Abordagem Proposta por Pinto, R e outros (2015) Aplicada ao Sistema SUAP

O terceiro experimento realizado, utilizando criatividade combinacional para geração de requisitos, envolve o Sistema Unicado de Administração Pública - SUAP. O SUAP, desenvolvido e mantido pelo Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte (IFRN), abrange módulos integrados de apoio às áreas Administrativa, Recursos Humanos e Educacional.

O módulo Educacional (SUAP-EDU) foi escolhido por possuir uma equipe exclusiva de stakeholders que auxiliaram no desenvolvimento e manutenção dos requisitos e regras de negócio do módulo. Além do conhecimento sobre as funcionalidades do módulo, pelos stakeholders, o SUAP-EDU conta com a documentação dos seus requisitos bem denida através de especicações de casos de uso. Este módulo é responsável pela gestão acadêmica de todas as atividades de ensino do IFRN e demais institutos federais conveniados. O sistema atende aos alunos dos cursos regulares e abrange todos os níveis de ensino.

O referido sistema está documentado utilizando linguagem natural em arquivos do MS Word. O módulo SUAP-EDU possui 96 casos de uso especicando suas funcionalidades e regras de negócio. Os casos de uso especicados seguem um template padrão com os seguintes campos: resumo, atores, precondições, póscondições, uxo normal, uxo alter- nativo, requisitos não funcionais, requisitos de interface, regras de negócio, protótipos de interface e diagramas.

O EngR responsável pelo módulo SUAP-EDU utilizou a ferramenta Ideasy para automatizar as principais tarefas da abordagem proposta.

Diante da documentação textual disponível, o EngR optou por combinar esses textos com textos relacionados à área de atuação do software, mas que não foram produzidos pela equipe de stakeholders do sistema. Para melhor entendimento deste experimento, vamos chamar de Fonte de Dados Interna os textos selecionados com base na documentação do SUAP-EDU e Fonte de Dados Externa os textos selecionados que são relacionados à área de atuação do software, mas que não foram produzidos pela equipe de stakeholders do sistema.

Assim, o EngR selecionou as especicações de casos de uso do SUAP-EDU, e removeu imagens, diagramas, uxogramas e demais informações que não eram referências textuais explícitas do domínio do sistema, incluindo assim a Fonte de Dados Interna.

Para a Fonte de Dados Externa, o EngR decidiu utilizar comentários de usuários em sites de venda de aplicativos móveis disponíveis na internet. Foram escolhidas duas aplica- ções hospedadas no Google Play3_{, que pertencem à categoria Educação. Para selecionar} essas duas aplicações, foi levado em consideração, além da área correlata da aplicação, a quantidade de vezes que as aplicações foram baixadas pelos usuários e a quantidade de comentários realizados pelos usuários. Desta forma, as aplicações escolhidas foram o Sisu4 e o Gabaritar5_.

A aplicação Sisu, desenvolvida pelo Ministério da Educação - Governo Federal, visa prover uma plataforma móvel (via smartphone) para consulta de informações do programa de mesmo nome. Em linhas gerais, este sistema permite que as instituições públicas de ensino superior ofereçam vagas para candidatos participantes do Enem. A aplicação já foi baixada por mais de 100 mil usuários (entre 100.000 e 500.000 downloads) e possuía na época 5.129 comentários, tendo uma avaliação de 4.4 pontos (em uma escala de 1 a 5 pontos).

A aplicação Gabaritar, desenvolvida por uma empresa privada com sede em São Paulo, permite que o usuário organize melhor os estudos para concursos públicos disponibilizando funcionalidades para registro de horários de estudo, resoluções de simulados, acompanha- mento de desempenho, dentre outras. A aplicação também possuía um alto número de downloads (entre 100.000 e 500.000), 1.956 comentários e uma avaliação de 4 pontos.

Após a escolha das duas aplicações, foi realizada a extração dos comentários (reviews) dos usuários utilizando uma pequena aplicação em Java, criada especicamente para este m. Ao nal do processamento, a aplicação Java salvava em um arquivo em formato texto todos os comentários extraídos. Para cada aplicação (Sisu e Gabaritar) foi criado um arquivo texto. Por m, esse conteúdo extraído foi inserido na ferramenta e vinculado ao projeto criado.

