大きなプログラムを作ることの難しさ
・1万行のプログラム
　1000行のプログラムの 10倍の時間 or 10倍の人手 をかければ作ることができるか？
・ できない！
　規模が10倍→作る困難さは 10倍以上

なぜか？
・「グループ作業の生産性」から
　・10人が協力して1年で完成するプログラム
　　・1人で10年後に完成→ 無意味→ グループで開発
　　・20人なら半年、40人なら3ヶ月でできるか？→ 否
　・人数が増加すると
　　→メンバー間のコミュニケーションに要する労力が 増加
　　→実質的な仕事にかけられる労力が 減少
・「ソフトウェアの信頼性」から
　・システムは、部品点数が多いほど信頼性が 低下
　　→大規模プログラムを正しく動作させること自体が困難

検証１　グループ作業の生産性(1)
(省略)

検証１　グループ作業の生産性(2)
(省略)

検証２　ソフトウェアの信頼性
(省略)

良いプログラムとは何か
・プログラムの良さの基準
(1) 正しい
(2) 使いやすい
(3) 機能が一般化されている
(4) 入力データの誤り検査が厳しい
(5) わかりやすい(読みやすい)
(6) ソースプログラムが簡潔である
(7) 修正しやすい
(8) 見通しがよい
(9) 適切にモジュール化されている
(10) 構造化されている
(11) 標準的な手法や書法を用いている
(12) 一貫した手法や書法を用いている
(13) 移植性がよい
(14) 文書化がよくなされている
(15) テストしやすい
(16) 実行速度が速い
(17) 無駄がない(効率がよい)
(18) 実行時のメモリ消費が少ない

・プログラムの良さを決める4つの因子
A. 仕様 ( specification)
B. 日程 ( schedule)
C. 適応性 ( adaptability)
D. 効率 ( efficiency)

DよりもAの方が 重要性が 高い

A. 仕様
・分かりやすい、修正しやすい、速い
　　このプログラムは良いプログラムか？
・これらがいかに良くても、
　　 使いにくければ、ユーザは受け入れない！
・良いプログラムは、まず、
　・使用目的に適した、
　・良い機能を持ち、
　・使いやすいこと
　　→これを決めるのが「 仕様」

・プログラムの「良さ」と「正しさ」
　・「良い」　→「仕様」が 優れていること
　・「正しい」→「仕様」を 正しく満たしていること
・but. (問題点)
　・プログラム作成以前に、完全な仕様を決定するのは困難
　　・プログラムの外部仕様と内部仕様は完全に分離できない
　・バグがあることを承知で、プログラムが販売・使用されている
　　・バグのないプログラムを作ることは、実用上不可能な投資と期間が必要
　　　(OSなどは、バグが根絶される前にシステムの寿命が尽きてしまう)

ここで質問
・納入先の要求仕様を満たす2つのプログラム
　A) 納期には間に合った。
　　しかし、それ以外の点では質が悪かった。
　B) 納期より1ヶ月遅れで完成した。
　　納期に遅れたこと以外は、大変素晴らしい製品だった。
　　・プログラムは洗練され、実行速度も速い。
　　・要求される以上の機能も盛り込まれている。
・どちらが良いプログラムか？

B. 日程(費用)
・仕様が大変優れたプログラム
　・完成が10年先→実用上ほとんど 意味がない
　　・プログラムは道具、その適用対象があって初めて価値を持つ
　・プログラムの良さ(仕様)
　　→「 日程」の制約の下で考えなければならない
　　　(複雑なプログラムは 費用と 時間がかかる)
・良い「仕様」とは
　・「日程(費用)」とプログラムの「作りやすさ」との
　　 トレードオフ( 妥協)で決定される

C. 適応性
・プログラムの適用対象
　・時間とともに変化
　　→プログラムも変化・成長する必要がある
　　　　　　　　　修正・改訂作業= 保守
　・適応性
　　→変化する環境に追従できる 「保守」のしやすさ
・プログラムの「 ライフ・サイクル」

　① 実用開始　　② 改正・改訂　③ 廃棄　　　 ④ 新規開発　

・プログラムにかかる費用の割合

　・新規開発 : 保守 = 1 : 2 ~ 1 : 3
・保守は効果の割に費用がかかる
　・2割の修正作業より、新規開発の方が安い
　・保守は長期にわたり、作成者とは別の人間によって行われる
・最初から保守しやすいプログラム＆文書を！

D. 効率
・プログラムの良さを決める4つの因子
A. 仕様　→ 利用者　　　の能率
B. 日程　→ 作成者　　　の能率
C. 適応性→ 保守者　　　の能率
D. 効率　→ コンピュータの能率

・効率= 実行速度、 必要記憶容量
　・効率は、「良さ」の因子の中で、最も重要性が 低い
　・初期のコンピュータ
　　・現在より数十万倍遅い
　　・メモリは数十Kバイト
　　・非常に高価
　　　→効率はプログラムの「良さ」の最重要かつ最優先
　・ハードウェアの進歩と価格低下
　　・ ムーアの法則
　　　・コンピュータの性能は18~24ヶ月で2倍になる
　　　　→効率の重要性は、低下し続ける
　　・ 人件費は、ハードウェアの価格よりずっと高い
　　　→コンピュータの能率より、人間の能率が優先されるのは当然
　　　→特殊な場合を除き、効率への配慮の必要性は低下

効率に対する考え方
・高速化への配慮
　・最も頻繁に実行される部分のみの高速化を考える
　　・ アルゴリズムレベル(オーダー)で考える
　　・コーディングレベルでの配慮は、ほとんど無意味
　　・プロファイラなどの利用
・必要記憶容量への配慮
　・必要性は、実行速度よりさらに低い
　　・メモリ価格→2年で半値
　　・1バイト、2バイトの節約は無意味
　　・巨大な配列などが不要になるかどうかというレベルで配慮
・あくまでも、 適応性への配慮が優先

まとめ
・工業製品としての良いプログラムとは
　・優れた 仕様を持つ
　　・使用目的に適した良い機能を備える
　　・ユーザーにとって使いやすい
　・ 日程( 費用)という制約が考慮された設計になっている
　　・いくら優れた仕様でも、期限内に完成できなければ意味がない
　・利用環境の変化に追従できる 適応性を持つ
　　・保守しやすい構造と適切なドキュメントの整備
　・効率に対する過度な配慮は 不要
　　・ハードウェアは日々進歩→コーディングレベルの配慮は無意味
　　・実行効率はアルゴリズムレベルでの改善を

この授業を終えるに当たって
・職業的プログラマ = professional programmer
・professionalとは
　職業人として
　・実力と広い視野を身につけていること
　・誇りを持っていること
　・厳しい倫理観を持っていること
　・変化に柔軟に対応できること
　　・変化を楽しむ→新しいことへの挑戦
　・そして、何より WILL(意志) を持っていること
　　・意志のないところからは、何も生まれない！