ソフトウェア工学
ソフトウェア検証→ソフトウェアが「正しい」かどうか確かめる
→ソフトウェアが求められる機能を実行できる。
ソフトウェアが求められる品質（性能efficiency、精度precision、信頼性dependability）
検証対象の「ソフトウェア」
プログラム + 文章（仕様書。開発の途中で作られる文章すべて）
検証には2種類ある
・verification
実装されたプログラムが仕様通りか
・validation
ソフトウェアが顧客の要求を満たすか
検証の現実
・欠陥ゼロを保証するものではない。
特定の目的に利用するのに適当な品質を保証。
・保証する性質はシステムの目的や顧客の期待度、市場環境により異なる。
ソフトウェアの品質
ISO9126による分類
ソフトウェア検証では以下の「◎」を検証して保証をする。
◎機能性functionality
suitability, accuracy, interoperability, security, compliance
◎信頼性reliability
maturitym fault tolerance, recoverrability
◎使用性usability
understandability, learnabilitym operability, attractiveness
◎効率性effciency
time bihavior, resorce behavior
・保守性maintainbility
analysability, changeabilitym stability, teatability
・可搬性portability
adaptability, installability, coexistence, replaceability
クリティカルシステム
その障害や動作不良により、大きな経済損出や物理的破壊・被害、生命・環境への脅威を引き起こす場合があるシステム。
システムやソフトウェアが望まない状況に落ちいることを回避することが重要。検証はその有効な手段の一つ。
どの品質がそのシステムにとって最もクリティカルであるかで分類
①安全saftyにクリティカルなシステム
障害にや誤作動により生命や自然下院今日に被害・損害を与えかねないシステム
e.g.化学プラント、飛行機などのナビゲーション・自動操縦、医療機器
②目的・使命missionにクリティカルなシステム
障害や誤作動により、その目的達成ができなくなてしまいかねないシステム
e,g, 宇宙船・衛星の航行制御、軍事、競技・競争
③経済的businessにクリティカルなシステム
障害や誤作動により、大きな経済的な損害を起こしかねないシステム
e.g. 銀行・金融・トレーディング、大量生産の民生品、衣食住のインフラ
計算機システムの障害原因
①ハードウェアの障害
②ソフトウェアの障害
③オペレーションの障害
ディペンダビリティdependability
クリティカルシステムはいずれの種類でも、システムがきちんと動作してくれるだろうと確信できなければ利用者は安心して使ったり受け入れたりすることができない。
ディペンダビリティ → あるシステムを利用するにあたり、信用のおける度合
ディペンダブルシステム →利用者が信用して使うことのできるシステム
ディペンダビリティを構成する4つの性質
・可用性availability
・信頼性relicbility
・安全性safety
・セキュリティsecurity
ディペンだビリティを高めると、確認機能がソフトウェアに含まれ遅くなる。また、冗長構成により空間を多く消費する→誤作動・障害による影響の大きさとのトレードオフとなる。
参考サイト
https://www.meti.go.jp/policy/it_policy/softseibi/metrics/product_metrics.pdf
