Upcoming PhD defense

For the past four years, our research focus was on large-scale agile system development. We were particularly interested in how requirements and related knowledge can be managed at the scale of complex automotive systems. This year, we expect several PhD theses on this topic to conclude and we are excited to announce the first defense in this series:

“Living Boundary Objects to Support Agile Inter-Team Coordination at Scale”.  

Rebekka Wohlrab

Rebekka’s thesis establishes knowledge management practices that are considered beneficial by practitioners and focus on the crucial aspects to align agile teams on. It suggests concepts and requirements for knowledge management tools that take the distinct role of living boundary objects into consideration and can be adjusted as organizations’ needs evolve.

Date: April 15, 2020
Time: 13:30
Place: Room Alfons, 2nd floor, Patricia Building, Lindholmen Campus, Forskningsgången 6, Göteborg
Opponent: Prof. Dr. Darja Šmite (Blekinge Institute of Technology)

Given the current situation in Sweden and at Chalmers and Gothenburg University, it is becoming however unlikely that the defense can be held in that room. We may run the defense via video conferencing or similar and will notify how participants can join.

Supervised by Dr. Patrizio Pellicione and Dr. Eric Knauss, the thesis is based on the following papers:

  1. R. Wohlrab, P. Pelliccione, E. Knauss, M. Larsson.
    “Boundary Objects and Their Use in Agile Systems Engineering” Journal of Software: Evolution and Process; 31:e2166, 2019.
  2. R. Wohlrab, E. Knauss, J.-P. Stegho ̈fer, S. Maro, A. Anjorin, P. Pelliccione. “Collaborative Traceability Management: A Multiple Case Study from the Perspectives of Organization, Process, and Culture”
    Requirements Engineering, 2018.
  3. R. Wohlrab, U. Eliasson, P. Pelliccione, R. Heldal.
    “Improving the Consistency and Usefulness of Architecture Descriptions: Guidelines for Architects”
    Proceedings of the International Conference on Software Architecture (ICSA’19), 2019. Best Paper Award.
  4. R. Wohlrab, P. Pelliccione, E. Knauss, R. Heldal.
    “On Interfaces to Support Agile Architecting in Automotive: An Exploratory Case Study”
    Proceedings of the International Conference on Software Architecture (ICSA’19), 2019.
  5. R. Wohlrab, E. Knauss, P. Pelliccione.
    “Why and How to Balance Alignment and Diversity of Requirements Engineering Practices in Automotive”
    Journal of Systems and Software; 162:110516, 2020.
  6. R. Wohlrab, P. Pelliccione, A. Shahrokni, E. Knauss.
    “Why and How Your Traceability Should Evolve: An Automotive Perspective”
    Revised version submitted to IEEE Software, 2020.

Postdoc position: Digitalization in construction (closed)

Digitalization changes the way of working in many areas. In this project, we aim to support digitalization in smart build environments: By embedding sensors into a construction (e.g. a bridge), valuable data can be generated to facilitate maintenance of such constructions. Machine learning can be used to identify parts of the construction that are particularly affected by use and wear. Smart visualization of such data can help inspections.

The postdoc position aims to further strengthen a strong multi-disciplinary project team to which a successful candidate will bring software engineering expertise. The project aims to present a showcase of digitalization of the built environment (here: the construction of physical infrastructure such as buildings or bridges).

Continue reading

Practices for Collaborative Traceability

We are currently investigating practices for collaborative traceability – how engineers work together to create and maintain trace links. This work is based on a previous study [1] which investigated how collaborative aspects of traceability management are situated in existing development contexts.

Be part of this research and get inspired by our catalogue of practices for collaborative traceability!

We are now following up on this work with a number of concrete practices for collaborative traceability that have emerged in a workshop held in Gothenburg in October 2019. We want to better understand how concrete practices can contribute to collaborative traceability and if they are desirable or applicable in the context of different organisations.

Continue reading

PhD position: Supporting the Interaction of Humans and Automated Vehicles

SHAPE-IT is a four-year project where 15 PhD-students will be performing research that enables rapid and reliable development of safe and user-centered automated vehicles for urban environments.

