Home » SyEN Newsjournal » PPI SyEN 54

PPI SyEN 54

Read monthly Project Performance International's Systems Engineering Newsjournal, named "PPI SyEN". PPI SyEN presents for the engineering professional 30-60 pages of valuable technical articles on topical subjects, shorter technical pieces, in-depth coverage of the month's news in systems engineering and directly related fields, pointers to useful resources and relevant industry events, plus limited information on PPI's activities.

Welcome to PPI SyEN 54

In This Edition

A Quotation to Open On

Feature Article

Coupling Methodology and Tooling for Systems Modelling: ARCADIA and Capella at Thales by Joe Silmon, Jean-Luc Voirin, and Stéphane Bonnet

Article

Systems Thinking: Life-Enhancing Business through Leadership: An interview with Fritjof Capra by Sandja Brügmann
Lean Thinking for Systems Analysis by Katarzyna Kot
Integrating Program Management and Systems Engineering by Ralph Young

Systems Engineering News

Tutorial on Data Science
Self-Contained Systems Map the User Journey
Systems Thinking: A View from the Trenches
Engineering Systems: A Convergence of Disciplines

Featured Organizations

Project Management Institute
INCOSE Agile Systems and Systems Engineering Working Group

Conferences and Meetings

Some Systems Engineering-Relevant Websites

Systems Engineering Publications

INCOSE Publishes its Systems Engineering Handbook in Chinese
A Guide to Selecting Software Measures and Metrics
Engineering Systems: Meeting Human Needs in a Complex Technological World
The MIT Guide to Science and Engineering Communication
The Human Side of Managing Technological Innovation: A Collection of Readings
Presentation for the Knowledge Professions by Gavan Lintern

Systems Engineering Tools News

Capella by PolarSys by Alwyn Smit

Education and Academia

Drexel University’s Online Master’s Degree in Systems Engineering
Worldwide Directory of SE and IE Academic Programs
Project Management Institute (PMI) Academic Programs & Research
Employees Graduate from Rigorous Systems Engineering and Systems Integration Programs at Naval Postgraduate School
Engineering Students Showcase Their Best Ideas
University of Kentucky, College of Engineering to Induct Five Alumni into its Hall of Distinction

Standards and Guides

Object Management Group Chairs Report on Future Direction of Technology Standards

Some Definitions to Close On

General Concepts and Approaches Related to Systems

PPI and CTI News

Upcoming Participation in Professional Conferences

PPI and CTI Events

A Quotation to Open On

While management and leadership are related and often treated as the same, their central functions are different. Managers clearly provide some leadership, and leaders obviously perform some management.

However, there are unique functions performed by leaders that are not performed by managers. My observation over the past forty years … is that we develop a lot of good managers, but very few leaders.

Let me explain the difference in functions that they perform:

A manager takes care of where you are; a leader takes you to a new place.
A manager is concerned with doing things right; a leader is concerned with doing the right things.
A manager deals with complexity; a leader deals with uncertainty.
A manager creates policies; a leader establishes principles.
A manager sees and hears what is going on; a leader hears when there is no sound and sees when there is no light.
A manager finds answers and solutions; a leader formulates the questions and identifies the problems.

James E. Colvard

PPI believes that all engineers are (or should be) leaders. Engineers practicing systems engineering are (or should be) empowered to advise concerning continuous improvement opportunities anywhere in a Program, Project, or Organization (PPO). They should be committed to PPO goals, objectives, priorities, benefits, and results. They should support PPO in creating a shared vision, encouraging active participation in decision-making, evolving collaboration among all team members, and facilitating full and easy access to information and data that are needed.

Feature Article

Coupling Methodology and Tooling for Systems Modelling:

ARCADIA and Capella at Thales

Joe Silmon, Jean-Luc Voirin, and Stéphane Bonnet

Thales S.A.

Thales S.A. is a global provider of engineering solutions and consultancy to the security, space, transportation, aerospace, and defense industries. In all sectors, Thales analyses customer needs and develops solutions that can include combinations of new technologies, existing Thales products, and integrated parts from other suppliers. The Thales engineering methodology and tool set enables engineering teams to manage the high complexity of modern technology in areas such as inter-bank secure transactions, safety-critical train control for metros and main line railways, and military C4I (Command, Control, Communications, Computers, and Intelligence).

Abstract

Model-based systems engineering has often come under criticism for being tool-driven and failing to solve the problems engineers are facing on projects. The notion of models as “shelf ware” has come about in part due to a disjoint between approaches, engineering procedures, and media of communication. The ARCADIA design approach and the Capella system modelling tool have been developed to more tightly couple the output of modelling with the needs of an engineering process. In this article, we describe their background, and illustrate how the two fit together, allowing engineers to realize benefits in both pure model-based scenarios and more pragmatic model-supported scenarios.

Website: http://www.thalesgroup.com

Email: joe.silmon@uk.thalesgroup.com

Introduction

In early 2006, Thales decided to launch an in-depth engineering transformation plan, to face new challenges and new customer expectations worldwide. This plan led to the development, in collaboration with the partners of the Clarity consortium, of an engineering method offering a language to describe engineering assets, and a tool for describing those assets using formal models.

The method is called ARCADIA, and is currently in use in most Thales units and technical domains worldwide, where security, performance, and safety are critical to success. The method and its dedicated modelling tool, named Capella, have been designed to support tightly coupled development and engineering teams, with real-life, full scale, short loop assessment of each feature to be considered.

In this paper, we will give an outline of ARCADIA’s structure and principles, and details of Capella’s features and user interface.

Scope

ARCADIA and Capella are two distinct solutions that work together for the implementation of model-based systems engineering (MBSE). As illustrated in Figure 1^[1], ARCADIA (which stands for ARChitecture And Design Integrated Approach) covers the methodology and the high-level conceptual ontology and viewpoints.

Capella elaborates on these with more detail to provide a comprehensive set of diagrams and notation elements. ARCADIA may be used with other tools, but Capella has been purpose-built to provide the notation and diagrams needed to create models that exactly fit with ARCADIA’s approach.

Figure 1 – Scope split between ARCADIA and Capella

Purpose of ARCADIA

ARCADIA is a model-based method and language devoted to systems, software, and hardware architecture engineering to:

Understand the real customer need;
Define and share the system architecture among engineering stakeholders;
Support cooperation between different engineering levels, along with specialities (safety, security, performance, product line etc.);
Validate and justify system design early in the life cycle; and
Ease and master IVVQ (Integration, Validation, Verification, Qualification).

ARCADIA principles and modelling language

The ARCADIA definition is driven by a few structuring principles:

Extended functional analysis to define both need and solution behavior;
Separation of need analysis and solution architecture definition;
Separation of operational need analysis and definition of system contribution to this need (system need analysis);
Separation of functional/behavioral description, and structural decomposition;
Differentiation between the structuring of behavioral/logical components and physical hosting components.

This favors separation of concerns, so as to adapt to different life cycles, provides capabilities for impact analysis, and allows efficient management of architecture alternatives, reuse, etc.

Major concepts of the ARCADIA method and framework

The following subsections illustrate the general semantic concepts covered by ARCADIA, using Capella diagrams as examples. These diagrams are taken from an openly-available demonstrator model that can be downloaded, along with the Capella tool, here.

Functional analysis

Functional analysis is structured by missions and capabilities, dealing with system use case description using functional data flows. Each (leaf) function in the dataflow produces outputs and requires inputs through ports. Function ports are linked to each other by exchanges expressing only possible dependencies between functions.

Figure 2 – Example of system analysis implemented in the System Dataflow diagram in Capella

For each capability, several sequence scenarios or functional chains illustrate how the dataflow functions and exchanges contribute to the capability.

Concurrent Modes and states machines can be defined (for the system and behavioral components), fully integrated and connected with the dataflow and scenarios, and expressing conditions for functional contents availability in each mode or state, and combinations.

Data analysis

$H:\Referent\SE Newsletter paper\[CDB] In-Flight Entertainment Dictionary.png$

Figure 3 – Example of a data model implemented with Capella’s Class Diagram

A data model describes exchanges contents based on class-organized structures. These classes can be grouped into Exchange Items, to be exchanged between functions or components. Exchange items may carry a communication paradigm (such as flow event, operations, etc.).

Behavioral structure

$H:\Referent\SE Newsletter paper\[SAB] Top Level System Overview.jpg$

Figure 4 – Example of behavioural structure at the top level of the system, implemented with the Capella System Architecture diagram

In logical and physical architecture perspectives, behavioral components are defined to implement functions. Component ports are linked by behavioral exchanges, grouping functional exchanges. Component interfaces are defined on ports, and group exchange items (see below). These exchange items are originated from functional exchange contents.

Hosting structure

Behavioral components are hosted by implementation components that deliver needed resources to them. Each behavioral component is hosted by one implementation component, and behavioral exchanges are carried via physical links between implementation components ports.

$H:\Referent\SE Newsletter paper\[PAB] Focus on SVDU Audio Video Playing.jpg$

Figure 5 – Example of hosting architecture implemented with the Physical Architecture diagram in Capella

Other considerations

All model elements included within functional and structural modelling in ARCADIA are instances (i.e. unique and individual elements constituting a part of the system). Reusability is implemented with specific constructs called Replicable Elements, instead of type/instance constructs. Replicable Elements can be defined individually or as collections, and can be stored in libraries to build product-line reference architecture models for future use.

The initial DSL semantics is deliberately not focused on precise executable semantics, so as to adapt to various needs in terms of viewpoint analyses, models of computations, and simulation flavors/objectives. Each domain may enrich it according to its own needs.

Perspectives

Five major perspectives, tightly integrated with the language, structure the model according to major engineering activities and concerns, each one dealing with specific engineering issues and outputs. These are listed below, together with an example of how elements can be traced from one level to another, providing instant justification for design features and assurance that requirements are met by architecture.

