用語集

【あ】

アーキテクチャ
対象システムの内部構造。システムの基本的な考え方や特性であり、システム要素およびそれらの関係として表現され、システムの設計や発展を支配する原則をなしている。(IPA 成功事例に学ぶシステムズエンジニアリング)

アジャイル
設計から評価までのプロセスを短い期間単位で反復的に行い、具体化していく手法。

エンティティ
モデルを構成する個々の要素。GENESYSでは、モデルを構成する要素、一つ一つをエンティティと称する。


【か】

コンストラクト(構造)、Structure
システム設計のコンポーネント(部品)とそれらの物理的/論理的接続関係。(ISO/IEC2009、1)
システムを構成する要素とそれらの関係。


【さ】

システム
システムについては様々な定義がある。何かの目的を達成するために相互作用するエンティティの集団をシステムという。
次はモデルベースシステムズエンジニアリング入門から抜粋した「システム」の定義。

1. 何かを達成するために一貫性を持って組織化されている相互につながっている一連の構成要素。部分の総和以上のもの。挙動は適応的で、ダイナミックで、目標追求型で、自己保存的なもので、進化的な動きを見せることもある。(Donella)
2. 相互作用、または相互依存で結合・規制されたソースと手順のまとまり(DoDAF)
3. 個々のエンティティだけでは成し得ない結果をもたらすような、異なるエンティティによる構成物や集合体(INCOSE)

部品、相互作用、目的の3つがあるところなら、どこにでも存在する。

システムズエンジニア
システムズエンジニアは、「システムズエンジニアリングをする人」である。さまざまな領域を跨いだ経験があり、専門性があり、コミュニケーション能力が高く、プロジェクトを率いられる、かつシステムを俯瞰できる人が適しているといわれている。

システムズエンジニアリング
システムを作ることに関するエンジニアリング。ここでのシステムは、企画から破棄までに至るプロセスを通したシステムとして考えることが重要である。 対象システムの内側だけではなく、外側とそれらの相互作用を鑑みてて開発を進めること。

システムモデル
システムズエンジニアが作成・使用する、システムに関する記述。システムの全容を表すもの。

システム思考
Peter Sengeによって一般に紹介された定義である。
問題へアプローチするやりかたを、異なる考え方、即ち、システムズの展望というところから行うということ。

1. 明確にすべきシステムを含む1つ、あるいは複数のシステムズを特定する
2. 対象システムを含むシステム(あるいはシステムズ)のふるまいを明確にする
3. 対象システムを含むシステムについて理解した内容を、明確にすべきシステムの役割や機能に分解する

という3段階のプロセス。総合的な思考(アプローチ)。
分析的思考(analytic thinking)とは対照的である。
(Ackoff/Primerより抜粋)

ステークホルダ
システムの内部・外部に関係なく、システムのライフサイクル全体において影響を与えるすべての人・組織を「ステークホルダ(利害関係者)」と称する。
ステークホルダには、エンドユーザ、設計者、生産者、メンテナンス、顧客、オペレータ、廃棄関連者などが含まれる。

ソースドキュメント
要求になりうる基となる文書。
例としては、システム概念定義書、上層部の命令、運用コンセプト(Concept of Operations)、作業記述書、市場分析結果、事業計画、標準規格、トレードスタディレポートなどがある。


【た】

段階的詳細化
従来の各分析ドメイン(構造、振る舞い、要求、V&V)ごとの詳細化ではなく、粒度が粗い段階から各ドメインを行き来しながらレイヤの要求充足度を確認してから次のレイヤに進む、レイヤの粒度を決めたうえで有機的に徐々に詳細化していくアプローチ。

抽象化
共通の特徴でまとめ、一般化すること。⇔ 具体化

ドメイン
特定基準で分けること。
設計作業においては要求、ふるまい、アーキテクチャ、検証と妥当性確認などの分け方や、ハードウェア設計・ソフトウェア設計・メカ設計などの設計する対象を基準に分けることもある。


【は】

バウンダリ
システム開発の範囲。システム境界(バウンダリ)を定義することによって、対象システムと、それに接続するすべての外部エンティティを特定することができる。

ブラックボックス
黒いため内部の構造/動作のことを知らない状態。その状態で外部から見た様子で十分に得られる結果を利用することでできる装置や機構の概念。


【ま】

メタモデル
情報を構造化して定義するテンプレート。モデルをあらゆる方面で活用するために、機械が理解できる構造化が必要である。その構造体を作ることがメタモデルを構築することである。メタモデルは設計する対象により異なるが、GENESYSはシステムズモデルに必須と思われる要素と要素間の関係性のメタモデル(テンプレート)が存在する。

モデル
システムに関する記述が論理的・構造的に表現されているもの。
要求、設計要素、テストケース、設計根拠、それらの相互関係を表す要素で構成される。
システムの目的を実現するように詳細化を試みているときに「もともと何がしたかったのか」を反復的に確認するために重要。

