目次

第1部　アーキテクチャの原則

第1 章　はじめに

1.1 アーキテクチャのライフサイクル
1.2 テーマ、目的、組織第2 章　アーキテクチャ定義

2.1 現代システムのコンセプトの歴史
2.2 システムアーキテクチャ
2.3 エンタープライズアーキテクチャ
2.4 現代ソフトウェアの簡潔な歴史
2.5 ソフトウェア主体システムのアーキテクチャデザインに向けて
2.6 デザイン階層第3 章　アーキテクチャドライバ

3.1 アーキテクチャドライバを定義する
3.2 ハイレベルな機能要求
3.3 品質特性要求
3.4 技術制約
3.5 ビジネス制約
3.6 まとめ第4 章　アーキテクチャ構造

4.1 構造と視点
4.2 構造とシステムレベルのプロパティ
4.3 構造、スタイル、パターン
4.4 構造の使用
4.5 構造化推論のフレームワーク
4.6 フレームワーク応用の例
4.7 タクティクス
4.8 まとめ第5 章　アーキテクトの仕事

5.1 アーキテクトは何をするのか？
5.2 いつアーキテクテチャをデザインするのか？
　　　5.2.1 ビジネスコンテキスト
　　　5.2.2 組　織
　　　5.2.3 デザイン階層における場所
　　　5.2.4 開発ライフサイクル
5.3 アーキテクチャデザインのガイダンス
　　　5.3.1 システムコンテキストの確立
　　　5.3.2 アーキテクチャの分割
5.4 スマートマーキーの例
　　　5.4.1 スマートマーキーのコンテキスト
　　　5.4.2 スマートマーキーの第1 レベルの分割
　　　5.4.3 スマートマーキーの第1 レベルの役割割り当て
　　　5.4.4 スマートマーキーの第2 レベルと第3 レベルの分割
　　　5.4.5 視点の切り替え
　　　5.4.6 何が起きるのか？　それはいつ起きるのか？
　　　5.4.7 インターフェースの定義
5.5 まとめ第6 章　アーキテクチャデザインの文書化

6.1 アーキテクチャ文書のステークホルダ
　　　6.1.1 詳細要素の設計者
　　　6.1.2 構築エンジニアと実装担当者
　　　6.1.3 マネージャ
　　　6.1.4 組織内部の資材調達担当者
　　　6.1.5 ユーザ
　　　6.1.6 顧　客
　　　6.1.7 メンテナンスエンジニア
　　　6.1.8 インストールエンジニア
　　　6.1.9 テスト担当者または評価エンジニア
　　　6.1.10 マーケティングまたは販売
6.2 いつアーキテクチャを文書化するべきか？
6.3 何を文書化すべきか？
6.4 文書化のためのツールとUML
6.5 技術文書作成のための一般的なガイダンス
　　　6.5.1 アーキテクチャ文書をデザインする
　　　6.5.2 読み手に感情移入する
　　　6.5.3 憶測をせずに、詳細に注目する
　　　6.5.4 関連する多数の相互作用をグループ化し、相互作用の数を減らす
　　　6.5.5 単純化し必要に応じて詳細を加える
　　　6.5.6 仕組みに注意を払う
6.6 文書の構造
　　　6.6.1 前付け
　　　6.6.2 第1 章：文書の説明
　　　6.6.3 第2 章：プロジェクト概要
　　　6.6.4 第3 章：アーキテクチャドライバ
　　　6.6.5 第4 章：システムのコンテキスト
　　　6.6.6 第5 章：レベルXの分解
　　　6.6.7 第6 章：視点の関連付け
　　　6.6.8 第7 章：文書の索引
6.7 まとめ第2部　アーキテクチャデザインプロセス

第7 章　アーキテクチャ中心設計手法（ACDM）

7.1 ACDM概説
7.2 ACDMで定義される役割第8 章　ACDM ステージ1 ：アーキテクチャドライバの発見