Table 1 – the five ARCADIA perspectives and their architectural concerns

Perspective	Major architectural concern	Example element tracing
Operational analysis	What the users of the system need to accomplish (user need)	Operational entity
System Need Analysis	What the system has to accomplish for the Users (system need)	System
Logical Architecture	How the system will work so as to fulfil expectations (notional solution)	Logical component
Physical Architecture	How the system will be developed & built (finalized architecture)	Behavioral physical component, hosting physical component
Product Building Strategy	Which configuration items constitute the system, how it shall be developed, integrated, verified	Configuration item

Capella

The scope and target of a method have direct consequences on the associated tooling. ARCADIA does not cover the full spectrum of design activities: its focus is primarily on architectural design, excluding, for example, low-level behavioral modelling or simulation. The original audience for the ARCADIA/Capella solution was primarily systems engineers with diverse backgrounds and skills.

At one end of the spectrum, standard or universal languages such as SysML target a wide variety of domains and modelling intentions. At the other end, specialized modelling languages have reduced coverage and more focused intentions, as they are intended to provide solutions for particular domains. These characteristics make them more likely to provide richer semantics and enhanced formalism.

Today, most modelling tools support SysML and provide various degrees of extensibility and customization. Therefore, the most common approach to implement MBSE methodological guidance is to enrich the SysML language with method-specific profiles, adding semantics and to provide relevant productivity and validation tooling.

Between 2003 and 2006, this alternative was the first-line approach for ARCADIA method support. A few man-years’ worth of development went into the creation of a UML profile and a significant amount of associated tooling such as model transformations and validations. The developed solution suffered not only from language complications, but from ergonomics issues as well and was quickly rejected by the pilot practitioners.

Capella is neither a SysML profile nor a domain-specific language (DSL). The core meta-model of the Capella notation has been strongly inspired by SysML and the diagrams provided are very similar. However, when considering the SysML language as a reference, the meta-model of Capella is simultaneously simplified, modified and enriched.

Simplified or modified: whenever SysML concepts were more complex than necessary to model architectures, they were either excluded (many low-level behavior modeling constructs are absent) or simplified (components, parts, instances);
Enriched: ARCADIA implements an architectural framework, where description languages such as SysML do not; the Capella tool implements this framework in its meta-model.

The main advantage of this hybrid approach is that Capella diagrams can be read and understood (to a certain extent) by engineers having no particular knowledge of Arcadia. The lessons learnt in the simplification of SysML are being fed back through our membership of the SysML 2 working group.

Capella is an original solution in the landscape of modelling workbenches for several reasons including the tight coupling between the method and the tool, the availability of multiple productivity tools, the artefacts allowing to master design complexity and the fact that it is an open source solution.

Tight coupling between the method and the tool

Its tight coupling with the ARCADIA method is one of the key aspects of Capella. In addition to having its concepts directly aligned on the ARCADIA ones, three features strongly enforce the implementation of the method in Capella models:

All projects are initialized with a model structure which reflects the ARCADIA engineering perspectives;
The graphical aspect of elements in all edition view and diagrams is aligned with the ARCADIA ones. For example, green is dedicated to functional analysis, blue is dedicated to structural elements and red is dedicated to interfaces;
A method explorer is the key interaction interface for Capella models, as illustrated in Figure 6.

Figure 6 – Capella screenshot indicating features of the user interface

The customizable method explorer lists all major modelling activities for each perspective, proposes shortcuts to the most suitable graphical representations, and provides an index for all existing diagrams for each activity. This explorer is of course a great help for beginners, eliminating the blank page syndrome. But beyond that, it is a powerful tool to navigate in Capella models.

Value-added productivity tools

A system model obeys construction rules. It is a graph, where elements are interconnected in multiple ways. Productivity tools help end-users create their models in a more efficient way, taking into account existing model parts to initialize others. A simple example is the one of interfaces between components, which is one of the key objectives of ARCADIA.

In the method, functions are connected to each other with functional exchanges expressing dependencies (data, energy, etc.). These dependencies are specified with formal descriptions (typically using class diagrams). As functions are allocated to components, it is straightforward to deduce the content of interfaces between components based on the dependencies between their allocated functions. Capella provides dedicated generation algorithms, validation rules and associated quick fixes.

Productivity or automation tools not only accelerate day-to-day modelling activities; they also improve the consistency and correctness of models by reducing human mistakes. Other productivity tools of Capella include automated and iterative model transitions from one Arcadia perspective to another, brushing of layouts between diagrams, etc.

Another key feature is the instant querying capability of the “semantic browser” (see Figure 7). This area of the user interface is populated by the relationships of any selected object on a diagram. A user can instantly query what an element is related to and which other views it appears in.

Complexity mastering

One of the main rationales for the deployment of model-based systems engineering is to be able to cope with the growing complexity of systems. It is mandatory for a modelling tool to provide concrete help to master this complexity.

This starts with reducing the incidental complexity. By simplifying the underlying modelling concepts (when compared to SysML for example), Capella minimizes the learning curve and improves the readability of models. While this is necessary, it is not sufficient and providing mechanisms to concretely help visualize and navigate models is essential.

The most illustrative example is the way Capella manages functional analysis with computed graphical simplifications favoring readability, understanding, and analysis. The ARCADIA method specifies that only leaf functions can ultimately have input and output object flows, own ports, and be allocated to structural elements.

Figure 7 – Example of the semantic browser populated with relationships

In Capella, ports and object flows appearing on non-leaf functions either reflect an intermediate design that is not yet finalized, or are a computed synthesis. The ports owned by children functions can be artificially displayed on parent functions, making the production of synthetic views such as the alternative representations 1 and 2 in Figure 8 possible at no cost.

This Capella implementation is also well adapted to different workflow (top-down, bottom-up). Refinement work consists in creating sub functions and drag-dropping existing ports. Bottom-up approaches simply consist of grouping leaf functions in parent ones and relying on the automated production of synthetic views.

Figure 8 – Synthetic views computed by Capella

Open source

Capella has been developed as a proprietary workbench by Thales for about six years before it was made open source in 2014. The ecosystem around Capella is now growing significantly, with major industrial organizations adopting the Arcadia method. Coupling with other engineering tools such as Safety Architect or the simulation modelling environment Citrus are direct results of this open sourcing strategy enabling open innovation around Capella.

Open source does not necessarily mean “free” for an adopting organization, because professional support and coaching are often required to increase the chances of success. However, open source means “open”: end-user organizations can join the Capella industry consortium, contribute and influence the development roadmap.

This openness is the highest guarantee of sustainability and freedom to customize, exploit, and enrich the tool according to their needs. Open source means organizations can shape the future of Capella and take the control of their modelling environment.

Scalability and applicability

ARCADIA can be used to implement a fully model-based systems engineering process, but it can add value to more traditional processes through careful scaling of the tasks undertaken and the models created.

For example, on a recent metro railway project, there was a clear distinction between core required functionality and the project-specific needs. Core functionality had been developed around thirty years ago for Thales’ first unattended metro railway (the Vancouver Skytrain). Hence, the design processes predate ARCADIA and, indeed, Thales itself in its current form.

This functionality, and the underlying design paradigm, were developed using formal requirements-based methods compliant with applicable international standards. The functions have been implemented, verified, and validated many times. Retrospectively modelling this functionality applying ARCADIA would add minimal value for a very large effort.

In contrast, the project-specific needs, such as external interfaces to depots, other systems belonging to the metro operator, and metro trains interoperating with main line trains under the protection of other signaling systems, were complex and not universally understood. Here, the project team implemented a scaled-back ARCADIA approach: not trying to engineer the entire system, but identifying the specific areas of interest and taking the ARCADIA approach to define their architecture within the context of an established system.

Whilst not approaching the level of maturity that is aspired to by MBSE purists, this pragmatic solution proved its value by assisting the engineering team in formalizing system requirements for these complex areas. The model-supported approach interleaves model artefacts with traditional requirements-based artefacts, as shown in Figure 9. This allowed the engineering teams to continue using established processes, but with model content to enhance existing documents, where they added value.

Figure 9 – Model-supported systems engineering

Summary

The journey towards model-based systems engineering is not straightforward. To equip engineering teams with the know-how and practical experience to implement such a paradigm shift is a major challenge.

By developing process-based tools and techniques that tie more closely in with current thinking and with corporate procedures, the ARCADIA and Capella teams have put into the hands of the engineering community a comprehensive toolkit with which to model their problem space and system architecture, whilst reducing the need for specialized training and years of theoretical learning. The open-source approach has seen collaboration between organizations and the development of a thriving ecosystem of tools.

List of acronyms and abbreviations used in this article

Term	Explanation
ARCADIA	Architecture and design integrated approach
DSL	Domain-specific language
IVVQ	Integration, verification, validation, and qualification
MBSE	Model-based systems engineering
SysML	Systems modelling language
UML	Unified modelling language

References

[1] Holt, Jon and Perry, Simon. SysML for systems engineering, 2^nd edition: a model-based approach. IET, 2014. ISBN 9-781849-196512.

Web links:

Capella website: https://polarsys.org/capella/index.html

Capella in-flight entertainment demonstrator model: https://polarsys.org/capella/start.html

ARCADIA introduction on the Capella website: https://polarsys.org/capella/arcadia.html

Clarity consortium website: http://www.clarity-se.org/consortium/

Safety Architect website: http://www.all4tec.net/Model-Based-Safety-Analysis/model-based-safety-analysis.html

Citrus website: http://solutions-isoneo.com/?page_id=499h

Article

Systems Thinking: Life-Enhancing Business through Leadership

An interview with Fritjof Capra

Sandja Brügmann

Originally published by Sustainable Brands

Used with permission.

Image Credit: The Good Campaigner

Change is one of the most challenging elements of life within an organization. To sustain a change agenda moving away from behaviors and decisions that are life-destroying to becoming life-enhancing, the nuances of both corporate culture and the patterns of human behavior need to be understood. This requires systems thinking – also called visual seeing and thinking skills.

