2015年3回目の勉強会を開催しました！！
藤田さんによる「テストプロセスについて考える」です。
参加者は8名。
内容は「ソフトウェア開発に関係したモデル」と「品質とプロセス」について、
資料を踏まえつつのディスカッションになります。
■アジェンダ
・ウォータフォール・モデルの解説と良い点、悪い点
・Vモデル・Wモデル・VVモデルの解説とWモデル・VVモデルの良い点、悪い点
・品質とプロセス
■ウォータフォール・モデル
特徴
・作業工程（要求仕様、基本設計など）を時系列にトップダウンで分割する
・原則とし前工程が完了しなと次工程に進めない
・並行作業（ex.設計中にプログラミング）を行わない
・前工程の成果物の品質を確保することで手戻りを最小限にする
etc
モデル例）
ウォーターフォールの良い点、悪い点のディスカッション
こんな意見が出ました。
（参加者コメント）
良い点
・順番に出来る
・見た目がわかりやすい、わかった気がする
・間違いないものが確実にできるならば後戻り不要
・スタート時に全体像(スケジュール・予算)が合意できる
・フェーズがしっかりしているので成果物が担保できる
・マネージャーが楽できる
・顧客が初期段階で安心できる
悪い点
・後戻りがしづらい
・スケジュールと予算は想定どおりにならない
・短期開発には向かない
・前工程の遅れが後工程にしわ寄せがくる
（所感）
（意外と）良い点に関する意見が多数でした。
「ウォーターフォール」というと諸悪の根源的な風潮になっている気がします。
開発の流れを「滝」というメタファでモデル化したものであって、その実はトップ・ダウン型のシーケンシャル開発。
純粋なソフトウェアだけで構成されるようなアプリケーションには不向きな点は多いと思いますが、
大規模で、しかもクリティカルなハードウェアを伴うようなソフトウェアには必要な考えでもあると思っています。
向き、不向きがあるというわけですね。
■Vモデル・Wモデル・VVモデルの解説
Vモデル
各作業工程に対するテストのレベルのモデル
モデル例）
Wモデル
テスト工程を上流工程に適用しテストアクティビティを前倒し他状態のモデル
VVモデル
開発でテストの設計を、検証で開発の設計を、双方の観点を取り入れた状態のモデル
Wモデル・VVモデルの良い点、悪い点のディスカッション
こんな意見が出ました。
（参加者コメント）
良い点
・牽制される(開発の独りよがりにならない)ため品質が高くなる
・ものづくりの本質に迫るアプローチ。(QCDオールよし！を実践)
・設計段階からテストを考慮出来るので品質・デリバリが良い
・上位文書でテスタビリティが良くなる
・仕様に関する問題点が早く出やすい
悪い点
・実感がない(ピンとこない)
・わかりやすい手順が示し難い（高いレベルが必要）
・大抵失敗する、テスト屋に開発スキルが必要(逆も然り)費用対効果的に難しい
・開発者はテストに興味がないので、テストの中身がおかしくなる。
・欠陥の発見工程より単純な定量的分析はできない
・実現が難しく、元に戻る(崩壊する)のが早い
・手戻りが発生した場合も開発が遅くなる(ウォーターフォールより線が多いから)
（所感）
Vモデル ＝ ウォータフォール と思われがちです。
Vモデル・Wモデル・VVモデルは作業工程毎にテストのレベルを対比したモノであって
決してプロセス自体を表しているわけではないことに気を付けないといけませんね。
■品質とプロセス
「プロセス」って何ですか？と言う問いから、はじまり、プロセスに関する資料をみながらディスカッション
製品品質に関する定義式について
Ｑpd（製品）
＝Ｑ pc （プロセス（仕掛け、仕組み））
×Ｑ rq （実際の要求仕様）
×Ｑ om（実際の組織、人材、知識、教育）
×Ｑ it （実際の技術、情報、部品、環境）
×Ｑ mt（モチベーション）
(出典：情報処理1995.5 p406)
（参加者コメント）
・成功事例から式の要素を出したように思える。
・製造における品質活動から出てきたのではないか？
プロセスが不具合の原因？いつまで経っても「不具合」が減らないのはなぜ？
「プロセス」が改善されていないから？定義されていないから？
（参加者コメント）
・品質改善を全てプロセス定義に頼らない方がいい。
・定義がなくても出来る改善はある。
・改善はプロセスが定義されていなくても出来ることがある。
ソフトウェア品質とプロセスの関係について
（参加者コメント）
・プロセスは必ずしも不具合の原因ではないでしょ？
・プロセス維持は固定化のことではない、改善も含まれる
・最低限の品質を抑える為の手段としてプロセスを使う
・プロセスとスキル以外に品質を向上させるものはある
・分厚い定義書を何も考えずに取り組むのは良くない
（所感）
プロセスを画一化・固定するのではなく、柔軟性と多様化が大事だなと思いました。
また、一般的に定義されたプロセスを（そのまま）適用するのではなく、そのプロセスを（適切な形で）使いこなすことが大事だと思いました。