A thorough explanation of the fundamentals of systems engineering, including verification and validation.

Last time, we discussed the systems that form the foundation of systems engineering.

I want to read it together

What is a system? – Understanding the fundamentals of "systems thinking" through abstraction and MECE (Mutually Exclusive, Collectively Exhaustive) Last time, under the title "Explanation of the Scope and Implementation Conditions of Systems Engineering: SE is a Methodology, Not an Answer," I explained the preface and introduction of the NASA SE Handbook...

To summarize the key points of the system, there are three main points:

This article discusses the systems that form the foundation of systems engineering, so if you're interested, please take a look.

Now, let's finally get down to business and discuss the fundamentals of systems engineering (original title: 2.0 Fundamentals of systems engineering).

We will carefully explain the definition and basic concepts of systems engineering, as these form the foundation of systems engineering.

From here on, I will abbreviate "Systems Engineering" to "SE" because writing it out accurately would be too long. However, please note that I will not abbreviate it in important sections.

Basic SE (Systems Engineer)

At NASA, "systems engineering" is defined as a systematic, multidisciplinary approach encompassing the design, implementation, technical management, operation, and retirement (or disposal) of systems.

Definition of System and SE

A system refers to a combination of multiple elements (subsystems) that work together to produce the capabilities required to meet specific needs.
*System capability includes not only the output, but also the overall quality, nature, characteristics, functions, dynamic behavior, and performance of the system.

Therefore, when making technical decisions about a system, it is extremely important to look at the big picture as well as the individual elements.

Specifically, it's a method for achieving various requirements—in terms of functionality, physical aspects, and operational aspects—over the entire system lifecycle, within various constraints such as cost and schedule. In other words, it can be described as a methodology for reducing the system's lifecycle cost.

To put it another way, SE is the very essence of logical thinking, which involves considering multiple individual elements, their connections, and the whole picture simultaneously.

Please refer to the previous post for a detailed explanation of the system.

I want to read it together

What is a system? – Understanding the fundamentals of "systems thinking" through abstraction and MECE (Mutually Exclusive, Collectively Exhaustive) Last time, under the title "Explanation of the Scope and Implementation Conditions of Systems Engineering: SE is a Methodology, Not an Answer," I explained the preface and introduction of the NASA SE Handbook...

SE is a fusion of technology (Art) and science (Science).

For systems engineers, it is both an art and a science to develop operational systems that meet all requirements while working within conflicting constraints.
*Logical thinking is science.

The technical (Art) aspect of this logical thinking for system engineers lies in "knowing when and where to investigate" in order to pursue system balance and verify its validity.

Individuals with these skills are often called system engineers, and may hold other titles such as lead system engineer, technical manager, or chief engineer, but this book will use the term system engineer.

The role of a systems engineer

The precise roles and responsibilities of a systems engineer vary depending on the size and complexity of the project, as well as the phase of its lifecycle.

Regardless of the size of the project or who is responsible for the SE (Systems Engineer) functions, the SE functions must be reliably executed.

The actual assignment of roles and responsibilities for systems engineers may vary depending on the size of the project and the organizational structure, but ultimately, systems engineers must have the responsibility and role to evolve concepts into actual products.

Systems engineers fulfill the above responsibilities by assuming the following roles:

To fulfill the responsibilities and roles up to this point, the systems engineer will proactively perform the following tasks:

Based on this task, the systems engineer is primarily responsible for leading technical planning activities and documenting technical information.

To summarize what has been discussed so far, systems engineering is a process of trade-offs and compromises, and it involves using a broad, system-wide perspective rather than a viewpoint from a single specialized field.

In other words, systems engineering is about seeing the big picture, and the following two things must be done reliably.

It is extremely important for systems engineers to constantly ask themselves these two questions while performing their tasks.

The role of SEs in project management

Project management has three main objectives.

