<プロジェクト名>
システム・アーキテクチャー説明書
バージョン <1.0>
[メモ: 次のテンプレートは、Rational Unified Process で使用することを目的に提供されたものです。大括弧で囲まれた青色のテキスト (style=InfoBlue) は、 作成者に対する説明用ですので、本文書を公開する前に削除してください。 このスタイルの後に入力した段落は自動的に通常の形式 (style=Body Text) に設定されます。]
改訂履歴
日付 |
バージョン |
説明 |
作成者 |
<yy/mm/dd> |
<x.x> |
<詳細> |
<名前> |
目次
システム・アーキテクチャー説明書
[システム・アーキテクチャー説明書の「はじめに」にはシステム・アーキテクチャー説明書の概要を記述します。]
本文書では、さまざまなアーキテクチャー上の視点からいくつかのシステムの特徴を記述し、システムのアーキテクチャーの総合的な概要を記載します。システムに関係する重大な アーキテクチャー上の影響事項、決定事項を把握し、明らかにすることを目的としています。
[このセクションでは、プロジェクトの全資料におけるシステム・アーキテクチャー説明書の目的を記述し、この説明書の構成について簡単に取り上げています。この文書の対象読者を明確に定義し、この文書の想定される利用方法を記載します。]
[システム・アーキテクチャー説明書の適用範囲、関連対象を簡潔に記します。]
[ここには、本文書が適用されるシステムの識別番号、名前、バージョンなどについて記載します。]
[ここには、本文書が適用されるシステムの目的および一般的な性質について記載します。何らかの形で既存のシステムがある場合、または先行版のシステムがある場合には、システムの履歴およびその運用についても簡単に説明します。取得者、利用者、運用機関などの主要な利害関係者を特定します。]
[ここではシステム・アーキテクチャー説明書を正しく解釈する上で必要となるすべての用語、頭字語、略語の定義を説明します。 この用語等の定義については、プロジェクトの用語集を参照するようにしてもかまいません。]
[ここではシステム・アーキテクチャー説明書の中で参照される すべての参考資料の一覧を記載します。 各資料は、タイトル、レポート番号 (該当する場合)、日付、および発行元を明記します。 その参考資料の入手先も記載してください。この参考資料については、付録または別の資料を参照するようにしてもかまいません。]
[ここではシステム・アーキテクチャー説明書のこの項目以降の内容と、システム・アーキテクチャー説明書の構成について説明します。]
[ここではシステム・アーキテクチャーを形成する場合に適用されるあらかじめ決められた方式、原則、および経験則について、それらの選択の根拠 (環境、組織、ドメインへの影響など) と共に記述します。アーキテクチャーの方式には、再利用可能な構成要素 (種類) とその組み合わせ (および組み合わせが可能な場合を示す規則)、および特定の方式を使用したシステムの提示および分析の方法に関する説明が記載されます。]
[ここには、「システム・ユースケース・モデル」に記載されたシステム・ユースケースまたはシナリオのうち、最終的なシステムの重要な中枢機能を表すもの、アーキテクチャー上、大きな範囲を網羅する、言い換えれば、アーキテクチャー上の多くの要素を使用するもの、あるいは、システム・アーキテクチャーで特定の注意を要する繊細な部分を強調し、説明しているものをリストします。また、これらに関連して技術性能測定プロセスの一部として追跡管理するべき性能要求があれば、それらを併せて記載します。]
[ここではシステム・アーキテクチャーの形成に大きく関わる重大な物理的、環境的、サービス品質上の、専門技術面、その他の制約をリストします。また、これらのうち、技術性能測定プロセスの一部として追跡管理するべき制約を併せて記載します。]
[ここではワーカーの視点から、システムの重要な特徴を記述します。 これには、組織およびシステム・ワーカーの役割と職責 (およびこれらに影響するポリシー) に関する事項があります。]
[ここでは論理的ビューポイントからシステムの重大な特徴について記述します。 これには、サブシステムへの分割、それらの接続、相互作用および処理に関連したシステム機能のしくみ、 およびサービス品質やその他の制約を含む機能外要求のサブシステムへのフローダウンに関する事項があります。]
[ここには「システム分析モデル」の「コンテキスト図」に記載されたアーキテクチャーの重要な要素を記述します。例えば、システムと相互処理が行われるエンティティー、接続、および維持される構成要素、データその他のフローなどがあります。]
[ここでは『4.1 システム・コンテキスト』で示されたエンティティー、接続およびフローをサポートする重要なインターフェース (提示および要求されたインターフェース) を記述します。]
[ここでは、アーキテクチャー上の重要な役割を果たすサブシステムについて、そのサブシステムがサポート、および必要とするインターフェース (機能と属性) とそれらの関係 (あるサブシステムと他のサブシステム、システムと外部との関係) を中心に記述します。]
[ここでは、サブシステムの相互作用に関して重要なユースケースとユースケース・シナリオがどのように実現されるか、および重要なシステム性能要求が、サブシステム機能に対して設定された性能上の制約とサブシステム間のリンクにどのように反映されるかを記述します。]
[ここには、重大な物理的、環境的、サービス品質、専門技術およびその他の制約が、どのようにサブシステムに反映されるか、および要求されたシステム特性を得るために、決定されたサブシステムの特性がどのように組み合わされるかを記述します。]
[ここでは、この論理アーキテクチャーの定義および選択が行われた背景となる事業調査、分析、および理由付け、さらに選択された特定のサブシステムおよび相互作用が有効な理由を記述します。運用システムの一部として人間が含まれる決定がなされた場合、人間と、ハードウェアまたはソフトウェアで同じ機能を行ったときの性能とのトレードオフ、および人間の動作特性をどのように考慮するかが記述の中心となります。 また、機能外要求の数値配分ないし割り当てについての根拠 (モデリング、分析、プロトタイプ作成など) についても記述します。]
[ここではプロセスの視点からシステムの重要な特徴を記述します。 これは、並行性 (見かけ上または実際に並行して実行されるマルチプロセス) を利用したシステム・アーキテクチャーをどのように設計すれば、より単純な (したがって保守も容易になる) アーキテクチャーを実現し、拡張容易性、性能、スループットおよび信頼性の問題に対応できるかということを記載します。]
[ここではシステム (サブシステム、クラス、オブジェクト) の重要で不可欠な活動要素を示し、それらの重要な関係と相互作用について説明します。この情報は、システム内のプロセスを表す活動要素を中心にし、「システム分析モデル」および「システム設計モデル」から得られます。]
[ここではプロセス・アーキテクチャーの背景となる分析、理由付けおよび事業調査、またなぜプロセスと相互作用が重要になるか、その理由を説明します。]
[ここでは物理的ビューポイントから、システムの重要な特徴を記述します。 これはシステムの機能および配布をサポートするために必要な物理インフラストラクチャーに関する事項になります。]
[ここではシステムの物理的配置、装置の取り付けおよび組み立て、安全で信頼性の高い物理的操作について記述します。考慮する特性としては、重量、電源装置、発熱および放熱、加速/振動効果、電磁気干渉、物理アクセスなどがあります。]
[ローカリティー・モデルの重要、不可欠な特徴について説明します。これにはローカリティーの分解 (あれば)、ローカリティーおよび接続の特性、ホストされるサブシステム、注目すべきローカリティーの相互作用があります。]
[記述子レベルでの「システム配置モデル」に関する重要で不可欠な特徴を記述します。このレベルでは、ローカリティーの処理リソースのタイプ を指定します。これらは、ノード と呼ばれ、コンピューティング・デバイス (サーバー、ワークステーションなど)、人間、あるいは他の電子機械デバイスが含まれます。]
[実装レベルでのシステム配置モデルの重要、不可欠な特徴を記述します。 このレベルでは、実際のハードウェアの選択が行われます。多数のロール・インスタンス (人的資源の場合) が、決定され、構成、処理能力、消費電力 (その他の環境要件)、コストおよび性能が定義されます。]
[ここには、物理レイアウトと配置アーキテクチャーの背景となる分析、理由付けおよび事業調査を記述し、提示された特徴がなぜ重要なのか、その理由を説明します。]