開発プロセス



 1980年代初頭にACM(American Computer Machinery)のSEN(Software Engineering Notes)誌を中心に、「ライフサイクル論争」が起こりました。それまで主流だったウォータフォール型の開発プロセスの原理的な欠陥が明らかになり、それを乗り越えるさまざまな提案がなされました。この論争を契機として、第1の波から、第2の波の時代へとパラダイムシフトが起こりました。

【ライフサイクル論争(開発プロセスの推移)】
 ウォータフォール型プロセスの原理的な欠陥である、最初の意思決定の正しさが、最後にならないと確認できないことを解決するための、論争がなされました。今で言う、プロトタイピング、スパイラルプロセス、モデル駆動開発といった新しいプロセスの必要性が認識されました。
 


 1970年代に確立され、現在でも多くのプロジェクトで採用されている開発プロセスは、図に示すようなウォーターフォール型を基本としたものです。前工程で得られた中間成果物を確定・固定化した後に、それを前提として該当する工程の作業を行う方式です。前工程での誤りが、後工程に持ち込まれると手戻り(フィードバック)を生じ、全体の工数も増加してしまうことになります。「ウォーターフォール型」という名前の由来も、工程を進めるということを、滝を下ることに見立てているところにあります。滝を逆に登るのが大変であることも、手戻りのコストが高いということをうまく表しています。
 


 仕様化、システム設計、モジュール設計、プログラミングのそれぞれの工程の正しさを、出来上がった成果物=プログラムに照らし合わせて確認する工程がテスト工程です。このことをよりわかりやすく表したのが、V字モデルです。工程は、図に示す通り左から右へと進められていきます。実行可能な成果物が得られるのは、プログラミング工程を終了した時ですから、プログラムを実行させてプログラムの正しさを確認していくテストは、後でまとめて行うことになります。
 V 字モデルによってウォータフォール型の開発プロセスを表すことによって、旧来の開発プロセスの欠点が明らかになります。それは、最初に行った意思決定の正しさが最後にならないとわからないことです。
 プロジェクトに着手してからの要求変動に対処することは難しい問題ですが、初段の分析や基本設計フェーズを着実に進める方法として、バリー・ベームがスパイラルモデルというのを提唱しています。これは図に示すように、初段の業務分析、要件分析、概要設計、基本設計について、計画、意思決定、分析評価を繰返しながら段階的に拡充していこうという考え方です。特に、プロトタイピングやシミュレーションを行って動くもので確認していくところが特徴です。こうして得られた堅牢な基本設計に基づいて、後は、ウォータフォール型の開発プロセスで進めていく方法です。つまり、「最初が肝心」ということを的確に進めるのがスパイラルモデルです。

 


【繰返し型プロセス】

 

 ウォータフォール型の開発プロセスの原理的欠陥を乗り越えるためには,仕様化から出荷テストまでの時間を短縮することと、仕様化等の初期段階の中間成果物の正しさをプログラムなしで確認する方法が必要になってきます。前者の解決策の一つが、インクリメンタル(段階的拡充型)開発プロセスです。後者については、前節のスパイラルモデルも対策の一つですが、より高度な検証技術が必要になります。
 インクリメンタル開発プロセスの利点は、顧客/ユーザの要求に関するフィードバックを得られることの他に、実現上の見通しを早期段階で得られるところにもあります。また管理上も、品質情報を随時得ることができます。製品のリリース時期が、技術的要因以外で決定されることも多いく、常に実行可能なプログラムを確保できるためリスク管理的な視点でも好ましいと言えます。
 インクリメンタル開発プロセスでは、要求分析・定義を行った後の仕様は固定化し、インクリメントのサイクルをくり返している時も変更しない方法です。この仕様も、フィードバックのサイクルの中で積極的に変更・発展させてしまう方式をとることもできこのような開発プロセスを、「発展型開発プロセス(evolutional development model)」と呼んでいます。次節で述べるアジャイルプロセスは、開発プロセスの観点からの整理では発展型開発プロセスの一つと位置づけられます。


 
 上記、インクリメンタル開発プロセスと発展型開発プロセスとを総称して、イテレーティブ(繰返し型)開発プロセスと呼ぶこともあります。これ等の開発プロセスは、仕様変更とその確認のサイクルを短くすることによって、同調性や可変性に対処する実践的な方法と言えます。

【ソフトウェアは知の織物】
 繰返し型開発プロセスは、仕様化、実現、テストが細かいサイクルで繰り返されます。これはコードのみならず、その前提となる仕様、テストに関する情報、その他さまざまな意思決定情報が同時並行的につくられていくものと見なせます。

 

 これは、さながらソフトウェア、あるいは、ソフトウェアを開発するための様々な知識が織り込まれていく様相を表わしていると言えるでしょう。

 

Comments