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.3の基本プラクティス
基本プラクティスに関する詳細な記述はプロセスアセスメントモデルを参照ください。
SWE.3 ソフトウェア詳細設計およびユニット構築には合計8つの基本プラクティス（BP1～BP8）が存在します。
SWE.3 (ソフトウェア詳細設計およびユニット構築) の目的は、定義したソフトウェアコンポーネントに対する詳細設計を規定し、ソフトウェアユニットを記述・生成することである。
BP1
BP1では、ソフトウェア詳細設計書の作成が求められています。
SWE.2ではソフトウェアアーキテクチャ単位での設計書について求められているのに対し、ソフトウェアのユニット単位での設計書を作成することが求められています。ソフトウェアユニットとは、プログラム単位であったりモジュール単位にまとまっている小さなまとまり（ユニット）になります。
ソフトウェアに関する要件定義を行い、アーキテクチャ単位で設計書を作成し、更にユニット単位での設計書を作成して、上位から下位までブレイクダウンするように設計書を作成しなくてはなりません。
ソフトウェアユニットにおける、関数や変数、範囲や値などの範囲をまとめ、ソースコード上の性的要素を設計書で定義しておく必要があります。
アセッサーとしては、ソースコードがソフトウェア詳細設計に基づき組まれていることを確認するため、コーディングを行うために十分に詳細となっている設計書の作成が求められます。
BP2
BP2では、ソフトウェアユニットのインタフェースを定義し、識別され明記された文書化した情報として維持することが求められています。
ソフトウェアユニット（各モジュールやプログラム）の動的な振る舞いを明確にするために、各ソフトウェアユニットがどういう関係性で動作をするのか可視化しなくてはなりません。例えば、ソフトウェアシーケンス図やダイアグラムを用いて、ソフトウェアの振る舞いを可視化する必要があります。
ここで求められているのは、ソフトウェアユニットレベルでのインタフェースを定義することであり、関数間やモジュールのインタフェースを定義しなくてはなりません。
BP3
BP3では、ソフトウェアの動的な振る舞いの記述が求められています。
実際には、ソフトウェアシーケンス図を用いてユニット同士の相互関係が明確になっており、どのような動的振る舞いを行うのか説明できるようなドキュメントの作成と維持が必要になります。
BP4
BP4では、ソフトウェア詳細設計の評価を行うことが求められています。ソフトウェア詳細設計書が上位のソフトウェアアーキテクチャ設計と一貫性があるのか評価することが求められています。
組織としての評価項目・検証基準を確立し、その内容に基づいたレビューを行います。そして、その結果を記録しなくてはなりません。
例えば、レビューチェックシートを作成し、参加しなくてはいけないステークホルダーの定義、一般情報（日付、マイルストン、ドキュメントバージョンなど）を記入し、データベースに保管します。
BP5
BP4では、双方向トレーサビリティの確立が求められています。ソフトウェアアーキテクチャ設計に記載されている個々の設計要素が、確かにソフトウェア詳細設計に漏れ無く反映され、上位からでも、下位からでも、互いに追跡できる仕組みが必要です。
BP6で上げる一貫性を証明するためにも、上位で定義されている要素が下位へ展開されているようにしなくてはなりません。
BP6
BP6では、一貫性の確保が求められています。一貫性の概念には、上位／下位の概念の他にも関係するグループ（属性）等にも適用されることになります。各要件が何と紐づいていて、一貫性のある（重複のない）状態を維持しなくてはなりません。
BP7
BP7では、合意したソフトウェア詳細設計の伝達が求められています。利害関係者（顧客や外注）に合意したソフトウェア要件を全ての関係者へ伝達します。
仮に合意されない要件がある場合は、その内容を利害関係者へ伝達し、SUP.10（変更依頼管理）に従って、変更内容を管理しなくてはなりません。
BP8
BP8では、ソフトウェアユニットの作成が求められています。コーディングができるくらいに詳細な情報が記載されているソフトウェア詳細設計が関係者間で合意され、そのソフトウェア詳細設計に基づいたソフトウェアユニットが構築されていることを確実にするための要求事項です。
ソフトウェアユニットは、ソフトウェアユニット検証により、その妥当性の確認が行われます。ソースコードをコンパイルして作成する実行形式を示したドキュメントを作成しなくてはなりません。コードのモデリングには、モデリングガイドラインにしたがってモデルを作成する必要があります。
コメント