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

                                                                                             43
                                                      T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
− 危険状態を引き起こし得る全ての故障について,イベント及びその移行を伴う既定状態の定義
− 変数の初期化,メモリ管理
− リスクコントロール手段に影響し得るコールド及びウォームリセット,待機並びに他の状態変化。
B.5.5 ソフトウェアユニットの実装
  このアクティビティは,製造業者がソフトウェアユニットのコードを作成し,検証することを要求する。
詳細設計は,ソースコードに変換される。コーディングは,仕様の分解が終了し,実行可能なソフトウェ
アの組立を開始する時点を表す。望ましいコード特性を一貫して実現するために,コーディング規約にお
いて,適切なコーディングスタイルを規定することが望ましい。コーディング規約の例としては,分かり
やすさ,言語使用法又は制限,複雑性管理などに対する要求事項がある。各ユニットのコードは,詳細設
計の定義どおりに機能すること,及び規定したコーディング規約に準拠することを確実にするために検証
される。
  5.5.5は,製造業者がコードを検証することを要求している。コードが正確に設計を実装していない場合,
医療機器ソフトウェアは,意図したとおりに機能しない。
B.5.6 ソフトウェア結合及び結合試験
  このアクティビティは,製造業者が,ソフトウェアアイテムをソフトウェアアイテムの上位集合体に結
合することに加え,ソフトウェアユニットをソフトウェアアイテムの集合体に結合することを計画及び実
施し,結合後のソフトウェアアイテムが意図したとおりに作動するかを検証することを要求している。
  この結合方法は,非繰返し結合から,様々な繰返し結合に及ぶ。アセンブルするソフトウェアアイテム
の特性によって,結合方法が決定される。
  ソフトウェア結合試験では,ソフトウェアアイテム内外のインタフェースを介したデータ転送及び制御
が重点的な対象となっている。外部インタフェースとは,オペレーティングシステムのソフトウェアを含
む他のソフトウェア及び医療機器のハードウェアとのインタフェースである。
  結合試験の厳密さ及び結合試験に関連する文書の詳細レベルは,次のものに見合うことが望ましい。す
なわち,機器に関連するリスク,潜在的に危害を発生させる可能性がある機能に対する機器のソフトウェ
アへの依存度,及び高リスク機器の機能における特定のソフトウェアアイテムの役割である。例えば,全
てのソフトウェアアイテムについて試験を実施することが望ましいが,安全に影響を及ぼすアイテムは,
より直接的,徹底的,かつ,詳細な試験を実施することが望ましい。
  規定どおりに,結合試験によって,インプット及びアウトプット領域の境界におけるプログラムの動作
を実証し,無効なインプット,予期せぬインプット及び特殊なインプットにプログラムが反応することを
確認する。複数のインプットの組合せ又は予期せぬインプットシーケンスが与えられたとき,若しくは規
定したタイミング要求事項の違反が生じたときに,プログラムの実際の動作が明らかになる。計画書の試
験要求事項には,適宜結合試験の一環として実施するホワイトボックス試験を含めることが望ましい。
  ホワイトボックス試験は,グラスボックス,構造,クリアボックス及びオープンボックス試験としても
知られ,試験対象のソフトウェアアイテムの内部動作についての十分な知識を使用して試験データを選択
する試験方法である。ホワイトボックス試験は,ソフトウェアアイテムについての特定の知識を用いてア
ウトプットを調べる試験である。試験者がソフトウェアアイテムの使用目的を知っている場合にだけ,正
確な試験となる。試験者は,ソフトウェアアイテムが意図した目的から逸脱していないかを確認できる。
ホワイトボックス試験は,ソフトウェアアイテムの実装の試験が中心であるため,完全な仕様が実装され
ていることを保証するとは限らない。ブラックボックス試験は,動作,機能,不透明ボックス及びクロー
ズドボックス試験としても知られ,機能仕様の試験が中心であるため,実装のあらゆる部分について試験

――――― [JIS T 2304 pdf 46] ―――――

44
T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
済みであることを保証するとは限らない。このようにブラックボックス試験は,仕様を確認するための試
験であり,仕様の一部が適合していないことを示すことで,仕様漏れによる不具合を検出する。ホワイト
ボックス試験は,実装を確認するための試験であり,実装の一部に誤りがあることを示すことで,動作の
不具合を検出する。医療機器ソフトウェアに対して完全な試験を実施するためには,ブラックボックス試
験及びホワイトボックス試験の両方が要求される可能性がある。
  5.6及び5.7に示す計画書及び試験文書は,特定の開発フェーズ又は進展的(Evolutionary)プロトタイプ
