Customer Reviews

Applied Software Measurement: Assuring Productivity and Quality

5 star:		(3)
4 star:		(0)
3 star:		(0)
2 star:		(0)
1 star:		(1)

 

 

Software engineering is not a discipline backed by science; it has many theories but few metrics and objective data to evaluate the theories. However, software must be built, people are hired to meet important business goals, and projects and careers are dependent on an accurate assessment of project factors. Jones' book supplies an objective way for software engineering managers to compare their projects against empirical data gathered from over 6700 software projects. The next time a manager challenges your effort and schedule estimates, you can turn to Jones' book (Chapter 3 is a must read for even time pressed managers and the charts alone worth the value of the book) and find the objective data to back you up. Neil Olsen

I bought this book as a suppliment to Software Engineering Economics, by Boehm, because of it's later publication date. However, once I read the book I believe that the Boehm should be a suppliment to this work. Before reading this book I was unfamiliar with function points. We are now implementing them in our company. If this book does not bridge the gap between technical and management it goes a long way toward that end.

It's hard to encapsulate in a few words what this book has done for me since I've started reading it. If you're part of any stage of your company's development cycle and care about the quality of the products you deliver ... this is a must read. Chris Showers Inmar Enterprises

I could neither read the book cover to cover nor expect anyone will accomplish this with sanity. This book is written as a text book that student will buy class notes instead or a self-promotion material which left untouched; Almost all supporting material are assembled from various sources. The author claim it's done to protect its customer's privacy but the result does not make sense and appear to be too much artificial. Besides the lack of "real" hard evidence to demostrate the author's theory, there are too many opinions from places to places. We don't assume a cause of an event by collecting opinions from a group of people. Only an controled experient can proof a theory. Over all the book is poorly written. However, it serve as a good weapon through corporate ladder. It can be uses in two way. Pick it up and hit someone. Its hard cover and weight can result a deadly attack. Otherwise one can pick up technical terms through out the book and make anyone in front of you shut up.

What's good about this book: The mention of function point vs lines of code. The importance of software measurement and it's value. Lastly, it provide you an template of basline report if the CEO ever ask.

What put this book useless: neither example nor explaination on how to calculate function point from a spec or project files. The detailed work require too much labor to accomplish.

Conclusion: a minimum software measurement is essential to evaluate a team's performance. a size of code / bug rate and few other key variables can show the quality and progress of an project. Thus a project schedule can be forcasted and updated. But we need to ask if the author had pushed the case to the extreme so the business solely based on selling measurment report like himself can exist and keep sucking our money.