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

ソフトウェアにもPL法?」記事へのコメント

  • 仕様のバグ (スコア:1, 興味深い)

    by Anonymous Coward on 2002年06月19日 23時06分 (#110321)
    バグという言葉について、コーディングレベルのものを前提にしている人が多いような気がするけど、仕様からして間違ってるもの(私は仕様のバグと呼んでます)についての意見も聞きたいな。
    別にMSをたたくのが目的じゃないけど、MSの製品に多いよね。
    • Re:仕様のバグ (スコア:2, 参考になる)

      by tix (7637) on 2002年06月20日 1時50分 (#110416) ホームページ
      バグという言葉について、コーディングレベルのものを前提にしている人が多いような気がするけど、仕様からして間違ってるもの(私は仕様のバグと呼んでます)についての意見も聞きたいな。
      ぼくも「仕様のバグ」という言葉を使います。「仕様のミス」と呼ぶこともありますが。コーディングのバグよりも直すのが大変なぶん、企業としては全力で避けたいところでしょうね。

      コーディングのバグか仕様のバグかというのは常に明確に分かれるものではないと思いますが、ソフトウェアのセキュリティホールの中には、仕様のバグによるものもけっこうあります。 IE や Opera で、 Content-Type: text/plain でもスクリプトが動く弱点 [srad.jp]は典型的な仕様のバグでしょう。しかも、 IE はいったんそういう仕様で作ってしまった以上、簡単には変えられないようです。
      別にMSをたたくのが目的じゃないけど、MSの製品に多いよね。
      そうですか? Windows や IE には仕様のバグと思われる問題点がいろいろありますが、ほかのソフトウェアについても挙げればいろいろあるような気がします。

      ……と書いたので例を挙げてみようと思っても面白い例が思いつかないのですが。 :) 最近、使っているソフトウェアのうち大規模なものがほとんど Microsoft 製だからなあ……。(不健全?)
      --
      鵜呑みにしてみる?
      親コメント
      • by G7 (3009) on 2002年06月20日 3時16分 (#110455)
        >コーディングのバグよりも直すのが大変なぶん、企業としては全力で避けたいところでしょうね。

        全力って何なんだろう?ってのが有ったりします(^^;
        卑近な言いかたをすれば、「レビュー」とやらをなんべんやったところで
        ほんとうに良くなるの?と疑問に思ってみたりとか。

        猟師プログラマとか名乗る人も言ってましたが、
        仕様のバグは、実装のように計算機の上で走らせて確認することが
        (たいてい)困難ないしは不可能なので、そう簡単にバグを取れない、という面が。

        #こっちとしては、そういう不確かなものなんだから、「仕様書いてやったんだぞ」的な、デカい面するなよなとは思う。

        やりかたをよほど選ばない限り、全力といっても空回りしまくるんじゃないかと思うんですよね。

        そういう意味では、いわゆる仕様書をかなりの割合で追放しちゃったXPは、慧眼かも。
        いかに早い段階から計算機上でデバッグできる形(現代の技術ではそれは実装そのものである)にするか?が勝負だという。
        実装詳細仕様書なんてものを(実装言語以外で)書いちゃった時点で、敗北なのかも知れない。

        よだん:
        企業内の「偉い人」ほど、仕様というものにたいして躍起になっているような気がする…のは被害妄想か?
        親コメント
        • by tix (7637) on 2002年06月20日 3時45分 (#110462) ホームページ
          いかに早い段階から計算機上でデバッグできる形(現代の技術ではそれは実装そのものである)にするか?が勝負だという。
          それはそれで、実装+デバッグというプロセスを過信しているような気がしますが……。それに、実装してデバッグしてみてから仕様に不備があったことに気付いたら、また実装からやり直すわけですよね。素人考えでは、それでは逆に時間がかかるのではないかと思います。

          ただ、ソフトウェアというものが、全体像を一人で理解できないくらい複雑になってしまった現在、仕様策定というステップでいくら慎重になってもうまい仕様など決められないのかもしれません。ぼくは、そうは思いたくないですが……。
          --
          鵜呑みにしてみる?
          親コメント
          • > それに、実装してデバッグしてみてから仕様に不備があったこと
            > に気付いたら、また実装からやり直すわけですよね。素人考えで
            > は、それでは逆に時間がかかるのではないかと思います。

            だからこそカプセル化して部分部分は仕様変更に耐えられるようにしよう、
            という OOP の発想が出て来るわけ。
            そうすれば再実装する部分はごくわずかでいい。
            --
            # mishimaは本田透先生を熱烈に応援しています
            親コメント
          • by G7 (3009) on 2002年06月25日 2時34分 (#112617)
            >実装してデバッグしてみてから仕様に不備があったことに気付いたら、また実装からやり直すわけですよね。

            スパイラル(ぐるぐる周り)開発と呼ばれる手法では、そのために、
            「やりなおしの単位」を最初から小さくなるように設定するようです。

            で、たとえばOOPは、それ以前の手法より、その小ささを実現しやすいという面が有るので、
            そっち方面で(も)重宝であるらしいです。
            OOPって、「小プログラム」を組みあわせてアプリを作るようなものですから。
            (従来もそうしていましたが、ルーチンの単位だけじゃなく状態の単位も小分けしやすいのが、OOP。)

            小さい部品を作りなおすわけです。大きい全体ではなく。

            >仕様策定というステップでいくら慎重になってもうまい仕様など決められないのかもしれません。

            木を見て森見ずと言いますが、俺が想うに、大掴みならばともかく
            詳細に至るまでについては、がっちり策定しにくいんじゃないかと。

            ただ、詳細かどうかとは直交の軸として、メタ度が高い視点か低い視点か、という問題が有りまして、
            高いメタ度で、かつ詳細に直結するような部分、を策定するってのは色々できるかなと。

            平たくいえば、「全体に共通する詳細」を把握することは、できるかも。
            個々の個所に固有な詳細は、きりがなくて手に負えないかなと。

            >ぼくは、そうは思いたくない

            どっちにせよ、万能支配主義に傾倒するのは、危険かなと。
            把握しやすい部分とそうでない部分が有るんで、それの区別、見極め、が重要ということなのじゃないかと。

            てゆーか、その区別を「間違う」とデスマーチしやすいと思います。
            人はしばしば、簡単なものと困難なものとを取り違える生き物ですので。

            あと前述したように、仕様のコンパイラ(笑いごとじゃなく)が存在しないのがイタイ、ってのも有ります。
            機械的にその確かさを確認する手段の不在、です。
            親コメント
        • こんな馬鹿な仕様、出来るわけねーだろと仕様を出した側を小一時間問い詰めたくなるような無茶苦茶な仕様と言うのも、特に基幹系やコンシューマ系のソフトでは少なくない訳で。

          なんつーか、仕様だしからデバッグまで一人とか数名で近い所でやってる場合は多少無茶な仕様でも時間さえあれば何とか出来るのですが(後は有能な営業:-)、
          そうでなくて営業ががちがちだったり、「何でも出来る」と勘違いしてる人だったり、孫請け以下まであるような大規模プロジェクトだったりすると、机上で仕様をこねられると大抵破綻するようですね。

          破綻しているのを無理に商品にするから、バグがてんこもりになるような感じがするのですが、実感として。

          親コメント
        • >猟師プログラマとか名乗る人も言ってましたが、

          細かいことですが、SDで連載されている方なら、「漁師」です。その意味は私には理解できていませんが。
          親コメント
        • by Anonymous Coward
          どうでもいいような仕様書は多いけど,かと言って仕様をないがしろにして作ったんでは、何ができるかわからないのでは?
          出来たものが正しいのかどうかも判定できないし。

          仕様に問題があれば、デバッグ中に発覚したとしても仕様のレ

          • by G7 (3009) on 2002年06月25日 2時41分 (#112619)
            >こういうレベルの仕様の話では無いと思うのだが。

            うーん。まあそれもそうなのかも知れないけど、
            大まかにせよ詳細にせよどっちにせよ、「仕様コンパイラ」「仕様インタプリタ」が無いかぎりは、
            その仕様書の記述が「ほんとに動くものにすることができるのか」を
            確かめる術が無いって事情は同じなわけです。

            漠然とした仕様が常に、実装し動かし得るモデルのいずれかにマッピングできる、という保証は、無いです。

            逆に言えば、そのマッピング可能性を素朴に信じて疑ってない人が、そういうイタい仕様書を書くわけです。
            そういう意味では、そういう人ほど、(迷惑であること(としばしば横暴であること)をさておけば)「かわいい」んですよね…(遠い目…

            #まあ、仕様書が詳細に言及すればするほど、イタい「個所の数」が多くなるのは、確かでしょうけども。
            親コメント
    • というのが, 大方のユーザの実態ではないでしょうか. このあたりの感覚はエンドユーザ相手に仕様のインタビューを行ったことのあるSEなら誰でも経験することでしょう.

      簡単な例ですが 3÷2 の答えは何になるのが正しいでしょうか? 2÷3 の答えと 2.0÷3 の答えは同じでしょうか?

      私は幸いにして, こういう話が通用するお客さんを相手にすることが多かったのですが, 残念ながら世の中ってのはそれほど道理の通る物じゃないみたいです.

      親コメント
      • by uguisu (9285) on 2002年06月21日 9時55分 (#111105) ホームページ 日記
        私は、自治体を相手に仕事をすることが多いのですが、この場合、自治体側が仕様書を作成し、競争入札にかけます。

        1.仕様作成について
        自治体は、その業務のプロではありますが、システム開発については彼らのビジネスの範疇外です。しかしながら、現在の自治体としては、彼らが仕様書を作成しなければならないことも多いようです。

        それで彼なりに仕様を作成するのですが、非常に多くの場合、開発側に意見を求めることが多いです。そして、残念ながら開発側が不適切なアドバイスをすることも多いようです。これは、自治体相手の場合、プレゼンの良し悪しなどが受注に結びつかないことが多いためだと思いますが(入札になると、見られるのは金額だけ)、こうしてせっかくの仕様作成にかかわるチャンスを見逃しているのも事実だとおもいます。

        2.受注後
        うちであった例として、自治体側が作成した仕様である特定のデータベースソフトを使用してアプリケーションを開発せよ、とありました。最近読んだ要求定義工学などでは、このような制限は仕様にするべきではない、とかかれていますが、まったくそのとおりです。実際、業務内容を聞いてみると、日に1000件のデータが入る代物で、そのデータベースの限界は1年ともたずに超えることがすぐに判明しました。これにもかかわらず何の対策もせずに当初の設計どおり開発したわれわれは、わずか3ヶ月分程の収入で、その後2年間ほど無償メンテナンスをすることになりました。

        以上から、私の自治体さん相手のポリシーは、
        1.意見を求められたら、たとえ嫌われても、たとえ自分が受注できる保証がなくとも、良い仕様がかけるようにアドバイスする。
        2.仕様を変えるのも開発側の仕事のうち。
        です。
        親コメント
      • ソフト単体ではなくて、装置モノの設計やってますが、特にオペレーション関連は結局、「動いてみるまで良いか(使いやすいかどうか)どうか判らない」という部分がありますね。動かしてから仕様のレビューに立ち戻る時間があるときはまだ良いですが....
        親コメント

私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson

処理中...