Software Engineering in the Systems Engineering Life Cycle
This article describes how software engineering SwE life cycle processes integrate with the SE life cycle. A joint workshop organized by INCOSE, the Systems Engineering Research Center and the IEEE Computer Society was held to consider this relationship (Pyster et al, 2015). This workshop concluded that:
Software is fundamental to the performance, features, and value of most modern engineering systems. It is not merely part of the system, but often shapes the system architecture; drives much of its complexity and emergent behavior; strains its verification; and drives much of the cost and schedule of its development. Given how significant an impact software has on system development and given how complex modern systems are, one would expect the relationship between the disciplines of systems engineering (SE) and software engineering (SWE) to be well defined. However, the relationship is, in fact, not well understood or articulated."
In this article we give some of the basic relationships between SwE and SE.
Systems Engineering and Software Engineering Life Cycles
The Guide to the Software Engineering Body of Knowledge (SWEBoK) (Bourque and Fairley 2014) describes the life cycle of a software product as:
- analysis and design,
- construction
- testing,
- operation,
- maintenance, and eventually
- retirement or replacement.
This life cycle is common to most other mature engineering disciplines.
In Part 3 of the SEBoK, SE and Management, there is a discussion of SE life cycle models and life cycle processes. A Generic Life Cycle Model is described, reproduced in Fig 1.below This is used to describe necessary stages in life cycle of a typical engineered system.
Part 3 defines a collection of generic SE life cycle processes which define the activities and information needed across the SE life cycle. These processes include activities which contribute across the whole life cycle, with “humps” of focused activity in certain stages, see Applying Life Cycle Processes for details.
The following sections provide a brief discussion of how SwE life cycle processes fit into SE life cycle process models. In practice the details of this relationship is a key part of how a system life cycle is planned and delivered. It will be shaped by operating domain practice and solution type. Some examples of this are provided in the Implementation Examples.
Systems Engineering and Software Engineering Standards
The Systems Engineering life cycle processes described in Part 3, SE and Management, are largely based on those defined in the ISO/IEEE/IEC SE Life Cycle Processes 15288 Standard (2015).
The SWEBoK references the equivalent ISO/IEEE/IEC Software Engineering Life Cycle Processes 12207 Standard (2008), which defines a very similar set of processes for software systems. Figure 2 shows the relationship between the Enabling, Acquisition, Project and Technical Systems and Software processes in both 15288 and 12207 and the software specific processes of ISO/IEEE/IEC 12207. This alignment is from the last updates of both 12207 and 15288 in 2008. The SE processes have been further updated in 15288:2015, see Systems Engineering and Management for details. This change has not yet been applied to 12207. An update of 12207 is planned for 2016, in which the alignment to 15288 will be reviewed. See Alignment and Comparison of the Standards for more discussion of the relationships between the standards.
Fig 2 Aligned Process Models for ISO/IEC 15288 & 12207: 2008 (Adapted from Roedler 2011). Reprinted with permission of Garry Roedler. All other rights are reserved by the copyright owner.
Systems Engineering and Software Engineering Life Cycle Relationships
Pyster et al (2015) define two dimensions of engineered systems and of the engineering disciplines associated with them. The vertical dimensions of a system are those that modularize around technically focused engineering disciplines such as electrical engineering or mechanical engineering. These disciplines can be described as as being vertical, or at least as playing vertical roles in most complex systems projects. SwE can be partially considered as a vertical discipline.
The horizontal technical dimensions of a system, involve crosscutting concerns at the systems level. Such concerns include evolving customer preferences: systems-level quality attributes, trade-offs and optimization; system architecture, decomposition and integration issues; system development processes; and system economics: cost, schedule and risk. Both SE can be consider to have a horizontal role in complex system project, as can SwE for those system with a significant software content.
The ISO/IEE/IEC 12207 software engineering standard (2008) considers two situations:
- The life cycle of software product, containing minimal physical hardware, should use the software specific processes and a simple life cycle
- The life cycle of systems with a significant software content (sometimes called software intensive systems) should integrate the software processes into the SE life cycle
The second of these is the one relevant to the practice of SE. The SwE implementation processes are used in the SE life cycle to support the implementation of software intensive system elements. This simple relationship must be seen in the context of the concurrency, iteration and recursion relationship between SE life cycle processes described in Applying Life Cycle Processes. This means that, in general, software requirements and architecture processes will be applied alongside system requirements and architecture processes; while software integration and test processes are applied alongside system integration, verification and validation processes. These interrelationship helps with vertical software concerns, ensuring detailed software design and construction issues are consider at the system level. They also help consider horizontal concerns, ensuring whole system issues consider and are influenced by an understanding of software. See the Nature of Software for more details.
The ways these related processes work together will depend on the mature of the systems approach to solution synthesis and how this influences the life cycle. If a top down approach is used problem needs and system architecture will drive software implementation and realization. If a bottom up approach is used the architecture of existing software will strongly influence both the system solution and the problem which can be considered. In Applying Life Cycle Processes a "middle-out" approach is described which combines these two ideas and is the most common way to develop systems.
The SwE support processes may also play these vertical and horizontal roles. Part 3 contains knowledge areas on both System Deployment and Use which includes operation, maintenance and logistics; and Systems Engineering Management which covers the project processes shown in figure 2. SwE support processes will focus on the successful deployment and use of software system elements and the management needed to achieve this. They also support their equivalent SE processes in contributing to the success of the whole system life cycle. The software re use processes have a particularly important role to play in the both deployment and use and Product and Service Life Management processes. The later considers Service Life Extension, Capability Updates, Upgrades, and Modernization and system Disposal and Retirement. All of these horizontal software engineering activities rely on the associated SE activities having a sufficient understanding of the strengths and limitations of software and SwE, see Key Points a Systems Engineer Needs to Know about Software Engineering.
The Life Cycle Models knowledge area also defines how Vee and Iterative life cycle models provide a framework to tailor the generic life cycle and process definitions to different types of system development. Both models, with some modification, apply equally to the development of products and services containing software. Thus, the simple relationships between SE and SwE processes will form the basis for tailoring to suite project needs within a selected life cycle model.
References
Works Cited
Art Pyster, Rick Adcock, Mark Ardis, Rob Cloutier, Devanandham Henry, Linda Laird, Harold ‘Bud’ Lawson, Michael Pennotti, Kevin Sullivan, Jon Wade. 2015. Exploring the Relationship between Systems Engineering and Software Engineering. 13th Conference on Systems Engineering Research (CSER), Procedia Computer Science, Volume 44, 2015, Pages 708-717
Bourque, P. and R.E. Fairley (eds.). 2014. Guide to the Software Engineering Body of Knowledge (SWEBOK). Los Alamitos, CA, USA: IEEE Computer Society. Available at: http://www.swebok.org
ISO/IEC/IEEE. 2015. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.
ISO/IEEE. 2008. Systems and Software Engineering — Software Life Cycle Processes. Geneva, Switzerland: International Organization for Standards (ISO)/Institute of Electrical & Electronics Engineers (IEEE) Computer Society, ISO/IEEE 12207:2008(E).
Roedler, G. 2011. "Towards Integrated Systems and Software Engineering Standards." National Defense Industrial Association (NDIA) Conference, San Diego, CA, USA.
Primary References
Roedler, G. 2011. "Towards Integrated Systems and Software Engineering Standards." National Defense Industrial Association (NDIA) Conference, San Diego, CA, USA.
Additional References
Roedler, G. 2010. An Overview of ISO/IEC/IEEE 15288, System Life Cycle Processes. Asian Pacific Council on Systems Engineering (APCOSE) Conference.
SEBoK Discussion
Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.
If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.
blog comments powered by Disqus