SEBoKのシステム分析の基本原則

システム分析は、意思決定手法への厳密なアプローチを提供します。 代替案の研究に使用され、モデリングとシミュレーション、コスト分析、技術的リスク分析、パフォーマンス分析が含まれます。



SWEBoKとは異なり、 SEBoKはロシアではあまり一般的ではありません。 少なくとも、政務のための訓練コースを準備しているとき、彼の記事の少なくともいくつかの翻訳を見つけることができませんでした。 それでも、この本は、システム分析を含む大規模システムの開発分野で非常に有用で、これまでのところ断片的な知識を構成しています。



私のコースは特にシステム分析を扱っているので、SEBOKのこの章の翻訳がカットされます...しかし、これらは本の7つのセクションの1つのほんの数章です。



PSこの記事（品質、必要性）およびシステム分析とシステムエンジニアリングへの関心に対するコメントと意見に感謝します。

システム分析の基本原則

システムエンジニアリングの主なタスクの1つは、プロセスの結果として得られた結果を評価することです。 比較、評価はシステム分析の中心的な目的であり、以下に必要な技術とツールを提供します。

• システム要件に基づく比較基準の定義。
• 選択した基準と比較した、各代替ソリューションの提案された特性の評価。
• 各オプションの概要評価とその説明。
• 最適なソリューションを選択します。

分析プロセスと、特定された問題/機会に対する代替ソリューションの選択については、SEBoKのセクション2（ システム設計の章体系的アプローチ）で説明されています。 システム分析の基本原則を定義します。

• システム分析は、システム合成のプロセスで得られた代替ソリューションを評価することで構成される反復プロセスです。
• システム分析は、システムの問題または機能の説明に基づいた評価基準に基づいています。
  
  
  • 基準は、システムの理想的な説明に基づいています。
  • 基準は、すべての可能な幅広いコンテキストで、最終決定においてシステムの必要な動作と特性を考慮に入れる必要があります。
  • 基準には、システムの安全性やセキュリティなど、機能以外の問題を含める必要があります。 （詳細については、 「システムエンジニアリングと特殊設計」の章で説明しています）。
  • 「理想的な」システムは、「厳密ではない」記述をサポートでき、そこから「ファジー」基準を決定できます。 たとえば、利害関係者は、特定の種類の決定、または関連する社会的、政治的または文化的慣習について賛成または反対することを検討する必要があります。
• 比較基準には、少なくとも、利害関係者が容認できるコストと時間の制限を含める必要があります。
• システム分析は、代替ソリューションを分析するための別個の妥協研究メカニズムを提供します。
  
  
  • 妥協の研究は、多くの提案された実行可能なオプションの中で最もバランスのとれた解決策を見つけるための学際的なアプローチです。
  • この研究では、制限と関係を考慮して、評価基準のセット全体を検討します。 「評価基準のシステム」が作成されています。
  • 代替案を比較する場合、客観的基準と主観的基準を同時に処理する必要があります。 全体的な評価（全体的な評価の感度）に対する各基準の影響を判断する際には、特に注意する必要があります。

_{注：「ソフト」/「非厳格」および「厳格」システムの説明は、システムの目標、目的、およびミッションを明確に定義する能力によって区別されます（「ソフト」システムの場合、これは非常に困難です）。}

妥協の研究

注：私たちの文献では、「代替案の分析」または「代替案の評価」という用語がより一般的です。

システムの説明のコンテキストでは、妥協の研究は、システムの各要素とシステムアーキテクチャの各バージョンの特性を比較して、評価される基準に一般的に最適なソリューションを決定することから成ります。 さまざまな特性の分析は、コスト分析、リスク分析、および効率分析のプロセスで実行されます。 システムエンジニアリングの観点から、これら3つのプロセスをより詳細に検討します。



すべての分析方法では、一般的な規則を使用する必要があります。

