The document discusses the Rational Unified Process (RUP), an iterative software development process for building object-oriented systems. It is based on commonly accepted best practices like iterative development. The RUP combines requirements, analysis, design, and testing activities into a series of timed iterations. Each iteration results in an integrated and tested increment of functionality. The RUP aims to deliver early and continuous value through practices like iterative development, user involvement, and risk-driven development.

1. ITERATIVE DEVELOPMENT
&
THE UNIFIED PROCESS

2. Objectives
• Define an iterative and adaptive process.
• Define fundamental concepts in the Unified Process
• Informally, a software development process describes an approach to building, deploying, and possibly
maintaining software.
• The Unified Process has emerged as a popular software development process for building object-
oriented systems. In particular, the Rational Unified Process or RUP.
• The Unified Process (UP) combines commonly accepted best practices, such as an iterative lifecycle and
risk-driven development, into a cohesive and well-documented description. Consequently, it is used in
this book as the example process within which to introduce OOA/D.

3. • UP was introduced for two reasons:
1. The UP is an iterative process. Iterative development is a valuable practice that influences how this book
introduces OOA/D, and how it is best practiced.
2. UP practices provide an example structure to talk about how to do—and how to learn—OOA/D.
The Most Important UP Idea: Iterative Development The UP promotes several best practices, but one stands
above the others: iterative development.
• In this approach, development is organized into a series of short, fixed-length (for example, four week) mini-
projects called iterations; the outcome of each is a tested, integrated, and executable system.
• Each iteration includes its own requirements analysis, design, implementation, and testing activities.
• The iterative lifecycle is based on the successive enlargement and refinement of a system through multiple
iterations, with cyclic feedback and adaptation as core drivers to converge upon a suitable system.

5. Benefits of Iterative Development include:
• Early rather than late mitigation of high risks (technical, requirements, objectives, usability, and so forth)
• Early visible progress.
• Early feedback, user engagement, and adaptation, leading to a refined system that more closely meets the real
needs of the stakeholders .
• Managed complexity; the team is not overwhelmed by “analysis paralysis” or very long and complex steps
• The learning within an iteration can be methodically used to improve the development process itself, iteration
by iteration.
Iteration Length and Timeboxing:
• The UP (and experienced iterative developers) recommends an iteration length between two and six weeks.
• Small steps, rapid feedback, and adaptation are central ideas in iterative development; long iterations
subvert the core motivation for iterative development and increase project risk.
• Much less than two weeks, and it is difficult to complete sufficient work to get meaningful throughput and
feedback; much more than six or eight weeks, and the complexity becomes rather overwhelming, and
feedback is delayed.

6. • A very long iteration misses the point of iterative development. Short is good. A key idea is that iterations are
timeboxed, or fixed in length.
• For example, if the next iteration is chosen to be four weeks long, then the partial system should be
integrated, tested, and stabilized by the scheduled date—date slippage is discouraged.
• If it seems that it will be difficult to meet the deadline, the recommended response is to remove tasks or
requirements from the iteration, and include them in a future iteration, rather than slip the completion date.
Some additional best practices and key concepts in the UP include:
• Tackle high-risk and high-value issues in early iterations.
• Continuously engage users for evaluation, feedback, and requirements.
• Build a cohesive, core architecture in early iterations.
• Continuously verify quality; test early, often, and realistically.
• Apply use cases.
• Model software visually (with the UML).
• Carefully manage requirements.
• Practice change request and configuration management.

7. THE UNIFIED PROCESS – CASE
STUDY EMPHASIS
&
RATIONALE UNIFIED PROCESS (RUP)

