Philippe Kruchten
Addison-Wesley, 2003 (3nd Edition)
Philippe Kruchten
Addison-Wesley, 2003 (3nd Edition)
ISBN 0321197704 (paper)
Buy it from Amazon.com
The Rational Unified Process (RUP) is one of the first serious attempts to put together an all-encompassing system development life-cycle that accurately embodies the object-oriented thinking that derives from the painful experience the software world had with functional analysis and design. The RUP is a major contribution to Systems Engineering thought, including Requirements Engineering and Management, Design, and Verification. No process is perfect, one size never fits all, and innovation - especially by an industrial player - is bound to be controversial, but the RUP is undeniably important.
This slim volume offers a short introduction to the RUP, in the same Object Technology Series as Fowler's UML Distilled. Unlike that book, this is all about process and goes into a lot more detail. The book covers a lot of ground, contains much good advice, and is written as if it was definitely right and suitable for all types of project. Plainly, its applicability cannot be so wide; substantial effort is required to follow each stage of the RUP -- up to 2 weeks to document a single Use Case (see Cockburn and Kulak & Guiney), according to Ian Graham's experience -- and many projects will choose to follow lighter, faster, and cheaper methods.
The style is dry (unlike Fowler) and basically just describes -- in the present tense -- each step of the unified process, or rather the set of sub-processes, known confusingly as workflows, that make up the overall process.
These workflow/processes take up the whole of part II of the book, and describe project management, business modeling, requirements, analysis & design, implementation (i.e. coding), testing, CM, environment (i.e. tool and process support for the developers), and deployment. All of these except the last are visualized as parallel streams -- requirements activity for instance may be most intense at the start, but it never tails away completely.
From this it is immediately clear that there is a lot here that is traditional, along with a clear recognition that things happen in parallel. Even the much-maligned waterfall model is given its due, before being carefully critiqued and dismissed. It wrongly assumes, says the author, that requirements will be frozen, and that the design can be got right before proceeding. The book's only noticeable flash of humour emerges when the "end user" reaction to prototypes is described as the IKIWISI effect, or "I'll Know It When I See It".
The discussion moves on to iterative life-cycles, prototyping, risk reduction, and not least the use of scenarios/use cases to identify stakeholders' goals and requirements.
The requirements process is just one of many parallel streams in this world. It is treated in reasonable depth, though naturally less than one would get in a book on requirements as such. The workflow is illustrated discreetly in a UML activity diagram (with extra icons for activities); other icons are invented for artifacts such as documents and models. This would represent unwelcome visual clutter, but for the fact that many pages of text are entirely free of graphics. People, known as Workers in Requirements, are subclassed into yet more icons (parallelogram-people rather than stick-men) with trip-off-the-tongue names like Use-Case Specifier, User-Interface Designer, and Requirements Reviewer. There isn't a Requirements Eliciter or Requirements Engineer though; the author stays with the traditional System Analyst -- not an ideal title for someone who analyzes problems and understands stakeholder needs before moving on to define a system that meets those needs.
This book should prove useful to project managers, lead designers and indeed people working on larger projects who want to start thinking about how they can organize their work better. It is at times dogmatic, admitting few if any other solutions, though many exist. It is reasonably short at just under 300 pages, but most readers will only look at a few pages at a time (one part of one workstream, for instance), so it has more of the character of a reference text rather than of a true introduction or tutorial.
© Ian Alexander 2000, 2001, 2004 You may also like:
Buy it from Amazon.co.uk
