ブロックチェーン・AI・システム開発の株式会社INDETAIL

トレーサビリティマトリクスを考える

2014.04.30
michiya

システムの要件や設計が変更になると、それに関連するドキュメントやプログラムを "漏れ" の無いように修正しなければなりません。

修正がどのドキュメントやプログラムに影響しているかを正確に把握するために「トレーサビリティマトリクス」を作成し、双方向に追跡できる情報を管理しておくことが有効です。

V字モデル

トレーサビリティマトリクスを取り上げる前に、まずは基本となる『V字モデル』について簡単に説明します。

以下の図は、システム開発の一般的な工程の関係を表したものです。
実践の矢印は作業順を、点線の矢印は、相互に整合性を保っておくべき成果物の関連を示しています。

V次モデル

例えば要件定義書は外部設計書とシステムテスト関連ドキュメント(試験計画表や仕様書、テストケース等)と整合性を保っておく必要があるとわかります。

つまり、「要件定義書のどこかに修正が入れば、外部設計やシステムテスト関連ドキュメントの "どこか" を修正しなければならない。」というわけです。

これは他のドキュメントやプログラムについても同じです。

この、 "どこか" を具体的にどこなのかをわかりやすく追跡できるようにすることがトレーサビリティの確保で、これがきちんと出来ていない為に、要件や設計の変更に漏れが生じてトラブルが発生してしまったような経験は無いでしょうか。

トレーサビリティマトリクス

この双方向の関連性を確保するために考えだされたのが、下の図の様な『トレーサビリティマトリクス』です。

これを作成して管理することにより、変更があった場合の影響をひと目で見分けることが可能になります。

トレーサビリティマトリクス

このように管理することにより、例えば "要件A-02" に変更があった場合、影響範囲の調査を "設計21"、"設計31"、"設計32"について行えば良いことがすぐに分かります。

この例は要件と外部設計についてですが、同様の表を外部設計と内部設計、内部設計とプログラム・・・といったように作成することで、変更に対する "漏れ" によるトラブルを減らす手助けになります。

まとめ

開発において、ユーザ様からの要件が変更となることはよくあることですね。
その際、要件変更に伴う影響範囲を把握する為に多くの工数を掛けてしまう経験はよくあるのではないでしょうか。

トレーサビリティマトリクスを活用し、事前に各工程の関連性を明確にすることで
お客様からの変更要望に対して柔軟に対応することができます。

各工程毎の"漏れ" をどのようにして防ぐか、システム開発にとって永遠のテーマなのではないでしょうか。
日々進化する開発手法を上手く取り入れて品質の高いプロジェクト運営を心がけたいものです。

@michiya

コメントを残す

「いいね」ボタンを押すと、最新情報をすぐに確認できます。