ASPICE解説は下記リンクよりアクセスください
プロセスアセスメントモデルはコチラから
※当該解説をより詳細に知りたい方はアセスメントモデルを参照ください
能力レベル3の取得を目標とした記事となります
Generic Practices とは？
既に説明を読んでいる人は飛ばしてください
- 全てのプロセスカテゴリーに当てはまる、共通の活動が記述される
- BP（基本プラクティス）で実施されたプロセスを成熟させるために利用される
BP (Basic practices: 基本プラクティス)は能力レベル1（PA1.1）のみに適用され、それ以上の能力レベル（レベル2～5）ではGP (Ganeric Practices: 共通プラクティス)とGR（Generic Resources: 共通リソース）が適用されます。
より詳しく知りたい方は、アセスメントモデルの【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.4の基本プラクティス
基本プラクティスに関する詳細な記述はプロセスアセスメントモデルを参照ください。
SWE.4ソフトウェアユニット検証 には合計7つの基本プラクティス（BP1～BP7）が存在します。
SWE.4 (ソフトウェアユニット検証) の目的は、生成したソフトウェアユニットを検証するために、各ソフトウェアユニットがソフトウェア詳細設計およびソフトウェアの要件に厳守している証拠を集めることである。
BP1
BP1では、ソフトウェアユニット検証戦略の作成が求められています。
どのような検証をどの程度まで行う必要があるのか、ソフトウェア検証における戦略を確立します。この戦略には、検証を実施するために必要なリソース（人、設備、ツールなど）を計画しておく必要があります。また責任分担を明確にしたり、テストスケジュールも必要です。
なお、BP1では回帰戦略を確立することが求められています。例えば、上位の要件（仕様やソフトウェア設計など）が変更された場合に、ソースコードにも変更が加わりますが、これをどの程度までソフトウェアユニット単位で再検証が必要か、方法や範囲を定義付けします。
BP2
BP2では、ユニット検証のための基準の作成が求められています。
ソフトウェアユニットの検証には、静的検証と動的検証の二種類が存在します。静的検証は、ソースコードレビューなどのように、ソフトウェア詳細設計で求められる内容がソースコードレベルで正しく作りこまれているのかレビューをすることです。
対して動的検証は、リソーステストのようにメモリの使用量や実行時間などを測定し、確認をすることを示し、ソフトウェアの動的な振る舞いを検証することを言います。
上記のような検証における判断基準を定めることがBP2では求められています。例えば、静的検証であればソースコードレビューチェックシートの作成であったり、コーディング規約であったり、正当な根拠をもって正しく検証結果を判断できるように基準を定められているかアセスメント時には確認されます。
動的検証であれば、リソース消費目標（どの程度のメモリ消費量を目標値と定めたもの）であったり、テストケース（シナリオ）の網羅性を検証する基準です。
BP3
BP3では、ソフトウェアユニットの静的検証の実施が求められています。
BP2で定めたようなユニット検証のための基準を用いて、実際に静的検証を実行することが求められています。例えば、レビューチェックリストを使用し、関係者と確認を行うだけではなく、それらの証拠を保存しなくてはなりません。議事録、実施日、参加者、レビューの目的、レビューした書類等を含め、エビデンスとして維持します。
BP4
BP4では、ソフトウェアユニットのテストの実施が求められています。
プログラムを構成する小さな単位（ユニット）が個々の機能を正しく果たしているのか検証をすることです。単体テストとも呼ばれます。ユニットテスト（単体テスト）は、ソースコードの作成時など、比較的早い段階で行われることが多いです。
BP2で定めたようなユニット検証のための基準を用いて、ユニットテストを行う必要があります。これは、BP3同様に検証の証拠を保存しなくてはなりません。
BP5
BP5では、双方向トレーサビリティの確立が求められています。
個々のユニットテストが漏れなく、ソフトウェア詳細設計書に記載された全ての要件に対して実行されるため、ソフトウェア詳細設計書とユニットテストの一貫性を担保する必要があります。双方向トレーサビリティというのは、下位概念と上位概念の両方向から互いをトレーサビリティできることをいいます。
例えば、ユニットテスト単位の情報から、それらがソフトウェア詳細設計書のどこに該当するのかトラックでき、逆にソフトウェア詳細設計書からユニットテストをトラッキングできる仕組みです。
BP6
BP6では、一貫性の確保が求められています。
一貫性とは、双方向トレーサビリティと似た言葉になりますが、上位概念と下位概念の一貫性を確立することが求められています。例えば、SWE.4ではソフトウェア詳細設計書の内容が、ユニットテストレベルまで落とし込まれている（互いに齟齬がない状態）ことが必要となってきます。
BP7
BP7では、結果の要約および伝達が求められています。
SWE.4で求められるユニットテストの検証結果が関係する全ての要員に伝達される必要があります。レビュー実施日、参加者、検証目的など、一般的な情報の他にも、検証するソフトウェアのバージョンであったり、仕様したツールなどの情報も事細かに記入（保存）しておく必要があります。これは、レビュー後に、同様の環境を再現することに役立てることができます。
コメント