JIS F 8082:2007 船舶用プログラマブル電子系の開発及び使用に関する一般原則 | ページ 12

54
F 8082 : 2007 (ISO 17894 : 2005)
                          表D.1−PESライフサイクル出力の要件(続き)
      出力                                要件及び内容                                参照
検証計画                                                                         [JIS C 0508-2の
                検証するコンポーネント(ソフトウェア,ハードウェア,データ,訓練,ド
                キュメント等)を特定する。                                       7.5.2及び7.9]
                設計文書と対照したコンポーネントの検証に用いる技術及び手順のステップ
                を定義する。                                                     [ISO 9000-3の
                                                                                 7.3.5,7.4.3及び
                設計文書を参照し,コンポーネントの検証で対照する判定基準を挙げる。
                検証の技術的戦略を定義する。                                     8.1]
                検証に用いる手段と方法を定義する。
                要求される入力データ,期待される出力,その他の合格判定基準を特定する。
                検証スタッフに要求される能力を指定する。
                すべての校正済みツールと装置を含む試験環境を指定する。
                試験評定手順を定義する(正当化)。
                検証中の不良を解決するための手段と手順を定義する。
                各運転モードで検証する安全関連ソフトウェアを特定する。
妥当性確認報告  PESに関するすべての妥当性確認活動の結果を報告する。              [JIS C 0508-2の
書              要求仕様と妥当性確認計画に関する合否決定。                       7.7.2.4]
                使用されている妥当性確認計画のバージョンを記載する。
                試験(又は分析)された安全機能を明記する。                         [IACSの7.1]
                妥当性確認計画における特別な妥当性確認要求を記載する。
                誰が評価を行ったかを記録する。                                   [ISO 9000-3の
                使用したツールと装置を記録する。                                 7.3.6,7.3.7,8.2.4
                使用した校正データを記録する。                                   及び7.5.3]
                各試験の結果を記録する。
                期待される結果と実際の結果の間での不一致を記述する。             [JIS Z 8530]
                妥当性確認中にみつかった不一致に起因する分析と処置を記述する。
                試験手順の適切性の証拠。
                規格と対照した試験では : 
                ― 使用された規格のリストと使用理由
                ― 全体としてのシステムに関する有意義な結果が得られるだけの十分なシ
                   ステムの部分が評価されたことの証拠
                ― すべての大小の不適合,所見,全体的評価の報告
                ― 設計でどのように不適合に対処したかに関する報告
                特別な利用者要求を満たすための規格からの逸脱の妥当化。
                操作性の評定や日常監視では,関連する統計分析を示さなければならない。
検証報告書                                                                       [JIS C 0508-1の
                ライフサイクル局面に関係する検証活動の結果を報告する。検証の結果を記
                載する。                                                         7.18.2.4]
                                                                                 [JIS C 0508-2の
                PESライフサイクル,設計基準,安全管理要件に関する不適合を取り上げる。
                検証活動でのPESの合否又は不合格の理由を記載する。                7.9.2.7]
                関連した検証計画に対して適合性を確認できるように記載する。       [ISO 9000-3の
                PESが検証に合格したかどうかや失敗の理由をはっきりと述べる。      7.3.3,7.3.5,7.3.7,
                                                                                 7.5.3及び7.4.3]
                                                                                 [JIS Z 8530]

――――― [JIS F 8082 pdf 56] ―――――

                                                                                             55
                                                                   F 8082 : 2007 (ISO 17894 : 2005)
                                          附属書E
                                          (参考)
                         ライフサイクルにおける原則の適用
            E.1

序文

  この規格には,信頼性の高いPESの開発と使用を実現するための一連の原則が示されている。PESの耐
