1

What is it? Computer software is a work prod- uct that software professionals build and then support over many years. These work prod- ucts include programs that execute within computers of any size and architecture. Soft- ware engineering encompasses a process, a collection of methods (practice), and an array of tools that allow professionals to build high- quality computer software.

Who does it? Software engineers build and support software, and virtually everyone in the industrialized world uses it. Software engineers apply the software engineering process.

Why is it important? Software engineering is important because it enables us to build com- plex systems in a timely manner and with high quality. It imposes discipline to work that can become quite chaotic, but it also allows the

people who build computer software to adapt their approach in a manner that best suits their needs.

What are the steps? You build computer soft- ware like you build any successful product, by applying an agile, adaptable process that leads to a high-quality result that meets the needs of the people who will use the product.

What is the work product? From the software engineer’s point of view, the work product is the set of programs, content (data), and other work products that support computer soft- ware. But from the user’s point of view, the work product is a tool or product that some- how makes the user’s world better.

How do I ensure that I’ve done it right? Read the remainder of this book, select those ideas that are applicable to the software that you build, and apply them to your work.

Q u i c k L o o k

C H A P T E R

1 As he finished showing me the latest build of one of the world’s most popular first-person shooter video games, the young developer laughed.

“You’re not a gamer, are you?” he asked. I smiled. “How’d you guess?” The young man was dressed in shorts and a tee shirt. His leg bounced up and

down like a piston, burning the nervous energy that seemed to be commonplace among his co-workers.

Software and Software Engineering

application domains . . . . . . . . . . . . . . . . . . . . . . 7 failure curves . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 framework activities . . . . . . . . . . . . . . . . . . . . . 10 general principles . . . . . . . . . . . . . . . . . . . . . . . 14 legacy software . . . . . . . . . . . . . . . . . . . . . . . . . . 8 principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 problem solving . . . . . . . . . . . . . . . . . . . . . . . . . 12 SafeHome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 software,

definition . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 nature of . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 questions about . . . . . . . . . . . . . . . . . . . . . . . 4

software engineering, definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 practice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

umbrella activities . . . . . . . . . . . . . . . . . . . . . . . 11 wear . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

k e y c o n c e p t s

2 CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING

“Because if you were,” he said, “you’d be a lot more excited. You’ve gotten a peek at our next generation product and that’s something that our customers would kill for  .  .  . no pun intended.”

We sat in a development area at one of the most successful game developers on the planet. Over the years, earlier generations of the game he demoed sold over 50 million copies and generated billions of dollars in revenue.

“So, when will this version be on the market?” I asked. He shrugged. “In about five months, and we’ve still got a lot of work to do.” He had responsibility for game play and artificial intelligence functionality in an

application that encompassed more than three million lines of code. “Do you guys use any software engineering techniques?” I asked, half-expecting

that he’d laugh and shake his head. He paused and thought for a moment. Then he slowly nodded. “We adapt them to

our needs, but sure, we use them.” “Where?” I asked, probing. “Our problem is often translating the requirements the creatives give us.” “The creatives?” I interrupted. “You know, the guys who design the story, the characters, all the stuff that make

the game a hit. We have to take what they give us and produce a set of technical requirements that allow us to build the game.”

“And after the requirements are established?” He shrugged. “We have to extend and adapt the architecture of the previous version

of the game and create a new product. We have to create code from the requirements, test the code with daily builds, and do lots of things that your book recommends.”

“You know my book?” I was honestly surprised. “Sure, used it in school. There’s a lot there.” “I’ve talked to some of your buddies here, and they’re more skeptical about the

stuff in my book.” He frowned. “Look, we’re not an IT department or an aerospace company, so we

have to customize what you advocate. But the bottom line is the same—we need to produce a high-quality product, and the only way we can accomplish that in a repeat- able fashion is to adapt our own subset of software engineering techniques.”

“And how will your subset change as the years pass?” He paused as if to ponder the future. “Games will become bigger and more com-

