受託開発を生業とするものにとって、見積もり根拠を正しく示すことは死活問題だ、という話です。

1. なぜデータモデリングが重要なのか?
kawasima

2. その１
見積りが過小になるのを防ぐ

3. ファンクションポイント
ソフトウェアの入出力から機能の規模を算出し
その合計をソフトウェアの規模とする。
平易にいえば、画面・バッチ・帳票・テーブルの数を数え、
それらの複雑度に応じて数値変換し足し合わせたもの

4. テーブルの数
は
システムの規模

5. 汎用マスタ
種別コード
コード
都道府県
申込ステータス
口座種別名称
元号
職業
業種
異なるデータの塊を、一つのテーブルに
入れるホスト時代の流行設計を
現代にも残した由緒正しき汚モデル

6. 種別コード
コード
名称
さて、このテーブルの持つFP値は?
(本当は論理的なエンティティを見出して数えなきゃいけないが、
ER図にこの形だけ書き込まれていると、誰もそんなことはしない)
５

7. 都道府県
申込ステータス
口座種別
元号
職業
業種
ちゃんとバラしてエンティティとして書かれていれば…
５
５
５
５
５
５
30
正しいFP値が
誰でも求められる

8. FP値を人月換算すると、
だいたい１人月 10FP〜15FP
と言われているので…
先の例では
データモデルをちゃんと書かないと
２~３人月分を
損することになる

9. その２
見積りが過小になるのを防ぐ

10. FPでは
複雑なロジックが表現しきれない(キリッ
という無知

11. 注文会員ID
注文日時
注文確認者
注文確認日
紹介者ID
紹介者報酬
紹介者報酬支払予定日時
紹介者報酬支払日時
請求書出力フラグ
入金予定日
入金日時
入金者氏名
登録日時
更新日時
キャンセル日時
キャンセル取消日時
キャンセル理由
受注番号 複雑な業務ロジックが産まれる原因
１つのテーブルを複数の業務で更新する
ことにより、更新時のルールが産まれるため
「この業務では、このカラムとこのカラムだ
け更新しする」とか…
１５

12. 注文
紹介注文
請求書印刷
入金
キャンセル
７
７
７
７
７
３５
ちゃんとバラしてエンティティとして書かれていれば…

13. FP値を人月換算すると、
だいたい１人月 10FP〜15FP
と言われているので…
先の例では
データモデルをちゃんと書かないと
１~２人月分を
損することになる

14. データモデルを
正しくおこなう意義

15. システム規模を正しく見通し
余裕のある開発をするため