 |
||||||||||
|
||||||||||
| 前のページ 1 2 3 | ||||||||||
|
||||||||||
| 処理数は本当に要件定義が終わらないと見えないのか | ||||||||||
|
解説してきたように、FP法はボトムアップ見積と異なり、内部論理ファイル数と外部インターフェース数をというデータにも着目しています。ボトムアップ見積もそうですが、従来の「システムによってどんな業務にするのか（What）」をあらわす場合、業務フローなどにより、プロセスのみを記載することが大半でした。 しかしFP法では、ファイルやインターフェースというデータの固まりの数を対象にしています。実はこれが大きなヒントになります。 データにはそれぞれ関係があります。例えば、顧客と契約の間には1:nの関係があることや、入庫や出庫と在庫の間にはデータを更新するという関係があるなどということです。この関係が、実は参照や更新の処理が必要であることをあらわしているのです。 このようなデータの関係を示している「データモデル」こそがRFP作成をする上で重要になります。 特に重要なのが在庫ファイルや実績をサマリするファイルとその更新元ファイルの関係です。これらの関係は、最終的にバックエンドプロセスやバッチプロセスとして実装されます。つまりデータモデルを書けば、難しいと思われていたバックエンドやバッチプロセス数も明らかになるのです。 ここで必要になるのは、要件定義の中で作成するような精緻なデータモデルではなく、データとデータの関係、つまりデータ構造が明らかになるだけで十分なのです。 また、データ構造だけを明らかにするのであれば、業務の概要が見えた段階でデータモデルを作成することが可能です。このため、本連載のテーマとしている要件定義前のRFP作成でも実施できるわけです。 なお、これらのことで、FP算出の基になる部分が見えるのですが、従来型の算出方法でそのままFPが算出できるわけではありません。見積れるだけの要素が提示できるということに過ぎないのです。これらの要素からFPを算出するためには、オランダのソフトウェア計測団体NESMAが提案しているFP試算法などを適用するのもよいかもしれません。 |
||||||||||
| システムによってどんな業務にするのか（What）は、何で定義するか | ||||||||||
|
データモデルを参考することによって、開発の概算費用が算出できるようになります。この他にもRFP作成のために必要なものとして、「業務フロー」と「業務WBS」があります。 |
||||||||||
| 業務フロー | ||||||||||
|
業務をあらわすためのドキュメントは、一般的に業務フローでしょう。業務フローには組織が登場します。本連載で対象にしている業務フローは、システム化をテーマにしていますから、情報システムもなんらかの役割を担うことになります。このため、業務フローには必ず情報システムを組織の１つとして登場させることが重要です。 |
||||||||||
| 業務WBS | ||||||||||
|
業務フローは業務の詳細な記述は得意ですが、全体の把握にはあまり向きません。このため、業務フローの上位のドキュメントである業務WBSを記述しています。業務WBSには業務機能の階層関係を記述します。 例えば、受注業務機能には、受注受付機能と受注変更受付機能があるなどがわかるように記述します。表形式であったり、組織図のような階層図で記述したりすることもあります。 |
||||||||||
| データモデル | ||||||||||
|
これらに加えて、先に解説したデータ構造を記述したデータモデルを作成します。 |
||||||||||
| 次回は | ||||||||||
|
なお、実際の要件定義前のRFP作成では、対象業務のすべてに対して、これらのドキュメントを全部作るわけではありません。 今回は費用の算出に焦点をあて、RFP作成の事前に「何を（What）」をどこまで決めておくのかを解説してきました。また、「何を（What）」が決まったところで、次回は、いよいよRFP作成の具体的な体制や手順などを解説します。 |
||||||||||
|
前のページ 1 2 3 |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
-
連載
