このコラムは無料メールマガジン「アメニティ&サウンド音と快適の空間へ」 vol.36〜vol.64(2003年8/21〜2004年11/18)に音響と開発の関連コラムとして連載していたものを編集掲載したものです。
ソフトウェアのバグやエラーをなくし品質を向上することは情報機器の多い現代では社会的にも重要な問題となっていますが、高度で複雑化が進むソフトウェアのエラーをなくすためのテストや開発にかかるコストが大きくなることも重要な問題です。
今回は、ソフトウェアのエラー、バグとコストの話題にしてみたいと思います。
ソフトウェアに関するエラーには、大きく分けて2種類があります。
1つは、ソフトウェアを実行する上でエラーとなって実行できなくなるタイプです。
身近なところでは、OSが検出してアプリケーションを停止するような「除算エラー」や「不正なメモリアクセス」などです。
▼e-Words IT用語辞典 : ゼロ除算【divide by zero】
http://e-words.jp/w/E382BCE383ADE999A4E7AE97.html
これらのエラーは、プログラムの不正な実行によって発生するCPUが正常範囲での継続処理が困難なためのエラーです。
実行コードや内容に問題が生じているものです。
ゼロ除算は、プログラムが分母をゼロで割り算を実行すると、解が求められないため、不正な処理を行ったことをCPUが検出するようになっています。
また、CPU のアーキテクチャ上、除算の解を以降に扱うことができない値になる場合にも同様にエラーとなります(大きな数値を小さな数値で除算するなど)。
OSのエラー表示では、ゼロ除算でブルースクリーンになることはほとんどなく、ダイアログ表示されると思います。
ブルースクリーンはGUI表示の機構が使えない致命的なエラーの場合に表示されます。
単一のアプリケーションのみのエラーとなるゼロ除算などより、ブルースクリーンの方が重症のように語られる傾向がありますが、たとえ、アプリケーション単独でも目的は果たせないことに違いはないので、ミッションから見たエラーの重要度に違いはありません。
以前にOSがブルースクリーンの根絶を目指すと発表された時、背景の色を赤に変えると根絶というジョークがありましたが...
もう1つのエラーは、プログラミング・エラーなどと呼ばれるバグです。
ソフトウェアはプログラムされた通り、正常に実行していますが、望む目的とは異なる結果や予想外の結果となるためエラーとみなすものです。
計算結果が間違っていたり、フリーズなどの挙動になるバグもこれに分類できます。
▼e-Words IT用語辞典 : 凍る【フリーズ】
http://e-words.jp/w/E5878DE3828B.html
「除算エラー」もバグに含められますが、プログラミング・エラーは、CPU実行自体には差し支えないエラーであることが異なります。
フリーズは、コンピュータを継続利用できなくなっていますが、人に対するリアクション部分の実行には問題が生じていますが、ある意味プログラム通りの正常動作中の現象と言えます。
フリーズに至るようなプログラムがされているという点が問題点です。
ソフトウェア・エラーもプログラミング・エラーもどちらもエラーですが、その性質や防ぐための技術的な内容はかなり異なります。
ソフトウェア・エラーは、コードを実行する上での、プログラミング・エラーは、プログラム設計、実装上でのエラーという違いについて述べました。
この定義や呼称は、一般的なものかどうかは判りませんが2種類に大別できることは理解していただけると思います。
ソフトウェア・エラーの場合も、プログラミング・エラーの場合も、その対策は、やはり、大きく分けて2種類の手段で対策されているといえるかと思います。
1つは、コンパイラなどツールや言語で防御する方法で、開発言語の構文上、実行に支障のでる可能性があるコードを検出できる仕様にしてコンパイル・エラーやワーニング(警告)に落とし込むことができるようにするものです。
問題となる実行コードを生成できなくすることもこの範疇に含まれるかと思います(メモリやI/Oのアクセスコードの制限など)。
もう1つは、実際に実行させて、その動作を検証するデバッグです。
一般にテストとされるものは、例えば、XPプログラミングなどテスト手法が違っていたとしても、実行テストで問題を見つけて対処するという意味では、単体テストも結合テストも実行テストによる方法といえます。
▼e-Words IT用語辞典 : XP【エクストリームプログラミング】
http://e-words.jp/w/XP.html
XPは、1つのモデルというより、ペアプログラミングやリファクタリング、そして、重きをおいているテストの手法など、いくつもの開発アプローチに対する提案の集合といえるので、一部の手段のみ採用することも可能な方法で、高い評価も理解、導入しやすいことも一因かと思います。
中小規模の開発に向いているとされていますが、テストの考え方やペアプログラミングなどは、規模にかかわらず、比較的、導入しやすい手法かと思いますし、実現した場合も一定以上の効果を上げやすいものかと思いますが...
「リファクタリング」や「大きな設計変更に立ち向かう勇気」や「頻繁なテストによるフィードバック」といったものは、コストを考えると必ずしもうまく行くとは限らないことは容易に想像でき、前面的にXPとは行かないことが多いのも事実でしょう。
▼e-Words IT用語辞典 : リファクタリング【refactoring】
http://e-words.jp/
w/E383AAE38395E382A1E382AFE382BFE383AAE383B3E382B0.html
実行によるテストは、テストツールが導入されたり、効率が工夫されて時間や実行の精度を向上させることは可能としても、エラーを検出することには必ずしも効果が高いとは限りません。
ソフトウェアの設計(プログラミング)やテスト仕様の設計に問題がある場合には、ツールやテスト方法を工夫しても問題の解決にはなりません。
テスト仕様の期待値を間違えると、当然、正常なテスト結果であるというレポートを生むに過ぎませんので、やはり、テスト内容自体が最も重要ということになります。
これは先に挙げたXPのテスト手法を導入したとしても事情は同じです。
プログラミング・エラーと同様、テストの設計が重要なポジションを占め、ソフトウェアの設計と同等のテストの設計能力が必要となるため、的確なテストを作成できるのが設計者自身である場合も往々にしてあります(そして、これが、XPのテスト手法が効果をあげる理由ですね)。
実行テストには、最低限の実行時間とその検証の時間を伴いますのでデバッグ作業の繰り返しとテスト時間はコストに与える影響が大となり、テストに最も設計能力の高い技術者を当てて対処することも決して珍しくはないこともご存知の通りです。
上記までは、エラーや対策などについてでしたが、ここからは表題にしている対策とコストについてです。
エラーに対する対策やテストなどが技術的に困難な場合もありますが、最も難しい問題は、それに関わるコストの問題だと考えています。
例えば、大規模で複雑な状態、条件が発生するシステムの場合、組み合わせテストを最終段階で完全に網羅するテストは困難です。
網羅しているに等価とみなせるテストを行うか、個別の条件を確認することで正常動作を期待できるとみなすなどの方法が採られることが一般的かと思います。
実際に起こる組み合わせの条件を網羅していませんが原理的に、問題が生じない場合、妥当なテスト方法と言える場合もあると思いますが、完全なテストが行われていないことも事実でしょう。
複雑なソフトウェアでのテストにつては、単純にコストによる見切りが行われているに過ぎない場合も存在するだろうと思います。
コストバランスによる見切りというものも、必要なことであることは、そのコストがユーザーの対価にかかっていることを考えれば自明ですし、例えば、ワードプロセッサのテストを行うとして全てを網羅するいうことは不可能ですから(たとえ自動テストといえども無限の文字数の組み合わせを行うことは現実的ではないので文字数や組み合わせなどの)、何らかの必要条件を設けることになります。
ゲームなどのようにリアルタイム性を持つシステムの場合には、タイミングによってエラーの条件が発生する場合がありますから、さらに、テストの完全性を持たせることが困難な部類になります。
従って、どこまでが必要なテスト、コストとなるかを判断することが品質や製品コストなどの重要な問題となります。
コストは安いに越したことはありませんが、その見合いに品質が低下するようでは問題の解決にならないため、必要条件を満たしていると難しい判断が求められます。
このような膨大となり得るテストによってエラーを検出するを努力をするよりも、エラーが発生する可能性を減らす設計を重視する方が、ローコストでありながら品質を保つことができる可能性が高いことは容易に理解できます。
リアルタイムのシステムであれば、状態遷移が中間状態にならないようにしたり、データを多く扱うアプリケーションであれば、データに依存して処理が異なる部分をできる限り少なくすることで、エラーが起こりうる条件を抑える工夫が可能な場合があります。
これは、バグを出さないという単純な発想以上に、状況を作り出さないような設計段階でのアルゴリズムの設計、対策を採るということです。
エラーやバグを含む可能性を減らすことよりも、条件に対する堅牢性を高める設計、複雑度を低下する設計が、組み合わせ問題を緩和し、ローコストなテストやエラー対策での開発完了を可能とし、品質を低下させないポイントとなります。
エラーとコストバランスの問題は、このような局所的なロジックに落としたり、単純な条件となるように工夫することが最も効果的な手法の1つといえるでしょう。
ARIはハードウェア設計、製造、ファームウェア開発、 Windowsアプリケーションの開発をしています。 実績等に興味をお持ちいただけましたら、会社情報に主な開発実績を 「音響と開発」のコーナーには事例など関連情報を掲載していますのでご覧ください。
ソフト、ハードウェア 技術関連の雑記
このコラムは無料メールマガジン「アメニティ&サウンド 音と快適の空間へ」 vol.36〜vol.64(2003年8/21〜2004年11/18)に 音響と開発の関連コラムとして連載していたものを編集掲載したものです。
ソフトウェア開発と開発ツール関連の雑記
機器組込みのエンベデット・ソフトウェア(ファームウェア)の開発に関連したコラムです。 メールマガジン「アメニティ&サウンド 音と快適の空間へ」に連載していた技術・開発コラムを編集掲載しています。
技術・開発の閑話 : ソフト開発コラムファームウェア開発(組込み)の技術 / |
開発ツールの話 : ソフト開発コラムソフトウェアの分類 / |
プロジェクト初期 ツール評価 : ソフト開発ツールの話プロジェクト初期のツール評価 / プログラムの動作・ソースの作成 / コード生成 アセンブラ、コンパイラ / 型変換を伴う式評価(コード生成) / 暗黙のライブラリ(コンパイラ生成コード) / 組込みCPUのメモリアクセス / コード生成〜デバッガ |
デバッガとICE ツール評価2 : ソフト開発ツールの話CPU,DSPの内部の状態モニター / プロセッサ周辺のモニター(メモリ、I/O) / 実行の停止(ブレーク) / シングルステップ実行 / 任意部分の実行 / ヒストリー - 実行トレースとコマンド / 各種ファイルのロード、セーブ / シンボル化 |