Systems and Software Interface Survey

Abstract

INCOSE formed the Systems and Software Interface Working Group (SaSIWG) in 2017, in response to Corporate Advisory Board interest in software, and problems identified in the systems and software interface (physical, logical, data and human). This third SaSIWG paper presents the results of a survey of systems engineers, software engineers, and project managers as to what are best practices and what are the priority challenges related to the interface between systems and software. The best practices mentioned by the 31 interviewees are grouped and summarized, followed by information on priority challenges and problems. Systems engineering must be done well, and that includes an ever‐increasing amount of Model‐Based Systems Engineering. It also includes developing and holding to a vision, addressing data, ensuring interdisciplinary work, planning systematic verification, and ensuring modularity. Systems Engineering must evolve to meet new challenges and most important, the expertise of systems engineers must include software engineering.

System- and Software-level Architecting Harmonization Practices for Systems-of-Systems : An exploratory case study on a long-running large-scale scientific instrument

“…Moving from analysis to synthesis, the practice of splitting the system along the subsystems axis, and the use of ICDs for subsystem demarcation was a significant improvement during the LOFAR2.0 system design. It is worth noting that the use of ICDs for the separation of concerns in the design of loosely coupled subsystems has been extensively discussed in empirical research literature [43], [44], [45], which identifies them as a key element for improving the interfacing between SE and SWE [11]. The results of this exploratory case study, however, suggest that the uniformity of ICDs across the system is key, particularly in large-scale systems.…”

“…Although in LOFAR2.0 the adoption of a more rigorous SE process, with a front-loading approach on requirements was aimed to address this, requirements-related problems persisted, but this time due to the domain knowledge required by software engineers to understand scientific use cases, a common issue also reported in [10]. Previous studies [11] highlighted the importance of interdisciplinary communication as a critical component of the process to avoid these kinds of problems. However, in the particular context of this study, it was pointed out that people talking with each other does not necessarily mean that they will understand each other.…”

“…The results of this exploratory case study, however, suggest that the uniformity of ICDs across the system is key, particularly in large-scale systems. On systems like LOFAR2.0, monitoring and control points, in addition to the I/O-related ones [11], are essential elements to be considered and uniformly described in their ICDs.…”

“…First, Pyster et al [2] explored the problems between these two disciplines through a workshop with practitioners, whose results were late integrated into the Systems Engineering Body of Knowledge 4 (SEBoK). A few years later, a study supported by INCOSE's Systems and Software Interface Working group further explored these interdisciplinary problems and a series of 'best-practices'some of them related to architecting practices-through a series of interviews with Systems Engineers and Software Engineers from different domains [11].…”

“…that do not enforce such hierarchical system/subsystem structure, or even prescribe a non-hierarchical one (e.g., Event-Driven). Related work in this field [7], [8], [9], and recent practitioner surveys [10], [11] suggest that the gaps and mismatches between system-level and software-level architectures created by these interdisciplinary differences are linked to major integration and operation problems in many engineered systems, including SoS.…”