Anais FEES Congresso Brasileiro de Software: Teoria e Prática 28 de setembro a 03 de outubro de 2014 Maceió/AL

Transcrição

1 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

2 Anais Volume 02 ISSN 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

3 PROCEEDINGS Volume 02 ISSN FEES 2014 VII Fórum de Educação em Engenharia de Software PROGRAM CHAIR Paulo Meirelles - Universidade de Brasília (UnB) CBSOFT 2014 GENERAL CHAIRS Baldoino Fonseca - Universidade Federal de Alagoas (UFAL) Leandro Dias da Silva - Universidade Federal de Alagoas (UFAL) Márcio Ribeiro - Universidade Federal de Alagoas (UFAL) 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

4 Autorizo a reprodução parcial ou total desta obra, para fins acadêmicos, desde que citada a fonte 4

5 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

6 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

7 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) Paulo Meirelles - 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

8 Comitê organizador / Organizing Committee COORDENAÇÃO GERAL Baldoino Fonseca - Universidade Federal de Alagoas (UFAL) Leandro Dias da Silva - Universidade Federal de Alagoas (UFAL) Márcio Ribeiro - Universidade Federal de Alagoas (UFAL) 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 Paulo Meirelles - Universidade de Brasília (UnB) 8

9 Í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 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 Gamebok: jogo educativo para o ensino-aprendizagem do PMBOK 5ª edição Fabricio Pinto, Marcos Paulo Correia Azevedo Avaliação por Meio de Questionários de um Curso Online para Engenharia de Software Lucas Garcia, Ingridy Martins, Luiz Ferreira, Eduardo Figueiredo Ambiente Integrado como Apoio ao Ensino da Engenharia de Software Simone Vasconcelos, Aline Vasconcelos 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 O uso do dojo na prática pedagógica do ensino de lógica de programação Fabio Rocha, Rosimeri Sabino, Josephine Esan Um Jogo Educacional para o Ensino de Metodologias Ágeis Giani Petri, Rogério Paulo Marcon Junior Formação de Equipes de Alto Desempenho para Desenvolvimento de Software Alessandra Dutra, Rafael Prikladnicki ARPostIts: Mobile Application for Agile Software Engineering using Augmented Reality Dhiana Deva Rocha, Thaiana Lima, Claudia Werner, Claudia Susie Rodrigues

10 Aprendendo Programação Concorrente em Java com o Objeto de Aprendizagem Quero Bolo Fagner Silva Martins e Ayla Dantas 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 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 Experiência no Projeto Framework de Soluções de TI Thatiany Lima de Sousa, Rejane Maria da Costa Figueiredo, Elaine Venson, Ricardo Ajax Koslovisk 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 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 Um estudos sobre métricas de produto e vulnerabilidades para tomada de decisões Arthur Del Esposte, Carlos Bezerra, Paulo Meirelles, Hilmer Neri A Platform Fed by Software Industry Problems to Learn Software Development Luiz Ferreira, Eduardo Figueiredo Um estudo sobre bibliotecas digitais no contexto da participação social Luiz Matos, Fernando Cruz, Paulo Meirelles Aspectos da Validação de Software em Metodologias Ágeis Aplicáveis à Terceirização do Desenvolvimento de Software Eduardo Pinto Barbosa, Elaine Venson

11 Mezuro, Evolução de Software Livre: Da Arquitetura à Experiência do Usuário Renan Costa, Vinícius Vieira, Paulo Meirelles Técnicas de usabilidade e testes automatizados em processos de desenvolvimento de software empírico Rodrigo Medeiros, Jônatas Medeiros, Paulo Meirelles O desenvolvimento do Novo Portal do Software Público Brasileiro Camila Ferreira, Aline Gonçalves, Marisa Santos, Paulo Meirelles, Hilmer Neri 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

12 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 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. Keywords Usability Evaluation; Software Quality; Serious Games; Heuristic Evaluation, Usability Inspection Methods 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. 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]. 12

13 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]. 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. 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. 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 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. 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. 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. 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

14 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 Concordância do sistema com o mundo real Controle e liberdade do usuário O sistema precisa manter os usuários informados sobre o que está acontecendo, fornecendo um feedback adequado dentro de um tempo razoável. 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 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 Locais da cidade não possuem nome, desta forma os habitantes não sabem onde estão. Os símbolos e palavras que são mostrados nas placas da cidade não fazem sentido. Há muitas ruas sem saída, o que dificulta a circulação dos veículos. Consistência e padrões Prevenção de erros Reconhecer ao invés de lembrar Flexibilidade e eficiência de uso Estética e design minimalista Ajudar os usuários a reconhecer, diagnosticar e corrigir erros Ajuda e documentação 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. É melhor que o sistema possua um design cuidadoso o qual previna o erro antes dele acontecer. 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. 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. 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. As mensagens de erro devem ser expressas em linguagem clara (sem códigos) indicando precisamente o problema e construtivamente sugerindo uma soluçã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. Há sinais de trânsito diferentes (fora do padrão) em vários locais da cidade, deixando os Users confusos. Quando há obras na cidade, nunca são colocados avisos para evitar acidentes. 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. Na cidade é preciso fazer caminhos muito longos para chegar a um local, a cidade não possui atalhos. Na cidade há nomes de locais muito detalhados sem necessidade. 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. 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

15 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]. 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. 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]. III. 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 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]. 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 Fig. 1. Tela de contextualização do jogo UsabiliCity. 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. 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 15

16 jogador deve selecionar as duas heurísticas adequadas que ajudam a identificar os problemas descritos na fase corrente (ver Fig. 3 - Elemento 2). 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 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. Fig. 3. Tela de uma das fases do jogo UsabiliCity.. Fig. 4. Processo de Seleção da Heurísticas do Jogo. 16

17 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 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. 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]. ao acrescentar estas questões foi permitir um melhor entendimento das respostas dos participantes em relação às categorias do modelo. 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 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

18 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. 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 Observações dos Monitores 01 Não ficou claro para os alunos como selecionar as respostas (indicar as heurísticas) nas fases. 02 Os alunos não percebiam que deviam ser escolhidas duas heurísticas por fase. 03 Para alguns alunos a fonte não era agradável. 04 Não era possível desmarcar uma heurística após ter sido selecionada, o aluno precisava reiniciar a fase. 05 A seleção da heurística com a cor vermelha assustou os alunos, estes pensavam que tinham cometido um erro. 06 Um aluno se divertiu ao ver boneco chorar quando perdia a fase. 07 Os alunos gostaram dos balões com informações sobre a heurística. 08 Alguns alunos acharam que a tela continha muita informação. 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 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. 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. 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? 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

19 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: É interessante para minha formação, pois trata de conhecimentos que uso na faculdade na matéria de IHC que estou estudando atualmente. Participante 15 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: 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 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 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: Só tem uma versão, já estou esperando as próximas. Participante 5 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: Deveria ter algo mais dinâmico, que deixasse a tela com mais movimento. Participante 31 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

20 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 No entanto, outros alunos gostaram, pois se sentiram estimulados a continuar jogando, como indica o comentário a seguir: 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 por alguns participantes reforçam os porcentuais obtidos: 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 melhorar os meus conhecimentos Participante 24 Fig. 9. Gráfico de Avaliação da categoria Aprendizagem. 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. 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

