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

18
T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
    注記 この規格は,形式仕様記述言語の使用を要求するものではない。

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

5.3.1  ソフトウェア要求事項のアーキテクチャへの変換
  製造業者は,医療機器ソフトウェアの要求事項を,文書化したアーキテクチャ(ソフトウェアの構造の
説明及びソフトウェアアイテムの特定をしているもの)に変換する(クラスB,C)。
5.3.2  ソフトウェアアイテムのインタフェース用アーキテクチャの開発
  製造業者は,ソフトウェアアイテムとソフトウェアアイテム外部のコンポーネント(ソフトウェア及び
ハードウェア)との間,及びソフトウェアアイテム間のインタフェースについて,アーキテクチャを開発
し,文書化する(クラスB,C)。
5.3.3  SOUPアイテムの機能及び性能要求事項の指定
  ソフトウェアアイテムをSOUPと特定している場合,製造業者は,そのSOUPアイテムについて,その
意図する使用に必要な機能性能要求事項を明確にする(クラスB,C)。
5.3.4  SOUPアイテムが要求するシステムハードウェア及びシステムソフトウェアの指定
  ソフトウェアアイテムをSOUPと特定している場合,製造業者は,SOUPアイテムの正常な動作に必要
なシステムハードウェア及びシステムソフトウェアを明確にする(クラスB,C)。
    注記 例としては,プロセッサのタイプ及び速度,メモリのタイプ及びサイズ,システムソフトウェ
          アのタイプ,通信及び表示のソフトウェア要求事項などがある。
5.3.5  リスクコントロールに必要な分離の特定
  製造業者は,リスクコントロールに必要なソフトウェアアイテム間の分離を特定し,分離が有効である
ことを確実にする方法について明示する(クラスC)。
    注記 分離の例としては,異なるプロセッサ上でソフトウェアアイテムを実行させることがある。分
          離の効果は,プロセッサ間に共有リソースをもたないことによって保証できる。ソフトウェア
          アーキテクチャの設計(B.4.3参照)によって効果を保証できる場合は,他の分離手段を適用で
          きる。
5.3.6  ソフトウェアアーキテクチャの検証
  製造業者は,次の事項を検証し,文書化する(クラスB,C)。
a) ソフトウェアのアーキテクチャが,リスクコントロールに関わる要求事項を含む,システム及びソフ
    トウェアの要求事項を実装している。
b) ソフトウェアアーキテクチャが,ソフトウェアアイテム間及びソフトウェアアイテムとハードウェア
    との間のインタフェースを支援できる。
c) 医療機器アーキテクチャが,全てのSOUPアイテムの正常な動作を支援している。
    注記 要求事項a)を満たすために,ソフトウェア要求事項に対するアーキテクチャのトレーサビリテ
          ィ分析を行ってもよい。

5.4 *ソフトウェア詳細設計

5.4.1  ソフトウェアのソフトウェアユニットへの分解
  製造業者は,ソフトウェアをソフトウェアユニットに分解する(クラスB,C)。
    注記 ソフトウェアシステムによっては,それ以上分解できないこともある。
5.4.2  ソフトウェアユニットごとの詳細設計の開発
  製造業者は,それぞれのソフトウェアユニットを正しく実装するために,十分な詳細設計をして,文書
化する(クラスC)。

――――― [JIS T 2304 pdf 21] ―――――

                                                                                             19
                                                      T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
5.4.3  インタフェース用詳細設計の開発
  製造業者は,ソフトウェアユニットと外部コンポーネント(ハードウェア又はソフトウェア)との間,
及びソフトウェアユニット間の全てのインタフェースについての設計を文書化する。この文書化は,各ソ
フトウェアユニット及びそのインタフェースを正しく実装するために十分詳細なものとする(クラスC)。
5.4.4  詳細設計の検証
  製造業者は,ソフトウェアの詳細設計が次によることを検証し,文書化する(クラスC)。
a) ソフトウェアアーキテクチャを実装している。
b) ソフトウェアアーキテクチャとの矛盾がない。
    注記 要求事項a)を満たすために,ソフトウェア詳細設計に対するアーキテクチャのトレーサビリテ
          ィ分析を行ってもよい。

5.5 *ソフトウェアユニットの実装

5.5.1  各ソフトウェアユニットの実装
  製造業者は,各ソフトウェアユニットを実装する(クラスA,B,C)。
5.5.2  ソフトウェアユニット検証プロセスの確立
  製造業者は,ソフトウェアユニットを検証するための方針,方法及び手順を確立する。検証を試験によ
って実施する場合は,その試験手順の適切性について評価する(クラスB,C)。
    注記 結合試験及びソフトウェアシステム試験は,一つの計画及び一連のアクティビティに統合して
          もよい。
5.5.3  ソフトウェアユニットの合否判定基準
  製造業者は,より大きなソフトウェアアイテムに結合する前に,必要に応じてソフトウェアユニットの
合否判定基準を確立し,ソフトウェアユニットが合否判定基準を確実に適合するようにする(クラスB,
C)。
    注記 合否判定基準の例を,次に示す。
          − ソフトウェアコードが,リスクコントロール手段を含む要求事項を実装しているか。
          − ソフトウェアコードが,ソフトウェアユニットのインタフェース設計と矛盾しないか。
          − ソフトウェアコードが,プログラミング手順又はコーディング標準に従っているか。
5.5.4  追加のソフトウェアユニット合否判定基準
  設計に当たって,製造業者は,必要に応じて次の事項についての追加の合否判定基準を含める(クラス
C)。
a) 適正なイベントシーケンス
b) データ及び制御フロー
c) 計画したリソース配分
d) 異常処理(エラーの定義,特定及び復帰)
e) 変数の初期化
f)  自己診断
g) メモリ管理及びメモリオーバーフロー
h) 境界条件
5.5.5  ソフトウェアユニットの検証
  製造業者は,ソフトウェアユニットの検証を実行し,結果を文書化する(クラスB,C)。

――――― [JIS T 2304 pdf 22] ―――――

20
T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)

5.6 *ソフトウェア結合及び結合試験

5.6.1  ソフトウェアユニットの結合
  製造業者は,結合計画に従ってソフトウェアユニットを結合する(5.1.5参照)(クラスB,C)。
5.6.2  ソフトウェア結合の検証
  製造業者は,ソフトウェアユニットがソフトウェアアイテム及び/又はソフトウェアシステムに結合さ
れていることを結合計画(5.1.5参照)に従って検証し,検証を行った証拠を記録として保存する(クラス
B,C)。
    注記 ここでは,結合が計画に従って実施されているかについてだけ検証する。この検証は,何らか
          の調査で行うのが望ましい。
5.6.3  ソフトウェア結合試験
  製造業者は,結合計画(5.1.5参照)に従って,結合したソフトウェアアイテムを試験し,結果を文書化
する(クラスB,C)。
5.6.4  ソフトウェア結合試験の内容
  ソフトウェア結合試験では,製造業者は,結合したソフトウェアアイテムが意図したとおりに機能する
かを明確にする(クラスB,C)。
    注記1 考慮することが望ましい事項の例を次に示す。
            − ソフトウェアに要求している機能
            − リスクコントロール手段の実装
            − 指定したタイミング及びその他の動作
            − 内部及び外部インタフェースの指定した機能
            − 予見可能な誤使用を含む異常な条件下での試験
    注記2 結合試験及びソフトウェアシステム試験は,一つの計画及び一連のアクティビティに統合し
            てもよい。
5.6.5  ソフトウェア結合試験手順の評価
  製造業者は,結合試験手順の適切性を評価する(クラスB,C)。
5.6.6  回帰テストの実施
  製造業者は,ソフトウェアアイテムを既存の結合済みソフトウェアに結合する場合,回帰テストを適宜
実施して,結合前にはなかった欠陥が新たに生じていないことを実証する(クラスB,C)。
5.6.7  結合試験記録の内容
  製造業者は,次の事項を実施する(クラスB,C)。
a) 試験結果(合否及び異常箇所のリスト)を文書化する。
b) 試験を再現できるように,十分な記録を保存する。
c) 試験者を明示する。
    注記 要求事項b)は,例えば,次のものを保存することによって行うこともある。
          − 要求される処置及び期待される結果を示すテストケース仕様
          − 装置の記録
          − 試験に使用した,(ソフトウェアツールを含む。)試験環境の記録
5.6.8  ソフトウェア問題解決プロセスの使用
  製造業者は,ソフトウェア結合及び結合試験中に発見した異常を,ソフトウェア問題解決プロセスで処
理する(クラスB,C)。

――――― [JIS T 2304 pdf 23] ―――――

                                                                                             21
                                                      T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
    注記 箇条9参照。

5.7 *ソフトウェアシステム試験

5.7.1  ソフトウェア要求事項についての試験の確立
a) 製造業者は,ソフトウェアシステム試験の実施のために,個々のソフトウェア要求事項を対象として,
    インプット内容,予想する結果,合否判定基準及び手順を定めた一連の試験を確立し,実施する。
