The best thing about this book has to be its honest, real-world mix of software engineering theory and real-world practice for managing object-oriented software development. The author refuses to be doctrinaire and continually offers valuable nuggets of practical advice. Regarding the pitfalls of one software development process, he writes, "I am sure someone has succeeded, but I have never seen it done." Later, he advises managers to "never show panic."

The book doesn't skimp on specifics with a sample case study on a jet fighter trainer simulation system that has a budget of over $22 million. The book also provides real numbers for project estimation, bug tracking, and resource allocation. You'll even find numbers for measuring productivity, including KLOCs. Numerous sample documents (including sample meeting agendas) round out the tour here. The book offers plenty of good advice for working with upper management, customers, and development teams throughout the software development process.

While there's certainly no substitute for actual project management experience, Object-Oriented Project Management with UML may be the next best thing. The author's tour of how to manage object-oriented software development offers dozens of savvy tips and a very thorough guide to using some of the best available techniques for software management. This book is perfect for practically minded IS managers or project leaders who want to see how their software development process can be improved using UML with rigorous management techniques. --Richard Dragan

Topics covered: object-oriented project management overview; obstacles; UML basics; use cases; class diagrams; lifecycle models: waterfall, spiral, RAD; time box model and controlled iteration; Software Development Plans (SDPs); budgeting; project estimation; management tips for inception, elaboration, construction, and transition phases; software metrics: KLOCs and COCOMO; measuring productivity; and sample meeting agendas.

Traceability issues
Useful checklists and tables
Quantitative treatment (measurement)

Furthermore, the chapter on lifecycle models is not convincing. The author suggests that we should NEVER use the Waterfall model while he suggests that the Controlled Iteration model. Why? I have not understood this latter model when reading the boook. I think that it is too complex.

Concluding, this book serves as a baseline for further research and should be complemented by other sources, for example from Boehm, Air force and IEEE.

Finally, the title is an attention-grabber and in my opinion incorrect. Project management is independent of the technology used (in this case OOT). A better name would have been "Project management of software projects that use UML".

Recommended reading for those becoming involve in the development of larger, more complex systems.

The author uses a flight simulator example that is helpful both in understanding the evolution of a project and in some of the "unexpected" problems that crop up. He also describes how the various UML tools help in organizing and documenting the project.

This book is not so much about code as it is about management.

The books main thesis is that by using object-oriented approaches, UML and an appropriate methodology the new project manger is well prepared to be successful. Nothing could be further from the truth. Managing a software development project has very little to do with any of these.

Throughout the book we look in vain for proper treatment of the real issues a project manager faces: requirements elucidation, senior management involvement, change control, risk management, user involvement, etc. Where these issues are not ignored they are dismissed in a few lines. To find out why projects succeed or fail all managers should read the CHAOS report.

Despite its title the book seems curiously dated. Many of its claims were also made about structured methodologies nearly twenty years ago. Here are some examples.

In the Introduction the author boldly states "..we in the industry really do know how to manage software development." This is beyond positive thinking and way into deep denial. Where ever you go and what ever group of users you ask, by and large the response is the same: most software sucks. We remain very bad at managing software development.

We are also told "..developers are still the best source of software managers". Rubbish! There are certainly cases where developers have become good software development managers. However for the most part, good developers are miserably unhappy and fail to perform well as managers. Developers who become managers often do so because they have false idea of what they will be expected to do. A false idea that’s perpetuated by books like this.

On the plus side, the book contains numerous references many of which new project managers would benefit from reading.