ＣＲＵＤ分析完了段階での見積もり

ここまでの作業では、データ設計はデータ設計、ユーザインタフェース設計はユーザインタフェース設計という別の作業と考え方で説明してきました。

実際には、それぞれの作業の中で双方が情報を参考にしながら実施していくことになると思います。
ただし、それはあくまでそれぞれの成果物間で不整合がないかを確認しながら実施していくということにとどまっています。

実際に次に説明するプロセスがプロジェクトに存在するかどうか、いろいろありますが・・・

データと処理の関係を整理するためにＣＲＵＤ図を作成していきます。
http://blog.goo.ne.jp/tecsup/e/499bea59ff1f2726e97bb9baeabec8e8 参照

ＣＲＵＤ図を作成することにより、どの処理がどのデータ（エンティティ）にどのようなアクセスをしているかを確認することができます。
また、ＣＲＵＤ図は処理とデータ（エンティティ）レベルだけではなく、処理とデータ項目（属性）レベルも作成していきます。

実は、ＩＦＰＵＧのＣＰＭ（カウントマニュアル）ではDETとして識別するのは、処理を行っているデータ項目のみということになっています。

従って、これまでの方法ではどのデータ項目が処理対象となっているのかについての考慮がなされていません。

そこで、処理とデータ項目（属性）単位のＣＲＵＤ図を用いて、処理対象となっているデータ項目（属性）のみをDETとして識別するようにします。

手順としては以下のようになります。（基本的に同じ手順です・・・）

【トランザクションファンクション】
①トランザクションファンクションの識別
②ファンクションタイプ（EI、EO、EQ）の判定
③DET数の算出
④FTR数の算出
⑤複雑度の判定
⑥未調整ＦＰの算出

データファンクションについてのＦＰ見積り手順としては以下のようになります。

【データファンクション】
①データファンクションの識別
②ファンクションタイプ（ＩＬＦ、ＥＩＦ）の判定
③DET数の算出
④RET数の算出
⑤複雑度の判定
⑥未調整ＦＰの算出

【トランザクションファンクションの見積り】

①トランザクションファンクションの識別
まずは、トランザクションファンクションですが、これまでと違い処理をもう少し詳細なレベルで検討していく必要があります。
特に画面については、レイアウトからどのようなデータアクセスが存在するのかについて検討をしていく必要があります。
テーブルを更新する処理があれば、その処理がトランザクションファンクションになりますが、当然、登録処理と更新処理と削除処理はそれぞれ別のトランザクションファクションということになります。
さらに、画面でコード選択を行っている場合、区分マスタ等を参照して一覧表示を行っているような場合もトランザクションファンクションとなります。（ＥＱ）
画面上のコンボボックスの表示などが該当します。（ただし、データへアクセスすることなく、固定の値を一覧表示しているような場合は、ファンクションとしては識別しません。）

それぞれのデータ（エンティティ）に関するアクセスをＣＲＵＤとして定義していきます。（Ｃ：作成、Ｒ：参照、Ｕ：更新、Ｄ：削除）
それぞれの、データアクセスに処理名を付与し、データアクセスのパターンをトランザクションファンクションとして識別します。

②ファンクションタイプの判定
トランザクションファンクションのタイプとしては、ＥＩ（外部入力）、ＥＯ（外部出力）、ＥＱ（外部照会）があります。
データに対するアクセスの種類によってトランザクションファンクションのタイプを識別します。
Ｃ（作成）、Ｕ（更新）、Ｄ：（削除）については、基本的にＩＬＦ（内部論理ファイル）に対して維持管理を行っているはずですので、タイプとしてはＥＩ（外部入力）ということになります。
Ｒ（参照）については、編集処理（金額計算等）があれば、ＥＯ（外部出力）、なければＥＱ（外部照会）に分類します。

③DET数の識別
データのアクセスの種類（ＣＲＵＤ）の単位にどのデータ項目を対象としているかを判定します。
登録処理であれば、通常、対象テーブルの全てのカラムに対して値をセットしていくことになりますが、更新処理の場合は、特定のカラムのみを更新することも考えられます。（有効在庫数の更新等）
また、削除処理では、対象テーブルのキー項目のみを指定すればいいですので、それぞれの処理が対象としてデータ項目（カラム）は異なることになります。
それぞれの処理ごとにデータ項目（エンティティの属性）とのＣＲＵＤを作成しておけば、それぞれの処理でどのようなデータ項目（エンティティの属性）に対して処理をしているのかを把握することが可能となります。

ここで注意して欲しいのは、対象とするデータ項目についても「論理的なデータ項目である」ということです。
例えば、処理のステータスを判定するための区分や作成情報（作成日、作成者）、更新情報（更新日、更新者）といった情報はDETとしては識別しないようにします。

④FTR数の識別
FTR数（関連ファイル数）ですが、あるＣＲＵＤ（データアクセス処理）は、１つのデータ（エンティティ）のみで処理が完結することもあれば、複数のデータ（エンティティ）に対して処理を行う必要がある場合もあります。
例えば、受注登録という処理があったとして、この受注登録は「受注」エンティティのみを対象とした処理ではありません。「受注」エンティティに受注情報を登録すると同時に「在庫」エンティティの引当数を更新する必要があります。
したがって、あるＣＲＵＤ（データアクセス処理）は複数のFTR（関連ファイル数）が存在することもあるわけです。
ＣＲＵＤを定義しておけば、どのＣＲＵＤ（データアクセス処理）でどのようなデータ（エンティティ）にアクセスしているかも明確ですので、アクセスしているデータ（エンティティ）の数をカウントしていけば、処理のFTR数を識別することができます。

