ソフトウェア開発 201の法則（Alan M. Davis）
書籍情報
- 著者:Alan M. Davis（著）、 松原友夫（訳）
- 発行日:1996-03-22
- ISBN:9784822290023
- URL:https://www.nikkeibp.co.jp/atclpubmkt/book/96/140263/
書籍目次
- 日本版へのまえがき
- まえがき
- 感謝のことば
- 第1章 序章
- 第2章 一般原理
- 原理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 責任をとれ
- 第2章 要求分析の原理
- 原理38 いいかげんな要求仕様からはいいかげんなコスト見積もりしかできない
- 原理39 要求仕様を書く前に問題を特定せよ
- 原理40 要求について今できることは何でもやれ
- 原理41 今すぐ要求仕様書の誤りを直せ
- 原理42 プロトタイプはユーザー・インターフェース選択のリスクを減らす
- 原理43 なぜこの要求項目が含まれたかを記録せよ
- 原理44 サブセットを識別せよ
- 原理45 要求を審査せよ
- 原理46 要求分析段階で設計するな
- 原理47 正しい技法を使え
- 原理48 要求を複数の視点から見よ
- 原理49 要求仕様書を賢く編成せよ
- 原理50 要求に優先順位をつけよ
- 原理51 簡明に書け
- 原理52 どの要求項目にも別々に番号を付けよ
- 原理53 曖昧な要求記述を減らせ
- 原理54 自然言語を増やし、決して置き換えるな
- 原理55 より形式的なモデルを作る前に自然言語で書け
- 原理56 要求仕様書を常に読みやすくしておけ
- 原理57 信頼性について特に規定せよ
- 原理58 環境が「受け入れ可能な」条件を満たさない場合について規定せよ
- 原理59 未決項目は自己消滅させる注記と共に記述せよ
- 原理60 要求仕様書をデーターベースに格納せよ
- 第3章 設計の原理
- 原理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 ソフトウェア信頼性は冗長性を与えることで達成できる
- 第4章 コーディングの原理
- 原理87 トリックを使うな
- 原理88 グローバル変数を使うな
- 原理89 トップダウンで読めるように書け
- 原理90 副作用を避けよ
- 原理91 意味のある名称を使え
- 原理92 人のことを第一に考えてプログラムを書け
- 原理93 最適なデーター構造を使え
- 原理94 それを速くする前に正しいものにせよ
- 原理95 コードを仕上げる前にコメントを加えよ
- 原理96 コーディングを始める前に文書化せよ
- 原理97 すべてのコンポーネントを机上デバッグせよ
- 原理98 コードを細かく審査せよ
- 原理99 構造化機能のない言語でも使うことができる
- 原理100 構造化されたコードは必ずしもよいコードではない
- 原理101 深い入れ子を作ってはいけない
- 原理102 適切な言語を使用せよ
- 原理103 プログラミング言語を言い訳にしてはならない
- 原理104 言語についての知識はそれほど重要ではない
- 原理105 プログラムの体裁を整えよ
- 原理106 すぐコーディングを始めるな
- 第5章 テスティングの原理
- 原理107 テスト項目を要求項目と関係づけよ
- 原理108 テストを行なう時期よりずっと前にテストを計画せよ
- 原理109 自分のソフトウェアを自分でテストするな
- 原理110 自分のソフトウェアのテスト計画を自分で作成するな
- 原理111 テスティングは欠陥の存在をあらわにする
- 原理112 エラーだらけのソフトウェアは価値がないことを保証するが、かといってエラーがないこと
- 原理113 エラーを見つけてこそテストがうまくいったと言える
- 原理114 半分のエラーは15%のモジュールで発見される
- 原理115 ブラックボックス及びホワイトボックス両方のテスティングを用いよ
- 原理116 テストケースには期待される結果を含めよ
- 原理117 無効な入力をテストせよ
- 原理118 常に過負荷状態のテストをせよ
- 原理119 宇宙爆発起源説は当てはまらない
- 原理120 McCabeの複雑性尺度を使え
- 原理121 効果的なテスト完了尺度を使え
- 原理122 テスト・カバレッジを効果的に達成せよ
- 原理123 単体テスティングが済む前に統合するな
- 原理124 ソフトウェアに仕掛けを組み込め
- 原理125 エラーの原因を分析せよ
- 原理126 エラーを個人のもにするな
- 第6章 管理の原理
- 原理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 プロジェクトの事後検討会（または反省会）を実施せよ
- 第7章 製品保証の原理
- 原理173 製品保証は贅沢ではない
- 原理174 ソフトウェア構成管理手順を早期に確立せよ
- 原理175 SCMをソフトウェア・プロセスに適応させよ
- 原理176 SCMをプロジェクト管理を独立になるように組織化せよ
- 原理177 開発と製品保証の仕事を回転させよ
- 原理178 すべての中間成果物に名称とバージョン番号を与えよ
- 原理179 基準品目を制御せよ
- 原理180 すべてを保存せよ
- 原理181 すべての変更を追跡し続けよ
- 原理182 変更制御を抜かしてはいけない
- 原理183 変更要求にランクをつけ日程を立てよ
- 原理184 大規模な開発には検証と妥当性の確認(V&V)を用いよ
- 第8章 進化の原理
- 原理185 ソフトウェアは変化し続ける
- 原理186 ソフトウェアのエントロピーは増加する
- 原理187 壊れていないのなら直すな
- 原理188 現象を直すのではなく問題を直せ
- 原理189 最初に要求仕様を変更せよ
- 原理190 リリース前のエラーはリリース後のエラーを生む
- 原理191 プログラムが古ければ古いほど保守するのが難しくなる
- 原理192 言語は保守性に影響を与える
- 原理193 ときには始めからやり直す方がいい場合がある
- 原理194 最悪のコンポーネントを最初に作り直せ
- 原理195 保守は開発よりも多くのエラーを作り込む
- 原理196 変更した後には必ず回帰テストを行なえ
- 原理197 この変更は簡単だという信念が正しくない変更をもたらすことが多い
- 原理198 構造化されていないコードを構造化してもそれが改善されるとは限らない
- 原理199 最適化する前にプロファイラーを使え
- 原理200 親しさを維持せよ
- 原理201 システムの存在そのものが進化を促進する
- 訳者あとがき
- 参考文献
- 索引