JIS T 2304:2017 医療機器ソフトウェア―ソフトウェアライフサイクルプロセス | ページ 9

38
T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
業者は,ソフトウェアアーキテクチャの設計時に,システムを図B.1のように三つのソフトウェアアイテ
ム,X,W及びZに分割することを決定した。製造業者は,死亡又は重傷を引き起こす可能性のある危険
状態の要因となる全てのソフトウェアシステムを,ソフトウェアアイテムZに分離し,重傷の可能性のな
い危険状態の要因となる,残り全てのソフトウェアシステムをソフトウェアアイテムWに分離できる。ソ
フトウェアアイテムWは,ソフトウェア安全クラスBに分類され,ソフトウェアアイテムZは,ソフト
ウェア安全クラスCに分類される。したがって,ソフトウェアアイテムYは,4.3 d)に従い,クラスCと
して分類する。ソフトウェアシステムも,また,この要求事項に従ってソフトウェア安全クラスCにする。
ソフトウェアアイテムXは,ソフトウェア安全クラスAに分類された。製造業者は,分離の完全性を徹底
するために,ソフトウェアアイテムX及びY並びにW及びZについて,分離の根拠を文書化できる。
  ソフトウェアアイテムX及びYの分離が不可能な場合は,ソフトウェアアイテムXを,ソフトウェア
安全クラスCに分類しなければならない。
B.4.4 レガシーソフトウェア
  4.4は,この規格をレガシーソフトウェアに適用するプロセスを確立する。地域によっては,この規格
の現行版ができる前に設計されたもの(レガシーソフトウェア)であっても,医療機器ソフトウェアの規
制当局の承認を得るために,製造業者が規格への適合性を示さなければならないことがある。この場合,
製造業者は,4.4に規定する方法によって,レガシーソフトウェアが規格に適合していることを示すこと
ができる。
  製造業者は,既に終了した開発ライフサイクルを過去に遡って単独のアクティビティとして文書化を行
っても,製品の使用に伴うリスクの低減にはつながらない,と判断するかもしれない。このプロセスでは,
この規格で定義するアクティビティのどれを実施すればリスクの低減につながるかを特定する。このプロ
セスでは,次を前提事項としている。
− 必要なアクティビティ及びそれに伴う文書化は,可能な限り既存の文書を信頼して,これを活用する。
− 製造業者は,リスクを低減するために,リソースをできるだけ有効活用する。
  このプロセスでは,実行する必要のあるアクティビティを特定し,レガシーソフトウェアを安全に継続
使用するための客観的な証拠を集め,継続使用する根拠をまとめる。
  レガシーソフトウェアを計画的に継続使用することに伴うリスクは,そのソフトウェアをソフトウェア
システムの作成に使用する状況によって変わる。製造業者は,レガシーソフトウェアに関連する医療機器
のハザードを特定し,全て文書化する。
  4.4では,レガシーソフトウェアが製造及び使用されていた期間に得られた,製造後の市場データの総
合的評価が必要となる。製造後データの一般的な情報源としては,次がある。
− 機器に起因する有害事象
− 機器の使用者からのフィードバック
− 製造業者が発見した異常
  ソフトウェアの故障の発生確率を事前に定量的に推定する方法については,意見の一致が得られていな
いが,レガシーソフトウェアについては,ソフトウェアの使用状況と製造後データの評価とに基づいてそ
うした情報が得られるかもしれない。そのような場合に,一連の事象それぞれの確率の定量的推定が可能
であれば,一連の事象全体の発生確率を定量的な値として使用してもよい。定量的に推定できない場合は,
最悪の場合の確率を考えるのが適切であり,ソフトウェアの故障の発生確率は1とするのがよい。
  製造業者は,医療機器システムアーキテクチャ全体においてレガシーソフトウェアをどのように使用す
るかを決定し,リスクアセスメントのインプットとする。考慮すべきリスクは,それによって変わる。

――――― [JIS T 2304 pdf 41] ―――――

                                                                                             39
                                                      T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
