L36 Unified Process Ch16lect2

8/20/2019 L36 Unified Process Ch16lect2

1/61

U s i n g U M L , P a t t e r n s , a n d J a v a

O

b j e c t - O r i e n t e d S o f t w a r e E n g i n e e r i n g

Chapter 15, Software LifeCycle,

Unied Process


2/61

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 2

Outline of Today’s Lecture

• Unified Process: An iterative process model

• States of a software system developed with theUnified Process:

• Inception, Elaboration, Construction, Transition

• Artifacts Sets:

• ana!ement Set, En!ineerin! Set

• "or#flows:• ana!ement, Environment, $e%uirements, &esi!n,

Implementation, Assessment, &eployment

• Iterations• ana!in! iterations as software pro'ects

• ista#es in mana!in! iterations


3/61


Reiew of !enitions

• Software life cycle:• Set of activities and their relationships to each other to

support the development of a software system

• Software development methodolo!y: • A collection of techni%ues for buildin! models ( appliedacross the software life cycle


4/61


Software Life Cycle "uestions#Reiew$• "hich activities should I select)

• "hat are the dependencies between activities)

• *ow should I schedule the activities)

• +uestions to as#:• "hat is the problem)

• "hat is the solution)

• "hat are the mechanisms that best implement thesolution)

• *ow is the solution constructed)

• Is the problem solved)• Can the customer use the solution)

• *ow do we deal with chan!es that occur durin! thedevelopment) Are enhancements needed)


5/61


Life Cycle %odelin&

• So far we have discussed the life cycle models• "aterfall model

• (model

• Spiral model

• Issue(based model

• Today we will introduce another life cycle model• Unified Software Process


6/61


'Processes' in the Unied ProcessThe term Process is overloaded in the Unified Process

• icro process: Policies - practices for buildin! an artifact• .ocus: Intermediate baselines with ade%uate %uality and

functionality as economically and rapidly as practical

• Same as /Process0 in the IEEE 1234 Standard

• acro process: A set of micro processes and the

dependencies amon! them• .ocus: Production of a software system within cost, schedule and

%uality constraints

• Also called: 5ife cycle model

• eta process

• .ocus: 6r!ani7ational improvement, lon!(term strate!ies, andreturn on investment 8$6I9

• Also called: usiness process;


7/61


The Unied Process

• The Unified Process supports the followin!1; Evolution of pro'ect plans, re%uirements and software

architecture with well(defined synchroni7ation points


8/61


!i(erence) *n&ineerin& s+Production• En!ineerin! Sta!e

• &riven by less predictable but smaller teams, focusin! ondesi!n and synthesis activities

• Production Sta!e• &riven by more predictable but lar!er teams, focusin! on

construction, test and deployment activities

Focus

Risk

Artifacts

Activities

Quality Assessment

Engineering Stage Emphasis

Technical feasibility, Schedule

Planning, Requirements,

System Design Documents

Planning, Analysis, Design

Demonstration, Inspection

Production Stage Emphasis

Cost

Baselines, Releases

Implementation, Integration

Testing


9/61


Phases in the Unied Process

• The two sta!es of the Unified Process aredecomposed into four distinct phases

• En!ineerin! sta!e• Inception phase

• Elaboration phase

• Production phase• Construction phase

• Transition phase;


10/61


Transitionin& fro *n&ineerin& toProduction

"hen the /en!ineerin!0 of the system is complete,a decision must be made:• Commit to production phase)

• ove to an operation with hi!her cost ris# and inertia8i;e; bureaucracy9

ain %uestions:• Are the system models and pro'ect plans stable

enou!h)

• *ave the ris#s been dealt with)

• Can we predict cost and schedule for the completion ofthe development for an acceptable ran!e)


11/61


ElaborationInception

Construction

States of a Software Syste in theUP

Transition

Transition from

engineering stage toproduction stage.


12/61


-nception Phase) O./ecties

• Establish the pro'ect scope

• Identify the critical use cases and scenarios

• &efine acceptance criteria

• &emonstrate at least one candidate softwarearchitecture

• Estimate the cost and schedule for the pro'ect

• &efine and estimate potential ris#s;


ConstructionTransition


13/61


-nception Phase) 0ctiities

• .ormulate the scope of the pro'ect• Capture re%uirements

• $esult: problem space and acceptance criteria aredefined

• &esi!n the software architecture• Evaluate desi!n trade(offs, investi!ate solution space

• $esult: .easibility of at least one candidatearchitecture is e>plored, initial set of build vs; buydecisions

•Plan and prepare a business case• Evaluate alternatives for ris#s, staffin! problems,

plans;


14/61


-nception Phase) *aluation Criteria

• &o all sta#eholders concur on the scope definitionand cost and schedule estimates)

• Are the re%uirements understood, are the criticaluse cases ade%uately modeled)

• Is the software architecture understood)

• Are cost, schedule estimates, priorities, ris#s anddevelopment processes credible)

•Is there a prototype that helps in evaluatin! thecriteria)


15/61


*la.oration Phase) O./ecties

• aseline the software architecture• Establish a confi!uration mana!ement plan in which all

chan!es are trac#ed and maintained

• aseline the problem statement

• ase line the software pro'ect mana!ement planfor the construction phase

• &emonstrate that the architecture supports there%uirements at a reasonable cost in a

reasonable time+uestion: "hy does the Unified process not

recommend the establishment of a confi!urationmana!ement plan durin! the inception phase)




16/61


*la.oration Phase) 0ctiities

• Elaborate the problem statement 8/vision09 bywor#in! out the critical use cases that drivetechnical and mana!erial decisions;

• Elaborate the infrastructure;

• Tailor the software process for the construction

sta!e, identify tools;• Establish intermediate milestones and evaluation

criteria for these milestones;

• Identify buy?build 8/ma#e?buy09 problems and

ma#e decisions;• Identify lessons learned from the inception phase

to redesi!n the software architecture if necessary8/always necessary0:(9


17/61


*la.oration Phase) *aluationCriteria

• Apply the followin! %uestions to the results of theinception phase:• Is the problem statement stable)

• Is the architecture stable)

• &oes the e>ecutable demonstration show that the ma'or

ris# elements have been addressed and crediblyresolved)

• Is the construction plan credible) y what claims is itbac#ed up)

• &o all sta#eholders 8pro'ect participants9 a!ree that the

vision e>pressed in the problem can be met if thecurrent plan is e>ecuted)

• Are actual resource e>penditures versus plannede>penditures so far acceptable)


18/61


Construction Phase) O./ecties

• inimi7e development costs by optimi7in!resources

• Achieve ade%uate %uality as rapidly as practical

• Achieve useful version 8alpha, beta, and othertest releases9 as soon as possible




19/61


Construction Phase) 0ctiities

• $esource mana!ement, control and processoptimi7ation

• Complete component development and testin!a!ainst evaluation criteria

• Assessment of product releases a!ainstacceptance criteria


20/61


Construction Phase) *aluationCriteria

• Apply the followin! %uestions to the results of theconstruction phase:• Is the product baseline mature enou!h to be deployed

in the user community)

• E>istin! faults are not obstacles to do the release

• Is the product baseline stable enou!h to be deployed inthe user community)

• Pendin! chan!es are not obstacles to do the release

• Are the sta#eholders ready for the transition of thesoftware system to the user community)

• Are actual resource e>penditures versus plannede>penditures so far acceptable)


21/61


Transition Phase

• The transition phase is entered when a baselineis mature

• A usable subset of the system has been built withacceptable %uality levels and user documents

• It can be deployed to the user community

• .or some pro'ects the transition phase means thestartin! point for another version of the softwaresystem

• .or other pro'ects the transition phase means thecomplete delivery of the software system to athird party responsible for operation,maintenance and enhancement;




22/61


Transition Phase) O./ecties

•Achieve independence of user 8users can supportthemselves9

• &eployment baseline is complete and consistentwith the criteria in the pro'ect a!reement

• The final baseline can be built as rapidly andcost(effectively as possible;


23/61


Transition Phase) 0ctiities

•Synchroni7ation and inte!ration of concurrentdevelopment increments into one consistentdeployment baseline

• Commercial pac#a!in! and production

• Sales rollout #it development

• .ield personnel trainin!

• Test of deployment baseline a!ainst theacceptance criteria;


24/61


Transition Phase) *aluation Criteria

•Is the user satisfied)• Are actual resource e>penditures versus plannede>penditures so far acceptable)


25/61


-terations in the Unied Process

•Each of the four phases introduced so far8inception, elaboration, construction, transition9consists of one or more iterations

• An iteration represents a set of activities forwhich there is a milestone 8/well(defined

intermediate event09• The scope and results of the iteration are captured via

wor# products 8called artifacts in the UP9;


26/61


Phase s+ -teration

• A phase creates a formal, sta#e(holder approvedversion of artifacts

• It leads to a /ma'or milestone0

• Phase to phase transition:

• tri!!ered by a si!nificant business decision 8not by

the completion of a software development activity9• An iteration creates an informal, internally

controlled version of artifacts• It leads to a /minor milestone0

• Iteration to iteration transition:

• Tri!!ered by a specific software developmentactivity;


27/61


0rtifact Sets in the Unied Process

• Artifact: A wor# product in a uniform

representation format 8natural lan!ua!e, U5,@ava, binary code,9

• Artifact set: • A set of artifacts developed and reviewed as a sin!le

entity

• The Unified Process distin!uishes five artifact sets• ana!ement set

• $e%uirements set

• &esi!n set

• Implementation set

• &eployment set

Also called the engineering set.


28/61


0rtifact Sets in the Unied Process

Requirements

Set1; ision

document


29/61


Representation of 0rtifact Sets #1$

• ana!ement Set • oal: Capture plans, processes, ob'ectives, acceptance

criteria

• Dotation: Ad hoc te>t, !raphics, te>tual use cases;

• $e%uirements set

• oal: Capture problem in lan!ua!e of problem domain• Dotation: Structured te>t, U5 models

• &esi!n set• oal: Capture the en!ineerin! blueprints

• Dotation: Structured te>t, U5 models;

Rationale for Selection of 0rtifact


30/61


Rationale for Selection of 0rtifactSets #$

• Implementation set• oal: Capture the buildin! bloc#s of the solution domain

in human(readable format

• Dotation: Pro!rammin! lan!ua!e

• &eployment set

• oal: Capture the solution in machine(readable format• Dotation: achine lan!ua!e;


31/61


Life2cycle 3ocus on 0rtifact Sets

• Each artifact set is the predominant focus in one sta!e

of the unified process;

Inception Elaboration Construction Transition

Management

Set

Requirements Set

Design Set

ImplementationSet

DeploymentSet

i h if


32/61


%ana&in& the 0rtifact Sets

• Some artifacts need to be updated at each ma'ormilestone 8after a phase9

• 6ther artifacts must be updated at each minormilestone 8after an iteration9

• Artifact set roadmap• isuali7ation of the updates of artifacts across the

software life(cycle

• The software pro'ect mana!er is responsible for

mana!in! the artifact set roadmap• Artifact set roadmap: .ocus on models

• Artifact set roadmap: .ocus on documents;

0rtifact Set Roadap) 3ocus

Informal


33/61

pon%odels Inception Elaboration Construction TransitionManagement Set

Requirements Set

Design Set

Deployment Set

1. Vision2. WBS3. Schedule4. Conf. Management5. Project Agreement6. Test cases

1. Analysis Model

1. System Design2. Interface Specification

Implementation Set1. Source code2. Test cases

1. Alpha-Test2. Beta-Test

Baseline

0rtifact Set Roadap) 3ocus on

Informal


34/61

0rtifact Set Roadap) 3ocus on!ocuents

Inception Elaboration Construction Transition

Management Set

Requirements Set

Design Set

Deployment Set

1. Problem Statement2. WBS3. SPMP4. SCMP5. Project Agreement6. Test plan

1. RAD

1. SDD2. ODD

Implementation Set1. Source code2. Test cases

1. User Manual2. Administrator Manual

Baseline

% d l ! t


35/61


%odels s+ !ocuents

• any software pro'ect mana!ers pay too much

attention on the production of documents • &ocumentation(driven approach

• The production of the documents drives the milestonesand deadlines

• odel(driven approach• The production of the models drive the milestones

deadlines

• ain !oal of a software development pro'ect:• Creation of models and construction of the software

system

• The purpose of documentation is to support this!oal;

4istorical Reasons for


36/61


4istorical Reasons for!ocuentation2!rien 0pproach

• People wanted to review information, but did not

understand the lan!ua!e of the artifact• People wanted to review information, but did not

have access to the tools to view the information

• Do ri!orous en!ineerin! methods and lan!ua!es

were available for analysis and desi!n models• Therefore paper documents with ad hoc te>t were used

• Conventional lan!ua!es for implementation anddeployment were hi!hly cryptic• A more human(readable format was needed

• ana!ers needed /status0 • &ocuments seemed to be a !ood mechanism for

demonstratin! pro!ress;

0rtifact !rien 0pproach


37/61


0rtifact2!rien 0pproach

• Provide templates for documents at the start ofthe pro'ect

• Instantiate documents automatically from thesetemplates

• Enrich them with modelin! and artifact information

!enerated durin! the pro'ect• Tools automatically !enerate documents from the

models; E>amples:• eneration of analysis and desi!n documents

8Commercial CASE tools9

• eneration of the interface specification 8@avadoc9

• Test case !eneration 8@Unit9

• Schedule !eneration 8icrosoft Pro'ect9;

%icro Processes in the Unied


38/61


%icro Processes in the UniedProcess• The Unified Process distin!uishes between macro

and micro process:• The macro process models the software lifecycle

• The micro process models activities that produce artifacts

• The micro processes are also called wor#flows in theUnified Process;

or67ows in the Unied Process


39/61



• ana!ement wor#flow

• Environment wor#flow

• $e%uirements wor#flow

• &esi!n wor#flow• Implementation wor#flow

• Assessment wor#flow

• &eployment wor#flow;



40/61



• ana!ement wor#flow• Plannin! the pro'ect 8Problem statement, SPP, SCP,

test plan9

• Environment wor#flow• Automation of process and maintenance environment;

Setup of infrastructure 8Communication, confi!urationmana!ement, ;;;9

• $e%uirements wor#flow• Analysis of application domain and creation of

re%uirements artifacts 8analysis model9

• &esi!n wor#flow• Creation of solution and desi!n artifacts 8system desi!n

model, ob'ect desi!n model9;

or67ows in the Unied Process #$


41/61


or67ows in the Unied Process #$

• Implementation wor#flow• Implementation of solution, source code testin!,

maintenance of implementation and deploymentartifacts 8source code9

• Assessment wor#flow• Assess process and products 8reviews, wal#throu!hs,

inspections, testin!9

• &eployment wor#flow• Transition the software system to the end user;

or67ows wor6 across Phases


42/61


• "or#flows create artifacts 8documents, models9

• "or#flows consist of one or more iterations per phase;

ImplementationWorkflow

ManagementWorkflow

Requirements Workflow

Design Workflow

DeploymentWorkflow

Assessment

Workflow

EnvironmentWorkflow

Inception ElaborationConstruction Transition

%ana&in& Pro/ects in the Unied


43/61


& & /Process

• *ow should we mana!e the construction ofsoftware systems with the Unified Process)

• Approach• Treat the development of a software system with the

Unified Process as a set of several iterations

• Some of these can can be scheduled in parallel,others have to occur in se%uence

• &efine a sin!le pro'ect for each iteration

• Establish wor# brea# down structures for each of the 3wor#flows;

Pro/ect Phases s+ Unied Process


44/61


Phases

• Every pro'ect has at least B states• Conceivin!: The idea is born

• &efinin!: A plan is developed

• Startin!: Teams are formed

• Performin!: The wor# is bein! done

• Closin!: The pro'ect is finished;

Phases of a Software Pro/ect


45/61


Phases of a Software Pro/ect

System Done

New Technology

Conception

do/FormulateIdea

do/Cost-BeneftAnalysis

do/FeasibilityStudy

do/e!iew

!enitiondo/"roblem Statement

do/So#tware Architecturedo/So#tware "lan

Start

do/"ro$ect %ic&o'

do/In#rastructure Setu(

do/S&ill Identifcationdo/Team Formation

Steady State

do/De!elo( Systemdo/Controlling

do/is& )anagement

do/e(lanning

New e*uirement

+oAhead

Sco(eDefned

Terinationdo/Client Acce(tance

do/Deli!ery

do/"ost )ortem

Teams assembledIn#rastructure done

Pro/ect Phases s+ Unied Processh


46/61


Phases

Each iteration in the unified process phasesInception, Elaboration, Construction, Transition

should !o throu!h each of these B pro'ect phasesF

System Done

New Technology

Conception

do/FormulateIdeado/Cost-BeneftAnalysis

do/FeasibilityStudy

do/e!iew



Start

do/"ro$ect %ic&o'

do/In#rastructure Setu(do/S&ill Identifcation

do/Team Formation

Steady Statedo/De!elo( System

do/Controllingdo/is& )anagement

do/e(lanning

New e*uirement

+oAhead

Sco(eDefned


do/Deli!ery

do/"ost )ortem


Unied Process %ana&eent%i 6

f d


47/61


• Pro'ect mana!er s#ips the start phase

• Pro'ect mana!er s#ips the definition and start phase

• Pro'ect mana!er 'umps strai!ht to the steady state phaseafter 'oinin! the pro'ect late

• Pro'ect mana!er cancels the termination phase;

%ista6es

System Done

New Technology

Conception

do/FormulateIdea


do/FeasibilityStudydo/e!iew



Start

do/"ro$ect %ic&o'


do/S&ill Identifcation

do/Team Formation

Steady State

do/De!elo( Systemdo/Controlling

do/is& )anagement

do/e(lanning

New e*uirement

+oAhead

Sco(eDefned


do/Deli!ery

do/"ost )ortem

Teams assembledIn#rastructure doneX XX

XX XX

%ista6e) S6ippin& the Start Phase


48/61


%ista6e) S6ippin& the Start Phase

• ain reason: Time pressure• $easons for start phase

• Inform sta#eholders that the pro'ect has been approvedand when wor# will start

• Confirm that sta#eholders are able to support the pro'ect

• $eevaluate and reconfirm wor# pac#a!es with developers

• E>plain your role as mana!er to sta#eholders anddevelopers;

System Done

New Technology

Conception

do/FormulateIdea


do/FeasibilityStudy

do/e!iew


do/So#tware Architecture

do/So#tware "lan

Start

do/"ro$ect %ic&o'



do/Team Formation

Steady State

do/De!elo( System

do/Controlling

do/is& )anagement

do/e(lanning

New e*uirement

+oAhead

Sco(eDefned


do/Deli!ery

do/"ost )ortem

Teams assembledIn#rastructure doneX

%ista6e) S6ippin& !enition andSt t Ph


49/61


Start Phase

• Gnown territory ar!ument • /I have done this before, no need to waste time0 • Even thou!h a pro'ect may be similar to an earlier

one, some thin!s are always different

• Un#nown territory ar!ument • /y pro'ect is different from anythin! I have ever done

before, so what !ood is it to plan)0

• It is better to create a map if you are attemptin! totravel into un#nown territory;

System Done

New Technology

Conception

do/FormulateIdea


do/FeasibilityStudy

do/e!iew



do/So#tware "lan

Start

do/"ro$ect %ic&o'



do/Team Formation

Steady State

do/De!elo( System

do/Controlling

do/is& )anagement

do/e(lanning

New e*uirement

+oAhead

Sco(eDefned


do/Deli!ery

do/"ost )ortem

Teams assembledIn#rastructure doneXX

Pro.le) 8oinin& a Pro/ect Late


50/61


8 & /

@oinin! a pro'ect late is not that uncommon• 6ften the plannin! has been performed by another

person, usually a hi!h level mana!er, and you areas#ed to ta#e the pro'ect over

• 6r the pro'ect is in such a bad state, that the currentpro'ect mana!er needs to be replaced

•$eason to 'ump ri!ht into steady state phase• /The plan has already been developed, so why should

I !o bac# to the conception and definition phases)0

• $easons to reevaluate the conception anddefinition phase:

1; See if you can identify any issues that may have beenoverloo#ed


51/61


• Ta#e the time to ensure that all tas#s are completedor identified as open issues:

• 6therwise you never really #now how successful your

pro'ect was

• Try to learn from your mista#es 8/lessons learned09:• If you donHt, you will ma#e the the same mista#es a!ain,

and may even fail;

System Done

New Technology

Conception

do/FormulateIdea


do/FeasibilityStudy

do/e!iew



do/So#tware "lan

Start

do/"ro$ect %ic&o'



do/Team Formation

Steady State

do/De!elo( System

do/Controlling

do/is& )anagement

do/e(lanning

New e*uirement

+oAhead

Sco(eDefned


do/Deli!ery

do/"ost )ortem


X

• $easons for s#ippin! or notcompletin! the termination phase:

• ou leave a pro'ect to move on ri!ht tothe ne>t one; 8ecause you are asuccessful mana!er:(9

• Scarce resources and short deadlines

• A new pro'ect is always more

challen!in! than wrappin! up an old one

Suary


52/61


y

• Unified Process: Iterative software lifecycle model•

Emphasis on early construction of a software architecture• Emphasis on early demonstrations of the system

• &efinitions• Phase: Status of the software system;

• 4 phases: Inception, Elaboration, Construction, Transition

• "or#flow: ostly se%uential activity that produces artifacts

• 3 wor#flows: ana!ement, environment, re%uirements,desi!n, implementation, assessment, deployment;

• B artifact sets: ana!ement set, re%uirements set,desi!n set, implementation set, deployment set

• Iteration: $epetition within a wor#flow;

• Each unified process iteration is a software pro'ect;

0dditional References


53/61


• "al#er $oyce• Software Pro'ect ana!ement, Addison("esley, 1JJK;

• Ivar @acobsen, rady ooch - @ames $umbau!h• The Unified Software &evelopment Process, Addison

"esley, 1JJJ;

• @im Arlow and Ila Deustadt• U5 and the Unified Process: Practical 6b'ect(6riented

Analysis and &esi!n, Addison "esley,


54/61


Coponent :ased Software!eelopent


55/61


!eelopent

• uy• Commercial of the shelf components 8C6TS9, reusable

ob'ects,

• uild• Custom development, build everythin! from scratch,

• Comparision: uy vs; uild

Coercial Coponents #':uy;$


56/61


Predictable license costs

roadly used, maturetechnolo!y

Available now

&edicated supportor!ani7ation

*ardware?softwareindependence 8sometimes9

$ich in functionality

.re%uent up!rades

Up(front license fees $ecurrin! maintenance fees

&ependency on vendor

$un(time efficiency sacrifices

.unctionality constraints

Inte!ration not always trivial

Do control over up!rades andmaintenance

Unnecessary features thatconsume e>tra resources

6ften inade%uate reliability andstability

ultiple(vendorincompatibilities;

Custo Coponents #':uild;$


57/61


Complete chan!e freedom

Smaller, often simplerimplementations

6ften better performance

Control of developmentand enhancement

E>pensive, unpredictable

development Unpredictable availability

date

Undefined maintenancemodel

6ften immature and fra!ile Sin!le(platform

dependency

&rain on e>pert resources;

%odel of the Unied Process#0nalysis$


58/61


#0nalysis$• Inputs:

• Problem Statement

• .unctional $e%uirements:• Top level use case: &evelop software system that

implements the problem statement;

• 6utputs:

• $e%uirements analysis document• Software pro'ect mana!ement plan

• Software confi!uration mana!ement plan

• System desi!n document

•6b'ect desi!n document• Test plan and test cases

• Source code

• User manual and administrator manual

%odel of the Unied Process) Syste!esi&n


59/61


!esi&n• &esi!n oals:

•*i!h performance, dependability, low cost, maintainability,usability

• Subsystems:• The wor#flows ana!ement, Environment, $e%uirements,

&esi!n, Implementation, Assessment, &eployment

• *ardware?Software mappin!:• Each subsystem is runnin! on its own node;

• Concurrency:• The threads can run concurrently;

• lobal control flow:• Event(driven; The subsystems communicate via events;

Typical events are: L$e%uirement has chan!ed/, L$eviewcomments available/, LTime has e>pired/9

%odel of the Unied Process) Syste!esi&n #ctd$


60/61


!esi&n #ctd$

• Persistent &ata:

• ision, Process odel, Confi!uration Items, Analysis odel,System &esi!n odel, 6b'ect &esi!n odel,Communication data;

• Access control:• Sta#eholders 8End users, mana!ers, customers,

developers, 9 have access to the persistent data withaccess ri!hts defined dynamically by environmentwor#flow;

• oundary Conditions• Startup of wor#flows: All wor#flows start simultaneously

• Steady state of wor#flows: "or#flows wa#e up on an event,process the event, and !o to sleep afterwards;

• Terminal conditions of wor#flows: A ris# has occurred thatcannot be dealt with

Lifecycle -proeent


61/61


• There are = possibilities to improve a multi(step

process• +uality improvement: "e ta#e an n(step process and

improve the efficiency of each step

• E>ample: T+ 8Total +uality ana!ement9

• 6verhead reduction: "e ta#e an n(step process andeliminate some of the steps

• E>ample: E>treme Pro!rammin!

• Concurrency: "e ta#e an n(step process and paralleli7esome of the seps or use more concurrency in theresources bein! used

• E>ample: Unified Process;