ユーザーのためのシステム開発の見積もり評価 の商品レビュー
いくつかの見積もり手法を知れてよかったです。 ただ、複雑で、作成とレビューに膨大な時間が必要になります。それに経験値が高くないと作れないです。 半自動化でもない限りやろうと思わないです... それ以前に、作っても評価できるクライアントがまれで、ほとんどのクライアントにとっては大量...
いくつかの見積もり手法を知れてよかったです。 ただ、複雑で、作成とレビューに膨大な時間が必要になります。それに経験値が高くないと作れないです。 半自動化でもない限りやろうと思わないです... それ以前に、作っても評価できるクライアントがまれで、ほとんどのクライアントにとっては大量の項目と数字と記号が並んでいて、ちゃんとしてる感じがするだと思います。
Posted by
システム発注を行う際にベンダーが提示する金額が妥当か?を見極めるために、見積もりの勘所が記載されたユーザ向けの本。 文章構成自体は読みやすく適宜図も挿んでいるのですが・・・具体的事例にかけるため、「なるほど!」とところどころあるものの実際に生かせる部分があるかはちょっと微妙。 ...
システム発注を行う際にベンダーが提示する金額が妥当か?を見極めるために、見積もりの勘所が記載されたユーザ向けの本。 文章構成自体は読みやすく適宜図も挿んでいるのですが・・・具体的事例にかけるため、「なるほど!」とところどころあるものの実際に生かせる部分があるかはちょっと微妙。 ただしシステムの見積もりはどのような事が行われているか?という部分には、中々は発注する(ユーザ)側は見えないと思うのでそういった概略を掴むにはよいと思います。 あと参考資料として掲載されていた、生産性データや公開資料は知らなかったのでここは非常にためになりました。
Posted by
ITプロジェクトで一番大変な準備、計画フェーズ。 その前段階となる見積もり部分について書いた本。 具体的にこうすべき!というハウツー本ではないが、 どんなことに気をつけて見積もり作成、評価をすべきかは 読み進めていくことで分かります。 【参考になったこと】 ・評価の際に意識す...
ITプロジェクトで一番大変な準備、計画フェーズ。 その前段階となる見積もり部分について書いた本。 具体的にこうすべき!というハウツー本ではないが、 どんなことに気をつけて見積もり作成、評価をすべきかは 読み進めていくことで分かります。 【参考になったこと】 ・評価の際に意識すべきは機能網羅性 実際には非機能、マネジメント工数等も意識するべきだが、 何よりもまずは機能網羅性の確認から。 ・成果物スコープは、規模見積もりに繋がり、 プロジェクトスコープは、工数見積もりに繋がる。 ・規模見積もりには様々なメトリクスがあり、 それぞれ一長一短がある。 後フェーズでの実績管理も含め、メトリクスは1つに絞り、 評価として別メトリクスも使って見積もることが大切。 主なメトリクス: SLOC, FP, 画面・帳票数, ユースケースポイント, ドキュメントページ数 ・FP法の簡単な手順 ①ソフトウェアの機能抽出 ②抽出した各機能の複雑度を判定 ③複雑度に応じた点数付与 ④点数を積算 ・FP法で点数化されない項目は以下 処理ロジック(検索・紹介、チェックエラー処理、複雑な計算) 非機能要件 技術要件 上記については積み上げで見積もる必要があり、 見積もり段階からWBSを作成すべきである。 ・機能要件+非機能要件+技術要件+プロジェクト特性に 対して、リスク費を積むことで見積もりは完成する。 このうち、FP法にて算出出来る部分は機能要件部分のみ。 ・WBSを評価するときのポイント ①必要な作業が漏れていないか ②役割分担が明確かつ妥当か ③非機能要件、技術要件、プロジェクト特性の実現方法が妥当か
Posted by
- 1