Updates

新着情報

コラム

作業成果物と情報項目 Automotive SPICE 4.0のアセスメント指標の変化

Automotive SPICE V4.0に更新され、アセスメント指標が変更されたことをご存知ですか?今回のAutomotive SPICEV4.0に関するコラムは、アセスメント指標についてお届けします。  アセスメント指標とはプロセスアセスメントの関する国際規格の1つである、ISO/IEC 33004では、プロセスアセスメントモデルは、能力レベルを評価するために、アセッサの判断の拠り所として「アセスメント指標」を定義することを要求しています。プロセス成果やプロセス属性達成成果の有無を判断するために、対象プロジェクトの作業成果物や管理者・開発者の証言を、この「アセスメント指標」にマッピングすることで、達成度合いを評価します。Automotive SPICEにおいてもアセスメント指標を定義していますが、V4.0への更新に伴い内容が更新されましたので、ご紹介します。  Automotive SPICE V4.0におけるアセスメント指標V4.0では、プロセス実施指標とプロセス能力指標の定義がなくなり、単に2つの指標として、プラクティスと情報項目を定義しています。 プラクティス:活動重視の指標 情報項目:結果重視の指標プラクティスは、V3.1と同様に、基本プラクティスと共通プラクティスの2種類となっています。 基本プラクティス(BP):能力レベル1に適用。プロセス成果の達成程度を示し、プロセス固有のものである。 共通プラクティス(GP):能力レベル2~5に適用。プロセス属性の達成成果の程度を示し、全プロセス共通のものである。情報項目(II)は、プロセス成果およびプロセス属性の達成成果の達成を構成するものとしており、情報項目特性(IIC)含まれます。V4.0では、アセスメント指標がシンプルになり、理解しやすい構造になっていますね。  作業成果物と情報項目の違いプラクティスに変更はありませんが、V3.1で定義されていた作業成果物や共通リソースが、情報項目に変更されました。それでは、作業成果物と情報項目にはどのような違いがあるのでしょうか?V4.0では、以下のように定義しています。 情報項目:アセッサーがプロセス属性の達成成果を判断するために使用される関連情報の一部分を定義している。 作業成果物:プロセスを実施、管理、確立、分析、および革新する際に、アセスメント対象組織によって生成されるものである。情報項目(II)は、アセッサーがアセスメントにおいて、作業成果物を調査する際に、「何を見るべきか」のガイダンスとして提供されているものであり、作業成果物そのものではありません。また、情報項目に含まれる情報項目特性は、情報項目の潜在的な特性の例を示しており、作業成果物のチェックリストとして使用されることを意図していません。言い換えると、作業成果物はプロジェクトが生成した(生成すべき)ものであり、情報項目はアセッサーが調査の拠り所をするものなので、両者を同一と理解してはいけないことになります。作業成果物と情報項目(情報項目特性)の関係は以下のように整理されています。 作業成果物は、複数の情報項目特性から構成される場合がある。 複数の作業成果物が同一の情報項目特性を有する場合もある。 作業成果物は、情報項目とは別の名称で呼んでもよい(名称は重要ではない)。 構造や帳票が異なる作業成果物が存在しても良い。(例:課題をエクセルとチケットシステムで管理)例えば、V3.1の作業成果物「ソフトウェア要件仕様書」は、V4.0では、「要求」と「要求の属性」に変更されています。これは「ソフトウェア要件仕様書という文書が存在しないといけない」ということではなく、基本プラクティスを満たした結果として、情報項目や情報項目特性が含まれているのであれば、「ソフトウェア要求仕様書」や「ソフトウェア仕様書」でも良く、複数の「ソフトウェア仕様書」に分冊されていても良いことを示しています。  さいごにいかがでしょうか?システム開発やソフトウェア開発に携わっている方にとって、V3.1で求められていた作業成果物を生成することを意識するのではなく、皆さんの組織や開発している製品の特長に合わせて、V4.0で求めれている情報項目や情報項目特性を満たした作業成果物の構成や形を検討してみることが大切なことだと思います。内山哲三 

コラム

ソフトウェアエレメント、ソフトウェアコンポーネント、ソフトウエアユニットの関係について

