>サイトトップへ >このカテゴリの一覧へ

C 5750-4-2

:2008

(1)

目  次

ページ

序文

1

1

  適用範囲

1

2

  引用規格

2

3

  用語及び定義

2

4

  ソフトウェア  ライフサイクル  プロセス

8

5

  主ソフトウェア  ライフサイクル  プロセスにおけるディペンダビリティに関する諸活動

9

5.1

  取得プロセス

9

5.2

  供給プロセス

12

5.3

  開発プロセス

15

5.4

  運用プロセス

20

5.5

  保守プロセス

22

6

  支援ソフトウェア  ライフサイクル  プロセスにおけるディペンダビリティに関する諸活動

25

7

  組織に関するソフトウェア  ライフサイクル  プロセスにおけるディペンダビリティの諸活動

26

附属書 A(参考)ディペンダビリティ  プログラム要素及び  

タスクとソフトウェア  ライフサイクル  プロセスとの関係

29

附属書 B(参考)主ソフトウェア  ライフサイクル  プロセスと利用者との相互作用

30

附属書 JA(参考)JIS と対応する国際規格との対比表

31


C 5750-4-2

:2008

(2)

まえがき

この規格は,工業標準化法第 12 条第 1 項の規定に基づき,財団法人日本規格協会(JSA)から,工業標準

原案を具して日本工業規格を制定すべきとの申出があり,日本工業標準調査会の審議を経て,経済産業大

臣が制定した日本工業規格である。

この規格は,著作権法で保護対象となっている著作物である。

この規格の一部が,特許権,出願公開後の特許出願,実用新案権又は出願公開後の実用新案登録出願に

抵触する可能性があることに注意を喚起する。経済産業大臣及び日本工業標準調査会は,このような特許

権,出願公開後の特許出願,実用新案権又は出願公開後の実用新案登録出願に係る確認について,責任は

もたない。

JIS C 5750

の規格群には,次に示す部編成がある。

JIS

C

5750-1

第 1 部:ディペンダビリティプログラム管理

JIS

C

5750-2

第 2 部:ディペンダビリティプログラム要素及びタスク

JIS

C

5750-3-1

第 3-1 部:適用の指針−ディペンダビリティ解析手法の指針

JIS

C

5750-3-2

第 3-2 部:適用の指針−フィールドからのディペンダビリティデータの収集

JIS

C

5750-3-3

第 3-3 部:適用の指針−ライフサイクル  コスティング

JIS

C

5750-3-4

第 3-4 部:適用の指針−ディペンダビリティ要求事項仕様書作成の指針

JIS

C

5750-3-5

第 3-5 部:適用の指針−信頼性試験条件及び統計的方法に基づく試験原則

JIS

C

5750-3-6

第 3-6 部:適用の指針−ディペンダビリティにおけるソフトウェアの側面

JIS

C

5750-3-7

第 3-7 部:適用の指針−電子ハードウェアの信頼性ストレススクリーニング

JIS

C

5750-4-1

第 4-1 部:適用の指針−リユース部品を含む製品のディペンダビリティ−機能性及び

試験に関する要求事項

JIS

C

5750-4-2

第 4-2 部:適用の指針−ソフトウェア  ライフサイクル  プロセスにおけるソフトウェ

ア  ディペンダビリティ


日本工業規格

JIS

 C

5750-4-2

:2008

ディペンダビリティ管理−第 4-2 部:適用の指針−

ソフトウェア  ライフサイクル  プロセスにおける

ソフトウェア  ディペンダビリティ

Dependability management

−Part 4-2 : Software dependability through

the software life-cycle processes

−Application guide

序文

この規格は,2000 年に第 1 版として発行された IEC 61713 を基に技術的内容を変更して作成した日本工

業規格である。

なお,この規格で点線の下線を施してある箇所は,対応国際規格を変更している事項である。変更の一

覧表をその説明を付けて,

附属書 JA に示す。

ディペンダビリティはアベイラビリティ性能及びこれに影響を与える要因,すなわち,信頼性性能,保

全性性能及び保全支援能力を記述するために用いられる包括的な用語である。JIS C 5750-2 は,広範囲に

わたるディペンダビリティプログラムに含まれる要素及びタスクに関する指針を規定する。ディペンダビ

リティ  プログラムにおけるソフトウェアの側面に関する更に詳細な指針は,JIS C 5750-3-6 に規定する。

この規格は,多くのソフトウェア規格の基礎を構成するソフトウェア  ライフサイクル  プロセスに関連付

けて,ソフトウェア  ディペンダビリティの達成についての指針を規定することによって JIS C 5750-3-6 

補完することを意図している。この指針は,信頼できるソフトウェア,すなわち,要求事項に従って確実

に動作するソフトウェアを達成する手助けをするソフトウェア  ライフサイクル  プロセスのアクティビテ

ィ及びディペンダビリティ  プログラムの諸活動を明確にするものである。

ソフトウェア取得からソフトウ

ェア保守までのソフトウェア  ライフサイクルを表現するために規定するソフトウェア  ライフサイクル

プロセス及びその構造の詳細は,JIS X 0160 に規定する。

ソフトウェアに関するアクティビティ及びそのディペンダビリティ  プログラム諸活動は,各種のソフト

ウェア  ライフサイクル  プロセスに関係している。ソフトウェア  ライフサイクル  プロセスは,ソフトウ

ェア  プロジェクトの明記された目的を達成するために行われる要求事項の仕様を含む,

計画されたアクテ

ィビティ及びその諸活動の集合である。この指針は,ソフトウェア  ディペンダビリティに影響をもつこれ

らのライフサイクル活動の識別及び実施を容易にする。

1

適用範囲

この規格は,

信頼できるソフトウェアの達成に影響を与えるソフトウェア  ライフサイクルのアクティビ

ティのすべて及びディペンダビリティ  プログラム諸活動の側面に関する指針について規定する。

そのソフ

トウェア  ライフサイクル  アクティビティ及びその諸活動は,ソフトウェア  ライフサイクル  プロセスに

関連している文書に定義されている。この指針は,JIS C 5750-3-6 の活用を補完することを意図している。


2

C 5750-4-2

:2008

識別されたソフトウェア  ライフサイクル諸活動は,

システム又はソフトウェアを含む製品に対するディ

ペンダビリティ  プログラムの中の一部分となり得る。識別された諸活動は,信頼性及び保守性の優れたソ

フトウェアの達成を助ける,また,適切な保守支援の提供を確実にすることを助ける。それらの諸活動は,

ソフトウェア  ライフサイクル全期間にわたって適用できるか,

又はこのソフトウェアの関係者次第でソフ

トウェア  ライフサイクル  プロセスの一部分に限って適用できる。このソフトウェアの関係者とソフトウ

ェア  ライフサイクル  プロセスとの間の関連は,

附属書 に示す。それらは,JIS X 0160 に規定するよう

にソフトウェア  ライフサイクル全体を構成する種々の個別ソフトウェア  ライフサイクル  プロセスに対

応したグループに分けられている。この指針では,主ソフトウェア  ライフサイクル  プロセスに適用でき

るディペンダビリティ要求事項及びそのアクティビティについて,重点を置いている。この指針は,ソフ

トウェアの取得者,供給者,開発者,運用担当者,又は保守担当者が利用することができる。この指針は,

ソフトウェア及びディペンダビリティの専門家に加えて,ソフトウェアを含むシステム又は製品を開発し

たり,利用するプロジェクト管理者,品質管理専門家その他のプロジェクト参加者が利用することを意図

している。

注記  この規格の対応国際規格及びその対応の程度を表す記号を,次に示す。

IEC 61713:2000

,Software dependability through the software life-cycle processes−Application guide

(MOD)

なお,対応の程度を表す記号(MOD)は,ISO/IEC Guide 21 に基づき,修正していることを示

す。

2

引用規格

次に掲げる規格は,この規格に引用されることによって,この規格の規定の一部を構成する。これらの

引用規格は,その最新版(追補を含む。

)を適用する。

JIS C 5750-2

  ディペンダビリティ管理−第 2 部:ディペンダビリティプログラム要素及びタスク

注記  対応国際規格:IEC 60300-2:1995,Dependability management−Part 2: Dependability programme

elements and tasks (MOD)

JIS C 5750-3-6

  ディペンダビリティ管理−第 3-6 部:適用の指針−ディペンダビリティにおけるソフ

トウェアの側面

注記  対応国際規格:IEC 60300-3-6:1997,Dependability management−Part 3: Application guide−

Section 6: Software aspects of dependability (IDT)

JIS Q 9000

  品質マネジメントシステム−基本及び用語

注記  対応国際規格:ISO 9000:2005,Quality management systems−Fundamentals and vocabulary (IDT)

JIS X 0160

  ソフトウェアライフサイクルプロセス

注記  対応国際規格:ISO/IEC 12207:1995,Information technology−Software life cycle processes (IDT)

JIS Z 8115

  ディペンダビリティ(信頼性)用語

注記  対応国際規格:IEC 60050 (191):1990,International Electrotechnical Vocabulary (IEV)−Chapter

191: Dependability and quality of service (MOD)

IEC 61160

,Formal design review

3

用語及び定義

この規格で用いる主な用語及び定義は,JIS Z 8115JIS X 0160 及び JIS Q 9000 によるほか,次による。


3

C 5750-4-2

:2008

注記 1  JIS Z 8115 では Maintenance に対応する用語は保全又は保守であるが,この規格ではソフトウ

ェア産業分野の慣習に従って保守を用いる。

注記 2  ディペンダビリティの規格では,用語 activity は活動,activities は諸活動として用いている。

一方,JIS X 0160 のソフトウェア  ライフサイクル  プロセスの記述では用語 activities をアク

ティビティとして用いている。プロセス関連の記述でも諸活動及びアクティビティは,ディ

ペンダビリティ規格から見ると同義語と解釈できる。したがって,この規格の中では,同義

語という解釈のもとで,ソフトウェア  ライフサイクル  プロセス関連の記述に限って,

activities

をアクティビティと表現する。

注記 3 2003 年に ISO 8402 から完全に置き換わった JIS Q 9000 での用語の定義は,ISO 8402 よりも

更に広い意味をもつように定義されている用語もあるので,引用するときには,引用する固

有の領域に限定して使用することができるように留意する。

注記 4  3.73.43 の用語及び定義は,JIS X 0160 に規定するものであるが,この規格の理解を助ける

ために,ここに繰り返して示しておく。

3.1

ディペンダビリティ  (dependability)

アベイラビリティ性能及びこれに影響を与える要因,すなわち信頼性性能,保全性性能及び保全支援能

力を記述するために用いる包括的な用語(JIS Z 8115 の R1 参照)

注記  ソフトウェアのディペンダビリティは,ソフトウェアの信頼性,ソフトウェアの保守性及びソ

フトウェアの保守支援によって記述する。

3.2

ディペンダビリティ機能  (dependability function)

ソフトウェアのディペンダビリティ要求事項仕様の個々の側面を記述するために用いる用語。ディペン

ダビリティ機能は,信頼性,保守性又は保守支援に関連したディペンダビリティ要求事項を記述する。

3.3

保守リリース  (maintenance release)

拡張又は改良された機能の提供ではなく,訂正のために実施する製品のリリース。この訂正は,是正保

守及び予防保守を意味する。

3.4

ソフトウェアの信頼性  (software reliability)

与えられた条件の下で,システムの運用中の与えられた期間,システムのどのソフトウェア要素もフォ

ールトがなく動作している確率。

3.5

ソフトウェアの保守性  (software maintainability)

システムのソフトウェア要素に検出されたフォールトを是正することの容易さ。

3.6

ソフトウェアの保守支援  (software maintenance support)

与えられた保守方針の下でシステムのソフトウェア要素を維持するために必要なリソース(又は資源)

を供給するための与えられた条件の下での組織の能力。

注記  与えられた条件はソフトウェア要素そのものに関係しているし,また,それが用いられ保守さ

れる条件に関係する(JIS Z 8115 の MM2 参照,修正)


4

C 5750-4-2

:2008

3.7

取得者  (acquirer)

供給者から,システム,ソフトウェア製品若しくはソフトウェア  サービスを取得又は調達する人,又は

