FEES 2014 - Instituto de Computação

Transcrição

Congresso Brasileiro de Software: Teoria e Prática
28 de setembro a 03 de outubro de 2014 – Maceió/AL
VII FÓRUM DE EDUCAÇÃO EM ENGENHARIA DE SOFTWARE
FEES 2014
Anais
FEES
Volume 02
ISSN 2175-9677
Anais
FEES 2014
VII Fórum de Educação em Engenharia de Software
COORDENADOR DO COMITÊ DE PROGRAMA
Paulo Meirelles - Universidade de Brasília (UnB)
COORDENAÇÃO DO CBSOFT 2014
Baldoino Fonseca - Universidade Federal de Alagoas (UFAL)
Leandro Dias da Silva - Universidade Federal de Alagoas (UFAL)
Márcio Ribeiro - Universidade Federal de Alagoas (UFAL)
REALIZAÇÃO
Universidade Federal de Alagoas (UFAL)
Instituto de Computação (IC/UFAL)
PROMOÇÃO
Sociedade Brasileira de Computação (SBC)
PATROCÍNIO
CAPES, CNPq, INES, Google
APOIO
Instituto Federal de Alagoas, Aloo Telecom, Springer, Secretaria de Estado do Turismo
AL, Maceió Convention & Visitors Bureau, Centro Universitário CESMAC e Mix Cópia
2
FEES
PROCEEDINGS
Volume 02
ISSN 2175-9677
FEES 2014
VII Fórum de Educação em Engenharia de Software
PROGRAM CHAIR
CBSOFT 2014 GENERAL CHAIRS
ORGANIZATION
Universidade Federal de Alagoas (UFAL)
Instituto de Computação (IC/UFAL)
PROMOTION
Sociedade Brasileira de Computação (SBC)
SPONSORS
CAPES, CNPq, INES, Google
SUPPORT
Instituto Federal de Alagoas, Aloo Telecom, Springer, Secretaria de Estado do Turismo AL, Maceió Convention & Visitors Bureau, Centro Universitário CESMAC and Mix Cópia
3
FEES
Autorizo a reprodução parcial ou total desta obra, para fins acadêmicos, desde que citada a fonte
4
FEES
Apresentação
A Educação em Engenharia de Software tem sido apoiada e alavancada por esforços
de diversas instituições e sociedades educacionais e científicas da área da
computação. O Computing Curricula - Software Engineering Volume (CCSE), que surgiu
a partir de um desses esforços, fornece orientação às instituições acadêmicas de como
constituir o ensino-aprendizagem de Engenharia de Software, em termos de
graduação, por exemplo. Entre outros pontos, o CCSE afirma que a exposição aos
aspectos da prática profissional da Engenharia de Software deve ser um componente
integrante do currículo de graduação, abrangendo uma grande variedade de assuntos
e atividades, incluindo a resolução de problemas, gestão, questões éticas e legais,
bem como a escrita e comunicação oral, trabalhando o aluno para fazer parte de
equipes heterogêneas e responder às rápidas mudanças atuais da área.
No Brasil, nos últimos anos, foram criados alguns bacharelados em Engenharia de
Software. Além disso, temos as disciplinas e linhas de pesquisas já amplamente
estabelecidas nos cursos de graduação e pós-graduação em Ciência e Engenharia de
Computação, por exemplo. Com esse cenário de expansão e avanços do ensinoaprendizagem e pesquisa em Engenharia de Software no Brasil, temos também que
reunir um maior número de educadores/professores, pesquisadores e estudantes
para trocarem suas experiências e conhecimentos, bem como, colaborativamente
com seus pares, amadurecerem os métodos e formatos de ensino-aprendizagem de
Engenharia de Software, levando em conta também nossas características, inclusive
de mercado, nacionais e regionais.
Dessa forma, o Fórum de Educação em Engenharia de Software (FEES) visa a ser esse
espaço e momento, em que, através das publicações e apresentações das nossas
pesquisas e relatos de experiências, podemos como comunidade científica e
educacional, avançarmos no ensino-aprendizagem em Engenharia de Software, em
particular no contexto brasileiro.
5
FEES
Foreword
Education on Software Engineering has been supported and leveraged efforts of
various institutions and educational and scientific computing societies. The Computing
Curricula - Software Engineering Volume (CCSE), which grew out of one of these
efforts, provides guidance to academic institutions to provide teaching and learning of
Software Engineering. In this context, the CCSE states that exposure to professional
practices from Software Engineering should be an integrated component to the
bachelor's degree curriculum, covering a wide range of subjects and activities,
including problem solving, management, legal and ethical issues, as well as, written
and oral communication. This way preparing students to be part of diverse teams and
respond to fast changes in the current area.
In recent years, some Bachelors of Software Engineering were created in Brazil.
Moreover, we have disciplines and research areas already widely established in
bachelor and graduate Computer Science and Engineering courses, for example. With
this scenario of expansion and advancement of teaching-learning and research in
Software Engineering in Brazil, we also have to gather a large number of
educators/professors, researchers, and students to exchange their experiences and
knowledge, as well as, to collaborate to their peers to mature Software Engineering
teaching-learning methods, considering the Brazilian characteristics which include our
national and regional market.
Thus, the Software Engineering Education Forum (FEES 2014) aims be this space and
moment, wherein, through the publications and apresentations of ours research
results and experience reports, we can advance of Software Engineering Education as
cientifical and educational comunity, in particular in the Brazilian context.
6
FEES
Comitês Técnicos / Program Committee
Comitê do programa / Program Committee
Abraham Lincoln Rabelo - Centro Universitário La Salle (LaSalle-RS)
Alexandre Gomes de Lima - Instituto Federal do Rio Grande do Norte (IFRN)
Ana Paula Terra - Pontifícia Universidade Católica do Rio Grande do Sul (PUCRS)
André Gustavo Duarte - Instituto Federal do Rio Grande do Norte (IFRN)
Antonio Terceiro - Colivre
Auri Vincenzi - Universidade Federal de Goiás (UFG)
Bruno Carreiro - Universidade Federal da Bahia (UFBA)/SENAI-CIMATEC
Carlos Machado - Serviço Federal de Processamento de Dados (SERPRO)
Claudia Werner - Universidade Federal do Rio de Janeiro (UFRJ)
Clovis Fernandes - Instituto Tecnológico de Aeronáutica (ITA)
Edmundo Spoto - Universidade Federal de Goiás (UFG)
Eduardo Guerra - Instituto Nacional de Pesquisas Espaciais (INPE)
Edson Alves - Universidade de Brasília (UnB)
Ellen Francine Barbosa - Universidade de São Paulo (USP)
Emílio Francesquini - Universidade de São Paulo (USP)
Fellipe Aleixo - Instituto Federal do Rio Grande do Norte (IFRN)
Hilmer Neri - Universidade de Brasília (UnB)
Igor Steinmacher - Universidade Tecnológica Federal do Paraná (UFTPR)
Ingrid Nunes - Universidade Federal do Rio Grande do Sul (UFRGS)
Jorge Audy - Pontifícia Universidade Católica do Rio Grande do Sul (PUC-RS)
Leonardo Leite - Serviço Federal de Processamento de Dados (SERPRO)
Leonardo Minora - Instituto Federal do Rio Grande do Norte (Instituto Federal do Rio
Grande do Norte (IFRN))
Leônidas Brandão - Universidade de São Paulo (USP)
Marcelo Yamaguti - Pontifícia Universidade Católica do Rio Grande do Sul (PUC-RS)
Marcelo Pimenta - Universidade Federal do Rio Grande do Sul (UFRGS)
Marcelo Werneck - Pontifícia Universidade Católica de Minas Gerais (PUC-Minas)
Marco Aurélio Gerosa - Universidade de São Paulo (USP)
Marco Aurélio Graciotto - Universidade Tecnológica Federal do Paraná (UFTPR)
Marco A. Wehrmeister - Universidade Tecnológica Federal do Paraná (UFTPR)
Maurício Aniche - Universidade de São Paulo (USP)
Milene Serrano - Universidade de Brasília (UnB)
Rafael Messias - Universidade de São Paulo (USP)
Rejane Figueredo - Universidade de Brasília (UnB)
Rodrigo Santos - Universidade Federal do Rio de Janeiro (UFRJ)
Rodrigo Quites Reis - Universidade Federal do Pará (UFPA)
Sandro Andrade - Instituto Federal da Bahia (IFBA)
Thiago Souto Mendes - Instituto Federal da Bahia (IFBA)/Universidade Federal da
Bahia (UFBA)
7
FEES
Comitê organizador / Organizing Committee
COORDENAÇÃO GERAL
COMITÊ LOCAL
Adilson Santos - Centro Universitário Cesmac (CESMAC)
Elvys Soares - Instituto Federal de Alagoas (IFAL)
Francisco Dalton Barbosa Dias - Universidade Federal de Alagoas (UFAL)
COORDENADOR DO COMITÊ DO FEES 2014
8
FEES
Índice / Table of Contents
Artigos completos
Apoiando o Ensino de Qualidade de Software: Um Serious Game
para o Ensino de Usabilidade
Bruna Ferreira, Luis Rivero, Adriana Costa, Ana Beatriz Marques, Tayana
Conte
12
Aplicação de métodos de avaliação da experiência do usuário na
utilização de serious game em sala de aula
Anna Beatriz Marques, Adriana Lopes, Tayana Conte
22
Gamebok: jogo educativo para o ensino-aprendizagem do PMBOK
5ª edição
Fabricio Pinto, Marcos Paulo Correia Azevedo
32
Avaliação por Meio de Questionários de um Curso Online para
Engenharia de Software
Lucas Garcia, Ingridy Martins, Luiz Ferreira, Eduardo Figueiredo
40
Ambiente Integrado como Apoio ao Ensino da Engenharia de
Software
Simone Vasconcelos, Aline Vasconcelos
50
Artigos resumidos
DCCP: Uma Abordagem para Detecção de Colas em Provas de
Programação
Francisco Rodrigues Santos, Methanias Colaço Júnior, José Neto
58
O uso do dojo na prática pedagógica do ensino de
lógica de programação
Fabio Rocha, Rosimeri Sabino, Josephine Esan
62
Um Jogo Educacional para o Ensino de Metodologias Ágeis
Giani Petri, Rogério Paulo Marcon Junior
66
Formação de Equipes de Alto Desempenho para Desenvolvimento
de Software
Alessandra Dutra, Rafael Prikladnicki
70
ARPostIts: Mobile Application for Agile Software Engineering using
Augmented Reality
Dhiana Deva Rocha, Thaiana Lima, Claudia Werner, Claudia Susie Rodrigues
74
9
FEES
Aprendendo Programação Concorrente em Java com o Objeto de
Aprendizagem “Quero Bolo”
Fagner Silva Martins e Ayla Dantas
78
O uso de questionários para elicitação de informações sobre uma
estratégia didática em Engenharia e Requisitos
Joanna Pivatelli Bistene, Roxana Quintanilla Portugal, Priscila Engiel, Edgar
Alexander, Julio Cesar Sampaio do Prado Leite
82
Relatos estudos de casos
Práticas de colaboração no desenvolvimento de Software com o
Governo: impactos na aprendizagem de alunos de graduação
Camila Ferreira, Aline Gonçalves, Marisa Santos, Paulo Meirelles, Hilmer Neri
86
Experiência no Projeto Framework de Soluções de TI
Thatiany Lima de Sousa, Rejane Maria da Costa Figueiredo, Elaine Venson,
Ricardo Ajax Koslovisk
90
Uma Ferramenta de Apoio à Criação e Gerenciamento de Laudos
Patológicos Veterinários
Édylle Landy Oliveira, Luiz Venicio P. Conceição, Marcos César da Rocha
Seruffo
94
Sessão de pôsteres
Um Estudo de Caso sobre a Adoção de Métodos Ágeis na Gestão de
Contratos de Fornecedores de Desenvolvimento de Software em
uma Organização Pública Brasileira
Aline Gonçalves, Hilmer Neri
97
Um estudos sobre métricas de produto e vulnerabilidades para
tomada de decisões
Arthur Del Esposte, Carlos Bezerra, Paulo Meirelles, Hilmer Neri
99
A Platform Fed by Software Industry Problems to Learn Software
Development
Luiz Ferreira, Eduardo Figueiredo
101
Um estudo sobre bibliotecas digitais no contexto da participação
social
Luiz Matos, Fernando Cruz, Paulo Meirelles
103
Aspectos da Validação de Software em Metodologias Ágeis
Aplicáveis à Terceirização do Desenvolvimento de Software
Eduardo Pinto Barbosa, Elaine Venson
104
10
FEES
Mezuro, Evolução de Software Livre: Da Arquitetura à Experiência
do Usuário
Renan Costa, Vinícius Vieira, Paulo Meirelles
107
Técnicas de usabilidade e testes automatizados em processos de
desenvolvimento de software empírico
Rodrigo Medeiros, Jônatas Medeiros, Paulo Meirelles
109
O desenvolvimento do Novo Portal do Software Público Brasileiro
Camila Ferreira, Aline Gonçalves, Marisa Santos, Paulo Meirelles, Hilmer Neri
111
Rede de colaboração social para universidades brasileiras: um
estudo de caso de implantação e desenvolvimento distribuído de
uma plataforma livre na Universidade de Brasília
Daniel Costa Bucher, Paulo Meirelles
113
11
FEES
Apoiando o Ensino de Qualidade de Software
Um Serious Game para o Ensino de Usabilidade
Bruna Ferreira, Luis Rivero, Adriana Lopes, Anna Beatriz Marques e Tayana Conte
Grupo de Usabilidade e Engenharia de Software
Instituto de Computação Universidade Federal do Amazonas
Manaus - Brasil
{bmf, luisrivero, adriana, anna.beatriz, tayana}@icomp.ufam.edu.br
Abstract Usability inspection is a key activity for ensuring
software development with quality. One of the most applied
inspection techniques for evaluating the usability of software
artifacts is the Heuristic Evaluation (HE). However, the
performance of an inspector (number of identified defects and
time spent during the inspection) highly depends on the
ropriate for
experienced inspectors. In that context, it is necessary to invest in
teaching the HE technique, so novice inspectors can achieve
better results. In order to facilitate the learning process of the
developed
UsabiliCity, an educational game which uses analogies to explain
how the heuristics can help detect and solve specific usability
problems. Besides introducing the game, this paper shows its
evaluation process through an experiment. In that experiment, 37
students tried the game while observers identified improvement
I. INTRODUÇÃO
Usabilidade é um dos fatores estratégicos de qualidade de
software,
cuja
importância
tem
aumentado
no
desenvolvimento de aplicações interativas [7]. De acordo com
os critérios de qualidade de software, a norma ISO/IEC9126
define usabilidade como um conjunto de atributos
relacionados com o esforço necessário para o uso de um
sistema interativo e relacionado com a avaliação individual de
tal uso por um conjunto específico de usuários [3].
A avaliação de usabilidade é uma atividade fundamental
em qualquer processo de desenvolvimento que busque
produzir um sistema interativo com alta qualidade de uso [3].
Ela permite que um avaliador faça um julgamento sobre a
qualidade de uso do software desenvolvido (ou seus artefatos)
e identifique problemas que possam prejudicar a experiência
de uso [3]. Inspeção de usabilidade é um tipo de avaliação de
usabilidade onde um inspetor examina a interface verificando
se esta respeita padrões de usabilidade [5]. A vantagem de
utilizar inspeções no lugar de outros tipos de avaliações de
usabilidade (como teste com usuários) é que as inspeções
possuem baixo custo e alto benefício [5], diminuindo os custos
da identificação de problemas de usabilidade.
learning to verify if the game can assist them in better learning
experience. The results showed that overall, students found that
the analogies made it easier to understand the heuristics and that
the game was found educational and entertaining.
Resumo
A inspeção de usabilidade é uma atividade
fundamental para garantir o desenvolvimento de um software de
qualidade. Uma das técnicas de inspeção de usabilidade mais
aplicadas para avaliar a usabilidade de artefatos de software é a
Avaliação Heurística (AH). No entanto, o desempenho dos
inspetores (número de defeitos identificados e tempo gasto na
inspeção) depende da sua expertise, tornando a técnica mais
indicada para inspetores experientes. Desta forma, torna-se
importante investir no ensino da técnica AH para aumentar o
desempenho dos inspetores novatos. Com o intuito de facilitar o
processo de aprendizagem das heurísticas da técnica AH por este
tipo de inspetores, foi desenvolvido o jogo educacional
UsabiliCity que mostra, através de analogias, como as heurísticas
podem ajudar a detectar e resolver problemas específicos de
usabilidade. Além de introduzir o jogo, este artigo mostra a sua
avaliação através de um experimento. Neste contexto, 37 alunos
testaram o jogo, enquanto observadores identificaram
oportunidades de melhoria. Foi medida a percepção dos alunos
sobre o aprendizado para verificar se o jogo ajuda a entender
melhor as heurísticas. Os resultados mostraram que, de um modo
geral, as analogias facilitaram o entendimento das heurísticas e
que o jogo contribuiu para o processo de aprendizagem.
Uma das técnicas de inspeção de usabilidade mais
adotadas para avaliar a usabilidade de softwares [12] é a
Avaliação Heurística (AH), proposta por Nielsen [14]. A AH
utiliza um conjunto de heurísticas que são diretrizes que
orientam o inspetor a encontrar problemas de usabilidade na
interface. No entanto, apesar de permitir identificar um grande
número de problemas de usabilidade em pouco tempo, a
experiência do inspetor influencia no resultado da inspeção
[12].
Para melhorar o desempenho do inspetor ao aplicar a
técnica AH, é necessário que o mesmo entenda os atributos de
usabilidade avaliados pelas heurísticas. No entanto, apesar da
importância do ensino de técnicas de inspeção de usabilidade
para a identificação de problemas que afetam a qualidade de
software, estas técnicas raramente são ensinadas como um
elemento indispensável no processo de desenvolvimento de
software nos cursos de computação [4]. É indispensável que o
profissional de computação entenda os conceitos de
usabilidade para conseguir projetar e desenvolver sistemas
com maior qualidade de uso, diferenciando os seus produtos
perante o mercado e aumentando sua aceitação [10].
Keywords Usability Evaluation; Software Quality; Serious
Games; Heuristic Evaluation, Usability Inspection Methods
12
FEES
Uma forma de estimular o aprendizado de conceitos
relacionados com a computação e outras áreas (história,
geografia, matemática, literatura etc.) é através do uso de
Serious Games (SGs), que são jogos com outras finalidades
além do entretenimento [19]. SGs utilizam entretenimento
para promover treinamentos, educação, saúde e políticas
públicas [19]. Na educação, o uso de jogos pode tornar o
processo de ensino-aprendizagem mais atrativo e proveitoso
[10], permitindo reforçar conceitos através da prática [14]. A
utilização de jogos aumenta o envolvimento emocional de um
estudante, ocasionando variações de estímulos e ajudando-o a
reter novos conhecimentos [11].
atributos de usabilidade para prever se ocorrerá ou não um
problema de interação.
Ao executar uma avaliação de usabilidade, as duas abordagens
possuem vantagens e desvantagens. O teste com usuários é
mais eficaz na identificação de problemas de usabilidade que
afetam usuários finais [12]. No entanto, segundo Matera et al.
[13], ele possui alto custo, pois requer muitos recursos para
cobrir os diferentes perfis de usuário. Além disso, para aplicar
um teste com usuários, muitas vezes é necessário o uso de
laboratórios específicos de usabilidade. Métodos de inspeção
de usabilidade, por outro lado, podem ser usados nas primeiras
etapas do processo de desenvolvimento. Adicionalmente,
esses métodos requerem menos recursos e consequentemente,
podem diminuir os custos de encontrar problemas de
usabilidade [12]. Entre os métodos de inspeção de usabilidade
está a avaliação heurística.
Com o intuito de melhorar o entendimento das regras de
usabilidade descritas pela técnica AH, neste artigo é proposto
o uso de um Serious Game chamado UsabiliCity. O jogo
utiliza analogias para reforçar os conceitos das heurísticas da
AH. Desta forma, os inspetores novatos podem entender
melhor que tipos de problemas podem ser identificados e
solucionados. E assim obter melhores resultados na realização
de inspeção de usabilidade aplicando a técnica AH. Além
disso, para obter indícios da viabilidade do uso do jogo
UsabiliCity em um ambiente acadêmico, foi realizada uma
avaliação experimental inicial. Nesta avaliação, o jogo foi
testado por alunos de um curso de Ciência da Computação,
para verificar o grau de aprendizado das heurísticas após a sua
aplicação.
B. Avaliação Heurística
A avaliação heurística é um método de avaliação de
usabilidade criado por Nielsen [15], para apoiar a identificação
de problemas de usabilidade durante um processo de design
interativo. Este método orienta os avaliadores a inspecionarem
sistematicamente a interface, em busca de problemas que
prejudiquem a qualidade do software em termos de
usabilidade [5]. Para isso, a avaliação heurística utiliza como
base um conjunto de diretrizes de usabilidade que guiam os
inspetores durante o processo de avaliação. A TABELA I
apresenta a listagem completa das heurísticas propostas por
Nielsen [15] e suas descrições.
O restante deste trabalho está organizado da seguinte
forma: Na seção II são mostrados conceitos relacionados à
Inspeção de usabilidade, a técnica Avaliação Heurística e a
Jogos para Ensino de Qualidade de Software. Na seção III, é
apresentado o jogo UsabiliCity e como este utiliza analogias
para facilitar o processo de aprendizado das heurísticas da AH.
Na seção IV, é descrito o processo de avaliação experimental
do jogo e seus resultados. Por fim, são mostradas as
considerações finais e trabalhos futuros decorrentes desta
pesquisa.
Durante o processo de inspeção cada avaliador percorre
inicialmente a interface inspecionando os diferentes
componentes de interface em busca de problemas. Para cada
problema identificado, o avaliador deve anotar qual heurística
foi violada, em que local o problema foi encontrado, a
gravidade do problema e uma justificativa de por que aquilo é
um problema. O local em que o problema foi encontrado
indica quais partes da interface devem ser modificadas [12].
Depois que todas as inspeções individuais são concluídas, os
avaliadores se reúnem para consolidar os resultados. Em
seguida eles realizam um novo julgamento, onde decidem
quais problemas de usabilidade devem ser corrigidos e
sugestões de soluções.
II. BACKGROUND E TRABALHOS RELACIONADOS
A. Inspeção de Usabilidade
Métodos de Avaliação de Usabilidade são procedimentos
compostos por um conjunto definido de atividades que são
utilizadas para avaliar a usabilidade de um sistema. Os
métodos de avaliação podem ser divididos em duas categorias
[5]: teste com usuários e inspeções. Um teste com usuários é
uma avaliação centrada no usuário, na qual métodos
experimentais, observacionais e técnicas baseadas em
perguntas podem ser usados para avaliar a usabilidade do
sistema. O teste com usuários captura dados de uso de
usuários reais enquanto estes fazem uso do produto para
completar um conjunto definido de atividades. A análise dos
resultados oferece informações que podem ser usadas para
detectar problemas de usabilidade e assim melhorar o modelo
de interação do sistema. Inspeções, por outro lado, foram
propostas como uma alternativa com baixo custo e alto
benefício em comparação com os testes de usabilidade. Neste
contexto, inspeções são avaliações em que inspetores
verificam a conformidade dos artefatos de software com
C. Jogos no Ensino de Qualidade de Software
Apesar da importância da Usabilidade no desenvolvimento
de softwares de qualidade, técnicas de avaliação de
usabilidade raramente são ensinadas como um elemento
indispensável do processo de desenvolvimento de software
nos cursos de computação [4]. Como consequência,
profissionais da indústria de desenvolvimento de software
precisam dedicar mais tempo durante seu cotidiano
profissional para o aprendizado de técnicas de avaliação de
usabilidade [4].
A forma tradicional de ensino excessivamente centrada no
professor faz com que falte aos estudantes oportunidade para
aplicação prática dos conceitos [4]. Além disso, os métodos
tradicionais de ensino com base em livros texto e aulas
expositivas têm se mostrado insuficientes [6]. O uso de jogos
13
FEES
para treinar, aprender e executar atividades reais de
desenvolvimento de software em ambientes realísticos pode
melhorar o desempenho dos alunos, pois possibilita a vivência
de experiências de aprendizagem que não são fornecidas de
forma teórica [14]. Dentre os jogos existente para o apoio do
ensino de conceitos relacionados à qualidade de software
podemos citar o UsabilityGame [18], o Inspsoft [11] e o
InspectorX [16].
TABELA I RELAÇÃO ENTRE HEURÍSTICAS [15] E ANALOGIAS COM PROBLEMAS MOSTRADOS NA CIDADE
Heurística
Descrição da Heurística
Analogia Aplicada no Jogo
Visibilidade do
status do sistema
O sistema precisa manter os usuários informados sobre o
que está acontecendo, fornecendo um feedback adequado
dentro de um tempo razoável.
Locais da cidade não possuem nome, desta forma os
habitantes não sabem onde estão.
Concordância do
sistema com o
mundo real
O sistema precisa falar a linguagem do usuário, com
palavras, frases e conceitos familiares ao usuário, ao invés
de termos orientados ao sistema. Seguir convenções do
mundo real, fazendo com que a informação apareça numa
ordem natural e lógica.
Os símbolos e palavras que são mostrados nas placas
da cidade não fazem sentido.
Controle e
liberdade do
usuário
Os usuários frequentemente escolhem por engano funções
do sistema e precisam ter claras saídas de emergência para
sair do estado indesejado sem ter que percorrer um extenso
Há muitas ruas sem saída, o que dificulta a circulação
dos veículos.
Consistência e
padrões
Os usuários não precisam adivinhar que diferentes
palavras, situações ou ações significam a mesma coisa.
Seguir convenções de plataforma computacional.
Há sinais de trânsito diferentes (fora do padrão) em
vários locais da cidade, deixando os Users confusos.
Prevenção de erros
É melhor que o sistema possua um design cuidadoso o qual
previna o erro antes dele acontecer.
Quando há obras na cidade, nunca são colocados
avisos para evitar acidentes.
Reconhecer ao
invés de lembrar
O sistema deve tornar objetos, ações e opções visíveis. O
usuário não deve ter que lembrar informação de uma para
outra parte do diálogo. Instruções para uso do sistema
devem estar visíveis e facilmente recuperáveis quando
necessário.
As prateleiras do supermercado e das lojas não
possuem nomes indicando o que é vendido em cada
seção da loja, desta forma, toda vez que o habitante da
cidade volta ao local tem que lembrar onde se localiza
o que ele deseja comprar.
Flexibilidade e
eficiência de uso
Os usuários novatos se tornam peritos com o uso. O
sistema deve prover aceleradores de formar a aumentar a
velocidade da interação. O sistema deve permitir aos
usuários experientes "cortar caminho" em ações frequentes.
Na cidade é preciso fazer caminhos muito longos para
chegar a um local, a cidade não possui atalhos.
Estética e design
minimalista
Os diálogos não devem conter informação irrelevante ou
raramente necessária. Qualquer unidade de informação
extra no diálogo irá competir com unidades relevantes de
informação e diminuir sua visibilidade relativa.
Na cidade há nomes de locais muito detalhados sem
necessidade.
Ajudar os usuários
a reconhecer,
diagnosticar e
corrigir erros
As mensagens de erro devem ser expressas em linguagem
clara (sem códigos) indicando precisamente o problema e
construtivamente sugerindo uma solução.
Quando ocorre um problema (como um incêndio), não
há um bom serviço de bombeiros disponível para
ajudar na recuperação dos prédios.
Ajuda e
documentação
É necessário prover ajuda e documentação embora seja
melhor um sistema que possa ser usado sem documentação.
Essas informações devem ser fáceis de encontrar,
focalizadas na tarefa do usuário e não muito extensas.
Não há um serviço de ajuda para o User saber onde
pode obter determinado documento ou serviço.
O UsabilityGame [18] é um jogo simulador que aborda
aspectos do ciclo de vida de usabilidade. O jogo tem como
cenário uma empresa de desenvolvimento de software fictícia
que, após enfrentar problemas devido à falta de usabilidade de
seus produtos, está contratando engenheiros de usabilidade.
Assim, o jogador (aluno) ao ser contratado assume o papel de
engenheiro de usabilidade e deve buscar um bom desempenho
em cada uma das fases do jogo, que possuem relação com as
fases do ciclo de vida proposto.
InspSoft [11] é um jogo que tem por objetivo proporcionar
o aprendizado ao processo de inspeção de software, papéis dos
participantes em uma inspeção e na atividade de detecção de
defeitos através de um ambiente lúdico, com a finalidade de
entreter os jogadores através de seu enredo e dos personagens,
simulando uma inspeção de software em uma empresa. Assim,
é possível aprender sobre os papéis de cada participante no
processo de inspeção e saber os tipos de defeitos existentes.
O jogo InspectorX [16] foi construído com o objetivo de
desenvolver a percepção do jogador na identificação e
14
FEES
classificação de defeitos em artefatos de software, por meio do
condicionamento da observação dos padrões apresentados.
Cada questão do jogo é composta de um ou mais trechos de
artefatos de software (documentos de requisitos ou código
fonte). Cada trecho contém um ou mais defeitos que devem
ser corretamente identificados e classificados pelo jogador, de
forma a acumular pontos. Visando permitir um aumento
gradual na complexidade das tarefas, obedecendo à teoria do
esforço cognitivo, o jogo varia gradualmente o nível de
dificuldade [16].
interface do sistema. As dez governantes da cidade,
representam as diretrizes (heurísticas) utilizadas durante o
processo de inspeção com a técnica de Avaliação Heurística.
O uso de analogias tem por objetivo familiarizar o inspetor
novato com as heurísticas, de forma que ele tenha um melhor
entendimento das heurísticas e assim possa obter melhores
resultados ao realizar uma inspeção de usabilidade utilizando a
Avaliação Heurística. A TABELA I apresenta as analogias que
foram criadas para cada uma das heurísticas de Nielsen [15].
Apesar do grande uso de jogos educacionais na área de
computação, o único jogo para ensino de qualidade de
software em termos de usabilidade encontrado nesta pesquisa
foi o UsabilityGame. Além de ser o único jogo de usabilidade
identificado pelos autores deste trabalho, este jogo não foi
avaliado experimentalmente. Os outros dois jogos Inspsoft e
InspectorX também são utilizados para o ensino de inspeção
de software, mas não possuem foco em inspeção de
usabilidade. Sendo assim, existe a necessidade de propor
novos jogos para apoiar ensino de usabilidade, visto que os
jogos são uma forma de tornar o ensino mais atraente e
divertido. Para minimizar estes problemas, está sendo
proposto o jogo UsabiliCity, que será descrito a seguir.
III. USABILICITY
Fig. 1. Tela de contextualização do jogo UsabiliCity.
UsabiliCity é um Serious Game, desenvolvido para Web,
que tem por objetivo apoiar o entendimento do aluno sobre as
heurísticas propostas por Nielsen [15] para inspeção de
usabilidade. No jogo, problemas típicos de usabilidade que
podem ocorrer em um sistema são exemplificados por meio de
analogias com problemas em uma cidade, tentando tornar os
problemas descritos pelas heurísticas mais familiares aos
inspetores novatos. Através do uso de analogias com situações
do cotidiano, o jogo tenta ajudar o aluno a entender melhor
quais são os problemas que uma determinada heurística pode
ajudar a identificar para melhorar a usabilidade da interface de
um software.
A Fig. 2 apresenta a tela do jogo que mostra a cidade, onde
o jogador deverá selecionar qual fase irá jogar. No início do
jogo, apenas a fase inicial está habilitada (uma fase está
habilitada quando o número da fase está em vermelho).
Conforme o jogador for concluindo as fases, ele terá acesso às
próximas fases do jogo, totalizando cinco fases. Caso o
jogador queira, ele poderá revisitar as fases que já concluiu.
A interface do jogo UsabiliCity foi definida com base em
ideias da primeira autora deste artigo de forma a estimular o
aprendizado e torná-lo divertido para os alunos. A Fig. 1
mostra como a história do jogo é apresentada ao aluno. A
criação de uma história busca envolver o aluno com o jogo, de
forma a tornar o aprendizado mais divertido. Na história, o
aluno tem o papel de um inspetor (representado por um
menino com uma lupa) que deve ajudar a identificar quem
pode solucionar alguns problemas da cidade. A cidade,
chamada de UsabiliCity, é um lugar com muitos problemas na
sua estrutura que dificultam a realização das tarefas diárias dos
seus moradores (os Users). Desta forma, UsabiliCity é
governada e organizada pelas dez heurísticas de Nielsen [15].
Fig. 2. Tela de seleção de fase do jogo.
Ao acessar uma fase, o jogo apresenta uma tela como a da
Fig. 3. Nesta figura, o Elemento 1 indica: (a) o número da
fase, e (b) o título da fase em termos de
problemas/propriedades típicos de usabilidade. Já o Elemento
2 da Fig. 3 apresenta a descrição dos problemas presentes na
cidade que devem ser resolvidos na fase do jogo. Em cada fase
são descritos dois problemas distintos. Para cada um dos
problemas, o jogador deve selecionar uma heurística que será
a responsável pela sua solução. Finalmente, na Fig. 3
Elemento 3 são apresentadas as dez heurísticas para seleção
pelo jogador. Para chamar a atenção do jogador, as heurísticas
são representadas em forma de personagem. Durante o jogo, o
O objetivo do jogo é descobrir quais heurísticas podem
ajudar a encontrar os problemas descritos para reorganizar a
cidade e torná-la um lugar melhor para os Users. No contexto
de desenvolvimento de software, a cidade seria o sistema em
si, os problemas na estrutura da cidade seriam os problemas de
usabilidade que ocorrem nos sistemas. Os habitantes da cidade
representam os usuários do sistema, que têm suas atividades
dificultadas devido aos problemas de usabilidade existentes na
15
FEES
jogador deve selecionar as duas heurísticas adequadas que
ajudam a identificar os problemas descritos na fase corrente
(ver Fig. 3 - Elemento 2).
encontrar na interface. Quando o aluno tiver certeza das
heurísticas que podem ajudar a resolver o problema na
UsabiliCity, este pode selecioná-las clicando nelas (ver Fig. 4
Parte B). O aluno pode selecionar apenas duas das dez
heurísticas disponíveis em cada fase. Se o aluno quiser
modificar sua resposta, ele pode reiniciar a fase. Finalmente,
quando o aluno tiver certeza da sua escolha, pode validar sua
Fig. 3). Caso o jogador
escolha as heurísticas corretas, este poderá passar para a
próxima fase.
A Fig. 4 apresenta o processo de escolha das heurísticas
através do qual o aluno pode fixar melhor que tipo de
problemas de usabilidade cada heurística pode ajudar a
resolver. Nesse sentido, o aluno pode checar a descrição da
heurística como mostra a Fig. 4 (Parte A).
Ao passar o mouse sobre as heurísticas, é apresentado um
balão informando que tipo de problemas a heurística ajuda a
Fig. 3. Tela de uma das fases do jogo UsabiliCity.
Fig. 4. Processo de Seleção da Heurísticas do Jogo.
.
16
FEES
A Fig. 5 mostra as diferentes telas que podem ser
apresentadas ao jogador dependendo do seu desempenho em
cada fase. A Fig. 5 (Elemento A) apresenta a tela de sucesso,
ou seja, o jogador conseguiu identificar todas as heurísticas da
fase corretamente. Já a Fig. 5 (Elemento B) apresenta a tela de
fracasso, quando o jogador errou uma ou duas heurísticas na
fase. Nesse caso, o jogador ainda pode verificar as respostas
da fase, o que leva o jogo a apresentar a tela da Fig. 5
(Elemento C). Nesta tela são indicados os motivos pelos quais
uma determinada heurística foi escolhida para solucionar um
problema. Desta forma, o aluno pode entender melhor para
que tipo de problemas uma determinada heurística é mais
adequada.
O questionário fornecido por Savi et al. [17] é dividido em
duas etapas. Na primeira etapa, o participante deve indicar sua
opinião em relação a itens de avaliação que estão divididos em
três categorias Motivação, Experiência do Usuário e
Aprendizagem. Para indicar sua opinião, o participante avalia
os itens do questionário de cada categoria em uma escala de
cinco itens: ( 2) discordância forte, (-1) discordância, (0) nem
concorda nem discorda, (+1) concordância e (+2)
concordância forte. Na segunda etapa do questionário, o
participante faz uma autoavaliação em relação aos objetivos
de aprendizagem. Para isso, o participante atribui uma nota
obtido antes e depois do jogo. Os itens avaliados nesta parte
do questionário são: (a) Lembrar o que é; (b) Compreender
como funciona; e (c) Aplicar na prática. A Fig. 6 apresenta um
exemplo da segunda etapa do questionário aplicado após o uso
do jogo Usabilicity com o intuito de avaliar o aprendizado em
relação às heurísticas da AH.
Fig. 6. Parte do questionário para autoavaliação em relação aos objetivos de
aprendizagem.
Finalmente, foi acrescentada uma terceira etapa ao
ao acrescentar estas questões foi permitir um melhor
entendimento das respostas dos participantes em relação às
categorias do modelo.
Fig. 5. Telas de sucesso, fracasso e respostas das fases.
IV. AVALIAÇÃO DO JOGO USABILICITY
A efetividade dos jogos propostos como ferramenta de
apoio ao processo de ensino e aprendizagem deve ser avaliada
para garantir que os mesmos tenham um efeito positivo no
aprendizado do jogador [21]. Desta forma, torna-se necessário
avaliar o jogo UsabiliCity como ferramenta de aprendizagem,
verificando se o mesmo tem um efeito positivo na
aprendizagem dos conceitos das heurísticas. Nesta seção é
descrito o processo de avaliação do jogo e seus resultados.
O modelo proposto por Savi et al. [17] fornece uma
planilha configurada para análise dos itens de avaliação
respondidos pelos participantes. Vale ressaltar, que este
modelo já foi utilizado na avaliação de vários outros jogos
educacionais na área de Computação [11][20][21].
A avaliação do jogo foi realizada através de um estudo de
observação cujos participantes foram 37 alunos do 5º período
do curso de Ciência da Computação da Universidade Centro
Universitário do Norte (UNINORTE). Antes da avaliação do
jogo, todos os alunos assistiram aulas sobre inspeção de
usabilidade utilizando a técnica Avaliação Heurística [15] e
assinaram um termo de consentimento, onde concordavam em
participar do estudo. Para apoio ao processo da avaliação
experimental, foram selecionados 11 monitores: 9 monitores
agiram como observadores e 2 verificaram a completude das
respostas aos questionários.
A. Materiais e Procedimentos
Para avaliação do aprendizado com o jogo UsabiliCity, foi
utilizado o modelo proposto por Savi et al. [17] que permite
avaliar jogos educacionais. Este modelo fornece um
questionário que considera: (a) os programas de treinamento
de Kirkpatrick [9], (b) as estratégias motivacionais do modelo
ARCS (Atenção, Relevância, Confiança e Satisfação) [8], (c) a
experiência do usuário que mede o engajamento do jogador ao
utilizar o jogo, e (d) a taxonomia de objetivos educacionais de
Bloom [2].
A avaliação ocorreu em duas etapas: (a) Utilização do
jogo; e (b) Preenchimento do questionário. Durante a
utilização do jogo, cada um dos monitores que agiram como
observadores acompanhavam um aluno. Cada monitor tinha
17
FEES
um computador com o jogo Usabilicity instalado e o
apresentava ao aluno, convidando-o a jogar. Enquanto o aluno
jogava, o monitor tomava notas sobre o tempo de interação do
aluno com o jogo, as dificuldades encontradas e as reações do
aluno em relação ao jogo.
itens de avaliação de cada categoria. Desta forma, considerase concordância em um determinado item se as notas +1 e +2
forem mais frequentes; e discordância se notas -1 e -2
apresentarem maior frequência.
Para avaliação da segunda parte do questionário,
relacionada ao aprendizado que o aluno julga ter obtido antes
e depois do jogo, foi calculada uma média para cada conceito
explorado. No caso do jogo UsabiliCity, os conceitos
explorados foram as heurísticas de Nielsen [15] para resolver
problemas de usabilidade. Após o cálculo das médias, foram
gerados gráficos do aprendizado percebido pelos alunos antes
e depois da utilização do jogo para cada heurística.
O tempo médio de utilização do jogo pelos participantes
foi de 10,91 minutos, sendo o maior tempo identificado igual a
27 minutos, indicando que é viável a utilização do jogo
durante uma aula normal, que geralmente tem duração de 2
horas. Na TABELA II é feito um resumo das principais
observações feitas pelos monitores enquanto os jogadores
utilizavam o jogo.
TABELA II RESULTADOS DAS OBSERVAÇÕES FEITAS PELOS MONITORES
ID
01
02
03
04
05
06
07
08
A terceira parte do questionário, relativa às perguntas
respondidas livremente, sobre pontos fortes, pontos fracos e
sugestões de melhorias para jogo, foram utilizadas para
complementar as respostas obtidas nas outras partes do
questionário. A seguir, são relatados os resultados relativos a
cada categoria e à percepção do aprendizado dos alunos antes
e depois do jogo.
Observações dos Monitores
Não ficou claro para os alunos como selecionar as respostas (indicar
as heurísticas) nas fases.
Os alunos não percebiam que deviam ser escolhidas duas
heurísticas por fase.
Para alguns alunos a fonte não era agradável.
Não era possível desmarcar uma heurística após ter sido
selecionada, o aluno precisava reiniciar a fase.
A seleção da heurística com a cor vermelha assustou os alunos,
estes pensavam que tinham cometido um erro.
Um aluno se divertiu ao ver boneco chorar quando perdia a fase.
Os alunos gostaram dos balões com informações sobre a heurística.
Alguns alunos acharam que a tela continha muita informação.
1) Análise de Resultados da Categoria de Motivação
Na categoria de motivação, foram avaliadas as dimensões
de confiança, relevância e atenção. O gráfico da Fig. 7,
mostra as afirmativas relacionadas a cada uma das dimensões
e as porcentagens relativas a cada afirmativa. Sobre a
dimensão de Confiança, 95% dos participantes afirmam sentir
confiança sobre o aprendizado obtido ao passar pelas etapas
do jogo. Entre os alunos, 82% concordam que o jogo foi fácil
de entender e começar a jogar, como mostra o comentário
Do que você gostou no jogo?
B. Resultados da Avaliação
Para a interpretação das respostas dos participantes na
primeira parte do questionário de avaliação do modelo
proposto por Savi et al. [17], foi utilizada a planilha que o
mesmo modelo disponibiliza para apoiar a análise das
categorias: Motivação, Experiência do Usuário e
Aprendizagem. Nesse contexto, foram gerados gráficos das
frequências das notas atribuídas pelos participantes para os
Da interação e facilidade ao jogar, também a atenção
que o sistema oferece para o usuário, mostrando que ao
praticar o game, ele aprende de uma forma mais atraente.
Participante 5
Fig. 7. Gráfico de Avaliação da categoria Motivação.
18
FEES
Na dimensão Relevância houve afirmação de 91% dos
participantes sobre o conteúdo relacionado com outros
conhecimentos que já possuíam, 91% dos participantes
avaliam o jogo adequado com a maneira de aprenderem e 95%
afirmam que o conteúdo do jogo é relevante para seus
interesses, sendo esta última afirmativa reforçada pelo
comentário descrito abaixo:
que atingiram os objetivos do jogo por meio de suas
habilidades.
Na dimensão de Diversão, 93% dos participantes afirmam
que gostariam de utilizar o jogo novamente, sendo que 2
participantes não responderam a esta afirmativa. E 88% dos
participantes recomendam o jogo para seus colegas. O
comentário a seguir reforça o resultado obtido para a primeira
afirmativa desta dimensão:
É interessante para minha formação, pois trata de
conhecimentos que uso na faculdade na matéria de IHC que
estou estudando atualmente. Participante 15
Só tem uma versão, já estou esperando as próximas.
Participante 5
Sobre a dimensão da Atenção, 67% dos participantes
afirmam que a variação do jogo ajudou a mantê-los atentos.
No item que avalia se o participante achou algo interessante
no início do jogo que capture sua atenção, houve concordância
entre 51% dos participantes Em relação ao design do jogo,
64% consideram o design atraente. Os comentários descritos a
seguir reforçam os resultados obtidos:
Para o item que avalia se os participantes ficaram
desapontados com a interrupção do fim do jogo, houve uma
concordância com apenas 48% dos participantes. A baixa
concordância quanto a este item pode ser justificada por
alguns itens do jogo que não agradaram aos alunos. Além
disso, como o estudo foi realizado em uma turma noturna,
alguns alunos já estavam cansados e com desejo de ir para
casa. Dentro dos itens que afetaram a avaliação dos
participantes podem ser citados: falta de áudio, animações ou
pontuação no jogo, conforme relatado no comentário descrito
abaixo:
Gostei do jogo, pois ele me fez dar mais atenção a ele,
pois deixou um mistério, me fez querer descobrir as
respostas
Participante 26
As perguntas são de acordo com o dia a dia, desperta o
interesse pessoal.
Participante 27
Deveria ter algo mais dinâmico, que deixasse a tela com
mais movimento. Participante 31
2) Análise de Resultados da Categoria de Experiência do
Usuário
Na categoria sobre Experiência do Usuário são avaliadas
quatro dimensões: Competência, Diversão, Desafio e Imersão.
A Fig. 8 apresenta o gráfico dos resultados obtidos para a
categoria de Experiência do Usuário em relação às perguntas
de cada uma das dimensões. Desta forma, sobre a avaliação da
dimensão de Competência, 88% dos participantes tiveram
sentimentos positivos de eficiência no jogo e 69% afirmam
No entanto, apesar dos problemas encontrados, 79% dos
alunos afirmam que se divertiram com o jogo, sendo que um
aluno não respondeu a esta afirmativa. O comentário abaixo
reforça os indícios obtidos:
Linguagem fácil e intuitiva, gráficos parecidos com
nintendo wii, isso causou certo estímulo. Foi legal jogar e
aprender. Participante 8
Fig. 8. Gráfico de Avaliação da categoria Experiência do Usuário.
19
FEES
Para a dimensão do Desafio 67% concordam que o jogo
não fica monótono ao oferecer novos obstáculos ou variação e
66% afirmam que as tarefas do jogo são adequadamente
desafiadoras. Os itens da dimensão Desafio tiveram baixa
concordância devido ao fato de que, quando o aluno erra a
fase, é mostrada a resposta. Vários alunos afirmaram que isto
acaba tirando a vontade de continuar jogando, pois após a
mensagem, já se sabe a resposta, conforme ilustra o
comentário abaixo:
Eu tiraria a mensagem que informa qual heurística
deveria ser usada ao errar. Isso acaba tirando a vontade de
continuar jogando.
Participante 1
Fig. 9. Gráfico de Avaliação da categoria Aprendizagem.
No entanto, outros alunos gostaram, pois se sentiram
estimulados a continuar jogando, como indica o comentário a
seguir:
Outra forma utilizada para avaliar a aprendizagem, foi
através da autoavaliação do aluno em relação ao seu
aprendizado. Os conceitos avaliados no jogo foram em relação
às dez Heurísticas de Nielsen [15]. Em relação à
aprendizagem do conceito das Heurísticas, foram avaliados
três objetivos, antes e depois de utilizar o jogo: (a) Lembrar o
que é, (b) Compreender como funciona e (c) Aplicar na
Prática. A Fig. 10 apresenta o gráfico com as médias de
autoavaliação dos alunos em relação aos objetivos de
aprendizagem, antes e depois do jogo, onde se observa um
aumento do nível de conhecimento em todos os objetivos de
aprendizagem do jogo para todas as heurísticas da AH. Este
resultado é positivo, pois indica que o jogo oferece
oportunidade para os alunos colocarem em prática os assuntos
estudados durante as aulas teóricas e contribui para o
aprendizado da Avaliação Heurística.
Gostei porque ele deixa o usuário evoluir durante o jogo,
mesmo errando, ele mostra a resposta e deixa passar de fase
- Participante 4
Para a última dimensão avaliada na categoria, a Imersão, o
item que avalia se o participante se sentiu mais no ambiente do
jogo do que no mundo real, houve confirmação de 48%. Além
disso, 60% dos alunos não perceberam o tempo passar
enquanto jogavam e 61% afirmam que esqueceram as
preocupações enquanto estavam jogando. Novamente, a falta
de áudio, animações e pontuação afetou a opinião dos
participantes, de acordo com os seguintes comentários:
Poderia citar mais situações do mundo real e colocar
fundo musical para atrair mais os usuários - Participante 13
Colocaria algumas animações
- Participante 17
Faria o jogo por pontuação de acertos. Acima de 50% a
cidade não seria destruída
Participante 21
3) Análise de Resultados da Categoria de Aprendizagem
O gráfico dos resultados da categoria de Aprendizagem é
apresentado na Fig. 9. Houve concordância de 86% dos
participantes sobre o item que avalia se o jogo traz
contribuições para a vida profissional. Para o item que avalia
se os participantes consideram o jogo eficiente em
comparação com outras atividades da disciplina, houve 92%
de concordância e 91% dos participantes afirmam que o jogo
trouxe contribuições na aprendizagem sendo que 7 alunos não
assinalaram resposta a esta última afirmativa.
Os comentários relatados
reforçam os porcentuais obtidos:
por
alguns participantes
Gostei do conteúdo dado através do jogo, reforça o
aprendizado no assunto - Participante 13
Gostei da correção dos erros, ajudando a relembrar os
assuntos ensinados em sala de aula - Participante 18
Ajudou a
Participante 24
melhorar os meus
conhecimentos
Fig. 10. Gráfico das medidas de autoavaliação sobre os objetivos de
aprendizagem.
V. CONSIDERAÇÕES FINAIS E TRABALHOS FUTUROS
Este trabalho apresentou o jogo UsabiliCity para apoio ao
ensino das heurísticas da Avaliação Heurística e sua avaliação
20
FEES
experimental. Para avaliação do jogo foi utilizado o Modelo
de Savi et al. [17]. Em relação a este modelo, através dos
resultados fornecidos, foi possível obter as opiniões dos
usuários sobre o aprendizado, motivação e experiência do
usuário.
Alfabetização Infantil. Anais do Simpósio Brasileiro de Informática na
Educação, 2013.
[2] Anderson, L., Krathwohl, D., Airasian, P., Cruikshank, K., Mayer, R.,
Pintrich, P., Raths, J., Wittrock, M.: A Taxonomy for Learning, Teaching,
and Assessing: a Revision of Bloom's Taxonomy of Educational
Objectives. Longman, NewYork, pp. 336, 2001.
Apesar dos indícios sobre a utilidade do jogo para o ensino
das Heurísticas de Nielsen [15] a inspetores novatos, foram
identificadas oportunidades de melhorias na interface do jogo
para facilitar o seu uso. Dentre as possíveis melhorias,
pretende-se incorporar áudio e animações, de forma a
melhorar a experiência do usuário e tornar o jogo mais atrativo
e dinâmico. Além disso, pretende-se melhorar o design de
interação do jogo, principalmente com relação à forma em que
as heurísticas são escolhidas em cada fase, e a forma de ver a
resposta das fases. Adicionalmente, conforme sugerido pelos
participantes, será feito um estudo sobre que elementos de
ludicidade podem ser incorporados ao jogo para torná-lo mais
atraente como: pontuação, perfil de jogador, entre outros.
Também serão revisadas as analogias feitas para as heurísticas
de forma a alinhá-las corretamente no contexto da cidade
UsabiliCity e serão adicionadas mais fases ao jogo,
descrevendo mais problemas, para que inspetores novatos
possam praticar mais e ter maior aprendizado dos problemas
que as heurísticas da técnica Avaliação Heurística podem
ajudar a identificar nas interfaces de software.
[3] Barbosa, S., Silva B.: Interação Humano-Computador, Rio de Janeiro:
Elsevier, 2010.
[4] Benitti, F., Sommariva, L.: Investigando o ensino de IHC no contexto da
computação: o que e como é ensinado?. In: Workshop sobre Ensino de
IHC, 2012.
[5] Conte, T., Vaz, V., Zanetti, D., Santos, G., Rocha, A., Travassos, G.:
Aplicação do Modelo de Aceitação de Tecnologia para uma Técnica de
Inspeção de Usabilidade. Simpósio Brasileiro de Qualidade de Software,
pp. 367-374, 2010.
[6] Desurvire, H., Faster, C.: Are Usability Inspection Methods as Effective
as Empirical Testing?. In: Nielsen, Jakob. Usability Inspection Methods
Computer. John Wiley & Sons, New York, NY, 1994.
[7] Juristo, N., Moreno, A., Sanchez-Segura, M.: Analyzing the impact of
usability on software design. Journal of Systems and Software, Volume
80, Issue 9, 2007.
[8] Keller, J.: Development and Use of the ARCS Model of motivational
Design. Journal of Instructional Development, Volume 10, Issue 3, pp. 2
10, 1987.
[9] Kirkpatrick, D.: Evaluating Training Programs - The Four Levels. BerrettKoehler Publishers, pp. 289, 1994.
[10]Kochanski, D.: Um framework para apoiar a construção de experimentos
na avaliação empírica de jogos educacionais. Dissertação apresentada à
Universidade do Vale do Itajaí como requisito para a obtenção do título
de Mestre em computação. São José, Brasil, 2009.
Uma limitação deste trabalho é que o jogo foi avaliado
segundo o Nível 1 (Reação), do modelo de quatro níveis para
avaliação de aprendizagem proposto por Kirkpatrick [9]. É
necessário continuar a avaliação do jogo nos outros níveis
(aprendizado, comportamento e resultados) para garantir que o
efeito do mesmo seja positivo em todos os níveis de
aprendizado do aluno. Consequentemente, pretende-se realizar
uma nova avaliação para verificar se o jogo proporciona
aumento nas competências do inspetor novato, permitindo um
melhor desempenho na aplicação da técnica da Avaliação
Heurística. Além disso, pretende-se utilizar outros métodos de
avaliação de jogos educacionais (como o proposto por An et
al. [1]) para verificar a viabilidade do uso do UsabiliCity em
sala de aula. Espera-se desta forma, contribuir para o ensino
de Qualidade de Software em termos de usabilidade em cursos
de computação no Brasil.
[11]Lopes, A., Marques, A., Conte, T.: Avaliação do Jogo InspSoft: Um Jogo
para o Ensino de Inspeção de Software. In: XII Simpósio Brasileiro de
Qualidade de Software, 2013.
[12]Maciel, C., Nogueira, J., Ciuffo, L., Garcia, A.: Avaliação heurística de
sítios na web. Anais do 9º Congresso Regional de Informática e
Telecomunicações - SUCESU-MT. Cuiabá : PAK Multimídia, 2004.
[13]Matera, M., Rizzo, F., Carughi, G. T.: Web Usability: Principles and
Evaluation Methods. Mendes, E., Mosley, N. (eds), Web Engineering,
2006.
[14]Monsalve, E., Werneck, V., Leite, J.: SimulES-W: Um Jogo para o
Ensino de Engenharia de Software. Anais do FEES 2010/ CBSoft 2010.
SBC, 2010. v.1. pp. 17 26, 2010.
[15]Nielsen, J.: Usability engineering. Morgan Kaufmann Pub, 1994.
[16]Pötter, H., Schots, M.: InspectorX: Um Jogo para o Aprendizado em
Inspeção de Software. IV Fórum de Educação em Engenharia de Software
(FEES'11), São Paulo, 2011
AGRADECIMENTOS
Os autores agradecem a todos os participantes do estudo,
aos monitores que colaboraram durante a execução do estudo.
Além disso, os autores agradecem aos revisores deste artigo
no Fórum de Educação em Engenharia de Software pelas
sugestões propostas para a melhoria do jogo UsabiliCity.
Finalmente, os autores agradecem o apoio financeiro do CNPq
e da Fundação de Amparo à Pesquisa do Estado do Amazonas
(FAPEAM) através do Projeto ProTI
Pesquisa sob o
processo n. 062.00578/2014.
[17]Savi, R., Wangenheim, C., Borgatto, A.: Um Modelo de Avaliação de
Jogos Educacionais na Engenharia de Software. Anais do XXV Simpósio
Brasileiro de Engenharia de Software (SBES 2011), São Paulo, 2011.
[18]Sommariva, L., Benitti, F., Vavassori, D.: UsabilityGame: jogo simulador
para apoio ao ensino de usabilidade. In: Proceedings of the 10th Brazilian
Symposium on on Human Factors in Computing Systems and the 5th
Latin American Conference on Human-Computer Interaction. Brazilian
Computer Society, pp. 61-65, 2011.
[19]Vargas, J., García-Mundo, L., Genero, M., Piattini, M.: A Systematic
Mapping Study on Serious Game Quality, 2011.
REFERÊNCIAS
[20]Wangenheim, C., Savi, R., Borgatto, A.: SCRUMIA An Educational
Game for Teaching SCRUM in Computing Courses. Journal of Systems
and Software, Volume 86, Issue 10, 2013.
[1] An, D., da Silva, C. , Ribeiro, D., da Rocha, P., Maltinti, C., Nunes, V.,
Fávero, R.: Digita-um Jogo Educativo de Apoio ao Processo de
[21]Wangenheim, C., Savi, R., Borgatto, A.: DELIVER! An Educational
Game for Teaching Earned Value Management in Computing
Courses. Information and Software Technology, Volume 54, Issue 3,
March 2012.
21
FEES
Aplicação de métodos de avaliação da experiência
do usuário na utilização de serious game em sala de
aula
Anna Beatriz Marques, Adriana Lopes, Tayana Conte
Grupo de Usabilidade e Engenharia de Software
Instituto de Computação – Universidade Federal do Amazonas
Manaus – Brasil
{anna.beatriz, adriana, tayana}@icomp.ufam.edu.br
corporativo, educação, saúde, políticas públicas e objetivos
estratégicos de comunicação”. Serious games estão sendo
projetados, desenvolvidos e avaliados para uma população
diversificada de usuários e abrangem um amplo espectro de
variados conteúdos [5].
Resumo— Serious games são jogos com outras finalidades além
do entretenimento, e têm sido utilizados como apoio ao ensino de
diversos tópicos da Engenharia de Software. Porém não é o bastante
que estes jogos sejam apenas didaticamente adequados e provedores
do aprendizado, é necessário que eles proporcionem uma boa
experiência aos alunos. Portanto, torna-se importante avaliar a
experiência de uso destas aplicações. Neste artigo, é relatada a
avaliação do jogo uTest através de dois métodos de avaliação da
experiência do usuário: Game Experience Questionnarie e as 10
Heurísticas da Emoção. Além disso, os resultados permitiram
identificar possíveis melhorias nos métodos de avaliação aplicados
que poderiam enriquecer os resultados obtidos.
A experiência do usuário é um conceito mais amplo de
qualidade de uso que engloba também a usabilidade,
explorando como uma pessoa se sente em relação a um produto
e está mais relacionada a aspectos subjetivos tais como a
motivação, a expectativa e a satisfação no uso de um produto
[6]. Geralmente, um serious game é adotado em sala de aula
como forma de motivar os alunos no ensino de um determinado
tópico. Por esta razão, é muito importante que a experiência do
usuário proporcionada pelo serious game seja positiva.
Portanto, ao selecionar um serious game, seria interessante
dispor de resultados anteriores da experiência de usuários para
evitar que a tentativa de motivação resulte em uma experiência
contrária, tal como a frustração dos alunos.
Abstract— Serious games are games for purposes other than
entertainment and have been used to support the teaching of various
disciplines in software engineering. However, it is not enough to be
didactic adequate and learning providers but it is necessary to provide
a good experience for students. Therefore, it becomes important to
assess the students' use experience with serious game. In this paper,
we report the evaluation of uTest game using two user experience
evaluation methods: Game Experience Questionnaire and the 10
heuristics of Emotion. Furthermore, the results allowed identify
possible improvements in user experience of serious game that could
enrich the results.
Uma iniciativa de incluir a avaliação da experiência do
usuário para serious game foi realizada por Savi et al. [7] ao
propor um modelo de avaliação para jogos educacionais de
Engenharia de Software. No modelo existem três subescalas de
avaliação, e uma das subescalas é a experiência do usuário, que
foi composta a partir de quatros modelos encontrados na
literatura [1][8][9][10]. Os conceitos considerados na subescala de experiência do usuário são: Imersão, Interação Social,
Desafio, Diversão, Controle e Competência [7]. Considerando
que o enfoque do método não é apenas avaliar a experiência do
usuário, torna-se interessante a utilização de métodos próprios
para a avaliação da experiência do usuário, de modo a
enriquecer os resultados obtidos.
Keywords—Software Engineering education, serious games;
user experience; software testing.
I.
INTRODUÇÃO
Um dos problemas relacionados à capacitação de métodos e
técnicas de Engenharia de Software (ES) se deve ao fato de que
as iniciativas de treinamento muitas vezes possuem um enfoque
teórico [1]. Uma forma de motivar o aprendizado e diminuir o
enfoque teórico é através do uso de jogos que estimulem o
aprendizado [2]. O termo atualmente adotado para jogos que
possuem, além do entretenimento, o foco na aprendizagem é
serious game [3].
Este artigo apresenta uma discussão sobre os resultados
obtidos na avaliação da experiência do usuário para o serious
game uTest [2], que apoia o ensino de teste de software. Para a
avaliação do serious game, foram utilizados os métodos Game
Experience Questionnarie [11] e as 10 Heurísticas da Emoção
[12]. Através destes métodos foi possível analisar diferentes
aspectos da experiência dos alunos durante a utilização do
uTest.
Ritterfeld et al. [3] definem serious games como jogos para
um ou mais jogadores, cujo objetivo não é somente o
entretenimento. De maneira mais ampla, Zyda [4] descreve um
serious game como “uma disputa mental através de um
computador, com regras específicas definidas, que utiliza
entretenimento para promover treinamento governamental ou
O restante deste artigo está organizado da seguinte forma:
primeiramente, são apresentados os métodos de avaliação da
22
FEES
TABELA I.
experiência do usuário utilizados. Em seguida, são descritas a
avaliação do serious game uTest e a análise dos resultados
obtidos sob o enfoque da experiência do usuário. Na seção
seguinte, é apresentada uma discussão a respeito dos resultados
obtidos e métodos aplicados. Por fim, são abordadas as
considerações finais e trabalhos futuros decorrentes deste
estudo.
Módulo principal
Módulo
II. EXPERIÊNCIA DO USUÁRIO E MÉTODOS DE AVALIAÇÃO
Segundo Vermeeren et al. [6], como a experiência do
usuário é subjetiva, as métricas objetivas de usabilidade, tais
como o tempo de execução da tarefa e o número de cliques ou
erros não são medidas suficientes: precisamos saber como o
usuário se sente sobre o sistema. Neste sentido, diversos
métodos para avaliação da experiência do usuário têm sido
propostos com foco em diversos tipos de aplicações, tais como
aplicativos móveis, aplicações desktop, web services.
COMPONENTES DOS MÓDULOS DO GEQ.
Componente
Competência
Imersão sensorial
e imaginativa
Fluxo
Tensão
/
Aborrecimento
Desafio
Afeição negativa
Módulo Aspecto Social
Afeição positiva
Módulo pós game
Porém, em sua revisão da literatura sobre métodos de
avaliação da experiência do usuário, Vermeeren et al. [6] não
identificaram a categoria games nos tipos de aplicações para as
quais tem sido propostos métodos de avaliação da experiência
do usuário, o que pode ser um indício da necessidade de
métodos específicos para este tipo de aplicação. Para a
avaliação do serious game objeto deste estudo foram
selecionados dois métodos da avaliação da experiência do
usuário. O primeiro método é específico para jogos, mas não
especificamente para serious game – o Game Experience
Questionnarie [11]. O segundo método permite analisar
respostas emocionais dos usuários – As 10 heurísticas da
emoção [12]. Os dois métodos são apresentados a seguir.
A. Game Experience Questionnarie (GEQ)
O método Game Experience Questionnarie (GEQ) é um
questionário contendo afirmativas em relação à experiência do
usuário durante a interação com jogos digitais. O usuário
responde ao questionário assinalando o seu grau de
concordância em relação a como se sente sobre cada afirmativa
[13]. O grau de concordância foi definido segundo a escala de
Likert e é definido da seguinte forma: (0) De modo algum, (1)
Levemente, (2) Moderadamente, (3) Bastante e (4)
Extremamente.
Envolvimento
psicológico
–
empatia
Envolvimento
psicológico
sentimentos
negativos
Envolvimento
comportamental
Experiência
positiva
Experiência
negativa
Cansaço
Retorno
realidade
à
Descrição
Percepção do jogador sobre sua habilidade
e competência no jogo.
Avalia o quanto o jogador se sentiu no jogo
e se imaginou no jogo.
Percepção do jogador em relação ao curso
e enredo do jogo.
Avalia se o jogo causou tensão ou
aborrecimento no jogador.
Percepção do jogador em relação aos
desafios apresentados no jogo.
Avalia se o jogo causou antipatia no
jogador.
Avalia se o jogo causou simpatia no
jogador.
Avalia se o jogo leva os jogadores a
compartilharem sentimentos e afinidades
durante o jogo.
Avalia se o jogo promove a rivalidade
entre os jogadores.
Avalia se o jogo promove a participação
colaborativa
dos
jogadores
na
aprendizagem.
Avalia se o jogador obteve uma experiência
positiva durante o jogo.
Avalia se o jogador obteve uma experiência
negativa durante o jogo.
Avalia se o jogo causou cansaço no
jogador.
Avalia como o jogador se sentiu ao se
desconectar do jogo.
B. As 10 Heurísticas da Emoção
A emoção é um aspecto fundamental na experiência do
usuário, uma vez que permite compreender o nível de
engajamento e motivação do usuário durante a interação com
um produto [12]. Com base em teorias que relacionam reações
expressivas a diferentes emoções, Lera e Domingo [12]
propuseram as 10 heurísticas da emoção: (H1) Testa franzida,
(H2) Levantar as sobrancelhas, (H3) Olhar à distância, (H4)
Sorrir, (H5) Comprimir os lábios, (H6) Mexer a boca, (H7)
Expressão vocal, (H8) Mão tocando a face, (H9) Ir para trás na
cadeira, (H10) Inclinar para frente o tronco. A H4 é a única
heurística positiva e representa o objetivo que o design da
aplicação deseja alcançar. A TABELA II. apresenta uma breve
descrição de cada heurística proposta por Lera e Domingo.
O questionário é dividido em diferentes módulos: (1)
módulo principal, que aborda a experiência do usuário durante
o jogo e contém 33 afirmativas (2) módulo de aspecto social,
que aborda a experiência entre jogadores e contém 17
afirmativas e (3) módulo pós-game, que diz respeito à
experiência do usuário após o término do jogo e também possui
17 afirmativas [1]. Além desta divisão do questionário, o
método analisa a experiência do usuário através de diferentes
dimensões da experiência do jogador, conforme detalhado na
TABELA I. O questionário deve ser aplicado logo após o
término do jogo. O módulo principal pode, ainda, ser aplicado
após pausas durante o jogo e avaliar cada etapa da utilização.
Para a avaliação do uTest foram utilizados apenas os módulos
principal e pós game. O módulo principal foi utilizado uma
única vez, ao término do jogo. O módulo de aspecto social não
foi utilizado, pois o jogo não permite a interação entre
jogadores.
A análise do estado emocional dos usuários é realizada
através da observação de seus comportamentos. Esta
observação é feita com base em um vídeo com a captura da face
dos usuários durante a interação. A interação de um usuário será
considerada negativa se pelo menos cinco heurísticas negativas
forem identificadas durante a observação.
TABELA II.
DESCRIÇÃO DAS HEURÍSTICAS DA EMOÇÃO.
Heurística
(H1) Testa franzida
(H2) Levantar as sobrancelhas
23
Descrição
Pode ser um sinal da necessidade de
concentração, desgosto ou percepção de
falta de clareza.
Sinal de incerteza, descrença, espanto e
exasperação.
FEES
Heurística
(H3) Olhar à distância
(H4) Sorrir
(H5) Comprimir os lábios
(H6) Mexer a boca
(H7) Expressão vocal
(H8) Mão tocando a face
(H9) Ir para trás na cadeira
(H10) Inclinar para frente o
tronco
III.
do jogador no projeto sob o enredo do jogador “estar
procurando um projeto para trabalhar”. Após este cenário, a
próxima etapa esta relacionada a uma entrevista de emprego
que inicialmente o jogador deve realizar.
Descrição
Pode ser um sinal de decepção. Olhar para
baixo tende a transmitir uma atitude de
derrotado mas pode ser também culpa ou
vergonha.
Sinal de satisfação.
Pode ser percebido como um sinal de
frustração ou confusão.
Se o usuário é visto falando ou
gesticulando com si mesmo, é sinal de
estar perdido ou de incerteza.
Suspiros e tosses, bem como o volume, o
tom e a qualidade da expressão podem ser
sinais de frustração ou decepção.
Pode ser percebido como um sinal de
frustração ou confusão.
Ir para trás na cadeira pode estar
mostrando um desejo de fugir daquela
situação.
Pode ser um sinal de depressão ou
frustração. Mas ao contrário da heurística
anterior, o usuário não demonstra recusa,
pois inclinar-se para frente é um sinal de
chegar mais perto.
Para fazer parte da equipe de teste, o jogador deve responder
corretamente pelo menos três das cinco perguntas que o jogo
disponibiliza na primeira etapa como apresenta a Fig. 1. Ao
obter resultado positivo para os primeiros desafios, o jogador
recebe o feedback de sua aprovação na entrevista conforme a
Fig. 2. Caso o resultado seja negativo, ou seja, o jogador não
obteve a pontuação mínima, o jogo disponibiliza a opção para
tentar novamente ou procurar outro projeto.
AVALIAÇAO DA EXPERIÊNCIA DO USUÁRIO NO SERIOUS
GAME UTEST
Avaliar a experiência do usuário permite identificar as
percepções e reações de um usuário que resultam do uso ou do
uso previsto de um produto, sistema ou serviço. [14] Com o
intuito de analisar a experiência de alunos na interação com
serious game uTest em sala de aula, foi realizada uma avaliação
da experiência do usuário.
Fig. 2. Tela com feedback da aprovação do jogador.
Assumindo que o jogador obtenha o resultado positivo, o
mesmo é encaminhado para a segunda etapa, que inicia sob o
enredo do jogador “ser contratado para o projeto”. Os desafios
desta etapa estão relacionados ao artefato que o jogador
“recebe”, que contém informações para criar um teste unitário
no projeto. Os desafios são:
A. O serious game uTest
O serious game uTest proposto por Silva [2], utiliza
simulação através de cenários com o objetivo de apoiar o ensino
de teste de software, especificamente ao teste de unidade,
através de questões teóricas e práticas.
1. Classes de equivalência - Para este desafio, o jogador
deve selecionar as partições de equivalência com base na
descrição de um cenário.
2. Valor Limite - Com base na resposta informada pelo
desafio 1, o jogo solicita que o usuário informe os valores
limites para as classes identificadas.
3. Dados de Entrada - O jogo permite que o jogador indique
os dados de entrada com base nos desafios anteriores. O jogador
deve selecionar uma das partições ou valores limites
disponíveis no painel à esquerda, e então selecionar um valor
correspondente.
4. Grafo de Causa e Efeito ou Árvore de Decisão - Neste
desafio, o jogador seleciona e arrasta os objetos para montar o
grafo. Caso o objeto seja selecionado para o local correto, a
posição é alterada para a cor verde, caso contrário, é alterado
para a cor vermelha.
Fig. 1. Tela com a primeira etapa de desafios.
A tela inicial do jogo disponibiliza ao jogador três opções:
“visualizar instruções”, “informações sobre o jogo” e “jogar”.
Após a opção jogar ser selecionada, é exibida uma tela onde o
nome do usuário e senha devem ser inseridos. Caso seja a
primeira vez que o usuário utiliza seus dados de cadastro no
jogo, o jogador é encaminhado para uma tela para que o mesmo
escolha um personagem. O jogo apresenta duas etapas com
desafios. O cenário da primeira etapa do jogo introduz a seleção
Após a conclusão de todos os desafios no jogo, a tela de
encerramento e feedback do final do projeto é exibido para o
jogador, exibindo sua pontuação total através do cenário em que
o responsável pelo projeto o informa sobre seu desempenho. O
responsável neste cenário é o mesmo personagem que realizou
a entrevista do jogador no inicio como ilustra a Fig. 3. Após a
tela de encerramento ser exibida, o jogador é encaminhado a
tela de ranking, onde o resultado é confrontado com a
24
FEES
pontuação dos demais jogadores sob o cenário "Hall da Fama",
que exibe os melhores resultados e os nomes dos jogadores.
dados para posterior análise. Cada participante utilizou
individualmente o jogo em sala de aula através de notebooks
com o software Debut Video Capture instalado para possibilitar
a captura da face de cada participante durante a interação com
o jogo.
Como objetivos educacionais, o jogo proposto tem como
finalidade: reconhecer e entender os principais conceitos de
testes de software de maneira geral e entender e aplicar as
técnicas para a seleção de dados de entrada, tais como
particionamento em classes de equivalência, análise de valor
limite e grafo de causa e efeito [2].
Durante a interação com o jogo, os participantes não podiam
interagir uns com os outros. Após o fim do jogo, os
participantes recebiam os formulários do método GEQ para
preenchimento de acordo com o seu grau de concordância em
relação a cada afirmação do questionário.
C. Análise dos Resultados da Avaliação
Na análise dos resultados, primeiramente os dados obtidos
com o formulário do GEQ foram analisados quantitativamente
para obtenção de percentuais na escala do grau de concordância.
Para a análise quantitativa dos resultados, IJsselsteijn et al. [13]
definem uma divisão para cada módulo do questionário em
componentes. Cada componente possui afirmações do
questionário associadas, conforme detalhado a seguir em
relação ao módulo principal: Competência (2, 10, 15, 17 e 21),
Imersão sensorial e imaginativa (3, 12, 18, 19, 27 e 30), Fluxo
(5, 13, 25, 28 e 31), Tensão/Aborrecimento (22, 24 e 29),
Desafio (11, 23, 26, 32 e 33), Afeição negativa (7, 8, 9 e 16) e
Afeição positiva (1, 4, 6, 14 e 20).
Fig. 3. Tela de encerramento do jogo.
O uTest foi avaliado em relação aos efeitos de
aprendizagem de jogos educacionais aplicados ao ensino de
Engenharia de Software, através de experimentos que visavam
responder hipóteses levantadas para as perguntas [11]:
A TABELA III. apresenta os resultados obtidos para cada
afirmativa do módulo principal do GEQ separados por
componentes.
"A utilização do jogo proposto como apoio para o ensino de
teste de software permite uma melhor fixação e compreensão
dos conceitos abordados em aula?"
TABELA III.
RESULTADOS QUANTITATIVOS DO MÓDULO PRINCIPAL.
Componente Competência
"O jogo proposto permite, por parte do aluno, a aplicação
dos conceitos e técnicas de teste, possibilitando a criação de
um conhecimento do nível de aplicação?"
2. Eu me senti habilidoso
10. Eu me senti competente
15. Eu fui bem no jogo
17. Eu me senti bem sucedido
21. Eu atingi as metas do jogo de
forma rápida
Componente Imersão Sensorial e
Imaginativa
3. Eu estava interessado na história
do jogo
12. Foi esteticamente agradável
18. Eu me senti criativo
19. Eu senti que podia explorar
coisas
27. Eu achei impressionante
30. Pareceu uma rica experiência
"O jogo proposto é considerado uma atividade motivante?"
A análise dos experimentos confirmou que os objetivos
específicos planejados para o uTest foram alcançados. Porém,
com a avaliação proposta neste artigo pode-se verificar a
experiência do usuário em relação ao uTest.
B. Planejamento e Execução da Avaliação
Durante o planejamento, os formulários para avaliação do
uTest segundo o método GEQ foram elaborados, bem como o
Termo de Consentimento Livre e Esclarecido (TCLE). Como
mencionado anteriormente, apenas os módulos principal e pósgame foram aplicados. O módulo de aspecto social não foi
aplicado, pois o jogo não previa a interação entre jogadores.
Componente Fluxo
5. Eu estava completamente ocupado
com o jogo
13. Eu esqueci de tudo ao meu redor
25. Eu perdi a noção do tempo
28. Eu fiquei profundamente
concentrado no jogo
31. Eu me desconectei do mundo
exterior
Componente
Tensão/Aborrecimento
22. Eu me senti aborrecido
24. Eu me senti irritado
29. Eu me senti frustrado
Os participantes da avaliação foram 21 alunos do 6º período
do curso de Ciência da Computação da disciplina Engenharia
de Software. E, para apoio ao processo da avaliação, foram
selecionados 5 monitores que preparavam os notebooks para
iniciar a captura da face dos participantes e verificavam a
completude das respostas aos questionários.
Todos os alunos haviam assistido a aulas sobre teste de
software e técnicas para seleção de dados de entrada em testes
de unidade e assinaram devidamente o termo de consentimento,
onde concordavam em participar do estudo e disponibilizar seus
25
0
(%)
5
0
14
14
1
(%)
24
19
24
29
2
(%)
52
33
38
19
3
(%)
14
33
24
24
4
(%)
5
10
0
10
24
33
24
14
5
0
(%)
1
(%)
2
(%)
3
(%)
4
(%)
0
14
14
19
52
10
10
14
24
19
38
10
24
43
5
10
14
14
48
14
5
5
0
(%)
29
14
1
(%)
24
19
2
(%)
38
33
3
(%)
5
29
4
(%)
0
10
24
19
48
33
19
19
19
19
14
5
24
24
24
5
19
24
29
19
33
10
24
10
24
0
(%)
33
33
19
1
(%)
29
38
38
2
(%)
10
5
33
3
(%)
19
19
5
4
(%)
5
10
5
FEES
Componente Desafio
11. Eu achei o jogo difícil
23. Eu me senti pressionado
26. Eu me senti desafiado
32. Eu senti a pressão do tempo
33. Eu tive que me esforçar bastante
Componente Afeição Negativa
7. O jogo me deixou de mau humor
8. Eu pensei em outras coisas
durante o jogo
9. Eu achei o jogo cansativo
16. Eu me senti entediado
Componente Afeição Positiva
1. Eu me senti contente
4. Eu achei o jogo divertido
6. Eu me senti feliz
14. Eu me senti bem
20. Eu me diverti
0
(%)
5
48
0
33
0
0
(%)
38
1
(%)
29
19
5
19
24
1
(%)
24
2
(%)
19
14
14
24
24
2
(%)
14
3
(%)
38
14
33
19
24
3
(%)
5
4
(%)
10
5
48
5
29
4
(%)
14
38
19
24
14
5
33
29
0
(%)
19
5
10
10
19
24
43
1
(%)
5
5
24
14
19
19
24
2
(%)
33
19
29
38
10
14
0
3
(%)
43
38
19
19
29
TABELA IV.
RESULTADO QUANTITATIVOS DO MÓDULO PÓS GAME.
Componente Experiência Positiva
1. Eu me senti renovado.
5. Eu me senti vitorioso.
7. Eu me senti estimulado.
8. Eu me senti satisfeito.
12. Eu me senti poderoso.
15. Eu me senti orgulhoso.
Componente Experiência Negativa
2. Eu me senti mal.
4. Eu me senti culpado.
6. Eu achei um desperdício de
tempo.
11. Eu acho que poderia ter feito
coisas mais úteis.
14. Eu fiquei arrependido.
16. Eu fiquei envergonhado.
10
5
4
(%)
0
29
19
19
24
Componente Cansaço
10. Eu me senti exausto.
13. Eu me senti cansado.*
O módulo pós-game também possui afirmativas associadas
a cada um de seus componentes, da seguinte forma: Experiência
positiva (1, 5, 7, 8, 12 e 15), Experiência negativa (2, 4, 6, 11,
14 e 16), Cansaço (10 e 13) e Retorno à realidade (3, 9 e 17). A
TABELA IV. apresenta os resultados obtidos para cada
afirmativa do módulo principal do GEQ separados por
componentes.
Componente Retorno à Realidade
3. Eu achei difícil voltar à realidade.
9. Eu me senti desorientado.
17. Eu tive a sensação de ter
retornado de uma viagem.
0
(%)
24
24
5
14
33
24
0
(%)
62
76
1
(%)
19
10
10
19
29
10
1
(%)
19
10
2
(%)
33
29
33
19
19
24
2
(%)
10
0
3
(%)
14
19
24
29
14
24
3
(%)
5
14
4
(%)
10
19
29
19
0
14
4
(%)
5
0
67
24
5
5
0
29
24
5
19
19
57
38
0
(%)
33
0
(%)
85
43
14
19
1
(%)
33
1
(%)
5
33
14
19
2
(%)
10
2
(%)
10
10
5
10
3
(%)
19
3
(%)
0
10
5
10
4
(%)
5
4
(%)
0
5
57
19
5
10
5
*Durante a tradução do questionário, a afirmativa 13 não foi inserida
por uma falha na preparação do questionário.
Como forma de visualizar os resultados quantitativos de
forma mais adequada, optou-se por gerar gráficos de barras que
representassem a porcentagem de participantes que
selecionaram cada grau de concordância em cada afirmação do
questionário. O eixo X representa a escala do grau de
concordância para cada afirmativa. O eixo Y representa a
porcentagem de participantes que assinalaram o respectivo grau
de concordância para uma determinada afirmativa. As legendas
descrevem as afirmativas que compõem o componente em
análise.
A seguir são apresentados os gráficos de resultados para
alguns dos componentes do GEQ.A Fig. 4 ilustra os resultados
quantitativos obtidos para o componente do módulo principal –
Competência, que aborda como o participante avalia sua
habilidade e desempenho no jogo. É possível analisar que para
este componente como um todo, houve um menor percentual de
concordância em relação às afirmativas, pois as subescalas “De
modo algum” e “Levemente” obtiveram maior percentual de
respostas. Isto pode indicar a ocorrência de dificuldades durante
o jogo.
Fig. 4. Resultados quantitativos para o componente Competência.
A Fig. 5 ilustra os resultados quantitativos obtidos para o
componente do módulo principal – Imersão sensorial e
imaginativa, que investiga o quanto o jogador se imaginou no
jogo. Para este componente, houve um maior percentual de
concordância em relação às afirmativas, o que fornece indícios
de que a maioria dos participantes achou interessante a história
simulada no jogo e que o jogo permitiu ter uma experiência
criativa e agradável no aprendizado de teste de software.
26
FEES
Fig. 5. Resultados quantitativos para o componente Imersão Sensorial e Imaginativa.
Na Fig. 6 são apresentados os resultados quantitativos
obtidos para o componente do módulo principal – Tensão /
Aborrecimento, que avalia se o jogo causou tensão ou
aborrecimento no jogador. Em relação a este componente, a
maioria das respostas foi para as subescalas de discordância.
Isto ilustra um resultado positivo, indicando que o jogo pode ter
provocado tensão ou aborrecimento em poucos participantes.
Fig. 6. Resultados quantitativos para o componente Tensão / Aborrecimento.
A Fig. 7 apresenta os resultados quantitativos obtidos para
o componente do módulo principal – Desafio, que identifica a
percepção do jogador em relação aos desafios apresentados
durante o jogo. Foi obtido um maior índice de concordância às
afirmativas relacionadas à dificuldade e esforço exigido pelo
jogo (itens 11, 26 e 33), indicando que o jogo foi desafiador e
exigiu esforço dos participantes para alcançar as metas. Porém,
a maioria dos participantes discordou das afirmativas
relacionadas à pressão que o jogo causou sobre eles (itens 23 e
32), indicando que não se sentiram pressionados durante o jogo.
27
FEES
Fig. 7. Resultados quantitativos para o componente Desafio.
componente do módulo principal – Afeição negativa, que avalia
se o jogo causou antipatia nos jogadores. Este componente
obteve maior discordância em relação às afirmativas, indicando
que o jogo não causou um nível significativo de tédio, cansaço
e mau humor nos participantes.
Fig. 8. Resultados quantitativos para o componente Afeição Negativa.
componente do módulo principal – Fluxo, que avalia a
percepção do jogador em relação ao enredo do jogo. Houve
pouca diferença em relação à concordância e à discordância dos
participantes em relação aos itens de "Eu me desconectei do
mundo exterior" e "Eu fiquei profundamente concentrado no
jogo", isto indica que a imersão dos participantes no enredo do
jogo pode ser considerada como média.
Fig. 9. Resultados quantitativos para o componente Fluxo
28
FEES
componente do módulo pós game - Experiência Negativa. A
maioria das respostas representou discordância sobre a
ocorrência de experiências negativas durante o jogo. O que
demonstra um resultado positivo para o uTest, indicando que o
jogo causou o mínimo de mal-estar, culpa, vergonha ou
arrependimento durante o jogo.
Fig. 10. Resultados quantitativos para o componente Experiência Negativa.
componente do módulo pós-game – Retorno à realidade, que
aborda como o jogador se sentiu ao se desconectar do jogo. A
maioria das respostas representou discordância sobre a
dificuldade de retornar à realidade após o jogo. Isto pode ter
sido influenciado pelo fato de que o jogo foi aplicado em uma
turma do turno noturno e ainda no último horário de aula. Nesta
turma, a maioria dos alunos trabalha durante o dia e à noite já
estão bem cansados.
Fig. 11. Resultados quantitativos para o componente Retorno à Realidade.
Uma maior investigação sobre os resultados negativos
poderia auxiliar em futuras melhorias para o jogo, porém o
método GEQ não possibilita este detalhamento, uma vez que
não aborda a coleta de dados qualitativos.
fortes PFT03, PFT08 e PFT09 relacionados ao componente
Competência, pois abordam aspectos que afetam a habilidade
do participante no jogo.
TABELA V.
Para melhor compreensão dos resultados, foram
adicionadas aos questionários duas perguntas exploratórias que
solicitava ao jogador que descrevesse três pontos positivos e
três pontos negativos no uTest. Como as respostas foram
pontuais, foram elaboradas tabelas para a apresentação dos
pontos fortes (PFT) e pontos fracos (PFC) do uTest do ponto de
vista dos participantes. A TABELA V. descreve os pontos
fortes citados pelos participantes e a TABELA VI. lista os
pontos negativos.
PONTOS FORTES DO JOGO DO PONTO DE VISTA DOS
PARTICIPANTES.
Ponto Forte
PFT01
PFT02
PFT03
PFT04
PFT05
PFT06
PFT07
PFT08
PFT09
PFT10
Analisando a TABELA V. e relacionando os pontos a
alguns componentes do GEQ, é possível identificar os pontos
29
Descrição
A abordagem contextual do jogo é interessante.
O jogo é criativo.
Motivação, pois dava explicações quando o jogador
comete um erro.
O jogo é bastante interativo.
A forma de tratar a disciplina é interessante.
O jogo é bem animado.
O jogo prende a atenção do jogador.
O jogo estimula o conhecimento do jogador.
O jogo é de fácil entendimento.
O hall da fama é um recurso bem interessante.
FEES
PFT11
PFT12
O jogo não é entediante, dá vontade de ser aprofundar
mais no jogo.
Os desafios do jogo são bem elaborados.
desafio, sem sucesso. O ponto PFC05 não pôde ser associado a
nenhum componente.
Os itens PFT01, PFT02, PFT05 e PFT07 podem ser
relacionados ao componente Imersão Sensorial e Imaginativa,
uma vez que descrevem fatores relacionados à criatividade e
interesse do participante no enredo do jogo.
De posse do vídeo com a captura da face dos participantes
durante a interação, as ocorrências das heurísticas da emoção
foram identificadas. Vale ressaltar que um vídeo foi descartado
devido a uma falha na captura da interação. A TABELA VII.
apresenta a análise quantitativa em relação à ocorrência das
heurísticas.
Já o item PFT04 está relacionado ao componente Fluxo,
pois é um aspecto que afeta positivamente a concentração do
aluno no jogo. Ao componente Desafio, estão relacionados os
pontos PFT10, pois o hall da fama é visto como um desafio do
jogo, já que apenas são exibidos os nomes dos jogadores com
maior pontuação e PFT12, que menciona diretamente a
qualidade dos desafios do jogo.
TABELA VII. ANÁLISE DA OCORRÊNCIA DAS HEURÍSTICAS DA EMOÇÃO.
Heurística
H1. Testa franzida
H2. Levantar as sobrancelhas
H3. Olhar à distância
H4. Sorrir
H5. Comprimir os lábios
H6. Mexer a boca
H7. Expressão vocal
H8. Mão tocando a face
H9. Ir para trás na cadeira
H10. Inclinar para frente o tronco
O ponto PFT06 diz respeito ao componente Afeição
positiva, pois permite que o jogador se divirta durante o jogo.
E, por fim, os pontos PFT08 e PFT11, são relacionados,
respectivamente, aos componentes Experiência positiva e
Experiência negativa. O ponto PFT08 possibilita que o jogador
se sinta estimulado durante o jogo. E o ponto PFT11 impede
que o jogador se sinta entediado.
TABELA VI.
De acordo com Lera e Domingo [12], a interação será
considerada negativa se pelo menos cinco heurísticas negativas
forem identificadas. Caso contrário, a experiência é considerada
positiva. Assim, a TABELA VIII. apresenta o resultado geral
obtido com base nesta análise. Observa-se que 27% dos
participantes apresentam experiência positiva com o serious
game, devido à quantidade de heurísticas negativas observadas
por tais participantes serem menores que cinco.
PONTOS FRACOS DO JOGO DO PONTO DE VISTA DOS
PARTICIPANTES.
Ponto Fraco
PFC01
PFC02
PFC03
PFC04
PFC05
PFC06
PFC07
PFC08
PFC09
PFC10
PFC11
PFC12
PFC13
PFC14
Número de participantes
11
10
9
3
11
11
12
16
14
16
Descrição
As dicas do jogo poderiam ser mais explicadas.
As perguntas do jogo são complexas.
O jogo é cansativo.
O jogo é difícil.
O jogo precisa de conexão com a internet.
O jogo poderia ter mais opções de perguntas.
O jogo possui poucos artefatos a serem analisados.
A quantidade de chances para acertar uma questão é
ilimitada.
O jogo poderia apresentar um resultado final para o
jogador, mostrando seus pontos fracos no jogo.
A forma de obtenção da pontuação do jogo não está clara.
As perguntas não estavam bem explicadas.
Algumas telas do jogo eram muito coloridas.
O jogo poderia ser mais divertido.
O jogo apresentava muitas telas com texto.
TABELA VIII. RESULTADO GERAL DO MÉTODO HEURÍSTICAS DA EMOÇÃO.
Experiência Positiva
27%
Experiência
Negativa
73%
Avaliação Final
Negativa
A avaliação final do jogo uTest segundo as 10 heurísticas
da emoção foi considerada negativa, pois a maioria dos
participantes apresentou uma experiência negativa. De maneira
similar ao método GEQ, as heurísticas da emoção não
disponibilizam práticas para avaliar os sinais da emoção de
maneira qualitativa, para uma melhor compreensão dos
resultados, podendo fornecer apenas uma avaliação geral da
experiência emocional.
Relacionando os pontos da TABELA VI. aos componentes
do GEQ, temos que os pontos PFC01, PFC02 e PFC09 estão
relacionados à Competência, pois afetam negativamente o
desempenho do jogador. Já o ponto PFC03 está relacionado ao
Cansaço, pois permite que o jogador fique cansado durante o
jogo.
Após a utilização do serious game, foi realizado um debate
entre os participantes e a professora que aplicou o uTest. Os
alunos comentaram que este jogo não auxilia tanto no
aprendizado inicial de teste, mas sim na avaliação deste
aprendizado. Isto se deve ao fato de que, em alguns desafios do
jogo, as dicas não são suficientes para que um aluno que não
domina o assunto consiga resolver o desafio, como ocorre em
outros jogos.
Em relação ao Desafio, temos os pontos PFC04 e PFC11,
que fazem com que o jogador ache o jogo difícil. Ao
componente Imersão sensorial e imaginativa podemos
relacionar os pontos PFC06, PFC12 e PFC14. Os pontos PFC12
e PCF14 afetam a experiência estética agradável. O item
PFC06, por sua vez, afeta negativamente o fato de o jogador
sentir que pode explorar coisas no jogo, já que as questões são
limitadas.
Assim, este jogo pode fornecer uma experiência mais
positiva quando os alunos já aprenderam e aplicaram as técnicas
para seleção de testes unitários em outro contexto. O jogo seria
uma ferramenta para avaliação do aprendizado dos alunos neste
tema.
Os pontos PFC07, PFC10 e PFC13 estão relacionados à
Experiência positiva, pois influenciam a satisfação e estímulo
do jogador durante o jogo. Por fim, o ponto PFC08 pode ser
associado à Afeição negativa, pois pode tornar o jogo
entediante quando o jogador tenta várias vezes resolver um
IV.
DISCUSSÃO
O objetivo deste artigo não consiste em apenas apresentar
os resultados de uma avaliação, mas também apresentar a
30
FEES
variedade de perspectivas relacionadas à experiência do usuário
a serem exploradas em serious game. Apesar de os métodos
adotados não serem específicos para serious game, o GEQ em
especial, forneceu resultados interessantes em relação à
experiência do usuário durante o jogo, permitindo a análise de
diversos aspectos como competência, imersão, desafio,
cansaço, entre outros. Ainda em relação aos métodos de
avaliação adotados, alguns aspectos podem ser destacados.
Agradecimentos
As autoras agradecem o apoio financeiro da FAPEAM
através do Edital N° 016/2013 PROTI – PESQUISA, processo
No 062.00578/2014. As autoras também agradecem a Antônio
Carlos Silva e ao Prof. Marcello Thiry da Costa por
disponibilizarem o serious game uTest.
Referências
Em relação aos resultados obtidos através do GEQ, um
ponto fraco do método foi o fato de se concentrar apenas em
dados quantitativos, pois quando se opta por realizar uma
avaliação da experiência do usuário em uma aplicação, o
objetivo é não só avaliar se a aplicação apresenta uma boa ou
má experiência, como também identificar possíveis melhorias
na aplicação. Em contrapartida, um ponto forte do método é a
facilidade da coleta de dados e a divisão da análise em
dimensões, o que facilita a organização dos resultados.
[1]
[2]
[3]
[4]
Um ponto importante em relação às 10 heurísticas da
emoção é o fato de que 5 heurísticas são o suficiente para
considerar uma experiência negativa. Porém, em um serious
game algumas heurísticas podem ocorrer não pelo fato de o
usuário estar experimentando uma má experiência e sim, pelo
fato de estar concentrado e empenhado no jogo. Outro ponto é
o fato de que mesmo que um usuário não apresente a única
heurística positiva – H4, sua experiência pode ser considerada
positiva pelo próprio usuário.
V.
[5]
[6]
[7]
CONCLUSÕES E TRABALHOS FUTUROS
[8]
Os resultados obtidos mostram principalmente dois pontos
principais: (1) a necessidade de analisar a validade dos
resultados da experiência do usuário para o contexto de serious
game, e (2) a necessidade de complementar os resultados
através de dados qualitativos. Em relação ao GEQ, uma
proposta de melhoria poderia ser a aplicação de entrevistas após
o preenchimento dos formulários para investigar resultados
negativos assinalados no questionário pelos usuários. Desta
forma, seria possível identificar as causas das experiências
negativas durante a interação e sugestões de melhorias advindas
dos próprios usuários. Como trabalho futuro, pretende-se
realizar avaliações qualitativas para outros serious game
voltados para o ensino de tópicos em Engenharia de Software,
com o objetivo de compreender os dados quantitativos das
questões de pesquisa do método GEQ.
[9]
[10]
[11]
[12]
[13]
Já na perspectiva da análise das emoções de usuários
durante a interação com serious game, uma investigação mais
aprofundada deve ser conduzida de forma a verificar a
necessidade de adotar uma perspectiva distinta de avaliação
para este tipo de aplicação. Os resultados deste estudo
permitiram identificar a necessidade da elaboração de métodos
de avaliação da experiência do usuário voltados aos serious
games ou a necessidade de adequação de métodos existentes,
como os métodos aplicados neste estudo. Espera-se com estes
resultados contribuir para a melhoria da experiência do usuário
neste tipo de aplicação que tem sido amplamente adotada em
diversas disciplinas.
[14]
[15]
31
Thiry, M., Zoucas, A., Gonçalves, R., Salviano, C. “Aplicação de Jogos
Educativos para Aprendizagem em Melhoria de Processo e Engenharia de
Software”, In: Anais do VI Workshop Anual do MPS, 2010.
Silva, A. C. (2010). “Jogo Educacional para Apoiar o Ensino de Técnicas
para Elaboração de Testes de Unidade”. Dissertação de Curso de
Mestrado, Computação Aplicada, UNIVALI, São José.
Ritterfeld, U., Cody, M., and Vorderer, P. Serious Games: Mechanisms
and Effects. Routledge, London, 2009.
Zyda, M. From Visual Simulation to Virtual Reality to Games. Computer,
38 (9), 25-32.
Vargas, J.A., García-Mundo, L., Genero, M. e Piattini, M. A Systematic
Mapping Study on Serious Game Quality. In Proc. of 18th International
Conference on Evaluation and Assessment in Software Engineering.
(2014), 159-168
Vermeeren, A.P.O.S., Law, E.L.C., Roto, V., Obrist, M., Hoonhout, J. and
Mattila, K.V.V.User Experience Evaluation Methods: Current State and
Development Needs. In Proc. NordiCHi 2010, 521-530.
Savi, R.; Wangenheim, C., Borgatto, A., (2011). “Um Modelo de
Avaliação de Jogos Educacionais na Engenharia de Software”. Anais do
XXV Simpósio Brasileiro de Engenharia de Software (SBES 2011), São
Paulo.
Gámez, E. H. C. "On the Core Elements of the Experience of Playing
Video Games", Tese de doutorado - UCL Interaction Centre Department
of Computer Science, 2009.
Jennett, C., Cox, A. L., Cairns, P., Dhoparee, S., Epps, A., Tijs, T.,
Walton, A. "Measuring and defining the experience of immersion in
games", International Journal of Human-Computer Studies, v. 66, n. 9,
2008, p. 641-661.
Poels, K., Kort, Y. D., Ijsselsteijn, W. ""It is always a lot of fun!":
exploring dimensions of digital game experience using focus group
methodology", In: Proceedings of the 2007 Conference on Future Play.
Toronto, Canada: ACM, 2007.p.83-89.
IJsselsteijn, W.A., de Kort, Y.A.W. & Poels, K. Game Experience
Questionnaire - The English version.
Lera, E. e Domingo M. G. (2007) “Ten emotion heuristics: Guidelines for
assessing the user’s affective dimension easily and cost-effectively”, In
proc. of BCS-HCI ‘07, 163-166.
Ijsselsteijn, W., van der Hoogen, W., Klimmt, C., de Kort, Y., Lindley,
C., Mathiak, K. Poels, K., Ravaja, N., Turpeinen, M. & Vorderer,
P.(2008). Measuring the experience of digital game enjoyment. In A.J.
Spink, M.R. Ballintijn, N.D. Bogers, F. Grieco, L.W.S. Loijens, L.P.J.J.
Noldus, G. Smit, and P.H. Zimmerman (Eds.), Proc. of Measuring
Behavior 2008, 88-89.
Law, E.L-C., Roto, V., Hassenzahl, M., Vermeeren, A.P.O.S. and Kort. J.
Understanding, scoping and defining user experience: a survey approach.
In Proc. of the SIGCHI Conference on Human Factors in Computing
Systems (CHI '09), 2009, 719-728
Fu, F., Su, R., Yu, S. "EGameFlow: A scale to measure learners'
enjoyment of e-learning games", Computers & Education, v. 52, n. 1,
2009, p. 101-112..
FEES
Gamebok: jogo educativo para o ensinoaprendizagem do pmbok 5ª edição
Marcos Paulo Correia Azevedo
Fabrício de Sousa Pinto
Colegiado de Sistemas de Informação
Faculdade de Tecnologia e Ciências (FTC)
Vitória da Conquista-BA, Brasil
[email protected]
Colegiado de Sistemas de Informação
Faculdade de Tecnologia e Ciências (FTC)
Vitória da Conquista-BA, Brasil
[email protected]
aprendendo mais nada [1]. Ainda defende que aulas expositivas
infelizmente não estimulam um aprendizado profundo, apenas
algo superficial e que não motiva o estudante a aprender. Para
contornar isso e levar o estudante a exercitar a aplicação do
conhecimento é necessário buscar outras maneiras de ensino.
Resumo— Os jogos educativo tem se tornado uma excelente
ferramenta de trabalho e veem sendo utilizados nas mais diversas
áreas de ensino buscando dinamizar o aprendizado. Em gestão de
Projetos essa prática é pouco valorizada, pois se trata de uma área
ampla, com vasto conhecimento teórico, o que dá margem para que
o aprendizado se torne deficiente e desmotivador para alguns
estudantes. Para contornar os problemas citados, este artigo propôs
o desenvolvimento do jogo educacional GameBOK para auxiliar no
ensino-aprendizagem dos conteúdos de gestão de projetos de
software utilizando o guia PMBOK 5ª Edição. O jogo foi
desenvolvido nas linguagens HTML, JavaScript e PHP.
Questionários foram aplicados aos estudantes da disciplina
Engenharia de Software após aplicação do jogo, os dados foram
analisados e os resultados mostraram-se satisfatórios.
Levando em consideração os estudantes da geração
atual que interagem muito e esperam um retorno imediato. Fazse necessário que o professor busque recursos educacionais
mais atraentes, e motivadores, como o jogo educacional.
Assim, a utilização dos jogos nas salas de aula poderá se tornar
um elemento capaz de aumentar o interesse dos discentes, o
que por sua vez, aumentará o nível de aprendizagem.
Em relação a gestão de projetos tem-se observado
uma carência de jogos que auxilie os discentes e docentes nesta
área, principalmente quando se trata no ensino de boas práticas
de gerenciamento de projetos. O PMI (Project Management
Institute) conseguiu compilar estas boas práticas, sendo
aplicadas em projetos de tamanhos e áreas diferentes e montou
uma publicação, o PMBOK (Project Management Body of
Knowledge). Segundo o guia PMBOK [2], este contém
inúmeros processos de trabalho, cada um com conjunto de
técnicas e ferramentas para serem usadas ao longo de seus
cinco grupos de processos, totalizando dez áreas de
conhecimento.
Palavras-chave— pmbok; gestão de projetos; jogos educativos;
engenharia de software
Abstract—The educational games has become an excellent working
tool and see being used in several areas of education seeking to
boost learning. Project management practice that is undervalued
because it is a large area with vast theoretical knowledge, which
gives rise to that learning becomes deficient and demotivating for
some students. To circumvent the above problems, this paper
proposes the development of educational game GameBOK to assist
in the teaching and learning of content management software
projects using the PMBOK Guide 5th Edition. The game was
developed in HTML, JavaScript, and PHP. Questionnaires to
students in the discipline of Software Engineering were applied
after the game application, the data were analyzed and the results
were satisfactory.
Motivado em criar um jogo que possam contribuir
com os estudantes e professores, dando a eles uma forma
alternativa de facilitar o processo ensino-aprendizagem o
GameBOK foi desenvolvido utilizando uma estrutura de
organização hierárquica de objetivos educacionais, baseando-se
na taxonomia de Bloom. Neste o jogador assume o papel do
personagem e vai se envolvendo no enredo de acordo com
algumas regras predeterminadas, onde o jogador irá aprender
boas práticas de gerenciamento de projetos de software,
utilizando-se do PMBOK 5ª.
Keywords —pmbok; project management; educational games;
software engineering
I INTRODUÇÃO
No contexto atual de ensino é possível notar o frequente
uso de aulas expositivas pelos docentes em ambientes
educacionais. Este tipo é adequado para a apresentação de
conhecimentos teóricos de forma eficiente para turmas grandes,
porém possui diversas desvantagens. É comum que em aulas
expositivas os estudantes percam a concentração depois de dez
a quinze minutos, iniciando conversas com colegas, mandando
mensagens no telefone ou simplesmente adormecem, não
Este artigo está organizado da seguinte forma: Esta
seção apresenta uma visão geral do que foi abordado no
trabalho desenvolvido, fornecendo alguns conceitos principais
e o objetivo do trabalho. Na seção 2 e 3 é feita uma revisão
bibliográfica, onde são apresentados os conceitos de PMBOK e
Jogos Educacionais. A seção 4 a metodologia. Na seção 5
mostra o processo de desenvolvimento do jogo GameBOK. Já
32
FEES
na seção 6 é apresentado os trabalhos relacionados. Por fim, na
seção 7 as considerações finais.
Todo projeto possui uma margem de riscos e nessa
área é possível planejar o gerenciamento de riscos, o que é
muito vantajoso já que é possível identificar e realizar análises
qualitativas e quantitativas, assim como planejar respostas e o
monitoramento e controle para estes riscos [2].
II PMBOK
O gerenciamento de aquisições do projeto é
considerado, por algumas pessoas, como uma das etapas mais
críticas do projeto, pois nela estão envolvidos os processos
envolvidos na aquisição de produtos, serviços e resultados para
o projeto. Nesse quesito pode-se, planejar, conduzir e
administrar as aquisições [2].
O PMBOK é um modelo na área de Gestão de Projeto,
onde o mesmo descreve as áreas de conhecimento, listagens de
processos e define as entradas, ferramentas, técnicas e as saídas
de cada área. Ele era concentrado em nove áreas de
conhecimento, sendo elas: Gerenciamento de integração,
Escopo, Tempo, Custo, Qualidade, Recursos humanos,
Comunicação, Riscos, Aquisições e a sua mais nova área
Stakeholders (Parte Interessadas) que foi incluída no PMBOK
5ª Edição, totalizando dez áreas. Iremos comentar de forma
resumida, cada área a seguir.
A área de conhecimento stakeholders (partes
interessadas), só aparece na quinta edição do PMBOK, pois até
então o gerenciamento da mesma fazia parte de dois processos
da área de conhecimento de gerenciamento das comunicações
(identificar as partes interessadas e gerenciar as expectativas
das partes interessadas). Agora são documentados quatro
processos para o gerenciamento das partes interessadas:
Identificar as partes interessadas, planejar o gerenciamento das
partes interessadas, gerenciar o engajamento das partes
interessadas e controlar o engajamento das partes interessadas
[2].
No gerenciamento de escopo do projeto são descritos
os processos relativos à garantia de inclusão de todo o trabalho
necessário, para o projeto que seja concluído com sucesso,
abordando categorias como a coleta de requisitos, definição do
escopo, criação da Estrutura Analítica do Projeto (EAP),
verificação e controle do escopo [2].
No que se diz respeito ao Gerenciamento do Tempo
do Projeto, tem-se que abordar os processos relativos ao
término do projeto no prazo correto, tais como a definição de
atividades, sequências, duração de atividades, desenvolvimento
e controle do cronograma [2].
III JOGOS EDUCACIONAIS
Segundo [3], os jogos fazem parte da nossa vida desde os
tempos antigos, não só na nossa infância como também em
outros momentos. São capazes de serem ferramentas
instrucionais eficientes, pois motivam enquanto proporcionam
diversão e ainda facilitam o aprendizado aumentando a
capacidade de absorção do que foi ensinado, exercitando o
intelecto e as funções mentais do jogador. Ao jogar, os
participantes entram em um mundo de faz de conta onde é
possível dispor-se às incertezas e enfrentar desafios em busca
de soluções e entretimento. As pessoas quando jogam são
capazes de revelar autonomia, criatividade e vontade de
experimentar situações perigosas e proibidas no nosso
cotidiano, fazendo com que elas tomem decisões mais
calculadas a partir dos seus erros.
Em relação ao gerenciamento de custos do projeto são
descritos os processos envolvidos no planejamento, a
estimativa, a determinação do orçamento e o controle de
custos. Isso possibilita que o projeto termine dentro do
orçamento aprovado. Neste ponto busca-se estimar custos,
determinar o orçamento e realizar o controle dos custos do
projeto [2].
O gerenciamento de qualidade do projeto corresponde
aos processos envolvidos no planejamento, monitoramento,
controle e na garantia de que o projeto irá satisfazer os
requisitos de qualidade especificados. Nessa etapa é possível
planejar a qualidade do projeto, realizar a garantia de qualidade
e o controle do mesmo [2].
Partindo da ideia atribuída por [3] os jogos são
baseados em uma abordagem autodirigida, onde o jogador é
capaz de aprender por si só, através da interação e relação com
o jogo. Nesse cenário o professor passa a ter o papel de
mediador do processo, dando orientações e selecionando os
jogos adequados a sua prática pedagógica, proporcionando que
o estudante aprenda de forma dinâmica e motivadora.
Por meio da avaliação dos processos envolvidos no
planejamento,
na
contratação
e
mobilização,
no
desenvolvimento e no gerenciamento do projeto, ocorre o
gerenciamento dos recursos humanos, onde é possível
desenvolver esse plano de recursos humanos, realizar a
contratação ou mobilização da equipe de projetos, buscar o
desenvolvimento e gerenciamento da equipe do projeto [2].
Quando se fala sobre o enredo, torna-se interessante
mencionar que ele é o elemento responsável por manter o
jogador entusiasmado no decorrer do jogo. Dessa forma, podese dizer que o enredo é o esqueleto da narrativa, ou seja, aquilo
que dá sustentação à história, onde todos os fatos e
acontecimentos são desenrolados.
Ressalta-se que o gerenciamento das comunicações é
outro fator importante a ser considerado, tendo em vista que ele
é o responsável por buscar identificar os processos relativos à
geração, coleta, disseminação, armazenamento e destinação
final das informações do projeto de forma oportuna e
apropriada. Dessa forma, essa área pode planejar o
gerenciamento das comunicação, gerenciar as comunicações e,
por fim, controlar as comunicações [2].
Na Figura 01 são mostrados os elementos separados
de acordo [2]. São eles: Objetivos: usuário busca vencer, ser o
melhor entre os competidores, alcançar um maior nível de
aprendizagem; Regras e Restrições: regras para definir o que
pode ou não ser feito pelo jogador e restrições que podem ser
33
FEES
ganhadas ou perdidas (exemplo: dinheiro); Narrativa:
Responsável por motivar as ações dos jogadores dando um
pouco de ficção, porém também existem jogos que não
possuem nenhum tipo de narrativa. Resultados, recompensas e
feedback: Responsável por indicar ao jogador/competidor suas
proezas no jogo tais como acertos e erros; Desafio, competição
e conflito: Faz com que o jogo não se torne monótono, levando
ao usuário o espirito de competição dando a ele mais um
elemento motivador; Interação: Considerado o elemento mais
importante do jogo.
IV METODOLOGIA
O GameBOK foi desenvolvido utilizando HTML
(HiperText Markup Language), PHP (Hypertext Preprocessor),
Banco de dados MySQL, CSS (Cascading Style Sheets) e
JavaScript. A linguagem de marcação HTML foi escolhida
pelo motivo de rodar em qualquer dispositivo que tenha um
navegador web. A linguagens de programação PHP foi
utilizada para manter a conexão com o banco de dados MySQL
gravando o desempenho do jogador de forma que possa ser
recuperada no ranking do jogo. Todos os outros eventos do
jogo como arrastar ícones, selecionar e verificar respostas
foram feitas pela linguagem de programação JavaScript. Toda
a etapa de estilização do jogo foi feita através do CSS.
Foi utilizado o Sublime Text, editor de texto com
gratuito, para a construção dos arquivos .php, .js e .css.
Para edição e criação das imagens exibidas do jogo foi
utilizada a ferramenta Adobe Photoshop CC em sua versão
licenciada.
Para realizar os testes do jogo, rotinas PHP e
JavaScript foram realizadas buscando encontrar falhas.
Também foi realizado testes manuais, visando rotinas
improváveis dos usuários.
V DESENVOLVIMENTO DO JOGO GAMEBOK
Figura 01: Principais elementos de um jogo
Nesta seção serão abordados todos os processos envolvidos
no desenvolvimento do jogo proposto, apresentando os
resultados obtidos. Como todo jogo, um nome foi escolhido
GameBOK, resultado da junção da palavra Game, com a sigla
do PMBOK, tendo alterações nas iniciais PM, substituindo-as
por Game, dando ao usuário um rápido entendimento do que se
trata o jogo.
Fonte: [1]
Uma das formas de avaliar um jogo educacional é
utilizando a Taxonomia de Bloom. Porém existe a Taxonomia
Revisada de Bloom [4] que é uma versão atualizada da mesma
feita por Dr. Lorin Anderson, em 2001. Esta possui seis
capacitações, conforme ilustrado na Figura 02.
O GameBOK foi desenvolvido para se tornar um
projeto Open Source. Os arquivos desse projeto encontram-se
disponível em um servidor público que pode ser acessado
através
do
link
disponível
em:
http://sourceforge.net/projects/gamebok/ .
A versão final do jogo também pode ser acessada de
forma livre através do link: http://itaz.com.br/gamebok.
O jogo narra uma adaptação da série de TV Prison
Break, criada por Paul T. Scheuring, onde o personagem
Michael Scofield, um jovem de classe média americana, que
descobre que seu irmão foi preso depois de assassinar um
deputado importante nos Estados Unidos. Acreditando na
inocência do irmão, Michael utiliza as boas práticas de
gerenciamento de projeto do PMBOK afim de consegui tirar
Lincoln do presídio.
Este jogo tem como público-alvo estudantes,
professores e pessoas interessadas em reforçar os estudos sobre
o PMBOK.
Figura 02: Taxonomia revisada de Bloom
Fonte: adaptado de [4]
Para que possa jogar o estudante deverá ter o
conhecimento básico sobre gestão de projeto, conhecer os
ciclos de vida de um projeto, conceitos básicos sobre o
34
FEES
PMBOK, tais como os grupos de processos e áreas de
conhecimento.
Este jogo possui o objetivo de reforçar os estudos
sobre o PMBOK visto em sala de aula e mostrar um exemplo
prático de sua aplicação. Contudo ele também busca apresentar
aos estudantes outras formas de aplicar o gerenciamento de
projetos, mostrando a eficácia de se fazer um bom
planejamento antes de iniciar qualquer atividade.
O GameBOK é um jogo single-play, onde o jogador
assume o papel de Michael Scoofield, um engenheiro civil que
ao descobrir que seu irmão foi preso por um crime que não
cometeu, faz de tudo para tirá-lo do presídio. Michael terá que
solucionar os desafios propostos para que possa progredir no
jogo. Na Figura 03 temos a tela inicial do jogo.
Figura 04: Análise de risco
Figura 03: Tela inicial do jogo
Entender: elemento capaz de fazer com que o jogador
busque fazer sua própria interpretação do material educacional.
Com o enredo semelhante a uma situação real onde o jogador
inicia, planeja, executa, monitora e finaliza o projeto. O
jogador visualiza no enredo os ensinamentos aplicados,
fazendo com que o mesmo vá compreendendo o que se passa
em cada fase. Na Figura 05, por exemplo, o jogador tem acesso
ao cronograma com a sequência de atividades que serão feitas.
Na tela seguinte, o jogador irá entender em qual área do
PMBOK está sendo aplicada e quais processos foram
atendidos, Figuras 05 e 06.
O GameBOK foi desenvolvido para corresponder ao
ciclo de vida de um projeto, tendo início, meio e fim. Para
facilitar o aprendizado dos jogadores, o jogo foi dividido em
três fases, onde ambas aplicam as áreas de conhecimento de
projeto do PMBOK 5ª Edição, são elas: Tatuar o corpo (1ª
Fase): O personagem Michael deverá tatuar de forma
camuflada a planta do presídio em seu corpo; Assaltar banco
(2ª Fase): Michael planeja o assalto de um banco, criando uma
emboscada para si mesmo para que possa ser preso; Fugir do
presídio (3ª Fase): Com um plano de fuga planejado
anteriormente à prisão, Michael juntamente com seu irmão
busca fugir do presídio.
Figura 05: Planejamento
Pensando em se tornar um jogo agradável e motivador
aos usuários, este utiliza quatro capacitações da Taxonomia de
Bloom [4]: Lembrar, entender, aplicar e analisar. Distrações e
desafios foram adicionadas ao jogo evitando que o mesmo se
torne monótono. A seguir será comentado cada elemento da
Taxonomia de Bloom.
Analisar: o jogador passa a dividir o conhecimento em
partes e pensar como estas podem se relacionar com o todo.
Na Figura 04, o jogador terá que fazer a gestão de riscos,
através da análise de risco qualitativa e quantitativa.
Figura 06: Aprendizado do jogador, através dos processos do PMBOK.
35
FEES
O jogador buscar reconhecer e recordar informações.
Ele terá que lembrar dos conceitos básico do PMBOK, como
por exemplo, os grupos de processo do ciclo de vida de um
projeto, conforme ilustrado na Figura 07. Assim como
responder corretamente algumas questões de desafios.
Figura 09: Desafio de quebrar a parede
Figura 07: Lembrar os ciclo de vida do projeto de acordo com a Taxonomia de
Bloom.
Na Figura 10 o jogador é desafiado a arrancar e
arrastar os parafusos para a lixeira num curto período de tempo.
5.1 Distrações e Desafios
O GameBOK possui uma série de distrações e
desafios para que o usuário possa jogar sem perder o ânimo ou
até mesmo sentir que o jogo está ficando monótono. Quando o
jogo começa a ficar cansativo distrações são exibidas ao
jogador. Na Figura 08 o jogador depois de responder algumas
perguntas, terá o desafio de montar um quebra-cabeça da
imagem que será tatuada no corpo do personagem Michael.
Figura 10: Removendo parafusos do sanitário.
5.1 Validação do Jogo
O GameBOK foi disponibilizado aos estudantes do curso
de Sistemas de Informação da Faculdade de Tecnologia e
Ciências (FTC), Campus Vitória da Conquista – BA que
cursam a disciplina Engenharia de Software. Posteriormente foi
aplicado um questionário abordando questões referentes à
utilização, importância, sugestões de melhoria e pontos fontes
do jogo.
Figura 08: Quebra-Cabeça camuflando tatuagem
Os dezoito estudantes da disciplina Engenharia de Software
responderam o questionário disponibilizado por [5]. As
respostas destes foram avaliadas da seguinte forma:
Outras distrações estão presentes no jogo, como por
exemplo, o jogador tem que clicar numa parede quebrado-a até
que o mesma esteja completamente destruída, Figura 09.
Afirmações: Foram 27 questões onde o usuário pode
responder se ele concorda ou discorda destas. Esse método
avaliativo tinha como opção de resposta: discordo
fortemente, discordo parcialmente, concordo parcialmente,
concordo, concordo Fortemente.
36
FEES
Conceitos: Para essa avaliação o estudante teve suas
respostas avaliadas no que ele sabia antes e depois de ter
jogado o GameBOK.
estudantes concordaram fortemente, 37,5% concordam e 25%
estudantes concordam parcialmente como mostra na Figura 12.
De acordo com a análise feita sobre a eficiência do jogo na
aprendizagem em comparação à outras atividades da disciplina,
37,5% dos estudantes concordaram plenamente, 37,5%
concordaram e 25% dos estudantes concordaram parcialmente
como se vê na Figura 12 .
Questões abertas: O estudante pode avaliar o jogo com seu
ponto de vista, buscando informar quais foram os pontos
fortes do jogo e quais sugestões ele daria para a melhoria
do mesmo.
O questionário foi dividido em quatro partes, avaliando o
jogo quanto a sua motivação, experiência do usuário,
aprendizagem e objetivos da aprendizagem.
Ao serem questionados se o jogo contribui na
aprendizagem da disciplina 50,0% dos estudantes concordaram
plenamente, 37,5% concordaram e 12,5% concorda
parcialmente que o jogo é importante para o aprendizado da
disciplina. A Figura 13 apresenta essas informações.
Para a motivação, conforme Figura 11 foram analisadas
perguntas que atendem requisitos como: Satisfação, confiança,
relevância e a atenção do jogador durante e depois do jogo.
Questionados quanto a satisfação 50% dos estudantes
mostraram que concorda com o nível de satisfação do jogo,
25% concordam parcialmente e os outros 25% concordam
fortemente. Quanto a confiança, relevância e atenção
transmitida pelo jogo 62,5% dos estudantes disseram que
concorda com a forma de ensino do jogo.
Figura 11: Gráfico Motivação
Ao avaliar os questionamentos dos estudantes sobre a
experiência do usuário ao jogo, obteve-se resultados
excelentes, principalmente tratando-se da diversão e desafios
propostos aos jogadores como apresenta na Figura 12. Os
outros requisitos como: Competência, Interação e Imersão
obtiveram ótimos resultados.
Figura 12: Gráfico Experiência do Usuário
Quando questionados sobre a experiência que o jogo
contribuiu para o desempenho na vida profissional 37,5% dos
37
FEES
Figura 14: Gráfico objetivos da aprendizagem
Como é mostrado na Figura 14, vê-se a suma importância
da aplicação de jogos de ensino-aprendizagem.
Figura 13: Gráfico de Aprendizagem
Para finalizar a avaliação dos objetivos de aprendizagem os
estudantes, como dito anteriormente citaram três pontos fortes
e sugestões de melhoria do mesmo, contribuindo com a maior
aceitação do jogo por todos.
Por fim foi feita uma avaliação dos resultados obtidos
depois de ter jogado o GameBOK. Foram abordados os
conceitos mais presentes no jogo, buscando identificar a
eficiência deste. Os conceitos avaliados foram: Grupos de
Processos do ciclo de vida do projeto; Conceitos básicos
(Stakeholders, Entregáveis, Premissas/Restrições, Sponsor e
PMI); Habilidades do gerente do projeto; Gestão de Riscos;
Escopo do Projeto; Mudanças da 4ª para a 5ª edição do
PMBOK.
Pontos fortes: Estratégia, curiosidade, conhecimento, boa
explicação do conteúdo, torna o aprendizado mais fácil,
divertido, torna fácil a memorização do conteúdo, designer,
Estimula o raciocínio lógico, ajuda memorizar o conteúdo e,
Interação com o usuário.
Sugestões de melhorias: Textos em áudio, deixar as
perguntas mais simples, explicar mais cada fase, perguntas
aleatórias, não repetir pergunta ao errar ou reiniciar o jogo.
Diminuir o valor de perda ao errar as perguntas, animações,
menos conteúdo e mais animações
Cada conceito passou pela avaliação onde o estudante
atribuiu uma nota de 1 a 5 para seu nível de conhecimento
antes e depois do jogo, como é exposto na Figura 14. As notas
são avaliadas a partir de três fatores:

Lembrar o que é: o estudante avalia se o jogo foi
eficiente ao aprendizagem e se jogo ajuda na
memorização dos conceitos aplicados;

Compreender como funciona: É ponderada a
compreensão do estudante antes e depois de ter
jogado o GameBOK;

VI TRABALHOS RELACIONADOS
Uma análise foi realizada entre os jogos já
desenvolvidos semelhantes ao jogo que este trabalho se propôs
a cumprir, onde a forma de avaliação dos jogos foi totalmente
direcionada ao PMBOK e todas as suas áreas de processos. Os
critérios avaliativos foram à interatividade do jogo com o
usuário e os conceitos aplicados. Três jogos foram escolhidos:
Puzzle PMBOK [7], Jogo de Processos da Rita [6] e PMBOX
Tetris I [9].
Aplicar na prática: O discente analisou os
conceitos quanto à sua aplicação na disciplina e/ou
vida profissional.
O Puzzle PMBOK é um jogo de tabuleiro criado pela
empresa KPO [7] com objetivo de oferecer soluções efetivas e
completas para empresas e instituições, testando os
conhecimentos dos jogadores. No Puzzle PMBOK os
jogadores tem que possuir um conhecimento prévio sobre o
PMBOK, caso contrário os jogadores não terão condições de
jogar ou sustentar o jogo até o final. O jogo contém dois níveis
de entretenimento, dando a possibilidade do jogador escolher
38
FEES
qual quer jogar. Desenvolvido para navegadores com suporte à
arquivos Flash, o jogo se torna ultrapassado, pois está
tecnologia sendo substituída pelo atual HTML5.
VII CONSIDERAÇÕES FINAIS
Após aplicação do jogo e posterior análise dos resultados
obtidos, o GameBOK apresentou resultado satisfatório,
cumprindo seu objetivo de auxiliar ao processo de ensinoaprendizagem das boas práticas de gerência de processos
utilizando o guia PMBOK 5ª edição. Além disso, de acordo
com a Taxonomia de Bloom, nele é possível lembrar , aplicar,
entender e analisar, sendo um diferencial dos jogos educativos
existentes nessa área, que atendem apenas ao lembrar.
Diferente do Puzzle PMBOK o Jogo de Processos da Rita
[10] (em inglês: Rita’s Process Game), dá ao usuário uma
melhor jogabilidade, tornando a experiência com o jogo mais
agradável. Este foi traduzido e adaptado por [6] no idioma
português. O jogo sofreu modificações, mas mantendo o
mesmo estilo de jogo de tabuleiro. O Jogo de Processos da
Rita, foi desenvolvido utilizando linguagens como JavaScript e
HTML. O jogo possui uma interface simples, mas assim como
o Puzzle PMBOK, este também exige que o usuário tenha um
bom conhecimento prévio sobre os Processos do PMBOK
Como sugestão de trabalho futuro é proposto a
implementação de novas fases, perguntas randômicas, suporte
a dispositivos móveis e melhorias no código e na estrutura do
jogo.
O Quadro 01 compara os jogos encontrados durante a
pesquisa e o jogo GameBOK. Neste é realizado uma análise
comparativa entre as funcionalidades propostas pelo jogo
GameBOK.
REFERÊNCIAS
[1] WANGENHEIM, Chistiane Gesse Von (2012). “Como ensinar com
jogos?”, XXXII Congresso da Sociedade Brasileira de Computação,
Curitiba.
[2] PMBOK (2013). “Um Guia do Conjunto de Conhecimentos em
Gerenciamento de Projetos (Guia PMBOK®)”, 5. Ed.. Project
Management Institute, Four Campus Boulevard, Newtown Square, PA
190073-3299
EUA.
Disponível
em:
<
https://drm.pmi.org/Default.aspx?doc=PMBOK_Guide5th_Portuguese.p
df>
O jogo PMBOX Tetris I [7], é um single-play onde o
jogador deve alocar os processos em suas devidas posições. No
jogo o usuário utilizando as setas do teclado para mover os
processos de um grupo de processos para o outro, alinhando-os
na sua devida posição, uma boa experiência do jogo é que de
acordo o usuário vai acertando as posições a velocidade em que
os blocos vão aparecendo vão ficando cada vai mais rápidas,
transmitindo ao usuário uma sensação de adrenalina e aventura
na sua experiência com o jogo. Um dos ponto negativo do jogo
, assim como encontrado em todos os comentados
anteriormente, é que o usuário precisa ter um bom
conhecimento sobre todos os processos do PMBOK antes de
jogar, outra dificuldade apresentada é que este só está
disponibilizado no idioma inglês.
[3]
[3] BOTELHO, Luiz (2004). “Jogos educacionais aplicados ao e-learning”.
Disponível em:
<http://www.elearningbrasil.com.br/news/artigos/artigo_48.asp.> Acessado
em: janeiro de 2004.
[4] FERRAZ, Ana Paula C.M. Taxonomia de Bloom: revisão teórica e
apresentação das adequações do instrumento para a definição de
objetivos institucionais.
Quadro 01: Comparação entre os jogos encontrados e o GameBOK.
Característica
Puzzle
PMBOK
GameBOK
Sim
Baseado na WEB
Jogo de
processos
da Rita
Sim
PMBOX
Tetris I
Sim
[5] SAVI, R.; GRESSE VON WANGENHEIM, C.; BORGATTO, A (2011).
“Um Modelo de Avaliação de Jogos Educacionais na Engenharia de
Software”. 25th Brazilian Symposium on Software Engineering
(SBES)/São Paulo/Brazil.
Sim
Suporte nativo ao
português do Brasil
Sim
Sim
Sim
Não
Personagens
Sim
Não
Não
Não
Sistema de desafio
ao usuário
Sim
Não
Não
Sim
Fácil aprendizado
Sim
Não
Não
Não
Aborda as áreas do
PMBOK?
Sim
Sim
Sim
Sim
Taxonomia
Bloom
Lembrar,
Aplicar,
Enteder
Analisar
Lembrar
Lembrar
Lembrar
de
TAROUCO, L. et al. Jogos Educacionais. Novas tecnologias na
educação, Rio Grande do Sul, CINTED-UFRGS, 2004.
[6] GUINTER, Marco (2014). “Jogo de processos da Rita (versão estendida)
v1.0”. Disponível em <http://www.viawebsite.com.br/jogoPMP/v2.htm>
Acesso em: 07 mar. 2014.
[7] KPO, Consulting and Educational Services (2014). “PUZZLE PMBOK”.
Disponível em <http://www.kpocs.com.br/Game/pmbok.html> Acesso
em: 03 mar. 2014.
[8] PMI Book Service Center (2008). “Um Guia do conhecimento em
Gerenciamento de Projetos”. 4.Ed. Atlanta.
[9] RAD, Nader Khorrami (2014). PMarchy - PMBOX Tetris 1. Disponível
em < http://www.pmarchy.com/pmbok-tetris-1/> Acesso em: 10 mar.
2014.
[10] AFRIDI, Samir. Rita’s Process Game [UNOFFICIAL] v1.2. Disponível
em <http://pmp.aamirafridi.com/_rpg/index-3.html> Acesso em: 07 mar.
2014.
e
39
FEES
Avaliação por Meio de Questionários de um
Curso Online para Engenharia de Software
Lucas Garcia, Ingridy Martins, Luiz Ferreira, Eduardo Figueiredo
Laboratório de Engenharia de Software (LabSoft), Universidade Federal de Minas Gerais (UFMG)
Belo Horizonte, Brasil
{lucas.sg, ingridymartins, luizpcf, figueiredo}@dcc.ufmg.br
Adeptos desse tipo de ensino argumentam que o suporte de
material online, tais como aulas em vídeo, permite aos alunos
acompanharem o curso no seu próprio ritmo e horário. Desta
forma, o curso aberto constitui uma ferramenta importante no
processo de aprendizagem [2]. 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. Além de aulas em vídeo, alunos registrados em
um curso aberto podem desempenhar outras atividades, como
responder a questionários de revisão e participar em fóruns de
discussão. Em alguns casos, o aluno que completar o curso
aberto pode obter um certificado de conclusão.
Resumo—Curso aberto e online, tais como MOOC (Massive
Open Online Course), é um método emergente de ensino que não
é limitado por restrições de espaço e localização. A implantação
bem sucedida de um curso online exige mudanças conceituais na
forma como professores e alunos se comportam em um ambiente
aberto de ensino. Existem algumas iniciativas emergentes de
cursos online para a Engenharia de Software. No entanto, ainda é
limitado o conhecimento sobre as vantagens de um curso online
para o ensino de Engenharia de Software. Este artigo avalia o
desempenho de alunos em um curso online de Engenharia de
Software. Mais de 230 alunos estão registrados neste curso online
que apoia um curso presencial de ementa equivalente. O curso
online é composto de 44 aulas em vídeo, 140 perguntas em 14
questionários de revisão e vários tópicos de discussão. Para
avaliar o curso, foi comparado o desempenho de alunos nos
questionários de revisão em relação à: (i) participação destes
alunos em outras atividades do curso como vídeos assistidos, (ii)
frequência dos alunos em aulas presenciais e (iii) desempenho dos
alunos em provas presenciais. Os resultados indicam baixa
correlação entre os vídeos assistidos e o desempenho nos
questionários de revisão. Por outro lado, frequência em aulas
presenciais e desempenho nas provas estão diretamente
relacionados ao sucesso em questionários online de revisão.
Existem algumas iniciativas emergentes de cursos abertos
para o ensino de Engenharia de Software, como o curso de
Arquitetura de Software Orientada a Padrões [24] e Software
como Serviços [25]. Entretanto, estes cursos são restritos a
tópicos específicos de Engenharia de Software ou focam no
ensino de programação. Além disso, não é de nosso
conhecimento estudos sistemáticos que investigam as
vantagens e desvantagens de cursos abertos para o ensino de
conceitos básicos de Engenharia de Software, tais como
engenharia de requisitos, processos de software e reutilização
de software. Portanto, 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.
Palavras-chave—Educação, MOOC, Engenharia de Software,
Avaliação.
I.
INTRODUÇÃO
A internet tem se tronado uma importante ferramenta para
modificar as formas de ensino através de cursos abertos e
online. Um curso aberto é um método de ensino online que
não é limitado por restrições de espaço e localização [19].
Cursos abertos têm particularmente se expandido na última
década através dos MOOCs (do inglês, Massive Open Online
Course) [18]. Várias universidades dos principais centros
educacionais influentes ao redor do mundo criaram ou estão
criando cursos abertos com suporte total ou parcial via
internet. Por exemplo, a Universidade de Harvard e o MIT
(Massachusetts Institute of Technology) estão investindo na
criação de vários MOOCs por meio do portal edX [12]. Outras
mais de 100 universidades, em sua maioria americanas e
europeias, estão envolvidas na criação de centenas de cursos
abertos em diversas áreas do conhecimento pelo portal
Coursera [9]. Muitos outros cursos abertos são oferecidos em
portais similares, como no in Udacity [28] e no Udemy [29].
Por outro lado, no ano de 2013 foi criado um curso aberto
online para o ensino de Engenharia de Software [1] [14] [23] a
partir de um curso presencial equivalente da Universidade
Federal de Minas Gerais (UFMG). Este curso teve como
objetivo inicial atender os mais de 100 alunos anualmente
matriculados em 4 turmas (duas turmas por semestre) da
universidade. O material usado no curso online (e.g., livro
texto, apresentações, exercícios, etc.) é exatamente o mesmo
usado no curso presencial equivalente. Atualmente, o curso
online de Engenharia de Software é composto de 44 aulas em
vídeo, 140 perguntas em 14 questionários de revisão e vários
tópicos para discussão em formato de fórum. O curso online
conta hoje com mais de 230 alunos registrados, sendo que
aproximadamente metade deste número não são (nem foram)
alunos da UFMG.
Neste contexto, este artigo apresenta avaliação deste curso
online de Engenharia de Software que foi proposto em um
40
FEES
trabalho anterior [23]. Além disso, outro estudo anterior [14]
apresentou uma avaliação preliminar baseada no desempenho
dos alunos em provas. Dando continuidade, este artigo
apresenta uma nova dimensão de avaliação investigando em
detalhes o desempenho dos alunos em questionários de revisão
(do inglês, quiz) e correlacionando com outras variáveis do
curso. Nesta avaliação, foram considerados dados de uma
amostra aleatória1 de 43 alunos que fizeram o curso em dois
semestres consecutivos (2013-II e 2014-I).
A estrutura do curso e os resultados do estudo piloto foram
apresentados à comunidade por meio de estudo anteriores [14]
[23]. Nestes estudos preliminares, os autores avaliaram o
curso online comparando o desempenho dos alunos do curso
no primeiro semestre de 2013 com o desempenho de alunos
em turmas anteriores (2012), nas quais o curso era ofertado
somente de forma presencial. Os principais resultados dos
estudos anteriores foram os seguintes.
Os resultados deste estudo indicam que o desempenho dos
alunos nos questionários de revisão melhorou de um semestre
para outro consideravelmente. Esta melhora pode ter sido
impactada por mudanças pontuais no programa do curso.
Observamos também que as questões com maiores taxas de
erros são praticamente as mesmas nos dois semestres. Por
outro lado, foi encontrada baixa correlação entre o
desempenho nos questionários de revisão e o total de vídeos
assistidos no website do curso. Este artigo avalia também a
correlação entre o desempenho nos questionários de revisão
em relação à (i) frequência em aulas presenciais e (ii) notas
nas provas. Em ambos os casos, a correlação é baixa para a
turma 2013-II, mas moderada na turma 2014-I. A justificativa
para esta variação pode estar em mudanças no formato do
curso e/ou no perfil dos alunos de cada turma.
Os alunos se mostraram engajados e motivados a
participarem do curso online, especialmente como forma
de revisar para provas;
•
As notas das provas dos alunos no curso presencial com
apoio do curso online são estatisticamente maiores do
que as notas de alunos cursando a mesma disciplina
puramente presencial; e
•
A frequência dos alunos no curso com apoio do curso à
distância não foi fator determinante para as suas boas
notas.
Esses resultados serviram de motivação para os autores
darem continuidade ao trabalho neste artigo. Nesse sentido,
este trabalho busca avaliar o curso em outras dimensões, com
foco principalmente nos questionários de revisão. Para isso,
foram incluídos 8 novos questionários de revisão no curso
online; sendo quatro em 2013-II e outros quatro em 2014-I.
Portanto, dos 14 questionários atuais do curso, 10 deles são
comuns aos dois semestres considerados em nossa avaliação
(2013-II e 2014-I).
O restante do artigo está organizado da seguinte forma. A
Seção II revisita o curso online de Engenharia de Software que
é objeto desta avaliação. A Seção III apresenta os resultados
da avaliação enquanto a Seção IV enumera algumas lições
aprendidas. A Seção V discute trabalhos relacionados, com
foto especial em educação aberta no contexto de Engenharia
de Software. A Seção VI apresenta algumas limitações do
estudo. Finalmente, a Seção VII conclui este artigo e propõe
direções para trabalhos futuros.
II.
•
A Tabela I apresenta uma breve descrição do assunto
abordado em cada um dos 10 questionários de revisão. A
coluna à esquerda dessa descrição representa a identificação
dos 10 questionários (Q1 a Q10) comuns aos dois semestres
utilizada no artigo. O curso online de Engenharia de Software
passou por ajustes visando sua melhoria. Estes ajustes incluem
a inclusão de novos questionários (descrito acima) e alterações
na ordem de algumas aulas e questionários. Assim, a coluna à
direita apresenta a correspondência com a numeração atual
dos questionários presentes no website do curso [1]. Por
exemplo, o questionário sobre Métodos Ágeis [5] é tratado no
artigo como Q3 e têm atualmente o identificador Quiz 3 no
website do curso.
O CURSO ONLINE DE ENGENHARIA DE SOFTWARE
Esta seção apresenta (A) um breve histórico de criação do
curso online, (B) o programa do curso e (C) as estatísticas de
acessos e registros de alunos.
A. Histórico de Criação do Curso Online
A criação do curso online de Engenharia de Software foi
motivada pela crescente disponibilidade de cursos abertos
online no formato de MOOCs em várias universidades dos
principais centros influentes em educação ao redor do mundo.
Inicialmente, o objetivo do curso online de Engenharia de
Software era apoiar o aprendizado dos alunos matriculados na
disciplina presencial equivalente na Universidade Federal de
Minas Gerais (UFMG). Assim, em fevereiro de 2013, o curso
online foi criado, inicialmente com 44 aulas em vídeo e 6
questionários de revisão. O primeiro semestre de 2013 serviu
como estudo piloto para a identificação de pontos para
melhoria do material do curso. Portanto, dados dos alunos de
2013-I não estão sendo considerados neste artigo.
TABELA I. CONTEÚDO E CORRESPONDÊNCIA DOS QUESTIONÁRIOS
Artigo Descrição
1
A amostra inclui alunos matriculados no curso presencial da
UFMG que se registraram no curso online e nos enviaram as
respostas dos questionários de revisão.
41
Site
Q1
Introdução a Engenharia de Software
Quiz 1
Q2
Processos de Software
Quiz 2
Q3
Métodos Ágeis
Quiz 3
Q4
Arquitetura de Software e Padrões Arquiteturais
Quiz 6
Q5
Idiomas de Programação
Quiz 9
Q6
Reutilização de Software
Quiz 12
Q7
Engenharia de Software baseada em Componentes
Quiz 13
Q8
Desenvolvimento de Software Orientado a Aspectos
Quiz 14
Q9
Qualidade e Medição de Software
Quiz 15
Q10
Melhoria de Processos de Software
Quiz 16
FEES
O conteúdo abordado no curso envolve tópicos básicos de
Engenharia de Software, tais como engenharia de requisitos e
processos de software [6]. Além disso, são apresentados cinco
diagramas da UML [7]: Diagrama de Casos de Uso, Diagrama
de Classes, Diagrama de Sequência, Diagrama de Colaboração
e Diagrama de Atividades. O curso também apresenta tópicos
relacionados a reutilização de software [3], qualidade de
software [16] e melhoria do processo de software.
B. Programa do Curso Online de Engenharia de Software
O curso online de Engenharia de Software é um curso
gratuito e baseado em dois livros texto: Engenharia de
Software de Sommerville [26] e UML Guia do Usuário de
Booch, Rumbaugh, Jacobson [7]. O curso possui atualmente
44 aulas em vídeo totalizando mais de 20 horas de conteúdo
gravado, além de 14 questionários de revisão (e dois em
construção) e vários tópicos para discussão no formato de
fórum. Cada questionário contém 10 perguntas de múltipla
escolha. Uma figura que ilustra a tela principal do curso e
identifica seus principais elementos é apresentada no Anexo I.
C. Estatísticas Resumidas do Curso
O curso online de Engenharia de Software (acessível em
[1]) foi implantado no ambiente Udemy. Udemy [29] é uma
plataforma de aprendizagem online e gerência de conteúdo
que permite aos instrutores criarem cursos pagos ou gratuitos.
Utilizando o Udemy, os instrutores disponibilizam no curso:
aulas em vídeo, apresentações, questionários de revisão e
arquivos complementares. 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 as aulas em vídeo e ter acesso ao conteúdo
utilizando dispositivos móveis.
A Tabela II apresenta a lista de vídeos e um mapeamento
de cada vídeo (2ª e 3ª colunas) para a aula presencial
equivalente na primeira coluna. Note que mais de um vídeo é
associado à uma única aula presencial, pois o primeiro tem no
máximo 30 minutos de duração enquanto um dia de aula
presencial dura 1 hora e 40 minutos.
TABELA II. PROGRAMA DE AULAS DO CURSO ONLINE.
Dia
I
II
III
IV
V
VI
VII
VIII
IX
X
XI
XII
XIII
XIV
XV
XVI
Vídeo
Conteúdo abordado
1
Apresentação do Curso
2
Introdução a Engenharia de Software
3
Desenvolvimento e Evolução de Software
4
Atividades Comuns de Desenvolvimento de Software
5
Processos de Software
6
Processos de Software que Lidam com Mudanças
7
Desenvolvimento Ágil de Software
8
Programação Extrema (XP)
9
Scrum
10
Requisitos de Usuários e Requisitos do Sistema
11
Requisitos Funcionais e Requisitos Não Funcionais
12
Processos de Engenharia de Requisitos
13
Introdução a UML
14
Diagramas de Casos de Uso
15
Arquitetura de Software
16
Padrões Arquiteturais
17
Modelagem de Software Orientada a Objetos
18
Diagrama de Classes
19
Diagrama de Sequência
20
Uso de Diagrama de Sequência para Casos de Uso
21
Diagrama de Colaboração
22
Diagrama de Atividades
23
Programação Orientada a Objectos
24
Idiomas de Programação
25
Verificação e Validação de Software
26
Inspeção de Software
27
Testes de Software
28
Evolução de Software
29
Refatoração e Reengenharia
30
Reutilização de Software
31
Técnicas de Reutilização de Software
32
Linha de Produtos de Software
33
Engenharia de Software baseada em Componentes
34
Processos de Desenvolvimento de Componentes
35
Composição de Componentes
36
Separação de Interesses
37
Desenvolvimentos de Software Orientado a Aspectos
38
A Linguagem AspectJ
39
Qualidade de Software
40
Medição e Modelos de Qualidade
41
Métricas de Produtos de Software
42
Melhoria de Processos de Software
43
Os Modelos CMM e CMMI
44
O Modelo Brasileiro MPS.Br
O Udemy permite que os instrutores visualizem algumas
estatísticas referentes aos seus cursos. Estas estatísticas são
processadas no próprio ambiente de administração do curso e
estão relacionadas ao envolvimento e adesão dos alunos.
Todas as estatísticas que estão disponíveis foram analisadas e
aquelas que foram consideradas relevantes para este estudo
estão apresentadas nesta seção em forma de gráfico. Além das
estatísticas do portal Udemy, também analisamos dados
coletados pelo Google Analytics2.
A Figura 1 apresenta um gráfico sobre o consumo geral de
conteúdo do curso nos últimos doze meses; i.e., agosto de
2013 a julho de 2014. Esse consumo é medido em minutos de
acesso ao curso e o gráfico apresenta os resultados
acumulados mês a mês. Nesse período, verificou-se que há um
menor consumo de conteúdo no período de férias escolares e
picos de consumo em finais dos respectivos semestres. Essas
características são explicadas pelo fato de que o curso online
de Engenharia de Software ser utilizado como forma de apoio
a disciplina presencial na universidade. Portanto, os alunos
buscam recursos disponíveis no curso online, por exemplo,
para se prepararem para as provas em finais de semestre.
Fig. 1. Consumo geral de conteúdo
2
42
http://www.google.com/analytics/
FEES
Fig. 2. Estatística de visualização de páginas do curso online de janeiro a junho de 2014.
Rastreamos também o acesso às páginas do curso por meio
do Google Analytics. Esta ferramenta indica mais de 8 mil
visualizações às páginas do curso online de Engenharia de
Software nos últimos seis meses (janeiro a junho de 2014). A
Figura 2 detalha o número de páginas visualizadas neste
período. Os picos que aparecem nesta figura correspondem
tipicamente aos dias de aulas presenciais, nos quais os alunos
também acessam o conteúdo online. Os vales mais fundos são
normalmente finais de semana, feriados ou período de férias
(por exemplo, o mês de janeiro de 2014). Picos mais altos
correspondem principalmente a dias de exercícios ou provas
presenciais.
Yahoo. Este fato merece atenção dos instrutores que podem,
por exemplo, trabalharem na divulgação do curso online para
a sociedade além das fronteiras da universidade que o
mantém.
As Figuras 3 e 4 apresentam dados em relação à adesão ao
curso. Por exemplo, a Figura 3 apresenta o número de novos
estudantes registrados nos últimos doze meses. Nesse gráfico,
pode-se verificar que os meses que possuem os menores
índices são os meses que estão no meio do semestre, tais como
abril e maio de 2014, ou no período de férias, como dezembro
e janeiro de 2013. Esse fato sugere uma relação entre o
número de novos estudantes e o andamento da disciplina no
curso presencial da universidade. Estranhamente, há um
grande número de novas adesões ao curso online no mês de
junho de 2014 (pico na Figura 3). Este caso é intrigante, mas
pode estar associado ao fato de um artigo recente sobre o
curso ter sido aceito para publicação [14]. Outra explicação
possível é que algum professor tenha recomentado o curso
para seus alunos.
Fig. 4. Visitas à página de destino por origem de tráfego externa
III.
AVALIAÇÃO DO CURSO
Esta seção apresenta uma avaliação do curso considerando
vários aspectos, focando principalmente no resultado dos
questionários de revisão; ou questionários, para simplificar o
texto). A Seção III.A apresenta a taxa de acerto dos alunos nos
questionários. A Seção III.B investiga esta taxa em relação as
questões individuais. A Seção III.C discute a correlação entre
a taxa de acerto nos questionários e o percentual de vídeos
assistidos por cada aluno. A Seção III.D faz similar análise em
relação à frequência em aulas presenciais. Finalmente, a Seção
III.E correlaciona o desempenho nos questionários online com
o aproveitamento em provas presenciais.
A. Taxa de Acerto dos Alunos nos Questionários
O curso online de Engenharia de Software possui
atualmente mais de 230 alunos registrados. Uma parte destes
alunos refere-se a estudantes regularmente matriculados na
disciplina presencial em semestres anteriores. Estes estudantes
são, em sua maioria, estudantes de cursos oferecidos pelo
Departamento de Ciência da Computação da UFMG: Sistemas
de Informação e Ciência da Computação.
Fig. 3. Número de novos estudantes
Para a análise e comparação de desempenho dos
estudantes nos questionários, foram analisadas uma amostra
de 43 alunos das turmas academicamente matriculadas na
disciplina presencial em 2013-II e 2014-I. A primeira turma
possui 23 alunos enquanto a segunda possui 20 alunos. Esta
amostra inclui apenas os alunos que nos enviaram as suas
O gráfico da Figura 4 apresenta o número de visitas à
página do curso por origem do acesso. Das origens conhecidas
a que tem maior índice é o site da UFMG no qual os
instrutores normalmente divulgam o site do curso para os
alunos da universidade. Ainda é pouco expressivo o número
de acesso providos de mecanismos de busca, como Google e
43
FEES
respostas para os questionários, pois as mesmas não são
individualmente disponibilizadas aos instrutores.
Software (Questionário 2) e Métodos Ágeis (Questionário 3).
Uma possível explicação é que os alunos não deram devida
atenção aos questionários no início do curso. O índice de erro
diminui com o avanço do aluno no curso.
A Figura 5 mostra o desempenho médio geral das
avaliadas. Turma A refere-se a 2013-II e Turma B
corresponde a 2014-I. Na Turma A, foram feitos 10
questionários e na Turma B, foram feitos 14 questionários
(vide Seção II.A). Para comparação, é considerado somente os
dez questionários respondidos por ambas as turmas. Em cada
questionário são feitas 10 questões de múltipla escolha sobre
um assunto já visto anteriormente no curso. Vale ressaltar que,
como a amostra inclui apenas alunos academicamente
matriculados no curso presencial, os alunos tiveram a opção
de ler slides sobre o assunto e assistir às aulas em sala.
Turma A (2013-II)
TABELA III. QUESTÕES COM MAIOR ÍNDICE DE ERRO DAS TURMAS A E B
Quest.
1
2
3
4
5
6
7
8
9
10
Turma A
Questão
% de Erro
6
1
7
1e4
2e3
5
10
2
1e3
2e9
64,71%
60%
66,67%
26,67%
23,53%
35,29%
11,76%
40%
40%
14,29%
Turma B
Questão
% de Erro
6
1
7
4e5
5
5
6e9
8
3e5
9
44,44%
61,11%
66,67%
28,57%
23,08%
42,86%
21,43%
35,71%
15,38%
35,71%
Observando também os dados da Tabela III, percebe-se
que 70% das questões que possuem o maior índice de erro são
iguais em ambas as turmas. Uma explicação possível é que as
questões com elevadas taxas de erros não têm todas as
alternativas claramente explicadas no material do site
(necessitando consulta ao livro texto). Percebe-se também que
a maioria dos questionários tem um índice de erro baixo. Isso
se deve a quantidade de materiais disponíveis para consulta no
website do curso.
Turma B (2014-I)
Fig. 5. Desempenho médio geral da turmas avaliadas.
Os gráficos da Figura 5 mostram um melhor desempenho
nos questionários da Turma B em relação a Turma A. Esta
diferença de rendimento entre as duas turmas é possivelmente
explicada pela alteração do programa da disciplina. Dentre as
alterações mais relevantes de 2013 para 2014, houve uma
mudança de ordem de apresentação de alguns tópicos e a
adição de mais 4 novos questionários a serem feitos pelos
alunos em 2014-1. Além disso, os questionários começaram a
ser feitos como revisão para as provas; ou seja, uma aula antes
da prova que trata o conteúdo. Esta prática pode ter levado os
alunos de 2014-I a estudarem mais antes de responder os
questionários.
C. Participação Online
Esta seção tem o objetivo de analisar se a participação
online dos alunos estabelece algum tipo de relação com suas
notas nos questionários. As Figuras 6 e 7 apresentam,
respectivamente para as Turmas A e B, os gráficos de
dispersão com as duas variáveis em questão: porcentagem de
vídeos assistidos e desempenho nos questionários. Além dos
gráficos de dispersão, procurou-se interpretar alguns índices
importantes tais como média, coeficiente de variação e
coeficiente de correlação entre duas variáveis [17].
B. Análise das Questões
Como analisado na Seção III.A, a Turma B possui um
rendimento médio superior ao da Turma A nos questionários
de revisão. Por outro lado, ao analisar cada questionário
individualmente, percebe-se que os índices de erro em uma
mesma questão são muito parecidos. Por exemplo, existem
questões com índices de erro inferior a 20% ou até mesmo
nulo. Por outro lado, há questões com índices de erro acima de
50% em ambas as turmas.
As informações sobre a porcentagem de vídeos assistidos
por cada aluno são calculadas a partir do total de vídeos
disponíveis no curso. Essa estatística foi retirada do próprio
ambiente educacional Udemy. Este ambiente considera um
vídeo assistido se um aluno iniciou a exibição daquele vídeo.
É importante ressaltar que a existência dessa funcionalidade
não foi informada aos alunos a fim de evitar distorções por
alunos forjando seu percentual de vídeos assistidos. Por outro
lado, o desempenho do aluno nos questionários foi calculado a
partir da média aritmética simples das notas dos questionários
aos quais ele respondeu.
A Tabela III mostra as questões que obtiveram maior
índice de erro em cada questionário considerando ambas as
Turmas A e B. Nesta tabela, “Quest.” se refere ao número de
cada questionário. “Questão” e “% de Erro” indicam,
respectivamente, as questões com maior índice de erros o
índice de erro médio da turma nesta questão. Os três
questionários que apresentaram as questões com o maior
percentual de erro são relacionados a Introdução da
Engenharia de Software (Questionário 1), Processos de
Essas informações foram coletadas a partir de uma
interação direta entre os instrutores e os alunos matriculados
na disciplina presencial. Isto tornou-se necessário já que o
Udemy permite apenas uma visualização geral do desempenho
dos mais de 230 alunos do curso online. Ou seja, ele não
44
FEES
disponibiliza meios para o estudo de
individualmente, como é feito nesse estudo.
cada
aluno
D. Participação Presencial
Uma outra dimensão da análise é a participação presencial.
Para tal, foram utilizadas as mesmas técnicas de estudo da
participação online descritas na seção anterior. Nessa
oportunidade foram coletadas informações do diário de classe
referentes a frequência dos alunos em aulas presenciais.
Através dessas informações se pôde quantificar o nível de
correlação entre a frequência dos alunos nas aulas presenciais
e suas respectivas notas nos questionários de revisão. Os
resultados desta correlação estão apresentados nas Figuras 8 e
9. A Figura 8 apresentam os dados da Turma A e a Figura 9 os
dados da Turma B
A Figura 8 apresenta uma linha de tendência ligeiramente
inclinada positivamente e um gráfico de dispersão que reforça
uma correlação fraca entre as variáveis. Essa hipótese foi
quantificada pelo coeficiente de correlação de 0,07; i.e., índice
baixo. Por outro lado, a Figura 9 apresenta uma linha de
tendência mais inclinada. Além disso, o coeficiente de
correlação calculado para esta turma também foi superior. O
valor de 0,35 pode ser considerado como um valor médio de
correlação.
Fig. 6. Turma A: % de vídeos assistidos vs. Desempenho nos questionários
Fig. 7. Turma B: % de vídeos assistidos vs. Desempenho nos questionários
Em relação a Turma A foi observado, através do gráfico de
dispersão e da linha de tendência da Figura 6, que há uma
relação positiva muito fraca entre a porcentagem de vídeos
que os alunos assistiram e seus respectivos desempenhos nos
questionários de avaliação. O resultado dessa observação foi
reforçado pelo cálculo do coeficiente de correlação entre as
duas variáveis, cujo resultado é de 0,14. Este índice de
correlação é considerado muito baixo. Uma situação parecida
foi observada na Figura 7 para a Turma B. Porém, neste caso a
linha de tendência aparece mais inclinada e o coeficiente de
correlação foi de 0,30 - caracterizando um nível médio de
correlação.
Fig. 8. Turma A: Frequência vs. Desempenho nos questionários
A partir desses resultados conclui-se que assistir às aulas
em vídeo do curso à distância foi fator pouco determinante
para o um desempenho do grupo de alunos estudados nos
questionários de revisão. Esse quadro pode ser explicado pelo
fato desses alunos terem a possibilidade de assistir às aulas
presenciais ou estudar por meio de outros materiais
disponíveis (por exemplo, pelos livros texto da disciplina).
Entretanto, o aumento no desempenho da Turma B em relação
a Turma A nos questionários e um aumento no coeficiente de
correlação entre as variáveis sugerem um crescente
engajamento dos alunos matriculados na disciplina no
ambiente online.
Fig. 9. Turma B: Frequência vs. Desempenho nos questionários
Apesar do desempenho nos questionários estar mais
relacionado com a frequência para a Turma B do que para a
Turma A, percebeu-se que a média de frequência na Turma A
foi menor. Além disso, verificou-se no gráfico da Figura 8
(principalmente) que mesmo alunos com índice de frequência
muito baixo, obtiveram excelentes resultados nos
questionários se comparados com seus colegas de turma. Esses
45
FEES
relação entre as variáveis, e essa hipótese é reforçada com o
resultado do coeficiente de correlação que foi de 0,46 e a uma
inclinação bem visível da linha de tendência no gráfico. Os
alunos do segundo perfil podem ser considerados como
outliers. Uma possível explicação para esse último caso seria
que esses alunos não se dedicaram tanto na realização das
provas.
resultados sugerem que a participação online do aluno em
conjunto com sua participação presencial pouco contribui em
seu desempenho nos questionários de revisão.
E. Desempenho em Provas
Esta seção investiga uma possível relação entre o
desempenho dos alunos nos questionários de revisão e o
desempenho desses alunos nas provas aplicadas no decorrer da
disciplina presencial. Essa dimensão de avaliação chamou
bastante atenção pois faz uma comparação direta entre duas
formas diferentes de avaliar os alunos dentro de um mesmo
domínio. Entretanto, como provas diferentes foram aplicadas
às Turmas A e B teve-se o cuidado de realizar o estudo
separadamente por turma. O critério para calcular o
desempenho do aluno nas provas foi o mesmo para o
desempenho nos questionários, calculando-se média aritmética
simples entre as notas de todas as atividades avaliativas que o
aluno realizou. As técnicas estatísticas utilizadas para esse
estudo foram as mesmas empregadas nas seções anteriores e
os resultados estão apresentados a seguir.
A Figura 10 apresenta um gráfico de dispersão com uma
linha de tendência onde cada aluno da Turma A é representado
por um ponto. Visualmente percebe-se que o desempenho nos
questionários não variou muito entre os alunos, já em relação
as provas houve uma variação bem maior. Estatisticamente, a
linha de tendência exibida no gráfico apresenta uma baixa
inclinação e o resultado do coeficiente de correlação de
Pearson calculado foi de 0,06, que é um índice muito baixo.
Contudo, é possível observar que a maioria dos alunos dessa
turma teve desempenho médio tanto nos questionários quanto
nas provas. Esse fato reforça a ideia da existência de uma
relação entre as duas variáveis apesar das estatísticas não
favoráveis.
Fig. 11. Turma B: Desempenho nos questionários e provas
IV.
LIÇÕES APRENDIDAS
Percebe-se através das análises feitas na Seção III que os
questionários são muito úteis aos alunos para praticar o seu
aprendizado. Além disso, eles são úteis para os instrutores que
podem visualizar melhor a dificuldade dos alunos em cada
tópico dado em sala de aula. Após visualizar as eventuais
dificuldades dos alunos, o professor pode tomar algumas
medidas, tais como explicar mais detalhadamente o tópico
com grande percentual de erro em sala de aula e nos materiais
disponíveis no curso online.
Os materiais disponíveis para os alunos no curso online
são de enorme importância. Através deles, tanto os alunos
academicamente matriculados como os alunos online podem
aprender e melhorar o seu aprendizado sem sair de casa. Além
disso, os alunos não academicamente matriculados não
precisam pagar um curso sobre Engenharia de Software já que
o curso online é gratuito.
Além dos materiais disponibilizados, uma boa ferramenta
para aprendizado é o fórum. O curso online mantém um fórum
de discussão onde é possível que os alunos interajam entre si.
Existem 14 tópicos diferentes, no qual os alunos podem
discutir sobre a disciplina e retirar dúvidas de outros colegas.
Este tipo de ferramenta é muito importante, pois um aluno
pode aprender muito mais com outros alunos, além de se sentir
motivado a continuar o curso e estudar.
Fig. 10. Turma A: Desempenho nos questionários e provas
Para a Turma B foi feito o mesmo tipo de análise feita para
a Turma A. O gráfico equivalente está devidamente
representado pela Figura 11. Nesse gráfico pode-se observar
três perfis de alunos que tiveram desempenho parecido entre
si: o primeiro deles, que caracteriza a maioria dos alunos, teve
desempenho excelente nos questionários e bom nas provas;
outro teve desempenho excelente nos questionários e ruim nas
provas; e o último, caracterizado por apenas um aluno, teve
desempenho médio nos questionários e ruim nas provas. A
observação do primeiro e do último perfil sugerem uma
Analisando o comportamento dos alunos no fórum, é
possível visualizar que a maioria dos alunos que participaram
de algum tópico do fórum são alunos da Turma B. Isso se deve
ao fato de que o fórum foi criado ao longo do segundo
semestre de 2013 e, portanto, houve uma maior visualização
dos tópicos por parte dos alunos da Turma B. Outro fato a ser
citado é que os alunos participantes do fórum, mesmo da
Turma B são poucos, porém muito frequentes, ou seja, alunos
que postam em quase todos os tópicos.
46
FEES
V.
Finalmente temos a ameaça na identificação da causa e
efeito no experimento, nosso experimento avalia qual os
impactos na nota final dos alunos quando realizam os
questionários corretamente, mas existe a possibilidade de na
verdade as notas dos alunos impactarem no resultado dos
questionários, e não o contrário, onde bons alunos conseguem
resolver os questionários sem dificuldades por serem bons
alunos e não que eles são bons alunos por se prepararem para
os questionários. Ou então que a presença dos alunos em sala
de aula causa ambos os resultados, com boas notas nos
questionários e na avaliação final. De qualquer maneira existe
claramente uma dificuldade de identificar qual ação gera o
efeito real na outra.
AMEAÇAS À VALIDADE
Esta seção discute possíveis ameaças a validade do estudo
[32]. A primeira ameaça a validade do experimento é o fato do
experimento ter sido conduzido em 2 turmas diferentes. Como
os questionários são um complemento das aulas em sala de
aula, a aula do professor em cada uma das turmas pode ter
sido levemente diferente, mesmo que tenha sido realizada pelo
mesmo professor, o que pode causar uma turma a possuir
notas mais altas que outra. O professor ao dar a mesma
disciplina em dois períodos seguidos acaba evoluindo em sua
didática, tendendo a dar uma aula de qualidade superior para a
segunda turma em comparação com a primeira. As aulas
foram assistidas tanto online quanto presencial, onde as aulas
online não foram modificadas, mesmo com isso o impacto de
uma aula diferentes pode ser grande, principalmente para
alunos que não assistiram muitas aulas pelo computador.
VI.
TRABALHOS RELACIONADOS
Muitos trabalhos têm sido realizados com o objetivo de
melhorar o ensino de Engenharia de Software [8] [10] [13]
[14] [20] [21] [22]. Além disso, trabalhos focados em
Engenharia de Software e educação aberta tem recebido um
grande destaque na academia [30]. Entretanto, estes trabalhos
não analisam o impacto que o ambiente online pode exercer
sobre o aprendizado dos alunos como é descrito por Derwin
[11]. O que diferencia este trabalho dos demais é a forma
como avaliamos o impacto que uma atividade realizada online
pode ter no desempenho e aprendizado de um aluno
regularmente matriculado em um curso presencial de
Engenharia de Software.
Outra ameaça é que o próprio curso sofreu uma evolução
nesse período, mais questionários foram adicionados a
segunda turma e mais conteúdos diferentes foram
disponibilizados, entretanto isto não invalida o experimento
pois os conteúdos dos questionários avaliados neste artigo
foram mantidos. O maior problema desta evolução é que o
aluno, ao responder mais questionários, pode se preparar
melhor a esse tipo de avaliação, podendo ter um rendimento
superior nesses testes do que teria se tivesse realizado o
experimento na primeira turma.
Podemos acrescentar também que as aulas online não
foram realizadas em um ambiente controlado, onde que cada
aluno realizou suas atividades de sua residência, desta forma é
aceitável que possamos ter desvios causados por distrações
durante as respostas dos alunos, uma vez que cada um realizou
a atividade em ambiente diferente, e em horários diferentes.
Como a distribuição das possíveis distrações não foram
escolhidas por nós, podemos dizer que elas foram aleatórias.
Entretanto essas distrações podem impactar no resultado de
cada aluno, podendo causar distorções nos resultados e devem
ser destacadas nessa seção.
O trabalho mais semelhante ao que nós fazemos é o
realizado por Ahmadi e Jazayeri [2]. Onde o autor discute o
processo de aprendizagem do aluno enquanto realiza
atividades online de ensino, analisando inclusive o resultado
dos alunos em questionários e atividades realizadas por eles
durante os experimentos. Entretanto o autor não faz um
comparativo com os resultados dos alunos em métodos
tradicionais de ensino, não traçando um paralelo do resultado
obtido nas atividades online com as atividades presenciais.
O trabalho de Fox e Patterson [15] também possui
semelhanças com o nosso uma vez que os autores oferecem na
Universidade de Berkeley um curso híbrido (parte presencial
parte online) de Engenharia de Software. Diferentemente de
tal artigo, o nosso trabalho oferece um conteúdo mais
abrangente para uma disciplina de Engenharia de Software.
Como os questionários foram aplicados por todos os
alunos das duas turmas, não possuindo então um grupo de
controle, é possível que os fatos discutidos neste artigo sejam
consequência de algum outro fator não controlado pelo
experimento, como o alto, ou baixo, interesse dos alunos do
grupo escolhido ou então.
Trabalhos como o de Ahmadi e Jazayeri [2] e Ye e colegas
[31] utilizam a educação aberta como complemento ao ensino
de Engenharia de Software. Por outro lado, o nosso trabalho é
focado na comparação do aprendizado em sala de aula com o
aprendizado online com a intenção de avaliar se no futuro um
curso poderá substituir o outro de forma eficiente.
Outro ponto que não podemos desconsiderar é que o
experimento foi realizado somente na matéria de Engenharia
de Software, por isso os seus resultados podem não se repetir
em diferentes matérias, tanto sobre o mesmo tema ou temas
diferentes.
Vários trabalhos anteriores, como o Ye et al. [31] e Potter
e Schots [22], utilizam a educação aberta como complemento
ao ensino de Engenharia de Software utilizando de jogos para
o melhor aproveitamento do conteúdo pelos alunos. Nosso
trabalho, entretanto, é focado na comparação do aprendizado
em sala de aula com o aprendizado online com a intenção de
avaliar se no futuro um curso poderá substituir o outro de
forma eficiente.
Além disso os alunos avaliados no experimento são todos
de uma mesma instituição de ensino e, por isso, possuem o
mesmo perfil, podendo não ser igual ao perfil de alunos de
outras instituições de ensino. Estes alunos podem estar mais,
ou menos, acostumados a estudar por conta própria ou a este
tipo de conteúdo, de acordo com os professores que tiveram
anteriormente no curso, portanto não podemos garantir que os
alunos de outras instituições terão resultados iguais no mesmo
experimento.
47
FEES
[8]
VII. CONCLUSÕES E TRABALHOS FUTUROS
Este artigo avaliou os desempenhos de alunos em um curso
aberto e online para ensino de Engenharia de Software. O
curso online foi proposto a partir de um curso presencial da
Universidade Federal de Minas Gerais (UFMG). Ele é
composto de 44 aulas em vídeo, 140 perguntas em 14
questionários de revisão e tópicos para discussão em formato
de fórum. Apesar de possuir mais de 230 alunos registrados,
este estudo considerou uma amostra de 43 alunos da UFMG
academicamente matriculados no curso presencial e
registrados no curso online.
[9]
[10]
[11]
[12]
[13]
Os resultados deste estudo mostraram que o desempenho
dos alunos nos questionários de revisão melhorou de um
semestre para o outro consideravelmente. Esta melhora pode
ter sido impactada por mudanças pontuais no programa do
curso. Além disso, foi observado que: (i) as questões com
maiores taxas de erros são praticamente as mesmas nos dois
semestres, (ii) foi encontrada baixa correlação entre o
desempenho nos questionários de revisão e o total de vídeos
assistidos pelo aluno, (iii) a correlação entre o desempenho
nos questionários de revisão em relação à frequência em aulas
presenciais varia de baixa a moderada e (iv) a correlação entre
o desempenho nos questionários de revisão e notas nas provas
presenciais também varia de baixa a moderada.
[14]
[15]
[16]
[17]
[18]
Como trabalhos futuros, pretendemos implementar
melhorias no material do curso online, incluir novos
questionários de revisão, e fazer novas avaliações. Uma das
melhorias a ser implementada é criar vídeos mais elaborados
para aproximar a experiência do aluno no ambiente virtual ao
ambiente de sala de aula. Outra dimensão de trabalhos futuros
melhoria é investigar em profundidade as possíveis causas
para altos índices de erro em determinadas questões,
possivelmente buscando apresentar o conteúdo de forma mais
clara para essas questões.
[19]
[20]
[21]
[22]
AGRADECIMENTOS
[23]
Este trabalho recebeu recursos financeiros da Universidade
Federal de Minas Gerais por meio da PROGRAD (Processo
PIQEG2013-41), do CNPq (Processo 485907/2013-5) e da
FAPEMIG (Processos APQ-02532-12 e PPM-00382-14).
[24]
REFERÊNCIAS
[25]
[1]
[2]
[3]
[4]
[5]
[6]
[7]
Open Software Engineering Course. Acessado em 08/07/2014:
http://www.udemy.com/engenharia-de-software-ufmg/
N. Ahmadi, M. Jazayeri. “Analyzing the Learning Process in Online
Educational Game Design: A Case Study”. In 23rd Australian Software
Engineering Conference (ASWEC), pp. 84-93, 2014.
S. Apel, D. Batory, C. Kastner, G. Saake. “Feature-Oriented Software
Product Lines: Concepts and Implementation”. Springer; 2013.
M. A. Ardis and P. B. Henderson. “Software Engineering Education
(SEEd) - Is Software Engineering Ready for MOOCs?”. ACM
SIGSOFT Software Engineering Notes, v. 37, n. 5, 2012.
K. Beck and C. Andres. “Extreme Programming Explained: Embrace
Change”, 2nd Edition. Addison-Wesley, 2004.
B. Boehm. “A Spiral Model of Software Development and
Enhancement”, IEEE Computer, 21(5), 61-72, 1988.
G. Booch, J. Rumbaugh, I. Jacobson. “The Unified Modeling Language
User Guide”, 2 edition. Addison Wesley, 2005.
[26]
[27]
[28]
[29]
[30]
[31]
[32]
48
J. C. Braga. “Diretrizes para o Ensino interdisciplinar de Engenharia de
Software”. Fórum de Educação em Enge. de Software (FEES), 2009.
Coursera. Acessado em 08/07/2014: http://www.coursera.org/
B. Dasarathy, K. Sullivan, D. C. Schmidt, D. H. Fisher, A. Porter. “The
Past, Present, and Future of MOOCs and their Relevance to Software
Engineering”. In Proceedings of the on Future of Software Engineering,
pp. 212-224, 2014.
E. B. Derwin. “Critical Thinking in Online vs. Face-to-Face Higher
Education”. ProQuest, 2008.
edX. Accessed in 08/07/2014: http://www.edx.org/
E. Figueiredo, C. Lobato, K. Dias, J. Leite, C. Lucena. “Um Jogo para o
Ensino de Engenharia de Software centrado na Perspectiva de
Evolução”. Workshop de Educação em Informática (WEI), pp. 37-46,
2007.
E. Figueiredo, J. Pereira, L. Garcia, and L. Lourdes. “On the Evaluation
of an Open Software Engineering Course”. In proceedings of the 44th
Annual Frontiers in Education Conference (FIE). Madrid, Spain, 2014.
A. Fox and D. Patterson. “Crossing the Software Education Chasm”.
Communications of the ACM, 55(5), 44–49, 2012.
E. Gamma, R. Helm, R. Johnson, J. Vlissides. “Design Patterns:
Elements of Reusable Object-Oriented Software”. Addison-Wesley,
Reading, 1995.
R. Jain. “The Art of Computer System Performance Analysis:
Techniques for Experimental Design, Measurement, Simulation and
Modeling”. Wiley and Sons. 1991.
T. R. Liyanagunawardena, A. A. Adams, and S. A. Williams. “MOOCs:
A Systematic Study of the Published Literature 2008-2012”. The
International Review of Research in Open and Distance Learning, 2012.
K. Masters. “A Brief Guide to Understanding MOOCs”. The Internet
Journal of Medical Education, 1(2), 2011.
L. Meirelles, D. Peixoto, E. Monsalve, E. Figueiredo, V. Werneck, J. C.
Leite, C. Pádua. “Uso de Jogos para o Ensino de Engenharia de
Software”. IV Fórum de Educação em Engenharia de Software, São
Paulo, Brasil, 2011.
N. Papaspyrou, S. Retalis, S. Efremidis, G. Barlas, E. Skordalakis.
“Web-based Teaching in Software Engineering”. Advances in
Engineering Software, 30(12), 901-906, 1999.
H. Potter, M. Schots. “InspectorX: Um Jogo para o Aprendizado em
Inspeçao de Software”. Fórum de Educação em Engenharia de Software
(FEES), 2011.
J. Pereira, L. Garcia, E. Figueiredo. “Proposta e Avaliação de Educação
Aberta para Engenharia de Software”. Anais do Fórum de Educação em
Engenharia de Software (FEES), Brasilia, 2013.
D. C. Schmidt and Z. McCormick, “Producing and Delivering a
Coursera MOOC on Pattern-Oriented Software Architecture for
Concurrent and Networked Software”. In Proc. of the Int’l Conference
on Systems, Program., Languages and Applications (SPLASH), 2013.
Software as a Service (SaaS). Acessado em 08/07/2014:
http://www.edx.org/course/uc-berkeley/cs169-1x/software-service/691
I. Sommerville. “Software Engineering”, 9 edition. Pearson, 2010.
N. Tillmann, J. Halleux, T. Xie, S. Gulwani, J. Bishop. “Teaching and
Learning Programming and Software Engineering via Interactive
Gaming”. In Proc. of the International Conference on Software
Engineering (ICSE), pp. 1117-1126, 2013.
Udacity. Acessado em 08/07/2014: http://www.udacity.com
Udemy. Acessado em 08/07/2014: http://www.udemy.com/
T. Xie, N. Tillmann, J. De Halleux. “Educational Software Engineering:
Where Software Engineering, Education, and Gaming Meet”. In Int’l
Workshop on Games and Software Engineering (GAS), pp. 36-39, 2013.
E. Ye, C. Liu, J. A. Polack-Wahl. “Enhancing Software Engineering
Education using Teaching Aids in 3-D Online Virtual Worlds”. Frontiers
in Education (FIE), 2007.
C. Wohlin, P. Runeson, M. Host, M. C. Ohlsson, B. Regnell, A.
Wesslen. “Experimentation in Software Engineering”, 2nd edition.
Springer, 2012.
FEES
ANEXO I TELA PRINCIPAL DO CURSO ONLINE DE ENGENHARIA DE SOFTWARE
49
FEES
Ambiente Integrado como Apoio ao Ensino da
Engenharia de Software
Simone Vasconcelos Silva
Instituto Federal Fluminense (IFFluminense)
Núcleo de Engenharia de Software (NES)
Rio de Janeiro/Brasil
[email protected]
Aline Pires Vieira de Vasconcelos
Instituto Federal Fluminense (IFFluminense)
Núcleo de Engenharia de Software (NES)
Rio de Janeiro/Brasil
[email protected]
Abstract—This paper proposes the use of an Integrated
Environment, designed to automate the processes of Software
Engineering (ES), as an aid to teaching and learning in the
area of ES in undergraduate and postgraduate courses. The
emphasis of this paper is the use of two tools of the
Environment, Integrated Management and Fermine, related
to the processes of Project Management and Requirements
Engineering. This environment can bring benefits to teaching
and learning in the area of ES, both in academic and
professional contexts. In the academic context, teaching can
be awarded by using the tools in the classroom, through case
studies that represent real cases. In the industrial context, the
tools can facilitate the training of new employees in the
processes adopted, and it can be used information from real
projects registered in the environment. It is also being
developed in this Integrated Environment, a "3D Simulation"
tool devoted to simulate real scenarios regarding the ES
procedures, raising the quality of the teaching-learning
process in this area.
software; gerência de projetos; gerência de requisitos; ensinoaprendizado
I. INTRODUÇÃO
Atualmente, a sociedade encontra-se cada vez mais
dependente do uso de software e esta dependência ocorre
em diversos aspectos, tais como: pessoais, acadêmicos e
profissionais. Portanto, a qualidade do software é essencial
para melhor atender às necessidades do mundo moderno.
Desta forma tornou-se crescente e inevitável a busca por
novas metodologias e ferramentas específicas para
melhoria do ensino da Engenharia de Software (ES).
A preocupação com a educação em ES reflete a
demanda por profissionais qualificados, as dificuldades de
abstração, a necessidade de lidar com escalabilidade e
confiabilidade de sistemas na indústria [1].
O processo de ensino-aprendizagem de ES tem sido
amplamente analisado e discutido por diversos autores [2]
[3] [4] [5] [6] [7] [8]. Grande parte destes estudos apontam
para o seguinte problema generalizado: no ambiente
organizacional a área de ES é extremamente prática e no
ambiente acadêmico a área de ES é predominantemente
teórica.
Keywords—integrated environment; software engineering;
project management; requirements management; teachinglearning
Resumo—Este artigo propõe a utilização de um Ambiente
Integrado, desenvolvido para automatizar os processos da
Engenharia de Software (ES), como um auxílio ao ensinoaprendizagem da área de ES em cursos de graduação e de
pós-graduação. A ênfase do artigo está no uso de duas das
ferramentas do ambiente, Gestão Integrada e Fermine,
relacionadas aos processos de Gerência de Projetos e de
Gerência de Requisitos. Este ambiente pode trazer benefícios
ao ensino-aprendizagem na área de ES, tanto no contexto
acadêmico quanto no contexto profissional. Na academia, o
ensino pode ser contemplado com o uso das ferramentas em
sala de aula, através de estudos de caso que representem casos
reais. No contexto industrial, as ferramentas podem facilitar a
capacitação de novos funcionários nos processos adotados,
podendo-se utilizar as informações dos projetos reais
cadastrados nas mesmas. Encontra-se em desenvolvimento,
ainda, neste Ambiente Integrado, “Simuladores 3D” com o
objetivo de simular cenários reais referentes aos processos de
ES, elevando a qualidade do processo de ensino-aprendizagem
nesta área.
Palavras-Chave—ambiente
integrado;
engenharia
O processo tradicional de ensino de ES consiste na
apresentação de conceitos relevantes e indispensáveis para
o aprendizado. Embora essencial, pesquisas mostram que
apenas esse conhecimento não é suficiente para que o aluno
esteja preparado para a realidade de mercado,
principalmente com relação à tomada de decisões em
ambientes dinâmicos [6].
A aula teórica e os trabalhos abordados em sala de aula,
em sua maioria, não refletem a realidade do mundo
profissional, fazendo com que os alunos não consigam
visualizar claramente a utilidade e a aplicabilidade dos
conhecimentos adquiridos em sala de aula em relação ao
ambiente organizacional.
A literatura técnica mundial registra várias discussões
sobre problemas no processo de ensino-aprendizagem na
área de ES, podendo ser facilmente observada a
necessidade de uma maior integração entre as disciplinas
da área [9]. Alguns trabalhos elaboraram pesquisas
relacionadas ao ensino da ES, podendo ser divididos em
dois grupos: o primeiro diz respeito a uma pesquisa de
de
50
FEES
opinião realizada com alunos e ex-alunos de disciplinas da
área de ES em mais de 30 instituições brasileiras; o
segundo diz respeito a uma revisão sistemática de diversos
trabalhos abordando pesquisas sobre o ensino de ES. Podese citar alguns dos principais problemas no processo de
ensino-aprendizagem em ES encontrados nestas pesquisas,
tais como [9][10]:
•
A existência de grande distância entre o que se
ensina e a realidade do mercado de trabalho;
•
Os discentes têm pouco interesse pelas aulas
extremamente teóricas;
•
A maioria dos cursos de ES têm significativas
taxas de evasão e reprovação;
•
Índices de aprendizagem
questionáveis;
•
Pouca ênfase ao trabalho em grupo e pouca prática
de interdisciplinaridade;
•
Em geral, o que se ensina e se aprende em uma
disciplina não é apropriado pela comunidade
como um patrimônio intelectual para uso futuro;
•
Pouca ou nenhuma interação entre professores e
alunos fora da sala de aula.
efetiva
determinadas funções e resolverem possíveis problemas
que encontrarem em um cenário real [11]. Pesquisas na
área de treinamento e educação sugerem o uso de jogos no
ensino, pois estes podem engajar o estudante, reforçando
conceitos através da prática, e aprofundando os
conhecimentos [12].
A utilização de simulação e jogos educativos tem sido
abordada em muitos trabalhos na literatura, onde a
principal vantagem abordada na utilização de jogos como
auxílio no aprendizado é a de que os mesmos estimulam e
motivam o aluno através da simulação de diversas
situações reais do desenvolvimento [13].
O envolvimento emocional de um estudante aumenta
conforme o entretenimento, e assim ocorre a variação de
estímulos, o que ajuda o estudante a reter novos
conhecimentos, e para isto as aulas palestradas não são
suficientes [14].
bastante
A pedagogia que utiliza o jogo como ferramenta de
apoio ao processo de aprendizagem oferece vantagens
como ludicidade, cooperação, participação, prazer e
motivação [15].
Na ES, o desenvolvimento e uso de jogos vem
crescendo cada vez mais, visto que ainda há um déficit
grande nesta área, apesar da demanda por treinamento e
simulação de processos de ES [8].
Para apoiar o ensino, este trabalho propõe a utilização
de um Ambiente Integrado que possui ferramentas capazes
de proporcionar melhorias no processo de ensinoaprendizagem de diversas disciplinas da área de ES. A
ênfase está na utilização de ferramentas para o ensino
prático dos conteúdos das disciplinas relacionadas à
Gerência de Projetos e à Gerência de Requisitos. Além
disso, está sendo desenvolvido um Simulador 3D para este
ambiente, com o intuito de simular cenários reais, gerando
melhoria contínua do aprendizado.
Na área da ES, algumas organizações para minimizar a
curva de aprendizado de seus recém-contratados, junto aos
processos já estabelecidos nas equipes, têm investido no
treinamento e capacitação prévia nas práticas dos processos
adotados. Com isso, o uso de jogos como mecanismo
complementar
de
aderência
de
conceitos
e
desenvolvimento de habilidades está se tornando cada vez
mais importante dentro dos processos educativos
organizacionais. O jogo serve assim como forma
complementar ao treinamento tradicional, ajudando a fixar
conceitos de forma lúdica e criativa [16].
Partindo desta Introdução, o restante do artigo está
organizado da seguinte forma: a Seção 2 aborda o uso de
ferramentas e simuladores como facilitadores do processo
de ensino-aprendizagem de ES; a Seção 3 apresenta o
Ambiente Integrado, assim como suas ferramentas para
Gerência de Projetos e Gerência de Requisitos; a Seção 4
apresenta como estas ferramentas podem auxiliar no
processo de ensino-aprendizagem; e a Seção 5 apresenta as
considerações finais deste trabalho.
Diversos trabalhos foram realizados para analisar o uso
de ferramentas (comerciais e acadêmicas) para apoio ao
ensino-aprendizagem da Gerência de Projetos e Gerência
de Requisitos, podendo-se citar algumas delas, tais como:
eGroupware e GPAC [17], DotProject [18], Case Gemetrics
[19] [20].
Pode-se citar alguns ambientes de simulação/jogos para
auxílio no processo de ensino-aprendizagem da área de ES,
onde muitos estão relacionados a Gerência de Projetos e
Gerência de Requisitos: SESAM [2], Incredible Manager
[21], Virtual Team [22], SimSE [5], SPARSE [23],
Kallango [16], Planegeri [24], SimProject [25], RE-O-Poly
[26], Quantum [27], Guess what we want [14], SimSE
[28], Ilha de Requisitos [29], UbiRE [30], SimulES-W
[31], SimVBSE [32].
II. FERRAMENTAS E SIMULADORES/JOGOS PARA
O ENSINO EM ES
Diversas ferramentas, tanto as desenvolvidas com fins
comerciais e disponibilizadas no mercado quanto as
desenvolvidas através de projetos acadêmicos e de
pesquisa) podem ser utilizadas para apoio ao ensinoaprendizagem na área de ES, onde muitas destas
ferramentas estão relacionadas com os processos de
Gerência de Projetos e de Gerência de Requisitos.
III. O AMBIENTE INTEGRADO
A simulação de modelos em computador pode ser
utilizada com diferentes objetivos: produzir dados e
situações que conduzam a tomada de decisões reais
imediatas, visando solucionar diferentes problemas; e
capacitar e treinar pessoas de maneira mais rápida, de
forma que estas se tornem mais aptas a realizarem
O Ambiente Integrado é desenvolvido pelo Núcleo de
Engenharia de Software do Instituto Federal Fluminense
(IFFluminense) por pesquisadores e alunos de iniciação
científica que recebem apoio financeiro do próprio instituto
e do CNPq. Este ambiente possui ferramentas que já foram
utilizadas em projetos de software mantidos pelo
51
FEES
Ministério da Educação (MEC) através da SETEC
(Secretaria de Educação Profissional e Tecnológica) [33],
pelo Ministério das Comunicações (MC) através do projeto
Formação GESAC [34] e atualmente encontram-se em uso
no IFFluminense através de diversos campus e diretorias.
quais permitem a realização de correções quando
houver desvios significativos no desempenho do
mesmo. Também proporciona a modelagem dos
processos da organização com o objetivo principal
de integrar os processos aos projetos [42] [43];
Atualmente, o Ambiente Integrado é considerado um
ambiente colaborativo composto de um conjunto de
ferramentas inter-relacionadas com o objetivo de
automatizar e integrar os seguintes processos para apoio ao
desenvolvimento de software: Gerência de Requisitos,
Gerência de Projetos, Gerência de Configuração, e
Verificação e Validação. Estas ferramentas foram
desenvolvidas seguindo os princípios do modelo MPS.Br
[35].
As ferramentas desenvolvidas têm como base inicial a
plataforma Redmine [36], a qual é desenvolvida através do
framework Ruby on Rails, possuindo como características
principais o código aberto, a facilidade de extensão e
configurações personalizadas. Estas características
facilitaram a implementação das ferramentas do Ambiente
Integrado e para tal foram elaboradas adaptações através de
configurações, implementação de formulários eletrônicos e
de plugins específicos para atender de forma satisfatória
todos os processos envolvidos . Os plugins desenvolvidos
se integram no ambiente juntamente com os demais
plugins nativos da própria plataforma.
Pode-se observar na Figura 1 que a metodologia
utilizada para o desenvolvimento do Ambiente Integrado
foi composta pelos seguintes métodos e guias: modelagem
de processos com BPMN (Business Process Modeling
Notation) [37]; MPS.Br (Melhoria do Processo de
Software) [35]; PMBOK (Project Management Body of
Knowledge) [38]; Project Model Canvas [39]; ISO/IEC
25000 e Metodologias Ágeis [40].
•
Fermine: atende à Gerência de Requisitos, visando
buscar técnicas bem definidas para elicitar,
especificar, validar, documentar e rastrear
requisitos [44] [45];
•
RedSCoM: atende à Gerência de Configuração,
fornecendo subsídios para identificar e
documentar as características físicas e funcionais
de um item de configuração, controlar as
alterações nessas características, armazenar e
relatar o processamento das modificações e o
estágio da implementação, além de verificar a
compatibilidade com os requisitos especificados
[46];
•
WiseTest: atende parcialmente ao processo de
Validação através dos Testes Funcionais e possui
como principal funcionalidade a geração
automática de casos de teste [45];
•
QualiPSoft: proporciona a avaliação da qualidade
de produtos de software através da ISO/IEC
25000;
•
TotalMeasure: atende parcialmente ao processo de
Medição, contendo funcionalidades para cálculo
de ponto por função e por caso de uso.
A. Ferramenta Gestão Integrada
A ferramenta Gestão Integrada surgiu da necessidade das
organizações, que trabalham com projetos, de integrar as
informações através de um único ambiente, onde o
planejamento seja realizado de forma colaborativa, com
reaproveitamento de dados, aumento da produtividade e
facilidade de monitoramento. Esta necessidade foi
fortalecida pela ausência de ferramentas que atendessem
por completo estas demandas. Suas funcionalidades
contemplam os seguintes métodos e guias [42] [43]:
•
As áreas do conhecimento do PMBOK através de
plugins e formulário eletrônicos, além de fornecer
todos os resultados esperados para o processo
Gerência de Projetos (GPR) do MPS.Br (Melhoria
do Processo de Software Brasileiro) no nível G;
•
Ambiente para o Project Model Canvas (integrado
e com geração automática dos formulários
eletrônicos necessários às áreas do PMBOK). E
também este mesmo ambiente no modo Quadro
Inteligente, ou seja, os componentes (canvas, postits e stakeholders) são manipulados através de
movimentos e toques na superfície do quadro
inteligente. Este modo facilita a elaboração do
plano do projeto de forma interativa e colaborativa
através da participação das partes interessadas;
•
Gerência de requisitos e tarefas através da
metodologia ágil abordada no Lean utilizando o
Fig. 1. Metodologia Elaborada para o Ambiente Integrado (Adaptado de
[41])
De acordo com a Figura 1, as ferramentas que
compõem o Ambiente Integrado são:
•
Gestão Integrada: atende à Gerência de Projetos,
cujo objetivo é estabelecer e manter planos que
definem as atividades, prazos, recursos e
responsabilidades do projeto. Bem como prover
informações sobre o andamento do projeto, as
52
FEES
método kanban;
•
•
Modelagem de processos através do BPMN
(Business Process Modeling Notation) de forma
integrada aos projetos.
Esta ferramenta é um projeto que se encontra em
constante melhoria, logo estão sendo desenvolvidas
funcionalidades que agregam o framework do Scrum,
simuladores 3D para apoio ao aprendizado e mapeamento
do planejamento estratégico integrado aos processos e
projetos. Muitas das funcionalidades da ferramenta deram
origem a diversos artigos científicos e monografias de
cursos de graduação e pós-graduação.
IV. FERRAMENTAS DO AMBIENTE INTEGRADO NO
AUXÍLIO AO PROCESSO DE ENSINOAPRENDIZAGEM
O Ambiente Integrado e suas ferramentas são oriundos
de projetos de pesquisa, tornando-se possível a integração
entre as pesquisas realizadas pelo Núcleo de Engenharia de
Software e o processo de ensino-aprendizagem das
disciplinas relacionadas à ES nos cursos de graduação e de
pós-graduação do IFFluminense. Ou seja, o ambiente
desenvolvido para automatizar os processos da ES para as
organizações de software no âmbito profissional também
pode ser perfeitamente utilizado para auxiliar o ensino da
ES no âmbito acadêmico.
A referida ferramenta recebeu o prêmio de melhor
projeto do ano de 2013 na categoria inovação rela revista
Mundo Project Management [47].
B. Ferramenta Fermine
A Fermine é uma ferramenta de apoio ao processo de
Gerência de Requisitos capaz de realizar a manutenção de
diversos artefatos que contemplam a Engenharia de
Requisitos (ER). A ferramenta disponibiliza um conjunto
de formulários eletrônicos que padronizam e otimizam o
preenchimento de diversos documentos da ER. Suas
funcionalidades são [44] [45]:
•
Até o momento, duas das ferramentas do Ambiente
Integrado, Gestão Integrada e Fermine, já foram utilizadas
em sala de aula para facilitar o processo de ensinoaprendizagem, tendo sido utilizadas nas disciplinas e
monografias relacionados à Gerência de Projetos e à
Gerência de Requisitos, nos cursos de Bacharelado em
Sistemas de Informação e Pós-Graduação em Análise e
Gestão de Sistemas de Informação do IFFluminense.
Atores: são cadastrados, sendo possível definir
suas interfaces de comunicação com o sistema
(ICS), informando inclusive novos tipos de ICS
além dos já existentes. A definição da ICS para
cada ator poderá ser utilizada para o cálculo de
métricas referentes aos casos de uso. O ator
representa um artefato reutilizável, que depois de
criado, pode estar associado a um ou mais projetos
no ambiente;
•
Requisitos: cadastro de requisitos funcionais e
não-funcionais, além de checklists de validação da
descrição de requisitos;
•
Regras de negócio, Glossário e Mensagens;
•
Casos de uso (CDU): no cadastro do CDU é
possível definir pré-condições, fluxos de eventos,
pós-condições, exceções etc., além de associar
atores, regras de negócio, mensagens, requisitos,
casos de uso incluídos (includes) e estendidos
(extends). Na descrição resumida do caso de uso,
os termos do glossário são exibidos como links
que permitem consultar suas definições. É
possível ainda no caso de uso, adicionar imagens
dos protótipos das telas e associar tabela de
especificação de dados;
•
Rastreabilidade entre os artefatos: muito útil na
avaliação dos impactos que mudanças nos
requisitos podem ocasionar e apoiando a
identificação de inconsistências;
•
Geração de cenários: cadastro de cenários com o
objetivo de possibilitar testes automatizados TDD
(Test Driven Development), esta funcionalidade
encontra-se em desenvolvimento;
Acompanhamento dos requisitos: é possível
acompanhar e alterar o status do requisito de
acordo com a execução das tarefas relacionadas ao
mesmo. Esta funcionalidade encontra-se em
desenvolvimento e permite total integração entre a
Fermine e a Gestão Integrada.
A. Ensino da Gerência de Projetos com apoio da
ferramenta Gestão Integrada
Este processo ocorre através do uso da ferramenta
Gestão Integrada para elaborar/simular projetos de
desenvolvimento de software que são utilizados como
estudos de caso nas disciplinas e nas monografias.
O método utilizado é semelhante para graduação e pósgraduação, onde são elaborados estudos de caso de forma
que estes se aproximem o máximo possível da realidade
das organizações que desenvolvem software. Para cada
aula teórica encontra-se associada uma aula prática, onde
os conceitos aprendidos são aplicados na ferramenta,
elaborando-se um projeto passo a passo.
As aulas práticas com uso da ferramenta são divididas
nas seguintes etapas:
53
•
Etapa 1 - divisão da turma em grupos, onde cada
grupo recebe um estudo de caso e seleciona um
aluno para o perfil de gerente do projeto. Após
este processo, a ferramenta é apresentada aos
alunos;
•
Etapa 2 - criação do projeto, stakeholders e seus
perfis;
•
Etapa 3 - elaboração de uma síntese do projeto
com o Project Model Canvas;
•
Etapa 4 - elaboração do Termo de Abertura de
Projeto;
•
Etapa 5 - elaboração da Estrutura Analítica do
Projeto (EAP);
FEES
•
Etapa 6 - elaboração do cronograma e orçamento;
•
Etapa 7 - elaboração da matriz de
responsabilidades e gestão das partes interessadas;
•
Etapa 8 - elaboração do plano de comunicação;
•
Etapa 9 - elaboração do plano de riscos e de
mitigação;
•
Etapa 10 - controle das tarefas através de diversas
formas e métodos;
•
Etapa 11 – tratamento das aquisições e plano de
qualidade do projeto;
•
Etapa 12 - elaboração das lições aprendidas e
problemas encontrados;
•
Etapa 13 - avaliação do uso da ferramenta pelos
alunos.
Em relação ao uso da ferramenta Gestão Integrada na
sala de aula pode-se relatar que cerca de 35 alunos, que
utilizaram a ferramenta durante as aulas (uma turma do 6o
período da graduação com 15 alunos e uma turma da pósgraduação com 20 alunos), demonstraram um aumento no
interesse pela disciplina de Gerência de Projetos após a
inserção do uso da ferramenta, o que gerou uma maior
procura pelo tema para elaboração de monografias e
artigos.
Fig. 3. Uso da ferramenta para elaboração de uma EAP (Estrutura
Analítica do Projeto) na turma de Pós-Graduação
Na turma da pós-graduação com início em 2010 não foi
utilizada a ferramenta em sala de aula, a mesma foi inserida
a partir da turma com início em 2012. Esta última turma
apresentou uma maior procura por assuntos relacionados a
Gerência de Projetos para elaboração das monografias. Este
fato pode ser observado comparando o número das
monografias da turma de 2010 com este mesmo indicador
da turma de 2012. Em relação as monografias defendidas
pela primeira turma, de 7 trabalhos apenas 2 foram
relacionados a disciplina de Gerência de Projetos. Em
relação as monografias em desenvolvimento pela segunda
turma, de 11 trabalhos foram apontados 6 relacionados a
disciplina. Pode-se perceber que o percentual de 28,57%
referente ao ano de 2010 subiu para 54,55% em relação ao
ano de 2012.
Na turma da graduação, onde a carga horária da
disciplina é maior do que na pós-graduação, os projetos
desenvolvidos pelos grupos foram transformados em
artigos de forma integrada com a disciplina de Qualidade
de Software, dando origem a 5 trabalhos. Destes artigos, 3
foram publicados: dois artigos na Revista Perspectivas
Online [48] [49] e um artigo no WAMPS (Workshop Anual
do MPS.Br) [50]. A utilização da ferramenta em sala de
aula pode ser observada nas Figuras 2 e 3.
B. Ensino da Gerência de Requisitos com auxilio da
ferramenta Fermine
Este processo se dá através do uso da ferramenta
Fermine para elaborar/simular a Gerência de Requisitos do
processo de desenvolvimento de software, utilizando
estudos de caso próximos da realidade das organizações.
O processo ocorre de forma muito semelhante ao ensino
da Gerência de Projetos, onde a cada aula prática os alunos
aplicam na ferramenta os conceitos aprendidos nas aulas
teóricas, gerando passo a passo todos os artefatos
necessários.
As aulas práticas com uso da ferramenta são divididas
nas seguintes etapas:
Fig. 2. Uso da ferramenta para elaboração de um plano de projeto através
do Project Model Canvas na turma de Pós-Graduação
54
•
Etapa 1 - divisão da turma em grupos, onde cada
grupo recebe um estudo de caso. Após este
processo, a ferramenta é apresentada aos alunos;
•
Etapa 2 - cadastro dos atores e regras de negócio;
•
Etapa 3 - cadastro dos requisitos funcionais e não
funcionais;
FEES
•
Etapa 4 - cadastro das mensagens e glossário;
•
Etapa 5 - elaboração dos casos de uso;
•
Etapa 6 - elaboração dos protótipos (em outra
ferramenta);
•
Etapa 7 - elaboração dos diagramas da UML
(Unified Modeling Language) (em outra
ferramenta);
•
Etapa 8 - associação dos arquivos referentes aos
protótipos e diagramas aos casos de uso
cadastrados na Fermine;
•
Etapa 9 - verificação da rastreabilidade;
•
Etapa 10 - avaliação do uso da ferramenta pelos
alunos.
informações cadastradas na ferramenta, assim como
facilitar o aprendizado dos conceitos e práticas da Gerência
de Requisitos.
Este simulador 3D será composto de diversas
funcionalidades, podendo citar as consideradas principais:
Em relação ao uso da ferramenta Fermine na sala de
aula, a mesma foi utilizada na disciplina de Análise
Orientada a Objetos do curso de graduação. Pode-se relatar
que as turmas (totalizando 32 alunos) se mostraram
satisfeitas com o uso da ferramenta. Alguns alunos
solicitaram a inserção de mais recursos visuais e a
possibilidade de elaborar os diagramas da UML na própria
ferramenta.
Foi elaborada uma pesquisa de opinião, através de
questionários, com uma das turmas da disciplina de
Análise Orientada a Objetos que não utilizou a Fermine
durante as aulas. Esta turma (15 alunos) foi convidada a
documentar os artefatos necessários a Gerência de
Requisitos (atores, requisitos funcionais e não-funcionais,
casos de uso, mensagens e regras de negócio) de um
pequeno estudo de caso utilizando a ferramenta. O objetivo
deste estudo foi verificar os pontos positivos e negativos
em relação ao uso da ferramenta, na visão do aluno que já
cursou a disciplina sem a ajuda de ferramentas para
documentação destes artefatos.
•
Cenários simulando o ambiente organizacional:
semelhante ao ambiente visual de um jogo, onde
os alunos poderão interagir com um ambiente
muito próximo ao de uma organização de
desenvolvimento de software e participarão das
tomadas de decisões de acordo com os perfis
adotados;
•
Objetos virtuais de aprendizagem: são utilizados
para representar de forma gráfica e visual os
conceitos da disciplina;
•
Vídeos interativos abordando conceitos e práticas:
vídeos contendo objetos de aprendizagem, textos e
áudio para facilitar o aprendizado do aluno;
•
Elaboração virtual e automatizada de documentos:
utilizado nos cenários e também de forma
individual com o objetivo de demonstrar para o
aluno o preenchimento dos documentos
necessários a prática de cada disciplina;
•
Stakeholders virtuais: representam virtualmente os
alunos na participação nos cenários, na
manipulação dos objetos virtuais e na elaboração
virtual dos documentos.
Em ambiente organizacional este simulador também
poderá ser de grande importância para a capacitação dos
novos funcionários, pois poderá facilitar o aprendizado dos
processos utilizados pela organização.
VI. CONSIDERAÇÕES FINAIS
Pode-se concluir que a utilização do Ambiente Integrado
como facilitador do ensino-aprendizagem, através de suas
ferramentas Gestão Integrada e Fermine, para as disciplinas
relacionadas aos processos de Gerência de Projetos e
Gerência de Requisitos, gerou os seguintes benefícios ao
ensino da ES:
Com o resultado desta pesquisa foi possível verificar que
mais de 80% dos alunos apontaram como pontos positivos
no uso da ferramenta os seguintes itens: maior motivação;
maior satisfação com as aulas; maior conhecimento prático
da disciplina; maior proximidade do mercado profissional;
maior rapidez na execução dos exercícios práticos; e maior
facilidade para gerenciar as informações. Os pontos
negativos mais citados foram: no software é necessário
seguir o padrão dos formulários e na forma manual a
escrita é mais livre; dependência do uso da ferramenta; e a
necessidade, mesmo que seja pequena, de aprender a
utilizar a ferramenta.
C. Simulador 3D
Encontra-se em desenvolvimento, no Ambiente
Integrado, um simulador 3D que contempla as
funcionalidades das ferramentas Gestão Integrada e
Fermine. O objetivo deste simulador é elevar cada vez mais
a qualidade do ensino-aprendizado dos diversos métodos e
guias utilizados para Gerência de Projetos através das
55
•
As aulas foram dividas em teoria e prática;
•
A prática exercida aproximou-se da realidade do
mundo profissional;
•
O aprendizado foi facilitado através da vivência
prática dos conceitos abordados;
•
Foi incentivada a tomada de decisões, por parte
dos alunos, durante as aulas;
•
Gerou motivação e satisfação nas aulas;
•
Proporcionou trabalhos em grupo;
•
Resultou no aumento do número de monografias e
artigos relacionados a gerência de projetos e
FEES
Relatório Técnico. UFPB/CCEN, João Pessoa.
[10] Paiva, S. R. (2011) “Pesquisa Nacional sobre Ensino de Engenharia
de Software”. Relatório Técnico. UFPB/CCEN, João Pessoa.
[11] Hoover, S. V., Perry, R. F. (1989) “Simulation: a problem-solving
approach”. Massachusetts: Addison-Wesley, EUA.
[12] El-shamy, S. (2001) “Training Games: Everything You need to
Know About Using Games to Reinforce Learning”. Stylus
Publishing, Virginia.
[13] Law, A. M., Kelton, W. D. (2000) “Simulation Modeling and
Analysis”. 3 ed.: McGraw-Hill.
[14] Alexander, M.; Beatty, J. (2008) “Effective Design and Use of
Requirements Engineering Training Games”. Requirements
Engineering Education and Training, REET08, Barcelona.
[15] Borges, C. J. (2005) “O Lúdico nas Interfaces das Relações
Educativas”. Revista de Pedagogia, n. 12 vol. 6.
[16] Campos, A.M.C., Signoretti, A., Lima, P., Luis, E., Fontes, M.
(2011) “Um jogo voltado à prática de gerenciamento de projetos”.
XXII Simpósio Brasileiro de Informática na Educação - XVII
Workshop de Informática na Educação, Aracaju.
[17] Schmitt, M. A. R. (2011) “Ferramentas de gerência de projetos como
recurso de aprendizagem”. Tese de Doutorado em Informática na
Educação. Universidade Federal do Rio Grande do Sul, Porto
Alegre.
[18] Leitão, V. L., Andrade, R. M. de C. (2008). Utilizando uma
ferramenta de gerência de projetos para auxiliar no ensino de
Engenharia de Software. Simpósio Brasileiro de Engenharia de
Software – Fórum de Educação em Engenharia de Software
(FEES'08).
[19] Vavassori, B. F., Souza, E. W. De, Fiamoncini, J. C. (2001)
“Ferramenta case gemetrics: aplicado ao ensino de conceitos de
gerenciamento de projetos e métrica de software”. III Workshop de
Investigadores en Ciencias de la Computación. Rede de
Universidades con Carreras en Informática (RedUNCI).
[20] Vavassori, B. F., Souza, E. W. De, Fiamoncini, J. C. (2001)
“Ferramenta Case para Gerenciamento de Projetos e Métricas de
Software”. XV Simpósio Brasileiro de Engenharia de Software.
[21] Dantas, A. R., Barros, M. O., Werner, C.M.L. (2004) “A SimulationBased Game for Project Management Experiential Learning”.
Proceedings of the International Conference on Software
Engineering and Knowledge Engineering, Canada.
[22] Guedes, M. S. (2006) "Um Modelo Integrado Para Construção de
Jogos de Computador Aplicado à Capacitação em Gestão de
Projetos". Dissertação de Mestrado de Ciência da Computação,
Universidade Federal de Pernambuco, Recife.
[23] Souza, M.M., Resende, R.F., Prado, L.S., Fonseca, E.F., Carvalho,
F.A., Rodrigues, A.D. (2010) “SPARSE: Um Ambiente de Ensino e
Aprendizado de Engenharia de Software Baseado em Jogos e
Simulação”. XXI Simpósio Brasileiro de Informática na Educação,
João Pessoa.
[24] Prikladnicki, R., Rosa, R., Kieling , E. (2007) “Ensino de Gerência
de Projetos de Software com o Planageri”. Workshop em
Informática na Educação (SBIE ) - XVIII Simpósio Brasileiro de
Informática na Educação.
[25] Hood, J. D.; Hood, C. S. (2006) “Teaching software project
management using simulations”. Proceedings of ACM’s Eleventh
Annual Conference on Innovation and Technology in Computer
Science Education (ItiCSE). New York.
[26] Smith, R.; Gotel O. (2008) “RE-O-Poly: A Customizable Game to
Introduce and Reinforce Requirements Engineering Good
Practices”. Departament of Computer Science, Pace University,
EUA.
[27] Knauss, E., Schneider, K., Stapel, K. (2008) “A Game for Taking
Requirements Engineering More Seriously”. Leibniz Universität
Hannover, Germany.
[28] Navarro, E.; Hoek, A. (2009) “Multi-Site Evaluation of SimSE”.
Proceedings of the 40th ACM Technical Symposium on Computer
Science Education, EUA.
requisitos;
•
Incentivou aos alunos a participarem de projetos
de pesquisa na área de Engenharia de Software.
Pode-se relatar, também que, uma importante
contribuição do uso do ambiente para o ensino da ES é a
facilidade proporcionada ao aluno na utilização de diversos
processos (Figura 1) no único ambiente, onde é possível o
reaproveitamento das informações através da integração
entre as ferramentas.
Como continuidade deste trabalho pretende-se:
•
Elaborar uma análise mais detalhada do uso das
ferramentas de Gestão Integrada e Fermine em
sala de aula utilizando as novas funcionalidades
que encontram-se em desenvolvimento;
•
Apresentar dados que mostrem a melhoria do
desempenho acadêmico dos alunos nas
disciplinas, e a relação do desempenho com o
Ambiente Integrado;
•
Elaborar um estudo do uso destas ferramentas
para capacitação em ambiente organizacional;
•
Concluir o desenvolvimento dos simulares 3D
para estas ferramentas e analisar os benefícios
obtidos no ensino-aprendizagem em sala de aula e
também no ambiente organizacional;
•
Utilizar as demais ferramentas do ambiente em
sala de aula e analisar os resultados.
REFERÊNCIAS
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
Dantas, A., Silva, I. (2005) “Uma Introdução à Computação Ubíqua
e seus Desafios para a Engenharia de Software”. Relatório Técnico,
PESC/COPPE/UFRJ, Rio de Janeiro.
Drappa, A., Ludewig, J. (2000) “Simulation in Software Engineering
Training” in Proceedings of the 22nd International Conference on
Software Engineering. ACM.
Pfahl, D., Laitengerger, O., Gunther R., Dorsch, J., Krivobokova, T.
(2004) “Evaluating the learning effectiveness of using simulations in
software project management education: results from a twice
replicated experiment”. Information and Software Technology.
Baker, A., Navarro, E. e Hoek, A. (2006) “An Experimental Card
Game for TeachingSoftware Engineering Processes”. Journal of
Systems and Software.
Navarro, E. (2006) “SimSE: A Software Engineering Simulation
Environment for Software Process Education”. Tese de Doutorado
do Departamento de Informática da Universidade da Califórnia,
Irvine.
Damian, D., Hadwin, A., Al-Abni, B. (2006) “Instructional Design
and Assessment Strategies for Teaching Global Software
Development: A Framework” in Proceedings of the International
Conference on Software Engineering. ACM.
Chen, W., Wu, W., Wang, T., Su, C. (2008) “Work in Progress – A
Game-based Learning System for Software Engineering Education”.
IEEE Frontiers in Education Conference.
Werner, C., Rodrigues, C., Santos, R., Costa, H., Santo, R., Castro,
W. (2009) “Projeto Tec3ES: Tecnologias e Estratégias para
Educação em Engenharia de Software”. XVII Congresso
Iberoamericano de Educação Superior em Computação, Pelotas.
Paiva, S. R. (2011) “Uma Revisão Sistemática das Pesquisas
Realizadas sobre a Melhoria no Ensino de Engenharia de Software”.
56
FEES
[29] Thiry, M., Zoucas, A., Gonçalves, R. (2010) “Promovendo a
Aprendizagem de Engenharia de Requisitos de Software Através de
um Jogo Educativo”. XXI Simpósio Brasileiro de Informática na
Educação , João Pessoa.
[30] Campos, B., Lima T., Santos, R., Werner, C., Limoeiro, F. (2011)
“Experiência de Projeto e Desenvolvimento de Jogo para Ensino de
Engenharia de Requisitos para Sistemas Ubíquos”. XXII Simpósio
Brasileiro de Informática na Educação - XVII Workshop de
Informática na Educação, Aracaju.
[31] Monsalve, E. S. (2010), “Construindo um Jogo Educacional com
Modelagem Intencional Apoiado em Princípios de Transparência”,
Dissertação de Mestrado, PUC–Rio.
[32] Jain, A. e Boehm, B. (2006). “SimVBSE: Developing a Game for
Value-Based Software Engineering. Proceedings 19th Conference on
Software Engineering Education and Training”.
[33] BRASIL (2014). Ministério da Educação (MEC) - Secretaria de
Educação Profissional e Tecnológica (SETEC). Disponível em
http://portal.mec.gov.br/index.php?
option=com_content&view=article&id=286&Itemid=353
[34] BRASIL (2014). Ministério das Comunicações - Programa Governo
Eletrônico - Serviço de Atendimento ao Cidadão (Gesac).
Disponível em http://www.comunicacoes.gov.br/gesac
[35] SOFTEX - Associação Para Promoção da Excelência do Software
Brasileiro (2012) “MPS.Br – Guia Geral: 2012”. Disponível em
http://www.softex.br/mpsbr/_guias/guias/MPS.BR_Guia_Geral_201
2.pdf.
[36] Redmine (2014). Redmine. Disponível em http://www.redmine.org/
[37] ABPM Brasil (2013) “BPM CBOK V3.0: Guia para o
Gerenciamento de Processos de Negócio - Corpo Comum de
Conhecimento” - 2ª edição. 2013.
[38] PMI - Project Management Institute (2013) “A Guide to the Project
Management Body of Knowledge – PMBOK” . 5º Edição. EUA,
2013.
[39] Finocchio Junior, J. (2013) “Project Model Canvas”. Ed.Campus.
2013.
[40] Sabbagh, R. (2012) “Scrum: Gestão Ágil para Projetos de Sucesso”.
Editora Casa do Código, 2012.
[41] Silva, S. V., Vasconcelos, A. P. V. de, Coutinho, J. L. (2012).
“Ambiente
Integrado–Uma
Abordagem
Automatizada
e
Colaborativa para Gestão de Processos do MPS.Br”. Revista Programa Brasileiro da Qualidade e Produtividade em Software -3ª
Ediçao. SEPIN-MCT.
[42] Silva, S. V., Coutinho, L. J., Vasconcelos, A. P. V. de, Barbosa, C.,
Reis, M., Leite, R., Barroso, L. (2011) “Gestão Integrada – Uma
Ferramenta para Atender aos Processos de Gerência de Projetos e
Portfólio do MPS.Br”. IV Workshop de Gerenciamento de Projetos
de Software (WPGS 2011). SBQS 2011, Curitiba.
[43] Silva, S. V. ; Barroso, L. ; Paulino, E. (2013) “Uma Ferramenta para
Integração e Melhoria do Processo de Gerência de Projetos”. VI
Workshop de Gerenciamento de Projetos de Software (WSGP 2013).
SBQS 2013, Salvador.
[44] Almeida, G. T. de, Ramos, B. A., Neto, M. M. F., Reis, M. F.,
Barcelos, M.R. dos S., Vasconcelos, A. P. V. de, (2010) “ Ferramenta
de Apoio à Engenharia de Requisitos Integrada a um Ambiente
Colaborativo de Código Aberto”. Congresso Brasileiro de Software:
Teoria e Prática (CBSoft 2010), Volume 4, Salvador.
[45] Almeida, G., Ramos, B., Neto, M., Carvalho, J., Barcelos, M., Silva,
S., Vasconcelos, A., (2011) “Apoio aos Processos de Gerência de
Requisitos e Verificação e Validação em um Ambiente Integrado”.
VII Workshop Anual do MPS (WAMPS), Sessão de Ferramentas,
Campinas.
[46] Carvalho, J., Amaral, M., Barcelos, M. R. dos S., Silva, V., S.,
Vasconcelos, A. P. V. de, (2010) “Integração da Gerência de
Configuração com a Gerência de Projetos e de Requisitos em um
Ambiente Colaborativo”. VI Workshop Anual do MPS (WAMPS),
Sessão de Ferramentas, Campinas.
[47] Silva, S. V.; Barroso, L. (2013) “Ferramenta Gestão Integrada”.
Resumo dos projetos da premiação Melhor Projeto do Ano de 2013.
Revista Mundo Project Management. Ed. dez/jan, São Paulo.
[48] Paulino, E. dos S. (2011) “Uma Análise dos Processos do Portal do
Projeto Formação Gesac Em Relação Ao MPS.Br Nível G”. Revista
Perspectivas Online. V. 1, N. 2.
[49] Chaves, S., Mussa, M. (2011) “Avaliação do Processo de
Desenvolvimento do Sistema Gestão dos Institutos de Acordo com a
ISO/IEC 15504”. Revista Perspectivas Online. V. 1, N. 3.
[50] Valle, M. J. ; Motta, R. ; Barroso, L. ; Silva, S. V. (2013) “Análise da
Metodologia Lean - Kanban em Relação ao Nível G do MPS.Br”.
Workshop Anual do MPS.Br (WAMPS 2013). Campinas, 2013.
57
FEES
dccp: UMA ABORDAGEM PARA DETECÇÃO DE
COLAS EM PROVAS DE PROGRAMAÇÃO
Francisco Rodrigues Santos∗ , Methanias Colaço Júnior† , José Francisco da Silva Neto∗
∗ GRUFE
– Grupo de Pesquisa no Desenvolvimento de Ferramentas Computacionais Educacionais
Instituto Federal de Educação, Ciências e Tecnologia de Sergipe (IFS)
Lagarto, Sergipe, Brasil
† NUPIC – Núcleo de Pesquisa e Prática em Inteligência Competitiva
Universidade Federal da Sergipe (UFS)
Itabaiana, Sergipe, Brasil
Email: [email protected]
uso de métricas parametrizáveis, auxilia o professor na correta
orientação e reduz a possibilidade do avanço de alunos com
baixo rendimento, para disciplinas que possuam a programação
como pré-requisito [5] [8].
Resumo—Software clones are source code fragments (similar
or exact) used in another part of the program code. In Software
Engineering, clones are kind of bad smell. In programming
exams, clones may represent shared code by students, attitude
popularly called “cheating”. Based on these principles, this paper
presents an approach and a tool for automatic detection of
"cheat"in exams of programming, with adjustable parameters
by levels of students. In a case study with teachers from the
Federal Institute of Sergipe and Tiradentes University, the initial
results showed that it is possible an automated analysis of the
resolutions of the students in exams of programming, in order
to identify clones of responses and to increase effectiveness in
correcting the tests.
I.
Partindo destes princípios, o presente artigo apresenta uma
abordagem e uma ferramenta para detecção automática de
cópias em provas de programação, a partir da análise do
código. Tal ferramenta possibilitará ao docente definir qual
o nível de rigorosidade da correção (quais componentes sintáticos que serão analisados), assim como as provas a serem
analisadas. O objetivo principal é proporcionar o aumento na
efetividade das correções de exercícios e provas aplicadas pelo
professor, buscando as possíveis práticas incompatíveis com as
diretrizes da instituição ou parâmetros de avaliação. Um estudo
de caso foi realizado para avaliar a viabilidade da proposta ao
buscar clones de software em códigos fontes, programados por
alunos dos cursos de Sistemas de Informação e Licenciatura
em Informática que utilizaram a linguagem de programação
Java. Os resultados iniciais encontrados mostraram que existe
viabilidade técnica de avaliação automática não somente em
códigos programados em Java, mas também em outras linguagens, oferecendo agilidade ao processo de correção de provas,
bem como diversas visualizações dos clones encontrados.
I NTRODUÇÃO
Clones de Software, ou simplesmente clones, são fragmentos de códigos utilizados em outra parte do programa [1].
[2] definem clone de software como um fragmento de código
que é idêntico ou similar a outro fragmento de código. Na
Engenharia de Software, um clone é considerado um bad smell,
isto é, partes de códigos que possuem alta probabilidade de
problemas [1] [3].
A análise automática em busca de clones pode retornar
vários resultados [4]. Portanto, detectar os bad smells requer
a aplicação de filtros, isto é, a configuração de métricas nos
analisadores. Um exemplo de métrica, aplicada ao analisador,
é a busca de clones que possuam mais de 5 linhas ou que
possuam o mesmo fragmento de código [4].
O restante do artigo é organizado da seguinte forma: a
próxima seção discute trabalhos relacionados. Na seção 3, são
descritas a abordagem, o funcionamento e arquitetura geral da
ferramenta. A seção 4 apresenta o estudo de caso. Finalmente,
a seção 5 discute aprimoramentos e oportunidades de pesquisas
futuras.
No contexto educacional, ao observar códigos clonados
de alunos, é comum encontrar bad smells, ou a tentativa de
disfarçar o código compartilhado ou copiado. Nestes códigos,
é possível perceber as variáveis renomeadas, comentários
alterados e uma definição de variável ou métodos deslocados
para outro ponto no código [5].
II.
T RABALHOS R ELACIONADOS
Diversos estudos e ferramentas estão sendo produzidos para
reduzirem e/ou identificarem códigos clonados. [9] construiu
a GPLAG, uma ferramenta de detecção de clones utilizando
a técnica de reconhecimento de clones baseada em grafos ou
PDG (Program Dependency Graph).
Sabe-se também que o aprendizado de programação é
lento e gradual [6] e, portanto, requer um cuidado especial,
uma vez que muitos podem adotar meios ilícitos para a
resolução de provas, por não compreenderem o assunto ou por
estarem desestimulados na disciplina, devido à complexidade
da mesma [7].
Um survey sobre clones de softwares foi realizado por
[3]. A análise comparativa das formas e técnicas utilizadas
na identificação de clones, apresentando os seus tipos e destacando os que fazem por similaridade, foi elaborada por
[1]. Buscando encontrar erros similares ao que é apresentado
Portanto, realizar a detecção de códigos clonados em
avaliações/exercícios de estudantes de programação, fazendo
58
FEES
como parâmetro de entrada em um grande conjunto de códigos
fontes, [10] propuseram um software para automatizar a tarefa.
Já a Java Code Clone Detection API (JCCD), um framework
para auxiliar na busca de códigos duplicados, foi elaborada por
[2] contudo, não faz uso do PDG.
A. Concepção da abordagem utilizada
Sabendo que um clone é um bad smell e que é possível
utilizar análise de similaridade de códigos para acompanhar
os alunos na realização de atividades práticas de programação
[8], foram aplicados procedimentos abaixo.
Já [4] destacam que a aplicação de uma ferramenta automática de detecção, em um grande pacote de software, pode
retornar vários resultados. Para direcionar ou filtrar os resultados mais críticos/relevantes, [4] elaboraram uma ferramenta
que combina a busca de clones com as métricas de engenharia
de software, tais como o tamanho do código clonado e número
de clones no programa, com a finalidade de auxiliar as tarefas
de refatoração de código.
Um experimento foi realizado por [5] com a finalidade de
identificar as principais métricas que uma ferramenta de detecção de plágio em programação deverá utilizar quando aplicada
em contexto educacional. Para o levantamento das métricas,
foram analisados códigos de estudantes com baixa maturidade
de programação em comparação com códigos modificados
pelos alunos mais experientes. Em seu estudo, [5] puderam
concluir, por exemplo, que alunos seniors, em contraste com
os juniors, tendem a restringir acesso para as variáveis de
instância. Tal característica é explicada pela necessidade de
codificação mais extensa, para a efetiva restrição, o que não
era esperado para os alunos iniciantes, que preferiram plagiar
ao invés de escrever seu próprio código.
A análise de similaridade de códigos foi aplicada por
[8] para acompanhar os alunos na realização de atividades
práticas de programação que deveriam ser implementados
na linguagem C. Em seu artigo, [8] fez uso do Moodle 1
e mostrou que é possível identificar o comportamento dos
alunos através dos códigos semelhantes, detectando, assim, os
possíveis plágios através de parâmetros estáticos de análise.
Além destes, outras discussões, que tratam de Engenharia
de Software e de clones de códigos, podem ser acompanhadas
em eventos como a conferência anual específica, o IWSC –
“International Workshop on Software Clones”.
Levantamento de técnicas para identificação de clone
de códigos, realizado através de um estudo dos principais tipos de clones de códigos e quais são os resultados que estes proporcionam, como os apresentados
por [1] e [3];
•
Levantamento de métricas para configuração de clones
de códigos: caracterizado pelo estudo das métricas de
software que podem ser utilizadas em uma correção
de provas de programação, como as apresentadas por
[5];
•
Busca ou construção de ferramentas e/ou APIs que
identificam clones: Pesquisa de ferramentas e/ou bibliotecas de software que mapeiam os clones de
software com vistas à integração com a ferramenta
a ser construída. Nesta abordagem, inicialmente foi
utilizada a API descrita por [5] para realizar buscas por
similaridades entre os códigos, em Java, dos alunos;
•
Identificação de técnicas de visualização/exibição de
clones e construção de módulo de exibição de resultados: Com base nos resultados das duas etapas
iniciais, escolheram-se os tipos de clone e métricas
que mais se adequam à realidade de cópia de provas de
programação e como representá-las, isto é, nesta etapa,
foi escolhida e implementada a representação tabular,
contendo o percentual de similaridade encontrado em
cada grupo de códigos clonados, segmentados por
alunos.
Em suma, para avaliação da abordagem de combinação e
contextualização educacional, este trabalho utilizou os conceitos sobre os tipos de clones apresentados por [3] e [2], fazendo
uso da API descrita por [2] para elaborar a estratégia de
busca por similaridades entre os códigos dos alunos, utilizando
métricas customizadas como as apresentadas por [5] para a
busca de clones de códigos.
Neste contexto, este trabalho apresenta uma abordagem
para a detecção automática de “colas” em provas de programação que possibilita a combinação de diversas APIs de análise
de código (pesquisas anteriores), com métricas parametrizáveis
ao escopo da avaliação e normas da instituição, resolvendo o
problema de estaticidade de outras pesquisas e possibilitando a
apresentação dos resultados em formatos customizados, como
o tabular.
III.
•
B. Arquitetura
A arquitetura proposta para a ferramenta é composta de
quatro camadas básicas e integradas (Figura 1), definidas
como: (a) módulo de apresentação, para exibir os resultados
encontrados em diversas visualizações; (b) módulo de apuração
de resultados, responsável por obter, dos grupos de similaridade, as métricas necessárias para a visualização escolhida;
(c) módulo de instanciação de coleta de clones, que, dados os
parâmetros de avaliação, realiza a instanciação das bibliotecas
necessárias para a identificação de grupos de similaridade e,
por fim, (d) Banco de dados, que armazena as configurações
do projeto/avaliação, apoiando toda a aplicação.
A FERRAMENTA dccp
2
A dccp (ver Figura 2), um acrónimo para Detection Code
Clone Pupils, é uma ferramenta multiplataforma elaborada
em Java capaz de analisar as respostas das provas de um
grupo de alunos, com base em configurações pré-estabelecidas.
A abordagem da ferramenta verifica os códigos dos alunos,
localizando grupos de similaridade, isto é, trechos de códigos
semelhantes entre os alunos, podendo oferecer agilidade na
correção de provas de programação, principalmente em matérias iniciais.
1) Módulo de apresentação: Composto, inicialmente, de
um único visualizador, a camada de apresentação tem por
finalidade instanciar o visualizador selecionado e exibir os
resultados para o usuário, neste caso, um professor. Sendo
1 https://moodle.org
2 https://dccp-frchico.rhcloud.com/
59
FEES
Figura 3. Em (a), tela de configuração de parâmetros de avaliação de um
projeto e, em (b), tela de configuração de APIs de avaliação
Figura 1.
que seja possível calcular o total de prova clonada, dado o
problema acima, é necessário remover as partes repetidas entre
os grupos de similaridade.
Arquitetura da dccp.
3) Módulo de instanciação de coleta de clones: O módulo de instanciação de localizadores de clones foi elaborado
para permitir a personalização de APIs que analisam códigos
buscando semelhanças. Foi criada uma interface que consulta
o banco de dados contendo os metadados de cada um dos
analisadores e suas características (vide Figura 3-a).
Assim, para que a dccp analise o código de uma determinada turma, por exemplo, sem observar o tipo ou o nome da
variável, faz-se necessário um cadastro prévio do analisador no
banco de dados e sua habilitação na tela de configuração do
projeto, conforme pode ser observado na figura 3-b, através
do campo Category. Já na figura 3-b, é exibido como a
dccp armazena o local contendo as respostas dos alunos, para
uma determinada configuração. Assim, é possível aplicar os
mesmos parâmetros de identificação para conjuntos de alunos
diferentes, oriundos de turmas diferentes.
Figura 2. (a) Exibição de resultados da análise com (b) detalhes, em vermelho,
dos códigos idênticos.
projetado para ser extensível, este módulo recebe um conjunto de resultados (métricas e seus valores) e exibe-o ao
usuário. Na etapa atual do projeto, os resultados são expostos
em formato tabular e segmentados por arquivo/questão a ser
verificada a incidência de cola (vide Figura 2). Além disto, a
implementação atual exibe, ao ser clicado nos alunos 1 e 7, por
exemplo, o trecho do código semelhante, dada as configurações
de verificação.
4) API de identificação de clones de código: Conforme
apresentado na seção II, diversos autores buscam entender e
encontrar semelhanças em códigos. A dccp optou por flexibilizar o analisador de clones de códigos com configuração em
banco de dados e instanciação dinâmica (vide seção III-B2).
Neste contexto, foi utilizada, como primeira API de detecção
de clones, a Java Clone Code Detector (JCCD) por possuir
documentação, ser de código aberto e possibilitar combinação
da parametrização para as análises. Assim, a dccp, ao utilizar
os parâmetros da JCCD, oferece ao professor a escolha dos
elementos que serão analisados como, por exemplo, a exatidão
dos nomes de métodos e variáveis nos códigos Java. Além
disto, caso a JCCD não ofereça todos os recursos necessários, o professor poderá realizar a extensão do analisador,
adicionando-o à dccp.
2) Módulo de apuração de resultados: Para a apuração
dos resultados, foi definida uma camada que proporcionasse a
independência, tanto de visualizadores, quanto de buscadores
de códigos semelhantes (clones). Tal estratégia visa permitir,
no futuro, que as métricas sejam adicionadas dinamicamente,
como plug-ins, sem a necessidade da compilação do código.
A implementação atual recebe, para a obtenção da métrica,
grupos contendo a linha, coluna (ponto de início e fim) e
o caminho dos arquivos clonados, ou seja, os grupos de
similaridades.
IV.
Já a métrica implementada, baseia-se na quantidade de
caracteres que aquele clone representa para um determinado
arquivo. Então, se uma prova de um aluno contenha, no total,
1000 caracteres, com 300 caracteres fazendo parte de um ou
mais clones, então, a prova foi 30% copiada, encontrando-se
o percentual que esse clone representa na prova do aluno.
E STUDO DE CASO
A. Objetivo
O objetivo do estudo foi avaliar a viabilidade do uso
da nossa abordagem na identificação automática de clones
de software em códigos fontes, programados por alunos de
primeiro período de cursos de Sistemas de Informação, que
utilizaram a linguagem de programação Java.
Entretanto, uma prova pode possuir mais de um grupo de
similaridade, logo, não se pode apenas somar os clones, pois
clones diferentes podem referenciar a mesma “parte” da prova.
Isso ocorre porque clones que difiram parcialmente podem ser
alocados em diferentes grupos de similaridades. Assim, para
B. Seleção de participantes e objetos
Foram realizadas parcerias com professores do curso de
Licenciatura em Informática da Universidade Tiradentes 60
FEES
geralmente, não é considerada como cola a cópia de parte
do código, realizado pelo mesmo autor, na mesma questão.
Por fim, nota-se que a ferramenta auxiliará os professores em
turmas iniciais de programação, porém, são necessários outros
testes e experimentos, com visualizações e agrupamento de
análises diferenciadas, para mensurar o grau de eficiência que
a dccp oferece, principalmente em períodos mais avançados
do curso de Sistemas de Informação.
Sergipe (UNIT) e de Sistemas de Informação do Instituto
Federal de Sergipe (IFS). Os professores selecionados deveriam ter lecionado a disciplina de "Introdução à Programação
com Java". Os professores da UNIT forneceram dois grupos
de 2 alunos, com 2 questões em cada grupo e dois casos
confirmados de cola. Já os professores do IFS, compartilharam
um conjunto de sete alunos, contendo três questões para cada
aluno.
V.
C. Instrumentação
C ONCLUSÃO E TRABALHOS FUTUROS
Para a coleta dos dados, os arquivos dos alunos passaram
por uma normalização em seus nomes e os dados pessoais
foram substituídos pelo texto “Aluno X”, sendo X um sequencial dado para cada aluno. Na sequência, os arquivos foram
organizados em diretórios contendo a estrutura [Universidade
/ Aluno X / QuestaoY.java] , onde o Y representa o número
da questão respondida.
A abordagem modelada para a dccp mostrou que é possível oferecer uma ferramenta que proporcione o aumento na
eficiência das correções de exercícios e provas aplicadas pelo
professor, principalmente em períodos iniciais nos cursos de
informática. Além disto, existem diversos estudos voltados
para a identificação de cópias de códigos, o que viabiliza a
configuração de analisadores e métricas mais específicas a um
determinado semestre ou linguagem de programação.
D. Operação
Em trabalhos futuros, serão aplicadas novas métricas, visualizadores de resultados e a aplicação de questionários aos
professores, permitindo ao projeto a execução de um experimento controlado para avaliar a efetividade da ferramenta.
1) Preparação: Para a execução do estudo de caso, foi
necessária a configuração da ferramenta (Figura 3) para não
permitir clones dos tipos I e II. Os dois primeiros grupos
de respostas, oriundos da UNIT, sofreram uma análise manual, para posterior comparação com os dados gerados pela
ferramenta. O grupo 1 foi considerado como clones do tipo
I (clones exatos/idênticos) e no grupo 2, foram encontrados
clone tipo II - “códigos idênticos em estrutura e sintaxe,
exceto por variações nos identificadores, literais, tipos, layout
e comentários” [2].
Por fim, espera-se que os resultados obtidos neste projeto
tenham impacto direto no fortalecimento da linha de pesquisa
de Educação em Engenharia de Software no estado de Sergipe.
AGRADECIMENTOS
Ao Instituto Federal de Sergipe, pelo apoio financeiro
através do Programa de Bolsas de Iniciação Cientifica em
Desenvolvimento Tecnológico e Inovação (PIBITI).
Numa abordagem inversa, o conjunto de respostas dos
alunos do IFS não passou por uma análise prévia dos tipos de
clones contidos entre eles, nem a identificação do percentual
de cópia, isto para que a averiguação da eficácia pudesse ser
feita em um segundo momento (trabalhos futuros).
R EFERÊNCIAS
[1]
[2]
2) Execução: Os professores foram consultados para confirmar se os códigos encontrados eram considerados cola.
No total, a ferramenta alcançou uma acurácia de 75% (4
casos de cola detectados e 3 confirmados). Com os resultados
encontrados, foi aplicada uma análise por amostragem para
averiguar os resultados obtidos pela ferramenta.
[3]
[4]
3) Validação dos dados: Após a análise dos dados fornecidos pela ferramenta, foi encontrado que o Aluno 6 havia
produzido código duplicado na própria questão, devendo este
ser excluído dos resultados. Sem esse falso positivo, a ferramenta teria atingido uma acurácia de 100%. Para os alunos de
números 1 e 7, foi verificada a maior quantidade de códigos
semelhantes entre si. Neste caso, os professores entrevistados
consideraram o conteúdo como a tentativa mais nítida de
fraude, por possuírem em seu código a mesma implementação,
com exceção apenas do tipo da variável utilizada.
[5]
[6]
[7]
[8]
4) Resultados e Interpretação: A dccp poderá auxiliar as
correções das provas ao apresentar, em termos percentuais, a
quantidade de linhas que são idênticas aos demais alunos,
organizadas por blocos que contém o mesmo código, isto
é, detectados como cola. Observou-se a necessidade de um
parâmetro que anulasse, seja da análise ou visualmente, os
clones identificados no mesmo arquivo. Tal procedimento reduzirá os falsos positivos, pois, em provas do primeiro período,
[9]
[10]
61
E. Borges, “Um estudo sobre abordagens e ferramentas de detecção de
clones de software,” 2008.
B. Biegel and S. Diehl, “Jccd: A flexible and extensible api for implementing custom code clone detectors,” in Proceedings of the IEEE/ACM
international conference on Automated software engineering. ACM,
2010, pp. 167–168.
C. Roy and J. Cordy, “A survey on software clone detection research,”
Queen’s School of Computing TR, vol. 541, p. 115, 2007.
E. Choi, N. Yoshida, T. Ishio, K. Inoue, and T. Sano, “Extracting
code clones for refactoring using combinations of clone metrics,” in
Proceedings of the 5th International Workshop on Software Clones.
ACM, 2011, pp. 7–13.
M. Ahmadzadeh, E. Mahmoudabadi, and F. Khodadadi, “Pattern of
plagiarism in novice students’ generated programs: An experimental
approach,” Journal of Information Technology Education, vol. 10, 2011.
E. W. Dijkstra, “On the cruelty of really teaching computing science,”
Communications of the ACM, vol. 32, no. 12, pp. 1398–1404, 1989.
E. S. de Almeida, E. d. B. Costa, K. d. S. Silva, R. d. B. Paes,
A. A. M. Almeida, and J. D. H. Braga, “Ambap: Um ambiente de
apoio ao aprendizado de programação,” in Anais do XXII Congresso da
Sociedade Brasileira de Computação, vol. 4, 2002, pp. 79–88.
D. L. Maciel, J. M. Soares, A. B. França, and D. G. Gomes, “AnÁlise de
similaridade de cÓdigos-fonte como estratÉgia para o acompanhamento
de atividades de laboratÓrio de programaÇÃo,” 2012.
C. Liu, C. Chen, J. Han, and P. Yu, “Gplag: detection of software
plagiarism by program dependence graph analysis,” in Proceedings
of the 12th ACM SIGKDD international conference on Knowledge
discovery and data mining. ACM, 2006, pp. 872–881.
N. Yoshida, T. Hattori, and K. Inoue, “Finding similar defects using
synonymous identifier retrieval,” in Proceedings of the 4th International
Workshop on Software Clones. ACM, 2010, pp. 49–56.
FEES
O uso do dojo na prática pedagógica do ensino de
lógica de programação
Prof. Josephine Esan(154344)
Mapple Bear
Aracaju/SE – Brasil
Prof. Fabio Gomes Rocha(59633)
Computação – GPITIC - UNIT
Aracaju/SE - Brasil
[email protected]
[email protected]
Profa. Rosimeri Ferraz Sabino(154343)
CCSA – UFS
Doutoranda em Educação - UFS
Aracaju/SE - Brasil
[email protected]
pela Resolução nº 4, de 6 de junho de 2012 [7] contemplando
“220 cursos, distribuídos em 13 eixos tecnológicos, e
[constituindo]-se em referência e fonte de orientação para a
oferta dos cursos técnicos no país” [6]. Alocado no primeiro
catálogo na área profissional 11, o curso Técnico em
Informática passou a constar no Eixo Tecnológico Informação
e Comunicação da última resolução, a qual é acompanhada da
Tabela de Convergência sobre “as denominações a serem
utilizadas nacionalmente para os cursos técnicos brasileiros e
as denominações anteriormente empregadas no país” [8]. De
acordo com esses documentos, o objetivo da formação técnica
em informática é expresso na caracterização do profissional
que
Abstract— The objective of this article is to analyze the
contribution of the use of software for the teaching of logic, using
Dojo as a pedagogical practice. As an empirical research, the
research is a case study in the discipline of Programming Logic of
the Computer Technician Course of the National Industrial
Training Service of the State of Sergipe. Based on the verification
about the difficulties of students’ learning, a test using Dojo as a
methodology for teaching was developed. The analyzes were
performed with a qualitative approach, using and associating the
data obtained from the pedagogical activity, framework and
references adopted in the case study. The final results showed a
reduction in the number of absences, higher rate students’
satisfaction, higher grades in the discipline, stating the possibility
of adopting the experiment done to success in learning.
Desenvolve programas de computador, seguindo as
especificações e paradigmas da lógica de programação e
das linguagens de programação. Utiliza ambientes de
desenvolvimento de sistemas, sistemas operacionais e
banco de dados. Realiza testes de programas de
computador, mantendo registros que possibilitem análises e
refinamento dos resultados. Executa manutenção de
programas de computadores implantados. [6].
Keywords— Dojo, Professional Education, Programming
Logic, Pedagogical Practices
I. INTRODUÇÃO
A evolução tecnológica ocorrida entre as décadas de 1980
e 1990, com o surgimento do micro computador e da Internet,
deu origem a novas ocupações e impulsionou a de
programador de computador. A alta aplicabilidade dos
softwares, desde a gestão de usinas nucleares à
disponibilização de jogos eletrônicos para celulares [20],
proporcionou a expansão da demanda de mão-de-obra
qualificada para esse trabalho. A formação desses
trabalhadores, iniciada já em 1969, pelos cursos superiores e
técnicos em computação [9], veio a receber diretrizes
específicas ao nível técnico com “princípios, critérios,
definição de competências profissionais gerais” [4] a partir da
Resolução no 4, de 08 de dezembro de 1999, do Conselho
Nacional de Educação. Esse documento recebeu diversas
atualizações nas legislações para a educação profissional,
culminando na publicação do primeiro Catálogo Nacional de
Cursos Técnicos, instituído e implantado pela Resolução no 3,
de 9 de julho de 2008 [5]
Observa-se, portanto, que a expectativa sobre os
conhecimentos a serem desenvolvidos para os técnicos em
informática está envolta de questões que se relacionam ao
pensamento sistematizado, abstração de dados e foco na
solução de problemas como um sistema. As “sugestões de
temas a serem abordados na formação” [6] contemplam
estudos sobre raciocínio lógico, o qual precede a habilidade
sobre um pensamento sistêmico para a compreensão da
integração de partes que se organizarão em um todo [23].
Evidencia-se, assim, a relevância da disciplina de Lógica de
Programação para a educação profissional em questão.
O foco dessa disciplina é estudar “as leis e os critérios de
validade que regem o pensamento e a demonstração” [14].
Sendo uma aprendizagem essencial para a programação de
computadores e, portanto, para as carreiras relacionadas à
Informática [17], a disciplina de Lógica de Programação é
ministrada na primeira fase do curso, onde os discentes devem
Uma segunda versão daquele documento norteador ocorreu
62
FEES
aprender a desenvolver o raciocínio lógico para a resolução de
problemas.
Iniciou-se o ensino da disciplina com 8 horas de
abordagem teórica sobre Lógica Aplicada à Programação,
contextualizando-a diante da formação do Técnico em
Informática e identificando a relevância para o
desenvolvimento das atividades pertinentes a esse profissional.
Em prosseguimento ao plano de ensino, explorou-se a relação
da lógica com situações vivenciadas no cotidiano dos
estudantes, buscando-se os conhecimentos implícitos através
de exemplos como o simples fato da tomada de decisão no
momento em que um indivíduo atravessa uma rua. Essa ação
demanda a avaliação sobre um semáforo estar sinalizando o
impedimento ou liberação para o pedestre.
Devido a sua natureza, relacionada a operações mentais
que envolvem percepção e análises apuradas para a elaboração
do conhecimento para soluções, a disciplina é uma das
principais razões para evasão e reprovação nas primeiras fases
dos cursos de Técnico em Informática [22].
Tal contexto releva a importância do desenvolvimento de
práticas pedagógicas que viabilizem melhores resultados na
aprendizagem dessa disciplina. Assim, o objetivo desta
pesquisa foi analisar a contribuição do uso de softwares para o
ensino de lógica, adotando-se o Dojo como prática
pedagógica. Trata-se de uma técnica de treinamento para
programadores, baseada em testes, idealizada por David
Thomas, que iniciou essa prática em 2003, em Paris, chegando
no Brasil em 2007, com Ivan Sanchez, a partir da criação do
grupo Dojo Floripa. O Dojo constitui-se em “Um espaço onde
programadores se reúnem para treinar e aprender. As reuniões
são periódicas e centradas num desafio de programação” [10].
A hipótese a ser verificada na investigação foi de que a
aplicação dessa prática poderia viabilizar melhor assimilação
por parte dos alunos, reduzir o índice de reprovação e de
evasão, bem como ampliar a interação entre os alunos e
professor, e a visão abstrata para solução de problemas.
A partir dessas aulas introdutórias passou-se a adotar a
ferramenta Scratch como incentivo à atuação das turmas em
grupos de quatro estudantes para a solução de problemas. O
Scratch é um software, criado pelo Massachusettes Institute of
Technology (MIT) para o ensino de lógica. Ele permite que o
aluno interaja de forma simples, e crie animações virtuais com
base na aplicação de lógica.
Após três aulas, totalizando 12 horas, prosseguiu-se com a
apresentação do conceito, dos objetivos e das regras para o uso
do Dojo na busca de soluções de problemas. Todos os alunos
foram envolvidos na solução de um único problema no
software VisualG. Nessa dinâmica, foi proposto um desafio. O
objetivo da atividade não se relaciona à conclusão do desafio,
mas ao aprender com as experiências vivenciadas pelo grupo.
Após a definição de um problema, uma dupla iniciou o
trabalho de codificação de um computador, sendo a atividade
exposta ao grande grupo para que todos pudessem
acompanhar. Um dos estudantes do grupo assumiu o papel de
“piloto”, desenvolvendo a codificação, enquanto um segundo
membro do grupo atuou como “co-piloto”, observando e
auxiliando o piloto.
II. METODOLOGIA
Como investigação empírica, a pesquisa constitui um
estudo de caso, uma vez que se voltou à observação de um
grupo específico de alunos [24], tornando-se exploratória,
sobre a verificação das dificuldades de aprendizagem dos
estudantes, e descritiva, quanto à experimentação do uso do
Dojo como metodologia para o ensino. As análises sobre os
resultados foram feitas sob abordagem qualitativa, associandose os dados obtidos na atividade pedagógica e os referenciais
adotados no estudo. O público investigado constituiu-se de
alunos da disciplina de Lógica de Programação, a qual
constitui 140 horas do total de 1.100 horas do curso Técnico
de Informática do Serviço Nacional de Aprendizagem
Industrial do Estado de Sergipe, no período de março a abril
de 2014.
Cada grupo recebeu o tempo de cinco a sete minutos para
desenvolver a atividade. Na conclusão desse tempo, o piloto
devia juntar-se ao grande grupo, passando o co-piloto ao lugar
do primeiro. Isso se estendeu a todos do grupo, até a solução do
problema proposto. Ao finalizar, iniciou-se o ciclo de prática
de codificação, visando a melhoria do código desenvolvido
inicialmente. A intenção pedagógica é despertar no estudante o
entendimento de que uma solução inicial pode ser otimizada
por outras contribuições, não se tornando a única possível. As
aulas seguintes foram intercaladas com conteúdos teóricos,
exercícios individuais e novas proposições de soluções com o
uso do Dojo, induzindo à prática dos conteúdos trabalhados nas
aulas teóricas. Assim, a cada 4 horas de matéria teórica e
exercícios, ocorreram 4 horas de uso do Dojo.
Esse curso, denominado Ensino Articulado, é desenvolvido
pelo Serviço Social da Indústria (SESI) e Serviço Nacional de
Aprendizagem Industrial (SENAI), onde os alunos freqüentam
o ensino médio no SESI concomitantemente ao ensino técnico
na segunda instituição. As turmas têm ingresso anual e o
curso, no formato atual, está em seu segundo ano. As turmas
investigadas, com idade média dos alunos entre 14 e 16 anos,
estão distribuídas entre os turnos da manhã e tarde, com
estudantes de ambos os sexos, conforme exposto na Tabela 1,
a seguir:
III. A ABORDAGEM CONCEITUAL SOBRE A PRÁTICA
Tabela 1 – Distribuição das turmas e sexo dos alunos
Turno
Homens
Mulheres
Total
Manhã
20
05
25
Tarde
19
10
29
Total
39
15
54
PEDAGÓGICA UTILIZADA
A utilização do software Scratch para a experiência
pedagógica tomou como base a teoria construcionista, a qual
“[...] atribui especial importância ao papel das construções no
mundo como apoio para o que ocorreu na cabeça, tornando-se,
deste modo menos uma doutrina puramente mentalista” [15].
Essa ferramenta tecnológica tem uma interface simples, que
permite ao aluno interagir com personagens virtuais,
possibilitando, ainda, a criação de estórias interativas, jogos e
animações. O seu foco é auxiliar os jovens a pensar de forma
Fonte: Elaborado pelos autores.
63
FEES
criativa, sistemática e colaborativa [21]. O público alvo do
software são jovens entre 8 e 16 anos, estando, assim, a sua
aplicação ao curso investigado esta dentro do escopo de idade
previsto.
tratada nesta pesquisa, com a utilização do Dojo como
instrumento pedagógico demonstrou-se positiva, com
resultados surpreendentes. Entre eles, consta o índice zero de
evasão e 6% de faltas. Em turmas anteriores, as quais tiveram
o mesmo professor e práticas pedagógicas sem o uso do Dojo,
as faltas às aulas atingiram 23%. Ao final da dinâmica na
experiência aqui relatada, os alunos alegaram estar motivados,
e por isso, evitavam faltar às aulas. Embora a experiência
tenha sido realizada em apenas duas turmas, e os seus
resultados ainda sejam iniciais, é possível observar que o
conjunto interação e aplicação criativa viabiliza uma melhor
assimilação por parte dos alunos. Nas avaliações aplicadas em
período anterior ao uso do Dojo constaram médias entre a nota
seis e sete, sendo seis a mínima para aprovação. Após a
experiência, as notas elevaram-se para a média entre sete
vírgula cinco e oito, ressaltando-se a opinião dos alunos sobre
a satisfação obtida na atividade proposta. Considerando que a
disciplina subsequente é a de Programação Desktop, os alunos
se apresentam melhor preparados nos processos lógicos
necessários também aos demais conhecimentos a serem
trabalhados no curso. Assim, mesmo considerando-se como
primeiros resultados, demandando a experiência em maior
período de observação, e em outras turmas, constatou-se a
viabilidade de adoção do Dojo como prática pedagógica para o
desenvolvimento do pensamento lógico, abstrato e sistêmico.
Conclui-se, assim, que o papel das atividades e ferramentas
utilizadas é o de auxiliar o professor no processo de ensino e
da aprendizagem, tornando-o mais interativo e colaborativo.
Ponderando-se que a pesquisa não pretende esgotar as
possibilidades de sucesso com outras práticas, novos estudos
podem ser desenvolvidos para a busca de variadas ferramentas
a serem aplicadas ao ensino da lógica, como jogos e uso de
robótica lego.
As atividades pedagógicas propostas foram estabelecidas com
base nos estágios de Piaget [16], considerando o estágio
operacional formal, ocorrido a partir dos 11 ou 12 anos até a
vida adulta do indivíduo. Aplicando-se os pressupostos desse
estágio de desenvolvimento humano, na medida em que o
aluno decompõe o problema em etapas, partindo dos
problemas gerais, em uma visão concreta, aos complexos,
desenvolvendo uma visão mais abstrata, se estabelece o
pensamento dedutivo- indutivo necessário à lógica.
Constando os alunos como participantes ativos do processo de
solução de problemas, também se posiciona eles diante do
concreto, das suas experiências mais próximas, em um
processo de interação pessoa-meio conforme descrito por [3]
sobre a realidade percebida. O professor e os colegas ficam, na
dinâmica proposta, também envolvidos nessa interação com
vistas ao conhecimento, já que esse movimento “[...] implica
uma relação sujeito-sujeito-objeto” [12].
Sendo a sala de aula o local em que ocorreu a atividade, esse
espaço “ [...] pode assumir para si a perspectiva de interação
com o conhecimento e com os atores do ato educativo,
Assume também a função de ser o principal lugar em que se
desenvolva a inteligência coletiva” [13].
O ato de codificar um software resulta na criação de um objeto
com significância ao aluno, já que vê a concretização da
aplicação de seus conhecimentos. Para tal criação o aluno é
estimulado a perceber o problema de forma individual, mas
sendo levado a considerar a participação colaborativa dos
demais na elaboração da solução lógica. Desta forma, os
alunos passam a ter uma participação ativa e interativa, que
“[...] tem muito mais vantagens que a recepção passiva. A
participação ativa e efetiva é promovida através da observação
de alguns princípios mais específicos. Prontidão e
aprendizagem” [3]
REFERÊNCIAS BIBLIOGRÁFICAS
[1] APOIE. CodingDojo. Disponível em <http://apoie.org/Dojo.html>. Acesso
em: 15 mai. 2014.
[2] ASSIS, João Francisco. Evasão escolar no ensino profissionalizante: Um
estudo de caso do Colégio Carneiro Martins. Unicentro: Revista Eletrônica de
pós-graduação
Lato
Sensu,
2008.
Disponível
em
<http://web03.unicentro.br/especializacao/revista/edicao4/lingua/LL_EvasaoE.
pdf>. Acesso em: 15 mai. 2014.
[3] BIGGE, Morris L. Teorias da aprendizagem para professores. São Paulo:
Pedagógica e Universitária, 1977.
[4] BRASIL. Resolução Conselho Nacional de Educação no 4, de 8 de
dezembro de 1999. Diário Oficial [da] União, Poder Executivo, Brasília, DF,
22 dez. 1999. Seção 1, p. 229.
[5] BRASIL. Resolução Conselho Nacional de Educação no 3, de 9 de julho
de 2008. Diário Oficial [da] União, Poder Executivo, Brasília, DF, 10 jul. 2008.
Seção 1, p. 9.
[6] BRASIL. Programa Nacional de Acesso ao Ensino Técnico e Emprego.
Institucional.
Disponível
em:
<http://pronatec.mec.gov.br/cnct/apresentacao.php>. Acesso em: 10 dez.
2012(a).
[7] BRASIL. Resolução Conselho Nacional de Educação no 4, de 6 de junho
de 2012. Diário Oficial [da] União, Poder Executivo, Brasília, DF, 8 jun.
2012(b), Seção 1, p. 13.
[8] BRASIL. Programa Nacional de Acesso ao Ensino Técnico e Emprego.
Tabela
de
Convergência.
Disponível
em:
<http://pronatec.mec.gov.br/cnct/pdf/tabela_convergencia.pdf>. Acesso em: 10
dez. 2012(c).
[9] CABRAL, Maria Izabel Cavalcanti; NUNES, Daltro José.; BIGONHA,
Roberto da Silva; COSTA, Therezinha S.; WAGNER, Flávio R.; OLIVEIRA,
José Palazzo M. de. A trajetória dos cursos de graduação da área de
computação e informática (1969-2006). Rio de Janeiro: SBC, 2008.
Na prática investigada, a participação do professor é
especialmente relevante nos momentos da passagem da
abordagem teórica para a explicação detalhada sobre a forma
da busca de solução ao problema proposto. Além disso, é
fundamental que o professor esclareça sobre a possibilidade da
solução proposta ser revista pelos alunos, constituindo um
ciclo contínuo de melhoria da solução inicial. O processo de
ensino e da aprendizagem torna-se, assim, contínuo na própria
reconstrução da experiência [11].
No entanto, a distribuição desses momentos de prática ao
longo da disciplina investigada não deve levar os alunos à
exaustão, devendo ser evitada a realização diária, pois “[...]
todas as evidências de pesquisa mostram que a prática
espaçada é mais eficiente que a prática compacta [3].
IV. CONSIDERAÇÕES FINAIS
A lógica, por ser essencial ao ensino que envolva
programação, exige do aluno a compreensão de conceitos e
aplicações que perpassarão toda a sua formação e o
acompanharão em sua jornada profissional. Ao professor
dessa disciplina compete criar um ambiente motivador e
atraente, desenvolvendo a cognição dos alunos. A experiência
64
FEES
[10] CODING DOJO. Treinamento para programadores utilizando TDD:
Desenvolvimento
Orientado
a
Testes.
Disponível:
<
http://apoie.org/Dojo.html#1> Acesso em: 11 nov. 2013.
[11] DEWEY, John. Experiência y Educación. Buenos Aires: Editorial
Losada, 1958.
[12] GAMEZ, Luciano. Psicologia da educação. Rio de Janeiro: LTC, 2013.
[13] KENSKI. Vani Moreira. Educação e Tecnologias: O novo ativo da
informação. Campinas: Papirus, 2007.
[14] MANZANO, José Augusto N. G.; OLIVEIRA, Jair Figueiredo.
Algoritmos: lógica para desenvolvimento de programação. São Paulo: Érica,
2009.
[15] PAPERT, Seymour. A máquina das crianças: repensando a escola na era
da informática. Tradução: Paulo Gileno Cisneiros. Porto Alegre: Artes
médicas, 1994.
[16] PIAGET, Jean. Seis estudos de psicologia. Tradução Maria Alice
Magalhães D´Amorim e Paulo Sergio Lima Silva. 24. ed. Rio de Janeiro:
Forense Universitária, 2010.
[17] PIMENTEL, Edson Pinheiro; FRANÇA, Vilma Fernandes; NORONHA,
Robson V.; OMAR, Nizam. Avaliação contínua da aprendizagem, das
competências e habilidades em programação de computadores. In: [18]
WORKSHOP SOBRE EDUCAÇÃO EM COMPUTAÇÃO, 9., 2003,
Campinas. Anais. Campinas: SBC, 2003. p. 105-116.
[19] PRENSKY, Marc. Aprendizagem baseada em jogos digitais. São Paulo:
Senac, 2012.
[20] SEBESTA, Robert W. Conceitos de linguagem de programação. 9. ed.
Porto Alegre: Bookman, 2011.
[21] SCRATCH. Massachusettes Institute of Technology (MIT). Scratch.
Disponível em: <scratch.mit.edu>. Acesso em: 15 nov. 2013.
[22] SILVEIRA, Zuleide Simas da. Contradições entre capital e trabalho:
concepções de educação tecnológica na reforma do ensino médio e técnico.
2007. 294 f. Dissertação (Mestrado em Educação) Universidade Federal
Fluminense, Niterói, 2007.
[23] VASCONCELOS, Maria José Esteves. Pensamento sistêmico: o novo
paradigma da ciência. 10. ed. Campinas: Papirus, 2013.
[24] YIN, Robert.K. Estudo de caso: planejamento e métodos. 3. ed. Porto
Alegre: Bookman, 2005.
65
FEES
Um Jogo Educacional para o Ensino de
Metodologias Ágeis
Giani Petri
Rogério Paulo Marcon Júnior
Universidade Federal de Santa Maria (UFSM)
Caixa Postal 54, Frederico Westphalen - RS
Universidade Federal de Santa Maria (UFSM)
Caixa Postal 54, Frederico Westphalen - RS
Email: rpjunior [email protected]
acadêmico, proporcionando uma experiência prática aos educandos, trabalhando em uma grande equipe integrada, estimulando e vivenciando os conceitos importantes para a formação
profissional dos discentes na competência de Metodologias
Ágeis.
Resumo—The teaching-learning process of Agile Methodologies, does not have the same result if the teacher does not provide
a practical experience to the students. In this context, educational
games helps in learning, enhancing the testing of the concepts
in practice. Thus, this paper aims to embed Agile Ball Point
Game, a game used in business training as an educational game
in the academic context, providing a practical experience to the
students, working in a large integrated team, experiencing the
important concepts. The priliminar results of the experiment,
performed in a class with thirty-one students, emphasize the
importance of teamwork, the need for reorganization, communication, rehabilitation and leadership skills.
I.
Um experimento foi realizado aplicando o Agile Ball Point
Game em uma amostra de 31 alunos formando uma grande
equipe. Utilizando o Agile Ball Point Game como um jogo
educativo permitiu aos alunos vivenciar na prática os conceitos
previamente teorizados em sala de aula. Em uma análise
inicial dos resultados do experimento, obtidos através de um
questionário, fatores como a necessidade de replanejamento,
reorganização, comunicação, readaptação e a capacidade de
liderança foram os itens identificados como essenciais para
alcançar os objetivos do jogo, estando estes itens fortemente
relacionados às habilidades individuais e de grupo envolvidas
na competência de Metodologias Ágeis.
I NTRODUÇ ÃO
A efetivação do processo de ensino aprendizagem das
disciplinas relacionadas à Engenharia de Software, em especial
as competências de Metologias Ágeis, são fundamentais para
a formação de profissionais que irão trabalhar na área de
desenvolvimento de sistemas. No entanto, o grande número
de conceitos e teorias envolvidas nestas disciplinas, muitas
vezes, tornam os momentos pedagógicos insatisfatórios para
potencializar o aprendizado dos discentes. Neste contexto, Reif
e Mitri (2005) destacam que o aprendizado dessas disciplinas
não possui o mesmo efeito se o aluno não tiver uma vivência
prática com o conteúdo, por mais simples que seja [1].
II.
F UNDAMENTAÇ ÃO T E ÓRICA
A. Jogos Educacionais
De modo a contribuir para a efetivação do processo de
ensino aprendizagem e potencializar as experiências práticas
dos discentes, cada vez mais os profissionais de educação estão
buscando metodologias alternativas para inserirem no contexto
acadêmico [5]. Um dos recursos educacionais à disposição dos
docentes são os jogos educativos. Este tipo de recurso contribui
na aprendizagem dos alunos, potencializando a experimentação
e visualização de conceitos na prática, além de criar ambientes
que despertem a criatividade e o interesse dos alunos [2].
Assim, surge a necessidade de explorar os diversos recursos
educacionais existentes atualmente e que estão disponı́veis aos
professores, para serem inseridos nos momentos pedagógicos,
fazendo com que o paradigma de ensino utilizado construa
um ambiente de aprendizagem divertido e motivador, e que
os conteúdos teorizados possam ser inseridos em atividades
lúdicas e que estimulem a participação dos alunos. Um dos
recursos educacionais à disposição dos docentes atualmente
são os jogos educacionais. Os jogos educacionais vêm contribuindo para as aprendizagens em diversas áreas de conhecimento, de modo a produzir um ambiente de integração e
interação entre alunos e professores.
Um jogo educacional é qualquer atividade de formato
instrucional ou que estimule a aprendizagem, que envolva
competição e seja organizada por regras e restrições para
alcançar um determinado objetivo [6]. Dentre os principais
benefı́cios dos jogos educacionais estão: (a) permitem conectar
de forma divertida o aluno ao conhecimento [5]; (b) auxiliam
o desenvolvimento de pensamentos complexos [7]; (c) é uma
forma de aplicar na prática os conceitos [8] e; (d) promovem
o desenvolvimento de habilidades cognitivas [5].
Diversos jogos educacionais foram desenvolvidos para potencializar o processo de ensino aprendizado dos conteúdos
relacionados à Engenharia de Software [3]. No entanto, jogos
educacionais não computadorizados especı́ficos para trabalhar
com os conceitos envolvidos nas Metodologias Ágeis ainda
são pouco explorados. Desta forma, o objetivo deste trabalho
é inserir o Agile Ball Point Game [4], uma técnica consolidada
utilizada em treinamentos empresariais e certificações em
Metodologias Ágeis, como um jogo educacional no ambiente
Os jogos educativos podem ser classificados de diversas
formas, uma das classificações é em jogos digitais (computadorizados) e jogos não digitais (não computadorizados). Um
jogo educacional digital objetiva aliar o aprendizado com a
diversão e são caracterizados por serem jogados através de um
dispositivo virtual (computador, tablet, etc.) e por oferecerem
um ambiente interativo [9]. Por outro lado, um jogo não digital
66
FEES
para elencar as contribuições do jogo educativo para a aprendizagem de cada membro da equipe.
(não computadorizado) caracteriza-se por explorar a interação
entre um grupo de jogadores não individualizados, proporcionando um momento lúdico e potencializando o convı́vio, a
comunicação e a integração sem explorar o uso de recursos
digitais. Por estes motivos, este trabalho objetiva abordar
um jogo educacional não computadorizado, mas que também
atua como objeto dinâmico e de integração, estimulando a
aprendizagem dos envolvidos.
IV.
Desenvolvido por Bóris Gloger em meados dos anos 2006,
o Agile Ball Point Game [4] é uma metodologia destinada
à tomada de decisões e estimativas, onde os próprios participantes deverão organizar o grupo que estará participando. O
Agile Ball Point Game foi inicialmente utilizado no evento
Certified Scrum Master Training e é utilizado até hoje em
vários treinamentos e certificações em Metodologias Ágeis,
especialmente sobre o Scrum.
B. Metodologias Ágeis
Insatisfeitos com o uso de técnicas tradicionais e pesadas
para o desenvolvimento de softwares, Kent Beck e outros
dezesseis desenvolvedores, assinaram um documento chamado
de Manifesto para o Desenvolvimento Ágil de Software [10].
O documento foi criado a partir das experiências pessoais do
grupo de desenvolvedores que valorizavam em especial os
seguintes aspectos: (a) os indivı́duos e interações acima de
processos e ferramentas; (b) software operacional acima de
documentação completa; (c) colaboração dos clientes acima de
negociação contratual e; (d) respostas as mudanças acima de
seguir um plano [10]. Estes aspectos abordados no Manifesto
Ágil contribuı́ram para sanar as dificuldades encontradas na
engenharia de software convencional e potencializar o desenvolvimento de softwares em um ambiente dinâmico com
muitas mudanças, conflitos e requisitos incertos.
O jogo possui poucas regras e todos os envolvidos são
organizados em um único e grande time. O objetivo do jogo
é passar uma pequena bola por cada integrante do grupo,
o integrante que iniciou a passar a bola deve ser o que
encerra, isto acumula um ponto para equipe. Inicialmente,
o time terá dois minutos para se organizar da maneira que
achar melhor, logo em seguida deverá dar uma estimativa de
quantos pontos conseguirão realizar na iteração. Para a equipe
conseguir pontuar, a mesma deve passar as bolas por todos
os seus participantes, as quais apenas devem ser passadas
pelo ar e não devem ser passada entre os companheiros que
estão diretamente ao lado (vizinhos da esquerda e direita). Ao
todo, o jogo tem cinco iterações de dois minutos cada uma.
Terminada a iteração, os participantes terão mais um minuto
para se reorganizar e apresentar uma estimativa, fazendo as
alterações necessárias para a próxima iteração, isso se repete
nas cinco iterações.
Uma das principais caracterı́sticas das Metodologias Ágeis
é que os engenheiros de software e outros envolvidos no
projeto (clientes, usuários, gerentes) trabalham de forma integrada em uma equipe ágil, que se auto-organiza, controla suas
atividades e acelera a comunicação entre todos os membros da
equipe, objetivando resolver conflitos e responder as mudanças
no menor tempo possı́vel.
III.
O AGILE BALL P OINT G AME
V.
E XPERIMENTO E D ISCUSS ÃO DOS R ESULTADOS
P RELIMINARES
Para dar inı́cio ao experimento, os alunos foram instruı́dos
com as regras do jogo (conforme apresentado na Seção IV),
organizados em um grande time os alunos tiveram dois minutos
para organizar o processo e prever uma estimativa de quantos
pontos iriam realizar na primeira iteração. Durante este tempo
de organização inicial do grupo, já se observou a capacidade de
liderança de muitos alunos, como o tempo era restrito alguns
alunos saı́ram divulgando as suas ideias de como organizar o
processo e de imediato a maior parte da equipe recebeu bem
a ideia dos alunos lı́deres e conseguiram organizar a equipe
para iniciar a iteração. No entanto, alguns alunos ainda estavam
dispersos e não ouviram as ideias dos colegas o que dificultou,
e de alguma forma, comprometeu a equipe durante a iteração.
Para a iteração inicial a equipe estimou 5 pontos.
M ETODOLOGIA
A metodologia utilizada para o desenvolvimento do trabalho iniciou com uma pesquisa bibliográfica com o objetivo
de investigar jogos empresariais utilizados em treinamentos e
certificações e que estivessem relacionados a competência de
metodologias ágeis. As caracterı́sticas de trabalhar em uma
grande equipe, envolvendo os conceitos de reorganização do
processo e principalmente a comunicação foram os fatores
motivadores para a escolha do Agile Ball Point Game. A
sequência metodológica constituiu-se no estudo das regras
do jogo e preparação do experimento. O experimento com
a aplicação do jogo contou com uma amostra de 31 alunos
do Curso Técnico em Informática concomitante ao ensino
médio do Colégio Agrı́cola de Frederico Westphalen, uma das
unidades da Universidade Federal de Santa Maria.
Na primeira iteração os alunos dividiram-se em dois grupos, formando duas grandes filas. Assim, cada aluno recebia
a bola de outro colega, repassava para o colega da outra
fila e se dirigia para o final da sua fila, até a bola chegar
novamente no aluno que iniciou e então marcar um ponto.
A Figura 1 apresenta a organização do processo durante a
primeira iteração.
Antes de executar o experimento, os alunos tiveram uma
explicação geral sobre o Processo de Desenvolvimento de Sistemas e uma breve comparação entre os modelos de processo
tradicionais e as metodologias ágeis. Na sequência, os alunos
da amostra foram instruı́dos com as regras do jogo, onde o
experimento foi executado sob coordenação (sem intervenção)
de um professor. Durante o experimento a re/organização e
comunicação do grupo foi registrada através de filmagens
e fotos (previamente acordado com os alunos). Ao final do
experimento a amostra de alunos respondeu um questionário
com perguntas abertas envolvendo os conceitos trabalhados
Ao longo da primeira iteração os alunos tiveram algumas
dificuldades. A principal delas foi a falta de atenção da equipe,
muitas bolas foram ao chão, fazendo com que o processo
iniciasse novamente, além disso, como alguns membros da
equipe estavam dispersos durante o tempo de organização
inicial, os mesmos tiveram dificuldades em aderir ao processo
67
FEES
No entanto, alguns alunos ainda dispersos e desconcentrados
impossibilitaram da equipe aumentar a pontuação.
Figura 1.
Ao término da iteração 4 a equipe percebeu que tinha
adquirido um ritmo e que estavam com o processo organizado.
Nos dois minutos para reorganização, a equipe fez poucos ajustes, alguns alunos lı́deres solicitaram uma maior concentração
e dedicação da equipe. Confiantes, a estimativa subiu para
cinco pontos. Durante a quinta e última iteração observouse que a equipe estava motivada a fazer o maior número de
pontos possı́veis, eles mesmos perceberam que estavam no
caminho certo e conseguiram definir um ritmo para alcançar
os objetivos. A Figura 2 apresenta a organização da equipe
durante a iteração 5 onde conseguiram fazer nove pontos.
Organização da equipe na iteração 1.
e contribuir para o êxito da equipe. Na iteração 1 a equipe
conseguiu marcar apenas um ponto, não alcançado o objetivo
por eles estimado.
Tão logo acabou a iteração 1, os alunos tiveram mais
dois minutos para discutir, reorganizar o processo, organizar a
equipe e definir uma nova estimativa para a iteração 2. Neste
tempo, os alunos lı́deres se destacaram novamente, agora se
dedicando a esclarecer o processo para quem ainda estava
com dúvidas e então estimaram três pontos para a próxima
iteração. Durante a iteração 2 os alunos mantiveram o mesmo
processo de passagem das bolas por cada membro da equipe
(conforme apresentado na Figura 1). No entanto, os alunos
tentaram realizar a passagem das bolas com mais rapidez o que
dificultou, pois várias bolas foram derrubadas o que contribuiu
para a equipe novamente não alcançar a estimativa. Na iteração
2 os alunos fizeram dois pontos, evoluindo mas ainda não
alcançando o estimado.
Figura 2.
Organização da equipe na iteração 5.
Ao final da quinta iteração houve uma conversa entre a
equipe e o professor coordenador da dinâmica. Na oportunidade os alunos destacaram a importância do trabalho em
equipe, aliada a concentração e comprometimento, bem como
a capacidade de reorganização que foi essencial para a equipe
pegar um ritmo e alcançar os objetivos estimados nas últimas
iterações.
Após o término da iteração 2 os alunos ganharam mais
dois minutos para reorganizar o processo. Logo no inı́cio
deste tempo, um dos alunos lı́deres perguntou ao professor
coordenador da atividade se poderia passar mais de uma bola
ao mesmo tempo. O professor então comentou que as regras
do jogo não proı́bem isto. Assim, a equipe teve a ideia de
organizar duas filas em paralelo, uma de frente para outra,
para então agilizar o processo e passar mais de uma bola ao
mesmo tempo. No entanto, os alunos tiveram dificuldades em
entender como se organizar, os dois minutos de organização
encerraram e a equipe não estava preparada. A iteração 3 iniciou com a mesma estimativa da iteração anterior (três pontos),
a equipe teve sérias dificuldades de organização, comunicação
e comprometimento de alguns membros da equipe e não
conseguiram marcar nenhum ponto.
A. Discussão dos Resultados Preliminares
Os resultados preliminares identificados na aplicação do
jogo e destacados pelos alunos nas respostas ao questionário
aplicado ao final da atividade podem ser sucintamente representados por quatro palavras-chave: comunicação, organização,
ritmo e trabalho em equipe.
Quanto a comunicação os alunos observaram e destacaram
a importância de trocar ideias com o grupo, além de ter
algumas pessoas que liderassem a atividade, pois como o
tempo era restrito quem tivesse ideias deveria organizar a
equipe. Além disso, os próprios alunos apontaram que a falta
de comprometimento de alguns alunos acarretou em falhas na
comunicação interna e consequentemente prejudicou a equipe.
Da mesma forma, em equipes que utilizam metodologias
ágeis para o desenvolvimento de softwares necessitam ter
uma comunicação eficiente para resolver conflitos e alinhar
os objetivos da organização.
Sem sucesso na iteração 3, a equipe conseguiu identificar
uma organização do processo para as próximas iterações.
Assim, após o término da iteração 3, os dois minutos de
reorganização foram excelentes para a equipe se comunicar
e definir como o as filas deveriam se organizar. Mesmo com o
entendimento de toda a equipe sobre o processo a estimativa
continuou em três pontos. Ao inı́cio da iteração 4 a melhoria
do processo já foi observada, os alunos estavam em duas filas
em paralelo, cada aluno de frente para outro. Assim, um aluno
iniciava a passagem da bola para o aluno imediatamente a sua
frente na outra fila, ao final o último da fila repassava a bola
para o aluno que iniciou a passagem para então marcar um
ponto. Neste processo a equipe também trabalhou com mais
de uma bola ao mesmo tempo, o que contribuiu para alcançar
e superar a estimativa. Na iteração 4 a equipe conseguiu fazer
cinco pontos, dois a mais que a estimativa para a iteração.
O principal resultado do jogo educativo está centrado
na organização e reorganização do processo. Ao longo da
dinâmica os alunos tiveram que reconhecer os erros e procurar uma solução rápida para resolvê-los. Este quesito está
bastante relacionado à adaptação às mudanças. A capacidade
de identificar o que está errado, se auto-organizar e encontrar
soluções imediatas para resolver os conflitos são as principais
caracterı́sticas das metodologias ágeis. Assim, durante cada
iteração do jogo os alunos discutiam o que poderia melhorar e
adaptavam o processo, até chegar a um processo definido, que
68
FEES
inserção de um jogo utilizado em treinamentos e certificações
em Metodologias Ágeis como um jogo educativo em um ambiente acadêmico, potencializando o aprendizado dos conteúdos
relacionados à competência.
com o passar do tempo (iteração) a equipe foi se adaptando
ao processo e melhorando o seu ritmo e consequentemente
alcançando e superando as estimativas.
Outro fator importante destacado pelos alunos refere-se ao
trabalho em grupo. Um fragmento das respostas dos alunos
destaca que: “o jogo mostrou que em um grupo todos precisam
colaborar para resolver problemas. Uma pessoa sozinha não
consegue controlar tudo.” Outro fragmento de uma resposta
enfatiza a cooperação do grupo na construção de ideias,
“em grupo podemos entender e ajudar a elaborar ideias, que
talvez sozinhos não irı́amos conseguir.” Desta forma, podemos
observar que o jogo educativo contribui no aprendizado de
diversos aspectos envolvidos na atividade e que estão fortemente relacionados aos principais conceitos envolvidos nas
metodologias ágeis, com ênfase especial à comunicação, autoorganização e capacidade de trabalhar em grupo.
VI.
Com base nos resultados preliminares obtidos no experimento conclui-se que a inserção do Agile Ball Point Game
foi estratégica para potencializar o processo de ensino aprendizagem da amostra de alunos. Os mesmos, ao formarem um
grande time, vivenciaram na prática a realidade dos conceitos
e habilidades envolvidas nas Metodologias Ágeis. Exercitando
assim, a importância do trabalho em grupo, dando ênfase
na comunicação, liderança, comprometimento e especialmente
na capacidade de se auto-organizar, adaptar as mudanças e
resolver conflitos. Como trabalho futuro pretende-se avaliar
formalmente a contribuição do jogo educacional como um instrumento de aprendizagem, utilizando para isso metodologias
de avaliação de jogos já existentes na literatura.
T RABALHOS R ELACIONADOS
R EFER ÊNCIAS
Na área de Engenharia de Software diversos jogos educacionais, apoiados ou não por computadores, vêm sendo
utilizados para contribuir no processo de ensino aprendizagem. Para melhor compreensão dos trabalhos relacionados
encontrados na literatura, que apresentam e abordam jogos
educacionais especı́fico para o ensino de Metodologias Ágeis,
a Tabela I apresenta uma breve comparação entre os trabalhos
encontrados. A tabela destaca o nome do jogo seguido de sua
referência, uma classificação do jogo quando ao seu tipo e uma
sı́ntese dos objetivos.
Tabela I.
[1]
[2]
[3]
[4]
R EVIS ÃO DE JOGOS EDUCACIONAIS PARA O ENSINO DE
M ETODOLOGIAS Á GEIS
Jogo
Scrum
Game
[11]
Scrumming
[12]
Tipo do Jogo
Jogo de Tabuleiro
Lego for
Scrum
[13]
Playing
Scrum
[14]
Scrumia
[15]
Jogo de LEGO
Jogo Digital
Jogo Digital
Jogo não digital
[5]
Objetivos
Cumprir determinadas tarefas de uma Sprint
onde o tempo do projeto é gerenciado conforme a posição do participante no tabuleiro.
Apoiar o ensino de práticas do Scrum através
da definição e simulação de Sprints para o
gerenciamento de projetos.
Simular o processo de desenvolvimento com
Scrum, criando objetos com LEGO a partir
de histórias de usuário.
Ensinar de forma prática o Scrum explorando
os papéis, reuniões e a execução de mais de
uma Sprint.
Planejar e executar uma Sprint em um projeto
simulado.
[6]
[7]
[8]
[9]
[10]
Em comparação aos trabalhos encontrados na literatura o
Agile Ball Point Game destaca-se por ser um jogo não computadorizado e por criar uma interação maior entre os participantes, integrando todos os envolvidos em um grande time, potencializando o trabalho em grupo e colocando em prática as habilidades individuais e de grupo, tais como: comunicação, autoorganização, readaptação de processos, adaptação a mudanças
e resolução de conflitos, conceitos estes que são de extrema
importância para o aprendizado de Metodologias Ágeis.
VII.
[11]
[12]
[13]
C ONCLUS ÕES
[14]
A utilização de jogos educacionais, que visam explorar a
prática de conteúdos, construindo um ambiente de aprendizagem lúdico e que desperte o interesse dos educandos, é uma
técnica que deve ser seguida pelos docentes que trabalham
com as disciplinas de Engenharia de Software, incluindo as
Metodologias Ágeis. Desta forma, este trabalho apresentou a
[15]
69
H. L. Reif and M. Mitri, “How university professors teach
project management for information systems,” Commun. ACM,
vol. 48, no. 8, pp. 134–136, aug 2005. [Online]. Available:
http://doi.acm.org/10.1145/1076211.1076249
M. R. Gramigna, Jogos de Empresa, 2nd ed. Pearson Education, 2007,
são Paulo.
C. G. Wangenheim, D. Kochanski, and R. Savi, “Revisão sistemática
sobre avaliação de jogos voltados para aprendizagem de engenharia
de software no brasil,” FEES - Fórum de Educação em Engenharia de
Software, evento integrante do XXIII Simpósio Brasileiro de Engenharia
de Software (SBES), 2009.
B. Gloger, “Ball point game,” 2008, disponı́vel em:
http://kanemar.files.wordpress.com/2008/03/theballpointgame.pdf.
R. Savi, “Avaliação de jogos voltados para a disseminação do conhecimento,” Ph.D. dissertation, Universidade Federal de Santa Catarina
(UFSC), 2011, tese (Doutorado) - UFSC, Florianópolis.
J. V. Dempsey et al., “Instructional applications of computer games.”
Annual Meeting of the American Educational Research Association,
April 1996, new York, NY.
J. Mcdonald, “Exam review strategies,” 2004, disponı́vel em:
http://www.wlu.ca/documents/107/Exam Review Strategies Packages.pdf.
Acesso em: 01 jul. 2014.
K. Mantyla, Interactive Distance Learning Exercises that Really Work!
ASTD, 1999.
T. Mitamura, Y. Suzuki, and T. Oohori, “Serious games for learning
programming languages,” in Systems, Man, and Cybernetics (SMC),
2012 IEEE International Conference on, Oct 2012, pp. 1812–1817.
R. S. Pressman, Engenharia de Software - Uma Abordagem Profissional, 7th ed. Mc Graw Hill, 2011.
M. Cohn and B. Wake, “The scrum game a fun
interactive
tool
for
learning,”
2007,
disponı́vel
em:
http://www.mountaingoatsoftware.com/products/scrum-game.
E. Isotton, “Scrumming - ferramenta educacional para ensino de práticas
de scrum,” 2008, trabalho de Conclusão de Curso (Graduação em
Bacharelado em Sistemas de Informação) - Pontifı́cia Universidade
Católica do Rio Grande do Sul, Porto Alegre.
A. Krivitsky, “Scrum simulation with lego bricks,” 2009, disponı́vel em: http://2013.agileee.org/wp-content/uploads/2011/12/ScrumSimulation-with-LEGO-Bricks-v2.0.pdf.
F. Siller and J. C. Braga, “Software educacional para prática do scrum,”
Workshops do II Congresso Brasileiro de Informática na Educação,
2013, campinas, São Paulo.
C. G. von Wangenheim, R. Savi, and A. F. Borgatto, “Scrumia an educational game for teaching {SCRUM} in computing courses,”
Journal of Systems and Software, vol. 86, no. 10, pp. 2675 –
2687, 2013. [Online]. Available: http://www.sciencedirect.com/science/
article/pii/S0164121213001295
FEES
Formação de Equipes de Alto Desempenho Para
Desenvolvimento de Software
Alessandra Costa Smolenaars Dutra
Rafael Prikladnicki
Faculdade de Informática (FACIN)
Pontifícia Universidade Católica do RS (PUCRS)
Porto Alegre, RS, Brasil
[email protected]
Faculdade de Informática (FACIN)
Pontifícia Universidade Católica do RS (PUCRS)
Porto Alegre, RS, Brasil
[email protected]
parte do compromisso das Instituições de Ensino Superior
(IES) com a sociedade [3]. Especificamente no ensino de
Engenharia de Software (ES), a qualidade dos profissionais
está diretamente relacionada à qualidade da educação, embora
também existam outros fatores que contribuem para isto [4].
Resumo — Este artigo apresenta uma discussão em relação às
atuais abordagens de capacitação para desenvolvimento de
software e a formação de equipes de alto desempenho. Foi
realizado um estudo sobre as abordagens de capacitação e sobre
as características das equipes de alto desempenho e, a partir
destes estudos, uma reflexão sobre os desafios de capacitar
equipes de alto desempenho para desenvolvimento de software.
A qualidade da capacitação em ES pode contribuir
significativamente à melhoria do estado da arte do
desenvolvimento de software e auxiliar a solução de alguns
problemas tradicionais e crises relacionadas com as práticas da
indústria de software [5]. Hoje, a capacitação e o treinamento
para formar profissionais de software devem incluir não
apenas conhecimentos básicos na área de computação, mas
também o ensino de conceitos, processos e técnicas para
definição, desenvolvimento e manutenção de software [6] [7].
Palavras Chaves — desenvolvimento de software, equipes de
alto desempenho, abordagens de capacitação, revisão sistemática
da literatura, características de alto desempenho.
I.
INTRODUÇÃO
O mercado de desenvolvimento de software opera em um
ambiente global, com mudanças rápidas, e precisam responder
com agilidade a estas novas oportunidades e a estes novos
mercados [13]. Conseguir agilidade, competitividade e
resultados sem uma equipe de desenvolvimento de software
capacitada e de alto desempenho é uma tarefa difícil e pode
trazer resultados pouco competitivos.
Neste sentido, o processo de ensino e aprendizagem de
Engenharia de Software tem passado por questionamentos
acerca dos métodos utilizados nas atividades de capacitação
[8]. Estudos recentes observam que estes métodos envolvem
estratégias tradicionais de ensino, tais como apresentação de
teoria, aulas expositivas e leituras complementares, fazendo
com que os alunos encontrem na indústria um cenário
diferente do que é ensinado na academia [8] [9]. Ao mesmo
tempo, o desenvolvimento de software tem exigido a formação
de equipes de alto desempenho, de grande domínio técnico,
comportamental e de negócio [10] [11], uma necessidade que
as atuais formações não conseguem suprir. Uma das razões é o
fato de se concentrarem na formação básica com ênfase na
abordagem tradicional do desenvolvimento de software, não
preparando o profissional para atuar como integrante de uma
equipe de desenvolvimento de software, que demanda
competências multifuncionais e ambientes multidisciplinares.
Desta forma, o objetivo deste artigo é desenvolver uma
reflexão de como as atuais abordagens de capacitação em ES
existentes cobrem as diversas características de uma equipe de
alto desempenho.
Um estudo realizado pelo Standish Group [1], conduzido
em 2010, com uma amostra de 10.000 projetos ao redor do
mundo, chamado de relatório “Chaos Manifesto 2011”,
revelou que os projetos de Tecnologia da Informação (TI)
ainda são problemáticos: apesar de 37% dos projetos de TI
terem sido bem sucedidos, sendo entregues no tempo
combinado e dentro do orçamento estipulado; 42% dos
projetos foram entregues após o tempo previsto, mais caro do
que o cálculo inicial, ou com menos recursos do que o
combinado; e 21% dos projetos foram um fracasso total, sendo
cancelados antes mesmo da entrega ou entregues mas nunca
usados. Conforme Faraj [2], melhorar a produtividade e
qualidade dos projetos é importante; enquanto abordagens
iniciais foram focadas na descoberta de melhores
metodologias e ferramentas, há uma crescente percepção de
que os projetos são caracterizados por desafios na
comunicação, na coordenação, na aprendizagem, na
negociação, na diversidade e na formação das equipes de alto
desempenho de projetos.
Este artigo está dividido em 5 seções. Na seção 2
apresentamos o referencial teórico. Nas seção 4 relatamos as
abordagens de capacitação existentes. A seção 4 apresenta
uma discussão sobre o tema e a seção 5 conclui o artigo.
Este contexto indica que a formação qualificada e a
capacitação de profissionais são cada vez mais necessárias na
sociedade em que vivemos. Seja em cursos de curta duração,
graduação ou pós-graduação, formar bons profissionais faz
70
FEES
II.
leva a indústria a ter que complementar a sua educação com
treinamentos que lhes forneçam o conhecimento necessário
para suprir esta deficiência, visando também a formação de
equipes de alto desempenho.
REFERENCIAL TEÓRICO
A. Capacitação em Engenharia de Software
A Engenharia de Software (ES) envolve a aplicação de
teoria, conhecimento e prática para o desenvolvimento efetivo
e eficiente de sistemas de software que satisfaçam os
requisitos dos usuários [7]. A ES começou a ser discutida
como disciplina em 1968 [12] e atualmente faz parte do
currículo de vários cursos de graduação entre eles: Ciência da
Computação, Engenharia da Computação e Sistemas de
Informação. Além disso, Universidades tais como UNB, UFG,
UFRN e possuem cursos de graduação específicos em
Engenharia de Software.
B. Equipes de alto desempenho
Equipe de alto desempenho é um grupo que reúne
membros comprometidos com o crescimento e o sucesso
pessoal mútuo. Conforme Chiavenato [17], os principais
atributos das equipes de alto desempenho são: participação,
responsabilidade, clareza, interação, flexibilidade, focalização,
criatividade e rapidez. Katzenbach e Smith [16], apresentam
algumas características das equipes de alto desempenho:
“profundos compromissos pessoais de cada um para com o
crescimento e o sucesso dos outros é o que distingue as
equipes de alta performance da maioria das equipes existentes.
Energizados por esse senso extra de compromisso, as equipes
de alta performance tipicamente refletem vigorosas
ampliações das características fundamentais das equipes:
senso mais profundo de propósito, metas mais ambiciosas de
performance, abordagens mais completas, maior plenitude de
responsabilidade
mútua,
intercambiabilidade
e
complementaridade de conhecimentos.”
A ES esta relacionada com todos os aspectos da produção
de software, desde os estágios iniciais até a sua manutenção,
envolvendo não apenas os processos técnicos do
desenvolvimento, como também as atividades de
gerenciamento de projeto e a utilização de ferramentas,
métodos e teorias que apoiem a sua produção [13]. Portanto, a
ES vai muito além da criação de códigos de programas,
procura disciplinar o desenvolvimento e traz para a criação de
software princípios, técnicas e conhecimento para tratar de
questões de qualidade, prazos e fatores econômicos [12].
Boyett e Boyett [18] citam algumas empresas que
obtiveram grandes resultados com equipes de alto
desempenho, tais como a AT&T Credit Corporation, que usou
equipes interfuncionais de alto desempenho para melhorar a
eficiência e o serviço ao cliente. Conforme Raj [19], observase uma grande dificuldade nas organizações para a
disseminação das práticas das equipes de alto desempenho,
como reorganização do trabalho, envolvimento dos
professionais nos processos decisórios e melhoria das
habilidades dos trabalhadores, apesar dos indícios de que as
organizações investem nestas práticas obtendo maior
produtividade e eficiência. Segundo Tonet [20] “as pessoas
que integram essas equipes tem clara noção do potencial que
possuem e buscam o desenvolvimento em todas as dimensões
humanas: racional, sensorial, emocional, cultural, espiritual”.
Os profissionais que finalizam a graduação em ES,
segundo as recomendações curriculares, devem ser capazes de,
entre outros aspectos, dominar os conhecimentos e habilidades
que fazem parte da área de ES; trabalhar individualmente ou
como parte de uma equipe para desenvolver artefatos de
software com qualidade; projetar soluções utilizando
abordagens apropriadas de ES que integrem questões éticas,
sociais, legais e econômicas; saber aplicar teorias, modelos e
técnicas correntes que forneçam uma base para identificação
de problemas e analise, projeto de software, desenvolvimento,
implementação, verificação e documentação; demonstrar
entendimento e apreciação para a importância de negociação,
hábitos de trabalho eficientes, liderança, e boa comunicação
com stakeholders; aprender novos modelos, técnicas e
tecnologias conforme elas surjam [12].
Hause [27] comenta, em sua pesquisa, que as equipes de
alto desempenho são mais focadas em tarefas específicas.
Outros estudos também seguiram pelo mesmo caminho,
identificando características de produtividade e de
desempenho, mas sem conceituar o que são equipes de alto
desempenho.
O currículo na área de ES [12][7] aponta a necessidade de
ensino para além do formato de aula expositiva, e uma das
formas de aumentar a qualidade do ensino é aperfeiçoar os
processos de ensino e aprendizagem, através de didáticas e
estratégias inovadoras. Conforme Beckman [4], a qualidade da
educação é um dos fatores importantes que influência na
qualidade dos profissionais. Assim, alguns dos desafios para
melhorar a educação em ES são: tornar os cursos de ES mais
atrativos aos estudantes; focar na educação de ES
apropriadamente, entendendo suas dimensões; apresentar as
práticas industriais aos estudantes; prover educação para
profissionais da indústria; tornar a educação em ES baseada
em evidência; assegurar que educadores em ES tenham uma
bagagem necessária para essa tarefa; aumentar o prestígio e a
qualidade da pesquisa educacional em ES [16].
Nos resultados do estudo de Staples [28], ele descreve que
o desempenho da equipe está associado a características como:
habilidades interpessoais adequadas, baixa rotatividade dentro
da equipe, tamanho da equipe adequado para que os recursos
possam completar as tarefas, presente um forte espírito de
equipe, e criação de formas inovadoras para coordenar a
equipe, ajudando a realizar as suas tarefas.
Em nossa pesquisa, realizada através de uma Revisão
Sistemática da Literatura (www.inf.pucrs.br/~10085110),
identificamos algumas características que as equipes de alto
desempenho devem ter no desenvolvimento de software.
Identificamos características organizacionais, comportamentais
e técnicas. As mais citadas são apresentadas na tabela 1 e são
Os profissionais de ES, segundo Conn [15] estão
insatisfeitos com a falta de preparo dos estudantes
universitários que ingressam no mercado de trabalho, o que
71
FEES
necessidade e de uma oportunidade. Necessidade de adotar
abordagens alternativas para a capacitação de equipes de alto
desempenho em ES, e a oportunidade de utilizá-las em
disciplinas de graduação e pós-graduação em Universidades.
principalmente características comportamentais. Assim,
podemos sugerir que as equipes de alto desempenho (1)
possuem uma comunicação eficaz, (2) apresentam uma
diversidade que estimula a aprendizagem e a inovação, (3)
possuem coesão, motivação, liderança e coordenação, a fim de
alcançar seus objetivos.
Considerando as características das equipes de alto
desempenho mais citadas, podemos identificar que a maioria
das abordagens de capacitação alternativas tem em seu foco a
melhoria destas características como trabalho em equipe,
comunicação, liderança, e motivação [9].
Tabela 1 – Características mais citadas nos estudos da RSL
Características mais citadas
Comunicação Eficiente
Coordenação
Trabalho em equipe
Diversidade da equipe
Liderança
Coesão da equipe
Motivação
Assim, as equipes de alto desempenho precisam ser
capacitadas e desenvolver seus pontos fortes, visando
proporcionar um conjunto de competências que somente estas
equipes apresentam. A capacitação das equipes é, portanto, um
aspecto essencial para a transformação das equipes em equipes
de alto desempenho.
III.
Identificamos ainda, que em um nível organizacional se
percebe pouca relação das características das equipes de alto
desempenho com as abordagens de capacitação. Do ponto de
vista comportamental, características tais como liderança,
comunicação, trabalho em equipe, motivação, coesão,
flexibilidade, são características que se consegue identificar a
relação com as abordagens de capacitação.
Por último, as características relacionadas com
competências técnicas são mais fáceis de serem trabalhadas
com as atuais abordagens de capacitação, visto que
competências técnicas são justamente os aspectos mais
trabalhados nas capacitações atuais.
ABORDAGENS DE CAPACITAÇÃO EM ES
Neste sentido, e em uma reflexão inicial, entendemos que é
importante fazer o mapeamento das abordagens de capacitação
em relação as características dos times de alto desempenho em
desenvolvimento de software.
O capacitação em ES deve preparar os estudantes tanto
para a teoria como para participações efetivas em ambientes
colaborativos e interdisciplinares. Neste sentido, é importante
considerar a variação de técnicas de capacitação.
Analisando alguns tipos de abordagens em relação as
características dos times de alto desempenho podemos
observar que: (1) Grupo de verbalização e de observação,
oficina (laboratório ou workshop) e abordagens alternativas,
tem em seu objetivo o desenvolvimento de habilidades como o
trabalho em equipe e a comunicação; (2) abordagem de
dinâmicas de grupo, educação à distância e atividades práticas
[9], possibilitam ao aluno a trabalhar com características como
o trabalho em equipe, a comunicação, a responsabilidade,
além da motivação do aluno em relação ao trabalho realizado;
(3) aulas expositivas focam mais no conteúdo. Embora o
professor leve os alunos a questionarem, interpretarem e
discutirem o objeto de estudo, esta abordagem não trabalha a
equipe, a liderança e a comunicação; (4) Capstone projects e
atividades práticas, dinâmicas de grupo e simuladores
educacionais trabalham com comunicação, trabalho em
equipe, liderança e organização, com atividades em grupo.
Neste sentido, e considerando esta reflexão inicial, temos
indícios de que: (1) é importante compreender o que são
equipes de alto desempenho em desenvolvimento de software e
suas características; (2) é necessário definir as abordagens de
capacitação a partir do que queremos ensinar, e não apenas a
partir das abordagens que conhecemos para ensinar.
Em termos de oportunidades, identificamos: (1) a execução
de um mapeamento entre as abordagens de capacitação e as
características das equipes de alto desempenho. Este estudo
facilitaria o professor na escolha da abordagem em relação as
características das equipes que se deseja trabalhar, neste caso
com foco em alto desempenho; (2) a oportunidade de propor
uma abordagem metodológica de capacitação visando a
formação de equipes de alto desempenho em ES.
As abordagens mais comuns para capacitação em ES
incluem aulas expositivas, estudo de texto, aulas de
laboratório, entre outros. Entretanto, abordagens alternativas
podem ajudar os alunos a aprender de maneira mais efetiva,
como por exemplo: utilização de estratégias que promovem
maior participação dos alunos nas aulas de ES [9], a
substituição de aulas expositivas por discussão de casos
práticos [21], abordagens construtivistas centradas nos
estudantes [22], dinâmicas de grupo, jogos e simuladores
educacionais [23] [24] e capstone projects (onde os alunos
devem desenvolver um projeto do início ao fim, muitas vezes
envolvendo um cliente real).
Estas abordagens mais focadas no aluno e que promovem
uma participação mais ativa nas aulas, segundo Junior e Saiaia
[26], têm potencial para aumentar o interesse dos alunos,
motivá-los e melhorar a aprendizagem no nível de aplicação
de conceitos. Algumas abordagens tradicionais de capacitação
são: aulas expositivas dialogadas, estudo de texto, mapa
conceitual, estudo dirigido, uso de listas de discussão, solução
de problemas, grupos de verbalização e observação,
dramatização, seminário, estudo de caso, painel, júri simulado,
fórum, oficina [25]. Além disso, existem abordagens
alternativas tais como dinâmicas de grupo, educação à
distância, atividades práticas, capstone projects, atividades
lúdicas, dinâmicas de grupo e jogos.
IV. DISCUSSÃO
A reflexão em relação as abordagens de capacitação
existentes e as características das equipes de alto desempenho
em desenvolvimento de software surgiram a partir de uma
72
FEES
[3]
[4]
Identificamos ainda os seguintes desafios: (1) conseguir
identificar, dentro de uma equipe de desenvolvimento de
software, as características que se deseja capacitar; (2).
trabalhar a capacitação aos docentes para que, através de
novas abordagens inovadoras, possam preparar melhor seus
alunos para o mercado de trabalho.
[5]
[6]
V. CONSIDERAÇÕES FINAIS
[7]
Este artigo apresentou uma reflexão inicial sobre a relação
entre abordagens de capacitação existentes e as características
das equipes de alto desempenho em desenvolvimento de
software. Para esta reflexão, o desenvolvimento foi feito em
dois passos. Primeiro, foi feito um estudo sobre as abordagens
existentes de capacitação em ES e segundo foi realizada uma
revisão sistemática da literatura (RSL) que teve como objetivo
avaliar, sintetizar e aprofundar os estudos sobre equipes de alto
desempenho em desenvolvimento de software, buscando
oportunidades de pesquisa e um embasamento teórico para
pesquisas futuras. Também foi possível observar o pouco
desenvolvimento científico abordando estudos sobre equipes de
alto desempenho em desenvolvimento de software. Para
finalizar, discutiu-se sobre como este dois temas podem se
complementar visando a melhoria da qualidade da capacitação
em ES.
Neste aspecto encontramos uma oportunidade de estudo
futuro com alguns questionamentos: Como é possível, através
das abordagens de capacitação existentes, trabalhar a
formação de equipes de alto desempenho para
desenvolvimento de software? Que novas abordagens de
capacitação poderiam ser propostas ?
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
A. Limitações e Trabalhos Futuros
Este estudo possui algumas limitações. A primeira delas
está relacionada ao viés do pesquisador durante o processo de
análise dos artigos. Isso porque a revisão sistemática de
literatura foi executada por apenas um pesquisador, assim
como a seleção dos artigos e a extração dos dados. Portanto, a
inexistência de mais de um revisor pode ocasionar erros na
classificação e na seleção dos artigos. O estudo sobre as
abordagens existentes de capacitação também teve como
limitação o viés do pesquisador durante o processo de estudo.
Em função da limitação de páginas não foi possível
apresentar mais detalhes sobre a condução da RSL, incluindo
o protocolo da revisão e as discussões qualitativas e
quantitativas (a lista de artigos pode ser encontrada em
www.inf.pucrs.br/~10085110).
Como próximo passo pretende-se analisar a formação de
equipes de alto desempenho frente às abordagens de
capacitação existentes, visando propor uma abordagem
metodológica de capacitação para formar equipes de alto
desempenho para o desenvolvimento de software.
[18]
[19]
[20]
[21]
[22]
[23]
[24]
[25]
[26]
REFERÊNCIAS
[1]
[2]
The
Standish
Group,
“Chaos”,
http://
www.versionone.com/assets/img/files/CHAOSManifesto2013.pdf,
acessado em 9 de junho de 2013.
Faraj, S., Sambamurthy, V.,"Leadership of information systems
development projects". In: IEEE Transactions on Engineering
Management, 2006.
[27]
[28]
73
Enricone, D. (Org.). “Ser Professor”, 3a edição, EDIPUCRS, 2002.
Beckman, K., Coulter, N., Khajenouri, S., Mead, N.
“Collaborations:Closing the industry–academia gap”. IEEE Software 14
(6), pp. 49–57,1997.
Gibbs, W. “Software's chronic crisis”. Scientific American 271 3 (1994),
pp. 86–95.
Saiedian, H., “Software engineering education and training for the next
millennium, Journal of Systems and Software”, v. 49, p. 113-115, 1999.
ACM/IEEE. Computer Science Curriculum, Guidelines for
Undergraduate Degree Programs in Software Engineering, 2008.
Santos, R. P., Santos, P. S. M., Werner, C. M. L., Travassos, G. H.
“Utilizando Experimentação para Apoiar a Pesquisa em Educação em
Engenharia de Software no Brasil”, Fórum de Educação em ES, 2008.
R.Prikladnicki, A. Albuquerque, C. Wangenheim, e R. Cabral, “Ensino
de Engenharia de Software: Desafios, Estratégias de Ensino e Lições
Aprendidas,” no FEES 2009.
Nearshore Americas. “Collaborate. Innovate. Accelerate. Creating
successful software requires a new model of development and a new
kind of development team”. Disponível online, acesso em Abril de 2012.
Roda, R., “Self-Organizing Agile Teams: A Grounded Theory”, Tese de
Doutorado, Victoria University of Wellington, 2011.
ACM/IEEE. Software Engineering Curriculum. Guidelines for
Undergraduate Degree Programs in Software Engineering, 2004.
Sommerville, I. “Engenharia de Software” 9a edição. São Paulo:
Pearson Prentice Hall, 2011.
Shaw, M. “Software Engineering Education: A Roadmap. In: Future Of
Softwareengineering,
International
Conference
On
Software
Engineering - Icse',Limerick. Proceedings. New York: ACM, 2000..
Conn, R. “Developing Software Engineers at the C-130J Software
Factory”. IEEE Software,Los Alamitos, v. 19, n. 5, p. 25-30, Sep. 2002.
Katzenbach, J. R; Smith D. K. “A Força e o Poder das Equipes”. São
Paulo: Makron Books do Brasil Editora Ltda, 1994.
Chiavenato, I. “Gestão de pessoas: o novo papel dos recursos humanos
nas organizações”. Rio de Janeiro: Elsevier, 2008, 3a edição.
Boyett, J.H; Boyett, J.T. “O gui dos gurus: os melhores conceitos e
práticas de negócios. Rio de Janeiro: Campus, 1999.
Raj, P.P ; Baumotte A.C.T; Fonseca D.P.D; Silva, L.H.C.M.
“Gerenciamento de pessoas em projetos”. Rio de Janeiro : Editora FGV
– Fundação Getúlio Vargas, 2006, 180p.
Tonet, H. et al. “Desenvolvimento de equipes”. 2. ed. Rio de Janeiro:
FGV, 2009, p 72.
Gnatz, M.; Kof. L.; Prilmeier, F.; Seifert, T. A. “Practical
Approach
of Teaching
Software Engineering”.
In:
16TH
CONF.
SOFTWARE ENG. EDUCATION AND TRAINING, 2003.
Proceedings... p. 120–128, 2003.
Hadjerrouit, S. “Learner-centered web-based instruction in software
engineering”. IEEE Transactions on Education, v. 48, p. 99-104, 2005.
Gresse, V. W. C.; SHull, F. “To Game or Not to Game?” Software,
IEEE, v. 26, n. 2, p. 92-94, 2009.
Fernandes, L; Werner, C. M. L. “Sobre o uso de Jogos Digitais
para o Ensino de Engenharia de Software”. In: II FÓRUM DE
EDUCAÇÃO EM ENGENHARIA DE SOFTWARE, 2009, Fortaleza,
Anais... XXIII SBES,2009.v.1.p.1-8.
Anastasiou, L. G. C.; Alves, L. P. “Estratégias de ensinagem”. In:
Anastasiou, L. G. C.; Alves, L. P. (Orgs.). Processos de ensinagem na
universidade. Pressupostos para as estratégias de trabalho em aula. 3. ed.
Joinville: Univille, 2004. p. 67-100
Junio, W. H., Saiaia, A. C. A. “Aprendizagem Centrada no Participante
ou no Professor? Um Estudo Comparativo em Administração de
Materiais”. Revista de Administração Contemporânea, p. 631-658, 2008.
Hause, M.L., "Distributed team performance in software development".
In: Proceedings of the 10th Annual SIGCSE Conference on Innovation
and Technology in Computer Science Education, 2005.
Staples, D.S., Cameron, A.F., "The effect of task design, team
characteristics, organizational context and team processes on the
performance and attitudes of virtual team members". In: Proceedings of
the Annual Hawaii International Conference on System Sciences, 2005.
FEES
ARPostIts: Mobile Application
for Agile Software Engineering using
Augmented Reality
Dhiana Deva
and Thaiana Lima
Cláudia Werner
and Claudia Rodrigues
Polytechnic School
Federal University of Rio de Janeiro (UFRJ)
Rio de Janeiro, Brazil
Email: {dhiana.deva, thaianamaria}@poli.ufrj.br
Systems Engineering and Computer Science Program
COPPE/UFRJ
Rio de Janeiro, Brazil
Email: {werner, susie}@cos.ufrj.br
The remaining of the paper is presented as follow: Section
II introduces the Augmented Reality (AR) technology; Section
III integrates SE and AR indicating some related works;
Section IV briefly explains the agile method and its use of
Post-It notes; Section V describes the ARPostIts application;
Section VI discusses the experience of users on applying it,
and Section VII presents some final considerations
Abstract—This paper presents the case of ARPostIts, a mobile
application that uses Augmented Reality in the context of Agile
Software Development. ARPostIts supports daily stand-up meetings. It expands the information of a given item (physically represented by Post-its at agile task boards) with a virtual progress
bar. These virtual objects change size and color according to the
progress and status of the item.
Keywords—Augmented Reality; Software Engineering; Mobile
devices; Agile development; Frame Makers
I.
II.
I NTRODUCTION
AUGMENTED R EALITY
Many emerging technologies that modified software requirements and developing methods are the ones that combine
mobility, connectivity and graphics evolution. This is due to
advances in knowledge about computer systems, graphics and
processing power, which are some of the main reasons we
currently have so many tools for complementing our real world
with virtual objects.
Software Engineering (SE) is defined as a series of methods, tools and procedures that allows software development
in a sustainable way [1].Observing those defining elements,
SE has changed in the past decades towards new methods,
perspectives and technologies, due to the growing complexity
and requirements of software products.
Currently, software technologies and systems still represent a challenge for anyone who creates software based in
computers [1]. The rapid changes in software projects and
infrastructure, such as massive distribution, mobile computing
and evolving Web objects, represent some of the challenges
the 21st century presents [2].
The goal of Augmented Reality (AR) is to deliver a
scenario where the real world is enriched with virtual items
(usually 2D or 3D computer generated elements) rather than
being replaced [3].Also, it needs to be a real time system that
allows interaction between the user and the virtual objects.
Therefore, we can represent and interact better with systems
that could be otherwise difficult to visualize [4].For example,
for a regular person, the car engine is something too complex
to interact with, even if the goal is to execute a simple task.
With AR we can enhance only the part we have to use, with a
virtual line or any other object. In this way, the real world is
altered with virtual elements in order to make it easier to be
understood.
Despite the information technology changes happen very
fast, the developers and their organizations often take some
time to update their methods and tools. Then, another technology emerges in the market and so the process starts all
over again. Technologies such as mobile devices, advances in
computer graphics, evolution on the processing power, battery
and connectivity create new demands and possibilities for
software applications.
AR is now used for several goals, such as simulation,
training, tracking, teaching and learning processes and many
others. In a classroom, AR can be a powerful tool to envision
3D objects rather than visualize 2D figures in books.
In this context, it is possible to notice that the way SE is
used can also be altered. The impacts of such modifications
need to be studied so the development and design of software
products can be optimized in order to minimize the damages
in time, price, rework and other traditional problems in this
field of study.
AR technology is already available in daily activities of
people with a simple smartphone, tablet or other computer
device. The applications, initially developed for studies and
academics, became tools for medicine, teaching, games and
even military use.
The goal for this work is to raise attention to ARPostIts,
an innovative application where new technologies are applied
at SE, particularly to the agile development methods.
74
FEES
III.
IV.
S OFTWARE E NGINEERING AND AUGMENTED
R EALITY
AGILE S OFTWARE D EVELOPMENT
Agile software development values individual and interactions more than processes and tools [7]. In this context, the
use of Post-it Notes at Task Boards, also called Information
Radiators, is very popular in the agile community. Agile task
boards are created for the team and by the team, adapted
according to its needs. Project management tools have builtin abstractions that force the team to be adapted to the tool,
and not the inverse. For example, Mingle1 uses cards to refer
to the items being developed by the team. In contrast, the
central elements of Pivotal Tracker2 are stories. These concepts
are similar, but when a tool is chosen, the team has to work
according to its foundations and stick to it throughout the
project lifetime.
AR makes it possible to include information in the real
world using additional dimensions and, therefore, enhances the
users perception without modifying the physical environment.
AR applications change basic notions of what a software
product can do and on which devices it can run. Those types
of applications need to be developed fast, otherwise they will
become obsolete before reaching a mature state.
AR use in SE is not explored as it could be. By executing
an ad-hoc search through literature, we could find some
works such as VisAr3D [5], an application that uses AR
to support the teaching process of the Software Architecture
(SA) concept. The public of VisAr3D are students of a SA
discipline, so that they are well prepared to the market. This
application motivates students to participate in more complex
projects, decreasing the gap between theory and practice.
The environment is explored in 3D by the student. Figure 1
shows the prototype screen capture for VisAr3D, representing
a diagram with 3D elements. Figure 1 shows the prototype
screen capture for VisAr3D, representing a diagram with 3D
elements.
A study [8] shows that paper-based task board outperforms
its software-based pendant in terms of accessibility, motivation,
haptic quality, costs, availability, overhead and communication.
A software-based task board outperforms its paper-based pendant in terms of flexibility, integration, archiving and distance.
Visual pollution may be a disadvantage for paper-based
task boards. When the team wants to give visibility to more
information about an item, it may pile up multiple Post-its
upon one another. Figure 3 shows an example of a polluted
task board where the communication is undermined. A video3
was recorded to illustrate extreme cases of these situations.
Fig. 1: VisAr3D prototype screen
SkyscrapAR [6] is another example that uses AR as a visualization technique for software evolution. Software classes
and packages in a particular project revision can be observed
in a 3D perspective. Buildings are a metaphor for constructing
a city graphic as illustrated in Figure 2.
Fig. 3: Example of a polluted area of an agile task board
Another well-known agile practice is the stand-up meeting,
such as the Daily Scrum [9].This is held every working day
at the same time and place for no more than fifteen minutes.
Every member of the development team must attend it.
The goal is to give visibility to the progress of the items
being developed. This allows daily inspection and adaptation
opportunities during the iteration. Since they are only fifteen
minutes long, they must be effective. The team members standup to keep the meeting short.
These are not status report meetings where the developers
show the work they have done. The items represent the most
important part of the meeting. Keeping them on the focus is
an important practice.
Fig. 2: Example of project visualized as a city [6]
These works address the architecture of software systems.
Our contribution uses AR technologies for the management of
software development processes
1 Mingle
website. Available in http://www.thoughtworks.com/mingle.
Tracker website. Available in http://www.pivotaltracker.com/.
3 Visual pollution with Post-it notes https://www.youtube.com/watch?v=VVSMlZFBCOY
2 Pivotal
75
FEES
V.
a variety of sample applications. Also, it has a growing
community of active developers
ARP OST I TS
ARPostIts is a mobile application to help agile software
development teams overcome the limitations of paper-based
task boards. Using AR, virtual elements related to a Post-it
can be displayed. This is done by printing an encoded frame
on Post-it notes and tracking them using computer vision-based
image recognition.
Figure 5 shows the main screen of the mobile application.
ARPostIts was developed as a final project for the Augmented and Virtual Reality discipline at the Computer Engineering graduation course of UFRJ. In this context, there were
limited resources to run a formal evaluation of the application.
The idea behind ARPostIts was conceived exploring how
AR could be applied to the agile SE context, where Post-it
notes represent items to be developed by the team. Currently,
the application displays a virtual progress bar aligned to the
bottom of each Post-it. Its color represents the current status
of the item. In the future, ARPostIts can support other types
of virtual elements.
Figure 4 illustrates a Post-it note with an encoded frame.
Only the frame is used for image tracking. People can write
anything inside it.
Fig. 5: Android mobile application AR screen
The cloud based administration web interface6 is hosted
at Heroku7 and was developed using Django8 framework.
This web system supports User authentication, User accounts
management, Projects management, Items management and
Tasks management. In this administration interface, users can
link the actual items of a given project with its corresponding
encoded post-its.
All code developed for the solution is open-source and
available at GitHub 9 10 .
Fig. 4: Post-it with encoded frame
VI.
U SER E XPERIENCE
Marker-based AR is known to rely on environmental factors such as illumination. It is usually recommended attaching
the AR marker at a flat surface such as a piece of cardboard.
When the user starts the application, the splash screen
accesses the cloud and updates the information about the
projects, items and tasks. Then, the user is prompted to input
the identification number of the project he wants to access. The
application displays the device’s camera image and renders the
virtual progress bars with lengths and colors according to the
data associated to each Post-it. The application’s usage has
been recorded in a video4 .
The malleability of Post-it notes initially represented a risk
for the markers recognition. Therefore, we have tested the
application response for different types of Post-it sizes and
colors, rooms lighting and Post-it distortion.
The tests showed that the most familiar color, Canary Yellow, has adequate contrast for the application. Even when the
Post-it note has small distortions due to heavy manipulation.
But ARPostIts could not track markers printed at Neon Pink
color.
ARPostIts consists of two applications: an Android mobile
application and a cloud based web system with a RESTful
API.
The mobile application is built with Vuforia5 platform. Vuforia image tracking algorithms are very robust. This platform
supports encoded frame markers and provides 512 different
codes. These markers can be printed on regular Post-it notes
with the aid of the template available along with the source
code. The Developer Portal has in-depth documentation and
6 Administrative
web application of ARPostIts. Available in
http://arpostits.herokuapp.com/admin/
7 Heroku:
Cloud
Platform
as
a
Service.
Available
in
https://www.heroku.com/
8 Django:
High-level
Python
web
framework.
Available
in
https://www.djangoproject.com/
9 Code repository for the mobile application of ARPostIts. Available in
http://github.com/dhiana/ARPostIts
10 Code repository for the administrative application of ARPostIts Available
in http://github.com/dhiana/arpostits_api
4 ARPostIts video showing its usage at an agile consulting firm. Available
in https://www.youtube.com/watch?v=ek7FqlI_qXc
5 Qualcomm
Vuforia
Developer
Portal.
Available
in
https://developer.vuforia.com/
76
FEES
members during the meetings. A formal experiment is a goal
for future work.
By using the typical 3 x 3 in Post-it model, the application
provides good tracking at close distances such as the common
alignment of the team around a task board on stand-up
meetings.Also, corporate offices usually have adequate lights
and stable wi-fi signal. These factors are important for a good
user experience with ARPostIts.
Another practical aspect is that the frame recognition is
little intrusive for teams that use physical task boards. Teams
with already established virtual task board tools are harder to
accept new tools. This can be overcome by integrating it with
the most popular virtual task boards and project management
tools.
A. Applications
ARPostIts has been used for product and project management activities at Concrete Solutions11 . It expands the visibility
of items progress on agile task boards. Figure 6 shows a task
board using encoded Post-its.
Currently, a virtual list of tasks related to an item is being
developed. The application will display the tasks associated
with a given item (represented by the Post-it in focus), according to the information stored on the cloud service, a tap on
the touch screen will trigger that feature.
The need for updating the progress of the items before the
stand-up meeting is the most notable downside. Web-sockets
and mobile push technology can be used for on-the-fly updates
of user interactions with the virtual progress bar changing its
value and color.
Also, publishing the application to Google Play app store
and gathering usage metrics is another important milestone.
Finally, ARPostIts, as well as similar works, shows that
SE can also benefit from high-level AR software platforms.
Such platforms are mostly used at games studios and publicity
agencies for retail and branding mobile applications, but can
be exploited for SE methods and tools.
Fig. 6: Organized task board using ARPostIts
R EFERENCES
Such task boards are mostly inspired by the KanBan [10]
tool, which is the first pillar of the Toyota production system.
This suggests that ARPostIts can also be used for production
tracking at industries aligned with the lean manufacturing
practices. The use of AR can be an invaluable technique in
SE education. It has potential to enhance traditional learning
methods by fostering a more engaging participation of students. ARPostIts can also help agile SE education by setting
up project templates for illustrating typical scenarios during
the agile life cycle of software projects.
[1]
[2]
[3]
[4]
Personal task management also benefits from the ease of
visual communication of ARPostIts. This expands the potential
reach of the application.
VII.
[5]
F INAL CONSIDERATIONS
[6]
This paper presented ARPostIts, an innovative mobile
application using augmented reality for agile software development. It provides an intermediate solution between paperbased and software-based task boards, an approach that haven’t
been explored as it could be. With this, it is suggested that it
balances their advantages and disadvantages.
[7]
No formal experiment was performed yet. However, the
application is currently on active use by a small team of four
developers at Concrete Solutions. The feedback gathered suggests that ARPostIts helps keeping efficient stand-up meetings
with organized, updated and clean information radiators. Also,
the use of AR contributes for more energetic and engaged team
[8]
[9]
[10]
11 Concrete
Solutions
http://www.concretesolutions.com.br
website.
Available
in
77
R.S. Pressman. Software Engineering, 7th ed. Brazil, 2011,
pp. 705-721.
B. E. Boehm, A View of 20th and 21st Century Software
Engineering. Proc. 28th International Conference on Software
Engineering (ICSE 2006), Shanghai, China, pp.12-29, ACM
Press, 2006.
S. Feiner, B. Macintyre, and D. Seligmann. Knowledge-based
augmented reality. Magazine Communications of ACM, New
York, vol. 36, pp.53–62, July 1993.
R. Azuma, Y. Baillot, R. Behringer, S. Feiner, S. Julier and
B. MacIntyre. Recent advances in augmented reality. IEEE
Computer Graphics & Applications, pp. 56–63, vol 21, issue
6, Nov-Dec 2001.
C. S. C., Rodrigues & C. M. L. Werner. Apoiando a Compreensão de Sistemas de Grande Escala Através da Visualização 3D.
In: V Fórum de Educação em Engenharia de Software, 2012,
Natal. V FEES. III Congresso Brasileiro de Software: Teoria e
Prática (CBSoft), 2012.(in portuguese)
R. Souza, B. Silva, T. Mendes and M. Mendonça SkyscrapAR:
An Augmented Reality Visualization for Software Evolution.
In: II Workshop Brasileiro de Visualização de Software, 2012.
Natal, II WBVS. III Congresso Brasileiro de Software(CBSoft),
2012; (in portuguese)
K. Beck, M. Beedle, A. van Bennekum, A. Cockburn, W.
Cunningham, M. Fowler, J. Grenning, J. Highsmith, A. Hunt,
R. Jeffries, J. Kern, B. Marick, R. C. Martin, S. Mellor, K.
Schwaber, J. Sutherland, and D. Thomas, "Manifesto for Agile
Software Development". http://agilemanifesto.org, 2001
J. Segers. Analysis of a paper- and software-based Scrum
task board
Business Information Technology MSc Thesis.
Enschede, September 2012.
K. Schwaber and J. Sutherland. The Scrum Guide
https://www.scrum.org/Scrum-Guide July 2013.
T. Ohno. Toyota Production System: Beyond Large-Scale Production Cambridge, MA, Productivity Press, 1988.
FEES
Aprendendo Programação Concorrente em Java
com o Objeto de Aprendizagem “Quero Bolo”
Fagner Silva Martins e Ayla Dantas
Departamento de Ciências Exatas
Universidade Federal da Paraíba (UFPB) – Campus IV
Rio Tinto, PB, Brasil
{fagner.silva, ayla}@dce.ufpb.br
Abstract— We are witnessing a paradigm shift in
programming. Multicore processors have revolutionized the way we
design systems in order to better utilize the computational power of
these machines. Therefore, an important aspect to consider in
Computer Science and Information Systems undergraduate courses
is that their students should know concurrent programming. We
have observed that for many students this is a difficult subject. In
this paper we describe a learning object to help in the introduction
of some concepts related to concurrent programming in Java and
an initial evaluation performed by some undergraduate students
from Computer Science and Information Systems courses.
é um tópico difícil e reforça a importância de se explorar mais
e mais concorrência nas aplicações para se explorar
completamente o poder computacional das CPUs modernas.
Resumo— Tem-se observado uma mudança de paradigma na
programação. Com a chegada dos processadores multicore,
desenvolvedores devem modificar sua forma de projetar sistemas
para melhor utilizar o poder computacional dessas máquinas.
Portanto, um aspecto importante da formação dos egressos em
computação e sistemas de informação é que dominem bem a
programação concorrente. Observa-se que para vários alunos é
complicado compreender esse conteúdo. Neste artigo é descrito um
objeto de aprendizagem (OA) criado com o intuito de auxiliar no
ensino introdutório de programação concorrente em Java e também
uma avaliação inicial desse OA por alunos de graduação em
ciência da computação e sistemas de informação.
Neste artigo será descrito o objeto de aprendizagem “Quero
Bolo”, criado para apoiar a introdução ao conteúdo de
programação concorrente em Java. Além disso, será
apresentada também uma avaliação inicial deste OA com
alunos. Este artigo está organizado da seguinte forma: a Seção
II discute os principais trabalhos relacionados; a Seção III
apresenta os objetivos do OA “Quero Bolo”; a Seção IV
descreve com mais detalhes este OA; a Seção V apresenta os
resultados de uma avaliação inicial do OA com alguns alunos
de graduação e por fim, na Seção VI são apresentadas as
conclusões deste trabalho e algumas propostas de trabalhos
futuros.
Considerando essa dificuldade apresentada pelos alunos e
até profissionais da área no aprendizado de programação
concorrente e que é também citada pela literatura, este artigo
apresenta uma proposta de um objeto de aprendizagem (OA)
para apoiar o ensino-aprendizagem deste conteúdo. Considerase aqui objeto de aprendizagem como sendo “qualquer recurso
digital que possa ser reutilizado para o suporte ao ensino” [4].
Keywords (palavras-chave) —ensino de programação; objetos
de aprendizagem; programação concorrente.
I.
II. TRABALHOS RELACIONADOS
Um dos trabalhos relacionados a este artigo é o de Davies
[2], que apresenta um dialeto da linguagem Pascal (Pascal-FC)
desenvolvido especialmente para dar uma experiência prática
aos alunos em cursos de programação concorrente. A
abordagem seguida no trabalho citado acima é diferente da que
será apresentada neste trabalho já que este se foca no ensino de
programação concorrente usando uma linguagem comercial, no
caso Java, ao invés de uma linguagem desenvolvida apenas
para fins educacionais. Abordagem semelhante é também
seguida pelo trabalho de Toscani [7], que apresenta a
linguagem Vale4 (V4), destinada ao ensino de programação
concorrente.
INTRODUÇÃO
Com o avanço da tecnologia e o surgimento dos
processadores multicore, tem-se explorado cada vez mais o
paralelismo durante o desenvolvimento dos atuais sistemas de
software para assim melhor utilizar o hardware disponível.
Considerando esse aspecto, é importante que os profissionais
de informática tenham uma formação sólida de programação
concorrente de forma a aproveitar melhor o paralelismo das
máquinas e a produzir software desse tipo com qualidade.
No entanto, programação concorrente é considerada um
assunto difícil por vários alunos. Alguns relatos da literatura
como de Van Roy, Armstrong, Flatt e Magnusson [8], também
falam da reputação de programação concorrente de ser
considerada difícil e de ser algo a ser evitado, se possível. Tal
reputação, segundo um dos autores, é um efeito colateral dos
problemas da programação de threads em sistemas
operacionais convencionais usando linguagens como Java, C
ou C++. Outro autor, Ortiz [6], também alega que concorrência
Há também trabalhos relacionados ao ensino de
programação concorrente focando em linguagens como Erlang,
ao invés de Java (foco do presente trabalho). Segundo Van
Roy, Armstrong, Flatt e Magnusson [8], em Erlang, criar um
processo é 100 vezes mais rápido que em Java. Isso ocorre
porque a concorrência é projetada dentro da linguagem Erlang
e não tem nada a ver com o sistema operacional. Segundo Ortiz
78
FEES
[6], Erlang é uma linguagem de programação de propósito
geral que tem suporte nativo a concorrência, distribuição e
tolerância a falhas. Neste seu trabalho, Ortiz mostra como essa
linguagem foi utilizada com sucesso para ensinar programação
orientada a concorrência (concurrency-oriented programming
– COP) em um curso avançado de programação. Na
experiência relatada neste artigo, mostrou-se que inicialmente
os alunos consideraram Erlang uma linguagem estranha, mas
que ao fim do semestre muitos gostaram de tê-la usado. Este
trabalho difere do presente artigo já que este se foca no
conteúdo introdutório de programação concorrente e com Java.
por Akimoto e Cheng [1], através do qual iniciantes podem
aprender vários conceitos de concorrência (como
sincronização, processos, semáforos, etc) naturalmente. Este
trabalho se diferencia do que é proposto neste artigo
principalmente por não usar nenhuma linguagem de
programação.
III. OBJETIVO DO OA “QUERO BOLO”
O principal objetivo desta ferramenta é apresentar o
conteúdo introdutório de programação concorrente em Java aos
estudantes de forma atraente e divertida para uma melhor
compreensão dessa área. A ideia é que o uso do OA influencie
o aluno a buscar mais conhecimentos sobre a área,
demonstrando a aplicação na prática de alguns conteúdos que
podem ser considerados bem abstratos se não forem bem
contextualizados. A ideia do OA não é substituir o professor ou
a aula, mas sim apoiar o aluno na revisão do conteúdo
apresentado em uma aula ou apoiar o professor na apresentação
do conteúdo. Além disso, pode servir como material para os
adeptos do ensino a distância que desejam fortalecer o
conhecimento na área.
Outro trabalho relacionado é o de Manickam e Aravind [5].
Neste trabalho se discute também a dificuldade de se
desenvolver software concorrente e a necessidade de se
encontrar maneiras efetivas de ensinar esse conteúdo aos
alunos. Os autores acreditam que o uso de um software de
simulação com capacidade de animação é uma ferramenta
atrativa para ensinar alguns algoritmos e conceitos de
programação concorrente. Nesse sentido, os autores projetaram
um simulador dessa natureza chamado VITTY e que pode ser
usado como ferramenta de ensino para animar algoritmos
simples e elegantes (como o algoritmo de exclusão mútua de
Knuth) e se aprofundar em sua lógica.
Para que possa ser mais amplamente utilizado, o OA e
seu código, que é aberto (open source), podem ser
gratuitamente baixados da Internet através dos sítios
http://querobolo.esy.es/ e https://github.com/fagnersistematx/
querobolo. Para executar o programa, basta realizar o
download do arquivo .jar e ter Java instalado na máquina,
independentemente do sistema operacional do usuário. Em
alguns sistemas basta o duplo clique nesse arquivo. Em outros
sistemas operacionais pode-se ir pelo terminal ao diretório
onde esse arquivo foi baixado e executar: java –jar
nomeArquivo.jar, onde “nomeArquivo” é o nome com que se
salvou o arquivo.
O Robocode [3] também é relacionado a este trabalho. Ele
é uma ferramenta de ensino desenvolvida pela IBM e que
permite o aprendizado de programação em Java através de um
engenho de simulação de uma batalha de robôs. O usuário
escreve o código que controla um mini tanque que combate
outros tanques construídos por outros usuários em um campo
de batalha. Embora seja concorrente, o foco do aprendizado
proporcionado pelo Robocode é em outras questões da
linguagem Java como chamadas de API, herança, eventos, etc
já que o usuário normalmente controla um robô.
Semelhante ao Robocode, é o jogo educacional proposto
Fig. 1. OA Quero Bolo – Tela inicial
79
FEES
caixas de seleção correspondentes são ativadas no “Quero
Bolo”.
IV. O OBJETO DE APRENDIZAGEM “QUERO BOLO”
Quero Bolo é uma ferramenta construída na linguagem de
programação Java para executar em desktops/notebooks e que
tem como intuito apoiar na compreensão de conceitos iniciais
da programação concorrente utilizando também essa
linguagem. Ela basicamente mostra uma animação cujo
comportamento pode ser influenciado pelo usuário. Nessa
animação são apresentados três bonecos (cozinheiro, mãe e
filho) onde apenas o cozinheiro e a mãe se movimentam. Estes
representam duas threads cujo início e velocidade são
controlados pelo usuário do OA. À medida que estes bonecos
se movimentam, são mostrados os estados de suas threads a
cada momento, conforme se pode observar nos cantos
superiores da Figura 1. Além disso, pode-se visualizar o código
parcial destas threads, controlar sua velocidade por meio de
botões, iniciá-las ou pausá-las. O objeto de aprendizagem
oferece ainda um botão para ajuda, onde algumas informações
sobre a sua utilização ou sobre o conteúdo introdutório relativo
a programação concorrente são apresentados.
TABELA I.
CÓDIGO PARCIAL DO COZINHEIRO E DA MÃE
CÓDIGO PARCIAL DO COZINHEIRO
class Cozinheiro extends Thread {
int velocidade = 10;
boolean sentido = ESQUERDA;
Bolo bolo;
public void run(){
while(! levouBoloBalcao()){
andar();
if(encontrouFogao()){
pegarBolo();
mudarSentido();
}
}
synchronized(bolo){
bolo.notifyAll();
}
}
public void andar(){
incrementarPosicao();
try {
Thread.sleep(VELOC_MAXIMA/velocidade);
} catch (InterruptedException e){}
}
} //...
A animação mostrada pelo “Quero Bolo” ilustra uma mãe
que vai até a confeitaria buscar um bolo para seu filho e que
aguarda no balcão até que este bolo seja trazido, caso ele ainda
não esteja lá. É ilustrado também um cozinheiro que vai buscar
o bolo no fogão e o leva ao balcão. Para iniciar o movimento
da mãe e do cozinheiro, é necessário que o usuário inicie a
thread representando cada um, o que ocorre quando se clica no
botão “Iniciar” respectivo a cada boneco. Quando ativados, os
mesmos invocarão os métodos start() de ambas as threads.
Quando as threads se iniciam, os botões “Iniciar” se
transformarão em botões de pausar. A função do boneco
cozinheiro é buscar o bolo que está no forno à esquerda e levar
até a mesa que se encontra no centro da tela para que possa ser
levado pela mãe, o que representa uma concorrência pelo
recurso compartilhado (o bolo). Para representar em código
essa concorrência, pode-se ver trechos de código da mãe e do
cozinheiro. Quando o bolo é colocado em cima da mesa, no
código da thread do cozinheiro ocorre a chamada ao método
bolo.notify(), o qual pode acordar a thread da mãe, caso esta
esteja esperando pelo bolo. A espera da mãe pelo bolo é
representada no código mostrado no OA pela invocação
bolo.wait() que ocorre caso o boneco mãe chegue até a mesa e
o bolo não esteja lá.
CÓDIGO PARCIAL DA MÃE
class Mae extends Thread {
int velocidade = 10;
boolean sentido = ESQUERDA;
Bolo bolo;
public void run(){
while(! encontrouBalcao){
andar();
}
synchronized(bolo){
while(!encontrouBolo()){
bolo.wait();
}
}
pegarBolo();
mudarSentido();
while(!encontrouFilho()){
andar();
}
}
public void andar(){
incrementarPosicao();
try {
Thread.sleep(VELOC_MAXIMA/velocidade);
} catch (InterruptedException e){}
}
} //...
Quando um dos botões “Iniciar” é ativado, o usuário poderá
controlar a velocidade do boneco que foi ativado. Isso ocorre
através de uma barra deslizante cujos valores variam entre zero
e cem e que define o valor utilizado pelo método
sleep(timeout) da classe Thread. O usuário também pode
pausar qualquer thread, ativando o botão “Pausar”. Com isso, o
mesmo se transformará novamente no botão “Iniciar”. Outra
funcionalidade é a de reiniciar o OA quando o botão
“Reiniciar” é ativado.
Uma outra tela apresentada pelo OA é um menu com
botões e que é acionado quando o usuário seleciona o botão de
ajuda, representado pela ? na versão 1.0 do Quero Bolo. Dentre
as opções que esta tela oferece está a opção de saber mais sobre
threads ou saber mais sobre como a ferramenta funciona.
V. AVALIAÇÃO DO “QUERO BOLO”
O objeto de aprendizagem pode mostrar parte do código
relativo a cada uma dessas threads para assim trabalhar
aspectos relativos à sincronização de variáveis em Java e das
operações da linguagem que fazem com que threads
modifiquem seus estados, como wait e notify. Os códigos
apresentados na tela referentes à mãe e ao cozinheiro são
apresentados na Tabela 1 e são exibidos pelo OA quando as
Com o término do desenvolvimento da primeira versão do
OA “Quero Bolo” por parte do aluno sob a supervisão de sua
orientadora fez-se necessário realizar uma avaliação deste
software por estudantes para investigar as seguintes variáveis:
o seu nível de aceitação do OA, a utilidade percebida por eles
para o aprendizado e os principais pontos positivos e negativos
80
FEES
observados. Para esta avaliação foi escolhida uma turma de
POO (disciplina do terceiro período da graduação em SI e LCC
da UFPB-Campus IV) para a qual havia sido introduzido o
conteúdo relativo à programação concorrente. Para preservar o
anonimato das respostas e o máximo de sinceridade por parte
dos alunos, foi utilizado como instrumento de pesquisa um
formulário online para esta avaliação. Foi feita uma
apresentação do OA em sala de aula e posteriormente o link
para a ferramenta e para o formulário de avaliação foi
divulgado entre os alunos na lista de discussão de e-mails da
disciplina, que tinha cerca de trinta alunos matriculados. No
total, dezoito alunos responderam o formulário. Este
apresentava quatorze perguntas, sendo algumas discursivas e
outras objetivas.
Licenciatura em Ciência da Computação e Sistemas de
Informação da UFPB-Campus IV.
De maneira geral, os resultados iniciais obtidos até então
demonstram que o OA pode sim apoiar o ensino introdutório
de programação concorrente e teve uma boa aceitação por parte
dos alunos, embora necessite evoluir para contemplar mais
conteúdos relacionados. Um dos trabalhos futuros planejados
com relação ao objeto de aprendizagem “Quero Bolo” é a sua
utilização e avaliação em outras turmas, como as turmas da
disciplina de Sistemas Operacionais, outras turmas da
disciplina de Programação Orientada a Objetos ou de outras
disciplinas específicas da área, por meio de um experimento
formal que avalie o OA. Antes disso, é importante que sejam
acrescentados nele mais recursos, como os que foram sugeridos
na avaliação, principalmente mais recursos instrucionais no
menu de Ajuda e que permitam ao aluno aprender mais com a
ferramenta sobre os conceitos de programação concorrente que
ela trabalha. Seria interessante também alguma explicação
sobre os códigos da mãe e cozinheiro para melhor explicar o
uso de synchronized e do wait e notity, conteúdos nem sempre
bem compreendidos quando se está aprendendo a fazer
sistemas concorrentes em Java. Além disso, o OA poderia
explorar também e discutir melhores implementações do
comportamento concorrente, como o uso da interface Runnable
ao invés da extensão da classe Thread e permitir no futuro que o
aluno possa alterar o código e ver o efeito disso na animação
mostrada. Um outro trabalho futuro planejado é disponibilizar
no site da ferramenta suas versões futuras (inclusive uma
versão Applet) e um fórum de discussão sobre a ferramenta
para assim incentivar o desenvolvimento de futuros OAs deste
gênero e também contribuições para a própria ferramenta por
outros desenvolvedores.
Uma das formas de identificar o nível de aceitação do OA
por parte dos alunos foi perguntar se o indicariam para colegas.
Observou-se que 87% dos alunos que responderam o
formulário indicaria o OA Quero Bolo para algum colega.
Além de observar se os alunos indicariam a ferramenta para
colegas, avaliou-se também a percepção dos alunos sobre o
quanto a ferramenta poderia lhes ajudar a absorver o conteúdo
visto. 59% dos alunos responderam que a ferramenta poderia
sim ter auxiliado em uma melhor absorção do assunto visto em
sala de aula sobre programação concorrente e 35%
responderam “Talvez”. Apenas 6% responderam que não. Com
base nisso, confirma-se para este grupo pesquisado a hipótese
de que foi útil utilizar o “Quero Bolo” para apoiar a introdução
desse conteúdo considerado difícil por vários alunos. Este
aspecto foi também verificado através de outra questão em que
se perguntava se eles acreditavam que o OA pode auxiliar no
ensino de programação concorrente. 81% dos alunos que
responderam acreditam que o OA Quero Bolo pode auxiliar no
ensino da programação concorrente, o que foi um resultado
positivo e que mostra que a ferramenta teve uma boa aceitação
inicial (hipótese que foi considerada nessa avaliação feita).
REFERENCES
Foram levantados os aspectos positivos e negativos
observados pelos participantes da avaliação. Alguns dos
principais aspectos positivos se referiam à interface, que foi
considerada bastante amigável para desmistificar um assunto
que causa certo receio aos alunos. Outro ponto positivo
levantado é o de que o OA é uma forma divertida de se
entender o básico de threads em Java em pouco tempo. Foi
observado que a maioria dos alunos acharam a ferramenta
interessante e acreditavam que ela ajudaria muitos estudantes
que têm dificuldade em assimilar este conteúdo.
[1]
Os principais aspectos negativos se referiram a sugestões
para que o OA Quero Bolo pudesse ter mais explicações sobre
threads e outros conteúdos relacionados. Um outro ponto
negativo levantado é a falta de recursos de áudio na ferramenta
e o fato de não explorar outros aspectos da programação
concorrente como o uso de semáforos em Java.
[5]
[2]
[3]
[4]
[6]
[7]
VI. CONCLUSÕES E TRABALHOS FUTUROS
Este trabalho apresentou e discutiu a aplicação de um
objeto de aprendizagem produzido para apoiar o ensino
introdutório de programação concorrente na disciplina de
Programação Orientada a Objetos para alunos dos cursos de
[8]
81
N. Akimoto; J. Cheng “An Educational Game for Teaching and
Learning Concurrency”. In: Knowledge Economy and Development of
Science and Technology (KEST 2013), 2013.
G. L. Davies. “Teaching concurrent programming with Pascal-FC.”
ACM SIGCSE Bulletin, v. 22, n. 2, p. 38-41, 1990.
S. Li. Rock 'em, sock 'em Robocode! Learning Java programming is
more fun than ever with this advanced robot battle simulation engine.
IBM Developer Works. 1 jan 2002. Disponível em: <
http://www.ibm.com/developerworks/java/library/j-robocode/>
L. N. Macêdo; A. A. M. Macêdo; J. A. C. Filho. “Avaliação de um
Objeto de Aprendizagem com Base nas Teorias Cognitivas”. WIE, Rio
de janeiro, julho. de 2007.
V. Manickam, V. e A. Aravind. “If a picture is worth a thousand words,
what would an animation be worth?” In Proceedings of the 16th Western
Canadian Conference on Computing Education, New York, NY, USA,
2011.
A. Ortiz. “Teaching concurrency-oriented programming with Erlang”. In
Proceedings of the 42nd ACM technical symposium on Computer
science education, SIGCSE’ 11, 2011, pages 195-200, New York, NY,
USA. ACM.
S. S. Toscani. “Vale4 – Uma Linguagem Didática para Ensino de
Programação Concorrente”. In: Anais do I Workshop de Sistemas
Operacionais (WSO 2004), 2004.
P. Van Roy; J. Armstrong, M. Flatt; B. Magnusson. The role of language
paradigms in teaching programming. In ACM SIGCSE Bulletin (Vol. 35,
No.
1,
pp.
269-270).
ACM.
2003
FEES
O uso de questionários para elicitação de informações
sobre uma estratégia didática em Engenharia de
Requisitos
Joanna Pivatelli Bistene¹, Roxana Quintanilla Portugal¹, Priscila Engiel¹, Edgar Alexander¹,², Julio Cesar Sampaio do
Prado Leite¹
¹Departamento de Informática, PUC-Rio, Rio de Janeiro, RJ, Brasil
²Departamento de Ciências Exatas e Tecnológicas, UESC, Ilhéus, Bahia
{jpivatelli, rportugal, pengiel}@inf.puc-rio.br, [email protected], www.inf.puc-rio/~julio
construção de um software. Uma abordagem para minimizar
essa dificuldade é a criação artificial de interessados (clientes),
com o material humano disponível no curso, isto é, os próprios
alunos.
Resumo — o ensino de Engenharia de Requisitos apresenta
uma série de desafios para os educadores, sendo um dos
principais, o ensino de métodos, técnicas e ferramentas de
elicitação. Uma estratégia para mitigar alguns dos desafios vem
sendo adotada na PUC-Rio no ensino de Engenharia de
Requisitos e foi avaliada com base em uma técnica de elicitação, o
questionário, junto aos alunos no fim do semestre de 2014.1.
Apresentamos um resumo da estratégia, o processo de construção
do questionário, bem como uma análise das informações
coletadas.
Apesar do sucesso obtido com essa estratégia em cursos
anteriores [4], faltava um instrumento sistêmico para auxiliar
no entendimento de como essa estratégia era assimilada pelos
alunos. Para isso, produzimos um questionário que permitisse
elicitar como a estratégia tinha sido percebida pelos alunos.
Esse questionário foi elaborado com quinze perguntas
quantitativas, baseadas na escala Likert [5], e duas perguntas
qualitativas de respostas livres. O questionário foi construído
com especial cuidado, visto que serviria também como parte
do ensino da disciplina. Ele serviu como instrumento
quantitativo e como exemplo de uma forma de elicitar
requisitos. O questionário foi implantado no software Google
Forms [6] e respondido após o término do semestre.
Palavras-chave — engenharia de requisitos; elicitação;
didática; questionário
I. INTRODUÇÃO
A Engenharia de Requisitos pode ser entendida como
composta de partes que estão em constante interação e
concorrência. Essas partes são: elicitação, modelagem,
análise e gerência [1]. Um dos desafios no ensino de
Engenharia de Requisitos é a dificuldade que os alunos de
graduação têm para aprenderem da elicitação de requisitos.
Um dos motivos é o fato de que a elicitação de requisitos é
fortemente ligada às disciplinas da área social [2].
O objetivo deste artigo é apresentar as informações
elicitadas a respeito da estratégia didática utilizada, na
disciplina de Engenharia de Requisitos da graduação. Este
artigo segue com a Seção II que descreve a os trabalhos
relacionados, a Seção III que apresenta estratégia didática
adotada, a Seção IV que detalha o processo de criação do
questionário, a Seção V que apresenta os resultados da
aplicação do questionário e a Seção VI que apresenta a
conclusão e propõe trabalhos futuros.
Dentre as técnicas ensinadas no curso de Engenharia de
Requisitos, relacionadas à área social, temos, por exemplo:
identificação de fontes de informação, entrevistas
(estruturadas, semi estruturadas e não estruturadas),
questionários (qualitativos e quantitativos), reuniões (“brainstorming”, “JAD” e “orientado à listas”), observação e
etnografia [1]. Para fixação e melhor compreensão dessas
técnicas é importante que elas sejam praticadas gerando
questionamentos e vivências experimentais de forma que o
conceito seja consolidado.
II. TRABALHOS RELACIONADOS
Apesar do IEEE REET (“Requirements Engineering
Education and Training Workshop”) estar na sua oitava
edição, a literatura focada em elicitação de requisitos ainda
é, em geral, escassa. Dos artigos publicados destacamos [7]
que procura utilizar alunos, sem conhecimento de engenharia
de software, como clientes para responderem a perguntas com
base em um detalhado documento. Nossa estratégia difere
porque não é fornecida nenhuma descrição, cabendo à equipe
de interessados pensar e criar uma necessidade real. No caso
No entanto, disponibilizar fontes de informação para a
disciplina de Engenharia de Requisitos é difícil e custoso,
visto que o papel de interessado requer o envolvimento de um
grupo que tenha conhecimento e interesse na evolução ou
82
FEES
em pauta, tivemos quatro aplicações: um sistema geográfico
para indicações dentro de um bairro, um gerenciador de
exercícios de academia, um controle de bancas de jornal e um
sistema de troca de jogos.
análise, os grupos praticaram estratégias de verificação,
principalmente a inspeção de modelos com base em uma lista
de perguntas estabelecida para cada tipo de modelo. Como
parte da estratégia de gerência, enfatizamos a construção de
rastros, por meio da descrição da história do processo de
construção.
Outros autores propõem o uso de jogos [8] para substituir a
interação entre indivíduos, mas cremos que o resultado dessa
estratégia para o ensino de Engenharia de Requisitos em
turmas de graduação é limitado devido ao fato de este ser, na
maioria, o primeiro contato dos alunos com a disciplina.
Acreditamos que o contato humano ainda é necessário para as
abordagens de ensino de elicitação, modelagem, análise e
gerência.
IV. QUESTIONÁRIO
Elaboramos o questionário de forma colaborativa visando
avaliar a estratégia de ensino adotada no decorrer da disciplina
de Engenharia de Requisitos da graduação. Dividimos as
questões em categorias segundo os papéis assumidos pelos
alunos da graduação, as percepções quanto ao papel dos
alunos de pós-graduação e aspectos gerais que possibilitassem
reflexão sobre a atuação dos grupos.
III. A ESTRATÉGIA DIDÁTICA
No processo de ensino da disciplina de Engenharia de
Requisitos da graduação, é simulado um cenário mais próximo
possível da realidade de elicitação de requisitos, no qual
grupos de alunos representam empresas de construção de
requisitos com o objetivo de levantar as necessidades de um
cliente, representado por outro grupo de alunos. Os alunos
também desempenharam o papel de auditores, no qual eles
realizam análise, através de tarefas de verificação. No caso, a
verificação foi conduzida nas representações criadas por outro
grupo utilizando métodos de inspeção com listas de perguntas,
inspiradas em Fagan1. Com isso, ao longo da disciplina, cada
grupo teve a possibilidade de exercer três papéis diferentes:
construtor de requisito, cliente e auditor.
Na categoria referente ao papel de engenheiro de
requisitos, foram agrupadas seis questões que nos permitiram
identificar como o respondente avaliou o desempenho do seu
grupo no papel de engenheiro de requisitos. A ideia era
verificar se o grupo teve o entendimento das tarefas de um
engenheiro de requisitos e se ele conseguiu executá-las
Na categoria referente ao papel de cliente, foram
agrupadas quatro questões que nos permitiram observar como
o respondente compreendeu a relevância das atividades
pertinentes ao cliente. A ideia era verificar se os alunos
entenderam melhor o papel de engenharia de requisitos por ter
desempenhado o duplo papel, ou se este duplo papel apenas
dificultou o aprendizado.
Portanto, a disciplina de Engenharia de Requisitos vem
utilizando a estratégia de um projeto prático [3], entremeado
com as aulas. Esse projeto pressupõe a formação de empresas
que atuarão na construção de requisitos para um determinado
grupo de interessados, o grupo cliente. Para tal, cada grupo de
alunos, quando assume o papel de empresa construtora de
requisitos, é responsável por construir requisitos para um
grupo de interessados. Ocorre que este grupo de interessados é
outro grupo de alunos da disciplina. No caso em questão, a
turma tinha quatro grupos, onde cada um foi, ao mesmo
tempo, cliente e construtor. Com isso, os grupos A, B, C e D
formaram 4 pares: A - construtor, D – cliente; A - cliente, B construtor; B – cliente, C - construtor; D - construtor, C cliente.
Na categoria referente ao papel de auditor, foram
agrupadas duas questões que nos permitiram identificar como
o respondente assimilou a atividade de inspecionar o trabalho.
Além de verificar o entendimento das tarefas de inspeção, a
ideia era verificar se eles entenderam a importância desta fase
dentro do processo como um todo.
Na categoria referente ao papel do consultor, temos uma
questão com o intuito de verificar se a presença de um
membro externo foi benéfica para a compreensão e
entendimento das etapas de elicitação.
Na categoria de aspectos gerais, temos duas questões: uma
sobre gerência e outra sobre a participação dos membros do
grupo. Além disso, nessa parte do questionário fizemos duas
perguntas qualitativas: “Diga sumariamente os 3 pontos fortes
da estratégia de ensino” e “Diga sumariamente os 3 pontos
fracos da estratégia de ensino”
Desta forma, cada grupo empregou técnicas de elicitação
com o seu cliente, ou seja, outro grupo de alunos. Além disso,
cada grupo desempenhou, também, o papel de auditor externo,
por meio da técnica de inspeção [9, 10 e 11]. Cada grupo foi
apoiado por um consultor, papel esse desempenhado por
alunos de pós-graduação em Engenharia de Requisitos.
Para cada questão, foi definido e apresentado ao
respondente o objetivo, a justificativa e cinco possíveis
respostas gradativas que possibilitavam identificar o grau de
satisfatibilidade, conceito de “satisfação a contento” proposto
em [14], do aluno. Realizamos cinco reuniões para debater o
questionário e dividimos as tarefas de propor questões por
grupos entre os autores. Obter a cobertura desejada, dentro de
um limite de 15 perguntas quantitativas é um desafio e faz
parte da competência do Engenheiro de Requisitos, no uso da
técnica de questionário.
Para elicitação de requisitos, os grupos usaram as técnicas
[1] apresentadas nas aulas teóricas, como, por exemplo,
reuniões, questionários, entrevistas, leitura de documentos e
observação. Para a modelagem, cada grupo utilizou três
linguagens apresentadas nas aulas teóricas, dentre elas,
cenários [12] e léxico ampliado da linguagem [13]. Para a
1
Michael E. Fagan, "Advances in software inspections," IEEE
Transactions on Software Engineering, vol. 12, no. 7, pp. 744-751,
July, 1986.
As respostas foram elaboradas de acordo com uma ordem
ascendente de satisfação a contento ou entendimento quanto a
83
FEES
questão de referência. Desta forma, foi possível identificar
que, caso a resposta a uma pergunta tenha sido 1, o grau de
satisfatibilidade do aluno foi o mais baixo possível. Em
contrapartida, caso a resposta do aluno tenha sido 5, o grau de
satisfatibilidade foi o mais alto possível.
Pontos fracos:
• Gerência não atuante
Consistências:
• Na maioria das perguntas quantitativas e
qualitativas é possível perceber que há
consistência
Após a conclusão da disciplina, enviamos um e-mail
solicitando aos 26 alunos que respondessem ao questionário,
cujo objetivo era entender como a estratégia de ensino tinha
sido percebida e como poderia ser melhorada. Obtivemos 19
questionários respondidos completamente. Cabe ressaltar que
o preenchimento do questionário foi anônimo, não houve
associação às notas atribuídas e não coletamos quaisquer
informações pessoais que possibilitassem a identificação dos
alunos. Além disso, o aluno poderia abandonar o questionário
a qualquer momento sem a necessidade de finalizá-lo.
Discrepâncias:
• Algumas perguntas apresentam algum
grau de insatisfação, porém, não disserta
a respeito
Tab 1 - Consolidação das Respostas do Questionário
A. Identificação de pontos fortes e pontos fracos
Os pontos fortes e fracos foram elicitados através das duas
questões qualitativas que solicitavam, aos alunos da disciplina
de Engenharia de Requisitos da graduação, três pontos fortes e
três pontos fracos da estratégia de ensino utilizada.
A Figura 1 ilustra uma questão quantitativa presente no
questionário referente ao papel de Engenheiro de Requisitos.
Os pontos fortes apresentados demonstraram que os alunos
da disciplina de Engenharia de Requisitos da graduação
aproveitaram a presença dos consultores no decorrer da
execução do trabalho, destacando o auxílio prestado durante a
elaboração das atividades. Além disso, os pontos fortes
identificaram a experiência do trabalho como algo próximo à
realidade, contribuindo positivamente para a assimilação do
conteúdo da disciplina. Outros temas como a gerência,
paralelização e divisão das tarefas foram citados como
consequência da maximização da qualidade dos trabalhos
produzidos. Os diferentes papéis que os alunos de graduação
puderam vivenciar foram citados, com destaque maior para o
papel de cliente que possibilitou maior compreensão do papel
de empresa construtora de requisitos. Por último, o uso de atas
foi citado como um ponto importante para manter a
organização no grupo.
Fig 1 - Feedbak sobre o Trabalho de E.R.
V. RESULTADOS DA APLICAÇÃO DO QUESTIONÁRIO
As respostas obtidas por meio das perguntas qualitativas
foram estudadas por todos os alunos de pós-graduação. Para
facilitar a análise, as respostas foram divididas entre os quatro
alunos fazendo com que cada um trabalhasse com um total de
quatro ou cinco conjuntos de respostas. A Tabela 1 apresenta
os resultados relevantes obtidos por meio das 19 respostas e
contém os pontos fortes, os pontos fracos, as consistências e as
discrepâncias identificadas na comparação das respostas
qualitativas e quantitativas de cada conjunto de questões
respondidas.
ALUNO 01
Pontos fortes:
• Presença do consultor
• Experiência próxima da realidade
Pontos fortes:
• Tamanho do grupo
Consistências:
• O papel cliente foi evidenciado
• Falta de um enunciado formal foi
evidenciada
Discrepâncias:
• O papel cliente foi considerado
indiferente para o aprendizado porém
não é destacado como ponto negativo
ALUNO 03
Pontos fortes:
• Gerência atuante
• Uso de atas
Pontos fracos:
• Falta de um enunciado formal
• Conhecimento dividido
Consistências:
• O paralelismo das tarefas e melhoria
do trabalho
• Nas
perguntas
quantitativas
e
qualitativas é possível perceber que há
consistência
Discrepâncias:
• Não identificada
Os pontos fracos apresentados demonstraram a
insatisfação quanto ao tamanho dos grupos (seis a sete
membros) justificada sob a dificuldade de gerenciar um
número grande de pessoas, acarretando em conhecimento
concentrado naquele que executou a tarefa de gerência. A
gerência não atuante e a falta de um enunciado formal foram
apontadas como demais pontos fracos.
ALUNO 02
Pontos fortes:
• Estratégia de tarefas paralelizadas
• Divisão das tarefas
Pontos fracos:
• Conhecimento dividido
Consistências:
• O paralelismo das tarefas e melhoria
do trabalho
• Nas
perguntas
quantitativas
e
qualitativas é possível perceber o
conhecimento dividido
Discrepâncias:
• O papel cliente foi considerado
indiferente para o aprendizado porém
não é destacado como ponto negativo
ALUNO 04
Pontos fortes:
• Estratégia de tarefas paralelizadas
• Divisão das tarefas e diferentes papéis
• Experiência próxima da realidade
B. Identificação de consistências e discrepâncias
A identificação de consistências e discrepâncias foi
realizada a partir das questões quantitativas e incidências
destas no que foi respondido nas questões qualitativas e viceversa. Desta forma, por exemplo, caso o respondente tenha
selecionado uma resposta que traduza que o papel de cliente
não contribuiu para o trabalho, espera-se que esse aluno tenha
citado o papel de cliente no processo de elicitar requisitos
como ponto fraco da estratégia adotada.
Com isso, foi possível identificar discrepâncias gerais
acerca de informações coletadas nas perguntas que não foram
citadas nas duas questões qualitativas. Observamos que o
papel cliente teve boa receptividade, sendo citado como ponto
positivo nas respostas qualitativas e evidenciadas nas
84
FEES
propiciou aos alunos compreenderem a aplicação de técnicas
de elicitação, bem como a experiência de assumir o papel do
cliente que, geralmente, não é levada em consideração ou,
ainda, não é destacada.
quantitativas, apresentando homogeneidade no conjunto de
respostas fornecidas.
C. Resultados
Após a identificação dos pontos fortes, dos pontos fracos,
das consistências e discrepâncias, foi realizado um cálculo
para mensurar a aceitabilidade da estratégica de ensino
adotada. Para o cálculo, foi considerada a escala Likert [5] de
forma que a primeira resposta teria valor 1, a segunda resposta
teria valor 2, e assim por diante. Para cada questão, foi
identificada aquela que teve maior incidência de votos e, para
as questões que apresentaram duas opções como mais votadas,
contabilizamos a média.
Nossos resultados iniciais corroboram no sentido de que a
estratégia adotada é positiva e auxiliaram os alunos a
compreender melhor as atividades de um Engenheiro de
Requisitos, entretanto, é necessário replicá-la em mais turmas.
Entendemos que, além do questionário, devemos analisar as
observações feitas pelos alunos da pós-graduação como
consultores do projeto. Acreditamos que esse é um dos
trabalhos futuros que pode ser realizado.
A disponibilização do material aqui utilizado bem como os
questionários, ajudará na replicação do estudo em outras
instituições, possibilitando uma melhor análise quanto a
eficácia da estratégia didática proposta.
Na Figura 2 apresentamos a média para as perguntas
relacionadas ao papel de Engenheiro de Requisitos, 3,75, para
o papel de Cliente, 4,37, para o papel de Auditor, 4, para o
papel de Consultor, 5 e, finalmente, para os aspectos gerais a
média, 3,5. A média geral dos itens citados é 4,1 e é este
numeral que define o grau de aceitabilidade da estratégia
educacional adotada no período de 2014.1 na turma de
graduação da disciplina de Engenharia de Requisitos.
REFERÊNCIAS
[1]
[2]
[3]
[4]
[5]
[6]
Fig. 2 - Resultado Obtido
[7]
Considerando 1 como “Ruim”, 2 como “Fraco”, 3 como
“Médio”, 4 como “Bom” e 5 como “Ótimo”, temos duas
categorias com médias entre “Médio” e “Bom”, uma categoria
com “Bom” e duas categorias com médias entre “Bom” e
“Ótimo”. Desta forma, consideramos a estratégia utilizada
positiva com a média geral 4,1 entre “Bom” e “Ótimo”.
[8]
[9]
A categoria “Aspectos Gerais”, com média 3.5, reflete os
pontos fracos citados agregando consistência às informações
apresentadas, conforme contemplado na Tabela 1.
[10]
VI. CONCLUSÃO
Dos pontos fracos apontados pelo alunos em relação a
estratégia didática, destacamos dois: a falta de um enunciado e
o tamanho do grupo de trabalho que foi considerado grande. É
interessante observar que estes pontos fizeram parte da
estratégia. A falta de enunciado formal foi proposital, para
contrapor com uma constante no ensino de engenharia de
requisitos que é o fornecimento de descrições completas para
alunos, o que é irreal e pouco ajuda a tarefa de elicitação, com
exceção da técnica de leitura de documentos. O tamanho dos
grupos de trabalho também faz parte da estratégia utilizada,
pois a coordenação do grupo é um problema real e o tamanho
ajudou na conscientização do problema. Além disso, a
possibilidade de simular um projeto próximo da realidade
[11]
[12]
[13]
[14]
85
J.C.S.P. Leite, .Livro Vivo: Engenharia de Requisitos,
http://livrodeengenhariaderequisitos.blogspot.com/, 2007.
H.S. Becker, Segredos e Truques da Pesquisa, Ed. Zahar, 2008.
L.F. Silva,. J.C.S.P. Leite,. ,K. K. Breitman, “Ensino de Engenharia de
Software: Relato de Experiência”, Workshop de Educação em
Informática (WEI – 2004), 12., Salvador, 2004.
M. Serrano, F. Napolitano, M. Serrano, E. Kinder, M. Douglas, D.
Loyola, B. Rezende, J.C.S.P. Leite “Uma Proposta para Avaliação de
Equipes de Requisitos”. Anais do WER08 - Workshop em Engenharia
de Requisitos, Barcelona, Catalonia, Spain, Setembro 12-13, pp 34- ,
2008.
R.A. Likert, “A technique for the measurement of attitudes” Archives
of Psychology.Vol. 22 n. 140, p. 42-53, 1932.
Google Docs Create Form in http://www.google.com/google-ds/createforms.html, acessado e criado em maio de 2014.
G. Gabrysiak, H. Giese, A. Seibel, S. Nerumann, “Teaching
requirements engineering with virtual stakeholders without software
engineering knowledge”. 2010 IEEE: IEEE Computer Society 2010.
T. Hainey, T.M. Connolly, M. Stansfield, and E.A. Boyle. Evaluation
of a game to teach requirements collection and analysis in software
engineering at tertiary education level. Comput. Educ. 56, 1, 21-35,
January 2011.
A. Belgamo, S. Fabbri. GUCCRA: Contribuindo para a Identificação
de Defeitos em Documentos de Requisitos Durante a Construção
de Modelos de Casos de Uso. Anais do WER04 - Workshop em
Engenharia de Requisitos, Tandil, Argentina, Dezembro 9-10, 2004, pp
100-111.
L.A. Bertini, T.G. Kirner, M.I. Montebelo, I.A. R. Lara. Técnicas de
Inspeção de Documentos de Requisitos de Software: um Estudo
Comparativo. Anais do WER06 - Workshop em Engenharia de
Requisitos, Rio de Janeiro, RJ, Brasil, Julho 13-14, 2006, pp 67-74.
G.N. Kaplan, G.D.S. Hadad, J.H.Doorn, J.C.S.P. Leite. Inspección Del
Lexico Extendido Del Lenguaje. Anais do WER00 - Workshop em
Engenharia de Requisitos, Rio de Janeiro-RJ, Brasilpp 70-91, Julho 1314, 2000.
K.K. Breitman, “Evolução de cenários”, Tese de Doutorado,
Departamento de Informática, Pontifícia Universidade Católica do Rio
de Janeiro, RJ, 2000.
R. Nitsche, L.A. Bortoli, “E-LAL: Um Editor Para o Léxico Ampliado
da Linguagem”,INFOCOMP Journal of Computer Science, vol. 5, no.
3, pp.59-67, 2006.
H. Simon, “Theories of Decision-Making in Economics and
Behavioral. Science” The American Economic Review, Vol. 49, No.3,
Pags. 253-283, 1959.
FEES
Práticas de colaboração no desenvolvimento de
Software com o Governo: impactos na
aprendizagem de alunos de graduação
Camila Ferreira1 , Aline Gonçalves1 , Marisa Santos2 , Paulo Meirelles1 , Hilmer Neri1
1
Faculdade UnB Gama – Universidade de Brasília (UnB), Brasil
Ministério do Planejamento, Orçamento e Gestão (MP), Brasil
{camilaferreira251,alinegsantoss}@gmail.com, [email protected], {paulormm,hilmer}@unb.br
2
versões lançadas a partir daquele ano. Dessa forma, o SPB
passou um processo de estagnação tecnológica e qualquer evolução a ser realizada na ferramenta demandava muito tempo e
esforço dos analistas da SLTI/MP. Sendo assim, o SPB atual
conta com uma série de problemas, especialmente a ausência
de uma ferramenta para desenvolvimento colaborativo e um
ambiente de rede social para as comunidades do projetos.
Nesse contexto, um dos passos para a concretização de
uma nova plataforma para o SPB é a integração com novas
tecnologias, desde uma plataforma colaborativa até sistemas
de controle de versão e de monitoramento da qualidade do
código fonte, gerenciadas e apresentadas em uma plataforma
integrada no back-end e, em especial, no front-end para que os
usuários e as comunidades tenham um conjunto de recursos
para encontrarem os projetos, bem como colaborarem em torno
de um sofware público.
Mesmo com as limitações citadas, o Portal do Software
Público Brasileiro teve em 2013 mais de 600 mil visitantes
únicos, com mais de 1 milhão de acessos, gerando mais de
16 milhões de visitas nas páginas, com um total de mais
de 49 milhões de hits. no Portal SPB. Avaliando apenas os
principais projetos, houveram mais de 15 mil downloads e 4
mil mensagens trocadas nos fóruns. Essa amostra ilustra bem
o potencial do SPB que mesmo com alguns problemas possui
uma boa quantidade de acessos, softwares e usuários.
Para concretizar a evolução do SPB, a Universidade de
Brasília está coordenando tal processo, através de uma equipe
heterogêne de alunos, professores e profissionais, que estão
aplicando práticas colaborativas de desenvolvimento de software e gestão de projeto que impactam no projeto em si
e, em especial, na aprendizagem dos alunos envolvidos, que
estão tendo contato com métodos ágeis como XP e Scrum,
além de novas ferramentas de suporte ao desenvolvimento de
software. Portanto, neste artigo iremos relatar, na Seção II,
apresentamos uma visão geral da arquitetura e das tecnologias livres que estão sendo usadas e evoluídas para compor
a nova plataforma do SPB; na Seção III, as metodologias
usadas e as principais práticas adaptadas à equipe em questão;
na Seção IV, discutimos os resultados de uma pesquisa de
levantamento da aprendizagem dos alunos do projeto; na
Resumo—O Portal do Software Público Brasileiro (SPB), na
prática, é um sistema web que se consolidou como um ambiente
de compartilhamento de softwares. O projeto de evolução deste
portal está sendo desenvolvido pela Universidade de Brasília e
conta com integrantes de diversos perfis e níveis de formação.
O projeto utiliza algumas práticas de métodos ágeis em sua
metodologia de desenvolvimento. O objetivo deste artigo é relatar
a experiência no desenvolvimento, ao lado do Ministério de
Planejamento, bem como mostrar o quanto o projeto tem
contribuído para a formação dos seus integrantes.
Index Terms—Engenharia de Sofware, Software Livre, Software Público, Evolução de Software
I. I NTRODUÇÃO
O governo federal brasileiro vem nos últimos anos buscando
melhorias nos seus processos de desenvolvimento e adoção de
software. Desde 2003, a recomendação da adoção de software
livre passou a ser uma política incentivada na esfera federal,
inicialmente com a criação do Guia Livre1 . Hoje, tal iniciativa
é coordenada pelo Comitê Técnico de Implementação de
Software Livre do Governo Federal2 .
No contexto da promoção do software livre no governo
federal, a Secretaria de Logística e Tecnologia da Informação
(SLTI) do Ministério do Planejamento, Orçamento e Gestão
(MP) inaugurou em 2007, o Portal do Software Público
Brasileiro (SPB), que, na prática, é um sistema web que
se consolidou como um ambiente de compartilhamento de
projetos de software no governo. Por exemplo, a Instrução
Normativa 04/20123 indica que os gestores devem consultar
as soluções existentes no Portal do SPB antes de realizar uma
contratação de software. Hoje, com o portal do SPB tem cerca
de 69 comunidades de desenvolvimento e mais de 200.000
usuários cadastrados.
Entretanto, a evolução do SPB foi comprometida, desde
2009, quando a plataforma do SPB não acompanhou a evolução do seu arcabouço base, o OpenACS4 . Com isso, não tendo
1 governoeletronico.gov.br/acoes-e-projetos/guia-livre
2 softwarelivre.gov.br
3 governoeletronico.gov.br/biblioteca/arquivos/instrucao-normativa-no-04de-12-de-novembro-de-2010
4 openacs.org
86
FEES
Seção V, apresentamos as considerações finais deste relato
de experiência.
Para Forge para SVN estamos utilizando o Trac, que é
uma ferramenta open source para controle de mudanças
em projetos de desenvolvimento;
• Para sistemas de controle de versão estamos utilizando
SVN e Git, que são ferramentas open-source para controle de mudanças em projetos de desenvolvimento;
• Para Forge para Git estamos utilizando o GitLab, que é
um software livre de colaboração de código online que
utiliza a ferramenta de gerência de código fonte Git;
• Para sistema de gerenciamento estamos utilizando o
Redmine, que é uma aplicação web de gerenciamento
de projetos que disponibiliza diversas ferramentas para
auxiliar a gestão e manutenção de um projeto;
• Para suporte a Single Sign On estamos utilizando o
Mozilla Persona, que foi desenvolvido pela Mozilla e
permite o suporte a single sign on;
• Para Sistema de Integração contínua estamos utilizando o
Jenkins, que é uma aplicação web de integração contínua
de construção de projetos.
Para integrar todas estas ferramentas estamos utilizando o
Colab, que é uma plataforma de integração de ferramentas.
Nele, são também integradas as interfaces das ferramentas para
que, ao navegar, o usuário tenha a sensação de estar navegando
em uma única ferramenta.
•
II. A RQUITETURA
O sistema que irá atender a evolução e reformulação do
Portal do Software Público Brasileiro é composto por diversos módulos, os quais irão comunicar-se entre si de forma
organizada e integrada para suprir as necessidades do projeto.
Figura 1. Proposta de arquitetura do Novo Portal do Software Público
III. M ETODOLOGIA
Pelo contexto colaborativo e empírico do desenvolviemento
de software livre, adotamos algumas práticas dos ágeis, baseada em Scrum e Extreme Programming (XP). O XP prover
o suporte aos aspectos mais técnicos, enquanto o Scrum
provê práticas e técnicas para gerenciamento, planejamento
e acompanhamento [1], [2].
Para melhor gerenciamento a duração total do projeto foi
dividida em sete Releases, cada uma com duração de quatro
meses. Ao final de cada release é realizada uma entrega. Ou
seja, serão ao todo sete etapas de resultados a serem disponibilizadas ao longo da execução do projeto. Para homologação e
ateste técnico, é disponibilizado um resultado prévio um mês
antes da entrega da Release, chamadas de Releases Candidatas.
Assim, a partir da disponibilização do resultado da release
candidata, temos trinta dias para ajustes, correções e testes
finais.
Além disso, são disponibilizados resultados intermediários
mensalmente. Trata-se da oportunidade da equipe da SLTI/MP
poder fornecer feedbacks de possíveis alterações ou novas
funcionalidades, as quais são tratados como novos itens no
backlog para priorização.
A equipe é formada, em sua maioria, por estudantes, 16
de graduação e 5 de pós-graduação, de engenharia de software, ciência da computação, artes e desenho industrial, da
Universidade de Brasília e da Universidade de São Paulo,
os quais estão tendo sua formação complementada por meio
dessa oportunidade de participarem como protagonistas em um
projeto de grande magnitude. Cinco professores coordenam
as subequipes do projeto e dois desenvolvedores, criadores
da duas principais ferramentadas livres adotadas, atuam como
No início do projeto realizamos estudos de possíveis ferramentas que pudessem ser utilizadas para atender as necessidades do projeto, chegando então na lista apresentada abaixo.
Na análise realizada chegamos ao entendimento que utilizar
elementos já oferecidos por softwares livres existentes seria o
ideal, pois eles já atendem às nossas necessidades, evitando o
retrabalho e customizando os elementos necessários.
As ferramentas que serão utilizadas para suprir essas necessidades serão:
•
•
•
•
Para lista de e-mail estamos utilizando o Mailman na
versão 2, que é um software gratuito para gerenciamento
de discussão eletrônica de e-mail e listas e- newsletter;
Para Chat estamos utilizando Punjab BOSH (XMPP),
que é uma interface HTTP cliente jabber. É um gerenciador de conexão BOSH que permite conexões de
clientes persistentes para um servidor XMPP (protocolo
de comunicação para mensagens orientadas a middleware
baseado em XML);
Para Plataforma de Buscas estamos utilizando Apache
Solr, que é uma plataforma de busca open source da
Apache Lucene escrita em Java;
Para rede social estamos utilizando o Noosfero que é
uma plataforma web livre para criação de redes sociais
com blog, e-Portifólios, CMS, RSS, discussão temática,
agenda de eventos, galeria de imagens, chat, entre outros.
Ele foi desenvolvido pela Cooperativa de Tecnologias
Livres – Colivre 3 em 2007, sob a licença AGPL v.3,
com a proposta de permitir ao usuário criar sua própria
rede social personalizada, livre e autônoma;
87
FEES
arquitetos de software, liderando as decisões técnicas. Além
deles, três analistas do SLTI/MP acompanham e também
participam da gestão do projeto e das decisões tecnológicas.
Em resumo, os integrantes estão divididos em subequipes que
atuam, no momento, em quatro frentes: Proxy de Integração,
Rede Social, Monitoramento de código-fonte e Design de
interação. Contamos ainda com um professor cuidando mais
de perto do gerenciamento do projeto como um todo.
Pela natureza do projeto, utilização de práticas ágeis e
proximidade dos analistas do SLTI/MP, utilizamos user stories
para levantamento de requisitos. São feitas reuniões de acompanhamento do projeto com os analistas que seguem de perto
o andamento do mesmo e assim temos a chance de escrever
juntamente com os administradores do SPB as user stories.
É utilizada a prática de programação em par para o desenvolvimento de todas as histórias. Temos observado que tal
prática facilita o nivelamento e a disseminação do conhecimento entre todos os membros da equipe sem atrapalhar a
produtividade da mesma, com essa prática a validação e a
verificação da história é mais confiável por estar sendo feito
por pelo menos duas pessoas.
Devido a formação diversificada, a disponibilidade de horário variadas e a distribuição geográfica da equipe (com
integrantes de Brasília, da Bahia e de São Paulo), precisamos
definir algumas práticas que facilitassem a comunicação entre
os integrantes.
Para informar o status das tarefas do projeto e evitar falhas
de comunicação mantemos uma lista de e-mail com todos
os integrantes do projeto, na qual é relatado diariamente o
status das histórias da sprint atual e eventuais problemas que
precisam ser resolvidos.
Para manter o controle das atividades do projeto, utilizamos
a ferramenta de gerenciamento Redmine com configuração
ágil, onde são mantidos o product backlog com as histórias de
usuários, as histórias técnicas e suas respectivas tarefas. Para
cada história, há um responsável associado, o qual responde
pelo progresso da história, e uma pontuação, que corresponde
ao esforço planejado para a mesma.
Baseado nos eventos da metodologia ágil Scrum, a equipe
realiza algumas cerimônias, dentre elas:
•
•
•
IV. R ELATO DE E XPERIÊNCIA
Para verificar o quanto o projeto está auxiliando a formação
do aluno em diferentes aspectos, foi aplicado um questionário
na equipe de desenvolvimento do Novo Portal do Software
Público, onde os mesmos poderiam expressar o quanto estão
aprendendo com o projeto.
O questioário foi respondido por 17 integrantes do projeto
que têm entre 20 e 26 anos, os quais então entre o 5o e o 10o
semestre do curso de Engenharia de Software.
A primeira questão pretendia averiguar o nível de conhecimento dos entrevistados, em uma escala de 1 a 5, em
relação às ferramentas que estão sendo utilizadas no projeto.
Como resultados tivemos que 63% responderam nível 3, 19%
responderam nível 2 e 19% responderam nível 4.
A segunda questão pretendia averiguar o quanto o projeto
está contribuindo para a formação do entrevistado. Em uma
escala de 0 a 5, 69% dos entrevistados responderam "5 Contribui muito, mais que determinadas disciplinas", 19% dos
entrevistados responderam "4 - Contribui, no mesmo nível de
muitas disciplinas"e 13% dos entrevistados responderam "3 Contribui, da mesma forma que um estágio convencional".
A terceira questão está relacionada, também em uma escala
de 0 a 5, a quanto o projeto atrapalha a sua performance
nas disciplinas da graduação. Como resultados, 19% dos
entrevistados responderam "3 - Atrapalha minha graduação da
mesma forma que um estágio", 50% dos entrevistados responderam "2 - Atrapalha moderadamente", 19% dos entrevistados
responderam "1 - Atrapalha pouco, menos que um estágio"e
13% dos entrevistados responderam "0 Não atrapalha em nada
na minha graduação".
A quarta questão averigua o quanto, em uma escala de
0 a 5, os conhecimentos adiquiridos durante a execução do
projeto ajudam os entrevistados nas disciplinas da graduação.
Como resultados, 7% dos entrevistados responderam "5 Ajuda muito, sempre utilizo os conhecimentos adiquiridos nas
disciplinas da graduação ", 47% respondeu "4 Ajuda muito,
utilizo os conhecimentos com frequência nas disciplinas da
graduação", 27% respondeu "3 - Ajuda, utilizo os conhecimentos nas disciplinas da graduação"13% respondeu "2 - Ajuda
moderadamente, as vezes utilizo os conhecimentos adquiridos
no projeto"e 7% respondeu "1 – Ajuda um pouco, utilizo
pouco os conhecimentos do projeto".
E a quinta questão perguntou o quanto, em uma escala de
0 a 5, o entrevistado acredita que o projeto do Novo SPB
vai contribuir em experiência para o mercado de trabalho.
Como resultados, 38% responderam "5 O projeto me tornará
experiente para o mercado de trabalho", 38% responderam "4
- O projeto me dará muita experiência para o mercado de
trabalho"e 25% responderam "3 - O projeto me dará uma boa
experiência para o mercado de trabalho".
Stand-up: a equipe realiza stand-up diários fisicamente,
onde cada frente de trabalho comunica o que foi feito,
o que está sendo feito e eventuais problemas. Para que
os integrantes da equipe localizados em estados diferentes
acompanhem o stand-up, é utilizada uma ferramenta para
hangout.
Reuniões de planejamento: no início de cada sprint,
é realizada uma reunião de planejamento na qual são
definidas as histórias que seram desenvolvidades e essas
histórias são pontuadas com a prática Planning Poker.
Reuniões de encerramento: ao final de cada sprint, é realizada uma reunião de encerramento, onde é apresentado
o que foi desenvolvido e concluído para a sprint e o que
pode ser melhorado.
A. Discussão dos resultados
Já era esperado o resultado da questão relacionada ao
nível de experiência da equipe com as ferramentas a serem
utilizadas pois, era sabido que por serem alunos de graduação
88
FEES
já poderiam ter tido alguma experiência com as ferramentas nas disciplinas sem chegar a ser usuário avançado ou
desenvolvedores experientes nas mesmas, mas teriam algum
conhecimento que auxiliaria na execução das atividades.
O projeto tem como objetivo auxiliar na formação dos
alunos e por isso foi questionada a opinião dos alunos à respeito da contribuição trazida pelo projeto para sua formação,
obtivemos respostas positivas para essa pergunta pois o projeto
proporciona um ambiente de aprendizado e conhecimento de
novas tecnologias e metodologias de desenvolvimento além de
adiantar problemáticas que ainda serão vistas nas disciplinas
da graduação.
Sabendo que o projeto retira do aluno horas semanais que
poderiam estar destinadas ao estudo para as disciplinas da
graduação, trouxemos a questão de quanto o projeto atrapalha
no desempenho das disciplinas da graduação. As respostas
foram mais variadas, alguns responderam que não atrapalha
em nada na graduação, outros que atrapalham menos ou da
mesma forma que um estágio e a maioria respondeu que
atrapalha moderadamente, ou seja, o projeto está atrapalhado
na graduação mas é compensado pelo conhecimento adquirido
já que nenhum entrevistado respondeu que está se sentindo
prejudicado por causa do projeto.
O projeto têm auxiliado nas disciplinas da graduação, segundo os entrevistados, como já mencionado, sendo assim o
projeto adianta para os integrantes alguns assuntos que ainda
seriam vistos nas disciplinas de graduação, diminuindo a curva
de aprendizados dessas disciplinas durante a graduação.
Uma preparação para o mercado de trabalho é importante
e segundo os entrevistados o projeto está trazendo uma boa
experiência profissional para os seus integrantes. O contexto
de um projeto real com prazos e necessidades específicas em
diferentes áreas da engenharia de software devem ter sidos
pensadas pelos entrevistados para a resposta desta questão.
O projeto também tem beneficiado o aprendizado dos alunos
em temas relacionados a Administração Pública pois o Portal
do SPB é um sistema web que também visa beneficiar aos
órgãos das esferas federal, estadual e municipal. Essa relação
com o governo auxilia tanto no crescimento profissional, uma
vez que estabelece um contato com usuários de governo, como
uma visão sobre negócios que envolvem toda a Administração
Pública.
ao conhecimento prévio adquirido não somente de práticas
ágeis mas também de novas linguagens de programação. Ficou
conhecido também que tempo gasto trabalhando no projeto
atrapalha moderadamente o desempenho na graduação dos
integrantes do projeto, mas o esforço será recompensado com
uma boa experiência para o mercado de trabalho.
De maneira geral o projeto tem ajudado os seus integrantes
a aprender a lidar com dificuldades encontradas no desenvolvimento de software, está trazendo conhecimento técnico e
gerencial para os membros da equipe além de auxiliar nas
relações interpessoais.
VI. T RABALHOS F UTUROS
Como proposta de trabalho futuro seria interessante abordar
como a presença dos profissionais chamados sêniors no projeto
supracitado contribui para a formação dos alunos integrantes
do mesmo bem como o aprendizado de mercado que esse
profissionais passaramm para os alunos.
R EFERÊNCIAS
[1] K. Schwaber and M. Beedle, Agile Software Development with Scrum,
1st ed. Upper Saddle River, NJ, USA: Prentice Hall PTR, 2001.
[2] B. Fitzgerald, G. Hartnett, and K. Conboy, “Customising agile methods
to software practices at intel shannon,” Eur. J. Inf. Syst., pp. 200–213,
2006.
V. C ONCLUSÃO
Neste projeto são utilizadas diversas ferramentas que não
têm sua linguagem de programação em comum e sobretudo
são relativamente novas no mercado e mesmo com esses
impecilhos podemos afirmar, a partir do relato de experiência, que os alunos não tinham experiêcia nas ferramentas a
serem utilizadas no projeto mas esta aparente dificuldade não
impediu os alunos de contribuir com o projeto
Foi possível concluir também que o projeto está contribuindo com a construção da formação dos alunos, pois coloca
em prática algumas situações antes vistas apenas na teoria
dentro da sala de aula. O desempenho dos alunos nas disciplinas da graduação também é ajudado pelo projeto,devido
89
FEES
Experiência no Projeto Framework de Soluções de TI
Thatiany Lima de Sousa, Rejane Maria da Costa Figueiredo, Elaine Venson, Ricardo Ajax Koslovisk
Centro de Qualidade e Testes de Software - CQTS
Universidade de Brasília – Faculdade do Gama
Gama, Brasil
[email protected], {RejaneCosta, ElaineVenson, RicardoAjax}@unb.br
relatos pelo TCU, é a dependência excessiva do fornecedor
[3]. O trabalho de transferência de conhecimento, no primeiro
ano de execução, foi conduzido por Brito [4] com metodologia
descritiva e procedimento de estudo de caso. Dando
continuidade, para a avaliação da proposta, objetiva-se
executar um projeto piloto, fazendo uso da metodologia
explicativa e procedimento de pesquisa-ação.
Resumo— A contratação de serviços de Tecnologia da
Informação (TI) tem se tornado uma prática comum nas
organizações. Com a crescente popularidade das metodologias
ágeis, as organizações públicas estão adotando-as para
realizarem gestão de demandas de desenvolvimento de software.
A fim de contribuir com uma necessidade real do governo, uma
das frentes do projeto Framework de Soluções de TI é de
Melhoria de Processo, a qual tem o objetivo de produzir
conhecimentos e definir um processo de gestão de demandas,
baseado em princípios ágeis, para um Ministério do governo
federal que recorre à contratação de fornecedor de
desenvolvimento de software. Visando a redução da dependência
excessiva do fornecedor, um dos aspectos abordados nesta frente
é a transferência de conhecimento. Com o intuito de
compartilhar conhecimentos e experiências, este trabalho tem o
objetivo de apresentar os principais resultados e relatar a
experiência dos autores na condução da Frente Melhoria de
Processo – Transferência de Conhecimento. No relato, também
são apresentados as dificuldades encontradas, o aprendizado
adquirido durante a execução do projeto e as sugestões de
trabalhos futuros.
Com o intuito de compartilhar as experiências e os
conhecimentos adquiridos com o projeto, o objetivo deste
trabalho é apresentar os principais resultados e relatar a
experiência dos autores na condução da Frente Melhoria de
Processo – Transferência de Conhecimento. Para isso, serão
apresentados os principais resultados alcançados, o
aprendizado adquirido, as principais dificuldades encontradas
e os resultados esperados.
Este artigo está organizado em cinco Seções. Na Seção II
são apresentados os conceitos relacionados à contratação de
serviços de Tecnologia da Informação (TI) e transferência de
conhecimento em contratações. Na Seção III são apresentadas
informações sobre o projeto de pesquisa, Framework de
Soluções de TI. Na Seção IV é apresentado o relato de
experiência com a execução do projeto. Por fim, na Seção V
são apresentadas as considerações finais e as sugestões de
trabalhos futuros.
Palavras-chave— transferência de conhecimento; contratações
;software; metodologias ágeis; organizações públicas
I. INTRODUÇÃO
As organizações públicas tem buscado melhorar os seus
processos acreditando que produzirão produtos com maior
qualidade. Desde 2001, as metodologias ágeis vêm ganhando
crescente popularidade, inclusive dentro da administração
pública [1].
II. CONTRATAÇÕES DE SERVIÇOS DE TI
A terceirização de serviços de TI tem se tornado uma
prática comum nas empresas [5]. No Brasil, a APF é uma das
principais contratantes de serviços de TI.
Em 2013, o Tribunal de Contas da União (TCU) publicou
um acórdão para relatar a adoção de métodos ágeis pelas
organizações públicas [2]. Das organizações analisadas,
algumas recorriam à contratação de fábrica de software e
faziam uso dessas metodologias para realizarem a gestão das
demandas de desenvolvimento de software.
Devido a irregularidades e impropriedades encontradas em
contratações, o TCU recomendou a elaboração de um modelo
de licitações e contratação de serviços de TI. Como resultados,
foram elaborados: a Instrução Normativa nº 04/2010 (IN
04/2010) [6], o Guia Prático de Contratações de TI (MCTI)
[7], o Processo de Contratação de Serviços de TI para
Organizações Públicas Brasileiras (PCSTI) [8] e o Guia de
Boas Práticas em Contratação de Soluções de TI [3].
No contexto de pesquisa e desenvolvimento envolvendo
um Órgão da Administração Pública Federal (APF), a
Universidade de Brasília (UnB) possui um Termo de
Cooperação com um Ministério do Governo Federal. O
projeto teve início em 2012 e tem como um dos objetivos
apoiar a definição de um processo de gestão de demandas de
desenvolvimento de software, baseado em metodologias e
princípios ágeis, e alinhado a legislação pertinente.
As contratações de fábrica de software envolvem riscos e
desafios. Um dos ricos é a dependência excessiva dos
fornecedores [3] [5]. Com o objetivo de reduzir essa
dependência, as normas e modelos preveem a execução de
atividades de transferência de conhecimento no início, durante
e no fim da contratação.
Um dos aspectos abordados no projeto é a transferência de
conhecimento, uma vez que um dos riscos das contratações,
90
FEES
radiodifusão, postais e de telecomunicações. O Ministério
apresenta um baixo quantitativo de servidores de TI. Cerca de
78% da força de trabalho do órgão é de terceirizados e apenas
cerca de 18% são servidores da casa [15]. Como
consequência, o órgão recorre a contratação de serviços de TI
e fica a cargo apenas da gestão dos contratatos.
A. Transferência de Conhecimento em Contratações
A Gestão do Conhecimento para Nonaka e Takeuchi [9]
está baseada na conversão do conhecimento tácito-explícito,
por meio das etapas: combinação, internalização, socialização
e externalização do conhecimento. O ciclo entre as etapas
apresentadas anteriormente denomina-se ciclo SECI. Chau,
Maurer e Melnik afirmam que o ciclo SECI pode ser utilizado
para a transferência de conhecimento em projetos de
desenvolvimento de software [10]. Além desse ciclo, o
modelo eSourcing Capability Model for Service Providers for
clients (e-SCM-CL) apresenta sete práticas voltadas para
transferência de conhecimento em contratações [11].
Atualmente, os três contratos mais significativos
gerenciados pela TI são relacionados à fábrica de software,
qualidade (validação dos entregáveis e contagem em pontos de
função) e infraestrutura de TI.
Além do baixo quantitativo dos servidores, o órgão
apresenta a Metodologia de Gestão de Projetos de TI (MGPTI)
[16], a qual estabelece um ciclo de gerenciamento de projetos
de TI dividido em fases. Após cada fase, são realizadas
reuniões de decisões que autorizam a passagem do projeto
para a próxima fase.
Alguns estudos mostram que a transferência de
conhecimento impacta no sucesso das contratações [12] [13]
[14]. Devido a essa importância, observa-se que como o MCTI
e o PCSTI são alinhados a IN 04/2010, ambos possuem
atividades e artefatos, bem similares, voltados para
transferência de conhecimento.
Devido à insatisfação com o modelo corrente de gestão de
contrato, o órgão objetiva adotar metodologias ágeis para
realizar a gestão das demandas de desenvolvimento de
software.
Outra realidade é a crescente adoção de metodologias
ágeis por organizações públicas brasileiras. Em 2013, o TCU
publicou um acórdão [2] em que relata a adoção de
metodologias ágeis por organizações públicas. A insatisfação
das organizações com o modelo corrente de desenvolvimento
ou gestão de demandas tem impulsionado as organizações a
adotarem metodologias ágeis para tal fim.
B. Frente Melhoria de Processo
O objetivo desta frente de trabalho é definir um processo
de gestão de demandas de desenvolvimento de software,
alinhado a legislação pertinente e baseado em metodologias e
princípios ágeis, a ser adotado pelo Ministério.
III. O PROJETO
Atualmente, o projeto está no segundo ano de execução. O
segundo ano da frente contempla pesquisas acadêmicas e a
execução de atividades como: detalhamento de atividades de
validação de software; estabelecimento de atividades de
transferência de conhecimento; evolução do modelo de
critérios de aceitação do produto; apoio à implantação do
processo por meio de projetos piloto; e avaliação e ajustes do
processo, a partir dos resultados da execução do projeto piloto.
O projeto Framework Soluções de TI é oriundo de um
Termo de Cooperação entre a UnB, representada pelo
laboratório de pesquisa, Centro de Qualidade e Testes de
Software (CQTS), e um Ministério do Governo Federal
Brasileiro. O projeto foi criado em 2012, com o objetivo de
produzir conhecimentos, assentados em bases acadêmicocientíficas, que possam viabilizar a elaboração e a implantação
de um framework de soluções para a Coordenação Geral de TI
(CGTI) do Ministério, de forma a proporcionar um
alinhamento entre as suas estratégias e ações de
gerenciamento de TI com a estratégia de governança em TI do
Ministério.
Assim, nesta frente de trabalho são abordados três
aspectos: verificação e validação de software, transferência de
conhecimento e adaptação da metodologia Scrum. Além
desses aspectos, há o contexto de gerenciamento de projetos
sob o olhar da MPGTI. Uma vez que, o processo proposto
deve estar alinhado a metodologia de gerenciamento de
projetos adotada pelo Ministério.
Devido à multidisciplinaridade do projeto foram definidas
três frentes de trabalho no contexto de: Processo de Gestão de
Demandas de Desenvolvimento Ágil para Contratação de
Fábrica de Software; Arquitetura de Software; e Infraestrutura
de TI. Neste artigo, o foco é a frente de definição de processos
nomeada de “Melhoria de Processos”.
C. Transferência de Conhecimento
O trabalho de transferência de conhecimento [4], no
primeiro ano de execução, foi conduzido por Brito com
metodologia descritiva e procedimento de estudo de caso. A
proposta de Brito teve como pilares o ciclo SECI apresentado
por Nonaka e Takeuchi [9] e as práticas de transferência de
conhecimento do modelo e-SCM-CL [11].
Inicialmente, a frente era composta por seis integrantes, 3
professores e 4 estudantes bolsistas. Atualmente é composta
por sete integrantes, 4 professores e 3 estudantes bolsistas. No
segundo ano do projeto, o integrante bolsista que trabalhava
com transferência de conhecimento finalizou a graduação e
uma nova estudante, primeira autora deste artigo, integrou o
grupo. A substituição ocorreu para que fosse possível dar
continuidade ao trabalho de Brito [4].
Futuramente, para realizar a avaliação da proposta de
Brito, será executado um projeto piloto do processo proposto.
Para isso, pretende-se aplicar a metodologia explicativa com o
procedimento de pesquisa-ação. Para a execução do projeto
será levado em consideração as características ideais de um
projeto piloto, sugeridas por Cohn [17]. Para a avaliação será
A. A Organização Pública
A organização participante do termo de cooperação é um
Ministério cujas áreas de competência são os serviços de
91
FEES
levado em consideração o aspecto de satisfação dos receptores
[18].
o projeto piloto; transferir conhecimento dos pesquisadores
para os envolvidos do Ministério; e participar e contribuir nos
eventos acadêmicos da área.
IV. RELATO DE EXPERIÊNCIA
A. Dinâmica de Trabalho
Para realizar a definição do processo, os integrantes
realizaram estudos de alguns casos de adoção de metodologias
ágeis por organizações públicas; estudos de ferramentas de
modelagem de processos, para a escolha da ferramenta mais
adequada para o contexto; e análise de editais de outras
organizações, que adotaram ágeis, com o intuito de identificar
os artefatos mais recorrentes.
Como resultado, do primeiro ano de execução, houve a
definição do processo de gestão de demandas, nomeado de
ProGeDDAS. O resultado inclui a definição das atividades de
transferência de conhecimento. Para isso, Brito [4] realizou:
uma revisão sistemática sobre transferência de conhecimento
em processos de contratação de fábricas de software por
organizações públicas; definição de atividades, tarefas e
artefatos de transferência de conhecimento, respeitando o
paradigma ágil Scrum; e detalhamento de atividades de
transferência de conhecimento.
Para a realização do trabalho, a equipe utilizou algumas
ferramentas. Para a modelagem do processo utilizou-se a
ferramenta Bizagi Process Modeler1. Para a organização dos
estudos identificados nas bases de dados eletrônicas utilizouse o Zotero2. Já para a distribuição e acompanhamento das
atividades, utilizou-se o Trello3.
Durante a execução do segundo ano do projeto foi possível
identificar pontos com necessidades de melhorias que foram
abordados no primeiro ano de execução. Como continuidade
do trabalho de Brito [4], no segundo ano de execução foram
realizadas: reuniões semanais com os envolvidos do
Ministério para a validação da proposta realizada no primeiro
ano de execução; adaptação da proposta de Brito conforme as
mudanças solicitadas nas reuniões com os envolvidos do
Ministério; detalhamento dos artefatos definidos, quando
possível; e apresentação das características ideais de um
projeto piloto.
Em relação à interação junto ao órgão, são realizadas
reuniões para apresentação e análise do processo.
Internamente, também, são realizadas reuniões, conforme
necessário (geralmente semanais), para acompanhamento e
resolução de impedimentos. Para a comunicação interna
utiliza-se lista de e-mail.
O impacto da rotatividade de pessoal é minimizado com o
compartilhamento de conhecimento entre todos os membros
da equipe. Cada integrante procura entender todos os aspectos
que são abordados no projeto. Além disso, quando possível,
antes da saída de determinado membro há a inserção de um
novo integrante com certa antecedência.
As atividades voltadas para transferência de conhecimento
e os artefatos definidos para o ProGeDDAS estão na Tabela I.
TABELA I.
ATIVIDADES E ARTEFATOS
Atividades
Artefatos
Definir visão da solução
Documento de visão
Revisar visão da solução
Documento de análise e viabilidade
Workshop de solução
Backlog do produto
Escrever histórias de usuário da
primeira sprint
Escrever histórias de usuário da
próxima sprint
B. Aprendizado adquirido
O projeto contribui para uma necessidade real de uma
Organização Pública Federal Brasileira. Tal contribuição
permitirá a organização melhorar a sua forma de trabalho,
visando à obtenção de melhores resultados. Permitindo,
futuramente, a melhor aplicação das verbas públicas
empregadas em projetos de software.
Em relação à contribuição acadêmica, o projeto contribui
para as pesquisas de uma área em crescente demanda, a
adoção de metodologias ágeis por parte das organizações
públicas brasileiras. Além disso, permite aos alunos bolsistas a
vivência prática das teorias estudadas na universidade.
Os principais aprendizados proporcionados pelo projeto
são relacionados à: contratações de serviços TI,
principalmente do serviço de fábrica de software; legislação
aplicável às contratações; metodologias ágeis; adoção de
metodologias por parte das organizações públicas; e
transferência de conhecimento em contratações de fábrica de
software.
A experiência proporcionada pelo projeto é importante
para a formação dos alunos de engenharia de software, uma
vez que mescla a teoria com a prática. Isso faz com que o
aluno saia mais capacitado e preparado para o mercado de
trabalho. O projeto proporciona aos bolsistas um ambiente de
projeto real com prazos e necessidades reais. Dessa forma, o
projeto de pesquisa colabora para a formação profissional dos
Documento de arquitetura
Código fonte documentado
Colaborar com o time scrum
Testes unitários automatizados
Realizar reunião de revisão da
sprint
Testes de integração
Treinar usuários
Evidência de teste
Modelo de entidade relacionamento
Dicionário de dados
Manual do usuário
Relatório de qualidade
Lições aprendidas
Wiki
Neste segundo ano, alguns pontos ainda deverão ser
aprofundados, como: apoiar a implantação do novo processo
de gestão de demandas, a partir do uso de projeto piloto;
definir treinamentos; acompanhar o projeto piloto; ajustar o
novo processo proposto, com base nos resultados obtidos com
1
http://www.bizagi.com/
https://www.zotero.org/
3
https://trello.com/
2
92
FEES
Universidade de Brasília e parcialmente financiada pelo
projeto de pesquisa Framework de Soluções de Tecnologia da
Informação.
bolsistas, para a pesquisa acadêmica e para a resolução de uma
situação problemática real do governo.
C. Dificuldades encontradas
Durante a execução do projeto algumas dificuldades foram
encontradas no segundo ano de execução. A principal
dificuldade está relacionada à execução do projeto piloto. Uma
vez, que o órgão apresenta três contratos distintos relacionados
aos serviços de TI (desenvolvimento, qualidade e
infraestrutura) e os três estão presentes no ProGeDDAS.
REFERÊNCIAS
[1]
[2]
Outras dificuldades encontradas e observadas foram:
alinhamento da metodologia ágil Scrum à MGPTI do órgão;
compatibilidade de agenda de reuniões entre os pesquisadores
e os envolvidos do órgão e preocupação com a mudança da
cultura organizacional atual.
[3]
[4]
A última dificuldade é um desafio a ser enfrentado durante
a execução do projeto piloto. Dado que, segundo relatos dos
envolvidos do Ministério, atualmente, não é cultura da
organização a participação ativa da área de negócio durante a
execução dos projetos de software.
[5]
[6]
D. Resultados esperados com a pesquisa
Ao concluir o Projeto (Frente Melhoria de Processo) são
esperados os seguintes impactos no contexto do Ministério: (i)
geração de maiores benefícios para a CGTI e seus clientes; (ii)
redução de riscos e atrasos inesperados nos projetos; (iii)
melhoria na comunicação e no envolvimento dos usuários de
negócios nos projetos; (iv) maximização no valor de negócio
gerado pelos produtos de software entregues; e (v) redução de
dependência do fornecedor.
[7]
[8]
[9]
[10]
V. CONSIDERAÇÕES FINAIS E TRABALHOS FUTUROS
Algumas organizações públicas estão adotando
metodologias ágeis para gerenciar as demandas de
desenvolvimento de software. Estudos sobre transferência de
conhecimento em contratações de fábrica de software são
necessários e importantes para o crescimento da academia e
das organizações. Além disso, a transferência de
conhecimento é um fator crítico para o sucesso dos projetos e
a redução de dependência do fornecedor por parte das
organizações. Projetos de pesquisa dessa natureza, que
mesclam a teoria com a prática e que visam à resolução de um
problema real enfrentado pelo governo, são importantes para o
desenvolvimento das organizações públicas, da academia e
dos estudantes. O projeto proporciona o aluno vivenciar a
resolução de um problema prático, o que é importante para
uma graduação de engenharia. Como trabalhos futuros do
projeto sugere-se a definição de atividades, tarefas e artefatos
de transferência de conhecimento para o processo de
manutenção e a execução de projetos similares em outras
organizações públicas.
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
AGRADECIMENTOS
Este trabalho foi realizado no laboratório de pesquisa
Centro de Qualidade e Testes (CQTS) da Faculdade Gama da
93
C. de O. Melo e G. R. Ferreira, “Adoção de métodos ágeis em uma
Instituição Pública de grande porte-um estudo de caso”, in Workshop
Brasileiro de Métodos Ágeis, Porto Alegre, 2010, vol. 24.
Brasil, “Acórdão No 2314/2013. Levantamento de Auditoria.
Conhecimento Acerca da Utilização de Metodologias Ágeis nas
Contratações de Software Pela Administração Pública Federal”. 2013.
Brasil, “Guia de Boas Práticas em Contratação de Soluções de
Tecnologia da Informação”. 2012.
M. F. Brito, “Transferência de conhecimento em processos de
contratação de fábricas de software por organizações públicas
federais”, Trabalho de Conclusão de Curso, Faculdade Gama,
Universidade de Brasília, Brasília, 2013.
M. Alaranta e S. L. Jarvenpaa, “Changing IT Providers in Public Sector
Outsourcing: Managing the Loss of Experiential Knowledge”, in
System Sciences (HICSS), 2010 43rd Hawaii International Conference
on, 2010, p. 1–10.
Brasil, “Instrução Normativa No04, de 12 de novembro de 2010. Dispõe
sobre o processo de contratação de Soluções de Tecnologia da
Informação pelos órgãos integrantes do Sistema de Administração dos
Recursos de Informação e Informática (SISP) do Poder Executivo
Federal.” 2010.
Brasil, “Guia Prático para Contratação de Soluções de Tecnologia da
Informação”. 2011.
C. S. da Cruz, E. L. P. de Andrade, e R. M. da C. Figueiredo, Processo
de Contratação de Serviços de Tecnologia da Informação para
Organizações Públicas. Brasília, 2011.
I. Nonaka e H. Takeuchi,
. Rio de Janeiro:
Campus, 1997.
T. Chau, F. Maurer, e G. Melnik, “Knowledge sharing: Agile methods
vs. tayloristic methods”, apresentado em 2012 IEEE 21st International
Workshop on Enabling Technologies: Infrastructure for Collaborative
Enterprises, 2003, p. 302–302.
W. E. Hefley e E. A. Loesche, “The eSourcing Capability Model for
Client Organizations (eSCM-CL), Part 2: Practice Details.”, Carnage
Mellon University, Information Technology Services Qualification
Center, 2006.
S. Blumenberg, H.-T. Wagner, e D. Beimborn, “Knowledge transfer
processes in IT outsourcing relationships and their impact on shared
knowledge and outsourcing performance”, International Journal of
Information Management, vol. 29, no 5, p. 342–352, out. 2009.
J.-N. Lee, “The impact of knowledge sharing, organizational capability
and partnership quality on IS outsourcing success”, Information &
Management, vol. 38, no 5, p. 323–335, 2001.
M. Westner e S. Strahringer, “Determinants of success in IS offshoring
projects: Results from an empirical study of German companies”,
Information & Management, vol. 47, no 5–6, p. 291–299, ago. 2010.
Brasil, “Plano Estratégico de Tecnologia da Informação (PETI) e Plano
Diretor de Tecnologia da Informação (PDTI) 2013 - 2015”. 2014.
Brasil, “Norma Operacional SPOA No 006, de 10 de Setembro de
2012. Dispõe sobre a Metodologia de Gerenciamento de Projetos de
Tecnologia da Informação - MGP-TI, utilizada no âmbito do Ministério
das Comunicações.” 2012.
M. Cohn, Succeeding with agile: software development using Scrum.
Upper Saddle River, NJ: Addison-Wesley, 2010.
Y. Mei, Z. Wang, e Z. Cao, “Performance evaluation model of
knowledge transfer”, in Artificial Intelligence, Management Science
and Electronic Commerce (AIMSEC), 2011 2nd International
Conference on, 2011, p. 5677–5681.
FEES
Uma Ferramenta de Apoio à Criação e
Gerenciamento de Laudos Patológicos Veterinários
Édylle Landy Oliveira
Luiz Venicio P. Conceição
Marcos César da Rocha Seruffo
Grupo de Pesquisa de Tomada de
Decisão Multicritério (GPTDM)
Universidade Federal do Pará
Castanhal, Pará
e-mail: [email protected]
Castanhal, Pará
Belém, Pará
Resumo — Este artigo tem como principal propósito apresentar
todas as fases de desenvolvimento de um sistema de laudos
patológicos, indo do nível conceitual ao implementacional, que
executa funcionalidades relativas ao cadastro, armazenamento,
edição, impressão dos laudos, bem como a exportação dos dados
para eventuais correlações. Tal sistema irá padronizar todo o
processo na criação dos formulários e criar uma base de dados
consistente.
Palavras-chave..—..informatização;
padronização; veterinária.
I.
laudos;
desenvolvimento do sistema, metodologia que descreve os
passos seguidos no projeto, resultados obtidos que trata sobre o
produto final que é o software em si e finalizando com as
considerações finais.
II. A FÁBRICA DE SOFTWARE
A Fábrica de Software da Faculdade de Sistemas de
Informação da UFPA/Castanhal é um projeto que busca a
inovação e a interação contínua entre teoria e prática,
subsidiando os alunos na aplicação real dos conceitos
aprendidos em sala de aula, promovendo uma maior integração
e aperfeiçoamento dos componentes curriculares dos cursos
presentes na faculdade, assim como dos docentes e discentes
por meio da realização de atividades de ensino, pesquisa e
extensão. Visa ainda simular o ambiente de uma empresa de
desenvolvimento de softwares, criando uma ferramenta de
gestão para micro e pequenas empresas e preparando mão-deobra especializada e qualificada para o mercado de
desenvolvimento de sistemas.
sistema;
INTRODUÇÃO
No contexto atual, a Tecnologia da Informação
desempenha tarefa crucial para o alcance dos objetivos das
instituições (Alavi & Joachimsthaler, 1992; Bergeron, Bateu &
Raymond, 1991). Contudo, a maneira como algumas
organizações, tanto públicas quanto privadas, organizam seus
dados faz com que haja uma carência no gerenciamento dos
mesmos.
A admissão de candidatos para a Fábrica de Software foi
realizada através de uma seleção com discentes regularmente
matriculados nos cursos de Sistemas de Informação e
Engenharia da Computação da UFPA Campus de Castanhal.
Como requisito obrigatório, o aluno deveria ter conhecimento
em programação, posteriormente participando da seleção que
era constituída de uma prova prática com questões sobre
HTML5, CSS, JavaScript, MySQL e PHP e finalizando com
uma entrevista.
A solução apresentada para o Laboratório de Patologia
Animal da Universidade Federal do Pará tem como objetivo
reduzir a circulação do volume de papel em que assentam os
processos, diminuindo o tempo de análise das informações para
que se possa ter um registro organizado sobre os animais
cadastrados, diagnósticos, etc. e que sirva de apoio à tomada de
decisão com embasamento em toda a informação e histórico
que a base de dados disponibiliza.
Assim, o objetivo deste artigo é apresentar as etapas de
desenvolvimento do Sistema de Laudos Patológicos que vai
desde o nível conceitual até o nível implementacional. O
sistema tem como principal objetivo facilitar o trabalho das
pessoas que fazem necropsias e/ou biopsias em animais no
laboratório de patologia animal que realizam cadastros de todos
os dados de animais, exames e diagnósticos e usar essas
informações posteriormente para fazer correlações.
A estrutura de recursos humanos da Fábrica de Software
possui uma hierarquia onde se tem: um Coordenador, que
possui uma visão mais ampla dos projetos que serão captados,
executados e que serão entregues dentro do prazo estipulado;
os Gerentes de Projeto, que são docentes da Faculdade de
Sistemas de Informação, responsáveis pela supervisão de
projetos de forma pontual, possuindo a tarefa de gerenciar o
cronograma de execução e verificar as atividades da equipe de
desenvolvimento.
Este trabalho foi desenvolvido a partir da Fábrica de
Software da UFPA campus Castanhal. O artigo é composto por
esta primeira seção introdutória, seguido pela contextualização
da problemática onde é abordado os principais motivos para o
Durante o desenvolvimento do sistema, os integrantes da
Fábrica de Software foram orientados a estudar novas
94
FEES
tecnologias Web e/ou aprofundar suas noções nas que já
haviam um certo grau de conhecimento. O acompanhamento
da evolução do desenvolvimento era feito com reuniões
semanais, onde eram discutidos os novos requisitos, andamento
de atividades individuais, etc.
realizaram entrevistas e monitoraram a rotina e funcionamento
do ambiente para poder desenvolver um sistema altamente
personalizado a tarefa proposta.
Logo após os requisitos concluídos e validados junto à
professora responsável pelo pedido do sistema, um aluno
integrante da Fábrica de Software ficou responsável pela
modelagem dos principais diagramas necessários para o
desenvolvimento do projeto e outro aluno se comprometeu em
criar e arquitetar a interface do mesmo.
III. CONTEXTUALIZAÇÃO DA PROBLEMÁTICA
Uma das principais problemáticas no Laboratório de
Patologia Animal era o gerenciamento de laudos e
armazenamento de informações. Como os laudos eram
preenchidos de forma manual, o armazenamento das
informações gerava uma série de problemas tais como:
ocupação de espaços e manuseios de grandes volumes do
mesmo, o que dificultava a recuperação das informações,
duplicação de formulários, falta de informações devido ao não
preenchimento de alguns campos, etc.
A Figura 1 mostra o diagrama de casos uso. A modelagem
de um diagrama de casos de uso é uma técnica usada para
descrever e definir os requisitos funcionais de um sistema. Do
ponto de vista do usuário, as principais funcionalidades do
sistema de laudos patológicos são: Cadastrar formulário:
inserção das informações do animal, dono, plantonista, etc.;
Busca: edição, remoção e impressão de formulários; Exportar
planilha: criação de uma planilha com informações de acordo
com a busca do usuário.
Realizava-se coleta de informações no laboratório através
de dois tipos de laudos: Laudo de Histopatologia e Laudo de
Necropsia. Após o preenchimento de todo o formulário, os
dados eram inseridos de forma manual no software SPSS
(Statistical Package for the Social Sciences) que faz
correlações de dados e gera cálculos estatísticos que dão apoio
às tomadas de decisões. O SPSS é um software do tipo
cientifico que é capaz de fazer aplicação analítica, Data
Mining, Text Mining e estatística que transformam os dados em
informações importantes.
O SPSS consegue contemplar as necessidades de correlação
de dados, contudo o método manual de alimentação do sistema
é muito dispendioso e corre o risco de perda de dados, já que a
tabulação dependia exclusivamente do manuseio de papéis.
IV. METODOLOGIA
Segundo [Ian Sommerville, 2003], um processo de software
é um conjunto de atividades e resultados que geram um
produto de software. No projeto foi utilizado o modelo de
processo Iterativo/Incremental no qual foram feitas três versões
durante quatro meses. A abordagem de desenvolvimento
incremental foi sugerida por Mills [Mills et al., 1980] como
uma solução para diminuir o trabalho no processo de
desenvolvimento, ao mesmo tempo proporcionando ao cliente
a oportunidade de adiar decisões sobre seus requisitos
detalhados até que eles tenham alguma experiência com o
sistema.
Fig. 1. Casos de Uso.
Com os diagramas prontos e as telas definidas, foi dado
início ao processo de programação, o qual foi realizado de
forma colaborativa, onde cada integrante ficava responsável
por uma funcionalidade do sistema. Durante este processo de
programação foram desenvolvidos três releases sendo o
terceiro a versão final do sistema.
A modelagem do projeto foi feita usando UML (Unified
Model Language), diagramas de casos de uso, diagramas de
classe e diagramas de pacotes. Na codificação foram usadas as
seguintes tecnologias: Java Web, (X)HTML (eXtensible
Hypertext Markup Language), CSS (Cascading Style Sheets),
Java Server Faces (JSF), Primefaces e Hibernate fazendo
persistência no banco de dados MySQL que foi escolhido pelo
fato de possuir consistência, ter alta performance,
confiabilidade e ser fácil de usar. Os desenvolvedores
gerenciaram o projeto colaborativamente usando as
ferramentas de repositório de código fonte SVN e Assembla.
Na maioria dos projetos ocorre algum reuso de software.
Isso, em geral, acontece informalmente quando as pessoas que
trabalham naquele projeto conhecem projetos ou códigos
similares àqueles exigidos [Ian Sommerville, 2003]. No
sistema de laudos foram utilizados alguns módulos de um
sistema desenvolvido pela turma de 2011 de Sistemas de
Informação da UFPA-Castanhal como avaliação da disciplina
de Análise e Projeto de Sistemas o qual foi desenvolvido para a
prefeitura do município de Castanhal objetivando a gestão de
carteirinhas de passagens municipais.
Os testes não foram realizados de forma automatizada
ficando a cargo de parceiros da Fábrica de Software e dos
usuários finais do sistema a tarefa de testar suas
Os alunos integrantes da Fábrica de Software fizeram o
levantamento dos requisitos junto aos professores e bolsistas
que utilizam o Laboratório de Patologia Animal. Para tanto,
eles passaram dois dias no local onde o sistema seria utilizado,
95
FEES
funcionalidades. Os erros encontrados eram documentados
pelos desenvolvedores e corrigidos o quanto antes.
padronizar todo o processo de criação de laudos. A integração
do sistema ao ambiente SPSS permite utilizar os dados
coletados para ajudar nas tomadas de decisões.
A implementação do sistema foi realizada em um
computador que somente os professores e alunos bolsistas do
Laboratório de Laudos Patológicos tinham acesso e este serviu
como servidor de armazenamento do sistema. Foi instalado
nesta máquina, também, o software MySQL Backup Manager
para realizar o backup dos dados em uma conta de
armazenamento em nuvem que apenas os integrantes da
Fábrica de Software possuem acesso.
Com conceitos aprendidos em sala de aula vindo de
disciplinas como Engenharia de Software, Programação,
Análise e Projeto de Sistemas, entre outras, os alunos puderam
colocar em prática toda essa teoria durante o desenvolvimento.
Na parte de coleta e detalhamento de requisitos houve evolução
devido ao contato real com o cliente, assim utilizando as
técnicas aprendidas como entrevista e observação. Como todo
processo de desenvolvimento exige obedecer um cronograma,
os alunos vivenciaram uma experiência de como é desenvolver
um projeto seguindo um prazo previamente definido.
V. RESULTADOS OBTIDOS
Como resultado foi alcançado um aplicativo para criação e
gerenciamento de laudos patológicos animais. Como tela
principal foi obtida a Figura 2 que apresenta a página inicial do
sistema logo após o login ser aceito.
A participação dos integrantes da Fábrica de Software na
realização deste projeto trouxe uma expertise altamente
satisfatória na modulação de gerência de processos e
habilidades nas ferramentas utilizadas. Por conta disso, a
equipe da Fábrica de Software foi capaz de fornecer um curso
de HTML5 e PHP para a comunidade acadêmica de
Castanhal/PA que contou com a participação de vários alunos
de diferentes instituições.
Na figura 2-A, o usuário pode escolher entre dois tipos de
formulários: histopatologia ou necropsia. No final do cadastro
é gerado, automaticamente, um código no qual é inserido a
primeira letra do tipo de laudo, “H” ou “N”, seguido de um
número que é auto iterativo e por último os dois últimos dígitos
do atual ano; Ex: N1/14; Na figura 2-B é onde o usuário irá
fazer o gerenciamento dos formulários optando por: visualizar,
editar, imprimir ou excluir. A busca é feita de acordo com o
que o usuário desejar, por tipo de formulário, código, nome do
proprietário, nome do animal, espécie, raça, data de cadastro ou
diagnóstico; Na figura 2-C é onde o usuário irá exportar
planilhas com dados para ser importados no software SPSS; Na
figura 2-D ficam as opções de logoff no sistema e alterações de
senhas de aluno e/ou professor.
Atualmente a ferramenta está sendo utilizada no
Laboratório de Patologia Animal do Campus II da
Universidade Federal do Pará – Castanhal. Futuramente
pretende-se evoluir a ferramenta para uma nova versão com
melhor usabilidade, além disso espera-se hospedar a aplicação
nos servidores da UFPA para que possa ser acessada de forma
online.
REFERÊNCIAS
[1]
[2]
[3]
[4]
[5]
[6]
Fig. 2. Tela do Sistema.
VI. CONSIDERAÇÃOES FINAIS
Este artigo apresentou a ferramenta Sistema de Laudos
Patológicos que veio para fazer a informatização do sistema de
informação já existente no Laboratório de Patologia Animal e
que é voltada para apoiar a gerência de informações e
[7]
96
Alavi, M., & Joachimsthaler, E. A. (1992, March). Revisiting DSS
implementation research: a meta analysis of the literature and
suggestions for researchers. MIS Quarterly, 16(1), 95-116.
Bergeron, F., Bateau, C., & Raymond, L. (1991, March). Identification
of strategic information systems opportunities: applying and comparing
two methodologies. MIS Quarterly, 15(1), 89-99
SOMMERVILLE, Ian. Engenharia de software. São Paulo. 6. ed.
Pearson Education Companion, 2003.
Pressman, Roger. S. (2005) Software Engineering: A practitioner’s
approach, McGraw Hill, 6th edition.
Mills DR, Kramer FR, Dobkin C, Nishihara T, Cole PE (1980)
Modification of cytidines in a Q beta replicase template: analysis of
conformation and localization of lethal nucleotide substitutions.
Biochemistry 19: 228-236. PMI: 6986163
SALES, Murilo F., SALES, Ernani O., LIMA REIS, Carla A., REIS, R.
Q. Uma Ferramenta de Gerência de Requisitos Integrada a um Ambiente
de Desenvolvimento de Software Centrado em Processos. In: Congresso
Brasileiro de Software - Sessão de Ferramentas, 2010, Salvador - BA.
Congresso Brasileiro de Software: Teoria e Prática, 2010.
DMSS Software. IBM SPSS Statistics. Disponível em:
<http://www.dmss.com.br/teste/dmss/software/statistics/index.html>
Acesso
em:
19
maio
2014.
FEES
Um Estudo de Caso sobre a Adoção de Métodos
Ágeis na Gestão de Contratos de Fornecedores de
Desenvolvimento de Software em uma Organização
Pública Brasileira
Aline Gonçalves1 , Hilmer Neri1
1
Faculdade UnB Gama - Universidade de Brasília (UnB), Brasil
[email protected], [email protected]
desenvolvimento de software influenciaram no resultado final
do contrato do ponto de vista do gestor de contrato e do fiscal
técnico do contrato, que juntos gerenciam o contrato?
Resumo—Atualmente, algumas organizações da Administração Pública Federal iniciam investimentos para adotar contratações de serviços de desenvolvimento de software utilizando métodos ágeis, motivado pelo entendimento de que os instrumentos
contratuais, hoje em vigor, apresentam limitações que causam
impacto nos custos dos projetos e na entrega do produto. O
objetivo desse trabalho foi analisar a influência da adoção de
métodos ágeis na gestão de contratos públicos de desenvolvimento
de software. Para isso, foi realizada uma investigação empírica,
descritiva, por meio da execução de um estudo de caso exploratório. Analisamos os efeitos sobre a entrega de ordens de serviço, a
qualidade interna do produto e a satisfação do cliente da solução
desenvolvida na organização. Após a análise dos dados coletados
concluímos que neste caso foi possível a aplicação de métodos
ágeis na gestão de contratos públicos de desenvolvimento de
software, e que isso pode melhorar a atividade da gestão do
desenvolvimento, em que pese, haja restrições face ao normativo
vigente.
II. M ETODOLOGIA DE P ESQUISA
Na metodologia de pesquisa adotada neste trabalho, foram
definidos: a natureza da pesquisa; o tipo de metodologia de
pesquisa; o tipo de abordagem de pesquisa; os métodos de
procedimentos de pesquisa e os tipos de técnicas de coletas
de dados.
O procedimento de pesquisa escolhido foi o estudo de
caso. As técnicas de coleta de dados selecionadas foram
documentos, questionários e entrevistas informais.
III. P ROJETO DO E STUDO DE C ASO
Como unidade de estudo de caso, foi selecionado o contrato
IPHAN No 28/2011 do Sistema Integrado de Conhecimento e
Gestão (SICG) do Instituto do Patrimônio Histórico e Artístico
Nacional-IPHAN. Trata-se de estudo exploratório, onde foram
coletados dados qualitativos e qualitativos, que caracterizaram
a organização contratante, a empresa contratada, o objeto do
contrato e a solução de gestão de contrato definida. O foco
foi a análise dos efeitos sobre a entrega de ordens de serviço
e sobre a satisfação do cliente com o produto do referido
contrato.
A confiabilidade diz respeito a mostrar que se o estudo
for repetido utilizando as mesmas fontes de dados, poderá
obter-se os mesmos resultados. Para isso, a definição do
protocolo do estudo de caso e o desenvolvimento de um banco
de dados do estudo foram táticas utilizadas para garantir a
confiabilidade desse estudo de caso, pode ser obtida em:
Index Terms—Gerenciamento, contratações, software, organizações públicas, lean, métodos ágeis, desenvolvimento, produção,
estudo de caso, engenharia de software.
I. I NTRODUÇÃO
Algumas organizações públicas têm compactuado entendimento de que os instrumentos contratuais, hoje em vigor,
não priorizam a entrega de software, tampouco sua qualidade
interna e valor de negócio. Isso contribui para que projetos
terminem sem sucesso, o que onera os cofres públicos [1].
A partir dessa motivação algumas entidades da Administração
Pública, começam adotar métodos ágeis em suas equipes de
desenvolvimento, com destaque para o Scrum e o Extreme
Programming-XP [2]
Com objetivo de trabalhar a problemática atual de adoção de
métodos ágeis na gestão de contratos públicos, em um trabalho
de conclusão de curso, foi realizado um estudo de caso em uma
organização pública brasileira, a qual utiliza métodos ágeis e
o pensamento lean na sua solução de gestão de contrato de
fornecedores de desenvolvimento de software, se propondo a
responder a seguinte questão de pesquisa:
Questão de Pesquisa: Como o uso de métodos ágeis e do
pensamento lean na gestão de contratos de fornecedores de
https://github.com/alinegs/TCC1_Aline_Goncalves.git
IV. R ESULTADOS DO E STUDO DE C ASO
Os resultados dos dados coletados foram categorizados em
dois efeitos: entrega de ordens de serviço e satisfação do
cliente.
97
FEES
conclusões. Nesta pesquisa houve triangulação de dados e de
metodologia. A triangulação de dados se deu pelo uso de base
de documentos e código organizacionais, questionários e entrevistas para coletar dados. A triangulação de métodos ocorreu
pelo uso de métodos de coleta quantitativos e qualitativos.
A validade externa diz respeito a estabelecer o quanto
as descobertas podem ser generalizadas. Pode-se testar a
coerência entre os resultados do estudo e resultados de outras
investigações similares. Para isso, [3] recomenda a replicaçao
do estudo em múltiplos casos. Como o escopo deste trabalho
é o estudo de um único caso, a validade externa não pode ser
atingida.
A. Efeitos sobre a entrega de ordens de serviço
A partir dos dados coletados da documentação dos Processos do projeto SICG foram calculadas as métricas para
responder as questões específicas do protocolo do estudo de
caso, que caracterizam os efeitos sobre a entrega de ordens
de serviço do uso de métodos ágeis na gestão do contrato de
fornecedores de desenvolvimento de software.
A média geral de requisitos atendidos ao longo do projeto
de acordo com os dados levantados da documentação foi de
78%, o que coincide com a percepção dos envolvidos no
projeto: 75% dos envolvidos responderam ao questionário que
a percepção geral de requisitos atendidos durante o projeto
estava entre 70% e 90%.
Ainda pelos dados coletados neste estudo, não foi evidenciada a utilização de uma técnica de gerenciamento de
custos de projeto, como exemplo, a análise do valor agregado.
Uma solução a ser investigada seria o uso de uma ferramenta
que automatizasse o processo de monitoramento de custos.
Assim, métricas relacionadas a custo poderiam ser acessadas
tempestivamente de forma auxiliar o gestor na tomada de
decisão. O gestor do contrato poderia analisar, por exemplo,
se o que está sendo pago está de acordo com o que está sendo
produzido ou de acordo com o que foi planejado.
V. C ONCLUSÃO
Neste trabalho foi constatado que é possível aplicar uma
solução baseada em métodos ágeis e no pensamento lean sobre
a gestão de um contrato de desenvolvimento de software.
É importante ressaltar que a solução de gestão de contratos
definida pelo IPHAN não fere o que é determinado na Lei
na lei geral de contratações No. 8.666/93 ou na norma específica, a Instrução Normativa No. 04/2010/MP ou mesmo
nos Princípios da Administração Pública Federal. Ao mesmo
tempo, a solução foi baseada nos valores, princípios e práticas
do pensamento lean e de metodologias ágeis.
A abordagem de ensino-aprendizado utilizada neste trabalho
levou em consideração a participação ativa da aluna/orientador
na investigação do objeto do estudo, onde foi possível se
posicionar diante do concreto, um contrato real em execução,
e das experiências pessoais de ambos. Esse tipo de abordagem,
construtivista, se caracteriza pela interação pessoa-meio sobre
a realidade percebida [4]. Nesse contexto o desenvolvimento
não consiste em produzir cópias internalizadas da realidade
externa, mas sim, em produzir estruturas lógicas que permitam
ao indivíduo atuar sobre o mundo de formas cada vez mais
flexíveis e complexas [5] .
Assim, este trabalho foi essencial para aproximar a academia e uma organização da Administração Pública Federal
na análise dos efeitos advindos do uso de métodos ágeis
na gestão de contratos de fornecedores de desenvolvimento
de software. A interação entre essas entidades contribuiu
para validar soluções e sugerir melhorias visando melhores
resultados na gestão do erário e no atendimento às requisições
inerentes ao desenvolvimento de software.
B. Efeitos sobre a satisfação do cliente
O cliente do projeto SICG é representado pelo papel de
Product Owner, que também atuou como gestor do contrato,
e por todos os envolvidos no projeto por parte do IPHAN.
Este nunca havia participado anteriormente de um projeto onde
a gestão do contrato era realizada com o uso de métodos
ágeis, portanto, a experiência dos envolvidos no projeto com
esses métodos era pouca. Para coletar a opinião do cliente foi
aplicado o questionário.
Como resultado tivemos que cerca de 80% dos envolvidos
no projeto consideraram a visibilidade do processo como
"Alta", dentre eles o gestor do contrato. Além disso, o resultado de satisfação do IPHAN com relação ao produto entregue,
de forma unânime foi considerado como "Satisfeito".
C. Análise de Validade
As principais ameaças aplicáveis aos estudos de caso são:
validade do constructo, validade interna, validade externa e
confiabilidade [3].
A validade de constructo diz respeito ao uso de múltiplas
fontes de evidência e seleção de informantes chave. Neste
trabalho foram utilizadas múltiplas fontes de evidências e os
informantes que responderam ao questionário e às entrevistas
foram os principais envolvidos no projeto, tanto da autarquia
contratante quanto da empresa contratada. Além disso, a
utilização da técnica GQM (Goal-Question-Metric) direcionou
a definição de métricas, procurando-se então a reforçar a
validade do constructo.
A validade interna pode ser atingida por meio de diversas
estratégias, dentre elas a triangulação, uma técnica para confirmar se os resultados de diversas fontes e de diversos métodos
convergem, sendo possível aumentar a aumentar a força das
R EFERÊNCIAS
[1] Acórdão no 2314, Tribunal de Contas da União, Brasília, Brasil, 2013.
[2] C. Melo, V. A. Santos, H. Corbucci, E. Katayama, A. Goldman, and
F. Kon, Métodos ágeis no Brasil: estado da prática em times e organizações, 2012.
[3] R. K. Yin, Estudo de Caso - Planejamento e Métodos, 2010.
[4] M. Bigge, Teorías de aprendizagem para professores. Editora
pedagógica e universitaria, 1977. [Online]. Available: http://books.
google.com.br/books?id=A4ppAAAACAAJ
[5] C. Rappaport, W. Fiori, and C. Davis, Psicologia do desenvolvimento:
Teorias do desenvolvimento conceitos fundamentais. E.P.U., 1981,
no. v. 1. [Online]. Available: http://books.google.com.br/books?id=
CSMiQwAACAAJ
98
FEES
Um estudos sobre métricas de produto e
vulnerabilidades para tomada de decisões
Arthur Del Esposte1 , Carlos Bezerra1 , Paulo Meirelles1 , Hilmer Neri1
1
Laboratório Avançado de Produção Pesquisa e Inovação em Software - LAPPIS
Faculdade UnB Gama, Universidade de Brasília, Brasil
{arthurmde,carlosfilipe.lb}@gmail.com, {paulormm,hilmer}@unb.br
código-fonte possuem natureza objetiva que buscam mensurar
tamanho, complexidade e outros atributos importantes do
software [2][3]. Neste sentido, o estudo de métricas e sua
utilização no contexto de segurança e qualidade interna do
código-fonte podem ser fundamentais para a formação do
Engenheiro de Software.
Neste artigo, iremos mostrar os estudos e avanços intermediários de um trabalho de conclusão de curso de Engenharia
de Software da Faculdade UnB Gama, cujo foco é explorar
e potencializar a utilização de métricas para o monitoramento
de código-fonte a partir da compreensão e estabelecimento de
possíveis relações existentes entre métricas de vulnerabilidade
e qualidade de software. Assim, esse trabalho contempla a
composição de métricas em cenários de decisões e o desenvolvimento e evolução de duas ferramentas que possam
apoiar a utilização de métricas e cenários na melhoria contínua
do desenvolvimento. A primeira ferramenta consiste em uma
plataforma livre de monitoramento de código fonte chamada
Mezuro, enquanto a segunda consiste em um ambiente de Data
Warehousing que também já foi explorado em outros trabalhos
[4].
Na sequência deste artigo, abordamos brevemente a metodologia para o desenvolvimento deste trabalho, na Seção II. Já
na Seção III apresentamos os estudos realizados e resultados
alcançados. Por fim, na Seção IV fazemos as considerações
finais deste trabalho.
Resumo—Neste texto apresentamos os resultados intermediários de um Trabalho de Conclusão de Curso de Engenharia de
Software da UnB. Assim, é explorada a importância da utilização
de métricas estáticas de código-fonte para suportar a tomada
de decisões, tanto a nível técnico quanto gerencial a respeito do
design e segurança do software. Além disso, é proposta uma nova
técnica para realizar medições que será viabilizada a partir da
evolução de duas ferramentas de monitoramento de código-fonte.
Index Terms—Métricas; Design; Segurança; Monitoramento;
Cenários de Decisões; Código-fonte;
I. I NTRODUÇÃO
A qualidade interna é um dos fatores de sucesso de projetos de software, pois corresponde à aspectos como manutenibilidade e segurança. Sistemas de software com boa
qualidade interna proporcionam maior produtividade uma vez
que possibilitam a criação de mais testes automatizados, são
mais compreensíveis, reduzem o risco de bugs e facilitam
as modificações e evoluções no código. Além disso, um
estudo do ICAT/NIST 1 de 2005 já apontava que 80% das
vulnerabilidades exploráveis estão ligadas a má codificação.
Nesse sentido, a medição pode ser utilizada como um
processo de apoio ao acompanhamento da segurança e qualidade, através do estabelecimento de metas e indicadores que
indiquem oportunidades de melhorias observáveis do produto.
Em um cenário otimista, os próprios Engenheiros de Software
podem adotar como prática a medição do código-fonte para
auxiliar as tomadas de decisões, ou até mesmo para avaliação
do código inserido ou da aplicação de refatorações. Entretanto, uma grande quantidade de métricas, coletas manuais e
poucos recursos de visualização são fatores que acabam por
desmotivar o uso dessas para o monitoramento do código.
Além disso, assim como destacado por [1], a compreensão
do significado de valores obtidos através de métricas não é
uma tarefa trivial, demandando um grande esforço de coleta
e interpretação, cujas análises podem ser errôneas caso feitas
sobre métricas isoladas, correlações inexistes ou até mesmo a
escolha de métricas inadequadas.
Nesse contexto, métricas de código-fonte podem ser utilizadas tanto no âmbito gerencial quanto como referência técnica
para tomada de decisões sobre o código-fonte. Métricas de
II. M ETODOLOGIA
Este trabalho tem sido realizado por dois graduandos de
Engenharia de Software cuja primeira etapa foi desenvolvida
ao longo do 1o semestre de 2014 e a finalização deve-se dar
no fim do 2o semestre do mesmo ano.
Dentro da primeira etapa, realizamos uma extensa revisão
bibliográfica com mais de 50 fontes de estudos relacionados
ao design e segurança de software cujo principal objetivo
era compreender os principais aspectos, problemas, princípios, técnicas e práticas as quais o Engenheiro de Software
está exposto. Da mesma forma, exploramos os principais
conceitos relacionados a métricas estáticas de código-fonte,
onde também listamos um conjunto de métricas de design
de software e um conjunto de métricas de vulnerabilidades.
As métricas que foram explanadas foram selecionadas devido
sua popularidade tanto em trabalhos científicos quanto em
ferramentas de análise estática de código-fonte.
1 ICAT foi um motor de busca de vulnerabilidades, desenvolvido pelo
NIST(National Institue of Standards and Technology). O ICAT foi substituido
pelo NVD (National Vulnerability Database) - http://nvd.nist.gov/
99
FEES
A definição de estrutra dos Cenários de Decisões, explicados
na próxima sessão, foi advinda do estudo realizado por Almeida e Miranda [5] sobre mapeamento de métricas de códigofonte com os conceitos de Código Limpo. A partir dos estudos
realizados sobre métricas, design e segurança, foram propostos
alguns cenários para tomada de decisões sobre projetos de
software, principalmente sobre segurança e vulnerabilidade.
métricas específicas de segurança podem compor por si só um
cenários de decisão, pois estas já indicam pontualmente uma
situação de vulnerabilidade.
Cenário
Ponto Crítico de
Falha
III. E STUDOS E R ESULTADOS
Com os estudos verificamos uma forte relação entre princípios de design de software com os princípios de design seguro,
onde a aplicação de ambos podem prover softwares mais
robustos, extensíveis e seguros. Os cuidados com o bom design
do código-fonte são fundamentais para o desenvolvimento de
códigos seguros, podendo ser realizados através, por exemplo,
da prática de refactorings e aplicação de padrões de projeto.
Neste sentido, o monitoramento do código fonte pode ser
utilizado para apoiar a utillização de técnicas que buscam
aplicar os princípios citados e este monitoramento pode ser
feito com o auxílio de métricas de código fonte.
Com o objetivo de minimizar as principais dificuldades
existentes na medição de código fonte, como a escolha de
métricas, interpretação de valores, redundância de métricas
e interpretaçoes isoladas, buscamos definir o conceito de
Cenários de Decisão. Os Cenários de Decisão visam nomear
e mapear estados observáveis através de métricas de códigofonte que indicam a existência de determinada característica
dentro do software, classe ou método, potencializando o uso
de métricas para tomada de decisões em projetos. A estrutura
dos cenários consistem em:
• Nome: Identificação única do cenário
• Métricas Envolvidas: Métricas necessárias para a caracterização do cenário
• Nível: Abstração envolvida (projeto, classe, método)
• Descrição: Discuti os problemas, princípios envolvidos e
a caracterização
• Caracterização com Métricas: Define e discuti como as
métricas envolvidas devem ser utilizadas para identificar
o cenário
• Ações Sugeridas: Propõe um conjunto de ações específicas tais como uma refatoração, a utilização de um padrão
de projeto, prática e aplicação de princípios
Neste sentido, projetos podem utilizar cenários de referência
ou até mesmo definir novos cenários de acordo com parâmetros de qualidade do projeto. Dentro da primeira etapa de desenvolvimento desse trabalho, baseado nos estudos e relações
existentes sobre design e vulnerabilidades de software, definimos um conjunto de cenários que visam identificar características de software relacionado à violações de princípios de segurança e presença de vulnerabilidades. Nos cenários propostos,
observamos que alguns cenários podem conter apenas métricas
de design e mesmo assim determinar uma vulnerabilidade,
como o cenário "Ponto Crítico de Falha"mostrado na tabela I.
Por outro lado, outros cenários podem ser compostos apenas
com métricas de segurança, como o caso do cenário "Variáveis
não inicializadas". Neste ultimo caso, notamos que algumas
Variáveis não inicializadas
Caracterização
do cenário
Identificar classes muito
acopladas, que representam pontos críticos da
aplicação
Variáveis não inicializadas podem causar falha da
aplicação ou acesso não
autorizado de informações
caso sejam utilizadas
Tabela I
Caracterização
com Métricas
Alto valor de
ACC+NOC
Ao menos uma
ocorrência
da
métrica UAV
E XEMPLOS DE CENÁRIOS PROPOSTOS
Por fim, na primeira etapa dessa monografia, contribuímos
tecnicamente com dois projetos de software livre que fazem
parte do contexto deste trabalho: o Mezuro2 e Analizo3 , que é
um dos extratores utilizados pelo Mezuro. Os objetivos dessas
contribuições foi compreender a arquitetura desses projetos
para proporcionar evoluções que contemplem a utilização de
cenários e a coleta e apresentação de novas métricas de
vulnerabilidades.
IV. C ONSIDERAÇÕES F INAIS
A partir dos estudos realizados durante a primeira etapa
do trabalho de conclusão de curso observou-se que existem
relações explícitas entre o design de software e sua segurança.
Dessa forma, iniciamos o mapeamento de características observáveis do software em métricas a partir da estrutura criada
Cenários de Decisões, que por sua vez, se apresentam como
uma técnica alternativa para suportar a medição em projetos
de software.
A segunda etapa deste trabalho será destinada a evolução
da plataforma de monitoramento Mezuro para viabilizar o
conceito de cenários de decisões assim como construir uma
proposta de ambiente DWing para monitoramento do código.
Além disso, pretendemos realizar um estudo estatístico para
aferir a correlação existente entre métricas de design e de vulnerabilidades a partir da avaliação automatizada de softwares
livres em C/C++, com objetivo de apoiar cientificamente a
criação de cenários de referência.
R EFERÊNCIAS
[1] S. R. Chidamber and C. F. Keremer, “A metrics suite for object oriented
design,” in IEEE Transactions on Software Engineering, vol. 20, 1994,
pp. 476–493.
[2] S. Henry and D. Kafura, “The evaluation of software systems’ structure
using quantitative software metrics,” in Software Practice and Experience,
1984, pp. 561–573.
[3] T. Sÿsta, “Static and dynamic reverse engineering techniques for java
software systems,” Ph.D. dissertation, University of Tampere, Department
of Computer and Information Science. Finland, Maio 2000.
[4] G. M. Mazuco, “Uma abordagem de data warehouse para gestão de
métricas de software com análise e valor agregado,” Porto Alegre, 2011.
[5] L. T. Almeida and J. M. Miranda, “Código limpo e seu mapeamento para
métricas de código fonte,” 2010.
100
2 http://mezuro.org/
3 http://analizo.org/
FEES
A Platform Fed by Software Industry Problems to
Learn Software Development
Luiz Ferreira
Eduardo Figueiredo
Departamento de Ciências da Computação
Universidade Federal de Minas Gerais
Belo Horizonte, Minas Gerais, Brasil
Departamento de Ciências da Computação
Universidade Federal de Minas Gerais
Belo Horizonte, Minas Gerais, Brasil
Abstract—Nowadays, simply knowing the theoretical aspects
of software engineering is not sufficient to remain competitive.
People must also learn to apply their knowledge in new domains
and practical situations to solve complex software development
problems. Professionals holding different jobs in software industry must be creative and flexible problem solvers. This requires
the ability to apply experience and practical knowledge to address
novel problems. Consequently, learning to think critically, to
analyze the problem description, and to synthesize information to
solve software development problems in groups are crucial skills
for successful participation in our modern and highly competitive
software market. This work then proposes the development of a
Web-based platform, named CodeChallenge, to teach people how
to solve complex problems in software development by programming solutions for actual problems. The learning experience is
going to be enhanced by students exchanging experience with
peers in an environment that mimics a social network. From the
business model point of view, it is possible to charge in a long
term our industry partners based on their problems solved by
our students.
I.
courses that teach theoretical aspects of software engineering
[2][3]. There are also initiatives to teach software development
based on games and simulators [4]. However, unlike these
approaches, we aim both to teach people how to program and
to generate value from this produced code. The main idea is
to create exercises based in actual problems from our industry
partners. That is, specific problems that are part of the requirements of actual software systems are posted in a repository.
Then, students are challenged to solve those specific problems
and, as a result, deliver useful code to that system owner. In
fact, several students are expected to solve the same problem.
Therefore, we plan to add a ranking of best solutions based
on users’ recommendations in a social network environment.
A similar ranking mechanism also applies to students based
on their number of correct solutions to open problems. In
summary, our general goal of the master dissertation is to teach
software development based on actual industry problems to a
large amount of people without costs for students.
II.
I NTRODUCTION
In a society where many people cannot afford paying for
education, it is important to create ways to facilitate access
to education. With respect to Software Engineering, a field of
study that always needs creative and flexible problem solvers,
it is of upmost importance to create alternatives to teach not
only theoretical aspects of software development, but also how
to solve complex software development problems. In addition,
creating a learning environment that favors critical thinking
and helps people to boost their careers is not only relevant but
also important and necessary.
The idea of learning from real-world problems is not new.
For instance, there is web approaches to teach people new
languages by making them translate documents and books [1].
The basic idea is simple in this case. Somebody who needs
a document translation uploads it to a Web repository. That
document then gets presented to students in a Web interface,
and students can translate it in order to practice the language
they are learning. When the document is fully translated, it
is returned to the original content owner who, depending on
the type of document they uploaded, pays for the translation.
Similar approach has been applied to other areas. However, as
far as we are concerned, there is anything like that to teach
software engineering.
There exists today a large amount of high quality online
101
C ODE C HALLENGE
In this work, we expect to create a platform of courses
related to software engineering called CodeChallenge. This
platform is composed of several courses aiming to teach
software development in different programming languages,
such as C#, Java, Ruby, JavaScript, and Python and different
subjects of software engineering . The exercises of all courses
are going to be designed as an implementation of real life
problems, like Minimum Viable Product (MVP) or prototypes
for startups and software products for small business. From
the business model side, we foresee solving real life complex
problems by breaking them into smaller problems which are
solved by students. After all sub-problems have been solved,
CodeChallenge aggregates one to another creating the solution
for the original problem. Software Engineering courses will be
available for free and, as a result, we believe that we are able
to achieve a widely audience.
Figure 1 presents an overview of CodeChallenge. This
figure shows that the proposed learning platform includes
two types of users: (industry) partners and students. Our
partners submit a real life problem of software development
to CodeChallenge. Each open problem is then displayed for
our students as an exercise that they can solve, based in
what problems they already solved. CodeChallenge will enable
students to solve problems by developing source code in its
Web front end or offline in the desirable IDE. In the latter
FEES
Fig. 1.
CodeChallenge Architecture
case, students have to upload the source code with the problem
solution. The verification of the quality of solutions is going
to be performed in three steps. First, the learning platform is
going to execute automated tests and those who pass in all tests
are marked as likely correct. The platform will allow users
to create more tests to guarantee that the solution proposed
will solve the partner problem. After that, each likely correct
solutions are going to be syntactically analyzed (e.g., to check
code style and patterns) and quantitatively evaluated by source
code metrics [5]. This automated analysis may approve or not
the solution and will help the users to rank the better solution.
Finally, users of the platform, i.e. students and partners, are
able to qualitatively evaluate the quality of the approved
solutions.
After a solution is solved by an user, CodeChallenge will
allow and encourage users to do code reviews and improve
code of others users. This will give us two benefits. First, will
increase students skills helping them to understand how they
can make better codes. Second, it will improve the overall
solution that each partner will receive, improving code quality
and maintenance.
exercises and verifies its correctness automatically. In a second
step, CodeChallenge will be evaluated by analyzing whether
it is capable of solving actual problems from industry partners
and delivered value for them. Detailed evaluations strategies
are expected to be designed during the work execution.
III.
C ONCLUSION AND E XPECTED R ESULTS
This project aims to help students older than 15 years
old, who cannot pay a large amount for learning how to
program or for improving their software development skills.
CodeChallenge focuses on people either who are not ready
yet to start their careers or have interests in learning new
technologies. We believe that this project can impact the IT
industry worldwide, by providing skilled manpower to an ever
growing software market and by helping poor people to grow
and enhance their programming skills.
We expect that at the end of the work, in December
of 2015, Luiz Ferreira will be able to defend his master
dissertation under the supervision of Eduardo Figueiredo.
IV.
ACKNOWLEDGEMENTS
This can introduce a new business model to massive open
online courses [6] by developing a model based on creating
small products to early stage companies. This approach will
allow entrepreneurs to test their hypothesis faster at low cost.
This work was partially supported by CNPq (grant Universal 485907/2013-5) and FAPEMIG (grants APQ-02532-12
and PPM-00382-14).
The work has two milestone. First, it is expected to develop
a teaching platform to allow worldwide students to practice
their program skills in real world problems. This first milestone
is planned for 2014. Second, both the learning and programming platforms are going to be integrated and evaluated
based on empirical research methods, such as surveys and
experiments [7].
R EFERENCES
This work can be divided in 3 phases. 1st Term: Development of a prototype module that allow students to do
software engineering exercises and verifying automatically if
the exercise is correct in the cloud. 2nd Term: Development of
a module of the course to teach software engineering based on
real life problems provided by our industry partners. 3rd Term:
Design empirical studies to evaluate the proposed platform.
The first prototype version of CodeChallenge is going to
be evaluated both in a controlled experiment with students in
our university and by applying a survey with worldwide users
[7]. We aim first to analyze if the platform is able to create
an environment where students can write source code to solve
102
[1]
[2]
[3]
[4]
[5]
[6]
[7]
L. von Ahn, “Duolingo: learn a language for free while helping to
translate the web,” in Proceedings of the 2013 international conference
on Intelligent user interfaces. ACM, 2013, pp. 1–2.
E. Figueiredo, J. Pereira, L. Garcia, and L. Lourdes, “On the evaluation
of an open software engineering course,” 44th Annual Frontiers in
Education (FIE) Conference.
D. C. Schmidt and Z. McCormick, “Creating and teaching a mooc
on pattern-oriented software architecture for concurrent and networked
software,” in Proceedings of the WaveFront Forum at the SPLASH 2013
conference, 2013.
N. Tillmann, J. De Halleux, T. Xie, S. Gulwani, and J. Bishop, “Teaching
and learning programming and software engineering via interactive
gaming,” in Software Engineering (ICSE), 2013 35th International Conference on. IEEE, 2013, pp. 1117–1126.
S. R. Chidamber and C. F. Kemerer, “A metrics suite for object oriented
design,” Software Engineering, IEEE Transactions on, vol. 20, no. 6, pp.
476–493, 1994.
C. Dellarocas and M. Van Alstyne, “Money models for moocs,” Communications of the ACM, vol. 56, no. 8, pp. 25–28, 2013.
C. Wohlin, P. Runeson, M. Höst, M. C. Ohlsson, B. Regnell, and
A. Wesslén, Experimentation in software engineering. Springer, 2012.
FEES
Um estudo sobre bibliotecas digitais no contexto da
participação social
Luiz Matos1 , Fernando Cruz1 , Paulo Meirelles1
1
[email protected], {fwcruz, paulormm}@unb.br
Resumo—Este artigo relata os resultados intermediários da
primeira etapa de um trabalho graduação de Engenharia de
Software na Universidade de Brasília, que propõe a construção de
uma biblioteca digital distribuída, tomando o portal Participa.br,
que utiliza o software livre Noosfero, como um provedor de
serviços e os mecanismos formais de participação social como
provedores de dados, cuja a comunicação ocorre por meio de
um protocolo de interoperabilidade.
Index Terms—Bibliotecas digitais, Participação social, Software livre, Interoperabilidade, Biblioteca digital semântica.
I. I NTRODUÇÃO
A participação popular pode ser compreendida como um
processo no qual homens e mulheres se descobrem como
sujeitos políticos, exercendo seus direitos políticos [1]. Uma
das formas de participação previstas na Constituição de 1988
e instituída no Decreto 8243/2014 é através dos mecanismos
formais de participação (conselhos, conferências, ouvidorias,
entre outros), que tem como objetivo, permitir o acesso do
cidadão ao processo decisório.
Um dos problemas enfrentados é a inexistência de um local
para busca de informações sobre os mecanismos, eles possuem
seu próprio repositório de informações, em diversos formatos
digitais. Embora exista uma quantidade enorme de informações sobre participação social, a maioria delas possuem
informações heterogêneas e desatualizadas, principalmente as
disponibilizadas em catálogos impressos e em sites.
Por isso, propõe-se criar um local para disponibilizar as
informações sobre os mecanismos. No entanto, do ponto
de vista da Engenharia de Software foi necessário juntar
conhecimento com outras áreas, a fim pensar em uma solução
que seja duradoura e atualizada.
Este artigo apresenta o andamento de um trabalho de
conclusão de curso (graduação) de Engenharia de Software na
Universidade de Brasília (UnB), que tem o objetivo conceber
um ambiente para consulta colaborativa dos mecanismos ,
onde cada instância será responsável pela manutenção de suas
informações.
O restante deste artigo está organizado da seguinte maneira:
a seção II descreve como foi nossa metodologia de trabalho;
a seção III apresenta os estudos e resultados obtidos até o
momento; e a seção IV conclui este artigo.
II. M ETODOLOGIA
Este trabalho iniciou-se com o problema sobre a catalogação
e sistematização dos canais formais de participação. Primeiramente foi realizado um estudo inicial sobre o tema na literatura
concernente (IPEA1 ) e nos conteúdos disponibilizados nos
sites dos mecanismos.
Além disso, realizou-se entrevistas e reuniões com os principais gestores dos conselhos e conferências. Essas entrevistas auxiliaram no entendimento sobre o funcionamento dos
mecanismos formais, como também, ajudaram a definir as
principais necessidades de informação (requisitos), necessários
na etapa de catalogação dos mecanismos formais dentro da
biblioteca digital.
Após o levantamento, foi visto que a catalogação manual
desses mecanismos formais é inviável, tendo em vista que:
(i) as informações ficam facilmente desatualizadas, (ii) há
mecanismos que possuem pouca ou nenhuma informação, (iii)
ou com quantidade muito grande.
A fim de manter uma solução mais duradoura e inteligente, foi percebido que conceitos da Ciência da Informação
e Biblioteconomia poderiam complementar a Engenharia de
Software no intuito de resolver o problema. Durante os estudos
foi proposto a criação de uma biblioteca digital, contendo as
principais informações sobre os mecanismos, na qual cada um
é responsável pela manutenção de suas informações.
Em seguida, foram feitos estudos sobre as principais plataformas de software livre voltadas para construção de bibliotecas digitais. Analisando as principais características, podemos comprovar qual ferramenta que atende as necessidades
levantadas. Além disso foi realizada uma prova de conceito,
adotando um desses softwares para demonstração de uma
possível biblioteca digital de participação social.
Percebendo-se a possibilidade de colaborar com a Ciência
da Informação, foi feita uma proposta para ampliar a biblioteca
digital para um espaço semântico e social colaborativo, com
base em ontologias e metodologias já conhecidas a fim de
disponibilizar um ambiente mais completo para o usuário.
III. E STUDOS E R ESULTADOS
A biblioteca digital de participação social funcionará integrada com a plataforma Participa.br (Plataforma Federal
1 O IPEA (Fundação Instituto de Pesquisa Econômica Aplicada)fornece
suporte técnico e institucional às ações governamentais para a formulação de
políticas públicas e programas de desenvolvimento.
103
FEES
da Participação Social), que busca a criação de um espaço
colaborativo para participação social através de ferramentas e
metodologias.
Uma biblioteca digital não é somente uma coleção digital
com ferramentas para manter as informações. Ela é composta
por um ambiente que possui coleções, serviços e pessoas
apoiando um ciclo de vida de disseminação, uso e preservação
do dado, informação e conhecimento. A biblioteca digital
tem várias finalidades, dentre elas: (i) preservar objetos de
informação; (ii) melhorar a acessibilidade; e (iii) integrar
vários formatos de informação.
O Participa.br utiliza o Noosfero2 , uma plataforma livre
para criação de redes sociais. O Noosfero utiliza o arcabouço
Ruby on Rails, que influencia em maior produtividade para
o programador. Utiliza o padrão arquitetural Model-ViewController (MVC) e é extensível através de plugins.
Figura 1. Modelo de comunicação entre o portal e os mecanismos de
participação. Adaptado de [2]
Mediante o uso do protocolo de interoperabilidade 3 OAIPMH, que é um protocolo que permite o compartilhamento
de metadados 4 , foi realizado um primeiro protótipo de funcionamento da biblioteca. A Figura 1 representa um consórcio
de bibliotecas digitais, onde os mecanismos formais terão um
módulo de biblioteca digital pré-configurado e preencherão
informações, tais como: telefones de contato, nomes dos conselheiros, entre outras. O Participa.br (Noosfero), vai coletar
as informações dos mecanismos, já que terá acoplado a si um
plugin de biblioteca digital.
Dentro da participação social, a ampliação da biblioteca
digital para o contexto de web semântica é interessante, pois
a descrição dos mecanismos pode ser feita com auxílio da
comunidade de usuários, além de tornar mais abrangente
que uma biblioteca comum. Para a proposição inicial da
biblioteca, foram utilizadas como base: (i) a ontologia de
2 Maiores
informações em: http://www.noosfero.org
de dois ou mais componentes de software cooperarem [3].
4 Dados sobre outros dados, ou seja, são as informações detalhadas de
um determinado conteúdo (documentos, mídias, planilhas, etc) que está na
biblioteca
3 Capacidade
participação social feita por [4]; e (ii) a proposta metodológica
feita por [5]. Durante o decorrer do trabalho foi visto que
algumas ontologias podem ser utilizados, como é o caso da
FOAF (Friend of a Friend). Através da ferramenta LOV 5
(Linked Open Vocabularies), podem ser escolhidos diversos
vocabulários para serem usados na biblioteca semântica.
IV. C ONSIDERAÇÕES F INAIS
Em função das manifestações sociais que circulam pelo
País, o Participa.br tem sido considerado como uma plataforma
estratégica para o Governo Federal e há interesse direto na
sua divulgação e uso, com disponibilização de conteúdos que
beneficiam os mecanismos.
De fato, durante o período do trabalho de conclusão de
curso, foram realizadas várias atividades que passaram pelas
principais disciplinas presentes no currículo de graduação de
um Engenheiro de Software. Nas atividades relacionadas a
concepção e elaboração de projetos, o arcabouço visto no
curso foi proveitoso. No entanto, tendo em vista as dificuldades encontradas no desenvolvimento da biblioteca, dentre elas:
evolução de código fonte, instalação do software, manuseio
de servidores, etc, foi notado que as disciplinas não ajudaram
muito na solução desses problemas, pois o currículo aborda
muito pouco na área do desenvolvimento, algo que está
mudando nos currículos atuais.
Outro fator importante foi a possibilidade de integração da
Engenharia de Software com outras áreas de conhecimento
para solucionar o problema encontrado. Vendo que bibliotecas
digitais era a solução mais viável, analisamos que ainda não
seria um ambiente suficiente e utilizamos técnicas estudadas
na Engenharia de Software buscando a criação de um ambiente
mais completo para os usuários, já que entendemos que essa
é um dos principais objetivos do Engenheiro de Software.
Até o momento da escrita desse artigo, já foram feitas
proposições dos metadados iniciais para catalogação dos mecanismos, levantamento das principais ferramentas de bibliotecas digitais e criação de um ambiente de homologação para
biblioteca. Os próximos passos serão: formalizar a biblioteca
digital, criar o formulário para os mecanismos e estender a
biblioteca de participação.
Espera-se que, com essas iniciativas, o portal Participa.br
possa ser um catálogo de informações de participação social
sempre atualizado e organizado com a ajuda dos próprios
canais de participação.
R EFERÊNCIAS
[1] G. A. de Almeida, “Participação e controle social na garantia dos
direitos humanos,” 2011. [Online]. Available: http://www.dhnet.org.br/
dados/cursos/dh/cc/2/participacao.htm
[2] C. L. d. C. Renan Rodrigues de Oliveira, “Implementação de interoperabilidade entre repositórios digitais por meio do protocolo oai-pmh,” 2009.
[3] P. Wegner, “Interoperability,” ACM Computing Surveys, vol. 28, pp. 285–
287, 1996.
[4] R. Fabbri, “Relatório técnico do pnud - ontologia do portal federal de
participação social,” 2014.
[5] F. Solagna, “Análise de experiências nacionais e internacionais de participação mediada por internet,” 2014.
5 Base contendo as principais vocabulários utilizados em web semântica.
Disponível em: http://lov.okfn.org/dataset/lov/
104
FEES
Aspectos da Validação de Software em Metodologias Ágeis
Aplicáveis à Terceirização do Desenvolvimento de Software
Eduardo Pinto Barbosa
Orientadora: Elaine Venson
Universidade de Brasília – UnB,
Faculdade do Gama - FGA
Brasília, Brasil
Universidade de Brasília – UnB,
Faculdade do Gama - FGA
Brasília, Brasil
[email protected]
[email protected]
Trabalho de Conclusão de Curso de Graduação
I. INTRODUÇÃO
A administração pública federal brasileira tem aderido a
metodologias ágeis de desenvolvimento de software em suas
contratações de serviços de TI [1]. Um acórdão publicado pelo
Tribunal de Contas da União apresenta algumas das unidades
da administração pública que já fazem uso, assim como riscos
da utilização de metodologias ágeis na terceirização do
desenvolvimento de software [2].
TABELA I
Estágios da Iteração
Ágil
Interação entre Cliente e equipe de
desenvolvimento
Pré-Iteração
A aceitação e consequente pagamento dos serviços e
produtos de software em um contrato são dependentes da
validação dos mesmos [3]. A validação de software garante que
as necessidades e expectativas do cliente sejam satisfeitas e que
o produto certo esteja sendo desenvolvido ao longo do
processo [4].
Práticas de Validação de Software
Ágil
Interação entre Cliente e pessoas do
negócio
desenvolvimento
Planejamento
Iteração
da
Itens como os requisitos de software e o produto final
devem ser validados para se obter um produto de qualidade [5].
Interação
de
programadores
da
desenvolvimento
testadores
equipe
de
Requisitos ágeis
desenvolvimento
Este trabalho visa responder como práticas e
recomendações no desenvolvimento ágil se relacionam com
questões já estabelecidas sobre validação na engenharia de
software [6]. Especificamente, busca-se compreender como
ocorre a validação de software em processos de
desenvolvimento ágil e a partir deste entendimento, propõe
instrumentos para viabilizar esta atividade em um contexto de
terceirização de projetos de software por órgãos da
Administração Pública Federal.
Interação entre Cliente e pessoas do
negócio
Dentro da Iteração
Interação
de
programadores
da
desenvolvimento
testadores
equipe
de
Testes ágeis
Teste de Aceitação
II. VALIDAÇÃO ÁGIL
A iteratividade e entregas mais constantes do
desenvolvimento ágil fazem com que a validação desses itens
também ocorra iterativa e constantemente ao longo do projeto
[7]. As práticas de software que foram identificadas para
validação ágil são apresentadas na Tabela I.
Pós-Iteração/ Final
da iteração
Revisão da Iteração
III. CONCLUSÃO
Instrumentos foram desenvolvidos para um estudo de caso
especifico em um órgão da administração pública federal para
viabilizar a atividade de validação. Tais instrumentos são
apresentados na Tabela II.
105
FEES
TABELA II
Práticas de Validação de
Software Ágil
Interação entre Cliente e
pessoas do negócio
Interação entre Cliente e
equipe de desenvolvimento
Requisitos ágeis
Testes ágeis
Teste de Aceitação
Revisão da Iteração
O trabalho é resultado de uma pesquisa aplicada,
qualitativa e descritiva sobre aspectos da validação de software,
em que se analisam as práticas de validação de acordo com os
estágios de uma iteração do Processo de Desenvolvimento de
Software Ágil [8].
Instrumentos propostos para
o estudo de caso
Atuação do Product Owner
Partner (POP)
Atuação do Product Owner
Partner (POP)
Agenda do Product Owner
(PO)
Template de histórias de
usuário e critérios de
aceitação
Definição do conceito de
“Pronto” para a iteração
Definição dos testes a serem
utilizados pela equipe de
desenvolvimento
Template dos testes de
aceitação
Execução dos testes de
aceitação
Apresentação de resultados
dos testes
Decisão de Aceite
Apresenta-se um mapeamento e análise das práticas de
validação de software ágil, as quais foram materializadas em
instrumentos de validação ágeis e aplicadas ao processo de um
estudo de caso em uma organização da administração pública
federal brasileira.
REFERENCIAS
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
106
C. de O. Melo, V. Santos, E. Katayama, H. Corbucci, R. Prikladnicki,
A. Goldman, e F. Kon, “The evolution of agile software development in
Brazil”, J. Braz. Comput. Soc., vol. 19, no 4, p. 523–552, nov. 2013.
Brasil, “Acórdão 2314/2013”. Tribunal de Contas da União, 28-ago2013.
M. BRASIL, “Instrução Normativa - SLTI 4”. 12-nov-2010.
ISO/IEC, “ISO 12207:2008 - Standard for Systems and Software
Engineering - Software Life Cycle Processes.” IEEE, 2008.
A. Barti , Garantia da qualidade de software. Rio de Janeiro: Elsevier,
2002.
T. Dingsøyr, S. Nerur, V. Balijepally, e N. B. Moe, “A decade of agile
methodologies: Towards explaining agile software development”, J.
Syst. Softw., vol. 85, no 6, p. 1213–1221, jun. 2012.
R. E. Gallardo-Valencia e S. E. Sim, “Continuous and Collaborative
Validation: A Field Study of Requirements Knowledge in Agile”,
Second International Workshop on Managing Requirements Knowledge,
2009.
M. F. de C. Tozoni-Reis, Metodologia da Pesquisa, 2o ed. Curitiba:
IESDE Brasil S.A., 2009.
FEES
Mezuro, Evolução de Software Livre: Da
Arquitetura à Experiência do Usuário
Renan Costa1 , Vinícius Vieira1 , Paulo Meirelles1
1
{renan2703,vvieira17}@gmail.com, [email protected]
Resumo—Este trabalho apresenta um estudo e as colaborações
na evolução de uma plataforma para monitoramento de códigosfonte chamada Mezuro, que, em sua concepção, ela pensada como
um plugin de uma plataforma de redes sociais. Com sua evolução,
a equipe de desenvolvimento decidiu então por re-escrevê-la como
aplicação independente. Neste trabalho, apresentamos um relato
das nossas colaborações nesse projeto de software livre.
Index Terms—Métricas de software, software livre, análise de
código-fonte, contribuição, evolução de software, requisitos de
qualidade.
I. I NTRODUÇÃO
Há várias características que fazem do software um sistema
de qualidade ou não. Entre elas há algumas que são obtidas
exclusivamente através do código-fonte. Quando compilamos
um software, por exemplo, características podem ser analisadas, mas outras como organização e legibilidade não. Isso
não refletiria tamanho, modularidade, manutenibilidade, complexidade, flexibilidade, que são características encontradas na
análise de códigos-fonte [1]. O que define essas características
em sistemas de software são suas métricas de código-fonte. O
esforço necessário para extraí-las, ou obtê-las, manualmente
pode ser considerado imensurável. Quanto maior e mais complexo é o código, esse tipo de atividade se torna ainda mais
distante das equipes de desenvolvimento, dada a quantidade
de propriedades e linhas de códigos a se analisar, além de não
ser viável pelo tempo despendido. Existem ferramentas que
auxiliam nessas atividades, por meio da extração e monitoramento automático de métricas de código-fonte, auxiliando a
equipe durante o processo de desenvolvimento. Porém, existem
existem poucas ferramentas disponíveis, e muitas delas nem
sempre são adequadas para análise do projetos de software
livre [2], que é ponto central deste trabalho ao apresentamos
a evolução do projeto Mezuro. Dessa forma, o artigo está
organizado, de forma que, na Seção II, apresentamos o projeto
Mezuro; na Seção III, discutimos as contribuições deste trabalho ao projeto Mezuro; na Seção IV, abordamos a metodologia
de desenvolvimento usada; por fim, na Seção V fazemos as
considerações finais.
II. P ROJETO M EZURO
denominada Mezuro1 , que possibilita o monitoramento de
características específicas do software. O Mezuro foi concebido como instância de uma plataforma web conhecida como
Noosfero, com o plugin Mezuro ativado. O Noosfero é um
software livre para criação de redes sociais, que está disponível
sob licença AGPL 2 V3, com o intuito de permitir que os
usuários criem sua própria rede social livre e personalizada
de acordo com suas necessidades. Porém, o Noosfero limitava
o desenvolvimento do Mezuro, ao passo que as versões do
arcabouço Rails e da linguagem Ruby, tecnologias utilizadas
para seu desenvolvimento, eram versões antigas, sem tantos
recursos e com suporte menor da comunidade comparando
com as versões mais atuais. Além disso, os recursos relacionados a redes sociais não são tão relevantes para ferramentas
de análise de código-fonte. Adição e remoção de recursos que
não se encaixam no ambiente onde o sistema está inserido
são intenções da evolução de software. Dessa forma, a equipe
do Mezuro decidiu pela reescrita do seu código, extraindo-o
do Noosfero e transformado-o numa plataforma independente,
desenvolvida com as versões mais novas do arcabouço Rails e
da linguagem Ruby. Essa decisão foi importante, não apenas
pelo ganho de liberdade no desenvolvimento ou por tornar o
Mezuro uma ferramenta mais enxuta, e concisa em relação as
suas funcionalidades. Ela foi relevante também para formatar
uma comunidade de software livre, formada não apenas pela
equipe core, a qual concebeu o Mezuro, mas também por
desenvolvedores externos, ou co-desenvolvedores.
III. C ONTRIBUIÇÕES
As contribuições, do ponto de vista de implementação, da
equipe UnB para o Mezuro, podem ser divididas em cinco grupos, que representam os ciclos de desenvolvimento de algumas
das features do Mezuro. São elas: i) Manter Repositórios; ii)
Manter Configurações; iii) Refatoração do Fluxo de Adição
de Métricas de Configuração; iv) Aplicação de uma Técnica
de Visualização de Informações; v) Aplicação de Técnicas
de Usabilidade. Para monitorar um determinado código-fonte
no Mezuro é necessário, criar uma conta de usuário. Com
a conta criada é possível criar um projeto, o qual pode
conter um repositório de dados ou mais. O monitoramento do
A partir da necessidade de extrair métricas de código-fonte
e interpretar seus valores, foi desenvolvida uma plataforma
107
1 http://mezuro.org/
2 Licença
de software GNU Affero General Public License
FEES
código-fonte acontece por meio da entidade repositório, que é
processado e apresenta as métricas ao usuário no final.
A primeira contribuição relacionada a este trabalho foi a
funcionalidade de Manter Repositórios. Apesar de simples, é
uma funcionalidade vital para o funcionamento do Mezuro,
além de representar o primeiro contato com as tecnologias
envolvidas no projeto, e a primeira contribuição de desenvolvedores externos à equipe core. A segunda funcionalidade
foi Manter Configurações, a qual teve um tempo de sprint
de uma semana, já que a familiaridade com o código-fonte
e tecnologia estava maior. A terceira funcionalidade por sua
vez, foi a que teve o maior ciclo de desenvolvimento, e foi
desenvolvida em sua grande parte utilizando pair programmming. O objetivo dessa terceira contribuição era melhorar o
fluxo de adição de métricas de configuração, que era pouco
eficiente e monótono para o usuário. A quarta contribuição,
relacionada a visualização de software, teve o objetivo de
aplicar uma técnica de visualização de software ao Mezuro.
A visualização de software é um ramo da visualização de
informações que mais cresce atualmente. Tem como objetivo
principal aumentar o poder de compreensão das informações
apresentadas, neste caso as métricas, por meio de gráficos
ou técnicas de visualização. A quinta contribuição aconteceu
paralelamente a todas as outras contribuição. Ela se resume
em vários ciclos de usabilidade que objetivavam melhorar a
utilização do sistema pelos usuários finais aplicando princípios
ou técnicas de usabilidade ao Mezuro. Entretanto, os aspectos
relevantes deste trabalho não estão restritos apenas aos pontos
práticos ou de implementação citados. A colaboração com um
software livre, de acordo com os padrões de contribuição voltadas para softwares livres, passando por vários dos processos
que compõem a engenharia de software, além da aplicação
de práticas ágeis, interação e envolvimento com uma equipe
remota também são pontos notáveis deste trabalho.
IV. M ETODOLOGIA DE D ESENVOLVIMENTO
Durante as contribuições foi possível observar os seguintes
grupos de padrões associados às colaborações com softwares
livre: i) Padrões de seleção; ii) Padrões de envolvimento; iii)
Padrões de contribuição. No grupo dos padrões de seleção,
aquele que foi mais relevante para este trabalho foi o terceiro
padrão, o qual incentiva os futuros colaboradores a procurar
por projetos que ofereçam funcionalidades atrativas, independente da familiaridade com as tecnologias envolvidas. E foi
exatamente isso que foi feito num primeiro momento, onde
não havia conhecimento das tecnologias utilizadas no desenvolvimento do Mezuro. Entretanto suas funcionalidades despertavam o interesse para as contribuições. Diversos padrões
do grupo de envolvimento foram aplicados, já que muitos
colaboradores da plataforma, auxiliaram durante o processo
de envolvimento, apresentando funcionalidades e principais
cenários do sistema, além de fornecer documentação necessária para o entendimento do contexto no qual o Mezuro está
inserido. Os dois primeiros grupos tratam de como iniciar e se
familiarizar com o projeto, enquanto o grupo de contribuição
trata do fornecimento de insumos adequados para o projeto
de software livre, sejam eles código-fonte ou outros artefatos
presentes no desenvolvimento. As políticas estabelecidas no
processo de desenvolvimento do Mezuro, como política de
commits e padrões de desenvolvimento satisfazem a grande
parte desses padrões.
Já em relação às práticas ágeis utilizadas dentro dos ciclos
de desenvolvimento, destacam-se o pair programming, divisão
das iterações em sprints, sprint planning meetings e sprint
review meetings. As práticas do pair programming foi a
mais eficiente, já que otimizava o tempo, seja na rapidez
no alcançe dos objetivos ou na passagem de conhecimento
a outro desenvolvedor. Em relação a eficácia há destaque
para a prática da revisão da sprint, pois ajustes eram feitos,
quando necessário, o que contribuía bastante para o alcance
dos objetivos na iteração seguinte.
V. C ONSIDERAÇÕES F INAIS
A evolução do Mezuro não foi motivada por um motivo
isolado. Um conjunto de fatores influenciaram e convenceram
a equipe que o melhor para o futuro do projeto Mezuro
seria um conjunto de modificações em sua estrutura. Os
desenvolvedores estavam restritos aos ultrapassados recursos
do Rails 2 e do Ruby 1.8, a qual não recebia mais suporte de
seus desenvolvedores. A equipe criadora do Mezuro almejava
por liberdade na tomada de decisões, como por exemplo
atualizar o Mezuro para as novas versões do Rails e do
Ruby, aproveitando suas melhorias e novos recursos. Porém,
estavam subordinados as decisões e andamento do projeto
Noosfero. A equipe se deu conta que os recursos relacionados
a redes sociais fornecidos não eram necessários para uma
ferramenta de monitoramento de código-fonte. Além disso,
a manutenibilidade e inserção de novos desenvolvedores ao
projeto eram tarefas difíceis, já que o Mezuro crescia bastante
e se tornava cada vez mais uma aplicação dentro de outra
aplicação, ao invés de um plugin com funcionalidades bem
específicas.
Os aspectos relevantes deste trabalho não estão restritos
apenas aos pontos práticos ou de implementação citados.
A colaboração com um software livre, de acordo com os
padrões de contribuição, passando por vários dos processos
(implementação, gerencia de configuração, requisitos e manutenção e evolução de software) que compõem a engenharia de
software, além da aplicação de princípios ágeis. Por fim, as
melhorias alcançadas por essas contribuições foram medidas
através de questionários e avaliação heurística aplicados aos
contribuidores originais da plataforma.
R EFERÊNCIAS
[1] P. R. M. Meirelles, “Monitoramento de métricas de código-fonte em
projetos de software livre,” Ph.D. dissertation, Instituto de Matemática
e Estátistica – Universidade de São Paulo (IME/USP), 2013.
[2] P. Meirelles, C. Morais, R. Martins M., F. Kon, C. Santos Jr., and
J. Maldonado, “Mezuro: A source code tracking platform,” Ph.D. dissertation, FLOSS Competence Center – University of São Paulo, Instituto
de Matemática e Estatística, Maio 2010.
108
FEES
Técnicas de usabilidade e testes automatizados em
processos de desenvolvimento de software empírico
Rodrigo Medeiros, Jônatas Medeiros, Paulo Meirelles
{rodrigo.mss01,jonatasmm}@gmail.com, [email protected]
Resumo—Este artigo apresenta um estudo sobre usabilidade
e testes automatizados no desenvolvimento empírico de software,
voltado para a plataforma livre Noosfero. Neste estudo, levantamos hipóteses sobre a influência dos testes automatizados nas
técnicas de usabilidade.
Index Terms—Testes Automatizados, Usabilidade, Métodos
Empíricos, Software Livre, Métodos Ágeis
I. I NTRODUÇÃO
O desenvolvimento de software usando métodos empíricos,
como software livre e métodos ágeis, é uma realidade, tendo
como prática básica testes automatizados, preocupando-se com
as aplicações de testes em sistemas dinâmicos e reutilizáveis
elevando qualidade e produtividade [1]. Adicionalmente, a
usabilidade vem sendo estudada para ser aplicadas no desenvolvimento de software. Criar software que seja útil e fácil
de usar é fator importante para a evolução dos sistemas [2].
O Noosfero, plataforma de desenvolvimento em que se baseia
as aplicações estudadas, já teve iniciativas para a melhoria da
usabilidade.
II. M ÉTODOS E MPÍRICOS DE D ESENVOLVIMENTO DE
S OFTWARE
O Empirismo baseia-se na aquisição de sabedoria através
da percepção do mundo externo [3]. Como método empírico,
Software livre é uma filosofia que trata programas de computadores como fontes de conhecimento que devem ser compartilhados. A utilização de métodos ágeis no desenvolvimento tem
como características intrínsecas a flexibilidade e rapidez nas
respostas a mudanças. Existe uma relação entre métodos ágeis
e software livre, que tem a essência da sua comunidade em
manter indivíduos que interajam de forma a produzir o que
é mais importante [4]. Além de compartilharem os mesmos
valores, sendo métodos empíricos, que buscam tomar decisões
rápidas de acordo com a percepção do mundo externo.
III. T ESTES
A automação de testes é uma prática ágil, eficaz e de
baixo custo para melhorar a qualidade do software. Os testes
automatizados afetam diretamente a qualidade do software,
mesmo que os artefatos produzidos não sejam visíveis para
os usuários finais [5]. Esses testes podem ser divididos em
diversos tipos, sendo os abordados neste estudo:
1) Testes de unidade: testes de correção responsável pelos
menores trechos de código com um comportamento [5].
2) Testes funcionais: testes que tem como objetivo verificar a eficiência dos componentes de um sistema [6].
3) Testes de aceitação: testes para verificar se um módulo
se comporta como foi especificado [7].
Foram utilizados neste estudo, o desenvolvimento dirigido
por testes, TDD (Test-Driven Develepment), é uma técnica se
dá pela repetição de um ciclo de passos de implementação de
testes e do sistema [8]. E a técnica de desenvolvimento dirigido
por comportamento (BDD - Behavior Driven Development)
que induz a utilização de uma linguagem ubíqua entre cliente
e equipe de desenvolvimento.
IV. U SABILIDADE
A usabilidade é definida como o fator que assegura que
um produto é fácil de usar, eficiente e agradável [9]. Para
entender o que é usabilidade e como ela está inserida no desenvolvimento de software, precisamos compreender algumas
relações: Design centrado no usuário é uma filosofia baseada
nas necessidades e interesses dos usuário, com ênfase em
fazer produtos usáveis e inteligíveis [10]. O termo é usado
frequentemente para sintetizar toda a experiência com um
produto de software. Não engloba somente as funcionalidades
e sim o quanto é agradável ao usuário [11]. Um problema
encontrado em softwares livres é a pouca atenção aos aspectos
de usabilidade, o que pode ser causado pela sua própria
comunidade que apenas enfatiza na criação, melhoria e teste do
código fonte. A integração entre os processos de usabilidade
e métodos ágeis é esperada visto que tanto os métodos ágeis
como a usabilidade tem em comum características que tem
foco nas necessidades dos usuários.
V. E STUDO
Foi planejado um estudo de usabilidade para analisar a interação dos usuários com o portal Participa.Br a fim de avaliar
a qualidade em uso do portal. Este estudo de usabilidade
será aplicado na segunda fase deste trabalho. Assim, foram
definidas questões sobre o que é preciso saber de forma a
apoiá-la a entender se o objetivo foi alcançado, e para cada
questão foram definidas as métricas relacionadas na Tabela I:
Elencamos algumas técnicas para identificação dos usuários:
109
FEES
Questões
Q1. Qual o perfil do
usuário que utiliza
o Participa.Br?
Q2. Qual o grau de
satisfação do usuário
do Participa.Br
Q3. Quantidade de tempo
gasto para realizar
as tarefas
Métricas
Perfil
Diretrizes para
interpretação
Análise de Dados Estatísticos,
criação de personas, análise
dos dados qualitativos
Satisfação
do usuário
Escore da satisfação global
pelo usuário
Duração
Tempo gasto
Tabela I
Q UESTÕES DE P ESQUISA
1) Dados Estatísticos : Possibilita identificar algumas informações sobre o perfil dos usuários, coletadas de base
de dados, redes sociais, etc.
2) Questionário de identificação de perfil dos usuários:
Pesquisa que busca compreender quem são, qual o
conhecimento e como utilizam o sistema.
3) Identificação de Personas: “Persona” são personagens
fictícios criados com base em dados reais.
Elencamos algumas técnicas para avaliar a usabilidade do
portal Participa.Br:
Técnica
Observar Usuários
Perguntar aos usuários
Descrição
Um observador irá registrar o tempo gasto por cada
participante para concluir o estudo de caso, avaliar a
ferramenta e se necessitou de alguma ajuda
Os questionários ASQ e PSSUQ de satisfação dos
usuários será utilizado para coletar as opiniões dos
participantes.
Tabela II
T ÉCNICAS DE AVALIAÇÃO PARA OS TESTES COM USUÁRIOS
Os instrumentos de coletas de informações utilizados são
dois questionários para medir a satisfação do usuário. São eles
o After-Scenario Questionnaire (ASQ) destinado ao uso em
testes de usabilidade baseados em cenários. Possui três itens:
(1) facilidade de conclusão da tarefa, (2) tempo necessário
para completar uma tarefa e,(3) a adequação das instruções
ou materiais de apoio fornecidos. Ainda temos o Post-Study
System Usabiliy Questionnaire (PSSUQ), aplicado após a conclusão de todos os cenários para uma avaliação da usabilidade
do sistema de forma mais ampla, podendo avaliar: satisfação
geral, utilidade do sistema, qualidade da interface e qualidade
da informação.
O estudo sobre testes teve enfoque na rede Comunidade
UnB, sendo desenvolvidos alguns plugins para verificar a
aplibilidade. A rede Comunidade UnB necessita de restrição
de acesso aos usuários. Assim foi desenvolvido um plugin no
noosfero, que efetuasse essas restrições, utilizando o protocolo
de autenticação da UnB, o LDAP (Lightweight Directory
Access Protocol).
Com os testes unitário e funcionais do plugin alcançamos
os seguintes dados:
• Quantidade de testes executados: 96 testes;
• Quantiadde de falhas obtidas: 0 falhas;
• Taxa de cobertura de código: 88.94;
Outro plugin (plugin de Envio de TCC) desenvolvido para
o Noosfero, porém em uma aplicação diferente, o Portal UnB
Gama, é responsável por criar uma atribuição de trabalhos,
chamada de work assignment. Essa atribuição possui algumas
funcionalidades específicas como possibilitar que os usuários
envolvidos sejam notificados via email sobre a submissão de
um trabalho. Segue os dados sobre a execução dos testes:
• Quantidade de testes executados: 28 testes;
• Taxa de cobertura de código: 73.30;
Para o plugin de envio de tcc, foram definidos testes de
aceitação, para verificar o comportamento da funcionalidade:
• Quantidade de cenários executados: 6 cenários;
• Quantidade de passos executadas: 130 passos;
VI. C ONSIDERAÇÕES FINAISS
Com desenvolvimento baseado em testes e a avaliação de
usabilidade voltados para o Noosfero, chegamos a algumas
hipóteses que serão respondidas na segunda fase do trabalho.
• Como inserir os princípios de usabilidade no processo
desenvolvimento empírico de software?
• É possível alcançar melhores resultados em testes de
usabilidade utilizando práticas do BDD e TDD?
Nesse contexto, a ideia do estudo inicial sobre projeto
Participa.Br foi conhecer como funciona algumas técnicas de
avaliação da usabilidade. Aplicamos as técnicas de usabilidade
pesquisadas durante o trabalho, em um processo baseado em
BDD e TDD, a fim de verificar problemas de usabilidade, e
satisfação e uso em um estudo de caso da plataforma Noosfero.
Assim, a segunda fase deste trabalho de graduação será aplicar
o estudo realizado, a fim de verificar a influência de testes
automatizados na usabilidade do sistema e possui previsão de
entrega em dezembro de 2014.
R EFERÊNCIAS
[1] A. A. Vicente, “Definição e gerenciamento de métricas de teste no
contexto de métodos ágeis,” Master’s thesis, USP - Universidade de
São Paulo, 2010.
[2] A. P. Santos, “Aplicação de práticas de usabilidade ágil em software
livre,” 2012.
[3] M. Chauí, Convite a filosofia, 2003.
[4] H. Corbucci, “Métodos ágeis e software livre: um estudo da relação
entre estas duas comunidades,” Ph.D. dissertation, Universidade de São
Paulo, 2011.
[5] P. C. Bernardo, “Padrões de testes automatizados,” Master’s thesis,
Instituto de Matemática e Estatística – Universidade de São Paulo,
2011. [Online]. Available: http://www.teses.usp.br/teses/disponiveis/45/
45134/tde-02042012-120707/
[6] L. Molinari, Teste de Software. Produzindo Sistemas Melhores e Mais
Confiáveis., 2003.
[7] R. C. Martin, “The test bus imperative: Architectures that support
automated acceptance testing,” 2005. [Online]. Available: http:
//www.martinfowler.com/ieeeSoftware/testBus.pdf
[8] L. Koskela, Test Driven: Pratical TDD and Acceptance TDD for Java
Developers. Manning Publications, 2007.
[9] J. Preece, Y. Rogers, and H. Sharp, Design de Interação: Além do homem
computador, 2007.
[10] D. Norman, O design do dia-a-dia. Rocco, 2006. [Online]. Available:
http://books.google.com.br/books?id=8zd8PgAACAAJ
[11] t. Lowdermilk, Design Centrado no Usuário: Um guia para o desenvolvimento de aplicativos amigáveis, 2013.
110
FEES
O desenvolvimento do Novo Portal do Software
Público Brasileiro
Camila Ferreira1 , Aline Gonçalves1 , Marisa Santos2 , Paulo Meirelles1 , Hilmer Neri1
1
Faculdade UnB Gama – Universidade de Brasília (UnB), Brasil
Ministério do Planejamento, Orçamento e Gestão (MP), Brasil
{camilaferreira251,alinegsantoss}@gmail.com, [email protected], {paulormm,hilmer}@unb.br
2
Resumo—O Portal do Software Público Brasileiro (SPB), na
prática, é um sistema web que se consolidou como um ambiente
de compartilhamento de softwares. O projeto de evolução deste
portal está sendo desenvolvido pela Universidade de Brasília e
conta com integrantes de diversos perfis e níveis de formação.
O projeto utiliza algumas práticas de métodos ágeis em sua
metodologia de desenvolvimento. O objetivo deste artigo é relatar
a experiência no desenvolvimento, ao lado do Ministério de
Planejamento.
Index Terms—Engenharia de Sofware, Software Livre, Software Público, Evolução de Software
I. I NTRODUÇÃO
O governo federal brasileiro vem nos últimos anos buscando
melhorias nos seus processos de desenvolvimento e adoção de
software. Desde 2003, a recomendação da adoção de software
livre passou a ser uma política incentivada na esfera federal,
inicialmente com a criação do Guia Livre1 . Hoje, tal iniciativa
é coordenada pelo Comitê Técnico de Implementação de
Software Livre do Governo Federal2 .
No contexto da promoção do software livre no governo
federal, a Secretaria de Logística e Tecnologia da Informação
(SLTI) do Ministério do Planejamento, Orçamento e Gestão
(MP) inaugurou em 2007, o Portal do Software Público Brasileiro (SPB)3 , que é um sistema web que se consolidou como
um ambiente de compartilhamento de projetos de software no
governo. Por exemplo, a Instrução Normativa 04/20124 indica
que os gestores devem consultar as soluções existentes no
Portal do SPB antes de realizar uma contratação de software.
Hoje, com o portal do SPB tem cerca de 69 comunidades de
desenvolvimento e mais de 200.000 usuários cadastrados.
Entretanto, a evolução do SPB foi comprometida, desde
2009, quando a plataforma do SPB não acompanhou a evolução do seu framework base, o OpenACS5 . Com isso, não
tendo versões lançadas a partir daquele ano.
Nesse contexto, um dos passos para a concretização de
uma nova plataforma para o SPB é a integração com novas
tecnologias, desde uma plataforma colaborativa até sistemas
1 governoeletronico.gov.br/acoes-e-projetos/guia-livre
2 softwarelivre.gov.br
3 softwarepublico.gov.br/O_que_e_o_SPB
4 governoeletronico.gov.br/biblioteca/arquivos/instrucao-normativa-no-04de-12-de-novembro-de-2010
5 openacs.org
de controle de versão e de monitoramento da qualidade do
código-fonte. Para concretizar a evolução do SPB, a Universidade de Brasília está coordenando tal processo, através de
uma equipe heterogênea de alunos, professores e profissionais,
que estão aplicando práticas colaborativas de desenvolvimento
de software e gestão de projeto que impactam no projeto e,
em especial, na aprendizagem dos envolvidos. A equipe é
formada, em sua maioria, por estudantes de graduação e de
pós-graduação, os quais estão tendo sua formação complementada por meio dessa oportunidade de participarem como
protagonistas em um projeto de grande magnitude, o qual
envolve dezenas de comunidades e milhares de usuários.
II. A RQUITETURA E TECNOLOGIAS PROPOSTAS
A solução que irá atender a evolução e reformulação do
Portal do Software Público Brasileiro é composto por diversos módulos, os quais irão comunicar-se entre si de forma
organizada e integrada para suprir as necessidades do projeto.
Figura 1. Proposta de arquitetura do Novo Portal do Software Público
No início do projeto realizamos estudos de possíveis ferramentas que pudessem ser utilizadas para atender as necessidades do projeto, chegando então na lista apresentada abaixo.
Na análise realizada chegamos ao entendimento que utilizar
elementos já oferecidos por softwares livres existentes seria o
ideal, pois eles já atendem às nossas necessidades, evitando o
retrabalho e customizando os elementos necessários.
111
FEES
As ferramentas que serão utilizadas para suprir essas necessidades serão:
• Para lista de e-mail estamos utilizando o Mailman na versão
2, que é um software livre para gerenciamento de discussão
eletrônica de e-mail e listas e- newsletter;
• Para Chat estamos utilizando Punjab BOSH (XMPP), que é
uma interface HTTP de cliente jabber. É um gerenciador de
conexão BOSH que permite conexões de clientes persistentes
para um servidor XMPP (protocolo de comunicação para
mensagens orientadas a middleware baseado em XML);
• Para Plataforma de Buscas estamos utilizando Apache Solr,
que é uma plataforma de busca open source da Apache
Lucene escrita em Java;
• Para rede social estamos utilizando o Noosfero que é uma
plataforma web livre para criação de redes sociais com blog,
e-Portifólios, CMS, RSS, discussão temática, agenda de eventos, galeria de imagens, chat, entre outros. O desenvolvimento
dele foi iniciado pela Cooperativa de Tecnologias Livres –
Colivre em 2007, sob a licença AGPL v.3, com a proposta
de permitir ao usuário criar sua própria rede social personalizada, livre e autônoma;
• Para Forge com SVN estamos utilizando o Trac, que é uma
ferramenta open source para controle de mudanças em projetos de desenvolvimento;
• Para sistemas de controle de versão estamos utilizando SVN
e Git, que são ferramentas open-source para controle de
mudanças em projetos de desenvolvimento;
• Para Forge com Git estamos utilizando o GitLab, que é um
software livre de colaboração de código online que utiliza a
ferramenta de gerência de código fonte Git;
• Para sistema de gerenciamento estamos utilizando o Redmine, que é uma aplicação web de gerenciamento de projetos
que disponibiliza diversas ferramentas para auxiliar a gestão
e manutenção de um projeto;
• Para suporte a single sign on estamos utilizando o Mozilla
Persona, que foi desenvolvido pela Mozilla e permite o suporte a single sign on;
• Para Sistema de Integração contínua estamos utilizando o
Jenkins, que é uma aplicação web de integração contínua de
construção de projetos.
Para reunir todas estas ferramentas estamos utilizando o
Colab, que é uma plataforma de integração de ferramentas.
Nele, são também integradas as interfaces das ferramentas para
que, ao navegar, o usuário tenha a sensação de estar navegando
em uma única ferramenta.
III. M ETODOLOGIA
Pelo contexto colaborativo e empírico do desenvolvimento
de software livre, adotamos algumas práticas ágeis com base
nas experiências destacadas em [1] e [2], sobre a motivação de
adoção dos métodos ágeis, XP e Scrum, no desenvolvimento
de software moderno, as quais são apresentadas a seguir.
Para melhor gerenciamento a duração total do projeto foi
dividida em sete Releases, cada uma com duração de quatro
meses. Ao final de cada release é realizada uma entrega. Ou
seja, serão ao todo sete etapas de resultados a serem disponibilizadas ao longo da execução do projeto. Para homologação e
ateste técnico, é disponibilizado um resultado prévio um mês
antes da entrega da Release, chamadas de Releases Candidatas.
Assim, a partir da disponibilização do resultado da release
candidata, temos trinta dias para ajustes, correções e testes
finais.
Além disso, são disponibilizados resultados intermediários
mensalmente. Trata-se da oportunidade da equipe da SLTI/MP
poder fornecer feedbacks de possíveis alterações ou novas
funcionalidades, as quais são tratados como novos itens no
backlog para priorização.
A equipe utiliza a prática de programação em par para
o desenvolvimento de todas as histórias de usuários, que
representam as funcionalidades a serem desenvolvidas, e histórias técnicas. Temos observado que tal prática facilita o
nivelamento e a disseminação do conhecimento entre todos os
membros da equipe sem atrapalhar a produtividade da mesma,
pelo contrário, com essa prática a validação e a verificação da
história é mais confiável por estar sendo feito por pelo menos
duas pessoas.
Devido a formação diversificada, a disponibilidade de horário variadas e a distribuição geográfica da equipe (com
integrantes de Brasília, da Bahia e de São Paulo), precisamos
definir algumas práticas que facilitassem a comunicação entre
os integrantes.
Para informar o status das tarefas do projeto e evitar falhas
de comunicação mantemos uma lista de e-mail com todos
os integrantes do projeto, na qual é relatado diariamente o
status das histórias da sprint atual e eventuais problemas que
precisam ser resolvidos.
Para manter o controle das atividades do projeto, utilizamos
a ferramenta de gerenciamento Redmine com configuração
ágil, onde são mantidos o product backlog com as histórias de
usuários, as histórias técnicas e suas respectivas tarefas. Para
cada história, há um responsável associado, o qual responde
pelo progresso da história, e uma pontuação, que corresponde
ao esforço planejado para a mesma.
Baseado nos eventos da metodologia ágil Scrum, a equipe
realiza algumas cerimônias, dentre elas: Stand-up, Reuniões
de planejamento (com Planning Poker) e Reuniões de encerramento (com retrospectivas).
IV. C ONCLUSÃO
Concluímos que a utilização de metodologias ágeis contribuíram favoravelmente para o desenvolvimento do projeto,
pois o escopo do mesmo está em contínua mudança e tais
metodologias facilitaram a adaptação da equipe. Destacamos
que XP e Scrum complementam um ao outro bem, com o
XP provendo suporte para aspectos mais técnicos enquanto o
Scrum provê práticas e técnicas para gerenciamento, planejamento e acompanhamento.
R EFERÊNCIAS
[1] K. Schwaber and M. Beedle, Agile Software Development with Scrum,
1st ed. Upper Saddle River, NJ, USA: Prentice Hall PTR, 2001.
[2] B. Fitzgerald, G. Hartnett, and K. Conboy, “Customising agile methods
to software practices at intel shannon,” Eur. J. Inf. Syst., pp. 200–213,
2006.
112
FEES
Rede de colaboração social para universidades
brasileiras: um estudo de caso de implantação e
desenvolvimento distribuído de uma plataforma
livre na Universidade de Brasília
Daniel Costa Bucher1 , Paulo Meirelles1
1
[email protected], [email protected]
Resumo—Este trabalho de conclusão de curso apresenta os
resultados de um estudo para viabilizar a implantação de
uma rede de colaboração para a Universidade de Brasília
(UnB), que atue como um ambiente virtual para a criação e
o compartilhamento de conhecimento de forma colaborativa e
horizontal. Para isso, escolhemos utilizar a plataforma brasileira
para redes sociais livres Noosfero, por entender que esta satisfaz
as necessidades imediatas do projeto, de acordo com estudos
feitos pela Universidade de São Paulo, quando adotou a mesma.
Além da implantação em si na UnB, este estudo contemplou um
levantamento de requisitos e a implementação de um conjunto
de funcionalidades e melhorias para a plataforma em questão,
de forma que atendesse as necessidades básicas para podermos
realizar estudos de caso com alunos da UnB Gama. Dessa forma,
indicando como podemos oficializar a rede Comunidade.UnB,
bem como quais os próximos passos para que melhor atenda o
público dessa universidade. Adicionalmente, os esforços e conhecimento adquiridos neste trabalho foram repassados para uma
equipe de desenvolvedores na UnB Gama, o que proporcionará a
continuidade e concretização da implantação desta rede na UnB,
em 2014.
Index Terms—Redes sociais, software livre, engenharia de
software, Ruby on Rails.
I. I NTRODUÇÃO
Este artigo apresenta os resultados de um estudo de caso
de implantação e desenvolvimento de software livre na Universidade de Brasília (UnB). O software livre em questão
é o Noosfero1 , uma plataforma para a criação de redes
sociais livres criada pela Cooperativa de Tecnologias Livres
- Colivre2 , uma empresa cooperativa que atua exclusivamente
com soluções livres. As contribuições para a comunidade do
Noosfero são feitas por alunos do Laboratório Avançado de
Produção, Pesquisa e Inovação em Software (LAPPIS)3 da
UnB Gama desde junho de 2013 e produziram como resultado
a implantação e a manutenção de dois ambiente Noosfero na
universidade: (i) Comunidade.UnB4 , e o (ii) Portal da UnB
Gama5 . O primeiro é uma rede de colaboração social para
alunos, professores e funcionários técnico-administrativos da
UnB, ainda em estágio de homologação, e tem por objetivo
fornecer um ambiente virtual para a criação e o compartilhamento de conhecimento. O segundo é o portal de informações
e notícias da Faculdade do Gama (UnB/FGA). Até a data
da escrita deste artigo, os alunos do LAPPIS já contribuíram
com mais de vinte merge requests incorporados no core do
Noosfero e o Comunidade.Unb já possui 167 usuários e 24
comunidades.
II. F UNDAMENTAÇÃO T EÓRICA
O princípio básico do ecossistema do software livre é
promover a liberdade do usuário, sem discriminar quem tem
permissão para usar um software e seus limites de uso, baseado
na colaboração e num processo de desenvolvimento aberto.
Software livre é aquele que permite aos usuários usá-lo,
estudá-lo, modificá-lo e redistribui-lo, em geral, sem restrições
para tal e prevenindo que não sejam impostas restrições
aos futuros usuários [1]. Entendemos que este modelo de
desenvolvimento de distribuição de software seja o ideal em
um estudo de caso envolvendo uma universidade, uma vez
que entendemos ser o papel da universidade não só promover
a construção de conhecimento, mas também a disseminação
deste conhecimento para a sociedade. A utilização do software
livre permite isso por causa dos direitos que este fornece6 .
Nesse contexto, o Noosfero é uma plataforma web livre
para criação de redes sociais,com a proposta de permitir aos
usuários criarem sua própria rede social personalizada, livre e
autônoma.
O Noosfero foi desenvolvido na linguagem de programação Ruby versão 1.8.7, e utiliza o framework Model-ViewController (MVC) para aplicações web Ruby on Rails, versão
2.3.5. Este framework possui uma alta capacidade produtiva
1 http://noosfero.org/
4 http://comunidade.unb.br/
2 http://colivre.coop.br/
5 http://fga.unb.br/
3 http://fga.unb.br/lappis/
6 Extraído
113
de http://www.gnu.org/ em Julho de 2014
FEES
por priorizar conceitos como convention over configuration
e DRY (Don’t Repeat Yourself ). Além disso, a comunidade
do Ruby on Rails é bem alinhada e adota várias práticas da
comunidade de metodologias ágeis de desenvolvimento, como
o TDD e o BDD. Estas práticas foram utilizadas neste trabalho.
Além disso, a arquitetura do Noosfero foi pensada para
permitir que este seja facilmente expansível, de forma que
funcionalidades que não sejam comuns ao conceito de redes
sociais sejam desenvolvidas como plugins, assim diminuindo
o acoplamento e aumentando a coesão dos diversos módulos
do sistema.
III. M ETODOLOGIA
O processo de colaboração com o Noosfero inclui uma série
de práticas apresentadas pelas metodologias ágeis de desenvolvimento de software como o uso de testes automatizados,
a descrição das funcionalidades do projeto no formato de
histórias de usuário e a adoção de ferramentas para a utilização
da metodologia Behavior Driven Development (BDD)7 , uma
evolução do Test Driven Development (TDD)8 apresentada por
Dan North [2].
Em suma, o processo de desenvolvimento de software utilizado durante este trabalho também se baseia em metodologias
ágeis, com a utilização de ciclos curtos de forma a permitir
que haja feedback de forma mais rápida. A funcionalidades
desenvolvidas eram então submetidas upstream e passam por
uma revisão dos commiters oficiais do Noosfero antes de
serem incorporadas, o que permite que o desenvolvedor tenha
feedback sobre a qualidade de seu código e possa melhorá-lo
caso necessário.
IV. R ESULTADOS
A primeira funcionalidade desenvolvida surgiu da necessidade de se ter sub-comunidades para cada projeto da disciplina
de Manutenção e Evolução de Software da FGA, ministrada
pelo Prof. Paulo Meirelles. O Noosfero já possuia um plugin
que adicionava a possibilidade de criamos sub-comunidades
de determinada comunidade, no entanto este não oferecia
uma forma clara do usuário visualizar a relação entre estas.
Como primeira colaboração deste trabalho, desenvolvemos
uma camada de visualização, dentro de uma comunidade,
na qual o usuário pudesse visualizar todas as comunidades
“filhas” ou todas as comunidades “pais” desta, uma vez que
a relação entre comunidade e sub-comunidade é de N para
N. Esta contribuição pode ser visualizada na comunidade da
disciplina mencionada9 .
Outra contribuição interessante pro contexto da UnB, foi a
melhoria no plugin de submissão de trabalhos, uma demanda
que surgiu da necessidade de existir um sistema web no qual os
alunos pudessem enviar seus trabalhos de conclusão de curso
7 http://en.wikipedia.org/wiki/Behavior-driven_
development
8 http://en.wikipedia.org/wiki/Test-driven_
development
9 http://comunidade.unb.br/profile/mes-fga/plugin/
sub_organizations/children?display=full&type=
community
(TCC) e notificar seus orientadores e outros interessados a respeito. Este plugin permite não só que os alunos façam upload
de um arquivo, mas também que o mesmo seja versionado,
criando uma nova versão para cada novo upload realizado pelo
mesmo aluno, além de permitir a possibilidade de notificar
pessoas interessadas via e-mail. No primeiro semestre de 2014,
foi realizado um teste10 com os alunos do curso de engenharia
de software da FGA que estivessem fazendo TCC.
A wiki do Participa.Br11 , um projeto de uma rede social
livre para possibilitar a participação social no meio virtual
desenvolvido pela presidência da república e que também
contou com a contribuição dos alunos do LAPPIS, possui uma
série de patchs (ou merge requests enviados no contexto deste
trabalho, e de outros projetos do laboratório, e já incorporado
no núcleo do Noosfero.)
V. C ONCLUSÃO
Ao longo deste trabalho, realizamos atividades que passam pelas principais áreas de conhecimento da Engenharia
de Software, como a gerência de projetos, a gerência de
configuração de software, o levantamento e a elaboração de
requisitos, a análise e o design, a implementação, e aqui
incluímos a criação de testes automatizados, a manutenção
e a implantação de uma plataforma real de software livre,
dentre outras. Nos preocupamos em contribuir, na prática,
com a escrita de código, uma vez que, em nossa visão,
esta é a principal missão de um Engenheiro de Software.
Outra atividade realizada, e que julgamos ser de fundamental
importância para a continuidade deste trabalho, diz respeito
ao repasse do conhecimento adquirido para uma equipe de
alunos do curso de Engenharia de Software, que trabalhou
inicialmente no Portal da UnB Gama.
O fato deste trabalho ter sido desenvolvido dentro de uma
comunidade de software livre possibilitou que o aprendizado
fosse compartilhado entre os membros desta, permitindo que
houvesse discussões sobre as funcionalidades desenvolvidas
para que estas se adequassem melhor as necessidades dos
diversos ambientes Noosfero existentes, além de possibilitar
que haja um feedback em relação à qualidade do código
submetido.
Esta experiência nos proporcionou a possibilidade de participar de um processo distribuído de desenvolvimento de
software com outras equipes espalhadas pelo país e de fazer
parte de uma comunidade de software livre. Ao final deste
trabalho, julgamos que a rede Comunidade.UnB está bem
próxima da capacidade de ser lançada oficialmente para a
universidade.
R EFERÊNCIAS
[1] P. R. M. Meirelles, “Monitoramento de métricas de código-fonte em
projetos de software livre,” Thesis, 2013. [Online]. Available: http://www.
teses.usp.br/teses/disponiveis/45/45134/tde-27082013-090242/pt-br.php
[2] D. North, “Introducing BDD,” Better Software, 2006. [Online]. Available:
http://dannorth.net/introducing-bdd/bdd
10 http://fga.unb.br/tcc
11 https://gitlab.com/participa/noosfero/wikis/
CodeReview
114

FEES 2014 - Instituto de Computação

Transcrição

Documentos relacionados

Imprimir/PDF

Exposição do imóvel

Apresentação FETEC

GAME DA RESPONSABILIDADE SOCIAL FAMATH

Pacote de Golfe - Tryp Montijo Parque Hotel

// 109 MindGym: Jogos para Doentes com Alzeimer?

REGRAS Mortal Kombat X

These all are free copyrighted scripts. Demo specs: • mp3, 128Kbps

Cristiano Ronaldo eleito jogador do século do futebol português

Imprimir/PDF