Software Engineering Economics (Prentice-Hall Advances in Computing Science & Technology Series) (英語) ペーパーバック – 1981/10/22
Kindle 端末は必要ありません。無料 Kindle アプリのいずれかをダウンロードすると、スマートフォン、タブレットPCで Kindle 本をお読みいただけます。
Software Engineering Economics is an invaluable guide to determining software costs, applying the fundamental concepts of microeconomics to software engineering, and utilizing economic analysis in software engineering decision making.
Personally I especially likes the Part III and Part IV which were about the factors changing the software estimate and the reasons why. The last chapter of the book is something everyone should read who is working in quality/process management and is trying to improve productivity of a large project.
Still a classic and worth reading!
The COCOMO model is calibrated by industry data and expert opinion. Given module size estimates in lines of code as input the COCOMO model will predict effort and schedule in man-months. The COCOMO predictions cover the plans, product design, programming, and integration & test portions of the life cycle. The validity of the model is illustrated by charting actual vs. COCOMO prediction and the detailed analysis of the COCOMO cost driver attributes in Chapters 24-26. Product attributes are required software reliability (RELY), data base size (DATA), and product complexity (CPLX). Computer attributes are execution time constraint (TIME), main storage constraint (STOR), virtual machine volatility (VIRT), and computer turnaround time (TURN). Personnel attributes are analyst capability (ACAP), applications experience (AEXP), programmer capability (PCAP), virtual machine experience (VEXP), and programming language experience (LEXP). Project attributes are modern programming practices (MODP), use of software tools (TOOL), and required development schedule (SCED).
Readers should be aware that some aspects of the COCOMO have been replaced by the publication of the "Software Cost Estimation with COCOMO II" book. The "COCOMO II" book contains a preface section titled "Relation to 1981 Software Engineering Book". I recommend keeping a copy of this preface handy while you read "Software Engineering Economics" because it provides a chapter-by-chapter assessment of the relevance of the "Software Engineering Economics" content in the year 2000.
HOWEVER, it must be kept in mind that the book itself is somewhat outdated - COCOMO 81, as defined by Barry Boehm, has been overtaken by new technologies and in particular by the surge in PCs & the Internet. The basic model is still valid - I still use it myself - provided you are aware what the background in computing was when it was written, and you carefully assign the adjustment factors.
Barry Boehm himself recognizes that COCOMO 81 is no longer valid - hence his collaboration with COCOMO II, which has addressed many of the problems that affected the old COCOMO 81 (e.g., it was mainly thought for development of software on expensive mainframes, and development tools have greatly evolved since that time). Still, I insist, if you are careful when making your estimations, the model and the techniques presented in this book are very useful and could be applied even on more modern projects.
My second HOWEVER is related to use the model presented in this book for Software Maintenance purposes. Though the book has a chapter on this issue, by opinion is a radical NO-No on this particular issue. COCOMO 81 (as presented in this book) and COCOMO II are adequate for software development purposes. I totally disagree that they are adequate for software Maintenance purposes (though COCOMO II is at least not so very bad). Apart from the fact that it ignores things such as regression testing, or the number of releases to be made during such maintenance, it also ignores the fact that software "degrades" during such maintenance - subsequent modifications introduce more and more stress on the original design, until at a certain moment the software requires a great "overhaul" in order to solve a lot of patchwork that has accumulated over the years. Hence the typical case of having to redesign a complete new software system because maintenance of the old system becomes too expensive.
In any case, if aware of such limitations, I can highly recommend it.