わたしは最近、設計上の問題について判断を迫られた。新しい機能を実装しなければならなくなったが、そのために使えそうなモジュールが2つあり、どちらかを選択する必要があったのだ。
こうした設計上の判断は、確かな基準による評価に基づいて行わなければならない。チームリーダーたちが設計ミーティングでこの問題を議論するのを聞いたところ、チームリーダーのモジュール選択は分かれていた。彼らの主張の大部分は客観的なもので、いずれもシステム全体のリアルタイム制約や将来の保守性を考慮に入れていた。わたしは最終的にもう1つの基準を加味して、新機能の実装のために2つのモジュールのうち、どちらを採用すべきかを判断した。本稿では、こうしたソフトウェア設計プロセスへの取り組み方を説明する。
わたしは開発と品質保証の両方のリーダーを務めており、開発業務とテスト業務の橋渡しができる立場にある。設計ミーティングにおいて、変更したいモジュールの品質について多くの情報が得られる機会がある。これは的確な判断を下すのに役立つものだ。
多くのチームリーダーは、ソフトウェアのキャパシティー上のリアルタイムな制約と長期的な保守性を重視している。これは良い慣行だ。しかし、わたしはもう1つの重要な基準を見いだすことができた。それは「ソフトウェアの信頼性」だ。わたしが信頼性に関する情報を得たのは、常にテストプロセスに携わっているおかげだ。
Copyright © ITmedia, Inc. All Rights Reserved.