ソフトウェアの品質

久しぶりにソフトウェアの検証を行う事になり、改めて思うところがあるので記述する。ソフトウェアの品質は、テスト工程で向上させる事はできない。そう、設計の段階から品質について検討し、作り込んでいく必要がある。

昔がてらの開発手法となぞられる ウォーターフォールのV字モデルなどの



左半分の「要件定義」、「外部設計」、「内部設計」、「開発実施」におけるV字型の前半部分で「品質を作り込む工程」を行い、右半分の「コンポーネントテスト」、「結合テスト」、「システムテスト」におけるV字型の後半で「品質を確認・検証する工程」となる。要件や仕様がすべて製品に反映されているかは「システムテスト」工程で検証し、「外部設計」工程の成果は「統合テスト」工程で、「内部設計」工程の成果は「コンポーネントテスト」工程で検証する。

しかし、問題点がある。初めて対応するシステム構成 および システムが複雑な場合、要件定義工程で全ての要件を洗い出す事が困難であり、要件定義工程での漏れは、リスクとなり得る。そのリスクは、テスト工程がプロジェクト後半にある為、要件定義工程や外部設計工程などの上流工程に欠陥があっても、それがプロジェクトの終盤まで発見できない事が多い。その為、終盤で欠陥が発見された場合、手戻りが発生してコストが膨大になる事となる。


ここまで話を進めてしまうと開発プロセスについても語りたくなるがところだが、今回の主旨と違うのでピックアップだけにしておく。

• 「計画」、「要件定義」、「設計」の各工程が 1つのサイクルとなり、各サイクルで、目標設定、分析・開発、検証、次サイクルの計画を実施するスパイラル型


• ウォーターフォール型の上流工程にプロトタイピングを組み合わせる型


• システム全体をいくつかの部分（サブシステムやコンポーネントなど）に分割し、追加していく「インクリメンタル型」と、分割した部分ごとに開発・テストを繰り返してシステムとする「イタラティブ型」


• 小規模なクライアント／サーバー型のシステム開発で使用された開発ツールのRAD（Rapid Application Develoment）


• XP（eXtreme Programming）、FDD（Feature Driven Development）、TDD(test-driven development)、スクラム（SCRUM）などの「アジャイル型」反服サイクルを数週間から2,3ヶ月程度で ユーザーからのフィードバックの頻度を増やし、システムの仕様を明確にする

実際のプロジェクトに適用するには《適材適所》という事に尽きる。開発対象となるシステムやプロジェクトの特性、コスト、開発体制、採用する技術、要員のスキル、スケジュールなどに応じて、開発プロセスを選択し、組み合わせる事になる。例えとしてシステムによっては要求される品質レベルが異なり、品質の体制 や 作業項目が違ってくる、また、分散した開発拠点で行う場合は、コミュニケーション計画や開発環境の整備が必要となり、そして要員のスキルや経験が不足している場合は開発プロセスやツールなどの教育 や 訓練を行う必要がある。どの様な開発を進めるにも、まずはプロジェクトの初期段階でスコープを明確にし、管理する事は変わらない。
詳細は、Web上を検索すると 開発プロセスについて 各達人たちが解説しているので一読しておくと良いと思う。


ここで話を戻し、要するに V字型の前半部分で作成される以下が入力項目となり

• 要件定義：システム要求の調査と分析からシステム要件を定義


• 外部仕様：サブシステムの定義、システム機能仕様、ユーザー・インターフェース設計、データベース設計、運用障害設計


• 内部仕様：プログラム構造設計、プログラム機能仕様、モジュール定義


• 基本計画：システムの全体スケジュール


• 品質管理計画：品質の定義


• テストツール仕様：選定したテストツール仕様

テスト工程全体の マスタープランとなる テスト方針を作成させる。




テスト方針 (Comprehensive Test Plan)

• テスト工程全体の構成


• 各テストの位置付けや目的


• テスト方法


• テストの開始・終了基準


• テストケースの定義方法(何をテストするのかを定めたもの)


• テストツールと使用データ


• テストのスケジュール


• テストを実施する組織計画