21 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. 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. 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. 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 /2014. REFERÊNCIAS [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 Alfabetização Infantil. Anais do Simpósio Brasileiro de Informática na Educação, [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, [3] Barbosa, S., Silva B.: Interação Humano-Computador, Rio de Janeiro: Elsevier, [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, [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 , [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, [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, [8] Keller, J.: Development and Use of the ARCS Model of motivational Design. Journal of Instructional Development, Volume 10, Issue 3, pp. 2 10, [9] Kirkpatrick, D.: Evaluating Training Programs - The Four Levels. Berrett- Koehler Publishers, pp. 289, [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, [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, [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, [13]Matera, M., Rizzo, F., Carughi, G. T.: Web Usability: Principles and Evaluation Methods. Mendes, E., Mosley, N. (eds), Web Engineering, [14]Monsalve, E., Werneck, V., Leite, J.: SimulES-W: Um Jogo para o Ensino de Engenharia de Software. Anais do FEES 2010/ CBSoft SBC, v.1. pp , [15]Nielsen, J.: Usability engineering. Morgan Kaufmann Pub, [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 [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, [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 , [19]Vargas, J., García-Mundo, L., Genero, M., Piattini, M.: A Systematic Mapping Study on Serious Game Quality, [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, [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

22 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 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. 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. 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]. 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 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]. 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. 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. 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. O restante deste artigo está organizado da seguinte forma: primeiramente, são apresentados os métodos de avaliação da 22

23 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. 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. 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. 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. Módulo principal Módulo Aspecto Social TABELA I. COMPONENTES DOS MÓDULOS DO GEQ. Módulo Componente Descrição Competência Percepção do jogador sobre sua habilidade e competência no jogo. Imersão sensorial Avalia o quanto o jogador se sentiu no jogo e imaginativa e se imaginou no jogo. Fluxo Percepção do jogador em relação ao curso e enredo do jogo. Tensão / Avalia se o jogo causou tensão ou Aborrecimento aborrecimento no jogador. Desafio Percepção do jogador em relação aos desafios apresentados no jogo. Afeição negativa Avalia se o jogo causou antipatia no jogador. Afeição positiva Avalia se o jogo causou simpatia no jogador. Envolvimento Avalia se o jogo leva os jogadores a psicológico compartilharem sentimentos e afinidades empatia durante o jogo. Módulo pós game Envolvimento psicológico - sentimentos negativos Envolvimento comportamental Experiência positiva Experiência negativa Cansaço Retorno realidade à 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. 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. Heurística (H1) Testa franzida (H2) Levantar as sobrancelhas DESCRIÇÃO DAS HEURÍSTICAS DA EMOÇÃO. 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. 23

24 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 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. FEES 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. 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. III. 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. 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. 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 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: 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. 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

25 pontuação dos demais jogadores sob o cenário "Hall da Fama", que exibe os melhores resultados e os nomes dos jogadores. 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]. 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 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?" "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?" "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. 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 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. 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). A TABELA III. apresenta os resultados obtidos para cada afirmativa do módulo principal do GEQ separados por componentes. TABELA III. RESULTADOS QUANTITATIVOS DO MÓDULO PRINCIPAL. Componente Competência (%) (%) (%) (%) (%) 2. Eu me senti habilidoso Eu me senti competente Eu fui bem no jogo Eu me senti bem sucedido Eu atingi as metas do jogo de forma rápida Componente Imersão Sensorial e Imaginativa 0 (%) 1 (%) 2 (%) 3 (%) 4 (%) 3. Eu estava interessado na história do jogo Foi esteticamente agradável Eu me senti criativo Eu senti que podia explorar coisas Eu achei impressionante Pareceu uma rica experiência Componente Fluxo 0 (%) 1 (%) 2 (%) 3 (%) 4 (%) 5. Eu estava completamente ocupado com o jogo Eu esqueci de tudo ao meu redor Eu perdi a noção do tempo Eu fiquei profundamente concentrado no jogo 31. Eu me desconectei do mundo exterior Componente Tensão/Aborrecimento (%) (%) (%) (%) (%) 22. Eu me senti aborrecido Eu me senti irritado Eu me senti frustrado

26 Componente Desafio (%) (%) (%) (%) (%) 11. Eu achei o jogo difícil Eu me senti pressionado Eu me senti desafiado Eu senti a pressão do tempo Eu tive que me esforçar bastante Componente Afeição Negativa (%) (%) (%) (%) (%) 7. O jogo me deixou de mau humor Eu pensei em outras coisas durante o jogo Eu achei o jogo cansativo Eu me senti entediado Componente Afeição Positiva (%) (%) (%) (%) (%) 1. Eu me senti contente Eu achei o jogo divertido Eu me senti feliz Eu me senti bem Eu me diverti 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. 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. TABELA IV. RESULTADO QUANTITATIVOS DO MÓDULO PÓS GAME. Componente Experiência Positiva (%) (%) (%) (%) (%) 1. Eu me senti renovado Eu me senti vitorioso Eu me senti estimulado Eu me senti satisfeito Eu me senti poderoso Eu me senti orgulhoso Componente Experiência Negativa (%) (%) (%) (%) 2. Eu me senti mal Eu me senti culpado Eu achei um desperdício de 4 (%) tempo Eu acho que poderia ter feito coisas mais úteis Eu fiquei arrependido Eu fiquei envergonhado Componente Cansaço (%) (%) (%) (%) (%) 10. Eu me senti exausto Eu me senti cansado.* Componente Retorno à Realidade (%) (%) (%) (%) (%) 3. Eu achei difícil voltar à realidade Eu me senti desorientado Eu tive a sensação de ter retornado de uma viagem. *Durante a tradução do questionário, a afirmativa 13 não foi inserida por uma falha na preparação do questionário. 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

27 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

28 Fig. 7. Resultados quantitativos para o componente Desafio. A Fig. 8 ilustra os resultados quantitativos obtidos para o 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. A Fig. 9 ilustra os resultados quantitativos obtidos para o 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

29 A Fig. 10 ilustra os resultados quantitativos obtidos para o 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. A Fig. 11 ilustra os resultados quantitativos obtidos para o 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. 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. Analisando a TABELA V. e relacionando os pontos a alguns componentes do GEQ, é possível identificar os pontos fortes PFT03, PFT08 e PFT09 relacionados ao componente Competência, pois abordam aspectos que afetam a habilidade do participante no jogo. TABELA V. PONTOS FORTES DO JOGO DO PONTO DE VISTA DOS PARTICIPANTES. Ponto Forte PFT01 PFT02 PFT03 PFT04 PFT05 PFT06 PFT07 PFT08 PFT09 PFT10 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. 29

30 O jogo não é entediante, dá vontade de ser aprofundar PFT11 mais no jogo. PFT12 Os desafios do jogo são bem elaborados. 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. 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. 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. PONTOS FRACOS DO JOGO DO PONTO DE VISTA DOS PARTICIPANTES. Ponto Fraco Descrição PFC01 As dicas do jogo poderiam ser mais explicadas. PFC02 As perguntas do jogo são complexas. PFC03 O jogo é cansativo. PFC04 O jogo é difícil. PFC05 O jogo precisa de conexão com a internet. PFC06 O jogo poderia ter mais opções de perguntas. PFC07 O jogo possui poucos artefatos a serem analisados. PFC08 A quantidade de chances para acertar uma questão é ilimitada. PFC09 O jogo poderia apresentar um resultado final para o jogador, mostrando seus pontos fracos no jogo. PFC10 A forma de obtenção da pontuação do jogo não está clara. PFC11 As perguntas não estavam bem explicadas. PFC12 Algumas telas do jogo eram muito coloridas. PFC13 O jogo poderia ser mais divertido. PFC14 O jogo apresentava muitas telas com texto. 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. 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. 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 desafio, sem sucesso. O ponto PFC05 não pôde ser associado a nenhum componente. 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. TABELA VII. ANÁLISE DA OCORRÊNCIA DAS HEURÍSTICAS DA EMOÇÃO. Heurística Número de participantes H1. Testa franzida 11 H2. Levantar as sobrancelhas 10 H3. Olhar à distância 9 H4. Sorrir 3 H5. Comprimir os lábios 11 H6. Mexer a boca 11 H7. Expressão vocal 12 H8. Mão tocando a face 16 H9. Ir para trás na cadeira 14 H10. Inclinar para frente o tronco 16 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. TABELA VIII. RESULTADO GERAL DO MÉTODO HEURÍSTICAS DA EMOÇÃO. Experiência Positiva Experiência Avaliação Final Negativa 27% 73% 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. 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. 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. 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

31 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. 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. 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. CONCLUSÕES E TRABALHOS FUTUROS 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. 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. Agradecimentos As autoras agradecem o apoio financeiro da FAPEAM através do Edital N 016/2013 PROTI PESQUISA, processo N o /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 [1] 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, [2] 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é. [3] Ritterfeld, U., Cody, M., and Vorderer, P. Serious Games: Mechanisms and Effects. Routledge, London, [4] Zyda, M. From Visual Simulation to Virtual Reality to Games. Computer, 38 (9), [5] 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), [6] 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, [7] 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. [8] 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, [9] 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 [10] 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 [11] IJsselsteijn, W.A., de Kort, Y.A.W. & Poels, K. Game Experience Questionnaire - The English version. [12] 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, [13] 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, [14] 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, [15] 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

32 Gamebok: jogo educativo para o ensinoaprendizagem do pmbok 5ª edição Marcos Paulo Correia Azevedo Colegiado de Sistemas de Informação Faculdade de Tecnologia e Ciências (FTC) Vitória da Conquista-BA, Brasil marcos.azevedo@izap.com.br Fabrício de Sousa Pinto Colegiado de Sistemas de Informação Faculdade de Tecnologia e Ciências (FTC) Vitória da Conquista-BA, Brasil fabbricio7@yahoo.com.br 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. 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. 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 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. 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. 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ª. 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

33 na seção 6 é apresentado os trabalhos relacionados. Por fim, na seção 7 as considerações finais. II PMBOK 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. 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]. 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]. 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]. 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]. 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]. 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]. 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]. 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. 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. 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. 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

34 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. Figura 01: Principais elementos de um 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 Esta possui seis capacitações, conforme ilustrado na Figura 02. Figura 02: Taxonomia revisada de Bloom Fonte: adaptado de [4] V DESENVOLVIMENTO DO JOGO GAMEBOK 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. 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: A versão final do jogo também pode ser acessada de forma livre através do link: 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. 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

35 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. FEES 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. 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 05: Planejamento Figura 06: Aprendizado do jogador, através dos processos do PMBOK. 35

36 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. FEES 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 Figura 08: Quebra-Cabeça camuflando tatuagem 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. 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. Os dezoito estudantes da disciplina Engenharia de Software responderam o questionário disponibilizado por [5]. As respostas destes foram avaliadas da seguinte forma: 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

37 Conceitos: Para essa avaliação o estudante teve suas respostas avaliadas no que ele sabia antes e depois de ter jogado o GameBOK. 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. 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. 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. 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. 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. Quando questionados sobre a experiência que o jogo contribuiu para o desempenho na vida profissional 37,5% dos Figura 12: Gráfico Experiência do Usuário 37

38 Figura 14: Gráfico objetivos da aprendizagem Figura 13: Gráfico de Aprendizagem 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. 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; Aplicar na prática: O discente analisou os conceitos quanto à sua aplicação na disciplina e/ou vida profissional. Como é mostrado na Figura 14, vê-se a suma importância da aplicação de jogos de ensino-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. 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 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]. 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

39 qual quer jogar. Desenvolvido para navegadores com suporte à arquivos Flash, o jogo se torna ultrapassado, pois está tecnologia sendo substituída pelo atual HTML5. 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 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. 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. Quadro 01: Comparação entre os jogos encontrados e o GameBOK. Característica GameBOK Puzzle PMBOK Jogo de processos da Rita PMBOX Tetris I Baseado na WEB Sim Sim Sim 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 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. 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. 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 EUA. Disponível em: < df> [3] TAROUCO, L. et al. Jogos Educacionais. Novas tecnologias na educação, Rio Grande do Sul, CINTED-UFRGS, [3] BOTELHO, Luiz (2004). Jogos educacionais aplicados ao e-learning. Disponível em: < Acessado em: janeiro de [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. [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. [6] GUINTER, Marco (2014). Jogo de processos da Rita (versão estendida) v1.0. Disponível em < Acesso em: 07 mar [7] KPO, Consulting and Educational Services (2014). PUZZLE PMBOK. Disponível em < Acesso em: 03 mar [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 < Acesso em: 10 mar [10] AFRIDI, Samir. Rita s Process Game [UNOFFICIAL] v1.2. Disponível em < Acesso em: 07 mar Taxonomia Bloom de Lembrar, Aplicar, Enteder Analisar e Lembrar Lembrar Lembrar 39

40 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, 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. 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]. 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. 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. 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

41 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ória 1 de 43 alunos que fizeram o curso em dois semestres consecutivos (2013-II e 2014-I). 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. 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. 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. 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. 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 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). 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. TABELA I. CONTEÚDO E CORRESPONDÊNCIA DOS QUESTIONÁRIOS Artigo Descrição 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 41

42 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. 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 Vídeo Conteúdo abordado I 1 Apresentação do Curso 2 Introdução a Engenharia de Software 3 Desenvolvimento e Evolução de Software II 4 Atividades Comuns de Desenvolvimento de Software 5 Processos de Software 6 Processos de Software que Lidam com Mudanças III 7 Desenvolvimento Ágil de Software 8 Programação Extrema (XP) 9 Scrum IV 10 Requisitos de Usuários e Requisitos do Sistema 11 Requisitos Funcionais e Requisitos Não Funcionais 12 Processos de Engenharia de Requisitos V 13 Introdução a UML 14 Diagramas de Casos de Uso VI 15 Arquitetura de Software 16 Padrões Arquiteturais VII 17 Modelagem de Software Orientada a Objetos 18 Diagrama de Classes VIII 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 IX 23 Programação Orientada a Objectos 24 Idiomas de Programação X 25 Verificação e Validação de Software 26 Inspeção de Software 27 Testes de Software XI 28 Evolução de Software 29 Refatoração e Reengenharia XII 30 Reutilização de Software 31 Técnicas de Reutilização de Software 32 Linha de Produtos de Software XIII 33 Engenharia de Software baseada em Componentes 34 Processos de Desenvolvimento de Componentes 35 Composição de Componentes XIV 36 Separação de Interesses 37 Desenvolvimentos de Software Orientado a Aspectos 38 A Linguagem AspectJ XV 39 Qualidade de Software 40 Medição e Modelos de Qualidade 41 Métricas de Produtos de Software XVI 42 Melhoria de Processos de Software 43 Os Modelos CMM e CMMI 44 O Modelo Brasileiro MPS.Br 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. 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. 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 Analytics 2. 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 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

43 Fig. 2. Estatística de visualização de páginas do curso online de janeiro a junho de 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. 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 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. 3. Número de novos estudantes 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 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. 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. 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 43

44 respostas para os questionários, pois as mesmas não são individualmente disponibilizadas aos instrutores. 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. 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. TABELA III. QUESTÕES COM MAIOR ÍNDICE DE ERRO DAS TURMAS A E B Turma A Turma B Quest. Questão % de Erro Questão % de Erro ,71% 6 44,44% % 1 61,11% ,67% 7 66,67% 4 1 e 4 26,67% 4 e 5 28,57% 5 2 e 3 23,53% 5 23,08% ,29% 5 42,86% ,76% 6 e 9 21,43% % 8 35,71% 9 1 e 3 40% 3 e 5 15,38% 10 2 e 9 14,29% 9 35,71% Turma A (2013-II) Fig. 5. Desempenho médio geral da turmas avaliadas. Turma B (2014-I) 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 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. 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. 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 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. 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]. 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. 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

45 disponibiliza meios para o estudo de cada aluno individualmente, como é feito nesse estudo. Fig. 6. Turma A: % de vídeos assistidos vs. Desempenho nos questionários 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. 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. 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. 8. Turma A: Frequência vs. Desempenho nos questionários 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

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

47 V. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 47

48 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. 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. 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. AGRADECIMENTOS Este trabalho recebeu recursos financeiros da Universidade Federal de Minas Gerais por meio da PROGRAD (Processo PIQEG ), do CNPq (Processo /2013-5) e da FAPEMIG (Processos APQ e PPM ). REFERÊNCIAS [1] Open Software Engineering Course. Acessado em 08/07/2014: [2] N. Ahmadi, M. Jazayeri. Analyzing the Learning Process in Online Educational Game Design: A Case Study. In 23rd Australian Software Engineering Conference (ASWEC), pp , [3] S. Apel, D. Batory, C. Kastner, G. Saake. Feature-Oriented Software Product Lines: Concepts and Implementation. Springer; [4] 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, [5] K. Beck and C. Andres. Extreme Programming Explained: Embrace Change, 2nd Edition. Addison-Wesley, [6] B. Boehm. A Spiral Model of Software Development and Enhancement, IEEE Computer, 21(5), 61-72, [7] G. Booch, J. Rumbaugh, I. Jacobson. The Unified Modeling Language User Guide, 2 edition. Addison Wesley, [8] J. C. Braga. Diretrizes para o Ensino interdisciplinar de Engenharia de Software. Fórum de Educação em Enge. de Software (FEES), [9] Coursera. Acessado em 08/07/2014: [10] 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 , [11] E. B. Derwin. Critical Thinking in Online vs. Face-to-Face Higher Education. ProQuest, [12] edx. Accessed in 08/07/2014: [13] 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 , [14] 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, [15] A. Fox and D. Patterson. Crossing the Software Education Chasm. Communications of the ACM, 55(5), 44 49, [16] E. Gamma, R. Helm, R. Johnson, J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading, [17] R. Jain. The Art of Computer System Performance Analysis: Techniques for Experimental Design, Measurement, Simulation and Modeling. Wiley and Sons [18] T. R. Liyanagunawardena, A. A. Adams, and S. A. Williams. MOOCs: A Systematic Study of the Published Literature The International Review of Research in Open and Distance Learning, [19] K. Masters. A Brief Guide to Understanding MOOCs. The Internet Journal of Medical Education, 1(2), [20] 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, [21] N. Papaspyrou, S. Retalis, S. Efremidis, G. Barlas, E. Skordalakis. Web-based Teaching in Software Engineering. Advances in Engineering Software, 30(12), , [22] 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), [23] 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, [24] 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), [25] Software as a Service (SaaS). Acessado em 08/07/2014: [26] I. Sommerville. Software Engineering, 9 edition. Pearson, [27] 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 , [28] Udacity. Acessado em 08/07/2014: [29] Udemy. Acessado em 08/07/2014: [30] 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 , [31] 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), [32] C. Wohlin, P. Runeson, M. Host, M. C. Ohlsson, B. Regnell, A. Wesslen. Experimentation in Software Engineering, 2nd edition. Springer,

