The book begins by outlining the "traditional" waterfall approach to software development. The author looks at what changes for management when it comes to today's iterative software processes. Written with an eye toward management (with plenty of tables and figures for project estimation and planning), the author takes you through common pitfalls of managing software.

Besides reviewing older studies and metrics, the author offers his own 10 principles to managing software, along with hints for all facets of development, from initial inception to construction and deployment of software. The author provides detailed project milestones and other deliverables to help you manage software better, including a breakdown of tasks for your team that will help maximize your efficiency.

After a look forward at what better software management means for return on investment (ROI), the author presents several very useful appendices, which include software metrics (like COCOMO), as well as a description of the CCPDS-R missile command system (which used many of the author's management principles). Overall, this groundbreaking title will be useful to any software manager or project leader seeking to get control of software costs and improve team efficiency. --Richard Dragan

Conventional software engineering is first presented, along with its drawbacks. The changing software landscape is examined, and future success factors are identified. The factors are then tied into the new process.

Thorough coverage of many different angles, including an excellent section on metrics, estimation models (and the evolution of COCOMO), team development, culture changes, etc.

Great read.

That being said, the "process framework" hinges on iterative development. The author does a good job of showing why the traditional waterfall process does not work in today's environment, and this is applies to all organizations.

Then the author goes on to outline how software development breaks down into phases and iterations within phases. He also talks about the activites and artifacts that belong in each phase. Additionally, he talks about how organizations should be structured to support the process and how to taylor the process to a specific organization.

The case studies support the claims made throughout the book making it well rounded and logically sound. This process will work very well in the correct situation.

The highlights are:
* A project life cycle and process framework that is [obviously] closely aligned to the Rational Unified Process (RUP), and can be fitted to any rapid development or iterative approach.

* An excellent tutorial on effective project controls, with an emphasis on earned value project management.

* In-depth coverage of estimating techniques, with a lot of material on the constructive cost model (CoCoMo), and current gaps in estimating techniques and to where the craft and science of estimating and software economics needs to evolve in the discussion of next-generation cost models. I especially like his distinction between the use of source lines of code metrics for size and function points for scale. There is middle ground.The treasure trove of metrics, including core project metrics, and the change metrics that are given in Appendix C.
There is one glaring flaw in this book and an experienced project manager will quickly spot it: the proposed approach to basing work breakdown structures on project phases instead of the decomposition of the system to be delivered will not work. Using Royce's approach there is no clear way of integrating the work breakdown structure with the organizational breakdown structure. Using earned value techniques (which is well covered elsewhere in the book) Royce's approach will not align control accounts (sometimes called cost accounts), making his recommendations contrived and unworkable.

This book is better suited for an architecture-centric approach to project management, which means that it's more applicable to product development instead of internal IT projects. However, all seasoned PMs will learn much from it.

I gave it a 4.5 star rating as at times Royce spends too much time on some personal favorite topic of his. But at no point is this book un-interesting.

All in all, Royce makes a good read out of a tough subject. This is not, however a book for the inexperienced software manager. You truely need to have gone through projects of various sizes and some tough project management before you begin to understand the book. Royce's book serves to fortify and aid what the software manager has experienced, enlightens managers on why software is the way it is, lists out pitfalls to expect, standards to follow. A rather good manual for the tough job of a software project manager.

"The message rings out clearly: software development as a realm of individualized creativity and exploration is now a thing of the past. Software companies must impose conformity and Taylor-like authoritarian control. Software developers should be made to realize that they are nothing more than cogs in a wheel, and that management is justified in intervening in every aspect of their working life."

As a programmer and project manager, yes, this is the case. And it should be the case. The roles don't necessarily mean two different and distinct people always, but programming is a commodity function in large software projects. At least those that wish to be successful.

For example, would you rather fly on a plane whose systems were programmed and managed by a group of software engineers each of whom was free to exercise his or her own "individualized creativity and exploration" or a group that used Royce's work in managing the project?

I'll be on the latter plane thanks.