Integrating Supporting Aspects into System Models

Introduction

The model-based approach to systems engineering considers the system model as much more than a plain description of the system; the model is the central common basis for capturing, representing and integrating the various system aspects listed below. The model is key to the design and understanding of the system and to managing its life cycle and evolution. Modeling languages constitute the basis for standardized, formal descriptions of systems, just like natural languages form the basis for human communication. As systems are becoming ever more complex and multidisciplinary, so does the conceptual modeling of systems evolve and become more critical for understanding complex design (Dori 2002). In addition to facilitating communication among clients, designers, and developers, conceptual modeling languages also help in clearly describing and documenting various domains, systems, and problems, and define requirements and constraints for the design and development phases (Wand and Weber 2002). The importance of model-based analysis is demonstrated by the variety of conceptual modeling methodologies and frameworks, although de-Facto standards are slow to emerge. While uni-disciplinary engineering design such as structural analysis or circuit design have established modeling semantics and notation, the conceptual modeling of complex systems and processes has not yet converged on a unified, consolidated modeling framework (Estefan 2007). The challenge to integrate multiple aspects and support the various phases of the system’s life cycle, but first to capture the multidisciplinary nature of the system, has led to the creation of various frameworks. Nevertheless, the information systems analysis paradigm is currently the leading one, perhaps due to the need to integrate complex systems via information-intensive applications and interactions. This article discusses the integrated modeling of systems and supporting aspects using Model-based Systems Engineering methodologies and frameworks. Supporting aspects of systems engineering include engineering management; project management; requirements engineering and management; risk modeling, analysis, and management; quality assurance, testing, verification, and validation; system integration and deployment; and the analysis of "ilities": reliability, availability, maintainability, safety, and security (RAMSS), manufacturability, extensibility, robustness, resilience, flexibility, and evolvability. These aspects can pertain to physical and informatical facets, as well as to functional, structural, behavioral, social, and environmental facets of the core system model. The article focuses on three main aspects:

1. Project and Engineering Management
2. Risk Modeling, Analysis, and Management
3. Requirements Definition and Management

Integrated Modeling of Systems and Projects

This section discusses the integrated modeling of systems and projects and of the project-system relationship (often called Project-Product Integration). The fields of Project Management and Systems Engineering have been advancing hand-in-hand for the last two decades, with the understanding that successful projects create successful systems. All the main Systems Engineering resources pay considerable attention to Project Management as a critical process and enabler of Systems Engineering (Haskins, Forsberg, and Krueger 2007; NASA 2007; Sage and Rouse 2011). The integration of system-related aspects and concepts into project plans is more common than the integration of project-related aspects and concepts into system models. This is so because the project is a means to an end—it is the process that is expected to deliver the system. Indeed, project activities are often named after or in accord with the deliverables they are aimed at facilitating, e.g., “console design”, “software development”, “hardware acquisition”, or “vehicle assembly”. Each is a function name, consisting of an object (noun)—the system to be attained, and a process (verb)—the project or part of project aimed at attaining the end system. The specific process associated with each of these examples refers to different stages or phases of the project, and to different maturity levels of the system or sub-system it applies to. Moreover, the mere inclusion of system and part names in activity names does not truly associate system model artifact s with these activities. Therefore, it cannot be truly possible to derive the set of activities associated with a particular part or functionality of the system which is delivered by the project. Project-Product integration is not straightforward, as project models and system models are traditionally disparate and hardly interface. A model-based approach to project-system integration follows a system-centric paradigm, and focuses on incorporating project-related aspects and concepts into the core system model, as opposed to the project-centric approach described in the previous paragraph. Such aspects and concepts include schedule, budget and resources, deliverables, work-packages, constraints and precedence relations. The integrated system-project model should provide useful information on the mutual effects of project activities and system components and capabilities—processes it is designed to perform in order to provide value. Some examples of integrated system-project modeling are the following:

1. The set of project activities associated with a particular system component, feature, or capability,
2. The set of resources required for performing a task of designing or developing a particular component of the system,
3. The team or subcontractor responsible for delivering each system component,
4. The precedence dependencies between activities of system components deployment,
5. The cost associated with each system component, feature, or capability, and
6. The parts of the system negotiated for each delivery, deployment, build, release, or version.

