JP2006323851A

JP2006323851A - ソフトウェア開発工数費用の評価装置

Info

Publication number: JP2006323851A
Application number: JP2006157706A
Authority: JP
Inventors: Kinfuku Ryu; 錦福劉; Yoshihiro Nakano; 義弘中野
Original assignee: TEIKOKU DATABANK Ltd
Current assignee: TEIKOKU DATABANK Ltd
Priority date: 2004-03-02
Filing date: 2006-06-06
Publication date: 2006-11-30

Abstract

【課題】ソフトウェア開発工数費用の評価を客観的にかつ公正な手法で行い得るソフトウェア開発工数費用の評価装置を提供する。
【解決手段】ソフトウェアの開発言語別の生産性を定量化した生産性値を記憶するテーブルと、生産性値を調整する係数としてシステム規模をファンクションポイント（ＦＰ）値の量によって分類して定量化したシステム規模係数、及びシステム環境をその形態によって分類して定量化したステム環境係数を含む各係数を記憶するテーブルとを有するデータベースと、入力画面上で操作手段により指示された変動要素の入力情報と前記データベースを検索して前記変動要素に対応する生産性値及び前記各係数の情報とを取得する手段と、該情報を用いて、当該ソフトウェアの機能規模を表わすＦＰ値に重み付けを行い、工程毎の開発工数／費用の評価情報を生成する手段と、該評価情報を全工程及び工程別に表す画像を生成して表示する手段とを備える。
【選択図】図５

Description

本発明は、コンピュータシステム、ネットワーク等を構成するソフトウェアの開発工数費用の価格（見積り額）を、できるだけ客観的にかつ合理性をもって評価するためのソフトウェア開発工数費用の評価装置及びソフトウェア開発工数費用見積りプログラム並びにソフトウェア開発工数費用見積りプログラムを記憶した記憶媒体に関する。

情報システムが業務や社会の隅々まで浸透し、それに伴う情報システムの投資が膨大になってきており、その中でもソフトウェア開発費が大きな割合を占めている。しかしながら、ソフトウェア開発費（評価）の見積りプロセスが構造化されていないため、ベンダーから提示された見積りは往々にして明確な根拠が示されないまま、発注・システム構築等の業務が遂行されてしまうのが実情である。

従来コンピュータシステムを構成するソフトウェアの開発工数費用を見積る場合、ソフトウェアの規模や作業内容を考慮して開発工数費用を算出することが一般的である。そのため、ソフトウェア開発工数費用の見積りや評価作業は、ソフトウェア開発作業を永年従事したエキスパートと称されるような特定な人の経験と勘に依存することが多い。

ソフトウェア開発工数費用を見積ったり評価する手法として、ＬＯＣ（Lines of Code:プログラム行数）法が存在するが、1990年代からＩＴ技術の進歩に伴い、システム構成と開発手法の多様化と複雑化が進み、もはやプログラム行数の量と開発工数、費用との相関関係が崩れ、ＬＯＣ法で培ってきた経験や勘に基づいて見積ることに限界が来ている。そこで、ＬＯＣ法の代わりにＦＰ（Function Point：機能規模）法が注目されるようになった。ＦＰ法はソフトウェアが持つ機能の量を計測する手法であり、図１に示すようにシステム仕様書から規模を定量的に計測してソフトウェア機能規模を計るものである。ソフトウェアの開発工数や費用を算定する際に使用されているＦＰに対する評価額は、一般的に図２に示すような２次関数となっている。

また、特開２００２−２２２０８０（特許文献１）のソフトウェア見積りシステムでは、ソフトウェアの機能情報が記憶された機能情報記憶部と、この機能情報記憶部に記憶された機能情報から開発するソフトウェアプロジェクトの機能情報を選択する機能情報選択部と、この機能情報選択部によって選択された機能情報を用いて上記ソフトウェアプロジェクトの機能量を計算する機能量計算部とを設けている。業務分野と規模を開発費用の見積りに利用している。

特開２００３−２６３３２０（特許文献２）の見積り作業支援システムは、開発対象システムの見積り作業を支援する見積り作業支援システムであり、開発対象システムのソフトウェア規模を見積るための規模見積り条件を入力し、規模見積り条件に基づいてソフトウェア規模を見積るソフトウェア規模見積り手段と、開発工数を見積るための工数見積り条件を入力し、工数見積り条件に基づいて開発工数を見積る開発工数見積り手段と、開発コストを見積るためのコスト見積り条件を入力し、コスト見積り条件に基づいて開発コストを見積る開発コスト見積り手段と、ソフトウェア規模の見積り結果、開発工数の見積り結果、および開発コストの見積り結果を、見積り作業を行う作業者に提示する見積り結果提示手段とを設けている。開発費用の見積りは、工数に対する単金の乗算値に間接費用を加算している。

更に、特開２００３−３０８４４９（特許文献３）のシステム開発見積支援システムは、開発対象となるシステムの規模の情報であるシステム規模情報を算出するための規模算出情報と、システム開発に要する人員や期間である開発工数情報を算出するための開発工数算出情報とをクライアントマシンから受信する情報受信手段と、前記情報受信手段によって受信した前記規模算出情報及び前記開発工数算出情報を記憶する記憶手段と、前記記憶手段に記憶された前記規模算出情報に基づいてシステム規模情報を算出するための規模算出関数情報と、前記開発工数算出情報に基づいて開発工数情報を算出するための開発工数算出関数情報とを記憶する算出関数情報記憶手段と、前記開発工数情報を算出する見積算出手段と、前記見積算出手段によって算出された開発工数情報と前記規模算出情報とを関連付けて記憶する開発工数情報記憶手段と、前記開発工数情報記憶手段に記憶された前記開発工数情報を前記クライアントマシンに送信する情報送信手段と、これら各手段の動作を制御する処理装置とを備えたシステム開発見積支援システムであって、前記処理装置は、前記見積算出手段に、前記算出関数情報記憶手段に記憶された前記規模算出関数情報と前記記憶手段に記憶された前記規模算出情報とを取得させ、これら情報に基づいてシステム規模情報を算出させ、前記算出関数情報記憶手段に記憶された前記開発工数算出関数情報と、算出された前記システム規模情報と、前記記憶手段に記憶された前記開発工数算出情報とを取得させ、これら情報に基づいて前記開発工数情報を算出させるものである。
特開２００２−２２２０８０特開２００３−２６３３２０特開２００３−３０８４４９

上述のように従来の一般的評価方法ではその評価値に客観的で合理的な根拠がなく、果たして適正な評価額であるか否かが問題であり、ソフトウェア開発工数費用の評価を客観的に合理性をもって実行できることを、発注者側及び受注側共に強く望んでいた。ＦＰ値を用いた評価法も同様である。

特許文献１に記載のソフトウェア見積りシステムでは、開発分野毎にＦＰ算出に必要な情報を予め準備しておき、それらを呼び出してソフトウェア見積りに利用するようにしており、情報管理が煩雑であるという問題がある。開発言語別生産性は考慮されておらず、生産性調整も不可であり、費用見積りが不完全である。

また、特許文献２に記載の見積り作業支援システムは開発工数の見積り及び開発コストの見積りという一連の見積り作業全体を支援できるようにしているが、開発対象システムのソフトウェア規模を見積もるための規模見積り条件を入力し、規模見積り条件に基づいてソフトウェア規模を見積り、開発工数を見積もるための工数見積り条件を入力し、工数見積り条件に基づいて開発工数を見積り、開発コストを見積もるためのコスト見積り条件を入力し、コスト見積り条件に基づいて開発コストを見積もるようにしているので、開発コストを迅速に得ることができない。開発言語別生産性値は考慮されておらず、生産性調整係数が提供側向けであり、調達側が利用できない問題がある。

