Rational Unified Process Fundamentals Module 3: Core Workflows I - Concepts

1. Rational Unified Process Fundamentals Module 3: Core Workflows I - Concepts

2. Where Are We? • Core Workflows - I • Introduction • Project Management • Requirements • Analysis & Design

3. Objectives • Understand the elements of a Core Workflow • Explain the purpose of Core Workflows • Understand how models result from Core Workflows • Explain important concepts for • Project Management • Requirements • Analysis & Design

4. Core Workflows

5. Core Workflows are Associated with Models

6. Elements of the Core Workflow • Introduction • Concepts • Workflow Details • Activity Overview • Artifact Overview • Guidelines Overview

7. Where Are We? • Core Workflows - I • Introduction • Project Management • Requirements • Analysis & Design

8. Core Workflow: 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. Key Concept: Incremental Planning Project plan Phase plan Next iteration Phases and major milestones What and when Iterations for each phase Number of iterations Objectives Duration Current iteration “Road-map” Coarse-grained Plan Fine-grained Plans

10. Supplementary Specification Iteration Plan Use Cases as a Basis for Iteration Planning Constraints Project Management Use-Case Model Fine-grained plan for a single iteration

11. Inception Inception Elaboration Elaboration Construction Construction Transition Transition Beyond Transition: Development Cycles • A development cycle includes one execution of all four phases and produces a software generation • Most software systems require multiple cycles • Cycles may be sequential, but more commonly overlap Inception Elab. . . time

12. Strategies for Iterative Development Incremental (1) Incremental delivery (3) Evolutionary (2) “Grand design” (4)

13. Architecture Concerns in Project Management • 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

14. Key Concept: Risk • A risk is whatever may stand in our way to success, and is currently unknown or uncertain. • Success is meeting the entire set of all requirements and constraints, and satisfying stakeholder expectations.

15. 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) Risk - whatever may stand in the way of our success

16. Risk Management • Strategies: • Risk avoidance • Risk transfer • Risk acceptance • Risk mitigation • Confront risks • Plan for contingencies • Monitor risks • Maintain a risk list

17. 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,. . .

18. Risk Reduction Drives the Iterative Lifecycle • Early iterations address the highest risks • Risk assessment is a continuous process; risks change over time • Risk profile by phase • Inception - based on unknowns and risks • Elaboration - based on risk and critical scenarios • Construction - based on use case, features, and subsystems completion • Transition - based on quality indicators

19. Where Are We? • Core Workflows - I • Introduction • Project Management • Requirements • Analysis & Design

20. Core Workflow: Requirements • Purpose: produce requirements artifacts • Stakeholders needs • Vision document • Use case model • All functional requirements • Some non functional requirements • Supplementary specification • Other non functional requirements • User interface prototype (optional) • Traceability

21. Requirement Non-Functional (URPS) Functional Supplementary Specification Primary Requirements Artifacts Use-Cases

22. What Is in a Use-Case Model? • Actors and their descriptions • Use-Case diagrams showing relationships • For each use case • Name and brief description • Flow of events • Preconditions and postconditions (optional) • Special requirements • Other diagrams, such as activity or state diagrams

23. The Purpose of a Use-Case • Use cases capture requirements, especially functional requirements • They are usable by many stakeholders • They drive many activities in the process • They trace to several models: design model, test model

24. Major concepts in the Use-Case Model An actor represents anything that interacts with the system. A use case (instance) defines a sequence of actions a system performs that yields a result of observable value to an actor. Actor Use Case

25. 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. Actor System

26. A User Can Act as Several Actors C h a r l i e a s d e p o t m a n a g e r D e p o t M a n a g e r C h a r l i e C h a r l i e a s d e p o t s t a f f D e p o t S t a f f

27. Use Case • A use case models 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. Use Case

28. 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

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

30. The Use Case Model Relates to Other Models Use-Case Model (requirements) realization verification influence Design Model (classes and objects) Test Model (test cases and procedures) Implementation Model (source code)