plex, that’s for sure. And our development timelines will shrink as more competition emerges. Slowly, the games themselves will force us to apply a bit more development discipline. If we don’t, we’re dead.”

*****

Computer software continues to be the single most important technology on the world stage. And it’s also a prime example of the law of unintended consequences. Sixty years ago no one could have predicted that software would become an indispensable technology for business, science, and engineering; that software would enable the creation of new technologies (e.g., genetic engineering and nanotechnology), the extension of existing technologies (e.g., telecommunications), and the radical change in older technologies (e.g., the media); that software would be the driving force behind the personal computer revolution; that software applications would be purchased by

CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING 3

consumers using their mobile devices; that software would slowly evolve from a prod- uct to a service as “on-demand” software companies deliver just-in-time functionality via a Web browser; that a software company would become larger and more influen- tial than all industrial-era companies; or that a vast software-driven network would evolve and change everything from library research to consumer shopping to political discourse to the dating habits of young (and not so young) adults.

As software’s importance has grown, the software community has continually attempted to develop technologies that will make it easier, faster, and less expensive to build and support high-quality computer programs. Some of these technologies are targeted at a specific application domain (e.g., website design and implementation); others focus on a technology domain (e.g., object-oriented systems or aspect-oriented programming); and still others are broad based (e.g., operating systems such as Linux). However, we have yet to develop a software technology that does it all, and the likeli- hood of one arising in the future is small. And yet, people bet their jobs, their com- forts, their safety, their entertainment, their decisions, and their very lives on computer software. It better be right.

This book presents a framework that can be used by those who build computer software—people who must get it right. The framework encompasses a process, a set of methods, and an array of tools that we call software engineering.

To build software that is ready to meet the challenges of the twenty-first century, you must recognize a few simple realities:

∙ Software has become deeply embedded in virtually every aspect of our lives. The number of people who have an interest in the features and functions provided by a specific application1 has grown dramatically. A concerted effort should be made to understand the problem before a software solution is developed.

∙ The information technology requirements demanded by individuals, businesses, and governments grow increasingly complex with each passing year. Large teams of people now create computer programs. Sophisticated software that was once implemented in a predictable, self-contained computing environment is now embedded inside everything from consumer electronics to medical devices to autonomous vehicles. Design has become a pivotal activity.

∙ Individuals, businesses, and governments increasingly rely on software for strategic and tactical decision making as well as day-to-day operations and control. If the software fails, people and major enterprises can experience anything from minor inconvenience to catastrophic consequences. Software should exhibit high quality.

∙ As the perceived value of a specific application grows, the likelihood is that its user base and longevity will also grow. As its user base and time in use increase, demands for adaptation and enhancement will also grow. Software should be maintainable.

These simple realities lead to one conclusion: Software in all its forms and across all its application domains should be engineered. And that leads us to the topic of this book—software engineering.

1 We will call these people “stakeholders” later in this book.

4 CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING

1 .1 th e nat u r e o f so f t wa r e

Today, software takes on a dual role. It is a product, and the vehicle for delivering a product. As a product, it delivers the computing potential embodied by computer hardware or, more broadly, by a network of computers that are accessible by local hardware. Whether it resides within a mobile device, on the desktop, in the cloud, or within a mainframe computer or autonomous machine, software is an information transformer—producing, managing, acquiring, modifying, displaying, or transmitting information that can be as simple as a single bit or as complex as an augmented- reality representation derived from data acquired from dozens of independent sources and then overlaid on the real world. As the vehicle used to deliver a product, software acts as the basis for the control of the computer (operating systems), the communica- tion of information (networks), and the creation and control of other programs (soft- ware tools and environments).

Software delivers the most important product of our time—information. It trans- forms personal data (e.g., an individual’s financial transactions) so that the data can be more useful in a local context; it manages business information to enhance com- petitiveness; it provides a gateway to worldwide information networks (e.g., the Inter- net); and provides the means for acquiring information in all its forms. It also provides a vehicle that can threaten personal privacy and a gateway that enables those with malicious intent to commit criminal acts.

