エラーとコスト /ゼロ除算/ブルースクリーン /XP

技術開発コラム:技術・開発の閑話-2- vol.04
音響技術と開発 技術開発コラム
DSPボード/基板設計パターン image 映像と振動信号の製作イメージ 無響室 - 音響実験/測定、音響解析 image アナログ回路とオーディ信号処理 イメージ 音声信号波形とデジタルストレージ image

音響技術とソフトウェア、ハードウェア開発

音響と開発 : Sound & Development
株式会社エーアールアイ / ARI
ARI CO.,LTD.
技術・開発の閑話

エラーとコスト

ゼロ除算/ブルースクリーン /エクストリームプログラミング
04

このコラムは無料メールマガジン「アメニティ&サウンド音と快適の空間へ」 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つといえるでしょう。

開発実績と事例 ソフトウェア・ファームウェア
CPU/DSP

ARIはハードウェア設計、製造、ファームウェア開発、 Windowsアプリケーションの開発をしています。 実績等に興味をお持ちいただけましたら、会社情報に主な開発実績を 「音響と開発」のコーナーには事例など関連情報を掲載していますのでご覧ください。

技術・開発の閑話 -2-

ソフト、ハードウェア 技術関連の雑記

このコラムは無料メールマガジン「アメニティ&サウンド 音と快適の空間へ」 vol.36〜vol.64(2003年8/21〜2004年11/18)に 音響と開発の関連コラムとして連載していたものを編集掲載したものです。

技術・開発の閑話 -2- :技術開発コラム

技術・開発の閑話-2- vol.11〜20

20F1とコンピュータ技術 後編
技術・開発の閑話-2-
19F1とコンピュータ技術 前編
技術・開発の閑話-2-
18ソフトウェアの標準と部品化 8
標準と生産管理
17ソフトウェアの標準と部品化 7
遺産と再生産
16ソフトウェアの標準と部品化 6
重要な課題
15ソフトウェアの標準と部品化 5
リファクタリング
14ソフトウェアの標準と部品化 4
アジャイル開発
13ソフトウェアの標準と部品化 3
新開発ツールと再生産
12ソフトウェアの標準と部品化 2
戦術と戦略の誤解
11ソフトウェアの標準と部品化 1
技術・開発の閑話-2-

技術・開発の閑話-2- vol.01〜10

10NHK技研公開 2004
超高精細映像システム
09Googleローカルファイル検索へ
技術・開発の閑話-2-
08専門ドメインの基礎範囲 2
高度な統合化による構造変化
07専門ドメインの基礎範囲 1
技術・開発の閑話-2-
06Prescottリリース
技術・開発の閑話-2-
05NDAと情報公開
技術・開発の閑話-2-
04エラーとコスト
ゼロ除算/ブルースクリーン /XP
03リアルタイムとベストエフォート
技術・開発の閑話-2-
02HDD容量の差
天使の分け前(Angels' share)
01「ありえない」
フェイルセーフと安全機能の連鎖

ソフトウェア開発コラム : 技術・開発の閑話

ソフトウェア開発と開発ツール関連の雑記

機器組込みのエンベデット・ソフトウェア(ファームウェア)の開発に関連したコラムです。 メールマガジン「アメニティ&サウンド 音と快適の空間へ」に連載していた技術・開発コラムを編集掲載しています。

技術・開発の閑話 :ソフト開発コラム

技術・開発の閑話 : ソフト開発コラム

ファームウェア開発(組込み)の技術 /
デバッギング・ミステリー

開発ツールの話 : ソフト開発コラム

ソフトウェアの分類 /
CPUとDSPのアーキテクチャの違い

プロジェクト初期 ツール評価 : ソフト開発ツールの話

プロジェクト初期のツール評価 / プログラムの動作・ソースの作成 / コード生成 アセンブラ、コンパイラ / 型変換を伴う式評価(コード生成) / 暗黙のライブラリ(コンパイラ生成コード) / 組込みCPUのメモリアクセス / コード生成〜デバッガ

デバッガとICE ツール評価2 : ソフト開発ツールの話

CPU,DSPの内部の状態モニター / プロセッサ周辺のモニター(メモリ、I/O) / 実行の停止(ブレーク) / シングルステップ実行 / 任意部分の実行 / ヒストリー - 実行トレースとコマンド / 各種ファイルのロード、セーブ / シンボル化

≪ 技術・開発の閑話 :技術・開発コラム ≫
3GPP対応 携帯電話開発用音響測定システム
TS 26.131/ 26.132 V5.0に準拠、ITU-T P.50とP501の試験信号、Windows Vista、Windows XP 3GPP対応 携帯電話開発用オーディオアナライザー MTA-02WB-S

《 エラーとコスト ゼロ除算/ブルースクリーン /エクストリームプログラミング-技術・開発の閑話-2-vol.04 》

株式会社エーアールアイ/ARI CO.,LTD.
東京都八王子市横山町6丁目9番 丸多屋ビル8F
tel:042-656-2771 fax:042-656-2654

ARIはアナログ、デジタル音響機器の ハードウェア開発ソフトウェア開発、 製品、受託開発を行なっています。試作、研究開発や特注機器などのソフト、ハード、システムの設計から製造までご相談いただけます。

エーアールアイ会社情報
製品情報と販売
音響と開発・サービス
音響機器メーカーと代理店

ご利用案内 | 免責事項 | ARI 音響と開発のサイトマップ | 株式会社エーアールアイ | 東京都八王子市横山町6丁目9番 丸多屋ビル8F

Copyright(c) 2001-2017 ARI Co.,Ltd. all rights reserved.