The Work Breakdown Structure (WBS) is designed to support the division of the project scope (work content) amongst the individuals and organizations participating in the project (Golany and Shtub 2001). While WBS is traditionally organization or activity-oriented, one of its main cornerstones is the deliverable, which corresponds to the system, sub-system, component, or a capability or feature thereof. A deliverable-oriented WBS, in which the high-level elements correspond to primary sub-systems, is advocated in order to make the WBS more product-oriented (Rad 1999). An integrated approach to project planning and system modeling (Sharon and Dori 2009) merges the system model with the project’s WBS using Object-Process Methodology, OPM (Dori 2002). The unified OPM model captures both the project activities and the system components and functionalities.

The Design Structure Matrix (DSM) is a common method for enhancing and analyzing the design of products and systems. DSMs can be component-based, task-based, parameter-based, or team-based (Browning 2001). A DSM OPM-based project-product model derives a hybrid DSM of project activities and system building blocks from the unified OPM model, accounting for dependencies between project activities and system components, and replacing the two monolithic and hitherto separate component-based and task-based DSM views (Sharon, De-Weck, and Dori 2012). The underlying OPM model assures model consistency and traceability. The integrated project-product OPM model includes both a diagram and an equivalent auto-generated textual description. The DSM derived from this model visualizes a dependency loop comprising both system components and project activities.

Another model-based approach (Demoly et al. 2010) employs the System Modeling Language (SysML) in order to create various views that meet the needs of various system stakeholders, such as the project/process manager. The set of views includes product-oriented and process-oriented views.

Integrated Modeling of Systems and Requirements

Requirements are statements that describe operational, functional, or design-related aspects of a system. Requirements definition and management is a key SE process, as it both initiates and facilitates the entire SE effort by defining the expected functions and performance of the engineered system. Several challenges associated with requirements are a) to define the requirements in a structured, controlled manner, b) to trace these requirements to system components, aspects, and decisions, and c) to test and verify compliance of the system with these requirements. The extension of conceptual system models to include requirements has several significant benefits:

1. Requirements provide the rationale for the system's architecture and design by making and justifying architectural and design decisions based on specific requirements.
2. Modeling the internal logic and the hierarchy and dependency relations among requirements enables identification and elimination of redundant and contradictory requirements.
3. Responsibility for satisfying specific requirements can often be assigned to teams and persons responsible for delivering various system components. While the advantages of good requirements engineering is clear, it is often a challenge to directly trace requirements to specific system artifacts, especially when the requirements are defined in a holistic, solution-independent manner.

There are several methods to incorporate requirements into system models, including:

1. SysML Requirements Engineering.
2. Object-Process Methodology(OPM)-based Requirements Engineering and Authoring.

SysML-based Requirements Engineering

The SysML requirements diagram makes it possible to capture requirements and the relations among them in a visual manner, which is more intuitive than the textual manner in which requirements are traditionally edited and managed. The diagram was added to the basic set of UML diagrams that formed the basis for SysML (Friedenthal, Moore, and Steiner 2006), and is not a native UML diagram. Tracing requirements to the system blocks and artifacts satisfying them can be captured in the SysML Block Definition Diagram, which is primarily designated to capture the relations among types of system elements and components. The < > link between the block and the requirement captures the trace.

OPM-based Requirements Engineering

Object-Process Methodology (OPM) is a methodology and language for conceptual modeling of complex systems and processes, with a bimodal textual and graphical representation (Dori 2002). OPM’s textual representation is coordinated with the graphical representation, and each visual model construct in the Object-Process Diagram (OPD) is described by a formal structured textual statement in Object-Process Language (OPL), which is a subset of natural English. OPM facilitates model-based requirements engineering, authoring, and specification, in three possible modes: #) OPM can be used to generate conceptual models which initially focus on the requirements level—the problem domain, rather than the design level—the solution domain, facilitates automated model-based requirements generation (Blekhman and Dori 2011). The requirements model is solution-neutral, and it can be the basis for one or more architectural solutions for achieving the functions specified in the requirements. #) Using OPM in order to generate requirement-oriented OPDs in a manner similar to the SysML Requirements Diagram enables capturing requirements specification as the skeleton for the system model. User-defined tagged structural relations, such as "is realized by", is allocated to" provide for associating requirements with system model functions (objects and processes that transform them). This approach is similar to the SysML requirements diagram, but instead of using a unique notation in a separate diagram type, the requirements are seamlessly incorporated into the single system model. #) OPM can be used in order to generate visual system models from formally specified requirements, thereby tracing the textually authored requirements to system model inserts and artifacts (Dori et al. 2004).

Integrating Risk into System Models

