改めて Barry Boehm のスパイラルモデルを学ぶ

softwareengineering

paper

Spiral model of the software process - 改めて Barry Boehm のスパイラルモデルを学ぶ

Spiral model of the software process^*1

ソフトウェア開発に関するライフサイクルモデルというと、誰もが知っているのが「ウォーターフォールモデル」と「スパイラルモデル」の２つ。

単に試験対策などで勉強しただけだと、前者は「繰り返しがないモデル」で、後者は「繰り返しがあるモデル」くらいの理解であることも多いと思いますが、今日は改めてこのスパイラルモデルについて調べてみたのでメモ。

大学において専門科目やゼミなどでソフトウェア工学を受講している場合、画像のような図は一度は目にするであろう図ですが、変に翻訳されてしまっていたりすると肝心な部分が抜け落ちている場合があります。Google でスパイラルモデルを画像検索してみると、原型をとどめていないものも多く、PDCA と誤解しているものがあったりと、まさに玉石混淆という感じです。

† 提唱者は Barry Boehm

まず、スパイラルモデルを最初に提唱したのは Barry Boehm（バリー・ベーム） 。
それを知っていても、きちんと原文を読んだことがある人は少ないのではないでしょうか。

Barry Boehm, "A Spiral Model of Software Development and Enhancement," IEEE Computer, Vol. 21, Issue 5, pp. 61-72, May 1988.

Barry Boehm の論文のほとんどは USC Viterbi School of Engineering のCenter for Systems and Software Engineering（CSSE）のウェブサイトでPDF が公開されていることが分かったのでこれはいろいろと使えそうです。ちなみに上記の原稿はオリジナルを OCR しているようで、単語の r が n になっている typo （例えば spiral → spinal 、software → softwane という）が何カ所かあります。

† ポイントは Risk-Driven

スパイラルモデルは大きく４つのステップで構成されており、ポイントは2つ目（右上）の部分でしょうか。

Determine objectives, alternatives, constraints（目的、代替案、制約の決定）
Evaluate alternatives, identify, resolve risks（代替案の評価、リスクの特定と解決）
Develop, verify next-level product（次のレベルの製品の開発、検証）
Plan next phases（次フェーズの計画）

このEvaluate alternatives, identify, resolve risks の部分については、以下のように書かれています。

Frequently, this process will identify areas of uncertainty that are significant sources of project risk. If so, the next step should involve the formulation of a cost-effective strategy for resolving the sources of risk. This may involve prototyping, simulation, benchmarking, reference checking, administering user questionnaires, analytic modeling, or combinations of these and other risk resolution techniques.

このため、ここでプロトタイプを作るのはあくまでプロジェクトのリスクを識別、解決するための手段であることがわかります。従って、「スパイラルモデル」＝「プロトタイプを作る」という理解は必ずしも正しくないことが分かります。

このRisk-Driven（リスク駆動）考え方はこの記事を通して一貫しています。つまり、スパイラルモデルはプロジェクトのリスク（不確実性）が高い部分に着目することが重要であり、これらを少しずつ評価する方が手戻りが少なくなるということを言っているわけで、これは最近のアジャイル開発の考え方とも矛盾していないことに驚きます。

† Boehm のソフトウェア開発に関するリスク Top 10

この記事の中で Boehm は以下のようなソフトウェア開発に関するリスク Top 10 を挙げています。

スパイラルモデルが発表されたのが 1988 年なので、もうそれから30 年以上経っていますが、依然としてソフトウェア開発に関する核心部分の問題は全く解決されていないということが改めて確認できます。

Personnel shortfalls（要員不足）
Unrealistic schedules and budgets（非現実的なスケジュールと予算）
Developing wrong software functions（誤ったソフトウェア機能の開発）
Developing the wrong user interface （誤った UI の開発）
Gold plating （過剰品質？）
Continuing stream of requirement changes （継続的な要求仕様変更）
Shortfalls in externally furnished components （外注部品に関する不足）
Shortfalls in externally performed tasks（外注タスクに関する不足）
Real-time performance shortfalls（リアルタイム性能の不足）
Straining computer-science capabilities（コンピュータサイエンス能力の濫用？）

ちなみに Gold plating（金メッキ）というのは聞き慣れませんが、これは PMBOK と同じく要求された以上のものを作ってしまうというムダ（過剰品質）ということでいいんでしょうかね。

† 多くのプロジェクトはリスクの高い状況を自らに作り出している

そのほかにも最後の Straining computer-science capabilities の Straining という単語もどう捉えたらよいか難しいですが、Longman で strain を調べると "to cause difficulties for something by making too much work or too many problems which it cannot deal with easily" とあるので、頭でっかちになってコンピュータサイエンスを使いすぎると良くないみたいな感じなんでしょうか。

ちなみにこのルール名で検索をしてみたら、以下の本の一節がヒットしました。

Richard W. Selby, "Software Engineering: Barry W. Boehm's Lifetime Contributions to Software Development, Management, and Research," John Wiley & Sons, p.435, 2007/06/04.

2.3.1.6 Straining Computer Science capabilities
Here again, many projects create high-risk situations for themselves by neglecting to establish whether computer-science technology can meet their stated requirements, or by gold plating requirements in ways that can turn straightforward software-development project into high-risk software-research projects.

「多くのプロジェクトはリスクの高い状況を自らに作り出している」というのはなかなか痛烈です。

この分でリスクの高い状況を作り出す原因として触れられている原因は２つですが、Straining computer-science capabilities の意味は", or by gold plating requirements ～" 以下の部分という感じでしょうか。過剰なソフトウェアサイエンスが、簡単なソフトウェア開発プロジェクトをリスクの高いソフトウェア研究プロジェクトに変えることができる方法だというのは、ソフトウェア工学者としては心に留めておきたいところです。