The role of computer software has undergone significant change over the last 60 years. Dramatic improvements in hardware performance, profound changes in com- puting architectures, vast increases in memory and storage capacity, and a wide vari- ety of exotic input and output options have all precipitated more sophisticated and complex computer-based systems. Sophistication and complexity can produce dazzling results when a system succeeds, but they can also pose huge problems for those who must build and protect complex systems.

Today, a huge software industry has become a dominant factor in the economies of the industrialized world. Teams of software specialists, each focusing on one part of the technology required to deliver a complex application, have replaced the lone program- mer of an earlier era. And yet, the questions that were asked of the lone programmer are the same questions that are asked when modern computer-based systems are built:2

∙ Why does it take so long to get software finished? ∙ Why are development costs so high? ∙ Why can’t we find all errors before we give the software to our customers? ∙ Why do we spend so much time and effort maintaining existing programs? ∙ Why do we continue to have difficulty in measuring progress as software is

being developed and maintained?

2 In an excellent book of essays on the software business, Tom DeMarco [DeM95] argues the counterpoint. He states: “Instead of asking why software costs so much, we need to begin asking ‘What have we done to make it possible for today’s software to cost so little?’ The answer to that question will help us continue the extraordinary level of achievement that has always distinguished the software industry.”

CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING 5

These, and many other questions, are a manifestation of the concern about software and how it is developed—a concern that has led to the adoption of software engineer- ing practice.

1.1.1 Defining Software Today, most professionals and many members of the public at large feel that they understand software. But do they?

A textbook description of software might take the following form:

Software is: (1) instructions (computer programs) that when executed provide desired features, function, and performance; (2) data structures that enable the programs to ade- quately manipulate information; and (3) descriptive information in both hard copy and virtual forms that describes the operation and use of the programs.

There is no question that other more complete definitions could be offered. But a more formal definition probably won’t measurably improve your understanding. To accomplish that, it’s important to examine the characteristics of software that make it different from other things that human beings build. Software is a logical rather than a physical system element. Therefore, software has one fundamental characteristic that makes it considerably different from hardware: Software doesn’t “wear out.”

Figure 1.1 depicts failure rate as a function of time for hardware. The relationship, often called the “bathtub curve,” indicates that hardware exhibits relatively high fail- ure rates early in its life (these failures are often attributable to design or manufactur- ing defects); defects are corrected, and the failure rate drops to a steady-state level (hopefully, quite low) for some period of time. As time passes, however, the failure rate rises again as hardware components suffer from the cumulative effects of dust,

Figure 1.1

"Wear out"

Time

Fa ilu

re ra

te

"Infant mortality"

Failure curve for hardware

6 CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING

vibration, abuse, temperature extremes, and many other environmental maladies. Stated simply, the hardware begins to wear out.

Software is not susceptible to the environmental maladies that cause hardware to wear out. In theory, therefore, the failure rate curve for software should take the form of the “idealized curve” shown in Figure 1.2. Undiscovered defects will cause high failure rates early in the life of a program. However, these are corrected and the curve flattens as shown. The idealized curve is a gross oversimplification of actual failure models for software. However, the implication is clear—software doesn’t wear out. But it does deteriorate!

This seeming contradiction can best be explained by considering the actual curve in Figure 1.2. During its life,3 software will undergo change. As changes are made, it is likely that errors will be introduced, causing the failure rate curve to spike as shown in the “actual curve” (Figure 1.2). Before the curve can return to the original steady- state failure rate, another change is requested, causing the curve to spike again. Slowly, the minimum failure rate level begins to rise—the software is deteriorating due to change.

Another aspect of wear illustrates the difference between hardware and software. When a hardware component wears out, it is replaced by a spare part. There are no software spare parts. Every software failure indicates an error in design or in the process through which design was translated into machine executable code. Therefore, the software maintenance tasks that accommodate requests for change involve consid- erably more complexity than hardware maintenance.