特許文献３は調整係数に提供側（開発業者）向けの観点が強く、調達側（ユーザ企業）の観点と異なっている問題がある。例えば提供側の開発言語経験年数、リーダのプロジェクト管理経験、開発支援ツールへの習熟度など、提供側の努力事項を開発工数費用の見積りに反映してしまうと、これは提供側から調達側へのコスト転嫁ということになる。特許文献３に記載のシステム開発見積支援システムでは、開発言語別生産性値は考慮されていない。また、調整係数を主観的に設定し、かつ調整係数の設定が煩雑であり、実務上もっと簡便で、誰からも設定方法を見れば同じ結果が設定されるような客観的な設定方法が求められている。

更に、上記特許文献１乃至３に記載のものは、いずれも新規案件についての見積りであり、改修案件への対応ができない問題がある。実務上システム案件の６０〜８０％程度が保守案件であると言われ、これに対応できなければビジネス効果が半減してしまう。

本発明は上述のような事情よりなされたものであり、本発明の目的は、ソフトウェア開発工数費用の評価を客観的にかつ公正な手法で、しかも簡易なシステムで合理性をもって行い得るソフトウェア開発工数費用の評価方法、評価値算出装置及びプログラムを提供することにある。即ち、本発明は、多様な環境や種々の開発言語に対応可能であり、多数の企業に利用され、客観的に比較・検証可能であり、実装に左右されずに論理的視点に立ち、関係者の納得と理解が得られ、システム構築の早期段階での計測が可能で、属人性を排除したアプローチが可能なソフトウェア開発工数費用の評価装置及びソフトウェア開発工数費用見積りプログラム並びにソフトウェア開発工数費用見積りプログラムを記憶した記憶媒体を提供することを目的とする。

本発明はソフトウェア開発工数費用の評価装置に関し、本発明の上記目的は、ソフトウェアの機能規模を表わすファンクションポイント値を基本として、評価対象のソフトウェアの開発状況及びシステム環境を考慮した評価要素に基づいて前記ファンクションポイント値に重み付けを行い、前記ソフトウェアの開発工数／費用を評価する評価装置であって、ソフトウェアの一人月当たりの開発言語別の生産性を定量化した生産性値を記憶する開発言語別生産性値テーブルと、前記生産性値を調整する係数として、システム規模を前記ファンクションポイント値の量によって分類して定量化したシステム規模係数、及びシステム環境をその形態によって分類して定量化したステム環境係数を含む各係数を記憶する生産性調整係数テーブルと、ソフトウェアの開発言語とその利用割合、前記システム環境の分類項目、前記システム規模の分類項目、及びシステムエンジニア単価金額を含む情報の入力画面を表示する表示手段と、前記入力画面上で選択された前記開発言語を基に前記開発言語別生産性値テーブルから得た前記ソフトウェアの開発言語に対応する前記生産性値、及び前記入力画面上で入力された前記利用割合に基づいて、ソフトウェア言語を評価要素とした前記ソフトウェアの開発言語別生産性値を算出する手段と、前記入力画面上で選択された前記システム規模の項目及び前記システム環境の項目を含む各項目に対応する係数を前記生産性調整係数テーブルから得て、それらの係数を生産性調整係数として設定する手段と、前記ソフトウェアの基本設計、詳細設計、プログラム設計・製造、ソフトウェアテスト及びシステムテストの各工程における前記開発言語別生産性値及び前記生産性調整係数、並びに、前記各工程における工程別発注率、前記ソフトウェアの発注側と受注側との作業比率を示す作業分担率及び既存システムに対する改修の割合を示す改修率の入力情報に基づいて前記ソフトウェアの生産性係数を算出する手段と、前記各工程における前記ファンクションポイント値を前記生産性係数で除算して前記ソフトウェアの標準開発作業工数を算定する開発工数算定手段と、前記標準開発作業工数、及び前記システムエンジニア単価金額の入力情報に基づいて前記ソフトウェアの開発費用を算定する開発費用算定手段と、前記開発工数算定手段により算定した前記標準開発作業工数、及び前記開発費用算定手段により算定した前記開発費用を前記ソフトウェアの開発工数／費用の評価情報として出力する評価情報出力手段とを備えることによって達成される。

また、本発明の上記目的は、前記評価要素として業者提示価格を含み、前記評価情報出力手段は、前記開発費用算定手段により算定した前記開発費用を評価用基準価格として、その評価用基準価格と前記入力画面上で入力された前記業者提示価格とを対比させた情報を出力すること、前記評価情報出力手段は、前記標準開発作業工数の合計及び前記開発費用の合計を出力すると共に、前記標準開発作業工数及び前記開発費用を前記工程別に出力することによってそれぞれ一層効果的に達成される。

また、本発明の上記目的は、前記生産性調整係数テーブルには、データとプロセスの集中処理及び分散処理を含む処理形態に伴う開発作業負荷を前記処理形態によって分類して定量化した処理負荷係数、ユーザからの品質要求をその要求度合によって分類して定量化した品質要求係数、及び、ドキュメントに係る生産性をドキュメントの種類，数量によって分類して定量化したドキュメント係数が更に記憶されており、前記表示手段は、前記処理負荷係数の分類項目、前記品質要求係数の分類項目及び前記ドキュメント係数の分類項目の各選択メニューを前記入力画面に表示し、前記生産性調整係数を算出する手段は、前記各選択メニューの中から選択された前記処理負荷係数の項目、前記品質要求係数の項目及び前記ドキュメント係数の項目にそれぞれ対応する前記処理負荷係数、前記品質要求係数及び前記ドキュメント係数を前記生産性調整係数テーブルから得て、それらの係数、前記システム規模係数、及び前記システム環境係数に基づいて前記生産性調整係数を算出すること、前記各工程別に設定された標準発注率を記憶する開発工程別標準配分率テーブルを備え、前記生産性係数を算出する手段は、前記工程別発注率が入力されなかった場合は、入力されなかった工程に対応する前記標準発注率を前記開発工程別標準配分率テーブルから得て、該標準発注率を当該工程における前記工程別発注率として前記生産性係数を算出することによって、それぞれ一層効果的に達成される。

また、本発明の上記目的は、前記ソフトウェアが新規開発の場合は、前記改修率を１００％として前記ソフトウェアの生産性係数が算出されること、前記評価要素として、前記ソフトウェアの標準開発作業以外に発注者から提供者に委託された作業の工数を示す付帯作業工数を含み、前記開発費用算定手段は、前記標準開発作業工数と前記付帯作業工数との和に前記システムエンジニア単価金額を乗算して前記開発費用を算定すること、前記ファンクションポイント値は、ＩＦＰＵＧ（International Function Point Users Group）法、概算法、論理ファイル推定法又はステップ逆算法のいずれかを用いて算出したファンクションポイント値であることによって、それぞれ一層効果的に達成される。

本発明によれば、比較的簡易なシステムであると共に、ソフトウェア開発工数費用の開発や環境を考慮した要素を評価の条件として合理的に入力するようにしているので、ソフトウェア開発工数費用の評価を客観的かつ公正な手法で行い得る。また、本発明によれば、新規案件のみならず、改修案件についてもソフトウェア機能規模の定量化を通して見積り価格の曖昧さを排除でき、評価の合理性、妥当性、透明性を高めることができる。

本発明はＦＰ（ファンクションポイント）をソフトウェア評価の基本とし、ソフトウェアの開発状況やシステム環境を考慮した要素を評価の条件として重み付けを行って評価値演算に利用しており、また、評価のための入力条件が合理的な理由を有しているので、個人的な経験や勘に頼ることなく、客観性のある公正なソフトウェア開発費用の評価を得ることができる。

