Supporting Multiple Stakeholders in Agile Development

Agile software development practices require several stakeholders with different kinds of expertise to collaborate while specifying requirements, designing and modeling software, and verifying whether developers have implemented requirements correctly. We studied 112 requirements engineering (RE) tools from academia and the features of 13 actively maintained behavior-driven development (BDD) tools, which support various stakeholders in specifying and verifying the application behavior. Overall, we found that there is a growing tool specialization targeted towards a specific type of stakeholders. Particularly with BDD tools, we found no adequate support for non-technical stakeholders —- they are required to use an integrated development environment (IDE) —- which is not adapted to suit their expertise. We argue that employing separate tools for requirements specification, modeling, implementation, and verification is counter-productive for agile development. Such an approach makes it difficult to manage associated artifacts and support rapid implementation and feedback loops. To avoid dispersion of requirements and other software-related artifacts among separate tools, establish traceability between requirements and the application source code, and streamline a collaborative software development workflow, we propose to adapt an IDE as an agile development platform. With our approach, we provide in-IDE graphical interfaces to support non-technical stakeholders in creating and maintaining requirements concurrently with the implementation. With such graphical interfaces, we also guide non-technical stakeholders through the object-oriented design process and support them in verifying the modeled behavior. This approach has two advantages: (i) compared with employing separate tools, creating and maintaining requirements directly within a development platform eliminates the necessity to recover trace links, and (ii) various natively created artifacts can be composed into stakeholder-specific interactive live in-IDE documentation. These advantages have a direct impact on how various stakeholders collaborate with each other, and allow for rapid feedback, which is much desired in agile practices. We exemplify our approach using the Glamorous Toolkit IDE. Moreover, the discussed building blocks can be implemented in any IDE with a rich-enough graphical engine and reflective capabilities

Augmenting Source Code Lines with Sample Variable Values

Source code is inherently abstract, which makes it difficult to understand. Activities such as debugging can reveal concrete runtime details, including the values of variables. However, they require that a developer explicitly requests these data for a specific execution moment. We present a simple approach, RuntimeSamp, which collects sample variable values during normal executions of a program by a programmer. These values are then displayed in an ambient way at the end of each line in the source code editor. We discuss questions which should be answered for this approach to be usable in practice, such as how to efficiently record the values and when to display them. We provide partial answers to these questions and suggest future research directions

Supporting multiple stakeholders in agile development

Agile software development practices require several stakeholders with different kinds of expertise to collaborate while specifying requirements, designing, and modelling software, and verifying whether developers have implemented requirements correctly. We studied 112 requirements engineering (RE) tools from academia and the features of 13 actively maintained behavior-driven development (BDD) tools, which support various stakeholders in specifying and verifying the application behavior. Overall, we found that there is a growing tool specialization targeted towards a specific type of stakeholders. Particularly with BDD tools, we found no adequate support for non-technical stakeholders-- they are required to use an integrated development environment (IDE)-- which is not adapted to suit their expertise. We argue that employing separate tools for requirements specification, modelling, implementation, and verification is counterproductive for agile development. Such an approach makes it difficult to manage associated artifacts and support rapid implementation and feedback loops. To avoid dispersion of requirements and other software-related artifacts among separate tools, establish traceability between requirements and the application source code, and streamline a collaborative software development workflow, we propose to adapt an IDE as an agile development platform. With our approach, we provide in-IDE graphical interfaces to support non-technical stakeholders in creating and maintaining requirements concurrently with the implementation. With such graphical interfaces, we also guide non-technical stakeholders through the object-oriented design process and support them in verifying the modelled behavior. This approach has two advantages: (i) compared with employing separate tools, creating, and maintaining requirements directly within a development platform eliminates the necessity to recover trace links, and (ii) various natively created artifacts can be composed into stakeholder-specific interactive live in-IDE documentation. These advantages have a direct impact on how various stakeholders collaborate with each other, and allow for rapid feedback, which is much desired in agile practices. We exemplify our approach using the Glamorous Toolkit IDE. Moreover, the discussed building blocks can be implemented in any IDE with a rich-enough graphical engine and reflective capabilities

Sindarin: A Versatile Scripting API for the Pharo Debugger

