8

プロジェクトの時間を見積もる (または他の誰かの見積もりを確認する) 必要があるたびに、アルファ版と製品版のリリースの間に行われるテスト/バグ修正に時間が割り当てられます。私は、サイズが未知の一連の問題に関してこれまでのところ未来を見積もることが、成功する見積のための良いレシピではないことをよく知っています. ただし、さまざまな理由から、定義された時間数がこの作業セグメントの最初に必ず割り当てられます。そして、この最初の見積もりが実際の最終的な値から遠ざかるほど、デバッグに関与する人々は、後で見積もりを「超えた」ときに、より多くの悲しみを抱かなければならなくなります。

私の質問は次のとおりです。このような見積もりを行うことに関して、あなたが見た中で最善の戦略は何ですか? 全体的な開発見積もりの​​均一なパーセンテージ? 時間数を設定しますか (それが上がることを期待して)? 他の何か？

他に考慮すべき点: クライアントが (内部 QA ではなく) テストの責任を負い、クライアントが見つけるかどうかわからないバグに対応するための時間を割り当てる必要がある場合、これにどのように別の回答をしますか?テストではなくバグ修正にかかる時間の見積もりを把握するため)

4

5 に答える 5

9

それは本当に多くの要因に依存します。ほんの数例を挙げると、使用している開発方法論、使用しているテストリソースの量、プロジェクトのこの段階で利用可能な開発者の数（多くのプロジェクトマネージャーは、最後に人々を新しいものに移します）。

Rob Rolnickが言うように、1：1は経験則ですが、仕様が悪い場合、クライアントは実際には正しく指定されていない機能である「バグ」をプッシュする可能性があります。私は最近、多くのリリースを使用するプロジェクトに参加しましたが、仕様がひどいため、実際の開発よりもバグ修正に多くの時間が費やされました。

テスターが何をどのようにテストするかを確認しやすくなり、クライアントが追加機能をプッシュする余地が少なくなるため、優れた仕様/設計とテスト/バグ修正時間が短縮されることを確認してください。

于 2008-09-07T14:05:45.757 に答える
6

バグのあるコードを書いているだけかもしれませんが、開発とテストの比率を 1:1 にするのが好きです。アルファ版までテストするのではなく、プロジェクト全体でテストを行います。ロジック？リリース スケジュールによっては、開発が開始されてから、アルファ版、ベータ版、および出荷日までにかなりの時間がかかる場合があります。さらに、バグを発見するのが早ければ早いほど、バグを修正するのは簡単 (かつ安価) になります。

チェックインのたびにすぐにバグを発見する優れたテスターは、かけがえのない存在です。(または、PR または DPK からチェックインする前に) 簡単に言えば、私はまだ自分のコードに非常に精通しているため、ほとんどのバグ修正は非常に簡単になります。このアプローチでは、開発時間の約 15% をバグ修正に費やす傾向があります。少なくとも私が見積もりをするとき。したがって、16週間の実行では、約2〜3週間離れます.

于 2008-09-07T13:49:24.097 に答える
5

以前のプロジェクトから蓄積された統計のかなりの量だけが、正確な見積もりを与えるのに役立ちます。明確に定義された一連の要件がある場合は、使用例の数を大まかに計算できます。私が言ったように、あなたはあなたのチームのためにいくつかの統計を持っている必要があります。バグの総数を見積もるには、場所ごとの平均バグ数を知る必要があります。チームにそのような数値がない場合は、業界平均の数値を使用できます。LOC（ユースケースの数* NLOC）と行ごとの平均バグを見積もった後、プロジェクトのリリースに必要な時間について、多かれ少なかれ正確な見積もりを行うことができます。

私の実際の経験から、バグ修正に費やされた時間は、元の実装に費やされた時間と同じかそれ以上です（99％の場合:)）。

于 2008-09-07T13:57:46.870 に答える
5

テスト聖書から：

コンピュータソフトウェアのテスト コンピュータソフトウェアのテスト

p。31：「テスト[...]は、製品の初期開発の45％を占めています。」したがって、経験則として、初期開発中のテストに総作業量の約半分を割り当てることです。

于 2008-09-07T14:30:43.513 に答える
2

Design-by-Contract または「コード コントラクト」(前提条件、チェック アサーション、事後条件、クラス不変条件など) を備えた言語を使用して、クラスとクラスの機能 (メソッドとプロパティ) にできるだけ近い「テスト」を取得します。可能。次に、TDD を使用してコードをそのコントラクトでテストします。

可能な限り多くの自己構築コード生成を使用してください。生成されたコードは、すべて手作業でコーディングされたコードよりも、実証済みで、予測可能で、デバッグが容易で、修正が容易/迅速です。なぜあなたが生成できるものを書くのですか？ただし、OPG (other-peoples-generators) は使用しないでください。あなたが生成するコードは、あなたが制御し、知っているコードです。

プロジェクトの過程で反転比率を費やすことを期待できます。つまり、プロジェクトの開始時 (1:1) に大量のハンド コードとコントラクトを記述します。パターンが見えたら、自分が書いたコード ジェネレーターにコードを生成して再利用するように教えます。生成すればするほど、設計、記述、デバッグ、およびテストが少なくなります。プロジェクトの終わりまでに、方程式が逆転していることに気付くでしょう: コア コードの記述が減り、「リーフ コード」(ラスト マイル) または特殊化 (一般化および生成されたものに対して) に焦点が移ります。 ) コード。

最後に、コード アナライザーを入手します。優れた自動化されたコード分析ルール システムとエンジンを使用すると、「ばかげたバグ」を見つける時間を大幅に節約できます。Eiffel には、Eiffel Inspector があり、付属の 90 以上のルールを使用するだけでなく、発見した独自の「落とし穴」に対して独自のルールを作成することを学んでいます。このようなアナライザーは、バグの点であなたを救うだけでなく、あなたのデザインを向上させます。GREEN プログラマーでさえもかなり早く「理解」し、初歩的な間違いをするのを早くやめて、より速く学びます!

既存のシステムを書き直すための経験則は、「書くのに 10 年かかったなら、書き直すのにも 10 年かかる」です。私たちの場合、Eiffel、Design-by-Contract、コード分析、およびコード生成を使用して、14 年のシステムを 4 年で書き直し、4 年半で完全に配信します。新しいシステムは古いシステムよりも約 4 倍から 5 倍複雑なので、これは多くのことを物語っています。

于 2014-09-20T03:42:49.887 に答える