1. Rational Unified Process Fundamentals Module 1: Best Practices of Software Engineering Rational Unified Process Fundamentals Module 1: Best Practices of Software Engineering

2. 2 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved Objectives  Identify activities for understanding and solving software engineering problems.  Explain the Six Best Practices.  Present RUP within the context of the Six Best Practices.

3. 3 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved Module 1 Content Outline  Software development problems  The Six Best Practices  RUP within the context of the Six Best Practices

4. 4 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved 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 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved 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 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved Module 1 Content Outline  Software development problems  The Six Best Practices  RUP within the context of the Six Best Practices

7. 7 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved 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

8. 8 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved 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 Code and unit test Design Subsystem integration System test Waterfall Process Requirements analysis

9. 9 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved Iterative Development Produces an Executable Initial Planning Requirements Analysis & Design Implementation Deployment Test Evaluation Management Environment Each iteration results in an executable release

10. 10 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved Risk Reduction Time Risk Waterfall Risk Iterative Risk Risk Profiles

11. 11 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved 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

12. 12 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved Requirements Management  A requirement is a condition or capability a system must have.  Managing the requirements of a project offers a number of solutions to the root causes of SW development problems.  A disciplined approach is built into requirements management.  Communications are based on defined requirements  Requirements can be prioritized and traced.  An objective assessment of functionality and performance is possible.  Inconsistencies are detected more easily.

13. 13 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved Requirements Management 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.

14. 14 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved Aspects of Requirements Management  Analyze the Problem  Understand User Needs  Define the System  Manage Scope  Refine the System Definition  Manage Changing Requirements

15. 15 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved Problem Solution Space Problem Space Needs Features Software Requirements Test Scripts DesignUser Docs The Product to Be Built Traceability Map of the Territory

16. 16 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved 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

17. 17 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved Resilient Component-Based Architectures  A system’s architecture is perhaps the most important deliverable for the purpose of managing the diverse viewpoints of the various stakeholders.  The architecture is helpful in controlling the incremental and iterative development of a system throughout its lifecycle.

18. 18 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved Resilient 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

19. 19 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved 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

20. 20 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved 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

21. 21 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved 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

22. 22 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved Visual Modeling with Unified Modeling Language Activity Diagrams Models Dynamic Diagrams Static Diagrams  Multiple views  Precise syntax and semantics Sequence Diagrams Collaboration Diagrams Statechart Diagrams Deployment Diagrams Component Diagrams Object Diagrams Class Diagrams Use-Case Diagrams

23. 23 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved 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

24. 24 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved 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

25. 25 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved Continuously Verify Your Software’s Quality  Verifying SW quality offers a number of solutions to the root causes of SW development problems.  Project status is objective, not subjective.  Objective assessment exposes inconsistencies in requirements, design and implementation.  Testing can be focused on the highest areas of risk.  Defects are identified earlier thus reducing the cost of fixing them.

26. 26 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved Continuously Verify Your Software’s Quality Cost TransitionConstructionElaborationInception 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

27. 27 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved Testing Dimensions of Quality Reliability  Test 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

28. 28 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved 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

29. 29 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved Test Within the Product Development Lifecycle

30. 30 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved 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

31. 31 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved Why manage change?  A key challenge when you are managing SW-intensive systems is that you must cope with multiple developers organized into teams, possible at different sites, working together on multiple iterations, releases, products, and platforms.  Without some sort of disciplined control, the development process rapidly degenerates into chaos.

32. 32 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved ALERT REPORT Workspace Management Process Integration Parallel Development Build Management CM 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

33. 33 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved Aspects of a CM System  Change Request Management (CRM)  Configuration Status Reporting  Configuration Management (CM)  Change Tracking  Version Selection  Software Manufacture

34. 34 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved Unified Change Management (UCM) UCM involves:  Management across the lifecycle  System  Project Management  Activity-Based Management  Tasks  Defects  Enhancements  Progress Tracking  Charts  Reports

35. 35 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved Best Practices Reinforce Each Other 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

36. 36 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved Module 1 Content Outline  Software development problems  The Six Best Practices  RUP within the context of the Six Best Practices

37. 37 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved Rational Unified Process 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

38. 38 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved Achieving Best Practices  Iterative approach  Guidance for activities and artifacts  Process focus on architecture  Use cases which drive design and implementation  Models which abstract the system

39. 39 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved A Team-Based Definition of Process A process defines Who is doing What, When, and How, in order to reach a certain goal. New or changed requirements New or changed system Software Engineering Process

40. 40 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved InceptionElaborationConstructionTransition Process Structure - Lifecycle Phases 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 time

41. 41 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved Phase Boundaries Mark Major Milestones InceptionElaborationConstructionTransition Lifecycle Objective Milestone (LCO) Lifecycle Architecture Milestone (LCA) Initial Operational Capability Milestone (IOC) Product Release time

42. 42 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved Iterations and Phases An iteration is a distinct sequence of activities based on an established plan and evaluation criteria, resulting in an executable release (internal or external). PreliminaryIterationArchitect.IterationArchitect.IterationDevel.IterationDevel.IterationDevel.IterationTransitionIterationTransitionIteration InceptionElaborationConstructionTransition Minor Milestones: Releases

43. 43 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved Bringing It All Together: The Iterative Approach Disciplines group activities logically In an iteration, you walk through all disciplines

44. 44 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved Disciplines Produce Models

45. 45 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved Disciplines Guide Iterative Development Business Modeling: Workflow Requirements: Workflow

46. 46 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved Overview of Rational Unified Process Concepts

47. 47 Unified Software Practices Copyright © 1999-2001 Rational Software, all rights reserved Review  Best Practices guide software engineering by addressing root causes.  Best Practices reinforce each other.  Process guides a team on who does what, when, and how.  Rational Unified Process is a means of achieving Best Practices.