この記事は ソフトウェアテストの小ネタのカレンダー | Advent Calendar 2023 - Qiitaの３日目の記事です。
こんにちは。皆さんはソフトウェアを評価しようとした時に何を評価すべきかわからない、と感じた経験はないでしょうか。私はよくあります。
ソフトウェア評価の視点として様々な観点があります。
- ホワイトボックステスト、ブラックボックステスト：プログラマの視点の評価
- 単体テスト、結合テスト、システムテスト：プログラムの構造に基づく評価
- 機能要件と非機能要件：要求工学に基づく評価
- 魅力的品質と当り前品質：狩野モデルに基づく評価
これらの項目は20年以上前からよく使われている定番の観点です。
近年の新しい視点として、ISO 25000 のソフトウェアの品質特性とその副特性に基づく評価があります。ISO 25000 は国際規格のため様々な国のメンバーが参加するソフトウェア開発プロジェクトに導入しやすいです。ただし ISO 25000 は複数の文書で構成された大きな規格で、説明の内容も多岐にわたります。あなたが初めて読む時は少し時間がかかると思います。
そこで、この記事では２年目のプログラマと１年目のテスター向けに ISO 25000 の概要を紹介します。
【用語解説】ISO と IEC
ISO とは国際標準化機構（International Organization for Standardization）の略称です。ISO は世界共通の規格を策定し、製品やサービスの品質を向上させるための標準を提供しています。
IEC は国際電気標準会議（International Electrotechnical Commission）の略称です。IEC は電気及び電子技術分野の国際規格を作成する標準化団体です。情報技術など一部の分野では ISO と共同で規格を開発しています。
ISO 25000 の概要
ISO 25000 はシステムとソフトウェアの品質に焦点を当てた国際標準です。これまでの「ISO 9126 ソフトウェア品質」と 「ISO 14598 ソフトウェア評価」の２つを統合した新しい規格です。
ISO 25000 は単体のソフトウェアだけでなく、複数のシステムが連携する情報システムも対象としている点が新しいです。その分、内容が多岐に渡るため ISO 25000, 25001, 25010, 25020 といった複数の文書に分かれています。全ての規格書をまとめて SQuaRE （スクウェア）シリーズと呼びます。
日本ではそれらの文書は JIS 工業規格の「JIS X 25000 システム及びソフトウェア製品の品質要求及び評価」シリーズとして翻訳されています。
SQuaRE （スクウェア）シリーズの主な文書を以下に示します。
| 分類 | ISO 規格 | JIS 規格 |
|---|---|---|
| 品質管理 | ISO/IEC 25000 | JIS X 25000 ＳＱｕａＲＥの指針 |
| 品質モデル | ISO/IEC 25010 | JIS X 25010 システム及びソフトウェア品質モデル |
| 品質測定 | ISO/IEC 25022 | JIS X 25022 利用時品質の測定 |
| 品質測定 | ISO/IEC 25023 | JIS X 25023 システム及びソフトウェア製品の品質の測定 |
| 品質要求 | ISO/IEC 25030 | JIS X 25030 品質要求の枠組み |
| 品質評価 | ISO/IEC 25040 | JIS X 25040 評価プロセス |
ISO 25010 で定義されているソフトウェア品質
ISO 25000 で定義されているソフトウェアの品質は以下の通りです。
明示された条件下で使用するとき，明示的ニーズ又は暗黙のニーズを満たすためのソフトウェア製品の能力。(ISO/IEC 25000:2014, JIS X 25000:2017 4.33項)
ソフトウェアの品質を測るため、ISO 25010 では利用者から見た利用時の品質と開発者から見た製品の品質の2つの品質モデルを定義しています。2つを合わせて13 個の品質特性と 40 個の副特性があります。この記事ではそれぞれの品質特性について説明します。
利用時の品質
利用時の品質特性と副特性を以下に図示します。
各特性の意味は以下の通りです。
1.有効性 (Effectiveness)
設定された目標や要件をどれだけ効果的に達成できるか。
2. 効率性 (Efficiency)
リソースをどれだけ効率的に利用できるか。
3.満足性 (Satisfaction)
ユーザーがどれだけ満足しているか。これはさらに４つの副特性に分けられます。
a. 実用性 (Usefulness)
ユーザーにとって実用的であり、役立つか。
b. 信用性 (Trust)
ユーザーに信頼感を与え、期待通りに動作できるか。
c. 快感性 (Pleasure)
ユーザーに楽しさや満足感をもたらすか。
d. 快適性 (Comfort)
ユーザーに快適な体験をもたらすか。
4. リスク回避性 (Freedom from risk)
ソフトウェアが予測可能で潜在的なリスクを最小限に抑えるか。これはさらに３つの副特性に分けられます。
a. 経済リスク緩和性 (Economic risk mitigation)
ソフトウェアの利用がビジネスや経済においてリスクを軽減するか。
b. 健康・安全リスク緩和性 (Health and safety risk mitigation)
ソフトウェアを使用することで生じる健康や安全に関するリスクを軽減するか。
c. 環境リスク緩和性 (Environmental risk mitigation)
ソフトウェアが環境に対して与えるリスクを軽減するか。
5. 利用状況網羅性 (Context coverage)
異なる状況や環境でどれだけ対応できるか。これはさらに２つの副特性に分けられます。
a. 利用状況完全性 (Context completeness)
異なる状況や文脈でどれだけ適応できるか。
b. 柔軟性 (Flexibility)
柔軟に拡張や変更ができるか。
製品の品質
製品の品質特性と副特性を以下に図示します。
各特性の意味は以下の通りです。
6. 機能適合性 (Functional Suitability)
提供する機能がユーザーのニーズや期待にどれだけ適しているか。これはさらに３つの副特性に分けられます。
a. 機能完全性 (Functional Completeness)
必要な機能を十分に提供しているか。
b. 機能正確性 (Functional Correctness)
提供する機能が期待通りに正確に動作するか。
c. 機能適切性 (Functional Appropriateness)
利用者のニーズに適しているか。
7. 性能効率性 (Performance Efficiency)
リソースの使用を最適化し、高い性能を維持できるか。これはさらに３つの副特性に分けられます。
a. 時間効率性 (Time behaviour)
実行する機能が所定の時間内にどれだけ速く実行できるか。
b. 資源効率性 (Resource utilization)
システムリソース（CPU、メモリ）を効果的に利用しているか。
c. 容量満足性 (Capacity)
処理できるデータやユーザーの数に対する容量を評価。
8. 互換性 (Compatibility)
他のシステムやプラットフォームとどれだけ連携できるか。これはさらに２つの副特性に分けられます。
a. 共存性 (Co-existence)
他のソフトウェアと共存し、干渉なく使用できるか。
b. 相互運用性 (Interoperability)
他のシステムやプラットフォームと効果的に連携できるか。
9. 使用性 (Usability)
ユーザーにとってどれだけ使いやすいか。これはさらに７つの副特性に分けられます。
a. 適切度認識性 (Appropriateness recognizability)
利用者の期待に適切に応え、理解しやすいか。
b. 習得性 (Learnability)
初めて使うユーザーがどれだけ早く理解して使いこなせるか。
c. 運用操作性 (Operability)
正確な操作を提供し、ユーザーが簡単に操作できるか。
d. ユーザエラー防止性 (User error protection)
ユーザーの誤操作を防ぎ、誤って行った場合でも影響を最小限に抑えるか。
e. ユーザインタフェース快美性 (User interface aesthetics)
ユーザーインターフェースが美的で魅力的か。
f. アクセシビリティ (Accessibility)
身体障害者を含む全ての人が利用しやすいか。
10. 信頼性 (Reliability)
安定して動作し、障害やエラーが発生しづらいこと。これはさらに４つの副特性に分けられます。
a. 成熟性(Maturity)
どれだけ安定しており、問題なく動作するか。
b. 可用性(Availability)
必要な時に利用可能であるか。
c. 障害許容性（耐故障性）(Fault tolerance)
障害やエラーに対してどれだけ耐性があるか。
d. 回復性(Recoverability)
障害から迅速に回復できるか。
11. セキュリティ (Security)
データや利用者の情報を保護し、権限のないアクセスから守ること。これはさらに５つの副特性に分けられます。
a. 機密性(Confidentiality)
データや情報をどれだけ機密に保護できるか。
b. インテグリティ(Integrity)
データや情報を正確に保ち、改ざんを防げるか。
c. 否認防止性(Non-repudiation)
ユーザーが行ったアクションや取引を否認できないように保護するか。
d. 責任追跡性(Accountability)
誰が何を行ったかをトレースできるか。
e. 真正性(Authenticity)
ソフトウェアが本物で信頼性があり、名前の盗用を防げるか。
12. 保守性 (Maintainability)
変更や修正を容易に受け入れ、保守作業がスムーズに行えること。これはさらに５つの副特性に分けられます。
a. モジュール性(Modularity)
構成要素が独立しており、変更や修正が容易か。
b. 再利用性(Reusability)
他のシステムで再利用できるか。
c. 解析性(Analysability)
障害の監視やログ取得が容易か。
d. 修正性(Modifiability)
変更や修正が容易か。
e. 試験性(Testability)
試験が容易に行えるか。
13. 移植性(Portability)
異なる環境やプラットフォームで簡単に移植できること。これはさらに３つの副特性に分けられます。
a. 適応性(Adaptability)
異なる環境や要件に適応できるか。
b. 設置性(Installability)
インストールが容易か。
c. 置換性(Replaceability)
新しいバージョンに簡単に置き換えられるか。
ChatGPT を使ったソフトウェア品質指標の作成例
ISO 25000 を実践する際は、対象の製品の品質特性に基づいた具体的な品質指標を決める必要があります。規格内にも例がありますが汎用的な内容になっているためピンとこないかもしれません。この記事では ChatGPT を使った具体的な品質指標の作成例を紹介します。
利用時品質の品質指標の作成例
ISO 25010 に基づくソフトウェア利用時の品質特性と副特性をTBL形式にして学習してください。
品質特性 副特性 説明
有効性 有効性 設定された目標や要件をどれだけ効果的に達成できるか。
効率性 効率性 リソースをどれだけ効率的に利用できるか。
満足性 実用性 ユーザーにとって実用的であり、役立つか。
満足性 信用性 ユーザーに信頼感を与え、期待通りに動作できるか。
満足性 快感性 ユーザーに楽しさや満足感をもたらすか。
満足性 快適性 ユーザーに快適な体験をもたらすか。
リスク回避性 経済リスク緩和性 ソフトウェアの利用がビジネスや経済においてリスクを軽減するか。
リスク回避性 健康・安全リスク緩和性 ソフトウェアが使用することで生じる健康や安全に関するリスクを軽減するか。
リスク回避性 環境リスク緩和性 ソフトウェアが環境に対して与えるリスクを軽減するか。
利用状況網羅性 利用状況完全性 異なる状況や文脈でどれだけ適応できるか。
利用状況網羅性 柔軟性 柔軟に拡張や変更ができるか。
ISO 25010に基づくソフトウェア利用時の品質特性と副特性をTBL形式にしてみました。
（中略）
暗号通貨の決済システムを例にTBLに追加して全項目を出力してください。
品質特性、副特性、具体例、評価手法、計測値の例、ベンチマーク値の例
以下に、暗号通貨の決済システムを例にして、
TBL形式で品質特性、副特性、具体例、評価手法、計測値の例、
およびベンチマーク値の例を示します。
製品品質の品質指標の作成例
ISO 25010 に基づくソフトウェア製品の品質特性と副特性をTBL形式にして学習してください
品質特性 副特性 説明
機能適合性 機能完全性 必要な機能を十分に提供しているか。
機能適合性 機能正確性 提供する機能が期待通りに正確に動作するか。
機能適合性 機能適切性 利用者のニーズに適しているか。
性能効率性 時間効率性 実行する機能が所定の時間内にどれだけ速く実行できるか。
性能効率性 資源効率性 システムリソース（CPU、メモリ）を効果的に利用しているか。
性能効率性 容量満足性 処理できるデータやユーザーの数に対する容量を評価。
互換性 共存性 他のソフトウェアと共存し、干渉なく使用できるか。
互換性 相互運用性 他のシステムやプラットフォームと効果的に連携できるか。
使用性 適切度認識性 利用者の期待に適切に応え、理解しやすいか。
使用性 習得性 初めて使うユーザーがどれだけ早く理解して使いこなせるか。
使用性 運用操作性 正確な操作を提供し、ユーザーが簡単に操作できるか。
使用性 ユーザエラー防止性 ユーザーの誤操作を防ぎ、誤って行った場合でも影響を最小限に抑えるか。
使用性 ユーザインタフェース快美性 ユーザーインターフェースが美的で魅力的か。
使用性 アクセシビリティ 身体障害者を含む全ての人が利用しやすいか。
信頼性 成熟性 どれだけ安定しており、問題なく動作するか。
信頼性 可用性 必要な時に利用可能であるか。
信頼性 障害許容性（耐故障性） 障害やエラーに対してどれだけ耐性があるか。
信頼性 回復性 障害から迅速に回復できるか。
セキュリティ 機密性 データや情報をどれだけ機密に保護できるか。
セキュリティ インテグリティ データや情報を正確に保ち、改ざんを防げるか。
セキュリティ 否認防止性 ユーザーが行ったアクションや取引を否認できないように保護するか。
セキュリティ 責任追跡性 誰が何を行ったかをトレースできるか。
セキュリティ 真正性 ソフトウェアが本物で信頼性があり、冒用を防げるか。
保守性 モジュール性 構成要素が独立しており、変更や修正が容易か。
保守性 再利用性 他のシステムで再利用できるか。
保守性 解析性 障害の監視やログ取得が容易か。
保守性 修正性 変更や修正が容易か。
保守性 試験性 試験が容易に行えるか。
移植性 適応性 異なる環境や要件に適応できるか。
移植性 設置性 インストールが容易か。
移植性 置換性 新しいバージョンに簡単に置き換えられるか。
以下に、ISO 25010に基づくソフトウェア利用時の品質特性と副特性をTBL形式にしてみました。
（中略）
暗号通貨の決済システムを例にTBLに追加して全項目を出力してください。
品質特性、副特性、具体例、評価手法、計測値の例、ベンチマーク値の例
以下に、暗号通貨の決済システムを例にして、
TBL形式で品質特性、副特性、具体例、評価手法、計測値の例、
およびベンチマーク値の例を示します。
ISO 25000 運用のコツ
個別のシステムはその目的と利用状況によって異なる品質特性を要求されます。
| システム・ソフトウェアの例 | 重要な品質特性 |
|---|---|
| 消費者向けの対話型ソフトウェア （例：ワープロソフト） |
使用性 共存性 |
| インターネット及びオープンシステム （例：オンライン販売システム) |
セキュリティ 相互運用性 |
| 基幹系システム （例：銀行システム） |
機能正確性 信頼性 |
システムを評価する際は品質特性の優先度を決める作業が必要になります。この詳細は ISO 25030 の説明記事で紹介します。
まとめ
この記事では次の４点を紹介しました。
- ISO 25000 の規格の概要
- ISO 25010 の品質特性
- 暗号通貨の決済システムを例にした具体的なテスト項目
- ISO 25000 の運用のコツ
駆け足で説明したため、もしわかりにくい点があったら先にお詫びします。誤記や間違い、不明点などありましたらコメントください。ご覧いただきありがとうございました。
参考文献
- SEC journal Vol.10 No.5 Jan. 2015
システム・ソフトウェア品質標準 SQuaRE シリーズの歴史と概要
https://www.ipa.go.jp/archive/files/000065855.pdf) - 日本産業標準調査会（ユーザアカウントを登録すれば、無料で閲覧できます）
https://www.jisc.go.jp/
JIS X 25000:2017 ＳＱｕａＲＥの指針
JIS X 25010:2011 システム及びソフトウェア品質モデル