49 ANEXO I TELA PRINCIPAL DO CURSO ONLINE DE ENGENHARIA DE SOFTWARE 49

50 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 Aline Pires Vieira de Vasconcelos Instituto Federal Fluminense (IFFluminense) Núcleo de Engenharia de Software (NES) Rio de Janeiro/Brasil 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. 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 de 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. 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 50

51 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 efetiva bastante 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. 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. 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. 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. 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 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]. 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]. 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]. 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]. III. O AMBIENTE INTEGRADO 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

52 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. 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 e Metodologias Ágeis [40]. 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 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]; 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 52

53 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. 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]: 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. IV. FERRAMENTAS DO AMBIENTE INTEGRADO NO AUXÍLIO AO PROCESSO DE ENSINO- APRENDIZAGEM 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. 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. 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: 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); 53

54 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. 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. 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 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 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 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 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: 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; 54

55 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. 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. 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 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: 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: 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 55

56 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] 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. [2] Drappa, A., Ludewig, J. (2000) Simulation in Software Engineering Training in Proceedings of the 22nd International Conference on Software Engineering. ACM. [3] 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. [4] Baker, A., Navarro, E. e Hoek, A. (2006) An Experimental Card Game for TeachingSoftware Engineering Processes. Journal of Systems and Software. [5] 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. [6] 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. [7] 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. [8] 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. [9] Paiva, S. R. (2011) Uma Revisão Sistemática das Pesquisas Realizadas sobre a Melhoria no Ensino de Engenharia de Software. 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 Simulation- Based 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. 56