本発明は新規及び改修のいずれのソフトウェア開発案件を対象としているが、ハードウェア、ネットワーク、ミドルウェアなどの設計、導入作業費などは評価の対象としていない。また、システム開発プロセスのうち、ＳＬＣＰ(Software Life Cycle Process: ソフトウェアを中心としたシステム開発及び取引の明確化を目的に、ソフトウェア又はシステムの構想から運用や保守に至るまでのソフトウェアライフサイクルプロセスを可視化し、共通の枠組みを規定したもので、「共通フレーム」と呼ばれる)開発プロセス（開発プロセス開始の準備〜ソフトウェア受入れ支援）の見積りをＦＰ法見積り評価の対象範囲とする。それ以外の企画や立案などのコンサルタント業務、データ移行や運用支援業務などの付帯作業の見積りは、作業積み上げ方式で評価するが、ＦＰ評価の対象としない。更に、本発明では、新規案件と改修案件のいずれも開発費用評価の対象としている。

見積りの前提が基本設計完了前の場合の見積り入力情報は、要件定義書及び伝票、帳票、画面、マスタファイル一覧であり、ＮＥＳＭＡ提案の概算法で見積りを行う。即ち、マスタファイル一覧を基に要件定義書の内容を参考にし、業務的な観点からＩＬＦ(Internal Logical File: 計測対象システムである自システムが維持管理している論理マスタ)とＥＩＦ(External Interface File: 自システムが参照する他システム（計測対象システムと関連するシステム）の維持管理している論理マスタ)を特定し、ＦＰ規模を算出する。なお、ＮＥＳＭＡはポーランドのＦＰ法推進団体であり、ＮＥＳＭＡがＩＦＰＵＧ法を改良してシステム開発の早期段階に適用できる概算法を提案した。

また、見積りの前提が基本設計完了後の場合の見積り入力情報は、要求仕様書及び基本設計書、画面一覧及び画面仕様、帳票一覧及び帳票仕様、マスタファイル一覧及びマスタファイル仕様、インタフェースファイル一覧及びインタフェースファイル仕様である。そして、見積り方法はＩＦＰＵＧ(International Function Point Users Group)法でファンクションを洗い出し、各ファンクション毎の複雑さを評価し、未調整の機能規模（ＦＰ）を算出するようにしている。

企業のビジネス業務の自動化（コンピュータ化）が一巡し、現在システム化案件のうち、新規開発案件（２０〜４０％）が少なく、殆どは保守案件（６０〜８０％）である。そのため、保守費用の見積り評価が重要な業務となっている。しかし、ＦＰ法（ＩＦＰＵＧ法）では、保守案件における規模計測は保守の母体（追加・変更・削除する対象機能）しか計測できないため、同じシステムに対する保守であっても、軽微な保守と作り直しに近い保守などによってかかる手間が大きく異なる。かかる保守の度合いを明確に計って保守費用を見積り、また調達側がそれを評価することが不可欠となっている。このため、本発明では新規案件のみならず、改修案件をも評価の対象としている。

以下に、本発明の実施の形態を、図面を参照して説明する。

図３は本発明の原理を模式的に示しており、所定の手法で求められたＦＰ値に対して生産性モデルから生産性に関する情報を与え、次いで開発工数の人月単価（システムエンジニア単価金額）を入力し、所定演算式に従ってソフトウェア開発工数費用を算出する。生産性モデルに基づく生産性に関する情報をFP値に加味して開発工数等を算出するため、客観的で公正な評価を行い得る。

なお、生産性は、１人月当り“ｘｘFP”のシステムを開発できるという指標を示しており、生産性モデルについては後述するが、（開発言語別生産性値×システム環境係数×システム規模係数×処理負荷係数×品質要求係数×ドキュメント係数×工程別発注率×作業分担率×改修率）のことを示している。

図４は、本発明の評価値算出装置（コンピュータ）の構成例を示しており、コンピュータが有する入力手段より別途算出されたＦＰが数値で入力されると共に、システム開発状況やシステム環境等を考慮して選定されたシステム環境係数、システム規模係数、処理負荷係数、品質要求係数、ドキュメント係数、工程別発注率、作業分担率、改修率等の条件データ（Ｃ_１〜Ｃ_ｎ）が入力され、さらにシステム評価のための評価用データが評価用データテーブルとして入力される。演算部１０は入力されたＦＰ、各条件データ及び評価用データテーブルに基づいて評価値（見積り）を算出して表示若しくは印字出力する。算出された評価値は、ＦＰを基に各条件データ及び評価用データテーブルを加味して算出されているため、客観的で公正な評価値となっている。なお、評価用データテーブルは後述する開発言語別生産性値テーブル、生産性調整係数テーブル、開発工程別標準配分率テーブル、標準テスト項目件数テーブル等のデータである。

図５はコンピュータの詳細な構成例を示しており、全体の制御や演算を実行する演算部（ＣＰＵ）１０には動作プログラムを格納したＲＯＭ１０２と、各種データ入力が行われる入力手段１１０と、開発言語別生産性値テーブル記憶手段１０３１、生産性調整係数テーブル記憶手段１０３２、開発工程別配分率テーブル記憶手段１０３３、標準テスト項目件数テーブル記憶手段１０３４及びシステムエンジニア単価金額（ＳＥ単金）テーブル記憶手段１０３５を内部に含むＲＡＭ１０３と、データ等を表示する表示手段１２０と、データ等を印字出力する印刷手段１２１とから構成されている。

開発言語別生産性値テーブル記憶手段１０３１には、利用される言語毎に設定された一人月当たりの生産性値が記憶される。生産性調整係数テーブル記憶手段１０３２には、後述するシステム規模係数、システム環境係数、処理負荷係数、品質要求係数及びドキュメント係数のそれぞれの入力値に対応する生産値が記憶される。開発工程別配分率テーブル記憶手段１０３３には、基本設計、詳細設計、プログラム設計・製造、ソフトウェアテスト及びシステムテストの各工程について一般的経験則に基づいた発注率が記憶される。標準テスト項目件数テーブル記憶手段１０３４には、ソフトウェアテスト及びシステムテストの各工程において行われるテスト項目件数について一般的経験則に基づく件数が記憶される。

なお、一般的に経験則に基づいた発注率は、それぞれ１６％、２０％、３６％、１５％及び１３％であるが、ソフトウェアの改修状況に基づいて入力手段１１０から入力されても構わない。また、一般的に経験則に基づいたテスト項目件数は通常、ソフトウェアテストの基準項目数がＦＰ値×２．０件、システムテストの基準項目数がＦＰ値×０．５件であるが、そのソフトウェア分野によっても異なる場合があるため、後述するソフトウェアテスト項目件数の適用にはそれぞれＲ５及びＲ６の代数を用いて表現している。また、これらのテーブル記憶手段は、演算部１０が制御プログラムの指令を受けて予め作成される。もちろん、入力部１１０を動作させてこれらのテーブルに記憶されたテーブル値を入力された値に変化させることも可能である。

このような構成において、その動作を図６のフローチャートを参照して説明する。なお、以下の各ステップは、演算部１０がＲＯＭ１０２に記憶された制御プログラムの指令を受けて動作する。

先ず別途求められたFPが入力手段１１０より入力され（ステップＳ１）、次いで対象とするシステムが使用する言語に基づいて、言語別生産性値入力手段１１０より言語別生産性値、開発言語別生産性値が入力されると共に（ステップＳ２）、入力手段１１０より生産性調整係数が入力される（ステップＳ４）。生産性調整係数を算出するパラメータとして本発明では、生産性調整係数としてのシステムのプラットフォームを示すシステム環境係数、評価対象アプリケーションの規模を示すシステム規模係数、プロセスの形態（集中、分散）を示す処理負荷係数、システムの品質要求の度合い（レビュー、テスト、評価作業）を示す品質要求係数、作成するドキュメントの種類や数量を示すドキュメント係数が入力されて算出されても構わない。生産成長性係数のこれらパラメータからの算出の詳細は後述する。