8. The UP Phases and Schedule –Oriented Terms:
• A UP Project organizes the work and Iterations across “four” major phases:
1. Inception: approximate vision, business case, scope, vague estimates.
2. Elaboration: refined vision, iterative implementation of the core architecture, resolution of high risks, identification of most
requirements and scope, more realistic estimates.
3. Construction: iterative implementation of the remaining lower risk and easier elements, and preparation for deployment.
4. Transition: beta tests, deployment.
• These phases are more fully defined in subsequent chapters.
• This is not the old “waterfall” or sequential lifecycle of first defining all the requirements, and then doing all or most
of the design.
• Inception is not a requirements phase; rather, it is a kind of feasibility phase, where just enough investigation is done
to support a decision to continue or stop.
• Similarly, elaboration is not the requirements or design phase; rather, it is a phase where the core architecture is
iteratively implemented, and high risk issues are mitigated.
• The below figure illustrates common schedule-oriented terms in the UP. Notice that one development cycle (which
ends in the release of a system into production) is composed of many iterations.

10. The UP Disciplines (Workflows):
• The UP describes work activities, such as writing a use case, within disciplines (originally called
workflows).
• Informally, a discipline is a set of activities (and related artifacts) in one subject area, such as the
activities within requirements analysis. In the UP, an artifact is the general term for any work product
like: code, Web graphics, database schema, text documents, diagrams, models, and so on.
• There are several disciplines in the UP, that focuses on some artifacts in the following “three”:
1. Business Modeling: When developing a single application, this includes domain object modeling.
When engaged in large-scale business analysis or business process re-engineering, this includes
dynamic modeling of the business processes across the entire enterprise.
2. Requirements: Requirements analysis for an application, such as writing use cases and identifying
non-functional requirements.
3. Design: All aspects of design, including the overall architecture, objects, databases, networking, and
the like.

12. Book Structure of OOA/D with UP Phases & Disciplines:
• With respect to the phases and disciplines, what is the focus of the case study?
 The earlier chapters introduce activities in inception; later chapters explore several iterations in elaboration.
 The following list and below Figure describe the organization with respect to the UP phases as:
1. The inception phase chapters introduce the basics of requirements analysis.
2. Iteration 1 introduces fundamental OOA/D and how to assign responsibilities to objects.
3. Iteration 2 focuses on object design, especially on introducing some high-use “design patterns”.
4. Iteration 3 introduces a variety of subjects, such as architectural analysis and framework design.

13. • Rational Unified Process (RUP) is a software development process for object-oriented models.
• It is also known as the Modern Unified Process Model. It is created by Rational Corporation
and it is designed & documented by using UML (Unified Modeling Language).
• This process is included in IBM Rational Method Composer (RMC) product. IBMC
(International Business Machine Corporation) allows us to customize, design, and personalize
the unified process.
• RUP is proposed by Ivar Jacobson, Grady Booch, and James Rumbaugh called as “Three
Amigos”. Their work continued by Philip Kruchten, & Walker Royce in development to RUP
with use of Booch methodology.
• Some characteristics of RUP include:
 use-case driven,
 Iterative (repetition of the process), and
 Incremental (increase in value) by nature, delivered online using web technology, can be
customized or tailored in modular and electronic form, etc.
• RUP reduces unexpected development costs and prevents wastage of resources.

15. Inception –
 Communication and planning are the main ones.
 Identifies the scope of the project using a use-case model allowing managers to estimate costs and
time required.
 Customers’ requirements are identified and then it becomes easy to make a plan for the project.
 The project plan, Project goal, risks, use-case model, and Project description, are made.
 The project is checked against the milestone criteria and if it couldn’t pass these criteria then the
project can be either cancelled or redesigned.
Elaboration –
 Planning and modelling are the main ones.
 A detailed evaluation and development plan is carried out and diminishes the risks.
 Revise or redefine the use-case model (approx. 80%), business case, and risks.
 Again, checked against milestone criteria and if it couldn’t pass these criteria then again project
can be cancelled or redesigned.
 Executable architecture baseline.

16. Construction –
 The project is developed and completed.
 System or source code is created and then testing is done.
 Coding takes place.
Transition –
 The final project is released to the public.
 Transit the project from development into production.
 Update project documentation.
 Beta testing is conducted.
 Defects are removed from the project based on feedback from the public.
Production –
 The final phase of the model.
 The project is maintained and updated accordingly.

