Dinâmica de ER

Durante a aplicação na disciplina não foi utilizado o esquema de stakeholders cruzados como foi feito no teste. Alguns fatores influenciaram nessa decisão, como o tempo disponível para a realização da dinâmica, e o fato de que o objetivo do trabalho é mostrar que os alunos podem ser utilizados como stakeholders virtuais em um curso de ER. Dessa forma, não necessariamente todos os alunos participantes teriam que atuar como analista de requisitos.

Essa fase foi realizada da seguinte maneira: foram formados dois grupos de stakeholders virtuais, um para cada domínio apresentado e um grupo de analistas de requisitos. Em seguida, foram formadas duplas compostas por um analista e um stakeholder para que a dinâmica pudesse seguir dando inicio as rodadas de atividades de ER.

Na primeira etapa foi realizada uma rodada de elicitação, em que cada aluno analista entrevistava sua dupla a fim de obter uma visão inicial sobre o domínio do qual ele deveria analisar os problemas relatados e identificar funcionalidades de um software apresentando soluções para seu cliente. Nesse momento cada analista deveria elaborar um documento de visão simples.

Com o documento de visão elaborado, cada analista tinha de validar juntamente ao stakeholder e realizar correções se necessário. Feito isso, uma das funcionalidades identificadas devia ser priorizada, para em seguida ser especificada e detalhada em forma de histórias de usuário.

Nesse ponto podemos observar outra modificação em relação ao teste: a substituição de casos de uso por histórias de usuários. Essa alteração ocorreu devido a alguns fatores, como o fato de que elas são mais utilizadas na disciplina de engenharia de requisitos. Além disso, sua escrita prática e rápida fez com que se encaixasse bem para agilizar a realização das atividades da dinâmica, já que o tempo foi curto, sem contar que histórias de usuários são muito usadas nas metodologias ágeis como SCRUM, empregadas em grandes organizações de desenvolvimento de software.

Para finalizar a segunda etapa, as histórias de usuário deveriam ser revisadas e validadas. Por fim, na terceira e ultima etapa, os analistas deveriam criar um protótipo de tela da funcionalidade escolhida anteriormente e apresentá-lo para seu cliente.

6.2.5 Aplicação de questionários

Após a execução de todas as etapas da dinâmica, foi solicitado que os alunos que participaram do curso respondessem um questionário com objetivo de obter feedback sobre a abordagem de ensino e o comportamento dos alunos ao executar seus papeis de stakeholders virtuais e analistas de requisitos.

O questionário utilizado foi um pouco diferente do que foi aplicado no teste, com algumas modificações que visavam obter respostas mais relevantes. Anteriormente a forma como as perguntas eram apresentadas deixava espaço para respostas muito diretas como “sim” ou ”não”. Visto isso, foram elaboradas alternativas para as questões requisitando uma justificativa para a opção escolhida. Como durante a aplicação na disciplina existia um grupo de alunos composto apenas por analistas de requisitos e outro composto apenas por stakeholders, foi elaborado um questionário para cada grupo.

As perguntas contidas nos questionários possuem o objetivo de identificar aspectos como: o nível de segurança dos stakeholders virtuais ao responder as perguntas dos analistas e a eficácia das narrativas de uso em fazer com que os alunos stakeholders compreendam o problema. As questões foram organizadas nos questionários de forma que as informações obtidas possam ser confrontadas, ou seja, as respostas dos analistas possam ser comparadas com as respostas dos stakeholder a fim de analisar os aspectos citados acima.

O questionário destinado aos alunos que atuaram com analistas encontra-se no Apêndice B. Já o questionário destinado aos alunos que atuaram com stakeholders pode ser encontrado no Apêndice C.

7 DESENVOLVIMENTO/RESULTADOS

O curso de ER utilizando a proposta de ensino apresentada nesse trabalho foi realizado durante a disciplina de Requisitos de Software na Universidade Federal do Ceará – Campus Quixadá. Dezessete alunos participaram, sendo eles 8 stakeholder e 9 analistas, totalizando 7 duplas e um trio.