さらに、開発プロセス（工程）の一部を自製したり、１案件を複数段階に分割して（工程別）発注したり、１案件を複数のベンダーに分割して（工程別）発注したりする場合の発注比率を示す工程別発注率（ステップＳ４Ａ）、発注側（調達側）と受注側（提供側）との作業比率を示す作業分担率(ステップＳ４Ｂ)、機能改造の場合の改修率（ステップＳ４Ｃ）が設定され、入力される。なお、これらの入力順序は任意でもよい。

上述のようにして演算のための条件とそのデータが入力されると、演算部１０１はＲＯＭ１０２内に格納されたプログラムに従って演算を実行し（ステップＳ５）、その後に入力手段１１０より付帯作業工数が入力され（ステップＳ６）、所定の演算が実行される（ステップＳ７）。そして、入力手段１１０よりシステムエンジニア単価金額が入力され（ステップＳ８）、所定の演算を実行して終了する（ステップＳ９）。これにより、ソフトウェア開発工数費用の評価を数値で得ることができ、表示手段１２０で結果を見ることができると共に、印刷手段１２１で印字することができる。

なお、ステップＳ４Ａの工程別発注率が入力されない場合もある。この場合、開発工程別標準配分率テーブル記憶手段１０３３に記憶された標準配分率（標準発注率）のデータを読み出して、工程別発注率として演算が行われる。

上述の例ではデータ入力毎に演算しているが、図７に示すように全てのデータを入力してから演算を行うようにしても良い。この場合、ＦＰ、開発言語別生産性値、生産性調整係数、工程別発注率、作業分担率、改修率、付帯作業工数及びＳＥ単金の入力の順番は任意である。

図８は、本発明による新規開発案件及び改修案件の開発規模、工数、費用のコンピュータでの算出方法の流れを詳細に示しており、先ずソフトウェア規模（ＦＰ）の算出を行ってデータ入力を行うが、本発明ではＩＦＰＵＧ法、概算法、論理ファイル推定法又はステップ逆算法のいずれかを使用する。ＩＦＰＵＧ法は、ＩＬＦ(Internal Logical File)＋ＥＩＦ(External Interface File)＋ＥＩ(External Input)＋ＥＯ(External Output)＋ＥＱ(External Inquiry)で各機能の重み付けがあり、ＶＡＦの調整はなしとなっており、概算法は、ＩＬＦ＋ＥＩＦ＋ＥＩ＋ＥＯ＋ＥＱで各機能の重み付けはなく、ＶＡＦの調整もなしとなっている。ＶＡＦ(Value Adjusted Factor)とは、ＩＦＰＵＧ法で提示されている調整要因（生産性調整係数）である。また、論理ファイル推定法はＩＬＦ数×３５＋ＥＩＦ数×１５であり、ステップ逆算法は言語別ステップ数÷言語別ＦＰ当りステップ数である。

上述のようにして計算されたＦＰが演算部１０に入力されると、開発言語別生産性値及び生産性係数の入力を行う。つまり、開発言語別生産性値、生産性調整係数（システム規模係数、システム環境係数、処理負荷係数、品質要求係数、ドキュメント係数）、工程別発注率、作業分担率及び改修率の入力を行う。ソフトウェア言語としては、COBOL85、Microfocus COBOL、C、C++、Visual C++、JAVA（登録商標）/JAVA Script、ABAP/4、Oracle Developer/2000、Access、EXCEL、PL/SQL等があるが、ソフトウェア言語によって人月生産性が異なる。そのため使用言語に対する人月生産性を予め開発言語別生産性値テーブル１０３１に設定しておき、当該開発システムの使用言語に基づいてデータを読み出して人月生産性を入力する。例えばCOBOL85やＣは人月生産性が低く、Visual Basic, C++などは人月生産性が高い。なお、同一ソフトウェアの開発に複数の言語を採用した場合、それぞれの割合を算出して全体の開発言語別生産性値を合算する。

また、生産性調整係数内のシステム環境係数はPCスタンドアロン形態、ホスト集中形態、単一プラットフォーム構成（ALL UNIX（登録商標）又はALL Windows（登録商標））、複式プラットフォーム構成（UNIX、Windows、LINUX）によって生産性が相違するため、システム環境に基づいた係数を設定する。システム規模係数はFPの値によって判断し、規模の大小によって係数値を変える。処理負荷係数はプロセスの形態によって判断し、単一部門／拠点で少人数利用の場合（例えばローカル系や部門内小規模システム）、単一部門／拠点で多人数利用の場合（例えばプロセス集中処理、ホスト系）、複数部門／拠点で多人数利用の場合（例えばプロセス分散処理、基幹系）で生産性が相違するため、各場合によって係数値を変える。品質要求係数はユーザからの品質要求が特にない場合（動作確認程度）、ユーザからの品質要求が普通である場合（マスタ状態確認）、ユーザからの品質要求が厳しい場合（大規模トランザクション／データ性能確認）であるかによって生産性が相違するため、各場合によって係数値を変える。ドキュメント係数に関しては、例えばＳＬＣＰ例示ドキュメントのうち作成されたものが５０％未満である場合、ＳＬＣＰ例示ドキュメントのうち作成されるものが５１％〜１００％程度である場合、ＳＬＣＰ例示ドキュメントのうち作成されるものが１００％を超える場合で生産性が相違するため、各場合によって係数値を変える。なお、生産性調整係数は生産性調整係数テーブル１０３２に格納されている。

工程別発注率は、開発プロセスの一部を自製する場合、１案件を複数段階に分割して発注する場合、１案件を複数の提供者に分割して発注する場合等で生産性が相違するため、開発プロセス全体を一まとめにして提供者に発注する場合の比率を１００％とし、各場合の比率を入力する。作業分担率は、開発プロセスの一部作業を自製したり、１案件を複数の提供者に分割して発注する場合があり、このような場合、双方の作業分担の度合い（原則は工数ベース）を勘案して作業分担率を設定することが有効である。開発プロセスの全ての作業を提供者に発注する場合（完全請負）の作業分担率を１００％とする。改修は既存システムに対して機能を追加、変更、削除することをいい、改修案件の見積り評価は、既存母体システム（対象システム）を新規で開発した場合の改修率を１００％とし、既存母体システムに対する追加、変更、削除の割合を定量化して、改修案件工数の見積りを評価する。改修規模は下記（１）式で定義される。

改修規模＝改修母体規模×改修率 …（１）

開発言語別生産性値及び生産性調整係数並びに工程別発注率、作業分担率、改修率が入力された後、演算部１０はこれら入力されたFP、開発言語別生産性値及び生産性調整係数並びに工程別発注率、作業分担率、改修率に対して、下記（２）式に従って標準開発作業工数Ａの演算を行う。

標準開発作業工数A= FP÷生産性係数
＝FP÷(開発言語別生産性値×生産性調整係数×工程別発注率
×作業分担率×改修率)
＝FP÷{開発言語別生産性値×システム規模係数ｋ１×システム
環境係数ｋ２×処理負荷係数ｋ３×品質要求係数ｋ４×
ドキュメント係数ｋ５×工程別発注率×作業分担率×改修率}
…（２）
なお、ｋ１〜ｋ５は図１５に示す生産性調整テーブル記憶手段１０３２に記憶された調整値である。入力手段１１０からの入力に基づいて、各調整値が適用されることを表す。

その後、入力手段１１０より付帯作業工数を入力し、下記（３）式の演算を行う。「付帯作業」とは、上記標準開発作業以外に発注者から提供者に委託した作業を指し、これらの作業を遂行するために発生する費用を「付帯作業工数」と定義する。そして、下記（３）式を演算する。