• 評価基準は、さまざまなソリューションを分類するために使用されます。 それらは相対的または絶対的です。 たとえば、最大単価はルーブル単位、コスト削減率は％、効率向上は％、リスク削減も％です。
• 分析中に適用される評価基準の許容範囲が決定されます（たとえば、考慮する必要のあるコストの種類、許容される技術的リスクなど）。
• 評価尺度は、量的特性を比較するために使用されます。 それらの説明には、上限と下限、およびこれらの制限内で特性が変化する順序（線形、対数など）を含める必要があります。
• 評価スコアは、すべての基準に従って各ソリューションオプションに割り当てられます。 妥協の研究の目的は、各ソリューションオプション（コスト、リスク、有効性）の3つの領域（およびそれらの個別の基準への分解）で定量的な比較を提供することです。 この操作は通常複雑であり、モデルの作成が必要です。
• 特性またはプロパティの最適化により、最も興味深いソリューションの評価が向上します。

意思決定プロセスは厳密な科学ではないため、代替案の研究には限界があります。 次の問題を考慮する必要があります。

• 主観的評価基準-アナリストの個人的な意見。 たとえば、コンポーネントが美しくなければならない場合、「美しい」基準は何ですか？
• 未定義データ。 たとえば、システムのライフサイクル全体のメンテナンスコストを計算するときは、インフレを考慮する必要があります。 システムエンジニアは、今後5年間のインフレをどのように予測できますか？
• 感度分析。 各代替ソリューションに与えられる総合評価は絶対的なものではありません。 したがって、各評価基準の「重み」の小さな変化を考慮した感度分析を実行することをお勧めします。 「重み」の変化が評価自体を大きく変えない場合、評価は信頼できるとみなされます。

トレードオフの徹底的な調査により、結果の許容値が決定されます。

パフォーマンス分析

パフォーマンス分析は、システムまたは問題の使用状況に基づいています。



ソリューションの有効性は、利害関係者の要件を満たすことに基づいて識別されるシステムの基本機能および追加機能の実装に基づいて決定されます。 製品の場合、これは、たとえば、安全性、セキュリティ、信頼性、保守性、使いやすさなど、一般的な非機能的な品質のセットになります。 これらの基準は、多くの場合、関連する技術分野および分野で正確に説明されています。 サービスまたは組織の場合、基準はユーザーのニーズまたは組織の目標の決定により関連している場合があります。 そのようなシステムの典型的な特性には、安定性、柔軟性、開発などが含まれます。



ソリューションの絶対的な効果を評価することに加えて、コストと実装時間の制約も考慮する必要があります。 一般に、システム分析の役割は、特定の反復ごとに割り当てられたコストと時間を考慮に入れて、ある程度の効率を提供できるソリューションを識別することに限定されます。



提案された投資を正当化するレベルの効率を提供できるソリューションがない場合、問題の元の状態に戻す必要があります。 オプションの少なくとも1つが十分な効率を示している場合は、選択を行うことができます。



ソリューションの有効性には、パフォーマンス、ユーザビリティ、信頼性、生産、サービス、サポートなど、いくつかの重要な特性が含まれます（ただし、これらに限定されません）。 これらの各領域の分析では、さまざまな観点から提案されたソリューションを強調しています。



パフォーマンス分析の側面の重要性の分類を確立することが重要です。いわゆる 主要業績評価指標。 有効性分析の主な難点は、有効性を評価する観点から一連の側面を正しくソートして選択することです。 たとえば、製品が単回使用向けに製造されている場合、保守性は適切な基準にはなりません。

コスト分析

コスト分析では、ライフサイクル全体のコストを考慮します。 典型的なコストの基本セットは、特定のプロジェクトとシステムによって異なる場合があります。 コスト構造には、人件費（人件費）と非人件費の両方が含まれる場合があります。

種類	説明と例
開発	設計、ツール（ハードウェアおよびソフトウェア）の開発、プロジェクト管理、テスト、プロトタイピングおよびプロトタイピング、トレーニングなど
製品の製造またはサービスの提供	原材料と供給品、スペアパーツと在庫、作業に必要な資源（水、電気など）、リスク、避難、廃棄物またはスクラップの処理と保管、管理費（税、管理、文書管理、品質管理、清掃） 、制御など）、パッケージングと保管、必要な文書。
販売およびアフターサービス	販売ネットワーク（支店、店舗、サービスセンター、販売業者、情報の取得など）、苦情の処理、保証の提供などの費用
顧客の使用	税金、設置（顧客の場所で）、仕事に必要なリソース（水、燃料など）、財政的リスクなど
備品	輸送と配送
サービス	サービスセンターと旅行、予防、管理、スペアパーツ、保証費用など
削除する	折りたたみ、解体、輸送、廃棄物処理など

