開発サイクル編

第１０章　開発サイクルの基本形

１０．１　 開発サイクルの基本形

図10-1 Drop開発サイクルの基本形

１０．２　 契約主導型開発サイクル

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


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

　この開発サイクルは、ODGが主体となり、再利用可能なコンポーネントを開発しながら、企業における再利用基盤を構築・発展させるためのものである。そのライフサイクルは、コンポーネントを開発し続けるという半永久的なものとなる。この開発サイクルは、システム開発で必要とされるコンポーネントの中から、新規に開発が必要なものについて、コンポーネントの提供単位であるパッケージを開発ステージという単位とし、それぞれのステージを反復させるというものである。
　図10-2の例では、システム１の開発において要求されたコンポーネントは、ステージ１、２、３毎に開発され、リリースされる。いくつのステージが対象システムに対応するかは、再利用クラス・コンポーネントをいくつ開発するかという決定による。それ以外のステージは別のシステム開発に対応するか、もしくは、ODG主導による再利用クラス構築計画に基づく開発のために使用されることになる。

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

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

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

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

  図10-3 単一アプリケーション型

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

  図10-4　システム型

  
  
  
  
  
• 大規模システム型（アプリケーション積み上げ反復戦略）
  　大規模なシステム開発において、一度に開発が困難なシステムについては、再利用クラス開発サイクルと同じく積み上げ反復を採用することとなる。アプリケーション積み上げ反復は、アプリケーションをサブシステムという単位で積み上げる反復戦略である。図10-6に説明図を示す。この場合は、Drop基本形で示したシステム開発サイクルは、１つのステージとなる。
  　この方法は、システムを積み上げていく際に、その融合が困難になるという問題をかかえている。たとえば、第２ステージで開発したものが、第１ステージで開発したものに影響を及ぼしたり、２つのステージ間でのインターフェースミスマッチが発生したりという問題が起こってしまう。この問題は、システム開発ステージの分割が、再利用コンポーネントという単位よりも独立性を保ち辛いということからくる。従って、積み上げ反復開発サイクルをシステム開発に使う場合は、ステージ間で独立した単位をどのように作るかということが成功のポイントとなり、それを厳密に設計する必要がある。（この設計については、第２３章システム共通設計のサブシステム分割を参照）
  この設計は、１回目のステージのシステム共通設計フェーズによって行われることとなり、通常よりも早い段階で決定しなければならない。よって、このようなケースでは、システム共通設計を問題領域分析フェーズと同時期、または、問題領域分析フェーズよりも早い段階から開始することが必要となる。
  
  

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

  表10-1　　アプリケーション積み上げ反復戦略

  
  
  
  
  

  図10-6 大規模システム型（アプリケーション積み上げ反復戦略）

  
  
  
  
  
  
• 複雑システム型（積み上げ反復の応用）
  　複雑なシステム開発において、一度に開発が困難と思えるシステムで、アプリケーション単位に分割できないような問題については、システムの重要な部分を先に作り上げ、徐々に肉付けしていくアプローチを取るとよい。
  　この方法は、システムを積み上げていく際に、アプリケーション単位に分割するのではなく、Dropの再利用基盤モデルのVPD(View、Process、DataManage)の単位に分割したり、基本機能、サブ機能、性能改善というような分割をする方法である。（この設計については、第２３章　システク共通設計のVPD分割を参照）
  　この特徴は、複雑なシステムの重要部分の骨組みだけを先に作り、動作検証を済ませ、その後に肉付けするため、重要部分の設計・実装に力をいれることができやすくなる。また、主要部分の骨組を早いうちに完成させることで、ゴールを見定めることができるため、開発者は、精神的に安定した中で後半の開発ができるようになることである。
  　ただし、これを成功させるには、先行する重要部分の骨組みがゴールまで持ちこたえられるよう強固で柔軟設計がなされていることが重要である。そのためには、問題領域分析にて、システムの要求範囲を明確にしておくことが重要となる。そして、システムの要求範囲と拡張部分を予測した骨組み設計がなされなければならない。
  
  

  適した ケース	開発対象が複雑で、開発期間が非常に長いと予測される(たとえば１年以上)
  例	初めに基本的な制御部分を作り、次にユーザインタフェース部分を作る
  イメージ 図10-7

  表10-2　　積み上げ反復の応用

  
  
  
  
  

  図10-6 複雑システム型（積み上げ反復の応用）