− レガシーソフトウェアが安全,かつ,確実に使用されていて,その継続使用を製造業者が希望する場
    合,継続使用の根拠は,主に製造後の記録に基づくリスクアセスメントによる。
− レガシーソフトウェアを再利用して新しいソフトウェアシステムを作成する場合,レガシーソフトウ
    ェアの意図する使用が当初のものと異なることがある。この場合,レガシーソフトウェアの故障に起
    因する危険状態を見直して,リスクアセスメントで考慮しなければならない。
− 再利用するレガシーソフトウェアが新しいソフトウェアシステムに結合されている場合でも,同様の
    意図する使用に用いていることがあるかもしれない。この場合は,5.3に従って,アーキテクチャ上の
    リスクコントロール手段を修正して,リスクアセスメントで考慮するのがよい。
  レガシーソフトウェアを変更して新しいソフトウェアシステムで使用する場合,製造業者は,これまで
安全で確実に使用されていたことの記録が,変更によってどの程度無効になるか検討するのが望ましい。
  レガシーソフトウェアの変更は,リスクコントロール手段への影響の評価(7.4)を含め,この規格の箇
条4箇条9に従って実施するのがよい。レガシーソフトウェアの場合は,既存のリスクコントロール手
段が完全に文書化されていない可能性があり,使用可能な設計記録文書に加えて,システムについて知識
をもつ個人の専門知識を活用して,変更がもたらす潜在的影響を慎重に評価するのがよい。
  製造業者は,4.4に従ってギャップ分析を実施する。この分析は,使用可能な文書を決定するために行い,
対象文書には,レガシーソフトウェアの開発中に行ったタスクによる客観的証拠を含み,5.2,5.3,5.7及
び箇条7の要求と比較して分析する。ギャップ分析を遂行するための一般的な手順には,次がある。
a) レガシーソフトウェアをバージョン,リビジョン及びその他の手段によって,明確に特定する。
b) 5.2,5.3,5.7及び箇条7で要求する成果物に相当する,既存の成果物を評価する。
c) 使用可能な客観的証拠を評価する。必要な場合,以前適用したソフトウェア開発ライフサイクルモデ
    ルを文書化する。
d)   IS T 14971を考慮して,既存のリスクマネジメント文書が適切であるか評価する。
  製造業者は,実施したギャップ分析を考慮し,不足している成果物を作成して関連アクティビティを実
施することでリスクをどの程度低減できるか評価し,ギャップを解消するためのアクティビティの実施及
び成果物の作成についての計画を立案する。
  リスクの低減においては,箇条5のソフトウェア開発プロセスを適用する利益と,開発履歴を十分知ら
ずにレガシーソフトウェアを修正することで新しい欠陥が生じ,リスクが上昇する可能性とのバランスを
とるのがよい。箇条5の要素の中には,事後に行っても,ほとんど又は全くリスクが低減されないと思わ
れるものもある。例えば,詳細設計及びユニット検証は,主に新しいソフトウェアの開発プロセス,又は
既存のソフトウェアのリファクタリングプロセスにおいてリスクを低減する。目的が計画に明示されず,
ただアクティビティを行うだけでは,文書は作成されてもリスクの低減にはつながらない可能性がある。
  ギャップ解消計画では,少なくとも,不足しているソフトウェアシステム試験の記録に対処する。試験
記録がない又はレガシーソフトウェアを継続使用する根拠の裏付けとして適切でない場合は,ソフトウェ
アシステム要求事項の機能レベルでの作成(5.2)と試験(5.7)とを,ギャップ解消計画に含めるのがよ
い。
  レガシーソフトウェアを継続使用する根拠を示す文書は,リスクアセスメントの過程及びそのソフトウ
ェアを再利用する状況に適したギャップ解消計画を立案する過程で得られた,使用可能な客観的証拠と分
析とに基づいて作成する。
  この根拠は,レガシーソフトウェアについて使用可能な製造後の記録と,プロセスギャップの解消によ
って達成されるリスクコントロール手段とを共に考慮しており,計画した再利用状況におけるレガシーソ

――――― [JIS T 2304 pdf 42] ―――――

