当記事のリンクには広告が含まれています
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.1の基本プラクティス
基本プラクティスに関する詳細な記述はプロセスアセスメントモデルを参照ください。
SWE.1 ソフトウェア要件分析には合計8つの基本プラクティス（BP1～BP8）が存在します。
SWE.1（ソフトウェア要件分析）の目的は、顧客要求を分析し、ソフトウェアとして実装ができるように要件として整理・まとめあげることである。上位の顧客要求は、曖昧なことも多くソフトウェアとして実装できる状態ではないため、技術的な実現可能性、検証、品質、コスト、工数をソフトウェア観点で分析して要件定義する。
BP1
BP1では、上位の要求事項をソフトウェア要件として仕様化していくことが求められています。最上位に顧客による要件が存在し、場合によっては上位システムから降りてくるものも存在します。
この要件をより詳細に落とし込むために階層をブレイクダウンしていかなくてはなりません。上位から降りてくる大まかな要件を識別管理（カテゴリ、責任、ステータス等）を行い、下位に引き渡していきます。そして最終的にソフトウェアの実装を行います。
この実装（コーディング）が漏れなく確実に顧客要求事項や上位システムの要件を満たすよう、ソフトウェア要件の仕様化が求められます。
BP2
BP2では、ソフトウェア要件の構造化が求められています。要件が漏れなく・正しく下位システムに落とし込まれるためには、ソフトウェア要件を分かりやすく忠実に管理するためです。
関連する内容をグループ化し、論理的順序に基づく並び替え、基準、優先順位付け等です。
場合によっては顧客要求事項はプロジェクト毎に存在するのではなく、複数のプロジェクトに渡って適用されるケースも存在します。その場合は、各要件がどのプロジェクトに適用されるのか明確にしていかなくてはなりません。その他にも、それが顧客要求事項なのか、上位システムからの要件なのか等を識別したりする必要が出てくる場合もあります。
またシステム階層レベル（論理的順序）に基づく並べ替えも求められております。
例えば、顧客要求事項→ 上位システム（ドライバ）→ 中間層（OS) → アプリケーション というように順序立てた構造化が求められます。
その他にも、計画段階なのか、レビューしたのか、検証したのか、実装したのか、それとも実装不可と判断したのか等のステータスが必要となるケースも存在します。
BP3
BP3では、ソフトウェア要件の分析が求められています。BP2で構造化され分かりやすくなった各要件を、ソフトウェアとして正確性や技術的可能性、検証の実現性を分析し、リスクアセスメントに役立てる必要があります。
また、この分析により、コストやスケジュールへの影響度も明確にする必要があります。
このコストやスケジュールへの影響度合いは、MAN3. BP5【プロジェクトの見積りおよびリソースの定義、監視、および調整】に役立つ情報となるため、下記の記事も参考にしてください。
この分析には、例えばシステム／ソフトウェア観点のチェックシートやスコア等の定量的判断ができる情報およびその定義、社内標準や開発プロセス定義などの支援ツールが必要となってきます。
また、それらのレビューエビデンスを残すツールや規定も必要です。
BP4
BP4では、運用環境における影響分析が求められています。運用環境とは、ソフトウェア単体での動作ではなく、実際に使用される環境（運用環境）を想定した影響分析を行うことが求められています。
例えば、ソフトウェアと関連するハードウェア／OS等との整合性であったり、上位システム（ドライバ等）のインターフェース（データ送受信およびそのタイミング等）が挙げられます。
ソフトウェア単体での影響分析ではなく、実際に使用される『運用環境』を考慮した影響分析が求められています。
BP5
BP5では、検証基準の作成が求められています。各ソフトウェア要件に対し、それらが問題ないことを検証するための定性的・定量的な検証基準を作成する必要があります。
上位要件から下位要件にブレイクダウンされていき、それらを確認するために検証（テストバリデーション）を実行します。検証の適用範囲としては、BP3の分析によって『実現可能』と判断された項目のみに適用されることになります。
ソフトウェアのテストケースやシステムチェック、完成品状態での検証等、テスト項目を明確にし、判断基準（何をもって問題ないと判断するのか）が定義され運用される必要があります。
BP6
BP6では、双方向トレーサビリティの確立を行わなくてはなりません。双方向トレーサビリティとは、相互関係にあるソフトウェア要件同士が、それぞれ両方向からトラッキングできる仕組みのことをいいます。
例えば、上位の顧客要求事項は、どの要件と紐づきがあるのかリンクが取られている状況のことを意味します。双方向トレーサビリティであるため、逆に下位に存在する要件から、上位の顧客要求事項もトラッキングできる環境を構築しなくてはなりません。
BP2の構造化に、この仕組みを織り交ぜ運用することが必要です。
なお双方向トレーサビリティは大切なポイントで、SUP.10『変更依頼管理』でも求められている内容となりますので、必要に応じて下記も参考にしてください。
BP7
BP7では、要件の一貫性を確保することが求められています。BP2で構造化され、BP6で双方向トレーサビリティを確立し、各要件と要件の一貫性を確保できる環境を整えていく必要があります。
この一貫性の概念には、上位／下位の概念の他にも関係するグループ（属性）等にも適用されることになります。各要件が何と紐づいていて、一貫性のある（重複のない）状態を維持しなくてはなりません。
BP8
BP8では、合意したソフトウェア要件の伝達が求められています。利害関係者（顧客や外注）に合意したソフトウェア要件を全ての関係者へ伝達します。
仮に合意されない要件がある場合は、その内容を利害関係者へ伝達し、SUP.10（変更依頼管理）に従って、変更内容を管理しなくてはなりません。
コメント