And right now, we are looking for suitable candidates, one of which will be under my supervision.

The positions will be funded by a European Commission Horizon 2020 program for research and innovation: Marie Skłodowska-Curie Action (MSCA) Innovative Training Network (ITN). Link to more information about the 15 PhD positions.

I am specifically looking for a PhD candidate who will be considering human factors from a software (AI development) requirement perspective, with the aim to understand and describe how AI-based AV design can account for human factors. Methods will be developed to incorporate results from studies on acceptance which will improve AI-based AV-designs, taking human behavior into account. Recommendations on what information should be communicated between AV human factors researchers and AI-based AV designers to improve road-user acceptance, AV transparency, and vehicle safety, will be produced. Link to the ad and recruitment page.


* picture from Riccardo Scandariato, depicting one of the regular potluck dinner’s at the Division of Software Engineering.

Boundary Objects in Agile Practices

Continuous Management of Systems Engineering Artifacts in the Automotive Domain.

We are honored to have received a best paper award at ICSSP conference for this collaborative work with Rebekka Wohlrab, Patrizio Pelliccione, Eric Knauss and Mats Larsson.

In this paper, we derive guidelines for managing requirements, models, and other systems engineering artifacts continuously. This becomes an increasingly important capability, especially as more and more complex system development organizations transition towards agile methods. This can for example be observed in the automotive domain.

When reasoning on how to manage such artifacts, we found that the most important criterion is the artifacts’ context of use: Is it locally relevant to a (cross-functional) team? Or is it a boundary object relevant to two or more teams, potentially on different abstraction levels?

Locally relevant artifacts

Since such documents are only used by the team itself, it can (and likely: should) be retired when it is no longer useful. The other way around: if the document is supposed to be kept alive, we recommend to keep it useful by using it for example to generate (parts of) the output of the team, e.g. code. Thus, our recommendation is to focus on prescriptive models and similar artifacts.

Boundary objects

These artifacts are used to coordinate between teams and represent an interface between these teams. Examples include architectural models, high-level requirements, and variability information.

Our guidelines

Our first two guidelines are targeting system management artifacts in general, to create the sufficient overview to systematically manage artifacts.

  • (G1) Involve stakeholders from different areas to identify what artifacts are boundary objects and locally relevant artifacts. Find out how and by whom they are used, who should be responsible at what point in time, and how traceability can be established.
  • (G2) Make sure that you evaluate artifacts’ relevance and usage at frequent intervals. Depending on how the system evolves throughout its lifecycle, artifacts might become more relevant or should be discarded. Boundary objects could be converted into locally relevant artifacts and vice versa.

For boundary objects, we offer the following guidelines:

  • (G3) For each boundary object within your organization, establish
    a group of representatives from affected teams to discuss issues and later propagate that information. Store information in an accessible tool.
  • (G4) Find a lightweight and flexible approach to defining high- level artifacts upfront. Exploit this information to make impact analysis and changes, to avoid suboptimal decisions. With time, the artifacts should be refined and become more mature.

Finally, we also offer guidelines for locally relevant artifacts:

  • (G5) Produce locally relevant artifacts, especially those for documentation, as late as possible and only when they are actually needed. If possible this documentation should be automatically generated from other artifacts and code.
  • (G6) Aim to make locally relevant artifacts reusable (as with pre-scriptive models) and convey their relevance and use. Establish traceability to boundary objects.

Please refer to our paper for details, including our reasoning on why we provide these guidelines.


Reference: Wohlrab, R.; Pelliccione, P.; Knauss, E. & Larsson, M.: Boundary Objects in Agile Practices: Continuous Management of Systems Engineering Artifacts in the Automotive Domain (PDF). In: Proc. of Int. Conf. on Software and System Process (ICSSP), pp. 31-40, Gothenburg, Sweden, DOI: 10.1145/3202710.3203155, 2018

