1. Rational Unified Process Fundamentals Module 3: Disciplines I

2. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 2 Objectives  Understand how models result from Disciplines  Understand discipline concepts for:  Business Modeling  Environment  Project Management  Requirements

3. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 3 Disciplines

4. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 4 Discipline: Environment  Purpose: Support the development organization, both with process and tools  Process configuration Adapt RUP to organization  Process implementation Train and mentor RUP users  Process improvement  Managing organizational change  Development environment Tool selection and acquisition Tool instillation and configuration

5. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 5 Discipline: Environment  The primary roll in the Environment Discipline is the Process Engineer.  The primary artifact produced by the Process Engineer is the Development Case.  The Development Case describes, for each process discipline, how the project will apply the process.

6. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 6 Development Case  Describes the development process that you have chosen to follow in your project  Contained in Environment discipline  Created early in Inception  Updated during project Development Case Select from RUP knowledge base Minimize cost of process definition

7. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 7 Development Case Example Brief Outline: 1.Introduction: Purpose, Scope, Definitions, References, Overview 2.Overview of the Development Case: Lifecycle Model, Discipline Configuration, Artifact Classification, Review Procedures, Sample Iteration Plans 3.Disciplines: Describes artifacts used for each discipline 4.Roles: Describes any changes in Role Sets Example below shows Requirements artifacts to be used as defined in the Development Case

8. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 8 Discipline: Project Management  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

9. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 9 Discipline: Project Management  Questions that must be addressed by the project manager:  How many iterations are needed?  How long should each iteration be?  How are the contents and objectives of an iteration determined?  How is the progress of an iteration tracked?

10. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 10 Discipline: Project Management  Project planning takes place at two levels 1.Phase Plan Level Dates of major milestones: end of each phase and its objectives Staffing profiles: which resources are required over time. Dates of minor milestones: end of each iteration and its objectives 2.Iteration Plan Level  Current iteration plan  Next iteration plan (built toward end of current iteration)

11. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 11 Coarse-Grained and Fine-Grained Planning Single coarse-grained plan (the phase plan) PreliminaryIterationArchitect.IterationArchitect.IterationDevel.IterationDevel.IterationDevel.IterationTransitionIterationTransitionIteration Series of fine-grained plans (the iteration plans) InceptionElaborationConstructionTransition

12. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 12 Incremental (1) Evolutionary (2) Incremental delivery (3) “Grand design” (4) Strategies for Iterative Development

13. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 13 Planning for Iterative Development Iteration Plan (next) Iteration Plan (current) Phases and major milestones What and when Project PlanPhase Plan Iterations for each phase Number of iterations Objectives Duration Fine-grained Plans Coarse-grained Plan “Roadmap”

14. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 14 Concerns in Project Management  Significant concerns for iterative development are:  Architecture  Risk

15. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 15 Architecture Concerns in Project Management  Early elimination of architectural risk in the project.  Other concerns:  Consistent architecture and development guidelines  Relationship between the architecture and organizational structures  Separation of development concerns, which will provide a basis for separation of work  Stability of the technical infrastructures  Adherence to standards  Required skills

16. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 16 Definition of Risk  Success is meeting the entire set of all requirements and constraints, and satisfying stakeholder expectations. A risk is whatever may stand in the way of our success or in the way of achieving major milestones.

17. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 17 Risk Reduction Drives the Iterative Lifecycle  Early iterations address the highest risks  Risk assessment is a continuous process; risks change over time

18. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 18 Risk Terms  Direct risk - the project has a large degree of control  Indirect risk - the project has little or no control  Risk attributes:  Probability of occurrence  Impact on the project (severity)

19. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 19 Risk Management Strategies  Risk avoidance  Reorganize project so that it cannot be affected by risk  Risk transfer  Reorganize project so that risk is passed off onto some other stakeholder  Risk acceptance  Live with the risk and hope that it never materializes  Risk mitigation (deal with risk head-on)  Confront risks  Plan for contingencies  Monitor risks

20. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 20 Some Sample Risks  Resource risks  People, skills, funding  Business risks  Competition, ROI, supplier interfaces  Technical risks  Unproven technology, uncertain scope  Schedule risks  Only 24 hours in a day

21. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 21 Discipline: Requirements  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.

22. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 22 Supplementary Specification Primary Requirements Artifacts RequirementFunctionalNonFunctional (URPS) Use-Case Model

23. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 23 Major Concepts in the Use-Case Model Actor Use Case 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.

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

25. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 25 Charlieas depotstaff Charlieasdepot manager Charlie DepotStaff DepotManager A User Can Act as Several Actors

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

27. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 27 Register for Courses Student Course Catalog 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.

28. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 28 A Sample UML Diagram: Use Cases A University Course Registration System Professor Select Courses to Teach StudentCourse Catalog Register for Courses Maintain Student Information Maintain Professor Information Registrar Billing System Close Registration

29. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 29 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 Preconditions and postconditions (optional) Special requirements Other diagrams, such as activity or state diagrams

30. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 30 Use Cases in the Development Process:  Drive many activities in the process.  Trace to several models.

31. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 31 Use Cases as a Basis for Iteration Planning Use-Case Model Iteration Plan Fine-grained plan for a single iteration Supplementary Specification Project Management Constraints

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

33. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 33 Use CasesAnalysis Classes Source Code ExecDesign Classes Use Cases as a Basis for System Modeling (2)

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

35. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 35 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 Design ModelTest SuiteEnd-User Documentation Materials and Training Materials 1 2 4 3 1 2 3 4 Vision Use-Case Model Supplementary Specification Stakeholder Needs

36. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 36 Discipline: Business Modeling  Purpose  Understand structure and dynamics of organization in which system is to be deployed  Understand problems in target organization and identify improvement potentials  Ensure customer/end user common understanding of target organization  Derive system requirements to support target organization

37. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 37 Two business models What a Business Model Shows  Customers  Business processes  Organizational structure  Roles and responsibilities  Products  Internal deliverables  Events Business Object Model Business Use-Case Model