cbsoft 2010 fees anais

http://cbsoft.dcc.ufba.br

A N A I S

Foto: MaWá

Foto: MaWá

FEESIII Fórum de Educação em Engenharia de Software

Volume 5 ISSN 2178-6097

FEES 2010 III Fórum de Educação em Engenharia de Software 01 de Outubro de 2010 Salvador • Bahia • Brasil

ANAIS Coordenador do Comitê de Programa e Editor Márcio de Oliveira Barros Coordenadores Locais do SBES Christina von Flach Garcia Chavez Cláudio Nogueira Sant’Anna Coordenador Geral do CBSOFT Manoel Gomes de Mendonça Neto Realização LES • Laboratório de Engenharia de Software DCC • Departamento de Ciência da Computação UFBA • Universidade Federal da Bahia Promoção SBC • Sociedade Brasileira de Computação

Sistema de Bibliotecas - UFBA

Congresso Brasileiro de Software: Teoria e Prática (2010 : Salvador, BA).

Anais [do] Congresso Brasileiro de Software : Teoria e Prática, Salvador, BA, 27 de setembro a 01 de outubro de 2010 / organização UFBA, LES, DCC ; coordenador geral. - Salvador : SBC, 2010. 12 v. Inclui 10 eventos satélites Conteúdo: v. 5 - Fórum de Educação em Engenharia de Software ( 3. : 2010 : Salvador, BA) 1.Software - Brasil - Congressos. I. Fórum de Educação em Engenharia de Software ( 3. : 2010 : Salvador, BA). II. Universidade Federal da Bahia. Instituto de Matemática. Departamento de Ciência da Computação. III. Laboratório de Engenharia de Software. IV. Sociedade Brasileira de Computação. V. Mendonça Neto, Manoel Gomes de. VI. Título

CDD - 005

III Fórum de Educação em Engenharia de Software

iii

Apresentação O avanço dos cursos de graduação em Engenharia de Software torna ainda mais importante a discussão sobre educação e treinamento em nosso domínio de conhecimento. A Engenharia de Software é um domínio complexo, onde aspectos técnicos e sociológicos convivem em um ambiente onde a natureza e o arcabouço tecnológico impõem cada vez um número menor de restrições.

A diversidade de temas pertinentes ao domínio confere um aspecto especial às práticas utilizadas na educação e no treinamento. 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.

Portanto, não é de espantar o crescimento de interesse nesta terceira edição do FEES. Foram submetidos 26 artigos ao Fórum, envolvendo diversas regiões do país – 1 da região Sul, 7 do Sudeste, 5 do Centro-Oeste, 8 do Nordeste e 3 do Norte – e do exterior – 2 artigos. Desses, 8 foram aceitos para apresentação e publicação nos anais. Cada artigo foi avaliado por, pelo menos, três membros do Comitê de Programa, segundo critérios pré-estabelecidos. O coordenador tomou a decisão final a partir de análise dos comentários dos avaliadores e da relevância do tema do artigo para o fórum.

Além da apresentação e discussão dos artigos supracitados, teremos um painel no dia 01 de Outubro destinado a debater os currículos de graduação em Engenharia de Software, com depoimentos da área acadêmica, do Governo e da indústria. Esperamos que esse debate possa contribuir para aprimorar o ensino de Engenharia de Software.

Gostaríamos de agradecer mais uma vez aos autores e revisores. O trabalho cuidadoso dos revisores continua sendo uma marca desse Fórum, contribuindo tanto para o debate como para a qualidade dos textos publicados. Agradecemos, também, o apoio da organização local do CBSOFT, nas pessoas de Christina von Flach Garcia Chavez e Cláudio Nogueira Sant’Anna e suas equipes, assim como ao Coordenador Geral do CBSOFT, Manoel Gomes de Mendonça Neto.

Esperamos que o Fórum seja uma experiência positiva para todos.

Salvador, Outubro de 2010.

Márcio Barros Coordenador do Comitê de Programa do FEES 2010

iv

Biografia do Coordenador

Márcio Barros é professor adjunto da Escola de Informática Aplicada da Universidade Federal do Estado do Rio de Janeiro (UNIRIO), onde lidera um grupo de pesquisa que aplica buscas heurísticas e otimização para resolver problemas relacionados com gerência de projetos e projeto de software (software design). Suas áreas de interesse também incluem modelagem e simulação

aplicados a processos e a gerência de projetos. Márcio obteve seu Doutorado em Engenharia de Sistemas e Computação pela Universidade Federal do Rio de Janeiro (COPPE/UFRJ), em 2001. Já orientou mais de 10 dissertações de Mestrado e publicou diversos artigos científicos. Márcio é membro da Sociedade Brasileira de Computação.


v

Comitê de Programa Adenilso Simao, ICMC-USP, Brazil Ana Regina Rocha, COPPE/UFRJ, Brazil Andréa Mendonça, UFCG, Brazil Christiane Gresse von Wangenheim, UFSC, Brazil Christina Chavez, UFBA, Brazil Claudia Werner, COPPE/UFRJ, Brazil Daltro Nunes, UFRGS, Brazil Eduardo Almeida, UFBA, Brazil Ellen Francine Barbosa, ICMC-USP, Brazil Flavia Santoro, UNIRIO, Brazil Gleison Santos, UNIRIO, Brazil Itana Maria de Souza Gimenes, UEM, Brazil Julio Leite, PUC-Rio, Brazil Paulo Pires, UFRN, Brazil Rafael Prikladnicki, PUCRS, Brazil Renata Araujo, UNIRIO, Brazil Simone Barbosa, PUC-Rio, Brazil Valter Camargo, UFSC, Brazil

Revisores Externos Marcelo Schots Marco Aurélio Graciotto Silva Ricardo Argenton Ramos Rodolfo de Souza Barbeiro Rodrigo Santos

vi

Comitê Organizador Coordenação Local SBES Christina von Flach Garcia Chavez (DCC/IM/UFBA) Cláudio Nogueira Sant’Anna (DCC/IM/UFBA) Coordenador Geral do CBSoft Manoel Mendonça (DCC/IM/UFBA) Vice-Coordenadora do CBSoft Vaninha Vieira (DCC/IM/UFBA) Coordenação Local SBES Christina Chavez (DCC/IM/UFBA) Claudio Sant'Anna (DCC/IM/UFBA) Coordenação Local SBCARS Eduardo Almeida (DCC/IM/UFBA) Adolfo Almeida Duran (CPD/UFBA) Coordenação Local SBLP Lais N. Salvador (DCC/IM/UFBA) Rita Suzana P. Maciel (DCC/IM/UFBA) Time de OrganizaçãoAntonio Terceiro (DMCC/UFBA) Antonio Oliveira (DMCC/UFBA) Bruno Carreiro (DMCC/UFBA) Glauco Carneiro (DMCC/UFBA) Ivan Machado (DMCC/UFBA)

Leandro Andrade (CC/UFBA) Raphael Oliveira (DMCC/UFBA) Renato Novais (DMCC/UFBA e IFBA) Rodrigo Rocha (DMCC/UFBA) Yguaratã Cavalcanti (CIn/UFPE)

Apoio Executivo DAGAZ Eventos


vii

Índice Um Jogo de Estratégia de Gerência de Configuração ................................................ 1

Karen Figueiredo (UFF), Jonatas Ferreira (UFF), Leonardo Murta (UFF), Esteban Clua (UFF) O Poder da Tecnologia de Workflow e dos Mapas Conceituais no Processo de Ensino e Aprendizagem da UML ............................................................................... 9

Simone Sawasaki Tanaka (UEL, UNIFIL), Rodolfo Miranda de Barros (UEL), Sergio Akio Tanaka (UNIFIL)

SimulES-W: Um Jogo para o Ensino de Engenharia de Software ........................... 17

Elizabeth Suescún Monsalve (PUC-Rio), Vera Maria B. Werneck (UERJ), Julio Cesar Sampaio do Prado Leite (PUC-Rio)

Ensino da Engenharia de Software por meio de Fábricas de Software no contexto Distribuído: Um Relato de Experiência .................................................................... 27

Catarina Costa (UFPE), Rodrigo Rocha (UFPE), Jair Figueirêdo (UFPE), Marcos Duarte (UFPE), Sílvio Meira (UFPE), Rafael Prikladnicki (PUCRS)

Avaliação do Componente Curricular Interdisciplinar de Engenharia de Software .................................................................................................................... 35

David Moises B. Santos (UEFS), Hugo Saba (UEFS)

Graduação em Engenharia de Software: uma proposta de flexibilização e interdisciplinaridade ................................................................................................. 43

Rejane M. da C. Figueiredo (UnB), Luiz C. M. Ribeiro Jr (UnB), André B. de Sales (UnB), Edna Dias Canedo (UnB), Ricardo Matos Chaim (UnB), Adson Rocha (UnB), Giovanni Almeida Santos (UnB), Cristiane Soares Ramos (UnB)

Graduação em Engenharia de Software versus Graduação em Engenharia de Computação: uma reflexão ....................................................................................... 51

Rejane M. da C. Figueiredo (UnB), Luiz C. M. Ribeiro Jr (UnB), Cristiane S. Ramos (UnB), Edna Dias Canedo (UnB)

O Curso de Engenharia de Software da UFRN......................................................... 59

David Deharbe (UFRN), Eduardo Aranha (UFRN), Jair Leite (UFRN), Marcel Oliveira (UFRN), Paulo Pires (UFRN), Uirá Kulesza (UFRN), Umberto Costa (UFRN)

Um Jogo de Estratégia de Gerência de Configuração

Karen Figueiredo, Jonatas Ferreira, Leonardo Murta, Esteban Clua

Instituto de Computação – Universidade Federal Fluminense (UFF)

{kfigueiredo, jferreira, leomurta, esteban}@ic.uff.br

Resumo. A utilização de jogos na educação é uma prática que vem ganhando

destaque, tendo em vista seus benefícios no processo de ensino e aprendiza-

gem. Desta forma, este artigo propõe o JEEES, que é um jogo de estratégia

inovador, com intuito de transmitir conhecimentos de Gerência de Configura-

ção. Além da descrição do JEEES, este artigo também apresenta uma avalia-

ção preliminar do jogo em turmas de engenharia de software.

1. Introdução

Os jogos são elementos presentes na nossa vida desde a infância, inicialmente como

exercício onde a criança repete determinada situação por puro prazer. Posteriormente,

com uma idade mais avançada, os jogos tendem a se tornar estratégicos e regrados [Sil-

va 2009]. Estimulados pela corrente pedagógica do construtivismo, que ressalta a parti-

cipação do aluno na construção de seu próprio conhecimento por meio de suas intera-

ções, os jogos começaram a ser utilizados no âmbito educacional [Tarouco et al. 2004].

De tal modo, quando elaborados com intuito educativo, os jogos podem receber diferen-

tes nomenclaturas tais como: jogos educacionais ou educativos, jogos de aprendizagem

ou jogos sérios (do inglês, serious games), sendo que alguns tipos de simuladores tam-

bém podem ser considerados jogos educacionais [Savi 2008].

Segundo Tarouco et al. (2004), os jogos educacionais são importantes ferramen-

tas instrucionais já que os mesmos divertem e motivam os alunos, facilitando assim o

aprendizado e aumentando a capacidade de retenção do que foi ensinado. Além do cará-

ter motivacional, os jogos educativos ajudam os alunos a desenvolverem uma série de

habilidades e estratégias e, por isso, começam a ser tratados como importantes materiais

didáticos [Gros 2003]. O fato dos jogos implicarem em uma imersão e participação ati-

va do usuário ressalta ainda mais o potencial de aprendizagem e fixação de conteúdo.

Dentre as várias disciplinas da Engenharia de Software, a Gerência de Configu-

ração (GC) assume um papel fundamental de apoio ao controle da evolução [Dart 1991]

durante o desenvolvimento e, em especial, durante a manutenção de software . Contudo,

em 2005 somente 25% de um total de 2500 empresas brasileiras faziam uso de GC

[MCT 2006]. Apesar da sua importância e da baixa adoção na indústria brasileira, raros

trabalhos relatam esforços relacionados ao ensino de GC [Bendix 2001], e nenhum tra-

balho relata a adoção de jogos com esse propósito.

Desta forma, o objetivo deste artigo é propor um jogo educacional baseado em

Engenharia de Software que visa ensinar especificamente conceitos e práticas de GC.

Esse jogo, denominado JEEES (Jogo de Estratégia para o Ensino de Engenharia de

Software) tem como inspiração elementos e conceitos do jogo SimulES [Figueiredo et

al. 2006], que simula o processo de desenvolvimento de software centrado na perspecti-

1


va de evolução. Além do SimulES, existem outras iniciativas de construção de jogos

educacionais em Engenharia de Software, como, por exemplo, em Gerência de Projetos

[Kieling e Rosa 2006], Processo de Software [Navarro 2006] e Qualidade de Software

[Lino 2007]. Contudo, como discutido anteriormente, nenhuma delas trata de GC. Essa

foi a principal motivação deste trabalho, tendo como hipótese que iniciativas desse tipo

tornariam o ensino de conceitos de GC mais efetivo e prazeroso para os alunos, atraindo

mais adeptos e entusiastas para o tema. Após a elaboração do JEEES, foram executados

alguns estudos experimentais em turmas de cursos de engenharia de software visando

obter indícios que apoiem essa hipótese.

Além desta seção, que apresenta a motivação, trabalhos relacionados, e objetivo

do trabalho, o restante deste artigo está organizado da seguinte forma: na seção 2 o jogo

JEEES é descrito, apresentando seu material e dinâmica; a seção 3 mostra a avaliação

preliminar da primeira versão de JEEES; e na seção 4 são feitas as considerações finais.

2. JEEES: Jogo de Estratégia para o Ensino de Engenharia de Software

JEEES é um jogo de estratégia elaborado com o intuito de ensinar diversos aspectos da

Engenharia de Software. Ele é constituído, em sua maior parte, por diferentes tipos de

cartas e é através destas que os conteúdos são transmitidos para os jogadores. Assim,

novas cartas podem ser adicionadas e cartas que se mostrarem pouco funcionais podem

ser excluídas, permitindo a criação de inúmeras versões do jogo que podem ter propósi-

tos específicos ou não. Por exemplo, a versão atual do jogo, apresentada neste artigo, é

voltada especificamente para o ensino de GC, pois o deque de cartas em uso é relacio-

nado a conceitos dessa área. Desta forma, para o ensino de outras disciplinas de Enge-

nharia de Software, como, por exemplo, Medição e Análise ou Garantia da Qualidade,

bastaria que deques de cartas voltados para essas áreas fossem produzidos. As regras do

jogo e todo o material de apoio continuariam os mesmos.

2.1. O material do jogo

O jogo é constituído basicamente de um tabuleiro de projeto para cada jogador (Figura

1) e diversos tipos de cartas (Figura 2) descritos a seguir, além do material de apoio:

tabuleiro para organização da área da mesa, dados de 6 faces, “dinheiro” para as transa-

ções comerciais do jogo, e marcadores. A versão atual do JEEES conta com 23 cartas

com conteúdos de GC, além de 34 cartas de propósito geral (Tabela 1).

O Tabuleiro de Projeto é a área onde o jogador vai desenvolver o seu projeto

(representado pela Carta de Projeto) que consiste no seu objetivo do jogo. No tabuleiro

de projeto o jogador irá dispor as equipes (Carta de Equipe) que irão trabalhar no pro-

jeto nas respectivas áreas de desenvolvimento e de testes. Ao longo do jogo, estas equi-

pes produzirão as funcionalidades dos componentes das releases do projeto. As funcio-

nalidades produzidas poderão apresentar erros, os quais devem ser identificados pelas

equipes de teste, ou defeitos, que devem ser corrigidos pelas equipes de desenvolvimen-

to. Também são agregados ao tabuleiro de projeto os conceitos que o jogador tenha apli-

cado ao seu projeto (Carta de Conceito) e os eventos que estão em andamento que afe-

tam o projeto (Carta de Evento).

A Carta de Projeto representa o objetivo do jogo para cada jogador, ou seja, o

projeto que este jogador deve concluir para ganhar uma partida de JEEES. Ela contém:

2


(i) a descrição básica do projeto em questão, (ii) o número de releases a serem comple-

tadas e entregues para conclusão do projeto, (iii) o número de funcionalidades que de-

vem ser produzidas para cada componente das releases, (iv) a qualidade do projeto, i.e.,

o número aceitável de defeitos que o projeto final poderá conter, e (v) a quantidade de

dinheiro que será arrecadada no início do projeto e ao final de cada release.

Figura 1. Tabuleiro de projeto do JEEES

Figura 2. Exemplos de cartas do jogo: carta de projeto (a), carta de equipe (b),

carta de conceito (c), carta de evento local (d) e carta de evento global (e)

3


Tabela 1. Cartas da primeira versão de JEEES

Tipo da Carta Quantidade Tipo de Conteúdo

Projeto 5 Projetos open-source. Propósito geral.

Equipe 10 Propósito geral.

Evento 32 14 cartas com conteúdos de GC. 18 cartas de propósito geral.

Conceito 10 9 cartas com conteúdos de GC. 1 carta de propósito geral.

A Carta de Equipe representa a mão de obra do projeto. Quando uma equipe é

alocada em desenvolvimento, ela irá produzir os componentes das releases, efetuando

mudanças e corrigindo defeitos. Quando é alocada em testes a equipe irá detectar os

erros nas releases candidatas e reportar às equipes de desenvolvimento. Esse tipo de

carta contém os seguintes atributos: (i) salário, (ii) adicional por contratação, que é uma

taxa que deve ser acrescentada ao valor do salário da equipe cada vez que for contratada

por um outro jogador, (iii) a habilidade possuída pela equipe em desenvolvimento, (iv) a

tendência de produção de defeitos da equipe, e (v) a habilidade que a equipe tem para

efetuar testes.

A Carta de Conceito descreve um elemento que pode ser agregado ao projeto.

Uma carta de conceito pode ser uma ferramenta, uma técnica ou um processo. Cada

carta de conceito contém sua descrição e custo de implementação. Finalmente, a Carta

de Evento apresenta uma situação (boa ou ruim) que pode ocorrer em um projeto de

software. Cada carta de evento possui a descrição do evento e causa algum efeito ao

jogador que sorteou o evento (evento local) ou a todos os jogadores (evento global).

O material de JEEES possui uma série de marcadores utilizados para representar

as funcionalidades, funcionalidades com erro e funcionalidades com defeito do projeto

(Figura 1), e, ainda, marcadores de humor e de adicional de contratação das equipes.

Além disso, o material também inclui um pequeno guia com as instruções do jogo, uma

lista de todas as referências que foram utilizadas nas cartas e leituras recomendadas e

um glossário com os termos marcados em negrito nas cartas para complementar o a-

prendizado. O material completo do jogo está disponível em (http://sel.ic.uff.br/jeees).

2.2. A dinâmica do jogo

O objetivo do JEEES é concluir um projeto de software. Para isto o jogador deve con-

cluir e entregar todas as releases descritas em sua carta de projeto. Ganha o jogo aquele

que terminar primeiro o projeto ou, em caso de empate, aquele que possuir mais dinhei-

ro no final. O número de jogadores recomendado para esta primeira versão é de 2 a 3

jogadores devido a quantidade de cartas, mas JEEES também poderia ser jogado indivi-

dualmente. A dinâmica do jogo é organizada em turnos para cada jogador, tal como des-

critos a seguir:

No Turno de Contratação o jogador pode contratar uma das equipes disponí-

veis no mercado, à sua escolha, pagando o salário indicado, ou tentar contratar uma e-

quipe de outro jogador, aumentando o salário atual da equipe de acordo com o adicional

por contratação da mesma. A equipe contratada deve ser alocada em uma das funções:

desenvolvimento ou testes. Quaisquer realocações de função de outras equipes também

devem ser realizadas nesse turno. No Turno de Compra o jogador deve retirar uma

carta de evento e realizar as ações indicadas pela carta. Caso a carta de evento se refira a

4


todos os jogadores (evento global), todos os jogadores devem realizar as ações indica-

das.

No Turno de Produção o jogador pode implementar as modificações nos com-

ponentes conforme a produção das suas equipes a fim de completá-los para a conclusão

da release em desenvolvimento. As modificações realizadas devem respeitar o número

de tendência a defeitos de cada equipe. Os defeitos reportados pela equipe de teste de-

vem ser consertados nesse turno pelas equipes de desenvolvimento. Após o turno de

produção ocorre o Turno de Conclusão da Release Candidata caso o jogador tenha

completado o número de modificações necessárias nos componentes da release. Assim,

ele pode anunciar a release candidata e entregar seus componentes para as equipes de

teste. No Turno de Testes o jogador pode detectar os erros nos componentes da release

candidata com a habilidade das suas equipes de teste. Depois de detectados, os erros

devem ser reportados à equipe de desenvolvimento.

No Turno de Conclusão da Release, caso a release candidata tenha a sua qua-

lidade dentro do limite aceitável pelo projeto, e se o jogador assim desejar, a conclusão

da release pode ser anunciada e a sua entrega realizada. O jogador recebe o pagamento

referente à release. O jogador também pode tentar entregar a release para o cliente

mesmo se ela estiver fora dos padrões, porém, neste caso, haverá uma probabilidade de

rejeição do cliente. O último turno é o Turno de Pagamento, onde o jogador deverá

pagar o salário das suas equipes. Caso o pagamento não seja efetuado o jogador sofre

algumas penalidades como a perda de produtividade das suas equipes no turno seguinte.

3. Avaliação do Jogo

A fim de avaliar o jogo desenvolvido, a primeira versão de JEEES foi aplicada em três

turmas de graduação de engenharia de software de duas instituições federais de ensino

superior, a saber: 4º período do curso de Sistemas de Informação do Instituto Federal

Fluminense (Turma A), 5º período do curso de Tecnologia em Análise e Desenvolvi-

mento de Sistemas de Informação do IFF (Turma B) e turma de Engenharia de Software

I (disciplina de 5º período) do curso de Ciências da Computação da Universidade Fede-

ral Fluminense (Turma C).

O objetivo desta avaliação preliminar foi investigar qual seria a percepção dos

alunos com relação ao jogo e avaliar se eles conseguiriam apreender o conteúdo de GC

que foi proposto no jogo. Para isso, foram elaborados 2 questionários de avaliação, am-

bos com 8 questões de múltipla escolha cada. O primeiro questionário avalia a qualidade

do jogo e, além das 8 perguntas apresentadas na Tabela 2, conta com uma área para co-

mentários, críticas e sugestões pessoais.

O segundo questionário avalia se os conteúdos propostos nas cartas desta primei-

ra versão do jogo foram compreendidos pelos alunos e, além das opções de resposta

para as perguntas de GC, cada questão possui também as seguintes opções: “Já sabia” –

caso o aluno já soubesse a resposta da pergunta antes da dinâmica do jogo, “Não vi nada

sobre isso no jogo” – caso o aluno não tivesse visto o conteúdo ao qual a pergunta se

referia nas cartas durante o jogo, e “Não sei responder” – caso o aluno não soubesse a

resposta para a questão. As perguntas desse questionário, juntamente com as suas op-

ções de resposta, podem ser visualizadas na Tabela 3.

5


Tabela 2. Questionário de avaliação da qualidade do jogo

Pergunta Opção 1 Opção 2 Opção 3

1) Após ter jogado JEEES, você diria que: Gostou Gostou muito Não gostou

2) Quanto à jogabilidade, você diria que o JEEES é: Normal Fácil Complicado

3) Você diria que aprendeu com o jogo? Sim Não -

4) Você acha que o tempo de duração do jogo foi ade-

quado para aprender o jogo e conhecer o assunto?

Pouco Adequado Muito

5) Entre o jogo e uma aula, você prefere: Aula e jogo Jogo Aula

6) Uma versão digital do jogo atrairia mais sua atenção? Sim Não -

7) Você gostaria de jogar JEEES novamente? Sim Não -

8) O jogo despertou seu interesse por GC? Sim Não -

Tabela 3. Questionário de avaliação do conteúdo de GC

Pergunta Opções de resposta

1) Um dos objetivos principais da GC é controlar: a) A evolução do software

b) A qualidade do software

c) O custo do software

2) Relacione o nome das ferramentas à sua utilização:

[1] Subversion; [2] Ant; [3] Snort; [4] Trac

[ ] Ferramenta de controle de versões