I sat down with Fritjof Capra, one of the world’s most distinguished scientists and systems theorists, to discuss the implications of systems thinking for business, leadership and society.

Sandja Brügmann (SB): In Capra Course, you speak to the biggest crisis of our time – that we are not just experiencing a sustainability crisis, but a crisis of perception. What is this crisis of perception? And how does it differ from a sustainability crisis?

Fritjof Capra (FC): Two key aspects of the crisis we find ourselves in are that it is global and that its many facets — energy, the environment, climate change, economic inequality, violence and war — are all interrelated and interdependent. None of these global problems can be understood in isolation; they are systemic problems. To understand and solve them we need to learn how to think systemically — in terms of relationships, patterns, and context. This is what I teach in my Capra Course. So, we are talking about one global crisis with many interdependent facets. You can call it a sustainability crisis, because all of its facets are obstacles to a sustainable society. But this does not describe the fundamental nature of the crisis. It is rooted in the inability of our leaders to see our problems as systemic problems, and to design appropriate systemic solutions. This is why I call it a crisis of perception.

A systems view of life is critical today for all professions, because the major problems of our time are systemic problems — all interconnected and interdependent — and they need corresponding systemic solutions. The systems view of life provides the conceptual framework for such systemic solutions.

SB: How does this crisis of perception influence human life, leadership and business?

FC: Most of our business and political leaders are unable to “connect the dots,” to use a popular phrase. They fail to see how the major problems of our time are all interrelated. Their so-called “solutions” tend to focus on a single issue, thereby simply shifting the problem to another part of the system — for example, by producing more energy at the expense of biodiversity, public health, or climate stability. Moreover, they refuse to recognize how their piecemeal solutions affect future generations.

SB: You talk about how life-enhancing organizations can only truly flourish when the entire economic system has been changed from life-destroying to life-enhancing. Can you explain the terms ‘life-destroying’ and ‘life-enhancing,’ in terms of business and leadership?

FC: To understand if, and in what sense, a business organization is alive, is a difficult subject that I struggled with for many years, until I realized that every human organization has a dual nature. It is a legal and economic entity, designed for a specific purpose, and it is also a community, or a cluster of communities — informal networks known as “communities of practice.” The organization’s aliveness resides in its communities of practice. Life-enhancing leadership recognizes and legitimizes these informal networks; life-destroying leadership suppresses them.

SB: Is it a utopian dream to think that the current business and economic environment can become life-enhancing? It seems one of the key blocks to this is that in the current system, it’s people with money who hold the power. In order for these people to support the move towards a life-enhancing economic and business structure, they need to see what’s in it for them. How would you speak to them so they can understand the implications for them if we stay in a life-destroying economic model?

FC: So far in our conversation, I have mentioned the crisis of perception and systemic thinking. This is not all there is to the problems of our time, even though it is my main focus. The other part is values. Most people in power want to hold on to it, and even to increase it, valuing short-term personal financial gains higher than the well-being of communities and future generations. In other words, there is a clear lack of ethics in our business world and in our politics. Ethical behavior is always behavior for the common good. How to speak to powerful people about this is not easy. I would say, we have to show them the relationship between behavior for the common good and sustainability. If they continue to only care about “what’s in it for them” in the short run, they will destroy the future of their children and grandchildren, and ultimately of their business.

SB: How can leaders and people of all walks of life support the change towards a life-enhancing economic system?

FC: In our daily lives, we make hundreds of decisions that are either life-enhancing (sustainable) or life-destroying (unsustainable). Do I recycle my bottles and plastics, or do I throw them away? Do I use a paper or a cloth shopping bag? Do I drive, or do I bicycle (or walk) for short distances? Do I eat mostly beef or mostly vegetarian food? Do I let the water run while brushing my teeth, or do I use a cup? In business, sustainable actions should be encouraged and rewarded (symbolically and financially); in government, they should be supported by ecological “tax shifting” (reducing taxes on work and raising them on environmentally destructive activities).

SB: What are the key influences needed for humanity to live and do business in a thriving manner within the planetary boundaries? What kind of business values and leadership are needed to accomplish this?

FC: As I have mentioned, ethical behavior is behavior for the common good. It is always related to a particular community. In today’s world, there are two communities to which we all belong. We are all members of humanity, and we all belong to the global biosphere – the “Earth Household” (the meaning of the Greek oikos, the root of “ecology”). The outstanding characteristic of the Earth Household is its inherent ability to sustain life. As members of the global community of living beings, it behooves us to behave in such a way that we do not interfere with this ability, and our behavior should reflect a respect of human dignity and basic human rights. To lay this out in detail is quite a challenge, but fortunately we have a magnificent document, the Earth Charter, which covers the broad range of human dignity and human rights. It is a global declaration of 16 values and principles for building a just, sustainable and peaceful world. The Earth Charter is a perfect summary of the ethics we need for our time.

SB: I found your lecture on living systems and change management and business fascinating. It is complex to create leadership transformation within corporations. What are some of the key areas to be aware of when working with expanding perceptions and change within business and leadership?

FC: The main challenge, in my view, is how to bring life into human organizations. The best way to do so is to acknowledge and legitimize the role of the living networks, or communities of practice, in every organization. This includes recognizing the creativity inherent in all life, which manifests in the spontaneous emergence of novelty, and to facilitate and reward that emergence. Facilitating emergence is now increasingly being recognized as a new form of leadership.

SB: How does a systemic understanding of the world impact ecoliteracy (ecological literacy)?

FC: Living sustainably means living in such a way that we do not interfere with nature’s inherent ability to sustain life. To do so, obviously, we first need to understand how nature sustains life. We need to understand the basic principles of organization that nature’s ecosystems have evolved to sustain the web of life. This knowledge is what I call “ecological literacy,” or “ecoliteracy.” It requires systemic thinking because ecology is essentially a science of relationships, and thinking in terms of relationships is what systems thinking is all about.

SB: The topic of power is particularly interesting, when working with executive leadership and business. What have you found characterizes the old type of power and how is the new power different?

FC: Basically, there are two kinds of power: power as domination of others (the old type of power) and power as empowerment of others (the new power). Whereas power as domination is most effectively exercised through a hierarchy, the most effective social structure for power as empowerment is the network. In a social network, people are empowered by being connected to the network. In such a network, the success of the whole community depends on the success of its individual members, while the success of each member depends on the success of the community as a whole. Any enrichment of individuals, due to increased connectedness in the network, will also enrich the entire network.

SB: How do we change power structures within an organization or institution, or even cultural system of a nation?

FC: All these power structures are already changing. The global civil society, where many of the leaders are women, and the vast number of social media are all exerting the new type of power as empowerment. The youth of today has been growing up with and within these social networks and, while often fighting the old type of power, they are used to network empowerment as power of a new kind.

SB: This shift in paradigms seems to have been underway for 30-40 years, and in my work, I have dedicated myself to helping this shift for more than 18 years. The change seems to be very slow and the old system and way of perception and values so ingrained. When do you think we’ll experience a tipping point towards the more enriching way of life? What are some markers you see in the world of forward movement?

FC: I feel that we are at the very cusp of our global crisis — close to the tipping point but also close to disaster. What we need is a profound change of perception — a change of paradigms from seeing the world as a machine to understanding it as a network. Accordingly, we need to find systemic solutions for our global problems — solutions that do not solve any problem in isolation but deal with it within the context of other related problems. Over the last few decades, the research institutes and centers of learning of the global civil society have developed and tested hundreds of such systemic solutions all over the world. In my course I review some of the most important of these solutions. They include new ownership designs that embody a shift from extractive to generative ownership; systemic solutions to the twin problems of energy and climate change; the worldwide renaissance of sustainable agriculture, and the recent dramatic rise in ecologically-oriented design practices and projects — such as solar and wind energy, hybrid-electric cars, ‘green’ architecture, and so on. I conclude that we now have the knowledge and the technologies to build a sustainable future. What we need is political will and leadership.

Fritjof Capra, Ph.D., is a scientist, educator, activist, and author of many international bestsellers that connect conceptual changes in science with broader changes in worldview and values in society. A Vienna-born physicist and systems theorist, Capra first became popularly known for his book, The Tao of Physics, which explored the ways in which modern physics was changing our worldview from a mechanistic to a holistic and ecological one. Published in 1975, it is still in print in more than 40 editions worldwide.

Over the past 30 years, Capra has been engaged in a systematic exploration of how other sciences and society are ushering in a similar shift in worldview, or paradigms, leading to a new vision of reality and a new understanding of the social implications of this cultural transformation.

His most recent book, The Systems View of Life (Cambridge University Press, 2014), presents a grand new synthesis of this work—integrating the biological, cognitive, social, and ecological dimensions of life into one unified vision. Several critics have suggested that The Systems View of Life, which Capra coauthored with Pier Luigi Luisi, Professor of Biology at the University of Rome, is destined to become another classic. Capra Course is based on The Systems View of Life.

Sandja Brügmann is CEO of Refresh Agency and The Passion Institute. She is a sustainable communication expert, conscious business and leadership advisor, international speaker, author and Women Leadership Achievement Award recipient 2017. She has worked with… [Read more about Sandja Brügmann]

Article

Lean Thinking for Systems Analysis

Katarzyna Kot

Published with permission of the author.

Lean thinking comes from Toyota Systems. It is defined as elimination of all non-value-added activities, also called waste. Most people associate lean with factories and production processes, but lean can be used in many different parts of the organization.

The goal of lean is to find areas of waste and to permanently eliminate them. It connects directly with managing and continuously improving the organizational processes. But in order to identify the waste we need to understand what value is, and what activities in our process are necessary to create this value. Once this is understood, the identification of waste becomes easier.

