Common Mistakes and Misunderstandings

or, How to Fail with the Unified Process

There are internal IT organizations, books, Web pages, articles, consulting organizations, and speakers that demonstrate these misunderstandings. Be cautious in receiving UP advice or hiring consultants, and apply the tests in the "Signs the UP "Expert" Is Not an Iterative Expert" section on page 198.

Superimposing Waterfall Ideas

The most common of the significant UP misunderstandings, and a quick sign that the UP "expert" actually is not, is to describe the four phases akin to the waterfall phases (requirements, design, implementation, test):

1. Inception requirements analysis, detailed specifications.

   THIS IS INCORRECT; it is a sign of misinformation by those not truly understanding the UP

2. Elaboration more detailed requirements analysis, modeling, and design work.

3. Construction programming the design.

4. Transition testing.

This incorrect description of the UP phases illustrates the most common misunderstanding: superimposition of waterfall phases onto the UP. A corollary of misapplying the waterfall phases includes other common waterfall mistakes in UP adoption:

• Attempting to do most requirements analysis or design before programming.

• Deferring major testing or QA till near the end of the project.

Other Common Misunderstandings

Error: Iterations too long It is usually a misunderstanding to define iterations of several months long. The UP recommends an iteration length between two and six weeks, excluding massive projects involving hundreds of people and many subteams. Skilled iterative project leaders strive towards shorter timeboxed iterations in the two to four-week range, all other things being equal. One project may be composed of dozens of short iterations.

Error: Iterations aren't timeboxed It is a misunderstanding to let the iteration length expand when it appears the goals can't be met within the original timeframe. Rather, the usual expert strategy is to remove or simplify goals for the iteration.

Error: Iteration doesn't end in an integrated and tested baseline An iteration is not properly complete unless all the software, across all or most subteams, has been integrated, tested, and baselined. It is a misunderstanding to think an iteration simply ends arbitrarily on the end date; the goal is to pull everything together.

Error: Each iteration ends in a production release It is a misunderstanding to think each iteration must end in a production release. Although this is possible (especially during maintenance) it is less common than requiring many iterations before a production release.

Error: Elaboration phase goal is to create a throwaway prototype Prototypes are perfectly acceptable in the UP (usually during inception), but the goal of elaboration is not a throwaway prototype but rather a production subset of the final system. Some have misunderstood this (and some UP books have misadvised on this point) because the original UP and RUP literature itself used the unfortunate choice of phrase "architectural prototype" in a few places to describe the output of elaboration. This confusing term was meant to imply "architectural subset of the final production system" but many interpreted "prototype" to invariably mean throwaway code.

Error: Development Case too complex; too many workproducts It is a misunderstanding to define a Development Case with dozens of UP workproducts, when fewer will suffice. The guideline is "less is better." This is not advice to avoid demonstrably useful documentation, or the forethought that accompanies its creation; the UP recommends creating workproducts that really add value, and abandon make-work or low-value document or model creation.

Error: Predictive planning It is a misunderstanding to create, near the start of the project, a believable plan laying out exactly how many iterations there will be for a long project, their lengths, and what will occur in each.

Error: The team should do lots of modeling and UML diagrams, and use a CASE tool The UP contains several optional models, with many opportunities to apply the UML for diagramming speculative designs before programming. However, these are optional, and if a team can successfully and easily develop software with little or no prior diagramming, they may. Modeling and UML diagramming in the UP are aids to help with complexity and creativity, no more. And it is certainly not necessary to use a CASE or UML drawing tool while modeling on a UP project. The Agile Modeling approach that recommends the simplest possible tool perhaps whiteboard hand sketches and digital cameras is perfectly suitable.

Error: Need many tools It is a misunderstanding to think many software tools need to be applied on an UP project. Rather, it can be run as low-tech, high-touch as paper cards, wall posters, and whiteboards, combined with a sprinkling of CVS, Anthill (for continuous integration), and Bugzilla (for issue and defect tracking).

Error: Software Architecture Document (SAD) "finished" before end of elaboration The UP SAD is a learning aid that summarizes the big ideas and motivation in the architecture. It is a misunderstanding to create the final SAD before the end of elaboration, as that would imply major up-front design, and speculative definition of the architecture without programming. In the UP, the architecture evolves iteration by iteration through an interplay of some educated guesses combined with programming and testing. The architecture is not stabilized until the end of elaboration, after significant programming to build and prove it. Thus, the SAD, which summarizes the architecture, cannot be finished until elaboration is over.

Error: Not conforming to the official UP workproduct names or phase names One purpose of the UP is to establish a common vocabulary, both within an organization and globally across UP-conforming teams, for workproducts and major lifecycle phases. For an organization that is adopting the UP to replace a prior process, it is a misunderstanding to rename the UP workproduct to the older familiar names, rather than surrender to the new terms.

You Know You Didn't Understand the UP When...

Some of the key misunderstandings expressed as a checklist:

• You think a sequence of requirements design implementation express the way to run a UP project.

• You think inception is like requirements analysis, elaboration is like design and detailed requirements analysis, construction is like programming after the design, and transition is a testing phase.

• You want to do most requirements analysis or design before programming.

• You defer the major testing until near the end of the project.

• You define iterations months long rather than weeks long.

• You create the SAD before the end of elaboration.

Signs the UP "Expert" Is Not an Iterative Expert

UP consultants, authors, and speakers from both major well-known consulting organizations and small shops may exhibit a misunderstanding of the UP and iterative development. Here are some of the key ones illustrated in the behavior of a UP "expert":

• Describes the UP phases similar to waterfall phases; recommends doing most requirements or design before programming; encourages creation of more and more detailed specifications and plans, before starting development work.

• Suggests iterations more than six weeks long. Does not strive towards short iterations.

• Recommends an inception phase that is weeks (or worse, months) long, involving major planning and analysis; is not encouraging a rapid transition to early programming in an elaboration phase.

• Is not stressing the importance of early programming starting in the first elaboration iteration, well before all requirements, plans, and design are known.

• Recommends creating many UP artifacts, rather than seeking ways to reduce the number. Some UP consultants do this out of ignorance; others out of a justification for their presence and guidance in the creation of these and handling a more complex process.

• Builds only a throwaway prototype in the elaboration phase.

• Defers unit, load, usability, or acceptance testing until near the end of the project.

• Insists that the team follow the UP activities "by the book."

• Insists on the team using UML CASE tools to draw many diagrams, whereas hand sketches on whiteboards, or simply bypassing drawing and just programming, would suffice.

• Creates the "final" SAD before the end of elaboration and before significant programming has occurred.

• Near the start, defines a "believable" plan laying out how many iterations there will be for the project, their lengths, and what will occur in each (i.e., predictive planning).

• If hired as an UP auditor to verify the team is skillfully applying the UP, encourages more or more thorough workproduct creation or more detailed planning, rather than early programming, evolutionary requirements, and adaptive planning.