model based systems engineering (mbse) in …...model based systems engineering (mbse) in...

International Association for Management of Technology IAMOT 2018Conference Proceedings

MODEL BASED SYSTEMS ENGINEERING (MBSE) IN DEVELOPMENTPROJECTS: A FRAMEWORK FOR DEPLOYMENT

MR PHILIP STEYN*Graduate School for Technology ManagementUniversity of Pretoria, Pretoria, South Africa

[email protected]

PROF LEON PRETORIUSGraduate School for Technology ManagementUniversity of Pretoria, Pretoria, South Africa

[email protected]

ABSTRACT

Projects continue to suffer schedule and cost overrun. One cause of this is the conflictingrelationship between systems engineering and project management. The inherent natureof systems engineering is to work towards achieving requirements through an iterativeprocess of design influencing and design change. Because of the unpredictable nature ofthis iterative process, projects are prone to failure. This is because the projectmanagement process cannot account for the unpredictable systems engineering processimpact.

The purpose of this paper is to highlight the research done on the constructive andproactive deployment of design methods to improve the performance of systemsengineering within the development project environment.

Research is underway as part of a PhD project to further defines the relationship betweenMBSE deployment and effective project execution in a complex design and constructionenvironment.

For the purpose of the research presented in part here design methods such as SystemsThinking, MBSE, Axiomatic Design, Agile Design will be collectively referred to asStructured Design methods. This is because they share a number of the key attributesbeneficial to an optimized design process and successful project execution. StructuredDesign methods follow a predefined methodology with the objective of reducing risk andthe number of unplanned design iterations.

The research project reported on here in part will attempt to obtain empirical evidence tosupport these observations first through literature research then research questionnaires,interviews, case studies and system dynamic modelling. A framework for evaluating thedeployment of structured design methods in development projects will be put forward asan artefact of the research project. Design science research will eventually be used toevaluate this framework.

The framework presented for proactive deployment of structured design methods withina development project is based on a model based systems engineering methodology andincorporates a systems thinking approach.

The research findings is expected to give guidance to systems engineering practitionerson how to assess structured design methods considered for implementation indevelopment projects.

The paper provides novel approach to the deployment of structured design methods.

of 12

mailto:[email protected]


Key words: Structured design; Model based systems engineering; Framework;Deployment

* Corresponding author.

INTRODUCTION

Projects continue to suffer schedule and cost overrun. One cause of this highlighted byWessels (2012)is the conflicting relationship between systems engineering and projectmanagement. This is also emphasised by Martin when he elaborates on the conflictsbetween systems engineering and project management (Martin, 2000). Martin alsofocuses on the differences between systems engineering and “regular” engineering. Theinherent nature of systems engineering is to work towards achieving requirementsthrough an iterative process of design influencing and design change. The integratedapproach as part of a systems engineering process to achieving requirements is alsoaddressed for cases where technology and projects become increasingly complex(Rochecouste, 1996).Because of the unpredictable nature of this iterative process,projects are prone to failure. The unpredictability of new product development projects isalso highlighted by Fernandez and others when they focus also on the issue of tightplanning and coordination in such cases (Fernandes et al., 2009). This is because theproject management process cannot account for the unpredictable systems engineeringprocess impact. (Wessels, 2012)

The purpose of this paper is to highlight the research done on the constructive andproactive deployment of design methods to improve the performance of systemsengineering within the development project environment.

Related work by Componation et al. (2009) and Elm et al. (2008) reported on studies ofeffectiveness of systems engineering and project performance in general. Research bythe author is underway as part of a PhD project to further define the relationship betweenMBSE deployment and effective project execution in a complex design and constructionenvironment.

