直前もいいところですが、今回はファンクションポイント法について改めてやる。
あくまで試験対策の観点で扱うので、実践的に使えるレベルまではやりません。
PM試験的には午後Ⅰでがっつり出たという話も聞かないですし、午後Ⅱの論文でツールとして使用できるレベルで十分ではないかと考えています。
ファンクションポイント法
ファンクションポイント法(ファンクションポイントほう、英: function point method)とは、1979年にIBMのアレン・J・アルブレヒト(A.J.Albrecht)が考案したソフトウェアの規模を測定する手法の1つ。ソフトウェアがもつ機能数や複雑さによって重みづけした点数(ファンクションポイント:FP)を付け、そのソフトウェアにおける合計点数から開発工数を見積もる。米国International Function Point Users Group(IFPUG)によってマニュアルが策定された。
理解レベル1
まずはざっくりとした理解で認識を合わせます。
ファンクションポイント法(以下、FP法)はソフトウェアの規模を測定する見積り技法です。
FP法自体には工数やコストを計測するための技法ではないと言われています。
FP法自体は工数を算出しないと言っても見積りを行うということはほとんどの場合は工数やコストを算出することになると思います。
しかし、まだコードにもなっていない、場合によっては設計書もないソフトウェアから工数を見積もることは困難なので、FP法を用いることによって、ソフトウェア規模の定量化を行うことになります。
ファンクションとは機能ことであり、FP法では機能を洗い出しそこに複雑さや重みを掛け合わせることでソフトウェアの規模を計測することになります。
理解レベル2
PM試験で活用できる程度まで理解を深めます。
FP法では機能を抽出する際にデータファンクションとトランザクションファンクションに分類を行います。
午前Ⅱ試験にて頻出ポイントになるので、PM試験を受けるなら名称ぐらいは押さえていて当然のレベルになりますが以下のような分類となります。
また、正確にはFP法の中のIFPUG法で使われる単位になりますが、試験的にはそこまで意識しなくてもいいと思っています。
ざっくり言うと、データファンクションがデータのまとまりを表し、トランザクションファンクションがデータ処理に関する機能となります。
■機能数の抽出
これを基準にアプリケーションからファンクションを切り出し、適切な複雑さを分類していきます。
また、実際にはデータファンクションにおけるテーブルの項目数で複雑さを決定するなど、設定基準が重要となりそうです。
■重みの決定
次に複雑さに応じた重みを決定します。
■未調整ファンクションポイント算出
最終的に、ファンクション数と重みを掛けわせることによって、未調整ファンクションポイントを決定します。
今回は868とでました。
ここまでのポイントを未調整ファンクションポイントと設定します。
■補正値の決定
詳細は省略しますが、分散処理性、応答性能、などシステムの特性から影響度を決定します。
影響度から補正係数を算出することができます。
補正係数=影響度の合算×0.01+0.65
ここでは仮に補正係数を0.9とします。
■調整済みファンクションポイント算出
最終的に未調整ファンクションポイントと補正係数から調整済みファンクションポイントを算出します。
調整済みファンクションポイント=未調整ファンクションポイント×補正係数
最終的に調整済みファンクションポイントは「781」と算出できました。
■最後に
ファンクションポイント法として開発規模を算出する上記までで完了します。
ただ、見積りは一般に工数などを算出するためのものなのでファンクションポイントを算出後、開発生産性で割ることによって工数に落とし込みます。
例えば、開発生産性(FP数/人月)が「100」とすると以下のように算出することができます。
781÷100=7.8人月
開発生産性は開発言語などによって定まるものなのケースによってFP数が異なっても工数が変わってくることになります。
PM試験観点で考える
ここでは、FP法をPM試験でどのように使用するか、どのようなことを気をつけるか考えていきます。
主に午後Ⅱ対策となりますが、正しさの保証はできないのであくまで参考程度に。
どんな問題で使用する可能性があるか
通常、ほとんどのプロジェクトでは見積りという作業は必要になりますが、PM試験ではどんな問題にでも使用するわけではありません。
見積り中心で話が進み、その根拠を示す必要になる問題で使用するのが一般的になるでしょう。
となるとコストが主題になる問題で、かつ見積りが絡んでくる問題なので必然的に使用する機会は少ないとも言えます。
具体的には「平成26年 問1」、「平成23年 問1」などが挙げられます。
どの工程で使うか
実際の見積りでもそうですが、見積りを行う工程によって用意できる情報の粒度が異なってくるため、見積もれる精度が変わってきます。
引用元:https://www.ipa.go.jp/files/000005108.pdf
PM試験では見積りを行った時期を明確に示す必要があります。また、見積りのための情報というのは用意しておく必要もあります。
例えば、システム計画時点では過去のプロジェクトから類推してファンクション数を決定する。
内部設計以降を請負契約で開発するために外部設計が完了した時点で、実際に作成した設計書からファンクション数を抽出してより正確に見積る。
なども考えられます。
FP法を使用する理由は
FP法の特徴は「利用者機能要件を定量化して得られるソフトウェアの規模を計測すること」ということが挙げられます。
つまりは、利用者が認識できる機能から見積りとなるため、ユーザに対して根拠の説明が行いやすいということになります。
過去の実績をベースとする類推法との比較としては、理論上は実績がないシステム開発であっても見積りを行うことができます。
また、システム開発の各工程に対して適用することできるという点も特徴の一つとなりますが、それだけでは適用する理由としては弱い気もします。
見積りにおける工夫点は
PM試験では各種取り組みの中での工夫を求められることも多いです。
私の考えとしては、やっていることは基本的なことでよく、具体的な内容をプロジェクトの特徴と関連付けることで臨場感を出せばよいと考えています。
また、工夫については成果をプラスするための取り組みというよりは、そのままやると失敗するので工夫を行うという流れになることが多いと感じます。
見積りで言えば「精度が求められる」、「不完全な情報」などが工夫を実施した点になりやすい。
これは問題文から求められることもあれば、プロジェクトの制約から必要になる場合もあるでしょう。
このための工夫が高度な内容になっているかというよりは、そのようにした必要性が高くなっているかという点がポイントになってくると考えます。
・自組織で初めて取り組む開発言語のシステム
⇒調査機関の公表値に補正をかける⇒先行開発により補正値を決定する
・計画時点で未決事項(情報欠損)が存在する
⇒未決事項(情報欠損)の有無で見積り範囲を変える⇒未決事項が存在する部分は類推法を用いる
「工夫が必要な理由」と「精度が必要な理由」は問題の展開によって異なってくるので注意した方がよいかもしれない。
精度はプロジェクトの制約でコスト面のオーバーが許されないことから引っ張ってくる場合が多い。
と思う。