Bruno Casella*
5. Conclusions and policy implications
Ao todo, o survey continha 10 questões, disponível no Anexo A, que foram divididas em 3 categorias.
Questões Pessoais para extrair informações relativas à instituição, tempo de ensino na disciplina e se possuíam experiência acadêmica ou industrial na área.
Questões de Ensino para descobrir as metodologias usadas e a percepção do partici- pante quando a novas abordagens, processos ensinados em sala, fontes de informa- ções e di culdades no ensino.
Desa os no Ensino para identi car as di culdades considerando também a perspectiva dos alunos que é percebida pelo docente.
4.5 Resultados
Todas as questões foram dispostas em uma planilha e suas respostas foram organi- zadas e categorizadas para melhorar a análise. Participaram da pesquisa os docentes das instituições pertencentes ao Ceará, Pernambuco, Rio Grande do Norte, Espírito Santo, Mato Grosso do Sul, Santa Catarina, São Carlos e Rio de Janeiro, Figura 7. Metade dos participantes possuíam mais de 4 anos de ensino da disciplina, o que mostra uma matu- ridade para responder questões acerca do ensino. Vimos que a maioria dos participantes estava concentrado na região Nordeste, Figura 8 Quando questionados sobre as experiên- cias na área em um contexto industrial, mais da metade responderam que sim. A Tabela 11 mostra um resumo dos participantes. Na primeira coluna encontra-se o ID seguido do estado, tempo de ensino (anos) e experiência na indústria.
Figura 7: Estados participantes na pesquisa
Dos participantes, 8 possuíam mais de 4 anos de experiência no ensino da disciplina, 6 possuíam entre 1 e 3 anos, o restante dos participantes com menos de 1 ano de experiência. Dos participantes, aproximadamente 13 deles possuíam experiência na indústria com a área.
Sobre as metodologias de ensino utilizadas (Q01)
Questionamos os docentes acerca das metodologias e abordagens utilizadas em sala de aula no processo de ensino-aprendizagem da disciplina. Foi identi cado que a maioria utiliza o ensino baseado em projetos, onde o aluno ou o docente de nem um sistema a ser implementado, ou especi cado e seu desenvolvimento será feito no decorrer da disciplina
Tabela 11: Resumo dos docentes participantes
ID UF Tempo Experiência na indústria P01 CE 1 a 3 anos Sim P02 RN > 4 anos Não P03 CE 1 a 3 anos Sim P04 PE > 4 anos Sim P05 ES > 4 anos Sim P06 RN > 4 anos Sim P07 PR > 4 anos Não P08 MS < 1 ano Não P09 SC 1 a 3 anos Sim P10 PR 1 a 3 anos Sim P11 CE 1 a 3 anos Sim P12 SC 1 a 3 anos Sim P13 SP > 4 anos Sim P14 PR > 4 anos Sim P15 CE > 4 anos Sim P16 RJ > 4 anos Sim
Figura 8: Regiões dos participantes
ou ao nal. Alguns docentes destacaram o fato de que os projetos, em sua maioria, são reais, com clientes sendo representados por docentes ou externos à universidade. Um dos docentes comentou sobre a inspeção de documentação que é feita durante o desenvolvi- mento desses projetos.
"Também fazemos com que times diferentes façam inspeção da documenta- ção."(Sic)
A inspeção, é uma atividade muito importante que pode reduzir problemas em um ambiente de desenvolvimento onde se tem um processo constante de elicitação de requi- sitos. Um outro docente destacou que os sistemas desenvolvidos são utilizados na própria
instituição. Esse fato nos faz acreditar que possa induzir a uma maior motivação dos alu- nos. Os projetos desenvolvidos por eles são úteis a seu contexto e não são do tipo que só serão utilizados naquela disciplina e em seguida descartada. Como os sistemas tendem a evoluir os mesmos poderão ser usados novamente, na disciplina, quando necessitarem de mais funcionalidades que deverão então ser especi cadas e documentadas pelos alunos.
"Já utilizei diversas metodologias, mas costumo utilizar projetos, nos quais os alunos executam as etapas da Engenharia de Requisitos considerando sta- keholders reais (podem ser projetos voltados ao contexto da universidade por exemplo)". (Sic)
Uma parcela dos docentes utiliza a abordagem de simulação onde exercitam, por meio de entrevistas, a elicitação de requisitos com docentes ou pessoas externas à universidade. Um dos participantes descreveu que durante a simulação uma equipe de alunos cumpre o papel de engenheiro de requisitos, enquanto também assumem o papel de cliente para outras equipes. Um outro docente relatou que os clientes são docentes do campus. Outro docente destacou o treinamento da atividade de documentação através de simulações de projetos em sala de aula.
"Ao longo do semestre cada atividade ou prática da Engenharia de Requisitos (elicitação de requisitos, classi cação, validação, etc) os alunos devem aplicar no projeto, por exemplo, utilizar as técnicas de elicitação de requisitos com um possível cliente do projeto." (Sic)
Houve também a menção de utilização de aulas expositivas, PBL e uso de jogos. Uma abordagem de pesquisa de campo foi citada no survey, onde os alunos identi cam opor- tunidades e problemas de negócio detectando assim requisitos para um sistema. Ainda nessa questão foi percebido o uso de artefatos e sistemas em sala de aula. Alguns docen- tes destacaram o uso de listas de exercício, formulários online (Quizziz1 e Kahoot2) que
trabalham com game cação, poemas, interpretação textual, notícias e quebra-cabeças. A Figura 9 mostra o percentual de cada metodologia/abordagem mencionada na pesquisa pelos docentes.
"Aulas expositivas dialogadas com a utilização de aulas reservadas a realização de lista de exercícios de especi cação e modelagem" (Sic)
Figura 9: Metodologias e abordagens utilizadas
Sobre ascensão das metodologias de ensino-aprendizagem (Q02)
Há muitos desa os que estão relacionados com o ensino da disciplina. Um exemplo pode ser a complexidade de alguns tópicos, como documentação que é bastante variável dependendo do contexto, com níveis diferentes de profundidade e atributos. Muitas evolu- ções aconteceram no campo da educação e muitas metodologias que valorizam o processo de ensino-aprendizagem, surgiram.
Questionamos os docentes, no survey, sobre metodologias que estão em ascensão e sendo fortemente usada, segundo a sua visão. Foram citados metodologias que colocam o aluno como elemento central no processo de ensino aprendizagem, como a Aprendizagem Baseada em Problemas, por exemplo. Outra citação diz respeito a abordagens de ensino que envolvem o desenvolvimento de ideias de negócio e a participação de clientes reais. Através dessa abordagem é possível trabalhar tópicos, citados como: análise de domínio, design de soluções, elicitação e priorização de requisitos.
"Abordagens que coloquem o aluno como agente central (sujeito ativo) no pro- cesso de ensino aprendizagem. É interessante buscar experiências de mercado para dentro da ambiente educacional." (Sic)
A aprendizagem baseada em projetos e uso de jogos também foram citadas por alguns docentes. Ensinar por meio de projetos, disse um docente, ajuda o aluno a entender as práticas a serem realizadas dentro do contexto das empresas. Em contrapartida, também foi destacado que isso só é efetivo quando o ensino da disciplina é feito por docentes que
1https://quizizz.com/
tiveram experiência de mercado. Metodologias que conseguem mesclar a participação de membros da indústria também foram vistas, porém existe um certo fator de di culdade em fazer planejamentos de aulas desse tipo.
"Trazer casos práticos de especi cação de sistemas na indústria de software. O grande problema é conseguir a cooperação de empresas de desenvolvimento." (Sic)
Sobre o foco do ensino (Q03)
São muitas etapas e atividades no processo de Engenharia de Requisitos e foi ques- tionada se haveria um foco maior em alguma delas dada a experiência do docente ou necessidade do mercado, por exemplo. A Figura 10 mostra a porcentagem das etapas citadas pelos docentes. É percebido que nem todo processo é ensinado na disciplina den- tre os participantes. Mais de 50% dos participantes focam na etapa de identi cação dos requisitos. Em seguida, a etapa de especi cação foi a mais comentada entre eles.
Um dos docentes descreveu o foco intenso em técnicas de levantamento de requisitos. A experiência de uso dessas técnicas, em sala, são importantes. Essas atividades ajudam o discente a desenvolver habilidades de fala, raciocínio e principalmente de comportamento, já que irão lidar diretamente com outras pessoas que na maioria das vezes serão externas a sua equipe de trabalho. Ainda foi mencionada a utilização de modelagem conceitual (foco no domínio do problema) e orientado ao objeto nas etapas em foco.
Figura 10: Processo ou atividades em foco na disciplina Sobre a percepção de modi cação no ensino da disciplina (Q04)
Muito já se evoluiu em questões de práticas e metodologias de ensino. A disciplina de Engenharia de Requisitos é mencionada pela IEEE em 2004, logo a mesma tem muitos anos de vigência. Os participantes da pesquisa foram questionados sobre sua percepção em relação à evolução na maneira como a disciplina é abordada. Há alguns grupos de estudos voltados para Engenharia de Requisitos no Brasil, além de eventos que lidam com o ensino da área.
Dos respondentes, alguns a rmam que percebem essas mudanças, porém foi comen- tado que a prática de aplicação de projetos e exercícios ainda é muito forte e exposta de uma maneira não tão dinâmica. Outros disseram que não perceberam nenhuma evolução na maneira como a disciplina é apresentada em sala de aula. O restante cou dividido entre talvez e sobre desconhecerem as abordagens de ensino de outras universidades.
"Apenas parcialmente. O uso de projetos/exercícios parece dominante."(Sic) Sobre as fontes de busca de informações (Q05)
Há muitos eventos com trilhas voltadas especi camente para Engenharia de Requisi- tos, educação e indústria. Existem também livros e sites que descrevem conteúdos sobre a área. Questionamos os participantes sobre as fontes de informações na qual se man- têm atualizados quando a área, seja ela livro, eventos ou sites. Tivemos um volume de indicações de fontes de busca de diferentes tipos:
Livros: Software Engineering by Sommerville; Software Engineering by Wazlawick; Soft- ware Engineering by Pressman; Project Management Book, Requirements Engi- neering: Fundamentals, Principles, and Techniques by Klaus Pohl; and books on standards and quality models for Requirements Engineering
Eventos: Workshop on Requirements Engineering - WER; Workshop on Informatics in Education - WEI; International Requirements Engineering - RE; Brazilian Sym- posium on Software Engineering - SBES; Brazilian Computer Society Congress - CSBC; Brazilian Symposium on Informatics in Education - SBIE; Latin Ameri- can Symposium on Software Engineering - SLISW; Brazilian Software Congress - CBSoft; International Conference on Software Engineering - ICSE; Software Engi- neering Teaching Forum - FEES; Brazilian Software Quality Symposium - SBQS; and Conference on Software Engineering Education and Training - CSEET
Websites: Microsoft; Podcasts; and YouTube and DevMedia videos
Outros: RUP models and templates; and Rational Enterprise Architect modeling tools Sobre di culdades no ensino de etapas do processo (Q06)
O processo de ER é bastante complexo e isso também pode ser re etido no ensino. Alguns tópicos podem ser difíceis de serem ensinados devido a: complexidade, abstração, limitação de material, metodologias e tempo da disciplina. Os docentes responderam sobre qual etapa do processo de Engenharia de Requisitos eles consideram mais difícil dado esse conjunto de fatores. A Figura 11 mostra a porcentagem dos tópicos e etapas citados pelos docentes.
Figura 11: Tópicos ou etapas mais difíceis de se ensinar
Percebemos que grande parte das di culdades estão pautadas na complicação em simular experiências reais com projetos complexos em sala de aula. Na elicitação, além da subjetividade foi comentado que há uma necessidade de visão horizontal e vertical do domínio do negócio e do problema a ser resolvido. Ainda mais, foi comentado que é uma etapa que necessita de maturidade do aluno, o que geralmente não se têm devido ao semestre onde a disciplina se encontra ou a própria falta de experiência. Há também uma di culdade no que diz respeito à presença de pessoas com experiência de mercado que possam atuar como clientes na disciplina, em forma de parceria.
"Levantamento (Elicitação) de Requisitos é a mais difícil de ensinar, pois é aquela em que há menos oportunidade de simular situações de mundo real. Os alunos geralmente têm pouca maturidade e é muito difícil conseguir pessoas para desempenhar os papéis de clientes e usuários."(Sic)
Sobre a especi cação foi comentado que os alunos não entendem a importância de se documentar requisitos e da complexidade dessa atividade. Um dos participantes falou que a documentação é simples de se explicar, porém bastante complexa de se fazer. A atividade de modelagem da especi cação também foi citada. A criação de diagramas de casos de uso e descrição de cenário é bastante di cultosa e a limitação dos alunos quanto a variedade de modelagem, uma vez que eles acreditam que casos de uso são su cientes.
Na Validação e Veri cação os alunos necessitam revisar artefatos e um docente relatou que os mesmos não gostam dessa atividade. Ainda foi comentado da falta de tempo, ex- periência dos alunos para identi car classes de defeitos e ausência de exemplos complexos para que os alunos exercitem a atividade de prototipação dessa etapa. A subjetividade da área também foi comentada por ser algo que não depende só do Engenheiro de Software, mas também do cliente para aprovação.
"Acredito que as etapas de validação e veri cação sejam as mais complicadas devido aos aspectos subjetivos para que o cliente aprove as etapas do pro- jeto."(Sic)
Por m, a etapa de gerenciamento foi citada e foi comentado que as mudanças que são simuladas em sala de aula não transmitem o que acontece no mundo real. O aluno não tem a dimensão da quantidade de coisas que são afetadas ao longo do projeto.
"Gerência de Requisitos, porque as mudanças são "simuladas"e o aluno não vivencia as di culdades reais que advém de mudanças ao longo de um projeto real."(Sic)
Sobre os problemas e desa os no ensino-aprendizagem da disciplina (Q07) Há alguns registros na literatura que demonstram di culdades no processo de ensino como um todo. Fatores como complexidade do tema, limitação de materiais, motivação dos alunos entre outros, são comumente vistos em alguns cenários. Tendo isso em vista, perguntamos aos docentes quais são seus desa os frente ao ensino-aprendizagem da dis- ciplina.
Os desa os mais citados foram falta de dedicação dos alunos e a di culdade em simular um ambiente em sala de aula que transmita para os alunos uma experiência mais real do processo ensinado na disciplina. O fator carga horária foi citado por que o tempo alocado para a disciplina é pouquíssimo. Sabemos que o processo a ser ensinado é longo e em
algumas partes complexas, além de possuir um conjunto variado de técnicas e artefatos para se conhecer. A Figura 12 mostra a porcentagem dos fatores citados.
"desinteresse dos alunos pois os mesmos dão mais valor ao projeto e imple- mentação." (Sic)
Figura 12: Di culdades e desa os no ensino da disciplina
Outro fator citado foi a falta de abordagens práticas, que está ligado à abordagem de ensino. Um docente destacou que o conteúdo costuma ser muito teórico e que sente a necessidade de se investir em formas mais práticas de se trabalhar em sala de aula. Esse é um fator que pode estar ligado com a interdisciplinaridade. A disciplina em conjunto com outras dá uma impressão mais real do processo e pode gerar no aluno o pensamento da importância da área.
"Quando a disciplina é ministrada de maneira muito teórica, com poucas ati- vidades práticas, os alunos sentem-se desmotivados em contribuir com a dis- ciplina. As atividades práticas fazem com que a disciplina torne-se mais atra- tiva."(Sic)
Na interdisciplinaridade é notada uma ênfase na necessidade de que se haja um pa- ralelismo com outras disciplinas. Outro ponto comentado por um docente é que o ensino da disciplina deveria ser distribuído ao longo do curso e não focado em uma ou duas disciplinas.
"O ensino de ER deveria ser distribuído ao longo dos cursos de graduação, ao invés de ter uma carga horária concentrado em uma ou duas disciplinas."(Sic)
Sobre o problema com simulação de ambiente em sala de aula foi comentado que isso re ete no entendimento do aluno acerca do tema. Um docente comentou que o aluno sente di culdades em aplicar na prática o que foi visto por que é um fator que está fora dos livros, por tratar-se de uma relacionamento pessoal construído com experiência quando se tem vivência da relação engenheiro-cliente e engenheiro-técnicas. Logo, como foi comentado na pesquisa, há uma necessidade de práticas reais e representativas.
Outro fator envolvendo a simulação e que foi comentado é que se faz necessária a criação de um contexto/atividades para se trabalhar melhor a escrita de requisitos. O aluno precisa entender que elicitar é coletar e não especi car o que um sistema terá, enfatizou um docente. São necessários cenários mais complexos e que exijam mais esforço entre os alunos para extrair e entender melhor as aplicações. A carência nessas simulações acaba por não mostrar a aplicabilidade do que é aprendido em sala de aula e será visto na indústria, comentou um docente.
O último fator, e mais citado, diz respeito à motivação e dedicação dos alunos. Foi unanimemente comentado o desa o que é motivar o aluno em sala de aula. Um docente comentou da di culdade em mostrar que essa é uma fase do processo de desenvolvimento muito importante. O docente tem ainda que lidar com o pensamento dos alunos de que a disciplina é fácil, e por isso não se empenham muito nela. Além disso, ainda há a ideia de que especi car requisitos é tarefa simples, porém, a literatura nos mostra muitos exemplos de problemas nessa atividade.
"Vivenciar os problemas reais e compreender a importância da engenharia de requisitos em ambiente acadêmico. Além disso, quando tentamos promover essas experiências reais por meio de projetos, nem sempre os(as) alunos (as) se engajam da forma esperada."(Sic)
Há a falta de interesse em aprender requisitos por que o aluno dá mais importância a implementar o projeto do que em fazer o processo de especi cação de funcionalidades. Uma solução foi comentada por um docente que é tornar a disciplina prática por que é percebida uma motivação quando isso ocorre. Foi veri cado que em alguns casos, mesmo quando se promovem projetos a serem desenvolvidos, os alunos não se encorajam como esperado na disciplina.
Sobre estratégias para se ensinar documentação de requisitos (Q08)
Restringindo as abordagens a um tema especí co, questionamos sobre como os docen- tes abordam a documentação de requisitos em sala de aula. Como demonstrado no Grá co
13, em primeiro lugar foi citada a disponibilização de templates, seguido de execução de projetos e ferramentas.
É identi cado que os docentes costumam disponibilizar templates para seus alunos e adotar estratégias a partir disso. Foi mencionado que esses templates são disponibilizados em plataformas onde o docente acompanha a modi cação dos mesmo. Outro fator citado é que é feito uma adaptação e escolha de templates que sejam adequados para determinadas situações e contextos.
Há muitos tipos de documentação. Um docente comentou que costuma de nir modelos de documento de de nição de requisitos e especi cação. Através disso, ele avalia e aponta os problemas identi cados na elaboração. Outro docente comentou o uso de padrões IEEE na documentação. Foi percebido que existem casos onde o template é construído na medida em que os conceitos são abordados em sala.
"Leitura, uso de templates e outros modelos, adaptação de templates, escolha dos modelos adequados a cada situação." (Sic)
Figura 13: Abordagens para o ensino de documentação
Quanto à abordagem de realização de projetos, é importante para se trabalhar docu- mentação. Com base no modelo de desenvolvimento os alunos terão sempre que atualizá-la e validá-la sendo acompanhados pelo docente. Outro docente enfatizou que faz essa ativi- dade com clientes reais o que gera um estímulo diferente dependendo do usuário que está solicitando aquelas funcionalidades.
Outro fator trabalhado em projeto é que alguns docentes adotam o modelo de sprints e os alunos terão que entregar sempre a documentação revisada e validada. Ainda nessa
atividade alguns solicitam mudança de escopo que re ete a evolução do requisito e impacta diretamente na documentação do projeto.
Um ponto bastante interessante e mencionado por um participante foi a variedade de templates e ferramentas que existem dependendo da empresa. É importante focar nos conceito e padrões básicos e através disso complementar com modelos mais atuais de documentações.
"Formatos e ferramentas de documentação/especi cação de requisitos variam