ASPICE解説は下記リンクよりアクセスください
プロセスアセスメントモデルはコチラから
※当該解説をより詳細に知りたい方はアセスメントモデルを参照ください
能力レベル3の取得を目標とした記事となります
Generic Practices とは？
既に説明を読んでいる人は飛ばしてください
- 全てのプロセスカテゴリーに当てはまる、共通の活動が記述される
- BP（基本プラクティス）で実施されたプロセスを成熟させるために利用される
BP (Basic practices: 基本プラクティス)は能力レベル1（PA1.1）のみに適用され、それ以上の能力レベル（レベル2～5）ではGP (Ganeric Practices: 共通プラクティス)とGR（Generic Resource: 共通リソース）が適用されます。
より詳しく知りたい方は、アセスメントモデルの【5.3.1 実施管理プロセス属性】以降を参照ください。
能力レベル1-2-3を例えるのであれば、料理なんかが良い例だと思います。
レベル1：レシピ通りに作ってるが、何を調合したのかわからず同じ味を再現できるか不明な状態。
レベル2：レシピに何をどのタイミングで調合するのか記載され、似た味を再現できている状態。
レベル3：レシピがレストランの決まりに組み込まれ展開されており、誰でも同じくできる状態。
即ちの能力レベル1では何となく実施してリリースができている状態に対し、能力レベル2以上ではプロセス（レシピ）が存在して計画・実行・調整がかけられる状態を示します。
Generic Practices の構成
Generic Practicesを能力レベルで分けた表は以下の通りです。
| 能力 レベル |
プロセス属性 | 項 | 説明 |
| L2 | 実施管理プロセス | GP2.1 | プロセスの実施が管理されている程度を示す |
| 作業成果物管理プロセス | GP2.2 | プロセスにより作成される作業成果物が管理されている程度を示す | |
| L3 | プロセス定義プロセス | GP3.1 | 定義されたプロセスが維持されている程度を示す |
| プロセス展開プロセス | GP3.2 | 定義されたプロセスの展開されている程度を示す |
SWE.2の基本プラクティス
基本プラクティスに関する詳細な記述はプロセスアセスメントモデルを参照ください。
SWE.2 ソフトウェアアーキテクチャ設計には合計9つの基本プラクティス（BP1～BP9）が存在します。
SWE.2（ソフトウェアアーキテクチャ設計）の目的は、アーキテクチャ設計を確立することで、どのソフトウェア要件を、どのソフトウェアエレメントに割り当てるのかを識別し、定義した基準に基づくソフトウェアアーキテクチャ設計を評価することである。
BP1
BP1では、ソフトウェアアーキテクチャ設計書の作成が求められています。
システムは、複数の機能が集まってできるため、それぞれがどのように機能し動くのかを明確にしておかなくてはなりません。システムの構造を可視化したものがソフトウェアアーキテクチャであり、ソフトウェアを構築するための基礎となります。
もしソフトウェアアーキテクチャが存在しないと、各々の機能がどのような物であり、どう動くのか全体的な体系が不明確となります。そのためソフトウェア実装者が好き勝手に実装してしまい、後でソフトウェアの保守がとても難しくなってしまう恐れが出てくるのです。
ソフトウェアアーキテクチャは、システムの品質、性能、保守性等における大切なドキュメントです。
そのソフトウェアアーキテクチャ設計書を作成しドキュメント化して保持することをBP1では求めています。
アセスメントでは、アーキテクチャ設計における過程や根拠、分析などの観点に着目します。そのため『なぜそのよなアーキテクチャ設計となったのか』評価の基準や根拠を説明していかなくてはなりません。
BP2
BP2では、ソフトウェア要件の割り当てが求められています。ソフトウェアに関する要件を実現するために、上位で定義されているソフトウェア要件が、ソフトウェアアーキテクチャ設計で定義された各エレメントに割り当てられる必要があります。
エレメントとは、システム全体で様々な機能を分割した個々の単位であり、アーキテクチャ設計における構造化されたオブジェクトを示します。
要は、様々な機能から成る大きなシステムを個々の機能として分割した集合体をエレメントと呼び、そソフトウェア要件とエレメントを結びつけなくてはなりません。
ASPICEのアセスメント観点では、ソフトウェアの最小単位である『ソフトウェアユニット』が特定できるまでソフトウェア要件が落とし込まれている必要があります。
BP3
BP3では、ソフトウェアエレメントのインターフェースを定義することが求められています。各ソフトウェアエレメントのインターフェースを識別し、管理できる状態にして、インターフェース（エレメント同士の相互関係）を明確にして文書化しなくてはなりません。
BP4
BP4では、システムにおける必要な動的な振る舞いを記述することが求められています。
ソフトウェアには構造的（パッケージや範囲等）な静的要素と、実際にソフトウェアが動作するときの挙動を示す『動的な振る舞い』が存在します。
例えば、スタートアップ／シャットダウンであったり、プロセス間通信（送受信）、スレッド、タイムスライス、割り込み等を示します。このような実際にソフトウェアが動作する際の挙動を記述することが求められています。
一般的には、アーキテクチャ設計で作成された各エレメントが構造化されているドキュメントに、エレメント同士がどのような相互関係にあるのか記述し、動的な振る舞いが明確にされています。
BP5
BP5では、リソース消費目標の定義が求められています。該当する全てのエレメントに対してリソース消費目標が定義されていなくてはなりません。車載システムにおいて、大多数のソフトウェアはマイコンに格納されるため、限られているマイコンのリソースを有効に使用できるように、目標設定することを求めています。
リソース消費量は、メモリ（ROM・RAM・データフラッシュ等）やCPU負荷、CAN通信等で決定されます。
システムやマイコン自体への負荷に影響する部品レベルで、それらが持つデータ容量や負荷を一元化して管理しておかなくてはなりません。
BP6
BP6では、ソフトウェアアーキテクチャ設計の評価が求められています。ソフトウェアアーキテクチャ設計の評価基準を定義し、その基準に従って、何故そのようなソフトウェアアーキテクチャ設計となったのか評価を行います。そして、ソフトウェアアーキテクチャ設計の根拠として記録されなくてはなりません。
これはソフトウェアアーキテクチャ設計とソフトウェア要件の一貫性が担保されているのかもポイントとなり、アーキテクチャ設計の確からしさを評価しなくてはなりません。
評価基準には、品質特性（モジュール性、保守性、拡張性、スケーラビリティ、信頼性、セキュリティ、利用可能性）が含まれている必要があります。これらの観点から設問を作成し、定量的評価を実施できるツールや環境を整える必要があります。
BP7
BP7では、双方向トレーサビリティの確立が求められています。ソフトウェアアーキテクチャ設計で定義したエレメントとソフトウェア要件が互いからトレースできるような仕組みが必要です。
ソフトウェア要件に記載される個々のソフトウェア要件が、ソフトウェアアーキテクチャ設計で確立されるエレメントに正しく抜け漏れなく反映されていなくてはならないです。例えば、管理システムでトレースができるタグを設定し、どのソフトウェア要件がどのエレメントに紐づくのか確認できるようにします。
BP8
BP7では、一貫性の確立が求められています。BP7で、ソフトウェアアーキテクチャ設計で定義したエレメントとソフトウェア要件が互いからトレースできる双方向トレーサビリティの仕組みが必要となりました。この双方向トレーサビリティによって、どのソフトウェア要件が、どのソフトウェアアーキテクチャ設計に紐づいているのか一貫性を保った状態で管理される状態にしなくてはなりません。
この一貫性は、双方向トレーサビリティによって裏付けられる形となります。
BP9
BP9では、合意したソフトウェアアーキテクチャ設計の伝達が求められています。ソフトウェアアーキテクチャ設計の評価はBP6で求められていましたが、その結果に基づき関係者がソフトウェアアーキテクチャ設計に合意され、合意後には関係者へ展開されるような仕組みが必要となります。
何が合意され、何は合意されていないのか、そのステータスがわかるような仕組みの構築が必要となります。
コメント