開発工数B＝標準開発作業工数A＋付帯作業工数 …（３）

その後、更に入力手段１１０よりシステムエンジニア単価金額テーブル記憶手段１０３５からデータを読み出してシステムエンジニア単価金額を入力し、下記（４）式の演算を行う。これにより、ソフトウェア開発費用（Ｃ＝開発工数×ＳＥ単金）が得られる。

開発費用C＝開発工数B×システムエンジニア単価金額 …（４）

即ち、ソフトウェア開発費用の演算式は下記（５）式となる。

開発費用＝{機能規模ＦＰ÷（開発言語別生産性値×生産性調整係数×工程別発注率
×作業分担率×改修率）＋付帯作業工数}×システムエンジニア単価金額
…（５）

一方、開発言語別生産性値は例えば下記（６）式によって計算され、予め開発言語別生産性値テーブル記憶手段１０３１に格納されている。この場合、各開発言語別の生産性（7.5FP/人月〜40FP/人月）が開発言語別生産性値テーブル記憶手段１０３１に格納され、利用者が開発言語を選択し、それぞれの利用割合（開発する機能の多さ）を入力することによって言語の生産性が自動的に付与される。

開発言語別生産性値＝（開発言語＃１の生産性値×利用割合ｍ１）
＋（開発言語＃２の生産性値×利用割合ｍ２）
＋（開発言語＃３の生産性値×利用割合ｍ３）
＋（開発言語＃４の生産性値×利用割合ｍ４）
＋（開発言語＃５の生産性値×利用割合ｍ５）
…（６）

また、生産性調整係数は下記（７）式に基づいて計算される。なお、各係数は0.80〜1.20の範囲で設定され、表示手段１２０の入力画面を参照して所定の調整係数が選択入力されることによって、その値が一意的に付与される。

生産性調整係数＝システム規模係数ｋ１×システム環境係数ｋ２×
処理負荷係数ｋ３×品質要求係数ｋ４×
ドキュメント係数ｋ５ …（７）

なお、図６では開発言語別生産性値及び生産性調整係数等を入力後に（２）式の演算、付帯作業工数の入力後に（３）式の演算、システムエンジニア単価金額の入力後に（４）式の演算を行うようになっているが、図７に示すように開発言語別生産性値、生産性調整係数等、付帯作業工数及びシステムエンジニア単価金額の入力後に続けて（２）〜（４）式を連続的に演算するようにしても良い。

以下、本発明の具体例を説明する。

本発明はソフトウェア開発（改修）案件を対象とし、ハードウェア、ネットワーク、ミドルウェアなどの設計、導入作業費などは評価の対象とせず、システム開発プロセスのうち、ＳＬＣＰ開発プロセス（開発プロセス開始の準備〜ソフトウェア受入れ支援）の見積りをＦＰ法見積り評価の対象範囲としている。それ以外の企画や立案などのコンサルタント業務、データ移行や運用支援業務などの付帯作業の見積りは「作業積み上げ方式」で評価するが、ＦＰ評価の対象としない。本発明は、新規案件と改修案件を対象とする点に特徴がある。

ＦＰ法はソフトウェア規模を測定するための手法（尺度）の１つであり、ソフトウェアのデータや機能の数と複雑度を計測することで、そのソフトウェアの機能規模（ＦＰ値）を算出する。図９は、本発明で採用するＦＰ法の概略を示している。

ファンクションの種別はＩＬＦ、ＥＩＦ、ＥＩ、ＥＯ、ＥＱであり、ＩＬＦはユーザが識別でき自システム（計測対象システム）が維持管理している論理データのまとまりであり、ＥＩＦはユーザが識別でき他システム（計測対象システムと関連するシステム）が維持管理し、自システムが参照している論理データのまとまりである。また、ＥＩはシステム境界外からデータを投入して、ＩＬＦを維持管理（登録、更新、削除）する機能であり、ＥＯはＩＬＦやＥＩＦを参照してユーザや他システムへ情報を提供する機能で、情報提供に計算式や導出データが含まれ、ＥＱはＩＬＦやＥＩＦを参照してユーザや他システムへ情報を提供する機能で、情報提供に計算式や導出データは含まれていない。

ソフトウェアの機能規模がそのソフトウェア開発工数、費用と強い相関が見られることから、ＦＰ値を使用して開発工数、費用を見積もることが考えられる。例えば、１人当り１０ＦＰの生産性で１０００ＦＰのシステムを開発するのに１００人月かかる。更に、１人月のＳＥ単金が９０万円の場合、開発費用が９０００万円となる。発注側が独自でＦＰ値を計測して開発工数費用を算出し、提供者から徴収した見積りの妥当性を評価するものとし、本発明では上記ＦＰを用いて、前記（５）式を使ってシステム開発費を見積もる。

かかるシステム開発費見積りの精度を上げるため、ＦＰ値を正確に計測する必要がある。仮に提供側からＦＰを取得した場合、提供者が提示したＦＰ値が正しいか否か、発注側が自ら検証しなければならない。

図１０は、開発規模（ＦＰ）算出のための入力情報と算出方法を示している。即ち、見積りの前提として企画立案完了＃１、企画立案完了＃２、要件定義完了、基本設計完了があり、企画立案完了＃１はステップ逆算法で見積もるために既存システム言語別プログラム行数、ソースコード及びシステム企画内容を入力する。企画立案完了＃２は論理ファイル推定法で見積るためにＥＲ一覧、マスタデータ一覧及びシステム企画内容を入力し、要件定義完了は概算法で見積もるために機能要件全体概要、現行業務の流れ、システム化計画、システム機能概要及び機能・画面帳票・ＤＢ一覧を入力し、基本設計完了はＩＦＰＵＧ法で見積もるために機能要件、現行業務の流れ、システム化計画、システム機能概要、システム機能詳細及び機能・画面帳票・ＤＢ一覧とレイアウトを入力する。

本発明ではＦＰ法を活用したシステム開発費見積り評価を行うが、本発明では特に下記４点に留意している。
（１）可能な限りＩＦＰＵＧ法に準拠して計測する。
ＦＰ法はＩＦＰＵＧの他にも、複数の手法が存在する。これらは概ね同様なコンセプ
トに基づいているが、それぞれの着眼点が違うため、計測されたＦＰ値の意味も異な
ってくる。本発明では、ＦＰの計測方法やその粒度は、「ＩＦＰＵＧ法（国際標準規
格ＩＳＯ２０９２６：２００３：ＩＦＰＵＧ法）」に準拠する。ＩＦＰＵＧ法以外の
手法を適用して算出したＦＰ値とＩＦＰＵＧ法のＦＰ値との関連を明確にする必要が
ある。
なお、「国際標準規格ＩＳＯ２０９２６：２００３：ＩＦＰＵＧ法」で「機能要件
と品質技術要件と分離する」との解釈に従い、本発明では、ＦＰは未調整ＦＰとす
る。即ち、ータファンクションとトランザクションファンクションの規模をＦＰと
し、１４項目の般システム特性を用いた調整は行わない。そのシステムの品質、技
術要件はシステム特性調整係数で評価し、システム開発工数費用に反映される。
（２）複数手法の併用を推奨する。
ＩＦＰＵＧ法を適用してＦＰを計測する場合、システムの基本設計が完了し、かつ
計測で必要な入力情報が揃っていることを前提とする。しかし、実務ではもっと早い
時期に見積りが行われることがよくある。例えば要件定義完了時点での費用の推定な
どである。このような早期段階でＦＰを計測する場合、計測者が入手できる入力情報
（仕様書）の種類や詳細度が限られているため、いくつかの簡易計測法が考案されて
いる。ここで強調したいことは、（ａ）可能な限りＩＦＰＵＧ法に近付ける方法を適
用すること、（ｂ）簡易法を利用した場合、可能な限り複数の手法を実施し、検証を
行うことである。
（３）見積り評価の目的はコスト適正化である。
本発明で提案しているシステム開発費用の見積り評価方法は、開発プロセスの標準
業を対象としている。実務でのシステム開発案件は、開発プロセスの一部しか発注
しないか、又は開発プロセス以外の作業も発注している場合がよく見受けられるこ
のことを念頭において、システム開発費用の見積り評価に臨まなければならない。本
発明のシステム開発作業が受注側と発注側との協同作業であって、両者が同じゴール
を目指さなければ上手くいかないことに着眼し、見積り評価業務は提供者の開発費用
見積りを安く叩くことではなく、双方で確認、納得できる適性コストに対する客観的
な根拠（目安）を示すことに立脚する。
（４）可能な限り定量化を図る。
見積り評価作業の客観性を保つには、評価の根拠を可能な限り定量化する必要があ
る。特に改修案件について、世間ではシステム開発費用の６０％以上をシステム改修
に充てているにも拘わらず、今まで有効な見積り評価方法が提唱されていない。この
実状を勘案すると、改修案件の見積評価に注力しなければ、情報システム部門が経営
者や利用部門への説明義務が果たせない。従って、本発明では改修度合いを定量化し
、改修案件の見積評価にも確実に対応している。

