ソフトウェア開発の困難性

ソフトウェア工学誕生までの歴史（History of SE）

• 1942〜46 コンピュータの軍事利用（暗号解読，弾道計算，リレーによるプログラミング）
• 1949 プログラム内蔵方式（EDSAC）
• 1953〜54 基本ソフトウェア
• 1955 FORTRAN
• 1960 ALGOL, COBOL, LISP
• 1964 IBM System/360 (OS/360)
• 1968 NATO の国際会議「ソフトウェア工学」

ソフトウェア危機とソフトウェア工学（Software Crisis）

ソフトウェア危機

• 汎用化によりハードウェアよりもソフトウェアを重視
• ソフトウェア開発需要の増加と技術者の不足
  • 予定期間・コストの超過
  • 品質の低いソフトウェア

ソフトウェア工学

• ソフトウェアを工業製品として設計・開発する技術
• 定義 (IEEE Std 610-1990)
  • ソフトウェアの開発，運用，保守に対する，系統的で統制され定量化可能な方法．すなわちソフトウェアへの工学の適用．
  • 上記のような方法の研究．

ソフトウェア開発体制（Software Development Organizations）

• チームによるプロジェクト
  • 「早く行きたければ一人で行け．遠くまで行きたければ皆で行け」（アフリカのことわざ）

なにが難しいのか？（What are Issues?）

• Frederick P. Brooks の分析（IBM OS/360 の開発者）
• OS/360 開発プロジェクトの失敗を経て分析
  結論：規模の大きなソフトウェアを作るのは難しい
  • 目に見えないものは管理できない（完成度が見えない）
  • 変化させやすいものは管理が難しい（「これで最後」がない）
  • 絶対的な制約のないものは管理が難しい（物理制約がない）

• 建設プロジェクトと対比・・
  • 基礎，骨組み，・・などが目に見える
  • 完成したら変化させることは容易でない
  • 物理的な制約を無視して屋根から先に作れない

ブランコの例

ブランコの例（ユーザ要求; User requirement）

ブランコの例（製品仕様; Specifications）

ブランコの例（設計; Design）

ブランコの例（実装; Implementation）

ブランコの例（テスト; Testing）

ブランコの例（本当に必要なもの; The truth）

ブランコの例（別バージョン）

なにが難しいのか？（再掲）

• Frederick P. Brooks の分析（IBM OS/360 の開発者）
• OS/360 開発プロジェクトの失敗を経て分析
  結論：規模の大きなプログラムを作るのは難しい
  • 目に見えないものは管理できない（完成度が見えない）
  • 変化させやすいものは管理が難しい（「これで最後」がない）
  • 絶対的な制約のないものは管理が難しい（物理制約がない）

モダンな開発ではどう解決しているのか？

ソリューション（今のところ） Solutions at the present

• 目に見えないものは管理できない
  「動作」が見えるようにする（継続的インテグレーション; Continuous Integration）
  -変化させやすいものは管理が難しい
  変化を許容する（リファクタリング; Refactoring）
• 絶対的な制約のないものは管理が難しい
  最低限の制約を与える（テスト駆動; Test-driven development）

関連する分野：さらなる勉強にむけて

（ここはみんなで作るページです）