ソフトウェア開発を成功に納める秘訣は、失敗する確率をいかに低くするかということです。
 失敗の確率を下げるためには、自らが失敗を侵してから改善するのではなく、多くの人の教訓を取り入れることが大切だと考えています。
 ここで紹介する鉄則は、多くのソフトウェアエンジニアの長年の経験から培われた、知識や知恵によるものです。


  一般原理
  原理1 品質第一主義
  原理2 品質の定義は見る人によって異なる
  原理3 生産性と品質は不可分である
  原理4 高品質のソフトウェアは可能である
  原理5 品質を後からとってつけるようなことはするな
  原理6 信頼性が低いソフトウェアは性能が悪いソフトウェアより手に負えない
  原理7 製品のプロトタイプを早めに顧客に納めよ
  原理8 顧客やユーザーとよく話し合え
  原理9 開発者と顧客の見返りを合わせよ
  原理10 1つは放棄するつもりでいよ
  原理11 適切な形のプロトタイプを開発せよ
  原理12 プロトタイプに適切な機能を組み込め
  原理13 使い捨て型のプロトタイプは手早く作れ
  原理14 システムを漸進的に成長させるように計画せよ
  原理15 見れば見るほどもっとよいものが欲しくなる
  原理16 開発期間中の変更は避けられない
  原理17 可能なら開発するより購入せよ
  原理18 ユーザー用のマニュアルが短くて済むようにソフトウェアを作成せよ
  原理19 どんな複雑な問題にも解決策はあると思うのは誤り
  原理20 仮定を記録せよ
  原理21 異なるフェーズには異なる言語を
  原理22 ツールを使う前に技法を学べ
  原理23 ツールを使え、ただし現実的に
  原理24 ソフトウェア・ツールを優れた技術者に与えよ
  原理25 CASEツールは高価である
  原理26 「 いつ使うかを知る 」 ことは、どう使うかを知ることと同じくらい重要だ
  原理27 目標を達成したらそこで止めよ
  原理28 形式的手法を知れ
  原理29 組織の評価と個人の評価を合わせよ
  原理30 レミング( 一時の流行 )には心して従え
  原理31 新技術を無視するな
  原理32 文書化規格を使え
  原理33 どの文書にも用語集が必要だ
  原理34 どの文書にも索引が必要だ
  原理35 同じ概念には同じ名称を使え
  原理36 研究が終わってからの技術移転はうまくいかない
  原理37 責任をとれ
     
  要求分析の原理
  原理38 いいかげんな要求仕様からはいいかげんなコスト見積もりしかできない
  原理39 要求仕様を書く前に問題を特定せよ
  原理40 要求について今できることは何でもやれ
  原理41 今すぐ要求仕様書の誤りを直せ
  原理42 プロトタイプはユーザー・インタフェース選択のリスクを減らす
  原理43 なぜこの要求項目が含まれたかを記録せよ
  原理44 サブセットを識別せよ
  原理45 要求仕様を審査せよ
  原理46 要求分析段階で設計するな
  原理47 正しい技法を使え
  原理48 要求を複数の視点から見よ
  原理49 要求仕様書を賢く編成せよ
  原理50 要求に優先順位をつけよ
  原理51 簡明に書け
  原理52 どの要求項目にも識別に番号を付けよ
  原理53 曖昧な要求記述を減らせ
  原理54 自然言語を強化し、決して置き換えるな
  原理55 より形式的なモデルを作る前に自然言語で書け
  原理56 要求仕様書を常に読みやすくしておけ
  原理57 信頼性について特に規定せよ
  原理58 環境が「 受け入れ可能な 」 条件を満たさない場合に規定せよ
  原理59 未決項目は自己消滅させる注記と共に記述せよ
  原理60 要求仕様書をデータベースに格納せよ
     
  設計の原理
  原理61 要求仕様から設計への移行は容易ではない
  原理62 設計から要求項目を追跡せよ
  原理63 代替案を評価せよ
  原理64 文書のない設計は設計とは言わない
  原理65 カプセル化せよ
  原理66 同じものを何度も発明するな
  原理67 単純に作れ
  原理68 特殊なケースをあまりたくさん作るな
  原理69 知的な距離を最小にせよ
  原理70 設計を知的コントロールの下に置け
  原理71 概念の完全性を維持せよ
  原理72 概念上の誤りは文脈上の誤りよりも深刻である
  原理73 カップリングとコヒージョンを使え
  原理74 変更が容易なように設計せよ
  原理75 保守が容易なように設計せよ
  原理76 エラー修正が容易なように設計せよ
  原理77 ソフトウェアに普遍性を組み込め
  原理78 ソフトウェアに柔軟性を組み込め
  原理79 効率のよいアルゴリズムを用いよ
  原理80 モジュール仕様書にはユーザーが必要な情報はすべて書き、それ以外は書くな
  原理81 設計は多次元的だ
  原理82 優れた設計は優れた設計者が創り出す
  原理83 アプリケーションを熟知せよ
  原理84 巨額の投資をしないでも再利用はできる
  原理85 「 ガーベッジ・イン、ガーベッジ・アウト 」 は正しくない
  原理86 ソフトウェア信頼性は冗長性を与えることで達成できる
     
  コーディングの原理
  原理87 トリックを使うな
  原理88 グローバル関数を使うな
  原理89 トップダウンで読めるように書け
  原理90 副作用を避けよ
  原理91 意味のある名称を使え
  原理92 人のこと第一に考えてプログラムを書け
  原理93 最適なデータ構造を使え
  原理94 それを速くする前に正しいものにせよ
  原理95 コードを仕上げる前にコメントを加えよ
  原理96 コーディングを始める前に文書化せよ
  原理97 すべてのコンポーネントを机上でデバッグせよ
  原理98 コードを細かく審査せよ
  原理99 構造化機能のない言語でも使うことができる
  原理100 構造化されたコードは必ずしもよいコードではない
  原理101 深い入れ子を作ってはいけない
  原理102 適切な言語を使用せよ
  原理103 プログラミング言語を言い訳にしてはならない
  原理104 言語についての知識はそれほど重要ではない
  原理105 プログラムの体裁を整えよ
  原理106 すぐコーディングを始めるな
     
  テスティングの原理
  原理107 テスト項目を要求項目と関係づけよ
  原理108 テストを行う時期よりずっと前にテストを計画せよ
  原理109 自分のソフトウェアを自分でテストするな
  原理110 自分のソフトウェアのテスト計画を自分で作成するな
  原理111 テスティングは結果の存在をあらわにするだけだ
  原理112 エラーだらけのソフトウェアが価値がないことを保証するが、エラーがないことと
