1. 1 IBM Software Group ® PRJ270: Essentials of Rational Unified Process Module 4: RUP Content

2. 2 Module 4 Objectives Be introduced to the content of RUP and its application by investigating:  RUP disciplines Requirements Business Modeling Configuration & Change Management Environment Project Management Analysis & Design Implementation Test Deployment

3. 3 Review: RUP Organization Based on Content The disciplines are:  Business Modeling  Requirements  Analysis & Design  Implementation  Test RUP content is organized into disciplines. Discipline: a collection of activities that are all related to a major “area of concern.”  Deployment  Configuration & Change Management  Project Management  Environment

4. 4 RUP Disciplines RUP has disciplines. Artifacts from each discipline evolve over the iterative process.

5. 5 Disciplines Produce and Share Models 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 … each of those models is Assessed Deployment Input To

6. 6 Requirements Discipline Purpose  Establish and maintain agreement with the customers and other stakeholders on what the system should do  Provide system developers with a better understanding of the system requirements  Define the boundaries of (delimit) the system  Provide a basis for planning the technical contents of iterations  Provide a basis for estimating cost and time to develop the system  Define a user-interface for the system, focusing on the needs and goals of the users

7. 7 Requirements Types  Features: used for scoping the project  Main audience: Stakeholders  Documented in the Vision artifact  Functional Requirements: specifying interactions with system users  Main audience: users and project team  Modeled in the Use-Case Model artifact  Supplementary Requirements: specifying functionality, usability, reliability, performance, supportability requirements, and design constraints  Main audience: architects and designers  Documented in the Supplementary Specifications artifact

8. 8 Major Concepts in the Use-Case Model An actor represents a person or another system that interacts with the system. A use case defines a sequence of actions a system performs that yields a result of observable value to an actor. Actor Use Case

9. 9 Actor System Actor  Actors are not part of the system. They represent roles a user of the system can play.  An actor can actively interchange information with the system.  An actor can be a passive recipient of information.  An actor can be a giver of information.  An actor can represent a human, a machine or another system.

10. 10 Charlie C d harlieas epotstaff DepotStaff Charlieasdepot manager DepotManager A User Can Act as Several Actors

11. 11 Use Case  A use case specifies a dialogue between an actor and the system.  A use case is initiated by an actor to invoke a certain functionality in the system.  A use case is a complete and meaningful flow of events.  Taken together, all use cases constitute all possible ways of using the system.

12. 12 A Scenario - One Path Through a Use Case  A use case can have many instances.  A scenario is a described use-case instance: a specific sequence of actions that illustrates behaviors of the system. Register for Courses Student Course Catalog

13. 13 A Sample UML Diagram: Use Cases A University Course Registration System Professor Select Courses to Teach Student Course Catalog Register for Courses Maintain Student Information Maintain Professor Information Registrar Billing System Close Registration

14. 14 What Is in a Use-Case Model?  Actors and their descriptions  Use-case diagrams showing relationships  For each use case:  Name and brief description  Textual specification of: Flow of events Pre-conditions and post-conditions (optional) Special requirements Other diagrams, such as activity or state diagrams

15. 15 Review: Disciplines Produce and Share Models 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 Analysis Model Realized By Automated By Realized By Test Verified ByValidated By BBB B … each of those models is Assessed Deployment Input To

16. 16 Use Cases as a Basis for Iteration Planning Use-Case Model Supplementary Specifications Iteration Plan Fine-grained plan for a single iteration Project Management Constraints During Elaboration, use cases are implemented to validate the architecture.

17. 17 Use Cases as a Basis for System Modeling (1) verification realizatio n Use-Case Model (requirements) Implementation Model (source code) Test Scripts influence Design Model (classes and objects)

18. 18 Use Cases ExecAnalysis Classes Design Classes Source Code Use Cases as a Basis for System Modeling (2)

19. 19 Use Cases as a Basis for Test Planning The complete behavior of a use case is tested using Test Scripts and Test Suites. Test Suite Test Script Test Suite

20. 20 Requirements Traceability Trace product requirements (features) into detailed requirements Trace requirements into design Trace requirements into test procedures Trace requirements into user documentation and training materials

21. 21 Business Modeling Discipline  Purpose  Understand problems in target organization and identify potential improvements  Ensure customer and end user have common understanding of target organization  Derive system requirements to support target organization  Understand structure and dynamics of organization in which system is to be deployed  This discipline uses an approach very similar to that of system development

