IN THIS EDITION
1. Quotations to Open On
2. Feature Articles
2.1 The MBSE Horizon: Advances and Challenges over the Next Few Years by James Towers
2.2 Tutorial: Why the SEMP is not Shelfware – How to Write a SEMP to Ensure it Delivers Value to All by Ian Presland and Becky Reed
3. Additional Article
3.1 Strengthening Technical Leadership for Systems Engineers by Nelson Ruiz
4. Systems Engineering News
4.1 Model-Based Systems Engineering Maturity Benchmark Survey: Your participation is invited
4.2 Trinity Hall Lauded for STEM Achievements
4.3 Systems Engineering Publishes Special Issue Concerning System of Systems Engineering
4.4 Project Management Institute Issues New Standard for Earned Value Management
4.5 Systems Thinking Daily (STDaily) Group on Facebook
4.6 2020 INCOSE Officers and Directors
4.7 Call for Papers Special Issue of Mind & Society Advanced Modeling of Organizational Behavior
4.8 Systems Engineering Tools Database Prototype Demonstration at the INCOSE IW 2020
5. Featured Organizations
5.1 Systems Engineering Advancement Research Initiative (SEAri)
5.2 Fraunhofer Institute for Experimental Software Engineering (Fraunhofer IESE)
6. News on Software Tools Supporting Systems Engineering
6.1 Jama Software On-demand Webinar: Tips and Tricks for Better Reviews
6.2 UAF Special Event: Actionable Architecture in the 21st Century Special Event
6.3 The REUSE Company Develops Capella Integration Tool
7. Systems Engineering Publications
7.1 Model-based Systems Engineering: An Introduction to the Mathematical Theory of Discrete Systems and to the Tricotyledon Theory of System Design
7.2 International Journal on Software and Systems Modeling (SoSyM)
7.3 Think Engineer
7.4 Systemic Change Management
7.5 Accelerating the Development of Senior Systems Engineers
7.6 Emergent Behavior in Complex Systems Engineering: A Modeling and Simulation Approach
7.7 The Standard for Earned Value Management
7.8 Performance-Based Earned Value
8. Education and Academia
8.1 Challenges and Best Practices in Systems Engineering Across Innovative Companies in the German-speaking Region
8.2 University of Technology of Compiègne
8.3 Delft University of Technology
9. Some Systems Engineering-Relevant Websites
10. Standards and Guides
10.1 OMG System Modeling Language, SysML® Version 1.6 Released
10.2 New PMI Standard for Earned Value Management
11. Some Definitions to Close On
11.1 Acceptance
11.2 Function
11.3 Integration
12. Conferences and Meetings
12.1 The International Conference on Design Engineering and Science – February 27-29, 2020 (Shenzhen, China)
13. PPI and CTI News
14. PPI and CTI Events
15. Upcoming PPI Participation in Professional Conferences
1. Quotations to Open On
“The true professional represents things as she or he sees them, not just as represented by the heard. Galileo wasn’t popular, but he was right. Be true to oneself.”
Robert John Halligan
“Team work makes the dream work.”
John C. Maxwell
“To finish the moment, to find the journey’s end in every step of the road, to live the greatest number of good hours, is wisdom.”
2. Feature Articles
2.1 The MBSE Horizon: Advances and Challenges over the Next Few Years
by
James Towers
Email: james.towers@scarecrowconsultants.co.uk
Abstract
The most significant development on the MBSE horizon is the forthcoming submission of the SysML v2 proposal which diverges SysML from its origins as a Profile of UML. While this is a welcome and necessary development, language is only one of the critical aspects of MBSE; there is still additional work to be done in terms of methodology, organizational capability, practitioners’ competence, and tool functionality and usability. This article explores the need for the new direction of SysML v2 and provides views of leading figures in the industry concerning their thoughts about where MBSE is and should be heading.
Copyright © 2020 by James Towers. All rights reserved.
Introduction
It seems hard to believe that the Systems Engineering Domain Special Interest Group (SE DSIG), a joint venture between the Object Management Group (OMG), and the International Council on Systems Engineering (INCOSE), turned eighteen years old in 2019. Its charter was established at the OMG technical meeting in Danvers on July 9th, 2001. While the SE DSIG can’t claim to be the founders of Model-Based Systems Engineering (MBSE), it could be argued that they are responsible for much of its modern form and direction, through the development of the Systems Modeling Language (SysML) used by the majority of modern MBSE practitioners. Eighteen plus years seems long enough for us to consider this a mature endeavor[1], so this is an appropriate opportunity to reflect on where we are with MBSE with SysML, where we are heading, and what are the strengths, weaknesses, opportunities, and threats it faces as an approach to Systems Engineering (SE).
SysML v2
While the SE DSIG received its charter in 2001, it wasn’t until six years later that v1 of the SysML was adopted in September 2007. Subsequently there have been six revisions with the latest, version v1.6, adopted in December 2019. So far, they have all been minor revisions focusing on missing or inconsistent aspects of the specification, documentation errors, a few simplifications,[2] and other semantic and syntax changes driven by practical usage of the language.
SysML v1 was defined as an extension (in UML terms, a Profile) of the OMG’s software modeling language, the Unified[3] Modeling Language (UML) v2, the first version of which was adopted in July 2005. The use of a Profile to extend UML for SysML has both advantages and disadvantages. One of the advantages is that many of the semantics of UML are sufficiently abstract that they are readily transferable to SE. Actually, before SysML, many practitioners, including myself, were engaged in MBSE with UML. One of the disadvantages of using UML as the foundation is that the development of SysML is then coupled (for some aspects tightly) to the semantics and occasional ambiguities and peculiarities of the underlying UML. It has not been uncommon for the SysML revision process to be dependent or even restricted by the need to first enhance the UML specification. Additionally, as the use of SysML has become further widespread and more mature, systems modeling practitioners, tool vendors, and methodologists have all identified new requirements to enhance the language.
There is frequent discussion about whether the underlying Object-Oriented paradigm of UML is appropriate to meet the needs of SE. While it may be possible to evolve the UML metamodel in order to address the requirements of SE, there is a danger that by doing so, SysML could add unnecessary[4] and confusing semantics or syntax, which may hamper the users of UML. With these drivers in mind, in addition to the overarching objective of increasing the adoption of MBSE by enhancing; precision and expressiveness, consistency and integration between language concepts, and usability by model developers and consumers, the OMG issued a Request for Proposal (RFP) for SysML v2 in December 2017.
The SysML v2 RFP includes the requirement that submissions should “include both a SysML profile of UML and a SysML metamodel, and a mapping between them. In addition, submitters have the option to specify additional features that include model interchange and formal semantics.” This separation allows the new SysML v2 metamodel to be more compact, better aligned, and evolve independently from the UML metamodel which underpins SysML v1. The inclusion of an additional UML profile should ensure that the language is backwards compatible (as far as can be possible) and that it can be implemented within UML v2 based tools. The latter is an issue that was an initial concern for tool vendors when the move to an independent metamodel was first suggested.
In June 2018 a second RFP for “SysML v2 API and Services” was issued to “enable interoperability between SysML modeling tools and other model-based engineering tools”, something which had long been a criticism and potential barrier to adoption of MBSE with SysML v1.
In December 2007 a SysML Submissions Team (SST) was formed to respond to the first, and then subsequently, the second RFP. The team, jointly lead by Sandy Friedenthal and Ed Seidewitz, comprising a diverse team of end-users, tool vendors, academics, and governmental representatives, with over one hundred members from over sixty organizations. These submissions are being driven by the RFP requirements and user needs, and the team has adopted an “agile collaborative approach” to its development. The planned enhancements in SysML v2 can be categorized by the following themes:
- Usage Focused Modeling – A paradigm shift to make the language more precise and intuitive to use through the greater emphasis of ‘usages’, e.g. more can be done with Internal Block Diagrams (IBD) rather than the current focus on type definitions with Block Definition Diagrams (BDD). These changes will, in turn, support other language requirements such as variant specification and configurations, individuals and snapshots[5] and improved analysis and verification.
- A new metamodel not constrained by UML. This meta-model will be grounded in formal semantics. It will be minimalist (less than one hundred elements compared to UML which has over two hundred elements) and is based on the Kernel Modeling Language (KerML).
- A new textual representation based on the Action Language for fUML (Alf), which provides a powerful and concise alternative to the graphical representations.
- Robust visualizations based on flexible view and viewpoint specifications, and
- Standardized API access to the model, which can be summarized by the following ‘Logical Architecture for a SysML v2 System Modeling Environment’ proposed by the SST.
Figure : Logical Architecture for a SysML v2 System Modeling Environment
View from the front line
To better understand the current position and future direction of MBSE with SysML, I asked some of the authors and practitioners in the field a broad question – “What are the current strengths, weaknesses, opportunities, and threats facing MBSE?” The following sections summarize some of their responses that were provided, together with my own thoughts. A list of the contributors is provided in the acknowledgements section.
Strengths
With respect to strengths, the consensus is that the size of the community, the increasing number of books and conference papers, plus the growing demand for training and consultancy all suggest that the approach has a burgeoning and robust foundation. The increased adoption by industry (although perhaps not at the rate some of us would like!) also suggests that MBSE with SysML is firmly embedded within the overall SE culture.[6] As Rick Steiner of Skygazer Consulting, an MBSE and SysML author, Instructor at UC San Diego Extension and OMG contributor, put it – “[there is] a growing awareness that MBSE is in fact a viable approach to engineering complex systems. This is being expressed as increasing enrolment in SysML and MBSE courses, as well as an increasing number and extent of organizational MBSE related initiatives in defense, government, and industry.” Tim Weilkiens, of OOSE Innovative Informatik eG, an MBSE and SysML author, lecturer, and OMG contributor further elaborated by writing – “I think the strengths of MBSE are pretty clear and identified in many publications. It can be summarized under the term mastering complexity: No one can really believe that we can master complex systems with Word, PowerPoint, and Excel. In the past, our systems were less complex, and the market environment and system architectures were more stable. The engineering organization including its processes covered inherently the system architecture. So, there was no big need for specifying the system level explicitly.” It is perhaps most telling that Tim can answer the question by initially directing us to the existing body of knowledge in the “many publications”.
Weaknesses
The views on apparent weaknesses were quite diverse, and only one of the commentators directly identified SysML v1 as a problem. The reason for this could be because as the SysML v2 process is ongoing, many people may consider it ‘fixed’. Alternatively, it could be that the majority of practitioners and implementations are not yet mature enough for the limitations of the language to be a visible problem.
When considering weaknesses, Raphaël Faudou of Samares Engineering pointed to the lack of a generic shared MBSE process – “There are several approaches, but none is generic enough to be considered as a good starting point shared by the whole community. So, we see most industrial companies defining their own method and customizing MBSE tools to support it.” Rick Steiner noted that SE maturity was sometimes an issue – “SE organizational maturity must be suitably advanced before MBSE can be successfully deployed. Discovering a low level of SE maturity can be both difficult and traumatic for an engineering organization.” He also highlighted that the management obsession of harvesting ‘low hanging fruit’ often drives expectation – “Finding specific areas where MBSE deployment can add immediate, irrefutable value requires considerable effort and cooperation across organizational stovepipes in an engineering organization.” This view resonates with my experience. It is not unusual for organizations relatively new to MBSE to expect measurable returns within very short timeframes or to want to introduce advanced techniques such a variant modeling from day one. This challenge is not surprising when it is noted that there is very little material published on how to transition from document-based to model-based systems engineering.
Considering the current tools and languages, Tim Weilkiens was critical: “The MBSE tools are still at the level of the 90’s. The usability is a nightmare and basic features common in other engineering disciplines are rarely available. Another weakness is probably the language SysML, but with SysML v2 we are on a very good way.” Similar sentiments about the languages were expressed by Dave Banham of BlackBerry QNX and an OMG contributor – “[MBSE languages] are all flawed by being niche (limited ecosystem), lacking in expressiveness, divergent in interpretation/use, and generally have no or limited means of validating the model with formal verification of properties or at best model execution.” As suggested by Tim Weilkiens, some of these issues may be addressed by SysML v2. However, Dave Banham further went on to suggest what could be done to improve tooling – “[the OMG] needs to enforce a tool certification program for vendors to be able to use the modeling language brand name. It’s that lack of enforcement that has allowed vendor solutions to drift.” Returning to perceived weaknesses, Tim Weilkiens also discussed educational requirements for successful MBSE: “Too few people are familiar with systems thinking, abstractions, and modeling (not SysML/UML, but metamodels and other modeling theory)”. This is perhaps particularly evident within the SysML v2 SST which, while including over one hundred members, the majority of its intellectual effort is provided by approximately twenty key contributors.
Opportunities
Thinking about the opportunities ahead, Rick Steiner highlighted that it was no longer just the SE technical processes[7] such as ‘stakeholder needs and requirements definition’ or ‘architecture definition’ that were taking advantage of MBSE; “specialty engineering (Reliability, Safety, Availability) are well-positioned to also realize great benefit from MBSE, if properly emphasized during program development.” An illustration is the RFP for “Safety and Reliability for UML” issued by the OMG in 2017 to define a UML profile for this purpose. Tim Weilkiens looked at the opportunities from the perspective of the System of Interest (SOI) – “[in the future] engineers can do engineering again instead of copy & paste tasks, reading thousands of textual requirements, managing traceability matrices, etc. When engineers do real engineering again, they will build great systems again.” Dave Wood of Harris Corporation pointed to the Department of Defense (DOD) ‘Digital Engineering Strategy’ as a driver for opportunities with MBSE – “Now we are seeing RFPs (requests) that require an MBSE model. Like industry changed after WWII and the space race (and the WWW) I think this mandate by the DOD will accelerate MBSE adoption in Systems Engineering and bring all sorts of unexpected changes: SysML/XMI libraries of common parts we can all use for free (thank you OMG), Architectural Patterns (like Christopher Alexander), Machine Learning algorithms that analyze system architecture, ‘Digital twins’ that track the life of each aircraft and ship, and a seamless integration of engineering even better JPL’s OpenMBEE.” Dave’s outlook is possibly the most optimistic of those given, but if only one of his predictions comes true, it is undoubtedly an exciting time to be involved in MBSE.
Threats
Several of the commentators highlighted that while SysML v2 provided a great opportunity to increase the benefits and usability of MBSE, it also presented significant risk. Even with successful adoption of the standard we are still reliant on usable and compliant implementations from tool vendors. Tim Weilkiens echoed these thoughts, and it is also significant to consider Raphaël Faudou’s insight: “Taking a long time to get SysML 2.0 and fragmentation of SysML 2.0 are threats for me. If there are too many actors willing to achieve a too large scope, there might be nothing before 5 years, which could lead to deception in the SysML community and movement in large industrial companies to other none-SysML tools (Capella, Simulink, and Modelica) to implement their MBSE method.”
Rick Steiner thought there were at least four different threats to the discipline as a whole:
- SE Maturity – “Organizations that attempt to deploy MBSE tools and training without sufficient SE maturity (processes, culture, and support) inevitably fail to provide value, and then blame MBSE for their SE shortcomings.” There is certainly a lot of anecdotal evidence of this occurring historically with UML for software development.
- A lack of understanding concerning what MBSE is – “There is a perception that MBSE is “only for software” and doesn’t apply to non-software systems. This is pervasive in the mechanical engineering community but can show up elsewhere.” This is possibly a manifestation of the ‘not invented here’ anti-pattern (Brown et al. 1998).
- A failure to recognize the limitations of document-based approaches, particular concerning scale and complexity – “If the systems being developed are not particularly complex, organizations often make do using MS Office, requirements management tools, and traditional document-based SE. It is tempting to try to “scale up” these techniques as systems inevitably become more complex, rather than invest in the culture shift and retraining required for MBSE.” This is illustrated by the different rates of adoption of SE across different industries as they reach their ‘tipping point’ at different times.
- A general cautious attitude and reluctance to change – “Complex system developers with a history of successful projects that relied on detailed customer-provided requirement specifications (such as in defense projects) often see no need to change their SE processes. Their system acquisition customers in government organizations will have to change the acquisition model before MBSE becomes meaningful. Note that this is beginning to happen in many cases, but every supplier must have appropriate incentive and accountability before multi-level MBSE can be effective.” Hopefully the DODs ‘Digital Engineering Strategy’ will contribute to this.
Returning to one of the topics raised by Raphaël Faudou, we need to be mindful that SysML isn’t the only language in town. For users of the Capella tool (from the Eclipse Foundation), the chosen language is a domain-specific language (DSL) with many overlapping concepts with SysML v1. The tool also embeds the Arcadia Method, so in that sense, the Capella language can’t be thought of as a general-purpose modeling language in the same way as SysML which is not tied to any one approach[8]. With the arrival of SysML v2 it is not known if the Capella DSL will evolve in a similar fashion or whether it will result in a larger divergence between the two. The threat to MBSE could therefore be that the choice of languages and perceived inability to switch makes the take-up look even more onerous than it is now. The lack of a diagram interchange standard currently makes tool migration very difficult even if they both use the same language, which is something many users are hoping the SysML v2 API approach will facilitate.
The use of languages such as Simulink, with its foundations in control theory, or Modelica, which while aimed at cyber physical systems is firmly grounded in multi-physics simulation and physical-system modeling, both play important roles in an overall model-based engineering (MBE) approach. The question is, though: “Do you need multiple languages, and if so, which language is best suited to which purpose?” The challenge, as always, is tool-interoperability. If a key aim of MBSE is to provide ‘a single source of truth’, then having multiple tools, using different languages, and which are not connected, will only ever provide ‘multiple sources of half-truths’ at best: something which is only marginally better than traditional document-based approaches.
Finally, another language which could be described as being in competition with SysML is the Object-Process Methodology (OPM) specified as the International Standards Organization, Publicly Available Standard (ISO/PAS) 19450. Perhaps the formal standards-based and general-purpose nature of OPM makes it the closest rival to SysML. Like Capella, and as its name suggests, OPM has a built-in methodology. Being tied to a methodology is not necessarily a disadvantage, but it does mean that users have less freedom, when transitioning from a document-based approach with an existing SE process. On the flipside, for organizations without a well-defined SE process, it provides one more thing they need straight out of the box. The biggest difference between SysML and OPM is their underling paradigms – while SysML v1, is based on the Object-Oriented approach of UML reusing the concepts of Structure and Behavior and adding the concepts of Requirements and Parametrics, OPM is based around the generalized concept of ‘Things’ which are then specialized into ‘Objects’ and ‘Processes’ and may appear on the same view. OPM has a smaller meta-model than UML v2, precise semantics and a textual notation, all things planned to be improved or included in SysML v2. However, the current version of OPM lacks the concept of Parametrics used for engineering analysis, it is currently only supported by a small number of tools and has limited literature. There is no doubt that OPM is a capable and powerful language; the challenge for SysML v2 then is to adopt those features which it does better than SysML v1.
Summary and Conclusions
Model-Based Systems Engineering is here to stay, and while continued increased adoption may see a reduction in document-based approaches, it will never wholly supersede them. In the same way that driving has not eliminated walking and television has not killed radio, there will always be low risk or low complexity projects where the flexibility and informality of a document-based approach is sufficient. Conversely, there is a growing number of engineering projects which are reaching their ‘tipping point’ in terms of what can be achieved through scaling legacy approaches.
SysML v1 has served the community well over the past twelve years, but we are starting to outgrow it. SysML v2 provides an opportunity to define an enhanced language that not only meets the growing demands of the most advanced organizations (by introducing the ability to perform tasks such as variant modeling and better engineering analysis such as reliability, availability, maintainability, and safety modeling), but also, by making the language more intuitive (from an SE practitioner’s perspective) and by increasing the accessibility and usability for less mature organizations and users.
A new version of the language introduces risks as well as benefits. How will practitioners, especially those who are well versed (possibly even certified) with SysML v1, adapt to SysML v2? What will be the commercial impact on organizations that provide tools, training, and methodologies aligned to SysML v1? These questions have yet to be answered. The language used is only one aspect of MBSE, as our commentators have described, successful MBSE requires competent practitioners, appropriate methods, and usable and compliant tools. Perhaps then, the forthcoming arrival of SysML v2 is not the announcement of a new era in MBSE just yet, but rather a call for educators, methodologists, and tool vendors to step up to the plate.
List of Acronyms Used in this Paper
Acronym Explanation
Alf Action Language for fUML
DOD Department of Defense (United States of America)
DSIG Domain Special Interest Group
DSL Domain-Specific Language
fUML Foundational Subset for Executable UML
INCOSE International Council on Systems Engineering
ISO International Standards Organization
KerML Kernel Modeling Language
MBE Model-Based Engineering
MBSE Model-Based Systems Engineering
OMG Object Management Group
OMT Object-Modeling Technique
OOSE Object-Oriented Software Engineering
OPM Object-Process Methodology
PAS Publicly Available Standard
SE Systems Engineering
SOI System of Interest
SysML Systems Modeling Language
UML Unified Modeling Language
Acknowledgements
My thanks go to the following people for their published works and individual insights which contributed to this article:
- Dave Banham – BlackBerry QNX and an OMG contributor http://blackberry.qnx.com
- Dave Wood – L3 Harris Technology, MBSE provocateur, and Systems Engineer https://www.harris.com
- Ed Seidewitz – Model Driven Solutions, creator of ALF and SysML v2 SST co-lead http://www.modeldriven.com
- Graham Bleakley – IBM, OMG UAF Co-chair and OMG contributor https://www.ibm.com/
- Rick Steiner (RS) – Skygazer Consulting, MBSE & SysML author, instructor at UC San Diego Extension and OMG contributor. http://skygazerconsulting.com
- Raphaël Faudou (RF) – Samares Engineering http://www.samares-engineering.com/en/
- Sandy Friedenthal (SF) – SAF Consulting, MBSE & SysML author, SE DSIG Chair and SysML v2 SST co-lead
- Tim Weilkiens (TW) – OOSE Innovative Informatik eG, MBSE & SysML author, lecturer and OMG contributor https://www.oose.de
UML® and SysML® are registered trademarks of the Object Management Group
References
Brown, William, Raphael Malveau, Hays McCormick III and Thomas Mowbray. AntiPatterns, Refactoring Software, Architectures, and Projects in Crisis. USA: Wiley Computer Publishing, 1998, ISBN 0-471-19713-0
Bleakley, Graham, SysML v2 Submission Team (SST) SysML v2 Submission Overview & Status, Presentation to the INCOSE UK MBSE Interest Group, Lincoln UK, 19th September 2019. http://www.incosewiki.info/Model_Based_Systems_Engineering/Files/e/eb/Ad-19-03-01_INCOSE_UK_MBSE_.pdf
Cappella https://www.eclipse.org/capella/
Friedenthal, Sandford. SysML v2 Submission Team (SST) SysML v2 Update, INCOSE International Workshop, Torrance, CA, 26th – 29th January 2019. http://www.omgwiki.org/MBSE/lib/exe/fetch.php?media=mbse:incose_mbse_iw_2019:12_sysml_v2_update-friedenthal-incose_iw_presentation-2019-01-27.pdf
INCOSE, https://www.incose.org
ISO/PAS 19450:2015 Automation systems and integration — Object-Process Methodology https://www.iso.org/standard/62274.html
Kemp, Duncan, Dawn Gilbert and Ben Mogridge. Horizon Scanning to Discover the Future of Systems Engineering, Leeds UK, 2019, INCOSE UK Annual Systems Engineering Conference.
The Modelica Association https://www.modelica.org
OMG, d/17-03-05 (Safety and Reliability for UML RFP), https://www.omg.org/cgi-bin/doc.cgi?ad/2017-3-5
OMG, ad/17-12-02 (Systems Modeling Language (SysML) v2 RFP), https://www.omg.org/cgi-bin/doc?ad/2017-12-02
OMG, ad/18-06-03 (SysML v2 API and Services RFP), https://www.omg.org/cgi-bin/doc?ad/2018-06-03
OMG, SE DSIG, https://www.omg.org/syseng/
OMG, SE DSIG, Charter, Danvers, Massachusetts, July 9 – 13, 2001, https://www.omg.org/cgi-bin/doc?dtc/2001-07-02
OMG, SysML, http://www.omgsysml.org
OMG, UML, https://www.uml.org
Walden, David, Garry Roedler, Kevin Forsberg, R. Douglas Hamelinn and Thomas Shortell. Systems Engineering Handbook: A guide for systems life cycle processes and activities, 4th Edition. San Diego, CA: Wiley, 2015, ISBN 978-1-118-99940-0
About the Author
James holds a bachelor’s degree with honors in Electrical and Electronic Engineering from the Nottingham Trent University which he earned in 1996. Since then he has had a varied career in software and systems modeling and has presented both papers and tutorials at conferences and seminars as well as writing and delivering training courses on the subject. James has provided consultancy, training, and mentoring to various organizations working in aerospace, automotive, consumer electronics, defense, finance, information technology, power electronics, telecommunications, rail, retail, and supply chain. He is a Charted Engineer; an OMG Certified UML professional and member of the IET and INCOSE UK where he is co-chair of the UK Model-Based Systems Engineering (MBSE) Working Group. He is also a visiting lecturer in MBSE at the University of Warwick.
2.2 Tutorial: Why the SEMP is not Shelfware
How to write a SEMP to ensure it delivers value to all
SEMP = Systems Engineering Management Plan
The file provided using the link at the end of this article is a tutorial developed by Becky Reed and Ian Presland that provides detailed guidance concerning how to write a vital systems engineering document sometimes known as the Systems Engineering Management Plan (SEMP), alternatively as the Systems Engineering Plan (SEP).
The Learning Objectives of the tutorial are to:
- Explain why a SEMP is required for any systems engineering project;
- Identify SEMP stakeholders and their needs;
- Summarize why a well-constructed SEMP delivers value;
- Identify how a SEMP fits within a typical document hierarchy;
- Describe the “lifecycle” of a SEMP: when it is initiated, how it is used, and when it should be updated;
- Summarize key questions that need to be asked when writing a SEMP in order to maximize value delivery.
The SEMP is a plan for managing and conducting the engineering of the systems.
A well-developed SEMP includes the following information:
- It is a top-level plan for managing the SE effort.
- How the plan relates to other engineering activities.
- How the project will be organized, structured, and conducted.
- How the engineering process will be controlled to provide a product that satisfies stakeholder requirements.
- Provides guidance and direction to the project staff (the “Team”).
- Provides information that helps the members of the Project Team be informed (read: empowered) and to avoid unnecessary discussions concerning how to perform systems engineering.
The SEMP provides a framework for thinking about the engineering for the systems of interest including:
- Identification of issues and risks.
- Organizing and planning.
- Allocation of responsibilities and who is responsible for what (ownership).
- Sequencing of tasks.
- Estimation.
- Management and control.
The SEMP should include:
- Organization of the project, how SE interfaces with the other parts of the organization, and how communications at these interfaces are handled.
- Responsibilities and authority of the leadership roles on the project.
- System boundaries and the scope of the project.
- Project assumptions and constraints.
- Key technical objectives.
- Infrastructure support and resources.
- Approach and methods used for planning and executing the technical processes.
- Approach and methods used for planning and executing the technical management processes.
- Approach and methods used for planning and executing the applicable specialty engineering processes.
Editor’s note: PPI prefers the alternative name “Systems Engineering Plan” (SEP), since the scope of a SEMP is much more than a plan for managing the engineering, it is a plan for doing the engineering, where a systems engineering approach is to be used. PPI publishes and uses a Data Item Description (an elaborate template with guidance) for the SEP – the PPI SEP DID may be downloaded here.
View the Tutorial via the link below:
https://social.ppi-int.com/IncoseTutorial
About the Authors of the Tutorial
Ian Presland is Director of Charterhouse Systems Limited, an independent consultancy specializing in Systems Engineering competency development around the globe. After graduating from Bristol University in the UK with a BEng in Electronic and Electrical Engineering in 1980, Ian worked as an electronics engineer before moving into firmware, software and finally systems engineering where he has spent the last 25+ years. His experiences cover senior leadership roles in various sectors including aerospace, su, automotive, and transportation. In 2015, Ian left corporate life to establish his own independent consultancy and now supports a variety of clients in the UK and internationally. He lectures in Systems Engineering at Warwick University, UK and for the University of California (Irvine). Ian is a Chartered Engineer, Member of the British Computer Society, a Fellow of the IET, and an INCOSE ESEP. His INCOSE activities include eight years as Director of Professional Development for the UK Chapter and two terms on the INCOSE Certification Advisory Group. He is a co-author and editor of the new INCOSE Systems Engineering Competency Framework. In 2017, Ian was awarded an INCOSE Outstanding Achievement Award for his work in Certification and Professional Development.
Becky Reed is the President and CEO of Reed Integration, Inc., a WOSB/EDWOSB, SDB headquartered in Suffolk, VA, with an additional office in the Washington, DC area and employees in 4 other states. With more than 25 years of engineering and leadership experience in aerospace, nuclear, environmental, and information technology industries, Becky is an internationally recognized authority on life cycle systems engineering and risk management and their applications in government and commercial markets. Her small business is an industry leader in technical and management consulting and training services, and is a premiere provider of systems engineering training and CSEP exam preparation programs. A long-time, active member of INCOSE, Becky obtained her CSEP certification in 2004 and then became the 24th person in the world to achieve the credential of ESEP in 2010. She was awarded the INCOSE Outstanding Service Award in 2007 and is a member of the INCOSE Hall of Leaders.
3. Additional Article
3.1 Strengthening Technical Leadership for Systems Engineers
by
Nelson Ruiz
Escuela Tecnológica Instituto Técnico Central
Bogotá, Colombia
Email: n75ruiz@gmail.com
Abstract
Systems engineering has an increasingly important role in addressing societal needs. The development of complex systems is critical to address these needs. There are extensive demands for systems that provide a holistic view of the challenge at hand as well as solutions that address many disciplines. Systems engineers are integrators and architects who require leadership skills in order to lead teams of interdisciplinary professionals who can build divergent solutions that address increasingly complex problems and needs. This article recommends that additional emphasis be focused on strengthening leadership abilities and skills in the educational and training activities that are provided for systems engineers.
The Evolution of Systems Engineering
Figure 1 provides a brief overview of the evolution of the discipline of Systems Engineering. Note that SE is a young discipline; yet, it has already contributed immensely to solutions needed by society.
Figure 1: Evolution of the Discipline of Systems Engineering
Figure by Bernardo Delicado (Delicado, Pressing Need for Technical Leadership)
Technical Leadership is Critical to Effective Systems Engineering
The development of complex systems is critical to address societal needs (Figure 2). There are extensive demands for systems that provide a holistic view of the challenge at hand as well as solutions. Systems engineers are integrators and architects who require well developed leadership skills and abilities in order to lead teams of interdisciplinary professionals who can build divergent solutions to increasingly complex problems and needs.
Figure 2: Systems Must Respond to Societal Needs
The INCOSE Vision
The International Council on Systems Engineering (INCOSE) vision is available at https://www.incose.org/products-and-publications/se-vision-2025. INCOSE Vision 2025 is a publication produced by a team of leaders from industry, academia, and government with the intent that it will be used by people working in many domains – healthcare, utilities, transportation, defense, finance – who will add their unique perspectives to the role systems engineering plays in our serving our world’s many complicated demands.
Vision 2025 addresses:
- The Global Context for Systems Engineering
- The Current State of Systems Engineering
- The Future State of Systems Engineering
INCOSE’s Vision 2025 is summarized in Figure 3.
Figure 3: INCOSE’s Vision 2025
INCOSE’s Vision 2025 and the Systems Engineering Competency Framework (SECF) (available at https://www.incose.org/products-and-publications/competency-framework) identify the development of Systems Thinking and Technical Leadership as key systems engineering competencies.
The INCOSE Competency Framework provides a set of 36 competencies for Systems Engineering within a tailorable framework that provides guidance for practitioners and stakeholders to identify knowledge, skills, abilities, and behaviors crucial to Systems Engineering effectiveness.
Today, We Are Dealing with Complex Systems
INCOSE has provided A Complexity Primer for Systems Engineers, available at https://www.incose.org/docs/default-source/ProductsPublications/a-complexity-primer-for-systems-engineers.pdf.
Figure 4: INCOSE’s A Complexity Primer for Systems Engineers
Complexity is nothing new to systems engineers and managers. The discipline of systems engineering has evolved to improve our ability to deal with scale, interdependency, and complexity in systems development. Few systems engineers would doubt that complexity is increasing every year. The rate of change, the increasing interdependence and adaptability of systems, and the increasing ambitions of clients ensure that complexity keeps expanding to the limits of our capacity to cope with it.
Complex systems science provides a strong foundation for understanding, coping with, and even exploiting complexity. There is a large and rapidly expanding literature on networks, complexity, and complex adaptive systems that can guide systems engineering practice. But busy systems engineers rarely have the time to keep up with this literature, which is diffused across the many interdisciplinary applications of complex systems science. This paper is written for systems engineers and program/project managers who suspect they may encounter complexity-related challenges. This paper applies key concepts from complex systems science to systems engineering to suggest new methods that can handle complexity rather than assuming it away. It is not a complete or even extensive treatment, but is intended as an introduction to the subject for systems engineers as they encounter and work with complexity-related phenomena.
Systems Engineering Leadership
INCOSE has published the Systems Engineering Handbook (SEH). Many of the processes in this handbook rightly discuss technical management functions (e.g., decision management, risk management, portfolio management, and knowledge management), and these are all important aspects of the Systems Engineering (SE) process. However, leadership is a critical ability for systems engineers. In a paper entitled “What Leaders Really Do,” J. P. Kotter (2001) states that “leadership is different from management, but not for the reason most people think.” Kotter defines the key differences between leaders and managers as:
- Coping with change versus coping with complexity;
- Setting a direction versus planning and budgeting;
- Aligning people versus organizing and staffing; and
- Motivating people versus controlling and problem solving.
A quote often attributed to Peter Drucker is: “Managers do things right. Leaders do the right things” (Drucker, 1955). Compare this to the informal definitions of the SE verification and validation processes: “Verification ensures you built the system right. Validation ensures you built the right system.” Both verification and validation are important for the development of systems. Likewise, both management and leadership are important for systems engineers and their teams. Different phases of a project demand emphasis on different aspects of leadership.
Being a Systems Leader Requires Several Aspects of Leadership:
Figure 5: INCOSE’s View of the Aspects of Technical Leadership
Technical Processes
Technical processes enable systems engineers to coordinate the interactions between engineering specialists, other engineering disciplines, system stakeholders and operators, and manufacturing. They also address conformance with the expectations and legislated requirements of society. These processes lead to the creation of a sufficient set of requirements and resulting system solutions that address the desired capabilities within the bounds of performance, environment, external interfaces, and design constraints. Without the technical processes, the risk of project failure would be unacceptably high.
Skills of a Technical Systems Leader
Consider some skills of a technical systems leader:
- Holds the Vision
To be able to visualize and create an environment that enables development of a system that meets the vision and needs of the stakeholders.
- Thinks Strategically
Have a high-level understanding of the system and its role in meeting strategic needs, based on the system life cycle (SLC) and a balanced understanding of the different views of the system. A technical systems leader must be oriented to the delivery and evaluation of results.
- Fosters Collaboration
Fostering discussion and constructive criticism, unifying and integrating the different points of view of those interested in the systems of interest.
- Communicates Effectively
A technical systems leader must be an effective communicator. In their book The Leadership Challenge, Kouzes and Posner address many of these aspects. For example, they emphasize that it is the technical leader’s responsibility to communicate the long-term significance of the organization’s or project’s work and to foster frequent opportunities for team members to associate and intermingle among disciplines, among departments, and across continents.[9]
- Enables Others to Be Successful
Motivating people to achieve their goals, creating personal and professional satisfaction and having an active and important part of the system that is being built.
- Demonstrates Emotional Intelligence
But on the ground, it is sufficient to be an excellent engineer of systems, and it is necessary to understand that the systems that are built directly or indirectly affect the smallest of their lives.
4.1 Business or Mission Analysis Process
The purpose of the Business or Mission Analysis process is to define the business or mission problem or opportunity, characterize the solution space, and determine potential solution class(es) that could address a problem or take advantage of an opportunity.
Holds the Vision. It makes it easier to analyze the business by defining the problem or the opportunities. Planting different solution alternatives as well as assessing which alternatives are the best suited for the business.
Thinks Strategically. It makes it easier to understand the business of a holistic way, and to have a 360-degree view of the same.
Figure 6: Conceptual Model of Systems Engineering Leadership with OPM
4.2 Stakeholder Needs and Requirements Definition Process
The purpose of the Stakeholder Needs and Requirements Definition process is to define the stakeholder requirements for a system that can provide the capabilities needed by users and other stakeholders in a defined environment.
Communicates Effectively. It facilitates the communication between those interested in the business, allowing to define the different needs of those interested. Transformed the needs of the interested ones in requirements for its analysis and later definition.
4.3 System Requirements Definition Process
The purpose of the System Requirements Definition process is to transform the stakeholder, user-oriented view of desired capabilities into a technical view of a solution that meets the operational needs of the user.
Communicates Effectively. Facilitates definition, analysis and management of system requirements.
4.4 Architecture Definition Process
The purpose of the Architecture Definition process is to generate system architecture alternatives, to select one or more alternative(s) that frame stakeholder concerns and meet system requirements, and to express this in a set of consistent views.
Fosters Collaboration. It facilitates the collaboration of the different specialists in the architectural definitions of the system.
Enable Others to Be Successful. It motivates the different specialists to define the most suitable architecture for the system in consideration.
4.5 Design Definition Process
The purpose of the Design Definition process is to provide sufficient detailed data and information about the system and its elements to enable the implementation to be consistent with architectural entities as defined in models and views of the system architecture.
Fosters Collaboration. Facilitates collaboration of different specialists in design definitions for system elements.
Enables Others to Be Successful. It motivates the different specialists to define the detailed design appropriate for the elements of the system under consideration.
4.6 System Analysis Process
The purpose of the System Analysis process is to provide a rigorous basis of data and information for technical understanding to aid decision‐making across the life cycle.
Fosters Collaboration. Facilitates the analysis of the system by promoting the work shared among the different specialists.
Communicates Effectively. Through effective communication of the results obtained from the analysis process will enable better decision making.
4.7 Implementation Process
The purpose of the Implementation process is to realize a specified system element.
Thinks Strategically. It allows the development of a strategic way for the implementation of the product and / or service, having in mind the requirements of the system and the needs of the interested ones.
Fosters Collaboration. Facilitates the collaborative use of procedures, tools and other defined elements for product and service implementation.
Communicates Effectively. By means of an effective communication that facilitates the understanding by parts of the personas of the different procedures, tools and other elements to be used in the implementation of the product and / or the service.
4.8 Integration Process
The purpose of the Integration process is to synthesize a set of system elements into a realized system (product or service) that satisfies system requirements, architecture, and design.
Thinks Strategically. It allows the development of a strategic way of integrating the different interfaces of the product and / or service, while meeting the requirements of the system.
Fosters Collaboration. It facilitates that the realization of the different interfaces of the system is carried out by a team that shares the understanding and understanding of the elements involved in each of the interfaces of the system.
Communicates Effectively. Effective communication between each of the envelopes in the effective realization of the interfaces helps to reduce the errors in the implementation of the two interfaces, making the system more robust.
4.9 Verification Process
The purpose of the Verification process is to provide objective evidence that a system or system element fulfils its specified requirements and characteristics.
Fosters Collaboration. It makes it easier for different participants to understand how collaborative work allows them to build the system correctly.
Communicates Effectively. To build the system correctly, effective communication between different team members is an important feature.
Enables Others to Be Successful. Building the system correctly motivates the team members to reconcile the importance of each of the tasks performed during the process of building the product and / or service.
4.10 Transition Process
The purpose of the Transition process is to establish a capability for a system to provide services specified by stakeholder requirements in the operational environment.
Communicates Effectively. To be able to timely communicate to those interested in the services that the system provides.
4.11 Validation Process
The purpose of the Validation process is to provide objective evidence that the system, when in use, fulfills its business or mission objectives and stakeholder requirements, achieving its intended use in its intended operational environment.
Thinks Strategically. Having a holistic view of the system allows you to help understand that the correct system is being built.
4.12 Operation Process
The purpose of the Operation process is to use the system to deliver its services.
Communicates Effectively. During the operation of the system, tell a communication about how to use the system and how it behaves in the face of different situations.
4.13 Maintenance Process
The purpose of the Maintenance process is to sustain the capability of the system to provide a service.
Communicates Effectively. Communicate to people in charge of maintaining the system the different situations and how to solve them to ensure a stable operation.
4.14 Disposal Process
[6.4.14.1] The purpose of the Disposal process is to end the existence of a system element or system for a specified intended use, appropriately handle replaced or retired elements, and to properly attend to identified critical disposal needs.
Communicates Effectively. Informing those concerned, the impact of withdrawing a system service and the possible situations that may arise from the process of withdrawing the system of interest from one of its parts.
Communication
This paper has shown that a critical aspect of a systems engineer’s work is communication. Therefore, it makes good sense to further strengthen and improve communication skills and abilities in systems engineering education and training. In his book, Project Requirements: A Guide to Best Practices, Young provides many suggestions for how this can be done. In Chapter 7, Clear Communication: The Key to Project Success, for example, Young provides an extensive list of communications aids on a project, identifying the Suggested Aid, What is it, and How Does it Help. “Of all the areas of project management and systems engineering, communication is perhaps the one area that most establishes the ability of the people supporting a project to work productively and effectively.”
Conclusion
If you consider skills related to leadership that are present in the technical aspects of systems engineering, it is clear that effective communication can make the difference between success and failure in the different activities that make up each of the technical processes.
List of Acronyms
Acronym Explanation
ETITC Escuela Tecnológica Instituto Técnico Central
INCOSE International Council on Systems Engineering
OPM Object-Process Methodology
OPL Object-Process Language
OPD Object-Process Diagram
References
Delicado Bernardo, A pressing need for a True Systemic Technical Leadership in High-Tech Companies in a Fast-Changing World, October 2019. Available at
Dori, Dov. Object Process Methodology: a Holistic Systems Paradigm. Springer 2002.
Drucker, Peter F. The Practice of Management. Oxford: Elsevier Ltd., 1955.
International Council on Systems Engineering (INCOSE). Systems Engineering Handbook (SEH): A Guide for System Life Cycle Processes and Activities, Version 4e, 2015.
INCOSE, 2014, ‘A World in Motion – Systems Engineering Vision 2015’. Available at https://www.incose.org/products-and-publications/se-vision-2025
ISO/IEC/IEEE 15288, 2015, ‘Systems and software engineering – System life cycle processes’. Available at https://connect.incose.org/pages/store.aspx
Kouzes, James M. and Barry Z. Posner. The Leadership Challenge (6th Ed.). Hoboken, New Jersey USA: John Wiley & Sons, 2017.
Knotter, J.R. What Leaders Really Do. Harvard Business Review Book. Harvard Business Review Press, 1999.
Young, Ralph R. Project Requirements: A Guide to Best Practices. Vienna, Virginia USA: Management Concepts, 2006.
About the Author
Nelson Javier Ruiz Aponte is a Systems Engineer at the “Francisco José de Caldas” Distrital University and a Software Enterprise Architecture Specialist at the Pontificia Universidad Javeriana. He is the first Colombian engineer certified as a Certified Systems Engineering Professional (CSEP) by the International Council on Systems Engineering (INCOSE). Among his research interests are: model-based systems engineering, conceptual modeling of complex systems, systems architecture and design, systems and software engineering and knowledge management. His professional experience has been developed as a Systems Analyst and Technical Leader in public and private sector companies. He has been a professor in the Systems Engineering Program at the Escuela Tecnológica Instituto Técnico Central “La Salle”. He is a member of the IEEE SMC Technical Committee on Model Based Systems Engineering (TC-MBSE) and the Research Group in Virtual Learning Environments: “Virtus”.
4. SYstems Engineering News
4.1 Model-Based Systems Engineering Maturity Benchmark Survey
Your participation is invited
Stueti Gupta, Systems and Architecture Lead at John Deere and India Chapter President (Pune, Maharashtra, India) requests your participation in the INCOSE/NDIA/SERC Maturity Benchmarking Survey Model-Based Systems Engineering Maturity Benchmark Survey. This survey is intended to assess the value and effectiveness of MBSE adoption for improving business outcomes. It is also intended to develop a profile of current MBSE use and expectations across the systems engineering life cycle.
This broad survey is intended to assess the value and effectiveness of MBSE adoption for improving business outcomes. It is also intended to develop a profile of current MBSE use and expectations across the systems engineering life cycle. It is based on the upcoming INCOSE Model-Based Capabilities Matrix, which you can download with the survey. The survey will take about 30 minutes.
The survey is a joint effort of the International Council on Systems Engineering (INCOSE) and the National Defense Industrial Association (NDIA) Systems Engineering Division. The survey is supported by researchers at the Systems Engineering Research Center (SERC).
Editor’s Note: The deadline for receipt of all surveys is February 1, 2020
Please access the survey here:
4.2 Trinity Hall Lauded for STEM Achievements
Figure 1: Trinity Hall board chairperson Victoria Gmelich, left, joined Head of School Mary Sciarrillo Nov. 18 in announcing special recognition for the school’s STEM program from the Middle States Association.
Photo by Laura D.C. Kolnoski
The student body of Trinity Hall High School (New Jersey USA) joined with teachers, parents, local officials, and business leaders November 18, 2019 to accept recognition as a “Program of Distinction” from the Middle States Association Commissions on Elementary and Secondary Schools (MSA-CESS) for its curriculum in science, technology, engineering and mathematics (STEM). According to Middle States, Trinity Hall is the first high school in New Jersey USA – and the only all-girls school in the nation – to receive this recognition.
Mary Sciarrillo, Trinity Hall’s head of school, advised that the school’s four-year STEM courses are aligned with college level courses and that the school’s infrastructure has been redesigned to enhance STEM programs. Students and faculty work and establish partnerships with area educational institutions, businesses, and industries to pursue grants, create internships, and more, she said.
4.3 Systems Engineering Publishes Special Issue Concerning System of Systems Engineering
In November 2019, INCOSE published a special issue of the Journal of Systems Engineering concerning System of Systems Engineering. The titles of papers included in this edition are as follows:
- Systems of systems: From mission definition to architecture description
- Architecting systems-of-systems and their constituents: A case study applying Industry 4.0 in the construction domain
- Interface modeling for product-service system integration
- A network perspective on assessing system architectures: Foundations and challenges
- Architecting exogenous software-intensive systems-of-systems on the internet-of-vehicles with SosADL
- A method of identifying and analyzing irrational system behavior in a system of system
- Decision learning framework for architecture design decisions of complex systems and system-of-systems
- Designing development processes related to system of systems using a modeling framework
Read the Journal here.
4.4 Project Management Institute Issues New Standard for
Earned Value Management
The Project Management Institute (PMI) has published The Standard for Earned Value Management (PMI EVM Standard). It is a Voluntary Consensus Standard (VCS) and should be used in concert with A Guide to the Project Management Body of Knowledge, (PMBOK® Guide).
From the PMI Website:
The Standard for Earned Value Management is an update and expansion upon PMI’s reference, The Practice Standard for Earned Value Management—Second Edition.
EVM is a management methodology used in project management for integrating scope, schedule, & resources; for objectively measuring project performance and progress; and for forecasting project outcome. EVM provides practices, methods and tools for project and program performance monitoring and has demonstrated itself to be of great value.
This standard will assist practitioners & organizations to:
- Mature their practices
- Drive continuous improvement
- Integrate these practices with existing project management practices
For project professionals, it is important to know that project work is being accomplished as planned, that costs are at the level expected, and what the remaining work is likely to cost. It is even more important to be able to identify where any problems are occurring, how serious the problems are, and what it will take to get the project back on track.
Earned Value Management (EVM), known as “management with the lights on”, is based on the principle that past patterns and trends can indicate future conditions. EVM helps you clearly and objectively see where your project is headed compared to where it is supposed to be.
The Standard for Earned Value Management is intended for any practitioner or organization who wants to expand their toolset and use EVM to improve project performance.
Editor’s Note: See a description of the book in the SE Publications Section, below. See also the description of a related book, Performance Based Earned Value, which advocates incorporating product requirements and planned quality into the Performance Management Baseline (PMB).
4.5 Systems Thinking Daily (STDaily) Group on Facebook
There is a Systems Thinking Daily group on Facebook. Here is a description from the page:
“Systems Thinking Daily (STDaily) is a Facebook group for folks to deepen their knowledge of scientifically-sound and ultimately-useable systems thinking (ST). The group is for both aspiring and expert systems thinkers. Research shows that underlying all ST are four universal cognitive skills called DSRP. Learn more about DSRP in this video: https://vimeo.com/124858581. We promote more refined discussion of specific ST/DSRP skills that can be learned, developed, and used. DSRP is therefore synonymous with ST, but far more specific.
We encourage your posts to this channel. However, STDaily is a bit different from other systems thinking lists. We want to make ST TANGIBLE for folks. Posts tend to be based in real world examples (both every day and wicked problems) that provide a basis for learning to DO ST/DSRP better. There is much confusion in the ST world as to what systems thinking is and STDaily hopes to decrease this confusion by making the underlying patterns of thinking explicit to users so that they are empowered to do systems thinking on their own and apply it to their daily lives. In this spirit we ask that all posts include an editorial statement that explicates one or more of the four scientifically valid patterns of thinking (DSRP): distinctions (identity-other), systems (part-whole), relationships (action-reaction), and perspectives (point-view). This need not require much from you. For example, an article, blog, or image posted might just include an editorial introduction such as: “note the distinctions being made in this article.” Or, just pose a question to the group…
Alternatively, there are other great lists that accept any systems thinking content, explicit or not, such as those on LinkedIn and Facebook.
We run this list as a complex adaptive system (CAS) because all human social groups are complex adaptive systems. The way CASs work is that their collective behavior is an emergent property of underlying simple rules followed by the autonomous agents (you and other list members). In other words, all the little interactions that we have each day and in each: post, like, comment, re-comment, share, etc. will lead to the collective behavior or emergent property that we call “the list.” Learn about CAS in this video: https://youtu.be/GjwvsK-6640
Be sure to check out our 10 Simple Rules. The culture of the list is based on the basic spirit and rules of scholarship and science (transparency, attribution, validity, openness to new ideas, critical review of proposed ideas, avoidance of strawmen and ad hominem arguments, topical focus, materialism, etc.). If that sounds interesting, this is the place.”
Join the group through the following link:
https://www.facebook.com/groups/stdaily/
4.6 2020 INCOSE Officers and Directors
On Saturday 25th of January at the INCOSE International Workshop in Torrance, California, the following new INCOSE directors will be installed by INCOSE nominations and elections (NOMELEC) committee chair, Alan Harding.
INCOSE members also approved a change to our bylaws enabling a new appointed board position of Services Director, a role that will direct and oversee the development and delivery of key services to our members such as events, training, and certification.
Alan Harding wrote in an INCOSE emailer sent out in early January 2020, ‘Of course the process of finding and developing future INCOSE leaders at all levels continues throughout the year, And so I would encourage anybody interested in both contributing to both our society and systems engineering, and the personal development opportunity that comes from volunteer leadership roles, to approach either myself, Bob Kenley (my successor as NOMELEC chair) or any member of the INCOSE board of directors.’
Join the official INCOSE LinkedIn Group
http://www.linkedin.com/groups?gid=7499834
or
INCOSE FACEBOOK
https://www.facebook.com/groups/INCOSE/
and Twitter at
https://twitter.com/incose_org
4.7 Call for Papers Special Issue of Mind & Society Advanced Modeling of Organizational Behavior
Submission Deadline: April 1st, 2020
Over the last decades, psychological research has often highlighted that the theory of “rational” decision-making eventually prescribes choices from which humans systematically deviate. Remarkably, several Nobel laureates including Herbert Simon (1978), Daniel Kahneman (2002) and Richard Thaler (2017) have been prized for developing more realistic theories of human behavior and interaction.
In line with these theoretical developments, novel modeling methods have been proposed that allow more realistic descriptions of actual organizational behavior. In particular, computational methods and statistical techniques nowadays allow for capturing dynamics of latent psychological constructs and reproducing the emergence of novel organizational features. Ideally, these methods strive for recreating the complexity of macroscopic organizational structures without losing sight of individual human behavior.
The present call for special issue aims to collect a series of contributions (including original research articles, reports, or reviews) where such methods are employed in order to capture organizational dynamics. Potential methods to be applied to organizational studies include, but are not limited, to the following list:
- Agent-based modeling
- Pattern analysis
- Nonlinear regressionn
- Latent Class Growth Analysis
- Nonlinear dynamical processes
- Growth curve modeling
- Hidden Markov chains
- Network analysis
- Recurrence quantification analysis
4.8 Systems Engineering Tools Database Prototype Demonstration at the INCOSE IW 2020
The Systems Engineering Tools Database (SETDB) is an online library of systems engineering software tools that support engineering business and processes. During the upcoming INCOSE International Workshop in Torrance, California (USA) taking place from 25 to 28 January 2020, the SETDB prototype will be demonstrated for all workshop attendees. The SETDB project team welcome all workshop attendees to provide feedback on the functional prototype during this time. This feedback will be considered in further development of the SETDB that is due for operational release at the INCOSE International Symposium taking place from 18 – 23 July 2020 in Cape Town, South Africa. Details about the prototype booth location will be available at the registration table during the IW.
INCOSE and PPI’s partnership also includes the sharing of PPI’s Systems Engineering Goldmine, a resource of over 4GB of systems engineering documents and a searchable database of definitions of more than 7,800 terms used in systems engineering. INCOSE and PPI have a mutual commitment to improving the state of systems engineering practice. These projects help us to achieve our shared goal and to bring the systems engineering community closer together as we continue to innovate,” said Garry Roedler, president of INCOSE.
Read more about the collaboration here.
5. featured organizations
5.1 Systems Engineering Advancement Research Initiative (SEAri)
SEAri investigates novel approaches to accelerate transformation of engineering to a model-centric discipline.
The Systems Engineering Advancement Research Initiative (SEAri) partners with government, industry and academia across multiple sectors to accelerate the transformation of engineering practices and enterprises under the digital paradigm. Current research projects include:
- Model Curation Innovation and Implementation
- Principles and Enablers for Human-Model Interaction
- Leading Indicators for Engineering Effectiveness in Model-Centric Programs
- Architecting Innovative Enterprise Strategies for Digital Transformation
- System of Systems Architecting with Ilities (SAI)
About SEAri (from the SEAri webpage)
SEAri’s Vision
Be a recognized world leader in systems engineering research and advanced methods for systems engineering, as seen by academia, industry, and government, across many technical domains.
SEAri’s Mission
Advance the theories, methods, and effective practice of systems engineering applied to complex socio-technical systems through collaborative research.
SEAri’s Objectives
- Foster dialog among senior system leaders across multiple domains and application sectors
- Conduct both theoretical and empirical field research to ensure rigorous and relevant contributions
- Leverage resources of MIT and strategic partners
- Define and research fundamental concepts for advanced systems engineering
- Contribute to the academic body of knowledge through journal and conference publications
- Develop curricula, education materials, and handbooks to inspire, inform, and guide students and practitioners
5.2 Fraunhofer Institute for Experimental Software Engineering (Fraunhofer IESE)
Kaiserslautern, Germany
Fraunhofer IESE is one of the world’s leading research institutes for applied research in the area of software and systems engineering. The Institute researches trendsetting key technologies for smart ecosystems and assists its customers and partners on the path to digital transformation. The focus of the research is on scalable systems engineering with guaranteed qualities in the areas of Safety and Security as well as software-driven innovation.
The institute deals with innovative topics such as Industry 4.0, big data and cyber security. The institute is a technology and innovation partner for digital transformation in the areas of autonomous & cyber-physical systems and digital services and researches the interplay of embedded systems and information systems in digital ecosystems. The institute is a member of the Fraunhofer Society, the largest organization for applied research in Europe.
Fraunhofer IESE is developing an innovative digital neighborhood platform on which various digital services in the areas of energy, mobility and smart home are made available. This creates added value for the companies, users and residents of the district. For example, through more energy-efficient lighting and heating concepts or improved mobility options. This initiative supports the goal of a CO2-neutral district. Fraunhofer IESE is building on the results of the “Smart Rural Areas” research program and the “Digital Villages” project. Among other things, value is placed on new data protection concepts, through which the users retain complete sovereignty over the data used at all times.
6. News on Software ToolS Supporting Systems Engineering
6.1 Jama Software On-demand Webinar: Tips and Tricks for Better Reviews
Reviews play a critical role in successful product and systems development. Unfortunately, too many organizations are weighed down by outdated processes, such as emailing versioned Word and Excel documents and enduring lengthy review meetings.
The consequences of outdated review processes include added rework, missed deadlines, product design failures, and expensive recalls. Luckily, reviews don’t have to be so tedious.
The experts from Jama Software recently held a webinar on this topic, “Ask Jama: Tips and Tricks for More Effective Reviews,” that is now available for you to watch on-demand.
Watch this webinar to learn how to define, manage, and improve your requirements and test case review process and provide best practices for reviews based on learnings from our industry-leading customers.
6.2 UAF Special Event: Actionable Architecture in the 21st Century Special Event
Industry, government, and DoD are driving towards implementing architecture enabled digital engineering transformation. This transformation provides the means to connect information across and within enterprises. The intent of this public information day is to present the latest thinking around enterprise and system of systems architecture with examples of how UAF (www.omg.org/uaf) can be developed and used to provide timely and accurate information to decision makers. Free registration here: https://lnkd.in/eQiCyCq.
The Unified Architecture Framework® (UAF®) is based on the Unified Profile for DoDAF and MODAF™ (UPDM™). UAF defines ways of representing an enterprise architecture that enables stakeholders to focus on specific areas of interest in the enterprise while retaining sight of the big picture. UAF meets the specific business, operational and systems-of-systems integration needs of commercial and industrial enterprises as well as the U.S. Department of Defense (DoD), the UK Ministry of Defense (MOD), the North Atlantic Treaty Organization (NATO) and other defense organizations.
6.3 The REUSE Company Develops Capella Integration Tool
The REUSE Company has developed a RAT (Requirements Authoring Tool) that makes use of Artificial Intelligence and Natural Language Processing and help you to write the perfect requirement. This addition offers traceability and integration meaning the requirements and the models will always be integrated. When the elements are edited or renamed, there is a link to automatically update your requirements. RAT aggregates the requirements in a SMART Grid in Capella. This way you can sort, filter, do an advanced search or check the quality rate for each element.
Watch this video to learn more about RAT for Capella.
7. Systems Engineering Publications
7.1 Model-based Systems Engineering: An Introduction to the Mathematical Theory of Discrete Systems and to the Tricotyledon Theory of System Design
by
A. Wayne Wymore
From the Search Works Catalog of Stanford Libraries:
‘Model-Based Systems Engineering’ explains the fundamental theories behind model-based systems and the considerations involved in applying theory to the design of real systems. The book begins by presenting terms used in systems engineering and introducing the discrete system and its components. The remainder of the text explains topics such as the mathematical theory of system coupling, the homomorphic relationship between systems, the concept of system mode, the mathematical structure of T3SD system requirements, and the implications of that structure for T3SD system design. Appendices include a short bibliography, detailed definitions of all examples discussed in the text, a list of all notations used, and an index. “Model-Based Systems Engineering” is an excellent text for engineering students, and an invaluable reference for engineers and scientists.
Publisher: Boca Raton: CRC Press, c1993.
ISBN:
IBSN 11: 084938012X
IBSN 13: 9780849380129
7.2 International Journal on Software and Systems Modeling
(SoSyM)
published by
Springer
Software and Systems Modeling (SoSyM) is a quarterly international journal (published in English) that focuses on theoretical and practical issues pertaining to the development and application of software and system modeling languages and techniques. The aim of the journal is to publish high-quality works that further understanding of the theoretical underpinnings of modeling languages and techniques, present rigorous analyses of modeling experiences, and introduce scalable modeling techniques and processes that facilitate rigorous, efficient, or economical development of software.
The journal is unique in its emphasis on theoretical foundations of modeling languages and techniques, and on rigorous analyses of “real-world” modeling experiences. The balance of theoretical works and works based on in-depth analyses of experiences offers insights to researchers that can inform future investigations into better modeling languages and techniques, and provides modeling practitioners with a deeper understanding of modeling languages and techniques that can lead to more effective application.
The journal targets researchers, practitioners and students who have a vested interest in results generated by high-quality modeling research and by rigorously analyzed modeling experiences. We invite authors to submit papers that discuss and analyze research challenges and experiences pertaining to software and system modeling languages, techniques, tools, practices and other facets. The following are some of the topic areas that are of special interest, but the journal publishes on a wide range of software and systems modeling concerns:
- Domain-specific models and modeling standards
- Model-based testing techniques
- Model-based simulation techniques
- Formal syntax and semantics of modeling languages such as the UML
- Rigorous model-based analysis
- Model composition, refinement and transformation
- Software Language Engineering
- Modeling Languages in Science and Engineering
- Language Adaptation and Composition
- Metamodeling techniques
- Measuring quality of models and languages
- Ontological approaches to model engineering
- Generating test and code artifacts from models
- Model synthesis
- Methodology
- Model development tool environments
- Modeling Cyberphysical Systems
- Data intensive modeling
- Derivation of explicit models from data
- Case studies and experience reports with significant modeling lessons learned
- Comparative analyses of modeling languages and techniques
- Scientific assessment of modeling practices
Publisher: Springer Berlin Heidelberg
ISSN: 1619-1366 (Print) 1619-1374 (Online)
Coverage: Volume 1 / 2002 – Volume 18 / 2019
7.3 Think Engineer
by
Professor Jon Holt
A Book for All Ages
From the INCOSE Online UK Bookstore:
Think Engineer is a book that is designed to promote STEM (Science, Technology, Engineering, and Mathematics) and specifically, to promote engineering to school children. The book was launched in November 2015 and is published by INCOSE UK.
The book is aimed at Key Stage 2 pupils (ages 7-11), and their parents and teachers to raise the awareness of engineering.
The book is written by Professor Jon Holt (author of ten books on Model-Based Systems Engineering and Technical Director of INCOSE UK) and is beautifully illustrated by the renowned artist Ian Simmons.
The book is written in simple rhymes and tells the story of two children, one of whom is considering her options at school. She is frustrated by the options that she faces but, never fear, the Engineer in the Hat is here! Join the Engineer in the Hat for a roller-coaster journey through engineering – “Engineering, we know, will not leave you snoring!”
Watch the Five-minute Video on YouTube
Information about the Book (requires INCOSE UK membership login)
Order the book – scroll down the following Webpage (requires INCOSE UK membership login)
7.4 Systemic Change Management
by
George L. Roth and Anthony J. DiBella
Editor’s note: This well-researched and insightful book includes a chapter titled “Distributing Leadership” that details the critical role of leadership – people working on and in the system to create a strong and resilient enterprise that does not depend on any one individual and has the capacity to build and sustain excellence. The book explains what is required to promote systemic change. Five enterprise capabilities are described showing how individual, group, and cultural attitudes and skills provide the basis for successful growth and change.
A Review on the Amazon.com Webpage:
As a former practitioner in Organizational Development and alliance relationships, I was curious what this book might offer that is new in systems change management. From the stories of NUMMI executives ‘closed eyes’ to the discussion of high-performance relationships impact on the success of huge corporate networks, I was fascinated and captivated by this book. It is one of the best summarizations of systems thinking I have ever read, but goes well beyond theory. The hundreds of examples of successful organizational change offered in the book become a blueprint to inspire and rethink how to effectively create change within multiple environments, whether it be work, governing, social organizations, families and more. Unlike many academic approaches to systems thinking and theory, this book creates infinite possibilities for emerging leaders to learn and apply invaluable real-life lessons.
Format: Kindle, Hardcover, Paperback
Publisher: Palgrave Macmillan; 2015 edition (January 12, 2016)
ASIN: B00YN31EJG
7.5 Accelerating the Development of Senior Systems Engineers
by
Heidi L. Davidz, Deborah J. Nightingale, Donna H. Rhodes
Abstract
Since more senior systems engineers are needed to handle the increasing complexity of contemporary systems, there is an increasing need to accelerate the development of these senior professionals. However, the process of efficiently developing a senior systems engineer is not well-understood. Compounding this problem, the skill set needed by senior systems engineers continues to broaden while system complexity increases and system boundaries expand. In order to better understand the mechanisms that most effectively and efficiently develop these individuals, this article discusses enablers, barriers, and precursors to this development process. In addition to reviewing related literature, specific interventions currently used to accelerate systems thinking development are discussed. Findings from ongoing research related to this topic provide preliminary information about current understanding and practice. Better understanding of systems thinking development provides a foundation for educational interventions and employee development in systems thinking for engineering professionals across industry, government, and academia.
PDF File available at
https://core.ac.uk/download/pdf/19879175.pdf
7.6 Emergent Behavior in Complex Systems Engineering:
A Modeling and Simulation Approach
(Stevens Institute Series on Complex Systems and Enterprises)
by
Saurabh Mittal, Saikou Diallo, and Andreas Tolk
From the Amazon.com Website:
A comprehensive text that reviews the methods and technologies that explore emergent behavior in complex systems engineering in multidisciplinary fields.
In Emergent Behavior in Complex Systems Engineering, the authors present the theoretical considerations and the tools required to enable the study of emergent behaviors in manmade systems. Information Technology is key to today’s modern world. Scientific theories introduced in the last five decades can now be realized with the latest computational infrastructure. Modeling and simulation, along with Big Data technologies are at the forefront of such exploration and investigation.
The text offers a number of simulation-based methods, technologies, and approaches that are designed to encourage the reader to incorporate simulation technologies to further their understanding of emergent behavior in complex systems. The authors present a resource for those designing, developing, managing, operating, and maintaining systems, including system of systems. The guide is designed to help better detect, analyze, understand, and manage the emergent behavior inherent in complex systems engineering in order to reap the benefits of innovations and avoid the dangers of unforeseen consequences. This vital resource:
- Presents coverage of a wide range of simulation technologies.
- Explores the subject of emergence through the lens of Modeling and Simulation (M&S).
- Offers contributions from authors at the forefront of various related disciplines such as philosophy, science, engineering, sociology, and economics.
- Contains information on the next generation of complex systems engineering.
Written for researchers, lecturers, and students, Emergent Behavior in Complex Systems Engineering provides an overview of the current discussions on complexity and emergence, and shows how systems engineering methods in general and simulation methods in particular can help in gaining new insights in complex systems engineering.
Formats: Kindle, Hardcover
Publisher: Wiley; 1 edition (April 3, 2018)
ISBN-13: 978-1119378860
ISBN-10: 1119378869
ASIN: B07BYD4HYF
7.7 The Standard for Earned Value Management
by
The Project Management Institute
From the Project Management Institute Webpage:
Earned value management (EVM) is a management methodology for integrating scope, schedule, and resources; objectively measuring project performance and progress; and forecasting project outcomes. It is considered by many to be one of the most effective performance measurement and feedback tools for managing projects.
The Standard for Earned Value Management builds on the concepts for EVM described in the Practice Standard for Earned Value Management and includes enhanced project delivery information, by integrating concepts and practices from the PMBOK® Guide – Sixth Edition and the Agile Practice Guide.
A central theme in this standard is the recognition that the definition for value in EVM has expanded. While the term retains its traditional definition in terms of project cost, it embraces current practice by including the concept of earned schedule. This standard also integrates hybrid methodologies that blend together historical EVM concepts with the needs of the agile practitioner, all with an eye towards aiding the project team in enhancing overall project delivery.
This standard is a useful tool for experienced project management practitioners who are seeking to expand and update their knowledge of the field as well as less experienced practitioners who want to learn other approaches for managing project performance. It provides insight and detailed explanations of the basic elements and processes of EVM, and demonstrates how to scale EVM to fit varying project sizes and situations. This standard includes graphical examples and detailed explanations that will enable the reader to establish and implement EVM on projects in almost any environment and of almost every size. When used together with good project management principles, EVM methodology will provide a greater return on any project and results that will directly benefit your organization.
Format: Paperback
Publisher: Project Management Institute (December 2019)
ISBN-13: 978162825638
7.8 Performance-Based Earned Value
by
Paul J. Solomon and Ralph R. Young
From the Amazon.com Website:
Performance-Based Earned Value uniquely shows project managers how to effectively integrate technical, schedule, and cost objectives by improving earned value management (EVM) practices. Providing innovative guidelines, methods, examples, and templates consistent with capability models and standards, this book approaches EVM from a practical level with understandable techniques that are applicable to the management of any project. Its uniqueness is that the book integrates Project Quality, Cost, and Schedule control all in one method. Also, it is the only book that includes excerpts from the PMI®’s Project Management Body of Knowledge (PMBOK®), CMMI, the EVM System standard, systems engineering standards, federal acquisition regulations, and Department of Defense guides.
Clear and unambiguous instructions explain how to incorporate EVM with key systems engineering, software engineering, and project management processes such as establishing the technical or quality baseline, requirements management, using product metrics, and meeting success criteria for technical reviews. Detailed information is included on linking product requirements, project work products, the project plan, and the Performance Measurement Baseline (PMB), as well as correlating technical performance measures (TPM) with EVM. The book provides straightforward instructions concerning how to use EVM on a simple project, such as building a house, and on complex projects, such as high-risk IT and engineering development projects.
Performance-Based Earned Value allows both novices and experienced project managers, including project managers of suppliers and customers in the commercial and government sectors; software and systems engineering process improvement leaders; CMMI appraisers; PMI members; and IEEE Computer Society members to:
- Incorporate product requirements and planned quality into the PMB
- Conduct an Integrated Baseline Review
- Analyze performance reports
- Perform independent assessments and predictive analysis
- Ensure that key TPMs are selected, monitored, and reported
- Identify the right success criteria for technical reviews
- Develop techniques for monitoring and controlling supplier performance
- Integrate risk management with EVM
- Comply with government acquisition policies and regulations
Written by Paul Solomon and Ralph Young, internationally recognized industry experts, Performance-Based Earned Value is constructed from guidance in standards and capability models for EVM, systems engineering, software engineering, and project management. It is the complete guide to EVM, invaluable in helping students prepare for the PMI®-PMP® exam with practical examples and templates to facilitate understanding, and in guiding project professionals in the private and public sectors to use EVM on complex projects.
(PMI, PMBOK, PMP, and Project Management Professional are registered marks of the Project Management Institute, Inc.)
From the Foreword to the book, by Eleanor Haupt, Past President, Project Management Institute, College of Performance Management: “Solomon and Young make the strong case that EVM has not kept pace with the increasing emphasis on systems engineering, product quality, risk management, and cycle time reduction that all project managers now face. Indeed, while EVM has always claimed that it integrates work scope, schedule, and budget into the so-called “Iron Triangle”, experience shows us that true integration of product scope and achieving the desired product quality have not been fully integrated with EVM. Solomon and Young have not only advanced the practice of EVM; they have achieved what many have only dreamed of: proving the worth of EVM to the technical community.”
Format: Paperback
Publisher: IEEE Computer Society and John Wiley
ISBN-10: 0471721883
ISBN-13: 978-0471721888
8. EDUCATION AND ACADEMIA
8.1 Challenges and Best Practices in Systems Engineering Across Innovative Companies in the German-speaking Region
Fraunhofer Institute for Experimental Software Engineering
Kaiserslautern, Germany
In the summer of 2016, Fraunhofer IESE conducted a study about challenges and best practices in the area of systems engineering across innovative companies in the German-speaking region. The results of the study were presented in Japan at the end of October 2016, as many Japanese companies are interested in sharing experience on how to successfully establish systems engineering in the organization and make it sustainable.
One of the major findings is that software is the key to innovation and increased productivity. The amount of software in formerly largely hardware-dominated products has continuously increased over time. Software is perceived as an enabler of new, innovative services and business models in all sectors of industry and society. Systems engineering is an interdisciplinary approach that considers both the business and the technical needs of all customers. Being able to establish appropriate Systems Engineering practices in the organization is crucial for staying competitive and for developing innovative products on time, within budget, and with a high level of quality.
Another major finding is that systems engineering is increasingly critical due to customer demand for higher quality, increased product complexity, and the requirements related to system platforms and integration. Key systems engineering challenges identified in the report are organizational change management, managing complex requirements and interfaces, and modeling and simulation.
Another major finding is that the greatest improvement potential for systems engineering lies in increased virtual engineering and better integration of the tool chains used.
Organizational and technical recommendations are provided.
View the Study:
Review the Report Slides:
Part I – Overview and Analysis Results
Part II – Best Practices for Systems Engineering
8.2 University of Technology of Compiègne
Compiègne, France
“Meaning to Innovation”
The University of Technology of Compiègne (French: Université de Technologie de Compiègne, UTC) is a public research university located in Compiègne, France. It was founded in 1972 by Guy Deniélou and is described as the first experimental technological university in France.
UTC’s 6-hectare (15-acre) campus is part of the city of Compiègne, 80 kilometers (50 mi) north of Paris, and overlooks the Oise River with a blend of traditional and modern architecture. The university is one among a small group of French technological universities which tend to be primarily devoted to the instruction of technical arts and applied sciences.
UTC is organized into nine research units within the School of Engineering. The university offers around thirty degree programs in twenty fields, leading to bachelors, masters, and doctorate degrees.
The teaching model is a mix between North American and French traditions; students select their classes, which are complemented by assisted classwork and applied lab work.
The UTC has been ranked No. 1 in the nation for highest median earnings by recent alumni in 2016 with L’Étudiant.
UTC has established six areas of research as institute priorities: biotechnology, energy and the environment, nanotechnology, computation and information technology, and media and the arts.
Among the degree offerings is a Master’s Degree in Complex Systems Engineering. The objectives assigned to this program are to provide future engineering managers with a solid scientific and technological knowledge base to be able to study (viz., to characterize and understand), model, and design complex and innovative systems using a systemic multidisciplinary approach.
Sources: Wikipedia, UTC Webpage
8.3 Delft University of Technology
Delft, Netherlands
“Challenge the Future”
Delft University of Technology (Dutch: Technische Universiteit Delft) also known as TU Delft, is the largest and oldest Dutch public technological university, located in Delft, Netherlands. As of 2019, it is ranked in the top 20 of best universities for engineering and technology worldwide and is the highest ranked university in the Netherlands. Generally, the TU Delft has been placed in the top 200 universities in the world by five major ranking tables.
With eight faculties and numerous research institutes, it hosts over 19,000 students (undergraduate and postgraduate), more than 2,900 scientists, and more than 2,100 support and management staff.
The university was established on 8 January 1842 by William II of the Netherlands as a Royal Academy, with the main purpose of training civil servants for the Dutch East Indies. The school rapidly expanded its research and education curriculum, becoming first a Polytechnic School in 1864, Institute of Technology in 1905, gaining full university rights, and finally changing its name to Delft University of Technology in 1986.
Among the degree offerings are a Professional Doctorate in Engineering a Master of Science in Complex Systems Engineering and Management, and a Doctorate in Aerospace Engineering.
9. Some Systems Engineering-Relevant Websites
IT Technology Center Japan
This site contains gives access to a wide variety of information on systems engineering as well as tutorials and guidebooks related the Internet of Things, Complex Systems, Quality Assurance, Critical Infrastructure and Internationalization.
https://www.ipa.go.jp/english/ikc/index.html
SE Universities and Research institutes for SE
This list of systems engineering at universities gives an overview of the different forms of systems engineering (SE) programs, faculties, and institutes at universities worldwide. Education in systems engineering is often observed to be an extension to the regular engineering courses, reflecting the industry attitude that engineering professionals need a foundational background in one of the traditional engineering disciplines (e.g. civil engineering, electrical engineering, industrial engineering) plus professional, real-world experience to be effective as systems engineers. Undergraduate university programs in systems engineering are rare.
https://en.wikipedia.org/wiki/List_of_systems_engineering_universities
First Principles of Product Management
Brandon Chu advises that some of the best project managers he knows make their decisions based on first principles. A first principle is a “basic, foundational proposition or assumption that cannot be deduced from any other proposition or assumption”. First principle thinking helps PMs because as companies scale, communicating the rationale behind historical, current, and future decisions can be simplified in a way that their team and stakeholders can rally around. This enables people around the PM to move quickly in the same direction, decouple, and make smart tradeoffs without their presence.
https://blackboxofpm.com/the-first-principles-of-product-management-ea0e2f2a018c
10. Standards and Guides
10.1 OMG System Modeling Language, SysML® Version 1.6 Released
SysML® Version 1.6 was released in December, 2019. Changes from Version 1.5 are in the areas of:
- compartment names
- more formalism: OCL instead of text
- block-typed properties without associations
- property-specific types
- conjugated ports.
A discussion of these changes is at https://mbse4u.com/2019/12/05/whats-new-in-sysml-1-6/
10.2 New PMI Standard for Earned Value Management
Approved by the American National Standards Institute
Editor’s Note: This new standard is described in the SE Publications of this issue.
The new PMI Standard for Earned Value Management (EVM) is an American National Standards Institute (ANSI) standard. It was approved by ANSI as ANSI/PMI 19-006-2019 on 10/29/2019.
The ANSI approval is further evidence that it is a “widely accepted standard for program and project management (P/PM) planning and delivery.” Per the Program Management Improvement and Accountability Act of 2015 (PMIAA), the Office of Management and Budget (OMB) is required to:
- Adopt and oversee implementation of government-wide standards, policies, and guidelines for program and project management for executive agencies;
- Establish standards and policies for executive agencies consistent with widely accepted standards for program and project management (P/PM) planning and delivery; and
- Establish a 5-year strategic plan for P/PM
ANSI vs. EIA
Per the ANSI web site, “Encompassing practically every industry, the Institute represents the diverse interests of more than 270,000 companies and organizations, and 30 million professionals worldwide.” ANSI is the only accreditor of U.S. voluntary consensus standards developing organizations
In contrast, EIA-748, was approved by SAE International (SAE). It is not ANSI-approved. SAE is the Society of Automotive Engineers. Per Wikipedia, SAE International has over 138,000 global members. Per SAE, an SAE standard is a technical report, documentation of broadly accepted engineering practices or specifications for a material, product, process, procedure, or test method.
Per OMB Circular, Federal Participation in the Development and Use of Voluntary Consensus Standards (VCS) and in Conformity Assessment Activities (Circular). In evaluating whether to use a standard…an agency should consider the following:
- Whether the standard is effective and otherwise suitable for meeting agency regulatory, procurement, or program needs, including as applicable
- the prevalence of the use of the standard in the national and international marketplaces;
Approval of ANSI/PMI 19-006-2019 by ANSI is evidence that it meets the PMIAA criterion of being widely accepted and that it meets the OMB criterion, prevalence of the use of the standard in the national and international marketplaces.
EIA-748 no longer meets the OMB and PMIAA criteria for a Voluntary Consensus Standard. ANSI/PMI 19-006-2019 should fill the gap.
11. Some definitions to close on
11.1 Acceptance
An agreeing either expressly or by conduct to the act or offer of another so that a contract is concluded and the parties become legally bound
Source: Merriam Webster
11.2 Function
The action for which a person or thing is specially fitted or used or for which a thing exists.
11.3 Integration
The act or process of uniting different things.
12. Conferences and Meetings
For more information on systems engineering related conferences and meetings, please go to our website.
The featured event for this edition is:
The International Conference on Design Engineering and Science
February 27-29, 2020
2020 5th International Conference on Design Engineering and Science (ICDES 2020) will be hosted in Shenzhen, China during Feb. 27-29, 2020, in conjunction with IC4M 2020. ICDES 2020 is organized by Hong Kong Society of Mechanical Engineers, technical sponsored by Loughborough University, Gent University, IQS, South China University of Technology and other organizations. The idea of the conference is for the scientists, scholars, engineers and students from the universities all around the world and the industry to present ongoing research activities, and hence to foster research relations between the universities and the industry.
13. PPI and cti News
13.1 A (PP) International Edition of SyEN!
This month, PPI SyEN editors are pleased to bring an edition of SyEN featuring authors from Germany, the USA, France, the Netherlands, Japan and Columbia. This makes this month’s edition our most global yet (from the perspective of residences of contributing authors). Thank you to all our authors for contributing to this special edition.
If you would be interested in submitting an article for inclusion in an upcoming SyEN, please contact SyEN editor Ralph Young.
13.2 PPI to attend the INCOSE International Workshop 2020
Three PPI team members including Robert Halligan (Managing Director), Randy Iliff (Principal Consultant and Course Presenter) and René King (CTI Managing Director) will be attending the INCOSE IW in Torrance, California from 25 to 28 January 2020 to participate in this flagship SE event. Our team members will be involved in a host of activities including: intensive work sessions on and a daily demonstration of the Systems Engineering Tools Database (SETDB) prototype; attending relevant work sessions not related to the SETDB; and partaking in discussions regarding PM-SE integration fostered by PMI and INCOSE and beyond! his is one of our favorite SE events of the year as it gives us a chance to roll up our sleeves and collaborate with SE professionals from around the world in order to create valuable work products that will benefit engineering development for years to come. It also gives us a chance to let our hair down outside of working hours as we reconnect with old friends and make friends anew. See you soon, Torrance!
14. PPI and CTI Events
On-site systems engineering training is delivered worldwide throughout the year. Below is an overview of public courses. For a full public training course schedule, please visit https://www.ppi-int.com/course-schedule/
Systems Engineering 5-Day Courses
Upcoming locations include:
- Amsterdam, the Netherlands (P006-802)
24 Feb – 28 Feb 2020
Requirements Analysis and Specification Writing 5-Day Courses
Upcoming locations include:
- Madrid, Spain (P007-500)
09 Mar – 13 Mar 2020
Systems Engineering Management 5-Day Courses
Upcoming locations include:
- Bristol, United Kingdom (P1135-183)
02 Mar – 06 Mar 2020
Requirements, OCD and CONOPS in Military Capability Development 5-Day Courses
Upcoming locations include:
- Melbourne, Australia (P958-62)
16 Mar – 20 Mar 2020
Engineering Successful Infrastructure Systems (ESIS5D)
Upcoming locations include:
- Detroit, MI USA (P2005-5)
15 Jun – 19 Jun 2020
Architectural Design 5-Day Course
Upcoming locations include:
- Adelaide, South Australia (P1768-27)
04 May – 08 May 2020
CSEP Preparation 5-Day Courses (Presented by Certification Training International, a PPI company)
Upcoming locations include:
- Bristol, U.K. (C002-96)
27 Apr – 01 May 2020
Medical Device Risk Management 3-Day Course
Upcoming locations include:
- Berlin, Germany (P1848-8)
17 Mar – 19 Mar 2020
Other training courses available on-site only include:
- Project Risk and Opportunity Management 3-Day
- Managing Technical Projects 2-Day
- Integrated Product Teams 2-Day
- Software Engineering 5-Day.
15. Upcoming PPI Participation in Professional Conferences
PPI will be participating in the following upcoming events. We support the events that we are sponsoring, and look forward to meeting old friends and making new friends at the events at which we will be exhibiting.
Institute of Industrial and Systems Engineering Annual Conference 2019
(Exhibiting)
Date: 30 May – 02 June, 2020
Location: New Orleans (LA), United States
The INCOSE International Symposium 2020
(Exhibiting)
Date: 18 – 23 July, 2020
Location: Cape Town, South Africa
Kind regards from the PPI SyEN team:
Robert Halligan, Editor-in-Chief, email: rhalligan@ppi-int.com
Ralph Young, Editor, email: ryoung@ppi-int.com
René King, Managing Editor, email: rking@ppi-int.com
Project Performance International
2 Parkgate Drive, Ringwood, Vic 3134 Australia
Tel: +61 3 9876 7345
Fax: +61 3 9876 2664
Tel Brasil: +55 12 9 9780 3490
Tel UK: +44 20 3608 6754
Tel USA: +1 888 772 5174
Tel China: +86 188 5117 2867
Web: www.ppi-int.com
Email: contact@ppi-int.com
Copyright 2012-2020 Project Performance (Australia) Pty Ltd, trading as
Project Performance International
Tell us what you think of PPI SyEN. Email us at syen@ppi-int.info.
- That said, ‘immaturity of the discipline’ is still used as an explanation for failure in software projects. ↑
- The way SysML ports changed between v1.2 and v1.3, while arguably simpler and progressive, left many users confused. ↑
- Named so because it ‘unified’ concepts from the three authors, Rumbaugh, Jacobson, and Booch (colloquially known as the Three Amigos) using existing modeling approaches: Rumbaugh’s Object-Modeling Technique (OMT); the eponymous Booch Method; and Jacobson’s Object-Oriented Software Engineering (OOSE). ↑
- One of the criticisms often levelled at UML is that since its first official adoption in 1997, more and more semantics have been added such that it has become ‘bloated’ with many concepts of little use to the average software modeler. ↑
- Whereas Blocks can be thought of as constraining all instances in all contexts at all times, individuals constrain instances to subsets of those contexts, and snapshots constrain individuals to specific time periods. ↑
- Although we shouldn’t be complacent. At the recent INCOSE UK Annual SE Conference (Leeds, UK, November 2019) a speaker reported that “MBSE is not on the horizon for the UK Ministry of Defence (MOD)” (Kemp, et al, 2019). ↑
- As defined by the INCOSE Systems Engineering Handbook 4th Edition (Walden et al. 2015). ↑
- We shouldn’t confuse the fact that SysML is built on four pillars; Requirements, Structure, Behaviour and Parametrics, with it having an embed approach. The language simply defines valid models, not what should be built and in what order. ↑
- Kouzes and Posner, p.215. ↑