すべてのプロジェクトのネジを外し、実際の遅延を評価してみてください。
遅延が単に巨大な値に達することが判明する場合があります。
この記事の著者は、プロジェクトが400％と700％遅れているのを見ました！
原則として遅滞なくプログラムを開発することは不可能であるという意見があります。
一般に、この観点の理由は明確です。人々は先見者ではなく、未来を見ることができないからです。
TKの複雑さの評価の時点では、常にあるとは限りません。 そして、たとえ存在していても、不確実性の要因は依然として大きな役割を果たし続けます-残念ながら、人々は実際には先見の明がないため、TKがどれほど詳細であっても、見えない瞬間がまだあります。
隠された機能に加えて、誤った評価は、評価者のプログラミングの資格と個人的な経験によっても非常に強く影響されます（個人的なプログラミング経験のない人が開発にかかる時間を見積もることはより困難です）。
興味深いのは、使用のシナリオ（オプション）により、作業の複雑さをかなり正確に評価できることです。
実践では、評価で20％の精度（=％エラー）を達成できることが示されています。 しかし、20％遅れているのは700％ではありませんよね？
どうやってやるの？
どこから始めるか
結論は代替案です！
ユースケースの美しさは、イベントのメインコースだけでなく、考えられるすべての可能性と不可能な代替状況も記述していることです。 そして、代替案-これらは非常に落とし穴です。そのため、複雑さを評価する際にエラーが発生します。
スクリプトを使用して複雑さを計算する方法は？
この小さなウィンドウをプログラムする必要があると想像してください。
この例は完全に正しいわけではありません。なぜなら これはビジネスタスクではありませんが、労働集約度の計算の説明として使用できます。 ですから、スクリプトのプレゼンテーションの正確さを割り引いて、複雑さに集中してください。
シナリオを簡単に記述します。
ユースケースドキュメントの検索
成功した結果：選択したドキュメントは、あるオブジェクトのプロパティに登録されています
主な成功シナリオ
1.ユーザーが検索フレーズを入力します。
2.システムは適切なドキュメントのリストを表示し、その名前には目的のフレーズが含まれます 。 ドキュメントは名前で表示されます。 リストはアルファベット順にソートされます。
3.ユーザーがドキュメントの1つを選択します。
4.システムは、選択したドキュメントを目的のオブジェクトに登録します 。
代替案
2a。ユーザーは指定された日付のドキュメントを検索したい
1.システムは、作成日によって制限された適切なドキュメントのリストを表示します 。 条項3に従って実行が継続されます。
2b。ユーザーがアーカイブ内のドキュメントを検索したい
1. 1. 適切な現在のドキュメントとアーカイブされたドキュメントのリストが表示されます 。 条項3に従って実行が継続されます。
3a。ドキュメントが見つかりません
1.システムに「ドキュメントが見つかりませんでした」というメッセージが表示されます。 実行は請求項1に従って続行されます。
スクリプトは、「主要な成功したスクリプト」と「代替」の2つの部分に分かれていることに注意してください。
次に、労働投入量の推定方法について考えます。 作業は通常、成功したシナリオ（最初に思い浮かぶ最も明白なシナリオ）に従ってのみ評価されることに同意すると思いますが、彼らは代替案についてはまったく考えていません。
これが問題の本質です。主な労働投入量がしばしば埋められるのは代替案です。
続けましょう。
この例では、 イタリア人がプログラマーがプログラミングする必要がある操作をマークしました。
代替案では、メインシナリオにはない2つの操作を見ることができます。 これらの操作が何であるかを考えてみましょう。 本質的に、これらは通常のSQLデータベースクエリですが、！
これらには、メインリクエストにはない追加のパラメーターがあります。 そして、これらのパラメータを使用したリクエストのデバッグには、メインリクエストの10倍の時間がかかる可能性があります。 そして、まさにそれが起こるのですよね？
スクリプトを使用すると、これらすべての選択肢（またはそれらのほとんど）などを明らかにすることができます。 作業の全体的な複雑さを評価するために、数倍正確です。
複雑さを評価する方法
スクリプトのすべての情報を1つのテーブルにまとめて、実装にかかる時間を計算してみましょう。
クラスインフラストラクチャの作成-1時間
ウィンドウシェーピング-2時間
キーワードによるドキュメントのリストの表示-1h
作成日を考慮したドキュメントのリストの表示-1h
アーカイブ文書を含む文書のリスト-1時間
選択したドキュメントをオブジェクトのプロパティに書き込む-1時間
テスト4 * 0.5h = 2h
合計：9時間
ご覧のとおり、評価では、代替案の実装にさらに2時間、それらのテストにさらに1時間かかります。 そして、評価が成功したシナリオに従ってのみ実行された場合、これらの3時間はカウントされませんでした。
そして、これはほぼ50％の時間です（メインシナリオでは6時間、代替案では3時間）！
まとめ
ユースケースは明らかに、複雑さの評価において非常に大きな利点をもたらします。 それらを使用して、他のソフトウェア開発者よりも競争上の優位性を獲得します。
PSAは、まだスクリプトがない場合はどうなりますか？
評価の時点でスクリプトをまだ作成していない場合は、少なくとも主要な代替案の簡単なスケッチを試してください。 これにより、すでに成績が改善されます。
PPS豚は他のどこに埋葬されていますか
スクリプトのステップが十分に小さくないことが起こります。 たとえば、システムが何らかのデータを公開する必要があるとします。
理解しているように、アクションの「ヒープ」は、すぐに判断するのが難しい一連のアクション全体を隠すことができます。
このような状況は、労働強度評価で3時間以上の時間が設定されている場合、非常に簡単に判断できます。 これは、評価を行う人が内部に隠されているものを知らないことを明確に示しています。 そして、100％が大きな待ち伏せに座っています！ 繰り返し確認されます。
この場合、必ず内部に隠されているものを熟考し、処方してください。そうしないと、非常に時間通りに取得できます。