Evaluating the Impact of Critical Factors in Agile Continuous Delivery Process: A System Dynamics Approach

Continuous Delivery is aimed at the frequent delivery of good quality software in a speedy, reliable and efficient fashion – with strong emphasis on automation and team collaboration. However, even with this new paradigm, repeatability of project outcome is still not guaranteed: project performance varies due to the various interacting and inter-related factors in the Continuous Delivery 'system'. This paper presents results from the investigation of various factors, in particular agile practices, on the quality of the developed software in the Continuous Delivery process. Results show that customer involvement and the cognitive ability of the QA have the most significant individual effects on the quality of software in continuous delivery

Cenários de usuário por meio de diagramas de interação com o usuário

Dissertação (mestrado) - Universidade Federal de Santa Catarina, Centro Tecnológico, Programa de Pós-Graduação em Ciência da Computação, Florianópolis, 2015.O Desenvolvimento Dirigido por Testes de Aceitação (ATDD  Acceptance Test-Driven Development) requer que os requisitos da aplicação sejam expressos em formatos executáveis, criados a priori do desenvolvimento do código de aplicação. Esses testes devem conter as expectativas dos usuários e são adotados para promover a comunicação e colaboração entre usuários e desenvolvedores. Os requisitos normalmente são derivados de histórias de usuários. Contudo, devido à dificuldade dos usuários em expressarem os requisitos, os desenvolvedores são responsáveis pela especificação e automatização dos testes. Com objetivo de viabilizar a especificação de requisitos por usuários, esta Dissertação propõe os Cenários de Usuários por meio de Diagramas de Interação do Usuário (US-UID  User Scenarios through User Interaction Diagrams). Sendo assim, este estudo aborda: a criação de US-UIDs por usuários não técnicos e a execução automatizada dos US-UIDs. Este trabalho foi avaliado por meio de um estudo de caso de um jogo, que resultou em 67% dos requisitos completos e 90% dos requisitos corretos. A partir dos resultados obtidos na avaliação, apresentou-se e implementou-se um framework para executar os US-UIDs. Além disto, apresentou-se um estudo de caso baseado em um sistema web para verificar a capacidade de rastreabilidade de falha, erro e sucesso do código de aplicação.Abstract : Acceptance Test-Driven Development (ATDD) requires that application requirements to be expressed in executable formats and created a priori the development of the application code. These tests must include the users expectations and are adopted to promote communication and collaboration between users and developers. The requirements are usually derived from user stories. However, customers or users expressing requirements can be difficult. Thus, the developers are responsible for the specification and automation of tests. In order to facilitate the user s requirements specification, this dissertation proposes the User Scenarios through User Interaction Diagrams (US-UID). This study addresses: creation of US-UIDs by non-technical users and automated execution of US-UIDs. This study evaluated through a case study of a game, which resulted in 67% of complete requirements and 90% of correct requirements. Through the evaluation results, we developed a framework to automate the US-UIDs execution. In addition, we show a case study on a Web-base system to check the ability of traceability: failure, error and success of the application code

On the real world practice of Behaviour Driven Development

Surveys of industry practice over the last decade suggest that Behaviour Driven Development is a popular Agile practice. For example, 19% of respondents to the 14th State of Agile annual survey reported using BDD, placing it in the top 13 practices reported. As well as potential benefits, the adoption of BDD necessarily involves an additional cost of writing and maintaining Gherkin features and scenarios, and (if used for acceptance testing,) the associated step functions. Yet there is a lack of published literature exploring how BDD is used in practice and the challenges experienced by real world software development efforts. This gap is significant because without understanding current real world practice, it is hard to identify opportunities to address and mitigate challenges. In order to address this research gap concerning the challenges of using BDD, this thesis reports on a research project which explored: (a) the challenges of applying agile and undertaking requirements engineering in a real world context; (b) the challenges of applying BDD specifically and (c) the application of BDD in open-source projects to understand challenges in this different context. For this purpose, we progressively conducted two case studies, two series of interviews, four iterations of action research, and an empirical study. The first case study was conducted in an avionics company to discover the challenges of using an agile process in a large scale safety critical project environment. Since requirements management was found to be one of the biggest challenges during the case study, we decided to investigate BDD because of its reputation for requirements management. The second case study was conducted in the company with an aim to discover the challenges of using BDD in real life. The case study was complemented with an empirical study of the practice of BDD in open source projects, taking a study sample from the GitHub open source collaboration site. As a result of this Ph.D research, we were able to discover: (i) challenges of using an agile process in a large scale safety-critical organisation, (ii) current state of BDD in practice, (iii) technical limitations of Gherkin (i.e., the language for writing requirements in BDD), (iv) challenges of using BDD in a real project, (v) bad smells in the Gherkin specifications of open source projects on GitHub. We also presented a brief comparison between the theoretical description of BDD and BDD in practice. This research, therefore, presents the results of lessons learned from BDD in practice, and serves as a guide for software practitioners planning on using BDD in their projects