[ ] Ferramenta de controle de modificações

[ ] Ferramenta de gerenciamento de constru-

ção e liberação

3) Quais práticas devem ser adotadas para que as equi-

pes de um projeto saibam como trabalhar melhor em

grupo paralelamente, evitando problemas como os de

merge, por exemplo?

a) Políticas de Backup

b) Políticas de Engenharia Concorrente

c) Políticas de Configuração

4) Relacione o tipo de “bug” à sua definição:

[1] Defeito ; [2] Falha; [3] Erro

[ ] Problema interno em um artefato. É des-

coberto através da depuração/inspeção.

[ ] Problema de percepção externa que denota

que o artefato não se comportou conforme o

esperado. É descoberto através de testes.

5) O documento que descreve todo o processo de GC de

um projeto é chamado de:

a) Estratégia de GC

b) Política de GC

c) Plano de GC

6) O conjunto de técnicas que descrevem como construir

um ambiente de desenvolvimento apoiado por GC para

criar software mais rápido e confiável é chamado de:

a) Padrões de GC

b) Treinamento de GC

c) Técnicas de Desenvolvimento Ágil

7) O estado em que um sistema se encontra em um de-

terminado momento constitui a sua:

a) Alteração

b) Configuração

c) Classificação

8) Quando uma nova versão de um produto de software é

lançada é chamada de:

a) Merge

b) Commit

c) Release

A dinâmica proposta teve duração de 1 hora e 30 minutos nas turmas A e B e 1

hora na Turma C, divididas respectivamente em: 20 minutos de apresentação do jogo,

50 minutos jogando e 20 minutos para aplicação dos questionários; e, 15 minutos de

apresentação do jogo, 30 minutos jogando e 15 minutos para aplicação dos questioná-

rios. A duração da dinâmica foi determinada pelo tempo disponibilizado pelos professo-

res das turmas. Na Turma A, 8 alunos participaram da dinâmica; na Turma B, 18 alunos

participaram; e na Turma C, 21 alunos, totalizando 47 alunos. Estes alunos foram divi-

didos em grupos de 4, 5 ou 6 alunos, nos quais 3 alunos jogavam e os demais alunos

observavam a partida auxiliando com a distribuição das cartas e inspecionando se as

6


regras estavam sendo cumpridas. Os resultados gerais do primeiro e segundo questioná-

rios aplicados podem ser observados na Tabela 4.

Com relação ao primeiro questionário (Tabela 4.a), referente à qualidade do jo-

go, é possível observar que todos os resultados foram satisfatórios, considerando que

todos os alunos gostaram do jogo e que 89% afirmaram ter aprendido com o jogo. Além

disso, 95% responderam que o jogo fez despertar o interesse por GC. Ambos os indícios

estão alinhados com a hipótese, levantada na seção 1. Entretanto, os alunos também

apontaram o tempo curto da dinâmica, já que 78% acharam pouco o tempo de jogo. A

estimativa de duração de uma partida de JEEES com 3 jogadores é de 2 horas, contudo

o experimento não teve tanto tempo disponível. Este aspecto talvez justifique as dificul-

dades que alguns alunos demonstraram ao jogar (17% acharam o jogo complicado).

Tabela 4. Avaliações da qualidade do jogo (a) e do conteúdo de GC (b)

1º questionário (a) 2º questionário (b)

Qu

estã

o

Op

ção

1

Op

ção

2

Op

ção

3

Qu

estã

o

Res

po

sta

s

cert

as

Res

po

sta

s

erra

da

s

Nã

o v

iu n

o

jog

o

Nã

o s

ou

be

resp

on

der

Já

sa

bia

1 85,1% 14,9% 0 1 68,1% 14,9% 8,5% 6,4% 2,1%

2 63,8% 19,1% 17,1% 2 19,2% 0 48,9% 31,9% 0

3 89,4% 10,6% - 3 14,9% 4,3% 48,9% 31,9% 0

4 78,7% 21,3% 0 4 8,5% 14,9% 29,8% 46,8% 0

5 57,4% 36,2% 6,4% 5 8,5% 10,6% 29,8% 51,1% 0

6 74,5% 25,5% - 6 12,8% 19,2% 34,0% 34,0% 0

7 93,6% 6,4% - 7 46,8% 4,3% 21,3% 27,6% 0

8 95,7% 4,3% - 8 44,7% 0 4,3% 17,0% 34,0%

No segundo questionário, referente à compreensão dos conteúdos transmitidos,

as questões 1, 4, 7 e 8 são relacionadas à GC de um modo geral e a elementos básicos

do jogo. Com exceção da quarta questão, essas questões mostraram resultados satisfató-

rios, como pode ser observado na Tabela 4.b. Porém, observando os demais resultados,

a taxa de acerto nas questões 2, 3, 5 e 6 foi abaixo do esperado. Estas questões se referi-

am a conteúdos presentes em cartas específicas do jogo, e como o tempo da dinâmica

foi menor do que a duração de uma partida normal, os participantes deixaram de ver

essas cartas.

4. Conclusão

Este artigo propôs o jogo JEEES, criado para ensinar conceitos de Engenharia de Soft-

ware com foco em GC. Durante a concepção do JEEES houve a preocupação de aprimo-

rar algumas características herdadas do jogo SimulES, o qual nos serviu de inspiração,

por exemplo: (i) alterar o sistema de compras de cartas e aumentar a quantidade de car-

tas para que as cartas do jogo sejam suficientes para completar uma partida, (ii) renovar

o design das cartas para que a disposição do conteúdo da carta e seu efeito constituam

um único texto, evitando que o jogador leia somente o efeito da carta e ignore o conteú-

do que está sendo informado, (iii) retirar a possibilidade de jogadores lançarem proble-

mas para outros jogadores, (iv) implementar o pagamento de salário das equipes por

turno. Além disso, como dito anteriormente, o foco do jogo foi no ensino da disciplina

de GC. Dentro do conhecimento dos autores, esse é o primeiro jogo com esse intuito.

7


Outro ponto relevante foi a avaliação, ainda que preliminar, da versão atual do jogo. O

estudo mostrou que os alunos receberam bem o jogo, inspirando o aprimoramento deste

trabalho.

Trabalhos futuros consistem na aplicação de novos testes para avaliação do jogo

e na criação de novos conjuntos de cartas para o ensino de outras áreas da Engenharia de

Software, além do refinamento do conjunto de cartas de GC desenvolvido, de forma que

englobe conteúdos de todas as funções da GC. Com um deque maior de cartas, será pos-

sível aplicar o jogo com mais participantes, podendo inclusive estender para jogadores

em rede. Finalmente, a criação de uma versão digital do jogo JEEES está em andamen-

to, já que 74% dos alunos participantes citaram esse interesse.

Agradecimentos

Gostaríamos de agradecer às professoras Aline Vasconcelos e Viviane Torres, que viabi-

lizaram os estudos experimentais, e ao CNPq pelo apoio financeiro.

Referências

Bendix, L. (2001) “Experience from Teaching Configuration Management” In: Interna-

tional Workshop on Software Configuration Management (SCM), Toronto, Canada.

Dart, S. (1991) “Concepts in Configuration Management Systems” In: International

Workshop on SCM, Trondheim, Norway: ACM Press, 1-18 p.

Figueiredo, E., Lobato, C., Dias, K., Leite, J. e Lucena, C. (2006) "SimulES: Um Jogo

para o Ensino de Engenharia de Software". Relat. Técnico 34/06, Depto de Informá-

tica, PUC-Rio.

Gros, B. (2003) “The Impact of Digital Games in Education”, http://www.firstmonday

.org/issues/issue8_7/xyzgros/index.html, Acesso em: 18 de Nov de 2009.

Kieling, E. e Rosa, R. (2006) “Planager - Um Jogo para Apoio ao Ensino de Con-

ceitos de Gerência de Projetos de Software”, Monografia de Trabalho de Conclusão

de Curso de Graduação, Ciência da Computação, FACIN, PUCRS, Porto Alegre.

Lino, J. (2007) “Proposta de um Jogo Educacional para Medição e Análise de Softwa-

re”, Trabalho de Conclusão de Curso, Sistemas de Informação, Universidade Federal

de Santa Catarina, Florianópolis.

MCT (2006) “Qualidade e Produtividade no Setor de Software Brasileiro”. Brasília, DF,

Ministério de Ciência e Tecnologia, Secretaria de Política de Informática.

Navarro, E. (2006) “SimSE: A Software Engineering Simulation Environment for Soft-

ware Process Education”, Doctoral Dissertation, Donald Bren School of Information

and Computer Sciences, University of California, Irvine.

Savi, R. (2008) “Jogos Digitais Educacionais: Benefícios e Desafios”, In: Revista de

Novas Tecnologias na Educação, UFRGS, Porto Alegre, V. 6 Nº 2.

Silva, L. (2009) “O Jogo na Educação”, In: Quaderns Digitals nº59, Departamento de

Educação e Psicologia, Universidade de Trás-dos-Montes e Alto Douro, Portugal.

Tarouco, L., Roland, L., Fabre, M. e Konrath M. (2004) “Jogos Educacionais”, In: Re-

vista de Novas Tecnologias na Educação, UFRGS, Porto Alegre, V. 2 Nº 1.

8


O Poder da Tecnologia de Workflow e dos Mapas Conceituais no Processo de Ensino e Aprendizagem da UML

Simone Sawasaki Tanaka1,2, Rodolfo Miranda de Barros1, Sergio Akio Tanaka2

1Universidade Estadual de Londrina (UEL), Londrina, PR, Brasil

2Centro Universitário Filadélfia de Londrina (UNIFIL), Londrina, PR, Brasil

[email protected]; [email protected]; [email protected]

Abstract. This paper presents the study of the implementation of a workflow for teaching and learning of modeling UML diagrams. For this study, use will be the features and benefits of concept maps to assist in understanding the development of the diagram, which can be used both in classroom teaching and in distance education. The main contributions of this work was the implementation of workflow to aid in the teaching-learning models of UML, the definition of the concept map representing traceability modeling diagrams.

Keywords: UML, Workflow, Map-Concept, Teaching and Learning

Resumo. Este trabalho apresenta o estudo da aplicação de um workflow para o ensino e aprendizagem da modelagem de diagramas da UML. Para este estudo, utilizou as características e benefícios dos mapas conceituais para auxiliar no entendimento da elaboração do diagrama, na qual pode ser utilizado tanto no ensino presencial como no ensino a distância. As principais contribuições deste trabalho foram a implementação do workflow para ajudar no ensino-aprendizagem dos modelos da UML, a definição do mapa conceitual representando a rastreabilidade para modelagem dos diagramas.

Palavras-chaves: UML, Workflow, Mapa-Conceitual, Ensino e Aprendizagem

1 Introdução

Para desenvolver um software, é necessário obedecer a uma série de normas e diretrizes e respeitar todo um processo de desenvolvimento para que tenha-se um software de qualidade. Dessa forma, criar mecanismos para facilitar o desenvolvimento de software é uma iniciativa que vem sendo adotado por muitas empresas com o intuito de aumentar a produtividade e a qualidade dos produtos intermediários e dos produtos finais.

No início do desenvolvimento orientado a objetos existiam vários métodos utilizados na análise, cada um com suas características, porém nenhum completo. Para atender a necessidade de uma padronização foi criada a Unified Modeling Language (UML) [Pender 2004].

Como a UML é uma linguagem de modelagem mundialmente utilizada, preocupa-se com o ensino-aprendizagem da mesma. Uma parte dos alunos depara com a dificuldade em visualizar a dependência entre os diagramas bem como não conseguem obter uma visão geral dos mesmos. As dificuldades apresentadas pelos alunos na

9


disciplina motivaram o desenvolvimento do presente artigo, objetivando a busca de uma maneira para facilitar o processo de ensino e aprendizagem.

O trabalho está focado na teoria da aprendizagem significativa de David Ausubel [Ausubel 1980]. Para facilitar o processo de ensino-aprendizagem da UML, foi proposto a utilização do mapa conceitual para um melhor entendimento da relação dos diagramas da UML. Para uma visualização dinâmica das atividades referente ao ensino e aprendizagem da UML foi utilizada a tecnologia de workflow.

Este trabalho está estruturado da seguinte forma: no capítulo 2 é apresentado os trabalhos relacionados, no capítulo 3 foram apresentadas as abordagens teóricas que serão utilizadas do decorrer do artigo. O capítulo 4 aborda a implementação do Mapa Conceitual dos diagramas da UML e do workflow para a elaboração do Diagrama de Atividades, no capítulo 5 aborda a aplicação do instrumento, no capítulo 6 foi efetuado o fechamento com os resultados. Finalmente no capítulo 7 são apresentados as conclusões e trabalhos futuros.

2 Trabalhos relacionados

A utilização das técnicas de workflow foi encontrada em alguns trabalhos, como também foram localizados trabalhos relacionados com a UML. Em Lopes (2010) foi abordado a tecnologia de workflow relacionado a aprendizagem trazendo uma proposta de integração de técnicas de planejamento em inteligência artificial (IA) e tecnologia de workflow a um ambiente de Ensino à Distância.

Já Pichiliani (2006), mostra como utilizar a modelagem colaborativa no aprendizado da UML.

Foram localizados trabalhos sobre mapas conceituais sendo utilizados no processo de ensino aprendizagem [Santos 2005], bem como trabalhos sobre a UML e também a utilização do workflow [Sizilio 2001], [Robinson 2004], entretanto nenhum dos trabalhos pesquisados aborda as técnicas agrupadas com o intuito de contribuir com o processo de ensino e aprendizagem da UML, sendo este agrupamento uma das contribuições deste trabalho.

3 Fundamentação Teórica

Esta seção apresenta os principais conceitos utilizados neste artigo, tais como: Aprendizagem Significativa, UML, Workflow, Mapa Conceitual.

3.1 Aprendizagem Significativa

Para Ausubel [Ausubel 1980], a aprendizagem pode se processar entre os extremos da aprendizagem mecânica e a aprendizagem significativa. A aprendizagem mecânica está relacionada com a aprendizagem de novas informações, com pouca ou nenhuma associação com conceitos relevantes existentes na estrutura cognitiva do aluno.

Pode-se dizer que a aprendizagem significativa ocorre quando a nova informação ancora-se em conceitos relevantes pré-existentes na estrutura cognitiva do

10


aluno. A essência do trabalho de Ausubel é a aprendizagem significativa na qual os conceitos são ordenados progressivamente, de forma que os conceitos mais gerais de um conteúdo estão ligados a conceitos subordinados e este a conceitos específicos.

Para Moreira (2001), Ausubel sustenta que o ponto de vista de que cada disciplina acadêmica tem uma estrutura articulada e hierarquicamente organizada de conceitos que constitui o sistema de informações dessa disciplina. Esses conceitos estruturais podem ser identificados e ensinados a um aluno, constituindo para ele em sistema de processamento de informações, um verdadeiro mapa intelectual que pode ser usado para analisar o domínio particular da disciplina e nela resolver os problemas.

3.2 UML

A UML é uma linguagem gráfica para visualizar, especificar, construir e documentar os artefatos de um sistema de software. Por meio de seus diagramas, é possível representar sistema de software sob diversas perspectivas de visualização, facilitando a comunicação de todas as pessoas envolvidas no processo de desenvolvimento de um sistema tais como: gerentes, coordenadores, analistas, desenvolvedores por apresentar um vocabulário de fácil entendimento [Booch 2005].

A importância da modelagem para um bom desenvolvimento e entendimento de um sistema de software, torna a UML importante, elevando assim uma melhor comunicação entre todas as pessoas que estão envolvidas no projeto de desenvolvimento do software.

Para uma melhor compreensão do processo e de como iniciar a modelagem utilizando a UML são utilizados as técnicas de workflow juntamente com os mapas conceituais, visando facilitar a compreensão para a elaboração dos diagramas.

3.3 Workflow

Um workflow define as tarefas e atividades a serem desenvolvidas, paralelamente ou sequencialmente, bem como os responsáveis por cada uma dessas atividades e os recursos necessários para a sua execução.

A tecnologia de workflow têm-se apresentado como possibilidade de modelar as atividades inerentes ao ensino, uma vez que tem-se a definição clara das tarefas a serem executadas com seus agentes responsáveis [Sizilio 2001].

O workflow foi utilizado para tornar dinâmico o mapa conceitual, ou seja, por meio do workflow foi demonstrado o fluxo de atividades para o desenvolvimento de um dado diagrama onde as informações tramitarão entre os atores envolvidos gerando artefatos. Cada atividade do workflow deve prover produtos advindos das atividades anteriores, que serão utilizados na atividade corrente, bem como a metodologia a ser utilizada nesta atividade na qual é descrita por uma instrução de trabalho como também os recursos necessários (recursos humanos, máquinas, software, entre outros) e os produtos resultantes (artefatos).

Com essas informações em mãos, tem-se um mecanismo de auxílio ao processo de ensino-aprendizagem que permite tanto o professor e o aluno se posicionar e compreenderem de uma maneira mais sistêmica os diagramas da UML.

11


3.4 Mapa Conceitual

Os Mapas Conceituais, desenvolvidos por John Novak a partir da teoria de Ausubel [Novak 1998], são representações gráficas semelhantes a diagramas, que indicam relações entre conceitos ligados por palavras. Representam uma estrutura que vai desde os conceitos mais abrangentes até os menos inclusivos. São utilizados para auxiliar a ordenação e a sequenciação hierarquizada dos conteúdos de ensino, de forma a oferecer estímulos adequados ao aluno. Em linhas gerais os conceitos são apresentados em retângulos e as ligações entre estes conceitos são representadas por linhas que rotulam o tipo de relacionamento entre estes.

Como uma ferramenta de aprendizagem, o mapa conceitual é útil para o estudante fazer anotações, resolver problemas, planejar o estudo e/ou a redação de grandes relatórios, preparar-se para avaliações, integrar os tópicos.

Para os professores, os mapas conceituais podem auxiliar em suas tarefas rotineiras, tais como, ensino de um novo tópico, reforço da compreensão, verificação da aprendizagem, identificação de conceitos mal compreendidos e avaliação [Barros 2008].

4 Implementação do Mapa Conceitual e do Workflow

Partindo do pressuposto da análise da dificuldade dos alunos em assimilar a UML bem como a do professor em ministrar o conteúdo, foram elaborados mapas conceituais com o objetivo de facilitar o processo de ensino e aprendizagem.

Como se pode observar na Figura 1, a partir da definição da arquitetura, pode-se iniciar a elaboração de diversos diagramas. Após se iniciar a elaboração do Diagrama de Caso de Uso, onde são modelados os requisitos do comportamento do sistema [Booch 2005], é possível também dar início ao Diagrama de Classe e Diagrama de Atividades. Durante a elaboração dos diagramas, podem ocorrer refinamentos sucessivos, na qual está sendo representado por um retângulo pontilhado sobre os diagramas que sofrem tais refinamentos, como o Diagrama de Caso de Uso, Diagrama de Classe e Diagrama de Atividades. O Diagrama de Classe se encontra no centro do processo de modelagem de objetos [Pender 2004], com este diagrama definido, outros diagramas podem ser elaborados, pois todos eles possuem uma dependência em relação às classes. A maioria dos diagramas citados na sequência não possui uma hierarquia de construção, como pode ser observado no mapa conceitual da Figura 1.

Este artigo aborda o Diagrama de Atividades, onde através do workflow, são demonstradas as atividades necessárias para que o mesmo seja construído. Para que a aprendizagem seja realmente significativa, somente o mapa conceitual apresentado na Figura 1 não é suficiente, visto que o mesmo está mostrando as relações e não o que é necessário fazer passo-a-passo para a construção de cada diagrama, ou seja, a dinamicidade para o processo de ensino e aprendizagem.

12


Definir a

Arquitetura

Diagrama de

Implantação

Elaborar

Diagrama

Caso de Uso

Elaborar

Diagrama

de Pacotes

Elaborar

Diagrama

de Classe

Elaborar

Diagrama de

Atividades

Elaborar

Diagrama de Sequencia e

Comunicação

Elaborar

Diagrama de

Máquina de Estado

Elaborar

Digrama de

Tempo

Elaborar

Diagrama de

Componentes

Elaborar

Diagrama de

Estrutura Composta

ElaborarVisão Geral

Elaborar

Elaborar

Elaborar

Elaborar

Figura 1 – Mapa Conceitual da Elaboração dos Diagramas da UML

Na Figura 2 e Figura 3 são demonstrados os workflows para a elaboração do Diagrama de Atividades. Para a elaboração do workflow foi utilizado o modelo de Casati cuja notação pode ser mais bem compreendido no trabalho de Sizilio (2001).

Como pode se verificar na Figura 2, a elaboração do Diagrama de Atividades inicia-se com a atividade “Estabelecer o foco do Diagrama”, posteriormente tem-se duas atividades que acontecem paralelamente, a “Identificar Grupos e/ou responsáveis” e “Identificar as Atividades”. Ao término das duas atividades, inicia-se a atividade “Elaborar o Diagrama de Atividades”, na qual é considerada uma supertarefa, demonstrada detalhadamente na Figura 3. Para um bom entendimento do problema e para agregar qualidade ao desenvolvimento do software, é necessária a realização de refinamentos sucessivos. Isto é representado no workflow pelo fork condicional, que acontece após a execução da supertarefa, retornando ou não para o início do workflow.

Figura 2 – Workflow do Diagrama de Atividades

Figura 3 – Workflow da Atividade Elaborar o Diagrama de Atividades

13


A supertarefa “Elaborar Diagrama de Atividades”, detalha os passos para elaborar o diagrama , onde a primeira atividade é “definir o estado inicial”, seguido da atividade “separar as atividades por grupos”, posteriormente deve-se “definir o fluxo de controle”, paralelamente acontecem duas atividades, “verificar fluxos concorrente” e “verificar as ramificações”. Após executada essas atividades, “defini-se o estado final” do diagrama, e através do fork condicional, pode-se retornar ou não para o início do workflow.

Conforme ilustrado na Figura 2 e Figura 3, o workflow é composto por atividades, e vários itens influenciam nestas atividades com o intuito de resultar em um produto, além disso, cada atividade é composta por instruções de trabalho. Como suporte ao workflow, também foi elaborado um mapa conceitual do diagrama em questão (Figura 4), visando agregar valor ao cognitivo dos alunos, ou seja, conceitos sem os quais o aluno pode ter uma maior dificuldade em elaborar tais diagramas.

Figura 4 – Mapa Conceitual do Diagrama de Atividades

5 Estudo de Caso

Para verificar e validar a aplicação do workflow e dos mapas conceituais no processo de ensino e aprendizagem da UML, foi realizado uma pesquisa, que constitui na elaboração e realização de uma aula, onde se apresentou e aplicou o workflow e os mapas conceituais desenvolvidos no âmbito desta pesquisa, para os alunos que já detinham ou não algum conhecimento da UML, com o propósito de se avaliar o grau de contribuição do workflow e do mapa conceitual, o que dá um indicativo da eficácia da solução apresentada, permitindo dar continuidade ao desenvolvimento desta pesquisa.

As aulas foram ministradas na Universidade Estadual de Londrina (UEL), para 22 alunos do 3º ano do Curso de Ciência da Computação, de forma expositiva, utilizando o aplicativo PowerPoint da Microsoft e datashow. O conteúdo foi trazido pelo professor inteiramente delimitado, justamente por se buscar conclusões sobre o uso dos mapas conceituais e workflow no processo de ensino e aprendizagem

O instrumento de coleta de dados que foi utilizado para o desenvolvimento da pesquisa foi o uso de um questionário, que por suas características próprias tem a vantagem da rapidez e poder incluir a opinião de todos os alunos que participaram da aula. Ao término de cada aula foi solicitado aos alunos que preenchessem o questionário visando demonstrar o grau de contribuição que o workflow e os mapas conceituais

14


trouxeram ao aluno.

6 Resultados

De acordo com a análise de resultados de opinião dos alunos submetidos aos questionários, foi possível concluir que o uso do workflow e dos mapas conceituais, em uma análise preliminar, contribui de forma significativamente positiva no entendimento de conceitos dos diagramas da UML e do Diagrama de Atividades em especial. É importante ressaltar que a maioria dos alunos participantes do estudo considerou a contribuição positiva.

A mesma técnica foi aplicada anteriormente no ensino do Diagrama de Caso de Uso, na qual o resultado demonstrou-se positivo. O instrumento foi aplicado a alguns alunos que já tinham conhecimento da UML e outros não. Questionou-se os alunos em relação ao conhecimento agregado mesmo já tendo contato com a UML e o resultado foi considerado positivo, conforme a Figura 5. Quanto a utilização do workflow e dos mapas conceituais, as respostas foram em todos os casos, satisfatória podendo concluir que há contribuição positiva significativa dos mesmos, similarmente ocorreu quando questionado sobre o workflow e as instruções de trabalho e o mapa conceitual juntamente com o workflow.

Figura 5 – Histograma do questionário

7 Conclusões e trabalhos futuros

A educação é o processo de desenvolvimento de aptidões, de atitudes e de outras formas de conduta exigidas pela sociedade, um processo globalizado que visa à formação integral de uma pessoa, para o atendimento às necessidades e às aspirações de

15


natureza pessoal e social.

A utilização dos mapas conceituais pode levar a uma forma profunda e significativa na maneira de ensinar e aprender. A utilização dos mapas conceituais para o ensino e aprendizagem do Diagrama de Atividades da UML juntamente com o workflow da elaboração do Diagrama de Atividades, tornou mais claro e organizado a forma de ensinar e estudar.

Por meio desse trabalho foi possível desenvolver um processo que orienta o estudo e o acesso às pessoas que queiram compreender melhor os passos para o estudo e desenvolvimento do Diagrama de Atividades. Os resultados apresentados no capítulo 6 demonstraram que os mapas conceituais e o workflow contribuíram para a aprendizagem do diagrama. Indubitavelmente ainda existe a necessidade de aplicar o instrumento para mais alunos objetivando um resultado mais abrangente. Todavia, já foi possível avaliar de forma preliminar a produtividade no aprendizado do aluno com a utilização do instrumento em questão.

Como trabalho futuro, o estudo pode ser estendido a outros diagramas da UML 2.0 e também aplicar o estudo ao ensino à distância.

8 Referências Bibliográficas

Ausubel, David et AL. (1980) “Psicologia Educacional”, Rio de Janeiro: Interamericano.

Barros, Rodolfo Miranda de. (2008) “Um Estudo sobre o Poder das Metáforas e dos Recursos Multimídia no Processo de Ensino e Aprendizagem de Cálculo Diferencial e Integral”, Campinas, SP

Booch, Grady; Rumbaugh, James; Jacobson, Ivair. (2005) “UML: Guia do Usuário”, Rio de Janeiro: Elsevier.

Lopes, R. S. (2007) “Workflow Genético para Planejamento e Gerenciamento de Currículo em EAD”, http://www.facom.ufu.br/posgrad/WD1/robson.pdf, Junho.

Moreira, Marco Antonio. (2001) “Aprendizagem Significativa: a teoria de David Ausubel”, São Paulo: Centauro.

Novak, Joseph D. (1998), “Learning, Creating and using Knowledge: Concept Maps as Facilitative Tools in Schools and Corporations”, Laurence Erbaum Ass.

Pender, Tom. (2004) “UML, A Bíblia”, Rio de Janeiro: Elsevier.

Pichiliani, M. C. (2006) “Usando a modelagem colaborativa no aprendizado da UML”, http://www.br-ie.org/pub/index.php/wie/article/viewFile/906/892, Junho.

Robinson, G., Scopel, M. (2004) “Modelando Requisitos Especificados com Mapas conceituas através da UML-MC”, Manaus, Brasil

Santos, P. S.; Menezes, C. S.; Cury, D.; Nevado, R. A. (2005) “Um Ambiente para Acompanhamento da Aprendizagem baseado em Mapas Conceituais” In: Simpósio Brasileiro de Informática na Educação. Anais. Juiz de Fora, MG

Sizilio, Glaucia Regina M. A. (2001) “Modelo de Autoria de Cursos de Ensino a Distância”, Revista Brasileira de Informática na Educação, n. 8, Abril.

16


SimulES-W: Um Jogo para o Ensino de Engenharia de Software

Elizabeth Suescún Monsalve1, Vera Maria B. Werneck2, Julio Cesar Sampaio do Prado Leite1

1 Pontifícia Universidade Católica de Rio de Janeiro (PUC-Rio), Rio de Janeiro, Brasil

2Universidade do Estado do Rio de Janeiro (UERJ), Rio de Janeiro, Brasil

emonsalveinf.puc-rio.br, [email protected], www.inf.puc-rio.br/~julio

Abstract. This paper describes SimulES-W, a software engineering educational card board game. This game allows the student to assume different roles in tasks and decisions of a software construction project. In addition the game encourages competitiveness, testing the student's ability in dealing with problems and applying software engineering concepts to solve these problems or improve their performance in the game, simulating situations difficult to exercise in traditional classrooms. SimulES-W is implemented by software which provides a collaborative infrastructure for Web game playing.

Resumo. Este artigo apresenta SimulES-W, um jogo educacional de cartas que ensina engenharia de software. Este jogo permite que um aluno assuma diferentes papéis num projeto de construção de software, permitindo que ele vivencie tarefas e decisões usuais num contexto de produção de software. O jogo estimula a competividade testando a capacidade do aluno em lidar com problemas e aplicar conceitos de engenharia de software para solucionar problemas ou melhorar seu desempenho no jogo, simulando situações que dificilmente ocorrem em aulas tradicionais. SimulES-W é implementado por um software que provê um ambiente colaborativo na Internet.

1. Introdução

Jogos estão cada vez mais presentes como uma prática habitual no ensino e treinamento, sendo concebidos como uma atividade lúdica que é bastante motivadora no processo de ensino-aprendizado. Desta forma, o uso de jogos para treinar, aprender e executar atividades reais em ambientes realísticos pode melhorar o desempenho dos alunos, pois possibilita a vivência de experiências de aprendizagem que não são fornecidas de forma teórica.

A Engenharia de Software é uma área onde aspectos teóricos e aspectos práticos interagem, tornando fundamentais as decisões e experiências da prática no desenvolvimento de softwares de qualidade, econômicos, úteis e no prazo esperado.

Para contemplar esses aspectos práticos que dificilmente são contemplados pelo ensino tradicional de aulas expositivas, com pouca iteração dos alunos, surgiram propostas do ensino de Engenharia de Software através de pequenos projetos de

17


desenvolvimento (Pressman, 2006), (Claypool e Claypool, 2005) e (Sweedyk e Keller, 2005). Entretanto, situações vivenciadas na prática, como em projetos de médio a longo porte, dificilmente podem ser exercitadas em sala de aula. O uso de jogos ajuda o enfrentamento desse problema simulando situações e decisões reais vividas pelos engenheiros de software no dia a dia de projetos.

Neste contexto surgiram alguns jogos de tabuleiros, de cartas e simuladores para apoiar o ensino de engenharia de software (Baker, 2003), (SESAM, 2009), (Jain e Boehm, 2006), (Birkhoelzer et al, 2005). SimulES (Figueiredo, 2007), um jogo de tabuleiro para ensino de Engenharia de Software foi proposto com esse objetivo de exercitar, através de simulação, algumas situações e decisões do processo de desenvolvimento de software.

SimulES-W, implementado em um software que utiliza a Internet, daí o W, é a versão digital do SimulES que evoluiu até a versão SimulES 2.0. Essas evoluções foram baseadas na utilização do jogo em diversos cursos de Engenharia de Software na graduação e pós-graduação (Serrano 2007), (Napolitano 2007), (Monsalve, 2010), e (Monsalve, Werneck e Leite, 2010). SimulES-W explora conceitos de complexidade, tamanho e qualidade do produto, de produtividade e maturidade da equipe de desenvolvimento, de gestão de orçamento, de riscos do desenvolvimento versus qualidade e aceitação do produto final. Além desses conceitos básicos os jogadores são expostos a conceitos e problemas gerais de engenharia de software que têm que ser discutidos e argumentados pelos participantes do jogo centrado num processo de colaboração.

A coloboração é outro aspecto importante no processo de produção de software. Segundo Fuks et al (2003) indivíduos que trabalham em grupo podem produzir melhores resultados decorrentes da complementação de capacidades, conhecimentos e de esforços individuais, além da interação entre as pessoas com seus entendimentos, pontos de vista e habilidades.

Neste contexto colaborativo, SimulES-W tem como objetivo ajudar no ensino da engenharia de software de uma forma lúdica, agradável e divertida gerando situações que espelham situações reais num projeto de construção de um software, O jogo é jogado através de tarefas individuais e coletivas segundo regras pré-estabelecidas. Os participantes trabalham com um objetivo individual de ganhar o jogo, além de interagir entre si compartilhando e argumentando informações e conceitos relacionados com a engenharia de software. Ganhar o jogo significa ser o primeiro a entregar o produto a ser produzido durante o jogo.

Este artigo está dividido em cinco Seções. A Seção 2 apresenta alguns jogos usados como ferramentas para o Ensino na Engenharia de Software. Na Seção 3 é fornecida uma visão detalhada do jogo de tabuleiro SimulES na sua versão 2.0, descrevendo suas regras gerais, seus elementos e o objetivo de cada partida. Na Seção 4 descreve-se o SimulES-W, implementação do jogo na Web, que foi baseada na versão de tabuleiro descrita na Seção 3. Finalmente, na Seção 5 concluímos e relatamos como os trabalhos futuros serão abordados.

18


2. Jogos como Ferramentas de Ensino na Engenharia de Software

Jogos estão cada vez mais presentes como uma prática habitual no ensino e treinamento, sendo concebidos como uma atividade motivadora no processo de ensino-aprendizado. No domínio da Engenharia de Software podemos citar alguns jogos, tais como: PnP (Baker, 2003), SESAM (2009), SimVBSE (Jain e Boehm, 2006), SimSE (Birkhoelzer et al, 2005).

O jogo Problems and Programmers (PnP) é um jogo de cartas educacional direcionado para o ensino geral de engenharia de software (Baker, 2003) cujo objetivo é simular o processo de desenvolvimento de sistemas de uma maneira competitiva entre jogadores. SESAM (Software Engineering Simulation by Animated Models) (2009) é focado no ensino de gestão de projetos através de uma simulação com a criação e execução de um modelo do processo de desenvolvimento de software e executá-lo usando um sistema de simulação. SimVBSE baseia-se no ensino do valor da engenharia de software (Jain e Boehm, 2006) através conceito de “fator crítico de sucesso”. O objetivo deste jogo é integrar esse valor considerando-o em toda a gama existente e emergente dos princípios e práticas de engenharia de software. SimSE permite aos alunos praticar de forma “virtual” o processo de engenharia de software (ou seus sub-processos) de uma forma totalmente gráfica (Birkhoelzer et al, 2005), além disso, permite saber a causa e efeito das complexas relações que permeiam as atividades de engenharia de software.

A tabela 1 apresenta uma síntese dos elementos mais importantes dos jogos apresentados nesse trabalho. Além disso, foram identificadas outras iniciativas que estão em processo de desenvolvimento tais como Scrumming (Isotton, 2008), Planager (Kieling e Rosa, 2006), X-MED (Lino, 2007), GamePlay (Smith e Gotel, 2008) as quais têm como foco realizar simulações para ensinar conceitos de gerência de projetos, práticas ágeis de gerenciamento de projetos, principalmente o SCRUM, medição de software e gerência de requisitos respectivamente.

Tabela 1. Resumo das características de alguns Jogo s Educacionais para Ensino na Engenharia de Software

3. SimulES

3.1 Visão Geral

SimulES (Figueiredo, 2007) é um jogo de tabuleiro educacional direcionado para o ensino de engenharia de software, concebido a partir da evolução do jogo "Problems and Programmers" (PnP) (Baker, 2003), que é também a base de outros jogos (SESAM, 2009), (Jain e Boehm, 2006), (Birkhoelzer et al, 2005) descritos anteriormente.

19


Na utilização do SimulES em diversos cursos de Engenharia de Software na graduação e pós-graduação foram identificados requisitos que permitiram uma evolução do SimulES original documentados em (Serrano 2007) e (Napolitano 2007). O resultado dessas experiências foi a definição do SimulES 2.0 (Serrano et al 2007). As descrições e regras apresentadas neste artigo referem-se ao SimulES 2.0 que será a partir de agora denominado simplesmente SimulES.

O objetivo do SimulES é que cada jogador construa um mesmo produto de software. No jogo o aluno/jogador assume vários papeis, tais como: engenheiro de software, coordenador técnico, controlador de qualidade e gerente de projeto. Dentre as tarefas do jogo, jogador deve lidar com: (i) complexidade e tamanho do produto, (ii) noção de tratamento de qualidade do produto com base na verificação por meio de inspeção (iii) risco de se ter produtos de má qualidade, (iv) orçamento em termos de valor do projeto, (v) contratação e demissão de engenheiros de software, (vi) visão de recursos em função do valor, produtividade e maturidade das pessoas envolvidas e (vii) construção de diversos artefatos necessários para término do projeto.

Para ganhar o jogo, entregar o produto, o jogador deve criar uma estratégia que irá melhorar o seu jogo em relação à dos seus adversários e ao mesmo tempo deverá fazer jogadas que desestabilizem os jogos de seus adversários, através das Cartas Problemas. Os adversários podem responder a esses problemas com conceitos de engenharia de software e bloquear o ataque de um jogador. Esse processo é colaborativo no sentido de que todos os jogadores devem estar cientes tanto do problema como do remédio (conceito) e concordar com sua aplicação.

A partida termina quando um jogador constrói todos os módulos necessários para completar o projeto com a qualidade estipulada, onde os módulos do projeto podem ter sidos todos inspecionados ou não. A tarefa de inspeção tem custo associado. Se o jogador escolher não inspecionar todos os seus módulos, a inspeção final obrigatória, segundo o critério de qualidade do projeto, poderá ou não encontrar defeitos. Se o número de defeitos encontrado for maior que o permitido, o jogo continua, porque aquele jogador não atingiu a meta. Essa dinâmica onde qualidade, custo e risco são exercitados é um dos pontos principais sob a ótica do aprendizado. Ou seja, usa-se o término do jogo, primeiro jogador a completar o projeto com seus módulos, como a didática para ensino dos conceitos de qualidade, custo e risco.

3.2 Recursos do Jogo

Os recursos do jogo podem ser visualizados na Figura 1 (Serrano et al, 2009) sendo os seguintes: Tabuleiro Principal, Tabuleiro Individual, Cartas de Artefato (Brancas e Cinzas), Cartão do Projeto, Engenheiros de Software e Cartas Conceitos e Cartas Problemas. Esses recursos que estão, também, presentes no SimulES-W, são apresentados nesta sessão para explicar as características gerais do jogo.

O Tabuleiro Principal (Figura 1 parte a) é colocado no centro da mesa do Jogo, e nele estão dispostos as Cartas de Projeto, as Cartas de Artefato Brancas e Cinzas, as Cartas Conceito e as Cartas Problemas, assim como também uma pilha de Engenheiros de Software. O projeto escolhido deve ficar visível no tabuleiro principal e os lançamentos do dado, também, são efetuados nesta área.

20


O Tabuleiro Individual (Figura 1 parte b) é o local onde cada jogador coloca seus Engenheiros de Software em colunas e os artefatos que vai construindo em linhas. Os artefatos podem ser dos seguintes tipos: requisito, desenho, código, rastro e ajuda. A quantidade e tipos de artefatos a construir dependerão do projeto escolhido no inicio do jogo. As Cartas de Artefato Brancas e Cinzas são colocadas nas células do tabuleiro, abaixo do engenheiro que as construíram e nas linhas referentes aos seus tipos. Essas cartas simbolizam os produtos construídos pelos engenheiros de software que podem ou não conter defeitos (“bugs”). Cartas de Artefato Brancas custam dois “pontos de tempo” para serem compradas e as Cartas de Artefato Cinzas a metade, mas as de cor branca contêm menos defeitos (proporção de 5 cartas para 1 defeito) que as cinzas (proporção é de 3 para 2). Por isso, custa mais construir o software com cartas brancas mas estas podem trazer maior beneficio na inspeção nos artefatos. Antes de uma inspeção os artefatos estão todos virados para baixo, o que esconde o conhecimento se estão marcadas com um inseto (“bug”) no verso ou não. Portanto esse truque do jogo simula um artefato real, no qual a qualidade deixou de ser aferida. O cartão do projeto (Figura 1 parte c) é escolhido no inicio do projeto e é o mesmo durante todo o jogo, contendo os seguintes elementos: (i) Complexidade que indica quantos pontos de tempo um engenheiro de software precisa gastar para construir um bom artefato; (ii) Tamanho que indica o número e os tipos de módulos devem ser construídos e integrados para que o produto software esteja completo; (iii) Qualidade que representa o quão livre de defeitos (bugs) deve estar o produto final, indicando o número mínimo de módulos sem defeitos necessários para submeter o produto e vencer o jogo; (iv) Orçamento que determina a quantidade de dinheiro disponível para gastar com o projeto e representa também uma restrição para contratação de engenheiros de software e para o uso de Cartas de Conceitos.

As Cartas de Conceitos e Problemas (Figura 1 parte e) descrevem boas práticas e problemas clássicos de Engenharia de Software respectivamente. As Cartas de Problema são utilizadas para que os jogadores criem obstáculos ao progresso dos jogos de outros jogadores enquanto que as Cartas Conceito servem para melhorar o progresso no jogo ou para neutralizar uma Carta Problema.

O jogador é um participante do jogo que tem por objetivo vencer o jogo. Em uma partida ele desempenha os papéis de jogador da vez e adversário. O jogador da vez, através de seus engenheiros de software, pode construir um artefato ou corrigir ou inspecionar artefatos ou integrar um artefato ou submeter produto. Os adversários são os oponentes do jogador da vez, principalmente, na rodada de conceitos, no tratamento de problemas e na submissão de produtos.

3.3 Regras do Jogo

As regras do jogo apresentadas em (Serrano et al 2007) foram utilizadas e aprimoradas na versão do SimulES-W como é discutido em (Monsalve, Werneck e Leite, 2010). Estas servem para contextualizar e melhorar o entendimento da dinâmica do jogo e por isso são apresentadas a seguir.

Os jogadores executam uma serie de ações chamadas “Rodadas” dispostas seqüencialmente onde todos os jogadores devem participar de forma ordenada. O jogo possui as seguintes rodadas: Inicio, Ações, Conceitos, Tratamento de problemas e Submissão do produto.

21


Figura 1. Principais Elementos do SimulES Jogo de T abuleiro [9]

Na jogada de inicio é escolhido aleatoriamente o projeto que deve ser tratado durante todo o jogo, como também o primeiro Engenheiro de Software para cada um dos jogadores. A jogada de ações começa com o lançamento do dado e de acordo com o número tirado, retira 1 a 3 Cartas de Conceito e Problema e se o valor do dado for mais de 4 pode pegar também (dado–3) Cartas de Engenheiro de Software. A jogada de ações continua e o jogador da vez deve tratar (construir, inspecionar ou empacotar) os artefatos dispostos no tabuleiro individual. Na construção pode retirar novas Cartas de Artefato dependendo da complexidade do projeto e da habilidade de sua equipe de Engenheiros de Software. A habilidade determina quantos “pontos de tempo” ele tem e, portanto, quantas ações ele pode desempenhar por vez. Analogamente ele pode inspecionar dependendo também da habilidade da sua equipe. Na jogada de conceitos e tratamento de problemas os jogadores podem ser atacados e atacam seus adversários usando as Cartas Conceitos e Cartas Problemas com conceitos típicos da engenharia de software. Esta instância do jogo é importante porque permite que os jogadores analisem tanto as Cartas Conceitos e Cartas Problemas que possuem quanto as que possuem seus adversários para realizar a melhor jogada possível. Essas cartas possuem conhecimento de engenharia de software e devem ser lidas, entendidas e discutidas entre os jogadores. Além disso, o professor (jogando ou “só olhando”) pode induzir a uma análise mais profunda que permita aos jogadores melhor aprender os conceitos sendo discutidos. Por último, o produto de software é submetido, sendo que o primeiro jogador a chegar nesta instância ganha o jogo, se o produto passar pela inspeção final e se que não houver penalidade pendente.

Para vencer o jogo, é preciso completar os módulos do projeto definidos no cartão de projeto selecionado no início do jogo, na qualidade exigida. Após serem construídos os artefatos estes devem ser empacotados na Rodada de Ações e depois submetidos como produtos finais.

22


No decorrer do jogo, o jogador poderá refletir sobre os problemas e conceitos de engenharia de software que tanto ele quanto os demais jogadores apresentem dentro do jogo os quais referenciam a problemas típicos na engenharia de software. O jogador poderá, também, escolher para a construção de seu produto de software a abordagem de desenvolvimento de seus produtos (Figueiredo, 2007), pois, SimulES não obriga a utilização de uma única estratégia ou processo seqüencial, ou seja, o jogador pode estar na construção de código e pode voltar a trabalhar em requisitos ou desenho. No final do jogo ele identificará que uma escolha flexível para a construção de seu produto de software pode ser a mais adequada, além disso, ele notará a evolução dos diferentes artefatos criados no processo de desenvolvimento os quais através da inspeção podem precisar ou não de melhorias que podem ser aplicadas através da correção.

O jogo SimulES em suas várias versões já foi utilizado uma dezena de vezes, sempre com uma retroalimentação positiva sobre seu potencial de ensino. Relatos de validações e de experiências com o jogo podem ser encontrados em (Serrano et al 2007), (Serrano 2007) e (Napolitano 2007). Além disso, a avaliação de sobre o uso de SimulES 2.0 que foi publicada em (Monsalve, Werneck e Leite, 2010) foi utilizada na versão de SimulES-W apresentada na próxima seção.

4. SimulES-W

A evolução do SimulES para o SimulES-W foi realizada com base num estudo de literatura sobre jogos educacionais na engenharia de software, alguns deles apresentados na Sessão 2 deste artigo e em experiências de uso do jogo. Nessa pesquisa identificou-se que as descrições sobre as modelagens do sistema eram vagas ou inexistentes e que a interação entre usuários não era considerada na implementação desses jogos. Assim foi escolhida a modelagem intencional para representação dos modelos de requisitos, pois esta considera a modelagem da interação entre os atores (Yu, 1995). Adotou-se também o método ERi*c (Oliveira, 2008) para facilitar a criação dos modelos iniciais sendo estes baseados no conceito de intencionalidade do “framework” i* (Yu, 1995). A descrição dessa modelagem pode ser encontrada em Monsalve (2010).

SimulES-W foi desenvolvido mapeando as informações dos modelos intencionais até o código e para isso foi escolhida uma arquitetura do tipo MVC (NETBEANS 6.5, 2008) e como ferramenta de desenvolvimento a linguagem Java. Além disso, foram utilizados os seguintes softwares de apoio: MySQL, Visual Web JavaServer Faces, Hibernate e jMaki Ajax.

O SimulES-W é jogado na internet com navegadores padrão, permitindo que jogadores geograficamente separados trabalhem tanto em tarefas individuais como em tarefas em equipe. Esta é uma das vantagens dos sistemas colaborativos: para cooperar os indivíduos trocam informações, se organizam e operam em conjunto num espaço compartilhado (Fuks et al 2003). No caso do SimulES-W esta cooperação é calcada nas interfaces apresentadas no navegador e onde os jogadores negociam, tomam decisões e observam o que está acontecendo, sendo estas ações necessárias para sua atuação dentro da interação.

Na Figura 2 é apresentada a interface principal do SimulES-W onde são dispostas as mensagens trocadas entre os jogadores e as informações sobre jogadas e estado do jogo. Nesta página têm-se, também, as informações de projeto escolhido para

23


a jogada e os jogadores on-line, e finalmente a lista das jogadas aceitadas ou não entre os jogadores.

Na Figura 3 mostra-se o Tabuleiro Individual em duas situações: a) Construção de Artefato onde o jogador tem os Engenheiros de Software contratados para a construção dos diferentes artefatos, cada um deles com um link que apresenta as informações dos Engenheiros de Software. Na parte a dessa Figura as cartas de artefato brancas e as cartas de artefato cinza aparecem sem terem sido desviradas ainda. Na parte inferior desta página aparecem, também, as operações possíveis a serem realizadas dentro do tabuleiro. A Figura 3 parte b apresenta uma situação de Inspeção de Artefatos, pois o jogador já construiu o artefato (parte a) e ele pode inspecioná-lo. Nessa segunda parte da Figura 3 é ilustrado o resultado de uma inspeção quando o artefato tem erro e quando não tem. SimulES-W aleatoriamente escolhe a qualidade da carta de artefato branca ou carta cinza, sendo que as cartas brancas têm menos possibilidades de terem erro que as cartas cinzas.