17. Advantages:
• It provides good documentation, it completes the process in itself.
• It provides risk-management support.
• It reuses the components, and hence total time duration is less.
• Good online support is available in the form of tutorials and training.
Disadvantages:
• Team of expert professional is required, as the process is complex.
• Complex and not properly organized process.
• More dependency on risk management.
• Hard to integrate again and again.

18. RATIONAL UNIFIED PROCESS (RUP):
Before going in detailed discussion with RUP, let’s get a short – note on OOAD as:
 What is OOA and OOD?
 What is UML?
 What is Rational Unified Process
 Stages of RUP
 Static Structure of RUP
 RUP Workflow Example
 Activities in Rational Unified Process
 Effort distribution of activities
 Relative effort of activities

19. What is OOA and OOD?
Analysis emphasizes an investigation of the problem and not on how the solution is
defined.
Design emphasizes a logical solution, how the system fulfills the requirements.
Object Oriented Analysis and Design (OOAD) is to emphasize considering problem
domain and logical solution from perspective of objects.
Object Oriented Analysis (OOA) finds and describes the objects or concepts in problem
domain.
Object Oriented Design (OOD) defines logical software objects that will implement in
an object-oriented programming language.

20. What is UML?
 UML stands for Unified Modeling Language.
 UML is a language for specifying, visualizing, and constructing the artifacts of software system.
 UML is a modeling language, not a method, where these ‘Methods’ consist of both a modeling language and a process,
i.e., A ‘Process’ describes “who is doing what, how, and when”.
 Modeling Language is the notation that methods use to express designs. It is a notational system with semantics
defined & aimed at modeling systems using object-oriented concepts. It is an industry standard for object oriented
modeling approved by OMG (Object Management Group).
 The UML is the emerging effort of ‘3’ persons namely called as “Three Amigos” as:
 Grady Booch (creator of BMT, Booch Modeling Technique),
 Jim Rumbaugh (creator of OMT, Object Modeling Technique), and
 Ivar Jacobson (creator of OOSE, Object-Oriented Software Engineering).
 However, UML does not include description of a process.
 Grady Booch, Jim Rumbaugh, & Ivar Jacobson from Rational also form a software engineering process called
Rational Unified Process (RUP).
 The UML is used throughout the Rational Unified Process (RUP).

21. What is Rational Unified Process (RUP)?
 Rational Unified Process (RUP) is a software development process for object-oriented models. It is an iterative
and incremental approach allows an increasing understanding of the problem through successive refinements.
 It is created by Rational Corporation and it is designed & documented by using UML (Unified Modeling
Language).
 This process is included in IBM Rational Method Composer (RMC) product. IBMC (International Business
Machine Corporation) allows us to customize, design, and personalize the unified process.
 RUP is proposed by Grady Booch, Ivar Jacobson, and James Rumbaugh called as “Three Amigos”. Their work
continued by Philip Kruchten, & Walker Royce in development to RUP with use of Booch methodology.
 Some characteristics of RUP include:
 An architecture-centric approach,
 A use-case driven approach,
 Manages risk,
 Manages change, and
 Can be tailored to different situations (flexible).

22. What is RUP? (cont.)

23. What is RUP? (cont.)
 The Rational Unified Process (RUP) is a software development process. Rational Software Corporation develops it;
now, it is part of IBM from 2003. It controls the development process and produces a high-quality software product.
It is nothing but a model for the software development process. This development process involves multiple stages like
business modeling or planning, analysis and design, implementation or coding, testing, and deployment, etc.
 The Rational Unified Process is a combination of Building Blocks used to describe who, what, when, and how the
development process will occur.
 These RUP consists of “4” Building Blocks like:
1. (Roles) the ‘Who’: It shows who are the responsibilities for developing the software product. It may be an
individual or a group of individuals together as a team who work on it.
2. (Work Products) the ‘What’: It indicates what will be produced. That shows the behavior and type of software
product.
3. (Workflows) the ‘When’: It represents the flowchart of activities in order to produce a software product.
4. (Tasks) the ‘How’: It describes how the development will take place, i.e. a unit of work assigned to a Role to
perform and that provides a meaningful result.