Lean thinking can be applied to a systems analysis process as well. It may be needed too. Research from the Standish Group states that 60 percent of the features implemented in products is never used. This is waste, isn’t it? A part of this waste lies in requirements. Why produce requirements for something that will never be used? Does this situation sound familiar? As a business analyst you are confronted with many situations like that; for me it was checking myself and the process I had to follow as a business analyst for possible improvements. Sometimes you know that something needs to change, but you cannot get a grasp on what it actually is. Lean principles help you discover what the issue might be.

Lean recognizes eight types of waste. An easy way to remember them is to use a mnemonic – TIM WOODS – where each letter represents one form of waste:

· T – Transport: Moving people, products and information

· I – Inventory: Storing parts, pieces and documentation ahead of requirements

· M – Motion: Bending, turning, reaching, lifting

· W – Waiting: For parts, information, instructions, equipment

· O – Overproduction: Making more than is IMMEDIATELY required

· O – Over processing: Tighter tolerances or higher grade materials than are necessary

· D – Defects: Rework, scrap, incorrect documentation

· S – Skills: Underutilizing capabilities, delegating tasks with inadequate training

Transport

Waste of transport is related to the movement of people, products and information from one location to another. Transport adds no value to the product. Why would a customer (or you for that matter) want to pay for an operation that adds no value? In terms of business analysis passing a requirements document to a number of company officials with no clear goal, only because the process says so, is an example of transportation waste. Travelling to speak with your stakeholders about something small, when you could use the phone to get the answer, is transportation waste.

Inventory

Inventory costs you money; every piece of product tied up in raw material, unfinished work or finished goods in a warehouse has a cost and until it is actually sold that cost is carried by you. This is waste. In business analysis the unfinished work – an abandoned requirements document or domain diagram nobody updates anymore, for example – is inventory waste. We can also think of a requirements document as waste. The requirements document without working SW is worth nothing. Producing requirements documents with lots of models and without transforming them into a product is an inventory. It is a partially done work. We don’t want too much of it.

Motion

Motion waste is related to unnecessary movements of man or machine. In terms of business analysis you may think about excessive distance between agile team members, who should work together, or working with offshoring or geographically dispersed teams. Offshoring agile teams may introduce this waste as well as working with them may introduce additional overheads. Quite often motion waste introduces waiting waste as well, because the performed task will take more time to complete. Motion waste is also related to seeking information. If you don’t know sufficiently well who your stakeholders are, so you are forced to do extra interviews with stakeholders you overlooked at the beginning of the project, is a form of motion waste. Also, think about bad review preparation where you call a stakeholder on many occasions for extra information that you just forgot to ask for during a meeting.

Waiting

Waiting relates to delays due to waiting for an answer or availability. It can be waiting for a stakeholder’s input or waiting for a management decision. It can also mean that a development team has to wait for requirements because a business analyst wants to be sure requirements are complete. We should ask the question of whether we need these details in requirements; whether we need these requirements to be reviewed by 40 stakeholders. What value does this add to the development process? Do requirements need to be that perfect before the team can start working on them? Does the way we do business analysis stand in our way? Perhaps an agreement and setting out boundaries are sufficient to get the job done? When others wait, they are not doing activities that are adding value. And this is waste.

Overproduction

The waste of overproduction is making too much or too early. In other words it is violation of the “just in time”/“just enough” principle of agile. In business analysis it is about producing an extensive requirements document describing features stakeholders requested and not checking requirements’ feasibility. The feasibility check done later in the project may reduce the amount of requirements by 30%. This means that writing those infeasible requirements is waste. But overproduction also has another side. When a stakeholder requests that you change something during sprint execution and you agree to that, it is overproduction waste. You jeopardize the results of the team to accommodate additional needs. The stakeholder might think he can do it next time without consequences. Also, unproductive meetings or involving too many people into a problem or situation fall into this category of waste.

Over processing

The waste of over processing is where inappropriate techniques are used, too much detail added or processes are performed that are not required by the customer. A frequent complaint about business analysts is; that they provide too much or insufficient detail. If a business analyst provides a lot of details and already defines a solution, and then the development team might say that the prescribed solution is not okay, a discussion starts during which a proper solution gets defined. This is waste. Often people ask “How do I know what’s needed?” The answer is by asking the receiving party what they want from me as their business analyst. Define how you can add value to this process, the required level of detail, give it a try and ask for feedback about whether it works. By doing so you will discover how to work effectively together. Over processing waste is also organizing too many reviews on a requirements document or as simple a thing of making notes on paper when you could do it on a word processor immediately.

Defects

This seems to be the most straightforward form of waste. Every defective item requires rework or replacement; it wastes resources such as people’s time and materials e.g. paper you used to unnecessarily print the documents for a review. In business analysis, every time the stakeholder does not understand what a business analyst has produced (either a requirement, diagram or similar) is a waste. Every time a diagram does not make sense, and the stakeholders of a team have to come back to the business analyst to check what he meant with his work, is a defect: the business analyst didn’t do just enough, just in time.

(Underutilization of) Skills

Underutilization of people’s skills and knowledge is an additional waste form, which was adopted by lean. In our knowledge-based economy, effectively developing and applying intellectual capital is the key to creating value. This waste form expresses itself in not learning from each other, lack of involvement or participation by project members, or not knowing skills of others so not using them to the advantage of the project. As business analysts we suffer from this waste when we are involved in the politics of having to deal with stakeholders with short-term thinking. Sometimes you take part in it. Being aware of your environment, and putting effort in to discover and use other people’s skills and knowledge to the advantage of the problem you are trying to solve, are key here.

Conclusions

Being aware of waste forms can help us, as business analysts, to think critically about the process we follow and our role in it. It is never too late to change our practices, to make small adjustments here and there that allow us to become better in what we do. I must say it was quite confrontational for me in the beginning: to check myself and to dedicate some time explicitly to analyzing how my practice contributes to adding value in the process. But it was worth doing. It made me aware of how I work and allowed me to improve for the good of my project team. If you want the same for yourself, check yourself against these different waste forms and start working today on your better, lean existence.

This post is a reprint and is already published on Beyond Business Analysis blog.

References:

http://leanself.org/

http://leanmanufacturingtools.org/

ARTICLE

Integrating Program Management

and

Systems Engineering

Ralph Young

The previous issue of this Systems Engineering Newsletter (SyEN) highlighted a book that has just been released: “Integrating Program Management and Systems Engineering (IPMSE)”. This book was five years in the making and is a collaboration of the International Council on Systems Engineering (INCOSE), the Project Management Institute (PMI), and the Consortium for Engineering Program Excellence (CEPE) at the Massachusetts Institute of Technology (MIT). Every once in a great while, a book comes along that is destined to have a huge impact. We at PPI believe that this book has the potential to significantly improve program results. In support of the needed effort to build collaboration and further strengthen the practice of program management and systems engineering, over the next sixteen months we plan to highlight the message of each of the chapters of “The Book” (IPMSE) in our monthly issues of SyEN. These summaries will be provided in a new section of SyEN, under the caption “Integrating Program Management and Systems Engineering”. Additionally, some of the many references used in the broad research that comprises the knowledge foundation of The Book will be included in the Systems Engineering Publications section of each forthcoming issue of SyEN.

The Book has features that are useful and content that is thought-provoking (for example, in considering the impact of making changes in your program and organization):

The Dedication is an acknowledgement to all those who are helping to advance integrated approaches to successfully deliver value through well-executed complex programs.
The Table of Contents is detailed and well organized. The content of The Book is presented in four parts:
- Part I: In Search of Integrated Solutions
- Part II: Building Capabilities to Effectively Execute Complex Programs
- Part III: Developing Organizational Competencies in Your Organization
- Part IV: Calls to Action:
  - For Academia: Help Budding Professionals Learn to Adapt
  - For Enterprise: Build the Right Engine for Strategy Implementation
  - For Policymakers: Refocus Oversight and Accountability in the Right Ways
  - For Industry and Professional Societies: Take an Interdisciplinary View
  - For Researchers: Explore Interdisciplinary Systems
