こんにちは、イーソル エンジニアリング本部 Medical課のY.Sです。

イーソルは医療機器や顕微鏡・研究向け製品をはじめとした医療・科学分野のエンジニアリングサービスを提供しており、Medical課は医療系のソフトウェア開発に携わっています。

このブログシリーズでは、イーソルで定期的に開催しているIEC 62304理解のための社内勉強会で得た見識について紹介しています。

前回までは、以下の内容を紹介しました。

• 第1回：IEC 62304とは何か、また規格についての基本的な知識や読み方について
• 第2回：IEC 62304で定義されているソフトウェア安全クラス分類、また医療機器ソフトウェア開発のリスクマネジメントプロセスについて

第3回では、医療機器ソフトウェア開発のV字モデルについて取り上げます。

1. 医療機器ソフトウェア開発のV字モデル

医療機器ソフトウェア開発の設計～実装～評価のV字モデルは以下のように表されます。ソフトウェア安全クラスによって、医療機器ソフトウェアで必要となるプロセス及びドキュメントは異なります。
各ソフトウェア安全クラスで必要となるプロセスとドキュメントを以下に示します。
図の中で、青で示されるプロセス及びドキュメントはクラスA、B、Cで、緑で示されるものはクラスB、Cで、橙で示されるものはクラスCで必要です。

図1　医療機器ソフトウェア開発のV字モデル（※画像をクリックすると拡大します）　
　　　　　　　

リスクの高いソフトウェア安全クラスの場合は、より多くのプロセス定義やドキュメントが必要となります。
イーソルでは、薬事法とIEC 62304に準拠したお客様の社内開発プロセスの策定支援を行った経験があったため、その経験をシェアして理解を深めました。

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

ソフトウェア要求事項分析では、システム要求仕様書からソフトウェアシステムの要求事項を定義し、ソフトウェア要求仕様書を作成します。クラスA、B、C、どのクラスにおいてもこのプロセスの整備が必要です。

図2 ソフトウェア要求事項分析

Point：
各ソフトウェア要求事項に対してシステム試験が必要となるため、客観的に検証可能な基準を持てる要求事項を作成することが重要です。例えば、システムへの要求から応答までのリアルタイム性に制限を設ける場合、曖昧に記載するのではなく、具体的な時間を要求事項として定める必要があります。
クラスB、Cでは、ソフトウェアに実装するリスクコントロール手段もソフトウェアシステムの要求事項に含めます。この場合、リスクコントロール手段からソフトウェアシステム要求事項が辿れるように、トレースを取ります。このように、プロセスの成果物同士を紐づけることをトレーサビリティと呼びます。医療機器ソフトウェアのトレーサビリティに関しては、次回で詳しく説明します。

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

ソフトウェアアーキテクチャの設計では、ソフトウェア要求仕様書をアーキテクチャに変換します。また、ソフトウェアアイテム間やソフトウェア外部とのインタフェースの定義を行います。これはクラスB、Cでは公式なプロセス整備が必要となります。

図3 ソフトウェアアーキテクチャの設計

Point：
ソフトウェアアーキテクチャ設計上、リスクの高いソフトウェアアイテムをデータフロー、プロセッサ、メモリ空間等の面から独立させることで、リスクの低いソフトウェアアイテムで障害が起こった場合に重大な危害が発生することを防ぐことができます。
このように、ソフトウェアアーキテクチャの設計はリスクコントロール手段に繋がります。
また、上記のようにソフトウェアアイテム同士が独立している、疎結合のアーキテクチャであることは、ソフトウェア変更の影響が少なくなるメリットもあります。

・ソフトウェア詳細設計

ソフトウェア詳細設計では、ソフトウェアをソフトウェアユニットに分解します。これはクラスB、Cでは公式なプロセス整備が必要となります。また、クラスCでは詳細設計の文書化が必要となります。

図4 ソフトウェア詳細設計

Point：
※ソフトウェアユニットについてはこのブログのシリーズの第2回で説明していますので、そちらをご参照ください。
ソフトウェア安全クラスの分類において、リスクの低いソフトウェアの一部（ソフトウェアユニット）を、下位のクラスに分類することもできます。
その例として、内視鏡光源をクラスC、残る内視鏡システムをクラスBとして開発しているプロジェクトがありました。

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

ソフトウェアを実装します。クラスA、B、C、どのクラスにおいてもこのプロセスの整備が必要です。

図5 ソフトウェアユニットの実装

Point：
ソフトウェア実装時、ソフトウェアの可読性や保守性を高めるため、コーディング規約を設定することが望ましいです。

・ソフトウェアユニットの検証

ソフトウェアユニットの検証を行います。これはクラスB、Cでは公式なプロセス整備が必要となります。

図6 ソフトウェアユニットの検証

Point：
ソフトウェアユニットの合否判定基準が必要です。クラスCの場合、例えば異常処理や境界条件など、合否判定基準を定められなければいけない対象が具体的に示されていますので、それぞれについての合否判定基準を定める必要があります。

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

ソフトウェアユニットを結合し、結合試験計画に従って、結合したソフトウェアの検証を行います。これはクラスB、Cでは公式なプロセス整備が必要となります。

図7 ソフトウェア結合及び結合試験

Point：
ソフトウェア結合時は、SOUP(Software of Unknown Provenance:由来のわからないソフトウェア)を含んだ状態で結合します。
ソフトウェア結合試験では、ソフトウェアアイテムのインタフェースを重点的に検証します。
ソフトウェアが仕様通りに動作するか確認するブラックボックステストだけでなく、ソフトウェアの内部動作や動作なども考慮したホワイトボックステストを行うことが望ましいです。
既存の結合済みソフトウェアに対し、新たにソフトウェアアイテムを結合する場合は、回帰テストが必要となります。

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

各ソフトウェア要求事項を対象としてソフトウェアシステム試験を行います。クラスA、B、C、どのクラスにおいてもこのプロセスの整備が必要です。

図8 ソフトウェアシステム試験

Point：
ソフトウェアに変更が発生した場合、回帰テストが必要となります。
仕様変更の場合、変更した要求仕様に紐づけられた試験、バグ修正の場合、ソフトウェアアイテムに紐づけられた試験を行う必要があります。ソフトウェアのアーキテクチャによってはさらに追加で試験が必要です。