「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
見積とは...
- 金額・量・期間・行動を前もって概算すること。
- 見積もること。
- あらましの計算をすること。
- また、その計算。
詳細 †
分類 †
以下のような分類がある。
ソフトウェア開発見積 †
基本的に、パラメトリック見積で行う。
FP法 †
（ファンクションポイント法 / Function Point method）
し、そのソフトウェアにおける合計点数（FP）から開発工数を見積もる。
- トレード・オフ
- プログラミング言語の種類や書き方、機能の実装方法などに依存しない。
- 機能の複雑度の判定は主観が入り込みやすく、過去事例の無い場合の評価が難しい。
オレオレ法 †
これも立派なパラメトリック見積（FP法と同じ）。
ステップ規模見積 †
- 以下の事例情報が、企業 / 組織 / 個人に、
多数、溜まっていることで見積もりが実現可能。
- 開発言語 / フレームワーク / ツールによって影響を受ける。
- ステップ規模が大きくなる。
・Webアプリケーション
・低水準言語
・フレームワークの未活用
・自動生成の使用
- ステップ規模が小さくなる。
・C/Sアプリケーション
・高水準言語
・フレームワークの活用
・EUCツールの使用
・自動生成の不使用
- ローカル・ルール
ステップ規模の測定には、ローカル・ルールが多いが、
事例内のルールが統一されていないとデータの利用が難しくなる。
- SQL (DDL / DML)は測定しない。
- 画面定義、帳票定義は測定しない。
- （DHTML時代の...死語）JavaScriptは測定しない。
- 新規開発規模以外のステップ規模算出式
- 流用、改造等などを考慮する。
- ステップ・カウント・ツールに機能が組み込まれていることも。
案件特徴 †
生産性変動要因 †
- 開発技術
- 初めて使う開発技術
- 生産性が 高い / 低い 開発技術
- 顧客マター（上流）
- 要件が固まらない（要件未確定）。
- 仕様が出てこない（仕様未確定）。
- 仕様膨張。
生産性ではなく規模の話のように聞こえるが、
下流工程でも膨張を続けるようだと≒仕様未確定で生産性も低下する。
- 顧客マター（下流）
- ユーザが「コレジャナイ。」と言う。
- オーナーが「こんなはずじゃなかった。」と言う。
- 最近は単純な案件が減り、
変動要因が重要になってきている。
再構築（現新一致）の見積もり †
スクラッチ開発の見積もりと似ているが、以下の点が異なる。
- 現行システムと仕様書の乖離が見積もりのポイントになる。
- 乖離が大きい場合、リエンジ後に見積もらないと危ない。
パッケージ・カスタマイズの見積もり †
スクラッチ開発の見積もりとは、大きく異る。
- 特徴
- 要件 / 仕様が不明確なら段階的になるが、パッケージでは一括の慣例。
- 一括になると、業務に詳しくないとカスタマイズの見積が不可能。
- 結果、フィット＆ギャップが十分でない状態で契約してしまうケースが多い。
- ポイント
- 一般的に、カスタマイズ規模が3割を超えると、≒新規開発と言われる。
- スクラッチ開発の見積もりとは、大きく異る。
- 例外的に、ボトムアップ見積的に行う。
トピック †
ソフトウェア開発見積と異なり、ボトムアップ見積的に行う。
KKD（勘と経験と度胸）でエイヤの裏側 †
- これは、「１画面、１K step、１人月」と言う感じの概算の見積もり方法。
こう書くと、伝統的＆属人的な、陳腐な方法に見えるが、
PMBOKで以下に該当と言われるとマトモな方法にも見えてくる不思議
- 昔ながらの開発では、恐らく、
以下のような感じで概算可能。
- 金融 / 公共系：１画面、２K step、２人月
- 産業系：１画面、２K step、１人月
- 「下限での見積」がSI事業の商習慣として慣例化しているため。
- また、発生したバッファ工数が「パーキンソンの法則」で消費されるため。
- 業種によって（、例えば以下のように）、
WBSが異なり、形骸化など生産性が下がる事もある。
- コレが、ナカナカ是正されないは以下による。
- 「パーキンソンの法則」的
- 事業者サイドにメリットが無い。
参考 †
Wikipedia †
パッケージ・カスタマイズ †
- SEC BOOKS：
ソフトウェア改良開発見積りガイドブック：
IPA 独立行政法人 情報処理推進機構
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