Figura 2. Tela principal de SimulES-W

Figura 3. Tabuleiro Individual nas situações de Con strução de Artefato e

Inspeção de Artefato

SimulES-W (Monsalve 2010) encontra-se em fase de empacotamento para disponibilização como software livre. A primeira validação do SimulES-W (Monsalve 2010) permitiu observar os usuários no ambiente e com isso identificar suas expectativas e implementar as melhorias sugeridas na versão a ser disponibilizada. Essa

24


versão, além de implementar as características do jogo do tabuleiro possui a vantagens adicionais, tais como: software livre e aberto para continuar sua evolução; funcionamento como um serviço Web rodando num servidor e com interfaces feita no navegador, sendo disponível sem necessidade de realizar “downloads”, instalações e configurações; sendo , portanto, menos intrusivas que outras aplicações disponíveis para “download”.

Como limitações deste trabalho, pode-se destacar que o Jogo SimulES-W ainda não foi suficientemente utilizado, embora ele já tenha sido submetido a validação nos elementos do jogo de tabuleiro o qual já foi extensamente exposto como foi apresentado anteriormente. Experimentos de validação que permitam melhor avaliar a eficiência/eficácia do SimulES-W no ensino da engenharia de software são trabalhos futuros. Além disso, é preciso comparar tanto o jogo de tabuleiro quanto SimulES-W para identificar restrições e vantagens de cada um dos ambientes do jogo. No entanto, uma das grandes vantagens do SimulES-W sobre as versões anteriores é a possibilidade de edição das Cartas de Problemas e das Cartas de Conceito, fazendo portanto que o material a ser enfatizado pelo curso seja customizado pelo professor.

5. Conclusões e Trabalhos Futuros

Jogos educacionais são promissores porque ajudam na motivação, simulam ambientes reais, podem ser colaborativos e ajudam no entendimento do perfil profissional (Monsalve, Werneck e Leite, 2010), (Gramigma, 1994). Considerando que outras áreas do conhecimento entendem jogos como um aliado da aprendizagem e o fato de que esta tendência é abastecida por recursos tecnológicos cada vez mais sofisticados, entendemos que o SimulES-W é uma plataforma promissora para alcançar resultados eficazes de disseminação de conhecimento de Engenharia de Software.

Lidando com: risco, custo, qualidade com base na verificação por inspeção, conhecimentos pontuais das cartas, a relação da complexidade e do tamanho do projeto, habilidade, maturidade e salário, o aluno tem oportunidade a aprender conceitos tanto sob a ótica da gerência técnica como da gerência de projeto.

Planejamos, para o futuro, a avaliação das diferentes interfaces do SimulES-W, tanto com o foco da comunicabilidade, como com o foco da observação dos jogadores, para que possamos conhecer melhor sobre as interações do jogo. Na distribuição do SimulES-W pretende-se estimular que outros grupos possam também avaliar a eficácia/eficiência do uso do SimulES-W como prática educacional. Essas avaliações devem procurar medir e comparar os resultados do uso do jogo e para isso, métricas precisam ser desenvolvidas.

Referências Baker, A. (2003). “Problems and Programmers”. Honors Thesis, Department of Informatics, School of

Information and Computer Science, University of California, Irvine, CA.

Birkhoelzer, T., Navarro, E. e Van Der Hoek, A. (2005). “Teaching by Modeling instead of by Models”, Proceedings of the 6th International Workshop on Software Process Simulation and Modeling, MO.

Claypool, K. e Claypool, M. (2005). “Teaching software engineering through game design”. ACM SIGCSE Bulletin, v.37 n.3.

25


Figueiredo, Eduardo; Lobato, Cidiane; Dias, Klessis; Leite, Julio e Lucena, Carlos. (2007). “Um Jogo para o Ensino de Engenharia de Software Centrado na Perspectiva de Evolução” em Workshop sobre Educação em Computação (WEI – 2007), 15, Rio de Janeiro, , 37-46.

Fuks, H., Raposo, A.B. & Gerosa, M.A. (2003) “Do Modelo de Colaboração 3C à Engenharia de Groupware”, Simpósio Brasileiro de Sistemas Multimídia e Web – Webmidia 2003, Trilha especial de Trabalho Cooperativo Assistido por Computador, 03 a 06 de Novembro de 2003, Salvador-BA.

Gramigma, M. R. M. (1994). “Jogos de empresa e técnicas vivenciais”. 1ªEdição, SPaulo, Makron Books.

Isotton, E. (2008). “Ferramenta Educacional para Apoio ao Ensino de Práticas de SCRUM”, Monografia de Trabalho de Conclusão de Curso Graduação, Sistemas Informação, FACIN-PUCRS, Porto Alegre.

Jain, A. e Boehm, B. (2006). “SimVBSE: Developing a Game for Value-Based Software Engineering. Proceedings 19th Conference on Software Engineering Education and Training”. Paginas 103 -114.

Kieling, E.; Rosa, R. Planager (2006), “Um Jogo para Apoio ao Ensino de Conceitos de Gerência de Projetos de Software”, Monografia de Trabalho de Conclusão de Curso de Graduação, Ciência da Computação, FACIN, PUCRS, Porto Alegre.

Lino, J. I. (2007), “Proposta de um Jogo Educacional para Medição e Análise de Software”, Trabalho de Conclusão de Curso, Sistemas de Informação, Universidade Federal de Santa Catarina, Florianópolis.

Monsalve, E. S. (2010), “Construindo um Jogo Educacional com Modelagem Intencional Apoiado em Princípios de Transparência”, Dissertação de Mestrado, PUC–Rio, Março de 2010.

Monsalve, E.; Werneck, V.; Leite, J.C.S.P. (2010), “Evolución de un Juego Educacional de Ingeniería de Software a través de Técnicas de Elicitación de Requisitos”, Proceedings of XIII Workshop on Requirements Engineering (WER’2010), Cuenca, Ecuador, Abril 2010, 12–23.

NETBEANS 6.5 (2008), NetBeans IDE 6.5 Release Candidate Information. Disponível em <http://www.netbeans.org/community/releases/65/>, acesso em: fevereiro de 2010.

Oliveira, A. P. A. (2008). “Engenharia de Requisitos Intencional: Um Método de Elicitação, Modelagem e Análise de Requisitos”, Tese de Doutorado. PUC–Rio, Março de 2008.

Pressman, Roger (2006). “Software Engineering: A Practitioner's Approach”, 7ª Edição, Mc Graw Hill.

Serrano, M.; Serrano, M.; Napolitano, F.; Soares, B. (2007). “Evolução do SimulES Versão 2.0”, Monografia em Ciências da Computação, Departamento de Informática. PUC–Rio.

Serrano, M. (2007) http://mileneserrano.wordpress.com/2007/06/14/um-dia-de-jogo-simules/ acesso em 7 de abril.

Napolitano, F. (2007) http://fnapolitano.blogspot.com/2007/06/simules-simulador-de-engenharia-de.html acesso em 7 de abril.

Smith, R, Gotel, O. (2008). “Gameplay to Introduce and Reinforce Requirements Engineering Practices”, Proceedings of 16th IEEE International Requirements Engineering Conference, ISBN ~ ISSN:1090-705X , 95-104.

Software Engineering Simulation by Animated Models (SESAM) (2009), Stuttgart, Alemanha, Disponível em: <http://www.iste.uni-stuttgart.de/se/research/sesam/overview/index_e.html> acesso em 7 de abril.

Sweedyk, Elizabeth e Keller, Robert M., (2005), “Fun and games: a new software engineering course”, Proceedings of the 10th annual SIGCSE.

Yu, E. (1995). “Modeling Strategic Relationships for Process Reengineering”, Ph.D. Thesis, Graduate Dept. of Comp. Science, University of Toronto.

26


Ensino da Engenharia de Software por meio de Fábricas de

Software no contexto Distribuído: Um Relato de Experiência

Catarina Costa1, Rodrigo Rocha

1, Jair Figueirêdo

1, Marcos Duarte

1, Silvio Meira

1,

Rafael Prikladnicki2

1Centro de Informática – Universidade Federal de Pernambuco (UFPE) 50.732-970 – Recife – PE – Brasil

2Pontifícia Universidade Católica do Rio Grande do Sul – PUCRS – FACIN

90619-900 – Rio Grande do Sul – RS – Brasil

{csc, rgcr, jjcf, mpd, srlm}@cin.ufpe.br, [email protected]

Abstract. Globalization has enabled the development of software evolved

significantly, creating the Distributed Software Development. Given this

development environment, it is necessary to hire professionals who can

perform well development activities in this scenario. Therefore, the

learning centers need to create a motivating environment in which to

prepare professionals for the market. This paper aims to report the

experience of students in learning the concepts of software engineering,

using a pedagogical tool a small software factory through of a real project

and working in a distributed environment.

Resumo. A globalização permitiu que o desenvolvimento de software

evoluísse significativamente, criando o Desenvolvimento Distribuído de

Software. Diante deste ambiente de desenvolvimento, faz-se necessário a

contratação de profissionais que possam desempenhar bem as atividades

de desenvolvimento neste cenário. Dessa forma, os centros de ensino

precisam criar um ambiente motivador, no qual seja possível preparar

profissionais para o mercado. O objetivo nesse artigo é relatar a

experiência de alunos no aprendizado dos conceitos de engenharia de

software, utilizando como ferramenta pedagógica uma pequena fábrica de

software com um projeto real trabalhando de maneira distribuída.

1. Introdução

A evolução do software faz com que diversas áreas do conhecimento reconheçam sua importância como posição estratégica perante o mercado. Com esse reconhecimento, a demanda por software aumenta, transformando mercados nacionais em mercados globais. Essas transformações alteraram a forma como os produtos são concebidos, construídos, testados e entregues aos clientes finais. Desta maneira, o software tem se tornado um componente estratégico para diversas áreas de negócio, mais especificamente na área de Engenharia de Software (ES), criando novas formas de cooperação e competição que vão além das fronteiras dos países [Herbsleb e Moitra, 2001]. É possível verificar essas mudanças a partir do final da década passada, no qual, visando diminuir os custos e buscando recursos mais qualificados, muitas

27


organizações começaram a experimentar o Desenvolvimento Distribuído de Software (DDS) [Herbsleb e Moitra, 2001].

O ambiente distribuído herdou os desafios do desenvolvimento tradicional (co-localizado) de software e acrescentou outros desafios ao processo ao adicionar fatores como dispersão física, distância temporal e diferenças culturais. Diante deste complexo ambiente de desenvolvimento, faz-se necessário cada vez mais a contratação de profissionais que possam planejar, analisar e especificar requisitos, projetar arquitetura de sistemas e coordenar todas estas atividades em meio as adversidades trazidas no novo cenário de desenvolvimento global. Em meio à crescente demanda, os centros de ensino que preparam profissionais para o mercado, precisam de ferramentas pedagógicas que possam criar um ambiente motivador, no qual seja possível aplicar e preparar os alunos para solucionar os problemas demandados pelo mercado.

Neste contexto, este trabalho tem como principal objetivo relatar a experiência de uma equipe de alunos de pós-graduação em Ciência da Computação da Universidade Federal de Pernambuco no aprendizado dos conceitos de engenharia de software, utilizando como ferramenta pedagógica de aprendizado pequenas fábricas de software [Siy, 2001] com a missão de solucionar um problema real trabalhando de maneira distribuída. Desta forma, os alunos foram divididos de acordo com o perfil de conhecimento e lhes foi atribuída a tarefa de organização completa da fábrica: definição de papéis, hierarquia, processo de desenvolvimento, seleção de ferramentas de gerencia, entre outros.

O trabalho está organizado da seguinte maneira: na seção 2 é apresentado o contexto da fábrica de software criada para a disciplina de Engenharia de Software; na seção 3 é apresentado o projeto desenvolvido, o papéis, processo e ferramentas, assim como os desafios e adaptações realizadas; na seção 4 uma reflexão sobre a aprendizagem no uso de fábrica de software para o ensino da engenharia de software é apresentada; e por fim, na seção 5 são apresentadas as considerações finais.

2. A Fábrica de Software: TechnoSapiens

O estudo de caso é parte de uma disciplina de Engenharia de Software (IN953, 2008) com foco na criação de fábricas de software que façam uso de desenvolvimento distribuído para a realização de projetos reais. Com a definição dos clientes e projetos, os alunos têm quatro meses para executar um ambiente de fábrica de software e entregar os produtos definidos em comum acordo com o cliente. A TechnoSapiens foi uma das fábricas criadas durante a disciplina e foi composta por nove estudantes, todos trabalhando de forma distribuída. Estavam envolvidos no projeto membros distribuídos nas cidades de Recife – PE, João Pessoa – PB e Campina Grande – PB. Nenhum dos integrantes havia trabalhado anteriormente com outro membro da equipe ou de forma distribuída.

A fim de permitir adequações e melhorias na fábrica, um projeto piloto foi executado no primeiro mês da disciplina. O objetivo foi validar a estrutura organizacional da fábrica e do processo de desenvolvimento adotado. Após o primeiro projeto, um segundo projeto de dimensões maiores foi executado num

28


período de três meses. O projeto assumido pela fábrica foi o desenvolvimento de uma versão para dispositivos móveis do serviço citIX1. O citIX utiliza um sistema de informações geográficas que possibilita que os usuários do serviço construam uma rede de conhecimento sobre as características (segurança pública, entretenimento, infraestrutura, serviços públicos, entre outros.) de uma determinada localidade ou região.

3. O Projeto CitIX

O projeto CitIX é um projeto liderado pelo Centro de Estudos Avançados do Recife – CESAR, seu principio é montar uma rede social sobre uma plataforma de sistemas de coordenadas geográficas, produzindo conhecimento categorizado em determinada região. Uma versão Web do projeto já havia sido construída, cabendo a TechnoSapiens construir uma versão para dispositivos móveis.

Como princípios base do desenvolvimento do projeto buscou-se utilizar as mais adequadas e eficientes técnicas, práticas, métodos e ferramentas de engenharia de software, tendo em vista as peculiaridades de um projeto distribuído. Embora o projeto fosse acadêmico havia um cliente real e um prazo determinado a ser cumprido, demandando muito empenho e responsabilidade por parte do time.

Logo após a definição do projeto a ser desenvolvido, o time precisou tomar diversas decisões, tais como: os papéis dentro da fábrica, o processo a ser seguido, as ferramentas a serem utilizadas, as formas de comunicação, entre outras. Para direcionar os trabalhos da equipe, o primeiro passo foi definir um plano de projeto, com todas as informações necessárias, para que o trabalho fosse conduzido da melhor forma. O plano de projeto continha uma visão geral do projeto: objetivos, escopo, os papéis e responsabilidades bem definidos, as entregas do projeto, os riscos identificados até aquele momento, um plano de comunicação entre o time e o cliente, com a periodicidade de reuniões e os artefatos a serem produzidos, os critérios de aceitação, os treinamentos necessários a equipe, e finalmente, o cronograma do projeto.

Um gerente e um vice-gerente foram eleitos de acordo o perfil identificado pelo time para o planejamento e acompanhamento dos trabalhos. Eles foram responsáveis por definir um plano de projeto e o cronograma de atividades, assim como um plano de comunicação e os meios de acompanhamento dos trabalhos. Um SQA (Sofware Quality Assurance) ficou responsável por acompanhar a evolução e realizar as adaptações durante o andamento do projeto. Também visando garantir a qualidade, um membro ficou alocado para o planejamento e realização de testes do projeto e reportar aos demais membros e principalmente a gerência as necessidades e impedimentos para a realização dos mesmos.

Para garantir um adequado ambiente de desenvolvimento, bem como uma gestão de configuração eficiente, um líder técnico com a ajuda de outros membros da fábrica ficou responsável pelas questões técnicas do projeto. Com os principais papéis definidos, todos os demais membros, e até mesmo os que já tinham assumido

1 citIX: http://www.citix.net/

29


algum dos papéis já citados, eram engenheiros de software, papel que exercia diversas atividades no processo (especificação dos requisitos, modelagem de dados, implementação, atualização do site de acompanhamento do projeto, entre outros).

O processo utilizado para conduzir o projeto, chamado de TechnoProcess (Figura 1), foi baseado no Rational Unified Process (RUP) [Cavalcanti, Bandeira e Donegan, 2004], que por ser muito amplo, foi adaptado para uma versão mais leve, reduzindo-se o número de processos e artefatos de acordo com a realidade do projeto. Apesar das muitas aplicações do RUP no TechnoProcess, a equipe sentiu a necessidade de adicionar a ele algumas práticas ágeis que se tem verificado em projetos de sucesso. Com isso, foram incorporadas à metodologia escolhida algumas práticas e lições aprendidas no XP (eXtreme Programming), como por exemplo: revisão permanente do código, programação em par, integração contínua e frequente comunicação.

Figura 1. TechnoProcess

As principais fases definidas para o processo foram: Pré-Venda, Requisitos, Análise e Projeto, Implementação, Testes e Implantação. Fases de suporte também foram definidas: Planejamento e Gerência de Projeto, Revisão e Aprovação, Gerência de Configuração e Garantia de Qualidade.

Em paralelo a definição dos papéis e processo, estudavam-se as ferramentas de apoio ao projeto. A ferramenta web XPlanner de planejamento e acompanhamento foi utilizada para que, mesmo com a distribuição, a equipe tivesse visibilidade do projeto e pudesse acompanhar o andamento das atividades e saber, além das atividades onde cada membro estava alocado, o tempo dedicado e a estimativa de término, gerenciando assim as dependências, além da possibilidade de utilização de métricas de esforço e controle do projeto. Outras ferramentas foram fundamentais para a comunicação entre os membros, tais como e-mails, comunicadores instantâneos ou messengers e o próprio website da fábrica. Finalmente, para o controle de versões dos artefatos foi configurado um CVS (Concurrent Version

System ou Sistema de Versões Concorrentes).

3.1. Desafios e Adequações

Com boa parte das principais decisões do projeto definidas a equipe começou a enfrentar alguns desafios, principalmente ligados à distribuição física dos envolvidos

30


e falta de domínio das tecnologias utilizadas. Os principais desafios identificados durante o projeto são listados abaixo:

Carência de Processos: A definição do processo foi uma das primeiras preocupações da equipe, tendo em vista que sem um processo bem definido, com as fases e os padrões a serem seguidos, os riscos seriam maiores. A maioria dos processos de desenvolvimento amplamente reconhecidos pela literatura não prevê a distribuição do time, e podem não atender adequadamente a esse modelo de desenvolvimento.

Parte da equipe ficou responsável pela definição do processo, que deveria levar em conta a distribuição física dos participantes, a pouca experiência da equipe com a tecnologia de desenvolvimento JavaME e a necessidade de um processo leve, que contemplasse uma quantidade menor de artefatos. O Processo definido pela equipe buscou integrar melhores práticas de metodologias reconhecidas pela literatura, adaptando para a realidade do projeto.

Falta de domínio e experiência no ambiente e ferramenta de

desenvolvimento: Um novo projeto, uma nova equipe e uma nova tecnologia podem trazer insegurança ao time. Adicionando a isso o fato de a equipe trabalhar distante, pode aumentar mais ainda o problema. O colega com mais experiência não está ao lado para responder a uma dúvida rápida, ajudar em um impedimento ou problema, ou compartilhar uma solução. A troca de conhecimento sobre o projeto e a tecnologia envolvida é dificultada. A maioria dos membros da equipe não tinha conhecimento das tecnologias necessárias para o desenvolvimento.

Para contornar tal problema, houve treinamento presencial para a equipe sobre a instalação, configuração e adaptação do ambiente. O gerente de configuração atendeu individualmente todos aqueles membros que, mesmo após o treinamento, permaneceram com problemas. A equipe, embora tenha atrasado algumas atividades pelas dificuldades na configuração do ambiente de desenvolvimento, conseguiu, principalmente com os esforços dos membros mais experientes, resolver os problemas e dar continuidade aos trabalhos.

Estimativas: Com a distribuição do time, o acompanhamento por parte da gerência é menor, e a falta de comprometimento com as atividades do projeto pode acontecer, levando as estimativas irreais e ao atraso no andamento do projeto. A gerência começou a atribuir às atividades a equipe em um encontro presencial no início de cada semana e a estimar a quantidade de horas necessárias para a realização de cada atividade, buscando uma distribuição equivalente. Ao final do tempo previsto, o membro deveria reportar à gerencia a realização ou não da mesma, as dificuldades e impedimentos. O acompanhamento era realizado por e-mails e em reuniões presenciais no início e fim da semana.

Logo nas primeiras semanas percebeu-se a fragilidade desta abordagem, já que, como o gerente era o responsável pelas estimativas, os membros não estavam realmente comprometidos com as datas que eram estabelecidas e com o decorrer dos trabalhos, houve um aumento e uma maior dependência entre as atividades, atrasando o projeto. Quando a gerência percebeu que as estimativas não eram realistas, e os prazos do projeto estavam comprometidos, a equipe começou a usar uma estratégia,

31


no qual, todos os membros passaram a utilizar um processo de autogerenciamento. Com o auxílio de uma ferramenta web, a gerência ou o próprio responsável cadastrava as atividades e o tempo estimado para a realização. Percebeu-se que, neste projeto, quando o próprio membro era responsável pela estimativa de suas atividades, o grau de comprometimento era maior.

Feedbacks demorados e deficiência nas ferramentas de comunicação: Embora o time tivesse contato face-a-face em determinados períodos, a maior parte da comunicação era por meio de ferramentas. A principal ferramenta de comunicação utilizada foi e-mail, o que demandava um tempo de espera bem maior do que se o outro membro estivesse trabalhando no mesmo ambiente físico. O e-mail, por ser um meio de comunicação assíncrono, em diversos momentos não atendeu completamente as necessidades do time, pois, as dúvidas e informações só eram respondidas quando outros membros estavam disponíveis. Foi observada também a deficiência de algumas ferramentas, já que na maioria dos softwares testados para conversas via áudio, a equipe teve dificuldades, como: (1) Suportar todos os membros na chamada; (2) Falhas no áudio; e, (3) Instabilidade de conexão.

Assim, quando era necessário realizar uma reunião online via conferência, um moderador era definido para coordenar a conversa, controlando a ordem de fala dos membros do time, dessa forma, evitava-se sobrecarga na conversação. Como as ferramentas utilizadas não conseguiam suportar a quantidade de usuários da equipe, a solução foi intensificar o uso de ferramentas assíncronas, principalmente o e-mail.

Controle dos Riscos: Embora os riscos tenham sido levantados no início e durante todo o projeto, assim como as respostas aos mesmos, a implementação dos planos de resposta dentro de um desenvolvimento distribuído é difícil. A gerência acaba ficando com a responsabilidade de mitigar ou conter o risco sem que o time se envolva efetivamente. Com a alta probabilidade, pela pouca experiência da equipe em projetos distribuídos, de riscos serem ignorados, a equipe se reuniu e identificou em conjunto os riscos do projeto logo no início dos trabalhos. Como a gerência era responsável pelo acompanhamento do projeto e por desempenhar outras atividades, não conseguir acompanhar e realizar as ações de resposta aos riscos, foi definido que cada membro, de acordo com o papel que exercia dentro da equipe, ficar responsável por acompanhar e implementar ações de mitigação para reduzir a possibilidade de o risco relacionado ao seu papel acontecer.

4. Ensino / Aprendizagem

Aprender os conceitos de Engenharia de Software em sala de aula é essencial para a formação de um profissional de software, porém, aplicar esse conhecimento em projetos reais ainda na formação desses profissionais é um diferencial e importante caminho a ser seguido para a melhoria desse processo tão complexo. A disciplina na qual o projeto CitIX foi realizado exigiu que os membros estudassem e aplicassem os conceitos da Engenharia de Software em ambientes distribuídos, favorecendo a aplicação e ampliação do conhecimento teórico dos estudantes e a preparação dos mesmos nessa abordagem de desenvolvimento distribuído que vem se tornando cada vez mais presente nas organizações em conseqüência da globalização.

32


