Estude fácil! Tem muito documento disponível na Docsity
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
Prepare-se para as provas
Estude fácil! Tem muito documento disponível na Docsity
Prepare-se para as provas com trabalhos de outros alunos como você, aqui na Docsity
Encontra documentos específicos para os exames da tua universidade
Prepare-se com as videoaulas e exercícios resolvidos criados a partir da grade da sua Universidade
Responda perguntas de provas passadas e avalie sua preparação.
Ganhe pontos para baixar
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
O Behavior-Driven Development (BDD) centra-se na colaboração e descoberta do com- portamento do sistema incorporando a definição de funcionalidades por meio de features baseadas em especificação por exemplos, o denominado Specification by Example.
Tipologia: Esquemas
1 / 97
Esta página não é visível na pré-visualização
Não perca as partes importantes!
Instituto de Ciências Exatas Departamento de Ciência da Computação
Dissertação apresentada como requisito parcial para conclusão do Mestrado Profissional em Computação Aplicada
Orientador Prof. Dr. Genaina Nunes Rodrigues
Ficha catalográfica elaborada automaticamente, com os dados fornecidos pelo(a) autor(a)
Ba Barros Leal, Fábio paraUma o^ abordagemdesenvolvimento^ usando ágilfeatures de software^ BDD^ e^ Modelo / Fábio^ de BarrosObjetivos Leal; orientador Genaina Nunes Rodrigues. -- Brasília, 2019. 84 p. Dissertação (Mestrado - Mestrado Profissional em Computação Aplicada) -- Universidade de Brasília, 2019.
por1. Comportamento.^ Engenharia^ de 3.Requisitos. Engenharia^ 2. de^ Desenvolvimento Requisitos Orientada^ Guiado porÁgeis. Objetivos. I. Nunes 4. Rodrigues, Projetos Ágeis.Genaina, 5. orient.Gestão deII. Projetos Título.
À minha esposa, que esteve ao meu lado na consecução desse trabalho, me dando forças e fôlego para não esmorecer. Seu auxílio foi contumaz importante, motivando e despertando a vontade de vencer. Sua dedicação e atenção nos momentos mais críticos me inspirou os pensamentos de uma forma bem especial, levando-me a novos horizontes no despertar do caminho do saber.
iv
Em primeiro lugar a Deus, que é o princípio de tudo e causa primária de todas as coisas. À minha esposa, que suportou a minha ausência, fruto de horas e meses na elaboração desta obra. Aos meus professores de mestrado que me fizeram uma nova pessoa, em especial a minha orientadora, com a sua paciência, sendo educadora, compreensiva, e às vezes rígida nos momentos em que houve a necessidade, me conduzindo ao caminho certo da apren- dizagem. Agradeço também a todos os meus amigos que me deram uma força para que eu pudesse levar a cabo este projeto, pelos incentivos e pela credibilidade.
v
Behavior-Driven Development (BDD) focuses on the collaboration and discovery of sys- tem behavior incorporating the definition of functionalities through features based on Specification by Example. On the other hand, the Goal-Oriented Requirements Engi- neering (GORE) uses goals to capture the intentionalities of the system in different levels of abstraction, in order to specify, structure, analyze, negotiate, document and modify requirements to be effectively achieved. Therefore, GORE aims to use the concept of objective to support the initial phases of requirements engineering. Thus, taking advantage of the benefit of both approaches, the proposed work aims to propose a method to support the management of agile projects based on the BDD and GORE techniques. This method proposes the combination of BDD techniques and the use of GORE models to contribute to the management of requirements and how they achieve their respective business objectives. Additionally, we propose an algorithm to analyze qualitatively and quantitatively the feasibility of the objectives of the objectives model in the presence of tasks following the concept of living documentation of the BDD approach, and allowing traceability between requirements and business objectives and their achievement in a dynamic way. In this way, our modeling approach based on the association of BDD features with tasks can open the way to contribute to agile project management. The proposed method was implemented in the piStar tool and analyzed in the System of Bulletins and Changes (SISBOL) in order to assess the feasibility of the proposal in supporting the management of agile software projects. In this context, a method was used to collect data from the requirements specifications of the PROMISE-EB project. Through the data collection of the 16 sprints of the project it was possible to monitor percentually the degree of acceptance of the features, as well as the respective achievement of the business objectives.
Keywords: Requirements, Behavior-Driven Development (BDD), Goal-Oriented Require- ments Engineering (GORE), Agile Project, Agile Project Management
vii
E Simulação de Evolução do Projeto 77
F Programa R: Scripts de plotagens 81
x
2.1 Comparação entre abordagens tradicional e ágil em relação ao processo de Engenharia de Requisitos [42].......................... 10
3.1 Exemplo de sucesso SISBOL (primeiras 2 sprints)............... 25 3.2 Processo com algumas falhas e skippeds..................... 25
4.1 Dados das entregas do SISBOL......................... 38
5.1 Comparação entre trabalhos relacionados.................... 45
A.1 Features do SISBOL............................... 53
xiii
O processo de desenvolvimento de software seguindo metodologias ágeis pode envolver algumas peculiaridades que devem ser levadas em consideração, ao debater a escassez de documentação de requisitos em metologias ágeis, conforme Mendes et al. [36]. Entretanto, apesar dos problemas levantados, o padrão de documentação ágil agrega diversos benefí- cios ao processo de desenvolvimento [11], principalmente em relação a aproximação entre os stakeholders do projeto e a evolução dos requisitos ao longo do tempo, de maneira dinâmica [29]. Ainda segundo Ernst [20], dados os requisitos G , e as suposições de domínio D , en- contramos a especificação S , de tal forma que, juntos, D e S satisfazem os requisitos G. Os requisitos G são representados como objetivos ( goals ), que capturam as propriedades desejadas do sistema, incluindo se a satisfação de um objetivo é obrigatória ou opcional com relação a outros objetivos. Os objetivos capturam o que o cliente considera valioso. Os objetivos podem ser satisfeitos pelas especificações S , representadas por conjuntos de Tarefas S referentes aos comportamentos do futuro sistema. Convêm frisar que as especi- ficidades de S são deliberadamente vagas: um conjunto de tarefas pode assumir a forma de delegações, compromissos, serviços, ou código, entre outros. Finalmente, os pressu- postos do domínio D são condições que se acredita que se mantêm no mundo, bem como afirmações que descrevem como o próprio problema está estruturado. Neste sentido, quando nos referimos a evolução dos requisitos de maneira dinâmica, nos deparamos com o conceito de living documentation , ou documentação viva , geralmente detalhada a partir de exemplos, como mostra [2]. Sabe-se que requisitos ágeis são baseados em histórias de usuário, definindo os comportamentos do sistema de maneira simples e sucinta [33], como apresenta a Listagem 1.1.
Apoiado nas vantagens de se descrever requisitos utilizando o modelo i, além de basear-se nas vantagens da especificação dos requisitos usando a técnica BDD no con- texto da metodologia ágil e essas carências elencadas ao representar os requisitos do um sistema, torna-se interessante desenvolver uma abordagem capaz de unir um modelo muito eficiente, porém, com limitações de informação, que é a utilização de features BDD, para um modelo mais completo, que nos forneça uma visão hierárquica das features BDD, demonstrando como suas respectivas tarefas ( tasks ) são capazes de representar os requi- sitos, por meio do mapeamento das features BDD, o modelo i. E apoiado nesta união nos possibilitar realização do cálculo da satisf acao^1 de requisitos.
Apesar das várias propostas de gestão de requisitos no processo de desenvolvimento de software, ainda carecem propostas para contornar problemas ainda presentes na gestão de requisitos. Dentre eles temos o estudo de Abad e Ruhe [1] que indicam a aplicação da análise de opções reais para gerenciamento em situações de incerteza, quanto ao contexto do projeto, custo e cronograma. Porém, a forma de gerenciamento proposta não foi testada em um ambiente real de desenvolvimento de software, necessitando assim, de confiabilidade quanto aos seus resultados. Além disso, conforme Soares et al. [51], dentre as dificuldades no uso de requisitos ágeis encontra-se a falta de informação. Embora o uso de requisitos ágeis possa pro- porcionar um ganho inicial em termos de tempo durante as atividades de especificação de requisitos, dificuldades como a falta de um requisito detalhado podem causar o de- senvolvimento de funcionalidades que não estão alinhadas com as esperadas pelo cliente. Consequentemente, vários indicadores podem emergir: (1) documentação dos requisitos inexistente (ou incompleta), (2) documentação desatualizada por falta de informação ou por volatilidade dos requisitos e (3) documentação de testes carecendo de uma relação com e entre os requisitos. Uma vez que a documentação viva proposta pela abordagem BDD pode explicitar as questões relativas aos três problemas acima, ela ainda carece de prover uma visão global da relação entre os requisitos. Em particular, ao descrever os requisitos a partir features BDD, percebe-se a carência com que essas features representam às funcionalidades do sistema, pois não é possível compreender as dependências entre as features , além de não ser possível dizer qual o contexto na qual elas estão inseridas dentro de um sistema. Desta forma, faz-se necessário a combinação da abordagem BDD com outra técnica para suprir esta lacuna. (^1) Conceito definido no âmbito deste trabalho como o grau de aceitação dos requisitos expressos por meio das features BDD
Por outro lado, a Engenharia de Requisitos Orientada por Objetivos [55] (GORE) provê uma abordagem mais estratégica do processo de desenvolvimento de software em uma perspetiva mais abrangente a partir dos objetivos principais do sistema e seus refina- mentos AND/OR. No entanto, abordagens como por exemplo o RE-KOMBINE [20], que tratam a evolução dos requisitos, não provêm uma maneira pragmática de conectar os requisitos técnicos (objetivos) e suas representações mais concretas para uma abordagem ágil.
As features BDD são bastante fragmentadas e não tem nenhuma relação direta entre si. Assim, torna-se necessário prover uma visão em que seja possível perceber se os objetivos de um sistema de software estão adequadamente atendidos/satisfeitos a partir do conjunto de requisitos especificados nessas features. Dessa forma, acreditamos que as abordagens BDD e GORE têm informações suficien- tes para prover uma metodologia de mensuração de evolução dos requisitos. Além disso, postulamos, também, que é possível propor uma abordagem para medir o grau de aceita- ção dos requisitos sem adicionar um alto custo adicional ao processo de desenvolvimento de software, em particular ao processo ágil. Uma vez que tanto a abordagem BDD, baseada no conceito de documentação viva a partir de histórias de usuário, quanto a abordagem GORE tem como cerne os objetivos do software como requisitos principais, surge então a seguinte pergunta de pesquisa:
RQ1: É possível saber se o conjunto de features BDD que representam o sistema é amplo o suficiente para atender aos seus objetivos de negócio? Se for possível, podemos rastrear diretamente os objetivos do sistema a partir dos seus artefatos de software? Caso essa rastreabilidade seja alcançada, é possível ter uma visão dinâmica e sempre atual dos requisitos alcançáveis por meio de suas features BDD e o grau de realização das mesmas?
Assumimos neste trabalho que os requisitos são especificados como features no formato Gherkin segundo a abordagem BDD. Aliado a isso utilizamos a abordagem de modelagem de objetivos iStar. Logo unindo essas duas abordagens investigaremos a possibilidade de propor uma abordagem para a gestão do grau de aceitação de requisitos ágeis.
do repositório de código do projeto. Os dados referem-se as features implementadas ao longo de 16 sprints no período de Outubro de 2016 a Abril de 2018. Como terceira contribuição deste trabalho, implementamos uma ferramenta que in- corpora a metodologia proposta nesta pesquisa. A implementação foi feita a partir da extensão da ferramenta piStar e está disponível em um repositório de código aberto no GitHub^2.
Este trabalho está organizado de acordo com o apresentado a seguir, além de conter alguns anexos e apêndices que devem ser consultados para compreensão adequada da pesquisa.
(^2) https://github.com/lealfb/bdd2Goal/
6
Os engenheiros de software, em seus trabalhos, devem procurar a alta qualidade e, ao mesmo tempo, o menor custo possível e o menor prazo para a entrega dos produtos, mesmo que a entrega seja subdividida em fases. Entretanto, o desenvolvimento de soft- ware nem sempre segue um caminho suave, pois a condução dos processos tornam-se imprevisíveis, ora por imposição dos recursos de tecnologia disponíveis, treinamento ou mudanças frequentes dos requisitos, ora por imposição do cliente, face às inúmeras frentes que se descortinam durante a construção e a lapidação do software futuro. Nesse contexto, os engenheiros de software estão cientes de que algumas questões técnicas e sócio-técnicas podem comprometer o software e sua evolução. Este capítulo providencia um referencial teórico sobre essa questão no viés das Metodologias Ágeis e suas implicações durante o processo de maturação, assunto relevante para a Engenharia de Software e suas nuances, mostrando o que pensam alguns autores sobre o assunto.
Os primeiros movimentos em direção ao Desenvolvimento Ágil ocorreram no ano de 2000, em Oregon, quando alguns engenheiros se reuniram para debater a temática. Mas foi so- mente em 2001 que, em uma segunda reunião em Utah, é que foi oficializado o movimento, com a publicação do Manifesto Ágil [7]. Com o tempo, os processos foram amadurecendo, surgindo várias metodologias de emprego, como o XP de Kent Beck [5] e o Scrum de Schwaber [47], entre outras.
Uma definição para Metodologia Ágil, em toda a sua complexidade e essência, poderia ser resumida em Ericksson et al. [19]:
