システムエンジニアリング

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

システムエンジニアリング技術は、宇宙船の設計、コンピューターチップの設計、ロボット工学、ソフトウェア統合、橋の建設などの複雑なプロジェクトで使用されます。システムエンジニアリングでは、モデリングとシミュレーション、要件分析、スケジューリングなどの多数のツールを使用して、複雑さを管理します。

システムエンジニアリングは、ライフサイクル全体にわたって複雑なシステムを設計、統合、および管理する方法に焦点を当てた、エンジニアリングおよびエンジニアリング管理の学際的な分野です基本的に、システムエンジニアリングは、システム思考の原則を利用して、この知識体系を整理します。そのような努力の個々の成果である設計されたシステムは、相乗効果で機能して有用な機能を集合的に実行するコンポーネントの組み合わせとして定義できます

大規模または複雑なプロジェクトを処理する場合、要件エンジニアリング、信頼性、ロジスティクス、さまざまなチームの調整、テストと評価、保守性、およびシステムの設計、開発、実装、最終的な廃止措置を成功させるために必要なその他の多くの分野などの問題がより困難になります。システムエンジニアリングは、そのようなプロジェクトの作業プロセス、最適化方法、およびリスク管理ツールを扱います。それは、工業工学プロセスシステム工学機械工学製造工学などの技術的および人間中心の分野と重複しています生産工学制御工学ソフトウェア工学電気工学サイバネティクス航空宇宙工学組織研究土木工学およびプロジェクト管理システムエンジニアリングは、プロジェクトまたはシステムのすべての可能性のある側面が考慮され、全体に統合されることを保証します。

システムエンジニアリングプロセスは、製造プロセスとはまったく異なる発見プロセスです。製造プロセスは、最小限のコストと時間で高品質の出力を実現する反復的な活動に重点を置いています。システムエンジニアリングプロセスは、解決する必要のある実際の問題を発見し、発生する可能性のある最も可能性の高い、または最も影響の大きい障害を特定することから始める必要があります。システムエンジニアリングには、これらの問題の解決策を見つけることが含まれます。

歴史

QFD House of Quality for Enterprise Product Development Processes

システムエンジニアリングという用語は、1940年代のベル研究所にまでさかのぼることができます。[1]システム全体のプロパティを識別して操作する必要性。これは、複雑なエンジニアリングプロジェクトでは、パーツのプロパティの合計とは大きく異なる可能性があり、さまざまな業界、特に米軍向けのシステムを開発する業界に適用する動機を与えました。規律。[2] [3]

システムを改善するために設計の進化に依存することがもはや不可能であり、既存のツールが増大する需要を満たすのに十分でなかったとき、複雑さに直接対処する新しい方法が開発され始めました。[4]システムエンジニアリングの継続的な進化には、新しい方法とモデリング手法の開発と特定が含まれます。これらの方法は、エンジニアリングシステムがより複雑になるにつれて、エンジニアリングシステムの設計と開発管理をよりよく理解するのに役立ちます。USLUMLQFDIDEF 0 など、システムエンジニアリングのコンテキストでよく使用される人気のあるツールは、これらの時代に開発されました。

1990年に、システムエンジニアリングの専門家協会であるNational Council on Systems Engineering(NCOSE)が、多くの米国の企業や組織の代表者によって設立されました。NCOSEは、システムエンジニアリングの実践と教育の改善の必要性に対処するために作成されました。米国外のシステムエンジニアの関与が高まった結果、組織の名前は1995年に国際システム工学評議会(INCOSE)に変更されました。 [5]いくつかの国の学校は、システム工学の大学院プログラムを提供し、継続しています技術者を実践するための教育オプションも利用できます。[6]

コンセプト

いくつかの定義
現代のシステムエンジニアリングの創設者であると一部の人が考えているSimonRamoは、この分野を次のように定義しました。すべての側面とすべての変数を考慮し、社会と技術を結び付けます。」[7]複雑さの克服、2004年。
「成功したシステムの実現を可能にする学際的なアプローチと手段」[8]INCOSEハンドブック、2004年。
「システムエンジニアリングは、システムの設計、作成、運用に対する堅牢なアプローチです。簡単に言えば、このアプローチは、システム目標の特定と定量化、代替システム設計コンセプトの作成、設計トレードのパフォーマンス、選択と実装で構成されます。最良の設計、設計が適切に構築および統合されていることの検証、およびシステムが目標をどの程度満たしているか(または達成しているか)の実装後の評価。」[9]NASAシステムエンジニアリングハンドブック、1995年。
「システム全体、生涯の原則を使用して、効果的なシステムを作成する芸術と科学」または「複雑な問題と問題に対する最適なソリューションシステムを作成する芸術と科学」[10]システム工学教授、元大統領、デレク・ヒッチンズINCOSE(UK)、2007年。
「工学的見地からの概念は、工学科学者、すなわち広い視野を維持する科学ジェネラリストの進化です。方法はチームアプローチの方法です。大規模システムの問題では、科学者とエンジニアのチーム、ジェネラリスト専門家だけでなく、解決策を見つけて物理的に実現するために共同で努力しています...この手法は、システムアプローチまたはチーム開発方法とさまざまに呼ばれています。」[11]ハリー・H・グッド&ロバート・E・マコール、1957年。
「システム工学の手法は、多様で特殊な構造やサブ機能で構成されていても、各システムが統合された全体であることを認識します。さらに、どのシステムにも多くの目的があり、それらの間のバランスはシステムごとに大きく異なる可能性があることを認識します。これらの方法は、加重目標に従ってシステム全体の機能を最適化し、その部品の最大の互換性を実現することを目的としています。」[12]ハロルド・チェスナットによるシステムエンジニアリングツール、1965年。

