ISO/IEC 21122-2:2022/Amd 1:2022 (W) 情報技術 — JPEG XS 低遅延軽量画像コーディング システム — Part 2:プロファイルとバッファ モデル — 修正 1:4:2:0 コンテンツのプロファイルとサブレベル | ページ 6

※一部、英文及び仏文を自動翻訳した日本語訳を使用しています。

3 用語と定義

この文書の目的上、次の用語と定義が適用されます。

3.1

適応型メンテナンス

変更された環境または変化する環境でソフトウェア製品を使用可能な状態に保つために、納品後に実行されるソフトウェア製品の修正。

注記 1:適応型メンテナンスは、ソフトウェア製品が動作する必要がある環境の変化に対応するために必要な機能拡張を提供します。これらの変化は、環境の変化に対応するために行われなければならないものです。たとえば、オペレーティング システムがアップグレードされ、新しいオペレーティング システムに対応するためにいくつかの変更が加えられる場合があります。

[出典:ISO/IEC 14764:2006, 3.1]

3.2

応用

1 つ以上のコンポーネント、モジュール、またはサブシステムで構成される、ビジネス目標をサポートする自動化された手順とデータのまとまったコレクション

例:

買掛金、売掛金、給与計算、調達、工場生産、組立ライン制御、航空捜索レーダー、目標追跡、武器の発射、飛行ラインのスケジュール設定、乗客の予約。

3.3

アプリケーションの機能サイズ

アプリケーションがユーザーに提供する機能の尺度。アプリケーションの機能ポイント数によって決定されます。

3.4

アプリケーション機能ポイント数

アプリケーションの機能サイズを測定するためにこの国際標準を適用する活動

3.5

アレンジする

トランザクション関数内のシーケンス属性のアクティビティ

3.6

関連エンティティ タイプ

他の 2 つのエンティティ タイプ間の多対多の関係をさらに記述する属性を含むエンティティ タイプ

3.7

属性エンティティ タイプ

別のエンティティ タイプの 1 つ以上の属性をさらに説明するエンティティ タイプ

3.8

基本機能コンポーネント

BFC

測定目的で FSM メソッドによって定義され、使用される機能ユーザー要件の基本単位

例:

機能的なユーザー要件は「顧客の維持」であり、これは次の BFC で構成されます:「新しい顧客の追加」、「顧客の購入の報告」、および「顧客の詳細の変更」。別の例には、「顧客の詳細」など、研究対象のソフトウェアによって維持される論理的に関連するビジネス データのコレクションが含まれる場合があります。他にも多くの例があります。

[出典:ISO/IEC 14143-1:2007, 3.1]

3.9

境界

研究対象のソフトウェアとそのユーザーの間の概念的なインターフェイス

[出典:ISO/IEC 14143-1:2007, 3.3]

注記 1: ISO/IEC 20926:2003 では、 「アプリケーション境界」という用語が使用されています。

3.10

一貫した状態

処理が完全に実行された時点で、機能ユーザー要件が満たされ、それ以上行うことはありません。

例 1:

機能ユーザーの要件は、小切手を印刷し、適切なアカウントに支払い済みのマークを付けることです。機能的ユーザー要件の一部のみが完了している場合 (たとえば、小切手を印刷するだけ、または支払い済みとしてマークするだけ)、アプリケーションは一貫した状態にありません。アカウントを支払済みとしてマークせずに小切手を印刷すると、印刷せずに小切手を支払済みとしてマークした場合と同様に、アプリケーションで不整合が発生します。

例 2:

機能ユーザーの要件は、入力ファイルを受け入れてデータ ストアを更新し、運用管理レポートを作成し、送信側アプリケーションにエラー レポートを返すバッチ プロセスを備えていることです。これらの部分がすべて完了しない限り、プロセスは一貫した状態にはなりません。

例 3:

機能ユーザー要件は、従業員を新しい仕事に異動させ、その従業員のセキュリティ クリアランス レベルを検証することです。これを完了するには、セキュリティ アプリケーション (アプリケーションのセキュリティではなく政府のセキュリティ クリアランスを維持します) にリアルタイムのリクエストが送信され、転送が完了する前に応答が受信されます。一貫した状態を作成するには、すべての手順が必要です。セキュリティ アプリケーションとの対話は、独立したステップまたはアクションではありません。これ自体は発生しません。また、従業員を異動させるトランザクションは、これがなければ一貫した状態になりません。

3.11

制御情報

データをいつ、何を、どのように処理するかを指定することによって基本プロセスに影響を与えるデータ

3.12

変換機能

データを変換したり、その他のユーザー指定の変換要件を提供したりするために提供されるトランザクション関数またはデータ関数

注記 1:変換機能は、アプリケーションの開発または拡張中にのみ存在します。

3.13

事後保全

発見された問題を修正するために納品後に実行されるソフトウェア製品の事後的な修正

注記 1: この変更により、要件を満たすようにソフトウェア製品が修復されます。

[出典:ISO/IEC 14764:2006, 3.2]

3.14

カウント範囲

機能ポイント数に含まれる一連の機能ユーザー要件

3.15

データ要素のタイプ

DET

ユニークで、ユーザーが認識できる、繰り返されない属性

3.16

データ関数

内部または外部のデータ ストレージ要件を満たすためにユーザーに提供される機能

注1:​​データ関数は、内部論理ファイルまたは外部インタフェース・ファイルのいずれかです。

3.17

派生データ

データ関数からの情報の直接的な取得と検証以外の、またはそれに加えて行われるステップを伴う処理の結果として作成されたデータ

3.18

開発プロジェクト

ソフトウェア アプリケーションの最初のリリースを開発して提供するプロジェクト

3.19

開発プロジェクトの機能サイズ

ソフトウェアの最初のリリースでユーザーに提供される機能の尺度。開発プロジェクトの機能ポイント数によって測定されます。

注記 1: 開発プロジェクトの機能サイズには、変換機能のサイズが含まれる場合があります。

3.20

開発プロジェクト機能ポイント数

開発プロジェクトの機能規模を測定するためにこの国際規格を適用する活動

3.21

基本的なプロセス

ユーザーにとって意味のあるアクティビティの最小単位

3.22

強化プロジェクト

適応型メンテナンスを開発および提供するプロジェクト

注記 1: 拡張プロジェクトでは、修正保守および完全保守を開発および提供することもできますが、これらは拡張プロジェクトの機能規模には影響しません。

3.23

プロジェクトの機能サイズ

拡張プロジェクトの完了時に追加、変更、または削除された機能の尺度。拡張プロジェクトの機能ポイント数によって測定されます。

注記 1: 拡張プロジェクトの機能サイズには、変換機能のサイズが含まれる場合があります。

3.24

強化プロジェクト機能ポイント数

強化プロジェクトの機能規模を測定するためにこの国際規格を適用する活動

3.25

エンティティ依存

他のエンティティの存在がなければ、ビジネス自体にとって意味がないか、重要ではありません。
  • エンティティ X の出現はエンティティ Y の出現にリンクされている必要があり、また
  • エンティティ Y のオカレンスを削除すると、エンティティ X の関連するオカレンスがすべて削除されます。

3.26

エンティティに依存しない

他のエンティティの存在がなくても、それ自体でビジネスにとって意味のある、または重要な

3.27

外部入力

境界外から送信されたデータや制御情報を処理する基本プロセス

注記 1:外部入力は、基本機能コンポーネントの一種です。

3.28

社外からのお問い合わせ

EQ

データまたは制御情報を境界の外に送信する基本プロセス

注記 1:外部問い合わせは、基本機能コンポーネントの一種です。

3.29

外部インターフェースファイル

EIF

ユーザーが認識できる論理的に関連したデータまたは制御情報のグループ。測定対象のアプリケーションによって参照されますが、別のアプリケーションの境界内に維持されます。

注記 1:外部インターフェース・ファイルは、基本機能コンポーネントの一種です。

3.30

外部出力

eo

データまたは制御情報を境界の外に送信し、外部問い合わせのロジックを超える追加の処理ロジックを含む基本プロセス

