ソフトウェア開発におけるクリーンルーム手法

（クリーンルーム・ソフトウェア・エンジニアリング）

概念

• 欠陥が混入しないように、開発工程と開発環境を注意深く制御し、監視する。欠陥が見つかったら、工程の欠陥とみなす。
  （ソース・コード・ファイルやコード・モジュールに欠陥があるのではない。設計仕様、設計手法、インスペクション（目視検査）技術の欠陥である。）
• 欠陥の特徴を調べ、どの開発工程に問題があり、どう対策するかを特定する。
• 工程を修正し、開発を再開する。
• 欠陥の見つかった元のソース・コードは廃棄する。
  →　「クリーンルーム手法において最も重要なツールは、ソース・コードを破棄するための『くずかご』である。」
  　　　　　　　　（クリーンルーム手法の提唱者の一人、Harlan Mills）
• 単体テストは実施しない。できあがったコードは、実行しないし、テストもしない。不具合なく動作するものとみなし、統合テストの工程に渡す。
  （モジュール単位の単体テストはプログラマが個人レベルで行うもので、テスト結果もプログラマが個人的に管理する。）
• 欠陥はすべて統合テストで見つけだす。
• ドキュメントやコードのような成果物はすべて、目視レビューの対象となる。１回の目視レビューの対象は大きすぎてはならない。３ページ以上に渡るコードからなるモジュールは分割する。

クリーンルーム手法を構成する４種の手法

1. 仕様構造化（structured specifications）：仕様を管理しやすい規模に分割：設計以前
2. 機能検証（functional verification）：修正のために形式的にチェック：設計
3. データ構造化（structured data）：ランダムにアクセスする配列などを削除：設計、コーディング、インスペクション
4. 統計的テスト（statistical testing）：シグマの値を使って品質を評価：統合テスト

仕様構造化

• 分割したそれぞれの仕様は、十分に小さなものでなければならない。（開発チームが数日ないし数週間で完成できる程度の規模）
  『プロジェクトが50%完了した』というのは、「全ての機能が50%の完成度」ではなく、「50%の機能が100%の完成度」を意味する。
• 個々の仕様をコーディングしたモジュールは、それぞれ単体で完全に実行あるいはテストできなければならない。（テストする際にモジュールの一部を切り離すようなことがあってはならない。欠陥が残る危険がある。）
• 分割した仕様が相互に依存し合うような関係にならないこと。（モジュールＡとＢがお互いに完成しないと完全な動作をしないような関係は不可。）

機能検証

• 仕様が正しいかどうかを検証するのではない。仕様で定義された通りのプログラムとなっているかを検証する。
• 前提条件として、階層構造を持つ開発工程であること。
• テストより人間の目視検査を重視する。「知的把握」(intellectual control)、「規範にのっとったプリミティブの評価」(legal primitive evaluation)、「分析的証明」(analytical proof)の３段階。
• 「知的把握」は、仕様からコードへ段階的に展開する開発手順をドキュメントでチェックする。
• 「規範にのっとったプリミティブの評価」は、数学的に導出した複数の質問を用意し、設計仕様書などの記述を検査し、誤りがないことを示す。
• 「分析的証明」は、用意した質問に数学的に答える手法。
• 「知的把握」の５原則（設計に携わらなかったレビューの参加者に対して、設計が正しいことを明らかにする。）
  

  原則１：

  完全なドキュメントを作成せよ。

  • 各階層のドキュメントはすぐ上の階層のドキュメントの記述を完全に反映していること。
  • システム仕様の各仕様をどの階層、モジュールで処理されるのか、明確であること。
  • 不足している箇所、余分な箇所、未定義の箇所、先送りしている箇所、記述に合わない箇所がないこと。

  原則２：

  与えられた定義とそのすぐ下にある全ての仕様を、１回のインスペクション作業でチェックせよ。

  • ドキュメントが５ページを超えるようでは、細分化が足りないことを示す。

  原則３：

  一つの階層レベルで、すべてのデータ項目のライフ・サイクルを完全に定義せよ。さらに、これを１回のインスペクション作業でチェックせよ。

  • データ項目はどこで、どのような理由で生成するのか？
  • 個々のデータ項目は、どのような理由でどういう値に初期化するのか？
  • 個々のデータ項目は、どこでどのように使うのか？使用した結果、どんな影響が生じるのか？
  • 個々のデータ項目は、どこでどのように更新するのか？どのような値に変わるのか？
  • 個々のデータ項目は、どこで、どのような理由で、どのように消滅するのか？

  原則４：

  データはいつも同じ仕組みで更新せよ。

  原則５：

  知的把握の際には、常にボトムアップの考え方を意識せよ。

  • 本質にかかわる決定を先送りしないこと。「後でなんとかなる」の考え方はだめ。
  • プリミティブに応じて質問を用意
    Dykstra のいうプリミティブ（If-Then-Else 文や While-Do 文など）に対して、数学的に導出した質問を用意する。
    例えば、While-Do 文であれば、�@ループが終了することが保証されるか？、�A条件が真のとき、実行部が処理されるか？
    処理結果は期待する結果か？、�B条件が偽のとき、処理結果は期待する結果か？