Abstract: Automotive companies increasingly include proven agile methods in their plan-driven system development. The adoption of agile methods impacts not only the way individuals collaborate, but also the management of artifacts like requirements, test cases, safety documentation, and models. While practitioners aim to reduce unnecessary documentation, there is a lack of guidance for automotive companies with respect to what artifacts are needed and how to manage them. To close this knowledge gap and create practical guidelines, we conducted a design-science study together with 53 practitioners from six automotive companies. Using interviews, surveys, and focus groups, we analyzed categories of artifacts and practical challenges to create applicable guidelines to collaboratively manage artifacts in agile automotive contexts. Our findings indicate that different practices are required to manage artifacts that are shared among different teams within the company (boundary objects) and those that are relevant within a specific team (locally relevant artifacts).

Communication and Coordination for release management in software ecosystems

Recently, I had an opportunity to work with German, Leif, and Daniel on a very interesting study of the Gnome FOSS Ecosystem. We were interested to understand how release managers coordinate a shared release of a set of interrelated projects within the Gnome Ecosystem. In particular, we investigated:

  • Communication channels used…
  • How developers communicate and coordinate…
  • The key actors, the key tasks, and the most pressing challenges…

With respect to release management in the Gnome FOSS Ecosystem.

What I personally found most interesting are implications for coordinating activities across an ecosystem. In our case, release managers did not exhibit concrete power over developers. They could not just make people do things. This reminds me of some systems and systems as well as ecosystems that I see emerging in industry, where again it is not always clear who has the main responsibility.

In such a situation, our lessons learnt relate to soft factors more than technology. Specifically, we derive the following recommendations from our case study:

  1. Ensure that the release team follows the main communication channels used by developers. The release team needs to be in touch with the developers. IRC channels and face-to-face meetings in developer conferences were highlighted in our case study.
  2. Provide a common place for coordination for an ecosystem. In a globally distributed and multi-cultural environment, we found an asynchronous, global mailing list ideal, when complemented with individual, direct communication (face-to-face or IRC) with developers.
  3. Consider including both good technical and social skills in a release team. In short, technical skills are necessary to earn the respect of developers and to communicate with them, social skills are crucial to convince them to perform necessary actions.
  4. Aim for a diverse release team. Successful release managers can be seen as representatives of the different parts of the ecosystem. A good release team should mirror the diversity of its ecosystem.
  5. Based on lack of power, lobbying and consensus based management must be followed. A release team is well advised to keep close to key influencers in the ecosystem.

 

The Journal of Internet Services and Applications has accepted this work and published it open access.

author Germán Poo-Caamaño and Eric Knauss and Leif Singer and Daniel M. German
title Herding cats in a FOSS ecosystem: a tale of communication and coordination for release management
journal Internet Services and Application, 2017, 8(12), 1-24
abstract Release management in large-scale software development projects requires significant communication and coordination. It is particularly challenging in Free and Open Source Software (FOSS) ecosystems, in which hundreds of loosely connected developers and their projects are coordinated to release software to a schedule. To better understand this process and its challenges, we analyzed over two and half years of communication in the GNOME ecosystem and studied developers’ interactions. Through a case study, we cataloged communication channels, determined the main channel from which we categorized high level communication and coordination activities spanning five releases, and triangulated our results by interviewing ten key developers. We found that a release schedule, influence (instead of direct control), and diversity are the main factors that positively impact the release process in the GNOME ecosystem. We report a set of lessons learned that encapsulates our understanding of how the Release Management process function in a FOSS ecosystem, we learned that: (1) ensure that the release team follows the main communication channels used by developers, (2) provide a common place for coordination for an ecosystem, (3) consider including both good technical and social skills in a release team, (4) aim for a diverse release team, (5) based on lack of power, lobbying and consensus based management must be followed, (6) help the release team in the coordination process with a well defined schedule, and (7) release team work is different from regular software work. Our results can help organizations build better large-scale teams and show that research focused on individual projects might miss important parts of the picture.
doi 10.1186/s13174-017-0063-2
keywords release management, software ecosystems, empirical study

RE for Large-Scale Agile System Development

I am very proud that our project on requirements engineering for large-scale agile system development at the software center is now going into its second year. The software center focuses on speed based on the following themes: Continous DeliveryContinuous Architecture, Metrics, and Customer Data- and Ecosystem-Driven Development. The software center has seen requirements at the end.