に関連する個別の文書になる可能性がある。これらの文書を結合させて,単独の文書又はひとまとまりの
文書で複数の細分箇条の要求事項を対象とすることも可能である。また,上位のプロジェクト文書に,文
書の全て又は一部を組み入れることも可能である。上位のプロジェクト文書とは,ソフトウェア又はプロ
ジェクトの品質保証計画書,若しくはハードウェア及びソフトウェア試験のあらゆる点に対応した包括的
な試験計画書などである。この場合,様々なプロジェクト文書がどのように各ソフトウェア結合タスクに
関連するかを記載した相互参照表を作成することが望ましい。
  ソフトウェア結合試験は,模擬環境,実際のターゲットハードウェア又は医療機器全体のいずれにおい
ても実施可能である。
  5.6.2は,製造業者が,ソフトウェア結合アクティビティのアウトプットを検証することを要求している。
ソフトウェア結合アクティビティのアウトプットとは,結合したソフトウェアアイテムである。結合した
ソフトウェアアイテムは,医療機器ソフトウェア全体が正確かつ安全に機能するよう適切に機能しなけれ
ばならない。
B.5.7 ソフトウェアシステム試験
  このアクティビティは,製造業者が,ソフトウェアの要求事項を正しく実装していることを検証するこ
とによって,ソフトウェアの機能を検証するよう要求している。
  ソフトウェアシステム試験は,定義した機能が存在することを実証する。この試験によって,ソフトウ
ェアの要求事項に従って構築したプログラムの,機能性及び性能を検証することができる。
  ホワイトボックス手法(B.5.6参照)を用いて,特定の試験の遂行,負荷条件又は故障の誘発,コードの
品質試験範囲の拡大を実現することが望ましいが,ソフトウェアシステム試験では機能試験(ブラックボ
ックス試験)が集中的に行われる。タイプ及び試験段階ごとの試験の体系には柔軟性があるが,要求事項
の網羅性,リスクコントロール,有用性及び試験タイプ(故障,インストール,負荷など)を実証及び文
書化することが望ましい。
  ソフトウェアシステム試験は,結合したソフトウェアを試験するもので,模擬環境,実際のターゲット
ハードウェア又は医療機器全体のいずれにおいても実施可能である。
  ソフトウェアシステムを変更する場合(小さな変更であっても),(個々の変更の試験だけではない)回
帰テストの実施の程度を決めて,意図しない副作用が発生していないことを確実にすることが望ましい。
この回帰テスト(及びソフトウェアシステム試験全体を繰り返して行わない根拠)は,計画し,文書化す
ることが望ましい(B.6.3参照)。
  ソフトウェアシステム試験に対する責任は,分散させてもよく,異なる場所及び組織で実施可能である。
しかし,タスクの実行組織,実行場所,契約関係,コンポーネントの出所又は開発環境にかかわらず,機
器製造業者には,ソフトウェアが意図する使用に対して適切に機能することを徹底する最終責任がある。
  試験中に発見した異常が繰り返し発生する可能性があっても,それを修正しないことが決定されている
場合,リスク分析と関連付けてこの異常を評価し,それが機器の安全性に影響しないことを検証する必要
がある。異常の根本的原因及び兆候を理解し,修正しない根拠を文書化することが望ましい。

――――― [JIS T 2304 pdf 47] ―――――

                                                                                             45
                                                      T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
  5.7.4は,期待した結果が得られたことを確認するために,ソフトウェアシステム試験の結果を評価する
ことを要求している。
B.5.8 システムレベルで使用するためのソフトウェアリリース
  このアクティビティは,製造業者が,リリースする医療機器ソフトウェアのバージョンを文書化し,ど
のように製造したかを明確にするとともに,そのソフトウェアのリリースに当たり適切な手順を踏むこと
を要求している。
  製造業者は,開発プロセスを用いて開発したソフトウェアが,リリースするソフトウェアであることを
証明できることが望ましい。また,製造業者は,ソフトウェア及びその生成に使用したツールを,今後必
要とされる場合に備え,回収可能にしておくことが望ましく,ソフトウェアの損傷又は誤使用が最小限に
抑えられるよう,ソフトウェアを保管,こん(梱)包及び出荷することが望ましい。これらのタスクを適
切に一貫した結果を伴って実施することを確実にするために,定義付けした手順を確立することが望まし
い。
B.6   ソフトウェア保守プロセス
B.6.1 ソフトウェア保守計画の確立
  ソフトウェア保守プロセスは,次の2点でソフトウェア開発プロセスと異なる。
− 製造業者は,緊急の問題に対処して即急に変更を実装するため,完全な形のソフトウェア開発プロセ
    スより小規模のプロセスを用いることが許されている。