A experiência de desenvolver um projeto de software com todas as etapas formais que são sugeridas pela engenharia de software ou parte delas, com um cliente e prazos reais, fornece aos alunos um conhecimento prático e real da dinâmica, das incertezas e dos riscos que envolvem o desenvolvimento de um software. Além disso, com o desenvolvimento, o uso de técnicas, métodos, processos e ferramentas acontecem no dia-a-dia do projeto, permitindo aos envolvidos conhecer e aplicar as diversas soluções existentes e ter uma visão crítica das mesmas, o que seria difícil apenas com o conhecimento teórico da literatura cientifica.

O acompanhamento das fábricas de software se dava semanalmente pelos professores das disciplinas. Os alunos reportavam as atividades realizadas e os artefatos gerados no decorrer da disciplina, expondo como realizaram tais atribuições. Por meio desse acompanhamento, era possível gerar discussões entre a fábrica, os professores e as outras fábricas de software sobre boas práticas, metodologias, técnicas, ferramentas, com intuito gerar análises e debates para mitigar riscos e identificar melhores soluções para possíveis problemas.

O projeto proporcionou aos seus participantes uma experiência única, principalmente pelas suas características singulares, que se tornaram grandes desafios: a equipe nunca havia trabalhado junta ou em um projeto distribuído, ninguém se conhecia; e, boa parte da equipe desconhecia a tecnologia necessária para o desenvolvimento do projeto.

Na pratica diversos conceitos/praticas puderam ser trabalhados, levando alguns participantes do grupo a ter o primeiro contato real ou aprimorar os conhecimentos que tinham, dentre os principais:

• Adequação e utilização do processo de desenvolvimento RUP (utilizando práticas das metodologias ágeis) para a realidade distribuída;

• Gerência de configuração: nomenclatura de documentos, controle de versão, solicitações de mudanças, auditoria, backup, entre outros;

• Gerência de projeto: planejamento, estimativas, distribuição e acompanhamento de tarefas, e utilização de ferramenta para gestão;

• Gerência de qualidade de software: definição de um processo com padrões e procedimentos, e definição de métricas;

• Plano de teste de software: planejamento e execução de testes, definição de casos de testes, ferramentas de gestão de mudanças;

• Gerência de Comunicação: definição e padronização dos diferentes meios de comunicação e suas formas de utilização.

Diversas conclusões podem ser extraídas desse projeto, o cliente nem sempre estará presente para acompanhar a evolução e dar seu feedback, a equipe precisa ter um plano de comunicação estabelecido e conhecido por todos, os papéis devem estar bem definidos, o processo deve garantir padrões e a qualidade do produto, entre outros. Porém, a principal conclusão que se pode chegar é que, por mais que a teoria nos direcione e ajude a fazer as melhores escolhas, é na utilização das teorias,

33


práticas, métodos, processos e ferramentas da engenharia de software que é possível ter um conhecimento realmente sólido, real e crítico da utilização dos mesmos, pois a aplicação prática, em paralelo ao ensino da teoria, solidifica fortemente o aprendizado e visa garantir um maior aproveitamento dos conceitos teóricos.

5. Conclusões e Trabalhos Futuros

Com a crescente demanda por produtos de software, é necessário que os envolvidos no processo de desenvolvimento de software busquem por alternativas que possibilitem melhorias seja em custo, qualidade ou tempo de desenvolvimento.

Este estudo relatou a experiência de uma equipe de alunos de pós-graduação que foram incumbidos da realização de um projeto de desenvolvimento distribuído de software na disciplina de engenharia de software por meio de uma fábrica de software. A experiência prática dos alunos permitiu aos mesmos identificar desafios e soluções durante a realização do projeto, além de ter uma visão de como a experiência prática em um projeto real ajuda a equipe a ter um melhor entendimento das teorias, práticas, métodos, processos e ferramentas que envolvem a engenharia de software.

Com o relato é possível perceber o cuidado da equipe em utilizar as melhores práticas da engenharia de software e adaptá-las para a realidade de um projeto distribuído de desenvolvimento, tornando a experiência dos alunos bastante interessante para outros estudantes e cursos na área que busquem melhorar seus programas de ensino por meio do uso de fábrica de software e projetos com clientes reais, no qual, os alunos têm prazos e responsabilidades bem definidos.

Neste sentido, uma abordagem semelhante à aplicada neste relato pode ser utilizada por outros grupos no processo de ensino e aprendizagem da Engenharia de Software, possibilitando o compartilhamento de experiência semelhante e buscando proporcionar melhor qualificação dos profissionais, por meio da teoria aliada a prática.

Referências

Cavalcanti, Ana Paula de Carvalho, Bandeira, Liane Ribeiro Pinto, Donegan, Paula Marques. (2004). Um modelo de gerência de projetos baseado no RUP com aplicações em PMBOK, VI Simpósio Internacional de Melhoria de Processos de Software, São Paulo.

Herbsleb, J. D.; Moitra, D. (2001). Guest editors’ introduction: global software development. IEEE Software.

IN953 (2008), Software Engineering: Building Open Source Software Factories. Disponível em http://www.cin.ufpe.br/~in953/.

Siy, H. P., Herbsleb, J. D., Mockus, A., Tucker, G. T., and Krishnan, M. (2001). “Making the Software Factory Work: Lessons from a Decade of Experience”. In Proceedings of the 7th international Symposium on Software Metrics (April 04 - 06, 2001). METRICS. IEEE Computer Society, Washington, DC, 317.

34


Avaliação do Componente Curricular Interdisciplinar de

Engenharia de Software

David Moises B. Santos, Hugo Saba

Departamento de Ciências Exatas – Universidade Estadual de Feira de Santana (UEFS) Avenida Transnordestina, s/n – Novo Horizonte – 44.036-900 – Feira de Santana – BA

[email protected], [email protected]

Abstract. The importance of interdisciplinarity has grown significantly in recent

years, however, many undergraduate courses offer curriculum components

without a proper integration. Thus, this paper aims to present an evaluation of

the results of the experience of an interdisciplinary project in the Software

Engineering component.

Resumo. A importância da interdisciplinaridade tem crescido muito nos últimos

anos, porém, muitos cursos de graduação oferecem componentes curriculares

correlatos em momentos diferentes, sem uma devida integração. Desta forma,

este trabalho tem por objetivo apresentar uma avaliação dos resultados

alcançados com a experiência da aplicação de um projeto interdisciplinar no

componente curricular de Engenharia de Software.

1. Introdução

Em um mundo globalizado cada vez mais está se tornando comum a integração de tecnologias, áreas de conhecimento, empresas, pessoas, etc. Seguindo essa tendência, componentes curriculares também podem ser trabalhados em conjunto, compartilhando trabalhos, desafios e oportunidades de aprendizado [Bittencourt & Figueiredo, 2003]. Um exemplo é a área de Engenharia de Software que agrega diversas áreas tais como gerência de projetos, testes, processo de software, gerência de configuração, entre outras.

Tendo em vista essa demanda foi criado então o componente curricular do Estudo Integrado (EI) de Engenharia de Software, com carga horária de 180 horas, oferecido pelo curso de Engenharia de Computação da Universidade Estadual de Feira de Santana (UEFS), o qual agrega três outros componentes (módulos), com 60 horas cada: (1) Engenharia de Software, (2) Análise e Projeto de Sistemas e (3) Banco de Dados.

Destarte, o objetivo deste artigo é avaliar justamente a aplicação deste componente curricular cujo carro-chefe é a aplicação de um projeto interdisciplinar que agrega o conteúdo dos três módulos envolvidos. Para tanto foi aplicado um formulário de avaliação de Projetos Interdisciplinares baseado na proposta de Cunha e Souza Júnior (2007).

2. Descrição do EI de Engenharia de Software

O EI de Engenharia de Software é um componente obrigatório do currículo do curso supracitado. A avaliação feita neste trabalho foi realizada durante o período letivo 2007.1 – devido a ocorrências de greves, a oferta do componente aconteceu de fato entre o final de 2007 e início de 2008. Nesta turma, estavam matriculados vinte alunos.

Em suma, a carga horária do EI (180 horas) é dividida pela metade, sendo a

35


primeira destinada a parte teórica, e a outra metade, a parte prática. Uma vez que o tempo destinado a explanação da teoria é reduzido pela metade não é possível detalhar todo o conteúdo programático em sala de aula. Neste sentido, os tópicos abordados em sala de aula têm a finalidade de: 1) apresentar uma visão geral daqueles conceitos vistos na prática; 2) detalhar conceitos complexos; e 3) explanar assuntos que não são abordados na prática, afinal não é possível abordar de forma prática, com a atual carga horária, todos os conceitos envolvidos na engenharia de software.

Considerando o teor prático do EI, é adotada uma metodologia de ensino prática centrada no estudante, denominada PBL (Project-Based Learning) [Thomas, 2000][Duch, 2001][Santos et al, 2007b], onde o aprendizado é motivado através de projetos – mais especificamente, neste componente curricular trata-se de projetos interdisciplinares que abrangem o conteúdo dos três módulos envolvidos. O projeto avaliado aqui objetivou o desenvolvimento de um software em parceria com a Assessoria de Informática da UEFS.

Nesta abordagem didático-pedagógica um projeto (problema) é apresentado aos alunos com o intuito de os mesmos explorarem o domínio da solução exercitando suas diversas habilidades. Para tanto, a turma é dividida em grupos de dez alunos, sendo um tutor (professor) alocado para cada grupo. O encontro de cada equipe acontece simultaneamente1. Para direcionar o aprendizado, são indicados recursos de aprendizagem (livros, artigos, vídeos, entre outros) apropriados à atividade designada. Todavia, os estudantes também são estimulados a buscar outras fontes de conhecimento. Vale ressaltar que essa abordagem é trabalhada com os alunos em outros componentes curriculares desde o ingresso no curso [Santos et al, 2007a].

O processo de software usado para o desenvolvimento de software foi baseado do Extreme Programming [Beck, 2000], fragmentando o projeto em iterações e releases; consequentemente, os alunos tinham que entregar uma parte do software periodicamente. Além disso, muitas de suas práticas foram usadas e/ou adaptadas. Os artefatos a serem entregues também foram especificados com cuidado para não provocar uma sobrecarga, e prejudicar a entrega do produto final. Mais informações sobre o EI de Engenharia de Software podem ser encontradas em [Santos et al, 2007b].

3. Avaliação e Análise

Buscando avaliar o EI de Engenharia de Software foi usado, como dito antes, o formulá-rio de Avaliação de Aprendizagem por Projetos Interdisciplinares [Cunha & Souza Júnior, 2007], o qual é dividido em seis tópicos: 1) Processo Ensino-Aprendizagem; 2) Desenvol-vimento do Projeto; 3) Integração entre as Disciplinas Envolvidas; 4) Simulação do Ambi-ente do Mercado de Trabalho; 5) Dinâmica do Time do Projeto; 6) Critérios de Avaliação.

Cada tópico é composto por itens correlacionados a fim de auxiliar na avaliação. Para cada um destes itens, os alunos marcaram uma das opções disponibilizadas – pouco, razoável ou muito – para demonstrar sua impressão quanto ao método de ensino-aprendizagem no projeto interdisciplinar do EI de Engenharia de Software. Apresentaremos aqui os resultados analisados a partir do preenchimento do formulário logo após a entrega da última release, ou seja, final do projeto. Tais resultados foram quantificados e estão apresentados em forma de gráficos, como aqueles presentes na Tabela 1 e demais. Em cada uma das tabelas apresentadas, está presente a avaliação de

1 Nas aulas teóricas a turma fica em única sala onde um professor ministra as aulas (modelo tradicional).

36


dois tópicos, sendo que para cada um há uma coluna destinada a descrição do item do tópico correspondente e uma outra apontando a síntese dos dados da avaliação realizada pelos estudantes. A seguir, são analisados os dados coletados.

3.1. Processo Ensino-Aprendizagem

Este tópico avalia questões gerais a respeito do processo de ensino-aprendizagem aplicado ao componente curricular (ver Tabela 1). Primeiramente, é analisada a aliança teoria-prática, que segundo os alunos, pouco prejudicou o aprendizado. Vale destacar que um componente como Engenharia de Software intrinsecamente envolve tanto teoria quanto, principalmente, prática. Quando se recorre a literatura [Alves & Benitti, 2006] [Sarinho, 2005][Cunha & Souza Júnior, 2007], fica claro que isto é uma das características fundamentais de um componente como este, independentemente se o mesmo está ou não integrado com componentes correlatos.

Tabela 1. Avaliação dos tópicos 1 e 2. Processo ensino-aprendizagem Desenvolvimento do projeto

Item Avaliação Item Avaliação Relação teoria x prática favoreceu aprendizado

Aproveitamento dos conteúdos de componentes anteriores

Aplicação prática de conteúdos abordados pelos módulos envolvidos

Clareza e coerência na definição dos objetivos a serem alcançados

Aumento da auto-afirmação e criatividade do aluno

Cumprimento de prazo das exigências previstas

Desenvolvimento de habilidades (lingüística, síntese, interpretação, análise, prospecção, espírito de equipe)

Abertura do corpo docente para dúvidas e questionamentos

Mediação/ acompanhamento do professor na execução das tarefas

Produto final coerente com os objetivos propostos

O planejamento das aulas precisa ser aperfeiçoado para que aja um bom casamento da teoria a medida que a prática evolui – este é o item que mais precisar ser melhorado dentre aqueles do mesmo tópico de acordo a visão dos alunos. Apesar de o planejamento ter sido feito com todos os professores envolvidos, ainda acaba por escapar detalhes que surgem com o decorrer das discussões e necessidades dos alunos. Isso ocorre principalmente porque o volume de informação envolvido é muito grande. Este planejamento tem sido aprimorado ao longo das ofertas do componente ano a ano. Todavia, é importante ressaltar ainda que não é possível abordar em sala de aula todo o assunto contemplado pelos três módulos, e como já foi explanado, algumas atividades não são abordadas teoricamente justamente por esperarmos que o aprendizado aconteça de forma prática. O que esperamos é que o planejamento das aulas aconteça de forma a diminuir o impacto do aprendizado de tão grande volume de conhecimento.

37


Os itens auto-afirmação e criatividade e desenvolvimento de habilidades tiveram de certa forma uma boa avaliação uma vez que foram os que apresentaram as maiores proporções para a opção “muito” dentre os itens deste tópico. O principal fator que contribui para isto é a aplicação do método PBL que favorece o desenvolvimento de habilidades não só técnicas, mas também não-técnicas tais como expressão oral e escrita, criatividade e trabalho em equipe.

Um aspecto importante aqui é o acompanhamento das atividades discentes pelo professor durante a execução do projeto. Apesar de os alunos realizarem muitas tarefas extra-classe, seis horas semanais de prática são dedicadas em sala de aula com supervisão do professor, quando o mesmo pode fazer intervenções corretivas com vistas à um melhor aprendizado. Normalmente, isso não ocorre em muitos componentes oferecidos por outras instituições uma vez que a prática é realizada quase que integralmente extra-classe e o tempo para as intervenções são normalmente compartilhado com outras equipes.

3.2. Desenvolvimento do Projeto

Neste tópico avalia-se questões pertinentes aos pré-requisitos, objetivos e produto final do componente curricular (ver Tabela 1). Antes deste EI, os componentes correlatos que os alunos haviam cursado foram Algoritmo e Programação I (uma introdução a programação) e o EI de Programação (sucintamente, abrange estrutura de dados e orientação a objetos). Na etapa inicial do projeto pouco se usa programação, mas sim muito planejamento. Somente após essa etapa é que usa-se bastante dos conhecimentos de programação, justamente na implementação do software. Daí nenhum aluno ter marcado a opção de “pouco” aproveitamento no momento de avaliação.

Quanto a clareza e coerência dos objetivos, detectamos que muitas vezes os mesmos não ficam explícitos para os alunos. Em alguns momentos observamos que é por falta de conhecimento do assunto, e a medida que avançamos no conteúdo eles têm uma melhor percepção (um reflexo disso é o item “produto final coerente com os objetivos propostos”). Por outro lado, também notamos que é preciso, por parte dos docentes, deixar os objetivos mais explícitos, sinalizando de forma recorrente. Com o decorrer das atividades, frequentemente os estudantes focam em uma atividade, na implementação, por exemplo, e acabam não tendo uma visão geral muito clara e concisa.

Quanto ao cumprimento de prazos, acreditamos que não houve uma boa avaliação porque, dentre outros motivos, da metade para o fim do projeto, as atividades aumentam bastante devido sobretudo a fase de implementação. Por essas tarefas extra-classe ampliarem alunos também têm que ter uma maior autonomia e, consequentemente, recorrem com mais frequência ao tutor. É importante ressaltar que os tutores não dão respostas prontas, mas buscar auxiliar o aluno a refletir, buscar o caminho do aprendizado. Porém, de toda sorte, é um indicador que os tutores devem estar atentos no decorrer do projeto, pois a avaliação discente mostrou-se insatisfeita com a assistência dada (também refletida no item “mediação do professor na execução das tarefas” do primeiro tópico).

3.3. Integração entre as Disciplinas Envolvidas

Este tópico verifica aspectos pertinentes ao desafio de integrar os módulos do Estudo Integrado (Tabela 2). Um primeiro (grande) desafio é a sinergia das atividades dos professores envolvidos. Como são professores diferentes para equipes diferentes, algumas vezes acontecem algumas divergências nas tarefas realizadas tanto pelo estilo de cada docente quanto pelo ritmo dos próprios componentes das equipes. A finalidade é diminuir

38


ao máximo esse impacto porque diferenças sempre acontecerão. É notável que a sinergia precisa ser mais consistente. Isso pode melhorar a medida que reuniões entre os professores responsáveis ocorram mais freqüentemente.

Tabela 2. Avaliação dos tópicos 3 e 4.

Integração entre as Disciplinas Envolvidas Simulação do ambiente do mercado de trabalho

Item Avaliação Item Avaliação

Sincronia nas tarefas propostas pelos professores envolvidos no projeto

Quanto a simulação sobre exigências do cliente

Atrasos no andamento do projeto por conta dos pré-requisitos dos conteúdos

Experiência com relação a cumprimento de prazos

Correlação entre os conteúdos ministrados nos módulos

Metodologia de trabalho recomendada à profissionais

Clareza em relação à contribuição dos módulos no projeto

Utilização de ferramentas adotadas pelas empresas

Grau de importância dos módulos envolvidos na visão do aluno

Desenvolvimento de competências técnicas

No segundo item retomamos a questão do planejamento do conteúdo ministrado durante a execução do projeto. Como já foi dito, é essencial para diminuir a absorção do volume de informação.

Para todos os demais itens verificamos que faz-se mister um trabalho de conscientização dos alunos de que nem todo o conteúdo é abordado em sala de aula de forma teórica ao mesmo tempo em que é preciso deixar mais claro a contribuição dos módulos para a execução do projeto. De alguma forma, parece que isso está um pouco confuso para os discentes. Um dos aspectos que acreditamos interferir também nesse sentido é o fato de o trabalho ferramental não ser abordado teoricamente, apesar de eles usarem bastante na prática.

3.4. Simulação do Ambiente do Mercado de Trabalho

Aqui é avaliado o ambiente construído durante a execução do projeto. Será que realmente cria-se um ambiente similar aquele encontrado no mercado de trabalho? Bem, a grande maioria dos alunos, senão 100%, neste momento do curso, ainda não tiveram uma experiência fora da universidade, apesar de ouvir muitos rumores a respeito do ambiente de tal mercado. Foi baseado nisso que fizeram a avaliação, ilustrada na Tabela 2.

Destarte, primeiramente avaliaram a postura do cliente, que é funcionário da

39


Assessoria de Informática da universidade. É notável a importância de um cliente “real”, que não seja o professor. Mesmo assim, não foi o suficiente segundo a avaliação. Talvez um cliente que não fosse da área de informática retrataria com mais veracidade a realidade.

Quanto a preocupação de comprometimento com a qualidade, entrega do produto final e cumprimento de prazos, fica mais evidente uma boa avaliação, afinal os prazos eram claros e determinados com antecedência.

A metodologia de trabalho usada, resumidamente, se detém ao processo de software criado de acordo a realidade do componente curricular, levando em sua receita alguns dos ingredientes usados em algumas poucas empresas uma vez que muitas ainda não usam metodologias ágeis, base do processo XP. Quantos as ferramentas, muitas delas são definidas pelos próprios alunos, eles têm a liberdade de tomar decisões a respeito de tecnologias desde que apresentem boas argumentações. Já estas ferramentas, muitas delas são de fato usadas por empresas.

No primeiro tópico (processo ensino-aprendizagem), um dos itens avaliou o desenvolvimento de habilidades não técnicas enquanto que no último item deste tópico é avaliado o de habilidades técnicas. De forma unânime, não houve “pouco” desenvolvimento destas habilidades, e 71% marcaram “muito”.

3.5. Dinâmica do Time do Projeto

As atividades inerentes ao trabalho em equipe são discutidas neste tópico (Tabela 3). Desde o início do semestre, os alunos têm autonomia para desenvolver o projeto. Assim, como o gerente de projeto, os outros papéis de cada membro são acordados pela equipe. Por terem pouca prática no desenvolvimento de projetos com uma certa quantidade de pessoas e também um pouco por falta de conhecimento técnico, às vezes os alunos apresentam dificuldades em como dividir as tarefas entre os membros e em como integrá-las após sua realização (primeiro item deste tópico). Porém, à medida que avançam, também vão desempenhando melhor suas tarefas, adquirindo mais experiência.

Como acontece em qualquer outra atividade curricular, freqüentemente ocorre que alguns alunos se dediquem mais ao projeto do que outros, o que acaba gerando uma determinada insatisfação com a dedicação de alguns colegas. Caso todos se empenhassem de igual forma em prol do objetivo comum a avaliação do item 2 deste tópico seria 100% com o qualificador “muito”. Isso também está refletido no item 5, quando percebe-se participação desigual dos membros do time em relação ao desenvolvimento das atividades.

Apesar das discordâncias entre os membros da equipe (item 4), há uma relativa boa visão de trabalho em grupo (item 3) pelos membros. A discussão entre os membros é sempre estimulada conforme descrito no método PBL. Como todo trabalho em grupo, há divergências entre idéias, mas o consenso e o respeito mútuo frequentemente prevalecem.

3.6. Critérios de Avaliação

Entre todos os tópicos, este é o que mais precisa ser aperfeiçoado no componente, pois obteve os piores resultados (Tabela 3). Isso se deve sobretudo por diversas variáveis estar envolvidas na avaliação, tornando-a complexa. Através do projeto, tenta-se avaliar o desempenho individual de cada um bem como da equipe como um todo.

As habilidades de cada aluno (ex.: participação, expressão oral, respeito mútuo, capacidade de síntese, argumentação, etc) são avaliadas durante a reunião da equipe e por

40


uma argüição individual após a entrega de cada etapa do produto, ambas pelo tutor responsável do grupo. O primeiro item apresentou uma baixa satisfação dos alunos quanto a isso, talvez nem tanto pelos instrumentos usados, mas sim como foram aplicados. Desta forma, faltou uma maior transparência dos critérios atribuídos no sentido de divulgá-los antecipadamente (item 2) e serem mais claros (item 5).

Tabela 3. Avaliação dos tópicos 5 e 6.

Dinâmica do time do projeto Critérios de avaliação

Item Avaliação Item Avaliação

Clareza na divisão das tarefas

Avaliação reflete aprendizado individual das competências requeridas

Cooperação entre os participantes para alcançar o objetivo comum

Definição prévia dos critérios de avaliação

Visão de trabalho em grupo

Avaliação unificada prejudica aprovação do aluno

Consenso na discussão das idéias e escolha da solução apropriada

Padronização dos critérios de avaliação dos professores

Participação dos membros do time em relação ao desenvolvimento das atividades

Clareza dos critérios de avaliação por parte dos alunos

Um ponto que já foi levantado e que entra aqui também é a necessidade de aumento da sinergia entre os professores para que as diferenças e estilos de cada um tenham o menor impacto possível para os alunos (item 3). A forma como cada professor avalia, por exemplo, a participação do aluno é subjetiva, então, neste aspecto é difícil manter a padronização, apesar de o critério ser o mesmo.

7. Considerações Finais

Em suma, este trabalho mostrou uma avaliação da aplicação da abordagem de projeto interdisciplinar no EI de Engenharia de Software. Após a análise, concluímos que este instrumento de aprendizagem tem ajudado bastante no aprendizado dos discentes, promovendo uma articulação das atividades relacionadas aos módulos envolvidos (Engenharia de Software, Banco de Dados e Análise e Projeto de Sistemas).

