SciELO - Scientific Electronic Library Online

 
 número20Prácticas adoptadas de la ISO/IEC 20000 en pequeñas organizaciones desarrolladoras de software que ofrecen mesa de servicios: Un estudio de casoMecanismo de controlo para a frente orientado ao risco como garantia da conformidade da execução de processos de negócio índice de autoresíndice de materiabúsqueda de artículos
Home Pagelista alfabética de revistas  

Servicios Personalizados

Revista

Articulo

Indicadores

Links relacionados

  • No hay articulos similaresSimilares en SciELO

Compartir


RISTI - Revista Ibérica de Sistemas e Tecnologias de Informação

versión impresa ISSN 1646-9895

RISTI  no.20 Porto dic. 2016

https://doi.org/10.17013/risti.20.18-33 

ARTÍCULOS

Uma estratégia baseada em aquisição de conhecimento para o gerenciamento de riscos nos requisitos em um desenvolvimento XP distribuído

A strategy based on knowledge acquisition for management of requirements risks on distributed XP development

Glaucia Schnoeller dos Santos 1, Ivan Luiz Marques Ricarte 1

 

1 Faculdade de Tecnologia, Universidade Estadual de Campinas (UNICAMP), Limeira, Brasil. E-mail: glaucia@pos.ft.unicamp.br , ricarte@unicamp.br

 

RESUMO

Este estudo apresenta uma estratégia baseada em aquisição de conhecimento processual para gerenciar riscos de ausência de informação e falta de compreensão dos requisitos de software na aplicação de Extreme Programming (XP) em desenvolvimento distribuído de software (DDS). Para a avaliação dessa estratégia, um estudo de caso foi conduzido com participação de especialistas da área de análise de sistemas. O resultado desse estudo mostra que, por meio de regras semânticas, o processo gera um conhecimento estruturado e globalizado, que expõe clareza nos requisitos, identifica e extrai informações ausentes.

Palavras-chave: Aquisição de conhecimento; Metodologias ágeis; Engenharia de requisitos; Gestão de riscos.

 

ABSTRACT

This study presents a strategy based on a process for the acquisition of knowledge to manage risks related to lack of information and understanding of requirements, when applying Extreme Programming (XP) in distributed software development (DSD). For assessing this strategy, a case study was conducted with experts in systems analysis. Results of this study show that, through semantic rules, the process generates a structured and globalized knowledge, exposing clarity in the requirement, besides being able to identify and extract missing information.

Keywords: Knowledge acquisition; Agile methodologies; Requirements engineering; Risk management.

 

1. Introdução

A aplicação de métodos ágeis em projetos de desenvolvimento distribuído de software (DDS) (Alzoubi, Gill & Al-Ani, 2016) está associada a benefícios como redução de custo e tempo no desenvolvimento, facilidade de recrutamento de desenvolvedores qualificados e compartilhamento das boas práticas (Ågerfalk et al., 2008; Kimble et al., 2016). Uma das metodologias aplicadas nesse cenário é a Extreme Programming (XP), que foca em práticas para o desenvolvimento de sistemas para acompanhar mudanças frequentes e entregar um sistema de qualidade (Sadiq & Hassan, 2014).

XP preconiza a adoção de equipes pequenas, mas é possível sua aplicação em cenários co-locados em DDS. Ganesh e Thangasamy (2011) constataram flexibilidade e economia de custos em projetos; Hildebrand et al. (2008) e Abdullah e Abdelsatir (2013) aplicaram XP em projetos distribuídos de larga escala. Entretanto, a aplicação de XP nesses cenários expõe o projeto a riscos na engenharia de requisitos (Shrivastava & Rathod, 2014), principalmente na comunicação das estórias do usuário, como a ausência de informação e falta de compreensão dos requisitos, potencialmente agravados por problemas semânticos.

Neste trabalho, explora-se a aplicação de um processo para a aquisição de conhecimento processual baseado em regras semânticas para mitigar riscos na comunicação dos requisitos. Esse processo simplifica a extração do conhecimento, além de facilitar a leitura, expor clareza nas informações e permitir a aplicação em diversas áreas de conhecimento, uma vez que não exige conhecimento prévio do negócio (Vasques et al., 2016). Para avaliar as contribuições dessa estratégia na mitigação de riscos relacionados à ausência de informação e à falta de compreensão nos requisitos com a metodologia ágil XP em DDS, um estudo de caso foi conduzido.

Este artigo apresenta uma revisão de trabalhos relacionados com riscos na engenharia de requisitos e estratégias de gerenciamento, seguida pela proposta da estratégia para o gerenciamento de riscos semânticos e a metodologia aplicada. Por fim, apresenta o estudo de caso desenvolvido, seguido por discussão dos achados.

 

2. Revisão de Literatura

Os estudos relacionados foram divididos em duas categorias: riscos na engenharia de requisitos na aplicação de XP no desenvolvimento distribuído e estratégias para o gerenciamento de riscos.

2.1. Riscos nos requisitos da XP em DDS

As práticas de XP são indicadas para equipes co-locadas, juntamente com um especialista do negócio. No entanto, há interesse no uso da metodologia ágil em cenários de desenvolvimento distribuído (Alzoubi, Gill & Al-Ani, 2016). XP visa suprir as lacunas de projetos de desenvolvimento de sistemas, desenvolvidos por equipes pequenas (2 a 10 desenvolvedores), que enfrentam requisitos incertos e estão em constante alteração. Já DDS tem como princípio a adoção de processos colaborativos: as partes interessadas são formadas por uma empresa (cliente), a qual negocia o desenvolvimento de software total ou em partes com outra empresa prestadora de serviços (fornecedor) (Niazi & Mahmood, 2013).

Alguns estudos investigaram a aplicação de XP no cenário distribuído. Kircher et al. (2001) adaptaram XP para desenvolvimento de projetos com a equipe distribuída. Paasivaara e Lassenius (2006) discutem benefícios e desafios dessa adaptação com base em casos reais. Hildenbrand et al. (2008) analisam como XP pode ser empregada em projetos distribuídos, gerenciados por grandes empresas, e identificam práticas a utilizar nesse contexto. Abdullah e Abdelsatir (2013), nesse mesmo contexto, argumentam que há aumento de interação humana entre a equipe, o que contribui para geração de novas ideias e eficaz implementação do sistema. Por outro lado, Shrivastava & Rathod (2014) evidenciam que a aplicação de XP em DDS pode trazer riscos à engenharia de requisitos. O projeto enfrenta desafios nas diferenças das distâncias geográficas, fusos horários e diferenças culturais (línguas e contextos organizacionais) (Jain & Suman, 2015) e torna mais difícil a comunicação de requisitos (Qahtani, Wills & Gravell, 2013).

Em XP, requisitos são expressos por estórias informais, escritas em linguagem natural pelo especialista do negócio e registradas em cartões, mas essa linguagem agrava deficiências na comunicação das estórias do usuário. Akbar, Haris e Naeem (2008), ao relatar o risco da ausência de informações nos requisitos no desenvolvimento distribuído e ágil, propõem questões a serem discutidas com o especialista do negócio, porém sem indicar como gerenciar esse risco.

2.2. Estratégias de gerenciamento de riscos semânticos na comunicação

A comunicação dos requisitos entre o especialista do negócio e desenvolvedores pode ser prejudicada pelas diferenças culturais entre os envolvidos, com lacunas semânticas e consequente perda de informação. Wanderley e Silveira (2012) propõem uma abordagem interativa para modelar os requisitos em metodologias ágeis com modelos mentais do domínio, que são transcritos para um modelo conceitual. Essa abordagem gera um vocabulário com uma linguagem comum para ambas as partes. Já Wanderley et al. (2014) propõem um framework para modelar estórias do usuário com uma linguagem visual fundamentada em mapas mentais.

A escrita dos requisitos pode apontar problemas, como dependências ocultas, inconsistências, ambiguidade e falta de padrão. Lucassen et al. (2015), com base em um conjunto de estórias reais, apresentam 14 critérios para melhorar a qualidade nas estórias do usuário. Um protótipo desenvolvido para analisar e expor erros nos requisitos identificou baixa qualidade e pontos de melhorias, embora sem apontar como resolver os problemas identificados. Rodríguez e Caro (2012) propõem um método para modelagem de processos do negócio, com ênfase na qualidade dos dados, e Vicente (2012) apresenta a utilização de dinâmica de sistemas para a modelagem semântica do negócio no processo de desenvolvimento de software.

