下記に、4つのバグの兆候と対策を示します。
要求仕様と結果が合致しない場合に発生します。ただし、設計やコーディングのバグの可能性もあるため注意が必要です。
バグが発生した場合、まずは達成可能な要求仕様という前提で、データの設定値、制御フローなどの設計・コーディングのバグを調査し、それでも原因が分からない場合、要求仕様自体のバグを疑いましょう。
対策案は、要求仕様フェーズで不安な部分がある場合は、プロトタイプやシミュレーターを作り、実現可能性を確認することです。特に、制御、通信速度、ノウハウがない新機能の場合は効果的です※2)。
※2)ただし、シミュレーターはあくまでもシミュレーターです。実機では、その通りに行かない場合が「非常に」多く、注意が必要です。
自己矛盾を起こしている仕様は、プログラムやテスト項目を作成しているうちによく見つかります。要求仕様書をしっかり読みながら作成しましょう。
対策案は、要求仕様書作成時にページ数を減らせないか検討することです。他の作業にも関連しますが、量が多いと、急激に全体を把握できなくなります。
実装フェーズで見つけてもよいでしょうが、より早い段階で見つけたい場合は、要求仕様を開発メンバーとしっかり読み合わせましょう。矛盾点が見つかる可能性が少なくありません。また、時間があれば少し大ざっぱなテスト項目を作成しましょう。テスト項目は、「具体的な数値による仕様書」です。矛盾点がポロポロ見つかります。
要求仕様の抜けは、顧客が気付かないと、兆候を見つけることは非常に困難です。タチが悪い上、仕様書のバグで最も多いのがこれといわれています。
対策案として、要求仕様の作成後に運用フローを作成して、顧客に確認を取りましょう。顧客側も巻き込んで運用フローを説明すると、「この機能も必要ですね」といわれることが少なくありません。
仕様をよく読むと、いろいろな解釈があると気付くでしょう。その際は、担当者にしっかり確認を取りましょう。曖昧な要求仕様をベースにしたため、自分の考えが間違っている可能性があります。
対策案としては、チームメンバーでの仕様の読み合わせや、要求仕様のテスト項目の作成が効果的です。
下記に、今回のまとめを示します。
要求仕様は、ソフトウェア開発フェーズで最も大切な工程です。今回は、要求仕様のバグを取り上げました。なんとなく作成し、次の設計フェーズへ進みがちですが、実際の開発では、要求仕様書のバグによって想定通りにいかず、苦労することも少なくありません。今回取り上げたバグを頭に入れ、いざとなった時のお役に立てればと思います。
2019年11月27日に、山浦恒央先生が執筆した書籍「ソフトウェア技術者のためのバグ検出ドリル」が日科技連出版から発売されました。本連載「山浦恒央の“くみこみ”な話」とTechFactoryの連載「組み込みエンジニアの現場力養成演習ドリル」をベースに、大幅加筆、改訂した内容になっています。
内容は、「デバッグの詰将棋」で、要求仕様定義、設計、コーディング、テスト、保守の5フェーズでの「バグを埋め込んだ仕様記述やソースコード」を読んで、バグをピンポイントで見つける問題集になっています。全部で31問あり、難易度は初級から上級まで、いろいろです。興味のある方は、Amazon.comや書店でチェックしてください!
東海大学 大学院 組込み技術研究科 非常勤講師(工学博士)
Copyright © ITmedia, Inc. All Rights Reserved.