.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

見積とは...

  • 金額・量・期間・行動を前もって概算すること。
    • 見積もること。
    • あらましの計算をすること。
    • また、その計算。

詳細

分類

以下のような分類がある。

類推見積(トップダウン見積)

パラメトリック見積

三点見積

ボトムアップ見積

ソフトウェア開発見積

基本的に、パラメトリック見積で行う。

FP法

(ファンクションポイント法 / Function Point method)

  • ソフトウェアがもつ機能数を
    • 点数付け、
    • 複雑さによって重み付け、

し、そのソフトウェアにおける合計点数(FP)から開発工数を見積もる。

  • トレード・オフ
    • プログラミング言語の種類や書き方、機能の実装方法などに依存しない。
    • 機能の複雑度の判定は主観が入り込みやすく、過去事例の無い場合の評価が難しい。

オレオレ法

これも立派なパラメトリック見積FP法と同じ)。

ステップ規模見積

  • 以下の事例情報が、企業 / 組織 / 個人に、
    多数、溜まっていることで見積もりが実現可能。
  • 案件特徴
  • 工数 / 原価
  • ステップ規模
  • ステップ規模
  • ステップ・カウント・ツールなどを用いて算出する。
  • 開発言語 / フレームワーク / ツールによって影響を受ける。
  • ステップ規模が大きくなる。
    ・Webアプリケーション
    ・低水準言語
    ・フレームワークの未活用
    ・自動生成の使用
  • ステップ規模が小さくなる。
    ・C/Sアプリケーション
    ・高水準言語
    ・フレームワークの活用
    ・EUCツールの使用
    ・自動生成の不使用
  • ローカル・ルール
    ステップ規模の測定には、ローカル・ルールが多いが、
    事例内のルールが統一されていないとデータの利用が難しくなる。
  • SQL (DDL / DML)は測定しない。
  • 画面定義、帳票定義は測定しない。
  • (DHTML時代の...死語)JavaScriptは測定しない。
  • 新規開発規模以外のステップ規模算出式
    • 流用、改造等などを考慮する。
    • ステップ・カウント・ツールに機能が組み込まれていることも。

案件特徴

生産性変動要因

  • 企業で分析されている≒リスクである。
  • 生産性変動要因の例
  • 開発技術
    • 初めて使う開発技術
    • 生産性が 高い / 低い 開発技術
  • 顧客マター(上流)
    • 要件が固まらない(要件未確定)。
    • 仕様が出てこない(仕様未確定)。
    • 仕様膨張。
      生産性ではなく規模の話のように聞こえるが、
      下流工程でも膨張を続けるようだと≒仕様未確定で生産性も低下する。
  • 顧客マター(下流)
    • ユーザが「コレジャナイ。」と言う。
    • オーナーが「こんなはずじゃなかった。」と言う。
  • 最近は単純な案件が減り、
    変動要因が重要になってきている。

再構築(現新一致)の見積もり

スクラッチ開発の見積もりと似ているが、以下の点が異なる。

  • 現行システムと仕様書の乖離が見積もりのポイントになる。
  • 乖離が大きい場合、リエンジ後に見積もらないと危ない。

パッケージ・カスタマイズの見積もり

スクラッチ開発の見積もりとは、大きく異る。

  • 特徴
    • 要件 / 仕様が不明確なら段階的になるが、パッケージでは一括の慣例。
    • 一括になると、業務に詳しくないとカスタマイズの見積が不可能。
    • 結果、フィット&ギャップが十分でない状態で契約してしまうケースが多い。
  • ポイント
    • 一般的に、カスタマイズ規模が3割を超えると、≒新規開発と言われる。

移行・マイグレーションの見積もり

トピック

SE作業見積

ソフトウェア開発見積と異なり、ボトムアップ見積的に行う。

KKD(勘と経験と度胸)でエイヤの裏側

  • これは、「1画面、1K step、1人月」と言う感じの概算の見積もり方法。
    こう書くと、伝統的&属人的な、陳腐な方法に見えるが、
    PMBOKで以下に該当と言われるとマトモな方法にも見えてくる不思議
  • 昔ながらの開発では、恐らく、
    以下のような感じで概算可能。
    • 金融 / 公共系:1画面、2K step、2人月
    • 産業系:1画面、2K step、1人月
  • これが成立してしまう理由。
  • 「下限での見積」がSI事業の商習慣として慣例化しているため。
  • また、発生したバッファ工数が「パーキンソンの法則」で消費されるため。
  • 業種によって(、例えば以下のように)、
    WBSが異なり、形骸化など生産性が下がる事もある。
  • コレが、ナカナカ是正されないは以下による。
    • 「パーキンソンの法則」的
    • 事業者サイドにメリットが無い。

参考

Wikipedia

パッケージ・カスタマイズ

生産性事例収集項目例

SI事業と見積の関連


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2020-03-12 (木) 19:18:54 (25d)