57 [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 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 [35] SOFTEX - Associação Para Promoção da Excelência do Software Brasileiro (2012) MPS.Br Guia Geral: Disponível em 2.pdf. [36] Redmine (2014). Redmine. Disponível em [37] ABPM Brasil (2013) BPM CBOK V3.0: Guia para o Gerenciamento de Processos de Negócio - Corpo Comum de Conhecimento - 2ª edição [38] PMI - Project Management Institute (2013) A Guide to the Project Management Body of Knowledge PMBOK. 5º Edição. EUA, [39] Finocchio Junior, J. (2013) Project Model Canvas. Ed.Campus [40] Sabbagh, R. (2012) Scrum: Gestão Ágil para Projetos de Sucesso. Editora Casa do Código, [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 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 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,

58 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 frchico@gmail.com 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. INTRODUÇÃ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]. 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]. 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]. Portanto, realizar a detecção de códigos clonados em avaliações/exercícios de estudantes de programação, fazendo 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]. 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. 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. II. TRABALHOS RELACIONADOS 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). 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 58

59 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. 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. 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. A FERRAMENTA dccp A dccp 2 (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 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. 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. 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. 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 59

60 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. Arquitetura da dccp. 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. 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. 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. 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 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. 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. 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. A. Objetivo IV. ESTUDO DE CASO 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. B. Seleção de participantes e objetos Foram realizadas parcerias com professores do curso de Licenciatura em Informática da Universidade Tiradentes - 60

61 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. C. Instrumentação 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. D. Operação 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]. 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). 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) 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. 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, 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. V. CONCLUSÃO E TRABALHOS FUTUROS 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. 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. 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). REFERÊNCIAS [1] E. Borges, Um estudo sobre abordagens e ferramentas de detecção de clones de software, [2] 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 [3] C. Roy and J. Cordy, A survey on software clone detection research, Queen s School of Computing TR, vol. 541, p. 115, [4] 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 [5] 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, [6] E. W. Dijkstra, On the cruelty of really teaching computing science, Communications of the ACM, vol. 32, no. 12, pp , [7] 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 [8] 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, [9] 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 [10] 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

62 O uso do dojo na prática pedagógica do ensino de lógica de programação Prof. Fabio Gomes Rocha(59633) Computação GPITIC - UNIT Aracaju/SE - Brasil fabio_gomes@unit.br Prof. Josephine Esan(154344) Mapple Bear Aracaju/SE Brasil josephine_esan@hotmail.com Profa. Rosimeri Ferraz Sabino(154343) CCSA UFS Doutoranda em Educação - UFS Aracaju/SE - Brasil rf.sabino@gmail.com 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. 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 n o 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 n o 3, de 9 de julho de 2008 [5] Uma segunda versão daquele documento norteador ocorreu 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 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]. 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 62

63 aprender a desenvolver o raciocínio lógico para a resolução de problemas. 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. 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 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 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: Tabela 1 Distribuição das turmas e sexo dos alunos Turno Homens Mulheres Total Manhã Tarde Total Fonte: Elaborado pelos autores. 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. 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. 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. III. A ABORDAGEM CONCEITUAL SOBRE A PRÁTICA 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 63

