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

                                                                                             13
                                                      T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
4.4.3  ギャップ分析
  製造業者は,レガシーソフトウェアのソフトウェア安全クラス(4.3参照)に基づいて,5.2,5.3,5.7
及び箇条7の要求事項に対し,使用可能な成果物とのギャップ分析を行う。
a) 製造業者は,使用可能な成果物の継続的有効性を評価する。
b) ギャップが特定された場合,製造業者は,不足する成果物を作成し関連アクティビティを実施するこ
    とによって,リスクをどの程度低減できるか評価する。
c) 製造業者は,この評価に基づいて,作成する成果物と実施する関連アクティビティとを決定する。成
    果物は,少なくともソフトウェアシステム試験記録(5.7.5参照)を含むものとする。
      注記 こうしたギャップ分析によって,レガシーソフトウェアに実装したリスクコントロール手段
            をソフトウェア要求事項に確実に含めることが望ましい。
4.4.4  ギャップ解消アクティビティ
a) 製造業者は,特定した成果物を作成するための計画を確立し実行する。客観的な証拠を利用できる場
    合は,5.2,5.3,5.7及び箇条7で要求するアクティビティを行わずに,その証拠を用いて必要な成果
    物を作成してもよい。
      注記 特定したギャップに対応するための計画は,ソフトウェア保守計画(6.1参照)に含めること
            ができる。
b) この計画では,箇条9に従って発見したレガシーソフトウェア及び成果物の問題に対処するため,問
    題解決プロセスを使用する。
c) レガシーソフトウェアに対する変更は,箇条6に従って実施する。
4.4.5  レガシーソフトウェアを使用する根拠
  製造業者は,レガシーソフトウェアのバージョンとともに,そのソフトウェアを継続使用する根拠を,
4.4のアウトプットに基づいて文書化する。
    注記 4.4を満たしていれば,この規格に従って,レガシーソフトウェアを今後も使用できる。

5 ソフトウェア開発プロセス

5.1 *ソフトウェア開発計画

5.1.1  ソフトウェア開発計画
  製造業者は,開発するソフトウェアシステムの適用範囲,規模及びソフトウェア安全クラス分類に適し
た,ソフトウェア開発プロセスのアクティビティを実施するために,(一つ又は複数の)ソフトウェア開
発計画を確立する。ソフトウェア開発ライフサイクルモデルは,その計画の中に全てを定義するか,又は
引用するかのいずれかとする。計画は,次の事項を扱った内容とする(クラスA,B,C)。
a) ソフトウェアシステムの開発に使用するプロセス(注記4参照)
b) アクティビティ及びタスクの成果物(文書化を含む。)
c) システム要求事項,ソフトウェア要求事項,ソフトウェアシステム試験及びソフトウェアに実装する
    リスクコントロール手段の間のトレーサビリティ
d)   OUP構成アイテム及び開発支援用ソフトウェアを含む,ソフトウェア構成管理及び変更管理
e) ライフサイクルの各段階で発見される医療機器ソフトウェア,成果物及びアクティビティの問題に対
    処するためのソフトウェア問題解決
      注記1 ソフトウェア開発ライフサイクルモデルでは,ソフトウェアシステムの各ソフトウェアア
              イテムの安全クラス分類に従って,異なるソフトウェアアイテムに対し,それぞれ別の要

――――― [JIS T 2304 pdf 16] ―――――

14
T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
              素(プロセス,アクティビティ,タスク及び成果物)を割り付けることができる。
      注記2 これらのアクティビティ及びタスクは,重複するものであっても相互に影響を与え合うも
              のであってもよく,反復的又は循環的に実行してもよい。特定のライフサイクルモデルを
              使用することが望ましいということを意図したものではない。
      注記3 この規格には,開発プロセスと区別して説明している他のプロセスがあるが,それらを別
              のアクティビティ及びタスクとして実装しなければならないということを意味するもので
              はない。それらのプロセスのアクティビティ及びタスクは,開発プロセスに統合できる。
      注記4 ソフトウェア開発計画では,既存のプロセスを引用しても新たにプロセスを定義してもよ
              い。
      注記5 ソフトウェア開発計画は,全体のシステム開発計画に統合してもよい。
5.1.2  ソフトウェア開発計画の継続更新
  製造業者は,開発の進捗に応じて,計画を適宜更新する(クラスA,B,C)。
5.1.3  ソフトウェア開発計画におけるシステム設計及びシステム開発の引用
  (クラスA,B,C)
a) ソフトウェア開発のためのインプットとなるシステム要求事項は,製造業者がソフトウェア開発計画
    の中で引用する。
