1. Information Systems Development Slovak University of Technology Faculty of Material Science and Technology in Trnava

2. Rational Unified Process

3. What is RUP A software development approach that is iterative, architecture- centric and use-case driven. A well-defined and structured software engineering process. A process product providing a customizable process framework.

4. Relations between UP and RUP - Methodology UP is founded on Ericsson and Rational methods - The base of methodology is modeling of aspects: what, who and where, in the process of sw development - There is a several commercial variant of UP methodology - The RUP is most widely distributed – in many ways it renew and extend UP methodology - In UML thinking: methodology UP defines a class of sw development methods, RUP inherit all property, whereby some of them overbild with new definition.

5. Role UML in RUP  Methodology Rational Unified Process has been developed „hand-in-hand“ with modeling language UML.  Many elements of Rational Unified Process has representation in UML.  Rational Unified Process contains also guidelines for UML work session.

6. Language is not enough to build a system Modeling Language Unified Process Team-Based Development

7. The main principles of the RUP  Attack major risks early and continuously…  Ensure that you deliver value to your customer  Have a maniacal focus on working software  Accommodate change early in the project  Baseline an executable architecture early on  Build your system with components  Work closely together as one team  Make quality a way of life, not an afterthought

8. Late discovery of issues Subjective and error-prone measure of progress Late integration and testing Precludes early deployment Frequently results in major unplanned iterations Integration System Test Code Design Requirements Waterflow lifecycle

9. Late Design Breakage 100% Project Schedule Development (% coded) Target Date Integration Begins Requirements Design Code Integration Test What Happens in Practice ?

10. Waterfall - some problems  A waterfall approach can not properly handle the growing complexity associated with Increased duration Increased application size Larger and/or distributed team Increased technical complexity Novelty of technology  The root cause of the problem with the waterfall lifecycle is that it does not allow to identify and mitigate risks early enough

11. The Rational Best Practices - principles  Develop only what is necessary Lean process, agility  Minimize paperwork  Be flexible Requirements, plan, usage of people, etc…  Learn from earlier mistakes Feedback loops Process improvement  Revisit risks regularly  Establish objective, measurable criteria for progress  Automate Support process with software development tools

12. The Rational Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change The Rational Best Practices Rational Unified Process is a means of achieving Best Practices. Implementation

13. Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change The Rational Best Practices

14.  Discover the biggest hazard before investing.  Allows early user feed back.  Allows continual testing and integration. time Iteration 1 Iteration 2 Iteration 3 P R D C I T P R D C I T P R D C I T

15. The Rational Best Practices Risk Reduction Time Risk Waterfall Risk Iterative Risk

16. The Rational Best Practices 100% Project Schedule Waterfall Project Profile Modern Project Profile Development Progress (% coded) Sequential phases, but iterative activities Integration Begins

17. The Rational Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change

18. The Rational Best Practices Aspects of manage requirement  Analysis of problem area  Understanding of user requirements  Describing of the system  Fine down of system description  Managing of requirements changes

19. The Rational Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change

20. The Rational Best Practices R1 R2. RN Ra Rb. Rc FaFbFc Ri Rj. Rk FiFjFk Rx Ry. Rz FxFyFz System Requirements Software Requirements Software Functions Common Data Traditional Functional Decomposition Many dependencies creates inflexible systems

21. The Rational Best Practices Ri Rj. Rk Ra Rb. Rc Rx Ry. Rz System Requirements Software Requirements Layered, Component-based Architecture Common Mechanisms Domain Components Functions R1 R2. RN Component architecture provides flexibility

22. The Rational Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change

23. Why model visually?  To capture structure and behavior  To show how system elements fit together  To keep design and implementation consistent  To hide or expose details as appropriate  To promote unambiguous communication UML provides one language for all practitioners