そのソフトウェアの価値は無関係である
  原理113 エラーを見つけてこそテストがうまくいったと言える
  原理114 半分のエラーは15%のモジュールで発見される
  原理115 ホワイトボックス及びブラックボックス両方のテスティングを用いよ
  原理116 テストケースには期待される結果を含めよ
  原理117 無効な入力をテストせよ
  原理118 常に過不可状態のテストをせよ
  原理119 ビッグバン説はあてはまらない
  原理120 McCabeの複雑性尺度を使え
  原理121 コカ的なテスト完了尺度を使え
  原理122 テスト・カバレッジを効果的に達成せよ
  原理123 単体テスティングが済む前に統合するな
  原理124 ソフトウェアに仕掛けを組み込め
  原理125 エラーの原因を分析せよ
  原理126 エラーを個人のものにするな
     
  管理の原理
  原理127 優れた管理は優れた技術よりもずっと重要だ
  原理128 適切な解決策を用いよ
  原理129 読んだことのすべてを信じるな
  原理130 顧客の優先順位を理解せよ
  原理131 人材こそ成功への鍵だ
  原理132 少数精鋭はスキルの低い人々による人海戦術よりずっとよい
  原理133 部下の話をよく聞け
  原理134 部下を信頼せよ
  原理135 すばらしい仕事を期待せよ
  原理136 うまく話し合う技術は必須である
  原理137 水運びの仕事をせよ
  原理138 人は思いもよらない動機で仕事をしている
  原理139 オフィスを静かに保て
  原理140 人員と時間は交換できない
  原理141 ソフトウェア技術者の能力差は大きい
  原理142 望んだ目標に最適化できる
  原理143 押し付けがましいデーターの集め方をするな
  原理144 1行当たりのコストは役に立たない
  原理145 生産性を計測する完全な方法はない
  原理146 特別誂えのコスト見積もりモデルを作れ
  原理147 非現実的な完成予定日を設定するな
  原理148 不可能なことをするな
  原理149 数える前に知れ
  原理150 生産性データーを収集せよ
  原理151 チームの生産性を忘れるな
  原理152 人月当たり行数は言語に関係しない
  原理153 日程を信じよ
  原理154 正確に積み上げられたコスト見積もりでも正しいとは限らない
  原理155 日程を定期的に見直せ
  原理156 少しくらいの過少見積もりは常に悪いとは限らない
  原理157 適切な資源を割り当てよ
  原理158 プロジェクトを詳細に計画せよ
  原理159 計画を常に更新せよ
  原理160 増幅する波のような計画変更の繰り返しをするな
  原理161 上位10のリスク項目を知れ
  原理162 直面するリスクを理解せよ
  原理163 適切なプロセス・モデルを使え
  原理164 手法はあなたを救いはしない
  原理165 奇蹟的な生産性の情報には秘密はない
  原理166 進歩が何を意味するかを知れ
  原理167 計画とのずれにより管理せよ
  原理168 ハードウェアに過大な負担をかけるな
  原理169 ハードウェアの進化には楽天的であれ
  原理170 ソフトウェアの進化には悲観的であれ
  原理171 大混乱など起こるはずがないという考えがしばしば大混乱をもたらす
  原理172 プロジェクトの事後検討会( または反省会 )を実施せよ
     
  製品保証の原理
  原理173 製品保証は贅沢ではない
  原理174 ソフトウェア構成管理手順を早期に確率せよ
  原理175 SCMをソフトウェア・プロセスに適応せよ
  原理176 SCMをプロジェクト管理から独立するように組織化せよ
  原理177 開発と製品保証の仕事の間を行き来させよ
  原理178 すべての中間成果物に名称とバージョン番号を与えよ
  原理179 基準品目を制御せよ
  原理180 すべてを保存せよ
  原理181 すべての変更を追跡し続けよ
  原理182 変更制御を抜かしてはいけない
  原理183 変更要求にランクをつけ日程を立てよ
  原理184 大規模な開発には検証と妥当性の確認( V&V )を用いよ
     
  進化の原理
  原理185 ソフトウェアは変化し続ける
  原理186 ソフトウェアのエントロピーは増加する
  原理187 壊れていないのなら直すな
  原理188 現象を直すのではなく問題を直せ
  原理189 最初に要求使用を変更せよ
  原理190 リリース前のエラーはリリース後のエラーを生む
  原理191 プログラムは古くなればなるほど保守するのが難しくなる
  原理192 言語は保守性に影響を与える
  原理193 ときには始めからやり直す方がいい場合がある
  原理194 最悪のコンポーネントを最初に作り直せ
  原理195 保守は開発よりも多くのエラーを作り込む
  原理196 変更した後には必ず回帰テストを行え
  原理197 この変更は簡単だという信念が正しくない変更をもたらすことが多い
  原理198 構造化されていないコードを構造化してもそれが改善されるとは限らない
  原理199 最適化する前にプロファイラーを使え
  原理200 親密さを維持せよ
  原理201 システムの存在そのものが進化を促進する