注記 1:外部出力は、基本機能コンポーネントの一種です。

3.31

参照されるファイルType

FTR

トランザクション関数によって読み取られるおよび/または維持されるデータ関数

3.32

機能の複雑さ

この国際規格内で定義されているルールを使用して関数に割り当てられる特定の複雑さの評価

3.33

機能的なサイズ

ユーザーの機能要件を定量化することで得られるソフトウェアのサイズ

[出典:ISO/IEC 14143-1:2007, 3.6]

3.34

機能的なユーザー要件

タスクとサービスに関してソフトウェアが何を行うかを指定するユーザー要件のサブセット

注記 1: 機能ユーザー要件には以下が含まれますが、これらに限定されません。
  • データ転送 (例: 顧客データの入力、制御信号の送信);
  • データ変換 (例: 銀行金利の計算、平均気温の導出)
  • データストレージ (例: 顧客の注文を保存、周囲温度を経時的に記録);
  • データの取得 (例: 現在の従業員のリスト、航空機の位置の取得)

機能ユーザー要件ではないユーザー要件には次のものが含まれますが、これらに限定されません。
  • 品質の制約 (例: 使いやすさ、信頼性、効率性、移植性)
  • 組織上の制約 (例: 運用場所、ターゲット ハードウェア、標準への準拠)
  • 環境上の制約 (例: 相互運用性、セキュリティ、プライバシー、安全性)
  • 実装上の制約 (例: 開発言語、納品スケジュール)

注記 2: ISO/IEC 14143-1:2007, 3.8 から適応。

3.35

ファンクションポイント

FP

この国際規格内で定義されている機能的サイズの測定単位

3.36

ファンクションポイント分析

FPA

この国際規格内で定義されている機能的サイズの測定方法

3.37

機能ポイント数

アプリケーションまたはプロジェクトの機能サイズを測定するために、この国際標準内のルールを適用する活動

注記 1: 機能ポイント数には、アプリケーション、開発プロジェクト、拡張プロジェクトの 3 種類があります。

3.38

関数の種類

この国際規格で特定される基本機能コンポーネントのタイプ

注記 1:この国際規格で識別されている 5 つの関数タイプは、外部入力、外部出力、外部問い合わせ、内部論理ファイル、および外部インターフェースファイルです。

3.39

内部論理ファイル

ILF

測定対象のアプリケーションの境界内に維持される、論理的に関連したデータまたは制御情報のユーザーが認識できるグループ

注記 1:内部論理ファイルは、基本機能コンポーネントの一種です。

3.40

維持する

基本プロセスによるデータの追加、変更、削除

3.41

意味のある

ユーザーが認識可能であり、機能ユーザー要件を満たしている

3.42

完璧なメンテナンス

納品後にソフトウェア製品に修正を加え、ソフトウェア製品の潜在的な欠陥を障害として現れる前に検出して修正すること

注記 1: ISO/IEC 14764:2006, 3.7 から適応。

注記 2:完全保守は、ユーザーに対する機能拡張、プログラム文書の改善、およびソフトウェアのパフォーマンス、保守性、またはその他のソフトウェア属性を改善するための再コーディングを提供します。

注記 3:適応型メンテナンスと対比してください。修正メンテナンス。

3.43

主な目的

まず重要な意図

3.44

処理ロジック

検証、アルゴリズムまたは計算、データ関数の読み取りまたは維持などの基本プロセスを完了するためにユーザーが特に要求した要件のいずれか

3.45

カウントの目的

関数ポイントカウントを実行する理由

3.46

レコード要素のタイプ

RET

データ関数内のユーザーが認識できるデータ要素タイプのサブグループ

3.47

自己完結型

機能ユーザー要件を開始または完了するために、前後の処理ステップは必要ありません。

例:

機能ユーザー要件には、従業員を追加および更新する必要があると記載されています。完全な従業員情報を構成する複数の部分が存在する場合があります。これは、次のような個別の物理画面、ウィンドウ、またはタブで表すことができます。
  • 従業員の身分証明書、
  • 従業員の所在地、
  • 扶養家族情報、
  • 給与情報など
  • 教育。

