 |
||||||||||||
|
||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||
|
||||||||||||
| ライフサイクルモデル | ||||||||||||
|
次に代表的ライフサイクルモデルを、順次型と繰り返し型に分けて紹介します。
表2：順次型
表3：繰り返し型 ソフトウェアの開発の基本要素は分析・設計・実装・テストで、このサイクルを1回行うか複数回行うかの違いが開発ライフサイクルモデルの差異となっています（図3）。  図3：開発基本要素と開発ライフサイクルモデル （画像をクリックすると別ウィンドウに拡大図を表示します） 実際の開発プロジェクトでは立ち上げ作業として、開発ライフサイクルモデルの選定後、具体的な開発プロセスと成果物の定義、それと並行して使用する支援ツール評価選定（含む機能の限定）を行いながら、作業計画の詳細化を実施します（図4）。  図4：プロジェクト立ち上げ作業 |
||||||||||||
| 実プロジェクトへの適用 | ||||||||||||
|
では実際に開発プロジェクトに適用するにはどのようにすればよいのでしょうか。近年主流となっているWebシステム開発の例をご紹介させていただきます。 プロジェクトのたびにライフサイクルモデルや開発プロセス、成果物を検討するのはコストも時間もかかりすぎるため、実績のある開発プロセスをカスタマイズして利用し、実利のある成果物を作成するのが得策です。 さらに弊社では、利用者の視点を管理者と開発者に分離し、それぞれに専念できるよう開発管理標準と開発標準を別文書として策定しています。なぜなら、開発者にとって管理上だけに必要な情報を押しつけられるのはわずらわしいと感じるからです。管理と開発の分離により、各人の作業に専念できる環境を作ることでモチベーションが向上し、これに開発生産性と品質も比例して向上するものと考えます。 内容を少し紹介しますと、管理標準（TEAMmethodという米国ユニシスの方法論を日本の慣習を踏まえた形で再構築しています）としては契約前の手続きから保守運用にいたるまでの管理手順を規模別に規定し運用しています。 また開発標準（LUCINA：弊社の過去の経験と共通フレームなどの工学的要素とを組み合わせて策定したもの）では、実行環境ごと（Java、.NETなど）によって、より開発プロジェクトに近い形で以下の3つを基本要素として定義しています。
|
||||||||||||
|
表4：基本要素の定義 |
||||||||||||
これはカスタマイズの範囲を絞り、プロジェクトの立ち上げをスムーズにするとともに、技術リスクを抑えることに役立っています（図5）。 図5：LUCINA開発工程と管理工程 （画像をクリックすると別ウィンドウに拡大図を表示します） LUCINAは、複数の会社にまたがった形で開発を行うのが当たり前の昨今、繰り返し型モデルをベースに、汎用的な利用も考慮しています（図6）。  図6：LUCINAにおける共通フレームと開発プロセスの対応 （画像をクリックすると別ウィンドウに拡大図を表示します） また開発標準として全社利用を前提とし、実プロジェクトからのフィードバックを受けながら洗練させることにより、ノウハウの蓄積、要員の経験の積み重ね、教育コストの軽減に効果を発揮しています（図7）。  図7：開発標準の洗練 一方、開発サイドだけに限らず、ユーザサイドでも開発標準を設けることは有効であり、受け入れ／検収のベースとすることで、構築ベンダーの違いや関連部門ごとの差異を吸収できると考えています。 |
||||||||||||
|
前のページ 1 2 3 4 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