Figure 1.2

Increased failure rate due to side e�ects

Actual curve

Idealized curve

Time

Fa ilu

re ra

te

Change

3 In fact, from the moment that development begins and long before the first version is deliv- ered, changes may be requested by a variety of different stakeholders.

Failure curves for software

CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING 7

1.1.2 Software Application Domains Today, seven broad categories of computer software present continuing challenges for software engineers:

System software. A collection of programs written to service other programs. Some system software (e.g., compilers, editors, and file management utilities) pro- cesses complex, but determinate,4 information structures. Other systems applications (e.g., operating system components, drivers, networking software, telecommuni- cations processors) process largely indeterminate data.

Application software. Stand-alone programs that solve a specific business need. Applications in this area process business or technical data in a way that facilitates business operations or management/technical decision making.

Engineering/scientific software. A broad array of “number-crunching” or data science programs that range from astronomy to volcanology, from automotive stress analysis to orbital dynamics, from computer-aided design to consumer spending habits, and from genetic analysis to meteorology.

Embedded software. Resides within a product or system and is used to implement and control features and functions for the end user and for the system itself. Embedded software can perform limited and esoteric functions (e.g., key pad control for a micro- wave oven) or provide significant function and control capability (e.g., digital functions in an automobile such as fuel control, dashboard displays, and braking systems).

Product-line software. Composed of reusable components and designed to provide specific capabilities for use by many different customers. It may focus on a limited and esoteric marketplace (e.g., inventory control products) or attempt to address the mass consumer market.

Web/mobile applications. This network-centric software category spans a wide array of applications and encompasses browser-based apps, cloud computing, service-based computing, and software that resides on mobile devices.

Artificial intelligence software. Makes use of heuristics5 to solve complex prob- lems that are not amenable to regular computation or straightforward analysis. Applications within this area include robotics, decision-making systems, pattern rec- ognition (image and voice), machine learning, theorem proving, and game playing.

Millions of software engineers worldwide are hard at work on software projects in one or more of these categories. In some cases, new systems are being built, but in many others, existing applications are being corrected, adapted, and enhanced. It is not uncommon for a young software engineer to work on a program that is older than she is! Past generations of software people have left a legacy in each of the categories we have discussed. Hopefully, the legacy to be left behind by this generation will ease the burden on future software engineers.

4 Software is determinate if the order and timing of inputs, processing, and outputs is predict- able. Software is indeterminate if the order and timing of inputs, processing, and outputs cannot be predicted in advance.

5 The use of heuristics is an approach to problem solving that employs a practical method or “rule of thumb” not guaranteed to be perfect, but sufficient for the task at hand.

8 CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING

1.1.3 Legacy Software Hundreds of thousands of computer programs fall into one of the seven broad appli- cation domains discussed in the preceding subsection. Some of these are state-of-the- art software. But other programs are older, in some cases much older.

These older programs—often referred to as legacy software—have been the focus of continuous attention and concern since the 1960s. Dayani-Fard and his colleagues [Day99] describe legacy software in the following way:

Legacy software systems  .  .  . were developed decades ago and have been continually modified to meet changes in business requirements and computing platforms. The pro- liferation of such systems is causing headaches for large organizations who find them costly to maintain and risky to evolve.

These changes may create an additional side effect that is often present in legacy software—poor quality.6 Legacy systems sometimes have inextensible designs, convoluted code, poor or nonexistent documentation, test cases and results that were never archived, and a poorly managed change history. The list can be quite long. And yet, these systems often support “core functions and are indispensable to the business.” What to do?

The only reasonable answer may be: Do nothing, at least until the legacy system must undergo some significant change. If the legacy software meets the needs of its users and runs reliably, it isn’t broken and does not need to be fixed. However, as time passes, legacy systems often evolve for one or more of the following reasons:

∙ The software must be adapted to meet the needs of new computing environ- ments or technology.

∙ The software must be enhanced to implement new business requirements. ∙ The software must be extended to make it work with other more modern

systems or databases. ∙ The software must be re-architected to make it viable within an evolving

computing environment.

When these modes of evolution occur, a legacy system must be reengineered so that it remains viable in the future. The goal of modern software engineering is to “devise methodologies that are founded on the notion of evolution; that is, the notion that software systems change continually, new software systems can be built from the old ones, and  .  .  . all must interact and cooperate with each other” [Day99].

1 .2 De f i n i ng t h e Di s c i p L i n e

The IEEE [IEE17] has developed the following definition for software engineering:

Software Engineering: The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.

6 In this case, quality is judged based on modern software engineering thinking—a somewhat unfair criterion since some modern software engineering concepts and principles may not have been well understood at the time that the legacy software was developed.

CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING 9

And yet, a “systematic, disciplined, and quantifiable” approach applied by one software team may be burdensome to another. We need discipline, but we also need adaptability and agility.

Software engineering is a layered technology. Referring to Figure 1.3, any engi- neering approach (including software engineering) must rest on an organizational commitment to quality. You may have heard of total quality management (TQM) or Six Sigma, and similar philosophies7 that foster a culture of continuous process improvement. It is this culture that ultimately leads to more effective approaches to software engineering. The bedrock that supports software engineering is a quality focus.

The foundation for software engineering is the process layer. The software engi- neering process is the glue that holds the technology layers together and enables rational and timely development of computer software. Process defines a framework that must be established for effective delivery of software engineering technology. The software process forms the basis for management control of software projects and establishes the context in which technical methods are applied, work products (mod- els, documents, data, reports, forms, etc.) are produced, milestones are established, quality is ensured, and change is properly managed.

Software engineering methods provide the technical how-to’s for building software. Methods encompass a broad array of tasks that include communication, requirements analysis, design modeling, program construction, testing, and support. Software engi- neering methods rely on a set of basic principles that govern each area of the technol- ogy and include modeling activities and other descriptive techniques.

Software engineering tools provide automated or semi-automated support for the process and the methods. When tools are integrated so that information created by one tool can be used by another, a system for the support of software development, called computer-aided software engineering, is established.

1 .3 th e so f t wa r e pro c e s s

A process is a collection of activities, actions, and tasks that are performed when some work product is to be created. An activity strives to achieve a broad objective (e.g., communication with stakeholders) and is applied regardless of the application domain, size of the project, complexity of the effort, or degree of rigor with which

7 Quality management and related approaches are discussed throughout Part Three of this book.

Figure 1.3

Tools

Methods

Process

A quality focus

Software engineering layers

10 CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING

software engineering is to be applied. An action (e.g., architectural design) encom- passes a set of tasks that produce a major work product (e.g., an architectural model). A task focuses on a small, but well-defined objective (e.g., conducting a unit test) that produces a tangible outcome.

In the context of software engineering, a process is not a rigid prescription for how to build computer software. Rather, it is an adaptable approach that enables the peo- ple doing the work (the software team) to pick and choose the appropriate set of work actions and tasks. The intent is always to deliver software in a timely manner and with sufficient quality to satisfy those who have sponsored its creation and those who will use it.

1.3.1 The Process Framework A process framework establishes the foundation for a complete software engineering process by identifying a small number of framework activities that are applicable to all software projects, regardless of their size or complexity. In addition, the process framework encompasses a set of umbrella activities that are applicable across the entire software process. A generic process framework for software engineering encom- passes five activities:

Communication. Before any technical work can commence, it is critically important to communicate and collaborate with the customer (and other stakeholders).8 The intent is to understand stakeholders’ objectives for the project and to gather require- ments that help define software features and functions.

Planning. Any complicated journey can be simplified if a map exists. A software project is a complicated journey, and the planning activity creates a “map” that helps guide the team as it makes the journey. The map—called a software project plan— defines the softwa