x software development project management

8/13/2019 x Software Development Project Management

1/73

A REPORT ON

COMPREHENSIVE PROJECT WORK

SOFTWARE DEVLOPMENT PROJECT MANAGEMENT

Submitted to

INDUKAKA IPCOWALA INSTITUTE OF MANAGEMENT (IIM!

CHAROTAR UNIVERSIT" OF SCIENCE AND TECHNOLOG"

(CHARUSAT!

CHANGA

P#e$%#ed b&

RAJESH PATEL

ID No: 09MBA59

MBA Second Ye!

U'de# te Guid%')e o*

M!" G" #" #!$%&n'(!)$

No*e'+e! ,0-0


2/73

INDEX

PART -1

1. Software Project Management Concepts

-"-" Software Project Management: Factors That Influence Results

-"," Project Management Concerns

-"." Why Projects Fail

-"/" The Management S!ectrum

-"5" The Software Team

-"" Coor"ination an" Communication Issues

-"1" W#hh Princi!le

-"2" Com!arison of $ine of Co"e an" Function Points %nalysis

&. Software Development

'. Software S!e Estmaton

(. Software "#alt$ %actors

/"-" Measuring )uality

/"," *efect Remo+al ,fficiency

#. Software Project Plannng

5"-" Software Sco!e ,stimation

5"," Feasi-ility

5"." Software Project ,stimation

. Rs& Anal$ss an' Management

"-" Ty!es of Ris/s

"," Ris/ I"entification


3/73

"."%ssessing 0+erall Project Ris/s

"/" Ris/ Com!onents an" *ri+ers

. Software Project Sc(e'#lng an' Montorng

1"-" Software Project Sche"uling

1"," Relationshi! -etween Peo!le an" ,ffort

PART-)

1* S#mmar$ of t(e case st#'$

1.1.*efine the sco!e

)* T(e feas+lt$ st#'$

&.1.What is circulation function

&.&.Stu"y the e2isting system

&.'.Ste!s in the feasi-ility stu"y I followe".

,* Pro+lems anal$ss

* Poss+le sol#ton an' cost +eneft anal$ss

(.1.Main characteristic of the software

(.&.Re3uirement analysis

.* E/ample of 0re#rement specfcaton2


4/73

S3%T4ARE PR35ECT MANA6EMENT C3NCEPTS

Software !roject management is a +ery im!ortant acti+ity for successful !rojects.

In fact4 in an organi5ation at CMM $e+el -asic !roject management !rocesses

are esta-lishe" to trac/ cost4 sche"ule4 an" functionality. That is4 it is

characteri5e" -y -asic !roject management !ractices. It also im!lies that without

!roject management not much can -e achie+e". 6oo" !roject management was

associate" with 1778 of the successful !roject an" -a" !roject management

was associate" with 1778 of the unsuccessful !rojects. Therefore4

un"erstan"ing of goo" !roject management !rinci!les an" !ractices is essential

for all !roject managers an" software engineers.

Software !roject management in+ol+es that !lanning4 organi5ation4 monitoring4

an" control of the !eo!le an" the !rocesses.

Software Project Management7 %actors t(at nfl#ence res#lts

The first ste! towar"s -etter !roject management is the com!rehension of the

factors that influence results of a !roject. %mong these4 the most im!ortant

factors are:

Project s!e7%s the !roject si5e increases4 the com!le2ity of the !ro-lem also

increases an" therefore its management also -ecomes more "ifficult.

Delver$ 'ea'lne7 *eli+ery "ea"line "irectly influences the resources an"

3uality. With a realistic "ea"line4 chances of "eli+ering the !ro"uct with high

3uality an" reasona-le resources increase tremen"ously as com!are" to an

unrealistic "ea"line. So a !roject manager has to first "etermine a realistic an"


5/73

reasona-le "ea"line an" then monitor the !roject !rogress an" ensure timely

"eli+ery.

8#'gets an' costs7% !roject manager is res!onsi-le for ensuring "eli+ery of

the !roject within the allocate" -u"get an" sche"ule. % goo" estimate of -u"get4

cost an" sche"ule is essential for any successful !roject. It is therefore

im!erati+e that the !roject manager un"erstan" an" learns the techni3ues an"

!rinci!le nee"e" to "e+elo! these estimates.

Applcaton 'oman7 %!!lication "omain also !lays an im!ortant role in the

success of a !roject. The chances of success of a !roject in a well9/nown

a!!lication "omain woul" -e much -etter than of a !roject in a relati+ely

un/nown "omain. The !roject manager thus nee"s to im!lement measures to

han"le unforeseen !ro-lems that may arise "uring the !roject lifecycle.

Tec(nolog$ to +e mplemente'7 Technology also !lays a +ery significant role

in the success or failure of a !roject. 0ne the one han"4 a new state9of9the9art;

technology may increase the !ro"ucti+ity of the team an" 3uality of the !ro"uct.

0n the other han"4 it may !ro+e to -e unsta-le an" hence !ro+e to -e "ifficult to

han"le. Resultantly4 it may totally -low you off the trac/. So4 the !roject manager

shoul" -e careful in choosing the im!lementation technology an" must ta/e

!ro!er safeguar" measures.

S$stem constrants7 The non9functional re3uirement or system constraints

s!ecify the con"itions an" the restrictions im!ose" on the system. % system that

fulfils all its functional re3uirements -ut "oes not satisfy the non9functional

re3uirements woul" -e rejecte" -y the user.

9ser re#rements7% system has to satisfy its user re3uirements. Failing to "o

so woul" ren"er this system unusa-le.


6/73

Avala+le reso#rces7 % !roject has to -e "e+elo!e" using the a+aila-le

resources who /now the "omain as well as the technology. The !roject manager

has to ensure that the re3uire" num-er of resources with a!!ro!riate s/ill9set is

a+aila-le to the !roject.

Project Management Concerns

In or"er to !lan an" run a !roject successfully4 a !roject manager nee"s to worry

a-out the following issues:

1. Pro"uct 3uality: what woul" -e the acce!ta-le 3uality le+el for this !articular

!roject an" how coul" it -e ensure"

&. Ris/ assessment: what woul" -e the !otential !ro-lems that coul" jeo!ar"i5e

the !roject an" how coul" they -e mitigate"

'. Measurement: how coul" the si5e4 !ro"ucti+ity4 3uality an" other im!ortant

factors -e measure" an" -enchmar/e"

(. Cost estimation: how coul" cost of the !roject -e estimate"

#. Project sche"ule: how coul" the sche"ule for the !roject -e com!ute" an"

estimate"

. Customer communication: what /in" of communication with the customer

woul" -e nee"e" an" how coul" it -e esta-lishe" an" maintaine"

consistently

. Staffing: how many !eo!le with what /in" of resources woul" -e nee"e" an"

how that re3uirement coul" -e fulfille"


7/73

Thorough un"erstan"ing an" a!!reciation of these issues lea"s to the 3uest for

fin"ing satisfactory answers to these !ro-lems an" im!ro+es the chances for

success of a !roject.

4($ Projects %al:

% !roject manager is tas/e" to ensure the successful "e+elo!ment of a !ro"uct.

Success cannot -e attaine" without un"erstan"ing the reasons for failure. The

main reasons for the failure of software !rojects are:

1. changing customer re3uirements

&. am-iguous>incom!lete re3uirements

'. unrealistic "ea"line

(. an honest un"erestimate of effort

#. !re"icta-le an">or un!re"icta-le ris/s

. technical "ifficulties

. miscommunication among !roject staff


8/73

%s "iscusse" earlier4 "eli+ery "ea"line "irectly influences the resources an"

3uality. With a realistic "ea"line4 chances of "eli+ering the !ro"uct with high

3uality an" reasona-le resources increase tremen"ously as com!are" to an

unrealistic "ea"line. %n unrealistic "ea"line coul" -e enforce" -y the

management or the client or it coul" -e "ue to error in estimation. In -oth these

cases it often results in "isaster for the !roject.

% !roject manager who is not !re!are" an" without a contingency !lan for all

sorts of !re"icta-le an" un!re"icta-le ris/s woul" !ut the !roject in jeo!ar"y if

such a ris/ shoul" ha!!en. Ris/ assessment an" antici!ation of technical an"

other "ifficulties allows the !roject manager to co!e with these situations.

Miscommunication among the !roject staff is another +ery im!ortant reason for

!roject failure. $ac/ of !ro!er coor"ination an" communication in a !roject

results in wastage of resources an" chaos.

T(e Management Spectr#m

,ffecti+e !roject management focuses on four as!ects of the !roject /nown as

the ( P@s. These are: !eo!le4 !ro"uct4 !rocess4 an" !roject.

People

Software "e+elo!ment is a highly !eo!le intensi+e acti+ity. In this -usiness4 the

software factory com!rises of the !eo!le wor/ing there. Aence ta/ing care of the

first P4 that is !eo!le4 shoul" ta/e the highest !riority on a !roject manager@s

agen"a.


9/73

Pro'#ct

The !ro"uct is the outcome of the !roject. It inclu"es all /in"s of the software

systems. Bo meaningful !lanning for a !roject can -e carrie"9out until all the

"imensions of the !ro"uct inclu"ing its functional as well as non9functional

re3uirements are un"erstoo" an" all technical an" management constraints are

i"entifie".

Process

0nce the !ro"uct o-jecti+es an" sco!e ha+e -een "etermine"4 a !ro!er

software "e+elo!ment !rocess an" lifecycle mo"el must -e chosen to i"entify

the re3uire" wor/ !ro"ucts an" "efine the milestones in or"er to ensure

streamline" "e+elo!ment acti+ities. It inclu"es the set of all the framewor/

acti+ities an" software engineering tas/s to get the jo- "one.

Project

% !roject com!rises of all wor/ the re3uire" to ma/e the !ro"uct a reality. In

or"er to a+oi" failure4 a !roject manager an" software engineer is re3uire" to

-uil" the software !ro"uct in a controlle" an" organi5e" fashion an" run it li/e

other !rojects foun" in more concrete "omains.

We now "iscuss these ( in more "etail.

People

The !roject team was i"entifie" -y the senior e2ecuti+es as the most im!ortant

contri-utor to a successful software !roject. Aowe+er4 unfortunately4 !eo!le are

often ta/en for grante" an" "o no get the attention an" focus they "eser+e.


10/73

There are a num-er of !layers that !artici!ate in software !rocess an" influence

the outcome of the !roject. These inclu"e senior managers4 !roject technicalD

managers4 !ractitioners4 customers4 an" en"9users. Senior managers "efine the

-usiness +ision whereas the !roject managers !lan4 moti+ate4 organi5e an"

control the !ractitioners who wor/ to "e+elo! the software !ro"uct. To -e

effecti+e4 the !roject team must -e organi5e" to use each in"i+i"ual to the -est

of his>her a-ilities. This jo- is carrie" out -y the team lea"er.

Team ;ea'er

Project management is a !eo!le intensi+e acti+ity. It nee"s the right mi2 of

!eo!le s/ills. Therefore4 com!etent !ractitioners often ma/e !oor team lea"ers.

$ea"ers shoul" a!!ly a !ro-lem sol+ing management style. That is4 a !roject

manager shoul" concentrate on un"erstan"ing the !ro-lem to -e sol+e"4

managing the flow of i"eas4 an" at the same time4 letting e+eryone on the team

/now that 3uality counts an" that it will not -e com!romise".

M0I mo"el of lea"ershi! "e+elo!e" -y Wein-erg suggest that a lea"ershi!

nee"s Moti+ation4 0rgani5ation4 an" Inno+ation.

Motvatonis the a-ility to encourage technical !eo!le to !ro"uce to their -est.

3rgan!atonis the a-ility to mol" the e2isting !rocesses or in+ent new onesD

that will ena-le the initial conce!t to -e translate" into a final !ro"uct4 an" I'ea

or Innovatonis the a-ility to encourage !eo!le to create an" feel creati+e.


11/73

It is suggeste" that successful !roject managers a!!ly a !ro-lem sol+ing

management style. This in+ol+es "e+elo!ing an un"erstan"ing of the !ro-lem

an" moti+ating the team to generate i"eas to sol+e the !ro-lem.

,"gemon suggests that the following characteristics are nee"e" to -ecome an

effecti+e !roject manager:

E Pro-lem Sol+ing

Shoul" -e a-le to "iagnose technical an" organi5ational issues an" -e

willing to change "irection if nee"e".

E Managerial I"entity

Must ha+e the confi"ence to ta/e control when necessary

E %chie+ement

Rewar" initiati+e controlle" ris/ ta/ingD an" accom!lishment

E Influence an" team -uil"ing

Must remain un"er control in high stress con"itions. Shoul" -e a-le to

rea" signals an" a""ress !eo!les@ nee"s.

T(e Software Team

There are many !ossi-le organi5ational structures. In or"er to i"entify the most

suita-le structure4 the following factors must -e consi"ere":

E the "ifficulty of the !ro-lem to -e sol+e"

E the si5e of the resultant !rogramsD in lines of co"e or function !oints

E the time that the team will stay together team lifetimeD

E the "egree to which the !ro-lem can -e mo"ulari5e"


12/73

E the re3uire" 3uality an" relia-ility of the system to -e -uilt

E the rigi"ity of the "eli+ery "ate

E the "egree of socia-ility communicationD re3uire" for the !roject

Constantine suggests that teams coul" -e organi5e" in the following generic

structural !ara"igms:

E close' para'gmGstructures a team along a tra"itional hierarchy of

authority

E ran'om para'gmGstructures a team loosely an" "e!en"s on in"i+i"ual

initiati+e of the team mem-ers

E open para'gmGattem!ts to structure a team in a manner that achie+es

some of the controls associate" with the close" !ara"igm -ut also much of

the inno+ation that occurs when using the ran"om !ara"igm

E s$nc(rono#s para'gmGrelies on the natural com!artmentali5ation of a

!ro-lem an" organi5es team mem-ers to wor/ on !ieces of the !ro-lem with

little acti+e communication among themsel+es

Mantei suggests the following three generic team organi5ations:

E *emocratic "ecentrali5e" **D: In this organi5ation there is no !ermanent

lea"er an" tas/ coor"inators are a!!ointe" for short "uration. *ecisions on

!ro-lems an" a!!roach are ma"e -y grou! consensus an" communication

among team is hori5ontal.

E Controlle" "ecentrali5e" C*D: In C*4 there is a "efine" lea"er who

coor"inates s!ecific tas/s. Aowe+er4 !ro-lem sol+ing remains a grou! acti+ity


13/73

an" communication among su-grou!s an" in"i+i"uals is hori5ontal. Hertical

communication along the control hierarchy also occurs.

E Controlle" centrali5e" CCD: In a Controlle" Centrali5e" structure4 to! le+el

!ro-lem sol+ing an" internal team coor"ination are manage" -y the team

lea"er an" communication -etween the lea"er an" team mem-ers is +ertical.

Centrali5e" structures com!lete tas/s faster an" are most useful for han"ling

sim!le !ro-lems. 0n the other han"4 "ecentrali5e" teams generate more an"

-etter solutions than in"i+i"uals an" are most useful for com!le2 !ro-lems

For the team morale !oint of +iew4 ** is -etter.

Coor'naton an' Comm#ncaton Iss#es

$ac/ of coor"ination results in confusion an" uncertainty. 0n the other han"4

!erformance is in+ersely !ro!ortional to the amount of communication an"

hence too much communication an" coor"ination is also not healthy for the

!roject. Hery large !rojects are -est a""resse" with CC or C* when su-9

grou!ing can -e easily accommo"ate".

raul an" Steeter categori5e the !roject coor"ination techni3ues as follows:

E Formal4 im!ersonal a!!roaches: In these a!!roaches4 coor"ination is

achie+e" through im!ersonal an" formal mechanism such as S, "ocuments4

technical memos4 sche"ules4 error trac/ing re!orts.


14/73

E Formal4 inter!ersonal !roce"ures: In this case4 the a!!roaches are

inter!ersonal an" formal. These inclu"e )% acti+ities4 "esign an" co"e

re+iews4 an" status meetings.

E Informal4 inter!ersonal !roce"ures: This a!!roach em!loys informal

inter!ersonal !roce"ures an" inclu"es grou! meetings an" collocating

"ifferent grou!s together.

E ,lectronic communication inclu"es emails an" -ulletin -oar"s.

E Inter!ersonal networ/ing inclu"es informal "iscussions with grou! mem-ers

The effecti+eness of these a!!roaches has -een summari5e" in the following

"iagram:

Techni3ues that fall a-o+e the regression line yiel" more +alue to use ratio as

com!are" to the ones -elow the line.


15/73

T(e Project

%s "iscusse" earlier4 a !roject manager must un"erstan" what can go wrong

an" how to "o it right. Reel has "efine" a # ste! !rocess to im!ro+e the chances

of success. These are:

Start on the right foot: this is accom!lishe" -y !utting in the re3uire" effort to

un"erstan" the !ro-lem4 set realistic o-jecti+es4 -uil" the right team4 an"

!ro+i"e the nee"e" infrastructure.

Maintain momentum: many !rojects4 after starting on the right4 loose focus

an" momentum. The initial momentum must -e maintaine" till the +ery en".

Trac/ !rogress: no !lanning is useful if the !rogress is not trac/e". Trac/ing

ensures timely "eli+ery an" reme"ial action4 if nee"e"4 in a suita-le manner.

Ma/e smart "ecisions

Con"uct a !ostmortem analysis: in or"er to learn from the mista/es an"

im!ro+e the !rocess continuously4 a !roject !ostmortem must -e con"ucte".

4.


16/73

E 4


17/73

S3%T4ARE DE>E;3PMENT

The construction acti+ities are those that are "irectly relate" to the construction

or "e+elo!ment of the software. While the management acti+ities are those that

com!lement the !rocess of construction in or"er to !erform construction

acti+ities smoothly an" effecti+ely. % greater "etail of the acti+ities in+ol+e" in the

construction an" management categories is !resente" -elow.


18/73

Construction

The construction acti+ities are those that "irectly relate" to the "e+elo!ment of

software4 e.g. gathering the re3uirements of the software4 "e+elo! "esign4

im!lement an" test the software etc. Some of the major construction acti+ities

are liste" -elow.

Re3uirement 6athering

*esign *e+elo!ment

Co"ing

Testing

Management

Management acti+ities are /in" of um-rella acti+ities that are use" to smoothly

an" successfully !erform the construction acti+ities e.g. !roject !lanning4

software 3uality assurance etc. Some of the major management acti+ities are

liste" -elow.

Project Planning an" Management

Configuration Management

Software )uality %ssurance

Installation an" Training

%s we ha+e sai" earlier that management acti+ities are /in" of um-rella acti+ities

that surroun" the construction acti+ities so that the construction !rocess may

!rocee" smoothly. This fact is em!athi5e" in the ,rror: Reference source not

foun". The figure shows that construction is surroun"e" -y management


19/73

acti+ities. That is4 certain !rocesses an" rules go+ern all construction acti+ities.

These !rocesses an" rules are relate" to the management of the construction

acti+ities an" not the construction itself.


20/73

S3%T4ARE SI?E ESTIMATI3N

The si5e of the software nee"s to -e estimate" to figure out the time nee"e" in

terms of calen"ar an" man months as well as the num-er an" ty!e of resources

re3uire" carrying out the jo-. The time an" resources estimation e+entually !lays

a significant role in "etermining the cost of the !roject.

Most organi5ations use their !re+ious e2!erience to estimate the si5e an" hence

the resource an" time re3uirements for the !roject. If not 3uantifie"4 this estimate

is su-jecti+e an" is as goo" as the !erson who is con"ucting this e2ercise. %t

times this ma/es it highly contentious. It is therefore im!erati+e for a go+ernment

organi5ation to a"o!t an estimation mechanism that is:

0-jecti+e in nature.

1. It shoul" -e an acce!ta-le stan"ar" with wi"e s!rea" use an" acce!tance

le+el.

&. It shoul" ser+e as a single yar"stic/ to measure an" ma/e com!arisons.

'. Must -e -ase" u!on a "eli+era-le that is meaningful to the inten"e"

au"ience.

(. It shoul" -e in"e!en"ent of the tool an" technology use" for the "e+elo!ing

the software.

% num-er of techni3ues an" tools can -e use" in estimating the si5e of the

software. These inclu"e:

1. $ines of co"e $0CD


21/73

&. Bum-er of o-jects

'. Bum-er of 6?Is

(. Bum-er of "ocument !ages

#. Functional !oints FPD


22/73

C3MPARIS3N 3% ;INE 3% C3DE AND %9NCTI3N

P3INTS ANA;=SIS

0ut of these #4 the two most wi"ely use" metrics for the measurement of

software si5e are F?BCTI0B P0IBTS an" $0C. $IB, 0F C0*, metric suffer

from the following shortcomings:

1. There are a num-er of 3uestions regar"ing the "efinition for lines of co"e.

These inclu"e:

a. Whether to count !hysical line or logical lines

-. What ty!e of lines shoul" -e counte" For e2am!le4 shoul" the

comments4 "ata "efinitions4 an" -lan/ lines -e counte" or not

&. $IB, 0F C0*, is hea+ily "e!en"ent u!on the in"i+i"ual !rogramming

style.

'. It is "e!en"ent u!on the technology an" hence it is "ifficult to com!are

a!!lications "e+elo!e" in two "ifferent languages. This is true for e+en

seemingly +ery close languages li/e in CKK an" La+a.

(. If a mi2ture of languages an" tools is use" then the com!arison is e+en

more "ifficult. For e2am!le4 it is not !ossi-le to com!are a !roject that

"eli+ers a 17747779line mi2ture of %ssem-ly4 CKK4 S)$ an" Hisual Jasic

to one that "eli+ers 1774777 lines of C0J0$.

F?BCTI0B P0IBTS measures the si5e of the functionality !ro+i"e" -y the

software. The functionally is measure" as a function of the "ata an" the

o!erations !erforme" on that "ata. The measure is in"e!en"ent of the tool an"


23/73

technology use" an" hence !ro+i"es a consistent measure for com!arison

-etween +arious organi5ations an" !rojects.

The -iggest a"+antage of F?BCTI0B P0IBTS o+er $IB, 0F C0*, is that $IB,

0F C0*, can -e counte" only %FT,R the co"e has -een "e+elo!e" while

F?BCTI0B P0IBTS can -e counte" e+en at the re3uirement !hase an" hence

can -e use" for !lanning an" estimation while the $IB, 0F C0*, cannot -e

use" for this !ur!ose.

%nother major "istinction -etween the F?BCTI0B P0IBTS an" $IB, 0F C0*,

is that the $IB, 0F C0*, measures the a!!lication from a "e+elo!ers

!ers!ecti+e while the F?BCTI0B P0IBTS is a measure of the si5e of the

functionality from the users !ers!ecti+e.

Therefore4 Function Point %nalysis measures the si5e of the functionality

"eli+ere" an" use" -y the en" user as o!!ose" to the +olume of the artifacts an"

co"e.

%#ncton Pont Anal$ss @ 9sage

?sage of F?BCTI0B P0IBTS inclu"es:

,ffort Sco!e ,stimation

Project Planning

*etermine the im!act of a""itional or change" re3uirements

Resource Planning>%llocation

Jenchmar/ing an" target setting


24/73

Contract Begotiations

Following is a list of some of the F?BCTI0B P0IBTS -ase" metrics use" for

these !ur!oses:

Si5e Function Points

*efects Per Function Point

,ffort Staff9Months

Pro"ucti+ity Function Points !er Staff9Month

*uration Sche"ule Calen"arD Months

Time ,fficiency Function Points !er Month

Cost Per Function


25/73

S3%T4ARE "9A;IT= %ACT3RS

In 1=


26/73

%actors relate' wt( operaton

E Correctness: The e2tent to which a !rogram satisfies its s!ecifications

an" fulfills the customer@s mission o-jecti+es

E Relia-ility: The e2tent to which a !rogram can -e e2!ecte" to !erform its

inten"e" function with re3uire" !recision.

E ,fficiency: The amount of com!uting resources re3uire" -y a !rogram to

!erform its function

E Integrity: ,2tent to which access to software or "ata -y unauthori5e"

!ersons can -e controlle".

E ?sa-ility: ,ffort re3uire" to learn4 o!erate4 !re!are in!ut4 an" inter!ret

out!ut of a !rogram

%actors relate' wt( revson

E Maintaina-ility: ,ffort re3uire" to locate an" fi2 an error in a !rogram

E Fle2i-ility: ,ffort re3uire" to mo"ify an o!erational !rogram

E Testa-ility: ,ffort re3uire" to test a !rogram to ensure that it !erforms its

inten"e" function

%actors relate' wt( a'aptaton

E Porta-ility: ,ffort re3uire" transferring the !rogram from one har"ware

an">or software system en+ironment to another.

E Reusa-ility: ,2tent to which a !rogram can -e reuse" in other

a!!lications

E Intero!era-ility: ,ffort re3uire" to cou!le one system to another.


27/73

It is interesting to note that the fiel" of com!uting an" its theoretical ha+e gone

through !henomenal changes -ut McCall@s 3uality factors are still as rele+ant as

they were almost years ago.

Meas#rng "#alt$

6il- e2ten"s McCall@s i"ea an" !ro!oses that the 3uality can -e measure" if we

measure the correctness4 maintaina-ility4 integrity4 an" usa-ility of the !ro"uct.

Correctness is "efine" as the "egree to which software !erforms its function. It

can -e measure" in "efects>$0C or "efects>FP where "efects are "efine" as

+erifie" lac/ of conformance to re3uirements. These are the !ro-lems re!orte"

-y the user after release. These are counte" o+er a stan"ar" !erio" of time

which is ty!ically "uring the first year of o!eration.

Maintaina-ility is "efine" as the ease with which a !rogram can -e correcte" if

an error is encountere"4 a"a!te" if en+ironment changes4 enhance" if the

customer re3uires an enhancement in functionality. It is an in"irect measure of

the 3uality.

% sim!le time oriente" metric to gauge the maintaina-ility is /nown as MMTC

mean time to change. It is "efine" as the time it ta/es to analy5e the change

re3uest4 "esign an a!!ro!riate mo"ification4 im!lement the change4 test it4 an"

im!lement it.


28/73

% cost oriente" metric use" to assess maintaina-ility is calle" S!oilage. It is

"efine" as the cost to correct "efects encountere" after the software has -een

release" to the users. S!oilage cost is !lotte" against the o+erall !roject cost as

a function of time to "etermine whether the o+erall maintaina-ility of software

!ro"uce" -y the organi5ation is im!ro+ing.

Integrity is an e2tremely im!ortant measure es!ecially in to"ay@s conte2t when

the system is e2!ose" to all sorts to attac/s -ecause of the internet

!henomenon. It is "efine" as software@s a-ility to withstan" attac/ -oth

acci"ental an" intentionalD to its security. It inclu"es integrity of !rogram4 "ata4

an" "ocuments. To measure integrity4 two a""itional attri-utes are nee"e".

These are: threat an" security.

Threat is the !ro-a-ility "eri+e" or measure" from em!irical e+i"enceD that an

attac/ of a s!ecific ty!e will occur within a gi+en time an" security is the

!ro-a-ility that an attac/ of a s!ecific ty!e will -e re!elle". So the integrity of a

system is "efine" as the sum of all the !ro-a-ility that the threat of a s!ecific

ty!e will not ta/e !lace an" the !ro-a-ility that if that threat "oes ta/e !lace4 it

will not -e re!elle".

Integrity N O 19threatD 2 19securityDQ

Finally4 usa-ility is a measure of user frien"liness the ease with which a

system can -e use". It can -e measure" in terms of ( characteristics:

E Physical or intellectual s/ill re3uire" learn the system


29/73

E The time re3uire" to -ecome mo"erately efficient in the use of system

E The net increase in !ro"ucti+ity

E % su-jecti+e assessment

It is im!ortant to note that e2ce!t for the usa-ility4 the other three factors are

essentially the same as !ro!ose" -y McCall.

Defect Removal Effcenc$

*efect remo+al efficiency is the measure of how many "efects are remo+e" -y

the 3uality assurance !rocesses -efore the !ro"uct is shi!!e" for o!eration. It is

therefore a measure that "etermines the effecti+eness of the )% !rocesses

"uring "e+elo!ment. It is useful at -oth the !roject an" !rocess le+el.

*efect remo+al efficiency is calculate" as the num-er of "efect remo+e" -efore

shi!ment as a !ercentage of total "efects

*R, N ,>,K*D

Where

E , errors foun" -efore "eli+ery

E * errors foun" after "eli+ery ty!ically within the first year of o!erationD

Regar"ing the effecti+eness of +arious )% acti+ities4 Ca!ers Lones !u-lishe"

some "ata in 1== which is summari5e" in the following ta-le.

Desgn Inspecton

Co'e Inspecton

"#alt$ Ass#rance

Testng

4orst ,B ,B .B ..B .B .B B E.B F.B

Me'an -B .,B .B B EB EB FB FB FFB8est .B B .B EB EB F,B F.B FFB FF*FB


30/73

In this research4 they trie" to measure the effecti+eness of ( "ifferent acti+ities

namely "esign ins!ection4 co"e ins!ection4 3uality assurance function4 an"

testing. It is im!ortant to note that testing alone only yiel"s a *R, of (78 on the

a+erage. Aowe+er4 when it is com-ine" with "esign an" co"e ins!ection4 the

*R, reaches =8. That means4 co"e an" "esign ins!ection are e2tremely

im!ortant acti+ates that are unfortunately not gi+en their "ue im!ortance.


31/73

S3%T4ARE PR35ECT P;ANNIN6

Software !roject !lanning is an acti+ity carrie" out -y the !roject manager to

estimate an" a""ress the following !oints:

1. Software sco!e estimation

&. Resources re3uirements

'. Time re3uirements

(. Structural "ecom!osition

#. Ris/ analysis an" !lanning

Software scope estmaton

Software sco!e "escri-es the "ata an" control to -e !rocesse"4 function4

!erformance4 constraints4 interfaces4 an" relia-ility. *etermination of the

software sco!e is a !re9re3uisite of all sorts of estimates4 inclu"ing4 resources4

time4 an" -u"get.

In or"er to un"erstan" the sco!e4 a meeting with the client shoul" -e arrange".

The analyst shoul" start with "e+elo!ing a relationshi! with the client

re!resentati+e an" start with conte2t9free 3uestions. %n un"erstan"ing of the

!roject -ac/groun" shoul" also -e "e+elo!e". This inclu"es un"erstan"ing:

E Who is -ehin" the re3uest s!onsorD

E Who will use the solution usersD

E What are the economic -enefits whyD


32/73

Bow is the time to a""ress the fin" out the more a-out the !ro"uct. In this

conte2t4 the following 3uestions may -e as/e":

E Aow woul" you characteri5e goo" out!ut

E What !ro-lems will the solution a""ress

E Can you show me the en+ironment in which the solution will -e use"

E Will any s!ecial !erformance issues or constraints affect the way the

solution is a!!roache"

E %re you the right !erson to answer these 3uestions %re answers

official;

E %re my 3uestions rele+ant to the !ro-lem that you ha+e

E %m I as/ing too many 3uestions

E Can anyone else !ro+i"e a""itional information

E Shoul" I -e as/ing you anything else

In this regar"s4 a techni3ue /nown as %acltate' Applcaton Specfcaton

Tec(n#es or sim!ly%ASTcan -e use". This is a team9oriente" a!!roach to

re3uirement gathering that is use" "uring early stages of analysis an"

s!ecification. In this case joint team of customers an" "e+elo!ers wor/ together

to i"entify the !ro-lem4 !ro!ose elements of the solution4 negotiate "ifferent

a!!roaches4 an" s!ecify a !reliminary set of re3uirements.

%eas+lt$

The !ur!ose of the feasi-ility analysis is to "etermine can we -uil" software to

meet the sco!e For this !ur!ose4 the !roject is analy5e" on the following (

"imensions:


33/73

Technology

3 Is the !roject technically feasi-le

3 Is it within the state of the art

3 Can "efects -e re"uce" to a le+el matching the a!!lication nee"s

Finance

3 Is it financially feasi-le

3 Can "e+elo!ment -e com!lete" at a cost that software organi5ation4 its

client4 or the mar/et can affor"

Time

3 Will the !roject time to mar/et -eat the com!etition

3 Can we com!lete the !roject in the gi+en amount of time

Resources

3 *oes the organi5ation ha+e resources nee"e" to succee" The resources

inclu"e:

3 AW>SW tools

3 Reusa-le software com!onents

3 Peo!le

Software Project Estmaton

0nce the !roject feasi-ility has -een "etermine"4 the !roject manager starts the

estimation acti+ity. It is a relati+ely "ifficult e2ercise an" has not -ecome an

e2act science. It is influence" -y human4 technical4 en+ironmental4 !olitical

factors.


34/73

For software !roject estimation4 a !roject manager can use historic "ata a-out its

organi5ations !re+ious !rojects4 "ecom!osition techni3ues4 an">or em!irical

mo"els "e+elo!e" -y "ifferent researchers.

Emprcal Mo'els

,m!irical mo"els are statistical mo"els an" are -ase" u!on historic "ata.

%lthough there are many "ifferent mo"els "e+elo!e" -y "ifferent researchers4 all

of them share the following -asic structure:

, N % K J e+DC

where

%4 J4 c are em!irical constants4

e+@ is the effort in terms of lines of co"e or FP4 an"

,@ is the effort in terms of !erson months.

The most famous of these mo"els is the C0C0M0 9 Constructi+e Cost Mo"el

mo"el. It also has many "ifferent +ersions. The sim!lest of these +ersions is

gi+en -elow:

, N '.& $0CD1.7#

Some of these mo"els ta/e into account the !roject a"justment com!onents

inclu"ing !ro-lem com!le2ity4 staff e2!erience4 an" "e+elo!ment en+ironment.

It is im!ortant to note that there are a num-er of mo"els with each yiel"ing a

"ifferent result. This means that any mo"el must -e cali-rate" for local nee"s

-efore it can -e effecti+ely use".


35/73

T(e Software E#aton

The software e3uation shown -elow is "ynamic multi+aria-le estimation mo"el. It

assumes a s!ecific "istri-ution of effort o+er the life of the software "e+elo!ment

!roject an" is "eri+e" from !ro"ucti+ity "ata collecte" for o+er (777 !rojects.

, N $0C 2 J7.'''>PQ'2 1>t(D

Where:

E , effort in !erson months or !erson years

E t !roject "uration in months or years

E J s!ecial s/ill factor

Increases slowly as the nee" for integration4 testing4 )%4

"ocumentation4 an" management s/ills grow

E P !ro"ucti+ity !arameter

0+erall !rocess maturity an" management !ractices

The e2tent to which goo" S, !ractices are use"

The le+el of !rogramming language use"

The state of the software en+ironment

The s/ills an" e2!erience of the software team

The com!le2ity of the a!!lication

8#$ vers#s +#l'

It is often more cost9effecti+e to ac3uire than to -uil". There may -e se+eral

"ifferent o!tions a+aila-le. These inclu"e:

3 0ff9the9shelf license" software

3 Software com!onents to -e mo"ifie" an" integrate" into the a!!lication

3 Su-9contract


36/73

The final "ecision "e!en"s u!on the criticality of the software to -e !urchase"

an" the en" cost. The -uy +ersus -uil" "ecision !rocess in+ol+es the following

ste!s:

E *e+elo! s!ecification for function an" !erformance of the "esire"

software. *efine measura-le characteristics whene+er !ossi-le.

E ,stimate internal cost an" time to "e+elo!

E Select '9( can"i"ate a!!lications that -est meet your s!ecifications

E Select reusa-le software com!onents that will assist in constructing the

re3uire" a!!lication

E *e+elo! com!arison matri2 that !resents a hea"9to9hea" com!arison of

/ey function. %lternati+ely4 con"uct -enchmar/ tests to com!are

can"i"ate software.

E ,+aluate each software !ac/age or com!onent -ase" on !ast !ro"uct

3uality4 +en"or su!!ort4 !ro"uct "irection4 re!utation4 etc.

E Contact other users of the software an" as/ for o!inion.

The following /ey consi"erations must always -e /e!t in the !ers!ecti+e:

E *eli+ery "ate

E *e+elo!ment Cost

%c3uisition K customi5ation

E Maintenance Cost


37/73

RISG ANA;=SIS AND MANA6EMENT

%nalysis an" management of !roject ris/s is also a +ery im!ortant acti+ity that a

!roject manager must !erform in or"er to im!ro+e the chances for the !roject.

Ris/ analysis an" management in+ol+es a""ressing the following concerns:

1. Future what ris/s might cause the !roject to go awry

&. Change what change might cause the ris/ to stri/e

E Aow changes in re3uirements4 technology4 !ersonnel an" other

entities connecte" to the !roject affect the !roject

'. Choice what o!tions "o we ha+e for each ris/

There are two -asic ris/ management !hiloso!hies4 reacti+e an" !roacti+e.

E Reacti+e In"iana Lones school of ris/ management

Be+er worrying a-out !ro-lems until they ha!!ene"4 an" then

reacting in some heroic way In"iana Lones style.

E Proacti+e

Jegins long -efore technical wor/ starts

Ris/s are i"entifie"4 their !ro-a-ility an" im!act are analy5e"4 an"

they are ran/e" -y im!ortance.

Ris/ management !lan it !re!are"

E Primary o-jecti+e is to a+oi" ris/

E Since all ris/s cannot -e a+oi"e"4 a contingency !lan is

!re!are" that will ena-le it to res!on" in a controlle" an"

effecti+e manner


38/73

?nfortunately4 In"iana Lones style is more suita-le for fiction an" has a rare

chance of success in real life situations. It is therefore im!erati+e that we

manage ris/ !roacti+ely.

% ris/ has two characteristics:

E ?ncertainty the ris/ may or may not ha!!en

E $oss if the ris/ -ecomes a reality4 unwante" conse3uences or losses

will occur.

% ris/ analysis in+ol+es 3uantifying "egree of uncertainty of the ris/ an" loss

associate with it. In this regar"s4 the PM tries to fin" answers to the following

3uestions:

E What can go wrong

E What is the li/elihoo" of it going wrong

E What will the "amage -e

E What can we "o a-out it


39/73

T=PES 3% RISGS

,ach !roject is face" with many ty!es of ris/s. These inclu"e:

E Project ris/s

Will im!act sche"ule an" cost

Inclu"es -u"getary4 sche"ule4 !ersonnel4 resource4 customer4

re3uirement !ro-lems

E Technical ris/s

Im!act the 3uality4 timelines4 an" cost

Im!lementation may -ecome "ifficult or im!ossi-le

Inclu"es "esign4 im!lementation4 interface4 +erification an"

maintenance !ro-lems

$ea"ing e"ge technology

E Jusiness ris/s

Mar/eta-ility

%lignment with the o+erall -usiness strategy

Aow to sell

$osing -u"get or !ersonnel commitments

Furthermore4 there are !re"icta-le an" un!re"icta-le ris/s. Pre"icta-le ris/s can

-e unco+ere" after careful e+aluation whereas un!re"icta-le ris/s cannot -e

i"entifie".


40/73

Rs& I'entfcaton

It is the res!onsi-ility of the !roject manager to i"entify /nown an" !re"icta-le

ris/s. These ris/s fall in the following categories of generic ris/s an" !ro"uct

s!ecific ris/s. Generic risksare threats to e+ery !roject whereas Product specific

risksare s!ecific to a !articular !roject. The 3uestion to -e as/e" in this conte2t

is: what s!ecial characteristics of this !roject may threaten your !roject !lan %

useful techni3ue in this regar"s is the !re!aration of a ris/ item chec/list. This

list tries to as/ an" answer 3uestions rele+ant to each of the following to!ics for

each software !roject:

E Pro"uct si5e

E Jusiness im!act

E Customer characteristics

E Process "efinition

E *e+elo!ment en+ironment

E Technology to -e -uilt

E Staff si5e an" e2!erience

Assessng 3verall Project Rs&s

In or"er to assess the o+erall !roject ris/s4 the following 3uestions nee" to -e

a""resse":

E Aa+e to! software an" customer managers formally committe" to su!!ort

the !roject

E %re en"9users committe" to the !roject an" the system>!ro"uct to -e

-uilt

E %re re3uirements fully un"erstoo"


41/73

E Aa+e customers -een in+ol+e" fully in re3uirement "efinition

E *o en"9users ha+e realistic e2!ectations

E *oes the software team ha+e right mi2 of s/ills

E %re !roject re3uirements sta-le

E *oes the !roject team ha+e e2!erience with the technology to -e

im!lemente"

E Is the num-er of !eo!le on the !roject team a"e3uate to "o the jo-

Rs& components an' 'rvers

,ach ris/ has many com!onents an" forces -ehin" them. From this !ers!ecti+e4

ris/s can -e categori5e" into the following categories:

E Performance ris/s

*egree of uncertainty that the !ro"uct will meet its re3uirements

an" -e fit for its inten"e" use

E Cost ris/s

The "egree of uncertainty that the !roject -u"get will -e

maintaine"

E Su!!ort ris/s

Resultant software will -e easy to correct4 enhance4 an" a"a!t

E Sche"ule ris/s

Pro"uct sche"ule will -e maintaine"

,ach ris/ has its own im!act an" can -e characteri5e" as negligi-le4 marginal4

critical4 or catastro!hic.


42/73

This is summari5e" in the following ta-le:

Rs&

Impact

Performa

nce

S#pport Cost Sc(e'#le

Catastrop(

c

Conse3uence of

error

Failure to meet the

re3uirements will result

in mission failure

Results in increase"

cost an" sche"ule

"elays. ,2!ecte"

+alue in e2cess of

#77Conse3uence of

failure to achie+e

"esire" result

Significant

"egra"ati

on

Bon9

res!onsi+e or

unsu!!orta-l

e

Ju"get

o+erru

n li/ely

?nachie+a-le

Crtcal Conse3uence of

error

Woul" "egra"e

!erformance to a !oint

where mission success

is 3uestiona-le

Results in

o!erational "elays

an" or increase"

cost with e2!ecte"

+alue of 1779

#77Conse3uence of

failure to achie+e

"esire" result

Some

re"uction

in

technical

!erforman

ce

Minor "elays Possi-l

e

o+erru

n

Possi-le

sli!!age

Margnal Conse3uence of

error

Result in "egra"ation of

secon"ary mission

,2!ecte" +alue

U177Conse3uence of

failure to achie+e

Small

re"uction

Res!onsi+e Sufficie

nt

Realistic


43/73

"esire" result financi

al

resour

cesNeglg+le Conse3uence of

error

Incon+enience Minor

Conse3uence of

failure to achie+e

"esire" result

Bo

re"uction

Su!!orta-le Ju"get

un"er

run

!ossi-l

e

achie+a-le

Rs& Projecton

Ris/ !rojection is concerne" with ris/ estimation. It attem!ts to rate ris/s in two

ways: li/elihoo" an" conse3uences. There are four ris/ !roject acti+ities. These

are:

3 ,sta-lish a scale that reflects the !ercei+e" li/elihoo" of ris/

3 *elineate the conse3uences

3 ,stimate im!act

3 Bote the o+erall accuracy of ris/ !rojection

This !rocess is e2em!lifie" with the hel! of the following ta-le:

Ris/ Category Pro-a-ility Im!act RMMM


44/73

Si5e estimate may -e significantly low

$arger num-er of users than !lanne"

$ess reuse than !lanne"

,n"9users resist system

*eli+ery "ea"line will -e tightene"

Fun"ing will -e lost

Customer will change re3uirements

Technology will not meet e2!ectations

$ac/ of training on tools

Staff ine2!erience"

Staff turno+er will -e high

PS

PS

PS

J?

J?

C?

PS

T,

*,

ST

ST

78

'78

78

(78

#78

(78


45/73

ASSESSIN6 RISG IMPACT

%ssessment of ris/ im!act is a non9tri+ial !rocess. Factors affecting the

conse3uences are the nature4 sco!e4 an" timing.

For each ris/ an e2!osure is calculate" as follows:

RE H Pro+a+lt$ of t(e rs& / Cost

This ris/ e2!osure is then use" to i"entify the to! ris/s an" mitigation strategies.

%s an e2am!le4 let us consi"er the following case:

E Ris/:

0nly 78 of the software com!onents sche"ule" for reuse will4 in

fact4 -e integrate" into the a!!lication. The remaining functionality

will ha+e to -e custom "e+elo!e".

E Ris/ Pro-a-ility


46/73

1. Certain reusa-le com!onents were "e+elo!e" -y 'r" !arty with no

/nowle"ge of internal "esign stan"ar".

&. *esign stan"ar" for com!onent interfaces has not -een soli"ifie" an"

may not conform to certain e2isting com!onents.

'. Certain reusa-le com!onents ha+e -een im!lemente" in a language that

is not su!!orte" on the target en+ironment.

We can now ta/e the following measures to mitigate an" monitor the ris/:

1. Contact 'r" !arty to "etermine conformance with "esign stan"ar"s.

&. Press for interface stan"ar" com!letionV consi"er com!onent structure

when "eci"ing on interface !rotocol.

'. Chec/ to "etermine if language su!!ort can -e ac3uire".

This lea"s us to the following Management>Contingency Plan:

1. R, com!ute" to 14((74777. %llocate this amount within !roject

contingency cost.

&. *e+elo! re+ise" sche"ule assuming 1< a""itional com!onents will ha+e

to -e custom9-uilt

'. %llocate staff accor"ingly

Rs& Mtgaton Montorng an' Management JRMMMK

The RMMM !lan assists the !roject team in "e+elo!ing strategy for "ealing with

ris/. In this conte2t4 an effecti+e strategy must consi"er:

Ris/ a+oi"ance

Ris/ monitoring


47/73

Ris/ management an" contingency !lan

It must always -e remem-ere" that a+oi"ance is always the -est strategy.

%s an e2am!le4 let consi"er the following scenario. In this case high turn9o+er

has -een i"entifie" as a ris/ with the following characteristics:

E Ris/ r j 9 Aigh turno+er

E $i/elihoo" ljN 7.

E Im!act 2j 9 !rojecte" at le+el & criticalD

$et us now "e+ise a mitigation strategy for re"ucing turno+er. In or"er to "o so4

the following ste!s may -e ta/en:

E Meet with current staff to "etermine causes for turno+er e.g. !oor wor/ing

con"itions4 low !ay4 com!etiti+e jo- mar/etD

E Mitigate those causes that are un"er our control -efore the !roject starts

E 0nce the !roject commences4 assume turno+er will occur an" "e+elo!

techni3ues to ensure continuity when !eo!le lea+e

E 0rgani5e !roject teams so that information a-out each "e+elo!ment

acti+ity is wi"ely "is!erse"

E *efine "ocumentation stan"ar"s an" esta-lish mechanisms to -e sure

that "ocuments are "e+elo!e" in a timely manner to ensure continuityD

E Con"uct !eer re+iews of all wor/ so that more than one !erson is u! to

s!ee"D

E %ssign a -ac/u! staff mem-er for e+ery critical technology


48/73

0nce the strategy has -een "e+ise"4 the !roject must -e monitore" for this

!articular ris/. That is4 we must /ee! an eye on the +arious factors that can

in"icate that this !articular ris/ is a-out to ha!!en. In this case4 the factors coul"

-e:

E 6eneral attitu"e of team mem-ers -ase" on !roject !ressures

E The "egree to which the team is jelle"

E Inter!ersonal relationshi!s among team mem-ers

E Potential !ro-lems with com!ensation an" -enefits

E The a+aila-ility of jo-s within the com!any an" outsi"e it

%lso4 the effecti+eness of the ris/ mitigation ste!s shoul" -e monitore". So4 in

this e2am!le4 the PM shoul" monitor "ocuments carefully to ensure that each

can stan" on its own an" that each im!arts information that woul" -e necessary

if a newcomer were force" to join the software team somewhere in the mi""le of

the !roject.

Rs& Management an' Contngenc$ Plan

Ris/ management an" contingency !lanning assumes that mitigation efforts

ha+e faile" an" that the ris/ has -ecome a reality.

E Ris/ has -ecome a reality some !eo!le announce that they will -e

lea+ing

E If mitigation strategy has -een followe"4 -ac/u! is a+aila-le4 information

has -een "ocumente"4 an" /nowle"ge has -een "is!erse"

E Tem!orarily refocus an" rea"just resources


49/73

E Peo!le who are lea+ing are as/e" to sto! all wor/ an" ensure /nowle"ge

transfer


50/73

S3%T4ARE PR35ECT SC


51/73

Software Project Sc(e'#lng

Software !roject sche"uling is an acti+ity that "istri-utes estimate" effort across

the !lanne" !roject "uration -y allocating the effort to s!ecific software

engineering tas/s.

It is im!ortant to note that the sche"ule e+ol+es o+er time. *uring early stages of

!roject !lanning4 a macrosco!ic sche"ule is "e+elo!e". This ty!e of sche"ule

i"entifies all major S, acti+ities an" the !ro"uct functions to which they are

a!!lie". %s the !roject gets un"erway these tas/s are refine" into a "etaile"

sche"ule.

In or"er to come u! with a realistic sche"ule4 the following -asic !rinci!les are

use":

3 Com!artmentali5ation: The !roject must -e com!artmentali5e" into a num-er

of managea-le acti+ities an" tas/s. To accom!lish com!artmentali5ation4

-oth the !ro"uct an" !rocess are "ecom!ose".

3 Inter"e!en"ency: The inter"e!en"ency of each com!artmentali5e" acti+ity or

tas/ must -e "etermine". Some tas/s must occur in se3uence while others

can occur in !arallel. Some acti+ities cannot commence until the wor/

!ro"uct !ro"uce" -y another is a+aila-le.

3 Time allocation: ,ach tas/ to -e sche"ule" must -e allocate" some num-er

of wor/ units e.g. !erson9"ays of effortD. In a""ition4 each tas/ must -e

assigne" a start "ate an" an en" "ate which is a function of the

inter"e!en"encies an" num-er of resources.


52/73

3 ,ffort +ali"ation: ,+ery !roject has a "efine" num-er of staff mem-ers. %s

time allocation occurs4 the !roject manager must ensure that no more than

the allocate" num-er of !eo!le has -een sche"ule" at any gi+en time.

3 *efine" res!onsi-ilities: ,+ery tas/ shoul" -e assigne" to a s!ecific team

mem-er.

3 *efine" outcomes: ,+ery tas/ shoul" ha+e a "efine" outcome4 normally a

wor/ !ro"uct.

3 *efine" milestones: ,+ery tas/ or grou! of tas/s shoul" -e associate" with a

!roject milestone.


53/73

RE;ATI3NS&

Bow4 if the communication o+erhea" !er channel is /4 then wor/ accom!lishe" is

gi+en -y:

W N 19/DC2 B

This !henomenon is "e!icte" in the following "iagram:


54/73

It may -e note" here that with only a #8 communication o+erhea" !er channel4

the total wor/ accom!lishe" -y a team of !eo!le woul" -e less than the

+olume of wor/ com!lete" -y a team of ( !eo!le. It is also interesting to note

that it a!!roaches 7 as the team si5e a!!roaches &7.

Tas& Set Defnton

% !rocess mo"el "efines a tas/ set which com!rises of S, wor/ tas/s4

milestones4 an" "eli+era-les. This ena-le a software team to "efine4 "e+elo!4

an" su!!ort the software.

Therefore4 each software !rocess shoul" "efine a collection of tas/ sets4

"esigne" to meet the nee"s of "ifferent ty!es of !rojects. To "etermine the set of

tas/s to -e !erforme" the ty!e of the !roject an" the "egree of rigor re3uire"

nee"s to -e esta-lishe". *ifferent ty!es of !rojects an" "ifferent "egree of rigor.

These !rojects coul" fall into the following categories:

E Conce!t "e+elo!ment !rojects

E Bew a!!lication "e+elo!ment

E %!!lication enhancement

E %!!lication maintenance

E Reengineering !rojects

The "egree of rigor can also -e categori5e" as Casual4 Structure"4 Strict4 or

)uic/ Reaction. The following !aragra!hs ela-orate each one of these.


55/73

E Casual: %ll !rocess framewor/ acti+ities are a!!lie"4 -ut only a minimum

tas/ set is re3uire". It re3uires re"uce" um-rella tas/s an" re"uce"

"ocumentation. Jasic !rinci!les of S, are howe+er still followe".

E Structure": In this case a com!lete !rocess framewor/ is a!!lie".

%!!ro!riate framewor/ acti+ities4 relate" tas/s4 an" um-rella acti+ities to

ensure high 3ualityD are also a!!lie". S)%4 SCM4 "ocumentation4 an"

measurement are con"ucte" in streamline" manner.

E Strict: In this case a full !rocess is im!lemente" an" all um-rella acti+ities

are a!!lie". The wor/ !ro"ucts generate" in this case are ro-ust.

E )uic/ Reaction: This a!!roach is ta/en in case of an emergency. In this

case only tas/ essential for maintaining goo" 3uality are a!!lie". %fter the

tas/ has -een accom!lishe"4 "ocuments are u!"ate" -y -ac/9filling.

The ne2t 3uestion is how to "eci"e a-out the "egree of rigor. For this !ur!ose an

a"a!tation criterion has -een "e+elo!e". The following !arameters are

consi"ere" -efore a "ecision is ma"e:

E Si5e of the !roject

E Bum-er of !otential users

E Mission criticality

E %!!lication longe+ity

E Sta-ility of re3uirements

E ,ase of customer>"e+elo!er communication

E Si5e of the !roject

E Bum-er of !otential users

E Mission criticality


56/73

E %!!lication longe+ity

E Sta-ility of re3uirements

E ,ase of customer>"e+elo!er communication


57/73

PART - )

CASE ST9D=

3%

T


58/73

S9MMAR= 3% T


59/73

These are the mem-ers who are in"ustrial organi5ations who woul" li/e to refer

-oo/s in the li-rary.

0+er the years it is felt that the circulation function of this li-rary is not

satisfactory -y the +arious regions which a!!ear to contri-uting to the !ro-lem.

Function in+ol+e" lot of -oo/ /ee!ing lot of recor" ha+e to -e carrie" a-out

-oo/s which ha+e -een issue" when they ha+e -een issue" an" the signature of

the !eo!le to whom they ha+e -een issue". These are a /in" of -oo/ /ee!ing

which nee"s to -e "one in the fast. The function also getting core ser+ice to the

users where as we often sees the long 3ueues. Many !eo!le in the li-rary are

tie" u! for this tas/. So for this reasons the circulation function is not -een

consi"ere" as "oing +ery satisfactorily.

So at this !oint the li-rarian thin/s that com!uteri5ation coul" -e the solution to

the !ro-lems. Aowe+er we shoul" note that what is -een mentione" is a solution

not a !ro-lem an" in"ee" +erify the !ro-lem that we ha+e i"entifie" in fact we

first esta-lish that the !ro-lem i"entifie" are in"ee" the once which is causing

the !ro-lem.

The analysis is calle" to in+estigator o!te" for the !ur!ose of the case stu"y the

analyst or the "e+elo!ment agencies it will -e consi"ere" goo" i"ea to han"le

the entire !roject. To "o the "e+elo!ment acti+ity as a !art of a contract so that

the entire metho"ology is sic/ly followe" an" all the "eli+era-les are !ro"uce"

an" the re+iews are carrie" out systematically. So a"+antage of ha+ing an


60/73

e2ternal agency is that the whole tas/ is carrie" out in a +ery systematic !assion

rather then "oing it in house -y the !rogrammers who may not follow the

metho"ology +ery thoroughly so although here it is mentione" some from the

com!uter ser+ices section is -uilt an" can -e calle". We will assume that at

e+ery ste! we will ha+e +ery "efinite /in" of commitment from these !ersons to

"e+ol+e the a!!lications for the li-rary.

The real o-jecti+e of the analyst is to fin"

% really efficient an" cost effecti+e solution to the /in" of !ro-lems the

li-rarian has notice"

Jenefit an" cost must -e i"entifie" to the solution that we might -e

!ro!ose"

The analyst must focus on the !ro-lem an" the solution which is a""ressing to

those !ro-lems. The !ro-lem is mainly efficiency an" the cost effecti+eness.

DE%INE T


61/73

/in" of organi5ation it is. Bow we are also seen the /in" of !ro-lem the li-rarian

has mentione". the way at this !oint trying to gi+e an i"ea of the sco!e of the

!roject to the li-rarian how much may it cost to li-rary to sol+e such a !ro-lem

an" where com!uteri5ation can coul" -e a solution so at this !oint the li-rary

in"icates it can s!eare" a-out

T


62/73

The stu"y of the e2isting system will com!lete" -y ntervewng t(e #sers 4

fin"ing out tas/s to -e !erforme" 4 amount of the "ata han"ling re3uire" an" the

!ro-lems they were facing -y the e2isting System.

?sers:

1. The assistant li-rarian

&. The counter cleric

'. Stu"ents

(. Staffs

Tas/ to -e !erforme":

1. Issue a -oo/

&. Return a -oo/

'. Claims for -oo/s

(. Fine han"ling for the late returnsD

#. Aan"ling user en3uiries to whom the -oo/ is issue" 4 how many -oo/s

are issue" to themD

. Regular re!orts for li-rarian the use of -oo/s4 situation a-out the fineD

Pro+lems7

Why the !ro-lems are face" can -e stu"y -y un"erstan"ing the circulation rules

-ecause the "ifferent user ha+e "ifferent re3uirement a-out the num-er of the

-oo/s allowe" an" the !erio" of issue.

Pro-lem of the mem-ers li-rary usersD


63/73

1. $ong 3ueues

&. ?nacce!ta-le claim an" en3uiry ser+ice

Counter cler/@s !ro-lem

1. ,2cessi+e -oo/ /ee!ing : "ate9stam!ing an" signatures at (9#

!laces

Herification !ro-lem

1. )uota e2cee"ing

&. Signatures +erification

'. *elaye" returns

(. Claim han"ling

#. ,n3uiries

Management or a"ministration !ro-lems

1. Aan"ling of the re!orts an" the statistics "one -y the li-rarian is

inefficient or un satisfactory

&. Time to gi+e such re!orts

'. Pro-lem of o+er"ue -oo/s

(. Pro-lem of the lost -oo/s


64/73

Signing -oo/ an" mem-er car" at issue time is also a !ro-lem how to /ee!

recor" of the -oo/s an" issue function of the li-rary. The !ossi-le alternati+e for

the issue is mem-er car" shoul" -e fi2e" for a -oo/ an" nee" to -e !ut -ac/ in

-oo/ !ouch. %nother o!tion is it can -e use for any -oo/ an" the sli! serial

num-ers recor"e" in "ata-ase an" release it at the time of the return. The

alternati+e shoul" -e e+aluate" -ase on the "u!lication function. It shoul" -e

consi"ere" -ase" on the Remo+ing that "u!lication.

The other !ossi-le alternati+e is /ee! rows of trays containing -oo/ an" mem-er

car"s /e!t at counter. So now we will -e re3uire" to !re!are the "ata flow

"iagrams as other !roce"ures are o-+ious.

%fter o-taining the general #n'erstan'ng of t(e e/stng s$stemsa-out the

tas/ to -e !erforme" -y the "ifferent entities an" what shoul" -e "one an" -y


65/73

whom shoul" -e "one an" the issues relate" to the "ifferent acti+ities. Bow we

will try to recor" the fin"ings. We will use the tools that -ring our un"erstan"ing

to the fusi-le state. We will fin" out the "ata in+ol+e"4 su- tas/s to -e !erforme"4

an" the !rocesses.

P3SSI8;E S3;9TI3N AND C3ST 8ENE%IT ANA;=SIS

Bow we can go for the !ossi-le solution at the high le+el an" thin/ out the

alternatve. %s we ha+e carrie" out the main reasons contri-uting to !ro-lems.

We note "own them so that we can /now that they shoul" -e a''resse' +$ t(e

entre alternatvewe are consi"ering or not.

The first reason contri-uting to the !ro-lem is the '#plcaton"ue re3uirement

of two mo"es of accessing. %s the "ata is to -e accessi-le -oth -y the user an"

the counter cler/4 who are using the accession num-er of the -oo/. Secon" is -y

using the mem+er 'entfcaton. Jecause as the "u!lication increases the

wor/ at the counter.

The secon" reason is the en#r$ an' t(e ret#rn processng. It is re3uire" that

the -oo/ an" the mem-er car"s are to -e locate" an" !ut -ac/ in -oo/ or tray or

return it to the user after the "ue cancelation. In this !rocess4 first the tray has to

-e searche" then we nee" to ta/e out the car" from the -oo/ an" ta/e out the

car" of the mem-er. so this acti+ities ta/e time an" there for a 3ueue of !eo!le

easily -uil" u!.


66/73

MAIN C


67/73

A;TERNATI>E -1 ;AN 8ASED S3;9TI3N

The one alter nati+e is installing the (7 6J ser+er with ' wor/ stations. The "ata

entry is "one mostly -y entering the mem-er i"s an" accession num-ers through

the /ey-oar" at counter. Which is actually not +ery significant -ecause most of

the time they ha+e to enter the i"s an" the accession num-er when the issue

an" the return of the -oo/ is ta/ing !lace so we woul" consi"er an o!tion where

the "ata entry at the counter will -e manual. Bow we will loo/ after the cost

in+ol+e" in this.

Costs:

1. Systems : Rs. (.77 $a/hs

&. *JMS : Rs. 7.&7 $a/hs

'. %!!lication software "e+elo!ment : Rs. 7.'7 $a/hs

(. Initial -oo/ an" mem-er "ata entry : Rs. &.#7 $a/hs

Total: Rs. .77 la/hs

A;TERNATI>E -) ;AN 8ASED 4IT< 8ARC3DE DATA ENTR=

The main a"+antage of this alternati+e will -e further re"uction in the time for

users at counter. Jut this will -rings out more cost or say a""itional in+estment.


68/73

RE"9IREMENT ANA;=SIS

To "etermine what e2actly the system has to "o4 we ha+e to *efine" in!uts4

out!uts4 !rocessing of the e2isting system that are *etaile" enough for "esign

wor/.

So I first start with stu"y of the e2isting system in feasi-ility re!ort. We ha+e to

e2!an" the feasi-ility re!ort into further "etail an" ha+e to Com!ile list of all "ata

elements in in!uts4 out!uts4 an" s!ecify !rocessing "etails.

Then after as a !roject manager we ha+e to !re!are re3uirement s!ecification

an" we arrange" re+iewe" an" !re9re+iew of all user. For that we ha+e to Wor/

at logical le+el. We ha+e to un"erstan" an" em!hasi5e the system re3uirement.

We ha+e analy5e" what is the nee" to -e "one. %n" note" how it can -e "one.

Then I ?se "ifferent a!!ro!riate tools to store the fin"ings such as "ata flow

"iagram. % "ata flow "iagram contains flow of "ata an" relationshi!s -etween

in!uts4 out!uts an" !rocess. % "ata flow "iagram contains *ata "ictionary which

contains "ata "escri!tions an" Proce"ures as flow9charts4 "ecision ta-les4 or

!seu"o9language "escri!tion.

Contains of "ata store -oo/@

o %cc. Bo.

o %uthors

o Price

o ISJB

o Pu-lisher


69/73

o Classification

o Title

o Xear

o Joo/9ty!e

Bote: 9 Joo/ ty!e in"icates -oo/ category that may ha+e issue

restriction only to certain mem-er categories an" for certain

!erio"sD

Content of the "ata store mem-er

o I"

o Bame

o *e!t

o Category

o Termination9"ate

Bote9 category "efines !ri+ileges of mem-er no. of

-oo/s4 !erio" of issues 4 etc.D

Content of the "ata store ISS?,

o I"

o %cc. Bo.

o Issue "ate

o *ue "ate

o Return "ate

o Fine

Content of the "ata store claim@

o I"


70/73

o %cc. Bo.

o Claim9"ate

Refinement of issue !rocess

o B0T,S:

Claim "ata is mo"ifie" if an issue is against claim ma"e

earlier

no@ res!onse coul" -e gi+en -y any +ali"ate !rocess

Refine further where necessary

Interact with to o-tain !roce"ural an" "ata "etails

Pre!are re3uirement s!ecification "ocument


71/73

E/ample of 0RE"9IREMENT SPECI%ICATI3N2

%JSTR%CT: the system to -e "e+elo!e" will han"le issuing of -oo/s to

mem-ers of li-rary. 0ther im!ortant an" associate" tas/s are -oo/ claims

an" fines for late returns. This "ocument follows I,,, stan"ar"s format.

1. IBTR0*?CTI0B

1.1.P?RP0S,: This "ocument "escri-es functional tas/s4 user interfaces

an" main "ata "omains for the -oo/ circulation system

1.&.Sco!e: this "ocument acts as a -ase line for re3uirements "efinition an"

any changes must go through a formal change !rocess. This system will

-e referre" as CIRC?$%TI0B system4 whose major goals are re"uction

of costs an" ser+ice to4 mem-ers. It inclu"es an e2tensi+e "ata entry

effort for all -oo/s in the li-rary.

1.'.*efinition4 acronyms: not a!!lica-le

1.(.References: feasi-ility "ocument "ate" %!ril 14 1==


72/73

1..Pro"uct !ers!ecti+e : it is a stan"9alone an" self9containe" !ac/age V no

interfaces to other systems

&. Pro"uct functions : o+er+iew of these functions:

&.1.1. Maintain "ata a-out mem-ers an" ty!e of feasi-ilities allowe" to

them categoryD

&.1.&. Maintain "ata a-out -oo/s an" restrictions on their issuing ty!eD

&.1.'. Joo/ issue: issue a -oo/ !ro+i"e" category an" ty!e +ali"ations

are met4 com!uter "ue "ate for return4 ta/ing into account holi"ays4

summer +acation is treate" as holi"ays.

&.&.Pro"uct functions: o+er+iew of these functions:

&.&.1.1. Claims !rocessing: u! to ' claims>-oo/ an" # claims>user

are !ermitte". Claims acce!te" only for claims on -oo/. Issue

against claim u!"ates claims "ata.

&.&.1.&. ,n3uiry re!orts: +arious online4 "etail an" summary

en3uiries on mem-ers4 -oo/s4 issues an" claims will -e

!ro+i"e" for -oth mem-ers an" management.

&.&.1.'. Fine !ayments>lost -oo/s4 etc. are a""itional functions to -e

im!lemente".

&.'.?ser characteristics: main users are counter cler/s

issues>return>claim>fineD4 mem-ers can use for en3uiry. ?sers4 -eing

from a !remier technical institute 4 are literate a-out com!uters

&.(.6eneral constraints : nil a-out e2isting systems

&.#.%ssum!tion an" "e!en"encies: not a!!lica-le

'. S!ecific re3uirements: this section "escri-es the recei+ing functional

re3uirements4 !erformance re3uirements4 "esign constraints4 etc.


73/73

'.1.Functional re3uirements : we gi+e here 4 for each function4 its "escri!tion

4 in!uts4 !rocessing an" out!uts4 in!uts which are largely common nee"

-e "escri-e" only once

'.&.Files: "escri-e here contents of all major file>"ata stores i.e. mem-er4

-oo/4 issue an" claims D. $eft as e2ercise

'.'.Function: the circulation system is -asically an on9line transaction

!rocessing system. The im!ortant transaction an" corres!on"ing system

tas/s are:

'.'.1. Joo/ issue : gi+en mem-er@s i" an" acc no of a -oo/ 4 issue the

-oo/ !ro+i"e" the following con"itions are met:

'.'.&. The ty!e of -oo/ is !ermitte" for the mem-er

'.'.'. Mem-er has not finishe" her 3uota of -oo/s

'.'.(. There is currently no claim on the -oo/ -y any other mem-er

'.(.Performance re3uirements : this may -e gi+en in terms of static an"

"ynamic re3uirements

'.(.1. Statics

Bum-er of terminate to -e su!!orte": (

- Bum-er of simultaneous users : (

- Bum-er of files to -e han"le" :

'.(.&. File si5es

9Mem-er: M

x software development project management

Documents