パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

新しい材料には新しい検査が必要」記事へのコメント

  • 飛行機は過度に安全係数をとると重くなって飛びませんから、
    ギリギリの安全係数で設計して、その代わりに検査で問題点を摘出するというアプローチしか取れません。
    また、いったん飛び立ってしまえば着陸するまで修理は出来ないし、あちこち飛び回っているので、
    どの時点で修理をするかを決め、必要機材を先回りして準備しておかなければいけないといった事情あり、
    予測ということが重要でしょう。
    これが地上の構築物であれば思いっきり安全係数を掛けて、検査を軽くするという
    ライフサイクルコストを考えたアプローチも取れるのですが。

    ソフトウェアのいいところはバグを潰しきれれば、その部分は安全であり、経年劣化や疲労などの心配をしないで済むということですね。
    事前検査できる、個体差を考えなくてもいいというのも大きな特徴です。
    • Re:安全係数 (スコア:2, 興味深い)

      by Anonymous Coward
      >ソフトウェアのいいところはバグを潰しきれれば、その部分は安全であり、経年劣化や疲労などの心配をしないで済むということですね。

      裏を返せば恐ろしい事実が浮かび上がってきますね。

      つまり、ソフトウェアでは、
      上の人たちが話していたようなリアル物と違い、
      「予測不可能な」壊れ方が大半を占める、ということになるので。

      リアル物の疲労とかの壊れ方は、ある意味で予測可能なんですよね。
      これくらいの力がかかってるから確率的にこれくらいの時期に駄目になるだろうとか。

      ところがソフトはその発想が通用しない。
      時間によって壊れるのではない。
      実は最初から壊れてるだけで、それが発覚
      • by Anonymous Coward
        > #某通信系大手に「バグ率」という言葉を散々振りかざされてウンザリしたのでAC
        > #バグが多いならまだしも、少な「すぎ」てもペナルティを科されたんだよね…
        > #もしウチの社員がテメーラより3倍優秀だったらバグも1/3になることは全然おかしくないだろうに…
        多分そこの中の人の上の人です。

        コードの品質が高いことを客観的に示せば受け入れてもらえたはずですよ。
        データに基づいて説得できなかった時点で負けですね。
        せっかくコーダは優秀なようなのに、マネージャがゴミじゃダメだよな。
        • ああ、ソフトウェアの設計にも安全係数の考え方ができたら、 どんなに楽なことか。

          常識的には、ソフトウェアの品質は、 欠陥を見つけて修正して、それが枯れたことでしか測れません。 そもそも欠陥が出ないと品質が測れないということは、 仮に超優秀なプログラマがいて、本当に無欠陥のコードを書いたとしても、 それは品質測定ができず、受け入れ不可能ってことになります。 だから、テストで欠陥がある程度出てくれないと困るのは確かです。

          でもね、欠陥の検出率を測定して、 ある一定以上の欠陥が出ていないとしたら、 まず、テスト担当側の方法を疑う

          • by Anonymous Coward
            >欠陥の検出率を測定して、ある一定以上の欠陥が出ていないとしたら、まず、テスト担当側の方法を疑うのが普通であって、開発会社にペナルティを科すってのは、全くデタラメなやり方ですね。

            え?「テスト担当者」も弊社ですが何か?

            変だって?「普通」でないって?
            でも、こっちでテストしろと、あちら様に命じられたんですもの。普通という言葉すら歪曲するのが大企業様の恐ろしいところ。

            (あれ?そういや「テストの方法」を命じられた記憶が無いです。「いかにテストするか」を縛ってないくせにバグ率(行数あたりのバグ件数)は縛り、しかも実はコッチの言い値ですか?なん
            • Re:安全係数 (スコア:1, 参考になる)

              by Anonymous Coward
              私も下請けの身ですが、大会社様のもとで品質管理のお手伝いをしたことがあるので。

              まぁ、相手は大会社様ですからね、その大会社様の会社全体で見るとサンプル数も多いんですわ。
              するってーと、案外、それなりに平均的な値とか傾向っつーのも出てくるんですよ、特に案件の規模が大きくなってくるとね。
              傾向の出方も、バグ数だけの話じゃないんですよ、バグの種類とか、各工程での出方とかね。
              この辺をきちんと見ていくと、これ数字捏造でしょ?とか、テスト本当にやったの?とか、テストの力入れる部分違うんじゃない?とか、そういうのも大体見えてくるんです。
              SI工程なのに
              • Re:安全係数 (スコア:1, 参考になる)

                by Anonymous Coward on 2007年11月26日 6時26分 (#1255485)
                アドバイス追加

                テスト目的やテスト観点、試験項目はきちんとレビューしてもらおう。→やるべき試験についての事前ネゴ
                テスト期間や項目数にもよるが、最低でも週1、可能なら毎日、試験消化状況やバグの発生状況について話す場を設けてもらおう。→状況把握してもらおう&捏造してないことを知ってもらおう
                政治的・コスト的に可能なら、担当部署の品質管理チームに数人混ぜてもらおう。→相手がどういう考えでいるのかを知ろう&手法を学び取ろう
                同じく政治的・コスト的に可能なら、自社内部にも品質管理チームを持とう。担当部署の品質管理チーム分隊という感じでもOK。→大会社様と同じ意識を持とう&内部の記録ミスなんかは随時正そう
                親コメント

身近な人の偉大さは半減する -- あるアレゲ人

処理中...