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            
無料ブログはココログ

« 2009年2月 | トップページ | 2009年4月 »

2009年3月

2009年3月20日 (金)

【ソフトウェア信頼度成長モデルを少しまじめに考える⑥】1つ目の仮定:J-M(Jelinski-Moranda)モデルの仮定③

以上から、
  2.故障はランダムに起こる--故障間隔は独立である。
  3.全ての欠陥は故障発生に等しく寄与する。
の2つは、特に満足することが難しい仮定であることがわかる。

そして、達成が絶望的に難しい仮定でありながら、この2つは、曲線がモデル通りに寝ていくための必須条件であるのである。

J-M(Jelinski-Moranda)モデルの5つの仮定を満たせば、モデルに従った綺麗なカーブを描きますよといわれても、開発現場において、では全部満たした上で採用しようかとはなかなか言えないと思う。

尚、書籍「ソフトウェア品質工学の尺度とモデル」に挙げられているが、上の5つの条件のうち、3.の制約を克服するためにLittlewoodのモデルが、Goel-Okumotoの不完全デバッキングモデルが4.,5.を改善しようとして提示されている。
ただ、プログラム中の欠陥のばらつきや数については、統計技術で収束できるかもしれないが、テスト工数・テスト時間というものは「テスト実施者個々の能力」「テスト実施者のやる気」により、同じことを同じレベルで実施するにしても大きなばらつきがあるように思えるので、ここの部分を統計的に収束させることは難しいのではないかと考える。

2009年3月18日 (水)

【ソフトウェア信頼度成長モデルを少しまじめに考える⑤】1つ目の仮定:J-M(Jelinski-Moranda)モデルの仮定②

3.全ての欠陥は故障発生に等しく寄与する。

これも実際問題難しいであろう。
かなり細かい条件を満たさないと故障が発生しないバグと、プログラム実行の入り口で発生してしまうバグとでは、故障発生の寄与は異なるであろう。
この仮定は、ある程度複雑なプログラムでは満足することは困難であろう。
実用に供することができるプログラムの場合、まず満足することは無いのではないかと考える。

4.修正時間は無視できる。

まあ、これは、理論上はそのように運用すればよいので、可能ではある。
バグが発生した都度、テストを中止してプログラムを直せばよいのであるから。
実際の開発現場でこれを満たすようにテストを行うのは困難ではあろうが。

5.各故障に対する修正は完全であり、欠陥修正中に新しい欠陥は混入しない。
まあ、これも、実際には発生するであろう欠陥修正中に混入した新しい欠陥の数及びそれにより影響を受けたテスト時間、もしくは工数等横軸にとった数量を考慮することとすれば可能ではある。

2009年3月16日 (月)

【ソフトウェア信頼度成長モデルを少しまじめに考える④】1つ目の仮定:J-M(Jelinski-Moranda)モデルの仮定①

先に挙げた書籍「ソフトウェア品質工学の尺度とモデル」には、ソフトウェア信頼度成長モデルのモデルの仮定を2組紹介している。
この2組の仮定のうちどちらかを十分に満たすような実際の開発案件があれば、ソフトウェア信頼度成長モデルを上手く導入できるであろう。

---------------------------------------------------------------------------
J-M(Jelinski-Moranda)モデルの仮定

1.テスト開始時点で未知のN個のソフトウェアの欠陥が存在する。
2.故障はランダムに起こる--故障間隔は独立である。
3.全ての欠陥は故障発生に等しく寄与する。
4.修正時間は無視できる。
5.各故障に対する修正は完全であり、欠陥修正中に新しい欠陥は混入しない。

---------------------------------------------------------------------------
なかなか、クリアすることが難しそうな仮定である。

1.は、まあ、そう仮定すればよいのであろうから満たすと言ってよいであろう。

2.は、つまり、テストケースの実施順に関わらず、同じテスト対象プログラムであれば、理論上は同じ形の曲線になることを意味する。
実際の開発現場でこれを実現することは少し難しい。
「ソフトウェア品質工学の尺度とモデル」でも触れられているが、あるバグが見つかったら類似バグが無いかをテストすることや、バグが多く見つかったプログラムに対し集中的にテストすることは通常の開発においてはよく行われる。
しかし、これは「故障はランダムに起こる--故障間隔は独立である」に反する可能性が高い。
また、重要な機能や複雑な機能などを先に集中的にテストすることも行われるが、これも。故障間隔の独立性に反する結果となる可能性がある。

