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.5の基本プラクティス
基本プラクティスに関する詳細な記述はプロセスアセスメントモデルを参照ください。
SWE.5 ソフトウェア統合および統合テスト には合計9つの基本プラクティス（BP1～BP9）が存在します。
SWE.5 (ソフトウェア統合および統合テスト) の目的は、ソフトウェアアーキテクチャ設計と整合性のあるソフトウェアが完成するまで、ソフトウェアユニットをより大きなソフトウェアアイテムに統合し、その統合ソフトウェアアイテムがソフトウェアユニット間およびソフトウェアアイテム間のインタフェースを含むソフトウェアアーキテクチャ設計に遵守している証拠を提供するために、ソフトウェアアイテムのテストを確実に実施することである。
BP1
BP1では、ソフトウェア統合戦略の策定が求められています。
ソフトウェア統合テストとは、個々のソフトウェアユニットを組み合わせた集合体としてテストをするフェーズを言います。SWE.4では、個々のソフトウェアユニット単体でのテストが求めらていたことに対し、SWE.5では単体テスト後に行われる統合テストに関する要件になります。
ソフトウェアにおける検証（評価）は、ソフトウェアユニットから段階的に統合しながら実施されます。
BP1では、ソフトウェア統合テストを実施するにあたり戦略を策定します。全体的な戦略（標準や規定など）が存在し、ソフトウェア統合の方法や統合の計画を策定します。全体的なソフトウェアリリースのタイミングなどを示したスケジュールも明確にしておく必要があります。
BP2
BP2では、回帰戦略を含むソフトウェア統合テスト戦略の策定が求められています。
回帰戦略とは、例えば上位の要件（仕様やソフトウェア設計など）が変更された場合に、ソースコードにも変更が加わりますが、これをどの程度までソフトウェアユニット単位で再検証が必要か、方法や範囲を定義付けします。
BP1との違いは、回帰戦略が含まれていること以外にも、BP2ではソフトウェアテストに焦点を当てた計画となっていることです。例えば、ソフトウェア統合テストを行うリソースの計画を策定しておかなくてはなりません。ソフトウェア統合テスト計画書や、ソフトウェア統合テストスケジュールなどで、検証を実施するために必要なリソース（人、設備、ツールなど）を計画しておく必要があります。また責任分担を明確にしたり、日程表などのテストスケジュールも必要です。
このソフトウェア統合テストの計画は上位計画やスケジュールと整合性のある状況を維持しなくてはなりません。例えば、プロジェクト開発マイルストンと整合性が担保されているかなどになります。
BP3
BP3では、ソフトウェア統合テスト仕様の作成が求められています。
統合ソフトウェア戦略に従い、テストケースを含んだ仕様を作成する必要があります。実際に行われるソフトウェア統合テストの事例としては、設計に定義された正常な状態とは逸脱した状態を再現して、ソフトウェアの振る舞いを検証する手法（いじわるテスト等）であったり、ソフトウェアユニット間のインターフェースが設計書で定義された振る舞いを満たしているのか確認を行う手法（インターフェーステスト等）が挙げられます。
実際にテストを行う上での、テストの仕様を作成しなくてはなりません。
BP4
BP4では、ソフトウェアユニットおよびソフトウェアアイテムの統合が求められています。
ASPICEの概念として、ソフトウェアにおける検証（評価）は、ソフトウェアユニットから段階的に統合しながら実施されます。ソフトウェアを構成する最小単位であるソフトウェアユニットの検証（単体テスト）を要求していたのがSWE.4に対し、複数のソフトウェアユニットの集合体（結合テスト）の検証を要求しているのがSWE.5になります。
このようにソフトウェアユニットがソフトウェア統合戦略に基づき、どのように統合していくのか決めていく必要があり、そしてそれを実施できる状態を満足しなくてはなりません。
BP5
BP5では、テストケースの選択が求められています。
BP3で求められていた、ソフトウェア統合テスト仕様に従って、実際にテストケースを選択することが求められています。これは、ソフトウェア結合テスト戦略や、策定したリリース計画に従って十分な網羅性を持つように選択されなくてはなりません。
BP6
BP6では、ソフトウェア統合テストの実施が求められています。
今までのBPで求められてきた、戦略・計画・スケジュール・リソース・仕様などなどを用いて、実際にソフトウェア結合テストを実施することがBP6で求められています。なお、テストの記録やログを記録することも求められており、検証目的、実施日、担当者を記録する他にも、再現環境を構築するための確認したソフトウェアバージョンやツールのバージョンやライセンス等も記録します。
BP7
BP7では、双方向トレーサビリティの確立が求められています。
個々のユニットテストが漏れなく、ソフトウェア詳細設計書に記載された全ての要件に対して実行されるため、ソフトウェア詳細設計書と結合テストの一貫性を担保する必要があります。双方向トレーサビリティというのは、下位概念と上位概念の両方向から互いをトレーサビリティできることをいいます。
例えば、結合テストの情報から、それらがソフトウェア詳細設計書のどこに該当するのかトラックでき、逆にソフトウェア詳細設計書から結合テストをトラッキングできる仕組みです。
BP8
BP8では、一貫性の確保が求められています。
一貫性とは、双方向トレーサビリティと似た言葉になりますが、上位概念と下位概念の一貫性を確立することが求められています。例えば、SWE.5ではソフトウェア結合テストの仕様とテストケース間の一貫性を担保することが必要となってきます。
BP9
BP9では、結果の要約および伝達が求められています。
ソフトウェア統合テスト結果を要約し、影響を受けるすべての関係者へ伝達する。が関係する全ての要員に伝達される必要があります。レビュー実施日、参加者、検証目的など、一般的な情報の他にも、検証するソフトウェアのバージョンであったり、仕様したツールなどの情報も事細かに記入（保存）しておく必要があります。これは、レビュー後に、同様の環境を再現することに役立てることができます。
コメント