Todavia, algumas melhorias precisam ser feitas para um melhor aproveitamento do componente. Entre elas, duas que ficaram bastante claras foram uma maior integração dos professores e uma revisão do processo de avaliação. Ademais, também, é preciso abrir um espaço para que os alunos possam expressar melhor suas opiniões, apontando sugestões e especificando melhor alguns pontos desta avaliação. Por exemplo, durante o semestre, é

41


fazer uma avaliação parcial e apresentar os resultados para os próprios alunos a fim de discuti-los e, assim, ir aperfeiçoando todo o projeto.

Por fim, também notamos a necessidade de realizar ajustes no questionário. O primeiro seria ampliar o número de respostas de três (pouco, razoável e muito) para quatro. Percebemos que o qualificador razoável fica muito em “cima do muro”, é importante saber se um determinado item está tendendo mais para melhor do que para pior ou vice-versa. Orientações para preenchimento também devem ser postas para guiar os alunos. Por exemplo, o item “atrasos no andamento do projeto por conta dos pré-requisitos dos conteúdos” do tópico integração entre as disciplinas envolvidas quanto mais a opção “pouco” é marcada melhor seria avaliado, enquanto que os demais itens isso acontece com a opção “muito”. Isso foi questionado por alunos durante o preenchimento.

Referências bibliográficas

Alves, Adriana G.; Benitti, Fabiane B. V. (2006). Processo de Desenvolvimento Integrando Disciplinas de Engenharia de Software. In: XIV Workshop sobre Educação em Computação – Anais do XXVI Congresso da Sociedade Brasileira de Computação – Anais do, p. 206-215, Campo Grande, Mato Grosso do Sul.

Bittencourt, Roberto A. & Figueiredo, Orlando A. O Currículo do Curso de Engenharia de Computação da UEFS: Flexibilização e Integração Curricular. In: XI Workshop sobre Educação em Computação – Anais do XXIII Congresso da Sociedade Brasileira de Computação – Anais do, p. 171-182, Campinas, São Paulo, 2003.

Cunha, Mônica X. C.; SOUZA JÚNIOR, Marcilio F. (2007). Análise dos Resultados da Aplicação de Projetos Interdisciplinares em um Curso de Tecnologia sob a Perspectiva dos Alunos. In: XV Workshop sobre Educação em Computação – Anais do XXVII Congresso da Sociedade Brasileira de Computação. p. 145-154, Rio de Janeiro – RJ.

Duch, Bárbara J.; Groh, Susan E.; Allen, Deborah E. (2001). The Power of Problem-Based Learning: a practial “how to” for reaching undergraduate courses in any discipline. Virginia: Stylus Publishing, LLC.

Beck, K. (2000). Programação Extrema (XP) explicada. Porto Alegre, Artmed Editora.

Santos, David M. B.; Pinto, G. R. P.; Sena, C. P. R.; Bertoni, F. C.; Bittencourt, R. A. (2007a). Aplicação do Método de Aprendizagem Baseada em Problemas no Curso de Engenharia de Computação da Universidade Estadual de Feira de Santana. In: Anais do XXXV Congresso Brasileiro de Educação em Engenharia, Curitiba, Paraná.

Santos, David M. B; Saba, H.; Rocha Junior, J.; Sarinho, V. (2007b). Integrando as Disciplinas de Engenharia de Software, Análise e Projeto de Sistemas e Banco de Dados utilizando PBL. In: XV Workshop sobre Educação em Computação – Anais do XXVII Congresso da Sociedade Brasileira de Computação, p. 66-75, Rio de Janeiro – RJ.

Sarinho, Victor. (2005). Usando Atividades Práticas e Avaliação Contínua no Ensino de Engenharia de Software. In: XXV Congresso da Sociedade Brasileira de Computação – Anais do XIII Workshop sobre Educação em Computação. São Leopoldo - RS.

Thomas, John W. (2000). A Review Of Research On Project-Based Learning. Relatório Técnico. Fundação Autodesk, San Rafael, Califórnia, EUA.

42


Graduação em Engenharia de Software: uma proposta de flexibilização e interdisciplinaridade

Rejane M. da C. Figueiredo, Luiz C. M. Ribeiro Jr, André B. de Sales, Edna Dias Canedo, Ricardo Matos Chaim, Adson Rocha, Giovanni Almeida Santos, Cristiane

Soares Ramos

Faculdade UnB Gama (FGA) - Universidade de Brasília (UnB) Caixa Postal 8114 - CEP: 72405-610 – Gama, DF – Brasil

{rejanemaria, edna.canedo, giovannix}@gmail.com, {lcarlos, andrebdes,

ricardoc, adson}@unb.br, [email protected]

Abstract. The undergraduate course in Software Engineering comes from the Engineering Campus of University of Brasilia (UnB). It is composed of: (a) a common core of disciplines shared with other engineering programs of the Campus; (b) a set of disciplines for overall training in SE; (c) a set of optional disciplines as emphasis that could freely be selected by students in their education; The pedagogical objective of this combination is to allow flexibility and the interrelationship of the four Engineering courses and other disciplines of UnB courses as a whole resulting in a multidisciplinary and interdisciplinary. Thus students are co-responsible over their curriculum construction with a formation in their major area of interest.

Resumo: O curso de graduação em Engenharia de Software (ESW) é oriundo de um Campus de Engenharias da Universidade de Brasília. É composto por (a) um núcleo comum de disciplinas compartilhado com os demais cursos de engenharia do Campus, (b) um conjunto de disciplinas de formação específica de ESW; (c) um conjunto de disciplinas optativas, que constituem as ênfases (e/ou disciplinas de outros campi UnB). O objetivo pedagógico desta combinação é permitir a flexibilização e o diálogo entre os 4 cursos de engenharia, e demais disciplinas da UnB, possibilitando a multidisciplinaridade e interdisciplinaridade e que o estudante seja co-responsável pela construção de seu currículo, com uma formação na área de maior interesse.

1. Introdução

O Projeto Político Pedagógico do curso de Engenharia de Software (PPP-ESW) do Campus da Faculdade Gama (FGA) da Universidade de Brasília (UnB) é resultado de amplas discussões a respeito da sua formulação, realizadas fundamentalmente com professores da FGA. O maior desafio dos envolvidos se concentrou na formulação do primeiro curso de graduação em engenharia de software no país, sem diretrizes curriculares nacionais específicas, em um campus de Engenharias, enquanto os demais são oriundos de departamentos de computação. .

A fundamentação do PPP-ESW foi calcada nas diretrizes do Conselho Nacional de Educação (CNE), nas diretrizes curriculares das principais associações norte-americanas de engenharias e de computação, como IEEE-CS e ACM e nos currículos de referência da SBC.

43


Neste contexto, apresenta-se neste trabalho, o curso de graduação em Engenharia de Software da FGA. Na Seção 2 apresenta-se o contexto de criação do curso no Campus FGA. Na Seção 3, a estrutura metodológica e pedagógica adotada na FGA. Na Seção 4, as principais referências que fundamentam a proposta do curso. Na Seção 5 apresenta-se a proposta FGA de ESW. Na Seção 6, diretrizes de escolha de curso do estudante FGA. Finalizando, as Considerações Finais.

2. Campus – Faculdade UnB Gama - FGA

O Campus de Engenharias da Faculdade UnB Gama (FGA) da Universidade de Brasília (UnB) foi criado no contexto do Programa de Apoio a Planos de Reestruturação e Expansão das Universidades Federais – REUNI, instituído pelo Decreto nº 6.096/2007.

Estima-se para a região Centro-Oeste um grande desenvolvimento do setor das Tecnologias da Informação e Comunicação (TIC) nos próximos anos, o que proporciona sustentabilidade ao curso proposto. A expansão da engenharia e da alta tecnologia na região centro-oeste será potencializada pela atuação sinergética com o setor de software e de engenharias, possibilitando o desenvolvimento de produtos de engenharia integrada altamente inovadores.

A Faculdade UnB Gama oferece 240 vagas semestrais (entrada única) para 4 novos cursos de Graduação: Engenharia de Software, Engenharia de Energia, Engenharia Automotiva e Engenharia Eletrônica. Durante o segundo período letivo, os estudantes da FGA optam por qual das quatro engenharias deseja cursar. A escolha entre um dos cursos é livre.

A formação em nível superior em Engenharia de Software no Brasil encontrava-se implícita nos cursos de Ciência da Computação e Sistemas de Informação. Ela também pode ser obtida em cursos de pós-graduação strictu sensu ou latu sensu oferecidos por instituições brasileiras.

Nos EUA, Canadá, Japão e em alguns países da Europa e da Ásia, a Engenharia de Software é reconhecida como uma atividade científica e tecnológica distinta das demais atividades de computação, com várias ofertas de cursos de graduação em engenharia de software.

Atualmente, no Brasil, cinco universidades públicas federais oferecem cursos de Bacharelado em Engenharia de Software: a Faculdade UnB Gama (FGA), desde o segundo semestre 2008, a Universidade Federal de Goiás (UFG), desde 2009, e as Universidade Federal do Rio Grande do Norte (UFRN), Universidade Federal do Pampa (UNIPAMPA), e Universidade Federal do Ceará (UFC), campus Quixadá, a partir de 2010.

O curso de Engenharia de Software da FGA foi o primeiro no Brasil a ingressar alunos por um vestibular e também foi o primeiro a realizar um vestibular único com demais cursos de engenharias no Brasil. Dentre os cursos de Engenharias de Software existente nas universidades no Brasil e no mundo, o curso de Engenharia de Software da FGA se assemelha aos cursos criados em Departamentos de Engenharias, com uma formação sólida na área de exatas.

A FGA busca contribuir com o Programa de Formação de Capital Humano em ESW [Brasil, 2006], para atuar tanto quantitativamente, aumentando o número de

44


profissionais no mercado, quanto qualitativamente, promovendo a capacitação adequada dos profissionais às demandas do setor.

3. Estrutura Metodológica e Pedagógica

A proposta metodológica e pedagógica adotada na FGA contempla a formação integral do estudante, preocupando-se com sua formação científica e técnica, sua inserção no mercado de trabalho atual e formação ética-cidadã. Isto implica em um currículo organizado em conjuntos: um ciclo básico (tronco comum entre as engenharias), conteúdos profissionalizantes, isto é, um conjunto de disciplinas específicas para formação em cada engenharia, um conjunto de disciplinas optativas de formação complementar que constituem as ênfases, um conjunto de disciplinas de formação livre da Universidade, e estágio obrigatório supervisionado.

Nos currículos de cada engenharia são previstas atividades acadêmicas de formação complementar, as chamadas ênfases. Cada engenharia possui três conjuntos de disciplinas que constituem as ênfases em cada uma das três outras engenharias. São sugestões de seqüências de disciplinas que o estudante pode realizar. Além disso, são previsto conjuntos de disciplinas compondo ênfases específicas da própria engenharia.

Além desses conjuntos de disciplinas e atividades, é definido um mínimo de 210 horas de estágios curriculares obrigatórios. E é determinada a obrigatoriedade de quatro trabalhos de síntese e integração dos conhecimentos adquiridos ao longo do curso de graduação. O projeto de final de curso chamado de Projeto de Graduação 1 e 2 (9º e 10º semestres) e os Projetos Integradores 1 e 2 (4° e 8° semestres), constituídos por estudantes das 4 engenharias, com temas que envolvam as 4 engenharias, que possibilitam ao estudante a participação em projetos e atividades que permitam a síntese dos conceitos e competências adquiridos até o momento, promovendo a multi e interdisciplinaridade.

A formação livre, disciplinas categorizadas como módulo livre (cursadas em outros campi da UnB), constitui de atividades/disciplinas desenvolvidas pelo estudante com base em seus interesses pessoais.

Além das disciplinas curriculares, a carga horária pode ser distribuída em diferentes atividades geradoras de créditos, como: participação em eventos; monitoria; iniciação científica; docência e extensão; estágio não supervisionado; projetos multidisciplinares; visitas técnicas; trabalhos em equipe; participação em empresas juniores; entre outras.

4. Fundamentação do curso de Engenharia de Software

Nesta seção apresentam-se as principais referências que fundamentam a proposta do curso de graduação em engenharia de software.

Em 2004 foram publicadas as diretrizes curriculares para graduação em engenharia de software pela The Joint Task Force IEEE-CS and ACM, o Software Engineering 2004 [SE2004].

O SE2004 apresenta três grandes contribuições: a) um conjunto de resultados esperados e uma declaração sobre o que um graduado em ESW deve saber; b) a especificação dos conhecimentos a serem contemplados em uma graduação em ESW, o Software Engineering Education Knowledge (SEEK), baseado nas áreas de

45


conhecimento previstas no SWEBOK [SWEBOK 2004]; c) um conjunto de recomendações curriculares que descreve como um currículo de ESW, juntamente com o SEEK, pode ser estruturado em vários contextos.

No Brasil, a SBC elaborou e mantém os Currículos de Referências para cursos de graduação em Ciência da Computação, Engenharia de Computação e Sistemas de Informação [SBC 2003]. Os Currículos de Referências SBC concentram-se nos conteúdos a serem oferecidos pelos cursos de graduação na área da computação.

O PARECER CNE/CES Nº. 184/2006 estabelece a carga horária mínima dos cursos de Engenharia em 3.600 horas, envolvendo: Aulas, exercícios, laboratórios, tutoriais, estágio, pesquisa, etc.; Horas de estudo extra-classe não são computadas.

A RESOLUÇÃO CNE/CES Nº. 11, de 11/03/2002 institui diretrizes curriculares nacionais de cursos de graduação em Engenharia. Em linhas gerais, esta resolução define a estrutura do curso de Engenharia como sendo composto por 3 núcleos de conhecimentos, sem qualquer menção a disciplinas, como:

� Núcleo de conteúdos básicos (30% da carga horária mínima). � Núcleo de conteúdos profissionalizantes (15% da carga horária mínima). � Núcleo de conteúdos específicos, representado por extensões e aprofundamentos

dos conteúdos do núcleo de conteúdos profissionalizantes.

Além destes núcleos de conteúdos, esta resolução define a necessidade de um mínimo de 160 horas de estágios curriculares e a realização de um trabalho final de curso, como atividade de síntese e integração de conhecimentos.

5. Curso de Engenharia de Software da FGA

Nesta seção apresenta-se a proposta FGA e o alinhamento das principais diretrizes utilizadas e apresentadas na Seção 4.

Segundo o Software Engineering 2004 [SE2004], a engenharia de software deve ser a integração dos princípios da matemática e ciência da computação com as práticas da engenharia, com objetivo de desenvolver modelos sistemáticos e técnicas confiáveis para a produção de software de alta qualidade.

A estrutura do curso de Engenharia de Software FGA é formada pelos três núcleos de conhecimentos, alinhados a RESOLUÇÃO CNE/CES Nº. 11, de 11/03/2002.

O Quadro 1 apresenta na primeira coluna as áreas de conhecimento básico para as engenharias. A segunda coluna apresenta as disciplinas comuns as engenharias e que a Engenharia de software define como básicas e obrigatórias. A terceira coluna apresenta as disciplinas profissionalizantes da Engenharia de software que também satisfazem, totalmente ou parcialmente, as recomendações da Resolução, como básicas.

Quadro 1. Núcleo de conteúdos básicos (Resolução CNE-CES 11/2002) e a cobertura de ESW

Áreas de Conhecimento - Núcleo Básico CNE

Disciplinas Básicas de ESW que satisfazem as recomendações

Disciplinas Profissionalizantes de ESW que satisfazem as

recomendações

Metodologia Científica e Tecnológica Introdução à Engenharia Produtividade e Profissionalismo em

Engenharia de Software (parcialmente)

Comunicação e Expressão Produtividade e Profissionalismo em

Engenharia de Software (parcialmente)

46


Áreas de Conhecimento - Núcleo Básico CNE

Disciplinas Básicas de ESW que satisfazem as recomendações

Disciplinas Profissionalizantes de ESW que satisfazem as

recomendações

Informática Introdução à Ciência da Computação Orientação a Objetos

Estrutura de Dados e Algoritmos

Expressão Gráfica Desenho Industrial Assistido por

Computador

Matemática

Cálculo 1 Estruturas Matemáticas para Computação

Cálculo 2

Cálculo 3 Introdução à Álgebra Linear

Métodos Numéricos para Engenharia

Probabilidade e Estatística Aplicada à Engenharia

Física Física 1

Física 1 Experimental

Fenômenos de Transporte

Mecânica dos Sólidos

Eletricidade Aplicada

Química Química Geral

Ciência e Tecnologia dos Materiais

Administração Gestão da Produção e Qualidade Gestão de Portfólio e Projetos de Software

Economia Engenharia Econômica Gestão de Portfólio e Projetos de Software

(parcialmente)

Ciências do Ambiente Engenharia e Ambiente

Humanidades, Ciências Sociais e Cidadania

Humanidades e Cidadania Produtividade e Profissionalismo em Engenharia de Software

A definição do Núcleo Profissionalizante segue as diretrizes apresentadas pelo SEEK [SE2004]. O SEEK apresenta 10 áreas de conhecimento, cada qual possui um conjunto detalhado de tópicos de conhecimento. No Quadro 2, a primeira coluna apresenta as áreas de conhecimento do SEEK e seus tópicos e a segunda coluna apresenta as disciplinas do curso de ESW que cobrem os tópicos do SEEK.

Quadro 2. Núcleo Profissionalizante segundo SEEK e a cobertura de ESW

Áreas de Conhecimentos do SEEK Cobertura no Curso de ESW / FGA (básicas e

profissionalizantes)

Fundamentos Matemáticos e de Engenharia

Fundamentos matemáticos Fundamentos de engenharia para software

Engenharia econômica para software

Estruturas Matemáticas para Computação Sistemas Digitais 1

Métodos Numéricos para Engenharia (Tronco Comum) Probabilidade e Estatística Aplicada à Engenharia (Tronco

Comum) Desenho Industrial Assistido por Computador (Tronco comum)

Introdução à Álgebra Linear (Tronco comum) Engenharia Econômica (Tronco comum)

Cálculo 1, 2 e 3 (Tronco comum)

Computação Fundamentos de Ciência da Computação

Tecnologias de Construção Ferramentas de Construção

Métodos Formais de Construção

Introdução à Ciência da Computação (Tronco Comum) Orientação a Objetos

Estrutura de Dados e Algoritmos Sistemas de Banco de Dados

Fundamentos de Sistemas Operacionais Paradigmas de Programação

Técnicas de Programação Avançada Fundamentos de Sistemas Distribuídos

Prática Profissional Psicologia / dinâmicas de grupo

Habilidades de comunicação Profissionalismo

Produtividade e Profissionalismo em Engenharia de Software Humanidades e Cidadania (Tronco Comum)

47


Áreas de Conhecimentos do SEEK Cobertura no Curso de ESW / FGA (básicas e

profissionalizantes) Análise e Modelagem de Software

Fundamentos de modelagem Tipos de modelos

Fundamentos de requisitos Elicitação de requisitos

Documentação e especificação de requisitos Validação de requisitos

Métodos de Desenvolvimento de Software (parcialmente) Sistemas de Banco de Dados

Requisitos de Software

Verificação e Validação de Software Terminologia e fundamentos de Verificação e Validação

Revisões Teste

Avaliação e teste em interface humano computador Registro e análise de problema

Verificação e Validação de Software

Desenho de Software Conceitos de desenho Estratégias de desenho Desenho arquitetural

Desenho de interface humano computador Desenho detalhado

Avaliação e ferramentas de suporte a desenho

Desenho de Software Interação Humano Computador

Desenvolvimento Avançado de Software

Evolução de Software Processos de evolução Atividades de evolução

Manutenção e Evolução de Software

Processo de software Conceitos de processo

Implementação de processo

Processo de Desenvolvimento de Software (parcialmente) Métodos de Desenvolvimento de Software (parcialmente)

Melhoria de Processos de Software Qualidade de Software

Cultura e conceitos de qualidade de software Padrões de qualidade de software

Processos de qualidade de software Garantia do processo Garantia do produto

Gestão da Produção e Qualidade (Tronco comum) Medição e Análise

Desenvolvimento Avançado de Software (parcialmente)

Gestão de Software Conceitos de gestão

Planejamento de projeto Projeto pessoal e organizacional

Controle de projeto Gestão de configuração de software

Gestão de Portfólio e Projetos de Software Gestão da Produção e Qualidade (Tronco comum)

Engenharia Econômica (Tronco comum) Produtividade e Profissionalismo em Engenharia de Software

(parcialmente) Gerência de Configuração de Software

Seguindo as diretrizes da SBC [SBC 2003], as matérias da área de Computação organizadas nos núcleos Fundamentos da Computação e Tecnologia da Computação, foram cobertas pelas áreas de conhecimento do SEEK

Além dos três núcleos, algumas disciplinas possuem característica integradora e de alta multidisciplinaridade. E foram definidas como pertencentes ao Núcleo de Conteúdos Transversais e Interdisciplinares, são elas: Projeto Integrador 1; Projeto Integrador 2; Projeto de Graduação 1; e Projeto de Graduação 2.

O Estudante do curso de Engenharia de Software deverá realizar um estágio supervisionado com carga horária mínima de 210 horas como atividade de síntese e integração de conhecimentos.

Cabe salientar que o curso de Engenharia de Software, por meio das disciplinas optativas de conteúdo específico, permite que o estudante possa optar por seguir uma determinada ênfase, complementando sua formação com conhecimentos científicos, tecnológicos e instrumentais necessários à integração entre os cursos de engenharias do campus UnB-Gama. Seguindo a Resolução UnB, no mínimo 30 % do total de créditos do curso é caracterizado por disciplinas optativas ou disciplinas do módulo livre.

O curso de Engenharia de Software possui uma ênfase para cada uma das outras engenharias oferecidas no campus FGA, de Energia, Eletrônica e Automotiva. Além

48


dessas três ênfases, o curso de Engenharia de Software apresentará propostas de ênfases continuamente, de acordo com a demanda da sociedade, dos corpos discente e docente, e da evolução tecnológica. Por exemplo: uma ênfase em Sistemas Embarcados, Críticos e Seguros (que corresponde as demandas dos cursos de Engenharias Eletrônica, Automotiva e de Energia).

No Quadro 3 apresenta-se a distribuição de créditos nos núcleos, perfazendo um total de 226 créditos, referentes a 3.600 horas, duração de 5 anos.

Quadro 3 – Distribuição dos Créditos do curso de ESW

Núcleos Créditos Porcentagem Básico 62 25.8 %

Profissionalizante 72 30.0 % Optativas

(Módulo Livre) 72

(24 módulo livre) 30.0 %

Transversais e interdisciplinares (Projetos de

Graduação e Integradores) 20 8.3 %

Estágio Obrigatório 210 horas 5.8

Total 226 (3600 horas) 100%

6. Escolha Definitiva do Curso

Ao ingressar na Faculdade UnB Gama, o estudante não opta imediatamente por um dos cursos de engenharia oferecidos na FGA. Em lugar disso, o estudante ingressa em um curso denominado Engenharia, no qual permanecerá por dois períodos letivos completos. Durante o segundo período letivo o estudante deverá solicitar a mudança do curso de Engenharia para a modalidade específica de seu interesse, dentre suas opções na FGA. A escolha entre um dos cursos de graduação oferecidos é livre – o estudante poderá optar por qualquer um dos cursos de graduação oferecidos na FGA.

6.1. Dados de adesão ao curso de Engenharia de Software na FGA

Atualmente a FGA conta com 4 turmas em andamento. A primeira iniciou em agosto de 2008. A escolha pelo curso de engenharia de software na FGA sofreu mudanças bruscas da primeira turma para as demais. De um total de aproximadamente 240 estudantes, se espera que cada engenharia tenha uma média de 60 estudantes, ou 25% para cada Engenharia. A primeira turma, entretanto, demonstrou baixa adesão ao curso de graduação em Engenharia de Software, com uma média de 10% de adesão.

Segundo uma pesquisa realizada na FGA, a baixa adesão ao curso de Engenharia de Software pela primeira turma foi caracterizada pelo desconhecimento, pelos recém ingressos no segundo semestre de 2008, do curso de graduação em Engenharia de Software e sua área de atuação. Uma das estratégias foi caracterizar e divulgar o curso de engenharia de software. Foram proferidas palestras por profissionais que atuam na indústria privada e em órgãos do governo, visitas técnicas, entre outras.