Perda de informações e falta de compreensão dos requisitos são tipos de riscos semânticos. O processo Verbka (Vasques et al., 2016) visa reduzir problemas inerentes à utilização da linguagem natural, ao sistematizar, com base em regras de semântica verbal, a aquisição de conhecimento processual representado textualmente. Verbka fragmenta o texto em componentes linguísticas, que são reestruturadas em conceitos e relações, e produzem declarações proposicionais, modeladas semanticamente por tabelas e mapas conceituais causais, oferecendo uma visão geral do processo causal entre os conceitos.

 

3. Estratégia para gerenciamento de riscos nos requisitos da equipe XP distribuída

Este estudo parte da premissa que a extração do conhecimento tácito de requisitos pode contribuir para gerenciar riscos de ausência de informação e falta de clareza na especificação de requisitos. Propõe-se aplicar o processo Verbka para gerenciar riscos na comunicação das estórias do usuário de equipes XP em DDS, com: (a) tratamento do conteúdo semântico das estórias do usuário; (b) extração de conhecimento tácito; (c) estruturação do conhecimento extraído e (d) modelagem semântica das estórias do usuário. A aplicação do processo Verbka, ao modelar o conhecimento nas estórias do usuário, pode reduzir viéses na interpretação dos requisitos e, assim, mitigar os riscos semânticos associados.

Considere como exemplo um requisito escrito por um especialista do negócio: Como administrador cadastro, altero e excluo funcionário com número de matrícula, nome e departamento, para controle de acesso. O primeiro passo é preparar o texto, com refinamento textual, transcrição para voz ativa e explicitação de todos os verbos no tempo presente. Sujeitos indeterminados devem ser explicitados, termos acessórios são eliminados e orações coordenadas são desmembradas. Desse passo, resultam oito orações: Administrador cadastra funcionário; Administrador consulta funcionário;. Administrador altera funcionário; Administrador exclui funcionário; Funcionário tem número de matrícula; Funcionário tem nome; Funcionário tem departamento; Administrador controla acesso de funcionário.

A seleção dos verbos contribui para a extração dos sintagmas. As sentenças foram fragmentadas em dois blocos, sintagma nominal sujeito (NSubj) – composto por substantivo e eventuais adjetivos – e sintagma verbal (SV) – composto por verbo e complementos. Para identificar esses elementos, duas questões são direcionadas ao verbo: Quem e O quê. Por exemplo, na primeira oração, administrador cadastra funcionário, o verbo é cadastrar. Para a pergunta quem cadastra, a resposta é administrador; para a pergunta cadastra o quê, a resposta é funcionário. Após a análise ser aplicada a todas as orações, resulta o conhecimento codificado em proposições sintetizado na Tabela 1.

 

 

A seguir, o sintagma verbal é complementado com base nas questões aplicadas ao verbo: O quê, Para quem, Onde, Quando e Quanto. Assim, a cada conceito é atribuída uma função semântica, com valores relativos às respostas obtidas; questões sem respostas têm os campos em branco. Essa etapa permite identificar informações ausentes e possibilita a inserção de inferências para relações implícitas. No exemplo, o administrador não tinha sua função definida, o que levantou dúvidas como: Administrador do negócio? Administrador de informação? Por meio das respostas, foi possível identificar e explicitar essa informação, conforme apresentado na Tabela 2. As questões Como e Por quê são respondidas após a modelagem das proposições, pois fornecem uma visão completa do requisito. Após esses passos, se houver conceitos sinônimos na tabela, o termo mais representativo é selecionado.

 

 

Com base nessa tabela, proposições podem ser modeladas com seus conceitos e relações. Para isso, cada coluna da tabela é percorrida e os conceitos são atribuídos a caixas, relacionadas por setas correspondentes a verbos e extensões verbais. As setas seguem a ordem das colunas, de maneira que complementos são ligados ao conceito anterior. Esse processo é realizado para cada linha da tabela de protopapéis. As inferências (de relações não explícitas) são destacadas com uma seta tracejada.

O fluxo de energia entre os conceitos é diferenciado pelo tipo de associação, o que permite uma visão complexa do requisito. Os tipos de associação são: associações por verbos de ação (transitivos diretos e indiretos), que representam o relacionamento em que um conceito afeta outro conceito e altera seu estado de energia; associações por verbos de ação (reflexivos, intransitivos e também transitivos de percepção e psicológicos), que indicam conceitos que afetam a si próprios; e associações por verbos de ligação são conceitos estáticos, em que não se encontra um fluxo de energia. A Figura 1 mostra o modelo resultante da aplicação dessa etapa ao exemplo, que foi validado por um especialista do negócio e usuários.

 

 