テストケースの実施順に関わらず、同じテスト対象プログラムであれば、理論上は同じ形の曲線になることを満たすテストは限られてくる。
テストケースの挙げ方・実施順に恣意性があると、条件を満たすことが困難になるし、プログラムの新機能におけるバグと、性能上の問題、従来機能のデグレードによるバグが、ランダムに起こるようにテストすることは難しいであろう。新機能確認テストと、性能テスト、レグレッションテストは、通常、それぞれをフェーズに分けて実施されることが多いからである。

「2.故障はランダムに起こる--故障間隔は独立である」を満たすには、そもそも本質的にそれを満たすようなテストであるか、もしくはそれを満たすように注意深く設計されたテストをする必要がある。
これは、テストケースに「ここの部分は怪しいから最初に深めにテストしよう」とか「ここにバグが見つかったからちょっと重点的にテストしよう」といったテスト実施順番の恣意性が無いことを要求しているのである。
「2.故障はランダムに起こる--故障間隔は独立である」は、テスト実施順番に関わらず、同じ曲線になることを言っているのである。
リスクベースのテストとは両立しないと思われる。

 ・そもそも本質的にそれを満たすようなテスト
    プログラムの個々の機能には着目せず、業務面に着目して設計されたテストがこれに当てはまるであろう。
    具体的には、実際にはそのプログラムが使用法に準じた使われるのと同じ方法で

    たとえば、プログラムが対象とする業務について1日を通しての業務処理を何日分も廻すテストやカーナビソフトのテストで実際に車に積んで色々な場所を何時間も走って行うテストがこれに該当しよう。
    しかし、「そもそも本質的にそれを満たすようなテスト」というものは、あまり実施されることが無いのではないだろうか。
    そもそも業務処理の日廻しやカーナビの実走の段階で曲線が立ちあがって後に寝ることがグラフで分かるようなプログラムはそれまでのテストで何やっていたんだという危険なプログラムであろう。

    モジュールテスト、結合テスト、初期のシステムテストでそもそも本質的に「2.故障はランダムに起こる--故障間隔は独立である」を満たすテストとはどのようなテストなのであろうか。解があれば教えてほしい課題である。

 ・それを満たすように注意深く設計されたテスト
    テストケースの一覧から乱数等を使ってランダムにテストの実施順を決定してテストすることで、機能のまとまり毎にテストすることによる故障発生可能性の偏りを回避しようとするようなテストがこれに該当するかもしれない。

    自動化されたテストツールで行うテストであれば単に実施順を入れ替えるだけで対応は楽だが、人手でのテストであれば、テスト実施者にとってはなかなか嫌なテストであろう。
機能のまとまり毎にテストすることは、類似操作が並んでいることが多く、テスト実施に習熟しやすいが、都度、違う部分のテストを行うのは、設定等の準備も都度発生するであろうし、操作も一々再確認しなければならないであろうからテストに集中するのが大変であると予想される。

    但し、一定程度の自動化が進んだテストであればこれは可能であるので、その場合は「2.故障はランダムに起こる--故障間隔は独立である」ようにテストを実施することは可能である。

2009年3月13日 (金)

【ソフトウェア信頼度成長モデルを少しまじめに考える③】直感的理解容易性のために忘れられがちであるが悩ましい前提③

○応用に際しては、基礎となる仮定が満足されているとき、モデルはより効力を発揮し、逆も成り立つ。言い換えると、仮定が妥当なものであればあるほどモデルはより役に立つものとなる

=>ソフトウェア信頼度成長モデルの有効性に付いて、
     モデルはより効力を発揮し
     モデルはより役に立つ
   程度にしか書かれていないのであって、
     モデルの精度は高くなる
   とは言っていない。
   なぜ「精度」という語を使わないのであろうか。
   そもそもソフトウェア信頼度成長モデルは、「精度」云々を論ずるレベルのものではないと著者が考えているからなのではないだろうか。

「応用に際しては、基礎となる仮定が満足されているとき、モデルはより効力を発揮し」
に対して、逆も成り立つとわざわざ言っていることからもそれが推測される。

「応用に際しては、基礎となる仮定が満足されているとき、モデルはより効力を発揮し」
「仮定が妥当なものであればあるほどモデルはより役に立つものとなる」
を、逆にすると、
「応用に際しては、基礎となる仮定が満足されてないとき、モデルはより効力を発揮できない」
「仮定が妥当なものでないほどモデルはより役に立たなくなる」
となる。

ソフトウェア信頼度成長モデルが自己の0ソフトウェア開発においてどの程度満足できるかは、その仮定を見ていけばよい。
実際の開発現場で仮定を十分に満たすようなモデルを探すことが、ソフトウェア信頼度成長モデル導入の成功の秘訣ということになる。

2009年3月11日 (水)

【ソフトウェア信頼度成長モデルを少しまじめに考える②】直感的理解容易性のために忘れられがちであるが悩ましい前提②

○モデル化する物理プロセス(ソフトウェア故障現象)に高い精度を殆ど期待できないので、モデルの開発にあたっては仮定を曖昧でない形で明らかにする必要がある

=>最初の文と実質的に同じことを言っている。
   繰り返すということは、重要であるという意味であるし、言葉は過激になっている。
   「物理プロセス(ソフトウェア故障現象)に高い精度を殆ど期待できない」ということは、高い精度を期待できないなりに、なんとか管理しようということである。
つまり、仮定を曖昧なままとしたら、管理できるようなものではないと捉えてよいと考える。

ソフトウェア信頼度成長モデルにおいて、「ソフトウェア品質工学の尺度とモデル」の著者は「物理プロセス(ソフトウェア故障現象)に高い精度を殆ど期待できない」と言い切っている。

高い精度を殆ど期待できないものを、高い精度で表そうと言うことは考えられないと帰着できよう。
故に、ソフトウェア信頼度成長モデルは、高い精度で管理する類のものではないということを実戦で活用する際は肝に銘ずるべきである。

しかし、実際の活用においては、様々な曲線を表すモデルが考案され、管理描画ツールも種々ある。そして、これを使えば、手っ取り早く「高い精度」で管理できると考えてしまいがちである。

モデルが洗練されることは、「前よりまし」になるだけの話で、それで「高い精度」となるわけではない。
低い精度が多少高くなるだけと考えた方が良い。
なぜなら、取り扱う元の現象である物理プロセス(ソフトウェア故障現象)に、そもそも高い精度を殆ど期待できないのであるから、
それをどんなに洗練された方法で取り扱っても「高い精度」にはならない。
全くでたらめではなく、多少傾向が出る、辛うじて管理できるようにするために、仮定を曖昧でない形で明らかにできるモデルが必要なのである。
高い精度で管理できるようにするために、仮定を曖昧でない形で明らかにできるモデルが必要だと考えるべきではない。

あくまで、個人的な考えであるが、取り組みやすいし誰にも直感的にわかりやすいからと、ソフトウェア信頼度成長モデル1本にテストの止め時判定の責任を押し付けることは勧められない。
統計的な処理結果にも関わらずブレを表現しない曲線1本で表すソフトウェア信頼度成長モデルは、「複雑な現実」の開発現場において主役にはなり得ない。あくまで脇役として使うべきである。

2009年3月 9日 (月)

【ソフトウェア信頼度成長モデルを少しまじめに考える①】直感的理解容易性のために忘れられがちであるが悩ましい前提①

直感的な理解が容易であるために忘れられがちであるが、ソフトウェア信頼度成長モデルの悩ましい前提について詳しく考えておきたい。

考察のベースとして、
   Stephen H. Kan 著 古山恒夫・富野壽 監訳
     「ソフトウェア品質工学の尺度とモデル」(2004, 共立出版株式会社)
を用いる。
本書の「第8章 指数分布と信頼度成長モデル」にソフトウェア信頼度成長モデルについて述べられている。
そして「8.3 モデルの仮定」において、次の記述がある。

