Rational Unified Process for User Interface Design

Rational Unified Process for
User Interface Design
g

Rajendra Akerkar

R. Akerkar SE 160, 2005 1

What Is the Rational Unified Process?

 The Rational Unified Process provides a
disciplined approach to assigning tasks and
responsibilities within a development
organization.
i i

 Its goal is to ensure the production of high-
quality product that meets the needs of its
end-users,
end users within a predictable schedule and
budget.


The RUP Framework

 RUP = making a movie ≠ building a house
movie, house.
 sheer size.
 hundreds of artifacts and activities involved
involved.
 RUP® framework is actually easy, particularly
when th ' i t d
h they're introduced b analogy t some
d by l to
familiar process.


The trouble with the construction analogy

 RUP is so often compared to the process of
constructing a building.
t ti b ildi
 it's about producing something concrete using a
similar role set and vocabulary
vocabulary.
 As with an interactive system,
 first have th f
fi t h the foundation ready (th i f
d ti d (the information
ti
architecture in the our case) before building the
walls and the roof.



 information architect deals with problems
such as the internal workings of a interactive
system.
y
 The house architect is more concerned about
visual and functional design,
 which pretty much equals the concerns of a
system analyst in the software world.


 The main objection to
comparing the two is that the
building process can be a
totally predictable waterfall
process,
 while a UI development
process can't!
 the fact is that civil
engineering relies on a
number of well-known
physical laws of nature and
nature,
again, UI design doesn't!


A better analogy to the RUP framework

 The RUP does share the basic goals and
strategies of engineering processes.

 The actual process to achieve those goals
 creative approach required by artistic disciplines
 making movies,
 authoring books, or
g ,
 even writing an article.


The essential principles of the RUP

 RUP is based on common sense
sense,
 harvested from the best practices of numerous
successful projects.
p j

 Interesting fact is that similar practices exist
in areas other than UI development.


The essential principles of the RUP

 The RUP is used to mitigate the risks
associated with software/UI development.

 By conforming to a well-defined and proven
set of rules we aim to increase the
rules,
probability of a successful result.

 Why would we bother with the extra effort?


The general risks associated with UI
development

 lack of resources for carrying out the project
 insufficient funding
g
 not enough time and too much to do
 immature, slow, or non-agile organizations

These risks are the same as for any other type of
development.

R. Akerkar SE 160, 2005 10

Agile Approach
 Novel approach to development based on the
development and delivery of very small increments
of functionality.
ff i li
 Based on Values of simplicity, communication,
feedback and courage.
g
 Relies on constant code improvement, user
involvement in the development team and pairwise
programming
 Two crucial design heuristics
 never duplicate code
 use simplest design possible
 Continuous Testing
 Write the tests before we design the code

R. Akerkar SE 160, 2005 11

The technical risks associated with UI
development
 Unknown t h l i
U k technologies.
 Undiscovered requirements.
 Complicated architecture.

These risks are associated with unpredictable
nature of UI development.
p

R. Akerkar SE 160, 2005 12

The RUP strategy for handing risk

 Develop iteratively.
p y
 Manage requirements.
 Use a component architecture.
architecture
 Model visually.
 Continuously verify quality
quality.
 Manage change.
The RUP gives us these primary strategies for handling
such technical nature risks (the best practices of the RUP).

R. Akerkar SE 160, 2005 13

Develop iteratively
 Creating something innovative, whether a motion
picture or UI requires many iterations to be
UI,
performed on the same artifacts during the
discovery process of building the final product.
 With a waterfall development strategy, projects cycle
through the various phases in a sequential manner,
postponing confrontation with potential problems
t i f t ti ith t ti l bl
until the product has been built and tested.
 Iterative development, on the other hand allows
development hand,
projects to proceed by small steps, or increments, to
gradually build a more complete system.

R. Akerkar SE 160, 2005 14

The RUP's iterative development
process
 Each iteration in the RUP is a pass
through the disciplines.
disciplines

 A discipline in the RUP can be
described as a grouping of interrelated
activities and the artifacts or
deliverables they produce.

 Each pass, which is like a mini
waterfall, explores a new p
p portion of the
requirements set and offers a chance to
correct defects and rework the result of
the previous iteration.

 With each iteration, the solution is
h it ti th l ti i
coming closer and closer to the final
product.

R. Akerkar SE 160, 2005 15

Analogy of Moviemaking
 If making a movie is a pretty straightforward
process of first writing a script then figuring
script,
out how to put the words into motion, doing
the filming and editing, and finally watching
g g y g
the result.
 This would be a traditional waterfall
approach.
 But just as the waterfall approach fails when
we're writing UI it would f il i making a
' iti UI, ld fail in ki
movie as well.

R. Akerkar SE 160, 2005 16

 Instead, the process is much more iterative.
 The actors start working with the script, and revisions
arise out of that interaction.
 For example, the script for the blockbuster Lord of the
Rings based on J R R Tolkien's classic masterpiece
Rings, J.R.R. Tolkien s masterpiece,
was rewritten almost every day after interaction with the
actors.
 Director Peter J k
Di t P t Jackson described th creative process
d ib d the ti
as a controlled chaos.
 Before the end of the project, the script had been
rewritten many times. Each time (or iteration) resulted in
an incremented (and better) version that more closely
resembled the final version.

R. Akerkar SE 160, 2005 17

Manage requirements
 Another essential task whenever a new
product of any kind i d
d t f ki d is developed i ensuring
l d is i
that it meets the needs of its intended users.
 Troublesome task - users sometimes have
only a vague idea of the product under
development.
d l t
 An active requirements management strategy
can it ti l i
iteratively improve th requirements i t
the i t into
something that will satisfy users.

R. Akerkar SE 160, 2005 18

Manage requirements
 The RUP enforces requirements management
throughout the lifecycle
lifecycle.
 The requirements are iteratively and incrementally
identified, documented, evaluated, and refined.
, , ,
 Functional requirements are described in terms of
use cases.
 Nonfunctional requirements are also identified and
managed.
 These are properties of the system that aren t described as use cases
aren't
but usually have a great impact on them, involving the system's usability,
reliability, performance, and supportability.

R. Akerkar SE 160, 2005 19

 As moviemakers work with the script and the actors,
they must think in terms of meeting the needs of
their audience.
 What kind of emotional response do they want the movie to
p y
evoke?
 What kind of experience do they want the audience to
have?
 Where do they want the story to take viewers?
 The movie script is fine-tuned through many
p g y
iterations to match the director's vision of meeting
these functional requirements.

R. Akerkar SE 160, 2005 20

 If the functional requirements of a UI product have
their counterpart in movies, then can a movie also
have nonfunctional requirements?
h f ti l i t ?
 The answer (not surprisingly) is yes.
 Maybe the movie must be viewable by children under 18 and
no longer than 120 minutes
minutes.

 Although these requirements aren't directly related to
the t
th story line, they'll h
li th 'll have an iimpact on th fi l result
t the final lt
- just as nonfunctional software requirements must
have on a computer system.
 In th
I the same way, these requirements must be
th i t tb
identified and addressed in the process of making the
movie.

R. Akerkar SE 160, 2005 21

Use a component architecture
 A component is a replaceable piece of UI that fulfills
a clear function.
 The RUP encourages the use of components to
assemble a system.
 Component based
Component-based development has advantages:
 it facilitates reuse both within the system and by other
systems,
 it provides a convenient abstraction in the system design,
and
 it enables efficient parallel development.
 Furthermore, a well-structured component based
well structured component-based
architecture makes a system more scalable and
easier to maintain.

R. Akerkar SE 160, 2005 22

( Analogy to Moviemaking)

 The most obvious equivalent of a component
in a movie is a scene.
 A film is typically made up of a number of
scenes unified in a coherent structure that
realizes the director's vision.
director s
 Each scene is fully replaceable, meaning that
it s
it's possible to replace it alter it or even
it, it,
remove it without compromising the whole
p
picture ( that's what the director wants).
(if )
R. Akerkar SE 160, 2005 23


 Developing a computer application of considerable size without
using a component-based architecture, something that's still
done today,
 It is like shooting a movie in only one take.
 This is how the 2002 drama Russian Ark by Aleksandr Sokurov
was made - the whole movie (2 hours, 16 minutes) is one
continuous shot.
 Given that it's pretty hard to make even a ten minute continuous
it s ten-minute
scene, Sokurov's achievement is truly heroic.

 Going back to the UI design world the RUP principle of
world,
component-based architecture relieves developers of the need to
be heroes on impossible quests.

R. Akerkar SE 160, 2005 24


 Another movie equivalent to software components is:
 In making the computer-animated adventure Finding Nemo,

 The modelers were challenged with the task of creating natural-
looking surging and swelling water. (under water story)

 The problem was not only to accurately simulate the movement
of water, but also
 to capture how light refracts through it,
 the way particles dance around,

 the colors of different types of water, and so on.

 This had never been achieved to that extent before in computer
animation.

R. Akerkar SE 160, 2005 25


 As soon as the project was launched, the design department
started experimenting with water modeling.
t t d i ti ith t d li
 Extensive studies, consulted experts on oceanography, made
sketches and drawings, and most important of all, made
prototypes based on their increasing knowledge of the problem
problem.
 The prototypes were then exposed to the director's critical eye.
 Then the final result of the hard labor was a design template
covering every conceivable water simulation in the movie
movie.
 This template was a fundamental component of the film's
architecture;
 other components (templates) resolved different problems such
problems,
as the motion patterns of fish and plants.

R. Akerkar SE 160, 2005 26

In the kingdom of UI development

 design templates tell designers how to deal
with the most significant problems.
 Without a solid architecture or design
architecture,
template, there really isn't much point in
moving on in the project.
 Until these kinds of issues can be resolved,
designers will never be able to meet the
requirements.

R. Akerkar SE 160, 2005 27

Model visually
 A model is a simplified representation of a real-world
entity or process, intended to help us imagine and
process
flesh out the real-world version.
 At some point early in the development of UI
software, there's a need to understand the
f
interaction between the system and its users.
 The developers have two options:
 they can implement the software as they guess it should
work, or
 they can create a model of it, which can then be exposed to
it
potential users, designers, and testers, whose feedback
can in turn alter the model.

R. Akerkar SE 160, 2005 28

Model visually
 This type of model, describing how a user interacts
with the system, is usually referred to as a use case
system
model.
 The point of creating use case models is to mitigate
p g g
the risk of building the wrong system.
 Modeling is theoretical exercise to understand
complex system behavior by simplification.
 The RUP encourages architecture teams to prove
their architectural concepts by executing prototypes
prototypes.

R. Akerkar SE 160, 2005 29

Model visually (Analogy to Moviemaking)
 In the early stages of a movie project, all that exists is a script.
 But just as in the software case, the director needs to see the product
before it's completed.
 As with the RUP, the solution is to build a model of the story.
 This is known in the film industry as visualization, and it can be
achieved by various techniques:
 traditional actor acting,
 puppet acting,
 storyboarding, and

 even 3D computer graphics.
 If storyboarding (a concept that also exists in the RUP) is used, the
t b di ( t th t l i t i th i d th
model consists of a sequential series of sketches illustrating stages or
scenes.
 From the storyboards, the director can decide if a scene seems too
long or should be removed, or if something is missing.
removed missing
 The storyboards can be filmed and edited, and temporary sound
effects and music can be added, just to further enhance the model's
usefulness.

R. Akerkar SE 160, 2005 30

Continuously verify quality
 The RUP is divided into four phases, each one
focusing on a certain aspect of the development
g p p
cycle:
 Inception,
 Elaboration,
Elaboration
 Construction, and
 Transition.
 In each of these phases the RUP best practices give
us the opportunity to verify the progress and quality
of the project under development and thus to find
flaws and potential improvements as early as
possible.

R. Akerkar SE 160, 2005 31

 In the Inception phase, the focus is on
understanding the objectives of the project
project.
 The question to be answered before the end
of this phase is whether the project is worth
doing at all.
 Once the project has a go to continue, it
enters the Elaboration phase.
 Here, the focus is on establishing a solid design
foundation (the architecture) and mitigating the
major risks of the project.

R. Akerkar SE 160, 2005 32

(Analogy to Moviemaking)

 In the RUP, the quality of the latest increment is verified in every
iteration.
 In a movie project, the director primarily uses the modeling tools
in his or her toolbox to catch problems with
 a diverging story line,
 scenes that don't fit together, or
 a tempo (rhythm) that just isn't right.

 When problems are found early, it's easier to do something about
them.
 In moviemaking as in UI development the general rule is that the
development,
earlier a fault is discovered, the cheaper it is to fix.
 The best practice of continuously verifying quality can facilitate
this.
this

R. Akerkar SE 160, 2005 33

Manage change
 change is necessary but inconvenient.
 Requirements will almost inevitably change
over time.
 waterfall development so often fails is that it's
unable to handle change.
 An iterative and incremental methodology, by
contrast, facilitates continuous change,
iterating t
it ti toward a better solution.
d b tt l ti

R. Akerkar SE 160, 2005 34

Manage Change (Analogy to Moviemaking)
 Making a feature film: a huge crew and a substantial budget.
 Communicating well about needed changes is vital to the success of
such a project
project.
 Imagine that the director wants to improve the final scene.

 Although it comes at the end of the movie, the need for improvement
can b id ifi d early since quality i continuously verified on all
be identified l i li is i l ifi d ll
levels.
 Do the screenwriters have to update the script?
 Who will review and approve it?
pp
 Does the scene have to be modeled again?
 If so, will storyboards, 3D graphics, or plastic models be used?
 Does the set need to be modified, or does a new set need to be built? How
does this affect our budget?
g
 Do we have to ask for more time and money?

 These are the kinds of questions that result in changing plans and
therefore must be addressed preferably in an iterative manner
addressed, manner.

R. Akerkar SE 160, 2005 35

A movie project plan
 One of the key artifacts in the RUP
framework is the project plan
plan.
 The project plan details the tasks, schedule,
cost, resources, milestones,
cost resources milestones and deliverables
needed to complete the project.
 Progress is tracked against the plan and
measured by work completed by milestones
reached and results delivered.
 The plan is conceived early in the project and
frequently updated throughout the lifecycle.

R. Akerkar SE 160, 2005 36

The Iterative Model graph of RUP
 The horizontal axis
represents time and
shows the dynamic
aspect of the process as
it is enacted, and it is
expressed in terms of
cycles, phases,
iterations, and
milestones.

 The vertical axis
represents the static
aspect of the p
p process:
how it is described in
terms of activities,
artifacts, workers and
workflows.

R. Akerkar SE 160, 2005 37

A movie project plan = a User Interface
development project

R. Akerkar SE 160, 2005 38

A movie project plan = a User Interface
development project
 In this figure, activities related to making a movie are substituted
for the RUP disciplines.
 Developing the screenplay is analogous to writing requirements,

 filming corresponds to implementation, and

 producing the movie is more or less like project management.

 Dividing the timeline into four p
g phases pputs the focus on different
aspects of the movie project at different times.
 We also see that the activities run in parallel, typically
exchanging information and work packages in a highly efficient,
cross-functional manner:
f
 just as the RUP.

R. Akerkar SE 160, 2005 39

The Essentials of RUP
 In all projects, it is important to explore what will
happen if any of these essentials is ignored.

 For example:
1. No vision? You may lose track of where you are going.
2. No plan? You will not be able to track progress.
3. No risk list? You may be focusing on the wrong issues
now.
4. No issues li ? With t accountability, th
N i list? Without t bilit these are th
the
roadblocks to success.
5. No architecture? You may be unable to handle
communication, synchronization,
communication synchronization and data access issues
as they arise.

R. Akerkar SE 160, 2005 40

The Essentials of RUP
6. No product (prototype)? Get started writing code; get
something working in front of the customers
customers.
7. No evaluation? Don’t keep your head in the sand. It is
important to face the truth. How close are you really to your
deadline? To your goals in quality or budget?
8. No change requests? How do you keep track of these?
9. No user support? What happens when a user has a
pp pp
question or can’t figure out how to use the product?

R. Akerkar SE 160, 2005 41

References
 Rational Unified Process, version 5.5, Rational Software
Corporation, Cupertino, CA (1999)
 Introduction to the IBM Rational Unified Process Essentials,
an article by Mats Wessberg (2005).
 Philippe Kruchten, The Rational Unified Process An
Process—An
Introduction, Addison-Wesley-Longman, Reading, MA (1999)
 Ivar Jacobson, Grady Booch, Jim Rumbaugh, The Unified
Software Development Process, Addison Wesley (1999)
Process Addison-Wesley
 Grady Booch, et al., UML User’s Guide, Addison-Wesley-
Longman, Reading, MA (1999).
 Stefan Bergstrand, Adopting the Rational Unified Process:
Success with the RUP, Addison Wesley (2004).

R. Akerkar SE 160, 2005 42

Rational Unified Process for User Interface Design

More Related Content

What's hot (18)

Viewers also liked (20)

Similar to Rational Unified Process for User Interface Design (20)

More from R A Akerkar (16)

Recently uploaded (20)

Rational Unified Process for User Interface Design