組織。

注記  取得者とは,バイヤ,顧客,所有者,利用者又は購入者のいずれかである。

3.8

取得  (acquisition)

システム,ソフトウェア製品又はソフトウェア  サービスを得るためのプロセス。

3.9

合意  (agreement)

業務上の関係を実施するための契約条件の定義。

3.10

監査  (audit)

ソフトウェア製品及びその作成プロセスが要求事項を満足しているかどうかを,権限を与えられた者が

独立した立場で評価すること。

3.11

ベースライン(基準線)(baseline)

構成アイテムがそのライフサイクル期間の決められた特定の時期に媒体に関係なく,正式に指定し確定

された構成アイテムの正式版として承認されたもの。

3.12

構成アイテム  (configuration item)

与えられた基準時点で最終用途の機能を満足し,一意に識別できる構成(全体構成)の中のアイテム。

3.13

契約  (contract)

ソフトウェア  サービスの供給に関する,又はソフトウェア製品の供給,開発,生産(製造)

,運用若し

くは保守に関する,法的強制力のある二者間の合意。又は,一つの組織の中で行われる同様な内部合意。

3.14

開発者  (developer)

ソフトウェア  ライフサイクル  プロセスにおける(要求事項の分析,設計及び受入れテストを含む。

)開

発活動を遂行する人又は組織。

3.15

評価  (evaluation)

アイテムがその規定された基準に適合している程度を系統的に決定すること。

3.16

ファームウェア  (firmware)

ハードウェア  デバイス及びハードウェア  デバイス上に読取り専用ソフトウェアとして組み込まれたコ

ンピュータ  インストラクション又はデータとの組合せ。このソフトウェアは,プログラム制御の下では容

易には修正できない。

3.17

ライフサイクル  モデル  (life-cycle model)


5

C 5750-4-2

:2008

ソフトウェア製品の開発,運用及び保守に伴うプロセス,アクティビティ及びディペンダビリティ  プロ

グラムの諸活動並びにタスクの枠組み。この枠組みは,システム要求事項の定義からその利用の終了まで

のシステム寿命に及ぶ。

注記  プロセス,アクティビティ(諸活動)及びタスクは,システム開発作業を階層化して表す。最

上位の作業のくくりがプロセス,そのプロセスの構成要素がアクティビティ(活動)

,更にアク

ティビティ(活動)の構成要素がタスクである(JIS X 0160 の 3.11

参考を参照)。

3.18

保守担当者  (maintainer)

保守活動又は保守作業を実施する人又は組織。

3.19

監視  (monitoring)

取得者又は第三者が,供給者の活動(作業)状況及びその結果を調べるために観察すること。

3.20

非納入アイテム  (non-deliverable item)

ソフトウェア製品の開発で必要となるハードウェア又はソフトウェア製品であるが,契約上は納入する

必要がないもの。

3.21

既製品  (off-the-shelf product)

開発済み製品で,そのままで又は少し手を加えて使用できる状態にある製品。

3.22

運用担当者  (operator)

システムを運用する人又は組織。

3.23

プロセス  (process)

時間的に順序付けられ,互いに関連をもっており,入力を出力に変換するアクティビティの集合。

注記  用語“アクティビティ”には,資源を利用することも含まれる。

3.24

認定(適格性確認)(qualification)

アイテムが規定要求事項を満たす能力があるかどうかを実証するプロセス。

3.25

認定要求事項(適格性確認要求事項)(qualification requirement)

ソフトウェア製品が仕様に適合し,かつ,実環境で利用可能であることの確認に用いる基準又は条件の

集合。

3.26

認定テスト(適格性確認テスト)(qualification testing)

ソフトウェア製品が仕様に適合し,かつ,実環境で利用可能であることを実証確認するテスト。このテ

ストは開発者が行い,適宜取得者が確認する。

3.27

品質保証  (quality assurance)

品質要求事項が満たされているという確信を与えることに焦点を合わせた品質マネジメントの一部(JIS 


6

C 5750-4-2

:2008

Q 9000

の 3.2.11 参照)

注記  JIS X 0160 の 3.21 では品質保証 (quality assurance) を次のように定義している。

ある“もの”すなわち,アイテムが品質要求事項を満たすことについての十分な信用を与えるた

めに,品質システムの中で実施され,必要に応じて実証される,すべての計画的,かつ,体系的な

活動。

a)

品質保証には,次に示す内部目的と外部目的とがある。

1)

内部品質保証  組織内においては,品質保証は,経営者に対して信頼を与える。

2)

外部品質保証  契約下では,品質保証は,顧客又はその他に対して信頼を与える。

b)

品質管理手法による活動及び品質保証活動の一部は相互に関連している。

c)

品質要求事項が利用者のニーズを完全に反映していないときには,品質保証が十分な信頼を

与えないこともある。

3.28

リリース  (release)

特定の目的のために用いられる構成アイテムの特別な版(例えば,テストリリース)

3.29

提案依頼書(入札依頼書)(request for proposal, tender)

規定されたシステム,ソフトウェア製品又はソフトウェア  サービスを取得するために,取得者が入札者

(入札してもらえそうな組織)に対しその意図を伝えるために用いる文書。

3.30

廃棄  (retirement)

運用組織及び保守組織が実施中の支援を中止すること。引き継いで新システムに一部若しくは全体を置

き換えるか,又はグレードアップしたシステムを導入することもある。

3.31

セキュリティ  (security)

権限なしの者又はシステムが情報及びデータを読み込んだり,変更できないように保護し,かつ,権限

がある者又はシステムはアクセスを拒否されないようにすること。

3.32

ソフトウェア製品  (software product)

コンピュータ  プログラム,手続及びその関連する文書及びデータを含めたまとまり。

3.33

ソフトウェア  サービス  (software service)

開発,運用及び保守のようなソフトウェア製品に関する活動,作業又は職務の遂行。

3.34

ソフトウェア  ユニット  (software unit)

単独でコンパイル可能なコードの一まとまり。

3.35

作業指示書  (statement of work, SOW)

契約の下で実施する作業を記述し,規定する手段として取得者が用いる文書。

3.36

供給者  (supplier)


7

C 5750-4-2

:2008

取得者と契約を交わし,その条項に基づいてシステム,ソフトウェア製品又はソフトウェア  サービスを

提供する人又は組織。

注記 1  “供給者”という用語は,契約者(受注者),製作者,販売者又はベンダと同義語とする。

注記 2  取得者は,自組織の一部を供給者として指定する場合がある。

3.37

システム  (system)

一つ以上のプロセス,ハードウェア,ソフトウェア,設備及び人を統合化して,規定のニーズ又は目的

を満たす能力を提供するまとまり。

3.38

テスト網羅性  (test coverage)

システム又はソフトウェア製品に対する要求事項について,テストケースを使用してテストを実施でき

る又はテストを実施した範囲。

3.39

テスト可能性(テスト計画性)(testability)

要求が満たされているかどうかを判定するために,客観的,かつ,実施可能なテストが計画できる範囲。

注記 1  テスト可能性(テスト計画性)は,ソフトウェアの品質特性の観点から,テスト性とも呼ば

れる場合がある(JIS X 0129:1994 ソフトウェア製品の評価−品質特性及びその利用要領)

その場合は,改訂したソフトウェアの妥当性の確認に必要な労力に影響する,ソフトウェア

の属性を意味する用語として使われている。この規格では,この用語の趣旨と JIS X 

0129:1994

とのそれと異なるので,訳語を変えている(この

注記は,JIS X 0160 の 3.33 参考

を参照)

注記 2  テスト可能性の代わりにテスト容易性が状況に応じて用いられる。

3.40

利用者(ユーザ)(user)

特定の機能を果たす運用システムを利用する個人又は組織。

注記  利用者(ユーザ)は,取得者,開発者又は保守担当者の役割を果たす場合がある。

3.41

妥当性確認  (validation)

客観的証拠を提示することによって,特定の意図された用途又は適用に関する要求事項が満たされてい

ることを確認すること。

注記 1  “妥当性確認済み”という用語は,妥当性確認が済んでいる状態を示すために用いられる。

注記 2  妥当性確認のための使用条件は,実環境でも模擬でもよい。

JIS Q 9000 の 3.8.5 参照)

注記 3  JIS Z 8115 の MT11 では,妥当性確認 (validation)を次のよう定義している。

最終製品とその支援機能が,全体として使用者の用途に適合しているかいないかを確認す

る行為。

a)

妥当性確認は,通常,最終製品について規定の運用条件の下で実施される。

b)

“妥当性確認済み”という用語は,妥当性確認された状態を示すために使用される。

c)

複数の異なった用途があるときには,妥当性確認を用途ごとに分けて複数回実施す

ることがある。


8

C 5750-4-2

:2008

d)

ソフトウェア  アイテムの場合,要求仕様事項を満たしているかどうかを決定するた

めに,開発プロセスの最終段階で,システム及びその構成部品を評価し,実証する

プロセス。

3.42

適合確認(検証)(verification)

客観的証拠を提示することによって,規定要求事項が満たすことを確認すること。

注記 1  “検証済み”という用語は,検証が済んでいる状態を示すために用いる。

注記 2  確認には,次のような活動があり得る。

−  別法によって計算を実施する。

−  新しい設計仕様書を類似の証明済みの設計仕様書と比較する。

−  テスト及び実証を行う。

−  発行前に文書をレビューする。

JIS Q 9000 の 3.8.4 参照)

注記 3  JIS Z 8115 の MT10 では,適合確認(検証)(verification)  を次のように定義している。

規定された要求事項が満たされていることを,客観的証拠の調査及び提示によって確認す

る行為。又は,製品が,ライフサイクルの中の与えられた段階(又はその部分段階)に対し

て定義されるディペンダビリティ仕様に適合しているかいないかを判定する行為。

a)

設計及び開発において,検証(又は適合確認)は,対象となる活動の結果を調査・吟味し,

その活動に関して明記された要求事項に適合しているかいないかを判定することにかかわる

ものである。

b)

“検証済み”

“適合確認済み”

)という用語は,検証された(適合確認された)状態を示すた

めに使用される。

c)

ソフトウェア  アイテムの場合は,ある開発段階の製品がその段階の初めに課せられていた条

件を満たしているかいないかを決定するため,システム又は部品を評価するプロセス。この

評価は一般に要求事項を反映した製品機能の仕様に基づく評価基準によって行われる。

3.43

バージョン  (version)

更新されたアイテムの段階,又はその識別子。

注記  ソフトウェア製品の版の変更を行って,新しい版とする場合は,構成管理の処置をとる必要が

ある。

4

ソフトウェア  ライフサイクル  プロセス

ソフトウェア  ライフサイクル  プロセスは,

ソフトウェア  プロジェクトで明記している目標達成のため

に必要な計画されたアクティビティ又はタスクの集合である。それには次の三つのグループが存在する。

すなわち,概念段階から廃棄の段階にわたるソフトウェア製品に関連するアクティビティを包含している

主ライフサイクル  プロセス,

支援ライフサイクル  プロセス及び組織に関するライフサイクル  プロセスで

ある。

五つの主ライフサイクル  プロセスは,

ソフトウェアを含むシステム又は製品の取得者,

供給者,

開発者,

運用担当者及び保守担当者への指針を与える。

八つの支援ライフサイクル  プロセスは,

他のプロセスを支援し,

五つの主プロセスとともに用いられる。


9

C 5750-4-2

:2008

これらの支援ライフサイクル  プロセスは,文書化,構成管理,品質保証,適合確認,妥当性確認,共同レ

ビュー,監査及び問題解決のプロセスである。

四つの組織に関するライフサイクル  プロセスは,

組織上若しくはプロジェクト上での必要性に応じて主

要な部門又は主プロセスで用いることができる。

これらの組織に関するライフサイクル  プロセスは,

管理,

環境整備,改善及び教育訓練のプロセスである。ソフトウェア  ライフサイクル  プロセスの詳細及びその

使用は,JIS X 0160 に規定する。

JIS C 5750-2

に規定するディペンダピリティ  プログラム要素及びタスクとソフトウェア  ライフサイク