SEs are strongly related to the technical aspects of this; while project managers (PMs) are responsible for delivering within budget and deadlines, system engineers are responsible for technical success (performance, quality, safety, etc.).
*In Japan, project leaders often handle both SE and PM roles, but organizations like NASA and those that utilize SEs clearly separate these roles.

The roles of these two parties overlap considerably, and at NASA, the SE (Engineering) and PP&C (Project Planning & Management: Business & Budget) teams work together to support projects.

Explanation of the interconnection, verification, and validation of each element of the system.

This concludes our brief overview of the NASA Systems Engineering Handbook. From here on, I will focus on explaining the points that I consider important from the text.　

The capabilities of a system are created by the relationships and interconnections between its elements.

Let's start by looking at the original text.

Let's understand this using a concrete example: a car.

First, let's consider the main components of a car and their respective functions (this is just a simple example).

Each individual component cannot possibly constitute a car.

In any case, there are no components that seem to be of any use on their own.

Here, we consider the relationships between each component and connect them correctly (which is actually quite complex).

As can be seen from the diagram, each component, individually, is nothing more than a strange ornament, but when properly connected to one another, it becomes a car that a person can ride in and move freely.

This is SE'sBeyond the ability of individual elements to function independently, the capabilities added to the system as a whole are primarily generated by the relationships between elements, that is, how they are interconnected and interact with each other.This is a simplified example of "[...]".

このInterconnection and interaction are called flow, and the form of that flow is called interface.called.
*The Japanese translation of FLOW is "flow," and the Japanese translation of INTERFACE is "mesh," "interface," or "joint surface."

To elaborate further, I've stated that for software engineers, it's extremely important to see the big picture.

As shown in the example above, having a perspective that allows you to see the big picture enables you to check the relationships between the elements, resulting in a correct design from an SE's perspective.

The example is extremely simplified and may seem obvious to everyone, but in actual automobile development, where components number over 3, this is a very important perspective.

Furthermore, this approach can be applied not only to automobiles, but also to a wide range of products, from large-scale products such as rockets, airplanes, and power plants, to everyday items like smartphones, personal computers, and electric-assist bicycles.

As the next example, let's shift our perspective from products to organizations and look at the Japanese government.

Similar to how we view automobiles, we consider each government ministry as a separate component, and we will examine several ministries in this way.

Each government ministry, naturally, specializes in a single function.

I don't think that if each individual pursues their own work independently, it will result in a country where citizens can live a decent life.

Here, we consider the relationships between each constituent ministry and connect them correctly (this is merely an example imagined by the author).

I believe that a properly functioning government would result from reliable interconnections between government ministries and agencies (this is my speculation).
*In reality, it is far more complex and bizarre than the diagram suggests. The exchange of information and personnel between government ministries and agencies is based on the author's wishful thinking and is not actually known.

This is how SEs thinkBeyond the ability of individual elements to function independently, the capabilities added to the system as a whole are primarily generated by the relationships between elements, that is, how they are interconnected.This is a broad concept that can be applied not only to projects and products, but also to large organizations and projects like governments.
*This is also an area where large organizations and projects, such as the government, can truly shine.

Furthermore, this methodology demonstrates that if SE (Systems Engineering) is implemented correctly, even large organizations and projects like the government can develop the right policies, as described below.

The difference between verification and validity

This section will explain two important terms that are used casually several times throughout the text: verification and validity. These two terms are fundamental to software engineering, so we will explain them in particular detail.

First, let's look at the meanings of the terms from organizations like the SE academic societies, INCOSE and JCOSE. The English terms are also important, so please remember them.

This is a difficult text that is both understandable and incomprehensible at the same time. Since both INCOSE and JCOSE are like academic societies, it's perhaps unavoidable that they prioritize accuracy and comprehensiveness over clarity.

From here on, I will explain it in my own way.

What is verification?

Verification is a concept that is very easy for Japanese people to understand, and in my own words, it is the concept of "What was the actual value compared to the target value?"

