Software Engineering: A Practitioner's Approach 1st edition (1982)に見る歴史

まとめ

  • Software Engineering: A Practitioner's Approach 1st edition (1982) はソフトウェアエンジニアリングの教科書として最初期のもの。9版(原著2019、邦訳2021)が最新。
  • ソフトウェアエンジニアリングはソフトウェア危機(software crisis)に呼応して生まれたと書かれている。ただし、ソフトウェア危機を示す参考文献として NATO Software Engineering Conference の議事録は挙げられていない。
  • ソフトウェア危機は表面的にはコストとスケジュールの問題であり、その背景には「開発の実績データがない」「生産性の指標がない」「開発プロジェクトの拠り所は曖昧な顧客の要求しかない」「テストの重要性に気づいたのはつい最近」「既存ソフトウェアの保守は難しい」という難しさがある、と書かれている。問題も難しさを増しているため現代でも克服できていないことは多い、というのが私の所感。
  • 計画、開発、保守というライフサイクルに沿った章構成となっている。その背景にはライフサイクルをフェーズとみなした逐次的なプロセスモデルが伺える。ただし、プロセスモデル、ウォーターフォール、Winston Royce は参考文献に無い。
  • 保守が工数的に最も多くを占めることは1982年の時点で認識されている。ただし、それに対応する技術は未開拓であり、逐次的なライフサイクル（フェーズ）の最後に保守があるというプロセスモデルしか見いだせていなかったのではないか。
  • 初版にはプログラミング言語選定指針とコーディングスタイルの章がある。これの現代版に需要があるのではないか。
  • 初版は Amazon.com で入手。昔の学生が使っていた教科書かもしれない。えもい。

この文章を書いたきっかけ

米国の大学を中心に教科書として採用されており、40年に渡って改訂されてきたベストセラーであるという Software Engineering: A Practitioner's Approach 9th edition の訳書 "実践ソフトウェアエンジニアリング第9版" が2021年12月1日にオーム社より発刊されました。これを記念して、翻訳者による感想や解説などの本書にまつわる文章をアドベントカレンダー形式でお届けします。この文章は 実践ソフトウェアエンジニアリング第9版アドベントカレンダー の15日目(2021/12/15)に公開するはずでしたが、1月になってから書いています。

今回は1982年に発刊された初版 Software Engineering: A Practitioner's Approach 1st edition を扱います。 最新の9版を知る共訳者の身からして、始まりは何だったのかという興味がわいて入手しました。 入手先は Amazon.com で、値段は10ドル未満でした。

f:id:masskaneko:20211021212315j:plain
初版(左)、9版(右)

始まりを示す記述

一般に、ソフトウェアエンジニアリングという分野の始まりは 1968-1969 年の NATO Software Engineering Conferences *1 とされています。 そして、1982年に出版された本書はソフトウェアエンジニアリングを冠した最初期の教科書です*2。 であれば、本書にはソフトウェアエンジニアリングという分野の始まりが書かれているはずです。

それは本書のPREFACE(まえがき)に書かれていました。

  • 電子コンピューターの時代を振り返ると、1950年代と1960年代はハードウェアの時代だった。1970年代はソフトウェアを認識する転換期だった。そしてソフトウェアの時代が目の前に訪れた。現に、強力な1980年代のプロセッサを使いこなすほど質の高いソフトウェアを生み出せず、コンピューター技術が進歩する足を引っ張りつつある。
  • 1970年代において、我々は「ソフトウェア危機(software crisis)」と称される状況を認識するに至った。ソフトウェアに関するコストは爆発的に増大し、コンピューターを使用したシステムにおいて最も高価な要素となった。開発計画の通りに進むことはほとんどなかった。ソフトウェアが大きくなるにつれ品質が怪しくなってきた。参考となる過去の開発データは乏しく、プロジェクトのコントロールは失われていった。
  • そして、ソフトウェア危機に呼応する一連の技術、すなわち「ソフトウェアエンジニアリング」が誕生した。これらの技術はソフトウェアを工業製品として扱うものであり、計画、分析、設計、実装、テスト、保守というプロセスが必要な工業製品だと位置づけた。本書の目標は、そうしたソフトウェアエンジニアリングプロセスをまとめて紹介することである。