「信頼性のモデル化は、複雑な現実を正確な統計の言葉でまとめるための1つの試みである。モデル化する物理プロセス(ソフトウェア故障現象)に高い精度を殆ど期待できないので、モデルの開発にあたっては仮定を曖昧でない形で明らかにする必要がある。応用に際しては、基礎となる家庭が満足されているとき、モデルはより効力を発揮し、逆も成り立つ。言い換えると、仮定が妥当なものであればあるほどモデルはより役に立つものとなる」

この引用部分は、ソフトウェア信頼度成長モデルの適用を考える上での課題を簡潔に言い表していると考える。

○信頼性のモデル化は、複雑な現実を正確な統計の言葉でまとめるための1つの試みである

=>ソフトウェア信頼度成長モデルが対象とするものは、本来的に「複雑な現実」なのである。これを忘れてはならない。
  曲線1本で表されて、あたかもその線の指す方向が従うべき道に見えてしまうが、誤りである。
  ソフトウェア信頼度成長モデルから導き出される曲線は、統計的に引かれた線にすぎず、個々の「複雑な現実」によってブレることは、異例なことではないのである。

また、曲線の算出式自体が、ソフトウェア開発プロセスの論理的帰結から導き出されているのではなく、経験的に曲線は寝るはずであるからどうやって実際の計測値に合う式を見つけるか…から来ているので、そこから導き出される曲線1本にどの程度の管理が可能であるかを予め考えておくべきである。

実際の開発現場において、ソフトウェア信頼度成長モデルで表される曲線1本に、「複雑な現実」のどの程度を表現させることができるかを、自らの開発プロセスや過去の実績を省みて予め考えておく必要がある。

2009年3月 6日 (金)

【ソフトウェア信頼度成長モデルを考える⑤】グラフが寝るとはどういうことか②

簡単な仮想事例で考えてみる。
ソフトウェア信頼度成長モデルを用いてテスト十分性を見ようという場合に、新機能確認Aを2000件行った後、新機能確認Bを2000件、レグレッションテストを5000件行ったところ、綺麗に曲線が寝たという場合に喜んで良いのか。

次の3つの順番で行っても、同様に寝るのか。

①新機能確認Bを2000件行った後、新機能確認Aを2000件、レグレッションテストを5000件行う
=>これはまあ、寝方は変わるだろうが寝る可能性が高いのではないか。

②レグレッションテストを5000件行った後,新機能確認Aを2000件、新機能確認Bを2000件行う
=>モデルが想定するような綺麗な形には寝ないだろう。

③新機能確認Aを1000件行った後、新機能確認Bを1000件、レグレッションテストを5000件行う
=>これもまあ、寝方は変わるだろうが寝る可能性が高いのではないか。

ある程度のケース数のレグレッションテストを最後に持ってくれば、新機能確認のケース数の多少に関係無く一般的に曲線は寝ることが多い。

つまり、先ほどの例で言えば、

   ・最初から寝ることが分かっているレグレッションテスト
の前に、
   ・通常寝ない新機能確認A、B

を持ってくれば、実際のソフトウェア内のバグの残存に関わらず「最初から寝る」可能性が非常に高い。
これを以って、「ソフトウェア信頼度」が成長したとか言うのは全くナンセンスである

このようなことは、わざわざ例示までしなくとも、誰にも理解できるであろう。

しかし、頭で理解できてもこれを考慮してテストを実施することは、非常に難しい。
通常、実際のテストにおいては、テストの実施順番は、機能・重要度・リスク等によってグルーピングしており、
    バグがテストケース全体にわたって同じ発生確率でばらまかれていること
という前提が、十分仮定として成り立つようなテストの方が少ないであろう。

ソフトウェア信頼度成長モデルの前提については、別途詳しく考えることとする。

2009年3月 4日 (水)

【ソフトウェア信頼度成長モデルを考える④】グラフが寝るとはどういうことか①

グラフが寝るとはどういうことなのだろうか。
テストを実施するにつれてバグが見つかりにくくなるから寝るという考え方は、直感的には理解できる。
故に手を出しやすいのであるが、何故寝るのかについては、直感ではなく、理論的に考える必要がある。

その上で、自分たちの開発において、グラフが論理的に寝ることの必然性が確認できれば採用すべきであるし、そうでなければグラフがきれいに描かれるからといって採用するべきではなかろう。

なぜ寝るのか。
①バグがテストケース全体にわたって同じ発生確率でばらまかれていること
が大前提である。
また、
②テストケースは、基本的に、特定の1機能のみに絞った確認を行うのではなく、1ケースで複数の機能の確認ができ、かつ、各機能は複数のテストケースで発見される可能性を有していること
が前提となる。

①の前提がなく、テストケースのある一群を実施している段階ではバグがほとんど出ず、別な一群で大量に出るようでは、実施順によってグラフの傾きが変わってしまう。
同じソフトウェアに対して、テストの実施順によって傾きや寝方が変わるというのは、モデルとして不適当であるということは理解できよう。
故に、①の前提が意味することは、ソフトウェア信頼度成長モデルにおいては、テスト順によらずグラフは同じ形で収束する、つまり寝ることが理論的前提となっているということである。

また、②の前提がなく、それぞれのテストケースで発見されるバグは他のテストケースでは見つからないようであると、こちらも実施する順番によって、グラフが寝たり立ったりする可能性が出てくる。

このように、信頼度成長モデルには、「テストケースの挙げ方」「テストの実施順」についての前提がある。
この前提があるからこそ、曲線が寝るということがソフトウェアの信頼度が上がることと結びつくのである。

そしてまた、この「テストケースの挙げ方」「テストの実施順」という前提故に、ソフトウェア信頼度成長モデルは直感的には容易に理解できるにも関わらず、実際活用してみると色々悩みが出てくる。既に挙げた「テストサイクルを通じて寝るように計画されている」や「同じテストを何ショットか繰り返すから寝るように計画されている」という、定量的把握とは言い難い活用法も出てくるのである。

2009年3月 2日 (月)

【ソフトウェア信頼度成長モデルを考える③】現場における様々な言い方、使われ方(3)

2.曲線の意味

(1)テストを実施するにつれてバグが見つかりにくくなるから寝るという考え方
  一般的な考え方。但しこれも、深く考えると難しい問題に直面するがそれは別途述べる。

(2)そもそも寝るように計画されたテストであるという考え方

 (ア)テストサイクルを通じて寝るように計画されているという考え方

   例えば、既存のシステムに大規模な改定を行った場合のシステムテストにおいて、
     ①まず新しい機能およびその影響を受ける部分を確認する
     ②次に非機能要件を確認する
     ③最後に既存部分は無影響であることを確認する
   まあ、直感的には③は①と②に比べバグが出ることも少ないであろうことは理解できる。
   しかし、これを言ってしまうと①②をどんなにいいかげんに行っても③を行ったら寝始める。
   だから、確かにグラフは誰もがイメージする形になるが、これから何が分かるのかというと、何も分からないのではないか。

   馬鹿げていると言う方も多いであろうが、信頼度成長モデルをこのように理解している人もいる。
   また、上記のように書くとばかげていると言う方でも、実際のテストでは、無意識のうちに、
       新しい機能およびその影響を受ける部分、非機能要件、既存部分の無影響確認
   の順にテストして、結果をプロットして寝た寝たと言っているなら結果的にこの考えで捉えていることになる。

   尚、だから、
       新しい機能およびその影響を受ける部分、非機能要件、既存部分の無影響確認
   の順番でのテストが意味が無いというものではない。
   この順番でテストすることの合理性は、リスクベースという面からも理解できる。
   但し、この順番でテストした結果をわざわざ信頼度成長モデルに当てはめることに意味が無いのではないかというだけである。

   
 (イ)同じテストを何ショットか繰り返すから寝るように計画されているという考え方
   まず、1ショットテストケースをこなす。バグを潰して1回目と同じテストケースをもう1ショット行う。バグが出たら繰り返す。
   で、バグ修正によるデグレードが収まったところでカーブは寝るはずだという理屈。
   これも、この結果をわざわざ信頼度成長モデルに当てはめることに意味が無いのではないかというだけである。

  ちなみに、(ア)も(イ)もコンサルタントとして金を取っている人から聞いたことがある。
  現場において信頼度成長モデルを適用するにあたっての説明の難しさが伺える。

« 2009年2月 | トップページ | 2009年4月 »