Let's look at some specific examples to align our understanding.

As you can see from the specific examples, in each case of verification, the verification content and methods are specific, focusing on "how did it compare to the target value?". In particular, a major characteristic of verification is that it is determined quantitatively by numbers.

The key point of this verification is easiest to understand if you consider it as, "How do the actual values ​​compare to the target?"

This verification process is probably easy to understand for most people, as they encounter it frequently in their daily lives and work.

What is validity?

Validation is very difficult to explain, but in short, it's the concept of "whether the set goals align with the objectives of users or other stakeholders."

Let's use specific examples to align our understanding of this validity.

As the specific examples show, validity differs significantly from verification and becomes much more complex.

The most distinctive feature is that validity is determined comprehensively and qualitatively, and cannot be uniquely determined by numerical values ​​alone.

It's easiest to understand this validation process if you think of it as ensuring "consistency between purpose and objectives."
*The objective is largely driven by external factors such as users and customers, while the goal is often determined by internal factors. In other words, it can be seen as the alignment of external and internal vectors.

Furthermore, although it lacks academic accuracy and logic, I think it's safe to assume that in Japanese, phrases like "Is this even correct in the first place?" or similar fundamental questions are, with a probability of over 95%, intended as validation.
*This is just my personal opinion, but don't you think that fundamental questions often don't have an immediate answer? I think it's perfectly fair to consider this a validation question.

Verification and validation

We will use concrete examples to illustrate the differences between verification and validation.

Verification and validation are concepts and tasks that frequently appear in SE work, including the explanation given here, so it's important to have a solid understanding of them.

Furthermore, the meaning of "knowing when and where to investigate" in the context of the fundamentals of SE (Systems Engineering) can be said to be "when and where to perform verification and validation."

Furthermore, I believe that verification and validation are essentially what SE (Systems Engineering) is all about.

The V-process, which has been popular for about the last ten years, can also be described as a process of verification and validation (I will explain this in more detail next time).

Summary ~Fundamentals of SE, Interconnection of System Elements, Verification, and Validation~

Let's summarize what we've covered today.

That's it.

Although I haven't touched on this much in previous articles, in Japan, I believe that "systems engineers are responsible for technical success," and that both project managers (PMs) and system engineers (SEs) have traditionally taken on the roles of project leaders.
*It seems that the roles of PM and SE are not well understood in Japan.

In my personal opinion, one of the main reasons why Japan is not quite leading the world in today's increasingly complex society and products is that the project leader system, which essentially combines the roles of project manager and systems engineer, is not adequately suited to dealing with this complexity.

While new challenges may be difficult, appointing someone to manage projects with a focus on the technical aspects, such as a systems engineer, could be a major catalyst for breaking through the current situation (it's recommended to appoint this role on a project-by-project basis, separate from the typical technical manager role).

Personally, I only have experience in automotive development, but even considering the increasing complexity of today's automobiles, I think it's virtually impossible for one person to manage an entire project while simultaneously fulfilling the roles of both project manager and systems engineer.

In the next session, the first half will cover the V process, and the second half will cover systems engineering processes and SE engines (including iterative and recursive ones).

I want to read it together

A thorough explanation of the SE engine and V-process: The V-model derived from decomposition and integration, V&V, and the principles of iteration and recursion. In the previous article, we discussed the fundamental concepts of systems engineering: verification and validation. In particular, we focused on verification and validation…

• NASA Systems Engineering Handbook Rev2
  This book is the basis for this explanation. It is in the public domain, so you can get it for free.

• Systems Engineering Handbook, Keio University Press, supervised by Hidekazu Nishimura
  We'll be working hard to supervise the NASA handbook on this site, but it will take time, so if you want to learn the whole thing right away, I recommend this book. I own a copy myself.

Systems Engineering Handbook, 5th Edition

created by Rinker

Keio University Press

• Amazon
• Rakuten
• Yahoo Shopping