The Foreword, Practices, Knowledge, and Innovation, is provided by Larry Prusak. He clarifies the primary challenge that is addressed in this book: How do you successfully bring together two different ways of knowing and doing to accomplish a critical role? He defines “practices” as the vocabularies, work habits, accumulated historical stories, interfaces and entanglements with technology, and our deep understanding concerning the best way to do things. Practices evolve by incorporating new ideas, perspectives, and tools so that they remain relevant. He advises that this book is a wonderful attempt to see what two established and valuable disciplines have to offer to one another, to their customers, and to society.
The Preface, provided by Alan Harding (President of INCOSE) and Mark Langley (President & CEO, Project Management Institute), reports that in 2011, INCOSE and PMI allied to enhance, foster, and enable collaboration between program managers and systems engineers. Leaders in the two organizations believed that the two disciplines had developed silos between them that inhibited collaboration and that an urgent priority is to change mindsets to remove barriers. Partnering with MIT’s Consortium for Engineering Program Excellence (CEPE), INCOSE and PMI conducted a series of studies over three years to explore issues concerning the extent of collaboration between the PM discipline and the SE discipline, in particular, does integration and collaboration demonstrably impact program performance? Also, are alignment, integration, and collaboration embedded in the organizational culture, processes, and systems? The two leaders emphasize that senior executives within corporations, governments, professional associations, academia, and research must also change their mindsets. They must see the connections between strategy, benefits, performance, and capabilities, and work within their organizations to remove gaps and improve performance. They must recognize the value their organizations could gain from even incremental efforts to reduce wasted investments due to poor program execution. They must ensure their organizations learn from examples of success and failure, and utilize that learning to continuously improve their own practices. Most importantly, they must stand with their program managers and chief engineers and lead the change toward a new mindset.
The Acknowledgements reflect that developing The Book was itself a significant collaborative effort that involved many individuals and institutions during the course of the last five years – many perspectives were brought together to create something unique and noteworthy. In the case of this book, it is correct to say that many hands made superior work – this is the message and the experience of this effort.
The Introduction describes the background that led to the collaboration of INCOSE, PMI, and MIT’s CEPE; to creation of The Guide to Lean Enablers for Managing Engineering Programs (Oehman, 2012); and to the creation of The Book. The research basis for the book unfolded through four distinct phases over a period of three years. The initial research results from analysis of the data were informative, but raised more questions than they answered. The initial findings just scratched the surface of what appeared to be an important but largely unaddressed area. A four-phase research program emerged. In Phase I, an invitation to participate in a joint PMI and INCOSE survey in 2012 was sent to approximately 3,000 INCOSE members (systems engineers) and 5,000 PMI members (program managers). While a number of useful insights emerged from this analysis, the connection between integration, unproductive tension, and overall program or organizational performance remained unclear at this stage. The action mechanisms for enabling greater levels of integration were likewise unclear. The survey provided a good starting point to understand high-level issues associated with integration of program management and systems engineering. In order to clarify the mechanisms of integration and the impact of integration on performance, additional information about how integration actually occurred in organizations was needed and led to the Phase II and III studies. Phase II of the research focused on those organizations that experienced little or no unproductive tension between program management and systems engineering. Phase III involved a separate sample of respondents that indicated high levels of unproductive tension in their organizations. This study was inductive, with effort primarily focused on identification of the key factors that drive overall behavior. Analysis of the data produced more formal definitions of integration and unproductive tension. The Phase IV study involved an online survey and sampled 157 participants from around the world and included program managers and systems engineers. The results provided a better understanding of what factors contribute to integration. While much has been learned, research on the integration of program management and systems engineering should be considered at this point in the early stages of theory development and understanding. An Integration Framework was developed that lays out learnings (factors) that seem to provide integration.
Each Chapter has:
- An introduction that places the topic of the chapter in context: how it impacts the integration of program management (PM) and systems engineering (SE).
- Carefully developed figures and tables that provide rich amplification of the text.
- References to other chapters (not surprisingly, the book itself is integrated!).
- Bulleted lists that provide specific takeaways.
- A summary that provides a concise explanation of the importance of the topic of the chapter.
- A list of Discussion Questions that encourage the reader to reflect on his or her own experience and perspective to reinforce learning and to open possibilities for new thinking.
- A list of applicable References – the references are on-topic and provide extensive examples and opportunities for further research and understanding. You will be surprised to learn of the availability of insightful publications both very recent (many of them written to report on research undertaken to answer questions for this book) and not-so-recent but apropos.
- A short list of Additional Resources that serves as icing on the cake of learning opportunities.
An Afterword: Toward An Integrated Future is provided that is an admonition to individual practitioners to reflect on the messages of the book, develop a plan of action, and proceed with actions to create better integration between program management and systems engineering in their own sphere of influence.
The Glossary provides a comprehensive list of usable, useful definitions.
The Index is thorough: one is able to locate topics easily.

The table accompanying this article addresses what is different about an integrated approach from that which is often used today, which we term “Less Successful Approaches”. Many complex programs have been successful and The Book provides examples and case studies concerning them as well as exhaustive research concerning what can be done to further strengthen and improve the practice of systems engineering going forward.

It is our hope that these summaries will stimulate our subscribers to join the movement to begin efforts to transition to an integrated approach. As you will see, it is going to take time and concerted efforts on the part of program managers and systems engineers to implement needed change. Strategy Implementation is defined as the collective organizational effort to execute strategy by investing in the right initiatives to deliver desired business benefits.

The bottom line is that the current situation [today’s program management and systems engineering implementation] is not sustainable. At the top level, the following are some of the things that are needed:

Respect for people.
Organizational culture that values people and their capabilities.
Executive leaders with integrity who foster and expect trust.
Empowerment.
Collaboration.
Requirements management.
Risk management, mitigation, and back up plans.
Processes, methods, tools, techniques, and systems support that are fit for duty.
Ongoing training and people development.
Team competency.
Knowledge.
Alignment and coordination of the extended enterprise.

Systems Engineering News

Tutorial on Data Science

$C:\Users\Ralph\Documents\SyEN 2017\SyEN 54 June 2017\SE News\e890325f-0fb5-43b1-9bc5-162fb63e05c4.jpg$

The San Diego Chapter of INCOSE sponsored a tutorial entitled End-to-End Practices to Gain Business Decision Insights for Mission Objectives on May 13th, 2017 at the University of California San Diego (UCSD) Extension University City Center. The following information summarizes the event:

Lecturer: Dr. James C Meng, UCSD SDSC Senior Fellow

Background: Data science, as a profession and as an academic discipline unto itself, is new, having been born in the first decade of the 21st century (Calvin Andrus 2012). Data science is the study of the generalizable extraction of knowledge from data. While many fail in unleashing data’s potential, few end-to-end practical guides are available for the enterprise leadership to learn what it takes to build business data insights without over-relying on tool vendors. McKinsey Global Institute 2011 assessed that the U.S. needs 1.5 million data managers and executives and 140,000 data scientists over the current decade.

Focus: This tutorial offers a practical step-by-step guide how to achieve business objectives leveraging data science basics. The end-to-end system engineering steps are described starting from organization’s business objectives, business processes, data governance, database management, data integration, and analytics to gain decision-making business intelligence.

Objectives: The purpose of this tutorial is to equip students with an overall understanding to manage their businesses analytics. The objective is not IT skill development, but rather critical thinking for solutions development for students. The focus of this tutorial is to develop students’ understanding of how large organizations gain insights from their own wealth of execution data. Students will develop insights into what, when, and how business insights can be effectively gained from planning and execution data by using the most widely accepted automation tools developed by the industry leaders.

Scope: Data Science incorporates varying elements, including signal processing, mathematics, statistics, probability models, computer programming, engineering analysis, pattern recognition, and learning and cloud computing with the goal of extracting meaning from data for businesses creating Business Insights. This tutorial will not address any of these aspects; instead, we will focus on the end-to-end steps starting from business missions, data standardization, data governance, and data processing to visualize business insights. This four-hour tutorial will comprise the following:

What is Business Data Science? Why Bother? Expectations of Learning
Defining Business Objectives; Linking Business Missions with Performance Data; Business Process and Systems Engineering Requirements
Business Data Integration; Business Data governance
Business Data Standardization and Data Architecture for Interoperability

For more information, send an email to info@sdincose.org

Self-Contained Systems Map the User Journey

The Self-contained System (SCS) approach is an architecture that focuses on a separation of the functionality into many independent systems, making the complete logical system a collaboration of many smaller software systems. This avoids the problem of large monoliths that grow constantly and eventually become unmaintainable. Over the past few years, its benefits have been realized in many mid-sized and large-scale projects. The idea is to break a large system apart into several smaller self-contained systems, or SCSs that follow certain rules (provided at a link in this article).

More information

Systems Thinking: A View from the Trenches

In recent years, systems thinking—a discipline that helps us understand interdependent structures of dynamic systems—has emerged as a powerful force for change in the philanthropic world. Borne out of the realization that significant and sustainable social change requires more than discrete interventions, systems thinking has become de rigueur for any foundation looking to create impact at scale. A 2016 publication on systems grantmaking by Grantmakers for Effective Organizations, as well as recent pieces by FSG, Bridgespan, and New Profit have captured this spirit, and sought to provide guidance and direction for foundations navigating this new world. But what does systems thinking and change look like in the trenches?

More information

Engineering Systems: A Convergence of Disciplines

The Conference on Systems Engineering Research (CSER) held its 15th annual event in March at the Crowne Plaza Hotel in Redondo Beach, Calif. The conference was hosted by USC Viterbi School of Engineering’s Systems Architecting and Engineering (SAE) program, with support provided by the International Council on Systems Engineering (INCOSE). Co-founded by SAE and the Stevens Institute of Technology, CSER offers researchers an opportunity to present and discuss their work in systems engineering, an interdisciplinary field responsible for the development and management of complex systems and projects such as spacecraft design and healthcare systems integration. Currently, this field is undergoing a major transformation driven by the increasing complexity of systems and technical advances. “Systems in the 21^st century is becoming increasingly hyper-connected and consequently more complex. It is becoming apparent that traditional systems engineering methods and tools no longer suffice,” said Azad M. Madni, USC Professor of Astronautics and INCOSE Fellow and Pioneer, who has co-chaired this conference for the last 10 years. “Researchers in government and academia have recognized this trend and are actively engaged in transforming systems engineering to ensure that the new methods will better support systems verification and testing and will scale with system complexity,” he said.

More information

Featured Organizations

Project Management Institute

Editor’s note: The article provided above, “Integrating Program Management and Systems Engineering”, reported on recent research performed by INCOSE, PMI, and MIT’s Consortium for Engineering Program Excellence (CEPE) in a book just released, with the same title as the above article, which concluded that our current approach to program management, project management, and systems engineering is not sustainable. It’s urgent that systems engineers take steps to facilitate integration. One step is becoming more familiar with the vision, sense of purpose, cultural approach, practices, processes, and tools used by program and project managers. PMI is an excellent location to enrich your knowledge in these areas.

The Project Management Institute (PMI) is a worldwide nonprofit professional organization for project management. The PMI provides services including the development of standards, research, education, publication, networking-opportunities in local chapters, hosting conferences and training seminars, and providing accreditation in project management.

PMI has recruited volunteers to create industry standards, such as “A Guide to the Project Management Body of Knowledge“, which has been recognized by the American National Standards Institute (ANSI). In 2012, the International Standards Organization (ISO) adapted the project management processes from the PMBOK Guide 4th edition. PMI is located in Newtown Square, Pennsylvania, United States and has approximately 480,000 members. With the slogan “Making project management indispensable for business results”, PMI’s first credential was the PMP. It has since become a de facto standard certification, along with the PRINCE2 certification, in project management. In 2007 it earned the ANSI/ISO/IEC 17024 accreditation from the International Organization for Standardization (ISO). As of 2016 over 710,000 people held the PMP credential.