24. What is RUP? (cont.)
 RUP incrementally grows an effective solution over multiple iterations, i.e., it develops a high quality software that
meets the needs of its end-users, with in a predictable schedule and budget.
 The RUP consists of “4” phases namely:
 Inception,
 Elaboration,
 Construction, and
 Transition.
 Inception Phase: Do you & the Customer have a shared understanding of the system? i.e., it establishes the business
rationale for the project, delimits the project scope and a conceptual prototype.
 Elaboration Phase: Do you have an architecture to be able to build the system? i.e., it collects more detailed
requirements, performs high-level analysis and design to establish an architecture baseline, and create a plan for
construction.
 Construction Phase: Are you developing the product? i.e., it consists of many iterations, in which each iteration
analyzes, designs, builds, tests, and integrates a subset of requirements of a project.

25. What is RUP? (cont.)
 Transition Phase: Are you trying to get the Customer to take ownership of the system? i.e., it includes beta testing,
packaging, performance tuning, and user training.

26. INCEPTION
 It is the initial phase of the developing process. During this phase, the project’s basic ideas and structure will be
determined to prepare a business suite, i.e. the team will decide the purpose of the project, success criteria,
estimated cost, risk assessment, scheduled time, and resources required to complete it etc.
 The idea for the project is stated. The development team determines if the project is worth pursuing and what
resources will be needed.
 It is just like an evaluation of the project. The project may be canceled or consider depends on if it fails to pass the
below criteria.
 The conclusions of the Inception Phase are:
 It provides a general vision of project initiative document with multiple parameters.
 We get the project scope with the initial project model.
 An initial business suite with financial analysis like Cost, Size, Revenue as ROI, and Time spent on Project .
 A project plan with different phases with a business model.
 Requirements understanding.
 Actual expenditures (how much money you really spent) versus planned expenditures (expected money to spend).

27. ELABORATION
 This is the second phase of the development process. During this phase, to analyze the project’s requirements and
necessary architecture, i.e., to review the problems, develop the project plan and architect, and eliminate the high-risk
elements from the project. It is the most critical phase among the four phases. The actual development and coding will take
place in the following phase.
 The conclusions of the Elaboration Phase are:
 It provides a full model of the project with functional requirements (defines a system / its component i.e., “what should the
software system do?”; it is mandatory; captured in use case; defined at component level; and helps us to verify the
functionality of the software like System Integration, End-to-End, & API Testing) and non-functional requirements (defines
the quality attribute of a system i.e., “How should the software system fulfill the functional requirements?”; it is not
mandatory; captured as a quality attribute; applied to system as a whole; and helps us to verify the performance, usability, &
security of the software).
 It provides a full Software Architecture Description.
 It provides the stability of the project, like the vision of the product & architecture of product stable or not?
 Similarly, the project plan will approve or not?
 Is the actual resource cost (amount spent on the project to date) versus planned resource cost (amount earned as per the
schedule) acceptable or not?

28. ELABORATION (cont.)
 At this stage, requirements for the project is usually quite vague (not clearly defined / not stated). To better
understand requirements, ask the following questions:
 What is actually going to be built?
 How are you going to built it?
 What technology are you going to use?
 The issues addressing in this stage can be found by identifying the risks in your project:
1. Requirement Risk: What is the chance of building the wrong system?
2. Technological Risk: Assume the use of OO and JAVA technology, how much is known about OO design? Will
JAVA do the job?
3. Skill Risk: Staff has the necessary expertise?
4. Political Risk: Any political influences that may affect the project?
1. To address Requirement Risk:
 Use cases drive the elaboration phase and form the foundation of planning for the construction phase.
 A use case is a typical sequence that a user has with the system in order to achieve some goal.
 A skeleton of conceptual model of the problem domain is provided.

29. ELABORATION (cont.)
 Explore the vocabulary of the domain.
 UML class diagrams capture the conceptual perspective of the business requirement.
 UML sequence diagrams explore how various roles interact in the business.
 One may build a prototype of any tricky parts of the use cases.
