ハードウェアの信頼性は、「設計誤り、製造誤り、故障（failure)の３つ」だとのこと。（P11)
「ソフトウェアには故障はない。また磨耗もない。」とかかれている。
しかし、自己書き換えするソフトウェアは、自己書き換えの計算がたまたま間違えているところを通過していないと、異常が起きない。たまたま自己書き換えの間違えたところを通過すると、ソフトウェアの故障が起きるかもしれない。
磨耗は、ソフトウェアが記憶領域を取りすぎて、足らなくなると、再起動しないとうまくいかないのは、磨耗の一種だと考えてもいいかもしれない。
「アポロ８号宇宙船に搭載されたコンピュータはソフトウェア・エラーのために、メモリの一部が消されてしまった。」「アポロ１４号が１０日間飛行した間に検出されたエラーは１８個にのぼった。」とのことである。
「１９６３年のNORAD演習は、レーダー情報が誤った経路をとってしまうというソフトウェアのエラーのために、実行不可能になった。」
「合衆国戦略高級司令部の４６５L司令システムは、１２年間稼動してきたあとでも、なお平均毎日１度のソフトウェア故障が生じている（文献 Rome air development center R&D program in computer language controls and software engineering techniques, R.H. THayer, 1974)
「FORTARANプログラムの文に、１つエラーがあったために、合衆国の第一次金星ロケットが失われた。」
医療事故文献、B.W. Boehm, Software and its impact: A quantitative Assessment', datamation 19(5), 48-59(1973)
航空機事故文献、P.Naur and B. Randell, Software engineering: Report on a conference sponsored by the NATO science committeee, 1968, p121
4.2に、ソフトウェアの目標という項がある。
「製品の目標は、ユーザの立場から見た製品の到達点を定め、
事業目標は、予定、費用、試験の程度などの事業内での到達点を定める。」
製品の目標
１ 総論
２ 利用者の定義
３ 機能的な目標の詳細
４ 文書（利用者文書）
５ 効率
６ 適合性（古い製品、規格）
７ 構成（対象ハードウェア、ソフトウェア）
８ 保護（会計検査など）
９ サービス度（エラー処理の費用と時間、診断プログラム）
１０ 接地
１１ 信頼性
A システム故障、ユーザ故障、特定の機能の故障について、故障間平均時間、故障の重大さ
B 故障後再運転可能になるまでの平均時間
C ソフトウェアエラーの許容数。重大さの程度と発見までの時間
D システム故障や主要な機能が失われた結果生じる状況
E 故障が生じた際に、許容されうるデータの損失量
F 故障から保護すべき重要な情報
G 必要とされる欠陥検出機能
H 必要とされる欠陥修正機能
I 必要とされる欠陥耐性機能
J 利用者エラーおよびハードウェア故障の検出と回復
事業目標
１ それぞれの過程の費用目標点
２ 事業の規模
３ 試験過程の目標
４ 達すべき適合性や拡張性の程度を帰した、適応性の到達点
５ 製品の保守に関する考察を記した、保守性の到達点
６ 製品の信頼性目標を達するために、各開発過程がたっすべき信頼性の水準
７ 時行間の内部文書に関する目標
８ 製品がしよう可能かどうかをさだめるための評価基準
１２．２には、原因結果グラフを示している
１７．２では、「証明で証明できること、できなこと」
出力アサーションに誤りがあったり、不完全だったりした場合、
未検出のエラーが残っていることが起こりうる。
入力アサーションは、プログラムの初期段階の前提と環境を規定している。実行時に成立していることを保障していない。
証明は誤ったインタフェースは通常検出できない。
証明自体があやまっていることがある。
言語の意味論が簡単に誤解されうる。プログラムのある特定の分は、それがみかけ上意味することを実はいみしないことがある。
丸め誤差、オーバフロー条件、算術機構の制約、システム、機会の制限事項は証明では省略している。
入出力操作を実行するプログラムをうまく証明できない。
非数値プログラムの証明は、数値プログラムの証明にくらべてずっと困難である。
証明では、望ましくない副作用や、無関係な結果は検出できない。グローバルなデータ領域の破壊などの副作用が検出できないことがある。
並列性の検証。
証明の困難さは複雑度に比例する。
本棚登録 : 
感想 : 