PMI later introduced many other credentials and a certification. Credential holders do not have to be members of PMI.

To initially obtain a PMI credential, candidates must first document that they have met required education and experience requirements. They must then pass an examination consisting of multiple choice questions. To maintain most PMI credentials, holders must earn Professional Development Units (PDUs), which can be earned in a variety of ways such as taking classes, attending PMI global congresses, contributing to professional research or writing and publishing papers on the subject. Most credentials must be renewed every three years. These are the certifications and credentials offered by PMI (there is an up-to-date list at the PMI website):

Credentials:

Certified Associate in Project Management (CAPM)
Project Management Professional (PMP)
Program Management Professional (PgMP)
Portfolio Management Professional (PfMP)
PMI Agile Certified Practitioner (PMI-ACP)
PMI Risk Management Professional (PMI-RMP)
PMI Scheduling Professional (PMI-SP)
PMI Professional in Business Analysis (PMI-PBA)

Certification:

PMI Certified OPM3 Professional

The standards PMI develop and publish fall into three main categories:

Foundational Standards
Practice Standards and Frameworks
PMI Standards Extensions

Here is a list of the standards belonging to each category:

Foundational Standards

A Guide to the Project Management Body of Knowledge (PMBOK Guide) – Fifth Edition (2013). Recognized by the American National Standards Institute (ANSI) as American National Standard BSR/PMI 99-001-2013.
The Standard for Program Management—Third Edition (2013). Recognized by ANSI as American National Standard BSR/PMI 08-002-2013.
The Standard for Portfolio Management—Third Edition (2013). Recognized by ANSI as American National Standard BSR/PMI 08-003-2013.
Organizational Project Management Maturity Model (OPM3). Knowledge Foundation—Second Edition (2008). Recognized by ANSI as ANSI/PMI 08-004-2008.

Practice Standards and Frameworks

Practice Standard for Project Risk Management (2009)
Practice Standard for Earned Value Management—Second Edition (2011)
Practice Standard for Project Configuration Management (2007)
Practice Standard for Work Breakdown Structures—Second Edition (2006)
Practice Standard for Scheduling—Second Edition (2011)
Practice Standard for Project Estimating (2010)
Project Manager Competency Development Framework—Second Edition (2007)

PMI Standards Extensions

Construction Extension to the PMBOK Guide—Third Edition (2016)
Government Extension to the PMBOK Guide—Third Edition (2006)
Software Extension to the PMBOK Guide—Fifth Edition (2013)

Combined Standards Glossary

PMI publishes a combined glossary listing acronyms, terms and definitions:

Combined Standards Glossary – Third Edition. Recognized by ANSI as American National Standard PMI-978-1-933890-27-2.

According to PMI, standards are developed by volunteers in an open, consensus-based process including a public exposure draft process that allows the standard draft to be viewed and changes suggested.

More information

INCOSE Agile Systems and Systems Engineering Working Group

The capitalized word Agile is used as a noun by many people: “We do Agile.” In this respect, it refers to software project management values, backed up by some good software development process principles, shared by a family of software development practices. Some people trained or certified in coaching agile software development would like to solve the needs of agile systems engineering with the same core values and principles. When all you know is a hammer, every problem looks like a nail.

The INCOSE Working Group (WG) on Agile Systems and Systems Engineering does not subscribe to this insufficient understanding and misguided belief.

Instead, we are focused on agility as an adjective – an operational property of systems and the systems engineering processes that create them. A property that enables and facilitates effective and sustainable systems and development processes faced with uncertainty and unpredictable changes in their operational environments.

Charter (briefly)

Purpose

Develop a body of knowledge that will inform systems engineering on how to deal with unpredictable, uncertain, and evolving environments.

Goals

Agile systems-engineering and agile-systems engineering fundamentals
Agile acquisition processes
Supplier Quick Reaction Capability (QRC)
System and process design that can respond effectively to the pace of technology and changing user expectations
International engagement

Scope

Fundamentally necessary and sufficient INCOSE-relevant architectural concepts and concept-employment principles that enable any system or process to be agile.

Overview

Architecture and design principles that enable system and process agility were discovered in the 90’s by analyzing the causal DNA of this agility property in hundreds of systems and processes. But architecture and design principles are static enabling concepts. Agility manifests in execution – in the facilitated behavior of dynamic system and process operations.

A major current project of the WG is the discovery of an Agile Systems Engineering Life Cycle Model (ASELCM). It is a discovery, not invention, project – analyzing what works and why in effective process operational dynamics across a wide variety of agile process models.

The general focus of this WG is on education and socialization of the enabling concepts, employment examples of these concepts in application, and discovery of fundamental agility facilitating behaviors – in broadly-applicable systems engineering.

We are a Working Group, with the accent on working. Working manifests as self-motivated collaborative projects that result in published or performance artifacts. We also welcome curious visitors at our biannual workshops at the INCOSE International Workshops and International Symposiums, as well as observers and lurkers among all on the email distribution list.

What Work Has The Group Done?

Five annual INCOSE Webinars on agile System and Process fundamentals.
Wrote INCOSE Handbook V4 section on agile systems engineering.
Conducted fundamental-based tutorials at IS and IW.
Provided papers and panels at INCOSE International Symposiums.
Organized and edited two INSIGHT Theme issues on Agile SE and on Agile Security.
Completed four ASELCM Phase 1 Case Studies.
Confirmed an Agile SE Life Cycle Model Framework and the necessary addition of a Research stage.
Discovered nine fundamental operational principles that appear necessary for sustaining agile SE processes.
Developed the CURVE operating environment requirements framework: Caprice, Uncertainty, Risk, Variation, Evolution.

What Work is the Group Doing?

ASELCM Phase 2, vetting Phase 1 discoveries as fundamentally necessary.
Five WG collaborations in process.
Open Systems Architecture (OSA), agility, and complexity project.
Sixth annual INCOSE webinar in development.
Systems Summit ConOps for Chapter employment.
Systems Summit planning for IS17 and IW18.
INSIGHT Theme issue 2018 Q2 draft essays for review at IW18 – Enabling and Practicing Systems Engineering Agility.
Presentations to various Chapters.

What Work is Planned?

ASELCM project report as INCOSE Product.
Agility-enabling hardware development infrastructures and concepts.
Mixed discipline Agile systems engineering processes.
Quick reaction capability, with accent on enabling capability.
SEBoK contributions.
Supplier-compatible agile-acquisition concept guidance.
Whatever YOU want to do, consistent with our Charter.

How Do They Do It?

Enable and facilitate distributed remote project team collaboration.
Facilitate project team formation and operation.
Conduct two annual workshops at IW and IS that review projects in process, discuss new project interests, and start new projects.
Select project starts that fulfill a need felt by you, by your organization, and by others.

Why Do You Want to Work With Them?

The Group is mission-oriented – focused on employable deliverables that satisfy application needs. The WG provides the opportunity to broaden your understandings through collaborative diversity, and develop actionable knowledge of value to you and your organization. On a personal level, engagement in WG activity is professional development, network enlargement, and new knowledge assimilation. On an organizational level, you bring home actionable and sharable knowledge, broader understandings, and more capability.

How Do You Get Involved?

Email the WG chair to be on the WG distribution list. Attend our IW and IS workshops. Come with a passion to learn and make something happen.

Chair: Rick Dove, Paradigm Shift International, dove@parshift.com.

Co-Chair: Ron Lyells, Retired Honeywell, rlyells@aol.com

Co-Chair: Larri Rosser, Raytheon, larri_rosser@raytheon.com

INCOSE Connect Web Site: https://connect.incose.org/WorkingGroups/ASASE/Pages/Home.aspx

Public Web Site: www.incose.org/ChaptersGroups/WorkingGroups/knowledge/agile-systems-se

Conferences and Meetings

For more information on systems engineering related conferences and meetings, please proceed to our website.

Some Systems Engineering-Relevant Websites

MIT Strategic Engineering

Strategic Engineering Research Group (SERG), Massachusetts Institute of Technology, states that “Engineering is not just about designing systems and products so they work when you first take them “out of the box” and turn them on. That’s when the real game starts. Systems that take only a few months or years to design and implement often operate for many decades, some of them will operate for centuries. It is therefore important to consider the whole life cycle, even if it is very uncertain.”

http://strategic.mit.edu/

INCOSE’s INSIGHT Practitioners Magazine (Volume 20 Issue 1)

INCOSE’s recent issue of its INSIGHT Practitioners Magazine (Volume 20 Issue 1) focuses on Verification and Validation, in collaboration with the March 2017 issue of the ITEA (International Test and Evaluation Association) Journal of Test and Evaluation on the common theme of the engagement of systems engineering with test and evaluation. The issue is available in the INCOSE Connect Library (member login required).

http://www.incose.org/ProductsPublications/periodicals/insight

INCOSE eNote

http://www.incose.org/ProductsPublications/enote

INCOSE’s Systems Engineering Standards

www.incose.org/AboutSE/SEStandards

Systems Engineering Publications

INCOSE Publishes its Systems Engineering Handbook in Chinese

The INCOSE Systems Engineering Handbook Version 4, originally released in 2015 in English only, was released in April 2017 in a dual English/Chinese version, with pages in Chinese and English languages side-by-side. Published by China Machine Press, this version is available via http://www.incose-beijing.com/. The translation was done by Zhang Xinguo (Doctor of Engineering, Doctor of Management, Researcher, doctoral supervisor, and currently Deputy General Manager and CIO of AVIC).

A Guide to Selecting Software Measures and Metrics

$C:\Users\Ralph\Documents\SyEN 2017\SyEN 54 June 2017\Books\Jones_SW Measures.jpg$

Image source

by Capers Jones

Book Description (from the Amazon website):

