SOUPコンポーネントを使用してSWドキュメントを構成する方法
IEC 62304 に準拠するためにいくつかのドキュメントを作成する必要があります。また、ドキュメント化する必要があるすべてのプロセスを読んでいる間に、多くのドキュメント全体を構成する方法についていくつか疑問があります。
私の懸念は、すべてのドキュメントを別々のドキュメントに分割する方法と、何を含める必要があるかということです。
ソフトウェアシステム全体は、3つのメインサブシステムで構成されていると見なすことができます。
- 組み込みデバイスのファームウェア（＃1）
- コンパニオンAndroidアプリケーション（＃2）
- デバイスからのデータの取り込み、処理、保存に使用されるアプリケーションバックエンド（＃3）
私は特に最新のものを担当しています。これはかなり合理化されたストリーミング指向のアプリケーションで、データを処理してDBに保存します（a [〜＃〜] soup [〜＃〜] 、 IEC 62304準拠）の場合。
これで、DBに保存されたデータがGrafanaダッシュボードで視覚化されます。このコンポーネントで考慮すべきドキュメントはどれですか＃3アプリケーションと他のコンポーネントとの相互作用に関するスコープの制限は何ですか？ GrafanaはSOUPになるので、すべての構成とSOUP管理がある適切なドキュメントにそれを書くことを考えていました。 ＃3アプリケーションのSRS内で、必要な視覚化の要件について言及/参照する必要がありますか？この情報をどこに入れればよいのでしょうか？
私は必要なすべてのドキュメントのテンプレートリファレンスとして使用しています このブログ 。これは、ISO /標準規則によるソフトウェア開発が初めてなので、ドキュメント全体の構造に関する追加リソースです。このコンテキストは高く評価されています。
ありがとうございました
コンポーネントがSOUPとして識別されるという事実は、そのコンポーネントの開発に使用されるプロセスを制御できないことを意味します。そのため、コンポーネントが最悪のプロセスで開発されたと想定する必要があります（テストなし、設計なし、問題追跡なし）。 、何も）。それとは別に、SOUPコンポーネントは（サブ）システムの別のコンポーネントにすぎません。
これの意味は：
- SRSには、特定のSOUPコンポーネントの選択につながる要件が含まれている必要があります。 Grafanaを使用する場合は、ダッシュボードの要件が必要です。その要件なしで、なぜ最初にダッシュボードを作成するのですか？.
- 建築、システム、またはサブシステムの設計では、そのレベルの抽象化を構成する部分を特定します。ここでは、SOUPとして購入した部品と、システム全体の品質を確保するために講じる措置を特定します。
- 他の設計ドキュメント、たとえばデータベースとの相互作用を記述する詳細設計では、SOUPであるかどうかを明示的に呼び出さなくても、外部コンポーネントを参照するだけで済みます。それらの設計に関する限り、外部コンポーネントを誰が開発したかは問題ではありません。