A dinâmica teve 2 horas de duração e seguiu o seguinte roteiro:

 Apresentação da proposta (apresentação do termo de consentimento e esclarecer, explicações gerais sobre a proposta de ensino, ferramentas que serão utilizados) – 10 minutos;

 Treinamento de stakeholders virtuais (apresentação do material de treinamento, retirar dúvidas) – 20 minutos;

 Primeira rodada de elicitação – 10 minutos;  Elaboração do documento de visão – 20 minutos;

 Validação e revisão do documento de visão/ priorização de funcionalidade a ser desenvolvida – 10 minutos;

 Escrita de histórias de usuários relacionadas a funcionalidade escolhida – 15 minutos;

 Validação e revisão das histórias – 10 minutos;  Criação e apresentação de protótipo – 15 minutos;  Aplicação de questionário – 10 minutos.

O instrutor ficou disponível para responder as dúvidas dos alunos durante toda a realização da dinâmica. Nesse tempo foi procurado seis vezes pelos alunos que estavam atuando como stakeholders e três vezes pelos alunos analistas de requisitos.

Entre os alunos stakeholders as principais dúvidas eram quanto ao domínio quando eram questionados sobre aspectos que estavam fora do escopo das narrativas de uso. O mesmo aconteceu com os alunos analistas, que não ficavam satisfeitos com as respostas dos stakeholders em alguns momentos. Alguns chegaram a solicitar a possibilidade de falar com uma das partes interessadas que eram relatadas nas narrativas de uso, como por exemplo, a atendente citada várias vezes nas narrativas referentes ao domínio da clínica odontológica.

Nesses casos os alunos stakeholders foram orientados a acrescentar informações ao domínio por si mesmo, além do que estava nas narrativas. Aos analistas, foi orientado que

apresentassem sugestões aos stakeholders, já que esse é um cenário que acontece com frequência nos processos de levantamento de requisitos: o cliente muitas vezes não sabe exatamente o que quer. Cabe então ao analista utilizar sua habilidade de análise de negócio para apresentar soluções para os problemas identificados.

Ao final da dinâmica verificou que dos artefatos gerados, todas as equipes elaboraram documento de visão e histórias de usuários, sendo que apenas duas equipes criaram protótipos de tela para a funcionalidade escolhida. Com isso, concluiu-se que o tempo utilizado para a dinâmica foi curto e a finalização das atividades depende muito da capacidade de cada aluno.

A maior parte dos analistas escreveram documentos de visão bem elaborados e que abordavam o problema apresentado pelos stakeholders de uma forma abrangente e compreensível. Por outro lado, alguns documentos de visão apresentavam apenas a descrição de uma parte do problema, focando em apenas um dos pontos chaves abordados nas narrativas. Já as histórias de usuários foram bem elaboradas, todas apresentavam um cenário de utilização do sistema que resolvesse algum problema apresentado pelo domínio. Por fim, os protótipos de tela construídos demonstraram soluções para a visualização das consultas diárias pelo paciente, referente ao domínio da clínica odontológica, e para visualização de informações sobre quartos para reserva, referente ao domínio do hotel. Assim, podemos verificar que as soluções elaboradas pelos analistas atendem a algum ponto chave dos domínios apresentados aos stakeholders.

Por fim, foi solicitado aos alunos que respondessem um questionário de acordo com o papel desempenhado na dinâmica, analista de requisitos ou stakeholder. Dos dezessete participantes quinze responderam o questionário, dentre os quais oito foram stakeholders e sete eram analistas, faltando assim, as respostas de dois analistas de requisitos.

A Figura 4 ilustra como foram divididas as equipe na dinâmica, a fim de facilitar a visualização e comparação das respostas dadas pelos alunos e seus respectivos companheiros. Os analistas foram identificados de A1 a A7 e os stakeholders de S1 a S6, como podemos observar a seguir:

Figura 5 – Relacionamentos da aplicação: Analistas x Stakeholders.

Fonte: elaborada pelo autor.

As respostas do questionário direcionado aos alunos que atuaram como analista de requisitos, Apêndice B, encontram-se a seguir:

Quadro 3 – Pergunta 1 do questionário de aluno analista.

P1: Os stakeholders estavam preparados para responder suas perguntas com segurança? Classifique quão seguros estavam os stakeholders virtuais, justifique sua resposta.

Analistas Respostas

A1  Seguro na maioria das respostas

 Justificativa: “Quando eram feitas perguntas que pareciam fugir do roteiro de

informações passadas para o stakeholder, ele não sabia responder”.

A2  Seguro na maioria das respostas

 Justificativa: “Estava apto para expor suas necessidades”.

