Volume 1: Issue 1, August 2004 For Private Circulation Only

……………….. ……….. ……. …… .

NEWSLETTER ON SOFTWARE DESIGN AND architecture, Visually model software, Verify
PROCESSES
software quality, and control changes to
software.
Dear Readers,
The RUP has two aspects: static and dynamic.
Welcome to the first issue of my newsletter on
The dynamic aspect is represented by four
Software Design and Processes. The focus of
phases: inception, elaboration, construction,
the newsletters will be “How To Build Better
and transition, whereas the static aspect is
Software”. Factors such as proper requirement
represented by nine core workflows.
gathering, sound architectural design, diligent
unit testing, adoption of appropriate processes,
Four Phases of the Rational Unified Process:
proper project management, etc play an
important role in the success of a software
Phase 1- Inception:
project. Through these newsletters I wish to
The two key activities of this phase are
bring forth articles that will highlight various
definition of the business case and project
issues, and best practices, involved in Software
scope for the software project/product.
Design. I look forward to hearing your
Defining the business case constitutes defining
suggestions on how we can improve the
the success criteria, assessing risks,
newsletter, things that you enjoyed reading and
determining resources, and outlining a basic
things that you would like to read. Please mail
plan in terms of resources and schedules.
your feedback to
Defining the scope constitutes identifying all
newsletters@adaptivesoftware.biz
actors and major use cases of the system. The
culmination of the inception phase is marked
Contents by a clear definition of the objectives that the
1. Rational Unified Process: A Brief software must achieve.
Introduction
Phase 2- Elaboration:
2. Best Practice The key focus of the elaboration phase is to
analyze/understand the problem domain and
-- Converted from Word to PDF for free by Fast PDF -- www.fastpdf.com --

design a sound architecture, project plan, and

cost estimates. This phase is the main planning
1. Rational Unified Process: A Brief
phase before actually starting the
Introduction
implementation.
Introduction: The Rational Unified Process
Phase 3- Construction:
(RUP) is an attempt at combining some
The construction phase is the realization of the
industry best practices and unifying two (The
Rational approach, and the Objectory Process) business plans and architecture created in the
elaboration phase. The end of the construction
well established software development process
phase is marked with a deployable product,
into a unified process. The RUP is an
which is ready to be given to the users.
engineering process which provides a
disciplined approach to assigning tasks and
Phase 4- Transition:
responsibilities in a development organization
The transition phase is mainly marked with
to produce high quality software that meets the
installing the software on various platforms and
needs of end users within a predictable
training users. The transition phase may
schedule and budget. The Rational Unified
coincide with the inception phase of the next
Process draws from six industry best practices:
release cycle.
Develop software iteratively, Manage
requirements, use component - based

Adaptive Software Solutions: Solutions that adapt to your requirements

 Volume 1: Issue 1, August 2004
Since RUP is an iterative process, the four
phases of RUP are not to be followed in a strict
linear manner. In fact they will usually
intertwine during an actual project execution.
Static Structure of the Rational Unified
Process:
A process describes objectives which have to
be accomplished, the time schedule within
which they must be accomplished, how they
must be accomplished, and by whom. RUP has
four primary modeling elements (workers,
activities, artifacts, and workflows) that
describe the process.
Workers: A worker is essentially a role, which
an individual assumes. Each role is assigned
responsibilities in the form of performing
activities and owning artifacts.
Activity: An activity is a unit of work that a
worker has to perform. Each activity has a
clear purpose and is fulfilled by
producing/modifying an artifact. Each activity
typically lasts for a few hours to a few days.
Examples of activities include ‘finding use
cases’, ‘reviewing a design’, and
‘implementing a component’.
Artifact: An artifact represents a piece of
information. Artifacts are produced/modified
during various activities. Examples of artifacts
are models (use case diagram, class diagram),
-- Converted from Word to PDF for free by Fast PDF -- www.fastpdf.com --
source code, binaries, etc.
Workflows: workflows define a sequence in
which activities are to be performed. They
define the ordering as well as the concurrency
of multiple activities if applicable. RUP defines
nine core Workflows. The first six are
engineering workflows, while the remaining
three are supporting workflows.
1) Business Modeling Workflow: The
business modeling workflow provides a
common language and tools to both the
business and software engineering teams,
so that they may communicate effectively
and unambiguously.
2) Requirements Workflow: The purpose of
the requirements workflow is to create a list
Adaptive Software Solutions: Solutions that adapt to your requirements
For Private Circulation Only
of user requirements and functionality for
the proposed software.
3) Analysis & Design Workflow: The goal of
this workflow is to create an architectural
model of the proposed system, which can
fulfill the functionality described in the use
cases. The architecture of the system is
represented by various UML diagrams .
4) Implementation Workflow: In the
implementation workflow the architecture
of the system is realized using a
programming language. The components,
and classes described in the architecture are
implemented and integrated into an
executable system. Unit testing of classes
and components is also considered to be a
part of this workflow.
5) Test: The test workflow is used to verify
that the system functions in an error-. free
manner. The system is tested along three
quality dimensions: reliability,
functionality, and performance. Testing is
an iterative process and should be
performed in all phases of the Rational
Unified Process.
6) Deployment: The purpose of the
deployment workflow is to package the
software and successfully install it. Other
activities that may be performed in this
workflow are user training, data transfer,
helping users transition from their old
system to the new one, and formal
acceptance, if you want to include this.
7) Project Management: The purpose of the
project management workflow is to allocate
resources for the project, define time
schedules, and to ensure that an error-free
software is delivered on time, and within
budget. Risk analysis and management is
an very important part of the project
management workflow.
8) Configuration & Change Management: A
project consists of many artifacts (including
source code) which are produced, modified
and used by various workers. Since these
artifacts may be accessed simultaneously, it
 Volume 1: Issue 1, August 2004