Going where no book on software measurement and metrics has previously gone, this critique thoroughly examines a number of bad measurement practices, hazardous metrics, and huge gaps and omissions in the software literature that neglect important topics in measurement. The book covers the major gaps and omissions that need to be filled if data about software development is to be useful for comparisons or estimating future projects.

Among the more serious gaps are leaks in reporting about software development efforts that, if not corrected, can distort data and make benchmarks almost useless and possibly even harmful. One of the most common leaks is that of unpaid overtime. Software is a very labor-intensive occupation, and many practitioners work very long hours. However, few companies actually record unpaid overtime. This means that software effort is underreported by around 15%, which is too large a value to ignore. Other sources of leaks include the work of part-time specialists who come and go as needed. There are dozens of these specialists, and their combined effort can top 45% of total software effort on large projects.

The book helps software project managers and developers uncover errors in measurements so they can develop meaningful benchmarks to estimate software development efforts. It examines variations in a number of areas that include:

Programming languages
Development methodology
Software reuse
Functional and nonfunctional requirements
Industry type
Team size and experience

Filled with tables and charts, this book is a starting point for making measurements that reflect current software development practices and realities to arrive at meaningful benchmarks to guide successful software projects.

Editor’s note: Capers Jones has developed data that will be of keen interest to some subscribers. The data provide approximate United States Software Industry Productivity and Quality Levels, circa 2016. This table is copyright 2008-2016 by Capers Jones. All Rights reserved. Published in SyEN with the permission of Capers Jones. The data rank 75 industries according to Best Quality, Good Quality, Average Quality, and Poor Quality. The data represent 827,578 projects and 3,724,100 software personnel.

More information

Engineering Systems: Meeting Human Needs in a Complex Technological World (Reprint Edition)

$C:\Users\Ralph\Documents\SyEN 2017\SyEN 54 June 2017\Books\Meeting Human Needs.jpg$

Image source

by Olivier L. de Weck, Daniel Roos and Christopher L. Magee

Book Description (from the Amazon website):

Engineering, for much of the twentieth century, was mainly about artifacts and inventions. Now, it’s increasingly about complex systems. As the airplane taxis to the gate, you access the Internet and check email with your PDA, linking the communication and transportation systems. At home, you recharge your plug-in hybrid vehicle, linking transportation to the electricity grid. Today’s large-scale, highly complex sociotechnical systems converge, interact, and depend on each other in ways engineers of old could barely have imagined. As scale, scope, and complexity increase, engineers consider technical and social issues together in a highly integrated way as they design flexible, adaptable, robust systems that can be easily modified and reconfigured to satisfy changing requirements and new technological opportunities.

Engineering Systems offers a comprehensive examination of such systems and the associated emerging field of study. Through scholarly discussion, concrete examples, and history, the authors consider the engineer’s changing role, new ways to model and analyze these systems, the impacts on engineering education, and the future challenges of meeting human needs through the technologically enabled systems of today and tomorrow.

More information

The MIT Guide to Science and Engineering Communication (Second Edition)

$C:\Users\Ralph\Pictures\For SyEN\Guide to Eng Communication.jpg$

Image source

by James G. Paradis and Muriel L. Zimmerman

Book Description (from the Amazon website):

This guide covers the basics of scientific and engineering communication, including defining an audience, working with collaborators, searching the literature, organizing and drafting documents, developing graphics, and documenting sources. The documents covered include memos, letters, proposals, progress reports, other types of reports, journal articles, oral presentations, instructions, CVs and resumes. Throughout, the authors provide realistic examples from actual documents and situations. The materials, drawn from the authors’ experience teaching scientific and technical communication, bridge the gap between the university novice and the seasoned professional. In the five years since the first edition was published, communication practices have been transformed by computer technology. Today, most correspondence is transmitted electronically, proposals are submitted online, reports are distributed to clients through intranets, journal articles are written for electronic transmission, and conference presentations are posted on the Web. Every chapter of the book reflects these changes. The second edition also includes a compact Handbook of Style and Usage that provides guidelines for sentence and paragraph structure, punctuation, and usage and presents many examples of strategies for improved style.

More information

The Human Side of Managing Technological Innovation

A Collection of Readings

(Second Edition)

$C:\Users\Ralph\Pictures\For SyEN\The Human Side of Managing Technological Innovation.jpg$

Image source

by Ralph Katz

Book Description (from the Amazon website):

Organizations competing in today’s rapidly changing technological markets are faced with the challenges of “dualism”–operating efficiently in the present while innovating effectively for the future. Managers and leaders within these organizations not only have to focus on current market success and profitability, but they must also introduce the next generation of technical advances, product attributes, or service features that will sustain and even augment their continuing global competitiveness.

The Human Side of Managing Technological Innovation, 2^nd Edition, provides a variety of approaches and perspectives on issues critical to the effective leadership of technical professionals and cross-functional teams throughout the innovation process. Designed for courses within business, engineering, and executive education programs, the book has been updated throughout and features more than twenty articles new to this edition. In the articles, researchers and practitioners present their thoughts and ideas of the complex interplay between the specialized knowledge and skills of creative professionals and the realistic pressures and constraints required by successful business organizations. The text is organized into seven sections that cover such topics as motivating professionals, measuring productivity, organizing and leading cross-functional development teams, enhancing creativity and decision-making, developing human resource capabilities, building and maintaining innovative climates, managing lead users for new product innovation, and using technology as a strategic resource. It can be used in advanced undergraduate or graduate courses as well as in organizational workshops and seminars that focus primarily on how managers, individual professionals, project teams, and functional groups deal with problems and issues related to the management of technology-based innovation. The book can also be used as a complementary text for any course that emphasizes product, process, organizational, or technological innovation.

The Human Side of Managing Technological Innovation, 2^nd Edition, provides a unique collection of articles that increase the sensitivity and understanding of individuals who are managing or influencing innovation and change processes within organizations. It also offers practicing managers and staff professionals new ideas, tools, and insights for problem-solving, organizing, and functioning more effectively.

More information

Presentation for the Knowledge Professions

by Gavan Lintern

Cognitive Systems Design Newsletter (April 2017)

This book is available on Apple iBooks and Amazon Kindle at a price of US$9.99.

For early-career knowledge workers such as scientists, researchers, engineers and healthcare practitioners. In this book, the author explains how to plan and deliver an engaging and informative presentation. He describes what works and, along the way, topple some pervasive myths that will push you in the wrong direction. If you are chronically dissatisfied with your presentations, and especially if you are frustrated that nothing you try works, this book will help you move ahead. If you follow the planning and delivery structure outlined here, you will soon become more comfortable and more satisfied with your presentations and may even begin to enjoy your time in front of an audience. There are many presentation books for business and marketing. This book, Presentations for the Knowledge Professions, fills a niche for those who work in a knowledge-intensive profession where ideas derived from research and design dominate.

Offer: Complimentary Copy

If you are registered on the author’s website, you may request a complimentary copy of his book, Presentations for the Knowledge Professions. You may also email the author if you wish to receive a complimentary copy of the book. You are welcome to let friends and colleagues know that this book is available. Make an inquiry to the author for an email flyer you can send friends and colleagues, or download it here.

The epub can be read in iBooks, however the author is yet to find any epub reader for Windows or Android that reproduces this book well. If you want to test the epub on any windows or android epub apps, you will be given access to the book in both formats.

If you read the book and like it, the author would appreciate any supportive comments you might offer. Dr. Lintern is an Associate of PPI.

Systems Engineering Tools News

Capella by PolarSys

by Alwyn Smit

Principal Consultant & Training Presenter

Project Performance International (PPI)

asmit@ppi-int.com

The last couple of years have seen an explosion of the number of Model-Based Systems Engineering Tools. If you are in the market for a MBSE tool, you indeed have a tough job making a selection. The INCOSE Tools database that used to be on their website is sadly no longer available. We want to work towards providing you with basic information on the tools that are out there.

Firstly, we are keen to see the re-establishment of some sort of tools database that can be populated by contributing tools vendors – the intent is to provide a comparison between the tools that are currently available in the market. More on that in a future issue of SyEN.

Secondly, we will start featuring MBSE Tools in a short article based on information that is publicly available from the tool vendor’s website. That way, we can provide some visibility without unduly promoting one tool of tool vendor above another. The sequence will be as it comes across my desk – no preference implied.

The tool that caught my eye this month is Capella by PolarSys.

From polarsys.org:

“PolarSys is an Eclipse Working Group created by large industry players and by tools providers to collaborate on the creation and support of Open Source tools for the development of embedded systems.”^{^[2]}

“Capella is a model-based engineering solution that has been successfully deployed in a wide variety of industrial contexts. Based on a graphical modeling workbench, it provides rich methodological guidance, high productivity and quality assurance gains for engineers developing systems, software and hardware architectures.”^[3]

The tool implements the Arcadia MBSE method and provides a graphical modelling workbench that makes provision for operational needs analysis, system functional analysis and solution architecture.

Some of the features^[4] include:

An embedded methodology browser
Advanced mechanisms to manage complexity through computed simpliﬁcations and abstractions
Productivity tools including:
- Model-to-model transformations
- Capitalization through patterns
- Libraries of replicable elements
- Layout brushing
- System to subsystem transition, etc.
Native support for viewpoint extensions using Kitalpha (PolarSys solution) and Sirius (Eclipse component)
Ability to extend and/or specialize the core environment to address particular engineering concerns (performance, operating safety, cost, mass, product line, etc.) and carry out multi-criteria analyses of target architectures to ﬁnd the best trade-offs.

You can find more information on this open source tool at: https://www.polarsys.org/solutions/capella

Education and Academia

Drexel University’s Online Master’s Degree in Systems Engineering

The accredited Master’s degree in Systems Engineering prepares students to become effective systems engineers, leaders, managers and future executives. With a systems engineering background, students are able to tackle a wide array of engineering challenges from the entire systems life cycle, including concept development, technology assessment, architecture selection, and proposal development.

More Information

