システムアーキテクチャ構築の実践手法

序　文

第1 章　はじめに

1.1 プロセスの適用
1.2 プロセスの要約
1.3 スコープ
1.4 まとめ

第2 章　アーキテクチャ、アーキテクト、アーキテクティング

2.1 アーキテクチャ
　　　2.1.1 アーキテクチャは構造を定義する
　　　2.1.2 アーキテクチャは振る舞いを定義する
　　　2.1.3 アーキテクチャは重要な要素に焦点を絞る
　　　2.1.4 アーキテクチャはステークホルダのニーズのバランスをとる
　　　2.1.5 アーキテクチャは論理的根拠に基づく判断を具体化する
　　　2.1.6 アーキテクチャはアーキテクチャスタイルに従う場合がある
　　　2.1.7 アーキテクチャはその環境によって影響を受ける
　　　2.1.8 アーキテクチャは開発チームの構造に影響を与える
　　　2.1.9 アーキテクチャはすべてのシステムに存在する
　　　2.1.10 アーキテクチャはある特定のスコープを持つ
2.2 アーキテクト
　　　2.2.1 アーキテクトは技術リーダーである
　　　2.2.2 アーキテクトの役割は、チームで遂行してもよい
　　　2.2.3 アーキテクトはソフトウェア開発プロセスを理解している
　　　2.2.4 アーキテクトはビジネス領域の知識を持っている
　　　2.2.5 アーキテクトはテクノロジーの知識を持っている
　　　2.2.6 アーキテクトは設計スキルを持っている
　　　2.2.7 アーキテクトはプログラミングスキルを持っている
　　　2.2.8 アーキテクトは優れたコミュニケータである
　　　2.2.9 アーキテクトは判断を下す
　　　2.2.10 アーキテクトは組織的な政治に配慮する
　　　2.2.11 アーキテクトは交渉人である
2.3 アーキテクティング
　　　2.3.1 アーキテクティングは科学である
　　　2.3.2 アーキテクティングは芸術である
　　　2.3.3 アーキテクティングは多くの専門分野にまたがる
　　　2.3.4 アーキテクティングは継続的な活動である
　　　2.3.5 アーキテクティングは多くのステークホルダによって動機付けされる
　　　2.3.6 アーキテクティングはしばしばトレードオフを伴う
　　　2.3.7 アーキテクティングは経験を認める
　　　2.3.8 アーキテクティングにはトップダウンとボトムアップの両方がある
2.4 アーキテクティングの利点
　　　2.4.1 アーキテクティングはシステム品質に寄与する
　　　2.4.2 アーキテクティングは合意を促進する
　　　2.4.3 アーキテクティングはプランニングプロセスをサポートする
　　　2.4.4 アーキテクティングはアーキテクチャ上の一貫性を促進する
　　　2.4.5 アーキテクティングは複雑性を管理する助けになる
　　　2.4.6 アーキテクティングは再利用の基礎を与える
　　　2.4.7 アーキテクティングは保守コストを削減する
　　　2.4.8 アーキテクティングは影響分析をサポートする
2.5 まとめ

第3 章　手法の基礎

3.1 主要な概念
3.2 メソッドコンテンツ
　　　3.2.1 ロール（役割）
　　　3.2.2 ワークプロダクト
　　　3.2.3 アクティビティ
　　　3.2.4 タスク
3.3 プロセス
　　　3.3.1 ウォーターフォール型プロセス
　　　3.3.2 反復型プロセス
　　　3.3.3 アジャイル型プロセス
3.4 まとめ

第4 章　ソフトウェアアーキテクチャの文書化

