無料ブログはココログ

« [#TiDD] プロセスプログラミング1 - ソフトウェアプロセスもソフトウェアである - | トップページ | [#TiDD] プロセスプログラミング3(改) - ファシリテーション - »

[#TiDD] プロセスプログラミング2 - ウォーターフォールとアジャイル -

プロセスプログラミングの観点でウォーターフォール開発のプロセスとアジャイル開発のプロセスを考えてみます。ソフトウェアプロセスがプログラムであるなら、プログラムと同じように様々な設計方法や品質特性があるはずです。

まず、設計の観点で見てみます。ウォーターフォールは構造化設計や複合設計で言うところのSTS(源泉、変換、吸収)分割と似ています。これはデータフローに基づく機能分割で、モジュールの強度を強く、モジュール間結合度を弱く実現すべきであると言われています。

各工程をモジュールと考えるなら、設計書や仕様書というドキュメントのインタフェースによってモジュールの独立性が保たれています。しかし、ドキュメントで実現される仕様はすべてが一括に実現されることが前提であり、その多くは個々のパラメータを個別に扱えないスタンプ結合になっています。また、各工程の関係を考えるとその順序は絶対であり、順序結合であると考えられます。

このように、ウォーターフォール開発の工程はあまり保守性の良いモジュールではありません。各工程の関連が強く、工程の順番を入れ替えることもできません。その反面、工程内の作業をモジュール化するのはリーダの役目であり、リーダーや支援する環境によってより良いプロセスを実現できる可能性があります。

一方、アジャイル開発におけるイテレーションは、ストーリーまたはタスクの集合を入力とする機能的なモジュールです。実装する対象によって、ある程度の順序性はありますが、基本的にイテレーションは独立であり、さらにはイテレーション内のタスクお多くが独立性の高いものになっています。

このように考えるとアジャイル開発は、オブジェクト指向設計されているようです。開発作業が多くのオブジェクトに分割され、柔軟に組み合わせることができます。その反面、全体を見渡せるオブジェクトブラウザ(かんばん)が必要で、呼び出しシーケンスを明確にしておく(トラッカーの)必要があります。

このようにウォーターフォール開発とアジャイル開発をプロセスプログラミングの観点でみると、その特徴と支援すべきものが見えてきます。そして、そこにチケット駆動開発の有効性が見えるのです。

このエントリーをはてなブックマークに追加



« [#TiDD] プロセスプログラミング1 - ソフトウェアプロセスもソフトウェアである - | トップページ | [#TiDD] プロセスプログラミング3(改) - ファシリテーション - »

私のアジャイル」カテゴリの記事

ソフトウェア」カテゴリの記事

プログラミング」カテゴリの記事

チケット駆動開発」カテゴリの記事

コメント

コメントを書く

コメントは記事投稿者が公開するまで表示されません。

(ウェブ上には掲載しません)

トラックバック

« [#TiDD] プロセスプログラミング1 - ソフトウェアプロセスもソフトウェアである - | トップページ | [#TiDD] プロセスプログラミング3(改) - ファシリテーション - »