1 IBM Software Group ® PRJ270: Essentials of Rational Unified Process Module 1: Best Practices of Software Engineering

2 Module 1 Objectives Understand Rational’s best practices for software development by looking at:  Symptoms and root causes  The Rational Best Practices  An introduction to Rational Unified Process

3 Discussion: Symptoms and Root Causes  What are some symptoms of software development problems?  To what root causes can these symptoms be traced?

4 Symptoms of Software Development Problems User or business needs not met Requirements churn Modules don’t integrate Hard to maintain Late discovery of flaws Poor quality or end-user experience Poor performance under load No coordinated team effort Build-and-release issues

5 Trace Symptoms to Root Causes Needs not met Requirements churn Modules don’t fit Hard to maintain Late discovery Poor quality Poor performance Colliding developers Build-and-release Insufficient requirements Ambiguous communications Brittle architectures Overwhelming complexity Undetected inconsistencies Poor testing Subjective assessment Waterfall development Uncontrolled change Insufficient automation SymptomsRoot CausesBest Practices Ambiguous communications Undetected inconsistencies Ambiguous communications Undetected inconsistencies Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Model Visually (UML) Continuously Verify Quality Model Visually (UML) Continuously Verify Quality Modules don’t fit Modules don’t fit

6 Best Practices Process Made Practical Best Practices Process Made Practical 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 Practice 1: Develop Iteratively

7 Waterfall Development Characteristics  Delays confirmation of critical risk resolution  Measures progress by assessing work-products that are poor predictors of time-to-completion  Delays and aggregates integration and testing  Precludes early deployment  Frequently results in major unplanned iterations Waterfall Process Requirements Analysis Design Code and Unit Test Subsystem Integration System Test

8 Iterative Development Produces Executables Planning Requirements Analysis & Design Implementation Deployment Test Evaluation Management Environment Each iteration results in an executable release.

9 Risk Reduction Time Risk Waterfall Risk Iterative Risk Risk Profiles

10 Practice 2: Manage Requirements Best Practices Process Made Practical Best Practices Process Made Practical 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

11 Requirements Management Means… Making sure you  solve the right problem  build the right system by taking a systematic approach to  eliciting  organizing  documenting  managing the changing requirements of a software application.

12 Aspects of Requirements Management  Analyze the Problem  Understand User Needs  Define the System  Manage Scope  Refine the System Definition  Manage Changing Requirements

13 Problem Solution Space Problem Space Needs Features Software Requirements Test Scripts DesignUser Docs The Product to Be Built Traceability Map of the Territory

14 Practice 3: Use Component Architectures Best Practices Process Made Practical Best Practices Process Made Practical 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

15 Purpose of a Component-Based Architecture  Basis for reuse  Component reuse  Architecture reuse  Basis for project management  Planning  Staffing  Delivery  Intellectual control  Manage complexity  Maintain integrity System-software Middleware Business-specific Application-specific Component-based architecture with layers

16 Resilient and Component-Based Architectures  Resilient  Meets current and future requirements  Improves extensibility  Enables reuse  Encapsulates system dependencies  Component-based  Reuse or customize components  Select from commercially available components  Evolve existing software incrementally

17 Practice 4: Model Visually (UML) Best Practices Process Made Practical Best Practices Process Made Practical 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 Why Model Visually? To:  Capture structure and behavior  Show how system elements fit together  Keep design and implementation consistent  Hide or expose details as appropriate  Promote unambiguous communication  UML provides one language for all practitioners

19 Visual Modeling with Unified Modeling Language Dynamic Diagrams Static Diagrams Activity Diagrams Models Sequence Diagrams Collaboration Diagrams Statechart Diagrams Deployment Diagrams Component Diagrams Object Diagrams Class Diagrams Use-Case Diagrams  Allows multiple views  Provides precise syntax and semantics

20 Visual Modeling Using UML Diagrams 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

21 Practice 5: Continuously Verify Quality Best Practices Process Made Practical Best Practices Process Made Practical 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

22 Continuously Verify Your Software’s Quality Cost Development Phases Software problems are 100 to 1000 times more costly to find and repair after deployment  Cost to Repair Software  Cost of Lost Opportunities  Cost of Lost Customers  Cost to Repair Software  Cost of Lost Opportunities  Cost of Lost Customers

23 Testing Dimensions of Quality 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

24 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

25 Practice 6: Manage Change Best Practices Process Made Practical Best Practices Process Made Practical 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

26 ALERT REPORT Workspace Management Process Integration Parallel Development Build Management Configuration Management is more than just check-in and check- out. What Do You Want to Control?  Secure workspaces for each developer  Automated integration/build management  Parallel development

27 Aspects of Managing Change  Change Request Management (CRM)  Configuration Status Reporting  Configuration Management (CM)  Change Tracking  Version Selection  Software Manufacture

28 Best Practices Reinforce Each Other: An Example Validates architectural decisions early on Addresses complexity of design/implementation incrementally Measures quality early and often Evolves baselines incrementally Ensures users involved as requirements evolve 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

29 RUP Implements Best Practices Best Practices Process Made Practical Best Practices Process Made Practical 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 Achieving Best Practices Through a Process  Iterative approach  Guidance for activities and artifacts  Process focus on architecture  Use cases which drive design and implementation  Models which abstract the system

31 Rational Unified Process (1)  Captures and presents best practices  Is a Web-enabled, tailorable knowledge base that enables efficient development of quality software  Is continuously improved with regular upgrades  Contains templates, guidelines, and online Help  Promotes common vision and culture  Mentors successful use of tools Process ManualsYour Process Online

32 Rational Unified Process (2) Process online + supporting tools Training Consulting and Mentoring +

33 History of RUP Rational Process Workbench Major addition of content Major addition of tool mentors Improved Process for independent testing Rational Objectory Process Rational Objectory Process Rational Unified Process Rational Unified Process 2000 Rational Unified Process 2001 Rational Unified Process Rational Unified Process 2002 Rational Unified Process 2003 Rational Approach Project Management UML 1.3 RealTime Performance Testing Business Modeling Configuration & Change Mgt Objectory UI Design Data Engineering UML 1.1 OMT Booch UML 1.0 Requirements Test Process Tree browser upgraded for enhanced capabilities of creating customized My RUP tree Introduction of RUP Platform providing a configurable process framework Objectory Process 3.8

34 Role of UML in RUP  Rational Unified Process was developed hand-in-hand with the UML.  Many artifacts in Rational Unified Process have a UML representation.  Rational Unified Process also includes guidelines for UML concepts.

35 What’s New in RUP ?  Tree browser upgraded with enhanced capabilities for creating customized MyRUP trees.  New look and feel for entire RUP Web site.  Introduction of RUP Platform providing a configurable process framework.

36 RUP Organization RUP is organized:  By time  Phases and iterations  By content  Disciplines

37 RUP Organization By Time Rational Unified Process has four phases:  Inception: Define the scope of project  Elaboration: Plan project, specify features, baseline architecture  Construction: Build the product  Transition: Transition the product into end-user community InceptionElaborationConstructionTransition time

38 RUP Organization By Content The disciplines are:  Business Modeling  Requirements  Analysis & Design  Implementation  Test RUP content is organized into disciplines. A discipline is a collection of activities that are all related to a major ‘area of concern’.  Deployment  Configuration & Change Management  Project Management  Environment

39 Bringing It All Together: The Iterative Approach time content Disciplines group related activities. In an iteration, you walk through all disciplines.

40 Review  Rational’s Best Practices are: Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change  Best Practices guide software engineering by addressing root causes.  Best Practices reinforce each other.  Rational Unified Process is a means of achieving Best Practices.