2015年5月
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
無料ブログはココログ

« 2008年11月 | トップページ | 2009年1月 »

2008年12月

2008年12月26日 (金)

【定量的品質予測のススメ】測定項目はどう定めるべきか

P38「(a)測定項目の一覧表をもとにした測定とデータの精査」において「測定項目の一覧表を作り「(b)測定データの一元化と正規化」において「複数の測定項目から意味のありそうな項目を集計(一元化)する」とある。

一方、P28「品質予測の実際」には「以下に紹介する測定項目や分析を全て行うのではなく、効果に見合った測定・分析コストだけをかけるようにしていただきたい」とある。

この2つの記述は両立できるのだろうか。

「複数の測定項目から意味のありそうな項目を集計(一元化)する」というのは、測定時はこの項目を使って管理を使用と確信しているわけではないということを意味するであろう。

一方で、「測定項目や分析を全て行うのではなく、効果に見合った測定・分析コストだけをかけるようにしていただきたい」というのは、意味の有りそうな項目を事前に絞ってから測定を始めよと言っている。

これを矛盾と呼んでよいのであろうか。

書籍としての一貫性の観点からは矛盾といってよいであろう。

しかし、2つの記述はそれぞれ真であるとも言える。

昨今の開発環境の進歩は目覚しいものがある。
単体テストは自動でするものというのが常識の開発者も多いであろう。

しかし、一方で、未だ昔ながらのシステムの子守りをしている開発者も多い。
彼らには、単体テスト自動化といってもピンとこないであろう。

そもそも、旧来のシステムにおける単体テストは、昨今の開発者から見たら「それは結合テストでしょう」というものばかりであろう。

この旧来のシステム開発者に取っては、測定項目の追加は即ち「コストの増加」なのである。
彼らにとっては、「測定項目や分析を全て行うのではなく、効果に見合った測定・分析コストだけをかけるようにしていただきたい」というのは、真なのである。

一方、昨今の恵まれた開発環境の開発者にとっては、単体テストだけでなく、開発の生産性項目・品質項目に関わらず、様々な項目が「勝手に」自動化されて取られてしまう状況にある。
彼らにとっては、勝手にあらゆる項目を自動収集されるわけだから、「複数の測定項目から意味のありそうな項目を集計(一元化)する」というのは、真なのである。

このように、相反する記述はそれぞれ立場によっては正しいのである。
しかし、この「立場によっては」という語を外して提示されると、やはり違和感を感じるであろうし、それが正常な反応である。

本書が、この内部矛盾を意図的にしているのであれば、できればそれが分かるようにガイドしてあげる必要があろう。

そうでなければ、P38だけ読んだ人と、P28だけ読んだ人で、同じ本を読んでいるのに測定項目に対する考え方が反対になってしまう危険性がある。
両方読んだら読んだで、あれ、と悩むことになるのだが。

2008年12月25日 (木)

【定量的品質予測のススメ】ソフトウェア信頼度成長モデルの横軸は何を取ると良いか

P91「1. ソフトウェア信頼度成長モデルとは」において、「横軸は、経過時刻だけでなく、消化テスト項目数や作業工数等を取ることが多い」とある。

さらりと書いてあるが、ソフトウェア信頼度成長モデルの本質に関わる事項である。

まず、横軸をどう取ろうとも同じ曲線になるのであろうか。
否である。

経過時間と消化テスト項目数、作業工数とそれぞれで取れば、それぞれ異なる曲線となることは容易に想像できよう。

そうであるのに、何故一まとめにして「横軸は、経過時刻だけでなく、消化テスト項目数や作業工数等を取ることが多い」と言うのであろう。

ここで、P64「(6)信頼度成長モデルの適用条件の考慮」に書かれている「横軸に指定した単位間で同じテスト密度になるように、単位を設定することが理想である。しかし現実には難しく、横軸としてテスト日数やテスト消化率、テスト工数を取ることが多い。したがって予測の解釈には注意が必要である」という記述を思い出したい。

本書ではP91とは離れた場所で、横軸には偏りのないものを取るべきであるが、経過時間にしろ、消化テスト項目数にしろ、作業工数も、どれも「横軸に指定した単位間で同じテスト密度になるように、単位を設定すること」ができない代用軸であると認めているのだ。
であるのにP91では「横軸は、経過時刻だけでなく、消化テスト項目数や作業工数等を取ることが多い」と代用軸ではないかのように書かれている。

それぞれ見てみよう。
経過時間につれ、確かに欠陥発見件数は増えようが、1項目のテストに半日かかる日もあれば、数秒で終わるものもあろう。そうであれば、経過時間当たりの指摘欠陥数も、個々でみれば大きなばらつきがでよう。

消化テスト項目数にしても、どのようにテストするか、オンライン処理の細かい1項目とバッチ処理が同じ1件で計上して良いのか、何をもってテスト1件とするのか、という1件の重み付けの問題がある。