モデル化/モデリング
モデルを作る行為。
システム内外について「論理的に構造化された記述をする」、「記述をデジタル化する」こと。目的を達成するために論理を表・ブロック図・一覧など分析しやすい形にすることをモデリングツールが補助する。


【ら】

ライフサイクル
製造業におけるライフサイクルは企画から破棄まで至る過程を示す。


【アルファベット】

BDD
ブロック定義図(Block Definition Diagram)
従来の物理階層から設計仕様などを加えてブロックの構成を視覚的に表現したもの。

Core
Vitech社開発のシステムズエンジニアリングツール。20年以上、世界各国の数千のプロジェクトで培われた豊富なノウハウのエキスとなるVitech社のオリジナル製品。他の追隨を許さない強力なパフォーマンスと検証済みの歴史のある遺産を誇るCoreは、集中的かつ独立型のシステムズエンジニアリング環境を追求するすべての顧客のサポートを継続的に行っている。

EFFBD
拡張機能フローブロック図(Enhanced Function Flow Block Diagram)
機能に関する入出力、トリガー、リソースを含む構造化されたシステム機能のシーケンスと論理で構成されている振る舞い図の一つ。
システムの機能的アーキテクチャを描写していて、制御、データ、データフローを示す。

FMEA
故障モード影響解析(Failure Mode and Effect Analysis)
設計段階で故障モード(Failure Mode)を考え、使用時に起こる問題を明確にし、可能な限り排除したり、軽減したりする手法。

GENESYS
Vitech社開発の企業向けのシステムズエンジニアリングツール。GENESYSは複雑なシステムに対応するVitech社の豊富なノウハウを反映した強力なシステムズエンジニアリングツールである。モデル中心アプローチを実装したGENESYSは、モデルから設計者が求める情報に自由に活用できるよう、既存環境との親和性を整えた強力かつ完全なMBSE感興を提供する。

MBD
モデルベース開発(Model-based Development)
シミュレーションモデルを用いて設計段階で開発対象の検証を行う開発方式。

MBSE
モデルベースシステムズエンジニアリング(Model-based Systems Engineering)は、モデルを用いたシステムズエンジニアリングを示す。
概念フェーズから始まり、開発まで続くライフサイクルフェーズを通してのシステム要求、設計、分析、検証、および妥当性確認のアクティビティをサポートするモデリングの形式化された思考プロセス。(INCOSE)

Measure of Effectiveness (MoE)
技術的努力により生産された製品に対する購買者の満足度を測定する指標。(IEEE 2005)

STRATA
Vitech社のMBSEアプローチ。
Jim Long, Marge Dyer, Mack Alfordによって開発された。
Strategic Layer(戦略的階層)の略語。

システムズ開発の際、各階層において要求、ふるまい、アーキテクチャ、V&Vの整合性をとり階層を下げていく(抽象度を下げていく)という考え方。

SysML
System Modeling Language。OMGにて定義されたシステムを表現する図的言語。UMLから派生された言語で、9つのダイアグラムを用いてシステムのふるまい、要求、構造、制約条件などが表現できる。

System of Interest (SoI)
関心のある対象システム。
システム境界(バウンダリ)を定義することで特定される。
ライフサイクルを考慮しているシステム。(ISO/IEC/IEEE2015)

System of systems (SoS)
複合、巨大システム。複数のシステムを部品とするシステム。
システムがそれ単体で扱うことができず、構成する複数の要素がさらにそれぞれシステムとして扱えるというもの。

UML
OMGで規定している図的言語。
主にソフトウェア設計に使われる。UMLからSysMLが派生された。

V&V
検証と妥当性の確認。
設計の基となる、要求を満たしているか/正しく設計されたかの確認。
システムライフサイクルのシステムズ開発フェーズの終わりに、顧客は出来上がったシステムの受け入れの是非を決定する必要があり、V&Vは、システム受け入れに関する問いに対する解答の二つの側面である。
どちらの側面も、設計と開発プロセスを通じて考慮する必要がある。

Validation
妥当性確認。
正しいシステムを作り上げているかどうかを調べること。(IPA MBSE導入の手引き)
ステークホルダの要求(目的)を満たしているかの確認。または、その要求を満たす根拠を残すプロセス。

Verification
検証。
システムを正しく作り上げているかどうかを調べること。仕様として明確になった要求が正しいかテストする作業(テストするべきことをテストしたか?)。 (IPA MBSE導入の手引き)

Vitech
アメリカ所在のシステムズエンジニアリングのソフトウェア・ソリューションを提供する会社。2019年に図研グループになった。
Vitech社は20年以上の豊富な経験を活かし、各国の政府機関、民間・公共企業および大学などの多くの複雑なシステムを定義・開発するに必要な革新性を与えるソフトウェア・ソリューションを提供した実績がある。


閉じる

前へ

会社情報
世界のモノづくり企業のパートナーとして、
最適なITソリューションの提供をさらに推進します。