Customer Reviews

Object-Oriented Project Management with UML

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

 

 

There is no doubt that this book is very good for somebody, who is going to start working in a software engineering environment. However, there are a couple of points which indicate that one should look around before deciding upon a purchase. (Even with the current price of 24 $)

Here are my points of concern:

- The chapter on object technology is really a half-hearted introduction and not very useful for getting started in this field.

- The book relies heavily on just a few references. Those references are recommended repeatedly. One of them is the doubtful 'Journey of a Software Professional' (Hint: Check out the mixed reviews.)

- The author can't resist recommending the 80-20 rule throughout the different project phases. This is hardly inventive and adds to a certain degree of repetitiveness.

- The case study is more entertaining than informative.

- The third part of the book (consisting of only one chapter) simply gives the impression that the book was rushed out for print.

I am not quite sure why this book merits a hardcover and on some occasions throughout the book, I could not help thinking that the layouters tried to increase the number of pages by adding a few commentary boxes ('Tips') here and there and enlarging diagrams to 'poster-size'.

Despite all those complaints, I have to say that the book helped me to gain an overview of the management process of a software product. But, after my first reading, it now gathers dust on the bookshelf ...

Murray Cantor's Object-Oriented Project Management with UML is of value to both the young manager looking for guidance and the seasoned manager looking to ground one's practices. The book is an engaging read that blends best practices with personal opinions. The author is careful to distinguish his personal opinions from the rest of the text and is conscientious to appropriately cite the work of others. Some 70 plus references are listed in the bibliography. In fact, what comes across is Mr. Cantor would prefer software managers to have a repertoire of books on one's shelf. I myself keep returning to Walker Royce's Software Project Management, a Unified Framework, Grady Booch, James Rumbaugh, and Ivar Jacobson's The Unified Modeling Language User Guide, as well as Mr. Cantor's O-O Project Management. Managing great software teams within projects is tough in today's environment of complex solutions, anxious customers, and shrinking time-to-markets. It takes more than just common sense. It requires a game plan and an awareness of when to be flexible. Mr. Cantor lays out a series of methods that focuses on attacking project complexity, leveraging team dynamics, and what needs to be accomplished when in the controlled, iterative development lifecycle. The underlying theme is risk management. Software projects will likely be adventurous for the foreseeable future as we seek ever larger scale systems, but if more engineers and customers were grounded in the techniques espoused by this book a lot more businesses would achieve their goals.

This book cannot be recommended. Experienced project managers will find a better and more balanced treatment of these topics elsewhere, while neophytes will be seriously misled about the role of a project manager and his responsibilities.

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.

The UML is an OO notation that has many views. I have been following developments in the UML for about two years now, awaiting the acceptance of the industry. You see, the UML by itself is not a software development methodology. It is simply a collection of notations and views of software development. Dr.Cantor's book takes the UML in the direction of a solid project management methodology by applying a minimal set of OO notations, views and other techniques. The major view in his methodology (and rightfully in my mind) is the use case because it is easily understood by anyone (even your grandmother). Surprisingly, he extends the application of use cases to multiple levels (user, developer, and package) and as a result provides a technique that should actively engage the client throughout the life-cycle of the project. As a practical matter, he ties the use cases back to the design artifacts that OO developers create on their way to writing code. Without these artifacts (class diagrams, sequence diagrams, and methods) and the source code, the use cases are merely documentation. His methodology is well rounded and also minimal. Thus, the project manager does not need to design the entire project to make estimates of effort and time. In addition, it is clear from his real world examples, the simulator case study, and suggestions for project reports, forms, and graphs that he speaks from the experience of having tested his OO methodology on medium and large scale systems. If you are a practicing software developer, a project manager, or a wanabee project manager, or like me, a college instructor, and are interested in learning how to apply OO techniques to project management, this book is for you.

I found this book very useful because it covered UML nicely, and did so in the context of real-world project management scenarios. The book is full of useful tips on how to improve your next PM experience.

The author applies standard project management techniques to object-oriented projects. In particular, the assumptions and techniques underlying UML and the Unified Process are to be found in the various chapters in the book. For example, the author advocates managing complexity by using packages, use cases, encapsulation, inheritance and aggregation.
The main strengths of the book are: It attempts to integrate OOT with project management techniques using the standard UML and this integration process lasts for the duration of the full software lifecycle.
The book may or may not be useful depending on what you are looking for. For example, it is (very) superficial in places and in general I would say that it lacks 'meat' in the following places:

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".

This was very useful for me to get a tactical grip on OO proj mgmt. Has a very good intro and is designed in modules to allow you to read based on your specific role in the group. Always recommend this to customers who are trying to move to iterative development.

Having been dumped into a first-time management situation, I found this book helpful in understanding the group dynamics, the steps to follow and the problems to expect. The next time I'll probably remember what I learned here, but probably I haven't absorbed it all, so will browse it again.

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.

This no-nonsense book is a must read for the project manager of large software systems who embraces - or is contemplating embracing - object-based development. Cantor skillfully shares a plethora of knowledge, experience and wisdom for planning, buiding, tracking and delivering your next software product

This book is not a book written by someone for the purpose of money. Dr. Cantor gives the reader his valuable experiences and insight. If you really understand what he tries to teach you, you will be a first-class software engineer or project manager. If you can implement the fly simulator example in the book by youself, you will even more appreciate his book.