4. Metodologia

Para responder à questão de pesquisa, quais as contribuições do processo de aquisição de conhecimento para o gerenciamento de riscos de ausência de informação e falta de compreensão nos requisitos para a equipe XP em DDS, adotou-se a abordagem qualitativa de estudo de caso. A população do estudo é composta por desenvolvedores de software, com participantes selecionados por amostragem de conveniência por indicação de profissionais da área de desenvolvimento de software. O critério para a inclusão na pesquisa foi a experiência em outros projetos de desenvolvimento de sistemas, preferencialmente no tipo de projeto de software que se buscava para este estudo (sistema comercial), por seu foco na interação com o cliente.

Foram desenvolvidos dois roteiros de entrevistas para a coleta dos dados, disponibilizados online por meio da ferramenta de formulários Google. A primeira entrevista foi realizada antes da aplicação do Verbka e teve como finalidade investigar questões relacionadas à compreensão de requisitos, requisitos vagos e ausência de informações. A segunda entrevista, após a aplicação do Verbka, levantou as contribuições da estratégia para o gerenciamento de riscos nos requisitos.

As respostas às entrevistas foram analisadas pelo método da análise de conteúdo (Silva & Fossá, 2015), associando rótulos (categorias) a fragmentos das respostas. As etapas realizadas para o tratamento dos dados foram: leitura geral dos questionários coletados; codificação para a construção de temas para a análise, utilizando o recorte de unidades de registro (em frases); estabelecimento de categorias temáticas das unidades de registro; revisão de temas; definição de temas; agrupamento temático das unidades de registro; e produção do relatório qualitativo. Durante a etapa de codificação, a ferramenta QDA Miner1 foi utilizada para a seleção de unidades de registro. Após essa etapa, a ferramenta XMind2 foi aplicada para organizar o mapeamento dos temas e subtemas. Como resultado dessa análise, foi extraída uma ampla descrição de temas específicos dentro dos dados coletados.

 

5. Estudo de Caso

O objetivo da equipe foi desenvolver um sistema comercial para gestão de estoque de produtos, para substituir um sistema que não acompanhou a evolução tecnológica do estoque, tornando-se obsoleto e não atendendo aos negócios da empresa. O estudo de caso teve a duração de um mês. A equipe XP, distribuída geograficamente, foi composta por três especialistas em análise e desenvolvimento de sistemas, um tamanho de amostra adequado para esse tipo de estudo.

Para evidenciar as práticas da XP em DDS, todos os processos do desenvolvimento foram realizados remotamente. Um curto treinamento sobre ferramentas de apoio ao DDS foi oferecido aos participantes antes do início do desenvolvimento. Entre essas ferramentas, Skype teve grande aceitação para a programação em pares, pelo fácil acesso para os envolvidos e recursos como mensagem (chat) e compartilhamento de tela. O gerenciamento do projeto utilizou o Mingle3, uma ferramenta virtual (gratuita para até 5 integrantes) aplicável a projetos ágeis que oferece funções como a criação e o controle de cartões de estórias; acompanhamento de releases, tarefas e defeitos; e priorização de requisitos. Possibilita, na construção e organização dos cartões, a inserção de anexos, comentários e gráficos, o que facilita a colaboração na equipe.

O sistema foi desenvolvido em C#, linguagem de conhecimento comum entre os participantes do estudo, utilizando a plataforma Visual Studio Community 2015, com Visual Studio Team Services4. Essa ferramenta, gratuita para até cinco usuários, é baseada em nuvem e fornece um conjunto de recursos para equipes ágeis. O código do sistema foi armazenado e compartilhado em repositório privado com todos os envolvidos do projeto, com controle de versão distribuído, gerenciamento de mudanças, plano de testes, integração contínua e chat.

Para a geração dos mapas conceituais, foi utilizada a ferramenta gratuita CmapTool5. A aplicação das tabelas de protopapéis seguiu os princípios da ferramenta 5W2H, com um checklist de cinco questões iniciadas (em inglês) com W (what, why, when, where e who) e duas com H (how e how much).

5.2. Processo convencional da XP