Worldwide Directory of SE and IE Academic Programs

The International Council on Systems Engineering (INCOSE) and the Systems Engineering Research Center (SERC) at Stevens Institute of Technology have developed this directory as a resource for the industrial and systems engineering community; they intend to update it annually.

The information contained in this directory was primarily drawn from university websites. For each university, the directory lists the name and address of that university, the degrees offered by that university, the academic unit that offers those degrees, the head of the academic unit offering those degrees, and a URL where more information can be found.

Institutions that wish to include their programs in this directory, or make an addition or correction to their existing information in the directory, should contact ISEDirectory@stevens.edu; and include the name of the institution, location, URL for the English language page providing program information, and point of contact information.

The Directory can be downloaded here.

Project Management Institute (PMI) Academic Programs & Research

There are many PMI resources and publications available that potentially are useful for systems engineers. The article provided earlier in this issue concerning Integrating Systems Engineering and Program Management reports on extensive research that shows that greater integration of SE and PM is required in order to produce sustained positive change on complex programs and in complex organizations.

For example, PMI is committed to advancing the science and practice of project management by supporting the work of academics through its research and education programs. The Global Accreditation Center for Project Management Education Programs (GAC) is an independent academic accreditation body with policies, procedures, and standards for accrediting project management and related programs at the bachelor’s, master’s and doctoral degree levels.

More information

Employees Graduate from Rigorous Systems Engineering and Systems Integration Programs at Naval Postgraduate School

“The curriculum covered the gamut of systems engineering, and the instructors covered topics applicable to programs at NAVAIR,” Graduate Joan Melendez, fuel systems propulsion and power engineer, Propulsion and Power Engineering department, currently on rotation in Jacksonville, Florida, explained. “This program taught me various methods to approach problems from different angles, and I have even been able to apply these approaches to my daily tasking. This experience provided a holistic background of the roles and responsibilities that are required to become a systems engineer and reinforced my aspirations to become one.” The Naval Postgraduate School (NPS) distance-learning program is a partnership between Naval Air Systems Command (NAVAIR) and NPS in which students complete a rigorous, fast-paced curriculum while continuing to work full-time. In addition to 16 courses, master’s degree candidates complete a capstone project designed to resolve actual engineering problems confronting NAWCAD or NAVAIR. To date, there have been a total of 361 graduates of the MSSE program.

More information

Engineering Students Showcase Their Best Ideas

The California State University, Northridge College of Engineering and Computer Science hosted the eighth annual Senior Design Project Showcase on April 14. The showcase, which filled the Grand Salon and Northridge Center of the University Student Union, featured an automatic wheelchair, a concrete canoe and an electric bicycle, among many other student projects.

More information

University of Kentucky, College of Engineering to Induct Five Alumni into its Hall of Distinction

On April 21, 2017, the University of Kentucky College of Engineering inducted five alumni into its Hall of Distinction. Inducted were: Allen W. Brown, of Plano, Texas; William Todd Johnson, of Fort Wayne, Indiana; Elmer T. Lee, of Frankfort, Kentucky (posthumous induction); Javaid Masoud, of St. Paul, Minnesota; and Mark D. Whitley, of Fort Worth, Texas.

More information

Standards and Guides

Object Management Group Chairs Report on Future Direction of Technology Standards

Chairs of Object Management Group® (OMG®) Task Forces (TFs) and Special Interest Groups (SIGs) reported about technology processes underway at OMG’s quarterly membership meeting, which took place from March 20-24 in Reston, VA, USA. OMG is an international, open membership, not-for-profit technology standards consortium, whose membership represents the end-user, vendor, government agency, university, and research institution communities. Members develop and maintain standards that influence the future direction of technology as well as impact industries including space, government, finance, manufacturing, robotics and healthcare.

More information

Some Definitions to Close On

General Concepts and Approches Related to Systems

System point of view: A conviction that system behaviors are qualitatively different from the behaviors of a system’s components, that system design requires doing more than designing the components, and that special effort is required to understand systems and their behavior over and above that which is required to understand any individual component.

System thinking: Includes holism, and ability to think about the system as a whole; focus, an ability to address the important system-level issues; emergence (see below), recognition that there are latent properties in systems; and trade-offs, judgment, and balance, which enable one to juggle all the various considerations and make a proper choice.

System theories: Theories that attempt to explain the interacting and combining behavior of a system as well as how the interaction of its components contributes to the behavior of the system.

System modeling: Vocabularies, symbols, rules, and representations (behavioral, structural) that make use of the vocabularies, symbols, and rules for the purpose of displaying and predicting the structure and behavior of systems, or which represent in symbolic form or operational ways, one or more aspects of the system under study.

Emergent properties: Properties or behaviors of a system that are discovered (i.e., properties that were there but latent), those that emerge spontaneously over time or space, and those that arise in response to behavior of other systems and environments; in a hierarchical view of systems, emergent properties show up at one level of the hierarchy, but not at lower levels.

Synergy: Mutually advantageous behaviors or properties that exist only because distinct elements are joined or can interact.

Ilities and Related System Issues

Ilities: Requirements of systems, such as flexibility or maintainability, often ending in the suffix « ility » ; properties of systems that are not necessarily part of the fundamental set of functions or constraints and sometimes not in the requirements.

Flexibility: The ability of a system to undergo classes of changes with relative ease. Thus, it involves a change in properties divided by the resources needed to affect the change in properties. The nature of the properties that change and the way such changes can occur is diverse : a system of roads is flexible if it permits a driver to go from one point to another using several paths ; flexibility may indicate the ease of « programming » the system to achieve a variety of functions; flexibility may indicate the ease of changing the system’s requirements with a relatively small increase in complexity (and rework). This last part of the definition can also be called:

Evolvability: The ability of a system to change efficiently as new requirements, needs, and possibilities emerge over time.

Agility: The ability of a system to be both flexibile and undergo change rapidly.

Robustness: The ability of a system to perform under a variety of circumstances; the ability to deliver desired functions in spite of changes in the environment, uses, or internal variations that are either built in or emergent.

Adaptability: The ability of a system to change internally to fit changes in its environment. A flexible system is usually modified from outside the system. An adaptable system may undergo self-modification (e.g. a thermostat controlling the heating of a subsystem).

Scalability: The ability of a system to maintain its performance and function, and retain all its desired properties when its scale is increased greatly without having a corresponding increase in the system’s complexity. An increase in scope (i.e. an increase in the system’s functional capabilities) usually involves an increase in scale, yet scalability does not normally imply ease with increasing the scope of a system without unduly increasing its complexity. Such ease is usually related to the structure of the system’s architecture and its flexibility.

Modularity: The degree to which the components of a system can be designed, made, operated, and changed independently of each other; or, the presence of functionally meaningful repetitive patterns or modules within a larger system.

Extensibility: The degree to which sets of components of a system can be extended to a higher level of abstraction.

Fail-safe: The ability to be guided to a safe state, if the system cannot deliver the full desired function due to failure(s).

Safety: The property of being free from accidents (see below) or unacceptable losses.

Durability: The ability to deliver a specified level of function for a specified length of time.

Sustainability: Maintaining economic growth and viability while meeting concerns for environmental protection, quality of life, and social equity; or, a property of an engineering system having optimal resource preservation and environmental management over time.

Quality: The ability to deliver requirements at a « high » level, as perceived by people relative to other alternatives that deliver the same requirements.

Reliability: The probability that a system or component will satisfy its requirements over a given period of time and under given conditions.

Repairability: The ability to be returned to the original state of function when some function is lost.

Maintainability: The ability of a system to be kept in an appropriate operating condition : the system should also possess the property of repairability.

Source : Originally developed in 2002 for the Engineering Systems Division of the Massachusetts Institute of Technology (MIT). Joel Moses led an MIT Internal Symposium Committee that took responsibility for defining these terms. Since then, the text of the definitions has been modified for use in courses by Moses, Daniel E. Whitney, and Christopher L. Magee. These definitions are included in Version 17. Cited in Oliver L. de Weck, Daniel Roos, and Christopher L. Magee, Engineering Systems: Meeting Human Needs in a Complex Technological World, The MIT Press, First MIT Press paperback edition, 2016, pp. 187—188 and190.

Editor’s Note: See Chapter 4 of Engineering Systems: Meeting Human Needs in a Complex Technological World: Life-cycle Properties of Engineering Systems: the Ilities, for a thorough summary of these complexities, including an explanation of how the Ilities are related.

PPI and cti News

INCOSE Beijing Student Division

INCOSE Beijing Student Division was founded at the Industrial Engineering Department of Tsinghua University on Monday, 24 April, 2017. David Mason, the INCOSE Assistant Director for the Student Division, who is also an ESEP, worked for Lockheed Martin for almost 30 years, and is a CTI Principal Consultant, delivered a speech to the students on system engineering, on how INCOSE Beijing Student Division can grow and what the future could be.

Dr. Zhang Xingu（President of INCOSE Beijing Chapter, Vice General Manager of Aviation Industry Corporation of China), Mr. Guo Baozhu (Academician of International Academy of Astronautics; Retired Deputy Director of China National Space Administration), Dr. Li Lefei (Associate Professor of Tsinghua University, Industrial Engineering Department, and Vice Director of INCOSE Beijing Chapter, Advisor INCOSE Beijing Student Division) also attended the inauguration and gave speeches.

New Addition to the Family

PPI Principal Consultant, David Mason, rushed home after presenting a course in Denver to welcome his second grandson, Michael David Hargrove, born on the 5^th April 2017.

Upcoming Participation in Professional Conferences

PPI will be participating in the following upcoming events.

27th Annual INCOSE International Symposium (IS2017)

July 15 – 20, 2017

Adelaide, Australia

13th INCOSE SA Conference 2017

11 – 13 October 2017

Pretoria, South Africa

PPI and CTI Events

Systems Engineering Public 5-Day Courses

Upcoming locations include: