Behavior Driven Development (BDD) is a modern agile software development approach that originates from Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD). Other than TDD and ATDD, BDD introduces new methods and strategies that intend to discover the behavior of software in greater detail which is achieved through enhanced communication and cooperation between everyone involved in software projects. In this paper it is examined how BDD can be taken even further and be connected to the products of UX-strategy in order to explore the possibilities to improve internal communication within software project teams. The report guides the reader through the theoretical frameworks of BDD, UX-strategy and Communication and presents suggestions of how BDD and the products UX-strategy can be connected to improve communication and understanding.

Submitted by Lucelia Lucena (lucelia.lucena@ufpe.br) on 2015-03-06T18:19:42Z No. of bitstreams: 2 DISSERTAÇÃO Carlos Diego Cavalcanti Pereira.pdf: 4207386 bytes, checksum: 1b429f9663fd012cb9da480f02ee5391 (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) / Made available in DSpace on 2015-03-06T18:19:42Z (GMT). No. of bitstreams: 2 DISSERTAÇÃO Carlos Diego Cavalcanti Pereira.pdf: 4207386 bytes, checksum: 1b429f9663fd012cb9da480f02ee5391 (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Previous issue date: 2014-03-18 / As metodologias ágeis de desenvolvimento de software emergiram como alternativa para processos prescritivos, os quais são classificados como excessivamente formais. Com objetivo de viabilizar entregas frequentes, processos adaptáveis, flexíveis e focados no cliente, as metodologias ágeis se tornaram referência sobre como produzir software de forma produtiva. Contudo, com objetivo de tornar o processo mais simples, essas abordagens invariavelmente incorrem em problemas como: modelos pouco generalistas para cobrir todo o ciclo de vida da Engenharia de Software; foco em disciplinas específicas do processo de software; subestimação de aspectos relevantes em iniciativas de desenvolvimento, como esforços de arquitetura, design e documentação; e indicação para equipes e projetos de pequena escala. A proposta desta dissertação de mestrado é propor um framework de processo eficiente de desenvolvimento de software, o qual se baseia nos ideários das metodologias ágeis, porém cobre todo o ciclo de vida de projeto desde a concepção, gestão, implementação e entrega. O framework inclui ferramentas como princípios, valores, atividades, artefatos e práticas específicas, incluindo esforços como arquitetura, design e documentação, concebendo um processo ágil, eficiente e extremamente produtivo para projetos de concepção e manutenção software, independentemente da sua escala.

Behavior-driven development (BDD) is a development practice focusing on behaviors and requirements from users and stakeholders. It is designed to develop behaviors which contribute directly to system outcomes. BDD encourages multiple stakeholders to collaborate by minimizing communication gaps and create a shared understanding of the project between technical and non-technical speakers. As a result, the development process becomes faster and the cost lower. Although BDD has many benefits, there are teams who feel inertia towards using it as their main development practice.This thesis work took place at a company with a strong agile foundation. It had the goal to investigate reasons why teams feel inertia against BDD, and thus contribute to BDD research and assist the company. The assumption that positive motivation would help in dispelling inertia was the idea behind this thesis work, and that a stronger motivation for a practice can be achieved by assessing a team’s suitability for it. To reach the goal of the thesis a qualitative research methodology was used, with a focus on obtaining a better understanding of opinions and behaviors that exist, with rounds of interviews and forms as the main method of data collection. Interviews were also consistently used throughout the thesis work to validate that it followed the right track.The inertia which teams at the company have experienced was clustered into different dimensions. These dimensions were used to develop a self-assessment tool intended to help people starting a project to assess how well BDD might fit their context. It allows people to assess their inertia in the different dimensions identified, and as well as attempting to give an overall guide to readiness, also giving some recommendations where gaps could be identified.The deliverable of the thesis work is the tool for managing inertia against BDD. It was developed in a spreadsheet-format for quick development and easy access for multiple users. However, it is important to highlight that this tool focuses on agile autonomous teams. The tool is not about forcing the development practice on someone but rather acts as an aid in giving insight into how well BDD could work for a specific project and team. Finally, to grasp the validity of the tool teams who had previous success developing projects using BDD at the company were able to try it out to see how well it reflected their project reality. The tool also got tested on teams who felt strong inertia towards BDD, to verify whether it helped them manage it or not. / Beteendedriven utveckling (BDD), är ett arbetssätt som fokuserar på beteenden och krav från både användare och intressenter. Det är utvecklat för att främja och skapa beteenen som bidrar till det önskade målet. Några av BDDs fördelar är att arbetssättet uppmuntrar intressenterna till tätt samarbete, att minska luckor i kommunikation och information samt att det skapar en delad förståelse för projektet mellan teknisktoch icke-tekniskt kunniga intressenter. En positiv konsekvens av detta är att utvecklingen tenderar att bli snabbare och kostnaderna lägre. BDD ser till att alla inblandade är eniga om vilket resultat man kan förvänta sig från ett utvecklingsprojekt, redan innan utvecklingen börjar. Detta gör att de missförstånd som är vanligt förekommande mellan intressenter och utvecklingsteam reduceras. Trots att BDD, som nämnts, har flera fördelar finns det team som känner motstånd mot att använda BDD som sitt huvudsakliga arbetssätt.Antagandet att motivation kan bidra till att minska motståndet och att motivationen kan skapas genom att påvisa för team hur lämpligt BDD skulle vara för just dem var ideén bakom detta arbete. Det utfördes på ett företag med stark agil bas. Målet var att identifiera och utreda orsakerna till att team känner motstånd mot BDD, och på så sätt bidra till forskningen och samtidigt hjälpa företaget med en ökad insikt i detta. Syftet med arbetet var att utveckla ett verktyg för att hjälpa team förstå sitt motstånd mot BDD och guida dem till hur de kan hantera det. För att nå målet användes en kvalitativ forskningsmetod med fokus på att få en bättre förståelse för åsikter och beteenden som finns angående BDD. Olika rundor av intervjuer utgjorde den huvudsakliga datainsamlingen. Intervjuer användes också kontinuerligt för att validera att arbetet höll rätt kurs.Det motstånd mot BDD som påträffades på företaget grupperades i olika dimensioner. Dessa användes för att utveckla slutprodukten av kandidatexamensarbetet, ett självskattningsverktyg. För att underlätta utvecklingen valdes ett spreadsheet-format på verktyget, detta även för att enkelt kunna dela det mellan flertalet intressenter.Det är viktigt att understryka att verktyget fokuserar på autonoma team. Det har inte som mål att tvinga någon att använda BDD, utan att agera som hjälp för att visa hur arbetssättet skulle kunna fungera för ett specifikt projekt och team. Slutligen, för att kunna verifiera kvaliteten på verktyget, utvärderades det i samarbete med team som tidigare på ett framgångsrikt sätt utvecklat ett projekt med BDD. Detta för att se om självskattningsverktygets utsägelse motsvarade teamets helhetsupplevelse. Verktyget testades också av andra team för att se om det var till hjälp för dem eller inte.

Dans un processus de conception centré sur l'utilisateur, les artefacts évoluent par cycles itératifs jusqu'à ce qu'ils répondent aux exigences des utilisateurs et deviennent ensuite le produit final. Chaque cycle donne l'occasion de réviser la conception et d'introduire de nouvelles exigences qui pourraient affecter les artefacts qui ont été définis dans les phases de développement précédentes. Garder la cohérence des exigences dans tels artefacts tout au long du processus de développement est une activité lourde et longue, surtout si elle est faite manuellement. Actuellement, certains cadres d'applications implémentent le BDD (Développement dirigé par le comportement) et les récits utilisateur comme un moyen d'automatiser le test des systèmes interactifs en construction. Les tests automatisés permettent de simuler les actions de l'utilisateur sur l'interface et, par conséquent, de vérifier si le système se comporte correctement et conformément aux exigences de l'utilisateur. Cependant, les outils actuels supportant BDD requièrent que les tests soient écrits en utilisant des événements de bas niveau et des composants qui n'existent que lorsque le système est déjà implémenté. En conséquence d'un tel bas niveau d'abstraction, les tests BDD peuvent difficilement être réutilisés avec des artefacts plus abstraits. Afin d'éviter que les tests doivent être écrits sur chaque type d'artefact, nous avons étudié l'utilisation des ontologies pour spécifier à la fois les exigences et les tests, puis exécuter des tests dans tous les artefacts partageant les concepts ontologiques. L'ontologie fondée sur le comportement que nous proposons ici vise alors à élever le niveau d'abstraction tout en supportant l'automatisation de tests dans des multiples artefacts. Cette thèse présente tel ontologie et une approche fondée sur BDD et les récits utilisateur pour soutenir la spécification et l'évaluation automatisée des exigences des utilisateurs dans les artefacts logiciels tout au long du processus de développement des systèmes interactifs. Deux études de cas sont également présentées pour valider notre approche. La première étude de cas évalue la compréhensibilité des spécifications des récits utilisateur par une équipe de propriétaires de produit (POs) du département en charge des voyages d'affaires dans notre institut. À l'aide de cette première étude de cas, nous avons conçu une deuxième étude pour démontrer comment les récits utilisateur rédigés à l'aide de notre ontologie peuvent être utilisées pour évaluer les exigences fonctionnelles exprimées dans des différents artefacts, tels que les modèles de tâche, les prototypes d'interface utilisateur et les interfaces utilisateur à part entière. Les résultats ont montré que notre approche est capable d'identifier même des incohérences à grain fin dans les artefacts mentionnés, permettant d'établir une compatibilité fiable entre les différents artefacts de conception de l'interface utilisateur. / In a user-centered design process, artifacts evolve in iterative cycles until they meet user requirements and then become the final product. Every cycle gives the opportunity to revise the design and to introduce new requirements which might affect the artifacts that have been set in former development phases. Keeping the consistency of requirements in such artifacts along the development process is a cumbersome and time-consuming activity, especially if it is done manually. Nowadays, some software development frameworks implement Behavior-Driven Development (BDD) and User Stories as a means of automating the test of interactive systems under construction. Automated testing helps to simulate user's actions on the user interface and therefore check if the system behaves properly and in accordance with the user requirements. However, current tools supporting BDD requires that tests should be written using low-level events and components that only exist when the system is already implemented. As a consequence of such low-level of abstraction, BDD tests can hardly be reused with more abstract artifacts. In order to prevent that tests should be written to every type of artifact, we have investigated the use of ontologies for specifying both requirements and tests once, and then run tests on all artifacts sharing the ontological concepts. The resultant behavior-based ontology we propose herein is therefore aimed at raising the abstraction level while supporting test automation on multiple artifacts. This thesis presents this ontology and an approach based on BDD and User Stories to support the specification and the automated assessment of user requirements on software artifacts along the development process of interactive systems. Two case studies are also presented to validate our approach. The first case study evaluates the understandability of User Stories specifications by a team of Product Owners (POs) from the department in charge of business trips in our institute. With the help of this first case study, we designed a second one to demonstrate how User Stories written using our ontology can be used to assess functional requirements expressed in different artifacts, such as task models, user interface (UI) prototypes, and full-fledged UIs. The results have shown that our approach is able to identify even fine-grained inconsistencies in the mentioned artifacts, allowing establishing a reliable compatibility among different user interface design artifacts.