64 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. 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] 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 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. REFERÊNCIAS BIBLIOGRÁFICAS [1] APOIE. CodingDojo. Disponível em < Acesso em: 15 mai [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, Disponível em < pdf>. Acesso em: 15 mai [3] BIGGE, Morris L. Teorias da aprendizagem para professores. São Paulo: Pedagógica e Universitária, [4] BRASIL. Resolução Conselho Nacional de Educação no 4, de 8 de dezembro de Diário Oficial [da] União, Poder Executivo, Brasília, DF, 22 dez Seção 1, p [5] BRASIL. Resolução Conselho Nacional de Educação no 3, de 9 de julho de Diário Oficial [da] União, Poder Executivo, Brasília, DF, 10 jul Seção 1, p. 9. [6] BRASIL. Programa Nacional de Acesso ao Ensino Técnico e Emprego. Institucional. Disponível em: < Acesso em: 10 dez. 2012(a). [7] BRASIL. Resolução Conselho Nacional de Educação no 4, de 6 de junho de 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: < 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 ( ). Rio de Janeiro: SBC,

65 [10] CODING DOJO. Treinamento para programadores utilizando TDD: Desenvolvimento Orientado a Testes. Disponível: < Acesso em: 11 nov [11] DEWEY, John. Experiência y Educación. Buenos Aires: Editorial Losada, [12] GAMEZ, Luciano. Psicologia da educação. Rio de Janeiro: LTC, [13] KENSKI. Vani Moreira. Educação e Tecnologias: O novo ativo da informação. Campinas: Papirus, [14] MANZANO, José Augusto N. G.; OLIVEIRA, Jair Figueiredo. Algoritmos: lógica para desenvolvimento de programação. São Paulo: Érica, [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, [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, [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, p [19] PRENSKY, Marc. Aprendizagem baseada em jogos digitais. São Paulo: Senac, [20] SEBESTA, Robert W. Conceitos de linguagem de programação. 9. ed. Porto Alegre: Bookman, [21] SCRATCH. Massachusettes Institute of Technology (MIT). Scratch. Disponível em: <scratch.mit.edu>. Acesso em: 15 nov [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 f. Dissertação (Mestrado em Educação) Universidade Federal Fluminense, Niterói, [23] VASCONCELOS, Maria José Esteves. Pensamento sistêmico: o novo paradigma da ciência. 10. ed. Campinas: Papirus, [24] YIN, Robert.K. Estudo de caso: planejamento e métodos. 3. ed. Porto Alegre: Bookman,

66 Um Jogo Educacional para o Ensino de Metodologias Ágeis Giani Petri Universidade Federal de Santa Maria (UFSM) Caixa Postal 54, Frederico Westphalen - RS gpetri@inf.ufsm.br Rogério Paulo Marcon Júnior Universidade Federal de Santa Maria (UFSM) Caixa Postal 54, Frederico Westphalen - RS rpjunior 1@hotmail.com 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. INTRODUÇÃO A efetivação do processo de ensino aprendizagem das disciplinas relacionadas à Engenharia de Software, em especial as competências de Metologias Ágeis, são fundamentais para a formação de profissionais que irão trabalhar na área de desenvolvimento de sistemas. No entanto, o grande número de conceitos e teorias envolvidas nestas disciplinas, muitas vezes, tornam os momentos pedagógicos insatisfatórios para potencializar o aprendizado dos discentes. Neste contexto, Reif e Mitri (2005) destacam que o aprendizado dessas disciplinas não possui o mesmo efeito se o aluno não tiver uma vivência prática com o conteúdo, por mais simples que seja [1]. Assim, surge a necessidade de explorar os diversos recursos educacionais existentes atualmente e que estão disponíveis aos professores, para serem inseridos nos momentos pedagógicos, fazendo com que o paradigma de ensino utilizado construa um ambiente de aprendizagem divertido e motivador, e que os conteúdos teorizados possam ser inseridos em atividades lúdicas e que estimulem a participação dos alunos. Um dos recursos educacionais à disposição dos docentes atualmente são os jogos educacionais. Os jogos educacionais vêm contribuindo para as aprendizagens em diversas áreas de conhecimento, de modo a produzir um ambiente de integração e interação entre alunos e professores. Diversos jogos educacionais foram desenvolvidos para potencializar o processo de ensino aprendizado dos conteúdos relacionados à Engenharia de Software [3]. No entanto, jogos educacionais não computadorizados específicos para trabalhar com os conceitos envolvidos nas Metodologias Ágeis ainda são pouco explorados. Desta forma, o objetivo deste trabalho é inserir o Agile Ball Point Game [4], uma técnica consolidada utilizada em treinamentos empresariais e certificações em Metodologias Ágeis, como um jogo educacional no ambiente acadêmico, proporcionando uma experiência prática aos educandos, trabalhando em uma grande equipe integrada, estimulando e vivenciando os conceitos importantes para a formação profissional dos discentes na competência de Metodologias Ágeis. 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 prática os conceitos previamente teorizados em sala de aula. Em uma análise inicial dos resultados do experimento, obtidos através de um questionário, fatores como a necessidade de replanejamento, reorganização, comunicação, readaptação e a capacidade de liderança foram os itens identificados como essenciais para alcançar os objetivos do jogo, estando estes itens fortemente relacionados às habilidades individuais e de grupo envolvidas na competência de Metodologias Ágeis. II. A. Jogos Educacionais FUNDAMENTAÇÃO TEÓRICA De modo a contribuir para a efetivação do processo de ensino aprendizagem e potencializar as experiências práticas dos discentes, cada vez mais os profissionais de educação estão buscando metodologias alternativas para inserirem no contexto acadêmico [5]. Um dos recursos educacionais à disposição dos docentes são os jogos educativos. Este tipo de recurso contribui na aprendizagem dos alunos, potencializando a experimentação e visualização de conceitos na prática, além de criar ambientes que despertem a criatividade e o interesse dos alunos [2]. Um jogo educacional é qualquer atividade de formato instrucional ou que estimule a aprendizagem, que envolva competição e seja organizada por regras e restrições para alcançar um determinado objetivo [6]. Dentre os principais benefícios dos jogos educacionais estão: (a) permitem conectar de forma divertida o aluno ao conhecimento [5]; (b) auxiliam o desenvolvimento de pensamentos complexos [7]; (c) é uma forma de aplicar na prática os conceitos [8] e; (d) promovem o desenvolvimento de habilidades cognitivas [5]. Os jogos educativos podem ser classificados de diversas formas, uma das classificações é em jogos digitais (computadorizados) e jogos não digitais (não computadorizados). Um jogo educacional digital objetiva aliar o aprendizado com a diversão e são caracterizados por serem jogados através de um dispositivo virtual (computador, tablet, etc.) e por oferecerem um ambiente interativo [9]. Por outro lado, um jogo não digital 66

67 (não computadorizado) caracteriza-se por explorar a interação entre um grupo de jogadores não individualizados, proporcionando um momento lúdico e potencializando o convívio, a comunicação e a integração sem explorar o uso de recursos digitais. Por estes motivos, este trabalho objetiva abordar um jogo educacional não computadorizado, mas que também atua como objeto dinâmico e de integração, estimulando a aprendizagem dos envolvidos. B. Metodologias Ágeis Insatisfeitos com o uso de técnicas tradicionais e pesadas para o desenvolvimento de softwares, Kent Beck e outros dezesseis desenvolvedores, assinaram um documento chamado de Manifesto para o Desenvolvimento Ágil de Software [10]. O documento foi criado a partir das experiências pessoais do grupo de desenvolvedores que valorizavam em especial os seguintes aspectos: (a) os indivíduos e interações acima de processos e ferramentas; (b) software operacional acima de documentação completa; (c) colaboração dos clientes acima de negociação contratual e; (d) respostas as mudanças acima de seguir um plano [10]. Estes aspectos abordados no Manifesto Ágil contribuíram para sanar as dificuldades encontradas na engenharia de software convencional e potencializar o desenvolvimento de softwares em um ambiente dinâmico com muitas mudanças, conflitos e requisitos incertos. Uma das principais características das Metodologias Ágeis é que os engenheiros de software e outros envolvidos no projeto (clientes, usuários, gerentes) trabalham de forma integrada em uma equipe ágil, que se auto-organiza, controla suas atividades e acelera a comunicação entre todos os membros da equipe, objetivando resolver conflitos e responder as mudanças no menor tempo possível. III. METODOLOGIA A metodologia utilizada para o desenvolvimento do trabalho iniciou com uma pesquisa bibliográfica com o objetivo de investigar jogos empresariais utilizados em treinamentos e certificações e que estivessem relacionados a competência de metodologias ágeis. As características de trabalhar em uma grande equipe, envolvendo os conceitos de reorganização do processo e principalmente a comunicação foram os fatores motivadores para a escolha do Agile Ball Point Game. A sequência metodológica constituiu-se no estudo das regras do jogo e preparação do experimento. O experimento com a aplicação do jogo contou com uma amostra de 31 alunos do Curso Técnico em Informática concomitante ao ensino médio do Colégio Agrícola de Frederico Westphalen, uma das unidades da Universidade Federal de Santa Maria. Antes de executar o experimento, os alunos tiveram uma explicação geral sobre o Processo de Desenvolvimento de Sistemas e uma breve comparação entre os modelos de processo tradicionais e as metodologias ágeis. Na sequência, os alunos da amostra foram instruídos com as regras do jogo, onde o experimento foi executado sob coordenação (sem intervenção) de um professor. Durante o experimento a re/organização e comunicação do grupo foi registrada através de filmagens e fotos (previamente acordado com os alunos). Ao final do experimento a amostra de alunos respondeu um questionário com perguntas abertas envolvendo os conceitos trabalhados para elencar as contribuições do jogo educativo para a aprendizagem de cada membro da equipe. IV. O AGILE BALL POINT GAME Desenvolvido por Bóris Gloger em meados dos anos 2006, o Agile Ball Point Game [4] é uma metodologia destinada à tomada de decisões e estimativas, onde os próprios participantes deverão organizar o grupo que estará participando. O Agile Ball Point Game foi inicialmente utilizado no evento Certified Scrum Master Training e é utilizado até hoje em vários treinamentos e certificações em Metodologias Ágeis, especialmente sobre o Scrum. O jogo possui poucas regras e todos os envolvidos são organizados em um único e grande time. O objetivo do jogo é 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 terá dois minutos para se organizar da maneira que achar melhor, logo em seguida deverá dar uma estimativa de quantos pontos conseguirão realizar na iteraçã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 não devem ser passada entre os companheiros que estão diretamente ao lado (vizinhos da esquerda e direita). Ao todo, o jogo tem cinco iterações de dois minutos cada uma. Terminada a iteração, os participantes terão mais um minuto para se reorganizar e apresentar uma estimativa, fazendo as alterações necessárias para a próxima iteração, isso se repete nas cinco iterações. V. EXPERIMENTO E DISCUSSÃO DOS RESULTADOS PRELIMINARES Para dar início ao experimento, os alunos foram instruídos com as regras do jogo (conforme apresentado na Seçã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 iteração. Durante este tempo de organização inicial do grupo, já se observou a capacidade de lideranç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 iteração. No entanto, alguns alunos ainda estavam dispersos e não ouviram as ideias dos colegas o que dificultou, e de alguma forma, comprometeu a equipe durante a iteração. Para a iteração inicial a equipe estimou 5 pontos. Na primeira iteraçã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, até a bola chegar novamente no aluno que iniciou e então marcar um ponto. A Figura 1 apresenta a organização do processo durante a primeira iteração. Ao longo da primeira iteração os alunos tiveram algumas dificuldades. A principal delas foi a falta de atenção da equipe, muitas bolas foram ao chão, fazendo com que o processo iniciasse novamente, além disso, como alguns membros da equipe estavam dispersos durante o tempo de organização inicial, os mesmos tiveram dificuldades em aderir ao processo 67

68 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

69 com o passar do tempo (iteração) a equipe foi se adaptando ao processo e melhorando o seu ritmo e consequentemente alcanç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 não consegue controlar tudo. Outro fragmento de uma resposta enfatiza a cooperação do grupo na construção de ideias, em grupo podemos entender e ajudar a elaborar ideias, que talvez sozinhos não iríamos conseguir. Desta forma, podemos observar que o jogo educativo contribui no aprendizado de diversos aspectos envolvidos na atividade e que estão fortemente relacionados aos principais conceitos envolvidos nas metodologias ágeis, com ênfase especial à comunicação, autoorganização e capacidade de trabalhar em grupo. VI. TRABALHOS RELACIONADOS Na área de Engenharia de Software diversos jogos educacionais, apoiados ou não por computadores, vêm sendo utilizados para contribuir no processo de ensino aprendizagem. Para melhor compreensão dos trabalhos relacionados encontrados na literatura, que apresentam e abordam jogos educacionais específico para o ensino de Metodologias Ágeis, a Tabela I apresenta uma breve comparação entre os trabalhos encontrados. A tabela destaca o nome do jogo seguido de sua referência, uma classificação do jogo quando ao seu tipo e uma síntese dos objetivos. Tabela I. REVISÃO DE JOGOS EDUCACIONAIS PARA O ENSINO DE METODOLOGIAS ÁGEIS Jogo Tipo do Jogo Objetivos Scrum Game [11] Jogo de Tabuleiro Cumprir determinadas tarefas de uma Sprint onde o tempo do projeto é gerenciado conforme a posição do participante no tabuleiro. Scrumming [12] Lego for Scrum [13] Playing Scrum [14] Scrumia [15] Jogo Digital Jogo de LEGO Jogo Digital Jogo não digital Apoiar o ensino de práticas do Scrum através da definição e simulação de Sprints para o gerenciamento de projetos. Simular o processo de desenvolvimento com Scrum, criando objetos com LEGO a partir de histórias de usuário. Ensinar de forma prática o Scrum explorando os papéis, reuniões e a execução de mais de uma Sprint. Planejar e executar uma Sprint em um projeto simulado. Em comparação aos trabalhos encontrados na literatura o Agile Ball Point Game destaca-se por ser um jogo não computadorizado e por criar uma interação maior entre os participantes, integrando todos os envolvidos em um grande time, potencializando o trabalho em grupo e colocando em prática as habilidades individuais e de grupo, tais como: comunicação, autoorganização, readaptação de processos, adaptação a mudanças e resolução de conflitos, conceitos estes que são de extrema importância para o aprendizado de Metodologias Ágeis. VII. CONCLUSÕES A utilização de jogos educacionais, que visam explorar a prática de conteúdos, construindo um ambiente de aprendizagem lúdico e que desperte o interesse dos educandos, é uma técnica que deve ser seguida pelos docentes que trabalham com as disciplinas de Engenharia de Software, incluindo as Metodologias Ágeis. Desta forma, este trabalho apresentou a inserção de um jogo utilizado em treinamentos e certificações em Metodologias Ágeis como um jogo educativo em um ambiente acadêmico, potencializando o aprendizado dos conteúdos relacionados à competência. Com base nos resultados preliminares obtidos no experimento conclui-se que a inserção do Agile Ball Point Game foi estratégica para potencializar o processo de ensino aprendizagem da amostra de alunos. Os mesmos, ao formarem um grande time, vivenciaram na prática a realidade dos conceitos e habilidades envolvidas nas Metodologias Ágeis. Exercitando assim, a importância do trabalho em grupo, dando ênfase na comunicação, liderança, comprometimento e especialmente na capacidade de se auto-organizar, adaptar as mudanças e resolver conflitos. Como trabalho futuro pretende-se avaliar formalmente a contribuição do jogo educacional como um instrumento de aprendizagem, utilizando para isso metodologias de avaliação de jogos já existentes na literatura. REFERÊNCIAS [1] H. L. Reif and M. Mitri, How university professors teach project management for information systems, Commun. ACM, vol. 48, no. 8, pp , aug [Online]. Available: [2] M. R. Gramigna, Jogos de Empresa, 2nd ed. Pearson Education, 2007, são Paulo. [3] C. G. Wangenheim, D. Kochanski, and R. Savi, Revisão sistemática sobre avaliação de jogos voltados para aprendizagem de engenharia de software no brasil, FEES - Fórum de Educação em Engenharia de Software, evento integrante do XXIII Simpósio Brasileiro de Engenharia de Software (SBES), [4] B. Gloger, Ball point game, 2008, disponível em: [5] R. Savi, Avaliação de jogos voltados para a disseminação do conhecimento, Ph.D. dissertation, Universidade Federal de Santa Catarina (UFSC), 2011, tese (Doutorado) - UFSC, Florianópolis. [6] J. V. Dempsey et al., Instructional applications of computer games. Annual Meeting of the American Educational Research Association, April 1996, new York, NY. [7] J. Mcdonald, Exam review strategies, 2004, disponível em: Review Strategies Packages.pdf. Acesso em: 01 jul [8] K. Mantyla, Interactive Distance Learning Exercises that Really Work! ASTD, [9] 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 [10] R. S. Pressman, Engenharia de Software - Uma Abordagem Profissional, 7th ed. Mc Graw Hill, [11] M. Cohn and B. Wake, The scrum game a fun interactive tool for learning, 2007, disponível em: [12] E. Isotton, Scrumming - ferramenta educacional para ensino de práticas de scrum, 2008, trabalho de Conclusão de Curso (Graduação em Bacharelado em Sistemas de Informação) - Pontifícia Universidade Católica do Rio Grande do Sul, Porto Alegre. [13] A. Krivitsky, Scrum simulation with lego bricks, 2009, disponível em: Simulation-with-LEGO-Bricks-v2.0.pdf. [14] F. Siller and J. C. Braga, Software educacional para prática do scrum, Workshops do II Congresso Brasileiro de Informática na Educação, 2013, campinas, São Paulo. [15] 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 , [Online]. Available: article/pii/s

70 Formação de Equipes de Alto Desempenho Para Desenvolvimento de Software Alessandra Costa Smolenaars Dutra Faculdade de Informática (FACIN) Pontifícia Universidade Católica do RS (PUCRS) Porto Alegre, RS, Brasil Rafael Prikladnicki Faculdade de Informática (FACIN) Pontifícia Universidade Católica do RS (PUCRS) Porto Alegre, RS, Brasil 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. 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. Um estudo realizado pelo Standish Group [1], conduzido em 2010, com uma amostra de 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 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 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]. 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]. 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. 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. 70

71 II. 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. 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]. 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]. 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]. 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 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. 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. 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. 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. 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 ( 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 71

72 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. 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. ABORDAGENS DE CAPACITAÇÃO EM ES 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. 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 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. 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]. 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. 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. 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. 72

73 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. V. CONSIDERAÇÕES FINAIS 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? 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 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. REFERÊNCIAS [1] The Standish Group, Chaos, acessado em 9 de junho de [2] Faraj, S., Sambamurthy, V.,"Leadership of information systems development projects". In: IEEE Transactions on Engineering Management, [3] Enricone, D. (Org.). Ser Professor, 3a edição, EDIPUCRS, [4] Beckman, K., Coulter, N., Khajenouri, S., Mead, N. Collaborations:Closing the industry academia gap. IEEE Software 14 (6), pp ,1997. [5] Gibbs, W. Software's chronic crisis. Scientific American (1994), pp [6] Saiedian, H., Software engineering education and training for the next millennium, Journal of Systems and Software, v. 49, p , [7] ACM/IEEE. Computer Science Curriculum, Guidelines for Undergraduate Degree Programs in Software Engineering, [8] 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, [9] 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 [10] 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 [11] Roda, R., Self-Organizing Agile Teams: A Grounded Theory, Tese de Doutorado, Victoria University of Wellington, [12] ACM/IEEE. Software Engineering Curriculum. Guidelines for Undergraduate Degree Programs in Software Engineering, [13] Sommerville, I. Engenharia de Software 9a edição. São Paulo: Pearson Prentice Hall, [14] Shaw, M. Software Engineering Education: A Roadmap. In: Future Of Softwareengineering, International Conference On Software Engineering - Icse',Limerick. Proceedings. New York: ACM, [15] Conn, R. Developing Software Engineers at the C-130J Software Factory. IEEE Software,Los Alamitos, v. 19, n. 5, p , Sep [16] Katzenbach, J. R; Smith D. K. A Força e o Poder das Equipes. São Paulo: Makron Books do Brasil Editora Ltda, [17] Chiavenato, I. Gestão de pessoas: o novo papel dos recursos humanos nas organizações. Rio de Janeiro: Elsevier, 2008, 3a edição. [18] Boyett, J.H; Boyett, J.T. O gui dos gurus: os melhores conceitos e práticas de negócios. Rio de Janeiro: Campus, [19] 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. [20] Tonet, H. et al. Desenvolvimento de equipes. 2. ed. Rio de Janeiro: FGV, 2009, p 72. [21] Gnatz, M.; Kof. L.; Prilmeier, F.; Seifert, T. A. Practical Approach of Teaching Software Engineering. In: 16 TH CONF. SOFTWARE ENG. EDUCATION AND TRAINING, Proceedings... p , [22] Hadjerrouit, S. Learner-centered web-based instruction in software engineering. IEEE Transactions on Education, v. 48, p , [23] Gresse, V. W. C.; SHull, F. To Game or Not to Game? Software, IEEE, v. 26, n. 2, p , [24] 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. [25] 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, p [26] 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 , [27] 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, [28] 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,

74 ARPostIts: Mobile Application for Agile Software Engineering using Augmented Reality Dhiana Deva and Thaiana Lima Polytechnic School Federal University of Rio de Janeiro (UFRJ) Rio de Janeiro, Brazil {dhiana.deva, Cláudia Werner and Claudia Rodrigues Systems Engineering and Computer Science Program COPPE/UFRJ Rio de Janeiro, Brazil {werner, 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. INTRODUCTION 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]. 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. 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. 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. 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 II. AUGMENTED REALITY 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. 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. 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. 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. 74

75 III. SOFTWARE ENGINEERING AND AUGMENTED REALITY 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. IV. AGILE SOFTWARE DEVELOPMENT 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, Mingle 1 uses cards to refer to the items being developed by the team. In contrast, the central elements of Pivotal Tracker 2 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. 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 video 3 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. 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 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. 1 Mingle website. Available in 2 Pivotal Tracker website. Available in 3 Visual pollution with Post-it notes 75

76 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 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 7 Heroku: Cloud Platform as a Service. Available in 8 Django: High-level Python web framework. Available in 9 Code repository for the mobile application of ARPostIts. Available in 10 Code repository for the administrative application of ARPostIts Available in 4 ARPostIts video showing its usage at an agile consulting firm. Available in 5 Qualcomm Vuforia Developer Portal. Available in 76

77 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. A. Applications ARPostIts has been used for product and project management activities at Concrete Solutions 11. It expands the visibility of items progress on agile task boards. Figure 6 shows a task board using encoded Post-its. Fig. 6: Organized task board using ARPostIts 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. Personal task management also benefits from the ease of visual communication of ARPostIts. This expands the potential reach of the application. VII. FINAL CONSIDERATIONS 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. 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 11 Concrete Solutions website. Available in members during the meetings. A formal experiment is a goal for future work. 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. 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. REFERENCES [1] R.S. Pressman. Software Engineering, 7th ed. Brazil, 2011, pp [2] 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, [3] S. Feiner, B. Macintyre, and D. Seligmann. Knowledge-based augmented reality. Magazine Communications of ACM, New York, vol. 36, pp.53 62, July [4] R. Azuma, Y. Baillot, R. Behringer, S. Feiner, S. Julier and B. MacIntyre. Recent advances in augmented reality. IEEE Computer Graphics & Applications, pp , vol 21, issue 6, Nov-Dec [5] 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) [6] 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, Natal, II WBVS. III Congresso Brasileiro de Software(CBSoft), 2012; (in portuguese) [7] 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" [8] J. Segers. Analysis of a paper- and software-based Scrum task board Business Information Technology MSc Thesis. Enschede, September [9] K. Schwaber and J. Sutherland. The Scrum Guide July [10] T. Ohno. Toyota Production System: Beyond Large-Scale Production Cambridge, MA, Productivity Press,

78 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. 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. Keywords (palavras-chave) ensino de programação; objetos de aprendizagem; programação concorrente. I. 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 é 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. 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]. 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. 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. 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