A ferramenta Ideasy permitiu a seleção de palavras relevantes de acordo com cate- gorias diferentes de textos. Por exemplo: dada Fonte de Dados Interna x palavras foram extraídas, assim como, y palavras foram extraídas da Fonte de Dados Externa. Além disso, a ferramenta disponibiliza dois conjuntos de palavras, como resultado do proces- samento, classicadas como substantivos ou verbos. Neste caso, o EngR deniu que 15 palavras deveriam estar disponíveis para cada um dos conjuntos, ou seja, 15 substantivos e 15 verbos. Para isso, a ferramenta foi congurada para gerar 8 substantivos e 8 verbos

3_{https://play.google.com/store/apps/category/EDUCATION}

4_{https://play.google.com/store/apps/details?id=br.gov.mec.sisu}

com base na Fonte Interna (documentação do SUAP-EDU) e 7 substantivos e 7 verbos com base na Fonte Externa (comentários de usuários de aplicações na internet).

Após o processamento da ferramenta, o EngR analisou a lista de palavras selecionadas e propôs algumas alterações, removendo e acrescentando algumas palavras, mas mantendo a quantidade nal denida (15 palavras de cada categoria gramatical).

Finalizadas as tarefas de conguração da ferramenta e denição das palavras, o for- mulário para criação de novos requisitos foi disponibilizado. Com isso, o EngR reuniu três stakeholders para participarem do experimento em uma reunião presencial. Cada um deles possuía um notebook com acesso à ferramenta e em uma tela foi projetada as regras do experimento.

O EngR conduziu a reunião e contextualizou os participantes, informando do que se tratava a abordagem e enfatizando que o objetivo nal era criar novos requisitos (ou não, caso eles não tivessem nenhuma sugestão para as palavras selecionadas). As regras para a criação dos requisitos foram explicadas: (i) cada participante poderia sugerir até 3 (três) frases curtas que representassem assim uma nova funcionalidade para o sistema em questão; (ii) cada frase deveria ter pelo menos um substantivo e um verbo retirado de cada lista apresentada; (iii) os verbos retirados da lista poderiam ser exionados em outra forma ou tempo verbal, assim como os substantivos também poderiam ser exionados segundo grau, gênero ou número. Caso realizassem essa modicação, deveriam colocar entre parêntesis a palavra original. (iv) A frase poderia ter outros verbos e substantivos. Além disso, foi informado que os participantes poderiam conversar entre si sobre as funci- onalidades atuais do sistema, mas que não deveriam dar informações sobre o que estavam escrevendo ou quais palavras estavam utilizando.

Após as explicações e sanadas as dúvidas, os participantes foram autorizados a ler as listas de verbos e substantivos e criar os novos requisitos. Após 15 minutos essa etapa do experimento foi nalizada e cada um dos participantes criou 3 requisitos.

Uma vez terminada a tarefa de criação de novos requisitos, foi solicitado que os parti- cipantes acessassem a tela de avaliação, através da própria ferramenta e avaliassem cada um dos requisitos criados, atribuindo uma pontuação de 1 a 5, considerando os quesi- tos utilidade e originalidade. Neste momento, não poderia haver comunicação para obter maiores informações dos requisitos ou para tentar saber quem criou determinado requi- sito. Além disso, a ferramenta não permitia que os participantes avaliassem seus próprios requisitos.

Finalizada a avaliação, o EngR iniciou a discussão dos requisitos criados, projetando o resultado obtido em uma tela visível a todos e iniciando a leitura de cada um dos re- quisitos, bem como a média nal obtida por cada um deles. Neste momento, o autor da ideia era identicado e entrevistado com a nalidade de explicar melhor qual o objetivo ou necessidade daquele requisito. Esta discussão foi bem produtiva uma vez que os partici- pantes puderam detalhar melhor seus objetivos e até mesmo expandir a ideia original. No entanto, um fato interessante foi levantado: os participantes sugeriram elevar as notas in- formadas para um dos requisitos, uma vez que não haviam entendido por completo aquela sugestão. Neste caso eles preferiram atribuir a nota 3 (Neutro/Indiferente) no momento da avaliação, mas desejaram atribuir 5 (Muito útil e Muito original) após a discussão. O EngR informou que esta alteração não era possível, mas que iria registrar essa sugestão am de se analisar melhor esse passo da abordagem futuramente. Além disso, um requisito foi alterado, tendo seu escopo aumentado para um melhor aproveitamento da sugestão. Essas sugestões foram registradas em um documento textual.

O experimento foi concluído, gerando assim uma lista de novos requisitos validada e aperfeiçoada. Foi constatado uma excelente taxa de resposta, uma vez que os três par- ticipantes criaram os três requisitos solicitados dentro de um curto tempo (15 minutos). Além disso, o índice de originalidade dos requisitos cou em 78% (7 de 9 requisitos novos foram considerados originais pelos participantes). O índice de utilidade dos requisitos cou em 67% (6 de 9 requisitos novos foram considerados úteis pelos participantes). Ademais, 56% dos requisitos obtiveram pontuação média maior ou igual a 4 em ambos os quesitos (originalidade e utilidade) validando assim a técnica empregada.

A tabela 7 demonstra os requisitos criados, bem como a média obtida pela avalia- ção dos demais participantes nos quesitos originalidade e utilidade. A média geral dos requisitos quanto à utilidade cou em torno de 4,3 pontos enquanto que no quesito uti- lidade, a média geral cou em 4,2 pontos. Os substantivos e verbos destacados indicam sua presença nas lista de palavras disponibilizadas aos participantes.

Tabela 7: Resultados do experimento realizado com o SUAP-EDU.

Pontuação Média

# Requisito Original Útil

1 O aluno deve personalizar seu ambiente de aula. 3,0 3,0 2 O professor deve servir dados de aula via facebook. 4,0 3,5 3 O sistema deve dispensar o lançamento de aula diariamente para cursos EaD. 4,5 4,5 4 O sistema deverá acionar a câmera externa para fotografar o usuário durante a matrícula caso ele não

possua facebook.

3,5 5,0 5 O sistema deverá lançar automaticamente a aula do professor nos sábados letivos previamente cadastrados. 4,0 4,0 6 O sistema deverá matricular via mensagem no whatsapp. 5,0 3,5 7 Acionar solicitação online de reposição de aula. 5,0 5,0 8 Personalizar uma versão resumida do suap-edu para professores a alunos no programa android e OS/2. 5,0 5,0 9 Precisa (precisar) criar uxo de funcionamento das rotinas do SUAP com o passo a passo. 5,0 4,0 Média: 4,3 4,2

Na Tabela 8 exibimos o resumo das atividades e features selecionadas neste último experimento. Assim, é possível observar que, mais uma vez, a LPrS contempla a abor- dagem aplicada neste experimento. Além de novas variabilidades utilizadas em relação ao trabalho de Bhowmik e ao experimento anterior (Sigaa), neste novo experimento é possível constatar a utilização da atividade Aperfeiçoar Requisitos, bem como o uso de suas features. Além disso, a utilização desta atividade promoveu a melhoria de um dos requisitos propostos, além de possibilitar o melhor entendimento dos demais, dando um maior destaque para a atividade Aperfeiçoar Requisitos dentro do processo.

Tabela 8: Comparação entre atividades da LPrS e a abordagem utilizada por Pinto, R. no experimento do SUAP-EDU.

Atividades da LPrS

Proposta Feature Variabilidade Utilizada por Pinto, R. Denir Fontes de

Elementos Denir Fontes de Elementos - Textos

Documentação do software (especicações de caso de uso) e comentários de usuários em sites de venda de aplicativos móveis disponíveis na internet.

Selecionar Elementos

Classicar Elementos - Textos Classicação gramatical das palavras extraídas, considerando apenas verbos e substantivos. Forma de Seleção Automatizada através da ferramenta Ideasy. Tipo de Processamento - Texto

Extração de palavras mais relevantes nos textos selecionados; Inclusão, alteração e exclusão de palavras de forma manual realizada pelo EngR Quantidade 15 substantivos e 15 verbos.

Denir Regras de Cria- ção dos Requisitos

-

Criar de uma a três frases simples que descrevessem uma nova funcionalidade para o sistema; Utilizar pelo menos uma palavra de cada grupo (verbos e substantivos); O stakeholder poderia exionar o verbo ou mudar o substantivo em grau, gênero ou número;

Template padrão Sujeito + verbo + substantivo.

Criar Novos Requisitos

Localização dos Stakeholders Presencial. Organização e Interação entre

Stakeholders Individual.

Tipo de Stakeholder Especialistas do domínio da aplicação. Quantidade de Stakeholders 3

Avaliar Requisitos

Critério de Avaliação Considerado algo útil e original para o software pretendido.

Denir dos Avaliadores Especialistas do domínio da aplicação (os próprios participantes).

Quantidade de Avaliadores 3

Quantidade de Requisitos Todos os requisitos criados. Escala de Pontuação Escala de Likert de 5 pontos.

Aperfeiçoar Requisitos

Selecionar Requisitos Todos os requisitos criados. Técnica de Elicitação Entrevista

Participantes Especialistas do domínio da aplicação (os mesmos participantes da elicitação).

4.4 Discussão

Levando-se em conta o que foi observado, entende-se que as abordagens de elicitação de requisitos utilizando criatividade combinacional tratadas neste capítulo estão alinhadas à Linha de Processo de Software denida em nossa abordagem. Conforme é possível observar na Tabela 9 todas as abordagens relatadas exploraram fontes de elementos textuais e

processaram estas fontes em busca de palavras classicadas segundo sua função gramatical (verbos e substantivos). Além disso, em todos os casos, o Processamento de Linguagem Natural foi utilizado de forma a automatizar as tarefas de classicação de palavras e extração de tópicos relevantes.

No entanto, diversas variabilidades foram utilizadas nas demais features, dadas as di- ferentes circunstâncias de cada software. Mesmo diante das variabilidades empregadas em cada uma das abordagens, o resultado dos experimentos conseguiu extrair novos requisitos para os softwares em questão utilizando a perspectiva da criatividade combinacional. A tarefa Aperfeiçoar Requisitos, utilizada na abordagem proposta por Pinto, R. e outros, (2015) Aplicada ao Sistema SUAP, mostrou que esta é uma tarefa importante, uma vez que pode ampliar ainda mais os resultados melhorando os requisitos obtidos na tarefa Criar Novos Requisitos. A ferramenta Ideasy, apesar de ainda estar em fase de testes, também mostrou um resultado satisfatório na medida em que automatizou quase toda a abordagem, facilitando assim a coleta, validação e avaliação dos requisitos.

Feature Framework de Bhowmik: Firefox e Mylin Abordagem de Pinto, R.: Sigaa Abordagem de Pinto, R.: Suap Denir Fontes de Elementos - Textos Textos extraídos da descrição de requisitos e comentários do software. Documentação do software (Documento de visão e especicação de caso de uso). Documentação do software (especicações de caso de uso) e comentários de usuários em sites de venda de aplicativos móveis. Classicar

Elementos - Textos Classicação gramatical das palavras extraídas, considerando apenas verbos e substantivos. Selecionar

Elementos - Forma de Seleção

Automatizada através da implementação de algoritmos de PLN. Automatizada através da ferramenta Ideasy. Selecionar

Elementos - Tipo de Processamento

Extração de pares de palavras com menos familiaridade entre si

Extração de palavras mais e menos frequentes nos textos selecionados.

Extração de palavras mais relevantes nos textos selecionados; Inclusão e exclusão de palavras de forma manual. Selecionar Elementos - Quantidade

Não informado. 30 substantivos e 24 verbos. 15 substantivos e 15 verbos. Denir Regras de Criação dos Requisitos O participante deveria utilizar o verbo e o substantivo da tupla selecionada; o verbo deveria fazer sua ação sobre o substantivo.

Criar de uma a três frases simples que descrevessem uma nova funcionalidade para o sistema; Utilizar pelo menos uma palavra de cada grupo (verbos e substantivos).

Criar de uma a três frases simples que descrevessem uma nova funcionalidade para o sistema; Utilizar pelo menos uma palavra de cada grupo (verbos e substantivos).

Template padrão Sujeito + verbo + substantivo.

Feature Framework de Bhowmik: Firefox e Mylin Abordagem de Pinto, R.: Sigaa Abordagem de Pinto, R.: Suap Criar Novos Requisitos - Localização dos Stakeholders

Presencial. Remota. Presencial.

Criar Novos Requisitos - Tipo de Atividade Individual. Criar Novos Requisitos - Tipo de Stakeholder Especialista do domínio da

aplicação. Usuários da aplicação.

Especialistas do domínio da aplicação. Criar Novos Requisitos - Quantidade de Stakeholder 1 11 3 Avaliar Requisitos - Critério de Avaliação

Algo original e novo, assim

como, relevante e útil. Algo novo. Algo útil e original. Avaliar Requisitos

- Denir Avaliadores

Desenvolvedores com experiência nos softwares explorados.

Analista de Sistemas com experiência no

desenvolvimento e utilização do software explorado.

Especialistas do domínio da aplicação (os próprios participantes). Avaliar Requisitos - Quantidade de Avaliadores 29 1 3 Avaliar Requisitos - Quantidade de Requisitos

Todos os requisitos criados. Avaliar Requisitos

- Escala de Pontuação

Escala de Likert de 5 pontos.

Avaliação dos requisitos propostos, considerando-os válidos, inválidos, novos ou comuns. Escala de Likert de 5 pontos. Aperfeiçoar Requisitos - Selecionar Requisitos - - Todos os requisitos criados. Aperfeiçoar Requisitos - Técnica de Elicitação - - Entrevista Aperfeiçoar Requisitos - Participantes - - Especialistas do domínio da aplicação (os próprios participantes).

Tabela 9: Comparação entre variabilidades utilizadas nas abordagens analisadas utilizando criatividade combinacional.

Nossa LPrS buscou analisar e documentar as principais variabilidades disponíveis para utilização da criatividade combinacional na elicitação de requisitos. Variabilidades

não utilizadas nos experimentos relatados foram identicadas a m de documentar e sugerir possíveis trabalhos utilizando outras formas de combinação, de acordo com o contexto organizacional do projeto. Exemplos dessas variabilidades são os elementos do tipo imagens, vídeos e áudios. Apesar de mapear variabilidades utilizadas e não utilizadas nos experimentos analisados, nossa LPrS não tem a pretensão de listar todas, uma vez que novas características e opções podem surgir de acordo com o contexto organizacional do projeto.

No próximo capítulo iremos discutir as conclusões gerais da abordagem, trabalhos relacionados e sugestões de trabalhos futuros.

5 Conclusão

Esta dissertação propõe uma Linha de Processo de Software para elicitação de requi- sitos utilizando a perspectiva da criatividade combinacional. A LPrS foi denida e suas tarefas mapeadas e documentadas de forma a adaptar o modelo ao contexto organizacio- nal em que o software é desenvolvido. Além da LPrS, identicamos e documentamos as features encontradas durante as tarefas apresentadas. Ademais, implementamos uma fer- ramenta para automatizar parte das tarefas dos utilizadores da LPrS, de forma a facilitar ainda mais o uso de abordagens de elicitação de requisitos utilizando criatividade com- binacional. A ferramenta proposta mostrou-se satisfatória na medida em que automatiza parte das tarefas propostas pelo modelo, além de permitir a seleção de palavras relevantes dentro de um conjunto de elementos textuais denidos.

Para avaliar a Linha de Processo de Software proposta, contrastamos a LPrS com as características dos experimentos da literatura que realizaram elicitação de requisitos utilizando criatividade combinacional. Com isso validamos as tarefas e features modeladas na LPrS. Como foi possível perceber no Capítulo 4, os experimentos realizados, que pre- cedem a criação da LPrS, tratam da criação de novos requisitos através da combinação de pares de palavras. No entanto, nosso mapeamento vai além destes elementos e documenta outras possibilidades de combinações a m de auxiliar as equipes de desenvolvimento de software de acordo com seu contexto.

Na seção 5.1 apresentamos as contribuições desta dissertação, na seção 5.2 compara- mos os trabalhos relacionados ao tema com a nossa abordagem e na seção 5.3 os trabalhos futuros.

5.1 Contribuições

A principal contribuição desta pesquisa é a denição de uma Linha de Processo de Software para técnicas de elicitação de requisitos utilizando criatividade combinacional. A LPrS apresentada, contribui para a área de Engenharia de Software uma vez que ma-

peia as principais tarefas de técnicas de elicitação de requisitos que utiliza a criatividade combinacional. Além disso, mapeia também suas variabilidades, com o propósito de do- cumentar características relevantes a serem planejadas pelo Engenheiro de Requisitos, facilitando assim o uso deste tipo de técnica.

Da mesma maneira, a ferramenta Ideasy criada para automatizar uma instância da Linha de Processo de Software proposta, também pode ser caracterizada como uma contribuição deste trabalho uma vez que ela facilita a realização das tarefas identicadas pela abordagem.

Uma terceira contribuição é a classicação e comparação de diferentes abordagens de criatividade combinacional. Constatamos que mesmo variando diversas característi- cas modeladas na LPrS foi possível levantar requisitos criativos. Assim, não existe uma fórmula exata para selecionar palavras ou mesmo uma fonte de elementos especíca que garanta palavras essenciais para geração de requisitos inovadores. O conjunto de fatores combinados bem como a disposição da equipe de desenvolvimento, é responsável pela criação de requisitos inesperados.