- Paperback: 304 pages
- Publisher: Prentice Hall; 1 edition (June 4 1986)
- Language: English
- ISBN-10: 0131717111
- ISBN-13: 978-0131717114
- Product Dimensions: 17 x 1.4 x 24.8 cm
- Shipping Weight: 522 g
- Average Customer Review: Be the first to review this item
- Amazon Bestsellers Rank: #2,885,957 in Books (See Top 100 in Books)
Controlling Software Projects: Management, Measurement, and Estimates Paperback – Facsimile, Jun 4 1986
No Kindle device required. Download one of the Free Kindle apps to start reading Kindle books on your smartphone, tablet, and computer.
To get the free app, enter your mobile phone number.
From the Back Cover
Controlling Software Projects shows managers how to organize software projects so they are objectively measurable, and prescribes techniques for making early and accurate projections of time and cost to deliver.
No customer reviews
|5 star (0%)|
|4 star (0%)|
|3 star (0%)|
|2 star (0%)|
|1 star (0%)|
Review this product
Most helpful customer reviews on Amazon.com
While following a reading of this book this reviewer still recommends "Software Estimation: Demystifying the Black Art" by Steve McConnell (see my review) as the best overall project estimation text, what is appealing to this Six Sigma practitioner are the metrics presented throughout this text even though McConnell indicates that many of the early metrics that are still being referenced within the industry were harvested from large government projects. Metrics can be compelling, but it helps to understand that there are many different types of software development projects taking place in many different corporate cultures, and "Balancing Agility and Discipline: A Guide for the Perplexed" by Barry Boehm and Richard Turner (see my review) interestingly enough co-written by the individual who wrote the forward for the object of this review 20 years prior can greatly aid leadership in this industry as they choose which direction to take in this regard.
While the content in this book is well connected throughout, DeMarco discusses four main areas that are each dedicated a section in the book, although the largest amount of text is dedicated to the second section: (1) "Chaos and Order in the Software Development Process", (2) "System Models and System Metrics", (3) Cost Models, and (4) Software Quality. Some of the questions that DeMarco addresses might be posed as follows: What does it mean "to control" a software development project? What is estimation and how can it be approached effectively? How can project costs be projected into the future? How are metrics generated and who should do this work? What long-term benefits can be provided by a cost model? What exactly does software quality mean and how can related goals be achieved? The author also provides four appendixes, but in the opinion of this reviewer only the third, entitled "A Tailored Primer on Statistics", is suggested reading.
While less than 300-pages, this book covers a lot of ground. While the author carefully lays out his approach on how to gather metrics in the second part of the book, it is obvious from a year-2010 perspective that this method relies much too heavily on the classic Waterfall software development methodology, and so this part of the book should only be given a cursory reading. Some of the material in this section is beneficial, but harvesting this information is like separating the wheat from the chaff. In other words, while still taking into account the excellent conversational writing style of the author, the reader is advised to read other material such as that found in texts sited earlier in this review. Because DeMarco offers so many great diagrams in this book, a possible way to explore this third section is by looking at these diagrams to determine whether reading the surrounding text is worthwhile. The fourth section on quality does not seem to belong in this book, even if it were not for its lack of inclusion within the subtitle. The other two sections were well received by this reviewer, especially the first.
At the outset, DeMarco is entertaining by presenting the default definition of "estimate", which he writes is "the most optimistic prediction that has a non-zero probability of coming true", and his proposed definition of "estimate", which is "a prediction that is equally likely to be above or below the actual result". In addition, the author exposes one chief villain of accurate estimates: corporate policies that use estimates to create incentives. As the author explains, "when such a policy is allowed to prevail, the estimation process is nothing more than a charade. Whenever estimates are required, the person requiring them is not truly interested in the estimator's probabilistic assessment of when the work will be done or at what cost. Rather, the 'estimator' is being asked to establish goals for performance. In many cases, it's even worse: The 'estimator' is being asked to accept previously established goals. And what shall the characteristics of those goals be? If they're going to serve real prods for the development process, they have to be totally unachievable."
If you do not have time to sit down with this book for long periods, this reviewer recommends that the latter portion of chapter four where the author discusses five objections to empirical software projection be read at a minimum: (1) "We don't have the data. Without that vaunted bluebook, the metal extrusion estimator would be nowhere. That's where we are." (2) "Even if we have the data, we haven't got anything to correlate it with. What can we use as the early measurable indication of size? (If you say lines of code, I'll scream.)" (3) "Each software system is different. You can't use data about developing small on-line systems in PL/I with experienced people to project results for a development of large batch systems in assembler by novices." (4) "The data don't converge. The tolerances will be so wide that no one will accept the results." (5) "Upper managers won't accept the projected numbers because the figures will be too high. The worker bees won't work as hard without unreasonable numbers to strive toward. Everybody's ego will be offended by the idea that the work is predictably doable and that people's efforts are interchangeable."
As this reviewer wrote the list in that last paragraph, he was reminded of some of the technologies mentioned by Frederick P. Brooks, Jr. in his classic work entitled "The Mythical Man-Month" (see my review). "PL/I"? "Batch systems"? "Assembler"? As this reviewer mentioned in his earlier review of "Object-Oriented Technology: A Manager's Guide" by David A. Taylor, "the next language of the day/week/month/year" will come and go soon enough.
But this book has not aged as well as, say "Mythical Man Month" or "Death March". Don't get me wrong - I am giving it 4 stars because it is still full of excellent material; you just need other, more 'modern' references to help give this book perspective. With the proper perspective, this book really helps explain "The more things change, the more they stay the same", something that is often forgotten in this fast moving field.
The context that this book needs today is that of a given 'methodology', whether that be Extreme Programming, Scrum, Unified Process, or CMMi. If you don't have a model in mind, I would start with the book "Agile Software Development, Principles, Patterns, and Practices", by Robert Martin.