SYSTEM DEVELOP MENT

A SYSTEM DEVEL OP MENT LI FE CYCLE I S ESSENTI ALLY A PROJECT MANAGEMNT

MODEL. I T I S PART OF THE MANY STRUCT URED SYSTEM DEVEL OPMENT
MET HODOL OGI ES.

( YOURDON, JACKSON, SOFT SYSTEM MET HOD) .

Syste m

A syst e mi s a set of thi ngs wor ki ng toget her as part of a mechani s m or an i nterconnecti ng
net wor k ( a co mpl ex whol e). It can al so be a set of organi zed co mponent s whi ch int eract
i n a gi ven envi ronment and wi t hi n a specifi ed boundary to achi eve coll ecti ve goal s and
obj ecti ves.

Whe n we t al k about a ‘ syste m’ we are ref erri ng to t he compl ex rel ati onshi ps of t he
f oll owi ng: Busi ness: l awmaki ng, controlli ng requi re me nt s, poli cy, gui deli nes etc.
Pr ocess: how t he busi ness i s carri ed out.

I nf or mati on system

It ref ers to t he tool s t hat organi zati ons use t o coll ect, manage and anal yze dat a. Thi s
dat a gui des deci si on maki ng to i mpr ove effi ci ency and probability.

It al so ref ers to a str uct ured organi zati on of peopl e, data, processes, i nf ormati on
present ati on and inf or mati on technol ogy wor ki ng toget her i n supporti ng deci si on
ma ki ng, i mpr ovi ng operati ons and sol ve pr obl e ms i n t he organi zati on. It i s an i nt egr at ed
set of co mponent s for coll ecti ng, st ori ng and processi ng data f or provi di ng knowl edge
and di gital product s.

Pur poses of devel opi ng i nf or mati on syste m

- I mpr ovi ng dat a coll ecti on, processi ng and co mmuni cati on.
- On-li ne anal yti cal processi ng.
- For shari ng i nf or mat i on.
- I ncreasi ng producti vity.
Moti vati on f or devel opi ng new i nf or mati on syste ms
- Ne w opport uni ti es.
- Pr obl e ms.
- Di recti ves
- Need t o i mpr ove PI ECES
P = perf or mance I = i nf or mati on E = econo mi cs C = control security E= effi ci ency
S= servi ces
Met hods or Appr oaches to Syste m Devel op ment
1. Wat erf all
2. Iterati ve

1|P
age
 3. Spi ral
4. Rapi d Appli cati on Devel op me nt
5. Str uct ured syste m devel op me nt

Wat erf all

Thi s met hod i s used i n syste m devel op me nt life ci rcl e to creat e a syste m wi t h li near and
sequenti al approach. It i s a sequenti al step by step approach wi t h 7 st ages.

1. Requi re me nt s
2. Anal ysi s
3. Desi gn
4. Codi ng
5. Testi ng
6. I mpl e me nt ati on
7. Mai nt enance

Advant ages
1. Each st age must be co mpl eted bef ore you go to t he next st age.
2. It i s sui ted f or s maller proj ects where requi re me nt s are well defi ned.
3. Any changes i n software i s made duri ng t he process of develop me nt.

Di sadvant ages

1. Errors can onl y be fixed duri ng a parti cul ar st age.

2. It i s not good f or compl ex proj ect.
3. It i s sl ow

2|P
age
 Spi ral model

It was desi gned t o overco me t he weaknesses of wat erf all. It has more e mphasi s on ri sk
anal ysi s. Spi ral method creat es ri sk driven approach wi t h the ai m of reduci ng fail ure
t hrough iterati ve use of prot ot ypes ( exa mpl es or types). It has f our st ages;

1. Pl anni ng
2. Desi gn
3. Constr uct
4. Eval uati on

Phases

1. Pl anni ng: it st arts wi t h gat heri ng of requi re me nt s.

