FEES 2009Fórum de Educação em Engenharia de Software

05 a 09 de Outubro de 2009 Fortaleza • Ceará • Brasil

Artigos Técnicos

Realização DC • Departamento de Computação

UFC • Universidade Federal do Ceará

PromoçãoSBC • Sociedade Brasileira de Computação

ACM • Association for Computing Machinery

ii

Apresentação

A educação e o treinamento adequados podem melhorar significativamente a prática de Engenharia de Software e representam, também, um pré-requisito para o avanço do estado da arte nesta área. O objetivo do Fórum em Educação de Engenharia de Software (FEES) é expor e analisar as dificuldades e particularidades do ensino e da aprendizagem de Engenharia de Software, propondo e discutindo estratégias de apoio às atividades educacionais.

O Fórum é o espaço adequado para a discussão geral de tópicos relacionados à educação em Engenharia de Software, criando um canal de integração e de troca de experiências entre diferentes tipos de atores interessados no assunto. O FEES está em sua 2a edição e é parte das atividades do Simpósio Brasileiro de Engenharia de Software (SBES).

Esta coletânea reúne os trabalhos selecionados para apresentação no II FEES. Este ano, recebemos 12 artigos, dos quais 8 foram selecionados para apresentação e publicação. Dos 8 artigos, 7 são artigos completos e 1 é um resumo estendido. Além da disponibilização dos anais, os artigos estarão disponíveis na rede, na coleção FEESArtigos (http://fees.inf.puc-rio.br/FEESArtigos/).

Faz parte desta edição do FEES um painel que discutirá os currículos de graduação em Engenharia de Software. Essa nova modalidade de graduação é um tema que vem atraindo várias discussões no âmbito da Sociedade Brasileira de Computação.

Agradecemos aos autores e aos revisores. O trabalho cuidadoso dos revisores continua como marca desse Fórum, contribuindo para o debate como para a qualidade dos textos publicados. Agradecemos, também, o apoio da Comissão Especial de Engenharia de Software da SBC e à organização local do SBES e SBBD, nas pessoas de Bernadette Farias Lóscio e Vânia Maria Ponte Vidal e suas equipes.

Fortaleza, Outubro de 2009

Itana Maria de Souza Gimenes, UEM/PR Julio Cesar Sampaio do Prado Leite, PUC-Rio

Coordenadores do Comitê de Programa do FEES 2009

XXIII SBES - FEES

iii

Biografias

Itana Gimenes. Professora Titular de Engenharia de Software da Universidade Estadual de Maringá. Pós-Doutorado na School of Computer Science/University of Waterloo, ON, Canadá (2005). Ph.D. em Ciência da Computação pela The University of York, Department of Computer Science, GB (1992). Interesses atuais de pesquisa incluem: arquitetura de software, linha de produto de software, desenvolvimento baseado em componentes e sistemas de gerenciamento de workflow e processos de negócios.

Julio Cesar Sampaio do Prado Leite. Membro do Working Group 2.9 (Software Requirements Engineering) da IFIP (International Federation for Information Processing) é um dos fundadores da área de Engenharia de Requisitos. Tem participação ativa nessa área; quer como membro do corpo editorial do Requirements Engineering Journal da Springer, quer como membro, desde de 1993, do comitê de programa da conferência internacional de requisitos (RE). Além da Engenharia de Requisitos, tem

trabalhado em outras áreas, principalmente em reuso de software; tendo sido o General Chair da ICSR. Foi Cientista do Nosso Estado (1999 e 2007), professor visitante da Universidade de São Paulo(ICMC), professor visitante da Universität Kaiserslautern, cientista visitante do Fraunhofer IESE, professor convidado da ECI da Universidad de Buenos Aires e visiting scholar na University of Toronto. É membro da Association for Computing Machinery e da IEEE Computer Society. Sócio fundador da Sociedade Brasileira de Computação (SBC) , participou de seu conselho entre 1996 e 2000. Tem revisto artigos para uma série de periódicos, entre os quais destacam-se: IEEE TSE, IEEE Software, ACM Computer Surveys e ACM Tosem. Tem participado de alguns seminários Dagstuhl. É Co-editor do livro Perspectives on Software Requirements e co-fundador da série WER (Workshop em Engenharia de Requisitos) e da série FEES (Fórum de Educação em Engenharia de Software). Através de palestras ou consultoria tem ajudado diversas organizações na adoção de novas tecnologias.

XXIII SBES - FEES

iv

Coordenadores do Comitê de Programa

Itana Maria de Souza Gimenes, UEM/PR Julio Cesar Sampaio do Prado Leite, PUC-Rio

Comitê de Programa

Adenilso Simão, ICMC/USP Ana Regina Cavalcanti da Rocha, COPPE/UFRJ Andréa Mendonça, UFCG Claúdia Werner, COPPE/UFRJ Cristina Von Flach G. Chavez, UFBA Christiane Gresse von Wangenheim,UNIVALI Daltro Nunes, UFRGS Eduardo Almeida, UFBA Ellen Francine Barbosa, ICMC/USP José Luis Braga, UFV Paulo Pires, UFRN Rafael Prikladnicki, PUCRS Renata Araujo, UNIRIO Simone Barbosa, PUC-Rio Valter Camargo, UFSCar

XXIII SBES - FEES

v

Índice

Sessão Técnica 1:Estratégias de Ensino de Engenharia de Software

Qual Conhecimento de Engenharia de Software é Importante para um Profissional de Software? ............................................................................................................................. 1 Christiane Gresse von Wangenheim, Djoni Antonio da Silva

Ensino de Engenharia de Software: Desafios, Estratégias de Ensino eLições Aprendidas ............................................................................................................... 9 Rafael Prikladnicki, Adriano Bessa Albuquerque, Christiane G. von Wangenheim, Reinaldo Cabral

Sobre o uso de Jogos Digitais para o Ensino de Engenharia de Software........................... 17 Lúcia Fernandes e Cláudia Maria Lima Werner

Tratando Especificação de Requisitos com Estudantes Iniciantes de Programação ........... 25 Andréa Mendonça, Danielle Chaves, Dalton Guerrero, Evandro Costa

Sessão Técnica 2: Apoio ao Ensino de Engenharia de Software

Portal EduES Brasil: Um Ambiente para Apoiar a Pesquisa em Educação em Engenharia de Software no Brasil ....................................................................................... 33 Rafael E. Santo, Rodrigo Santos, Cláudia Werner, Guilherme Travassos

Revisão Sistemática sobre Avaliação de Jogos Voltados para Aprendizagem de Engenharia de Software no Brasil ....................................................................................... 41 Christiane Gresse von Wangenheim, Djone Kochanski, Rafael Savi

Diretrizes para o Ensino Interdisciplinar de Engenharia de Software................................. 49 Juliana Cristina Braga

Elaboração de um Survey para a Caracterização do Cenário de Educação em Engenharia de Software no Brasil .......................................................................................................... 57 Marcelo Schots, Rodrigo Santos, Andréa Mendonça, Cláudia Werner

XXIII SBES - FEES

Qual Conhecimento de Engenharia de Software é Importante para um Profissional de Software?

Christiane Gresse von Wangenheim1, Djoni Antonio da Silva2

1PPGCC/INE/UFSC – Federal University of Santa Catarina2CTTMAR/UNIVALI – Universidade do Vale do Itajaí

gresse@gmail.com, djonisilva@gmail.com

Abstract. We present the results of a survey conducted to identify the importance and amount learned of Computer Science topics, principally, focusing on Software Engineering, in the career of software professionals,repeating an adapted version of a survey conducted in 1998 by T. Lethbridge. The survey has been conducted in 2008 among Computer Science graduates in Brazil. The results suggest that various topics may be under-represented in Computer Science courses, whereas others may be less relevant for Computer Science curriculums.

Resumo. Apresentamos resultados de um estudo realizado para identificar a importância e a quantidade de conhecimentos aprendidos por profissionais da área de software em tópicos dos Cursos de Ciência da Computação, dando ênfase para a Engenharia de Software, repetindo e adaptando uma versão de uma pesquisa realizada em 1998 por T. Lethbridge. A pesquisa foi realizada em 2008 entre graduados em Ciência da Computação no Brasil. Os resultados sugerem que vários tópicos podem estar sendo abordados de maneira insuficiente nos cursos de Ciência da Computação, enquanto outros poderiam ser considerados menos relevantes nos currículos.

1. IntroduçãoTipicamente, profissionais de software são formados em cursos de graduação como modo de preparação para atuar na área. O curso de graduação, que se destaca nesta área é o de Ciência da Computação, além dos cursos de Engenharia da Computação e de Sistemas de Informação. No entanto, há anos a indústria se queixa de que os cursos de graduação não ensinam aos alunos as competências necessárias para que eles possam começar a executar o seu trabalho com eficiência (Gudivada, 2003) (Callahan & Pedigo, 2002). Uma das críticas é a falta de atenção com o ensino de Engenharia de Software (ES) na graduação (Mead et al., 1997). Além disso, o papel de um profissional de software deixou de limitar-se somente a conhecimentos técnicos, passando a exigir um vasto conjunto de conhecimentos e habilidades como comunicação, trabalho em equipe, etc. Neste contexto, o ensino adequado de ES é importante para melhorar o estado atual de desenvolvimento de software e ajudar a mitigar muitos dos problemas tradicionais associados à indústria de software.

Contudo, especialmente nos cursos de graduação, os tópicos de ES são normalmente ensinados de forma bastante superficial, abordando essas questões dentro de poucas disciplinas no curso (Mead et al., 1997). E, embora o desenvolvimento do SWEBOK (IEEE, 2004) e das Diretrizes Curriculares para Graduação (IEEE/ACM, 2005) tenham

XXIII SBES - FEES

1

sido um avanço significativo, ainda se pergunta se os tópicos de ES são ensinados de maneira adequada no Curso de Ciência da Computação para preparar adequadamente os profissionais desta área.

Esta questão tem sido de grande interesse nos últimos anos e foram realizadasalgumas tentativas de investigar o que os profissionais e a as empresas esperam do ensino do Curso de Ciência da Computação (CC). Em 1998, Lethbridge (Lethbridge, 2000) realizou uma pesquisa com profissionais da área de software constatando que alguns tópicos da graduação foram considerados menos úteis, enquanto se teve a impressão que para outros tópicos considerados importantes, não foi dada a devida atenção no ensino. Este estudo foi repetido em 2002 por Kitchenham (Kitchenham et al., 2005) com resultados muito semelhantes. Portanto, dez anos depois da primeira pesquisa nos propomos repetir o estudo, buscando obter informações sobre a relevância dos temas abordados nos cursos de ciência da computação segundo opinião dos profissionais desta área (especificamente, no que diz respeito à ES), visando contribuir para a melhoria dos currículos atuais.

2. A PesquisaNossa pesquisa é fortemente baseada na pesquisa realizada por (Lethbridge, 2000) (Lethbridge, 1999) e na pesquisa realizada por (Kitchenham et al., 2005).Questionário. Revendo o questionário utilizado por (Lethbridge, 1999) e (Kitchenham et al., 2005), definimos um questionário com 69 tópicos agrupados em 6 categorias (Tabela 1) levando em consideração as recomendações para currículos de cursos de Ciência da Computação (IEEE/ACM, 2001), (IEEE/ACM, 2004), (MEC, 1999) e principalmente, relacionados à ES, o SWEBOK (IEEE, 2004) e o framework CMMI (CMMI Product Team, 2006). Tabela 1. Lista de tópicos e categorias

Software Estruturas de dados e algoritmosGerência de arquivos Banco de dadosLinguagens de programação específicas Teoria de linguagem de programaçãoMedição e análise de desempenhoAnálise de complexidade computacional e de algoritmoInteligência artificialReconhecimento de padrões e de processamento de imagensComputação gráficaSegurança e criptografiaSistemas operacionaisTransmissão de dados e redesProcessamento paralelo e distribuídoSistemas embarcadosProgramação WebErgonomia

Engenharia de SoftwareGerência de projetosDesenvolvimento de requisitosGerência de requisitosMétodos formais de especificaçãoConceitos e tecnologias orientadas a objetosArquitetura de softwareSoftware design/projeto e padrõesTeste de softwareInspeção e revisão de softwareGarantia da qualidade de softwareGerência de configuração de softwareManutenção, reengenharia e engenharia reversaMétricas de softwareConfiabilidade de software e tolerância à falhasEstimativa de custo/ esforço de software Processo de software e melhoria de processo (CMMI, MPS.BR)Ferramentas de engenharia de software

Hardware Eletrônica digital e lógica digitalArquitetura de microprocessadorArquitetura de sistema de computadorEletrônica analógicaRobóticaProcessamento digital de sinaisProjeto VLSI

MatemáticaCálculo diferencial e integralEquações diferenciaisÁlgebra linear e matrizesProbabilidades e estatísticaLógica matemáticaTeoria de grafosAnálise combinatóriaFunções, relações e conjuntos

Áreas AfinsFísicaQuímicaEconomiaContabilidadeMarketingGerenciamentoEmpreendedorismoPsicologia

Ciência ComputacionalAnálise numéricaPesquisa operacionalModelagem e simulação

XXIII SBES - FEES

2

Filosofia Redação TécnicaOratóriaHabilidades de trabalho em equipeLiderançaNegociaçãoLegal / profissionalismo, ética e sociedadeControle estatístico de processosMetodologia científicaSegunda língua

Seguindo (Lethbridge, 1999), utilizamos as mesmas quatro perguntas para cada tema(Tabela 2). Cada uma destas questões tem respostas associadas a uma pontuação, que varia de 0 a 5. Tabela 2. Questões e respostas.

Q1. Quanto você aprendeu sobre isso durante o curso de ciência da computação?0 =Aprendi nada1 = Tornei-me vagamente familiar2 =Aprendi o básico3=Me tornei funcional (conhecimento moderado) 4= Aprendi muito5 =Aprendi em profundidade, me tornei um especialista (aprendi quase tudo)

Q2. Qual é o seu atual conhecimento sobre isso, considerando que você aprendeu isso no emprego e quanto você esqueceu-se desde a sua graduação?0=Sei nada1=Estou vagamente familiarizado2=Sei o básico3=Estou funcional (conhecimento moderado) 4=Sei muito5=Sei em profundidade, sou um especialista (sei quase tudo)

Q3. Este assunto específico foi útil para você na sua carreira?0=Completamente inútil1=Quase nunca usei2=Ocasionalmente útil3=Moderadamente útil - em determinadas atividades4=Muito útil5=Essencial

Q4. Quanto seria útil aprender mais sobre este assunto (por exemplo, em cursos complementares)?0=Inútil aprender mais1=Dificilmente útil2=Possivelmente útil3= Moderadamente útil4=Importante aprender mais5=Crítico de aprender mais

Além disso, incluímos questões demográficas a fim de caracterizar os participantes. Também utilizamos um conjunto de perguntas como filtro no início do questionário. Duas versões do questionário (em Português e Inglês) foram desenvolvidas e disponibilizadas na web utilizando a ferramenta de código aberto LimeSurvey(http://www.limesurvey.org). Para reduzir a influência do cansaço nas respostas, a ordem dos grupos e dos tópicos é alterada automaticamente a cada acesso. Antes da coleta de dados, o questionário foi testado dentro do nosso grupo de pesquisa.Público-alvo. Como público-alvo do nosso estudo, definimos Bacharéis em Ciência da Computação que se formaram entre 1998 - 2005 em um curso de CC no Brasil, e que trabalham como profissionais da área de software. Este público alvo foi selecionado com o objetivo de incluir profissionais que tiveram tempo suficiente para adquirir experiências na prática. Por outro lado, foram excluídos profissionais que se formaram há muito tempo seguindo um currículo desatualizado. Como nossa pesquisa está focada emBacharéis em CC, excluímos graduados de outros cursos como Engenharia da Computação e de Sistemas de Informação. Realizamos o convite para a participação da pesquisa por meio de listas de email, grupos de discussão e fóruns.Execução da Pesquisa. Dados foram coletados durante o período de 20 de Outubro de 2008 a 1 de Dezembro de 2008. Durante esse período, recebemos respostas completas de 48 participantes que trabalham como profissionais na área de software. Entre os participantes estão bacharéis de Ciência da Computação de universidade públicas e privadas do Brasil. Os participantes da pesquisa trabalham com diferentes tipos de softwares, sendo que a maioria trabalha com gestão de informação ou aplicações de software e uma minoria com sistemas embutidos. Eles estão envolvidos em diferentes atividades no processo de software com uma forte concentração nas atividades técnicas.

XXIII SBES - FEES

3

3. ResultadosUma análise completa e detalhada da pesquisa pode ser encontrada em (Wangenheim & Silva, 2009). Aqui, em razão do foco deste trabalho, apresentamos resultados específicos para a Engenharia de Software.3.1 Quais tópicos de ES são mais importantes para os profissionais da área de software?A importância dos tópicos foi avaliada baseando-se no valor da mediana das respostas à pergunta 3: Este assunto específico foi útil para você na sua carreira? Comparado com outros tópicos de Cursos de CC, os tópicos de ES estão entre os mais importantes, todos com uma importância de no mínimo 3. Na Figura 1 é mostrada a ordem dos tópicos de ES por importância.

Figura 1. Classificação dos tópicos de ES ordenados pela importância

Esta importância dos tópicos relacionados à ES é enfatizada também pelo fato que, considerando todos os tópicos de Cursos de CC desta pesquisa, aqueles relativos àES ficaram entre os 25 mais importantes (Wangenheim & Silva, 2009).3.2 A quantidade do ensino na graduação corresponde à importância dada aos tópicos de ES?Adaptando a definição utilizada em (Kitchenham et al., 2005), que define o gap de conhecimento como sendo a diferença entre a importância e o aprendizado na graduação: Gap de Conhecimento = (mediana das respostas da pergunta Q3) - (medianadas respostas da pergunta Q1) (Figura 2). Assim, um valor negativo indica que a graduação deixou a desejar em relação à importância dada ao tópico.

XXIII SBES - FEES

4

Figura 2. Gap de conhecimento por tópico de ES

Analisando o gap de conhecimento, podemos observar que todos os tópicos de ES parecem não ser tratados suficientemente na graduação considerando a importância dada aos mesmos, e isto, especialmente em relação á gerência de projetos. 3.3 Os profissionais da área de software aprendem no trabalho o que é necessário?De acordo com (Lethbridge, 1999), analisamos a quantidade aprendida referente a cadatópico no trabalho (ou esquecida desde a graduação) com base na diferença entre as respostas das perguntas 1 e 2 (Figura 3).

Figura 3. Quantidade aprendido nos tópicos de ES em relação a educação formal e treinamentos

Os profissionais confirmaram que aprenderam mais sobre tópicos de ES depois da graduação. Sobretudo, o tópico de gerência de projetos é enfatizado como um dos temas que os profissionais mais tiveram que aprender depois de se formarem. No entanto, o conhecimento atual dos participantes ainda não atinge o nível de importância

XXIII SBES - FEES

5

dado a vários tópicos de ES, salientando, mais uma vez, o gap de conhecimento existente no que diz respeito ao aprendizado dos tópicos de ES, tanto na graduação, quanto na formação profissional.

3.4 A importância dos tópicos mudou em comparação com as outras pesquisas?A fim de analisar esta questão, comparamos a classificação dos tópicos ordenados pelaimportância em nossa pesquisa com a classificação das pesquisas realizadas por Lethbridge e Kitchenham. No entanto, é importante salientar que a importância foi avaliada de forma diferente em cada uma das pesquisas. Em nosso estudo, analisamos importância considerando o valor da mediana para as respostas da pergunta 3. No estudo Lethbridge, várias maneiras de avaliar a importância foram aplicadas (Lethbridge, 1999). No entanto, a apresentação da lista completa dos tópicos está disposta pelo cálculo do valor médio das respostas das questões 3 e 4. No estudo de Kitchenham, a importância é calculada sobre a proporção de respostas dos participantes, que receberam três pontos (indicando, que a utilidade do tópico era no mínimo moderada) ou mais para a questão 3.Outro aspecto a ser considerado é a variação dos tópicos considerados em cada uma das pesquisas. Embora, fortemente baseado no estudo de Lethbridge, modificamos os tópicos para ajustá-los as nossas necessidades e aos avanços da área, incluindo, por exemplo, o tópico de programação web. Por outro lado, a pesquisa realizada por Kitchenham abrange os grupos de software e ES apenas, não incluindo, por exemplo, áreas afins ou hardware. Em razão das quantidades diferentes de tópicos nas pesquisas, consideramos então os tópicos de ES que estavam entre os 15 mais e os 15 menos importantes da pesquisa de Kitchenham, e os tópicos que estavam entre os 25 mais e 25 menos importantes com relação aos nossos resultados e os do Lethbridge.Tabela 3. Comparação do ranking de importância (os tópicos presentes em todas as três pesquisas são marcados em azul, os tópicos presentes em duas pesquisas são marcados em verde).Nossa pesquisa (Lethbridge, 1999) (Kitchenham et al., 2005) Tópico de SE entre os tópicos mais importantesConceitos e tecnologias orientadas a objetos

Software design/projeto e padrões Gerência de projetos

Gerência de projetos Arquitetura de software Levantamento e análise de requisitosDesenvolvimento de requisitos Levantamento e análise de requisitos Arquitetura de softwareGerência de requisitos Conceitos e tecnologias orientadas a

objetosMétodos de projetos e análise

Arquitetura de software Métodos de projetos e análise Testes, verificação & garantia da Qualidade

Software design/projeto e padrões Gerência de projetos Práticas de projetos de softwareTeste de software Testes, verificação & garantia da

QualidadeConceitos e tecnologias orientadas a objetos

Garantia da qualidade de software Gerência de liberação e configuraçãoEstimativa de custo/ esforço de software Confiabilidade de software e tolerância a

falhasProcesso de software e melhoria de processo (CMMI, MPS.BR)Ferramentas de engenharia de softwareTópico de SE entre os tópicos menos importantesNenhum Nenhum Manutenção, reengenharia e engenharia

reversaMétodos de especificação formalEstimativa de custo de softwareConfiabilidade de software e tolerância a falhasNormas e processos (CMM/ISO 9000 etc.) Métricas de software

Comparando os resultados dos três estudos, podemos observar que praticamente todos os tópicos de ES citados entre os mais importantes da pesquisa Lethbridge e Kitchenham

XXIII SBES - FEES

6

também continuam entre os temas mais importantes no nosso estudo. No entanto, o fato do nosso estudo ter mais tópicos de ES citados entre os mais importantes pode indicar uma tendência de aumento da importância dos tópicos de ES. Isso inclui até mesmo tópicos como melhoria de processo de software e estimativa dos custos, que, no estudo de Kitchenham, ficaram classificados entre os tópicos menos importantes. Uma observação interessante é que no nosso estudo (bem como no estudo Lethbridge) nenhum tópico de ES foi citado entre os menos importantes, ao contrário do estudo de Kitchenham, em que alguns tópicos de ES foram citados entre os menos importantes.

4. Implicações para as orientações curricularesEmbora tenhamos de ter muito cuidado ao interpretar os resultados, devido ao pequeno tamanho da amostra e a sua restrição a profissionais brasileiros, os resultados podem ser relevantes como base para reexaminar as competências profissionais necessárias para ter sucesso na área de software, especialmente em comparação com os outros estudos. A Tabela 4 mostra uma comparação da classificação dos tópicos de ES por importância.Esta comparação é resultante da nossa pesquisa com o resumo do corpo de conhecimento de Cursos de CC, conforme apresentado nas diretrizes curriculares para a graduação em computação (IEEE/ACM, 2001), indicando também o número mínimo de horas sugerido para cada tópico.Tabela 4. Mapeamento dos tópicos de ES ao corpo de conhecimento de Cursos de CCNossa Pesquisa IEEE/ACM CS Curriculum guidelines

Grau daImportância Tópicos de Engenharia de Software Corpo de conhecimentos de Cursos de

Ciência da Computação

Número mínimo sugerido de horas *

1 Conceitos e tecnologias orientadas a objetos PL6. Programação orientada a objeto 10

2

Gerência de projetos SE8. Gerenciamento de Projetos de Software 3Desenvolvimento de requisitos SE5. Especificações e requisitos de software 4Gerência de requisitosArquitetura de software SE1. Projeto de Software 8Software design/projeto e padrõesTeste de software SE6. Validação de Software 3Garantia da qualidade de softwareConfiabilidade de software e tolerância à falhas SE11. Confiabilidade de Software -Estimativa de custo/ esforço de softwareProcesso de software e melhoria de processo (CMMI, MPS.BR)

SE4. Processos de Software 2

Ferramentas de engenharia de software SE3. Ambientes e Ferramentas de Software 3Métodos de especificação formal SE10. Métodos Formais -Inspeção e revisão de software Como parte da validação de software(SE6)Gerência de configuração de softwareManutenção, reengenharia e engenharia reversa SE7. Evolução de Software 3Métricas de software

*O número representa o número mínimo de horas necessárias para atingir o padrão do curso conforme sugerido pelo (IEEE/ACM, 2001). A não alocação do número de horas indica que o conteúdo do curso não possui número mínimo de horas indicado na especificação.

Esta comparação pode indicar uma falta de dedicação a certos tópicos de ES considerados importantes. Para alguns temas podemos identificar uma falta total de consideração, como, por exemplo, gerenciamento de configuração de software, que na prática é considerada como uma base essencial, não só para engenheiros de software, mas para qualquer profissional de software. E, em geral, considerando a sugestão de umtotal de no mínimo 280 horas para um curso de CC, a atribuição de cerca 36 horas aos tópicos de ES não parece corresponder com a percepção da importância destes tópicos.

5. Conclusões

XXIII SBES - FEES

7

Nossa pesquisa parece confirmar as críticas de que as competências de ES, necessárias aos profissionais de software, muitas vezes não estão sendo adequadamente abordadas nos cursos de CC. Comparando nossos resultados com estudos anteriores, parece que aimportância dos tópicos SE cresceu ainda mais hoje em dia. É claro, que o desenvolvimento de um currículo de CC adequado e atualizado não é trivial. Um problema central é que é simplesmente impossível cobrir todo o material potencialmente relevante, especialmente considerando a variedade de empregos e domínios em que profissionais de software atuam. Mesmo assim, acreditamos que os resultados da nossa pesquisa podem contribuir como um feedback às práticas educacionais atuais.

AgradecimentosGostaríamos de agradecer o T. Lethbridge por fornecer o material utilizado na pesquisa em 1998 e o grupo de pesquisa Cyclops/UFSC por hospedar o sistema de pesquisa.Este trabalho foi apoiado pelo Conselho Nacional de Desenvolvimento Científico e Tecnológico - CNPq – Brasil e a UNIVALI – Universidade do Vale do Itajaí/Brasil.

ReferênciasCallahan, D., Pedigo, B. Educating Experienced IT Professionals by Addressing Industry’s Needs. IEEE Software, 19/5, 2002.CMMI Product Team. CMMI for Development, Version 1.2. Technical Report CMU/SEI-2006-TR-008, Carnegie Mellon University/Software Engineering Institute, 2006Gudivada, V. N. The Computing Profession at a Crossroads. IEEE Computer, 36/5, 2003.IEEE CS. SWEBOK - Guide to the Software Engineering Body of Knowledge, 2004.Joint Task Force on Computing Curricula IEEE/ACM. Computing Curricula 2001 - Computer Science. Final Report, 2001.Joint Task Force on Computing Curricula IEEE/ACM. Software Engineering 2004 - Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering, 2004.Joint Task Force for Computing Curricula ACM/AIS/IEEE-CS. Computing Curricula 2005 -The Overview Report, 2005.Kitchenham, B. et al. An Investigation of Software Engineering Curricula. Journal of Systems and Software, 74/3, 2005.Lethbridge, T. C. The Relevance of Education to Software Practitioners: Data from the 1998 Survey. Technical Report TR-99-06, University of Ottawa - Computer Science, 1999.Lethbridge, T. C. What Knowledge Is Important to a Software Professional? IEEE Computer, 33/5, 2000.Mead, N., et al. The State of Software Engineering Education and Training. IEEE Software, vol. 14, no. 6, 1997.Ministério de Educação. Currículo de Referência da SBC para Cursos de Graduação em Computação e Informática, 1999. Wangenheim, C. Gresse von, da Silva, D. A. Survey on the Relevance of Topics in Computer Science Education. Technical Report LQPS001.09E, Universidade do Vale do Itajaí, 2009.(http://www.inf.ufsc.br/~gresse/download/LQPS001_09E.pdf)

XXIII SBES - FEES

8

Ensino de Engenharia de Software: Desafios, Estratégias de Ensino e Lições Aprendidas

Rafael Prikladnicki1, Adriano Bessa Albuquerque2, Christiane G. von Wangenheim3, Reinaldo Cabral4

1Faculdade de Informática (FACIN) – PUCRS – Porto Alegre – RS 2Universidade de Fortaleza - UNIFOR – Fortaleza – CE

3PPGCC/INE/CTC – UFSC – Florianópolis – SC*

4PESC/COPPE – UFRJ – Rio de Janeiro – RJ

rafaelp@pucrs.br, adrianoba@unifor.br, gresse@gmail.com,

cabral@cos.ufrj.br

* Anteriormente afiliada à UNIVALI

Abstract. This paper presents a set of teaching experiences in Software Engineering from four Universities in Brazil. These experiences were planned and executed based on the identification of important challenges faced during the learning processes in the last years. Lessons learned and plans for future activities are also presented.

Resumo. Neste artigo apresenta-se um conjunto de experiências de ensino em Engenharia de Software vivenciadas por quatro Instituições de Ensino Superior no Brasil. Estas experiências foram planejadas e executadas a partirda identificação de desafios importantes durante o processo de ensino nos últimos anos. Junto com as experiências são apresentadas algumas lições aprendidas e passos futuros.

1. Introdução 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 (Enricone, 2002). 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 (Beckman et al., 1997). A qualidade da educaçã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 (Gibbs, 1994). Hoje, a educaçã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 (Saiedian, 1999; ACM/IEEE, 2008).

XXIII SBES - FEES

9

Mas ao mesmo tempo em que esta importância em relação ao conteúdo é reconhecida, também se demonstra cada vez mais significativo tratar aspectos didáticos e pedagógicos no ensino (Saiedian, 1999). Aulas tradicionais, estratégia de ensino predominante, raramente satisfazem a necessidade de aprendizagem (Grillo, 2002). Segundo Junior (2008) e Grillo (2002), os métodos de ensino podem estar focados no professor ou focados no aluno. Cada um tem suas vantagens e desvantagens, em função do conteúdo da aula, das características dos alunos, da turma, entre outros fatores. Os métodos focados no aluno podem gerar uma maior motivação por parte de quem aprende, além de uma participação mais ativa no processo e uma melhor aprendizagem no nível de aplicação dos conceitos (Junior, 2008), o que hoje parece ser um dos principais pontos fracos no ensino de ES. E é exatamente este o tema deste artigo. A partir de experiências reais de quatro diferentes Instituições, apresentam-se estratégias de ensino de ES usando uma abordagem participativa com foco no aluno. A próxima seção apresenta os conceitos relacionados com o processo de ensino, enquanto que na seção 3 apresentam-se as estratégias de ensino. Lições aprendidas e recomendações são apresentadas na seção 4.

2. O Processo de Ensino O professor é um dos principais responsáveis pelo ensino, pesquisa e gerenciamento do processo educacional. É ele quem escolhe os métodos utilizados para captar a atenção do seu público em um determinado período. O professor deve utilizar instrumentos didáticos que priorizem a participação do aluno, gerenciando suas expectativas e habilidades. Existem duas categorias principais de métodos de ensino: as focadas no professor e as focadas no aluno. A tabela 1 apresenta uma comparação entre os métodos (Junior, 2008; Grillo, 2002).

Tabela 1. Comparação entre as duas categorias de métodos de ensino

Focado no professor Focado no aluno

Papel do professor

•Principal fornecedor da informação •Especialista •Avaliador do rendimento

•Facilitador •Fornece informação para ajudar na compreensão da informação

Clima de aprendizagem

•Individualista •Coletiva •Foco na coesão de grupo

Orientação •Baseada na experiência e nos

conhecimentos do professor •Baseada na experiência e conhecimento dos alunos

Programa de estudos

•Definido pelo professor •Negociado entre professor e alunos

Objetivo de ensino

•Definido pelo professor •Resultado padrão

•Definido pelos alunos •Resultados diferentes para cada aluno

Aquisição de conhecimento

•Enfoque na aquisição •Foco na memorização

•Enfoque na utilização e absorção de conhecimento com foco em problemas reais

Métodos de ensino

•Didático •Grande participação do professor

•Métodos que envolvem a participação dos alunos (técnicas dinâmicas)

Foco na educação •Educação individual •Educação coletiva

Avaliação •Executada pelo professor •Uso tradicional de provas e notas

•Os alunos também são responsáveis pela avaliação

Quanto mais expositiva for a aula, mais ela será centrada no professor. Por outro lado, quanto mais prática e dinâmica for a aula, mais ela será centrada no aluno. Apesar de a aula expositiva ser o principal e mais antigo instrumento de ensino no Brasil em

XXIII SBES - FEES

10

todos os níveis, a pedagogia centrada no professor tende a valorizar relações hierárquicas (Junior, 2008). Uma aula expositiva acaba sendo pouco eficiente, pois ativa apenas o sentido da audição. Eventos simulados e atividades vivenciais permitem assimilar situações diferentes na prática. Sendo assim, a aprendizagem mais prática acaba sendo caracterizada pelo envolvimento de uma pessoa em uma determinada atividade, com resultados mais positivos, visto que os alunos acabam sendoresponsáveis pela definição de rumos de uma situação proposta.

2.1. Ensino de Engenharia de Software A ES é uma disciplina preocupada com 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 (ACM/IEEE, 2008). Geralmente, ES é ensinada no ensino formal no nível de graduação e/ou pós-graduação ou por meio de treinamentos profissionais de curta duração. Em relação à estratégia de ensino, o currículo na área de ES (ACM/IEEE, 2004; ACM/IEEE, 2008) ressalta a necessidade de mover-se para além do formato de aula expositiva. Neste sentido, é importante considerar a variação de técnicas de ensino e aprendizado. As abordagens mais comuns para ensinar ES incluem aulas expositivas, aulas de laboratório, entre outros. Entretanto, abordagens alternativas podem ajudar os alunos a aprender de maneira mais efetiva, como por exemplo: a substituição de aulas expositivas por discussão de casos práticos (Gnatz et al, 2003), dinâmicas de grupo, o uso de jogos (Wangenheim e Shull, 2009) e Capstone projects (um esforço em grupo em que alunos executam um projeto do início ao fim) (Goold e Horan, 2002). Neste sentido, são apresentadas a seguir algumas experiências vivenciadas pelos autores com foco no aumento da participação do aluno no processo de ensino-aprendizagem em ES.

3. Estratégias participativas para o ensino de Engenharia de Software

3.1. O uso de dinâmicas de grupo, educação à distância e atividades práticas Na PUCRS, no curso de graduação em Sistemas de Informação (SI), a área de Engenharia de Software é abordada principalmente em seis disciplinas (PUCRS, 2009). Neste artigo o foco é no relato da experiência com a disciplina de Gerência de Projetos de Software, que tem fomentado o aumento da participação do aluno desde 2004. Esta disciplina, de 60 horas-aula, envolve o ensino de conceitos básicos de gerência de projetos de software, relacionando o ciclo de gerenciamento com as etapas do ciclo de desenvolvimento. Objetivo de aprendizagem: apresentar os conceitos básicos de gerência de projetos de software, mesclando teoria e prática. Estratégia de ensino: A estratégia de ensino se propõe a tratar dos conceitos de gerência de projetos de forma diferenciada. A interação com os alunos é enfatizada através de dinâmicas que exploram assuntos específicos. São características chave da estratégia: (i) diversificação nas técnicas de dinâmicas de grupo: uso de dinâmicas envolvendo raciocínio, mini-fábrica de aviões e jogo de memória. A dinâmica com aviões são utilizadas para introduzir conceitos de processo de gerência de projetos. O jogo de memória é utilizado para trabalhar os conceitos do PMBOK (PMI, 2008) e raciocínio é utilizado em dinâmicas sobre gerência de comunicação; (ii) aula prática em laboratório: apesar de gerência de projetos ter um conteúdo bastante teórico, a disciplina

XXIII SBES - FEES

11

é organizada de forma que os alunos explorem conceitos de forma prática, envolvendo a definição de escopo de projeto, criação de EAP (estrutura analítica de projeto) e desenvolvimento de cronogramas; (iii) planejamento dos trabalhos pelos alunos: as datas de entregas (parcial e final) dos trabalhos são planejadas pelos alunos, respeitando datas limites definidas pelo professor. Isto faz com que os alunos tenham uma experiência real de planejamento e monitoramento de um projeto, que no caso é o trabalho da própria disciplina. A entrega no prazo vale nota, e qualquer alteração deve ser justificada; e (iv) aulas semipresenciais: 20% da disciplina (em média seis aulas) são realizadas utilizando-se de recursos EAD (educação à distância). Nestas aulas, os alunos vivenciam situações reais de projetos e precisam resolver estando fora do ambiente de aula. Uma contribuição relevante da aula EAD é o desenvolvimento de habilidades de trabalho em equipe e comunicação à distância. Avaliações: A avaliação da disciplina é realizada através de provas individuais e a entrega de dois trabalhos, todos com pesos iguais. Parte das atividades desenvolvidas nas aulas em formato EAD compõe a nota do trabalho 1, e parte compõe a nota de uma das provas. Além disso, existe uma atividade para avaliar a percepção de evolução do aprendizado, onde os alunos preenchem questionários no primeiro dia de aula e recebem o mesmo questionário no último dia de aula para avaliar a evolução do aprendizado e comparar com as respostas fornecidas no início do semestre; Experiências: Esta disciplina começou a incentivar a participação dos alunos em 2004, e desde então vem evoluindo de formato. Os questionários foram introduzidos no ano de 2004. Em 2005 foram introduzidas duas dinâmicas (para ensino da importância de processo de software e para ensino do processo de gerenciamento das comunicações), complementadas por uma terceira dinâmica em 2008 (ensino de gerenciamento de projetos iterativos e incrementais). As aulas em laboratório foram introduzidas em 2006, e o planejamento do trabalho por parte dos alunos foi introduzido em 2008. As aulas EAD foram introduzidas em 2009. Apesar de haver o estímulo da avaliação, houve uma participação acima de 90% dos alunos nas atividades EAD. No futuro planeja-se a inclusão de jogos de computador.

3.2 O uso de capstone projects e atividades práticasNa UNIVALI no curso de graduação em Ciência da Computação no campus São José a área de Engenharia de Software é principalmente abordada por quatro disciplinas. Dentro deste contexto, o objetivo das primeiras disciplinas é ensinar os conceitos básicos. No contexto deste artigo, o foco está na última das quatro disciplinas, chamada de Análise e Projeto de Sistemas 2. Esta disciplina representa um capstone project conforme sugerido nas recomendações da ACM/IEEE (2004), em que grupos de alunos planejam e executam um projeto de software do inicio até o fim durante um semestre inteiro.

Objetivos de aprendizagem: Os objetivos de aprendizagem são de reforçar a compreensão de conceitos, processo e técnicas de ES e de que o aluno tenha a competência para aplicá-los com assistência na prática. Além disso, visa à evolução de habilidades, como: comunicação, trabalho em equipe e resolução de problemas.

Estratégia de ensino: O enfoque principal desta disciplina é a internalização de conhecimento e habilidades pelo "learning by doing". Durante a disciplina é simulado um projeto de software, incluindo o planejamento, a execução (cobrindo as fases de análise de requisitos, design, implementação e testes) e a monitoração final. As equipes

XXIII SBES - FEES

12

de projetos são formadas por aproximadamente seis alunos. Cada aluno assume uma responsabilidade principal, porém, participa ativamente em todas as fases do projeto. O cliente é representado pelo professor, que também fornece uma descrição de alto-nível das necessidades do cliente.

O projeto se inicia com a fase de planejamento, onde é elaborado um plano de projeto. Em seguida, se iniciam as atividades técnicas conforme o plano de projeto e seguindo um modelo de processo de desenvolvimento pré-definido com base no modelo deciclo de vida cascata. Durante a execução do projeto, os alunos realizam as fases de análise de requisitos, design, implementação e testes. Em paralelo, os alunos coletam dados referentes aos prazos e esforço gastos nas atividades. Estes dados são avaliados no final do projeto representando um resumo de monitoração de projeto e são comparados com as estimativas no plano de projeto inicial. No final de cada fase, cada grupo entrega e apresenta os resultados parciais do projeto.

Avaliações: As avaliações da disciplina são realizadas por meio das entregas e apresentações dos resultados parciais do projeto no decorrer do semestre. No final do semestre é realizada uma avaliação individual por meio de uma prova. Experiências: Esta disciplina está sendo oferecida neste formato (com pequenas variações) desde 2000. O principal ponto forte observado pelos alunos é o fato que a disciplina oferece a oportunidade de acompanhar a execução de um projeto de software do início ao fim com o objetivo de reunir todos os conhecimentos e habilidadesaprendidos anteriormente durante o curso. Observa-se, que a necessidade de efetivamente aplicar os conceitos da ES também ajuda a reforçar o conhecimento teórico, além de começar a criar a competência de aplicá-los. Isto fornece aos alunos a oportunidade de alcançar competências e desenvolver habilidades, que não sãofacilmente adquiridas com métodos de ensino tradicionais. Para possibilitar que a disciplina reflita cada vez mais a realidade dos projetos de desenvolvimento de software, planejou-se também a troca de projetos entre os grupos em cada fase (por exemplo, o Grupo A desenvolve os requisitos referente ao projeto X, faz o design referente ao projeto Y para o qual grupo B desenvolveu os requisitos). Porém, esta prática requer que todos os trabalhos sejam realizados com um nível de qualidade mínima e dentro dos prazos dos marcos, para não prejudicar nenhum grupo de alunos. Outro ponto crítico da organização da disciplina é a criação de grupos maiores, pois o grau da contribuição de cada aluno pode variar significativamente causando injustiças na avaliação, mas, por outro lado, permite que os alunos treinem também habilidades, como trabalho em grupo e comunicação.

3.3. O uso de atividades lúdicas e jogos A disciplina de ES do curso de graduação em Ciências da Computação da Universidade de Fortaleza – UNIFOR é ofertada no penúltimo semestre do curso e tem como pré-requisitos as disciplinas de Análise e Projeto de Sistemas 1 e Análise e Projeto de Sistemas 2. A disciplina é ministrada com foco nos modelos de maturidade de software, principalmente no MR MPS (SOFTEX, 2007).

Objetivos de aprendizagem: Aumentar a compreensão de conceitos envolvidos na execução dos processos relacionados aos principais modelos de maturidade, bem como aumentar a percepção do aluno sobre como se dá a execução de cada um destes processos e sobre a importância de executá-los de forma integrada.

XXIII SBES - FEES

13

Estratégia de ensino: Primeiramente são apresentados conteúdos relacionados à qualidade de produtos de software para que posteriormente sejam apresentados conteúdos relacionados a processos de software, abrangendo a Normas ISO, processos ágeis e de forma geral o CMMI (SEI, 2006) e MR MPS (SOFTEX, 2007). Após uma ampla contextualização, os conteúdos relevantes de cada processo do MR MPS são apresentados e trabalhos em equipe. No final da disciplina, objetivando consolidar a compreensão dos processos Gerência de Projetos, Gerência de Requisitos, Garantia da Qualidade, Medição e Gerência de Configuração do MR MPS, é realizada uma atividade lúdica em grupo, utilizando LEGO. Uma das motivações de se utilizar LEGO é a relevância de atividades lúdicas para a retenção de conteúdos. Além disso, este brinquedo possibilita projetar, a partir de requisitos definidos, um produto a ser construído, havendo um bom nível de similaridade com a construção de software. Outra motivação para este tipo de abordagem em sala de aula é o professor poder realizar mais intervenções junto aos alunos e observar mais de perto as dificuldades encontradas durante a execução dos processos, percebendo assim, que conteúdos foram menos compreendidos. O uso de LEGO é planejado para ser executado em três aulas, seguindo um roteiro pré-definido. Os alunos devem planejar e construir um projeto real, fazendo o monitoramento e controle do projeto, a partir dos processos que foram definidos. Avaliações: As avaliações dos alunos na disciplina são realizadas por meio de provas individuais e trabalhos em equipe. A atividade lúdica premia com 1 ponto na média final os membros da melhor equipe. Além disso, os alunos também avaliam a abordagem utilizada respondendo um questionário contendo 19 questões. Experiências: De acordo com a última avaliação da disciplina, a grande maioria dos alunos (95%) considerou que a abordagem despertou neles a compreensão da relevância de se ter bons mecanismos de comunicação para a eficiência de processos de software. Além disso, 96% dos alunos consideraram que passaram a conhecer melhor as relações existes entre os processos. Este resultado foi importante, pois em apenas três aulas a interação entre os processos foi mais compreendida do que nas aulas teóricas, onde é sempre muito mais difícil perceber os pontos de interligação entre os processos. A grande maioria dos alunos considerou como principal ponto fraco da dinâmica o tempo estabelecido para sua execução, além de alguns alunos não encararem a experiência com seriedade. Também foram destacados os seguintes pontos fortes: a possibilidade de aumentar o nível de interação ente os alunos e aluno/professor e o auxílio para consolidar conceitos, a partir da vivência da teoria. A principal oportunidade de melhoria identificada foi aumentar o tempo de execução da abordagem.

3.4. Atividades lúdicas no aprendizado por analogia Em cursos de graduação ou pós-graduação, é possível desenvolver projetos que envolvem todo o ciclo de desenvolvimento de software, a exemplo da estratégia apresentada na seção 3.2. Porém, em cursos de curta duração (de 4 a 16 horas) não é possível realizar este exercício e este é um grande desafio: como potencializar a aprendizagem em cursos de curta duração? Esta estratégia, desenvolvida pelo Laboratório de Engenharia de Software (LENS) da COPPE/UFRJ, trata esta questão. Objetivos de aprendizagem: Prover o conhecimento e as habilidades necessárias à definição, à avaliação e à melhoria de processos de software que permeiam o ciclo de vida dos produtos de software.

XXIII SBES - FEES

14

Estratégia de ensino: A estratégia está baseada no uso de um instrumento didático que propicia o entendimento dos objetivos, da importância e da dinâmica dos processos de software pelo uso de analogias. O instrumento didático é constituído por um processo de aplicação, instrumentação (quebra-cabeças, um processo definido conforme o propósito, formulários de coleta de dados, check-lists e outros) e diretrizes de adaptação (permitem a configuração do instrumento para diferentes contextos). Para aplicar o instrumento em um cenário de melhoria de processos de software, por exemplo, os alunos são divididos em grupos e assumem os papéis de garantia da qualidade, medição, gerente de projetos e desenvolvedores. Um processo definido (de montagem do quebra-cabeça) é entregue com o quebra-cabeça desmontado. Um objetivo de melhoria é definido para todos os grupos: “diminuir o tempo de montagem”. A partir daí são executados três ciclos de montagem com quebra-cabeças diferentes: o primeiro para que o processo seja aprendido; o segundo para que o processo seja mensurado e o terceiro para testar as melhorias feitas no processo. Cada aluno exerce o seu papel, mensurando o processo, avaliando a qualidade dos produtos ao longo da execução, gerenciando o projeto e desenvolvendo o produto (montando o quebra-cabeça) e todos atuam na melhoria de forma conjunta. Após a aplicação do instrumento todos os aspectos exercitados são discutidos e tratados com enfoque teórico.

Avaliações: A avaliação do alcance dos objetivos de aprendizagem é realizada pelo uso de critérios qualitativos que incluem a participação e envolvimento durante a utilização do instrumento didático e durante a discussão a posteriori, que considera os aspectos teóricos apresentados versus as situações vivenciadas durante a dinâmica. Todos os participantes são incitados a emitir sua opinião sobre como a teoria poderia ser utilizada para potencializar os resultados da dinâmica. Neste ponto, é comum observar o surgimento de discussões polêmicas que podem ser exploradas de diversas formas.

Experiências: O instrumento foi submetido a diferentes cenários de cursos de curta duração em que o LENS atuou: em cursos fechados para empresa pública, em cursos abertos para empresas privadas, em disciplinas de pós-graduação e em diferentes regiões do País (sudeste, norte e nordeste), variando de quatro a oito horas de duração. O instrumento didático foi desenvolvido em outubro de 2005 e desde então vem evoluindo e sofrendo adaptações que permitem a exploração de diversos cenários. A abordagem descrita na seção 3.3, por exemplo, é um fruto da evolução desta estratégia definida para cursos de curta duração aplicada ao contexto de cursos de graduação.

4. Lições Aprendidas A partir das experiências relatadas neste artigo foram identificadas importantes recomendações, traduzidas em lições aprendidas: Lição 1: O uso de capstone projects propicia aos alunos vivência em projetos de software ao mesmo tempo que permite mesclar teoria e prática em disciplinas onde a experiência desempenha um papel fundamental; Lição 2: jogos e dinâmicas auxiliam na retenção de um conjunto de conceitos e significados que são mais facilmente compreendidos pelos participantes; Lição 3: As atividades lúdicas bem planejadas proporcionam maior abertura para lidar com o novo, o inesperado e as dificuldades comuns em projetos de software; Lição 4: O uso de abordagens que incentivam os alunos a testar hipóteses, refletirem sob suas práticas e se posicionarem de forma crítica fomentam o aprendizado e a participação.

XXIII SBES - FEES

15

5. Considerações finais Neste artigo foram apresentadas experiências de ensino de ES em cursos de graduação, pós-graduação e curta-duração de quatro IESs brasileiras. O foco do artigo foi na descrição de diversas experiências de ensino evitando as abordagens tradicionais. Devido ao limite de páginas, não foi possível aprofundar-se em cada estratégia de ensino com o nível de detalhe desejado. A partir desta limitação, uma das idéias futuras é conceber um local comum e integrado, de acesso público, para compartilhar diferentes estratégias de ensino para a comunidade de educadores de ES. Recomenda-se utilizar, sempre que possível, estratégias de ensino em que o aluno possa vivenciar os conteúdos apresentados em sala de aula, tirando-os da condição de meros observadores para manipuladores de instrumentos da realidade.

Agradecimentos Este trabalho recebeu apoio do Conselho Nacional de Desenvolvimento Científico e Tecnológico - CNPq.

Referências Bibliográficas ACM/IEEE. Computer Science Curriculum, 2008.

ACM/IEEE. Software Engineering Curriculum. Guidelines for Undergraduate Degree Programs in Software Engineering, 2004.

Beckman, K., Coulter, N., Khajenouri, S., Mead, N., Collaborations: Closing the industry–academia gap. IEEE Software 14 (6), pp. 49–57, 1997.

Enricone, D. (Org.) Ser Professor, 3a edição, EDIPUCRS, 2002.

Gibbs, W., Software's chronic crisis. Scientific American 271 3 (1994), pp. 86–95.

Gnatz, M., Kof. L., Prilmeier, F., Seifert, T. A Practical Approach of Teaching Software Engineering, Proc. 16th Conf. Software Eng. Education and Training, pp. 120–128, 2003.

Goold, A. e Horan, P. Foundation software engineering practices for capstone projects and beyond. Proc. 15th Conference on Software Engineering Education and Training (CSEE&T 2002), IEEE CS Press, pp 140-146, 2002.

Grillo, M. C., Práticas docentes e referenciais norteadores. Caderno Marista de Educação,Porto Alegre, v. 2, n. 2, p. 41-52, 2003.

Junior, W. H., Sauaia, A. C. A. Aprendizagem Centrada no Participante ou no Professor? Um Estudo Comparativo em Administração de Materiais. RAC, 12 (3), pp. 631-658, 2008.

PMI – Project Management Institute. A guide to the project management body of knowledge, 4th edition, 2008.

PUCRS, Bacharelado em Sistemas de Informação, Grade curricular, disponível online em www.pucrs.br/inf/estruturacurricular/sistemasdeinformacao_4621.htm, acesso em Julho/09.

SEI, CMMI® for Development, Version 1.2. CMU/SEI-2006-TR-008 ESC-TR-2006-008. Pittsburgh, PA Software Engineering Institute-SEI, Carnegie Mellon University: 561, 2006.

SOFTEX, MR-MPS - Modelo de Referência para Melhoria de Processos de Software - Guia Geral v1.2, Campinas, SP, SOFTEX: 53, 2007.

Saiedian, H., Software engineering education and training for the next millennium, Journal of Systems and Software, v. 49, i. 2-3, p. 113-115, 1999.

Wangenheim, C. G. v., Shull, F. To Game or Not to Game?, IEEE Software, 26 (2), pp. 92-94, 2009.

XXIII SBES - FEES

16

Sobre o uso de Jogos Digitais para o Ensino de Engenharia de Software

Lúcia Fernandes e Cláudia Maria Lima Werner

Programa de Engenharia de Sistemas e Computação – COPPE Universidade Federal do Rio de Janeiro

Centro de Tecnologia, Bloco H, Sala 319 Caixa Postal: 68511 CEP: 21941-972 - Brazil

{luciaaf,werner}@cos.ufrj.br

Abstract. More than two thousand years ago, the Sumerians invented the first board game. Since then, games have increasingly evolved. Maybe because it challenges our capacity, maybe because it amuses and distracts, people of any age or sex find in games an irresistible attraction. From this perception, educators make use of games aiming to increase the interest of their students in the classrooms. Technology has helped in this matter through computer games. The variety of titles found on the Internet shows that this is an attractive market with high possibility of expansion. This paper investigates learning through the use of games and, more specifically, learning of Software Engineering using computer games.

Resumo. Há mais de dois mil anos os sumérios inventaram o primeiro jogo de tabuleiro e de lá para cá, os jogos têm evoluído incessantemente. Seja porque desafia sua capacidade, seja porque diverte e distrai, o ser humano, de qualquer idade ou sexo, encontra no jogo uma atração irresistível. A partir desta percepção, educadores lançam mão de jogos visando aumentar o interesse dos alunos em suas salas de aula. A tecnologia veio auxiliar este objetivo através dos jogos em computador. A variedade de títulos encontrados na Internet mostra que este é um nicho de mercado atrativo e com possibilidade de expansão. Este artigo investiga o aprendizado com o uso de jogos e, mais especificamente, o aprendizado de Engenharia de Software.

1. Introdução

Em 2007, Marc Prensky cunhou o termo “Nativos Digitais” se referindo aos nascidos depois dos anos 80. Segundo ele, essa geração é capaz de ver TV, ouvir música, usar o celular e o notebook, tudo ao mesmo tempo. É altamente familiarizada com a Internet e o computador, representando hoje 50% da população ativa (pessoas de até 25 anos), mas em 2020 serão, possivelmente, 80% da população [MONTEIRO, 2009].

É fácil imaginar que o estudo e a forma de ensinar esta geração têm se modificado e deve vir a se modificar ainda mais ao longo dos anos. Um livro escolar de 20 anos atrás tem conteúdo, imagens e escrita bastante diferente dos atuais. Estas modificações objetivam não só acompanhar a evolução tecnológica, mas também tornar o estudo mais

XXIII SBES - FEES

17

atraente. Ensinar continua sendo um desafio. Como atrair os alunos para as salas de aula? Como tornar um assunto difícil e maçante em um desafio interessante?

A tecnologia pode ajudar, neste aspecto. A Internet está, literalmente, lotada de jogos educativos visando divertir e ensinar. Os jogos podem, sem que o aluno perceba, ajudá-los a introjetar conceitos que, de outra forma, seriam difíceis de aprender, no entanto, seria possível usar software no ensino da construção de software?

Este trabalho tem o objetivo de investigar a utilização de jogos como ferramenta de auxílio ao aprendizado, mais especificamente, ao aprendizado de Engenharia de Software (ES), e foi organizado da seguinte forma: a seção dois trata da evolução dos jogos. A seção três trata do ensino para adultos. A seção quatro trata dos jogos para o aprendizado de ES. Na seção cinco são propostos requisitos para os jogos de ES e, finalmente, na última seção, são feitas considerações finais.

2. Evolução dos Jogos Digitais

PRENSKY (2001) definiu a ação de jogar como uma atividade não obrigatória, governada por regras, que produz resultados incertos e que apresenta elementos que imitam a realidade. Sintetizado nesta frase talvez estejam presentes os elementos que tornam o jogo um atrativo, principalmente, para os “nativos digitais”. A incerteza de resultados e a não obrigatoriedade são chave. Todos gostam de “zerar” (completar e ganhar) um jogo, mas não mais retornam a ele quando o desafio acaba.

O ser humano vem se utilizando de jogos há centenas de anos, no entanto, ao contrário do que se poderia imaginar, a motivação inicial para sua criação não se deveu ao divertimento, e sim a treinamento e estratégia. Um exemplo é o jogo de tabuleiro chamado GO que, pretensamente, o imperador chinês Yao (2337-2258 a.C.) criou para ensinar seu filho Danzhu disciplina, concentração e equilíbrio [BANASCHAK, 1999].

O período de transição entre estes jogos, chamados de tabuleiro e os atuais videogames, se deu de forma lenta a princípio, em função da dificuldade de produção dos elementos do jogo. A partir da Revolução Industrial estes jogos foram amplamente disseminados [CEILIKAN, 2009]. Com a criação do primeiro jogo de computador (1952) e do primeiro videogame (1958), teve início a era dos jogos eletrônicos [WIKIPÉDIA, 2009].

No entanto, somente a partir da década de 70 os jogos eletrônicos passaram a ser explorados comercialmente. Inicialmente via jogos de galeria (arcade) e, em seguida, através das consoles [BATTAIOLA, 2000]. A partir dos anos 80, os jogos de tabuleiro perderam espaço para videogames e outras diversões eletrônicas [CEILIKAN, 2009].

Hoje os jogos possuem objetivos muito mais comerciais que em seus primórdios. Atualmente, três empresas controlam o mercado das consoles: a Microsoft (Xbox 360 - 2005), a Nintendo (Wii - 2006) e a Sony (Playstation 3 - 2006). Em virtude do alto interesse comercial, pois se trata de uma indústria que em 2008 movimentou R$90 bilhões somente no Brasil [BAND, 2009], a quantidade e variedade de jogos voltados para a diversão é significativamente maior que aqueles voltados para outros fins. Pode-se perceber, por exemplo, navegando pela Internet, que os jogos educativos estão presentes no computador, mas possuem fraquíssima penetração no mundo das consoles.

Na classificação encontrada em [BATTAIOLA, 2000], os jogos para treinamento ou educativos podem envolver características dos demais tipos, como: análise crítica e

XXIII SBES - FEES

18

decisão (jogos de estratégia), ambientação, tática e visão de primeira pessoa (simuladores), ações com raciocínio e reflexo (aventura), quebra-cabeças (passatempos), histórias e personagens (RPG) e colaboração e competição (esportes).

O mercado de jogos para educação está em formação. Talvez porque o jogo educativo exija, além do divertimento, a obrigatoriedade de um conteúdo didático, é que os professores ainda se aventurem pouco na utilização de jogos como apoio escolar.

3. Ensinando Adultos

O aprendizado de adultos e crianças é diferente. Esta foi a conclusão a que muitos educadores chegaram a partir da década de 70, quando Malcom Knowles (considerado o criador do termo “Andragogia”) trouxe à tona as idéias plantadas por Linderman e publicou várias obras, entre elas "The Adult Learner - A Neglected Species" (1973) [CAVALCANTI, 1999].

De acordo com CHOTGUIS (2005), o modelo andragógico (orientar adultos a aprender) é baseado em vários pressupostos que são diferentes daqueles do modelo pedagógico (educação de crianças – do grego paidós = criança): os adultos têm necessidade de saber porque precisam aprender algo. O motivador mais potente para o aprendizado de adultos são pressões internas, tais como o desejo crescente de satisfação no trabalho, auto-estima, qualidade de vida etc.

Considerando-se os cursos de graduação e especialização, onde os estudantes não podem ser considerados, exatamente, adultos, o ensino clássico pode resultar, para muitos deles, num “retardamento da maturidade”, já que exige uma total dependência dos professores e currículos estabelecidos. Suas iniciativas não encontram apoio, nem são estimuladas. A instituição e o professor decidem o que, quando e como eles devem aprender cada assunto ou habilidade [CAVALCANTI, 1999].

O computador tem ampliado sua participação no meio acadêmico, seja por imposição do mundo globalizado, onde ele está presente, significativamente na vida de cada cidadão (bancos, cartões de crédito, celulares etc.), seja por iniciativas explícitas governamentais (e.g., através da Universidade Aberta do Brasil ou programas de inclusão digital), o computador, aos poucos, deixa de ser um objeto de aprendizado para se tornar uma ferramenta no aprendizado.

4. Motivando o aprendizado de ES através de Jogos

A disciplina de ES foi criada em resposta à “crise do software” [PRESSMAN, 2001], caracterizada por atrasos na entrega, altos custos e baixa qualidade do software.. Comparando-se a um curso de Arquitetura onde se aprende a criar espaços, desde o primeiro período, em projetos cada vez mais completos; ou a um curso de Engenharia Civil onde o cálculo estrutural é usado em projetos ao longo do curso; em um curso de Computação, mais especificamente em uma disciplina de ES, pouco usa software no aprendizado dos processos de desenvolvimento de software.

Os projetos desenvolvidos em sala de aula pelos estudantes de ES, em função do tempo e da natureza didática, não permitem evidenciar diversos aspectos do processo de desenvolvimento [BENITTI, 2008].

XXIII SBES - FEES

19

BAKER, NAVARRO e HOEK (2005) reforçam que este problema está relacionado à maneira como a engenharia de software é comumente ensinada, não abrangendo adequadamente as ações críticas envolvidas no processo de desenvolvimento e na gestão de projetos. Mesmo que o professor possa explicar a maioria destas ações em aulas expositivas, os estudantes não terão a oportunidade de participar de um processo de desenvolvimento de software completo [BENITTI, 2008].

Em virtude da necessidade de capacitar o aluno nos processos da ES, uma das alternativas mais freqüentemente apresentadas é a utilização de jogos para preencher a lacuna existente entre o teórico e o prático.

Alguns projetos acadêmicos foram encontrados com enfoques e características variadas, dentre eles, o Planager, desenvolvido para apoiar o ensino de conceitos de gerência de projetos [KIELING et al, 2006]; o Scrumming, que simula o uso de algumas práticas do Scrum [SCHWABER, 2004], e busca suprir as necessidades no ensino de métodos ágeis para gerenciamento de projetos; o X-MED v1.0, que incentiva os alunos a aprender como desenvolver ou selecionar objetivos de medição, planos GQM e está alinhado ao nível 2 de maturidade do CMMI-DEV v1.2 [WANGENHEIM, 2009]; o SimSE, cujo propósito é representar os conceitos sendo estudados de forma gráfica [HOEK, 2002]; o SE•RPG que simula o ambiente de desenvolvimento de software através de um jogo que tem por cenário uma empresa de desenvolvimento fictícia [BENITTI, 2008]; o THE INCREDIBLE MANAGER, que apresenta as diversas fases características de um modelo de desenvolvimento de projeto de software onde o jogador (gerente de projetos) deve preparar um projeto, aprová-lo junto ao patrocinador, acompanhar seu desenvolvimento e resolver os problemas que ocorrerem [DANTAS, 2003]; o SESAM,cujo objetivo é testar o jogador (gerente de projetos) e fazê-lo ganhar o jogo se o projeto obtiver sucesso [DRAPPA e LUDEWIG, 2000]; o YAMM, que busca consolidar os conceitos relevantes da gerência de projetos, incluindo decisões de um ambiente real [VERONESE, 2004]; o Card Game que apresenta as fases de requisitos, projeto, desenvolvimento, integração e entrega de um projeto [BAKER et al, 2005]; e, finalmente, o CBT, que objetiva o entendimento das complexas situações de decisão associados ao gerenciamento de projeto [PFAHL, 2000].

A partir dos relatos encontrados na literatura pudemos observar que todas as propostas apresentadas estão associadas a jogos de simulação representando ambientes para desenvolvimento de projetos de software.

Curiosamente, quase todas as propostas, à exceção da X-Med (que está centrada na medição de software), focam nos mesmos aspectos, o desenvolvimento de um projeto dentro do orçamento, prazo e escopo previamente estabelecidos, tornando evidente que a motivação da criação da disciplina de ES ainda não foi completamente equacionada.

A avaliação de resultados das propostas não é conclusiva para todas, havendo algumas que não chegaram a ser utilizadas pelos estudantes (o Planager e o Scrumming estão em avaliação pelos estudantes e a avaliação para o CBT está em planejamento) ou os autores não fizeram menção a esta avaliação (YAMM). As avaliações de eficácia, quando existentes, se basearam em questionários preenchidos pelos estudantes que colocaram seus pontos de vista sobre os resultados alcançados (X-MED, THE INCREDIBLE MANAGER, Card Game). Somente a proposta SE•RPG se utilizou de

XXIII SBES - FEES

20

uma avaliação do aprendizado, com a aplicação de um questionário de conhecimentos antes e depois da utilização do jogo.

Considerando-se que a aplicação do jogo pode ocorrer em sala de aula, o professor somente interfere no “enredo” do jogo para as propostas SE•RPG e SimSE, onde o educador pode construir modelos customizados a fim de dar ênfase a assuntos específicos. As demais propostas não possuem esta opção ou não a mencionam.

A utilização remota do software não é estabelecida nas propostas, à exceção da proposta CBT que indica a possibilidade de utilização de um browser padrão.

As propostas não focam o trabalho colaborativo, considerando em todos os casos, o aluno (ou jogador) como o Gerente de Projetos responsável pela ação que deve, sozinho, controlar todos os problemas de um projeto ou realizar medições (X-Med).

Dos processos de gerenciamento, destaca-se o grupo de processos de Execução (para a grande maioria, onde é simulado o período de desenvolvimento de um projeto – requisitos, projeto, desenvolvimento e entrega). Nesta linha, encontra-se o SESAM, YAMM, CBT, Card Game e o SE•RPG. Enquadra-se no grupo de processos de Monitoramento e Controle a proposta X-Med e abordando o processo de planejamento posiciona-se o Planager [PRIKLADNICKI, 2008]. Outros aspectos de ES (por exemplo, Análise de Risco, Responsabilidade Profissional e Social) não são mencionados nas propostas. Da mesma forma que não encontramos comentários sobre foco em práticas de reuso envolvidas no desenvolvimento do software.

As proposições de jogos apresentadas, considerando-se o seu perfeito funcionamento, atendem a uma parte da proposição da ES que trata do desenvolvimento de software dentro de parâmetros limitantes de custo, prazo e esforço. Porém deixa em aberto vários itens que fazem parte da disciplina.

5. Ensinando com Jogos – Uma análise

Conforme identificado anteriormente, a quantidade de jogos desenvolvidos no meio acadêmico com o intuito de ensinar ES evidencia que é possível utilizar software para ensinar software. No entanto, será que os jogos estão sendo avaliados? Qual a eficiência de um jogo no aprendizado? Quais os requisitos capazes de ensinar a desenvolver software? Como aliar conteúdo ao desafio de um jogo? Deve existir alguma diferenciação nos jogos para os diferentes graus de ensino (graduação, pós-graduação, especialização etc.)? E para os níveis de maturidade de software?

Os requisitos para o desenvolvimento de tais jogos poderiam incluir diversos itens, dentre os quais, o conjunto sugerido a seguir:

Colaboração – um projeto de software, normalmente, é desenvolvido em equipe, sendo os participantes caracterizados por papéis específicos. A possibilidade de colaboração poderia levar os estudantes a melhor compreenderem a interação em equipe, necessária ao desenvolvimento de um software.

Conteúdo/Desafio – se o objetivo do jogo é ensinar, o conteúdo didático talvez seja o ponto mais crítico a ser abordado. Neste caso, uma importante característica do jogo seria o relacionamento entre os desafios do jogo e o conhecimento que se deseja transmitir.

XXIII SBES - FEES

21

Flexibilidade – de forma complementar ao item acima, existe uma grande necessidade de que o jogo possa acompanhar evolutivamente a disciplina abordada, pois, diferentemente de um assunto estabilizado (por exemplo, matemática fundamental), a disciplina está em constante evolução.

Participação do professor – a intervenção do professor para acelerar, modificar ou direcionar, pode vir a ser uma interessante característica a ser explorada em jogos educativos em geral e, especificamente, em uma proposta de Engenharia de Software.

Foco em processo – a resposta da comunidade de computação à “Crise do Software” onde os problemas de escopo, prazo, custo e qualidade atingiram limites indesejáveis [PRESSMAN, 2001] foi o estudo, desenvolvimento e estabelecimento de processos que viessem a disciplinar o desenvolvimento de software. Nada mais razoável, então, desejar-se que o jogo seja, fortemente, focado em processo. Esta deveria ser uma preocupação fundamental: ensinar processos (compreender, definir, seguir, controlar).

Níveis – uma prática comum em jogos digitais é a utilização de níveis de dificuldade para permitir aos jogadores maiores desafios. No caso de jogos para engenharia de software, estes níveis poderiam ser traduzidos para níveis de maturidade associados ao CMMI (Capability Maturity Model Integration) ou MPS-BR (Melhoria de Processos do Software Brasileiro) onde a cada nível mais requisitos seriam adicionados. Outra alternativa seria o aumento gradativo, nível a nível, do grau de controle sobre processos.

Lúdico – um dos maiores apelos para a utilização de jogos na educação é a possibilidade do estudante aprender e raciocinar sobre um tema sem perceber claramente que o está fazendo. O fator lúdico é de vital importância para a aceitação do jogo pelo aluno, sem ele, o jogo torna-se mero treinamento, não cativando seu interesse.

Multimídia – outro fator importante para atrair a atenção dos alunos é a capacidade visual do jogo através de recursos multimídia (som, imagem, movimento, efeitos).

Local x Remoto – um quesito adicional seria a possibilidade de se utilizar o jogo via Internet. Isso permitiria que os estudantes treinassem fora do período e do recinto escolar, em seus horários disponíveis, além de poder explorar um cenário cada vez mais comum que é o desenvolvimento distribuído de software.

Não se deve esquecer também, da avaliação dos resultados alcançados pelo jogo. Esta avaliação é de vital importância ao longo das aulas, para acompanhamento da eficácia do conteúdo transmitido.

Retornando aos jogos mencionados na seção 4, a Tabela 1 mostra um quadro comparativo segundo estes requisitos.

Tópicos Planager Scrumming X-MED SimSE SE•RPG The Manager SESAM YAMM C.Game CBT

Colaboração x x x x x x x x x xConteúdo + + + + + + + + + +

Flexibilidade x x x x x x x x x xParticipação x x x + + x x x x x

Foco Processo ? ? + ? ? ? ? ? ? ?Níveis x x x x x x x x x xLúdico - - - - - - - - - -

XXIII SBES - FEES

22

Multimídia - - - + - - - - - -Local x Remoto x x x x x x x x x +

Avaliação - - - - + - - - - -

Tabela 1: Quadro comparativo das propostas de jogos

Legenda: + característica identificada – característica fracamente identificada x característica não identificada ? característica não avaliada

Apesar da limitação causada pela análise ter se baseado apenas no relato dos autores, algumas observações puderam ser feitas: (colaboração) nenhum dos jogos é colaborativo; (conteúdo) de um modo geral, todos aliam o conteúdo ao desafio, apesar de todas as propostas, à exceção da X-Med (que está centrada na medição de software) estarem focadas na gestão do projeto, não abrangendo outros aspectos de ES; (flexibilidade) não foram relatadas características de crescimento ou extensão; (participação) somente relatado em SE•RPG e SimSE; (foco) não foi possível a análise deste quesito, no entanto, aparentemente, a proposta X-Med dá ênfase aos processos de Verificação do CMMI; (níveis) não mencionado em nenhuma das propostas; (lúdico) aspecto pouco explorado, pois as propostas utilizam simuladores, isto é, softwares capazes de reproduzir fielmente o comportamento do que se deseja estudar; (multimídia) ressaltada para o SimSE, os demais utilizam interface gráfica, com alguns recursos visuais, porém, não enfatizam o uso de multimídia, se utilizando muito mais de textos para a interface com o usuário; (remoto) aparentemente, somente a proposta CBT possui a possibilidade de utilização remota; (avaliação) a única proposta que avaliou a eficácia do jogo para o aprendizado foi a SE•RPG, as demais, quando ocorreu, avaliaram o interesse no uso do jogo.

6. Considerações Finais

O aprendizado de Engenharia de Software é desafiante tanto para alunos quanto para professores. A quantidade de propostas voltadas para o assunto nos últimos anos evidencia que têm-se buscado, mais enfaticamente, formas mais agradáveis e mais motivadoras de transmitir, aos futuros engenheiros, os reais desafios da área.

O uso de jogos parece ser uma alternativa viável para atingir esta meta, no entanto, precisam ser estabelecidos critérios que determinem suas características e avaliem a aplicabilidade de seus resultados. Apesar de seu desenvolvimento ainda estar bastante embrionário, pode evoluir de forma positiva, ajudando os alunos a compreenderem todas as dificuldades do desenvolvimento de software e a melhor se prepararem para os desafios que os esperam fora das salas de aula.

Referências

BAKER, A., NAVARRO, E. AND HOEK A. (2005) “An Experimental Card Game for Teaching Software Engineering Processes”. In: Journal of Systems and Software, v. 75, 1-2, pp. 3-16.

BANASCHAK, P. – Early East Asian Chess Pieces: An overview – 1999

BAND - Mercado de jogos eletrônicos não enfrenta crise. Reportagem da Band em 14/01/2009. Disponível em http://www.band.com.br/jornaldanoite/conteudo.asp?ID=121835&CNL=1

XXIII SBES - FEES

23

BATTAIOLA, A.L. - Jogos por Computador – Histórico, Relevância Tecnológica e Mercadológica, Tendências e Técnicas de Implementação - XIX Jornada de Atualização em Informática/SBC – 2000.

BENITTI, F. B. V.; MOLLÉRI, J. S. - Utilização de um RPG no Ensino de Gerenciamento e Processo de Desenvolvimento de Software - Anais do XXVIII Congresso da SBC – 2008.

CAVALCANTI, R. A. - Andragogia: A Aprendizagem nos Adultos - texto publicado na Revista de Clínica Cirúrgica da Paraíba n.6, ano 4, julho de 1999.

CEILIKAN – História dos Jogos de Tabuleiro. Disponível em http://www.ceilikan.com.br. Acesso em maio de 2009.

CHOTGUIS, J. Andragogia: arte e ciência na aprendizagem do adulto. NEAD - Universidade Federal do Paraná. Curitiba, Paraná, 2005.

DANTAS, A. R. - Jogos de Simulação no Treinamento de Gerentes de Projetos de Software- tese submetida à pós-graduação de Engenharia da UFRJ – dezembro/2003.

DRAPPA, A.; LUDEWIG, J (2000). Simulation in software engineering training. In Proceedings of The 22nd International Conference on Software Engineering - ICSE, pages 199-208, Limerick, Ireland.

KIELING, E., ROSA, R. Planager - Um Jogo para Apoio ao Ensino de Conceitos de Gerência de Projetos de Software. Trabalho de Conclusão de Curso de Ciência da Computação, FACIN, PUCRS, Porto Alegre, 2006.

KNOWLES, M.S. and ASSOCIATES. Andragory in Action: Applying Modern Principles of Adult Learning. San Francisco, 1985; ppxvi & 444.

MONTEIRO, E – Nativos Digitais já estão dominando o mundo e transformando a forma como o ser humano se comunica. Reportagem do O Globo de 18/05/2009. Disponível em: http://oglobo.globo.com/tecnologia/mat/2009/05/18/nativos-digitais-ja-estao-dominando-mundo-transformando-forma-como-ser-humano-se-comunica-755911408.asp. Acesso em maio de 1009.

PFAHL, D.; KLEMM, M.; RUHE, G. - Using System Dynamics Simulation Models for Software Project Management Education and Training (Extended Abstract) - ProSim2000, London, July 2000.

PRENSKY, M., 2001, Digital Game-Based Learning, McGraw-Hill.

PRESSMAN, R. Engenharia de Software. Editora McGrawHill, 2001.

PRIKLADNICKI, R.; WANGENHEIM, C.G. - O Uso de Jogos Educacionais para o Ensino de Gerência de Projetos de Software - FEES 2008

SCHWABER, K. Agile Project Management with Scrum. Microsoft Press, 2004.

VERONESE, G. O. - Sistematização do Desenvolvimento de Jogos de Simulação para Treinamento - tese submetida à pós-graduação de Engenharia da UFRJ – maio/2004.

WANGENHEIM, C.G. et al. - Desenvolvimento de um jogo para ensino de medição de software - SBQS 2009 - VIII SBQS - Junho/2009.

WIKIPEDIA – A História dos videogames. Disponível em http://pt.wikipedia.Org/wiki/ Hist%C3%B3r ia dos videogames. Acesso em maio de 2009.

XXIII SBES - FEES

24

Tratando Especificacao de Requisitos com EstudantesIniciantes de Programacao

Andrea Mendonca1, Danielle Chaves2, Dalton Guerrero1, Evandro Costa1

1Coordenacao de Pos-Graduacao em Ciencia da Computacao –Universidade Federal do Campina Grande (UFCG)

Caixa Postal 10.106 – 58.109-970 – Campina Grande – PB – Brasil

2Departamento de Sistemas e Computacao –Universidade Federal do Campina Grande (UFCG)

{andrea,danielle,dalton}@dsc.ufcg.edu.br, ebc@gmail.com

Abstract. In this paper, we report the application of a methodology of program-ming teaching to novice students that aims to develop the skills for problemsunderstanding and requirements specification. According to this methodology,students are confronted with ill-defined problems and they must specify, with aclient, what the program must do. The requirements inspection, using Defects-Based Reading Technique, revealed that the percentage of requirements docu-mented by students was higher than 88% and that the strategy to document testcases minimized the type of defects related to ambiguous and contradictory re-quirements.

Resumo. Neste artigo apresentamos a aplicacao de uma metodologia de ensinode programacao para iniciantes que tem por objetivo desenvolver as habilidadesdos estudantes para entendimento de problemas e especificacao de requisitos.Segundo esta metodologia, os estudantes sao confrontados com problemas maldefinidos e cabe a eles especificarem, junto a um cliente, os requisitos que oprograma deve atender para resolver o problema proposto. A inspecao dos re-quisitos, por meio da tecnica Defects-Based Reading, revelou que o percentualde requisitos documentados pelos estudantes foi superior a 88% e que a es-trategia de documentar casos de testes minimizou os tipos de defeitos referentesa requisitos ambıguos e contraditorios.

1. IntroducaoPesquisadores tem advertido a comunidade de educacao em computacao para as dificul-dades dos estudantes com entendimento de problemas e especificacao de requisitos, den-tre elas, citamos: dificuldades em identificar e eliminar ambiguidades em especificacoesde software [Blaha et al. 2005], perceber os diferentes nıveis de abstracao requeridos naresolucao de um problema [Hazzan 2008], identificar as informacoes relevantes para umprojeto de software e comunica-las adequadamente [Eckerdal et al. 2006].

Essas dificuldades, vivenciadas pelos estudantes no decorrer de sua formacao, re-fletem, posteriormente, em sua pratica profissional. Conn [Conn 2002] evidencia os pro-blemas que os estudantes enfrentam ao ingressarem na industria de software e chamaatencao para as deficiencias com especificacao de requisitos.

XXIII SBES - FEES

25

Embora sejam muitos os relatos que notificam as dificuldades dos estudantes comespecificacao de requisitos, esta atividade e tratada no currıculo dos cursos de computacaoapenas nas disciplinas de Engenharia de Software ou Analise de Sistemas, geralmentelocalizadas proximo ao final da graduacao. As disciplinas iniciais, por sua vez, focam nodesenvolvimento do raciocınio logico e construcao de programas.

Essa estrutura curricular nao apenas retarda o desenvolvimento dessas habilidades,como tambem contraria a forma canonica de resolucao de problemas, na qual, primeira-mente, entende-se o problema e somente depois soluciona-o.

Preocupados com esta problematica e confiantes de que melhorias na formacaopodem ser obtidas se a especificacao de requisitos for tratada desde o inıcio da graduacao,nos concebemos e aplicamos uma metodologia de ensino de programacao para iniciantes,denominada Programacao Orientada ao Problema (POP), que tem por objetivo desen-volver as habilidades para entendimento de problemas e especificacao em conjunto comas habilidades de programacao.

Neste artigo, nos relatamos a metodologia adotada, sua implementacao em umadisciplina de programacao para iniciantes e os resultados obtidos com a especificacao deum problema mal definido.

2. Programacao Orientada ao Problema (POP)De forma sucinta, POP consiste em propor aos estudantes problemas mal definidos1 ecabe a eles especificarem, junto a um cliente, os requisitos que o programa deve atenderpara resolver o problema proposto. Em POP, o cliente assume dupla funcao: (i) clientepara responder aos questionamentos dos estudantes com relacao aos requisitos; e (ii) tutorpara orientar os estudantes na realizacao das atividades. Em funcao disso, o chamamosde cliente-tutor.

Ao serem confrontados com um problema mal definido, os estudantes devem re-alizar uma leitura exploratoria do enunciado buscando extrair as informacoes relevan-tes e identificar aquelas que sao ambıguas, contraditorias, irrelevantes, incorretas e/ouinformacoes que foram omitidas. Essa atividade possibilita aos estudantes ter um enten-dimento inicial do problema, identificar alguns requisitos que o programa deve atender eregistra-los no documento de especificacao.

A medida que os requisitos vao sendo identificados, os estudantes devem trabalharpara refinar sua compreensao do problema. Ou seja, eles devem analisar mais detalhada-mente os requisitos a fim de descobrir, por exemplo, suas restricoes.

Uma das estrategias utilizadas para detalhamento dos requisitos, consiste no esta-belecimento de um dialogo entre estudantes e cliente-tutor que vai se tornando, progres-sivamente, mais estruturado, conforme ilustrado na Figura 1. Inicialmente, os estudantescomecam a interacao de maneira livre – perguntas e respostas (a), e, posteriormente, vaodialogando na forma de casos de testes de entrada e saıda (b) e na forma de asserts2 (c).Em POP, os testes (entrada e saıda e asserts) sao entendidos como uma pergunta quequestiona e/ou confirma com o cliente-tutor os requisitos e restricoes do problema. Porestarem escritas de forma mais sucinta e estruturada, os testes removem as ambiguidadese contradicoes, muitas vezes comuns no dialogo em linguagem natural.

1Problemas que possuem, intencionalmente, em seu enunciado, ambiguidades, contradicoes, falta deinformacoes, informacoes irrelevantes e/ou incorretas.

2Um comando da linguagem Python que permite a criacao de testes automaticos.

XXIII SBES - FEES

26

Figura 1. Progredindo do dialogo livre para um dialogo mais estruturado.

E comum que requisitos sejam descobertos e/ou melhor detalhados a medida queos estudantes vao construindo a solucao do problema (programa). A implementacao con-tribui para o enriquecimento da interpretacao e analise dos requisitos e realimenta asinteracoes para a especificacao. Em POP, esse desenvolvimento iterativo e incrementale levado em consideracao.

Diferente das metodologias tradicionais de ensino de programacao que focamapenas no espaco da solucao3, POP propoe o desenvolvimento das habilidades deespecificacao (espaco do problema) em conjunto com as de programacao, proporcio-nando aos estudantes vivenciarem “as idas e vindas” naturais no processo de resolucaode problemas. Ao exercitarem as atividades previstas em POP, os estudantes trabalhamna producao de tres artefatos – documento de especificacao, programa e casos de testes.Neste artigo, apresentamos a analise dos documentos produzidos pelos estudantes para aespecificacao de um problema mal definido.

Essa metodologia tem sido adotada, desde o segundo semestre academico de 2008,na disciplina de programacao para iniciantes do curso de Ciencia da Computacao da Uni-versidade Federal de Campina Grande (UFCG). Python e a linguagem de programacaoadotada na disciplina.

3. Aplicacao de POP com Alunos Iniciantes de ProgramacaoNesta secao, nos descrevemos a aplicacao de POP com os estudantes. Por uma limitacaode espaco, apresentaremos apenas um dos problemas propostos, cujo enunciado e descritona Secao 3.1. Posteriormente, descrevemos a forma como POP vem sendo aplicada nadisciplina de programacao (Secao 3.2).

3.1. O Problema PropostoEnunciado. Em funcao da crise financeira mundial tem crescido os investimentos na poupancaprogramada, pois e um investimento rentavel e com baixıssimo risco. Um professor deadministracao financeira da UFCG deseja simular investimentos na poupanca programada paraensinar seus alunos a driblarem a crise. Faca um programa que atenda a solicitacao desse pro-fessor, considerando que a poupanca rende 5% ao mes, sendo tempo e capital programados peloinvestidor com isencao total do imposto de renda.

Este problema apresenta, intencionalmente, falta de informacoes, ambiguidades e

informacoes irrelevantes.

Falta de informacao Nao sao informados no problema quais sao as entradas, saıdas e como elasdevem ser formatadas; quais os calculos que devem ser efetuados e as restricoes que o programa deveobedecer. Tambem nao esta claro se a poupanca tem rendimento fixo;

3Aprendizagem de uma linguagem de programacao, desenvolvimento do raciocınio logico e construcaode programas.

XXIII SBES - FEES

27

Ambiguidades A expressao “sendo tempo e capital programados pelo investidor com isencaototal do imposto de renda” refere-se ao fato de que a poupanca programada e um investimento que temisencao do imposto de renda? ou, que somente pode aplicar na poupanca o investidor isento do imposto derenda?

Informacoes irrelevantes A frase inicial que fala da crise mundial e desnecessaria para o enten-dimento e resolucao do problema. Ela foi inserida apenas para deixar o problema mais interessante.

3.2. Aplicacao de POP na Disciplina de ProgramacaoPOP foi aplicada em duas turmas da disciplina de programacao para iniciantes do curso de Ciencia

da Computacao da UFCG. As duas turmas totalizavam 70 alunos, os quais foram divididos em

grupos compostos por 5 ± 2 estudantes.

Para cada grupo foi designado um cliente-tutor. Cada cliente-tutor recebeu, previamente,

orientacoes sobre como proceder. Foi entregue a cada cliente-tutor uma especificacao e um con-

junto de casos de testes de referencia. Com bases neles, os clientes-tutores respondiam aos ques-

tionamentos dos estudantes.

O Google Docs foi o editor de texto colaborativo utilizado para registrar as especificacoes

dos requisitos. Alem disso, listas de discussoes foram criadas no Google Groups para permi-

tir interacoes entre estudantes e cliente-tutor fora do horario de aula. Ambos os recursos eram

restritos aos membros do grupo e seu respectivo cliente-tutor.

A especificacao dos requisitos foi realizada em grupo e a implementacao do programa

realizada individualmente. Desta forma, os estudantes poderiam reforcar a aprendizagem da sin-

taxe da linguagem, o desenvolvimento do raciocınio logico e a construcao de programas, ficando

livres para definir o design do codigo. Alem disso, ao final, os estudantes poderiam verificar como

programas construıdos de diferentes maneiras atendiam a mesma especificacao.

POP foi executada da seguinte forma: primeiramente, cada grupo teve uma reuniao pre-

sencial de duas horas com o cliente-tutor, nessa reuniao foi produzida uma versao inicial do do-cumento de especificacao. Com base nessa especificacao inicial, os estudantes, individualmente,

trabalharam na construcao de um programa para atende-la. Ao construırem essa versao do pro-

grama, surgiram novos questionamentos que foram tratados via lista de discussao e permitiram

atualizacao do documento de especificacao. Um segundo encontro presencial foi estabelecido en-

tre cliente-tutor e estudantes para produzir uma versao final do documento de especificacao. Neste

caso, os estudantes, reunidos com seu respectivo grupo, utilizaram os programas e casos de testes

para confirmarem e descobrirem novos requisitos. Apos esta data, cada estudante trabalhou na

versao final de seu programa para atender a especificacao. Alem disso, produziram um conjunto

de casos de testes, escritos em asserts, para atestar a qualidade do programa produzido.

4. Avaliacao das Especificacoes Produzidas pelos EstudantesNesta secao, apresentamos os procedimentos adotados para analise das especificacoes, reportamos

e discutimos os resultados obtidos.

4.1. ProcedimentosPara avaliar os documentos de especificacao produzidos pelos estudantes, nos utilizamos uma

tecnica de inspecao de requisitos denominada tecnica de leitura baseada em defeitos (Defect-BasedReading – DBR) [Porter et al. 1995].

Para definir os tipos de defeitos que deveriam ser observados, nos adotamos uma versao

simplificada da taxonomia de defeitos4 definida por Shull, Rus e Basili [Shull et al. 2000] que e

apresentada na Tabela 1.

4Um defeito e uma falha no requisito do sistema que pode levar o software a comportar-se de umamaneira indesejada [Shull 1998].

XXIII SBES - FEES

28

Tabela 1. Taxonomia de Defeitos.Tipo Descricao

Informacao Omitida Alguma informacao que foi omitida no documento deespecificacao.

Informacao Ambıgua Alguma informacao que foi descrita no documento deespecificacao de forma ambıgua, causando duplo sentido.

Informacao Contraditoria Duas informacoes que se contradizem mutuamente ou expressaoacoes que nao podem ser ambas corretas.

Informacao Incorreta Alguma informacao que consta no documento de requisitos, masnao descreve corretamente o problema.

Informacao irrelevante Alguma informacao que consta no documento de requisitos, masnao e importante, necessaria ao entendimento do problema.

Cada documento foi inspecionado por duas pessoas. Na primeira etapa de avaliacao, cada

inspetor avaliou individualmente os documentos e contabilizou os defeitos observados. Apos a

avaliacao individual, foi realizada uma avaliacao conjunta e nos casos em que houve divergencia

no numero e tipo de defeitos identificados, os inspetores entraram em consenso, produzindo uma

avaliacao final para cada documento de especificacao.

4.2. Resultado das Avaliacoes

Conforme definido no documento de especificacao de referencia, o programa para resolver o pro-

blema proposto (Secao 3.1) teria que atender a 17 requisitos.

Na inspecao dos documentos avaliamos se esses requisitos tinham sido documentados e

tambem se eles tinham sido documentados corretamente, isto e, nao apresentavam os tipos de

defeitos mencionados na Tabela 1.

A Figura 2 apresenta as porcentagens de requisitos documentados e de requisitos docu-

mentados corretamente pelos estudantes das Turmas 1 e 2, respectivamente. A Turma 1 foi dividia

em 8 grupos e a Turma 2 em 7. Todos os grupos das duas turmas documentaram mais de 80% dos

requisitos. Sendo que 7 grupos documentaram 100% dos requisitos (Grupos 3, 4 e 7 da Turma

1 e Grupos 1, 2, 4 e 7 da Turma 2). Desses grupos que documentaram 100% dos requisitos,

apenas o grupo 3 da Turma 1 e o grupo 7 da Turma 2 documentaram todos os requisitos corre-

tamente. No caso do grupo 1 da Turma 2, dos 100% de requisitos documentados, apenas 76,4%

deles foram documentados corretamente. Esse grupo apresentou a porcentagem mais baixa de

requisitos corretamente documentados. Ha casos que merecem destaque, por exemplo, o grupo 3

da Turma 2 documentou apenas 88,2% dos requisitos, sendo que todos eles foram documentados

corretamente.

Figura 2. Turma 1 e 2 – Requisitos Documentados e Requisitos DocumentadosCorretamente.

XXIII SBES - FEES

29

A Figura 3 apresenta a porcentagem dos tipos de defeitos encontrados nos documentos de

especificacao das Turmas 1 e 2. Nas duas turmas, os defeitos mais frequentes foram informacaoomitida e informacao incorreta. No que diz respeito ao tipo de defeito informacao incorreta,

verificamos que foi comum os estudantes documentarem, erroneamente, o tipo de mensagem que

deveria ser exibida em caso de erro na leitura dos valores de entrada, conforme exemplificado no

Quadro 1.

Figura 3. Tipos de Defeitos.

Quadro 1: Turma 1 – Grupo 7: Especificacao Incorreta – Mensagem de Erro.

Mensagem que deve ser exibida para entrada invalida de Tempo

Mensagem de erro esperada pelo cliente:Perıodo de tempo de 02 a 48 meses

Mensagem de erro especificada pelo grupo:Tempo mınimo de 2 meses

O registro de casos de testes de entrada e saıda no documento de especificacao minimizou

a porcentagem de outros tipos de defeitos, como por exemplo, ambiguidades e contradicoes. Isso

ocorreu porque os casos de testes sao descritos de maneira mais estruturada e conseguem explicitar

varios requisitos de maneira concisa. A Figura 4 mostra como dois casos de testes foram utilizados

para especificar diferentes requisitos.

Ainda tratando da especificacao de requisitos por meio de testes, a Figura 5 apresenta a

porcentagem de requisitos cobertos pelos casos de testes de entrada e saıda documentados pelos

estudantes. Na Turma 2, essa estrategia foi adotada por apenas 3 grupos, cujos testes de cada

grupo cobriram mais de 50% dos requisitos. Na Turma 01, essa estrategia foi mais utilizada e os

grupos conseguiram cobrir mais de 70% dos requisitos.

4.3. DiscussaoA situacao expressa no Quadro 1 evidencia a necessidade de alertar os estudantes para o deta-

lhamento dos requisitos nao funcionais. No caso do tipo de defeito informacao omitida, verifi-

camos que alguns grupos ao interagirem, via lista de discussao, nao atualizaram o documento de

especificacao, confiando no registro que havia sido feita na lista.

Uma dificuldade manifestada pelos estudantes foi a criacao dos testes automaticos com

uso de asserts. Muitos estudantes garantiram a qualidade do codigo baseando-se nos testes de

entrada e saıda, descritos no documentados de especificacao.

XXIII SBES - FEES

30

Figura 4. Turma 1 – Grupo 2: Casos de Testes.

Figura 5. Requisitos cobertos pelos casos de testes de entrada e saıda.

Pelos resultados obtidos, nossa avaliacao com respeito a POP e de que essa metodologia

tem possibilitado resultados promissores no desenvolvimento das habilidades dos estudantes para

lidar com problemas mal definidos.

Envolver os estudantes, desde o inıcio da graduacao, em atividades de entendimento de

problemas e de especificacao permite a eles vivenciarem situacoes mais proximas do mundo real

e desenvolverem habilidades que sao transferıveis para outras disciplinas do currıculo, tais como,

Banco de Dados, Analise de Sistemas, Engenharia de Software e Inteligencia Artificial.

5. Validade do Estudo e Melhorias de POPDe acordo com a organizacao da UFCG, alunos repetentes de programacao concentram-se em uma

turma (Turma 3) a qual recebe assistencia mais direcionada. Os resultados reportados nesse artigo

sintetizam apenas os dados obtidos das Turmas 1 e 2. Essa organizacao assegura que a experiencia

dos alunos repetentes nao influenciaram nos resultados reportados.

Para evitar interferencias por parte dos clientes-tutores na elaboracao do documento de

especificacao, eles receberam, previamente, as orientacoes necessarias a aplicacao de POP. Estes

cuidados aumentam a confianca de que fatores externos nao teriam influencia sobre os resultados.

Varias fontes de dados foram coletadas (programas, documentos de especificacao, casos de testes

e dialogos) a fim de evitar que julgamentos “subjetivos” interferissem na analise dos resultados.

No que diz respeito a validade externa, esse estudo nao teve por objetivo estabelecer

generalizacoes, mas sim adquirir informacoes que nos permita melhorar a efetividade de POP.

XXIII SBES - FEES

31

A partir dos resultados obtidos com esse estudo, pretendemos intensificar a utilizacao de

problemas mal definidos na disciplina e melhorar as orientacoes aos clientes-tutores no que diz

respeito a forma de conduzir as atividades em sala de aula e prover feedback de acompanhamento

aos estudantes.

6. Consideracoes FinaisNeste artigo, nos apresentamos uma metodologia, denominada Programacao Orientada ao Pro-blema (POP), e sua aplicacao em duas turmas da disciplina de programacao para iniciantes do

curso de Ciencia da Computacao da UFCG.

Com a adocao de POP e possıvel antecipar para o contexto de estudantes iniciantes de

programacao o desenvolvimento das habilidades para entendimento de problemas e especificacao

de requisitos. A antecipacao destas habilidades tem despertado o interesse da comunidade de

Educacao em Engenharia de Software que vem discutindo estrategias para minimizar o gap entre

universidade e industria de software [Lethbridge et al. 2007]. Colabora tambem para essa reflexao

uma orientacao da Joint Task Force on Computing Curricula [ACM/IEEE 2004] que diz que mui-

tos conceitos e princıpios da Engenharia de Software devem ser ensinados como temas recorrentes

durante todo o currıculo e a distribuicao curricular deve possibilitar a progressiva expansao e apro-

fundamento desses temas.

ReferenciasACM/IEEE (2004). Software Engineering 2004,Curriculum Guidelines for Undergraduate De-

gree Programs in Software Engineering.

Blaha, K., Monge, A., Sanders, D., Simon, B., and VanDeGrift, T. (2005). Do students recognize

ambiguity in software design? a multi-national, multi-institutional report. In ICSE ’05: Pro-ceedings of the 27th international conference on Software engineering, pages 615–616, New

York, NY, USA. ACM.

Conn, R. (2002). Developing software engineers at the c-130j software factory. IEEE Softw.,19(5):25–29.

Eckerdal, A., McCartney, R., Mostrom, J. E., Ratcliffe, M., and Zander, C. (2006). Can graduating

students design software systems? SIGCSE Bull., 38(1):403–407.

Hazzan, O. (2008). Reflections on teaching abstraction and other soft ideas. SIGCSE Bull.,40(2):40–43.

Lethbridge, T. C., Diaz-Herrera, J., LeBlanc, R. J. J., and Thompson, J. B. (2007). Improving

software practice through education: Challenges and future trends. In FOSE ’07: 2007 Futureof Software Engineering, pages 12–28, Washington, DC, USA. IEEE Computer Society.

Porter, A. A., Votta, Jr., L. G., and Basili, V. R. (1995). Comparing detection methods for software

requirements inspections: A replicated experiment. IEEE Trans. Softw. Eng., 21(6):563–575.

Shull, F., Rus, I., and Basili, V. (2000). How perspective-based reading can improve requirements

inspections. Computer, 33(7):73–79.

Shull, F. J. (1998). Developing Techniques for Using Software Documents: A Series of EmpiricalStudies. PhD thesis, University of Maryland. Department of Computer Science.

XXIII SBES - FEES

32

Portal EduES Brasil: Um Ambiente para Apoiar a Pesquisa em Educação em Engenharia de Software no Brasil

Rafael E. Santo, Rodrigo Santos, Cláudia Werner, Guilherme Travassos

COPPE/UFRJ, Universidade Federal do Rio de Janeiro, Brasil Caixa Postal 68511 – CEP 21945-970 – Rio de Janeiro, RJ

{res,rps,werner,ght}@cos.ufrj.br

Abstract. The education of human resources in Software Engineering (SE) depends on the researches related to underlying teaching and learning process. Despite the initiatives to improve SE education, there is a lack of integration to understand its issues in the Brazilian scenario. In this sense, this paper presents EduES Brasil Portal, a web environment to join the community interested in SE educational process, focusing on primary and secondary experimental studies and on organizing a body of knowledge that considers particularities of SE education in Brazil.

Resumo. O sucesso da formação de recursos humanos em Engenharia de Software (ES) está relacionado ao empenho e compreensão de seu processo de ensino e aprendizagem. Apesar da existência de iniciativas para melhorar a educação em ES, estas não são integradas, de forma a viabilizar o entendi-mento dos problemas do cenário nacional. Nesse sentido, este artigo apre-senta o Portal EduES Brasil, desenvolvido com o objetivo de integrar a comu-nidade interessada no processo educacional de ES, com foco na execução de estudos experimentais primários e secundários e na organização de um corpo de conhecimento que considere o cenário nacional.

1. Introdução

O sucesso do processo de formação de recursos humanos em Engenharia de Software (ES), assim como em outras áreas da Ciência da Computação (CC), está intimamente relacionado às pesquisas de seu processo de ensino e aprendizagem. No contexto da ES, as primeiras iniciativas dessas pesquisas ocorreram nos cursos de CC [Lethbridge et al., 2007]. Apesar disso, não existiu um esforço integrado da comunidade acadêmica na identificação e elaboração de propostas de solução para os problemas relacionados à educação em ES, de maneira que transcendesse apenas a documentação de corpo de conhecimento estático e não representativo das particularidades da área [Hiebert et al.,2002]. Adicionalmente, os conceitos ensinados muitas vezes não são suficientes para formar uma base conceitual e prática necessária para enfrentar os desafios referentes ao desenvolvimento de produtos de software na indústria.

Com o intuito de prover mecanismos que facilitem o processo de ensino e aprendizagem, o paradigma experimental, que envolve a coleção e análise de dados e evidências, pode ser utilizado para caracterizar, avaliar e revelar relacionamentos entre tecnologias, práticas e resultados do processo de ensino e aprendizagem de ES [Santos et al., 2008a]. A utilização de estudos experimentais contribui para a formação de um corpo de conhecimento efetivo [Basili et al., 1999], o que favorece a formulação de teorias mais bem consolidadas sobre a educação em ES. Visando auxiliar a formação deste corpo de conhecimento, o Projeto EduES Brasil constitui uma estratégia de apoio a pesquisa experimental direcionada à identificação de problemas, soluções, desafios e

XXIII SBES - FEES

33

peculiaridades do cenário nacional no escopo da educação em ES [Werner et al., 2009]. Nesse contexto, este artigo apresenta o Portal EduES Brasil, um ambiente web para apoiar a pesquisa experimental em educação em ES no Brasil, construído a partir da estratégia de pesquisa descrita em [Santos et al., 2008b] e inicialmente focado nas eta-pas Revisão Sistemática da Literatura e Pesquisa de Opinião (survey). Este portal busca facilitar a participação e integração da comunidade interessada nas questões relaciona-das ao processo de ensino e aprendizagem de ES. O artigo está estruturado da seguinte forma: a Seção 2 discorre sobre o Projeto EduES Brasil; a Seção 3 apresenta o Portal EduES Brasil e suas funcionalidades; e a Seção 4 exibe as considerações finais.

2. Estratégia de Apoio à Pesquisa Experimental em Educação em ES

Há um crescente interesse em direção à utilização de experimentação em ES de uma maneira geral [Shull et al., 2001]. Os objetivos da execução de experimentos em ES consistem na caracterização, avaliação, controle e melhoria de produtos, processos, re-cursos, modelos e teorias, entre outros [Travassos et al., 2002]. Com base nisso, o Projeto EduES Brasil contempla uma estratégia de pesquisa colaborativa e em larga escala sobre educação em ES focada em experimentação. Essa estratégia propõe a utili-zação de estudos experimentais primários (survey) e secundários (revisão sistemática) com o intuito de estabelecer, fundamentar e integrar as pesquisas relacionadas à educa-ção em ES de forma colaborativa, distribuída e especializada.

Duas comunidades foram identificadas: educadores (professores de disciplinas na área de ES) e pesquisadores em educação em ES (pesquisadores em tópicos de ES que passam a expandir o escopo de suas pesquisas a fim de contribuir para a educação destes tópicos). Além disso, essa comunidade de pesquisadores seria organizada em áreas de pesquisa, visando agregar diferentes perspectivas provenientes de diversos cenários rumo à organização conjunta de um corpo de conhecimento. Inicialmente, cada área de pesquisa estaria focada na identificação de problemas, soluções, desafios e pe-culiaridades do cenário nacional no ensino e aprendizagem do tópico de ES relacionado. Essa estratégia foi derivada da proposta de Spínola et al. (2008) relativa ao desenvolvi-mento de novas tecnologias em ES e adaptada para o contexto de manutenção de tec-nologias e processos para a educação, prevendo a condução de pesquisas por meio de quatro etapas, conforme mostrado na Tabela 1 e na Figura 1.

Tabela 1 – Etapas do Projeto EduES BrasilETAPA OBJETIVO Revisão

Informal da Literatura

Identificar os conceitos básicos sobre a pesquisa em educação em ES, permitindo a formulação de um protocolo de revisão sistemática mais preciso e abrangente para cada um dos tópicos abrangidos por cada área de pesquisa.

Revisão Sistemática

da Literatura

Elaborar e executar o protocolo de revisão sistemática. Baseado nos resultados obti-dos a partir da análise dos artigos identificados, o conjunto de pesquisadores envolvi-dos em uma área de pesquisa define se é necessário refinar o estudo executado. Caso positivo, este passo é repetido. Caso contrário, é decidido se o conjunto de conheci-mento obtido deve ser avaliado por meio de um survey ou não.

Pesquisa de Opinião

Planejar e executar um survey para avaliar o conhecimento adquirido na etapa de revisão sistemática junto à comunidade de educadores, com foco no cenário nacional.

Organização do Corpo de

Conhecimento

Reunir os conhecimentos obtidos na revisão sistemática e no survey visando organizar um corpo de conhecimento em educação em ES. A estruturação de um repositório de informações visa servir de guia para o compartilhamento de experiências de ensino.

A primeira etapa da estratégia de pesquisa foi abordada em [Santos et al., 2008a] e um exemplo de plano de pesquisa de opinião em [Schots et al., 2009], considerando

XXIII SBES - FEES

34

os aspectos que permeiam a educação em ES de uma maneira geral. As etapas Revisão Sistemática da Literatura e Pesquisa de Opinião são tratadas com a utilização do Portal EduES Brasil, de forma que este sirva como uma infra-estrutura de apoio à execução de estudos experimentais. No futuro, o portal poderá organizar e manter um corpo de co-nhecimento dinâmico e focado na realidade nacional. Com isso, espera-se que a comu-nidade de pesquisadores envolvidos nas questões de ensino e aprendizagem de ES inte-raja na condução de estudos experimentais para que os resultados obtidos possam ser discutidos nas edições do Fórum de Educação em Engenharia de Software (FEES), um evento então voltado para a integração presencial entre as comunidades envolvidas.

Figura 1 –Estratégia de Pesquisa Experimental [Santos et al., 2008a]

3. Portal EduES Brasil

O objetivo do Portal EduES Brasil é possibilitar uma maior integração da comunidade de pesquisadores e educadores de ES no Brasil, através de uma estratégia de pesquisa baseada em experimentação para organizar um corpo de conhecimento. O portal possi-bilitará o gerenciamento de conteúdos de interesse, facilitará a comunicação dos usuá-rios do portal e condução de estudos experimentais relacionados à educação em ES em um ambiente integrado. A partir de um estudo realizado para avaliar as tecnologias existentes, optou-se por construir o ambiente web baseado na plataforma Java Enterprise Edition usando o framework JBoss Seam [JBoss, 2009] com a preocupação de investigar componentes que pudessem ser integrados ao portal. O ambiente será hos-pedado no servidor do Laboratório de Engenharia de Software da COPPE/UFRJ e pre-tende apoiar a realização das quatro etapas apresentadas na Seção 2, cada uma das quais composta por um conjunto de macro e micro-atividades que tratam questões minuciosas da área de Experimentação [Travassos et al., 2002].

Espera-se que o portal sirva como um repositório de conhecimento baseado em estudos experimentais em educação em ES, a partir da identificação de aspectos que permeiam o seu processo de ensino e aprendizagem nos seus diversos tópicos. Ou seja, após a organização das comunidades envolvidas e a caracterização da educação em ES, o portal manterá uma rede conceitual que relacione problemas, soluções, desafios e pe-culiaridades do cenário nacional identificados em estudos experimentais pelos pesquisadores de cada área de pesquisa. Assim, questões de pesquisa não especulativas poderão ser delineadas e esses pesquisadores, em suas respectivas áreas, poderão se organizar para desenvolver as pesquisas (ferramentas, jogos, metodologias etc.). Por sua vez, a comunidade de educadores poderá usufruir dos resultados obtidos, com o com-prometimento de retornar ao portal um conjunto de dados solicitados pelos pesquisadores responsáveis, a fim de colaborar para a evolução das pesquisas e para a divulgação científica. Isso requer que mecanismos para recuperação de relatos de expe-

XXIII SBES - FEES

35

riências (sucessos, fracassos etc.) sejam agregados ao portal e apóiem à nova (quinta) etapa da estratégia: manutenção da estratégia de pesquisa.

Em nível de projeto, os usuários do portal são classificados por papéis (Tabela 2) para diferenciar o conteúdo disponível para acesso. Esses também são classificados por facetas, que no futuro serão úteis para a execução de estudos experimentais que explorem as características dos participantes (e.g., titulação, profissão, instituição). Os usuários que desejam obter acesso às funcionalidades restritas do portal deverão efetuar o seu cadastro. Porém, a avaliação dos pedidos de acesso será de responsabilidade da equipe de administração do portal. Além disto, os pesquisadores poderão convidar no-vos usuários através do envio de convites de acesso.

Tabela 2 – Descrição dos papéis do Portal EduES Brasil PAPEL DESCRIÇÃO Visitante Usuário não autenticado no portal. Usuário Comum

Usuário que deseja participar de listas de discussão, fórum, acessar materiais do por-tal (e.g., artigos) e realizar comentários sobre artigos publicados no FEES.

Educador

Usuário participante de estudos experimentais. Este usuário será selecionado de pelo coordenador de um estudo experimental do tipo survey, com o intuito de colaborar com a verificação dos resultados de um estudo experimental do tipo revisão sistemá-tica ao preencher uma pesquisa de opinião. Além disso, este usuário poderá buscar e utilizar recursos educacionais referentes a produtos de pesquisa contidos no portal, visando contribuir para uma base de experiência.

Pesquisador

Usuário responsável pela condução de estudos experimentais. Este usuário participará das áreas de pesquisa (em que atua) que realizam estudos experimentais instanciados pelo coordenador, além de participar da organização de surveys. Além disso, este usuário poderá investigar questões de pesquisas contidas no corpo de conhecimento e contribuir com recursos educacionais para a base de experiência do portal.

Coordenador Pesquisador responsável pelo acompanhamento direto de um estudo experimental em uma área de pesquisa (i.e., organiza a realização de revisões sistemáticas e surveys). Supervisiona micro-atividades de cada macro-atividade de um estudo experimental.

Revisor Responsável por supervisionar as macro-atividades e verificar as informações e re-sultados gerados pelos estudos experimentais conduzidos por uma área de pesquisa.

Gerente Usuário que coordena o Projeto EduES Brasil, supervisiona o fluxo de execução das etapas da estratégia de pesquisa e inicia o processo de execução de estudos experi-mentais. Possui também atribuições de administrar conteúdos de interesse.

Administrador Responsável pelo gerenciamento de conteúdo e estrutura do portal.

O foco inicial da construção do portal está sobre as três primeiras etapas da es-tratégia de pesquisa, visando gerar uma base para que mecanismos mais elaborados pos-sam ser construídos e embasem a quarta e quinta etapas, a posteriori. Inicialmente, a estratégia de pesquisa será instanciada de maneira a ocorrer à execução da segunda etapa, revisão sistemática da literatura, com o intuito de identificar artigos relacionadosaos diferentes tópicos de ES previamente definidos no portal e alocados aos coordenadores de cada área de pesquisa. Cinco macro-atividades definidas por Biolchini et al. (2007) serão planejadas, instanciando-se um protocolo de investigação científica padrão preliminarmente estruturado em [Santos et al., 2008a] e reorganizadas como um processo para sua execução: formulação da questão de pesquisa, seleção das fontes, seleção dos estudos, extração da informação e sumarização dos resultados.

Após a conclusão da etapa revisão sistemática da literatura pelos diferentes conjuntos de pesquisadores, o gerente e a equipe de revisores poderão disparar a etapa pesquisa de opinião. Esta pesquisa de opinião consiste de um survey on-line geral que confronte os resultados provenientes das revisões sistemáticas com uma amostra da co-munidade de educadores de ES, abrangendo os principais aspectos que permeiam a

XXIII SBES - FEES

36

educação de cada uma das áreas de pesquisa em ES definidas previamente no portal. Dessa forma, esta pesquisa de opinião será composta por questionamentos extraídos daqueles apontados pelos conjuntos de pesquisadores e organizados pela equipe de revisores. Por outro lado, caso haja necessidade de se investigar mais detalhadamente os aspectos de alguma área de pesquisa em particular, os respectivos coordenadores pode-rão solicitar ao portal a execução de pesquisas de opinião específicas com a comunidade de educadores. Esse passo poderá ser executado através da escolha de grupos de educadores segundo critérios definidos pelo gerente e sua equipe de revisores (survey geral) ou pelo coordenador (survey específico) para a construção e realização deste es-tudo, ambas as situações apoiadas pelo portal.

3.1. Estrutura do Portal

A estrutura do Portal EduES Brasil contém módulos (Figura 2) que apóiam a organiza-ção de conteúdos de interesse e que permitem a comunicação, coordenação e colabora-ção de comunidades de pesquisa, além da condução da segunda e terceira etapas da es-tratégia de pesquisa. O acesso aos módulos do portal foi dividido em duas partes (Figura 3), representadas em menus de acesso e agrupadas por visões que considerem os diferentes papéis. A primeira parte corresponde às funcionalidades de uso comum a todos os usuários do portal, cujas opções são: acesso ao conteúdo explicativo da estraté-gia de pesquisa, notícias, eventos, links de interesse, cadastro de publicações (artigos, relatórios técnicos, apresentações, conteúdo multimídia etc.) e contato com a equipe de administração do portal. Além destas, existe a opção de gerenciamento do conteúdo relacionado às edições do evento FEES, que passará a conter os artigos e as apresenta-ções dos trabalhos apresentados em cada edição de forma a centralizar todo o conteúdo em um único ambiente. A administração deste conteúdo estará a cargo dos usuários que possuam os papéis de administrador, gerente ou pesquisador (definido como chair do evento). Por fim, será possível fazer comentários sobre os trabalhos apresentados, de forma a gerar discussões sobre os temas abordados.

Figura 2 – Módulos do Portal EduES Brasil

A segunda parte estará disponível somente aos usuários que tenham sido apro-vados pela equipe de administração. Entre as opções disponíveis estão: envio de mensa-gens para usuários e membros de áreas de pesquisa gerenciadas pelo portal (com possi-bilidade de receber e responder mensagens a partir do e-mail fornecido durante o ca-dastro), e participação em chats (através da integração do componente JChatBox[JavaZOOM, 2009]), fórum (por meio do componente JForum [JForum, 2009]) e listas de discussão. O portal organizará os pesquisadores em áreas de pesquisa e a supervisão de cada uma delas será desempenhada por um de seus pesquisadores, definido como coordenador, permitindo a organização de estudos experimentais de forma colaborativa (entre diferentes pesquisadores), distribuída (entre diferentes instituições) e especiali-

XXIII SBES - FEES

37

zada (por especialistas de cada área da ES) (Seção 3.2); a atribuição do papel de coordenador é realizada inicialmente pelo gerente e pode ser alterada pelo coordenadoratual. Dentre as responsabilidades do coordenador, está a gestão da execução das tare-fas dos pesquisadores envolvidos (e educadores, no caso de estudos primários) em es-tudos experimentais. Por fim, a equipe de administração do portal será responsável pela criação de chats, gerenciamento do fórum e de listas de discussão (gerais e por área de pesquisa), gerenciamento de usuários e cadastro de instituições de ensino. Essa equipe gerenciará o cadastramento de notícias, eventos, links, publicações, edições do FEES e manutenção do conteúdo da estratégia de pesquisa, além de poder desempenhar todas as funções disponíveis aos demais papéis contemplados pelo portal.

Figura 3 – Menus de acesso do Portal EduES Brasil

3.2. Estruturação de Estudos Experimentais

O Portal EduES Brasil provê a condução de estudos experimentais ao oferecer uma infra-estrutura que auxilie a execução das macro e micro-atividades de cada uma das etapas envolvidas na estratégia de pesquisa, de forma coordenada e sistematizada, além de permitir o rastreamento dos processos que levaram a um determinado resultado. Isso facilita o compartilhamento e a compreensão do processo científico por diversos pesquisadores [Mattoso et al., 2008]. A cada macro-atividade realizada em cada um dos estudos experimentais instanciados e relacionados a alguma das etapas da estratégia de pesquisa, um revisor terá a tarefa de verificar as informações geradas pelos conjuntos de pesquisadores envolvidos e/ou por educadores (no caso de estudos experimentais pri-mários do tipo survey), e definir, em conjunto com o coordenador, se a próxima macro-atividade do estudo deve ser atingida ou se o processo precisa ser refinado. A comuni-cação dos envolvidos em um dado experimento será realizada por meio de mensagens dentro do portal e pela participação em salas de chat e em tópicos do fórum.

O processo relacionado à condução de revisões sistemáticas em cada área de pesquisa está exibido na Figura 4. Cada macro-atividade é composta por micro-ativida-des que refinam a sua execução. O processo de execução de revisões sistemáticas será iniciado pelo gerente e a sua continuidade estará a cargo do coordenador de cada área de pesquisa, em conjunto com os pesquisadores envolvidos. Seguindo o processo, um protocolo de revisão sistemática será construído a partir de um documento template que será disponibilizado aos pesquisadores, que poderão discutir as informações relaciona-

XXIII SBES - FEES

38

das ao plano do estudo utilizando a infra-estrutura oferecida pelo portal e editar o proto-colo de forma colaborativa. O portal auxiliará o coordenador de cada área de pesquisa no controle das modificações realizadas no protocolo, além de manter um histórico de edições do documento. Ao término de cada macro-atividade, um revisor (alocado ao estudo pelo gerente) avaliará os resultados obtidos de forma a permitir a execução da próxima macro-atividade ou recomendar refinamentos na macro-atividade em execução. A avaliação dos artigos obtidos durante a execução da revisão sistemática será auxiliada pelo uso da ferramenta de gerência de referências bibliográficas JabRef [JabRef, 2009], que poderá ser customizada caso os pesquisadores envolvidos achem necessário. A dis-ponibilização de uma versão do JabRef e a coordenação das micro-atividades posterio-res ficará cargo do coordenador da área de pesquisa e será auxiliada pelo portal. Ao término da execução de uma revisão sistemática, o coordenador selecionará os resulta-dos estatísticos de interesse e disponibilizará o relatório final do estudo no portal.

Figura 4 – Atividades para a condução de revisões sistemáticas no portal

4. Considerações Finais

O processo de ensino e aprendizagem de ES tem passado por questionamentos [Lethbridge et al., 2007]. Apesar das iniciativas existentes para melhorar este processo, as pesquisas subjacentes muitas vezes são realizadas de forma isolada e localizada, sem focar em uma ação conjunta para identificar as questões que impactam a educação de ES no cenário nacional. Identificando a necessidade de explorar os aspectos que per-meiam a educação em ES, o este artigo apresentou o Portal EduES Brasil, uma infra-estrutura que busca facilitar a integração das comunidades de educadores e de pesqui-sadores em educação em ES, a fim de auxiliar a condução de estudos experimentais que contribuam para a organização e manutenção de um corpo de conhecimento sobre edu-cação em ES no Brasil. Atualmente, o Portal EduES Brasil contém módulos que apóiam

XXIII SBES - FEES

39

a comunicação, coordenação e colaboração de comunidades de pesquisa e a condução da segunda etapa da estratégia de pesquisa do Projeto EduES Brasil. A implementação dos módulos relacionados à terceira etapa da estratégia de pesquisa encontra-se em de-senvolvimento. O portal estará disponível em http://lens.cos.ufrj.br/portaledues em breve. Com isso, planeja-se a condução de um estudo piloto para identificar as modifi-cações e/ou melhorias a serem feitas na estrutura do portal e nas atividades relacionadas à condução dos estudos experimentais.

Agradecimentos Os autores agradecem ao CNPq, FAPERJ e à CAPES pelo apoio financeiro para este trabalho.

Referências Basili, V. R.; Shull, F.; Lanubile, F. (1999) “Building Knowledge through Families of Experiments”.

IEEE Transactions on Software Engineering 25, 4 (July-August), 456-473. Biolchini, J. C. A.; Mian, P. G.; Natali, A. C. C.; Conte, T. U.; Travassos, G. H. (2007) “Scientific

Research Ontology to Support Systematic Review in Software Engineering”. Advances Engineering Informatics 21, 2, 133-151.

FEES (2009) “Fórum de Educação em Engenharia de Software”, http://fees.inf.puc-rio.br/.Hiebert, J.; Gallimore, R.; Stigler, J. W. (2002) “A Knowledge Base for the Teaching Profession:

What Would It Look Like and How Can We Get One?”. Educational Research 31, 5, 315. JabRef (2009) “JabRef Reference Manager”, http://jabref.sourceforge.net/.JavaZOOM (2009) “JChatBox”, http://www.javazoom.net/jzservlets/jchatbox/jchatbox.html.JForum (2009) “JFoum”, http://www.jforum.net/.Lethbridge, T. C.; Diaz-Herrera, J.; Leblanc, R. J.; Thompson, J. B. (2007) “Improving Software

Practice through Education: Challenges and Future Trends”, In: The Future of Software Engineering, Proc. of the 29th ICSE, Minneapolis, USA, 12-28.

Mafra, S. N.; Barcelos, R. F.; Travassos, G. H. (2006) “Aplicando uma Metodologia Baseada em Evidência na Definição de Novas Tecnologias de Software”, In: Anais do XX Simpósio Brasileiro de Engenharia de Software, Florianópolis, Brasil, 239-254.

Mattoso, M.; Werner, C.; Travassos, G.; Braganholo, V.; Murta, L. (2008) “Gerenciando Experimentos Científicos em Larga Escala”, In: SEMISH, CSBC, Belém, Brasil, 121-135.

Santos, R. P.; Santos, P. S. M.; Werner, C. M. L.; Travassos, G. H. (2008a) “Utilizando Experimentação para Apoiar a Pesquisa em Educação em Engenharia de Software no Brasil”, In: Anais do I FEES, XXII SBES, Campinas, Brasil, 55-64.

Santos, R.; Santos, P. S.; Werner, C.; Travassos, G. (2008b) “Uma Estratégia para Apoiar a Pesquisa em Educação em Engenharia de Software no Brasil”, In: Proc. of the 5th Experimental Software Engineering Latin American Workshop, Salvador, Brasil, 1-10.

Schots, M.; Santos, R.; Mendonça, A.; Werner, C. (2009) “Elaboração de um Survey para a Caracterização do Cenário de Educação em Engenharia de Software no Brasil”, In: Anais do II FEES, XXIII SBES, Fortaleza, Brasil. Aceito p/ publicação.

Seam (2009) “JBoss Seam Framework”, http://seamframework.org/.Shull, F.; Carver, J.; Travassos, G. (2001) “An Empirical Methodology for Introducing Software

Processes”, In: Joint 8th ESEC and 9th ACM SIGSOFT FSE-9, 288-296. Spínola, R. O.; Dias-Neto, A. C.; Travassos, G. H. (2008) “Abordagem para Desenvolver

Tecnologias de Software com Apoio de Estudos Secundários e Primários”, In: Proc. of the 5th Experimental Software Engineering Latin American Workshop, Salvador, Brasil, 11-20.

Travassos, G. H.; Gurov, D.; Amaral, E. A. G. (2002) “Introdução à Engenharia de Software Experimental”, Relatório Técnico ES-590/02, PESC/COPPE/UFRJ.

Werner, C.; Rodrigues, C.; Santos, R.; Costa, H. L.; Santo, R.; Castro, W. (2009) “Projeto Tec3ES: Tecnologias e Estratégias para Educação em Engenharia de Software”, In: XVII CIESC, Pelotas, Brasil. Aceito p/ publicação.

XXIII SBES - FEES

40

Revisão Sistemática sobre Avaliação de Jogos Voltados para Aprendizagem de Engenharia de Software no Brasil

Christiane Gresse von Wangenheim1, Djone Kochanski2, Rafael Savi3

1Programa de Pós-Graduação em Ciência da Computação/ Departamento de Informática e Estatística – Universidade Federal de Santa Catarina (UFSC)

Florianópolis – SC – Brasil

2Programa de Pós-Graduação em Computação Aplicada – Universidade do Vale do Itajaí (UNIVALI) – São José – SC – Brasil

3Programa de Pós-Graduação em Engenharia e Gestão do Conhecimento – Universidade Federal de Santa Catarina (UFSC) – Florianópolis – SC – Brasil

gresse@gmail.com, djonekoc@terra.com.br, rafaelsavi@gmail.com

Abstract. This paper describes a systematic review on the evaluation of educational games for teaching Software Engineering in Brazil. The objective of the review was to elicit which educational games are used and how their learning effects on the students are evaluated. A few games studies were founded and we observed that most part focused on software project management and had a superficial educational evaluation.

Resumo. Este artigo descreve uma revisão sistemática sobre avaliação de jogos voltados para a aprendizagem de Engenharia de Software no Brasil. O objetivo da revisão foi levantar quais jogos educacionais são utilizados e como os efeitos de aprendizagem são avaliados. Estudos sobre alguns jogos foram encontrados e observamos que a maioria deles estava voltada para gerência de projetos de software e tiveram uma avaliação educacional superficial.

1. Introdução

Um dos grandes desafios enfrentados no ensino da Engenharia de Software (ES) atualmente é suprir a necessidade de uso de métodos de ensino que permitam tornar o processo de ensino-aprendizagem mais efetivo [Santos et al. 2008]. A aceleração das inovações tecnológicas também tem representado um desafio para o ensino em ES [Chen et al. 2008]. Em função disso, a forma tradicional de ensino excessivamente centrada no professor, faz com que falte aos estudantes oportunidades para aplicação prática dos conceitos [Chen et al. 2008] [Shaw e Dermoudy 2005]. Uma forma de melhorar a situação é através do uso de métodos de ensino alternativos, como, estudos de caso, atividades realizadas em projetos de empresas do ramo, jogos (cartas, tabuleiro, computador, etc.), simuladores, entre outros. Recentemente, criou-se a expectativa de que jogos educacionais sejam um meio bastante vantajoso [Prensky 2001]. Em geral, tais jogos são desenvolvidos em ambientes educacionais para serem utilizados como complemento às aulas de determinados assuntos. São desenvolvidos para terem, além do fundamento educacional, elementos relativos a jogos como contexto, objetivos, regras, feedback, competição e interação [Prensky 2001].

XXIII SBES - FEES

41

Através de ambientes virtuais, como jogos e ferramentas de simulação, as pessoas podem ser capacitadas pela vivência com situações realísticas que podem ser encontradas na prática. Tal abordagem permite o desenvolvimento de experiências sem os riscos existentes no mundo real [Pfahl et al. 2000]. Além disso, utilizar abordagens de jogos e simulação permite ao estudante aprender fazendo, reduzindo assim a lacuna existente entre teoria e prática [Baker et al. 2005]. Atualmente, vários jogos educacionais já são utilizados no ensino de ES, como, p.ex., [Navarro e van der Hoek 2007], [Drappa e Ludewig 2000], [Barros et al. 2006], entre outros.

É importante que se tenha evidências dos benefícios dos jogos antes de utilizá-los em sala de aula. Uma compreensão mais precisa a respeito dos resultados do uso desse tipo de recurso permite saber se compensam os custos e esforços envolvidos em adotá-los [Navarro e van der Hoek 2007]. Mas, embora se tenha indícios de que os jogos educacionais possam ser ferramentas capazes de aprimorar o processo de ensino-aprendizagem [Garris, Ahlers e Driskell 2002], e que esse tipo de recurso começa a atrair a atenção de professores e alunos, ainda não se conhece direito o grau de contribuição que os jogos podem trazer para a educação [Akilli 2007].

Assim, com o objetivo de conhecer quais jogos educacionais foram desenvolvidos para o ensino de Engenharia de Software no Brasil e como são avaliados os efeitos de aprendizagem dos alunos que utilizam esses jogos, foi realizada a presente revisão sistemática.

2. Revisão Sistemática

Com este intuito, realizamos uma revisão sistemática de literatura sobre jogos educacionais voltados para o ensino de Engenharia de Software no Brasil, seguindo o processo de condução de revisões sistemáticas definido por Kitchenham (2004).

A revisão foi realizada por uma equipe de pesquisadores de Engenharia de Software da UFSC e da UNIVALI, com o objetivo de obter informações que ajudem a responder as seguintes questões:

1) Que jogos foram desenvolvidos para o ensino de Engenharia de Software no Brasil?

2) Como a eficiência educacional dos jogos brasileiros para Engenharia de Software tem sido avaliada em relação a outros métodos instrucionais?

Em comparação com outras revisões sistemáticas com objetivos similares [Wangenheim e Shull 2009], que restringiram as buscas por artigos em bases de dados científicas como IEEEXplore, ACM Digital Library, entre outras, e que retornou apenas um caso brasileiro, o presente trabalho amplia o domínio de buscas para a Web em geral, visando encontrar um maior número de estudos que abordam jogos desenvolvidos no Brasil publicados em português.

Para essa revisão, a equipe procurou examinar todos os artigos sobre jogos no ensino de ES no Brasil disponíveis na Web (indicados por buscas no Google), publicados entre janeiro de 1990 e junho de 2009. Foram considerados todos os tipos de jogos ou simuladores com objetivos educacionais, incluindo jogos de computador ou não (p.exe, jogos de tabuleiro, cartas, etc.). Também foram considerados protótipos conceituais de jogos, que foram apenas modelados e ainda não chegaram a ser implementados. Da pesquisa na web, foram excluídos os resultados que:

XXIII SBES - FEES

42

� Não tenham sido publicados em revistas especializadas, em anais de congressos, simpósios, seminários ou não sejam trabalhos de conclusão de curso ou dissertações;

� Não tratem de jogos ou simulação com finalidades acadêmicas ou educacionais; � Não são voltados para o ensino de ES; � Não relatam aplicação do jogo no Brasil.

Fontes de dados e estratégias de busca. A equipe buscou todos os artigos brasileiros publicados em português, que abordam jogos para a ES disponíveis na internet. A ferramenta de pesquisa utilizada foi o Google (www.google.com.br). Para obtenção das publicações foram utilizados dois argumentos de pesquisa por causa de uma limitação no campo de buscas do Google, que aceita no máximo 32 palavras.

O primeiro argumento de pesquisa utilizado foi: (jogo OR simulação) AND (abstract AND resumo) AND (educação OR ensino OR aprendizagem) AND (“engenharia de software” OR “projeto de software” OR “requisitos de software” OR “design de software” OR “construção de software” OR “teste de software”) filetype:pdf. Este argumento de pesquisa retornou 1.120 resultados.

O segundo argumento de pesquisa utilizado foi: (jogo OR simulação) AND (abstract AND resumo) AND (educação OR ensino OR aprendizagem) AND (“manutenção de software” OR “gerenciamento de configuração” OR “processo de software” OR “medição de software” OR “qualidade de software”) filetype:pdf. Este segundo argumento retornou 849 resultados.

Todos esses documentos foram conferidos (título e resumo) pela equipe de pesquisadores e apenas 8 foram considerados relevantes, de acordo com os critérios de inclusão e exclusão.

A partir desses artigos foi realizada nova pesquisa no Google, dessa vez usando como argumento de busca o nome dos jogos encontrados. O objetivo foi identificar outros documentos que pudessem enriquecer a revisão, como, por exemplo, dissertações e trabalhos de conclusão de curso, ou mesmo artigos que não haviam sido retornados com os argumentos de pesquisa utilizados. Com esse procedimento mais 4 documentos foram encontrados e incorporados ao conjunto de estudos considerados para essa revisão.

Extração dos dados. Depois de ter os artigos selecionados foi realizada a extração dos dados sobre os jogos, que foram sintetizados na Tabela 1 de acordo com os seguintes itens: Identificação do artigo: identificador do artigo composto por um número seqüencial; Jogo: Nome do jogo relatado no estudo; Referências: referência do artigo, bem como documentos adicionais que tenham sido utilizados para obtenção das informações; Descrição do jogo: breve descrição do jogo ou ferramenta de simulaçãoavaliada; Forma de utilização: utilização por usuários individuais ou múltiplos usuários; Tipo do jogo: identifica se o jogo é utilizado em tabuleiro, cartas, computador em ambiente local ou computador na internet; Área de conhecimento da ES: área de conhecimento da Engenharia de Software na qual a atividade de aprendizagem está focada, com base no SWEBOK [IEEE 2004]; Atividade de aprendizagem: visão geral da tarefa que deve ser cumprida pelos alunos; Contexto de uso: indica o contexto educacional em que o jogo pode ser utilizado; Resultado de aprendizagem: indica o que o aluno deve atingir como resultado da experiência de aprendizagem, classificados em

XXIII SBES - FEES

43

conhecimentos, habilidades e atitudes; Avaliação: identifica se o uso educacional foi formalmente avaliado; Principais descobertas: sumarização dos principais resultados obtidos no estudo e/ou avaliação realizados.

4. Resultados

Em relação à primeira pergunta de pesquisa (Que jogos foram desenvolvidos para o ensino de Engenharia de Software no Brasil?), pode-se perceber que ainda existem poucas publicações sobre jogos educacionais para ensino de ES no Brasil. Dentre as áreas da Engenharia de Software, a mais abordada pelos jogos é a de Gerenciamento de Projetos. Os jogos identificados são listados na Tabela 1.

Em relação à segunda pergunta de pesquisa (Como a eficiência educacional dos jogos brasileiros para Engenharia de Software tem sido avaliada em relação a outros métodos instrucionais?), a análise aponta que a grande maioria das publicações não apresenta detalhamento suficiente sobre uma avaliação dos efeitos de aprendizagem dos jogos. Dos oito jogos analisados, apenas três foram avaliados com o objetivo de evidenciar os ganhos obtidos através do uso do jogo. Em relação aos demais jogos, ou as publicações não citam nenhum tipo de avaliação ou uma avaliação bem informal, mais no sentido de expressão de opinião ad-hoc. Isto também demonstra uma deficiência neste ponto, que pode até inibir uma adoção mais ampla deste método de ensino na área de ES.

Outro ponto observado foi a consideração insuficiente de aspectos educacionais. As descrições dos jogos em si, muitas vezes, não descrevem suficientemente as características dos jogos e principalmente não descrevem claramente os objetivos de aprendizagem e contexto de uso educacional, que são informações essenciais para um professor decidir adotar os jogos como material instrucional.

5. Conclusão

Atualmente jogos educacionais são apontados como um tipo promissor de material instrucional, que pode trazer benefícios para a educação também na área de Engenharia de Software. Há indicações de que esse método de ensino costuma agradar e motivar os alunos, despertar o interesse e a curiosidade, além de contribuir positivamente na aprendizagem. Porém, os resultados desta revisão da literatura confirmam também outras observações, que de fato, esses benefícios muitas vezes ainda não foram formalmente demonstrados. Desta forma, é necessário um esforço dos pesquisadores interessados neste campo para aumentar as evidências sobre as vantagens do uso dos jogos na aprendizagem dos alunos, utilizando métodos de pesquisas para avaliações mais rigorosas.

Agradecimentos

Este trabalho foi suportado pelo Conselho Nacional de Desenvolvimento Científico e Tecnológico - CNPq – Brasil.

XXIII SBES - FEES

44

Tab

ela

1: S

ínte

se d

os

dad

os

extr

aíd

os

Identificação

Jogo

Estudos relacionados

Descrição do jogo

Forma de utilização

Ambiente de execução

Área de conhecimento da Engenharia de Software

Atividade de aprendizagem

Contexto de uso

Resultado de aprendizagem

Avaliação

Principais descobertas

1 E

licit@

ção

[Ber

nard

i, F

onto

ura

e C

orde

nons

i 200

8]

O jo

gado

r re

aliz

a en

trev

ista

s co

m

pers

onag

ens

virt

uais

par

a id

entif

icar

req

uisi

tos

de u

m s

iste

ma

para

ges

tão

de e

spet

ácul

os

teat

rais

. Os

alun

os a

pren

dem

es

trat

égia

s pa

ra id

entif

icar

re

quis

itos

em e

ntre

vist

as q

ue

acon

tece

m e

m d

ifere

ntes

am

bien

tes

de tr

abal

ho, c

om

usuá

rios

de d

ifere

ntes

pe

rson

alid

ades

e d

ifere

ntes

de

sejo

s de

coo

pera

ção.

usuá

rios

indi

vidu

ais

Est

e jo

go

está

em

fase

de

pr

otot

ipaç

ão

e ai

nda

não

foi

impl

emen

tado

Req

uisi

tos

de

Sof

twar

e O

joga

dor

part

icip

a de

si

mul

açõe

s de

ent

revi

stas

pa

ra a

pren

der

técn

icas

de

elic

itaçã

o de

req

uisi

tos

Jogo

par

a se

r ut

iliza

do c

omo

ferr

amen

ta

com

ple

men

tar

na

apre

ndiz

agem

na

grad

uaçã

o de

co

mpu

taçã

o ou

si

stem

as d

e in

form

ação

.

Con

heci

men

to

Hab

ilida

de

Não

O

jogo

ape

nas

foi m

odel

ado

e ai

nda

é um

pro

tótip

o co

ncei

tual

. N

ão fo

i tes

tado

com

usu

ário

s e

não

trás

res

ulta

dos

de s

eu u

so.

2 H

oney

[S

ouza

et a

l. 20

08]

O H

oney

é u

m jo

go q

ue s

imul

a um

am

bien

te n

o qu

al o

usu

ário

pod

e cl

icar

em

por

tas

de s

alas

de

escr

itório

ond

e co

nteú

dos

sobr

e X

P

(Ext

rem

e P

rogr

amm

ing)

são

ap

rese

ntad

os

usuá

rios

indi

vidu

ais

com

puta

dor

na in

tern

et

Pro

cess

o de

so

ftwar

e O

joga

dor

aces

sa u

m

ambi

ente

virt

ual c

om

dive

rsas

por

tas

de s

alas

de

esc

ritór

ios

com

ob

jeto

s e

ator

es. C

ada

port

a ga

rant

e o

aces

so a

um

a pr

átic

a do

XP

.

Jogo

util

izad

o co

mo

com

ple

men

to d

a ap

rend

izag

em d

e co

ncei

tos

rela

cion

ados

ao

XP

(E

xtre

me

Pro

gram

min

g) e

m

curs

o de

gra

duaç

ão

em C

iênc

ia d

a C

om

puta

ção

Con

heci

men

to

Não

O

jogo

não

ava

liado

de

form

a si

stem

átic

a, p

orém

a o

bser

vaçã

o ap

onta

a e

xist

ênci

a de

res

ulta

dos

satis

fató

rios

em r

elaç

ão a

o en

tend

imen

to d

o X

P e

boa

ac

eita

ção

da fe

rram

enta

.

3 P

lana

ger

[Ros

a e

Kie

ling

2006

]

[Prik

ladn

icki

, Ros

a e

Kie

ling

2007

]

[Prik

ladn

icki

e

Wan

genh

eim

200

8]

O P

lana

ger

apói

a o

ensi

no d

e co

ncei

tos

de g

erên

cia

de p

roje

tos,

fo

cado

no

grup

o de

pro

cess

os d

e pl

anej

am

ento

do

PM

BO

K. E

xist

em

do

is m

odos

de

jogo

: o tu

toria

l, on

de

o us

uário

apr

ende

sob

re g

erên

cia

de p

roje

tos

e o

jogo

, ond

e é

poss

ível

inte

ragi

r co

m d

iver

sos

cená

rios

de p

roje

tos

cada

stra

dos

na b

ase

de d

ados

do

Pla

nage

r. E

m

cada

cen

ário

há

a de

scriç

ão d

e um

pr

ojet

o e

o jo

gado

r de

verá

pas

sar

por

cinc

o fa

ses:

def

iniç

ão d

o es

copo

, cria

ção

da E

AP

, def

iniç

ão

de a

tivid

ades

, seq

üenc

iam

ento

de

ativ

idad

es e

cam

inho

crí

tico.

usuá

rios

indi

vidu

ais

com

puta

dor

em a

mbi

ente

lo

cal

Ger

enci

amen

to

de e

ngen

haria

de

sof

twar

e

O J

ogo

sim

ula

um

ambi

ente

em

pres

aria

l e o

es

tuda

nte

exer

cita

os

proc

esso

s de

pl

anej

am

ento

do

PM

BO

K

Util

izad

o pa

ra

com

ple

men

tar

o en

sino

de

gerê

ncia

de

pro

jeto

s de

so

ftwar

e em

cur

sos

de g

radu

ação

.

Con

heci

men

to

Hab

ilida

de

Não

A

valia

ções

pre

limin

ares

m

ostr

ara

m q

ue o

s al

unos

tive

ram

m

aior

faci

lidad

e pa

ra e

nten

der

os

conc

eito

s de

ger

ênci

a de

pr

ojet

os, e

a e

stra

tégi

a de

po

ntua

ção

usad

a no

jogo

aju

dou

ao p

rofe

ssor

iden

tific

ar a

di

fere

ncia

ção

de c

onhe

cim

ento

s de

cad

a al

uno.

H

á ne

cess

idad

e de

incl

uir

mai

or

núm

ero

de c

enár

ios

no jo

go,

aper

feiç

oar

a in

terf

ace

gráf

ica

e va

lidar

o u

so e

duca

cion

al c

om

técn

icas

de

expe

rimen

taçã

o.

4 S

crum

min

g

[Isot

ton

2008

]

[Prik

ladn

icki

e

Wan

genh

eim

200

8]

O S

crum

min

g é

um

jogo

de

apoi

o ao

ens

ino

e pr

átic

a de

con

ceito

s do

S

CR

UM

, per

miti

ndo

a si

mul

ação

da

defin

ição

de

um s

prin

t de

um

pr

ojet

o po

r ve

z.

usuá

rios

indi

vidu

ais

Co

mpu

tado

r em

am

bien

te

loca

l

Ger

enci

amen

to

de p

roje

tos

de

softw

are

O jo

gado

r re

aliz

a a

defin

ição

de

um s

prin

t do

SC

RU

M a

ssu

min

do o

pa

pel d

e S

crum

Mas

ter

Jogo

util

izad

o co

mo

apoi

o no

ens

ino

de

prát

icas

do

SC

RU

M

para

pro

fissi

onai

s da

indú

stria

e

alun

os d

e

Con

heci

men

to

Não

A

ferr

amen

ta n

ão fo

i ava

liada

de

form

a si

stem

átic

a, p

orém

foi

apre

sent

ada

para

alg

uns

gere

ntes

de

proj

etos

os

quai

s m

ostr

ara

m b

asta

nte

inte

ress

e e

curio

sida

de p

ela

utili

zaçã

o pa

ra

XX

III S

BE

S -

FEE

S

45

grad

uaçã

o.

prat

icar

os

conc

eito

s ap

rese

ntad

os.

5 S

E•R

PG

[B

enitt

i e M

ollé

ri 20

08]

Jogo

edu

caci

onal

bas

eado

em

pa

péis

(R

PG

– R

ole-

Pla

ying

Gam

e)

que

sim

ula

um a

mbi

ente

de

dese

nvol

vim

ento

de

softw

are

de

uma

em

pres

a fic

tícia

.

usuá

rios

indi

vidu

ais

Co

mpu

tado

r na

inte

rnet

G

eren

ciam

ento

de

pro

jeto

s de

so

ftwar

e

O jo

gado

r si

mul

a a

exec

ução

de

um p

roje

to

assu

min

do o

pap

el d

e ge

rent

e de

pro

jeto

s,

pode

ndo

sele

cion

ar o

m

odel

o de

pro

cess

o, a

lin

guag

em u

tiliz

ada

e a

equi

pe d

o pr

ojet

o.

Jogo

util

izad

o co

mo

ferr

amen

ta d

e au

xílio

ao

apre

ndiz

ado

do

proc

esso

de

dese

nvol

vim

ento

de

softw

are

e ge

stão

de

pro

jeto

s em

au

las

de g

radu

ação

.

Con

heci

men

to

Hab

ilida

de

Sim

P

erm

ite m

inim

izar

a la

cuna

ex

iste

nte

entr

e te

oria

e p

rátic

a.

Est

imul

a a

apre

ndiz

agem

. P

ropo

rcio

na u

ma

visã

o pr

átic

a do

pr

oces

so d

e de

senv

olvi

men

to.

O jo

go fo

i con

side

rado

mot

ivad

or

e de

safia

dor.

O

jogo

teve

con

trib

uiçã

o si

gnifi

cativ

a ao

apr

endi

zado

. 6

Sim

ulE

S

[Fig

ueir

edo

et a

l. 20

06]

[Fig

ueir

edo

et a

l. 20

08]

O jo

go S

imul

ES

(S

imul

ador

de

Uso

da

Eng

enha

ria d

e S

oftw

are)

é u

m

jogo

que

util

iza

tabu

leiro

, car

tas

e ca

rtõe

s ba

sead

o no

jogo

PnP

(P

robl

ems

and

Pro

gram

mer

s) c

uja

final

idad

e é

o en

sino

de

conc

eito

s de

Eng

enha

ria d

e S

oftw

are

múl

tiplo

s us

uário

s T

abul

eiro

P

roce

sso

de

softw

are

O jo

gado

r as

sum

e o

pape

l de

gere

nte

de

proj

etos

e d

eve

apre

sent

ar s

oluç

ões

aos

prob

lem

as a

pres

enta

dos

dura

nte

um p

roce

sso

de

dese

nvol

vim

ento

de

softw

are

Jogo

de

tabu

leir

o ut

iliza

do p

ara

apoi

o no

ens

ino

do

proc

esso

de

dese

nvol

vim

ento

de

softw

are

em c

urso

s de

gra

duaç

ão.

Con

heci

men

to

Não

F

oi r

ealiz

ada

apen

as u

ma

aval

iaçã

o da

din

âmic

a do

jogo

, se

ndo

suge

rida

com

o tr

abal

ho

futu

ro, a

rea

lizaç

ão d

e um

a av

alia

ção

mai

s si

stem

átic

a.

7 T

he

Incr

edib

le

Man

ager

[Dan

tas

2003

]

[Dan

tas,

Bar

ros

e W

erne

r 20

04a]

[Dan

tas,

Bar

ros

e W

erne

r 20

04b]

The

Inc

redi

ble

Man

ager

é u

m j

ogo

de

si

mul

ação

on

de

o es

tuda

nte

deve

at

uar

com

o ge

rent

e de

pr

ojet

os d

e so

ftwar

e. N

o in

ício

, é

prec

iso

cons

trui

r um

pl

ano

do

proj

eto,

for

mar

a e

quip

e e

aloc

ar o

s re

curs

os

nas

ativ

idad

es,

que

deve

rão

ser

cont

rola

das

para

pe

rman

ecer

em

dent

ro

do

cron

ogra

ma

e or

çam

ento

pre

vist

os.

No

deco

rrer

do

jo

go

o es

tuda

nte

pode

pr

ecis

ar

alte

rar

o pl

anej

am

ento

or

igin

al

do

dese

nvol

vim

ento

pa

ra

alca

nçar

o

suce

sso,

qu

e ac

onte

ce

quan

do

toda

s as

ativ

idad

es s

ão c

oncl

uída

s se

m

que

os

dias

e

fund

os

do

proj

eto

acab

em.

usuá

rios

indi

vidu

ais

Co

mpu

tado

r em

am

bien

te

loca

l

Ger

enci

amen

to

de p

roje

tos

de

softw

are

O jo

gado

r as

sum

e o

pape

l do

gere

nte

do

proj

eto,

faz

um

plan

eja

men

to q

ue d

ever

á se

r co

ntro

lado

par

a fin

aliz

ar o

pro

jeto

den

tro

dos

cust

os e

pra

zos

plan

ejad

os.

Sim

ulaç

ão u

sada

co

mo

com

ple

men

to

de a

pren

diza

gem

em

trei

nam

ento

s de

ge

rent

es d

e pr

ojet

os, o

corr

idos

em

cur

sos

de

grad

uaçã

o, p

ós-

grad

uaçã

o ou

em

tr

eina

men

tos

para

em

pres

as.

Con

heci

men

to

Hab

ilida

de

Atit

ude

Sim

O

pro

cess

o de

trei

nam

ento

ba

sead

o em

jogo

s de

sim

ulaç

ão

foi c

onsi

dera

do m

otiv

ador

, di

nâm

ico,

prá

tico

e di

vert

ido.

P

artic

ipan

tes

apon

tara

m c

om

o as

pect

os im

port

ante

s a

pres

são

psic

ológ

ica

e ní

vel d

e di

ficul

dade

do

jogo

. In

form

ara

m q

ue h

ouve

aum

ento

em

hab

ilida

de d

e ge

renc

iam

ento

; O

inte

ress

e po

r ge

renc

iam

ento

au

men

tou

depo

is d

o jo

go;

Tre

inam

ento

bas

eado

em

jogo

s fo

i con

side

rado

bom

; O

s al

unos

con

side

rara

m o

tr

eina

men

to d

iver

tido

ou m

uito

di

vert

ido.

A

luno

s re

clam

ara

m q

ue o

mod

elo

atua

l é u

m p

ouco

sim

ples

e

inca

paz

de r

epre

sent

ar d

iver

sas

situ

açõe

s e

even

tos

ines

pera

dos.

8

X-M

ED

[P

rikla

dnic

ki e

W

ange

nhei

m 2

008]

[Wan

genh

eim

, Thi

ry

e K

ocha

nski

200

8]

O X

-ME

D é

um

jogo

edu

caci

onal

qu

e pe

rmite

rea

lizar

a s

imul

ação

de

um p

rogr

am

a de

med

ição

de

softw

are

com

enf

oque

no

mon

itora

men

to d

e pr

ojet

os d

e ac

ordo

com

o n

ível

2 d

e m

atur

idad

e do

CM

MI-

DE

V v

1.2,

co

m b

ase

no G

QM

(G

oal/Q

uest

ion/

Met

ric)

e P

SM

(P

ract

ical

Sof

twar

e an

d S

yste

ms

Mea

sure

men

t). O

obj

etiv

o do

jogo

é

refo

rçar

con

ceito

s de

med

ição

e

ensi

nar

a co

mpe

tênc

ia n

a ap

licaç

ão d

o co

nhec

imen

to d

e m

ediç

ão.

usuá

rios

indi

vidu

ais

Co

mpu

tado

r em

am

bien

te

loca

l

Ger

enci

amen

to

de p

roje

tos

de

softw

are

e m

ediç

ão d

e so

ftwar

e

O jo

gado

r as

sum

e o

pape

l de

um a

nalis

ta d

e m

ediç

ão e

seg

ue

seqü

enci

alm

ente

toda

s as

tare

fas

para

def

inir

e

aplic

ar u

m p

rogr

ama

de

med

ição

.

O jo

go é

util

izad

o pa

ra c

ompl

emen

tar

curs

os tr

adic

iona

is

ou e

-lear

ning

de

estu

dant

es d

e pó

s-gr

adua

ção

na á

rea

de C

iênc

ia d

a C

om

puta

ção

e/ou

pr

ofis

sion

ais

de

Eng

enha

ria d

e S

oftw

are,

fo

rnec

endo

um

am

bien

te p

ara

exer

cita

r os

co

ncei

tos

apre

sent

ados

.

Con

heci

men

to

Hab

ilida

de

Sim

C

om

o re

sulta

do d

o ex

perim

ento

, m

uito

s pa

rtic

ipan

tes

acre

dita

ram

de

mod

o su

bjet

ivo

que

o jo

go o

s aj

udou

a a

pren

der

tant

o so

bre

conc

eito

s e

proc

esso

qua

nto

sobr

e a

aplic

ação

da

med

ição

. E

m g

eral

, os

part

icip

ante

s av

alia

ram

o jo

go c

om

o ap

ropr

iado

e a

trat

ivo.

M

uito

s pa

rtic

ipan

tes

com

enta

ram

qu

e pr

efer

iram

o jo

go e

m r

elaç

ão

a ex

ercí

cios

trad

icio

nais

.

XX

III S

BE

S -

FEE

S

46

6. Referências

Akilli, G. K. (2007) “Games and Simulations: A new approach in education”. In: Gibson D, Aldrich C, Prensky M(eds) Games and simulations in online learning: research and development frameworks. Information Science Publishing, Hershey/PA, p. 1-20.

Baker, A., Navarro, E. O. e van der Hoek, A. (2005) “An Experimental Card Game for Teaching Software Engineering Processes”, In: Journal of Systems and Software. Volume 75. p. 3-16. New York.

Barros, M., Dantas, A., Veronese, G. e Werner, C. (2006) “Model-Driven Game Development: Experience and Model Enhancements in Software Project Management Education”, Journal of Software Process: Improvement and Practice, Special Issue on Software Process Simulation Modeling, vol. 11, no. 4, p. 411-421.

Benitti, F. B. V. e Molléri, J. S. (2008) “Utilização de um RPG no ensino de gerenciamento e processo de desenvolvimento de software”. In: WEI - Workshop sobre Educação em Computação, 2008, Belém do Pará. Anais do XXVIII Congresso da SBC, 2008. p. 258-267.

Bernardi, G., Fontoura, L. M. e Cordenonsi, A. Z. (2008) “Elicit@ção: Ferramenta de Apoio ao Ensino de Elicitação de Requisitos de Software baseada em Instituições Eletrônicas”. In: II Workshop-Escola de Sistemas de Agentes para Ambientes Colaborativos. Santa Cruz do Sul – RS, 2008.

Chen, W., Wu, W., Wang, T. e Su, C. (2008) "Work in Progress - A Game-based Learning System for Software Engineering Education", in 38th ASEE/IEEE Frontiers in Education Conference. p. T2A-12-T2A-13. Saratoga Springs: New York.

Dantas, A. R. (2003) “Jogos de Simulação no Treinamento de Gerentes de Projetos de Software”. Dissertação (Mestrado Engenharia de Sistemas e Computação) – Programa de Pós-Graduação em Engenharia de Sistemas e Computação, UFRJ, Rio de Janeiro.

Dantas, A. R., Barros, M. O. e Werner, C. M. L. (2004a) “Treinamento Experimental com Jogos de Simulação para Gerentes de Projeto de Software”. In: XVIII Simpósio Brasileiro de Engenharia de Software, 2004, p. 23-38. Brasíla, DF.

Dantas, A. R., Barros, M. O. e Werner, C. M. L. (2004b) “A Simulation-Based Game for Project Management Experiential Learning”. In: International Conference on Software Engineering & Knowledge Engineering, 2004, p. 19-24. Banff, Alberta.

Drappa, A. e Ludewig, J. (2000) “Simulation in Software Engineering Training”, In Proc. 22th Int’l Conf. Software Eng., ACM Press, p. 199-208.

Figueiredo, E., Lobato, C. A., Dias, K., Leite, J. C. S. P. e Lucena, C. J. P. (2006) “SimulES: Um Jogo para o Ensino de Engenharia de Software”. Disponível em: <ftp://ftp.inf.puc-rio.br/pub/docs/techreports/06_34_figueiredo.pdf>. Acesso em: 27 jun. 2009

Figueiredo, E., Lobato, C. A., Dias, K. L., Leite, J. C. e Lucena, C. J. P. (2007) “Um Jogo para o Ensino de Engenharia de Software Centrado na Perspectiva de Evolução”. In: Congresso da Sociedade Brasileira de Computação (SBC), 2007, p. 37-46. Rio de Janeiro.

XXIII SBES - FEES

47

Garris, R., Ahlers, R. e Driskell, J.E. (2002). “Games, Motivation, and Learning: A Research and Practice Model”. Simulation Gaming 33, no. 4 (December 1), p. 441-467.

IEEE Computer Society. (2004) “SWEBOK - Guide to the Software Engineering Body of Knowledge”.

Isotton, E. (2008) “Scrumming - Ferramenta Educacional para Ensino de Práticas de SCRUM”. 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.

Kitchenham, B. A. (2004) “Procedures for Performing Systematic Reviews”, Tech. report TR/SE-0401, Keele University.

Navarro, E. O. e van der Hoek, A. (2007) “Comprehensive Evaluation of an Educational Software Engineering Simulation Environment,” Proc. 20th Conf. Software Eng. Education and Training, IEEE CS Press, p. 195-202.

Pfahl, D., Klemm, M. e Ruhe, G. (2000) "Using System Dynamics Simulation Models for Software Project Management Education and Training", In Software Process Simulation Modeling Workshop (ProSim2000), Londres.

Prensky, M. (2001) "Digital Game-Based Learning". New York, McGraw-Hill.

Prikladnicki, R.; Rosa, R. e Kieling, E. (2007) “Ensino de Gerência de Projetos de Software com o Planager”. In: XVIII SBIE - Simpósio Brasileiro de Informática na Educação, 2007, São Paulo.

Prikladnicki, R. e Wangenheim, C. G. (2008) “O Uso de Jogos Educacionais para o Ensino de Gerência de Projetos de Software”. In: FEES - Fórum de Educação em Engenharia de Software, 2008, Campinas. FEES - Fórum de Educação em Engenharia de Software. Rio de Janeiro, 2008. v. 1. p. 37-45.

Rosa, R. e Kieling, E. (2006) “Planager - Um Jogo para Apoio ao Ensino de Gerência de Projetos de Software”. 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.

Santos, R. P., Santos, P. S. M., Werner, C. M. L. e Travassos, G. H. (2008) "Utilizando Experimentação para Apoiar a Pesquisa em Educação em Engenharia de Software no Brasil", In: I FEES - I Fórum de Educação em Engenharia de Software, 2008, Campinas.

Shaw, K. e Dermoudy, J. (2005) "Engendering an Empathy for Software Engineering", In Proc. Seventh Australian Computing Education Conference (ACE2005). p. 135-144. Newcastle, Australia.

Souza, D. A. C. M., Vasconcelos, C. R. , Azevedo, R., Fujioka, R. C., Almeida, M. J. S. C. e Freitas, F. (2008) “Honey: Um Ambiente Virtual Baseado em Agentes para Apoiar o Ensino de Engenharia de Software”. In: XIX Simpósio Brasileiro de Informática na Educação, 2008, Fortaleza-CE. v. 1. p. 55-64.

Wangenheim, C. G., Thiry, M. e Kochanski, D. (2008) “Empirical evaluation of an educational game on software measurement”. Empirical Software Engineering, v. 1, p. 1-35, 2008.

Wangenheim, C. G. e Shull, F. (2009) “To Game or Not to Game?” Software, IEEE 26, no. 2, p. 92-94.

XXIII SBES - FEES

48

1

Diretrizes para o Ensino Interdisciplinar de Engenharia de Software

Juliana Cristina Braga

Faculdade de Computação e Informática (FCI) – Universidade Presbiteriana Mackenzie (UPM) – São Paulo – SP.

{j.cbraga}@mackenzie.com.br

Abstract. This paper proposes guidelines for practicing the concepts of Software Engineering in several disciplines within the curriculum of undergraduate courses in Computer Science. These guidelines contain how practice will be, what its goals and knowledge necessary to perform it. This knowledge will be represented by video, text, wiki, and organized in a collaborative portal on the Internet. The methodology is based on management's knowledge and can be applied in other areas.

Resumo. O trabalho propõe diretrizes para aplicação dos conceitos de Engenharia de Software em várias disciplinas pertencentes ao currículo da maioria dos cursos de graduação em Ciência da Computação. Essas diretrizes contêm como essa aplicação deverá ser feita, qual o seu objetivo e o conhecimento necessário para realização da mesma. Este conhecimento será representado em vídeos, textos, wiki, e organizado em um portal colaborativo na Internet. A metodologia utilizada é baseada na gestão do conhecimento e poderá ser aplicada em outras áreas.

1. Introdução

A Engenharia de Software (ES) é uma área da Ciência da Computação que contém conhecimento suficiente para auxiliar na criação de diversos tipos de sistemas, sejam eles simples ou complexos. No entanto, os desafios nessa área continuam, pois ainda existem projetos que atrasam, ultrapassam o orçamento, não produzem software de qualidade e nem atendem às necessidades do cliente. Segundo Lethbridge (2007) parte desses problemas de orçamentos, prazos e qualidade são causados por carência de profissionais habilitados nessa área. Essa carência, por sua vez, são resultados de uma educação inadequada, podendo ser comprovada pela pesquisa feita por Sargent (2004) e citada pelo mesmo autor. A pesquisa revela que: (i) apenas 40% dos profissionais da área de informática dos Estados Unidos possuem formação nessa área; (ii) 40% desses conhecem os principais campos da ES, tais como: requisitos, arquitetura, testes, fatores humanos e gestão de projetos; (iii) a maior parte é qualificada em programação e/ou são especialistas em determinados tipos de produtos como ferramentas para gerenciamento de dados e desenvolvimento web, etc; e (iv) existe uma parcela considerável de profissionais que não tem consciência do que não sabem. Apesar de não terem sido encontrados dados estatísticos a respeito no Brasil, acredita-se que a realidade dos profissionais de ES neste país não deve ser diferente. No meio acadêmico, dificuldades no ensino de ES já foram relatadas (Soares, 2000; Castro, 2000; e Hazzan, 2003) (i) muito conteúdo sendo dado em pouco tempo; (ii) baixa motivação que os alunos de ciência da computação possuem para estudar os conceitos teóricos de ES; (iii)

XXIII SBES - FEES

49

2

dificuldades em preparar os estudantes para a prática profissional dentro de ambientes acadêmicos. Esforços estão sendo realizados para diminuir essas dificuldades e esse trabalho encaixa-se nesse contexto.

2. Objetivos

Em vista da importância que o ensino da Engenharia de Software possui e das suas dificuldades, o presente trabalho tem como objetivo geral aumentar a prática da ES dentro das disciplinas oferecida nos cursos de Ciência da Computação e relacionados. Com isso, pretende-se consolidar os conceitos da ES, conscientizar os alunos sobre a sua importância e incentivar sua prática desde o início da graduação até o mercado de trabalho. Os objetivos específicos são: (i) Elaborar diretrizes para aplicação da ES em outras disciplinas; (ii) experimentar aplicar essas diretrizes em uma Universidade; e (iii) avaliar e divulgar os resultados e lições aprendidas desse experimento.

O artigo está organizado como segue: na Seção 3 é apresentada a metodologia utilizada. Na Seção 4 são mostrados os resultados parciais e esperados. Na Seção 5 descrevem-se os trabalhos relacionados e na Sessão 6 as considerações finais.

3. Metodologia

Conforme mencionado no objetivo, esse projeto deverá relacionar a Engenharia de Software (ES) com outras disciplinas. Segundo Piaget (1973), as relações entre as disciplinas podem ocorrer em três níveis: multidisciplinaridade, interdisciplinaridade e transdiciplinaridade. Neste trabalho será abordada a relação de interdisciplinaridade, pois uma interação entre duas ou mais disciplinas deverá ser estabelecida. A metodologia que será utilizada para estabelecer a relação da ES com outras disciplinas será baseada nos processos já consagrados de gestão do conhecimento presentes nos modelos de Liebowitz e Beckman (1998). A escolha da gestão do conhecimento é justificada pelo fato de se considerar as diretrizes propostas equivalentes a conhecimentos que deverão ser gerenciados, ou seja, criados, organizados, armazenados, atualizados e recuperados. Cada processo é representado por uma etapa da metodologia proposta, totalizando assim 7 etapas. Dentro de cada uma dessas etapas outros aspectos também serão considerados, como por exemplo, o gerenciamento de projetos, técnicas para elaboração e validação de conteúdos educacionais, etc. Esses aspectos serão estudados a medida que o projeto for sendo desenvolvido. A definição final da metodologia fará parte dos resultados desse trabalho. A seguir uma breve descrição das tarefas contidas em cada uma dessas 7 etapas:

Etapa 1 – Identificação, conceituação do conhecimento, definição do capital intelectual: Nesta etapa ocorre a identificação e conceituação do conhecimento necessário para aplicar a ES em outras disciplinas. Para isso devem-se descrever as diretrizes de como a ES será aplicada a cada uma das disciplinas, o objetivo pedagógicoque se deseja alcançar, a definição do conteúdo a ser disponibilizado contendo as referências a serem utilizadas para a elaboração do mesmo.

Etapa 2 – Captura do capital intelectual, captura do conhecimento, coleta do conhecimento, importação de metodologias e tecnologias externas: reunião do conhecimento necessário para atender o que foi definido na etapa 1. Esse conhecimento poderá: já existir dentro da instituição em que a metodologia está sendo implantado, estar disponível externamente à instituição e/ou não existir e exigir desenvolvimento utilizando como ponto de partida as referências da Etapa 1. Nessa etapa é necessária vasta revisão bibliográfica, comunicação interna e colaboração externa.

XXIII SBES - FEES

50

3

Etapa 3 – Seleção e validação do conhecimento: seleção e validação, padronização e adequação dos conhecimentos reunidos na Etapa2.

Etapa 4 - Organização e armazenagem do conhecimento, codificação do conhecimento, compilação e transformação do conhecimento: organização e classificação do conhecimento selecionado e validado na Etapa 3. Para essa organização deve-se definir ainda uma metodologia.

Etapa 5 - Compartilhamento do capital intelectual, acesso e disponibilização do conhecimento, transferência do conhecimento, externalização do conhecimento:Disponibilização e divulgação do conhecimento organizado na Etapa 5 através de um portal colaborativo na Internet. A partir da divulgação do conhecimento, as diretrizes já poderão ser aplicadas.

Etapa 6 - criação do conhecimento, geração do conhecimento, busca de soluções criativas, combinações de conhecimentos: o portal ficará preparado para receber outras colaborações, e espera-se seja ampliado englobando outras disciplinas e outras áreas do conhecimento.

Etapa 7 - Avaliação dos benefícios e do valor do conhecimento: monitoramento permanente deverá existir com objetivo de avaliar os benefícios do projeto.

4. Resultados Parciais e Esperados

De acordo com a metodologia implantada, alguns resultados parciais foram obtidos. Em linhas gerais, na Etapa 1 foram definidas as diretrizes para aplicação da ES em outras disciplinas. Na Etapa 2 algum conhecimento já foi reunido e gerado para possibilitar a execução do que foi definido Etapa 1. Na Etapa 3, o conhecimento reunido está sendo selecionado e validado. Na Etapa 4, o conhecimento que foi revisado está sendo organizado. Na Etapa 5, o conhecimento reunido está sendo disponibilizado em um portal de testes denominado Portal Educacional de Engenharia de Software Aplicada (PEESA). Ainda não foram obtidos resultados referentes às Etapas 6 e 7. A seguir uma descrição mais detalhada dos resultados obtidos e esperados em cada um das etapas.

4.1 Resultados parciais da Etapa 1

Nesta etapa foram escolhidas quais disciplinas, inicialmente, deverão aplicar a ES em seu conteúdo. Para cada uma delas foram definidas as diretrizes contendo como, o objetivo e o conteúdo das aplicações. As disciplinas foram escolhidas tomando-se como base o currículo do curso de Ciência da Computação da Universidade Mackenzie que está alinhado com os currículos de referência da Sociedade Brasileira de Computação e ACM/IEEE. Deve-se observar que os objetivos pedagógicos definidos estão sempre buscando criar no aluno o perfil desejável para um bom Engenheiro de Software (Lucena, 2008 e Bagert, 1999) e o hábito de sempre gerar software de qualidade. A seguir uma descrição breve de parte do já foi definida nesta etapa:

• Língua Portuguesa - Como: deve-se solicitar que o aluno faça uma atividade que documente os requisitos de um sistema. O professor dessa disciplina deverá corrigir os erros de português do documento, as frases ambíguas e sem sentido e as inconsistências. Objetivo pedagógico: aumentar a capacidade de especificar software, escrever documentos técnicos com clareza, e destacar que a língua portuguesa também é muito importante para a área de Ciência da Computação. Conteúdo: documento explicativo sobre a atividade, o protótipo do software que será descrito e o modelo de documentação que deverá ser seguido. O aluno não

XXIII SBES - FEES

51

4

precisa entender ainda detalhes sobre o modelo, mas já ficará familiarizado com modelos de especificação do sistema.

• Ética e cidadania I e II - Como: mostrar e discutir o código de ética e práticas profissionais baseadas em oito princípios desenvolvidos pela IEEE Computer Society and the ACM (IEEE-CS,1999). Ler documentos relacionados ao mesmo assunto. Objetivo pedagógico: promover a conscientização da importância da compreensão da ética dentro da ciência da computação. Conteúdo: documento explicativo sobre a atividade, código de ética e o seguinte artigo sugerido para leitura: “How the New Software Engineering Code of Ethics Affects you.” (Gotterbarn,1999).

• Administração: Como: no tópico competência comunicativa verbal deve-semostrar um vídeo aula sobre os casos práticos da dificuldade existente na etapa de elicitação de requisitos. Objetivo pedagógico: é demonstrar a real importância da comunicação para os alunos da Ciência da Computação, que em sua maioria possuem dificuldade nesse aspecto, aumento da capacidade de comunicação. Conteúdo: Para essa atividade estará disponível a vídeo aula.

• Introdução a Algoritmos e Computação - Como: deve-se solicitar que o aluno utilize, além de outras notações, o diagrama de atividades UML para descrever um algoritmo. O professor deverá cobrar dos alunos a utilização de um guia de boas práticas de programação (modelo para documentar e organizar seus programas). Objetivo pedagógico: criação do hábito e a prática, desde o início de sua formação, de projetar software, utilizar boas práticas de programação, como por exemplo, comentar o código, dar nomes mnemônicos para variáveis, etc. Pretende-se assim já iniciar uma cultura de qualidade de software e também introduzir a notação UML. Conteúdo: documento explicativo sobre a atividade, guia de melhores práticas de programação (Mcconnell, 2005), vídeo aula explicando o diagrama de atividades dentro do conceito abordado.

• Linguagem de Programação I e Estruturas de Dados - Como: deve-se, em sala de aula, apresentar os exemplos de classes e objetos utilizando o diagrama de classes e objetos UML. No caso de linguagem de programação I, sugere-se um projeto integrado com a disciplina de Desenvolvimento Orientado a Objetos que é oferecida no mesmo período. Deve-se dar continuidade ao uso do guia de melhores práticas de programação e iniciar a utilização de um controlador de versão para os programas a serem desenvolvidos. Objetivo pedagógico: aumento da capacidade de especificar software, criação do hábito e da prática em projetar software, criação do hábito da programação com qualidade, familiarização com UML, incentivo ao trabalho em equipe. Conteúdo: documento explicativo sobre a atividade, exemplos de classes em UML com código associado e descrição do trabalho de integração com todo material necessário para sua realização.

• Computação Gráfica - Como: devem-se utilizar as ferramentas testes unitáriospara testar os algoritmos de computação gráfica. Sugere-se dar continuidade ao uso do guia de melhores práticas e do controlador de versão. Objetivopedagógico: Mostrar a utilidade das ferramentas de testes, despertando o interesse do aluno para essa sub área de ES que cresce a cada dia, criação do hábito da programação com qualidade. Conteúdo: documento explicativo sobre a atividade, atividade prática do uso de testes unitários em algoritmos de computação gráfica, utilização de módulos educacionais no domínio de testes (Barbosa, 2004).

XXIII SBES - FEES

52

5

• Banco de Dados - Como: exibir a modelagem do banco também utilizando diagramas de classes persistentes em UML. Solicitar entrega de um projeto de banco de dados contendo modelagem e dicionário de dados. O objetivo pedagógico é mostrar a importância da documentação dos dados criando esse hábito nos alunos e aplicar os conceitos de orientação a objetos, e da prática em projetar software. Conteúdo: Para essa atividade encontra-se uma sugestão de trabalho prático que exige esses conceitos e também modelos de diagrama de classe e dicionário de dados.

• Iteração Humana Máquina: Como: aplicar as atividades práticas propostas no trabalho: Uma Metodologia de Ensino para a Disciplina Interação Humano-Computador (Braga, 2005). Objetivo pedagógico: praticar as técnicas de prototipação com foco na usabilidade, validação dos requisitos e testes de avaliação da usabilidade. Conteúdo: Para essa atividade está disponível todo o material necessário para a aplicação da metodologia proposta como, por exemplo: protótipos, fichas de avaliações, etc.

• Trabalho de Graduação I e II: Como: cobrar dos alunos que todos os projetos ligados ao desenvolvimento de software, passem pelas etapas (cabíveis ao projeto) do processo de ES. Deve-se deixar clara a importância da utilização das ferramentas de versionamento principalmente de trabalhos em equipe. Deve-se cobrar do aluno que o código obedeça ao guia de melhores práticas. Objetivo pedagógico: praticar e incentivar a utilização da ES durante o trabalho de graduação, aumento da capacidade de especificar software, criação do hábito e da prática em projetar software, criação do hábito da programação com qualidade, enfatizar a importância das atividades de manutenção de software, incentivo ao trabalho em equipe, aumento da capacidade de comunicação, escrever documentos técnicos com clareza. Para essa atividade será disponibilizado um exemplo de trabalho de graduação que utilizou essa modelagem.

• Programação de Jogos - Como: solicitar que o aluno faça plano de testes, testes unitários, testes de integração, casos de teste e relatório de teses. Objetivopedagógico: mostrar a importância da área de testes para o desenvolvimento de jogos. Conteúdo: Para essa atividade será disponibilizado o modelo da documentação e o tutorial de istalação de plugins de testes unitários.

Diretrizes para outras disciplinas, detalhes sobre como o professor deverá avaliar cada uma das atividades e as referências que serão utilizadas para geração do conhecimento foram omitidos por restrição de espaço. Até o momento, observou-se um grande interesse dos professores de outras disciplinas em utilizar a ES em sua disciplina. Além disso, os professores de áreas diferentes da computação consideram a abordagem desse projeto uma maneira de motivar os alunos de CC no estudo de sua disciplina.

4. 2 Resultados Obtidos e Esperados da Etapa 2

Nesta etapa foram reunidos conhecimentos internos e identificados, através de revisão bibliográfica, conhecimentos externos que servirão de apoio para a execução das aplicações sugeridas na Etapa 1. Essa etapa é contínua e um levantamento bibliográfico deverá ser exaustivo para poder descobrir quais metodologias e ferramentas na área de Educação podem ser aproveitadas para o escopo desse projeto.

XXIII SBES - FEES

53

6

4.3 Resultados Obtidos Esperados da Etapa 3 e 4 e 5

O conhecimento reunido na etapa 1 será disponibilizado no portal do projeto. A organização desse portal será, inicialmente, baseada no Guide to the Software Engineering (Bagert, 1999) que foi construído baseado no SWEBOK (Abran, et al., 2001).

4.4 Resultados Esperados da Etapa 6

Deste ponto em diante espera-se que o projeto adquira vida própria, onde os professores poderão estar em constante uso e colaboração do conhecimento através do portal.

4.5 Resultados da Etapa 7

O portal deverá possuir ferramentas de controle de acesso para controlar as colaborações. Paralelo a isso, serão disponibilizados questionários para coletar “feedebacks” dos professores que aplicaram a ES em suas disciplinas. Uma análise dos dados será feita e os resultados publicados. Pretende-se ainda investigar melhor as práticas utilizadas para organizar documentos educacionais, como por exemplo: Mecanismos e abordagens de apoio à modelagem de conteúdos educacionais (Barbosa, 2004). Pretende-se investigar também a utilização de ontologias para apoiar a aquisição, organização, reúso e compartilhamento de conhecimento sobre processos de softwares.

5. Trabalhos relacionados e Abrangência

Assim como este trabalho, diferentes abordagens têm sido adotadas na tentativa de melhorar o ensino de Engenharia de Software (ES), dentre elas encontram-se: metodologias de ensino (Soares, 2000; Castro, 2000; e Hazzan, 2003), Jogos e/ou ferramentas (Tao e Qing, 2009; Baker et al., 2003), estudos de caso (Barros e Araujo, 2008; Hilburn, 2007), estudos empíricos (Santos, et al., 2008; Hilburn, 2006). A principal diferença desses trabalhos para o presente, é que aqueles não utilizam a interdisciplinaridade. Outros trabalhos abordam a ES juntamente com outras disciplinas (Cunha, et al., 2008, Silva, 2008; Hilburn, 2006; Santos, 2007; Alves, 2006). No entanto, a ES é utilizada, mas não é desenvolvida dentro delas como é o caso deste trabalho. Além disso, as outras disciplinas estão sempre dentro da área de exatas, sendo que neste trabalho sugere-se relacionar a ES também com disciplinas pertencentes ao domínio de humanas como: Português, Administração e Ética. Esses trabalhos relacionados podem ser utilizados como referências nas diretrizes do presente trabalho. O trabalho apresentado por Werneck (2008) aborda a adoção dos conceitos de ES em outras disciplinas e também pretende obter resultados dessa abordagem. No entanto, o mesmo trabalho não adota os processos de gestão de conhecimento e não propõe a elaboração de diretrizes. Os resultados deste trabalho e o proposto por Wenerck podem ser complementares. O trabalho de Prikladnicki (2006) objetivou discutir a construção do conhecimento na Engenharia de Software, e entender como pesquisas multi, inter e transdisciplinares podem contribuir para a evolução das pesquisas neste contexto. Esse trabalho está sendo utilizado como fundamentação teórica para este. O trabalho mais próximo até o momento encontrado foi o proposto por Hilburn (2002), que sugere a aplicação da qualidade de software durante todo o currículo. O presente trabalho também tem o mesmo propósito, com as diferenças de fornecer a base de conhecimento e abordar outros conceitos de ES e não somente a qualidade de software.

XXIII SBES - FEES

54

7

6. Considerações Finais Este trabalho objetiva melhorar o ensino de ES através da aplicação de seus conceitos em outras disciplinas do curso de Ciência da Computação. Para isso, ele propõe diretrizes que indicarão, para cada disciplina, como aplicar a ES, qual o objetivopedagógico dessa aplicação, e o conhecimento necessário para que a aplicação seja realizada com êxito. Esse conhecimento será representado por vídeos, transparências, textos, wiki (Leuf, 2001), e referências externas que serão organizadas e disponibilizadas em um portal colaborativo na Internet. O portal também receberá “feedbacks” das aplicações das diretrizes propostas que futuramente serão analisados e publicados. A metodologia desse projeto é genérica e poderá ser estendida para a integração entre outras disciplinas diferentes das que foram mencionadas e entre disciplinas de cursos distintos. O projeto possui baixo custo de implantação, pois não exige acréscimos de horas e nem criação de novas disciplinas no currículo. As principais contribuições desse trabalho são: (i) fornecer diretrizes associadas à conteúdo didático para serem aplicadas, sendo este o principal incentivador da utilização dessas diretrizes; (ii) fornecer resultados empíricos da interdisciplinaridade, o que poderá ajudar em outras pesquisas; (iii) incentivar a interdisciplinaridade na Ciência da Computação sendo esta apontada como fator importante no documento Grandes Desafios da Pesquisa em Computação no Brasil (SBC, 2004).

7. ReferênciasAbran, A., Bourque P., Dupuis R. and Moore. J. D. (2001), “Guide to the Software Engineering

Body of Knowledge – SWEBOK”, IEEE Press. Bagert D.J. et al. (1999), “Guidelines for Software Engineering Education”, Version 1.0,

Software Eng. Inst., Carnegie Mellon Univ., Pittsburgh, Nov. Baker, A.; Navarro, E.O.; van der Hoek. (2003), A. “An experimental card game for teaching

software engineering”, Software Engineering Education and Training, Proceedings. 16th Conference on Volume , Issue , 20-22 March 2003 Page(s): 216 – 223.

Barbosa, E. F. (2004),“Uma contribuição ao processo de desenvolvimento e modelagem de módulos educacionais”, Tese de Doutorado - Universidade de São Paulo, Instituto de Ciências Matemáticas e de Computação, São Carlos - SP, Brasil. Orientador: José Carlos Maldonado.

Barros, M. O., Araújo, R. M. (2008), “Ensinando Construção de Software Aplicada a Sistemas de Informação do Mundo Real”, In: Fórum de Educação em Engenharia de Software Outubro.

Braga, J. C., Marucci, R. A. (2006), “Proposta de uma Metodologia de Ensino para a Disciplina Interação Humano-Computador”. In: WEI - Workshop de Educação em Computação, 2006, Campo Grande. Anais do XXVI Congresso da SBC p. 215-225.

Castro, J.F.B, Gimenes, I.M.S, Maldonado,J.C. (2000), “Uma proposta de Plano Pedagógico para a matéria Engenharia de Software”. In: II curso de qualidade de cursos de graduação da area de Computação e Informática, Curitiba, pp. 251-270.

Cunha, A.M., et al. (2008), “Estudo de Caso abrangendo o Ensino Interdisciplinar de Engenharia de Software” , Fórum de Educação em Engenharia de Software (FEES), Campinas – SP, out.

Lucena, F. N. (2008), “Projeto Pedagógico do Curso Bacharelado em Engenharia de Software – Universidade Federal de Goiás – UFG”.

Hazzan,O., Dubinsky,Y., (2003). “Teaching a Software Development Methodology: The case of Extreme Programming”, Proceedings of the 16th Conference on Software Engineering Education and Training (CSEE&T 2003), Espanha, pp. 176-184.

Hilburn, T.B.; Towhidnejad, M., (2007), “Case for Software Engineering”, Software Engineering Education & Training, 20th Conference on Volume , Issue , 3-5 July 2007 Page(s):107 – 114

XXIII SBES - FEES

55

8

Hilburn, Y. Towhidnejad, M, (2002), “Software quality across the curriculum”, in: Frontiers in Education, 2002. FIE 2002. 32nd Annual, 6-9 Nov. 2002, Volume: 3, pg, S1G-18- S1G-23 vol.3

Hilburn, T.B.; Towhidnejad, M.; Nangia, Shen, S., L., (2006), “A Case Study Project for Software Engineering Education Frontiers”. Education Conference, 36th Annual Volume , Issue , 27-31 Oct. Page(s):1 – 5

IEEE-CS, (1999), “Software Engineering Code of Ethics and Professional Practice,” IEEE-CS/ACM.

Lethbridge, T.C.; Diaz-Herrera, J.; LeBlanc, R.J.; Thompson, J.B., (2007), “Improving software practice through education: Challenges and future trends”, Future of Software Engineering, 2007. FOSE apos;07, Volume , Issue , 23-25 May, Page(s):12 – 28.

Leuf, B., Cunningham, W., (2001), “The Wiki Way”, Quick Collaboration of the Web. Addison-Wesley.

Liebowitz J. and Beckman T., (1998), “Knowledge Organizations: What Every Manager Should Know”, St. Lucie Press, Boca Raton, Fla.

Mcconnell, S., (2005), “Code Complete: um Guia Prático para a Construção de Software”, 2a edição, Bookman.

Meyer, B., (2001), “Software Engineering in the Academy Computer”, Los Alamitos, v. 34, n. 5, pp. 28-35, May.

Piaget, Jean., (1973) “The epistemology of interdisciplinary relationships”. In Iterdisciplinarity, pp. 127-39, and Main Trends in Inter-Disciplinary Research, New York: Harperan Row.

Prikladnicki, Rafael (2006), Audy, Jorge Luis Nicolas . “Construção de Conhecimento e Complexidade na área de Engenharia de Software”. In: WOSES 2006 - II Workshop Um Olhar Sócio-Técnico sobre a Engenharia de Software, Vila Velha. p. 51-64.

Santos, R. P., et al. (2008), “Utilizando Experimentação para Apoiar a Pesquisa em Educação em Engenharia de Software no Brasil”, Fórum de Educação em Engenharia de Software (FEES), Campinas – SP, out.

Sargent, J., (2004) “An Overview of Past and Projected Employment Changes in the Professional IT Occupations”. Computing Research News, 16, 3, May, pp. 1, 21.

Soares, M. S., (2008) “Uma experiência de ensino de Engenharia de Software orientada a trabalhos práticos”. Fórum de Educação em Engenharia de Software (FEES), Campinas – SP, out.

Sociedade Brasileira de Computação (SBC), (1999), “Currículo de Referência da SBC para Cursos de Graduação em Computação e Informática”. Sociedade Brasileira de Computação – SBC.Set.

Sociedade Brasileira de Computação (SBC), (2004), Grandes Desafios da Pesquisa em Computação no Brasil 2006 até 2016, Sociedade Brasileira de Computação - SBC, 2004. 22p.

Tao W., Qing Z., (2009), “A Software Engineering Education Game in a 3-D Online Virtual Environment”, vol. 2, pp.708-710, First International Workshop on Education Technology and Computer Science.

Don Gotterbarn, (1999), "How the New Software Engineering Code of Ethics Affects You", IEEE Software, vol. 16, no. 6, pp. 58-64, Nov./Dec.

Werneck, V., M., B., et al., (2008), “Engenharia de Software no Curso de Ciência da Computação”, Fórum de Educação em Engenharia de Software (FEES), Campinas – SP, out.

XXIII SBES - FEES

56

Elaboração de um Survey para a Caracterização do Cenáriode Educação em Engenharia de Software no Brasil

Marcelo Schots1, Rodrigo Santos1, Andréa Mendonça2, Cláudia Werner1

1 COPPE/UFRJ, Universidade Federal do Rio de Janeiro, BrasilCaixa Postal 68511 CEP 21945-970 Rio de Janeiro, RJ

2 DSC/UFCG, Universidade Federal de Campina Grande, BrasilCaixa Postal 10106 CEP 58109-970 Campina Grande, PB

{schots, rps, werner}@cos.ufrj.br, andrea@dsc.ufcg.edu.brAbstract. The Software Engineering (SE) research community has been trying to improve SE education. However, attempts to characterize the Brazilian scenario from the educator have not been found, and this hampers to identify problems and challenges in this community, as well as reusing existing solutions. In this sense, this paper presents the preparation of a survey which aims at characterizing the Brazilian SE teaching and learning scenario. This survey is part of a strategy to support collaborative, large scale research in SE education in Brazil.Resumo. A comunidade de pesquisa em Engenharia de Software (ES) temrealizado esforços no sentido de melhorar a educação nesse domínio.Contudo, ainda não foram observadas iniciativas para caracterizar o cenário brasileiro, do ponto de vista dos educadores, o que dificulta a identificação de problemas e desafios desta comunidade, bem como a reutilização de soluções já existentes. Nesse sentido, este artigo apresenta a elaboração de um surveyque visa caracterizar o processo de ensino e aprendizagem de ES no cenário brasileiro. Este survey faz parte de uma estratégia de apoio à pesquisa colaborativa e em larga escala em educação em ES no Brasil.

1. IntroduçãoComo disciplina acadêmica, a ES é relativamente nova [Boehm, 2006], e a educação de seus princípios e práticas tem recebido uma atenção especial da comunidade, em virtudedas demandas dos sistemas de software atuais, que exigem escalabilidade, distribuição, integração de diferentes tecnologias etc. [Lethbridge et al., 2007]. No cenário internacional, existem alguns trabalhos que descrevem aspectos que permeiam a educação em ES (problemas, soluções e desafios) [Freeman et al., 1976] [Carver, 1987] [Shaw, 2000], inclusive esforços visando à caracterização dos cursos de ES por meio de surveys (pesquisas de opinião) [Petricig & Freeman, 1984] [Werth, 1987].

Por outro lado, as iniciativas para melhorar o contexto de educação em ES noBrasil ainda são isoladas e localizadas, o que dificulta a sua disseminação e utilização em larga escala [Santos et al., 2008]. Tal carência dificulta a percepção e a avaliação de alguns aspectos, tais como: (1) em que situação se encontra a educação em ES no Brasil, comparada ao cenário internacional; (2) quais são os problemas e desafios da educação em ES no Brasil; e (3) quais são as questões de pesquisa prioritárias e estratégicas que impactam a indústria de software brasileira.

XXIII SBES - FEES

57

Dessa forma, este artigo apresenta a instanciação de uma das etapas do projeto EduES Brasil, correspondente a um survey (ou pesquisa de opinião) que visacaracterizar o cenário de educação em ES no Brasil, sob o ponto de vista da comunidade de educadores. O artigo está organizado da seguinte forma: na Seção 2, é brevemente descrito o projeto EduES Brasil, em cujo contexto o survey está inserido; a Seção 3 mostra o objetivo do survey e dados a respeito do estudo piloto realizado; por fim, aSeção 4 apresenta as considerações finais e trabalhos futuros.

2. Projeto EduES BrasilO projeto EduES Brasil [Santo et al., 2009] consiste de uma estratégia de pesquisacolaborativa, distribuída, especializada e em larga escala sobre educação em ES focada em experimentação. A estratégia visa caracterizar o processo de ensino e aprendizagem de ES, com base em quatro etapas integradas, a saber: uma revisão informal da literaturapara embasar uma posterior revisão sistemática [Biolchini et al., 2007], a ser executada por pesquisadores especialistas em uma área de pesquisa em ES (e.g., teste, qualidade, modelagem etc.), podendo viabilizar a definição e a execução de uma pesquisa de opinião com uma comunidade de educadores de ES para avaliar os resultados obtidos e prover a organização de um corpo de conhecimento em educação em ES no Brasil.

Uma das iniciativas do projeto EduES Brasil está na elaboração de um survey,permitindo a identificação de problemas e dificuldades, soluções comumente adotadas,desafios e peculiaridades da educação em ES no país. Esta iniciativa busca favorecer aorganização e implementação de ações e pesquisas direcionadas ao processo deformação de recursos humanos, buscando resultados que possam, posteriormente,refletir de maneira positiva na indústria de software. Neste contexto, este survey é um exemplo da realização da etapa pesquisa de opinião, visando confrontar os resultados obtidos na caracterização inicial dos aspectos que permeiam a educação em ES [Santos et al., 2008], que, por sua vez, exemplifica a etapa de revisão informal da literatura.

3. Definição de um Survey para Caracterizar a Educação em ES no BrasilEste survey foi desenvolvido como uma pesquisa experimental de cunho geral paraverificar, dentre outros aspectos, se as preocupações apontadas no cenário internacionalse refletem ou não no Brasil. O survey contém questões objetivas e discursivas, visando permitir que os educadores expressem suas experiências e percepções, com base em suas respectivas realidades.

3.1. Objetivo e Caracterização do SurveyO objetivo do survey, descrito segundo a abordagem GQM [Basili et al., 1994], éanalisar o ensino de ES com o propósito de caracterizar o estado da prática nocenário nacional, com respeito à identificação de problemas recorrentes, soluções já adotadas e direcionamentos em prol de um ensino de melhor qualidade, sob o ponto de vista de educadores na área de ES no Brasil no contexto de disciplinas e cursos presenciais de ES no nível de graduação.

O survey tem caráter exploratório, isto é, por meio deste estudo experimental, pretende-se obter informações que permitam realizar uma caracterização inicial efetiva da educação em ES no Brasil. Além disso, sua aplicação dar-se-á de forma não-supervisionada, ou seja, os participantes responderão ao survey seguindo as instruções

XXIII SBES - FEES

58

descritas, sem supervisão ou prestação de auxílio por parte de terceiros. A população alvo é composta por educadores da área de ES que atuam em instituições de ensino nacionais (modalidade presencial), e a seleção da amostra será realizada através de pesquisas na plataforma Lattes1 e no grupo de discussão on-line EduES2.

O survey foi estruturado em três partes. A primeira parte é responsável por identificar a atuação do participante na área de ES. Já a segunda parte tem por objetivo caracterizar a instituição e o curso em que o participante atua e ministra disciplinas da área de ES. Por fim, a terceira parte almeja caracterizar o processo de ensino e aprendizagem de ES no curso e na instituição na qual o participante atua, de forma a identificar estratégias e problemas durante o processo de ensino e aprendizagem.

3.2. Organização e Execução do Estudo PilotoA fim de realizar uma avaliação prévia do survey, de forma a permitir a identificação de refinamentos necessários e examinar a adequação do instrumento a ser utilizado, foi conduzido um estudo piloto. Foram convidados para participar do estudo alunos de doutorado e de mestrado na linha de ES de dois programas de pós-graduação: (1) Programa de Pós-Graduação em Ciência da Computação da UFCG3; e (2) Programa de Pós-Graduação em Engenharia de Sistemas e Computação da COPPE/UFRJ4. O estudo também contou com um participante recém-doutorado pela COPPE/UFRJ.

A amostra do estudo piloto foi selecionada por conveniência. Inicialmente, foi enviado por e-mail um convite para as listas de discussão de dois grupos de pesquisa existentes nas linhas de ES da COPPE/UFRJ. No caso da UFCG, foram enviados e-mails específicos para os alunos da área de ES (8 alunos foram convidados). Foram selecionados os alunos que poderiam contribuir com o estudo, considerando experiência prévia em ensino, formação (identificada por meio dos dados disponíveis nas páginas web dos programas de pós-graduação) e disponibilidade para participar do estudo experimental. A partir disso, o link do survey on-line foi enviado apenas para os alunosque manifestaram interesse, respondendo ao convite enviado.

A taxa de respondentes da UFCG foi de 37,5% (3 participantes). No caso daCOPPE/UFRJ, sabe-se que, com base no número de membros das listas de discussão(52 inscritos), 11,54% participaram do estudo piloto (6 participantes). Nem todos os participantes destas listas faziam parte da população alvo; portanto, tal valor não pode ser considerado como taxa de respondentes. As observações extraídas da aplicação desteestudo piloto trouxeram as seguintes contribuições: (1) foi possível estimar o tempo de resposta; (2) algumas questões foram removidas, adaptadas ou combinadas; (3) as instruções de preenchimento e a descrição da população alvo foram mais bem detalhadas. Foi possível também vislumbrar possíveis ameaças à validade do estudo.

4. Considerações FinaisEste artigo apresentou a elaboração de um survey para caracterizar o cenário de educação em ES no Brasil do ponto de vista da comunidade de educadores. As contribuições deste trabalho incluem a captura dos resultados do estudo piloto, para que

1 Plataforma Lattes, disponível em: http://lattes.cnpq.br/2 Grupo de Discussão sobre Educação em ES, disponível em: http://groups.google.com.br/group/edues3 Página web do COPIN/UFCG, disponível em http://www.copin.ufcg.edu.br/4 Página web do PESC/COPPE/UFRJ, disponível em http://www.cos.ufrj.br/

XXIII SBES - FEES

59

fossem realizados os ajustes necessários para a aplicação do survey em larga escala. No contexto do projeto EduES Brasil, o artigo também contribui como exemplo de um plano de pesquisa de opinião que os pesquisadores de educação em ES realizarão para atestar os resultados das revisões sistemáticas, no escopo da estratégia de pesquisa.

Com a análise dos dados obtidos com a execução do survey, vislumbra-semotivar discussões junto à comunidade de ES no Brasil em temas como: (1) estratégias para minimizar as dificuldades de ensino-aprendizagem; (2) dificuldades e discrepâncias em ensino considerando diferentes regiões do país; (3) adaptações noensino para atender as demandas da indústria de software; e (4) características peculiares dos cursos de graduação em ES recém-criados, comparadas às de outroscursos de graduação na área de Computação. Um pacote experimental está sendo elaborado, de forma a permitir a reutilização deste estudo adaptada a contextos e populações semelhantes (e.g., educação à distância).

O survey foi refinado diante das observações realizadas com o estudo piloto, e entrará em execução até setembro de 2009. Espera-se que a análise dos resultados dosurvey favoreça a detecção de indícios que permitam a construção de hipóteses de investigação científica, motivando o estabelecimento das comunidades de educadores ede pesquisadores em educação em ES.

AgradecimentosOs autores agradecem a CAPES, o CNPq e a FAPEAM pelo apoio financeiro na realização deste trabalho, e a todos os participantes do estudo piloto pelas contribuições e sugestões dadas.

ReferênciasBasili, V.; Caldiera, G.; Rombach, D. H. (1994) The Goal Question Metric Approach . Encyclopedia of

Software Engineering, John Wiley & Sons, v. 2.Biolchini, J. C. A.; Mian, P. G.; Natali, A. C. C.; Conte, T. U.; Travassos, G

Advances Engineering Informatics 21, 2, 133-151.

Boehm, B. (2006) Proceedings of the 28th International Conference on Software Engineering , Shanghai, China, 12-29.

Carver, D. L. (1987) Recommendations for Software Engineering Education . ACM SIGCSE Bulletin19, 1 (February), 228-232.

Freeman, P.; Wasserman, A. I.; Fairley, R. E. (1976) Essential Elements of Software Engineering Education In: Proceedings of the 2nd ICSE, San Francisco, USA, 116-122.

Lethbridge, T. C.; Diaz-Herrera, J.; Leblanc, R. J.; Thompson, J. B. (2007) Improving Software Practice through Education: Challenges and Future Trends. In: Proceedings of the Conference on The Future of Software Engineering, 29th ICSE, Minneapolis, USA, 12-28.

Petricig, M.; Freeman, P. (1984) Software Engineering Education: A Survey . ACM SIGCSE Bulletin,16, 4 (December), 18-22.

Santo, R. E.; Portal EduES Brasil: Um Ambiente para Apoiar a Pesquisa em Educação em Engenharia de Software no Brasil IIFEES, XXIII Simpósio Brasileiro de Engenharia de Software, Fortaleza, Brasil.

Santos, R. P.; Santos, P. S. M.; Werner, C. M. L.;. In: Anais do I FEES,

XXII Simpósio Brasileiro de Engenharia de Software, Campinas, Brasil, 55-64.Shaw, M. (2000) Software Engineering Education: A Roadmap In Proceedings of the Conference on

the Future of Software Engineering, 22nd ICSE, Limerick, Ireland, 371-380.Werth, L. H. (1987) Software Engineering Education: A Survey of Current Courses . ACM SIGSOFT

Software Engineering Notes 12, 4 (October), 19-26.

XXIII SBES - FEES

60