費用のコストを決定する方法は、 「計画」セクション（セクション3）で説明されています。

テクニカルリスク分析

リスクは、特定のコスト、スケジュール、および技術的な制約内で目標を達成できない可能性があります。 2つの部分で構成されます。

1. 実装の確率（リスクが正当化され、目標が達成されない可能性）;
2. 実装の影響または結果の程度。

各リスクには、0より大きく1より小さい確率があり、影響の程度は0より大きく、将来のタイミングです。 確率が0の場合、リスクはありません。1の場合、これは事実であり、リスクではありません。 影響度が0の場合、リスクはありません。 その発生の結果はありません（無視できます）。 期限が将来にない場合、これはすでに既成事実です。



あらゆる分野のリスク分析は、次の3つの要因に基づいています。

1. 潜在的な脅威または不要なイベントの存在とそれらの発生の可能性の分析。
2. 特定された脅威の結果の分析と重大度スケールでの分類。
3. 脅威の可能性または許容値にさらされる脅威のレベルを減らします。

技術的リスクは、システムがその要件を満たすのをやめると認識されます。 この理由は、要件にあるか、ソリューション自体にあります。 それらは有効性の欠如として表され、いくつかの理由があるかもしれません：

• 技術的能力の誤った評価。
• システム要素の技術的な準備の再評価。
• 機器、コンポーネントまたはソフトウェアの劣化または陳腐化による事故、
• サプライヤーへの依存（互換性のない部品、配送遅延など）;
• 人的要因（不十分なトレーニング、不適切な設定、不十分なエラー処理、不適切な手順、悪意）

管理方法は同じですが、技術的リスクとプロジェクトリスクを混在させないでください。 技術的リスクはプロジェクトリスクにつながる可能性があるという事実にもかかわらず、それらはシステムの開発プロセスではなくシステム自体に焦点を当てています（セクション3の「リスク管理」の章で詳しく説明）。

プロセスアプローチ

アプローチの目的と原則

システム分析プロセスは次の目的で使用されます。

1. 意思決定への厳密なアプローチを確保し、要件の競合を解決し、代替の物理的ソリューション（個々の要素とアーキテクチャ全体）を評価します。
2. 要件の満足度の決定。
3. リスク管理サポート。
4. 決定は、コスト、タイムライン、生産性、およびシステムの設計または再設計に対するリスクの影響を計算した後にのみ行われることの確認。

このプロセスは、意思決定分析プロセス（NASA、2007）とも呼ばれ、技術的な問題、代替ソリューション、および意思決定の不確実性を評価するために使用されました。 詳細については、「意思決定管理」の章（セクション3）を参照してください。

システム分析は、他のシステム記述プロセスをサポートします。

• 利害関係者の要件を記述し、システム要件を記述するプロセスでは、システム分析を使用して要件間の矛盾を解決します。 特にコスト、技術的リスク、効率に関連しています。 高いリスクにさらされるか、重要なアーキテクチャの変更が必要なシステム要件についてさらに説明します。
• 論理的および物理的アーキテクチャの開発プロセスでは、システム分析を使用して、アーキテクチャオプションの特性を評価またはプロパティを開発し、コスト、技術的リスク、効率の観点から最も効果的なオプションの選択を正当化します。

他のシステム記述プロセスと同様に、システム分析は繰り返し行われます。 各操作は数回実行され、各ステップで分析の精度が向上します。

プロセスタスク

このプロセスの主なアクティビティとタスクは次のとおりです。

• 代替案を検討するための計画：
  
  
  • 分析の代替案の数、使用する方法と手順、予想される結果（行動シナリオ、物理アーキテクチャ、システム要素などから選択するオブジェクトの例）、および正当化の決定。
  • モデル、技術データ（システム要件、システムプロパティの説明）、スタッフの資格、選択した手順の可用性に応じた分析スケジュールの作成。
  
  
  
