You are on page 1of 73

A REPORT ON COMPREHENSIVE PROJECT WORK

SOFTWARE DEVLOPMENT PROJECT MANAGEMENT

Submitted to

INDUKAKA IPCOWALA INSTITUTE OF MANAGEMENT (I IM! CHAROTAR UNIVERSIT" OF SCIENCE AND TECHNOLOG" (CHARUSAT! CHANGA

P#e$%#ed b& RAJESH PATEL ID No: 09MBA59 MBA Second Ye ! U'de# t(e Guid%')e o* M!" G" #" #!$%& n '(!)$
No*e'+e! ,0-0

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 -"0" 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 Est mat on (. Software "#al t$ %actors /"-" Measuring )uality /"," *efect Remo+al ,fficiency #. Software Project Plann ng 5"-" Software Sco!e ,stimation 5"," Feasi-ility 5"." Software Project ,stimation .. R s& Anal$s s an' Management 0"-" Ty!es of Ris/s 0"," Ris/ I"entification

0"." %ssessing 0+erall Project Ris/s 0"/" Ris/ Com!onents an" *ri+ers 1. Software Project Sc(e'#l ng an' Mon tor ng 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 + l t$ st#'$ &.1. What is circulation function &.&. Stu"y the e2isting system &.'. Ste!s in the feasi-ility stu"y I followe". ,* Pro+lems anal$s s -* Poss +le sol#t on an' cost +enef t anal$s s (.1. Main characteristic of the software (.&. Re3uirement analysis .* E/ample of 0re1# rement spec f cat on2

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. Del ver$ 'ea'l ne7 *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"

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. Appl cat on 'oma n7 %!!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 constra nts7 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 re1# rements7 % system has to satisfy its user re3uirements. Failing to "o so woul" ren"er this system unusa-le.

Ava la+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 1. Staffing: how many !eo!le with what /in" of resources woul" -e nee"e" an" how that re3uirement coul" -e fulfille" <. 0ther resources: what other har"ware an" software resources woul" -e nee"e" for the !roject =. Project monitoring: how the !rogress of the !roject coul" -e monitore"

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 %a l: % !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 1. miscommunication among !roject staff <. failure in !roject management

The first two !oints relate to goo" re3uirement engineering !ractices. ?nsta-le user re3uirements an" continuous re3uirement cree! has -een i"entifie" as the to! most reason for !roject failure. %m-iguous an" incom!lete re3uirements lea" to un"esira-le !ro"uct that is rejecte" -y the user.

%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.

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.

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 CtechnicalD 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.

Mot vat on is the a-ility to encourage technical !eo!le to !ro"uce to their -est.

3rgan !at on is the a-ility to mol" the e2isting !rocesses Cor in+ent new onesD that will ena-le the initial conce!t to -e translate" into a final !ro"uct4 an" I'ea or Innovat on is the a-ility to encourage !eo!le to create an" feel creati+e.

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:

Pro-lem Sol+ing F Shoul" -e a-le to "iagnose technical an" organi5ational issues an" -e willing to change "irection if nee"e".

Managerial I"entity F Must ha+e the confi"ence to ta/e control when necessary

%chie+ement F Rewar" initiati+e Ccontrolle" ris/ ta/ingD an" accom!lishment

Influence an" team -uil"ing F 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 E E E the "ifficulty of the !ro-lem to -e sol+e" the si5e of the resultant !rogramCsD in lines of co"e or function !oints the time that the team will stay together Cteam lifetimeD the "egree to which the !ro-lem can -e mo"ulari5e"

E E E

the re3uire" 3uality an" relia-ility of the system to -e -uilt the rigi"ity of the "eli+ery "ate the "egree of socia-ility CcommunicationD 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 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 a tra"itional hierarchy of

Mantei suggests the following three generic team organi5ations: E *emocratic "ecentrali5e" C**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" CC*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

an" communication among su-grou!s an" in"i+i"uals is hori5ontal. Hertical communication along the control hierarchy also occurs. E Controlle" centrali5e" CCCD: 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' nat on an' Comm#n cat on 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".

Iraul 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.

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.

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 E ,lectronic communication inclu"es emails an" -ulletin -oar"s. 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.

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: F 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. F Maintain momentum: many !rojects4 after starting on the right4 loose focus an" momentum. The initial momentum must -e maintaine" till the +ery en". F 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. F Ma/e smart "ecisions F 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.<< Pr nc ple Jarry Joehm has suggeste" a systematic a!!roach to !roject management. It is /nown as the WWWWWAA !rinci!le. It com!rises of 1 3uestions. Fin"ing the answers to these 1 3uestions is essentially all a !roject manager has to "o. These are: E E E E 4<= is the system -eing "e+elo!e" 4<AT will -e "one Jy 4<EN 4<3 is res!onsi-le for a function

E E E

4<ERE they are organi5ationally locate" <34 will the jo- -e "one technically an" managerially <34 M9C< of each resource Ce.g.4 !eo!le4 software4 tools4 "ata-aseD will -e nee"e"

Joehm@s W#AA !rinci!le is a!!lica-le4 regar"less of the si5e an" com!le2ity of the !roject an" !ro+i"e e2cellent !lanning outline.

Cr t cal Pract ces The %irlie Council has "e+elo!e" a list of critical success !ractices that must -e !resent for successful !roject management. These are: E E E E E E Formal ris/ analysis ,m!irical cost an" sche"ule estimation Metrics9-ase" !roject management ,arne" +alue trac/ing *efect trac/ing against 3uality targets Peo!le aware !roject management

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.

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

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.

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 C$0CD

&. Bum-er of o-jects '. Bum-er of 6?Is (. Bum-er of "ocument !ages #. Functional !oints CFPD

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"

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!erMs !ers!ecti+e while the F?BCTI0B P0IBTS is a measure of the si5e of the functionality from the userMs !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.

%#nct on Po nt Anal$s s @ 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

Contract Begotiations

Following is a list of some of the F?BCTI0B P0IBTS -ase" metrics use" for these !ur!oses: Si5e F Function Points *efects F Per Function Point ,ffort F Staff9Months Pro"ucti+ity F Function Points !er Staff9Month *uration F Sche"ule CCalen"arD Months Time ,fficiency F Function Points !er Month Cost F Per Function

S3%T4ARE "9A;IT= %ACT3RS

In 1=1<4 McCall i"entifie" factors that coul" -e use" to "e+elo! metrics for the software 3uality. These factors try to assess the inner 3uality of software from factors that can -e o-ser+e" from outsi"e. The -asic i"ea is that the 3uality of the software can -e inferre" if we measure certain attri-utes once the !ro"uct is !ut to actual use. 0nce com!lete" an" im!lemente"4 it goes through three !hases: o!eration Cwhen it is use"D4 "uring re+isions Cwhen it goes through changesD4 an" "uring transitions Cwhen it is !orte" to "ifferent en+ironments an" !latformsD.

*uring each one of these !hases4 "ifferent ty!es of "ata can -e collecte" to measure the 3uality of the !ro"uct. McCall@s mo"el is "e!icte" an" e2!laine" as follows.

%actors relate' w t( operat on 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' w t( rev s on E E E Maintaina-ility: ,ffort re3uire" to locate an" fi2 an error in a !rogram Fle2i-ility: ,ffort re3uire" to mo"ify an o!erational !rogram Testa-ility: ,ffort re3uire" to test a !rogram to ensure that it !erforms its inten"e" function

%actors relate' w t( a'aptat on 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.

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#r ng "#al t$ 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>I$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 F 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.

% 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/ C-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 C"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 PC19threatD 2 C19securityDQ

Finally4 usa-ility is a measure of user frien"liness F 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

E E E

The time re3uire" to -ecome mo"erately efficient in the use of system The net increase in !ro"ucti+ity % 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 Eff c enc$ *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 ,>C,K*D Where E E , F errors foun" -efore "eli+ery * F errors foun" after "eli+ery Cty!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==1 which is summari5e" in the following ta-le.
Des gn Inspect on Co'e Inspect on "#al t$ Ass#rance Test ng 4orst Me' an 8est

,AB ,CB .AB ..B D.B C.B CCB E.B F.B -AB .,B D.B CAB EAB ECB FAB FCB FFB .AB DAB C.B EAB ECB F,B F.B FFB FF*FB

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 =18. That means4 co"e an" "esign ins!ection are e2tremely im!ortant acti+ates that are unfortunately not gi+en their "ue im!ortance.

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 est mat on 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 E E Who is -ehin" the re3uest Cs!onsorD Who will use the solution CusersD What are the economic -enefits CwhyD

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 E E E Aow woul" you characteri5e goo" out!ut What !ro-lems will the solution a""ress Can you show me the en+ironment in which the solution will -e use" 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 :official; E E E E %re my 3uestions rele+ant to the !ro-lem that you ha+e %m I as/ing too many 3uestions Can anyone else !ro+i"e a""itional information Shoul" I -e as/ing you anything else %re answers

In this regar"s4 a techni3ue /nown as %ac l tate' Appl cat on Spec f cat on Tec(n 1#es or sim!ly %AST can -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 + l t$ The !ur!ose of the feasi-ility analysis is to "etermine can we -uil" software to meet the sco!e "imensions: For this !ur!ose4 the !roject is analy5e" on the following (

Technology 3 3 3 Is the !roject technically feasi-le Is it within the state of the art Can "efects -e re"uce" to a le+el matching the a!!lication nee"s

Finance 3 3 Is it financially feasi-le Can "e+elo!ment -e com!lete" at a cost that software organi5ation4 its client4 or the mar/et can affor" Time 3 3 Will the !roject time to mar/et -eat the com!etition 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 3 3 AW>SW tools Reusa-le software com!onents Peo!le

Software Project Est mat on 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.

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.

Emp r cal 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 R Ce+DC where %4 J4 c are em!irical constants4 Se+@ is the effort in terms of lines of co"e or FP4 an" S,@ is the effort in terms of !erson months. The most famous of these mo"els is the C0C0M0 9 Constructi+e Cost Mo"el F mo"el. It also has many "ifferent +ersions. The sim!lest of these +ersions is gi+en -elow: , N '.& CI$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".

T(e Software E1#at on 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 P$0C 2 J7.'''>PQ' 2 C1>t(D Where: E E E , F effort in !erson months or !erson years t F !roject "uration in months or years J F s!ecial s/ill factor F Increases slowly as the nee" for integration4 testing4 )%4 "ocumentation4 an" management s/ills grow E P F !ro"ucti+ity !arameter F 0+erall !rocess maturity an" management !ractices F The e2tent to which goo" S, !ractices are use" F The le+el of !rogramming language use" F The state of the software en+ironment F The s/ills an" e2!erience of the software team F 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 3 3 0ff9the9shelf license" software Software com!onents to -e mo"ifie" an" integrate" into the a!!lication Su-9contract

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 E E ,stimate internal cost an" time to "e+elo! Select '9( can"i"ate a!!lications that -est meet your s!ecifications 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 E *eli+ery "ate *e+elo!ment Cost F %c3uisition K customi5ation E Maintenance Cost

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 F what ris/s might cause the !roject to go awry &. Change F 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 F 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 F In"iana Lones school of ris/ management F Be+er worrying a-out !ro-lems until they ha!!ene"4 an" then reacting in some heroic way F In"iana Lones style. E Proacti+e F Jegins long -efore technical wor/ starts F Ris/s are i"entifie"4 their !ro-a-ility an" im!act are analy5e"4 an" they are ran/e" -y im!ortance. F Ris/ management !lan it !re!are" E E Primary o-jecti+e is to a+oi" ris/ 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

?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 E ?ncertainty F the ris/ may or may not ha!!en $oss F 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 E E E What can go wrong What is the li/elihoo" of it going wrong What will the "amage -e What can we "o a-out it

T=PES 3% RISGS

,ach !roject is face" with many ty!es of ris/s. These inclu"e: E Project ris/s F Will im!act sche"ule an" cost F Inclu"es -u"getary4 sche"ule4 !ersonnel4 resource4 customer4 re3uirement !ro-lems E Technical ris/s F Im!act the 3uality4 timelines4 an" cost F Im!lementation may -ecome "ifficult or im!ossi-le F Inclu"es "esign4 im!lementation4 interface4 +erification an"

maintenance !ro-lems F $ea"ing e"ge technology E Jusiness ris/s F Mar/eta-ility F %lignment with the o+erall -usiness strategy F Aow to sell F $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".

R s& I'ent f cat on 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 risks are threats to e+ery !roject whereas Product specific risks are 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 E E E E E E Pro"uct si5e Jusiness im!act Customer characteristics Process "efinition *e+elo!ment en+ironment Technology to -e -uilt Staff si5e an" e2!erience

Assess ng 3verall Project R s&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"

E E E E E

Aa+e customers -een in+ol+e" fully in re3uirement "efinition *o en"9users ha+e realistic e2!ectations *oes the software team ha+e right mi2 of s/ills %re !roject re3uirements sta-le *oes the !roject team ha+e e2!erience with the technology to -e im!lemente"

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

R s& components an' 'r vers ,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 F *egree of uncertainty that the !ro"uct will meet its re3uirements an" -e fit for its inten"e" use E Cost ris/s F The "egree of uncertainty that the !roject -u"get will -e maintaine" E Su!!ort ris/s F Resultant software will -e easy to correct4 enhance4 an" a"a!t E Sche"ule ris/s F 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.

This is summari5e" in the following ta-le: R s& Impact Catastrop(Conse3uence of c error Performa S#pport nce Failure to meet the Cost Sc(e'#le

Results in increase"

re3uirements will result cost an" sche"ule in mission failure "elays. ,2!ecte" +alue in e2cess of

Conse3uence of failure to achie+e "esire" result Cr t cal Conse3uence of error

SignificantBon9

T#77I Ju"get ?nachie+a-le

"egra"ati res!onsi+e or o+erru on unsu!!orta-l n li/ely Results in

e Woul" "egra"e

!erformance to a !oint o!erational "elays where mission success an" or increase" is 3uestiona-le cost with e2!ecte" +alue of T177I9

Conse3uence of failure to achie+e "esire" result

Some re"uction in technical !erforman

T#77I Minor "elays Possi-l Possi-le e o+erru n sli!!age

Marg nal

Conse3uence of error Conse3uence of failure to achie+e

ce Result in "egra"ation of ,2!ecte" +alue secon"ary mission Small Res!onsi+e re"uction UT177I SufficieRealistic nt

"esire" result

financi al resour

Negl g +le Conse3uence of error Conse3uence of failure to achie+e "esire" result

Incon+enience Bo re"uction

ces Minor

Su!!orta-le Ju"get achie+a-le un"er run !ossi-l e

R s& Project on 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 3 3 3 ,sta-lish a scale that reflects the !ercei+e" li/elihoo" of ris/ *elineate the conse3uences ,stimate im!act 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

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 Where im!acts are co"ifie" as follows: 1: catastro!hic &: critical

PS PS PS J? J? C? PS T, *, ST ST

.78 '78 178 (78 #78 (78 <78 '78 <78 '78 .78

& ' & ' & 1 & 1 ' & &

': marginal

(: negligi-le

%n" RMMM stan"s for ris/ mitigation4 monitoring4 an" management !lan.

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+ l t$ of t(e r s& / 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/: F 0nly 178 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 E Ris/ Pro-a-ility F <78 li/ely Ci.e. 7.<D Ris/ im!act F .7 reusa-le software com!onents were !lanne". If only 178 can -e use"4 1< com!onents woul" ha+e to -e "e+elo!e" from scratch. Since the a+erage com!onent will cost 17747774 the total cost will -e 14<774777. E Therefore4 R, N 7.< R 14<774777 N 14((74777

% high le+el ris/ may -e refine" into finer granularity to han"le it efficiently. %s an e2am!le4 the a-o+e mentione" ris/ is refine" as follows:

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

R s& M t gat onI Mon tor ngI 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: F Ris/ a+oi"ance F Ris/ monitoring

F 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 E E

Ris/ rj 9 Aigh turno+er $i/elihoo" lj N 7.1 Im!act 2j 9 !rojecte" at le+el & CcriticalD

$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:

Meet with current staff to "etermine causes for turno+er Ce.g. !oor wor/ing con"itions4 low !ay4 com!etiti+e jo- mar/etD

E E

Mitigate those causes that are un"er our control -efore the !roject starts 0nce the !roject commences4 assume turno+er will occur an" "e+elo! techni3ues to ensure continuity when !eo!le lea+e

0rgani5e !roject teams so that information a-out each "e+elo!ment acti+ity is wi"ely "is!erse"

*efine "ocumentation stan"ar"s an" esta-lish mechanisms to -e sure that "ocuments are "e+elo!e" in a timely manner Cto ensure continuityD

Con"uct !eer re+iews of all wor/ Cso that more than one !erson is u! to s!ee"D

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

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 E E E E

6eneral attitu"e of team mem-ers -ase" on !roject !ressures The "egree to which the team is jelle" Inter!ersonal relationshi!s among team mem-ers Potential !ro-lems with com!ensation an" -enefits 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.

R s& Management an' Cont ngenc$ 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 F 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

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

S3%T4ARE PR35ECT SC<ED9;IN6 AND M3NIT3RIN6

Software !roject sche"uling is the ne2t tas/ to -e !erforme" -y the PM. It is im!ortant to note once again that in the reasons for !roject failure4 unrealistic "ea"line an" un"erestimate of effort in+ol+e" in the !roject are two of the most im!ortant reasons for !roject failure. Therefore4 a goo" sche"ule estimate woul" increase the chances of the success of the !roject.

In this conte2t4 a PM has to first come u! with the sche"ule an" then monitor the !rogress of the !roject to ensure that things are ha!!ening accor"ing to the sche"ule. It woul" not -e out of !lace to 3uote Fre" Jroo/s at this !oint. Ae says4 Projects fall behind schedule one day at a time. That means a "elay of a wee/ or a month or a year "oes not ha!!en su""enly F it ha!!ens one "ay at a time. Therefore4 a !roject manager has to -e +igilant to ensure that the !roject "oes not fall -ehin" sche"ule.

The reality of a technical !roject is that hun"re"s of small tas/s must occur to accom!lish a large goal. Therefore the Project manager@s o-jecti+es inclu"e:

F I"entification an" "efinition all !roject tas/s F Juil"ing a networ/ that "e!icts their inter"e!en"encies F I"entification of the tas/s that are critical within the networ/ F Trac/ing their !rogress to ensure "elay is recogni5e" one "ay at a time

For this4 the sche"ule must -e fine graine".

Software Project Sc(e'#l ng 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 Ce.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.

,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.

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

*efine" outcomes: ,+ery tas/ shoul" ha+e a "efine" outcome4 normally a wor/ !ro"uct.

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

RE;ATI3NS<IP 8ET4EEN PE3P;E AND E%%3RT

The relationshi! -etween the num-er of !eo!le an" time to "e+elo! an a!!lication is not linear. It is not as sim!le as a 1&7 man9"ay !roject can -e "e+elo!e" -y 1 !erson wor/ing for 1&7 "ays or 1&7 !eo!le wor/ing for 1 "ay. The communication an" coor"ination o+erhea" !lays a +ery significant role.

%s can -e recalle" from our earlier "iscussions4 total num-er of Channels of communication in+ol+ing B !eo!le is gi+en -y the following formula. C N BCB91D>& Bow4 if the communication o+erhea" !er channel is /4 then wor/ accom!lishe" is gi+en -y: W N C19/DC 2 B This !henomenon is "e!icte" in the following "iagram:

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 Def n t on % !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 E E E E Conce!t "e+elo!ment !rojects Bew a!!lication "e+elo!ment %!!lication enhancement %!!lication maintenance 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.

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".

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 Cto ensure high 3ualityD are also a!!lie". S)%4 SCM4 "ocumentation4 an" measurement are con"ucte" in streamline" manner.

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.

)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 E E E E E E E E Si5e of the !roject Bum-er of !otential users Mission criticality %!!lication longe+ity Sta-ility of re3uirements ,ase of customer>"e+elo!er communication Si5e of the !roject Bum-er of !otential users Mission criticality

E E E

%!!lication longe+ity Sta-ility of re3uirements ,ase of customer>"e+elo!er communication

PART - ) CASE ST9D= 3% T<E ;I8RAR= 833G CIRC9;ATI3N %9NCTI3N JSoftware DevelopmentK

S9MMAR= 3% T<E CASE ST9D=

In this case we will stu"y the software "e+elo!ment metho"ology. The !ur!ose of the case stu"y is to illustrate the entire "e+elo!ment life cycle. We will loo/ at how the "ifferent !hases that we will i"entify can -e a!!lie" systematically ste! -y ste! in "e+elo!ing a software a!!lication. The main !ur!ose of the case stu"y is to focus on the metho"ology. What are the "eli+era-les What ste!s an"

techni3ues we shoul" go through The i"ea is to un"erstan" the entire !rocess of "e+elo!ment4 engineering !rocess an" !roject "e+elo!ment !rocesses. %n" see that how +arious "eli+era-le are !ro"uce" an" re+iewe" an" then only we follow the su-se3uent !hases of the "e+elo!ment so this case stu"y is a case stu"y on li-rary a!!lication. It@s a!!lication where the li-rary han"les the issues an" recei+ing of -oo/s from the user of the li-rary. So this is a realistic a!!lication an" the way it has -een !resente" is the way it can -e "one an" it shoul" -e "one.

Bow the organi5ation we coul" -e tal/ing here is li-rary of any uni+ersity or collage. $et us assume that it is a li-rary at the CA%R?S,T4 CA%B6%. Whose main function are -uying -oo/ for its users also -uying generals !erio"ically. They also ha+e a function calle" -oo/ circulation function which issues -oo/s to the mem-ers of the li-rary. It is one of the largest li-rary ha+ing more than ' la/h -oo/s an" em!loyees a-out #7 !ersons. This is the organi5ation which has the circulation functions. Its users are the faculty an" the staff as well as the stu"ents who are stu""ing in this institute in a""ition it has cor!orate mem-ers.

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

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<E SC3PE So the first thing that the analyst to "o of this ty!e to getting a statement of the !ro-lem from the li-rarian an" "oing some -ac/groun" chec/ing. What /in" of the organi5ation it is an" What /in" of acti+ities are inclu"ing in the circulation function.

The -est thing that the analyst shoul" "o is to "efine the !roject sco!e. Bow since this is the organi5ation which is 3uite regularly un"erstoo" -y the li-rarian whose main !ur!ose is to issues -oo/s to the users. So from that we /now what

/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<E %EASI8I;IT= ST9D= 4<AT IS CIRC9;ATI3N %9NCTI3N: The main !ro!ose of the !re!aring the feasi-ility stu"y is the assuming the !ossi-le solution an" e+aluating the gi+en solution an" ma/ing the

recommen"ation in limite" time. %lso ta/e in the account the cost an" efforts. The time an" the cost stu"y will -e "one -y the e2ternal agency. First we will start -y clearly un"erstan"ing the o-jecti+es.

ST9D= T<E EXISTIN6 S=STEM 1. What tas/ are to -e !erforme" &. What are the reasons for the !ro-lems

STEPS IN T<E %EASI8I;IT= ST9D= I %3;;34ED* 1. Ma/e the logical mo"el for the !ro!ose" system &. Consi"er the alternati+es '. For each alternati+e analy5e them CTechnical feasi-ility4 economic feasi-ilityD (. Ma/e the recommen"ation an" "e+elo! a !lan of action for the !roject

The stu"y of the e2isting system will com!lete" -y nterv ew ng 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"lingC for the late returnsD #. Aan"ling user en3uiries C to whom the -oo/ is issue" 4 how many -oo/s are issue" to themD .. Regular re!orts for li-rarian C 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 Cli-rary usersD

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

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/ st ng s$stems a-out the tas/ to -e !erforme" -y the "ifferent entities an" what shoul" -e "one an" -y

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 alternat ve. %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 ent re alternat ve we are consi"ering or not.

The first reason contri-uting to the !ro-lem is the '#pl cat on "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 'ent f cat on. Jecause as the "u!lication increases the wor/ at the counter.

The secon" reason is the en1# r$ an' t(e ret#rn process ng. 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!.

MAIN C<ARACTERISTIC 3% T<E S3%T4ARE 1. It is !rimarily an online system: -oo/s to -e issue" an" return in front of them. &. Issue4 return an" claims are all -asic tas/s: so !artial automation is meaningless -ecause either all nee"s to -e "one or all !ro-a-ly left for the manually system .it signifies that we cannot consi"er the alternati+e -ase" on the sco!e of the automation. '. Signe" recor"s shoul" -e /e!t: recor" of the issue must -e /e!t -oth to confirm signatures an" for legal !ur!ose until -oo/ is returne". (. We might thing of the other high cost alternati+e that the other "i+ision of the li-rary can -e ma/ing for the -oo/ circulation function.

Jase" on the characteristic of the re3uirement the poss +le propose' alternat ve at !hysical le+el or say the technical alternati+es. 1. Ser+er o!tion : ?BIW 4 $IB?W4 WIB*0WS &. $%B with ' or ( no"es '. *ata entry using -ar co"es (. *ata -ase management system or con+entional file -ase" system #. Aan"ling of the signe" recor"s

Be2t ste! after this is analyses the each of the alternati+e -ase" on the cost -enefit analysis. In this case stu"y now we will consi"er the two alternati+es an" analy5e them that are

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 &. *JMS '. %!!lication software "e+elo!ment (. Initial -oo/ an" mem-er "ata entry : Rs. (.77 $a/hs : Rs. 7.&7 $a/hs : Rs. 7.'7 $a/hs : Rs. &.#7 $a/hs

Total: Rs. 1.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.

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 S-oo/@ o %cc. Bo. o %uthors o Price o ISJB o Pu-lisher

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 Conly 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 Cno. 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 Sclaim@ o I"

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 Sno@ 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

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==<. 1.#. *e+elo!er@s res!onsi-ility : 1.#.1. *esign an" im!lement the system 1.#.&. *efine formats>!rograms for "ata entry wor/ 1.#.'. %ssist in system ac3uisition 1.#.(. Install the system an" 1.#.#. Pro+i"e maintenance for 1 year 1... 6eneral "escri!tion

1.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 CcategoryD &.1.&. Maintain "ata a-out -oo/s an" restrictions on their issuing Cty!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 Cissues>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.

'.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 C 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: &#77 9Joo/s: &77777 9Issues: #7777 '.#. Res!onse time !er transaction: less than 1 sec

You might also like