ここにおいて、システム開発工数、費用の見積り評価で最も重要なことは、１）精度の高いＦＰ値を得ること、２）精度の高い生産性係数を入力すること、３）明確で双方（発注側、受注側）が認識、合意できるスコープ（作業範囲）であること、４）改修案件の改修率の定量化が可能なこと、である。これら４つの要素に関して弛まぬ努力で精度の向上を念頭におき、独自の実績データを蓄積し、見積り評価で適用する各種係数の精度向上を追求する必要がある。本発明はかかる要求を満たすものである。

システム開発費用見積りの結果として、開発費用が算出される。上記（５）式で算出された開発費用は発注者が自ら見積もったもので、いわゆる評価用標準価格的なものである。これに対して、受注者から取得した見積りは業者提示価格と定義され、評価用標準価格と業者提示価格とを比較して差異の有無を検証するが、この比較行為が見積りの評価ということになる。

図１１はシステム開発費用の構成を示しており、システム開発費用にはハードウェア費用、ミドルウェア及びシステム開発費用が含まれるが、本発明ではそのうちのシステム開発費用内のソフトウェア開発費用のみを評価の対象とする。本発明におけるソフトウェア開発はＳＬＣＰの開発プロセスを指し、開発プロセスの範囲は図１２に示すようになっている。即ち、開発プロセスの範囲としては企画プロセス、開発プロセス、運用プロセス及び保守プロセスがあり、本発明はそのうちの開発プロセスを対象とし、プロセス開始の準備、システム要求分析、システム方式設計、業務詳細設計、ソフトウェア要求分析、ソフトウェア方式設計、ソフトウェア詳細設計、ソフトウェアコード作成及びテスト、ソフトウェア結合、ソフトウェア適合性確認テスト、システム結合、システム適合性確認テスト、ソフトウェア導入、ソフトウェア受入れ支援について評価する。なお、図１１における安定稼動システムの運営と維持管理業務は、月間基準勤務時間が１６０ｈ／月（１５０ｈ／月〜１７０ｈ／月）であり、開発工数は開発プロセス工程作業を対象とし、付帯作業は開発プロセス工程以外の作業を対象としている。

また、本発明では開発工程を基本設計、詳細設計、プログラム設計・製造、ソフトウェアテスト、システムテストの５工程に分け、それぞれのＳＬＣＰアクティビティとの対応関係は図１３に示すようになっている。即ち、基本設計としてプロセス開始の準備、システム要求分析、システム方式設計、ソフトウェア要求分析及びソフトウェア方式設計があり、詳細設計として業務詳細設計及びソフトウェア詳細設計がある。プログラム設計・製造はソフトウェアコード作成及びテストであり、ソフトウェアテストはソフトウェア結合及びソフトウェア適合性確認テストであり、システムテストとしてシステム結合、システム適合性確認テスト、ソフトウェア導入及びソフトウェア受入れ支援がある。

ここにおいて、システム開発作業の中で、実装工程（詳細設計〜ソフトウェアテスト）が全開発工数の６０％以上を占めている。開発言語（コード自動生成などの中下流開発支援ツールを含む）の選定が実装工程の作業工数、費用に大きな影響を与えている。従って、システム開発の生産性を設定する際には、開発言語の生産性に留意する必要がある。開発言語別生産性値の例を図１４に示すが、本例は１人月当り生産性の前提として、１人月を１６０時間とし、ＳＬＣＰ開発プロセスを作業範囲としている。なお、一部の工程しか発注しない場合、その割合を勘案して生産性を調整する必要がある。

前述の開発言語別生産性値以外に、開発生産性に影響を与える要素は多い。例えば対象システムの固有属性（規模、システム構成など）、発注側の要求度合い（品質要求度合い、ドキュメント要求度合いなど）、受注側の業務遂行能力、成熟度（類似システム構築経験、開発者熟練度、プロジェクト管理成熟度など）、数十若しくは百以上の要素が挙げられる。本発明では見積り評価の精度を保ちながら、業務の簡便性、迅速性を失わないように各種コスト誘因の中から、システム開発工数に影響の大きい非機能要件（品質要件、技術要件）、並びに調達側（発注側）が特に重視すべく要素を中心に、コストドライバーを設定している。

以下に、各システム特性が開発生産性に与える影響とその評価方法を示す。本発明では、下記５システムに係数を与えて評価を正確に行うようにしている。
（１）システム規模：大規模開発の場合、業務間の複雑度が増幅し、利害関係も増えるた
め、コミュニケーションオーバヘッドが発生しやすく、開発生産性が低下する。
（２）システム環境：プラットフォームが異なれば利用するＯＳ、ミドルウェア、ＤＢＭ
Ｓなども異なり、それに伴うシステム設計、構築の負荷が変化し、開発生産性も変
わる。
（３）処理負荷：データとプロセスの集中、分散によって、トランザクション制御、負荷
分散などシステム設計、構築の作業負荷が異なり、開発生産性が変動する。
（４）品質要求：社内のデータ確認と社外サービス課金と、品質への要求度合いが異なり
、それに伴い、システム設計観点、レビュー／テスト／品質評価への取込みによっ
て開発生産性が変動する。
（５）ドキュメント：大規模開発の場合、本稼動後の運用保守を重視する場合など、作成
するドキュメントのレベルや量が変わり、開発生産性に影響を与える。

上述のようなシステム特性に基づく生産性調整係数の例を図１５に示す。システム規模係数は計測対象アプリケーションによって分類し、システム環境係数はシステムのプラットフォーム（システム環境構成）によって分類し、処理負荷係数はプロセスの形態（集中、分散）によって分類し、品質要求係数はシステムの品質要求度合い（レビュー、テスト、品質評価作業）によって分類し、ドキュメント係数は作成するドキュメントの種類、数量によって分類する。なお、係数の大小関係は、K11＞K12＞K13＞K14＞K15であり、K21＞K22＞K23＞K24であり、K31＞K32＞K33であり、K41＞K42＞K43であり、K51＞K52＞K53である。