Risk is an expression and a measure of the negative or adverse impact of uncertainty. Risk exists whenever uncertainty can lead to several results, of which some may be negative (adverse) and some positive. A system faces risks from other systems or from the environment, and it can also pose risks to other systems or to the environment. Systems are characterized by such attributes as goals, objectives, inputs, outputs, variables, parameters, processes, events, states, subsystems, interfaces, mechanisms, and methods. System vulnerability is the system's total potential to be harmed or negatively affected in any one of these attributes. Analogously, system harmfulness – is the system's total potential to harm others or to generate negative effects, which can be manifested in one or more of these attributes (Haimes 2009). Model-based risk analysis (MBRA) enables structured analysis and risk-related process control. Several model-based risk analysis approaches are available in the literature. MBRA is presently common in the information technology and information security domains much more than the systems engineering domain. However, some of the methods are generally applicable to complex systems as well. The ISO-IEC-IEEE collaborative software development and operation lifecycle standard (ISO and IEC 2004) proposes a concurrent approach to IT Risk Management. This approach consists of five main activities:

a.) Plan and implement risk management, b.) Manage the project risk profile, c.) Perform risk analysis, d.) Perform risk monitoring, e.) Perform risk treatment, and f.) Evaluate the risk management process.

These activities are executed concurrently, affect and provide feedback to each other, and interact with other software life cycle processes, such as the technical management and the design processes (ISO and IEC 2004).

The CORAS approach (Fredriksen et al. 2002; den Braber et al. 2006; Lund, Solhaug, and Stølen 2011) is a UML-derivative for IT security risk modeling and assessment. This framework consists mostly of the UML use case (UC) diagram, extended for misuse cases. Additional notation was added to the UC notation in order to capture risk sources, effects, and results (e.g., the “bad actor” icon, moneybag for asset-in-risk). A misuse diagram can include, for example, the risk of loss of legal protection of proprietary know-how due to information theft and distribution by an unfaithful employee. The treatment for the risk source of insufficient security policy, which contributes to the above risk, is illustrated in a separate treatment diagram.

A quantitative risk assessment method for component-based systems (Grunske and Joyce 2008) supports component vulnerability analysis and specification using modular attack trees. In addition, it provides attacker profiling, which enables supporting econometric approaches to risk response. The methodology utilizes SysML as its underpinning language, and especially the SysML block definition diagram and parametric diagram, in order to capture parametric relations and constraints as a means to defining risk profiles.

System-Theoretic Accident Model and Processes, STAMP (Leveson 2011) is a method for system and component design for safety. STAMP reformulates the safety problem as a control problem rather than a reliability problem. STAMP is optimized for safety-oriented systems engineering and design and for hazard avoidance and mitigation, especially in complex socio-technical systems. A model-based adaptation of STAMP was also proposed (Leveson 2004), and STAMP was implemented in various safety-critical and mission-critical systems, including aircraft collision avoidance systems, CAS (Leveson 2004) and ballistic missile defense systems (Pereira, Lee, and Howard 2006). Risk-Oriented Systems Engineering, ROSE (Mordecai and Dori 2013) is a method based on Object-Process Methodology (OPM) for integrating risk into system models. Being system-centric, ROSE calls for capturing risk layers and aspects on top of and in sync with the core system model, while improving and immunizing it against captured risks and generating system robustness and resilience by design in response to various risk-posing scenarios. The risk handling metamodel includes risk mitigation during the design phase and risk response during the operational phase.

References

Primary References

Dori, D. 2002. Object-Process Methodology – A Holistic Systems Paradigm. New York, NY, USA: Springer-Verlag.

Estefan, J. 2008. A Survey of Model-Based Systems Engineering (MBSE) Methodologies, Rev. B. San Diego, CA, USA: International Council on Systems Engineering. INCOSE-TD-2007-003-02. Available at http://www.incose.org/ProductsPubs/pdf/techdata/MTTC/MBSE_Methodology_Survey_2008-0610_RevB-JAE2.pdf.

Golany, Boaz, and Avraham Shtub. 2001. “Work Breakdown Structure.” In Salvendy, G. (ed.) 2001. Handbook of Industrial Engineering, Technology and Operations Management, 3rd ed. Hoboken, NJ, USA: John Wiley & Sons, Inc. 1263–1280.

INCOSE. 2012. INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities. Version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.

NASA. 2007. Systems Engineering Handbook. Washington, D.C.: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105.

Additional References

Blekhman, Alex, and Dov Dori. 2011. “Model-Based Requirements Authoring - Creating Explicit Specifications with OPM.” In 6th International Conference on Systems Engineering. Herzeliyya, Israel.