ル  プロセスとの関係は,ソフトウェアを含む製品について関連するので,JIS C 5750-2 に規定する。

附属

書 に JIS C 5750-2 の特定の項目との相互参照表を示す。

5

主ソフトウェア  ライフサイクル  プロセスにおけるディペンダビリティに関する諸活動

信頼できるソフトウェア製品を完成させるためには,ディペンダビリティ特性に特に影響を与えるよう

な諸活動及びそれらの作業を明確にし,実施する必要がある。これらの活動は,ソフトウェアを含むシス

テム又は製品の意図した使用,応用,運用及びその環境を考慮するのがよい。次の 5.15.5 に規定する五

つの主ライフサイクル  プロセスのそれぞれにおいて必要な諸活動を,適切であれば,考慮するのがよい。

5.1

取得プロセス

取得プロセスとは,ソフトウェアを含むシステム又は製品を取得するときに含まれる取得者の諸活動及

びそれらの作業について記述するために用いる用語である。

ディペンダビリティの視点からは,ソフトウェア製品の信頼性性能,保守性性能及び供給者の保守支援

能力は考慮すべき主要な側面である。取得プロセスの主要要素は,ディペンダビリティの要求事項に基づ

いた仕様,供給者の評価及び選定,契約関連文書の準備,供給者の監視並びにそれらの受入れと管理であ

る。これらの要素は 5.1.15.1.5 に規定する。

5.1.1

ディペンダビリティの要求事項の仕様

取得者によって提供された要求事項に基づいた仕様は,ソフトウェア製品のディペンダビリティに影響

を及ぼす諸要因について表現するのがよい。すなわち,ディペンダビリティ要求事項は,信頼性,保守性

及び保守支援の要求事項として規定する。したがって,次に示す要求事項は取得者によって又は供給者と

共同で規定する。

a)

ソフトウェアの信頼性要求事項  連続したシステム運用のための要求事項,これらは故障発生までは

フォールトがない,与えられた運用時間間隔ごとの経過時間又は実施回数によって明確に規定するの

がよい。要求されたシステム運用アベイラビリティ性能,すなわち,システムがその機能を遂行する

ことの可能な運用時間の割合,これは,平均修理時間 (MTTR) 及び平均故障間隔 (MTBF) のような

分かりやすい用語で表現するのがよい。また,システムの故障を引き起こす諸条件も規定するのがよ

い。

−  意図したシステム適用のための特別な信頼性要求事項を与える環境諸要因。

−  システムの回復条件,すなわち,システム故障後のシステム再起動時に満足することが望ましい

システムの回復時間又は機能的条件。

−  規定されたフェール  セーフ要求事項,例えば,システムの故障時でも失わないことが望ましいデ

ータ,システム故障時に働くセーフ機能の状態,又は機能低下での運用。

第三者の査定,評価,又は認可のための要求事項は明確にするのがよい。これらの要求事項のソフ

トウェア設計要求項目への影響を考慮するのがよい。


10

C 5750-4-2

:2008

提供すべきサービスの最低水準があり,その最低水準のサービスの状況,サービス時間の長さ,回

数などが受け入れられる場合には,これらを明確にし,規定するのがよい。

システムのすべての側面に対して同等なディペンダビリティ要求事項が存在することはほとんどな

い。そのために取得者はシステムのどの部分に適用される要求事項であるかを厳密に識別するのがよ

い。

取得者はその要求事項の直接の結果として又はその要求事項に対する特別な解決策の結果としての

いずれかで,どのような追加のコスト,資源などが発生するかについて判断しておくのがよい。

b)

ソフトウェアの保守性に関する要求事項  意図したシステム適用プログラムのための特別な保守性に

関する要求事項を付加する環境要因。加えて,そのための保守性技術水準及びそのために必要な教育

訓練水準を明示しておくのがよい。保守性要求事項は,平均修理時間 (MTTR) のような分かりやすい

用語又は尺度で表現することが望ましい。

c)

ソフトウェアの保守支援に関する要求事項  意図したシステム適用プログラムのための特別な保守支

援に関する要求事項を付加する環境要因。加えて,そのための保守支援技術水準及びそのために必要

な教育訓練水準を明示しておくのがよい。保守支援に関する要求事項は,平均修理時間 (MTTR) 又は

平均補給遅延時間 (MLDT)のような分かりやすい用語又は尺度で表現することが望ましい。

5.1.2

供給者の選定

信頼できるソフトウェア製品の開発及び供給並びに製品の寿命期間中の効果的な支援サービスの提供に

関する供給者の能力は主要な要求事項である。供給者が既にソフトウェア製品を開発又は既存の製品とし

て保有している場合には,その既存の製品又はそれに伴う支援サービスは供給者の選定時には考慮するこ

とがある。供給者がソフトウェア開発者の可能性があると考えられる場合は,彼らの開発プロセスでの諸

活動について 5.3 に規定する指針に従って信頼できるソフトウェア製品の開発に対する評価をするのがよ

い。

供給者の選定には,次に示すような供給者が心得ておく項目を含むこともまた望ましい。

−  技術的要求事項  システム要求事項からのソフトウェア要求事項の系統的割出し。

−  契約上の要求事項  取得製品のソフトウェア部分に影響を及ぼす合意事項,諸条件及び規定事項

その他,供給者の選定に関する基準として次に示す項目に関する過去の実績を含むことが望まし

い。

−  ソフトウェアの開発。

−  ソフトウェア  プロジェクト管理,これはソフトウェア品質保証 (QA),構成管理 (CM),信頼性試

験,及び保守に関する事項などを含む。

−  利用者の支援のためのソフトウェアの移行。

−  ソフトウェアに関するリスク評価及びそれに基づくリスク軽減計画の立案。

−  ソフトウェアのセキュリティ。

供給者の評価と選定のためには,次に示す側面について考慮するのがよい。

a)

既存のソフトウェア製品  データが入手できる場合には,供給者によって既に提供されている製品の

ディペンダビリティを評価するのがよい。例えば,供給者がソフトウェアの開発者であれば,製品の

信頼性性能,保守性性能及び供給者の保守支援能力が評価される。これらの性能特性に関する測定の

ベースラインは保守支援能力の測定のための MTTR 又は信頼性性能の測定のための MTBF のような分

かりやすいアベイラビリティの尺度要素であるのがよい。以前に供給された製品のディペンダビリテ

ィに関するデータが入手できない場合には,取得者はソフトウェア製品を製作するために供給者が用


11

C 5750-4-2

:2008

いる開発プロセスについて評価することによって,製品のディペンダビリティを間接的な方法で評価

することができる。この方式は,5.1.2 b)に規定する。ソフトウェア製品のディペンダビリティは,そ

の製品を規定されたシステム環境下で動作している状態において評価することが望ましい。

検討されている製品のディペンダビリティは,競合する製品のディペンダビリティと比較検討する

のがよい。成熟したソフトウェア製品を提供できる供給者の能力は,しばしば製品のディペンダビリ

ティに反映されているものである。可能ならば類似した条件下で考えられる同等の尺度を用いること

によって,その比較検討を行うのがよい。

供給者がソフトウェア開発者の場合には,保守支援の組織体制及び支援手順は 5.5 に規定する保守

プロセスに関するディペンダビリティ指針に従って評価するのがよい。

供給者がソフトウェア開発者の場合に,製品のディペンダビリティを改善することを目的とした何

らかの信頼性成長試験を実施することになる。その信頼性成長試験は,故障要因の識別,解析,そし

て是正及びその是正処置が効果的か否かの適合確認を行う一連の作業である。このような信頼性成長

モデルを用いた信頼性成長試験の方法論に関する詳細は JIS C 5750-3-6 の 6.8.4 で規定する。供給者に

よって実施されるいかなる信頼性成長プログラムも,現在の達成度と計画されたディペンダビリティ

の目標とを比較するためにレビューするのがよい。

b)

新しいソフトウェア製品  供給者がソフトウェア開発者の場合には,要求事項の仕様として規定する

ディペンダビリティの測定方法について,その一貫性と完全性とを評価するのがよい。ソフトウェア

開発の場合は,供給者のソフトウェア開発プロセスを開発プロセス  ディペンダビリティ指針に従って

レビューするのがよい(5.3 参照)

。これらの指針は,信頼できるソフトウェアのための要求事項の解

析,仕様化,設計,コーディング,テスト及び導入に関する一連の開発者のための諸方法並びに手順

類を評価するための取組みについて助言を与える。

c)

ソ フ ト ウ ェ ア   プ ロ セ ス の 成 熟 度   ソ フ ト ウ ェ ア開 発 者 が プ ロ セ ス 能 力 成熟 度 モ デ ル  (CMM:

Capability Maturity Model)

のようなある種のソフトウェア  プロセス成熟度の評価認定をもっている

場合には,それらを評価基準の一部としてレビューし,考慮することが望ましい。この種のモデルは,

ソフトウェア開発を遂行したり,現行のソフトウェアへの取組みに使われているソフトウェア  プロセ

スの状態を監視したりするうえでの,個々のソフトウェア開発者の能力認定に関する評価尺度を与え

る。

5.1.3

契約締結のための準備

供給者の評価及び選定(5.2 参照)には支援及び供給条件に関する交渉がしばしば含まれるので,契約上

の文書類にはディペンダビリティに関する包括的な要求事項を含むことが必す(須)である。ソフトウェ

ア開発を含む契約の場合には特に必要である。小規模な供給会社の場合には,契約文書は公式の契約書で

はなく,入札文書又は注文書に限定されることがある。これらの場合には,

“契約書”という用語は入札文

書又は注文書を含むように拡張解釈される。次に示すディペンダビリティに関する側面は,相互に受け入

れることができる条件をどこの箇所で明示的に定義するかの交渉後に,契約書に規定するのがよい。

a)

受入れ条件,信頼性要求事項,保守性要求事項及び保守支援要求事項。

b)

アベイラビリティ要求事項に関する用語でアベイラビリティ特性についての明示。

システムの一構成部分として供給されるソフトウェアの場合には,システム環境で運用されるとき

のディペンダビリティ要求事項を明記するのがよい。適用可能なディペンダビリティに関する規格類

がある場合には,これらを規定するのがよい。

c)

取得者は,アベイラビリティ要求事項を明示するのがよい。これは最初のアベイラビリティ要求事項


12

C 5750-4-2

:2008

が定められることを確実にする。供給者が定められた要求事項を達成できないか又は達成できそうも

ない場合には,これらのアベイラビリティ要求事項は,その変更要件に合わせて契約事項の変更又は

仕様の改定について再交渉することになる。

d)

供給者が製品に変更を加えるプロセスは取得者と合意する必要がある。ソフトウェア製品の変更記録

及びその変更管理のためのプロセスは,すなわち,用いられるソフトウェア構成管理手順及び供給者

との合意に基づいて行われる,ソフトウェア変更管理委員会のような公式の変更管理方式であるのが

よい。

e)

規定されたディペンダビリティ要求事項は,完全に規定するのは難しいが,契約事項として必要であ

る。全システムのある範囲におけるディペンダビリティの低下は,別の範囲におけるコストの増加を

引き起こすことがある。例としては,ホット  スタンバイ端末を用意する場合,より多くの保守要員を

配置する場合,より多くの予備品を用意する場合などである。システムで要求しているディペンダビ

リティの水準を供給するためのコストが,その要求水準に達していない場合における補償のためのコ

ストを超え得る損益分岐点はしばしば存在するものである。契約書ではトレードオフの提案と,見積

りを可能にするのがよい。また,調達されるシステムの一部によって提供されるサービスの最低水準

を規定するか,又はサービス担当者数を増減できないことを明示することなどによって,関連する制

約条項を規定するのがよい。取得者は,解決を必要とする問題及びそのために適用される制約などを

できる限り明確に規定するのがよい。

通常,取得者がアベイラビリティ性能を規定するのがよいが,供給者がその信頼性性能,保守性性

能及び保守支援能力を管理することができない場合は,供給者はその契約条項を交渉することができ

る。アベイラビリティ性能  (A)  を信頼性性能  (R),保守性性能  (M)  及び保守支援能力  (MS)  の関数