Automotive SPICE v4.0ではソフトウェアに関して以下の3つの用語を用いていますが、それらの関係について、ソフトウェア設計工程(SWE.2、SWE.3)での取り扱いについて解説します。 ソフトウェアエレメントソフトウェアコンポーネント及びソフトウェアユニットを総称して、ソフトウェアエレメントと定義します。 ソフトウェアコンポーネントソフトウェアアーキテクチャで記述するソフトウェアエレメントをソフトウェアコンポーネントと定義します。ソフトウェアエレメントは、ソフトウェアユニットの上位に位置し、ソフトウェアアーキテクチャ設計(SWE.2)では、最下位のソフトウェアコンポーネントになるまで、ソフトウェアを適切な階層レベルで分割します。 ソフトウエアユニットソフトウェアコンポーネントの一部であり、これ以上細分化されないことが決定された、コンセプトモデルにおける最下位レベルのソフトウェアエレメントを表現したものと定義します。ソフトウェア、ソフトウェアコンポーネント、ソフトウェアユニットの関係を解り易く図で示します。 ソフトウェアコンポーネントとソフトウエアユニットの扱いに関しては、Automotive SPICE v3.1 では直感的/十分に記載されていませんでしたが、Automotive SPICE v4.0 では、 SWE.2 (ソフトウェアアーキテクチャ設計)ではソフトウェアコンポーネントの振舞いを定義する SWE.3 (ソフトウェア 詳細設計およびユニット構築)ではソフトウェアユニットの振舞いを定義すると明記されました。 SWE.2 で定義した各々のソフトウェアコンポーネントは、SWE.3 で複数のソフトウエアユニットによって構成されます。Automotive SPICE VDA ガイドライン第2版を参照し、SWE.2プロセス、SWE.3プロセスを通してソフトウェアコンポーネント、ソフトウェアユニットの関係を整理しました。  <SWE.2プロセスでの作業概要> ソフトウェアアーキテクチャ設計を実施する際、ソフトウェアの静的側面として、ソフトウェアを個々の機能に着目してソフトウェアコンポーネントに分割し、ソフトウェアコンポーネント毎の機能を(ブラックボックスとして)定義します(ソフトウェアコンポーネント設計)。 大規模なソフトウェアコンポーネントでは、そのコンポーネントを複数のコンポーネントに分割するケースもあります(コンポーネントの多重構造) ソフトウェアコンポーネント内部が、これ以上分割できないソフトウェアユニットに分割されるまで、ソフトウェアコンポーネントのブレークダウンを繰り返します。 ソフトウェアの動的側面として、個々のソフトウェアコンポーネントの動作概要、及びソフトウェアコンポーネント間インタフェースを定義します。 <SWE.3 プロセスでの作業概要> SWE.2で作成したソフトウェアアーキテクチャ設計に基づいて、ソフトウェアコンポーネントを詳細にブレークダウン設計します。 ソフトウェアユニット毎の機能を(ブラックボックスとして)定義します。 ソフトウェアの動的側面として、個々のソフトウェアユニットの詳細な動作、及びソフトウェアユニット間インタフェースを定義します。 最後に、ソフトウェア詳細設計に基づいて、ソフトウェアユニットのソースコードを作成します。実際の開発現場ではソフトウエアを様々な用語(例:ファンクションブロック、モジュール、セクション、ユニット、関数etc.)を用いて管理されていると思いますが、Automotive SPICE v4.0 で使用する3つの用語(エレメント、コンポーネント。ユニット)との対応を明確にすることで、Automotive SPICE への対応が効率的に実施できます。 ご不明な点等あれば、弊社までお問合せください。海農公宏

コラム

「テスト」から「検証」へ - Automotive SPICE 4.0の「検証」プロセス -

