第7回 ソフトウェア品質の特性

ソフトウェアは目に見えない分、品質に関して整理して考える手がかりとして品質特性という考え方があります。
一般的に品質がよいと言われるのは要求した機能が正しく動作することと捉えられています。
利用者もこんなことができるようにしてほしいという要求をしてきます。
入力された結果が正しく保存され色々な条件で活用され正しく出力されれば良しとされてきました。

しかし、最近ではもっと簡単に入力したい。処理スピードが遅い。実際の運用では使い勝手が悪い。等々の要望があり単純に機能を実装しただけではよい品質と言われなくなりました。

この要求を整理したのが内部品質6特性です。
【1】機能性　【2】信頼性　【3】使用性　【4】効率性　【5】保守性　【6】移植性

最近はこれに利用時の品質として【7】有効性　【8】生産性　【9】安全性　【10】満足性
といった客観的に基準で測れない品質も求められています。
内部品質は各特性の下に副特性も定義されています。
例えば機能性に関しては合目的性正確性、相互運用性、セキュリティ、機能性標準適合性です。
その機能は要求目的に合っていて、正しく処理され、他のソフトとの互換性が可能で一定の権限において運用可能で規格や法律があればそれに準拠しているということ。
これまで言われている品質レベルです。

ところが、
【3】使用性となると理解しやすくて習得しやすくて運用しやすいとかが求められます。
【4】効率性は応答時間、処理時間やネットワークの占有率が定義されています。
【5】保守性は故障した場合の解析が容易で変更しやすい設計であることが求められます。
【6】移植性は初期の環境以外でも、想定されたハードやネットワーク環境でも同じように動作することやデータ互換性を求められています。
Windows環境であればどんなバージョンでも正しく動作することとなります。

いかがでしょうか？
このような品質を最初から要求してソフトウェア開発を行ったらいくら予算があっても間に合いません。
車を購入したい、予算は100万円だと言われ軽自動車を提案したらオレのほしい車はベンツだと言われるようなものです。
目に見えないソフトウェアだからこそ発注する側も購入する側もその制限事項や範囲を限定して同意することが重要となってきます。

この処理の場合、何件までは何秒で処理可能とする。同時にアクセスするのは100端末までとする。
運用するのは熟練のオペレータのみである。といった具体的な利用環境を限定して設計し、開発することが重要となってきます。
特に利用時の品質となってくると導入し運用してみないとわからない事項も多くなってきます。
設計時点では想定できないことも多々あります。そのような場合は導入後のチューニング作業として捉えることが必要です。
データベースも運用以後に適切な効率を出すためにチューニングします。
同様に運用を開始してから発見される要求に関しては別予算・工程として提案し時間をかけて修正することが必要です。

以前は機能要件と非機能要件という考え方があり非機能要件は要求や定義しなくても当たり前に実装しておくべき機能として議論されどこまでやれば当たり前なのかわからない状態で多くの時間を浪費していました。

今後のソフトウェアに関しては、各品質特性に関してどの粒度まで、もしくはどこまでの目標でといった数値を明確にして開発する必要があります。
利用者が求める品質は限りなく、それに応える製造者は理論武装して理解を求めていくことが正しい品質の考え方と思います。

次回は3月28日（木）の更新予定です。

バックナンバーはこちら