この規格ページの目次
12
X 0142 : 2010
3.2.2.4 データファンクションの計測
データファンクションは,アプリケーション境界の内部データ要件及び外部データ要件を満たすために
利用者に提供される機能を表す。データファンクションは,ILF又はEIFである。
− ILFとは,計測対象のアプリケーション境界の内部で維持管理される,論理的に関連のあるデータ又
は制御情報の利用者視点のグループのことをいう。ILFは,計測対象のアプリケーション境界の内部
にある一つ以上の要素処理によって維持管理されるデータを保持することを主目的とする。
図1における人事情報システムのILFは,当該アプリケーションの中で維持管理される社員データ
のグループである。
− EIFとは,計測対象のアプリケーションによって参照される,論理的に関連のあるデータ又は制御情
報の利用者視点のグループのことをいう。ただし,維持管理は,他のアプリケーション境界の内部で
行われる。EIFは,計測対象のアプリケーション境界の内部にある一つ以上の要素処理によって参照
されるデータを保持することを主目的とする。このことは,あるアプリケーションで計測されるEIF
は,他のアプリケーションにおいてILFでなければならないことを意味している。
図1で示す人事情報システムの例は,為替システムによって維持管理され,人事情報システムによ
って参照される為替レートを示している。
データファンクションの詳細を,箇条7に示す。
3.2.2.5 トランザクション ファンクションの計測
トランザクション ファンクションは,データ処理のために利用者に提供される機能を表す。トランザク
ション ファンクションはEI,EO又はEQのいずれかである。
− EIとは,計測対象のアプリケーション境界の外部から入力されるデータ又は制御情報を処理する要素
処理のことをいう。EIは,一つ以上のILFの維持管理及び/又はシステムの振る舞いの変更を主目的
とする。
図1で示す人事情報システムの例は,人事情報システムに社員情報を入力する処理を示している。
− EOとは,計測対象のアプリケーション境界の外部にデータ又は制御情報を出力する要素処理のこと
をいう。EOは,データ又は制御情報の取り出しの有無にかかわらず,処理ロジックによって情報を
利用者に提供することを主目的とする。EOは,処理ロジックに少なくとも一つの“数式又は演算の
実行”又は導出データの生成を含まなければならない。EOは,一つ以上のILFの維持管理及び/又
はシステムの振る舞いの変更を行ってもよい。
図1で示す人事情報システムの例は,人事情報システムに登録されているすべての社員を記載する
報告書を作成する処理を示している。
− EQとは,計測対象のアプリケーション境界の外部にデータ又は制御情報を送り出す要素処理のこと
をいう。EQは,ILF又はEIFからデータ又は制御情報を取り出すことによって利用者に情報提供する
ことを主目的とする。EQは,処理ロジックに“数式又は演算の実行”を含まない。さらに,導出デ
ータを生成しない。処理中にILFを維持管理せず,システムの振る舞いの変更も行わない。
図1で示す人事情報システムの例は,社員情報を問い合わせて(入力要求),画面上に社員情報が表
示されたとき(出力検索),それを見る処理を示している。
トランザクション ファンクションの詳細を,箇条8に示す。
4 利用者要件記述
ここでは,プロジェクト又はシステムに対する利用者機能要件を定義するときの利用者の役割について
――――― [JIS X 0142 pdf 16] ―――――
13
X 0142 : 2010
の概念を示す。
4.1 利用者要件記述の定義
利用者要件記述とは,利用者の言葉による利用者業務の公式な記述のことをいう。開発者は,これを実
現するために,利用者情報を情報技術の言語に変換する。
ファンクションポイント計測は,利用者及び開発者の両者に共通の言語で表した情報を利用して達成さ
れる。
利用者要件記述とは,次のことをいう。
− 業務機能の記述である。
− 利用者に承認されている。
− ファンクションポイントを計測するために利用できる。
− 物理的な様式は多様である(例えば,トランザクションのカタログ,提案書,要件書,外部仕様書,
詳細仕様書,利用者マニュアルなど)。
4.2 システムのライフサイクルを通した規模測定
プロジェクトの初期段階では,利用者機能要件は急速に拡大する。システムに組み入れる機能の選択に
ついては,利用者と開発者との間で合意されなければならない。プロジェクトの機能に関するこうした決
定は,次のものから影響を受ける。
− 組織のニーズ
− プロジェクトに関連した(業務及び技術に関する)リスク
− プロジェクトに割当てできる組織内での資源(例えば,予算,要員)
− 組織内で利用可能な技術
− コメント及び提案を通しての利用者又は開発者の影響
プロジェクトの開始時には,実現可能性の検討を行う。実現可能性の検討の結果として得られるものは,
抽象度の高い仕様書であり,通常は,非常に簡潔に記述される。例えば,次のようなものをいう。
− 組織は,新税法に対応するシステムを必要とする。
− 組織は,より効率的な在庫管理を実施するためのシステムを必要とする。
− 組織は,より効率的に人事情報を取り扱うシステムを必要とする。
実現可能性の検討の後,利用者は時間の経過とともに要件を詳細化する。ある時点で利用者は,ソフト
ウェア開発者と協議して詳細な要件を作成する。一方,ソフトウェア開発者は,実現可能性の検討結果を
もとに,早期に開発要件及び実現要件の検討に着手することができる。利用者と開発者とが議論すること
によって,要件が改善される。開発プロセスは組織によって異なっている。この規格では,目的を示すた
めに,要件書を次の三つに分けて説明する。
− 初期利用者要件書
− 初期技術要件書
− 最終機能要件書
他の開発手法と同様に,最終機能要件書の段階で,ファンクションポイントを最も正確に計測すること
ができる。
4.2.1 初期利用者要件書の段階
この段階では,利用者とソフトウェア開発者との間の打合せの前に利用者要件を示す。この段階は,次
の特性を一つ以上もっていてもよい。
− 不完全性
――――― [JIS X 0142 pdf 17] ―――――
14
X 0142 : 2010
例1 初期利用者要件書は,関連する完全性に対して必要な機能を欠いてもよい。
− ユーティリティ機能の欠如
例2 必す(須)の妥当性確認の報告機能又は照会機能を欠いてもよい。
− 実現不可能又は利用困難
例3 利用者は,1時間のCPU処理を必要とするオンライン照会を要求してもよい。
− 一般性の過多
例4 要求には項目数を含まなくてもよい。
− 二人以上の利用者がプロジェクトに責任を負っている場合,機能要求の不統一
例5 要件が同じでない場合,利用者によって特定のプロジェクトの要求事項が異なってもよい。
− アプリケーション境界を考慮せずに規定された要件
例6 現在及び/又は将来のアプリケーション境界が考慮されていなくてもよい。
− 機能規模分析の概念又は定義に矛盾する表現
例7 初期利用者要件書は,システムの物理的又は運用的な事項に言及してもよい。
a) 事例
人事情報システムでは,利用者は,次のように要件を表現する。
“社員に関する作業を行っている間はいつでも,社員氏名を入力することによってその社員の情報が見
ることができるようにして欲しい。”
この要件は,照会画面の開発及び社員に関するひとまとまりのデータの開発を意味している(事例を単
純にするために,詳細には示さないが,社員に関するひとまとまりのデータは,社員の追加,更新及び削
除といった別の社員対応機能で内部的に維持管理される。)。
初期利用者要件書における機能の例には,次のものがある。
EQ 特定の社員に対する照会
ILF 社員に関するひとまとまりのデータ
4.2.2 初期技術要件書の段階
この段階では,実現可能性の検討から生成される,ソフトウェア開発者の視点からの要件を示す。既存
のアプリケーションがある場合,その中に要件を組み入れることはソフトウェア開発者の仕事の一つであ
る。初期技術要件書は,実現には必要とするが,ファンクションポイント計測には使用しない要素を含ん
でもよい(例えば,一時ファイル,索引など)。初期技術要件書は,次の特性を一つ以上もっている。
− 技術依存
例1 物理ファイルは,データベース環境によって変化する。
− 利用者の機能要求の誤識別
例2 ソフトウェア開発者は,利用者が要求していない機能を追加してもよい。
− 利用者にとってなじみのない用語
例3 ソフトウェア開発者は,論理的なデータではなく,物理的ファイルに言及してもよい。
− 技術的制約を過度に重視して,機能が決定されてもよい。
例4 開発者は,その組織で現在利用可能な計算機の処理能力に注目して,要求範囲を制限する傾
向がある。
− 組織の中の他のアプリケーションの技術的な構造に従って,アプリケーション境界が決定される。
例5 クライアントとサーバとでは技術要件が異なってもよいが,ファンクションポイントを計測
するときは,同一のアプリケーション境界に含まれる。
――――― [JIS X 0142 pdf 18] ―――――
15
X 0142 : 2010
a) 事例
初期利用者要件書の段階と同一の事例を用いると,開発者は,次のように示している。
“社員照会の要求は理解する。特定の社員の情報を高速で取り出すためには索引を必要とする。”
初期技術要件書で機能は,次のように識別されることがある。
EQ 特定の社員に対する照会
ILF 社員に関するひとまとまりのデータ
ILF 1) 社員ファイルに関する索引
注1) この規格では,索引ファイルは計測対象ではない。この事例では,ソフトウェア開発者が犯
しやすい計測誤りを示すために索引ファイルを誤ってILFと識別している。
4.2.3 最終機能要件書の段階
この段階では,最終機能要件書は,利用者とソフトウェア開発者との共同作業の結果から得られる。共
同作業は,システムの矛盾のない完全な機能要件書を作成するために必要になる。この段階では,開発段
階を開始する前の,機能要件書の最終版であり,次の特性をもつ。
− 利用者及びソフトウェア開発者の両者が理解できる用語で書かれている。
− 他の利用者の要件も含めて,すべての利用者要件を統合した記述を提供している。
− ファンクションポイントを正確に計測するために十分な程度に完全で,矛盾がない。
− すべてのプロセス及びすべてのデータが利用者によって承認されている。
− 実現可能性及び使用性がソフトウェア開発者によって承認されている。
a) 事例
初期利用者要件書の段階と同一の事例を用いると,次のようになる。
利用者 “社員に関する作業を行っている間はいつでも,社員氏名を入力することによってその社員
の情報を見ることができるようにして欲しい。”
開発者 “社員照会の要求は理解する。しかし,同じ氏名をもつ社員がいるかもしれない。氏名を入
力するだけでは社員を特定することはできない。したがって,社員を選択するための社員一
覧画面(社員氏名,事業所及び保険者番号)を提案する。特定の社員の情報を高速で取り出
すためには索引を必要とする。”
利用者 “この場合,社員一覧画面が必要なことについては了解した。また,その機能は,社員選択
以外の目的にも利用できるかもしれない。”
利用者と開発者との議論の結果は,次のとおりになる。
− 機能要件書に社員一覧画面を追加し,ファンクションポイント計測を行う。
− 社員索引は,技術的な解決策であるため,ファンクションポイント計測から除く。
この例の最終機能要件書に含まれる機能は,次のとおりになる。
EQ 特定の社員に対する照会
EQ 社員一覧画面
ILF 社員に関するひとまとまりのデータ
最終機能要件書は,開発段階を開始する前の,要件の最終版である。この時点で,文書化した要件書が,
完全で,正式で,承認されていることに合意していることが望ましい。計測範囲に追加の変更がないとす
れば,ファンクションポイントは,開発の完了時のファンクションポイントと一致する。
4.3 ライフサイクル段階の比較
ファンクションポイントを計測する前に,アプリケーションのライフサイクル段階を決め,見積もろう
――――― [JIS X 0142 pdf 19] ―――――
16
X 0142 : 2010
としているのか又は測定しようとしているのかを決める。いろいろな前提を記述する。
ファンクションポイント分析を完了するため,見積りには,未知の機能及び/又はそれらの複雑さにつ
いて前提を設けてもよい。
ファンクションポイント分析を完了するため,測定には,すべての機能及びそれらの複雑さの識別を包
含する。
初期の段階では,初期利用者要件だけがファンクションポイント分析のために入手できる唯一の文書で
ある。このような不利な点があるが,この計測値は,初期見積りを行うために有効である。様々なライフ
サイクル段階における,見積りのためのファンクションポイント法の用途を,表1に示す。
表1−ファンクションポイント法の用途
ライフサイクル段階 規模の見積りは可能か。 規模の測定は可能か。
提案 : 利用者がニーズ及び意図を表現する。 可能 不可能
要件 : 開発者及び利用者がレビューを行い,利用者 可能 可能
ニーズ及び意図の表現について合意する。
設計 : 開発者は,ファンクションポイント分析では 可能 可能
利用されない要素の実現を含めてもよい。
構築 可能 可能
出荷 可能 可能
修正保守 可能 可能
注記 特定のライフサイクルを意味しているわけではない。開発者と利用者とが対話する手法を使用する場合,
アプリケーションのライフサイクルにおけるある時点での見積りを期待できる。十分注意し,新規であ
れ,改良であれ,合意された利用者ニーズ及び意図を測定する。
4.4 計測上の留意点
次の留意点は,アプリケーションに対する利用者要件記述の識別に役立ち,ファンクションポイント法
の適用に役立つ。
− 利用者の観点からデータを論理的にみるとき,一つの物理的ファイルが一つの論理的ファイルに対応
すると想定しない。
− リレーショナルDBMSのテーブル又は順編成ファイルのような,ある種のデータ蓄積技術は,ILF又
はEIFと密接に関連しているが,このことが常に物理対論理の1対1の対応関係に等しいと想定しな
い。
− すべての物理的ファイルは,ILF又はEIFの一部として計測又は包含されなければならないと想定し
ない。
− トランザクション ファンクションを識別するときには,利用者が現在利用している他の紙書式も調べ
てみる。
− 複数の物理的入力,トランザクション ファイル又は画面で発生するトランザクションで,処理ロジッ
クが同じトランザクションは,通常は,一つのトランザクション ファンクション(EI,EO,EQ)に
相当する。
− 論理的にみる場合,一つの物理レポート,画面又はバッチ出力ファイルは,複数のEO及び/又はEQ
に対応できることを念頭に置く。
− 処理ロジックが同じ場合,二つ以上の物理レポート,画面又はバッチ出力ファイルは,一つのEO又
はEQに対応できることを念頭に置く。
− 一組のデータの再ソート又は再整列がその処理ロジックを独自なものとはしないことを念頭に置く。
――――― [JIS X 0142 pdf 20] ―――――
次のページ PDF 21
JIS X 0142:2010の引用国際規格 ISO 一覧
- ISO/IEC 20926:2003(MOD)