Browning, T.R. 2001. “Applying the Design Structure Matrix to System Decomposition and Integration Problems: a Review and New Directions.” IEEE Transactions on Engineering Management 48 (3): 292–306. doi:10.1109/17.946528. http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=946528.

Demoly, Frédéric, Davy Monticolo, Benoît Eynard, Louis Rivest, and Samuel Gomes. 2010. “Multiple Viewpoint Modelling Framework Enabling Integrated Product–process Design.” International Journal on Interactive Design and Manufacturing (IJIDeM) 4 (4) (October 12): 269–280. doi:10.1007/s12008-010-0107-3. http://link.springer.com/10.1007/s12008-010-0107-3.

Den Braber, Folker, Gyrd Brændeland, Heidi E. I. Dahl, Iselin Engan, Ida Hogganvik, Mass S. Lund, Bjørnar Solhaug, Ketil Stølen, and Fredrik Vraalsen. 2006. The CORAS Model-based Method for Security Risk Analysis. SINTEF, Oslo. Oslo: SINTEF.

Dori, Dov, Nahum Korda, Avi Soffer, and Shalom Cohen. 2004. “SMART: System Model Acquisition from Requirements Text.” Lecture Notes in Computer Science: Business Process Management 3080: 179–194. http://link.springer.com/chapter/10.1007/978-3-540-25970-1_12.

Kristiansen, Ba Gran, and K Stolen. 2002. “The CORAS Framework for a Model-based Risk Management Process.” In Lecture Notes In, edited by Stuart Anderson, Massimo Felici, and SandroEditors Bologna, 2434:94–105. Springer-Verlag. doi:10.1007/3-540-45732-1_11.

Friedenthal, Sanford, Alan Moore, and Rick Steiner. 2006. “OMG Systems Modeling Language ( OMG SysML ™ ) Tutorial” (July).

Grunske, L, and D Joyce. 2008. “Quantitative Risk-based Security Prediction for Component-based Systems with Explicitly Modeled Attack Profiles.” Journal of Systems and Software 81 (8): 1327–1345. Haimes, YY. 2009. “On the Complex Definition of Risk: A Systems-Based Approach.” Risk Analysis 29 (12): 1647–1654. http://onlinelibrary.wiley.com/doi/10.1111/j.1539-6924.2009.01310.x/full.

ISO, and IEC. 2004. “ISO/IEC 16085: Information Technology — Software Life Cycle Processes — Risk Management”. Vol. 2004.

Leveson, NG. 2004. “Model-based Analysis of Socio-technical Risk‏.”

Leveson, NG. 2011. Engineering a Safer World. MIT Press.

Lund, Mass Soldal, Bjørnar Solhaug, and Ketil Stølen. 2011. Model-Driven Risk Analysis: The CORAS Approach. Berlin, Heidelberg: Springer Berlin Heidelberg. doi:10.1007/978-3-642-12323-8. http://www.springerlink.com/index/10.1007/978-3-642-12323-8.

Mordecai, Yaniv, and Dov Dori. 2013. “Model-Based Risk-Oriented Robust Systems Design with Object-Process Methodology.” International Journal of Strategic Engineering Asset Management TBD (CESUN 2012 Special Issue).

Pereira, SJ, Grady Lee, and Jeffrey Howard. 2006. “A System-Theoretic Hazard Analysis Methodology for a Non-advocate Safety Assessment of the Ballistic Missile Defense System”. Vol. 1606. http://oai.dtic.mil/oai/oai?verb=getRecord&metadataPrefix=html&identifier=ADA466864.

Rad, Parviz F. 1999. “Advocating a Deliverable-oriented Work Breakdown Structure.” Sage, Andrew P., and William B. Rouse. 2011. Handbook of Systems Engineering and Management. Edited by Andrew P. Sage and William B. Rouse. 2nd ed. John Wiley & Sons.

Sharon, Amira, Olivier L De-Weck, and Dov Dori. 2012. “Improving Project-Product Lifecycle Management with Model-Based Design Structure Matrix : A Joint Project Management and Systems Engineering Approach.” Systems Engineering: 1–14. doi:10.1002/sys.

Sharon, Amira, and Dov Dori. 2009. “A Model-Based Approach for Planning Work Breakdown Structures of Complex Systems Projects.” In Proc. 14th IFAC Symposium on Information Control Problems in Manufacturing.

Wand, Yair, and Ron Weber. 2002. “Research Commentary: Information Systems and Conceptual Modeling?A Research Agenda.” Information Systems Research 13 (4) (December): 363–376. doi:10.1287/isre.13.4.363.69.

---

< 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