79 [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. 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. 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 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. 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 e 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. Fig. 1. OA Quero Bolo Tela inicial 79

80 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. 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á. 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. 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 caixas de seleção correspondentes são ativadas no Quero Bolo. 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){} } } //... 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){} } } //... 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 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

81 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 s 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. 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). 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. 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. 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 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. REFERENCES [1] N. Akimoto; J. Cheng An Educational Game for Teaching and Learning Concurrency. In: Knowledge Economy and Development of Science and Technology (KEST 2013), [2] G. L. Davies. Teaching concurrent programming with Pascal-FC. ACM SIGCSE Bulletin, v. 22, n. 2, p , [3] 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 Disponível em: < [4] 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 [5] 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, [6] A. Ortiz. Teaching concurrency-oriented programming with Erlang. In Proceedings of the 42nd ACM technical symposium on Computer science education, SIGCSE 11, 2011, pages , New York, NY, USA. ACM. [7] S. S. Toscani. Vale4 Uma Linguagem Didática para Ensino de Programação Concorrente. In: Anais do I Workshop de Sistemas Operacionais (WSO 2004), [8] 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 ). ACM

82 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, edgar@wais.com.br, 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 Apresentamos um resumo da estratégia, o processo de construção do questionário, bem como uma análise das informações coletadas. 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]. 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. 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 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. 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. 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. 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 82