4.1 エンドゲーム
4.2 主要な概念
4.3 ビューポイントとビュー
　　　4.3.1 基本ビューポイント
　　　4.3.2 横断的なビューポイント
　　　4.3.3 ビューとダイアグラム
　　　4.3.4 ビューポイントとビューの利点
4.4 モデル
　　　4.4.1 実現のレベル
　　　4.4.2 モデルの利点
4.5 アーキテクチャ記述フレームワークの特性
　　　4.5.1 ソフトウェアアーキテクチャの4+1 ビューモデル
　　　4.5.2 Zachman フレームワーク
　　　4.5.3 Rozanski とWoods
4.6 アーキテクチャ記述フレームワーク
　　　4.6.1 ビューポイント
　　　4.6.2 ワークプロダクト
　　　4.6.3 実現のレベル
　　　4.6.4 ビュー対応関係
4.7 ソフトウェアアーキテクチャ文書
4.8 まとめ

第5 章　再利用可能なアーキテクチャアセット

5.1 アーキテクチャの源
5.2 アーキテクチャアセットメタモデル
　　　5.2.1 開発時アセット
　　　5.2.2 実行時アセット
5.3 アセットタイプ
　　　5.3.1 参照アーキテクチャ
　　　5.3.2 開発手法
　　　5.3.3 ビューポイントカタログ
　　　5.3.4 アーキテクチャスタイル
　　　5.3.5 アーキテクチャメカニズム
　　　5.3.6 パターン
　　　5.3.7 参照モデル
　　　5.3.8 アーキテクチャ上の判断
　　　5.3.9 既存のアプリケーション
　　　5.3.10 パッケージアプリケーション
　　　5.3.11 アプリケーションフレームワーク
　　　5.3.12 コンポーネントライブラリ／コンポーネント
5.4 アーキテクチャアセットの属性
5.5 その他の再利用に関する考慮事項
5.6 まとめ

第6 章　ケーススタディ概論

6.1 プロセスの適用
6.2 ケーススタディのスコープ
　　　6.2.1 プロジェクトチーム
　　　6.2.2 外部からの影響
6.3 アプリケーション概要
6.4 YourTour のビジョン
　　　6.4.1 問題記述
　　　6.4.2 ステークホルダ
　　　6.4.3 機能性
　　　6.4.4 品　質
　　　6.4.5 制　約
6.5 まとめ

第7 章　要求の定義

7.1 要求をアーキテクチャに関連付けすること
7.2 機能および非機能要求
7.3 要求文書化のテクニック
7.4 プロセスの適用
7.5 タスク記述の理解
7.6 要求定義：アクティビティ概要
　　　タスク：ステークホルダ要望の収集
　　　タスク：共通ボキャブラリの捕捉
　　　タスク：システムコンテクストの定義
　　　タスク：機能要求の概要記述
　　　タスク：非機能要求の概要記述
　　　タスク：要求の優先順位付け
　　　タスク：機能要求の詳細化
　　　タスク：非機能要求の詳細化
　　　タスク：ソフトウェアアーキテクチャ文書の更新
　　　タスク：ステークホルダとの要求確認
7.7 まとめ

第8 章　論理アーキテクチャの作成

8.1 要求からソリューションへの遷移
8.2 論理アーキテクチャの価値
　　　8.2.1 論理アーキテクチャの最小化
　　　8.2.2 投資としての論理アーキテクチャ
　　　8.2.3 追跡可能性の重要性
8.3 プロセスの適用
8.4 論理アーキテクチャの作成：アクティビティの概要
　　　タスク：アーキテクチャアセットを調査する
　　　タスク：アーキテクチャ概要を定義する
　　　タスク：アーキテクチャ上の判断を文書化する
　　　タスク：機能要素の概要記述を作成する
　　　タスク：配置要素の概要記述を作成する
　　　タスク：アーキテクチャを検証する
　　　タスク：アーキテクチャ構想実証を構築する
　　　タスク：機能要素の詳細記述を作成する
　　　タスク：配置要素の詳細記述を作成する
　　　タスク：アーキテクチャの妥当性を確認する
　　　タスク：ソフトウェアアーキテクチャ文書を更新する
　　　タスク：ステークホルダとアーキテクチャをレビューする
8.5 まとめ

第9 章　物理アーキテクチャの作成

9.1 論理から物理アーキテクチャへの移行
9.2 プロセスの適用
9.3 物理アーキテクチャの作成：アクティビティの概要
9.4 タスク：アーキテクチャアセットの調査
9.5 タスク：アーキテクチャ概要の定義
9.6 タスク：アーキテクチャ上の判断の文書化
9.7 タスク：機能要素の概要記述
　　　9.7.1 論理機能要素から物理機能要素へのマッピング
　　　9.7.2 物理機能要素の特定
　　　9.7.3 製品の調達
　　　9.7.4 テクノロジー特化のパターンへの適合
9.8 タスク：配置要素の概要記述
　　　9.8.1 論理配置要素から物理配置要素へのマッピング
　　　9.8.2 物理配置要素の特定
　　　9.8.3 ハードウェアの調達
9.9 タスク：アーキテクチャの検証
9.10 タスク：アーキテクチャ構想実証の構築
9.11 タスク：機能要素の詳細化
9.12 タスク：配置要素の詳細化
9.13 タスク：アーキテクチャの妥当性確認
9.14 タスク：ソフトウェアアーキテクチャ文書を更新する
9.15 タスク：ステークホルダとのアーキテクチャレビュー
9.16 まとめ

第10 章　応用編

10.1 アーキテクトとプロジェクトチーム
　　　10.1.1 アーキテクトと要求
　　　10.1.2 アーキテクトと開発
　　　10.1.3 アーキテクトとテスト
　　　10.1.4 アーキテクトとプロジェクトマネジメント
　　　10.1.5 アーキテクトと構成管理
　　　10.1.6 アーキテクトと変更管理
　　　10.1.7 アーキテクトと開発環境
　　　10.1.8 アーキテクトとビジネスアナリシス
10.2 アーキテクトと外部の影響
　　　10.2.1 エンタープライズアーキテクチャ
　　　10.2.2 デザインオーソリティ
　　　10.2.3 システムインフラストラクチャを提供するプロバイダ
　　　10.2.4 アプリケーション保守に関わるプロバイダ
10.3 複雑なシステムのアーキテクティング
　　　10.3.1 明確に区別できる多くの機能が開発されている
　　　10.3.2 多くの要員が開発に関わる
　　　10.3.3 高度に分散化したシステム
　　　10.3.4 地理的に分散している開発チーム
　　　10.3.5 極めて厳しい実行時品質への挑戦
　　　10.3.6 システムの中のシステム
10.4 まとめ
10.5 結論：著者からのノート

付録A ソフトウェアアーキテクチャメタモデル

A.1 メタモデルの用語の定義

付録B ビューポイントカタログ

B.1 ステークホルダの要約
B.2 基本ビューポイント
B.3 横断的ビューポイント
B.4 ビュー対応関係

付録C 手法要約

C.1 ロール（役割）
C.2 ワークプロダクト
C.3 アクティビティ
C.4 タスク
　　　C.4.1 アクティビティ：要求定義
　　　C.4.2 アクティビティ：論理アーキテクチャの作成
　　　C.4.3 アクティビティ：物理アーキテクチャの作成
C.5 フェーズ
　　　C.5.1 方向付け
　　　C.5.2 推　敲
　　　C.5.3 作　成
　　　C.5.4 移　行

付録D アーキテクチャ要求チェックリスト

D.1 機能要求
D.2 ユーザビリティ要求
D.3 信頼性要求
D.4 パフォーマンス要求
D.5 サポータビリティ要求
D.6 制　約
D.6.1 ビジネス制約
D.6.2 アーキテクチャ制約
D.6.3 開発制約
D.6.4 物理制約
用語解説 参考文献 索　引

本書は付属データの提供はございません。

お問い合わせ

内容についてのお問い合わせは、正誤表、追加情報をご確認後に、お送りいただくようお願いいたします。

正誤表、追加情報に掲載されていない書籍内容へのお問い合わせや
その他書籍に関するお問い合わせは、書籍のお問い合わせフォームからお送りください。

利用許諾に関するお問い合わせ

本書の書影（表紙画像）をご利用になりたい場合は書影許諾申請フォームから申請をお願いいたします。
書影（表紙画像）以外のご利用については、こちらからお問い合わせください。

追加情報はありません。

正誤表の登録はありません。