NATO Software Engineering Conferences は1968-1969年であり、その議事録に software crisis が登場します。 その crisis と称されるほどの大問題が広く業界に認識される時期が1970年代だった (転換期だった) ということでしょう。

Software Crisis の内容

本書の2章は The Software Crisis です。 日本語ではソフトウェア危機と呼ばれ、Wikipedia に載っています。

本書の 2.1 The Problems でその問題が解説されています。

  • ソフトウェア危機は多くの問題によって特徴づけられる。だが、ソフトウェア開発の責任者（あるいは経営者）は、スケジュールが何ヶ月や何年も遅れることや、費用が予算を著しくオーバーするといった表面上の問題に関心がある。そうした問題はソフトウェアの難しさの結果として見えてくるものだ。
The software crisis is characterized by many problems, 
but managers responsible for software development concentrate on the "bottom-line" problem:
schedule and cost estimates are often grossly inaccurate.
Cost overruns of an order of magnitude have been experienced.
Schedules slip by months or years.
These problems are the most visible manifestation of other software difficulties:

続いて、その難しさが列挙されています。

  • ソフトウェア開発プロセスの実績データを収集していない。データがないので見積もりの精度は悪い。生産性の指標もないので、新しいツール、技法、標準の効果を評価できない。
  • 顧客が "完成" したシステムに不満を抱くことは日常茶飯事である。開発プロジェクトの拠り所は曖昧な顧客の要求しかない。顧客と開発者のコミュニケーションはお粗末である。
  • ソフトウェアの品質は大体怪しい。我々が体系的で技術的に完全なソフトウェアテストの重要性に気づいたのはつい最近のことだ。定量化の概念が信頼性と品質保証に持ち込まれたのも最近のことだ。
  • 既存ソフトウェアの保守は非常に難しい。大半のコストは保守にかかっている。だが、ソフトウェアの保守性は受け入れ条件として重要視されていない。

現代に至るまで、これらの難しさを克服するための技術が生まれてきました。 それによってどれだけ克服できたか考えてみると40年の進歩が明らかになりそうです。 問題も難しさを増しているため現代でも克服できていないことは多い、というのが私の所感です。

初版の構成とプロセスモデル

PREFACE(まえがき)によると、初版の構成はソフトウェアライフサイクルに沿ったものだそうです。

The contents of this book closely parallel the software life cycle.

1.4.3 にはソフトウェアエンジニアリングの主目的が示されており、計画(planning), 開発(development), 保守(maintenance) というソフトウェアライフサイクルに対応する方法論を確立することが挙げられています。

The key objectives of software engineering are
(1) a well-defined methodology that addresses a software life cycle of planning, development, and maintenance,
(2) an established set of software components that documents each step in the life cycle and shows traceability from step to step, and
(3) a set of predictive milestones that can be reviewed at regular intervals throughout the software lifecycle.

この後、Plannning phase, Development phase, Maintenance phase の説明が続きます。 実際に、本書の構成はこれらの phase に沿う物となっています。

まず、1, 2章はソフトウェアライフサイクルを語る前提に位置するものとなっています。

  1. Computer System Engineering
  2. The Software Crisis

そして、計画を扱う章が始まります。

3. System Planning
4. Software Planning
5. Software Requirement Analysis

次に開発。

6. The Software Design Process
7. Software Concepts
8. Data Flow-Oriented Design
9. Data Structure-Oriented Design
10. Detailed Design Tools
11. Programming Languages and Coding
12. Software Testing and Reliability

最後に保守で締めくくられます。

13. Software Maintenance

本書において、計画、開発、保守はライフサイクルであると共に一定の期間を表すフェーズです。 それを表す図として、manager と technical staff がどのライフサイクルで参加するかを示したものがあります。

f:id:masskaneko:20220105023845p:plain

また、ライフサイクルによる工数の推移を示した図もあります。

f:id:masskaneko:20220105023927p:plain

これらの図からすると、本書ではライフサイクルをフェーズに対応させたプロセスモデルを置いていることがわかります。 言い換えれば、ウォーターフォールと称される逐次的なプロセスモデルです。 ただし、プロセスモデルという言葉も、ウォーターフォールという言葉も、ウォーターフォールの祖と誤解された Winston Royce も本書には載っていません。