開発プロセス全体を一まとめにして提供側に発注する場合、そのときの工程別発注率を１００％とする。開発プロセスの一部を自製したり、１案件を複数段階に分割して発注したり、１案件を複数の提供者に分割して発注したりするケースが考えられる。このような場合、図１６に示すような工程別発注率を参考にして、工程別発注率を設定する必要がある。また、開発プロセスの全ての作業を提供側に発注する場合（完全請負型）、そのときの作業分担率を１００％とする。開発プロセスの一部作業を自製したり、１案件を複数の提供者に分割して発注したりするケースが考えられる。このような場合、双方の作業分担の度合い（原則は工数ペース）を勘案して、図１７に示すような作業分担率を設定する必要がある。例えば、基本設計全作業を１５人月と仮定し、そのうちの運用設計作業（１．５人月）を調達側が担当し、残りの１３．５人月を提供側が担うとする。この場合、基本設計工程の提供側作業分担率を

１３．５人月÷（１．５人月＋１３．５人月）×１００％＝９０％ …（８）

で、９０％とする。ただし、下記のような元々発注側が担うべき役割は、ここでの作業分担率の対象としない。
１）仕様提示：要求事項のまとめ、提示など
２）調達管理：ＲＦＰ作成、見積り評価、業者選定、契約の締結と管理、契約終了に伴
う事務処理など
３）検収作業：仕様、設計、実装結果のレビュー、承認、検証など

本発明では、改修案件の見積りを評価する場合、以下のようにしている。
１）改修率が１００％を超えた場合は、改修率「１００％」とする。
２）ソフトウェア改修個所とテスト範囲が大きく異なる場合があるため、改修率を開発
改修率とテスト改修率とに分ける。そして、開発改修率は基本設計からプログラミ
ング工程に適用し、テスト改修率はソフトウェアテスト工程（ソフトウェアテスト
改修率）とシステムテスト工程（システムテスト改修率）に適用する。

改修率の算出方法はステップ法を基本とし、下記（９）式で基本設計〜プログラミング工程に適用する。行数（ステップ数）はコメント行を含む物理ステップ数であり、母体（対象システム）行数のＲ１％は変更箇所とのインタフェースの考え方から計上する。また、改変行数は既存システムに対する「追加、変更、削除」の行数であり、外付け追加機能とは既存システムに手を入れることなく、別枠で追加する機能である。なお、定数Ｒ１％、Ｒ３％及びＲ４％は経験値であり、通常は６％を利用するが開発種類等によって変更することも構わない。また、改修前母体行数とは、改修対象システム（改修対象ソフトウェア）の既存行数を差し、既存システムの改変行数とは改修により改変が行われた行数を差し、改修後母体行数とは改修が行われた後の対象システム(対象ソフトウェア)の行数を差す。また、Ｒ２は改変行数にソフトウェア改修後の改変行数に対する確認作業で行われる確認倍率を示し、通常は改修前・改修後の確認を行うために２の値を適用する。

開発改修率＝{（改修前母体行数×Ｒ１％）＋（既存システムの改変行数×Ｒ２）
＋（外付け追加機能行数）}÷（改修後母体行数）
…（９）
なお、改修前母体行数×Ｒ１％を第一作業行数、既存システムの改変行数×Ｒ２を第二作業行数、第一作業行数、既存システムの改変行数及び外付け追加機能行数の和を開発作業行数と定義する。

また、ステップ方式で計測困難なケースの改修率算出方法は、下記（１０）式に従う。（１０）式において、ＤＥＴはデータ項目種別(Data Element Type)を意味している。

開発改修率＝{（改修前母体ＤＥＴ数×Ｒ３％）＋（追加・変更・削除ＤＥＴ数）}
÷（改修後母体ＤＥＴ数） …（１０）

なお、改修前母体ＤＥＴ数×Ｒ３％を改修前作業ＤＥＴ数、追加・変更・削除ＤＥＴ数を改変ＤＥＴ数、改修前作業ＤＥＴ数と改変DET数の和を開発作業ＤＥＴ数と定義する。

更に、ソフトウェアテストとシステムテスト工程に適用するテスト工程での改修率の算出方法は、下記（１１）式に拠る。この場合、新規開発時のテスト項目数実績データが記録されていない場合、ソフトウェアテストの基準項目数＝ＦＰ値×Ｒ５件、システムテストの基準項目数＝ＦＰ値×Ｒ６件の基準値を適用し、テスト改修率の提示がない場合、開発改修率と同等であるとみなす。なお、ソフトウェアテストの基準項目数及びシステムテストの基準項目数について、入力手段１１０から件数入力を受け付けるようにしても構わない。入力が行われない場合には、標準テスト項目件数テーブル記憶手段１０３４から読み出されて演算に利用される。

テスト改修率＝{（改修前母体・新規開発時のテスト項目数×Ｒ４％）＋（改修時
のテスト項目数）}÷（改修後母体・新規開発時のテスト項目数）
…（１１）

なお、改修前母体・新規開発時のテスト項目数×Ｒ４％を第一テスト作業行数、第一テスト作業行数と改修時のテスト項目数との和を全体テスト作業行数と定義する。
以下に代表的な「付帯作業」を例示する。
（１）運用テスト関連作業：運用テストとは、利用者が主体とする本稼働環境でのソフト
ウェア、システム、業務全体を確認するテストである。これに付随する環境構築、
利用者支援などの作業を付帯作業とする。
（２）移行関連作業：旧運用形態から新運用形態への切替えに伴う業務、システム、デー
タの移行作業が付帯作業とする。（ただし、移行用ツールの開発は標準開発作業の
範疇とし、ＦＰで評価する方式を採用する。）
（３）運用関連作業：本稼働に向けての利用者教育訓練及び本稼働作業（運用監視、稼働
情報収集、改善、評価など）を付帯作業とする。
（４）開発支援作業：開発標準化（作業手順、テンプレート、基準）の策定と推進、品質
保証（契約、プロセス、要求事項、文書化の検証と妥当性確認）、リソース管理な
どを付帯作業とする。
（５）プロジェクト管理：進捗管理、問題管理、変更管理などを付帯作業とする。なお、
本発明では、付帯作業費の見積り評価はＷＢＳ精査方式で行う。

本発明ではソフトウェア開発技術者を図１８に示すような４区分に分け、それぞれの役割と担当を決めている。即ち、開発技術者１は基本設計やシステムテストを主に担当し、システムの構成イメージ策定の中心的役割、システム開発計画の全体構想、プロジェクト体制の構築、後工程のプロジェクト管理指標決定等の役割を担っている。開発技術者２は基本設計、詳細設計、ソフトウェアテストやシステムテストを主に担当し、業務のモデル化、情報システム化の計画を策定したり、システムの機能設計及びシステムの具体化の中心的役割等を担っている。また、開発技術者３（設計）は詳細設計やソフトウェアテストを主に担当し、システムの基本設計を基にした詳細設計作成の中心的役割を担っており、開発技術者４（製造）はプログラム設計・製造を主に担当し、プログラミングの中心的役割、プログラムモジュールやプロセス毎のテストを担っている。

図１９は本発明の入力画面の一例を示し、図２０は本発明の結果を示す表示画面の一例である。本発明においては新規案件、改修案件のいずれも評価できるようになっており、新規案件と改修案件の唯一の違いは、図２０における項番４）の改修率にある。新規案件の場合は改修率が１００％になり、改修案件の場合は改修率が１００％未満となっている。

図１９の入力画面では、提供側から提示された見積りが高いか安いかを評価する業務を想定しているので、提供側見積り費用も入力すべき項目の１つとなっている。ウェブ画面をスクロールして入力作業を行う。「提供側見積り費用」の最後尾の「付帯作業工数」欄に付帯作業の数値を入力する。

本発明では、算出した機能規模（ＦＰ）と開発費を用いて図２１のように見積りを評価する。即ち、規模が過大や過小の場合、その提供者が開発範囲を過不足に捉えていないか否か、ＦＰ明細を精査し、逆に費用が過大や過小の場合、その提供者が見積もった作業内容に過不足はないか否か、作業内容を精査する。図２１では、Ｃ案件及びＥ案件が適性価格であることを示している。