is important to manage them effectively to
avoid conflicts and rework. This workflow
provides guidelines for managing multiple
versions of a software, tracking changes
and automating builds.
9) Environment: The purpose of this
workflow is to provide the team with an
appropriate environment (processes and
tools) so that they may complete the project
successfully. This workflow also explains
how the RUP process can be customized
for a particular organization or a project. It
consists of a development kit with tools,
templates and guidelines to help
organizations customize the process.
If we examine the six engineering workflows
closely we may conclude that they follow a
linear sequence of execution. However RUP is
not a linear process, but rather an iterative one.
All nine workflows are visited iteratively at all
stages in the development process. However
some workflows may be visited more often
than others during a particular phase. .
Even though the RUP is a tool independent
process it will prove to be extremely difficult to
manually manage every part of the process
even for a modestly sized project. Tools from
several vendors are available for managing
various aspects of the process. The Rational
Unified Process Product contains various
components such as a knowledge Base,
-- Converted from Word to PDF for free by Fast PDF -- www.fastpdf.com --
Microsoft Project Plans, Development Kit,
Resource Center and RUP Book to help
developers and project managers in every
phase of the product cycle. Rational also
provides us with a set of tools, which integrate
well with each other to give us a unified system
to manage the software development process.
The set of tools include Rational Requisite Pro,
Rational Clear Quest, and Rational Rose 98,
Rational SoDA, Rational Purify, Rational
VisualQuantify, Rational Visual
PureCoverage, Rational TeamTest, Rational
PerformanceStudio , and Rational Clear Case.
As we have seen RUP provides us with a
process using which, we can significantly
increase chances of project success. However
simply understanding RUP will not guarantee a
successful project. Readers are advised to refer
to case studies, best practices, and other
Adaptive Software Solutions: Solutions that adapt to your requirements
For Private Circulation Only
material, which will help them with more
information and thus increase the probability of
success. Finally we must remember that
however, good a process, it will not be
successful unless it is enforced properly and
adapted by the entire team.
Additional Resources:
1. Rational Unified Process- An Introduction by
Philippe Krutchen. Published by Adison-Wesley.
2. http://www.rational.com/products/index.html.
3. http://www.therationaledge.com
Note:Rational, Rational Unified Process, Rational Apex, Rational
Rose, RequisitePro,ClearQuest, Clear Case, Purify, VisualQuantify,
Visual PureCoverage, PerformanceStudio, and SQA, are registered by
Rational Software Corporation.
About the author
Parag Shah is the founder of Adaptive
Software Solutions. He provides consulting
services and corporate training, for software
architecture and J2EE implementation.
At Adaptive Software Solutions, we focus on
providing technology consulting, custom
software solutions, and software technology
training. We believe that software solutions
must possess two key qualities: Adaptability,
and Appropriateness. Adaptive, because a
software should adapt to a clients' requirements
and setup rather than a client changing their
processes for the software. Appropriate,
because a good solution is not necessarily one
which uses the latest and greatest technology,
but rather one which fulfills the requirement,
and uses the most appropriate technology to
create a solution that best balances various
forces.
Being extremely excited and enthusiastic about
technology, we also understand that technology
is a means to an end. The ' end' is bringing
value to our customers. As a client you will
benefit from our no-hype approach to
providing solutions. We make it a point never
to oversell technology, and always endeavor to
propose the most appropriate and cost effective
solution for any set of requirements.
Adaptive Software Solutions is headed by
Parag Shah, who has an MS in Computer
Science and over 6 years of experience in
software development. Please visit our website
http://www.adaptivesoftware.biz for more
information about our consulting and training
solutions.
 Volume 1: Issue 1, August 2004 For Private Circulation Only

Best Practices
Do not over – engineer the system architecture:
As systems architects we have to foresee elements that can change in the software specification
over time. We have learnt that a good system design is one which separates things that can
change from those that don’t. However in trying to foresee potential changes we often try to
accommodate room for a lot of changes, most of which will not happen in the lifetime of the
project. This leads to an over engineered design, which is more time consuming to implement,
and difficult to understand and hence maintain. Such a design becomes counter-productive.
While designing software it is very important to view the changes we anticipate along with their
probability of occurrence. It is often a good idea not to design for a low probability change, if it
significantly increases the design complexity.

Book - Post

To,

.
-- Converted from Word to PDF for free by Fast PDF -- www.fastpdf.com --

1/A Poonam C.H.S 45/48

Lallubhai Park Road
Andheri (W), Mumbai – 400058

Copyright 2002-2004 Adaptive Software Solutions. http://www.adaptivesoftware.biz

You may share the contents of this newsletter with anyone you feel may be interested. You may also reprint
excerpts both online and offline provided that you acknowledge the source appropriately.

Disclaimer: The information in this newsletter is distributed on an as-is basis, without any warranty. Even though
we have taken utmost care to ensure correctness, neither the authors nor the publisher shall have any liability to any
person or entitle with respect to any liability, loss or damage caused or alleged to be caused directly or indirectly by
material contained in this newsletter

Adaptive Software Solutions: Solutions that adapt to your requirements