− 製造業者は,リリースした製品に関連するソフトウェア問題報告を受けて問題に対処するだけでなく,
    (主に,現場から問題データを収集するために市販後監視の仕組みを施行し,問題についてユーザ及
    び規制当局と連絡をとることによって)法規制に適合させる。
  6.1は,保守計画の中でこれらのプロセスを確立することを要求している。
  このアクティビティは,製造業者が保守アクティビティ及びタスクを実行するための手順を,考案又は
明確にすることを要求している。製造業者は,是正措置を実行し,保守時に変更を管理し,改訂されたソ
フトウェアのリリースを管理することを目的に,ユーザから報告された問題及び要請を文書化して解決す
るとともに,医療機器ソフトウェアの修正を管理することが望ましい。このプロセスは,ある問題を理由
として,又は改善,適合の必要性があるという理由から,医療機器ソフトウェアのコード及び関連文書が
修正される場合に有効となる。その目的は,リリースした医療機器ソフトウェアの完全性を維持しながら
これを修正することにある。このプロセスは,医療機器ソフトウェアのリリース時には想定していなかっ
た環境又はプラットフォームへの移行を含む。この細分箇条に示したアクティビティは,保守プロセス固
有のものではあるが,この規格の他のプロセスを保守プロセスで使用してもよい。
  製造業者は,保守プロセスのアクティビティ及びタスクをどのように実行するかを計画する必要がある。
B.6.2 問題及び修正の分析
  このアクティビティは,製造業者が得たフィードバックの影響について分析し,報告された問題を検証
することを要求し,修正の選択肢の実装について検討,選択及び承認を得ることを要求している。問題及
びその他の変更要請は,医療機器の性能,安全性又は法律上の認可に影響する可能性がある。問題報告に
よる何らかの影響が存在するか,又は問題を是正したり要請内容を実装したりするための修正によって影
響が生じるかを判断するため,分析が必要である。ソフトウェア保守アクティビティの一環として実装す
るソフトウェア変更によって,機器に組み込まれたリスクコントロール手段が誤った形で変更又は修正さ
れないことを,トレース分析又は回帰的分析を通して検証することが非常に重要である。また,修正前に

――――― [JIS T 2304 pdf 48] ―――――

46
T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
は危険状態を引き起こす又はリスクを低減させることのなかったソフトウェアについて,修正が原因で危
険状態が生じる又はリスクが低減されることがないことを検証することも重要である。ソフトウェア修正
で危険状態が生じる又はリスクが低減される可能性がある場合は,ソフトウェアアイテムのソフトウェア
安全クラス分類が変わっている可能性がある。
  ソフトウェア保守(箇条6)とソフトウェア問題解決(箇条9)とを区別することは,重要である。
  ソフトウェア保守プロセスにおいて焦点となるのは,医療機器ソフトウェアリリース後のフィードバッ
クに適切に対処することである。ソフトウェア保守プロセスでは,医療機器の一部として次の事項を徹底
する必要がある。
− 安全に関連する問題報告について対応し,担当の規制当局及び影響を受けるユーザに対して報告をす
    る。
− 医療機器ソフトウェアは,問題の是正及び更なる問題の回避を確実にするために,正式な管理の下で
    修正した後,再確認して再リリースされる。
− 製造業者は,ほかのどの医療機器ソフトウェアが影響を受け得るかを考慮し,適切な処置をする。
  ソフトウェア問題解決において焦点となるのは,次のような包括的マネジメントシステムの運用である。
− 問題報告を分析し,問題が示唆する事柄全てを明確にする。
− 変更の数を決定し,変更による全ての副作用を明確にする。
− リスクマネジメントファイルを含むソフトウェア構成アイテムの一貫性を維持した上で,変更を実装
    する。
− 変更の実装を検証する。
  ソフトウェア保守プロセスでは,ソフトウェア問題解決プロセスを使用する。ソフトウェア保守プロセ
スでは,問題報告についての上層部での決定(問題が存在するか,問題が安全性に重大な影響を与えるか,
どのような変更が必要か,及び変更をいつ実装するか)を扱うとともに,ソフトウェア問題解決プロセス
を用いて問題報告分析を行い,引き起こされると思われる内容を全て検出し,変更を要する全ての構成ア
イテム,及び必要な全ての検証工程を明確にする,実行可能な変更要求を作成する。
B.6.3 修正の実装
  このアクティビティでは,製造業者が修正を行う場合に,確立したプロセスを使用することを要求して
