Ronald J. Leach
Howard University
Washington, DC, USA
CHAPMAN & HALL/CRC INNOVATIONS
IN SOFTWARE ENGINEERING AND SOFTWARE DEVELOPMENT
IN SOFTWARE ENGINEERING AND SOFTWARE DEVELOPMENT
 |
| Introduction to Software Engineering 2nd |
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 information 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 provided 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 distinguished) 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 systems that affect every part of modern life. Design techniques are illustrated, but students 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 entrepreneur 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 development 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 hundreds 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 demanding 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).
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 organizations. 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 computer 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 development 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 available 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.”
Lack of student exposure to, and interaction with, very large systems has other ramifications. 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 computers, 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 organizations 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 maintain 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 companies 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 application” software often used for the college admissions process. In its initial rollout in 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 process. 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 programming 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).
The microprocessors often relate safety status information from all the elevator company’s installed elevators back to a database in a single communications center. In most elevator 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 expensive 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 elevator 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 collection 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 problems 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 applications 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 complex 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 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 subsystems 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 commonly 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 application 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 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 engineering, 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 professional 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 integration; 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 process, 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 requirements understanding, even if there is no known customer, such as may be the case for 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 interoperability and user interfaces are discussed here as part of the requirements process. The requirements traceability matrix developed here is used throughout the book. The chapter 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 implementation techniques. This chapter emphasizes source code file organization, naming conventions, 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; students who read through the manuscript; and the Taylor & Francis “book team,” especially Jay Margolis and Adel Rosario, are gratefully acknowledged.
Screenshot
Purchase Now !
Just with Paypal
Just with Paypal
Product details
Price
|
|
|---|---|
File Size
| 28,222 KB |
Pages
|
420 p |
File Type
|
PDF format |
ISBN-13
| 978-1-4987-0528-8 |
Copyright
| 2016 by Taylor & Francis Group, LLC |
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 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
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
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
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
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
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
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
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
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
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
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
8.1 INTRODUCTION 335
8.2 CORRECTIVE SOFTWARE MAINTENANCE 338
8.3 ADAPTIVE SOFTWARE MAINTENANCE 343
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
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
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
●▬▬▬▬▬❂❂❂▬▬▬▬▬●
●▬▬❂❂▬▬●
●▬❂▬●
●❂●
═════● ●═════
