ソフトウェアの出荷判定に信頼度成長曲線を使用している場合、「○%以上なら出荷を認める」という判定基準を書いた物はどこかにありますでしょうか?

回答の条件
  • URL必須
  • 1人2回まで
  • 登録:2010/03/19 16:29:39
  • 終了:2010/03/22 09:55:44

ベストアンサー

id:ttakao No.2

RON回答回数276ベストアンサー獲得回数312010/03/20 08:23:20

ポイント36pt

残念ながら製品出荷で、そんな出し方をしているところはないと思います。

建前上は、重大障害0、出荷までに修正完了2件以下、システムテストをオールパス、などと決めるのが普通じゃないですか?信頼度成長曲線で大丈夫でしょう、って考え方はヤバイと思います。

現実はプロマネの経験がモノをいうんじゃないでしょうかねぇ。大昔ですが、プロマネが「ヤバい」と考え、わざと重大障害を一件作って、出荷延期なんてこともしていましたから。

というのも、信頼度成長曲線ってプロットしているのが件数と経過時間ですよね。テストケースの網羅性、トラブルの深刻度、トラブルの多いコンポーネントといった考察がないので、私ならそんな曲線を示されても参考にはなれど、出荷の決断要素にはできないですね。

テスト方法論の団体のurl

http://jasst.jp/index.html

id:garyo

それがどことはいいませんが、かなりの大手さんが言ってくるんですよ。

最近では大体提出を求められますね。

あと、Jasstは以前、講演もしたことがありますのでよく知っています。

2010/03/20 10:35:49

その他の回答(3件)

id:ko8820 No.1

ko8820回答回数1221ベストアンサー獲得回数692010/03/19 17:28:21

ポイント36pt

http://stage.tksc.jaxa.jp/jxithp/seminar/files/wocs2009_keynote4...

契約時に決めるか、社内規定で決めるものだと思いますが・・・。

失礼ですが、、「○%以上なら出荷を認める」というのは根本的に

考え方が間違ってると思います。

1.収束してるかどうか?

2.バグは一定基準検出できたかどうか?

で、品質を決めるものだと思います。

id:garyo

>1.収束してるかどうか?

の判定をどうするかという話です。

○%と書いたのは、予想残バグ数、バグがすべて除去されている確率など色々な指標があるからです。

社内規定で収束率を決めた場合、その値に決めた理由の説明を求められたとき、どう答えるかという話です。(過去の実績に基づき等はなく何かソースが必要な場合と考えて下さい)

2010/03/19 17:40:08
id:ttakao No.2

RON回答回数276ベストアンサー獲得回数312010/03/20 08:23:20ここでベストアンサー

ポイント36pt

残念ながら製品出荷で、そんな出し方をしているところはないと思います。

建前上は、重大障害0、出荷までに修正完了2件以下、システムテストをオールパス、などと決めるのが普通じゃないですか?信頼度成長曲線で大丈夫でしょう、って考え方はヤバイと思います。

現実はプロマネの経験がモノをいうんじゃないでしょうかねぇ。大昔ですが、プロマネが「ヤバい」と考え、わざと重大障害を一件作って、出荷延期なんてこともしていましたから。

というのも、信頼度成長曲線ってプロットしているのが件数と経過時間ですよね。テストケースの網羅性、トラブルの深刻度、トラブルの多いコンポーネントといった考察がないので、私ならそんな曲線を示されても参考にはなれど、出荷の決断要素にはできないですね。

テスト方法論の団体のurl

http://jasst.jp/index.html

id:garyo

それがどことはいいませんが、かなりの大手さんが言ってくるんですよ。

最近では大体提出を求められますね。

あと、Jasstは以前、講演もしたことがありますのでよく知っています。

2010/03/20 10:35:49
id:IZI No.4

klogg回答回数42ベストアンサー獲得回数02010/03/21 19:36:41

出荷で、そんな出し方をしているところはないと思います。

建前上は、重大障害0、出荷までに修正完了2件以下、システムテストをオールパス、などと決めるのが普通じゃないですか?信頼度成長曲線で大丈夫でしょう、って考え方はヤバイと思います。

現実はプロマネの経験がモノをいうんじゃないでしょうかねぇ。大昔ですが、プロマネが「ヤバい」と考え、わざと重大障害を一件作って、出荷延期なんてこともしていましたから。

というのも、信頼度成長曲線ってプロットしているのが件数と経過時間ですよね。テストケースの網羅性、トラブルの深刻度、トラブルの多いコンポーネントといった考察がないので、私ならそんな曲線を示されても参考にはなれど、出荷の決断要素にはできないですね。

テスト方法論の団体のurl

http://jasst.jp/index.html

id:garyo

2番の回答の丸コピーですか。通報しておきますね。

ーーーーーーーーーーーーーーーーーーーーーーーー

この質問に関してですが、コメントにも書きましたが

独立行政法人 情報処理推進機構 IPA発行の「ESQR組込みソフトウェア向け品質作り込みガイド」 PDF版

http://sec.ipa.go.jp/publish/index.html#emb

に「不具合収束率」の定義と参考値が載っているとtwitterで教えてもらいました。

P102に確かに載っていました。こちらを参考にさせて頂きます。

2010/03/22 09:54:53
  • id:Km1967
    望みのようなものが、あればいいな。
    暇なときにでも見ておくと新しい発見ができるかもしれないサイトを載せておく。
    http://jasst.jp/
    http://jasst.jp/archives/jasst08e/pdf/A2-1.pdf
  • id:garyo
    P15の
    「収束の基準値については、各組織の品質実績を元に設定する」
    の具体的な数値があれば教えてください。
    通常は公開されることはないので、IPAあたりが何か書いていると嬉しいのですが。
  • id:Km1967
    事例なら下記のようにいくつかあるが判定基準なんてものは各社・各部門・対象によってまちまち。
    http://stage.tksc.jaxa.jp/jxithp/seminar/files/wocs2009_keynote4_ohta.pdf

    質問の趣旨は画一的なものを求めているのであろうからなぁ。そんなものがあればいいなってのが最初のコメントの意味。
  • id:garyo
    当然判定値は「過去の実績を元に設定」としか言えないわけだが、部長が客先からその値の根拠を求められて何か出せと、言われているわけ。
    どこかIPAあたりにあれば、それを参照していますと言えるのだが。
  • id:Km1967
    流石 パパ パトゥさんだ。コピペだよ。
    http://q.hatena.ne.jp/1268752645 と一緒。
  • id:taknt
    その質問と何が一緒なの?
  • id:Km1967
    行動パターン。
  • id:taknt
    収束してるかどうかとか、バグは一定基準検出できたかどうかとかは 普通なことじゃん。
    私も それで 決めたほうがいいと思うね。

  • id:garyo
    >収束してるかどうかとか、バグは一定基準検出できたかどうかとかは 普通なことじゃん。
    その「収束」をどう判定するかですよ。目で見て「収束しているね」というのであれば簡単なのですが、
    近似曲線(ロジスティック曲線やゴンペルツ曲線等々)を当てはめた場合、漸近線までの距離で収束度を判定するわけですが、どの値以上漸近線に近づいた場合「収束している」と見なすかという話です。
  • id:Km1967
    >私も それで 決めたほうがいいと思うね。
    決めるかどうかではなく「その基準をどうやって決めたのか?」をクライアントから訊かれて、答えに窮してるって状況だろ。

    >「過去の実績を元に設定」としか言えない
    そうだよな。

    >どの値以上漸近線に近づいた場合「収束している」と見なすかという話です。

    それは御社内で決めた事だと押し通すしかないだろ。これまでxx年間、これでやってきて今があるとかないとか言ってさ。付け焼刃のデータ集めても「根拠も無く決めてるのか?」って言い返されるだけだろう。

    そんな状況くらいお見通しだ。だから「画一的」とか「あればいいな」って言ったんだよ。
    クライアントを説得しようとするなら、同業種が平均的に取ってる手法だとか何とか言って説得せねば(言いくるめねば)ならんだろうからな。
    示した資料は厳しい基準を設けてるJAXA関連でIPAからのものでもあるからさ。御社流にアレンジしてみれば?
  • id:garyo
    >そんな状況くらいお見通しだ。だから「画一的」とか「あればいいな」って言ったんだよ。
    私もそんなものは無いことを知っているから「質問」しているわけです。
    もしかしたら、私が知らないだけでどこかに知っている人がいるかも知れないと思っての質問です。
  • id:ken3memo
    少し話を脱線させてしまったらスミマセン、
    遠い昔、新人の頃、バグの数が必要だからバグを作り、書類を作成しろ・バグを作り出せと言われ、
    理由も知らずにテストを行いながらバグを無理矢理作り書類を書いていた、
    そんな昔話を思い出しました。※理由は後で聞かされ 一定数以上のバグが無いと納品物として認められない?でした。
    COBOLの仕事だったので、
    COBOL バグ率
    の2つで検索してみました。
    ※で、見つけられなかったのですが、面白いキーワードを発見しました。
    [バグ管理図] http://www.google.co.jp/search?q=%e3%83%90%e3%82%b0%e7%ae%a1%e7%90%86%e5%9b%b3
    私は聞いたこと無いのですが、この<b>バグ管理図</b> 基本情報処理の問題にもなっているみたいです。
    なので、
    基本情報処理 バグ管理図
    の2キーワードで検索すると、いろいろな年度の問題が引っかかります。
    この<b>バグ管理図</b>で探ると数値も見つけやすいのかなぁ・・・なんて思ったり(実際、基準値は見つけられなかったけど...)
    なんか的を大きく外したような気がしますが、解決の糸口となれば幸いです。
    古い情報処理2種しか持っていない(ぉぃぉぃ)開発手法に疎い三流プログラマーより。
  • id:garyo
    >ken3memoさん、こんにちは
    >バグ管理図
    オープンクローズチャートなどと呼ばれるものですね。
    基礎から学ぶソフトウエア・テスト(6)
    http://itpro.nikkeibp.co.jp/article/COLUMN/20060626/241754/
    に例があります。
    http://itpro.nikkeibp.co.jp/article/COLUMN/20060626/241754/?SS=imgview&FD=57833331&ST=develop


    SESSAMEの初級テキストの8章にもバグ管理図の見方の解説があります。
    http://www.sessame.jp/seminar/BeginnersTextbook/SESSAME_BegginersTextbookChapter8.pdf


    最近ではバグの発見数が成長曲線を描くことから、バグの発見数をゴンペルツ曲線やロジスティック曲線で近似したり、確率モデルとして、非同次ポアソン過程モデルなどで表したりする「信頼度成長曲線」というのが良く用いられて、色々解析に使われます。
    http://ja.wikipedia.org/wiki/%E4%BF%A1%E9%A0%BC%E5%BA%A6%E6%88%90%E9%95%B7%E6%9B%B2%E7%B7%9A

    以下参考文献です。

    「ソフトウェア信頼性モデル-基礎と応用」,山田茂著,日科技連出版
    http://www.amazon.co.jp/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E4%BF%A1%E9%A0%BC%E6%80%A7%E3%83%A2%E3%83%87%E3%83%AB%E2%80%95%E5%9F%BA%E7%A4%8E%E3%81%A8%E5%BF%9C%E7%94%A8-%E5%AE%9F%E8%B7%B5%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA%E5%B7%A5%E5%AD%A6%E3%82%B7%E3%83%AA%E3%83%BC%E3%82%BA-%E5%B1%B1%E7%94%B0-%E8%8C%82/dp/4817161167
    「品質指向ソフトウェアマネジメント」山田茂著、福島利彦著、森北出版、
    http://www.amazon.co.jp/%E5%93%81%E8%B3%AA%E6%8C%87%E5%90%91%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88-%E9%AB%98%E5%93%81%E8%B3%AA%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88-%E5%B1%B1%E7%94%B0-%E8%8C%82/dp/4627871112/ref=sr_11_1?ie=UTF8&qid=1223693768&sr=11-1

    マルコフモデルに基づくソフトウェアの運用信頼性評価法と最適リリース問題への応用 得能 貢一著、山田 茂著
    http://www.ism.ac.jp/~tsuchiya/sympo/shukai04/shukai04-papers/016tokuno.pdf
  • id:ttakao
    テスト方法論をご存知であるならば、ご質問されている内容の意味をよくご存知なんだと思います。
    ということは、いかに知識をもたない客を説得するかということです。正面きって、仮に権威ある本に「○パーセント」とあっても「ウチにはあてはまらない気がする」といわれたら終わりです。
    理論を積み上げれば上げるほど生意気に見られて袋小路に突入することを心配します。
    私ならば、お客の過去の経験から少しよくなってる数値をもっていきますね。
  • id:garyo
    >ttakaoさん
    まさにおっしゃられる通りです。
    信頼度成長曲線なんて、モデルに選ぶ曲線や、横軸の取り方(日数、テストケース数、テスト工数)で収束度は大幅に変化します。あくまでも目安として使用するのが良いのですが、数値に現れるとそれを盲信して、「いくら以上ないといけない」とか「根拠を示せ」と言い出す方が出てくるわけですよね。
    >私ならば、お客の過去の経験から少しよくなってる数値をもっていきますね。
    そうですよね。
  • id:garyo
    私が不勉強でした。

    IPA発行の「ESQR組込みソフトウェア向け品質作り込みガイド」 PDF版
    http://sec.ipa.go.jp/publish/index.html#emb

    に「不具合収束率」の定義と参考値が載っているとtwitterで教えてもらいました。

    P102に確かに載っていました。こちらを参考にさせて頂きます。

この質問への反応(ブックマークコメント)

トラックバック

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません