DNET_ServiceEstimation - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki

見積

概要

見積とは...

詳細

分類

以下のような分類がある。いずれも 時間の該当節を参照。

  • 類推見積（トップダウン見積）
  • パラメトリック見積
  • 三点見積
  • ボトムアップ見積

ソフトウェア開発見積

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

FP法

（ファンクションポイント法 / Function Point method）

  • パラメトリック見積の一手法

  • ソフトウェアがもつ機能数を

    • 点数付け、
    • 複雑さによって重み付け、

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

  • トレード・オフ

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

オレオレ法

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

ステップ規模見積

  • パラメトリック見積だが、
    企業 / 組織 / 個人の程度の差はあるもののオレオレ法ではある。

  • 以下の事例情報が、企業 / 組織 / 個人に、
    多数、溜まっていることで見積もりが実現可能。

    • 案件特徴
    • 工数 / 原価
    • ステップ規模

  • ステップ規模

    • ステップ・カウント・ツールなどを用いて算出する。

    • 開発言語 / フレームワーク / ツールによって影響を受ける。

      • ステップ規模が大きくなる。
        ・Webアプリケーション
        ・低水準言語
        ・フレームワークの未活用
        ・自動生成の使用

      • ステップ規模が小さくなる。
        ・C/Sアプリケーション
        ・高水準言語
        ・フレームワークの活用
        ・EUCツールの使用
        ・自動生成の不使用

    • ローカル・ルール
      ステップ規模の測定には、ローカル・ルールが多いが、
      事例内のルールが統一されていないとデータの利用が難しくなる。

      • SQL (DDL / DML) は測定しない。
      • 画面定義、帳票定義は測定しない。
      • （DHTML時代の...死語）JavaScriptは測定しない。

    • 新規開発規模以外のステップ規模算出式

      • 流用、改造等などを考慮する。
      • ステップ・カウント・ツールに機能が組み込まれていることも。

案件特徴

生産性変動要因

  • 企業で分析されている ≒ リスクである。

  • 生産性変動要因の例

    • 開発技術

      • 初めて使う開発技術
      • 生産性が 高い / 低い 開発技術

    • 顧客マター（上流）

      • 要件が固まらない（要件未確定）。
      • 仕様が出てこない（仕様未確定）。
      • 仕様膨張。
        生産性ではなく規模の話のように聞こえるが、
        下流工程でも膨張を続けるようだと ≒ 仕様未確定で生産性も低下する。

    • 顧客マター（下流）

      • ユーザが「コレジャナイ。」と言う。
      • オーナーが「こんなはずじゃなかった。」と言う。

    • プロジェクト・マネジメント上の悪循環（負のスパイラル）

  • 最近は単純な案件が減り、
    変動要因が重要になってきている。

再構築（現新一致）の見積もり

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

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

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

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

  • 特徴

    • 要件 / 仕様が不明確なら段階的になるが、パッケージでは一括の慣例。
    • 一括になると、業務に詳しくないとカスタマイズの見積が不可能。
    • 結果、フィット＆ギャップが十分でない状態で契約してしまうケースが多い。

  • ポイント

    • 一般的に、カスタマイズ規模が3割を超えると、≒新規開発と言われる。

  • 参考

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

  • スクラッチ開発の見積もりとは、大きく異る。
  • 例外的に、ボトムアップ見積的に行う。

トピック

SE作業見積

ソフトウェア開発見積と異なり、ボトムアップ見積的に行う。
（PMセミナーの該当節を参照）

KKD（勘と経験と度胸）でエイヤの裏側

  • これは、「１画面、１K step、１人月」と言う感じの概算の見積もり方法。
    こう書くと、伝統的＆属人的な、陳腐な方法に見えるが、
    以下に該当と言われるとマトモな方法にも見えてくる不思議

  • 以下のような感じで概算可能。

    • 金融 / 公共系：１画面、２K step、２人月
    • 産業系：１画面、２K step、１人月

  • これが成立してしまう理由。

    • 「下限での見積」がSI事業の商習慣として慣例化しているため。

    • また、発生したバッファ工数が「パーキンソンの法則」で消費されるため。

    • 業種によって（、例えば以下のように）、
      WBSが異なり、形骸化など生産性が下がる事もある。

    • コレが、ナカナカ是正されないは以下による。

      • 「パーキンソンの法則」的、サプライ・サイドにメリットが無い。
      • サプライ・サイドに無理をさせると品質に影響が出る。

  • 参考

参考

Wikipedia

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

生産性事例収集項目例

SI事業と見積の関連

Tags: 移行, サービス, 見積, 開発基盤

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

⚠️ **GitHub.com Fallback** ⚠️