Automotive SPICE 4.0 に関するコラム、今回は「検証」プロセスについてお届けいたします。 はじめに これまでのAutomotive SPICE v3.1にあった「テスト」と名の付くプロセスは、v4.0では以下の様に「テスト」の代わりに「検証」という用語に変わりました。SWE.5:ソフトウェア統合および統合テスト→ソフトウェアコンポーネント検証および統合検証SWE.6:ソフトウェア適格性確認テスト→ソフトウェア検証SYS.4:システム統合および統合テスト→システム統合および統合検証SYS.5:システム適格性確認テスト→システム検証 なぜ「テスト」から「検証」に変わったか Automotive SPICE v4.0のガイドラインでは、「特に、システム及びハードウェアのレベルでは、テストだけが唯一の検証アプローチではなく、測定、計算または物理的なサンプルを使用するシュミレーションなどは他の検証方法である」とあります。より包括的な「検証」という用語を用いることにより、テストに限定しないで最も適した検証手段を選んで下さいというメッセージになりました。もともとv3.1でも、SWE.4「ソフトウェアユニット検証」プロセスだけは、ユニット検証手法としてテストだけでなく静的解析やコードレビューもあることから、「ソフトウェアユニットテスト」ではなく「ソフトウェアユニット検証」というプロセス名になっていました。V4.0ではこの考え方が全テストプロセスに広がったことになります。 これまでのテストプロセスとの違い 用語の変更に伴い検証プロセスのBP(基本プラクティス)の内容も変わりました。v3.1 SWE.6:ソフトウェア適格性確認テストとv4.0 SWE.6:ソフトウェア検証を比較すると以下となります。 Ver3.1のSWE.6.BP1「回帰テスト戦略を含むソフトウェア適格性確認テスト戦略の策定」はV4.0では「戦略」がBPから無くなるために削除となり、「テスト仕様の作成(BP2)」は「検証手段の仕様化」、「テストケースの選択(BP3)」は「検証手段の選定」に、「ソフトウェアのテスト(BP4)」は「ソフトウェアの検証」と、その表現を変えています。これまでは「テスト仕様の作成」というBP名称だったため、とにかく「テストしなければならない」という思いが強かったのではないかと思います。そのため本来机上検証の方が効果的かつ効率的な項目においても、無理してテストを行うような場面があったのではないでしょうか。でもVer4.0では「この項目はテストで検証」「この項目は机上で計算」と戦略的に検証手段を選択することを求めていますので、テストに拘らずより検証目的に適った検証手段を選択することとなり、結果的に検証品質が向上し、製品の品質向上に繋がると考えます。(安部宏典)

コラム

Automotive SPICE 4.0 SWE.5 ソフトウェア統合テストの考え方

Automotive SPICE 4.0では、各プロセスの目的は変わっていないとしならがら、細かい点で修正が盛り込まれています。Automotive SPICEのアセスメントを予定している方には、目的は変わらないと言われても、不安に思われている方も多いと思われます。今回は、SWE.5 ソフトウェア統合テストに関する変更点についてお伝えします。 ソフトウェア統合および統合テストについては、インタビューの場面でもアセッサと論点がかみ合わず、対応に苦慮された経験をお持ちの方も多いのではないでしょうか?よくあるケースとして:  いわゆるビックバン:全てのソフトウェアをビルドして統合するので段階的な統合やテストは実施していない(する必要性を感じていない) 統合テストとは、ビルドしたソフトウェアを使って、機能を確認するテストである という説明になり、質疑に時間がかかってしまうケースが多いように見受けられます。勿論、製品開発の形態(新規、派生など)や、プロジェクトの状況などにより、統合やテストの方法は変わってきます。しかしながら、Automotive SPICEにおける考え方を理解しておくことで、状況に応じた説明をすることが重要だと思います。そこで、VDAガイドライン第2版をみながら統合テストのありかたを整理してみました。 ソフトウェア統合および統合テスト(検証)の考え方は次の通りです: ❶コンポーネント内のソフトウェアユニット相互が設計通りに振舞うことを検証する❷コンポーネントが設計通りに正しく動作することを検証する➌コンポーネント相互が設計通りに振舞うことを検証する VDAガイドラインでは、次の絵を使って解説しています。下記の4点は、Automotive SPICE v3.1では直感的/十分には記載されていなかったとして、Automotive SPICE 4.0 では各プロセスに明確に定義されました。 SWE.2 単体のソフトウェアコンポーネントの振舞いの定義(コンポーネント間の相互作用とは対照的なものとして) SWE.3 単体のソフトウェアユニットの振舞いの定義 SWE.5 ソフトウェアユニットをそれらのコンポーネントに統合および統合検証 SWE.5 単体のソフトウェアコンポーネントの検証(他のコンポーネントとの統合に先立ち)   これらを別の形で図示すると2023.10.7発行のコラム(ソフトウェアドキュメント間のトレーサビリティ)の中で「統合テスト」のアイコンで示したことと、ほぼ同じことを言っていることがわかります。 当たり前といえば、当たり前のことなのですが、アセスメントモデルのプラクティスとして記載されてしまうと、求められていることがわかりにくくなってしまうのかもしれません。このように図で表現するとわかりやすいのではないでしょうか?ご不明な点等あれば、弊社までお問合せください。日吉昭彦 

