1. Rational Unified Process Fundamentals Module 4: Disciplines II

2. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 2 Objectives  Understand discipline concepts for:  Analysis & Design  Test  Implementation  Deployment  Configuration & Change Management

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: Analysis & 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 non- functional requirements and the implementation environment  Design is a refinement of analysis  Primary artifact is Design Model

5. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 5 The Design Model Artifact:  Consists of a collection of models that collaborate to describe the structure and behavior of the system.  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.

6. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 6 Use Cases Drive Analysis & Design Supplementary Specifications Use-Case Model Design Model Data Model Architecture Document Analysis and Design Analysis Model (optional)

7. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 7 Analysis & Design Considerations  Transform requirements into classes and subsystems  Adhere to constraints of  Nonfunctional requirements  Implementation environment  Design the database  Mapping the design model to a data model  Identify components  Subsystems and interfaces

8. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 8 Use-Case Realization in Analysis & Design Use Case (Use-Case Model) Use-Case Realization (Design Model) > Class Diagrams Sequence Diagrams Collaboration Diagrams Use Case

9. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 9 Use-Case Analysis & Design  The complete behavior of a use case is allocated to collaborating classes

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

11. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 11 Purposes of Architecture  Intellectual control  Basis for reuse  Basis for project management

12. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 12 Architecture: Intellectual Control  Architecture is used for different things by various stakeholders  Customer: visualize what they are buying  Project manager: scheduling and resource allocation  System analyst: organize requirements  Developer: understand boundaries of their chunk of the project  Software architect: reason about evolution or reuse  Multidimensional reality (i.e. multiple views)  Multiple views: functional, implementation, dynamic, structural, spatial (physical distribution), etc.

13. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 13 Intellectual Control: Architecture Views Conceptual Physical Process ViewDeployment View Logical View Use-Case View Implementation View End-user Functionality Programmers Software management Performance Scalability Throughput System integrators System topology Delivery, installation communication System engineering Analysts/Designers Structure

14. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 14 Architecture: Basis for Reuse  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

15. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 15 Architecturally Significant Elements  Not all design is architecture  Main business classes  Important mechanisms  Processors and processes  Layers and subsystems  Architectural views = slices through models

16. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 16 Architecture: Basis for Project Management  Architecture Milestone in Elaboration phase is the Lifecyle Architecture milestone  Architecture primarily results from Analysis & Design  Architecture in phases and iterations:  It drives the risk mitigation of iterations  Architecture baseline is an exit criterion for Elaboration

17. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 17 Discipline: Test  Purpose: Testing focuses primarily on the evaluation or assessment of quality realized through a number of core practices:  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.  Test discipline acts in many respects as a service provider to the other disciplines.

18. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 18 Artifacts of Test Discipline

19. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 19 Workflow Detail: Define Evaluation Mission For each Iteration:  Identify the objectives for and deliverables of the testing effort  Identify a good utilization strategy for test resources  Define the scope and boundaries for the test effort  Outline the approach that will be used  Define how progress will be monitored and assessed Define Evaluation Mission Roles responsible for related activities:  Test Manager (mainly)  Test Analyst  Test Designer

20. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 20 Concept: Test Automation and Tools  Data acquisition tools  Static measurement tools  Dynamic measurement tools  Simulators or Drivers  Test management tools

21. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 21 Implementation Model Discipline: Implementation  The purposes of Implementation are:  To implement classes and objects in terms of components  To define the organization of the components in terms of implementation subsystems  To test the developed components as units  To create an executable system  Implementation results in an Implementation Model.

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

23. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 23 Concept: Build  Operational version of a system or part of a system  Demonstrates a subset of the capabilities provided in the final product  Integral part of the iterative lifecycle  Provides review points  Helps uncover integration problems as soon as they are introduced

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

25. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 25 Use Cases and End-User Documentation Use-Case Model Deployment End-User Support Material User’s Guide Online Help Demos Tutorials Training Material Supplementary Specification

26. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 26 Discipline: Configuration & Change Management  Purpose: Track and maintain integrity of project artifacts  Change control  Configuration identification and management  Configuration status accounting  Change tracking  Version selection  Software manufacture  Workspace management

27. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 27 The Configuration and Change Management (CCM) Cube

28. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 28 Configuration Management (CM)  Describes the product structure (logically correct configurations)  Identifies which artifacts are to be tracked  Identifies dependencies among artifacts  Maintaining traceability between artifacts  Isolate individual and team workspaces

29. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 29 Change Request Management (CRM) Addresses:  The capture and management of requested changes to one or more artifacts by various stakeholders.  A change request has a lifecycle: new, logged, approved, assigned and complete.  Not all change requests are acted on. The potential impact of a proposed change determines if it will be acted on.

30. Rational Unified Process Fundamentals Copyright © 1999-2001 Rational Software, all rights reserved 30 Configuration Status Accounting  This type of accounting 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.  Metrics derived under this aspect, either through audits or raw data, are useful in determining the overall completeness status of the project.  Problem areas that require attention