b) 製造業者は,検証方針及び試験手順の適切性を評価する。
  (クラスA,B,C)
    注記1 結合試験及びソフトウェアシステム試験は,一つの計画及び一連のアクティビティに統合し
            てもよい。また,ソフトウェア要求事項は,より早い段階で試験してもよい。
    注記2 特に要求事項の間に依存性が存在する場合は,要求事項ごとの個別試験だけでなく,要求事
            項を組み合わせた試験も実施可能である。
5.7.2  ソフトウェア問題解決プロセスの使用
  製造業者は,ソフトウェアシステム試験中に発見した異常を,ソフトウェア問題解決プロセスで処理す
る(クラスA,B,C)。
5.7.3  変更後の再試験
  製造業者は,ソフトウェアシステム試験の実施中に変更があった場合,次の処理をする(クラスA,B,
C)。
a) 必要に応じた試験のやり直し,試験の修正及び実施,又は追加試験の実施によって,変更が問題の訂
    正にどの程度有効かを検証する。
b) 副作用が発生しなかったことを示すための適切な試験を実施する。
c) 7.4で規定する,関連するリスクマネジメントアクティビティを実行する。
5.7.4  ソフトウェアシステム試験の評価
  製造業者は,検証方針及び試験手順の適切性を評価する。
  製造業者は,次の事項を検証する(クラスA,B,C)。
a) 全てのソフトウェア要求事項を対象に,試験又は検証を実施している。
b) ソフトウェア要求事項と試験又は検証との間のトレーサビリティが記録されている。
c) 試験結果が,要求する合否判定基準に適合する。
5.7.5  ソフトウェアシステム試験記録の内容
  試験の再現性を図るために,製造業者は,次の事項を文書化する(クラスA,B,C)。
a) 要求される処置及び期待される結果を示すテストケース手順書への参照表記
b) 試験結果(合否及び異常箇所のリスト)
c) 試験したソフトウェアのバージョン
d) 関連するハードウェア及びソフトウェアテスト構成
e) 関連試験ツール
f)  試験実施日
g) 試験の実施及び試験結果の記録に関わる責任者の識別

5.8 *システムレベルで使用するためのソフトウェアリリース

5.8.1  ソフトウェア検証の完了確認
  製造業者は,全てのソフトウェア検証アクティビティが完了し,結果を評価したことを,ソフトウェア
のリリース前に確認する(クラスA,B,C)。

――――― [JIS T 2304 pdf 24] ―――――

22
T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
5.8.2  既知の残留異常の文書化
  製造業者は,残留している既知の異常を全て文書化する(クラスA,B,C)。
5.8.3  既知の残留異常の評価
  製造業者は,残留している既知の異常を全て評価したことを確認し,受容できないリスクの原因になら
ないことを確実にする(クラスB,C)。
5.8.4  リリースするバージョンの文書化
  製造業者は,リリースする医療機器ソフトウェアのバージョンを文書化する(クラスA,B,C)。
5.8.5  リリースするソフトウェアの作成方法の文書化
  製造業者は,リリースするソフトウェアの作成手順及び作成環境を文書化する(クラスB,C)。
5.8.6  アクティビティ及びタスクの完了確認
  製造業者は,ソフトウェア開発計画(又は保守計画)の全てのアクティビティ及びタスクが,関連する
文書化とともに完了していることを確認する(クラスB,C)。
    注記 5.1.3 b) 参照。
5.8.7  ソフトウェアのアーカイブ
  製造業者は,次について,製造業者自身が決定した医療機器ソフトウェアの耐用期間,又は関連する規
制要求事項が規定する期間の,いずれか長い方を最低保管期間として保管する(クラスA,B,C)。
a) 医療機器ソフトウェア及び構成アイテム
b) 文書
5.8.8  ソフトウェアリリースの信頼性の確保
  製造業者は,リリースする医療機器ソフトウェアが,変造又は無断で変更されることなく使用する場所
に確実に納品されるようにするための手順を確立する。具体的には医療機器ソフトウェアを格納した媒体
の製造及び取扱いについての手順であり,必要に応じて次のものを含める(クラスA,B,C)。
− 複製
− 媒体のラベリング
− こん(梱)包
− 保護
− 保管
− 納品

6 ソフトウェア保守プロセス

6.1 *ソフトウェア保守計画の確立

  製造業者は,保守プロセスのアクティビティ及びタスクを実行するためのソフトウェア保守計画を確立
する。計画の内容は,次による(クラスA,B,C)。
a) 医療機器ソフトウェアのリリース後に発生する情報をフィードバックするための,次の手順
  − 取得
  − 文書化
  − 評価
  − 解決
  − 追跡
b) フィードバックした情報に問題があるかを判断するための基準

――――― [JIS T 2304 pdf 25] ―――――

次のページ PDF 26