2. Desi gn: it st arts wi th t he desi gn i n t he baseli ne spi ral and i nvol ves archi tect ural,
l ogi cal desi gn, physi cal product and fi nal desi gn i n t he successi ve spi ral s.
3. Constr uct: ref ers to devel op me nt of fi nal soft ware product at every spi ral.
4. Eval uati on and ri sk anal ysi s: t hi s i ncl udes i dentif yi ng, esti mati ng and observi ng
techni cal f easi bility.
Af ter testi ng t he build at t he end of first iterati on, user eval uates t he soft ware and
pr ovi des f eedback.
The process of iterati on al ong t he spi ral cari es on t hroughout t he life of t he
soft ware.

Advant ages

3|P
age
 - Soft ware i s produced earl y i n t he soft ware lifecycl e.
- Ri sk handli ng.
- Fl exi bl e requi re me nt s.
- It i s good f or l arge and co mpl ex proj ects.

Di sadvant ages

- It i s not sui t abl e f or s mall proj ects.

- It may go i ndefi nitely.
- It i s expensi ve.
- Di ffi cult i n ti me manage me nt.

Rapi d Appli cati on Devel op ment

RAD i s a coll ecti on of approaches whose ai mi s to qui ckl y develop and depl oy i nf or mati on
syst e ms. Thi s met hod i s al so kno wn as Rapi d Appli cati on Bui l di ng ( RAB) . RAD put l ess
e mphasi s on pl anni ng and more e mphasi s on an adapti ve process. Prot ot ype are often
used i n addi ti on to or so meti mes even i nst ead of desi gn speci fi cati ons.

RAD i s especi all y well suited f or ( alt hough not li mited to) devel opi ng soft ware t hat i s
dri ven by user i nterface requi re me nt s. Graphi cal user i nterf ace buil ders are often call ed
rapi d appli cati on devel op me nt tool s.

Exa mpl es of RAD

Pr ot ot ypi ng ( A prot otype i s a process i n whi ch desi gn tea ms i deat e, experi ment wi th, and
bri ng concept s to life, rangi ng fro m paper i deas to di gital designs): It i nvol ves creati ng a
si mplifi ed wor ki ng mo del of t he proposed syste m t hen showi ng it to t he users for vi ews
and co mme nt s. It can be i mpr oved t o come up wi t h t he fi nal syst e m.

Joi nt Appli cati on Devel op me nt: All t he st akehol ders are invol ved. Such as owners,
pr ogra mmers, anal yst s and users.

By t he end of t he meeti ng wor ki ng prot otypes woul d have been devel oped whi ch i s very
cl ose to t he fi nal soluti on.

Str uct ured syste m Anal ysi s and Devel op me nt

It defi nes a set of st ages t hat shoul d be foll owed when devel opi ng a syste m. Each st age
i s well docume nt ed and specifi es t he acti viti es to be carri ed out by t he syste m anal yst
and t he tea m whil e devel opi ng a syste m.

At t he end of each stage, deli verabl e i s produced whi ch f or ms t he basi s f or contracti ng

next st age.

It i s a concept ual model whi ch i ncl udes poli ci es (rul es, strategi es) and procedures f or
devel opi ng a syste m. It i s t he appli cati on of anal yti cal processes to t he pl anni ng, desi gn
and i mpl e me nt ati on of ne w and i mpr oved i nf or mati on syste m.
4|P
age
It i s a co mpl ete set of st ages t hrough whi ch a syste m i s devel oped, depl oyed and
mai nt ai ned.
It di vi des t he life of an i nf or mati on system i nt o t wo;

1. Devel op me nt st age
2. Oper ati on and support st age

St akehol ders i n syste m devel op ment

1. Syst e m owners: t hese are t he i nf or mati on sponsors and mai n advocat es, t he owner
of t he syste m.
2. Users: t hese are t he day to day users of t he syste m concerned wi t h t he busi ness
requi re me nt s of t he syst e m.
3. Syst e m desi gners: they transl ate t he user requi re me nt speci fi cati ons i nt o techni cal
desi gns consi sti ng of rel evant fil es, dat abases, i nput s out puts, user i nt erf aces and
ho w t hey i nteract wi t h one anot her.
4. Syst e m buil ders: t hese converts t he desi gn specifi cati ons i nt o pr ogra m code wi t h the
end resul t bei ng f uncti oni ng soft ware syst e m.
5. Syst e m anal yst: t his i s an I CT prof essi onal who f acilitates t he manage me nt of
i nf or mati on syste ms devel op me nt t hroughout t he devel op me nt process.