Nesta etapa do estudo, o processo convencional da XP foi aplicado para a elicitação, análise e validação dos requisitos. Todas as definições e negociações das estórias do usuário foram acompanhadas remotamente. Na primeira reunião com o especialista do negócio, realizada por Skype, foram compartilhadas as funcionalidades das ferramentas utilizadas no projeto. Escopo do projeto e planejamento do lançamento da primeira iteração das estórias foram discutidos em outras reuniões, com as estórias do usuário escritas pelo especialista do negócio em cartões criados diretamente no software Mingle (Figura 2). Por problemas de incompatibilidade de horários dos membros da equipe, esses cartões foram discutidos por meio de troca de mensagens e muitas dúvidas surgiram durante o processo de análise dos requisitos associados.

 

 

Foram realizadas quatro iterações para a priorização dos requisitos, pois algumas estórias dependiam de funcionalidades ainda não implementadas. A priorização foi atribuída no Mingle, com o recurso do mural de cartões, categorizados em novos, em andamento, testes e finalizados. Pela mesma ferramenta, os envolvidos no projeto puderam inserir comentários e realizar alterações, quando necessário. Foram criados 11 cartões de estória do usuário.

5.3. Processo de Aquisição de Conhecimento

Nesta etapa do desenvolvimento, além dos recursos e práticas utilizadas na etapa anterior, foi implantado o processo Verbka nas estórias do usuário para gerenciar os riscos de falta de informação e compreensão dos requisitos. Para isso, um dos autores (GSS) gerenciou o projeto de desenvolvimento e aplicou as regras semânticas nas estórias do usuário.

A tabela de protopapéis e o mapa conceitual causal, criados no processo, puderam ser incluídos nos cartões de estórias no Mingle. Isso permitiu que a equipe tivesse acesso ao conhecimento extraído, modelado e estruturado com a aplicação do processo pelo especialista do negócio no mesmo cartão de estória. A Figura 3 ilustra um exemplo de cartão para o requisito de cadastro, alteração e exclusão de funcionário, com a tabela e o mapa conceitual causal com a junção de todos os requisitos do sistema. Esse cartão oferece uma visão completa de funcionalidades e permite o rastreamento e a identificação de dependências entre requisitos.

 

 

 

6. Resultados

Os dados coletados no estudo de caso são apresentados em dois blocos, o processo convencional da XP e o processo de aquisição de conhecimento, com cada bloco organizado em três tópicos: processos do negócio, compreensão dos requisitos e detalhamento dos requisitos.

6.1. Processo convencional da XP

Processos do negócio

A aplicação da linguagem natural na escrita das estórias do usuário introduziu um formato informal e técnico dos processos exercidos no negócio. Apresentou ainda uma falta de padronização de conceitos utilizados nos requisitos. Isso prejudicou a compreensão dos desenvolvedores em relação aos processos do negócio, como mencionado em um dos questionários:

Na análise de requisitos houve uma dificuldade na compreensão das sentenças, pois as mesmas foram escritas de uma forma informal e o modo como elas foram expostas parecia que emissor e receptor conheciam todos os processos e particularidades da organização. Além disso, empregaram-se diferentes termos para designar a mesma coisa.

Outro risco proveniente desse problema foi a ambiguidade nos requisitos. Algumas dúvidas levantadas pelos participantes apresentaram essa ocorrência: “No lugar do termo ‘justamente’ não seria a palavra ‘juntamente’? Isso provoca diferentes interpretações”; “A data de entrega corresponderia à data da realização do pedido? Há uma dupla interpretação”.

A ausência de informações sobre o negócio foi um dos principais riscos identificados, como citado por um dos desenvolvedores: “A principal dificuldade encontrada consistiu na falta de informações referentes à organização e seu processo de trabalho”. O tempo gasto e o esforço dos desenvolvedores para o entendimento das estórias do usuário e dos processos do negócio foram considerados maiores, pela necessidade de repetir diversas vezes a leitura desses requisitos. Essa deficiência foi mencionada em um dos questionários: “Foi necessário ler todas as histórias mais de uma vez para entender a base dos processos realizados pelo cliente”. À vista disso, ficou evidente a necessidade da aplicação de estratégias para a modelagem desses processos de negócio, com a finalidade de reduzir o tempo gasto para a compreensão dos requisitos. Essa observação foi sugerida por um dos participantes: “Se as histórias fossem descritas como a explicar ou exemplificar os processos a um leigo, a análise dos requisitos poderia ser menos demorada e o escopo poderia ser laborado e aprovado mais rapidamente”.

Com esse cenário, o projeto requeria uma comunicação frequente e eficiente para a validação dos requisitos. No entanto, os envolvidos enfrentaram mais desafios, pelo motivo da equipe e o especialista do negócio estarem distribuídos geograficamente.

Compreensão dos requisitos

Uma das principais dificuldades dos desenvolvedores nas etapas de análise e implantação das estórias do usuário foi a falta de compreensão dos requisitos. De acordo com os participantes, as estórias escritas pelo usuário apresentaram deficiências, como: “Todos os requisitos apresentaram alguma imprecisão”. Apesar das sugestões apresentadas à equipe para a aplicação de um padrão para a criação dos cartões, sem o acompanhamento presencial para a elaboração dos cartões nem todos os critérios sugeridos foram adotados. Assim, os participantes se depararam com inconsistências no padrão das estórias do usuário, como a atribuição de duas estórias no mesmo cartão: “Colocou-se dois requisitos diferentes em um só”.

Foram identificados requisitos vagos, provenientes da falta de clareza, que limitaram a implantação das estórias: “Não há informações suficientes para que seja definido como requisito”. Nesse contexto, muitos questionamentos em relação à compreensão dos atores do sistema foram manifestados: “Administrador do quê?”, “Existem outros tipos de administradores?”, “Está faltando o tipo de usuário (para definir quais interfaces o usuário poderá acessar)”.

Houve questões sobre responsabilidades de cada ator: “Quais são os tipos de pedido que são de responsabilidade do almoxarife? E do departamento de compras?” “Somente o almoxarife cadastra um novo produto?” “Somente o departamento de almoxarife pode cadastrar fornecedor?” “A que tipo de informações o departamento de almoxarife deverá ter acesso?” Dificuldades foram associadas ao tipo de relacionamento entre atores: “Produto pode ter mais de um fornecedor vinculado?”.

Apesar da necessidade da independência, as estórias do usuário estavam relacionadas e alguns desafios surgiram para explicitar essas dependências: “A execução desta atividade depende de algum parâmetro, como por exemplo, a solicitação de um novo pedido de compra?” “É necessário algum aviso prévio, antes de receber definitivamente algum pedido?” Nesse sentido, outras dificuldades foram encontradas, como a ausência de relações do comportamento do requisito: “Os requisitos estão sem comportamento. Ex. (entrada, saída e estado).” “Não é possível definir qual é o comportamento do requisito”.

A falta de compreensão dos requisitos e os seus relacionamentos implicam em riscos de permissões de acesso para o controle de segurança do sistema. Foram também encontradas dificuldades para rastreamento desses requisitos.

Detalhamento dos requisitos

A falta de informação nos requisitos, tal como funcionalidades que não foram identificadas na implantação da história, teve grande impacto no desenvolvimento e afetou a usabilidade do sistema. Por exemplo, na geração de relatórios pelo sistema: “A geração desse relatório deve ser exibido em tela e/ou gerado em .pdf?” “O sistema deve possibilitar a opção de ‘imprimir’ o relatório?”.

Algumas ausências de atributos do sistema foram identificadas. No controle de acesso dos funcionários não foi esclarecida a atribuição de senhas para os funcionários. Outra situação foi o cadastramento de novas peças, que não previa a quantidade dos produtos: “Requisito de cadastro de novas peças: deve possuir um campo de quantidade atual?”. Por esse motivo, algumas funcionalidades que requeriam essas informações foram afetadas, demandando tempo para reparos.

6.2. Processo de aquisição de conhecimento

Na segunda etapa do desenvolvimento do sistema, com aplicação da estratégia proposta neste estudo, o objetivo foi identificar contribuições para o gerenciamento dos riscos expostos na primeira etapa do desenvolvimento.

Processos do negócio

O processo Verbka proporcionou uma modelagem e globalização do conhecimento referente ao negócio: “A aplicação de um processo de aquisição de conhecimento permitiu uma visão mais detalhada e ao mesmo tempo generalizada, permitindo uma compreensão global dos requisitos e do sistema”. O processo contribuiu para o levantamento de requisitos, fornecendo a construção de cenários: “Com o auxílio das tabelas a interpretação dos requisitos fica mais dinâmica, facilitando o levantamento dos requisitos e com isso a elaboração dos requisitos”. Durante o desenvolvimento do sistema, algumas falhas de compreensão nesta etapa foram reduzidas: “a ferramenta ajudou a diminuir algumas brechas do levantamento de requisitos, deixando mais visível o que cada requisito deve gerar”. Nesse sentido, reduziu-se o tempo desta etapa para a compreensão dos processos aplicados pelo negócio.

