Automotive SPICE 4.0 ソフトウェア要件とソフトウェアユニット間のトレーサビリティの廃止

Automotive SPICE v3.1 では

BP5：双方向のトレーサビリティの確立　として

• • • ソフトウェア要件とソフトウェアユニット間の双方向のトレーサビリティを確立する

という要求が存在していましたが、Automotive SPICE 4.0 では、この記述が削除され

• • • ソフトウェア詳細設計とソフトウェア要求との間の一貫性を確保しトレーサビリティを確立する

という内容に変更になりました。

 

 

Automotive SPICE v4.0  SWE.3 から引用：

 

 

 

Automotive SPICE ガイドライン2nd editionには、次のような主旨の説明が記述されています

• Automotive SPICE v3.1 とは対照的に、詳細設計におけるソフトウェアユニットまたはコードに対しては、ソフトウェア要求とのトレーサビリティを直接的には要求しない
• 従って、UML/SysMLシーケンス図またはアクティビティ図などの動的モデルを作成し、それを要求に割り当てることは、ソフトウェアコンポーネントおよびソフトウェアユニットへのトレーサビリティを表すことになる

 

また、「ソフトウェアユニット」とは、と題して次のような記述があります

---

• 用語「ソフトウェアユニット」は時々、ソースコードにおけるソフトウェアユニットの実装と誤って解釈されることがある。
• しかしながら、ソースコードは詳細設計において特定されたソフトウェアユニットの実装ソリューションであるため、この解釈は意図されていない。

---

• そもそも「ソフトウェアユニット」とは、実装レベルの用語ではなく、論理的モデリングレベルの用語である。
• 論理的モデリングレベルは詳細な詳細設計を表し、詳細なソフトウェア設計は常にソースコードから意味論的に抽象化されたものであるが、ソースコードそのものと同一ではない。
• 更に、ソフトウェアアーキテクチャ設計及び詳細設計はアプリケーションドメイン言語とエンティティを使用して作成される。
• その結果、ソフトウェアユニットは「分離不可能な一貫した振る舞いの一部分」であり、「単独で検証可能なもの」でもあるという見方はそもそもアプリケーションドメイン知識の視点となる。

---

 

 

これまで、ソフトウェア要件とソフトウェアユニットのトレーサビリティとは何を意味するのか悩まれてきた方も多かったと思います。アセスメントで証明するために無理な作業をしていたケースも多々ありそうですね。

 

参考に、Automotive SPICE 4.0の一貫性とトレーサビリティの図を引用しておきます。

 

 

 

 

今回の整理では、ソフトウェア要求のトレーサビリティは単純に2つのパターンで考えれば良いことになります。かなりすっきり整理されたのではないでしょうか？

 

• オプションA　：　ソフトウェアアーキテクチャを経由するトレーサビリティ

  • 要求を実現するために、ソフトウェアコンポーネントおよびソフトウェアユニットの相互作用のもと実現する場合に必要なトレーサビリティ

• オプションB　：　直接詳細設計のエレメントにつながるトレーサビリティ

  • CANの信号データなど、要求を動的な振る舞いとして設計する必要がない場合のトレーサビリティ

 

日吉　昭彦