Rational Unified Process Fundamentals Module 4: Disciplines II

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


Disciplines


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


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.


Use Cases Drive Analysis & Design

SupplementarySpecifications

Use-Case Model

Design Model

Data ModelArchitectureDocument

Analysis and Design

Analysis Model (optional)


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


Use-Case Realization in Analysis & Design

Use Case(Use-Case Model)

Use-Case Realization(Design Model)

<<realizes>>

Class Diagrams

Sequence Diagrams Collaboration DiagramsUse Case


Use-Case Analysis & Design

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


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


Purposes of Architecture

Intellectual control Basis for reuse Basis for project management


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.


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


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


Architecturally Significant Elements

Not all design is architecture Main business classes Important mechanisms Processors and processes Layers and subsystems Architectural views = slices through models


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


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.


Artifacts of Test Discipline


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


Concept: Test Automation and Tools

Data acquisition tools Static measurement tools Dynamic measurement tools Simulators or Drivers Test management tools


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.


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


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


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


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


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


The Configuration and Change Management (CCM) Cube


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


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.


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

Rational Unified Process Fundamentals Module 4: Disciplines II

Documents

Transcript of Rational Unified Process Fundamentals Module 4: Disciplines II