テスト方針は、プロジェクトの要員、スキル、コスト、スケジュールからもっとも有効な方針を立てて、限られたスケジュールとリソースでテストを効率よく行う。パフォーマンスやセキュリティ、信頼性といった最もクリティカルな要件や機能を重点的にテストする計画を立てる。

と言う様に V字の後半にあるテスト工程を実施するにもプロジェクトの初期段階でスコープを明確にしている事が重要である。



テスト計画 (Test Plan)

• テストの目的と範囲


• テスト方法


• テストの開始基準・終了基準


• テスト資源と体制


• スケジュール


• 検収方法

テスト方針を作成したらテスト方針に沿って各項目をブレークダウンしてテスト工程ごとの詳細な計画を作成する。「テストの目的と範囲」は、製品の売りから導きだされた 開発プロジェクトの役割 および 品質目標・製品リスク からテスト工程の対象・範囲を明確にする。「テスト方法」は、使用するテストツールやバグトラッキングの構成、テストツールの使用、テストケースの定義、テストケースの採番、テストデータの作成や保管、テスト・シナリオの組み方、テスト実行結果の記録や結果の検証、デバッグや欠陥の管理を明確にする。「検収方法」は、システムの開発契約義務の履行そして不履行を判断するのに必要な行為である。検収行為の内容や程度は、開発するシステム規模や技術レベルに応じて当事者間の合意によって決定される。検収の方法や期間、検収テスト(テストデータの種類と内容)、結果の評価方法などを事前に合意しておく。
更に深掘りし、テスト設計の進め方 や テスティングについて 各達人たちがWeb上で解説しているので一読しておくと良いと思う。


さて纏めに入らないとダラダラ記述しているだけで読み辛いものになるので纏めに入る。そこで伝えたい事の原点に戻り、「品質」の概要をWikipediaから引用すると“非常に広範な概念を含む語であり、一概に定義づけることは難しいが、おおよそ、提供される製品やサービスについて、買い手側である顧客が求める特性との合致度と考えられる（合致度が高ければ品質が高いといわれる）”と書かれている。
更に「ソフトウェアの品質」の定義をWikipediaから引用すると“ジェラルド・ワインバーグは著書 Quality Software Management: Systems Thinking v. 1 で「品質とは誰かにとっての価値である」と書いている。この定義は品質が本来主観的なものであることを強調している。同じソフトウェアであっても人によって品質の感じ方は全く異なる。この定義の利点は、ソフトウェア開発チームに「このソフトウェアは誰のために作っているのか?」とか「彼らにとって価値とは何か?」といった疑問を抱かせる点にある。品質を「目的への適合性」と定義する場合、品質を測定するのに使うべき尺度（属性）を決定する際に、そのソフトウェアの目的を考慮する必要があることを意味する。”である。

ソフトウェアは「人間が考えて人間が作るもの」である。
その人間は「知識不足、勘違い、経験不足、思い込み」の生き物である。

だから遣りたい事を明文化(文章だけでなく、製品を早い段階から見せて合意する事も含まれる)して その明文化したものが「正しく作ったか、正しく動作したか」を検証・確認するのがテスト工程であり、設計の段階で明文化する そうウォーターフォールV字モデルの左半分で遣る必要がある。

冒頭の「ソフトウェアの品質は、テスト工程で向上させる事はできない。そう、設計の段階から品質について検討し、作り込んでいく必要がある。」で 言いたかった事である。もう一度、ソフトウェアの品質について考えてみては如何でしょうか。


株式会社ジェイエスピー
システム部
秦　健一


monipet
　　動物病院の犬猫の見守りをサポート
　　病院を離れる夜間でも安心

ASSE/CORPA
　　センサー、IoT、ビッグデータを活用して新たな価値を創造
　　「できたらいいな」を「できる」に

OSGi対応 ECHONET Lite ミドルウェア
　　短納期HEMS開発をサポート！

GuruPlug
　　カードサイズ スマートサーバ

株式会社ジェイエスピー
　　横浜に拠点を置くソフトウェア開発・システム開発・
　　製品開発(monipet)、それに農業も手がけるIT企業