31. From Use Cases to Executables Use Cases AnalysisClasses DesignClasses Source Code Exec

32. Traceability Links Support Impact Assessment 1 Trace product requirements (features) into detailed requirements Trace requirements into design Trace requirements into test procedures Trace requirements into user documentation and training materials Vision 2 1 Stakeholder Needs 3 Use-Case Model Supplementary Specification 4 2 3 4 Design Model Test Model End-User Documentation Materials and Training Materials

33. Where Are We? • Core Workflows - I • Introduction • Project Management • Requirements • Analysis & Design

34. Core Workflow: Analysis and Design • Purpose: • To transform the requirements into a design of the system to-be. • To evolve a robust architecture for the system. • To adapt the design to match the implementation environment. • Modeling, using OO techniques & UML • Design model • Process view (concurrency) • Deployment view (distribution)

35. Core Workflow: Analysis & Design (cont.) • Transform requirements into classes and subsystems • Adhere to constraints of • nonfunctional requirements • implementation environment • Database design • Mapping the design model to a data model • Component identification • Subsystems and interfaces

36. What is a Design Model? • An object model describing the realization of use cases • Serves as an abstraction of the implementation model and its source code • Used as essential input to activities in implementation and test.

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

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

39. Use-Case Analysis and Design • The complete behavior of a use case is allocated to collaborating classes

40. <<boundary>> <<boundary>> MaintainScheduleForm MainForm 0..1 1 1 // select maintain schedule() + // open() + // select 4 primary and 2 alternate offerings() 1 1 <<control>> 1 0..* <<boundary>> RegistrationController CourseCatalogSystem // add courses to schedule() // get course offerings () // get course offerings() 0..1 1 <<entity>> Schedule // create with offerings() A Sample UML Diagram: Classes A University Course Registration System

41. Architecture • What is architecture? • Purpose • Definition • Architecture representation • Architectural views = slices through models • UML • Prototyping • Architecture milestone • Elaboration phase  Lifecycle architecture milestone

42. Purpose of Architecture • Intellectual control • Manage complexity • Maintain integrity • Basis for reuse • Component reuse • Architecture reuse • Line-of-product • Basis for project management • Planning • Staffing • Delivery

43. Significant Decisions About Software Architecture • the organizationof a software system • the structural elements and interfaces which compose the system, • the behavior seen in the collaboration of these elements • the composition of these elements into progressively larger subsystems • the architectural style that guides the organization, composition, and collaboration of elements and their interfaces

44. Architecture Includes a System in Its Environment • In addition to structure and behavior, software architecture is concerned with • usage • functionality • performance • resilience • reuse • comprehensibility • aesthetics • economic and technological constraints and tradeoffs

45. Many stakeholders, many views • Architecture is many things to many different interested parties • end-user • customer • project manager • system engineer • developer • architect • Multidimensional reality • Multiple stakeholders • multiple views, multiple blueprints

46. Architectural View • An architectural view is a simplified description (an abstraction) of a system from a particular perspective or vantage point, covering particular concerns, and omitting entities that are not relevant to this perspective

47. Architecturally significant elements • Not all design is architecture • Main “business” classes • Important mechanisms • Processors and processes • Layers and subsystems • Architectural views = slices through models

48. End-user Functionality LogicalView Implementation View Analysts/Designers Structure Programmers Software management Use-Case View Process View Deployment View System engineering System integrators System topology Delivery, installation communication Performance Scalability Throughput Conceptual Physical Architecture Views

49. Where is Architecture in the Process? • Primarily from Analysis & Design • Architecture in phases and iterations • Drives the risk mitigation of iterations • Architecture baseline is an exit criterion for Elaboration

50. Summary: Core Workflows • How often do you go through a Core Workflow? • How does the focus on individual Core Workflows change across the Lifecycle? • What is the role of risk in the iterative Lifecycle? • What is the purpose of the Use Case Model? • What is the purpose of the Analysis and Design workflow?