UML Weekend Crash Course™ - To Parent Directory

14
Friday Evening
be some strengths and weaknesses in each approach. This should give a fair idea of the
opportunities available to you and the factors that may influence your choices.
The list of all methodologies is far too long to cover here, so at the end of the session I’ll
point you to a resource where you can check out many of the others and dig a little deeper
into the methodologies presented here.
I have selected these four methodologies because they represent the diversity inherent
in system development. The Rational Unified Process works well in large projects where
quality artifacts and communication are critical. The Shlaer-Mellor Method was developed
primarily to address the unique needs of real-time systems long before the UML existed,
but has since adopted the UML notation. CRC is almost more of a technique than a methodology.
It was designed as a tool to help people gain an understanding of objects and how
they work. Extreme Programming tries to reduce many of the existing development practices
to the bare essentials, attempting to optimize the relationship between developers and
clients.
The Rational Unified Process
One method that has received a lot of interest recently is the Rational Unified Process
(RUP). RUP is the latest version of a series of methodologies resulting from a blending of
methodologies. You may have heard the names Objectory Process, the Rational Approach,
the Rational Objectory Process, and the Unified Software Development Process. These were
all predecessors and have been synthesized into the RUP. Actually, it gets a bit confusing
because the Rational Unified Process was a proprietary process within Rational Software,
Inc. The merged method was published in 1999 as The Unified Software Development
Process. The method has since been made public and the name reverted to the Rational
Unified Process (RUP).
The hallmarks of RUP are the two terms incremental and iterative. These concepts are
part of most current methods, but RUP places particular emphasis on their value and
their associated artifacts. The goal of the methodology is to deliver an executable release
of a product, an increment of the product for every pass, or iteration, through the
process. The motivation for this approach is to keep delivery times short and deliveries
frequent. This prevents the historical problem of projects that run for months or even years
before they actually produce anything. It also supports early review and early problem
detection.
Note that in the very early increments, the concept of an executable release is a bit of a
stretch. Typically, you might produce prototypes or layouts without anything executable
until at least a few iterations into the project. The key is to produce some verifiable output
for the clients.
The process is built around the two concepts of project lifecycle phases and process workflow.
Figure 2-1 shows a two-dimensional matrix. The horizontal axis represents the progress
of the project over time. The vertical axis represents the core process workflow. Using this
visualization, you can see that in each iteration, or small step through the life of the project,
the team is working through all the steps in the process workflow. In each subsequent
iteration, the team digs deeper into each activity in the process workflow.
The workflow consists of a set of activities, business modeling through defining the environment.
Each activity is associated with a set of artifacts or work products. In most cases,
the artifacts are UML diagrams, but they may also be items like requirements documents,
test plans, risk assessments, deployment plans, and much more.