データ構造化

• あいまいなアクセス方法を排除
  ランダムにアクセスする配列や汎用ポインタは使うべきではない。ランダムにアクセスする配列は、キューやスタック、集合に置き換える。

統計的テスト

• 欠陥に遭遇する頻度で品質を評価
• ユーザ像を想定してテスト
  テスト・シナリオを作成する方法と、実行する方法を明示する。ユーザ・プロフィールを作成する。まず、システムが取り得るあらゆる状態を確認する。次に、それぞれの状態に対して、ユーザが起こし得る行動をすべて挙げる。さらに、ユーザがそれぞれの行動を起こす相対的な割合を計算する。
• あらかじめ決めておいた品質目標の水準に達したと予測し、その信頼性が高ければ、製品を出荷する。
  テストのカバー範囲が全コードの100%に達していなくても、全分岐パスの100%に達していなくても構わない。

クリーンルーム・ソフトウェア・エンジニアリングとは

• 信頼性が高く欠陥がゼロのソフトウェアを開発することを狙いとした管理手法と開発技法。
• 単体テストとデバグは不要。というより、有害である。
  デバグは効率が悪く、欠陥を生みやすい。欠陥ゼロを達成するための精神的な規範と集中力を損なう。単体テストを省略することは、開発担当者に欠陥をゼロにしようと決意させる要因になる。
• 理論的な裏付けがある。仕様定義、設計、正しさの検証の実践手法は、関数理論に基づく。テストと品質保証の実践手法は、統計理論に基づく。
• 「最初から正しい」ものを作る。
  チームによる正しさの検証を仕様定義と設計に結び付けた厳格な検証手法を用いる。テストの目的は、定義した仕様に基づき、ソフトウェアの品質を保証することであり、「デバグし尽くす」ことではない。品質はテストではなく、設計と検証によって保証される。
• 品質の高さは費用削減につながる。
  仕様定義段階に時間をかける欠陥が入りにくく、かつ、上流工程での欠陥の発見になり、修正にかかる費用も少ない。仕様を明解に定義するために、あるいは検証しやすいパターンになるように設計を単純化するため、検証の能率も上がり、コード量が少なくなる傾向にある。

クリーンルーム手法で用いる基本技法

増分開発

• 増分コードを次々と開発し、できた順に品質を保証していく

ボックス構造化

• 「ブラック・ボックス」、「ステート・ボックス」、「クリア・ボックス」を使って、システムの振る舞いを定義する。これらのボックスから、システムのアーキテクチャを構成するオブジェクトを派生させ、それらを結合する。
• 「ブラック・ボックス」は、あらゆる利用環境でシステムあるいはシステムの一部に求められる振る舞いを、仕様として表現したもの。外部からの入力、応答、一連の入力を応答に対応づける遷移規則として定義する。
• 「ステート・ボックス」は、ブラック・ボックスを詳細化したもの。ブラック・ボックスの代わりに、これを検証する。ブラック・ボックスの振る舞いを満足させるのに必要な「カプセル化した状態データ」を定義する。
• 「クリア・ボックス」は、ステート・ボックスを詳細化したもの。ステート・ボックスの代わりに、これを検証する。ブラック・ボックスの振る舞いを満足させるために、状態データに基づいたサービスの処理手続きを定義する。さらにこれを詳細化した段階では、新たなブラック・ボックスを使う。
• 新しいブラック・ボックス（仕様）は、詳細化してステート・ボックス（状態設計）やクリア・ボックス（手続き設計）を作る。新しいブラック・ボックスを作る必要がなくなるまで、詳細化を続ける。
• 仕様定義＝設計である。
• ボックス構造化の原則は、
  
  1. ある設計仕様で定義したり保持したデータはすべて、どれかのボックスにカプセル化する。
  2. すべての処理は複数のボックスを連続して使うか、複数のボックスを並列に使うことによって定義する。
  3. ボックスを使う場合は、システムの利用階層図に、使う位置を明記する。

正しさの検証

• チームによるレビューで正しさの検証を行う。
• すべてのクリア・ボックスのプログラムは、順次処理、If-Then-Else 文、While-Do 文 及びこれらの変形といった、入れ子と順序の決まった制御構造で構成される。制御構造に対応する機能のマッピングは、設計書に予定機能として記述する。
• 順次処理、If-Then-Else 文、While-Do 文 という制御構造は、それぞれたかだか、１個、２個、３個の「正しさの条件」を検査すれば事足りる。チームによるレビューでそれぞれの制御構造の正しさの条件を調べれば、限られた工数で正しさを検証できる。

統計的な利用テスト

• 利用テストは品質保証チームが実施。
• ユーザがやりそうな利用方法を想定したテストを行う。「利用方法の確率分布」を作成し、利用方法についてあらゆる側面から考慮して、システム入力を定義する。（名目的なシナリオから、誤りの起きる条件やシステムに負荷をかける条件まで含む。）
• テスト・ケースは利用方法の確率分布をもとにランダム・サンプリングで生成する。
• 個々のテストの入力に対する正しい出力は、ソフトウェアの仕様定義書を参照して決める。