Rational Unified Process Fundamentals

Module 4: Disciplines II

Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 2

Objectives

Understand discipline concepts for: Analysis & Design Test Implementation Deployment Configuration & Change Management

Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 3

Disciplines

Rational Unified Process FundamentalsCopyright © 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

Rational Unified Process FundamentalsCopyright © 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.

Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 6

Use Cases Drive Analysis & Design

SupplementarySpecifications

Use-Case Model

Design Model

Data ModelArchitectureDocument

Analysis and Design

Analysis Model (optional)

Rational Unified Process FundamentalsCopyright © 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

Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 8

Use-Case Realization in Analysis & Design

Use Case(Use-Case Model)

Use-Case Realization(Design Model)

<<realizes>>

Class Diagrams

Sequence Diagrams Collaboration DiagramsUse Case

Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 9

Use-Case Analysis & Design

The complete behavior of a use case is allocated to collaborating classes

Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 10

Sample UML Class DiagramA University Course Registration System

MainForm

// select maintain schedule()

<<boundary>> MaintainScheduleForm

+ // open()+ // select 4 primary and 2 alternate offerings()

<<boundary>>

1 0..11

CourseCatalogSystem

// get course offerings()

<<boundary>> 1 0..*RegistrationController

// add courses to schedule()// get course offerings ()

<<control>>

1

1

Schedule

// create with offerings()

<<entity>>

10..1

Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 11

Purposes of Architecture

Intellectual control Basis for reuse Basis for project management

Rational Unified Process FundamentalsCopyright © 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.

Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 13

Intellectual Control: Architecture Views

Conceptual Physical

Process View Deployment View

Logical View

Use-Case View

Implementation View

End-user Functionality Programmers

Software management

PerformanceScalabilityThroughput

System integratorsSystem topology

Delivery, installationcommunication

System engineering

Analysts/DesignersStructure

Rational Unified Process FundamentalsCopyright © 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

Rational Unified Process FundamentalsCopyright © 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

Rational Unified Process FundamentalsCopyright © 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

Rational Unified Process FundamentalsCopyright © 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.

Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 18

Artifacts of Test Discipline

Rational Unified Process FundamentalsCopyright © 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

Rational Unified Process FundamentalsCopyright © 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

Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 21

ImplementationModel

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.

Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 22

What Is an Implementation Model?

Trading Services

Telephone Banking

A

B

<<import>> <<compilation>>

Components and implementationsubsystems 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

Rational Unified Process FundamentalsCopyright © 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

Rational Unified Process FundamentalsCopyright © 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.)

Rational Unified Process FundamentalsCopyright © 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

Rational Unified Process FundamentalsCopyright © 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

Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 27

The Configuration and Change Management (CCM) Cube

Rational Unified Process FundamentalsCopyright © 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

Rational Unified Process FundamentalsCopyright © 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.

Rational Unified Process FundamentalsCopyright © 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