24. Why model visually? Activity Diagrams Models Static Diagrams Sequence Diagrams Collaboration Diagrams Statechart Diagrams Deployment Diagrams Component Diagrams Object Diagrams Class Diagrams Use-Case Diagrams Dynamic Diagrams Allows multiple views

25. The Rational Best Practices Actor A Use Case 1 Use Case 2 Actor B user : Clerk mainWnd : MainWnd fileMgr : FileMgr repository : Repository document : Document gFile : GrpFile 9: sortByName ( ) L 1: Doc view request ( ) 2: fetchDoc( ) 5: readDoc ( ) 7: readFile ( ) 3: create ( ) 6: fillDocument ( ) 4: create ( ) 8: fillFile ( ) Window95 ¹®¼­°ü¸® Ŭ¶óÀ̾ðÆ®.EXE Windows NT ¹®¼­°ü¸® ¿£Áø.EXE Windows NT Windows95 Solaris ÀÀ¿ë¼­¹ö.EXE Alpha UNIX IBM Mainframe µ¥ÀÌŸº£À̽º¼­¹ö Windows95 ¹®¼­°ü¸® ¾ÖÇø´ Document FileManager GraphicFile File Repository DocumentList FileList user mainWndfileMgr : FileMgr repositorydocument : Document gFile 1: Doc view request ( ) 2: fetchDoc( ) 3: create ( ) 4: create ( ) 5: readDoc ( ) 6: fillDocument ( ) 7: readFile ( ) 8: fillFile ( ) 9: sortByName ( ) ƯÁ¤¹®¼­¿¡ ´ëÇÑ º¸±â¸¦ »ç¿ëÀÚ°¡ ¿äûÇÑ´Ù. È­ÀÏ°ü¸®ÀÚ´Â Àоî¿Â ¹®¼­ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼­ °´Ã¼¿¡ ¼³Á¤À» ¿äûÇÑ´Ù. È­¸é °´Ã¼´Â ÀоîµéÀÎ °´Ã¼µé¿¡ ´ëÇØ À̸§º°·Î Á¤·ÄÀ» ½ÃÄÑ È­¸é¿¡ º¸¿©ÁØ´Ù. Forward and Reverse Engineering Target System Use Case 3 Use-Case Diagram Class Diagram Collaboration Diagram Sequence Diagram Component Diagram Statechart Diagram Deployment Diagram Visual Modeling Using UML Diagrams

26. The Rational Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change

27. The Rational Best Practices Reliability  Test that the application behaves consistently and predictably. Performance  Test online response under average and peak loading Functionality  Test the accurate workings of each usage scenario Usability  Test application from the perspective of convenience to end-user. Supportability  Test the ability to maintain and support application under production use Testing dimensions of quality:

28. The Rational Best Practices UML Model and Implementation Tests Iteration 1 Test Suite 1 Iteration 2 Test Suite 2 Iteration 4 Test Suite 4 Iteration 3 Test Suite 3 Test Each Iteration It is often cheaper to find a problem through early implementation and testing, than through detailed design review. It is often cheaper to find a problem through early implementation and testing, than through detailed design review.

29. The Rational Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change

30. Changed requirements incomes from z multiple sources during whole life cycle. Help Desk User intervention Programmers intervention Customer intervention Marketing New items New requirements Errors Changed requirements Reqt Design Code Test Maint Weinberg, ‘95 Master Node for authorizing One channel for receiving

31. RUP – Phases of development Elaboration Construction Transition Milestones Inception Time

32. RUP – Phases of development Inception: Understand, what to build Vision, high-level requirements, business case No detail requirements Elaboration: Understand, how to build Base architecture, detail requirements No detail design Construction: Creating of product Functional product, finished system tests Transition: Validation of solution Finished acceptance tests

33. RUP – Phases of development 10% 30%50%10% Schedule Source: Walker Royce 1995

34. RUP – iteration Iteration - An iteration is a distinct sequence of activities with an established plan and evaluation criteria, resulting in an executable release. Partial iteration InceptionElaborationConstructionTransition Preliminary Iteration Architecture Iteration Architecture Iteration Development Iteration Development Iteration Development Iteration Transition Iteration Transition Iteration

35. RUP – iteration Time Requir. Design Implem. Test Deploy Iteration 1 Iteration 2 Iteration 3

36. RUP – iteration Planning Requirements Analysis & Design Implementation Deployment Test Evaluation Management Environment Each iteration results in an executable release.

37. Inception: Know What to Build InceptionElaborationConstructionTransition  Prepare document and initial business case  Include risk assessment and resource estimate  Develop high-level project requirements  Initial use-case and domain models (10-20% complete)  Manage project scope  Reduce risk by identifying all key requirements  Acknowledge that requirements will change Manage change, use iterative process

38. InceptionElaborationConstructionTransition Elaboration: Know How to Build It  Detail requirements (up to 80% complete)  Produce executable and stable architecture  Define, implement and test interfaces of major components  Identify dependencies on external components and systems.  Some key components will be partially implemented  Up to 10% of code is implemented.  Drive architecture with key use cases  20% of use cases drive 80% of the architecture  Design, implement and test key scenarios for use cases

39. Elaboration: Know How to Build It InceptionElaborationConstructionTransition  Verifying of architecture  Reliability: Stress test  Scalability and Performance: Load test  Continuously assess business case, risk profile and development plan

40. InceptionElaborationConstructionTransition Construction: Build The Product  Complete requirements and design model  Design, implement and test each component  Prototype system and involve end users  Build daily or weekly with automated build process  Test each build  Automate regression testing  Load and stress test to ensure architectural integrity  Deliver fully functional software (beta release)  Includes training material, user and deployment documentation  Produce release descriptions

41. InceptionElaborationConstructionTransition Transition: Deploy to End Users  Produce incremental ‘bug-fix’ releases  Update user manuals and deployment documentation  Update release descriptions  Execute cut-over  Conduct “post-mortem” project analysis

42. RUP – disciplines Disciplines are:  Business Modeling  Requirements  Analysis & Design  Implementation  Test  Deployment  Configuration & Change Management  Project Management  Environment RUP – is organized into disciplines. Disciplines are collections of activities, that are all joined into base „area of interest“.

43. RUP – phases and iterations

44. T I M E In an, you may walk through all disciplines In an iteration, you may walk through all disciplines

45. Created models Process ViewDeployment View Logical View Use-Case View Implementation View End-user Functionality Programmers Software management Performance, scalability, throughput System integrators System topology, delivery, installation, communication System engineering Analysts/Designer s Structure

46.  Use cases records functional requirements  Use cases are a basement analysis, design, testing and documentation Use-Case Model Analysis & Design Model Implementation Model Test Model Requirements realized by implemented by verified by Analysis & Design Implementation Test Created models

47. Various disciplines produce Models … Analysis & Design Require- ments Business Modeling Implement- ation Implemented By Implementation Model Design Model Use-Case Model Business Use- Case Model Business Object Model Realized By Automated By Realized By Test Verified ByValidated By BBB B Deployment Input To Created models

48. Business Modeling Workflow Requirements Workflow

49. A Structured Process: Role, Artifact, Activity

50. A Structured Process: Guidelines, Templates, Tool Mentors, …

51. Overview of Rational Unified Process Concepts

52. Role: A set of related responsibilities that may be assigned to an individual or a team in the development organization Activity: A unit of work a Role may be asked to perform Artifact: A piece of information that is produced, modified, or used by an Activity

53. Roles Are Used for Resource Planning Resource Pavol Mária Jozef Silvia Jana Each individual in the project is assigned to one or more roles Role Architect System Analyst Requirements Specifier Test Analyst Tester One role can be assigned to one or more individuals Activities Identify Design Mechanisms Find Actors and Use Cases Detail a Use Case Identify Test Ideas Analyze Failure