いる。保守プロセスを定義していない場合は,適切な開発プロセスタスクを使用して修正できる。さらに,
製造業者は,修正によって当該医療機器ソフトウェアの他の部分に副作用が生じないことを確実にするこ
とが望ましい。医療機器ソフトウェアが新規の開発品として扱われていない場合は,修正が医療機器ソフ
トウェア全体に与える影響を分析する必要がある。回帰的分析及び回帰テストを使用すると,変更によっ
て医療機器ソフトウェアの他の部分に問題が生じていないことを確認できる。回帰的分析では,関連文書
(ソフトウェア要求仕様書,ソフトウェア設計仕様書,ソースコード,試験計画書,テストケース,テス
ト手順など)のレビューに基づいて,変更のもたらす影響を判定し,実施すべき回帰テストを特定する。
回帰テストでは,プログラムがこれまで正しく実行してきたテストケースを再実行し,現在の結果を以前
の結果と比較して,ソフトウェアの変更がもたらす意図しない影響を見出す。医療機器ソフトウェアの修
正対象外の部分は,修正前と同じように機能するかを回帰テストで確認するが,そのテストの量について
根拠付けをする。
B.7   ソフトウェアリスクマネジメントプロセス
  ソフトウェアリスクマネジメントは,医療機器リスクマネジメント全体の一部であり,分離した場合,

――――― [JIS T 2304 pdf 49] ―――――

                                                                                             47
                                                      T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
十分に扱うことはできない。この規格は,JIS T 14971に適合するリスクマネジメントプロセスを使用する
ことを要求している。JIS T 14971で定義しているリスクマネジメントは,特に医療機器の使用に関連する
リスクを効果的に管理するためのフレームワークを扱う。JIS T 14971の一部は,リスク分析で確定した各
ハザードに関連する特定のリスクの管理に関係する。この規格のソフトウェアリスクマネジメントプロセ
スは,リスク分析で危険状態の潜在的な一因とされたソフトウェア又は医療機器のリスクマネジメントに
使用するソフトウェアなどのリスクコントロールに要求事項を追加する。次の二つの理由から,ソフトウ
ェアリスクマネジメントプロセスがこの規格に含まれている。
a) この規格の利用者は,ソフトウェアという責任領域におけるリスクコントロール手段の最低限の要求
    事項を理解する必要がある。
b) この規格に引用規格として示している,一般的なリスクマネジメントを扱う規格JIS T 14971は,ソ
    フトウェアのリスクコントロール及びソフトウェア開発ライフサイクルへのリスクコントロール導入
    について特に扱うものではない。
  ソフトウェアリスクマネジメントは,医療機器リスクマネジメント全体の一部である。ソフトウェアリ
スクマネジメントアクティビティに要求する計画書,手順書及び資料は,一連の個別の文書でも単独の文
書でもよく,この規格の要求事項全てに適合する限りにおいては,医療機器リスクマネジメントのアクテ
ィビティ及び資料と統合させてもよい。
B.7.1 危険状態を引き起こすソフトウェアの分析
  医療機器(device)のリスク分析3) によって,危険状態及び危険状態に対応するリスクコントロール手
段が明確になり,危険状態の確率及び/又は重大さが受容可能なレベルにまで低減することを期待する。
また,リスクコントロール手段を実装することを期待するソフトウェア機能に,リスクコントロール手段
が割り当てられることを期待する。
    注3) 対応国際規格のハザード分析を,リスク分析とした。
  しかし,ソフトウェアアーキテクチャの設計完了までに,全ての機器の危険状態を確定することは期待
できない。アーキテクチャの設計完了時点では,ソフトウェア機能をどのようにソフトウェアコンポーネ
ントの中で実装するかが明らかになり,ソフトウェア機能に割り当てたリスクコントロール手段の実用性
を評価する。その時点で,医療機器のリスク分析3) を改訂して,次の事項を含めることが望ましい。
− 改訂された危険状態
− 改訂されたリスクコントロール手段及びソフトウェア要求事項
− 人的要因に関係した危険状態など,ソフトウェアから生じる新たな危険状態
  ソフトウェアアーキテクチャには,ソフトウェアコンポーネント間で危険な相互作用が起きないように
ソフトウェアコンポーネントを分離する確実な方針を含むのが望ましい。
B.8   ソフトウェア構成管理プロセス
  ソフトウェア構成管理プロセスは,ソフトウェアライフサイクル全般にわたって管理手順及び技術的手
順を適用するプロセスであり,文書を含むシステムにおけるソフトウェアアイテムの識別及び定義,アイ
テムの修正及びリリースの管理,並びにアイテム及び変更要求の状況の文書化及び報告を行う。ソフトウ
ェア構成管理は,ソフトウェアアイテムの再製作,その構成部分の確定及び実施した変更履歴の提供に必
要である。
B.8.1 構成の識別
  このアクティビティは,製造業者がソフトウェア構成アイテム及びそのバージョンを一意に識別するこ

――――― [JIS T 2304 pdf 50] ―――――

次のページ PDF 51