作業工数は、テストのための仕込み工数もなぜ含めるのか。確認が大変なテスト1件と容易なテスト1件ではなぜ違いがあるのか。

そもそも、経過時間と消化テスト項目数、作業工数と横軸に種類があるのに、なぜ曲線の種類に、「経過時間」用、「消化テスト項目数」用、「作業工数」用がないのか不思議に思うべきである。

そのようなものはない。

ソフトウェア信頼度成長モデルは、理想的テスト条件の元で、累積指摘欠陥数は立ち上がりが急で、段段と平坦に収束するはずだという思い込みから出発しているのであるから。

そして曲線も、どんな立ち上がり方でも寝方でも対応できるような式を探しているだけの話で、「ソフトウェア開発においては、これこれこのような理由から、本質的にこれこれのような曲線になる」と論理的に証明されているものではない。

実際にデータを取ってみて、当てはめて、「あ、この曲線が合いそうだね、じゃあ、あと何件の指摘を挙げよう」と言っているだけのものである。

さて、本書では横軸に、経過時間と消化テスト項目数、作業工数の3つが例示されているが、どれを取っても同じ管理が出来るのであろうか、それとも、それぞれ別の意味を持つのであろうか。

経過時間なら、あと何時間テストをすれば良いかというテスト期間の推測としての活用になる。
納期との調整に使用することになる。
しかし、テストしてもしなくても時間は過ぎていくがそれも数えて問題ないのだろうか。

消化テスト項目数なら、あと何件テストをすれば良いかというテスト件数の推測としての活用になる。
網羅率やテストパターン見直しの話になる、
しかし、テスト1件とはどういう意味かの議論になる。

作業工数なら、あとどれだけの工数分だけテストをすれば良いかというテスト時間の推測としての活用になる。
現在保有要員で出来るか追加が必要かの話となる。
しかし、そもそも工数がかかるテストとかからないテストがあるがどうするのかという話がある。

もし、ソフトウェア信頼度成長モデルがきれいに適用できるのであれば、これら3種はそれぞれ作成すべきものであろう。
納期と要員、追加テストのやりくりを総合的にみるためにはそれぞれが必要であるから。

しかし、実際の開発現場では、この3つもしくは他の横軸のいずれか1つで管理されていることが多いであろう。

経過時間と消化テスト項目数、作業工数のいずれが良いのかという議論さえある。

「横軸は、経過時刻だけでなく、消化テスト項目数や作業工数等を取ることが多い」とだけいうのではなく、それぞれどのような意味を持ち、長所短所はなにかの説明がないと、今からソフトウェア信頼度成長モデルを使おうという組織では、どれを選べばよいか、それともどれでもよいのかが、わからないであろう。

ソフトウェア信頼度成長モデルによる予測はそもそも賛否両論のある手法なので、積極派と消極派の考えを対比的に記述されていると良かったであろう。

2008年12月24日 (水)

【定量的品質予測のススメ】ソフトウェア信頼度成長モデルはお勧めなのか

P91「B ソフトウェア信頼度成長モデル」において、「しかし、その後の研究から種々のモデルが提唱された。現在では、こうしたモデルを統合的に扱う研究やツールの普及が進み、予測精度は格段に向上してきている」とある。

これまで、本書では信頼度成長曲線は度々書かれていたが、今一つ絶対お勧めと言う形では扱われていなかったが、本書のスタンスは結局は推奨しているのだろうか。

さらにP93において種々の信頼度成長モデルを統合したモデルについての記述で「なお、統合モデルについては市販ツールも存在し、これを利用すれば、既存の単独モデルのみを使用した場合に生ずるモデル不適合による誤差の増大の問題や、既存の複数のモデルを適用すつ場合に生ずる際的モデル選択作業の煩雑さから開放され、安定した精度で残存欠陥数の推定ができる」とある。

この記述からみれば、信頼度成長モデルは使えるツールとして考えられているようである。

しかし、P11の「テストに極端な偏りがないことや、テストの網羅性が十分確保されている等々注意すべきことがあり、信頼度成長モデルだけでテストの終了を判断するのは不充分である」という記述も合わせて読まねばならない。

モデルの曲線を実測値にフィットするように変形してくれる便利なツールがあるのは良いが、その元となる計測が、信頼度成長モデルを適用できるレベルに達していることが重要なのである。

収束に向かってきたと思ったら、立て続けに欠陥が出てきたということが過去のプロジェクトでなかったであろうか。

「テストに極端な偏りがないことや、テストの網羅性が十分確保されている等々」という記述は甘くみてはならない。

「信頼度成長モデル(この場合S字モデルをイメージ)は、テスト開始直後は環境準備等に時間を要するために指摘件数の立ち上がりは遅いが、すぐに開発した機能の確認が始まるので曲線の立ち上がりが急になる。開発した機能のテストが一段落ついたところでレグレッションテストを行うから寝るんだよ」みたいな説明をする人も入るが、そのような使い方は信頼度成長モデルとはいえないのではないか。

単なる発見欠陥のプロットと呼ぶべきである。
なぜか。

開発した機能の確認が不充分の時でも、レグレッションテストを行えば寝るからである。
これで信頼度が成長したとは言えまい。

また、信頼度成長モデルからあと10個欠陥を出さねばと言ってテストしたら、バグが50個も出てきた場合どうするのであろうか。
そのようなことはありえないので仮定することもおかしいことなのだろうか。

2008年12月23日 (火)

【定量的品質予測のススメ】「標本数の確保」と「詳細な品質管理、分析」

P83「3.3.6 事例:プロセスパフォーマンスベースラインを活用したプロジェクト品質予測」の「(4)効果」において、「標本数の確保」として「プロジェクトの特性条件を絞ってパフォーマンスベースラインを設定しようとすると、標本数が少なくなり信頼性に問題が発生する」とある。

一方、P11「2.2.1 測定単位(品質管理単位)」において「測定単位を細かくして品質データ(欠陥数等)を測定することにより、詳細な品質管理、分析を行うことができる」と書かれている。
また、P63「(5)プロジェクト特性に合わせた品質目標の設定」において「品質目標は一意に決まるものではない。ユーザの求める品質要求や、品質への投資コストの大小により、品質目標が変わってくる」「プロジェクトの特性に合致した品質目標を設定すべきである」と書かれている。

これらは両立する考えなのだろうか。

定量的品質予測と一口に言っても、大雑把に傾向をつかむためのものから、精緻な管理限界を定めるものまで目的・用途は様々であるから、考え方としては両立する。。
要は、信頼性が確保できる程度に管理単位を細かくできる落としどころを探せと言うことである。

本書が少々使いづらいのは、これらの一見相反する考え方が、併記されず、別なところに書かれていることである。
そのため、本書を活用しようとする際に、一方のみにしか注意が向かなくなり、もう一方を見落とす可能性がある。

「3.3.6 事例:プロセスパフォーマンスベースラインを活用したプロジェクト品質予測」にしても、「プロジェクトの特性条件を絞ってパフォーマンスベースラインを設定」することの問題が挙げられているが、では、同業他社とも連携してデータ集めをすれば、標本数が大きくなるので良いことなのであろうか。
標本数は大きくなるが、プロジェクトや組織、個々のシステムの特性条件の違いによるばらつきも増大するので、管理限界は広がり、それで管理が改善されると短絡的に言えるわけではない。

「標本数の確保」と「詳細な品質管理、分析」は、相反するのであるが、両者の折り合いがつく点を探すことが、定量的品質予測には重要である。

「標本数の確保」のために「詳細な品質管理、分析」を犠牲にして、管理限界がぼやっと広い管理も改善の余地があるし、「詳細な品質管理、分析」のために「標本数の確保」を無視して、細分化しすぎとなり指標が全然収束しないというのも改善の余地があると考えねばならない。

2008年12月22日 (月)

【定量的品質予測のススメ】成功プロジェクトと失敗プロジェクトのトレンド解釈は簡単にできるのであろうか

P82「3.3.6 事例:プロセスパフォーマンスベースラインを活用したプロジェクト品質予測」の「(2)考え方」において、「品質目標達成プロジェクト(成功プロジェクト)と品質目標未達成プロジェクト(失敗プロジェクト)のテスト工程のトレンドに差があるという前提において、成功プロジェクトの工程ごとの欠陥密度のトレンドをモデル化する」と書かれている。
その上で、「(3)方法(項目、手法[把握、予測])」において、「予測判定は、実績値が3σの範囲で推移していれば成功プロジェクトに限りなく近いと予測し、3σを逸脱している場合は失敗プロジェクトに限りなく近いと予測する」とある。

また、P20「コラム モデル化時の注意点」において、「ソフトウェア開発では複数の要因(特に人的要因)が大きく影響するため、測定値に大きなバラツキが出る(すなわち分布の山がなだらかな)傾向が有り、しかも正規分布にならない場合が多い。したがって、実際の現場では管理限界±3σでは範囲が広過ぎて利用できないことが多い」と書かれている。

この、パフォーマンスベースラインは、P20の注意点をはねつけられるほどデータは収束するものであろうか。
成功プロジェクトと失敗プロジェクトの定義も難しいが、欠陥密度の工程の傾向をみてトレンドを解釈するというのは、単なる欠陥密度の評価以上にばらつきの要因があると思われる。

2008年12月19日 (金)

【定量的品質予測のススメ】コスト効率は最優先で監視するものなのか

P80「(a)コスト効率が悪化してしまった場合」において「一般的には、コスト効率は悪化すると、ほとんど挽回できないため、悪化させないように最優先で監視する」とある。

「最優先で監視する」、この表現に違和感を覚える。

