DOAの落とし穴オブジェクト指向分析を目指して |
DOAとはData Oriented Approachの意味で、データ中心に考えようという設計技法です。
DOAを使うメリットとしては、
- 簡単な表記法なので、ユーザーがシステムにかかわれる
- 簡単な表記法なので、ユーザーが確認できる
- データ中心なのでシステムの再利用の可能性が高い
- ドキュメント作成ルールがあるのでメンテナンスドキュメントが残る
ということがあげられるでしょう。
しかし、バラ色のDOAもいろんな落とし穴があります。例えば;
- 現状分析がほんとうにできるのか、「マニュアルがない」、「ブラックボックス」は日常茶飯事
- 現状について、担当者によりいうことが違う。さらに政治がからむ場合が多い
- 分析完成のレベルが合意できているか。ないままだと「お客の言い分がすべて」になる
- データ項目と工数は比例しない。(実績例:3300項目 100人月、6000項目 400人月)
- エンドユーザーがまったく介在していないプロジェクトは必ず破綻する。
- システムつくり以外に、制御系開発、開発ツール、データ移行、方式移行が必要になる
- BP(ビジネスプロセス)の見直しをやるなら、新論理を分析対象にいれねばならない
- 事務プロセスはどこまで詳細に追うか?
といったことを考慮しないとうまくいきません。たしかに帳票すべてが揃っていれば、分析はできますが、すべてを分析するのが仕事ではありません。どこまで
をシステム化の範囲とするか、どこは切り落とすかは、シニアな経験ゆたかなエンジニアが顧客と全体を見渡して、分析をしぼることが必要です。
一般的に分析結果として、次のようなドキュメントが想定されます。
- 業務フロー
- 業務マニュアル
- 用語集
- 伝票・帳票一覧表
- 伝票・帳票現物(かきこまれたもの)
- 画面体系
- 画面コピー
- DB・ファイルの仕様
- 入出力一覧
- 標準化マニュアル
なお、 データの論理化まですすんでいない、DFDは役にたちません。データの意味をあきらかにし、集約をかけねばデータベースにしようがありません。
およそ分析にかかるワークロードは、
現物理(現状手順):現論理(現状意味):新論理(新意味):そのほか=4:1.5:3:1.5
くらいであるといわれています。それほど、現状をまとめるのは大変です。
ワークロード自体は、DFD一枚描くために半日のインタビューを週二回やると、一週間いっぱいいっぱいくらいだと思ってください。また、非常に乱暴です
が、ひとつのDFDにプロセスボックスが6,7個。ひとつのプロセスはC言語で500ステップという数字がなにもないよりいいだろう、という意味で記して
おきます。
さて、ここからは私見です。
オブジェクト指向分析だからといって上のような構造化分析をしなくていいことにはなりません。全体を集約して始めて、どういうセマンティックなオブジェクトがあり、間違いがないかの基本資料をもつことができます。
これなしでやるといくら頭のいい人がオブジェクトを考えたとしても、それでうまくいく裏付けを取ることができません。いわゆるUMLだけで分析をしてきちんとユーザーの期待どおりのシステムができるとは思えません。
また、アプリ上のオブジェクトとプログラミング上のオブジェクトは一致しません。例えばVBで有名なADOはオブジェクトですが、これはアプリ上は意味がありません。オブジェクト指向分析とオブジェクト指向プログラミングは若干方向性が違います。