St ages

1 Probl e m recogni tion and defi niti on 2. Feasi bility st udy 3. Fact fi ndi ng 4.
Anal ysi s 5. Desi gn 6. Syst e m constr ucti on Testi ng 8. I mpl e me nt ati on 9.
Eval uati on and Mai nt enance.

Case St udy: Poi nt of Sal e Syst e m

A soft ware co mpany want s to devel op a poi nt of sal e syste m to servi ce a wi de
vari ety of ret ail stores. The proposed syste m i s supposed t o recor d sal es and
handl e pay me nt. Each product will have a barcode to identif y it. Upon
i dentifi cati on duri ng checkout, t he i nf ormati on about t he product i ncl udi ng
its pri ce i s ref erenced and t he cust o mer requi red to pay. At t he sa me ti me, t he
quantity of t he product s bought i s deduct ed fro m t he i nventory. Whe n t he
quantity of ite ms reduces to a gi ven l evel i n t he i nvent ory, an aut o mati c re-
or der e mail i s sent to t he suppli ers, t he sol uti on shoul d be abl e to gi ve credi t
poi nt s f or ret ur ni ng cust o mer. Ne w product li nes can be i ntroduced i nt o t he
syst e m.
1. Probl e m recogni ti on and defi niti on (f aili ng to pl an i s planni ng to f ail – British
Pri me Mi ni ster Churchill)
It i s done duri ng preli mi nary i nvesti gati on and seeks to ans wer t wo questi ons. The
devel opers will pl an f or t he upco mi ng proj ect.
( 1) Is t he proposed proj ect wort h pursui ng?

5|P
age
 ( 2) Is t he proj ect wort h looki ng at ?

Looki ng at t he case of POS syst e m, t he pr obl e m at hand i s to repl ace t he i neffi cient
ma nual operati ons suc h as i nvent ory manage me nt and sal es tracki ng wi t h an effi cient
co mput eri zed i nf or mati on syste m. The syst e m anal yst tri es to ans wer t he f oll owi ng
questi ons.

1. What are t he short co mi ngs of t he current syste m?

2. What types of recor ds are kept after a sal e?
3. What procedure i s f oll owed t o co mpl ete a transacti on?
4. Ho w i s ne w st ock re-or dered?
5. Ho w are cust o mers re war ded?

Ho w to pl an f or syste m devel op ment proj ect: Syst e m devel op me nt i s very co mpl ex

i n nat ure, t hat’ s why it requi res co mprehensi ve pl anni ng bef ore spendi ng. One of the
most i mport ant pl ans i s t hat of ti me manage me nt or proj ect schedul e. Thi s i s done i n
or der to avoi d extra cost. For i nst ance, if t he co mpany i s payi ng t he tea m on a pay
day basi s, an extra day means t he co mpany will i ncur t he extra cost.

One met hod of managi ng proj ect schedul e ti me i s t o use a speci al tool call ed Gantt
Chart. A Gantt Chart i s a di agra mmati c represent ati on of diff erent acti viti es of a
pr oj ect showi ng cl earl y t hei r order of precedence and ho w long each t ask will take.
One can tell fro mt he Gantt chart how l ong t he proj ect will take.

2. Feasi bility St udy its ai mi s to est abli sh t he costs and benefits of t he ne w syst em.
A ne w syst e m will onl y be devel oped if its benefits are more t han its cost s. At
t he end of t hi s st age a f easi bility report i s produced and present ed t o t he
ma nage me nt. The stage i s assessed i n f our ways 1. Operati onal f easi bility: 2.
Schedul e f easi bility 3. Techni cal f easi bility 4. Econo mi c f easibility
(i) Oper ati onal f easi bility: est abli shes t he ext ent to whi ch t he users are
co mf ort abl e or happy wi t h t he proposed syst e m.
(ii) Schedul e f easi bility: est abli shes whet her t he devel op me nt of the proposed
syst e m will be accompl i shed wi t hi n t he avail abl e ti me.
(iii) Techni cal f easi bility: est abli shes whet her t he technol ogy avail abl e i s
suffi ci ent or shoul d be upgraded f or t he ne w syst e m. It al so seeks t o fi nd
out whet her t he st aff have rel evant techni cal skill s to devel op and use t he
ne w syst e m.
(i v) Econo mi c f easi bility: est abli shes whet her devel opi ng t he ne w syst e m i s
cost eff ecti ve by anal yzi ng all t he costs and benefits of the proposed
syst e m.

