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年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桁の精度での欠陥件数の管理・・・確かにそれができる組織であれば定量的品質予測も可能であろう。

より以前の記事一覧