コストは重要ではあるが、「最優先して」監視すると言う表現は行きすぎではないだろうか。
確かにそのような組織は存在するかもしれない。
特にSIerにおいてはその意識が強いかもしれない。

しかし、スケジュールの監視より、リスクの監視より、さらに品質の監視より、コストの監視が再優先と言いきれるのは何故なのであろうか。

表現として「最優先で監視する」ではなく、「常時監視する」程度で解釈すれば良いのではないだろうか。

少なくとも、SIerではなく社内システム部門においては、コスト再優先の管理をすべきとは言えない。

また、見積もり精度が甘ければ、監視したところでどうしようもない。
コストばかり監視する対性であると、当初見積もりが不必要に大きく計上されるという本末転倒の自体を招く可能性があることを留意しなければならない。

2008年12月18日 (木)

【定量的品質予測のススメ】プロジェクト品質の予測モデルとプロダクト品質の予測モデルの違いはどこか

P77「(2)プロジェクト品質の予測モデル」において「多くの成功プロジェクトでは内在する誤りを早い段階で潰しているのに対し、失敗プロジェクトではレビューの甘さが後工程で露呈する傾向にある。このモデルは、その傾向がプロジェクト全般に当てはまることを前提とし、レビューやテストにおける欠陥密度でプロジェクトの遂行能力を定量化しようというものだ」とある。
更に「具体的な指標として、レビューにおいては1ページ当たりの欠陥数、テストにおいてはKLOCあたりの欠陥数を用い、成功プロジェクトのパターンを抽出し、モデル化する」と続く。

これを、「プロジェクト品質の予測モデル」と言ってよいのであろうか。

どうしても、プロダクト品質の管理の話にしかみえない。
単に、全プロジェクトデータを元に算出するのではなく、成功プロジェクトのデータのみを使ってレビュー指摘密度、欠陥密度の指標を定めると言っているだけではないのか。

2008年12月17日 (水)

【定量的品質予測のススメ】「プロジェクトの健全性」とは何か

P75「(d)仕様変更状況」「(e)問題課題状況」「(f)労務状況」「(g)プロセスの遵守度」において「プロジェクトの健全性」という言葉が何度も出てくる。

確かに便利な言葉である。
なんとなく意味が分かるように思えるが、具体的には、「プロジェクトの健全性」とは何かと聞かれたら誰もが同じ認識となるであろうか。

少々抽象的過ぎる。
1、2ヶ所ならともかく、6ヶ所も出てくるので、「プロジェクトの健全性」について、定義・言及されても良いと思われる。

この周辺の記述としては、「(g)プロセスの遵守度」において「プロジェクトの歯車が合わなくなると」という比喩的表現もある。
人によって捉え方が異なる可能性がある語句は避け、もう少し、具体的に書かれた方が良かろう。

2008年12月16日 (火)

【定量的品質予測のススメ】とにかくたくさんの項目を測ってから仮説を立てて良いのか

P71「3.3 プロジェクトの品質予測」の「3.3.2 アプローチ」において、


予測を行うためには、まずプロジェクトの現状を正しく把握する必要がある。
予測モデルを作るためのアプローチは次の順番になる。
  ①定量データによりプロジェクトの現状をとらえる。
  ②プロジェクト途上の状況が最終結果に及ぼす影響を蓄積データから分析する。
  ③因果関係について仮説を立て、定量的な裏づけからモデル化する。

とある。

このアプローチは何を意味するか。

とにかく何も考えずにたくさんの項目を測れ、と。
そして出てきた数字をみて初めて仮説を立てて考えろというアプローチである。

風が吹いたら桶屋がもうかるみたいな仮説を立てる可能性はないのであろうか。

「因果関係について仮説を立て、それを計測で検証する」を最初にするアプローチもあることも忘れてはならない。

データから仮説を探すと、怪しげな因果関係仮説が生まれる可能性があることに注意。
関連のある2つの測定項目が、何でも正比例関係にあると考えることも危険である。

人間の活動がそれほど均一なのだろうかという前提をもって当たることが重要である。

2008年12月15日 (月)

【定量的品質予測のススメ】ゾーン分析フラクタル

P65「3.2.5 事例:ゾーン分析例」において、

・サブシステム全体の分析結果が上記のように目標ゾーンに入っているから品質がよいと判断するのは粗すぎる。

・この例では、業務機能ごとにゾーン分析をすることで、業務機能A,B,Cの品質が目標ゾーンから外れていることがわかる。

とある。

この事例では、当てはめる目標ガイドが、サブシステム全体と各業務機能A,B,C,Dで同じであるが、それでよいのであろうか。
計測単位を細かくすれば、分母が小さくなるので誤差が大きくなると言うことは、この事例の場合には想定する必要はないのであろうか。

であれば、
・サブシステム全体及び業務機能ごとの分析結果とが上記のように目標ゾーンに入っているから品質がよいと判断するのは粗すぎる。