40
T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
フトウェアの安全で確実な性能を肯定的に論証するものとなる。
  レガシーソフトウェアを4.4に従って再利用した後は,そのソフトウェアのうち成果物のギャップが残
っている部分が,引き続きレガシーソフトウェアとなる。この部分については,4.4に従って,今後,ま
た,再利用を検討してもよい。レガシーソフトウェアを変更して成果物のギャップを解消する場合は,こ
の規格の箇条4箇条9に従って変更を実施するのがよい。
B.5   ソフトウェア開発プロセス
B.5.1 ソフトウェア開発計画
  このアクティビティの目的は,ソフトウェアに起因するリスクを低減するためのソフトウェア開発タス
クを計画し,開発チームのメンバに手順及び目標を周知し,医療機器ソフトウェアのシステム品質要求事
項に確実に適合することである。
  ソフトウェア開発計画アクティビティでは,タスクを単一の計画書又は複数の計画書で文書化すること
が可能である。製造業者によっては,医療機器ソフトウェア全ての開発に適用する方針及び手順を既に確
立している可能性がある。その場合,計画は,単純に既存の方針及び手順を引用可能である。製造業者に
よっては,各医療機器ソフトウェアの開発に限定した,単一又は複数の計画書を作成する可能性もある。
この場合,固有のアクティビティの内容を詳細に明記し,他は一般手順書を引用する。このほか,単一又
は複数の計画書を,医療機器ソフトウェアそれぞれの開発に合わせて調整する可能性もある。計画は,開
発プロセスを実行するために必要なレベルまで詳細に定義し,リスクに比例したものにすることが望まし
い。例えば,リスクが高いシステム又はアイテムは,開発プロセスをより厳密にする必要があり,タスク
は,より詳細に規定することが望ましい。
  計画とは,繰り返し行うことが望ましいアクティビティであり,開発が進むにつれて,再検討及び更新
することが望ましい。システム及びシステム開発に必要なレベルの取組みについての理解が深まるにつれ
て,計画は,より多くの,より十分な情報を包含したものへと発展できる。例えば,リスクマネジメント
プロセスの実行及びソフトウェアアーキテクチャの開発の結果,システムの当初のソフトウェア安全クラ
ス分類が変わることがある。又はシステムにSOUPを組み入れる決定がなされる可能性もある。開発プロ
セスを適切に管理できるよう,システムについての最新知識,及びシステム又はシステムにおけるアイテ
ムに必要なレベルの厳密さについての最新知識を反映させ,計画を更新することが重要である。
B.5.2 ソフトウェア要求事項分析
  このアクティビティは,製造業者が医療機器ソフトウェアのソフトウェア要求事項を確立,検証するこ
とを要求する。何を構築するべきかの判断,医療機器ソフトウェアが受容できる動作を示しているかの判
断,及び完成した医療機器ソフトウェアが使用可能状態にあることを実証するためには,検証可能な要求
事項の確立が不可欠である。要求事項が要求どおりに実装されていることを実証するためには,要求事項
が正確に実装されているか否かを判断する客観的基準が確立できるような方法で,各要求事項を提示する
ことが望ましい。医療機器(device)のリスクマネジメントプロセスにおいて,特定したリスクを管理す
るためにソフトウェアに要求事項が課されている場合,それらの要求事項をソフトウェア要求事項におい
て明確にすることが望ましい。このとき,リスクコントロール手段を追跡すると,ソフトウェア要求事項
に帰着できるような方法で明確にする。全てのソフトウェア要求事項は,要求事項とソフトウェアシステ
ム試験との間のトレーサビリティが実証できるように明確にすることが望ましい。規制当局の承認に特定
の規制又は規格への適合が求められる場合は,この適合要求事項をソフトウェア要求事項において文書化
することが望ましい。ソフトウェア要求事項が何をソフトウェアに実装するかを定義するため,要求事項

――――― [JIS T 2304 pdf 43] ―――――

                                                                                             41
                                                      T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