International audienceDebugging is one of the most important and time consuming activities in software maintenance, yet mainstream debuggers are not well-adapted to several debugging scenarios. This has led to the research of new techniques covering specific families of complex bugs. Notably, recent research proposes to empower developers with scripting DSLs, plugin-based and moldable debuggers. However, these solutions are tailored to specific use-cases, or too costly for one-time-use scenarios. In this paper we argue that exposing a debugging scripting interface in mainstream debuggers helps in solving many challenging debugging scenarios. For this purpose, we present Sindarin, a scripting API that eases the expression and automation of different strategies developers pursue during their debugging sessions. Sindarin provides a GDB-like API, augmented with AST-bytecode-source code mappings and object-centric capabilities. To demonstrate the versatility of Sindarin, we reproduce several advanced breakpoints and non-trivial debugging mechanisms from the literature

Interactive Behavior-driven Development: a Low-code Perspective

Within behavior-driven development (BDD), different types of stakeholders collaborate in creating scenarios that specify application behavior. The current workflow for BDD expects non-technical stakeholders to use an integrated development environment (IDE) to write textual scenarios in the Gherkin language and verify application behavior using test passed/failed reports. Research to date shows that this approach leads non-technical stakeholders to perceive BDD as an overhead in addition to the testing. In this vision paper, we propose an alternative approach to specify and verify application behavior visually, interactively, and collaboratively within an IDE. Instead of writing textual scenarios, non-technical stakeholders compose, edit, and save scenarios by using tailored graphical interfaces that allow them to manipulate involved domain objects. Upon executing such interactively composed scenarios, all stakeholders verify the application behavior by inspecting domain-specific representations of run-time domain objects instead of a test run report. Such a low code approach to BDD has the potential to enable nontechnical stakeholders to engage more harmoniously in behavior specification and validation together with technical stakeholders within an IDE. There are two main contributions of this work: (i) we present an analysis of the features of 13 BDD tools, (ii) we describe a prototype implementation of our approach, and (iii) we outline our plan to conduct a large-scale developer survey to evaluate our approach to highlight the perceived benefits over the existing approach

Practical domain-specific debuggers using the Moldable Debugger framework

International audienceUnderstanding the run-time behavior of software systems can be a challenging activity. Debuggers are an essential category of tools used for this purpose as they give developers direct access to the running systems. Nevertheless, traditional debuggers rely on generic mechanisms to introspect and interact with the running systems, while developers reason about and formulate domain-specific questions using concepts and abstractions from their application domains. This mismatch creates an abstraction gap between the debugging needs and the debugging support leading to an inefficient and error-prone debugging effort, as developers need to recover concrete domain concepts using generic mechanisms. To reduce this gap, and increase the efficiency of the debugging process, we propose a framework for developing domain-specific debuggers, called the Moldable Debugger, that enables debugging at the level of the application domain. The Moldable Debugger is adapted to a domain by creating and combining domain-specific debugging operations with domain-specific debugging views, and adapts itself to a domain by selecting, at run time, appropriate debugging operations and views. To ensure the proposed model has practical applicability (i.e., can be used in practice to build real debuggers), we discuss, from both a performance and usability point of view, three implementation strategies. We further motivate the need for domain-specific debugging, identify a set of key requirements and show how our approach improves debugging by adapting the debugger to several domains

SmartInspect: Smart Contract Inspection Technical Report

Smart contracts are embedded procedures stored with the data they act upon. Debugging deployed Smart Contracts is a difficult task since once deployed, the code cannot be reexecuted and inspecting a simple attribute is not easily possible because data is encoded. In this technical report, we present SmartInspect to address the lack of inspectability of a deployed contract. Our solution analyses the contract state by using decompilation techniques and a mirror-based architecture to represent the object responsible for interpreting the contract state. SmartInspect allows developers and also end-users of a contract to better visualize and understand the contract stored state without needing to redeploy, nor develop any ad-hoc code

SmartAnvil: Open-Source Tool Suite for Smart Contract Analysis

International audienceSmart contracts are new computational units with special properties: they act as classes with aspectual concerns; their memory structure is more complex than mere objects; they are obscure in the sense that once deployed it is difficult to access their internal state; they reside in an append-only chain. There is a need to support the building of new generation tools to help developers. Such support should tackle several important aspects: (1) the static structure of the contract, (2) the object nature of published contracts, and (3) the overall data chain composed of blocks and transactions. In this chapter, we present SmartAnvil an open platform to build software analysis tools around smart contracts. We illustrate the general components and we focus on three important aspects: support for static analysis of Solidity smart contracts, deployed smart contract binary analysis through inspection, and blockchain navigation and querying. SmartAnvil is open-source and supports a bridge to the Moose data and software analysis platform