Managing assumptions during agile development

The assumptions that underlie software development often go unrecorded and form part of the implicit rationale on which design and implementation decisions are based. These assumptions can fail at any time, with serious consequences. This paper presents a lightweight approach to assumption management (AM) designed to suit agile development. Assumptions were monitored for three months within a small agile team. Two key indicators were proposed for measuring AM success but only one was detected in the research results. A number of strong correlations were found between properties of assumptions. Data collection largely depended on the subjective judgements of the first author, but they were validated with some success by his colleagues. In some ways, assumption management was found to complement agile development. However, AM was not fully integrated into the team's development process, due to difficulty in adopting an 'assumption-aware' way of thinking. Suggestions are offered on how this transition may be eased, and on how others might wish to build on this research

Making Modeling Assumptions an Explicit Part of Real-Time Systems Models

A model abstracts a system. The model is valid for a precise set of assumptions. The authors recommend to include the assumptions into the model and discuss a solution based on Modeling Assumption Diagrams. SysML and TTool respectively serve as support language and tool to discuss the use of MADs

A mapping study on documentation in Continuous Software Development

Context: With an increase in Agile, Lean, and DevOps software methodologies over the last years (collectively referred to as Continuous Software Development (CSD)), we have observed that documentation is often poor. Objective: This work aims at collecting studies on documentation challenges, documentation practices, and tools that can support documentation in CSD. Method: A systematic mapping study was conducted to identify and analyze research on documentation in CSD, covering publications between 2001 and 2019. Results: A total of 63 studies were selected. We found 40 studies related to documentation practices and challenges, and 23 studies related to tools used in CSD. The challenges include: informal documentation is hard to understand, documentation is considered as waste, productivity is measured by working software only, documentation is out-of-sync with the software and there is a short-term focus. The practices include: non-written and informal communication, the usage of development artifacts for documentation, and the use of architecture frameworks. We also made an inventory of numerous tools that can be used for documentation purposes in CSD. Overall, we recommend the usage of executable documentation, modern tools and technologies to retrieve information and transform it into documentation, and the practice of minimal documentation upfront combined with detailed design for knowledge transfer afterwards. Conclusion: It is of paramount importance to increase the quantity and quality of documentation in CSD. While this remains challenging, practitioners will benefit from applying the identified practices and tools in order to mitigate the stated challenges

Notes on the synthesis of context: a novel approach to model context in software engineering

Context is often considered as a source for system change and variation. But the term ‘context’ has been typically used to mean the act of setting boundaries and setting system scope in software engineering. In this thesis, I challenge this view by suggesting that context should be applied to imply system variation on all levels of software (system) development. It constitutes as a more complex phenomena of how the system interacts with the world. The suggested approach synthesises context in terms of influence and perception through 'context states'. Context states are represented by a sixteen context state matrix, I refer to as The Context Dynamics Matrix (CDM). Context states are the result of two dimensions of context, perception on the x-axis, and influence on the y-axis. Analysts may identify context of a system using the CDM when they identify the influence that an element exerts and assign their perception of how they identified the influence. Each of the influence and perception dimensions is modelled using one model. First, the force model of influence, which identifies four levels of influence that an element may apply, each level showing a different implication on variation. Second, the knowledge model for perception, which shows five sources of knowledge about the influence. Accordingly, an analyst may describe the context of a system by matching the level of influence with the level of perception to obtain the context state of a given system element. A context state may imply a high or low level of variability, and a high or low level of perception. The use of context states is independent from any modelling view of a system that either describes functionality or system structure. Because context states describe the context of a system independently from the level or view in which they are described, it is possible to map the context states to enrich the description of a given view. Accordingly, I show how to map a context state to a functional description of a system by assigning a context state to Data Flow Diagram (DFD) element. Each process and data flow is assigned a context state that enriches its description of the system, in terms of levels of variation that the system’s context may imply. A proof-of-concept is provided to demonstrate howto apply context states to the analysis of the requirements of a system from industry. The results of the study show the viability of using context states to describe the context of systems, and support the argument to experiment further to evaluate the effectiveness of context states in areas of system development not covered by my research