分析アクティビティが完成する前に,要求事項を評価することが要求される。
  顧客ニーズ,設計インプット,ソフトウェア要求事項,ソフトウェア機能仕様書及びソフトウェア設計
仕様書の区別には,しばしば混乱が見られる。設計インプットとは,顧客ニーズを解釈して正式に文書化
した医療機器要求事項である。ソフトウェア要求事項とは,顧客ニーズ及び設計インプットに適合するた
めにソフトウェアが果たすべき役割を正式に文書化した仕様書である。ソフトウェア機能仕様書は,ソフ
トウェア要求事項に付随することが多く,要求事項に適合する代替ソフトウェアが数多く存在する可能性
があっても,要求事項に適合するためにソフトウェアが果たすべき役割を詳細に定義する。ソフトウェア
設計仕様書は,ソフトウェアの要求事項及び機能仕様を実装するために,ソフトウェアをどのように設計,
分割するかを定義する。
  従来,ソフトウェア要求事項,機能仕様書及び設計仕様書は,一つ以上の文書のまとまりとして書かれ
てきた。現在はこの情報を共通データベース内のデータアイテムとして捉えることが可能である。各アイ
テムには,その目的とデータベースの他のアイテムとの関連が定義される属性が一つ以上ある。この手法
によって,各対象ユーザ(製造業者,マーケティング担当者,試験者,監査員など)に最適な,様々な情
報の提示及び印刷が可能となり,実装の適切性及びテストケースによる要求事項の試験実施範囲を実証す
るためのトレーサビリティが確保されている。この手法の支援ツールには,リンク機能を用いたHTML文
書のように単純なものから,CASEツール及び要求事項分析ツールのような複雑で高度なものまである。
  システム要求事項プロセスは,この規格の適用範囲外である。しかし,医療機器の機能をソフトウェア
を用いて実装するかは,通常システム設計時に決定する。一部又は全てのシステム要求事項は,ソフトウ
ェアで実装するように割り当てられる。ソフトウェア要求事項分析アクティビティは,システム要求事項
プロセスがソフトウェアに割り当てた要求事項を分析する作業,及び割り当てた要求事項を反映した広範
囲にわたるソフトウェア要求事項を抽出する作業から成る。
  システムの完全性を確実にするために,製造業者は,親システムの要求事項及びソフトウェア要求事項
における非実用性,不整合性又は曖昧性を是正するために,システム要求事項に対する変更及び明確化の
実現を協議できる仕組みを提供することが望ましい。
  システム要求事項及びソフトウェア要求事項の収集及び分析のプロセスは,繰り返し行うことが可能で
ある。この規格は,そのプロセスを厳密に二層に分離させることを要求するものではない。実際には,シ
ステムアーキテクチャ及びソフトウェアアーキテクチャを同時に設計し,それに続いてシステム要求事項
及びソフトウェア要求事項を階層化された形で文書化することが多い。
B.5.3 ソフトウェアアーキテクチャ設計
  このアクティビティは,製造業者がソフトウェアの主要構造コンポーネントを定義し,コンポーネント
の重要な役割,外部に表れるコンポーネントの特性及びその間の関係について特定することを要求してい
る。あるコンポーネントの動作が他のコンポーネントに影響を与える可能性がある場合は,その動作をソ
フトウェアアーキテクチャで説明することが望ましい(5.3.5及びB.4.3参照)。この説明は,ソフトウェア
外部の医療機器のコンポーネントに影響を与え得る動作について特に重要である。アーキテクチャの決定
は,リスクコントロール手段の実装に非常に重要である。他のコンポーネントに影響を与える可能性があ
るコンポーネントの動作を理解(及び文書化)しなければ,システムが安全であることを証明するのは不
可能に近い。ソフトウェア要求事項の正確な実装を確実にするためには,ソフトウェアアーキテクチャが
必要である。ソフトウェアアーキテクチャは,指定したソフトウェアアイテムがソフトウェア要求事項の
全てを実装しない限り,完全とはいえない。ソフトウェアの設計及び実装は,アーキテクチャに依存する
ため,このアクティビティを完了するにはアーキテクチャを検証する。アーキテクチャの検証は通常,技

