(57)【要約】      （修正有）【課題】ソフトウェア開発における機能規模予測の精度を上げるとともに、機能規模の増減が発生した箇所の特定を容易にし、さらにこれらに要する工数を削減する。【解決手段】ソフトウェアのコンポーネントごとに仕様情報の入力を受付け、コンポーネントごとに仕様明確度に応じた適切な段階で、各コンポーネント及びソフトウェア全体の機能規模を測定する。前段階の仕様情報が入力されている場合は、前段階の仕様情報から引継ぎ可能な仕様情報を生成し、生成した仕様情報の編集と追加入力を受付け、各コンポーネント及びソフトウェア全体の機能規模を再測定する。【選択図】図１
2006119785.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェアの機能規模を、コンピュータを用いて測定する機能規模測定方法において、
仕様明確度と対応した複数の測定を実行するために、
測定対象であるソフトウェアを目的もしくは機能別にいくつかに分割したものであるコンポーネントごとに、機能規模の算出基礎となる情報である仕様情報を入力し、
前記コンポーネントごとに、入力された前記仕様情報をもとに、仕様明確度と対応した複数の測定の段階の中から、各コンポーネントの仕様明確度に応じた段階を選択し、
前記コンポーネントごとに選択された段階を用いて、前記コンポーネントごとの機能規模及びソフトウェア全体の機能規模を測定することを特徴とする機能規模測定方法。
【請求項２】
請求項１に記載の機能規模測定方法において、
さらに、
任意の段階で必要な仕様情報を入力する際に、それよりも前段階で仕様情報が入力されている場合、前段階で入力されている仕様情報から引継ぎ可能な仕様情報を生成し、
生成された仕様情報を編集して、他の仕様情報を追加入力し、
生成・編集・追加入力された仕様情報から、その仕様明確度に応じた段階でコンポーネントの機能規模を再測定し、ソフトウェア全体の機能規模を更新することを特徴とすることを特徴とする機能規模測定方法。
【請求項３】
ソフトウェアの機能規模を、コンピュータが測定するための機能規模測定プログラムにおいて、
仕様明確度と対応した複数の測定を実行するために、
測定対象であるソフトウェアを目的もしくは機能別にいくつかに分割したものであるコンポーネントごとに、機能規模の算出基礎となる情報である仕様情報を入力する機能、
前記コンポーネントごとに、入力された前記仕様情報をもとに、仕様明確度と対応した複数の測定の段階の中から、各コンポーネントの仕様明確度に応じた段階を選択する機能、
前記コンポーネントごとに選択された段階を用いて、前記コンポーネントごとの機能規模及びソフトウェア全体の機能規模を測定する機能を有することを特徴とする機能規模測定プログラム。
【請求項４】
請求項３に記載の機能規模測定プログラムにおいて、
さらに、
任意の段階で必要な仕様情報を入力する際に、それよりも前段階で仕様情報が入力されている場合、前段階で入力されている仕様情報から引継ぎ可能な仕様情報を生成する機能、
生成された仕様情報を編集して、他の仕様情報を追加入力する機能、
生成・編集・追加入力された仕様情報から、その仕様明確度に応じた段階でコンポーネントの機能規模を再測定し、ソフトウェア全体の機能規模を更新する機能を有することを特徴とすることを特徴とする機能規模測定プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はソフトウェア開発におけるソフトウェアの機能規模の測定に関する発明である。
【背景技術】
【０００２】
ソフトウェア開発プロジェクトで開発コストを見積る際には、まずソフトウェアの仕様情報をもとに機能規模測定法を用いて機能規模を測定する。
【０００３】
ここで、機能規模とは、ソフトウェアが提供する機能の量をあらわすもので、例としては画面数やファンクションポイントがある。
【０００４】
機能規模の測定には、非特許文献１で示されているようないくつかの機能規模測定方法がある。ソフトウェアの機能規模にファンクションポイント法を適用した場合の機能規模測定の基本的な仕掛けについては、特許文献３で示されているようなものがある。
【０００５】
仕様情報とは、機能規模の算出基礎となるソフトウェアの仕様に関する情報を意味する。ファンクションポイント法を用いた場合、機能数やファイル数等の項目がこれに該当する。
【０００６】
尚、この明細では機能規模の「測定」という言葉は、機能規模の「実測」及び「予測」の意味で用いる。1つの機能規模測定法には、仕様明確度と対応した複数の測定の段階が存在し、それぞれの段階は測定精度が異なる。ファンクションポイント法の場合、(1)低精度の測定の段階：機能数、ファイル数からの測定  (2)高精度の測定の段階：機能の入出力項目数、機能が扱うファイル数、ファイルのデータ項目数  という例が考えられる。(1)の場合は機能規模の「予測」になり、(2)の場合は「実測」となる。機能規模は「実測」することができるが、実測するために必要な仕様情報がわからない場合は、より少ない仕様情報から機能規模を「予測」できる簡易法を用いる。機能規模を「実測」できるのは、最も高精度な測定の段階のみであり、それ以外の「より低精度」な段階を用いた場合は、機能規模の「予測」である。
【０００７】
また、「段階」という言葉は、機能規模を実測及び予測するための方法の１つを指す。また「測定精度」とは、機能規模を「予測」した場合に、「実測」した場合の機能規模にどれだけ近いかということを意味する。
【０００８】
開発コストの見積りは、測定した機能規模をもとに、工数、コストを見積るという手順がとられる。このようなソフトウェア開発プロジェクトでの開発コストを見積る仕掛けについては、特許文献１、特許文献２に示されているようないくつかのものがある。
【０００９】
それぞれの機能規模測定法には、仕様明確度と対応した複数の測定の段階が存在し、それぞれの段階は、必要とする仕様情報が異なる。
【００１０】
機能規模を測定するための仕様情報をより多く必要とする段階は、高精度で機能規模を測定できる。逆に必要とする仕様情報が少ない段階での機能規模の測定は低精度である。
プロジェクトの初期段階ではソフトウェアの仕様明確度が低いため、高精度な段階で測定することは難しく、より低精度な段階で機能規模の測定を行う。
ここで、仕様明確度とは、プロジェクトの任意の時点でのソフトウェアの仕様の明確さの程度をあらわす。通常、ソフトウェア開発プロジェクトではプロジェクトの進行とともにソフトウェアの仕様が徐々に明確になっていく。その明確さの程度をあらわすものである。仕様明確度が低いと機能規模の測定に必要となる仕様情報は少ない。
【００１１】
プロジェクトの進行に伴って仕様明確度は高くなり、より高精度な段階で測定するために必要な仕様情報がわかるようになるため、プロジェクトの進行に伴いより高精度な段階での測定を実施する。プロジェクトではこの手順で機能規模の測定を繰り返し、機能規模の測定精度を高めると伴に、機能規模の増減の管理に利用する。このような手順を実施することで、プロジェクトのコストの見積精度を高めることができると伴に、プロジェクトにおけるコストの増減を管理することができる。
【００１２】
【特許文献１】特開２００３−２６３３２０号公報
【特許文献２】特開２００３−３０８４４９号公報
【特許文献３】特開平１１−１６１４８５号公報
【非特許文献１】ISBN: 432009722X「ソフトウェア開発の定量化手法第2版」
【発明の開示】
【発明が解決しようとする課題】
【００１３】
ソフトウェアの機能規模の測定は背景技術で示したような方法がとられている。このような従来の方法(背景技術)では、プロジェクトの任意の時点で機能規模の測定を行う際には、前段階での測定結果に関係なく、１つの段階でソフトウェア全体の機能規模を一括で測定していた。それぞれの段階ごとに入力となる仕様情報は異なるため、前段階の測定結果を元にして測定を行うことは困難であり、またソフトウェアの機能規模をコンポーネントごとに測定することも困難であった。そのため、前段階での測定結果に関係なく、ソフトウェア全体の機能規模を一括して測定する必要があった。
【００１４】
尚、本明細書では、「コンポーネント」とは、「ソフトウェアを目的や機能別にいくつかに分割したもの」という意味で用いている。
【００１５】
しかし、このことにより、下記３点の問題点があった。1つ目の問題点としては、プロジェクトの任意の時点で機能規模を測定する際に、実際の仕様明確度に応じた段階を適用できないという問題点があった。従来の方法ではソフトウェア全体を一括で測定するため、仕様明確度が最も低いコンポーネントの機能規模を測定できる段階でしか測定できないという問題点があった。通常、プロジェクトではコンポーネントによって、進み具合に差があることが多く仕様明確度も異なることが多い。ソフトウェア全体を一括で測定するには、全てのコンポーネントでわかっている仕様情報から測定できる段階で測定する必要があり、必然的に適用される段階は、最も進み具合が悪く、仕様明確度の低いコンポーネントを測定できる段階となる。そのため、仕様明確度の高いコンポーネントでも、その仕様明確度に見合った高精度の段階で測定できない場合がしばしば発生していた。
【００１６】
2つ目の問題点としては、機能規模の増減の管理において、機能規模の増減が発生した箇所を特定しにくいという問題点があげられる。そのため、全体の規模の増減の管理は容易であったが、各段階によって仕様情報が異なるため、前段階の測定結果との対応がとれず、ソフトウェアのどの部分に機能規模の増減が発生しているかを特定することは困難であった。このことにより、ソフトウェアの機能規模全体に大きな増減があった際に、機能規模の増減が発生した箇所を特定しづらく、原因が把握できないという状況がしばしば発生していた。
【００１７】
3つ目の問題点として、測定工数がかかるという問題点があげられる。プロジェクトでは仕様明確度の向上とともに機能規模の測定を繰り返すが、測定のたびに、前段階の測定結果に関係なく、１からソフトウェア全体の機能規模を計測することになるため、測定工数がかかってしまうという問題点があった。
【課題を解決するための手段】
【００１８】
上記の、プロジェクトの任意の時点で機能規模を測定する際に、実際の仕様明確度に応じた段階で測定できないという課題を解決するため、本発明では、ソフトウェアのコンポーネントごとに仕様情報の入力を受付け、入力された仕様情報からそのコンポーネントの仕様明確度に応じた段階を選択し、入力された仕様情報をもとに、選択された段階を用いて、各コンポーネント及びソフトウェア全体の機能規模を測定して測定結果を出力し、コンポーネントごとに、入力された仕様情報、選択された段階、測定結果を保存する処理を有することを特徴とする。
【００１９】
上記の、機能規模の増減の管理において、機能規模の増減が発生した箇所を特定しにくいという課題及び測定工数がかかるという課題を解決するため、本発明では、前段階の仕様情報から引継ぎ可能な仕様情報を生成し、生成した仕様情報に対する編集を受付け、他の仕様情報の追加入力を受付け、そのコンポーネントの仕様明確度に応じた段階を選択し、各コンポーネント及びソフトウェア全体の各機能規模を再測定して出力する手段と、コンポーネントごとに生成された仕様情報、追加入力された仕様情報、仕様明確度に応じた段階、測定結果を保存する手段を有することを特徴とする。
【発明の効果】
【００２０】
本発明では、コンポーネントごとにその仕様明確度に応じた適切な段階を選択して測定することにより、ソフトウェアの機能規模を測定する際にコンポーネントごとに異なる段階で機能規模を測定することが可能となる。
【発明を実施するための最良の形態】
【００２１】
以下に本発明の実施の形態を説明する。
【実施例１】
【００２２】
まず、実施例１について、説明する。はじめて規模を測定する際のプログラムのフローチャートを図１に示す。
【００２３】
本プログラムは，ソフトウェアのコンポーネントの仕様に関する情報を入力されると，そのコンポーネントに最適な規模測定段階を選択し，選択した段階の処理ロジックに基づいて規模の算出を行う。
【００２４】
本プログラムを実行するハードウェアとして，図２のように１台のコンピュータで実行する場合や，図３のように複数台のコンピュータが連携して実行する場合がある。
【００２５】
ここでは規模の尺度としてファンクションポイント（以下FPと略記）法を例に取る。FP法は下記の手順によりソフトウェアの規模を測定する。
（１）            ソフトウェアを要素処理に分解する。
（２）            各要素処理の種別（これをファンクションタイプという）と複雑さから要素処理のFPを算出する。
（３）            すべての要素処理のFPを合計する。
【００２６】
FPを正確に実測するためには，詳細な仕様情報が必要であるが，開発の途中の段階では，これらの情報が正確ではないため，正確に把握できる仕様情報を基にFPを予測することになる。FPを予測または実測する算出式として本プログラムでは規模測定段階１〜３をあらかじめ定義している。図４は規模測定段階１〜３において，どのような仕様情報が入力されれば算出可能かを示す。この図から，段階１は最も予測精度が低く，段階３は最も予測精度が高いことがわかる。このような規模測定段階は，FP法以外の規模尺度に対しても設定できる。
【００２７】
図５は、あるソフトウェアを構成するコンポーネントの一部について，仕様情報の状態と各コンポーネントで適用可能な規模測定段階を示している。例えば，コンポーネントA.情報照会は，要素処理数だけがわかっており，他の仕様情報はわかっていない状況にある。これを図４に照らすと，規模測定段階１は適用できるが段階２は適用できないことがわかる。一方，コンポーネントB.情報登録は，要素処理の複雑さまでわかっており，図４から規模測定段階３が適用できることがわかる。このように，コンポーネントによって仕様の明確さ度合が異なる場合でも，適切な規模測定段階を適用することによって，よりよい精度で規模を把握することが可能になる。
【００２８】
各コンポーネントで適用する規模測定段階を判断した後，定義された算出手順により各コンポーネントの規模を算出する。算出手順が図６，７のように定義されているとすると，各コンポーネントの規模は図６のようにして算出することができる。
【実施例２】
【００２９】
次に、実施例２について、説明する。過去に規模を測定しているソフトウェアに対して，開発が進行したため再度規模を測定する際のプログラムのフローチャートを図８に示す。
【００３０】
記憶装置に格納された前回までの規模測定に関する情報を表示し，開発の進行によって変更が生じた仕様情報を入力および修正していく。
【００３１】
例えば，実施例１の状況から仕様情報が図９のように変化したとする。これはコンポーネントA.情報照会の仕様がより明確になったことを表している。このとき本プログラムは下記のような動きをする（図10参照）。
（１）            記憶装置に格納していた前回までの規模測定に関する情報を基に，より詳細な仕様情報を自動生成する。この例では，２個の要素処理データを生成し要素処理名に仮の名前を付与している。
（２）            この情報を表示し，ユーザから入力および修正を受け付ける。この例で，ユーザは要素処理名を意味あるものにし，各要素処理のファンクションタイプを入力している。複雑さはこの時点ではまだわからないので入力していない。
（３）            ファンクションタイプが入力されたことから，本プログラムは，図４に照らしてコンポーネントA.情報照会の機能規模測定段階が前回の段階１から段階２に上がったことを認識し，段階２による規模の再算出を行う。再算出の結果は図11のようになる。
このようにして，上位の規模測定段階で規模を測定する際，下位の規模測定段階適用時に入力した仕様情報を引き継ぐことにより規模測定の継続性を維持する。
【００３２】
以上の本発明の実施の形態によれば、機能規模の増減が発生した際に、実際の仕様明確度に応じた段階を適用できないという問題が解消される。また、より低精度の段階で使用している仕様情報をもとにより高精度の段階で使用する仕様情報の一部を生成することで、前段階での測定結果との対応付けが容易になり、増減が発生した箇所の特定が困難であるという問題が解消され、また１から測定する必要がなくなり測定工数を大幅に削減することが可能となる。
【図面の簡単な説明】
【００３３】
【図１】本発明を実現巣するプログラムのフローチャートの例（その１）
【図２】本発明を実行するハードウエアの例（その１）
【図３】本発明を実行するハードウエアの例（その２）
【図４】規模測定段階と入力情報の関係の例
【図５】コンポーネントごとの使用情報と適用可能な測定段階の例（その１）
【図６】測定段階別のＦＰ規模算出式と算出例
【図７】ファンクションタイプと複雑さによるFP規模点数表
【図８】本発明の実現するプログラムのフローチャートの例（その２）
【図９】コンポーネントごとの使用情報と適用可能な測定段階の例（再測定時）
【図１０】規模測定段階が上がった場合のデータ引継ぎの例
【図１１】測定段階別のＦＰ規模算出式と算出例（再測定時）
【符号の説明】
【００３４】
１００…データ入出力装置、１０１…演算装置、１０２…記憶装置
【図１】
2006119785.tif 000003
【図２】
2006119785.tif 000004
【図３】
2006119785.tif 000005
【図４】
2006119785.tif 000006
【図５】
2006119785.tif 000007
【図６】
2006119785.tif 000008
【図７】
2006119785.tif 000009
【図８】
2006119785.tif 000010
【図９】
2006119785.tif 000011
【図１０】
2006119785.tif 000012
【図１１】
2006119785.tif 000013