ソフトウェア品質

• ソフトウェア品質概論
• 品質標準
• 品質保証

ソフトウェア品質概論

事例

次の二つのソフトウェアはどちらが「品質」がいいですか？

• ソフトウェアA
  • 様々な画像編集・フィルタ
  • 価格：15,000円
• ソフトウェアB
  • 写真の肌色補正・赤目補正程度
  • 価格：無料（OSについてくる）

• ソフトウェアAが無料だったら？
• 孫の写真を整理したいおじいちゃんだったら？
• ソフトウェアの中はどうなってる？
• ソフトウェアAが遅かったら？よく止まったら？

つまり・・

• ユーザ／ユースケースを無視してソフトウェアの品質の評価を行うことはできない
• 「品質」は一つの軸だけでは評価できない

品質改善とは

• メタファー（引喩）「ソフトウェアの品質は人間の健康のようなものだ」
• 「長生きしたい」「ソフトウェアの品質を上げたい」
• 「絶対に品質が上げる」活動 「絶対に長生きできる」活動
  • 実際人によって異なる．効果も異なる．
  • 長生きするためには自分にあった活動をする必要がある
  • 総論
    • 「定期健康診断を受けましょう」，「人間ドックを受けましょう」
    • 標準として規定「特定健診を受けましょう」
    • 特定健診では見つからない病気は様々ある
• 品質をあげるための特効薬はない

品質管理するにあたって

• 完璧な品質のソフトウェアはない 不老不死は不可能
• ゴールの設定を間違えると報われない
  • ソフトウェアの品質を計測可能にする
  • 計測可能なもので目標を設定する

• 品質を上げるための活動の効果は体質によって様々
  • 体質：企業風土，ソフトウェアの種類，メンバーの能力，その他
  • 体質にあうように活動を改善することが大事
• 漠然と高品質を追い求めると救われない（諸説あります）
• 重要なことはソフトウェアのゴールを明確に設定する
  • ゴールに向けた品質管理を目指す
  • ゴールに向かった品質管理になっているかを確認する
    • 適用する意味とどこの品質に寄与するのか（効果）を考える
    • 効果がわからない場合は測定とデータ分析をする

品質標準

品質標準

• ISO/IEC 25000 シリーズ（2011年から 9126-* の後継）
  • 品質モデル ISO/IEC 2501n 製品品質（内部・外部品質），利用時の品質モデル
  • 品質要求 ISO/IEC 2503n　品質要求の仕様化
  • 品質管理 ISO/IEC 2500n　用語の定義，品質要求の管理
  • 品質評価 ISO/IEC 2504n　品質評価のガイドライン，測定量の文書化
  • 品質測定 ISO/IEC 2502n　品質測定の参照モデル，測定量の定義

ソフトウェア品質の分類

「品質」は多属性

• プロダクト品質
  • 利用時の品質（ユーザ視点での品質）
  • 外部品質：実行時の品質（開発者視点：実行・テスト時）
  • 内部品質：設計・実装に関する品質（開発者視点：設計・実装時）
• プロセス品質（開発者視点）
  • 開発プロセスがうまく機能しているかどうか

• 利用時の品質 ゴール
• 外部品質・内部品質 コンディション
• プロセス品質 生活習慣の質

プロダクト品質

利用時の品質

• ユーザ視点での品質
• 満足度など
• UX (User eXperience) に関連

外部品質

• 開発者視点での品質
• システムを実行することで測定する品質
  • テストや実行の振る舞いから測定可能（であるべき）

内部品質

• 開発者視点での品質
• ソフトウェアの内部的な特徴
  • ソースコード，仕様書，設計書などから測定可能（であるべき）

品質の作り込みの考え方

1. 要件分析において「利用時の品質」に関する要求を整理する
2. 設計時に「利用時の品質」から「外部品質」の要求を定義する
3. 設計時に「外部品質」から「内部品質」の要求を定義する

例

1. 利用時の品質：「入力するときに快適に使いたい」
2. 外部品質の定義：「3分以内に登録作業が終わる」
3. 内部品質の定義：「1台のサーバへのアクセス数を1000以下にする」

利用時の品質モデル

利用者や利用場面に依存する主観的な特性

• 有効性（effectiveness）：やりたいことがどの程度達成できるのか
• 効率性（efficiency）：やりたいことをどのくらい効率的に達成できるのか
• 満足性（satisfaction）：どのくらい「使える」のか，どのくらい「信用」できるか，どのくらい「快適」か
• リスク回避性（freedom from risk）：どのくらい安心して使えるか（情報漏洩，障害，安全）
• 利用状況網羅性（context coverage）：どのくらいの環境まで許容できるか（ハードウェア要件，ユーザ状況）

製品品質モデル（主に外部品質）

• 機能適合性（functional suitability）：機能とニーズの適合に関する特性
• 性能効率性（performance efficiency）：実行時の性能や資源効率に関する特性
• 互換性（compatibility）：他製品との情報共有・変換に関する特性
• 使用性（usability）：使いやすさに関する特性
• 信頼性（reliability）：障害に関する特性
• セキュリティ（security）：悪意ある利用からの保護に関する特性
• 保守性（maintainability）：変更に関する特性
• 移植性（portability）：別環境への移行に関する特性

品質保証

ソフトウェア品質保証

• 考え方：利用時の品質を保証する
  • ユーザは誰か？
  • どの時点での価値か？
  • どの特性をどのレベルにするのか？

利用者や利用場面で価値（特性のレベル）が異なる

• Webデザイナは複雑な調整ができること
• おじいちゃんは簡単な操作でできること

品質保証における基本的な考え方

• プロセス改善
  • PDCA
• プロダクト改善
  • レビュー
  • テスト
