アーキテクチャ中心設計手法 ソフトウェア主体システム開発のアーキテクチャデザインプロセス(玉川 憲 玉川 憲 橘高 陸夫 橘高 陸夫 橘高 陸夫 Anthony J.Lattanze 濱田 一規 濱田 一規 長谷川 倫也 長谷川 倫也 杉浦 眞理 杉浦 眞理 遠藤 美乃里 遠藤 美乃里 川田 雅人 川田 雅人 遠藤 一雄 遠藤 一雄)|翔泳社の本
  1. ホーム >
  2. 書籍 >
  3. アーキテクチャ中心設計手法 ソフトウェア主体システム開発のアーキテクチャデザインプロセス

アーキテクチャ中心設計手法 ソフトウェア主体システム開発のアーキテクチャデザインプロセス

翻訳
原著
監修
翻訳
原著

翻訳
原著
翻訳
原著
翻訳
原著
翻訳
原著
翻訳
原著
翻訳
原著

形式:
書籍
発売日:
ISBN:
9784798122373
定価:
5,280(本体4,800円+税10%)
仕様:
B5変・560ページ
カテゴリ:
プログラミング・開発
キーワード:
#プログラミング,#開発環境,#開発手法,#Web・アプリ開発

本邦初 アーキテクチャ中心設計手法(ACDM)の詳解解説

緊急指令。
原理・実践に引き続き、アーキテクチャ構築のディシプリン(規律)を習得せよ。
---日本アイ・ビー・エム株式会社グローバル・ビジネス・サービス事業CTO 榊原彰氏 推薦

アーキテクトの卵やすでにアーキテクトとして働いている人が、参照できる初の実践ガイド。
アーキテクチャドライバからアーキテクチャ構造へいかにつなげていくのか、じっくり学べます。
---株式会社豆蔵 取締役CTO 羽生田栄一氏 推薦

現代のソフトウェアシステムは高度に複雑化し大規模化する傾向にあり、そうした中でのアーキテクチャ設計はシステムの特徴を決定づける非常に重要なステップにも関わらず、多くの企業はこれを経験任せの力技に頼っているのが現状です。

本書は、そうした企業向けにアーキテクチャ設計の原則とガイドライン、および本邦初紹介となる「アーキテクチャ中心設計手法(ACDM)」を解説します。さらに、ビジネス制約サイドから見たアーキテクチャへの影響、要求分析、要求とアーキテクチャの関係、組織の現状とその場しのぎのアーキテクチャ設計プロセスからの移行戦略などもまとめた一冊です。

【原書タイトル】 Architecting Sofware Intensive Systems:A Practitioner's Guide

第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 まとめ
参考文献 索 引
本書は付属データの提供はございません。

お問い合わせ

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

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

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

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

追加情報はありません。
この商品の「よくある質問」はありません。

ご購入いただいた書籍の種類を選択してください。

書籍の刷数を選択してください。

刷数は奥付(書籍の最終ページ)に記載されています。

現在表示されている正誤表の対象書籍

書籍の種類:

書籍の刷数:

本書に誤りまたは不十分な記述がありました。下記のとおり訂正し、お詫び申し上げます。

対象の書籍は正誤表がありません。

最終更新日:2015年07月07日
発生刷 ページ数 書籍改訂刷 電子書籍訂正 内容 登録日
1刷 094
「廃止と移行の戦略作成」2行目
そして通常は古いステムと
そして通常は古いシステムと
2015.07.07
1刷 468
表17.2(3箇所)
[品質特性の責務]-[QA-1]-[責務の相関] Σ=9/12 [品質特性の責務]-[QA-3]-[責務の相関] Σ=9/12 [ビジネス上の考慮事項]-[コスト]-[責務の相関] Σ=6/18
[品質特性の責務]-[QA-1]-[責務の相関] Σ=12/12 [品質特性の責務]-[QA-3]-[責務の相関] Σ=2/8 [ビジネス上の考慮事項]-[コスト]-[責務の相関] Σ=9/18
2014.12.24

感想・レビュー

bashi さん

2011-04-11

アーキテクチャ中心設計手法(ACDM)の解説本だが、前半部でアーキテクトの責務やアーキテクチャデザインの手法について詳細に説明しているため、アーキテクチャデザインについての知識があまりなくても実際にシステム開発に携わった人であれば理解できると思う。 成果物となるドキュメントのテンプレートが示されているのは良い。具体例がもっとあるとよかったが、そうするとページ数が多すぎかなあ。