として表す場合は,次のようになる。

(

)

MS

M

R

f

A

,

,

=

あるクリティカルなシステム  アプリケーションでは,アベイラビリティ性能  (A)  及び保守性性能

(M)

は注意深く規定することが重要である。例えば,アベイラビリティは医療分野ではソフトウェア

を含む医療機器のアベイラビリティはしばしば病人の命にかかわるクリティカルな要素である。

f

)

保守支援のための要求事項及び諸条件  ソフトウェアを含むシステム又は製品の保守活動の対応時

間,その頻度のような特定の保守又はアベイラビリティに関する諸要求事項がある場合には,これら

を規定するのがよい。特有な規制及び規格がある場合は,これらを規定するのがよい。

5.1.4

供給者の監視

供給者のレビュー,監査,適合確認及び妥当性確認の諸活動(箇条 参照)を取得者が監視することは,

規定されたディペンダビリティの諸機能の適合確認及び妥当性確認によって得られるソフトウェアのディ

ペンダビリティ達成に役立つことになる。取得者は,また,懸案事項を解決したり,必要なディペンダビ

リティ関連情報を適宜用意することによって,供給者と十分に共同作業を行うことが望ましい。

5.1.5

製品の受入れ及び完了

取得者は,受入テストの準備とその実施において要求仕様で規定されたディペンダビリティに関連する

諸事項を含めることを確実にすることが望ましい。取得者はすべての規定するディペンダビリティに関す

る受入条件を満たした時点で,供給者から納入可能なソフトウェアを受け取ることになる。

5.2

供給プロセス

供給プロセスは,供給者の行うアクティビティを網羅している。ディペンダビリティの視点から,供給

プロセスのアクティビティに関する次の付加的な信頼性  (R),保守性  (M)  及び保守支援  (MS)  の側面を考


13

C 5750-4-2

:2008

慮するのがよい。さらに,例えば,供給者の選択(5.1.2 参照)又は契約交渉の過程で信頼性成長プログラ

ムが交渉して決められるならば,信頼性成長プログラムを要求することがある。

5.2.1

開始

供給者は,取得者のディペンダビリティに関する諸要求事項を具体的にレビューし,信頼性,保守性及

び保守支援に関する諸要求事項を明確化し,これらの要求事項が新規又は既存の製品で満足できるかをも

明確化するのがよい。

レビューの結果に従って,契約の入札若しくは契約の受入れ又は適切な代替となる問題解決策の提案の

いずれかを決定する前に,供給者は信頼性,保守性及び保守支援に関する諸要求事項を満足するために必

要な支援能力レベル及びそのための費用を決定するのがよい。

5.2.2

提案の準備

供給者による提案内容の準備は,次による。

a

)

供給者の提案は,取得者の規定するディペンダビリティに関する諸要求事項又は諸規格を満足してい

るのがよい。提案が要求を満足していない場合には,提案するトレードオフと最初の要求事項,例え

ば,サービス水準の観点との差から,取得者によってそれらの価値が判断できるように,そのトレー

ドオフの内容を明確にするのがよい。

b

)

供給者の提案がソフトウェアの開発を必要とする場合には,供給者が信頼性成長プログラムを実施す

るか又はそれを試行するかを明確にするのがよい。

c

)

供給者の提案書は,技術的な提案を含むのがよい。これには,信頼性,保守性及び保守支援の判明し

ている課題,提案する問題解決策とそれがディペンダビリティに関する諸要求事項を完全に満足して

いるかについての記述を含むのがよい。

d

)

供給者の提案書は,管理面の提案を含むのがよい。これには方法,プロジェクト  マイルストーン,主

要管理点及びスケジュールの記述を含む。

e

)

供給者の提案書は,財務上の提案を含むのがよい。

f

)

供給者の提案書は,提案する教育訓練の種類と,取得,供給,開発,運用及び保守に関するすべての

プロセスのために教育訓練された要員の提供並びに維持との関連を記述した教育訓練に関する提案を

含むのがよい。

5.2.3

契約

供給者は,ソフトウェア製品又はサービスを供給するために取得者と契約を結ぶのがよい。ソフトウェ

ア製品又はサービスのディペンダビリティに関する諸要求事項は,5.1.3 に規定するように定義するのがよ

い。

5.2.4

計画立案

供給者は,計画立案要求に基づき計画を立案し文書化することが望ましい。計画の諸項目と例とは,包

括的なプロジェクト管理計画の下に考慮することが望ましい。これらのプロジェクト管理計画立案の諸項

目はクリティカルな項目であり,システムの信頼性,保守性及び保守支援に影響を与える。

プロジェクト管理計画で考慮すべき計画立案項目を次に示す。

a

)

プロジェクト管理計画立案−プロジェクト組織構成,責任及び権限−(プロジェクト管理計画)

b

)

開 発 , 運 用 又 は 保 守 に 関 す る 技 術 環 境 − [ シ ス テ ム 技 術 管 理 計 画  (SEMP: System Engineering

Management Plan)

,ソフトウェア開発計画−(SDP: Software Development Plan)]

c

)

ソフトウェア製品,サービス,資源,ソフトウェア規模などを含む作業構成明細など (WBS: Work

Breakdown Structure)


14

C 5750-4-2

:2008

d

)

ソフトウェア製品の品質特性の管理−(ソフトウェア品質保証計画)

e

)

信頼性成長試験,ソフトウェア  ストレステストなどを含む信頼性プログラム−(信頼性プログラム計

画)

f

)

故障モード・影響及び致命度解析,フォールトの切分け及び単一故障−ソフトウェア故障モード・影

響及び致命度解析 (FMECA)

g

)

安全性,  セキュリティ及び他のクリティカルな要求事項の管理−(ソフトウェア安全性プログラム計

画,コンピュータ  セキュリティ計画)

h

)

外部委託先(二次契約者)管理計画

i

)

適合確認及び妥当性確認の方法及び担当部門

j

)

リスク管理,これには,潜在的な技術的,コスト的及びスケジュール上のリスクを含む−(リスク管

理計画)

k

)

要員教育訓練−(教育訓練計画)

5.2.5

実施及び管理

供給者は,次に示すディペンダビリティに関するアクティビティの実施とその管理とを考慮することが

望ましい。

a

)

供給者は,5.2.4 に規定するプロジェクト管理計画を導入し実施するのがよい。

b

)

供給者がソフトウェア製品を開発する場合,5.3 に規定するディペンダビリティに関するアクティビテ

ィを実施するのがよい。

c

)

供給者がソフトウェア外部委託先(契約者)を使用する場合,供給者自身が外部委託先からソフトウ

ェアを取得するとき取得者として振る舞うことになる。そのために,ソフトウェア外部委託先に関し

て,供給者は 5.1 に規定するディペンダビリティに関するアクティビティを実施することが重要であ

る。

d

)

供給者がソフトウェア製品又はサービスを運用する場合,5.4 に規定するディペンダビリティに関する

アクティビティを実施するのがよい。

e

)

供給者がソフトウェア製品を保守する場合,5.5 に規定するディペンダビリティに関するアクティビテ

ィを実施するのがよい。

f

)

供給者がソフトウェア製品を支援している場合には,規定するアベイラビリティの水準を維持するた

めに必要な支援サービス又は規定する要求事項の結果若しくは要求事項に対する解決手法であるもの

を明確化するのがよい。供給者は,提供するそのような支援サービスの結果として発生する追加のコ

ストについて,取得者に助言するのがよい。

g

)

この管理領域は,ディペンダビリティに関する要求事項の進ちょく(捗)

,技術的性能の向上,これら

の関連するコスト並びにプロジェクト状況のスケジュール及び報告の監視と管理を含むことが望まし

い。例としては,信頼性及び保守性の側面について技術的性能の尺度 (TPM: Technical Performance

Measurements)

を追跡することがある。ここでは,ディペンダビリティ機能,記録,解析及び解決に

関連する問題の明確化を含めることが望ましい。

5.2.6

レビュー及び評価

ソフトウェア製品の信頼性,保守性及び保守支援の側面をレビューし評価することは重要な支援ライフ

サイクル  プロセスのアクティビティである。

関連する支援ライフサイクル  プロセスは,

文書化プロセス,

構成管理プロセス,品質保証プロセス,適合確認プロセス,妥当性確認プロセス,共同レビュー  プロセス,

監査プロセス及び問題解決プロセスを含む。供給者の組織は,プロセスが存在し機能していることを確実


15

C 5750-4-2

:2008

にする責任がある。レビュー及び評価のアクティビティは,供給者又は取得者の管理とそれらのアクティ

ビティが連動しているか否かに依存して,それぞれ内部的又は外部的である。支援ライフサイクル  プロセ

スは,取得,供給,開発,運用及び保守プロセスのすべての側面を支援し,結果として,達成する信頼性,

保守性及び保守支援水準に間接的ではあるが大きな貢献をする。そのために取得者は,信頼性,保守性及

び保守支援に直接関連するレビュー及び評価と同様に,すべてのレビュー及び評価のアクティビティに関

心をもつのがよい。

考慮するレビュー及び評価のアクティビティには,次に示すものがある。

a

)

供給者は,プロジェクト計画に規定するレビュー及び評価のアクティビティを実施し,契約に規定さ

れているか又は取得者から要求がある場合に,文書化した結果を取得者に通知するのがよい。これに

は,内部及び外部レビュー並びに評価のアクティビティを含むのがよい。レビュー及び評価の結果が

取得者に通知するように規定されていない場合にも,常に文書化して取得者の要求に応じられるよう

にしておくのがよい。

b

)

レビューのアクティビティは,ディペンダビリティに関する要求事項に対する特定の参照を含むのが

よい。

c

)

ディペンダビリティに関する要求事項又は特定の規格若しくは規制を満足していることが,取得者に

実証されるのがよい。大部分の場合には,大規模システムに対して,供給業者はディペンダビリティ

に関する要求事項を満足していることを実証するのに時間を必要とする。信頼性成長プログラムは,

長い期間にわたって実証し又は評価する手段を提供する。

5.2.7

納入及び完了

取得者は,ソフトウェア製品又はサービスが納入される前に,すべての規定された又は契約されたソフ

トウェアに関連するアクティビティが完了し,相互に受入れ可能な状態まで達成できたことを確実にする

のがよい。例えば,信頼性成長プログラムの完了又は合意した計画についてプログラムの継続を含むこと

がある。

製品の完了及び納入時に供給業者が考慮するべき,ソフトウェアに関連するアクティビティには次に示

すものがある。

a

)

供給業者は,契約に規定されたソフトウェア製品又はサービスを納入するのがよい。これらは,5.2.1

5.2.6 に規定する供給プロセスのディペンダビリティに関するアクティビティの主題である。

b

)

供給業者は,5.5 に規定するディペンダビリティに関するアクティビティに従って納入したソフトウェ

ア製品を支援するのがよい。

5.3

開発プロセス

開発プロセスは,開発者とソフトウェア製品とを定義し開発する組織のアクティビティを記述する。取

得者が供給者にソフトウェア製品の開発を要求する場合には,開発プロセス(JIS X 0160 参照)のすべて

の関連するアクティビティ及び支援ライフサイクル  プロセスが実施されることが重要である。特に,支援

ライフサイクル  プロセス(5.2.6 参照)のレビュー及び評価のアクティビティは,開発中のソフトウェア

製品のディペンダビリティ性能に直接の影響を与えるので,供給者によって実施されるのがよい。供給者

によって使用される技術の種類とソフトウェア  ツールとは,

供給者が繰返し可能で制御された開発プロセ

スを達成することを手助けすることによって,ディペンダビリティ性能に影響する。

ソフトウェア設計手法は,開発中のソフトウェア製品に適切であると認定された業界標準(例えば,オ

ブジェクト指向設計)であるのがよい。これはうまく構成された設計の見通しを高めるものである。技術

の種類は,現代的で,かつ,使用される設計手法に適しているのがよい。この例として,効率的で有効な


16

C 5750-4-2

:2008

グループ作業を可能にするネットワーク化されたワークステーションがある。普及しているソフトウェア

ツールは業界標準であり,認知された供給者によって支援するのがよい。この例が,ソフトウェア改版の

