この記事では、システムの品質管理について説明していきます。品質管理は品質管理部署があるか、PMOが兼任する場合など、品質を報告する相手（システム発注元）によって様々です。
システムの品質管理
ソフトウェアやシステムを開発、維持、改善する際に品質を確保するために行われる一連の活動やプロセスのことです。
具体的には、システムの要件定義、設計、コーディング、テスト、デバッグ、リリース、保守などの各段階において、品質を確保するためのプロセスやツール、方法論を適用し、品質に関する情報を収集し、改善に役立てるための分析を行います。
品質管理には、品質計画の策定、品質規定の策定、品質評価の実施、品質改善の推進などの活動が含まれます。品質管理は、システムのユーザーや利害関係者が求める品質水準を達成し、システムの信頼性、使いやすさ、性能、セキュリティなどの要素を確保することを目的としています。
システムの品質計画
開発や製造、サービス提供などのプロジェクトにおいて、品質目標や品質基準、品質保証および品質管理の方針を明確化し、品質を確保するためのプロセスや手順を決定することです。
品質計画は、プロジェクトの品質目標を達成するために、品質保証および品質管理の手順を詳細に定義し、品質に関する情報を文書化することが含まれます。具体的には、以下のような項目が含まれます。
品質目標
品質目標を設定し、それがプロジェクトのビジョン、目的および戦略に合致するように確認します。
品質基準
品質に関する基準や規格を定義し、その基準に合致するための要件を設定します。
品質保証
品質保証の方法、手順、責任および役割を明確化します。品質保証は、品質が設計段階で確保され、開発および製造のプロセスで維持されることを確実にするために行われます。
システムの品質分析
システムの品質分析方法は、以下のような方法があります。
テストケースによる検証
システムの品質を評価するために、テストケースを作成し、システムの正確性、完全性、および機能性を検証します。テストケースは、予想される結果を定義することで、システムの正確性を評価します。
機能テスト、負荷テスト、性能テストなどのテストを実施して、ソフトウェアの品質を評価します。テストによって、潜在的なバグを特定し、品質向上につながる改善を行うことができます。
レビュー
コードレビュー、設計書レビュー、テストレビューなどの手法を使用して、ソフトウェアの品質を分析します。レビューによって、バグや設計上の欠陥、コードの読みやすさなどを特定し、改善のためのアクションを取ることができます。
コードレビューは、プログラマーが書いたコードを、他のプログラマーがレビューして品質を評価するプロセスです。このプロセスにより、システムの品質を評価し、バグの修正や改善の機会を提供することができます。
設計書レビューは基本設計書や外部設計書、詳細設計書や内部設計書と呼ばれるものを開発リーダーやプロジェクト管理者がレビューし、結果をレビュー記録票などの記録に落とします。記録票は障害があったことと、修正したため問題ないことを担保するために作成します。
テストレビューは、仕様書、設計書、テスト仕様書などのドキュメントを分析して、テストで確認する観点に漏れや誤りがないかのレビューです。こちらも開発リーダーやプロジェクト管理者によって実施します。単体・結合・総合テストでそれぞれ重点的に確認すべき観点が違うため、予めテスト観点について知識があるとスムーズです。ここでは詳しい観点の説明はしません。
パフォーマンステスト
システムのパフォーマンステストは、システムが想定される負荷を受けたときに、システムがどのように動作するかを評価します。これにより、システムのスケーラビリティと負荷に対する耐性を評価することができます。
追加した機能や、システムを移行した際の速度など、ディベロッパーツールやストップウォッチを使用して検査します。
ユーザビリティテスト（受入テスト）
ユーザビリティテストは、システムを使用するユーザーが実際に動作させてみて、評価することで、システムの使いやすさと効率性を評価します。ユーザビリティテストは、ユーザーがシステムを使って目標を達成するための障壁を発見し、改善するためのフィードバックを提供することができます。
リリース直前のユーザー目線での検証であり、ここで問題ないと判断できればひとまず品質は安心できるでしょう。ただ、現実的にはエンジニアやITの有識者の目線では気づけないようなバグや改善要望、違和感が出てくるため、割と山場でもあります。
セキュリティテスト
セキュリティテストは、システムが外部からの攻撃や不正アクセスに対してどのように防御するかを評価します。これにより、システムの脆弱性を特定し、セキュリティ上の問題を解決するための対策を講じることができます。
これらの品質分析方法を組み合わせることで、システムの品質を総合的に評価し、改善のためのアクションプランを策定することができます。
品質分析の評価方法
品質分析には、定性評価と定量評価の2つの評価方法があります。
定性評価
定性評価は、主観的な評価を用いて、ソフトウェアの品質を評価します。定性評価では、ソフトウェアに対する評価基準を決め、それに基づいて評価を行います。例えば、ユーザビリティや使いやすさ、保守性、拡張性などが評価基準として使われます。定性評価は、アンケート調査やユーザーインタビュー、専門家による評価などを行います。
定量評価
定量評価は、客観的な評価を用いて、ソフトウェアの品質を評価します。定量評価では、数値化された評価基準を使用します。例えば、テストカバレッジやバグ密度、処理速度、メモリ使用量などが評価基準として使用されます。定量評価は、自動化されたテスト、コード分析ツール、プロファイラなどを使用して行います。
どちらの方法も、品質分析の目的は同じです。定性評価は主観的であるため、複数の評価者が一貫性を持って評価することが重要です。一方、定量評価は客観的であるため、数値化された基準に基づいて評価を行うことができますが、評価基準が正確でない場合、正しい評価結果を得ることができません。定性評価と定量評価を組み合わせて、より包括的な品質分析を行うことが望ましいです。
障害報告書とは
システム開発や運用中に発生した不具合やエラーを報告するための文書です。異常事象が発生した場合、その原因を特定し、解決策を見つけるために必要な情報を提供します。
品質に問題がないと判断していても、障害は必ずといって良いほど発生します。その際の障害報告書についてもざっと説明します。
障害報告書には、以下のような情報が含まれます。
障害の内容
どのような異常事象が発生したか、その状況や現象について詳細に記述します。
障害の影響範囲
発生した障害がどの程度の範囲に影響を及ぼしているか、またそれがどのような問題を引き起こす可能性があるかを記述します。
障害発生時の環境
障害が発生した場所や時間、システムの稼働状況、ネットワーク接続状況など、障害の発生状況を詳細に記述します。
再現手順
障害を再現するための手順や条件を示します。これにより、開発者や技術者が障害の原因を調査し、解決策を見つけることができます。
原因分析と対策
障害の原因を特定し、解決策を提案します。原因分析には、障害が発生したプログラムやシステムのコードを調べた結果や、システムの環境設定に問題がある可能性がある場合は、その設定内容も記載されます。
障害報告書は、開発者や技術者、システム利用者など、関係者間で情報共有を行うために使用されます。障害が発生した場合、障害報告書を作成し、早急に報告することで、問題解決のための迅速な対応が可能になります。また、障害報告書の情報を分析することで、システムの品質向上や改善につなげることができます。
コメント