アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
手段はともかく (スコア:1, 興味深い)
・前もって見積もったバグの量と比較するため?
・バグの再発を防ぐため?
・バグを作った原因をさぐるため?
・バグを上司に報告させるため?
・バグを直す
Re:手段はともかく (スコア:1, 参考になる)
「コードの行数あたりのバグ検出数」が、予言(藁)の値より小さかったら、
バグを探し直せ、と怒られるというプロジェクト運営を行なってくださる発注者を
経験したことが有ります。
ええ。勿論、まともなバグ報告なんて行なえなくなりました。
実際に見つかった数をどうやってそれ以上増やせってんだか。
どうということのない事象を「バグだ」とこじつけるとか、をする羽目になりましたね。
勿論そうすれば仕様書は逸脱するが、どうせ仕様書自体が曖昧模糊としたものだったので(藁)、
仕様書に「厳密に従う」方法が最初から存在しない…
製品といっしょに仕様書も成長 (スコア:0)
仕様書って、最初はどうしても曖昧な部分があるのはしょうがないと思うんです。
で、皆さんにお聞きしたいのは、作成しているソースや、そのバグを管理するのと同じように、仕様書も管理していますか?してる方はどんな風にしていますでしょうか。
Re:製品といっしょに仕様書も成長 (スコア:1)
変化しつづけていつまでも確定しないというのは
アレすぎて説明しにくいなあと思っていました。
以下の本でも仕様が変化していくということに
言及していますね。
「ソフトウエア開発 55の真実と10のウソ 」の目次 [nikkeibp.co.jp]
Re:製品といっしょに仕様書も成長 (スコア:0)
作業見積もりミスおよびスパイラル作業分は
デスマーチで対処することになります。
# GW のあいだに元計画に追いつかねばならないのでAC.