ソフトウェア品質

ソフトウェア品質は、プログラムのソースコードの良し悪しから、アプリケーションの使いやすさまで、非常に幅広い概念を包含しています。この品質という言葉は、開発者、ユーザー双方にとって重要な意味を持ち、それぞれの立場によって評価の基準が異なるのが特徴です。

ソフトウェア品質の定義

ソフトウェア品質の定義は多岐にわたりますが、ジェラルド・ワインバーグは「品質とは誰かにとっての価値である」と述べています。これは品質が主観的なものであり、同じソフトウェアでも、利用する人によって価値の感じ方が異なることを示唆しています。この定義は、開発チームに「誰のためのソフトウェアか」「彼らにとっての価値は何か」を問いかけるという点で重要です。

別の視点として、品質を「目的への適合性」と捉える場合、ソフトウェアの目的が明確になることで、品質を測定するための基準（属性）を定めることができるようになります。

ソフトウェア品質の構成要素

ソフトウェアの品質は、さまざまな側面から評価できます。以下に代表的な要素を挙げます。

製品品質: 要求仕様やプログラム仕様への適合性、スケーラビリティ、正当性、完全性、バグの少なさ、フォールトトレランス、拡張性、保守性、ドキュメンテーションなどが含まれます。
ソースコード品質: プログラムの保守性を高めるための記述方法、可読性、言語固有の規約への準拠が重要です。コードが論理的に分割され、管理しやすい構造になっていることも重要です。

良いコードの条件として、デビッド・スコット・バーンスタインは「CLEAN」という5つの原則を提唱しています。

1. 凝集性 (Cohesive)：機能が明確に定義されていること。
2. 疎結合 (Loosely Coupled)：責務が明確で、他の部分への依存を減らすこと。
3. カプセル化 (Encapsulated)：実装の詳細を隠蔽すること。
4. 断定的 (Assertive)：オブジェクトの状態はオブジェクト自身が管理すること。
5. 非冗長 (Nonredundant)：オブジェクトの定義は一度のみにすること。

ソフトウェアの信頼性

ソフトウェアの信頼性は、ソフトウェア品質を測る上で非常に重要な観点です。品質という言葉には主観的な要素が含まれますが、信頼性は客観的な基準で測定可能です。この測定基準は一般にソフトウェアメトリクスと呼ばれます。

組み込みシステムなどでは、ソフトウェアの問題は人命に関わる可能性もあります。そのため、ソフトウェアの信頼性に関する要求仕様が非常に重要になります。アメリカでは、FDA（食品医薬品局）やFAA（連邦航空局）がソフトウェア開発に関する要求仕様を策定しています。

信頼性の目標

ソフトウェアの信頼性を評価することは、ソフトウェアが期待通りに動作しないという現実的な問題に対処するために不可欠です。重要なシステムでは特に信頼性が求められます。

ソフトウェアは私たちの生活に深く浸透しており、社会基盤がソフトウェアに依存する度合いが高まるにつれて、ソフトウェアの信頼性向上がますます重要になっています。

信頼性への挑戦

ソフトウェアの信頼性を測定することは困難です。特に、ソフトウェアがどのように使用されるかを正確に予測することは難しく、人間の役割を代替するソフトウェアは、融通や常識を働かせる能力がないため、問題が発生する可能性もあります。

信頼性を評価するためには、ソフトウェアに特定の環境とデータを与えた時の結果を予測し、実際の結果と比較する必要があります。しかし、現状では、予測される結果を正確に求める手段が確立されていません。

プログラム開発における信頼性

ソフトウェアの信頼性を確保するためには、開発プロセス全体にわたって注意を払う必要があります。

