ライフサイクルモデル

ライフサイクルモデル

次に代表的ライフサイクルモデルを、順次型と繰り返し型に分けて紹介します。

ウォータフォールモデル

水が流れるごとく1段ずつ次に進み、ループバックがない。ほかの大半のモデルのベース。

Vモデル

実装を底として工程をV字型で表したモデルです。テストを仕様、設計と結びつけることを強調した手法。

イテレーティブ（反復）モデル

1サイクルでシステム全体を薄く仕上げ、前サイクルの成果にオーバーラップさせる手法。

インクリメンタル（漸増）モデル

対象をブロックに分割し、1サイクルで一塊のモジュール群（これを1インクリメントという）を前サイクルの結果に上乗せしていく手法。

ソフトウェアの開発の基本要素は分析・設計・実装・テストで、このサイクルを1回行うか複数回行うかの違いが開発ライフサイクルモデルの差異となっています（図3）。
 

図3：開発基本要素と開発ライフサイクルモデル
（画像をクリックすると別ウィンドウに拡大図を表示します）

実際の開発プロジェクトでは立ち上げ作業として、開発ライフサイクルモデルの選定後、具体的な開発プロセスと成果物の定義、それと並行して使用する支援ツール評価選定（含む機能の限定）を行いながら、作業計画の詳細化を実施します（図4）。
 

図4：プロジェクト立ち上げ作業

実プロジェクトへの適用

では実際に開発プロジェクトに適用するにはどのようにすればよいのでしょうか。近年主流となっているWebシステム開発の例をご紹介させていただきます。

プロジェクトのたびにライフサイクルモデルや開発プロセス、成果物を検討するのはコストも時間もかかりすぎるため、実績のある開発プロセスをカスタマイズして利用し、実利のある成果物を作成するのが得策です。

さらに弊社では、利用者の視点を管理者と開発者に分離し、それぞれに専念できるよう開発管理標準と開発標準を別文書として策定しています。なぜなら、開発者にとって管理上だけに必要な情報を押しつけられるのはわずらわしいと感じるからです。管理と開発の分離により、各人の作業に専念できる環境を作ることでモチベーションが向上し、これに開発生産性と品質も比例して向上するものと考えます。

内容を少し紹介しますと、管理標準（TEAMmethodという米国ユニシスの方法論を日本の慣習を踏まえた形で再構築しています）としては契約前の手続きから保守運用にいたるまでの管理手順を規模別に規定し運用しています。

また開発標準（LUCINA：弊社の過去の経験と共通フレームなどの工学的要素とを組み合わせて策定したもの）では、実行環境ごと（Java、.NETなど）によって、より開発プロジェクトに近い形で以下の3つを基本要素として定義しています。
 

これはカスタマイズの範囲を絞り、プロジェクトの立ち上げをスムーズにするとともに、技術リスクを抑えることに役立っています（図5）。

図5：LUCINA開発工程と管理工程
（画像をクリックすると別ウィンドウに拡大図を表示します）

LUCINAは、複数の会社にまたがった形で開発を行うのが当たり前の昨今、繰り返し型モデルをベースに、汎用的な利用も考慮しています（図6）。
 

図6：LUCINAにおける共通フレームと開発プロセスの対応
（画像をクリックすると別ウィンドウに拡大図を表示します）

また開発標準として全社利用を前提とし、実プロジェクトからのフィードバックを受けながら洗練させることにより、ノウハウの蓄積、要員の経験の積み重ね、教育コストの軽減に効果を発揮しています（図7）。
 

図7：開発標準の洗練

一方、開発サイドだけに限らず、ユーザサイドでも開発標準を設けることは有効であり、受け入れ／検収のベースとすることで、構築ベンダーの違いや関連部門ごとの差異を吸収できると考えています。