従業員を追加するには、ビジネス ルールに応じて 1 つ以上のタブを完了する必要があります。追加プロセスは、すべての必須情報が入力されるまでは自己完結型ではありません。
従業員を更新するために、いつでも 1 つ以上のタブを更新できますが、それらはすべて、従業員を更新するという機能ユーザー要件を満たすプロセス ステップです。個々のタブでの情報の追加、変更、削除は、個別の基本プロセスではありません。これは、従業員の更新に含まれるプロセス ステップです。従業員レコードに追加情報を入力することもできますが、すべての情報は、従業員の更新という単一の基本プロセスの一部とみなされます。
「従業員の追加」と「従業員の更新」はそれぞれ自己完結型のプロセスになります。

3.48

並べ替え

トランザクション関数における行またはレコードの順序付けのアクティビティ

3.49

トランザクション関数

データを処理するための機能をユーザーに提供する基本プロセス

注記 1: トランザクション機能とは、外部入力、外部出力、または外部照会です。

3.50

ユーザー.ユーザー

いつでもソフトウェアと通信または対話する人または物

注記 1: 「物」には、ソフトウェア・アプリケーション、動物、センサー、その他のハードウェアが含まれますが、これらに限定されません。

[出典:ISO/IEC 14143-1:2007, 3.11]

3.51

ユーザーが認識できる

ユーザーとソフトウェア開発者の両方によって合意および理解されたプロセスおよび/またはデータの要件

3.52

ユーザービュー

ユーザーが認識する機能的なユーザー要件

注記 1:開発者は、ソリューションを提供するために、ユーザーの視点をソフトウェアに変換します。

参考文献

1ISO/IEC 14764:2006, ソフトウェア エンジニアリング - ソフトウェア ライフ サイクル プロセス - メンテナンス

3 Terms and definitions

For the purposes of this document, the following terms and definitions apply.

3.1

adaptive maintenance

modification of a software product, performed after delivery, to keep a software product usable in a changed or changing environment

Note 1 to entry: Adaptive maintenance provides enhancements necessary to accommodate changes in the environment in which a software product must operate. These changes are those that must be made to keep pace with the changing environment. For example, the operating system might be upgraded and some changes may be made to accommodate the new operating system.

[SOURCE:ISO/IEC 14764:2006, 3.1]

3.2

application

cohesive collection of automated procedures and data supporting a business objective, consisting of one or more components, modules, or subsystems

EXAMPLE:

Accounts payable, accounts receivable, payroll, procurement, shop production, assembly line control, air search radar, target tracking, weapons firing, flight line scheduling and passenger reservations.

3.3

application functional size

measure of the functionality that an application provides to the user, determined by the application function point count

3.4

application function point count

activity of applying this International Standard to measure the functional size of an application

3.5

arranging

activity of sequencing attributes in a transactional function

3.6

associative entity type

entity type that contains attributes which further describe a many-to-many relationship between two other entity types

3.7

attributive entity type

entity type that further describes one or more attributes of another entity type

3.8

base functional component

BFC

elementary unit of Functional User Requirements defined by and used by an FSM Method for measurement purposes

EXAMPLE:

A Functional User Requirement could be “Maintain Customers”, which might consist of the following BFCs: “Add a new customer”, “Report Customer Purchases”, and “Change Customer Details”. Another example might include a collection of logically related business data maintained by the software under study such as “Customer Details”. There are many other examples.

[SOURCE:ISO/IEC 14143-1:2007, 3.1]

3.9

boundary

conceptual interface between the software under study and its users

[SOURCE:ISO/IEC 14143-1:2007, 3.3]

Note 1 to entry: ISO/IEC 20926:2003 used the term “application boundary”.

3.10

consistent state

point at which processing has been fully executed, the Functional User Requirement has been satisfied and there is nothing more to be done

EXAMPLE 1:

The Functional User Requirement is to print a check and mark the appropriate account as paid. If only part of the Functional User Requirement is completed (e.g., only printing the check or only marking it as paid), the application is not in a consistent state. The printing of a check without marking the account as paid causes an inconsistency in the application as does marking it as paid without printing it.

EXAMPLE 2:

The Functional User Requirement is to have a batch process that accepts an input file to update a data store, produce a production control report and return an error report back to the sending application. The process is not in a consistent state unless all of these parts are completed.

EXAMPLE 3:

The Functional User Requirement is to transfer an employee to a new job and validate his/her security clearance level. To complete this, a real-time request is sent to the security application (which maintains government security clearances and not application security) and a response received before the transfer can be completed. All steps are needed to create a consistent state. The interaction with the security application is not an independent step or action. It does not happen in and of itself, and the transaction to transfer an employee is not in a consistent state without it.

3.11

control information

data that influences an elementary process by specifying what, when or how data is to be processed

3.12

conversion functionality

transactional or data functions provided to convert data and/or provide other user specified conversion requirements

Note 1 to entry: Conversion functionality exists only during the development or enhancement of an application.

3.13

corrective maintenance

reactive modification of a software product performed after delivery to correct discovered problems

Note 1 to entry: The modification repairs the software product to satisfy requirements.

[SOURCE:ISO/IEC 14764:2006, 3.2]

3.14

counting scope

set of Functional User Requirements to be included in the function point count

3.15

Data Element Type

DET

unique, user recognizable, non-repeated attribute

3.16

data function

functionality provided to the user to meet internal or external data storage requirements

Note 1 to entry: A data function is either an Internal Logical File or an External Interface File.

3.17

derived data

data created as a result of processing that involves steps other than or in addition to direct retrieval and validation of information from data functions

3.18

development project

project to develop and deliver the first release of a software application

3.19

development project functional size

measure of the functionality provided to the users with the first release of the software, as measured by the development project function point count

Note 1 to entry: The functional size of a development project can include the size of conversion functionality.

3.20

development project function point count

activity of applying this International Standard to measure the functional size of a development project

3.21

elementary process

smallest unit of activity that is meaningful to the user

3.22

enhancement project

project to develop and deliver adaptive maintenance

Note 1 to entry: An enhancement project can also develop and deliver corrective and perfective maintenance, but these do not contribute to the enhancement project functional size.

3.23

enhancement project functional size

measure of the functionality added, changed or deleted at the completion of an enhancement project, as measured by the enhancement project function point count

Note 1 to entry: The functional size of an enhancement project can include the size of conversion functionality.

3.24

enhancement project function point count

activity of applying this International Standard to measure the functional size of an enhancement project

3.25

entity dependent

not meaningful or not significant to the business in and of itself without the presence of other entities, such that
  • an occurrence of entity X must be linked to an occurrence of entity Y, and
  • the deletion of an occurrence of entity Y results in the deletion of all related occurrences of entity X

3.26

entity independent

meaningful or significant to the business in and of itself without the presence of other entities

3.27

External Input

EI

elementary process that processes data or control information sent from outside the boundary

Note 1 to entry: An External Input is a type of base functional component.

3.28

External Inquiry

EQ

elementary process that sends data or control information outside the boundary

Note 1 to entry: An External Inquiry is a type of base functional component.

3.29

External Interface File

EIF

user recognizable group of logically related data or control information, which is referenced by the application being measured, but which is maintained within the boundary of another application

Note 1 to entry: An External Interface File is a type of base functional component.

3.30

External Output

eo

elementary process that sends data or control information outside the boundary and includes additional processing logic beyond that of an External Inquiry

Note 1 to entry: An External Output is a type of base functional component.

3.31

File Type Referenced

FTR

data function read and/or maintained by a transactional function

3.32

functional complexity

specific complexity rating assigned to a function using the rules as defined within this International Standard

3.33

functional size

size of the software derived by quantifying the Functional User Requirements

[SOURCE:ISO/IEC 14143-1:2007, 3.6]

3.34

Functional User Requirements

sub-set of the user requirements specifying what the software shall do in terms of tasks and services

