The document provides an overview of the Unified Software Process (UP). It discusses the history and development of UP over decades. Key aspects of UP include being use-case driven, architecture-centric, and iterative and incremental. UP recognizes four important aspects of software development: people, project, product, and process. Use cases drive the entire development process. UP emphasizes iterative development and producing incremental working software. The Rational Unified Process (RUP) provides additional tools and content to support applying UP.

1. SENG 623 Unified Software
Process
Linda (Yongxue) Cai
Kobe Davis
Guy Davis
1

2. The Unified Process
Agenda
• Overview
• 4 P’s
• Use-Case Driven
• Architecture Centric
• Iterative and Incremental
• RUP
• UP, Agile?
• Conclusion
2

3. History
• Developed over three decades
• Ericsson Approach, 1967
• Objectory AB established by Ivar Jacobson,
1987
• Developed the Objectory process, which extends
Ericsson approach
• Rational Software Corporation acquires
Objectory AB, 1995
• Rational Objectory process is created
3

4. History (cont.)
• UML standardized in 1997, supported by OMG
• Rational Objectory Process defines all models using
UML
• Through acquisitions, mergers and internal
development the Rational Objectory Process is
extended to cover all aspects of the software
development life cycle, the new process is called
the Rational Unified Process
4

5. History (cont.)
• The Unified Process was released to the
general public in the form of the book
‘The Unified Software Development
Process. (Jacobson, Booch, Rumbaugh)’,
1999
5

6. What is a Process?
• Define Who is doing What, When to do it, and
how to reach a certain goal.
User’s requirements Software system
Software Development Process
6

7. Overview
• The Unified Software Development Process is a
software development process that is ‘use-case
driven, architecture-centric and iterative and
incremental’. (Jacobson, Booch, Rumbaugh)
• The Unified Process is component based
• The Unified Process uses the Unified Modelling
Language for documentation and design
7

8. 4 P’s
• The Unified Process recognized four
aspects of software development as being
equally important
• People
• Project
• Product
• Process
• (Tools)
Figure 2.1 The Unified Software Development Process
8

9. 4 P’s (cont.)
• People are crucial
• Projects make the product
• Product is not just the code
• Process directs Projects
• Tools are integral to the process
9

10. Use-Case Driven
• Some Definitions
• User – Human Users + Other Systems
• Use Case – A piece of functionality
• Use-Case Model – All the use cases
• Use-Case Driven – Development
process follows a flow…
10

11. Use Case Driven (cont.)
• Why Use–Case Driven
quot;Use case drivenquot; means writing the user
manual first, then writing the code. This
practice reinforces the fundamental notion
that a system must conform to the needs of
the users, instead of your users conforming
to the system. [Doug 2001]
11

12. Use-Cases
• Why Use Cases
• Systematic and intuitive means of capturing
functional requirements
• Drives the whole development process
• Supports identifying software to meet user
goals
• Evaluate what system should do for each user
• Provides complete specification for all possible
uses of the system
12

13. How do Use Cases drive the process?
• Capturing the Requirements
• The goal of the requirements process
• Use cases are requirements artifact
1. used by the customers
2. used by the developers
13

14. How do Use Cases drive the process?
Use Cases also provide input for…
• Finding and specifying classes,
subsystems, and interfaces
• Finding and specifying test cases
• Planning development iterations and
systems integration
14

15. Use-Cases (cont.)
Driving the Development Process
• Use cases initiate series of workflows
• Use cases bind the core workflows together
• Help develop classes, user interfaces
• Used to verify instances of classes
• Support trace ability through the system
• Improve maintainability as changes are made
15

16. 1. Initiating the development process
•
16

17. 2. Binding the core workflows together
Implemen
Requirem Analysis Design Test
tation
ents
17

18. More about Use Cases
• Carrying out iterative development
• Devising the architecture
• Providing a starting point for the user
manual
• Good Estimation Tool
18

19. Role of Use Cases in System Development
19

20. Use-Case Realization in the Analysis Model
20

21. Pros & Cons: Use Cases
• Advantages:
• Valuable and coherent portions of the system
(use cases) are developed, providing business
value to your users.
• Users can easily comprehend your plan because
it is organized based on things that they do.
• Developers learn the business while they
implement use cases.
21

