6 The Object-oriented Paradigm l l .7 Terminology 21Chapter Review 23For Further Reading 24Problem s 25 2.6.1 lntegration Phase Testing 2.6.2 lntegration Phase Docum entation 42 M ainten
Trang 1t oxTzxTs
Preface xv
R A R Y ;Introduction to Softw are
l 4 Specihcation and Design Aspects
l 5 Team Programm ing A spects 15
l 6 The Object-oriented Paradigm l
l 7 Terminology 21Chapter Review 23For Further Reading 24Problem s 25
2.6.1 lntegration Phase Testing
2.6.2 lntegration Phase
Docum entation 42
M aintenance Phase 42
M aintenance Phase Testing
M aintenance PhaseDocum entation 43Retirem ent 43
Problem s with Softw are Production:Essence and Accidents 214
2.9.1 Complexity 45
2.9.2 Conform ity 47
2.9.3 Changeability 48
2.9.4 lnvisibility 49
2.9.5 No Silver Bullet? 50
2.10 lm proving the Softw are Process 51
2 l Capability M at-urity M odels 51
2.12 Other Softw are Process
lmprovement lnitiatives 542.13 Costs and Benehts of Software
Process lm provem ent 55Chapter Review 57
For Further Reading 58Problem s 59
2.2.1 Requirem ents Phase Testing 34
2.2.2 Requirem ents Phase
Docum entation 35Specihcation Phase 35
2.3.1 Specilication Phase Testing
2.3.2 Specilication Phase
Docum entation 38Design Phase 38
2.4.1 Design Phase Testing
2.4.2 Design Phase
Docum entation 40
Trang 2lncrem ental M odel 73
3.5 Extreme Program ming 753.6 Synchronize-and-stabilize M odel3.7 Spiral M odel 78
3.7.1 A nalysis of the Spiral M odel 82
Object-ori ent edLife-cycle M odels 823.9 Comparison of Life-cycle M odelsChapter Review 86
For Further Reading 86Problem s 87
References 87
f h l p :e r 4
Team s 90Team O rganization 90Dem ocratic Team Approach 92
4.2.1 A nalysis of the Dem ocratic
Team Approach 93Classical Chief Programm erTeam Approach 93
4.3.1 The New Ft pr/ c Iimes Project 95
4.3.2 lm practicality of the
Classical Chief
Program m er Team Approach 96Beyond Chief Programm er
and Dem ocratic Team s 97
4.5 Synchronize-and-stabilize Team s l0l4.6 Extreme Program ming Team s l02Chapter Review l03
For Further Reading 104Problem s 104
References 105
CONTENTS
5.4 CASE l 15
5.5 Taxonom y of CASE 1 165.6 Scope of CASE l 185.7 Software Versions l22
5.7.1 Revisions l22
5.2 Variations l23Conhguration Control l24
5.8.1 Conliguration Control during
Product M aintenance l26Baselines l27
Conliguration Control duringProduct Developm ent l27Build Tools l28
Productivity Gains w ithCASE Technology l29Chapter Review l31
For Further Reading 13lProblem s l32
Quali ty lssues 137
6.l Software Quality Assurance l37
6.l 2 M anagerial lndependence 138
N onexecution-Based Testing 139
W 'hat Should Be Tested? 145
6.5.1 Exam ple of a Correctness
Proof l5lCorrectness Proof
Trang 3CONTENTS I;tCorrectness Proof and
Software Engineering
W ho Should PerformExecution-Based Testing? l58
6.7 W hen Testing Stops l60Chapter Review l 60
For Further Reading l6 lProblem s l62
7.2.1 CoincidentalCohesion l7l
7.2.2 Logical Cohesion l72
7.3 Tem poral Cohesion l73
7.4 Procedural Cohesion l74
7.2.5 Com m unicationalCohesion
7.6 Functional Cohesion l75
7.7 lnform ational Cohesion l75
7.8 Cohesion Exam ple l76Coupling 177
7.3.1 Content Coupling l78
7.4.1 Data Encapsulation and
ProductD evelopm ent 186
D ata Encapsulation andProductM aintenance l88
7.5 Abstract D ata Types 194
7.6 lnfrom ation Hiding 195
7 7 Objects 198
7.8 lnheritance, Polym orphism ,
and Dynam ic Binding 20 1
7 9 Cohesion and Coupl ing of Objects 203 7.10 The Object-ori ented Paradigm 204Chapter Review 207
For Further Reading 207Problem s 208
8.2 lm pedim ents to Reuse 214
8.3 Reuse Case St-udies 2 l
8.3 European 'Space Agency 221
Objects and Reuse 222Reuse during the Design and
lm plem entation Phases 222
8.5.1 Design Reuse 222
8.5.2 Application Fram eworks
8.5.3 Design Patterns 225
8.5.4 Softw are Architecm re 229Reuse and M aintenance 230Portability 23 l
8.7.1 Hardware lncompatibilities
8.7.2 Operating Systems
lncom patibilies 233
8.7.3 Numerical Software
lncom patibilities 233
8.7.4 Compiler lncompatibilities
W 'hy Portability? 239Techniques forAchieving Portability 240
8.9.1 Portable System Softw are 240
8.2 Portable A pplication
Softw are 24l
8.9.3 Portable D ata 242lnteroperability 243
8.10.1 COM .243
8.10.2 CO RBA 244
8.10.3 Comparing CO M
and CORBA 245Fut-ure Trends in
lnteroperability 245Chapter Review 246For Further Reading 247Problem s 248
References 250
Trang 4f h l p :e r @
Planning and Estim ating 257Planning and the Softw are Process 257Estimating Duration and Cost 259
9.2.1 M etrics for the Size
of a Product 260Techniques of CostEstim ation 264
9.2.3 lnterm ediate COCO M O
9.2.4 CO COM O 11 270
9.2.5 Tracking Duration and
Cost Estim ates 272
Components of a Software Project
M anagem ent Plan 272Software Project
M anagem ent Plan FrameworkIEEE Software Project
M anagem ent Plan 274Planning Testing 278Planning Object-orient ed Projects 279
9.8 Training Requirem ents 2809.9 D ocumentation Standards 28 l9.10 CASE Tools for Planningand Estim ating 282Testi ng the Software Project
M anagem ent Plan 282Chapter Review 283
For Further Reading 283Problem s 284
Elicitation and Analysis 305Testing during the
Requirem ents Phase 305CASE Tools for theRequirem ents Phase 306
M etrics for theRequirem ents Phase 307l0 l 3 Object-ori ented Requi rements? 30810.14 Air Gourm et Case St-udy:
Requirem ents Phase 308Air Gourm et Case St-udy:
Rapid Prototype 31 lChallenges of theRequirem ents PhaseChapter Review 3 15For Further Reading 3 15Problem s 3l6
l l3.1 Sally's Softw are Shop 323
1 1.4 Other Sem iformal Techniques 33 l
Trang 5CONTENTS xIPetri Nets 34l
CA SE Tools for theSpecihcation Phase 354
M etrics for theSpecihcation Phase 355
Air G ourm et Case Study:
Structured System s Analysis 355
Air G ourm et Case Study:
Software Project M anagementPlan 357
Challenges of theSpecihcation PhaseChapter Review 358For Further Reading 359Problem s 360
References 362
12.9 Challenges of theObject- oriented Anal ysis Phase 390Chapter Review 39l
For Further Reading 39 lProblem s 392
References 393
f h l p :e r la
D esign Phase 395l3 Design and Abstraction 395
13.2 Action-oriented Design 396
13.3 Data Flow Analysis 397
13.3.1 D ata Flow AnalysisExam ple 398
13.8 Form al Techniques forDetailed Design 4l5
13.9 Real lim e Design Techniques 41 6l3.10 Testing during the Design Phase 4113.1 l CASE Tools for the
Design Phase 41l3.12 M etrics for the Design Phasel3.13 AP G ourm et Case St-udy:
Object- oriented Design 420l3.14 Challenges of the Design Phase 429Chapter Review 429
For Further Reading 430Problem s 43 l
12.3 Use-case M odeling 369
12.4 Class M odeling 37l
12.4.1 Noun Extraction 372
12.4.2 CRC Cards 374Dynam ic M odeling 375Testing during theObject-oriented Anal ysis Phase 378
CA SE Tools for theObject-oriented Anal ysis Phase 383
Air G ounnet Case Study:
Object-oriented Anal ysis 383
f h l p :e r 14
Im plem entation Phase 434l4 Choice of Programm ing Language 434
14.2 Fourth-G eneration Languages 437
14.3 Good Programm ing Practice 440
14.4 Coding Standards 445
14.5 M odule Reuse 446
Trang 6M odule Test Case Selection 447
14.6.1 Testing to Specilicationsversus Testing to Code 447Feasibility of Testing
to Specilications 447Feasibility of Testing
to Code 448Black-Box M odule lkstingTechniques 45 1
14.7.1 Equivalence Testing andBoundary Value A nalysis 45l
14.7.2 Functional Testing 452Glass-Box M odule lkstingTechniques 454
14.8.1 Strucm ral Testing: Statem ent,Branch, and Path Coverage 454
14.8.2 Com plexity M etrics 456Code W alkthroughs andlnspections 45814.10 Com parison of
M odule lksting Techniques 45814.1 l Cleanroom 459
14.12 Potential Problem s W henTest ing Objects 46014.13 M anagem ent Aspects of
M odule Testing 46314.14 W hen to Rewrite Rather thanDebug a M odule 46314.15 CASE Tools for thelmplem entation Phase 46514.16 AP Gourm et Case Study:
Black-Box Test Cases 465Challenges of the
lmplem entation Phase 467Chapter Review 467
For Further Reading 468Problem s 469
lm plem entation and lntegration
of Object-oriented Products 480
M anagem ent lssues during the
lm plem entation and
lntegration Phase 480Testing during the lm plem entationand lntegration Phase 48 llntegration Testing of GraphicalUser lnterfaces 48 l
15.4 Product Testing 482
15.5 Acceptance Testing 483
15.6 CASE Tools for the lm plem entationand lntegration Phase 484CASE Tools for the Com pleteSoftware Process 484lntegrated Environm ents 485Environm ents for
Business Applications 486l5.10 Public Tool lnfrastructures 487l5 l Potential Problem s
with Environm ents 487
M etrics for the lm plem entationand lntegration Phase 488Air Gourm et Case St-udy: lm plem entationand lntegration Phase 488
Challenges of the lmplementationand lntegration Phase 489Chapter Review 489
For Further Reading 490Problem s 490
16.4.2 Authorizing Changes
lntroduction to lm plem entationand lntegration 474
15.1.1 Top-down lm plem entation
Trang 7M aintenance Skills versusDevelopm ent Skills 504
l6.7 Reverse Engineering 505
M aintenance PhaseChapter Review 509For Further Reading 509Problem s 5l0
Air Gourpet Case Study:
Java Rapld Prototype 521
A p p e n d lx E
A ir G ourm et C ase Study:
Structured System s A nalysis 522
A p p e n d lx F
A ir G ourm et C ase Study:
Software Project M anagem ent
Plan 529
A p p e n d lx *
A ir G ourm et C ase Study:
Object-ori ented Analysis 534
A p p e n d lx H
A ir G ourm et C ase Study:
D esignforc + + Im plem entation 535
A p p e n d lx I
A ir G ourm et C ase Study:
Designforlavalm plem entation 560
A p p e n d lx J
A ir G ourm et C ase Study:
Black-Box Test C ases 582
A p p e n d lx K
A ir G ourm et C ase Study:
C + + Source C ode 588
A p p e n d lx k
A ir G ourm et C ase Study:
Java Source Code 589
Bibliography 590
A uthor Index 617
Subjectlndex 623
Trang 8P REFM :
The fourth edit ion of this book was publ ished in two versions, one wit h code exampl es present ed in C++
and the other in Java H owever, software engineering essentially is language independent, and in any event,there are relatively few code examples in this book Accordingly, in this edition, l m ade every effortto :11100thover language-dependent details and ensure that the code exam ples are equally clear to C++ and Java users
For exampl e, instead of using cout for C++ out put and System out printl n for Java output, l util ized the pseudocode instruction print (The one exception is the new case st - udy, where complete impl ementation details are given in 1 70t h C++ and Java ) Therefore, the f if th edi tion can be considered a unihcat ion of the
two versions of the fourth edition
Pedagogics is the theme of the fifth edition All through this book, l added m aterial to highlight keyaspects of each chapter For exam ple, there are How to Perform boxes that sum m arize im portant techniquessuch as object-ori ent ed anal ysis and object-oriented design ln addition, new synopses and outl ines assist 1 70ththe st-udent and the instructor Also, to provide additional m aterial on how to perform the various techniques
of software engineering, the case st-udy in this edition is presented in greater detail than in the fourth edition.The fourth edition included a chapter entitled ttl-eam s and the Tools of Their Trade.' As part of the stress
on pedagogics in this new edition, the m aterial has been updated and split into two, to focus m ore clearly oneach of the separate underlying topics ln this edition, Chapter 4 is devoted to teams, w hereas the tools used
by softw are engineers are described in Chapter 5
As before, l include 1 70th classical and object-orient ed material, notwithst anding t he virt - ually unanimous agreement that the object-oriented paradi gm is superior to t he classical (structured) paradi gm M y decision
m ight surprise som e readers', surely an up-to-date software engineering textbook should describe only theobject-oriented paradigm and treat the classical paradigm, at best , as a histori cal footnot e.
This is not the case Despi te the widespread ent husiasm for the object-ori ent ed paradigm and the rapidlyaccum ulating evidence of its superiority over the classical paradigm , it nevertheless is essential to include
m aterial on the classical paradigm There are three reasons for this First, it is im possible to appreciatewhy object -oriented technol ogy is superior t o classical technology without full y understandi ng the classical approach and how it differs from the object-oriented approach.
The second reason why 1 70th the classical and object-oriented paradi gms are included is that technology transfer is a slow process The vast majorit y of soft ware organizat ions have not yet adopted the object-orientedparadigm lttherefore is likely that m any of the st-udents who use this book willbe em ployed by organizationsthat still use classical software engineering techniques Furtherm ore, even if an organization is using theobject-oriented approach for developing new software, existi ng software still has to be maintai ned, and this legacy soft ware is not object orient ed Therefore, excluding classical material woul d not be fai r to many ofthe st-udents who use this text
A third reason for including 170th paradigm s is that a student who is em ployed at an organization sidering the transi tion to object-ori ent ed technol ogy will be able to advise that organi zation regarding 1 70ththe strengths and the weaknesses of the new paradigm So, as in the previous edition, the classical andobject-oriented approaches are compared, contrasted, and anal yzed.
con-The fourth edition was the first software engineering textbook to utilize the Unified M odeling Language
(UML), which was i ntroduced shortl y before that edi tion was publ ished ln t he interveni ng t hree years, UM L
has been form ally standardized and becom e so widely used that any textbook that does not use UM L to
Trang 9xvI PREFACE
describe object-oriented analysis and desi gn immedi at ely woul d be obsolete fore, l conti nue to use UML for object-oriented analysis and object-ori ented design,
There-as well as wherever diagrams depict objects and their int en- elationshi ps.
Another then-new topic introduced into the fourth edition was design patterns
As with UM L, design patterns now are part of m ainstream software engineering The
m aterial on design patterns therefore has been retained and strengthened
A new topi c in this edition is extreme programming (XP) XP still is controversial,
but l feel that st-udents need an overview of the topic so they can decide for them selveswhether XP is merely a fad or a genuine major breakt hrough i n software engineering.
ln the previous edition, l stressed the im portance of docum entation,m aintenance,reuse, portability, testing, and CASE tools ln this edition, all these concepts arestressed equally firm ly lt is no use teaching students the latest techniques unless theyappreciate the im portance of the basics of software engineering
As in the fourt h edition, part icular attention is paid to object-ori ent ed l ife-cycle models, object -oriented analysis, object-oriented design, management impl icat ions
of the object-orient ed paradigm, and the testing and mai nt enance of object-oriented soft ware Metrics forthe object-ori ent ed paradi gm also are incl uded ln addit ion, there are many briefer references to objects, a paragraph or even only a sentence i n l ength The reason is that the object-oriented paradi gm is not just concerned with how thevarious phases are performed but rather perm eates the w ay we think about softwareengi neeri ng Object technology pervades this book.
The softw are process still is the concept that underlies the book as a whole Tocont rol the process, we have to be able to measure what is happening to the project.Accordingly,the em phasis on m etrics is retained W ith regard to process improvem ent,
the material on the capabil ity mat - urit y model (CMM ) and ISO/IEC 15504 (SPICE)
has been updated, and m aterial on ISO/IEC 12207 has been added
As in the fourth edition,this book contains over 600 references l selected currentresearch papers as well as classic articles and books whose message rem ains freshand relevant There is no question that software engineering is a rapidly m oving fieldand that st-udents therefore need to know the latest results and where in the literature
to find them At the sam e tim e, today's cutting-edge research is based on yesterday'struths, and l see no reason to exclude an older reference if its ideas are as applicabletoday as they originally were
W ith regard to prerequisites, it is assum ed that the reader is familiar with onehigh-level programm ing language such as Pascal, C, C++, Ada, BASIC, CO BO L,FORTRAN, or Java ln addition, the reader is expected to have taken a course in datastruct -ures.
H ow THz FIFTH EpITIoN Is @ ROANIIZP
Like the fourth edition of this book,the fifth edition is w ritten for 170th the traditionalone-sem ester and the newer two-semester software engineering curriculum ln the
tradit ional one-semest er (or one-quart er) course, the instructor has to rush through
the theoretical m aterial to provide the students the knowledge and skills needed for
Trang 10m etrics, and testing', each chapter of Part 2 contains a section on CASE tools forthat phase, a section on m etrics for that phase, and a section on testing during thatphase Part l is kept short to enable the instructor to start Part 2 relatively early in
the semester Furthermore, the last two chapters of Part l (Chapters 8 and 9) may be
postponed and taught in parallelw ith Part 2 The class then can begin developing theterm project as soon as possi bl e.
W e t-urn now to the two-semester software engineering cuniculum M ore and
m ore com puter science and com puter engineering departm ents are realizing that theoverwhelm ing preponderance of their graduates find em ploym ent as softw are en-
gineers As a resul t, many coll eges and uni versiti es int roduced a two-semester (or two-quarter) soft ware engineering sequence The first course is largel y t heoret ical (but al m ost always there is a smal l project of some sort) The second course consists
of a major team-based term project, usuall y a capstone project W ' hen the tenn project
is in the second course, there is no need for the instructor to rush to start Part 2
Therefore, an instructor teaching a one-semest er (or one-quarter) sequence using the fift h edition covers most of Chapters l through 7, then starts Part 2 (Chapters 10 through 16) Chapters 8 and 9 can then be taught i n parallel wi th Part 2 or at t he end
of the course, whil e the st - udents are i mplementing t he t erm project W' hen teachingthe two-sem ester sequence,the chapters of the book are taught in order', the class now
is fully prepared for t he team-based term project t hey wil l develop i n the foll owingsem ester.
To ensure that the key software engineering techniques of Part 2 truly are derstood, each is presented twice First, whenever a technique is introduced, it isillustrated by means of the elevator problem The elevator problem is the correct sizefor the reader to be able to see the technique applied to a com plete problem , and ithas enough subtleties to highlight70th the strengths and weaknesses of the techniquebeing taught Then, the relevant portion of the new case study is presented toward theend of each chapter This detailed solution provides the second illustration of eachtechnique
Trang 11;t5eIII PREFACE
tied to the relevant chapter For exam ple, design is the topic of Chapter l3, so in thatchapter the component of t he term project is concerned with soft ware desi gn By breaking a large project into small er, well-dehned pi eces, t he instructor can m onitor the progress of the cl ass more closely The structure of the term project is such that
an instructor may freely apply the l 6 components to any other project that he or shechooses
Because this book is written for use by graduate st-udents as w ell as upper-classundergraduates, the third type of problem is based on research papers in the softwareengineering literat-ure ln each chapter, an im portant paper has been chosen',w hereverpossible, a paper related to object -oriented software engineeri ng has been select ed.The student is asked to read the paper and answer a question relating its contents
O f cotlrse, the instructor is free to assign any other research paper', the For FurtherReading section atthe end of each chapter includes a wide variety of relevant papers.The fourth type of problem relates to the case study This type of problem was firstintroduced in the third edition in response to instructors who feel that their st-udents
learn m ore by m odifying an existing product than by developing a product fromscratch M any senior softw are engineers in the industry agree with that viewpoint.Accordingly, each chapter in which the case study is presented has at least threeproblem s that require the st-udent to m odify the case st-udy in some way For exam ple,
in one chapter the st-udent is asked to redesign the case st-udy using a different designtechnique from the one used for the case study.ln another chapter,the st-udent is askedwhat the effect would have been of performing the steps of the object-oriented analysis
in a different order To m ake it easy to m odify the source code of the case study, it is
available on t he World Wide Web at - mhhe com/engcs/compsci /schach The
w eb site also has transparency m asters for all the figures in this book, as well as acomplete set of Powerpoint lecture notes
The Instructor's Solution M anual contains detailed solutions to all the exercises,
as well as to t he term project The Inst ruct or' s Sol ution Manual is available from
M cGraw -l-lill
A txxow kzpoM zxTs
l am indebted to those w ho review ed this edition, including'
An' in Agah (Uni versi ty of Kansas) Thaddeus R Crews, Jr (W estern Kentucky University) Eduardo B Fernandez (Florida Atlanti c University)
M ichael Godfrey (Cornell Uni versit y) Scott Hawker (Uni versi ty of Al abama) Thomas B Horton (Florida Atlantic Uni versity) Gail Kaiser (Col umbia Uni versit y)
Laxmi kant V Kal e (Uni versi ty of lll inois) Helene Kershner (University of Buffal o) Chung Lee (California Stat e Polyt echnic University at Pomona)
Trang 12PREFACE xIx
Ri chard A Lejk (Uni versi ty of North Carol ina, Charlotte) Susan A M engel (Texas Technol ogical University) David S Rosenblum (Uni versi ty of Cal ifornia at lrvine) Shmuel Rot enst reich (George W ashi ngton Uni versit y)
W endel Scarbrough (Azusa Pacifi c University) Geral d B Sheble (lowa State)
Jie W e (City University of New York) David W orkman (Uni versi ty of Cent ral Florida)
l thank two individuals who m ade contributions to earlier books First, Jeff Grayonce again m ade num erous insightful suggestions ln particular, l am grateful for his
m any ideas regarding Chapter 8 Also, he once again is a coauthor of the Instructor'sSolution M anual Second, m y son David has m ade a num ber of helpful contributions
to the book and again is a coauthor of the Instructor's Solution M anual
Si nce l 999, l have been i nvolved in joint research wi th Dr Ami r Tomer ofRAFAEL and the Technion, lsrael lnstitute of Technology The papers we wrotetogether are nom inally on m aintenance However, the issue underlying our research
is the nature of software engineering A direct consequence of working with Am ir
is that l gained new insight into software engineering l have incorporated m any ofthese ideas into this edition
Turning now to my publisher, M cG raw -l-lill, l am truly grateful to executiveeditor Betsy Jones and developm ental editor Emily Gray for their assistance fromstart to finish l particularly appreciate their suggestions regarding giving equal stress
to 1 70th C++ and Java in an i nt egrated vol ume Ri ck Hecker was the i deal project
m anager in every w ay l w as m ost fortunate to have Gnom i Schrift G ouldin as thecopy editor for this book She greatly improved the readability of m y m anuscript, and
l am grateful for her m any suggestions
l would like to thank the m any instructors from all over the world who sent m ee-m ail concerning the fourth edition l am exceedingly appreciative of their sugges-tions, com m ents, and criticism s l look forw ard with anticipation to receiving instruc-tors' feedback on t his edit ion also M y e-mail address i s srs@vuse vanderbi l t edu.
Students, too, have been m ost helpful First, l thank m y students at Vanderbiltfor their m any questions and com m ents, 170th inside and outside the classroom l also
an m ost grateful for the provocative questions and constructive suggestions e-m ailed
m e by st-udents from all over the world l look forward keenly to st-udent feedback onthis edition, too
Finally, as alw ays, l thank m y family for their continual support W hen l startedwriting books, my lim ited free tim e had to be shared between m y young children and
my current book project Now that my children are adul ts and work with me on mybooks, writing has becom e a fam ily activity For the tenth tim e, it is m y privilege todedicate this book to m y wife, Sharon, and m y children, David and Lauren, with love
Stephen R Schach
Trang 13R A R +
I E E I
Yhe fi rst nine chapt ers of this book play a dual rol e They int roduce the reader to the software process, and
they also provide an overview of the book The software process is the way we produce software lt starts withconcept exploration and ends when the product is finally decom m issioned During this period, the productgoes through a series of phases such as requirem ents, specification, design, implementation, integration,
m aintenance, and ultimately, retirement The softw are process also includes the tools and techniques we use
to develop and m aintain softw are as well as the software professionals involved
ln Chapter 1 Tçrlnhe Scope of Software Engineering,'' it is pointed out that techniques for software duction must be cost effective and prom ote constructive interaction between the members of the softw areproduction team The import ance of objects is stressed throughout the book, starting wi th t hi s chapter.
pro-çf'he Software Process'' is the title of Chapter 2 Each phase of the process is discussed in detail M anyproblem s of software engineering are described, but no solutions are put forward in this chapter Instead, thereader is informed where in the book each problem is tackled ln this w ay, the chapter serves as a guide to therest of the book The chapter concludes with m aterial on software process im provem ent
A variety of different software life-cycle m odels are discussed in detail in Chapter 3, ':software Life-cycle
M odels.' These include tch t Fat - erfal t- model th id rotot ing mod l t e ' remental model , ey-tr.q.! s
I zr - tyla urn- uing, the synchroni ze-and-stabi lize model and t he spi ral model To enabl e t he reader t o deci de on an appropri at e li fe-cycle model for a specihc project, the various l ife-cycle model s are compared and contrasted Chapter 4 is enti tled çTeams ' Today' s projects are too large to be completed by a si ngl e indivi dual wit hin
t he given ti me constrai nts Instead, a team of software professi onals collaborate on the project The major
topic of this chapter is how team s should be organized so that team mem bers work togethcr productively.Various different ways of organizing team s are discussed, including dem ocratic teams, chief program merteams, synchronize-and-stabilize team s, and extrem e program ming team s
Chapter 5 discusses ''The Tools of the Trade.' A software engineer needs to be able to use a number ofdifferent tools, both theoretical and practical In this chapter, the reader is introduced to a variety of softwareengineering tools One such tool is stepw ise refinem ent a technique for decom posing a large problem
into smaller, m ore tractable problem s Another tool is cost-benetit analysis, a technique for determ iningwhethera softwareproject is fnancially feasibl e Then, computer-aided software engineering (CASE) tools are
Trang 14x p A * T , Infrodutgion 'o soe are Engineering
r
is a software product that assists software engi neers to de- l descri bed A CASE tool
l vel op and maintain software
.Fi nall y, t o manage the software process it is necessary t
to measure val ious quanti ties to determine whet her the project is on t rack These t
measures (metrics) are criti cal t o the success of a project t The last two topi cs of Chapter 5, CASE tools and metrics, are t reat ed in detai l b
in Chapters 10 through 16, which describe the specific phases of the software life jcycle There is a discussion of the CA SE tools that support each phase, as w ell as a '
description of the m etrics needed to m anage that phase adequately @
An im portantthem e of this book is that testing is not a separate phase to be carried
out j ust before del iveri ng the product to t he cl ient or even at the end of each phase
of the software life cycle Instead, testing is performed in parallel with all softwareproduction activities ln Chapter 6, ç4lksting,' the concepts underlying testing arediscussed The consideration of testing techniques specihc to individual phases of thesoftware life cycle is defen'ed until Chapters 10 through 16
Chapter 7 is entitl ed ç t From Modules t o Objects ' A detail ed explanati on is given
of classes and objects, and why the object-ori ented paradigm i s proving t o be moresuccessfulthan the structured paradigm The concepts of this chapter then are utilized
i n the rest of t he book, part icul arl y Chapt er l2, ' çobject-oriented Analysi s Phase, ' and in Chapter 13, ' ' Design Phase, ' in whi ch object-oriented design i s presented.
The ideas of Chapter 7 are extended in Chapter 8, t'Reusability, Portability, andlnteroperability.'' It is important to be able to w rite reusa'ble software that can beported to a variety of different hardware and run on distributed architectures such
as client-server.The lirst part of the chapter is devoted to reuse', the topics include
a variety of reuse case studies as wel l as reuse strategi es such as object-ori ented patterns and frameworks Portabilit y is the second major topic; portabili ty st rategiesare presented in some depth The chapter concludes with interoperability topics such
as CORBA and COM A recuning theme of this chapter i s t he rol e of objects i nachieving reusability, portability, and interoperability
The last chapter in PM 1 iChapter 9, 4iplanning and Estim ating.'' Before starting
a software project, it is essential t o pl an t he enti re operation in detail Once the project begi ns, management must cl osely monitor progress not ing deviations fromthe plan and taking corrective action w here necessary Also, it is vital that the client
be provided accurat e estimates of how l ong the project wi ll take and how much it willcost Different estim ation techniques are presented, including function points andCOCOM O II A detail ed description of a soft ware project management plan i s given.
The m aterial of this chapter is utilized in Chapters 1 1 and 12 W hen the classical
paradigm i s used, major planni ng and estimating activi ties take place at the end of the
specification phase, as explained in Chapter 1 l W hen software is developed using theobject-oriented paradigm, t his planning takes pl ace at the end of the object-oriented anal ysis phase (Chapter 12).
Trang 15e n - > * - <
E t E F F E I EE I
A well-known story tells of an executi ve who recei ved a computer-generated bil l for $0 00 After having a
good laugh with friends about 'Eidiot computerss''the executive tossed the bill away.A m onth later a similar billanived,this tim e m arked 30 days Then came the third bill.The foul'h bill arrived a m onth later,accompanied
by a message hinting at p.pljible- le-gal acti on i f the bill for $0 00 was not paid at once.
The fifth bill, m arked 120 days, did nothint at anything- the m essage was rude and forthright,threateningall m anner of legal actions if the bill was not imm ediately paid Fearful of his organization's credit rating inthe hands of this mania- ca -l m achine, the executive called an acquaintance who was a softw are engineer andrelated the w hole son'y story Trying not to laugh, the software engineer told the executive to m ail a check
for $0.00 This had the desired effect, and a receipt for $0.00 was received a few days later The executivecarefully hl ed it away in case at some future dat e the eomputer might al lege that $0 00 was still owing.
This well-known story has a less well-know n sequel A few days later the executive was summ oned byhis bank m anager The banker held up a check and asked, ''ls this your check?''
The executive agreed that it was
çW ould you m ind telling m e why you wrote a check for $0.00?5' asked the banker
So the w hole story was retold W hen the executive had finished, the banker turned to him and she quietly
asked, E-lave you any idea what your check for $0.00 did to our computer system?''
A computer professional can l augh at this story, a lbe -tt somewhat nervously After all, every one of us has
designed or implemented a product that, in its original form , would have resulted in the equivalent of sending
dunni ng letters for $0 00 Up to now, we have al ways caught this sort of fault dul ing testing But our laughter
has a hollow ring to it, because at the back of our m inds is the fear that som eday w e will not detect the faultbefore the product is delivered to the customer
A decidedly less hum orous softw are fa was detected on N ovem berg 1979 The Strategic Aircomm and
had an al el ' scramble when the worldwide military command and cont rol system (W W MCCS) computer network report ed that the Soviet Uni on had launched missi les aimed toward the Unit ed St ates LNeumann,
19801 W hat actually happened was that a si mulated attack was interpreted as the real t hing, just as in t he
m ovie WarGames som e 5 years later Although the U.S Departmentof Defense understandably has not givendetails about the precise m echanism by w hich test data were taken for actual data, it seem s reasonable toascribe the problem to a softw are fault Either the system as a whole was not designed to differentiate betweensimulations and reality, or the user interface did not include the necessary checks for ensuring that end users
3
Trang 16(Leveson and Turner, 19931 The cause was a fault in During the Gulf W ar, the United States shipped Pa- 7
the control software triot missiles to lsrael for protection against the Scuds
D uring the 199 1 G ulf W ar, a Scud m issile pen- lsraeli forces detected the tim ing problem after only 8
etrated the Patriot antim issl e shield and struck a hours and im m ediately reported ito the m anufpcturerbarracks near Dhahran, Saudi Arabia In all, 28 Am eri- in the United States The m anufacturer corrected thecans were killed and 98 wounded.The software for the fault as quickly as it could but, tragically, the new soft-Patri m issile contained a cum ulative tim ing fault.The w are arrived the day after the direct hit by the Scud
Patriot was designed to operate for only a few hours at lM ellor, 19941
of the system would be able to distinguish fact from fiction ln other words,a softw arefault, if indeed the problem was caused by softw are, could have brought civilization
as we know it to an unpl easant and abrupt end (See the Just in Case You W anted to Know box above for information on disast ers caused by other software faults )
W hether we are dealing w ith billing or air defense, m uch of our software isdelivered late,overbudget,and with residualfaults.Software engineering is an attem pt
to solve these problem s In other w ords, software engineering is a discipline whoseaim is the production of fault-free software,delivered on tim e and within budget, thatsatishes the user's needs Furthermore, the software m ust be easy to m odify w henthe user's needs change To achieve these goals, a software engineer has to acquire abroad range of skills, both technical and m anagerial These skills have to be appliednotjust to programming but t o every phase of software production, from requi rements
to m aintenance
The scope of software engineering is extrem ely broad Som e aspects of softwareengineering can be categorized as m athem atics or computer science', other aspectsfall into the areas of econom ics, m anagem ent, or psychology To display the w ide-reaching realm of software engineering, five different as ects now will be examined
la H ISTO RItA: A spEtTs
Trang 17Aa HISTORICAL A SPK TS 5put on the sam e footing as traditional engineering disciplines, a NATO study group in
1967 coi ned the term software engineeri ng The claim that buil dlng software is simi lar
to other engineering tasks was endorsed by the l968 NATO Softw are Engineering
Conference held in Garmisch, Germany (Naur Randell, and Buxton, 19761 This
endorsement is nottoo surprising', the very name of the conference reflected the belief
that softw are production should be an engineeringlike activity A conclusion of theconferees was that software engineering should use the philosophies and paradigm s
of establi shed engineeri ng discipli nes to sol ve what they termed the software crisis;
namely,that the quality of software generally was unacceptably low and thatdeadlinesand cost lim its were not being m et
Despite m any software success stories, a considerable am ount of software still
is being delivered late, over budget, and with residual faults That the software crisisstill is with us, over 30 years later, tells us two things First, the software productionprocess, while resem bling traditional engineering in many respects,has its own uniqueproperties and problem s Second, the software crisis perhaps should be renam ed thesof- are depressi on, i n vi ew of its long duration and poor prognos - is.
Certainly, bridges collapse less frequently than operating system s W hy thencannot bridge-building techniques be used to build operating system s? W hat theNATO conferees overlooked is that bridges are as different from operating system s
as chalk is from cheese
A major difference between bri dges and operating systems li es i n the atti tudes ofthe civil engineering com m unity and the software engineering com m unity to the act
of collapsing W hen a bridge collapses as the Tacom a Narrows bridge did in 1940,the bridge alm ost always has to be redesigned and rebuilt from scratch The originaldesign was faulty and posed a threat to hum an safety', certainly, the design requiresdrastic changes ln addition, the effects of the collapse in almost every instance willhave caused so much dam age to the bridge fabric that the only reasonable thing is
to demolish w hat is left of the faulty bridge, then com pletely redesign and rebuild
it Furtherm ore, other bridges built to the sam e design have to be carefully inspectedand in the worst case, redesigned and rebuilt
ln contrast, an operating system crash is notconsidered unusualand rarely triggers
an im mediate investigation into its design W hen a cN sh occurs, it m ay be possible
èW h t caused the simply to reboot the system i n the hope t hat the set of cumstances t a
crash w ill not recur This m ay be the only rem edy if, as often is the case, there is noevidence as to the cause of the crash The dam age caused by the crash usually will
be minor: a database partially corrupted, a few files lost Even when dam age to the
file system is considerable, backup data often can restore the tile system to a state not
too far rem oved from its precrash condition Perhaps, if software engineers treated
an operating system crash as seriously as civil engineers treat a bridge collapse, theoverall level of professionalism within software engineering would rise
Now consider a real-time system , that is,a system able to respond to inputs from
the realworld as fast as they occur An example is a com puter-controlled intensive careunit Irrespective of how m any medical emergencies occur virtually simultaneously,the system m ust continue to alert the medical staff to every new em ergency withoutceasing to m onitor those patients whose condition is critical but stable In general,the failure of a real-tim e system , whether it controls an intensive care unit, a nuclear
Trang 18l t u A p T : R l * The stope ol soe ox Engineering
I)reactor, or the climati c conditions aboard a space station, has signi ficant effects M ost l1.real-tim e system s, therefore, include som e elem ent of fault tolerance to m inim ize the l
l
effects of a failure That is, the system is designed to attem pt an autom atic recovery à
The very concept of faul t tolerance highlights a major di fference between bridgesand operating system s Bridges are engineered to withstand every reasonably antici-pated condition: high winds, flash ioods, and so on A n implicit assumption of alltoo
m any software builders is that we cannot hope to anticipate al1 possible conditions
t ha t he of t war e mus t wi t hs t nd, s o we mus t des i gn our of t wa r o t y t mi ni - j
mi ze he damage hat an una nt i i pa t ed ondi t on mi ght a us e.In other words, bridges !
are assumed to be perfectl y engineered ln contrast, most operating systems are as- I
sumed to be imperfectly engi neered; many are designed i n such a way that rebooti ng i
is a sim ple operation that the user m ay perform whenever needed This difference !
is a fundamental reason why so much softw are today cannot be considered to be )
l mi ght be suggest ed t hat t hi s di f er ence i s onl y t empor my Af t er al l we have 1
been building bridges for thousands of years, and we therefore have considerable
i experi ence and experti se in t he types of conditions a bri dge must withstand.W e have
l y 50 year s of experi ence wi t h oper at i ng syst ems Sur el y wi t h mor e experi ence, i on
the argument goes we will understand operating system s as w ell as we understand ?bridges and so eventually w ill be able to construct operating system s thatw ill not fail iThe flaw in this argum ent is that hardware, and hence the associated operating I
is growing in complexity faster than we can master it ln the 1960s, we isystem
had mult iprogrammi ng operating systems' , in the l970s, we had to deal with vi rt ual 1
m em ory', and now, we are attempting to come to term s with m ultiprocessor and !
distri buted (network) operating syst ems Unti l we can handl e the complexity caused ' '
by the interconnections of the various components of a software product such as an :.
operating system , we cannot hope to understand it fully) and if w e do not understand
Part of the reason for the complexity of software is that, as it executes, softw are j
oes hrough di scr et e s t at es Changi ng even one bi t causes t he sof t ware t o change j g
st at e The t ot al number of s uch s t at es can be vas t, and many of t hem have not been ô
considered by the developm ent team If the software enters such an unanticipated I
he result often is software fai lure ln contrast, bridges are continuous (ana- j State, t
log) systems They are described usi ng cont inuous mathemati cs, essenti all y calculus.
However, discrete system s such as operating systems have to be described using
dis-l
crete mathemati cs gparnas, 19901 Software engineers therefore have t o be ski lled in I
ldiscrete m athem atics,a prim ary tool in trying to cope with this com plexity. l
A second major difference between bridges and operati ng syst ems is mainte- lnance M aintaining a bridge generally is restricted to painting it, repailing m inor
cracks, resurfacing the road, and so on A civil engineer, if asked to rotate a bridgethrough 90O or to m ove it hundreds of m iles, would consider the request outrageous
Trang 194.2 EcoNoMIC A :PK TS ycode of an operating system to be rew ritten over a s-year period, especially if it is
ported to new hardware But no engineer would consent to replacing half a bridge',safety requirements w ould dictate thata new bridge be built The area of m aintenance,therefore, is a second fundam ental aspect in w hich software engineering differs fromtraditional engineering Further m aintenance aspects of software engineering are de-scribed in Section l.3 But first, econom ic-oriented aspects are presented
1 Q KtoNoM lt A spetTs
An insight into the relationship between softw are engineering and com puter sciencecan be obtained by com paring and contrasting the relationship between chem icalengineering and chemistry After all, eom puter science and chemistry are both sci-ences, and both have a theoretical component and a practical com ponent In the case
of chemistry, the practical component is laboratory work; in the case of com puterscience, the practical com ponent is program ming
Consider the process of extracting gasoline from coal During W orld W ar lI, theGerm ans used this process to m ake fuel for their war machine because they largelywere cut off from oil supplies W hile the antiapartheid oil em bargo was in effect, thegovernm ent of the Republic of South A frica poured billions of dollars into SA SOL
(an Afrikaans acronym standing for t 'South African coal into oi1 '' ) About half of
South Africa's liquid fuel needs were m et in this way
From the viewpoint of a chem ist, there are m any possible ways to convert coal
into gasoline and all are equally im portant After all,no one chem ical reaction is m oreimportantthan any other But from the chem icalengineer's viewpoint,atany one tim e
there is exactly one important mechanism for synthesizing gasoline from coal- thereaction that is econom ically the m ostattractive In other words, the chem icalengineereval uates a1l possi ble reactions, then rejects all but that one reacti on for which thecost per liter is the lowest
A sim ilar relationship holds between computer science and software engineering
The computer scientist investigates a variety of ways to produce softw are, som e goodand som e bad But the software engineer is interested in only those techniques thatmake sound econom ic sense
For inst ance, a software organizat ion currentl y using coding technique C' L l d
di scovers that new coding technique, C' L e w, would result in code bei ng produced i n
only nine-tenths of the time needed by C'rold and, hence, at nine-tenths of the cost
Common sense seems to dictate that C' L e w is the appropriate techni que t o use In fact,
although com mon sense certainly dictates that the faster technique is the technique
of choice, the econom ics of software engineering m ay im ply the opposite
One reason is the cost of introducing new technology into an organization The
fact t hat coding i s 10 percent faster when technique C' Lew is used may be l ess i portant than the costs incurred in introducing C'Lew into the organization It may benecessary t o complete two or three projects before recoupi ng the cost of t raining.
Trang 20m-a t u A p T : R 4 The stope of soe are Engineering
Also, while attending courses on C'Lew, software personnel are unable to do
produc-tive work Even when they return, a steep learning curve m ay be involved',it m ay take
months of pract ice wi th C' L ew before soft ware professionals become as profi ci ent with C' L ew as they currentl y are with C' L l d Therefore, ini tial projects using C' L ew may take far longer to complete than if t he organizati on had continued to use C' Ll d.
A ll these costs need to be taken into account when deciding whether to change to
C' Lew.
A second reason why the econom ics of softw are engineering may dictate that
C' rou be retained is the maint enance consequence Coding techni que C' L ew indeed may be 10 percent faster than C' L l d and t he resul ting code may be of comparable
quality from the view point of satisfying the client's current needs But the use of
technique C' Lew may resul t in code t hat i s diffi cult to maintain, maki ng the cost of C' Lew higher over the li fe of the product Of course, if the software developer is not responsible for any maintenance, then, from the viewpoint of just t hat developer, C' Lew i s a most attracti ve proposition After al l, use of C' L ew would cost 10 percent
less The client should insist that technique Crrold be used and pay the higher initialcosts w ith the expectation that the total lifetime cost of the software will be lower
U nfortunately, often the sole aim of both the client and the software provider is
to produce code as quickly as possible The long-term effects of using a particulartechnique generally are ignored in the interests of short-term gain Applying econom icprinciples to software engineering requires the clientto choose techniques that reducelong-term costs
W e now consider the im portance of m aintenance
l.a M A INTENA NtE A spetTs
The series of steps that software undergoes, from concept exploration through final ;irement, is termed its I qfe cycl e During this time, t he product goes t hrough a l
seri es of phases: requirements, specil icati on design, implement ati on, i ntegration, I
m aintenance, and retirem ent Life-cycle m odels are discussed in greater detail inChapter 3', the topic is introduced at this point so that the concept of m aintenance can
be dehned
Until the end of the 1970s, m ost organizations were producing software using
as their life-cycle model what now is termed the water fall model There are manyvariations of this m odel,butby and large,the product goes through seven broad phases
These phases probably do not correspond exactly to the phases of any one particularorganization, but they are sufhciently close to m ost practices for the purposes ofthis book Sim ilarly, the precise name of each phase varies from organization toorganization The nam es used here for the various phases have been chosen to be asgeneral as possible in the hope that the reader will feel com fortable w ith them Foreasy reference, the phases are summ arized in Figure 11, which also indicates the