In the next section the research methodology is explained there after the deploymentframework is introduced. This is followed by a section on the development of thedeployment framework. The deployment framework is further elaborated regarding thesystems engineering domains it includes. The paper then considers a case study of amajor power industry development project to demonstrate the utilisation of thedeployment framework. Aspects observed such as constructive and destructive iterativedesign cycles, the role of constructive design methods to support / induce constructiveiterative design cycles and examples of constructive design methods are discussed.Systems dynamic modelling is also introduces as method of evaluating the impactstructured design methods.

RESEARCH METHODOLOGY

For the purpose of the research presented in part here design methods such as SystemsThinking(Flood, 2010, Forrester, 1999, Forrester, 1994), MBSE(Estefan, 2007) as part ofthe field of Systems Engineering (Oosthuizen et al., 2016, Holland, 2015), AxiomaticDesign(Guenov and Barker, 2005), Agile Design(Ferreira et al., 2007, Conboy et al., 2015)

of 12


will be collectively referred to as Structured Design methods. This is because they sharea number of the key attributes beneficial to an optimized design process and successfulproject execution. Structured Design methods follow a predefined methodology with theobjective of reducing risk and the number of unplanned design iterations.

The research project reported on here in part will attempt to obtain empirical evidence tosupport these observations first through literature research then research questionnaires,interviews, case studies and system dynamic modelling. A framework for evaluating thedeployment of structured design methods in development projects will be put forward asan artefact of the research project. A Design science research method(Conboy et al.,2015)will eventually be used to evaluate this framework.

INTRODUCING THE DEPLOYMENT FRAMEWORK

This paper presents a framework for deployment of structured design methodsproactively within a development project based on Model based systems engineeringmethodology and incorporating a systems thinking approach. The framework was derivedfrom the conceptual model presented in the next section. The framework is alsoconsistent with models presented by Erasmus and Doeben-Henisch (2011)and Long andScott (2011).

Table 1 illustrates a high level extract from this framework for the first two life cyclephases of a typical development project.

Table 1: Extract from Framework for deployment of structured design methods

Table 4at the end of article contains the complete framework.

The framework is built around three system engineering domains namely Requirements,Design and Execution. The following sections explain the basis and development of thisframework.

FRAMEWORKDEVELOPMENT

The deployment framework is derived from the conceptual model presented in Figure 1.The three perspectives of the system defined in the conceptual model: Requirements,Design and Execution, are mapped as the three parallel systems engineering domains ofthe framework. The framework is then mapped across the system life cycle phases fromRequirements definition to Disposal. (INCOSE, 2015). Each system engineering domain,life cycle stage combination is then elaborated to give content to the framework.

Complex design and construction environment

of 12


Figure 1: Conceptual model for deploying structured design methods

the model presented in Figure 1 is founded on the principle that the system design, ifconsidered to be an integrated system model, should be able to communicate thenecessary information relevant to each stakeholder’s perspective. (Long 2011)

The following key aspects can be observed from the model in Figure 1 to demonstratecongruence with the principle above:

I. The default perspective is suggested to be looking straight down on a conicalshape like a hill, the project goal (ie integrated system meeting all requirements)being the highest point of the hill. There are also perspectives from eachstakeholder. This represents the holistic or systems view as well as each stakeholder’s perspective of the same system design.

II. The stakeholders (eg. client, designer and contractor) are aligned to the samegoal although approaching from different perspectives. This is one thefundamentals of MBSE, to communicate various stakeholders according to theirdifferent perspectives.

III. The three main domains of development are Requirements, Design and Execution.They are closely integrated to each other. The interface between domains isdefined by a design baseline. The baseline between requirements and designdomains will be the Requirements baseline. That between the design andexecution domain the Design baseline. Between the execution and requirementdomain the Validation baseline.

IV. The framework represents a system towards dynamic equilibrium. That means thestakeholders are moving progressively towards the project goal centre of themodel. If there is disruption eg unexpected change or obstacle effort needs to beapplied to ensure that the stakeholders arrive at the intended goal. If not

of 12

Project

Goal

Client

Contractor(s)

..Designer(s)

Design Baseline

Design Methods


