ソフトウェア書籍一覧（ピアソンエデュケーション）


Amazon.co.jpで購入する cbook24.comで購入するソフトウエア書籍一覧　目次	自動ソフトウェアテスト導入から、管理・実践まで効果的な自動テスト環境の構築を目指して ISBN4-89471-488-4　　ピアソン・エデュケーション原書：Addison Wesley「Automated Software Testing: Introduction, Management, and Performance」ISBN0201432870 Elfriede Dustin, Jeff Rashka and John Paul　著向井清　訳 B5変形判　　544ページ　　本体価格\5.800　　2002年10月発売 [内容] ソフトウェアのリリース速度に関して日増しに市場からの要望が強くなっている現状のなかで、従来からの時間がかかり人海戦術的なテスト方法から、自動化された方法によるより速くより十分なテスト方法が求められています。これは、ソフトウェア業界がはらむ根源的な問題となりつつあります。本書は、自動ソフトウェアテストのもっとも効果的なツールやテクニックや自動化テストの方法を、包括的にかつ段階的に説明しています。また、自動ソフトウェアテストをどのように導入し、管理、実施していけばよいかを、ソフトウェア開発の実例をあげながらわかりやすく説明しています。 [目次] 第I部自動テストとは何か第1章自動テストの誕生と発展自動テストソフトウェアテストの背景自動テストライフサイクル方法論（ATLM）・テスト自動化への意思決定・テストツールの調達・自動テスト導入フェーズ・テスト計画、設計、開発・テストの実行と管理・テストプログラムのレビューとアセスメントソフトウェアテスト領域におけるATLMの役割・システム開発ライフサイクルとATLMの関係・テスト成熟度モデル（TMM）－自動ソフトウェアテスト成熟度による拡張・・CMMとTMMの相互関係・テスト自動化開発・テスト作業ソフトウェアテストキャリア第2章テスト自動化への意思決定誤った自動テストへの期待に打ち勝つ・自動テスト計画の作成・すべてにあうテストツール・テスト作業の即効的削減・スケジュールの即効的短縮・ツールの使い勝手・テスト自動化の普遍的な適用・100％のテストカバレージ自動テストの恩恵・高速信頼度システムの開発・・要求仕様定義の改善・・性能テストの改善・・ストレステストの改善・・品質測定とテスト最適化・・開発チームとのパートナシップの改善・・システム開発ライフサイクルの改善・テスト作業の品質改善・・ビルド検証テスト（スモークテスト）の改善・・回帰テストの改善・・マルチプラットフォームの両立性テストの改善・・ソフトウェア構成テストの改善・・退屈なテストの実行の改善・・先進的テスト課題の取り組みの改善・・手動テストでは達成不能なテストの実行・・ソフトウェア欠陥を再生する能力・・業務の専門知識の強化・・勤務時間外テストの実行経営者の支援の獲得・テストツール提案・・改善機会の見積もり・・正しいツール選択のための判定基準・・ツール費用見積もり・・ツール導入にともなう追加発生時間・・ツールの専門的知識・・ツールの訓練費用・・ツール評価ドメイン・・ツールの現場展開プロセス第3章自動テストツールの評価と選定企業のシステムエンジニアリング環境・経営者、スタッフ、エンドユーザからの第三者情報・システムエンジニアリング環境を反映したツール基準・ソフトウェア品質のレベル・ヘルプデスクの問題報告・予算の制約・テストのタイプ・長期的投資での考慮事項・テストツールプロセス・近道を避けるテストライフサイクルを支援するルール・業務分析フェーズのツール・・業務モデルツール・・構成管理ツール・・欠陥追跡ツール・・技術レビュー管理ツール・・ドキュメントジェネレータ・要求仕様定義フェーズのツール・・要求事項管理ツール・・要求事項検証ツール・分析および設計フェーズのツール・・ビジュアルモデリングツール・・テストプロシージャジェネレータ・プログラミングフェーズのツール・・構文チェッカ/デバッガ・・メモリリークおよびランタイムエラー検出ツール・・ソースコードテストツール・・静的および動的アナライザ・メトリクスツール・・メトリクスレポータ・・コードカバレージアナライザとコードインストルメンタ・・ユーザビリティ測定ツール・テストライフサイクルを支援するその他のツール・・テストデータジェネレータ・・ファイル比較ユーティリティ・・シミュレーションツール・テストフェーズのツール・・テスト管理ツール・・ネットワークテストツール・・GUIアプリケーションテストツール（記録/再生ツール）・・負荷/性能/ストレステストツール・・環境テストツール・・西暦2000年問題（Y2K）テストツール・・成果物依存テストプロシージャジェネレータテストツールの調査・改善機会評価ドメインの定義ツールの実地評価・評価レポート・ライセンス契約第II部プロジェクトへの自動テストの導入第4章自動テスト導入プロセステストプロセスの分析・プロセスレビュー・・テストチームの早期関与・・反復プロセス・・継続的改善・・自動テストプロセス統合へのセーフガード・テストのゴールとテスト目的・テスト戦略・・欠陥予防戦略・・欠陥検出戦略テストツールの検討・プロジェクト固有のシステム要求事項のレビュー・テスト対象アプリケーション概要・プロジェクトスケジュールのレビュー・テストツール両立性確認・プロジェクトチームへのツールのデモ・テストツールサポートプロフィール・訓練要求事項のレビュー第5章テストチーム管理テストチームの組織構造・ストーブパイプテストチーム・中央集中型テストチーム・IV＆Vテストチーム・システム方法論およびテスト（SMT）チーム・テストチームのまとめテストプログラム作業テスト作業規模推定・テストチーム規模見積もり手順－概要・開発比率法・人数比法・テストプロシージャ・計画タスク法・テスト工数規模見積もりの要因テスト技術者の採用・テスト技術者の資質・テストチームの構成・業務要件・採用活動・テスト技術者の位置付け・テスト技術者の面接・最良の候補者の峻別役割と責任第III部テスト計画と準備第6章テスト計画立案：賢いテストの適用テスト計画活動テストプログラムスコープ・システム記述・クリティカルで高リスクな機能・テストのゴール、目的、戦略・テストツール・テストプログラムパラメータ・検証手法・テスト要求事項定義テスト要求事項管理・要求事項管理ツール・テスト要求事項リスクのアセスメント・テストの優先順位付け・要求事項追跡管理テストプログラムのイベント、アクティビティ、文書化・イベント・アクティビティ・文書化テスト環境・テスト環境準備・テスト環境の統合とセットアップテスト計画・テスト終結/受け入れ基準・サンプルテスト計画第7章テスト分析と設計テスト要求事項分析・開発段階テスト分析（構造的アプローチ）・・開発テスト要求事項管理表・システム段階テスト分析（振る舞いアプローチ）・・システムテスト要求事項管理表テストプログラム設計・テストプログラム設計モデル・・設計ベースのテストアーキテクチャ・・技法ベースのテストアーキテクチャ・・効果的なテストプログラム設計・ホワイトボックス技法（開発段階テスト）・・ホワイトボックス技法の説明・・ホワイトボックステストを支援する自動化ツール・ブラックボックス技法（システム段階テスト）・・ブラックボックス技法の説明・・ブラックボックステスト支援自動ツール・テスト設計の文書化テストプロシージャ設計・テストプロシージャ定義・自動テストと手動テストの分析・・ステップバイステップ－一度にすべての自動化を図ってはいけない・・すべてのテストを自動化できるわけではない・・テストゴールを見失ってはいけない・・テスト対象アプリケーションのプログラムロジックと重複した自動化をしてはならない・・自動化対象作業を分析する・・自動モジュールの再利用可能性を分析する・・反復的タスクに自動化を絞る－手動テスト作業の削減・・データ駆動型タスクの自動化に的を絞る－手動テスト作業の削減・・テストツールの能力を考慮する・・リスクに基づくテスト要求事項を自動化する・自動テスト設計標準・・設計するべき時期・・何を設計するべきか・・どのように設計するか・・テストプロシージャのモジュール性・・テストプロシージャ独立（test procedure independence）・・スクリプト言語・・テストツールデータベース・・テストプロシージャテンプレート・・命名規約・手動テスト設計ガイドライン・・命名規約・・テストプロシージャ詳細・・予想出力・・手動テストプロシージャの例・詳細テスト設計・テストデータ要求事項・・ホワイトボックステストのデータ定義・・ブラックボックステストのデータ定義第8章テスト開発テスト開発アーキテクチャ・技術環境・環境準備状況の確認・自動化フレームワークの再利用分析・テストプロシージャ開発/実行スケジュール・モジュール相関分析・モジュール相関管理表の例の説明・テストツールのカスタマイズ・両立性問題の回避策・テストプロシージャの手動実行・テストプロシージャ検査－同僚レビュー・テストプロシージャの構成管理テスト開発ガイドライン・設計から開発への移行・再利用可能なテストプロシージャ・・データ・・アプリケーションナビゲーション・・ビットマップイメージの記録・・自動化ワイルドカード・・捕獲/再生・保守容易なテストプロシージャ・・外観標準・・テストスクリプトのコメント・・テストスクリプトの文書化・・テストプロシージャヘッダー・・同期化・・テストプロシージャインデックス・・エラー処理・・名称標準・・モジュール性・・ループ構造・・分岐構造・・文脈独立・・グローバルファイル・・定数・その他のガイドライン・・出力書式・・テストプロシージャ/検証観点・・ユーザ定義検証手法・・APIコールと.dllファイル自動化インフラストラクチャ・テーブル駆動のテスト自動化・PC環境の自動設定スクリプト・自動記録オプション・終了機能・ナビゲーション・GUI標準の検証・スモークテスト・エラーログルーチン・ヘルプ機能検証スクリプト・時限設定型メッセージボックス機能・高度な数学関数第IV部テストの実行とレビュー第9章テストの実行テストフェーズの実行と評価・単体テストの実行と評価・統合テストの実行と評価・システムテストの実行と評価・・偽陰性・・偽陽性・回帰テストのテスト結果分析・ユーザ受け入れテストの実行と評価欠陥追跡と新規ビルドプロセス・欠陥のライフサイクルモデルテストプログラム状況追跡・出来高価値管理システム・テストメトリクスの収集と分析・・ホワイトボックステストメトリクス・・ブラックボックステストのメトリクス第10章テストプログラムのレビューとアセスメントテストプログラムで学習した教訓－是正処置と改善活動テストプログラム投資利益第V部付録付録A 要求事項のテスト方法要求事項のテスト実施アプローチ付録B 自動テストライフサイクルを支援するツールはじめに業務分析フェーズ・業務モデルツール・・Oracle Designer/2000 ・・Rational Rose ・構成管理ツール・・ClearCase ・欠陥追跡ツール・・PVCS Tracker ・・TestTrack ・・Census ・技術レビュー管理ツール・・ReviewPro ・ドキュメントジェネレータ・・SoDA 要求事項定義フェーズ・要求事項管理フェーズ・・ReQuisitePro ・・DOORS ・要求事項検証ツール・ユースケースジェネレータ分析および設計フェーズ・ビジュアルモデリングツール・・RationalRose ・構造化チャート、フローチャート、シーケンス図・・Micrografx FlowCharter7 ・・テストプロシージャジェネレータプログラミングフェーズ・構文チェッカ/デバッガ・メモリリークおよびランタイムエラー検出ツール・・Rational Purify ・コードチェッカ・・CodeCheck ・静的および動的アナライザ・・LDRA Testbed ・・Discover ・単体および統合テストツール・・Aprobe ・・Integrisoft MTE メトリクスツール・コード（テスト）カバレージアナライザとコードインストルメンタ・・TCAT ・・Hindsight ・・EZCover ・・STW/C ・・PureCoverage ・ユーザビリティ測定ツール・・EgoLight テスト支援ツール・テストデータジェネレータ・・TestBytes ・ファイル比較ツール・・EXDIFF ・シミュレーションツール・・OPNET テストフェーズ・テスト管理ツール・ネットワークテストツール・・NetClarity ・GUIアプリケーションテストツール・・Rational Suite TestStudio ・・AutoScriptor Inferno ・負荷/性能テストツール・・PerformanceStudio ・Webテストツール・・Skill Tools ・西暦2000年問題テストツール・・DiscoverY2K ・その他のテストツールベンダー付録C テスト技術者の育成技術スキルステージテストプロセスステージチーム作業ステージ技術責任者ステージテスト/プロジェクト管理ステージビジネス/製品管理ステージ付録D サンプルテスト計画はじめに・目的・背景・システム概要・適用文書・マスタースケジュール役割と責任・プロジェクト組織・プロジェクトでの役割と責任・・プロジェクト管理・・機能要求事項・・ソフトウェア開発・・システムエンジニアリング・・製品保証・テスト作業構造・テストチームリソーステストプログラム・スコープ・テストアプローチ・・仮定・・テスト前提条件・・システム受け入れ基準・・リスク・テスト戦略・自動ツール・適格化手法・テスト要求事項・テスト設計・・テストプログラムモデル・・テストアーキテクチャ・・テストプロシージャ定義・・テストプロシージャ命名規約・テスト開発テスト環境・テスト環境構成管理・テストデータテスト実行・テストプログラム報告・テストプログラムメトリクス・欠陥追跡・構成管理詳細テストスケジュールテストプロシージャ開発ガイドラインテスト検証概要管理表テストプロシージャおよびテストスクリプト付録E ベストプラクティス文書化プロセス期待の管理パイロットプロジェクトテストツールの両立性チェックテストルールのアップグレードシステム設定と構成管理のベースライン化テスト環境ベースラインへのソフトウェアのインストールテストプログラムの全体的な目的単純な自動化にとどめるテストプロシージャ設計標準と開発標準自動テスト分析と手動テスト分析再利用分析テストチームと他のチームとのコミュニケーションスケジュールの両立性顧客の関与欠陥の文書化と報告自動テストの提唱者と専門家テストチームの担当割り当てユーザグループへの参加テストツールの改善提案ベータテストサイトになる特殊分野の専門家
Amazon.co.jpで購入する cbook24.comで購入するソフトウエア書籍一覧　目次	ソフトウェア職人気質人を育て、システム開発を成功へと導くための重要キーワード ISBN4-89471-441-8　　ピアソン・エデュケーション原書：Addison Wesley「Software Craftsmanship：The New Imperative」ピート・マクブリーン著村上雅章訳 A5判　　208ページ　　本体価格￥2.300　　2002/03発売 [内容] 本書で言う「職人気質」とは、ソフトウェア開発における基本への回帰である。優れたソフトウェア開発者は、プログラミングというものが熟練を要する技芸であることを常に理解している。技術者が持っている神秘的かつ詳細な技術的知識の量とは関係なく、アプリケーション開発は最後には経験と勘の世界になるからだ。ソフトウェアの芸術性に対する感覚が養われていなければ、アプリケーション開発をマスターすることなどできないのである。そこで、本書では、特定の技術に対する詳細な知識を常に鍛えておき、優れた開発者は常に新たな技術を入手して使用できるようにしておかなければならないことを説いている。　 [目次] 本書推薦の言葉まえがき訳者まえがき第1部ソフトウェア工学に対する疑問第1章ソフトウェア工学とは？ 1.1 ソフトウェア工学のパラドックス 1.2 現代におけるソフトウェア工学の定義 1.3 ソフトウェア工学は、あなたのプロジェクトに向いているか？第2章ソフトウェア工学の問題 2.1 ソフトウェア開発は体系化かつ定量化することが可能なのか？ 2.2 十分によいソフトウェアというアプローチの落とし穴 2.3 ソフトウェア工学に代わるものとは？第3章ソフトウェア開発を理解する 3.1 資本としてのソフトウェア 3.2 ソフトウェア開発において作業の分担は有効なのか？ 3.3 何にでもフィットするようなフリーサイズは存在しない 3.4 ソフトウェア工学よりも適用可能性のあるメタファを探る第4章ソフトウェア工学よりも優れたメタファを探る 4.1 ソフトウェア開発における技芸 4.2 伝統的な職人気質との類似点 4.3 ソフトウェア開発における技芸の復権第2部ソフトウェア職人気質第5章ソフトウェア開発に人を呼び戻す 5.1 職人気質はソフトウェア開発を改善するものである 5.2 職人気質によって優れたソフトウェアの記述が開発者に奨励される 5.3 武装命令第6章資格制度の対極に位置する職人気質 6.1 個人に基づく職人気質 6.2 資格制度は幻想である 6.3 個人に着目した職人気質第3部ソフトウェア職人気質がもたらすもの第7章職人気質がシステムのユーザにもたらす変化 7.1 ソフトウェアは簡単にコピーできるため、ソフトウェア職人気質が有効に機能する 7.2 職人とユーザの関係 7.3 素晴らしいソフトウェアには署名がある 7.4 職人には注文の多いユーザが必要である 7.5 ソフトウェア職人気質によって共同開発がもたらされる第8章顧客と職人の関係 8.1 現実的なリリース日の設定 8.2 十分によいソフトウェアの虚偽を暴く 8.3 ソフトウェア職人に、自身の仕事に対するクレジットを与える 8.4 開発者間の生産性の違いを利用し始めること 8.5 しかし、どのようにしたら開発者が本当に優れているかどうかを判断できるのか？ 8.6 顧客は職人選定時にコストと品質のトレード・オフを行う 8.7 顧客とソフトウェア職人の関係は長期に渡るものとなる 8.8 顧客の利益はソフトウェア職人の利益と一致する第9章職人の管理 9.1 ソフトウェア職人は下働きではない 9.2 優れた開発者は管理者よりも価値が高い 9.3 ソフトウェア職人と管理者の関係 9.4 優れた開発者を管理することは喜びであり特権である 9.5 ソフトウェア職人はアプリケーション作りが嫌いではない 9.6 ソフトウェア職人の管理は異なったものとなる 9.7 ソフトウェア職人は、自らが必要なものを得ようと努める第10章ソフトウェア職人になる 10.1 ソフトウェア職人気質は、極端な役割分担を否定する 10.2 職人気質には献身が必要 10.3 ソフトウェア職人になるには？ 10.4 伝統的な技芸は何世紀も生き続けてきた第11章技芸の熟達 11.1 ソフトウェアの熟練職人とはどのようなものか？ 11.2 古株の採用 11.3 技芸の熟達とは安定したテクノロジの使用を意味している 11.4 技芸の熟達には時間がかかる 11.5 熟達は技芸の伝承に対して責任を持つことを意味している第12章アプレンティス 12.1 開発者教育における品質の低下を打開する 12.2 アプレンティスになるのは重大なステップである 12.3 徒弟制度は生涯学習を根付かせる 12.4 アプレンティスの役割 12.5 徒弟制度は時間と努力に対する有意義な投資である第13章ジャーニーマン 13.1 技芸におけるジャーニーマンの位置づけ 13.2 ジャーニーマン開発者 13.3 ジャーニーマンはアプリケーションの調達に注力する 13.4 ジャーニーマンはソフトウェア職人気質の重要な役割を担っている第4部ソフトウェア工学の位置づけを再評価する第14章ソフトウェア工学に則ったプロジェクト 14.1 ソフトウェア工学は巨大システム・プロジェクトに対して用意されたものである 14.2 ソフトウェア工学に則ったプロジェクトは多種多様で変化に富んでいる第15章ソフトウェア工学メタファの危険性 15.1 低予算でソフトウェア工学を実行することはできない 15.2 ソフトウェア工学は科学的管理法を奨励している 15.3 ソフトウェア工場：ソフトウェアの流れ作業 15.4 長期の再利用は危険である 15.5 ソフトウェア開発の標準プロセスという神話 15.6 ソフトウェア工学は個人というものを忘れさせる 15.7 開発プロセスに必要なものは統合化ではなく、多様化である第16章ソフトウェア工学からの教訓 16.1 規模と複雑さが重要となる 16.2 アプリケーションはうまく構造化する必要がある 16.3 余裕のない変更は高価なものとなる 16.4 チーム内、およびユーザとのコミュニケーションの重要性 16.5 正確な見積もりはとても高くつく第5部土壇場になって行うこと第17章経験?プロジェクトを成功させる秘訣 17.1 ソフトウェア職人を評判に基づいて選ぶ 17.2 職人を評判とポートフォリオで評価する 17.3 ソフトウェア職人の選定 17.4 ソフトウェア職人に開発チームの他のメンバを選定させる 17.5 共同開発 17.6 最先端のテクノロジはできる限り避ける 17.7 経験に対して支払う 17.8 驚くべき成果第18章テストと保守のための設計 18.1 プロジェクトではなく、アプリケーションのことを考える 18.2 保守チームは粗悪なアプリケーションの受け取りを拒否すべきである 18.3 保守のための設計 18.4 ソフトウェア職人気質は独占されていないオープンソース・ツールを好む 18.5 優れたソフトウェアはグローバル対応している 18.6 ソフトウェア職人は計画的陳腐化と戦う必要がある 18.7 優れたソフトウェアには優れたユーザ・インタフェースが必要である 18.8 保守可能なソフトウェアは簡単に診断できる 18.9 アウトソーシングの危険性 18.10 アプリケーションを構築する際に外部の職人を用いる 18.11 保守はアプリケーションの寿命を支える最重要部分である 18.12 すべてのソフトウェアが保守可能である必要はない 18.13 テストと保守のための設計はロケット工学ではない第19章永続的な学習 19.1 学習環境を作り上げる 19.2 ソフトウェア開発における技芸の熟達 19.3 訓練コースは細心の注意を払って選択すること 19.4 ソフトウェア開発コミュニティ内で目立つことを奨励する 19.5 内省的な実践者になるエピローグ謝辞索引
Amazon.co.jpで購入する cbook24.comで購入するソフトウエア書籍一覧　目次	アジャイルソフトウェア開発 ISBN4-89471-579-1　　ピアソン・エデュケーション原書：Addison Wesley「Agile Software Development」Alistair. Cockburn　アリスター・コーバーン　著今野睦, 長瀬嘉秀, 株式会社テクノロジックアート　訳 A5判　　392ページ　　本体価格\3,200　　2002/08/30発売 [内容] 本書は比較的経験を積んだ読者向けに書かれている。本書ではソフトウェア開発の手順は扱っていない。実際に本書の中心となる考えは、「すべてのテクニックには限界がある」という認識である。ソフトウェアを開発する上で、最も正しい方法など挙げることはできない。読者がこのような認識に達し、現実に対して建設的な考えを持つようになることが、本書の理想である。ソフトウェア開発プロジェクトに携わる中レベルの実践者が、学習したルールの限界を探している場合は、以下のトピックが役立つだろう。・どのような方法論がどのようなプロジェクトに適しているか・各プロジェクトに適した方法論のカテゴリを検索するための索引・アジャイル方法論の基盤となる原則中レベルの実践者として上述の理論を適用する際は、自分の判断が必要であることを認識するだろう。高レベルの実践者なら、適用できる程度は提案によってまちまちだということに、すでに気付いている。そのことを表現する言葉を捜している場合もあるかもしれない。以下のトピックを扱っている箇所で、そのような言葉が見つけられるだろう。・コミュニケーションの不完全性の管理・継続した方法論の改善・アジャイルソフトウェア開発宣言いくつかのトピックは、高レベルのソフトウェア開発者にも目新しいと思われる。方法論を記述する語彙と、ジャストインタイムの方法論チューニングのテクニックは、これまで見たことがないだろう。－本書前書より－　そもそもアジャイル開発プロセスとは何だろう？「アジャイル開発プロセス」とはある特定の開発手法を指す言葉ではありません。「アジャイルな」とはつまり、良いものを手早く無駄なく作ることです。「アジャイル開発プロセス」という言葉はアジャイルにソフトウェアを開発することを可能にするさまざまな手法全体を指して使われています。かつては「軽量級の(lightweight)」プロセスと呼ばれていました。皆さんよくご存知のエクストリーム・プログラミングもアジャイル開発プロセスの代表的な手法の一つです。近年エクストリーム・プログラミングが日本でも急速に普及しているのと同様に、合衆国ではここ数年来エクストリーム・プログラミングを含む多くのアジャイル開発プロセスが提案され、広く利用されています。その背景には、ソフトウェア開発そのものが過去のものとは様変わりしてしまったことが上げられます。 90年代後半に至るまで、ソフトウェア開発と言えば長期間にわたり大勢の人間でコストをふんだんに使いながら作り上げていくようなものが関心を集めていました。ソフトウェア工学や多くのソフトウェア・プロジェクト管理手法もそのような種類のプロジェクトを主な対象としていたのです。しかし今やソフトウェアは、短期間にできるだけ低いコストで、なおかつ非常に複雑でオープンなものを作らなければならなくなりました。また社会状況やマーケットの変動の激しさに伴って、ソフトウェア自身に対する要求も日々刻々変わっていきます。もはや古典的なソフトウェア工学やソフトウェア・プロジェクト管理手法だけではどうにも対処できないということが誰の目にも明らかになってきました。それに対する技術的な解の一つが「オブジェクト指向」です。オブジェクト指向技術は上に挙げたようなソフトウェア開発の困難のいくつかに対処してくれましたが、同時にオブジェクトでソフトウェアを作るのにはそれに適した開発手法も必要となりました。アジャイル開発プロセスと呼ばれる手法の多くはオブジェクト技術のコミュニティから発しています(もちろん多くのアジャイル開発プロセスは非オブジェクト技術を用いたソフトウェア開発にも有効です)。一方、ソフトウェア開発の対象、つまり現実世界（金融やマーケティング、通信など）はそもそも非常に複雑な世界です。ここで「複雑」というのは、非常に小さなことが予想できない大きな影響をもたらす場合があるということです。さらにソフトウェアそのものが非常に複雑です。さらにはソフトウェアを開発するプロジェクトが非常に複雑です。このようにソフトウェア開発とは3つの複雑系が絡まり合って行われる作業です。そこでは時間も資源も有限であり、情報は不完全であり（例えば、顧客が欲しているものを完全に知ることはできない!）、将来を予見することは不可能です（例えば、ある機能を実装したらどのモジュールに影響が及ぶか完全には分からない!）。アジャイル開発プロセスの中には、このようにソフトウェア開発が複雑系を成すということを特に重要視しているものもあります。アジャイル開発プロセスは、時間とコストの制約の中で情報は不完全であり、予見は不可能であるという事実を前提とします。そしてその前提のもと、限られた範囲で合理的な答えを出すにはどうするべきかというのがアジャイル開発プロセスといってもいいかも知れません。　 [目次] まえがき序章導入：未知と伝達不能経験を解析する際の問題不可能なコミュニケーション学習の3レベル次のステップ第1章創作とコミュニケーションの協調ゲーム 1.1 ソフトウェアと詩 1.2 ソフトウェアとゲーム 1.2.1 ゲームの種類 1.2.2 ソフトウェアとロッククライミング 1.2.3 創作とコミュニケーションのゲーム 1.2.4 ソフトウェアと工学 1.2.5 ソフトウェアとモデル構築 1.3 協調ゲームに対する2番目の視点 1.3.1 コミュニケーションスペシャリストとしてのプログラマ 1.3.2 より迅速なゲーム進行 1.3.3 目印と支え 1.3.4 収益逓減 1.3.5 主目標としての充分性 1.3.6 残りの充分性 1.3.7 ゲーム内のゲーム 1.3.8 オープンソース開発 1.4 アイデアの実践第2章個人 2.1 あの愉快な人たち 2.1.1 性格的機能の探求 2.1.2 愉快さの要素 2.1.3 避けられない多様性 2.1.4 技術が効果的な場合 2.1.5 一般化の衝突 2.2 失敗モードの克服 2.2.1 間違える 2.2.2 保守的な失敗を好む 2.2.3 調べるよりも作る 2.2.4 習慣の生物である／一貫していない 2.2.5 規律と寛容による対処 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.3.9 報酬の結合 2.3.10 フィードバック 2.4 成功モードへの誘導 2.4.1 巡回が得意 2.4.2 人は学習する 2.4.3 柔軟性 2.4.4 貢献とイニシアティブ 2.4.5 成功モードの結合 2.4.6 普通の人としての英雄 2.5 次のステップ第3章チーム内のコミュニケーションと協調 3.1 情報の伝達 3.1.1 遅延と機会損失のコスト 3.1.2 仕事秒 3.1.3 浸透するコミュニケーション 3.1.4 隙間風 3.1.5 情報発信物 3.1.6 「熱い空気の理論」適用 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 敵対的なXP対友好的なXP 3.3.4 勝利のための「チーム」編成 3.3.5 カルチャーとサブカルチャー 3.4 生態系としてのチーム 3.5 次のステップ第4章方法論 4.1 ソフトウェアを出荷する生態系 4.2 方法論の概念 4.2.1 構造用語 4.2.2 スコープ 4.2.3 概念用語 4.2.5 方法論の公表 4.3 方法論の設計原則 4.3.1 共通の設計エラー 4.3.2 方法論的に成功したプロジェクト 4.3.3 作者の感性 4.3.4 7つの原則 4.4 フレームの中のXP 4.4.1 XPクイックリファレンス 4.4.2 XPの考察 4.4.3 XPの調整 4.5 なぜ方法論か 4.5.1 方法論が解決する問題 4.5.2 方法論の評価方法 4.6 次のステップ第5章アジャイルと自己適応 5.1 軽量充分 5.1.1 最小限 5.1.2 ドキュメントのすすめ 5.2 アジャイル 5.2.1 スイートスポット 5.2.2 バーチャルチームのトラブル 5.3 自己適応 5.3.1 意識的に行う反省 5.3.2 方法論拡張テクニック 5.3.3 反省会テクニック 5.4 次のステップ第6章クリスタル方法論 6.1 クリスタルファミリー 6.1.1 クリスタルの中核要素 6.2 クリスタルクリア 6.2.1 クリスタルクリアの概略 6.2.2 クリスタルクリアに関する考察 6.3 クリスタルオレンジ 6.3.1 クリスタルオレンジの概略 6.3.2 クリスタルオレンジに関する考察 6.4 クリスタルオレンジWeb 6.4.1 クリスタルオレンジWebの概略 6.4.2 クリスタルオレンジWebに関する考察 6.5 次のステップ付録A アジャイルソフトウェア開発宣言 A.1 アジャイルアライアンス A.2 宣言 A.2.1 宣言に関する考察 A.3 価値のサポート A.3.1 付録原則に関する考察付録B Naur、Ehn、武蔵 B.1 Peter Naur：理論構築としてのプログラミング B.1.1 理論構築としてのプログラミング B.1.2 「理論構築」の適用 B.2 Pelle Ehn：ヴィトゲンシュタインの言語ゲーム B.2.1 参加とスキル B.2.2 Ehnの著作に関する考察 B.3 武蔵 B.3.1 五輪書 B.3.2 ソフトウェア開発への武蔵の適用付録C 参考文献監訳者あとがき索引
Amazon.co.jpで購入する cbook24.comで購入するソフトウエア書籍一覧　目次	職業としてのソフトウェアアーキテクト Software Architecture Series ISBN4-89471-565-1　　ピアソン・エデュケーション原書：Prentice Hall「The Software Architect’s Profession：An Introduction」Marc T. Sewell/ Laura M. Sewell/ Foreword by Grady. Booch　ローラ・スウェル, マーク・スウェル　著倉骨彰　訳 A5判　　200ページ　　本体価格\2,200 　　2002/08/26発売 [内容] 本書は、建築（物）のアナロジーとしてソフトウェアをとらえ、ソフトウェアのアーキテクトの重要性を説いた本です。エンジニア（engineer）、サイエンティスト（科学者）、ビルダー（builder）、デザイナー（designer）、プログラマ（programmer）など、ソフトウェアを冠にした職種の定義があいまいで、なおかかつ実際の仕事内容も、好むと好まざるにかかわらず重複してしまい、ソフトウェアの品質やスケジュールに悪い影響がでているとの事実認識にたち、プロフェッショナルなソフトウェアアーキテクトという職業やその考え方を紹介し、教育・育成方法についても提起する本です。著者のひとりは、ソフトウェアアーキテクトとして仕事をしており、WWISA（The Worldwide Institute of Software Architects、WWISAは、ソフトウェアアーキテクトを真の職種として確立させることを目的に、1998年にアメリカで創設された非営利団体）の会長も務めています。 [目次] 第1章アナロジーからの着想・建築とソフトウェアの間に成り立つ完全なアナロジー・頭の中にメンタルイメージを作れ・アナロジーに着目することでアーキテクチャの真の姿が見えてくる・アナロジーに着目することで真の役割と目的が見えてくる・設計は、クライアントとアーキテクトのイメージの共有から始まる・アナロジーに着目することで、用語も生きてくる・アナロジーに着目することで、工程も予測可能になる・アナロジーに着目することで、ソフトウェア開発における複雑性と柔軟性の問題に対応できる・まとめ第2章アーキテクト不在の世界・ソフトウェア業界のパラドックス・真相を究明せよ・失敗事例:米国連邦航空局の行った航空管制システム開発プロジェクト・失敗事例:米国内国歳入庁の行った確定申告用紙読取処理システム開発プロジェクト・まとめ第3章アーキテクチャとは？・共通の特徴は技術・捉えどころのないものの定義・ユーティリタス、ベヌスタス、ファーミタス・デザインミステリー・調和と統一についてのサン・ピエトロ大聖堂の教訓・名前のない性質・まとめ第4章アーキテクチャの歴史から何を学ぶか・スーパースターもいれば無名の職人もいた・アーキテクチャの衰退・20世紀、アーキテクトは社会哲学者になった・アーキテクチャと第三の波・まとめ第5章ソフトウェアを構築することの意味・アーキテクト、ビルダー、エンジニア、サイエンティスト・基本的指標・ソフトウェアアーキテクトの仕事・ソフトウェアエンジニアの仕事・ビルダーの仕事・コンピュータサイエンティストの仕事・発注者（クライアント）の仕事・拘束せずに定義する・必要なのは役割の明確化・まとめ第6章ソフトウェアアーキテクトの役割・まずはクライアントの要望に耳を傾ける・クライアントのよき代弁者たれ・聞き上手になる・観察上手になる・戦略上手になる・ガラスのピラミッド事例・まとめ第7章アーキテクチャ主導のソフトウェア構築のフェーズ・設計（アーキテクチャ）フェーズにおける注意事項・設計は納品物件ではない・設計フェーズは一方通行型ではない・構築（実装）フェーズ・まとめ第8章アーキテクチャプラン・基本設計の特徴・有能なアーキテクトの定義、優れたアーキテクチャプランの定義・アーキテクチャプランが必要とされる理由・設計は概要を伝えるレベルもあれば、詳細を伝えるレベルもある・まとめ第9章ソフトウェアアーキテクトの育成・「第三の波の時代に、第二の波の時代の教育」・つまみ食い学生が急増している危機・仕事のイメージの良し悪し・コンピュータサイエンティストのプロフィール・ソフトウェアアーキテクトに必要な教育・ソフトウェアアーキテクチャ教育の確立・設計は教えられるか・まとめ第10章ソフトウェアアーキテクトという職名こそ名乗るのに相応しい・Professionの意味・クライアントがソフトウェアアーキテクトに期待するもの・通常知識の確立・教育カリキュラム・認知されることの重要性・職業倫理規定・われわれは出発点に立っている