コラム

Automotive SPICE SYS(システムエンジニアリング)プロセス担当について

 製品開発体制の中でSYSプロセス担当が不在になりがち一般的な製品開発組織は下記の様な体制が多い様です。しかし、このような開発体制の場合、システムエンジニアリング(SYSプロセス)はどこが担当するのが良いのでしょう?・プロジェクト全体を纏める「製品開発取り纏め部門」は、SYSプロセスを担当できる技術的なスキルが足りない・「制御/システム開発」は名前は近いが、役割は回路設計(E/E)や制御仕様が担当で、メカやソフトウェアも含めた製品全体の責任は取れない・製品全体のシステム要件整理を纏める担当が明確ではない。しかし、各部門間でそれぞれ要件調整を実施し、その結果を各担当部分の要件としているため特に必要性を感じていない上記のような理由から、SYSプロセスを担当する部門/開発チームが不在になっていないでしょうか。  SYSプロセス担当が不在なことによる弊害・各部門間で調整した要件が、システム要件として纏まっていないため、部門間の議論で気が付かない不整合が開発後半で発生してしまう可能性がある・システム全体の把握した設計ドキュメントが作られず、新規機能を検討する場合に、最適な機能分担がスムーズに行えない(行える人が不在)・システム全体目線でのシステム要件分析やシステムアーキテクチャ検討結果が作成されない。そのため、システム全体検証の項目に抜け漏れが発生して、機能不良や不具合が流出してしまう可能性がある 仮想的なシステムチームSYSプロセスは製品品質を向上させるために重要な役割を持っています。組織体制上、どこかの部門・チームがシステム全体を見るSYSプロセス担当となるのは難しいかも知れません。その場合は、例えばこの図の様に、各部門からリソースを出し合い仮想的なシステムチームを構成し、役割と責任を与えて、システム全体を明確にするためのSYSプロセスを適用できるような体制と責任分担が重要となります。 さいごに今回のコラムはいかがでしたでしょうか?思い当たることがありませんでしたか?製品開発体制の中に、システム担当部署がいない場合の解決案をご説明しました。仮想的なチーム運営は難しいかもしれませんが、参考にしていただけると幸いです。 鈴木功

コラム

Automotive SPICE 4.0にMLE(機械学習)が追加

Automotive SPICE 4.0に関するコラム、今回はMLE(機械学習)についてお届けいたします。 はじめに機械学習という言葉を耳にした方は多いのではないでしょうか。今回Automotive SPICE 4.0で機械学習が追加されたことで、各社独自に実施していた機械学習プロジェクトのプロセスが明確化されました。機械学習とは、特定のトレーニングデータから傾向(パターン)やルールを見つけ出し、その知識を他の同様のタスクに適用するソフトウエアの機能を指します。この機会学習の発達により、特定の分野では、人を上回る能力を発揮するようになっています。象徴的な事例がAlphaGo(コンピュータ囲碁プログラム)で、人間同士では何百年もかかるような膨大な数の対局経験をバーチャルにこなし、囲碁の世界チャンピオンを破るにまでに至っています。 機械学習プロセスの流れ以下がAutomotive SPICEで定義されている機械学習プロセスになります。これを見てわかる通り、通常のシステム開発プロセスと大きな違いはありません。MLE.1:機械学習要件分析・対象となるシステムや問題領域を理解し、機械学習システムが適用される領域やデータの特性を理解した上で、要件の洗い出しを行う。MLE2:機械学習アーキテクチャ・機械学習システムの全体的な構造やコンポーネントの設計を行います。モデルの選択やデータのフロー、各機能モジュールの役割と相互関係を明確化します。MLE3:機械学習トレーニング・モデルの学習を行います。トレーニングデータを使用してモデルのパラメータを調整し、データのパターンや関係性を学習させますMLE4:機械学習テスト・トレーニング済みモデルの性能や予測の精度を評価するために、テストデータを使用してモデルを評価する。さらに性能改善やバグ修正のための実験や検証も行いますSUP.11:機械学習データ管理・適切なデータの収集、前処理、変換、正規化、データセットの管理など、データに関する一連の作業を実施する。これにはデータの品質管理やセキュリティの確保も含まれています 機械学習の事例各社、機械学習を取り入れ医療や科学、無人配達などへの適用が進められています。今回は車載の自動運転に機械学習を適用している具体例をご説明いたします。■画像解析におけるAI・自動運転車の制御は「認知・判断・制御」に大別されます。・AI(人口知能)は主に「認知」の部分で使用されています。・車両に搭載されたカメラやLiDAR、ミリ波レーダーなどのセンサーが映し出すデータを分析し、物体を認識できるようにAIをトレーニングしています。■学習データの収集・AIのトレーニングには、車両に搭載されたカメラで撮影した画像とその画像にタグ付け(例:人間、犬、猫、信号等)するための情報を含むデータが使用されます。 自動運転では車載カメラやセンサーを使用し物体を認識したうえで、走行、停止、回避(判断)し必要に応じて制御します。 機械学習を導入することによるメリットやデメリット最後に機械学習を採用することによるメリットやデメリットについてコメントしたいと思います。・自動化によるコスト削減・高精度の識別、予測による効率化機械学習を取り入れる最大のメリットは上記に集約されるでしょう。一方で以下のようなデメリットもあります。・自動化、効率化の効果を予測しづらいこれは、「うまくいく」と想定されるテーマにおいても、実際にデータを集めて学習を行ってみるまで、本当に精度の高いモデルが作られるかどうか分からない。仮に「精度の高いモデルが作れたとしても、永続的に使い続けられるわけではない」という点が挙げられます。 今後、注目を浴びることになると思われる機械学習についてコメントいたしました。もし、もっと機械学習について知りたい、などご要望ございましたらコメントお願いいたします。  