A3  Seguro em todas as respostas

 Justificativa: “Ele não tinha duvidas e sabia exatamente o que queria”.

A4  Seguro na maioria das respostas

 Justificativa: “Acho que perguntamos coisas fora do escopo da narrativa”.

A5  Seguro na maioria das respostas

 Justificativa: “Pois as respostas foram em sua maioria bem imediatas, além de bem

A6  Seguro em todas as respostas

 Justificativa: “O Stakeholder estava totalmente ciente do problema e conseguiu

responder bem todas as perguntas”.

A7  Seguro em todas as respostas

 Justificativa: “Todas as perguntas que fiz, o stakeholder respondeu exatamente (ou

quase) o que eu queria saber”. Fonte: Elaborado pelo autor.

Quadro 4 – Pergunta 2 do questionário de aluno analista.

P2: As informações passadas pelos stakeholders foram suficientes para a compreensão do problema? Justifique sua resposta.

Analistas Respostas

A1  Compreensível sempre

 Justificativa: “As informações passadas pelo stakeholder destacavam bem a

necessidade requerida por ele graças às descrições do ambiente em que ocorre a

problemática e os envolvidos”.

A2  Compreensível na maioria das vezes

 Justificativa: “Sim, pois o mesmo sabia se expressar bem”.

A3  Compreensível sempre

 Justificativa: “Ele sempre passava o máximo de informações possíveis para ajudar a solucionar o problema”.

A4  Compreensível sempre

 Justificativa: “Foi compreensível, apenas perguntamos mais para ter certeza”.

A5  Compreensível na maioria das vezes

 Justificativa: “Pois tive algumas dúvidas, em especial sobre os a agenda dos dentistas”.

A6  Compreensível sempre

 Justificativa: “Conseguiu passar bem as informações e juntamente com as perguntas

(que foram respondidas de forma segura) conseguiu sanar as dúvidas”.

A7  Compreensível na maioria das vezes

 Justificativa: “Algumas vezes tive que ir um pouco mais a fundo para des cobrir a necessidade do cliente”.

Fonte: Elaborado pelo autor.

Em seguida, podemos visualizar as respostas do questionário direcionado aos alunos que atuaram como stakeholders, Apêndice C: “Qual domínio lhe foi apresentado?”: Essa pergunta tinha o objetivo único de identificar em qual domínio o aluno foi treinado para ser stakeholder, a fim de comparar se os resultados das demais perguntas eram semelhantes para os dois domínios apresentados.

Quadro 5 – Pergunta 2 do questionário de aluno stakeholder.

P2: Classifique o domínio que lhe foi apresentado quanto ao seu nível de conhecimento sobre ele:

Stakeholders Respostas

S1  Pouco conhecimento. Conheço poucos processos que ocorrem nesse domínio. S2  Conhecido. Conheço os principais processos.

S3  Desconhecido. Não conheço os processos que ocorrem nesse domínio. S4  Pouco conhecimento. Conheço poucos processos que ocorrem nesse domínio. S5  Conhecido. Conheço os principais processos.

S6  Pouco conhecimento. Conheço poucos processos que ocorrem nesse domínio.

Fonte: Elaborado pelo autor.

Quadro 6 – Pergunta 3 do questionário de aluno stakeholder.

P3: Sentiu-se preparado para responder as perguntas dos entrevistadores com segurança? Justifique sua resposta.

Stakeholders Respostas

S1  Bem preparado, seguro em todas as respostas.

 Justificativa: não justificou.

S2  Preparado, raramente inseguro em suas respostas.

 Justificativa: “Algumas dúvidas em como prosseguir com a entrevista, porém os

problemas apresentados eram fáceis de serem transmitidos”.

S3  Preparado, raramente inseguro em suas respostas.

 Justificativa: “O texto das descrições dos problemas forneciam bastantes detalhes”.

S4  Preparado, raramente inseguro em suas respostas.

 Justificativa: “Sim, devido às narrativas. Apenas algumas perguntas particulares do

negócio que não consegui responder com exatidão”.

S5  Preparado, raramente inseguro em suas respostas.

 Justificativa “Tive dúvidas em um determinado momento sobre o alcance da

solução do problema, se ele seria somente para a clínica Y, ou para mais clínicas”.

S6  Bem preparado, seguro em todas as respostas.

 Justificativa: “Não senti dificuldade”.

Quadro 7 – Pergunta 4 do questionário de aluno stakeholder.

