「標準ソフトウエア工学教科書」を作ってみたいと思います その９ ２．４

シリーズ「標準ソフトウエア工学教科書」を作ってみたいと思います

今回は「２．４　インクリメンタルモデル」です。

---

２．４　インクリメンタルモデル

　ここまでの話の流れをまとめると、以下のようになります。

・まず、ソフトウエア開発のプロセスとして、ウォーターフォールモデルが出てきた。
・それを変形したV字型モデル等がある
・ウォーターフォールの問題点を解決するために、さまざまなモデルが出てきていて、
　間違った要求仕様で開発しないようにするための手法として、プロトタイプがあった。

　今回も、ウォーターフォールモデルの問題点の改良版を見ていきます。
　まずは、解決すべき問題点についてですが、ウォーターフォールモデルでは、さらに２つの問題点があります。

・問題点１

　要求仕様を満たすような設計・実装は、実現できないような場合、設計・実装の段階になるまでわかりません。ウォーターフォールでは、設計・実装の段階から要求仕様に戻るということはしないし、そもそも、ウォーターフォール云々という前に、設計・実装から要求分析に戻ると、手間や開発リスクが増大します。


・問題点２
　ウォーターフォールでは、開発が完了するまで、実際にシステムを稼動して利益を得ることができません。しかし、その間に世の中が変化し、当初の要求でシステムを開発・稼動しても意味がなくなってしまうようなことが起きてしまったら、その開発経費は無駄になってしまいます。


　この問題点を解決する方法の１つが、インクリメンタルモデルです。

----

　インクリメンタルモデルでは、システムをいくつかの部分に分割し、その部分ごとに、作っていきます。

　たとえば、会社全体のシステムを作る場合、受注、発注、在庫、財務など、いくつかの部分（サブシステム）にわけ、その部分部分を作っていきます。今回は受注、受注ができたら発注・・のように。

　この方法だと、

・問題点１については、全体を作るより、サブシステムを作るほうが、早くできるので、設計・実装に入るタイミングも早くなり、最悪、要求仕様を修正しなくては、できないという場合になっても、全体を直すより、サブシステムを直すほうが、被害が少なくてすむ

・問題点２については、サブシステムを稼動する（上記の例だと、受注システムだけを稼動する）だけでも意味があるのであれば、システム全体を開発するより、サブシステムを稼動するほうが、早期にできるので、早い段階から、利益を享受できます。
　環境の激変により開発を中止するにしても、サブシステムだけの被害ですむので、少額の被害ですむことが期待されます。

----

　というと、なんかこのシステム開発方法がよさそうに見え、実際、サブシステムごとに開発していくというインクリメンタルモデルは多く行われている（と思います）のですが、問題もあります。

　それは

・すでに稼動しているサブシステムがある場合、新規サブシステムはそれに拘束される。
　稼動している既存サブシステムを修正するのは、コスト高になる。

　　たとえば、受注システムが稼動している段階で、発注システムを考える場合、
　発注システムは、受注システムのDBやDBの稼働環境に影響を受けます。
　もし、受注システムのテーブルを修正しないといけないとなった場合、稼動している
モノに対して、修正をかけ、稼動しているシステムをとめて、データ移行して、
修正版を入れなおして、それが完璧に稼動しないといけないです。

　そのハードルは、結構高かったりします。