22. 22 Two Business Models What Business Models Show  Customers and vendors  Business processes  Organizational structure  Roles and responsibilities  Products  Internal deliverables  Events Business Use-Case Model Business Analysis Model

23. 23 Business Modeling and Software Development Business Modeling acts as:  Input to Requirements  Business Use-Case Models help you to understand the requirements of the system and identify system use cases  Input to Analysis & Design  Business entities from the Business Analysis Model help identify entity classes in the Analysis Model

24. 24 Configuration & Change Management Discipline Purpose: controls change to, and maintains the integrity of, a project’s artifacts.

25. 25 Configuration Management (CM) Configuration Management tools Support members of the project team (especially those involved in development) by enabling:  Baselining of versions and concurrent development  Configuration identification and management  Configuration status accounting and change tracking  Version selection  Software manufacture  Measurement accounting by element  A framework for Work Breakdown Structure design The Product Directory Structure contains elements of the product under development

26. 26 Sample Product Directory Structure The structure should be initiated during Inception and detailed as the product is defined.

27. 27 Change Request Management (CRM) Two basic types of requests need to be managed:  Defects  CRM supports all members of the team by managing the processes to acquire, assign, correct, and report defect-related activities.  Enhancement Requests  CRM supports the Change Control Board in the administration of assessment and disposition of product change proposals.

28. 28 Change Request Management (CRM)

29. 29 Measurement  Quality:  Describes the state of the product based on the type, number, rate, and severity of defects found and fixed during the course of product development  Progress:  Measurements derived under this aspect, either through audits or raw data, are useful in determining the overall completeness status of the project.

30. 30 Environment Discipline  Purpose: Focuses on the activities necessary to configure the process for a project. Defines what improvements are realistic under the project’s circumstances: Current process Current tools Current staff skills and capabilities for change Current problems and possible improvement objectives

31. 31 Important Environment Artifacts Development Process: is a configuration of the underlying RUP framework that meets the needs of the project following it. Development Case: describes the development process that you have chosen to follow in your project.

32. 32 Development Case  Reflects decisions made by team leaders of the project  Describes the development process that you have chosen to follow in your project  Is contained in Environment discipline  Is created early in Inception, and updated during project Development Case Select from RUP knowledge base Minimize cost of process definition

33. 33 Development Case (Partial Example) ArtifactsHow to UseReview Details Tools Used / Templates / Examples IncepElabConstTrans GlossaryMust Formal – External MS Word/Template: Glossary Requirements Management Plan Must Formal – External RequisitePro/Template: Requirements Management Software Requirements Specification Must Formal – External MS Word/Template: Software Requirements Specification Supplementary Specification Must Formal – External RequisitePro/Template: Supplementary Specification Use-Case ModelShouldMust Formal – External Rose/Template: Use-Case Model Use-Case PackageCould InformalRose/Embedded Stakeholder Requests Must Formal – External ClearQuest/Template: Stakeholder Requests VisionMust Formal – External RequisitePro/Template: Vision

34. 34 Project Management Discipline Purpose:  Provide a framework for managing software-intensive projects.  Provide practical guidelines for planning, staffing, executing, and monitoring projects.  Provide a framework for managing risk. Main artifacts are:  Project Plan  Risk Management Plan  Business Case  Iteration Plans

35. 35 Business Case  Involves estimation of development costs based on:  The current Product Directory Structure  Make, buy, reuse decisions made by the architect  Estimation of project benefits to establish ROI  Estimation fidelity improves as the project goes through phases (shown before)  Typically the “justification” is made for the next phase, with scoped estimates for the rest.

36. 36 Iteration Plan  Focus during Inception and Elaboration  Project scoping and risk reduction, especially architectural risks  Focus during Construction and Transition  Development efficiency and product quality

37. 37 Discussion: Strategies for Iterative Development Evolutionary (2) Incremental delivery (3) “Grand design” (4) Conceptual prototype Architectural baseline ReleaseDelivery #1#2#n+1#..#m#m+1#m+2.. Iter. No. Prel. Iteration Elabo- ration ConstructionTransitionInception Incremental (1)

38. 38 Planning for Iterative Development Iteration Plan (next) Iteration Plan (current) Fine-grained Plans Phase Plan Iterations for each phase Number of iterations Objectives Duration Coarse-grained Plan Phases and major milestones What and when Project Plan “Roadmap”

39. 39 RUP Planning Guide for Microsoft® Project 2002  Free download available on RDN  Allows you to rightsize your project plan by helping you to:  plan the number of iterations to include in each project phase  incrementally plan each iteration by selecting from a suggested list of: tasks to be undertaken potential deliverables and artifacts to be produced roles to be responsible.  Contains one-click access to RUP