P4: Até que ponto as narrativas de uso foram capazes de torna-lo familiarizado com os problemas encontrados por um stakeholders real daquele domínio fazendo com que adquirisse o conhecimento necessário para responder as perguntas dos analistas? Classifique e justifique sua resposta:

Stakeholders Respostas

S1  Eficaz na maioria das vezes.

 Justificativa: não justificou.

S2  Eficaz na maioria das vezes.

 Justificativa: “As narrativas ajudaram bastante, não deixou praticamente nenhuma

duvida em relação aos problemas que deveriam ser resolvidos”.

S3  Eficaz na maioria das vezes.

 Justificativa: “Eu achei que havia entendido uma das narrativas, mas depois

cheguei à conclusão que havia interpretado errado. As outras, consegui entender bem”.

S4  Eficaz na maioria das vezes.

 Justificativa: “As narrativas melhoraram meu conhecimento sobre o domínio, e

tiraram a maioria das dúvidas”.

S5  Eficaz na maioria das vezes

 Justificativa: “A narrativa que me fez ter dúvidas foi aquela que o Dentista

marcava o mesmo horário para duas clínicas. Que me fez pensar que a solução alcançaria mais de uma clínica”.

S6  Sempre eficaz. Todas as narrativas me permitiram entender um problema

 Justificativa: “Elas foram capazes de mostrar os problemas da possível solução em

questão, com isso pude expressar para o analista o suficiente”. Fonte: Elaborado pelo autor.

Após apresentadas as perguntas específicas para cada papel, temos a análise da pergunta sobre a abordagem em geral, presente nos dois questionários: “Cite vantagens e desvantagens de se utilizar os próprios alunos do curso como stakeholde rs virtuais para o ensino de ER”. Os quadros 8 e 9 mostram as vantagens e desvantagens citadas pelos alunos, respectivamente, registrando a quantidade de ocorrências de cada citação:

Quadro 8 – Vantagens de utilizar alunos como stakeholder virtuais no ensino de ER.

Vantagens Ocorrências

 Facilita a comunicação 3

 Possibilita que o aluno experimente a posição do stakeholder, isso pode ajudar a ter

uma compreensão melhor sobre o cliente.

3

 Os alunos por possuírem conhecimento prévio da área podem incorporar o papel de

stakeholder com facilidade.

1

 Ganho de experiência 1

 Consolidação do conhecimento através da prática 1

 Os alunos possuem conhecimento em análise de negócio podendo entender bem o

domínio através das narrativas de uso.

1

 Adquirir conhecimento sobre os domínios utilizados para a aplicação da dinâmica. 1

 Possibilita a avaliação do nível da turma. 1 Fonte: Elaborado pelo autor.

Quadro 9 – Desvantagens de utilizar alunos como stakeholders virtuais no ensino de ER.

Desvantagens Ocorrências

 Alunos não são especialistas no domínio. 5

 Alunos já possuem conhecimento em engenharia de software e

engenharia de requisitos, fugindo um pouco do pensamento de stakeholder.

5

 Alunos que atuaram como stakeholder não experimentaram o papel de analista.

1

 Pouco tempo para entender bem o domínio. 1

Fonte: Elaborado pelo autor.

Por fim, foi realizada a entrevista com o professor que ministra a disciplina de Requisitos de Software durante a qual foi aplicada a dinâmica. Foi feita a ele a seguinte pergunta: “Quais as diferenças entre essa abordagem de ensino e o que era realizado anteriormente na disciplina de Requisitos de software?”. Depois de indagado, o professor fez algumas considerações: “O que era aplicado na disciplina era uma atividade lúdica de entrevistas. Em seguida os alunos eram motivados a pensarem em serviços como startups fazendo com que eles fossem seus próprios stakeholders. Não tem uma dinâmica para entrevistar uma pessoa específica [assim como acontece nessa abordagem de ensino]. O que ajudou foi que a dinâmica é focada em TI ao invés de ser lúdica como a atividade do desenho [a mesma realizada no treinamento ocorrido na aplicação do teste]. Como professor, percebi o interesse dos alunos pela dinâmica, principalmente em relação à curiosidade que eles tinham pelas narrativas de uso. Isso chamou a atenção dos alunos e eles se engajaram no formato da dinâmica”. Para finalizar, o professor fez algumas sugestões que poderiam trazer melhorias, como o aspecto do tempo de realização da dinâmica, e o ambiente em que foi realizada. Além disso, demonstrou interesse em aplicar esse método de ensino na disciplina novamente.