要求仕様: ソフトウェアが「どう動作すべきか」を詳細に把握することが重要です。要求仕様は試行錯誤的に変化するため、完璧な仕様を事前に作成することは難しいですが、要求仕様の形式化は信頼性を高める上で有効です。
設計: ソフトウェアが「どのように動作すべきか」を記述します。ソフトウェアを部品に分割し、それぞれの役割を明確にすることで、開発を効率化し、バグを減らすことができます。また、高レベルな設計は、アーキテクチャ上の問題とデータ処理の問題を分離し、並行開発を可能にします。
プログラミング: プログラミング言語の進化は、プログラムの複雑さを克服する試みです。抽象化、階層化、モジュール化により、コードの理解を容易にすることができます。
テスト: プログラムが要求仕様通りに動作するかを検証します。単体テスト、結合テストなど、さまざまなレベルでテストを行い、不具合を早期に発見することが重要です。
実行時: 実行時の信頼性評価は、性能、相互運用性、ハードウェア構成への適合性を評価します。

ソフトウェア品質の要因

ソフトウェア品質要因は、機能面以外で求められる品質です。以下に代表的な要素を列挙します。

理解可能性: 製品の目的が明確で、設計文書やユーザー文書が理解しやすいこと。
完全性: 製品が単独で機能し、その機能が目的に対して十分であること。
簡潔性: 無駄な情報がなく、メモリ使用量やコード行数が少ないこと。
移植性: さまざまな環境で容易に動作すること。
一貫性: 記法や用語が一貫していること。
保守性: 新たな要求に対応するための修正が容易であること。
試験性: テストが容易で、性能評価が可能であること。
ユーザビリティ: ユーザーにとって便利で実用的であること。
信頼性: エラーを防ぎ、期待された機能を十分に実現すること。
構造化の度合い: 構成要素が一様なパターンで整理されていること。
効率性: リソースを無駄に消費しないこと。
セキュリティ: 不正アクセスからデータやプログラムを守ること。

ソフトウェア品質の測定

ソフトウェア品質の測定は、さまざまな観点から行われます。定量的な測定と定性的な測定があり、どちらが優れているということはありません。重要なのは、測定によって得られた情報が、ソフトウェアの品質改善に役立つかどうかです。

よく使われるメトリクスの例として、検出バグ数があります。バグが少ないほど品質が高いと一般的に考えられますが、バグの種類、重大性、ソフトウェアの目的などを考慮する必要があります。また、バグ数の減少が必ずしも品質の向上を意味するとは限りません。例えば、バグの報告を意図的に少なくする可能性も考慮する必要があります。

ソフトウェア品質要因は曖昧であるため測定が難しい場合がありますが、信頼性、移植性などの属性に関連する測定可能な要素に着目し、評価することが可能です。

ソフトウェア品質要因の評価スキーム

ソフトウェア品質要因を評価するためのスキームとして、各要因に関連する質問群に対する回答に基づいて採点を行う方法があります。以下に例を挙げます。

理解可能性: 変数名、コメント文、データ構造が適切か。
完全性: 必要なサブプログラムやデータが揃っているか。
簡潔性: 無駄なコードや冗長なコードがないか。
移植性: プラットフォーム依存の記述がないか。
一貫性: 記法や用語が一貫しているか。
保守性: メモリ容量に余裕があるか、モジュール間の凝集度が適切か。
試験性: テストが容易か、詳細設計が明確か。
ユーザビリティ: GUI、オンラインヘルプ、マニュアルが充実しているか。
信頼性: 限界値チェック、例外処理、ゼロ除算対策がされているか。
構造化の度合い: モジュールの分割、制御の渡し方が適切か。
効率性: 実行時間、メモリ使用量が最適化されているか。
セキュリティ: 不正アクセス対策、セキュリティポリシーの設定、脆弱性対策がされているか。

ユーザーの観点

ソフトウェアの品質は、技術的な側面だけでなく、エンドユーザーの経験も重要です。ユーザビリティを定量化することは困難ですが、以下のような質問によって定性的に評価できます。

ユーザインターフェースは直感的か？
単純な操作は容易か？
複雑な操作は適切か？
エラーメッセージは分かりやすいか？
ウィジェットは期待通りに動作するか？
文書は十分か？
ユーザインタフェースの反応性は良いか？

さらに、サポート体制もユーザビリティを左右する重要な要素です。

まとめ

ソフトウェア品質は、単にバグがないだけでなく、利用する人にとって価値があり、目的に適合していることが重要です。信頼性、保守性、効率性など、さまざまな観点から評価し、改善を続けることが、高品質なソフトウェア開発につながります。

もう一度検索