The Unified Software Development Process (Overview)read.pudn.com/downloads152/ebook/663434/Neusoft/2.2... · (Overview) ★★★ NEU ... The Rational Unified Process® or RUP® product

统一软件开发过程统一软件开发过程The Unified Software Development ProcessThe Unified Software Development Process

(Overview)(Overview)

★★★NEU

www.neusoft.org

★★

东北大学信息学院东北大学信息学院郭军郭军Faculty of Information Science and Engineering NEU Faculty of Information Science and Engineering NEU GuoGuo J.J.Email :Email :[email protected]@sohu.comTel:024Tel:024--8160726081607260

www.neusoft.orgNEU★★★★★

Page Page 22

Contents

Part 2 Software ProcessesPart 2 Software Processes5. RUP• 5.1 What is the RUP?• 5.2 The Time Dimension• 5.3 The Content Dimension• 5.4 Best Practices• 5.5 The Ten Essentials of RUP• 5.6 Example: Volvo IT


Page Page 33


Page Page 44

5.1 What is the RUP?

Waterfall Process Waterfall Process • A strictly ordered sequence: requirements analysis, design,

implementation/integration, and then testing. • Problems

—defer testing until the end of the project lifecycle —serious threats to release deadlines —leave key team members idle for extended

periods of time—it does not facilitate, accommodate, or encourage

the use of feedback


Page Page 55

What is the RUP?

Transitioning from Waterfall to Iterative DevelopmentTransitioning from Waterfall to Iterative Development• Early iterations emphasize requirements as well as analysis

and design• Later iterations emphasize implementation and testing.


Page Page 66

What is the RUP?

Four steps for a transition from waterfall to iterative Four steps for a transition from waterfall to iterative developmentdevelopment

• 1. Build functional prototypes early. • 2. Divide the detailed design, implementation and test phases

into iterations. • 3. Baseline an executable architecture early on.• 4. Adopt an iterative and risk-driven management process.


Page Page 77

What is the RUP?

The Rational Unified ProcessThe Rational Unified Process®® or or RUPRUP®® productproduct• RUP is an industry-wide process platform that provides you with

software development knowledge, guidelines, templates, and examples for every member of your team.

• is a iterative and incremental software engineering process (free!)

• provides a disciplined approach to assigning tasks and responsibilities within a development organization.

• its goal is to ensure the production of high-quality software that meets the needs of its end users within a predictable schedule and budget


Page Page 88

What is the RUP?

RUPRUP• is a process product, developed and maintained by

Rational® Software—Rational is now part of IBM and provides

a range of tools to support system development• Created by the Rational/UML community

—Grady Booch,James Rumbaugh,Ivar Jacobson


Page Page 99

What is the RUP?

• Rumbaugh Domain object (problem space) models• Jacobson User-driven solution space models• Booch Detailed design-level models

Jacobson Booch

Jacobson

Rumbaugh


Page Page 1010

What is the RUP?

RUPRUP HistoryHistory


Page Page 1111


Page Page 1212

What is the RUP?

RUPRUP• has four phases:

—Inception—Elaboration—Construction—Transition

• Each phase may have one or more iterations• Each iteration has five iteration workflows

—Requirements, Analysis, Design, Implementation, Test


Page Page 1313

Process StructureProcess Structure


Page Page 1414

What is the RUP?

Characteristics of Characteristics of RUPRUP• Use-case and risk driven• Architecture centric• Iterative and incremental


Page Page 1515

What is the RUP?

BenefitsBenefits• Enhances team productivity• The RUP activities create and maintain models.• Is a guide for how to effectively use the Unified Modeling

Language.• Supported by tools, which automate large parts of the

process.• Is a configurable process.• Captures many of the best practices in modern software

development• …


Page Page 1616

5.2 The Time Dimension

Two Dimensions


Page Page 1717

The Time Dimension

Dynamic organization of the process along timeDynamic organization of the process along time• From a management perspective, the software lifecycle of the

RUP is decomposed over time into four sequential phases,—each concluded by a major milestone; —each phase is essentially a span of time between two major milestones—At each phase-end an assessment is performed to determine whether

the objectives of the phase have been met—A satisfactory assessment allows the project to move to the next phase


Page Page 1818

The Time Dimension

Planning PhasesPlanning Phases• One pass through the four phases is a development cycle;

Each pass through the four phases produces a generation of the software.

• Reasons


Page Page 1919

The Time Dimension

Time for a typical projectTime for a typical project• If we consider a project of “typical” difficulty, then this is how

the total time for the project is likely to be distributed over the phases


Page Page 2020

The Time Dimension

Resource for a typical projectResource for a typical project• If we consider a project of “typical” difficulty, then this is how

the total resource for the project is likely to be utilised over the phases


Page Page 2121

The Time Dimension

Resource for a difficult projectResource for a difficult project• If we consider a project of greater than normal difficulty, then

this is how the total resource for the project is likely to be distributed over the phases

• Note that for more difficult projects more resource is used in the early phases


Page Page 2222

The Time Dimension

Information set evolution over the development phases Information set evolution over the development phases


Page Page 2323

The Time Dimension

For each phase we will consider:For each phase we will consider:

• The goal for the phase

• The focus in terms of the core workflows

• The milestone at the end of the phase


Page Page 2424

The Time Dimension

Inception Inception -- GoalsGoals• scope and boundary conditions• critical use cases of the system, the primary scenarios of operation• at least one candidate architecture• the overall cost and schedule for the entire project• potential risks • the supporting environment for the project.


Page Page 2525

The Time Dimension

Inception Inception -- FocusFocus• Requirements – establish business case, scope and

core requirements• Analysis – establish feasibility• Design – design proof of concept or technical prototypes• Implementation – build the proof of concept prototype• Test – not generally applicable

N.B. The blue bars indicate approximately the relative amount of resource needed


Page Page 2626

The Time Dimension

Inception Inception -- The milestoneThe milestone• Vision• Business Case• Risk List• Software Development Plan• Iteration Plan and Development Process• Development Infrastructure• Glossary• Use-Case Model (Actors, Use Cases) • Domain Model (a.k.a. Business Analysis Model)• Prototypes


Page Page 2727

Transitioning from waterfall to iterative development


Page Page 2828


Page Page 2929


Page Page 3030

The Time Dimension

Elaboration Elaboration -- GoalsGoals• Create an executable architectural baseline• Refine Risk Assessment• Define quality attributes (defect rates etc.)• Capture use-cases to 80% of the functional requirements• Create a detailed plan for the construction phase• Formulate a bid which includes resources, time, equipment,

staff and cost


Page Page 3131

The Time Dimension

Elaboration Elaboration –– FocusFocus• Requirements – refine system scope and requirements• Analysis – establish what to build• Design – create a stable architecture• Implementation – build the architectural baseline• Test – test the architectural baseline



Page Page 3232

The Time Dimension

Elaboration Elaboration –– The milestoneThe milestone• Prototypes• Risk List• Development Process• Development Infrastructure• Vision• Software Development Plan• Iteration Plan• Supplementary Specifications• Test Suite• End-User Support Material


Page Page 3333

The Time Dimension

Elaboration Elaboration –– The milestoneThe milestone• Business Case (Model)• Use-Case Model• Analysis Model• Design Model• Data Model• Implementation Model• Test Automation Architecture• Software Architecture Document


Page Page 3434



Page Page 3535


Page Page 3636

The Time Dimension

Construction Construction -- GoalsGoals• Completing use-case identification, description and

realisation• To iteratively and incrementally develop a complete product• Finish analysis, design, implementation and test• Maintain the integrity of the system architecture• Revise the Risk Assessment


Page Page 3737

The Time Dimension

Construction Construction -- FocusFocus• Requirements – uncover any requirements that had

been missed• Analysis – finish the analysis model• Design – finish the design model• Implementation – build the Initial Operational Capability• Test – test the Initial

Operational Capability



Page Page 3838

The Time Dimension

Construction Construction –– The milestoneThe milestone• "The System" • Deployment Plan• Test Suite• End-User Support Material• Iteration Plan• Development Process• Development Infrastructure• Supplementary Specifications

• Use-Case Model• Design Model• Data Model• Implementation Model


Page Page 3939



Page Page 4040


Page Page 4141

The Time Dimension

Transition - Goals• converting operational databases • training of users and maintainers • Correct defects• Prepare the users site for the new software• Tailor the software to operate at the users site• Modify software if unforeseen problems arise• Create user manuals and other documentation• Conduct post project review


Page Page 4242

The Time Dimension

Transition Transition -- FocusFocus• Requirements – not applicable• Analysis – not applicable• Design – modify the design if problems emerge in beta testing• Implementation – tailor the software for the users site and

correct problems uncovered in beta testing• Test – beta testing and

acceptance testing at the users site



Page Page 4343

The Time Dimension

Transition Transition –– The milestoneThe milestone• The Product Build• End-User Support Material• Test Suite• 'Shrinkwrap' Product Packaging


Page Page 4444


Page Page 4545


Page Page 4646

The Time Dimension

Iterations• Each phase in the RUP can be broken down into iterations.• An iteration is a complete development loop • Resulting in a release of an executable product

—internal or external—a subset of the final product—grows incrementally from iteration to iteration to become the final system


Page Page 4747

The Time Dimension

Development cycle Development cycle


Page Page 4848

The Time Dimension

USDP specifies 5(+1) core workflows


Page Page 4949

The Time Dimension

Iterations may overlap

• In order to allow parallel development and flexible working in large teams, iterationscan, and often do, overlap.

• In the example above, Iteration 1overlaps significantly with iteration 2


Page Page 5050

The Time Dimension

USDP Phases


Page Page 5151

The Time Dimension

Iteration pattern: Incremental Lifecycle Iteration pattern: Incremental Lifecycle characteristic:characteristic: 11nm11nm

• a short Inception iteration to establish scope and vision, and to define the business case

• a single Elaboration iteration, during which requirements are defined, and the architecture established

• several Construction iterations during which the use cases are realized and the architecture fleshed-out

• several Transition iterations to migrate the product into the user community


Page Page 5252

The Time Dimension

Iteration pattern: Incremental Lifecycle Iteration pattern: Incremental Lifecycle This strategy is appropriate when:This strategy is appropriate when:

• The problem domain is familiar. • Risks are well-understood. • The project team is experienced


Page Page 5353

The Time Dimension

Iteration pattern: Evolutionary Lifecycle Iteration pattern: Evolutionary Lifecycle characteristic: characteristic: 1n1m1n1m


• several Elaboration iterations, during which requirements are refined at each iteration

• a single Construction iteration, during which the use cases are realized and the architecture is expanded upon



Page Page 5454

The Time Dimension

Iteration pattern: Evolutionary Lifecycle Iteration pattern: Evolutionary Lifecycle This strategy is appropriate when: This strategy is appropriate when:

• The problem domain is new or unfamiliar. • The team is inexperienced


Page Page 5555

The Time Dimension

Iteration pattern: Incremental Delivery Lifecycle Iteration pattern: Incremental Delivery Lifecycle characteristic: 111mcharacteristic: 111m


• a single Elaboration iteration, during which a stable architecture is baselined

• a single Construction iteration, during which the use cases are realized and the architecture fleshed-out



Page Page 5656

The Time Dimension

Iteration pattern: Incremental Delivery LifecycleIteration pattern: Incremental Delivery LifecycleThis strategy is appropriate when: This strategy is appropriate when:

• The problem domain is familiar (the architecture and requirements can be stabilized early;there is a low degree of novelty)

• The team is experienced. • Incremental releases of functionality have high value


Page Page 5757

The Time Dimension

Iteration pattern: "Grand Design" Lifecycle Iteration pattern: "Grand Design" Lifecycle

characteristic:characteristic: 111111mm• a short Inception iteration to establish scope and vision, and

to define the business case• a single Elaboration iteration, during which a stable

architecture is baselined• a single very long Construction iteration, during which the use

cases are realized and the architecture fleshed-out • several Transition iterations to migrate the product into the

user community


Page Page 5858

The Time Dimension

Iteration pattern: "Grand Design" LifecycleIteration pattern: "Grand Design" LifecycleThis strategy is appropriate when:This strategy is appropriate when:

• a small increment of well-defined functionality is being added to a very stable product

• the new functionality is well-defined and well-understood • The team is experienced, both in the problem domain and

with the existing product


Page Page 5959

The Time Dimension

Iteration pattern: Hybrid Strategies Iteration pattern: Hybrid Strategies • In practice few projects strictly follow one strategy. • You often end up with a hybrid, some evolution at the

beginning, some incremental building, and multiple deliveries. • Among the advantages of the phase-iteration model is that it

lets you accommodate a hybrid approach, simply by increasing the length and number of iterations in particular phases


Page Page 6060

The Time Dimension

Iteration pattern: Hybrid StrategiesIteration pattern: Hybrid Strategies• For complex or unfamiliar problem domains, where there is a

high degree of exploration: increase the number of iterations in the elaboration phase and its length.

• For more complex development problems, where there is complexity translating the design into code: increase the number of iterations in the construction phase and its length.

• To deliver software in a series of incremental releases: increase the number of iterations in the transition phase and its length.


Page Page 6161

The Time Dimension

Benefits of an iterative approachBenefits of an iterative approach• Compared to the traditional waterfall process, the iterative

process has the following advantages:—Risks are mitigated earlier—Change is more manageable—Higher level of reuse—The project team can learn along the way—Better overall quality


Page Page 6262

The Time Dimension

ConclusionConclusion


Page Page 6363

5.3 The Content Dimension

Static Structure of the ProcessStatic Structure of the Process• A process describes who is doing what, how, and when. The

Rational Unified Process is represented using four primary modeling elements:

—Workers, the ‘who’—Activities, the ‘how’—Artifacts, the ‘what’—Workflows, the ‘when’


Page Page 6464

The Content Dimension

Activities, Artifacts, and Workers


Page Page 6565


Role or WorkerRole or Worker• One of the most central concepts in the RUP is the role. • A role defines the behavior and responsibilities of an

individual, or a set of individuals working together as a team, within the context of a software engineering organization

• Note that roles are not individuals


Page Page 6666


Role or WorkerRole or Worker• You could regard a worker as a "hat" an individual can wear in

the project.

People and

Workers


Page Page 6767


Activity Activity • An activity is something that a role does that provides a

meaningful result in the context of the project.• An activity is a unit of work

—Clear purpose (in terms of creating or updating some artifacts, such as a model, a class, or a plan)

—Every activity is assigned to a specific role. —The granularity of an activity is generally a few hours to a few days—It usually involves one role, and affects one or only a small number

of artifacts.—Activities may be repeated several times on the same artifact


Page Page 6868


Activity: Activity: RequirementsRequirements


Page Page 6969


ArtifactArtifact• An artifact is a piece of information that is produced, modified,

or used by a process.• Artifacts are the tangible products of the project• Artifacts are used as input by workers to perform an activity,

and are the result or output of such activities. • Artifacts may take various shapes or forms

—A model or a model element—A document—Source code—Executables


Page Page 7070


Artifact:Artifact:ImplementationImplementation


Page Page 7171

What is the RUP?

Major artifacts in the process, and the approximate flow of information between them.


Page Page 7272


Workflow Workflow • A workflow is a sequence of activities that produces a result

of observable value.—A mere enumeration of all roles, activities and artifacts does not

constitute a process; we need a way to describe meaningful sequences of activities that produce some valuable result, and to show interactions between roles.

• Activity diagrams—In UML terms, a workflow can be expressed as a sequence

diagram, a collaboration diagram, or an activity diagram. We use a form of activity diagrams in the RUP. For each discipline, an activity diagram is presented. This diagram shows the workflow, expressedin terms of workflow details


Page Page 7373

Workflow: Workflow: Analysis & DesignAnalysis & Design


Page Page 7474

Workflow DetailWorkflow DetailDesign the DatabaseDesign the Database

• roles involved, input and output artifacts, and activities performed


Page Page 7575

5.4 Best Practices

Rational Unified Process Delivers Best PracticesRational Unified Process Delivers Best Practices• Rational Unified Process describes how to effectively

implement the six best practices for software development

Control ChangesControl Changes

Manage RequirementsManage Requirements

Use Use ComponentComponent

ArchitecturesArchitecturesDevelopDevelop

IterativelyIterativelyModel Model

VisuallyVisuallyVerifyVerify

QualityQuality


Page Page 7676

Best Practices –1. Develop Iteratively

Best Practice 1: Develop IterativelyBest Practice 1: Develop Iteratively• To mitigate risks, develop incrementally in an iterative fashion.

Each iteration results in an executable release.


Page Page 7777


What is Iterative Development? What is Iterative Development? • A project using iterative development has a lifecycle

consisting of several iterations. • An iteration incorporates a loosely sequential set of activities

in business modeling, requirements, analysis and design, implementation, test, and deployment, in various proportions depending on where in the development cycle the iteration is located.

—Iterations in the inception and elaboration phases focus on management, requirements, and design activities;

—iterations in the construction phase focus on design, implementation, and test;

—iterations in the transition phase focus on test and deployment.


Page Page 7878


Why Develop Iteratively?Why Develop Iteratively?• Defects and risks


Page Page 7979


Benefits of an Iterative ApproachBenefits of an Iterative ApproachAn iterative approach is generally superior to a linear or

waterfall approach for many different reasons. • 1). Risks are mitigated earlier, because elements are

integrated progressively. • 2). Changing requirements and tactics are accommodated.• 3). Improving and refining the product is facilitated, resulting

in a more robust product. • 4). Organizations can learn from this approach and improve

their process.• 5). Reusability is increased.


Page Page 8080


Benefits of an Iterative Approach (Benefits of an Iterative Approach (RUPRUP))• In the Rational Unified Process, the interactive approach is

very controlled; —iterations are planned in number, duration, and objective—The tasks and responsibilities of the participants are defined—Objective measures of progress are captured—Some rework does take place from one iteration to the next, but this,

too, is carefully controlled


Page Page 8181

Best Practices –2. Manage Requirements

Best Practice 2: Manage RequirementsBest Practice 2: Manage RequirementsWhat is Requirements Management? What is Requirements Management?

• Requirement —"a condition or capability to which the system must conform".

• Requirements management: a systematic approach to both—eliciting, organizing, and documenting the requirements of the

system —establishing and maintaining agreement between the customer and

the project team on the system's changing requirements


Page Page 8282


Collecting requirements may run into difficulties: Collecting requirements may run into difficulties: • not always obvious, and can come from many sources• not always easily or clearly expressed in words• many different types of requirements at different levels of detail• the number of requirements can become unmanageable if …• related to one another and also to other deliverables of the

software engineering process• not necessarily equally important nor equally easy to meet• need to be managed by cross-functional groups of people• requirements change


Page Page 8383


What is UseWhat is Use--Case ?Case ?

An actor is someone or something outside the system that interacts with the system

A use case is a sequence of actions a system performs that yields an observable result of value to a particular actor

Check BalanceClient

Withdraw Money

Use Cases for a Cash Machine


Page Page 8484


The The RUPRUP employs a "useemploys a "use--case driven approach",case driven approach",• Cases defined for a system are the basis for the entire

development process.• Use cases play a part in several disciplines.

—represent business processes (business use case)—requirements discipline—a basis for planning iterative development. —use cases are realized in a design model—derive test cases and test scripts—…


Page Page 8585


Benefits of a UseBenefits of a Use--Case Driven ProcessCase Driven Process• Use cases are concise, simple, and understandable by a wide

range of stakeholders—End users, developers and acquirers understand functional

requirements of the system• Use cases drive numerous activities in the process:

—Creation and validation of the design model—Definition of test cases and procedures of the test model—Planning of iterations—Creation of user documentation—System deployment—…


Page Page 8686

Best Practices –3. Use Component Architecture

Best Practice 3: Use Component ArchitecturesBest Practice 3: Use Component Architectures

ComponentComponent--based architecture with layersbased architecture with layers


Page Page 8787


What Does Component Architecture Mean? What Does Component Architecture Mean? • Use cases and architecture

—use cases drive the Rational Unified Process (RUP) end-to-end over the whole lifecycle

—the design activities are centered around the notion of architecture• A Component Architecture is an architecture based on

replaceable components as described • Because Component Architectures are based on independent,

replaceable, modular components, they help to manage complexity and encourage re-use


Page Page 8888


RUPRUP Supports ComponentSupports Component--based Developmentbased Development• The iterative approach allows you to progressively identify

components, and decide which ones to develop, which ones to reuse, and which ones to buy.

• The focus on software architecture allows you to articulate the structure—the components and the ways in which they integrate

• Concepts, such as packages, subsystems, and layers, are used during Analysis & Design to organize components and to specify interfaces.

• Testing is first organized around components, then gradually around larger sets of integrated components.


Page Page 8989


RUPRUP Supports ArchitectureSupports Architecture• The RUP provides a methodical, systematic way to design,

develop, and validate an architecture. RUP offer templates for architectural description

—multiple architectural views, —architectural style, —design rules,—constraints.


Page Page 9090


RUPRUP Is ArchitectureIs Architecture--CentricCentric• Architecture is the focus of the elaboration phase

—Building, validating, and baselining the architecture constitute the primary objective of elaboration

• The Architectural Prototype validates the architecture and serves as the baseline for the rest of development

• The Software Architecture Description is the primary artifact that documents the architecture chosen


Page Page 9191


Representing Architecture: The 4+1 View ModelRepresenting Architecture: The 4+1 View Model• Kruchten

Process View

Deployment View

Logical View

Implementation View

ProgrammersSoftware management

PerformanceScalabilityThroughput

System IntegratorsSystem topology

Delivery, installationcommunication

System Engineering

Use-Case View

Structure

Analysts/Designers End-user

Functionality


Page Page 9292


Benefits of an ArchitectureBenefits of an Architecture--Centric ProcessCentric Process• Architecture lets you gain and retain intellectual control over a

project, to manage its complexity, and to maintain system integrity

• Architecture provides an effective basis for large-scale reuse• Architecture provides a basis for project management• Architecture facilitates component-based development


Page Page 9393


Best Practice 4: Model Visually (Best Practice 4: Model Visually (UMLUML) )

Visual modeling raises the level of abstraction


Page Page 9494


What is Visual Modeling? What is Visual Modeling? • Visual modeling is the use of semantically rich, graphical and

textual design notations to capture software designs.• A notation, such as UML, allows the level of abstraction to be

raised, while maintaining rigorous syntax and semantics. • it improves communication

The The RUPRUP Employs Employs UMLUML• The RUP uses the Unified Modeling Language (UML), a

consistent notation that can be applied for system engineering as well as business engineering.


Page Page 9595


Major Workflows Produce ModelsMajor Workflows Produce Models

Analysis & Analysis & DesignDesign

DesignModel

ImplementationModel

TestModel

realized by

implemented by

verified by

RequirementsRequirements

ImplementationImplementation

TestTest

Use-CaseModel

BusinessBusinessModelingModeling

Business Modelsupported by


Page Page 9696


UMLUML Diagrams Are Key System Artifacts in the Diagrams Are Key System Artifacts in the RUPRUP

Actor A

Use Case 1

Use Case 2

Actor B

user : 荤侩磊

mainWnd : MainWnd

fileMgr : FileMgr

repository : Repositorydocument : Document

gFile : GrpFile

9: sortByName ( )

L1: Doc view request ( )

2: fetchDoc( )

5: readDoc ( )

7: readFile ( )

3: create ( )

6: fillDocument ( )

4: create ( )

8: fillFile ( )

GrpFile

read( )open( )create( )fillFile( )

rep

Repository

name : char * = 0

readDoc( )readFile( )

(from Persistence)

FileMgr

fetchDoc( )sortByName( )

DocumentList

add( )delete( )

Document

name : intdocid : intnumField : int

get( )open( )close( )read( )sortFileList( )create( )fillDocument( )

fList

1

FileList

add( )delete( )

1

File

read( )

read() fill the code..

UI

MFC

RogueWave

global

DocumentApp

Persistence Window95

巩辑包府努扼捞攫飘.EXE

WindowsNT

巩辑包府浚柳.EXE

WindowsNT

Windows95

Solaris

览侩辑滚.EXE

AlphaUNIX

IBM Mainframe

单捞鸥海捞胶辑滚

Windows95

巩辑包府局敲复

盒魂券版狼窍靛傀绢棺匙飘亏栏肺狼沥焊矫胶袍楷搬葛胆 - 扩档快 95 : 努扼捞攫飘 - 扩档快 NT: 览侩辑滚 - 蜡葱胶赣脚: 览侩辑滚棺单捞鸥辑滚, 烹脚辑滚 - IBM 皋牢橇饭烙 : 单捞鸥辑滚, 烹脚辑滚

Document

FileManager

GraphicFileFile

Repository DocumentList

FileList

usermainWnd fileMgr :

FileMgrrepositorydocument :

DocumentgFile

1: Doc view request ( )

2: fetchDoc( )

3: create ( )

4: create ( )

5: readDoc ( )

6: fillDocument ( )

7: readFile ( )

8: fillFile ( )

9: sortByName ( )

漂沥巩辑俊措茄焊扁甫荤侩磊啊夸没茄促.

拳老包府磊绰佬绢柯巩辑狼沥焊甫秦寸巩辑按眉俊汲沥阑夸没茄促.

拳搁按眉绰佬绢甸牢按眉甸俊措秦捞抚喊肺沥纺阑矫难拳搁俊焊咯霖促.

Customernameaddr

withdraw()fetch()send()

receive()

<<entity>>

Forward Engineering(Code Generation)and

Reverse Engineering

Executable System

User InterfaceDefinition

DomainExpert

Openning

Writing

ReadingClosing

add file [ numberOffile==MAX ] / flag OFF

add file

close file

close file

Use Case 3

Source Code edit, compile, debug, link

Use-Case Diagram Class Diagram

Collaboration Diagram

Sequence Diagram

Component Diagram

State Diagram

Package Diagram

Deployment DiagramClass


Page Page 9797

Best Practices –5. Continuously Verify Quality

Best Practice 5: Best Practice 5: Continuously Verify QualityContinuously Verify Quality

Software problems are 100 to 1000 times more costly to find and repair after deployment. Verifying and managing quality throughout the project's

lifecycle is essential to achieving the right objectives at the right time.


Page Page 9898


What Do We Mean by Quality Verification Throughout What Do We Mean by Quality Verification Throughout the Lifecycle? the Lifecycle?

• It's important that the quality of all artifacts are assessed atseveral points in the project's lifecycle

• Artifacts should be evaluated as the activities that produce them complete and at the conclusion of each iteration.


Page Page 9999


Management of Quality in the Management of Quality in the RUPRUP• in the Requirements discipline

—includes analyzing the requirements artifact set for consistency, clarity, and precision

• in the Analysis&Design discipline—includes assessing the design artifact set, including the consistency of

the design model, its translation from the requirements artifacts, and its translation into the implementation artifacts.

• in the Implementation discipline —includes assessing the implementation artifacts and evaluating the

source code or executable artifacts• in the Test discipline

—address the three purposes of managing quality, identified previously


Page Page 100100


Management of Quality in the Management of Quality in the RUPRUP (Cont.)(Cont.)• in the Environment discipline

—addressing the purposes of managing quality. Here you can find guidance on how to best configure your process to meet your needs

• in the Deployment discipline—the implementation and deployment artifacts

• in the Project Management discipline —the reviews and audits required to assess the implementation,

adherence, and progress of the development process.


Page Page 101101

Best Practices –6. Manage Change

Best Practice 6: Manage Change Best Practice 6: Manage Change

Managing change includes management of workspaces, parallel development, integration, and builds.


Page Page 102102

Best Practices –6. Manage Change

What Do We Mean by Manage Change Throughout the What Do We Mean by Manage Change Throughout the Lifecycle?Lifecycle?

• A key challenge when you're developing software-intensive systems is that you must cope with multiple developers, organized into different teams, possibly at different sites, working together on multiple iterations, releases, products, and platforms.

• In the absence of disciplined control, the development process rapidly degenerates into chaos.

Management of Change in the Management of Change in the RUPRUP• In the Rational Unified Process, the Configuration & Change

Management discipline describes how you meet this challenge.


Page Page 103103

Q&A

Be concerned about the affairs of state before Be concerned about the affairs of state before others, and enjoy comfort after others.others, and enjoy comfort after others.

Documents

The Unified Software Development Process (Overview)read.pudn.com/downloads152/ebook/663434/Neusoft/2.2... · (Overview) ★★★ NEU ... The Rational Unified Process® or RUP® product