III YEAR - VI SEMESTER

COURSE CODE: 7BCE6C3

CORE COURSE-XIV-SOFTWARE
ENGINEERING
LnitI
Introduction: Introduction to software
engineering - some definitions
:j::':rrs -quality and productivity factors - some size
l;-:lnrng the problem- developing a solution.- managerial i-ssue.splanning a software project:
stra-;e;-- prun irg the development process _
:'"nning an organizationar structuie other pturnirfl.tiiitr.,
-
t nit II
cost ractors - sortware cost estimation techniques
-.r,in,uffiTffi-::it T,ffi:ff; ::i}are
Software Requirements Definition: The
software requirements specification _ formal
specifi cation techniques

Unit III
Software Design: Fundamental design
concepts - modules and modular izationcriteria
- design notations - design techniques
- Stepwise refinement - Integrated top down
development - Jackson structured Programming
-6.1uiled design .orride.uTions
mil estones,walkthroughs and inspections - desig-n guider ines
-test plan -
Unit IV
Software Implementation: Structured coding
techniques - coding style standards
and guidelines - verification and validation -
and inspection -Unit Testing and
techniq"u.,
-'quurity ar.r.ui."'- walkthrorgh
Debugging _ System Testing

Unit V
Software Maintenance: Enhancing maintainability
during development managerial
aspects of software engineering -
- configirr"ti"; ;;;;;ir.r, - source code metrics
maintenance tools and techniqu-es _ other

Text Book:

concepts - Richard E. Fairley, rata McGraw Hiu publishing

.:#*;1ilft,.'ffi:ng
Books for Reference:

I '
Software Engineering A practitioner,s
- approach _ Roger S. pressman, (Fourth
Edition) McGrawHill Intemational
_ Editions
2' An Integrated Approach to Software engineering pankaj
Narosa publishing House - Jalote, Second Edition
3' Fundamentar s of.Soft_ware Engineering,
carloG hezzi,Mehdi Jazayeri, Dino
Mandrioli, prentice Hall of India pvt. itd.,New
Oett i

+Q*Aeaiiit

684 B.Sc. Computer Science

 I

t
I
BcA-vsemestcr
4BCA6CB - SoftwareEngi n eer.ing
UNIT _ I

INTR0DUCTIONToSoFTWAREIING][NEERI}{(.}

Definition :Software Engnieering

and managerial discipline concemed
software engineering is the technological
pr:oducts that are developed
with systematic production and maintenance of software
\l and modified on time and within cost estimates'
it]-lprove the quality of
The prirnary goals of software engineerillg ilre to
ancl job satisfacti'rtr of software
software products and to increase the productivity
engineers.

SOME DEFINITIONS

teln "prograntmer" is used to cleuote rl ill('ivitit':iil

itrll r ts ^gr.lcernc'(i
The
::rtcJ <latri
withthedetailsof,imp]cr,renting.packagirig.alldll],,.ill-',ttt.::tlg.rt.ilttrr:
languagcs'
structures rvritten in pafiicular programllring

Soffivareengineersar-eadditionallyconcernetl.',,'itl,,rr;suesotatiitlysts'desigrl'
soft$'arc lllitltctlatlce' atid projfe i
verification and testing, docuuentation,
management'

'Ihe term "computer soft\vare" is often ilrkerl to llc 51rlli)11)4'l1ous

"l'itlt
"contputer prograut" or "sotlrce code"'
cocle allii liij iiLc ilssO'l1a[ed cioculncnts
computer soflu,are inclucles the source doeulllents'
ancl documentation that constitule a
soflrvare protlLrct )lcquirelllellts
pians" ]]' rrlt il')''::' ';i' oDer attcti' quailtv
design specitications, source coctre' tesl , , t'11.r"1],.:, .r. ,|.|..,'.,',.1t.c.. ,tj\L.I .i
Solt',r'li.e pioblcrn repoll}"
aSSurSnCe pt.ocedures.
and traitring aids at'' llli rii'rll11r'll1c11i:
ot'li sofi*'a;i:
manuals, instaliatio, itistt-ttctions,
product"
'':ltitr ici"tlri
"Docttlttctttlttio:1" '""xJtl'rtlts thc chllrlclctt>lli
tile charactc:i'r'ijc:t r')1'tir''l ert'ci'j' ail(j uxtclll'li
documentation of soul'ce cocle ciescribes
the dOcLttlrcrlts 'iciOCtI'r'::rl 'r itil the corjc'
ciocu,rentation expllins the characteristics Of
ot'or:lituizllttorl that lt-tttiatt:s
The temr "Customel" is usecl to denote an indivrduai
product'
procurelrent or morlificatiort of t' st)ftr"'are

Soffware quality is a primarv concern of sofflr'arc cltgittclt'l''

v
..:
Fage 1 of 76
 (
\r'

possess' Thest:
quality attributes that every softwarc proclLtct shoulcl
Fundamental !'crl0sr
clarity, reliability, effi ciency, arr d r..rrs1-cff i:cti '

include usefulness,

reliabitity is "the ability of a pi"':rgratrt Lo pel'fcm a requircd

Softrvare
for a stated period of Iinte"'
function under stated conditions

SOME SIZE FACTORS

Thelevelofeffortdevotedtosoftwaredeveloprrrentandlnaintenanceis
of effort among activities is presepted; ald
size categorie's
discussed; the distribution
for software projects are described'

PROJECT SIZE CATEGORIES

level of management control
Project size is a major factor that determines the
anci the types of tools and techniques required
on a softrvare project' The following
categories give some indication of software
project size'

Trivial projects
periraps part
project involves one protrillllnler rvori<iit1t
FN
NI A trivial software
results irr I irrogt.anl of less thlin 5()(r
time, for a few daYs or a few weeks and
statements, packaged in 10 to 20 subroutincs'

Small projects

Asrrrallprojectemploysoneprogral-IllTterfbr]rtl(ltntltttlrsandresLrltsitr.i
25 to 5()
product containing 1000 to 2000 lines
oisource coclc packaged in pe'haps
no interactiotls u'llh othct'illoqralns'
routines. Srnall proSlams usually have

Size categories for softlvare products

--- -- --l Prociuct size
CategorY N,r"b., of Dr*t.t I

<oii Iines
l-4 u,ks. ''ot'tte i

Trivial 1
l
1t 1f
I I\ --- r\
'
i -6 mos
Srnall 1

\ls-)rl[\
2-5 1-2 yrs.
Medium
)-i vrs, 5CI{, l00K
Large 5-20

.4-,5 yrs, J\,I

Very Large 1 00- I 000
\l i
l\i- 1,lr\i
Extremely large 2000-5000

collilllol'cia1 lppIicatrons'
I Examples of such ilrograms include screntific applicatlt'rIs,
Page 2 o{ 76

il,,
 Medium-size Projects
|rog'aln1lers wi rking 1br 1to 2
A project of medium size requires two to fivc
Sourcr'r i;ode packageci rn 250 to
10()0
years and results in 10,000 to 50,000 lines of
routines.

Large Projects

A large project requires 5 ta 20 proglammels i,rr a pct'iod of 2 to 3

yoars altd
packaged in several
results in a system of 50,000 to 100,000 source stltemellis'
subsystems. A large proglam often has significant itrteraction-s
u'ith 'rther programs
and software systems.
systems'
Examples of large proegams include large compilcrs, smtrll Liiitc'shalinq
data-base packages.

Very large Projects

pcriot] o{"'1 tri 5
A very large project reqr.tires 100 to 1000 prtirlrarrrl'rlers for a
:'()rlrcc instrltctioll: ' A verv large
years and results in a softrvare system of i million
cach o[ *ilicl i''rrlrs a iittllc
system generally consists of seyeral major subsystt-'t'lrr''
system.

proces:: ltlL;, tcit:ctttLimtnicatitlns' anrl

very Iarge systems often inyolr'e real-time
multitasking.

Extremely' large Projects

Anextremelylargeprojecternploys2000to5()()0prorrilll}r}let.|]ilrper.iodsrlI
iitrcs.ll.,SLrtjrCC cr,c.le. Extrenrel-y
up to 10 years and results in i millir-lii to 10 nrillion
subsysteirls ttrlcj ollen inrolve real-time
large systems consist of'several very large
prccessirlg, telecomurunicatiolls,rnultitaskinS, anci dtstl';ili-rieti j]rlilr'sqllis'
irrLiljstiu nrissiic
Exar-Il.ples of extrenlely large S]'Stelns inr:iude air irrrfLlc :orrlr'of
defense, and military comnranci anci cotltroi s)'stcnls'

{fti*rcY AND PIIoDUCTI\/ITY FAcroRS

Dei,elopment and maintenance of soft."varo pl'trti ttols i'irc

colllil.lex Lasks Thost:
cxei'cises ila'i'
C*) rvho have u'ritten onll' 51"t11 programs for personai r:tc ol hltilcri'orjt
\:/ rr-il'""'
frnd it difficult to urtderstand the ir:lpofiance of s1'stetl;.ri1C i'
\
K
_+.i

?age 1 of 76
,' :f'\')
. d\r
'
., t{t
r,?-u1*

.L
s'j': "{-nr'
ll"
'i ' - 1iii
 + can be improve'l by improvtng
Software quality and progfammer productivity
software proclucts' Sot ne factors thtrr
the processes used to develop and maintain
influencequalityandproductivityarelistedinthefollowirrgtable

Factors that influence quality and productivity

Individual abilitY Ptott". r: rlderstancling

Stability r.l 1' rc cluirelnents

Team communication

Product complexitY Requirccl :;itiiis

Appropriate notations Facilities irrtd res()Llrccs

Systernatic approaches Adequaci', r l' l'i-ait-titig

Change control Manageruirnt sliiIIs

Level oftechnology Appropliritc goal:s

Required reliability Rising e)i I ccte'! j r)r ts

Available time

Individual ability

Production and maintenance of softwart. irl'or]ucts nre fi'li[ror-inten'ri

e

ability anr'i
activities. productivity and quality are thus direct fuitr:'.ions oi'irldirici.ral
etTorl.

Team communication

prograrnming has ti-aditionally been regat'deci as ri1 iiltlivldual ati{l 1"nVar''

activity. Many programmers have iow social necii' 'rllil 1lt'c1er
i'r u'ork aionr:
(cou78). Programs are selcloni perceived as pubjic .iocillllclll',\. l.r() rlIofr"'rl.l-1llle]!;
seldom discuss the exact cletails of their rvork in il S)'s r'rrr'rrrc
lllill)iler'

Many of the recent innorratior-rs ir-r softrtlallrr el l:ll:l;ctitt3. SlrCll us tiL'slgl)

revier,vs, stmctureci rvalkthror,rghs, an{ code-reaclirlc cxcie iseS' hA"'e the

goals o1'

nakir-rg softr.l,are lrgre visible and irnprovrllg contlTltliri.lrijnll atllOllg pr(rql'alrmers'

Product complexify

There tlu'ee -eeuerally acknorvledgc lc', cls o;' 1-r1'91lssi ccmpleX't',

ar<3 .

applications progralrs, utility' programs. and systeni-lcr ,'. ;rr{)[]lttt] {llpiic.1ti(rrr:

progrilms include scientifrc anci ciata proeessittg I('i.r ,,t,: \.\i'tilctt i1-r ; higil-ieir:i

Page 4 of 76

li lfii';
E
 {
language such as FORTRAN, Pascal, or coBol. ulilrrv l)ro:;rarlls inc iude compjlers',
(
assemblers, linkage editors, and loaders'
pac]:ag0s, re,I]-1i1l1e plocess
Systems proglams include data communicalion
ryl-Licii are usurrlly written in
control systems, and operating systems routilles'
assembly language or a high-level systems
language rrttch as Pf/| 61'{rla'

Appropriate notations
while
I Good notations can clarifl' the relationships anel interactions of intercst'
poor notations complicate and interfere with good practlce. Plogramtniilg lzrnguages
1
v/
provide concise notations for the implementation phasc of sol1u'ate dcvelopment, bul
1,
there are no widely accepted notations fbr stating lr;tctiotial recprirllnents. design
\- specifications, test plans, or perfbmrance criterial.

Systematic approaches

Various systematic approaches to softu,are alcr iriilpt:lr.lttt ;tttci 1l ailll'.riliitlce al'e

U
discussed in this text' but because the field of softr'"itr't: cllsiiiecrill{ 1: l11 :ts rttfanctr''
many of our procedures and techniques have not yet iI.ir r.ll.crd.

At this poipt in the evoiution of soliware engineering ti is oiierr iloi cle ti'u'liicir ol'tlle
various approaches to softrvare clevelopment should be itsccl irr rr'lticlt sllr-l:itiorls'
\-
Change control
to
{ In a very real sense soft,.vare adapts general-pr.rt'pose colllputirrg hardural'e
irr
particular applications. Sometimes software mttst cotllpensale ciestgtr deilciencies
rcquirements o[
the hardware, and software is often tailored to salj'sfy diti'ering
ai'd also a STeat
different customers. The flexibility of softrvare is a great st|ength
c'udc rs 1ls'lY rnodified' it
: source of difficuity in software engineenng. Because s;()Lrrc:
i'c' o: fir| i'te cLtstomer ttr
is not uncommon for cjifficult issues to be resoived itl si'lil-"
111j1i1':";il'litle-r trr the Sour(;o
L, request, and the prOject nlanager a8tree to, seemingl''
code"
U
'' \-) Requirenietlts calt also cirange due tt-r poor tiir(icl'stillrcling
o1'[]ic lrt'oblenl. tir

L extemal econotnic and politicai factors beyond the cor)lr.(il 0f crlst(-rmel ')l"dcvcioper'
i
a- Level of TechnologY

The level of tecllology utilized on a sofIu,,re ltl-t,.jcc'i ilccr Litlts lirr suclt
U factors as the programming language, the machine ,-tt"'ir.,'ntilellt, ihe 1;rogramminl:
practices. and the software toois.
{"L
'\-r

Page 5 of 75

(-t

{il,
"f.J;.
 Lcvel of ReliabilirY

Everysoftwareproductmustpossessabasii:lcr,c]oircli;rlijitv:h(lwev.:r
great carein t"lxl"Silr' r'icsiS11' 1 ntllementuttoti
extreme reliability is gained oniy u'ith
software procir'lct'
system testing, and maintenance of the

Problem understanding
to bs sol'n't'd is a common
Failure to understand the true nature of the probietn
and difficult issue. There are several factors thlt contributc to this lack ol'
understanding.

Most customers (most people in general) are trot trained to tlLink in iogical,
algor-ithmic terms, and often do not understand and tt't.tt, tlatuLr: of their rteeds.

Sometimes the customer is not the end user oi ti-ic s;'stcnl, aird the software
engineer has no oppofiunity to investigate the user's pr"bielti'

Available time
calr be corttpletcri
Software project r-equiripg six programffrer-mr)]rlll:, c1'el'iort
1 month' :;oit"r'are proje'cts
by one pr6glammer in 6 tnonths or by six progtamlll(-'r 1ti
are sensitive not only to total etfort but also to elapsc,.1
iinte airil illc tiu:nbet'ol"people
involved"

Required skills

The practice of software engineering requires l 'A:il

iirrlgc ot'sk ills' Extractinll
user uet:cls cJetlands gootl
information {iom customers in orcler to establisl.r
eommunication skil]s, tact, and diplomacy as
weil lrs knolvieiige ot the appiication
area.

Facilities and resources

Studieso{'factorsthattnotivateprogratnntersl'rire:sliort'trtilri\\Iork-l'elated
aS gOOd 1raC1-rille access artcl a cltliet
placc i'r ''\'rrlk' iil''' ll1 'rlc itnllorlatlt tir
faCtOrS, sUch
the typical progralrrner than status-related factors'

Adcquacl' of training
procluct imple'-reltation is 9nl1,,one aspect of r,rliitiit'c, ctlqitleet 1lg, )'cl tilts t'
ir l':rLitihl- 111 1ll;ll! erittc:rti'ltlai
the Only phase of procluct cleveloprnent and ilaintenalr
institutions.

Boehm has described the skills most lackini.: rrl .'trll'' -le , , l |: r$rc111111gIS

(BOE76b), his list inciudes inabiiity to:

Page 6 of 76
 I . Express oneself cleariy in English'
2.DevelopandvaiidatesoftrvarerequirementslirtlcJesirr'rrspccificatjotts.
3. Work within aPPlication area'
4. Perform software maintenance'
5. Perform economic analYses'
6. Work with project management techniques'
7. Work in grouPs.
Management skills

Software projects are often supervised by lnanagers "",'l1o hav: littie, if an)"
klowledge of softrvare engineering. Many of the Droblc'rlls ,,1 51firr'3re project
management are unique; everl rtanagers experieflcii(j tn rnauagemerrt of cornputer
hardware projects find softrvare project managemclrt to be dilficrrlt due to tlie
differences in design methods, notations, development tools, aud issues of concem.

Appropriate goals

The primary goal of software engineering is dcr r:1opn-tct-tt oi'soi{li'are products

that are appropriate for their intencled use. Ideally. r\' et'v sot'tu'are l,roduct shoul<l
provide optimal levels of generality, efftciency, and rclrrlhilit-"

Rising expectations

The most pervasive problem in so{trvare engineeritr;: rs thal oi'risinl

t:;tirc:clrtiilltt

There are two interrelated aspects to rising expectatiorls: iit'si

ls iitc ct ttcern i'or liori'
a g:i'en am6unt ttf
much functionality, reliability, and perfonnance can br: lr1o,'tiicri b1'
development efforl; and second is the issue of fundarrctltal lilritalicrts
of softwarc:
v v

0,
technology. .

!
Other factors
'a
(
a
Therearemanyotherfactorsthatinfluellcepr0gl"al]llliorprociuctivity.
s\'steln usecl to
ti including famtliarity with, access to, atrd stabilit,v ol rilc corltputing
) develop or modify the software; the lnemory and tintrttg
constrainl l'br the softwate
productl expcnence r,r,ir[ tfuc rrL)Erallilnlltg lartgtrage::,:..1 .]',tir-i't-:r.'sllc
5
*.
d
MANAGERIAL ISSUES
(
I Techlical and managerial activities are eqriail'' ttr il,c -sLleLrss ol'lt s'.rftrvarc
n I project. Mangers controi the resources ancl the enr r,.)t'Iillclil Ili u'l ich technicai
\- activities occur. Managers also have ultirnate respcnsihiirlr iirt"erlsLll'l,i! lltal srrlirvarrr
d
) products are delivered ott tirt-re and u ithin cost esttniltt -
d
0a
N some of the problenrs identified by' responclcilis ll'' itril.rr '1'1 "r1i :;'titltqettieni
problerns were:

PageT of76

Slllr
 generalll'poor'
l. Planning for software engineering projects is
of project illanagers are poor'
2. Procedures and teChniques for the selection
projects irr poor' leaving
3. The accountability oi*uny software engineering
some question as io who is responsible
for various prcject funcl ions.
The ability to accurately estimate the resources required
to accomplish a
4.
software development project is poor"
Success criteria for software developnlcnt pro-1ects iire
{icquenllY
5.
inappropriate. This results in software products that ali:
i:nreliable. dilllcult to
use, and difficult to maintain"
6. Decision rules to aid in selecting tire proper,rrgilllizaliL)ilal s1 ur-:tttrt] are n(11
available.
7. Decision rules to aicl in selecting the corrcc1 llttlli'lgclllcrlrt lcchniclues ftit
softrvare engineering prcrjects are not availabl,-:.
8. Procedr:res, methods, and techniques for destgning a pro-iect control systetn
that will enable project managers to successfrrllv coutrol their pro-iect are uol
readily availablc.
g. Procedures, tecluriques, strategies, and aids ti-rat u'ill provicjc visibility of
progress to the project Illanagcr are not availahti:'
10. Standards ald tecluriques for measuring the tlr.relitv r.rt perfonnance and
tire

quantity of prociuction expected from progralltltters anci ci,tta processinll

analysts are available.
(solutions alc
Some of the methods mentionecl-fbr solvirE-!13csc prr;i.,lr.:irlS wcle
not paired with Problems):

Educate and train top nlanagement, Pr,.r '. 111r,-rraqgl's, littd sofiwal"t:

devclopers.
Enforce the use of siatrclarcis, procedures, anci tir'rr-''tll-till"tiiii';l'i'
ci.'i et:tii"c I ilctliotis
Analyse data liorn prior soiirvare project to dc'icr rlritrtr
Define objectives iu tenns of quality desired'
L)efine quality in tenns of dehverahles"
6. Establish success priorit.v cnteria'
7. Allow for cottttngctte ics.
8. De,nelop truthful, accurate cost and scheduie
cstitrilites ihat ate accepted b1
management and customer, and rnallage to tilctll'
9. Select project managers based on abrlity
to lIriLilase -*ottu'arc liojects' rather
than on technicai abiliti'or a'''ailabilitv'
10" Make specific r.vork assignments to So11u'ilt '' c1n'e io1"et'S a'rd appl1" joh
perfonnance standarcl s'
,.

Page 8 crf 76
 1
PLANNING A SOFT\YARE PROJECT

Defining the Problern

o pl.obieri, Lrl be sol.,,ed, include a
\,/ 1' Develop a definitive statement of the
\' and a statement of the
description of the present situation, problern cotrstt'aints'
goals to be achievecl. The problem statetncnt shouid bc llhrased
in the
.p

fl 2.
3.
customer's terminologY.
Justify a computerized soiution strategy for the llroblenl'
Identify the functions to be provided by, and tlie constraints olt, the hardware
subsystem, the softrvare subsystem, and the peoplc' strlisy'sletlr.
4. Determine system-level goals and requirenterrl:s f'ol thc devr:lt'plrent prosess
and the rvork products. i. ' .
5. Escablish high-level acceptance criteria for thc :'\ iiielll. ,{'/
i\0
Developing a soiution strategy tr" f
6. Outline several solution strategies, rvithOut reg.ai cl i'rt ..,ilsii ,,r, '7/*f
7. Conduct a feasibility stucly for each strategy. ,y x
YS 8. Recommend a solution strategy, indicating u,h)' othcl' stlategies lv'ere rcjected'
9. Develop a Iist of priorities for product charactcristic-s'
Planning the dcvelopmcltt process

i0. Defile a life-cycle lrodel and an orgartzational strtrclute ior thc pro.ject.
I L Plan the configUration mcnagetnent, qualltl' lrssllrllnce,
lrtrc'l validatiotr
activities,
'io be usccl'
12. Determine phase-dependent tools, techniques, ;ititi tiotalitrtls
13. Establish preliminary cost estimates for system i1';t'e
iulltl-lent"

14. Establish : prelirninarl" development schedule

15. Develop prelirninary statfing estinlates"
16. Deyelop prelirninarl,,estirlates of the computi;.r feS ;rif ir: tc(l''t t'i:t1 ro L)pel-a1(r

and rnaintain the sYstettl.

17 . Prepare a glossarY of tenns,
18. Identifi, sources of inftrrrnation, ancl refer to thcrrr thtor!l.llll_'l: pro.ject plan.

ji" i rc cusltlrne:''-r
The first step in planttirrg a softrvare project l5 iLi 1lt'cplrie'
tenninology,, a concise statenteltt of the problem to bc sirlr'"d:rlr,l lit; c0ti:it.ttttt.s that
exist for its solution. l'ire clefinitive problem statenretrt shoulcl irluiucic a elcscription o1
the present situation anci the goais to be achie",ed by thr rlijfi sysiell1,

The second step in planning a soiiu,are project is to iictetrltirre the alrpropriatetless

of a compu terize'| solution.

Rage'9 erf,X.

F, )""
 A

lL'.
reliabiliry"
Soffivare characteristics such as performt[c€, cci-trl'll,i:'!'.lrttri level 'rf

Goals and Requirements

'tlamework fbr"
Goals are targets for achievement, ancl serve ro cstablish the
a

softrvare development Proj ect.

Goals can be either qualitative or quantitative:

A qualitative process goal: the developn-ront process should etilrance the

professional skills of quality assurance personnei.

A quantitative process goal: the system siroulci bc delivercd within 12

months.

A qualitative product goal: the system slroulcj nrake u.scrs'.1obs more

interesting.

A quantitative product goal: the system :holrlcl rc<lucc ihc cost of .r

transaction by 25 percent.

Planning the Development Process

Plaming the software development procc.-:r in','ojr'*s s9\'r:I'3i inrponatlr
considerations. The first consideration is to define a product life c1'ole n Lodel.

The Softu,are Life cycle encornpasses ail activitics required ttr

defi ne,develop,tes;deliver, operate arid ttraintain a softri'arc p rod u ct "

SDLC Overvielv
SDLC, Softrvale Development Life Cycle is a proi'css itscil by soit''vare industr)'
to design, develop and test high quality softwares. Thc SDI i iiLrrrs irr ,1'.,-ih.il a hi-qil

quality sofi-lvare that nteets or exceeds customer ex1',,-g1r' j.rlls. l'cltcll:.'; ctltrpletlott

u'it]rin tirles and t'or;1. eslitltttcs.

. SDLCI is the acrortytll oisoliu'are l)eveloptrerrr I rl- ( t' ii
. it is also called as S

. The softn,are dcvelopmeni lif-e c1,cle (SDLC) is rr Ii'rLrtrt-"'t'olk clcl nittg Iasks
perfomed at each step ir-i the software developnir'n[ ])l'orress.

A typical Software Development Iif'e cycle consists of lirc 1,rllo* rnrl slai,es:

. Stage l: Planning ancl Reclurrernenr Analysis

. Stage 2: Defining llequiremenrs

Page 70 of 76

I r'El
 ll
. Stage 3: Desigring the product architecture
. Stale 4: Building or Developing the Product
, Stage 5: Testing the Product
. itu!" 6: Deployment in the Market and Maintcllailc€
SDLC N{odels
There are various software development irfe cycle models defined
and

designed which are followed during softrvare developrnent process.

Tltese models are

also referred as Develoglglj Each process model

ll:ft*ltt frocess Y15.
follows a Series of steps unique to its type, in order to ensure success in process o1'
software development.

jn the industry
Following are the most imPortant and popular SDLC niodels foilolved

. Waterfall Model + R n, 'vt'"fi-qj

. Iterative Model + Prc,&c tyFtru,l
. Spiral Model
.
x C eJ A 1w "Jltl
V-[,[odel
. Big Bang NIodel

The other related methodologies are Agile l\Iodcl, li,q.I) l,'Iiidcl,

Rapio
Application Development and Prototyping lllodels'

SDLC Waterfall Moclel fE* L-:E.c;5c-La --e:l'?)

of waterlall rnodel'
Follorving is a diagrammatic representation of diffe;ent phases
aot-T>wE
SAg
a-"--,,."^*l
I Analysis I vJaterfall MElel

I Design
r.---*) I
coN'E
' l

:[l
l

-
i i
L___ )
l lrnPlementation 1-'- '
i

. ,{-,s\'

Page 11 of 76

't.
 lru

The sequential phases in Waterfall model are:

recltti|ements of tf6
, Requiremcnt Gathering and analysis; All pc'ssiblo
and do;umented in a
system to be develop"d u." captured in this pha:ie
requirernent sPecifi cation doc'
phas:: are studied in
. System Design: The requirement specificatioiis fiottt first
this phase an? system design is prepared.S)'slem Design heltrs in specilyilrg
hardware and system requirements and also hclps in clefining overali systern
architecfure.
. Implemeutation; With inputs from systern design, the systetn is fir'sl
developed in small programs called units, r.vltich are.integlated in the nexl
phase. Each unit is developed and tested for its functionality wuich is referred
to as Unit
:-. Testins.-
. IntegriffinliliTesting: All the units developed in tiie implenrentation phase
are integrated into a system after testing of each unit. Post integration the
entire system is tested for any faults and failures.
. Deployment of system: Once the functional and non flinctional testing is
'leascd into the
done, the product is deployed in the customer etrvirontneut or re
market.
. Maintenance: There are some issues rvhich conle up in the client
environment. To fix those issues patches arc relcascd, Also 1o enhancc tltt:
product some better versions are released. lvlaintcnattce is d.lne tti delivcr
these changes in the customer environment'

All these phases are cascaded to each other in ,,r'hti:h prolrorls i:i s:ett as t)orvinl;
phase is starteil
steadily downwards (like a waterfall) through the phi,rsc;s. I'he next
pJlase attd tf is signed ofl"
only after the defined set of goals are achieved fbr prc'"iotrs
,o ih. name "waterfall Moclql". in this model phases cio not ovet'lap'

SDLC Iterative Model

II
Btrito r ,':]ul
1 . l-
n[JDrveloPrlrentl
^ "J restins . .l ,,' , ,n,.,,,", .,, i

I \ i
\_--------J
-...
Desi6n &
Deve lopment

Build 3

Page tZ of 76

bl

v
*t1. I .'a
 1"7
t3
This model is most often used in the following scenarr''-\

.RequirementsofthecompletesystemareclelLrii,rjcrirlecllilclutrderstood.
. Major requirement, *'Jri be' defined; hori'er''i:r" sollle ftrrtctionalities
01'

requested may evolve with tirnc

. There is a "nha"deni"nts
time to the market constraint' ,': :'
. A new technology is being used and is 6eing lrlilr-1li bv tire derclopment team
"

rvhile working on the Project'

. Resources with needed skill set are not availairtr; ancl are PlanrteJ to be used on
contract basis for specific iterations'
q There are some high risk features and goals uhrch l1ldv change ,tr tlit: trttute'

SDLC Spiral ModeX

The spiral proclcl has foul phases. A software pro-i.:,:1 l'cpcritccily pas jcs througir
these phases in iterations called Spirals.

. Identification:This phase starls w,ith gatherirrr thc brt:rjness 1',rqrlirenlents rri

the baseline spiral. In the subsequent spir-rils as thc procluct t-tlatures,
identification of system requiremenis, stthsl':itenl icqtlirellr*rlts and unit
requirernents are all done in this phase'

This also inciudes understanding the systclrr requirements lrv cor')tinuotrs

comrnunication betr.veen the customer and thc rtystem alleivst At
the enC of
the spiral the product is depioyed in tlie identill,:d tti:ii'ket,

Design: Design phase stafrs vrith the concepluul clcsigr, ti-i tllc
. ir.r"eline spirrrl
..i1 iltc,ciuics" pir-1''sicll produc[
and involves architectural design, iogical dcsigr
clesign and frnal design in the subsequent spira;:
construct or Build: construct phase refct.., ro pi'olir-ltrti()il of' the
actruilx
o
f ilc i,'rociuct rs iusr
softrvare product at every spirai. Irthe baselil;:'r1)irti1 ''',ltcn
lr
thought of and tiic ciesigr-r is being developctl l I'oC iliroox- 'rt'Concepl)
deveioped in this phase to get custonrer f-eedb'e ''

tc(lLril'crl-rc lts and desigi:

Then in the s,bsequent spirals lvith higher cilt':i.\'(rrl js
of the software calluii brrlicl 1;tcclr-rcerl tvitir ri
details a *,orki1g,-,',o,l"l
Th.r, builcls are sellt to cusl"oill.l- i-cr Lr:cilbacl<'
version number.
. Evaluatio, an4 pisl< Analysis: Risk Anulr'sis ilrcli:clcl identifying'
risks. st-tcli as
estimating, and monitoring techriical f"easibilirr .irlcl illellrgelllelrl
sched,leliippog. ancl cos"t oven'un. Aiter testinl 1lls br,iiiti. ai iilc enci
i:f ilrsl
iteration, the customer er,,aiuates the soltrvare atiLi i;roi'li.]cs ieecib',rci':
Following is a diagrammatic representation of spiral rtoc'iei ljsiirlg iit': activities
in
each phase:

li,

'"r
 t4

V Model
TheV-modelisSDLCmodelwhereexecutionofprocesseshappensina
sequential manner in V-shape" It is also
known as Verification and Ettrti*11g{gt
based on association of a
v - Model is an extension of the waterfall model alrd is This means that for every
testing phase fo, development stage'
"u"t, "orresponding This
,injtJpt *e in the d"r"top*.nt cycli there is a directly associaled test ing phase'of the
i, I highty disciplined model and next phase starts onl1' after conrpieiion
previous phase.

The below figure illustrates the different phases in V-irr.odel of SDLC.

SDLC Bie Eane Mods!

thcrt- j: iit' sl t'c'iflc proces:j
T'he Big Bang model is sDLC nlodel wherc
reqtrtl'cci lllollelr arld erlbrts as tht:
fbllorved. The developirrent just sta(s *'ith the
q'hich 1r1i1\' 01' nlav llot he as per
input, and the output is the softwale develope{
custoilrer requirement.

Big Bang Model is SDl,c model rvhere therc is iio fb:ilrai developtnerlt
not srrre zbout u'hat
foliorved anfl ver.y little pianni;tg ls lequirecl. Eyen the t:Llstgrner is
gn Lllc 1i1' u'ithout tnueir
exactllr he wants and the requirements are implenlcrrtcd
analysis

Paee 14 of 76

tr ir

,/q'.^
 t;
is followed fbr small trlLriccis vi'hert" il'r:
developln(rlll
UsuallY this model
teams areYerY small'

Ae& Model
and
Agile thought had started early in the software deveiopment
Process
started becoming PoPular with time due
to its flexibility and adaptabilit y'

I'rocess (1994)'
The most poPutrgr agile methods include Rationai Unified
(1996), Adaptive Software
Scrum (1995), Crystal \ear, Extreme Programming
Development, Feafure Dn\n Development, and Dynanlic
Systetnr Dcvelopment
Method (DSDM) (199s)- ese ui" now collcctir ely rcictled to as agile
methodologies, after the Agile if-esto was Publislrr:ri ir, lll0.i ,

Follorving are the Agile I\{anifesto principles

()illl.lc1lt" scif-rliqanizatton artri
. Individuals and intcractiotrs in agile clcYe
motivation are important" as are interactiorr:' lik': cu-loua
lir)il artd parr

programming. j ._.r r,r_.. r-.,.,i ,.-.o, rtl 1:

. roi*urr..
Working Demo rvorking softwarc is ct-rtr:'idere6 tllc besl lneatts
communication rvith the custom". f,-, ,'d"'strlt'ri
liteil rceluiretr ettt' insteud I'i
just dePending on documentation'
u'r')11tlt rc gathe;ed conipletelr
. Customer coilaboration . As the requirements
cotllitl''ii'-us cttstotrcr
in the begirming of the pro";ect due to varioiis l'actors'
interactiott is veiy imporlant to get proper
prodrict reqltitcirtrtlts
.Respondingto.trorrg."agiledevelopmeuti:;fbcuscclonquickl'espollsesto
change and continuous development'

ijv.rs-l
i
. It('rstion tr

t-p",ilii"-l
ffi,,,
f"..,*1 G111,:f1l
IttrraUofl Z

tu-'i,rt"€f
fe:f;-l
(ffi,,,
['":'i;tl [;;;;;;';i;l
lieratron 3

{-jjg:s--l ['::@

t:\ U
t:'.
 )b
RAD Model
-- typical scenarios where RAD can
be I'rsed:
Following are the

be moriularized to be cielivered
. RAD should be used only when a system catr
in incremental manner'
a

. for nro leling'

It should be used if there.s high availability of 11r:signers

t ode generating
. tt ,t outd be used only if the budget permits usc of automated
tools.
a

. RAD SDLC model should be chosen only if dornain expefis artn available with
relevant business knorvledge.

. Should be u,here 1|e requilentents changc clu,-irlg tilc coursc of the project
use<J
ancl working prototype, u.. in be presenteci lo curitot-trer in stnrrll
iteratiotrs of
2-3 rnonths.

r::-:-:)
tffiffit l::*'""**'I
fTill ., G;ll
[. :.ri.o,a.ll,r. I
L-*.*.J
rEl
Ll',.] ,trfflot':" I
rI u"l*.r
',;-l I

[il,{"E]Il Gd-qrr-l
t".'s'::{r"J L-9J
r.-qffi;l
I,",frrtifrd -.,
f '-"Fl
I ..rsl"q" . ,' I
!---.-.--".....-.,",...".+
Prototrr,pe 1 PrototYPe 2

soltt@
protoivpe\
T'he Softu,are prototvping refers to building siiil\'/'ii1'c lllllllrcrtrr-)n
rvhich display the functio,roiity of the product uttil,,t. ,i.11'.iiilrl'liclll bitt lll'ry nc)1
actually holcl the exact logrc of the origrnal softwarc'

Page 16 of 76

,a . F:.tV
 17-
Softwaroprototypingisbecomingverynolrrlal...rsasoftwatedeveloprnettt
reciuiiemeuts at an early stage of'
model, as it enabl;t ;; uiderstand customer
from ihe customer a,d helps software
development. It helps get valuable.feedback produot
designers and developers underrtund
uiout what exactly is expected fiorn the
under develoPment.
prototlpe:
Following is the stepwise approach to design a softwr.ire

.' underst'inding the verl

Basic Requirement Identification: This step ;rtvolves
basics product requirements especially in tenris of user
interlace' Tlte mor<'
intricate details oith" internal design and extctltal aspects lil.e
perfirrmance
and security can be ignored at this stage'
. Developing the initial Protofype: The initial Protolype is develoPed in thrs
stage, *t the very basic requirements are sl'towcesed and use r interfaces are
v "r"
proiria"a. These feaiures may not exactly work in the same fiItul'lller internally
in the actual software developed and the wot'karounds ar:e used to give tlie
same look and feel to the customer in the protollupe developed.
. Review of the Prototype: The prototype devcloped is then presented to the
is
custorner and the other important stakeholders in the project. he tbedback
'X

collected in an organized manner and used for frrrlhel enhan';etnents in l.he

product under develoPment.

comments
. Revise and enhance the Prototype: The feedbaek and the reriew
are discussed during this stage and some ircgotiations lialrpen
with tlre
customer based on factcrs lik;, time a1d budget constraints
and technical
feasibility of actual implementation. Ttre ctianges accepled are
agairt

incorporated in the nerv Prototype developeri anrl the

cyclt repeat:; unlil
customer exPectations are met'

ettstrre the aciequacy of the systettt

A software Requirements Review is held to
specitication the Softu'at:
Definition, the Project Plan, the Software Requirenrcnt
Verification Plan, and the preliminary.User's Manual'

The Cost Model

Anotherviervofthesoftrvarclifecyclecanbeobtairreclbyconsideringthel
a softwarc pro;ect" The cost of conductirlg
cost of performing the various activities in
a software project is the sum of the costs incurred
ill conducting eaclr phase of thc'
project.

PI,ANNING AN ORGANIZATIONAL STRUCTU TT ii

must be perfomred'
During the lifetime of a software product, variotts tilsks
quality
The tasks include plannin-e, procluct development, services, publictrtions'
assurance, support, and maintenance.

The planning task jcientifles extemal customet lllri illlci';:ai 1 i-oclt-tcl net'tls,
1

conducts feasibility stutlics, tltcl ntonitors progress 1:' rll bc!,11i11i11g .r ctlCl tll til.r:
product Iife cycle.

PageLT of75

{tr I
 1f
Programrning Team Strttcture

EveryprogrammingteammusthaveanirltemalsiruCture.rhebestteatn
Structureforanyparticularprojectrlependsonthi:nati:teofthe]lrojectandth(]
product,andorrthecharacteristicsoftheindividualtcatrimclrlbct.s.
members partir:ipa'le il ai1 ctecrsioiis;the
chiel''
Democratic team. in rvhich all team
i's assisted ancl supllol-ted by othol
programmer team, in which a chief programmer
team members.
teatl' iitrcl the chit:l'
Hierarchical team, rvhich combines aspects of the tlel-il'crlltic
illso pussibie'
programmer team. Variations in these basic forms arc
attLl'lecisitllts rrtarle
Democratic teams, or Egoless team, in this tean. !r)i.ii:^ lilc set
by group consensus.
'llre ciriel'progrerrlnrer takes illl
chief Programmer team: It is highly structured.
major decisions.
atter'dsreviclvs antl
Hierarchical tearn structttre: The project leader asslgns iilsks,
r"'orkload'' antl irafiic:ipates in
walkthroughs,detects proble6r ai'eas,balances the
technical activities.

Management bY objectives (MBO)

ilir:.s 1.1 691,i-:131-rl'rlent olri'rittcti
An effeotive teclinique fbr assigping\,l,ork ar:iir
illl:iLl,ndcrstaltciirrgs and falstl
job descriptions fbr each projeci nrember' Tlris reduc(]S
assumptions of both manager and managee'

Managementbyobjectives(MBo)isarelatci]lechtiiiluct}-iat,sirrcreasingly
popular in software org^nirutions. LJsing
MBo, eml)i,)i'ees'lct lileir'{)\\'l-1 goals alld
parl^ rtr'rrs jtr tl're S( ttlrtl:' 0f ille ir
objectives with the trltp c,f their supervisor,
supervisor,sgoals.andareer,aiuatedbymeetingCol-lCi-t:i.].tr,rii1,tjllilb1eciir,es'
applied at alj ]cr,c1s 1rf ;1i1 irrl litttzlttotl,
atld
tr4anagettrent by objc:ctir,es catr be
Such aS cc'tllplet'lotl o1'clc'r1s'11
or testlllil'
can inclr.rfle both protiuct-oliented objectiyes'
anrl self-irnplovenient olljcctiycs, such as
skilis ig 'l':qLilii :itld 1rr ''psrlttiotls icrt

advancctrtcttt.

OTiIER PLI\NNING r\ C:T I\TITIES

otherplanningacttvitiesinciucleplanningtliccilllil!i'litiiill]lllanaqelllcriland
Iitcilriioil ;:rlci ancl
quality assurance functions, planning for indepencJetri '' "'c|ificatron'
planning phase-depenclent tools and tecluiiques'

Fage L8 of 75
 I1
Planning for Configuration Management and Qualil'1' 'dssurance

configuration management is concemed

with controlling cl^anges in worl
products, and maintainirrg the progralrt
products, accounting for thJ status of work
supportlibrary,wiriciristhecentralrepositoryforallprojectiltformatitrn.

Planning for Independent Verification and Vali<iation

of work
An independent organization may provide verjlication and valldation
and consistent
products. Verification ensures that various work prociucts are coruplete
with respect to other work products and customer neecis'

Validation is concerned with assessing the quality of'a softl','are s)'st(rlr in its actual
operating environment. Validation typically involves planning and er ecutiott of te.sl
cases.

Planning Phasc-Dcpeudent Tools and Techniques

Automated tools, speci alized notatious, and ni()(icl'lr tcctlniqtti:s are ohen tts,-'d
'd
to develop software requirerncnt specifications. arclii t co[ut:tr1 arrcl cletail ciosigns.
atrcl

the source code.

Other Pl:rnning Activities

cstirll;rtes ftrr
Other plaming activities include preparing prciin'irtlly L-ost
schedulc' estabhshing
pro'Juct deveiopment' establishing a preliminary devciolrr'leilt
(:rll1i|-ratcs ol' ihc' cornputing
prelirninary staffing levels, anrJ developing prelinrillri-r'
resources and persorral requircd to operate and nlaittt.tir:
llt'' s' : ':n

Page 79 of 76

6:t
:-
 !j t gi,W*r,
UNIT * II
SOFT\,VARE COST ESTtrII TI.[ON
otl': of thc Lnost dif licult attd error
Estimating the cost of'a softrvare product iS
prone tasks in .oftr"^r" engineering- It is difficult
to t,nakc an accura'e cost estitnittr'
because of thr: l trqe number ol'
during the planning phase of softu'are development,
req"trre a firm cosl
unknown factors at that time, yet contracting practices ofteil
commitment as part of the feasibility study" $;&L"prya.

SOFTWARE COST FACTORS

;
N{ajor factors t}rat influence softrvare cost

Programmer ability
Product complexity
Product size
Available time
Required reliability
Level oftechnology

There are many factors that itrfluence the r:osf rli' e soiirvat,: Irodtrct. T]te
I)r n'i:in tenlttrcc
effects of most of these factors, and hence the cost ol ;r devcioplllcllI
effort, are difficult to estimate.

Programmer AbilitY

The goaX rvas to determine the relative influcrtce of balch arrd time-sharetl
progtanti;rets ''i'ere cJcit
aCceSS On pr6glammer productrl'ity. Trvelve erpeneitced
'i:atcl: faciliiies and s0i11c uslllg
given two programming problem to solve, sotne using
time-sharing. The resulting clifferences in inclivrtlrr:l
pciiimranc0 alilong the
'7 iv small effect
programmers werernuch greaterthan could be attributc:cl to the rciati"e
of batch or titne-shared machine access'

Product CornPlexif-v'

There are three gcnerally ack.ou'lcdgc ciil!"i(rf i's irl softv al c i;l'tlducts:
:rrrd screnliiic pf')grallls: iitilill'
applications programs, u4rich include data processtt]g
cvst''1'1s: ltlrci s1'1t911,lcvel
prograns. such as cornpilers, iinkage editors' and inverrl(i1'\/
prog,ramS. SUCh aS data-baSe lTlenagelnellt S,\'StelllS, 1)1' ''irLi11'!1 ljVSLCll.lS'
aild reai-tltrl''
i.)\' ri
systems. Apolicaticls proglams are clcveioped in il'r, lllt"ironircili- lti'i'rvirjed
language compiler such as F-O|{1'RAN or Fasctli"

Boehnr uses three leycls of procluct coutpic;iriy llil,.l proviclcr cqttatitlns trr
"r:1'thousatrdr
predict total programmer-rtonths of eflbrt, PM, in tenrt:. e.f ihc ttumbe
of delivered source insti'ucttot.ts, I(DSI. ill the product.

Fage 20 of 76

[i..:,

ll ,,"'.
 ct
can lre obtaincd by rrrultrplying thc
Progfammer cost for a software project well:
per progranlrlrer-month' The equations
effort in programmer months by the cost
derived by examining historical data
from a large ntttr,ller irf actrra] pro iects.

TheselevelsroughlycorrespondtoapplicatirrnsprogralT}S,ulilit)..pl.()gran}s
and systems Programs;
**
Applications programs : PM=2'4* (KDS I) i' 0'r
Utility programs: PN{:3'0*(KDSIix*''
"
Systems programs: PM:3'6*(KDSI;x* i''O

The development time for a program, as given by Bochnl' rs

* *0'
Application s programs :'ID EV:2. 5'k (PM) 3S

Utility programs: TDEV:2. 5 *(PM)*'F0"3 5

* *0'3 2
Systems programs : TDEV:2 5 (PN4)
+
"

Product Size
one'
A large software product is obviouslv more expensive to ciev'ciop than snrali
r'

Available Time

Totai project effort is sensitive to the calcrttlrir Liine availalrlc

lbr prc'ject
i'iI- optiiril i cicvclgpnlettt
completion Several investigators have studied the or'li::;ttiiil
l lOIt' ltrtltl t'ff-trr1 rl
time, and mOSt Of them agfee that Softrvale p1o.lt'r''' l'ctitr:''r'
time is compressed or expanded from the
opiiiilai tilre'
development
oi
Project efforl is inversely proportional to thc
iourth po\\rer 'leYeloptlletrt
tirne, E=k/(Td**4)"

Required Level of Rcliabilirl

Softrr,arerelitbilitycanbedei-rnedasthellrili;ilbriitytjrrtapl.ogratnrr,llI
perfonn a required fr.rrtctior-r un<Jer State coilclitiorrs
tbr a stalied pr:riod ol titlle
r.()b,st,J;,'. r--r)r)1 plvr'rrcss' ttitti
Reriability can be expr-essoil irr ter,rs of accuracy.
consistency of tire source cocle (tiicse ten-,s
are irei]rcci i, 'l-able2.l). Iieliabilit>'
b''rl tilel'e is t cost i'scciated "l'i1h
characteristics can be br:ilt into a softlvare procluct,
atld '" c:r'ificiittorr ailcl
the increased level of analysis. design, implemirtrtatiotl,
validation effort that mr:st be exefied to ensuLcr high i'c1r;i'ni;itr''

Level of TechnologY

The level oitechnologl,in a softrvare cleveiopin'.:l)t oiuiect ts i'r flccletj b1'

t1l':

programming language, the abstract machine i'l'rll,rl"r,'lll't: plls slliivarc). tht'

proEamrningpraclices, and the softw'are toois usei. il ; \','ell iilloutl il ai thc ]illrilbc'l
of source jnstructions lyritten pcr rlay rs largely indep,'lrrir:tit. oillie langrrage useC' ,lll\j

Page 21. of 7 6

lfg

:4
'l . G[ill],l,, '
 eA
such a:; i ORTRAN an<[
that program statements u,ritten in high-level languages
st;rteuetrls'
Pascal typically expand into several machine-level

ModernprogramrninglanguagessuchasAdeprorlidc:aclditir,natrfeatureslct
improve programmer productivlty and software
rcliltbility' These f':atures includt:
corilpilation, excelrtion handling'
strong tlpe-checking, data abstraction, separate
intemrpt handling, and concurrency mechanisms'
and design
Modem programming practic;es include use o1'svstcmatic anal/sis
techniques, structured design notations, rvalkthrorrglrs atlcl inspectiltls,
structurcd

coding, systematic testing, and a program developmerli iibrar-v"

SOFTWARE COST ESTIMATION TECHNIQ LIES

Software cost estintates are based on past pcrfbrmance. I'lrslcrical data are
used to identify cost factors and detenline the relativc ittrportance elf various factors
within the environrnent of that organization.

Cost estimates can be made either top-clorvtt or bottom-tip. Top-do$'n

estimation first focuses op system-level costs, such as thL) colllpiltitlg rcseiurces and
perSonnel required to deveiop tlte s1'stem, as u'e1t ;is iitc cost:; o1 ccnfiguratit'rtt
management, quaiity assurance, systeill inteEgatit'n. tl'ainit'tg, itl-tci ;rubiications
projects'
Personnel costs are estiniatecl b1, exatnining the cost ol':;rlliiar past

module or
tsottom-up cost estinlation first estimates the i:rlst to del'elop i rch
subsystem.

Expert Judgment
cr1.,i:ri-.1udptrcn1, rvliich rs
The most widel,v used cost estimation techniquL'is
an inherently top-dorvn estimation techniqtte. [51'1'''t jutlgrnent relies on thc
of one or nlore kc;' peopie in tht:
experience, background, ancl business sense
organization.
illll'llllr';rll
An expert might arive at a oost estimate in the foiiort'ttlg
sinrilar to one that
The system to be developed is a process cotrit.trl si'iillrlll
\\'c rlitl rtot llet rrch on the
developed last year in 10 rr-roirths at a cost of $1 tnillr";r'
lci the baseiine
project, but we did rnake a respectable profit; thereforc, 11s s6ljirstnlenl
'l-he neu, system has similar cofltrtrl litrlctiotls. but lras 25 perceni
froject is required.
more activities to contr-ol; thus, rve rvill increasc oul tirrtc ancl cost
eslitlates b1'25
jlorv'cVer' $'e
percent. The previous systern lyas the first of its type thrtl w'r: dt'r'clopedl
tvill the same cotnputer and extenral sensing/cotltrc,liille devicr:s, atlci nlally
use
of the
same people are availabie to c1er,'elop the nevv systeln. .Lj \\ic t,rtlt reducl o1'll'estinlatt
by 20 percent. Furthemrore, \\,c oAn reuse mucir o1' lilc lt,'\'-1t'\'t.l .,rtie trtrrrr [lit;
'urllrl" l'he net
previous procluct, which reduccs the time and cost esiiinal.::s hr'2-5 De

Page 22 of 75

!19{.q ri L

-l'
 0t,z
,/5
oi 20 perceirt' ivhich resultt;
effect of these considerations is a tirne and cost reclucltcti
Litne. we krow that ther
in an estimate of $g00,000 and 8 months developrneul
customerhas budgeted $1 million and
I year ijeii'''ery iin.re itrr the systetrt
and bicl the systern at s"850'000 and 9
Therefore, we add a small margin of safety
months develoPment tirne.
can also be a
The biggest advantage of expert judgment, tlrltl]elv. cxpericnct],
liability.

The major disadvantage of goup estimation is the etl"ect thl,t interpersonal

goup dynamics may have on inclividuals in the groulr. Croup memb( rs may be less
than candid due to politicai considerations, the preserrce of ar-itiroritl figrrres in the
group, or the dominance of an overly assertive grolll) rrrL'llibcr" TIie D,:lphi technique
can be used to overcome these disadvantages.

Delphi Cost Estimation

The Delphi technique rvas developed at the Ranii Corpor"ation ir i 9'1E to garir
expert consensus without introducing the adverse sirie effects of gro'-rp meetrngs
(HEL66). The Delphi technique can be adapted to soliu'iire cost eslirl.iation in tire
following manner.

l. A coordinator provides each estimator with thr: Sysietrl Definition document

and a form for recording a cost estimate'
aiiony.nously'
2. Estimators study the definition and completc their cstimates
They may ask questions of the coordinator. iltt thcy do not
discuss their

estimates with one another.

3. The coordinator prepares and distributes zi slllltl']]:i1\'o1'tltc eslimators'
b1' 1Lt estit'tators'
responses, and includes any unusual rationales lloled
I'ls'ng the results
4. Estimators complete another estim.ate, agaill '1I'r)ll'yntr:'r;s1\"
ririfer s1;ar"ply fi'om tht:
from the previous estimate. Estimators r,.,hose cslirl-]atcs
tl cir estin.iates
gro,p may be asked, anon){rous1y, to provicle irl.Liflcaticrll lbI
No glou) iiiscussiotl t''
5" The process is iterated 1br as many rounds aS I'L' Lrtl'r:d
allorved during tlie entire process"

The following apploach is a variation on the startrla.rd

i)r:lpli; lecilrliquc that jllcreascr
comtnunication whiIe prcsen'ing anonl'mity'
and
The coordinator proyides each estimator rvith a S)"teiil Detinition
atl
l.
estimation form'
2. The estirnators stucly tlie definition, and the cot-'riiitlator r]r11s a ilr(,'lP tlloetlnSl
so that estimators can ciiscuss estimation issucs ivitli tilc coorcljntltoi alid one
another.
3. Estimators complete their estimates anonymousll

Page 23 of 76

i{'.rrii}
'.6'

ria
 e4
the s:sltrTlstes' irut cloes not record artl'
4. The coordinatorprepares a summary of
rationales' 71 issucs ''r4ter e the estimalcs
5.Thecoordinatorcallsagloupmeetingtofocusonl
vary widely
e!
qnnfher estimate,
'^*^lara another agalll anoflr$11ously' fhe process rs
6. Estimators complete
iterated for as many rounds as necessary'
not leac to A conseilsus estimate'
It is possible that several rounds of estimates will
with each estimator to
In this case, the coordinator must discuss the issues irrvolvecl
determine the reasons for the differences. The coordinator'orCer
may itave to gather'
additional information and present it to the estirnators in
lo resolve the
differences in viewPoint.
* /:t
Work Breakdown Structurcrs n()gt-..:,. t..r^,",

v
l-he rvork breakdou,n structure rnethod is a bortotri-itJr estitnatic ir tool. A
rvork
dr-ral prrrls cl1 a
break-dorvn structure is a hierarchicai chart that accoirrlrs 1ilr the tnclrv
system. A WBS chafi can indicate either product hier]r'chv
or proccs: irieratclty'

Procluct hierarchy identifies t[e product compoltctlis rnd incijcates thc ma]lne r

in which the components are interconnected' A \\'i]S cliiu-t of pl'oi-ess hrerarcltt'

lhose acitvitics' Tlprcrrl
identifies the work activities ancl the relationships anroirg
product and process WBS charts are iilustlated in Figurcs
:'ia ancl b' llsine tire WBS
technique, costs are estimated b)'assignirrg costs
to t-r'eii ^'rtiividr'ral co;trponent in the
chart and summing the costs.
iLre ill ;rlentiff ing atttl
The prirnary aclvantages of- the WBS techrtitlue
accounting for various process ald product
factors' iirtd in rnaking explicit exactly
vrhich costs are included in tlie estiu-rate'
rvorK bleak.j01,,.l1 Stl.tlotures arc the
Expert judgmerrt, Sloup conSenSUS' atld
Mant' organizatiot]s use all thretr
most widely used cost estimation techniques'
approaches and iterate on the eslirtrates
until differenccs have beett resolveti'

Algorithmic Cost h'Iodels

Algoritlrrniccostestimatorscotnptttetheestitllllictici.lsioflscliir,arei{},Sto]ll
:e systelll
as the sum of the costs of the nrodules
and subsyslclris lit.it c'-'tnlli-i the
Algodthmic modeis are thus bottont-ltp estimators'
r:osi ttlod'r descflhecl b1
f'he Constructive Cost lv{odei (COCOIV{O) is an a}goi"lthtrtii:
Boelln (BoE8 1)' Cocol\'Io is il'ret-l)' sntntnat'izecl ber':
llr-rilrilltll estinirtes
\\rhen using COCOMO. [he equattotts 31s l]5r.'tl 1o lltoytcie
of programmer-months and cleveiopment scheriule iirr a pt-ogl'ant tllrit
based ott the

estimated number of Deliverecl Source Instructioirs {f-rSI) 111 the uttit'

Eflbrl

Page 24 of 76

E
 Cr
multipliers are then used to adjust the estimate ibr product altributes,
domputer

attributes, personnel attributes, and proj ect attributes'

For example'
The COCOMO equations incorp orate anumber of assumption;'
apply irr the following
the nominal organic mode (applications programs) equations
tlpes of situations:

Small to medium-size projects (2K to 32K DSI) :

Familiar applications area
Stable, well-underslood virtual machine
In-house development effort

Effort multipliers are used to modify these assutnptions.

The following activities are covered by the estinrates:

Covers design through acceptance testing

Includes cost of documentatiorr and reviews
Includes cost ofproject manager and proglam librarian

The effort estimators exclude planning and lnall'sis costs, installation and
training costs, and the cost of secretaries, janitors, ancl cotnprtlsr srpet'.ttors. The DSI
estimate includes job conh'ol statements and soLlrce statelnent:i. but exciudc-s
comments and unmodified utilitl'routines. A DSI is con.stcit:rcd io btr onc line or card
image, and a programmer-month consists of 152 progralllmer-houl"s"

other assumptions concemtng the nature ot':ri'iiv'''iirc proiectrr estimated bv

COCOMO include the follorving:

. Carelhl definition anci valiciation oi'requirernents ir; ri,lri'ot-trtt:i h)' ;l :,,, rltll llulnller
tlf
capable people.
t The reqtrirentents remaitt stable tlroughout the plrrlr'(.t
a Careful defipition ancl vaiidation of the architecturr ,l ilr.:sir-:lr l: l).iii)l'll .r.l l,'"'l strlali
nunrberof capable peoPl e.
Iletaileci design, co,Jirry, ancl unit testing arcr periirnlrr,,i ill tll:rliiict irl ; r'i-'r-ips
ol
progralruners n'orking in teams.
r Integration testing is based on early test planninq
. Interface slrors r-rnrti-l'found l-,1'untt testitlg atltr irl'il:sllr;clit'rlts a;l i u'aik-
"r"
tluoughs beforc integratiot-t iesting.
. Docurnentation is peribirned incrementally as parl
()1-tl'le rle', cltlt.rlttetll i)roctrss'

ESTII\{ATING S OFTI\'ARE N{AINTENANCE C() S I'S

. Softrvare mainteriance typically reqtrires 40 tr irt) ller3cl)i. anci rn some ceses

much as 90 percelt, o1-1iie rotai life-cycle efti.,rt clclolcii 111 ;1 ;r,lftrilre product
Mainterrance acti\/1ties inciude adding enhAt.tci-:ntcltl.s ir) t)tc pt'o,-1tlct" adlUrtirt-r-
the product to neu, ltroccssing ertvironment ancl , ()t'r'rrciliill llrotLit rrl.s,

Page 25 of 76

t, e
 hr
,/,b
r A tvidcly used nlle of tllurnb 1br the distribrrriolt t,ri-nialnterlalce activities is
percent 1irr"
60 percent for enhancements, 20 perccnt for rtcial;latton, and 20
error correction"

soFT\YAnE REQUIIIEMENTS D EFINITION

The Soltrvare Recluirernents Specification is a technjcal specitication ot'

requirements for the softr,,'arc product. The goal of soii',r'are requirernc'rts definition is
ro completely and conliSr;fitji'\ecify the technical i'cquirernents firr thc softrvart:
prodnct in a c_qpcis_e and unambiglrous manner, usitt-t, fbrtrtal notations ,rs appropriate-
l,).,r' r .: f,,)..'.. ',, ,
THE SOFTWARE REQ{-IIREN,{EN'fS SPECII;ICI\.I'lC)N
(loc,intcttt i:; presentr:d in Tablc 4. I
?'"" Th" fomrat of a requireirrents specificatiou .

as i]_1_US-llqrcd there, Scctions i anil 2 of the r-ecluricltcnLs cloculr :trt yrrersent itt't
oven,ieu, ttf prorluct feanrres irnd sut'uutarize ihc irl'oijrlssllrg -'ttvtr'flltnctttli f<ir
developnient, operation, attcl mainternance of the proclit':I.

Section 3 specifies the extematty olr_-*ry-!le charactcristic-s of thc soltvrare Product.

Items in Section 3 include user <liiplays and repori tbrtrals, a sul'-]lnary of uscr
commands and report options. ,Jata flou, c'lia!,ran-rs. and a dlrta dictionary'.
Specifications for thc usel inrerface dispiays ancl repot-ts ale t efinetnents
of
informatiol contailed in the S),'-stem Definitorl and thc preiilitipary User''s Matlual'

Data florv diagrams ''liiq'- ,*'' ':' 'i'''

Data f'low diagratns specify rources and rlala sinks' data stores'
datt
transfomrations to be perfornred ou the data, and
thc 1lo$' of data betu'een sources'
sinks, trausformations, aticl stores'
as illiist|atccl in Figure 4'1' or blr
Data flo$,diagrarns can be clepicted infonnalll',
4"3, $'lri';'e (iata soLrrces anci dirtlr sink:;
using special notation as illustrated in l;igure
are depicted by shaded rcctangies" transfbillrations
irr 0r'ciinui'! l'lcti-lr'qlcs' lirttl tlallL
stores by open endeci rcctallgles. The arcs
irl a clata 1l "'r'clittilralll S[)Crr:ifi data florv'
u'hosc ''rllirfaJllritsilcs s rccilietl ill thi:
they are labellecl li,iththe nallles of ciata items
data clictionarY'

Likcflorvchafis,dataflorvdiagrallscanbetiscilltatlvlevel<fdetail''l-hel'
the irller u'orkii.tgs of the fuilctiolll
cau be hierarchically clecornposeil by specifying
flow cliagrams, Unlil<e flotrcheds, ciata llorv diagratns are
nodes using adclitional data
not concemed with decision structure or algorithllic
cletai1s.

Tabie Fomat of a softrvare requirements specification

Page 26 of 76

* -'i?'r"''6
 dT
Section 1: Product Overview anci Summarl'

Section 2: Development, Operating. and Maintettntlcer Eilvirotl tlents

Section 3: Extemal Interfaces and Data Flou'

Section 4: Fuuctronal Rcquirements

Section 5: P erformance Requirem ents

Section 6: Exception Handling

Section 7: Early Subsets and hnplementation Priorrties

Section 8: Foreseeable Modifications and EnhaucemenLs

Section 9: Acceptance Critena

Section 10: Design Hints and Guideiines

Section 1 1: C--ross-Reference Index

Section tr 2. Glossary of Tem-is

A data dictionary entry is illustrated in the follorving Table. Entrics ilt a data
dictiolary include the name of'the data itetn, and atlributes such as the data flow
diagrarns where it is used, its purpose, rvhere it is derived fiom, its subitenls, and any
notes that rnay be appropriate. Each named data itcrn on each data flow diagralrl
should appear in the data dictionary.

A Data dictionary entrY

Create

WHERE USED:

PURPOSE: Cleate passes a uscr-creatc(i closigrt ctltilv to the SLI'

processor t'or vertfication oi j\lllil\

User Interface Processor

DERIVED FROM:

SUBITEMS:

Page27 of76

,? .

! 1 ,n}ri!.
 v' I-lses

Procedures

R.eferences

Create contains one cornplete user-created design cntity. i

I

J
Section 4 of a Software Requirements Specification specifies the functional
requirements for tire software product.

Performance characteristics such as response time fbr varicus activities, processing

time for various processes! throughput, primary and secondaly mem(1ry constraints,
required telecommunication bandwidth, and special items such as extraordinary
security constraints or unusuai reliability requirements are specified in Scction 5 of
the requirernents document.

Exception handling, including the actions to be trlien anci the messages to be

displayeci in response to undesired situations or events. rs descritred in Section 6 o{'the
Software Requirernents Specification.

Section 7 of the Software Requirements Specificatrort spr:rcilics cat'lr, sttbsets an<[

implernentation priorities for the system under developrtrcni

Foreseeable modifications and enhancements that nray be incorpo'ated irlto th<:

product following initial product release are specificcl in Scctior, $ ,rf the product
requirements"

The software product acceptance criteria are specified irt Section 9 of the

requirements document.

Section 10 of the Softrvare Requirements Specification contains design hints and

a. guidelines.

Section l l relates procluct requiren-ients to the sources r,f ir-iiitl'ttt;ttiotl used in deriving
the requiremettts.

Section lZ of the Software Requirements Specificatior ttt'or.'icles definition o1'tetms

that may be unfamiliar to the customer and the product ii1l1rslopelS.

Desirablc propertics

T'here are a number Oesirable properties thltt a Sr,'fttvarc R ct,ttire tllents

of
..;
Specificatiou should possess. In parlicular, a requirelrcttts cit.lcuittetlt should bc:

Page 28 of 76

+"ir
 Correct
Complete
Consistent
:!
Unarnbiguous
Functional
Verifiable
Traceable
Easily changed
Y

,a
FORMAL SPECIFICATION TECHNIQUES

v Specifuing tire functional characteristics of I :ioftrt'are procluct is one o1'the

most important activities to be accomplished during reqrtircments aialysis. Formal
notations have the advantage of being concise and unantbiguot-ts, they support formal
=r' reasoning about the functional specifications, and they provirie a basis lor verification
of the resulting softrvare product.
v
Both relational and state-oriented notations at'c usecl to specify the functional
F characteristics of software. Relational notations are biised on thc collcL'pts of entities
and attributes.

Relational notations inclucie impiicit equatiotts. r'cclill'crlce relaliotrs, algebraic

jnclude decision tables,
axiorns, and regular expressions. State-oriented notaliotls
event tables, transition tables, finite-state mechanisms'
lrtlti Pch'i uets'

RELATIONAL NOTATIONS

Implicit equations

IrnplicitequatiorrsStatethepropefliesofasoltritonr,'iil.l.ioutsta,llrgas<llution
method. One niight, lbr example, specify matrix inver:;ton
as

MxM':l+E
ttrat the matnx
ht the above Equation, matrix inversiotr is specitlcC such
yiclcls the ldentity tnatrix i
product of tiie original mairix M apd the itn'ersc of N{' '\'1"
allori'able compulatlonal en'ors'
plus or minus the en.or matrix E. rvhere E specifies
l''eurs such as tuairix stzc'
complete specification of rnatrtx itlversion l]]ust illcltrrJe
iype of data elements, and degree of sparseness. CiiYerr a complt:te
turtctionai

specitication for matrix inversion. design involves specifving

a dala structure' all
algorithm 1br computing the inverse, altd a packagrng iechnlque
fbr the inversiorl
module,

.Y

Page 29 of 76
 )c
I
H; Algebraic axiorns

Mathematical systems are defined by axiorns. The axiorns specrfy fundamental

properties of a system and provide a basis for deriving a<iditional prc'perties that
are
t*r''t
implied by the axioms. These additional properties are called theorems

Regular expressions

Regular expressions can be used to specify the syntactic struc ture of symbol
strings" Because many software products itrvolve processing sf .synbol strings"
regular expressions provide a powerful and rvidely used notation in software
engineering.

State-Oriented Notations

Decision tables

Decision tables provide a mechanism for recording complex decision logic.

Decision tables are rvidely used in data processing applications and have i.m
extensively developed iiterature (POO7a). As illustrated in Table 4.3, a decision table
is segmented into four quadrants: condition stub, condition entry, at;tion stub, and
action entry.

Event tables
sets of
Event tables specify actions to be taken u4ren events occllr under different
conditions. A two-dimensional event table relates actiotrs to two variables;
(M,E):A,
where M denotes the current set of operating conditiols, E
is the event '>f interest, an<l

A is the action to be taken.

Table: A fwo-dimensional event table

Event

Mode 813 831 E45

Start-up A16 A14; A3l

Steady l\6, A5

Shut-down

AIarm

Page 30 of 76
 ?l
Transition Tables
state oi a system as it
Transition tables are used to specify changes in the
the statrrs of all entities
function of driving forces. The state of a system summatizes
in the system at a Particular time'

A simple transition table

Current
input

CI
:fn
SO SO

S1 S1 S(j

Next state

UNIT - III
SOFTWARE DESIGI.I

SOFTWARE DESIGN

Software design, there are three distinct t}?cS

of actir,ities: erternal design,
and detailed design are
architectural design. and detaiie<i design. ArchiteotLrrai
eoliectiveiy referred to as intemal design'
pla.nrlirtg out, anci spccifying
External design of software involves couceivitlc.
the externally obsenable characteristics of a
software lrt"ocir'tci'

pillrs''' arlcl conlinrte'r rnto thc desip'rr

Exterlral desigri begins during the analysis
phase.

rtilci specitf i lg tile intcrnll

Intenral design int,olves conceiving, plannillg oLtt'
produet
structure and processing detaiis of tlie softu'are
:,
FUNDAMENTAL DESIGN CONCEPTS ' -'r-'.\.(:
-
vl-t . ! :1, €
:i I

concepts and
Every intellectual discipline is characteized by flrndamental
as they apply
specific techniques. Techniques are the manifestations of the concepts
to particular situations. Techniques come and go with changes in technology'
intellectual fads, economic conditions, and social concel'lls.

Page 3L of 76

i'iix{

L}
 7zu
5u.
abstractiou, stt'ucture, informati.rr
Fundarnental concepts of software design include
and d esi gn aesthetics'
hiding, modularity, concurellcy, verifi cation'

Abstraction
us to deal with concepts apart
Absffaction is the intellectual tool that allolvs
definition and
from particular instances of those concepts. During requiiements
aspects of a system from the
design, abstraction perrnits separation of the conceptual
(yet to be specified) implementation details'

Three widely used abstraction mechanisms in softrvare design

are functional
rnechanisms allow us to
abstraction, data abstraction, and control abstraction. These
from the
control the cornplexity of the design process by systernatically proceeding
abstract to the concrete.

Functio,al abstraction involves the use of parameteriz,ed subprograrns' The ability

to paramet eize a subprograrn and to bind different parameter valucs on different
invocatiols of the subprogram is a powerful abstractiott tlrechanism'

Data abstraction involves specifying a <1ata type or I riata r-'b-iect lit' s.rccilyilrg leglrl
dclajis a.re suppr essed'
operations on objects; representation and manipulatioir
u'ithot'tt sta ing the exact
Control abstraction is used to state a desired cft'cct
mechanism of control'

Information }liding

informationhidingisafundamentaldesignCC)llCeplibrsoftware'
infonnation hitling approacl-r,
when a software system is designed using the
<.
and
each module in the system hides the
iniemal detaits of its processing activities
'--. modulescommunicateorrlythroughwell-deflrredintel.taces.
dcsrgr clecisious' olher candidates
trn adrlition to hiding of difficult and changeable
for infonnation hiding inciude:
cletails of thcr
L A data structure. its internal linkage. and thc inrplenrentation
proceduresthatnranipulateit(thisisttreprinorpli:tli.clalaabstractitlnl
2"TheformatofcontrolblockssuchasthoscforLlL],jl]fritlilt.,ll,.I.irtlttgsyslent
(a "control-block" module)
antl t'thet itrplcillt'llt Ltion dotails
3. character codes, ordering of character sets,
dctails'
4, Shifting, masking. and other machine dependeni

Page 32 of 76

\ /'1.''
 g3
Structure
r:ornputer software' The use 01'
Structure is a fundamental characteristic of
irrto srnaller' 111('lre mutageabir:
structuring permits decomposition of alarge systetn
irr the system'
units with well-defined relationships to the other units

The rnost general form of system structure is the network A

computirrg
and arcs' The
network can be represented as a directed graph, consisting of nodes
nodes catl represent processing elements that transform data and
the a'"cs can be used
to represen data links between nodes. Altematively, the nodes can represent data
t
stores and the arcs data transformation.

Diagram -page 143

Modulari "v
r'vi'ilr rviril-deline<[
Modular systems consist of rvell-defined, manatluahici uilits
nrocirtlar system irt';lude:
interfaces among the units. Desirable properties of a
that is potentially
1" Each processing abstraction is a well-defineti sr'rbsystem

in other aPPlications'
usefutr
u,ell defined pul.pose.
2, Each functiorr in each atrstraction has a single,
3,Eachfunctionmanipulatesnomorethanonel]la.loldatastructur.:,
routines ihat
4. Functions share globai data selectively' it is easy to iclcntify aJl
share a rnajor data structure"
5. Functions that rnanipulate iustances of abstract clata tlpes al(r
encapsulated

with the data structure being manipulated'

Moculanty enhances design clarity, $'hich in tltrit eases itlrplementatiotl'

of tlic sojltt'ttt'e product'
debugging, testing" clocuurentii-tg ancl rnaintenance

Concurrencl'

Softrvare sysrems can be categorized as seqLrential

or concllnent ln il
sequential systent. onl1, tine pol'tion of the systcnl
:' lctivc 11 an gi vert tilnc"'
carr bc activated srmultaneouSlY
Concurrent systems have inciependent processes that
plocess(rs can
if multiple processors are available. On a single procc\sol'' r:ottCuLrellt
of tirne-;hared' multi-
be interleaved in execution tinle. This penl-)its implenli'rlltatloll
programmed, and real-time systen-)s"

Page 33 of 76

,I

,i;r
 7+
Verification
design' I)esil;n is the bridg<:
Verification is a fundamentatr concept in solirvarr:
between customer requirements and an irnplertrenlatiot"t
that sittisfies thoser
c]ctllonstraled that the design will
requirements. A design is ver-ifiable if it can be
requiretnents' This is
result in an irnplemlntation that satisfies the ctrstomer's
typicaltry dcne in two steps: (l) verification that the soliivale
requilerllents dcfinition
and (2) verification
satisfies the customer's needs (verification of the rcrll,,lr"effIents);
that the design satisfics the requiremeuts definition (r'erilication of
the lesigTr)

Aesthetics

Aesthetic considerations are fundamental to desigu, whelher in ar1 o1

technology. Simplicity, elegance, and clarity of pr"rrpos.e distinguirh products o1'

outstanding quality.

MODULES AND MODULARIZATION CRITERIA

Architectural desigl has the goal of prociucing rvell-structLtred, modular

software systems.

Software module to trc a named entity having the foliorving

clturaclertstrcs'

structut es'
1. Moduies contain instructions, processing logrc. atlr] chta
rr liblary.
2. Modules can be separately compiled and storetl in
3" Modules catl be included in a program'
ancl sotne paratrteters'
4. Module segments can be used by invoking a nilrrrtr
5" Moilules can use other modules"

Coupling and Cohesion

the sofh'r'are product sc'
A fundamental goal of software design is to sir-ucturc
bohveetr ltloclules is nrinimized'
that the nurnber and complexity of intercomectious
inyolr'cs t hc concepts pf
An appeaiing set of heuristics for achieving this goal
coupling and cohesiotl.
of strougest (least desirabic)
Coupling between nlodules can be ranked on a scrlc
to rveakest (most desirable) as folio*'s;

€. i " Content couPlirrg

2" Common couPling
3. Control couPling
4" Stamp couPling
5, Data couPling

Page 34 cf 76
 36
Contcnt coupling
values or
conteni coupling occurs rvhen one nrodulc rnodifies locai data
instructions in auother module, Content coupling can occur in assenrbiy
languagc

programs.

Common coupling
\:. Common coupling rnodules are bound together b1' global data structures.

Conirol cclupling

\& Control coupling invoives passing control flrgs (as paramet')rs or giobais)
betrveen modules so that one module controls the :tccluencc of proc':ssitig steps in
another moclule.

Stamp coupling

Stamp coupling is similar to common coupling excepl that gLrbal data itents
are shared selectively among routines that require tlie clata.
\
Data coupling
items bctweelt
Data coupling involves tlte use of parameter lrsts io pass ciata
routines. The most desirable fonn of couplrrrU bctr'i'e etl ntociules ls a

combination and data couPling'

Cohesion

The internal cohesion of a module is measured itt

ti:n s <-rf the strerigth of binding
occufs on the scele of rveal<est
of elements within the module. cohesion of elementil
foll'r',t'itrC, orclcr:
(least desirable) to strongest (most desirable) in thc

1. Coincidental cohesion
2. Logical cohesion
3. TemPoral cohesiorl
4. Clommunication cohesion
5. Sequential cohesion
6. Functional cohesion
l. Infomrational cohesioll
Coincidental cohesion
have no
coinciclental cohesion occurs when the elentcrtts rvithin a t1lcrdule
appareltt relationship to one another'

Pa6e 35 of 76
--
tt
3h
Logical cohesion

Logicalcohesionimpliessomerelationshiparrongthe
elements of the

rnodule;

Temporal cohesion

Ternporal cohesion exhibit many of the same disadvantages as

}ogically bound
modules.

A typicatr example of temporal cohesion is a n-rodule that per[onns program

rnitialization.

Communication cohesion

t$.'
Cornrnunicatiopal cohesion refer to the same set t.if input and/or output data.

Sequential cohcsion

Sequeltial cohesiou of elentents occurs u,hetr tItc oulPut of otre eicnicttt

is t]re
input for the next eiement.

Functional cohesioll

Functionai cohesion is a strong- and hence clesirable, type

ol binding of
to li"ie perfonna:tcc of u singl<:
elements in a rnodule because ali elements are relateil
,\, are 'Cotlrpute square Root"'
functton. Examples of functionally bound module:
File"'
"Obtain RandomNumber," and "Write Record to OutpLrt

Informationan cohesion

Infonnationai cohesion of eiements in a module Occurs r'l'he rt the r.nodule

routiues to lriauipulate tl-ie datastructure'
contains a complex data structure and several

DESIGN NOTATIONS

htsofirvaredesign,asitltnathematics,therept't':rclltatiollschcnlesuse<larcol'
: fundamental in-iportance. Good notation oall
clarili the interrela'ionshills itn<l
cotttl"llJ'llc aIILi it'itcl-i:re w'tth gtrotl
interactions of interest" r'r'ltiie poor notatlon Call
specilicafr.lls cxis't: e'tcrttal desigrl
design practice. At least threc 1e'e1s of clesign
oi' a sotrit'et-c svstctrll
specifications, rvhicfu descnbe the extemal characteristics
architectural ciesign specifications, rvhicil desci-ibe
thc structl-tre ol tit'; systertl: untl
design specificatrons, which describe control
ilorv. clata repfcictltation' attcl
detailed
other algorithmic details rvithin the modules'

Page 36 of 76

'i'
ta ta&
fl, q
.v
3T
Data FIon'Diagrams

Data floo,v diagrams ("bubble charts") are dirt:i:Icrcl gr"aphs in';,'hich the nodr;sl
specify processing activities ancl ttrre arcs specify ri:ilr itetns tlansrrritted between
processing nodes.

Data florv cliagrams can be expressed using inlbrrrral trotation, rs illustrated in

the following Figule, or special symbols can be useci tcr denote processing nodes, data
soutrces, data sinks. and data stores.

'i'3^-,- '-(, i-L- J

StructureCharts'fL.4,:.vt{''' I q tjt
Structure charts are used ciuring architecturai cicsigr-r to
ciocltuerlt hierarchicatr
srructure chatt diffels fronr
structure, paratneters, atrd itrtercontlections in a systenl '\
arlcl tlte seqtrential
a flor.vchart in tu,o \r,,ays: a stluctLlle chart has nO clecitrolr Ltoxcs.
chart'
ordering of tasks irilrerent in a flowchart cau bc suppt'crr:,cd itt a strttctut'e

Page37 of76

r. -i.r'.Ijrer'*4r4.
| '4t
 9v

HIPO Diagrams

FiIPO diagrarns (I{ierarchy-Process-lnput-Or-rLprrt) rvere devr,:lc ped at IBM its

design representation schemes for top-down softrvllc develollnlent, rlnd as extcrnlti
documentation aids for released products.

A of IIIPO diagrarns contains a visual tablc of contents, a ret of overvietv

set
diagrams, and a set of detail diagraius. f'he visual tablc of contents it; a directory to
the set <lf diagrams in the package; it consists of a trec-structurcd (or gaph structured)
directory, e summary of the contents of each 61'g1'1,ig1v diagram, arrci a legend of
symbcrl definitions' e,,.t,.y r-,1,.", r r;' 6
't-_

Frarnlai n

\ nt rlt=ury

hnfrot

i--ffi
i t'nqrt6 t

Procedure TemPlates

The format of a procedure interface specificatii,ri is illuslr"atecl ir Irigurc'-5.10.

In the early stages of'architectural riesign. only the Irrlirl-tllaltion in 1e''el i tleerl b'.:
supplied. As design progresses, ihe infonriation on levci,, l.-i, and 4 cati '-rc inclrrded irr
successive steps.

Page 38 of 76

, J' ,ftif
-v-

b1
it is recommelcled that only the information on level 1 follor'ving example be:
provided during initial architectural design, because cietailed specilication of
side:

data representations
effects, exception handling, processing algorithms, and conr:rete
will sidetrack the designer into inappropriate levels of detail too sootr'
,Y
PROCEDURE NAME:

PART OF: (subsystem name & nurnber)

CAI-LED BY: LE\/EL, 1

PURPOSE:

DESIGNER/DATE(s):

PARAMETERS: (Names. ntodes, attributes, purposes)

INPUT ASSERTION: (preconditions) LEYEL 2

OUTPUT AS SERTION : (postconditions)

GLOBALS: (names, modes, attnbutes, pulpose, shared u'ith)

i.

SIDE EFFEC fS:

LoCAL DATA STRUCTURES: (nanres, attributes, pLrt.lloses)

EXCEPTIONS : (conditions' responses)

LE\ EL 3

TIMING CONSTRAINTS:

OTFIER LIMITATIONS:
I-E\ EL 4
PRCCEDUREBoDY:(Pseudocode,sttuctureciEnglis}r.
structured florvchafi, decision table)

Pseudocode

Pseudocodenotatiotlcanbeusedirlbothtlrearcllitccturalanddetaileddesigrt
ciesil'ecl leyel ':f abstraction'
phases. Like flor,vchafts, pseuclocode can be used at any
r-rsing :ihot1' conciSc'
Using pseudococie, the designer describes system cha|acteristics
il-'ihen-Els(j'
English language phrases that are structured by kt:1' rvot"cls suchas
While-Do. and Enci.

Pseudocode can replace florvchafts and redrtce the amoltnt of external

documentation recluired to describe a system.

Structured Flowcharts
?age 39 of 76

lt
--.'
fio
l-lowchart

Flowcharts are the traditional means for specif}'ing an<{ documenting

algorithmic details in a software system. Flowcharts inr;orporate rectangular boxes tbr
actions, diarnond shaped boxes for decisions, directed al'cs for specifying
interconnections between boxes, and a variety of specially shaped symbols to denote
input, output, data stores, etc.

Structured flowcharts

Structured flowcharts differ from traditional flowcharts in that structured

flowcharts are restricted to compositions of cefiain basic fouls. lhis makes the
resulting flowchart the graphical equivalent of a structured pseudocode description. A
tlpical set ofbasic forms and the pseudocode equivali-'nts are illustrater+ in lrigure.
n, t .y'- tl,
t,n
I cU *rv,,c ' g>

Qry

STRUCTUITED ENGLISH

structured English can be used to provide a steir-1,'-t'"slep spccilrcation

lor an
aXgorithnr. Like pseudococle, structured English can b'r
uscii iit atty ci':sired level c'f
detail. Structurecl Engiish is often used to specify cool:1'ook ..ue ipcs'

1. Preireat oven to 350 degrees F"

2. Mix eggs, milk, and vanilla.
3. Add flour and baking soda.
4. Pottr into a greased bakitrg dislt.
5. Cook until done.

Page 4A of 76
 t-'' 4(
Decision Tables

Decision tables can be used to specify compler. decisiou

logic in a high-level
software specification.

They are also-aseful for specifying algorithmic logic riuring rletailed design,
At this level of usage, decision tables can be specified and translated into source codo
logic.

DESIGN TECHNIQUES

The design process involves developing a conceptual view of the system.

establis|i1g systcm structure, identifying data streartts aud data stores, decomposirtg
high-level functions into subiunctions, establishing relrLtionships and itLtercotrnections
atnong components, dei:eloping concrcte data t'r'Jlresentatiolls, and specifyilrg
v
algorithmic details.
"t()ll-.lown" allr-l,,rr'obott{rtr-u1)"
Design techniques are t.lpically basccl on the
design strategies.

A prerlontinately top-dou,n strategy is nrost sLtcc,esslul rvhett a well-defined

envirorunetrt exists for sott*'are cievelopment'

. Steplvise Refinement
i9'
Steprwise refilement is a top-dor.vn tecirnique lirr rlecompositlg a system front
is als<r
high-lei,el specifications into more ciementary lel'els. Steprl'ise refittement
''successir,'e refinement'''
knorvn as "stepwise proglalll develOpnient" and

stepwise refinernent involves the follolving activities:

l.Decomposingdesigndecisionstoe]enrentar.o-1cl,c1s,
2. Isolating design aspects that are not truly inter(ltrDell(lcnt.
3" postponing decisiols concenring representatioll rletails as long as possible'
4. Carefully demonstrating tliat each successive tiielr irl iilc t'efiitertent process is

a faithfiul expansiotr of prevtous steps'

with the specificatior,' iielivcrl riut'iil1l rcilllllclllcllt:i

Steprr.,ise refinemeirt begiirs
analysis and extemai design.'i'he problem is fl|st rlcconrllosed irlLtl
a 1'cri tlritjt't'
processir1g steps that r.viii den-ronstrabiy solve the prcrbi. rll.

Tire major benefits of steprvise refinement as a design t.'chniquc ltre:

l. Top-dorvn decoitrP'--'sltlon
2. Incremental addition of detail
3. Postponement of detail clecisions
v 1. Colijnual verifi cation of consistency (fon.t-ral1,r' r,t' ittfonrlally)

Page 41 of 76

-h,$
fr,
 qe)
Levels of Abstraction

I-evels of abstraction rvas originally describcd bv Dijkstra lrs

a bottom-up
design teclurique in which arl operating system ''r'as clesigreci
as a la1'cring 6l
hierarcliical ievels startiDg at level 0 (processor allocatioir. r'eal-tiit-tc clock
intemrpts')

and building up to thc level of processing independettt user i)rograins'

Each level of abstraction performs a set of sct-r,iccs lor the frrnctions on the:

next higher level of abstractiott.

Each level of abstraction has exclusive use of ceitain resourccs (l/O deviccs.
data strucrures) that other levels are not permitted to access'

Structurcd Design

Structurecl design rvas developed by Constantjne as a top-dou'rt technique for

architectural design of softrvare systems (STE74). Tlie basic approach in structured
design is systematic conversion of data florv diagrams into structurc'chrrns.

The first step in structured design is revielr" and rettnetlcilt ol'lirc data llorv
diagfam(s) developecl during requirements deflnition and exLerrlal desi11rt. Tile sccond
step is to determine whetlier the system is transfonll-L:cllt(jro(l ol trall;action-drivett,
;ll a tritrlsfbnrt-
anri to derive a high-level structure cirarl based on this rlctenntnatiorl.
ceniered system. the <jata florv diagram contains trrrput, Plocessitll;,
attd output
rirree l11alor" subsystems in il
subsysterns in the structule chart. Boundaries bctwectl the
transform-centered sysrem are icientified by <leternrirlitrg tiler
pottti cl ;:tost abstraet
dala {:161v diiLgtatn'
input data and the point of lnost abstract output data on tirc
subsystem using
The third step in structured design is ,Jecourpositrol cf each
gUidelines such as couplirlg, cohesiott, infonlation hlcling, Iel"eis
of aL'stractiott' datzt
abstraction.

Pace 42 of VB

ll "',
, "'r,.,i'
 DETz\ILED DESIGN CONSIDIIRATIONS

Detailed {esign is concerned with specifying aJgorithmic detail;;, concrete data

i$ns, interconnections among functions and data sttuctures, and packaging
of the softrv product. Detailed design is strongly in.f]uenced by tire implementation
language, bu it is not the same as irnplernentation; detailed desigr is rrore concerned
with semantic and less concerned with syntactic details than is irttplemcntation,

design separates the ictivity o1' low-level design fiorn

impiementation, ust as the analysis and desigr activitics isoiate consid::ration of what
is desired from structure that will achieve tlie desirccl result.

ISTRIBUTED SYSTEM DESI GJ!

Many of Iar design "methodologies" were developed as design

techniques for app programs, operating systems, and utility programs.

These meth support concepts suchas hierarchical rlecomposition,

modularity, information iding, and data abstractiott. These design concepts are
important for real-time a: istributed systerns.

Iv{ajor issues to be ressed in designinir a distribr.rted s'vstem inciuder

specifying the topology of communication nc,'ttt'ork, establishing ruies fcil"
aocessing tire shared commu tiou channel, aljoi:ating altplrcati,rn pt'ocesslng
functions to processing nodes i the netrvork, and i:stabiisliing nt1r,s for process
communication and synchronizati

Real-tirne systems must Prov specified ain()Lutls of' coltlp itlttion rl'ilhitt
fixed time intervals. Real-time systems ically sen:r(-' an.i ctttttrol e.xrenlal devices.
respond to extemal events, and share ing time ir(rttt'een ntr"rlti1;1e iasks.

A real-time neirvork for process co ay c0nsrsi 0l severa] L'litlicottlputers

aud microcomputers connected to one or more la pro cres-SOi-S.

Froeess controi systellls otten utilize conl networks having iixed

static topologS' and ktlotvn capacitl requiretnents'

Several notatrons have been developed to suppo anal1,'sis arrd r{esign o1'real-

tirle and distributed systems. Tirey inciude l{SL, SDLP' \PN, corlrmrrni ;ation porls.

./2{EST PL.ANS
The rest plan soecifies the objectives ofl testrit.r (c.g.^ to acirt,:vo crror-iiec
operatioll under stated conditions fbr a stated periocJ L,l'trttle). the teit colllillctioll
criteria (to achieve a specifieci rate of effor exposurc, tr) ,tclticvc ii sltcciired percent o['
iogical patii coverage), the systenl integration plan (sLr:rlegy', schedLrl,:. r'esponsilllt:
individuals). methods to be used on parlicular modulr::; (ririkth:'ouglis. rnsnectiotts,

Page 43 of 76

U . +ltlt:rl||r*ril* !'
 Lh,
{.)
static analysis, dylauric tests, fonnai rierification), and the particular test cases to bc
used.

There are four tlpes of tests that a sotiwarc product must sattsfy: functional
tests, perfonnance tests, stress tests, and structural te sts. Functirlnal tests and
performance tests are based on the requirements specitications; lhey irre designed to
demonstrate that the system satisfies its requilemetrts. Therefore, the test plan can be
oniy as good as the requirements, which in turn ntust bc piliased in quarrtified, testable
terrns.

Functionai test cases specify, tlpical operaiing corrdltions. typicitl inpul

vaiues, and tlpical expected resuits.

Performancc test should be designed to veril'', r'es!)ol'ISCr tinre (trnder vat-ious

loads), execution time, throughput, primary atrd sec'.orrriar,v lltclno1'v' rr{ilization, and
traffic rates on data channels and comtrtunication links;

Strcss tests are desigted to overioad a sl ste m in various lvays, such as

attempting to sigl on more than the maxirnutn ltllou'ed number of temrinals,
pi.ocessing more than the allowed number of idcntifiers or static lel'els, otr
disconnecting a communication link.

Structural tests are concerned rvith exarnining the itrternal processing logic of
a software system.

}IILESTONES,WALKTHROUGHS,ANDINSPECI'IONS
Desiglr
T'ire two rnajor milestones <luring software des;qti are the Pr"elilrrinary
PDR is t1'pi;aily held near'
Review (PDR) and the Critical Design Review (CDR)' i'he
occur'; at the enrl ol'
the end of architectural design and prior to detailecl dcsign' CDR'
detaiied design and prior to implementation'

The major goal of a PDR is to demollstratc lhat tite externa'l)'

observable

cliaracteristics and architectural siructure of the prc.,iiur:t

ri'ili satisfy tl.tc cuslomcr's
exter'ia1 iutct'faces,
requirements. Functional characteristics. pelfontranec -rttt'iilulcs.
user dialogUes, report fonnats, exception cotrditions {rirrl exce.llliorr
iian'lling' product
during the
subsets, and future enhancements to the prodrtct siiolrld all be revifl1cd
PDR.

The CDR is held at the end of detailed desrgn anC piior to irl'rplementatiott.
Among other things, CDR provides a final lnallagenlortt clecislon point to build
or
cancel the system.

Page 44 of 7o
 Ltl
l-.
WAII(THROUGHS AND INSPECTIONS

A structurcd waikthrough is an in-depth, tccht:tcal ,'ci'ietv of some aspect of a

software system. Walkthroughs can be usccl at att;i' l"irne. cluring any phase of a

software project.

A walktlyough tearn consists of four to six people" The person whose material
is being reviewed is responsible for providing copies of the revit:w materiai to
mernbers of the walkthrough team in advance of thc u'alktluough session, and team
mernbers are responsible for revierving the material prior to the session. During the
walktlu'ough the reviewee "walks through" the material ivhile the revrervers look f,or
errors, request clarifications, and expiore problern at"c;is iu tire material under review.

The focus of a rvalkthrough is on detection .-rf erl'ors and uor on con'ective

actions. A designated secretary for the session records action items to be pursueil try
the reviewee foliowing tlie review session.

The reviewee is responsible for foilow-up and lbr inlbnrtiltg tl,c reviewers ,.rf
corrective actions taken. More detailed informatir,n cotrceruing tt e fonlrat anrl
conduct of walkthrough session is provided in Chapter' 8"

Design inspections are conCucted by teams o1'trained inspeclors who u"ork

from checklists of itertts to examinc.

DESIGN GUIDELINES

Design is a creative process that can be guided and dit'ectec1, but it

can never be

reduoed to an aigorithmic procedure. The desigrl o1'a real-time system

is a much
different activity than the design of a data processing application' fhe
following
guideliiies clo not constitute a "'design methodolorr"'. but ratfier provide some
guidance for organizing the activities of softrvare desigil'

1' Rel'iew the requirements specification' Itl

Jr:tntculal"' stud" the desired
functional characteristics anrl perfomance attt.ihrrtos of the systci]l
i"cporl 1<lt'tttats
2. Revierv and expand the extetnal interfaces, Llscl cllllogues, anci
developed cluring requiretretlts analysis'
3" Re'ieu,and refine the cjata flow diagrams d,.",'eloped cluri'rl requiremcnls
apalysis and extemai design. Identify intemal rlrila sto;'os; and claborate
I the

firoccsstttg futtclt otl,,

4. ideltify functionai abstractions and data abstrltotiotts. llectrld Lht'rn ttsiltg a

design notation,
5" Define the visible interfaces for each functio:tal abstractton :rnd each data
abstraction. Record thern using a desigr notation'
6. Define the nrodularization criteria to be used in establtsliirTg systt:m structure.
7" Apply the techniques of 1,'our particular desigrt ntethod to establish systenl
stmcrure. For example, derive the input and output clrta stt'uctt-trt;s and convert
Page 45 of 75

a
 the data structures into a processing stmcture, as in Jacksotr Structurecl
Frogramming; or convert the data flow diasrarns lnto strrcl.ure charts,:ts tn
strucfured design; or derive a system strucliirr: thaa rna,ximi;,es inftrnnaticrn
hiding- or a suucture that enhances the o"crla)'capabiirtit:s or real-tin:er
response rate, etc.
.\ 8. Iterate steps 4 tllough 7, and. as rlecessary, steps 1 tlrrou.qh 7 untii a suitable
structure is achieved.
9. Verify that the resulting system structure satisfies thr: requireme nts.
i 0. Develop interface specifications for the procedLrres in each mod ule.
I L Conduct the Preliminary Design Revierv. 'l'he level of detail should be
inclusive to levels 1 and 2 of the procedure ternplates in Figure :i" 10"
12. Develop concrete data representations fbr the clata storcs and dara abstlactions.
13. Expand the procedure templates of Figure -5.10 to ilrclude the infoirnation in
trevel -?.

14. Specify aigorithmic detaiis for the body of each plocedure in tlrr:systern, using
successive refinement, HIPO diagranrs, psoLrdocode, strucrured English,
and/or strucrured l'lorvcharts" Develop concr'ole datn rcprelentations anrl
interconnections between data structures and als,.,rtthuts.
i5. Conduct the Cr-itical Design Revieu' 't '-'{r'
,( ''"
)6. Rcdesigrt irs lleccssar)' U f-..f
SOFTWARE IMPLEMENTATION

The implernentation phase o1 5sftrvare do'eloptnert is cr,rtcerned with

transiating desiEr specifications into source corle. The prinr ary goal of
implementation is to wnte source code and internai docutnetttittion so that
conformance of the code to its specifications can bc easily verifierl. and so that
debugging, testing, and n-iodification are eased.

Source-code clarity is enhance<i by structureci coding techrriques, by good

coding style. by appropriate supportitlg docuurents, b1' gooci itltertlal comntents, and
by the features provided in modem prograntrning languages

Proeiuctiol of high-quaiity softrvare requires tltitt lltc progral.llll.lltlg teatu hiil'e

a desigpated leader, a w'ell-de'fined organizationll stl"tlctul'c, ;itlcl a lhororrglr
undelstanciing of tite duties and resportsibilities of eacl, i..rrr1 11lelllber.

The irnplementation teail should be providcir ri'itli a u,ell-c'cfined set of

solirvare requircments, an architectural design specilrerlrott. artd I c1':tailed clesrgrt
description" Also, each learr nrembet' ntust uitiicrsi:ttlt1 thc oblectlvcs ol
iinplementation.

Weinberg gave five progralnmers five diff'ereur rittplementatiol goals flor lhc
same program: rninimize the n-ietnory required, nraxintize oLltput readabiiity,

Page 46 of 76
 4*
maxirnize source test readability, rninimize tbe number of source $tatements, and
nrinimize development time

STRUCTUR.ED CODING TECHNIQUES

The goal of structured coding is to liberalize contr"ol flow throrrgh a c<lmpulei

program so that the execution sequence follows the sequence in whrch the code is
written.

This elhances readability of code, which eases understaudiltg, debugging,

testing, documentation, and modification of programs, It also facilitates formal
verification of programs. Linear flow of control can be achieved by relrtricting the sct
of allowed program constructs to single entry, single exit fonnats; ltowe'ver, sirict
adherence to nested, single emtty, single exit constructs leads to questions concerning
efficiency, questions about "reasonable" violations of single entry, stngle exit, and
questions about the proper role of the goto statetnent in stmctured cocling.

Siugle Entry, Single Exit Constructs

Every algorithm (every Turing machine prograrn) can be written using

sequencing, selection, and iteration"

Any single entry, single exit program segment lirat has all statelnents on some
pat6 fronr the entry to the exit can be spcr:rfied usirrg onllz sequencing,
selection, and iteration.

A sufficient set of single entry, single exit constntcts lbr specrlying cotrtrol flou' itt
algorithms is

Sequencing; S1;52;53;
Selection: if B then S1 else 52;
Iteration: while B do S;

='

Page47 of76

r',4
il 'r^
 rasult in a mamcr that violates ,rfff" *"'y, singl"' cxit ani yer t:iai;tt"rined localitl
and lincarity of control florv'

The goto statenlent also can be used to stntuiate single entry, single exrl
constructs in primitive prograrmling languages'

EX:

If B then S1 else 52; lF(.NOl.(B)) GO TO I0

S1
r!^ 4^
{.rU
^^ i \, lU
10 s2
20 CONTINUE
Rccursion

A recursive subprogram is one that calls itscli" cithei-clirectil or irttlirectly;

recursion is a porverful and elegant programming techrlrcltte.

The goais of clarity and efficiency are thus served by appr,)priate usc ol
recursion.

Recursive algorithrns arise narurally in cottjunctitltl ivith tec:ursil'e data

structures (e.g., linked lists trees).

For example, an algonthm ior in-order trerversa.l tlf binarY trees can be
expressed recursivel Y.

CODING STYLE

style is the consistent pattem of choices maci'-: alncn! altr:tn'ltiyc r'vays o1"
achieving a desireel effect.
by';l
In cornputer proglall-)mrng. coding style is lllllli'lcsl ir' tllc piliICl-rls usetl
programixertoexpressadesiredactionoroutcome.Pr.,gl.lilttt-tleI.:]i.',,hcltt,tlrkttlgetlrer
soon come to recognize the coding styles of their coller,l'res.

The gui<lelilles are examittecl in the follorving cliscussiot'

. Use a ferv statlclard contt-ol constructs

. Use gotos in a disciplined tnanner

" Introduce user-defineci data t)?es to nroclel entities in the probieni

domatit
o Hide data structures behind access fur,ctiotts" lsolate rnachinc
dependencies in a f"erv routitres
. Provide standarcj docur-nentation proiogttcs lirr eillh sublltograln and/or
compilation urut
. Carefull5, examine routines harring f-ct, 91' than Ir or trlore than 2-5

sl atr-lll cllIS
t'1age 49 of 7 6

,t t'
 Effi ciency Considerations

A recurring criticism of strict adherence to single el1try, single exit constructs

is that they result in inefficient use of memory space attd execution time. The need for
auxiliary variables, repeated segments of code, and excessive subprogram calls are
often cited.

The following example illustrates the need for auxiliary variabies in a search
loop on a linked list:

'\'o.y ,,o.,, i lQ

Violations of Single Entry, Single Exit

The goal of structured coding is to improve t.ite clarity' and rr:adahility o1'
source programs. clarity is greatly enhanced by usr: of sirrgle entry.
single cxit
constructs. There are, holvever, commoniy Occurdllg situatiOtls 'l
hiCh warrant
with thc
violation of strict adherence to single entry, single exit 'rrtd yet are colls'Stent
goal of improved clarity. Three commonly occurriltg sitLrations are rnultiple
loolr

ts, .,l9l ll?lgl1s, an d Sif lt:yla t i-ori

!{l
.
i
_ex

Data Encapsulation

Data encapsulation involves packaging 6f 6 rllta stt-t-icture arrd its access

routines in a single module. The data structure is nlarlipulated onl)'
l;y the access
routines, and other routines use the data structure b1' callrng the appropriate access
routine. A data structure is thus defined by the operations that can be perlormed
ott tt'

The Goto Statement

The goto statement pro,u,irJes unconditional trar,sl,:i'ol'control at,d thus aliou's

violation of the single entry. single exit cor-idition ol :li-Lrc'turccl coilirlg Wc hltvt:
presentecl several c.xamples w'here goto statements rii'rc Ltseci to aoili ;l,c a tlesire<i
Page 48 of 76

',-lr^',,:
F
 Use indentatioir, parentlreses, blank 5i);]C(jS,
blarrk lirlr:s, ancl bordcrsl
rerarllbtiil;r
around blocks of comments to enhance
a Don't be too clever
a Avoid null then statements
a Avoid then. . . if statements
o Don't nest too deePlY
a Avoid obscul'e sicie effbcts
ii Don't suboPtinrize
carefuliy examine routines having urot'e than fir'e folnaI
a
parameters

a Don't uso atl identifier for multiple pui'lloscs

STANDARDS AND GUIDELINES

Codilg stancllrcls are specifications for a pr,:t'el'rr:d coding r;tyle. Given a

ciroice of ways to acltieve an eftbct. a prefbrred rvay is

:'pccified' Codin't standards are
often viewed by prograrnnlers as mechanisms tt' colistrilill :nd devalue ttre
programmer' s creati \/e probiem so I \'ing ski i ls'

It is ciesirable tlrat all progranlmels on a sofit,rare llt.ojr:c.i adopt sirrriler co<ling

styies so that code of unifbnrr quality is prociuceci'

A prograrnlning star-idarcl nlight specify items

such as

i. Goto statements rr'iil not Lre used'

2.TlrenestingdepthofprogianrconstruCtsrvii]tlolexceeclfiveis:r'els.
3. Subroutine leirgth will not exceed 30 lines'

Aguidelinerephrasesthesespecificationsinthe|ollori,ingmal1ne1.:
avcided itt trortnai circutustances'
i, The use o1'goto statements should be
2.Thenestingcleptirofprogranrconstruotssho;ricibefir,eorlcssinnonnal
circltmstances.
in a sttblrt''rgt31 5]13ir1d nct erceed 30
in
3. The nunti;er of exer:urable statements
nonnal clrcull)stan ces'
requit'cs i l.lll.o\/al lri'lho 1l oiect loade:r'
4" Departure ftotn tlotrllal circutl-istatlces

D OCUN'IENTATION GUID E t,INiIS

C0tir: iir"e S}/Stcll] and all thc
Cotnputer softi,r,are irrclucles thc Source
analysis, rlesrgn' irnpietiletilatio'r' tcstittg'
and
supporting clocunents gcnerated during
inclr'rdes standard prologUes for
maintenance of tlie system. Inten-ral clocumentation
aspccts of tho sourcc code'
compilation units and subprograms, tlle self docuurctttitlrl
source code'
and tite intemal comments embedded in the

Page 50 of 76
 <7
Supporting Documents

Requirements specifications, design docurnerrls, Lr::;t plans, i,ser''^! rr:epuals

installation instructiotts, and maintenance reports are cxanrp.les of supportilg
docume,ts. These documents are the proclucts that result fi.r,11 svstematrc
development and maintenance of computer softrvare.

A
systenlatic approach to softrvare deveiopmr:nl assures tlrat supporting
documents evolve in an orderly manner, and that tfue docuqre.lts
are "rvarlable whcn
needed.

Supporting documents of substandard qualit)'. that

are not lvailable when
needed, are a strong indication of problems with
the processes being used to develop
and maintain software.

Program [.,nit Notebooirs

A progranr unit is a unit of source code that is ric,u,elopeci

and/or rnaintained by
one personi that person is responsible for the unit. Iri a well-cJesillped
systenr ir
program unit is a sul-rprogram or goup of subprogllnrs
tha: plor,icl.: r.vell-define<l
function or fbnn a well defined subsystenr. A prograrr unrt is also snrz,li
enough, an<l
modular enough, that ir can be thoroughly testecl in i-soiatron i;v the
;)r(,!,r31.11rner rvhri
develops or modifies it. Program unit notebooks are u:recl bv iuciividua,progr.amnler.s
to organize their work activities, and to maintain the tllcul,rcntatroLr for their prograrrl
units.

LINIT NAME: PI{CGITAMMER:

ROUTINES INCLUDED:
SECTION CONTENTS DIIE DATE CCMPLI]TTD DATE REVIEWER/DA'IE
I RQMTS.

2 ARCH. DESIGN

J DETAIL

DESIGN

4 TEST PLAN

5 SOURCE

CODE

6 TEST

RESUI,TS

v CFIANGE

Page Str of 76
 5e .r___-
REQIIESTS I
I

8 NOTES I
I
I

RELEASE APPROVAL: DA'I-Iii:---

\-:,
Internal Documentation

Internal documentation consists of a standard lrrologue for eacn program unit

and compilation unit, the self-documenting aspects of' the source code, and tlre
intemal comments ernbedded in the executable portion of the code.

Table: Typical format of subprogram and cornpilation unit prologue.s

Name of author.
Date of cornpilation:
Function(s) perl'onned :

Algorithms used:
Authorldate/pu{pose of modifi cations :

Parameters and modes;

Input assertion:
Output assenion:
Global variables:
Side effects:
N'lajor data structures:
Calling routines:
Called routines:
Timing constraints:
Exception liandling:
Assumptions;

'\7

\1

Page 52 of 76
 Ltnit IV
Software Testing
Definition - Sofhvare'festing :

. It is the process of Creating, Implementing and Evaluating tests

. Testing measures softrvare quality
. Testing can find faults. When they are rernoved. softrvare qualitv is irnprovecl.
. Testing is executing a progt'am with an indent of linding Enor'/i rult and
Faiiure.
" IEEE Terminology : An examination of the be lravior of the program hy
executing on sample data sets.
. Testing is a process of executin g a program .,i'ith Llie intent of flr rdins an errol' .
o A good test case is one that has a high probabilit-t'o1'tinding an rs vet
undiscovered error"
. Testing is a process of exercising or evaluating a..,r'stem cornporient by
manual or automated means to verify that it satisfics specified rr quirement

Why testing is important?

" This is China Airlines Airbus l\300 crashing due tc a softl',,are bug on April
26,1994, killing 264 innocent lives
. Software bugs can potentially cause monetary and irumatt ioss, history is full
of such examples

. In 1985, Canada's Therac-25 radiation therapl'nachitte n'rallunctioned due to

software bug ancl delivered lethal radiatioti doses to patietrts, 1ea "illg 3 people
dead and critically injuring 3 othels
, In April of 1999, a software bug caused the faiiLrrc oia Sl"2 biilion military
satellite launch, the costliest accidcnt ir-r history
. In rnay of 1996, a softu,are bug caused the bank .rccoLlnLS of 823 custotners o1'
a major U.S. bauk to bc credited rvith 920 millic,ir LjS dollars
. As you see, testing is important bccause softrr rii'c hugs coulrl bc expcnsive
0r eYen dangerous
. As Paul Elrich puts it - "To en'is hun-ian, but to rea111,'iolil thingr '.tp .vou need
a compuier""

What is thc objective of softn'are tcsting?

Softr,vare testing has matty objectives.

. Sofh,rare testing helps to rnake sure that it nrccts all the rcquit'ement it rvas
supposed to meet.
. It w'ill bring out all the errors, if any. u'hile using the solitvare.
)
n Softr,vare testing heips to understand that tiie soiitt'are ihat is bertts tested ls a
complete success
" Softrvare tesring helps ro give a qrialitv cefiiflcli:on that the sol'tu,are can bc
usecl by the ciient imnrcchately.
. It ensures quality of the product.

Page 53 of 76

lfi" 5'o'' ':':'

1,,
 A Straterric aprrroach to soffivare testing
fr
effectivo
Many software elrots are eliminated before testing begins by oonducting
technical reviews
Testing begins at the component level and works outward toward the integration
of the entire computer-based system.
a Different testing techniques are appropriate at different points in tin re'
a The developer of the software conducts testing and may be assisted by
independont test groups for large projects.
o Testing and debugging are different activities.
a Debugging must be accommodated in any testing strategy.

Veri{Ication and Validation

Make a distinction betrveen verification (are rve brrrtdirrg tire pt"odr:c, riglrt'/) and
"
validation (are we building the right product?)
. Sotlware testing is only one element of Softu'are Qrralit-1' /\ssttrance (SQA)
. Quality must be built in to the development procer;:r^ ),ou catl't use tr:sting
to add
quality after the fact

Organizing for Soffivare Testing

ffi . The role of the Independent Test Group (ITG) is to t'etno"'e the conflict of interest
ffi inherent rvhen the builder is testing his or her own lrroduct
H
H
. Misconceptions regarding the use of independent testitlg teams
ffi c The developer should do no testing at all
o Softrvare is tossed "over the rvall" to people to tcst lt rnercilessly
ffi o Testers are not involved u,ith the project until it is titne ibr it to L'e tested
ffi plcrject to
s " The deveioper and ITGC must rvork togethel tluoughout the sofiware
fr
fl ensure that thorough tests rvill be conducted
il
fi
H
tr
S oftrvare Testing Strategl'

T5,pcs of festing

Black Box Testing

White tsox Testing
Grey Box Testing

Black Box Testing

This testing is tenned as BlackBox Testing since the tester views the progranr
as a black box, that is the tester is completely unconcerned abor.tt the intl:mal behavior
and structure of the program.

Page 54 of 76

ii . !'l.{al:rr-,+trrr'.

r 5'.
 /at:
.) -/
White Box Testing

The tester views the intemal behavior aucl structtrie of ihe progratn' The
proilram'
.. testing strategy pennits one to examine the intemal stlllcturc of the

Grey Box Testing

Combination of Black box & Write box.

Critical or Complex Modules can be tested using White box testing while the
rest of the application is tested using Black Box Testing.

Levels of Testing

, {.Jnit Testing
' Integration Testing
' System Testing Or FURPS".....Testing
. Acceptance Testing
" Regression Testing

Unit Testing

progl arn

coding I afr'er coding is completed"

' Screen comPonents'

' Screen i Frogram.
' Back-end retrated to a Screen"
' Back-end and the Screen'

Integration Tcsting

' Intermediate level of testing

. progressively unit tested software conrponcttis are integratr:d anrl tested
until the sofhvare worl<s as a rvhole
. Test that evaluate the iuteraction and consistettc)' ot' interacting
comPonents

Types of Integration Testing

'/ Big Bang Testing

'/ Bottorn-Up Testing
'/ Top-Down Testing

Page 55 of 76

#.ri?:. : a
 Big Bang Tcsting
{h
. A fype of Integration test in which the softrvar"c coruponcnl of $n
appiication are combined all at oncc into a overall system.
. ,Gordipg to this approach, every module ir tirst unit tested in isolation
from other module. After each module is fested, all of th+ modules are
integrated together at once,,

Bottom-Up Testing

. (i.e.) mo<iules at lowest

Begins construction and testing with atomic trlodules
level in Program structure
. levsl
The terminal module is tested in isolation first then tlie next
set
')f higher
modules aro tested with the previously tested lorver rnodule'

,@1
,ry
@ @@
,q,
@
// \ / \

@ @ @ffi

Page 56 of 76

d
v
 Top-Dorvn Tesring fr
. Progtam merged and tested from the top to the bottom
. Modules are integrated by moving downward through ,1r. .entr,li hierarchy
with the main control rnodule.

-q
flF
@i @@r ffi@

4b 4U
Systern Testing

' Testing condr.rcted on a cornplete, integrated systcur to ev'a.luate the system's

cornpliance with its specified requirements
' In which tlie coniplete softr,vare build is made aircl rested to shou that all
requirements are met.
" Here all possible testings w.r.t
. Functionality, Usability. lrrstallation, l'erfi)nnance,
Security, etc... are expectcd to bc cauiecl .rut.

Activities of The Testing Tearn

./ Functionalify Tcsting.
,/ Usability Testing"

t |;ll::ilflI"i'lt1;,-
./ Scalabilifv Testing.
Functionalitv Testing

fms testing is done to cnsure that all the functionalitres clefineci irr the
requirements are being irnpleinented correctiy.

Usabili$, Testing

The catch plrrase "User Friendliness"' can be acirrcvccJ tlrrough { Isability

Testing.

Page57 of76

,9
 r8
v:
" Ease Of OPerabilitY
"
Communicativencss
,This test is done keeping the kind of end user's r't'ho are
going tc'' use the
product.
Reliability Testing
. These Tests are can'ied out to assess the systcrtt's capability to irandle various
scenarios like failure of a hard drive olt the web, database serve) or
communication link faiiure.
" Software reiiabilit), is defined in statistical tenls as "the probab'lity of failure-
f,ree operation of a computer progrant in a speci l''i ed environ-rn etl t fbr a
specified tinte".
Ferformance Tcsting
\!1
This test is done to ensure that the softwale i pr-oduct rvorks thc rvay it is
supposed to at various ioad (ioad testing ), Stress (strcss tcsting ) and V rlume (
volume testing ).

Volurne Testing

.:.
The pulpose is ro find weakness in the s1'stem respect to its
"vith
handling of trarge amounts of data during short time pe|ic'ds"
Stress Testing

* The purpose is to that the system has the capacity to hantlle iarge
numbers of processing transactions durirrg pcak penods.
Performance Testing

. Can be accomplished in parallel with Vc,trrnle attd Stl'ess testing

because we want to assess perfonnance rttrder rll t:onditions"
. System performance is generally assesscrl itr tenls <if response
titnes
and tfuoughpui rates under differing pro(rcssi1lg ittld conf,grtratiott
conditions.
Scalabilify Tcsting
Io,rds /
These tests ensure the deEee to which the applrcatiott'systclll
processes can be dishibuteci across additional servels atrri cltetlts'

Acceptancc Testing
to
" Acceptance Testing is clefinecl as the process of tbrrllal testing conducted
cdte,'ia and to
detenrrine whether or not the system satisfles its acceptance
enable the custorner to detelline whether or not io accellt the sylrtern
. The pu{pose of this testrng is to ensure that Cttstouer's requiretttettts
objeciives are met and that all the components al'c correctlf included in the
customer package.
ftcgrcssion Tcsting

Reg:'ession testing is ihe process of testing changi:s t() cojnputer I,roglams tO

make sure that the older programming still works rvith tlr.: ttcr',, chal'iges.
Page 58 of 76

dt,:
 Strategic issues

. Specify product requirements in a quantifiable mallnef before

tesiing starts'
. Specify testing objectives explicitly.
. tdentify categories of users for the software and develop a profile ftrr each.
. Develop a test plan that emphasizes rapid cycle testing'
o Build robuSt software that is designed to test itself.
g' Use effeetive formai reviervs as a filter prior to testing'
." Conduct formal technical reviews to assess the test strategy and tesl cases.
f . Develop a continuous improvement approach for the testing procesli"

Validatiora testine

r*-
The process of evaluating software during thc rlevelopment process or at tire

end of the development process to detemrine rvhethr:r it satislies s;rc;ificd trusiness

requirerrents"
Validation Testing ensures that the product acti:allir rneets tht: client's needs' lt
can also be clefined as to demonstrate that the produ,:r fultllls its interrded use whett
depioyed on appropriate environment.

It answers to the question, Are we building the right product?

Validation Testing - Workflorv:

Vahdation testing can be best demonstrated usrrlg V-ivlodel' The

Softwareiproduct under test is evaluated during this type of testrng.

Activities:

a Unit Testing
a Integration Testing
a System Testing
o User Acceptance Testing

Page 59 of 75
\4

r" fi"'
 Lo
Yenification and Validation

. callcd v':rification and

software testing is part of a broa<ier group of a;:ti'iities
validation that are involved itr software quality assuranoe
. Verification (Are the algorithms coded correctly?)
tre sLt of activities that ensure that software coirectiy ilnplemettts a
sPecific function or algorithm
' Validation (Does it meet user requirements?)
The set of activities that ensure that thc soflrvare that has been built is
traceable to customer requirements

Alpha and Beta Testing

. Alpha testing
Conducted at the developer's site by encl users
Software is used in a natural setting with developers watching intently
Testing is conducted in a controlled envirotlment
. Bcta testing
Conducted at end-user sites
Developer is generally not present
It serves u, u lirr" application of the soft',vare in an environmont lhat
cannot be controlled by the developer
The e1d-user records all problems that ale encountered and reports
these to the developers at regular intervals
and
After beta testing is complete, ,ofl*ur" engineers make sottrvare nrodifrcations
prepare for release of the software product to the entire customer
base '

The art of debussins

What is Debugging ?

test case uncovers an elror,

Debugging happens as a result of testing. when a
that enor'
debugging is the process that causes the removal of

The Debugging Process

<'f testing' The

Debugging is not testing, but always happens ils a response
debugging process will have one of two outcomes:

(1) The cause will be found, corrected and removed,

J or
J
{2) the cause r.l'ill not be fbund. Wliv' is debuggir rg ditficull I
The symptom and the cause are geographically remote'

Page 50 of 76

i!llli
 6r
o The symptom may clisappear when another error is correeted.
a The syniptom may aitually be the result ,f nons:rrors (e1; round
off i.
accuracies).
c ffr" .yr"piom may be caused by a human error that is not easy 1o find.
a 'fhe sirrnptom may be intermittent'
Thc symptorr, *iglrt be due t, the causes thai are distributed
a
across various
tasks on diverse Processes.

Debugging Strategies

. Objectivc of clebugging is to find and correct the cause of a software error

. Bugs are found by a combination of systematic evaluation, intuition, and luck
. Debugging methods and tools are not a substitute for carefui evaluation based
on a complete design model and clear source code

. There are threc main debugging stratcgies

Brute force
Backtracking
- Cause elimination

Brute Force

. Most commonly used and least efficient method

. Used when all else fails
. Involves the use of memory dumps, run-time tritr:es, and output
;tatemellts

" Leads many times to wasted effort and time

Backtracking

' Can be used successfully in small programs

. The method starts at the location where a syrnptoln
has been unc overed
, The sourcc code is then traced backward (manually)
until tlie location of the
cause is found
. I' torg. proglams, tfie number of potential backrvard paths itlay become
unmanageablY lar"ge
Cause Elimination

The third approach to debugging, cause elinlinatjotl. is rnanifested

by

induction or deduction and introduces the concept of bilary

parlitioning. ]'his
the orror occulrence
approach is also called incluction and deduction. Data rclatecl to
and the clala
are organized to isoiate potential causes. A "cause hyrothesis" is deviscd

are used to prove or disprove the hypothesis. Altemati"'clY, a Iist of

all P ossilile caLlsel

is developed and tests are conc]ucted to elirninated eaclr. If rnrtial tests inclicate
thilt il
jllrr''t ttl isolate
particular cause hypothesis si-iows promise, the data are ri:tliteci ltt atl iltt
rhe bug.
Page 67 of 76
 /v
(//
{ Le,
ildl Softlvare maintenance
SDLC nou' a days' [t stands for
software maintenance is widely acceptecl part of
of software product' There
all the modificatior;; updations done afterihe delivery
are nunber of ,eoso.rr, modifications are required, some of them are briefly
*iy
mentioned below:

. time, such as taxatitx

Marlcet Conditions - Policies, which changes over the
and newly introduced constraints like, how to maintain
bookkeeping' may
trigger need for rnodification'
. CUent Requiremerrts - Over the time, customer nlay ask fcrr Irew features
<>r

functions in the software'

. Host l\{odifications - If any of the hardware and/or platibnl (such as
operating system) of the target host changes, software changer are needed to
keep adaptabilitY.
. Organization Changes - If there is any business ievel changr: at client end,
such as reduction of orgaoization strength, acquiring anolher company,
organization venturing into new business, need to modify in the original
software maY arise.

Types of maintenance

trn a software lifetime, type of maintenance may

vary basedon its nature' It may
:,

bug discovered by some user or it may be

be just a routine maintenanie tasks as some
Following itre some t),To-s
alirgeevent in itself based on maintenance size or nature.
of maintenance based on their characteristics:

and upttations done irt

. corrective Maintenance - This includes modilLcatic.rns
6it"over':d by user <tr
order to correct or fix problems, which are either
conctruded bY user error rePofis'
and up<lations applied
, Aclaptive l\{aintcnance - This includes modif icatious
to the ever changing world
to keep the software product up-to tlate and tunecl
of teclurolo gy and business envitonment'
tlonc in
. Perfective Maintenance - This includes mo<lificatic,'us ancl ulrdates
period of time' I{ includes neu'
order to t""p trr. roftware usable over long
features, new user requirements for refining
the solJlvare and improve its
reliabilitY and Performance'
to
n Preventive Maintenance - This includes nlodifications and updations
proble ms, which are
prevent future problems of the software. trt aims to attend
irot significant at this mornent but may cause serious issues
in future'
Cost of Maintenance
Reports suggest that the cost of maintenance is high. i\ stucil.'ou
estirnating softrvare
as of thl cost of entire
maintenance found tliat the cost of maintenance is as hj1.lh
670/o

software process cYcle.

Configuration management
Softwareconfigurationmanagement(SCM)isasoftwateengineering
used bv organizations
discipline consisting of standard processes and techniques often
helprr in identifoing
to manage the changes introduced to its software products' SCM
individual elements and configurations, tracking changes, and version selection,
control,andbaselining.

SCM is also knorvn as software control lnanagelnent. SCM aims to control changes
introduced to large cornplex software systems through reiiable versiott selection and
version control.

SCM defines a mechanism to deal with different tcr:httical diffictllties of a proie,.:t

plan. In a software organization, effective implementiiliou ol'software configJuratiott
management can improve productivity by increased coordination among the
progri**rrs in a team. SCM helps to eliminate thr:: r:onftisiotl ofr en caused by
misiommunication among team members. The SCM systom conttols tho basrc
eomponents such as soft*are objects, progfam code, test data, test 'rutput, design
manuals'
documents,anduser
The SCM system has the following advantages:

a Reduced redundant work.

a Effective management of simultaneous updates'
a Avoids configuration-related problems'
a Facilitates team coordination.
used in builds'
a Helps in building management; managing tools
traceability back t'o its source'
a Defect tracking:1t .rrui", that every defect has

Page 63 of 76
 b4
{-lnit -lV
Software QualifY Assu rance

Software Quality
stated functional and
Software quaiity is called the conformance to explicitly
performance requirements, documented development standards,
and implicil
characteristics.

A software is said to be of a good quality if it

. Meets the customer's requirement

. Is completed in the estimated Tinte.

" Is completed within the estirnale(l cost.

I{eet Requilernettt

Tirne

Quafiry ConcePts

Qua}ityManagernentaisocalledSoftr,varequairlr,Assurallce(SC]A).

"Servesasanutribreilaactivitythatisappliedtht.lll.lgl,i.-lLttihesoli.\,'arcprocgss
. tioing it ovel"agattt
Involves doing tle soft.,r,are clevelopnlent corre(lil! "'6;11-5;115
. Recluces the imount of rcrvork, rvhich results tll
lot'er costs atld iltlirr.vetl
tinte to market

1. Quality
2. Quality Cotrtrol
3" Quality assurance
4. Cost of quality

Page 64 of 76

,
- lr..'f
4 ,ff,,'i &; ;
 {s-
:.:Y Trvo kinds of quality rnay be encountered:

o Quality of design
o Quality of conformance

Quality of Design

Quatity of design refers to the characteristics tht designers specify for an itent
The grade of materials, tolerance and performance specifications all contribute qualitl'
of design.

Qualify of Conformance

Quality of Conformance is the degree to which the design spccifications are

followed during manufacturing.

Quality Control (QC)

QC is the series of inspections, reviews,and tests usecl lhroughout the

development cycle to ensure that each work product rneets the requirernents placed
upon it.

QC includes a feeclback icop to the process thal r;t'eatod the wolk product.

Quality dssurance (QA)

. Consists of a set of auditing and reponllrg tirilctiotls-tl'at ass€ss tire
eff"ectiveness and cornpieteness of quality controi aclivtiies.
, Frovides rnanagemenr personnel with data lirat provides irsight into the
quality of the products.
, Aierts *u,rog.nr.nt personnel to quality problelns so that the5r can apply the
necessary resouiees to resolve quality issues.
Cost of Quality

Includes all costs incr:rred in the pursuit of qualll)'of irl perfoul-ring quality-
related activities,

Involves various kinds oi quality costs.

" Preventiort costs

Quality plamring. fonnal technical revi,j\\'s, trlst eouiplllc'rL. training
. Appraisal costs
Inspections, equipment calibration and nraintcrtattct:. test,ng

, Failure costs - subdivided into internal failure o.sts iir.td exteutal lailurc costs
Intemal f,ailure costs

Incured when an error is detectccl in a product ixror lcl

shipment.
Page 65 of 76

.:

.: i f,ills"'
 Include rework, repair, and failrrre mode analysi;'
'
External failure costs

. Involves defects found after the product lias beelr shipped

. Include complaint resolution, product return and replacement,
help line support, and warranty work'

a . Conformance to explicitly stated functional and performanct: requirements,

L
explicitly documented development standards, and implicit characteristics that are
expected of all professionally developed software'

The above definition emphasizes three points

(l) Software requirements are the founciation from wiiich quality' is

rneasured; lack of conformance to requtrements is lack of quality.

(2) Specified standards define a set of devcloptnent criterii that guide tlte
manner in which software is engincered; if the q"iteria are n6l
followed, lack of quality will almost surely result'

(3) A set of implicit requiremetlts often goes unmentionr:d: if software

tails to meer implicit requirements, software quality is sr,s,ect.]
-/
(i) SOA Rctivitics

Prepares an SQA Plan lor a Project'

ploccss descnption'
Panicipates in the clevelopment of the project's softlvare
rvith the define<l
Reviews software engineering activities to ygl]]y compiirutce
softrvare process.
rvjth thosc
. Audits designateci soiirvare work products to \1crdy cotlpliarrce
defined as pafi of the sofi*'are process'
Ensures that cleviations iu softrvare rvork and \\olk products ar: clocutnentetl'
and handled according to a documented proceciLlrc'

R.ecords any noltcollpiialce and teportS tO Seltit't' lllrtll"lgelllelll'

Coordinates the control and management of charige'

Helps to coliect and analyze software metrics'

Page 66 of 76

D.
 L+
\= (ii) Sofhvare Reviews

the soft'vare engineerin,g prc.rcess.

'fhal
Software reviews are a"filter" for
is reviews are applied at various points during the softwar': developmenl
process an server to uncover erTors that can then be removed.

Software reviews serve to "Puriff" the soltware analysis, tlesign, coding,

and testing activities.

, Catch large classes of errors that escape the oliginator tlore than other
practitioners
. Include the fonnal technical review (also called a rvalkthrough or inspection)
Acts as the most effective SQA filter
Conducted by software engineers for softwat"e eugineers
Effectively uncovers elrors and improves software quality
Has been shown to be up to 75o/o effective in uncovering design flaws
(which sonstitute 50-65% of all errors in software)
" Require the software engineers to expend time and effort, and the organization
to cover the costs.

Formal Technical Review I^F{I'R)

Formal Technical Review is aSQA activity tirat is performej

by softwaro
engineers.
J'
Objectives of FTR are

. To uncover elTors in function, logic, or implementation

fot any representation
of the software.
:J . To verify that the software under review meets
its requirements'
to predefined
. To ensure that the software has been represented according
standards.
oToachievesoftwarethatisdevelopeelinauniforrllll,}anllcr'
" To make projects more lnanageable"

soillvare engineers to
In addition, the FTR serves as a training ground ltri Ju;liot'
desigrl, and constntct;on'
observe different approaches to softrvare analysis,

Promotes backup and continuity because a lll1lll5trI

of'people bc;olne lamiliar
with other parts of the software.

-i
May sometimes be a sample-driven revierv'

. Pro.Ject managers nlust quantlfy those r'vork pi'oducts that ar() the pnmary
targets for formal teciinical reviervs.
The sample of products that are revierved nr.tst be represclltativc of thc
"
products as a rvhols.
Page 67 of76
 6r
\- (i) Review Meeting
Has the following constraints
From 3-5 people should be involved
Advance prefaration (i.e., reading) sh.uld occur
fol e;rch participa,t
piece and involvo only *
but should r"quire no moie tha,, two hcil[$-a
small subset of comPonents
The duration of the meeting sh<luld be less than two
hout s

Focuses on a specific work prnduit (a software requirements

lpecification, a
detailed design, a source code listing)
Activities befcrre the meeting
ffr" proOg""f informs the project manager that a work product is
complete and readY for review
The project rnanager contacts a gevlgiv leader, who evaluates the
prod,il f* readiness, gcnerates copies of product lnaterials, and
dirtribut"r thern to the reviewers for advance preparation
Each rgv:igwgl spends one to two hours revielving tlie product and
making notes before the actual review meeting
Th. ."ui"* l"udo an agencla for the rel'iew meeting and
; "stablishes
schedules the time and location
Activities 4urine the meeting
fire meeting is atteided by the review icacler, all revit'wers, and the
producer
one of the reviewers also serves as tlte iecorcJer lbr all
issues and
decisions concerning the Product
After a brief introdi"tion by the review leader, the plqltucer
proceeds
ask questions and
to ,,walk ,troughi the work product while reviewers
raise issues
that are rliscovered; n<r
The recorder notes any valid problems ol elrors
ti-. or.ffo.t is spentin this meeting to sqlyg any of these problems or
eITOrs
Activities at the conclusiort of the meeting
All attendees must decide whether to
.Accepttheprocluctwjthoutfufihc.r.moc]rflcation
(After tliese errors are
" Bglqgl the prociuet due to severe erors
colreoted. another review rvill thcrl occltt')
. Accept the product prqv$191U[]" (h4rnor elrcr i need to be
btlt no additional revie"i' rs lequired)
irreited
All atteldees then complete a $.gU-o&'rrr ri'hich tlrcy' ir-rrlrcate tirat they
took part in the revie$, and that they cone Lrr v''i1-11 tile findings
Activities follorvine the rneeting
The reccrder produces a list of review issLre-s that
' Identifies problern areas within tirr: llroduct
' E-qyqLaS-gtl44to!-item chect]r:i1-to guide thr: producer itt
tnak;ltg comcctiotts
The recorder includes the iist in an FTR sr-r1111llary 1'0p01'l

Page 58 of 76
 h1
'Thisonetotwo-pagereportdescribes]yha!wasreviewed,who
,*i"*"d it, and iutt't *"'" the findings and conclusions
Ttre review t.ua.. follows'up on ttrr't
findi,gs to elNure that the
p191!gg the requested corrections
"*kes

(ii) FTR Guidelines

1) Review the product, not the producer'

2) Set an agenda and maintain it'
Limit dJbate and reb,ttal; conduct in-depth discussions
ofilirre'
3; the problem noted'
1; rnrrnciate problem areas, but don't attempt to sgive
5) Take written notes; utllize a wall board to capture coinments.
6i Limit the number of participants and insist upon advance preparirtion
Develop a checklisi for each product in order to structure 'rnd
focus the
7)
review.
8) Allocate resources and schedule time for FTRs'
g) Conduct meaningful training for all reviewers'
review process'
1b; Review your edrlier reviews to improve the overall

Statistical Softrvare Oualih' Assurance

Statistical quality assurance implies the follorving

steps'

1) Collec! andcategorizeinformation(i.e.,causes;)abotttsoftwatedefectsthat
occur. to
2) AttemPt to trace each defect to its underlying cause (e'g', nonconformance
violation of standards, poor cotntnttnication with
specifications, design
"rrot,
the customer).
to 209'o of all causcs),
3) Using the Pareto principle (80% of defects can bc traced
!

isolate the20%'
crrrr be tracked 1o one of the
Although hundrecls of errors are uncovered all
following causes.

. Incomplete or erroneous specifications'

. Mffi.pritution of customer co-mmunication'
. Intentional deviation from specifications'
. Violation of programming standards"
. Errors in data rePresentation"
. Inconsistentcomponentinterface'
. Etre.ts in design logic.
" Incomplete or elToneous testing.
. Inaccurate or incomplete documentation'
. E..ott in programming language translation of closign'
. a.nUiguout or ilconsistent human/computer intertace'

Page 59 of 76

ll,:,
 To
^t Six Signta
. Popularizedby Motorola in the 1980s
.Isthemostwidelyusedstrategyforstatisticalqualit]rassurance a company's
. Uses data and statistical analysis to measurg and improve
oPerational Performance
. Identifies and eliminates defects in manufacturing and seryice-related

(3'4 defects per a million

. +fft"tJt? tigma" refers to six standard deviations
occurrences)

SOA PIan
quality arisurance in an
The SQA Provides a road map for instituting soliware
organization.

Developed by the SQA grouP to serve as a lgU4llqlq for:

SQA act'r'ities that arc
instituted for each softrvare project in an organization

. Structured as follows:
The Purpose and scope of the Plan
within
e arr.ripti* orutt toftware engineering work products that fall
Y thePurviewof SQA i. r t.--:-^ 4
- All applicable standards and practices that are applir:d during the
software Process
- r rL -
and tasks (including reviews and audrts) and their
sQa actions
placement throughout the software procelis
and tasks
{l The tools and mJthods that support SQA actions
for assembling, s#gxrarding, ancl maintainrttg all SQA-
Methods
related records
relative to product qualitY

The ISO 9000 qualitY standards

on cliririitt'ltlanagelll( trt alid quality
ISO 9000 is a set of internationai standards
assurance deveioped to hcip cornpanies
effectiveit' rlr-.cutltettI the quality systent
elements to be irnplemenred to maintain an
efficieni .lirllity systel]]" Thc-y itre not
specific to any one industry aud catl be applied
to orga,tiz'ttiotls of an1' sizc'

s. ISO9000canhelpacolnpanysatisfyitsct'tstottleLs'mc'etregulatory
requirements, and achieve continuai improvement"

ISO 9000 Series standards

The ISO 9000 family contains these standards:

. ISO 9001:2015: Quality management systems 1{ oq urrenteirts

. ISO 9000:2015: Quality management systems 1i Lnrriarneu[a]s att, l vocabulary)
v6 Page 70 of 76

J' 'fluF'
-" ,"r&P
v'1
1t
t.-J
ISO 9004:2009: Quality managemerlt systerrs -' Managing
for tire sustained
success of an organization (continuous improven-rent)
systems
ISO 1901 1:2011: Guidelines for auditing management

ISO 9000 certification

ISO 9001 is
Individuals and organizations cannot be certified to ISO 9000'
cao cerlify'
the only standard within the ISO 9000 fainily to which organizaliolls

ISO 9000 principles of qualify management

The ISO 9000:2015 and ISO 9001:2015 standards are based on seven quality
management principles that senior management can apply for organizational
improvement:
)

l. Custotner focus
o understand the needs of existing and futrrre customers
o Align organizational objectives rvith clrslomor needs arld expectatiotrs
o Mcet customer requirements
c Measut'ecustomersatisfaction
c, Manage customer relationshiPs
c Aim to exceed customer expectations
Leam more about the customer experiencc attd customer satisfaction.

2, Leadership
o Esiablisli a 'ision and directio, for the organizatiott
c Set challenging goals
o Model orgat'tizational values
c Establish trust
o EquiP and entPorver ernPioYees
o Recognizeemployeecontributions
Leammoreaboutleadershiparrdfindrelatec]l.esOurccs.

3. Engagernent of PeoPle
c Ensute that peopie's abilities are used anii vaiuecl
o Make PeoPle accountable
o Enabie parlicipation itt continual improvlrrrenl
o Evaluate individual perfonuance
o Enable lear:rirlg and knowledge sharing
o Enable open discussion of problems atlci r:ot'tstLaints

: Leam more about employee invoivement

4. Frocess approach
.J o Manage activities es Processes
o Measure the capabiiity of activities
o identify linkages betr'r'eetr activities
Page 71' ol 76
 7e)
o Prioritize improvement opporlunilies
o DePloY resources eflectivelY

woI i; anti see proces s analysis

Learn more about a process view of
toois.

nmprovement
anci capabiiities
o trmprov e arganizational perfbnnance
o Align imProvement activities
o Empower peoplc to make improvements
o Measureimprovementconsistently
o CelebrateirnProvements

Learnmoreaboutapproachestocotltinuitlimpror''ement'

6. Evidence-b ased decision making

o Ensure the accessibility of accurate and rciiablc data
o Use appropriate methods to analyze data
c Make elecisions based on analysis
o Balance data anaiysis lvith practical exp\'riellce

See tools for decision making'

7. Reiationship mairagenleni
ze resources. and
o Identify and select suppliers to manage costs' opttml
crcate value
ihc siloi-t ancl long term
\- c Establish relationships consiciering both
itnd plans lvith piulners
o Share expertise, resources, informatiolt,
cCollaborateonimprovetnentanddgyg]ollmelll,activitieS
o Recognize suPPlier successes

sec resout'ces reiatcd to

I-earn rnore about supplier quality and
rnanaging the suPPiY chain'

Page 72 of 76
.-
73
SOFTWARE ENGINEER,ING

UniversitY Questiotts

Sub.Code: 48CA6C3

PART A

; y' Wtrat is meant by softu'are qualitY?

T Z{Define "Tnvial projects".
3. What are the rnajor factors that influence softu';ire cost?
4. Write the format of a software requirements specification.
5. What is meant by coupling and cohcsion?
6. What is meant by single entry and single exit cotrstntcts?
i. Whai is meant bY unit testing?
8, What is nleant by configuration management")
q. Define "SQA - Plau".
10. Define "QualitY Assurance"'

:- t{Wnatare the factors that inf'luence quality and ,toduc.:tivitlr?

goals?
L l2f,ltlhatare the factors to consider in setting proJC( |
technrquc'l
.u 13. Which principle is useci in Deiphi cost estimatiorr
14. What are the used of Decision tables?

15. Wliat is meant bY lv{ilestone?

16. [hat are the tYPes of couPlings?

17. What is meant by Acceptance testing?

tr 8. State the "Flalstead's efforl equation"'

19. What is meant by Fon-nal technical reviervs?

20. Write the necessity of quality assurance'

r \\(What are the factors of rnediurn size projects?
L 22" What are the factors of consider irl project planrrirrg'l

23. Drall' the prociuct rvork breakdown stflicture'

2.1. What is meattt by relational notations?

25. Write the fundamental design concept of softwllt'''''

26. What is meant bY test Plan'/
27. Wbal is mearlt by Integration tcsting?
Page 73 of 76

,: "'
 28. Wrat is meant by systern
f4
testing? " /
29.Whatis meant by statistical quality assurance?
a30.Whatarethefactorsdeterminethequalityofas'lftware?
31. What is meant by Milestotte and deliverables?
32" What are the difference betwcetl softrvare
eriginecrillg and other engineering

branches'i
2 erponent colnputation cost
33. What are the scale factors usecl in thc COCOIT'Iil
estituaticn technique?
proct
34. Write the ciomain requirements in a software cleYr:lopme rlt
SS'

35" \&4rat are the rcal time executives?

36. Define modularization teclmique'

37. Define configuration managelnent'

38. What is tncant by validation and verif-rcation?

and process standard?
39. What are the difl'erences benveen prodr'rct stanclard
40" What is meant by quaiitl'planning?

PART B

, ( U.*plain tlie productivity factors'

/'
T;. Explain the largc Projects'
3. Explain about staffing ievel estirnatiort'
4. Explain about state oriented notations'
5. Describe abstraction in detail'
6. Deseribe the violation of single entry' singie exii'
'7
. Explain the validation testing'
8" Explain strategic issues of softu'are testing'
g. Expiain about the fonlal technical rcviews'
10, Describe the quality aspects in detail'
r 1 1. Explain the size categories for softu'are products' \
t)a913!all r-'"Ja-\
.L12. Explain the phased life-cycle model'
13. Explain the Expert judgment cost estimation techrticlue'

14. Write rhe format of a sollrvare requirements spccil'tcalton'

15. Explain the Abstraction mcchanism'

15. Fxplain the Single entry, Single exit constructs.

Page 74 of 76

r:fs!'' .
-t ,'t;
v
/,
:ctrT"ExptrainthemanagementaspectofSottr'vareenglneenng'

18. Expiain about the Configuration Managetneut'

lg.Wratarethedutiesperformedbythequalityassurancepersonnel?
9:20.How the quality of a software product is deternrrned?
y2l. Explain ttre distribution of effort'
22.ExplaintheHiel.archicaltearnStructureindetail
tecirniqttes'
23" Explain the recurreuce reiations of forrnal spccificai"ion

24. Explainabout modularity of software design'

25. Explain about the coding style in detail'
26" Describe about Waik throughs.

27. Explainthe managerial aspects of software englitr*,:rirtg.

28" Explain the need for quality assurance'

29. Explain about the formal tecirnical reviews'

3l"Explainaboutthesoftrvarerequirementsspecilicatit'n'
presenl. itt softlr'x1i' erngineering"l
32. What are the cost estimation techniques
Define all"

35. ExPlain about coding stYle'

35. ExPIain the art of debugging"

37. Describe about the quality concepts'

38. Explain about the software revierv'

PART C

1- (,r' Explain the size f'actols of a software'

2'Explaintlteso|twar.erequiretnentsspeoif]erinrilllltil'
3. Explain the distributed system design'
1. Explain the Integration Testing in detail'
5. Explain the ISO-9000 quality standards in detail'
T4 Explain the probierns ide,tified by respondents iti iv{a,agerial issues'
7. Describe the Algorithttric cost models'
8" Describe the softwar"e design guidelines"
Page 75 o{ 76

r! ,(,,:r
 {,c
t-
t .....7-
g.Explainabouttlreunittestingarrrivalidationtr.ltiljJrlL,Jci,;il.

s* 10. Dcscribc about softtvlrc revlcws'

to softwale'
1. Explain the total effort devoted
G* 1

12. Explain the algnrithtrr cost models'

s* 13. Explain the Milestones and Inspections'
ffi: 14. Explain the sour code rnetrics'
@i
\- tl5. Describe about Waterfall model'
f"". 16. Describe about softu'are cost factors'

,t,l 17. Explain about \Valkthrouglr and Inspections'

-.
18. Explain the strategic issues of soflrvarc tcsting
ffi*
19. Exptain the Fonnal Tec}rnical Rer iert"
*
:-
m
Y
ffi; t,

ffi*.
eSFq*v
q'*5d

.iqq
+:
W;
&*,
d,.
s;6r:

,6d!r,
&r'

W'84

q:-
.. ,,

(L;"

ffi
4ffi
s.

tr
(-
f
l'.,
*':a
Ss:.,

flr
ra
;(.
Page 76 of 76
\"-
:-"'
*"i't'