商品の詳細

• Amazon.co.jp ランキング: #51604 / 本
• 発売日: 2007-11
• 版型: 単行本
• 155 ページ

カスタマーレビュー

改良開発における見積り方法論
新規システムの開発とは異なり、

　既存のシステムがある状況で新たな機能を開発・・改良開発における見積り方法。

　・・でも、いまどき、純粋の新規システムの構築の方がまれなので、参考になります。
　

　改良開発のコスト構造・・

　　・既存システムの規模
　　・既存システムの理解容易性

　　・保守性の水準

　　・機能の変更量・追加量　等々を、考慮した上で見積もる必要あり。

　また、新規開発との大きな違いは、

　　「機能量とテスト量の相関が新規開発に比べて低い点」

　　ｅｘ．ソースコード１行の変更でも、そのコードが含まれる機能が母体の多くの部分に関係する場合
　　　　　であれば、その変更の妥当性を保証するために、関係する母体全体をテストすることもあり。


　また、保守性は、当然ながら、以前のプロジェクトの品質に大きく依存すること。


　以上踏まえた、ジャステックさんの改良開発の構造を踏まえての見積りモデル、

　計数の想定や計算式の適用可否は判断必要ですが、見積り時の考慮の観点、とても参考になります。

　・・既に実施されている場合でも、内外への説明として、頭の整理に良いと思います。

見積もりが大切だと経営者の方からは教わりましたが
見積もりの事例は貴重です。各社がどういう見積もりをしているかがわかる。

ps.
ソフトウェア経済学という用語があったが、発想は斬新かもしれない。経済学が、膨大は論理とデータを消費する学問がもう一つ増えるのであろうか。

原価計算に基づかない見積もりに、どういう意味があるか、あるいは原価計算に基づいた見積もりをするが原価部分は公開できないということであろうか。
ソフトウェア開発の資源として重要なプログラマの原価の計算が十分でなく、性能（能力）の評価が十分でなければ、よいものは作れないのではないだろうか。
見積もりにおいて、誰が担当するかによって原価が違うはずであるが、顧客にはそれは知らせないのが慣習になっているのだろうか。

その他の課題としては、調達の基準である各種国際標準との関連が明確でない点である。
受入試験をどうやっているかによって、見積もりの精度が変化するかについての記述があるとよかったかもしれない。