chapter2spm

8/10/2019 chapter2spm

http://slidepdf.com/reader/full/chapter2spm 1/76

phases are the ones that a project goes through in a chronological order in any one

iteration. The number and nature of the sectors varies with the size and complexity of the

product.

2. The project starts off from the center of the diagram and spirals up (clock-wise

in iterations. !ach iteration starts from a particular sector and returns to that sector at a

higher level than its starting point.

". !ach iteration can be taken as a particular level of the product or the completion

of a particular part of the product (e.g.# re$uirements# design etc.. %bviously# the

incurred costs are higher as we go farther from the center of the spiral. &ence each

iteration strives to identify and correct any errors at that iteration itself.

'. !ach iteration takes off from where the previous iteration left and moves on an

outward spiral. !ach iteration builds the next level of the product# building upon the levelfrom the previous iteration.

. The more distant the current point from the center# the closer is the project to its

completion. The overall radius of the spiral (i.e.# distance from the start) center of the

spiral denotes the length and complexity of the project) product. *f a product) project is

an incremental version# then the spiral will be of a shorter radius than that of a

revolutionary new product.

There are various names given to the sectors or phases in the literature. *n the

original description in +,%!&-# there are four sectors (actually $uadrants that areroughly labeled /0etermine objectives1 identify constraints# /!valuate alternatives)

*dentify risks# /0evelop# verify next level product and /3lan next release. +4560-78

combines the vanilla spiral model with 0eming9s 3lan-0o :heck-6ct and names the four

$uadrants as /3lan# /0o# /:heck and /6ct. 6s can be seen from the discussion

above# the essence of the model is an evolutionary approach to building the product1 the

product basically evolving in a series of levels1 each level satisfying the following three

criteria;

• !ach level is an indication of the stage of evolution of the project.

• !ach level builds on the previous level

• !ach level tries to isolate and correct errors at that level without passing them on

to the next level. That is why one of the sectors is usually called the /5isk

6nalysis# /!valuate 6lternatives or the /:ustomer !valuation sector.



Key Advantages and Disadvantages of the Model

The main advantages of the <piral model are;

• *t is realistic and typifies most software development products) projects. =ost

software is evolutionary in nature and this model captures that nature.

• *t combines the best features of most of the earlier models; 6 typical application of

the spiral model can use prototyping as a means of eliciting feedback (and

ensuring that the re$uirements are properly captured within each iteration. The

different phases resemble the >aterfall =odel.

• *t strikes a good balance mechanism for early problem identification and

correction while not missing out proactive problem prevention. !ach iteration has

a 5isk 6nalysis sector that evaluates alternatives for proactive problem avoidance.

6lso# each iteration has a /testing or /customer acceptance sector that takes care

of error correction at that level.

The key to the successful application of this model lies in effective management

oversight in ensuring that the evolutionary approach does not get out of hand. >hile

starting the overall product) project# there should be a clear definition of goals and

objectives1 at each level# while building upon the previous levels# it is important not to

change drastically what is expected of the previous levels and make the previous levels

go back to the drawing board often.

Applicability of the Model



There are significant similarities in the nature and applicability of this model as

compared to the 560 model. This model?like 560?is most applicable when the

product can be evolved in a series of steps or levels# each one building on top of the

previous ones. This model also re$uires some amount of customer participation and input but is more suited to building of general purpose software. 6lso# the spiral model tends to

be more useful for the development of systems software than 560.

CONCLUSION

>e have discussed the various models for software product * project life cycles.

The intent has been to describe the various models and their applicability. *t should be

noted that in real life situations# the actual /life cycle model could be a combination of

the features of one or more of the above models. These models are intended to be the

guidelines rather than be prescriptive. 6t the end of the day# it is important not to twist the

natural and most appropriate way of working on a product * project to suit any one

theoretical model.

REERENCES

The original treatment of the waterfall model is in +5%@:-8A. +,5%%-8

illustrates the concept one to throw away# an essential ingredient of the prototyping

model. The 560 model is discussed at length in +=65T-7B. The original spiral model is

in +,%!&-. Cariations of the same can be found in +35!<-78 and +4560-78.+&D=3-E and +35!<-78 give overall summaries# comparisons and birds-eye-view of

the various models.

CHAPTER 4



PROCESS MODELS

/!nd does not justify the means. — =ahatma 4andhi

Characteristics of a processes — what constitutes an effective process—why are

processes important — ISO-9001 — model — Capability Maturity Model — Common

misconceptions about processes

!"# IN$RODUC$ION

*n this chapter# we describe the concept of a process and how it is important in the project

life cycle. >hat is a processF ,efore we answer this $uestion# let us formally define a

term we have been using extensively so far# namely# a %&od'ct(

! "roduct is somethin# that is deliverable to an internal or an e$ternal customer

Gow# the definition of a %&ocess(

! "rocess is a documented and followed way that constitutes one or more steps in

producin# a product

!") C*ARAC$ERIS$ICS O A %ROCESS

Hollowing through on the definition of a process that we gave just now# let us explore

some of the characteristics of a process. Higure '.Bexpounds the concepts discussed as

follows.

%i# &1 "rocess characteristics



Each p&ocess has a +ell defined set of inputs that it ope&ates on( The purpose of a

process is to produce a product. Hor this# it needs a set of inputs. Hor example# for the

coding process# (where actual programming takes place# the design document constitutes

an input. 6n input is usually an output from another process (see next paragraph. <ome

of the inputs are mandatory to a process (i.e.# the process cannot proceed without suchinputs and some are optional inputs.

Each p&ocess p&od'ces a set of outputs that a&e 'sed as inp'ts to othe& p&ocesses( 6

process transforms its inputs to pre-defined outputs. Hor example# the design process

takes as inputs the re$uirement specifications and produces as output a design document.

This design document in turn becomes an input to the coding process.

Each p&ocess has a set of steps that a&e to be follo+ed to p&od'ce o'tp'ts f&o, the

inp'ts( The steps document what needs to be done# by whom# and in what se$uence to

transform the inputs to outputs. %ne can view this as the algorithm of the process.

Co,,on %itfalls in Doc',enting Steps

The purpose of documenting steps is that the reader of the process gets to know whoshould do what and when. This simple logic is sometimes forgotten by some poor writing skills.*n this inset# we give some examples of how easy it is to write bad documentation for steps andwhat are some commonsense tips to follow to avoid these pitfalls;

• ,ackup shall be taken.

>hen a step is documented like the above# no one knows when and who should takethe backup) <o a golden rule to follow when you document a step in the process is neve& 'se

passive voice- always use active voice)

• Eithe& the enginee& o& the ,anage& +ill ta.e the bac.'p"

This is a case of />hen somebody should do it# nobody ends up doing it) The lessonto be learned from this is that one should try to be specific as to who will carry out the step. *ngeneral# try to document each step in the format I/ does 01 where J is an unambiguous role and@ is a specific action.

• $he bac.'p shall be sent as soon as possible on co,pletion of the &elease

/6s soon as possible indicates it is never soon enough) $&y to be specific in te&,s

of ti,e li,its" 6 better way of documenting the above step could be /The administrator shall dothe backup within working days of completing the release.

• 2he&eve& possible- bac.'ps +ill be ta.en

>henever such an option is given# it is always easy not to take a backup) >hiledocumenting the steps of a process# the writer should avoid phrases like />herever possible#/>henever possible# /as soon as possible etc. 6 better way to document the above step could be# /The administrator shall take a backup immediately upon the completion of the cutting of the:0.



Each p&ocess gets t&igge&ed by a set of start criteria' To use an operating system

analogy# a documented process with the inputs?steps?outputs is like an executable

program stored on the disk. The process itself assumes a form only when it is executed.

(5emember the old operating system adage /6 process is a program in execution). The process can start being executed only when certain events defined as start criteria happen.

Hor instance# design can start only when the re$uirement specifications are signed off. *n

general# the minimum start criteria that is needed is that the mandatory inputs must be

available.

Each p&ocess has a set of success measures' These enable us to measure the consistency

and the degree of success of executing that process. %ne of the measures is also the

completion criteria# i.e.# at what stage does one deem the process complete. 6s an

example# you can say that the success measure for the testing process is the percentage of

code coverage obtained by testing. 6 completion criteria could be that /Testing is deemed

complete when 7AK of the code paths are covered by the tests.

$he s'ccessf'l e3ec'tion of each p&ocess is ve&ifiable by a set of (uality records' *n a

sense# these are like audit trails# i.e.# they are proof that the process was carried out in

compliance with the steps and meeting the success measures. =any times# the production

of outputs may itself suffice as $uality records. 6 typical example of when an output is

different from a $uality record is; >hen a product is produced and tested# the product

itself is the output. The test records that show what was tested# the extent of testing# and

the proportion of tests that succeeded the $uality records.

inally- each p&ocess has an owner +ho is a'tho&i4ed to change the p&ocess( *t is

assumed that the documented processes are the culmination of collective experience of

the organization. &ence it is important that great care be exercised in maintaining these

processes and in making the necessary changes to these processes as when re$uired. To

ensure this# each process is assigned to an owner. This owner is usually a practitioner who

has considerable experience in using this process.

!"5 2*A$ CONS$I$U$ES AN EEC$I6E %ROCESS7

Hundamentally# a process should be useful for the organization. !xperience shows

that for a process to be effective and useful the following attributes must be satisfied;

Start with what is being practiced: %bviously# any process must be practised in an

organisation before it can be institutionalized. %f what use is a process on /&ow to make

ice creams# if your organization is not in the business of making ice creams) %ne of the



challenges that comes about when we mandate that we should start with what is being

practiced is that we hear each person would say... but my project is very uni$ue). @ou

may then end up with only project-specific processes which will serve no purpose. The

challenge is to achieve the right level of abstraction that would generally be applicable to

most of the projects# but at the same time# not be so generic that it does not add value.

Docuent what is being practised: %ne of the objectives of a process is to make the

production egoless# i.e.# to reduce dependency on the person executing the process. 6

process that exists only in the head (or the heart) of an individual is of no use. Thus to

satisfy the above criteria of an egoless execution# process as must be documented. 6s the

objective of these processes is that they be used in day-to-day operations# it is important

that such documentation is done by a group of practitioners who actually use the

processes. ,y involving the practitioners# there will be a better buy-in and a better chance

of success. 6lso# by involving a group# there is a better chance of wider applicability.

Ensure that the processes are adaptab!e to a nuber o" pro#ects: The processes should

not straight-jacket the people; they should be flexible enough to adapt to the variety of

projects that exist in an organisation. 3eople should not feel that they have to force fit

projects to processes.

Train the sti"" on the use o" the docuented processes: !ven if the process is

documented# it would serve no purpose if new-corners cannot be trained on its use-.

&ence the current practitioners should train the entire organisation on the use these new

processes. Training is the first step towards adaptation and widespread acceptance of the processes across the organisation.

Deand and en"orce the use o" processes: *n a typical software organisation# thereB will

always be new-corners who may not know why the processes are needed or why they are

used the way they are?notwithstanding the amount of training they receive. *t might

re$uire enforcement of some rules by the senior management for the processes to be

followed# in view of the benefits that an organisation has g - in the past. *n particular#

senior management should not let employees short-circuit the processes for any short

term benefit. 6 process that is not enforced is likely to be taken less seriously and

therefore would not achieve its purpose. *t would likely remain a paper process and over

time# the practice would diverge from intent.

Measure the e""ecti$eness o" cop!iance to the process: <omething that cannot be

measured cannot be controlled. Taking an example from sports?all sports have a clearly

documented process of scoring. *s there any sport or game with no scoring) %ne way of





lay out the common functions that need to be carried out to achieve consistency and

predictability in the results and $uality of deliverables. >e discuss two of the most

popular models? *<%-7AAB and <!T9s <oftware :apability =aturity =odel (:==?in

this chapter. *n the next two sections# we will discuss the details of these process models

and their relevance in project management.

!"!") $he ISO:;##) Model

The *<%-7AAB model was originally targeted at producing consistency)

predictability and repeatability in the manufacturing sector. 0uring the mid-B7A9s# the

model was adapted for the software industry# with certain differences from the model for

the manufacturing industry. *n its basic form# the *<%-7AAB model has a set of 2A clauses

given in Hig. '.2 (referred to as /'.B through '.2A that create a framework for

enhancing consistency and predictability of processes followed in an organisation. *n

order to interpret the *<%-7AAB model more effectively for the specific needs of thesoftware industry# *<% came up with *<%-7AAB-" (which are guidelines for software

mapping the twenty clauses to specific activities in software development where

applicable. I

5ather than look at *<%-7AAB as a set of abstract twenty clauses or get bogged

down by specific details in *<%-7AAA-"# we take a different approach. %ur intent is to see

the relevance of this process model in the context of project management. &en in the

discussion below# we evolve the twenty clauses as sound business practices relate directly

to and enhance the $uality of the life cycle activities described in previous chapter.



%i# &* ISO-9001) *0 clauses as *0 #ood business practices

The intent of a software organisation is to understand the re$uirements of a

customer and effectively translate them into a product that meets with his expectations.

&ence# the first step is to ensure that we have indeed understood the customer9s

re$uirements and secondly that we have the resources and wherewithal to execute the

project successfully. This is exactly what Cont&act Revie+ <!"8= tries to accomplish. *n

effect# contract review ensures that the project fits into the 6ggregate 3roject 3lan of the

organisation. There may be skills that the organisation may not possess but has to ac$uire

in order to execute the project successfully. The $&aining <!")>= clause addresses

mechanisms to identify and provide appropriate training to the people.

&aving understood the re$uirements# we have to ensure that the design is in

accordance with the re$uirements before embarking on development. Design Cont&ol

<!"!= accomplishes this by introducing design review# design verification# etc.

0uring the execution of the project# we would need various resources. These could

include machines# hardware# software and people. <ome of these we have to procure

ourselves and some the customer may supply (for example# for a bespoke on-site

development# we may be working on the customer9s hardware. *t is obvious that one has

to ensure that the input resources are of acceptable and predictable $uality. %'&chasing

<!"?= and Cont&ol of C'sto,e& S'pplied %&od'cts <!"@= ensure that the incoming



materials (or people meet the criteria laid down for satisfactory completion of a $uality

product.

0uring the development phase?in fact throughout the process of project

execution?one has to ensure that proper standards (e.g.# :oding <tandards# are followed

and that the working environment e.g.# machines# office# etc. are at acceptable levels.

6lso# all other aspects of the project have to be in compliance with the company (and

may be even 4overnment policies. %&ocess Cont&ol <!";= lays down the framework to

accomplish these important aspects.

%ne of the principles for effective and efficient delivery of (software products is

to ensure that any defect in the product be identified and rectified close enough to the

point of time when it is injected. (6n even better scenario would be that the defects are

prevented# but we shall come to this later. To facilitate this# *<%-7AAB has introduced the

concept of *nspection. Inspection and $esting <!")#= covers processes to test the productfor defects while it is in-process or after completion. >henever you test a product# you

have to first ensure that the test e$uipment itself is error-free (imagine measuring

temperature with a faulty thermometer). *n the software context# test e$uipment refers to

things like testing tools# spreadsheets or databases used for logging# analysing the results#

etc. This function is addressed in Cont&ol of inspection- ,eas'&ing and test e'ip,ent

<!"))=" >hen a product fails some of the tests (Gon-:onforming# it is essential to have

procedures for identifying and segregating such products. Cont&ol of Non:confo&,ing

p&od'cts <!")8= pretty much focuses on this issue. The Inspection and $est Stat's

<!")5= puts in place processes to ensure that the records of testing are properlymaintained.

The previous paragraph addressed issues of product conformance. *t is also

e$ually important to ensure process compliance. Inte&nal A'dits <!")@= are a means of

ensuring that the organisation follows the documented processes. 6ny process has t have

$uality records to demonstrate its compliance and that is what Cont&ol 9'ality Reco&ds

<!")?= is all about. >hen the non-compliance of a process is discovered# it is important to

correct not only that instance of non-conformance but process has also to be improved so

that in future non-compliance can be avoid This is achieved by Co&&ective and%&eventive Action <!")!="

To round up the *<%-7AAB9s relationship to product development life cycle# one

has to be able to identify products in their various stages of evolution (different versions#

different levels of tests passed# etc.1 be able to specify how the product is to be packaged#

delivered and installed1 and be able to service * maintain the product once the product



goes into the maintenance mode. These activities are addressed by %&od'ct

Identification and $esting <!">=- *andling- Sto&age and %ac.aging <!")B= &d

Se&vicing <!");= &espectively"

*n order to achieve all of the above# it is very essential that there should be# first of

all# a very well defined $uality system (also called the Luality =anagement <ystem or

L=< and secondly# the implementation of the L=< should be taken seriously by the

management. This is spelt out very clearly in 9'ality Syste, <!"5= and Manage,ent

Responsibility <!")=" 6s outcomes from processes are essentially statistical# mere should

be effective use of Statistical $echni'es <!"5#="

Mast# but not the least# there should be effective document and change control

throughout the life cycle of the project. Doc',ent and Data Cont&ol <!"B= addresses this

very important umbrella activity.

Thus we have seen in the above discussion that *<%-7AAB clauses are not just

/arbitrary clauses but also make a lot of sense in the normal software development life

cycle. &ence a mandatory and an effective implementation of these clauses are likely to

enhance the predictability and consistency of the product.

!"!"5 $he Capability Mat'&ity Model

<oftware :apability =aturity =odel (<>-:== or :== for short was evolved

at <oftware !ngineering *nstitute by studying the development processes and practices

followed in several large projects in organisations like the D< 0epartment defense. ,ystudying the practices in these projects (that covered almost all aspects of product life

cycles# <!T abstracted the common features about how to produce software products

with consistent# repeatable and predictable $uality and how institutionalize the best

practices. Thus was born the <oftware :==.

Mike *<%-7AAB# :== also strives to achieve predictability and consistency as a

precursor to continuous improvement in the product by following a set of processes in a

well defined framework. Dnlike *<%-7AAB# which applies to all industries# :== applies

only to the software industry. &ence from a software project management perspective#

:== is a very valuable model to study.

The :== defines five levels of maturity of a software organisation. (<ee Hig.

'.". 6t each level# there are certain +ey "rocess !reas (N36 that an organisation must

satisfy. *n order to be at a given level# all the N36s of all the preceding levels must be



satisfied. N36s# like the *<% clauses# are simply sound business practices and not

arbitrary goals.

%i# &, SI Capability Maturity Model

Level ) of :== is called the Initial level" %rganisations at this level are

generally chaotic in the sense that there are no processes that are either defined or

followed in the organisation in a consistent manner. *t does not mean that these

organisations cannot be successful# but what can be said is that there is no predictability

as to how they will perform in any future project based upon past results. %ne of the mainreasons for this is that these organisations thrive on the personal heroics of a select few#

who may or may not continue working in the organisation. Gor can it be guaranteed that

these individuals can keep up the momentum forever. 6nother factor that affects

predictability and $uality is that when an organisation grows and a product matures# there

is a clear need for established processes in areas like support# servicing and maintenance1

and these are generally not the forte of the heroes of Mevel B %rganisations.

Level 5 called the Repeatable Level puts in place the management processes that

help achieve repeatability of performance and $uality# should the organisation undertakea similar project again. The N36s of this level are directly relevant to life cycle activities;

they start off with Re'i&e,ents Manage,ent# putting in place mechanisms to ensure

that we understand the re$uirements properly and can meet them (just like contract

review does in *<%. Then they take on Soft+a&e %&oect %lanning and %&oect

$&ac.ing Ove&sight" 6 couple of umbrella activities like soft+a&e Config'&ation

Manage,ent and Soft+a&e 9'ality Ass'&ance follow suit. S'bcont&acto&



Manage,ent ? an important activity in these days of outsourcing ? completes the list

of N36s of Mevel 2.

6t the end of Mevel 2# the organisation has defined the management processes

needed to achieve repeatable performance and consistency# should the organisation again

do a similar project. ,ut there are no technical processes that are defined# nor are the

processes necessarily consistent across the various projects.

The N36s of Level 8 (the Defined Level spread the process culture to the entire

organisation. O&ganisational %&ocess Definition makes the organisation define the

processes for execution of its day-to-day (technical functions (this definition is generally

done by the practitioners. 6 drive to O&ganisational %&ocess oc's is started and

maintained by activities such as forming of a <oftware !ngineering 3rocess 4roup

(<!34. *n large projects# one of the most important factors for success is that the

different groups work together effectively. Inte&:g&o'p co:o&dination N36 lays donguidelines that when tailored to meet the re$uirements of the organisation# ensures a high

degree of co-ordination between the various groups# with each group knowing what is

expected of it to ensure the success of the project and possessing the re$uired skills. 6lso#

as a first step towards correcting the defects as close to the paint of injection as possible#

%ee& Revie+s are introduced. Hinally# Integ&ated Soft+a&e Manage,ent addresses

issues that tie the entire life cycle together (e.g.# design testing# etc.

>hen an organisation reaches Mevel "# it would have achieved not only stable

management practices but also well defined processes on how the actual business iscarried out. Thus it would be possible for a new-comer into the organisation to reach the

desired level of competence very fast. !$ually important is the fact that once the

processes are defined# we have set the stage for making meaningful measurements to

know where we stand $uantitatively.

This is what the Level ! (the Meas'&ed Level achieves; 9'antitative %&ocess

Manage,ent K%A provides an organisation with a framework to define# capture arid

analyze appropriate metrics. ,ased on the metrics thus captured# Soft+a&e 9'ality

Manage,ent lays the foundation on which $uantitative $uality goals are set and

evaluated.

6 Mevel ' organisation is usually able to $uantify its processes and $uality in terms

of numbers. These numbers and metrics are most often directly relevant to the

performance and profitability of the organisation as they are actually defined by the

practitioners. %nce we can $uantify the $uality levels of the process and the products# we



can go the next level? Level B# called the Opti,i4ing Level" &ere# the processes are

continually fine-tuned and people are always working towards some targets to achieve

better and still better results as they go along. This continuous up gradation and

improvement is brought about by using the three N36s? Defect %&evention# by which

we introduce steps to ensure that defects do not get injected into the system at all1$echnology Change Manage,ent- by which we effectively absorb new technology into

the organisation and leverage it for continuous improvement1 and finally# %&ocess

Change Manage,ent- by which we consciously track what process changes need to be

made and the effect such changes have on the overall $uality of the product.

Gote that while all the other levels had their names in the past O past continuous

tense (5epeatable# 0efined# and =easured# Mevel is in present continuous tense

(%ptimizing) The reason for this is that continuous improvement is an ongoing process

that continues ad infinitum. 6t some point of time# one would see the law of diminishing

returns on efforts put in. Then# probably# the organisation would start with some new set

of business models and O or projects where it may have to start all over again from the

0efined Mevel or even the 5epeatable Mevel.

6s can be seen from the above discussion# :== and its N36s are directly

relevant to project management. There are two other very important concepts from :==

that we would take up in the framework for discussions on the specific life cycle

activities in the later few chapters. These are the concepts of Ney 3ractices and &ierarchy

of !stimates.

6ny N36s in :== has five broad characteristics (called Ney 3ractices;

• Co,,it,ent to %e&fo&,( 0oes the organisation display the commitment needed

to perform in the N36F &ow do you ascertain this commitmentF

• Ability to %e&fo&,( 0o the people have the ability to perform what is needed to

achieve the N36F 0o we have mechanisms (and commitment to train the people

if neededF

• Activities %e&fo&,ed( >hat are the actual activities performed when one attempts

to satisfy the N36 re$uirementsF

• Meas'&e,ents( >hat measurements do you take to ensure that we are following

the N36 re$uirementsF

• 6e&ification( &ow do you actually verify (i.e.# what do you compare the

measurements against to know that you are on the right trackF





manager to make an almost unbiased and reasonably accurate assessment of the

capabilities of the organisation to deliver the product. *t also enables him to set the right

expectations with the various stakeholders. 6s the eventual satisfaction is to a large

measure dictated by the expectation setting# the project manager would have gone a long

way in ensuring the success of the project.

!"B COMMON MISCONCE%$IONS AOU$ %ROCESSES

3rocess frameworks like *<%-7AAB and :== have produced significant benefits

to most organisations that use them. &owever# the success of the processes is largely

determined by how well the criteria for effective processes discussed in <ection '.2 are

complied with. Gotwithstanding the benefits of processes# there is usually a lot of

resistance to adopting a process framework like *<% or :==. <ome of the common

objections (which are actually misconceptions often heard are;

F%&ocesses inhibit c&eativity1( The reasoning given to substantiate the above claim is

that /processes give detailed steps on how to carry out a particular activity# thus they

completely preclude individual creativity and uni$ueness. The flaw in this argument is

that processes document things that often remain unchanged. !xperience has shown that

a significant chunk of any activity is made up of routine things that do not change with

time. Hor example# when you want to hire staff# you always have to go through some

routine processes like designing an advertisement# choosing the media in which to

advertise# negotiating rates for advertising# etc. >hile these steps are fairly static# what

you do specifically in each step would vary. Hor example# each advertisement could bedesigned in a different way based on the need.

,y adopting a common framework# the processes ensure that you are not missing

any vital step. Hurthermore# by augmenting the processes with illustrations and standard

lists# you may even get a head start. *n this example# if the processes also had a list of

media which have been successful in the past# you would not have to do the same

research again. ,y documenting these common or routine jobs as processes# the person

executing the tasks need not unnecessarily spend time on reinventing the wheel# i.e.#

figuring out how to do these routine jobs. &ence# the processes in fact leave more time

for creative work by individuals.

F%&ocessG'&ea'c&acy1( 6nother way this is expressed is /* have done all my

real9 work# now let me do the process stuff2 *f the processes are properly designed# then

they should involve no overheads or extra effort. 3rocesses should follow the dictum /do

what you say and say what you do. &ence you shouldn9t have to do anything extra just



for /processes9 sake. Luality records from a process should be its automatic by-products

rather than some rare artefacts. *f this general principle is followed while designing the

processes# then processes would not be perceived as bureaucratic.

F%&ocesses do not apply to sho&t cycle ti,e p&oects1( 6nother common excuse

given for not adopting processes is /@ou can do all the $uality documentation# processes#

reviews# etc# when you have long cycle time projects. =y project cycle times are so short

that * barely have time to do my work1 how do you expect me to do all this process

workF The fallacy here is that in a short life cycle project# more than in any other# you

need to avoid repetitive work. *n reality# the processes are as applicable in short cycle

time projects as they are in long cycle time projects.

FCe&tification as 'st a ,a&.eting activity1( *t is unfortunate that we see

organisations that use certification as a pure marketing flag. :ertification should be

viewed as taking an examination to prove your competence. The goal should be# gain thecompetence and come out with flying colors in the examination and not Ijust /cram for

the examination. *n the long run# the gimmick of using certification as a pure marketing

tool# without implementing the $uality systems with the proper intent# will backfire on

the organisation.

CHAPTER %

METR&CS

'(oa!s ) The "irst step towards getting soewhere is to decide that *ou are not going to

sta* where *ou are:+ ,,-ohn Pierpont Morgan

Metrics 3 In process metrics and end 3 result metrics 3 .he Metrics 4oadmap 3 ! .ypical

metrics strate#y 3 5hat to measure 3 .ar#ets 3 variability 3 !ctin# on data 3 "eople and

or#anisational issues 3 Common pitfall 3 Implementation 3 chec/lists

B"# IN$RODUC$ION



*n this chapter# we cover =etrics. >e looked up the word /=etric in the various

dictionaries. >ebster9s defined the word as an adjective# 6based on the meter as a

standard of measurement7 of) relatin# to or usin# the metric system8 %bviously this was

not the definition we were looking for) 6 little closer was the word /metrical which

meant of or relatin# to measurement which captured the real meaning that is normallyassociated with the word =etrics from a software project management perspective.

3erhaps the best motivation for =etrics comes from a $uotation by Mord Nelvin (of the

Nelvin Temperature <cale fame;

65hen you can measure what you are spea/in# about) you /now somethin# about

it' but when you cannot measure it) when you cannot e$press it in numbers) your

/nowled#e is of a mer#e and unsatisfactory /ind7 it may be the be#innin# of /nowled#e)

but you have scarcely in your thou#ht) advanced to the sta#e of science8

=etrics in a project management context is about measurements R =easuring your progress in order to know where you are and what mid-course corrections you need to

take to achieve your goal. There are two distinct (but related components that are

touched upon in the above sentence; Hirst is that metrics are measurements to measure

your progress R we call these in process-metrics. The second is the measurement of how

well you have achieved the goals R we call these the end R result metrics or business

goals.

&aving said that metrics is about measurements# several important $uestions arise

B. >hat should be the ideal roadmap for metricsF2. >hat should be the strategy for implementing metricsF". >hat are the individual steps that constitute metricsF'. >hat are the common management issues and pitfall to watch out for in

implementing metricsF These topics get addressed in the following sections of this chapter. >hile we do

give some examples of metrics in this chapter# we have consciously avoided going into a

lot of detail on what the specific metrics of each of the various project phases should be.

!very activity R be it an umbrella 6ctivity like <oftware configuration management or an

in-stream activity like project initiation R will have relevant metrics that need to beidentified. This is the reason why metrics is covered as the first umbrella 6ctivity in this

book. *n this chapter# we present some of the basic principles in metrics in any activity. *n

each of the remaining chapters# we will discuss in detail the specific metrics that apply to

that particular step O activity.

B") $*E ME$RICS ROADMA%



The =etrics 6ctivity should be viewed like a roadmap. ,asically# every project

has a certain set of objectives it has to meet. There are short term objectives# viz.# and the

specific deliverables for the particular project and there are long term objectives# e.g.#

how is this project tied to our company vision or how does this project further thelearning in the organizationF 6ny metrics program or measurements should provide

gauges that measure our progress towards both short term as well as long term objectives.

%i# 1 .he :emin# ":C! cycle for metric

The strategy for a successful metrics program falls in line with 0eming9s 30:6

Luality =odel as illustrated in Hig. .B. The acronymn 3-0-:-6 stands for 3lan? 0o?

:heck? 6ct. Hor any project or activity# you 3lan what you want to achieve# based on

your current position and your eventual destination. >hile making this plan# you also

establish measurement criteria (which includes what you measure# how you measure#how often you measure and what are your acceptable O borderline and danger zone

parameters. Then you 0o or carry out the 3lan. This entails carrying out the necessary

steps for the actual execution and also carrying out the measurements for health check.

The :heck phase compares the measurements made against the expected norms set in the

3lan phase. *f things are found to be out of line# corrective actions need to be taken. The

corrective actions (or fine-tuning or mid-course correction# to use other terms are taken

in the 6ct phase and we start all over again by refining the 3lan.

<tated in a different way# we can say that there are five $uestions one has toanswer for a metrics program that fall in four steps# as given in Hig. .2.



%i# * .he (uestions to as/ in a metrics pro#ram

B. >hat is your goal or where do you want to goF2. >hat is your current positionF". Nnowing where you are and where you want to go# what steps should you takeF'. &ow do you measure your progressF. >hat corrective actions do you take when you see that your progress deviates

from the expected courseF

Met us examine each of the $uestions in a slightly more detailed form.

*n managing a project successfully# the first step is to know what the goal or the

destination is. The goal has several dimensions like timeline# resource constraints#

profitability# $uality re$uirements# etc. >hile formulating the goals# it is important also to

strike a balance between the project (or tactical or short term goals and the

organizational (or strategic or long term goals. <ometimes these two may be conflicting

and there should be clarity of understanding why we are shooting for a goal. Hor

example# as a rule# every project usually strives for a certain profit margin. ,ut# there may

be some key customers whom you want to win over and may be willing to sacrifice the

margins. >hile undertaking such goals# the organization (and the project manager

should be very clear on the goal they are shooting for and why. *t is also important to

communicate the goals and the vision to the rest of the team so that there is a shared

vision and purpose.

%nce you know where you want to go# you should take stock of where you are

today. Nnowing where you are today comprises of asking ourselves $uestions like />hat

are our strengths and weaknessesF1 />hat has been our track record so farF1 /0o we



have the skill sets re$uired to achieve the goalsF and so on. This step is like taking a

health check of where the organisation stands today with respect to achieving the goals

set forth in the first step.

Nnowing where you are today and where you want to go (the eventual goal

enables the construction of an action plan of /how to get there from here. There are two

important constituents to an action plan. The first comprises the actual action items or

steps needed. Hor example# you may discover in your analysis of where you are and

where you want to go# that you currently do not have competency in a certain technology

area and that you need to ac$uire that competency. The action plan may be a training plan

of how O where you would get trained in that technology or where you would hire people

from with that competency. The second constituent of the action plan is comprised of the

steps to measure whether or not we are straying from our path. *n other words# while

carrying out the actions# how do you ensure that we are making progress (and making

sufficient progressF *n the above example of training# an essential step of the action plan

would be Ihow do we measure the effectiveness of the training receivedF9

Hrom the above steps# you have got a feel of the pulse of your progress if you have

got your measurements right (and are measuring the right things)# you would have got

data on whether or not you are on the right track1 if not# you would have an idea as to

what is needed to effect a mid-course correction. This constitutes the final step of the

metrics program?acting on data gathered and minimizing the deviation from desired

results.

A Real:Life E3a,ple of HMet&ics Road,ap

To illustrate this with a non-software example# let us imagine that our objective is to visit theHisherman9s >harf in <an Hrancisco. &ow would you start your plan or a measurement programF

%bviously# the first thing you should do is to evaluate where you are now) *f currently you are in,angalore# *ndia# then the kind of plan and measurement criteria you would need would be verydifferent from the one needed when starting from <tanford# :alifornia. *n the first case# your plan(and therefore your measurement criteria would include factors like;

>hat are the cheapestOmost convenient air-connections that exist from ,angalore#

*ndia to <an HranciscoF

>hat is the budget for your hotel stay in the ,ay 6reaF



>hich hotel offers the most comfortable room within the budget arid is close to

the Hisherman9s >harfF%n the other hand# if you are starting your journey at <tanford# :alifornia# your plan (andtherefore the measurement criteria would not be concerned with the cheapest air fare from*"angalore to <an Hrancisco or the best connections possible. *t would instead focus on;

>ould it be more practical# to take the public transportation or should * drive

downF

*f driving# which are the best routesOexits * would takeF >here would * parkF &ow

much time should be allocated to travel given the traffic conditions (and parkingavailability.

<o# it is obvious that you would start with an assessment of where you currently are and whereyou want to go# before drawing the roadmap of what you want to measure.

*n the above example# let us assume you are starting from <tanford and driving to theHisherman9s >harf. Met us assume that you planned and took the D< BAB &ighway# to alight atthe 4olden 4ate 6venue !xit. *f# after driving half-way through# you find that there is a traffic backup and that the D< BAB &ighway is closed to traffic# what would you doF @ou wouldobviously have to abandon your original plan mid-way and probably take some surface roads#reach a different highway and eventually try to reach your final destination within time. *n other words# you must be able to adapt to change.

The last step in the above example illustrates the next two steps in any measurement program; anessential part of any measurement program is that it should provide a? avenues for periodichealth checks by measuring progress towards the eventual goal. @ou will start off with someinitial plan (e.g.# the roadmap# define intermediate milestone or measurement criteria# carry outthose intermediate measurements# see if they c form to what was expected and if the values arewithin the acceptable limits1 then corrective action. !ach one of the steps presented above isextremely important also very easy to miss) 6nd when missed# it can render the much valuedmeasurement program totally ineffective.

B"5 A $0%ICAL ME$RICS S$RA$EJ0

&aving discussed the overall principles and the purpose behind metrics in the previous

section# we will now focus our attention on an outline of the steps that constitute a sound

metrics strategy;• Decide +hat yo' +ant to ,eas'&e and ho+ yo' a&e going to ,eas'&e it( *t is

very important for all the constituents to know the rules of the game# i.e.# what are

the measurements that matter and how they are carried out. This helps everyone to

work towards the same goals and have a common understanding of how to

measure progress.



• Set ta&gets and t&ac. the,( >hile the main goals (/where you want to go may

be well defined $ualitatively# it is also important to set specific $uantitative targets.

This step is about how to $uantify and track the targets.

• Unde&stand va&iability and +o&. to+a&ds ,ini,ising it( %ne of the

fundamental tenets of $uality performance is achieving consistency and predictability. Cariability is the opposite of predictability. This step is about how to

track variability and what to do to minimise it.

• Act on data and st&ive fo& contin'o's i,p&ove,ent( =easurements are useful

only when we act on them and take conscious decisions based on them. This step

discusses what kind of action is needed and how to achieve this action.

• Conside& the h',an angle( Dnlike most other industries# the software industry is

very people-oriented. >e cannot measure people9s progress the same way we

would measure a machine9s performance. There are significant human issues that

need to be addressed and this step covers some of those issues.

The subse$uent sections go into the details of each of the above steps.

B"8 2*A$ S*OULD 0OU MEASURE7

>ith the advent of tools and technology# it is very tempting to measure j a lot of

things) ,ut it is important that we measure those attributes that are related to the project

goals andOor organizational goals. The purpose of measurements (and the subse$uent

control if applicable is that they * lead to achieving the goals faster# more economically#

with superior $uality output and better employee O customer satisfaction. To achieve this

end# we present some $uestions that one should ask to decide whether a particular factor

is worth measuring;

• Is the entity that +e +ant to ,eas'&e di&ectly &elevant to the goals of the

p&oecto&ganisation7 <uppose you are developing software that is intended to

run only on one single platform# then any measure of portability is not relevant to

the project. %n the other hand# if the stated goal is that the product should run on

multiple platforms# one of the metrics could be the time taken) effort involved in

porting the product from one target platform to another.

• Is the entity easily o& Fnat'&ally1 ,eas'&able7 *deally# there should be no extra

effort involved in taking the measurements. *n a practical sense# the overheads

incurred on carrying out the measurements should not be high. 6fter all# the

measurements are done to identify problem areas and take corrective action. *f the

process of taking measurements itself is too complex or adds substantially to the

overheads# then the benefits gained will also reduce substantially.



• Can +e 'antify the cost and benefits of ,eas'&ing7 *t is important to do so in

order to ensure that the benefits exceed the costs incurred on measurements. %ne

of the major challenges in any metrics program (discussed in more detail in

<ection . is the perception that measurements are overheads that give rise to

bureaucracy. Luantifying the costs and benefits in the context of their relevance tothe projectOorganisation goals certainly helps in combating such negative

perceptions.

• Is the entity cont&ollable7 *deally# we should measure only those things which

allow us direct or indirect control over their effects. Hor example# if we were to set

up an office in the <an Hrancisco ,ay 6rea# it would not be worth our while to

measure the fre$uency of earth$uakes in that area because we know that the area is

prone to earth$uakes and that any past data cannot pinpoint the time of the next

earth$uake (and anyway# we have decided to have an office in that area for

business reasons.• Can yo' affo&d NO$ to ,eas'&e the entity7 Go matter how easy it is to measure

an entity# one should priorities and measure only those things that absolutely have

to be measured. There are several reasons for this. Hirst of all# every measurement

comes with a price tag and adding new measurements would just add to the cost.

<econdly# there are just a few things that when measured and controlled

appropriately# would improve significantly. %ther things# at best# would show

marginal improvement. &ence the measurement program should be limited to

measuring only those things which when controlled# produce the best bang-for-

the-buck.

B"! SE$ $ARJE$S AND $RACK $*EM

*n the previous step# we identified what we want to measure and how this

measurement is related to the project) %rganisation goals. The next step is to ensure that

certain targets are set for these entities. Hor example# in a software project# where the

criteria for success are time-bound SeBveries# a metric may be the /deviation from the

scheduled time to the actual time taken. This is called schedule variance in the project

management parlance.

&owever# it is not enough to say /we will track schedule variance as a metric. *t is also

important to set some targets which reflect the degree of success of the project. These

targets should then be understood by all the constituents who are concerned with

achieving these targets.



>hile setting these targets# it is important to ensure that the targets satisfy the

<=65T criteria. <=65T is an acronym for <pecific# =easurable# 6ggressive yet

6chievable# 5esults-oriented and Time-bound.

Specific( The target should be specific in terms of numbers. !.g.# /the project shall be

delivered no later than within two days of the scheduled date. *n particular# it is

important to avoid targets like /this project should be completed as soon as possible /we

should have as few defects as possible.Meas'&able( The value of the target should be measurable unambiguously and

interpreted consistently. There should be no disputes on the value or how it is arrived at.

6n example of a measurable target is /keeping the number of bugs in the product single

digits. 6n example of a target that is not measurable is /what the customer feels about

our product.Agg&essive yet Achievable( The target that one is trying to achieve should not be utterly

impossible to achieve (this will only discourage and demotivate people# nor d it be too

easy (this will not be challenging and hence will not motivate the people enough.

6n example of a target that is aggressive and yet achievable could be /achieving a speed-

up in the delivery time for each cycle without compromising on $uality goal that is not

aggressive is# /competition is delivering this feature in three months ? we will take six

months)Res'lts:o&iented( The measurement you are taking reflects a symptom. >hat you to

convey is how this measurement of the symptom has an impact on the final business

outcome or project outcome. Hor example# when you measure time taken a bug and thenumber of bugs over time# and find that one or both of these are decreasing# you can

show how this measurement results in lower re-work costs and make the constituents

realize the eventual benefits of what they are doing. This puts ownership of the results in

the hands of the constituents.$i,e:o'nd( The targets should be achieved within a given time-frame. *n the era of the

/*nternet Time# this time-frame is becoming ever shorter. Targets that do not have a

time-frame associated with them do not serve any purpose at all. 6n example of a time-

bound target is /5educe the bug count to AK of the current values in next three months.

*n order to ensure that the goals and targets are time-bound# it is important to avoid phrases like /as soon as possible or /at the earliest opportunity in the statement of

targets.

A J&eat E3a,ple of a S,a&t Joal

%ne of the best examples of how to set <=65T goals was 3resident Nennedy9s inspiring





re$uirements and estimates. 6lso# with such a track record# the prospects and customers

would feel more comfortable doing business with the organization.

=uch as we would like to achieve consistency and predictability# there are always

variations. These variations are a result of the inherent human nature (which is so

prominent in software# unclear understanding of the re$uirements# changing technology

and any other unforeseen reasons.

Cariability refers to how the key metrics vary over time or over different projects.

6s we discussed in the previous paragraph# certain amount of variability is inevitable# but

it is important to ensure thatB. The variability is within /reasonable limits (called ;ower Control ;imit or M:M

and <pper Control ;imit or D:M and hovers round an expected mean value.2. >hen the variability exceeds these limits# we should understand exactly why this

happens and how we can minimize such a wide variation in future.

&ow do you arrive at the specific values of D:MOM:M and the mean value of a metricF

• @ou can benchmark yourself against the industry norms. 6s the ultimate objective

of metrics is to ensure you stay competitive# it is necessary that you do not fall

short of the prevailing industry norms.

• @ou can examine your track record in similar projects (if you have got this data.

This can give you some guidelines as to your potential# capabilities and

limitations.• @our management may simply state the re$uired value of metrics as targets to

shoot for (after all# how did 3resident Nennedy choose end of the decade as the

time-frame to land on the moon).Met us analyze each of the above concepts in detail with an example;

<uppose you are in a software maintenance project fixing bugs in a product. *n

addition# also suppose that on an average# you expect to fix (or produce a response to a

bug within " days. ,ut for no bug should the response exceed a maximum of days (or

else you reckon there would be some customer dissatisfaction impact. @ou have also

estimated that you would take a minimum of one day to fix a bug# based on your

estimates of time taken to set up the bug situation# reproduce the problem# find a fix#

make the fix and distribute the fix.

Dnder the above assumptions# any bug-fix time should ideally fall between a

;ower Control ;imit (M:M B day and an <pper Control ;imit (D:M of days# with a



mean of " days. The meaning of these limits is that any variation of time to fix a bug

within the range of B day to days can be construed as normal. Hor example# if a set of

bug-fix times follow the distribution in Hig. ."# we can see that all of these values fall

between the D:M and M:M. <uch a distribution of bug-fix times seems to be an

/acceptable distribution as the bug-fix times seem to be within expected and tolerablelimits.

%i# , :istribution of a metric between <C; and ;C;

Met us consider a distribution of bug-fix times as shown in Hig. .'. Hrom the

figure# it is clear that most of the values fall in the range of D:M and M:M. ,ut there are

two that took more than days and three that got fixed in under half a day. >hen we

consider that the total number of observations is 2A# there are BAK that ar above the D:M

and BK below the M:M.

%i# & ! small percenta#e of values lyin# outside <C;I;C;

!ven though the distribution still tends to be skewed towards values withinacceptable ranges# it is very important to look at the instances where the value falls

outside the D:M O M:M limits and understand the root cause of why such a deviation took

place. Hor example# if you view the cases where the bug-fix time took more than days#

you may find that in those instances# any one of the possibilities listed in the first column

of Table .B could have been the cause;



.able 1 "ossible 4oot Cause !nalysis for Observations in %i# &

The purpose of doing an analysis such as above is that the corrective actions

needed to remove the variability and to smooth out the curve could be very differentdepending on the root cause. 6s can be seen from the second (/:orrective 6ctions

column# action needed to minimise the recurrence of a similar variance in future is very

different. <uch analysis and corrective action constitutes defect prevention and leads to

continuous improvement.Met us consider two more scenarios of behavior with respect to the above example;

Met us suppose that the 2A observations you made for the bug-fix time follow the

distribution pattern of Hig. ..



%i# ;ar#e percenta#e of values above the <C;6s you can notice from the graph# most of the bugs took more than BA days to *

whereas your D:M target was days.

*f you have achieved the target of days consistently in the past# you should

examine what has changed so suddenly to take this number to ten days and aboveF &as

there been a greater attrition resulting in a larger number of new (and not fully trained

employeesF &as there been a sudden increase in complexity of the productF >as there a

new version released to the market that caused a sudden increase in the inflow rate of

bugs that caused the fall in service levelsF*f this is the first time that you measured the targets# perhaps# your initial

expectation of what D:M O M:M should be is not correct. *f you have not received adverse

customer comments# perhaps# striving for -day turnarounds is an overkill and you can

make do with# say# a seven day turnaround# with no adverse customer impact (you can

then divert the extra manpower gained by increasing the mean fix time by 2 days into

activities that do have a more serious business impact. >hatever be the case# as the

number of values that fall outside the D:MOM:M has increased# the corrective action

should be more urgent and is likely to result in more significant overhaul of the targets or

the environment.

*n a final scenario# what if most of the values for bug-fix times are under half a

dayF *t probably means that by setting a target of B? days# you are not setting an

aggressive enough target for the organisation to shoot for. Thus# over the long term# this

could result in a decrease in motivation and productivity of the organisation.%ne of the main purposes behind gathering and analysing metrics is to ensure that

the organisation stays ahead of competition through continuous improvement. ,y



identifying the root causes of those instances of apparently out-of-range values and

employing corrective measures for the same (as listed in Table .B# the organisation can

remove most of the impediments and thus set the scene for continuous improvement. 6s

the variability of metrics gets minimised# you will find three patterns emerging in the

graphs of a continuously improving organisation;• The number of data points that fall outside the M:M-D:M range is reduced. This

implies that more of the data points are within acceptable ranges. Hor those

exceptional cases that do fall outside the D:M-M:M range# there is a clear

understanding of the root cause for their falling outside the range.

• The gap between the D:M and M:M is reduced and this means the metric lies

within a much narrower band. &ence the predictability of the metric increases.

• The acceptable level of performance or the mean value of the metric lies

continuously improving. The reason for this is that as you identify and remove

root causes of problems# you are weeding out the problem areas one by one andhence are providing a more conducive environment for continuous improvement.

>e conclude this section by summarizing the above discussions in the following

salient points;

=inimising variability in the chosen metrics is critical for business success

!ach metric is characterized by its mean value# upper control limit and lower

control limit

Hor those values that fall outside the D:M * M:M range# it is important to

understand the root causes and take corrective action to reduce the occurrence of such out of range data points in future

6s the next step in improving predictability# one should try to reduce the D:M-

M:M gap (i.e.# make the points fall under narrower ranges.

Hinally# in continuous improvement# one should seek to bring about improvement

in the base numbers itself# while keeping variability under control.

B"? AC$ ON DA$A

>e have already covered this indirectly in the previous section. ,ut this step is so

important and easy to miss# that we would like to draw one9s attention to it once again. *tis very tempting to collect a lot of data# plot nice# colorful graphs# but not take corrective

action. The job of metrics does not end with metrics collection and analysis. *t begins

there. The real culmination of the process is when the data is acted upon and corrective

action taken# resulting in continuous improvement# is seen. The importance of this step

emanates from three different (but related factors;



B. =etrics collection and analysis is an expensive and skilled-labour intensive

process. The benefits accrue only when corrective actions are taken. &ence# if we

do not act on the data# metrics activity becomes just a costly exercise with no

benefits.

2. :ontinuous improvement is absolutely essential even if we want to star where weare (let alone improve our position in the market. *f the findings from metrics

analysis are not acted upon# the organisation is unlikely to achieve continuous

improvement.". 6ll the constituents do end up putting in an extra effort into gathering these

metrics. *f they do not see any action or get any feedback# their faith and

willingness to gather and supply meaningful data will diminish. >e will cover

more of these human angles in the next section.

>hen we say /6ct on 0ata what we mean is# /take conscious business decisions

based on the data and the analysis of metrics. <tatus $uo (or not taking any action is

acceptable so long as it is a conscious decision and is justified by what you see in the

metrics. 6lso# we would like to emphasize that the metrics data should be used for

making business decisions and not just some fringe decisions that are not core to the

success of the business. 6t times# making business decisions based on metrics could be

tough# but just for the sake of acting on the data# one should avoid the mistake of doing

some superficial fixes on non-core issues. *n the long run# such an action (of superficial

fixes would erode the credibility of the metrics initiative.

The specific actions we would recommend are;

• 6sk $uestions like />hat if# />hy not# /<o whatF# etc. Hor example# />hat if

the mean time to respond to a bug goes up from days to 8 daysF >hat is the

business impact (preferably $uantified in U terms.

• 6rrive at root causes1 don9t be satisfied with re-stating the symptoms. This point

was discussed at length in the previous section.

• 0ecide whether the resultant action is a process change (e.g.# how to route a bug to

ensure that it gets fixed in the fastest time or a product change (perhaps a feature

is bug prone and one may consider modifying the product with respect to thisfeature or no change (i.e.# status $uo.

• 6nalyse whether# on the basis of the changes# the current metric still makes sense.

Hor example# if you modified the process of submission of a bug to specify a

minimum set of information that must accompany a bug# then the metric of time

taken to get the minimum set becomes irrelevant.



• :omplete the feedback loop to the people who supplied the data for the metrics. *t

is important for them to know that their data was acted upon and decisions were

taken on the basis of such supplied data.

B"@ %EO%LE AND ORJANISA$IONAL ISSUES IN ME$RICS %ROJRAMS*mplementing a successful metrics program does re$uire whole-hearted co-operation

from all levels in the organisation. &ence people issues play a very significant role. *n

this section# we will address some of the common people and organisational issues that

are important for the success of a metrics program.

Mana#ement commitment is essential for the success of metrics; The top management

should walk the talk and demonstrate their belief in the metrics program. They should not

short circuit the metrics system. Hor example# if the D:M for the number of known bugs

in a product is A and a product under test has BAA known bugs# the top management

should not allow the release of the product. <tated more generally# the management (at

any level should not give the impression that /=etrics is for the junior folks# * am too

senior and am therefore exempt) Metrics and tar#ets should not be thrust top down; The people who are actually doing the

job should buy into the actual metrics being collected and the targets to shoot for in terms

of =ean# D:M and M:M. !ngaging the grass roots people in setting the targets ensures a

better buy-in and a better chance of success for the metrics program.

=ot shootin# the messen#er ) =etrics do sometimes bring bad news?news that the top

management does not want to hear?be it in responsiveness to bugs or $uality of a product or the features (or lack thereof of a product. *t is important that such analysis is

taken objectively and the people who actually collect O analyse the metrics are not

penalised.

%ocus on analysis of a##re#ate results—not individual performance; The success of the

metrics program lies in the $uality of incoming data. >hen people suspect that the

metrics analysis would be used in their individual performance appraisals# they tend to

get defensive and this often ends up in a garbage in# garbage out phenomenon. Hor

example# suppose you want to capture the effort for a particular product developmentactivity# you should not use the captured data to ensure that each employee has worked

for 'A hours per week. *f this is done# the employees may end changing the numbers so

that they add up to forty hours and in the process# actual information that is re$uired

would be lost.



:o not violate privacy laws in the name of metrics; The only purpose metrics should use

for is to achieve continuous improvement in the product and process $uality. 6t no point

of time should the data be used for any other type of analysis or dissemination. Hor

example# it is not appropriate to compare the average bug fix response time of men versus

the average time taken by women as such information tends go into personaldemographics.

Ma/e sure the operational issues of metrics are understood consistently by everyone;

>hile defining a metric# it is important to ensure that some of the operational details are

well spelt out. <ome of these issues are; >ho is responsible for collecting the dataF 6t

what fre$uencyF >ho will analyse the dataF 6t what fre$uencyF >ho will receive that

analysisF

B"> COMMON %I$ALLS $O 2A$C* OU$ OR IN ME$RICS %ROJRAMS

*n this section# we cover some of the common pitfalls that we find easy to succumb to in

the implementation of metrics programs.

Overdose of metrics; Thanks to innovations in technology# it is all too easy to capture

almost any information you want to capture. %ne of the biggest problems in the metrics

programs is over-engineering1 collecting of too many metrics# too often. The fact is that

even if machines do all the number crunching# finally it is the human being (the project

manager who makes the decisions. 6nd there is only a limited amount of data that he can

focus on. Hurthermore# by the A? 2A rule (<ee :hapter 8 it is sufficient to focus

attention on a few important things than on a large number of things that will have arelatively reduced impact on the final outcome. ust as in case of medicines# the

appropriate medicine has to be given in the appropriate dosage.

:ecidin# on how to measure before you decide what to measure; >e call this the /:ool

<yndrome. =ost project managers get promoted to the project manager9s role rafter a

successful stint as a /techy. They start thinking; /gee# wouldn9t it be great to write a tool

for capturing this information or that. &ence the tool for measurement designed first and

then based on the capabilities of the tool# what you measure decided later. This almost

invariably causes frustration and results in wasted efforts.

<sin# metrics data for individual performance appraisal ; 6s stated earlier# the only purse

of collecting and analyzing metrics data is to achieve continuous improvement in the

product and process $uality. <uch data should not be used for individual performance

appraisals. <uch inappropriate usage of data is likely to lead to distrust and lack of



confidence on the part of the employees and eventually affect the $uality of data that is

obtained as input.

=ot bein# fle$ible and open in metrics; =etrics are not cast in stone# nor are they

sacrosanct) 6s an organisation evolves# the significance and relevance of metrics does

change and the project managers must not be blind to this fact. =ore often# the choices of

metrics (and the values thereof are decided early in the game but no conscious attempt is

made to validate the usefulness or relevance of the metric in the later stages of the

project. The older metrics are collected and analysed almost ritualistically. The project

managers must be open to accepting the changes in metrics and should fine-tune them as

they go along# rather than be fixated on things.

=ot allocatin# clear responsibilities for collection) analysis and reportin# of metrics;

Dsually people who collect metrics are not the same people who analyse the metrics and

present the findings. There should be clear allocation of responsibilities for each of these

activities and everyone should be aware of what their roles are. Mogistical details of how

the metrics are collected# by whom# at what fre$uency1 and similarly# the details of how

the metrics are analysed# at what fre$uency# who are the recipients of the analysis# etc.#

should be clearly understood by everyone.

=ot havin# a common understandin# of relevance and interpretation of the collected

metrics' %ne problem that the practitioners face in the metrics arena is that different

metrics are important for different parts of an organisation. Hor example# the same

metrics may not seem e$ually useful to the person providing the raw data as they do tothe person who is analyzing the data. !ach thinks he should be collecting only a subset

because that is what he finds useful. &owever# all metrics have to be collected in the

longer term interests of the organisation. Hor instance# project managers are typically

keen on ensuring that the project is completed on time with minimum overheads1 while

auditing personnel are interested in collecting data to ensure process compliance. The

$uality (or software engineering group is interested in collecting metrics for improving

estimation accuracy and ensuring continuous improvement. 5ather than leave the choice

to each party that has more focused special interests# it is important to ensure that

everyone understands the significance of all the metrics that are being collected and that

each of them has a payback. <ome of the paybacks are not necessarily immediate.

5einforcing this is critical to the success of the metrics program. <uch reinforcement can

be achieved by clear communication# leadership example# management commitment and

by mandate# if re$uired.



Metrics as a policin# activity' 6s metrics is about collecting and analyzing

measurements# there could be a nagging feeling of /,ig ,rother is watching in the

minds of employees. *t is very important to remove this feeling of being /policed at the

very start of the game. 4etting an early buy-in and involving employees in the choice of

metrics and their values# and achieving synergy of purpose among all the employees aresome of the ways by which this pitfall can be avoided.

Metrics as bein# incompatible with #ut feel' =ost /techys say they /trust their instincts

and experience more than anything else. They view formal measurements ai-d metrics as

an overhead activity and one finds $uestions like /* can9t justify it but my gut feel tells

me * am right) 6 properly conceived and implemented metrics program does not counter

intuition and gut feel. *t only reinforces them. *t is important that this is understood and

appreciated by all constituents else the metrics program will end up being viewed as an

overhead and as a non-intuitive bureaucracy.

Metrics as an 6e$tra step8 after the 6actual wor/8' =etrics collection should ideally be

a natural by-product of work. >hen this fact is not taken into account while designing the

metrics# it becomes an overhead. 3eople then start complaining that metrics is taking too

much of their time and that they can either meet project deadlines or produce metrics) *t

is important to set the proper infrastructure in place so that the metrics progress is tightly

integrated into the project life cycle activities and does not involve additional steps.

=ot closin# the feedbac/ loop fast enou#h' The results from the analysis of metrics and

the conse$uent action taken should be communicated to the constituents within areasonable time-frame. %therwise people tend to lose faith in the system and also# the

information and analysis may become unusable O inapplicable if there is a significant

delay. The thumb rule should be# /provide the analysis and recommendations at a

fre$uency at which the user can use and digest the information meaningfully.

B"; ME$RICS IM%LEMEN$A$ION C*ECKLIS$S AND $OOLS

Though the points we discussed in the previous section are pretty much a matter of

commonsense# it is extremely easy to miss out one or more of them at times. &ence# we

have tried to create a sample checklist that can be used to set up and monitor an effectivemetrics program.



Chec.list fo& a S'ccessf'l Met&ics %&og&a,

Choice of Met&ics

&ave you defined end-goal metrics for your project by which you can

measure the business success of your projectF

0o the end-goal metrics satisfy the <=65T criteriaF

&ave you defined the D:M and M:M for the end-goal metricsF

0o the end-goal metrics tie up with the organization9s visionF

&ave you defined the in-process metrics that enable you to make anobjective health check on the progress towards the end-goal metricsF

0o the in-process metrics satisfy the <=65T criteriaF

&ave you defined the D:M and M:M for the in-process metricsF

&ave you ensured that there are neither too few nor too many end-goalOin-

process metricsF



&ave you defined who is responsible for collection of metrics and what is

the collection fre$uency and mechanismF

&ave you defined who is responsible for analysis of metrics data and what

is the analysis fre$uency and mechanismF

&ave you ascertained the logistics and recipients of the results of theanalysisF

&ave you $uantified the costs associated with measuring# recording and

analyzing the metricsF

&ave you ascertained the availability of tools# infrastructure and other

resources needed to effectively carry out the metrics programF

&ave you ascertained the intervals at which you plan to re-visit the validity

of the metrics and redefine them if necessaryF

Ope&ational Iss'es 0o you notice any variation in the parameters (collection O analysis

fre$uency# measurement# overheads# etc. from what you planned and whatis actually taking placeF

*f there is such a variation# do you believe you should revise the original

estimates or should you tighten the screws on the executionF

&ave# you identified what kind of changes are taking place in

productsOprocesses because of metricsF

&ave you been able to $uantify the benefits of such changes that result from

the metrics programF 0o the benefits exceed the actual costsF *f not# have you planned for any

correctionsF

&ow many of the metric values lie outside the D:MOM:M boundariesF

&ave you done any root cause analysis for such exceptionsF

*f allOmost of the values are within the D:MOM:M boundaries# have you tried

to revise the estimates to be more aggressiveF

*',an Iss'es

*s there a clear management commitment to the specific end-goal and in-

process metricsF

0oes the top management understand and commit to the resources needed

for administering the metrics programF

0oes the project team realise the importance of their work and how it

relates to the metricsF



0oes the project team perceive the metrics activities as cumbersomeF

&ave you ensured that the metrics program information is not misused for

appraisals or for other inappropriate purposesF

&ave you ensured that the feedback loop is closed with the people who

supply the data in a time-bound mannerFCHAPTER .

SO/T0ARE CO1/&(2RAT&O1 MA1A(EME1T

/:hange is the only constant. 6nonymous

>hat is software :onfiguration =anagement (<:=F R Typical problems related to

:hange :ontrol R ,asic terminology and concepts in <:= R 3rocesses and activities in

<:= R <tatus 6ccounting R :onfiguration 6udit R *mpact of 0istributed teams on <:=

R =etrics for <:= R <:= tools and automation.

?"# IN$RODUC$ION

>e begin this chapter with a review of some of the characteristics of the software

development environments that motivate <oftware :onfiguration =anagement in section

we introduce some basic terminology used in <:=1 sections E.2# E." and E.' covers the

basic processes of <:=1 section E..# we address some issues in <:= that arise from

geographically distributed development teams. *n section E.E# we discuss the metrics that

apply to <:= and in section E.8 give an overview of the re$uirements of the <:= tools.Met us take a look at some of the characteristics of software development in

today9s product development organisations;

>rea/-up of products into components and inter-component dependency' Today9s

software products are broken down into multiple inter-related and inter-dependent

components. 6 change in one component of a product may have a ripple effect on other

components of the product or even on other products (even though this is not a desirable

situation. :onsider the example in Hig. E.B where there are three products; J# @ and Q.

3roduct J is made up of two components?JB and J21 product @ is made up of three

components?@l# @2 and @"1 product Q is again made up of two components?QB andQ2. Met us also assume that the component @B has a dependency on component Jl and

the component Q2 has a dependency on component @". The dependency?represented by

an arrow line in the figure?can be in the form of a source dependency (e.g.# include

files or in the form of an object dependency (e.g.# 0MMs. *f we do not have one



consistent public view of Jl and @" then this will mean a significantly increased

maintenance load on the components.

%i# ?1 "roducts) components and dependencies

Co-e$istence of multiple versions of a product' Gormally# each software product reaches

the market in different versions1 each version likely to be more feature-rich and more

powerful than the earlier versions. =ost often# multiple versions of the same product are

found in the market at the same time. The reason for this is that not customers can afford

(or be willing to go in for the latest version of a product immediately on its release. 6nysuch version upgrade may be accompanied by an increased cost or new hardware

re$uirements or upgrades of other software (e.g.# the %perating <ystem or laborious

testing of applications built on the o releases. &ence# it is common that multiple versions

of the same product will co-exist in the market. >hen such multiple versions exist# it is

important to be able unambiguously identify the components (source files# libraries etc.

that make each version. !$ually important# when a customer reports a problem in a

version# is the developer9s ability to recreate an environment wherein he can trace the

problem from the execution to the corresponding source files that were used in building

that particular version of the product.

Simultaneous or conflictin# wor/in# by multiple people on the same wor/ product' 4iven

the size and complexity of today9s software products# it is almost guaranteed that many

people will touch the same code multiple times during the product9s lifetime. *t is also

highly likely that more than one developer would attempt to touch the same code to fix

different problems (or even the same problem. *t is therefore important that the updates



of one developer do not get overridden by updates from other developers. This scenario is

very similar to synchronising updates in multi- user database management systems.Simultaneous support for multiple hardware and software platforms for a product' *n

today9s open standards era# the same software is expected to run almost identically on a

variety of hardware and software platforms. !ven though the actual product end behaviour may be identical on multiple platforms# there is likely to be a certain common

code (that defines the basic functionality# as well as a code that is specific a given

machine or an environment *t is important that the environment allows a good balance

between sharing and isolation or separation# i.e. sharing the common e and isolating the

code specific to the environment.

*n the above context of supporting multiple platforms# multiple products# multi- versions

worked upon by multiple people# <oftware :onfiguration =anagement becomes very

important.

?") SOME ASIC DEINI$IONS AND $ERMINOLOJ0

>e will take a somewhat round-about route in giving some definitions. >e will

first describe# rather than define :onfiguration =anagement1 then define what a

:onfiguration is and follow it up with a definition of :onfiguration *tem.

2hat is config'&ation ,anage,ent7

:onfiguration management is the combination of software# services and processes

enable each developer to re-create and use the exact set of files and environment for a

specific software product O version O platform. *t is also a mechanism to work environments of the individual developers# ensuring that none of the and confirmed

changes get lost.

2hat is a config'&ation7

6 configuration is a set of related items (also known as Confi#urable Items or

Confi#uration Item satisfying the following criteria;

The configuration is uni$uely identifiable by a Confi#uration Id

The items are consistent# i.e.# the items work with one another in a way that is well

understood The set of items is re-creatable as a unit

2hat is a config'&ation ite,7

*t is an elementary part (usually a file of the configuration that must be

*dentified or versioned; !ach item has a version number that characterizes its

change history.



Tracked; 6ny activity on the item is tracked

:ontrolled; 6ny update to the item goes through a well-documented and

controlled process.There are a few more definitions needed but we will add them as we encounter them in

the next section on :onfiguration =anagement 3rocesses.

Is the Concept of Config'&ation Anything Radical o& Ne+7 Got really) The concepts of :onfiguration and :onfigurable *tem are pretty muchcommon place. Met us give an example from an end user9s perspective that we are allfamiliar with.Met us assume that you are buying a computer that comes with some shrink- wrappedsoftware. The configuration you# as a user# would be interested in would include the

following; The computer system itself# with the appropriate memory configuration?hard

disk capacity# etc.

The appropriate peripherals like the mouse# keyboard# multi-media kits# etc.

The correct version of the operating system and other system software that should

go with the above system

The appropriate documentation that goes with all of the above.

The version of the shrink-wrapped software that should go with the above

hardware and system software

The documentation for that version of the shrink-wrapped software (e.g.# the

*nstallation 4uide# Dser9s 4uide# etc.

Hrom the point of view of the end user# he has to get the right configuration (or combination of each of the above# else the system may not be fully functional. Hor example# if one were to buy a machine that runs on the Minux operating system andinstead gets the shrink-wrapped software version for the GT operating system# it won9twork) 6lternatively# if one gets all correct versions of the software but gets the wrongversions of the documentation# the system may not be usable)

*n order to ensure that the end-user gets the right configuration# i.e.# the correctcombination of the hardware# system software# shrink-wrapped software anddocumentation# the manufacturer must have a proper configuration management systemthat ensures that the right components ? he it hardware# software or documentation?are put together.



?"5 $*E %ROCESSES AND AC$I6I$IES O SO$2ARE CONIJURA$ION

MANAJEMEN$

ust like metrics# software configuration management (<:= is an umbrella

activity that applies through all the phases of a software development life cycle. 6gain#

just like in metrics# where even though what one measures would be different in each

phase# the basic principles and philosophy remains the same1 so also# what one subjects to

software configuration management would be different in each phase# while the basic

principles and activities O processes of <:= would remain the same. >hat we will

discuss in this section are generic processes O steps of <:=. 6t the end of this chapter# in

Table E.B# we enumerate the possible items in each phase that need be subject to software

configuration management.The steps that constitute software configuration management are;

B. *nitial working2. ,ase lining". :hange management'. =anagement of workspaces. :onfiguration status accountingE. :onfiguration audit

>e will discuss each of the above points in the following sections and sub-sections.

?"5") Initial 2o&.ing

6lmost all life cycle activities generally starts off with an initial ad-hocism. There

is a small set of people (sometimes even just one who do the initial research andcommunication# as well as the spade work that is re$uired. 0uring this time# most of the

files are held privately by the individuals. <haring is need-based and is often

accomplished by across the hallway shouts. There is absence of certain formalism in the

communication and sharing of files and resources. This informality helps in being

responsive to $uick changes that are so characteristic of this phase of the life cycle. 6lso#

during this phase# very little of the work done by this group is made public. The product

or the component being developed is put to use only internally. Hor example# if the

product being developed is a set of 63*s (6pplication 3rogrammer *nterfaces that enable

other products to call the services of this product# such 63*s are not yet exposed fully to

other products. 6ny testing is done by local simulation using internally developed test

harness rather than by exposing this product to other groups.!ventually# the team that is working on this phase of the product comes to the

stage where they (in conjunction with other deciding authorities decide that the work

product and all the items under development are in some reasonable state of stability and



that others can start using this work product under development. 6lso# the other groups

(or products might reach a situation where they absolutely need access to the services

provided by this group (or product. *t is at this point of time that the work product passes

on to the next stage of <:= activities called base lining.

?"5"5 aselining

,aselining is the process by which a given set of items formally become publicly

available in a standard location to the people who are authorized to use it. The collection

of work products (files is identified as a configuration and given a configuration id !ach

of the individual files (or configuration items# to use a <:= terminology is associated

with this :onfiguration *d# given a uni$ue version number and stored in a standard

location as a uni$ue file. Hrom then on# no one is allowed to erase or modify this file at

this location. 6ny changes or additions get stored in separate files with different version

numbers in different locations. 6lso# from then on# even such additionsOchanges cannot be

carried out in an ad-hoc fashion1 they have to go through formal and well-defined review

and approval cycles. The process of baselining also establishes the appropriate authorities

who can review and * or approve any further changes.

6s can be seen from the above discussion# baselining involves the following

activities;

• /Hreezing a current version of the product and its constituent elements (like

source files# makefiles# etc.

• 6llocating a configuration id to the entire configuration

• 6llocating version numbers and standard locations to the constituent elements of

the configuration

• <toring the approval authority information

• Hinally# broadcasting the above information to the concerned people.

The vehicle used for these storage and communication purposes is the

:onfiguration =anagement 5epository (or 5epository for short. The repository is the

central place that contains all the configurations that have been made public along with

their related items# the authority levels# etc. *n other words# it contains information about

all the baselined items. %ne can view this as a database of all configurations. Therepository also records all the :hange &istory information (as discussed in the next

sections. The process of baselining (or re-baselining for a change is also referred to as

check-in.*t is interesting to note that by the process of baselining# the original owners of the

configuration items are in a sense relin$uishing some of the control and flexibility they



had to make any changes as and when they felt like and are# instead# voluntarily imposing

some structure and process in their functioning and that of the others to ensure that

further changes are controlled. This extra care is re$uired because the items could be used

by other people and in ways not fully visualised by the original owners# the impact of the

changes could be more significant than what the original owners could have imagined.*t is not necessary that all the items being worked on by the original owners get

baselined. Hor instance# there may be some temporary files# internal test harnesses or

email correspondence that might have been used and would therefore serve no purpose if

shared by other users. &ence these items do not get baselined.

So,e C&ite&ia fo& Choice of Ite,s fo& aselining

*n general# baseline those items that are;

needed to re-create the configuration (e.g.# source files# specific versions of compilers and linkers

needed for creation of objects in the next phase of life cycle (e.g.# re$uirement

specs are an input to the design phase

needed to establish the correctness or acceptability of the outputs from that phase

(e.g.# test logs from the testing phase or in general# any Luality 5ecords

6 popular misconception is that only the components that are directly involved inthe configuration need to be baselined. Hor example# during the development phase# onlythe source files are baselined. *t is e$ually important to baseline the environment aroundthe source files ? this includes the %<# the utilities# the compilers etc.

>hat are the items that usually need not be baselinedF

6nything that is transient only to the builderOdeveloper (e.g.# e-mail

correspondence

6nything that is initially designed as a place holder for future fillings (e.g.#

harnesses to be later filled up with the appropriate content

6ny intermediate files (e.g.# the myriad versions with the /printfs or

/<ystem.out.println of the temporary variables)

?"5"8 Change Manage,ent

6fter any configuration item gets checked-in and is baselined# changes are bound

to take place. These changes can come about because of several reasons?changes in

re$uirements# changes in design or architecture# changes in the platform or environment



or simply changes caused by the initial optimism that is so typical of the programming

fraternity)The objective of change control (and indeed of <:= is to ensure that changes are

well thought out and done consciously. %ne should be fully aware of all the implications

rather than make ad-hoc changes. &ence the change control process is further subdividedinto;B. :hange re$uest2. :hange review and authorization". :hange execution in a workspace'. :hange check-in and re-baselining

?"5"8") Change Re'est

6t some point of time after baselining and when the product is in use# someone

discovers there is a need to make a change in some of the items. <uch a need can be

caused by any of the reasons mentioned in the previous section. >hen the need for achange is realised# the person who realises such a need (possibly the person who also

makes the change raises a Chan#e 4e(uest The change re$uest documents what the

change is# why the change is needed# what items would be affected by the change# a brief

description of what changes would be made on each of the items and (in the author9s

opinion what the impact of this change would be on other items as well as on resources.

<ometimes the change re$uest may originate from someone who knows what the

change should be from a business perspective but may not be aware of what the

technology impact of the change is (i.e.# what files would need to be changed# whichother modules would get impacted# etc.. *n such a case# it is important that the

technology impacts are also brought to light by someone before a decision is made

implement this change.The change re$uest gets evaluated by the 5eviewO6pproval 6uthority in the rxt

step.

?"5"8"5 Change Revie+App&oval

%nce the change re$uest# with its justifications# is raised it goes to the

reviewOapproving authority. *n this discussion# we have assumed that there are different

review O approving authorities for different products O configurations. 6nother variation of

the same model is that all the change re$uests in an organisation go to a Confi#uration

Control >oard) which performs exactly the same functions as described below.The review O approval authority reviews the change re$uest from three

dimensions; Gecessity# 6ppropriateness and *mpact.



=ecessity' This dimension establishes whether a particular change is re$uired at all1 what

business or technology change warrants this change re$uest1 does this change re$uest

arise from a genuine re$uirements change or is it one of those /cool things someone

wanted to do with no business reason to back it upF *n essence# the necessity dimension

ensures that the change re$uest is not a /feature creep.

!ppropriateness' &aving ascertained that the change re$uest is necessary and genuine#

the Iappropriateness9 ensures that the change is carried out the right way. >hile necessity

focuses on the />hat and />hy of the change# appropriateness focuses on the /&ow.

To ascertain appropriateness# information about how the change is made (viz.# what files

need be changed must be made available. Hollowing this# $uestions such as /*s this the

best way to implement the changeF# /*s this the $uickest way to make the changeF#

/0oes the implementation truly carry out the mooted changeF# are asked to ensure that

the change is implemented correctly.

Impact' The final dimension of an analysis before approval is the impact analysis.

Luestions such as# /*f this change is made in the manner proposed# what impact would it

have on other componentsF# /&ow much effort would go into making this change and

what should be compromised to ensure that the resources re$uired for it are made

available# etc. *mpact analysis also considers the effect of other pending changes on this

change re$uest and vice versa. The impact dimension ensures that there are no hidden

surprises or side effects in implementing this change.

The checklist below summarises the key $uestions that the reviewer must ask before approving a change re$uest.

Chec.list fo& Revie+ing Change Re'ests

Necessity

&ave you identifed the re$uirements change that triggered this change re$uestF

&as the (re$uirements re$uest originated from an appropriate authorityF

*s there a documented evidence for the re$uirements changeF

&ave there been any other re$uirements that conflict with the current

re$uirementsF

*s the statement of change re$uest objective and clear (e.g.# instead of saying.

/changing to improve performance one should use a more specific statement like/removing the performance overhead caused by condition J@QF



*s this a reactive change (i.e.# correcting an existing anomaly to meet an expected

functionality or an enhancement (i.e.# adding a new featureF

&ave you (or the one who re$uested the change been able to establish any

changes in the revenue O productivity or profitability that would arise from making

this change# especially if it were an enhancement type of a changeF :an you afford not to make the changeF

App&op&iateness

&as the re$uestor of the change also outlined how he is planning to implement the

changeF

6re alternative strategies outlined and evaluated for relative merits and demeritsF

&ave you# as the reviewer# got all the information needed to validate the

implementationF

0oes the current implementation method appear to be the most cost-effectiveF 0oes the implementation method seem feasibleF

I,pact

>hat are the resources involved in implementing this changeF &ave you got an

estimate for the manpower and machine re$uirements for implementing thischangeF

0o you have bandwidth available to carry out the changeF *f not# where are you

stealing the bandwidth fromF >hat is the impact of such a moveF

&ave you got the buy-in from the implementation team to ensure that they willmake the change and under the given resource constraintsF

>ill this change upset the apple-cart for any other re$uirements or change in

progressF

>hat is the impact of not making this changeF

&ave you considered the run-time ramifications of making this change (e.g.# if you

are making a change to an algorithm# have you considered the memory- performance tradeoffsF

?"5"8"8 Ma.ing the Change( 2o&.spaceChec.:o't and Chec.:in%nce the change re$uest has been approved# the next step is to make the actual

change. 6s discussed earlier# it is likely that more than one developer feels there is a need

to make changes to the same item (possibly to fix different problems. *n order to ensure

that no changes get lost or over-ridden due to other changes# there is a need to serialise

the changes. The situation is not very different from that of a multi-user database

management system when two users are concurrently trying to date the same record.



<uch updates must preserve the 6:*0 property. 6:*0 stands for 6tomicity# :onsistency#

*solation and 0urability. *t is common that a change re$uest modifies multiple files. *n

such a case the changes to all the files list take place as one unit. This is referred to as

I6tomicity9. The other side of the atomicity is consistency ? the updates start with a

consistent state of the repository and leave the repository in another consistent state ? i.e.# there are no contradicting or incomplete records in the repository. >hen several

changes are taking place to the same file(s# the final result should not be dependent on

the se$uence of updates. *f there were such a dependency# then validation of the :hange

5e$uests become much more difficult. <uch invariance from the se$uence of operations

is called *solation. Hinally# once the changes are made and Icommitted9# they should be

permanent. The changes cannot be undone. This is what we mean by 0urable.The mechanisms to ensure the above properties of updates are 5or/spaces and the

concept of :heck-outO:heck-in# as illustrated in Hig. E.2 and the explanations below. The

developer has to make the changes needed and test the changes to ensure they areworking fine and as per the expectations. *n order to do this# he needs an environment in

which he can build and test the objects re$uired. This environment should be exactly the

same as the one on which the original baseline was built# with the sole exception of the

objects that are actually undergoing changes. <uch an environment is called the

5or/space

%i# ?* 5or/spaces) chec/-out and chec/-in

The workspace replicates the environment in which the developer can build

product under the same conditions in which the corresponding baseline was built. The

workspace allows read only access to all the objects needed to build and test the product.

*n addition# the developer is also provided with a private copy of the files he intends to

change. *n order to ensure that no two users are making changes to same file at the same



time# a file has to be checked-out from the <:= repository before it can be copied onto a

workspace and changes made. The check-out process involves the following functions;

The <:= system ensures that none of the files re$uested for by the user have been

checked out from the repository. *f any or all of the files that the user re$uested in

the current change re$uest have been checked out# then the current check-outre$uest is denied.

*f none of the items in the current change re$uest have been checked out# the <:=

system marks them as checked out# assigning a uni$ue transaction id for this

check-out. Mater# the re-check-in of these items has also to take place together as a

transaction.

Gow# the developer has an environment similar to the one at the time of

baselining1 super-imposed on which are the files he is changing. &e makes the re$uired

changes# builds the products# in the workspace and carries out flue necessary tests (againin the workspace to ensure that the change accomplishes what the change re$uest had set

forth to do.6fter he is satisfied that the change implementation matches with the original

intent of this whole exercise# it is very important (and often forgotten) that the person

making the change ensures that the details of how the changes were made (or what

changes were made are documented within the items that are changed. This is called in-

line chan#e documentation history and should# at the least# include tails of why the

changes were made# when they were made# who made the changes# and a brief

description of what the changes are. *t would also be a good idea to give local comments#close to the actual lines in the files that got changed.

6t this point of time# the change process enters the re-baselining or the re-check in

phase

?"5"8"! Re:baseilning and Re:chec.:in

The checked out items# when changed and tested# are ready for re-baselining. 6t this

time# the developer checks-in the files he had checked out earlier. This re-check-in (also

called re-baselining achieves the following purposes;

6 new copy of the checked out items is created with an updated version number.

The items that were marked as /checked out are marked /free# thus clearing the

way for other people to change the files if their change re$uests are approved.

This completes the cycle that actually carries out an approved change. The <:=

infrastructure ensures that even with multiple changes that are inevitable in the software

development life cycle# everyone gets a consistent view of the latest files and. at any



point of time it is possible to re-create the configuration as it existed at a certain baseline.

*n the next sections we will cover two of the housekeeping functions of <:=?

:onfiguration <tatus 6ccounting ant :onfiguration 6udit.?"8 CONIJURA$ION S$A$US ACCOUN$INJ

:onfiguration <tatus 6ccounting refers to dissemination of information about

changes in configuration that have taken place or are in the pipeline. *n large

development projects# it is $uite possible that the developers become so focused on their

specific enhancements or bug fixes that the big picture gets lost and no one knows the

overall effect of all the changes. This results (among other things in unanticipated side

effects and in the implementatioeB diverging from the re$uirements. <tatus accounting

provides a mechanism to maBc sure that everyone is in sync on the changes and their

impacts. ,y storing all tV change re$uests# reviews# approvals and the actual changes

themselves in a database and using the decision support and $uery tools of the database#

answers are obtained for $uestions such as the ones below and disseminated to the people

concerned.

• >hat were the changes made on a specific module or an itemF

• >hy were the changes necessitatedF

• >ho made the changes and whenF

• >hich of the changes were re-works of previous changesF

• >hat were the costs incurred on each change re$uestF

<uch reports are generated periodically as well as on an event driven basis. Dsually

whenever a change is re$uested# approved or carried out# some of these reports are

generated so as to provide a transaction snapshot of the specific change. *t would also be

useful to take such reports to key events like the ones held soon after before a major

release. The periodic reports provide a more pro-active and give view of all the changes

and would enable the management to track the problem areas or those areas that have

been change prone. This can then lead to further cause analysis and correction# (of why

the changes are re$uired such as change of the algorithm# data structures or the

architecture (or assigning better trained people for more change-prone areas to minimize

changes.

?"! CONIJURA$ION AUDI$

6n audit is a means of sampling various representative instances and ensuring

process compliance in these instances. *f the sampling is sufficiently random and done

reasonably fre$uently# by laws of statistics# we can ensure compliance in a majority of the

instances. The principles of a sound audit?random sampling1 independent authority1

sampling for process compliance rather than individual fault-finding1 a humane# non-

policing# non-threatening approach?are all applicable in the case of a configuration



audit. 6 configuration audit is what the name implies; 6 means of ensuring Ithat

configuration management is being followed as per the stated guidelines and that all the

Luality 5ecords are in place. The process of configuration audit should take some sample

of the changes in the system (and the sample should not be skewed towards a specific

group or project and should ask the following $uestions# as well as ensure that there aresatisfactory answers to these $uestions;

0oes this change have a change re$uest# review records that document necessity#

appropriateness and impact analysisF

&as the change re$uest gone through the appropriate authorities for review)

approvalF

0oes the actual change conform to the intended change as mentioned in the

change re$uestF

&ave proper documentation standards been followed to reflect the change within

the configuration itemsF

&ave the <:= processes (like check-out# check-in and version number update

been carried outF Gote that this may also throw up some issues on the correctness

of the <:= infrastructure itself.

&as the periodic and the event driven configuration status accounting been carried

outF

?"B SO$2ARE CONIJURA$ION MANAJEMEN$ IN JEOJRA%*ICALL0

DIS$RIU$ED $EAMS

>hen the software development team is split across multiple locations# software

configuration management becomes significantly more complex. Gew $uestions arise

such as;

Should there be one copy of the SCM 4epository @called the Centralised ModelA or

multiple copies) one in each location @called the 4eplicated ModelAB *n the above

discussion# we have always assumed that there is one single repository. >ould it

still hold for a geographically distributed project teamF >ould there be

performance compromisesF

If it is in one location) where should it beB <hould it be in a place where maximumnumber of people exists or should it be where most of the key parts are being

developedF Mocating the repository in a site with the largest number of users

would reduce the delays for a majority of people1 on the other hand locating it

where most of the key parts are developed would minimise delays in rolling in

changes.



If there are multiple copies) how are they /ept in syncB 0o you do a synchronous

update (i.e.# update the multiple copies at the same time when the primary copy is

updated or do you batch the updatesF 0o you have mechanisms of compacting

the updates to reduce network trafficF

Can you consider havin# a sin#le federated lo#ical repository made up of several

mutually e$clusive physical repositoriesB This may be a via-media between a

single repository and replicated repositories. *f for example# a team in :alifornia

works on modules 6# , and : and a team in ,angalore# *ndia# works on modules

J# @ and Q# then we can have a single logical repository that has the 6# H and :

components physically stored in :alifornia and J# @ and Q components physically

stored in ,angalore.

If you are usin# the replicated model) how are conflictin# chec/-outs handledB a

user checks out in location 6# a check-out in all the other locations must B made

impossible.

:oes the communication infrastructure provide enou#h bandwidth to carry out

above synchronisation effectivelyB *t is very difficult to estimate the network

traffic that arises out of having to sync the multiple copies. This may re$uire an

estimation of how many changes would come about and at what rate what would

be the average volumes that would get changed. This also depends on how

efficient the algorithms used in the <:= tools are.

5ho #ets what /ind of access ri#hts on the SCM 4epositoryB *n the central model#

there would usually be a set of system administrators who would have the /super user rights on what to do with the system. 6s they would be co-located# it is very

easy to ensure that there is no tripping on others9 toes. *n a distributed model# this

becomes far more trickier. <hould there be administrators in each site that has the

super user rightsF *f so# how do you ensure they don9t step over each others9 toesF

%n the other hand# if you don9t have local system administrators# how do you

ensure that system level privileges are provided when neededF Hor example# if

during day time in ,angalore# a process needs to be killed on the central server in

:alifornia# how would the /local administrator do itF >ould he wake up some

administrator in the middle of the night in :alifornia) 5hat happens when the communication lin/ between any two sites #oes downB *n

the centralised model# should the team in the location where the repository does

not exist just stop the workF >hat happens to work in the other sitesF *f some

offline work does take place in other sites when the link is down# how are the



changes communicated to the central repository when the link is restoredF 6lso#

how are conflicting check-outs handledF

The above $uestions don9t have easy answers. %ften# there is no one magical

answer that fits all the scenarios. !ach project may choose its own model of how the

repository is distributed across the various sites. The above discussion would serve as a

road map for the project manager to think through all the possible issues and arrive at the

decision of what model to deploy for his project.

?"? ME$RICS IN SO$2ARE CONIJURA$ION MANAJEMEN$

<oftware configuration management is an umbrella activity in the project

management life cycle. 6s is the case with all the activities and processes# <:= also has

a set of metrics. The metrics vary with each project and each situation but in the

discussion below# we give some general guidelines that would help the reader in choosing

the appropriate metrics for hisB. &ow many change re$uests are madeF2. :ategorisation of such change re$uests by moduleOproject; This is an indication of

the stability of that module or project". &ow many change re$uests are re-work change re$uestsF This is a measure how

well thought out and well implemented the changes are'. &ow many change re$uests are enhancement change re$uestsF This is a measure

of the re$uirement stability. &ow many change re$uests get approvedF This is a measure of /red herring

change re$uests# i.e.# those changes that actually are not well thought out.E. &ow did the resources predicted at the time of change re$uest match the actual

resources expendedF This indicates effectiveness of the estimation process8. &ow many changes actually happened on the system that bypassed the re$uest-

approval processF This may be tough to get but indicates the level of discipline

and compliance in a project..

?"@ SO$2ARE CONIJURA$ION MANAJEMEN$ $OOLS AND

AU$OMA$ION

6s can be seen from the above discussions# <:= is a fairly labour intensive

operation where there is a lot of scope for human error# There are several <:= tools inthe market that take the tedium out of the <:= operations and automate a number of

functions. *n the references section# we list some of these <:= tools. *n this section# we

cover some of the functionality and concepts that most of the <:= tools provide. *n

particular# we cover B. 5epository structure and identification of elements2. %perations supported



". 6dministrative support'. Hacilities for geographically distributed projects

?"@") Reposito&y St&'ct'&e and Identification of Ele,ents

=ost <:= tools use a hierarchical tree structure to represent configurations. !ach

tree represents a particular product under development. There are several branches in

each tree1 each branch representing a particular major version of the product. The sub-

branches of a branch represent the next level minor versions within that ma version. Hor

example# in Hig. E."# we are showing a tree for a product called the /Terminal 0river

(T0. There are several versions B.B# B.2# 2.A# etc. Dnder each of these# there are

(possibly multiple minor versions. Hor example# under B.2# we have B.2.B and B.2.2.

These are usually the maintenance versions.

%i# ?, .ree structure to represent obectDproduct versions

*n each branch# there are multiple items or files. Dsually each file by itself isidentified by two attributes; its name# which is invariant across multiple releases and its

version number. The version number of each file could increase independently some files

could get changed more fre$uently than the others. *n the figure above# the file tl.h has

gone through five revisions while the file t2.c has gone through two revisions and other

files have not been changed.6ll the files that belong to a given version of the product# e.g. B.B.B.# can be

reconstructed by using the following simple steps;B. <tart from a leaf of the tree under that branch. *nclude all the files in that leaf

2. 4o higher up the tree and include the names of those files which have not beenincluded so far.

". >hen you come to the root# stop.

The final re-constructed list of files for a given version is also called the >ill of

Materials for that configuration) version.



>hen do you increment which part of the product versionF That is a convention th

varies from product to product or company to company. %ne method is;

• Hor any release with major new functionality# the first digit of the version number

gets incremented (e.g.# B.A to 2.A.• *f there are minor functionality additions# increment the second digit (e.g.# B.2 to

B.".

• *f there are simple bug fixes and no functionality change# increment the third or

subse$uent digits (e.g.# B.B.B to B.B.2.

?"@"5 Ope&ations S'ppo&ted

=ost <:= tools support the following user level operations;

:reation of a new branch

:reation of a new work space

:heck-out of elements into the work space. 3rovision is also made to identify the

elements to be checked out individually or as a group of (related objects.

:heck-in of checked-out entries

=erging of branches

?"@"8 Ad,inist&ative S'ppo&t

=ost <:= tools provide system administration support. <ome of the examples

are; creation of userids# association of privileges with objects for users# space

management (allocation# expansion# defragmentation# etc. and backup O restore. <uchadministrative operations are usually privileged operations and not available for all the

users.

?"@"! S'ppo&t fo& Jeog&aphically Dist&ib'ted $ea,s

=ost <:= tools in the market today?whether they use the :entralised =odel the

0istributed =odel?provide access to all the functions through a web browser. This in

itself provides the first level of support for geographically distributed<ome of the <:= tools allow the system administrator to define multiple sites that

would contain copies of the same objects. They then provide m sync up the multiple

copies without compromising on performance or integrity.<ome of the <:= tools also allow federated repositories wherein one logical

repository is spread over several physical repositories. The <:= then provides seamless

access to the users to access any object# regardless of the physical location of that

particular object.



<ome of the <:= tools also allow temporary /cacheing of the objects closer to

the user actually needing those objects. This provides a performance enhancement and

places less load on the network bandwidth.To facilitate better communication among the team members# some of the <:=

tools also provide mechanisms like email alerts to broadcast changes.The following table lists some of the essential configurable items that are normally

re$uired in each phase of the software development life cycle..able ?1 Confi#urable Items at :ifferent "hases of ;ife Cycle



CHAPTER 3

SO/T0ARE 2AL&T5 ASS2RA1CE

/Think of the chaos that would be created if everyone did their best# not knowing what to

do. dward :emin# in Out of the Crisis

,asic definitions of Luality?>hy is <oftware Luality *mportant?Luality :ontrol and

Luality 6ssurance?:ost and benefits of Luality?Hunctions of <oftware Luality

6nalyst +<L6 ?=isconceptions about <L6 role ? <L6 tools ? %rganisational

structure?3rofile of a successful <L6 ?=easures of the <L69s function?pitfalls in the

<L69s role.

@"# *O2 DO 0OU DEINE 9UALI$07

The answer to this $uestion depends on the person being addressed) Hrom a customer9s

viewpoint# $uality is# /how well does the product meet my needsF1 from a producer9s

perspective# $uality refers to# how well does the product function comply with what *

said it would doF99*n an ideal scenario# when the producer of a product has fully understood the

customer9s needs and has incorporated the same into the product# the product would

satisfy all the needs of the customer. *t would also perform per the specifications and

everybody would be happy. Dnfortunately life is not that simple)

• Got all the re$uirements of a customer are stated explicitly1 there are certain

re$uirements that are implied and unstated but are e$pected to be fulfilled. The

implied needs arise because the customer assumes that some of the features or

benefits are available de facto either because they are normally provided by the

competition or because of the current trends in technology. Hor example if you

were to make a television in the present day would you ever dreaming of making a

black and white television just because the customer has not explicitlyitly asked

for a color television) 6lternatively# it could be that these implied needs are so

obvious to the customer that he did not think it was worthwhile to state them) The

fact that his unstated needs are not so obvious to the producer does not cross the

customer9s mind.

• >hen you make a general purpose software that is supposed to cater to the needs

of multiple customers# it is possible that you may not be able to meet all the

implied needs of all the customers because of conflicting re$uirements. &ence

there is likely to be a gap in meeting all the implied re$uirements of all the

customers.



• !ven if all the re$uirements were stated at the time of signing the contract# it is

unlikely that they would not change over time. &ence a product that was

developed to meet the original needs may no longer be ade$uate in the context of

the changes. Hor example# if the original system was designed to handle an

incoming load of BAA transactions per second but the volumes increase and theload increases to say# AA transactions per second# it is likely that in the

customer9s opinion the product does not meet his current needs.

<o we will give the first characterisation of $uality;

Luality is about transforming as many of the implied re$uirements of the customer(s

into stated re$uirements and meeting all the stated re$uirements. *t is about minimising

the implied re$uirements and minimising the gap of unfulfilled re$uirements. 6ny such

gap is called a defect.

The above definition of $uality is in line with what is called Luality of :onformance in

the literature. There is an alternative definition of $uality called the Luality of design Hor

example# a =ercedes car is more expensive and perhaps more glamorous to own than say#

a <uzuki or a &yundai. 0oes it mean that a =ercedes is of a superior $ualityF 6ll that it

means is that the =ercedes was designed for a different market# a different budget range

and a different purpose. <tated in other words# the $uality of 0esign for =ercedes is

different from that of &yundaiO<uzuki.

&owever# for the purpose of this chapter (and for this book# we will confine elves to the

Luality of :onformance.

,ut first# let us add just one more definition to $uality. *t is not sufficient that the (implied

and stated are met just once. They have to be met time and again in a consistent manner#

if# for instance# you are a fre$uent flier# would you be happy if your airline has an on-

time record of BAAK for one month and of 2AK for the next two months# K for the next

two and AK for the last two monthsF @ou can never make any definitive plan with

confidence when the behaviour is so inconsistent) To add this dimension# we would re-

define $uality as;

Euality is about transformin# as many of the implied re(uirements of the

customer@sA into stated re(uirements and meetin# all the stated re(uirements It is

about minimisin# the implied re(uirements and minimisin# the #ap of unfulfilled

re(uirements It is about meetin# these re(uirements in a consistent and a

repeatable manner





somebody else is not an easy task and often times# not relished by software engineers

who always look for /interesting design work instead of /maintenance work.

@"5 9UALI$0 CON$ROL AND 9UALI$0 ASSURANCE

>hat is it that inhibits or reduces the $uality of conformance in software productsF 6

product may not capture all the re$uirements faithfully or the design and implementation

may not reflect these re$uirements. There may be defects at any of the stages. *t is the

presence of these defects that causes non-compliance of the actual product functionality

with the customers9 needs. &ow do we minimise (or eliminate defectsF There are two

approaches; Euality Control and Euality !ssurance

Euality Control @ECA refers to testing a product after a given phase to find out if it any

defects and in case it does have defects# to employ corrective measures to remedy thesame. 6s given in the above definition and in Hig. 8.B# $uality control is;

%i# F1 Euality control

• 0one after the product is built. &ence it is usually reactive.

• !xpensive and sometimes impossible. Hor example# for life saving devices or mass

produced devices# it may not be possible to fix a problem after it is discovered.

• %riented towards defect detection rather than defect prevention.

%ne example of $uality control is the unit testing done on each module after it is

developed. ,y the time such testing is done# considerable design and development effort

has been expended. 6ny change at this stage would result in a significant amount of re-

work.

Euality !ssurance @E!A tries to go one step further. *nstead of concentrating on post-

facto defect detection and correction# it focuses on the prevention of defects from the

very start. Luality 6ssurance is thus;



• =eant to be pro-active# i.e.# defect prevention oriented rather than defect detection

oriented.

• *ntended to catch the defects as close to the point of injection as possible rather

than let the defects trickle down to subse$uent levels. >e will discuss more ci this

in the section on <L6 success measures (<ection 8.7 below.• 6pplies to the process rather a specific end-product1 thus this can be expected to

have a wide ranging impact and benefits.

• &appens across the board and not /in line (that would explain why you f not find

a flow diagram for $uality assurance as you do for $uality control)B

<ome of the tools used for Luality 6ssurance include reviews# inspection audits

which are covered later in the chapter.

*n general# defect prevention is always better than defect detection. <o one may

conclude that $uality assurance subsumes $uality control. >hile this may be truetheoretically# from a practical view# both $uality control and $uality assurance needed to

ensure effective product $uality.

@"8 COS$ AND ENEI$S O 9UALI$0

&ow do we define the cost and benefits of $ualityF *n order to mea this# let us look

at the various components in the two scenarios; f9 without L6 and L: and secondly# with

L6 andOor L:. The situation is depicted in Hig. 8.2 (a and (b respectively.

*n Hig. 8.2 (a# let us assume that there is no basic L6 or L: done. To start with. we havethe cost of development wherein the (defective product is being &ere# somebody is

actually getting paid for injecting defects (although hopefully# unintentionally into the

system) Then the product goes out to the consumer at the next level who could be an

internal consumer (like it happens from design to development or an external consumer

(who could be the end customer. The defects are detected by the consumer. This results

in some amount of down time for the consumer and possibly causes a loss of goodwill

(the impact of which cannot always be easily $uantified. These costs are called the Cost

of :efect in Hig. 8.2. The defects then get reported to the people who actually injected

them (who hopefully are responsible for fixing them as well) These people then have todo an analysis of the root cause of the defect (called appraisal costs# make the

corrections# package the corrections and ensure that the customer gets them. This last set

of costs to do with fixing and re-packaging are also called re-work costs. Thus the total

costs are the sum of the initial development costs# defect cost# appraisal cost and the

rework cost.



Gow consider a situation where certain processes are followed and some amount

of L6 and O or L: are in place. ,ecause of the presence of proper processes that are

proven to be repeatable and consistent# the development cost would presumably come

down. %ver a certain time period# perhaps the number of defects would also come down

because of the use of standard processes and components. 6s we are doing L6 O L:# wehave an added cost component called the L6 * L: component. This cost includes the cost

of testing (L:# cost of audits (L6 and other similar costs. ,ut by expending this extra

cost# hopefully fewer (and less damaging defects e passed through to the consumer at the

next level . Thus the cost of defects would come down. 6nd as there are fewer defects to

fix and the organisation has * defined processes to deal with and fix the defects# it is

likely that the re-work would come down as well. Thus the overall cost is reduced.

The role of the <oftware Luality 6nalyst (<L6 discussed in the next section is to

Be keeping a check on the L6OL: activities so as to minimise the overall costs.

%i# F* Cost of (uality components

@"! SO$2ARE 9UALI$0 ANAL0S$S UNC))ONS

The role of the <oftware Luality 6nalyst (<L6 can be viewed as that of a

/conscience keeper of the project. The <L6 is someone with a charter and a mandate toalert the top management on any possible $uality or consistency slippage. The main

functions of the <L6 can be classified into the following five major areas; 5e$uirements

fidelity# 3rocess compliance# :hange control# minimising the gap between defect

injection and detection# and 3roduct $uality.





passed on from one phase to another# there is a significant increase in cost see inset 5hy

is it important to catch the defects as early as possible. &ence it is advantageous to catch

and rectify the defects as close to the point of injection as possible. <ome of the

responsibilities of the <L6 in this regard are;

• :onfirming that the completion criteria for each phase are defined.

• !nsuring that documentary evidence exists for such phase-wise completion criteria

that have been met.

"roduct Euality' >hen the <L6 carries out all the above process $uality related activities

and also ensures that sound design and development methodologies and standards are

established and followed# it is to be expected that the product $uality will also see an

improvement. <ome of the specific activities of the <L6. that pertain directly to product

$uality are;

• Tracking progress against any $uantitative $uality goals or process O product

improvement goals.

• ,ringing to the management9s attention any changes in the process# tools or

technology that could substantially enhance product $uality in future.

Callin# the mana#ements attention to any of the above when thin#s do not appear ri#ht'

<ome of the factors that cause the <L6 to raise a red alert include;

• >hen certain key indicators swing outside the Dpper and Mower :ontrol Mimits

ranges.• >hen deviations are observed in processes even after the project teams have been

alerted to this fact.

2hy is it i,po&tant to Detect the Defects as Ea&ly as %ossible7

Met us start with a non-software example. 6ssume that you are going to a tailor togive measurements for a suit. The tailor takes the measurements. *f he makes an error at thetime of taking the measurements and detects it immediately# he can take the measurements

again and the only extra cost would be the extra few minutes he spends in re-doing themeasurements. Gow# assume that the mistake is detected at the time he calls you for a trial. *f the mistake is not too serious# he can probably still correct it# but the cost would be your additional travel (for a possible second trial. *t is also possible that it may not be possible tocorrect this mistake) Gext# assume that the defect is not even noticed at the trial but is onlydefected when you actually wear the suit. Then the cost is prohibitively high? not only doesa new dress material have to be bought and the entire tailoring reworked# but chances are thatthe tailor has incurred a loss of your goodwill that he probably would never be able to regain)



*n software projects too# the situation is not very different. Carious studies haveshown that if it costs U * to fix a defect found at the re$uirements gathering stage - itself# thenthe corresponding cost of fixing it at the coding stage could go upto UBA1 while if the samedefect is found by a customer during his operations# the cost could be as high as UBAAA.

@"B SOME %O%ULAR MISCONCE%$IONS AOU$ $*E S9AS ROLE

<L6 W testin#' Testing is done after a product is built. The $uality of a product

cannot be enhanced simply by increased testing. Luality has to be planned right

from the initial stage of product conception and design. That is precisely where an

<L69s role adds value Luality 6ssurance is more than testing# and the <L69s

activities which are Luality 6ssurance oriented# cannot be e$uated to testing..

<L6 W fault findin#' The <L6 should not be seen as someone who simply finds

faults and nitpicks all the time. *f this happens# then the effectiveness of the <L6

and his ability to get a $uality culture across the organisation will suffer badly. The

suggestions of the <L6 should be seen as constructive and value-adding. *n

addition# the <L6 should also highlight and propagate the best practices he

observes in a project. This will not only reduce the Inegative9# fault finding image

of an <L6# but would also help institutionalize the best practices found in pockets

within an organisation.

<L6 W Mana#ements Spy' The <L6 should not be seen as the /=anagement9sspy whose only job is to keep complaining to the management. The reporting of

the <L69s findings should be transparent so that the project team (and project

manager is aware of the issues the <L6 is bringing up to the management.

<L6 is the only person responsible for (uality' !veryone in the team is

responsible for $uality. The <L6 can indicate possible areas where problems exist

and improvement needs to be made. *t is the responsibility of the entire team (and

the project manager in particular is act on the recommendations of the <L6. The

<L6 is just like a medical practitioner who does a health check and tells the

patient (the team# the project manager and the management what the symptomsare and gives his diagnosis. ust as the patient has then to follow the doctor9s

orders (the right diet# exercise# etc.# it is upto the entire project team to effect the

corrective actions.



<L6 is responsible for fixing all the problems; The <L6 is only a messenger or a

conduit that gives an update on the state of the project# product and process $uality

issues. &e is not directly responsible for fixing all the problems he has reported.

@"? SO$2ARE 9UALI$0 ASSURANCE $OOLS

*n this section# we describe some tools that would facilitate the <L6 function.

Revie+s and Inspections

Hormal reviews and inspections are among the most effective tools to weed out the

defects from as close as possible to the point of injection. *n principle# every work product that is significant?be it the re$uirements specifications# design documents#

codeOtest specifications or test case?should be subjected to a formal review. There are

some distinctions made in the literature between reviews# inspections# and walkthroughs.

The interested reader is referred to the pointers in the references section. %ur discussions

below are based on Hagan *nspection discussed in +H6468E. >e use the term /review

synonymously with /inspection in the discussion below.

The salient features of a formal review (in the sense we use the term here are;

B. 6 review is formal?i.e.# there are formal# pre-defined roles played by each participant?and broadly follows the process outlined below.

2. Hor any work product to be reviewed# a review team is formed. The review team

consists of the following persons;

(a The author of the work product

(b 6 chairperson (usually other than the author also called the moderator

(c 6 scribe

(d %ne or more reviewers who are $ualified to review the work productand have no bias in terms of reporting structure or hierarchy

". The project manager (or the LualityO3rocess =anager forms the above review

team.'. The review team has an opening meeting. 0uring this meeting the author of the

work product presents a general overview of the work product# i.e.# what is its



objective and any other relevant details like implementation details# development

standards# etc. &e also ensures that each review team member has access to the

work product (either a soft copy or a hard copy and any relevant checklists or

criteria against which to evaluate the work produced.

. The moderator decides when the actual review meeting is going to be held. *n between the opening meeting and the actual review meeting# the review team

members are expected to diligently go through the work product and review it

using any applicable standards and guidelines as appropriate.E. The review team meets on the stipulated date and goes through the work product

se$uentially. The moderator controls the meeting. The scribe records the

proceedings of the meeting.8. !ach defect found in the work product is also recorded and classified into two

categories. The first is major vs minor# with major defects obviously being more

serious. The second category is whether it is a systemic defect or a mise$ecution

defect. *f the defect is systemic# then it is likely that the defect may be prevalent in

more situations and that a process change is needed. BB the defect is the result of

bad execution# then it is likely that human error is involved and this can be

avoided the next time without any process change.. 6fter the meeting the author a performs root cause analysis for the defects and

fixes the problems.7. The moderator ensures that all the open defects are fixed. *n case any process

changes are needed# he conveys them to the process $uality group.

To get the best results from the review process# the following guidelines have been foundeffective;

• The review team members clearly understand and faithfully enact their roles

• 6ll the team members come fully prepared for the meetings

• The review be only of the product and not of the author

• The process of identifying the problems should be the prerogative of the review

team. Hixing the identified problems is the author9s responsibility and domain and

should not be a part of the review meeting.

• The defects found in the review process are not be used in the performance

appraisal of the author. To this end# the author9s management chain should not a

part of the review team.

• The moderator keeps the discussions focused on the work product and does not let

any unnecessary small talk come in the way.

A'dits



>e have discussed audits in the context of process models in section '.2. 6 well

conducted audit is a very effective software $uality assurance tool. 6udits follow Ithe

broad process given below;

B. The senior management (or the process $uality team schedules periodic audits

and communicates the schedules to the entire organisation.2. The audit can be conducted either by an external body or a team of trained internal

auditors.". The audit is always performed using the existing documentation of the processes

of the organisation. *n addition# if the audit is for certification against any public

standard like the *<%-7AAB# such standards also become yardsticks against which

the audit is performed.'. !ach audit is assigned a lead auditor. The lead auditor is responsible for the

following;

• <electing the members of the audit team?either trained internal auditors or external auditors.

• =aintaining and communicating the schedules and responsibilities to all

concerned.

• :ommunicating the findings of the audit to the top management.

. The lead auditor selects a sample of projects that are to be audited. The sample

would be effective if;

• *t covers most of the representative projects in the organisation.

• *t covers some of those projects that have had problems in the past.

•*t covers projects in different phases of life cycle (e.g. some projects in there$uirements phase# some in design phase etc..

E. The lead auditor assigns a team of auditors to perform the audit of each project. To

be effective# the auditors for a given project should neither belong to the project

team nor should they be in the direct management chain of the project being

audited.8. The audit team (auditors audits the project team (auditees for compliance against

the documented processes and any applicable standards. 0uring the audit the audit

team ensures that all the relevant processes are practiced properly and that all

relevant $uality records are available.. The auditors document any variation between the processes and practices# based

on objective evidence as non-conformances. The auditees9 consent is usually

sought before documenting the non-conformance.7. The auditee (after the audit comes with corrective actions (to correct the

immediate occurrence of the non-conformance and preventive action (to prevent

such a non-conformance from occurring again in the future.



BA.The lead auditor collates all the non-conformances# corrective and preventive

actions and conveys these to the top management.BB. The top management and the process $uality group perform analysis on the

collated data to identify overall process improvement possibilities.

=ost of the tips we had given in the last section on making reviews effective also apply

to audits.

C&oss:S9As Info&,ation Sha&ing

The <L6s should communicate among themselves on a periodic basis# exchanging notes

on their experiences and practices. <uch a cross information sharing between the <L6s

would achieve the following purposes;

!arly warning signals of organisation-wide (and potentially endemic issues can

be got.

,est practices that take place in isolated pockets can be disseminated through

information sharing.

Govel methods adopted by <L6s to do their job can be shared

Defect Classification and Analysis $ools

The <L6s can add significant value to the project teams if besides just identifying

the defects# they can also perform some analysis and classification. Two of the more

popular tools in use for classification and analysis are; 3areto 6nalysis and Hish ,one0iagrams.

%a&eto Analysis

The A?2A (3areto rule is probably one of the most widely observed laws of

nature. AK of the productivity of an organisation is contributed by 2AK of its people1

AK of the value of inventory is accounted for by 2AK of the items. %n the same lines#

when problemsOnon-conformances are analysed and their root cause identified# it is

normally found that AK of the problemsOnon conformances are caused by a very specific

set of root causes. *f that specific set of root causes can be attacked and improvements

brought about# it would go a long way in removing a majority of the problemsOnon-

conformance.

ish one Diag&a,s



The fish bone diagram is another common tool that is used for getting to the root

cause of the defects. <tarting from the basic item being measured on the /spine# the fish

bone diagram creates new branches (or fish bones for any causes of defects. !ach gross

level classification (bone can be broken down into sub-branches or sub- bones which

would give a further refinement of the gross cause.

@"@ ORJANISA$IONAL S$RUC$URES

>here should the <L6 functions report into in an organisationF *n a typical organisation

tree# there are projects at the leaf level. 5elated projects are aggregated together (either in

terms of skill sets or product areas or geographically to form groups. These groups#

when aggregated together# make an organisation. The $uestions that arise are; whereshould the <L6 function exist and where should it report into.

%ne way to organise the <L6 function could be to identify a few individuals to

perform the <L6 function on a full time basis for the entire organisation. These <L6s

then become a part of the corporate $uality group.

6lternatively the <L6 function could be distributed across multiple project people

who# in addition to carrying out their normal project work# also carry out the <L6 role.

Thus instead of having a few full time <L6s# the <L6 role is split across several part

time <L6s. There are three possibilities of how <L6 teams can be organised in the case

of part time <L6s; 3roject level# 4roup level and :ompany level. The table below

presents a brief description of each of these models and their relative advantages and

disadvantages.



.able F1 SE! Or#aniGational Structures



@"> %ROILE O A SUCCESSUL S9A

5egardless of whether we go for project level# group level or company level <L6s (or

dedicated <L6s# there are some basic traits that successful <L6s should have;

"roven inte#rity' The <L69s job is about not compromising $uality1 it is also about being

able to call a spade a spade. Thus personal integrity is one of the most important traits

that an aspiring <L6 should possess.

"ersonal credibility' The <L6 will have to# on several occasions# tell the project team

and the management where things are not in order. Hor them to listen to him# and not

dismiss his observations as insignificant# the <L6 must have a high credibility rating in

the organisation.

$cellent people s/ills' *t is not always easy to tell someone that he is violating the rules

of some process and persuade him to take corrective action. The <L6 must have

excellent people skills (or soft skills which include good power of persuasion. %ne good

way to build the people bridges is to ensure that the <L6 also points out that is done well

rather than just pinpointing the weaknesses or non-conformances.

Stron# communication s/ills' The <L6 should possess very good spoken and written

communication skills. &e has to be able to communicate with the project teams and

management to let them know about the issues on hand without blaming airy particular

individual. *t is all about being able to disagree without being disagreeable)



<nderstandin# of (uality and statistical principles' The <L69s function will be more

value adding when he can do some aggregation# analysis# and make recommendations to

the project team and the management. To do this# he must have sound exposure and

adeptness in statistical principles and methods. &e should be familiar with tools like

3areto analysis# Hish bone diagram# etc. and have a basic understanding of the concept of variability# importance of predictability# and consistency.

@"; MEASURES O S9A SUCCESS

Mike for any other activity# we need to have metrics and the success criteria for the <L69s

success activities as well. *n this section# we present some of the important measures of

the <L6 s function within an organisation.

B. "rocess non-conformances that escape the SE!s evaluations' *t is the

responsibility of the <L6 to prevent defects or catch the defects as close as

possible to the point of injection. 0efects can be product defects or process non-

conformances. 3rocess non-conformances that escape the <L69s notice (and get

detected either as manifested product defects or show up in an external audit like

the *<% audit are indications of scope for improvement in the way the <L6

carries out his responsibilities.2. =umber and impact of process chan#es su##ested The <L69s suggestions# mainly

with respect to process changes# should not come across as nitpicking behaviour.

They should result in improvements in at least one of four dimensions; product

$uality# cost-effectiveness# customer satisfaction and employee satisfaction. The

impact of <L69s suggestions on these four dimensions is a reflection of the <L69s

success in his assigned role.". Impact of process (uality on product (uality' 6ny process or step that is followed

should have a material impact on the product $uality. The success of the <L6

function is measured by the impact on product $uality of any process changes

brought about by the findings of the <L6. These ties in with the previous point

about not going in for insignificant changes.'. !pplicability of process D product chan#es across proects' The impact of a change

would be more widespread if there are more people who benefit by that change. *f

the <L6 can suggest changes that can have ramifications and benefits in multiple

projects# they are likely to herald greater improvement than would the project-

specific process changes.. =umber and impact of best practices disseminated across the proects' 6s we said

earlier# it is important that the <L6 brings to the attention of the project team and

the management not just the problems but also the things that are done well.



&ence one of the measures of the <L69s success is how well the best practices

identified by him are disseminated across the organisation.

@")# %I$ALLS $O 2A$C* OU$ OR IN $*E S9AS ROLE

<L6 as an adversary to proect #roups' The <L6 should not be viewed as anadversary to the project group. The project group should not get the feeling of being

policed. <ome of the ways of combating such a pitfall are by making sure that the <L6 is

someone who has credibility and that he introduces some of the best practices of the

projects across the organisation in addition to just fault finding. 3icking the <L6 from

within the same group also helps to reduce this feeling of being policed.

<L6 as an overhead after the real wor/ is done wor/' The <L69s function should

be as much in stream as possible. *t should not be viewed /as let me do all my work and

allocate the day before the product release as the <L6 day) ,y interleaving the <L6

activity throughout the project# one can minimize the feeling of the <L6 being an

overhead activity.

>alance between pra#matism and strict compliance' %ne of the complaints that

people make against the <L6 is that he is a stickler for rules and is too literal in his

interpretation of the law (i.e.# the processes. The <L6 should be reasonable and strike a

fine balance between pragmatism and strict compliance. %ne way of doing this is not to

an alarm on every single instance of non-conformance but to have more data points# do

some analysis# and then come to conclusions. 6lso# it is a good idea to do a sanity check

on the intent vis-S-vis the actual steps documented in the process and ensure that the

intent is met.

Date post:	02-Jun-2018
Category:	Documents
Upload:	shanmugapriyavinodkumar
View:	216 times
Download:	0 times

chapter2spm

Documents