はじめに
以下を読んだ時の個人的なメモ。
部分的に引用しているものの、全部を引用しているわけではないので、正確な情報が見たければ以下を見てください。
本文
序文
この規格はSQuaREシリーズ規格の一部である
はい。
この規格の品質測定量の集合は，その実用的な価値に基づいて選択され，二つの信頼性のレベルに分類されている。
それらは網羅的であることを意図していない。
この規格の利用者には，必要に応じてそれらを定義することを推奨する。
信頼性の定義がちょっと理解しきれてないものの、上の2文はまだ分かる。
最後の1文の「必要に応じてそれらを定義することを推奨する」が気になる。
「それら」が何を指すかなんだけど、「この規格の品質測定量の集合」？「２つの信頼性のレベル」？
必要に応じて、この規格の品質測定量の集合、を定義することを推奨する。
必要に応じて、２つの信頼性のレベル、を定義することを推奨する。
後者のがそれっぽいので、そう仮定して読み進めてみるか・・・（きっと言及されるっしょ
1 適用範囲
警告文
この規格は，評定水準又は標準適合性の等級に測定量の値の範囲を割り当てるものではない。
なぜならば，これらの値は，システム，製品又は製品の一部の性質に基づいて定義されており，ソフトウェアの種類，インテグリティレベル及びユーザニーズのような要因に依存するからである。
幾つかの属性は，望ましい範囲の値をもつことができ，その範囲の値は，例えば人間がもつ認識能力の要因のような，特定のユーザニーズに依存しないが，一般的な要因に依存している。
ムズ。何かしら警告されてるのは分かるけど、何を警告されてるのかが分からぬ。自分の知識量の無さ故に分からぬ。
「評定水準」とは？
明示的又は暗示的な 必要性に基づいて，ソフトウェアを分類する(評定する)ための，尺度上の値の範囲 。
適切な評定水準は，例えば，利用者視点，管理者視点又は開発者視点といった異な る品質視点に対応して設定してもよい。これらの水準を評定水準とする。
(備)評定 水準は，ISO8402で定義する“等級”(grades)とは異なる。
ざっくり、品質の合格基準みたいなものと捉えれば良いんかな。
そもそも品質は合否の２択ではなく、いくつかの水準に分類されることになるため、合格基準というよりは、評定水準と表現するのが妥当みたいな話なんかな。
「標準適合性の等級」とは？
規格、規約または法律上および類似の法規上の規則を遵守するソフトウェア製品の能力。
ようは「合格であること」みたいなことかな。
ということは、この警告文はざっくり以下だと解釈。
「この規格は、合格基準の値の範囲を示すものじゃないよ。だってシステムも千差万別なので、一概に決めれないよね。まぁ、一部の特性は普遍的な部分もあって、そこはある程度"これが望ましいよね"くらいの定義はできるっちゃできる。」
説明文
提案する品質測定量は，開発ライフサイクルプロセスの実施中又は実施後に，製品の品質保証及び改善のために利用されることを主として意図している。
せやろな。
2 適合性
この規格に適合する品質要求事項の仕様化又は品質評価は，次のことを行わなければならない。
a) JIS X 25010:2013に規定されたように，明示又は評価される品質特性及び／又は品質副特性を選定する。
b) 選定した品質特性又は品質副特性ごとに，箇条8に規定している一般的な（G）品質測定量の全てを利用することが望ましい。いずれかの品質測定量を除外する場合，その論理的根拠を示す。
c) 箇条8で関係のある特定の（S）品質測定量を任意に選定する。
d) 品質測定量を修正する場合，変更に対する論理的根拠を提供する。
e) この規格に含まれていない，付加的な品質測定量及びQMEをJIS X 25021:2013のように規定する。
（G）とか（S）とか is 何？
GeneralとSpecificの頭文字かな・・・？
使い分け的には「どのシステムでも原則採用すべき＝General」「全部のシステムが測定する必要はないが、特定の場合には測定したほうが好ましいもの＝Specific」っぽい雰囲気。
ざっくり読み替え
- 自分のシステムで評価する品質特性・副特性を選ぼうね！
- 選んだ品質特性・副特性に定義している「（G）品質測定量」は全部利用しよう！使わない場合は理由を明確にしようね！
- その上でこのシステムに関係する「（S）品質測定量」を選出しよう！
（後は補足に近いので省略）
3 引用規格
パス
4 用語及び定義
（省略。分からんときに都度ここに戻る。）
5 略語
QME（quality measure element）：品質測定量要素
ひとつだけだったので、そのまま記載。
関連規格でQMEって出ててなんだろうって思ったけど、品質測定量要素なのかー。（わかってない）
6 製品の品質測定量の利用
6.1 製品の品質測定の概念
製品の品質は，様々な利害関係者の明示的ニーズ及び暗黙のニーズをどのくらい満たしているか，それによってどのくらい価値を提供しているかの度合いである。
SQuaREシリーズ規格の中では，製品品質を品質特性に分類し，幾つかの場合では更に品質副特性に細分化される品質モデルを用いて，これらの明示的ニーズ及び暗黙のニーズを表す。
製品の品質に関連した測定可能な特徴を，定量化のための特徴と呼び，品質測定量に関連付けることができる。
これらの特徴を測定方法を適用して測定する。
測定方法は，明示された尺度に照らして属性を定量化するために使用する，操作の論理的な順序である。
測定方法を適用した結果をQMEと呼ぶ。
ざっくり、一般的に「品質メトリクス」と呼んでるものが、「QME」に当たるよ。くらいに理解。（中身は違うけど、ポジショニングが同じという意味で）
6.2 品質測定の進め方
品質に対するユーザニーズは，特定の利用状況におけるシステムの利用時の品質の要求事項を含む。
これらの識別されたニーズは，ソフトウェア製品の品質特性及び品質副特性を用いて品質の外部及び内部測定量を特定するときに考慮することができる。
お互いに影響し合うものであるという前提のもと、最終的な「利用時の品質」を未来予測するために、測定したい品質に依存する外部特徴や内部特徴などを測定しておこう、ということだと理解。
7 品質測定量を記述するために使用される形式
a) ID 品質測定量の識別コード 各IDは，次の三つの部分から構成される。
- 品質特性を大文字，品質副特性を一文字の大文字及びそれに続く小文字で表現する，省略したアルファベットコード［例えば，“PTb”は“Performance efficiency（性能効率性）”の“Time behavior（時間効率性）”の測定量を示す。］
- 品質副特性の中で順番に付けられた通し番号
- G（一般的な）又はS（特定の）は，品質測定量の適用可能な範囲を示す分類を表す。ここで，一般的な測定量は適切なときにはいつでも使用することができ，特定の測定量は特別な状況に関係するときに使用することができる。
b) 名称 品質測定量の名称
c) 説明 品質測定量によって提供される情報
d) 測定関数 QMEが品質測定量を生成するためにどのように構成されるかを表す数式 注記 品質測定量の測定関数の理解及び適用の助けになるように，品質測定量を構成するために高い頻度で使用する，有用なQMEを附属書Bに簡潔に明示する。
GとSの説明ここにあるやんけ。
8 システム及びソフトウェア製品の品質測定量
8.1 一般
ここでは，JIS X 25010に記述された順で品質特性及び品質副特性ごとに品質測定量を一覧にしている。
内部測定量又は外部測定量として使用されるかどうかによって，品質特性及び評価の評定水準に従って選択が可能な，異なる評価技術によって品質測定量を使用できる。
その結果，箇条8で列挙されている幾つかの品質測定量は，設計仕様書の静的なレビュー，又は実行可能な製品の動的分析のような，評価の異なる段階で使用することができる。
「一般」って聞くと、全般的に使える測定量を定義したのかな？と思って読み始めたけど違った。
前説っぽい内容でした。
8.2 機能適合性の測定量
機能適合性の測定量は，“明示された状況下で使用するとき，明示的ニーズ及び暗黙のニーズを満足させる機能を，製品又はシステムが提供する度合い”を総合評価するために使用する。
うぃっす。
8.2.1 機能完全性の測定量
機能完全性の測定量は，“機能の集合が明示された作業及び利用者の目的の全てを網羅する度合い”を総合評価するために使用される。
| 項目 | 内容 |
|---|---|
| ID | FCp-1-G |
| 名称 | 機能網羅性 |
| 説明 | 明示された機能のうちどのくらいの比率で実装されているか。 |
| 測定関数 | X＝1−A/B |
測定関数補足：
- A＝実装されていない機能の数
- B＝明示された機能の数
機能数で測ったときに、どれくらい実装完了してる？的な指標。
8.2.2 機能正確性の測定量
機能正確性の測定量は，“正確さの必要な程度での正しい結果を，製品又はシステムが提供する度合い”を総合評価するために使用する。
| 項目 | 内容 |
|---|---|
| ID | FCr-1-G |
| 名称 | 機能正確性 |
| 説明 | 正しい結果を提供する機能はどのくらいの比率か。 |
| 測定関数 | X＝1−A/B |
測定関数補足：
- A＝正しい結果が得られない機能の数
- B＝考慮された機能の数
正しい結果が得られない機能とは，特定の意図した目的を達成するための，妥当で受容可能な成果物を提供しない機能のことである。
テストまで完了した機能数はどれくらい？みたいな指標。
システム的に評価可能な正確さ・厳密さみたいな要素なので、システム内部結合テストくらいまでのイメージ。
8.2.3 機能適切性の測定量
機能適切性の測定量は，“明示された作業及び目的の達成を，機能が促進する度合い”を総合評価するために使用する。
| 項目 | 内容 |
|---|---|
| ID | FAp-1-G |
| 名称 | 使用目的に関する機能適切性 |
| 説明 | 利用者が要求する機能のうち，特定の使用目的を達成するために適切な成果物を提供する機能は，どのくらいの比率か。 |
| 測定関数 | X＝1−A/B |
測定関数補足：
- A＝特定の使用目的を達成するために要求される機能の中で，実装されていない機能又は正しい結果が得られない機能の数
- B＝特定の使用目的を達成するために要求される機能の数
これもテストまで完了した機能数はどれくらい？みたいな指標。
利用者の使用目的を達成できているかどうかなので、ユーザー受け入れテストが終わったかどうかみたいな指標。
使用目的ごとに定義する指標の様子。
「使用目的」をどれくらいの粒度にするか悩みそう。ユースケース単位なのか、ユースケースをある程度まとめた業務単位なのか、とか。
| 項目 | 内容 |
|---|---|
| ID | FAp-2-G |
| 名称 | システムの機能適切性 |
| 説明 | 利用者がその目的を達成するために要求される機能のうち，適切な成果物を提供する機能は，どのくらいの比率か。 |
| 測定関数 | （以下） |
X = \sum_{i=1 to N} Ai / N
Ai＝i番目の使用目的に対する適切性の得点，すなわち，i番目の特定の使用目的のために測定された，FAp-1-Gの値
N＝使用目的の数
数式の表示がバグってたので、海外のISOのパワポから持ってきたので、JIS的にはワンちゃん嘘の可能性がある。
シグマの数式とか忘れちゃってたので改めて以下。
A1/N + A2/N + A3/N + ・・・ + Ai/N を指す。
使用目的が100個あって、1番目と2番目は受け入れテストが終わってて、3番目が半分、100番目は未着手、なら以下のようなイメージ。
1/100 + 1/100 + 0.5/100 + ・・・ + 0/100
全部終わってれば以下になる。
1/100 + 1/100 + 1/100 + ・・・ + 1/100 = 1/100 * 100 = 1
8.3 性能効率性の測定量
性能効率性の測定量は，“明記された状態（条件）で使用する資源の量に関係する性能の度合い”を総合評価するために使用される。資源は，他のソフトウェア製品，システムのソフトウェア及びハードウェア構成，並びに材料（例えば，印刷用紙，保管媒体）を含むことができる。
8.3.1 時間効率性の測定量
時間効率性の測定量は，“製品又はシステムの機能を実行するとき，製品又はシステムの応答時間及び処理時間，並びにスループット速度が要求事項を満足する度合い”を総合評価するために使用される。
なーんか、なんとなく知ってる話が続くから、細かいことは省略していきます。
- PTb-1-G:平均応答時間
- PTb-2-G:応答時間適切性＝目標をどれくらい満たしているか
- PTb-3-G:平均ターンアラウンド時間
- PTb-4-G:ターンアラウンド時間適切性＝目標をどれくらい満たしているか
- PTb-5-G:平均スループット
8.3.2 資源効率性の測定量
資源効率性の測定量は，“製品又はシステムの機能を実行するとき，製品又はシステムで使用される資源の量及び種類が要求事項を満足する度合い”を総合評価するために使用される。
- PRu-1-G:平均プロセッサ使用効率性≒CPU使用率
- PRu-2-G:平均メモリ使用効率性≒メモリ使用率
- PRu-3-G:平均I/Oデバイス使用効率性≒I/O使用率
- PRu-4-S:帯域使用効率性≒ネットワーク使用率
8.3.3 容量満足性の測定量
容量満足性の測定量は，“製品又はシステムのパラメータの最大限度が要求事項を満足させる度合い”を総合評価するために使用される。
- PCa-1-G:トランザクション処理容量満足性＝単位時間あたりに処理できるトランザクション量
- PCa-2-G:ユーザアクセス容量満足性＝単位時間あたりで同時処理できるアクセス数
- PCa-3-S:ユーザアクセス増加適切性＝単位時間あたりに処理ができたユーザー数
最後のやつだけ誤訳っぽい感じで読み取りにくかった・・・
引用元には「単位時間内に追加に成功した利用者はどのくらいか」ってあるけど、追加に成功ってなんぞ？
一旦、上記のように解釈した。
8.4 互換性の測定量
互換性の測定量は，“同じハードウェア環境又はソフトウェア環境を共有する間，製品，システム又は構成要素が他の製品，システム又は構成要素の情報を交換することができる度合い，及び／又はその要求された機能を実行することができる度合い”を総合評価するために使用される。
求められることもあるだろうけど、自分の開発現場ではあんまり求められないかも。
8.4.1 共存性の測定量
共存性の測定量は，“その他の製品に有害な影響を与えずに，他の製品と共通の環境及び資源を共有する間，製品が要求された機能を効率的に実行することができる度合い”を総合評価するために使用される。
- CCo-1-G:他製品との共存性＝共存できると明言している内のどれくらいが実際共存できるのか。
8.4.2 相互運用性の測定量
相互運用性の測定量は，“二つ以上のシステム，製品又は構成要素が情報を交換し，既に交換された情報を使用することができる度合い”を総合評価するために使用される。
- CIn-1-G:データ様式交換性＝インターフェースのフォーマットの種類は、要求に対してどれくらい実現できているか
- CIn-2-G:データ交換プロトコル充足性＝インターフェースのプロトコルの種類は、要求に対してどれくらい実現できているか
- CIn-3-S:外部インタフェース適切性＝ちゃんと機能するインターフェースの割合
システムによって変わると思うけど、１つ目と２つ目はGに分類されてるけど、あんまり多くは求められないんじゃないかなぁ・・・。
WEB APIの形式で提供するとして、jsonなのかcsvなのかとかを指してると思われるけど、jsonだけとか多いのでは？
8.5 使用性の測定量
使用性の測定量は，“明示された利用状況において，有効性，効率性及び満足性をもって明示された目標を達成するために，明示された利用者が製品又はシステムを利用することができる度合い”を総合評価するために使用される。
ちょっとしんどくなってきたので、もっと簡略化して記載する。
8.5.1 適切度認識性の測定量
- UAp-1-G:記述完全性＝提供している機能に対して、ドキュメントが提供できている割合。
- UAp-2-S:実演機能網羅率（英語：Demonstration Coverage）＝デモを提供することに意味がある機能に対して、デモが提供できている割合。
- UAp-3-S:ウェブサイトの目的説明率＝各機能のランディングページにおいて、各機能の目的を説明しているか。
8.5.2 習得性の測定量
- ULe-1-G:ユーザーガイダンス完全性＝ヘルプが必要な機能に対して、ヘルプが提供できている割合
- ULe-2-S:入力欄のデフォルト＝デフォルト値を設定可能な入力欄に対して、デフォルト値が自動入力できている割合
- ULe-3-S:エラーメッセージ理解性＝エラーメッセージの内、発生理由と対処方法を示唆できている割合
- ULe-4-S:自己説明提示インターフェース＝初見の利用者が通常の作業を完了できるようにするために必要な情報要素及びステップそれぞれに対してガイドが提供できているか。
8.5.3 運用操作性の測定量
- UOp-1-G:操作一貫性＝操作方法に一貫性が求められる作業に対して、一貫した作業方法を提供できている割合。（NG例：片方はWEB画面で、途中からCUIになって・・・みたいなのは極端だけど、まぁそんなやつ。）
- UOp-2-G:メッセージ明確性＝メッセージの内、正しい成果物または指示を伝達している割合。
- UOp-3-S:機能カスタマイズ可能性＝利用者自身がカスタマイズすることでメリットを教授できる機能に対して、カスタマイズ機能を提供している割合。
- UOp-4-S:ユーザインタフェースカスタマイズ可能性＝利用者自身がカスタマイズすることでメリットを教授できるUIに対して、カスタマイズ機能を提供しているUIの割合。
- UOp-5-S:監視能力＝利用者が監視することでメリットのある機能に対して、監視能力を提供している割合。（スマホのデータ使用量とかのイメージかな）
- UOp-6-S:操作実行取消し能力＝重大な操作を行う際の事前確認や取り消し機能。
- UOp-7-S:情報の理解可能な分類＝情報が馴染みのある基準で分類されている割合。（百貨店のオンラインが、物理店舗と同じ基準で分類しているなど）
- UOp-8-S:外観の一貫性
- UOp-9-S:入力デバイス支援＝適切な入力方式によって操作できる割合（検索欄にフォーカスしてるときにエンターキーを押したら検索が実行される、など）
正しいか間違っているかという線引というよりは、望ましい状態と定義したものに対して、どれくらい実装が済んでいるか？みたいなメトリクスとして捉えるのが良さそう。
切り口が違うだけで、機能実装がどこまでできていいるかみたいな話に思えちゃうなぁ。
8.5.4 ユーザエラー防止性の測定量
- 利用者操作エラー回避性＝ユーザー操作起因で機能不全を起こさないように防備されている割合
- 利用者入力エラーの訂正＝入力エラーに対して推奨入力値を提供する割合
- ユーザエラーの回復性＝利用者によって引き起こされるエラーの内、システム側が自動で復旧できる割合。
8.5.5 ユーザインタフェース快美性の測定量
"快美性"とか初めて聞いたな。
- ユーザインタフェースの外観の快美性＝外観がユーザーにとって美的に快いインターフェースの割合
基準むずそう。
8.5.6 アクセシビリティの測定量
- 障害のある利用者に対するアクセシビリティ＝特定の障害者が利用できる機能の数 / 全体の機能の数
- 利用が支援される言語の適切性
障害も言語もどこまで対応するか次第ってのはある。
8.6 信頼性の測定量
8.6.1 成熟性の測定量
- 障害修正性＝開発において検出された不具合をどれだけ修正したか
- 平均故障間隔時間（MTBF）＝運用時間 / 発生した障害件数
- 故障率＝観測期間中に発生した障害 / 観測期間
- テスト網羅性＝全体の内テストされた機能orシナリオ
わりと普通にチェックしてるメトリクスではある。
8.6.2 可用性の測定量
- システム可用性＝実際の運用時間 / 当初予定されていた運用時間
- 平均ダウン時間＝総ダウン時間 / ダウンした総回数
8.6.3 障害許容性（耐故障性）の測定量
- 故障回避性＝障害を回避できた数 / 該当の障害を回避するために検証したテストケースの数
- ちょっとわからんかった。
- 少ないテストケース数でうまく回避できるのがいいよね、的な指標なんかな・・・？
- 面白いけど観測するためにログ仕込んだりする必要ありそう。
- 構成要素の冗長性＝冗長化されている割合
- 平均障害通知時間＝検出～報告までにかかる平均時間
8.6.4 回復性の測定量
- 平均回復時間：ダウンから復旧までかかった平均時間
- データバックアップ完全性：エラーから回復するために必要な項目がバックアップされている割合
8.7 セキュリティの測定量
8.7.1 機密性の測定量
- アクセス制御可能性：機密データの内、アクセスが制御されている割合。（100%以外許容できなくない？）
- データ暗号化正確性：暗号化・復号が必要なデータの内、仕様通りに実装されている割合。
- 暗号化アルゴリズムの強度：使用している暗号アルゴリズムの内、十分な強度がある割合。
基本100%じゃね？って思っちゃう。
8.7.2 インテグリティの測定量
- データインテグリティ：データの整合性を保つ必要のある項目数の内、認可されていないアクセスによって整合性を毀損された割合。
- 内部データ損傷防止性：実装予定のデータ損傷防止方法の内、実装されている割合。
- バッファオーバーフロー防止性：利用者によって入力のあるメモリアクセス数の内、境界値チェックされている割合
バッファオーバーフローだけなんか細かい気がしちゃう。
ゲームとかだと必要なケースは多そう。
8.7.3 否認防止性の測定量
- デジタル署名使用率
そのまま
8.7.4 責任追跡性の測定量
- 利用者の監査証跡完全性：監査が必要なデータアクセスにおいてログに残される割合
- システムログ保持性：保管する必要のあるシステムログが適切に保管されている割合
8.7.5 真正性の測定量
- 真正性認証メカニズム十分性：本人確認をする機能をどれくらい実装できているか
- 真正性認証規則の整合性：仕様どおりに実装されている割合
8.8 保守性の測定量
8.8.1 モジュール性の測定量
モジュール性の測定量は，“一つの構成要素に対する変更が他の構成要素に与える影響を最小になるように，システム又はコンピュータプログラムが別々の構成要素から構成されている度合い”を総合評価するために使用される（表24参照）。
- 構成要素結合度＝独立がして実装すべきものが独立して実装できている割合
- サイクロマティック複雑度の適切性＝明示されたしきい値を超えるモジュール数
- モジュール種別又は機能種別に対して，たぶん異なった値となる。
「サイクロマティック複雑度の適切性」は面白そう。
ただ、細かく定義しすぎると管理できないし、塩梅が難しそう。
8.8.2 再利用性の測定量
- 資産の再利用性＝再利用可能となるように設計され，実装された資産の割合
- コーディング規約遵守性＝コーディング規約を遵守しているモジュール数
コーディング規約は守ろう。
とはいえ、違反しているものを全部検出可能かってむずいよね。
lintを突き詰めるlintマイスターみたいなの面白そうかもしれんなぁ。
lintもっとうまく使いたい感はあるね。
8.8.3 解析性の測定量
- システムログ完全性＝必要なログが出力されている割合
- 診断機能十分性＝診断機能が実装されている割合
- 診断機能有効性＝実装された上で実際に原因分析に役立っている診断機能の割合
8.8.4 修正性の測定量
- 修正効率性＝修正作業にかかった時間の 実績 / 予定
- 修正効率性というより、「見積もり精度」のが近い気がするが・・・
- 修正正確性＝リリース一定期間以内に不具合が発生した修正の割合
- 興味深いけど、なんとも言えんなぁ・・・。
- 自分ところの開発では、リリース後の不具合数がそもそも統計的に処理できるほどのボリュームにならないことが多いので、評価しにくい気がしてる。
- 修正可能性＝予定通り修正できた機能数
- これも見積もり精度に近い指標な気がする・・・
8.8.5 テスト性の測定量
- テスト機能完全性＝テストがちゃんと実装されている割合
- 自律的テスト性＝スタブが必要なテストの内、スタブが提供できている割合
- システム単体でテストができるかどうかみたいな基準
- テスト再開始性＝一時停止が可能なテストケースの内、再開が可能なテストケースの割合
再開始性とか面白い観点だなぁ。
8.9 移植性の測定量
8.9.1 適応性の測定量
適応性の測定量は，“異なる又は進化していくハードウェア，ソフトウェア又は他の運用環境若しくは利用環境に，製品又はシステムが適応できる有効性及び効率性の度合い”を総合評価するために使用される（表29参照）。
- ハードウェア環境適応性
- システムソフトウェア環境適応性
- 運用環境適応性
省略。
8.9.2 設置性の測定量
- 設置時間効率性
- 設置容易性
省略。
8.9.3 置換性の測定量
- 使用法の類似性
- 製品品質等価性
- 機能包含性
- データ再使用性及びインポート能力
省略。
さいごに
学び
- 大半は要件の分解基準・観点として使うのがいい気がした。
- 「実装されているか」「実装されたものは仕様通りか」ってのが自分は同一の基準だと思ってたけど、これを分けて評価しているものちらほらあって、興味深かった。
- 「サイクロマティック複雑度の適切性」でシステム評価してみるのは面白そう。
- linterをもっと活用して「コーディング規約遵守性」をなんか考えれないかしたい。＋規約そのものもなんとかできるといいなぁ。
以上。