A padronização do conhecimento forneceu uma linguagem comum para as partes envolvidas no projeto e facilitou a adição ou modificações de requisitos: “Com o auxílio da tabela de protopapéis, fica mais fácil a inserção de novas informações, como, atributos, procedimentos, dados e comportamentos.”

Compreensão dos requisitos

A extração do conhecimento tácito oferece uma estratégia para compreensão dos requisitos do sistema. O principal auxílio foi a redução de falta de clareza: “A partir do momento que existe um gráfico e/ou uma tabela, a compreensão dos requisitos fica mais clara”. Nesse contexto, ela permitiu a identificação dos atores do sistema e suas responsabilidades, como observado: “Com a ferramenta a visualização dos requisitos ficou mais clara, detalhando todos os atributos, revelando os responsáveis pela operação e definindo o tipo do comportamento do requisito”.

A geração do conhecimento estruturado e sistematizado das estórias do usuário permitiu a redução de dúvidas durante a análise: “Ela permite antecipar informações evitando dúvidas que podem surgir em fases posteriores”. Da mesma maneira, abrange a identificação de requisitos dependentes: “Com a aplicação do processo de aquisição de conhecimento, fica mais fácil analisar as dependências do requisito.” Fornece ainda o rastreamento desses requisitos: “O mapa conceitual ajuda a direcionar a função do requisito, revelando todo o caminho desse requisito”.

Detalhamento dos requisitos

A informação referente a atributos e funcionalidades do sistema foi complementada: “A visualização dos requisitos ficou mais clara, detalhando todos os atributos”. Com isso, foram reduzidos riscos relativos à ausência de informação, pois “os requisitos ficam mais detalhados”. No entanto, como mencionado pelos desenvolvedores, o excesso de informação nas tabelas ou no mapa conceitual causal pode comprometer a compreensão: “O gráfico e/ou a tabela deve ser clara. O excesso de informações no gráfico pode resultar em uma má compreensão das informações”. Ou seja, materiais extensos devem ser resumidos para melhorar a eficiência do processo.

A padronização dos conceitos reduziu o viés de interpretação e facilitou a comunicação dos requisitos. Como observou um participante, quando questionado se o processo contribuiu para o preenchimento de informações ausentes: “Sim, a partir da utilização de ‘palavras-chaves’, as quais complementam uma informação”.

 

7. Discussão

A linguagem natural fornece rápidos feedbacks para a equipe; no entanto, podem ocorrer várias falhas de comunicação devido ao caráter subjetivo da compreensão linguística. Há na literatura trabalhos que utilizam estratégias para o gerenciamento de riscos semânticos, com modelagens dos processos do negócio e identificação de viés na comunicação do texto, sem, contudo, reparar as falhas decorrentes desse problema. O diferencial deste estudo é a aplicação de uma estratégia de aquisição de conhecimento para gerenciar esses riscos em um cenário de desenvolvimento ágil e distribuído.

Na primeira etapa do desenvolvimento do estudo de caso, estórias de usuários foram utilizadas na extração de requisitos no processo convencional da XP. Devido à qualidade na produção do texto em um cenário de desenvolvimento distribuído, problemas semânticos foram agravados. Sem a estruturação do conhecimento, notou-se uma ausência de detalhes semânticos que levou à falta de compreensão. Esses riscos foram reduzidos na segunda etapa do desenvolvimento, quando foi aplicado o processo Verbka. A equipe teve acesso à modelagem semântica das estórias do usuário, com uma visão geral dos processos do negócio (como a identificação, atuação e relacionamentos causais de cada ator no sistema), e isso diminuiu o impacto de falta de compreensão decorrente do fato de a equipe estar distribuída geograficamente. Inferências puderam explicitar o conhecimento tácito presente nos requisitos ou detectar a ausência de informação. O processo contribuiu ainda para a compreensão do especialista do negócio, que pode avaliar a extração do seu próprio conhecimento. Em relação ao nível de granularidade do texto, as estórias curtas facilitaram a extração do conhecimento, mas a informação textual não pode ser o único meio para extrair todos os dados importantes das estórias do usuário. Além disso, pelo processo não ser automatizado, houve esforço humano para extração do conhecimento pelos desenvolvedores do projeto, sendo que apenas um integrante da equipe pode coordenar essa aplicação.

