ISO/IEC/IEEE 32430:2025 ソフトウェアエンジニアリング — ソフトウェア非機能サイズの測定 | ページ 6

3.1.1

アルゴリズム

問題の 解決策 (3.1.41) のための、明確に定義されたルールの有限順序セット

[出典:ISO/IEC 2382:2015, 2121376, 修正済み — 記入事項の注記は削除されました。]

3.1.2

応用

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

[出典:ISO/IEC 20926:2009, 3.2]

3.1.3

境界

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

注記 1:この文書では、「アプリケーション境界」を使用します。

[出典: ISO/IEC 14143-1:2007, 3.3, 修正 — エントリに注 1 が追加されました。]

3.1.4

コードデータ

リストデータ

翻訳データ

置換可能なデータ。説明的な属性が持つ可能性のある有効な値のリストを提供します。

3.1.5

data configuration

process of adding, changing or deleting reference data or code data (3.1.4) information from the database or data storage with no change in software code or the database structure

3.1.6

data element type

DET

unique, user (3.1.42) -recognizable, non-repeated attribute

Note 1 to entry: A DET can be in business data, reference data, or code data (3.1.4) . The number of different types of data elements of all tables is the number of DETs (3.1.27) . Instances of control information are also counted as a DET, such as the “Enter” key to facilitate an external input (EI) (3.1.12) .

[SOURCE:ISO/IEC 20926:2009, 3.15, modified — Note 1 to entry has been added.]

3.1.7

data function

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

Note 1 to entry: A data function is either an internal logical file (3.1.21) or an external interface file (3.1.14) .

[SOURCE:ISO/IEC 20926:2009, 3.16]

3.1.8

database view

result set of a stored query on the data, which the database users (3.1.42) can query just as they would in a persistent database collection object

Note 1 to entry: This stored (pre-established query) command is kept in the database dictionary. Unlike ordinary base tables in a relational database, it is a virtual table computed or collated dynamically from data in the database, when access to that view is requested. Changes applied to the data in a relevant underlying table are reflected in the data shown in subsequent invocations of the view.

3.1.9

elementary process

EP

smallest unit of activity that is meaningful to the user (3.1.42)

[SOURCE:ISO/IEC 20926:2009, 3.21, modified — The abbreviated term"EP" has been added.]

3.1.10

extensive mathematical operation

mathematical operation that includes one or more series of mathematical equations and calculations executed in conjunction with, or according to, logical operators, to produce results identifiable to the user (3.1.42)

Note 1 to entry: See also: algorithm (3.1.1) .

3.1.11

extensive logical operation

logical operation either containing a minimum of four nesting levels, containing more than 38 DETs (3.1.6) required to operate the logical operation, or both

Note 1 to entry: These DETs do not necessarily have to cross the application (3.1.2) boundary (3.1.3) .

3.1.12

external input

EI

elementary process (EP) (3.1.9) that processes data or control information sent from outside the boundary (3.1.3)

[SOURCE:ISO/IEC 20926:2009, 3.27, modified — Note 1 to entry has been removed.]

3.1.13

external inquiry

EQ

elementary process (EP) (3.1.9) that sends data or control information outside the boundary (3.1.3)

[SOURCE:ISO/IEC 20926:2009, 3.28, modified — Note 1 to entry has been removed.]

3.1.14

external interface file

EIF

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

[SOURCE:ISO/IEC 20926:2009, 3.29, modified — Note 1 to entry has been removed.]

3.1.15

external output

eo

elementary process (EP) (3.1.9) that sends data or control information outside the boundary (3.1.3) and includes additional processing logic beyond that of an external inquiry (3.1.13)

[SOURCE:ISO/IEC 20926:2009, 3.30, modified — Note 1 to entry has been removed.]

3.1.16

family of platforms

software platforms (3.1.29) that are serving the same purpose

3.1.17

file type referenced

FTR

data function (3.1.7) read or maintained by a transactional function

Note 1 to entry: A file type referenced includes an internal logical file (3.1.21) read or maintained by a transactional function, or an external interface file (3.1.14) read by a transactional function.

[SOURCE:ISO/IEC 20926:2009, 3.31, modified — Note 1 to entry has been added.]

3.1.18

function point

FP

unit of measure for functional size

[SOURCE:ISO/IEC 20926:2009, 3.35]

3.1.19

functional size measurement

FSM

process of measuring the functional size

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

3.1.20

functional user requirement

FUR

sub-set of the user (3.1.42) requirement that describes what the software does, in terms of tasks and services

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

3.1.21

internal logical file

ILF

user (3.1.42) -recognizable group of logically related data or control information maintained within the boundary (3.1.3) of the application (3.1.2) being measured