83 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. 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. 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 Fagan 1. Com isso, ao longo da disciplina, cada grupo teve a possibilidade de exercer três papéis diferentes: construtor de requisito, cliente e auditor. 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. 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 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 , July, 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. 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. 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. 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 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. As respostas foram elaboradas de acordo com uma ordem ascendente de satisfação a contento ou entendimento quanto a 83

84 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. Após a conclusão da disciplina, enviamos um 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. A Figura 1 ilustra uma questão quantitativa presente no questionário referente ao papel de Engenheiro de Requisitos. 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 ALUNO 02 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 Pontos fortes: Gerência atuante Uso de atas Pontos fortes: Presença do consultor Estratégia de tarefas paralelizadas Divisão das tarefas Pontos fracos: Tamanho do grupo 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 03 ALUNO 04 Pontos fortes: Presença do consultor Estratégia de tarefas paralelizadas Divisão das tarefas e diferentes papéis Experiência próxima da realidade Pontos fracos: Gerência não atuante Consistências: Na maioria das perguntas quantitativas e qualitativas é possível perceber que há consistência Discrepâncias: Algumas perguntas apresentam algum grau de insatisfação, porém, não disserta a respeito Pontos fracos: Tamanho do grupo 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 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. 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. 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. 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

85 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. 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 na turma de graduação da disciplina de Engenharia de Requisitos. Fig. 2 - Resultado Obtido 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. 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. 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 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. 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. REFERÊNCIAS [1] J.C.S.P. Leite,.Livro Vivo: Engenharia de Requisitos, [2] H.S. Becker, Segredos e Truques da Pesquisa, Ed. Zahar, [3] 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, [4] 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-, [5] R.A. Likert, A technique for the measurement of attitudes Archives of Psychology.Vol. 22 n. 140, p , [6] Google Docs Create Form in acessado e criado em maio de [7] G. Gabrysiak, H. Giese, A. Seibel, S. Nerumann, Teaching requirements engineering with virtual stakeholders without software engineering knowledge IEEE: IEEE Computer Society [8] 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 [9] 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 [10] 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 [11] 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 13-14, [12] 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, [13] 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, [14] H. Simon, Theories of Decision-Making in Economics and Behavioral. Science The American Economic Review, Vol. 49, No.3, Pags ,

86 Práticas de colaboração no desenvolvimento de Software com o Governo: impactos na aprendizagem de alunos de graduação Camila Ferreira 1, Aline Gonçalves 1, Marisa Santos 2, Paulo Meirelles 1, Hilmer Neri 1 1 Faculdade UnB Gama Universidade de Brasília (UnB), Brasil 2 Ministério do Planejamento, Orçamento e Gestão (MP), Brasil {camilaferreira251,alinegsantoss}@gmail.com, marisa.santos@planejamento.gov.br, {paulormm,hilmer}@unb.br 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. INTRODUÇÃ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 Livre 1. Hoje, tal iniciativa é coordenada pelo Comitê Técnico de Implementação de Software Livre do Governo Federal 2. 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/ 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 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 OpenACS 4. 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-04- de-12-de-novembro-de openacs.org 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 86

87 Seção V, apresentamos as considerações finais deste relato de experiência. II. ARQUITETURA 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 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 estamos utilizando o Mailman na versão 2, que é um software gratuito para gerenciamento de discussão eletrônica de 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; 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. III. METODOLOGIA 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 87

88 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 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: 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. IV. RELATO DE EXPERIÊ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 5 o e o 10 o 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". 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

89 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. TRABALHOS FUTUROS 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. REFERÊNCIAS [1] K. Schwaber and M. Beedle, Agile Software Development with Scrum, 1st ed. Upper Saddle River, NJ, USA: Prentice Hall PTR, [2] B. Fitzgerald, G. Hartnett, and K. Conboy, Customising agile methods to software practices at intel shannon, Eur. J. Inf. Syst., pp , V. CONCLUSÃ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

90 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 Thaty_Sousa13@hotmail.com, {RejaneCosta, ElaineVenson, RicardoAjax}@unb.br 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. 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]. 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. 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. Um dos aspectos abordados no projeto é a transferência de conhecimento, uma vez que um dos riscos das contratações, 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. 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. 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. 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]. 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. 90

91 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]. 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. 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. III. O PROJETO 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. 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. 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]. 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 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. 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. 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. 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. 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. 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. 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]. 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á 91

92 levado em consideração o aspecto de satisfação dos receptores [18]. IV. RELATO DE EXPERIÊNCIA 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. 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. As atividades voltadas para transferência de conhecimento e os artefatos definidos para o ProGeDDAS estão na Tabela I. TABELA I. Atividades Definir visão da solução Revisar visão da solução Workshop de solução Escrever histórias de usuário da primeira sprint Escrever histórias de usuário da próxima sprint Colaborar com o time scrum Realizar reunião de revisão da sprint Treinar usuários ATIVIDADES E ARTEFATOS Artefatos Documento de visão Documento de análise e viabilidade Backlog do produto Documento de arquitetura Código fonte documentado Testes unitários automatizados Testes de integração 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 o projeto piloto; transferir conhecimento dos pesquisadores para os envolvidos do Ministério; e participar e contribuir nos eventos acadêmicos da área. 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. Para a realização do trabalho, a equipe utilizou algumas ferramentas. Para a modelagem do processo utilizou-se a ferramenta Bizagi Process Modeler 1. Para a organização dos estudos identificados nas bases de dados eletrônicas utilizouse o Zotero 2. Já para a distribuição e acompanhamento das atividades, utilizou-se o Trello 3. 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 . 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. 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