b) 製造業者は,ソフトウェア開発計画に,4.1に適合するために必要な,ソフトウェア開発とシステム開
    発との整合性をとるための手順(システム結合,検証,妥当性確認など)を示すか又は引用する。
      注記 ソフトウェアシステムがスタンドアロンシステム(ソフトウェア単独)の場合は,ソフトウ
            ェアシステム要求事項とシステム要求事項とに差異がない場合もある。
5.1.4  ソフトウェア開発規格,方法及びツールの計画
  製造業者は,ソフトウェア開発計画書に,クラスCのソフトウェアアイテムの開発に関連する次の項目
を示すか又は引用する(クラスC)。
a) 規格
b) 方法
c) ツール
5.1.5  ソフトウェア結合及び結合試験計画
  製造業者は,ソフトウェアアイテム(SOUPを含む。)を結合して,結合時に試験を実施するための計画
を,ソフトウェア開発計画書に示すか又は引用する(クラスB,C)。
    注記1 結合試験及びソフトウェアシステム試験は,一つの計画及び一連のアクティビティに統合し
            てもよい。
    注記2 5.6参照。
5.1.6  ソフトウェア検証計画
  製造業者は,ソフトウェア開発計画書に,次の検証情報を示すか又は引用する(クラスA,B,C)。
a) 検証が必要な成果物
b) 各ライフサイクルアクティビティに必要な検証タスク
c) 成果物を検証するマイルストーン
d) 成果物検証の合否判定基準
5.1.7  ソフトウェアリスクマネジメント計画
  製造業者は,ソフトウェアリスクマネジメントプロセスのアクティビティ及びタスクの実行計画(SOUP

――――― [JIS T 2304 pdf 17] ―――――

                                                                                             15
                                                      T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
に関連したリスクマネジメントを含む。)を,ソフトウェア開発計画に示すか又は引用する(クラスA,B,
C)。
    注記 箇条7参照。
5.1.8  文書化計画
  製造業者は,ソフトウェア開発ライフサイクルにおいて作成する文書についての情報を,ソフトウェア
開発計画書に示すか又は引用する。記載した文書又は文書のタイプそれぞれについて,次の情報を示すか
又は引用する(クラスA,B,C)。
a) 題名,名称又は命名規則(naming convention)
b) 目的
c) (対応国際規格で削除されている。)
d) 開発,レビュー,承認及び修正のための手順並びに責任
    注記 文書の構成管理については,箇条8を参照する。
5.1.9  ソフトウェア構成管理計画
  製造業者は,ソフトウェア開発計画書に,ソフトウェア構成管理情報を示すか又は引用する。記載又は
引用するソフトウェア構成管理情報とは,次をいう(クラスA,B,C)。
a) 管理対象アイテムのクラス,タイプ,カテゴリ又はリスト
b) ソフトウェア構成管理アクティビティ及びタスク
c) ソフトウェア構成管理アクティビティの実行に責任を負う組織
d) それらの組織と他の組織(例えば,ソフトウェア開発又は保守など)との関係
e) アイテムを構成管理下に置く時期
f)  問題解決プロセスを使用する時期
    注記 箇条8参照。
5.1.10 管理が必要な支援アイテム
  管理対象のアイテムには,医療機器ソフトウェアに影響を及ぼす可能性のある,医療機器ソフトウェア
の開発に使用するツール,アイテム又は設定を含める(クラスB,C)。
    注記1 このようなアイテムの例には,コンパイラ又はアセンブラのバージョン,メイクファイル,
            バッチファイル及び特定の環境設定を含む。
    注記2 箇条8参照。
5.1.11 検証前のソフトウェア構成アイテムのコントロール
  製造業者は,ソフトウェア構成アイテムを,その検証前に,構成管理の管理下に置くように計画する(ク
ラスB,C)。
5.1.12 既知のソフトウェア欠陥の特定及び回避
  製造業者は,ソフトウェア開発計画書に,次の手順を示すか又は引用する(クラスB,C)。
a) ソフトウェアシステムに対して選択したプログラミング技術によって生じる可能性のある欠陥を分類
    するための手順。
b) これらの欠陥が受容できないリスクの一因にならないことを示す証拠を文書化する手順。
    注記 欠陥の分類又は危険状態の一因となる原因の例については,IEC TR 80002-1:2009の附属書B
          を参照する。

――――― [JIS T 2304 pdf 18] ―――――

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

5.2 *ソフトウェア要求事項分析

5.2.1  システム要求事項からのソフトウェア要求事項の定義及び文書化
  製造業者は,医療機器のソフトウェアシステムごとに,システムレベルの要求事項からソフトウェアシ