・この例では、モジュールごとにゾーン分析をすることで、業務機能A,B,Cの品質が目標ゾーンから外れていることがわかる。
ということはできないか。
さらには、
・サブシステム全体及び業務機能、モジュールごとの分析結果とが上記のように目標ゾーンに入っているから品質がよいと判断するのは粗すぎる。

・この例では、プログラムソースごとにゾーン分析をすることで、業務機能A,B,Cの品質が目標ゾーンから外れていることがわかる。
ということはおかしいのか。

さらにさらに、
・サブシステム全体及び業務機能、モジュール、プログラムソースごとの分析結果とが上記のように目標ゾーンに入っているから品質がよいと判断するのは粗すぎる。

・この例では、1論理ステップごとにゾーン分析をすることで、業務機能A,B,Cの品質が目標ゾーンから外れていることがわかる。
ということはおかしいのか。

論法は同じであるが、最後はおかしく感じるはずである。
どこで、止めるべきなのか。

収束するのは統計だからという前提を忘れていないか

Bの例では、テスト密度達成率85.3%でテスト不足と品質評価されている。

5.3%のずれ。
とりあえず、ずれたら分析することは良いとして、テスト密度達成率85.3%という数字の方に着目すべきである。
この事例では、なんと百分率の有効数字3桁で管理していると言うのだ。

これはとてつもない管理であると思われる。

百分率の有効数字3桁の精度での欠陥件数の管理・・・確かにそれができる組織であれば定量的品質予測も可能であろう。

2008年12月12日 (金)

【定量的品質予測のススメ】信頼度成長モデルは精度の高い実用的な物差したりうるか

P64「(6)信頼度成長モデルの適用条件の考慮」において「また、信頼度成長モデルでは、テストの進捗に合わせて欠陥数を累積していく。この累積欠陥数が数学モデルの曲線に正しく乗るためには、横軸に指定した単位間で同じテスト密度になるように、単位を設定することが理想である。しかし現実には難しく、横軸としてテスト日数やテスト消化率、テスト工数を取ることが多い。したがって予測の解釈には注意が必要である」と書かれている。

「・・・理想である。しかし現実には難しく、・・・したがって予測の解釈には注意が必要である」という記述は、本書が信頼度成長モデルを「簡便に使えるツール」もしくは「精緻にデータを評価できるツール」とは考えていないことを表しているのではないだろうか。

しかし、一方で、P59「(4)工程終了判断」において「あらかじめ設計したテスト項目を全て実施しても95%に到達しないときは、95%に達するまで追加テストを実施すべきである」とある。

信頼度成長曲線は、予測の解釈には注意が必要であるが、95%という5%の精度で品質で見ることができるツールであると本書は言っている。

人間の活動を5%単位で管理できるのはすばらしい精度であるといえる。

2008年12月11日 (木)

【定量的品質予測のススメ】±3σで管理限界を定めることができるとき、できないとき

P63「3.2.4 適用上の注意点」の「(2)プロジェクトにふさわしい管理限界を設定」において「測定した値を統計処理して決定する」とあっさりかかれている。

これまで、管理限界の話になると、大抵±3σの話が繰り返し出てきた(P27、P43、P49)が、ここでは触れられていない。
それだけではなく、±3σを否定するP20「コラム モデル化時の注意点」を参照するように誘導さえしている(本書では誤植で「モデル化するときの注意点」参照となっているが該当しそうなコラムは「モデル化時の注意点」しかないのでこれを指すとみなす)。

さて、本書は、ここまでさんざん±3σで管理せよと書いてきたのに、この場合では±3σに慎重になれと書かれているのはどういうことを意味するのであろうか。

どのようなときに±3σで管理限界を定めることができて、どのようなときにだめなのか。

さあこれから定量的品質予測をはじめ用という組織の担当者が、入門書と思い本書を取り、通して読んだ際に記述の一貫性に違和感を覚えることになってしまうのではないか。

2008年12月10日 (水)

【定量的品質予測のススメ】いわゆるデバッグで見つかった欠陥は常にカウントしないか

P60「3.2.3 方法(項目、手法)(1)基本測定量(c)欠陥数」において「作成者のセルフ・チェック(いわゆるデバッグ)で見つかった欠陥はカウントしない」とある。

ここでいうセルフチェック(いわゆるデバッグ)が許されるタイミングは、テスト工程にプログラムを渡す前、未だプログラムの管理主体が作成者にある場合のみである。
こう書くと、そのようなことは自明ではないか。一旦作成者の手を離れたら、もはやそれは例えテスト前に作成者により発見されてもいずれテストで発見されるのであるから、欠陥とすべきであると批判されそうである。

しかし、本当にそうであろうか。

後続のテストケースでは見つけられない欠陥を、例えばシステムテスト工程のタイミングで、作成者が見つけた場合、どう扱うのであろうか。

