C/Sシステムにおけるアプリケーションの開発工程

ユーザ向けアプリケーションの基本的な動きはイベント・ドリブンである。ボタン操作などのイベントが起きれば、それに連動した処理が動くしかけになっている。従って、イベントの発生に応じた処理を記述するようにして、アプリケーションを開発してゆく。開発は画面単位、オブジェクト単位に進む。さらに、設計と開発が同時進行するばかりか、その場でリンク・テストまで完了させてしまうことができる。従って、

「画面設計」→「開発」→「単体(結合)テスト」

は、不可分の一工程である。RADの強みは、このように、複数工程を極めて短いサイクルで済ませる事ができる点にある。日数を経るようなフェーズの考え方が不要である為、「フェーズを戻る」といった工程上の抵抗やストレスが少ない。また、各画面の開発をサイクリックに繰り返す事が可能であれば、ラウンド・トリップ式に、アプリケーションをブラシュアップして行く事が可能である。

工程の組み立てやスケジューリングは、体制と同様、下記の区分単位に行なう。

・クライアント・アプリケーション
・サーバ・アプリケーション
・運行管理用アプリケーション

このように工程やスケジュールを分けるのは、それぞれ、開発順序、開発方法、求められる品質、などが異なる為である。業務やアプリケーションに依存したサブシステム単位で開発工程を考えると、開発順序やテストなどのスケジューリングに無理がでる。一部のチームがアイドルしたり、テストの重複が発生するばかりか、共通化や標準化が中途半端に終わる危険性があるためである。

同様に、データベースも、単に「DBデータ」と一括りにしてしまうのではなく、それぞれのデータを以下のような指標によって区別する。

・揮発性(寿命) →どの程度のサイクルで発生し、どのくらい存在するか
・剛性 → 作成されて以降、殆ど変わらないか、頻繁に更新されているか
・処理 → 参照/変更/追加/削除の何が中心か、
・公共性 → 担当者/チーム/部/事業/全組織のどのレベルのデータか

万一、上記の指標で分類データの分類が確立出来なければ、以下のような区分に従っても良い。

・一時データ
・トランザクション・データ
・システム(ユーザに見えない)・データ
・属性マスタ・データ

そして、アプリケーション同様に、それぞれのデータは、個別の工程とスケジュールでDB化する。データによって、単純投入/生成/コンバージョンetc.といた、DB化の手順が異なるばかりでなく、求められる品質が異なる為である。

以上を総括すると、システム、アプリケーション、データのそれぞれには、以下のような事が言える。

「システムは、電源を入れる順で構築する」
- 電源を入れる順序とは、サーバやDBMSなど、システムにおける重要度である。極端な事を言えば、ユーザの使うPCなどは、いつ電源が入るかわからない。それよりも、「常に稼動しているコンポーネント」「サービスを提供している事が前提となっているコンポーネント」が、初めに構築されていなければならない。なぜなら、テストも実装も、初めにサーバありきで行なわれるからである。

「アプリケーションは利用者から遠い順に開発する」
- 利用者に近づくほど、アプリケーションの仕様は不安定となる。しかし、共通モジュールやサービス機能など、利用者の目に触れない部分(逆に言えば、よりデータに近い部分)は、影響範囲の広さと反比例して、比較的仕様を安定させやすい。仮に不安定であっても、早くから着手する事で、より長い収束期間を置ける。

「データは、変化の少ない順にDB化する」
- トランザクションは、特定アプリケーションが使うケースが多いが、マスタ・データは、殆どのアプリケーションが使うため、テストの日程を左右する。最初は変更の少ないマスタ・データから初め、日々変更されるトランザクションへと進めて、アプリケーションのテストや、データのチェックがより戻しになるのを防ぐ。更新の多いデータは、アプリケーションが揃わないうちにDB化しても、一定期間毎の再投入が必要となることが少なくない。また、DB化が一度で完了するとも限らないため、万一、再ロードの必要が出た場合には、最新データの再調達が必要になる場合もある。

「システムは、電源を入れる順で構築する」
「アプリケーションは利用者から遠い順に開発する」
「データは、変化の少ない順にDB化する」

於：ソフトウェア・シンポジウム’95 滋賀 SEA