93 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. 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. 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. 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. 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. AGRADECIMENTOS Este trabalho foi realizado no laboratório de pesquisa Centro de Qualidade e Testes (CQTS) da Faculdade Gama da Universidade de Brasília e parcialmente financiada pelo projeto de pesquisa Framework de Soluções de Tecnologia da Informação. REFERÊNCIAS [1] 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. [2] Brasil, Acórdão N o 2314/2013. Levantamento de Auditoria. Conhecimento Acerca da Utilização de Metodologias Ágeis nas Contratações de Software Pela Administração Pública Federal [3] Brasil, Guia de Boas Práticas em Contratação de Soluções de Tecnologia da Informação [4] 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, [5] M. Alaranta e S. L. Jarvenpaa, Changing IT Providers in Public Sector Outsourcing: Managing the Loss of Experiential Knowledge, in System Sciences (HICSS), rd Hawaii International Conference on, 2010, p [6] Brasil, Instrução Normativa N o 04, de 12 de novembro de 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 [7] Brasil, Guia Prático para Contratação de Soluções de Tecnologia da Informação [8] 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, [9] I. Nonaka e H. Takeuchi,. Rio de Janeiro: Campus, [10] 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 [11] 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, [12] 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, n o 5, p , out [13] J.-N. Lee, The impact of knowledge sharing, organizational capability and partnership quality on IS outsourcing success, Information & Management, vol. 38, n o 5, p , [14] M. Westner e S. Strahringer, Determinants of success in IS offshoring projects: Results from an empirical study of German companies, Information & Management, vol. 47, n o 5 6, p , ago [15] Brasil, Plano Estratégico de Tecnologia da Informação (PETI) e Plano Diretor de Tecnologia da Informação (PDTI) [16] Brasil, Norma Operacional SPOA No 006, de 10 de Setembro de 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 [17] M. Cohn, Succeeding with agile: software development using Scrum. Upper Saddle River, NJ: Addison-Wesley, [18] Y. Mei, Z. Wang, e Z. Cao, Performance evaluation model of knowledge transfer, in Artificial Intelligence, Management Science and Electronic Commerce (AIMSEC), nd International Conference on, 2011, p

94 Uma Ferramenta de Apoio à Criação e Gerenciamento de Laudos Patológicos Veterinários Édylle Landy Oliveira Grupo de Pesquisa de Tomada de Decisão Multicritério (GPTDM) Universidade Federal do Pará Castanhal, Pará edylle@ufpa.br Luiz Venicio P. Conceição Grupo de Pesquisa de Tomada de Decisão Multicritério (GPTDM) Universidade Federal do Pará Castanhal, Pará luizpedrosa@ufpa.br Marcos César da Rocha Seruffo Grupo de Pesquisa de Tomada de Decisão Multicritério (GPTDM) Universidade Federal do Pará Belém, Pará seruffo@ufpa.br 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; laudos; sistema; padronização; veterinária. I. 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 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. 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 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. 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 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. Durante o desenvolvimento do sistema, os integrantes da Fábrica de Software foram orientados a estudar novas 94

95 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. 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. 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. 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. 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. 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. 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 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, 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. 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 95

96 funcionalidades. Os erros encontrados eram documentados pelos desenvolvedores e corrigidos o quanto antes. 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. 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. 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. 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. 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. 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. 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 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 [1] 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), [2] Bergeron, F., Bateau, C., & Raymond, L. (1991, March). Identification of strategic information systems opportunities: applying and comparing two methodologies. MIS Quarterly, 15(1), [3] SOMMERVILLE, Ian. Engenharia de software. São Paulo. 6. ed. Pearson Education Companion, [4] Pressman, Roger. S. (2005) Software Engineering: A practitioner s approach, McGraw Hill, 6th edition. [5] 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: PMI: [6] 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, [7] DMSS Software. IBM SPSS Statistics. Disponível em: < Acesso em: 19 maio

97 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 1, Hilmer Neri 1 1 Faculdade UnB Gama - Universidade de Brasília (UnB), Brasil alinegsantoss@gmail.com, hilmer@unb.br 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. Index Terms Gerenciamento, contratações, software, organizações públicas, lean, métodos ágeis, desenvolvimento, produção, estudo de caso, engenharia de software. I. INTRODUÇÃ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 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? II. METODOLOGIA DE PESQUISA 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. PROJETO DO ESTUDO DE CASO Como unidade de estudo de caso, foi selecionado o contrato IPHAN N o 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: IV. RESULTADOS DO ESTUDO DE CASO Os resultados dos dados coletados foram categorizados em dois efeitos: entrega de ordens de serviço e satisfação do cliente. 97

98 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. 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 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. V. CONCLUSÃ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 /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. REFERÊNCIAS [1] Acórdão n o 2314, Tribunal de Contas da União, Brasília, Brasil, [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, [3] R. K. Yin, Estudo de Caso - Planejamento e Métodos, [4] M. Bigge, Teorías de aprendizagem para professores. Editora pedagógica e universitaria, [Online]. Available: 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: CSMiQwAACAAJ 98

99 Um estudos sobre métricas de produto e vulnerabilidades para tomada de decisões Arthur Del Esposte 1, Carlos Bezerra 1, Paulo Meirelles 1, Hilmer Neri 1 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 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. INTRODUÇÃ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 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) - 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. II. METODOLOGIA Este trabalho tem sido realizado por dois graduandos de Engenharia de Software cuja primeira etapa foi desenvolvida ao longo do 1 o semestre de 2014 e a finalização deve-se dar no fim do 2 o 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. 99

100 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. III. ESTUDOS E RESULTADOS 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 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 Caracterização Caracterização do cenário com Métricas Ponto Crítico de Identificar classes muito Alto valor de Falha acopladas, que representam ACC+NOC pontos críticos da Variáveis não inicializadas 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 EXEMPLOS DE CENÁRIOS PROPOSTOS Ao menos uma ocorrência da métrica UAV Por fim, na primeira etapa dessa monografia, contribuímos tecnicamente com dois projetos de software livre que fazem parte do contexto deste trabalho: o Mezuro 2 e Analizo 3, 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. CONSIDERAÇÕES FINAIS 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. REFERÊ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 [2] S. Henry and D. Kafura, The evaluation of software systems structure using quantitative software metrics, in Software Practice and Experience, 1984, pp [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 [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, [5] L. T. Almeida and J. M. Miranda, Código limpo e seu mapeamento para métricas de código fonte,

101 A Platform Fed by Software Industry Problems to Learn Software Development Luiz Ferreira Departamento de Ciências da Computação Universidade Federal de Minas Gerais Belo Horizonte, Minas Gerais, Brasil Eduardo Figueiredo 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. INTRODUCTION 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 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. CODECHALLENGE 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 101

102 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. 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. 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 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]. 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 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. CONCLUSION AND EXPECTED RESULTS 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 work was partially supported by CNPq (grant Universal /2013-5) and FAPEMIG (grants APQ and PPM ). REFERENCES [1] 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 [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. [3] 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, [4] 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), th International Conference on. IEEE, 2013, pp [5] S. R. Chidamber and C. F. Kemerer, A metrics suite for object oriented design, Software Engineering, IEEE Transactions on, vol. 20, no. 6, pp , [6] C. Dellarocas and M. Van Alstyne, Money models for moocs, Communications of the ACM, vol. 56, no. 8, pp , [7] C. Wohlin, P. Runeson, M. Höst, M. C. Ohlsson, B. Regnell, and A. Wesslén, Experimentation in software engineering. Springer,

103 Um estudo sobre bibliotecas digitais no contexto da participação social Luiz Matos 1, Fernando Cruz 1, Paulo Meirelles 1 1 Laboratório Avançado de Produção Pesquisa e Inovação em Software - LAPPIS Faculdade UnB Gama, Universidade de Brasília, Brasil luizff.matos@gmail.com, {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. INTRODUÇÃ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. METODOLOGIA 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 (IPEA 1 ) 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. ESTUDOS E RESULTADOS 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

104 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 Noosfero 2, 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-View- Controller (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 OAI- PMH, 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: 3 Capacidade 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 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. CONSIDERAÇÕES FINAIS 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. REFERÊNCIAS [1] G. A. de Almeida, Participação e controle social na garantia dos direitos humanos, [Online]. Available: 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, [3] P. Wegner, Interoperability, ACM Computing Surveys, vol. 28, pp , [4] R. Fabbri, Relatório técnico do pnud - ontologia do portal federal de participação social, [5] F. Solagna, Análise de experiências nacionais e internacionais de participação mediada por internet, Base contendo as principais vocabulários utilizados em web semântica. Disponível em: 104