タイミングはシステムテスト。しかし、それまでのテストでも、これからのシステムテストの計画においても、その部分のテストは行われない場合は、ありえるのではないか。

本書のスタンスでは、どうするのでしょう。

本書のスタンスでは、「カウントしない」が正解であると思うがいかがだろう。

2008年12月 9日 (火)

【定量的品質予測のススメ】定量的品質予測を行う際のテスト項目数の考え方

P60「3.2.3 方法(項目、手法)(1)基本測定量(b)テスト項目数」において、テスト項目を設計するにあたり「テスト項目とテスト対象部分の対応を明確にし、テスト部分の重複や漏れをなくすことで、最低限のテスト項目数でより多くの部分を網羅するテスト項目を作成する」とある。
平易な文章であるが、内容は難しい。

「テスト項目数」に対する考え方を整理する必要がある。

「テスト項目数」を統計的に処理することが目的であるのであれば、「テスト項目数」は、できる限り、互いに独立でありながら同じ重みを持つように設計されなければならない。

つまり、

互いに独立 : あるテスト項目において欠陥が発生する場合に、まったく同じプログラムのまったく同じ場所、まったく同じ原因で別なテスト項目においても必ず欠陥が発生するというようなテスト項目を避けること。ただし、プログラムの構造上等の理由でやむをえない場合は、定量的品質予測においてはこのような欠陥は重複して計上せず1件として挙げる。

同じ重み : 複数のテスト項目のいずれもが、同程度の割合で今回のテスト対象全体の品質を確認することに貢献すること。例えば、「画面Aのボタンが全て正常に稼動することを確認する」と「画面Bの送信ボタンを押下した場合に、本文欄に記入された内容を宛先に指定されたアドレスへ送付する」というテスト項目は同じ重みを有しないと考えること。ただし、実際のテスト項目策定においては、このように単純ではなく、オンライン処理とバッチ処理、日廻してストやレグレッションテスト(改定に伴い既存機能が悪影響を受けていないかのテスト)の件数をどう取り扱うか等に関し、考えなければならない。

2008年12月 8日 (月)

【定量的品質予測のススメ】LOCとFP

P60「3.2.3 方法(項目、手法)(1)基本測定量」として「テスト系のプロダクト品質予測時に使用する基本測定量について説明する」とあり、「(a)規模」において「全体的な傾向を把握するには、LOCでもFPでも大差ないが、品質不良個所を絞り込むにはLOCの方が向いている」と書かれている。

FP信奉者が聞いたら怒り出しそうな記述である。

何を根拠にこのようなことを言うのであろうか。

昔ながらの古き良き開発――全てのソースコードは人手で書かれ、画面さえも右からいくつ左からいくつと一行一行手で書かれる。
そんなソースコードならば、LOCも使えるかもしれない。

画面などGUIでパパッと作って保存すればソースに展開。変更も簡単。
内部ロジックも、自動生成ツールにパラメータを与えればほとんどできてしまったり。GUIが充実した開発環境で。

これで本当に「品質不良個所を絞り込むにはLOCの方が向いている」といえるのであろうか。

手で書いたLOCとツールで作成されたLOCを同じとは扱えまい。

これは、本書でも意識されており、「自動生成行」と「GUIツール」についてはP61で触れられている。

P61で「ソースコードの物理的な行数(半自動生成行で手を加えた行も含む)から、コメント行・空白行・自動生成行を減じたものを、論理ステップとみなしても実用上大きな違いは出てこない」と書かれている。

良く分からないが「自動生成行」から「論理ステップとみなしても実用上大きな違いは出てこない」と言い切っている。
しかし、「自動生成行を減じたもの」を「テスト系のプロダクト品質予測時に使用する基本測定量」としてよいのであろうか。
評価する際に、自動生成行部分のテストケースは一切しなくても良いのであろうか。
中には全て自動生成されるプログラムもあろうが、これはテストしなくて良い、もしくはテストをしてもその部分のプログラム規模はないと言うことであろうか。理解が難しい。

また、同じくP61で「GUIツール等で作成した成果物の量はLOCとは別に扱うことが多い」と書かれている。
「自動生成行」を含むプログラムは「GUIツール等で作成した成果物」と異なり「別に扱うことが多い」と書かれていないのはなぜなのだろうか。

それはおいても、ここでいう「GUIツール等で作成した成果物の量はLOCとは別に扱うことが多い」とはどういうことであろうか。
「他のプログラムとは別に扱うことが多い」ではなく「LOCとは別に扱うことが多い」というのだ。

P60で「全体的な傾向を把握するには、LOCでもFPでも大差ないが、品質不良個所を絞り込むにはLOCの方が向いている」という記述を思い出すと良い。

「GUIツール等で作成した成果物の量」はLOCではお手上げと言っているのだが、FPならどうか。
まだましに使えるのではないか。

ならばなぜ「LOCとは別に扱うことが多い」などと回りくどく書くのであろう。
別に扱うならそれで構わない。では、どう別に扱うのか書かなければならない。