――――― [JIS T 2304 pdf 44] ―――――

42
T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
術評価によって実施する。
  ソフトウェアアーキテクチャアクティビティでのソフトウェアアイテムのソフトウェア安全クラス分
類は,それに続くソフトウェアプロセスを選択する基準となる。分類の記録は,リスクマネジメントファ
イルの一部として変更管理する。
  引き続いて起こるイベントによっては,分類が無効になる可能性があることも多い。例えば,次のよう
なイベントが該当する。
− システム仕様,ソフトウェア仕様又はアーキテクチャの変更
− リスク分析のエラー,特に予見できないハザードの発見
− 要求事項,特にリスクコントロール手段の実行不可能性の発見
  したがって,ソフトウェアアーキテクチャの設計に続く全てのアクティビティで,ソフトウェアシステ
ム及びソフトウェアアイテムの分類は,再評価することが望ましく,改訂が必要となる可能性もある。結
果,ソフトウェアアイテムの分類が上位クラスに引き上げられることによって見直しが発生し,ソフトウ
ェアアイテムに追加プロセスを適用するに至る可能性がある。ソフトウェア構成管理プロセス(箇条8)
は,全ての必要な見直しを確定し完了させることを確認するために用いる。
B.5.4 ソフトウェア詳細設計
  このアクティビティは,製造業者がアーキテクチャで定義したソフトウェアアイテム及びインタフェー
スをリファインし,ソフトウェアユニット及びそのインタフェースを作成することを要求する。ソフトウ
ェアユニットは,単一の関数又はモジュールとして考えることが多いが,この考え方は,常に適切である
わけではない。この規格では,ソフトウェアユニットを,それ以上小さなアイテムに細分化できないソフ
トウェアアイテムと定義している。ソフトウェアユニットの試験は,ユニット単独で実行できる。製造業
者は,ソフトウェアユニットの詳細レベルを定義することが望ましい。詳細設計によって,アルゴリズム,
データ表記,異なったソフトウェアユニット間のインタフェース及びソフトウェアユニットとデータ構造
との間のインタフェースを定義する。詳細設計は,ソフトウェアのこん(梱)包も考慮する。ソフトウェ
アユニット及びインタフェースの設計については,十分な詳細を定義し,その安全性及び有効性を客観的
に検証できるようにする必要がある。他の要求事項又は設計文書を使用することで客観的な検証を担保で
きる場合もある。詳細設計は,プログラマがその場しのぎの設計を行う必要がないよう,完全であること
が望ましい。詳細設計は,医療機器ソフトウェアのアーキテクチャも考慮しなければならない。
  ソフトウェアアイテムは,少数の新しいソフトウェアアイテムだけが元のソフトウェアアイテムの安全
関連要求事項を実装するように分割可能である。残りのソフトウェアアイテムは,安全関連機能を実装す
ることがなく,下位のソフトウェア安全クラスに再分類できる。しかし,これを実行する決定そのものが
リスクマネジメントプロセスの一環であり,これは,リスクマネジメントファイルで文書化する。
  実装は,詳細設計に依存するため,アクティビティの完了前に詳細設計を検証する必要がある。詳細設
計の検証は,通常,技術評価によって実施する。5.4.4は,製造業者が詳細設計アクティビティのアウトプ
ットを検証することを要求している。設計が,要求事項をどのように実装するかを定義する。設計を検証
することで,設計がソフトウェアアーキテクチャを実装していること,及び設計がソフトウェアアーキテ
クチャと矛盾しないことが保証される。設計に欠陥があれば,コードは要求事項を正確に実装できない。
  製造業者は,安全性にとって重要であると思われる設計特性が設計中に存在する場合は,設計特性を検
証することが望ましい。こうした設計特性の例としては,次のようなものがある。
− 意図したイベント,インプット,アウトプット,インタフェース,論理フロー,CPU負荷の配分,メ
    モリの配分,エラー及び例外の定義並びに分離,エラーからの復帰処理の実装

――――― [JIS T 2304 pdf 45] ―――――

次のページ PDF 46