Fundamentals
`of Software
`Engineering
`
`Carlo Ghezzi
`Politecmco di Milar«>, Milar«>, Iflliy
`
`Mehdi Jazayeri
`Hewlett-Packard Laboratories, Palo Alto, California and Pisa, Iflliy
`
`Dino Mandrioli
`Politecnico di Milano, Milano, Italy
`
`PRENTICE HALL, l]pper Saddle River, NJ 07458
`
`IBM-1008
`Page 1 of 83
`
`

`
`L1brary of Congress Catalog1ng-tn-PUbl1Cat1on Oat~
`
`Ghezz1. Carle.
`Funda•entals of software ~ng1neer~ng 1 by carle Ghezz1, Mehd\
`.Jazayer1. D1no Manclr1ol1.
`c•.
`p.
`Inc1uclas b1bl1ograph1cal referenceS and 1nclex.
`ISBN 0-13-820432-Z
`1. Software eng1near1ng.
`01no.
`III-. THla.
`QA76. 768.G47
`1991
`005.1--dc2.D
`
`I. Jazayert, Mehdt.
`
`II. Mandr1ol1,
`
`90-20198
`CIP
`
`Editorial/prodUction supervision: Joe Scordato
`Cover design: Bruce Kenselaar
`Cover Art: Paolo Uccello (15th Century Florentine)
`Manufacturing buyers: Linda Behrens and Patrice Fracdo
`Acquisitions Editor: Marcia Horton
`
`The author and publisher of this book have used their best efforts in preparing this book. These efforts include
`the development, reseafch and testing of the theories and programs to determine their effectiveness. The author
`and publisher make no warranty of any kind, expressed or implied, with regard to these programs or the documen(cid:173)
`tation contained in this book. The author and publisher shall not be liable in any event for incidental or consequential
`damages in connection with, or arising out of, the furnishing, performance, or use of these programs.
`
`1991 by Prentice-Hall, Inc.
`A Simon & Schuster Company
`Upper Saddle River, New Jersey 07458
`
`AU rights reserved. No part of this book may be
`reproduced, in any form or by any means,
`without permission in writing from the publisher.
`
`Printed in the U~t~ ~i.Z 2 America
`
`10 9 8
`
`ISBN-0-13-820432-2
`
`Prentice-Hall International {UK) Limited, London
`Prentice-Hall of Australia Pty. Limited, Sydney
`Prentice·Haii.Canada Inc., Toronto
`Prentice-Hall Hispanoarneticana, S.A.,lvlexi'co
`Prentice-Hall of India Private Limited, New Delhi
`Prentice-Hall of Japan, Inc., Tokyo
`Simon & Schuster Asia Pte. Ltd., Singapore
`Editora Prentice-Hall do Brasil, Ltda., Rio de Janeiro
`
`TRADEMARK INFORMATION
`
`A~a is a registered trademark of the U.S. Government, Ada
`Joint Program Office.
`Eiffel is a trademark of Interactive Software Engineering, Inc.
`Kee is a registered trademark of InteltiCorj>, Inc.
`Macintosh, MacDraw, QuickDraw, MacProject are registered
`trademarks of Apple Computer, Inc.
`Software Through Pictures is a registered trademark of Interactive
`Development Environments, Inc.
`STATEMATE is a registered trademark of i-Logix, Inc.
`The teamwork logo, teamwork/SA. teamwork/SD, teamwork/
`ACCESS, reamwork/RT are registered trademarks; teamwork/
`IM, teamwork/ ADA are ttademarksofCadreTechnotogies, Inc.
`UNIX is a registered trademark of AT&T (Bell Laboratories).
`X Window System is a trademark of the Massachusetts
`Institute of Technology.
`
`· Ronald Williams Library ,
`Bort.heastern Illinois Univers1'!}1
`
`Contents
`
`PREFACE xi
`
`1
`
`SOFTWARE ENGINEERING: A PREVIEW 1
`
`1.1
`
`1.2
`
`1.3
`
`1.4
`
`1.5
`
`1.6
`
`1.7
`
`The Role of Software Engineering in System Design
`
`2
`
`A History of Software Engineering 3
`
`The Role of the Software Engineer 5
`
`The Software Life Cycle 6
`
`The Relationship of Software Engineering to Other 8
`Areas of Computer Science
`1.5.1 Programming Languages, 8
`1.5.1 Operating Systems, 10
`1.5.3 Data Bases, 10
`1.5.4 Artificial Intelligence, 11
`1.5.5 Theoretical Models, 12
`
`The Relationship of Software Engineering to Other 13
`Disciplines
`1. 6.1 Management Sci'ence. 13
`1.6.2 Systems Engineering, 13
`Concluding Remarks 14
`Bibliographic Notes 14
`
`2 SOFTWARE: ITS NATURE AND QUALITIES 17
`
`2.1
`,_.
`
`2.2
`
`, Cla~ifjcation Of Spftware Qualities 18
`-2.I~J, ¥Exte.ma/ Versus Interntt(,Qu~/!ties, 18
`2.1.2 Product and Process Qualities, 19
`Representative Qualities 19
`
`iii
`
`IBM-1008
`Page 2 of 83
`
`

`
`iv
`
`Contents
`
`Contents
`
`v
`
`Correctness, Reliability, and Robustness, 19
`2.2.1
`2.2.2 Performance, 22
`2.2.3 User Friendli'ness. 24
`2.2.4
`Verifiability, 25
`2.2.5 Maimainability, 25
`2.2.6 Reusability, 28
`2.2. 7 Portability, 30
`2.2.8 Understandability, 31
`2.2.9
`Interoperability, 3/
`2.2.1 0 Productivity, 32
`2.2.1 1 Timeliness, 33
`2.2.12 Visibility, 35
`Quality Requiremenls in Different Application Areas
`2.3.1
`Information Systems, 36
`2.3.2 Rea~time SystEms, 37
`2.3.3 Distributed Systems, 38
`2.3.4 Embedded Systems, 39
`Measurement of Quality 40
`Concluding Remarks 40
`Further Exercises 40
`Hints and Sketchy Solutions 41
`Bibliographic Notes 41
`
`36
`
`2.3
`
`2.4
`2.5
`
`3
`
`SOFTWARE ENGINEERING PRINCIPLES 43
`
`3.1
`3.2
`3.3
`3.4
`3.5
`3.6
`3.7
`3.8
`
`Rigor and Formality 45
`Separation of Concerns 47
`Modularity 49
`Abstraction 51
`Anticipation of Change 53
`Generality 54
`Incrementality 56
`Concluding Remarks 57
`Further Exercises 57
`Hints and Sketchy Solu lions 58
`Bibliographic Notes 58
`
`4
`
`SOFTWARE DESIGN 61
`
`4.1
`
`4.2
`
`Software Design Activity and Its Objectives 63
`4. L 1 Design for Change, 65
`4.1.2 Program Families, 70
`Modularization Techniques 72
`4.2.1 The Module Structure and Its Representation, 73
`
`4.2.2
`
`lnteiface, Implementation. and Information
`Hiding, 81
`4.2.3 Design Notations, 89
`4.2.4 Categories of Modules, 96
`4.2.5 More Techniques for Design for Change, 104
`4.2.6 SIEpwise Refinement, 107
`4.2. 7 Top-down vs. Bottom-up Design, 115
`Object-oriented Design 115
`Handling Anomalies 122
`A Case Study in Design 125
`Concurrent Software 128
`4. 6.1 Shared Datn, 129
`4.6.2 Real-time Software, 136
`4.6.3 Distributed Software, 138
`Concluding Remarks 144
`Further Exercises 145
`Hints and Sketchy Solutions 147
`Bibliographic Notes 148
`
`4.3
`4.4
`4.5
`4.6
`
`4.7
`
`5 SOFTWARE SPECIFICATION 151
`
`5.1
`5.2
`5.3
`5.4
`5.5
`
`5.6
`
`5.7
`
`5.8
`
`The Uses of Specifications 152
`Specification Qualities 154
`Classification of Specification Styles 157
`Verification of Specifications 159
`Operational Specifications 160
`5.5. I Data Flow Diagrams: Specifying Functions of
`Information SysiEms, 161
`5.5.2 FiniiE Stn/2 Machines: Describing Control Flow, 167
`5.5.3 Petri Nets: Specifying Asynchronous Systems, 174
`Descriptive Specifications 199
`5.6.1 Entity-relationship Diagrams, 199
`5. 6.2 Logic Specifications, 202
`5.6.3 Algebraic Specifications, 219
`Building and Using Specifications in Practice 226
`5. 7.1 Requirements for Specification Notations, 227
`5.7.2 Building Modular Specifications, 230
`5. 7.3 Specifications for the End User, 241
`Concluding Remarks 242
`Further Exercises 243
`Hints and Sketchy Solutions 248
`Bibliographic Notes 251
`
`IBM-1008
`Page 3 of 83
`
`

`
`vi
`
`Contents
`
`Contents
`
`vii
`
`6 SOFTWARE VERIFICATION 255
`
`6.1
`
`6.2
`6.3
`
`6.4
`
`6.5
`
`6.6
`6. 7
`
`6.8
`
`Goals and Requirements of Verification 256
`6.1.1 Everything Must Be Verified. 257
`6.1.2 The Results of Verification May Not Be Binary, 257
`6.1.3 Verification May Be Objective or Subjective, 258
`6.1.4 Even Implicit Qualities Must Be Verified, 259
`Approaches to Verification 260
`Testing 260
`6.3.1 Goals for Testing, 262
`6.3.2 Theoretical Foundations of Testing, 264
`6.3.3 Empirical Testing Principles, 266
`6.3.4 Testing in the Small, 269
`6.3.5 Testing in the I..mge, 288
`6.3.6 Separate Concerns in the Testing Activity, 293
`6.3. 7 Testing Concurrent and Real-time Systems, 295
`
`Analysis 29'7
`6. 4.1
`Informal Analysis Techniques, 298
`6. 4.2 Correctness Proofs, 301
`Symbolic Execution 318
`6.5.1 Basic Concepts of Symbolic Execution, 320
`6.5.2 Progroms with Arroys, 323
`6.5.3 The Use of Symbolic Execution in Testing. 325
`6.5.4 Symbolic Execution of Concurrent Programs, ]27
`
`Debugging 329
`Verifying Other Software Properties 334
`6.7.1 VerifYing Performance, 334
`6. 7.2 VerifYing Reliability, 335
`6. 7.3 Source-code Metrics, 339
`Concluding Remarks 344
`Further Exercises 345
`Hints and Sketchy Solutions 350
`Bibliographic Notes 353
`
`7 THE SOFTWARE PRODUCTION PROCESS 357
`
`7.1
`
`7.2
`
`Software Production Process Models 358
`7.1.1 Wateifa/1 Model, 360
`7.1.2 Evolutionary Model, 374
`7.1.3 Transfonnation Model, 377
`7.1.4 Spiral Model, 380
`7.1.5 An Assessment of Process Models, 382
`Case Studies 384
`7.2.1 Telephone Switching System. 384
`7.2.2 Budget Control System, 389
`
`7.3
`
`7.4
`
`Organizing the Process 394
`7.3.1 Software Methodologies, 394
`7.3.2 Configuration Management, 403
`7.3.3 Software Standards, 408
`Concluding Remarks 409
`Further Exercises 409
`Hints and Sketchy Solutions 411
`Bibliographic Notes 411
`
`8
`
`MANAGEMENT OF SOFTWARE ENGINEERING 415
`
`8.1
`8.2
`
`8.3
`
`8.4
`
`8.5
`
`8.6
`
`Management Functions 417
`Project Planning 418
`8 .. 2.1 Software Productivity, 420
`8.2.2 People and Productivity, 426
`8.2.3 Cost Estimation, 427
`Project Control 434
`8.3.1 Work Breakdown Structures, 434
`8.3.2 Gantt Charts, 435
`8.3.3 PERT Charts, 437
`8.3. 4 Dealing with Deviations from the Plan, 440
`Organization 441
`8.4.1 Centrolized-control Team Organization, 443
`8.4.2 Decentralized-control Team Organization, 444
`8.4.3 Mixed-control Team Organization, 445
`8.4.4 An Assessment of Team Organizations, 446
`Risk Management 446
`8.5.1 7jtpical Management Risks in Software
`Engineedng, 447
`Conclilding·Reinarks 449
`Further .Exercises 451
`Hints and Sketchy Solutions 452
`Bibliographic Notes 452
`
`9
`
`SOFTWARE ENGINEERING roOLS AND ENVIRONMENTS 455
`
`9.1
`9.2
`9.3
`
`Historical Evoiution of Tools and Environments 456
`Classifieatioil of Software Tools and Environments 458
`Representative Tools 462
`9.3.1
`Editors, 463
`9.3.2
`Linkers, 464
`9.3.3
`Int2rpmters, 464
`9.3.4 Code Generotors, 465
`
`IBM-1008
`Page 4 of 83
`
`

`
`Contents
`
`Contents
`
`ix
`
`B.
`
`Case Study 2: Building a Family of Compilers 529
`B.1
`Initial Product Planning, 529
`B.2 Economic and Financial Planning. 529
`B.J
`Technical Plam¢ng and Managemen~ 530
`B.4 Early Development Phrues, 53()
`B.S Project Monitoring, 531
`B.6 Project Reexamination, Revival, and Goal Setting, 531
`B.7 Assignment of Responsibility, 533
`B.8
`Steady Progress and Relerue of the Product, 533
`B. 9 Product Distribution, 534
`B. 10 Remarks, 534
`Case Study 3: Incremental Delivery 537
`C.
`Concluding Remarks 538
`
`REFERENCES 539
`
`INDEX 567
`
`viii
`
`9.4
`
`9.5
`
`9.6
`9.7
`
`9.3.5 Debuggers, 466
`9.3.6
`Tbols Used in Software Testing, 467
`9.3. 7
`Static Analyzers, 468
`9.3.8 Usef"interface Management Tools, 47()
`9.3. 9 Configuratir;>n Management Tools, 474
`9.3.10 Management Tdols, 477
`9.3.11 Software Engineering Infrastructures, 478
`The Role of Programming Language in the 479
`Environment
`9.4.I Procedural Versus Nonprocedural Languages, 480
`9.4.2 Features of Progranuning in the Small, 483
`9.4.3 Progromming lAnguages and Modu/an'ty, 484
`9.4.4 Object-oriented Progromming lAnguages, 487
`9.4.5 Programming lAnguages and the Handling of
`Anomalies, 491
`9.4.6 Programming lAnguages and ConcWTency, 493
`9.4. 7 Programming Languages and Verification, 496
`9. 4.8 Programming lAnguages and Software Design, 497
`Saine Sample Tools and Environments 498
`9.5.1 Team·work, 498
`9.5.2 The UNIX Environment, 500
`9.5.3
`lAnguage-centered Environments: Sma/lta/k8()
`and KEE, 504
`9.5.4 PCTE, 505
`An ideal Scenario for the Future 506
`Concluding Remarks 511
`Further Exercises 511
`Hints and Sketchy Solutions 512
`Bibliographic Notes 513
`
`10 EPILOGUE 517
`
`10.1
`Hl.2
`10.3
`
`The Future 518
`Ethics and SoCial Responsibility 520
`Concluding Remarks 521
`Bibliograi>hic Notes 521
`
`CASE STUDIES 523
`
`A.
`
`Case Study 1: Automating a Law Office 524
`A.1 Economic and Financial Planning, 525
`A.2 Technical Planning and Management, 526
`A.J Project Monitoring, 527
`A.4 Initial Delivery, 528
`AS Partial Recovery, 528
`
`IBM-1008
`Page 5 of 83
`
`

