Download presentation
Presentation is loading. Please wait.
Published byShaylee Stringham Modified over 9 years ago
1
1 IBM Software Group ® PRJ270: Essentials of Rational Unified Process Module 1: Best Practices of Software Engineering
2
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
3 Discussion: Symptoms and Root Causes What are some symptoms of software development problems? To what root causes can these symptoms be traced?
4
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
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
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
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
8 Iterative Development Produces Executables Planning Requirements Analysis & Design Implementation Deployment Test Evaluation Management Environment Each iteration results in an executable release.
9
9 Risk Reduction Time Risk Waterfall Risk Iterative Risk Risk Profiles
10
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
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
12 Aspects of Requirements Management Analyze the Problem Understand User Needs Define the System Manage Scope Refine the System Definition Manage Changing Requirements
13
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
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
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
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
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
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
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
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
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
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
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
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
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
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
27 Aspects of Managing Change Change Request Management (CRM) Configuration Status Reporting Configuration Management (CM) Change Tracking Version Selection Software Manufacture
28
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
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
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
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
32 Rational Unified Process (2) Process online + supporting tools Training Consulting and Mentoring +
33
33 History of RUP Rational Process Workbench Major addition of content Major addition of tool mentors Improved Process for independent testing Rational Objectory Process 4.1 1997 Rational Objectory Process 4.0 1996 Rational Unified Process 5.0 1998 Rational Unified Process 2000 Rational Unified Process 2001 Rational Unified Process 5.5 1999 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
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
35 What’s New in RUP 2003.06.00? 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
36 RUP Organization RUP is organized: By time Phases and iterations By content Disciplines
37
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
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
39 Bringing It All Together: The Iterative Approach time content Disciplines group related activities. In an iteration, you walk through all disciplines.
40
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.
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.