Unified Process


Published on

A meta-methodology (from my MSc in Software Engineering program 2002)

Published in: Technology, Business
  • I enjoyed reading this. I would like to include that at Cycloides, we will share our thought process, experience, insight, tools, ideas, techniques and templates, so that you understand the behavior of your project and how it is affected by certain limitations and what recurring techniques and approaches to leverage as you cope with constraints. You can visit below website for better insight: http://cycloides.com/I enjoyed reading this. I would like to include that at Cycloides, we will share our thought process, experience, insight, tools, ideas, techniques and templates, so that you understand the behavior of your project and how it is affected by certain limitations and what recurring techniques and approaches to leverage as you cope with constraints. You can visit below website for better insight: http://cycloides.com/
    Are you sure you want to  Yes  No
    Your message goes here
  • thank you very much such wonderful gist great content
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

  • Unified Process

    1. 1. SENG 623 Unified Software Process Linda (Yongxue) Cai Kobe Davis Guy Davis 1
    2. 2. The Unified Process Agenda • Overview • 4 P’s • Use-Case Driven • Architecture Centric • Iterative and Incremental • RUP • UP, Agile? • Conclusion 2
    3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 16. 1. Initiating the development process • 16
    17. 17. 2. Binding the core workflows together Implemen Requirem Analysis Design Test tation ents 17
    18. 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. 19. Role of Use Cases in System Development 19
    20. 20. Use-Case Realization in the Analysis Model 20
    21. 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. 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. 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. 24. Architecture-Centric (cont.) • Why do we need an Architecture? • Understand the system • Organize development • Foster reuse • Evolve the system 24
    25. 25. Architecture Baseline • Iteratively generated • Includes an Architecture Description 25
    26. 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. 27. Iterations through Workflows 27
    28. 28. Benefits of Iterative and Incremental • Early risk management and mitigation 28
    29. 29. Benefits (cont.) • Reduced integration time and effort 29
    30. 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. 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. 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. 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. 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. 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. 36. Comparing UP to XP • Collective Ownership / Programming • UP can be tailored to match the practices of XP 36
    37. 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. 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. 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. 40. Questions? 40