効率的な管理を可能とする,

設計手法又は構成管理及びデータベース  ツールに適合した高水準言語コンパ

イラなどである。

最新の精巧な技術の使用は,リスクの要素を伴うことになる。それゆえに,リスクを継続的に識別し,

順位付けし,監視し,管理し,追跡する手法を推奨する。

ソフトウェア開発者のアクティビティには,プロトタイプ化,モデル化及びシミュレーションの使用を

含むことが望ましい。これらの実践は,利用者の要求を定義し,明確にし,そしてシステムの実用性に関

する実施及び利用者とのインタフェースについての考えを妥当性確認するために,ときどき必要である。

開発プロセスの多くの様相は,ソフトウェア製品のディペンダビリティ性能に影響を与え得る。

次に示すアクティビティを実施することが望ましい。

5.3.1

プロセス開始の準備

プロセス開始の準備アクティビティは,プロジェクトの適用範囲,規模及び複雑さに応じて適切なソフ

トウェア  ライフサイクル  モデルを定義し,

又は選択する。

開発プロセスのアクティビティ及びタスクは,

選択されたライフサイクル  モデル及び実施される開発プロセスのアクティビティを実施可能にするため

に開発者によって選択された適切なツール,手法,ソフトウェア言語及び規格類を用いて企画される。そ

のため,適切なライフサイクル  モデルの選択は,5.3.2 以降で記述されるライフサイクル  プロセス及び関

連するディペンダビリティ活動の最も効果的な実施のために重要である。

次に示す事項が適切なプロセス開始の準備アクティビティの選択を助ける。

a

)

ソフトウェア  ライフサイクル段階におけるソフトウェア  ライフサイクル  プロセスの全体的構成に

関する情報は,JIS C 5750-3-6 を参照する。

b

)

開発者がディペンダビリティ  プログラム(JIS C 5750-2 参照)をもっている場合には,ソフトウェア

製品の開発プロセスは文書化され,ディペンダビリティ  プログラムにおいて参照されるのがよい。さ

らに詳しい情報は,JIS C 5750-3-6 を参照する。

5.3.2

システム要求分析

システム要求分析の目的は,機能の正確で一貫性のある仕様を作成し,ディペンダビリティ要求はこの

分析に明確に含まれるのがよい。次に示すシステム要求分析アクティビティが,考慮されることが望まし

い。

a

)

開発されるシステム全体のディペンダビリティ要求は,信頼性,保守性及び保守支援,並びにソフト

ウェアのすべてに関連している,明確化された各々のディペンダビリティに関する機能要素に基づい

て分析される。次に示すディペンダビリティに関する諸機能要素を,必要に応じて,明確化するのが

よい。

−  ソフトウェア製品及び関連するハードウェアにおけるフォールトの検出とその処置に関連する事項

−  オンライン及びオフラインのバックアップ機能又は支援機能の定期的なテスト実施に関連する事項

−  ソフトウェア製品の保守の可能に関する事項

−  保守支援に関連する事項

−  ソフトウェア製品に依存するアベイラビリティを規定する事項

−  ソフトウェア製品のテスト可能性を規定する事項

−  文書化に関連する事項

−  ディペンダビリティに関する規制又は標準に関連する事項


17

C 5750-4-2

:2008

−  認定テスト実施に関連する事項

−  ソフトウェア製品の運用に関連する事項

−  ソフトウェア製品のスタートアップ及びシャットダウンに関連する事項

−  利用者支援に関連する事項

b

)

各々の明確化されたディペンダビリティ事項は,正確で一貫性のある用語で規定するのがよい。各々

の事項が規定される精度は,ソフトウェア製品の種類及びその応用に依存する。

c

)

照合確認は,ディペンダビリティ機能仕様が各々の明確化された事項が関連する仕様をもつことを確

実にすることによって,完了するのがよい。

d

)

すべての該当する規制又はディペンダビリティ規格は,関連システムを含むシステム全体の分析及び

ディペンダビリティ機能仕様に関連する要求事項の分析時に考慮するのがよい。

5.3.3

システム  アーキテクチャ設計

全体のシステム  アーキテクチャを考慮するときには,ディペンダビリティ機能(5.3.2 参照)として明

確化されたディペンダビリティ性能要求事項が考慮される。設計基準はアベイラビリティ性能及び保守性

性能の質的な側面に関係する。また,その設計基準は,単一フォールトで製品がクリティカル状態になら

ないように設計すべきか否かなど,量的なディペンダビリティ要求事項を補い得るものである。そのため

に,システムの最上位レベルでのアーキテクチャ設計においては,できれば運用及び保守に対する記録を

立証していて,また,同時に明確化されたディペンダビリティ機能に適する既知の確立又は立証されたシ

ステム設計を考慮することが望ましい。信頼性成長プログラムを利用できる場合には,その結果は,特有

のシステム  アーキテクチャの適合性の確認に役立つことがある。

既存の製品がシステムに含まれる場合,最上位レベルでのアーキテクチャ設計は,システムの計画され

たライフサイクルでのベンダによる更新の結果として起こる設計上の不安定さ又はその既存製品のアベイ

ラビリティに影響される結果リスクを考慮することが望ましい。

5.3.4

ソフトウェア要求分析

ソフトウェア要求分析の目的は,ソフトウェアの各モジュール又はアイテムに対する機能の正確で完全

な一貫性のある仕様を作成することである。ディペンダビリティ要求は,この分析に明確に含まれるのが

よい。

ソフトウェア要求分析は,次に示す項目を含むことが望ましい。

a

)

開発されるソフトウェアのディペンダビリティ要求は,信頼性,保守性及び保守支援,並びに明確化

された各ディペンダビリティ機能に関して分析するのがよい。

b

)

各々の明確化されたディペンダビリティ機能は,正確で一貫性のある用語で規定するのがよい。各機

能が規定される精度は,ソフトウェア製品及びアプリケーションの種類による。

c

)

照合確認は,ディペンダビリティ機能仕様が各々の明確化された機能が関連する仕様をもつことを確

実にすることによって,完了するのがよい。

d

)

技術的設計要求事項のための仕様は,認定要求事項,該当する標準,アベイラビリティ要求事項及び

保守要求事項を網羅するのがよい。

5.3.5

ソフトウェア  アーキテクチャ設計

ソフトウェア  アーキテクチャを考慮するときには,ディペンダビリティ機能(5.3.2 参照)として明確

化されたディペンダビリティ性能要求事項は,規定されたディペンダビリティ機能に影響を与える設計の

それらの側面を検討することによって考慮することが望ましい。

システム  アーキテクチャ設計に関しては,

ソフトウェア  アーキテクチャ設計は,

明確化されたディペンダビリティ機能に適切な既知又は立証された


18

C 5750-4-2

:2008

設計を取り入れるのがよい。

5.3.6

ソフトウェア詳細設計

ソフトウェア詳細設計は,

前に説明したシステム及びソフトウェアのアーキテクチャに基づくのがよい。

設計手法は,ソフトウェア設計において,次に示す特質に焦点を当てることを容易にするのがよい。

a

)

開発者は,規定されたディペンダビリティ機能の要求事項を明確に反映するソフトウェアの設計を容

易にする適切に文書化され確立されたソフトウェア詳細設計アクティビティを実施できるのがよい。

b

)

設計は,モジュラリティ,保守性,テスト可能性,適合確認及び妥当性確認のような特質に力を注ぐ

ことを容易にするのがよい。

c

)

ソフトウェア開発プロセスの各段階における設計入出力データは,プロジェクトのレビューに使用す

るために記録,分析,文書化され,そして製品設計の改善を助けるのがよい。

d

)

設計変更管理及びレビューの手順は,規定し,実施するのがよい(IEC 61160 参照)

e

)

設計の適合確認プロセスは文書化し,実施するのがよい。

f

)

確立された設計手法及び開発ツールは,明確化されたディペンダビリティ機能において規定されたモ

ジュール間の情報の流れの表現,データ構造及び従属関係を容易にするものを使用するのがよい。

g

)

利用者が用いる文書は,ソフトウェアと連係して要求されたとおりに開発及び更新するのがよい。そ

れはソフトウェアの改版レベルと一致しているのがよい。

5.3.7

ソフトウェア  コーディング及びテスト

言語コンパイラ,構成管理ツール及び自動テストツールのような統合ツールの適切なセットは,ソフト

ウェア開発期間を通して使用するのがよい。ツールのセットの選択は,定評のあるソフトウェア製造業者

によって十分に支援されることが立証されている製品がよい。

次に示すコーディング及びテストのアクティビティを,考慮することが望ましい。

a

)

開発者は,よいプログラミングの実践と文書化を規定する十分に文書化され,確立されたソフトウェ

アのコーディング及びテスト手順をもつのがよい。

b

)

ソフトウェア製品のテスト及び妥当性確認に対する手順は,文書化され,是正処置の手順を含むのが

よい。ディペンダビリティ要求事項が規定されている場合には,テストは,これらの要求事項に直接

に関係する事項を含むのがよい。

c

)

ソフトウェア不良を報告し,その後の是正を追跡するために,十分に文書化され,調整された手順が

存在するのがよい。要求されたソフトウェア機能のアベイラビリティに影響する,いかなるソフトウ

ェア不良も迅速,かつ,効率的に是正されることを確実にするために,この手順は十分に確立され,

効率的に実施されることが,ソフトウェア  ディペンダビリティのために重要である。フォールトの種

類の分析を提供するために,開発者は,ソフトウェア不良発見報告及び追跡プログラムによって収集

されたデータ,

発生頻度及び構成アイテム当たりのフォールト  パターン又は信頼度成長を示すために

用いられるものをも使用することができる。

5.3.8

ソフトウェア統合

ソフトウェア統合では,すべての確認されたディペンダビリティ機能が正しく実施されることを明確に

テストするのがよい。テストでは,規定されたディペンダビリティ機能を働かせるために関連する構成要

素が正しく相互に作用することを実証するのがよい。

統合テストの結果は監査可能な形式で示すのがよい。

ソフトウェア統合,システム  テスト及び導入の手続を完全に文書化するのがよい。

5.3.9

ソフトウェア認定テスト

特定の定量的又は定性的なディペンダビリティ認定目標が要求仕様として規定されている場合には,こ


19

C 5750-4-2

:2008

れらは規定されたディペンダビリティ機能及び関連のある統合テストに含まれるのがよい。ディペンダビ

リティ固有の特性のため,システムが使用状態にある場合,又は,最も適切な環境での継続した試行期間

中において,ソフトウェア認定テストを一定期間にわたって行うことを,供給者と取得者との間で相互に

合意することがある。これらの認定テストの結果は,規定された認定目標と適合しているか監査するのが

よい。

考慮されるソフトウェア認定テストの側面は,次に示す項目である。

a

)

開発者はいかなる特定のディペンダビリティ認定要求事項に従っても認定テストを行うのがよい。

b

)

開発者は,テスト網羅性といかなるディペンダビリティ要求事項との適合をも評価するのがよい。

c

)

認定テストが規定されたディペンダビリティ認定要求事項に正確に関連付けられていることとともに,

認定テストに対してどのような変更が提案されたとしても,要求されているディペンダビリティ認定

目標との関連の正確さについての妥協のないことを確実にするために,いかなる特定の認定テストで

も,技術的レビュー,内部監査及び変更管理レビューからなる完全なプログラムがあるのがよい。

5.3.10

システム統合

システムとは,ハードウェア製品及びソフトウェア製品の最終的な運用組合せを表現するのに用いる言

葉である。システム統合は,ハードウェア製品及びソフトウェア製品の統合を伴う。統合システムのディ

ペンダビリティ性能はテストされて,全体的な定量的及び定性的なディペンダビリティ要求事項と照合さ

れる。したがって,システムの信頼性性能及び保守性性能はテストされ,明確化されたディペンダビリテ

ィ機能との適合性を確認するのがよい。

システム統合は,次に示すアクティビティを含むことが望ましい。

a

)

システム統合及びテストの手順は完全に文書化するのがよい。

b

)

システム統合テストの結果は,規定されたシステムの定量的及び定性的なディペンダビリティ要求事