用年数全体を通して,すべての原則をシステム全体とそのコンポーネント(構成要素)に適用できる。こ
れらの原則はPESの信頼性要件の包括的なセットであり,判定基準はこれらの要件の重要な属性である。
どのような適用でも,PESのライフサイクルのどの時点においても,各原則の意味と相対的重要性が変わ
ってくる場合がある。この規格を用いる場合,このような解釈を行い,それを関係者と共有することが必
要とされる。この附属書には,この規格の使用に関係する課題,処置,責務が図解され,ライフサイクル
における原則の使用例が示されている。
E.2 ライフサイクル
  システムの設計,開発,使用は,一連の明確に区分された段階であり,“揺りかごから墓場”までのライ
フサイクルに相当すると考えられる。一つ又は複数のタスクを実施する必要性があり,そのためにPESを
利用することが決定されたときに,ライフサイクルが開始される。使用されているシステムがその必要性
を満たさなくなったときや,必要性自体が変化したときに,ライフサイクルが終了する。その後,使用を
継続するためにシステムが修正されて新しいライフサイクルが始まるか,又はシステムが廃棄されること
になる。開始と終了の間に,システムは様々な状態をたどる。理論上の構想であったり最終的な構成部品
の組み立てであったりするが,いずれも目的を同じくするものである。
  図E.1には,システムライフサイクルの“V字形”モデルの簡略版が示されている。このモデルは,附
属書Cの船舶部門に関して詳述されたものである。附属書Cに示されているように,利害関係者は一つ又
は複数のプロセスに対する責任を割り当てられている。オペレータは構想とサービス,システムエンジニ
アは仕様と技術的なリスク管理,システム構築業者は試運転,供給業者は設計と構築に対する責任を負う。
一連のプロセスでそれぞれ前のプロセスに戻るサイクルとV字形を横切って戻るサイクルのあるモデルで
は,反復が暗示されている。二つの主要なサイクル局面がモデルに表示されている。計画局面(構想から
詳細設計まで)は概して文書に関係し,引渡し局面(コンポーネント構築から運用まで)は技術に関係す
る。前者はニーズの浸透を特徴とし,後者は構成部品の統合を特徴としている。計画局面は製品,人,組
織間の融合の確立にも役立つ。適切な統合を達成するためには,ライフサイクル全体を通してこれを維持
していかなければならない。
  計画局面と引渡し局面には対称性がある。引き渡されたシステムは動作概念を反映する。試運転は仕様
プロセスを反映する。技術構築はその設計を反映する。計画局面の欠陥は,ライフサイクルのより後の段
階で明らかになることが多い。例えば,装置の現位修正の必要性が遅延,損失,潜在的運用リスクをもた
らす結果となる。
  引渡し局面における故障(広義の期待動作からの逸脱)は,計画局面の後遺症であることが多い。(ソフ
トウェアの故障は本質的にランダムなものではなく,PESハードウェアの信頼性は向上し続けるため,ラ
ンダムな故障は比較的まれになる)ほとんどの故障は系統的なものであり,内因性の障害から生じ,特定
の状況で発生し,文書(製品)又はその耐用期間を通じた使用(プロセス)に起因するものである。ほと

――――― [JIS F 8082 pdf 57] ―――――

56
F 8082 : 2007 (ISO 17894 : 2005)
んどの技術者は,計画局面について考えるのではなく,技術的解決に重点を置きがちであるが,そのこと
はプロジェクトリスクを生み出すことになる。
  変更に伴うコストやリスクは,故障と故障原因との間隔が離れているほど大きくなる。例えば,仕様プ
ロセスが始まる前の概念の変更は容易であるが,引渡し局面での仕様の変更では大規模な再設計が必要と
されることが多い。技術の変更よりも文書の変更の方が容易である。計画局面の適切な段階における整合
性,完全性,明確性によって,信頼性の高い統合システムの提供と総合的なコスト管理の改善が保証され
る。
                                図E.1−簡略ライフサイクルモデル
E.3 計画局面
  計画局面では,技術を使用しやすくするのに必要な文書が作成される。この局面では,仕様から詳細設