図２０の結果表示画面における「開発工数費用評価」欄は、ユーザ企業がＦＰ法で算出した開発費用見積りと提供側から取得した開発費用見積りとを対比させ、提供側見積りが高過ぎないか又は安過ぎないかを判断するための情報が表示される。

本発明はインターネットを利用したネットワークにおいても利用可能である。

本発明によれば、ＦＰを基本にしてシステムの開発状況や環境を考慮した要素を条件として評価しているので、ソフトウェア開発工数費用の評価を客観的にかつ公正に行うことができ、そのためソフトウェア市場（入札や販売等）において見積の曖昧さを確実に排除することができ、ソフトウェア産業の活性化を図ることができる。

FPの求め方を示す図である。 FPと評価額との関係例を示す特性図である。本発明の原理を示す模式図である。本発明の評価値算出装置を示すブロック構成図である。演算部の構成例を示すブロック図である。本発明の動作例を示すフローチャートである。本発明の他の動作例を示すフローチャートである。本発明による新規開発及び改修案件の開発規模、工数、費用の算出方法を示す図である。ＦＰ法の概略を示す図である。開発規模算出のための入力情報と算出方法を示す図である。システム開発費用の構成を示す図である。開発プロセスの範囲を示す図である。工程区分とＳＬＣＰとの比較を示す図である。開発言語別生産性値の一例を示す図である。開発生産性調整係数の例を示す図である。工程配分比率の例を示す図である。作業分担比率の例を示す図である。ソフトウェア開発技術者の職種区分と役割を示す図である。本発明の入力画面の一例を示す図である。本発明の結果を示す表示画面の一例を示す図である。ＦＰを活用した参考価格の検証例を示す図である。

符号の説明

１０演算部（ＣＰＵ）
１０２ＲＯＭ
１０３ＲＡＭ
１１０入力手段
１２０表示手段
１２１印刷手段
１０３１開発言語別生産性値テーブル記憶手段
１０３２生産性調整係数テーブル記憶手段
１０３３開発工程別標準配分率テーブル記憶手段
１０３４標準テスト項目件数テーブル記憶手段
１０３５システムエンジニア単価金額テーブル記憶手段

Claims

ソフトウェアの機能規模を表わすファンクションポイント値を基本として、評価対象のソフトウェアの開発状況及びシステム環境を考慮した評価要素に基づいて前記ファンクションポイント値に重み付けを行い、前記ソフトウェアの開発工数／費用を評価する評価装置であって、
ソフトウェアの一人月当たりの開発言語別の生産性を定量化した生産性値を記憶する開発言語別生産性値テーブルと、
前記生産性値を調整する係数として、システム規模を前記ファンクションポイント値の量によって分類して定量化したシステム規模係数、及びシステム環境をその形態によって分類して定量化したステム環境係数を含む各係数を記憶する生産性調整係数テーブルと、
ソフトウェアの開発言語とその利用割合、前記システム環境の分類項目、前記システム規模の分類項目、及びシステムエンジニア単価金額を含む情報の入力画面を表示する表示手段と、
前記入力画面上で選択された前記開発言語を基に前記開発言語別生産性値テーブルから得た前記ソフトウェアの開発言語に対応する前記生産性値、及び前記入力画面上で入力された前記利用割合に基づいて、ソフトウェア言語を評価要素とした前記ソフトウェアの開発言語別生産性値を算出する手段と、
前記入力画面上で選択された前記システム規模の項目及び前記システム環境の項目を含む各項目に対応する係数を前記生産性調整係数テーブルから得て、それらの係数を生産性調整係数として設定する手段と、
前記ソフトウェアの基本設計、詳細設計、プログラム設計・製造、ソフトウェアテスト及びシステムテストの各工程における前記開発言語別生産性値及び前記生産性調整係数、並びに、前記各工程における工程別発注率、前記ソフトウェアの発注側と受注側との作業比率を示す作業分担率及び既存システムに対する改修の割合を示す改修率の入力情報に基づいて前記ソフトウェアの生産性係数を算出する手段と、
前記各工程における前記ファンクションポイント値を前記生産性係数で除算して前記ソフトウェアの標準開発作業工数を算定する開発工数算定手段と、
前記標準開発作業工数、及び前記システムエンジニア単価金額の入力情報に基づいて前記ソフトウェアの開発費用を算定する開発費用算定手段と、
前記開発工数算定手段により算定した前記標準開発作業工数、及び前記開発費用算定手段により算定した前記開発費用を前記ソフトウェアの開発工数／費用の評価情報として出力する評価情報出力手段とを備えたことを特徴とするソフトウェア開発工数費用の評価装置。
前記評価要素として業者提示価格を含み、
前記評価情報出力手段は、前記開発費用算定手段により算定した前記開発費用を評価用基準価格として、その評価用基準価格と前記入力画面上で入力された前記業者提示価格とを対比させた情報を出力することを特徴とする請求項１に記載のソフトウェア開発工数費用の評価装置。
前記評価情報出力手段は、前記標準開発作業工数の合計及び前記開発費用の合計を出力すると共に、前記標準開発作業工数及び前記開発費用を前記工程別に出力することを特徴とする請求項１又は２に記載のソフトウェア開発工数費用の評価装置。
前記生産性調整係数テーブルには、データとプロセスの集中処理及び分散処理を含む処理形態に伴う開発作業負荷を前記処理形態によって分類して定量化した処理負荷係数、ユーザからの品質要求をその要求度合によって分類して定量化した品質要求係数、及び、ドキュメントに係る生産性をドキュメントの種類，数量によって分類して定量化したドキュメント係数が更に記憶されており、
前記表示手段は、前記処理負荷係数の分類項目、前記品質要求係数の分類項目及び前記ドキュメント係数の分類項目の各選択メニューを前記入力画面に表示し、
前記生産性調整係数を算出する手段は、前記各選択メニューの中から選択された前記処理負荷係数の項目、前記品質要求係数の項目及び前記ドキュメント係数の項目にそれぞれ対応する前記処理負荷係数、前記品質要求係数及び前記ドキュメント係数を前記生産性調整係数テーブルから得て、それらの係数、前記システム規模係数、及び前記システム環境係数に基づいて前記生産性調整係数を算出することを特徴とする請求項１乃至３のいずれかに記載のソフトウェア開発工数費用の評価装置。
前記各工程別に設定された標準発注率を記憶する開発工程別標準配分率テーブルを備え、前記生産性係数を算出する手段は、前記工程別発注率が入力されなかった場合は、入力されなかった工程に対応する前記標準発注率を前記開発工程別標準配分率テーブルから得て、該標準発注率を当該工程における前記工程別発注率として前記生産性係数を算出することを特徴とする請求項１乃至４のいずれかに記載のソフトウェア開発工数費用の評価装置。
前記ソフトウェアが新規開発の場合は、前記改修率を１００％として前記ソフトウェアの生産性係数が算出されることを特徴とする請求項１乃至５のいずれかに記載のソフトウェア開発工数費用の評価装置。
前記評価要素として、前記ソフトウェアの標準開発作業以外に発注者から提供者に委託された作業の工数を示す付帯作業工数を含み、
前記開発費用算定手段は、前記標準開発作業工数と前記付帯作業工数との和に前記システムエンジニア単価金額を乗算して前記開発費用を算定することを特徴とする請求項１乃至６のいずれかに記載のソフトウェア開発工数費用の評価装置。
前記ファンクションポイント値は、ＩＦＰＵＧ（International Function Point Users Group）法、概算法、論理ファイル推定法又はステップ逆算法のいずれかを用いて算出したファンクションポイント値である請求項１乃至７のいずれかに記載のソフトウェア開発工数費用の評価装置。