⑤複雑度の判定
DET数とRET数をカウントできれば、後は複雑度の判定テーブルに当てはめユーザインタフェースごとに複雑度を判定することができます。

【複雑度判定テーブル】

⑥未調整ＦＰの算出
ファンクションタイプ別の複雑度はわかれば、以下のテーブルに当てはめ、未調整のＦＰを求めます。
その値を全て集計することにより、全トランザクションファンクションの未調整ＦＰ数を求めることができます。

【未調整ＦＰテーブル】

【データファンクションの見積り】

①データファンクションの識別
論理エンティティ関連図（論理データモデル）のエンティティをそのまま、データファンクションとして識別します。（ただし、ＩＦＰＵＧのＣＰＭでは、データファンクションの条件として「論理的でユーザ視点の（ユーザにとって意味のある）データであるデータ」とう条件がありますので、注意が必要です。

・論理的であることというのは、物理的ではないと捉えればいいでしょう。
例えば、伝票番号の採番用の採番テーブルがあったとしても、論理的には最大の伝票番号にプラス１をすればいいだけであれば、採番テーブルは物理的に必要なテーブルという認識で、データファンクションとしては識別しません。また、処理のための中間ファイルなども、データファンクションとしては識別しません。

・ユーザ視点であるといことですが、これはRET数のところにも絡んでくるのですが、１つのエンティティ（テーブル）だけでは、ユーザにとって意味のあるデータとなならいという場合は、概念的に一塊にしてデータファンクションを識別するということです。
例えば、「受注」エンティティと「受注明細」エンティティが存在したとしても、ユーザにとって意味のあるのは「受注」データであり、受注データのみをデータファンクションとして識別します。

②ファンクションタイプの判定
データファンクションのタイプとしては、ILF（内部論理ファイル）、EIF（外部インタフェースファイル）があります。
これまでの紹介してきた見積もり方法では、エンティティ関連図（データモデル）で整理されているエンティティをＩＬＦ（内部論理）として識別し、外部インタフェース一覧で定義されているものを、ＥＩＦ（外部インタフェースファイル）という識別を行うという方法を紹介してきましたが、ＣＲＵＤからデータファンクションを識別する場合は、異なる考え方を採用しています。
どういう考え方かというと、データ（エンティティ）に対して”Ｃ（作成）”、”Ｕ（更新）”、”Ｄ（削除）”が定義されているものは、当該アプリケーション内で維持管理されているいるデータ（エンティティ）であると判断して、”Ｃ（作成）”、”Ｕ（更新）”、”Ｄ（削除）”が定義されているデータ（エンティティ）をＩＬＦ（内部論理ファイル）として識別します。
では、ＥＩＦ（外部インタフェースファイル）をどうやって識別するかですが、データ（エンティティ）に対して”Ｒ（参照）”のみ定義されているものをＥＩＦ（外部インタフェースファイル）として識別します。
（前提として、外部インタフェースをエンティティとして登録してあり、外部インタフェースを含めたデータ（エンティティ）に対して、ＣＲＵＤが定義されているものとします。）
”Ｒ（参照）”のみ定義されているということは、当該アプリケーションは維持管理しておらず（外部のアプリケーションで維持管理しており）、参照のみをしているデータ（エンティティ）ということになります。

③RET数の算出
RET数（レコード種類数）というのは、当該テーブル（エンティティ）に何種類のレコードが保管されうるのかという数です。
ですので通常は、データファンクションのRET数（レコード種類数）は１となります。

しかし、サブタイプが存在する場合、例えば以下のような場合は、取引先テーブルには得意先レコードと仕入先レコードと納品先のレコードが存在する可能性がありますので、RET数は３ということになります。
（ちなみに、サブタイプはデータファンクションとしては識別しません。）

【サブタイプの例】
論理エンティティ関連図（論理データモデル）が作成され、適切にサブタイプが定義されていれば、サブタイプの数を集計することにより、RET数を算出することができます。

④DET数の算出
データファンクションのDET数とは、エンティティ（テーブル）の属性数（カラム数）に該当します。
この時点では、ＣＲＵＤを定義していますので、各データ（エンティティ）のどのでーた項目（属性）が処理されているのかを判断することができます。
データ（エンティティ）単位に、いずれかのトランザクションファンクションで処理をされているデータ項目（属性）の数をカウントしていくことによって、当該データ（エンティティ）のDET数とします。
ここで注意してもらいたいのは、RETと判定したサブタイプの属性です。サブタイプエンティティの属性についてはスーパータイプエンティティのDETとしてカウントする必要があります。（<==サブタイプはデータファンクションとしては識別しないため）

【サブタイプの属性の取扱】

⑤複雑度の判定
RET数とDET数をカウントできれば、後は複雑度の判定テーブルに当てはめデータファンクションごとに複雑度を判定することができます。

【データファンクションの複雑度判定】

⑥未調整ＦＰの算出
ファンクションタイプ別の複雑度はわかれば、以下のテーブルに当てはめ、未調整のＦＰを求めます。
その値を全て集計することにより、全データファンクションの未調整ＦＰ数を求めることができます。

【データファンクションの未調整ＦＰ】