8.1 目　的
8.2 事前条件
8.3 活動概要
8.4 技法、テンプレート、ガイダンス
8.5 主要な成果物
8.6 事後条件
8.7 ステージ1 の説明
8.8 マスター設計計画：デザイン戦略の立案
　　　8.8.1 アーキテクチャドライバ抽出ワークショップの計画づくり
8.9 アーキテクチャドライバ抽出ワークショップの実施
　　　8.9.1 導入とワークショップ概要
　　　8.9.2 製品やシステムの概要
　　　8.9.3 オペレーション記述の識別
　　　8.9.4 品質特性要求の識別
　　　8.9.5 ビジネス制約の識別
　　　8.9.6 技術制約の識別
　　　8.9.7 まとめと次のステップ
　　　8.9.8 未加工のアーキテクチャドライバの整理統合
8.10 マスター設計計画の作成と更新
　　　8.10.1 スケジュールの作成
　　　8.10.2 固定コストと固定スケジュールがACDMの計画づくりに与える影響
　　　8.10.3 あらかじめ決まっている要求がACDMの要求抽出プロセスへ与える影響
8.11 まとめ第9 章　ACDM ステージ2 ：プロジェクトスコープの確立

9.1 目　的
9.2 事前条件
9.3 活動概要
9.4 技法、テンプレート、ガイダンス
9.5 主要な成果物
9.6 事後条件
9.7 ステージ2 の説明
9.8 ステージ2 の計画づくり
9.9 分　析
　　　9.9.1 オペレーション記述からユースケースを構築するためのガイド
　　　9.9.2 ユースケースの例
　　　9.9.3 品質特性描写を分析して品質特性シナリオを定義するためのガイド
　　　9.9.4 制約の洗練
　　　9.9.5 難易度のランク付け
9.10 文書化
　　　9.10.1 アーキテクチャドライバ仕様
　　　9.10.2 アーキテクチャドライバ仕様の評価
　　　9.10.3 マスター設計計画の更新
9.11 まとめ第10 章　ACDM ステージ3 ：アーキテクチャの作成と洗練

10.1 目　的
10.2 事前条件
10.3 活動概要
10.4 技法、テンプレート、ガイダンス
10.5 主要な成果物
10.6 事後条件
10.7 ステージ3 の説明
10.8 ステージ3 の計画づくり
10.9 直感的なアーキテクチャのデザイン
　　　10.9.1 コンテキストの確立
　　　10.9.2 イテレーティブな分割
10.10 直感的なアーキテクチャの洗練
10.11 要素インターフェース
10.12 トレーサビリティ
10.13 いつアーキテクチャデザインは完了するのか？
10.14 マスター設計計画の更新
10.15 まとめ第11 章　ACDM ステージ4 ：アーキテクチャデザインの評価

11.1 目　的
11.2 事前条件
11.3 活動概要
11.4 技法、テンプレート、ガイダンス
11.5 主要な成果物
11.6 事後条件
11.7 ステージ4 の説明
11.8 評価手法の比較
11.9 ステージ4 の計画づくり
11.10 デザイン評価における心理学
　　　11.10.1 「私の子は醜くない！」
　　　11.10.2 無関心
　　　11.10.3 「私はあなたよりも賢い」
　　　11.10.4 「これは省こう」
　　　11.10.5 「犯人を探せ」
　　　11.10.6 「今、直そう」
　　　11.10.7 「お話の時間」
11.11 アーキテクチャデザイン評価ワークショップの実施
　　　11.11.1 ファシリテータ
　　　11.11.2 アーキテクチャ発表者
　　　11.11.3 書　記
　　　11.11.4 評価プロセス実施者
　　　11.11.5 タイムキーパー
　　　11.11.6 質問者
11.12 質問者へのアドバイス
　　　11.12.1 一貫性の吟味
　　　11.12.2 詳細過ぎず、概略過ぎず
　　　11.12.3 機能分析中の質問に対するガイダンス
　　　11.12.4 構造分析中の質問に対するガイダンス
11.13 ファシリテーションのためのアドバイス
　　　11.13.1 公正であれ
　　　11.13.2 聴く
　　　11.13.3 弱きものを守る
　　　11.13.4 非言語シグナルに注意を払う
　　　11.13.5 非生産的な振る舞いに対処する
　　　11.13.6 己を知る
11.14 マスター設計計画の更新
11.15 まとめ第12 章　ACDM ステージ5 ：製品化フェーズへの移行判定

12.1 目的
12.2 事前条件
12.3 活動概要
12.4 技法、テンプレート、ガイダンス
12.5 主要な成果物
12.6 事後条件
12.7 ステージ5 の説明
12.8 ステージ5 の計画づくり
12.9 課題分析ミーティング
12.10 移行判定
12.11 マスター設計計画の更新
12.12 まとめ第13 章　ACDM ステージ6 ：実証実験

