SENG 623 Unified Software Process - PowerPoint PPT Presentation

1 / 40
About This Presentation
Title:

SENG 623 Unified Software Process

Description:

Reduced integration time and effort. 30. Benefits (cont.) Robust architecture ... Grady Booch, Robert Martin and Jim Newkirk Object-Oriented Analysis and Design ... – PowerPoint PPT presentation

Number of Views:43
Avg rating:3.0/5.0
Slides: 41
Provided by: werb4
Category:

less

Transcript and Presenter's Notes

Title: SENG 623 Unified Software Process


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

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

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

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

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

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

Software Development Process
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

8
4 Ps
  • 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
9
4 Ps (cont.)
  • People are crucial
  • Projects make the product
  • Product is not just the code
  • Process directs Projects
  • Tools are integral to the process

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

11
Use Case Driven (cont.)
  • Why UseCase Driven
  • "Use case driven" 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

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

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

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

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

16
1. Initiating the development process

17
  • 2. Binding the core workflows together

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

19
Role of Use Cases in System Development
20
Use-Case Realization in the Analysis Model
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.

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

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

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

25
Architecture Baseline
  • Iteratively generated
  • Includes an Architecture Description

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

27
Iterations through Workflows
28
Benefits of Iterative and Incremental
  • Early risk management and mitigation

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

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

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

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)

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

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.j
    sp
  • From Waterfall to Iterative Lifecycle - Philippe
    Kruchten, Rational Software, Canada, 2000
  • A comparison of RUP and XP - John Smith,
    Rational Software, Australia, 2001

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 -gt User Stories
  • UP uses UML and requires more extensive modeling
    (product consists of more than just code)

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

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

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.

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/j
    avabeans/
  • Grady Booch, Robert Martin and Jim Newkirk
    Object-Oriented Analysis and Design with
    Applications (3rd Edition).

40
Questions?
Write a Comment
User Comments (0)
About PowerShow.com