項との適合のために,技術レビュー,内部監査及び外部監査の完全なプログラムに任せるのがよい。

5.3.11

システム認定テスト

システム認定テストの目的は,システム統合の後,各システム要求事項への適合性をテストすること,

及びシステム引渡しの準備ができていることを確実にすることである。ディペンダビリティ性能のシステ

ム認定テストは,各々の明確化されたディペンダビリティ機能要求への適合性をテストすることによって

達成することができる。システム  ディペンダビリティ機能要求事項は,各々のディペンダビリティ機能に

よる信頼性保守性の要求事項に関する適合性によって評価されるのがよい。ディペンダビリティ固有の特

性のため,システムが使用されている場合,又は最も適切な環境での継続した試行期間中において,シス

テム認定テストを一定期間にわたって行うことを供給者と取得者との間で相互に合意することがある。全

体的なシステム信頼性が要求事項に適合するかどうかを決定するもう一つの方法は,開発プロセス及びソ

ースコード特性又はそれらのいずれか片方をモデル化する技術によって統合システムのソフトウェア信頼

性を評価することである。管理体制及びデータ収集手順が設定され,得られたデータをそのモデルと組み

合わせて全体的なシステム信頼性の評価を行う。認定テスト結果を用いてディペンダビリティ認定要求事

項と作成された認定報告との適合性を監査するのがよい。システムが要求事項に適合し,協同作業プログ

ラムによって,システムが達成される前に,認定テストの結果がディペンダビリティ性能の改善が必要な

ことを示している場合には,供給者と顧客とは信頼性改善プログラムを開始することに相互に合意するこ

ともある。

システム認定テストのアクティビティは,次に示す項目を含むことが望ましい。

a

)

開発者は,いかなる特定のディペンダビリティ認定要求事項にも従って全体的なシステム認定テスト


20

C 5750-4-2

:2008

を行うのがよい。

b

)

開発者は,テスト網羅性及びいかなる全体的なシステム  ディペンダビリティ要求事項との適合も評価

するのがよい。

5.3.12

ソフトウェア導入

ソフトウェア導入テストはシステム認定テストと密接に結合していて,ソフトウェア製品を提供するた

めの準備ができていることの照合確認の一部となる。ソフトウェアが導入されて動作する条件は,達成さ

れる信頼性性能及び保守性性能に関連する。したがって,導入テストは規定される導入条件で行うのがよ

い。

ソフトウェア導入のアクティビティは,次に示す項目を含むことが望ましい。

a

)

開発者は,

導入文書に従ってソフトウェア製品又はシステムを導入し,

要求されたとおりに導入され,

稼動していることを適合確認するのがよい。ディペンダビリティの固有の特性から,システムが使用

状況にある場合,又は最も適切な環境での継続した試行期間中において,ソフトウェア導入テストを

一定期間にわたって行うことを供給者と取得者との間で相互に合意することもある。

b

)

いかなる規定された導入に関連したディペンダビリティ要求事項との適合も,適合確認して文書化す

るのがよい。

5.3.13

ソフトウェア受入れ支援

ソフトウェア受入れ支援は,取得者がソフトウェア製品の効果的な共同レビュー及び認定テストを実施

できるために重要な開発者のアクティビティである。特に長期間の又は困難を伴うディペンダビリティ要

求適合テストが予想される場合には,受入れテストの支援を開発者が約束するのがよい。

規定されたディペンダビリティ要求事項が実証されるまで,開発者は取得者に対して最初から継続して

適切な支援を提供するのがよい。

5.4

運用プロセス

運用プロセスは,システム又は製品の実環境での運用を行う運用担当者及びその組織のアクティビティ

を規定する。ソフトウェア製品の運用は,システム又は製品の不可欠な部分であるため,このプロセスは

ソフトウェア単独ではなく,システム又は製品を対象とする。運用中のソフトウェアのディペンダビリテ

ィに関する性能は,システム環境内で実施されているソフトウェアの運用と保守手順とに依存する。特定

のディペンダビリティ機能を満たすために必要とされる運用及び保守の手順を明確にし,それらがシステ

ムの運用中に実施されていることを照合確認する行動がなされているのがよい。運用プロセスを構成する

アクティビティは,プロセスの開始の準備,運用テスト,システムの運用及び利用者支援である。ソフト

ウェアの運用と保守手順とは,これらの見出しで考慮されている。

5.4.1

プロセス開始の準備

運用プロセスを実施するために,運用担当者は構成要素であるアクティビティを実施するために行うタ

スクとアクティビティとを計画し,

規定するのがよい。

ディペンダビリティ性能を検討するに当たっては,

その計画に次に示す項目を含めるのがよい。

a

)

運用手順は文書化され,利用者が使えるようにするのがよい。マニュアルは利用者への活発な文書更

新サービスによって,常に最新の内容に維持されるのがよい。

b

)

必要であれば,システム運用の教育訓練を運用担当者に対して行うのがよい。

c

)

システムの運用と保守期間中との顧客の苦情は,文書化された報告手順によって記録を残し,必要に

応じて迅速な是正処置のための分析を行うのがよい。

d

)

特定のディペンダビリティ機能を満たすために必要な定常的作業,例えば,バックアップ又はデータ


21

C 5750-4-2

:2008

の初期化及び立上げ若しくは停止の作業を規定する運用プロセスの手順を定義するのがよい。

e

)

ソフトウェア  アクティビティの適用範囲が規定されているのがよい。

f

)

ソフトウェアは運用環境下でどのようにテストされることが望ましいか,及びテスト結果が保守作業

又は実施中の信頼性成長プログラムにどのようにかかわるかを規定する運用プロセスの手順が定義さ

れているのがよい。開発者が運用テストの方法を規定している場合は,テスト結果をソフトウェア製

品が実運用に入れる準備ができているかどうかの評価と関係付けるのがよい。

5.4.2

運用テスト

運用テストは,システム又はソフトウェア製品が実運用にそれをリリースするための基準に適合してい

るかを照合確認するために行われる。運用に関するディペンダビリティを考慮する場合には,システム又

はソフトウェア製品に求められる信頼性性能と保守性性能とを検討する。

信頼性及び保守への要求事項は,

ディペンダビリティ機能の観点から規定されている(5.3.2 参照)

。運用テストは,規定のシステムのディ

ペンダビリティ機能要求事項に合致するかを照合確認するために行われるのがよい。

運用テストのアクティビティは,次に示す項目を含むことが望ましい。

a

)

システムのディペンダビリティの評価にはデータの収集,適切なソフトウェア信頼性評価技法の選択,

及び規定のシステムのディペンダビリティ機能要求事項と評価したディペンダビリティとを比較する

仕組みを確立することが求められる。特定のディペンダビリティに関する標準又は規制に適合するた

めの要求事項があれば,これらは,システム  ディペンダビリティ機能要求事項に網羅されているのが

よい。

注記  適切なデータ収集方法及び信頼性評価技法の選定,すなわち,収集したデータを処理するた

めの適切な製品又は信頼性モデルの選定の詳細は,BS 5760-8 に規定している。

b

)

システムを運用する環境及び使用方法によっては,

システム  ソフトウェアの信頼性を評価できる前に,

長期にわたってデータを収集することが必要となることがある。供給者と取得者とは,データ収集に

必要な期間を,相互に合意することが望ましい。定量的なディペンダビリティ要求事項に対して,シ

ステムを規定し,テストをすることが不可能な場合には,供給者と取得者とはディペンダビリティの

目標を達成するために,ソフトウェア製品の初期の定性的信頼性評価で納入し,その後,長期間にわ

たるデータ収集と信頼性成長プログラムの実施とを条件にして相互に合意することがある。

c

)

利用者への納入後のシステムのディペンダビリティ性能は運用担当者の運用手順の間違い又は抜けに

よっても影響を受ける。システムの信頼性に関連するいかなる変化も識別でき,運用手順を改善でき

るように,運用手順の変更を記録するのがよい。

5.4.3

システム運用

システム運用のアクティビティは,利用者の文書によって意図された環境下でのシステムの運用として

規定される。したがって,システムが稼動することになっており,かつ,システムがどのように運用され

なければならないかを利用者文書が,正確に規定する環境を定義するそれらのディペンダビリティ機能要

求事項との適合性を照合確認する配慮がされているのがよい。

推奨されるシステム運用アクティビティの確認項目を,次に示す。

a

)

保守支援アクティビティの種類と頻度とを規定する,ディペンダビリティ機能への適合性の照合確認

が行われるのがよい。ディペンダビリティ又はアベイラビリティに重大な影響を与える可能性のある

典型的な保守支援アクティビティには,定期的なシステム  データのバックアップ,最新版レベルへの

ソフトウェアのシステム化された更新又は製品のハードウェアの定期的保守がある。これらの照合確

認の目的は,システムの故障時に最小の寸断期間で復元できるような,定期的なバックアップが行わ


22

C 5750-4-2

:2008

れる十分に保守されたハードウェア上で,エラーが是正されている最新のソフトウェアの版によって

運用されるように,あらかじめ決められた保守機能が実施されているかを確実にすることである。バ

ックアップのような保守アクティビティは,例えば,システムがオフライン状態であったり,運用担

当者又はシステムのアクティビティが最小であるときなど,システム運用におけるリスクが最小とな

るときに行うのがよい。

b

)

不正確な,不完全な,又は使いにくい文書は,運用担当者の間違い又はシステムの運用故障を引き起

こす可能性があるので,利用者の文書は正確性,完全性及び運用担当者の使いやすさについて照合確

認するのがよい。可能であれば,文書の各節について,そこに明記されている運用機能の監査が供給

者によって行われ,間違い及び抜けが記録されるのがよい。どのような是正処置も報告書によって,

結果は取得者に報告するのがよい。

c

)

システムが利用者に納入される前に利用者文書の間違い又は抜けを識別することは不可能なことがあ

る。そのために,システム信頼性に関連のあるいかなる変化も認識し,運用手順が改善できるように,

納入後の運用手順の変更は記録しておくのがよい。

5.4.4

利用者支援

利用者支援アクティビティは,利用者への援助及び助言を提供し,保守プロセスへの利用者要求のフィ

ードバック又は問題の報告を提供する供給者の諸タスクとして規定する(5.5 参照)

。利用者支援アクティ

ビティは,例えば,利用者が支援を求めたときに迅速で専門的な助言をしたり,利用者の問題報告をソフ

トウェア開発及び更新プロセスへ効果的なフィードバック  プロセスをもたらすことによって,

ソフトウェ

ア製品のアベイラビリティ性能及びディペンダビリティ性能に顕著な効果を生じることがある。利用者支

援アクティビティは,次に示すタスクを含むのがよい。

a

)

供給者は利用者からの支援要求に対して,迅速で効果的な応答ができるように,よく組織された専門

的な支援サービスを提供するのがよい。支援サービスは,支援の依頼に対する電話での応答又はこの

サービスが利用者と供給者との間で協議されていれば,現場での援助が適当な時期に提供できるのが

よい。

b

)

供給者は,特定の要求がある場合,

ディペンダビリティ機能の分析結果の提供に相互に合意があれば,

定時外のソフトウェア支援サービスも提供する用意をしておくのがよい。

c

)

供給者は,利用者から問題報告又は追加拡張要求を受け取ったり,問題解決策を作り出したり,結果

として生じるソフトウェアの更新を利用者のシステムに実施するために,十分に規定され,立証され

た手順をもっているのがよい。

d

)

可能であれば,製品機能の情報をより効率的に自分自身でアクセスして利用者が製品のディペンダビ

リティ性能を向上できる仕組みを,供給者は利用者に提供するのがよい。供給者が保守する知識デー

タベースへ,利用者がインターネット又はファクシミリ経由でアクセスするなどはこの一例である。

e

)

供給者は,分析並びに開発及び保守プロセスへのフィードバックのために,すべての支援内容を記録

するのがよい。信頼性成長プログラムがある場合,支援内容の分析結果が,このプログラムに含まれ

ているのがよい。

f

)

供給者は,利用者からの特定の依頼によるか,又は供給者の行う要求事項の評価によるかのいずれか