successful the eventual end point will be somewhere off centre meaning theproject was not entirely successful. For example there is some cost or scheduleover run.

V. Within this framework structured design methods are deployed to support theprogression towards the project goal and are selected based on the characteristicsof the design and construction environment.

VI. The achieved goal during the project life cycle is reflected through thecombination of the virtual and actual plant. MBSE provides a means to representand communicate the virtual plant to all stakeholders throughout the project lifecycle.

SYSTEM ENGINEERING DOMAINS

The three systems engineering domains used in the deployment framework representthree different perspectives to the system, which also aligned to the stakeholdersperspectives introduced in Figure 1.Each domain represents the system life cycle and canbe described in its own right.

REQUIREMENTS DOMAIN

The Requirements Domain focuses on the evolution of requirements through the projectlife cycle. It starts off with user requirements but then evolves through functionalrequirements, construction requirements and operating and maintenance requirements.The objective of this domain is not to explain how those requirements will be met ratherto maintain a complete requirements definition throughout the project life cycle. Thisdomain also focuses on the verification of requirements being met through the resultingdesign solution.

DESIGN DOMAIN

The Design domain is concerned with developing and documenting an executable designsolution. The design evolved from a logic design through basic design, detailed design, asbuilt design, as commissioned design and handed over design. The design is baselined ateach stage in the design domain through a set of design documents or design data.

EXECUTION DOMAIN

The execution domain converts the design information into a virtual or physical plantmodel. Early stages are focused on virtual models, first logic models then architecturalmodels, while later stages focus on physical plant being constructed, commissioned andhanded over. The virtual and physical plant models also serve as a basis for validatingthe plant in its operating domain.

BACKGROUND OF THE CASE STUDY

As a case study the framework has been used to map out the dominant iterative designcycles resulting from design changes during project execution.

The authors utilised design change data obtained from a major power industry project.Over the last 10 years nearly10,000 design changes were recorded on this project. Thedesign changes recorded in the last three years (2015 – 2017) were analysed during thiscase study.

of 12


Figure 2: Trend of design iterations during project life cycle

The graph in Figure 2demonstrates the trend in design iterations during the life cycle ofthe project. There are distinct periods evident during the life cycle.

I. Period 1: project start, initial design

II. Period 2: major integration

III. Period 3: Consolidation and convergence

This trend represents a largely reactive approach. This is further emphasised by mappingthe dominant types of design iterations against the framework in the next section.

ANALYSIS OF DOMINANT ITERATIVE DESIGN CYCLE

Table 2demonstrates the application of the framework to map out the iterative designcycles observed during the development project case study.

Table 2: Mapping of observed iterative design cycles

of 12


The observed design iterations where classified in three broad categories:

I. Design Errors (A)

II. System Integration (B)

III. System Improvements (C)

Design Errors where further decomposed into detailed design errors (A1) and functionaldesign errors (A2).

The mapping done here is not exhaustive and only done to illustrate the utility of theproposed framework to understand the nature and consequence of design changesresulting in iterative design cycles.

The design iterations classified as A and C are considered to be destructive as theyessentially revert back to a prior life cycle phase. Design iterations classified as B isconsidered to be constructive as it takes place in the same life cycle phase.

CONSTRUCTIVE VS DESTRUCTIVE ITERATIVE DESIGN CYCLES

The reactive trend of iterative design cycles are considered to be destructive as theiterative design cycle tend to have larger cost and time impact (eg rework) as well ascausing secondary changes. A conservative estimate would be that each reactive designchange causes at least one secondary design change.

An ideal state would be where proactive iterative design cycles could lead to theelimination of reactive design cycles at a lower cost and time impact.

Reactive design iterations are one of the main causes of conflict between systemsengineering and project execution as from a project management perspective thesereactive iterations are eroding project value.

ROLE OF DESIGN METHODS TO SUPPORT/INDUCE CONSTRUCTIVE ITERATIVE DESIGN CYCLES (CONSTRUCTIVE DESIGN METHODS)