40. 40 What You Can Do in the RUP Planning Guide Wizards allow you to select how many iterations you want in each phase, as well as which discipline- based RUP activities you want in each iteration. Wizards allow you to select what deliverables you want in each iteration, and to attach activities or roles to them.

41. 41 Analysis & Design Discipline Purpose:  Transform the requirements into a design of the system-to-be  Evolve a robust architecture for the system  Adapt the design to match the implementation environment Primary artifact is the Design Model.

42. 42 A Design Model:  Is an object model describing the realization of use cases  Serves as an abstraction of the implementation model and its source code  Is used as essential input to activities in implementation and test

43. 43 Use Cases Drive Analysis & Design Supplementary Specifications Use-Case Model Analysis and Design Design Model Data Model Architecture Document Analysis Model (optional)

44. 44 Use-Case Realization in Analysis & Design Use Case (Use-Case Model) Use-Case Realization (Design Model) > Class Diagrams Sequence Diagrams Collaboration Diagrams Use Case

45. 45 Use-Case Analysis & Design  The complete behavior of a use case is allocated to collaborating classes.

46. 46 Sample UML Class Diagram A University Course Registration System MainForm // select maintain schedule() > MaintainScheduleForm + // open() + // select 4 primary and 2 alternate offerings() > 1 0..1 1 CourseCatalogSystem // get course offerings() > 10..* RegistrationController // add courses to schedule() // get course offerings () > 1 1 Schedule // create with offerings() > 1 0..1

47. 47 Sample UML Sequence Diagram : Student : :RegisterForCoursesForm : :RegistrationController : Course Catalog : :CourseCatalogSystem 1: create schedule( ) 5: display course offerings( ) 2: get course offerings( ) 3: get course offerings(forSemester) 6: display blank schedule( ) 4: get course offerings( )

48. 48 Implementation Discipline Purpose:  Implement classes and objects in terms of components and source code  Define the organization of the components in terms of implementation subsystems  Test the developed components as units  Create an executable system Primary artifact is Implementation Model.

49. 49 What is an Implementation Model? Trading Services Telephone Banking A B > Components and implementation subsystems in a Telephone Banking System.  An Implementation Model consists of:  Components  Implementation Subsystems  Components include:  Deliverable components, such as executables  Components from which the deliverables are produced, such as source code files

50. 50 Build A build:  Is an operational version of a system or part of a system.  Demonstrates a subset of the capabilities provided in the final product.  Is an integral part of the iterative lifecycle.  Provides review points.  Helps uncover integration problems as soon as they are introduced.

51. 51 Test Discipline Purpose:  Finding and documenting defects in software quality  Generally advising about perceived software quality  Proving the validity of the assumptions made in design and requirement specifications through concrete demonstration  Validating the software product functions as designed  Validating that the requirements have been implemented appropriately The Test discipline:  Focuses primarily on the evaluation or assessment of quality realized through a number of core practices  Acts in many respects as a service provider to the other disciplines

52. 52 Types of Test  Functionality  Function test  Security test  Volume test  Usability  Usability test  Reliability  Integrity test  Structure test  Stress test  Performance  Benchmark test  Contention test  Load test  Performance profile  Supportability  Configuration test  Installation test Notice the match with Supplementary Specifications Types.

53. 53 Test Automation and Tools  Data acquisition tools  Static measurement tools  Dynamic measurement tools  Simulators or Drivers  Test management tools

54. 54 Deployment Discipline  Purpose: Manage the activities associated with ensuring that the software product is available for its end users, such as:  Product deployment  Testing at the installation and target sites  Beta testing  Creating end-user support material  Creating user training material  Releasing to customer (in the form of shrink- wrapped package, download site, etc.)

55. 55 Use Cases and End-User Documentation Deployment End-User Support Material User’s Guide Online Help Demos Tutorials Training Material Use-Case Model Supplementary Specification

56. 56 Review  RUP content is organized into disciplines. A discipline is a collection of related activities that are related to a major “area of concern.”  Disciplines group:  Activities that are related  The roles that perform those activities  The artifacts that result from those activities  Most disciplines produce models.  Activities in disciplines have dependencies that cross discipline boundaries.

57. 57 Exercises Complete Module 4 Exercise 1: Artifact Evolution Through Phases in the Exercises section of your student manual. This exercise will allow you to become familiar with some RUP artifacts and how they evolve through phases. Complete Discussion Points associated with Exercise 2.

58. 58