The Need for Systems Engineering
This is part 2 of the blog series “Integrated Data as the Foundation of Systems Engineering.
Part 1 of this series introduced the overall topic of integrated data as the foundation of Systems Engineering.
In this part 2, I address the need for SE and the benefits of adopting SE from a data-centric perspective. A list of challenges that need to be addressed due to the increasingly complex systems is presented followed by a list of benefits organizations can realize by practicing SE from a data-centric perspective. This section concludes with a discussion concerning another key advantage to practicing SE from a data-centric perspective the use of measures to help better manage the system develop activities.
Meeting the challenges of increasingly complex systems
As stated in INCOSE Vision 2025 (INCOSE 2014), a constant throughout the evolution of systems engineering “is an ever-increasing complexity of systems which can be observed in terms of the number of system functions, components, and interfaces and their non-linear interactions and emergent properties. Each of these indicators of complexity has increased dramatically over the last fifty years, and will continue to increase due to the capabilities that stakeholders are demanding and the advancement in technologies that enable these capabilities.”
Often this complexity involves large-scale systems whose SE lifecycle process activities are distributed across many locations. An example of system complexity is the Boeing 787 (Malone et al 2016), for which over 30 companies based in countries around the world built large portions of the airplane. To help manage this complex system, Boeing developed a model that had >2,000 functions, >5,000 data flows, >1,000,000 data parameters, and >50,000,000 objects, with an average of three relationships per object, as well as ~1,000 geographically dispersed users involved in the modeling effort.
To successfully develop systems with increasing complexity in the future, there are several major challenges that SE needs to address:
* The need to manage the large number of work products and the underlying data and information that represents them electronically, rather than in printed documents, diagrams, or drawings.
* The need to remove “stovepipes” and use a common, integrated data set to holistically integrate with coherence and consistency work products and their underlying data and information across disciplines, organizations, and system lifecycles.
* The need to capture, integrate, manage, and access increasingly large sets of system engineering and program/project management data and information and associated interrelationships.
* The need to identify and manage dependencies across not only the system architecture but dependencies across disciplines and system lifecycles.
* The need to identify, define, and manage interactions (interfaces) between parts of the complex system architecture and between the system and the macro-system of which it is a part, no matter the complexity of the system under development.
* The need to track progress, identify at-risk activities, and take actions before these risks become problems that could impact cost, schedule, or the ability to deliver a product that meets stakeholder needs in the operational environment.
* The need to transition from a “gut” decision-making culture to a data-driven decision culture that is more effective and appropriate for managing complex systems. Data-driven decisions are not only driven by data and information but are recorded within an appropriate toolset, along with supporting information as to why the decision was made.
* The need to integrate SE activities with the program/project management activities and resulting work products and underlying data and information to better manage cost, schedule, and risk.
SE is continuously evolving to meet the needs of organizations and to address the challenges described above for increasingly complex systems. Out of this evolution, INCOSE launched the MBSE Initiative to meet these challenges and move towards INCOSE’s Vision 2025.
Technology is evolving at a rapid rate, especially information technology, not only resulting in more complex systems, but also enabling the documentation, management, and integration of large datasets that represent the many work products and underlying data and information generated as part of the SE lifecycle process activities.
Benefits of Implementing SE from a data-centric perspective
A data-centric perspective of SE complements the SE lifecycle processes by enabling the opportunity for system development with increased quality, lower cost, and lower risk. Implementing a data-centric perspective enables organizations to realize the following benefits: (Note: This list of benefits is derived from a similar list documented in National Aeronautical and Space Administration (NASA) “Expanded Guidance for NASA Systems Engineering”, Volume 2, Chapter 8.2. (NASA 2016)
- Meet the challenges associated with increasing complexity for current and future systems discussed in the previous section.
- Provides greater consistency of all products because any single piece of design data and information can be expressed authoritatively in a single place that can later be referred to by others for decisions, derivations, or formation of other work products.
- Provides better visibility into the principle characteristics of the whole system because multiple views from the common, integrated dataset can be created that succinctly address specific stakeholder concerns and interests.
- Provides greater congruence and configuration management between documentation and reality. Differing views of the underlying SE data and information can be automatically generated into SE work products, reducing the effort to keep the work products and their underlying data and information up to date and consistent, resulting in work products that match the best available, current data and information.
- Establishes “ground truth”. Ground truth is the only true reality—regardless of what someone says or thinks, no matter what they “remember” or what perspective they have concerning what is being done or built or a decision that was made, if it isn’t in the common, integrated dataset, it isn’t the truth. (Requires all the underlying data and information to be maintained and kept current and consistent.)
- Facilitates the navigation, traceability, and interrogation of data and information across all lifecycle stages. Managers and engineers can have access to the correct and consistent data and information more quickly, and on an as-needed basis, without going through manual distribution or search processes.
- Enables the reuse of SE and project management (PM) work products and underlying data and information. Considerable time and expense can be saved when an organization can reuse SE and PM data and information and not have to start from scratch for each new project. This reuse ability is key to effective product line management.
- Facilitates the management of the stakeholder needs, requirement definition, design, build/code, and system verification and validation activities in an integrated manner. Data and information associated with verification and validation activities across all lifecycle process activities can have higher quality, and provide greater insight concerning the status of verification and validation activities and being able to show compliance and that stakeholder needs are being met.
- Reduces the costs associated with erroneous design and resulting rework because analysis of the SE work products and underlying data and information can reveal a flaw or inconsistency as soon as it is created, enabling correction before downstream work is done, work that would be invalid, and costly and time consuming to correct if the upstream mistake were not corrected immediately. This also helps to avoid huge expenses associated with recalls, returns, warranty work, and negative comments on social media.
- Facilitates the identification of interactions (interfaces), helping to ensure your system of interest can be successfully integrated into the macro system it is a part and reducing integration issues and rework associated with these issues.
- Provides identification, management, interoperability, and integration of work products and underlying data and information across business or organizational elements needed to support program budget and schedule goals. With the ability to metatag data, information, and work products, you can, for example, tie these things directly to the WBS, budget, schedule, and risk management activities.
- Ensures data and information needed by programs and projects (e.g., for milestones, reviews, mission operations, risk mitigation, and anomaly investigations, decisions, and outcomes) are identified and managed to provide traceability of the data and information used in decision-making.
Organizations need to develop a level of organizational SE capability that will enable them to realize the benefits listed above. Further, since one size doesn’t fit all, an organization needs to assess the SE capabilities that best fit its domain, product line (degree of complexity), and culture. Consequently, the level of SE capability an organization establishes needs to be tailored to the size and complexity of systems developed by the organization, whether small, medium, or large projects. (A more detailed discussion on levels of SE capability is included in section 5.1.)
Measures – Using Data to Better Manage SE Projects
A key advantage of adopting SE from a data-centric perspective is being able to use measures to better manage, across all SE lifecycle processes, the SE activities associated with increasingly complex systems. Measures allow managers and systems engineers to monitor and assess progress, identify issues, and ensure the system being developed will meet stakeholder needs and expectations.
As stated in the INCOSE “Systems Engineering Measurement Primer”, v2.0, (INCOSE 2010) using measures can “efficiently deliver information to systems engineering managers who use it for decision-making.” Measurements help the project manager and systems engineer to:
* Monitor the progress and performance of SE and PM activities
* Communicate effectively throughout the organization
* Identify and correct problems early
* Make key tradeoffs
* Track specific project objectives
* Defend and justify decisions
Due to the importance of a measure to project success, several key measures are commonly used that reflect overall customer/user satisfaction (e.g., performance, safety, reliability, availability, maintainability, and workload requirements): measures of suitability (MOSs), measures of performance (MOPs), and measures of effectiveness (MOEs), and leading indicators (LIs). Once the project/program has identified and defined these measures, the measures are managed and monitored closely throughout the SE lifecycle processes and used by technical and programmatic leadership to make informed decisions and take appropriate and timely actions.
The purpose of using measures is to provide management with metrics that need to be watched and tracked closely throughout the system lifecycle to assess schedule and budget status and to help ensure a successful program and mission. The importance of identifying and managing using measures is emphasized by the number of documents that INCOSE has published on the subject:
* INCOSE SE HB, Section 5.7, Measurement Process (INCOSE-TP-2003-002-04, 2015)
* Metrics Guidebook for Integrated Systems and Product Development (INCOSE‐TP‐1995‐002‐01)
* Systems Engineering Measurement Primer (INCOSE‐TP‐2010‐005‐02)
* Technical Measurement Guide (INCOSE-TP-2003-020-01)
* Systems Engineering Leading Indicators Guide (INCOSE-TP-2005-001-03)
* Project Managers Guide to SE Measurement for Project Success (INCOSE-TP-2015-001-01)
In part 3a of this blog series, I introduce and define the concept of practicing SE from a data-centric perspective.
Comments are welcome.
If you have any other topics you would like addressed in our blog, feel free to let us know via our “Ask the Experts” page and we will do our best to provide a timely response.
.Tags: artifacts, data-centric, Integrated Data, Integrated dataset, MBSE, Model Based Systems Engineering, model-centric, systems engineering
By James Towers November 22, 2016 - 5:58 pm
A ‘model’ in MBSE term is not very well defined. This is an issue and as you have attempted, the sensible thing is to define it. Unfortunately though I don’t think you have got it correct. A model (in MBSE) is what you later go on to define as a data set. All the ‘artefacts’ in what ever format or language are just views (in the sense defined by ISO/IEC 42010)
By Lou Wheatcraft November 24, 2016 - 9:43 am
A lot of organizations use more than a single SE tool to define the artifacts. The result is a dataset generated by each SE tool and thus a collection of datasets. Differentiating between what is a model and what is a dataset is the core of the issue and a source of much of the confusion. Based on the various definitions of a model, datasets representing various artifacts can be considered models. In the INCOSE SE HB, the word model is used over 680 times! This has lead to a lot of confusion and is the basis of David Long’s blog and several other Vitech blogs on models versus views. Using the term model to refer to disjoint datasets used in this way leads to confusion – calling everything a model and saying you are implementing MBSE doesn’t mean you are really implementing MBSE as intended.
To realize the benefits of SE, we need to look at SE from a data-centric perspective (rather than a model based perspective) and link the various datasets that represent artifacts together across all system lifecycle stages. It is the integrated sets of data that allow the benefits of data-centric SE to be realized.
This integrated set of datasets represents an overall model of both the system under development and the SE process. Once all of the individual datasets are integrated into this one common model, then each artifact that is displayed is a view of this integrated dataset. So I think we are in total agreement.