So, based on t he above f our f act ors, t he devel op me nt tea m comes up wi t h t he f easibility
report t hat i s used to det er mi ne whet her t he syste mi s wort h pursui ng or not.

6|P
age
 3. Fact fi ndi ng/I nf ormati on Gat heri ng
Af ter f easi bility st udy and report has been approved by manage me nt, t he syst e m
anal yst can t hen proceed t o t he next st age ref erred to as i nf ormati on gat heri ng or
f act fi ndi ng.
Met hods of coll ecti ng dat a are as f oll ows;
1. Doc u me nt revi ew ( recei pts, reports, backup fil es etc.)
2. i ntervi ews
3. questi onnai res
4. observati ons
5. aut o mat ed met hods

Aut o mat ed data capt ure ref ers to t he use of technol ogi cal tool s li ke Artifici al
I ntelli gence and i mage recogni ti on soft ware to convert i nf ormati on i nt o a co mput er-
usabl e f or mat. It i s fast er t han manual dat a capt ure and prone t o errors.

Fact fi ndi ng report: at t he end of i nfor mati on gat heri ng st age, t he anal yst must
prepare and write a fact-fi ndi ng report t hat has so me of t he f oll owi ng det ail s;

i. Cover l etter addressed t o t he manage me nt and t he I T t ask force written by

t he person who gat hered dat a.
ii. Executi ve summar y whi ch provi des a snapshot of how t he ne w syst e m i s to
be i mpl e me nt ed.
iii. Det ail ed outli ne whi ch provi des i nf or mat i on about all t he met hods used t he
st udy.
i v. Su mmar y secti on t hat sho ws t he cont ents of t he report and it al so t ouch t he
i mport ance of t he syst e m.

The report i s t hen sub mi tted to t he manage me nt f or eval uati on and f urt her gui dance.
Af ter t he f acts have been consoli dat ed i nt o a f act-fi ndi ng report, a requi re ment
specifi cati on document i s prepared descri bi ng t he f oll owi ng co mponent s i n det ails:

1. Out put specifi cati on

2. I nput specifi cati on
3. Fil e/dat a st ores
4. Har dware and soft ware requi re me nt s.

4. Syste m Anal ysi s

Thi s st age i s t he process of breaki ng down a co mpl ex system i nt o s mall manageabl e

part s t hat can easil y be modell ed to underst and t he processes and dat a needs. Thi s
i s done t hrough t he syste m anal ysi s tool s. Exa mpl es of anal ysi s tool s i ncl ude dat a
fl ow di agra ms, entity rel ati onshi p model s, dat a di cti onari es ( a dat a di cti onary is a
coll ecti on of na mes, defi niti ons, and attri but es about dat a el e me nt s t hat are bei ng
used or capt ured i n dat abase, i nf or mati on syst e m, or part of a proj ect)
7|P
age
Syste m Fl owcharts

A syst e m fl owchart breaks down t he entire syste m devel opme nt event s or acti viti es
and di spl ays t hei r rel ati onshi p and l ogic fl ow i n graphi cal for m. A syste m fl owchart
cl earl y shows sequenti al, deci si on and loopi ng operati ons t hat a syste m handl es at a
hi gh l evel. Syst e mflo wchart sy mbol s are as f oll ows;

Desi gni ng a syste m fl owchart

Syst e m Fl owchart desi gn ill ustrates a sequence of operations t hat a syst e m goes
t hrough i n or to process i nf or mati on. Steps to f oll ow

1. Wri te a titl e: e. g. Poi nt of Sal e and i nventory Manage me nt Syste m.

