*begin*back*foward*end*contents

開発サイクル編 -
第10章 開発サイクルの基本形

10.1  開発サイクルの基本形

システム開発サイクルとコンポーネント開発サイクルという2つの開発サイクルは、ADGとODGの2つのチームに割りつけられる。システム開発サイクルはADGが主体となる開発サイクルであり、コンポーネント開発サイクルはODGが主体となる開発サイクルである。

このように、それぞれのチームは主体とする開発サイクルを持つことになるが、開発サイクルとチームの間には完全な結びつきがあるわけではない。たとえば、ODGは、ADGの開発を支援する際に、システム開発サイクルを使うことになる。また、ADGは、システムで共通のフレームワークを開発する際に、このコンポーネント開発サイクルを使うこともある。

Drop開発サイクルの基本形は、図10-1のようになる。以下にDrop開発サイクルの要点を整理する。

  • コンポーネント開発サイクルとシステム開発サイクルのコンカレント(同時並行)開発サイクルである。
  • コンポーネント開発は、ODGが主体となり、パッケージを単位とする積み上げ反復サイクルによって進められる。
  • システム開発は、ADGが主体となり、カスケード・ウォータフォールによって進められる。
  • 2つの開発サイクルの各フェーズでは、必要に応じてプロトタイプ開発が組み込まれる。

開発サイクルの各フェーズについては、開発フェーズ編(第21章~)で述べる。

sorry this is image
図10-1 Drop開発サイクルの基本形

10.2  契約主導型開発サイクル

契約主導型開発サイクルはDropが従来(version1.0)から採用している開発サイクルである。この開発サイクルは、「開発サイクルの基本形」で述べたように、コンポーネント開発(積み上げ反復)とアプリケーション開発(カスケードウォータフォール)を同時並行的に進めていく方法である。

コンポーネント開発サイクルの詳細

この開発サイクルは、ODGが主体となり、再利用可能なコンポーネントを開発しながら、企業における再利用基盤を構築・発展させるためのものである。そのライフサイクルは、コンポーネントを開発し続けるという半永久的なものとなる。この開発サイクルは、システム開発で必要とされるコンポーネントの中から、新規に開発が必要なものについて、コンポーネントの提供単位であるパッケージを開発ステージという単位とし、それぞれのステージを反復させるというものである。

図10-2の例では、システム1の開発において要求されたコンポーネントは、ステージ1、2、3毎に開発され、リリースされる。いくつのステージが対象システムに対応するかは、再利用クラス・コンポーネントをいくつ開発するかという決定による。それ以外のステージは別のシステム開発に対応するか、もしくは、ODG主導による再利用クラス構築計画に基づく開発のために使用されることになる。

sorry this is image
図10-2 複数のシステムに対応するコンポーネント開発サイクル

コンポーネント開発サイクルには、積み上げ反復方式がとられる。図10-2で注目すべき点は、コンポーネント分析フェーズが連続的に切れ目なく繰り返されているという特徴である。これは、クラスライブラリに新規のコンポーネントをパッケージとして追加するための分析と、クラスライブラリを計画的に発展させるためのソフトウェア構造基盤の分析を、連続させて行う必要があるからである。

システム開発サイクルの詳細

この開発サイクルは、ADGが主体となり、システムを新規に開発し、その後、改造・拡張するためのものである。この開発サイクルは、対象システムの運用開発が続く限り連続して行われる。

システム開発で取られる開発サイクルは、その規模や形態に応じて以下のような工程戦略が取られる。

単一アプリケーション型

単一のアプリケーションのような小規模システムの場合、システム共通設計は単一アプリケーションの構造基盤を決定するという意味合いしかもたない。開発サイクルについてもDropの開発サイクル基本形であげたような単純な形となる。

sorry this is image
図10-3 単一アプリケーション型

システム型

システム型では、システムを構成するアプリケーション毎にサブグループを割りつける形態となる。システム共通設計フェーズは、アプリケーション間で統一すべき共通仕様やルールについて決定をおこなう。システム共通設計の期間はアプリケーション設計より若干、先行するが、ほとんど並行的に進むこととなる。また、試験についてはアプリケーションレベルの試験の他に、システムレベルの統合試験が必要となる。

sorry this is image
図10-4 システム型

大規模システム型(アプリケーション積み上げ反復戦略)

大規模なシステム開発において、一度に開発が困難なシステムについては、再利用クラス開発サイクルと同じく積み上げ反復を採用することとなる。アプリケーション積み上げ反復は、アプリケーションをサブシステムという単位で積み上げる反復戦略である。図10-6に説明図を示す。この場合は、Drop基本形で示したシステム開発サイクルは、1つのステージとなる。

この方法は、システムを積み上げていく際に、その融合が困難になるという問題をかかえている。たとえば、第2ステージで開発したものが、第1ステージで開発したものに影響を及ぼしたり、2つのステージ間でのインターフェースミスマッチが発生したりという問題が起こってしまう。この問題は、システム開発ステージの分割が、再利用コンポーネントという単位よりも独立性を保ち辛いということからくる。従って、積み上げ反復開発サイクルをシステム開発に使う場合は、ステージ間で独立した単位をどのように作るかということが成功のポイントとなり、それを厳密に設計する必要がある。(この設計については、第23章システム共通設計のサブシステム分割を参照)

この設計は、1回目のステージのシステム共通設計フェーズによって行われることとなり、通常よりも早い段階で決定しなければならない。よって、このようなケースでは、システム共通設計を問題領域分析フェーズと同時期、または、問題領域分析フェーズよりも早い段階から開始することが必要となる。

表10-1  アプリケーション積み上げ反復戦略
適した ケース 積み上げるステージの生産物の独立性が高い場合
開発規模が大きく、開発期間が非常に長い場合(たとえば1年以上)
財務システムを導入後、次年度に営業システムを構築して統合させる
イメージ 図10-5 sorry this is image

sorry this is image
図10-6 大規模システム型(アプリケーション積み上げ反復戦略)

複雑システム型(積み上げ反復の応用)

複雑なシステム開発において、一度に開発が困難と思えるシステムで、アプリケーション単位に分割できないような問題については、システムの重要な部分を先に作り上げ、徐々に肉付けしていくアプローチを取るとよい。

この方法は、システムを積み上げていく際に、アプリケーション単位に分割するのではなく、Dropの再利用基盤モデルのVPD(View、Process、DataManage)の単位に分割したり、基本機能、サブ機能、性能改善というような分割をする方法である。(この設計については、第23章 システク共通設計のVPD分割を参照)

この特徴は、複雑なシステムの重要部分の骨組みだけを先に作り、動作検証を済ませ、その後に肉付けするため、重要部分の設計・実装に力をいれることができやすくなる。また、主要部分の骨組を早いうちに完成させることで、ゴールを見定めることができるため、開発者は、精神的に安定した中で後半の開発ができるようになることである。

ただし、これを成功させるには、先行する重要部分の骨組みがゴールまで持ちこたえられるよう強固で柔軟設計がなされていることが重要である。そのためには、問題領域分析にて、システムの要求範囲を明確にしておくことが重要となる。そして、システムの要求範囲と拡張部分を予測した骨組み設計がなされなければならない。

表10-2  積み上げ反復の応用
適した ケース 開発対象が複雑で、開発期間が非常に長いと予測される(たとえば1年以上)
初めに基本的な制御部分を作り、次にユーザインタフェース部分を作る
イメージ
図10-7
sorry this is image

sorry this is image
図10-6 複雑システム型(積み上げ反復の応用)


*begin*back*foward*end*contents

この記事のトップへ