22. Pros & Cons: Use Cases (cont.)
• Disadvantages:
• Use cases aren't a complete definition of your
requirements
• End-User is not directly involved
• All use cases aren't created equal
• Reuse becomes difficult
22

23. Architecture-Centric Approach
• What is Architecture?
• Most important dynamic and static aspects of
system
• Structural elements and interfaces that will
comprise a system together with their behavior
• Composition of elements into progressively
larger systems
• Architectural style that guides the organization
23

24. Architecture-Centric (cont.)
• Why do we need an Architecture?
• Understand the system
• Organize development
• Foster reuse
• Evolve the system
24

25. Architecture Baseline
• Iteratively generated
• Includes an Architecture Description
25

26. Unified Process Phases
• Cycles throughout the product lifetime
• Each cycle comprised of four phases
• Gated progress between phases (milestones)
• Each phase consists of iterations
26

27. Iterations through Workflows
27

28. Benefits of Iterative and
Incremental
• Early risk management and mitigation
28

29. Benefits (cont.)
• Reduced integration time and effort 29

30. Benefits (cont.)
• Robust architecture at early stage
• Change is more manageable
• Better training of team in workflows
• Higher level of reuse
• Higher overall product quality
30

31. Summary
• Use Case Driven, Architecture Centric, Iterative
and Incremental
• UP is a framework designed for configuring
• Use what you need (tailor)
• It’s all about risk
31

32. RUP
• By purchasing RUP, Rational provides the
following over and above the Unified
Process
• On-line Knowledge base
• Technology Plug-ins
• RUP Exchange (Plug-ins currently provide content
from IBM, Microsoft, BEA, Sun, HP, and other
companies)
32

33. RUP
• http://programs.rational.com/success/
• Numerous ‘success stories’ from companies
who have implemented or are using the
Rational Unified Process
• Ericsson (80% fewer bugs, 100% productivity
increase
• Lockheed Martin Canada
• Merrill Lynch
33

34. UP, Agile or Waterfall?
• The Unified Process has evolved beyond a waterfall
approach.
• Use Cased driven and Iterative and Incremental approach
provides a basis for Agile Methods
• http://www.rational.com/products/rup/whitepapers.jsp
• From Waterfall to Iterative Lifecycle - Philippe Kruchten,
Rational Software, Canada, 2000
• A comparison of RUP® and XP - John Smith, Rational
Software, Australia, 2001
34

35. Comparing UP to XP
• Team Sizes
• UP is designed to scale and can be tailored for use by
small to very large teams.
• Metaphor and Model
• Use Cases -> User Stories
• UP uses UML and requires more extensive modeling
(product consists of more than just code)
35

36. Comparing UP to XP
• Collective Ownership / Programming
• UP can be tailored to match the practices of XP
36

37. Comparing UP to XP
• Testing
• UP requires a testing model, test for each use case
(similar to XP acceptance tests). UP can be tailored to
fit XP practices
• Reporting
• UP is iterative and incremental, progress can be tracked
similarly to XP
37

38. Comparing UP to Agile Processes
• Overall
• UP is a process framework meant to be tailored,
XP can be likened to a tailored version of UP
• UP differs on Architecture and Product
• Architecture does not just happen
• Simple code does not ensure a solid architecture
• Product consists of more than just code, ie.
Documentation, models etc.
38

39. References
• Doug Rosenberg, Kendall Scott, Top Ten Use Case
Mistakes, Feb. 2001
• Jacobson, Booch, and Rumbaugh. The Unified Software
Development Process. Addison-Wesley. Boston, MA.
1999.
• Rational Software Corp. Rational Unified Process: Best
Practises for Software Development Teams. 2002. http://
www.rational.com/products/whitepapers/100420.jsp
• Sun Microsystems Ltd. JavaBeans Component
Architecture. 2002. http://java.sun.com/products/
javabeans/
• Grady Booch, Robert Martin and Jim Newkirk Object-
Oriented Analysis and Design with Applications (3rd
Edition).
39

40. Questions?
40