現代では、ライフサイクルをフェーズに対応させるのではなく、より多くのライフサイクルを円滑させたフェーズを反復するプロセスモデルが重要とみなされるようになりました(例：XP, DevOps)。 また、これらのライフサイクルにない領域も定義されるようになりました(例：構成マネジメント、システムモニタリング、プロセス改善)。

では、本書にはそのような現代的な事項に関係することが全く書かれていないか？ というとそうではなく、13章 Software Maintenance に全部押し込まれているというのが私の見解です。

最初の開発コストよりも保守コストが多くを占め、増してゆく図があります。 言い換えれば、リリースしてからが本番であることは40年前からわかっていたということです。

f:id:masskaneko:20220105025153p:plain

保守要望(maintenance requests)を基点としたプロセスフローを示した図があります。 これを現代的に見れば、バックログアイテムの認識と優先度づけ、それに対する変更マネジメントです。

f:id:masskaneko:20220105032043p:plain

ほか、既存コードを読み解くことの難しさ (maintaining alien code)、保守による思わぬ副作用(side effects)、変更日時や変更理由などを記録することの大切さ (record keeping)、デバッグを可能にしておくこと(built-in debugging facilities) が挙げられています。 13章に書かれた内容は現代に至るまで、構造化設計、オブジェクト指向設計、静的コード解析、保守性のメトリクス、バージョン管理、継続的インテグレーション、自動テスト、リファクタリング、イテレーティブ&インクリメンタルプロセスモデルに進化してゆきます。

本書が書かれた1982年の時点では、リリースしてからが工数的に本番であることは認識しつつも、それに対応する技術は未開拓であり、逐次的なライフサイクル（フェーズ）の最後に保守があるというプロセスモデルしか見いだせていなかったのではないでしょうか。だから、保守を扱う章は13章のみなのだと思います。

最新版にあってもいいんじゃない？と思う初版の内容

最新の9版では、1章にソフトウェアエンジニアリングの定義と意義と概要が書かれています。 ですが、ソフトウェアエンジニアリングが無いとどのような問題に直面するのか？それらの問題はコンピューターサイエンスでは解決できない領域なのか？という切り口では書かれていません。 なので、ジュニアクラスの実務者やコンピューターサイエンス専攻の学生が9版の1章を読んでソフトウェアエンジニアリングを学ぶ気になるかは怪しいと考えています。 そこでソフトウェア危機(software crisis)を持ち出し、歴史的にどのような問題があったか、それらの問題は現在ではどう形を変えて残っているのかを記述すれば、学習動機が生まれやすいのではないでしょうか。

9版にコーディングの章はありませんが、初版の11章は Programming Languages and Coding です。 プログラミング言語の種類と特徴、言語の選択指針、コーディングスタイルが扱われています。 40年前の本ですので、出てくる言語は FORTLAN, PL/1, Ada といった古いものですが、これの現代版があったら嬉しいのではないでしょうか。 現代のメジャーな言語をいくつか取り上げ、言語選択指針、コーディング規約、コード解析、コードメトリクスを扱うことは、 実際のソフトウェアエンジニアリングにおいて需要があると思います。

感想

初版を全て読んだわけではありませんが、分野の誕生と保守に着目して現代とのつながりを見出すことができました。 今後、教育資料を作るときに出番があるかもしれません。 実務で参照することは無いと思います。コレクター的に持っていてもいいんじゃない？という程度です。 私が入手した本にはハイライトやメモ書きが残っていました。 40年前にアメリカの学生が読んでいた教科書が日本の暇人の元にやってきたのでしょうか。エモし。

f:id:masskaneko:20220105052727p:plain

*1:http://homepages.cs.ncl.ac.uk/brian.randell/NATO/index.html

*2:ソフトウェアエンジニアリングの教科書例は CMU/SEI が1991年に調査した文献 https://resources.sei.cmu.edu/asset_files/TechnicalReport/1991_005_001_15932.pdf の Table 2 に掲載されており、本書はその筆頭として挙げられている。その中に、本書と同様に数十年に渡って改訂されている Sommerville 著の Software Engineering があるが、こちらの初版は1985年である。