2. To address the Technological Risk:
 Try out pieces of potential technology.
 Integrate test of the pieces of technology.
 Architectural design decisions can be illustrated by the following UML diagrams:
• Package diagram: A high level picture of the components at this stage.
• Deployment diagram: An overview of how pieces are distributed from system architecture perspectives.
• Sequence diagram: How components are communicated.
3. To address the Skill Risk:
 Train staff before the project started.
 Mentoring: Have an experience developer work with your project or have him/her review your project from stage to
stage.

30. ELABORATION (cont.)
Result of the elaboration is to have a baseline architecture for the system, that includes the
following:
 A list of use cases,
 Conceptual model, and
 Technology platform.
Plan for the Construction Phase includes:
 Prioritization of use cases, and
 Assignment of use cases into iterations of the construction phase.
A good rule of thumb (is a rule or principle that you follow which is not based on exact
calculations, but rather on experience) is that Elaboration Phase should take about a “fifth” of
the total length of the project.

31. CONSTRUCTION
 This is the third phase of the development process. During this phase, the project is developed and completed. Here
all the features are developed and integrated into the product, i.e. the software is designed, written, and tested
successfully. So, the development product will be a deployable product. It measures the completeness of the product.
 Builds the system in a series of iterations. Each iteration which is based on one or subset of a use case, including:
 Detail analysis,
 Detail design,
 Coding,
 Testing, and
 Integration of the use cases from previous iterations.
 Iteration is incremental in function. Each iteration builds on the use cases developed in the previous iteration.
 Iteration is iterative in terms of code base and rewrite some existing code to make it more flexible.
 Class diagram roughs out concepts for the use case and see how to fit into the software from previous iterations.
 If the use case contains significant workflow element, use sequence diagram to help.
 If a class has complex dynamic behavior (many state changes in response of events), use state diagram.
 Use package diagram to help visualize the logical pieces of the system.

32. CONSTRUCTION (cont.)
 Use patterns if possible to address the common problem.
 Patterns are well known model developed and collected by those with experiences to a set of common problems.
 The conclusions of the Construction Phase are:
 The software product integrated over different modules.
 It provides a user manual.
 Is the product release stable or not?
 Is it meets client requirements or not?
 Is the actual resource cost (amount spent on the project to date) versus planned resource cost (amount earned as
per the schedule) acceptable or not?
TRANSITION
 This is the last phase of the development process. During this phase, the software is released and delivered to the
public or customers. Based on the feedback from the end-users, the product will be made update or change. It is the
process of deployment.

33. TRANSITION (cont.)
 The conclusions of the Transition Phase are:
 It is one type of “beta testing” (it is one type of User Acceptance Testing, where it was performed
by real users of the software application in a real environment) to validate the product as per
user expectations.
 It provides the end-user to satisfy or not.
 All types of training manuals for the user.
 Optimization of code to improve system performance can be addressed in this stage, that includes:
 Bug fixing (elimination of software errors),
 No additional functionalities ( not rather than both functional & non-functional requirements),
 This is the time between beta release to customer and final release of a product,
 User training for beta users, and
 Packaging of software (assembling of code modules that work together to meet goals & objectives).

34. RUP Workflows
Requirements Analysis and Design

35. RUP Workflows (cont.)
Implementation Testing

36. Activities vs Roles (implementation workflow)

37. Activities vs Roles vs Artifacts (implementation workflow)

38. Activities vs Roles vs Artifacts (implementation workflow)

39. Activities in RUP
 Activities in RUP can be divided into the following major categories:
 Planning
 Analysis
 Architecture/Change Management/Tools
 Design
 Implementation
 Integration
 Test/Assessment
Activities can run in parallel.
The effort distribution of each activity depends on the locality of the RUP phase(s).
A sample of relative effort % for each RUP activity for a medium size project is
provided later.

40. Effort Distribution of Activities in RUP

41. Relative Effort of Activities
 Planning 15%
 Analysis 10%
 Architectural/Management 10%
 Design/Integration 15%
 Implementation 30%
 Maintenance 5%
 Test/Assessment 15%