思考のサルベージ(その７)

各工程で心がけたい思想を掘り起こしてみる

システムテスト工程末期、客先リリース直前での不具合修正と性能変化ついて考えます。

ちょっとした判定ミス

SWの動作としてはよくあるやつで、メインループで、実行命令を受信し、命令内容に従いHWを設定して後は命令実行完了の応答送信までHW任せ、次の実行命令が来ていれば同じことを繰り返し、来ていなければいったんsleep状態に入ります。 今回は、「特別なケース」の考慮が漏れていて、不具合につながっていました。

影響範囲

客先リリース直前です、不具合が直ればそれで良いとはなりません。修正による影響範囲を明確にしなければなりません。処理性能の側面でも考慮が必要です。今回は、メインループの中に判定分を1つ追加し、「特別なケース」の場合に関数コールをするという数ステップの修正で、他の不具合を引き起こすような修正ではありません。また、「特別なケース」は性能測定対象外なので、追加した判定分1つのオーバーヘッドは乗りますが、大きな性能劣化には繋がらないと判断されました。

思わぬ結果

不具合は解消されましたが、処理速度としては不利となるオーバーヘッドが増える修正なのに、何故か処理性能が数パーセント向上してしまいました。修正の結果必要な処理がスキップされている可能性も考えられます。逆に性能が劣化していれば、よけな処理が活性化している場合もあります。 調べてみると、オーバーヘッドが効いて、ループ処理の中の実行命令の受信タイミングが変わり、毎周期行われるようになり、sleepに入ることがなくなっていました。結果的に全体としての処理性能が向上していたのです。

HW依存

HW依存が大きい処理系では、ちょっとしたタイミングのずれで、処理性能に影響が出てしまいます。テスト工程初期であれば、さほど問題視されませんが、客先リリース前ともなると、例え性能が向上したとしても、もちろん劣化したとしてもですが、原因の究明は必須です。大切なことは、事前にあらゆる可能性を考慮し、起こりうることを見極めることです。

何か掘り起こせた？

• HW依存の大きい処理系では処理タイミングを考慮することが重要。
• 性能の変化点では、要因の究明は必須。

必要な修正は実装しなければいけないのだから、性能目標さえクリアしていて、論理的な説明さえできればなんの問題もありません。

おしまい

誤ってループ処理千回余計にやってました、なんて言ったら大目玉ですけどね。