13.1 目　的
13.2 事前条件
13.3 活動概要
13.4 技法、テンプレート、ガイダンス
13.5 主要な成果物
13.6 事後条件
13.7 ステージ6 の説明
13.8 ステージ6 の計画づくり
13.9 実証実験の計画づくりと実行
　　　13.9.1 実証実験テンプレート
　　　13.9.2 実証実験のプロセス
　　　13.9.3 実証実験の承認
　　　13.9.4 実験の実施
　　　13.9.5 実験後の記録
13.10 マスター設計計画の更新
13.11 まとめ第14 章　ACDM ステージ7 ：製品化計画

14.1 目　的
14.2 事前条件
14.3 活動概要
14.4 技法、テンプレート、ガイダンス
14.5 主要な成果物
14.6 事後条件
14.7 ステージ7 の説明
14.8 ステージ7 の計画づくり
14.9 アーキテクチャ説明ワークショップ
　　　14.9.1 一般的な計画づくりのガイドラインと検討項目
14.10 製品化のためのスケジュール
14.11 要素単位のワイドバンドデルファイ見積もり
14.12 テスト計画づくり
14.13 製品化計画における他の要素
14.14 マスター設計計画の更新
14.15 まとめ第15 章　ACDM ステージ8 ：製品化フェーズ

15.1 目　的
15.2 事前条件
15.3 活動概要
15.4 技法、テンプレート、ガイダンス
15.5 主要な成果物
15.6 事後条件
15.7 ステージ8 の説明
15.8 ステージ8 の計画づくり
15.9 デザインの一貫性
15.10 アーキテクチャ要素の統合
15.11 製品化工数の追跡
15.12 まとめ第3部　既存のプロセスフレームワークへのACDMのスケールアップと統合

第16 章　デザインプラクティス、プロセス、手法の移行

16.1 一般的な移行戦略
　　　16.1.1 変革の推進者（チェンジエージェント）
16.2 変革の戦略
　　　16.2.1 スポンサーシップ
　　　16.2.2 ベースライン
　　　16.2.3 計画
　　　16.2.4 実施
　　　16.2.5 振り返り
16.3 移行と適用についての現実的なアイデア
　　　16.3.1 コモンセンスは惜しげなく適用せよ
　　　16.3.2 テンプレートを導入する
　　　16.3.3 技術者のキャリアパスを作る
　　　16.3.4 アーキテクチャデザインチームを設立する
　　　16.3.5 アーキテクチャ評価を制度化する
16.4 導入にあたっての障壁：共通のアンチプラクティス
　　　16.4.1 ビジネスコンテキストの不一致
　　　16.4.2 放棄
　　　16.4.3 リップサービス
　　　16.4.4 ソフトウェアは簡単
　　　16.4.5 丸投げ
　　　16.4.6 ウチの縄張りだ…。コラー！
　　　16.4.7 必要な才能の不足
　　　16.4.8 マーケティングとエンジニアの分離
　　　16.4.9 トレーニングと移行計画
16.5 まとめ第17 章　デザインに関するその他の考慮事項：レガシー、選択によるデザイン、メンテナンス

17.1 「レガシーウェア」を使ったデザイン
　　　17.1.1 レガシーウェアの科学捜査
17.2 デザインに関するその他の考慮事項
17.3 選択によるデザイン
　　　17.3.1 共通の誤り
17.4 ACDMにおける商用製品の認定
17.5 アーキテクチャの非互換性の問題を解決する戦略
　　　17.5.1 ソフトウェアラッパー
　　　17.5.2 媒　介
17.6 ACDMのスケールアップ
17.7 メンテナンスにおけるACDM
17.8 まとめ第18 章　ソフトウェア開発フレームワークとACDM の併用

18.1 用　語
18.2 「重量プロセス」対「軽量プロセス」
18.3 ACDMとソフトウェア開発プロセスフレームワーク
　　　18.3.1 ACDMとウォーターフォール
　　　18.3.2 ACDMとエクストリームプログラミング（XP）
　　　18.3.3 ACDMとスクラム
　　　18.3.4 ACDMとチームソフトウェアプロセス（TSP）
　　　18.3.5 ACDMとRUP
　　　18.3.6 ACDMとAUP
　　　18.3.7 ACDMとCMMI
18.4 まとめ
参考文献 索　引