I would appreciate it if you would post this response.

Thanks,

Murray

----------------------------------------------

Review of Object-Oriented Project Management with UML by Murray Cantor -
Author's Response

While every author has to be ready for a uncomplimentary review, I was really surprised by some of the points taken in the review. I am appreciative of the many positive comments in the review about general project management. It seems to me that many of your negative comments are simply a misreading of the book. While I surely share some of the blame in this - I could have possibly been clearer - I feel it is important to set the record straight.

First of all, in spite of your impression, I have successfully managed OO projects using the techniques and processes in the book. The OO discussion is not an overlay. The entire process I describe is Use Case Driven and takes full advantage of object features such as encapsulation. I go to great length to discuss how object technology is the enabler for effective software project management (Chapter 1). Further this book is the first to document how to employ use cases to assign requirements to subsystems. This technique of use case flow down has been automated by Blueprint Technology (see their URL http://www.blueprint-technologies.com ) The book was not written as a text on UI development. That said, I am comfortable that the book places the UI effort well in the big picture, given the level of detail of the text.

We clearly have subtly different views on the role of UI in the development of a large project. This is a basis for further discussion and debate.

In the following I explicitly address some of the concerns raised in the review. Your words are in italics; mine are in bold.

He fails to point out that the requirement is to be written as Use Cases and they are a design - they describe the User Interaction with the System.

This is dead wrong, see pages 50, 52, 114 and many others

They are the User Interface Design.

I do not agree with this statement, in UML terms the UI realizes the use cases.

Throughout the book, we are guided by a worked example of a Military Flight Simulator problem. It would be nice to think that such a system had been built with the process described. Realtime systems like the one described are a hard problem for OO Design and a hard problem to describe in Use Cases. However, I failed to be convinced Yes, but not impossible. Modern simulation design is object-based. I validated the architecture with experts. I purposely chose a hard problem. I also chose a large problem to show how the methods do in fact scale.

Although he doesn't say so, he does know that this is a problem and suggests the solution is to introduce the UI Designer early and to prototype the UI. The prototype UI is then used to refine the UI design before the requirement is signed off by the customer. Suddenly I began to phase out again. Is it truly possible to design the whole of the UI for a big system and get it signed off before development starts? Surely not.

Of course not, but this is not what is said in the book. You are referring to the text on 177. The book says that it is important to have a prototype user interface for review and comment at the end of the inception phase. This is to determine if the intent of the phase is captured - agreement with the customer on the scope of the effort. It is important to determine early in the development if the UI is in line with the customer needs and expectations. I never state that the customer needs to sign off, only that issues are recorded to be addressed in the ongoing development. The hope is that it is sufficiently correct that the developer and the customer are comfortable that they are on the same page and what is needed is refinement. The interface is reviewed again at the end of the elaboration phase and the as needed throughout the construction phase.

I found his next suggestion surprising. He proposes putting a UI Designer in each Product Team which has a UI requirement for their package. Good work for all us UI Designer, I hear you cry. Then he suggests that a committee of all of these guys plus a Domain Expert and the lead Architect co-ordinate the UI Design so that it is consistent across the project. Hmmm. This breaks one of the golden rules from Fred Brooks, "The Mythical Man Month" - only one Architect!

This is one of the scaling techniques. Nothing that wrote here is in conflict with Brooks. If you review my staffing recommendation there is still a single lead architect.

Around page 210 the book moves into elaboration of the Use Case design and we hear about top-down and bottom-up UI Design.

Actually this section is on general class design.

CRC cards are used for bottom-up design. They have been shown not to scale to large system, so again I was left wondering, if we are talking about small projects

I agree that CRC cards do not scale to large projects, but they are useful if used along the flow-down techniques I discussed earlier

During this phase, we again hear about refining the User Interface and refining the Use Cases to keep them in synch with the UI. But what if the Use Case concerned has been built already?

Next we hear about packaging and class files. Earlier we had heard suggestion that the UI be prototyped in Java but Cantor shows that he knows little about it when he fails to point out that in Java every public class has its own file.

I have written code in JAVA and managed JAVA development. I do not see this detail as relevant.

Elaboration concludes with a Design Review. Strangely User Interface comes almost at the end of the review but we earlier heard that it was the input to the Use Cases. This just didn't make sense.

There is nothing strange here, the UI is not the input to the use case, the UI is not the use case, the UI is an aspect of the implementation of the system that realizes the use case. It should be reviewed and refined in the elaboration phase.

On page 259, we finally read about User Interface Development. It takes him all of 10 lines to say all that there is about this topic. It's far too light. Are we building Use Cases, Scenarios, Features, Classes? How do we go about it? How does it fit with the other parts of the system? How do we get incremental build testing?

All of these questions are addressed, In particular see pages 268-275, also see page 259-260.

How do we model the UI Plumbing and connect it to other classes?

This is addressed from a management point of view in the section on Horizontal and Vertical Development, pp. 257-8. The technical issues are beyond the scope of the book.

Summary
320 pages, 1" thick. An excellent book on Software Project Management, Team Leadership, Psychology in both software development teams and customer to team relationships. An insufficient book on how to manage a big OO project and too vague on how really to deal with Use Cases. The book gives me the impression that Cantor has managed some large projects but none of these were OO. He tries in the book to scale small size OO techniques up to large projects and the whole thing fails to gel together. It's also a very poor book on how UI fits into the big picture. Gives me the impression that the pieces on User Interface were grafted on later and that the author doesn't fully understand it. No surprise there!

You have ignored the techniques in the book that explicitly address scaling including use case flow down, and the management of the microschedules. The thought that I grafted the UI issues after writing the book makes no sense. I can't imagine a chain of events that would lead to me doing that. I simply described the UI development along with the other issues of project management. If you feel that the management of UI development needs more detail, it sounds like a great topic for a different book!