Na proposta metodológica e pedagógica adotada na Graduação em Engenharias o objetivo é fomentar a integração entre discentes e docentes da Faculdade FGA, pela flexibilização e o diálogo entre os 4 cursos de engenharia e demais disciplinas da UnB, possibilitando a multidisciplinaridade e interdisciplinaridade. O estudante é co-

49


responsável pela construção de seu currículo, com uma formação na área de maior interesse.

O jovem engenheiro de software na FGA terá um perfil desenhado para atender demandas relativas ao desenvolvimento de produtos de software de alta qualidade, abrangendo desde a sua concepção até a sua entrega e manutenção, com os princípios da matemática, computação e engenharia.

Para isso, foram considerados como princípios norteadores: a) formação que contemple a fundamentação básica em computação, segundo a sociedade SBC; b) formação que contemple a fundamentação básica em engenharias, adequada ao cenário de computação, segundo a CNE/CES Nº. 11 de 2002; c) formação profissionalizante em engenharia de software, que contemple os princípios básicos da engenharia de software, segundo as associações/sociedades SBC, IEEE-CS e a ACM; d) formação alinhada à demanda do mercado e contribuindo com a inovação; e) formação ética-cidadã; f) flexibilização multidisciplinar e interdisciplinar: diálogo entre os cursos de engenharias da FGA e a verticalização em uma área específica da própria engenharia de software; g) estudante como co-responsável pela construção de seu currículo, com uma formação na sua área de maior interesse.

Enfim, a graduação em Engenharia de Software almeja de forma geral, formar um engenheiro de maneira consistente e contextualizado às atribuições de sua área de atuação e comprometido com a sociedade.

Agradecimentos

Aos professores do grupo de Engenharia de Software da FGA, do Coordenador Geral de Graduação, e da diretoria da FGA. Aos coordenadores e professores dos outros cursos de graduação da FGA, e da comissão formada por professores do Departamento de Ciência da Computação e da Faculdade de Tecnologia da UnB, que elaboraram uma proposta preliminar de PPP do curso de Engenharia de Software.

Referências Brasil (2006) Ministério da Ciência e Tecnologia - MCT. Programa de Formação de

Capital Humano em SOFTWARE – FCHS. Plano de Investimentos (2006-2012). Brasília: MCT, 2005. Disponível em: <http://www.intepp.com.br/intepp/imgsite/artigos/23.pdf>. Acesso em: 26 out. 2008.

Software Engineering (2004) “Software Engineering 2004: Curriculum guidelines for undergraduate degree programs in computer engineering”, a volume of the Computing Curricula Series, copyright ACM and IEEE, published by the IEEE Computer Society, 2006. Disponível em: http://sites.computer.org/ccse/SE2004Volume.pdf. Acesso em: 2 set. 2008

SBC (2003) Sociedade Brasileira de Computação. Currículo de Referência da Sociedade Brasileira de Computação - SBC para Cursos de Graduação em Bacharelado em Ciência da Computação e Engenharia de Computação”. Disponível em: http://www.sbc.org.br. Acesso em: 21 set. 2008.

SWEBOK. (2004) The Guide to the Software Engineering Body of Knowledge. IEEE Computer Society. Disponível em: http://www.swebok.org/. Acesso em: 21 mar. 2008.

50


Graduação em Engenharia de Software versus Graduação em Engenharia de Computação: uma reflexão

Rejane M. da C. Figueiredo, Luiz C. M. Ribeiro Jr, Cristiane S. Ramos, Edna Dias

Canedo

Faculdade UnB Gama (FGA) - Universidade de Brasília (UnB) Caixa Postal 8114 - CEP: 72405-610 – Gama, DF – Brasil

{rejanecosta,lcarlos,cristianesramos}@unb.br [email protected]

Abstract. In 2009, MEC announced the convergence of the names of graduating courses. SBC and ABENGE requested the creation of a committee for discussion, but they received no answer. At the proposed convergence, the graduating course in Software Engineering is called Computer Engineering. On April 2010, MEC presented a proposal at the Andifes meeting, which confirmed that convergence, etc. Due to the refusal of members of Andifes, MEC is committed to wait the final position for the final version. UNB presented an Argumentation Document. This paper describes this argumentation of UnB, which goal is a reflection / discussion about the name of the graduating course of Software Engineering.

Resumo. Em 2009, o MEC anunciou a convergência de nomes dos cursos de graduação. A SBC e a ABENGE solicitaram a criação de uma comissão para discussão, porém não receberam manifestação. Na proposta de convergência, o curso de graduação em Engenharia de Software se chamaria Engenharia de Computação. O MEC em abril de 2010 apresentou uma proposta, na Reunião da Andifes, na qual confirmava essa convergência, entre outras. Dada a recusa dos membros da Andifes, se comprometeu em aguardar posição desta para a versão final. A UNB apresentou um Documento Argumentação. Este artigo descreve a argumentação da UnB, cujo objetivo é uma reflexão/discussão do nome do curso graduação em Engenharia de Software.

1. Contexto

Em junho de 2009, o MEC (Ministério da Educação) anunciou uma mudança de nomes de cursos de engenharia após consulta pública [UOL 2009]. Dos cursos de graduação existentes, muitos têm nomes diferentes para projetos pedagógicos similares, dificultando a avaliação do Sinaes (Sistema Nacional de Avaliação da Educação Superior). O meio acadêmico e a sociedade poderiam propor mudanças e inclusões até o final de julho de 2009, pela internet [Brasil 2009a].

Após a consulta pública, um grupo de especialistas verificaria as propostas e faria as alterações necessárias. A versão final seria disponibilizada para que as instituições começassem a fazer as mudanças nos nomes dos cursos. A revisão das denominações seria feita todo ano.

51


Nas engenharias atualmente constam 258 nomes, e o objetivo é reduzir para 28 nomes [VIDAUNIVERSITÁRIA 2010]. Foi disponibilizado um documento de convergência de denominações [Brasil 2009b]. Na proposta do MEC de uniformização dos nomes, o curso Engenharia de Software se chamaria Engenharia de Computação. No entanto, a essência do curso de engenharia de software é o software e a da engenharia de computação é o hardware. A referência são as diferenciações apresentadas pelas associações americanas e seguidas pelas universidades brasileiras.

Em 2009, a Sociedade Brasileira de Computação (SBC) enviou ao MEC uma Moção [SBC 2009], solicitando a composição de uma comissão mista de representantes da Computação e das Engenharias, para a concepção dos referenciais curriculares da área de Engenharia de Computação e, aproveitando, a elaboração dos referenciais curriculares de cursos de Engenharia de Software, como uma tendência mundial.

Em agosto de 2009, a Diretoria da ABENGE (Associação Brasileira de Ensino de Engenharia), enviou um Manifesto a Secretaria de Educação Superior (SESu) para que as discussões das denominações de cursos de engenharias fossem realizadas no COBEMGE2009 [ABENGE 2009a]. Não tendo recebido nenhuma manifestação, enviou carta ao Ministro da Educação solicitando providências relativas aos Referenciais Nacionais dos Cursos de Engenharia [ABENGE 2009b].

Na 89ª Reunião Ordinária do Conselho Pleno da Associação Nacional dos Dirigentes das Instituições Federais de Ensino Superior (Andifes) [VIDAUNIVERSITÁRIA 2010], o MEC apresentou uma proposta, na qual confirmava a mudança de engenharia de software, entre outras. Contudo, se comprometeu em aguardar posição da Andifes para assinar a versão final. O presidente da Andifes [BARBIERO 2010] encaminhou ofício aos dirigentes para conhecimento, análise e sugestões sobre o documento elaborado pela SESu/MEC “Referenciais Curriculares Nacionais dos Cursos de Bacharelado e Licenciatura” [Brasil 2010]. A UNB apresentou um Documento Argumentação com análise e sugestão de manutenção do nome do curso Engenharia de Software em detrimento da convergência Engenharia de Computação.

Neste contexto, apresentam-se neste trabalho as argumentações/sugestões encaminhadas pela UnB, objetivando uma reflexão/discussão sobre Graduação em Engenharia de Software versus Graduação em Engenharia de Computação.

As seções 2, 3, 4 e 5foram apresentadas no Documento Argumentação UnB. Na Seção 2 apresenta-se o Foco dos Cursos Engenharia de Computação e Engenharia de Software. Na Seção 3, o Programa de formação/capacitação do capital humano em engenharia de software, bem como as Universidades Nacionais que oferecem cursos de Engenharia de Software. Na Seção 4, apresentam-se os itens conforme modelo MEC/SESu com perfil do egresso;; temas abordados na formação; ambientes de atuação; e infraestrutura recomendada. Na Seção 5, as considerações finais.

2. Foco dos Cursos Engenharia de Computação e Engenharia de Software

A crescente demanda da sociedade por software vem requerendo, a cada ano, mais profissionais na área de engenharia de software, que possam contribuir tanto na produção de software de interesse da indústria e organizações nacionais quanto por iniciativas relacionadas a exportação de software, sendo extremamente importante tanto

52


no cenário nacional quanto no internacional a formação de profissionais capacitados para atender esta demanda. É comum no contexto internacional a oferta de graduação em engenharia de software. Contudo, somente a partir de 2008 Instituições Federais Nacionais iniciaram a oferta de cursos de graduação em Engenharia de Software.

As principais sociedades/associações americanas de engenharia e de computação (Computer Society of the Institute for Electrical and Electronic Engineers (IEEE-CS), Association for Computing Machinery (ACM), Association for Information Systems (AIS)) se reuniram e criaram uma força tarefa para examinar os currículos dos cursos existentes e os mapearam (muitos com nomes distintos), classificando-os em 5 grandes áreas: Engenharia de Computação (EC), Ciência da Computação (CC), Sistemas de Informação (SI), Tecnologia da Informação (TI) e Engenharia de Software (ES) [Computing Curricula 2005].

No Brasil, a Sociedade Brasileira de Computação (SBC) elaborou e mantém os Currículos de Referência para cursos de graduação em Ciência da Computação, Engenharia de Computação e Sistemas de Informação [SBC 2003]. Os currículos são adotados como referência pelas instituições brasileiras de ensino superior e referendados pelo Ministério da Educação (MEC). No entanto, para o curso de graduação em Engenharia de Software a SBC ainda não criou um currículo de referência.

A partir dos currículos propostos pelas associações IEEE/ACM/AIS, apresenta-se o foco dos dois cursos em questão [Software Engineering 2004)], [Computing Curricula 2005]. O Computing Curricula [2005] define que :

“ 1. Engenharia de Computação

A Engenharia de Computação se preocupa com o projeto e a construção de computadores e sistemas baseados em computadores. Envolve o estudo do hardware, software, comunicações e a interação entre eles. O currículo se concentra nas teorias, princípios e práticas da engenharia elétrica tradicional e da matemática e os aplicam nos projetos de computadores e de dispositivos baseados em computadores. Os estudantes de Engenharia de Computação estudam o projeto de sistemas de hardware digitais incluindo sistemas de comunicação, computadores, e dispositivos que contêm computadores. Eles estudam o desenvolvimento de software, concentrando-se em software para dispositivos digitais e suas interfaces com usuários e com outros dispositivos...

...A porção sombreada na Figura 1 representa a disciplina de engenharia de computação. Ela é larga no fundo porque a engenharia de computação cobre desde a teoria e os princípios como as aplicações práticas do projeto e implementação de produtos que usam hardware e software. Ela se estreita perto do centro na medida em que se move para cima porque os interesses do engenheiro de computação se estreitam na medida em que se afasta do hardware. Quando se chega no nível de desenvolvimento de software, observa-se que o interesse do engenheiro de computação se estreita para o centro no sentido horizontal porque eles se importam com software somente enquanto precisam dele no desenvolvimento de dispositivos integrados.”

53


Figura 1. Engenharia de Computação [Computing Curricula 2005]

E o Computing Curricula [2005] define que :

“2. Engenharia de Software

A Engenharia de Software (ES) é a disciplina do desenvolvimento e manutenção de sistemas de software que se comportam confiável e eficientemente, são econômicos de desenvolver e manter, e satisfazem todos os requisitos que os usuários definiram para eles. Mais recentemente, a ES evoluiu em resposta a fatores tais como o impacto crescente de grandes e custosos sistemas de software sobre uma gama bastante grande de situações e a grande importância de software em aplicações críticas. A ES tem um caráter diferente das outras engenharias devido tanto à natureza intangível do software quanto à natureza descontínua de sua operação. Ela busca integrar os princípios da matemática e da ciência da computação com as práticas da engenharia desenvolvidas para artefatos físicos tangíveis...

Figura 2. Engenharia de Software [Computing Curricula 2005]

... A porção sombreada na Figura 2 representa a disciplina de engenharia de software. Assim como a área correspondente à engenharia de computação se estende por toda a dimensão horizontal no nível mais baixo que é relacionado ao hardware, a engenharia de software cobre um espectro bastante amplo com respeito ao desenvolvimento sistemático de software. Isto é porque o profissional de ES preenche um espectro amplo de necessidades de competência em grandes projetos de software. O principal objetivo da ES é desenvolver modelos sistemáticos e técnicas confiáveis para a produção de software de alta qualidade dentro do prazo e do orçamento pre-estabelecidos, e estas preocupações se estendem desde a teoria e princípios até à prática diária. O domínio da ES também se estende para baixo cobrindo infraestrutura de sistemas, pois o profissional de ES desenvolve infraestrutura de software que é robusta operacionalmente. O seu

54


domínio também se estende para cima, para as questões organizacionais porque o profissional de ES se interessa em projetar e desenvolver sistemas de informação que sejam apropriados para a organização do cliente.”

3. Programa de Formação do Capital Humano em Software

Em agosto de 2005, o Governo brasileiro realizou uma análise do capital humano em desenvolvimento de software no Brasil, com um dimensionamento atual da escassez e uma projeção para os próximos sete anos (2006-2012) [BRASIL 2006].

Foi constatado que em 2005 existiam 17 mil vagas de trabalho não preenchidas na indústria nacional de software. As projeções do Governo apontam que, mantendo as condições atuais da formação de profissionais da área, faltarão 213 mil engenheiros de software para suprir a demanda das empresas. Há a necessidade urgente de um significativo aumento qualitativo e quantitativo de profissionais no setor, com uma ação por parte do Governo Federal em parceria com diversos atores dos setores públicos e privados.

A partir da questão: O Brasil está formando profissionais em Tecnologia da Informação com capacitação adequada ao mercado de trabalho? As seguintes medidas foram tomadas: (i) realização de levantamentos do estado atual dos cursos existentes nos diferentes níveis de formação, nível técnico (cursos técnicos) e superior (cursos tecnológicos, graduação, mestrado e doutorado). (ii) identificação das ações a serem executadas para formação de capital humano na área de Engenharia de Software, entre elas a criação de cursos de graduação em Engenharia de Software.

3.1 Universidades Nacionais

Atualmente as universidades nacionais que possuem cursos de bacharelado em

Engenharia de Software são: 1. Universidade Federal de Brasília (início 2º semestre de 2008)

http://www.fga.unb.br/unbgama/ 2. Universidade Federal de Goiás (início 1º semestre de 2009)

http://www.inf.ufg.br/?menu_id=1224609284&pos=esq&site_id=1 3. Universidade Federal do Rio Grande do Norte (início 1º semestre de 2010)

http://www.ufrn.br/mostradeprofissoes/cursos/engsoftware.pdf 4. Universidade Federal do Pampa (início 1º semestre de 2010)

http://porteiras.unipampa.edu.br/alegrete/graduacao/248 5. Universidade Federal do Ceará (UFC), Campus Quixadá (2010)

http://www.es.ufc.br/

4. Itens do Formulário MEC/SESu

No documento disponibilizado pelo MEC, as sugestões de mudança deveriam conter os itens: Perfil do Egresso; Temas abordados na Formação; Ambientes de Atuação; e Infraestrutura Recomendada.

Nas subseções seguintes, apresentam-se os itens do curso de Graduação em Engenharia de Software encaminhado pela UnB à demanda do MEC. O Perfil do Egresso é baseado em Lucena, Oliveira and Vincenzi (2008), os demais nas diretrizes do Software Engineering (2004) e Computing Curricula (2005).

55


4.1 Perfil do Egresso

O Bacharel em Engenharia de Software ou Engenheiro de Software atua na definição, construção e manutenção de software, e nos seus respectivos processos: gestão do projeto de software, definição e melhoria do processo de software. Em suas atividades técnicas: elicita, analisa, modela, especifica (documenta), valida e gerencia requisitos de software; projeta (design) software (arquitetura e projeto detalhado), incluindo modelagem, análise e avaliação da qualidade, princípios, estilos, métodos, modelos arquiteturais e padrões de projeto; constrói (programa) software com qualidade, só e em equipe, incluindo métodos, técnicas, tecnologias e ferramentas; realiza atividades de manutenção de software; planeja e executa atividades pertinentes à qualidade de software, incluindo verificação, validação, revisões, inspeções e testes. Em suas atividades gerenciais: gerencia projetos de software, incluindo estimativa de recursos, planejamento e monitoramento de projetos de desenvolvimento e manutenção de software, análise de riscos; Coordena e supervisiona equipes de trabalho define e gerencia processos de software e programas de melhoria contínua dos processos de software, incluindo auditorias e avaliações de qualidade de produto e processos de software; cria e adapta processos e técnicas de desenvolvimento de software. Realiza pesquisa científica e tecnológica e estudos de viabilidade técnico-econômica; executa e fiscaliza projetos e serviços técnicos; efetua vistorias, perícias e avaliações; Projeta soluções de software para problemas de áreas como automação, medicina, biologia, robótica, música, educação, empresarial, governo, financeira e construção civil, entre outras. Em suas atuações, considera a ética, a segurança e os impactos sócio-ambientais.

4.2 Temas Abordados na Formação

Fundamentos de computação: que apóiam o projeto e construção de produtos de software; Fundamentos de engenharia e matemática: de funções a estruturas algébricas, de métodos empíricos e técnicas experimentais a engenharia econômica. Modelagem e análise de software: de fundamentos de modelagem a elicitação, análise, especificação e validação de requisitos. Projeto de software: de conceitos a arquitetura, interface humano-computador, projeto detalhado, ferramentas e avaliação. Verificação e validação de software: de fundamentos a revisões, testes, análise e reporte de problemas. Evolução/manutenção: de processos a atividades de evolução/manutenção de software. Processos de software: de conceitos a implementação. Qualidade de software: de conceitos e cultura a padrões, processos e garantias de produto e processo de software. Gerenciamento de Software: de conceitos de gerenciamento, planejamento, organização, e controle de projeto a gerenciamento da configuração do software. Práticas profissionais: de dinâmica de grupo, psicologia a competências conversacionais e profissionalismo.

4.3 Ambientes de Atuação

O Engenheiro de Software atua em indústrias de desenvolvimento e manutenção de software; indústrias de computadores e aparelhos eletrônicos; setores de Tecnologia da Informação de instituições públicas e privadas; em empresas e laboratórios de pesquisa científica e tecnológica, ambientes colaborativos de desenvolvimento de software,

56


dispersos geograficamente. Também pode atuar de forma autônoma, em empresa própria ou serviços de consultoria.

4.4 Infraestrutura Recomendada

Laboratórios de: Programação; Arquitetura de Computadores e Periféricos; Redes de Computadores; Dispositivos Lógicos Programáveis; Ambientes de Engenharia de Software: ferramentas de apoio ao desenvolvimento de software - geradores de código, ferramentas CASE, sistemas gerenciadores de banco de dados, compiladores, ambientes de desenvolvimento (IDE), ferramentas de comunicação; e Biblioteca com acervo específico e atualizado.


Com base no contexto e nas características específicas das matrizes curriculares dos cursos de Bacharelado em Engenharia de Software no Brasil, e em outros países, pode-se concluir que o curso de Bacharelado em Engenharia de Software possui alguma interface com o curso de Bacharelado em Engenharia de Computação ao considerar que ambos trabalham com a Tecnologia da Informação.

Porém, a Engenharia de computação é direcionada ao desenvolvimento de ferramentas híbridas (hardware e software) visando especialmente as áreas de controle e automação, enquanto que a Engenharia de Software é voltada para a especificação, desenvolvimento e manutenção de sistemas de software, com aplicação de abordagens estruturadas compostas de processos, procedimentos, técnicas e ferramentas e práticas de gestão de projetos, cujos objetivos principais são a organização, a produtividade e a qualidade.

Na visão deste grupo, o nome Engenharia de Computação não é adequado ao curso proposto, devido às diferenças conceituais e estruturais apresentadas nesta reflexão. O maior desafio é que as comunidades de computação e engenharia possam, em conjunto, definir diretrizes curriculares que diferenciem claramente os dois cursos e proporcionem segurança aos futuros egressos dos cursos já criados e os possíveis cursos em criação pelas universidades brasileiras.

Referências

ABENGE 2009a. Associação Brasileira de Ensino de Engenharia. Referenciais Nacionais dos Cursos de Engenharia. Manifesto SESu 30 de agosto. http://www.abenge.org.br/index.php?option=com_content&task=view&id=52&Itemid=1. Acesso em: 10 out. 2009

ABENGE 2009b. Associação Brasileira de Ensino de Engenharia. Ofício 035/2009 ao MEC. http://www.abenge.org.br/dmdocuments/REFERENCIAIS%20MEC.pdf. Acesso em: 20 nov.. 2009

BARBIERO, A (2010). ANDIFES – Associação Nacional dos Dirigentes das Instituições Federais de Ensino Superior. OF.CIRC-SE / Andifes nº 064/2010 Brasília, 23 de abril de 2010

Brasil (2006) Ministério da Ciência e Tecnologia - MCT. Programa de Formação de Capital Humano em SOFTWARE – FCHS. Plano de Investimentos (2006-2012).

57


Brasília: MCT, 2005. Disponível em: <http://www.intepp.com.br/intepp/imgsite/artigos/23.pdf>. Acesso em: 26 out. 2008.

Brasil (2009a). MINISTÉRIO DA EDUCAÇÃO – MEC. Secretaria de Educação Superior – SESu. Projeto: Referenciais Nacionais de Graduação – Engenharias. Formulário de Avaliação. http://portal.mec.gov.br/dmdocuments/formulario_avaliacao.doc. Acesso em: 15 out. 2009.

Brasil (2009b). MINISTÉRIO DA EDUCAÇÃO – MEC. Secretaria de Educação Superior – SESu. Construção dos Referencias Nacionais dos Cursos de Graduação – Bacharelados e Licenciaturas Engenharias. Convergência de Denominação. http://portal.mec.gov.br/dmdocuments/convergencia_denominacao.pdf. Acesso em: 15 de out. De 2009.

Brasil (2010). MINISTÉRIO DA EDUCAÇÃO – MEC. Secretaria de Educação Superior – SESu. Referenciais Curiculares Nacionais dos Cursos de Bacharelado e Licenciatura. 99 p. Março de 2010.

Computing Curricula 2005: The Overview Report, a volume of the Computing Curricula series produced by the Joint Task Force for Computing Curricula 2005, copyright ACM and IEEE, published by the Association for Computing Machinery, 2006. Series. Disponível em: http://www.computer.org/portal/cms_docs_ieeecs/ieeecs/education/cc2001/CC2005-March06Final.pdf. Acesso em: 3 out. 2006.

Lucena, F. N., Oliveira, J. and Vincenzi, A.M.R. 2008. “Bacharelado em Engenharia de Software na Universidade Federal de Goiás, Fórum de Educação em Engenharia de Software (Simpósio Brasileiro de Engenharia de Software)”, Monografias em Ciência da Computação, número 43/08, páginas 16-21, Campinas/SP, 17/10/2008, ISSN 0103-9741.

SBC (2003) Sociedade Brasileira de Computação. Currículo de Referência da Sociedade Brasileira de Computação - SBC para Cursos de Graduação em Bacharelado em Ciência da Computação e Engenharia de Computação”. Disponível em: http://www.sbc.org.br. Acesso em: 21 set. 2008.

SBC (2009) Sociedade Brasileira de Computação. Moção Referenciais Curriculares dos Cursos de Engenharia de Software. Sociedade Brasileira de Computação – SBC. Disponível em: http://www.sbc.org.br/index.php?language=1&subject=28. Acesso em: 26 mai. 2010.

