第45回 ソフトウェア品質の品質評価1

ソフトウェア品質の品質評価1

前回（第44回）でソフトウェア製品の品質測定について記述しました。測定したからには分析して評価することが重要となります。「SQuaRE」シリーズではISO/IEC 2504nが品質評価の規格として定義されています。

第44回 ソフトウェア品質の品質測定2

ソフトウェアの評価の考え方は多様で、個人的には利用目的（社会的影響度合い）で大きく異なると考えています。詳細は表-1を参考にしていただきたいのですが3つに大別されます。

1. 生命に影響する
2. 利用者（接続先含む）に影響する
3. 影響ない

生命に影響するシステムは原子力発電の制御、航空管制システム、自動車制御、医療系システムがあります。この分野は業界単位に厳しい安全基準が定められており、専門の認定機関による評価が行われるので、今回の評価対象からは除外して説明します。

システムにおける品質評価は、作業フェーズ単位で行う必要があります。具体的には

1. 要求定義
2. 設計作業
3. プログラム製造
4. テスト作業
5. マニュアル

となります。

最近の要求定義書を見ると技術的な要求内容については、詳細に記述されていますが基本的な内容の記述が稚拙であると思います。一番大切なのは概要としてどんなシステムなのか。対象利用者はどの範囲なのか。そのシステムを利用することでどんな利便性や効率性を求めているのか。どのような利用状況を想定しているのか。この前提条件がしっかり書かれていないと求める粒度が曖昧となりトラブルの原因となります。

この要求定義での評価のポイントは、レビューの指摘内容やその密度です。定義書を経営者、管理者、運用者等の立場の違う関係者がきちんと検討しているか。システム担当者が業務担当者や運用担当者の意見を聞いて反映しているか。簡単な評価は、作成にいたるプロセスをヒアリングするだけで可能です。議事録を閲覧できる場合は、その内容からどれだけ意見の集約が行われたか判断可能となります。要求仕様書作成にかかる計画書も評価対象となります。どれくらいの規模（機能数や項目数で判断）のシステムをどれくらいの時間をかけて、どのような関係者が関わって作成したか。また、指摘事項が何件あって、レビューが何回くらい行われたのか。計画書から測定して評価できる内容となります。

設計作業の評価は、開発の知識がないと難しい作業です。全ての設計書（仕様書）を読み込む作業は一般には行いません。私の場合は、作成者のスキルシートを見せてもらい担当した業務や対象物の経験値を測定します。そのうえでABC3名程度の設計書を比較して整合性がとれているか。記述の粒度に差がないか。共通仕様が認識されているか。設計工程のスケジュールや投入人数が適切なのか。その後、完成された設計書のレビューがどのように行われその際の指摘件数がどれくらいあるか測定、数値化します。設計書の内容から想定して指摘事項が多ければその後のプログラム製造での不具合発生の可能性は高くなります。

プロジェクトによってはこの時点後に並行してテスト計画やテスト仕様書の作成も行われます。最近のテスト仕様書は設計書をコピーして、「記述されている機能をテストすること」しか書かずに作成しているケースがあります。これは論外で、単に納品のための成果物のボリュームを増やす無駄な工数です。テスト計画書を作成し、開発規模に見合ったスケジュールや要員計画を確認する。仕様書が書かれていれば設計同様レビュー状況や指摘件数を測定、数値化することが評価に必要です。

次回は6月29日（木）更新予定です。