自動化の可能性

前回の話が結果として自動化に繋がってきます。

概念的な話をすれば「変更管理により自動的(ツールによって)に検査項目を指定」するという話です。前回の対応表なども変更管理でどのユニットが変更されたか把握できていれば、すぐに検査項目を指定できるので、自動化のツールと考えることもできます。

しかし、ユニットと要求の対応表の作り方次第では有効な検査項目の指定ができないことも考えられます。

例えば C 言語で下のような呼び出し関係があったとします。

int main () {
    /* snip */
    foo ();
    /* snip */
}

void foo () {
    /* snip */
    bar ();
    /* snip */
}

void bar () {
    /* snip */
}

すなわち、main から foo が呼ばれ、foo から bar が呼ばれる。
この上で要件1 を満たすための機能が bar によって実現されている場合、bar の呼び出しに関与している main や foo は要件1 を満たすためのユニットに挙げられるのか？というのは結構重要な話になります。すなわち対応表において、ユニット main やユニット foo に○を付けるべきなのか？ということです。
もし呼び出し関係は一切考慮せず、その機能のみを実装しているユニットのみに○を付けるとすると、呼び出しの途中経路上で条件分岐等により呼び出しを制御している場合、その条件分岐自体や条件に関わるコードが変更されても検査の必要は無しという見解が出てきてしまうでしょう。その結果、本来 bar が呼び出されるべき（要求からしてその機能が発揮されるべき）状況で呼ばれないということが起こってしまうかもしれません。
であるなら、呼び出しの経路のユニット含め全て対応表で○とすべきかというと、ほとんどの場合 main から目的の関数ユニット（例えば bar）まで延々と続く関数呼び出しの列に現れる全ての関数ユニットにチェックが付いてしまいます。しかし、例えば本当になんの条件分岐等も無く呼び出しているような場合（上のコードであれば snip のところで制御が変わるようなことを一切していない場合）は、呼び出し自体を消去されてしまったり、条件分岐を挿入され制御を変えられでもしない限りは変更されても影響は無いはずです（実際は副作用等で影響することもあります）。
ではどうするのが良いのか？
手動でやるなら、例えば単に呼んでいるだけ、条件によっては呼んだり呼ばなかったりしている、機能を実現している本体ぐらいの３段階に分けて△、○、◎でも付して対応表を作り、コードの変更があった場合は、△や○を変更する可能性も考慮しつつコードレビューして対応検査を挙げるということになるでしょう。結構な工数を割かれると思います。
自動でやるのでも、同様です。人によるコードの解析、レビューの代わりにツールで対応ということになります。あとは、そういうことができるツールがあるか？というところ。

＜つづく＞