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.

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.

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.

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