システムエンジニアリングは、アプローチのみを意味し、最近ではエンジニアリングの分野を意味します。システム工学の教育の目的は、さまざまなアプローチを簡単に形式化することであり、そうすることで、他の工学分野で発生するものと同様の新しい方法と研究の機会を特定します。アプローチとして、システムエンジニアリングは、全体論的で学際的なフレーバーです。

起源と伝統的な範囲

従来のエンジニアリングの範囲には、物理​​システムの概念、設計、開発、製造、および運用が含まれます。システムエンジニアリングは、当初考えられていたように、この範囲に含まれます。この意味での「システム工学」とは、工学概念の構築を指します。

より広い範囲への進化

「システムエンジニア」という用語の使用は、「システム」とエンジニアリングプロセスのより広く、より包括的な概念を包含するように時間とともに進化してきました。この定義の進化は継続的な論争の対象となっており[13]、この用語はより狭い範囲とより広い範囲の両方に適用され続けています。

従来のシステムエンジニアリングは、古典的な意味でのエンジニアリングの一分野と見なされていました。つまり、宇宙船や航空機などの物理システムにのみ適用されていました。最近では、システムエンジニアリングは、特に人間がシステムの不可欠なコンポーネントと見なされたときに、より広い意味を持つように進化しました。たとえば、チェックランドは、「エンジニアリング」は「一般的な意味で読むことができます。会議や政治的合意を設計することができます」と述べることで、システムエンジニアリングのより広い意味を捉えています。[14] :10 

システムエンジニアリングのより広い範囲と一致して、システムエンジニアリング知識体系(SEBoK)[15]は、3つのタイプのシステムエンジニアリングを定義しました。(1)製品システムエンジニアリング(PSE)は、物理システムの設計に焦点を当てた従来のシステムエンジニアリングです。ハードウェアとソフトウェアで構成されています。(2)エンタープライズシステムエンジニアリング(ESE)は、システムとしての企業、つまり組織または組織の組み合わせの見方に関係します。(3)サービスシステムエンジニアリング(SSE)は、サービスシステムのエンジニアリングと関係があります。Checkland [14]は、サービスシステムを別のシステムにサービスを提供するものとして考えられているシステムとして定義しています。ほとんどの土木インフラシステムはサービスシステムです。

ホリスティックビュー

システムエンジニアリングは、開発サイクルの早い段階で顧客のニーズと必要な機能を分析および引き出し、要件を文書化し、完全な問題であるシステムライフサイクルを考慮しながら設計の統合とシステムの検証を進めることに重点を置いています。これには、関係するすべての利害関係者を完全に理解することが含まれますオリバーら。システムエンジニアリングプロセスは次のように分解できると主張する

  • システムエンジニアリング技術プロセスおよび
  • システムエンジニアリング管理プロセス

オリバーのモデル内で、管理プロセスの目標はライフサイクルの技術的取り組みを整理することですが、技術プロセスには、利用可能な情報の評価、有効性の測定定義、行動モデル作成、構造モデルの作成、トレードオフ分析の実行が含まれますシーケンシャルビルド&テストプランを作成します[16]

アプリケーションによっては、業界で使用されているモデルがいくつかありますが、それらはすべて、上記のさまざまな段階間の関係を特定し、フィードバックを組み込むことを目的としています。このようなモデルの例には、ウォーターフォールモデルVEEモデル(Vモデルとも呼ばれます)が含まれます。[17]

学際的分野

システム開発には、多くの場合、さまざまな技術分野からの貢献が必要です。[18]開発作業のシステム(全体論的)ビューを提供することにより、システムエンジニアリングは、すべての技術的貢献者を統一されたチーム作業に成形し、概念から生産、運用、場合によっては終了と廃棄。買収では、全体的な統合規律が貢献を組み合わせ、アイテムのライフサイクル全体をカバーする許容可能なレベルのリスクを維持しながら、コスト、スケジュール、およびパフォーマンスの間のトレードオフのバランスを取ります。[19]

この視点は、システムエンジニアリングコースが他のエンジニアリング部門の教員によって教えられ、学際的な環境を作り出すのに役立つという点で、教育プログラムでしばしば再現されます。[20] [21]

複雑さの管理

システムエンジニアリングの必要性は、システムとプロジェクトの複雑さが増すにつれて生じ、その結果、コンポーネントの摩擦の可能性が飛躍的に高まり、したがって設計の信頼性が低下しました。この文脈で話すとき、複雑さはエンジニアリングシステムだけでなく、データの論理的な人間の組織も含みます。同時に、システムは、サイズの増加、および設計に含まれるデータ、変数、またはフィールドの数の増加により、より複雑になる可能性があります。国際宇宙ステーションはそのようなシステムの一例です。

国際宇宙ステーションは、システムエンジニアリングを必要とする非常に複雑なシステムの例です

よりスマートな制御アルゴリズムの開発、マイクロプロセッサの設計、および環境システムの分析も、システムエンジニアリングの範囲内にあります。システムエンジニアリングは、システムの複雑さをよりよく理解して管理するためのツールと方法の使用を奨励しています。これらのツールのいくつかの例はここで見ることができます:[22]

システムコンポーネントの動作と相互作用が必ずしもすぐに明確に定義または理解されるとは限らないため、エンジニアリングシステムに学際的なアプローチをとることは本質的に複雑です。このようなシステムとサブシステム、およびそれらの間の相互作用を定義して特徴づけることは、システムエンジニアリングの目標の1つです。そうすることで、ユーザー、オペレーター、マーケティング組織からの非公式の要件と技術仕様の間に存在するギャップをうまく埋めることができます。

スコープ

システムエンジニアリング活動の範囲[23]

システムエンジニアリングの背後にある動機を理解する1つの方法は、システムエンジニアリングを、さまざまなシステム内に存在する共通のルールを特定して改善するための方法または実践と見なすことです。[要出典]これを念頭に置いて、システムエンジニアリングの原則–全体論、創発的行動、境界など。–システム思考がすべてのレベルで採用されている場合、複雑であろうとなかろうと、あらゆるシステムに適用できます。[24]防衛および航空宇宙に加えて、多くの情報および技術ベースの企業、ソフトウェア開発会社、および電子通信の分野の産業は、チームの一部としてシステムエンジニアを必要としています。[25]

INCOSEシステムエンジニアリングセンターオブエクセレンス(SECOE)による分析によると、システムエンジニアリングに費やされる最適な作業は、プロジェクト全体の作業の約15〜20%です。[26]同時に、研究によると、システムエンジニアリングは、他の利点の中でも本質的にコストの削減につながることが示されています。[26]しかしながら、最近まで、多種多様な産業を網羅する大規模な定量的調査は行われていませんでした。このような研究は、システムエンジニアリングの有効性を判断し、その利点を定量化するために進行中です。[27] [28]

システムエンジニアリングでは、モデリングとシミュレーションを使用して、システムとシステム内の相互作用に関する仮定または理論を検証することをお勧めします。[29] [30]

安全工学において、起こりうる故障の早期発見を可能にする方法の使用は、設計プロセスに統合されています。同時に、結果が明確に理解されていないプロジェクトの開始時に行われた決定は、システムの寿命の後半で大きな影響を与える可能性があり、これらの問題を調査して重要な決定を行うのは現代のシステムエンジニアの仕事です。システムが最初に考案されてから数年または数十年後にサービスを開始したときに、今日の決定が依然として有効であることを保証する方法はありません。ただし、システムエンジニアリングのプロセスをサポートする手法があります。例としては、ソフトシステム方法論、Jay Wright Forresterシステムダイナミクス手法、統一モデリング言語などがあります。(UML)-エンジニアリングの意思決定プロセスをサポートするために、現在すべてが調査、評価、および開発されています。

教育

システム工学の教育は、通常の工学コースの延長と見なされることが多く[31]、工学の学生は従来の工学分野の1つ(航空宇宙工学土木工学電気工学機械工学など)の基礎的なバックグラウンドが必要であるという業界の姿勢を反映しています。工学製造工学工業工学化学工学)—さらに、システムエンジニアとして効果的な実践的な実社会での経験。システム工学で明示的に学部の大学のプログラムは数が増えていますが、珍しいままであり、そのような資料を含む学位は、インダストリアルエンジニアリングの理学士として最も頻繁に提示されます。通常、プログラム(単独で、または学際的研究と組み合わせて)は、アカデミックトラックとプロフェッショナルトラックの両方で大学院レベルから提供され、MS / MEngまたはPh.Dのいずれかが付与されます。/工学博士号。

INCOSEは、スティーブンス工科大学のシステム工学研究センターと協力して、適切に認定された機関で世界的な学術プログラムの定期的に更新されるディレクトリを維持しています。[6] 2017年の時点で、北米の140以上の大学がリストされており、システムエンジニアリングの400以上の学部および大学院プログラムを提供しています。明確なサブディシプリンとしてのこの分野の広範な制度的承認はごく最近のものです。同じ出版物の2009年版は、そのような学校とプログラムの数をそれぞれわずか80と165と報告しました。

