製品品質について勉強する4

これでラスト.
残る2つの特性である保守性と移植性について見ていく.

しつこく貼っておくが,参照元はこちら.
JIS X 25010:2013 システム及びソフトウェア製品の品質要求及び評価(SQuaRE)−システム及びソフトウェア品質モデル

■保守性
定義は以下のとおり.

意図した保守者によって,製品又はシステムが修正することができる有効性及び効率性の度合い。

「直しやすさ」ということになる.
「保守者」とあるが,インクリメンタルな開発プロセスの場合,
開発者にとっても決して無視できない特性となる.
副特性はちょっと多くて,以下の5つ.

(1) モジュール性
定義は以下のとおり.

一つの構成要素に対する変更が他の構成要素に与える影響が最小になるように,システム又はコンピュータプログラムが別々の構成要素から構成されている度合い。

いわゆる「結合度」などで表現される品質特性だ.
モジュール性が低いと,修正時の影響範囲が広くなり,
回帰テストの必要量も多くなってしまう.

(2) 再利用性
定義は以下のとおり.

一つ以上のシステムに,又は他の資産作りに,資産を使用することができる度合い。

今のご時世,完全スクラッチの開発なんてのはレアケースであって,
多くの開発においては,過去資産の流用が行われる.
なので,再利用性というのは長い目で見ると割と重要なのだが,
多くの開発では,この特性は無視される.
ぶっちゃけ,未来のプロジェクトに向けた先行投資なんて余裕はない.

(3) 解析性
定義は以下のとおり.

製品若しくはシステムの一つ以上の部分への意図した変更が製品若しくはシステムに与える影響を総合評価すること,欠陥若しくは故障の原因を診断すること,又は修正しなければならない部分を識別することが可能であることについての有効性及び効率性の度合い。

解析のしやすさというのは,大きく2つの要素があると思う.
まずは,どこを解析すれば良いか自明であること.
構成要素毎の責務が明確なシステムであれば,解析の効率がぐっと上がる.
そして次が読みやすさだ.
ソースコードなら,いわゆる「リーダブル」であることが望ましい.
システム全体に目を向ければ,ログの読みやすさも重要な要素となる.

(4) 修正性
定義は以下のとおり.

欠陥の取込みも既存の製品品質の低下もなく,有効的に,かつ,効率的に製品又はシステムを修正することができる度合い。

……これ,ほぼ「保守性」のところで述べていることと同義では?
わざわざ改めて書いている理由が,よく分からない.

(5) 試験性
定義は以下のとおり.

システム,製品又は構成要素について試験基準を確立することができ,その基準が満たされているかどうかを決定するために試験を実行することができる有効性及び効率性の度合い。

名前通り,テストのしやすさを表す特性だ.
テストを考慮できていないソフトウェアアーキテクチャの場合,
自動化の導入が困難であったり,
あるいはかなり大きな単位まで結合しないとテストできなかったりする.
前者に関しては,たとえばSeleniumを導入したものの
スクリプトが安定して動いてくれず,スクリプトのメンテに
かえって膨大なパワーを要した……なんて経験がある人もいるのでは?

■移植性
定義は以下のとおり.

一つのハードウェア,ソフトウェア又は他の運用環境若しくは利用環境からその他の環境に,システム,製品又は構成要素を移すことができる有効性及び効率性の度合い。

システムの移転だけでなく,
内部構成の入れ替え(バージョンアップ)なども含めた,
包括的な「移植」への対応能力を意味する特性となる.
副特性は以下の3つ.

(1) 適応性
定義は以下のとおり.

異なる又は進化していくハードウェア,ソフトウェア又は他の運用環境若しくは利用環境に,製品又はシステムが適応できる有効性及び効率性の度合い。

移植を行うことで,
有効性や効率性がどの程度損なわれるか,という指標となる.
機能の制約が発生したり,性能劣化をもたらす場合は,
そのシステムは「適応性が低い」という扱いになる.

(2) 設置性
定義は以下のとおり.

明示された環境において,製品又はシステムをうまく設置及び/又は削除できる有効性及び効率性の度合い。

物理的な置きやすさ(コンパクトさや配線の簡便さ)だけでなく,
ソフトウェアならばインストールの容易性も影響する指標となる.
「削除」が含まれているという点も重要だ.

(3) 置換性
定義は以下のとおり.

同じ環境において,製品が同じ目的の別の明示された製品と置き換えることができる度合い。

適応性と被っている気がするが,
こちらはよりソフトウェアのバージョンアップを意識した特性.
こんなの,バージョンアップの仕様次第な気もするが.


以上,これで製品品質の理解は終わり.
それぞれの特性間には依存性があったり,
また,ぶっちゃけ定義が曖昧だったりもするので,
「俺達はこう理解する」「その上でこのレベルを目指す」という合意を
プロジェクトの計画段階で取っておくことが大事だと思う.