計まで徹底されるように,船主の動作概念が明確に理解されなければならない。文書に遺漏やあいまいさ
があると,PESのコンポーネント間のインタフェースを不明りょう化する想定や解釈がもたらされること
になる。システムが複雑になるほど,システムが含むインタフェースの数が多くなり,不十分な定義によ
る信頼性に対する脅威も増大する。
  仕様段階は,幾つかの個別プロセスから構成される。通常,これには,利害関係者の特定,利害関係者
のニーズの確定,それらを一貫性のある要件に集約すること,引渡し局面で適合を評価するための判定基
準を確立することが含まれる。この規格の原則は,PES信頼性要件の包括的なセットとなっている。また,
これらの原則を用いた評価プログラムが定義されている。
  様々な利害関係者が,その需要と制約によって,直接的(船主)又は間接的(技術供給業者)にプロセ
スに影響を及ぼす。ただし,主要な利害関係者とみなされなければならないのは,見落とされがちな最終
利用者である。利用者その他の重要な利害関係者の軽視は,引渡し局面での大規模な変更の原因となる。
利害関係者の要件の照合と有理化を行い,仕様プロセスに活用すべきである。
  通常,詳細な設計を行う前に,要件の割当てを考慮することが必要とされる。トータルシステムの機能
には,利用者によって最良に実施されるものと,技術によって最良に実施されるものがある。通常,技術
には複数の供給業者が関与し,それぞれが独自のスキルと経験をもっている。個々のタスクと要件を人と
技術に割り当てるシステム構成を定義すべきである。遺漏やあいまいさを最小限に抑えて,設計局面から
引渡し局面まで浸透する,系統的障害を回避すべきである。
  仕様の一般的な欠点として,明確な受入基準の欠如を挙げることができる。受入基準は,定性的なもの
であったり,定量的なものであったりするが,いずれにしても,具体的,測定可能,合意可能,実際的,

――――― [JIS F 8082 pdf 58] ―――――

                                                                                             57
                                                                   F 8082 : 2007 (ISO 17894 : 2005)
時宜を得たものとすべきである。
  プロジェクトの早い段階では,原則を適用するシステムがない。
  この時期には,適切なプロセス規範モデル(ソフトウェアプロセスに関するISO/IEC 12207及びISO/IEC
15504に示されているプロセス評価枠組み等)を用いたプロセス能力測定を,契約締結又はプロセス改善
計画確定の基礎とする場合がある。
  システム又はそのコンポーネントの概念が確定されたらすぐに,製品原則を適用することができる。シ
ステム及びコンポーネントの信頼性要件のチーム検討を製品原則と対照して行うことは,設計で信頼性の
課題に重点を絞り込む便利な方法である。
E.4 引渡し局面
  引渡し局面では,部品[注文品又は市販標準仕様品(COTS)コンポーネント]が統合され,要求され
るタスクに対して実現技術が提供される。この統合は,その組織と物理的環境におけるシステムの使用と
関連したものとなる。COTS製品の統合に要するコストと労力は予測が困難であり(注文製品と比べても
より困難であり),プロジェクト管理における課題となっている。比較的シンプルなソフトウェアであって
も,その徹底的な試験を瞬時に行おうとするのは非現実的である。
  工場受入試験,港湾又は海上試運転に関する船舶分野での一般的慣行は,複雑な技術に障害がないこと
を示すことに実質的には役立たない。最も実際的な解決方法は,開発プロセス全体を通した階層的モジュ
ール設計と検証/妥当性確認試験の系統的計画,及びCOTS製品の慎重な使用にある。機能試験は,指令
のためではなく確認のために役立てるべきである。製品の型式試験は,解決策になる可能性があるが,型
式試験された技術のフレキシビリティのなさは,利用者,組織,環境がそれらの制約に対処しなければな
らない範囲において,人的要素への負担を増大させることになる。費用と利益のバランスをとることが必
要とされるが,これは適切な判断及び理解に基づいたものとすべきである。
  設計,構築,引渡しにおいて,原則は三つの形で適用されると考えられる。第1は,設計意図が達成さ
