設計とデバッグの相関関係

スケジュールが遅延するプロジェクトとゆうのは、往々にしてテストフェーズがなかなか納まらなく、バグが収束しないために、リリースが後ろにずるずると延びてしまうことが原因であることが多い。ソフトウェアには、バグは必ず存在する。だが、許容範囲以上のバグは、バグがバグを呼びバグの修正が、またバグを呼ぶとゆう最悪のループにはまり込んでしまう。テストフェーズは、全体工程の１／２を占めるといわれているが、このようなトラブルを抱えたプロジェクトは、それ以上にテストフェーズが占める割合が、高くなる。では、なにがテストフェーズを、こんなにも混乱させる要因になっているのだろうか。

テストフェーズを賑わす原因は、やはり、仕様策定・設計工程に起因する。バグを許容範囲内に収めるには、コンセプトの統一性を意識した、仕様策定を行うことである。コンセプトが明確であると、リーダーのビジョンと相まって、進むべき方向性が明確になる。なにか、曖昧な仕様が存在したときには、おのずと、コンセプトに則った方向性に、仕様が落ち着く。また、テストを行う際にも、際どいバグが存在した場合、コンセプトに照らし合わせて、検証が可能となる。このように、コンセプトの統一性が、プロジェクトに与える影響は、非常に大きい。

さらに重要なのは、設計工程の完成度である。「どうせ、バグは出るんだから、適当に設計をして、細かいところはテストフェーズで直せばよい」、などと思っている設計者がいるとしたら、論外である。上記したように、許容範囲以上のバグは、収束のつかないループを生んでしまう。テストフェーズが、予想以上に多くの時間がかかる理由として、デ
バッグ作業が、困難なことにある。デバッグ作業は、問題の表面的な現象から、本質的なロジックの問題を解明する作業である。この作業は、高いスキルを必要とし、複雑な問題であれば、数週間や１ヶ月かかってしまうこともある。デバッグは、進捗度を予想できないため、スケジュールを立てにくい。このため、テストフェーズは、のびのびになってし
まうのだ。そのような、問題の根本であるデバッグ作業を減らすためには、おのずと、バグを減らすことになる。バグを減らすためには、完璧な一貫性のある設計を、心がけるべきである。特に、サブシステム間でのインターフェースや、シーケンスなど影響範囲が大きく、複雑な処理は、問題が起きた場合の解析作業や、手戻り作業が非常に大きいため、念入りに行う必要がある。

スケジュールを焦るあまり、設計を疎かにして製造工程に入るのではなく、「急がば回れ」の精神で、スケジュールが厳しいからこそ、さらに念入りに設計を行い、下流工程での組込みを抑え、大半の期間を要するテストフェーズを圧縮することこそ、最短リリースへの近道である。

vol.42

最近はモデルベースの設計がずいぶん浸透してきました。一部では設計からテストまでの全工程に適用した（ソースファイルをいじらない）開発プロセスを確立したところもあると聞きます。

モデルベース設計の利点はなんと言っても可視化できて記述を標準化できることです。ソースコードは人それぞれ。文章のようなものです。それを図式化することによってデバッグの速度も速くなるしそれを前工程（フロントローディング）で行うことで上記の問題が少しは改善されるでしょう。ですがモデルベースを開発全般で行うには自動コード生成においてＨＷ、プラットフォームとの対応をどうとっていくかが今後の課題でしょう。そろそろソフト開発も変えて行かなければならないですね。