ISO/IEC TR 7052:2023 ソフトウェア エンジニアリング — カスタム ソフトウェアの開発および保守中に頻繁に発生するリスクを制御します。 | ページ 6

3.1

受け入れテスト駆動開発

ATDD

関連する機能の開発にwhere さまざまな背景を持つチーム メンバー [ 開発者 (3.18) 、テスター、ビジネス アナリスト] が共同で受け入れテストを作成する開発方法

注記 1: 受け入れテスト駆動開発というメソッドの名前は、ATDD が テスト駆動開発 (3.46) (TDD) の特殊化であることを示唆していますが、そうではありません。むしろ、TDD は最初に 単体テスト (3.48) を作成して開発を推進することに重点を置き、ATDD は最初に受け入れテストを作成して開発を推進することに重点を置いています。

[出典:NEN NPR 5326:2019, 3.1, 修正 - エントリに注 1 を追加。]

3.2

取得者

サプライヤーから製品またはサービスを取得または調達する利害関係者 (3.44)

注記 1:買収者に対して一般的に使用されるその他の用語は、買い手、顧客、所有者、購入者、または内部/組織スポンサーです。

[出典:ISO/IEC/IEEE 12207:2017, 3.1.1]

3.3

アジャイル開発

反復的な開発、頻繁な検査と適応、および部門を超えたチームでのコラボレーションと継続的な関係者のフィードバックを通じて要件とソリューションが進化する段階的な納品に基づく開発アプローチ

注記 1:この文書で「アジャイル」という言葉を使用する場合は、方法論を指します。

[出典:ISO/IEC/IEEE 26515:2018, 3.1, 修正 — エントリの注 1 で、ISO/IEC/IEEE 26515:2018, 付録 A への参照を削除。]

3.4

やり残し

アジャイル機能のコレクション、または機能要件と非機能要件の両方のストーリー。通常は価値の優先順位に基づいて並べ替えられます。

注記 1:これは、優先順位を付けて完了する、現在の作業の一部ではない製品要件および 成果物 (3.13) のリストとして使用できます。

[出典:ISO/IEC/IEEE 26515:2018, 3.4, 修正 — エントリの注 1 を削除。]

3.5

行動主導型開発

BDD

関連する機能の開発に先立っwhere さまざまな背景を持つチーム メンバー [ 開発者 (3.18) 、テスター、ビジネス アナリスト] が共同で目的の機能の動作を説明する開発方法。

[出典:NEN NPR 5326:2019, 3.5]

3.6

全焼

[出典:ISO/IEC/IEEE 24765:2017, 3.437, 修正 - 定義と項目への注記 1 に再構成。]

3.7

バーンダウンチャート

プロジェクトでやるべき残りの作業を表すグラフ

注記 1:バーンダウン チャートの例については、図 1 を参照してください。

図 1 —横軸に時間を、縦軸に残作業量をとったバーンダウン チャートの例

Key

1	実線は実際の残り作業量を表します
2	作品の理想的なバーンダウンを表す点描線

注記 2: これは、完了した作業量とまだ行われていない作業量を示すグラフとして使用できます。

注記 3: これは、リリースまたはイテレーションごとだけでなく、 スプリント (3.42) ごとにも提示できます。

注記 4:たとえば、ユーザー ストーリーポイント (3.51) or ファンクションポイント (3.25) を使用して量を測定できます。

[出典:ISO/IEC/IEEE 26511:2018, 3.1.6, 修正 - サンプルの図とメモをエントリに追加しました。]

3.8

ビジネスへの影響分析

混乱が組織に及ぼす影響を時間の経過とともに分析するプロセス

注記 1: 結果は、事業継続要件の表明および正当化です。

[出典:ISO 22300:2021, 3.1.24]

3.9

コードレビュー

1 人以上の 開発者 (3.18) が ソース コード (3.41) (の一部) を通過することによって、その 品質 (3.35) を確立するwhere

注記 1: コードレビューを実施するには、形式的なものから非常に非公式なものまで、また個別的なものから継続的なものまで、さまざまな方法があります。

[出典:NEN NPR 5326:2019, 3.10, 修正 — 定義を修正し、エントリに注 1 を追加。]

3.10

構成管理データベース

CMDB

使用中のハードウェアとソフトウェアに関する情報を保存するために組織によって使用されるデータベース

[出典:NEN NPR 5326:2019 3.11]