によって,システム運用に関する完全な利用者教育訓練プログラムを提供するのがよい。特定のディ

ペンダビリティ機能及び性能要求が,運用担当者が行う危険を及ぼす重大な処置を含む場合,供給者

は現場で更に継続的な利用者教育訓練を提供するのがよい。

5.5

保守プロセス


23

C 5750-4-2

:2008

保守プロセスは,ソフトウェア保守担当者のアクティビティとタスクとを規定する。ディペンダビリテ

ィの影響要因は,信頼性,保守性及び保守支援と規定されており,したがって,保守プロセスのアクティ

ビティとタスクとの正確な実施は,

ソフトウェア  ディペンダビリティの達成にクリティカルな影響をもっ

ている。保守プロセスのアクティビティは,プロセス開始の準備,問題把握並びに変更処理及び修正の分

析,変更処理又は修正の実施,保守レビュー及び受入れ,移行並びにソフトウェア廃棄である。

これらのアクティビティのそれぞれは,次に続く細分箇条においてディペンダビリティの観点から考慮

される。すべての特定された保守要求事項を満たすためのアクティビティ及び照合確認,それらによって

多くの費用の発生が見込まれるが,主眼点はこれらを実施することの重要性におかれる。ソフトウェア  デ

ィペンダビリティに対するそれらの強い影響から考えて,

保守プロセス  アクティビティがより多くの費用

の発生を伴うという特性から,それらを実施する割合を減らさないことが重要である。

5.5.1

プロセス開始の準備

プロセス開始の準備のアクティビティは,

保守担当者に 5.5.25.5.6 に規定する保守プロセスのアクティ

ビティを実施するための手順を開発立案,文書化,及び実施できるようにするタスクから構成する。供給

者は,利用者からの問題報告と修正要求との受理,記録,追跡及び利用者にその状況を提供するための文

書化された手順一式が適切に整えてあることを確実にするのがよい。供給者は,システムアベイラビリテ

ィ及びディペンダビリティとソフトウェア問題の効率的な報告及び是正との間に直接の関係があるので,

文書化し手順が利用者と供給者との双方によって実施されることを確実にするのがよい。

このアクティビティのディペンダビリティの側面を考慮する場合,これらの要求事項を網羅するディペ

ンダビリティ機能は,運用テスト(5.4.2 参照)の一部として満足されていることの識別及び照合確認をす

るのがよい。システム保守担当者が文書化された手順を確実に実施するため,必要であれば,プロセス開

始の準備のタスクにシステム保守担当者の教育訓練が含まれる。

5.5.2

問題把握並びに変更及び修正の分析

問題把握並びに変更及び修正の分析のアクティビティは,変更及び修正の量,変更及び修正の費用,変

更及び修正の時間に関するシステム上の影響,及び性能上の効果に対する問題報告又は修正要求の分析か

ら構成される。ソフトウェアのディペンダビリティを考慮する場合,ディペンダビリティ性能に対する問

題報告並びに変更及び修正要求の影響は,特定されたディペンダビリティ機能の各々に対する影響を判断

して考慮するのがよい。供給者は,当初のディペンダビリティ機能の要求事項を満たすことを照合確認す

るのがよい。

分析結果とディペンダビリティ機能の要求事項との適合性を達成したものとの間に矛盾がある場合には,

変更及び修正の実施に取りかかる前に合意及び承認があるのがよい。

保守担当者は,各々の問題報告又は修正要求,分析結果,及び分析結果から開発立案した実施の選択肢

を文書化するのがよい。開発者が信頼性成長プログラムをもっている場合は,分析結果はそのプログラム

に含めるのがよい。

5.5.3

変更及び修正の実施

変更及び修正実施のアクティビティは,変更及び修正が必要とされる文書並びに関連するソフトウェア

アイテムを決定するための分析,更にそれに引き続く特定された変更及び修正の実施,変更及び修正され

たソフトウェアと文書アイテムのテスト並びに評価から構成される。開発プロセス及びすべてのその関連

アクティビティ(5.3 参照)は,変更され,修正されるソフトウェア  アイテムの製作のために使用するの

がよい。ソフトウェア  ディペンダビリティについて考慮すべきことは,修正されるソフトウェア  アイテ

ムに関連するディペンダビリティ機能が,開発プロセスのそれぞれのアクティビティのための規定に合わ


24

C 5750-4-2

:2008

せ同じような方法で検討されるのがよいという点では,開発プロセス(5.3 参照)のために規定することと

同様である。

レビューの目的は,当初のディペンダビリティ機能の要求事項及び何らかの改訂されたディペンダビリ

ティ機能の要求事項との適合性が達成されていることを決定するためであるのがよい。したがって,開発

者は次に示す項目について実施するのがよい。

a

)

要求された機能向上又は変更及び修正が,ディペンダビリティ機能の仕様書に対して関連する修正を

必要とするかどうかを決める。

b

)

いかなる変更及び修正においても,ディペンダビリティの機能仕様書に応じて作られたという観点か

ら,システム及びソフトウェア設計をレビューする。

c

)

要求された機能向上又は変更修正に照らして,ディペンダビリティ要求仕様書をレビューする。

d

)

開発者の確立した手順及びツール(5.3.7 参照)を使用して,ソフトウェア  コーディングの変更を実

施しテストする。

e

)

いかなる変更及び修正済みのディペンダビリティ機能又は認定の目標が正しく実施されていること,

及びいかなる変更及び修正もないディペンダビリティ機能に影響のないことを照合確認するために,

ソフトウェアの統合,認定並びに導入テストを実施する。

5.5.4

保守レビュー及び受入れ

保守レビュー及び受入れのアクティビティは,変更及び修正されたシステムの完全性を決定し,変更及

び修正の完了の承認を得るため保守担当者によって実施される。ソフトウェアのディペンダビリティを考

慮する場合,システム完全性の評価は,システム統合,認定,及び導入テストの期間中に,変更修正済み

及び変更修正のないディペンダビリティ機能要求事項の両方に適合することによる。したがって,ディペ

ンダビリティ機能の適合性のための統合,認定,及び導入テスト結果のレビューは,変更及び修正の実施

に関するアクティビティのタスクの完了(5.5.3 参照)に引き続いて実施されるのがよい。適合性の受入れ

可能水準が達成されている場合には,変更及び修正が契約仕様に従って完了したということを証明する承

認が保守担当者に与えられて差し支えない。

5.5.5

移行

移行アクティビティは,システム又はソフトウェア製品及びその当該データを以前の運用環境から新し

い運用環境に移行する場合に,実施するのがよいタスクを規定する。

ソフトウェアのディペンダビリティを考慮する場合,保守担当者はディペンダビリティ機能への移行ア

クティビティのタスクの影響を考慮するのがよい。

考慮されることが望ましい移行タスクのアクティビティの例を,次に示す。

a

)

何らかのソフトウェア製品又はデータが,システム又はソフトウェア製品の移行期間の間に製作され

たか修正された場合,その製作及びディペンダビリティ機能に関する考慮は,問題把握並びに変更及

び修正の分析(5.5.2 参照)

,変更及び修正の実施(5.5.3 参照)

,並びに保守レビュー及び受入れ(5.5.4

参照)について規定するアクティビティとタスクの規定と同じであるのがよい。全体の目的は,ディ

ペンダビリティ機能の適合性について,統合,認定及び導入のテスト結果を照合確認するためである

のがよい。

b

)

移行計画は,開発立案され,文書化され,そして実施されるのがよい。移行要求事項の分析を行う場

合,ディペンダビリティ機能の要求事項は,この分析及び作成されたディペンダビリティ機能の要求

仕様書に含まれるのがよい。移行の実施を計画する場合,移行期間中に満たされるべき特定のシステ

ム  アベイラビリティ要求事項があるなら,これは利用者と協力して行われるのがよい。


25

C 5750-4-2

:2008

c

)

利用者は,いつ,なぜその移行が行われ,新しい環境へ移行後の元の環境に対する支援水準に関して,

十分な情報を与えられることが重要である。

保守担当者は,利用者が新しい環境に移行せず,そして保守担当者によって提供された保守支援機

能に変更があるようなら,

利用者がシステム  アベイラビリティに関して潜在的な影響を評価できるよ

うにするため,利用者が以前の環境の支援水準に関するあらゆる変更を十分に知らされ,理解してい

ることを保守担当者が確実にするのがよい。

5.5.6

ソフトウェア廃棄

ソフトウェア廃棄のアクティビティは,システム又はソフトウェア製品がソフトウェア製品の所有者の

要請で運用及び保守の組織によって実施中の支援が停止される場合に,実施するのがよいタスクを規定す

る。ディペンダビリティの主要な寄与要因は,保守支援である。したがって,運用及び保守の組織は,実

施中の支援の停止が及ぼすソフトウェア  ディペンダビリティ機能の要求事項への影響を考慮に入れるの

がよい。

運用及び保守の組織は,実施中の支援の停止のための廃棄計画を開発立案し,文書化するのがよい。実

施中の支援停止のためのタイムスケールは,規定された保守支援機能が,ソフトウェア製品が廃棄される

か又は利用者が入れ替えソフトウェア製品に移行するかまで,いずれでも適切であれば継続的に維持され

るようなことを,利用者と保守担当者との間で相互に合意されるのがよい。利用者は,廃棄計画の中に廃

棄するソフトウェア製品,文書及びデータの保管を含めるのがよい。

6

支援ソフトウェア  ライフサイクル  プロセスにおけるディペンダビリティに関する諸活動

支援ライフサイクル  プロセスは八つのプロセスからなる。支援プロセスは,それぞれが明確な目的をも

ち,他のプロセスの活動の不可欠な一部として働き,ソフトウェア  プロジェクトの成功及び品質に貢献す

る。支援プロセスは,必要に応じて他のプロセスによって使用され,実施される。この規格の主な重点は,

主ライフサイクル  プロセスにおけるディペンダビリティの達成であるため,

支援プロセスは総括的に議論

する。支援プロセスは,そのもち合わせている支援機能で主プロセスの効力に貢献することによってディ

ペンダビリティに寄与している。支援ソフトウェア  ライフサイクル  プロセスは,文書化,構成管理,品

質保証,適合確認,妥当性確認,共同レビュー,監査及び問題解決の各プロセスを含む。各プロセスは,

そのディペンダビリティを含めて,それぞれ明確な目的を供給し,プロジェクトの成功及び品質に貢献す

る。

信頼できるソフトウェアの達成を助けるために,

次の支援プロセス  アクティビティを実施するのがよい。

a

)

ライフサイクル  プロセスが作り出す情報は文書化し,文書化プロセスに規定する規格として維持する

のがよい。ディペンダビリティ機能仕様書を含む,適切に計画し,設計し,開発し,製作し,配布し,

維持する文書は,主プロセスの効率的な実施のために絶対に必要である。

b

)

構成管理は,各製品のリリースに対してベースラインとなるソフトウェア構成の管理のために実施す

るのがよい。これは,特にソフトウェアの変更及びリリースの管理を維持するために重要なプロセス

であり,

したがって,

ディペンダビリティの保守性及び保守支援の側面において貢献することになる。

c

)

共同レビュー,監査及び問題解決プロセス  アクティビティは,ソフトウェア  プロジェクトの品質保

証プロセス  アクティビティと合わせて,

すべてのソフトウェア  ライフサイクル  プロセスの不可欠な

部分を構成するのがよい。これらの支援プロセスは,ディペンダビリティ機能活動の規定するレビュ

ー及び監査を通してディペンダビリティに貢献する。

d

)

適合確認プロセスは,ソフトウェア  ライフサイクル  プロセスに規定する要求事項及び条件に従って


26

C 5750-4-2

:2008

ソフトウェアが作成されてきているかどうかを決め,妥当性確認プロセスは,規定要求事項に従って

ソフトウェアが作成されてきているかどうかを決め,その両者が主プロセス及び支援プロセスによっ

てそのライフサイクルにおけるソフトウェアの向上を成就するのがよい。最終の適合確認及び妥当性

確認は,製品受入計画の一部を構成するのがよい。これらのプロセスは,主プロセスに規定するディ