• モデル選択基準の定義：
  
  
  • 非機能要件（パフォーマンス、動作条件、制限など）および/またはプロパティの説明からの評価基準の選択。
  • ソートおよび整理基準。
  • 各評価基準の比較スケールを定義し、他の基準と比較した重要度レベルに従って各基準の重みを決定します。
• 決定オプション、関連するモデルおよびデータの識別。
• 以前に定義された方法と手順を使用したオプションの評価：
  
  
  • コスト分析、技術的リスク分析、効率分析を実行し、すべての代替案を各評価基準のスケールに配置します。
  • 共通の評価尺度ですべての選択肢を評価します。
• 開始プロセスに結果を提供する：評価基準、評価の選択、比較スケール、すべてのオプションの評価結果、および正当化が可能な推奨事項。

アーティファクトとプロセスの用語

プロセスの一部として、次のような成果物：

• 選択基準のモデル（リスト、評価尺度、重量）;
• コスト、リスク、効率の分析に関するレポート。
• 選択の根拠を報告します。

このプロセスでは、以下の表にリストされている用語を使用します。

期間	説明
評価基準	システム分析のコンテキストでは、評価基準は、システムの要素、物理アーキテクチャ、機能シナリオ、および比較可能な他の要素を比較するために使用される特性です。 含まれるもの：識別子、名前、説明、重量。
評価の選択	システム要素、物理アーキテクチャ、または使用シナリオの選択を説明する評価スコアに基づいてシステム要素を管理します。
グレードポイント（グレード）	評価スコアは、一連の評価基準を使用して、システムの要素、物理アーキテクチャ、および機能シナリオによって取得されます。 含まれるもの：識別子、名前、説明、値。
費用	システム要素などの値に関連付けられている選択した通貨の値 含まれるもの：識別子、名前、説明、金額、コストの種類（開発、生産、使用、保守、廃棄）、評価方法、有効期間。
リスク	発生し、システムの目標またはその個々の特性（技術的リスク）に影響を与える可能性のあるイベント。 含まれるもの：識別子、名前、説明、ステータス。

システム分析検証

検証結果を取得するには、次のポイントが満たされていることを確認する必要があります。

• システムの使用状況におけるモデルとデータの対応。
• システムの使用状況に関連する評価基準の遵守。
• シミュレーションおよび計算結果の再現性。
• 比較スケールの十分なレベルの精度。
• 評価の信頼;
• 評価基準の重みに対する取得ポイントの十分な感度レベル。

モデルの使用の原則

• 一般的なモデルの使用。 システム分析のコンテキストでは、さまざまなタイプのモデルを使用できます。
  
  
  • 物理モデルは、物理現象を実験できるスケールモデルです。 各分野に固有; 例：プロトタイプ、テストベンチ、プロトタイプ、振動テーブル、減圧チャンバー、空気トンネルなど
  • 表現モデルは、主にシステムの動作をモデル化するために使用されます。 たとえば、状態図など。
  • 分析モデルは、推定値を確立するために使用されます。 方程式または図を使用して、システムの実際の動作を説明します。 それらは、非常に単純（要素の追加）または信じられないほど複雑（いくつかの変数を含む確率分布）のいずれかです。
  
  
  
• 必要なモデルを使用します。 プロジェクトの各段階で、適切なモデルを使用する必要があります。
  
  
  • プロジェクトの開始時には、単純なツールを使用して、多くのコストと労力をかけずに大まかな近似値を取得します。 このような近似は、非現実的なソリューションをすぐに判断するのに十分です。
  • プロジェクトが進行するにつれて、データの精度を高めて、まだ競合するオプションを比較する必要があります。 プロジェクトの高度な技術革新により、作業はより困難になります。
  • システムエンジニアだけで複雑なシステムをシミュレートすることはできません;このため、関連分野の専門家が彼を助けます。
  
  
  
