USDMとDRBFMを羅針盤にして派生開発を成功に導く

NECソフト株式会社
酒井　賢

１. はじめに

2011年2月にソフトウェアテストシンポジウム 新潟で「派生開発でUSDM（Universal Specification Description Manner）とDRBFM（Design Review based on Failure Mode）をミックスして一気通貫で品質確保する」という事例発表をさせていただきました。発表後、資料を見た何人かの方から、進めるに当たっての課題や現場にどのように導入したらよいかなどのご質問をいただきました。このような機会をいただきましたので、この場をお借りして詳しく説明します。

２. 導入前の状況

２.１　プロジェクトの概要

次のようなプロジェクトです。2003年から2009年までの約6年間担当しました。

・ オフィス機器（以降「装置」と書きます）に添付されるWindows上で動作するユーティリティソフトウェア
・ ソフトウェア単体では用をなさず、装置と通信を行うことによって利用出来る
・ 設計、製造、テストまでの工程を担当
・ 開発プロセスはウォーターフォール開発

装置開発の多くは、1つのマスターに対して、自社向け、OEM向けなど複数の製品が作られ、さらに、自社向けには廉価モデル、フラグシップモデルなどいくつかのモデルが製品化されます。
数年のサイクルで、その後継機が開発されてゆき、後継機開発までの谷間では、機能強化やバグフィックスなどの目的でメンテナンスリリースが行われたり、特定用途向けの改造開発が行われたりします。
私たちは、お客様(発注者)が何回か派生開発を経た後に引き継ぎました。

２. ２　状況の分析

引継ぎ当初は、規模も小さく、改造も限られた範囲だったので、大きな品質問題が発生することはありませんでした。
しかし、開発を重ねるごとに、機能、対応機種、サポートOSが増加していき、規模と複雑さが急激に高まっていきました。メンバーの増員はあったものの、モジュール別に担当者を分けていたため、意思の疎通がうまく行っていませんでした。そうしたことが重なり、品質問題が頻発するようになりました。

メンバーへのヒアリングや過去に発生した問題を分析した結果、次のような問題があることが分かりました。

1. １）仕様化があまい

   要求から仕様への落とし込みがあまいため、コーディング時になって仕様化がされていないことに気がつく後戻りが発生しました。また、テストフェーズで、動作途中でネットワークが切れた場合などの異常系を仕様化していないことがわかり、バグ修正と仕様化を同時に行うことがありました。

2. ２）変更の経緯が分からない

   仕様化する前段階で改造点の洗い出しを行っていると、どうして現在のような仕様になっているのか分からない部分が現れました。引継ぎ以前の経緯が分からないため、その部分には手を加えず、処理を分岐する形での設計を行わなくてはなりませんでした。

3. ３）変更の影響範囲がわからない

   変更に対するソースコードの修正箇所の特定が不十分で、修正漏れが多く見られました。また、変更を加えたことで、本来は影響のないはずの機能の振る舞が変わってしまうデグレードが発生しました。

4. ４）”思いもよらない”問題が発生

   テスト終盤になって、OSメーカーからサービスパックがリリースされ、それを適用するとセキュリティの関係で、これまで正常に動作していた機能が動作しなくなるという問題が発生しました。納期間際の想定外の問題の発生で現場が混乱し、仕様調整や対応で大きな作業負荷となりました。事後にふり返ってみると、セキュリティ強化のアナウンスはニュースサイトで読んで知っていた事を思い出しました。