システム工学の教育は、システム中心またはドメイン中心と見なすことができます。

  • システム中心のプログラムは、システムエンジニアリングを別の分野として扱い、ほとんどのコースは、システムエンジニアリングの原則と実践に焦点を当てて教えられています。
  • ドメイン中心のプログラムは、エンジニアリングの別の主要な分野で実行できるオプションとしてシステムエンジニアリングを提供します。

これらのパターンは両方とも、コアエンジニアに必要な深さで学際的なプロジェクトを監督できるシステムエンジニアを教育することを目的としています。[32]

システム工学のトピック

システムエンジニアリングツールは、プロジェクトまたは製品でシステムエンジニアリングを実行するのに役立つ戦略、手順、および手法です。これらのツールの目的は、データベース管理、グラフィカルブラウジング、シミュレーション、推論から、ドキュメントの作成、ニュートラルなインポート/エクスポートなどまでさまざまです。[33]

システム

システム工学の分野では、システムとは何かについて多くの定義があります。以下は、いくつかの信頼できる定義です。

  • ANSI / EIA -632-1999:「最終製品の集合体であり、製品が特定の目的を達成できるようにします。」[34]
  • DAU Systems Engineering Fundamentals:「定められたニーズまたは目的を満たす機能を提供する、人、製品、およびプロセスの統合された複合体」。[35]
  • IEEE Std 1220-1998:「関連し、その動作が顧客/運用上のニーズを満たし、製品のライフサイクルの維持を提供する要素とプロセスのセットまたは配置。」[36]
  • INCOSE Systems Engineering Handbook:「実世界で事前定義された動作を示し、その動作を個別に示さない異種パーツと、コンポーネントおよび/またはサブシステムの統合構成で構成される同種のエンティティ」。[37]
  • INCOSE:「システムとは、さまざまな要素の構成またはコレクションであり、要素だけでは得られない結果を生み出します。要素またはパーツには、人、ハードウェア、ソフトウェア、設備、ポリシー、およびドキュメントが含まれます。つまり、すべてのものが含まれます。システムレベルの結果を生成するために必要です。結果には、システムレベルの品質、プロパティ、特性、機能、動作、およびパフォーマンスが含まれます。システム全体によって追加される価値は、パーツによって独立して提供されるものを超えて、主にパーツ、つまり、それらがどのように相互接続されているか。」[38]
  • ISO / IEC 15288:2008:「1つまたは複数の定められた目的を達成するために編成された相互作用する要素の組み合わせ。」[39]
  • NASAシステムエンジニアリングハンドブック:「(1)ニーズを満たす能力を生み出すために一緒に機能する要素の組み合わせ。要素には、この目的に必要なすべてのハードウェア、ソフトウェア、機器、設備、人員、プロセス、および手順が含まれます。(2 )システムを構成する最終製品(運用機能を実行する)および有効化製品(運用最終製品にライフサイクルサポートサービスを提供する)。」[40]

システムエンジニアリングプロセス

システムエンジニアリングプロセスには、製品を定義するために必要な、製品の製造と展開のためにシステム定義を十分に詳細なシステム設計仕様に変換するために実行する必要のある、すべての創造的、手動、および技術的なアクティビティが含まれます。システムの設計と開発は、それぞれ異なる定義を持つ4つの段階に分けることができます。[41]

  • タスク定義(有益な定義)、
  • 概念段階(基本的な定義)、
  • 設計段階(正式な定義)、および
  • 実装段階(製造定義)。

アプリケーションに応じて、ツールはシステムエンジニアリングプロセスのさまざまな段階で使用されます。[23]

システムエンジニアリングProcess.jpg

モデルの使用

モデルは、システムエンジニアリングにおいて重要かつ多様な役割を果たします。モデルは、次のようないくつかの方法で定義できます。[42]

  • 現実世界に関する特定の質問に答えるために設計された現実の抽象化
  • 実世界のプロセスまたは構造の模倣、アナログ、または表現。また
  • 意思決定者を支援するための概念的、数学的、または物理的なツール。

総合すると、これらの定義は、システム設計の検証に使用される物理工学モデルだけでなく、機能フローブロック図や貿易調査プロセスで使用される数学的(つまり定量的)モデルなどの概略モデルを含むのに十分な広さです。このセクションでは、最後に焦点を当てます。[42]

