Change-Impact driven Agile Architecting.

Software architecture is a key factor to scale up Agile Software Development ASD in large softwareintensive systems. Currently, software architectures are more often approached through mechanisms that enable to incrementally design and evolve software architectures aka. agile architecting. Agile architecting should be a light-weight decision-making process, which could be achieved by providing knowledge to assist agile architects in reasoning about changes. This paper presents the novel solution of using change-impact knowledge as the main driver for agile architecting. The solution consists of a Change Impact Analysis technique and a set of models to assist agile architects in the change -decision-making- process by retrieving the change-impact architectural knowledge resulting from adding or changing features iteration after iteration. To validate our approach, we have put our solution into practice by running a project of a metering management system in electric power networks in an i-smart software factory

FEED-FORWARD IN SOFTWARE ENGINEERING WITH PARTICULAR FOCUS ON REQUIREMENTS ENGINEERING AND SOFTWARE ARCHITECTING

This study is intended to determine the characteristics, impact and state of the practice of feed-forward in software engineering; in particular, in the fields of Requirements Engineering (RE) and Software Architecting (SA). Feed-forward is used in many domains such as systems engineering, neural networks, management and psychotherapy. However, in software engineering, especially in RE and SA, the concept of feed-forward is not well researched. For example, what are the characteristics of feed-forward information? What effect does feed-forward information have on architectural artefacts and software project aspects such as cost, quality, time, etc.? What is the current state of practice of feed-forward? A knowledge seeking empirical investigation including an industrial survey and an embedded case study with four projects as four units of analysis were carried out based on these questions. The overall findings ofthis study show that the most common types of information that are fed-forward consistently are requirements and architectural information. This information affects a multitude of aspects of a software project (such as time, cost and quality) and influences several architectural artefacts (such as tactics, patterns and decisions). The results also show that approximately 20% of software professionals have never, or rarely, practiced feed­ forward in their organizations. On the other hand, approximately 66% of software professionals practice feed-forward in their organization in varying levels (“sometimes”, “most of the time”, “always”). 64% of software professionals find feed-forward to be useful for their organization and 4% thought that feed-forward would not be useful, citing reasons such as information overload and lack of motivation. From a researcher’s perspective, determining the properties of feed-forward could provide ground work for doing further research on feed-forward such as: the practice of feed-forward in the other areas of software engineering and the comparison of feedback and feed-forward in software engineerin

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

On Integrating Student Empirical Software Engineering Studies with Research and Teaching Goals

Background: Many empirical software engineering studies use students as subjects and are conducted as part of university courses. Aim: We aim at reporting our experiences with using guidelines for integrating empirical studies with our research and teaching goals. Method: We document our experience from conducting three studies with graduate students in two software architecture courses. Results: Our results show some problems that we faced when following the guidelines and deviations we made from the original guidelines. Conclusions: Based on our results we propose recommendations for empirical software engineering studies that are integrated in university courses.

Software Reuse in Agile Development Organizations - A Conceptual Management Tool

The reuse of knowledge is considered a major factor for increasing productivity and quality. In the software industry knowledge is embodied in software assets such as code components, functional designs and test cases. This kind of knowledge reuse is also referred to as software reuse. Although the benefits can be substantial, software reuse has never reached its full potential. Organizations are not aware of the different levels of reuse or do not know how to address reuse issues. This paper proposes a conceptual management tool for supporting software reuse. Furthermore the paper presents the findings of the application of the management tool in an agile development organization

Semantic Bridging between Conceptual Modeling Standards and Agile Software Projects Conceptualizations

Software engineering benefitted from modeling standards (e.g. UML, BPMN), but Agile Software Project Management tends to marginalize most forms of documentation including diagrammatic modeling, focusing instead on the tracking of a project\u27s backlog and related issues. Limited means are available for annotating Jira items with diagrams, however not on a granular and semantically traceable level. Business processes tend to get lost on the way between process analysis (if any) and backlog items; UML design decisions are often disconnected from the issue tracking environment. This paper proposes domain-specific conceptual modeling to obtain a diagrammatic view on a Jira project, motivated by past conceptualizations of the agile paradigm while also offering basic interoperability with Jira to switch between environments and views. The underlying conceptualization extends conceptual modeling languages (BPMN, UML) with an agile project management perspective to enrich contextual traceability of a project\u27s elements while ensuring that data structures handled by Jira can be captured and exposed to Jira if needed. Therefore, concepts underlying the typical software development project management are integrated with established modeling concepts and tailored (with metamodeling means) for the domain-specificity of agile project management. A Design Science approach was pursued to develop a modeling method artifact, resulting in a domain-specific modeling tool for software project managers that want to augment agile practices and enrich issue annotation