第43回「ソフトウェア品質の品質評価１」
前回（42回）でソフトウェア製品の品質測定について記述しました。測定したからには分析して評価することが重要となります。「SQuaRE」シリーズではISO/IEC 2504ｎが品質評価の規格として定義されています。
要求定義・設計工程における品質評価のポイント
ソフトウェアの評価の考え方は多様であり、個人としては利用目的（社会的影響の度合い）によって大きく異なると考えています。評価対象は、３つに大別されます。
生命に影響する
利用者（接続先含む）に影響する
影響ない
生命に影響するシステムは原子力発電の制御、航空管制システム、自動車制御、医療系システムがあります。この分野は業界単位に厳しい安全基準が定められており、専門の認定機関による評価が行われるため、今回の評価対象からは除外して説明します。
システムのおける品質評価は、作業フェーズ単位で行う必要があります。
具体的には以下の工程となります。
要求定義
設計作業
プログラム製造
テスト作業
マニュアル
最近の要求定義書を見た際、技術的な要求内容については詳細に記述されているが、基本的な内容の記述が不十分であると思いました。一番大切なのは、概要として「どんなシステムなのか」「対象利用者はどの範囲なのか」「そのシステムを利用することでどんな利便性や効率性を求めているのか」「どのような利用状況を想定しているのか」この前提条件がしっかり書かれていないと、求める粒度が曖昧となりトラブルの原因となります。
この要求定義での評価のポイントは、レビューの指摘内容や、その密度です。定義書を経営者、管理者、運用者などの立場の違う関係者がきちんと検討しているか。システム担当者が業務担当者や運用担当者の意見を聞いて反映しているか。簡単な評価であれば、作成にいたるプロセスをヒアリングするだけでも可能です。議事録を閲覧できる場合には、その内容からどれだけ意見の集約が行われたか判断可能となります。
要求仕様書作成にかかる計画書も評価対象となります。どれくらいの規模（機能数や項目数で判断）のシステムを、どれくらいの時間をかけて、どのような関係者が関わって作成したか。また、指摘事項が何件あって、レビューが何回行われたのか。計画書から測定して評価できる内容となります。
設計作業の評価は、開発の知識がないと難しい作業です。すべての設計書（仕様書）を読み込む作業は一般には行いません。私の場合は、作成者のスキルシートを見せてもらい担当した業務や対象物の経験値を測定します。その上で複数名（例としてＡ・Ｂ・Ｃの３名程度）の設計書を比較して「整合性がとれているか」「記述の粒度に差がないか」「共通仕様が認識されているか」「設計工程のスケジュールや投入人数が適切なのか」を確認します。
その後、完成された設計書のレビューがどのように行われその際の指摘件数がどれくらいあるか測定、数値化します。設計書の内容から想定して指摘事項が多ければ、その後のプログラム製造での不具合発生の可能性は高くなります。
テスト工程と品質評価
プロジェクトによっては、この時点後に並行してテスト計画やテスト仕様書の作成も行われます。しかし、テスト仕様書は設計書をコピーして、「記述されている機能をテストすること」しか書かずに作成しているケースがあります。このケースは適切とは言えず、単に納品のための成果物のボリュームを増やす無駄な工数です。テスト計画書を作成し、開発規模に見合ったスケジュールや要員計画を確認する。仕様書が書かれていれば設計同様レビュー状況や指摘件数を測定、数値化することが評価に必要です。