貿易研究で数学的モデルを使用する主な理由は、システムの有効性、パフォーマンスまたは技術的属性、および既知または推定可能な量のセットからのコストの推定値を提供することです。通常、これらすべての結果変数を提供するには、個別のモデルのコレクションが必要です。数学モデルの中心は、その入力と出力の間の意味のある定量的な関係のセットです。これらの関係は、構成要素の量を合計して合計を求めるのと同じくらい単純な場合もあれば、重力場での宇宙船の軌道を記述する一連の微分方程式のように複雑な場合もあります。理想的には、関係は相関関係だけでなく、因果関係を表します。[42]さらに、システムエンジニアリング活動を成功させるための鍵は、これらのモデルを効率的かつ効果的に管理し、システムをシミュレートするために使用する方法でもあります。ただし、さまざまなドメインでシステムエンジニアリングのモデリングとシミュレーションの問題が繰り返し発生することが多く、「モデリングとシミュレーションベースのシステムエンジニアリング」というタイトルで、異なる科学およびエンジニアリングコミュニティ間でメソッドを相互受精させることを目的とした新しい進歩が見られます。[43]

形式主義とグラフィック表現のモデリング

最初に、システムエンジニアの主な目的が複雑な問題を理解することである場合、システムのグラフィック表現を使用して、システムの機能要件とデータ要件を伝達します。[44]一般的なグラフィック表現には次のものがあります。

グラフィカル表現は、機能、データ、またはインターフェイスを介して、システムのさまざまなサブシステムまたは部分を関連付けます。上記の方法のいずれかまたはそれぞれは、その要件に基づいて業界で使用されます。たとえば、N2チャートは、システム間のインターフェイスが重要な場合に使用できます。設計段階の一部は、システムの構造モデルと動作モデルを作成することです。

要件を理解したら、システムエンジニアが要件を改善し、他のエンジニアと一緒に仕事に最適なテクノロジを決定する必要があります。貿易調査から始まるこの時点で、システムエンジニアリングは、最適なオプションを決定するために加重選択を使用することを推奨しています。決定マトリックス、またはピュー法は一方向です(QFDもう1つ)重要なすべての基準を考慮しながらこの選択を行うことです。次に、トレードス​​タディは設計に通知します。これは、システムのグラフィック表現に再び影響します(要件を変更することなく)。SEプロセスでは、この段階は、実行可能な解決策が見つかるまで実行される反復ステップを表します。意思決定マトリックスは、統計分析、信頼性分析、システムダイナミクス(フィードバック制御)、最適化手法などの手法を使用して入力されることがよくあります。

その他のツール

システムエンジニアリングアプリケーションに使用されるモデリング言語であるSystemsModeling Language(SysML)は、広範囲の複雑なシステムの仕様、分析、設計、検証、および妥当性確認をサポートします。[45]

ライフサイクルモデリング言語(LML)は、システムエンジニアリング用に設計されたオープンスタンダードのモデリング言語であり、概念、使用率、サポート、および廃止の各段階のライフサイクル全体をサポートします。[46]

関連フィールドとサブフィールド

多くの関連分野は、システム工学と密接に関連していると見なすことができます。以下の分野は、別個のエンティティとしてシステムエンジニアリングの開発に貢献しています。

