トレーサビリティ・マトリクスのはなし

　CMMI^®によるソフトウェア・プロセス改善の現場で良く質問に上がるのが、トレーサビリティ・マトリクスについてです。
いわく
　　「ソースコードや試験項目もトレースしないとダメ？」、
　　「どのくらいの細かさでトレースが必要なの？」、
　　「そもそもマトリクス表を作らないとダメ？」
などなど。

　CMMI^®モデルの要件管理プロセス領域（REQM)では「要件と、関連要件、実装、および検証との間にある識別可能な関連を維持すること」(SP1.4)を求めています。

　プロジェクトが「要件のすべてを正しく設計し、実装し、評価し、納入した」と保証するためには、要件と設計物、ソースコード、試験項目とのトレーサビリティ（追跡可能性）が必要です。更には、要件も大雑把な粒度では無く、ある程度細かい粒度で成果物と対応させなければ「要件のすべて」を成果物に抜けもれなく反映できたかどうかは分かりません。

　このトレーサビリティを維持する仕組みとして、上位要件と下位要件との追跡可能性や、要件と下流の作業成果物との追跡可能性を格子表（マトリクス）に整理したものが『トレーサビリティ・マトリクス』です。

　トレーサビリティ・マトリクスがあれば、要件の抜けもれや影響範囲が分かりやすくなり、要件の追加変更時の保守が大変ラクになります。特にシステム開発など開発範囲が大きい場合は、マトリクス化されていないと要件変更時の影響範囲を特定しきれない可能性があります。

　しかし、トレーサビリティ・マトリクスを要件の追加変更に併せて常に更新していく作業は結構手間とコストが掛かります。 表計算ソフトなどでマトリクス表を作成し、要件の追加変更内容を手作業で反映していくのが一般的なやり方と言えますが、プロジェクトによってはトレーサビリティ・マトリクスから得られる効果よりもマトリクスを維持するためのコストの方が、ずっと大きい場合があります。 更に、要件変更が度重なるとマトリクス表の更新が追いつかなくなる事例も少なくありません。

　また、アセスメントをしていると、CMMI^®モデルに書いているからと、形式的に作成されたマトリクスに出会うこともままありますが、得てしてそれらは、ソースコードや試験項目との対応が取れていなかったり、要件の粒度が荒すぎて影響範囲が特定できなかったりで、結局あまり使いものにならないムダな成果物だったりします。

　トレーサビリティを維持するには、例えば「固有の要件IDを設計物、ソースコード、試験項目に入れ込む」など、マトリクス以外にも色々仕組みや工夫はあります。 要は、プロジェクトの特徴（プロジェクトサイズ、メンバのスキルや習熟度、開発範囲や規模の大小、要件の難易度など）に応じて、どのようにすれば効果的かつ効率的にトレーサビリティを保てるか検討することが大切なんだと思います。
　（担当：A）

キーワード：要件、要件管理、トレーサビリティ、トレーサビリティ・マトリクス、追跡可能性、
　　　　　　　 CMMI^®

CMMI^®は、米国カーネギーメロン大学の米国における登録商標です。

ページの先頭へ戻る