• 測定

• プロセス改善 生活習慣の改善
  • PDCA
• プロダクト改善 肉体改造
  • レビュー
  • テスト
• 測定 日々の摂取カロリー，身体測定，検診での数値，などの測定

品質と検証

• 利用時の品質 validation
• 外部特徴 validation, verification
• 内部特徴 validation, verification
• プロセス品質 管理者視点での評価（検証技術とは関係ない）

V&V

• Verification 正当性検証: 定義された要求を満たしているかどうか「正しくソフトウェアを作っているか」
• Validation 妥当性確認: 特定の意図のもとでの利用，応用において，要求を満たしていることを確認「正しいソフトウェアを作っているか」

「正しさ」の定義を明確にする．検証基準・方法を決める．検証できる形で仕様化する

PDCA

• 計画（Plan）：目的・目標や手段・実行手順などの立案
• 実施（Do）：立案した計画を実行
• 確認（Check）：目標の達成状況と問題の発生を確認
• 処置（Act）：目標とのずれに対処・問題の除去と再発防止

Scrum（アジャイル開発の一つ）

• Plan スプリント計画
• Do スプリント
• Check スプリントレビュー
• Act スプリントレトロスペクティブ

MBD (Model-Based Development)

• Plan モデル構築
• Do シミュレーション実行
• Check 実行確認
• Act 問題点の洗い出し，改善

レビュー

• 成果物の内容を確認し問題を洗い出す
• 公式度，厳密性，実施内容などにより様々なレビュー方法が存在
• ピアレビュー，インスペクション，チームレビュー，ペアプログラミング，ピアデスクチェック，パスアラウンド，ラウンドロビンレビュー，ウォークスルー，アドホックレビュー

レビューの要点

• レビューの目的を確認する
  • 手戻り工程を減らす
  • あとの工程・運用で問題となりそうなことを洗い出す（code smell）
  • 問題（リスク）と品質の関係を意識する
• 時間をムダにしない

測定

• プロセス・プロダクト共に状態を把握するための「測定」が必要
• 「見える化」，「メトリクス」
• 数値化（定量化）されていることが重要
• 品質特性との関連が明確化されていることが望ましい

プロセス測定・見える化の例

• 開発工数，手戻り工数
• ファンクションポイント（機能見積もり）
• スケジュール（ガントチャート）
• バックログ，残り仕事量（バーンダウンチャート）
• タスクボード（かんばん）
• KPTシート

プロダクト測定・見える化の例

• ドキュメントページ数
• LOC (Lines of Code)
  • 新規，再利用，修正
• モジュール数
• 複雑性メトリクス，制御グラフ，データフロー
• モジュール結合度・凝集度
• テストケース数，テストカバレッジ
• 発見・修正バグ数

改善の要点

PDCAが形骸化しないために・・・

• 計測可能な目標にする
  • 目標達成できたかどうか明らかにするため
  • 成功したか失敗したかわからない状態で改善を考えても時間のムダ
• 品質と目標の関連を明確にする
  • 目標を達成した時にどの品質が保証されるか（どの価値が達成されるか）を明らかにするため
  • 品質（プロセス・プロダクト・ユーザ視点）に一切貢献しない目標を達成しても時間のムダ

• Fail Fast, Fail Cheap, Fail Smart
  • 失敗は成功のもと
  • 早く小さく失敗しましょう
  • 失敗を隠さない：恥ずかしい・評価が悪くなるので隠したがる
  • 失敗を意識する：失敗を失敗と思っていない
  • 小さな規模で早く失敗しておく
    • タスク単位でのPDCA
    • チーム単位でのPDCA
    • プロジェクト単位でのPDCA

機能安全

安全性

• ソフトウェア品質特性の一つ
• 利用時の品質では「リスク回避性」
• 外部・内部品質では「信頼性」が影響する
• ISO25000シリーズ以外の規格

組込システムと安全性

• 組込システム：機械・電機制御ソフトウェア
• Safety-Critical System の場合が多い
  • 例：医療機器，航空機，自動車，etc.

機能安全規格

• 安全な製品を開発するために有効と考えられる手法を定めたもの
• IEC61508：機能安全規格のベース．この規格から各分野向けの規格が派生
  • 例：自動車 ISO26262
• 機能安全規格に準拠した製品だけ販売可能などの制限を受けることがある

規格の概略

• 部品のリスクを評価（SIL: Safety Integrity Level）
• リスクに応じて規定された対策を行う
  • 例：MCDCのテストカバレッジレベルを強く推奨する

用語

• 危害（harm）：人が受ける身体的傷害，財産が受ける害
• ハザード（hazard）：危害の潜在的な源
• リスク（risk）：危害の発生確率と影響度合い
• 安全（safety）：受容できないリスクがない状態

安全設計

• 「ハザードの特定 リスクの評価 対策」のサイクルを繰り返す

対策

• 本質安全（inherent safety）
  • ハザードそのものを取り除く
• 機能安全（functional safety）
  • 「機能」（安全機能）によってリスクを低減させる

安全機能

• 監視：状態を監視
• インターロック：一定の条件が整わないと動作できない
• ファイルセーフ：故障しても安全側になるようにする
• フールプルーフ：不適切な操作等があっても危害が発生しないようにする
• 耐障害：故障しても動作するようにする（フェイルオペレーショナル）

安全分析

• 潜在するハザードを見つけ出す
• ハザードによるリスクを評価する
• FTA (Fault Tree Analysis)
• FMEA (Failure Modes and Effect Analysis)
• HAZOP (Hazard and Operability Study)

HAZOP解析例

• 低水位の安全機能が付いた電気ポット

• 状態遷移：加熱 保温
• 条件：温度 >= 100