![The Olympians threaten.—A real ice rink, said to be the largest in
the world, is in course of construction at Olympia. Does
Niagara realise, or, as in this conjunction it might be written,
real-ice, the fact that its own nice invention may, by its rival,
be beaten all to shivers?
From Love's Labour.—What our Sir Frederic, P.R.A. (quoting the
Divine Williams), will soon be saying to the accepted artist, Bid
him go hang!
A COCK AND BULL STORY.
Air—Casabianca.
[European navies were like fighting-cocks, armed to the teeth; a single spark
might cause an explosion.
Dr. MacGregor on the Navy Estimates.]
The fighting-cock stood on the deck,
His eye was rolling red,
His feathers whiffled round his neck,
His crest was on his head.
He wore his spur above his heel,
His claws were underneath,
He also had a mass of steel
Plate-armour on his teeth.
Meanwhile the House was haggling on
In one of those debates
When Little England jumps upon
The Navy Estimates.
There Cleophas, of many wiles,
Brought up his little lot,
And Mr. Byles, with wreathèd smiles,
Was deadly on the spot.
And Labby said the bootless pay](https://image.slidesharecdn.com/12153-250428111342-8e7483d9/85/Introduction-to-software-engineering-Second-Edition-Leach-41-320.jpg)
![BALLAD OF THE UNSURPRISED JUDGE.
[Mr. Justice Hawkins observed, 'I am surprised at nothing.'—Pitts v. Joseph,
Times' Report, March 27.]
All hail to Sir Henry, whom nothing surprises;
Ye Judges and suitors, regard him with awe,
As he sits up aloft on the Bench and applies his
Swift mind to the shifts and the tricks of the Law.
Many years has he lived, and has always seen clear things
That Nox seemed to hide from our average eyes:
But still, though encompassed with all sorts of queer things,
He never, no never gives way to surprise.
When a rogue, for example, a company-monger,
Grows fat on the gain of the shares he has sold,
While the public gets lean, winning nothing but hunger
And a few scraps of scrip for its masses of gold;
When the fat man goes further and takes to religion,
A rascal in hymn-books and bibles disguised,
It's a case, says Sir Henry, of rook versus pigeon,
And the pigeon gets left—well, I'm hardly surprised.
There's a Heath at Newmarket, and horses that run there,
There are owners and jockeys, and sharpers and flats;
There are some who do nicely, and some who are done
there,
There are loud men with pencils and satchels and hats.
But the Stewards see nothing of betting or money,
As they stand in the blinkers for Stewards devised;
Their blindness may strike Henry Hawkins as funny,
But he only smiles softly, he isn't surprised.
So, here's to Sir Henry, the terror of tricksters,
Of Law he's a master, and likewise a limb:
His mind never once, when its purpose is fixed, errs;
For cuteness there's none holds a candle to him.
Let them try to deceive him, why, bless you, he's been there,
And can track his way straight through a tangle of lies;
And, though some might grow grey at the things he has
seen there,](https://image.slidesharecdn.com/12153-250428111342-8e7483d9/85/Introduction-to-software-engineering-Second-Edition-Leach-47-320.jpg)
![[In a case heard before Judge French at Shoreditch,
the Judge remarked that the plea of infancy was not a
very meritorious one. 'No,' replied the defendant, 'but
it's jolly convenient.'—The Globe.]
When, toddling along with a swell, I pretend
Not to notice a shabby (though excellent) friend,—
Well, it is not lofty, to that I assent,
But then, it's so jolly con-ve-ni-ent!
When a tenant has built up a business with care,
And saved to his landlord all cost of repair,
It may not be kind just to double his rent,
Yet somehow it's jolly con-ve-ni-ent!
If you've suffered, in polling, a moral defeat,
Then to grab each Committee and every paid seat
Some might say was the act of a cad, not a gent;
But, you see, it's so jolly con-ve-ni-ent!
Then your house is for sale, and, if gifted with brains,
You, of course, do not mention the damp, rats, and
drains
Which is not what the ancients by honesty meant,
But, still, it is jolly con-ve-ni-ent!
Transcriber's Note
Page 159: Footnote [*] refers to [www.] gutenberg.org/ebooks/30739
Page 168: 'progess' corrected to 'progress'.
Francis Powell, usually mild-mannered man, went so far as to move to report
progress.](https://image.slidesharecdn.com/12153-250428111342-8e7483d9/85/Introduction-to-software-engineering-Second-Edition-Leach-53-320.jpg)
Introduction to software engineering Second Edition Leach
- 1. Introduction to software engineering Second Edition Leach download https://textbookfull.com/product/introduction-to-software- engineering-second-edition-leach/ Download more ebook from https://textbookfull.com
- 2. We believe these products will be a great fit for you. Click the link to download now, or visit textbookfull.com to discover even more! Introduction to Software Engineering 2nd Edition Ronald J. Leach https://textbookfull.com/product/introduction-to-software- engineering-2nd-edition-ronald-j-leach/ Engineering Software Products: An Introduction to Modern Software Engineering 1st Edition Ian Sommerville https://textbookfull.com/product/engineering-software-products- an-introduction-to-modern-software-engineering-1st-edition-ian- sommerville/ Introduction to industrial engineering Second Edition Shtub https://textbookfull.com/product/introduction-to-industrial- engineering-second-edition-shtub/ Introduction to Rocket Science and Engineering, Second Edition Travis S Taylor https://textbookfull.com/product/introduction-to-rocket-science- and-engineering-second-edition-travis-s-taylor/
- 3. Introduction to Software Testing 2nd Edition Paul Ammann https://textbookfull.com/product/introduction-to-software- testing-2nd-edition-paul-ammann/ Fundamental Approaches to Software Engineering Alessandra Russo https://textbookfull.com/product/fundamental-approaches-to- software-engineering-alessandra-russo/ Fundamental Approaches to Software Engineering 1st Edition Esther Guerra https://textbookfull.com/product/fundamental-approaches-to- software-engineering-1st-edition-esther-guerra/ Model Driven Software Engineering in Practice Second Edition Marco Brambilla Jordi Cabot Manuel Wimmer https://textbookfull.com/product/model-driven-software- engineering-in-practice-second-edition-marco-brambilla-jordi- cabot-manuel-wimmer/ A Guide to Software Quality Engineering 1st Edition Pargaonkar Shravan https://textbookfull.com/product/a-guide-to-software-quality- engineering-1st-edition-pargaonkar-shravan/
- 4. CHAPMAN & HALL/CRC INNOVATIONS IN SOFTWARE ENGINEERING AND SOFTWARE DEVELOPMENT Introduction to Software Engineering Second Edition CHAPMAN & HALL/CRC INNOVATIONS IN SOFTWARE ENGINEERING AND SOFTWARE DEVELOPMENT Ronald J. Leach
- 7. Chapman & Hall/CRC Innovations in Software Engineering and Software Development Series Editor Richard LeBlanc Chair, Department of Computer Science and Software Engineering, Seattle University AIMS AND SCOPE This series covers all aspects of software engineering and software development. Books in the series will be innovative reference books, research monographs, and textbooks at the undergraduate and graduate level. Coverage will include traditional subject matter, cutting-edge research, and current industry practice, such as agile software development methods and service-oriented architectures. We also welcome proposals for books that capture the latest results on the domains and conditions in which practices are most ef- fective. PUBLISHED TITLES Building Enterprise Systems with ODP: An Introduction to Open Distributed Processing Peter F. Linington, Zoran Milosevic, Akira Tanaka, and Antonio Vallecillo Computer Games and Software Engineering Kendra M. L. Cooper and Walt Scacchi Evidence-Based Software Engineering and Systematic Reviews Barbara Ann Kitchenham, David Budgen, and Pearl Brereton Fundamentals of Dependable Computing for Software Engineers John Knight Introduction to Combinatorial Testing D. Richard Kuhn, Raghu N. Kacker, and Yu Lei Introduction to Software Engineering, Second Edition Ronald J. Leach Software Designers in Action: A Human-Centric Look at Design Work André van der Hoek and Marian Petre Software Development: An Open Source Approach Allen Tucker, Ralph Morelli, and Chamindra de Silva Software Engineering: The Current Practice Václav Rajlich Software Essentials: Design and Construction Adair Dingle Software Metrics: A Rigorous and Practical Approach, Third Edition Norman Fenton and James Bieman Software Test Attacks to Break Mobile and Embedded Devices Jon Duncan Hagar
- 8. CHAPMAN & HALL/CRC INNOVATIONS IN SOFTWARE ENGINEERING AND SOFTWARE DEVELOPMENT Introduction to Software Engineering Second Edition Ronald J. Leach Howard University Washington, DC, USA
- 9. CRC Press Taylor & Francis Group 6000 Broken Sound Parkway NW, Suite 300 Boca Raton, FL 33487-2742 © 2016 by Taylor & Francis Group, LLC CRC Press is an imprint of Taylor & Francis Group, an Informa business No claim to original U.S. Government works Version Date: 20150916 International Standard Book Number-13: 978-1-4987-0528-8 (eBook - PDF) This book contains information obtained from authentic and highly regarded sources. Reasonable efforts have been made to publish reliable data and information, but the author and publisher cannot assume responsibility for the valid- ity of all materials or the consequences of their use. The authors and publishers have attempted to trace the copyright holders of all material reproduced in this publication and apologize to copyright holders if permission to publish in this form has not been obtained. If any copyright material has not been acknowledged please write and let us know so we may rectify in any future reprint. Except as permitted under U.S. Copyright Law, no part of this book may be reprinted, reproduced, transmitted, or uti- lized in any form by any electronic, mechanical, or other means, now known or hereafter invented, including photocopy- ing, microfilming, and recording, or in any information storage or retrieval system, without written permission from the publishers. For permission to photocopy or use material electronically from this work, please access www.copyright.com (http:// www.copyright.com/) or contact the Copyright Clearance Center, Inc. (CCC), 222 Rosewood Drive, Danvers, MA 01923, 978-750-8400. CCC is a not-for-profit organization that provides licenses and registration for a variety of users. For organizations that have been granted a photocopy license by the CCC, a separate system of payment has been arranged. Trademark Notice: Product or corporate names may be trademarks or registered trademarks, and are used only for identification and explanation without intent to infringe. Visit the Taylor & Francis Web site at http://www.taylorandfrancis.com and the CRC Press Web site at http://www.crcpress.com
- 10. v Contents Preface to the Second Edition, xiii Preface to the First Edition, xxi To the Instructor and the Reader, xxv Chapter 1 ◾ Introduction 1 1.1 THE NEED FOR SOFTWARE ENGINEERING 1 1.2 ARE SOFTWARE TEAMS REALLY NECESSARY? 7 1.3 GOALS OF SOFTWARE ENGINEERING 10 1.4 TYPICAL SOFTWARE ENGINEERING TASKS 11 1.5 SOFTWARE LIFE CYCLES 13 1.5.1 Classical Waterfall Model 14 1.5.2 Rapid Prototyping Model 16 1.5.3 Spiral Model 21 1.5.4 Market-Driven Model of Software Development 24 1.5.5 Open Source Model of Software Development 25 1.5.6 Agile Programming Model of Software Development 27 1.5.7 Common Features of All Models of Software Development 28 1.5.8 Software Evolution and the Decision to Buy versus Build versus Reuse versus Reengineer 28 1.6 DIFFERENT VIEWS OF SOFTWARE ENGINEERING ACTIVITIES 29 1.7 SOFTWARE ENGINEERING AS AN ENGINEERING DISCIPLINE 30 1.8 SOME TECHNIQUES OF SOFTWARE ENGINEERING 35 1.8.1 Reuse 36 1.8.2 Metrics 39 1.8.3 Computer-Aided Software Engineering (CASE) 41 1.8.4 Cost Estimation 45 1.8.5 Reviews and Inspections 46
- 11. vi ◾ Contents 1.9 STANDARDS COMMONLY USED FOR SOFTWARE DEVELOPMENT PROCESSES 47 1.10 ORGANIZATION OF THE BOOK 49 SUMMARY 50 KEYWORDS AND PHRASES 51 FURTHER READING 52 Chapter 2 ◾ Project Management 55 2.1 SUBTEAMS NEEDED IN SOFTWARE ENGINEERING PROJECTS 57 2.2 NATURE OF PROJECT TEAMS 61 2.3 PROJECT MANAGEMENT 63 2.4 SOFTWARE PROJECT ESTIMATION 65 2.5 PROJECT SCHEDULING 74 2.6 PROJECT MEASUREMENT 77 2.7 PROJECT MANAGEMENT TOOLS 78 2.8 ROLE OF NETWORKS IN PROJECT MANAGEMENT 79 2.9 GROUPWARE 81 2.10 CASE STUDY IN PROJECT MANAGEMENT FOR AGILE PROCESSES 82 SUMMARY 85 KEYWORDS AND PHRASES 86 FURTHER READING 86 Chapter 3 ◾ Requirements 89 3.1 SOME PROBLEMS WITH REQUIREMENTS DETERMINATION 89 3.2 REQUIREMENTS ELICITATION 92 3.3 REQUIREMENTS TRACEABILITY 97 3.4 SOFTWARE ARCHITECTURES AND REQUIREMENTS 99 3.4.1 Use of Data Abstraction and Information Hiding in Requirements Engineering 100 3.4.2 Regrouping Requirements in Requirements Engineering 102 3.4.3 Reuse of Requirements in Requirements Engineering 104 3.4.4 Automation of the Requirements Engineering Process 104 3.5 USE CASES IN REQUIREMENTS ENGINEERING 105 3.6 REENGINEERING SYSTEM REQUIREMENTS 106 3.7 ASSESSMENT OF FEASIBILITY OF SYSTEM REQUIREMENTS 108 3.8 USABILITY REQUIREMENTS 109
- 12. Contents ◾ vii 3.9 SPECIFYING REQUIREMENTS USING STATE DIAGRAMS AND DECISION TABLES 115 3.10 SPECIFYING REQUIREMENTS USING PETRI NETS 119 3.11 ETHICAL ISSUES 119 3.12 SOME METRICS FOR REQUIREMENTS 124 3.13 THE REQUIREMENTS REVIEW 128 3.14 A MANAGEMENT VIEWPOINT 134 3.15 CASE STUDY OF A MANAGEMENT PERSPECTIVE ON REQUIREMENTS IN AGILE DEVELOPMENT 136 3.16 THE MAJOR PROJECT: PROBLEM STATEMENT 139 3.17 THE MAJOR PROJECT: REQUIREMENTS ELICITATION 140 3.18 THE MAJOR SOFTWARE PROJECT: REQUIREMENTS ANALYSIS 146 SUMMARY 150 KEYWORDS AND PHRASES 151 FURTHER READING 151 Chapter 4 ◾ Software Design 157 4.1 INTRODUCTION 157 4.2 SOFTWARE DESIGN PATTERNS 159 4.3 INTRODUCTION TO SOFTWARE DESIGN REPRESENTATIONS 163 4.4 PROCEDURALLY ORIENTED DESIGN REPRESENTATIONS 169 4.5 SOFTWARE ARCHITECTURES 174 4.6 SOFTWARE DESIGN PRINCIPLES FOR PROCEDURALLY ORIENTED PROGRAMS 177 4.7 WHAT IS AN OBJECT? 180 4.8 OBJECT-ORIENTED DESIGN REPRESENTATIONS 183 4.9 SOFTWARE DESIGN PRINCIPLES FOR OBJECT-ORIENTED PROGRAMS 185 4.10 CLASS DESIGN ISSUES 189 4.11 USER INTERFACES 191 4.12 SOFTWARE INTERFACES 196 4.13 SOME METRICS FOR DESIGN 198 4.14 DESIGN REVIEWS 199 4.15 A MANAGER’S VIEWPOINT OF DESIGN 200 4.16 CASE STUDY OF DESIGN IN AGILE DEVELOPMENT 201 4.17 ARCHITECTURE OF THE MAJOR SOFTWARE ENGINEERING PROJECT 202
- 13. viii ◾ Contents 4.18 PRELIMINARY DESIGN OF THE MAJOR SOFTWARE PROJECT 206 4.19 SUBSYSTEM DESIGN FOR THE MAJOR SOFTWARE PROJECT 212 4.20 DETAILED DESIGN FOR THE MAJOR SOFTWARE PROJECT 217 SUMMARY 218 KEYWORDS AND PHRASES 221 FURTHER READING 221 Chapter 5 ◾ Coding 227 5.1 CHOICE OF PROGRAMMING LANGUAGE 227 5.2 CODING STYLES 230 5.3 CODING STANDARDS 237 5.4 CODING, DESIGN, REQUIREMENTS, AND CHANGE 239 5.5 COUPLING CAN BE DANGEROUS 240 5.6 SOME CODING METRICS 245 5.7 CODING REVIEWS AND INSPECTIONS 249 5.8 CONFIGURATION MANAGEMENT 249 5.9 A MANAGEMENT PERSPECTIVE ON CODING 254 5.10 CASE STUDY IN CODING IN AGILE DEVELOPMENT 255 5.11 CODING OF THE MAJOR SOFTWARE PROJECT 255 SUMMARY 260 KEYWORDS AND PHRASES 260 FURTHER READING 260 Chapter 6 ◾ Testing and Integration 267 6.1 TYPES OF SOFTWARE TESTING 269 6.2 BLACK-BOX MODULE TESTING 271 6.3 WHITE-BOX MODULE TESTING 274 6.4 REDUCING THE NUMBER OF TEST CASES BY EFFECTIVE TEST STRATEGIES 278 6.5 TESTING OBJECTS FOR ENCAPSULATION AND COMPLETENESS 281 6.6 TESTING OBJECTS WITH INHERITANCE 284 6.7 GENERAL TESTING ISSUES FOR OBJECT-ORIENTED SOFTWARE 286 6.8 TEST SCRIPTS, TEST HARNESSES, AND TEST PLANS 288 6.9 SOFTWARE INTEGRATION 290 6.10 CLOUD COMPUTING AND SOFTWARE INTEGRATION: SOFTWARE AS A SERVICE 297
- 14. Contents ◾ ix 6.11 MANAGING CHANGE IN THE INTEGRATION PROCESS 298 6.12 PERFORMANCE AND STRESS TESTING 300 6.13 QUALITY ASSURANCE 301 6.14 SOFTWARE RELIABILITY 302 6.15 A MANAGER’S VIEWPOINT ON TESTING AND INTEGRATION 305 6.16 CASE STUDY IN TESTING AND INTEGRATION IN AGILE DEVELOPMENT 307 6.17 TESTING THE MAJOR SOFTWARE PROJECT 308 6.18 INTEGRATING THE MAJOR SOFTWARE PROJECT 309 SUMMARY 311 KEYWORDS AND PHRASES 312 FURTHER READING 312 Chapter 7 ◾ Delivery, Installation, and Documentation 315 7.1 DELIVERY 315 7.2 INSTALLATION 321 7.3 DOCUMENTATION 323 7.4 INTERNAL DOCUMENTATION 324 7.5 EXTERNAL DOCUMENTATION 325 7.6 DESIGN RATIONALES 326 7.7 INSTALLATION, USER, TRAINING, AND OPERATIONS MANUALS 327 7.8 ONLINE DOCUMENTATION 327 7.9 READING LEVELS 328 7.10 A MANAGER’S VIEW OF DELIVERY, INSTALLATION, AND DOCUMENTATION 329 7.11 CASE STUDY OF DELIVERY IN AGILE DEVELOPMENT 329 7.12 DELIVERY, INSTALLATION, AND DOCUMENTATION OF THE MAJOR SOFTWARE PROJECT 330 SUMMARY 331 KEYWORDS AND PHRASES 332 FURTHER READING 332 Chapter 8 ◾ Maintenance and Software Evolution 335 8.1 INTRODUCTION 335 8.2 CORRECTIVE SOFTWARE MAINTENANCE 338 8.3 ADAPTIVE SOFTWARE MAINTENANCE 343
- 15. x ◾ Contents 8.4 HOW TO READ REQUIREMENTS, DESIGNS, AND SOURCE CODE 346 8.5 A MANAGER’S PERSPECTIVE ON SOFTWARE MAINTENANCE 347 8.6 MAINTENANCE COSTS, SOFTWARE EVOLUTION, AND THE DECISION TO BUY VERSUS BUILD VERSUS REUSE VERSUS REENGINEER 347 8.7 MAINTENANCE IN AGILE DEVELOPMENT AND THE TOTAL LIFE CYCLE COSTS 350 8.8 MAINTENANCE OF THE MAJOR SOFTWARE PROJECT 350 SUMMARY 350 KEYWORDS AND PHRASES 351 FURTHER READING 351 Chapter 9 ◾ Research Issues in Software Engineering 353 9.1 SOME IMPORTANT RESEARCH PROBLEMS IN SOFTWARE ENGINEERING 354 9.1.1 The Fundamental Question 354 9.1.2 Requirements 354 9.1.3 Design 355 9.1.4 Coding 355 9.1.5 Testing 355 9.1.6 Integration 356 9.1.7 Maintenance 356 9.1.8 Cost Estimation 357 9.1.9 Software Reuse 357 9.1.10 Fault Tolerance 358 9.1.11 Metrics 359 9.1.12 Languages and Efficiency 359 9.1.13 Language Generators 360 9.1.14 Inspections and Reviews 360 9.1.15 Distributed Systems 361 9.1.16 Software Project Management 361 9.1.17 Formal Methods 361 9.1.18 Processes 361 9.1.19 Risk Management 362 9.1.20 Quality Assurance 362
- 16. Contents ◾ xi 9.1.21 Configuration Management 362 9.1.22 Crystal Ball 362 9.2 HOW TO READ THE SOFTWARE ENGINEERING RESEARCH LITERATURE 362 FURTHER READING 365 APPENDIX A: AN INTERESTING SOFTWARE PATENT, 367 APPENDIX B: COMMAND-LINE ARGUMENTS, 369 APPENDIX C: FLOWCHARTS, 373 REFERENCES, 375 TRADEMARKS AND SERVICE MARKS, 389
- 18. xiii Preface to the Second Edition Since the first edition of this book was published, there have been enormous changes to the computer software industry. The inventions of the smartphone and the tablet have revolutionized our daily lives, and have transformed many industries. Online data is ubiquitous. The pace of deployment of ever more advanced digital capabilities of modern automobiles is breathtaking. Cloud computing has the potential to both greatly increase productivity and greatly reduce the maintenance and upgrade costs for large organiza- tions. A student studying software engineering might not even recall a time when these devices and software systems had not been ubiquitous. An experienced software professional probably would observe that there are problems in this paradise, and that most of these problems had been around in one form or another for many years, regardless of the advances in technology. Nearly all these problems are in the area of software. Here are some examples. The first problem is in the education of computer science students. In the mid-1990s, my university was partnering with a major research university on educational issues in com- puter science. An unnamed faculty member at our partner university was quoted as saying the following about the education of his students, although the same comment could have been applied to almost any college or university at that time: “We teach our students to write 300-line programs from scratch in a dead language.” This is a powerful statement and had a major influence on the curriculum in my department. That influence continues to this very day. Unfortunately, this statement is still generally applicable to the way that software devel- opment is still taught, at least in the United States. The only difference is that the dead language, which at the time was Pascal, generally is not taught anywhere. The rest of the statement is true, because there is little systematic effort to reuse the large body of existing code for applications and subsystems. Students are encouraged to use any available software development toolkit (SDK) and to use an application programming interface (API) in much of their software development. If they have been introduced to cloud computing in their coursework, they probably have used interfaces such as HTTP, SOAP, REST, or JSON. They generally are not encouraged to reuse code written by others in any systematic way. This is somewhat surprising, because so much source code is avail- able on the Internet, and because the effective, systematic reuse of large-scale source code components to make prototypes that morph into complete working projects is at the heart of the rapid development process known as “agile programming” or “agile development.”
- 19. xiv ◾ Preface to the Second Edition Lack of student exposure to, and interaction with, very large systems has other ramifica- tions. Students often ignore the possibilities in working with such long-lived systems that provide essential services and will continue to do so for the foreseeable future. This book will encourage reuse of existing software components in a systematic way as much as possible, with the goal of providing guidance into the way that software is currently developed and is likely to be developed in the foreseeable future, regardless of the software development life cycles that the reader may encounter, including the classical waterfall model, rapid prototyping model, spiral model, open source model, agile method, or any other technique that the reader is likely to encounter during his or her career. Here is another example. The operating systems of smartphones and tablets are not identical to the ones most commonly used on many companies’ computer offerings. This often causes interoperability problems. For example, most smartphones running some form of the Android operating system do not have quite the same version of Linux as their basis, which leads to some software incompatibilities. The Apple iOS operating system for iPhones does not have precisely the same type of file system organization as Apple com- puters, which, themselves, use an underlying operating system called Apple Darwin that is also based on Linux. The relative insecurity of many smartphones and tablets causes major issues for orga- nizations that wish to limit access to their critical data. Many banking applications (apps) deployed on smartphones to be interoperable with bank databases have had major security breaches. Even highly touted fingerprint readers have been compromised. Most software sold in online app stores is developed without very much effort given to documentation. The general feeling is that there appears to be little concern originally intended in the app’s postdeployment effort known as “software maintenance” that is so costly for traditional systems. Generally speaking, an app developer is expected to main- tain the software by correcting any errors, and at no cost to the purchaser of an app. This unpaid effort can be costly to developers in terms of time and effort, but is almost always necessary in order to continue to achieve good reviews, even if the initial reviews were good. Online data can be extremely useful, but many people, and many organizations as well, wish to limit this access. As the second edition of this book is being written in 2015, much of the news is filled with stories about the release of government data that is meant to have been confidential. The evident lack of appropriate data security is evidence of the incorrect design of databases and poor deployment of database access controls, which are, again, evidence of a software engineering problem, primarily in computer security. This problem of data security is not unique to government systems; many private com- panies have had their confidential intellectual property compromised. This is another example of a problem in computer security. Of course, everyone is well aware of the almost constant stream of information about consumer confidential information being accidently released, or even stolen, from many major companies. This is yet another example of a problem in computer security. If you have younger siblings or friends, you may be aware of the “common appli- cation” software often used for the college admissions process. In its initial rollout in
- 20. Preface to the Second Edition ◾ xv 2013, this web-based software often crashed during use, leaving applications in various states of completion, with applicants unsure if they should restart the application pro- cess. Clearly, the common application software was not efficient, reliable, or even usable at that time. There are also technical problems at the healthcare.gov website with the enrollment in insurance exchanges that are a major part of the Affordable Care Act. The problems include slow responses, broken and incorrect links, and internal inconsistencies within the website. (As with the privately developed common application software, many of these technical implementation problems are highly likely to be fixed long before the time this book appears in print.) The constant upgrading of automobile software is also a concern. Many problems with the entertainment and communications software have been reported in the literature. I have a personal example: my favorite car. After an upgrade of the satellite radio software at the provider’s site, the software on the car kept contacting the satellite for program- ming data even while the car was turned off. This depleted the battery and required two tows, two replacement batteries, and two days of work by the dealer’s top mechanic until the car was fixed. This is a problem in software configuration management, because the newest version of the satellite provider’s system did not interface correctly with existing satellite-enabled radios. It is also a problem in software design, because there was no safety mechanism, such as a time-out, to protect the battery. Deployment of software to multiple locations is a constant issue in modern software that uses networks and a variety of end- user devices. (You might see this particular car, a convertible with a vanity license plate. If you do, please smile and buy another copy of this book. Thank you.) The problem that my car had is only a small portion of the kinds of problems that might occur as we move toward an “Internet of things.” The term refers to the way that many people think that nearly every digital device will be connected and accessible by the Internet. In this sense, far more than standard computer equipment and smartphones can be accessible from the Internet. You are probably aware of concerns about accessing power plants and the electric grid via the Internet, and the security concerns about a potential vulnerability due to security breaches. Indeed, almost every device you use in everyday life, including human-driven cars, driverless cars, elevators, thermostats, medical devices, appliances, and electronic locks, just to name a few, will be accessible from the Internet. Many companies, including Google and many automobile manufacturers, have projects to develop autonomous vehicles that will largely replace human drivers. (The first known use of the term Internet of things was by Kevin Ashton in the June 2009 issue of the RFID Journal.) Here is a specific example with which I am very familiar: the use of the Internet for monitoring elevators. Here is the context. Nearly all modern elevators use microprocessors to control operation of the elevator cars and to monitor the elevator’s “health and safety.” Because efficient operation of an elevator often uses a more complex data structure than a stack or queue for scheduling, an elevator simulation has been a favorite topic of discussion in data structures books for many years. The first such elevator scheduling simulation I ever saw was in volume 1 of Donald Knuth’s The Art of Computer Programming (Knuth, 1973).
- 21. xvi ◾ Preface to the Second Edition The microprocessors often relate safety status information from all the elevator compa- ny’s installed elevators back to a database in a single communications center. In most eleva- tor companies, this database is linked to the emergency service of a local fire department in the event of system failure in the form of a car stuck between floors or a failure of some of the redundant mechanical and electrical systems. In some elevator companies’ systems, the database can be examined for determination of which problems recur, so that they can be fixed either on site or by reprogramming microprocessors, thereby helping reduce expen- sive service calls. All of this activity takes place in an environment in which the Internet communications and database technologies are constantly changing, whereas the typical microprocessor is created specifically for a particular generation of elevators and might be difficult to replace or even reprogram. Some additional information on the issue of eleva- tor monitoring and fault determination can be found in my paper “Experiences Analyzing Faults in a Hybrid Distributed System with Access Only to Sanitized Data” (Leach, 2010). Cloud computing, a very hot topic now, is, in some sense, a very old idea that goes back to the early 1960s. In the 1960s, most computing was done on mainframes, to which a col- lection of terminals was attached. Software was installed and updated on the mainframe, and no changes were needed on the terminals. All control resided in the hands of the mainframe operators. If the mainframe went down, or the software crashed, remote users on terminals were unable to accomplish anything. Such remote users may have had no knowledge of where the mainframe was located, although they needed to understand the mainframe’s hardware and software architecture to program it efficiently. When the personal computer revolution began, control of access and software devolved to the person who controlled the personal computer on his or her desk. This created prob- lems for system administrators, because they had to support large numbers of users, many of whom were not particularly knowledgeable about computers. The movement to cloud computing allows system administrators to keep all the applica- tions and data in what, to users, appears to be a single place, “the cloud,” that may, in fact, be a collection of servers and networks stored in one or more data centers in a location that may not be known to the remote users. Some of the issues in cloud computing involve scalability; that is, in having computer systems function well even if they are forced to respond to far more users, far more com- plex programs that implement far more complex algorithms, and far larger data sets than they were originally designed or originally intended for. A 2013 article by Sean Hull in the Communications of the ACM (Hull, 2013) describes some of the issues in scalability. There are often performance issues with cloud-based software. Proper data design and security prevent remote users from having unlimited access, but poor data design and poor security make the potential access dangers of placing everything on a cloud much more serious. Yet another concern with cloud-based systems is the ownership and management of the cloud. Two articles in the May 7, 2015, issue of the New York Times illustrate the point. Nick Wingfield writes in “Zynga Is Trimming Its Staff and Its Game Ambitions” about reducing the number of games produced, eliminating sports games, and moving the data center (where a player’s behavior is analyzed) to a cloud service such as Amazon. A second
- 22. Preface to the Second Edition ◾ xvii article, “Europe Adds E-Commerce to Antitrust Inquiries,” by Mark Scott, describes some European concerns about the broad reach of several large companies such as Amazon, Google, and Apple. Consider the problems that might arise if a company placed a major part of its business on a cloud platform that is being discontinued or modified due to legal or other pressures. Some software development processes currently in use were not common when the first edition of this book was produced. Perhaps the most important new process is known as “agile programming.” Agile programming is an attempt to improve the efficiency of the software development process by having software professionals experienced in a particular application domain develop software using reusable components such as APIs and subsys- tems whose performance and capability are well known to the developers. There is a belief that the interaction between software and hardware in modern network- centric systems should be viewed as Software as a Service (SaaS). This notion helps with abstraction, but places serious loads on both system performance and the treatment of unexpected software interactions not described in APIs. The term SaaS is often used in the context of cloud-based computing, where the term cloud is synonymous for remote storage of data and applications, where the actual location of the data or application used is probably not known to the user. Two of the most com- monly used cloud storage services are Amazon Cloud Services and IBM Cloud Services. SaaS is often used to monetize the use of software services on a pay-as-you-go basis. Cloud computing often includes the concept of virtualization, in which a software appli- cation executes on a remote machine that runs a virtual image of an operating system together with a set of all necessary cooperating applications. The idea is that maintenance of applications in virtual environments is much easier to control than maintaining the same applications on multiple physical computers. Virtualization is an old idea, in the sense that there have been emulators for, say, allowing Apple Mac applications to run on a computer running Microsoft Windows, allowing Windows operations to run on modern Apple computers, or run Sun Solaris applications within a Windows environment, without having the hassle of a dual-boot computer running multiple operating systems, one at a time. Ideally, applications running in different virtual environments are sealed off from other applications. However, many questions have been raised about the security of applications running in virtualized environments, especially in cases where two different virtualized environments are executing on the same server. Here is another example of a software problem that the use of cloud computing probably cannot solve. On May 6, 2015, I was asked to be an expert witness in a lawsuit involving a company that produced software with poor performance and security flaws. There was some question about how close the company’s software was to an existing, legacy system. (This opportunity became available to me one day before the two aforementioned articles in the New York Times.) It should be clear that the area of software engineering is evolving quickly, but that many of the problems we now face are older ones in new guises. The goal of this book is to provide you with the fundamentals in order to be able to have a satisfying professional
- 23. xviii ◾ Preface to the Second Edition career as a software engineer regardless of what changes occur in the future, even if many of these changes cannot be predicted or are even disruptive in nature. Ideally, you will understand all the software development methodologies and processes discussed in this book at a reasonably sophisticated level, and will be proficient in at least one of them. Do not think, however, that all software engineering issues occur with new systems. The Ada programming language, although not as popular as it was in the late 1980s and early 1990s, is still used for thirty-two air traffic control systems, twenty-six commercial airplane systems, thirteen railroad transportation systems (including the English Channel Tunnel), twenty scientific space vehicles, eight commercial satellites, two nuclear power plants, one automobile robot assembly plant, eight banking systems, and, of course, many military applications. Ada’s strong support for advanced software engineering principles is a primary issue in these safety-critical areas. The second edition follows the same organization as the first edition and is comprised of nine primary chapters. Many chapters will include one or more sections that provide typical views of software managers on the relevant technical activities. The purpose of the “managerial view” is to provide you with additional perspective on software engineer- ing, not to prepare you to be a manager in the immediate future. In most organizations, a considerable amount of varied project experience is essential before a person is given a managerial position at any level of responsibility. Chapter 1 contains a brief introduction to software engineering. The goals of software engineering are discussed, as are the typical responsibilities of team members. Both the classical waterfall and iterative software development models such as rapid prototyping and the spiral approach are discussed. New to this chapter is extensive material on both open source and agile software development methods. Chapter 2 contains a brief overview of project management. The intention is to present the minimum amount of information necessary to educate the student about the many types of software development environments that are likely to be encountered in the pro- fessional work force. The chapter has been rewritten to emphasize coding practices, such as reducing coupling between modules, instead of presenting long examples of actual source code as exemplars. An overview of cost and scheduling information is also given here. We also begin our discussion of a case study of agile software development. The case study will be continued throughout the book. Chapters 3 through 8 are devoted to requirements; design; coding; testing and inte- gration; delivery, installation, and documentation; and maintenance. Although these six chapters are presented in the order in which they would occur in the classical waterfall software development model, the material works well with other software development approaches. We present a unique approach in Chapter 3, which is devoted to the requirements pro- cess, with heavy emphasis on the movement from preliminary, informal requirements to more complete ones that describe a system in detail and can be used as the basis for a test plan. There is a hypothetical dialogue that illustrates how requirements might be elicited from a potential customer. The goal of the chapter is to indicate the importance of require- ments understanding, even if there is no known customer, such as may be the case for
- 24. Preface to the Second Edition ◾ xix development of apps for mobile devices. The large software project that we will discuss in each of the remaining chapters in this book is introduced in this chapter. Issues of inter operability and user interfaces are discussed here as part of the requirements process. The requirements traceability matrix developed here is used throughout the book. The chap- ter also continues the case study on agile programming through the development of the requirements for an actual system. Chapter 4 is devoted to software design. Both object-oriented and procedurally oriented design are discussed, and several commonly used design representations are given. We consider matching preexisting software patterns to the software’s requirements as part of the design process. Software reuse is also emphasized here. Large-scale, reusable software components are at the heart of the continuing case study on agile software development. The topic of coding is discussed in Chapter 5, where we examine software implementa- tion techniques. This chapter emphasizes source code file organization, naming conven- tions, and other coding standards. Since the reader is presumed to have had considerable experience writing source code, this chapter is brief. The role of coding, especially coding standards, in agile development is included. In Chapter 6, we discuss testing and integration in detail. Both “white-box” and “black- box” testing are discussed, as are testing methods for object-oriented programs. The “big- bang,” “bottom-up,” and “top-down” methods of software integration are discussed here. Since software integration is at the heart of many agile development projects, we describe this in our continuing case study. Chapter 7 is quite short and is devoted primarily to delivery and installation. It also includes a discussion of internal and external documentation and a brief discussion of online help systems. Due to the unique nature of agile software development processes, the continuing case study is very brief in this chapter on delivery and installation. Chapter 8 describes something that is foreign to most beginning software engineering students: software maintenance. It is discussed in detail because maintenance accounts for a large percentage of the funds spent on software projects and because many students will begin their professional careers as software maintainers. As was the case with Chapter 7, the continuing case study is very brief in this chapter on evolution and software maintenance. Chapter 9 lists a set of open research problems in software engineering and provides some suggestions to help you read the existing software engineering literature. There are three appendices: one on software patents, one on command-line arguments, and one on flowcharts. Any book is the result of a team effort. The efforts of Senior Acquisitions Editor Randi Cohen, at Chapman Hall/CRC Press; Richard LeBlanc, editor of the Innovations in Software Engineering and Software Development Series; many anonymous reviewers; stu- dents who read through the manuscript; and the Taylor Francis “book team,” especially Jay Margolis and Adel Rosario, are gratefully acknowledged.
- 26. xxi Preface to the First Edition Software engineering lies at the heart of the computer revolution. Software engi- neering may best be described as the application of engineering techniques to develop and maintain software that runs properly and is constructed in an efficient manner. Like most areas of computer science, software engineering has been influenced by the Internet and the ready availability of web browsers. You are certainly aware that the Internet has been instrumental in creating new job opportunities in the areas of web page design and server software development using tools such as the Common Gateway Interface (CGI) and Java. Many organizations use both the Internet and networks called “intranets,” which are used only within the organization. However, the Internet is hardly without problems. Poorly designed web pages, links that become outdated because there is no systematic plan for keeping them current, servers that crash under the load from multiple users, applications that use excessive resources, web pages and frame layouts that are unattractive when viewed on 15-inch monitors instead of the developers’ 21-inch systems, and computer security failures are familiar issues to any heavy Internet user. Less evident is the problem of separation of program functionality into servers and clients. A changing technology with relatively few standards, many of which are at least slightly inconsistent, causes additional problems. As you will see, these are essentially problems in software engineering, which we will address in this book. Software engineer- ing is necessary for writing programs for single user machines connected to a network, multi-user machines that are either standalone or connected to networks, and to networks themselves. Software is used in automobiles, airplanes, and many home appliances. As the bound aries between the telecommunications, entertainment, and computer industries continue to blur in multimedia and networking, the need for software will only increase, at least for the foreseeable future. Software engineering is essential if there is to be any hope of meet- ing the increasing needs for complex, high-quality software at affordable prices. Almost equally important is the more subtle influence of the Internet on the process of software development. Because of the complexity of modern software systems, nearly all software development is done by teams. As you will see later is this book, networks can be used to aid in the development process. This book is intended for juniors and seniors majoring in computer science. At some institutions, the book may also be used as a text for a graduate-level course intended for
- 27. xxii ◾ Preface to the First Edition those students who did not take an undergraduate course. A student reading this book will have taken several programming courses, including one that uses a modern programming language such as C, C++, Java, Ada, or Swift. At a minimum, the student will have had a follow-up course in data structures. Ideally, the student will have some experience with software projects larger than a few hundred lines of code, either as part of an internship or in formal classes. A book intended for an audience of undergraduates must be short enough for students to read it. It must show the student that there is a major difference between the real- ity of most industrial software engineering projects and the small, individually written programs that they have written in most of their computer science classes. I believe that projects are an important part of any software engineering course, other than those taught to experienced professionals or advanced graduate students. Therefore, the use of appropriate team projects will be considered as essential to reinforce the material presented in the book. Like most of us, students learn best by doing. However, their learning is enhanced if a systematic framework is provided, along with many examples of actual software industry practice where appropriate. Examples of this practical approach are present in most chap- ters of this book. The goal is to take students from an educational situation in which they have written relatively small programs, mostly from scratch and by themselves, and move them toward an understanding of how software systems that are several orders of magni- tude more complex are developed. Whenever it is pedagogically sound, we emphasize some approaches to software devel- opment that are used currently in industry and government. Thus, we discuss the Internet as a medium for publishing requirements and design documents, thereby making project coordination easier. This is done because many companies are either currently using, or intend to use, either the Internet or a local “intranet” for communication and coordination of software projects. This trend will certainly continue. The impact of the Java language as a “software backplane” unifying software development across multiple platforms cannot be ignored. Active-X and CORBA (Common Object Request Broker Architecture) are also heavily used in large-scale software projects with components written in more than one programming language. Object-oriented technology (OOT) presents a special problem for the author of any introductory book on software engineering. Certainly the availability of good class libraries is having an impact on the first software engineering projects, as evidenced by the incorporation of a panel on this topic at CSC’96. The Java language is gener- ally considered to be more object-oriented than C++ because C++ has support for both procedural and object-oriented programming, and Java enforces the object-oriented paradigm. There are more books on Java programming than on any other program- ming language. There are four alternative approaches to object-oriented technology in a software engineering book: ignore OOT; use only OOT; use both, thus having two parallel tracks within the same book; or use a hybrid. Each approach has proponents and opponents.
- 28. Preface to the First Edition ◾ xxiii This book uses a hybrid approach, describing object-oriented design and functional decomposition as alternative approaches in a systematic way. The emphasis is on showing that the goals of software engineering; namely, to write programs that are: • Efficient • Reliable • Usable • Modifiable • Portable • Testable • Reusable • Maintainable • Interoperable with other software • Correct This book contains a simple but non-trivial running example that is available in electronic form. The software example is composed of components in the C and C++ languages that will be integrated with certain commercial software applications. Multiple languages are used to reflect the reality of modern software development. The example illustrates the need for proper design and implementation of software components as part of the solution to a problem. There is emphasis on all the steps needed in software engineering: requirements; design, including design tradeoffs; testing; installation; and maintenance. Coding, with the exception of coding standards, is touched on only briefly. The book also covers computation and proper use of some software metrics such as lines of code or the McCabe cyclomatic complexity. It stresses the use of software tools whenever possible, and also includes a brief discussion of software reuse. The software associated with the book is available for testing and experimentation. There are several spreadsheets for project schedule and metrics. The book is organized into nine chapters. Many chapters will include one or more sec- tions that provide typical views of software managers on the relevant technical activities. The purpose of the “managerial view” is to provide you with additional perspective on software engineering, not to prepare you to be a manager in the immediate future. In most organizations, a considerable amount of varied project experience in essential before a person is given a managerial position at any level of responsibility. Chapter 1 contains a brief introduction to software engineering. The goals of software engineering are discussed, as are the typical responsibilities of team members. Both the classical waterfall and iterative software development models such as rapid prototyping and the spiral approach are discussed.
- 29. xxiv ◾ Preface to the First Edition Chapter 2 contains a brief overview of project management. The intention is to pres- ent the minimum amount of information necessary to educate the student about the type of software development environment that is likely to be encountered in the professional work force. An overview of cost and scheduling information is also given here. We present a unique approach in Chapter 3, which is devoted to the requirements pro- cess, with heavy emphasis on the movement from preliminary, informal requirements to more complete ones that describe a system in detail and can be used as the basis for a test plan. We present a hypothetical dialogue that illustrates how requirements might be elic- ited from a potential customer. The large software project that we will discuss in each of the remaining chapters in this book is introduced in this chapter. Issues of interoperability and user interfaces are discussed here as part of the requirements process. The requirements traceability matrix developed here is used throughout the book. Chapter 4 is devoted to software design. Both object-oriented and procedurally oriented design are discussed and several commonly used design representations are given. We consider matching preexisting software patterns as part of the design process. Software reuse is also emphasized here. The topic of coding is discussed in Chapter 5, where we examine software implementa- tion techniques. This chapter emphasizes source code file organization, naming conven- tions, and other coding standards. Since the reader is presumed to have had considerable experience writing source code, this chapter is brief. In Chapter 6, we discuss testing and integration in detail. Both “white-box” and “black- box” testing are discussed, as are testing methods for object-oriented programs. The “big- bang,” “bottom-up,” and “top-down” methods of software integration are discussed here. Chapter 7 is quite short and is devoted primarily to delivery and installation. It also includes a discussion of internal and external documentation and a brief discussion of online help systems. Chapter 8 describes something that is foreign to most beginning software engineering students: software maintenance. It is discussed in detail because maintenance accounts for a large percentage of the funds spent on software projects and because many students will begin their professional careers as software maintainers. Chapter 9 lists a set of open research problems in software engineering and provides some suggestions to help you read the existing software engineering literature. Some of the design documents, software, and spreadsheets described in this book are availableforyoutodownloadfromthewebsitehttp://imappl.org/~rjl/Software-Engineering. Any book is the result of a team effort. The efforts of the editor, Dawn Mesa at CRC Press, Taylor Francis, many anonymous reviewers, students who read through the man- uscript, and the CRC Press/Taylor Francis “book team,” especially Helena Redshaw and Schuyler Meder, are gratefully acknowledged.
- 30. xxv To the Instructor and the Reader The subject of software engineering is a vast one and is far too large to be covered in detail in any single volume of reasonable size. I have chosen to provide coverage of what I believe are the basics, at a level of detail that is appropriate in an age where much of the critical information is available for free on the World Wide Web. Nearly all topics discussed herein include some examples, often historical ones, if there is sufficient infor- mation on both the successes of software projects using the ideas behind these topics and some of the pitfalls that occurred using these ideas. State-of-the-art information is pro- vided when appropriate to those software engineering trends that can be expected to be important for the foreseeable future. The choices made in this book are strongly motivated by the likelihood that you will have many types of positions in your (I hope, long and dis- tinguished) careers in many different technology environments. The book contains a discussion of a major software project that is intended to provide a basis for any term project that the instructor may provide. I believe that a first course in software engineering is greatly improved by students formed into teams to complete a software project making use of many of the ideas in this book. There is also a case study of an actual complex project that was created using an agile development process. Of course, any team software development within an academic course is artificial, in the sense that the pressures typically involved in industry are not generally present within a single class project. Note that this section is addressed to both instructors and readers. This is because I think that students in their software teams and instructors must all work together to ensure that the learning process is as efficient as possible. Often the instructor will act as both a “customer” and a “manager’s manager,” who interfaces primarily with the software team’s leader. In some cases, the team projects will have external customers, either at the college or university, or with a representative of some potential employer. In most other situations, the instructor fills both roles. The situation in these class projects provides an idealized model of what a student may encounter in industry. The student is expected to be able to write programs (at least small ones) competently before enrolling in a software engineering course. They should be open to the idea that there are many things they need to learn in order to help create the much larger software
- 31. xxvi ◾ To the Instructor and the Reader systems that affect every part of modern life. Design techniques are illustrated, but stu- dents are expected to be at least familiar with the design representations they may need before entering the course. There is no attempt to provide extensive tutorials on dataflow diagrams and UML, for example. Even a student who expects to be an independent entre- preneur will benefit from the discussions in this book. The instructor is expected to determine which software development life cycle will be chosen for primary discussion in the course: classical waterfall model, rapid prototyping model, spiral model, open source model, agile method, or a similar life cycle. He or she may select one particular software development life cycle for use by every team in the class, allow the students to select their own particular software development life cycle, or even have the entire class work on the same project, each group using a different software devel- opment life cycle and comparing the results. The instructor may have additional goals, depending on the institution’s curriculum: assessing and improving the student’s performance in the many deliverable products that are in the form of technical reports or presentations. (It is my experience talking to hun- dreds of employers during my nine years as a department chair, that most employers place a high value on excellence in written and oral communications.) In an age when an enormous amount of source code is freely posted and there is so much sharing of ideas among students in multiple universities, there is little benefit to demand- ing that students do not copy code from other sources. Indeed, they should be encouraged to reuse code, as long as they attribute their sources for source code components, and have a systematic way of determining what the software component actually does, how it is documented, and provide some estimate of the component’s quality (perhaps by looking at the code structure).
- 32. 1 C h a p t e r 1 Introduction 1.1 THE NEED FOR SOFTWARE ENGINEERING The first commonly known use of the term software engineering was in 1968 as a title for a NATO conference on software engineering. An article by A. J. S. Rayl in a 2008 NASA magazine commemorating NASA’s fiftieth anniversary states that NASA scientist Margaret Hamilton had coined the term earlier (Rayl, 2008). The nature of computer software has changed considerably in the last forty-five or so years, with accelerated changes in the last fifteen to twenty. Software engineering has matured to the extent that a common software engineering body of knowledge, known by the acronym SWEBOK, has been developed. See the article “Software Engineering Body of Knowledge” (SWEBOK, 2013) for details. Even with this fine collection of knowledge of the discipline of software engineering, the continuing rapid changes in the field make it essential for students and practitioners to understand the basic concepts of the subject, and to understand when certain technologies and methodologies are appropriate—and when they are not. Providing this foundational knowledge is the goal of this book. You will need this foundational knowledge to be able to adapt to the inevitable changes in the way that software will be developed, deployed, and used in the future. We begin with a brief history. In the late 1970s and early 1980s, personal computers were just beginning to be available at reasonable cost. There were many computer magazines avail- able at newsstands and bookstores; these magazines were filled with articles describing how to determine the contents of specific memory locations used by computer operating systems. Other articles described algorithms and their implementation in some dialect of the BASIC programming language. High school students sometimes made more money by program- ming computers for a few months than their parents made in a year. Media coverage suggested that the possibilities for a talented, solitary programmer were unlimited. It seemed likely that the computerization of society and the fundamental changes caused by this computerization were driven by the actions of a large number of independently operating programmers. However, another trend was occurring, largely hidden from public view. Software was growing greatly in size and becoming extremely complex. The evolution of word process- ing software is a good illustration.
- 33. Random documents with unrelated content Scribd suggests to you:
- 34. Another Testimonial to the G. O. M.—In recognition of his most recent contribution to sacred literature. Mr. G. is to be presented with the freedom of the Dry-Psalter's company. THINGS ONE WOULD RATHER HAVE EXPRESSED DIFFERENTLY. She. I'm surprised to see your Wife in such a very Low Gown this cold evening, Baron! I heard she was Delicate. He. Ach, no! She vos. But now, sank Heafen, she is kvite Indelicate again!
- 35. QUOUSQUE TANDEM? OR, ONE AT A TIME. Duologue in a Dog-cart. Driver. Tc-c-c-h-k! Tc-c-c-h-k!! Officious Friend. Steady there! Wo-o-o-a!! Driver (aside). Confound the fellow! I wish he wouldn't fidget so. Officious Friend (aside). He drive tandem? Wish he'd hand the ribbons to me! Driver (aloud). Leader steps along, doesn't he? Officious Friend (aloud). Ya-a-s. Bit too fast, I fancy. Forgets that the wheeler has to do the work. Driver. Humph! Not so sure of that, in this case. Rather weedy, you know, and just a bit of a slug, if you ask me. I think they'd do better reversed—this journey, anyhow. Officious Friend (testily). Nonsense! You never have done that wheeler justice. Fact is you don't understand the horse's character, or how to get the best out of him. Now I—— Driver (adapting old Trin. Coll., Cam., Recitation). Fact is, he understood computing The odds at any bye-election; Was a dead hand at elocuting, Satire, and candidate-selection; But, like his parallel, Lord Random, He couldn't, somehow, drive a tandem. Officious Friend. What are you muttering about? You know I'm not up in poetry. As to poor Lord Random, he was a smart whip, anyhow, and though I don't agree with Z in his impertinent comparisons, still——
- 36. Driver. Still? Well, I wish you'd sit still, old fellow, and not fidget with the reins. You're fretting that leader awfully. Officious Friend. Confound the leader! Leaders, equine or—otherwise—(sotto voce: I was going to say asinine!)—are so apt to give themselves airs, and fancy they're pulling all the weight. Old G., for example! Driver. Ah! and he's not the only instance. [Sighs. Officious Friend. If G. had taken my tip, he'd never have upset the coach as he did. But handlers of the ribbons are always so obstinate. Look out! Mind that finger-post! Why, the leader nearly ran into it. Driver. Not at all, dear boy. But we'll run into something, and be both spilt if you don't leave off twitching at the reins. Officious Friend (reading finger-post). Leamington! Hythe! Aha! Now I think— as I know these roads well—if you'd just let me—— Driver (decisively). Look here, old man! You remember our Compact? Officious Friend (impatiently). Oh, of course, of course. But—I don't quite understand it as you seem to do. Driver. Humph! (Again adapting.) Your Rule of the Road seems a paradox, quite; For, in tooling our dog-cart along, If you're left with the reins you are sure to be right, If the reins are my right, it's all wrong. Officious Friend. Oh, more poetry! What a chap you are for Metaphysics and the Muses! Now the foundations of my belief are facts and figures. Driver (meditatively). It's a fact that the Tory total figures out much larger than the Liberal Unionist. Officious Friend. Oh, bother! What's that got to do with it! Our Compact——
- 37. Driver. Is ours—not Leamington's it seems. [Hums. There was a man at Leamington, Who thought it would be nice To jump into a Tory seat By help of Tory ayes. But if those ayes should be put out, It may prove no great gain Jumping into a Tory seat To please J. Ch-mb-rl-n! Officious Friend (grabbing reins). Here, I say! Whilst droning out your doggerel you're forgetting your driving. Where are you going? Look at that dashed leader! [Leader faces sharp round and fidgets. Driver (sharply). No wonder! Woa, lad, woa! Why on earth did you tug at the reins like that. I tell you that horse won't stand much more of it. Do you want a spill as well as a split? Officious Friend. Why, no! But according to our Compact, the wheeler—— Driver. According to our Compact it's my turn at the ribbons to-day. One at a time, if you please. Do you call this driving tandem? We shall never get on like this! Are you driving this dog-cart, or am I? [Left settling it.
- 39. QUOUSQUE TANDEM? OR, ONE AT A TIME. Arth-r B-lf-r (driver, to officious friend, Joe Ch-mb-rl-n). WE SHALL NEVER GET ON LIKE THIS! AM I DRIVING OR ARE YOU? Mrs. Smith. I think it dreadful that your Divorce Laws in America should be so much more lenient than they are in England. Mr. Van Rensselaer. Well, you see, my dear Madam, in England Divorce is a Luxury—while with us it is—er—a Necessity!
- 40. OUR BOOKING-OFFICE. Marco Polo Ulysses Henry Norman, having returned from a comprehensive tour in foreign parts, has set forth his experience in a handsome volume published by Fisher Unwin. The Far Fast is its alluring and well-sustained title. But why drag in Ulysses and Marco Polo? Their journeyings were on the scale of a jaunt to Switzerland as compared with Mr. Norman's. He has travelled through British, French, Spanish and Portuguese Colonies; has visited Siberia, China, Japan, Corea, Siam and Malaya. Whether in his study of political problems, his pictures of people, or his sketches of scenery, he is equally keen and habile. Anything that relates to China is peculiarly interesting just now, and Mr. Norman throws a flood of light on the state of the unwieldly empire. The description of the examination halls is instructive. The Government of China, Mr. Norman testifies, is a vast system of competitive examination tempered by bribery. Those who come out successfully in examinations—the subject-matter of which is knowledge of the works of Confucius, the history of China, and the art of writing as practised by the old masters—have berths found them under the Government. They are sent all over the country to be magistrates, generals, ship captains, engineers, without having the slightest acquaintance with details or systems over which they are put in a position of command. This fully accounts for what has taken place in recent campaigns by land and sea in the Far East. We can't all undertake Mr. Norman's monumental journey. But, adapting Sheridan's advice to his son on a certain occasion, my Baronite counsels the public to read The Far East and say they've been there. The immortal Flaccus (writes one of the Baron's assistants) has, it appears, been sojourning in Cambridge, having gone into residence there some time before he stayed at Hawarden, either for translation or perversion. I make this statement after reading a delightful little book of light verse entitled Horace at Cambridge, by Owen Seaman (London, A. D. Innes Co.). To every University man, and particularly, of course, to Cambridge men, this book will be a rare treat. But in virtue of its humour, its extreme and felicitous dexterity of workmanship both in rhyme and metre, and the aptness of its allusions, it will appeal to a far wider public. I pledge Mr. Seaman in a bumper of College Audit! and beg him to give us more of his work. The Baron de Book-Worms.
- 41. The Olympians threaten.—A real ice rink, said to be the largest in the world, is in course of construction at Olympia. Does Niagara realise, or, as in this conjunction it might be written, real-ice, the fact that its own nice invention may, by its rival, be beaten all to shivers? From Love's Labour.—What our Sir Frederic, P.R.A. (quoting the Divine Williams), will soon be saying to the accepted artist, Bid him go hang! A COCK AND BULL STORY. Air—Casabianca. [European navies were like fighting-cocks, armed to the teeth; a single spark might cause an explosion. Dr. MacGregor on the Navy Estimates.] The fighting-cock stood on the deck, His eye was rolling red, His feathers whiffled round his neck, His crest was on his head. He wore his spur above his heel, His claws were underneath, He also had a mass of steel Plate-armour on his teeth. Meanwhile the House was haggling on In one of those debates When Little England jumps upon The Navy Estimates. There Cleophas, of many wiles, Brought up his little lot, And Mr. Byles, with wreathèd smiles, Was deadly on the spot. And Labby said the bootless pay
- 42. Of navies should be stamped on; There is no boot! as strikers say In Labby's own Northampton. Then came a burst of thunder-sound That shook the very street, And lo! Macgregor's form was found To be upon its feet. He called the rates a great expense, He was a peaceful Scot, And said the talk about defense Was simply Tommy-rot. Far better for his country's good, So long allowed to bleed, If only half the money could Be spent across the Tweed. Then with a petrifying shout, Like some clamantis vox, He fetched a trumpet-note about The teeth of fighting-cocks. A simile of crew and crew All ripe for any ruction; (Refer to verses one and two, Or else the introduction). A spark might fall from out the sea, Completely unforeboded, And then the birds—where would they be? Why, they would be exploded. He looked around for some applause From front or side or rear; They never said a word, because They hadn't strength to cheer. With many an accidental jest The hearts of men were full,
- 43. But O! the thing they liked the best Was bold Macgregor's bull! SUR LE TAPIS DE BRUXELLES. However clever as a dramatic author he, M. Maurice Maeterlinck of Brussels, may be, it is rather handicapping him to be dubbed by enthusiastic but injudicious admirers The Belgian Shakspeare, though, of course, Belgian does qualify the Shakspeare, just as Brussels prefixed to sprout decides the character of that favourite and useful vegetable. M. Maeterlinck may be the coming on, or sprouting, dramatist of the future. Up to the present time there has not been much in any way to connect Belgian and English drama, so Maeterlinck may be the missing link destined to electrically illuminate all the world, which is, as the Divine Williams remarks, a stage.
- 44. PREHISTORIC PEEPS. The procedure in the Law Courts had many points of resemblance to our own but at times it was extremely difficult to give undivided attention to the Evidence! PROPOSED RULES FOR THE LADIES' UNIVERSAL ATHLETIC ASSOCIATION. (Compiled by One thoroughly Conversant with the Necessities of the Situation.) 1. The costume of every member of the Club shall be of the most elegant description. The design shall not be governed by the requirements of the game for which the uniform is required, but rather by the characteristics of the wearer. 2. Red and blue shall be worn according to the complexion of the player, and the choice of teams shall depend not upon prowess or locality, but the colour of the hair and eyes and the formation of the noses. 3. Patent leather shoes shall invariably form a part of the grande tenue of the Club, with high heels at discretion. 4. Football shall be played with a light india-rubber globe, and pushing shall be strictly forbidden. However, it shall be permissible for one player to hold an opponent tightly by the hands if the former thinks the latter is about to give it quite a hard kick with her toe. 5. No angry language will be allowed, but one member may tell another, in the height of an exciting contest, that she is a spiteful, disagreeable old thing. On very special occasions the word There! may be added with emphasis. 6. Cricket shall never be allowed to last for more than half an hour, and cups of tea shall be served to the strikers between the overs. 7. Only ladies shall be permitted to watch the game of the members, as a rule. However, at times when everyone is looking her best, individuals of the
- 45. inferior sex shall be admitted to the football ground or cricket field, on the condition that they promise not to laugh. 8. Players at football, cricket, and other games sanctioned by the Association, shall have full liberty to make their own rules and keep their own appointments. They will be usually expected to wait until a match is finished, unless called away to take a drive in the Park, or do a little shopping. 9 and Lastly. As women are as excellent as men at field sports, the members of the Club shall be entitled to the franchise.
- 46. SEQUELÆ! The General. You've had it, I suppose? The Judge. I should think so. I'm as weak as a Rat! The General. That's nothing. I'm as weak as Two Rats! The Judge. But Two Rats are stronger than One Rat! The General. If you argue, I shall Cry! THE LATEST FROM SOL. Scene—The Sun. First Solarist discovered reading local journal to Second Solarist. First Solarist. I say, have you seen what this century's Earth says? Second Solarist. No; it's much too hot for reading newspapers. First S. Why, the idiotic people on that ridiculous little planet have just discovered the existence of Helium! Second S. Dear me! How long have they taken about that? First S. About six thousand years (according to mundane measure), or thereabouts. Second S. They seem to have plenty of leisure on their hands! And now that they have found out Helium, of what use will it be to them? First S. Oh, that they will probably discover in another fix thousand years! Let's liquor! [Exeunt. Scene closes in upon an eclipse.
- 47. BALLAD OF THE UNSURPRISED JUDGE. [Mr. Justice Hawkins observed, 'I am surprised at nothing.'—Pitts v. Joseph, Times' Report, March 27.] All hail to Sir Henry, whom nothing surprises; Ye Judges and suitors, regard him with awe, As he sits up aloft on the Bench and applies his Swift mind to the shifts and the tricks of the Law. Many years has he lived, and has always seen clear things That Nox seemed to hide from our average eyes: But still, though encompassed with all sorts of queer things, He never, no never gives way to surprise. When a rogue, for example, a company-monger, Grows fat on the gain of the shares he has sold, While the public gets lean, winning nothing but hunger And a few scraps of scrip for its masses of gold; When the fat man goes further and takes to religion, A rascal in hymn-books and bibles disguised, It's a case, says Sir Henry, of rook versus pigeon, And the pigeon gets left—well, I'm hardly surprised. There's a Heath at Newmarket, and horses that run there, There are owners and jockeys, and sharpers and flats; There are some who do nicely, and some who are done there, There are loud men with pencils and satchels and hats. But the Stewards see nothing of betting or money, As they stand in the blinkers for Stewards devised; Their blindness may strike Henry Hawkins as funny, But he only smiles softly, he isn't surprised. So, here's to Sir Henry, the terror of tricksters, Of Law he's a master, and likewise a limb: His mind never once, when its purpose is fixed, errs; For cuteness there's none holds a candle to him. Let them try to deceive him, why, bless you, he's been there, And can track his way straight through a tangle of lies; And, though some might grow grey at the things he has seen there,
- 48. He never, no never, gives way to surprise.
- 49. ESSENCE OF PARLIAMENT. EXTRACTED FROM THE DIARY OF TOBY, M.P. House of Lords, Monday, March 25.—Impossible to avoid noticing depression of the Markiss when he entered House to-night. At first thought feelings of a father had overcome him. Cranborne, immediately after eloquent and energetic attack in other House of Welsh Disestablishment Bill, was struck down by indisposition, reported to be measles. That all very well. Do not wish to suggest anything wrong; but coincidence at least remarkable. Measles, the Member for Sark tells me, can be conveyed in various apparently innoxious guises. In a controversy so acrid that George Osborne Morgan has been publicly accused of profligacy, men will, it is too obvious, go any lengths. At present there is nothing that can be called evidence to connect Cranborne's sudden indisposition with current controversy. But if this mysterious attack is followed by symptoms of croup, rickets, teething, or any other complaint usually associated with happy days in the nursery, the public will know what to think. Happily it turned out that the depression of the Markiss had nothing to do with the condition of the heir of Hatfield. His sympathetic heart been touched by difficulties that environ a worthy class of men whom Lord Chancellor, conscious that Cobb's eye is upon him, has recently been making magistrates. Excellent persons, says the Markiss; self-made men. But unfortunately the process of self-manufacture does not include knowledge of the statutes at large. There is the Parish Councils Act, for example; one of those pieces of legislation with which a reckless Radical majority has embarrassed an ancient State. This law has to be administered by people unlearned in Acts of Parliament. They cannot take a step without having sixteen volumes of the statutes at large tucked under their arms. What the benevolent and thoughtful Markiss suggested was, that in all future legislation there shall be reprinted sections of Acts of Parliament referred to in text of Bill. House listened with admiration to statesman who, his mind engrossed by imperial cares, could find time to think out schemes for easing the pathway of working-men magistrates, and assisting operation of Parish Councils Act. Only, somehow, there was left on minds of hearers a strong impression that working-men magistrates are a mistake, and the Parish Councils Act a public injury, of which the Government ought to be more than ordinarily ashamed.
- 50. Business done.—More speech-making round Welsh Disestablishment Bill in Commons. Direfully dull. House of Commons, Tuesday.—Speakers may come, and Speakers may go, said the Member for Sark, but as long as the House of Commons produces men like Vicary Gibbs the institution is safe, and the State rocks safely on its everlasting foundations. It was, you will remember, Vicary who directly, though undesignedly, led to the row on that famous night in June when Home-Rule Committee was closured. Vicary shares with Heaven the peculiarity that order is his first law. On that particular night somebody had said something, and Vicary wanted to have his words taken down. Amid growing uproar his observations were inaudible to the Chair, and his presence undistinguishable. Some men would thereupon have resumed their seat. Vicary, his soul athirst to have something 'taken down,' moved on to the Front Opposition Bench, and shouted his desire in Mellor's left ear. Then Logan suddenly loomed large on the scene. Hayes Fisher reached forth a red right hand and shook him by the collar. Next an anonymous Irish Member fell over the bench on to Saunderson's knee, and was there incontinently but heartily pummelled. After that chaos; all arising out of Vicary Gibbs's insatiable, uncontrollable desire to have something 'taken down' in the sacred name of order. These musings on the mighty past were occasioned by Vicary once more unexpectedly, but sternly and effectively, interposing as the custodian of order. Weir broken out in epidemic of questions; puts down eleven on the paper; runs them up to the full score by supplementary questions, invariably prefaced by the formula Is the right hon. gentleman A. Weir that——? A poor joke, its only flash of humour being in the subtly varied tone with which the Speaker eleven times pronounced the words, Mr. Weir. Also grotesquely funny to hear the reverberation of the deep chest notes, in which Weir, with tragic sweep of pince-nez on to his nose, said in succession, Ques-ti-on one, Ques-ti-on two, and so on. Touch of tragedy came in when Vicary, managing to throw into tone and form of question conviction that Squire of Malwood was secretly at bottom of the whole business, asked him whether this was not abuse of forms of the House, calculated to lead to curtailment of valuable privilege. No use Squire assuming air of innocence. House knew all about it. Refreshed and revived by Vicary's timely vindication of law and order, proceeded to business. Business done.—Fourth night's Debate on Welsh Church Disestablishment Bill. The still prevalent dulness varied by speech from Plunket; witched the House
- 51. by music of stately though simple eloquence. Thursday.—Desperate dulness of week further relieved by discovery of new game. Tommy Bowles, Inv. House just got into Committee of Supply; Vote on Account under discussion; this covers multitudinous items; every spending department of State concerned. When Committee of Supply deals with Army Estimates, Cawmell-Bannerman and the Winsome Woodall in their places. The rest of Ministers may go away, knowing that everything is well. The same when Navy Estimates are on, or when particular votes in the Civil Service Estimates are to the fore. Ministers of particular departments affected in their place; the rest at liberty. To-night, as no one knew who might be called on next, all agreed to stop away—all but the faithful Hibbert. Cap'en Tommy, as usual, aloft in the Crow's Nest, perceived this weak point. Hauling on the bowline, and making all taut, he bore down swiftly on the Treasury Bench, and hailed it for the President of the Board of Trade. Wanted to talk to Bryce, he said, about lighthouses. No one knew better than Tommy that Bryce wasn't aboard. According to regulations, he ought to have been. Search made for him. Presently brought in with hands in pockets, trying to whistle, and otherwise present appearance of indifference. But a poor show. Encouraged by this success, Private Hanbury, observing Robertson was among absentees, addressed question to Civil Lord of Admiralty about Peterhead Harbour. Hibbert's agony of mind at this juncture would have softened harder hearts. An elderly hen, that has counted its brood seven times, on each occasion finding one or two missing, not more perturbed. Looked up and down Treasury Bench. Robertson, not within sight; might be below the Gangway. Vain hope. For Members opposite interest in Peterhead Harbour growing keener and more urgent. Francis Powell, usually mild-mannered man, went so far as to move to report progress. Mellor declined to put question. Very well, said the Blameless Bartley, with air of martyr. We must go on talking about Peterhead Harbour till the Minister comes in. So he did, and when he ran dry Tomlinson (having meanwhile ascertained where Peterhead Harbour is) took up the wondrous tale. Talking when Hibbert reappeared, his breast now swelling with maternal pride and satisfaction. He had found the lost chick, and clucked low notes of supreme content as he brought him back to the roost. Pretty to see how, Civil Lord in his place, all
- 52. Sir John Leng strongly objects to Lion-taming Exhibitions. interest in Peterhead Harbour subsided, Busy B's turning their attention to alleged felonious underrating of Government property. Business done.—Vote on Account through Committee. Sir John Leng calls Asquith's attention to dangerous occupation of lion-tamers. All very well, he says, for doughty knight like me. But these poor fellows with families shouldn't be allowed to run risks. Friday Night.—What's the business at to-night's sitting? asked Squire of Malwood, looking over Orders of the Day. Home Rule all round? Very well. Shall give practical proof of adherence to principle by stopping at home. John Morley did same, most other Ministers following suit. Cawmel-Bannerman sacrificed himself on altar of country. But insisted that he might at least dine out in interval between morning and evening sitting that made last day of Parliamentary week. His snowy shirt front gave air of almost reckless joviality to desolate Treasury Bench. Prince Arthur, not to be outdone in chivalry, also looked in after dinner, brightening up Front Bench opposite Minister for War. But two swallows don't make a summer, nor two gentlemen in evening dress a festive party. Trevelyan only man in earnest, and he terribly so. Business done.—Home Rule all round decreed by majority of 26 in House of 230. THE NEW CHIVALRY.
- 53. [In a case heard before Judge French at Shoreditch, the Judge remarked that the plea of infancy was not a very meritorious one. 'No,' replied the defendant, 'but it's jolly convenient.'—The Globe.] When, toddling along with a swell, I pretend Not to notice a shabby (though excellent) friend,— Well, it is not lofty, to that I assent, But then, it's so jolly con-ve-ni-ent! When a tenant has built up a business with care, And saved to his landlord all cost of repair, It may not be kind just to double his rent, Yet somehow it's jolly con-ve-ni-ent! If you've suffered, in polling, a moral defeat, Then to grab each Committee and every paid seat Some might say was the act of a cad, not a gent; But, you see, it's so jolly con-ve-ni-ent! Then your house is for sale, and, if gifted with brains, You, of course, do not mention the damp, rats, and drains Which is not what the ancients by honesty meant, But, still, it is jolly con-ve-ni-ent! Transcriber's Note Page 159: Footnote [*] refers to [www.] gutenberg.org/ebooks/30739 Page 168: 'progess' corrected to 'progress'. Francis Powell, usually mild-mannered man, went so far as to move to report progress.
- 54. *** END OF THE PROJECT GUTENBERG EBOOK PUNCH, OR THE LONDON CHARIVARI, VOL. 108, APRIL 6, 1895 *** Updated editions will replace the previous one—the old editions will be renamed. Creating the works from print editions not protected by U.S. copyright law means that no one owns a United States copyright in these works, so the Foundation (and you!) can copy and distribute it in the United States without permission and without paying copyright royalties. Special rules, set forth in the General Terms of Use part of this license, apply to copying and distributing Project Gutenberg™ electronic works to protect the PROJECT GUTENBERG™ concept and trademark. Project Gutenberg is a registered trademark, and may not be used if you charge for an eBook, except by following the terms of the trademark license, including paying royalties for use of the Project Gutenberg trademark. If you do not charge anything for copies of this eBook, complying with the trademark license is very easy. You may use this eBook for nearly any purpose such as creation of derivative works, reports, performances and research. Project Gutenberg eBooks may be modified and printed and given away—you may do practically ANYTHING in the United States with eBooks not protected by U.S. copyright law. Redistribution is subject to the trademark license, especially commercial redistribution. START: FULL LICENSE
- 55. THE FULL PROJECT GUTENBERG LICENSE
- 56. PLEASE READ THIS BEFORE YOU DISTRIBUTE OR USE THIS WORK To protect the Project Gutenberg™ mission of promoting the free distribution of electronic works, by using or distributing this work (or any other work associated in any way with the phrase “Project Gutenberg”), you agree to comply with all the terms of the Full Project Gutenberg™ License available with this file or online at www.gutenberg.org/license. Section 1. General Terms of Use and Redistributing Project Gutenberg™ electronic works 1.A. By reading or using any part of this Project Gutenberg™ electronic work, you indicate that you have read, understand, agree to and accept all the terms of this license and intellectual property (trademark/copyright) agreement. If you do not agree to abide by all the terms of this agreement, you must cease using and return or destroy all copies of Project Gutenberg™ electronic works in your possession. If you paid a fee for obtaining a copy of or access to a Project Gutenberg™ electronic work and you do not agree to be bound by the terms of this agreement, you may obtain a refund from the person or entity to whom you paid the fee as set forth in paragraph 1.E.8. 1.B. “Project Gutenberg” is a registered trademark. It may only be used on or associated in any way with an electronic work by people who agree to be bound by the terms of this agreement. There are a few things that you can do with most Project Gutenberg™ electronic works even without complying with the full terms of this agreement. See paragraph 1.C below. There are a lot of things you can do with Project Gutenberg™ electronic works if you follow the terms of this agreement and help preserve free future access to Project Gutenberg™ electronic works. See paragraph 1.E below.
- 57. 1.C. The Project Gutenberg Literary Archive Foundation (“the Foundation” or PGLAF), owns a compilation copyright in the collection of Project Gutenberg™ electronic works. Nearly all the individual works in the collection are in the public domain in the United States. If an individual work is unprotected by copyright law in the United States and you are located in the United States, we do not claim a right to prevent you from copying, distributing, performing, displaying or creating derivative works based on the work as long as all references to Project Gutenberg are removed. Of course, we hope that you will support the Project Gutenberg™ mission of promoting free access to electronic works by freely sharing Project Gutenberg™ works in compliance with the terms of this agreement for keeping the Project Gutenberg™ name associated with the work. You can easily comply with the terms of this agreement by keeping this work in the same format with its attached full Project Gutenberg™ License when you share it without charge with others. 1.D. The copyright laws of the place where you are located also govern what you can do with this work. Copyright laws in most countries are in a constant state of change. If you are outside the United States, check the laws of your country in addition to the terms of this agreement before downloading, copying, displaying, performing, distributing or creating derivative works based on this work or any other Project Gutenberg™ work. The Foundation makes no representations concerning the copyright status of any work in any country other than the United States. 1.E. Unless you have removed all references to Project Gutenberg: 1.E.1. The following sentence, with active links to, or other immediate access to, the full Project Gutenberg™ License must appear prominently whenever any copy of a Project Gutenberg™ work (any work on which the phrase “Project
- 58. Gutenberg” appears, or with which the phrase “Project Gutenberg” is associated) is accessed, displayed, performed, viewed, copied or distributed: This eBook is for the use of anyone anywhere in the United States and most other parts of the world at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at www.gutenberg.org. If you are not located in the United States, you will have to check the laws of the country where you are located before using this eBook. 1.E.2. If an individual Project Gutenberg™ electronic work is derived from texts not protected by U.S. copyright law (does not contain a notice indicating that it is posted with permission of the copyright holder), the work can be copied and distributed to anyone in the United States without paying any fees or charges. If you are redistributing or providing access to a work with the phrase “Project Gutenberg” associated with or appearing on the work, you must comply either with the requirements of paragraphs 1.E.1 through 1.E.7 or obtain permission for the use of the work and the Project Gutenberg™ trademark as set forth in paragraphs 1.E.8 or 1.E.9. 1.E.3. If an individual Project Gutenberg™ electronic work is posted with the permission of the copyright holder, your use and distribution must comply with both paragraphs 1.E.1 through 1.E.7 and any additional terms imposed by the copyright holder. Additional terms will be linked to the Project Gutenberg™ License for all works posted with the permission of the copyright holder found at the beginning of this work. 1.E.4. Do not unlink or detach or remove the full Project Gutenberg™ License terms from this work, or any files
- 59. containing a part of this work or any other work associated with Project Gutenberg™. 1.E.5. Do not copy, display, perform, distribute or redistribute this electronic work, or any part of this electronic work, without prominently displaying the sentence set forth in paragraph 1.E.1 with active links or immediate access to the full terms of the Project Gutenberg™ License. 1.E.6. You may convert to and distribute this work in any binary, compressed, marked up, nonproprietary or proprietary form, including any word processing or hypertext form. However, if you provide access to or distribute copies of a Project Gutenberg™ work in a format other than “Plain Vanilla ASCII” or other format used in the official version posted on the official Project Gutenberg™ website (www.gutenberg.org), you must, at no additional cost, fee or expense to the user, provide a copy, a means of exporting a copy, or a means of obtaining a copy upon request, of the work in its original “Plain Vanilla ASCII” or other form. Any alternate format must include the full Project Gutenberg™ License as specified in paragraph 1.E.1. 1.E.7. Do not charge a fee for access to, viewing, displaying, performing, copying or distributing any Project Gutenberg™ works unless you comply with paragraph 1.E.8 or 1.E.9. 1.E.8. You may charge a reasonable fee for copies of or providing access to or distributing Project Gutenberg™ electronic works provided that: • You pay a royalty fee of 20% of the gross profits you derive from the use of Project Gutenberg™ works calculated using the method you already use to calculate your applicable taxes. The fee is owed to the owner of the Project Gutenberg™ trademark, but he has agreed to donate royalties under this paragraph to the Project Gutenberg Literary Archive Foundation. Royalty
- 60. Welcome to our website – the ideal destination for book lovers and knowledge seekers. With a mission to inspire endlessly, we offer a vast collection of books, ranging from classic literary works to specialized publications, self-development books, and children's literature. Each book is a new journey of discovery, expanding knowledge and enriching the soul of the reade Our website is not just a platform for buying books, but a bridge connecting readers to the timeless values of culture and wisdom. With an elegant, user-friendly interface and an intelligent search system, we are committed to providing a quick and convenient shopping experience. Additionally, our special promotions and home delivery services ensure that you save time and fully enjoy the joy of reading. Let us accompany you on the journey of exploring knowledge and personal growth! textbookfull.com