ステム要求事項を定義して文書化する(クラスA,B,C)。
    注記 ソフトウェアシステムがスタンドアロンシステム(ソフトウェア単独の機器)の場合は,ソフ
          トウェアシステム要求事項とシステム要求事項とに差異がない場合もある。
5.2.2  ソフトウェア要求事項の内容
  製造業者は,医療機器ソフトウェアの要求事項に必要な場合は,次の事項を適宜含める(クラスA,B,
C)。
a) 機能及び能力についての要求事項
      注記1 要求事項の例を,次に示す。
              − 性能(例えば,ソフトウェアの目的,タイミング要求事項)
              − 物理的特性(例えば,コード言語,プラットフォーム,オペレーティングシステム)
              − ソフトウェアの実行環境(例えば,ハードウェア,メモリサイズ,処理ユニット,時
                  間帯の設定,ネットワークインフラストラクチャ)
              − アップグレード,複数のSOUP又は他機器との互換性の必要性
b) ソフトウェアシステムのインプット及びアウトプット
      注記2 要求事項の例を,次に示す。
              − データの型(例えば,数字,英数字,フォーマット)
              − 範囲
              − 制限
              − 既定値
c) ソフトウェアシステムと他のシステムとの間のインタフェース
d) ソフトウェアによる警報,警告及び操作者へのメッセージ
e) セキュリティ要求事項
      注記3 要求事項の例を,次に示す。
              − 機密情報の漏えい(洩)に関連する事項
              − 認証
              − 認可
              − 監査証跡(audit trail)
              − 通信の完全性
              − システムセキュリティ・マルウェアからの保護
f)  ソフトウェアで実装するユーザインタフェースの要求事項
      注記4 要求事項に関連する例を,次に示す。
              − 手動操作の支援
              − 人間と機器との相互作用
              − 人員についての制約
              − 人間の注意を集中する必要がある領域
      注記5 ユーザビリティエンジニアリング要求事項についての情報は,IEC 62366-1 [17]他[例えば,
              IEC 60601-1-6 [16]]に規定している。

――――― [JIS T 2304 pdf 19] ―――――

                                                                                             17
                                                      T 2304 : 2017 (IEC 62304 : 2006,Amd.1 : 2015)
g) データ定義及びデータベース要求事項
      注記6 要求事項の例を,次に示す。
              − 形式
              − 整合性
              − 機能
h) 納入した医療機器ソフトウェアの,操作現場及び保守現場におけるインストール及び受入れの要求事
    項
i)  操作及び保守の方法に関わる要求事項
j)  ITネットワークに関連する要求事項
      注記7 要求事項の例を,次に示す。
              − ネットワーク通信する,アラーム,警告及びオペレータメッセージ
              − ネットワークプロトコル
              − ネットワークサービスが利用できない場合の扱い
k) ユーザ保守要求事項
l)  規制要求事項
      注記8 a)   l)の要求事項は,重複することもある。
    注記9 ソフトウェア開発の初期には,必ずしも,これらの要求事項の全てが利用できるとは限らな
            い。
    注記10 JIS X 25010 [9]は,ソフトウェア要求事項の定義付けに有用な品質特性についての情報を規
            定している。
5.2.3  リスクコントロール手段のソフトウェア要求事項への包含
  製造業者は,ソフトウェアに実装するリスクコントロール手段を,医療機器ソフトウェアの要求事項に
含める(クラスB,C)。
    注記 これらの要求事項は,ソフトウェア開発の初期には利用できないこともあり,ソフトウェアの
          設計及びリスクコントロール手段の追加定義を行うことで変更できる。
5.2.4  医療機器のリスク分析の再評価
  製造業者は,ソフトウェア要求事項が確定した時点で医療機器のリスク分析を再評価し,適宜,更新す
る(クラスA,B,C)。
5.2.5  要求事項の更新
  製造業者は,ソフトウェア要求事項分析アクティビティの結果を受けて,適宜,システム要求事項を含
む既存の要求事項の再評価及び更新を確実に実施する(クラスA,B,C)。
5.2.6  ソフトウェア要求事項の検証
  製造業者は,ソフトウェア要求事項について次の点を検証し文書化する(クラスA,B,C)。
a) システム要求事項(リスクコントロールに関わるものを含む。)を実装している。
b) 相互に矛盾しない。
c) 曖昧さを回避した用語で表現している。
d) 試験基準を確立して,試験が実施できる表現で記載している。
e) 一意に識別できる。
f)  システム要求事項又は他の要求事項を追跡できる。

――――― [JIS T 2304 pdf 20] ―――――

次のページ PDF 21