Difference between revisions of "Software Engineering in the Systems Engineering Life Cycle"

From SEBoK
Jump to navigation Jump to search
Line 42: Line 42:
  
 
The ways these related processes work together will depend on the maturity of the [[Systems Approach (glossary)|systems approach]] to solution [[Synthesis (glossary)|synthesis]] used 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 ways these related processes work together will depend on the maturity of the [[Systems Approach (glossary)|systems approach]] to solution [[Synthesis (glossary)|synthesis]] used 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.     
 +
 +
This approach needs a two ways relationship between SE and SwE technical processes.
  
 
The '''SW 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 Reuse Processes''' have a particularly important role to play in 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 '''SW 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 Reuse Processes''' have a particularly important role to play in 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]].

Revision as of 12:28, 3 December 2015

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 and discuss how these can be related to some of the SEBoK knowledge areas.

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.

Figure 1. A Generic Life Cycle Model. (SEBoK Original)

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 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.

Figure 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 cross-cutting 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." 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 relationship central to this is the way SwE Implementation Processes (see Fig 2) 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 considered at the system level. They also help consider horizontal concerns, ensuring whole system issues are considered 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 maturity of the systems approach to solution synthesis used 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.

This approach needs a two ways relationship between SE and SwE technical processes.

The SW 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 Reuse Processes have a particularly important role to play in 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.

Software and Systems Challenges

Pyster et al (2015) define three classes of software intensive system distinguished by the primary sources of novelty, functionality, complexity and risk in their conception, development, operation and evolution. These are briefly described below:

  • Physical Systems operate on and generate matter or energy. While they often utilize computation and software technologies as components, those components are not dominant in the horizontal dimension of engineering. Rather, in such systems, they are defined as discrete system elements and viewed and handled as vertical concerns.
  • Computational Systems include those in which computational behavior and, ipso facto, software are dominant at the systems level. The primary purpose of these systems is to operate on and produce data and information. While these systems always include physical and human elements, these are not the predominant challenges in system development, operation and evolution.
  • Cyber-Physical Systems are a complex combination of computational and physical dimensions. Such systems are innovative, functionally complex and risky in both their cyber and physical dimensions. They pose major horizontal engineering challenges across the board. In cyber-physical systems, cyber and physical elements collaborate in complex ways to deliver expected system behavior.

Some of the challenges of physical and computational systems are well known and can be seen in many SE and SwE case studies. For example, physical systems life cycles often make key decisions about the system architecture or implementation which limit the subsequent development of software architecture and designs. This can lead to software which is inefficient and difficult or expensive to change. Problems which arise later in the life of such systems may be dealt with by changing software, or human, elements. This may be done in a way which does not fully consider SwE design and testing practices. Similarly, computational systems may be dominated by the software architecture, without sufficient care taken to consider the best solutions for enabling hardware or people. In particular, operator interfaces, training and support may not be considered leading to expensive organizational fixes needed once they are in use. Many computational systems in the past have been developed without a clear view of the user need they are trying to contribute to, or the other systems they must work with to do so. These and other related issues both point to a need for system and software engineers with a better understanding of each others disciplines. Pyster et al. considers how SE and SwE education might be better integrated to help achieve this aim.

Examples of cyber-physical systems increasingly abound – smart automobiles, power grids, robotic manufacturing systems, defense and international security systems, supply-chain systems, the so-called internet of things, etc. In these systems there is no clear distinction between software elements and the whole system solution. The use of software in these systems is central to the physical outcome and software is often the integrating element which brings physical elements and people together. These ideas are closely align with the Service System Engineering approach described in Part 4.

Part 3 includes a Business and Mission Analysis process which is based on the equivalent process in the updated ISO/IEC/IEEE 15288 (2015). This process enable SE to be involved in the selection and bounding of the problem situation which initiates an engineered system life cycle. For cyber physical systems an understanding of the nature of software is needed in the formulation of the problem, since this is often fundamentally driven by the use of software to create complex adaptive solution concepts. This close coupling of software physical and human elements system across the system continues throughout the system l, making it necessary to consider all three in most system level decision life cycle.

The life cycle of cyber physical systems cannot be easily partitioned into SE and SwE achieving their own outcomes, but working together on horizontal system issues. It will require a much more closely integrated approach requiring systems and software engineers with a complementary set of competencies and changes in how the two disciplines are seen in both team and organizational structures. See Enabling Systems Engineering.

References

Works Cited

Pyster, A., Adcock, R., Ardis, M., Cloutier, R., Henry, D., Laird, L., Lawson, H. ‘Bud’., Pennotti, M., Sullivan, K., Wade J. 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.

< Previous Article | Parent Article | Next Article >


SEBoK v. 1.9.1 released 30 September 2018

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