The case for front end engineering is well known, the principle being that major issuesduring project execution can be avoided with sufficient upfront engineering(Steinert andJablokow, 2013). This also holds for methods such as MBSE.

The focus now shifts to understanding which design methods should be employed toachieve a meaningful benefit. There is a myriad of methods to choose from and not allwill have the desired effect.

of 12


When analysing the framework presented in Table 2 with respect to the destructive orreactive iterative design cycles A and C observed, the need and place for proactiveiterative design cycle brought about by constructive design methods becomes apparent.Table 3 demonstrates the introduction of constructive design methods to induceproactive iterative design cycles.

Table 3: Introduction of constructive design methods

If constructive design methods were to be introduced they are expected to result inconstructive design iterations that can be mapped on the deployment framework by thearrows D, E and F as indicated in Table 3.

The objective of these induced design cycles will be to minimise the reactive designcycles A1, A2 and C.

SYSTEMS THINKING APPROACH

The principle of proactive design iterations can also be demonstrated through a SystemsDynamics approach. Steyn (2017) expanded on a systems thinking approach to, with theuse of system dynamic modelling, describe the relationship between conflict and projectstress. Figure 3 illustrates how a causal loop diagram can be constructed that includesthe influence of constructive design methods on the observed reactive design iterations.

of 12


Figure 3: Causal loop diagram for the effect of constructive design methods.

EXAMPLES OF CONSTRUCTIVE DESIGN METHODS

Constructive design methods should be selected based on their potential for delivering adesired outcome. For example the appropriate constructive design method for resolvingphysical interface issues during construction could be 3D modelling. This is typically whatwas observed in the design cycles denoted as B in Table 2.

On the other hand logic design issues are best resolved early through the use ofExecutable Functional Block Diagram (EFBD). This will be a candidate method forinducing proactive design iterations denoted D in Table 3.

Design improvements can be identified early through utilisation of axiomatic designprinciples and tools such as design matrices to identify coupled designs. This will be acandidate method for inducing proactive design iterations denoted E in Table 3.

The objective of this case study is not be explicit about which constructive designmethods to use but to point out that there is a logical framework for selecting theappropriate method to suite a desired outcome. It is even possible that completely newmethods may be derived that are more suitable than existing methods to achieve aspecific outcome in terms of the desired proactive iterative design cycles.

EVALUATION OF METHODS

The framework presented here also provides the opportunity to evaluate existing designmethods in the context of the observed reactive iterative design cycles. This may lead tofindings such that the existing methods are exercised at the wrong point the project lifecycle; are not achieving the desired result; are the wrong method ect.

Applying this reasoning the case study for instance reveals that insufficient effort is spentof verifying integrated logic design early in project life cycle. The methods used are notable to identify complex interface design issues resulting in design changes duringconstruction and commissioning phases looping back logic design.

FINDINGS

of 12


The relationship between Systems Engineering and project execution is conflicting innature. In an unconstrained environment this may eventually be resolved. In aconstrained environment, however, the capacity to resolve conflict diminishes to thedetriment of project performance. Structure design methods need to be geared toproactively deal with this potential for conflict.

It is therefore possible to take a proactive approach by employing constructive designmethods to induce proactive design iterations early in project life cycle to reduce thereactive design cycles typically observed.

This can be accomplished through a deployment framework as illustrated in this paper. Itis suggested that through thorough analysis of the observed reactive design iterationsappropriate proactive design iterations can be identified and introduced at earlier phasesin project life cycle. The consistent and early adoption of such a design managementstrategy will help reduce the project stress through avoidance of cost and scheduleincreases.

RESEARCH LIMITATIONS AND IMPLICATIONS

The research presented in this paper is limited to a case study of a major power industrydevelopment project in South Africa. The case study is however relevant and findingstransferable to other areas because of the extended period over which data werecollected and general nature of the observations.

