当記事のリンクには広告が含まれています
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の基本プラクティス
基本プラクティスに関する詳細な記述はプロセスアセスメントモデルを参照ください。
SYS.1 要件抽出には合計6つの基本プラクティス（BP1～BP6）が存在します。
SYS.1（要件抽出）の目的は、必要な作業成果物を定義する際にベースとなる要件ベースラインを確立するために、製品および／またはサービスのライフサイクルを通じて変化する利害関係者のニーズおよび要件を収集、処理、および追跡することである。
BP1
BP1では、要件および要求そのもの自体を顧客から入手することが求められている。この要求事項を元に、システム開発のトリガーとなるため、最上位ドキュメントがこれに当たる。
この要件を抽出する際には、顧客およびサプライヤーが関与しなくてはならない。また、要件事項のトレーサビリティ維持も求められており、情報は収集され文書化されなくてはならない。
BP2
BP2では、利害関係者の期待事項を理解することが求められている。
単純に要件を受領するだけではなく、要件について顧客の期待値をしっかりと理解したうえでシステム開発を行わなくてはならない。ドキュメント上だけの解釈では足らない部分もあるので、利害関係者（顧客・サプライヤー等）を含め、しっかりと期待事項を理解するように努めましょう。
BP3
BP3では、要件に関る合意を得ることが求められている。
合意が無い状態で開発を進めると、期待値との外れが生じてしまい、問題が大きくなる可能性がある。要件に取り組むためにも、全ての関係者から明確な合意を入手してから、開発に着手する。
BP4
BP4では、要件ベースラインの確立求められている。
ベースラインとは、公式の変更制御手順によってのみ変更が可能な、公式のレビューおよび合意を受けた仕様書または製品で、以後の開発の基準として提供されるものである。
このベースラインが存在しないと、そもそものシステム開発において基準となるものが存在しなくなってしまい、変更が生じた際の管理が複雑化してしまうリスクがある。
BP5
BP5では、要件が変更された際の管理が求められている。BP4にてベースラインを確立し、このベースラインにそって要件は管理されていく必要がある。
要件が変更される場合、機能追加点が確実に識別され管理されなくてはならない。変更において影響を受ける関係者がリスク評価を利害関係者と合意を取る必要がある。
BP6
BP6では、顧客とサプライヤー間での情報伝達の仕組みを確立することが求められている。顧客が出した要件変更のステータスや対応内容が把握でき、データを共有しておくシステムが必要となる。
例えば、JIRA等のシステムを顧客と共有し、チケットの内容を相互に知ることができる状態を確立しなくてはならない。
コメント