あしのあしあと

2017-04-08

FP 法のイメージをつかむ

| 09:05 |  FP 法のイメージをつかむを含むブックマーク

ファンクションポイント(以下、FP)法について、なんとなく頭に残っていることをメモしておく。もう、ほっとんど忘れてしまったので、少し復習しながら。

「FP 法」については、聞いたことしかなかった*1し、もはや過去の手法だと思っていた。どんなイメージをもっていたかというと、要件定義 〜 外部設計で洗い出された「機能一覧」,「画面一覧」,「帳票一覧」,「外部 I/F 一覧」,「テーブル一覧」の行数を数えて、お終いだと。まぁせいぜい「組織ごとに機能の粒度をなるべく統一する」や「重みづけをして足し合わせる」くらいの工夫がある程度だと。


1 年前くらいに、ほんの少しだけ仕事でからんだのをきっかけに、もっと「きちんと」計測のルールがあることを知った。イメージとはかなり違っていて「データの項目数を細かく計測し、そこから規模を算出する方法」だった。確かに、いわゆる「機能一覧」にある機能なんて、粒度がてんでバラバラで、それの数を数えることに、ほとんど意味はないだろう。項目数をベースにすれば、ぶれは小さくなりそうだ。

そして、この時お世話になったのが、次の書籍。ただ、残念ながら、業務で計測できるレベルまでは到達しなかった。相も変わらず、自分の理解力のなさには辟易する。

もとい。この本では、今、最も普及している IFPUG 法が解説されている。そもそも、複数の方法があったことすら知らなかったのだが。

まずは、AP 境界(以下、境界)を設定するところからスタート。内外で分けてデータを数える、境界をまたぐデータを数える。ちなみに、データを数える際は、だいたい、次のように考える。

  • ユーザが認識できないデータは、カウントしない。例えば、データベースの各テーブルにある、システム管理に用いるカラム(例えば、更新日時)など
  • 実質的に「同じ」データは、カウントしない。例えば、入力したデータが、次画面で出力されている場合は、あわせて 1 つとカウントする

これは、システムの規模が、過大に評価されないようにするためだろう。少し、具体的な計測の流れをみてみる。


ファンクションの抽出と識別

初めに、ファンクションを抽出、識別する。そもそも「ファンクション」とは、FP 法にもとづいて抽出された AP の『機能』のこと。全部で 5 種類ある。イメージ優先で、超コンパクトにメモしておく。

  • データファンクション(DF):ユーザが認識できる論理データ
    • ILF(内部論理ファイル)… 境界内で維持管理*2
    • EIF(外部 I/F ファイル)… 境界内から参照のみ
  • トランザクションファンクション(TF):ユーザにとって意味があるデータの入出力
    • EI(外部入力)… 境界外から ILF に維持管理
    • EO(外部出力)… 境界外に出力(加工あり)
    • EQ(外部照会)… 境界外に出力(加工なし)

これらが『機能』。

DF であれば「DFD」,「ER 図」などから抽出し、ILF と EIF を見つける。TF であれば「業務フロー図」,「画面設計書」,「帳票設計書」などから抽出し、EI, EO, EQ を見つける。


ILF, EIF および EI, EO, EQ を見つけたら、それぞれの複雑度を判定し、点数化していく。 複雑度は、Low(低), Average(中), High(高)の 3 段階で判定する。ざっくり 3 段階。どうせ一定のブレ幅があるのに、これ以上細かく基準を設けても、手間ばかりかかるからなのだろう。

具体的にどうやるのか、以下に、簡単にメモしておく。


DF の複雑度の判定と点数化

まずは、DF の複雑度の判定から。複雑度は、DET と RET の相関で決まる。間違いを恐れず、この 2 項目のイメージをメモする。

  • DET(データ項目数):ユーザが認識できる、データの項目数*3
  • RET(レコード種類数):データのサブグループの数

データの項目数と、サブグループの数を分けて数えるのは、なんとなく納得できる。いくらテーブルの項目数が少なくても、参照するテーブルのリストが多い場合には、処理が複雑になりやすい*4だろう。

それぞれ計測し終えたら、次の表*5に従って複雑度を判定し、点数化する。

f:id:higher_tomorrow:20170402174934p:image:w480


TF の複雑度の判定と点数化

次に TF の複雑度の判定。DF と同様、間違いを恐れずイメージだけをメモする。DF の DET の計測の粒度を考えると、画面や帳票だって、同様に数えると考えるのが自然だろう。

ここで、FTR の考え方が面白い。いくら画面の項目数が多くても、1 テーブルの内容を出力するだけの機能は、小さな機能だ。確かに、要件定義 〜 外部設計あたりのフェーズでは、こうやって複雑度を算出するしかない気がする。

  • FTR(関連ファイル数):処理を行うときに、参照・維持管理される DF*6
  • DET(データ項目数):境界をまたぐデータのうち、ユーザが認識できるデータの項目数*7

DF の場合同様、それぞれ計測し終えたら、次の表に従って、複雑度を判定し、点数化する。

ちなみに、EQ と EO の複雑度の判定は、全く同じ表を用いる。しかし、EQ よりも EO の方が高い点数がつくようになっている。

f:id:higher_tomorrow:20170402131836p:image:w480

f:id:higher_tomorrow:20170402131834p:image:w480

f:id:higher_tomorrow:20170402131831p:image:w480


複雑度の判定の具体例

例として、次の図のような、帳票を出力する処理における「発注情報の ILF」および「発注書を出力する EO」を考える。これで DET, RET および FTR, DET を計測するイメージがつかめるはず。


f:id:higher_tomorrow:20170402204903p:image:w480


ここで、「発注書を出力する」ファンクションが EO になっているのは、発注書に「合計」の欄があり、出力時に演算しているから。ただ、EO と EQ は、どこで線引きするのか、正直、よくわからない。

さて、前述したマトリクスを用いて、FP を計測しよう。「発注情報の ILF」は、DET = 8, RET = 2 なので、複雑度は L(低)。なので、7 FP。一方、「発注書を出力する EO」は、DET = 11, FTR = 3 なので、複雑度は A(中)。なので、5 FP。


せめて、これくらいは、頭に残しておきたい。

*1情報処理技術者試験で出題される程度の知識しかなかったし、興味もなかった。特に昔は、KKD(経験・勘・度胸)が好きだったからなぁ。

*2:登録、変更、削除などの処理をいう。

*3レコード数ではない。

*4:実装する場合には、SQL も大きくなるし、パフォーマンスもおちやすい。

*5:この表は、どうやって作ったのだろう?

*6:参照される ILF or EIF および、維持管理される ILF。

*7:やはり、繰り返しや重複を除く。

トラックバック - http://d.hatena.ne.jp/higher_tomorrow/20170408/1491609957