れるようにするための,製品及び(関連)ライフサイクル原則と対照したコンポーネント開発活動の検討
である。第2は,適切で時宜を得た十分な検証が行われるようにするための,製品原則と対照したコンポ
ーネントの評定である。第3は,適切な妥当性確認が行われるようにするための,製品原則と対照したト
ータルシステムの検討である。
E.5 管理
  プロジェクトの管理によって,この規格の原則適用の成功度が決まってくる。効果的なプロジェクトの
管理の基本となるのは,開かれた意思疎通と協調関係の育成である。あるライフサイクル段階又はプロセ
スから別のライフサイクル段階又はプロセスへの移行では,意思疎通が必要とされるし,おそらくは役割
や責任の変化が生じることになる。通常,個々のプロセスには製品反復が含まれ,従って参加利害関係者
間の継続的な意思疎通が必要とされる。
  システムの動作概念が十分に定義されたら,課せられた制約を考慮に入れて,動作概念を満たし実現技
術を提供する仕様を作成することになる。このタスクを構成する様々なプロセスを計画,編成,監視,制
御することが必要である。そのためには,各パートナーの役割と責任に関する明確な共通理解が必要とさ
れる。この規格のライフサイクル原則によって,高信頼性システムに関するプロセス要件の包括的なセッ
トがもたらされている。
  仕様のプロセスでは,主要な責任がオペレータからシステムエンジニアに移される。従来から,システ

――――― [JIS F 8082 pdf 59] ―――――

58
F 8082 : 2007 (ISO 17894 : 2005)
ムエンジニアの役割は造船所の責任になっている。造船所には,この責任を完全に果たす能力が要求され
る。造船所が責任を様々な供給業者にゆだねる場合には,それらの供給業者にトータルシステムが概念を
満たすものになることを保証できる権限と素質がない限り,これを達成することはできない。供給業者の
役割は,主として,COTS製品の供給である。仕様プロセスと割当プロセスが適切なものである場合だけ
に,これを実現できる。
  システムエンジニアの役割は,管理と技術に深く関与している。そこでは,動作概念(上流)と実現技
術(下流)の両方を理解することが必要とされる。システムエンジニアがインタフェースの適切な管理に
失敗すると,大規模な再設計が必要となる場合がある。
  通常,これには予期せぬ遅延と損失が伴い,修正によって更なるシステム障害の可能性がもたらされる
という点でのリスクがもたらされる。
  プロジェクト管理において,検証と妥当性確認が重要となる。検証が製品のタスクに対する“適切さ”
ではなく製品の“正確さ”を確認するものであるならば,基本的に,この局面を主として指定利害関係者
(例えば,技術供給業者)にゆだねることができる。管理プロセスの一部は,適切な確認が実施されてい
ることを保証するものとなる。例えば,試験記録や関連文書の第三者による監査や審査である。適切な検
証が行われれば,技術の信頼性に対する確信がもたらされ,工場受入試験,港湾や海上試運転等において
インタフェースの検証とトータルシステムの妥当性確認に重点を置くことが可能になる。信頼性を確立す
るためには,妥当性確認も計画・管理されたプロセスとすべきである。
  原則によって,管理のためのツールがもたらされる。当初,これらの原則は,関連するプロセス参照規
格(JIS X 0170,JIS Z 8530及びJIS C 0508等)とともに,PESの信頼性に対する脅威の分析,監視,緩
和のために必要とされる,プロジェクト活動のチェックリストとして使用される。それ以降は,ライフサ
イクル原則と対照したパートナー/プロジェクト活動の時宜を得た検討に関する一連の基本的な課題を提
供するものとなる。これらの検討では,計画局面で特定されたパートナーの能力に起因するプロセスリス
クと引渡し時に浮上するリスクを考慮に入れるべきである。

――――― [JIS F 8082 pdf 60] ―――――

次のページ PDF 61