[SOURCE:ISO/IEC 20926:2009, 3.39, modified — Note 1 to entry has been removed.]

3.1.22

logical file

logical group of data as seen by the users (3.1.42)

[SOURCE:ISO/IEC 24570:2018]

3.1.23

multiple instance approach

case where each method of delivery of the same functionality is counted separately

Note 1 to entry: See also: single instance approach (3.1.33) .

3.1.24

non-functional size

size of the software derived by quantifying the non-functional requirements (3.1.25) for the software, defined by a set of rules

3.1.25

non-functional requirement

NFR

requirement for a software-intensive system (3.1.40) or for a software product (3.1.38) , including how it should be developed and maintained, and how it should perform in operation, except any functional user requirement (3.1.20) for the software

3.1.26

NFR for software

non-functional requirements for software

portion of the non-functional requirements (NFR) (3.1.25) that are realized by the software

3.1.27

number of DETs

sum of all data element types (DETs) (3.1.6) that are part of the input/output/query of the elementary process (EP) (3.1.9) , plus the data elements which are read or maintained internally to the boundary (3.1.3)

3.1.28

partition

set of software functions within an application (3.1.2) boundary (3.1.3) that share common criteria and values

Note 1 to entry: Setting partitions is not based on technical or physical considerations.

Note 2 to entry: Partitions do not overlap.

3.1.29

platform

type of computer or hardware device or associated operating system, or a virtual environment, on which software can be installed or run

Note 1 to entry: Combination of an operating system and hardware that makes up the operating environment in which a program runs. A platform is distinct from the unique instances of that platform, which are typically referred to as devices or instances.

3.1.30

precautionary principle

principle that the introduction of a new product or process whose ultimate effects are unknown or disputed should be resisted until such risks are appropriately mitigated

Note 1 to entry: The precautionary principle denotes a duty to prevent harm, when it is within our power to do so, even when all the evidence is not in. This principle has been codified in several international treaties and in international law.

3.1.31

primary intent

intent that is first in importance

3.1.32

record element type

RET

user (3.1.42) recognizable sub-group of data element types (DETs) (3.1.6) within a data function (3.1.7)

[SOURCE:ISO/IEC 20926:2009, 3.46]

3.1.33

single instance approach

case where all methods of delivery of the same functionality are counted as one

Note 1 to entry: See also multiple instance approach (3.1.23) .

3.1.34

SNAP category

software non-functional assessment process category

group of components, processes or activities that are used in order to measure the non-functional size (3.1.24) of the software

Note 1 to entry: Categories classify the method and are generic enough to allow for future technologies. Categories are divided into sub-categories, so that the SNAP category groups the sub-categories based on similar operations or similar types of sizing activities.

3.1.35

SNAP counting unit

SCU

software non-functional assessment process counting unit

component, process or activity, in which non-functional size (3.1.24) is measured

Note 1 to entry: The SCU is identified according to the nature of each sub-category. It can contain both functional and non-functional characteristics; therefore, sizing an SCU is performed for its functional sizing, using function point (3.1.18) analysis (FPA), and for its non-functional sizing, using SNAP.

3.1.36

SNAP point

SP

software non-functional assessment process point

unit of measurement to express the non-functional size (3.1.24) of the software

3.1.37

SNAP sub-category

software non-functional assessment process sub-category

component, process or activity performed within the project, to meet a non-functional requirement (3.1.25)

Note 1 to entry: A non-functional requirement may be sized using more than one sub-category.

3.1.38

software product

set of computer programs, procedures, and possibly associated documentation and data

Note 1 to entry: A software product is a software system viewed as the output (product) resulting from a process.

[SOURCE:ISO/IEC/IEEE 12207:2017, 3.1.54]

3.1.39

software project

set of work activities, both technical and managerial, required to satisfy the terms and conditions of a project agreement

Note 1 to entry: A software project has specific starting and ending dates, well-defined objectives and constraints, established responsibilities, a budget and a schedule. A software project may be self-contained or may be part of a larger project. In some cases, a software project may span only a portion of the software development cycle. In other cases, a software project may span many years and consist of numerous subprojects, each being a well-defined and self-contained software project.

3.1.40

software-intensive system

system for which software is a major technical challenge and is perhaps the major factor that affects system schedule, cost and risk

Note 1 to entry: In the most general case, a software-intensive system is comprised of hardware, software, people and manual procedures.

[SOURCE:IEEE 1062-2015, 3.1]

3.1.41

solution

combination of people, processes and technologies to implement a desired capability

[SOURCE:IEEE 7005-2021, 3.1]

3.1.42

user

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

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