認知システム工学
認知システム工学(CSE)は、人間機械システムまたは社会技術システムの記述と分析に対する特定のアプローチです[47] CSEの3つの主要なテーマは、人間が複雑さに対処する方法、アーティファクトを使用して作業を行う方法、および人間と機械のシステムと社会技術システムを共同認知システムとして説明する方法です。CSEは当初から、認知工学とも呼ばれる、認められた科学分野になりました共同認知システム(JCS)の概念は、複雑な社会技術システムをさまざまな解像度で説明する方法を理解する方法として特に広く使用されるようになりました。CSEでの20年以上の経験は、広範囲にわたって説明されています。[48] [49]
構成管理
システムエンジニアリングと同様に、防衛および航空宇宙産業で実践されている構成管理は、幅広いシステムレベルの実践です。この分野は、システムエンジニアリングのタスクと類似しています。システムエンジニアリングが要件開発、開発アイテムへの割り当てと検証を処理する場合、構成管理は要件キャプチャ、開発アイテムへのトレーサビリティ、および開発アイテムの監査を処理して、システムエンジニアリングおよび/またはテストおよび/またはテストおよび/またはテストおよび/または検証エンジニアリングは、客観的なテストを通じて証明されています。
制御工学
制御工学とその設計および制御システムの実装は、ほぼすべての業界で広く使用されており、システム工学の大きなサブフィールドです。自動車のクルーズコントロールと弾道ミサイルの誘導システムは2つの例です。制御システム理論は、解空間の調査と制御プロセスの分析のための新しい方法の開発を含む応用数学の活発な分野です。
インダストリアル・エンジニアリング
インダストリアルエンジニアリングは、人、お金、知識、情報、機器、エネルギー、材料、プロセスの統合システムの開発、改善、実装、評価に関係するエンジニアリングの一分野です。インダストリアルエンジニアリングは、工学分析と合成の原理と方法、および数学、物理、社会科学を工学分析と設計の原理と方法とともに利用して、そのようなシステムから得られた結果を指定、予測、評価します。
インターフェイスデザイン
インターフェイスの設計とその仕様は、システムの各部分がシステムの他の部分および必要に応じて外部システムと接続および相互運用することを保証することに関係しています。インターフェイスの設計には、システムインターフェイスが、予約済みのワイヤ、プラグスペース、コマンドコード、通信プロトコルのビットなど、機械的、電気的、論理的なインターフェイスを含む新しい機能を受け入れることができるようにすることも含まれます。これは拡張性として知られています。ヒューマンコンピュータインタラクション(HCI)またはヒューマンマシンインターフェイス(HMI)は、インターフェイス設計のもう1つの側面であり、現代のシステムエンジニアリングの重要な側面です。システムエンジニアリングの原則は、ローカルエリアネットワークの通信プロトコルの設計に適用ますおよび広域ネットワーク
メカトロニクス工学
メカトロニクス工学は、システム工学と同様に、動的システムモデリングを使用して有形の構造を表現する学際的な工学分野です。その点で、それはシステムエンジニアリングとほとんど区別がつきませんが、それを際立たせているのは、より大きな一般化と関係ではなく、より小さな詳細に焦点を当てていることです。そのため、両方の分野は、実践の方法論ではなく、プロジェクトの範囲によって区別されます。
オペレーションズリサーチ
オペレーションズリサーチは、システムエンジニアリングをサポートします。オペレーションズリサーチのツールは、システム分析、意思決定、および貿易調査で使用されます。いくつかの学校は、オペレーションズリサーチまたはインダストリアルエンジニアリング部門内でSEコースを教えており、複雑プロジェクトでシステムエンジニアリングが果たす役割に焦点を当てていますオペレーションズリサーチは、簡単に言えば、複数の制約の下でのプロセスの最適化に関係しています。[50]
パフォーマンスエンジニアリング
パフォーマンスエンジニアリングは、システムがその寿命を通じてパフォーマンスに対する顧客の期待に応えることを保証する分野です。パフォーマンスは通常、特定の操作が実行される速度、または単位時間内にそのような操作の数を実行する能力として定義されます。実行するためにキューに入れられた操作が限られたシステム容量によって抑制されると、パフォーマンスが低下する可能性があります。たとえば、パケット交換ネットワークのパフォーマンスは、エンドツーエンドのパケット通過遅延、つまり1時間に交換されるパケットの数によって特徴付けられます。高性能システムの設計では分析モデリングまたはシミュレーションモデリングを使用しますが、高性能実装の提供には徹底的なパフォーマンステストが含まれます。パフォーマンスエンジニアリングは統計に大きく依存していますそのツールとプロセスの待ち行列理論確率論。
プログラム管理とプロジェクト管理
プログラム管理(またはプログラム管理)は、システムエンジニアリングと多くの類似点がありますが、システムエンジニアリングのエンジニアリングよりも幅広い起源を持っています。プロジェクト管理は、プログラム管理とシステムエンジニアリングの両方とも密接に関連しています。
提案工学
プロポーザルエンジニアリングは、費用効果の高いプロポーザル開発システムを設計、構築、運用するための科学的および数学的原理の適用です。基本的に、プロポーザルエンジニアリングは、「システムエンジニアリングプロセス」を使用して、費用効果の高いプロポーザルを作成し、プロポーザルが成功する確率を高めます。
信頼性工学
信頼性工学は、システムがその寿命を通じて信頼性に対する顧客の期待に応えることを保証する分野です。つまり、予想よりも頻繁に失敗することはありません。故障の予測の次に、それは故障の防止と同じくらい重要です。信頼性工学は、システムのすべての側面に適用されます。これは、保守性可用性信頼性、または一部の人が好むRAMS )、およびロジスティクスエンジニアリングと密接に関連しています信頼性エンジニアリングは、故障モードおよび影響分析(FMEA)やハザードフォールトツリー分析などの安全エンジニアリング、およびセキュリティエンジニアリングの重要なコンポーネントです。
危機管理
リスク管理、リスクの評価と対処の実践は、システムエンジニアリングの学際的な部分の1つです。開発、取得、または運用活動において、コスト、スケジュール、およびパフォーマンス機能とのトレードオフにリスクを含めるには、ドメイン全体およびシステムライフサイクルを必要とするトレーサビリティと評価の反復的な複雑な構成管理が含まれます。システム工学の学際的な技術的アプローチ。システムエンジニアリングでは、リスク管理に、全体的な取り組みに統合されたリスク管理の構造化されたプロセスを定義、調整、実装、および監視します。[51]
安全工学
安全工学の技術は、安全上重大な故障の可能性を最小限に抑えるために、複雑なシステムを設計する際に専門家ではないエンジニアによって適用される場合があります。「システム安全工学」機能は、新しい設計における「安全上の危険」を特定するのに役立ち、システムから設計できない(潜在的に)危険な状態の影響を「軽減」する技術を支援する場合があります。
スケジューリング
スケジューリングは、構成管理の下で学際的な懸念を評価する際の実践および項目としてのシステムエンジニアリングサポートツールの1つです。特に、リソース、パフォーマンス機能、およびタスクの期間に対するリスクの直接的な関係、またはタスク間の依存関係とシステムライフサイクル全体の影響は、システムエンジニアリングの懸念事項です。
セキュリティエンジニアリング
セキュリティエンジニアリングは、制御システムの設計、信頼性、安全性、およびシステムエンジニアリングの実践コミュニティを統合する学際的な分野と見なすことができます。これには、システムユーザー、システムターゲット、およびその他(人、オブジェクト、プロセス)の認証などのサブスペシャリティが含まれる場合があります。
ソフトウェア工学
ソフトウェアエンジニアリングは当初から、現代​​のシステムエンジニアリングの実践を形作るのに役立ってきました。大規模なソフトウェア集約型システムの複雑さの処理に使用される技術は、システムエンジニアリングのツール、方法、およびプロセスの形成と再形成に大きな影響を及ぼしました。

