この規格 プレビューページの目次
※一部、英文及び仏文を自動翻訳した日本語訳を使用しています。
2 FPA の紹介
この節では、FPA について簡単に説明し、それに関連するいくつかの重要な概念について説明します。より具体的には、節 2.1 は FPA の簡単な概要を提供します。節 2.2 から 2.4 では、さまざまなタイプの関数点分析を区別しています。 2.5 節から 2.9 節では、FPA のコンテキスト内で、次のそれぞれについて連続して説明します。
- 分析の境界
- ユーザー
- 関数の種類
- 関数型の複雑さ
- 関数型の評価
2.10 節では、機能サイズという用語を定義し、その決定方法について説明しています。
2.1 FPA の簡単な説明
2.1.1 FPA の背景、目的、適用
FPA は、1974 年から 1979 年の間に IBM の AJ Albrecht によって、多数のプロジェクトの生産性に関する研究の結果として開発されました。 FPA の最初のリリースは 1979 年に導入され、続いて 1983 年と 1984 年に実際の経験に基づいて適応されました。
FPA は、開発または保守するアプリケーションのサイズを測定するのに役立つ単位であるファンクション ポイントを導入しています。 FPA の枠組みにおける「アプリケーション」という言葉は、「自動化された情報システム」を意味します。ファンクション ポイントは、アプリケーションがユーザーに提供する情報処理の量を表します。この測定単位は、技術的な意味で情報処理が実現される方法とは別のものです。ファンクション ポイントは抽象的な用語であり、いわゆる「レンタル ポイント」といくらか比較することができます。賃貸ポイントは、家の部屋数、これらの部屋の表面積、家にある設備の数、および家の場所に基づいています。これは、潜在的なテナントに提供される住居の測定値として機能します。
FPA は、アプリケーションを構築した後のシステム開発とシステム保守の生産性を測定するために最初に使用されました。 FPA に必要なデータはプロジェクトの早い段階で利用できるため、この手法をプロジェクトの予算編成のサポートにも使用できることがすぐに明らかになりました。
2.1.2 FPA の背後にある合理性
「ファンクション ポイント分析」という用語を構成する 3 つの単語は、FPA の背後にある考え方を説明するために使用できます。
関数
前述のように、FPA は、アプリケーションがユーザーに提供する機能に基づいています (2.6 節を参照)ユーザーはアプリケーションの「外側」または境界(節 2.5 を参照) しか見えないため、FPA は、アプリケーションとその環境との情報交換を記述する仕様を調べます。機能は、着信および発信情報フロー (データまたは制御情報の両方) と、アプリケーションが格納または使用する論理ファイルから派生します。アプリケーションの機能は、データ機能とトランザクション機能を識別することによって測定されます (2.7 節を参照)
点
関数型の複雑さは、特定の標準ガイドラインに従って決定されます (2.8 節を参照)各機能は、その複雑さに応じて、いくつかのポイントの価値があります (セクション 2.9)これらのポイントの合計が機能サイズになります (2.10 節を参照)
分析
FPA は、アプリケーションの分析、またはアプリケーションの機能サイズを確立するためのアプリケーションの説明/仕様の分析です。したがって、アプリケーションまたはプロジェクトの機能サイズを確立する行為は、ファンクション ポイント分析と呼ばれます。
ファンクション ポイント分析を実行できるようにするには、まず次のことを決定する必要があります。
- ファンクションポイント分析の目的 (2.2 節);
- 分析の範囲と、分析対象のアプリケーションまたはプロジェクトの境界 (2.5 節)
以上で、方法論の概要と FPA の簡単な説明を終わります。以下の節では、FPA で使用されるさまざまな用語について説明します。
2.2 FPA の使用:アプリケーションとプロジェクトの機能規模
機能サイズは、アプリケーションまたはプロジェクトにリンクできます。これは、次の 2 つの目的が区別されることを意味します。
- アプリケーションの機能サイズの決定。
- プロジェクトの機能規模の決定。
アプリケーションの機能サイズ
アプリケーションがユーザーに提供する、または既に提供している機能の量の尺度であるファンクション ポイントの数です。また、維持する必要があるアプリケーションの機能サイズの尺度でもあります。
プロジェクトの機能サイズ
新しいアプリケーションの機能の量または既存のアプリケーションへの変更の尺度である関数ポイントの数です。既存のアプリケーションへの変更は、機能の追加、変更、および削除に持続します。プロジェクトの機能サイズは、プロジェクトに必要な工数とスケジュールを決定する際の重要なパラメーターです。
アプリケーションの機能サイズの決定については、3.5 節で詳しく説明します。セクション 3.6 では、プロジェクトの機能規模について詳しく説明しています。
2.3 ファンクションポイント分析の種類
ファンクションポイント解析は、仕様の詳細度に応じて3種類から選択できます。以下は、さまざまなタイプのファンクション ポイント解析を表しています。それらは詳細度別にリストされていることに注意してください。1 番目は詳細度が最も低く、3 番目は最も詳細度が高いです。
- 1指標機能点分析
- 2高レベルのファンクション ポイント分析 (以前は [推定] と呼ばれていました)
- 3詳細機能点分析
これらのファンクション ポイント分析については、3.2 節で詳しく説明します。
2.4 プロジェクト中のファンクションポイント分析
ファンクション ポイント分析は、プロジェクト中のさまざまな時点で実行できます。したがって、それらはプロジェクトのフェーズ (計画フェーズ、実行フェーズ、評価フェーズなど) に関連付けることができます。その結果、機能点分析の内訳として、初期機能点分析、中間機能点分析、および最終機能点分析 が生じます。これらの分析については、3.4 節で詳しく説明します。
2.5 分析範囲と分析対象アプリケーションの境界
分析の範囲は、機能点分析に含まれる機能要件/仕様のセットです。スコープが決定されると、アプリケーションとそのユーザーおよび/または他のアプリケーションとの間の概念的なインターフェースである境界を定義できます。
2.1 節で前述したように、分析の範囲とカウントされるアプリケーションの境界は、FPA で重要な役割を果たします。したがって、関数点分析を実行できるようにするには、カウントするアプリケーションの境界を最初に決定する必要があります。
境界は、以下を決定できるようにするために必要です。
- 特定のデータが属するアプリケーション。
- どのデータが境界を越えるか。
2.2 節で述べたように、アプリケーションのファンクション ポイント分析とプロジェクトのファンクション ポイント分析は区別されます。セクション 3.5.1 は、アプリケーションの機能サイズを決定するためのガイドラインを提供し、セクション 3.6.1 は、プロジェクトの機能サイズを決定するためのガイドラインを提供します。
2.6 ユーザー
FPA は、次の 3 種類のユーザーを認識します。
- 測定対象のアプリケーションを使用する、または使用する予定の人や組織。このカテゴリには、特に次のものが含まれます: エンドユーザー、機能管理者、およびオペレーター。
- 仕様に含まれる要件と希望を決定する所有者および/または従業員。これらの要件と希望は、たとえばエンドユーザーの要求に基づいて記録されますが、政府またはその法律がアプリケーションに課す要件にも基づいて記録されます。
- 分析対象のアプリケーションのデータまたは機能を使用するその他のアプリケーション。
ファンクションポイントの分析はユーザーの視点で行われるため、常にユーザーと協力して行うか、少なくとも分析結果をユーザーに検証してもらう必要があります。結局のところ、特定の機能が要求されているかどうかを判断できるのはユーザーだけです。
2.7 関数と関数の種類
ファンクション ポイント分析は、アプリケーション (の一部) の機能のサイズを測定します。分析は、分析対象のアプリケーションの方法ではなく、何を中心に展開します。ユーザーが要求し、認識し、重要と見なすことができるコンポーネントのみが評価されます。これらのコンポーネントは、機能または基本機能コンポーネントと呼ばれます。関数は関数型に属します。
FPA は、関数の型 を次のように 定義します。
FPA の観点から見た、アプリケーションが存在する 5 つのタイプのコンポーネント。これらのコンポーネントは、アプリケーションがユーザーに提供する機能の量を決定します。
図 2 —関数と関数の種類
関数の種類は、主に次の 2 つのグループに分類されます。
- データ関数の種類
- トランザクション関数のタイプ
データ関数は次のとおりです。
ユーザーの視点から見たデータの論理グループ。 FPA は、次のデータ関数タイプを区別します。
- 内部論理ファイル
- 外部論理ファイル
トランザクション関数 is
次の基準を満たす基本的なプロセス:
- 機能はユーザーにとって自律的な意味を持ち、1 つの完全な情報の処理を完全に実行します。
- 関数が実行された後、アプリケーションは一貫した状態になります。
FPA は、次のトランザクション関数タイプを区別します。
- 外部入力
- 外部出力
- 外部からの問い合わせ
各機能タイプについては、5 節から 9 節で詳しく説明します。
2.8 関数の複雑さ
関数の複雑度は次のように定義されます。
関数に割り当てられる関数ポイントの基準となる関数の重み。
関数の複雑度は、適切な複雑度マトリックスを使用して決定されます。関数の種類ごとに個別のテーブルが定義されています。複雑さは、データ要素タイプの数と、特定の関数に接続されている参照論理ファイルの数によって異なります。複雑さの 3 つのレベルが区別されます。
| 低い： | 関数に関連するデータ要素タイプや参照論理ファイルはほとんどありません。 |
| 平均： | 機能は、複雑さに関して低くも高くもありません。 |
| 高い： | 多くのデータ要素タイプおよび/または参照される論理ファイルが関数に関係しています。 |
複雑さのレベルを決定する複雑さの表は、付録 A に含まれています。
2.9 機能の評価
5節から9節で説明したように関数の複雑さが決定された後、関数点の数を関数に割り当てることができます。これは、表 1 の定格に従って行う必要があります。
表 1 —機能点表
高レベルの機能ポイント分析を実行する際に機能とそのタイプを識別するには、高レベルの仕様で十分ですが (3.2.2 節を参照)、これらの機能の複雑さを判断することは困難です。このような場合、データ関数は低と評価され、トランザクション関数には平均評価が使用されます。
2.10 機能サイズ
機能ポイントの数: 機能サイズを参照 機能サイズは、分析対象のオブジェクトの範囲内にある各機能 (上記の方法で) に割り当てられた機能ポイントの数の合計です。プロジェクト。
機能サイズは、機能ポイントの数に履歴データ (機能ポイントあたりの時間など) に基づく生産性率を掛けることによって、プロジェクト予算を準備するための基礎としても役立ちます。プロジェクト予算の準備は、この規格の焦点を超えています。このテーマの詳細については、Nesma の Web サイト nesma.org を参照してください。
ソフトウェアの機能ユーザー要件または仕様に関する Nesma FSM 測定結果は、次の規則に従ってラベル付けされます。
F(関数) P(oint) (ISO/IEC 24570:2018) |
2 Introduction to FPA
This clause gives a short description of FPA and explains a number of important concepts related to it. More specifically, subclause 2.1 provides a brief synopsis of FPA. Subclauses 2.2 through 2.4 distinguish between the different types of function point analyses. Subclauses 2.5 through 2.9 discuss each of the following successively within the context of FPA:
- The boundaries for an analysis
- Users
- Function types
- The complexity of a function type
- The valuing of function types
Subclause 2.10 defines the term functional size and describes how it is determined.
2.1 Brief description of FPA
2.1.1 Background, purpose and application of FPA
FPA was developed by A.J. Albrecht at IBM between 1974 and 1979 as a result of productivity research into a large number of projects. The first release of FPA was introduced in 1979, followed by adaptations based on practical experiences in 1983 and 1984.
FPA introduces a unit, the function point, to help measure the size of an application that is to be developed or maintained. The word"application" within the framework of FPA means"an automated information system". The function point expresses the quantity of information processing that an application provides to a user. This unit of measurement is separate from the way in which the information processing is realized in a technological sense. A function point is an abstract term and can be compared somewhat to so-called"rental points". Rental points are based on the number of rooms in a house, the surface area of these rooms, the number of facilities the house has, and the location of the house. This then serves as a measurement for a residence offered to a potential tenant.
FPA was first used to measure the productivity of system development and system maintenance after an application was built. It soon became clear that the technique could also be used to support project budgeting because the data needed for an FPA can be made available early on in a project.
2.1.2 Rationale behind FPA
The three separate words that make up the term"Function Point Analysis" can be used to explain the way of thinking behind FPA.
Function
As mentioned earlier, FPA bases itself on the functionality that an application provides to a user (see subclause 2.6). Because users see only the"outside" or the boundary (see subclause 2.5) of an application, FPA examines the specifications that describe the application's exchange of information with its environment. Functionality is derived from incoming and outgoing information flows (these can be both data or control information), as well as from the logical files that an application contains or uses. The functionality of an application is measured by identifying data functions and transactional functions (see subclause 2.7).
Point
The complexity of a function type is determined according to certain standard guidelines (see subclause 2.8). Each function is worth a number of points, depending on its complexity (subclause 2.9). The sum of these points yields the functional size (see subclause 2.10).
Analysis
FPA is the analysis of an application or the analysis of the description/specification of an application in order to establish its functional size. The act of establishing the functional size of an application or project is therefore called function point analysis.
In order to be able to perform a function point analysis the following must first be determined:
- purpose of the function point analysis (subclause 2.2);
- scope of the analysis and boundaries of the application or project to be analyzed (subclause 2.5).
This concludes a summary of the methodology and a brief description of FPA. The subclauses that follow explain the various terms used in FPA.
2.2 Use of FPA: application versus project functional size
Functional size can be linked to applications or to projects. This means that a distinction is made between the following two objectives:
- Determining the functional size of an application.
- Determining the functional size of a project.
Application functional size
is the number of function points that is a measure for the amount of functionality that an application is to supply or has already supplied to a user. It also is a measure for the functional size of an application that must be maintained.
Project functional size
is the number of function points that is a measure for the amount of functionality of a new application or of changes to an existing application. Changes to an existing application pertain to adding, changing, and deleting functions. The project functional size is an essential parameter when determining the effort and schedule required for a project.
Determining the application functional size is elaborated on in subclause 3.5. Subclause 3.6 discusses the project functional size further.
2.3 Types of function point analyses
One of three types of function point analyses can be chosen, depending on the degree of detail of the specifications available. The following represent the different types of function point analyses. Notice that they are listed by degree of detail, number one having the least detail and number three the most:
- 1 Indicative function point analysis
- 2 High level function point analysis (previously known as Estimated)
- 3 Detailed function point analysis
These function point analyses are explained further in subclause 3.2.
2.4 Function point analyses during a project
Function point analyses can be carried out at different times during a project. They can therefore be related to the phases of a project (e.g. the planning phase, the execution phase, and the evaluation phase). As a result, the following breakdown of function point analyses arises: the initial function point analysis, the interim function point analysis, and the final function point analysis. These analyses are discussed further in subclause 3.4.
2.5 Scope of the analysis and boundary of the application to be analyzed
The scope of the analysis is the set of functional requirements/specifications to be included in the function point analysis. When the scope has been determined, the boundary can be defined, the conceptual interface between the application and its users and/or other applications.
As indicated earlier in subclause 2.1, the scope of the analysis and the boundary of an application to be counted plays an important role in FPA. Consequently, the boundaries of the application to be counted must first be determined in order to be able to perform a function point analysis.
The boundary is necessary in order to be able to determine:
- the application that certain data belongs to;
- which data crosses the boundary.
As mentioned in subclause 2.2, a distinction is made between a function point analysis for an application and a function point analysis for a project. Subclause 3.5.1 provides guidelines for determining the application functional size and subclause 3.6.1 gives guidelines for determining the project functional size.
2.6 Users
FPA acknowledges three types of users:
- The people and/or organizations that use or are going to use the application to be measured. This category includes, amongst others, the following: end-users, functional managers, and operators.
- The owner and/or employee(s) who determine(s) the requirements and wishes included in the specifications. These requirements and wishes are recorded on the basis of the demands of the end-user(s) for example, but also on the basis of requirements that a government or its legislation can impose on the application.
- Other applications that use the data or the functions of the application to be analyzed.
Because the function point analysis takes place from the perspective of the user(s), it is always necessary to have it done in cooperation with the user or, at the very least, to have the result of the analysis verified by the user. The user, after all, is the only one who can determine whether a certain function is being requested.
2.7 Functions and function types
The function point analysis measures the size of the functions of (a part of) an application. The analysis revolves around the what and not the how of the application to be analyzed. Only those components that the user requests, can recognize and considers significant are assessed. These components are called functions or base functional components. A function belongs to a function type.
FPA defines function types as follows:
The five types of components of which an application exists, as seen from the perspective of FPA. These components determine the amount of functionality an application provides to a user.
Figure 2—Functions and function types
Function types are categorized into two main groups:
- Data function types
- Transactional function types
A data function is:
a logical group of data seen from the perspective of the user. FPA distinguishes between the following data function types:
- Internal logical files
- External logical files
A transactional function is
an elementary process that meets the following criteria:
- the function has an autonomous meaning to the user and fully executes one complete processing of information, and
- after the function has been executed, the application is in a consistent state.
FPA distinguishes between the following transactional function types:
- External inputs
- External outputs
- External inquiries
Each function type is discussed in detail in clauses 5 through 9.
2.8 The complexity of a function
The complexity of a function is defined as follows:
The weight of a function on the basis of which a number of function points are allocated to the function.
The complexity of a function is determined by using the appropriate complexity matrix. A separate table has been defined for each function type. Complexity depends on the number of data element types and the number of referenced logical files connected to a given function. Three levels of complexity are distinguished:
| Low: | Few data element types and/or referenced logical files are involved with the function. |
| Average: | The function is neither low nor high with regards to complexity. |
| High: | Many data element types and/or referenced logical files are involved with the function. |
The complexity tables that determine the levels of complexity are included in Annex A.
2.9 The valuing of functions
After the complexity of a function has been determined as described in clauses 5 through 9, the number of function points can be allocated to the function. This shall be done according to the rating in Table 1.
Table 1—Function point table
High level specifications are enough to identify functions and their type when performing a high level function point analysis (see subclause 3.2.2), but it will be difficult to determine the complexity of these functions. In such a case, a data function is rated as low, while the rating average is used for a transactional function.
2.10 The functional size
The Number of function points: see Functional size functional size is the sum of the number of function points assigned to each of the functions (in the way described above) that lie within the scope of the object to be analyzed, that is the application or the project.
The functional size can also serve as a basis for preparing a project budget, by multiplying the number of function points with a productivity rate based on historical data (such as hours per function point). The preparation of a project budget is beyond the focus of this standard. More information on this subject can be found on the Nesma website nesma.org .
A Nesma FSM measurement result on the functional user requirements or specifications for a piece of software shall be labeled according to the following convention:
F(unction) P(oint) (ISO/IEC 24570:2018) |