その別の扱いの最有力候補がFPだから書けないのだろうか。
なぜそこまでLOCを信奉するのであろうか。

信奉するならするで「全体的な傾向を把握するには、LOCでもFPでも大差ないが、品質不良個所を絞り込むにはLOCの方が向いている」ということを言い放っておきながら弱点は逃げて終わるのではなくて、理由を説明するべきである。

P60「全体的な傾向を把握するには、LOCでもFPでも大差ないが、品質不良個所を絞り込むにはLOCの方が向いている」という記述は、この書籍が、もしくは少なくともこの部分が、昔ながらの古き良き開発をイメージして書かれていることを図らずも表しているのではないだろうか。

2008年12月 5日 (金)

【定量的品質予測のススメ】「グラフに乗るようにテストを行う」という理想を追いすぎることの弊害

P60「(b)総合的な判断終了」において「累積欠陥件数が、テスト開始と同時に出始め、テストの後半では新たな欠陥が発生せず、平らな曲線になっており、未解決欠陥数が0件のグラフが理想的である」とある。

理想的なグラフになってしまった場合、だれかの恣意が働いていないかを疑ってみるのも逆に必要である。
グラフに合わせる開発者が出てこないと言う保証はないのだから、無邪気にグラフに乗ったと喜ぶのは早計である。

「グラフに乗るようにテストを行う」という理想を追いすぎることも、弊害が出る可能性があることを気に留めておくことも必要である。

2008年12月 4日 (木)

【定量的品質予測のススメ】信頼度成長モデルは、何の推移をみるものか

P59「(b)総合的な判断終了」において「信頼度成長モデルに加えて、残テスト項目数や、累積欠陥件数、及び未解決欠陥件数等を総合的に判断して評価する必要がある」とある。

さて、「信頼度成長モデルに加えて」とあるのであるから、その後の列挙は「信頼度成長モデル」と組み合わせるものである。
つまり、
  ①信頼度成長モデルと残テスト項目数
  ②信頼度成長モデルと累積欠陥件数
  ③信頼度成長モデルと未解決欠陥件数
というわけだ。

そして②に注目してみる。

信頼度成長モデルは、何の推移をみるものであったであろうか。
信頼度成長モデルは、累積欠陥件数の推移をみるものである。

では、「②信頼度成長モデルと累積欠陥件数」とは何をみるものなのであろうか。
単に勇み足であろう。②は外して考えてよい。

2008年12月 3日 (水)

【定量的品質予測のススメ】信頼度成長モデル活用法あれこれ

P59「(4)工程終了判断」において「プロジェクトの全体の信頼度成長モデルと、各サブシステムの信頼度成長モデルを1つのグラフに重ね合わせ、プロジェクト全体が95%に達する時期より遅く95%に達するサブシステムを発見し、てこ入れすると言う利用方法がある」とある。

「プロジェクト全体が95%に達する時期より早く95%に達するサブシステム」についての言及はないが、これはどう評価するのであろうか。

言及がないのであるから、これは健全であるとみなすのであろう。
しかし、「プロジェクト全体の障害件数が95%に達する時期より早く障害件数が95%に達するサブシステム」が本当に健全なのだろうか。

システムテストの開始直後に障害がものすごい勢いで発生するサブシステムがあったとする。
システムテストの中盤で既に95%を超えた場合にも、てこ入れはいらないのであろうか。

また、サブシステムごとにかなり特殊な業務もしくは処理を行うプロジェクトであったとする。
これらの値の合算値と個々のサブシステムの値を比べて多い少ないを論じる意味は何であろう。

P11「2.2.1 測定単位(品質管理単位)」では「測定単位を細かくして品質データ(欠陥数等)を測定することにより、詳細な品質管理、分析を行うことができる」と書かれている。

これを考えれば、「プロジェクトの全体の信頼度成長モデルと、各サブシステムの信頼度成長モデルを1つのグラフに重ね合わせ、プロジェクト全体が95%に達する時期より遅く95%に達するサブシステム」があっても、それはそのサブシステムにとっては詳細な値であるというだけではないのだろうか。

同じページに「テストに極端な偏りがないことや、テストの網羅性が十分確保されている等々注意すべきことがあり、信頼度成長モデルだけでテストの終了を判断するのは不充分である」と書かれている。

本書は信頼度成長曲線を有効と考えているのであろうか。

ちなみに「テストに極端な偏りがないことや、テストの網羅性が十分確保されている等々注意すべきことがあり」とさらりと書かれているが、ここが信頼度成長モデルの肝であろう。

しかし、これを満たすようなテストとはどのようなテストなのだろうか。

2008年12月 2日 (火)

【定量的品質予測のススメ】信頼度成長曲線の前提

P59「(4)工程終了判断」において「あらかじめ設計したテスト項目を全て実施しても95%に到達しないときは、95%に達するまで追加テストを実施すべきである」とある。