2. I dentif y t he tri gger event li ke cust o mer buyi ng an ite m or a ne w st ock ite m bei ng
i nput i n t he syste m. Thi s will mar k t he starti ng poi nt of t he flo wchart.
3. Doc u me nt t he l ogi cal fl ow of dat a fro mt he tri gger event to t he end and represent
it wit h syste mfl owchart sy mbol s.
4. Whe n t here are many alter nati ves at t he deci si on st age, f oll ow t he most
i mport ant and continue wi t h it.

8|P
age
Expl anati on
1. A product i s an ite m i n t he i nvent ory ready f or sal e.
2. Usi ng t he barcodes, t he syste m checks f or product s product det ail s i ncl udi ng
pri ce i n t he st ock file.
3. The syste m creat es the sal es i nvoi ce and co mput es l oyalty poi nt s.
4. Af ter recei vi ng payme nt and co mputi ng change, t he system pri nt s t he sal es
recei pt.
5. The syste m updat es t he i nvent ory aut o mati call y and writes l oyal ty poi nt s t o t he
cli ent’ s car d.

Dat a fl ow di agra ms ( DFD)

A dat a fl ow di agram i s a graphi cal model used t o represent an i nf or mati on syst e m
pr ocesses and dat a st orage.
- It depi cts what a syste m ought to do not ho w it will do it
- Four st andar d Sy mbol

Pr ocess represents a transf or mati on, so met hi ng t hat t he syste m does. Such as
pr ocessi ng dat a t hrough so me cal cul ati on, recei vi ng dat a, updati ng recor ds etc.

9|P
age
Dat a Store Represents a fil e or dat abase t hat st ores dat a from a process f or t he syst e m.
Whe n devel opi ng t he syste m, a dat a st ore beco mes a dat abase or a fl at fil e.
Ext er nal Entity t hi s i s a physi cal obj ect t hat i nteract s wi t h the syste m by i nputting or
recei vi ng so met hi ng fro mt he syste m.
Dat a fl ow represents t he fl ow of dat a to and fro m processes
Whe n creati ng dat a fl ow di agra m observe t he f oll owi ng
1. I dentif y processes, input s and out put s.
2. I dentif y dat a st ores
3. I dentif y dat a fl ows and ho w t hey fl ow from on process to t he next.
4. Dat a cannot fl ow between t wo dat a st ores wi t hout a process in bet ween t he m.
5. An ext er nal entity cannot write di rectl y i nt o dat a st ore but has t o go t hrough a
pr ocess.
Exa mpl e
Usi ng a dat a fl ow di agra m creat e a poi nt of Sal e Syst e m. Component s

POS DFD Cont ext Di agra m

10 |
Pag
e
POS Dat a fl ow di agra m Level 1

5. Syste m Desi gn
Thi s i s t he process of synt hesi zi ng or putti ng toget her co mponent s t hat will address all
t he syste m requi re ment s. It reasse mbl es a properl y anal yzed syst e mi nt o l ogi cal mo del
of str uct ures t hat represent t he sol uti on.
Str uct ured chart is a top and down hi erarchi cal di agram t hat enabl es a syst e m
devel oper to desi gn a syste m by organi zi ng it i nt o a hi erarchy of modul es and sub-
mo dul es of a syste m.
Co mponents of a struct ured chart

11 |
Pag
e
 Executi on Control Sequence

A i s t he root modul e whil e A1, A2 and A3 are sub- modul es.

Cr eate t he process of sal es Modul e wi th t he f oll owi ng sub- modul es.
a) Scan bar codes
b) Read ref erence fil e
c) co mput e tot al bill and change
d) pri nt recei pt
e) Updat e st ock fil e

6. Syste m Constr uction