8 DISCUSSÃO

Os resultados apresentados na seção anterior comprovam que o objetivo principal de aplicar uma técnica de ensino de engenharia de requisitos com alunos como stakeholders virtuais foi atingido. As respostas dos questionários direcionados aos alunos, e a entrevista feita com o professor responsável pela disciplina demonstram aprovação da abordagem utilizada.

Os relatos dos participantes permitem identificar aspectos muito importantes, como o fato de os alunos stakeholders mesmo sem possuírem conhecimento detalhado dos domínios que lhes foram apresentados, como pode ser observado no Quadro 5, conseguiram repassar as informações de forma satisfatória e com segurança para os analistas de requisitos, demonstrando a eficácia das narrativas de uso, facilmente visualizada no Quadro 7. Para constatar os aspectos citados, é interessante cruzar as respostas das perguntas 1 e 2 do questionário dos analistas, com as perguntas 3 e 4 do questionário dos stakeholders. Assim é possível visualizar o que cada aluno participante analisou de sua equipe.

Outro ponto que contribuiu bastante para a avaliação dessa proposta foram as vantagens e desvantagens apontadas pelos estudantes. Como foi exposto no Quadro 8, alguns alunos citaram a facilidade de comunicação, o ganho de experiência e a consolidação do conhecimento como vantagens de utilizar alunos como stakeholders. Nesse ponto, uma das vantagens citadas pelos alunos, a facilidade de comunicação, pode ser considerada na verdade uma desvantagem para o ensino de ER já que essa comunicação deve enfrentar uma lacuna que existe entre os termos específicos de cada domínio. Entretanto, outro aspecto chamou mais atenção por ser um ponto positivo que não foi identificado antes de realizar a aplicação da proposta: a experimentação da posição de stakeholder. Essa foi uma das vantagens mais abordadas nas respostas dos questionários. Para os participantes da dinâmica, ao se colocar no lugar do stakeholder o aluno passa a ter uma compreensão melhor sobre o cliente, identificando as principais dificuldades em expressar as suas necessidades e interesses, isso pode trazer um ganho para suas habilidades como analista de requisitos.

Entre as desvantagens, as mais citadas foram o fato de que os alunos stakeholders não são especialistas no domínio e, que por possuírem conhecimento de engenharia de requisitos, tendem a fugir de seu papel na dinâmica, passando informações de forma a facilitar a trabalho dos analistas, diminuindo assim o esforço para analisar os problemas e elaborar soluções.

Embora os alunos stakeholders não possuam conhecimento detalhado do domínio, as respostas dos questionários mostram que o treinamento realizado com as narrativas de uso foi eficaz para fazer com que as perguntas dos analistas fossem respondidas com segurança, deixando a desejar apenas quando foram feitos questionamentos sobre aspectos que estavam fora do escopo do problema apresentado. Isso é comum, pois um stakeholder específico pode não saber como funciona todo o processo de uma determinada área.

Uma possível solução seria treinar cada stakeholder virtual para atuar em um papel específico. Tomando como exemplo o domínio do hotel, o treinamento das partes interessadas seria diferente para cada uma das visões: a visão do cliente que frequenta a piscina e o restaurante, a visão do cliente que faz reserva de quartos, a visão do garçom, a visão da recepcionista e a visão do gerente do hotel.

Através dessa estratégia cada stakeholder aprofundaria seu conhecimento em um ponto de vista específico do domínio, procurando se aproximar o máximo possível de um stakeholder real. Além disso, o treinamento de cada stakeholder virtual para atuar em um papel especifico pode contribuir para manter o foco no problema e contornar a tendência de pensar em soluções. O aluno stakeholder teria que realmente agir como um ator para interpretar alguma parte interessada, ou seja, ao invés de identificar os personagens da narrativa de uso e entender o seu problema, o aluno agiria como o próprio personagem.

Apesar de não ser capaz de reproduzir um ambiente real de analise de negócio para desenvolvimento de software, a abordagem de ensino de ER com alunos como stakeholders virtuais tem suas vantagens. A complexidade de um projeto real pode influenciar

No documento Alunos como stakeholders virtuais no ensino de engenharia de requisitos (páginas 37-58)