信頼度成長曲線をここまで信頼することはすばらしいことである。
当初、90%であったので追加テストを実施したら、最初の曲線対比105%の欠陥が出てしまったとしよう。

この場合、どうするのであろうか。

本書には書かれていない。

あらかじめ設計したテスト項目と追加テストの結果を合わせて再度曲線を見直すのであろう。
予測に基づいて追加テストを行ったら、先の予測と異なる結果になったので再度見直す。
これを行き当たりばったりとはいわないのであろうか。
定量的品質予測とは行き当たりばったりのことなのだろうか。

これは何を意味するのであろうか。

信頼度成長曲線の前提を忘れてはならない。
欠陥がテスト対象に対して均一にばらまかれていることが仮定されている。

だから、テストを繰り返すうちに段々と欠陥が消しこまれて行き、新しい欠陥がなかなか見つからなくなるというのである。
逆からみると、テスト項目の実施順番をどのように変えても常に曲線が寝てくると言うことが前提になっている。

しかし、通常のテストはそのようになっているであろうか。
新機能をまず確認して、障害ケースを確認して、日廻しをして、とやっていたら、素直に寝てくれるわけがない。

未だにテストは「全パターン行っています」という組織には、追加テストがどういうことかさえ理解できないであろう。
「追加テストって、既に実施したテストをもう一度行うのですか。それは何の意味があるのですか」と聞かれるのではないだろうか。

信頼度成長曲線を使うテスト管理はどういうもので、そのときの注意事項は何か程度は書かないと、入門書としては良くないと思われる。

2008年12月 1日 (月)

【定量的品質予測のススメ】良いテスト項目とは重大な欠陥を検出できる確率が高いものであることのみか

P53「3.2.2 アプローチ」「(1)テスト実施」において、テスト実施時の留意点の1つとして、
    「良いテスト項目とは、重大な欠陥を検出できる確率が高いものである」
が挙げられている。

これは、テストに対する考え方の話であるが、「良いテスト項目は、実際運用された際の問題発生可能性を低くするもの」という考え方もある。

前者は、テストを「プログラムの欠陥を洗い出すもの」として捉え、後者は「プログラムの品質を一定程度保証するもの」として捉えている。

どちらの視点も必要であると考えることが普通であると思えるが、本書では前者のみが強調されている。
ここでは「普通であると思える」と書いたが、なぜかテストに関して「プログラムの欠陥を洗い出すもの」派と「プログラムの品質を一定程度保証するもの」派に分けて自分はどっちだという人を見かける。
こだわるものはそれぞれ信念があるのであろうが、特にこだわりをもたず両者の視点でテストを考えることは悪いことではないと考える。

再度本書の記述に戻ると、「良いテスト項目とは、重大な欠陥を検出できる確率が高いものである」というのは、「テストをプログラムの欠陥を洗い出すもの」として捉えるのみならず、「重大な欠陥」にのみターゲットを絞っている。
これは、「良いテスト項目とは、(軽微な欠陥を検出することには重きをおかず)重大な欠陥を検出できる確率が高いものである」という意味と取れるが、そうなのであろうか。

ではなぜ信頼度成長曲線など奨めるのか。
信頼度成長曲線でいう欠陥数に重大か否かの判別は通常入っていない。
単純に発見された欠陥数を数えていくだけだ。

それとも本書で考える信頼度成長曲線に挙げる欠陥とは重大な欠陥のみをさすのか。
しかし信頼度成長曲線で収束するほど重大欠陥が見つかるようなソフトウェア開発は途中でテストを止めて設計から見直したほうが良いのではないか。

やはり「良いテスト項目」として「重大な欠陥を検出できる確率が高いものである」だけを挙げるのは無理がある。

さて、P53「3.2.2 アプローチ」「(1)テスト実施」では、更にテスト実施時の留意点の1つとして、別に、
    「テスト実施に際して、人的や時間的な制約があるため、効率的/効果的に実施する必要がある」
というものも挙げられている。

言っていることが間違っているわけではない。

しかしこれは「テスト実施時固有」の留意点なのであろうか。

レビューについては当てはまらないか。
プログラミングには?要求分析には?設計には?

それ以前に「プロジェクト実施に際して、人的や時間的な制約があるため、効率的/効果的に実施する必要がある」ということが成り立つのではないか。

なぜならプロジェクトマネジメントの管理項目の中には人的や時間的な管理を含むのであるから。

テスト実施時の留意点として、わざわざ「テスト実施に際して、人的や時間的な制約があるため、効率的/効果的に実施する必要がある」を挙げる必然性は何であったのだろうか。

普通の人にとっては、ソフトウェア開発において「人的や時間的な制約がないので、効率的/効果的に実施する必要がない」場合を例示しないと、なぜ「テスト実施時の」留意点なのか分からないと思われる。

« 2008年11月 | トップページ | 2009年1月 »