• 主題の専門家による検査：評価基準の値が客観的かつ正確に確立できない場合。 試験は4段階で実施されます。
  
  
  1. 問題に関する適格な意見を得るための回答者の選択。
  2. 質問書案の作成。 正確な質問を含むアンケートは評価しやすいですが、あまりにも閉じすぎると、重要なポイントを失うリスクがあります。
  3. より正確な意見を得るために問題の詳細な議論を行うことを含む、質問事項に関する専門家とのインタビューの実施。
  4. 評価基準または決定オプションの分類に関する合意に達するまでレビューを比較する、複数の異なる人々との結果の分析。
  
  
  
  
  システム分析のフレームワークで最も一般的に使用される分析モデルを表に示します。
  
  

  モデルタイプ	説明
  確定的（定義済み）モデル	決定論は、確率論から独立したモデルです。 このカテゴリには、統計に基づくモデルが含まれます。 原則は、大量のデータと以前のプロジェクトの結果に基づいてモデルを作成することです。 それらは、技術が既に知られているシステムコンポーネントにのみ適用できます。 「類推による」モデルも以前のプロジェクトを使用します。 調査中の要素は、既知の特性を持つ既存の要素と比較されます。 その後、これらの特性は専門家の経験に基づいて洗練されます。 学習曲線により、パフォーマンスまたはテクノロジーの変化を予測できます。 一例：「生産されるモジュールの数が倍になるたびに、このモジュールのコストは一定の一定の割合で削減されます。」
  確率的（確率的）モデル	モデルにランダム変数が含まれている場合、つまり いくつかの確率的特性によってのみ決定されるモデルは、確率的（確率的、ランダム）と呼ばれます。 この場合、モデルを検討するときに得られる結果はすべて確率的性質であり、それに応じて解釈する必要があります。 確率理論により、多くのイベントの結果として可能な解決策を分類できます。 これらのモデルは、可能なオプションの単純な組み合わせで、限られた数のイベントに適用できます。
  多基準モデル	10を超える基準がある場合は、多基準モデルを使用することをお勧めします。 これらは、次のアクションの結果として取得されます。 基準の階層を構築します。 ツリーの各ブランチを同じ基準の基準と比較した「重み」で各基準に関連付けます。 各ブランチの基準の各「シート」の重みは、すべてのブランチの重みを乗算して計算されます。 基準リーフに従って各代替ソリューションを評価し、グレードを要約し、互いに比較します。 コンピューターを使用して、感度分析を実施して正確な結果を得ることができます。

  
  
  
  
  

  実用的な推奨事項

  
  
  システム分析の主な「落とし穴」と成功事例については、以下の2つのセクションで説明します。
  
  

  落とし穴

  
  
  

  落とし穴	説明
  分析モデリングは意思決定ツールではありません	分析モデルは、分析されたデータから分析結果を提供します。 それは援助として見られるべきですが、意思決定ツールとしてではありません。
  システムのモデルと分解レベル	このモデルは、システム分解のn番目のレベルにうまく適合させることができ、子レベルのデータを使用するより高いレベルのモデルとは互換性がありません。 システムエンジニアがさまざまなレベルでモデルの一貫性を確保することが重要です。
  最適化は、最適化された要素の合計ではありません	調査中のシステムの一般的な最適化は、システムの各部分の最適化の合計ではありません。

  
  
  

  実績のあるテクニック

  
  
  

  方法論	説明
  手術野にとどまる	モデルは、システムのすべての動作と反応を表示することはできません。変数の狭いセットを使用して、限られたスペースで動作します。 モデルを使用する場合、入力データとパラメーターが操作フィールドの一部であることを常に確認する必要があります。 そうしないと、誤った結果が生じるリスクが高くなります。
  モデルを開発する	モデルは、プロジェクト全体で開発する必要があります。パラメーター設定の変更、新しいデータの入力（評価基準、実行機能、要件などの変更）、および以前のツールが機能の限界に達した場合の新しいツールの使用。
  いくつかのタイプのモデルを使用します。	結果を比較し、システムの他の側面を考慮するために、いくつかの異なるタイプのモデルを同時に使用することをお勧めします。
  コンテキスト要素の一貫性を維持する	シミュレーション結果は、常にシミュレーションのコンテキスト内で取得されます：使用されるツール、仮定、入力されたパラメーターとデータ、および出力値の散布。