Com o intuito de garantir a confiabilidade dos resultados obtidos neste estudo, os fatores previsíveis de ameaças internas e externas foram analisados. A validade interna investiga as relações causais dos componentes de estudo (Bleijenbergh, Korzilius & Verschuren, 2011). Para reduzir o risco de influenciar os participantes, foram aplicadas questões abertas nos questionários. A validade externa refere-se à capacidade de generalizar os resultados da pesquisa para outros casos. Na metodologia de estudo de caso, o propósito é prover a generalização analítica para resultados que são relevantes a casos com caraterísticas similares (Runeson & Höst, 2009). Assim, os resultados desta pesquisa podem ser aplicados a pequenas equipes de desenvolvimento distribuído de software que adotam a linguagem natural como principal fonte de informação.

 

8. Conclusão

Este estudo analisou o desenvolvimento distribuído de um sistema comercial com a aplicação da metodologia de desenvolvimento de software XP. Foi possível constatar que, mesmo em um sistema simples, problemas semânticos como a ausência de informação e falta de compreensão nos textos expõem riscos na engenharia de requisitos. Esses riscos foram controlados com a utilização da estratégia proposta neste estudo que, por meio de um processo sistemático para extração de conhecimento, proporcionou a estruturação e facilitou a comunicação global da informação presente nas estórias do usuário.

A principal contribuição desta pesquisa foi demonstrar como o processo de extração de conhecimento Verbka pode ser utilizado para gerenciar os riscos na comunicação da equipe XP distribuída, reduzindo problemas inerentes ao uso da linguagem natural em estórias do usuário. Observou-se, para essa estratégia de desenvolvimento, uma melhora na comunicação de uma equipe pequena com o especialista do negócio e a geração de novas ideias no decorrer do projeto de um sistema comercial. No entanto, a aplicabilidade dessa estratégia a projetos de outra natureza, com equipes maiores ou outras estratégias de desenvolvimento deve ser alvo de trabalhos futuros. Nesse sentido, a automatização (total ou parcial) do processo Verbka, com o apoio de técnicas de processamento de linguagem natural e ferramentas de modelagem de conhecimento, como o uso de ontologias, é essencial para que essa estratégia possa ser disseminada em outros contextos.

 

Referências

Abdullah, E., & Abdelsatir, E.-T. B. (2013). Extreme programming applied in a large-scale distributed system. Paper presented at the International Conference on Computing, Electrical and Electronic Engineering (pp. 442–446), Khartoum, Sudan. doi:10.1109/ICCEEE.2013.6633979.         [ Links ]

Ågerfalk, P. J., Fitzgerald, B., Holmström Olsson, H., & Conchúir, E. Ó. (2008). Benefits of global software development: The known and unknown. Paper presented at Making Globally Distributed Software Development a Success Story (pp. 1–9), Leipzig, Germany. doi:10.1007/978-3-540-79588-9_1.         [ Links ]

Akbar, R., Haris, M., & Naeem, M. (2008). Requirement gathering and tracking process for distributed agile based development. Paper presented at the WSEAS International Conference on Applied Informatics and Communications (pp. 429–436), Rhodes, Greece.         [ Links ]

Alzoubi, Y. I., Gill, A. Q., & Al-Ani, A. (2016). Empirical studies of geographically distributed agile development communication challenges: A systematic review. Information & Management, 53(1), 22–37. doi:10.1016/j.im.2015.08.003.         [ Links ]

Bleijenbergh, I., Korzilius, H., & Verschuren, P. (2011). Methodological criteria for the internal validity and utility of practice oriented research. Quality & Quantity, 45(1), 145–156. doi:10.1007/s11135-010-9361-5.         [ Links ]

Ganesh, N., & Thangasamy, S. (2011). Issues identified in the software process due to barriers found during eliciting requirements on agile software projects: Insights from India. International Journal of Computer Applications, 16(5), 7–12. doi:10.5120/2011-2713.         [ Links ]

 

Recebido/Submission: 03/07/2016

Aceitação/Acceptance: 10/11/2016

 

Notas

1 http://provalisresearch.com/products/qualitative-data-analysis-software/freeware/

2 http://www.xmind.net/

3 https://www.thoughtworks.com/mingle/

4 https://www.visualstudio.com/pt-br/products/visual-studio-team-services-vs.aspx

5 http://cmap.ihmc.us/cmaptools/

Creative Commons License Todo el contenido de esta revista, excepto dónde está identificado, está bajo una Licencia Creative Commons