ペンダビリティ機能仕様書の適合確認及び妥当性確認によってディペンダビリティに貢献する。

7

組織に関するソフトウェア  ライフサイクル  プロセスにおけるディペンダビリティの諸活動

組織に関するソフトウェア  ライフサイクル  プロセスは,

関連するライフサイクル  プロセス及び要員か

らなる基本構造を確立及び実施する組織が使用する。この規格の主な重点は,主ライフサイクル  プロセス

におけるディペンダビリティの達成であるため,組織に関するプロセスは総括的に議論する。組織に関す

るプロセスは,主プロセス及びそれらの支援プロセスの効率的な実施に対して必要な組織を確立すること

によってディペンダビリティに貢献する。

組織に関するライフサイクル  プロセスは,管理,環境整備,改善及び教育訓練の各プロセスを含む。信

頼できるソフトウェアの達成を助けるために,

次の組織に関するプロセス  アクティビティを実施するのが

よい。

a

)

管理プロセス  管理プロセスは,主プロセス及び支援プロセスの製品管理,プロジェクト管理及びタ

スク管理を実施するために用いられるアクティビティ及びタスクを含む。管理プロセス  アクティビテ

ィは,プロジェクト又はプロセスの開始,管理対象の定義,計画立案,実施,管理,レビュー及び終

了の各アクティビティを網羅する。管理プロセスは,明確化されたディペンダビリティ機能を規定,

実施,レビュー,評価及び支援する主プロセス活動の組織及び実施を確立することによってソフトウ

ェア  ディペンダビリティに貢献する。

b

)

環境整備プロセス  環境整備プロセスは,他のすべてのプロセスに必要な環境を構築し,維持する。

環境整備には,ソフトウェアの開発,運用又は保守のためのハードウェア,ソフトウェア,ツール,

技法及び規格を含む。環境整備プロセスは,ソフトウェアの開発者又は供給者が反復でき及び管理さ

れた開発プロセス並びに保守プロセスを達成することができるソフトウェアのツール及び技法を確立

し維持することによってソフトウェア  ディペンダビリティに貢献する。

c

)

改善プロセス  改善プロセスは,ソフトウェア  ライフサイクル  プロセスを確立,評価,測定,制御

及び改善するためのプロセスである。そのプロセス  アクティビティは,主プロセス及び支援プロセス

を実施するために必要な組織に関するプロセス一式を確立し,プロセスが効果的であり続けることを

確実にするために評価メカニズムを設立し,また,評価の結果として必要と考えられる改善を実施す

る。改善プロセスは,信頼性成長プログラムに対する評価結果のフィードバックによってソフトウェ

ア  ディペンダビリティに貢献することができる。さらに,一般的な見地からは,開発プロセス及び保

守プロセスの有効性についての改善が,特定のディペンダビリティ機能のより効果的な仕様書作成,

実施,レビュー,評価及び支援に間接的に貢献することになる。改善プロセス又はプロセスの認定は,

ライフサイクルにおけるプロセスの有効性を評価するために用いることができる。

d

)

教育訓練プロセス  教育訓練プロセスは,取得,供給,開発,運用及び保守プロセスのために教育訓

練された要員を提供し,維持する。上記のプロセス  アクティビティ及びタスクの効果的で効率的な実

施は,知識豊富で技能に優れた要員と教育訓練の材料・資料がソフトウェア製品のライフサイクルに

おいて及びライフサイクル  プロセスのすべてに対して適用可能であることに依存している。

したがっ

て,取得者は,ソフトウェアの供給者がリソース,要員の技能,教育訓練の種類及び水準,教育訓練


27

C 5750-4-2

:2008

の文書化並びに実施スケジュールについてプロジェクト要求事項のレビューに基づいた教育訓練プロ

グラムを計画立案し,実施したことを確認するのがよい。したがって,教育訓練計画は,ソフトウェ

ア製品の供給,運用及び保守に貢献するすべての主ライフサイクル  プロセス  アクティビティ並びに

タスクを網羅するのがよい。また,明確化されたプロセス  アクティビティのために教育訓練された要

員の供給は,

計画されたライフサイクル  アクティビティの各々に要員を配置できるようにプロジェク

ト実施と調整するのがよい。教育訓練計画は,これらの要求事項に適合するようにレビューするのが

よい。

開発プロセスの設計,

コーディング及びテスト  アクティビティが適切に教育訓練された要員によって効

率的に実施される場合は,ソフトウェアの信頼性及び保守性は向上することになる。5.3 に規定するそれら

のアクティビティ及びタスクの教育訓練された要員による効率的な実施は,ディペンダビリティ機能の設

計,コーディング及びテストの実施と関係し,また,信頼できるソフトウェアの達成に重要な貢献をする

ことになる。

開発者及び供給者の要員が保守プロセスのアクティビティ及びタスクを実施するために必要な技能につ

いて教育訓練されている場合は,

保守支援も同様に向上することになる。

運用中の有効な保守支援活動は,

ソフトウェア製品のアベイラビリティ及びディペンダビリティを向上させることになる。

教育訓練された要員による運用プロセスアクティビティの効率的な実施は,運用上のエラーを最小にす

る手助けをすることによって,ディペンダビリティ性能の改善に役立つことになる。


28

C 5750-4-2

:2008

参考文献  JIS C 5750-1  ディペンダビリティ管理−第 1 部:ディペンダビリティプログラム管理

注記  対応国際規格:IEC 60300-1:1995,Dependability management−Part 1: Dependability

programme management (IDT)

JIS X 0129

:1994

  ソフトウェア製品の評価−品質特性及びその利用要領

注記  対応国際規格:ISO/IEC 9126:1991,Software engineering−Product quality (IDT)

JIS X 0129-1

:2003

  ソフトウェア製品の品質−第 1 部:品質モデル

注記  対応国際規格:ISO/IEC 9126-1:2001,Software engineering−Product quality−Part 1:

Quality model (IDT)

JIS X 0133-1

:1999

  ソフトウェア製品の評価−第 1 部:全体的概観

注記  対 応 国 際 規 格 : ISO/IEC 14598-1:1999 , Information technology − Software product

evaluation

−Part 1: General overview(IDT)

JIS X 0134

  システム及びソフトウェアに課せられたリスク抑制の完全性水準

注記  対 応 国 際規 格: ISO/IEC 15026:1998,Information technology− System and software

integrity levels (IDT)

BS 5760 : Part 8 

:1998

,Guide to the assessment of reliability of systems containing software

ISO 9000-3 

:1997

,Quality management and quality assurance standards−Part 3: Guidelines for the

application of ISO 9001:1994 to the development, supply installation and maintenance of computer

software

注記 1  この規格は 2000 年に廃止され,ISO/IEC 90003 (2004,Ed.1)  に置き換えられている。

注記 2  ISO/IEC 90003 (2004,Ed.1),Software engineering−Guidelines for the application of ISO

9001:2000 to computer software


29

C 5750-4-2

:2008

附属書 A

参考)

ディペンダビリティ  プログラム要素及び

タスクとソフトウェア  ライフサイクル  プロセスとの関係

序文

この附属書は,本体に関連した事柄を説明するもので,規定の一部ではない。

ソフトウェア  ライフサイクル  プロセス

主ライフサイクル  プロセス

(JIS X 0160) 

ディペンダビリティ  プログラム要素及びタスク

(JIS C 5750-2) 

5.1

取得プロセス 6.2

契約レビューと相互連絡

6.5

外注品及び顧客支給品

5.2

供給プロセス 6.2

契約レビューと相互連絡

5.3

開発プロセス 6.3

ディペンダビリティ要求事項

6.4

適用技術

6.6

解析,予測及びデザインレビュー

6.7

検証,妥当性確認及び試験

6.8

ライフサイクル  コスト  プログラム

5.4

運用プロセス 6.9

運用及び保全の支援計画

5.5

保守プロセス 6.10

改善及び変更

 6.11

運用実績のフィードバック

支援ライフサイクル  プロセス 

6.1

文書化プロセス 6.11 運用実績のフィードバック

ディペンダビリティの履歴

1)

6.2

構成管理プロセス 6.1.4

構成管理

6.3

品質保証プロセス

品質システム

2)

6.4

検証プロセス 6.7 検証,妥当性確認及び試験

6.5

妥当性確認プロセス 6.7 検証,妥当性確認及び試験

6.6

共同レビュープロセス 6.6.8

公式デザイン  レビュー

6.7

監査プロセス

品質システム

2)

6.8

問題解決プロセス

マネジメント  レビュー

2)

ディペンダビリティ  プログラムのレビュー

2)

組織に関するライフサイクル  プロセス 

7.1

管理プロセス

ディペンダビリティの方針

2)

ディペンダビリティ管理の実施

1)

7.2

環境整備プロセス

組織

2)

7.3

改善プロセス

品質システム

2)

7.4

教育訓練プロセス

ディペンダビリティ管理の実施

1)

1)

  JIS C 5750-1

に従うプロジェクトに一般的な要素

2)

  JIS C 5750-1

に従うディペンダビリティ管理要素


30

C 5750-4-2

:2008

附属書 B

参考)

主ソフトウェア  ライフサイクル  プロセスと利用者との相互作用

序文

この附属書は,本体に関連する事柄を補足するもので,規定の一部ではない。

取得者

供給者

開発者

運用担当者

保守担当者

取得プロセス

取得アクティビティを遂

作業指示書を評価

交渉及び契約に署名

要求事項の仕様が運用担
当者の必要性に適合して
いることを確実にする。

供給プロセス

供給者との契約に署名,

供給者のアクティビティ
を監視

供給アクティビティを遂

開発プロセス

認定試験に立会い

開発手順の実施をレビュ

開発アクティビティを遂

運用プロセス

運用システムの性能をレ
ビュー

運用手順を規定

運用アクティビティを遂

保守プロセス

取得者のために保守支援

を提供

保守しやすいソフトウェ

アを製作(すなわち,よ
い コ ー ド 構 造 及 び 文 書
化)

バージョンの管理遂行及

び運用担当者のための教
育訓練の更新

保守アクティビティを遂

30

C

 5750-4-2


2008


31

C 5750-4-2

:2008

附属書 JA

参考)

JIS

と対応する国際規格との対比表

JIS C 5750-4-2:2008

  ディペンダビリティ管理−第 4-2 部:適用の指針−ソフトウェア

ライフサイクル  プロセスにおけるソフトウェア  ディペンダビリティ

IEC 61713:2000

, Software dependability through the software life-cycle

processes

−Application guide

(

Ⅰ)JIS の規定

(

Ⅱ)

国際 
規格

番号

(

Ⅲ)国際規格の規定

(

Ⅳ)JIS と国際規格との技術的差異の

箇条ごとの評価及びその内容

(

Ⅴ)JIS と国際規格との技術的差

異の理由及び今後の対策

箇条番号及び名称

内容

箇条

番号

内容

箇条ごと

の評価

技術的差異の内容

3

用語及び定義 43 個の用語を定義

3 43

個の用語を

定義

変更

ISO 8402

の引用を ISO 

9000

に置き換える。

3.27

(品質保証)の用語

の定義を ISO 9000 の定

義に変更。

3.41

(妥当性確認)の定

義を ISO 9000 の定義に

変更。

3.42

[適合確認(検証)

の 用 語 の 定 義 を ISO 

9000

の定義に変更。

対応規格が廃止され,ISO 9000 

置き換わる。 
用語“品質保証”の定義を,ISO 

8402

の廃止に伴い,ISO 9000 

定義 3.2.11 に置き換える。 
用語“妥当性確認”の定義を,ISO 

8402

の廃止に伴い,ISO 9000 

定義 3.8.5 に置き換える。 
用語“適合確認(検証)”の定義
を,ISO 8402 の廃止に伴い,ISO 

9000

の定義 3.8.4 に置き換える。

JIS

と国際規格との対応の程度の全体評価:IEC 61713:2000,MOD

注記 1  箇条ごとの評価欄の用語の意味は,次による。

−  変更  国際規格の規定内容を変更している。

注記 2  JIS と国際規格との対応の程度の全体評価欄の記号の意味は,次による。

−  MOD  国際規格を修正している。

31

C

 5750-4-2


2008