第1章 ソフトウェアの開発

• 1・1 ソフトウェア開発の手順
• 1・2 ソフトウェアの設計
  • 1・2・1 基本設計
  • 1・2・2 機能設計
  • 1・2・3 詳細設計
• 1・3 ソフトウェアの開発と製造
  • 1・3・1 プログラミング
  • 1・3・2 テスト仕様書
  • 1・3・3 プログラム変更管理
  • 1・3・4 テスト進捗管理

第2章 管理とは何か

• 2・1 管理に対する考え方
• 2・2 開発工程と管理

第3章 開発と管理

• 3・1 開発管理で用いるドキュメント
  • 3・1・1 アローダイアグラム（作戦遂行戦略図）
  • 3・1・2 工程管理表
  • 3・1・3 テスト進捗管理（バグ発生/テスト消化曲線）
  • 3・1・4 目標設定
• 3・2 アローダイアグラム
  • 3・2・1 アローダイアグラムの利用
  • 3・2・2 アローダイアグラムを利用する上でのポイント
• 3・3 目標の設定
  • 3・3・1 プログラミング
  • 3・3・2 テスト項目
  • 3・3・3 摘出不良件数
• 3・4 開発管理マスタードキュメント
  • 3・4・1 工程管理表
  • 3・4・2 ILUO（モジュール関連図）管理
• 3・5 テスト進捗管理
  • 3・5・1 テスト進捗管理の事例
  • 3・5・2 発生/テスト消化曲線でのテスト進捗管理のポイント

第4章 品質と管理

• 4・1 品質の管理
• 4・2 品質とコスト
• 4・3 不良の分析
  • 4・3・1 プログラム変更管理表
  • 4・3・2 不良摘出状況分析/予測

第5章 開発における実践アドバイス

• 5・1 設計段階
  • 5・1・1 アローダイアグラムの日程は逆から立てる
  • 5・1・2 アローダイアグラムの項目ははっきりと記載する
  • 5・1・3 作業ステップ数はプログラム開発の基準値である
• 5・2 プログラミング段階
  • 5・2・1 きれいなプログラムには不良が少ない
  • 5・2・2 プログラムの先頭にはヘッダコメントをつける
  • 5・2・3 コメントは重要な仕様書である
  • 5・2・4 プログラムの入口/出口は1カ所にまとめる
  • 5・2・5 プログラムのステップ数は，50ステップを目安にする
  • 5・2・6 インデンティングはあまり深くしない
  • 5・2・7 例外処理，異常処理はメイン処理の外に置く
  • 5・2・8 アセンブラ言語で記述することをおそれてはいけない
  • 5・2・9 罠を張るプログラムを仕込んでおく
  • 5・2・10 重要な処理についてはシミュレーションを行う
  • 5・2・11 チューニングは諸条件を考慮して注意深く行う
  • 5・2・12 作業エリアの定義は正確に行う
  • 5・2・13 ソースの管理は体系的に行う
• 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・3・13 入力データは，許されない物もテストしておく
  • 5・3・14 モンキーオペレーションも重要なテスト方法である
  • 5・3・15 テスト結果の判定は正確に行う
  • 5・3・16 不良が発生したら分析を行う
  • 5・3・17 類似の不良はステップ数と同じだけあると考える
  • 5・3・18 「1と3の法則」に注意する
  • 5・3・19 不良の修正では，現象対策ではなく根本原因対策を行う
  • 5・3・20 プログラムの修正は完全を期して行う
  • 5・3・21 プログラムの変更管理は省かない
  • 5・3・22 自前ツールの開発は怠りなく行っておく
• 5・4 管理者としての心構え
  • 5・4・1 プロジェクト管理者は，そのあり方を自ら問うべし
  • 5・4・2 プロジェクトの開発能力を把握するように努める
  • 5・4・3 開発者の技術能力の差を平準化するように努める
  • 5・4・4 開発者が達成可能な目標値を定め，「挑戦」する
  • 5・4・5 技術能力は個人個人で違い，1人＝1人とはいえない
  • 5・4・6 つねに新しい試みを行うようにする
  • 5・4・7 管理者は，いつも攻撃的であれ
  • 5・4・8 油断はプロジェクトを混乱させる
  • 5・4・9 数字がすべてを物語るとは限らない
  • 5・4・10 管理はビジュアルに行う
  • 5・4・11 プロジェクト推進には3つの「山」がある
  • 5・4・12 突き当たった「壁」を知るには，ボールを投げてみる
  • 5・4・13 決断にはリスクがあることを認識しておく
  • 5・4・14 プログラムを切り捨てることも管理者の仕事である
  • 5・4・15 遅延を取り戻す特効薬はない
  • 5・4・16 分析ができない管理者は去れ
  • 5・4・17 過去の失敗は成功への扉の鍵として活かす
  • 5・4・18 ソフトウェアは，システムの総仕上げをするものである
  • 5・4・19 プログラムの最終評価は，使用する顧客が下す
  • 5・4・20 プログラムの品質という物を考え直してみる