It ref ers to codi ng, i nst all ati on and testi ng of t he progra m modul e and t hei r
co mponent s. The pur pose of constr uction phase i s to devel op and test f uncti onal
syst e mt hat f ulfil s busi ness and desi gn requi re me nt s.
Envi ronme nt s
- Hi gh l evel str uct ured l anguages. Such as Pascal, COBOL
- Fourt h generati on l anguages. Such Vi sual Basi c, Vi sual COBOL, Del phi Pascal
- Obj ect Ori ent ed Progra mmi ng l anguages. Such as Java, C++, C#
- Cust o mi zi ng off t he shelf appli cati ons. Suc h as Mi crosoft Access and Or acl e.
Testi ng t he syste m
It i s done i n order to vali dat e whet her:
1. The specifi ed requi reme nt s have been met.
2. The users are sati sfied wi t h t he syste m.
7. Syste mi mpl e ment ati on
It i s a process of deli veri ng t he system t o t he users i n t he day to day operati ng
envi ronme nt.
Fil e conversi on

12 |
Pag
e
Thi s i s when t he new syst e m i s i mpl e ment ed and t he f or mat changes fro m manual to
co mput eri zed. Fact ors to consi der: whether
1. A ne w operati ng syste mi s requi red
2. Ne w har dware i s requi red
3. Ne w appli cati on software i s requi red
4. Ne w dat abase i s requi red
Syste m change over strategi es
Syst e m changeover me ans how t o st op usi ng ol d syste m and st art usi ng t he ne w one.
1. Strai ght changeover
2. Par all el changeover
3. Phased changeover
4. Pil ot changeover
Strai ght changeover: The ol d syste m i s stopped and di scarded and t he ne w syst e m
st arts i mme di at el y.

Advant ages
 Cheaper to i mpl e ment
 Easi er to i mpl e me nt
Di sadvant ages
 I n case of a f ail ure there i s no f all back strategy si nce t he syste mi s di scar ded
 The ri sk to busi ness conti nui ty i s very hi gh
Parall el changeover: Bot h t he ol d and ne w syst e ms are r un concurrentl y f or so meti me
until t he users have confi dence i n t he new syst e m.

Advant ages
 I n case t he ne w syste mf ail s, a f all back strategy i s avail abl e
 Better testi ng of a new syst e mi s done i n a real envi ronme nt
Di sadvant ages
 Mor e expensi ve
 A l ot of ti me i s wast ed
Phased changeover: A ne w syst e mi s i mpl e me nt ed i n phases or st ages.

13 |
Pag
e
 Advant ages
 The ri sk of f ail ure i s l ow
 Sl ow but sure
Di sadvant ages
 Takes a l ot of ti me to fi nali ze.
 Ri sk of i nco mpati bility bet ween el e me nt s
Pil ot changeover: Thi s i s t he co mbi nati on of parall el operati on and strai ght changeover.
It i nvol ves i mpl e me nti ng a ne w syst e m at a sel ected sites whil e t he ol d syste m continues
to operat e.
Advant ages
 Reduced ri sk of syste mf ail ure.
 Less expensi ve
 All f eat ures of t he new syst e m can be f ully tested
Di sadvant ages
 No backup syste mif t hi ngs go wrong
8. Syste m Eval uati on and Mai ntenance
Syst e m eval uati on or (revi ew or audi t) i s a f or mal process of goi ng t hrough t he
specifi cati ons and testi ng t he syste m after i mpl e me nt ati on t o fi nd out whet her it me et s
t he user requi re me nt s. It assess an i nf or mati on syste m whet her f uncti onal requi reme nt s
and non-f uncti onal requi re me nt s are met.
Functi onal requi re ment s are t hose t hat can be measured or observed di rectl y. E. g. user
i nput, report generated and Dat abase.
Non-f uncti onal requi re me nt s are t hose t hat are diffi cult to measure. E. g. user
sati sf acti on, avail abi lity, i nteroperability, security, i ntegrity etc.
Syst e m mai nt enance i s t he adj ust me nt and enhance me nt of requi re me nt s or correcti on
of errors after a syste m has been i mpl e ment ed.
Syste m docu me nt ati on
Thi s i s a lifel ong process i n t he syste m devel op me nt life cycl e. It consi sts of t he f oll owi ng:
1. Report on f act fi ndi ng
2. Requi re me nt s specificati ons
3. Syst e m and modul e fl owcharts
4. Dat abase t abl es/fil es str uct ure/descri ption
5. Sa mpl e test dat a and expect ed out put
6. Report generat ed from t he syste m.

14 |
Pag
e