Note 1 to entry: Functional User Requirements include, but are not limited to, the following:
  • data transfer (for example: Input customer data, Send control signal);
  • data transformation (for example: Calculate bank interest, Derive average temperature);
  • data storage (for example: Store customer order, Record ambient temperature over time);
  • data retrieval (for example: List current employees, Retrieve aircraft position).

User requirements that are not Functional User Requirements include, but are not limited to, the following:
  • quality constraints (for example: usability, reliability, efficiency and portability);
  • organizational constraints (for example: locations for operation, target hardware and compliance to standards);
  • environmental constraints (for example: interoperability, security, privacy and safety);
  • implementation constraints (for example: development language, delivery schedule).

Note 2 to entry: Adapted from ISO/IEC 14143-1:2007, 3.8.

3.35

Function Point

FP

unit of measure for functional size as defined within this International Standard

3.36

Function Point Analysis

FPA

method for measuring functional size as defined within this International Standard

3.37

function point count

activity of applying the rules within this International Standard to measure the functional size of an application or project

Note 1 to entry: There are three types of function point count: application, development project and enhancement project.

3.38

function type

type of base functional component identified in this International Standard

Note 1 to entry: The five function types identified in this International Standard are: External Input, External Output, External Inquiry, Internal Logical File and External Interface File.

3.39

Internal Logical File

ILF

user recognizable group of logically related data or control information maintained within the boundary of the application being measured

Note 1 to entry: An Internal Logical File is a type of base functional component.

3.40

maintain

add, change or delete data through an elementary process

3.41

meaningful

user recognizable and satisfies a Functional User Requirement

3.42

perfective maintenance

modification of a software product after delivery to detect and correct latent faults in the software product before they are manifested as failures

Note 1 to entry: Adapted from ISO/IEC 14764:2006, 3.7.

Note 2 to entry: Perfective maintenance provides enhancements for users, improvement of program documentation, and recoding to improve software performance, maintainability, or other software attributes.

Note 3 to entry: Contrast with: adaptive maintenance; corrective maintenance.

3.43

primary intent

intent that is first in importance

3.44

processing logic

any of the requirements specifically requested by the user to complete an elementary process such as validations, algorithms or calculations and reading or maintaining a data function

3.45

purpose of the count

reason for performing the function point count

3.46

Record Element Type

RET

user recognizable sub-group of data element types within a data function

3.47

self-contained

no prior or subsequent processing steps are needed to initiate or complete the Functional User Requirement(s)

EXAMPLE:

The Functional User Requirement states that an employee is to be both added and updated. There might be multiple parts that make up the complete employee information. This can be represented by separate physical screens, windows or tabs such as
  • Employee identification,
  • Employee location,
  • Dependent information,
  • Salary information, and
  • Education.

To add an employee, one or more of the tabs must be completed, depending on the business rules. The add process is not self-contained until all mandatory information has been entered.
To update an employee, one or more of the tabs can be updated at any given time, but they are all process steps that meet the Functional User Requirement of updating an employee. Adding, changing or deleting information on any individual tab is not a separate elementary process. It is a process step involved in updating an employee. Even though additional information can be entered into the employee record, all of the information together is considered to be a part of the single elementary process: Update Employee.
Add Employee and Update Employee would each be a self-contained process.

3.48

sorting

activity of sequencing of rows or records in a transactional function

3.49

transactional function

elementary process that provides functionality to the user to process data

Note 1 to entry: A transactional function is an External Input, External Output or External Inquiry.

3.50

user

person or thing that communicates or interacts with the software at any time

Note 1 to entry: “Things” include, but are not limited to, software applications, animals, sensors and other hardware.

[SOURCE:ISO/IEC 14143-1:2007, 3.11]

3.51

user recognizable

requirements for processes and/or data that are agreed upon and understood by both the user(s) and software developer(s)

3.52

user view

Functional User Requirements as perceived by the user

Note 1 to entry: Developers translate the user view into software in order to provide a solution.

Bibliography

1ISO/IEC 14764:2006, Software Engineering — Software Life Cycle Processes — Maintenance