3.11

結果

目標 (3.30) に影響を及ぼす イベント (3.23 ) の結果

注記 1:イベントはさまざまな結果を引き起こす可能性があります。

注記 2:結果は確実である場合もあれば不確実である場合もあり、目的に対してプラスまたはマイナスの影響を与える場合があります。

注記 3:結果は定性的または定量的に表現できます。

注記 4: 初期の影響は、波及効果を通じて拡大する可能性があります。

[出典:ISO Guide 73:2009, 3.6.1.3]

3.12

コントロール

リスクを修正する措置 (3.37)

注記 1: コントロールには、リスクを修正するプロセス、ポリシー、デバイス、実践、またはその他のアクションが含まれます。

注記 2:コントロールは、意図された、または想定された変更効果を常に発揮できるとは限りません。

[出典: ISO Guide 73:2009, 3.8.1.1, 修正 - エントリの注 2 で、「できない」を「できない」に変更。

3.13

カスタムソフトウェア

ユーザー要件仕様に基づいて特定のアプリケーション向けに開発されたソフトウェア製品

[出典:ISO/IEC 25000:2014, 4.3]

3.14

データ保護の影響評価

DPIA

データ処理のプライバシー リスクを事前に評価し、 リスク (3.37) を軽減するための 制御 (3.12) を実装できるようにする 、一般データ保護規則 (3.27) (GDPR) に記載されているツール

注記 1: https://gdpr.eu/article-35-impact-assessment/ を参照。

[出典:NEN NPR 5326:2019 3.12, 修正 — 「措置を講じる」を「管理を実施する」に変更。 GDPR 第 35 条へのリンクを含むエントリに注 1 を追加しました。]

3.15

成果物

プロセス、フェーズ、またはプロジェクトを完了するために作成する必要がある、ユニークで検証可能な製品、結果、またはサービスを実行する機能

[出典:ISO/IEC/IEEE 24765:2017, 3.1098, 定義 1]

3.16

デルフィ法

ある主題について専門家の合意に達する方法として使用される情報収集手法

注記 1: Delphi メソッドは、この文書の指標/サブ指標の重みを決定するためのコンセンサスツールとして適用されます。

注記 2: ファシリテーターは、アンケートを使用して、主題に関連するプロジェクトの重要な点についてアイデアを募ります。回答は要約され、さらなるコメントを求めて専門家に再回覧されます。このプロセスを数回行うことで合意に達することができます。

[出典:ISO/IEC/IEEE 24765:2017, 3.1102, 修正済み - 定義と入力メモに再構成。]

3.17

デザイン思考

人間のニーズwhere 定義される（非常に複雑な）問題を解決するための方法論

注記 1: デザイン思考では、ソリューションはブレーンストーミング セッションで決定されここで, プロトタイプ (3.34) は、 意図したソリューションを実際にテストするために作成されます。

[出典:NEN NPR 5326:2019, 3.15]

3.18

開発者

システムまたはソフトウェアのライフサイクル プロセス中に開発活動 (要件分析、設計、テストから受け入れまでを含む) を実行する個人または組織

注記 1: カスタムソフトウェア (3.13) の開発者の活動には、機能的および非機能的なシステムおよびソフトウェア要件のセットアップと分析、設計、プログラミング、およびテストが含まれます。

注記 2: したがって、設計者、プログラマー、およびテスターはすべて開発者です。

[出典:ISO/IEC 25000:2014, 4.修正 — エントリにメモを追加しました。]

3.19

開発パイプライン

パイプラインを構築する

アプリケーションを使用できるパッケージの管理および制御されたビルドを目的としたツールのセット

注記 1:これらの一環として、 品質を決定し評価するためにさまざまなテストが実行されます (3.35) 。

[出典:NEN NPR 5326:2019, 3.30]

3.20

開発チーム

ソフトウェアを開発および/または保守するチーム

注記 1: 取得者 (3.2) 、 製品所有者 (3.33) 、および将来の保守者は、開発チームの一部を構成できます。

注記 2:開発チームは、機能ごとに分類することも (例: デザイナーのチーム、プログラマーのチーム、テスターのチーム)、多分野に分けることもできます (各チームは、例: 設計、プログラミング、テストの専門知識を持っています)

[出典:NEN NPR 5326:2019, 3.31]

3.21

DevOps

ソフトウェアおよびシステムの製品およびサービスの仕様、開発、運用、およびライフサイクルのあらゆる側面における継続的な改善を目的として、関連する利害関係者間のより良いコミュニケーションとコラボレーションを可能にする一連の原則と実践。

[出典:IEEE 2675-2021 3.1]

3.22

分散型サービス拒否攻撃

DDoS攻撃

システム リソースへの不正アクセス、または複数のシステムを侵害して対象システムの帯域幅やリソースをあふれさせ、その結果、許可されたユーザーの可用性が失われることによるシステムの操作や機能の遅延。

[出典:ISO/IEC 27039:2015, 3.7]

3.23

イベント

特定の一連の状況の発生または変化

注記 1:イベントは 1 つまたは複数の発生であり、複数の原因が考えられます。

注記 2:イベントは、何かが起こっていないことで構成される場合があります。

注記 3: 出来事は、 「事件」または「事故」と呼ばれることもあります。

注記 4: 結果を伴わない出来事 (3.11) は、「ニアミス」、「事故」、「ニアヒット」、または「危機一髪」とも呼ばれる。

[出典:ISO Guide 73:2009, 3.5.1.3]

3.24

エクストリームプログラミング

XP

アジャイル ソフトウェア開発の形式where 反復的な計画と作業の手順が、テスト駆動設計やペア プログラミングなどの技術的手順と組み合わされます。

[出典:NEN NPR 5326:2019, 3.20]

3.25

ファンクションポイント

FP

機能的なサイズの測定単位

[出典: ISO/IEC 20926:2009, 3.35, 修正 - 「この国際規格内での定義に従って」削除。]

3.26

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

FPA

機能的サイズの測定方法

[出典:ISO/IEC 20926:2009, 3.36, 修正 - 「この国際規格内での定義に従って」削除。]

3.27

一般データ保護規則

GDPR

欧州連合全体の民間企業および政府機関による個人データの処理ルールを標準化する欧州規制

注記 1: https://gdpr.eu を参照してください。

[出典:NEN NPR 5326:2019, 3.3]

3.28

統合テスト

ソフトウェア コンポーネント、ハードウェア コンポーネント、またはその両方を組み合わせてテストし、それらの間の相互作用を評価するテスト

[出典:ISO/IEC/IEEE 24765:2017, 3.2034, 修正 — エントリの注 1 を削除。]

3.29

最低限の実用的な製品

MVP

初期の顧客を満足させたり、将来の開発のためのフィードバックを提供したりするのに十分な機能と要件を備えた作業成果物のバージョン

[出典:IEEE 2675-2021, 3.1]

3.30

客観的

達成される予定の結果

注記 1: 目的を達成するには、通常、いくつかのツールと活動が必要であり、そのうちの 1 つは カスタム ソフトウェア (3.13) である場合があります。

[出典:NEN NPR 5326:2019, 3.18]

3.31

性能テスト

時間やその他のリソースの与えられた制約内で、テスト項目がその指定された機能をどの程度達成するかを評価するために実施されるテストの種類

グレード 1 から入門まで:多くの場合、負荷、ストレス、耐久性のテストが区別されます。負荷テストではシステムの通常の負荷をシミュレートし、ストレス テストでは負荷を増加させて、システムが機能し続ける最大負荷を決定します。耐久性テストでは、しばらくしてから顕在化するメモリ リークやその他の問題を検出するために、システムに長時間負荷をかけます。

[出典:ISO/IEC/IEEE 29119-1:2022, 3.58, 修正 — 用語を「パフォーマンス テスト」から「パフォーマンス テスト」に変更。 「テストの種類」を「テストの種類」に変更しました。エントリに注記 1 を追加しました。]

3.32

製品の内訳構造

PBS

製品をそのコンポーネントに分解する

注記 1: PBS は、階層の最上位にある完全な製品から始まり、その下に主要なコンポーネントがあり、それぞれをコンポーネントなどに再度分割することもできます。

[出典:ISO 21511:2018, 3.7, 修正 - 省略された用語と注 1 をエントリに追加。]

3.33

プロダクトオーナー

製品の機能、受け入れ、使用に責任を負う利害関係者

注記 1:製品所有者は、製品のビジョン、必要な機能とその優先順位、および受け入れ基準を共有します。

[出典:ISO/IEC TR 24587:2021, 3.12]

3.34

プロトタイプ

システム設計、パフォーマンス、および生産可能性の評価、または要件のより深い理解または決定に適したモデルまたは予備実装

[出典:ISO/IEC 2382:2015, 2122670, 修正 - エントリのメモを削除。]

3.35

品質

製品、サービス、システム、コンポーネント、またはプロセスが顧客またはユーザーのニーズ、期待、または要件を満たす能力

[出典:ISO/IEC/IEEE 24765:2017, 3.3259, 定義 2, 修正 - エントリに注 1 を追加。]

3.36

回帰テスト

回帰障害が発生するかどうかを特定するために、テスト項目またはその運用環境を変更した後に使用されるテスト タイプ

[出典:ISO/IEC/IEEE 29119-1:2022, 3.64, 修正 - 用語を「回帰テスト」から「回帰テスト」に変更。 「実行されたテスト」を「使用されたテストの種類」に変更しました。 「テスト項目の未変更部分での失敗」を「回帰失敗」に変更: エントリのメモを削除しました。]

3.37

危険

目標に対する不確実性の影響 (3.30)

[出典: ISO Guide 73:2009, 1.1, 修正 — エントリへの注記を削除]

3.38

リスク対応

リスクを修正するプロセス (3.37)

注記 2:マイナスの結果に対処するリスク処理は、「リスク軽減」、「リスク除去」、「リスク予防」、または「リスク軽減」と呼ばれることもあります。

注記 3: リスク処理により、新しいリスクが生み出されたり、既存のリスクが修正されたりする可能性があります。

[出典:ISO Guide 73:2009, 3.8.1]

3.39

スクラム

アジャイル開発 (3.3) で使用される反復的なプロジェクト管理フレームワーク。チームは要件 バックログ (3.4) から開発項目に同意し、数週間の短期間でそれらを作成します。

3.40

セキュリティテスト

テスト項目および関連するデータと情報が、権限のない人やシステムが使用、読み取り、変更できないように、また権限のある人やシステムがそれらへのアクセスを拒否されないように保護されている程度を評価するために実施されるテストの種類。

注記 1:セキュリティー・テスターがテストを実行するときに持つ、テスト対象のシステムに関する情報の量に応じて、ブラック・ボックス (最小限の情報)、グレー・ボックス (通常のユーザーと同じ知識とアクセス) という用語が使用されます。またはホワイトボックスセキュリティテスト[システム全体、ドキュメント、 ソースコードへのアクセス(3.41) ]が使用されます。

[出典:ISO/IEC/IEEE 29119-1:2022, 3.74, 修正 - 用語を「セキュリティ テスト」から「セキュリティ テスト」に変更。エントリに注記 1 を追加しました。]

3.41

ソースコード

アセンブラ、コンパイラ、その他のトランスレータへの入力に適した形式で表現されたコンピュータ命令とデータ定義

[出典:ISO/IEC/IEEE 24765:2017, 3.3882, 修正 — エントリの注 1 を削除。]

3.42

スプリント

「完了」し、使用可能でリリース可能な可能性のある製品増分が作成されるまでの 1 か月以内のタイムボックス

[出典:NEN NPR 5326:2019, 3.44]

3.43

ストーリーマッピング

バックログ (の一部) の 2 次元表現 (3.4) を作成します。これは、ユーザーがバックログ内のストーリーを論理的に分割、グループ化、配置するための視覚的な補助となり、すべての ユーザー ストーリー 間の関係の概要を示します。 (3.50)

[出典:NEN NPR 5326:2019, 3.45, 修正 — 用語を「ストーリー マップ」から「ストーリー マッピング」に変更しました。

3.44

サプライヤー

製品またはサービスの供給に関して 取得者と契約を結ぶ組織または個人 (3.2)

注記 1:サプライヤーに対して一般的に使用されるその他の用語としては、請負業者、生産者、販売者、ベンダーなどがあります。

注記 2:取得者と供給者は同じ組織の一部である場合があります。

[出典:ISO/IEC/IEEE 12207:2017, 3.1.60]

3.45

技術的負債

製品ライフサイクルの初期の時点で実行されなかった作業の繰延コスト

[出典:ISO/IEC/IEEE 24765:2017, 3.4181, 修正 — エントリと例に注 1 を追加。]

3.46

テスト駆動開発

TDD

関連する機能を実装する前where 開発者 (3.18) が 単体テスト (3.48) を作成する開発方法

[出典:NEN NPR 5326:2019, 3.47]

3.47

Tシャツのサイズ

ユーザー ストーリー (3.50) を比較し、これらを特小、小、中、大、特大のカテゴリに分類することによって相対的な見積もりを行う方法

注記 1: T シャツのサイジングは、誤った精度に時間を浪費することなく、相互関係を明確にします。

[出典:NEN NPR 5326:2019, 3.48]

3.48

単体テスト

開発者 (3.18) または独立したテスターに​​よる個々のルーチンとモジュールのテスト

[出典:ISO/IEC/IEEE 24765:2017, 3.4429 定義 1]

3.49

使用事例

システムの動作要件とユーザーとの対話の説明

注記 1:ユースケースは、ユーザーの目標と、ユーザーとシステムの間の一連の対話を含む要件を記述します。

[出典:ISO/IEC/IEEE 26515:2018, 3.15]

3.50

ユーザーストーリー

ユーザーがシステムの一部を使用して何を達成しようとしているのかについての短い説明

注記 1:ユーザーストーリーは通常、 取得者 (3.2) /ユーザーの通常の話し言葉の数文で構成され、ユーザーが特定の 目的 (3.30) を達成するために何をするか、またはできるようになるかを述べます。さらに、ユーザー ストーリーでは、作成された機能が完全であるとみなすためにどのような承認基準が使用されるかについて説明します。

注記 2:ユーザー・ストーリーで一般的に使用される形式は、「<役割> として、<アクティビティ> ができるため、<目的> が可能」です。例: 「従業員として、私は経費を指定して、雇用主からこれらを払い戻してもらうことができます。」

3.51

ユーザーストーリーポイント

ユーザー ストーリー (3.50) の範囲の相対的な尺度。 アジャイル開発 (3.3) 手法でよく使用されます。

[出典:NEN NPR 5326:2019, 3.52]

3.1

acceptance test-driven development

ATDD

development method where team members with various backgrounds [ developers (3.18) , testers and business analysts] jointly write the acceptance tests prior to development of the relevant functionality

Note 1 to entry: Although the name of the method, acceptance test-driven development, suggests that ATDD is a specialization of test-driven development (3.46) (TDD), this is not the case. Rather, TDD focuses on driving development by writing unit tests (3.48) first and ATDD focuses on driving development by writing acceptance tests first.

[SOURCE:NEN NPR 5326:2019, 3.1, modified —Added note 1 to entry.]

3.2

acquirer

stakeholder that acquires or procures a product or service from a supplier (3.44)

Note 1 to entry: Other terms commonly used for an acquirer are buyer, customer, owner, purchaser or internal/organizational sponsor.

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

3.3

agile development

development approach based on iterative development, frequent inspection and adaptation, and incremental deliveries in which requirements and solutions evolve through collaboration in cross-functional teams and through continuous stakeholder feedback

Note 1 to entry: Any use of the word “agile” in this document refers to methodology.

[SOURCE:ISO/IEC/IEEE 26515:2018, 3.1, modified — In note 1 to entry, removed the reference to ISO/IEC/IEEE 26515:2018, Annex A.]

3.4

backlog

collection of agile features or stories of both functional and non-functional requirements that are typically sorted in an order based on value priority

Note 1 to entry: This can be used as a list of product requirements and deliverables (3.13) not part of current work, to be prioritized and completed.

[SOURCE:ISO/IEC/IEEE 26515:2018, 3.4, modified — Removed note 1 to entry.]

3.5

behaviour-driven development

BDD

development method where team members with various backgrounds [ developers (3.18) , testers and business analysts] jointly describe the behaviour of the intended functionality prior to development of the relevant functionality

[SOURCE:NEN NPR 5326:2019, 3.5]

3.6

burndown

[SOURCE:ISO/IEC/IEEE 24765:2017, 3.437, modified — Restructured into definition and note 1 to entry.]

3.7

burndown chart

graph that represents the work remaining to do on a project

Note 1 to entry: See Figure 1 for an example of a burndown chart.

Figure 1 — Example of a burndown chart with time on the horizontal axis and work-remaining on the vertical axis

Key

1	solid line, representing the actual work-remaining
2	stippled line, representing the ideal burndown of the work

Note 2 to entry: This can be used as a chart to show the amount of the work done versus the amount of the work still to do.

Note 3 to entry: This can be presented per sprint (3.42) , as well as per release or iteration.

Note 4 to entry: For example, user story points (3.51) or function points (3.25) can be used to measure the amount.

[SOURCE:ISO/IEC/IEEE 26511:2018, 3.1.6, modified — Added the example figure and notes to entry.]

3.8

business impact analysis

process of analysing the impact over time of a disruption on the organization

Note 1 to entry: The outcome is a statement and justification of business continuity requirements.

[SOURCE:ISO 22300:2021, 3.1.24]

3.9

code review

activity where one or more developers (3.18) establish the quality (3.35) of (part of) the source code (3.41) by going through it

Note 1 to entry: There are a variety of ways to conduct code reviews which range from formal to very informal and from discrete to continuous.

[SOURCE:NEN NPR 5326:2019, 3.10, modified — Modified definition and added note 1 to entry.]

3.10

configuration management database

CMDB

database that is used by an organization to store information about the hardware and software in use

[SOURCE:NEN NPR 5326:2019 3.11]

3.11

consequence

outcome of an event (3.23) affecting objectives (3.30)

Note 1 to entry: An event can lead to a range of consequences.

Note 2 to entry: A consequence can be certain or uncertain and can have positive or negative effects on objectives.

Note 3 to entry: Consequences can be expressed qualitatively or quantitatively.

Note 4 to entry: Initial consequences can escalate through knock-on effects.

[SOURCE:ISO Guide 73:2009, 3.6.1.3]

3.12

control

measure that is modifying risk (3.37)

Note 1 to entry: Controls include any process, policy, device, practice, or other actions which modify risk.

Note 2 to entry: Controls cannot always exert the intended or assumed modifying effect.

[SOURCE:ISO Guide 73:2009, 3.8.1.1, modified — In note 2 to entry, changed “may not” to “cannot”.]

3.13

custom software

software product developed for a specific application from a user requirements specification

[SOURCE:ISO/IEC 25000:2014, 4.3]

3.14

data protection impact assessment

DPIA

tool described in the General Data Protection Regulation (3.27) (GDPR) to assess in advance the privacy risks of data processing and then to be able to implement controls (3.12) to reduce the risks (3.37)

Note 1 to entry: See https://gdpr.eu/article-35-impact-assessment/ .

[SOURCE:NEN NPR 5326:2019 3.12, modified — Changed “take measures” to “implement controls”. Added note 1 to entry with link to the GDPR Article 35.]

3.15

deliverable

any unique and verifiable product, result, or capability to perform a service that must be produced to complete a process, phase, or project

[SOURCE:ISO/IEC/IEEE 24765:2017, 3.1098, definition 1]

3.16

Delphi method

information-gathering technique used as a way to reach consensus of experts on a subject

Note 1 to entry: The Delphi method is applied as consensus tool for determining weights of indicators/sub-indicators in this document.

Note 2 to entry: A facilitator uses a questionnaire to solicit ideas about the important project points related to the subject. The responses are summarized and are then recirculated to the experts for further comment. Consensus can be reached in a few rounds of this process.

[SOURCE:ISO/IEC/IEEE 24765:2017, 3.1102, modified — Restructured into definition and notes to entry.]

3.17

design thinking

methodology for solving (very complex) problems where these are defined from the human needs

Note 1 to entry: In design thinking solutions are determined with brainstorming sessions ここで, prototypes (3.34) are produced to test the intended solution in practice.

[SOURCE:NEN NPR 5326:2019, 3.15]

3.18

developer

individual or organization that performs development activities (including requirements analysis, design, testing through acceptance) during the system or software life-cycle process

Note 1 to entry: Activities of the developer of custom software (3.13) include setup and analysis of functional and non-functional system and software requirements, design, programming and testing.

Note 2 to entry: Designers, programmers and testers are therefore all developers.

[SOURCE:ISO/IEC 25000:2014, 4.6. modified — Added notes to entry.]

3.19

development pipeline

build pipeline

set of tools aimed at the managed and controlled build of a package with which an application can be taken into use

Note 1 to entry: As part of this various tests are carried out to determine and assess quality (3.35) .

[SOURCE:NEN NPR 5326:2019, 3.30]

3.20

development team

team that develops and/or maintains software

Note 1 to entry: The acquirer (3.2) , product owner (3.33) and future maintainer can form part of the development team.

Note 2 to entry: Development teams can be broken down by function (e.g. a team of designers, a team of programmers, a team of testers) or be multidisciplinary (each team has e.g. design, programming and test expertise).

[SOURCE:NEN NPR 5326:2019, 3.31]

3.21

DevOps

set of principles and practices which enable better communication and collaboration between relevant stakeholders for the purpose of specifying, developing, and operating software and systems products and services, and continuous improvements in all aspects of the life cycle

[SOURCE:IEEE 2675-2021 3.1]

3.22

distributed denial of service attack

DDoS attack

unauthorized access to a system resource or the delaying of system operations and functions in the way of compromising multiple systems to flood the bandwidth or resources of the targeted system, with resultant loss of availability to authorized users

[SOURCE:ISO/IEC 27039:2015, 3.7]

3.23

event

occurrence or change of a particular set of circumstances

Note 1 to entry: An event can be one or more occurrences and can have several causes.

Note 2 to entry: An event can consist of something not happening.

Note 3 to entry: An event can sometimes be referred to as an ‘incident’ or ‘accident’.

Note 4 to entry: An event without consequences (3.11) can also be referred to as a ‘near miss’, ‘accident’, ‘near hit’ or ‘close call’.

[SOURCE:ISO Guide 73:2009, 3.5.1.3]

3.24

extreme programming

XP

form of agile software development where procedures for iterative planning and working are combined with technical procedures, such as test-driven design and pair programming

[SOURCE:NEN NPR 5326:2019, 3.20]

3.25

function point

FP

unit of measure for functional size

[SOURCE:ISO/IEC 20926:2009, 3.35, modified — removed “as defined within this International Standard”.]

3.26

function point analysis

FPA

method for measuring functional size

[SOURCE:ISO/IEC 20926:2009, 3.36, modified — removed “as defined within this International Standard”.]

3.27

General Data Protection Regulation

GDPR

European Regulation that standardizes the rules for processing personal data by private businesses and government bodies in the whole European Union

Note 1 to entry: See https://gdpr.eu .

[SOURCE:NEN NPR 5326:2019, 3.3]

3.28

integration testing

testing in which software components, hardware components, or both are combined and tested to evaluate the interaction between them

[SOURCE:ISO/IEC/IEEE 24765:2017, 3.2034, modified — Removed note 1 to entry.]

3.29

minimum viable product

MVP

version of a work product with just enough features and requirements to satisfy early customers and/or provide feedback for future development

[SOURCE:IEEE 2675-2021, 3.1]

3.30

objective

predetermined result to be achieved

Note 1 to entry: To achieve an objective several tools and activities are generally needed, one of which can be custom software (3.13) .

[SOURCE:NEN NPR 5326:2019, 3.18]

3.31

performance test

test type conducted to evaluate the degree to which a test item accomplishes its designated functions within given constraints of time and other resources

Note 1 to entry: A distinction is often made between load, stress and endurance tests. Load tests simulate a normal load on the system. Stress tests allow the load to increase to determine the maximum load at which the system still functions. Endurance tests load the system for a longer period in order to discover memory leaks or other problems which only manifest themselves after some time.

[SOURCE:ISO/IEC/IEEE 29119-1:2022, 3.58, modified — Changed the term from"performance testing" to"performance test"; changed"type of testing" to"test type"; added note 1 to entry.]

3.32

product breakdown structure

PBS

decomposition of the product into its components

Note 1 to entry: The PBS begins with the complete product at the top of the hierarchy and below this the main components, which can also each be broken down again into components, etc.

[SOURCE:ISO 21511:2018, 3.7, modified — Added the abbreviated term and note 1 to entry.]

3.33

product owner

stakeholder responsible for the capabilities, acceptance and use of a product

Note 1 to entry: The product owner shares the product vision, required features and their priorities, and acceptance criteria.

[SOURCE:ISO/IEC TR 24587:2021, 3.12]

3.34

prototype

model or preliminary implementation suitable for evaluation of system design, performance, and production potential, or for better understanding or determination of the requirements

[SOURCE:ISO/IEC 2382:2015, 2122670, modified — Removed notes to entry.]

3.35

quality

ability of a product, service, system, component, or process to meet customer or user needs, expectations, or requirements

[SOURCE:ISO/IEC/IEEE 24765:2017, 3.3259, definition 2, modified — Added note 1 to entry.]

3.36

regression test

test type used following modifications to a test item or to its operational environment, to identify whether regression failures occur

[SOURCE:ISO/IEC/IEEE 29119-1:2022, 3.64, modified — Changed to term from"regression testing" to"regression test"; changed"testing performed" to"test type used"; changed"failures in unmodified parts of the test item" to" regression failures": removed notes to entry.]

3.37

risk

effect of uncertainty on objectives (3.30)

[SOURCE:ISO Guide 73:2009, 1.1, modified — Notes to entry removed]

3.38

risk treatment

process to modify a risk (3.37)

Note 2 to entry: Risk treatment that deal with negative consequences is sometimes referred to as ‘risk mitigation’, ‘risk elimination’, ‘risk prevention’ or ‘risk reduction’.

Note 3 to entry: Risk treatment can create new risks or modify existing risks.

[SOURCE:ISO Guide 73:2009, 3.8.1]

3.39

Scrum

iterative project management framework used in agile development (3.3) , in which a team agrees on development items from a requirements backlog (3.4) and produces them within a short duration of a few weeks

3.40

security test

test type conducted to evaluate the degree to which a test item, and associated data and information, are protected so that unauthorized persons or systems cannot use, read, or modify them, and authorized persons or systems are not denied access to them

Note 1 to entry: Depending on the amount of information on the system to be tested that the security tester has when carrying out the test, the terms black box (minimum information), grey box (the same knowledge and access as an ordinary user) or white box security tests [access to the whole system, documentation and source code (3.41) ] are used.

[SOURCE:ISO/IEC/IEEE 29119-1:2022, 3.74, modified — Changed to term from"security testing" to"security test"; added note 1 to entry.]

3.41

source code

computer instructions and data definitions expressed in a form suitable for input to an assembler, compiler, or other translator

[SOURCE:ISO/IEC/IEEE 24765:2017, 3.3882, modified — Removed note 1 to entry.]

3.42

sprint

time box of one month or less during which a ‘done’, usable and potentially releasable product increment is created

[SOURCE:NEN NPR 5326:2019, 3.44]

3.43

story mapping

making of a two-dimensional representation of (part of the) backlog (3.4) that is a visual aid for the user to cut up, group and arrange stories logically in the backlog, which gives an overview of the relations between all the user stories (3.50)

[SOURCE:NEN NPR 5326:2019, 3.45, modified — Changed the term from"story map" to"story mapping".]

3.44

supplier

organization or an individual that enters into an agreement with the acquirer (3.2) for the supply of a product or service

Note 1 to entry: Other terms commonly used for supplier are contractor, producer, seller, or vendor.

Note 2 to entry: The acquirer and the supplier sometimes are part of the same organization.

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

3.45

technical debt

deferred cost of work not performed at an earlier point in the product life cycle

[SOURCE:ISO/IEC/IEEE 24765:2017, 3.4181, modified — Added note 1 to entry and EXAMPLE.]

3.46

test-driven development

TDD

development method where the developers (3.18) write unit tests (3.48) prior to implementing the relevant functionality

[SOURCE:NEN NPR 5326:2019, 3.47]

3.47

T-shirt sizing

method of making relative estimates by comparing user stories (3.50) and dividing these into the categories extra-small, small, medium, large and extra large

Note 1 to entry: T-shirt sizing clarifies the interrelationships without time being wasted on false precision.

[SOURCE:NEN NPR 5326:2019, 3.48]

3.48

unit test

testing of individual routines and modules by the developer (3.18) or an independent tester

[SOURCE:ISO/IEC/IEEE 24765:2017, 3.4429 definition 1]

3.49

use case

description of behavioural requirements of a system and its interaction with a user

Note 1 to entry: A use case describes the users' goal and the requirements including the sequence of interactions between users and the system.

[SOURCE:ISO/IEC/IEEE 26515:2018, 3.15]

3.50

user story

short description of what a user intends to achieve with part of the system

Note 1 to entry: A user story normally consists of a few sentences of ordinary spoken language of the acquirer (3.2) /user which states what the user does or will be able to do to achieve a certain objective (3.30) . In addition, a user story describes what acceptance criteria are used to consider the functionality produced as complete.

Note 2 to entry: A commonly used format for user stories is: ‘As <role> I can <activity> so that <purpose>’. For example: ‘As an employee I can specify my expenses so that I have these reimbursed by my employer’.

3.51

user story point

relative measure for the scope of user stories (3.50) , often used in agile development (3.3) methods

[SOURCE:NEN NPR 5326:2019, 3.52]