人月の神話

読んだのでメモしたことを記載していく。

p14 見積もりとスケジューリングに使われる「人月」そのものの間違い
　　→コストは実際に人数と月数の積に比例するが、進捗はそうではない
p18 往来の方法でスケジュールされたプロジェクトを検証
　　→たいていスケジュールの半分がテストに使われる
p19 シェフの例
p23 遅れているソフトウェアプロジェクトへの要員追加は、さらにプロジェクトを遅らせるだけだ
p26 プログラマ の生産性
p28 ミルズの案
p36 コンセプトの安全性
p38 ムーアズ TRAC言語 ALGOL68
　　 システムにおけるコンセプトの安全性こそが使いやすさを決定するもの

p308 訳語
　　　アーキテクチャ→外部設計局面
　　　インプリメンテーション→内部設計局面（実装というときにも使ってそう）
　　　実現→プログラミング局面

p44 安全に定義されたメモリスペースと機械の実行処理時間の目標
p50 Stretch 二度目のシステムが危ない（セカンドシステム症候群）→機械xにはmbiteとnマイクロ秒の値割当

p51 コアダンプ→実行中プログラムがエラーで強制終了する際にその時点でプログラムが使用してるメモリ空間の内容をまるごと写し取ってファイルに保存したもの
　　スナップショット→ある時点のソースこーそやファイル・ディレクトリ・データベース・ファイルなどの状態を抜き出したもの
　　インタープリタ→「通訳者」の意。コンピュータでプログラム実行する方法の１つ
　　IBM7030(Stretch) IBM最初のスパコン構築の試み

p56 マニュアルとは製品の外部仕様書
p58 バッカスーナウア記法
p60 週次ミーティングと全体会議
p68 バベルプロジェクトの失敗原因→コミュニケーションの欠落
p70 プロジェクト手引書→それぞれに分かれた文書というよりも、プロジェクトが生産する何かについてそれを文書として構造化したもの
p74 才能はさまざまな組み合わせによって、それぞれ違って発揮される
p76 ロバート・ハインライン「月を売った男」
p82 労力 = （定数）× (命令の数)1.5 PERT図
p90 プロラムサイズのコントロール

p92 オーバーレイ→物理メモリで処理できないほど大きなプログラムを実行する場合、機能ごとに分類し、細かく管理、制御すること
p93 実現者自身の姿勢の問題がある トータルシステム的な利用者志向の心構えを養うことが、プログラミングマネージャーの最も重要な役割と言えるかもしれない
p100 ソフトウェアプロジェクトのための文書について
p106 システム１つは駄目にするつもりで作成しなければならない
p111 前のリリースで発見された古いバグは、新しいリリースで再び発生する傾向がある
p113 プログラムメンテナンスはエントロピーが増加する過程がある
p116 （ボロクソ）
p121 mcframe
p124 対話型プログラミング→入力のためにIFに対話形式を採用しているプログラム
　　 高水準言語→人間にとって理解しやすい構文で書かれている言語
p130 コードができあがるずっと前に、仕様書は外部のテストグループへ渡し、完成度と明瞭さについて詳細に調べてもらわなければならない トップダウンのデザイン
p134 対話型デバッグ（1959）
p154 関連文書の重要性
p168 銀の弾を探し求める どこにも見当たらない
p173 ソフトウェア製品はアプリケーションや利用者、慣習および機械機器（媒体）といた文化的マトリックスにはめ込まれている
　　 偶有的困難⇄本質的困難
　　↑副次的、付随の（p198）
p177 Ada（プログラミング言語）
p187 1950〜1960の研究。利用者は給与管理や在庫管理、会計管理などに店頭パッケージを使いたがらないことが示された→その後変化
p190 プログラムは書くのではなく、構築する
p192 わくわくさせる製品

パワポも作ったから機会があれば会社で話す予定。