← 一覧に戻る ↓ このページの最下段に移る

JIS X 0160:2012
ソフトウェアライフサイクルプロセス 2012制定

番号 用語 定義 対応英語
4.1 取得者 供給者から,製品又はサービスを取得又は調達する利害関係者。
注記 取得者は,納入先,顧客,所有者及び購入者のいずれであってもよい。
acquirer
4.2 取得 システム,ソフトウェア製品又はソフトウェアサービスを得るためのプロセス。 acquisition
4.3 アクティビティ プロセスの構成要素で,関連の強いタスクの集合。 activity
4.4 合意 業務上の関係を実行するための取引条件の相互確認。 agreement
4.5 監査 要求事項との適合を評価するために権限を与えられた者によって行われるソフトウェア製品及びプロセスの独立した評価。 audit
4.6 ベースライン 公式にレビューされ,合意された仕様又は製品で,以降の開発の根拠として使用されるもの。その変更は,公式の変更管理手順を通してだけ認められる。 baseline
4.7 構成品目 決められた時点で実利用者が使用する機能を実現し,かつ,全体構成の中で一意に識別できる実体。
注記 この規格では,“実体(entity)”という用語は,製品だけでなく,例えば,活動,プロセス,組織又は人についても包含するように拡張している。
configuration item
4.8 契約 拘束力のある,特に法的強制力のある二者間の合意。又は,全て一つの組織の中で行われる同様の内部合意。 contract
4.9 顧客 製品又はサービスを受け取る組織又は人。
注記1 顧客は組織の内部又は外部であることができる。
注記2 JIS Q 9000:2006を編集。
注記3 顧客に対して通常使われる用語は,取得者,納入先及び購入者である。
customer
4.10 開発者 ライフサイクルプロセスを通して,開発作業(要求事項分析,設計,受入れテストなどを含む。)を遂行する組織。
注記 この規格では,開発者と実装者とは同義語になる。
developer
4.11 イネーブリングシステム ライフサイクル段階の期間中は対象システムを支援するが,運用の期間中はその機能に直接的に寄与するとは限らないシステム。
注記1 例えば,対象システムが製造段階に入ると,生産イネーブリングシステムが必要となる。
例えば,対象システムが自動車だとすると,イネーブリングシステムとは,ライフサイクルを通していえば,自動車のCAD,CAM,車体の組立工場,修理工場,リサイクル工場などを指す。
注記2 各イネーブリングシステムは,それ自身のライフサイクルをもつ。イネーブリングシステム自体を対象システムとして扱う場合には,この規格は,各イネーブリングシステムに適用可能である。
enabling system
4.12 評価 実体が特定の基準を満たしている度合いを系統的に測定すること。 evaluation
4.13 設備 活動の実施を容易にする物理的手段又は装置。例えば,建物,器具,道具など。 facility
4.14 ファームウェア ハードウェアデバイス上に読取り専用ソフトウェアとして組み込まれた計算機命令又はデータとハードウェアデバイスとの組合せ。
注記 そのソフトウェアは,プログラム制御下で容易に修正(modify)できない。
firmware
4.15 実装者 実装タスクを行う組織。
注記 この規格では,開発者と実装者とは同義語である。
implementer
4.16 ライフサイクル システム,製品,サービス,プロジェクト又は他の人工実体の,概念から廃止までの漸進的な変化。 life cycle
4.17 ライフサイクルモデル 段階に編成されることもあるライフサイクルに関係するプロセス及びアクティビティの枠組みで,コミュニケーション及び理解のための共通に参照できる役割をもつもの。
注記 “プロセス”,“アクティビティ”及び“タスク”は,システム開発作業を階層化して表すものである。最上位の作業のくくりが“プロセス”,その“プロセス”の構成要素が“アクティビティ”,更に,“アクティビティ”の構成要素が“タスク”である。
life cycle model
4.18 保守者 保守作業を実施する組織。 maintainer
4.19 監視 取得者又は第三者による,供給者の作業の状況及び作業結果の検査。 monitoring
4.20 非納入品目 ソフトウェア製品の開発で必要となるハードウェア製品又はソフトウェア製品であるが,契約上は納入する必要がないもの。 non-deliverable item
4.21 市販の製品 (製品の場合)既に開発が終わり,使用できる製品。 off-the-shelf
4.22 運用者 システムの運用を行う実体。
注記1 運用者及び利用者の役割は,同一の個人又は組織に対して,同時に又は順次的に,付与される。
注記2 この用語定義の中で,実体という用語は,個人又は組織を意味する。
operator
4.23 組織 責任,権限及び関係の取り合わせをもつ人又は人々の集団及び施設。
注記1 JIS Q 9000:2006を編集。
注記2 クラブ,組合,会社,学会など特定の目的のために組織された人の一群。
注記3 組織の識別された部分(たとえ単一個人のように小さくても)又は組織内の識別された群は責任,権限及び関係をもてば組織とみなされる。
注記4 組織的実体の形態は,エンタープライズと呼ばれることが多いので,この規格の組織の見方はエンタープライズにも同様に適用する。
organization
4.24 当事者 契約に関わる組織。
注記 この規格では,合意する当事者は取得者及び供給者と呼ばれる。
party
4.25 プロセス インプットをアウトプットに変換する,相互に関連する又は相互に作用する一連の活動(JIS Q 9000:2006)。 process
4.26 プロセス目的 プロセスを実行する高水準の目標及びプロセスの効果的実施によって見込みある成果。
注記 プロセスの実施は,利害関係者に目に見える利益を提供することが望ましい。
process purpose
4.27 プロセス成果 プロセスの目的の達成に成功することによって観察できる結果。
注記 成果の記述書は,次の一つを記述する。
−成果物の作成
−状態の重要な変化
−明示された制約事項への合致。例えば,要求事項,目標など。
process outcome
4.28 製品 プロセスの結果(JIS Q 9000:2006) product
4.29 プロジェクト 定められた資源及び要求事項に従って,製品又はサービスを作り出すために実施される,定義された開始日及び終了日がある取組み。
注記1 JIS Q 9000:2006を編集。
注記2 プロジェクトを調整され,制御されたアクティビティからなる固有のプロセスとして見てもよいし,この規格に定義されたプロジェクトプロセス及びテクニカルプロセスのアクティビティで構成されるものとしてもよい。
project
4.30 プロジェクトポートフォリオ 組織の戦略的目標に対応するプロジェクトの集まり。 project portfolio
4.31 適格性確認 実体が規定要求事項を満たすことができるかを実証するプロセス。 qualification
4.32 適格性確認の要求事項 ソフトウェア製品を適格とするために満たす必要のある基準又は条件の集合。そのソフトウェア製品は,仕様に適合し,かつ,実環境又はそれを含むシステムとの結合において利用可能である。 qualification requirement
4.33 適格性確認テスト ソフトウェア製品が仕様に適合し,かつ,実環境又はそれを含むシステムとの結合において利用可能であることを実証するテスト。このテストは,開発者が行い,必要な場合には,取得者が立ち合い,確認する。 qualification testing
4.34 品質保証 実体が品質要求事項を満たすことについての十分な自信を与えるために,品質システムの中で実施され,必要に応じて実証される,全ての計画的かつ体系的な活動。
注記1 品質保証には,次に示す内部目的及び外部目的がある。
a) 内部品質保証組織内においては,品質保証は管理に対して信頼を与える。
b) 外部品質保証契約下では,品質保証は顧客又はその他に対して信頼を与える。
注記2 品質管理活動及び品質保証活動の一部は相互に関連している。
注記3 品質要求事項が利用者のニーズを完全に反映していないときは,品質保証が十分な信頼を与えないこともある。
quality assurance
4.35 リリース 特定の目的(例えば,テストリリース)のために用意された構成品目の特定の版。 release
4.36 提案依頼書 指定されたシステム,ソフトウェア製品又はソフトウェアサービスを取得するために,取得者が入札希望者に対しその意図を伝えるために用いる文書。 request for proposal (tender)
4.37 資源 プロセスの実行中に利用又は消費される資産。
注記1 資源には,要員,設備,資本設備,道具などの多様な実在物及び電力,水,燃料,通信基盤などの公益物を含めてよい。
注記2 資源は,再利用できるものでもよいし,再生できるものでもよいし,又は使い切ってしまうものでもよい。
resource
4.38 廃止 新システムに一部若しくは全体を置き換えするか,又は改定したシステムを導入することで,運用又は保守組織が実施中の支援を中止すること。 retirement
4.39 セキュリティ 権限を与えられていない者又はシステムが読み込んだり修正(modify)できないように,かつ,権限を与えられている者又はシステムがアクセスを拒否されないように,情報及びデータを保護すること。 security
4.40 サービス 製品に付随した活動,作業又は職務の遂行。 service
4.41 ソフトウェア品目 ソースコード,オブジェクトコード,制御コード,制御データ又はこれらの品目の集まり。
注記 ソフトウェア品目は,ISO/IEC 15288:2008のシステム要素とみなすことができる。
software item
4.42 ソフトウェア製品 計算機プログラム,手続並びにその関連する文書及びデータを含めたまとまり。 software product
4.43 ソフトウェアユニット 別々にコンパイル可能なコードのひとまとまり。 software unit
4.44 段階 実体のライフサイクル内の期間で,実体記述又は実体の状態に関連するもの。
注記1 この規格では,段階は,そのライフサイクルを通して,実体の大きな進捗及び達成のマイルストーンに関係する。
注記2 段階は,重なってもよい。
stage
4.45 利害関係者 システムに,権利,持分,請求権又は関心をもっている個人又は組織。又は,ニーズ及び期待に合致する特性をシステムがもっていることに,権利,持分,請求権又は関心をもっている個人又は組織。 stakeholder
4.46 作業記述書 取得者が契約下で実施する作業を明確に記述するために使用する文書。 statement of work
4.47 供給者 製品又はサービスの供給に関して取得者と合意を結ぶ組織又は個人。
注記1 “供給者”は,請負業者,生産者,販売者又はベンダ。
注記2 時には取得者及び供給者は,同一の組織に属する。
supplier
4.48 システム 一つ以上の明記された目的を達成するために組織された相互に作用する要素の組合せ。
注記1 システムとは,それが提供する製品又はサービスとみなしてもよい。
注記2 実際には,その意味の解釈は,例えば,航空機システムのように複合名詞の使用によってしばしば明確にされる。別の表現として,システムという言葉を使わずに,文脈が明らかな場合は,例えば“航空機システム”を“航空機”という用語に置き換えられることができる。その場合は,システムという捉え方の観点が曖昧になる。
system
4.49 システム要素 システムを構成する要素の集合の一員。
注記 システム要素とは,特定の要求事項を満たすように実装できるシステムの個別の部分である。システム要素は,ハードウェア,ソフトウェア,データ,人間,プロセス(例えば,利用者にサービスを提供するプロセス),手順(例えば,操作指示),施設,資材及び自然に発生する実体(例えば,水,有機体,ミネラル)又はそれらの組合せであり得る。
system element
4.50 タスク プロセスの一つ以上の成果の達成に貢献するように意図された要求事項,勧告又は許される行動。 task
4.51 テスト網羅性 システム又はソフトウェア製品に対する要求事項について,テストケースを使用してテストできる程度。 test coverage
4.52 テスト可能性 要求事項が満たされているかどうかを決定するために,客観的かつ実行可能なテストが設計できる程度。
注記 JIS X 0129-1では,“testability”を“テスト可能性”ではなく,ソフトウェアの品質特性の観点から“試験性”と訳している。この場合は,修正したソフトウェアの妥当性の確認に必要な労力に影響する,ソフトウェアの属性を意味する用語として使われている。この規格では,用語の趣旨がJIS X 0129-1の趣旨と異なるので,訳語を変えている。
testability
4.53 利用者 システムを利用する間,システムからの恩恵を受ける個人又はグループ。
注記 利用者又は運用者の役割は,同一の個人又は組織の中で,同時に又は順番に担う。
user
4.54 妥当性確認 客観的証拠を提示することによって,特定の意図された用途又は適用に関する要求事項が満たされていることを確認すること(JIS Q 9000:2006)。
注記 ライフサイクルの関連でいう妥当性確認とは,意図された用途,ゴール及び目標をシステムが達成できることを確実にし,信任を得る一連のアクティビティである。
validation
4.55 検証 客観的証拠を提示することによって,規定要求事項が満たされていることを確認すること(JIS Q 9000:2006)。
注記 ライフサイクルでいう検証とは,ライフサイクルにおける任意の成果をその成果に必要とされる特性と比較するという一連のアクティビティである。これには,特定の要求事項,設計記述及びシステム自身を含めてもよく,それだけに限られるものでもない。
verification
4.56 ある品目の識別された実例。
注記 ソフトウェア製品の版の修正(modify)を行って新しい版とする場合は,構成管理の処置をとる必要がある。
version

← 一覧に戻る ↑ このページのトップに戻る