コラム

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の信号データなど、要求を動的な振る舞いとして設計する必要がない場合のトレーサビリティ 日吉昭彦

コラム

Automotive SPICE 4.0 SWE.2 ソフトウェアアーキテクチャ設計とは?

Automotive SPICE 4.0が発行され、Automotive SPICE (VDA)ガイドラインも含めて内容を確認していますが、SWE.2 のガイドラインにとても良い説明が書かれていますので、なるべく原文を引用しながら、個人的な見解を書いてみます。 青文字:VDAガイドラインから引用黒文字:筆者のコメント  ソフトウェアアーキテクチャ設計の目的Automotive SPICEはそれぞれのレベルでの設計上の決定を通じて、要求が体系的に下位レベルに細分化されるべきであることを強調している。つまり、要求レベルのフワっとした内容を、ソフトウェアで実現するための仕様に落とし、仕様をインプットにして詳細な設計を実施していく段階的なアプローチを前提としているということです。ソフトウェア構造においては、コンポーネント、モジュール、ユニット、関数と構造化設計をしていくことが高品質で変更にも強いソフトウェアを作ることが可能になります。結果的に、生産性も高まってくるわけで、こういった考え方がソフトウェアアーキテクチャ設計の目指すところになります。  その背後にある考え方は以下の通りである: あまりにも多くの情報に圧倒されて間違いを犯さないようにする(「分割統治」の原則) 将来のスタッフにソフトウェアの文書を提供し、潜在的に膨大なソースコードからソフトウェアがどのように作動するかを非効率的に学習する必要がないようにする 暗黙の知識が文書及び最終製品において失われていないことを確実にする それぞれのレベルでの要求が完全にカバーされていることを確保する 最終的に、余分なソフトウェアエレメントが存在しない(つまり、SWは要求が必要とする以上のものを含まない)小規模ソフトウェアの場合、要件毎に必要な関数を作り関数と関数をつなげた方が手っ取り早く機能を実現できるため、構造化設計の必要性を肌で感じていない方も多いのだと思っています。開発規模の増大化や実現機能の複雑化に加え、再利用性が事業上の重要課題になってくると、そのパラダイムを変える必要が出てくるはずです。事業に貢献するためのソフトウェアアーキテクチャを作りあげること。アーキテクチャに基づいて、それぞれの領域の専門家が分業していくことで、品質はもとよりTime to Marcketに貢献できるソフトウェア開発と保守が可能になるのです。  ソフトウェアアーキテクチャ設計静的及び動的なビューを超えて、どのようなビューが必要であるかについての共通的な定義はなく、ビューがいくつあれば完全であるかに関する基準はない。ビューの数及び種類は製品のサイズ並びに複雑性に大きく依存する。 業界には、綿密なアーキテクチャ設計記述のために、ビューに必要となる情報の種類(ある種類のビューを構築するためのパターン、テンプレート、規約の集合体である「ビューポイント」)、及び複数のビューの統合について特定したアプローチがいくつか存在する。多くの場合、ソフトウェアアーキテクチャ設計はテキストの説明によって補足されるソフトウェアのグラフィック的な表現である。ここにも書かれているように、アーキテクチャ設計はグラフィック系のソフトウェアを使用して作成することが一般的です。過去には、VISIOなどのDraw系ソフトウェアを使われている方が多かったようですが、現在ではSysML系のソフトウェアなどを使われているケースも多くなっています。更には、テキストから図表を自動作成してくれるSphinxの活用も一般的になってきているようです。動的なビューとしては、つぎのような例が一般的でしょう: シーケンス図(ソフトウェアコンポーネント間の相互作用を記述) 状態遷移図(製品を制御するために必要な動作状態と状態を遷移するイベントを記述) アクティビティ図(処理実行の流れと条件分岐を記述) データフロー図(データの流れを記述)開発するソフトウェアにとって、最適なビューを使うことがポイントとなります。動的ビューの事例は、弊社発行のAutomotive SPICE入門書籍でも掲載していますので参考にしてみてください。https://www.bgarage.co.jp/news/323/  静的なソフトウェアアーキテクチャのビューは、ソフトウェアを高い凝集性及び低い結合性をもつ管理可能なエレメントに分解することを可能にする。この分解は、これらのアーキテクチャエレメントへの要求の割り当てを支援し、開発者への作業パッケージの配布を整理するのに役立つ。 アセスメントの範囲外で開発されたソフトウェアのアーキテクチャエレメント(例えば、オープンソースソフトウェア、プラットフォームソフトウェア、第三者ソフトウェア)も、ソフトウェアアーキテクチャ設計の専用エレメントとして含まれ、同様にインタフェース分析、動的な振る舞い、リソース消費目標などに対しても考慮されなければならない。 必要に応じて、アーキテクチャエレメントはアーキテクチャ設計において最下位レベルのエレメントであるコンポーネントに至るまで更に具体化される。コンポーネントは1つ以上のユニットで構成され、ソフトウェア詳細設計(SWE.3)の対象となる。静的ビューについては、疎結合な設計をするために互換性や拡張性の観点からみて最適な構造を作ることを支援します。要求全体を見ながら、共通的な機能をまとめたり個別機能間とのインタフェースなどを考慮しながら、ソフトウェアコンポーネントを配置していくことになります。このような構造設計を実施すると、要求とソフトウェアが1対1にならないため、分割された各ソフトウェア要素にソフトウェア要求を割り付けることや、要求に対してソフトウェアコンポーネント間の相互動作を文書化して要求の網羅性を検証する必要が出てきます。そもそも構造化ができていない、関数の連結によるアーキテクチャであれば、要求の割り当てやトレーサビリティもあまり意味を持たないものになります。疎結合が高い設計は、分業化が進むことにより生産性や品質へ寄与しますが、反面ソフトウェアの全体を見渡せる人材が少なくなり、問題解析が1人では困難になるという副作用もでてきます。ソフトウェア構造の例は、コラム(ソフトウェアドキュメント間のトレーサビリティ)をご参照ください。https://www.bgarage.co.jp/news/190/  割り込みに関して最先端技術によれば、割り込みサービスルーチンはドメインロジックの振る舞い又は複雑なアルゴリズムを含めてはならないが、割り込み処理は依然として並列制御又はデータフローさえも表示している。特に、高い割り込み負荷はアプリケーションにおいて干渉を引き起こす可能性がある。 そのため、Automotive SPICE v4.0 では、それらをソフトウェア設計、特に動的な設計に反映させるためにソフトウェアユニットとして関連する割り込み処理を扱うことが重要であると考えている。割り込みについては、リアルタイムOSで見られるような割り込みクラスを定義して、タスクをダイナミックに制御することができていないことが多いようです。スケジューラに頼りすぎた設計になり、思わぬ障害につながるケースも数多く見てきました。ソフトウェアのアーキテクチャ設計では、割り込み処理に加えて、タスク制御やリソースおよび性能面も含めたソフトウェアの基本となるメカニズムの可視化も大切になります。 日吉昭彦