The research findings is expected to give guidance to systems engineering practitionerson how to assess structured design methods considered for implementation indevelopment projects.

ORIGINALITY/VALUE OF THE PAPER

The paper provides novel approach to the deployment of structured design methods.

CONCLUSION

The framework presented here does provide a usable methodology for deployment ofconstructive design methods including MBSE within a development project. Therelationship between constructive design methods and the desired outcomes are evidentand suitability of existing design methods can be assessed.

ACKNOWLEDGEMENTS

REFERENCES

Componation, P. J., Utley, D. R., Farrington, P. A. & Youngblood, A. D. Assessing the Relationships between Project Success and Systems Engineering Processes at NASA. IIE Annual Conference, 2009. Institute of Industrial and Systems Engineers (IISE), pp. 456.

Conboy, K., Gleasure, R. & Cullina, E. Agile design science research. InternationalConference on Design Science Research in Information Systems, 2015. Springer, pp. 168-180.

Elm, J. P., Goldenson, D., El Emam, K., Donatelli, N., Neisa, A. & Committee, N. S. E. 2008. A Survey of Systems Engineering Effectiveness-Initial Results.

Erasmus, L. D. & Doeben-Henisch, G. A theory for the systems engineering process. AFRICON, 2011. IEEE, pp. 1-5.

of 12


Estefan, J. A. 2007. Survey of model-based systems engineering (MBSE) methodologies. Incose MBSE Focus Group, 25.

Fernandes, A. A., Da Silva Vieira, S., Medeiros, A. P. & Natal Jorge, R. M. 2009. Structured methods of new product development and creativity management: A teaching experience. Creativity and Innovation Management, 18, 160-175.

Ferreira, J., Noble, J. & Biddle, R. Agile development iterations and UI design. Agile Conference (AGILE), 2007. IEEE, pp. 50-58.

Flood, R. L. 2010. The relationship of ‘systems thinking’to action research. Systemic Practice and Action Research, 23, 269-284.

Forrester, J. W. 1994. System dynamics, systems thinking, and soft OR. System dynamics review, 10, 245-256.

Forrester, J. W. 1999. System dynamics: the foundation under systems thinking. Sloan School of Management, Massachusetts Institute of Technology, Cambridge, MA, 2139.

Guenov, M. D. & Barker, S. G. 2005. Application of axiomatic design and design structure matrix to the decomposition of engineering systems. Systems engineering, 8, 29-40.

Holland, O. T. 2015. Model-Based Systems Engineering. Modeling and Simulation in the Systems Engineering Life Cycle. Springer.

Incose 2015. Systems Engineering Handbook, Wiley, (San Diego).Long, D. & Scott, Z. 2011. A primer for model-based systems engineering, Lulu.

com, Martin, J. N. Systems Engineering is Not Just Engineering—Or is It? A Critical Look

at the Scope of our Profession. INCOSE International Symposium, 2000. Wiley Online Library, pp. 727-734.

Oosthuizen, R., Swart, I. & Pretorius, L. An initial bibliometric analysis and mapping of systems engineering research. INCOSE International Symposium, 2016. Wiley Online Library, pp. 2241-2255.

Rochecouste, H. Engineering Information Systems and the IEEE Std 1220–1994. INCOSE International Symposium, 1996. Wiley Online Library, 316-323.

Steinert, M. & Jablokow, K. Triangulating front end engineering design activities with physiology data and psychological preferences. 2013. The Design Society.

Steyn, P. J., Pretorius, L. 2017. Aspects of Systems Thinking and Model Based Systems Engineering (MBSE) in Project Management. 5th Annual System Dynamics Conference. Johannesburg.

Wessels, A. 2012. The Development of Complex Systems: An Integrated Approach to Design Influencing. Philosophiae Doctor, University Of Pretoria.

of 12


Table 4: Full Deployment framework

of 12

model based systems engineering (mbse) in …...model based systems engineering (mbse) in...

Documents