目次
第1章 派生開発の現状
- 1.1 派生開発でのトラブル
- 1.1.1 動いていたシステムが止まる
- 1.1.2 わずかな変更でも納期をはずす
- 1.1.3 結合して動かしてみると動かない
- 1.1.4 変更モレが頻繁に発生している
- 1.1.5 デバッグの仕方がおかしい
- 1.1.6 納期が先に決まっていることがおかしい？
- 1.2 派生開発はなぜ失敗を繰り返すのか？
- 1.2.1 変更要求をつかんでいない
- 1.2.2 全体を理解しようとして失敗している
- 1.2.3 派生開発の特徴を理解していない
- 1.2.4 市場トラブルを通常のデバッグプロセスで対応している
- 1.2.5 一人プロジェクトの問題
- 1.2.6 疑似一人プロジェクトも起きている
- 1.2.7 「間に合わないモンスター」の襲来
- 1.2.8 データをとっていない
- 1.2.9 他人のソースを簡単に理解できるか
- 1.2.10 崩れた設計思想
- 1.2.11 忘れられた保守性などの品質要求
- 1.2.12 恐怖の「ドラえもんのポケット」
- 1.2.13 スペックアウトの技術を持たない
- 1.2.14 ソースコードの変更が早すぎる
- 1.2.15 潜在バグの意味
- 1.2.16 どこを変更したのか誰も知らない
- 1.2.17 インクリメンタルモデルでも失敗する
- 1.2.18 複雑なコンフリクトに対応できていない
- 1.2.19 既存の分析・設計技法はすべて新規開発向け
- 1.2.20 「新規開発崩し」で混乱している
- 1.2.21 構成管理を崩壊させる
- 1.2.22 CMMでの取り組みの誤り
- 1.2.23 思考を止めた組織
第2章 派生開発プロセス「XDDP」の提案
- 2.1 XDDPの誕生
- 2.1.1 厳密な変更制御
- 2.1.2 変更した行数からわかること
- 2.1.3 データをとることで見えてくること
- 2.1.4 派生開発での特徴を知る
- 2.1.5 「部分理解」を克服する
- 2.1.6 派生開発に特化したプロセスを提案
- 2.2 ライフサイクルモデルとしてのXDDP
- 2.2.1 ウォーターフォールモデルからインクリメンタルモデルへ
- 2.2.2 派生開発専用のライフサイクルモデル
- 2.3 「変更要求仕様書」の導入
- 2.3.1 変更内容や変更箇所を特定するための文書
- 2.3.2 変更箇所に関する情報を提供
- 2.3.3 ソースコードを“変更仕様”として扱う理由
- 2.4 2つのPFD
- 2.4.1 変更要求と機能追加要求で求められること
- 2.4.2 変更要求用のPFD
- 2.4.3 機能追加用のPFD
- 2.4.4 “差分”に徹する
- 2.5 XDDPの成果物
- 2.5.1 変更要求仕様書
- 2.5.2 追加機能要求仕様書
- 2.5.3 トレーサビリティ・マトリクス
- 2.5.4 インパクト・マトリクスとの違い
- 2.5.5 変更設計書
- 2.5.6 その他の成果物
- 2.6 変更用PFDの各プロセスの説明
- 2.6.1 変更要求項目を仕様書に記述する
- 2.6.2 ソース等を調査しながら変更仕様を抽出する
- 2.6.3 追加機能の変更要求仕様書を作成する
- 2.6.4 変更要求TMを作成する
- 2.6.5 変更設計書を作成する
- 2.6.6 ソースコードを変更する
- 2.7 追加用PFDの各プロセスの説明
- 2.7.1 追加機能用の要求仕様書を作成する
- 2.7.2 追加機能を設計する
- 2.7.3 追加機能の関数設計書を作成する
- 2.7.4 追加機能のソースコードを書く
- 2.8 XDDPとソフトウェアエンジニアリング
- 2.8.1 XDDPは100％近い成功率を誇る
- 2.8.2 変更用PFDは基本的にはウォーターフォールの変形
- 2.8.3 追加用PFDのプロセスは選択可能
第3章 XDDPによる変更のプロセス
- 3.1 変更要求をまとめる
- 3.1.1 変更依頼の内容を変更要求と変更仕様に振り分ける
- 3.1.2 カテゴリに分類する
- 3.1.3 「before」「after」で“変更要求”を表現する
- 3.1.4 変更要求も「範囲」を持つ
- 3.1.5 変更する“理由”が必要なわけ
- 3.1.6 変更要求を分割・階層化する
- 3.1.7 変更要求における分割基準
- 3.1.8 下位層の変更要求にも「理由」が必要
- 3.1.9 必要なら変更要求をグループ分けする
- 3.1.10 変更依頼が「仕様」でされることへの対応
- 3.1.11 変更仕様にふさわしい変更要求を立てる
- 3.1.12 積み残しのバグを変更要求として対応
- 3.1.13 変更でいくか追加でいくか
- 3.2 ソースコードから変更仕様を探す
- 3.2.1 文書やソースファイルの情報を整理する
- 3.2.2 変更要求単位で該当箇所を探す
- 3.2.3 ソースコードを探して変更仕様を拾う
- 3.2.4 スペックアウトで変更仕様を拾う
- 3.2.5 スペックアウト作業の注意
- 3.2.6 システムのアーキテクチャを確認する
- 3.2.7 仕様も「before」と「after」を表現する
- 3.3 関連文書から変更仕様を探す
- 3.3.1 ベースとなる機能仕様書などから変更仕様を拾う
- 3.3.2 関連箇所を漏らさない工夫
- 3.3.3 TMにマークしてから，あとでソースコード上で確認する
- 3.3.4 変更要求仕様書でテストケースを更新する
- 3.3.5 変更内容に応じた耐性を確認するテストが可能
- 3.4 追加の機能仕様から変更仕様を探す
- 3.4.1 機能追加を“変更”としても扱う
- 3.4.2 機能追加の実現方法を明らかにする
- 3.4.3 変更要求仕様と追加要求仕様書との連携
- 3.5 変更仕様の抽出時に注意が必要なこと
- 3.5.1 変更要求の下に変更仕様を記述する
- 3.5.2 仕様変更としての追加と削除
- 3.5.3 意外と書けない「before」「after」
- 3.5.4 変更要求の表現が適切でないと変更仕様が拾えない
- 3.5.5 完成後の機能仕様を作ってみることも
- 3.5.6 補助資料の効能
- 3.5.7 グループ化で変更のテーマを整える
- 3.5.8 先にグループを設定する効果
- 3.5.9 変更内容を文章で書くことが難しい？
- 3.5.10 変更要求仕様にソースを書かない理由
- 3.6 変更要求TMを作成する
- 3.6.1 列方向に持ってくるもの
- 3.6.2 クラス名では小さすぎる
- 3.6.3 TMの「列」情報を固定する効果
- 3.6.4 XDDPの“要”としての役割
- 3.6.5 変更要求TMにマークする
- 3.6.6 新規開発時に作るトレーサビリティ・マトリクスとの関係
- 3.6.7 トレーサビリティ・マトリクスにこだわる理由
- 3.6.8 理解の食い違いに気づく
- 3.6.9 「TM」部分は省かれる傾向がある
- 3.7 変更方法を変更設計書にまとめる
- 3.7.1 変更設計書に記入すること
- 3.7.2 変更方法を文章で書く
- 3.7.3 異なる変更仕様で同じ関数に変更が重なるケース
- 3.7.4 変更で新たな関数が作られるケース
- 3.7.5 変更設計書はいつ書くのか？
- 3.7.6 間違った変更を防止する最後の砦
- 3.7.7 変更方法の適正さを検証するための単体テスト
- 3.7.8 マージできるだけの情報があればよい
- 3.7.9 変更仕様の粒度の問題
- 3.7.10 バグも書き残す
- 3.8 ソースコードの変更は足並みを揃える
- 3.8.1 抜けがけ禁止のルール
- 3.8.2 ソースファイル単位に集める
- 3.8.3 3度目の訪問
- 3.8.4 ソースファイルを共有しているケース
- 3.8.5 変更作業に費やした時間を記録する
- 3.8.6 書き直しがない
- 3.8.7 変更後の単体テスト
- 3.8.8 ソースコードの合体
- 3.8.9 ソースコード変更後にすること
第4章 追加のプロセスとXDDPを支えるものたち
- 4.1 機能追加のプロセス
- 4.1.1 追加機能要求仕様書を作成する
- 4.1.2 仕様間の衝突に注意する
- 4.1.3 変更要求仕様書と要求番号でつなぐ
- 4.1.4 追加機能だけで設計を進める
- 4.1.5 機能追加分のTM（トレーサビリティ・マトリクス）を作る
- 4.2 移植を扱う
- 4.2.1 移植は“機能追加”の変形
- 4.2.2 2種類の変更仕様で対応する
- 4.2.3 仕様の確認を忘れずに
- 4.2.4 機能の一部を流用するケース
- 4.2.5 ペーストシンドロームを回避する
- 4.3 派生開発における品質要求のあり方
- 4.3.1 追加機能に対する品質要求
- 4.3.2 変更要求に対する品質要求
- 4.4 XDDPにおけるレビュー
- 4.4.1 3つの成果物の役割とレビューポイント
- 4.4.2 What−Where−How の関係
- 4.4.3 変更要求仕様でのレビュー
- 4.4.4 追加機能要求仕様書のレビュー
- 4.4.5 トレーサビリティ・マトリクス（TM）でのレビュー
- 4.4.6 変更設計書でのレビュー
- 4.4.7 その他の成果物のレビュー
- 4.4.8 変更作業をストップさせる
- 4.4.9 一人プロジェクトでのレビュー
- 4.4.10 レビューの効果
- 4.5 XDDPにおける要件管理
- 4.5.1 派生開発での要件変更の難しさ
- 4.5.2 派生開発における要求仕様書のベースライン設定
- 4.5.3 ベースライン設定後の変更の可能性は減っている
- 4.5.4 追加機能への変更は変更仕様も変わる可能性がある
- 4.5.5 慎重な要件管理で対応する
- 4.5.6 CCBに最終決定権を持たせる
- 4.5.7 一人プロジェクトにおける要件管理
- 4.5.8 暫定仕様に対する仕様変更
- 4.5.9 変更が仕様で届いたときの対応
- 4.5.10 作業の中断に工夫が必要
- 4.5.11 追跡リストへの登録と運用
- 4.5.12 もう一つの追跡リストの活用
- 4.5.13 ぎりぎりまでソースコードを変更していないことの効果
- 4.6 ドキュメントの維持
- 4.6.1 公式文書はテスト中に差分によってマージする
- 4.6.2 機能仕様書に戻す
- 4.6.3 スペックアウト文書の扱い
- 4.7 サイズ見積りについて
- 4.7.1 変更要求からソースコードの変更規模を見積る
- 4.7.2 「before」「after」が見積りの根拠となる
- 4.7.3 変更要求仕様書を書いたあとのサイズ見積りの調整
- 4.7.4 変更要求TMのセルをサイズ見積りにも活用する
- 4.7.5 変更設計書でさらに調整する
- 4.7.6 見積り値と実績値の乖離の意味
- 4.8 XDDPのプロセスを変化させる
- 4.8.1 PFDを使ったプロセスの表現
- 4.8.2 PFDはシミュレーションの道具
- 4.8.3 リファクタリングとのコラボレーション
- 4.8.4 共通のベースから複数の並行開発も可能
- 4.8.5 インクリメンタル開発も派生開発の特性を持つ
- 4.9 運用時の注意
- 4.9.1 1回目のコンサルティングでの成功を勘違いしない
- 4.9.2 文書を減らそうという圧力に対抗すること
- 4.9.3 サイズ見積りも計測も省かない
- 4.9.4 親和性に注意
- 4.9.5 「原典」に戻って
- 4.9.6 偽装工夫に注意すること
第5章 XDDPの効果
- 5.1 とても間に合わない……と思われたのに
- 5.2 XDDPで納期が遅れない理由
- 5.3 工数が大幅に短縮する仕組み
- 5.4 バグの件数からも大幅な時間の削減が可能
- 5.5 仕様変更と変更ミスの大幅な減少
- 5.6 バグの根源を絶っている
- 5.7 レビューでバグの過半が発見される
- 5.8 デバッグ時にも大きな効果が得られる
- 5.9 「デスマーチ」から脱出できる
- 5.10 一人プロジェクトでも失敗しない
- 5.11 アウトソース先と連携する
- 5.12 次のプロジェクトへの準備ができる
- 5.13 将来への備え
- 5.14 日本版SOX法への対応
- 5.15 ソフト以外への応用