Yet, we were able to form a consortium of six software center companies to investigate how current challenges with managing requirements related knowledge limit the speed and potential of continuous, agile system development. The current way of managing requirements in system development might be indeed at its end. Our goal is to uncover better ways that address these challenges while still allowing to fully leverage advantages of agile teams and continuous delivery.

themes

Fig. 1: Themes from our multiple case study relating to the scope of agile development (RQ1), the role of RE in large-scale agile system development (RQ2), and the challenges of RE for large-scale agile system development (RQ3).

We have now published an initial report on these challenges based on an exploratory multiple case study with four companies in Fall 2016 (see an overview of the challenges in Fig. 1 and details in the pre-print below). In this paper, we come to the following conclusions:

  1. Challenges of RE for large-scale agile system development relate to themes-origcommunication and knowledge management. While related work implies that communication challenges are mitigated by agile approaches and less prominent in agile RE, all our challenges relate to communication and knowledge management. Both aspects are at the core of Agile and RE, indicating a need for fundamental research in these areas specifically for system development.
  2. Challenges relate to two areas of requirements knowledge: User Value and System Understanding. While pre-agile RE approaches differ between user and system requirements specifications, we are not aware of related work that makes this distinction for RE in the scope of agile development. Surprisingly, we found that companies were not very interested in agile RE practices themselves. In contrast, they found it more important to understand how RE can support agile methods in large-scale system development and how agile development can be integrated with existing processes. Our findings indicate that such support cannot be offered sufficiently by traditional, upfront RE. This suggests that continuous and agile development methods on a large scale require new concepts.
  3. Challenges relate to the interplay of stake- holders from three domains: customer, development, and integration & testing. The development domain is generally embracing agility and characterized by a dislike for traditional requirements and bulk updates. The require better synchronization between teams and wish for establishing an agile tool-chain. In contrast, the customer domain is concerned with breaking down customer-visible features in order to communicate customer-value to team. They require better support for writing meaningful user stories and for bridging the gap between plan-driven and agile development. The integration and testing domain is struggling to create and maintain traces and with the fact that user stories and tests are not sufficient to build and maintain sufficient system understanding.
  4. In order to yield their full benefits, agile practices and a holistic system requirements model must be better aligned. Key challenges occur when there is an interaction, or a lack thereof, between the three domains above.

Since the writing of this paper, two more companies have joined our project and we have more closely investigated key challenges in the context of existing system engineering processes and requirements-related artifacts. While we are still working on extending our report on challenges of RE in Large-Scale Agile System Development, we are now, in the second year of this project, turning towards exploring the solution space.

Find more details in the following paper:

Reference: Kasauli, R.; Liebel, G.; Knauss, E.; Gopakumar, S. & Kanagwa, B.: Requirements Engineering Challenges in Large-Scale Agile System Development. In: Proc. of 25th Int. Requirements Engineering Conf. (RE ’17), Lisbon, Portugal, 2017

Pre-Print of the paper: Kasauli2017a

Abstract: Motivated by their success in software development, companies implement agile methods and their practices increasingly for software-intense, large products, such as cars, telecommunication infrastructure, and embedded systems. Such systems are usually subject to safety and regulative concerns as well as different development cycles of hardware and software. Consequently, requirements engineering involves upfront and detailed analysis, which can be at odds with agile (software) development. In this paper, we present results from a multiple case study with two car manufacturers, a telecommunications company, and a technology company that are on the journey to introduce organization wide continuous integration and continuous delivery to customers. Based on 20 qualitative interviews, 5 focus groups, and 2 cross-company workshops, we discuss possible scopes of agile methods within system development, the consequences this has on the role of requirements, and the challenges that arise from the interplay of requirements engineering and agile methods in large-scale system development. These relate in particular to communicating and managing knowledge about a) customer value and b) the system under development. We conclude that better alignment of a holistic requirements model with agile development practices promises rich gains in development speed, flexibility, and overall quality of software and systems.