Software Process

Software Process
• What are the main activities of

....nlng software processes?
• What are the main software

process types?
The Software • How would a learn such as a student

Development team go about setecting a process?
Ufecycle
Figure 3.1 The context and learning goals for this chapter
A software project progresses through a se ries of activities, sta rti ng at it conception and con tinuifl8
even beyo nd its reicllsc to customers. There are numerous ways (or individual and team s to organize these
activities. T ypically, a prOject is organized into pba,es, each wllh a prescribed se t of activities conducted
during that phase. A ",flu/art proces, prescribes the interrelatio nship among the phase byexpre sing their order
and frequency , a well as defi ning the deliverables of th" project. It also speciRes criteria for moving from one
phase to the next. Specific software processes, called software process ",odd, or life cycle modds are
described. Th is chapter is o rga nized to first des ribe the individual activitie of ofrware proce ses, and thcn
to describe process modds the variou ways in which these aCtl vi lieS can be pursued
In addition to the activities prescribed by proce s models, there is a et of ge neri actiVities, called
"mbrdla acIIV";es , that are implemen ted throughout the life of a proJect. For instance, projec ts contain certain
THE ACTIVITIES OF SOFTWARE PROCESS 33
risks th at if the cume 10 pass ca n affec t the uccessful outcome o f the so ftware. Risks need to be identiAed ,
mo Ol tored , and ma naged thro ugh out the life of a project. Th is is an umbrella ac tivity known as risk
management Ot her umbrella activities include projc t man age me nt, con Agu ratio n ma nageme nt, and quality
manage me nt. Project ma nageme n t is covered in Part III , con Rgu rat ion ma nageme nt in C h apter 6, and quality
man.geme nt t h ro ug ho ut, but especia ll y in Pa rt VI1.
People someti mes associa te process with overhead, unnecessary pape rwork, lo nge r schedul es, and so
on. In other words , they fee l that process d oesn't add v.lue, o r wor e, tha t it adversely affects the success of a
projec t. Whe n imp le me nted incorrectl y, sofrware processes ca n indeed lead to undesirable results. H owever,
as " 'e explain in th is c hapte r, if p rocesses are applied with a degree of flexi bil ity and ada ptab ili ty , they are o f
grea t be ncAt a nd invaluabl e to the successful o utcome o f projects.
In certai n situat ions, a versio n 01 working softw are contain ing a subset of th e overall pro duc t
func tio nal ity is req uired earl y in the overall schedule. This versio n of the emerg in g pro duc t, called a
prototypt, typ ica lly impl eme.nts fu nc ti o nal ity th at is deemed a risk to the project. T y pica l rcaso ns to bu ild
prototypes include provi ng tec hnical feas ibil ity and validating the usab ili ty of a user interface. Pro totypes are
covered III de tail in Secti o n 3.2.3. I.
T o rei n fo rce the contents of th is c hapte r a nd to provi de gui dance to snlde nts at the sa me ti me, thi s
c hapler e nds with a sectio n devo ted to getting stude nt teams started with a te ml projec t.
3.1 THE ACTIVITIES OF SOFTWARE PROCESS
Most software process mo dels prescribe a similar set 01 phases and ac tiv ities. The differe nce between models
is the orde r and freque ncy o f the phases. Some process models, suc h as the wate rfa ll , exec ute each ph ase o nl y
o nce. O the rs, suc h as ite rative mod els, cycl e throug h multiple times . This section desc ribes th e phases that
are prevale nt in most softwa re process model s, and is summarized in Figure 3.2. Th e ph ases in Fi gure 3. 1 and
Figure 3.2 are ide ntical , except that Fi gure 3. 1 co mbines ince pti o n and planning . The partS are explained
bel ow. SpeCific process mo dels a nd h ow they impleme nt the phases are covered In Section 3.2.
1. Inception
Software produc t is co nceived a nd d eA ned.
2. Planning
In itia l schedule, resources a nd cost arc dete rmined .
3. Requirements Analysis
Spcc ify w h a t the ap pl ica ti o n must do , answcrs "what7"
4. Desig n
Specify th e parts and how they fi t; a nswer< "how7"
5. Imple me ntation
Wri te the code .
6 T esting
Exe.::ute the app il atio n with In put test data
7 . Mainte na nce
Re palf d feets and add capabi lity.
Figure 3.2 The main phases of a software project, showing Inception as a separate phase
CHAPTER 3 SOFTWARE PROCESS
Inception ( . d Wh h
Th, Is the phase where illlti31produ t Idca, arc formulat ed and a Vl<lo n o f the <0 tware , o ncclve . et er
it is il brand new produ lor an .lI11pr vcrn c nt to . so (tWlJrc, every PrOlcct start, wilh an ,dea of what ,s to
be built. Malor hlllctio naloty and project cope is deAned . Target customers and market are
idcntlAed . Customers and takeholders may be con,ulted (o r hl gh . level Input Into software functlonaloty.
However, stakeholder involvement at LillS stage ,s doffere nl fro m that during the subsequent requirements
analy is phase. Dunng Inception, the goal i to galher very high level feedback. As an example, suppose a
company is considering budd ing a video store applicatio n. A market ana lysis may be conducted to determIne
the existe nce of competing video store applications. A summary of their features and an analysIS of their
tre ngths and weaknessc is compi led. The commercia l uceess o( the propo cd application is determined by
identifying potential new customers and contacting them for Info rmation concemlng,
• Their satisfaction with their current application

• Ideas for needed fun ctionality and feature
• Their likelihood of adopti ng a new product
As an example , suppose that a currenrly deployed ystem requires custom hardware, but potential
customers would prefer using standard Windows PCs. Based on this analysis and feedback , the need for and
Viability of the proposed applocation is determined. If· it is deemed prom iSing, high . level functionality for the
application is deAned based on the feedback received, and the project proceeds to the planning phase.
Planning
Once a high . level idea for the application is developed , a plan is formulated to produce it. Since this is still
very early in the overall life cycle and detailed infom,ation is not yet available, the plan will be a rough
estimale. However, some plan must be in place to understaAd the scope and cost of the project . A project plan
that ide ntifies the high.level activities, work ilems, schedule, and resources IS developed. From this
informatio n a cost estimate can be developed. This ste p is very important to determine the feasibility of
a project . For example, if the cost is deemed to be too high , a reduction in features may necessaty. If the
product release date is too late, more resources may be added It is critica l that the e types of problems be
identified as early as possib le so corrective action can be taken .
The results of this phase arc typically captured in a oftware Project Management Plan (SPMP). The
SPMP and project management are covered in Part IV. Because the plan is only a rough one at thi stage, it is
necessary to modify and adapt it throughout the lofe of the project. For example, suppose that during
subsequent requirements analysis potential new customers arc identiAed and additional functionality is
requested. Using the video store application as an example , suppose a request is received to add additional
workstations to stores so customers can retrieve detailed movie information, such as release date, movie
studio, cast, director, producer, genre, and so on. This new fun ctionality may require additional proj«t
resources and changes to the schedule. The SPMP would be updated as a result . Some life cycle models, such
as the spiral model described below, prescribe speciAc points in Ihe process where planning information is
revisited and updated when required . Agile projects, as will be seen , keep planning to a minimum.
In addition to the activities described above , a plan is developed for managing project artifact such as
technical specifica tions and source code . This is known as to.HfiouCQtlOH ""'""Q(D!",t, and mcludes tasks such as
tracking changes to artifacts and handling multiple versions. Configuration man.gement is pl.nned .t th.l
early project stage, before the first project artifacts are generated. Configuration management is .n
detail in Chapter 6.
THE ACTIVITIES OF SOFTWARE PROCESS 35
Requirements Analysis
During this phase . infolmation regarding customer wants and needs. and problems the software is
Intended to solve are gathered . Info mlatlo n ga thered and documented is in much greater than it was in
the inception phase. During inceptio n. only e nough information is required to start planning the project.
During analysis, speciAc product functions and features are denned along with requirements
such as performance, reliability. and u ability. Requirements are ge nerated in a form that is completely
readable and understa ndable by customers. Hi gh-level requirements in particular are typically expressed in
ordinary English (or the loca l language) . Various techOlques arc used to o btain this information, including
customer interviews and brainstorming sessIo ns. Requirements describe what the application is intended to
accomplish . They are specified in sumcient detail 50 they can be used as input for the subseq uent design
phase, which defines how the software will be buill. The resul ts of the analysis arc typically captured in a
formal Software Requirements Specification (SRS ), which serves as input to the next phase.
Software Design
The purpose of software design is to deAne how the software will be constructed to sa tisfy the requirements.
That is. the internal struCture of the so ftware is deAned . The two main levels of software design are software
architecture and detailed design . Software architecture is analogous to the overall blueprints of a hou e as a
whole. Blueprints specify the number of rooms and their layo ut . door and window locations, number of Aoors,
and so on. Software architecture speCifics how the software is broken into subsystems o r modules and the
software interfaces between them . For example. the architecture for a video store application may consist of
components such as a user interface module, a problem domain module. and a database module . Agile
projects general1y perform design . implementation , and much testing in an intcrweaved fashion rather than
cal1ing OUt design as a separate phase.
The detailed design is analogous to the details contained in a house blueprint. In house plans. details
such electrical wiring and plumbing are specified . In software . details such as al gorithms and data structures
are speCified. Other aspects of software design include user interface design and database desig n. The output
of software de ign is specified in a SofJware Design Document (SOD) and is used as input to the
implementation phase. Software design is covered in detail in Part V.
Implementation
This phase consists of programming. which is the translation of the software design develo ped in th e previous
phase to a programm ing language. It also involves integration . the a sembly of the so ftware parts. The outPUt
consists of program code that is ready to be tested for correCtness. For agile techniques. desig n implementa-
tion and muc h test 109 arc performed in tandem .
Testing
In this phasc . the code produced durin g the implementat io n phase IS testcd fo r correctne s. Testing is
performed at three Icvels. First . Individual modules are tes ted by develo pers. econd. modules are integrated
and lested to e nsure that they interface properly . Third . once all the modules have been integrated, the e ntire
is tested to e nsure that it meets the user req uirements. ystem testing is typical1y co nducted by an
indepe nde nt quality assura nce (QA ) tea m. Rcca l1 fro m hapter 2 that this testIn g proccs, IS called ""I,dalloll .
Once system testing has been comple ted, severa llevc1< of uSlOmer tcstin!! are co nducted . During brill Ir li"9
the software is as 10<" to the final rciea,e as possible. and i given to part o f the e ll ta mer community with th e
understanding lhat they report any defec ts the y And . The goa l is to uncover a set of problem, that could o nl '
be ruscovcred wllh lhi s type of "rcal -world" tes tlnl!. O nce beta testing is comple te, at' ,plalll( If 11'''9 IS
36 CHAPTER 3 SOFTWARE PROCESS
condu Icd o nlhc "fi nal" release of <u hwarc. arc omprised of a of <y<u:m le<ls, and aTC
condu Icd b e ither the cuStomer or a represcnlalivc of Ihe CUSlOmer lO ensure Ihal II mee ts the customers
nlena for relea e. o m lilli e a round of acceptance tcstong is cond uc ted prior to beta testing, to make sure
that the system mcets ert"i n e ntcria before it is given to cu,to me rs for beta testing.
Maintenance
Aher the sohware IS released to u tomers, the ma on le nance phase commences. During mainte-
nance, modiAcations arc made 10 the sohware that "rbe Ihrough one of the fo ll owi ng :
• The repair of software ddecls Ihal a rc dIscovered during no m,,1 customer use of the system
• ell lomer request for enhancements
• A desire to imp rove at tributes of the system suc h a pcrformance o r reli abil ity
Mod, fica t, o ns to the . oftware arc bundled togethe r, and new versio ns of th e software with these
mo di ficati o ns arc re leased . Maintenance is discussed in detail in C hapter 29.
Figure 3.3 shows examples of artifacts produced durin g each phase fur our example video store appl ication.
• Inception
" . .. An applica ti o n is needed to kee p track of vi deo rental s . . . "
• Planning (Software Project Management Plan )
" . . . The project will take 12 months, require 10 people and cost $2M ... "
• Requirements Analysis (Product , Software Req uire me nts Spec .)
" ... The clerk shall e nter video title, re ntcr name and date rented . The system shall . .. ..
• Design (Software Design Document, Diagrams and text)
.. ... classes DVD, Vid,oSlore , . . . , related by . . . "
• (Source and object code )
• . class DVD \ String title, . .. I...

• Testing (Software T est Documentation, test cases a nd test results)
" . . . Ran test case: Rrnl "Th, Ma ln'x" 001 OcI J , ro,l "Stoll'seui'" 001 Oct 4I return -T/',
.
Ma.x
tn' ·" 0" 1..1 f0 • •
Result : "Stalli"uil" du, Oct " 200. balancc of $8. (comrt) .. "
• Maintenance (Modir.cd requirements, desig n, code, and text)
Defect repair, "ApplicatIon crashes when balance is $10 a nd attempt IS made to "G W'tb tbt
W.
,n d" ," rent 0"' I
Enhancement, "Allow searching by d irecto r."
Fllllre 3.3 The main phases applied to a video store application

SOFTWARE PROCESS MOOELS 37
3.2 SOFTWARE PROCESS MODElS
ftwan:: proces model deAne the order and freque ncy of phases in a project. The following sections
describe the most important process models, starting with the classical waterfall process .
3.2.1 The Waterfall Process Model
One of the oldest oftware process models was deAned by Royce [ I] and is called the wa t,rjall proms. Despite
its many weaknesse (described later in the section), the waterfall process is still in Widespread use today and
is the basis for many other more effective processes.
FIgure 1.6 in Chapter I illu trates the phases of the waterfall process . Note that Royce's mode l begi ns
with the requirements phase he did not include inception and planning phases. In practice, o rganizations
implementing a wa terfall process wou ld typicall y start with these phases. The waterfall executes in a
manner through each phase, conclud ing with maintenance. n,e
output from o ne phase is used as
input for the next, implying that a phase is not tarted until the previous o ne has completed . It is accepted in
waterfall processes that there is a small overlap between adjacent phases. As an example , some personnel wi ll
be performing the last part of requirements analysis while others will have already started the design phase .
The waterfall process is c haracterized by documents generated by the time each phase is completed.
These include requirements specification and design specification, for example . Also, there are usual ly
entrance and exit criteria between phases to e nsure that a phase is completed successfull y before moving on .
In practice, an iterative re lationship between successive phases is usually inevitable. For example , after
the requirements are comple ted, unforeseen design d ifficult ies may arise. Some of these issues may resu lt in
the modiAcation or removal of co nflicti ng o r no n. implementable req uirements. Thi s may happen everal
times, resulting in looping between requirements and desig n. Another example of feedback is between
maintenance and testing. Defects a re discovered by custo mers after the software is released. Based on the
nature of the problems, it may be determined there is inadequate test coverage in a particular area of the
software. Additiona l tests may be added to ca tc h these types of defects in future sohwa re releases. A genera l
guIdeline, often accepted to sti ll bewithin the wa.terfa ll framework , is that feedback loops should be restricted
to adjacent phases . This min imize potent ially expe nsive rework if the feedback were to spa n multiple phases.
An modified model ill ustrati ng this iterative relationship i sh ow n in Figure 3.4 .
time
•
ReQuiremenls
Design
Implementallon
Phases (aerlvilles)
Tesllng
Malnlenance
Figure 3..4 The waterfaU software development process In pracllce: fcedMck Is IneVitable
38 CHAPTER 3 SOFlWARE PROCESS
A n,.lor limitati o n of the waterfa ll pro.:e>, th at the tC\ling phase DC at the end of the development
c de th e f,rs t time the ,y,te m is tes ted a a w ho le. Maj or Issue< <u h as timing, performance, storage, a nd
on an be discovered o nl y then . Even With thorough up-fro nt these kinds of factors arc difficult to
predi t until en ountcred during te' ting. o lutJo ns may require either complex de'ign c hanges or
tions to the req Uirements that the de Ig n 15 based o n, necessita ting Ite ration beyond adjacent phases
Discovering and repairing the e types o f ddect, <0 late in the developm e nt cycle ca n Jeopardize the project
schedule.
Major adva ntages and d isadvantages of the waterfa ll process are summanzed below.
Advantages
• S".plt 'llid tasy fo uSt: Phases arc executed and compl e ted senall y, with speCIfic e ntrance a nd exit criteria for
movinS between phases. O rde rly execu ti on of phases is easy to comprehe nd .
• Pracfiad for many and ptOplr I,aat milch txptritna ",iii, The process is well understood , a nd many people
are com fortab le with its execution .
• Easy fo manag' du, fo fb , rigidi fy of fh, mod,l: Each phase has speciAc deliverables and a review process.
• Facililales al/ocahon of rrsourcrs (due to sequential nature of phases): Distinct phases fac il itate allocation of
perso nnel With distinct skills.
• Works "" II for smallcr proj,cls ",hm rrqui,rmcnls arr D'ry w,lI It isn't necessa ry to add complexity of
iteration if requirement arc well known up fTo nt.
Disadvantages
• R,qui"mcnls mu,1 bt h,o",n up fron l: It's di ffic ult to imagi ne every detail in advance. Most projects start out with
some uncertai nty, a nd mo re de tails are learned as the prOject prog resses.
• Hard 10 rs limalt reliably , T o ga in conAde nce in an estimate, there may be the need to design and implement
parts, especia lly riskier o nes. Estimates become mo re preCise as the project progresses.
• No f"dback of ,y,fem by ' Iakrholdm unlil afltr l" ling phaSt: The process does not facilitate intermediate versions.
Stakeholders often need reassurance of progress and confirmation that what is being develo ped meets
requirements.
• Major problem, ",ill, system artn·1 discolXfld unlil lal, in proms : The testi ng phase is where these problems are
found , but it leaves very little time for correctio n, resulting in potentially d isastrous effects on projec t
schedule and cost.
• LAck of par.Ilt/lSm : Each phase is executed to completion . Disjointed parts of the system could otherwise be
completed in parallel.
• inrfficitnl USt of mourers : T eam members can be idle while waiting for o thers to complete their dependent tasks
or for phases to complete. Also, someone good at requireme nts analy is is not neee sarily good at
programming.
Ikcause of fac tors like these, alternative (but related) proce ses are often emplo ed , and these are
covered in subsequent sections.
SOFTWARE PROCESS MODELS 39
3.2.2 Iterative and Incremental Development
The wa",rfall process is c harac terized by a seque ntial executio n through the phases. It is generally agreed that
the order of the phases d ictated by the waterfall i fundamental : ga the r requirements. c reate a sohware desig n
to realize the requireme nts. imple me nt the design, and test the implementation. The problem arises.
however. when this is caled up to gather all the requirement . d o all of the design. implement all of the code.
and test all of the system in a linear fashion [2]. Except for rhl' emallce' o( projects this is imP'1'ctical. As the
system is developed and renned , more i lea rned and a need arises to revisit each of the phases. That is,
software is mo re naturally developed in a cyclica l manner. where a part o f the system is deve lo ped and tested.
feedback is ga thered . and based o n the feedback more of the system is developed. This reAects the fact that
not everything is unders tood at the start of a Ilrraliv( processes accept thi s cyclica l nature and are
discussed in the rest of th is section . Figure 3. 1 is drawn in a way that reflects this.
ilcraliv< process is typined by reDba ted executi o n of tbe walerfall pbases. in whole o r in part. resulting
in a ren nement of th e req uire me nts, design. and implementation . An iterative process is incrm", lol if each
iteration is relativel y small. At the conclusion of SlI c h an iteration . a piece of operat io nal code is p roduced that
suppo rts a subset of the nna l produc t functionality and (eatures. Project artifacts suc h as plans, speci flcatio ns.
and code evolve during eac h phase and ove r the life of the project. Artifacts are co nsi de red comple te only
when the software is released .
As defined by Cockburn (3). incremental development is "a sch eduling a nd staging strategy that allows
pieces of the system to be devel o ped at different times o r rates and integrated as they are completed: This
implies that iterations need no t be executed serially, but can be develo ped in parallel by separa te teams of
people . Successive increments implement an inc reasi ng set o f functionality and features until the nnal
iteration . which produces the nnal product. Figure 3.5 illu.s trates this concept for a project with three
iterations. Note that the output of each testing phase is a working subset of the nnal p roduc t that
incrementally contains more functionality .
An iteration other than an incremental one is sometimes defined as "a self-contai ned m ini -project. with a
well-denned outcome: a stable. integrated and tested release" [2]. That is, each itera ti on is a self-contained
lime
1 •• •• • • • • • • • • ••• I •
• MIL EST 0 N E S:
First iteration completed X ,,, •
•
•
• Product released X
• • •
• • • ,• • •
SCHEDULE •
•• ,
•
•• • • ••
Iteralion' 1 2 a
. - ••• _.•• .,_.-
• •
,
,• ._.,• •
••
•
,•
•
• -
Requlrements
• •
•
•• • ,•
analysls
1
•• ,
•
,•
•
,•
•
2
, •
•
•
• •, •
•
• ••
•
••
•
•
•
•
- .,•
• •
• -•
••
•• •
•
•
• •
• f-
Design td•
,
,
•
•
m
, ,•
•
•
0
•
:
• ,
,•
••
- -
•
• • • • • • • f-
••
•• • • • • • •
co:
•
•
Cod Ing CD: •
CD: ••
- •,
••
•
-• •
•
•
•
•
•,
_.•
•
•
• • •
• , , •
•
• --
T...tlng
• •
•• 1 •• •• I 2 •• •
• [' I
,• • • •
Final --1
•
SottwarL-l SottwarL-l
Sub"t Subset Version
Flgure 3.5 The IteratiVe software development process: an example with three Itera tions
Sourc:t COCt:btxn, AI'R eit " UN&..e!I"K loocmofH.8I OoYelopment,'· JDnuatY 1993. hup'/lahstnl1 COCkburn USlUnravoUnx r!ncremontal
.0 CHAPTER 3 SOFTWARE PROCESS
pro) t with It- ow n set of actlvitlc>, plan , o bjective , and eva luation Crlterl. , The ' re lea<e" is a
vCrlilo n of <oftware that Is clther u>cd internall y by the project team or externa lly by stakeholders
and cu,t merli. Type of rel eases an be [2J
• A proof of Oil 'p I, or f,lISibi lily ' IIIdy, that Is used to demonstra te or invest igate feasibi lity of a particular aspect
of the software . Thi includes producing software or simulations These are covered in Section 3.2.32
• A prolotyp, that is a workmg verliion of software demo n trating a parti cular capabi lity that is deemed high
risk . Prototypes are covered in Section 3 2 3, t ,
• An "internal" release that is o nl y used by the devel o pment tea m and is used to ensure tha t develo pment is on
track, elicit feedback, and provide a basis fo r further devcio pment and addi tiona l capabili ties.
• An "external" release that IS shipped to customCrli fo r evaluation .
Trea ting each iterati o n as a self·contained project allows clear and manageable objectives to be set, and
reduces overall projec t complexity by breaking it down into small er pieces. By produci ng working software at
the end of each Iteratio n, project progress can mo re easily be mOnito red and planned, and feedback can be
ci ici ted to ensure that its capabi lities arc meeting stakeho lder requireme nts. Typically, early iterations
ge nerate softwa re releases that address aspects of the project with the highest risk . In this way, as the project
progresse the overall proJec t risk level is reduced.
An example o f an iterative and incremental process that is used within parts of Microso ft is reported by
Cusumano and Selby [4]. to wh ic h the y give the name "synch·and·stabilize: Product features are defined at a
high level during the initial phase of a project, with the idea that many Will evolve as product development
proceeds. The product is divided into parts, each co nsisting of a set of features , with small teams aSSigned to
each part. The project is also diVided into parts, o r iteratio ns. each with its own completion milestone. Each
iteration includes several features . Feature teams employ incremental synchronizati o n by combining their
work and stabili zi ng the resulting system o n a daily or weekly basis In this way the evolving software
application is continually kept in a "working" state .
3.2.3 Prototyping, Feasibility Studies, and Proofs of concept
Prototypes and feasibility studies are impo rtant techniques in software development, and are explicitly
included as formal steps, o r phases, in several process models. We discuss them now in more detail.
3.2.3.1 Prototyping
On begi nning a software projec t, we are usuall y faced with factorli that we do no t yet fully underlitand . The
look and feel o f gra phical user interfaces (CU ls) that will sati fy the customer is o ne common example.
T iming is ano ther. For example, suppose that we plan to build a Java application to control an airplane. A
critical issue to pm down very early would be; Will the Java Virtu.1 Machine be fast e noughl Each unknown
factor o r risk is best confronted as oon as possible so that its severity can be assessed and a plan developed to
deal with it. Risk management is dealt with in detail in C hapter 8. ProlotyPi"9 is an important risk management
tec hnique. It is a partial implementation o f the target appl ication useful in identi fyi ng and retiring ri ky p.lrtS
of a project. Prototyping can also be a way to obtain ideas abollt the customer's requirements. An inc,. a,e in
o nc's underlitanding of what is to come can save expensive rework and remove future roadblocks before they
occur. Agile processes contain some of the beneAts of proto typi ng because they deal at all times with worlt,ng
code, However, they do not have all of the beneAts, since prototypes proceed in parallel with the main threod
of the project, whether agile o r not.
SOFlWARE PROCESS MODELS .1
•• , ••••• ·0_ •°
••••••••••••••••••
-.. Prototype Implements 0
....
•
••
risky parts of this ••
•
Prototype activity lirsl
Project
beginning Main project timeline time
Key:G= end of a unit 01 time = Activity wilh risk
Figure 3.6 An illustration of prototyping in the context of a development project
As Figure 3.6 hows , work on a prototype typically progresses in parallel with regular work o n the
project. The risks are prioritized and the prototype is geared towa rd as many of the mosi imporrant ones as
time allows. In the example shown in Figure 3.6, the prototype ignores the large risk near Ihe beginning of the
project because it will be dealt with early in the ordinary course of the project in any c ase.
Large programs, such as billion dollar defense projects, utilize extenSive prototyping to retire risks and
to guide the requirements and design of the real thing . For example , before the U.s. Navy built the Aegis
generation of shipboard systems, it built an entire scaled -back version , complete with software and hardware ,
installed o n a s hip for the purpose. Thi s prototype served to indicate to the Navy what the main problems
might be with the eventual systems . It also helped the Navy to deve lop the requireme nts and design of the
eventual system.
Simple gra phics showing curs usi ng paint · type too ls may be if the prototype's goa l i to
envision the interfaces. The more extensive the prototype, the mo re risks can be retired with it and the more
easily a customer's requirements can be understood . O n the o ther hand, protorypes are themselves software
applications , so extensive prototypes arc expensive . A rou gh assessment as to whether or nOt to build a
prototype is shown in Figure 3.7. Th e table in the figure illustrates, for example , that a re latively inexpensive
prototype with high va lue s hould probably be built. "High value" means that building the protorype helps th e
Calculate payoff
In detail
no
Calculate payoff
In detail
Figure 3.7 A rough calculation of whether developing a prototype would be wo rth It

CHAPTER 3 SOFTWARE PROCESS
t
Payoff from building
prototype ($'s saved
per $1 spent) optlllUll full
expenditure project
on expenditure
prototype
0/0 expenditure 1000/0

0%
on prototype
GUI
only
Figure 3.8 Concept of when It is worthwhile to build a prototype (near the beginning)
cu tomer understand better what kind of product is likely to emerge , helps the e ngi neers understand better
what kind of product shou ld emerge, andlo r retires a development risk .
Many cases fa ll into the "maybe" ca tegory of the table in Figure 3.7, and more detailed analysis is
required to assess the value of protorypi ng. \'l/e are seekin g an optimal level of effort to be spent on a
prototype, as sugge ted by Figure 3 8. As the expe nditure o n a pro torype increases, its usefu lness increases,
but so docs Its drain on the project's budget As a resuil , there is a point at which the payoff is optimal (the
maxImum point for the curve ), and some point beyond which funds are ac tually being squandered (w here the
curve drops be low the horizo ntal axis).
As an exa mple, consider an e -commerce application in which a clothing company wants to sell goods
on line, retain customer pronles, and allow customers to obtai n pictures of themselves wearing clothing from
the ca tolog . A typical calculati o n about prototypes factors the cos t of protoryping features and the potenti.1
for using prototype code in th e nnal product . Figure 3.9 gives nnancial estIma tes fo r prototyping four parts of
the clothing ve ndo r application ,
I . CUI screensho ts
2. T ransaclioll security
3. Complete transaction
4 . Customer tri es o n clothing
For each of the fo ur app licat io n features consi de red fo r the prototype, severa l estimates can made,
the cost of building the feature , the percentage of the feature's implementation that will be reused in the
applicatIOn itself (i.e., not di scarded ), and the "gross benefit" from the effort. The gro benefit here
estimates the gain from prototypin g the feature , excludin g reuse of th e code and excluding all e
For example, as show n in Figure 3.9, we have estimated that if the "Customer trie on clothing" feature
were to be prototypcd, it would save a minimum $20,000 in development co fS Thi estimate I based on
factors suc h as the fo llow ing,
SOFTWARE PROCESS MODELS
Cross IkneRI
<xcluding code
of prolOtyP<'
Estimated reu.., Net P.yoH
code reuscod
cost min max In appliation •
mm mOl(
ProlOlyP<' B D E C D-( . -C)B E- r .-C)B 1
fe.1Ure
J. CUI $10,000 $10,000 $ 80,000 $75 ,000
-
$40,000
50% $5 ,000
, -
soecnshots
..,
I
2 . T ransac- $50,000 $10,000 $300,000 80% $0 $290,000 $145 ,000
lion secu rity
3. Complete $SO,OOO $10,000 $400,000 50%
-- $30,000 $200,000
•
$85 ,000
I
transac,t ion
- - I
4 . C us to mer $120,000 $20,000 $140.000 30% -$64,000 $56,000 - $4 ,000
tries on
clothing
J
Figure 3.9 Payoff calculation example for building a prototype for a clothing application
LI , 'J"" v
• Preventing lime wasted o n proposed requirements that the prototype shows are not reall y needed (e.g .,
mi nimum of th ree un needed requirements out of 100, $300,000 budgeted for the requirements phase =
$9000 saved)
• Im p le me n ti ng a sohware desig n for the "trying o n clot hes" feature, thereby retiring some development risks
(e.g ., esti mate that t h is wi ll save a minimum of one of design time = $2000)
• Rewo rk th at would have resulted fTOm the customer cha nging requirements only after seeing the developed
product (e .g ., rework minimum of three requirements at $3000 each = $9000)
The minimum savings therefore is $9000 + $2000 + $9000 = $20 , 000. Estimating the cost of building
the prototype ca n usc approximation techniques like those described in Chapter 8. An estimation of code
reuse can be performed by identifying the classes of the prototype and determining which are likely to be
usable in th e actua l app lication.
This type of estimation often consists of adding up the estimation of sma ller parrs, which is often more
feasib le . Bracketing each estimate between a minimum and a max-imum can help to make this process a little
easier for the estimator.
Once these estimates are made, the best· and worst ·case scenarios for each feature can be computed.
This is shown in Figure 3.9. The minimum payoff value is obtained by taking the most pessimistic
combination : the highest costs, the lowest g ross benefits , and the lowe t reuse percentages. The maximum
payoff is calculated correspondingly. For example, the maxImum payoff (the most optimistic alternative) for
the ' CUI screenshot" prototype feature is as fo ll ows:
[ma xi mum estimated benefit ] - [ minimum estimated com 1
= $80 , 000 - [(minimum estimated cost) x (percent not reusable )]
= $80 , 000 - [ $10 , 000 x 50% ] = $75,000
U CHAPTER 3 SOFTWARE PROCESS
v is o ne way to deal with the >pread bel ween bcsl and worst ca'c, The result a
[lO'lIIVC payoff for all propo 'cd prolotypc fcalures ex ep l fo r the "tryIn g o n clothes· (eature, whIch prOjects
- $4000, an ovcrall wastc of $4000. The latter negatI ve resu lt IS due to relatively low payoff, high
devciopment cOSt, and low rell<C,
It may be adVIsa ble for the prototy pe to evolve InIO the appl ication ilself, but thi' sho uld be planned for,
no t accidenlal. By their nature, prolotypcs arc rapidly co n,lructed and rarel y documen ted They can be
imp!cmented uSIn g langua ges that get re ult, quickl y but may be unsuitable for th e applicallon itself.
3.2.3.2 Feasibility Studies

It IS unccrtain whether proposed requirement can actually be implemented in practice. In other
words, an entire project is at risk rather Ihan a few spcciRc requ irements. In addition, the project would not be
feasible If Ihe ri k were to be realized . In such cases, Jtasibll/l)' sludirs may be advisable. These are partial
implementations or simulations of the app:ication. For example, conSIder the fea sibility of a Java Internet-
based Encounter video game, and Ids say we suspect performance will be so slow that the game would be of
negligible Interesl 10 an yo ne . A feasibility study could consist of setting up a message · passi ng simulation at
the anticipated rale from a number of players, but with dummy content. Delays could then be estimated by
clocking the simulation .
Simulations can be expensive to create since they arc applications in themselve , sometimes requiring
software engineering artifacts of their own such as a requirements speCification! The author was once involved
with a si mulation of a large system development. The simulati on grew into a large program , which was
needed while engineers developed the rea l system. No one took the requirements for the simulation seriously
because it was not "the real thing ." As a result, even though the development community relied on the
simu lation , the cost of maintaining and using it became astronomical. Making cha nges required tracking
down an employee who "knew the system." Feasibility simulations arc common in large defense programs that
invo lve extensive software and hardware.
3.2.4 Spiral Model
One of the earliest and best known iterative proces es is Barry Boehm's Spiral Model [5). It is called a spiral
because Boehm concept1Jalized development iterating as an outward spIral, as shown in Figure 3. 10.
Boehm's spiral model is a risk· driven process in which iterations have the specified goals shown in
Figure 3. 10. (Recall that risks are potential events or situations that can adversely affect the success of a projcct.)
A project starts at the cenler, as it were , and each cycle of the spiral represents one iteration. The goal of each
cycle is to increase the degree of system definition and implementation , while decreaSing the deglee of risk. Risk
management is built into the process in that very early in each iteration , project risks are identified and analyzed
and a plan for the iteration is created that includes mitigati ng some or all of the risks. As an example, suppose that
at the beginning of a cycle a risk is identified with the screen layout of a portion of the user interface. Software
could be developed to implement pan of the user interface so feedback can be eliCIted from takeholders. Doing
this mitigates risk early in a project and leaves ample time to implement necessary changes. Thu the ov...11
project risk reduces the funher along you arc in the process. After the major risks arc addressed and mitigated,
the project transitions to a waterfall model , as shown in the outer spiral of Figure 3. 10
Each iteration in Boehm's spiral model consists of the follOWing steps,
1. IdentificatIOn of critical objectives and constraints of the product.

2. Evaluation of project and process alternatIves for achievlll8 the objectives.
SOFTWARE PROCESS MODELS 4S
COST
Dele,uutE ntROUCH
EVALUATE
oe,Ec11V£l. 8108
AL i EJdU.l1VEI
A1.. ftRNATIV£S, 1DE>m'Y,
CONsntAJNTI RE SOLVE R.tSKS
RISK ANALYSIS
,
RISK NtAl. Y&lS
RISK ANAL YSIS

", OP EllA naHAl:
COMM'iiriEHT ., PROTOTYPE
PAR Ii flOtt RJSK -' ROTOiTP £,
'., AHAI,., PROTOTY PE.,
,,
TYPE 1
"EVIEW -
ROTS PlAH
Uf'E CYCLE
- _
COHCEPTOF - -- - EKlLATlOHS
MOOELS
-- - -- BEHCHMAR KS
-
OPERA nON
PLAN SOflWARE
"an:
SOFlWARE OETA.D.. ED
DEVELOP·
MEHT PLAN
ReQUIREMENTS
VALIDATION
PRODUCT
OESI CH ... ... ...
DESlCN
" CODE
INTECRATION
OESK;H VALIDAnON '"
"HOttST AND VER'FICAl1OH UNIT "-
PLAN NEXT PLAN
" TEST
PHAS£S INTECRA·'
, nONAHO ,
\ ACCEPT. ' lEST
IMPLEMEH. \ ANtE TEST
TAllON D£VELOP. VER IFY
NEXT LEVEL PRODUCT
Figure 3.10 Boehm's spiral model for software development

Source: Boehm, B. w.o"A Splral MOClel of SOftware Development and Enhancement." IEEE COrnputtf. Vol, 21 , NO 5. May 1988, pp 61-n
3. Ide ntification of risks .

4. Cost·effec tive resolutio n of a sub et of ri sks uSi ng analysis, emulation , benchma rks, models, and
prototypes.
5. Developmen t of projec t deliverables including requ ireme nts, deS ig n. impl ementa tion , a nd testi ng.
6. Pla nni ng for next an d fu ture cycles-the overa ll project p lan is updated , including sc hedul e, cost, and
numbe r of remaini ng iterations.
7. Stakeholder review of iteration de hve rables and their commitme nt' to proceed based o n thei r objective
being mel.
Each traversa l o f the spira l resu lts in in remental deliverable<. Ea rl y Itera tio ns produce eithe r model ,
emulatio ns, be nc hmarks, or pro totypes, a nd later Itera tio ns fo llo w a more waterfa ll· like process and
increme ntall y pro du " more complete versio ns of the softwa re Th is implies that ea rl y Iterations may
exclude srcp 5, and late r ite rat io ns may exclude <tep 4. Altho ugh Figure 3. 10 shows four Itera tion , the proces
doc:. not presc ribe a et numbe r of cycles, The numbe r IS die ta led by the <ize of a projc t, the number of nsks
id"nrified , and the ir rate of retire me nt ,
CHAPTER 3 SOF1WARE PROCESS
Ith ug h Boehm" ori!! inal conception wa, risk. drtven , the piral Model ca n also be driven by a
,eque n c f fun tlonallty sets For example, Iteratlnn I for an o nline video .on · demand appileatlon could be to
Implement the database of video, and it API , Itera tion 2 could be to implement the CU ls, and so on
Key advantases and disadvantages of the spiral model are li sted next.
Advantages of the spiral model

• Risks IIrr ,nm'"g,d ,arly m,d ,hrougholl"'" proem : Ri k, are reduced before they beco me problematic, as they are
considered at all stages. A a re<ult , sta keholders can beller understand and react to risks .
• oj'u'lIrr ro%rs as ,h, proj,e' progrrsscs It is a reali sti c approach to the devciopment of large·scale sof·tware.
Errors and unattractive alternatives arc eliminated early .
• PIn,,.irr9 is b,,," 111'0 iI" procrss : Each cycle in ludes a planning tep to help mon itor and keep a project on track
Disadvantages of the spiral model

• Compli a"d '0 u,,: Risk analysi requires highly speCific experti e. There is inevitably some overlap between
iterations.
• Mtry b, oo"kill jor ,mall projrclS: The complication may not be necessary for smaller projects. It does AOt make
sense if the cost of risk analysis is a major part of the overa ll project cost.
Boehm's spira l model has been very influential in giving ri e to many styles of iterative development
model , including, we believe, the unified process, discussed next.
3.2.5 Unified Process and the Rational Unified Process
The Unified Software Development Process (U SDP) was first described by Jacobson , Boach, and
Rumbaug h in 1999 [6 J and is an outgrowth of earlier methodologies developed by these three
authors-namely, Jacob on's "Objectory methodology ," the "Booch methodology" [7]. and Rumbaugh
et al : s Object Modeling Technrque [8]. The USDP is generically referred to as the U.ifird Proem (UP).
IB M's Rational Software division has developed a detailed refinement to the UP called the Ratio•• l Ulliflrd
Proms (RUP ), which is a commercial product providing a set of process guidelines and tools to help
automate the process.
The UP is a "use·case driven, architecture·centric, iterative and incremental" software process [6J.
Iterations are grouped into fou r "phases," shown on the horizontal axis of Figure 3. 1 I , lllcrpllcm, Elaboralimr.
COlls'ruelioll, and Tra.silloll . The UP's lise of the term "phase" is different from the common usc of the term.
In fact , referring to the figure , the term "discipline" is the same as the common use of · phasc" that we use in
thiS book.
Each UP "phase" consists of one or more iteration , shown across the bottom of Figure 3. 11.
Iterations are relatively short (e.g., threc weeks), the outcome of which is a tested , integrated, and
executable partial ystem . Iteration are built on the work of previous and thus the Anal product
is constructed incrementally . Each iteration cycles through a set of nine diSciplines, whi hare hown on
the vertic.1 axis of Figure 3. 11 : business modeling , requirements, design , implementation and test
activities, plus supporting activities slIch as configuration management , project manag menl , and environ-
ment [9J . Fur examp le , during an iteration some requirements may be cho. en , the desilln enhanced to
support those requirements, and the requirement. implemented and te ted . The hOri zon tal "hump ' next
to each discipline show the relative effort expended on each diScipline during iterations. For example, the
•
Phases
Oil..: lpllne.
II II T.-n. I
Business Modeling •,
,,
Requirements ,
Analysis & Design
Implemenlation
Tesl
Deploymenl
,,
Configuration ,
,,
& Change Mgml ,, :,
Project Management
Environment ..----
I tr_ I EIob" Ebb' 2 Ic.:;' Ic:r I I I T;r
Iterations
Figure 3.11 The unified softwa re development process: its " phases" vs. traditIOnal phases
SOUrce' Adapted from Ambler. S. w.. "A Manager's Intfoductlon to the Rational undlea Process (RUP)." AmbySoft (OeCember 4, 2OOS) , http://Www ambysoh..COOV
do't'mlOaclSlmanagerslntTOToRUP.pdr.
largest requ ire me nts effort is expend ed du ri ng Inception a nd Elaborati o n, and the large ' t Implementation
effort during Constructio n.
Th e fo ll owing arc desc riptio ns oi the work conducted during each of the UP "phase ",
Inception
• Establish feasibility
• Make busi ness case
• Establish product visio n and scope
• Esti mate cost and schedule, includi ng major milestones
• Assess critical risks
• Build o ne o r more p ro totypes
Elabora tion
• Specdy requirements in greater detail
• Create architectural baseline

• Perfonm iterative implementation of core architecture
• Refine rISk as essment and resolve hIghest ri k Items
• DeAne metrics
• ReAne project plan , Including detailed plan for brg lnlllng onstn.1 t lo n lIerallo n<
48 CHAP 1ER 3 SOFlWARE PROCESS
• oml letc remaining reqUirement
• Do Ilera tl vc IInplcmcntJfion of rema ining dC'ign
• 1110roughl), te't Jnd prepare system (or deployment
T r.nsition
• Conduct beta te'ts
• orrect defects
• Create use r m"nuais
• Deliver the system for production
• Train end users, cu tomers and support'
• Conduct lesson learned
Ea h UP phase concludes with a well -defined milestone , where key deciSions are made and specific
goals defined Figure 3. 12 shows these milestones and where they are fulfilled in the process .
The typical amount of time spe nt in each UP phase is shown in Figure 3. 13 ( IOj. However, this varies
depending on the type o( project. For example, projects that contain o nl y mino r enhancements with known
requirement may spend morc time in the Construction phase, while projects for which very little is known
about requirements may spend more time in the Inceptio n and Elaboration UP phases .
The advantages and disadvantages of the unified rocess are summarized below.
Advantages of the unified process
• Mosl asptcls of a prOllel art accolm lrd Jar: The UP is very inc1usivI=, covering most work related to a software
developme nt project such as establishing a business case.
• Tht UP IS malur< , The process has existed for several years and has bee n quite Widely used .
............ 1
I - CGnIIru-..Ibl ,.,...."
Utecycle ObJective. lItecycle In ltle' Operational Product

(LCO) Archlteclure C.""b lllty (IOC ) RelNn
• Scope concurrence (LCA) • Syslem Slability (PR)
• Initial requirements • Requirements • Requirements • Business acceptance
definition stability stability • Opera lions
• Plan concurrence • A,rchltecture stability • Prepared stakeholders acceptance
• Risk acceptance • Risk acceptance • Risk acceptance • Suppon acceptance
• Process acceptance • Cost acceptance • Cost acceptance • Cost and estlmare
• Business case • AeaHslk chance to • ProJect plan acceptance
• Project plan succeed
..J
• Project plan
Figure 3. 12 Objectives for the unified process

S<;IurU. ,.Mpte(l fromAJ'nblef. S W . "A Managor"s Introduction 10 the RDtJoMl unjf'ie<l Process (RUP) ., AmbYSoI1 III. 200$)., httpl/Wwwlml:JVSOft.<OW
dOYmk'leOslmenagerSJntroToRUP octf
SOFlWARE PROCESS MODELS 49
UP Phaa•• - Typical Time DI •• rlbution
Transition Inception
10% 10%
Elaboration
25%
Construclton
55%
Figure 3.13 lYPical time distribution of the rational unified process's "phases"
SOurce: Adapted from Ambler. S. W . "A Manager'Slntrodoctlon [0 the Ra !MJoaI unified Process Ambysoft (DeceOlDef 4, 2005}" nttPJtwww.amoysoft.conv
dovJnkwk!managet"SfFltrOToRUP pdf,
Disadvantages of the unified process

• Tht UP was originally conctivtd oj Jor /nrgr projtclS, This is fine . except that many modem approaches perform
work in small self-contained phases.
• Th, procm may bt ovtrkill Jor smnll Proltc/s , The level of compl ication may not be necessary for smailer project .
Practitioners and vendors of the unified process have modified It to be morc like an agi le proccs ,
discussed next.
3.2.6 Agile Processes
This sectio n Introduces agile processcs. C hapter 4 is dcvotcd entirel y to agi le methods, and agi lity is
referenced and compared throu ghout this book
In 2001 . a group of industry disillusioned with some ommo nly held software engi neeri ng
beltefs and practices. met to discus way to Improve softwa re development. Thei r goa l was to produce a et of
values and princ ipl es to help spced up development and effectively to change . The group ca lled
themselves the Agile Alliance, in cssence to capture th elf goa l or produ Ing a mcthodology that wa< efficient
and adaptable . The resu lt of their work was the MmllJrsloJor Agi/t SoJlu)(I(( D".,lopmtlll [ 111. . 1 0 as the
Ag,k ManiJ,slo , which co ntains the va lues and pron iples they defi ned. All agil, software pro c< is o nc that
and co n/o rm s to the Agile Manifesto. whi ch i, umm arized In Figure . 14 .
Ag"e processes are hrghly Itera tive and incremental They comm only cmpl oy the foll owing:
• Sma ll , close -knit tea mS

•
• Rt:gular, frequent , ustomer reqUlremenh
• A code-centric approach, docu mentation nn an a' · needed bnSl< (e,g . h, gh·level reqlllrcment' statement<
only)
• .. . indi vidual s and interactio ns

o ve r pro e,sC' Jnd t
• . . . wo rkin g software
over o mprchenslvc docum ental ion
• .. , customer collaboration
ove r ontra cl nego tiati on
• . . . respo nding to change

over fo ll o wIn g a plan
Figure 3.14 Main points of the Agile Manifesto
• C u tom er repre entativcs wo rk ing w ithin th e team
• The use of use r sto ries as the ba sis fo r requirements end -to-end accounts of ho w uscrs need :0 acco mpl ish
indivi dua l tasks
• Rerncto ring, a kind o f d isciplined code Improvement explalOed full "" C hapter 24
• Pair programm ing, In whi ch tw o programmers work at a single wo rkstati o n
• Con ti nual un it· ccs ting, and acceptance tests as means o f setting customer ex pectations
Figure 3. 15 shows how the repeated iterati o ns o f an agile process arc executed over time. "Sto ry" is a task
required of th e application as th e eu tomer co nceives it.
Demonstrate
fulfillment Accumulating
of previous functionality J
stories
,,
,, Identity stories for th is iteration
,,
,,
,, • Interact with customer
,,
,,
, • Cement mutual undersranding
,,
,,
,, Implement stori es
,,
,, • Work incrementally
,
,,
, , • Develop test bank In parallel
------
,,
,,
---- --
----
,, Typical
,,
" ," Iteratio'l, _- --
nme; composed of equal iterallon
Figure 3.15 The agUe process

Ke ad><antag $ and di advantage o( ag.le proce es arc ummaflzcd below.
Advantages of an agile process
• n.. praitel alw"Y' ha, d,,"o"'lrabl, ","/r" The end product o( each iteration is working software .
• DnJtlo/ltrS tn.d 10 b, mort •• o/illnl,d, Developers prefer to produce working art.lacts and tend not to like creating
documentation .
• C.'lamm a" abl, 10 /lrollld, b,u" ",/""""",1, b, a"St Ihry cnll s" II" ,"ol"i"g proJllc/,
Disadvantages of an agile process
• Probl""aric.1 for lnrg, appli alia" , Agile methods are more readil y used for smaller projects. There is debale
about their utility for large projects.
• Docum",lallon outpul is qutSliOHabl" Since documentation takes second place, there i a question a. to whether
necessary documentat.on will ever be produced.
3.2.7 Open-source Processes
Open·source software is developed and maintained by people on a volunteer basis. All project artifacts, from
requirements documents through sourCe code, are available 10 anyone . The re are several open -source
software development Web sites on the Internel Ihat aggregale and reference open source projects, including
SourceForge.net and Freshmeat.ne!. As of 2009, SourceForge.nel hosted more than 100,000 projects and had
over 1,000,000 registered users. Hosting sites provide source code reposi tories and utilities for projecl
management, issues discussion , and source control. The case studies in this book dlustratc two well known
open source projects, Eclipse and Open Office .
Open-source projects typically get started when someone develops an applicat.on and posts it to a host
Web site V.rtually anyone ca n propose new requirements, and since the source code is freely ava.lable,
anyone can implement requirements that arc not part of the o(ficial baseline. There is a process by which
proposals and implementations arc elevated in priority and a process for accepting new code and capabdity
into the basehne. If defects arc (ound, they are reponed and others may work on fix ing them . This process is
repeated, and the application grows .n capabdity and $tability . In this wa y, open -source projects arc
developed in an .terative manner. In addition, by exercising aA appltc.tion many times, the open - o urce
communtty affects a huge testi ng process.
Some reasons why an individual o r company makes a project open source arc listed .n F.gure 3. 16 and
3.17, a,n d reasons why they may nOI arc listed in Figure 3. 18. A pnmary reaso n to make a proj" t ope n ,ource
is to leverage a large number of resources that might not otherwi<e be avadable A principal reason to no t
make ,o(tware open source., to keep artifacts h.dden from current and prospc live competitors. o me (e .g.,
Ferguson [ 12] and Kapor) believe that o pen <ource may become the do minanl pro es lor produci ng
wltwarc
An ,nlerestlng art.cle wntten by Alall dillstrates how Ihe ba nk Dresdner Kleim_on Wla sers leln
(DrKW) turned .nternally developed b.ck-c ndJa va integrallon too l, pe nAdap lcr, Into open <ollr C and
how It beneftted (rom the deci,lon . The (ollowinu "an 'XCC rpl (rom thaI Mil Ie
Samolades el.1 [ 1 studied ope n ' Iource d evelopme nl and compared .t w.th dOled s ure ..
>oftw.re Us.ng common me ln s, O code Qualtty was lound roug hl y equal to Ihat 01 _ , nnd 101lnd
to be supe-rior for mainta.nabd.ty . or at wo"t equa l n me o ( Ih el r result, nre Ih wn In F.gurn 3 19
and 3 lO .
open-source users find rewards in collaborative development

11 Alnn Joe"
1/ 1/100S hur i/www adtmas , o m/article .a<px1.d m 10544
Bo nk- pnde thcmselve o n pia ' In!! close to the ve, !. 0 , when Drcsdner KlelOwort W asser'Ste .n's IT
grollp shared the code of O penAdapter, an intemally develo ped tool, w.th the developme nt commun.ty,
.t all ed 3 , em alion. "It was asto nish.ng: reca lls Steve H owe, DrK Ws Sloba l head of o pe n·souree
.nlt iJ lives. "They fo und .t dime"lt to believe a bank was o pen sourcing o meth ing."
pen dapter, a back·end Java integrat. o n 1001 thaI he lps integrate bank a pps w.th little or no
usto m ()rogramnllng, had become "a famolls piece o f so f,tware within DrKW," H o we <ays. "Half of the
decis .on to o pe n . ouree it into the w.der Ananci al communilY was to try to re plicate that enthus iasm:
D rK\'v"s mot.ve fo r releasing the 1001 wa hardl y altru istic. By rcieasIIlg the too l to the wider
Anancial community , the ;nve<lmenl bank ho ped to beRe At fro m Ih c bug Axes and refineme nts other
programm ers in Euro pe and No rth America might make.
However, H owe and o ther o pen· ource experts wam that corpo rat.o ns' code·s haring projects
req uire a nllmber of safeguards 10 pro lec l intellectual pro perty and kee p companies from becoming
un wi u ing v.ctlms o r d istributors of des trllctive code . Some co mpanies bel ieve such risks ourweigh the
potenlla l beneA ts and re ist o pen·source busines app"ca t. o ns. DrK Wand o lher Arms believe careful
ope n.source collabo rario n g.ves them a competitive advantage.
• •
Banking on open source

Dresdner Klci nwo rt W asse rstc," (DrK W ) believes it found development success wirh OpenAdapter by
creat.n g a va nation o n the co llaborative mo del the open·source community pioneered . . . . . "We
open sourced the 1001 within DrKW and told people that if they needed to change OpenAdapter
sligh tly, they were free to do that," Howe says, "A lot of developers decided they co uld make a name for
themselves by cont ri buting to the software ." Today, more than 100 applications in the bank use the
mtegra tion tool.
T o tap simdar expertise outside DrKW, the bank tumed 10 ColiabNet, a commercial project·
develo pme nt plalfo rm from ColiabNet in Brisbane, California. ColiabNet provides a number of
services, incl Yd ing version control tools and discussion fon.ms common in free open ·source clearing.
houses such as SourceFo rge . .. . ColiabNet helped the bank establish a separate legal entity called Ihe
So ftware Conservanc y, which owns Ihe inlt,lIeetual rights to OpenAdapter.
The site publi shes the latest stable build of the sofrware, which anyone can download. Users can
also send in complaints and error reports and suggest bug Axes. So far, DrKW has received input from
devel opers at competing banks and from companies outside the financial industry. Collaboration
co nsists of lechnical subjects, nol information that involves trade secrets or conRdenlial customer data.
Devciopers .nterested in becoming more involved in OpenAdapler's evolution can gain access to
the source code by signing a legal agreemenl that assigns the intellectual property rights of Iheir code
to the Software Conservancy. About 20 developers now hold such status.
ompanies mI x and match opcn·source and proprietary processes according to buslncs nttds
F.gu re 3.2 1 suggests Ihal the pro porti on of o pen·source o r pro pnelary sofrware used. a bll IIle deci ion
ta ke n .n Ihe eonlex l of ex penses and revenues over t.me. An important factor is the expense of tn. lo ring and
• ••
malnta lnill g open SOurce
@ Leveraging large number of resources

© Professional atisfaction
© To enable ta,loring and integratio n
© Academic and research
© To gain extensive testing
© To maintain more stably
Figure 3.16 Some reasons for making a project open source. 1 of 2
© To damage the prospects of a competitor's product

© To gain market knowledge
© To support a core business
© To support services
Figure 3.17 Some reasons for making a project open source, 2 of 2
® Documentation inconsistent or poor

® No guarantee that developers will appear
® No management control
® No control over requirements
® Visibility to competitors
Figure 3.111 Some reasons agamst making a project open source
Project , Total Code No, of Project

I
Mnemonic
Code
Application
Type
Size
(KLOCs) I m('a
Evolution
Path
•
,, Opel.tins 13 OSS project that ga""
I 'Y'km appliatlon I birth to a CSS project
while still evolvi"8 a OSS
Figure 3,19 Maintainability index comparing ass and CSS for the same application, 1 of 2
Scx.vQr I SIbmC'IOS. L Artgclls, and A. Ofltonomoo " open source softwaro dOYOk>prnCOl shol.dd str ive even greater cooe RlIlntAtnotlilaty "
of tn..t Ae M. Vol 47. NO, 10. OCtober 2004, copyrlgh l (" 2004 ASsocIaOOn lor computing MachInery. Inc. Rop'Ii"Ued by pbll'rtsOO
5' CHAPTER 3 SOFTWARE PROCESS
Figure 3.20 Maintaina bility Index comparing OSS and CSS for the same application. 2 of 2
Source SamoLadas. monls. I Stametos. L Angel.S. and A. Qlkonomou. "open source SOftware oevelopment ShOUld strive for even greater code rnamtalnabIJty ..
CommunlCatloos 01 the ACM, VOl 47, NO 10, October 2004, copyright, 2004 , As.soclallon for COmputIng MaChinery. Inc Reprtnted by PeHI''ViM.
Various tools and e nviro nments are available to faci litate open -source development. Figure 3.22 shows a
sche matic diagram of o ne sllc h tool. Collabnet. "Subversion" is an o pen -source version control system used
for many open·source prOjec ts
Key adva ntages and disadvantages of o pen -source processes are summarized below.
Advantages of open source
• TI" work oj mauy moy b, obloiudj"" For projects that mo tivate o thers. work can be o btained from motivated
o utSiders.
• Dn"lopm I",d 10 b, mort moliva l,d. because they choose to work o n it.
• Op",-sollrcr applieoliolls art v'ry w,lI ltSl,d, because they arc continuall y exercised by many and usually have
efficient testin g processes .
Release Sales. service. /

I
I productivity ....
I
Cumulative I
revenue I
I
I
I
Time
I
CumulaUve Open
expense " " :
development : maintenance
I
I
Proprielary
•
I
Fllllr. 3.21 Hybrid open-source/ proprietary processes

• CASE STUDY: STUDENT TEAM GUIDANCE 55
ColiabNet TeamForge: Structure & Features

My Workspace Community & Projects
'-- *"' • ..,..

' '''melt ' _
.. ..
-=..:-
I 'we&. AI'IJI' ICb
Pp'e;rtt
, i I
u...-.p.'I O'. +
t ...- ... " ' . . . . . .
Oft.4., ' .... _ .,.

"" $ : ...
_rapEl.
,:.elk 1M' ,","". do · dl
,.., 'tI 1'Ot-u.

\.Mit" Uk_40
lAc ....... .,.,

... .,.
we"e", ' 1'Oj«U

• • 2,
M. 'I' "tOl'I/to.w
..,tfkU MId t ooh (,,,"",.0-0_
eo
• 'i ,
prw. •
,.,,' ,--
..., 7,="
v, ..., ' 'ns
-- - "
...
•
•
-- •
- ."' __ .0.111 I.
- C La
lOCI .. In •
Figure 3.22 ColiabNet TeamForge: Structure and Features

Source" CollabNet. httpJ/WWWopencoll8bnevproductslsleetc.apabllltles html
Disadvantages of open source
• Tbry art flIlflilablt 10 Oil' m.d all : Th. is part of the barga.n
• DOCunlrntlliio Pl 15 qucstio"ablr: Developers are not cont;islc m In what they produ e
• DtSi9" dorum(1,'alioll '(lids '0 b, poor. It seems that the ope n·source proce"
has espcc .ally great trouble keep.ng
designs and code sy nc h ronized, a nd so dcsign docum e nts are ofte n poor or even no nex.sten t
To ,einfo rce th e concepts o n pro esses de> ribed '" thl< chapter, we continue w.th ca e stud.c
3.3 CASE STUDY: STUDENT TEAM GUIDANCE
T o re",force the many softwa re c ng",cen ng o ncepts and practice 'n trodu cd in th" book , .t's best,f ou are
develop.ng a oftwan: project .n parallel You will ga lll the mo,t If the prOject .s a tea m dfort a< th.s I> ho\,
most real . world ,oft ware project arc exc lItcd At the e nd of most major parl< of the book a 'C lion ( lIch a'
th. s one) enti tl ed Ttam Gu.da" (ca n be found . gu .d .ng 'o u throllg h th e different pha,,,, of o llr group proJe t
Y u will he a,ked to speciO artd act<, and exa mple, WIll bc provIded , howi ng how real and
h i at hetl ca l tea m, 1(0 about develo pIng apD" atlOI1, We WIll o ft'cn USc the Encou nter VIdeo game case: study
a, all exa mple to dlu,trate team gUIdance
1any students look back o n the lf tcam proce,' as a Slgn lncant learnIng adve nture If the team
aVO Id, a few co mm o n i)lli all , th e adve nture an be a most enlI g htenin g and useful experience From
o ur i,ast experie nce , the bes t size for stude nt g roup, IS (our Or five . Any less and the workload fo r each
<tudent is toO great. More !lve doesn't afford all team members the opportu nity to contribute in a
mea nln g(ul way
T,p di tnbutcd th roughe ut th e te-xt arc desig ned to help groups maximize the benefit of group work. In
add,ti o n, cxerelseS at the e nd o ( th e chapter assign peclAc art ifacts to be developed as the prOject progresses
through the o ftware Ide cycle.
T he fo llo,"ing sectIo ns provide gui dance for hnld ing an initial team meetIng , developing a team
com muOIc;ltion plan. and exercisi ng the commun ica tion plan
3.3.1 Team Guidance Initial Team Meeting
T o start 0(1 ,he project , the team shou ld have an inItial meetlO g and make the decision sho wn in Figure 3.23.
Agenda
All meet lOgs should have a wnnen age nda and specific start and end times.
Team Leader
Decide who your Ars t team leader wi ll be (being a tcam leader provides yo u with valuable experience but puts
additional demands o n your time and communication skills) . To distribute the beneAt of team leadership
practice . It can be beneAClal to swa p team leadership about halfway through the projec t. Both team leaders
can be chose n up front , and they ca n back each other up in case of emergency.
i . Set agenda and tIme limits

2. C hoose the team leader.
3. Get everyone's commitmC!nt to required tim e.
o DeAne an expected average number o( hours per week.
o Cather da!es of planned abse nces.
4. Take a reali stic ce nsus of team skills.

o Commo n problem : inflated programming skill claims.
5. Begi n form ing a vision o( the application .

6. DeCIde how team will communicate.
7 Take meeting minutes with concrete .cllon Itcms.
Figure 3.23 initial student team meetlng-generai Issues
•
CASE STUDY: STUDENT TEAM GUIDANCE 57
Time Commitment
A big source of frustratIon in tudent teams is a lack of commItment of some team members. It is far better to
d, cuss commitment at the beginning than to try to fix a problem after the project is under way. To reduce
rc entment that follows when some team members feci they arc contributing much more than others, set
In advance an expected number of hours of commitment per week . This al,o helps to make members work
more efficiently .
Team Skills
For tudent projects there is often a trade ·off between producing an impressive · looking product and learning
new skill . To produce the most impressive product , team members would speciahze along the hnes of their
greatest strengths. This is a typical industrial mode . They may al 0 be tempted to sk ,mp on document.tion In
order to demonstrate more features . T o learn the most, however, team members need to try actiVIties '"ith
which they are inexperienced (e .g., team leade rs hIp). They also need to do thing rig ht. Teams deCIde how
and when to trade off between goals by speCifying when they WIll specia hze and whe n they wi.ll try new role
Instructors try to establi sh evaluation criteria that encourage learning.
Vision
All projects start out with a vision for the software to be developed In industry thIS is tYPI call y initiated by the
marketing department, which develop bUSIness req uirements fo r the product For ,tudent projec ts, the
product vision includes the purpo e of the application , major (u nctionality and operatio ns, and major ",puts
and outputs .
Communication Plan
Decisions need to be made as early as possible as to how the team will handle commUnicatIon . The next
section covers this in detail.
Meeting Minutes
During team mcetings, a member is de ignated to write the meet ing minute The purpose of meeting minute
is twofold. First, al l important decisions or agreements that are reached are recorded , ' 0 they are not forgotten
and can be referred back 10 if necessary . As an example, during the meeting it rna)' be decided that Coogle
Docs will be used for storing all project speciRcation . This decision is recorded in the meeting mInutes. The
second purpose of meeting minutes is 10 record unresolved issues that require follow up action. These arc
referred to as achon itrm s. Each action Item is assigned to one or more team members with a target date for
completion . An example action item might be that Joe is to investigate and recommend a sourCe o ntrollOol
for managing the project's source code, and is to complete his actIon In one week. It is a good Idea to revie,"
open action items at the start of each team meeting.
3,3,2 Team Guidance Communication Plan
When a softwa re prOjec t IS IOltiated in IOdustry, a set of project gUIdelines, 1001s, and commUOlcatlon
procedures IS tYPIcally established 10 ensure that the project IS cxecllled a effiCIently as pOSSIble ThIS hould
also be done for you r f(roup proje t.
Many team problem ari,<." (rom a failure to 01l1tnunicatc fully ThI S problem i nOt Itm ited to ,tudent
prOjcct,_ Real -world teams suffer from 11 as well. Errecl1ve verbal com01uOl ation means maklOl: sure our
thoughts are fully understood and I, steninll 10 what o thers arc ,ay'ng Th, " ntl al (or team' to be
I L"len 10 all Wllh on enl'" tl n
• Don't pre-judl!e
2 "ve all leam member; a turn
• ce Ihe value on every idea,
3 Oon'l make as,u mp" on
• Ask quesl lo n to clarify,
-\ , \'(fhc n in doubl , om munica le
Figure 3.24 Key precepts of communication
uccesshll. The pre epts shown in Figure 3.24 will h e lp you avoid ma ny communication problems. They
sound simple but ca n be hard to follow , especially during times of stress.
C reate pol,ei" for commun ica ting and sharin g informatio n with each other, oncludi ng gUi delines for
g roup ed'li llg and merging of documents, setti ng up a nd agreei ng to meeti ng times, sharing project artifacts,
and so o n
DeCide on procedures lor how yo u will ge nerate docume nts for the projec t. You pro bably ha ve to deal
wi th di ussing the scope and co nte nts of a document , writing initial dra fts, ed iting th e drafts, gettong group
agree me nt on edi ts, merging drafts and producin g the final document
Many teams-i ncludin g some stude nt learn s-a rc widely di stributed geogra phically, and the means of
commun ication becomes especi all y important. Large projects arc often developed by multiple groups at
mul tip le si tes, someti mes in multiple countries. Mergers, acquiSitions , "ollshoring," dis persed speCialists, and
joi nt ve ntures ofte n ro ult on people at multipl e si tes working together on projects.
An increasi ng number 01 products are available to lacilitate group work, including groupware, video
conferencing, and in tant messagi ng . Each com municatio n medium has speCific stren gths. In an y case, well-
run face -to -Iace meetings are very hard to beat. II possible, schedule re gular face -to-face meetings at least
once a week lor a n hour. It is hard to conve ne an unscheduled meetin g but easy to cancel a scheduled
meeting . You can make It a goa l to limit actual meetings to less time. However, il the committed time is
short-say a hall hour -you will It very difficult to make lo nge r meetings because people will build the
sho rt time Iomit in to their schedul es. If you think that your tcam may need to meet additionally, it is advisable
to agree o n when that would be each week. Set aside the time and aim to aVOid a meeting. This provides a
posi tive goal and it avoi ds the problem 01 repeatedl y trying to find a common time when meetings are
nee ded. When you set meeti ng times, specify an end time . Meetings typically expand to fill the allotted time.
You should always have an agenda for your meetings, otherwise your meetings will be less organized and not
as productive as they could be_
E-mail is an essential tool, but can be pro bl ematic due to unpredictable delays. Messages can become
unsynchro nized , damagi ng the threads of d ia logs. This is e pecially senous near the end 01 a project when
communica ti on is (TC:quent and of immediate importance
Use a shared Web Site, wiki , o r chat -ty pe faCility . For example, at the time 01 thiS writin!! , a number of
frec collaboration too ls arc available fTOm Coogle.
Do not merely state that you will use a particular tool such as Microsoh Word lor word processin,_
Specify a version number, and exchange a lew documen ts to be sure everyone c an read and edit them. Don't
c hange versions during the project without ensuring compatibility first ,
Document your decisions in a team (om... ". iratio. Pin. , as outloned in Figure 3.25.
SUMMARY 59
1 Meetings : TN'" ' vIII meet each Monday fro m .. to .. In .
tllHal do Plot rtpln ( t nltttlt19 wtlh rt'"ott II1t(/II'9s u,lIns (('molt mttlh1gs arc
de.lr/Y .JJtt"hve.
2. Meeting alternative : Team members should keep Fndays open from .. to .. In case an additional
meetlng is required
Standards: Word processor, pread heet, compi ler, • •
4 E-mail : require acknowledgement]

nvtol (-milll is poor jar j"lflISiv( collaboratioll
5. Collaboration: Tools for group collaboration and discussion _

e .g. Yahoo Croups , Wiki too l, Coogle tools, ...
6. Other tools: Microsoft Project (scheduling), Croup calendar, • • •
Figure 3.25 Communication planning-forms of communication
3.3.3 Team Guidance Test Communication Plan
It is important to test the methods speciRed in you r Com munica ti on Plan so you can make necessary
adjustments as early as possible in the project. This will avoid scra mbling for alternatives a the project
workload increases .
Search the Web for the latest information o n a topic determined by the instnlctor. Note at least four of
Its baSIC goals and at least five of the techniques it uses. Have everyone in the group contribute ome
information. Create a document containing your group's results, and practice how you 'vIII utd ize your
procedures for group editing and reviews. How 'viII yo u o rganize thi random activity] H ow can you obtai n a
useful result instead of a conglomerallon of unco nnected text
3.4 SUMMARY
A software project progresses through a of activities, staning .t Its conccl>ti on .nd conllmllng all the
way through its release Project arc orga nized into phase , each with a set of aC!IVllies conducted during that
phase. A soflw.rt process preSCribes the interrelationship among the ph.,es by expressing their order and
frequency, as well as defining the deliverable of the proJect. SpeC ific sofrwdre processes arc called ,of'"'ar,
prow, ,"odd, or 11ft <yel, modd"
Most software process models prescribc a slmd ar se t of phaSe< and actlvitle< The difference
models I< the order and frequency of the phases. The ph. es in lude planning , reqUirements anal SIS, deSign ,
Implementation , te ling , and maintenance
The walery.1I procc.s is one of the oldest and best known so ftw.re proces. Prole ts fo ll oWII1!; the
waterfall process progress sequentially through a senes of pho<es. \'(Iork tr.n ition< to a phase when work o n
the prevIous ph ase IS compl cted
/1".,,", and ,"cr""<tII"/ processes are c hara ten zed by repcatl'd exe ulion of the waterfall phosl's . "" ho le
Or ,n part, re>u ltlng in a reflncl11e nt of the reqUirement , de"gn , o"d Implementation . AI the on IU 51O " 01 an
Iteration, operational ode IS produLcd that uppom a of the nnal pr du t' lun 1I0 nolit)' Project
artifacts such plans, atlon<, and ode evol ve durinl! ca h and owr the Id e 01 tlw pr Ie t
Examples of lterallve Pfl)CC" s melude the <p lral model , the unlhed pro C" , and agi le pro C"t·<
pro e"e< arc 1"8 hl itl'raII ve , and elllphas,ze ode Ih roughout, as wel l as frequent
,ntcra tinn.; with th e U\lOIlU.:r.
A PllllolyPt ' a partia l lI11pl emcnlallon of the largel app licali o n u clu l ,n ,dent"'}'ing and re llring rISky
part> of a projc 1. 11 can <o mel,m es be a way 10 ob lOln ,dea; aboullhe customer's reqUlremenls. An ,ncrease ,n
understandi ng whal. 10 come ca n ,ave expon ivc rework and rem ove htlure roa dbl o ks before they OCcur
lany tlcra ll c I>roce , lIIodel. inco rpo rale prolo lypes ,n o ne or more o f Ihelr Iterallons
omC lImes, it " unclear whe lh er certa,n requiremenls ca n be ,mplemenled In pract,ce, plac,ng the
enl.re prOject at " k. In su h cases, !((I"bd, ly " lIdits may hc advisable, wh.c h are partIal Im plementations or
si mula lions of the app hCJ lio n.
In o pen· ource proces <s, so ftw are is developed and malnlained by peo ple o n a volunteer basis. Sou rce
code 's open 10 all , and th ere Is a process for virtua lly anyolle to susgest and Impl eme nt e nhancements and
. ubmil and repalfddccts This process is re pea ted and the app hcat .o n grows in ca pabili ty and stabIli ty. In thIs
wa , ope n· source proje ts are developed ,n an iterat,ve manner. In addit,o n, by exercising an application
many tim es, th e ope n-course community rtlnctlons as a huge test ing process.
3.S EXERCISES
1. During whi ch process phaseCs) would each of the fo ll owi ng aClivities occur;>
a. Creating a project schedule
b. De leml irlin g Ihe need for a bar code reader
c. Req uestin g the additio n o f a fi le backup ca pability
d. Performi ng a feasibility ana lysis
e. Documenting the software interface to an SQL database
f. Acceptance of the softwa re applicallon by the customer
2. G ive an example of a software project that wou ld beneAt much mo re hom usi ng the waterfall
process than fro m using most of the alternative processes. Explain your reasoning.
3. Describe the d ifference between iftr.,i., and incrt",,,,,., development. Describe the ways in which
they arc related.
4. Give an example of a software project that would beneht mo re fro m usi ng an iterative and
.ncremenlal process than fro m using most of the alternati ve processes. Explain your reasoning.
5. a In your own words, explain hmv the spiral model utilizes risk anal ysis and risk mitigation.
b. Exp lain why Ihe o uter spiral of the spiral mode l utilizes Ihe waterfall process , and how the
spiral model miligates the inherent disadvantages of the waterfall process.
6. Give an example of a software project that would beneR t much mo re from usi ng the spiral process
than from usi ng most of the alternalive processes. \'(frite a paragraph explain ing yo ur answer.
7. How do the phases of the unified proce .. (UP) differ from the pha es usually deRned for oftware
processes'
8. Describe Ihe pros and cons of each va lue listed in the Agi le Manife<to (sec F,gure 3 14).
EXERCISES 61
Communication
For the following exercises, consider as a group how you will perform them , check the hints below,
then carry out the assignments .
TI . Decide who your team leader{s) will be . Note that being team leader provides you with
practice that may be hard to get otherwise.
T2 . Decide how your team will communicate, specify your communication tools and methods,
and test your communication methods. Be specific: YOll may change the specifks later.
T3 . Search the Web for the latest mfomlation on a topic determined by the instructor (e .g., the
TSP). Note at least four of its basic goals and at least five of the techniques it uses. Post the
references to the course forum or \'(feb site If there is one. and annotate your posting with the name
of your group . State individual or gTOUp opi nio n of the topic or issue.
Your team respo nse should be 4-7 pages long .
Hints for Team Exercises

TI hints: To distribute the beneRts of team leadership practice, It can be beneficial to swap team
leadership about halfway through the semester. Both team leaders ca n be chosen up fTont , and they
can back each other up in case of emergency. Such backing up is a good practice in any case, because
the probability of a team leader having to quit a project o r a class can be high . ote that the second
half of a project typically requires the team leader to make decisions more quickly than the first half
T2 hints : Examples are telepho ne, meetings, e-mail , forums , chat facilities , and Web sites.
I. Schedule regular face-to-face meetings at least once a week, if possible It is hard to convene an
unscheduled meeting but easy to cancel a scheduled o ne .
2. E-mail is an essential tool. but can be problematiC due to unpredictable delay . Messages can
become unsynchronized, damaging the threads (subjects) of dialog . This is espeCially senous
near the end of a proiect when communication is frequent and of immediate Importance .
3. Use a shared Web si te or chat.type facility . Free services are available at hnp://groups.yahoo.
com!, for example .
4. Do not merely state, 'We will use Superword for word processing ." Specify a version number,
and exchange a few messages to be sure. Don't c hange versions dunng the project without
ensuring compatibility Rrst.
5 Try out all the standards and methods you have chosen .
Throughout this program of study, validate your plans and inte"tions with practical tests
whenever possible. Try to u e at two independent tests. In genera l, assume that your project
Will be much more demanding In the future than it is at the beginning .
T3 hints: Usc th is activity to strc your communication system . Forexample , you may want to set
up a Web site to which team members are to add new TSP mformation How will you orllaniu thi
random actlvlty7 How can you obtain a useful rc. ult In tcad of a conglomeration of unconne ted
text7
BIBLIOGRAPHY
I. Ro "O c, \: " the DC'v(lopmcnt o r Large Sohw3 rc YS It'lm o ncc:pts 3nd Tt'chnlquc'l: IEEE WESCON "70 , Aul\Kt
1970. pp 1- 9
2 BluMer, Kurt , .lnd Spence', I • 2007, hffolljW So/tuum DwdopMmf P,o), 's:' Peirson EduC1tlon, Inc.
kbum. Alistair · Unr.wdlllM Develo pment : )Jnuolry 1993 cockburn uYUnnvtilng+l ncre-mentll
.. devci opment November .s, 2()()<l j
... uSUnlano, MichJd, Olnd R. W dby "How Microsoft Builds SOhWolrt' ( o",,"w,,.cotiopu: oj fJH ACM, Vol. 40, No 6( 1997), pp.53-6'
s. Boc:hm, B W "A Splroll M.1dd of Sohwan: Dcvc/opment and EnhJncemc:nl: IEfE (o",,,,,'n, Vol 21 . No. S (MayI988). pp 61-n
6 Jacobson. IV3r, J Rumbaugh , olnd C . Hooc h The lI" iflrJ SOfhj'fJrr Dmt/opl'flntl PHKnJ , Add,son . Weslc:y, 1999.
7. Sooch. CrJ dy Ob)trl-Onnttcd (fltil [)cs.glf wit" AptJlir(,lIons,
8 Rumhaugh , James, M 8131111, W !'remcrlanl, F Eddy, and W , Lorenson , "Objut.OrindllJ Mode/mg m,J DtS'9"," Prenttce: Hall, 1990
9. LumJn, rol l S , Appl)'1"9 UMl Qlta Pallrm, Art ["'rodllC'l/olt to OU)tC'I-OrimItJ Aml/yr,s oJmI ON'9rt IInJ [krait"" Dt1J(U,,,rMtl," Prenlice t-UII ,
M
lOOS.
10 Ambkr, S. W " "A ,\iafttJ9rr, , .. ,roJIlCllo" 10 Ji)( Ral/oftal UK'fled Procm (RUPJ .. Ambyso (t (Dtccmber 4,2005) hnp:!/www.Jmbysoh.com/
unl flcdproccs ruplntrodu tio n.html (accessed November S, 2009 ].
1I Beck, Kent , Mike Beedle , Ane VOln Bcnnekum , OInd AlistaIr Cockbum , (or Agile Sohw;u't' Development,· feb 2001 . http://
org/ [accessed November S, 2009J
12 Ferguson, Charles, · Ho..... Lmux Cou ld Overthrow Microsoft ," T«lm ology Rrou1D Uun(2005 ). httpllwww.tcchnologyrevkw.coml
computmgl l4504! [acccssed November 5, 2009).
13 Samol .. das, loa nnls, I Stamdos, L Angel.s, ilnd A. O.konomou, "Open sourcc software devdopmcnl shou ld strive for t'Vcn grU(Cf
code mainliltnilbiluy: Co,"mUI'"cnlrolfs of tbe ACM, Vol. 47, No. 10, October 2004
Agile Software Processes
• How did agile melhods come about?

Planning
..... • What are the pnnclples 01 agility?
• How are agile processes carried out?
The Software • Can agile processes be combined

Development with non-agile ones?
Ufecycle
Design
Figure 4.1 The context and learning goals for this chapter
In the t9905, agile softwa re development came In lO being as an a ltern ",ve to the existing classl al
approa hes to ofrware engineering that were percelvt·d to be too · pro ess·heavy · TI,e e claSSical
approaches emphasize the need to plan projects In advJncc, cxpn:s, requirements In writing, provide:
"""tten deSign sa ti sfYi ng the reqUIrement , wrlle odc ba ed o n these de\lgn' an,fying the written
requiremcnts, and fina ll y 10 test the results A we ulstll<>ed in hapt er I and 3. how<'Vcr, Illany prOjects
(ollowlng the e steps exh ibit major prol lem, A primary rea,on I< that >takeholders do not uallv kn w at the
mCeptlon of a proJeu entirely ,,,hat they reqUire Ag"e process!:, addre" thl< shan oOllng Thl' hapter
w hat" meant by as"e dewlopment, des nbe< ,evera l peclfic softwa re proce"e. that adhere to allile
pnnclples and arc thus ons ldered .B"eprocc"e" and d"Lu ses h ow all " e and non -ag ile pr c'>es can be
coOlhtncd
6. CHAPTER 4 AGILE SOFlWARE PROCESSES
4.1 AGILE HISTORY AND THE AGILE MANIFESTO
gro up of II1du, try ex perl, me t "' 200 I to d l cuss way' o f Improv in g on the the n wrrent <onwa re
",St.
d e c lo pm e nt pro that th ey o mplnined were d o umenta tion dri ve n a nd pro css heavy. Their goal was
to produce a ,el of va lues and pnn ipks to help speed up development and effect ively respond to
ailing the mselves the AgIle All,ance , the g ro up's goa l was, In esse n c, to pro duce a d evelopme nt framework
:hal was dAcie nt and adaptable . Durin g th e 1990 , variou, Iterative so ftwa re mNhodologies were begi nn ing
to s"i n popularity. o mc we re used as the baSIS for the agi le fram ework These methodologies had dJffercnt
combinatio ns of o ld and new Ideas, but all shared th e fo ll owIn g c haracte ri sti c [ I)
• Clo<e co lla boration betwee n prog ramm ers and busi ness experts
• Face · to·l-ace communi catio n <as op po ed to d oc um e ntatio n)
• Frequent d e li very of worki ng softwa re
• Self·orga nizing tea ms
• Metho ds to c raft the code and the team so that th e Inevitable require ments churn was not a crisis
As a resu lt of t hei r mccting , th e Agile Alliance pro duced th e Agi le Manifesto [ I ) to ca pture
th o ug hts and id eas , and it is summari zed in Figure 4.2.
N o te that the Agi le Man ifesto IS not anti -metho do logy. Instead, its auth ors inte nded to resto re
For example , they embrace d esig n mo deling as a mea ns to belter understand ho w the software will be built,
but not prod uci ng dia gra ms that arc Rled away and seldom used. They embrace documentation, but not
hundre ds of pages th at cann o t practically be maintained and updated to reflec t c han ge [2J.
The fo ur PO Ints of the Agi le Manifesto form th e basIS of agile developme nt . The Rrst part of each
stateme nt speCifies a preference. The second part speCifies so meth ing that, alth o ugh important, is of lower
priority . Each of the four poi nts is described next .
Individuals and Interactions (over processes and tools)

For decades, manage ment practice has emphasized the hi g h value of commun icat io ns. Agile
emphasize the Sig nifica nce of hi g hl y ski lled ind ividuals and the enhanced expertise that emerges from
'"teractions among them . Altho ug h processes and tools are Important, skilled people should be allowed to
We are uncovering better ways of develop ing software by do ing it and helping others do it Through this
work we have come to value:
1. Individuals and interactions over and tools
2. Working software over documentation
3. Customer collabor.ation over co ntrac t negotiation

4 . Responding to change over following a plan
That is, while there is value in the items on the right, we value the o n the left
FIlii" 4.2 The AgIle Manifesto

AGILE PRINCIPLES 65
adapt the proce5 and modify the tools as appropriate to ge t their job done as efficiently as possible. As
suggested III [ 3J. agile ",ethods offer generative values rather than prescriptive rules, a nllnimum set of values.
observed in all IllIation , that generate appropriate practices tor specia l situations . Individuals and teams usc
these rulC'S when problems ari c a a basis for ge nerating soluti o ns that are appropria·te for the projecl.
ereali iry IS emphasized as a major means for problem solving. Thi s is in contrast to more rigid sofrware
proce e , whi h pre cribe a set of predetermined rules and force teams to adapt themselves to these rules.
Agile practices uggest that the laner approach is not effective and actually adds to the risk of project failure .
working Software (over comprehensive documentation)

orking software is considered the be t indicator of project progress and whether goals are being mel.
Teams can produce pages of documentation and supposedly be on schedule , but these are really promises of
what they expect to produce . Agile practices emphasize producing working code as early as possib le . As a
project progresses , sofrware functionality is added in smalllncremenlS such that the softwa re base continues
to function as an operatio nal system. In this way team members and stakeholders always know how rhe real
system is functioning .
Although Significant, working software is of greatly dimin ished value with out reaso nable documenta ·
tion. Agile practices emphasize that project teams determine for themselves the level of documentation that is
absolutely essential.
Customer Collaboration (over contract negotiation)

This statement emphasizes the fact that development team arc in business to proVide value to cuSlOmers.
Keeping as close as possible to your customer is a long-established maxi m of good business practice . Many
programmers are disconnected from the cuSlOmer by organizational layers and intermediaries, It is highly
desirable to remove this barrier. All stakeholders, including customers, should work logether and be on the same
team. Their different experiences and expertise should be merged with goodwililhat allows the team to change
direction quickly as needed to keep projects on track and produce whal i needed. Contrac ts and project charters
with customers are necessary, but in o rder to adapt to inevitable change, collabo ration is also nece sary [3].
Responding to Change (over following a plan)

Producing a project plan forces ream members to think through a project and develop contingencies .
However, change is inevirable, and agile practit ioners believe that change should not only be planned for but
also embraced_ Very good project mana gers plan to respond to change, and rhis is a reqUirement for teams
operatlllg at the most effecti ve leve ls, as you will see when we discuss rhe hi ghest capabi lity levels of the
CMM I in Section III of this book. As changes to the plan occur, the team h ould not tay focu 'ed on the
outdated plan but deal instead with the changes by ad.ptlng the plan as necessary [3). Agile practices rely on
short iterations of one ro six weeks to prOVide timel y project feedback and IIl fo rmati o n necessary to as ess
project progress and respond as necessary.
4.2 AGILE PRINCIPLES
In addItion to the va lues dcscnbed in Figure 4.2, Ihe aUlhors of th e Agile Mani!e to oU llined a se t of
prlllcipies that ,upport the manifesto. The,,, arc quoted from [ I) (bold added ).
• "Our nIghest priority .. to sa tisfy the custo mer through early and con tlnuo u. deltvcry f valuable suftware
• Welcome changin g requi remen ts, even lale In development. Ajlilc pro esses harness hange for the
OJstomer's competitive
66 CHAPTER 4 AGILE SOFTWARE PROCESSES
• working software frequently , from a couple of weeks to a o uple o f mo nth •. with a prefer nce to
tI,. shaner timesca le.
• BU5mess and developer must work together dally throughout the prOject
• Build projects around motivated ind ivid uals. C,VC them the e nvironment and support they need, and trust
them to get the job done.
• The most effiCient and effective method of conveying Infonnation to and With," a development team IS
face-to-face conversation .
• Working software i the primary measure of progress.
• Agile process. promote sustainable developme nt. The sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
• Continuous attemion to technical excellence and good design enhances agi li ty .
• Simplicity-the art oJ maXi mizing the amount of work not do ne-i s essential.
• The best architectures, requirements, and designs e merge from self-organizi ng teams.
• At regular interva ls, the team reflects o n how to become more effective , then tunes and adjusts its behavior
accordingly."
Many of these principles are implemented in prac tice by the agile methods de cribed in the next
section .
4.3 AGilE METHODS
This section describes some of the methods by which many agile processes practice the principles in the
Agile Manifesto.
Figure 4.3 shows the manner in wh ich agi le methods implement the Agi le Manifesto, a. fo ll ows. Agile
processes common ly employ small . close-knit teams; periodic customer requirements meetings; a code-
ce ntric approach ; documentation on an as-needed basis (e.g ., high-level requirements statements o nl y);
customer representatives working withi n the rcam ; rcfactoring; pair programming; continual unit-testi ng" and
acceptance tests as a means of setting customer expectations .
We next e laborate on the topics not already explai ned above.
Pa" programming is a fo nn of continua l inspection by one team member of the work of a teammate.
Typically, while one programs, the other inspects and devises tests. These roles are reversed for periods 0
time that the pair detennines.
Documenling 0" an a5-ntcd,d basi, usually ,"valves writing some high -level reqUirements but not detailed
requireme nts. These arc freque ntl y collected in the fonn of '"'' 5/0ries . A user story is a Slgn ltkant task that the
user wants to accomplish wit h the applicatio n. According to Cohn (4), every II er story consists of the
follOWing;
• A written description
• Conversations with the customer that establish a mutual understanding of It purpo e and content
• T eslS intendcd to validatc that the user story has been implemented
- - --
1. Individuals and interactions over and
tools
2. Working software over comprehensive

documentation
MANIFESTO _
3. Customer collaboration over contract
negotiation
RESPONSES :
4. Respond ing to change over fOllowing
a plan
a. Small, close-knit team of peers y y
b. Periodic customer requirements meetings y y y
c. Code-centric y y
d. High-level requirements statements only y y
e. Document as needed y y
f. Customer reps work within team y y

g. Refactor y
h. Pair programming and no-owner code y
i. Unit-test-intensive; Acceptance-test-driven y y
j. Automate testing y y
Figure 4.3 ways to address the principles of the Agile Manifesto
Examples of user sto ries fo r a video sto re applica ti o n are as fo ll o ws,
• "The use r ca n search for all D VDs by a opve n d irecto r."
• 'The user can establi sh a n acco unt tha t re me mbe rs all tra n ac tions wit h the c ustomer ·
• 'The u. e r can view all ava ilable in fo rmatio n o n any DVD "
o"lI"unl i"llractlo" a nd contac t With the cu to me r is ac hi eved In twa wa ys. Fi rs t, the wo rk periods ( 1- 6
wee ks, usually ) in whic h the each batc h o f reqUire me n t arc to be flll Rlled are speciRed With a tea m that
Involves the custo me r ('co nd, a cUSto me r re presenta tive I< e ncouraged to be part of the tea m.
TI,e e mphaS IS o n worki ng soflwart is rea lized by mea ns o f coding versio n o f the applica tio n a nd sho '"lng
them to the custo me r. These arc usually clo el y tied to corres po nding test< Indeed , Icsl-dnvOi drvclop",mt an
allile a pproach , actua lly has devel o pers wfIte test< even before devel opi ng the code
Obtain hlgh-tevel - Oblaln requirements for

requirements next perlod's' segment
Relactor to
Relector to accommodate
clean up new
requ irements
Modify code and test code base

to handle additional requirements
• Typically 1-6 weeks
Figure 4.4 A typical agile development iteration
Rcfa 1011"9 is a process of altering the fonm of a code base while retainin g the same functionality . The
usual goa l of a rdacto rln g is to make the design amenable to the addition of functionality , thereby satisfying
the agile deSIre 10 respo nd "'CillO c hange. The very fact that the discipline of rcfactoring has been developed
IS a majo r f.clO r mak ing agile methods possible This book covers rdacto ring in Chapt.er 24 . Although
refactorin g is discussed latcr in the book , much of it will be useful before then and can be referred to
throughout the book.
Agile metho d. employ the developmen.t cycle shown in Figure 4 .4 . T y picall y , the requirements
are expressed in terms of lIser stories . Past experience in the project allows the team to assess its
_docily , an assessment of the relati ve diCficulty of tories and the rate at which it is able to implement
them
The schedule effects of agile me thods can be seen in Fib>tJre 4.5 . Planning is attenuated because there is
less to plan . Requirements analysis, design, and testing are often conRned to high levels. The emphasis is
mostly code ce ntered .
4.4 AGILE PROCESSES
"Agi le developmen t" isn't itself a spe iRe process or methodology Instead , it refer.; to any software proc('Ss
that captures and embraces the fundamental va lues and principles espoused in the Agile Ma.nifesto. The
following sectio ns illustrate and describe three agile processes as repre cntative examples.
• Extreme programming (XP)
• C rystal
• Serum
AGILE PROCESSES 69
•
Time line
Plan lor agile methods
C,"'X <,-. " . ........... ........ ...... t</. ....

. "'6_ . ___
••, • • , . ' ' V " ' '
-"--'--"."
. " .
.'
_ -_.
-t. _ . "" .
' ••
Implement in agile fashion
System tests not covered by agile method:
Figure 4.5 The agile schedule
4.4.1 Extreme Programming
In 1996, Kent Beck and co lleagues bega n a project at DaimlerC hrysler [51 using an approach to software
development that appeared to make marters muc h simpler and more efficie nt. The methodology he
developed and used became know n as Exl""" Prograrnrni>lg (XP) [6].
Beck [6] cites fo ur "values" gUidi ng extreme programmi ng, communication , sImplicity, feedback , and
courage. These are summarized in Fig,,"'s 4 .6 and 4 ,7. XP programmers communi cate continuall y with their
customers and fc ll ow programmers. TI,ey keep their design simple and clean , They obta in feedback by
testing their software, starting on day o ne. They deliver parts of the system to the customers as early as
possible and Impleme nt changes as suggested , With this foundation , XP programmers are able to
·courageously· respo nd to c hangi ng requi rements and techno logy [5].
XP was created to deal effectively with projects in wh ich requirements c han ge . In fact , XP expects
requirements to be modified and added , O n man y projects, custo mers start with o nl y a vague idea of what
they want. As a prOject progTesses and a customer sees working software , specifks of what they want become
progressively firm .
I. Communication
• Customer on site
• Pair programm Ing
• CodIn g st.1ndards
2, Simplicity
• M e taphor: e ntity names drawn from COmm o n met"phor

• S,mplest d eSIg n (or c urrent reqUIrements
• R.efac tOnng
Figure 4.6 The "values" of extreme programming, 1 of 2

SOuru- 8.:;)'... YMYt, •. PtOSfMlming Eltplak'wl EmbrAce Chang.," '000
10 CHAPTER 4 AGILE SOFlWARE PROCESSES
I Feedback alwa y, a u!!hl
• onlJnual
• Ol1tll1UOU' 'nlegra tl o n (al leasl dad y )
• mall ",lease (small e' l usdul feature ,el )
2 Courage
• Planning and esti matio n with use r stones

• a llectlve code owner-hip
• ustain ablc pace
Figure 4.1 The "values" of extreme programming, 2 of 2

SOUtre. Beck.. Kenl "Extreme Programming EkJ)Ialned' Embrar.e Chango," Addlson·Wesley, 2000
XP projecls are divided inlO ilerations lasting from one to three weeks . Each iteratio n
soft ware that is fu lly tesled . Al the beginning of each , a planning mecli ng is held to determine the
of the iteration . Th is is "just · in . time" planning, and it facilitates th e mcorpora ti o n of changing
requirement s.
As code is devel o ped , XP rel ies o n continual integrati o n ralhe r that assembling large,
developed mo dules. In the same spint , releases are modest in added ca pability . The idea is to bite off a small
amount of new ca pability, integrate and lesl it thoroughl y, and the n re peal Ihe process.
EXITeme prog ramming recog nizes Ihe all . loo . frequent breakdown in c usto me r devel o per reiation-
sh ips, eac h pa rry de velops a scpa ralc concep l of what's need ed and also h ow much features
will cost to devel o p. Th e resull of Ihis mi smatc h is , all too often , a mad dash for deadlines, including
lo ng workin g ho urs and a n un suslainable pace. In respon se, eXlreme progTamming a modus
vive ndi thaI's susta mable in the lo ng term . In addition , it requires every developer to acknowledge up
front Ihat all code is everyo ne's commo n property , to be worked on a the project's needs require . In
o lhe r words, no code "belo ngs" to a prog rammer. This is in keeping wilh engineering practice , where a
bridge blueprint , fo r exampl e, is the product of an o rga nizalio n and nOI the personal property of
o ne desig ner.
XP is unique in usin g twelve practices Ihat dicta le how programmers should carry out their daily jobs.
These twel ve practices arc summarized next (7).
I. Planning Process . Req uirements, usuall y in Ihe form of user stories, are deR ned by cuslomers and given a
relative priority based o n cost esti mates provided by the XP team . Slories arc assigned to reieases, and Ihe
team breaks each slory into a set of tasks to imp le ment. \Y/e described user stories in Section 4.3.
2. Small Releases. A si mple system is buill and pUl inlo produclion early Ihat includes a minimal set or
useful reatures. The syslem is updated frequentl y and incrementally thro ughout the deveiopmenl
process.
3. Test-Driven Development. Un il tests are wrinen 10 leSI funclionality, before the code to implement
thaI functionalllY is aClually wrilten .
4 Refactorlng . Code is regularly modi fie d or rew ritte n 10 keep It simple and mainlainable
Incorporated as soo n as de Acie ncies are idenlified. We ,"troduced rdoc toring in 4.3 and cover It
in delail in C hapter 24
5. Design Simplicity. Desig ns are created 10 solve the known reqUirements, not 10 solve future
ments. If necessary, code will refa lored to implemenl fulure dcsisn needs.
AGILE PROCESSES 71
6. Pair Programming . This was described in Section 4. 3
7. Collective Code Ownership. All the code for the system is owned by the entire team. Programmers can
mod,fy any pan of the ystem necessary to complete a feature they're working o n. Th ey ca n also improve
an part of the system .
S. Coding Standard. For a team to effectively hare ownership of all the code, a common cod,ng standard
must be fo llowed. 11,is e nsures that no matter who writes a piece of code, it will be easi ly understood by
the entire team .
9. Continuous Integration . Code is checked into the system as soon as it's comple ted and tested. Thi s can
b" as freq uent as severa l tim e per da y. In this way the system is as close to production quality as possi ble.
10. On-Site Customer. A customer re prese ntative is available full · tim e to determine requirements, sct
priorities , and answer questions as the programmers have the m. The effect of being there is that
commun ication improves, with less hard -copy docume ntati on-ofte n o ne of the most expensive parts of
a software project.
I I . Sustainable Pace. XP tea ms are more productive and make fewer mi stakes if they're not burned out and
tired. Their aim is not to work excessive overtime, and to keep themse lves fresh , healthy, and effective.
12. Metaphor. XP teams share a common visio n of the system by deR ning and using a commo n system of
describing the art ifacts in the project.
4.4.2 Serum
Serum is an agile methodo logy deve lo ped in the early 1990s . It is named after the part of a rugby ga me that , in
U.s. foot ball terms, is a cross between the kickoff and a quarterback snap . As deRned by the Merriam Webster
dictionary, a scrum is "a rugby play in which th e fo".ards of each si de come together in a tight fo rmat ion and
struggle to gai n possessio n of th e ball using thei r fect when it is tossed in among them ." In o ther words, scrum
is a process that follows "o rganized c haos." It is based o n the no tio n that the developme nt process is
unpredic table and complicated, and can only be deRncd by a loose set of activities . Within this framework ,
the development team is empowered to de Rne and execute the necessary tasks to succes fully develop
software.
The flow of a ty pica l sc rum project is show n in Figure 4.8.
A project is broken ,ntO teams, or scn,ms, of no more than 6-9 members. Each team focuses o n a e lf-
contai ned area of work . A scrum master is appoi nted and is responsi ble for conducti ng the daily se rum
meeti ngs, mea uring progress, mak ong decisions, and clearing ob tacle that get in the way of team progress.
The daily scru m meetings shou ld last no more than 15 minutes . During the mee ting the Scrum master,
allowed to ask team memb"r< o nly three questio ns [8]:
I. What ,tem< have been comp leted since the last serum meeting:
2. What issue< have been di covered that need to be reso lved)
3. What new assignments make sense for the team to complete untol the nex t scrum mee ting)
At the begonning of a projec l, a lost of cu<tomcr wantS and needs ,s created , wh. h IS referred to J the
"backlog," The" rum methodology proceeds by mea ns of aili le 30·day y les ca ll ed ' sprints.' En h spn nt
takes on a t of featu res from (he back log (or deve lop mcn!. Whole in a <print , the tea m is given cllmplett>
every 24
hours
l S·mlnute dally meetings

1) Done since laSt meeting?
2} Have any obstacles'?
Sprint Backlog 01 Backlog 3) What will you do belore next
items 30 days meetrng?
assigned features expanded
•••• by team
New Functionality
Demonstrated
Product Backlog at end of sprint
Prioritized product features desired by
customer .
Figure 4.8 The serum work flow

SOUrce: QuoteCI and edited from t\rtf)'jfWvrIW coouolchaos.com/aboul
control of how they are to successfull y complete the spnnt. At the e nd of a sprint a customer demonstration is
conducted for the cuStomer. It serves several purposes, including [8],
t . Demonstrating to the custo mer what has been accomplished .

2. Giving th e develo pers a sense of accomplishment .
3. Ensuring that the software is properly integra ted and tested
4 . Ensuring that real progress is made o n the project.
At the co nclusion of the dem o nstration, the leftover and new tasks are gathered, a new backlog is
created r and a new spri nt commences.
4.4.3 Crystal
Crystal is a family of agile methods devel oped by Alistair Cockburn . Each Crystal method shares common
characteristics of "frequent delivery, close communication, and reRective improvement" (9 ). ot .11 projects
are the same , so differe nt Crystal methodologies were crea ted to address differences," project size and
critica lity. Figure 4.9 shows the different methodologies and the size project they are best suited to. Crystal
methods are characterized by a color, starting at clcar for smaIJ teams and progressing through to or""9'. mi.
and so on as the number of people increa ·os. For example, Crystal lear IS geared for smaIJ teams of
approxima tely 6 people, YeIJow for toams of t 0-20 people; Orange for teams of 20-40 people , and so o n, The
other axis deRnes the critica lity of a project, where L IS loss of life, E IS loss of es enllal monies. D IS loss of
discretionary monies, and C is loss of comfort . Note that the row for los of life" nOt shaded in Figure 4.9.
This is because Cockburn had no experience applying Crystal to the e types of projects when he .... ated th...
AGILE PROCESSES 73
L6
............. ,
,,,
E6
Clear
L; loss 01 life
E ; loss of essential monies
D ; loss of discretionary monies
C ; loss of comfon
Figure 4.9 Coverage of various crystal methodologies

SOUrce; Adapted trom CocXburn. AlistaIr, "Crystal Clear A Human-Powered MethodOlogy for Small Teams," Aadlson-wesJey, 2005
chart. Crystal Clear doesn't explici tl y suppo rt the E6 box, although Cockburn no tes that teams may be able to
adapt the process to accommodate such projec ts. Ano ther restrictio n of Crysta l is that it is al'plic2ble o nl y to
colocated teams.
Cockburn believes that deve lo pers do no t read ily accept the demands of fl"Y process (docu mentatio n,
sta ndards, e tc ). H e strongly recomme nds accepting thi s by Introduci ng the most limited amou nt of process
needed to get the job do ne successfull y, ma xi mizing the likelih ood that team members will actua ll y fo llow the
process.
All Crysta l methodo logies arc built around three commo n pri o rities (9}
I Safery in the project o utco me.
2. EffiCiency in development.
3. Habitability of the conventio ns (I.e ., the ability of devel o pers to abide by the pro es itself) .
Crystal projects exhib it seven prope rti es to varyi ng degrees (9)
I Frequent delivery .
2 Reflective Improvement.
3 lose commun ication
4. P -"ona l safety.
5 Fow,
6 Easy a"ccss to exp rt use rs
7 Technical With au to mated con If.:ura ti on manage men t, and Ircqllcnt In H:..:ratl n.
74 CHAPTER 4 AGILE SOFlWARE PRO ESSES
n,e I1r,t three p,opertl commo n to the ry\tallJmlly The others Cdn be ad ded ,n any order to
III rc."c the I'Ke llhood o f 1)l'o)ec t ,afety and SULtesS.
4.5 INTEGRATING AGILE WITH NON-AGILE PROCESSES
Th e advantage. 0 1 agile meth ods in lude the abll,ty to adjust eas ily to emcrlling and c hangi ng rC'Iu".ment'
n,c d,sadvantage in lude awkward ro le for de iBn and dowmentat, o n ockburn's Crystal fam,ly 01
meth dologies alrcady acknowledges that different k,nds of appllcallons must be treated d,fferently . L"Ven
when the metho ds are ag de .
oft",.re pro e. s, after all , oncerns the order in which we perform act,vities' Fo r example, deSigning
Ars t and then coding from the des'gn One extreme IS the waterfall process. As we have seen, there are many
IIm,talions in our ab d,ty to thorough ly perform the waterfall sequence:' o nce, or even a few times, 'terat,vely.
hangea ble and unknown requirements are a principal rea on Regardless of the development process we use,
we must make trade ·offs in deciding ho w ex tens,vely to pursue a phase befo re movlO8 to ano ther phase.
o nSider, for examp le . the issue of how much effort to spend on planning a software enterprise.
One extreme project situation is when we are certain of obtaining all of the requirements of the end
date , of the high ·level deSign , and of who wi ll be working on the job. In that case, we can and probably should
devel op a de tailed plan .
The other extreme prOject ,tuation is when ,_e have little idea of any of these factors , believing that
they wdl beco me clear only after the project is under way . In that ca e, planning at a detailed level would be a
wa te o f time at best becau e it could not be even nearl y accurate, and would probably even be misleading.
We ha ve no choice in this case but to begin the process , and revi sit the plan as required. The extremes are
Illustrated In Fi gure 4. 10.
Agile methods provide beneAts bur also costs, and these depend o n several factors . Some are shown in
Figure 4. 1 I.
In order to gain the advantages of both agi le and non·a gile' processes, we try to integrate them . The
means by wh,ch this can be performed depend on several !actors, but particularly on the size of the job. As of
100%
----------------------
• Can obtain all require",sntSr •
• Certain of end dale
• Certain of hlglHe.el design - "
..,
' .'
Advisable • Certain of personnel

,,
delallievel ,
01 plans DETAIL PlAN ,,
,
.- ,
,,
_ _ _ _ _ _ _ _ _ _ _ _ Extent o(
,,
0% knowledge
100%
•
Figure 4.10 HOw detailed should plans be?
Some: authors c haracterize n n 'JKilc processes For C'x.lmplc. one practice j, to 311 them
I The-
do not believe ,n a I\lOglc Ch"fiJcteri zatlon like of non-agile hence thc= blankf!'l tenn -non.oglle ·
•
INTEGRATING AGILE WITH NON·AGILE PROCESSES 75
Benetlts 01 Aglig Costs 01 Agile

@ Motivates developers ® Hard lor new panlcipants
@ Thoroughly tested. usually ®Sensltive to individuals
@Easler to estimate each cycle ®Hard 10 estimate lull lob
@ Responsive to customer ®Umlls learn size
©Always demonstrable sohware
Figure 4.11 Trade-ofts between agile and non·agile processes
2009, the conventional wisdom concerning the agile/non .agile split is shown roughly in Figure 4. I 2, The
larger the job , the more non-agile process is required.
Agile processes empha ize code first, whereas non.agile ones advocate coding on ly from well·
documented designs and designing o nl y from well·documented requirements. These approaches appear
to be almost contradictory, so combining (hem requires substantial ski ll and care . We will co ncentrate on
methods for doing this in large jobs, where th e c hallenges are greatest. We will ca ll the two options "oll-agile-
drivrn and agile-driu<II and will compare them .
4.5.1 A Non-Agile-Driven Approach
A common non·agile-driven approach is to initiall y approach the job without agility , then fit agile methods
Into the process after sufficient work has been done to define the agile ro les and portions. We develop a plan ,
create a ca rehll high. level design, and decompose the work into portions that can be implemented by teams
In the agile manner. One can superimpose upon each agile team a process by whic h the accumulating
Percent
agile vs.
non'agile
t
100%
.,-
-
C>
,
'c"
0
Z
..
i
I
SmaJ/ Large Job slzo
Figure ' .12 conceptual agJle/non-aglle combination options: some conventional wisdom, circa 2009
- - - - - - - ; : : : : : - - - - - - -•• rima
I
Requirements
documentation
Design
2
documentation
._--......- ... . ", . - - --

Coding and 3
testing
System testing 6
• High level
Figure 4.13 Integrating agile with non-agile methods, : time line for a single iteration
requirements are gat hered . and placed wit h in a master requirem e nts document. The sa me can be do ne with
the accu mulati ng design . Domg thi with design is mo re d ifficult because design parts may actually be
replaced a nd mo dified as rd.ctoring takes place. Requirements tend to accu mulate as much as they change.
The seque nce of eve nts is as fo ll ows,
I. Hi gh . level requi re ments are developed for the first iterat ion .
2. A I" gh .level design is develo ped based o n the h igh .level req uirements.
3. Agile develo pment by tcams begins. based o n these hi gh · level docume nts.
4 . Full require ments documentatio n is ga the red fro m the wo rk do ne by the agile tea ms as it progresses
5. The design documentation i ga thered from the agile teams at regular interva ls to update the design
document.
6. System testi ng not covered by the ag il e process is performed at the end . if necessary.
7 . The process is repeated fo r eac h iterallon .
This is illustrated for o ne watcrfailiteration in Figure 4 . 13. Figure 4 . 14 shows thiS for multiple iterations.
4.5.2 An Agile-Driven Approach
For an agile .driven approach to large jobs. a (small ) agile team can be set to work o n signincant a p«ts of the
project until the o utline of an architecture appear. At that point . non ·agile methods are used. This ma
invo lve reintegrating agile programming again as described in the no n·agi le ·driven approach above. This has
muc h In common with building a prototy pe . H owever. the differe n e IS that the initial work i performed
larl!cly to develop an architecture rather than retire flSks . In add itio n. the work I no t planned a throw.away
cod e. One agile -drive n approach is shown in Figure 4 . 15 .
SUMMARY 77
Time
M I L E S T 0 N E S
First /teralion' completed X Product released X
SCHEDULE
Iteration number 1 2 3
• _. ' .
• w_._.
Requlrements
d ocumentatlon • • •
l' "Tf _.
• '- - --- - .
- .- - ---
oeslgn •I • • -t-
d ocumentallon '--
_ _ _N _
.- -- ._._- --t- .. • -- -'
Coding and ....i.
t estlng
- -.---- -- - -, -- -
,
•
s ystem testing I 2 I 3
'High level
Figure 4.14 Integrating agile with non·agile methods 2: time line for multiple iterations
Initial agile
development I
I \
\
f \
Requirements
documentation
'i : I
\
\
\
Design
' ''iL_ _.....J1
documentation
Coding and testing

(Including agility?)
Figure 4.15 An agile-driven approach to large jobs
The case sludy sectio ns fo r Ihis part o f the book (wh ich ap pear in Ch apters 5 and 6) ca n lai n two case
studies thaI combine agil e and no n·agile methods.
4.6 SUMMARY
Agi le software develo pm e nt was crea ted as an allernative 10 exi ling plan. based approaches thaI were
perceived 10 be too process heavy and ngid. A gmu p o f industry ex perts mel in 200 1 to share the. r v. io n fo r
an alternative to these types o f pro esses. They crea ted the Agi le Mani fes to to ca pture their Ih ollghls fo r a
process th aI ada p ta ble, lea n, and as d".
• TI,e need to collaborate close ly wilh cm lomors and other ,takeholders

• omtl'lUniCJIIOI1 over do umentatlon
• Frequent delivery of workll1!; software
• elf orga niz II1g reams
4
• TI,e need to embrace and plan for changing requirements
Any process that embraces Ihe fundamental values of the ag ile manifesto is considered an agile process.
Examples include extreme programmll1g , scrum , and Crys lal.
E '\Teme programmIng is ba ed o n four prin iples : communicat Ion . feedback , simphclty, and courage. It
promotes practices such a lest-driven development, refactorl ng, pair· programming , collective code owner·
ship. continuous integration, and on·sitc customer.
Serum deAnes a framework , o r a loose set of activIties Ihal arc employed by the crum team . At the
beginning of a project , a btl klog of work. or requirements, is identified . Deve/opers work on a subset of
reqUIrements in the backlog in 30-day Sprill!S . Once a spri nt begins, the team is gIven the freedom to employ
any methods deemed necessary to complete their work sucLessfull y. A customer demo occurs al the end of
each sprint. A new set of work is defined from the backlog fo r the next spri nt and the cycle continues.
Crystal is a fam ily of methodologies that address projects of differe nt size and crit icality . Crystal
methods share the following characteristics: frequent delivery, reAective improvement, close communication,
personal safety, focus , and easy access to expert users, and a lechn ica l e nvironment with automated teSling,
configuration management, and frequent integrati o n.
Agile and non· agile process ca n be integrated o n projects in order to gain the advantages of both . The
means by which this ca n be performed depend o n severa l factors but particularly on the size of the project. One
approach IS to Initiate a job without agility, then incorporate agile methods into the process after enough work
has been accomplished in defining agile roles and responsibi lities. Another approach is to initiate a job with an
agile approach until the outlines of an architec!l;re appear. At that poinl , non ·agile methods are used_This may
involve reintegrating agile programming again as described in the no n.agi le-drive n approach above.
4.7 EXERCISES
I. The Agile Manifesto favors working software over exte nsive documentation . Under what
circumstances can thi s calise problems if taken to an extre me]
2. . . In your own words, explain how agile processes adapt to and embrace cha nging requirements.
b. Describe a scenario in which this mi ght be counterproductive
3. Name three benefit of the XP practice of testi ng oftware from "day one," always having working
software available.
4. During the daily IS -minute scrum meeti ng, the leader is only allowed 10 a k the same thlee
questions . What two additional questions mig ht you want to ask] For each , explain lIS benefit
toward achieving the goals of the meeting.
5. In your own words, explain how Crystal adapts to various types 01 projCCts.
79
I Bcd. /'.I,ke An. VOIn Iknnckum, .nd AU"." Cocklxom, "MA.;J,,'" lor Aglk Sol'."", Dno<kop,... ( ·· Feb 200 I. hUpJI
OII'k" .. n,b,o.orW [>cee,sed November S. 2009}.
2. HicMlilllh, Jim , -H131ory Agik /\It4_iftsJd," 2001. httpJlwww Novcmha S, 2009]
1 JIm.. A Cock.bum, -Agile Sortware 11" of Innovallon: IEEE Vol. 34, No 9,
$q>'<mber 2001 , pp. nO-ll2 .
•. Cohn. M.rt. -Usn IOn" AppIJ,J For Agik Sol'..." Dno<iop"",,': Add;son·Wcsky. 2004.
S. Wells, Oon, -Ext" t Pr09'''.... '''f A c;..,.tlt ,,,,roJUfhOJl - hupJlwww (xlfcmcprogr.lmmln8 .0 rg/ Novm1bcr IS , 2009].
6 Ike Kent, ooExtrtU Ex,,"'iMd. .e..brder 2000.
7. }effriC'S, Ron. A.. Agilt I)n,dopmcn' Rncwrct " hup://xprogramming .com [accC'Ss.c:d November IS , 20091.
Ii. 8c:cdJe, Mike. M.. nlnc ()n.os, Yonal Sharon, and Ken Schwillx:r, -SeRUM, All atmsioll """gtulg( fen roJfvNm
I ...... iM' " http://jeff9.nhc:rland.comlscrumlscl'Wll...,plop.pdf [accc:ssed November 15, 2009]'
9. Cockburn, Alastair, "Cryswl Ctt.u,. A H"rfI,Q"-PDvxml MclboJology for S...all Tw",s." Addison.Wesley, 2005.

Software Process

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Software Process

Caricato da

Copyright:

Formati disponibili

Software Process

• What are the main activities of

• What are the main software

The Software • How would a learn such as a student

3.1 THE ACTIVITIES OF SOFTWARE PROCESS

• Their satisfaction with their current application

• ell lomer request for enhancements

" . .. An applica ti o n is needed to kee p track of vi deo rental s . . . "

• Planning (Software Project Management Plan )

• Requirements Analysis (Product , Software Req uire me nts Spec .)

• Design (Software Design Document, Diagrams and text)

.. ... classes DVD, Vid,oSlore , . . . , related by . . . "

• (Source and object code )

• . class DVD \ String title, . .. I...

• Maintenance (Modir.cd requirements, desig n, code, and text)

Enhancement, "Allow searching by d irecto r."

Fllllre 3.3 The main phases applied to a video store application

3.2 SOFTWARE PROCESS MODElS

3.2.1 The Waterfall Process Model

3.2.2 Iterative and Incremental Development

• An "external" release that IS shipped to customCrli fo r evaluation .

3.2.3 Prototyping, Feasibility Studies, and Proofs of concept

-.. Prototype Implements 0

Key:G= end of a unit 01 time = Activity wilh risk

Figure 3.6 An illustration of prototyping in the context of a development project

Figure 3.7 A rough calculation of whether developing a prototype would be wo rth It

0/0 expenditure 1000/0

3.2.3.2 Feasibility Studies

3.2.4 Spiral Model

1. IdentificatIOn of critical objectives and constraints of the product.

RISK ANAL YSIS

Figure 3.10 Boehm's spiral model for software development

3. Ide ntification of risks .

Advantages of the spiral model

Disadvantages of the spiral model

3.2.5 Unified Process and the Rational Unified Process

SOFTWARE PROCESS MODELS 47

Analysis & Design

• Make busi ness case

• Establish product visio n and scope

• Esti mate cost and schedule, includi ng major milestones

• Assess critical risks

• Build o ne o r more p ro totypes

• Specdy requirements in greater detail

• Create architectural baseline

• Refine rISk as essment and resolve hIghest ri k Items

• oml letc remaining reqUirement

• Do Ilera tl vc IInplcmcntJfion of rema ining dC'ign

• 1110roughl), te't Jnd prepare system (or deployment

• Conduct beta te'ts

• Create use r m"nuais

• Deliver the system for production

• Train end users, cu tomers and support'

• Conduct lesson learned

Advantages of the unified process

Utecycle ObJective. lItecycle In ltle' Operational Product

Figure 3. 12 Objectives for the unified process

UP Phaa•• - Typical Time DI •• rlbution

Disadvantages of the unified process

3.2.6 Agile Processes

• Sma ll , close -knit tea mS

• .. . indi vidual s and interactio ns

over o mprchenslvc docum ental ion

• . . . respo nding to change