Software En gi~

re
ortance of detecting and removing faults befo
developers who could not und erst and the imp given a free
th e cust ome r experiences them as failures. It belongs to the legal system that has
r
ages._It also .belongs to universities and othe
pass tq software developers on bug rela ted dam ci-
pro gr~ g over software engineering prin
high er educational inst ituti ons that stre ss on
ples and practices.

v1'.2 WHAT IS SOFTWARE ENGINEERING?

art
to in almost all area s of hum an endeavour. The
Software has become critical advancement
of pro gr~ min g o~y i~ no longer sufficient
to construct larg e pr~grams. There are serious
and 9..uality of man y soft ~are products.
problems in the cost, timeliness, -mainteriance
ing thes e problems by producing good
Software engineering has the objective of solv to
in budget, '_fo achieve this objective, we have
quality, maintainable software, on •time, with
ity of the product and on the process used to
focus in a disciplined man ner on both the qual ·
develop the product.

/1 .2.1 Definition
in 1968, Frit z Bau er [FRIT68] defined software
At the first conference on software engineering in
soun d enginlering principles in order to obta
engineering as "The establishment and use of
and works e iently on real machines". Stephen
economicall developed software that is reliable
ipline whose aim is the pn uction of quality
Schach [SCHA90] defined the same as "A disc ~-
are, softw are that is deliv ered on time, with in budget, and that satisfies its requ irem e~•.
softw
Both the definitions are popular and acceptable
to majority. However, due to increase in
shifting to produce qua lity software that is
cost of maintaining software, objective is now
et, and also satisfies its requirements.
maintainable, delivered on time, within budg

/1 .2.2 Program Versus Software

the
of programs, documentation of any facet of
Software is more than Ptoe:t/AIIlS. It consists
operate the software system. The components
~B!al11 and tlie procedures used to setu p and
of the software systems are shown in Fig. 1.1.

dures
Proce
Software = Program + Documentation + Operating
Fig. 1.1: Components of software
Eoduction to Software Engineering · s I
Any program is a subset of software and it becomes software only if documentation and
era ting procedure manuals are prepai:ed. Program is a combination of source code and object
;.e. ~;;!1~!~11 consists of different types of manuals _as shown in Fig. 1.2.

Formal specification

Analysis\ - - - - - C..9~ex~:Diagr~_p
Specification

Data flow di~gr_~s

Flow charts

Design

Entity-Relationship diagrams

Documentation
manuals
~r':e code listings

lmplementallOn

Cross-Reference listing

Test data

T!:?Sl!ng

-
Test results

Ag. 1.2: List of documentation manuals

Oe-~ti~ e._~ll_!e~ consist of instructjo.m...to ~ tue, and ~ the softw~e ~~m and
instructionsonow to"""r eact to s~tem fail~. List of operating procedure manuals/documents
is given in Fig. 1.3-:- - - -·- --·-
 W♦ ,.

16
5ottware Engineering J
System overview

Beginner's guide tutorial

. - - - - User manuals

Reference guide

Operating procedures - - - 1
Installation guide

.___ _ Operational manuals

System administration guide

Fig. 1.3: List of operating procedure manuals

.,/1 .2.3 Software Process .

soft~ ~e. This diffe~s from or~anization .
The softwar~ process·is tbe way in.which ~ prod~c~
smess requrres more
.to organization. Surviving in the increa~in~~..c...~~pe t~?-~ -~oftwate_bu
~-eve~ e_n:ent too~. We
·. than ~~ smaj, _~~~led~ ~le~de'!'!1PP~!s and buying:_ ~~~ a~..5t
opers can systematically
also need to use effective software development processes; so that devel
lete their proJeds. Many
use the best technical and managerial piac_§:es to, successfully comp
as a way _to improve the
software organizations are looking at s~ftware process impro_vement
ind ·maintenance efforts
quality, prod~ctivity, ·predictability ·of their software d~velopnient, .
. ·. . .. . . .. . . .
[WIEG96].
s of compa-
It seems ~traight forward, and .the literature has a numb~r of success storie
gement capa- ·
t mana
nies that substantially improved their software development and projec
e signifi~ant and.la.sting
bilities: Howev~r, many other organizations· do not manage to achiev
ss -
improvements in the way_they conduct-their projects. Here we discu
. . . .·
~ f ! . ~ ~ H i l l 4 P 8 9 , WIEG99]?
. 1. Not enough time: Unrealistic schedules leave insuff
icient .time to do the essential
of spare time to devote t.o :_
project work. .No software,,gnmps are sitiiog atauod with nlentv
and w,mit they should be-
ex~lori~g what is wr9ng,~ ,lli..thcir c1tn:ent·deyelo12men lproc .es;s
ajgi : ~ ~e, of higher· . ·
d~m~ d~er~n~ly.__Ctisto~ers ~nd senior mail~ger~ i ~ ~~!!,!~~ _g~
Q!,_ality ~11-mlll)!}!l}!}}J>._OSSI~l~ .!fill- 'rherefor~, th_ere JS always a ,short
age of time. Oneoonse-
but then.they have·t.o.
qu_ence 1stha t software_~rg~_niz~tions may _deliver _release-1.0 on time,
discovered bugs. . ..
shi~ rele~ e 1.01 _almos_t munediately there a~r to fix .the.·recently
improvement is that
. 2. Lack of .knowledge: A second obstacle to·widespread proc~ss
m;;; so~ware develoe;rs do not seem to be familiar with industry best
practices Normally
ture to find out abo~t the best~
. . so. _ar~ .evelopers. do not spend much time readin~ the litera · ·
of software dP..velopJn.el. l.t. ""'Developers uia b books on J ava, Visua · l Basic or
k_gownLE
· O¾C waysb t d t l · k fi · · . · . Y uy
quali ty on their bookshelves .
. , . u ~ oo . or anything about process, testing or
~ntn)duCtion to Software Engl~eering 7 j
The industry awareness of process improvemen t frameworks such as the capat{i1~
roaturity m~,el and ISO 9001 for software (discussed in Chapter 7) have grown in recent
Jears, but e ective and sensible application still is not that common. Many recognized best
practices available in literature simply are not in widespread use in the software development
world. : ·
3. Wrong motivation s: Some organizations launch process improvemen t initiatives
for the wrong reasons. May b~ an external entity, sucb_as a .&J;>Jlt@ctor, d~w.aud_e.d.J!lli.!. the
dev.eJopment !)rg!!}ization shguld,achieve,CMM l~vel X by daf&.Y. Or perhaps a senior manager
learned just enough about the CMM and directed his organization to climb on the CMM
bandwagon.
The basic motivation for software process impro~ filfillUh.ould be to wake some of the
current difficulties ~ experience QD our projects tQ go away. Developers are rarely motivated
by seemingly ~bitrary goals of achieving a higher maturity level or an external certification
(ISO 9000) just because someone has decreed it. However, most people should be motivated by
the prospect _of ~ ~t4lg__ih~ir_co~ t.1!1..~PJ;s, imp!Q_ying_su ~.!Q}!_l~_i: ~ati.filaction, and deliv~ g
excellent products that meet customer expectations. The dev~lopers have resisted many process
improvement initiatives ·when they were directed to do "the CMM _thing", -without a clear
explanat~on of t}:le reason~ why improvement was needed and the benefits the team expected
to achieve. .. ·· · · .. · ·
. 4. blsuffici~nt'_ conunit~~n t:.· M~y times, the software process 4nprovemen t .fails, ..
·de~pite best of intentions, .due tc> lack-of t~ .~UJJDi~en t. It starts ~th a process assessm~ nt
but fails .to· follow .through with actual ch_a.J).filtS. Managemen t sets no ~xpectations· from the
dev~lopµle~t coinn)unity around.~ro~es~ improvement; tpey_devote insufficient resources~w~
· no improvement,,u.lan, develop .no roadma{>, and pilot' no new processes~ . · ·. · .
~ . .The'investm ent -we make in proce$S ~provemen t will not _hav'.e an impact on current·.
productivity; becaµse the time w~ spe~ 4evel9ping better ways to .work tomorrow is. _n <i
·a~ailable (or today's assignment.. It.can be ~mpting to abandon the effort when skeptics see··
.the energy they,want to be' devoted to immediate demands l;>eing siphoned off in the hope· of
a .better future (fig. 1.4);' Software organizations should not _give.up, but should take motiva-.
tion from the very real, long-te11I1 benefit.a that many companies (including Motorola, Hewlett-·
Packard,.Boeing, Mi~osoft ~tc.) have enjoyed from
sustained software process improvemen t
. initiatives. Improvements will _take place over time and organizations should not expect and
-·promise miracles [WIEG2K] and ·should always
. .
remember .the .
learning . curve~
. .
. ·... . . . . .

· . _'. · , ·. · • ' Improved future state

. Process 1mprovement . •· . · ·
. . . . begins . . . . .

r- . lnitial_.state : · . : :

Productivity .....,._-<

.· · 1 'Leaming-curve.
'
. Do not quit here!

- - rme·~ -
. ~ · .. : .· Ff~ 1.4: The ~ -lmprov~ .leamb,g C?UJV8
 [a Software En gin e~ ~

~ .2.4 Software Characteristics vio ur and

cia l ch ara cte ris tic e.g ., "it does no t· we ar out". Its . be ha
Th e so ~a re ha s a very spe hu ma n life. A co mp ari so~ wi th on
e suc h case,
n ~th er pro du cts of
~t ur e JS qu ite different tha itin g a pro gra m is giv en in Ta ble 1.1
. Bo th activities
dg e vis -a- vis wr
1.e., ~nstructing a bri ·
ses an d ha ve dif fer en t ch ara cte ris tic s.
require dif fer en t proces
program
stru cting a bridge and writing a
Table 1.1: A comparison of con
Writing a program
Sr. No. Construding a bridge -
m are under-
d. Only some ear ts of the proble
Th e problem is well understoo
1.

dges.
-
stood, oth ers are not.

Ev ery pro gra m is dif fer ent

and designed for
2. There are ma ny exi stin g bri soecjid a,ggli,a.tions.
,
nh ' du rin g all
typically do Re qu ire me nts tareically cha
3. The requirements for a bridge plw_se.1~0(.dey ~o pm ent .
struction.
no ~g e much dur ing con
tne ss of a pro-
a bridge can be Not po8Rible to cal cul ate cor rec
4. The str eng th and stability of gra m with existing metJioas.
cision.

5.
-
calculated with reasonable

When a bri de col la~ ,A the

pre
re ill a detailed When !..£.rogram fails, the rea
un ay ai l~ ey~_n__de!i~~rai~
son s are often
lY. conce~ed.
invest!O,lioa...and report.
Erograms for
.ing bridgN for D ev ~! " have been wr itin g
6. Engineen have been conatruct
50 J'.!{l.!'1' or 10.
thoUMnda of years.
'Ja'.es r apidly.
au- el) and f« h. Ha rdw att a]!u.q.{byatt,_~Jla
7. Ma ter ial , (wood, stone, iron,
carving •to ne,
niq ue, (m alu ng joi nu in wood,
. caating iron) cb an ~ 11lowly.

cte ru tia a r e ~ below

:
Some of the im po rta nt ch ara y
ou t: Th ere ii a we lJ- kn ow n ~a th tub cu rve " in reliabilit
(i) Software do es no
t we ar is Jike
. Th e cu rve is giv en in Fig . 1.5. Th e sh ap e of the cu rve
stu die s for ha rdw are products th tub cu n·t'.
ba
•ba th tub •; an d is known u
'
8unMn
se
I
pha
f Wear out
j IE---~
pha se
IE - UsehJ 'te pha se ~
I

I I
I
I
I

-~
- - - - - Tm e - - -

. Fig. 1.5: Balh tut> an e

~ to Software Engineeri~g

There are three phases for the life of a hardware product. Initial phase is bum-in p~e,
where failure intensity is high. It is expectedJ o t&.~P.I:PdJ1ct in ~e _i~d.u..s.tcy_befo.re rle~?'·
Due to testing and fixing faults, failure intensity wilLcome_d ~ti_ally_~ d- ~aL&_ti;t~Jli~e
after certain time. The second phase is the useful life phase where fa1lure mt_~n~.Y 1s
- roximately constant and is called useful life of a product After few years, agam failure
:!~nsity will increase due to wea.rjpg_ouLQu_QIDRQDen.t§. This phase is called ~ o u t ws~.
We do not hav~ this phase_f?E.!~~soft ware.~it. dQ~f?,,,,D.gt?~ar ou~. The curve for software 1s
give-; inr'ig.--1.6.

- - - Time _ __.>

Flg. 1.S: Software cu,ve

Import.ant point is fi.Ot\~l.lf!.~ mes reJiablt- ovrrti"!,e in~tead ofwearjp1i O!:!,t. It b~omes
obiml~te, if the environmen t for which it waB den•lopcd, changes. Hence software may be retired
d~~ environment al changeit, new ~ent.A , n~w ~"~~ions . etc.
(ii) Sonware ia not manuractu ttd: The life of a "°nw~re is from co~pt ex~laration
to the retirement of the software producL h i5 on«' t.ime de,·elopmen t effort and coiiil.nuous
mainte~ce effort-in -order t..o keep it operatioD41. Ho•·e,·er, making 1000 copies is not an
iRsue and it doet1 not iJ!~h:~_Rn.Y._ cost. In en~ (lf h,u,tw;u·r product. every PiS>d~n£Q""si;~s due
~ w material and other prorel'tcing t.>xp.•n~~. We do not have assembly line in software
development. Hence it is not manuf:\ctun.-d in the das.sical sense.
(iii) luusablllty of C'Ompon~n~ If we ha,·e to ~~-u f!ctU.!!.._8 TV, we ma.r_p~as e
pjc!ure tu\)eJr:9~-9 n~f9dor, ca~inel from An~ther. desJ.&1.! card from third and other electronic
romponents from fourth vendor. \\'e will as...llemble e,·ery part and tesfthe product thoroughly
to produce a good quality TV. We may be requi~ ~~ure on!f. a few CQ!ll~nen ~no
COQl.POnent at _all. \\'e purchase e ..-ery unit and component from the market and produce the
finished product. \Ve may have standard quality guidelines and effective processes to produce
a good quality product.
lp_E1oftware, e,·ery project is a new project. W_! start from the scratch and design every
unit of the so~are product. Huge effort is required to develop a soft.ware ~hich furttier
increases the cost of the software prod~ct. However, effort has been made to design standard
components that may be used in new projects. Software reusability bas introduced another
a~ an~-~!' -~~'!!' as component ba..~ software engmeenng . - -
 aw ~ _
-
th8 t i1', the
deve lopers can conc entr ate on truly innovativ e element.I of design,
Ht nce 11rd
s of lhe deBign lhal repr esen t BOm ethin g new . As explained eacUer, in the h wa~e world,
part th
ing proceH. 1n ,of\w are, ere •• onl1 a
c:omponent reuse is a natural part of the engineer
built using reusable wm ~nt. t~t
humble beginning like graphical user interfaces are
menus, and a wide variety of mteract"'°
enable the creation of grap hks windows, pull--down
mechanisms.
(iv) Soft war e ia fleu ble: We all feel that softw are is nexible. A erogram can be dev el~
· · be the best and may help m to
char acte Jj8~JC.ll}a .Y._ " . bar~
to do almost anyt hing. Sometimes, this ~~ ~
t~~e.!'t.tJw,_ aJ..m,t t •
ed-....4,::b· i• -:-
accomodate any kind ofchw e. However, most of the ·t.or d contro 1 ms unP! ' J1,;14 11 l Lt
· - ·-c . . ,.•
has made software development difficult U> plan. 0
mom an twar e ruJJS
the "Sof
- •· ~ ,_... -
red to for the_past 3 year s as
the basis of wha t has been refer
-.. - --~...
_ ·-·• 1 - r •

✓1 :3 THE CHANGING NATURE OF SOFTWARE

Software has ~m e integral part of most of the
fields of hum an life. We nam e a field and we find System
are
the usage of software in that field . Soft ware appl i- softw
ce
cations are gr2_~ped in to ei~ t ar.!!![<?,i:,convenien
as shown in Fig. 1. 7.
__.. (i) Syst em soft war e: Infr astr uctu
re soft-
s,
ware come under this category like compiler
operating systems, ~r s, ~r s, etc. Basically
to
system software is a collection of programs
provide service i.o other programs.
(ii) Rea l time soft war e: These software
are
ld
used to monitor, control and anal yze real wor
events as they occur. An example may be software
r~ui red for weather forcasting. Such software will
,
gath er and process the stat us of tem pera ture Ffg. 1.7: Software applications
met ers to
humidity and othe r environmental para
· forcast the weather.
(iii) Emb edd ed soft war e: This type of ~ftw
are is placed in "Read-Only-Memory (ROMf
the product. The prod uct could be an aircraft,
of the product and control the various functions of
automobile, security system, signalling sYStem, cont
rol unit ofpower plan ts, etc. The embedded
term ed as inte llige nt software.
software handles hard ware components and is also
(iv) Bus ines s soft war e: This is the larg
est application @rea. The soft ware desi gned to
software. Bus ines s soft ware could be payroll,
process business applications,!s called business
account man agem ent. It may also be a data
file monitoring system, employee management,
s base d on avai labl e data . Man agem ent
warehousing tool which helps us to take decision
(ERP) and such othe r soft ware are pop ular
.information system, enterprise resource plan ning . ·
examples of business software.
(v) PeJ1M)nal com pute r soft war e: The softw
are used in pers onal comput.ers are covered
pute r graphic;~, mul time dia and anim atin g
in this category. Examples are word processors, com
~ to Software Engineering 11

t,ools, database management, computer games etc. This is a very upcoming area and many big
organisations are concentrating their effort here due to large customer base. ·
(vi) Artificial intelligence software: Artificial Intelligence software makes ~ .f..!!.9,"-
nuroeriral a)~thms to solve come!_e~ ~bk_ms that are not amenable to computation or
sb'3ight forward analysis [PRESOI]. Examples are e!Pert systems, artificial neural netwo~k,
signal processing software etc.
(vii) Web based software: The software related to web applications, come under this
category. Examples are CGl;' HTML, Java, P ~ , DHTML etc.
(viii) Engineering and scientific software: Scientific and engineering application
software are grouped in this category. Huge computing is normally required to process data.
Examples are CAD/CAM package, SPSS, MATLAB, Engineering Pro, Circuit analyzers etc.
The expectations from software are increasing in modern civilisation. Software of any of
the.above groups, has a specialised role to play. Customers and development organisations are
desiring more features which may not be always possible to provide. Another trend has emerged
to provide source code to the customers and organisations so that they can make modifications
for their needs. This trend is particularly visible in infrastructure software like data bases,
operating systems, compilers etc. Software where source codes are available, are known as
open source. Organisations can develop software applications around such source codes. Some
of the examples of "open source software" are LINUX, MySQL, PHP, open office, Apache web
server etc. Open source software has risen to great prominence. We may say that these are the
programs whose licenses give users the freedom to run the progFam for any purpose, to study
and modify the program, and to redistribute copies of either the original or modified program
without paying royalties to original developers. Whether open source software are better than
proprietary software? Answer is not easy. Both schools of thought are in the market. How-
ever, popularity of many open source software give confidence to every user. They may also
help us to develop small business applications at low cost. ·

'Yt.4 SOFTWARE MYTHS •

5'_6#
~ to Softwara Ell!Pneering 1s j
~.S ROLE OF MAN~GEMENT IN SOFTWARE DE_VELOPMENT
anagement of software development is heavily dependent on four factors: People, Product,
'l'he Dl and Project. Order of dependency is as shown in Fig. 1.8.
process,
:,.;;..-- _ , . .

People

Project Product

Process

Fig. 1.8: Factors of management dependency (from People to Project)

Software development is a people centric activity. Hence, success of the project is on the
shoulders of the people who are involved in the development.

~ .6.1 The People .

Software development requires gm managers. The managers, who can understand the
e!Ychology of people and· provide good leadership. A good manager cannot ensure the success
of the project. but can increase the probability of succeN. The areas to be given priority are:
proper selection, training, comperuu1tion, career develo2ment, work culture etc..
Managers face challenges. It requires mental toughness to endure inner pain. We need
to plan for the best, be prepared for the worst, espect surprises, but continue to move forward
anyway. Charles Maurice once rightly said •1 am more afraid of an army of one hundred sheep
led by a lion than an army of one hundred lions led by a sheep•.
Hence, manager selection is most crucial and aitical After having a good_manager,
project is in safe hands. It is the responsibility of a manager to manage, motivate, encourage,
guide and control the people of his/her team.

/1.6.2 The Product

What do we want to deliver to the customer? Obviously, a product; ·a solution to his/her prob-
lems.
Hence, objectives and scope of work should be defined clearly to understand the
1?9,uirements. Alternate eolutions should be discussed. It may help the managers to select a
-i,est• approach within constraints imposed by delivery deadlines, budgetary restrictions,
personnel availability. technical interfaces etc. Without well defined requirements, it may be
- .
Software E ~
Qt
ne reas ona ble esti mat es of the cost dev elop men t tim e and sch edu le for the
im ~b le to defi '
ProJect.

✓ 1 ·6-3 The Process Whi_si si

software. It pro ~de s the fram ewo rk ~om
The Pro cess is the way in whi ch we produce 18 . the
<:,2mprehensive Ian for soft war e d~e lgp
™t ,san be esta blis hed . I!Jh e process ':e~rove .
nd duc t will und oub tedl y suff er. The re are man y life cycle ~od els and pro cess lDlp
e Pro -a-days
ect, a suit able model is to be sele cted . Now
men ts mod els. Dep end ing on the type of proj rk. The
alm ost ut@ dil, rd fo~ ~I.QCess fram ewo
Q.MM (Ca pab ility Ma turi ty Model) has beco!!!e however, it play s very cnti cal role for
th8 success
pro cess prio rity is aft.er people and product, proj ects,
pro ject . A sma ll num ber of fram ewo rk acti viti es are app lica ble to all soft war e
of the stones,
ard less of thei r size and com plex ity. A num ber of diff eren t task s~t~,. task s, mile
reg pted to
ts, ena ble the fram ewo rk acti viti es to be ado
wor k pro duc ts, and qua lity assu ranc e poin
irem ents of the pr~ ject team .
the cha ract eris tics of the project and the requ

✓1 .6.4 The Project .

q ~ d to con trol the coy10le3ity.
ning is requ ired to mon itor the stat us of
A pro per plan age
ove rrun s of mor e tha n 100%. In ord er to man
Mo st of the projects are co.ming late with cost
t can go wro ng and how to do it right. We shou
ld
a successful project, we inu st und erst and wha a n~s
difticult) and freeze thes e r~u irem ent s. Cl.!,_
define concrete reguiremepts (alt hou gh yez:y ays risky
uld not be inco rpor ated to ayo id ~Qf twar e ,sun>rit,es. Sof twa re sur pns es are alw
sho re
e a plan ning mec han ism to give war nin g befo
and we should min imis e them . We should hav '
·
the occurrence of any surp rise.
Pro ject ) are imp o~p t for the sncce§§..9f
All four factors (People, Pro duc t, Pro cess and more
s us to org anis e dev elop men t acti viti es in
the profoct. The ir rela tive imp orta nce help
scientific and professional way.
orta nt disc ipli ne of stud y, prac tice and re-
Software Eng inee ring has become very imp ing
prob lem s and to mee t the objective of develop
search. All are working har d to min imis e the sfie s
lity mai ntai nab le soft war e tha t is deli vere d on tim e, with in bud get, and also sati
good qua g day
requ irem ents . Wit h all crie s and diss atis faction, disc ipli ne is imp rov ing and mat urin
the being
the nich e ar88:s and enc our agin g resu lts are
by day. New solutions are bein g provided in war e
yea rs, ·situ atio n is bou nd to imp rov e and soft
observed. We do feel tha t with in couple of
ipline.
·e ngin eeri ng sha ll be a stab le and mat ure disc

pute r Soc iety Pres s, 1989 .

[BOEH89J Boehm B., "'Risk Management•, IEE E Com E
Acc iden ts of Soft war e Eng ine eri~ IEE
_[BROO87J Brooks F.P. , "No Silv er Bull et : Essence and . '
Com pute r, 10- 19, April, 1987.
Developmenr Englewood cliffs' NJ ' PH'
[BROW2KJ Brown AW., "'Large Scale. Com pone nt base d "
2000 .
O
CFRIT68) Ba_uer, Frit z et_ al., •sof twar e Eng inee ring :
A R.ep ort on a Conferrmee Spo nsor ed 1,:y NAT
Scum.ce Commtttee•, NATO. 1968 .