Software Engineering 2004: Curriculum guidelines for undergraduate degree programs in computer engineering, a volume of the Computing Curricula Series, copyright ACM and IEEE, published by the IEEE Computer Society, 2006. Disponível em: http://sites.computer.org/ccse/SE2004Volume.pdf Acesso em: 2 set. 2008

UOL (2009). MEC decide mudar nomes de cursos de engenharia. 29/06/2009. http://educacao.uol.com.br/ultnot/2009/06/29/ult105u8318.jhtm. Acesso em: 27 abr. 2010.

VIDAUNIVERSITÁRIA (2010). MEC quer padronizar nome de cursos. 16/04/2010. http://www.vidauniversitaria.com.br/blog/?p=57723. Acesso em: 27 abr. 2010.

58


O Curso de Engenharia de Software da UFRN David Deharbe, Eduardo Aranha, Jair Leite

Marcel Oliveira, Paulo Pires, Uirá Kulesza, Umberto Costa

Departamento de Informática e Matemática Aplicada– Universidade Federal do Rio Grande do Norte (UFRN)

Av. Se. Salgado Filho, 3000 – 59078-970 – Natal – RN – Brazil {david, jair, eduardo, marcel, uira, umberto }@dimap.ufrn.br

Resumo. A crescente demanda da sociedade por software vem requerendo, a cada ano, mais profissionais na área de engenharia de software, que possam contribuir tanto na produção de software de interesse da indústria e organizações nacionais quanto por iniciativas relacionadas à exportação de software. Este artigo descreve o curso de graduação em Engenharia de Software da Universidade Federal do Rio Grande do Norte, implantado em 2010 apresentando seus objetivos, motivações, perfil do profissional e a estrutura do curso com o objetivo de motivar discussões no âmbito da comunidade cientifica e profissional da computação no Brasil dando um passo para a implantação de referenciais para as diversas instituições do país.

1. Introdução Ao longo dos últimos anos, a sociedade passou a usar e depender cada vez mais dos serviços oferecidos por uma variedade de sistemas de software. Atualmente, diferentes atividades da vida cotidiana e do dia-a-dia de organizações privadas e públicas são amplamente apoiadas e mediadas por tais sistemas. A presença inerente dos softwares na vida em sociedade é visível nos diferentes dispositivos de uso pessoal (celulares, televisão, dispositivos de áudio), até diferentes sistemas de informação que apóiam a busca, disponibilização e uso de informação seja na Internet ou numa organização específica.

O desenvolvimento e manutenção de tais softwares demandam profissionais cada vez mais qualificados, capazes de entender todo o processo de sua produção e de atuar explicitamente na definição e melhoria de tal processo. Tal definição envolve uma série de decisões importantes, tais como: (i) a escolha de técnicas e ferramentas adequadas para cada uma das fases (análise e especificação de requisitos, projeto da arquitetura do software, codificação, testes e manutenção) envolvidas no processo de desenvolvimento; (ii) o planejamento e gestão dos recursos humanos e físicos disponíveis; e (iii) o treinamento das pessoas participantes do processo para execução. Tudo isso deve ser feito considerando não apenas a natureza e complexidade do software, mas também a cultura de desenvolvimento e nível de conhecimento tecnológico da equipe responsável pelo seu desenvolvimento.

O curso de Ciência da Computação veio ao longo dos últimos 40 anos aproximadamente assumindo o papel da formação dos profissionais de TI. No entanto, o aumento da diversidade tecnológica e da complexidade dos sistemas de software

59


requerem uma formação diferenciada onde os conhecimentos científicos da computação possam ser aplicados através de princípios, métodos e técnicas de engenharia. Aspectos gerenciais e econômicos são também fatores fundamentais para o exercício profissional da construção de software com qualidade.

A engenharia de software é a área da computação responsável pelo estabelecimento de técnicas e práticas para a realização das atividades acima. Ela é uma disciplina de engenharia que investiga todos os aspectos relacionados à produção de software. A engenharia de software propõe métodos sistemáticos com o uso adequado de ferramentas e técnicas, que levam em consideração o problema sendo resolvido, as restrições inerentes a tal desenvolvimento, bem como os recursos disponíveis [Sommerville, 2007].

Este artigo visa apresentar o curso de engenharia de software da UFRN, apresentando seus objetivos, motivações, perfil do profissional e a estrutura do curso. Nosso objetivo é motivar discussões no âmbito da comunidade cientifica e profissional da computação no Brasil dando um passo para a implantação de referenciais para as diversas instituições do país.

Este artigo está organizado da seguinte forma. Na seção 2 são apresentadas as motivações e justificativas para a criação do curso de bacharelado em Engenharia de Software da UFRN, proposto neste documento. As justificativas são apresentadas sobre duas diferentes perspectivas: (i) alta demanda de profissionais com o perfil de bacharel em engenharia de software no cenário nacional; e (ii) necessidade de criação de bacharelados com formação específica em engenharia de software, em contraposição a cursos existentes, respaldada por diferentes iniciativas da comunidade profissional e científica nacional e internacional.

2. Crescente Demanda por Profissionais em Engenharia de Software Estudos recentes têm mostrado que tanto a indústria nacional quanto internacional de desenvolvimento de software irá demandar uma grande quantidade de profissionais atuando na área de engenharia de software nos próximos anos. De acordo com estudos do governo [Brasscomm, 2009], por exemplo, a indústria nacional terá que formar 100 mil novos profissionais na área de desenvolvimento de software, para exportar US$ 5 bilhões em software até 2010. Dados do International Data Group (IDC) [IDC Brasil, 2009] mostram a ampliação dos negócios em tecnologia da informação a cada ano. De 2006 para 2007, por exemplo, o mercado mundial cresceu na ordem de 3,1%, enquanto o mercado nacional avançou 8,3%. A expectativa é que a área de software e serviços continue crescendo da ordem de 10% ao ano até 2012.

Diante de tal demanda e de forma estratégica para o país, os principais órgãos nacionais de fomento ao desenvolvimento científico e tecnológico ligados ao governo federal [CNPq, FINEP, Softex] têm proposto e estimulado editais específicos voltados exclusivamente para a área de engenharia de software. O CNPq, por exemplo, vem propondo editais que oferecem financiamento para a criação de projetos/programas de parcerias entre universidade e empresas que recebam profissionais recém-egressos da universidade visando ampliar sua formação em engenharia de software, através de um programa de residência, inspirado nos já tradicionais programas da medicina. A FINEP tem também criado e estimulado, em seus diversos editais, a submissão de projetos de inovação científica e tecnológica na área de desenvolvimento de software e tecnologia

60


da informação, por entender, a importância estratégica da área para a economia nacional.

No contexto regional, a UFRN está diretamente envolvida na criação e execução das atividades ligadas ao projeto Metrópole Digital, em parceria com o governo federal, empresas regionais e organizações da sociedade civil. O objetivo principal de tal projeto é qualificar mão-de-obra para área de Tecnologia da Informação (TI), através da capacitação de jovens, identificados através de metodologia específica, como potencialmente capazes de desenvolver o talento em TI para reduzir a carência de profissionais no mercado. Na medida em que este projeto integra uma ação de formação tecnológica com o campo da pesquisa e desenvolvimento científico, tecnológico e inovação em software e hardware, desdobra a possibilidade de formação superior de parte dos jovens talentos em cursos de graduação e pós-graduação da UFRN.

Diante deste cenário nacional e regional, o curso de Bacharelado em Engenharia de Software busca ampliar a capacidade da UFRN de formação de profissionais altamente qualificados na área de engenharia de software, com o objetivo de atender a demanda nacional crescente por profissionais na área. Além disso, o curso irá também contribuir para apoiar e estimular a geração de novos empreendimentos de tecnologia da informação, em colaboração com os diferentes centros e departamentos da UFRN, a serem realizadas no contexto do projeto Metrópole Digital.

3. Diferenciando a formação em Engenharia de Software com outras da Computação As principais sociedades de computação no mundo (a Association for Computing Machiney – ACM, a Association for Information Systems – AIS, e a Computer Society do Institute for Electrical-Electronic Engineering – IEEE-CS) uniram forças e concluíram em 2005 um trabalho que apresenta um currículo de referência para a área de computação [ACM/AIS/IEEE-CS, 2005]. Nesta proposta, estas sociedades propõem cinco possíveis cursos de graduação para a área da computação, apresentando suas diferenças, perfis dos formandos, competências e habilidades. Esta proposta é resultado de uma análise que considerou que as propostas anteriores não atendiam às demandas do mercado de trabalho da atualidade. De acordo com a força-tarefa da ACM, AIS e IEEE-CS, os cursos de graduação em computação podem ser: Engenharia de Computação, Ciência da Computação, Sistemas de Informação, Tecnologia da Informação e Engenharia de Software.

As diretrizes curriculares da área de computação [MEC-SESU, 2001], ainda não oficialmente aprovadas, contemplam apenas as três primeiras opções. Estas diretrizes foram resultados de um esforço da Sociedade Brasileira de Computação (SBC) durante alguns anos. Atualmente, a SBC está iniciando uma discussão sobre as novas possibilidades de cursos de graduação e a sua inclusão nos referenciais curriculares da Secretaria de Educação Superior do Ministério da Educação.

A Engenharia de Software é fundamentada sobretudo na ciência da computação e na matemática [Software Engineering Curriculum ACM/IEEE, 2004]. Ao longo dos últimos anos, a área de engenharia de software e suas diferentes disciplinas têm amadurecido bastante, através da proposição de novos métodos e técnicas que possibilitam o desenvolvimento de softwares mais confiáveis, de melhor qualidade, com custo reduzido e alta produtividade. Buscando atingir tais objetivos, a formação do

61


profissional de tal área exige não apenas um amplo domínio de técnicas de programação modernas e avançadas, mas também o conhecimento e domínio das diferentes disciplinas que compõem o processo de desenvolvimento de software. A IEEE Computer Society apresenta, em seu guia de corpo de conhecimento na área de engenharia de software [SWEBOK, 2004], as principais disciplinas que compõem a área, sendo elas: requisitos, projeto, construção, testes, manutenção de software, gerência de configuração, gestão de projetos, processos de desenvolvimento, ferramentas e métricas de engenharia de software, e qualidade de software. Cada uma destas disciplinas requer o aprendizado de técnicas e ferramentas específicas. A diferença de formação de profissionais nas diferentes carreiras em computação [ACM Carreers, 2009] é também destacada pela Association for Computing Machinery (ACM), a qual já reconhece explicitamente a área de engenharia de software como uma carreira na área de computação, e destaca as diferenças e necessidades de formação de profissionais em comparação com outras carreiras, tais como, ciência da computação e engenharia da computação.

De fato, a IEEE Computer Society e a Association for Computing Machinery (ACM), as duas principais organizações ligadas aos profissionais e cientistas da computação, têm recentemente reconhecido a importância crescente da área de engenharia de software, e a necessidade de oferta de cursos de graduação específicos para tal área. Juntas, elas propuseram diretrizes para um currículo específico na área de Engenharia de Software [ACM/IEEE, 2004]. O projeto pedagógico do curso de Bacharelado em Engenharia de Software [UFRN, 2009] apresentado neste documento segue tais diretrizes, oferecendo formação sólida tanto na área de programação avançada de sistemas (programação orientado a objetos, distribuída e concorrente) como também nas diferentes disciplinas que compõem o currículo em Engenharia de Software.

Assim, já é amplamente reconhecido que a formação de profissionais na área de Engenharia de Software é bastante distinta dos outros cursos de computação, e que são atualmente oferecidos pela UFRN e outras instituições federais. As próprias diretrizes para criação de cursos em Engenharia de Software da ACM/IEEE [ACM/IEEE, 2004] atentam para tal fato. A formação em engenharia de software requer o estudo de métodos, técnicas e ferramentas voltadas especificamente para o desenvolvimento de diferentes tipos de sistemas de software com qualidade e produtividade, e que, portanto, necessitam cobrir com profundidade as diferentes disciplinas envolvidas na área.

A formação de profissionais em engenharia de software se distingue também claramente da formação dos tradicionais e já consolidados cursos em Engenharia. Enquanto as engenharias tradicionais se fundamentam nas ciências naturais e na matemática contínua, e buscam a produção de artefatos físicos/concretos, a engenharia de software é fundamentada na ciência da computação e na matemática discreta, e focaliza a produção de software centrado em entidades abstratas/lógicas. Tais distinções nas áreas que permeiam a sua fundamentação, e no tipo e natureza dos artefatos que são construídos, são suficientes para delinear diferenças claras e explícitas na organização de seus currículos, as quais são ressaltadas pelas diretrizes da ACM/IEEE [ACM/IEEE, 2004].

62


4. Perfil, Competências e Habilidades A criação de cursos de graduação em Engenharia de Software é um fenômeno recente em nível mundial, e muito recente em nível nacional. A indústria de software sofre constante evoluções tecnológicas, e o egresso do curso deve não somente estar a par das tecnologias existentes, mas também possuir o embasamento teórico suficiente para poder acompanhar as futuras e inevitáveis evoluções tecnológicas. Pelas mesmas razões, a proposta pedagógica do curso deve sempre manter-se preocupada em oferecer uma flexibilidade suficiente para manter-se atualizada frente às necessidades mercadológicas, mas sem deixar de fornecer um núcleo sólido de ensinamentos fundamentais específicos para a área de desenvolvimento de software.

Tanto para atender às características propostas pela nova LDB e, principalmente, às da área de computação, como para propor um curso em sintonia com essa recente tendência mundial, não se pode pensar somente na estrutura curricular. É preciso mudar métodos de ensino/aprendizado e dar ênfase à formação em fundamentos científicos básicos e ao desenvolvimento de competências e habilidades para utilizar tecnologias atuais. Para dar flexibilidade na formação dos alunos do curso, o elenco de disciplinas ou atividades de formação optativas permite ao estudante acompanhar a evolução da área de computação.

O curso utiliza métodos de ensino que estimulem empreendedorismo, envolvimento em projetos de desenvolvimento de software, apresentação de seminários, elaboração de produtos de software. O aluno precisa desenvolver a capacidade de análise, abstração, elaboração de projetos, especificação, e avaliação nas diversas áreas da engenharia de software. A formação em tecnologia deve ser obtida estimulando o aluno a desenvolver a capacidade de investigação.

Uma das características mais marcantes da área de Engenharia de Software é a valorização da criatividade como ferramenta de uso no dia-a-dia do profissional. Uma conseqüência disto é a necessidade do curso incentivar a procura de soluções criativas na resolução dos problemas apresentados ao aluno. A proposta do curso do bacharelado em Engenharia de Software da UFRN incentiva a utilização de outros métodos pedagógicos, além das aulas expositivas, já que o aluno não precisa apenas decorar conteúdos que o professor passa nessas aulas. Para o aluno devem ser apresentados problemas cuja solução não se encontra diretamente na bibliografia, pois ele deve ser incentivado a combinar as técnicas, teorias e ferramentas apresentadas no curso, visando elaborar novas soluções para os problemas a ele apresentados. A presente proposta visa criar as condições de motivação de alunos e professores, de forma a evitar que a única meta do aluno seja ser aprovado em provas.

O aluno do Bacharelado em Engenharia de Software deve interessar-se pela computação e, em particular, pela produção de software. O aluno deve ser um entusiasta pela obtenção e domínio de novos assuntos, além de ser capaz de, baseado neles, construir sua própria reputação por meio dos produtos do seu esforço próprio ou resultantes de trabalho em equipe do qual participa sem necessariamente estar sob supervisão.

O egresso do Curso de Bacharelado em Engenharia de Software, para ter sucesso profissional, deve desenvolver a capacidade de expressão escrita e oral nos idiomas português e inglês. Isto não deve ser desvinculado da sua área profissional. A

63


experiência mostra-nos que para atingir este objetivo não é suficiente apenas a oferta de disciplinas "externas" como comunicação e expressão, língua inglesa e metodologia científica no currículo. É preciso oferecer alternativas que propiciem o desenvolvimento da capacidade de expressão escrita e oral dos alunos no decorrer do curso. Cada professor pode e deve cobrar esta capacidade dos alunos. O aprendizado de comunicação e expressão pode ser feito estimulando a participação dos alunos em seminários. O aprendizado de inglês pode ser aprimorado lendo e escrevendo textos para cada disciplina de informática, e o aprendizado de métodos para desenvolvimento de trabalhos científicos pode ser orientado a partir da experiência de cada professor.

O Bacharel em Engenharia de Software será capaz de efetivamente contribuir com equipes na produção de modelos abstratos correspondentes a software e realizá-los por meio de código que poderão ser executados em contexto real. Da perspectiva pessoal o egresso deve ser capaz de trabalhar de forma harmoniosa e ética, e efetiva-mente auxiliar na elaboração de produtos de software.

Alem disso, eles devem possuir as competências e habilidades listadas a seguir: 1.Mostrar domínio sobre o conhecimento e as habilidades da Engenharia de

Software, e as habilidades profissionais necessárias para iniciar a prática como um Bacharel em Engenharia de Software.

2.Trabalhar individualmente e como parte de uma equipe para desenvolver e entregar produtos de software de qualidade.

3. Reconciliar os objetivos conflitantes do projeto, encontrando acordos aceitáveis dentro das limitações do custo, tempo, conhecimento, sistemas existentes, e organizações.

4. Projetar soluções apropriadas em um ou vários domínios de aplicação, usando abordagens de engenharia de software que integram interesses éticos, sociais, legais, e econômicos.

5. Demonstrar compreensão e capacidade de aplicação de teorias, modelos, e as técnicas atuais que fornecem uma base para a identificação e a análise de problemas, o projeto de software, o desenvolvimento, a execução, a verificação, e sua documentação.

6. Demonstrar entendimento e compreensão da importância da negociação, de hábitos eficazes de trabalho, de liderança, e de uma boa comunicação com as partes interessadas em um ambiente típico da programação de software.

7. Aprender novos modelos, técnicas, e tecnologias que venham a emergir e entender a necessidade de um desenvolvimento profissional continuado.

A Tabela 1 especifica como estes procedimentos metodológicos se relacionam com o desenvolvimento de habilidades específicas.

64


Tabela 1: procedimentos metodológicos e habilidades desenvolvidas. Procedimentos metodológicos Habilidade a ser desenvolvida

Estudo orientado - pesquisa e monografia sobre conteúdos avançados

Auto-aprendizado, pesquisa, comunicação escrita, domínio da língua inglesa

Desenvolvimento de produtos Capacidade empreendedora, planejamento, trabalho em grupo, prática profissional, criatividade

Apresentação de seminários Comunicação oral, pesquisa

Realização de estágios Trabalho em grupo, prática profissional

Disciplinas expositivas com instrutor presencial

Concentração e atenção

Aulas em vídeo e/ou documentários Concentração e atenção

Grupos de estudo (leitura e discussão em grupo)

Reflexão, avaliação crítica

Participação em cursos e congressos Socialização, vivência de atividades profissionais.

Aplicações sociais e comunitárias (atividades de extensão)

Trabalho em grupo, prática profissional, socialização, análise de problemas e modelagem de soluções

Projeto de formação Prática profissional, trabalho em grupo, capacidade empreendedora, planejamento, criatividade.

5. Estrutura do Curso O currículo do curso de Bacharelado em Engenharia de Software da UFRN define 8 (oito) períodos letivos como sendo a duração ideal do curso, sendo 12 (dez) períodos letivos a sua duração máxima. Para conclusão do curso, o aluno deve integralizar : • 3.275 (três mil, duzentos e setenta e cinco) horas, sendo • 2.235 (duas mil, duzentas e trinta e cinco) horas de disciplinas obrigatórias; • 560 (quinhentos e sessenta) horas de atividades complementares; • 480 (quatrocentas e oitenta) horas de disciplinas optativas, sendo pelo menos 180

horas de disciplinas do grupo de formação avançada em engenharia de software , e 300 horas de outras disciplinas optativas.

A carga total mínima em disciplinas é de 12 créditos por período letivo, enquanto que a carga total máxima em disciplinas é de 30 créditos por período letivo, de forma a racionalizar a demanda por matrículas em turmas por parte dos discentes. O limite superior tem por objetivo inibir a demanda exagerada por matrículas em disciplinas e seus efeitos negativos tanto para o aluno, quanto para o professor e o curso.

O corpo de disciplinas disponíveis no presente projeto visa uma formação de qualidade na área de Engenharia de Software, a qual é complementada com disciplinas optativas de outras áreas. Para obter esse tipo de formação, o presente projeto prevê que

65


o aluno possa matricular-se, além das disciplinas obrigatórias do curso, em disciplinas avançadas ministradas por professores do DIMAp e de departamentos de áreas correlatas, assim como em disciplinas de cunho mais básico, ministrada por professores de outros departamentos da UFRN.

6. Conclusão O bacharelado em Engenharia de Software da UFRN visa atender a demanda nacional por mão-de-obra qualificada em Engenharia de Software, gerando profissionais capazes de intervir positivamente em empresas produtoras de software interferindo diretamente em todas as etapas do processo de desenvolvimento do software. A formação sólida de profissionais em engenharia de software influenciará decisivamente no sucesso do país no atendimento das demandas crescentes da indústria nacional, assim como no cenário internacional através da exportação de produtos de software.

O presente artigo apresentou as motivações, objetivos e características do curso da UFRN com base em seu projeto pedagógico [UFRN, 2009]. A estrutura detalhada do curso e o seu projeto pedagógico não são apresentados aqui por limitações de espaço, mas podem ser obtidas no localizador http://www.dimap.ufrn.br/bes.

Agradecimentos Os autores agradecem ao apoio dos colegas da UFRN pelas contribuições nas discussões e revisões ao projeto e a este texto e ao Instituto Nacional em Engenharia de Software (CNPq 573964/2008-4) que financia parcialmente o trabalho de David Deharbe e Marcel Oliveira.

Referências ACM Carreers, Computing: Degrees & Careers. 2009 URL:

http://computingcareers.acm.org. ACM/IEEE Software Engineering 2004 — Curriculum Guidelines for Undergraduate

Degree Programs in Software Engineering. URL: http://sites.computer.org/ccse/ ACM/IEEE-CS Computing Curricula 2005 – The Overview Report. The Joint Task

Force on Computing Curricula IEEE-CS/ACM, 2005. URL: http://www.acm.org/education/education/curric_vols/CC2005-March06Final.pdf

Brasscom. 2009 URL: http://brasscom.com.br. IDC Brasil, International Data Group, 2009. URL: http://www.idc.com. MEC-SESU Diretrizes Curriculares para os Cursos de Graduação. Ministério da

Educação – Secretaria de Educação Superior (MEC-SESU). Disponível na página Web do MEC (http://www.mec.gov.br/Sesu/), 2001.

Sommerville, I.Software Engineering, 8th edition, Ian Sommerville, Pearson Addison-Wesley, 2007.

SWEBOK Guide to the Software Engineering Body of Knowledge, IEEE Computer Society, 2004. URL: http://swebok.org

UFG Projeto Pedagógico do Curso Engenharia de Software (Bacharelado), Instituto de Informática, Universidade de Goiás. URL: http://engenhariadesoftware.inf.br

66


Sociedade Brasileirade Computação

UFBAORG

AN

IZA

ÇÃ

O

REA

LIZA

ÇÃ

OPA

TRO

CÍN

IO

FAPESBPesquisa do Estado da Bahia

Fundação de Amparo à

Secretaria da Indústria,Comércio e Mineração

EVENTOS SATÉLITES

XVII Sessão de Ferramentas

III FEESFórum de Educação em Engenharia de Software

XV WTESWorkshop de Teses e Dissertações em Engenharia de Software

IV LTPDWorkshop on Languages and Tools for Parallel and Distributed Programming

I WB-DSDMWorkshop Brasileiro de Desenvolvimento de Software Dirigido por Modelos

IV LA-WASPLatin American Workshop on Aspect-Oriented Software Development

AutoSoft 2010First Workshop on Autonomous Software Systems

IV WDDSWorkshop de Desenvolvimento Distribuído de Software

I WOESWorkshop Brasileiro de Otimização em Engenharia de Software

I WJPWorkshop sobre Diretrizes para Jovens Pesquisadores em Engenharia de Software

SBESXXIV Simpósio Brasileiro de

Engenharia de Software

SBLPXIV Simpósio Brasileiro de

Linguagens de Programação

SBCARSIV Simpósio Brasileiro de

Componentes, Arquitetura eReutilização de Software

cbsoft 2010 fees anais

Documents