も参照してください

参考文献

  1. ^ Schlager、J。(1956年7月)。「システム工学:現代の開発への鍵」。IREトランザクションEM-3(3):64–66。土井10.1109 /IRET-EM.1956.5007383S2CID51635376 _
  2. ^ アーサーD.ホール(1962年)。システム工学の方法論ヴァンノストランドラインホールド。ISBN 978-0-442-03046-9
  3. ^ アンブレロ、スティーブン(2021年4月5日)。「自律型兵器の意味のある人間による制御を理解する上での抽象化のレベルの結合:2層アプローチ」倫理および情報技術土井10.1007 / s10676-021-09588-wISSN1572-8439_ 
  4. ^ アンドリュー・パトリック・セージ(1992)。システム工学ワイリーIEEE。ISBN 978-0-471-53639-0
  5. ^ INCOSE Resp Group(2004年6月11日)。「INCOSEの創世記」2006年7月11日取得
  6. ^ a b INCOSE /アカデミックカウンシル。「SEおよびIEアカデミックプログラムのワールドワイドディレクトリ」2018年12月26日にオリジナルからアーカイブされました2019年2月4日取得
  7. ^ 複雑さの克服:防衛システムの買収に関する教訓、防衛エンジニアリンググループユニバーシティカレッジロンドン2005年。
  8. ^ システムエンジニアリングハンドブック、バージョン2aINCOSE。2004年。
  9. ^ NASAシステムエンジニアリングハンドブックNASA1995年。SP-610S。
  10. ^ 「デレクヒッチンズ」INCOSEUK 2007年6月2日取得
  11. ^ グッド、ハリーH。; ロバートE.マコール(1957)。システム工学:大規模システムの設計入門マグロウヒル。p。8. LCCN56011714_ 
  12. ^ 栗、ハロルド(1965)。システムエンジニアリングツールワイリー。ISBN 978-0-471-15448-8
  13. ^ ドナロードス; ダニエルヘイスティングス(2004年3月)。「工学システム内の分野としての進化するシステム工学の事例」。MITエンジニアリングシステムシンポジウム。CiteSeerX10.1.1.86.7496_  {{cite journal}}引用ジャーナルには|journal=ヘルプ)が必要です
  14. ^ a b チェックランド、ピーター(1999)。システム思考、システム実践ジョン・ワイリー&サンズ。
  15. ^ チェックランド、ピーター(1999)。システム思考、システム実践ジョン・ワイリー&サンズ。ピスター、アーサー、編 2012.システムエンジニアリング知識体系。1.0 ed:スティーブンスインスティテュートと海軍大学院。
  16. ^ オリバー、デビッドW。; Timothy P. Kelliher、James G. Keegan Jr.(1997)モデルとオブジェクトを使用した複雑なシステムのエンジニアリングマグロウヒル。pp。85–94。  _ ISBN 978-0-07-048188-6
  17. ^ 「SEVEE」SEOR、ジョージメイソン大学。2007年10月18日にオリジナルからアーカイブされました2007年5月26日取得
  18. ^ ラモ、サイモン; ロビンK.セントクレア(1998)。システムアプローチ:科学と実践的な常識を組み合わせることによる複雑な問題への新鮮な解決策(PDF)カリフォルニア州アナハイム:KNI、Inc。
  19. ^ 「4。システム工学」(PDF)ディフェンスアクイジションガイドブックディフェンスアクイジション大学2015年8月12日取得
  20. ^ 「コーネル大学のシステム工学プログラム」コーネル大学2007年5月25日取得
  21. ^ 「ESDの教員および教育スタッフ」MITエンジニアリングシステム部門2007年5月25日取得
  22. ^ 「コアコース、システム分析–アーキテクチャ、動作、最適化」コーネル大学2007年5月25日取得
  23. ^ ab システムエンジニアリングの基礎。2017年1月31日、Wayback Machine Defense Acquisition University Press、2001年にアーカイブ
  24. ^ リックアドコック。「システム工学の原理と実践」(PDF)INCOSE、英国。2007年6月15日にオリジナル(PDF)からアーカイブされました2007年6月7日取得
  25. ^ 「システム工学、キャリアの機会および給与情報(1994)」ジョージメイソン大学。2007年9月22日にオリジナルからアーカイブされました2007年6月7日取得
  26. ^ a b 「システムエンジニアリングの価値を理解する」(PDF)2007年6月7日取得
  27. ^ 「測量システム工学の有効性」(PDF)2007年6月15日にオリジナル(PDF)からアーカイブされました2007年6月7日取得
  28. ^ 「コンセンサスによるシステムエンジニアリングコスト見積もり」2007年6月7日取得
  29. ^ Andrew P. Sage、Stephen R. Olson(2001)。「システム工学におけるモデリングとシミュレーション」シミュレーション76(2):90。doi10.1177 / 003754970107600207S2CID3016918_ 2007年10月21日にオリジナルからアーカイブされました2007年6月2日取得 
  30. ^ ECスミスジュニア(1962年)。「システム工学におけるシミュレーション」(PDF)IBMリサーチ。2007年6月4日にオリジナル(PDF)からアーカイブされました2007年6月2日取得 {{cite journal}}引用ジャーナルには|journal=ヘルプ)が必要です
  31. ^ 「システム工学の教育のための教訓的な推薦」(PDF)2007年6月7日取得
  32. ^ 「システム工学認定の展望」(PDF)INCOSE2007年6月15日にオリジナル(PDF)からアーカイブされました2007年6月7日取得
  33. ^ スティーブンジェンキンス。「システムエンジニアリングツールの未来」(PDF)NASA。p。15. 2007年9月26日にオリジナル(PDF)からアーカイブされました2007年6月10日取得
  34. ^ 「システムを設計するためのプロセス」、ANSI / EIA-632-1999、 ANSI / EIA、1999 [1]
  35. ^ 「システム工学の基礎、2001年1月」(PDF)
  36. ^ 「システムエンジニアリングプロセスのアプリケーションと管理の標準-説明」、IEEE Std 1220-1998、 IEEE、1998 [2]
  37. ^ 「システムエンジニアリングハンドブック」、v3.1、 INCOSE、2007 [3]
  38. ^ 「INCOSEフェローのコンセンサス」、 INCOSE、2006年[4]
  39. ^ 「システムおよびソフトウェアエンジニアリング–システムライフサイクルプロセス」、ISO / IEC 15288:2008、 ISO / IEC、2008 [5]
  40. ^ 「NASA​​システムエンジニアリングハンドブック」、リビジョン1、NASA / SP-2007-6105、 NASA、2007 [6]
  41. ^ J. Lienig; H. Bruemmer(2017)。電子システム設計の基礎スプリンガーインターナショナルパブリッシング。pp。6–7。土井10.1007 / 978-3-319-55840-0ISBN 978-3-319-55839-4
  42. ^ a b c NASA(1995)。「システム分析とモデリングの問題」。In:NASA Systems Engineering Handbook 2008年12月17日にWaybackMachineで1995年6月にアーカイブされました。p.85。
  43. ^ ジャンニ、ダニエレ; D'Ambrogio、Andrea; トールク、アンドレアス編 (2014年12月4日)。モデリングおよびシミュレーションベースのシステムエンジニアリングハンドブック(第1版)。CRCプレス。p。513. ISBN 9781466571457
  44. ^ ロング、ジム(2002)。「システムエンジニアリングにおける一般的なグラフィック表現間の関係」(PDF)VitechCorp2017年8月13日にオリジナル(PDF)からアーカイブされました。
  45. ^ 「OMGSysML仕様」(PDF)SysMLオープンソース仕様プロジェクト。p。23 2007年7月3日取得
  46. ^ 「LML仕様」(PDF)LML運営委員会。p。4 2014年6月5日取得
  47. ^ ホルナゲルE.&ウッズDD(1983)。認知システム工学:新しいボトルに入った新しいワイン。International Journal of Man-Machine Studies、18、583–600。
  48. ^ Hollnagel、E。&Woods、DD(2005)共同認知システム:認知システム工学の基礎。テイラーアンドフランシス
  49. ^ Woods、DD&Hollnagel、E。(2006)。共同認知システム:認知システム工学のパターン。テイラーアンドフランシス。
  50. ^ (議論のための記事を参照してください: [7]および「アーカイブされたコピー」2005年9月20日にオリジナルからアーカイブされました。 2005年11月30日に取得されました。{{cite web}}:CS1 maint:タイトルとしてアーカイブされたコピー(リンク)。
  51. ^ 「リスク管理ツールキット」MITRE、SEプロセスオフィス2016年9月8日取得

さらに読む

外部リンク