設計上の問題を解決するために
ソフトウェア設計における信頼性評価の役割
ソフトウェアの品質保証プロセスで定義すべき「ソフトウェア信頼性の概念要素」を紹介する。
わたしは最近、設計上の問題について判断を迫られた。新しい機能を実装しなければならなくなったが、そのために使えそうなモジュールが2つあり、どちらかを選択する必要があったのだ。
こうした設計上の判断は、確かな基準による評価に基づいて行わなければならない。チームリーダーたちが設計ミーティングでこの問題を議論するのを聞いたところ、チームリーダーのモジュール選択は分かれていた。彼らの主張の大部分は客観的なもので、いずれもシステム全体のリアルタイム制約や将来の保守性を考慮に入れていた。わたしは最終的にもう1つの基準を加味して、新機能の実装のために2つのモジュールのうち、どちらを採用すべきかを判断した。本稿では、こうしたソフトウェア設計プロセスへの取り組み方を説明する。
わたしは開発と品質保証の両方のリーダーを務めており、開発業務とテスト業務の橋渡しができる立場にある。設計ミーティングにおいて、変更したいモジュールの品質について多くの情報が得られる機会がある。これは的確な判断を下すのに役立つものだ。
多くのチームリーダーは、ソフトウェアのキャパシティー上のリアルタイムな制約と長期的な保守性を重視している。これは良い慣行だ。しかし、わたしはもう1つの重要な基準を見いだすことができた。それは「ソフトウェアの信頼性」だ。わたしが信頼性に関する情報を得たのは、常にテストプロセスに携わっているおかげだ。
ソフトウェアの設計上の問題を解決するためには、ソフトウェアのキャパシティーや保守性、信頼性の評価をどのように総合的に考慮するのかということになる。こうした判断基準の設定の仕方は、ソフトウェア開発の背景に左右されると思う。
わたしが自分の組織で担当しているソフトウェア開発における目的と制約は、ほかの組織のソフトウェア開発におけるそれらとは異なっている。このため、ほかの職場のソフトウェアアーキテクトは、わたしと同じように「3つの判断基準」を立てることはないだろう。わたしが選択を迫られた2つのモジュールの場合は、それらの特性に加えてキャパシティーと保守性のレベルを考えると、信頼性の方がキャパシティーや保守性よりも重要だった。さらに、2つのモジュールのうち保守性が高かった方は、連携しなければならない環境（サードパーティーのライブラリ）のせいで信頼性が低かった。
わたしが直面したソフトウェア設計の問題を解決するには、これら3つの基準を踏まえる必要があった。だが、別の問題に取り組む場合には、ソフトウェア品質の別の要素（堅固性など）がかかわってくる。基準が何であれ、設計者はすべての基準に留意しなければならない。わたしは個人的には、基準を頭にたたき込み、おのずと判断に反映されるようにするのではなく、それらを書き留めて適宜参照する方を好む。
ここからは、ソフトウェアの信頼性評価に話を絞ろう。前述したように、わたしは信頼性に関する情報をソフトウェアの品質保証プロセスで得ることができた。ただし、このプロセスでは、信頼性評価が直接的に行われることはあまりない。ソフトウェア品質管理者は開発の目的と制約に応じ、ソフトウェアの信頼性に関して、以下のような概念要素を定義しなければならない。
- 障害の深刻度は高いか、低いか
- 障害の影響はシステム全体に及ぶのか、局所的なものか
- 障害の発生確率はどれくらいか
- 復旧の可能性、復旧時間、復旧の度合いは完全なのか、部分的なのか
これらの概念要素をすべて明確に定義したら、品質管理者は、それらを測定評価することを考慮してソフトウェアの品質保証プロセスを整備し、品質指標を設定しなければならない。最初の2つの項目（障害の深刻度と影響）は、バグ追跡システムで調べられそうだ。そのほかの2つの項目は、システムのログ、使用統計、顧客やβテスターの報告から導き出さなければならないかもしれない。
本稿筆者のゾハイル・チェントウフ氏はカナダのDialexia Communicationsで開発＆品質保証部門のディレクターを務め、シャーブルック大学で電気工学部の非常勤教授でもある。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[o9ソリューションズ・ジャパン株式会社] 「改正物流効率化法対策」徹底解説 総物流費を抑制するサプライチェーン戦略 -
製品資料
[o9ソリューションズ・ジャパン株式会社] 「サプライチェーン最適化」実践ガイド：効果的な意思決定を実現する秘訣とは？ -
製品資料
[株式会社リンプレス] 非デジタル／IT人材を「自走するDX推進者」に変えるための育成ロードマップ -
市場調査・トレンド
[ワンアイルコンサルティング株式会社] AI時代の組織設計：「判断と責任」を人に残すための2つの原則とは？ -
技術文書・技術解説
[ワンアイルコンサルティング株式会社] システムの保守がモダン化を阻む？ 「変えない判断」から脱却する方法とは
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
「完璧な設計」なのに3000万円溶けた AWSの失敗事例から学ぶ3つの教訓
-
2
パナソニックが国内製造26拠点のERPを「SAP S/4HANA」に統一 アドオン7割削減
-
3
「AIバブル」は崩壊するのか？ 熱狂の後に来る“尻拭い”と4つの防衛策
-
4
Microsoft製品でここまで自動化できる 情シスがやめられる手作業10選
-
5
守るべきは「開発者のフロー状態」 AIによる生産性改善の6施策
-
6
脱VMwareの前提が崩れる BroadcomのVDDK公開停止で確認すべき点
-
7
「データストレージの活用方法」に関するアンケート
-
8
全社標準「Copilot」にダメ出し？ 現場の8割が不満を抱く“致命的な欠点”
-
9
「企業内サーバ環境の利用実態」に関するアンケート
-
10
100億円の「Linux更新」を回避 みずほ銀行が選んだ“おきて破り”のRHEL延命策
ホワイトペーパーランキング PR
-
1
JR西日本ITソリューションズが「監視業務の属人化」を解消した方法とは？
-
2
インシデント対応工数を約3割削減、東京ガスの事例に学ぶ監視体制刷新のコツ
-
3
生成AIで文書活用を進めるには？ 効率化と安全性をどう両立する
-
4
Windows PCとMacの選択制で生産性向上 LINEヤフーが実践する運用管理方法とは
-
5
DX／AI投資の壁を突破、現代の最高財務責任者が直面する課題と克服のヒント
-
6
「Google Workspace」活用事例34選、先進の生成AIによる組織変革の全貌
-
7
「人員を増やす」という選択肢はない 情シスが負の連鎖から抜け出すには？
-
8
Linuxのスキルを証明する“激推し”の認定資格はこれだ
-
9
「問題が深刻化しやすいプロジェクト管理」から脱却する方法とは？
-
10
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
TechTargetジャパン SNS
@techtarget_itmをフォロー
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー