2020年7月27日
【システム企画～情報活用力を上げる仕組み作り】
～ウォーターフォールモデル①～
スクラムを含むアジャイル型のシステム開発手法は、しばしばウォーターフォールモデルの対案として挙げられます。以下、両者の特徴と違いを見ていきます。
▶ウォーターフォールモデル
ウォーターモデルモデルという語が初めて文献に登場するのは1976年のソフトウェア工学国際会議の報告書（T.E.Bell & T.A.Thayer「Software Requirement」1976,the Proceeding of the 2nd International Conference on Software Engineering）ですが、先行する文献（Winston W.Royce「Managing the Development of Large Software Systems」,1970,the Proceeding of IEEE WESCON）にもその思想、方法、事例が述べられていることから、ソフトウェア開発においてもその頃から存在していたと考えられます。
上記の英語文献で、ウォーターフォールモデルの特徴は「linear-sequential」（線形的、連続的）という語で表されています。このことは情報処理推進機構（IPA）の書籍では以下のように説明されています。
「それぞれの作業のステップを一回だけ通して行うというのが特徴である。利用者のニーズの決定からはじまって、要求の定義、システムの設定、システムの作成、テスト、修正、そして運用、導入に至る」（情報処理推進機構「共通フレーム2007,第2版」2009,情報処理推進機構）
ウォーターフォールモデル自体の詳細説明はここでは無用と考えて省略し、前出の英語文献を読んで目についた情報を記します。
Managing the Development of Large Software Systems
Royceは、ソフトウェア開発フェーズの最小の組み合わせは分析とコーディングであるとしています。（Figure1）
しかし、これだけでうまくいくのは開発者と使用者が同一人物である場合に限られるとして、Figure2を提示しています。
次に「iterative」という語を使ってFigure3を示します。スコープ固定、計画駆動、一方通行のイメージのあるウォーターフォールモデルについて書かれた最初期の文献に「iterative」が出てくるのは意外で新鮮でした。
ここでは、このモデルの成功を収める条件として、以下のような言葉でドキュメンテーションの重要性を強調しています。
＞どのくらいの量の文書が必要かといえば、きわめて大量にである。大半のプログラマ、アナリスト、設計者が書きたいと思っているよりは間違いなく多いだろう。
＞非常に高い水準のドキュメンテーションなくしては、ソフトウェアの管理は単純に不可能となる。
＞もしドキュメントの量と質が不十分であるときは、ドキュメンテーションに関係しない活動を一時的に停止してでもドキュメントの量と質を受け入れ可能な水準まで高める必要がある。
この後、ドキュメンテーション（文書作成とアップデート）の効用、シミュレーションとテストの重要性等が述べられて、最終的にはFigure10に至ります。
ウォーターフォールモデルの進み方として重要成功要因をまとめると、以下のようになります。
〔進み方〕
〇先行フェーズから後続フェーズに順を追って流れていくが、フェーズ間の行き来（iteration）があってもよい。
〔重要成功要因〕
〇仕様が明確に文書に記されていること
〇文書の内容が受注者内、発注者内、受注者と発注者の間で合意されていること
さらに、この論文には明確に記されていませんが、成功しやすい条件としては以下になると考えます。
〔成功しやすい条件〕
〇プロジェクト初期に要求が明確になっており、以降の変更が少ない
〇技術的に難しい要素が少ない
〇プロジェクト期間が短い
〇開発者側に十分なドキュメンテーションを行うリソースがある
〇発注者側に読むべきドキュメントを読むリソースがある
＞＞＞次回に続きます（2020/9/23）
2020年7月
▶関連コラム ｜ ウォーターフォールモデル②（2020/9/23）