一般に、派生開発では機能の追加と変更が中心になる。その結果、応答時間などに変化が生じることがある。設計の担当者は応答時間の変化に気づかなかったり、気づいていた時でも、これくらいなら問題ないだろうと勝手に決め込んだりしていることが多く、納品後に「時間効率性」の劣化としてクレームとなる場合がある。時間効率性に関するクレームは、必ずしも遅くなったから問題になるとは限らない。派生開発の場合、使い慣れている状況に対して変化が許容範囲を超えると操作に影響を与えるからである。
設計者が応答時間等の劣化に気づかない理由として、ソースコードの該当箇所を探す際も、機能の変更に気を取られ、その機能が操作と絡んでいることに気がついていないことがある。そこで、変更要求を捉える段階で、メモリー処理や通信処理などの時間効率性に影響を与えそうな機能を変更するときには、時間の変化を予測して、「EMOT(Estimation Method Of Time behavior degradation)」の確認表を使って変化時間の目安を確認する。そこで事前に想定している許容範囲を超える時は、早めに依頼者と変更方法などを協議する。また他に変更方法がない時は、操作側で事前にトレーニングして備えてもらうことになる。こうした対応によって、後からのクレームになることを回避する。

概要：

既存システムへの機能の追加・変更を行う派生開発では，機能の追加・変更により応答時間・処理速度といった性能劣化を招くことがある．これは，性能要求が要求仕様に明記されていないことで性能劣化への配慮不足に陥り易いためである．性能劣化は，開発終盤・納品後に判明することが多く，その改修によって開発コストの増加や納期遅延が発生する．そのため，機能の追加・変更に伴う性能劣化について顧客と交渉が容易な要件定義フェーズで把握する必要がある．そこで我々は，性能劣化をISO/IEC 25010で定義されている「時間効率性」の低下と捉え，機能の追加・変更が時間効率性に与える影響を処理時間に換算して検出するための方法「EMOT (Estimation Method Of Time behavior degradation)」を提案する．本手法を過去の不具合事例に適用した結果，時間効率性の劣化を機能の追加・変更要求から検出することができ，要件定義フェーズで性能劣化の対策を講じることで時間効率性の劣化防止に寄与することがわかった．