This month we take a look at two recent books about building large software systems which both discuss User Interface Design and how it fits into the bigger picture of software development.

The books in question are not directly competitive. The first, Object Oriented Project Management with UML, by Murray Cantor is a book about building a project: a team and a process in order to build a large software system. The second, Practical Analysis & Design for Client/Server & GUI Systems, by David A. Ruble, is much more about system architecture. So in effect these two books are complementary. One tells you how to manage the analysis, design & construction and the other tells you how to go about analysis & design for front and back end systems.

Both books talk about User Interface, thankfully. So there is at least recognition that User Interface Design is important to the delivery of large software systems. So do these books arm you with what you need in order to deliver an attractive, intuitive, usable piece of software which meets functional requirements and minimises defects in User Acceptance Testing?

Object Oriented Project Management with UML

by Murray Cantor, Wiley, 1998

Cantor, we are told, has 10 years experience managing software development and after reading this book, I have no reason to doubt it whatsoever. This is as good a book on project management generically as ever I have read. Cantor walks us through the task of building a project: a team of people with diverse skills and a set of processes which will deliver a large software system. Early reference is made to Fred Brooks, "The Mythical Man Month" - always a good sign.

Despite the title referring to "Object Oriented", he quickly moves on to use the phrase Object Technology. A good indication that he's been doing this for real. We are walked through the basic principles involved in an OO system and warned of some of the dangers. We are introduced to UML as a common language for communicating the design as the first chapter bounces between technology issues and psychology issues. We hear about communication problems and about Product Teams of developers led by a chief programmer. There is an excellent section on team formation and the phases of behaviour - Forming, Storming, Norming, Performing.

The second chapter takes us into the land of UML and Rational Unified Process (RUP). We are introduced to Use Cases and Use Case Diagrams as a form of describing the requirements. As we move into the area of User Interaction, however, we hear nothing about UI Design. In fact UI Design doesn't get a mention until page 156. Half way through the book.

Architecture

In the first half of the book we hear about basic packaging of sub-systems. According to Cantor, this has to be done first, before you write the first schedule and before you start to properly analyse the requirement. We hear about design patterns for OO Modelling and attributes of a good OO Design. This is a pretty sound section and he correctly points out that keeping the code and design in synch is a real problem which needs solving.

Chapter 3 moves onto problem solving and gives us a description of the 4 basic phases which he uses to structure the book: Inception, Elaboration, Construction and Transition. An analysis of life cycle models is given and controlled iterative life cycle is chosen as the way to go forward. All good stuff. On page 100 we get a gant chart displaying the controlled interaction model, including User Level Use Cases, High Level Package Diagrams, Development Level Use Cases, Class Diagrams and so on. "Where is UI?", I hear you ask.

Process

Chapter 4 takes us away from architecture and into process. We hear about Capability Maturity Model (CMM), Software Development Plans (SDP), Work Breakdown Structure (WBS), scheduling, planning and Product teams. Superficially, this all seems very sound stuff, but I began to wonder. It all began to get a bit fuzzy. Product Teams are assigned to packages and product teams are given tasks from the Work Breakdown Structure, which we are told should be of around 3 months duration and tracked on a Gant Chart. But what is the basic unit of work? The Use Case. We also heard that Use Cases are no respectors of packages and that they often span packages. We also heard that a Scenario is a single pass through a Use Case and that several Scenarios can come from a single Use Case. So how are we tracking these smaller grained tasks and how do we resolve the issue of the Use Case across the packages? There is some mention of Product Teams to solve this problem using the Chief Programmer from each of the Package Teams but it is never totally clear.

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.

Inception

Chapter 5 is titled - "Managing the Inception Phase". So we are finally ready to start, after 165 pages. User Interface gets an early mention as we begin to talk about requirements.

Cantor correctly observes that most customers give you a design rather than a requirement. How often have you heard, "We need a workflow system." or "We need a Lotus Notes system."? He fails to state the obvious which is - make the Customer state the requirement - don't accept a design as the requirement. Though he does say that suggesting alternative designs is a good idea.

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. They are the User Interface Design.

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. Maybe we are talking about small systems - but this is a book about big projects!

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!

The definition of Usability on page 179 is surprising to say the least.

• Is usable. Can the use cases be executed, and have the stated performance requirements been met?
• Promotes user efficiency. Does the system meet unstated but essential performance requirements?

A little lightweight for my taste.

There is some excellent stuff on leadership in Chapter 6. Have your manager read it. The one that I thought was missing is

• A development manager needs to absorb the uncertainty which exists around the project and insulate the team from it.

Elaboration

Around page 210 the book moves into elaboration of the Use Case design and we hear about top-down and bottom-up UI 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

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.

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.

Construction

Chapter 7. moves us onto construction and talks about managing scope and assigning development priorities. It talks about features without clearly defining it. Is a feature a Use Case? Surely a feature is a Scenario - a path through a Use Case. We are told that we should prioritise Use Cases using a 2x2 grid. This is an excellent technique for defining the Risk vs Priority. We are not really told how to define the customer priority for a feature. Nevertheless, this is an excellent section and there is some sound advice.

Finally Cantor comes back to Leadership and describes how to be a "Low Pass Filter" to absorb that uncertainty I was talking about.

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? How do we model the UI Plumbing and connect it to other classes? None of this is addressed. MVC or Model-View separation doesn't get a mention.

Transition

That's it for UI. The book finishes with a sound discussion on User Documentation, Testing and Rollout issues.

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.

Recommendation

3/5 - Don't waste your own money. If you're a developer, get your boss to buy it. If you're a UI Designer, forget it.