第195号：機能性と品質属性がある時ない時

組織の標準プロセスを作るときにCMMIプラクティスを参考にして作ることはよくあると思います。

CMMIのアプレイザルではプラクティスのレベルで証拠を確認しますので、アプレイザルを受ける組織のSEPGとしては、プラクティスを網羅する組織の標準プロセスを作りたい気持ちもあることでしょう。

そこで問題になるのは、CMMIモデルの改訂です。

例えば、CMMI V1.2では品質属性についての記述は、要件開発(RD)のプラクティスにありませんでした。

------------------------------------------------------------------------
RD SP3.2 必要とされる機能性の定義を確立し保守する。
------------------------------------------------------------------------

CMMI V1.3になって、品質属性が追加されました。

------------------------------------------------------------------------
RD SP3.2 必要とされる機能性および品質属性の定義を確立し保守する。
------------------------------------------------------------------------

ISO/IEC 9126などを参考にして組織の標準プロセスを見直したところもあるのではないでしょうか。

機能性、信頼性、使用性、効率性、保守性、移植性などを要件定義書に書くようにしたり、非機能要件を記入できるテンプレートを作ったりした組織もあると思います。

そして、CMMI V2.0になってモデルの構造がだいぶ変わりました。

要件の開発と管理(RDM)のプラクティスは次のとおりです。

------------------------------------------------------------------------
RDM 1.1 要件を記録する。

RDM 2.1 利害関係者のニーズ、期待、制約、およびインタフェースまたは接続を引き出す。

RDM 2.2 利害関係者のニーズ、期待、制約、およびインタフェースまたは接続を、優先順位を付けた顧客要件へ変換する。

RDM 2.3 要件提供者と共に、要件の意味について理解を深める。

RDM 2.4 プロジェクト参加者から要件を実装できるというコミットメントを獲得する。

RDM 2.5 要件と活動、または要件と作業成果物の間の双方向の追跡可能性を作成し、記録し、維持する。

RDM 2.6 計画と活動、または計画と作業成果物が要件と首尾一貫した状態が保たれているようにする。

RDM 3.1 ソリューションとその構成要素の要件を作成し、最新に保つ。

RDM 3.2 運用の考え方とシナリオを作成する。

RDM 3.3 実装される要件を割り当てる。

RDM 3.4 インタフェース要件または接続要件を特定し、作成し、最新に保つ。

RDM 3.5 要件が必要かつ十分であるようにする。

RDM 3.6 利害関係者のニーズと制約のつり合いを取る。

RDM 3.7 得られたソリューションが対象環境で意図したとおりに稼動するように、要件の妥当性を確認する。
------------------------------------------------------------------------

品質属性に関する記述が消えました。機能性も消えました。
どのプラクティスにもありません。

どうしますか？　機能性と品質属性に関する記述を組織の標準プロセスから削除しますか？

また、アプレイザルチームメンバになったらどうします。機能性と品質属性を定義していない場合に、十分に実装できていると判断しますか？

CMMI V1.2には、品質属性はプラクティスにありませんが、サブプラクティスには性能要件に関する記述がありました。

CMMI V2.0では、機能性と品質属性はプラクティスにはありませんが、追加解説情報、活動の例、作業成果物の例にはあります。