`
`We dedicate this book to our children:
`
`Marta, Silvia, and Giacomo;
`Darius and Ryan;
`Leonardo and Laura;
`
`who have Jived cheerfully through the many revisions.
`
`Preface
`
`This is a textbook on software engineering. The theme underlying the book is the
`importance of rigor in the practice of software engineering. Traditional textbooks on the
`subject are based on the lifecycle model of software development-that is, requirements,
`specification, designt coding, maintenance-examining each phase in tum. In contrast, our
`presentation is based on important principles that can be applied independently of the
`lifecycle model and often in several phases of the lifecycle. Our emphasis is on
`identifying and applying fundamental principles that are applicable throughout the
`software lifecycle.
`The general characteristics of the book are the following:
`
`It deals with software engineering as opposed to programming. Thus, we do
`not discuss any programming issues. For example, we omit any discussion of
`programming language constructs such as goto, loops, etc. We believe that the
`student of software engineering should have prior familiarity with these issues,
`which are more properly covered in textbooks on programming languages. On
`the other hand, w~ do discuss the issue of mapping software design constructs
`into specific programming languages. We concentrate on intermodule issues
`and assume as prerequisite the ability to program individual modules.
`It emphasizes principles and techniques as opposed to specific tools (which
`may be used in examples). Many companies are actively developing software
`engineering tools and environments today and we expect that better and more
`sophisticated tools will be invented as our knowledge of software engineering
`increases. Once the student understands the principles and techniques that the
`tool is based on, mastery of the tool will be easy. The principles and techniques
`are applicable across tools while mastering the use of any particular tool does
`not better prepare the student for the use of other tools. Further, use of tools
`without understanding their underlying principles is dangerous.
`It presents engineering principles; it is not an engineering handbook.
`Principles are general and are likely to remain applicable for many years while
`particular techniques will change due to technology, increased knowledge, etc.
`An engineering handbook may be consulted to learn how to apply a particular
`
`xi
`
`IBM-1008
`Page 6 of 83
`
`

`
`xii
`
`Preface
`
`Preface
`
`xiii
`
`technique: it contains a set of prescriptions. This book, on the other hand, aims
`to enable the reader to understand why a particular technique should be used
`and, just as important, why it should not be. Even though we do show how a
`particular technique can be used to implement a given principle, our primary
`emphasis is on the understanding of the why question.
`
`This book embodies our beliefs in the use of fundamental principles and the
`importance of theory in the practice of engineering. We have used the material in this
`book in both university and professional courses on various aspects of software
`engineering.
`
`AUDIENCE
`
`This book is designed to be used as a textbook by students of software engineering either
`in a classroom or for self-study. Professional engineers and managers will find material
`here to convince them of the usefulness of modem practices of software engineering and
`the need to adopt them. It may be used by professionals who are willing to invest the time
`for serious study; it is not really appropriate for a cursory reading. In particular, wherever
`necessary, we have sacrificed breadth for depth. For the professional, the notes on further
`references will be especially helpful. An Instructor's Manual is available with ideas for
`course organizations and solutions to some of the exercises.
`
`PREREQUISITES
`
`Tbe book is designed for junior, senior, or beginning-graduate level students in computer
`science. The reader must have had a course in data structures and should be fluent in one
`or more programming languages. We assume that the reader is already proficient in
`programming. Analytical reasoning, although not strictly necessary, will greatly enhance
`the ability of the reader to appreciate the deeper concepts of the book. This skill is
`developed by mathematics courses such as calculus, discrete mathematics, or-even
`better-theoretical computer science. "Mathematical maturity" is necessary for the student
`of any engineering discipline.
`
`ORGANIZATION AND CONTENT
`
`Software engineering is a large, multi-dimensional discipline. Organizing a textbook on
`the subject poses a challenge because a textbook should present material sequentially, but.
`the many facets of software engineering are so interrelated that there is no optimal
`sequence of topics. We have organized this textbook based on the view that in software
`'
`engineering:
`
`We are building a product: the software. ·
`We use a process to build that product; and
`We use tools in support of that process.
`
`The book thus has three technical sections dealing in tum with the software product
`(Chapters 4 through 6), the ,software engineering process and management (Chapters 7
`and 8), and the software engineering environment (Chapter 9). Chapters I through 3
`form a general introduction to the field and the subsequent more technical sections of the
`book.
`In Chapter 2, we discuss the many facets of software and common desirable
`characteristics for software. These characteristics impose constraints on the software
`builder and the process to be used. In Chapter 3, we present principles for building high(cid:173)
`quality software. By studying principles rather than specific tools, the student gains
`knowledge that is independent of a particular technology and application environment.
`Because technology changes and environments evolve, the student should be armed with
`principles and techniques that can be utilized in different application areas. Chapters 4
`through 8 present and discuss techniques for applying the principles of Chapter 3 to,
`respectively, design, specification, verification, engineering process, and engineering
`management. In Chapter 9, we discuss the use of computers themselves to help in the
`building of software. We postpone the discussion of any specific tools to this chapter.
`While the material in the first two sections should withstand the passage of time, it
`is likely that the material in the third section will become outdated (we hope) because
`newer and better tools are being developed. Since programming languages are a
`fundamental tool of the software engineer, we use Chapter 9 as a bridge between the
`design issues of Chapter 4 and specific programming language constructs.
`
`EXERCISES
`
`The book contains many exercises of three types:
`
`short, paper exercises, aimed at extending the knowledge gained from the book
`or applying the knowledge more deeply; these exercises are interspersed
`throughout the chapters.
`longer paper exercises at the end of each chapter, requiring integration of the
`material in the chapter.
`term-projects requiring the development of some substantial software system
`by a small team.
`
`Solutions to some of the exercises are provided at the end of each chapter. More
`exercise solutions are given in the Instructor's Manual.
`
`IBM-1008
`Page 7 of 83
`
`

`
`xiv
`
`CASE STUDIES
`
`Preface
`
`Preface
`
`XV
`
`Several case studies are used in the text to demonstrate the integration of different
`concepts and to contrast different approaches in realistic situations. In addition, three case
`studies of real-life software engineering projects and their analyses are presented at the
`end of the book. These case studies may be read and studied at different times and for
`different purposes. From these case studies, the new student with little industrial
`experience can gain a quick view of tbe diversity of problems faoed in industrial practice.
`The student with some experience perhaps will identify with certain aspects of these case
`studies and learn from others. The case studies may be read concurrently with the main
`text. Several exercises in the book refer to these case studies.
`
`LABORATORY COURSE
`
`Many software engineering courses combine lectures and a laboratory project. To do this
`in a single semester is rather difficult. The teacher will find himself discussing
`organizational issues while the students are concentrating on their daily forays into
`debugging. We believe that software engineering must be taught as all other engineering
`disciplines by first providing the student with a solid foundation in the "theory." Only
`after this has been achieved will laboratory experience enhance the student's knowledge.
`This implies that the student project must start closer to the middle of the semester rather
`than at the beginning. In our view, a better approach is to spend one semester on the
`theory and a second semester on the laboratury. The Instructor's Manual offers several
`ideas for organizing a laboratory course based on this text.
`
`READING GRAPH
`
`The book may be read in different sequences and at different levels. Each of Chapters 4
`through 7 contains material that may be skipped on the first reading or for a less detailed
`study. Chapters I through 3 are required reading for the subsequent chapters. The
`following graph shows the dependencies among the chapters and the various paths
`through the book. The notation nP refers to a partial reading of Chapter n, skipping some
`sections; nC stands for a complete reading.
`
`The Inst~ctor's Manual discusses different course organizations based on the book.
`The conventiOnal one-semester project software engineering course may follow the
`sequence: 1, 2, 3, 7P, 5P, 4P, 6P, 8, 9, 10. We ourselves prefer the sequence 1, 2, 3, 4P,
`5P, 6P, 7P, 8, 9, 10. In etther case, the students should start on the project after 5P.
`
`ACKNOWLEDGEMENTS
`
`W~ grat~fully acknowledge reviews of earlier drafts provided by Reda A. Ammar of the
`Umverstty of Conn"':ticut: Larry C. Christensen of Brigham Young University, William
`F .. Decker of the Uruversuy of Iow~, David A. Gustafson of Kansas State University,
`RtChar? A. ~emme~er_o~ the Umverstty of California at Santa Barbara, John C. Knight of
`the Umverstty of Vtrgmta, Seymour V. Pollack of Washington University, and K. C. Tai
`of North Carolina State University.
`We would_ also like to thank the following people who have provided valuable
`feedback on van?us drafts of the manuscript: Vincenzo Ambriola, Paola Bertaina, David
`Jacobson, and M!lon Mackey.
`,
`~ewle_tt-Packard Laboratories and Politecnico di Milano made it possible to
`co~cetve th~s book by supporting a course offered by Mehdi Jazayeri at the Politecnico di
`Mtlano dunng the spring of 1988. Alfredo Scarfone and HP Italiana provided us with
`support in Italy. "W_e would 1_ike to acknowledge the support of management at Hewlett(cid:173)
`Packard Laboratones, espectally John Wilkes, Dick Lampman, ~ob Ritchie, and Frank
`Carrubba m Palo Alto, and Peter Porzer in Pisa. We would like to thank Bart Sears for
`his help with various systems: and John Wilkes for the use of his data base for managing
`references. We have also recetved support from Co11siglio Nazionale delle Ricerche.
`
`Milano, Palo Alto, Pisa
`
`. Carlo Ghezzi
`Mehdi Jazayeri
`Dino Mandrioli
`
`IBM-1008
`Page 8 of 83
`
`

`
`Chapter 1
`
`Software Engint:ering: A Preview
`
`••
`
`•
`
`1
`
`Softwjlre engineering is the fielq of CQmputer science tflat deills with the building of
`software systems "~bleb are, so Jarge Qr so coinplex that tq~Y ¥e built by a team or teams
`of engln"!'rs. Usually, these software systel)ls I'Xist in multiple versions and are useq for
`many years. During. tb!fir lifl'lime, 'ihey Uf1dergo minJy changes-to· fix <lefects; to enhance
`existing features, to add new f!'all!res,'to remoye old features, or to be adapted to run i11 a
`new enVironrneQ.t.
`Pamas [1987] has defined software engineerif!g l"' "multi-person construction of
`multi-Yersion·software." This definition·captun;~ t!Je essen~e of software engineering and
`higlllights the differences between pro~rammi'!ll ,nd software engipeering .. A
`programmer ~rites a ~omplete program, while a software ~ngineer writes a software
`component that will be combined with comP.onents written by other software engineers to
`bUild " system. The oomponent one writes may be modified by others; it ~ay be used by
`others·!" build differept Vefsions of the systei!I long ·~fter. one has left .the project.
`Programming is primarily ~·personal actiyity, while software engineering is essenti'!lly a
`~ acti-;:jfY-
`··
`'
`·
`·
`· .
`·
`Ind"'1~• the term "software engineering" wa,~ il)Vented In the jate 1960s after the
`reali~ation that all thee less!Jns learned about how to pr!)gram well were not helping to
`b!!ild better software systems. While the field of programming had made tremendous
`progres,.:..through the systematic study of !'lgqrithms and data structures and the invention
`of "strul'tUred programming"-there were still major difficultie~ in building large software
`systems. The techniques !llat were used by a physicist writing a progi'am to calpulate the
`solution to a differential equa\iOI) for an experiment were not 3\lequate for a programmer
`. ~
`working on a team that was trying to build an operating system or even an inventory
`.
`.
`.
`.
`.
`.
`1
`
`IBM-1008
`Page 9 of 83
`
`

`
`2
`
`!
`
`Software Engineering: A Preview
`
`Chap. 1
`
`Sec. 1.2
`
`A History of Software Engineering
`
`3
`
`tracking system. WtJ_at was needed in these complex cases was the classic engineering
`approach: define clearly the problem you are trying to solve, and develop standard tools
`and techniques for solving it.
`To be sure, software engineering has made progress since the 1960s. There are
`standard techniques that are used in the field. But the field is still far from achieving the
`status of a classic engineering discipline. Many areas remain in the field that are still
`being taught and practiced on the basis of informal techniques. There are no generally
`accepted methods even for specifying what a software system should do. In designing an
`electrical engineering system, such as an amplifier, the system is specified precisely. All
`parameters and tolerance levels are stated clearly and are understood by the customer and
`the engineer. In software engineering, we are just beginning to define both what such
`parameters ought to be for a software system and-an apparently much harder task-how to
`specify them.
`Furthermore, in classic engineering disciplines, the engineer is equipped with tools
`and the maihematical maturity to specify the properties of the product separately from
`those of the design. For example, an electrical engineer relies on mathematjcal equations
`to verify that a design will not violate power requirements. In software engineering, such
`mathematical tools are not well developed. The typical software engineer relies much
`more on experience and judgment rather than mathematical techniques. While experience
`and judgment are ne;,.,ssary. fofr!lal analysis tools are also essential in the practice of
`engineering.
`In this book, we take the view that software engineering must be practiced as an
`engineering discipline. Our approach is to present certain principles that we l:!elieve are
`essential to the "multi-person construction of multi-version. software." It is our view that
`such principles are much more important than any particular notation or methodology for
`building software. These principles will enable the software engineer to evaluate various
`methodologies and apply them when they are appropriate. Chapter 3 presents the
`principles; the rest of the book can be viewed as setting forth their application to the
`various problems in software engineering.
`-
`.
`In this chapter, we review the evolution of software engineering and its relationship
`to other disciplines. The goal of the chapter is to place the field of software engineering
`in perspective.
`
`1.1 THE ROLE OF SOFTWARE ENGINEERING
`IN SYSTEM DESIGN
`
`A software system is often a component of a much larger system. The software
`engineering activity is therefore a part of a much larger system design activity in which
`the requirements of the software are balanced against the requirements of other parts of.
`the system being designed. For example, a telephone switching system consists of
`computers, telephone lines and cables, telephones, perhaps other hardware such as
`satellites, and finally, software to control the various other c.omponents. It is the
`combination of all these components that is expected to meet the requirements of the
`whole system.
`·
`
`A requirement such as "the system must not be down for more than a second in 20
`years" or "when a receiver is taken off the hook, a dial tone is played within half a
`second" can be satisfied with a combination of hardware, software, and special devices.
`The decision of how best to meet the requirement can only be made by considering many
`trade-offs. Power plant or traffic monitoring systems, banking systems, and hospital
`administration systems are other examples of systems that exhibit the need to view the
`software as a component of a larger system.
`To do software engineering right, then, requires a broader look at the general
`problem of system engineering. It requires the software engineer to be involved when the
`requirements are being developed initially for the whole system. It requires that the
`software engineer attempt to understand the application area rather than just what abstract
`interfaces the software must meet. For example, if the system is aimed at users who are
`going to use primarily a menu system, it is not wise to develop a sophisticated word
`processor as a component of the system.
`Above all, any engineering discipline requires the application of compromise. A
`classic compromise concerns the choice of what should be done in software and what
`should be done in hardware. Software implementation offers flexibility, while hardware
`implementation offers performance. For example, in Chapter 2, we will see an example
`of a coin-operated machine that could be built either with several coin slots, one for each
`type pf coin, or a single slot, leaving it to software to recognize the different coins. An
`even more basic compromise involves the decision as to what should be automated and
`what should be done manually.
`
`1.2 A IDSTORY OF SOFTWARE ENGINEERING
`
`The birth and evolution of software engineering as a discipline within computer science
`can be traced to the evolving and maturing view of the programming activity. In the early
`days of computing, the problem of programming was viewed essentially as how to place
`a sequence of instructions together to get the computer to do something useful. The
`problems being programmed were quite well understood-for example, how to solve a
`differential equation. The program was written by, say, a physicist to solve an equation of
`interest to him or her. The problem was just between the user and the computer-no other
`person was involved.
`As computers became cheaper and more common, more and more people started
`using them. Higher level languages were invented in the late 1950s to make it easier to
`communicate with the machine. But still, the activity of getting the computer to do
`something useful was essentially done by one person who was writing a program for a
`well-defined task.
`It was at this time that "programming" attained the status of a profession: you could
`ask a programmer to write a program for you instead of doing it yourself. This
`introduced a separation between the user and the computer. Now the user had to specify
`the task in a form other than the precise programming notation used before. The
`programmer then interpreted this specification and translated it into a precise set of
`machine instructions. This. of course~ sometimes resulted in the programmer
`misinterpreting the user's intentions, even in these usually small tasks.
`
`IBM-1008
`Page 10 of 83
`
`

`
`4
`
`Software Engineering: A Preview
`
`Chap. I
`
`Sec. 1.3
`
`The Role of the Software Engineer
`
`5
`
`Very few large software projects were being done at this time-the early 1960s-and
`these were done by computer pioneers who were experts. For example, the CTSS
`operating system developed at MIT was indeed a large project, but it was done by highly
`knowledgeable and motivated individuals.
`In the middle to late 1960s, truly large software systems were attempted
`commercially. The best documented of these projects was the OS 360 operating system
`for the IBM 360 computer family. The large projects were the source of the realization
`that building large software systems was materially different from building smaller
`systems. There were fundamental difficulties in scalin