1. Describe Agile development for software projects in your own words.
2. What data points are needed to make the go, no-go decision during the assessment of an evolutionary prototype?
3. How can a software manager increase the efficiency in their software team?
Need 2-3 pages in APA format with peer-reviewed citations. No need for introduction or conclusion.
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 software engineering work by describing the technical tasks to be con- ducted, the risks that are likely, the resources that will be required, the work products to be produced, and a work schedule.
Modeling. Whether you’re a landscaper, a bridge builder, an aeronautical engineer, a carpenter, or an architect, you work with models every day. You create a “sketch” of the thing so that you’ll understand the big picture—what it will look like architec- turally, how the constituent parts fit together, and many other characteristics. If required, you refine the sketch into greater and greater detail in an effort to better understand the problem and how you’re going to solve it. A software engineer does the same thing by creating models to better understand software requirements and the design that will achieve those requirements.
Construction. What you design must be built. This activity combines code genera- tion (either manual or automated) and the testing that is required to uncover errors in the code.
8 A stakeholder is anyone who has a stake in the successful outcome of the project—business managers, end users, software engineers, support people, and so forth. Rob Thomsett jokes that, “a stakeholder is a person holding a large and sharp stake. . . . If you don’t look after your stakeholders, you know where the stake will end up.”
CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING 11
Deployment. The software (as a complete entity or as a partially completed incre- ment) is delivered to the customer who evaluates the delivered product and provides feedback based on the evaluation.
These five generic framework activities can be used during the development of small, simple programs; the creation of Web applications; and for the engineering of large, complex computer-based systems. The details of the software process will be quite different in each case, but the framework activities remain the same.
For many software projects, framework activities are applied iteratively as a project progresses. That is, communication, planning, modeling, construction, and deploy- ment are applied repeatedly through a number of project iterations. Each iteration produces a software increment that provides stakeholders with a subset of overall software features and functionality. As each increment is produced, the software becomes more and more complete.
1.3.2 Umbrella Activities Software engineering process framework activities are complemented by a number of umbrella activities. In general, umbrella activities are applied throughout a software project and help a software team manage and control progress, quality, change, and risk. Typical umbrella activities include:
Software project tracking and control. Allows the software team to assess progress against the project plan and take any necessary action to maintain the schedule.
Risk management. Assesses risks that may affect the outcome of the project or the quality of the product.
Software quality assurance. Defines and conducts the activities required to ensure software quality.
Technical reviews. Assess software engineering work products in an effort to uncover and remove errors before they are propagated to the next activity.
Measurement. Defines and collects process, project, and product measures that assist the team in delivering software that meets stakeholders’ needs; can be used in conjunction with all other framework and umbrella activities.
Software configuration management. Manages the effects of change throughout the software process.
Reusability management. Defines criteria for work product reuse (including software components) and establishes mechanisms to achieve reusable components.
Work product preparation and production. Encompasses the activities required to create work products such as models, documents, logs, forms, and lists.
Each of these umbrella activities is discussed in detail later in this book.
1.3.3 Process Adaptation Previously in this section, we noted that the software engineering process is not a rigid prescription that must be followed dogmatically by a software team. Rather, it should be agile and adaptable (to the problem, to the project, to the team, and to the organizational
12 CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING
culture). Therefore, a process adopted for one project might be significantly different than a process adopted for another project. Among the differences are:
∙ Overall flow of activities, actions, and tasks and the interdependencies among them
∙ Degree to which actions and tasks are defined within each framework activity ∙ Degree to which work products are identified and required ∙ Manner in which quality assurance activities are applied ∙ Manner in which project tracking and control activities are applied ∙ Overall degree of detail and rigor with which the process is described ∙ Degree to which the customer and other stakeholders are involved with the
project ∙ Level of autonomy given to the software team ∙ Degree to which team organization and roles are prescribed
In Part One of this book, we examine software process in considerable detail.
1 .4 so f t wa r e eng i n e e r i ng pr ac t i c e
In Section 1.3, we introduced a generic software process model composed of a set of activities that establish a framework for software engineering practice. Generic frame- work activities—communication, planning, modeling, construction, and deployment—and umbrella activities establish a skeleton architecture for software engineering work. But how does the practice of software engineering fit in? In the sections that follow, you’ll gain a basic understanding of the generic concepts and principles that apply to framework activities.9
1.4.1 The Essence of Practice In the classic book How to Solve It, written before modern computers existed, George Polya [Pol45] outlined the essence of problem solving, and consequently, the essence of software engineering practice:
1. Understand the problem (communication and analysis). 2. Plan a solution (modeling and software design). 3. Carry out the plan (code generation). 4. Examine the result for accuracy (testing and quality assurance).
In the context of software engineering, these commonsense steps lead to a series of essential questions [adapted from Pol45]:
Understand the Problem. It’s sometimes difficult to admit, but most of us suffer from hubris when we’re presented with a problem. We listen for a few seconds and
9 You should revisit relevant sections within this chapter as we discuss specific software engineering methods and umbrella activities later in this book.
CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING 13
then think, Oh yeah, I understand, let’s get on with solving this thing. Unfortunately, understanding isn’t always that easy. It’s worth spending a little time answering a few simple questions:
∙ Who has a stake in the solution to the problem? That is, who are the stake- holders?
∙ What are the unknowns? What data, functions, and features are required to properly solve the problem?
∙ Can the problem be compartmentalized? Is it possible to represent smaller problems that may be easier to understand?
∙ Can the problem be represented graphically? Can an analysis model be created?
Plan the Solution. Now you understand the problem (or so you think), and you can’t wait to begin coding. Before you do, slow down just a bit and do a little design:
∙ Have you seen similar problems before? Are there patterns that are recogniz- able in a potential solution? Is there existing software that implements the data, functions, and features that are required?
∙ Has a similar problem been solved? If so, are elements of the solution reusable? ∙ Can subproblems be defined? If so, are solutions readily apparent for the
subproblems? ∙ Can you represent a solution in a manner that leads to effective implementation?
Can a design model be created?
Carry Out the Plan. The design you’ve created serves as a road map for the system you want to build. There may be unexpected detours, and it’s possible that you’ll discover an even better route as you go, but the “plan” will allow you to proceed without getting lost.
∙ Does the solution conform to the plan? Is source code traceable to the design model?
∙ Is each component part of the solution provably correct? Has the design and code been reviewed, or better, have correctness proofs been applied to the algorithm?
Examine the Result. You can’t be sure that your solution is perfect, but you can be sure that you’ve designed a sufficient number of tests to uncover as many errors as possible.
∙ Is it possible to test each component part of the solution? Has a reasonable testing strategy been implemented?
∙ Does the solution produce results that conform to the data, functions, and features that are required? Has the software been validated against all stake- holder requirements?
It shouldn’t surprise you that much of this approach is common sense. In fact, it’s reasonable to state that a commonsense approach to software engineering will never lead you astray.
14 CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING
1.4.2 General Principles The dictionary defines the word principle as “an important underlying law or assump- tion required in a system of thought.” Throughout this book we’ll discuss principles at many different levels of abstraction. Some focus on software engineering as a whole, others consider a specific generic framework activity (e.g., communication), and still others focus on software engineering actions (e.g., architectural design) or technical tasks (e.g., creating a usage scenario). Regardless of their level of focus, principles help you establish a mind-set for solid software engineering practice. They are important for that reason.
David Hooker [Hoo96] has proposed seven principles that focus on software engi- neering practice as a whole. They are reproduced in the following paragraphs:10
The First Principle: The Reason It All Exists
A software system exists for one reason: to provide value to its users. All deci- sions should be made with this in mind. Before specifying a system requirement, before noting a piece of system functionality, before determining the hardware plat- forms or development processes, ask yourself questions such as: “Does this add real value to the system?” If the answer is no, don’t do it. All other principles support this one.
The Second Principle: KISS (Keep It Simple, Stupid!)
There are many factors to consider in any design effort. All design should be as simple as possible, but no simpler. This facilitates having a more easily understood and easily maintained system. This is not to say that features should be discarded in the name of simplicity. Indeed, the more elegant designs are usually the simpler ones. Simple does not mean “quick and dirty.” It often takes a lot of thought and work over multiple iterations to simplify the design. The payoff is software that is more maintainable and less error-prone.
The Third Principle: Maintain the Vision
A clear vision is essential to the success of a software project. Without concep- tual integrity, a system threatens to become a patchwork of incompatible designs, held together by the wrong kind of screws . . . Compromising the architectural vision of a software system weakens and will eventually break even the well- designed systems. Having an empowered architect who can hold the vision and enforce compliance helps ensure a very successful software project.
The Fourth Principle: What You Produce, Others Will Consume
Always specify, design, document, and implement knowing someone else will have to understand what you are doing. The audience for any product of software development is potentially large. Specify with an eye to the users. Design, keeping the implementers in mind. Code with concern for those that must maintain and extend the system. Someone may have to debug the code you write, and that makes them a user of your code. Making their job easier adds value to the system.
10 Reproduced with permission of the author [Hoo96]. Hooker defines patterns for these prin- ciples at http://c2.com/cgi/wiki?SevenPrinciplesOfSoftwareDevelopment.
CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING 15
The Fifth Principle: Be Open to the Future
In today’s computing environments, where specifications change on a moment’s notice and hardware platforms are obsolete just a few months old, software lifetimes are typically measured in months instead of years. However, true “industrial- strength” software systems must endure far longer. To do this, systems must be ready to adapt to these and other changes. Systems that do this successfully have been designed this way from the start. Never design yourself into a corner. Always ask “what if,” and prepare for all possible answers by creating systems that solve the general problem, not just the specific one.11
The Sixth Principle: Plan Ahead for Reuse
Reuse saves time and effort.12 Achieving a high level of reuse is arguably the hardest goal to accomplish in developing a software system. The reuse of code and designs has been proclaimed as a major benefit of using object-oriented technolo- gies. However, the return on this investment is not automatic. Planning ahead for reuse reduces the cost and increases the value of both the reusable components and the systems into which they are incorporated.
The Seventh Principle: Think!
This last principle is probably the most overlooked. Placing clear, complete thought before action almost always produces better results. When you think about something, you are more likely to do it right. You also gain knowledge about how to do it right again. If you do think about something and still do it wrong, it becomes a valuable experience. A side effect of thinking is learning to recognize when you don’t know something, at which point you can research the answer. When clear thought has gone into a system, value comes out. Applying the first six principles requires intense thought, for which the potential rewards are enormous.
If every software engineer and every software team simply followed Hooker’s seven principles, many of the difficulties we experience in building complex computer-based systems would be eliminated.
1 .5 how it aL L sta rt s
Every software project is precipitated by some business need—the need to correct a defect in an existing application; the need to adapt a “legacy system” to a changing business environment; the need to extend the functions and features of an existing application; or the need to create a new product, service, or system.
11 This advice can be dangerous if it is taken to extremes. Designing for the “general problem” sometimes requires performance compromises and can make specific solutions inefficient.
12 Although this is true for those who reuse the software on future projects, reuse can be expensive for those who must design and build reusable components. Studies indicate that designing and building reusable components can cost between 25 to 200 percent more than building targeted software. In some cases, the cost differential cannot be justified.
16 CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING
At the beginning of a software project, the business need is often expressed informally as part of a simple conversation. The conversation presented in the sidebar is typical.
How a Project Starts
The scene: Meeting room at CPI Corporation, a (fictional)
company that makes consumer products for home and commercial use.
The players: Mal Golden, senior manager, product development; Lisa Perez, marketing manager; Lee Warren, engineering manager; Joe Camalleri, executive vice president, business development
The conversation: Joe: Okay, Lee, what’s this I hear about your folks developing a what? A generic universal wireless box?
Lee: It’s pretty cool . . . about the size of a small matchbook . . . we can attach it to sen- sors of all kinds, a digital camera, just about anything. Using the 802.11n wireless protocol. It allows us to access the device’s output without wires. We think it’ll lead to a whole new generation of products.
Joe: You agree, Mal?
Mal: I do. In fact, with sales as flat as they’ve been this year, we need something new. Lisa and I have been doing a little market research, and we think we’ve got a line of products that could be big.
Joe: How big . . . bottom line big?
Mal (avoiding a direct commitment): Tell him about our idea, Lisa.
Lisa: It’s a whole new generation of what we call “home management products.” We call ‘em SafeHome. They use the new wireless interface, provide homeowners or small- businesspeople with a system that’s controlled by their PC—home security, home surveillance, appliance and device control—you know, turn down the home air conditioner while you’re driving home, that sort of thing.
Lee (jumping in): Engineering’s done a techni- cal feasibility study of this idea, Joe. It’s doable at low manufacturing cost. Most hardware is off the shelf. Software is an issue, but it’s nothing that we can’t do.
Joe: Interesting. Now, I asked about the bottom line.
Mal: PCs and tablets have penetrated over 70 percent of all households in the USA. If we could price this thing right, it could be a killer app. Nobody else has our wireless box . . . it’s proprietary. We’ll have a 2-year jump on the competition. Revenue? Maybe as much as $30 to $40 million in the second year.
Joe (smiling): Let’s take this to the next level. I’m interested.
safehome13
13 SafeHome will be used throughout this book to illustrate the inner workings of project teams as they build a software product. The company, the project, and the people are purely ficti- tious, but the situations and problems are real.
With the exception of a passing reference, software was hardly mentioned as part of the conversation. And yet, software will make or break the SafeHome product line. The engineering effort will succeed only if SafeHome software succeeds. The market will accept the product only if the software embedded within it properly meets the customer’s (as yet unstated) needs. We’ll follow the progression of SafeHome software engineering in many of the chapters that follow.
CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING 17
1 .6 Su m m a ry
Software is the key element in the evolution of computer-based systems and products and one of the most important technologies on the world stage. Over the past 60 years, software has evolved from a specialized problem-solving and information analysis tool to an industry in itself. Yet we still have trouble developing high-quality software on time and within budget.
Software—programs, data, and descriptive information—addresses a wide array of technology and application areas. Legacy software continues to present special chal- lenges to those who must maintain it.
Software engineering encompasses process, methods, and tools that enable com- plex computer-based systems to be built in a timely manner with quality. The software process incorporates five framework activities—communication, planning, modeling, construction, and deployment—that are applicable to all software projects. Software engineering practice is a problem-solving activity that follows a set of core principles. As you learn more about software engineering, you’ll begin to understand why these principles should be considered when beginning any software project.
Pro b l e m S a n d Po i n t S to Po n d e r
1.1. Provide at least five additional examples of how the law of unintended consequences applies to computer software.
1.2. Provide a number of examples (both positive and negative) that indicate the impact of software on our society.
1.3. Develop your own answers to the five questions asked at the beginning of Section 1.1. Discuss them with your fellow students.
1.4. Many modern applications change frequently—before they are presented to the end user and then after the first version has been put into use. Suggest a few ways to build software to stop deterioration due to change.
1.5. Consider the seven software categories presented in Section 1.1.2. Do you think that the same approach to software engineering can be applied for each? Explain your answer.
1.6. As software becomes more pervasive, risks to the public (due to faulty programs) become an increasingly significant concern. Develop a doomsday but realistic scenario in which the failure of a computer program could do great harm, either economic or human.
1.7. Describe a process framework in your own words. When we say that framework activities are applicable to all projects, does this mean that the same work tasks are applied for all proj- ects, regardless of size and complexity? Explain.
1.8. Umbrella activities occur throughout the software process. Do you think they are applied evenly across the process, or are some concentrated in one or more framework activities?
Design element: Quick Look icon magnifying glass: © Roger Pressman
19
In this part of Software Engineering: A Practitioner’s Approach, you’ll learn about the process that provides a framework for software engineering practice. These questions are addressed in the chapters that follow:
∙ What is a software process? ∙ What are the generic framework activities that are present in every
software process? ∙ How are processes modeled, and what are process patterns? ∙ What are the prescriptive process models, and what are their strengths
and weaknesses? ∙ Why is agility a watchword in modern software engineering work? ∙ What is agile software development, and how does it differ from more
traditional process models?
Once these questions are answered, you’ll be better prepared to understand the context in which software engineering practice is applied.
The Software Process
One P A R T
20
What is it? When you work to build a product or system, it’s important to follow a series of pre- dictable steps (a road map) that helps you de- liver a high-quality product on time. This road map is called a “software process.”
Who does it? Software engineers adapt a pro- cess to their needs and then follow it. The people who have requested the software also have a role to play in the process of defining, building, and testing it.
Why is it important? A process provides stabil- ity, control, and organization to an activity so that it does not become chaotic. However, a modern software engineering process must be “agile.” It must include only those activities, controls, and work products that are appropriate
for the project team and the product that is to be produced.
What are the steps? The process that you adopt depends on the software that you’re building. A process might be appropriate for creating software for an aircraft avionics sys- tem but may not work well for the creation of a mobile app or video game.
What is the work product? The work prod- ucts are the programs, documents, and data produced by the engineering activities and tasks included in the process.
How do I ensure that I’ve done it right? The quality, timeliness, and long-term viability of the product built are the best indicators of the success of the process used.
Q u i c k L o o k
evolutionary process model . . . . . . . . . . . . . . .29 generic process model . . . . . . . . . . . . . . . . . . . 21 process assessment . . . . . . . . . . . . . . . . . . . . .24 process flow . . . . . . . . . . . . . . . . . . . . . . . . . . .24 process improvement . . . . . . . . . . . . . . . . . . . .24 process patterns . . . . . . . . . . . . . . . . . . . . . . . .24
prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 spiral model . . . . . . . . . . . . . . . . . . . . . . . . . . . .29 task set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Unified Process . . . . . . . . . . . . . . . . . . . . . . . . . 31 waterfall model . . . . . . . . . . . . . . . . . . . . . . . . .25
k e y c o n c e p t s
Process Models
Building computer software is an iterative social learning process, and the out- come, something that Baetjer [Bae98] would call “software capital,” is an embodiment of knowledge collected, distilled, and organized as the process is conducted.
But what exactly is a software process from a technical point of view? Within the context of this book, we define a software process as a framework for the activities, actions, and tasks required to build high-quality software. Is “process” synonymous with “software engineering”? The answer is yes and no. A software process defines the approach that is taken as software is engineered. But software engineering also encompasses technologies that populate the process—technical methods and automated tools.
More important, software engineering is performed by creative, knowledge- able people who should adapt a mature software process so that it is appropriate for the products that they build and the demands of their marketplace.
2 C H A P T E R
CHAPTER 2 PROCESS MODELS 21
2 .1 A Ge n e r i c pro c e s s Mo d e L
In Chapter 1, a process was defined as a collection of activities, actions, and tasks that are performed when some work product is to be created. Each of these activities, actions, and tasks resides within a framework or model that defines their relationship with the process and with one another.
The software process is represented schematically in Figure 2.1. Referring to the figure, each framework activity is populated by a set of software engineering actions. Each software engineering action is defined by a task set that identifies the work tasks that are to be completed, the work products that will be produced, the quality assur- ance points that will be required, and the milestones that will be used to indicate progress.
As we discussed in Chapter 1, a generic process framework for software engineering defines five framework activities—communication, planning, modeling, construction, and deployment. In addition, a set of umbrella activities—project tracking and control,
…
… …
work tasks work products quality assurance points project milestones
Software process Process framework
Umbrella activities Framework activity #1
software engineering action #1.1
Task sets
Software engineering action #1.k
Task sets work tasks work products quality assurance points project milestones
work tasks work products quality assurance points project milestones
Framework activity #n
software engineering action #n.1
Task sets
Software engineering action #n.m
Task sets work tasks work products quality assurance points project milestones
Figure 2.1 A software process framework
22 PART ONE THE SOFTWARE PROCESS
risk management, quality assurance, configuration management, technical reviews, and others—are applied throughout the process.
You should note that one important aspect of the software process has not been discussed yet. This aspect—called process flow—describes how the framework activ- ities and the actions and tasks that occur within each framework activity are organized with respect to sequence and time. It is illustrated in Figure 2.2.
ModelingPlanningCommunication Construction Deployment
Modeling
Planning
Communication
Communication
Construction
Deployment
Planning
Construction Deployment
ModelingPlanningCommunication Construction Deployment
Modeling
Construction Deployment
Modeling
(a) Linear process flow
(b) Iterative process flow
(c) Evolutionary process flow
(d) Parallel process flow
Increment released
Time
Figure 2.2 Process flow
CHAPTER 2 PROCESS MODELS 23
A linear process flow executes each of the five framework activities in sequence, beginning with communication and culminating with deployment (Figure 2.2a). An iterative process flow repeats one or more of the activities before proceeding to the next (Figure 2.2b). An evolutionary process flow executes the activities in a “cir- cular” manner. Each circuit through the five activities leads to a more complete version of the software (Figure 2.2c). A parallel process flow (Figure 2.2d) executes one or more activities in parallel with other activities (e.g., modeling for one aspect of the software might be executed in parallel with construction of another aspect of the software).
2 .2 de f i n i nG A fr A M e wo r k Ac t i v i t y
Although we have described five framework activities and provided a basic definition of each in Chapter 1, a software team would need significantly more information before it could properly execute any one of these activities as part of the software process. Therefore, you are faced with a key question: What actions are appropriate for a framework activity, given the nature of the problem to be solved, the character- istics of the people doing the work, and the stakeholders who are sponsoring the project?
For a small software project requested by one person (at a remote location) with simple, straightforward requirements, the communication activity might encompass little more than a phone call or e-mail with the appropriate stakeholder. Therefore, the only necessary action is phone conversation, and the work tasks (the task set) that this action encompasses are:
1. Make contact with stakeholder via telephone. 2. Discuss requirements and develop notes. 3. Organize notes into a brief written statement of requirements. 4. E-mail to stakeholder for review and approval.
If the project was considerably more complex with lots of stakeholders, each with a different set of (sometimes conflicting) requirements, the communication activity might have six distinct actions: inception, elicitation, elaboration, negotiation, speci- fication, and validation. Each of these software engineering actions might have many work tasks and in some cases a number of distinct work products.
2 .3 id e n t i f y i nG A tA s k se t
Referring again to Figure 2.1, each software engineering action (e.g., elicitation, an action associated with the communication activity) can be represented by a number of different task sets—each a collection of software engineering work tasks, related work products, quality assurance points, and project milestones. Different projects demand different task sets. You should choose a task set that best accommodates the
24 PART ONE THE SOFTWARE PROCESS
needs of the project and the characteristics of your team. This implies that a software engineering action should be adapted to the specific needs of the software project and the characteristics of the project team.
2 .4 pro c e s s As s e s s M e n t A n d iM p rov e M e n t
The existence of a software process is no guarantee that software will be delivered on time, that it will meet the customer’s needs, or that it will exhibit the technical charac- teristics that will lead to long-term quality characteristics (Chapter 15). Process patterns must be coupled with solid software engineering practice (Part Two of this book). In addition, the process itself can be assessed to ensure that it meets a set of basic process criteria that have been shown to be essential for successful software engineering.1
The current thinking among most engineers is that software processes and activities should be assessed using numeric measures or software analytics (metrics). The
A task set defines the actual work that needs to be done to accomplish the objectives of a software engineering
action. For example, elicitation (more commonly called “requirements gathering”) is an important software engineering action that occurs during the communication activity. The goal of requirements gathering is to understand what various stakehold- ers want from the software that is to be built.
For a small, relatively simple project, the task set for requirements gathering might look like this:
1. Make a list of stakeholders for the project. 2. Invite all stakeholders to an informal meeting. 3. Ask each stakeholder to make a list of
features and functions required. 4. Discuss requirements and build a final list. 5. Prioritize requirements. 6. Note areas of uncertainty.
For a larger, more complex software project, a dif- ferent task set would be required. It might encompass the following work tasks:
1. Make a list of stakeholders for the project. 2. Interview each stakeholder separately to
determine overall wants and needs.
3. Build a preliminary list of functions and features based on stakeholder input.
4. Schedule a series of facilitated application specification meetings.
5. Conduct meetings. 6. Produce informal user scenarios as part of
each meeting. 7. Refine user scenarios based on stakeholder
feedback. 8. Build a revised list of stakeholder
requirements. 9. Use quality function deployment techniques
to prioritize requirements. 10. Package requirements so that they can be
delivered incrementally. 11. Note constraints and restrictions that will be
placed on the system. 12. Discuss methods for validating the system.
Both of these task sets achieve “requirements gathering,” but they are quite different in their depth and level of formality. The software team chooses the task set that allows it to achieve the goal for each action and still maintain quality and agility.
tAsk set
1 The SEI’s CMMI-DEV [CMM07] describes the characteristics of a software process and the criteria for a successful process in voluminous detail.
CHAPTER 2 PROCESS MODELS 25
progress you have made in a journey toward an effective software process will define the degree to which you can measure improvement in a meaningful way. The use of software process metrics to assess process quality is introduced in Chapter 17. A more detailed discussion of process assessment and improvement methods is presented in Chapter 28.
2 .5 pr e s c r i p t i v e pro c e s s Mo d e L s
Prescriptive process models define a predefined set of process elements and a predict- able process work flow. Prescriptive process models2 strive for structure and order in software development. Activities and tasks occur sequentially with defined guidelines for progress. But are prescriptive models appropriate for a software world that thrives on change? If we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work?
There are no easy answers to these questions, but there are alternatives available to software engineers. In the sections that follow, we provide an overview of the prescriptive process approach in which order and project consistency are dominant issues. We call them “prescriptive” because they prescribe a set of process elements— framework activities, software engineering actions, tasks, work products, quality assurance, and change control mechanisms for each project. Each process model also prescribes a process flow (also called a work flow)—that is, the manner in which the process elements are interrelated to one another.
All software process models can accommodate the generic framework activities described in Chapter 1, but each applies a different emphasis to these activities and defines a process flow that invokes each framework activity (as well as software engineering actions and tasks) in a different manner. In Chapters 3 and 4 we will discuss software engineering practices that strive to accommodate the changes that are inevitable during the development of many software projects.
2.5.1 The Waterfall Model There are times when the requirements for a problem are well understood—when work flows from communication through deployment in a reasonably linear fashion. This situation is sometimes encountered when well-defined adaptations or enhancements to an existing system must be made (e.g., an adaptation to accounting software because it needs to accommodate changes to mandated government regulations). It may also occur in a limited number of new development efforts, but only when requirements are well defined and reasonably stable.
The waterfall model, sometimes called the linear sequential model, suggests a systematic, sequential approach3 to software development that begins with customer
2 Prescriptive process models are sometimes referred to as “traditional” process models. 3 Although the original waterfall model proposed by Winston Royce [Roy70] made provision
for “feedback loops,” the vast majority of organizations that apply this process model treat it as if it were strictly linear.
26 PART ONE THE SOFTWARE PROCESS
specification of requirements and progresses through planning, modeling, construc- tion, and deployment, culminating in ongoing support of the completed software (Figure 2.3).
The waterfall model is the oldest paradigm for software engineering. However, over the past five decades, criticism of this process model has caused even ardent support- ers to question its efficacy. Among the problems that are sometimes encountered when the waterfall model is applied are:
1. Real projects rarely follow the sequential work flow that the model proposes. 2. It is often difficult for the customer to state all requirements explicitly at the
beginning of most projects. 3. The customer must have patience because a working version of the
program(s) will not be available until late in the project time span. 4. Major blunders may not be detected until the working program is reviewed.
Today, software work is fast paced and subject to a never-ending stream of changes (to features, functions, and information content). The waterfall model is often inap- propriate for such work.
2.5.2 Prototyping Process Model Often, a customer defines a set of general objectives for software but does not identify detailed requirements for functions and features. In other cases, the developer may be unsure of the efficiency of an algorithm, the adaptability of an operating system, or the form that human-machine interaction should take. In these, and many other situations, a prototyping paradigm may offer the best approach.
Although prototyping can be used as a stand-alone process model, it is more com- monly used as a technique that can be implemented within the context of any one of the process models noted in this chapter. Regardless of the manner in which it is applied, the prototyping paradigm assists you and other stakeholders to better under- stand what is to be built when requirements are fuzzy.
For example, a fitness app developed using incremental prototypes might deliver the basic user interface screens needed to sync a mobile phone with the fitness device
Construction
Deployment
Communication
Planning
Modeling
project initiation requirements gathering estimating
scheduling tracking
delivery support
feedback
analysis design
code test
Figure 2.3 The waterfall model
CHAPTER 2 PROCESS MODELS 27
and display the current data; the ability to set goals and store the fitness device data on the cloud might be included in the second prototype, creating and modifying the user interface screens based on customers feedback; and a third prototype might include social media integration to allow users to set fitness goals and share progress toward them with a set of friends.
The prototyping paradigm (Figure 2.4) begins with communication. You meet with other stakeholders to define the overall objectives for the software, identify whatever requirements are known, and outline areas where further definition is mandatory. A prototyping iteration is planned quickly, and modeling (in the form of a “quick design”) occurs. A quick design focuses on a representation of those aspects of the software that will be visible to end users (e.g., human interface layout or output dis- play formats). The quick design leads to the construction of a prototype. The prototype is deployed and evaluated by stakeholders, who provide feedback that is used to further refine requirements. Iteration occurs as the prototype is tuned to satisfy the needs of various stakeholders, while at the same time enabling you to better under- stand what needs to be done.
Ideally, the prototype serves as a mechanism for identifying software requirements. If a working prototype is to be built, you can make use of existing program fragments or apply tools that enable working programs to be generated quickly.
Figure 2.4
Quick planQuQu
ngdelinModde k designickQuiui
struction ofConstrnstru prototype
Deployymentoyy t Delivevery &veve & feedbabackba
Commmmmunication
The prototyping paradigm
28 PART ONE THE SOFTWARE PROCESS
Both stakeholders and software engineers like the prototyping paradigm. Users get a feel for the actual system, and developers get to build something immediately. Yet, prototyping can be problematic for the following reasons:
1. Stakeholders see what appears to be a working version of the software. They may be unaware that the prototype architecture (program structure) is also evolving. This means that the developers may not have considered the overall software quality or long-term maintainability.
2. As a software engineer, you may be tempted to make implementation com- promises to get a prototype working quickly. If you are not careful, these less- than-ideal choices have now become an integral part of the evolving system.
Selecting a Process Model, Part 1
The scene: Meeting room for the software engineering group
at CPI Corporation, a (fictional) company that makes consumer products for home and commercial use.
The players: Lee Warren, engineering man- ager; Doug Miller, software engineering man- ager; Jamie Lazar, software team member; Vinod Raman, software team member; and Ed Robbins, software team member.
The conversation: Lee: So let’s recapitulate. I’ve spent some time discussing the SafeHome product line as we see it at the moment. No doubt, we’ve got a lot of work to do to simply define the thing, but I’d like you guys to begin thinking about how you’re going to approach the software part of this project.
Doug: Seems like we’ve been pretty disorga- nized in our approach to software in the past.
Ed: I don’t know, Doug, we always got product out the door.
Doug: True, but not without a lot of grief, and this project looks like it’s bigger and more complex than anything we’ve done in the past.
Jamie: Doesn’t look that hard, but I agree . . . our ad hoc approach to past projects won’t work here, particularly if we have a very tight time line.
Doug (smiling): I want to be a bit more profes- sional in our approach. I went to a short course last week and learned a lot about software engineering . . . good stuff. We need a process here.
Jamie (with a frown): My job is to build com- puter programs, not push paper around.
Doug: Give it a chance before you go nega- tive on me. Here’s what I mean. (Doug pro- ceeds to describe the process framework described in Chapter 1 and the prescriptive process models presented to this point.)
Doug: So anyway, it seems to me that a linear model is not for us . . . assumes we have all re- quirements up front and, knowing this place, that’s not likely.
Vinod: Yeah, and it sounds way too IT-oriented . . . probably good for building an inventory control system or something, but it’s just not right for SafeHome.
Doug: I agree.
Ed: That prototyping approach seems okay. A lot like what we do here anyway.
Vinod: That’s a problem. I’m worried that it doesn’t provide us with enough structure.
Doug: Not to worry. We’ve got plenty of other options, and I want you guys to pick what’s best for the team and best for the project.
sAfeHoMe
CHAPTER 2 PROCESS MODELS 29
Although problems can occur, prototyping can be an effective paradigm for soft- ware engineering. The key is to define the rules of the game at the beginning; that is, all stakeholders should agree that the prototype is built in part to serve as a mechanism for defining requirements. It is often desirable to design a prototype so it can be evolved into the final product. The reality is developers may need to discard (at least in part) a prototype to better meet the customer’s evolving needs.
2.5.3 Evolutionary Process Model Software, like all complex systems, evolves over time. Business and product require- ments often change as development proceeds, making a straight-line path to an end product unrealistic. Tight market deadlines may make completion of a comprehensive software product impossible. It might be possible to create a limited version of a product to meet competitive or business pressure and release a refined version once all system features are better understood. In a situation like this you need a process model that has been explicitly designed to accommodate a product that grows and changes.
Originally proposed by Barry Boehm [Boe88], the spiral model is an evolutionary software process model that couples the iterative nature of prototyping with the con- trolled and systematic aspects of the waterfall model. It provides the potential for rapid development of increasingly more complete versions of the software.
Using the spiral model, software is developed in a series of evolutionary releases. During early iterations, the release might be a model or prototype. During later itera- tions, increasingly more complete versions of the engineered system are produced.
A spiral model is divided into a set of framework activities defined by the soft- ware engineering team. For illustrative purposes, we use the generic framework activities discussed earlier.4 Each of the framework activities represent one segment of the spiral path illustrated in Figure 2.5. As this evolutionary process begins, the software team performs activities that are implied by a circuit around the spiral in a clockwise direction, beginning at the center. Risk (Chapter 26) is considered as each revolution is made. Anchor point milestones—a combination of work products and conditions that are attained along the path of the spiral—are noted for each evolutionary pass.
The first circuit around the spiral (beginning at the inside streamline nearest the center, as shown in Figure 2.5) might result in the development of a product specifi- cation; subsequent passes around the spiral might be used to develop a prototype and then progressively more sophisticated versions of the software. Each pass through the planning region results in adjustments to the project plan. Cost and schedule are adjusted based on feedback derived from the customer after delivery. In addition, the project manager adjusts the planned number of iterations required to complete the software.
Unlike other process models that end when software is delivered, the spiral model can be adapted to apply throughout the life of the computer software. The spiral model
4 The spiral model discussed in this section is a variation on the model proposed by Boehm. For further information on the original spiral model, see [Boe88]. More recent discussion of Boehm’s spiral model can be found in [Boe98] and [Boe01a].
30 PART ONE THE SOFTWARE PROCESS
is a realistic approach to the development of large-scale systems and software. It uses prototyping as a risk reduction mechanism. The spiral model demands a direct con- sideration of technical risks at all stages of the project and, if properly applied, should reduce risks before they become problematic.
But like other paradigms, the spiral model is not a panacea. It may be difficult to convince customers (particularly in contract situations) that the evolutionary approach is controllable. It demands considerable risk assessment expertise and relies on this expertise for success. If a major risk is not uncovered and managed, problems will undoubtedly occur.
We have already noted that modern computer software is characterized by con- tinual change, by very tight time lines, and by an emphatic need for customer-user satisfaction. In many cases, time to market is the most important management requirement. If a market window is missed, the software project itself may be meaningless.5
The intent of evolutionary models is to develop high-quality software6 in an itera- tive or incremental manner. However, it is possible to use an evolutionary process to
Modeling analysis design
Planning estimation scheduling risk analysis
start Construction code test
Deployment delivery feedback
Communication
Figure 2.5
A typical spiral model
5 It is important to note, however, that being the first to reach a market is no guarantee of success. In fact, many very successful software products have been second or even third to reach the market (learning from the mistakes of their predecessors).
6 In this context, software quality is defined quite broadly to encompass not only customer satisfaction, but also a variety of technical criteria discussed in Part Two of this book.
CHAPTER 2 PROCESS MODELS 31
emphasize flexibility, extensibility, and speed of development. The challenge for software teams and their managers is to establish a proper balance between these critical project and product parameters and customer satisfaction (the ultimate arbiter of software quality).
2.5.4 Unified Process Model In some ways the Unified Process (UP) [Jac99] is an attempt to draw on the best features and characteristics of traditional software process models but characterize them in a way that implements many of the best principles of agile software devel- opment (Chapter 3). The Unified Process recognizes the importance of customer communication and streamlined methods for describing the customer’s view of a system (the use case).7 It emphasizes the important role of software architecture and “helps the architect focus on the right goals, such as understandability, reliance to future changes, and reuse” [Jac99]. It suggests a process flow that is iterative and incremental, providing the evolutionary feel that is essential in modern software development.
Selecting a Process Model, Part 2
The scene: Meeting room for the software engineering group
at CPI Corporation, a company that makes con- sumer products for home and commercial use.
The players: Lee Warren, engineering man- ager; Doug Miller, software engineering manager; Vinod and Jamie, members of the software engineering team.
The conversation: (Doug describes evolution- ary process options.)
Jamie: Now I see something I like. An incre- mental approach makes sense, and I really like the flow of that spiral model thing. That’s keepin’ it real.
Vinod: I agree. We deliver an increment, learn from customer feedback, re-plan, and then de- liver another increment. It also fits into the na- ture of the product. We can have something on
the market fast and then add functionality with each version, er, increment.
Lee: Wait a minute. Did you say that we re- generate the plan with each tour around the spiral, Doug? That’s not so great; we need one plan, one schedule, and we’ve got to stick to it.
Doug: That’s old-school thinking, Lee. Like the guys said, we’ve got to keep it real. I submit that it’s better to tweak the plan as we learn more and as changes are requested. It’s way more realistic. What’s the point of a plan if it doesn’t reflect reality?
Lee (frowning): I suppose so, but . . . senior management’s not going to like this . . . they want a fixed plan.
Doug (smiling): Then you’ll have to reeducate them, buddy.
sAfeHoMe
7 A use case (Chapter 7) is a text narrative or template that describes a system function or feature from the user’s point of view. A use case is written by the user and serves as a basis for the creation of a more comprehensive analysis model.
32 PART ONE THE SOFTWARE PROCESS
UML, the unified modeling language, was developed to support their work. UML contains a robust notation for the modeling and development of object-oriented systems and has became a de facto industry standard for modeling software of all types. UML is used throughout Part Two of this book to represent both requirements and design models. Appendix 1 presents an introductory tutorial and a list of recom- mended books for those who are unfamiliar with basic UML notation and modeling rules.
Figure 2.6 depicts the “phases” of the Unified Process and relates them to the generic activities that were discussed in Section 2.1.
The inception phase of the UP is where customer communication and planning takes place. Fundamental business requirements are described through a set of pre- liminary use cases (Chapter 7) that describe which features and functions each major class of users desires that will become realized in the software architecture. Planning identifies resources, assesses major risks, and defines a preliminary schedule for the software increments.
Figure 2.6
planningplanninggg lingmode
ionctiotiotioonstrucocon
deployment
commmmummmmunicatiotiontio
software increment
Release
Inception
Elaboration
Construction
Transition
Production
The Unified Process
CHAPTER 2 PROCESS MODELS 33
The elaboration phase encompasses the planning and modeling activities of the generic process model (Figure 2.6). Elaboration refines and expands the preliminary use cases and creates an architectural baseline that includes five different views of the software—the use case model, the analysis model, the design model, the implementa- tion model, and the deployment model.8 Modifications to the plan are often made at this time.
The construction phase of the UP is identical to the construction activity defined for the generic software process. All necessary and required features and functions for the software increment (i.e., the release) are then implemented in source code. As components are being implemented, unit tests9 are designed and executed for each. In addition, integration activities (component assembly and integration testing) are con- ducted. Use cases are used to derive a suite of acceptance tests that are executed prior to the initiation of the next UP phase.
The transition phase of the UP encompasses the latter stages of the generic construction activity and the first part of the generic deployment (delivery and feedback) activity. Software and supporting documentation is given to end users for beta testing, and user feedback reports both defects and necessary changes. At the conclusion of the transition phase, the software increment becomes a usable software release.
The production phase of the UP coincides with the deployment activity of the generic process. During this phase, the ongoing use of the software is monitored, support for the operating environment (infrastructure) is provided, and defect reports and requests for changes are submitted and evaluated.
It is likely that at the same time the construction, transition, and production phases are being conducted, work may have already begun on the next software increment. This means that the five UP phases do not occur in a sequence, but rather with stag- gered concurrency.
It should be noted that not every task identified for a UP workflow is conducted for every software project. The team adapts the process (actions, tasks, subtasks, and work products) to meet its needs.
2 .6 pro d u c t A n d pro c e s s
Some of the strengths and weaknesses of the process models we have discussed are summarized in Table 2.1. In previous editions of this book we have discussed many others. The reality is that no process is perfect for every project. Usually the software team adapts one or more of the process models discussed in 2.5 or the agile process models discussed in Chapter 3 to meet their needs for the project at hand.
8 It is important to note that the architectural baseline is not a prototype in that it is not thrown away. Rather, the baseline is fleshed out during the next UP phase.
9 A comprehensive discussion of software testing (including unit tests) is presented in Chapters 19 through 21).
34 PART ONE THE SOFTWARE PROCESS
Table 2.1 Waterfall pros It is easy to understand and plan. It works for well-understood small projects. Analysis and testing are straightfoward.
Waterfall cons It does not accommodate change well. Testing occurs late in the process. Customer approval is at the end.
Prototyping pros There is a reduced impact of requirement changes. The customer is involved early and often. It works well for small projects. There is reduced likelihood of product rejection.
Prototyping cons Customer involvement may cause delays. There may be a temptation to “ship” a prototype. Work is lost in a throwaway prototype. It is hard to plan and manage.
Spiral pros There is continuous customer involvement. Development risks are managed. It is suitable for large, complex projects. It works well for extensible products.
Spiral cons Risk analysis failures can doom the project. The project may be hard to manage. It requires an expert development team.
Unified Process pros Quality documentation is emphasized. There is continuous customer involvement. It accommodates requirements changes. It works well for maintenance projects.
Unified Process cons Use cases are not always precise. It has tricky software increment integration. Overlapping phases can cause problems. It requires an expert development team.
If the process is weak, the end product will undoubtedly suffer. But an obsessive overreliance on process is also dangerous. In a brief essay written many years ago, Margaret Davis [Dav95a] makes timeless comments on the duality of product and process:
About every ten years give or take five, the software community redefines “the problem” by shifting its focus from product issues to process issues. . . .
While the natural tendency of a pendulum is to come to rest at a point midway between two extremes, the software community’s focus constantly shifts because new force is applied when the last swing fails. These swings are harmful in and of themselves because they confuse the average software practitioner by radically changing what it means to perform the job let alone perform it well. The swings also do not solve “the problem” for they are doomed to fail as long as product and process are treated as form- ing a dichotomy instead of a duality.
. . . You can never derive or understand the full artifact, its context, use, meaning, and worth if you view it as only a process or only a product.
All of human activity may be a process, but each of us derives a sense of self-worth from those activities that result in a representation or instance that can be used or
Comparing process models
CHAPTER 2 PROCESS MODELS 35
appreciated either by more than one person, used over and over, or used in some other context not considered. That is, we derive feelings of satisfaction from reuse of our products by ourselves or others.
Thus, while the rapid assimilation of reuse goals into software development poten- tially increases the satisfaction software practitioners derive from their work, it also increases the urgency for acceptance of the duality of product and process. . . .
People derive as much (or more) satisfaction from the creative process as they do from the end product. An artist enjoys the brush strokes as much as the framed result. A writer enjoys the search for the proper metaphor as much as the finished book. As a creative software professional, you should also derive as much satisfaction from the process as the end product. The duality of product and process is one important ele- ment in keeping creative people engaged as software engineering continues to evolve.
2 .7 su M M A ry
A generic process model for software engineering encompasses a set of framework and umbrella activities, actions, and work tasks. Each of a variety of process models can be described by a different process flow—a description of how the framework activities, actions, and tasks are organized sequentially and chronologically. Process patterns can be used to solve common problems that are encountered as part of the software process.
Prescriptive process models have been applied for many years in an effort to bring order and structure to software development. Each of these models suggests a some- what different process flow, but all perform the same set of generic framework activities: communication, planning, modeling, construction, and deployment.
Sequential process models, such as the waterfall model, are the oldest software engineering paradigms. They suggest a linear process flow that is often inconsistent with modern realities (e.g., continuous change, evolving systems, tight time lines) in the software world. They do, however, have applicability in situations where require- ments are well defined and stable.
Incremental process models are iterative in nature and produce working versions of software quite rapidly. Evolutionary process models recognize the iterative, incre- mental nature of most software engineering projects and are designed to accommodate change. Evolutionary models, such as prototyping and the spiral model, produce incre- mental work products (or working versions of the software) quickly. These models can be adopted to apply across all software engineering activities—from concept development to long-term system maintenance.
The Unified Process is a “use case driven, architecture-centric, iterative and incre- mental” software process designed as a framework for UML methods and tools.
pro b L e M s A n d po i n t s to po n d e r
2.1. Baetjer [Bae98] notes: “The process provides interaction between users and designers, between users and evolving tools, and between designers and evolving tools [technology].” List five questions that (1) designers should ask users, (2) users should ask designers, (3) users should ask themselves about the software product that is to be built, and (4) designers should ask themselves about the software product that is to be built and the process that will be used to build it.
36 PART ONE THE SOFTWARE PROCESS
2.2. Discuss the differences among the various process flows described in Section 2.1. Identify the types of problems that might be applicable to each of the generic flows described.
2.3. Try to develop a set of actions for the communication activity. Select one action, and define a task set for it.
2.4. A common problem during communication occurs when you encounter two stakeholders who have conflicting ideas about what the software should be. That is, they have mutually conflicting requirements. Develop a process pattern that addresses this problem and suggest an effective approach to it.
2.5. Provide three examples of software projects that would be amenable to the waterfall model. Be specific.
2.6. Provide three examples of software projects that would be amenable to the prototyping model. Be specific.
2.7. As you move outward along the spiral process flow, what can you say about the software that is being developed or maintained?
2.8. Is it possible to combine process models? If so, provide an example.
2.9. What are the advantages and disadvantages of developing software in which quality is “good enough”? That is, what happens when we emphasize development speed over product quality?
2.10. It is possible to prove that a software component and even an entire program is correct? So why doesn’t everyone do this?
2.11. Are the Unified Process and UML the same thing? Explain your answer.
Design element: Quick Look icon magnifying glass: © Roger Pressman
37
What is it? Agile software engineering com- bines a philosophy and a set of development guidelines. The philosophy encourages customer satisfaction and early incremental de- livery of software; small, highly motivated project teams; informal methods; minimal software engineering work products; and overall development simplicity. The develop- ment guidelines stress delivery over analysis and design (although these activities are not discouraged).
Who does it? Software engineers and other project stakeholders (managers, customers, end users) work together on an agile team—a team that is self-organizing and in control of its own destiny. An agile team fosters communi- cation and collaboration among all who serve on it.
Why is it important? Modern business envi- ronments that spawn computer-based sys- tems and software products are fast paced and ever changing. Agile software engineering
represents a reasonable alternative to con- ventional software engineering. It has been demonstrated to deliver successful systems quickly.
What are the steps? Agile development might best be termed “software engineering lite.” The basic framework activities—communica- tion, planning, modeling, construction, and deployment—remain. But they morph into a minimal task set that pushes the project team toward construction and delivery.
What is the work product? The most impor- tant work product is an operational “software increment” that is delivered to the customer on the appropriate commitment date. The most important documents created are the use sto- ries and their associated test cases.
How do I ensure that I’ve done it right? If the agile team agrees that the process works, and the team produces deliverable software increments that satisfy the customer, you’ve done it right.
Q u i c k L o o k
C H A P T E R
3Agility and Process
acceptance tests . . . . . . . . . . . . . . . . . . . . . . . .48 Agile Alliance . . . . . . . . . . . . . . . . . . . . . . . . . . .40 agile process . . . . . . . . . . . . . . . . . . . . . . . . . . .40 agility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38 agility principles . . . . . . . . . . . . . . . . . . . . . . . .40 cost of change . . . . . . . . . . . . . . . . . . . . . . . . . .39 DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50
Extreme Programming (XP) . . . . . . . . . . . . . . .46 Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48 pair programming . . . . . . . . . . . . . . . . . . . . . . .48 politics of agile development . . . . . . . . . . . . . . 41 project velocity . . . . . . . . . . . . . . . . . . . . . . . . . 47 refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
k e y c o n c e p t s
In 2001, a group of noted software developers, writers, and consultants [Bec01] signed the “Manifesto for Agile Software Development” in which they argued in favor of “individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract nego- tiation, and responding to change over following a plan.”
38 PART ONE THE SOFTWARE PROCESS
3 .1 Wh at is ag i L i t y? Just what is agility in the context of software engineering work? Ivar Jacobson [Jac02a] argues that the pervasiveness of change is the primary driver for agility. Software engineers must be quick on their feet if they are to accommodate the rapid changes that Jacobson describes.
But agility is more than an effective response to change. It also encompasses the philosophy espoused in the manifesto noted at the beginning of this chapter. It encour- ages team structures and attitudes that make communication (among team members, between technologists and business people, and between software engineers and their managers) more facile. It emphasizes rapid delivery of operational software and deem- phasizes the importance of intermediate work products (not always a good thing); it adopts the customer as a part of the development team and works to eliminate the “us and them” attitude that continues to pervade many software projects; it recognizes that planning in an uncertain world has its limits and that a project plan must be flexible.
Agility can be applied to any software process. However, to accomplish this, it is essential that the process be designed in a way that allows the project team to adapt tasks and to streamline them, conduct planning in a way that understands the fluidity of an
The underlying ideas that guide agile development led to the development of agile1 methods designed to overcome perceived and actual weaknesses in conventional soft- ware engineering. Agile development can provide important benefits, but it may not be applicable to all projects, all products, all people, and all situations. It is also not antithetical to solid software engineering practice and can be applied as an overriding philosophy for all software work.
In the modern economy, it is often difficult or impossible to predict how a computer- based system (e.g., a mobile application) will evolve as time passes. Market condi- tions change rapidly, end-user needs evolve, and new competitive threats emerge without warning. In many situations, you won’t be able to define requirements fully before the project begins. You must be agile enough to respond to a fluid business environment.
Fluidity implies change, and change is expensive—particularly if it is uncontrolled or poorly managed. One of the most compelling characteristics of the agile approach is its ability to reduce the costs of change through the software process.
In a thought-provoking book on agile software development, Alistair Cockburn [Coc02] argues that the prescriptive process models introduced in Chapter 2 have a major failing: they forget the frailties of the people who build computer software. Software engineers are not robots. They exhibit great variation in working styles and significant differences in skill level, creativity, orderliness, consistency, and spontane- ity. Some communicate well in written form, others do not. If process models are to work, they must provide a realistic mechanism for encouraging the discipline that is necessary, or they must be characterized in a manner that shows “tolerance” for the people who do software engineering work.
1 Agile methods are sometimes referred to as light methods or lean methods.
CHAPTER 3 AGILITY AND PROCESS 39
agile development approach, eliminate all but the most essential work products and keep them lean, and emphasize an incremental delivery strategy that gets working software to the customer as rapidly as feasible for the product type and operational environment.
3 .2 ag i L i t y a n d t h e co st o f ch a ng e
The conventional wisdom in software development (supported by decades of experience) is that the cost of change increases nonlinearly as a project progresses (Figure 3.1, solid black curve). It is relatively easy to accommodate a change when a software team is gathering requirements (early in a project). A usage scenario might have to be modified, a list of functions may be extended, or a written specification can be edited. The costs of doing this work are minimal, and the time required will not adversely affect the outcome of the project. But what if we fast-forward a number of months? The team is in the middle of validation testing (something that occurs relatively late in the project), and an important stakeholder is requesting a major functional change. The change requires a modification to the architectural design of the software, the design and con- struction of three new components, modifications to another five components, the design of new tests, and so on. Costs escalate quickly, and the time and effort required to ensure that the change is made without unintended side effects are nontrivial.
Proponents of agility (e.g., [Bec99], [Amb04]) argue that a well-designed agile process “flattens” the cost of change curve (Figure 3.1, shaded, solid curve), allowing
Cost of change using agile process
Idealized cost of change using agile process
Development schedule progress
D ev
el op
m en
t c os
t Cost of change using conventional software process
Figure 3.1 Change costs as a function of time in development
40 PART ONE THE SOFTWARE PROCESS
a software team to accommodate changes late in a software project without dramatic cost and time impact. You’ve already learned that the agile process encompasses incremental delivery. When incremental delivery is coupled with other agile practices such as continuous unit testing and pair programming (discussed briefly in Section 3.5.1 and in more detail in Chapter 20), the cost of making a change is attenuated. Although debate about the degree to which the cost curve flattens is ongoing, there is evidence [Coc01a] to suggest that a significant reduction in the cost of change can be achieved.
3 .3 Wh at is a n ag i L e pro c e s s? Any agile software process is characterized in a manner that addresses a number of key assumptions [Fow02] about the majority of software projects:
1. It is difficult to predict in advance which software requirements will persist and which will change. It is equally difficult to predict how customer priorities will change as the project proceeds.
2. For many types of software, design and construction are interleaved. That is, both activities should be performed in tandem so that design models are proven as they are created. It is difficult to predict how much design is necessary before construction is used to prove the design.
3. Analysis, design, construction, and testing are not as predictable (from a planning point of view) as we might like.
Given these three assumptions, an important question arises: How do we create a process that can manage unpredictability? The answer, as we have already noted, lies in process adaptability (to rapidly changing project and technical conditions). An agile process, therefore, must be adaptable.
But continual adaptation without forward progress accomplishes little. Therefore, an agile software process must adapt incrementally. To accomplish incremental adaptation, an agile team requires customer feedback (so that the appropriate adaptations can be made). An effective catalyst for customer feedback is an operational prototype or a portion of an operational system. Hence, an incremental development strategy should be instituted. Software increments (executable prototypes or portions of an operational system) must be delivered in short time periods so that adaptation keeps pace with change (unpredictability). This iterative approach enables the customer to evaluate the software increment regularly, provide necessary feedback to the software team, and influence the process adaptations that are made to accommodate the feedback.
3.3.1 Agility Principles The Agile Alliance [Agi17]2 defines 12 principles for those software organizations that want to achieve agility. These principles are summarized in the paragraphs that follow.
Customer satisfaction is achieved by providing value through software that is delivered to the customer as rapidly as possible. To achieve this, agile developers
2 The Agile Alliance home page contains much useful information: https://www.agilealliance.org/.
CHAPTER 3 AGILITY AND PROCESS 41
recognize that requirements will change. They deliver software increments frequently and work together with all stakeholders so that feedback on their deliveries is rapid and meaningful.
An agile team is populated by motivated individuals, who communicate face-to face and work in an environment that is conducive to high quality software development. The team follows a process that encourages technical excellence and good design, emphasizing simplicity—“the art of maximized the amount of work not done” [Agi17]. Working software that meets customer needs is their primary goal, and the pace and direction of the team’s work must be “sustainable,” enabling them to work effectively for long periods of time.
An agile team is a “self-organizing team”—one that can develop well-structured architectures that lead to solid designs and customer satisfaction. Part of the team culture is to consider its work introspectively, always with the intent of improving the manner in which it addresses its primary goal.
Not every agile process model applies characteristics described in this section with equal weight, and some models choose to ignore (or at least downplay) the importance of one or more agile principles. However, these principles define an agile spirit that is maintained in each of the process models presented in this chapter.
3.3.2 The Politics of Agile Development There is considerable debate (sometimes strident) about the benefits and applicability of agile software development as opposed to more conventional software engineering processes. Jim Highsmith [Hig02a] (facetiously) states the extremes when he charac- terizes the feeling of the pro-agility camp (“agilists”): “Traditional methodologists are a bunch of stick-in-the-muds who’d rather produce flawless documentation than a working system that meets business needs.” As a counterpoint, he states (again, face- tiously) the position of the traditional software engineering camp: “Lightweight, er, ‘agile’ methodologists are a bunch of glorified hackers who are going to be in for a heck of a surprise when they try to scale up their toys into enterprise-wide software.”
Like all software technology arguments, this methodology debate risks degenerat- ing into a religious war. If warfare breaks out, rational thought disappears and beliefs rather than facts guide decision making.
No one is against agility. The real question is: What is the best way to achieve it? Keep in mind that working software is important, but don’t forget that it must also exhibit a variety of quality attributes including reliability, usability, and maintainabil- ity. How do you build software that meets customers’ needs today and exhibits the quality characteristics that will enable it to be extended and scaled to meet customers’ needs over the long term?
There are no absolute answers to either of these questions. Even within the agile school itself, there are many proposed framework models (Sections 3.4 and 3.5), each with a subtly different approach to the agility problem. Within each model there is a set of “ideas” (agilists are loath to call them “work tasks”) that represent a significant departure from traditional software engineering. And yet, many agile concepts are simply adaptations of good software engineering concepts. The bottom line is there is much that can be gained by considering the best of both schools and virtually noth- ing to be gained by denigrating either approach.
42 PART ONE THE SOFTWARE PROCESS
3 .4 sc ru m
Scrum (the name is derived from an activity that occurs during a rugby match)3 is a very popular agile software development method that was conceived by Jeff Sutherland and his development team in the early 1990s. Further development on the Scrum methods was performed by Schwaber and Beedle [Sch01b].
Scrum principles are consistent with the agile manifesto and are used to guide development activities within a process that incorporates the following framework activities: requirements, analysis, design, evolution, and delivery. Within each framework activity, work tasks take place in a relatively short time-boxed4 period called a sprint. The work conducted within a sprint (the number of sprints required for each framework activity will vary depending on size of the product and its complexity) is adapted to the problem at hand and is defined and often modified in real time by the Scrum team. The overall flow of the Scrum process is illustrated in Figure 3.2. Much of our description of the Scrum framework appears in Fowler and Sutherland [Fow16].5
3 A group of players forms around the ball, and the teammates work together (sometimes violently!) to move the ball downfield.
4 A time-box is a project management term (see Part Four of this book) that indicates a period of time that has been allocated to accomplish some task.
5 The Scrum Guide is available at: https://www.Scrum.org/resources/what-is-Scrum.
every 24 hours
30 days
Scrum: 15-minute daily
meeting.
New functionality is demonstrated at end of sprint
Backlog items expanded by team
Sprint Backlog: Feature(s)
assigned to sprint
Product Backlog: Prioritized product features
desired by the customer
Figure 3.2 Scrum process flow
CHAPTER 3 AGILITY AND PROCESS 43
Considering Agile Software Development
The scene: Doug Miller’s office.
The players: Doug Miller, software engineering manager; Jamie Lazar, software team member; Vinod Raman, software team member.
The conversation: (A knock on the door, Jamie and Vinod enter Doug’s office.)
Jamie: Doug, you got a minute?
Doug: Sure Jamie, what’s up?
Jamie: We’ve been thinking about our pro- cess discussion yesterday . . . you know, what process we’re going to choose for this new SafeHome project.
Doug: And?
Vinod: I was talking to a friend at another company, and he was telling me about Scrum. It’s an agile process model . . . heard of it?
Doug: Yeah, some good, some bad.
Jamie: Well, it sounds pretty good to us. Lets you develop software really fast, uses some- thing called sprints to deliver software incre- ments when the team decides the product is done . . . it’s pretty cool, I think.
Doug: It does have a lot of really good ideas. I like the sprint concept, the emphasis on early test case creation, and the idea that the process owner should be part of the team.
Jamie: Huh? You mean that marketing will work on the project team with us?
Doug (nodding): They’re stakeholders but not really the product owner. That would be Marg.
Jamie: Good. She will filter the changes marketing will want to send every 5 minutes.
Vinod: Even so, my friend said that there are ways to “embrace” changes during an agile project.
Doug: So you guys think we should use Scrum?
Jamie: It’s definitely worth considering.
Doug: I agree. And even if we choose an incremental model as our approach, there’s no reason why we can’t incorporate much of what Scrum has to offer.
Vinod: Doug, before you said “some good, some bad.” What was the bad?
Doug: The thing I don’t like is the way Scrum downplays analysis and design . . . sort of says that writing code is where the action is . . .
(The team members look at one another and smile.)
Doug: So you agree with the Scrum ap- proach?
Jamie (speaking for both): It can be adapted to fit our needs. Besides, writing code is what we do, Boss!
Doug (laughing): True, but I’d like to see you spend a little less time coding and then recod- ing and a little more time analyzing what needs to be done and designing a solution that works.
Vinod: Maybe we can have it both ways, agility with a little discipline.
Doug: I think we can, Vinod. In fact, I’m sure of it.
safehome
3.4.1 Scrum Teams and Artifacts The Scrum team is a self-organizing interdisciplinary team consisting of a product owner, a Scrum master, and a small (three to six people) development team. The principle Scrum artifacts are the product backlog, the sprint backlog, and the code increment. Development proceeds by breaking the project into a series of incremental prototype development periods 2 to 4 weeks in length called sprints.
44 PART ONE THE SOFTWARE PROCESS
The product backlog is a prioritized list of product requirements or features that provide business value for the customer. Items can be added to the backlog at any time with the approval of the product owner and the consent of the development team. The product owner orders the items in the product backlog to meet the most important goals of all stakeholders. The product backlog is never complete while the product is evolving to meet stakeholder needs. The product owner is the only person who decides whether to end a sprint prematurely or extend the sprint if the increment is not accepted.
The sprint backlog is the subset of product backlog items selected by the product team to be completed as the code increment during the current active sprint. The increment is the union of all product backlog items completed in previous sprints and all backlog items to be completed in the current sprints. The development team creates a plan for delivering a software increment containing the selected features intended to meet an important goal as negotiated with the product owner in the current sprint. Most sprints are time-boxed to be completed in 3 to 4 weeks. How the development team completes the increment is left up to the team to decide. The development team also decides when the increment is done and ready to demonstrate to the product owner. No new features can be added to the sprint backlog unless the sprint is can- celled and restarted.
The Scrum master serves as facilitator to all members of the Scrum team. She runs the daily Scrum meeting and is responsible for removing obstacles identified by team members during the meeting. She coaches the development team members to help each other complete sprint tasks when they have time available. She helps the product owner find techniques for managing the product backlog items and helps ensure that backlog items are stated in clear and concise terms.
3.4.2 Sprint Planning Meeting Prior to beginning, any development team works with the product owner and all other stakeholders to develop the items in the product backlog. Techniques for gath- ering these requirements are discussed in Chapter 7. The product owner and the development team rank the items in the product backlog by the importance of the owner’s business needs and the complexity of the software engineering tasks (pro- gramming and testing) required to complete each of them. Sometimes this results in the identification of missing features needed to deliver the required functionality to the end users.
Prior to starting each sprint, the product owner states her development goal for the increment to be completed in the upcoming sprint. The Scrum master and the devel- opment team select the items to move from to the sprint backlog. The development team determines what can be delivered in the increment within the constraints of the time-box allocated for the sprint and, with the Scrum master, what work will be needed to deliver the increment. The development team decides which roles are needed and how they will need to be filled.
3.4.3 Daily Scrum Meeting The daily Scrum meeting is a 15-minute event scheduled at the start of each workday to allow team members to synchronize their activities and make plans for the next
CHAPTER 3 AGILITY AND PROCESS 45
24 hours. The Scrum master and the development team always attend the daily Scrum. Some teams allow the product owner to attend occasionally.
Three key questions are asked and answered by all team members:
∙ What did you do since the last team meeting? ∙ What obstacles are you encountering? ∙ What do you plan to accomplish by the next team meeting?
The Scrum master leads the meeting and assesses the responses from each person. The Scrum meeting helps the team to uncover potential problems as early as possible. It is the Scrum master’s task to clear obstacles presented before the next Scrum meeting if possible. These are not problem-solving meetings, those occur off-line and only involve the affected parties. Also, these daily meetings lead to “knowledge socialization” [Bee99] and thereby promote a self-organizing team structure.
Some teams use these meetings to declare sprint backlog items complete or done. When the team considers all sprint backlog items complete, the team may decide to schedule a demo and review of the completed increment with the product owner.
3.4.4 Sprint Review Meeting The sprint review occurs at the end of the sprint when the development team has judged the increment complete. The sprint review is often time-boxed as a 4-hour meeting for a 4-week sprint. The Scrum master, the development team, the product owner, and selected stakeholders attend this review. The primary activity is a demo of the software increment completed during the sprint. It is important to note that the demo may not contain all planned functionality, but rather those functions that were to be delivered within the time-box defined for the sprint.
The product owner may accept the increment as complete or not. If it is not accepted, the product owner and the stakeholders provide feedback to allow a new round of sprint planning to take place. This is the time when new features may be added or removed from the product backlog. The new features may affect the nature of the increment developed in the next sprint.
3.4.5 Sprint Retrospective Ideally, before beginning another sprint planning meeting, the Scrum master will schedule a 3-hour meeting (for a 4-week sprint) with the development team called a sprint retrospective. During this meeting the team discusses:
∙ What went well in the sprint ∙ What could be improved ∙ What the team will commit to improving in the next sprint
The Scrum master leads the meeting and encourages the team to improve its development practices to become more effective for the next sprint. The team plans ways to improve product quality by adapting its definition of “done.” At the end of this meeting, the team should have a good idea about the improvements needed in the next sprint and be ready to plan the increment at the next sprint planning meeting.
46 PART ONE THE SOFTWARE PROCESS
3 .5 ot h e r ag i L e fr a m e Wo r k s
The history of software engineering is littered with dozens of obsolete process descrip- tions and methodologies, modeling methods and notations, tools, and technology. Each flared in notoriety and was then eclipsed by something new and (purportedly) better. With the introduction of a wide array of agile process frameworks—each contending for acceptance within the software development community—the agile movement has followed the same historical path.6
As we noted in the last section, one of the most widely used of all agile frameworks is Scrum. But many other agile frameworks have been proposed and are in use across the industry. In this section, we present a brief overview of three popular agile meth- ods: Extreme Programming (XP), Kanban, and DevOps.
3.5.1 The XP Framework In this section we provide a brief overview of Extreme Programming (XP), one of the most widely used approaches to agile software development. Kent Beck [Bec04a] wrote the seminal work on XP.
Extreme Programming encompasses a set of rules and practices that occur within the context of four framework activities: planning, design, coding, and testing. Figure 3.3 illustrates the XP process and notes some of the key ideas and tasks that are associ- ated with each framework activity. The key XP activities are summarized in the para- graphs that follow.
Planning. The planning activity (also called the planning game) begins with a requirements activity called listening. Listening leads to the creation of a set of “stories” (also called user stories) that describe required output, features, and functionality for software to be built. Each user story (described in Chapter 7) is written by the cus- tomer and is placed on an index card. The customer assigns a value (i.e., a priority) to the story based on the overall business value of the feature or function.7 Members of the XP team then assess each story and assign a cost—measured in development weeks—to it. It is important to note that new stories can be written at any time.
Customers and developers work together to decide how to group stories into the next release (the next software increment) to be developed by the XP team. Once a basic commitment (agreement on stories to be included, delivery date, and other proj- ect matters) is made for a release, the XP team orders the stories that will be developed in one of three ways: (1) all stories will be implemented immediately (within a few weeks), (2) the stories with highest value will be moved up in the schedule and implemented first, or (3) the riskiest stories will be moved up in the schedule and implemented first.
6 This is not a bad thing. Before one or more models or methods are accepted as a de facto standard, all must contend for the hearts and minds of software engineers. The “winners” evolve into best practice, while the “losers” either disappear or merge with the winning models.
7 The value of a story may also be dependent on the presence of another story.
CHAPTER 3 AGILITY AND PROCESS 47
pppplaplanningplapla gg
design
ngcodincoco
testing
software increment project velocity computed
Release
user stories values acceptance test criteria
iteration plan
spike solutions prototypessimple design
CRC cards
pair programming
refactoringg
Unit test continuous integrationacceptance testing
Figure 3.3 The Extreme Programming process
After the first project release (also called a software increment) has been delivered, the XP team computes project velocity. Stated simply, project velocity is the number of customer stories implemented during the first release. Project velocity can then be used to help estimate delivery dates and schedule for subsequent releases. The XP team modifies its plans accordingly.
Design. XP design rigorously follows the KIS (keep it simple) principle. The design of extra functionality (because the developer assumes it will be required later) is discouraged.8
XP encourages the use of CRC cards (Chapter 8) as an effective mechanism for thinking about the software in an object-oriented context. CRC (class-responsibility- collaborator) cards identify and organize the object-oriented classes9 that are relevant to the current software increment. CRC cards are the only design work product pro- duced as part of the XP process.
If a difficult design problem is encountered as part of the design of a story, XP recommends the immediate creation of an operational prototype of that portion of the
8 These design guidelines should be followed in every software engineering method, although there are times when sophisticated design notation and terminology may get in the way of simplicity.
9 Object-oriented classes are discussed throughout Part Two of this book.
48 PART ONE THE SOFTWARE PROCESS
design. A central notion in XP is that design occurs both before and after coding commences. Refactoring—modifying/optimizing the code in a way that does not change the external behavior of the software [Fow00]—means that design occurs continuously as the system is constructed. In fact, the construction activity itself will provide the XP team with guidance on how to improve the design.
Coding. After user stories are developed and preliminary design work is done, the team does not move to code, but rather develops a series of unit tests that will exercise each of the stories that is to be included in the current release (software increment).10 Once the unit test11 has been created, the developer is better able to focus on what must be implemented to pass the test. Once the code is complete, it can be unit-tested immediately, thereby providing instantaneous feedback to the developers.
A key concept during the coding activity (and one of the most talked-about aspects of XP) is pair programming. XP recommends that two people work together at one computer to create code for a story. This provides a mechanism for real-time problem solving (two heads are often better than one) and real-time quality assurance (the code is reviewed as it is created).12
As pair programmers complete their work, the code they develop is integrated with the work of others. This “continuous integration” strategy helps uncover compatibility and interfacing errors early.
Testing. The unit tests that are created should be implemented using a framework that enables them to be automated (hence, they can be executed easily and repeat- edly). This encourages implementing a regression testing strategy (Chapter 20) when- ever code is modified (which is often, given the XP refactoring philosophy). XP acceptance tests, also called customer tests, are specified by the customer and focus on overall system features and functionality that are visible and reviewable by the customer. They are derived from user stories that have been implemented as part of a software release.
3.5.2 Kanban The Kanban method [And16] is a lean methodology that describes methods for improving any process or workflow. Kanban is focused on change management and service delivery. Change management defines the process through which a requested change is integrated into a software-based system. Service delivery is encouraged by focusing on understanding customer needs and expectations. The team members man- age the work and are given the freedom to organize themselves to complete it. Policies evolve as needed to improve outcomes.
10 This approach is analogous to knowing the exam questions before you begin to study. It makes studying much easier by focusing attention only on the questions that will be asked.
11 Unit testing, discussed in detail in Chapter 20, focuses on an individual software component, exercising the component’s interface, data structures, and functionality in an effort to uncover errors that are local to the component.
12 Pair programming has become so widespread throughout the software community that The Wall Street Journal [Wal12] ran a front-page story about the subject.
CHAPTER 3 AGILITY AND PROCESS 49
13 The use of process metrics is discussed in Chapter 23.
Selected
Expedite Lane
Analysis Development Testing Done
Doing DoneDoing Done
∞…
Figure 3.4 Kanban board
Kanban originated at Toyota as a set of industrial engineering practices and was adapted to software development by David Anderson [And16]. Kanban itself depends on six core practices:
1. Visualizing workflow using a Kanban board (an example is shown in Figure 3.4). The Kanban board is organized into columns representing the development stage for each element of software functionality. The cards on the board might contain single user stories or recently discovered defects on sticky notes and the team would advance them from “to do,” to “doing,” and “done” as the project progresses.
2. Limiting the amount of work in progress (WIP) at any given time. Developers are encouraged to complete their current task before starting another. This reduces lead time, improves work quality, and increases the team’s ability to deliver software functionality frequently to their stakeholders.
3. Managing workflow to reduce waste by understanding the current value flow, analyzing places where it is stalled, defining changes, and then implementing the changes.
4. Making process policies explicit (e.g., write down your reasons for selecting items to work on and the criteria used to define “done”).
5. Focusing on continuous improvement by creating feedback loops where changes are introduced based on process data and the effects of the change on the process are measured after the changes are made.13
6. Make process changes collaboratively and involve all team members and other stakeholders as needed.
50 PART ONE THE SOFTWARE PROCESS
The team meetings for Kanban are like those in the Scrum framework. If Kanban is being introduced to an existing project, not all items will start in the backlog column. Developers need to place their cards in the team process column by asking themselves: Where are they now? Where did they come from? Where are they going?
The basis of the daily Kanban standup meeting is a task called “walking the board.” Leadership of this meeting rotates daily. The team members identify any items missing from the board that are being worked on and add them to the board. The team tries to advance any items they can to “done.” The goal is to advance the high business value items first. The team looks at the flow and tries to identify any impediments to completion by looking at workload and risks.
During the weekly retrospective meeting, process measurements are examined. The team considers where process improvements may be needed and proposes changes to be implemented. Kanban can easily be combined with other agile development prac- tices to add a little more process discipline.
3.5.3 DevOps DevOps was created by Patrick DeBois [Kim16a] to combine Development and Oper- ations. DevOps attempts to apply agile and lean development principles across the entire software supply chain. Figure 3.5 presents an overview of the DevOps work- flow. The DevOps approach involves several stages that loop continuously until the desired product exists:
∙ Continuous development. Software deliverables are broken down and developed in multiple sprints with the increments delivered to the quality assurance14 members of the development team for testing
∙ Continuous testing. Automated testing tools15 are used to help team members test multiple code increments at the same time to ensure they are free of defects prior to integration.
∙ Continuous integration. The code pieces with new functionality are added to the existing code and to the run-time environment and then checked to ensure there are no errors after deployment.
∙ Continuous deployment. At this stage the integrated code is deployed (installed) to the production environment, which might include multiple sites globally that need to be prepared to receive the new functionality.
∙ Continuous monitoring. Operations staff who are members of the develop- ment team help to improve software quality by monitoring its performance in the production environment and proactively looking for possible problems before users find them.
DevOps enhances customers’ experiences by reacting quickly to changes in their needs or desires. This can increase brand loyalty and increase market share. Lean approaches like DevOps can provide organizations with increased capacity to innovate
14 The quality assurance is discussed in Chapter 17. 15 Automated testing tools are discussed in Chapter 19.
CHAPTER 3 AGILITY AND PROCESS 51
by reducing rework and allowing shifts to higher business value activities. Products do not make money until consumers have access to them, and DevOps can provide faster deployment time to production platforms [Sha17].
3 .6 Su m m a ry
In a modern economy, market conditions change rapidly, customer and end-user needs evolve, and new competitive threats emerge without warning. Practitioners must approach software engineering in a manner that allows them to remain agile—to define maneuverable, adaptive, lean processes that can accommodate the needs of modern business.
An agile philosophy for software engineering stresses four key issues: the impor- tance of self-organizing teams that have control over the work they perform, com- munication and collaboration between team members and between practitioners and their customers, a recognition that change represents an opportunity, and an emphasis on rapid delivery of software that satisfies the customer. Agile process models have been designed to address each of these issues.
Some of the strengths and weaknesses of the agile methods we discussed are sum- marized in Table 3.1. In previous editions of this book we have discussed many others. The reality is that no agile method is perfect for every project. Agile developers work on self-directed teams and are empowered to create their own process models.
Scrum emphasizes the use of a set of software process patterns that have proven effective for projects with tight time lines, changing requirements, and business criti- cality. There is no reason why a Scrum team could not adopt the use of a Kanban chart to help organize its daily planning meeting.
Plan
Code
Build
Test
Deploy
Operate
Monitor
ateratatatIntegeggegraatraaaeggggegrat
Figure 3.5 DevOps
52 PART ONE THE SOFTWARE PROCESS
Extreme programming (XP) is organized around four framework activities— planning, design, coding, and testing—XP suggests a number of innovative and powerful techniques that allow an agile team to create frequent software releases that deliver features and functionality that have been described and then prioritized by stakeholders. There is nothing preventing them from using DevOps techniques to decrease their time to deployment.
pro b L e m s a n d po i n t s to po n d e r
3.1. Read the “Manifesto of Agile Software Development” [Bec01] noted at the beginning of this chapter. Can you think of a situation in which one or more of the four “values” could get a software team into trouble?
Table 3.1
Comparing agile techniques
Scrum pros The product owner sets priorities. The team owns decision making. Documentation is lightweight. It supports frequent updating.
Scrum cons It is difficult to control the cost of changes. It may not be suitable for large teams. It requires expert team members.
XP pros It emphasizes customer involvement. It establishes rational plans and schedules. There is high developer commitment to the project. There is reduced likelihood of product rejection.
XP cons There is temptation to “ship” a prototype. It requires frequent meetings about increasing costs. It may allow for excessive changes. There is a dependence on highly skilled team members.
Kanban pros It has lower budget and time requirements. It allows for early product delivery. Process policies are written down. There is continuous process improvement.
Kanban cons Team collaboration skills determine success. Poor business analysis can doom the project. Flexibility can cause developers to lose focus. Developer reluctance to use measurement.
DevOps pros There is reduced time to code deployment. The team has developers and operations staff. The team has end-to-end project ownership. There is proactive monitoring of deployed product.
DevOps cons There is pressure to work on both old and new code. There is heavy reliance on automated tools to be effective. Deployment may affect the production environment. It requires an expert development team.
CHAPTER 3 AGILITY AND PROCESS 53
3.2. Describe agility (for software projects) in your own words.
3.3. Why does an iterative process make it easier to manage change? Is every agile process discussed in this chapter iterative? Is it possible to complete a project in just one iteration and still be agile? Explain your answers.
3.4. Try to come up with one more “agility principle” that would help a software engineering team become even more maneuverable.
3.5. Why do requirements change so much? After all, don’t people know what they want?
3.6. Most agile process models recommend face-to-face communication. Yet today, members of a software team and their customers may be geographically separated from one another. Do you think this implies that geographical separation is something to avoid? Can you think of ways to overcome this problem?
3.7. Write a user story that describes the “favorite places” or “favorites” feature available on most Web browsers.
3.8. Describe the XP concepts of refactoring and pair programming in your own words.
Design element: Quick Look icon magnifying glass: © Roger Pressman
54
What is it? Every software product needs a “road map” or “generic software process” of some kind. It doesn’t have to be complete be- fore you start, but you need to know where you’re headed before you begin. Any road map or generic process should be based on best industry practices.
Who does it? Software engineers and their product stakeholders collaborate to adapt a generic software process model to meet the needs of team and then either follow it di- rectly, or more likely, adapt as needed. Every software team should be disciplined but flexi- ble and self-empowered when needed.
Why is it important? Software development can easily become chaotic without the control and organization offered by a defined pro- cess. As we stated in Chapter 3, a modern software engineering approach must be “agile” and embrace changes that are needed to satisfy the stakeholders’ requirements. It is important not to be too focused on documents and rituals. The process should only include those activities, controls, and work products
that are appropriate for the project team and the product that is to be produced.
What are the steps? Even if a generic process must be adapted to meet the needs of the specific products being built, you need to be sure that all stakeholders have a role to play in defining, building, and testing the evolving software. There is likely to be substantial over- lap among the basic framework activities (communication, planning, modeling, con- struction, and deployment). Design a little, build a little, test a little, repeat is a better ap- proach than creating rigid project plans and documents for most software projects.
What is the work product? From the point of view of a software team, the work products are working program increments, useful docu- ments, and data that are produced by the pro- cess activities.
How do I ensure that I’ve done it right? The timeliness, levels of stakeholder satisfaction, overall quality, and long-term viability of the product increments built are the best indica- tors that your process is working.
Q u i c k L o o k
defining requirements . . . . . . . . . . . . . . . . . . . 57 estimating resources . . . . . . . . . . . . . . . . . . . .60 evaluating prototype . . . . . . . . . . . . . . . . . . . . .64 go, no-go decision . . . . . . . . . . . . . . . . . . . . . . .65 maintain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69 preliminary architectural design . . . . . . . . . . .59
prototype construction . . . . . . . . . . . . . . . . . . . 61 prototype evolution . . . . . . . . . . . . . . . . . . . . . . 67 release candidate . . . . . . . . . . . . . . . . . . . . . . .68 risk assessment . . . . . . . . . . . . . . . . . . . . . . . . .66 scope definition . . . . . . . . . . . . . . . . . . . . . . . . . 67 test and evaluate . . . . . . . . . . . . . . . . . . . . . . . .63
k e y c o n c e p t s
C H A P T E R
4 In Chapters 2 and 3, we provided brief descriptions of several software process models and software engineering frameworks. Every project is different, and every team is different. There is no single software engineering framework that is appropriate for every software product. In this chapter, we’ll share our thoughts on using an adaptable process that can be tailored to fit the needs of software developers working on many types of products.
Recommended Process Model
CHAPTER 4 RECOMMENDED PROCESS MODEL 55
A paper by Rajagoplan [Raj14] reviews the general weaknesses of prescriptive software life-cycle approaches (e.g., the waterfall model) and contains several sugges- tions that should be considered when organizing a modern software development project.
1. It is risky to use a linear process model without ample feedback. 2. It is never possible nor desirable to plan big up-front requirements gathering. 3. Up-front requirements gathering may not reduce costs or prevent time slippage. 4. Appropriate project management is integral to software development. 5. Documents should evolve with the software and should not delay the start of
construction. 6. Involve stakeholders early and frequently in the development process. 7. Testers need to become involved in the process prior to software construction.
In Section 2.6, we listed the pros and cons of several prescriptive process models. The waterfall model is not amenable to changes that may need to be introduced once developers start coding. Stakeholder feedback is therefore limited to the beginning and end of the project. Part of the reason for this is the waterfall model suggests that all analysis and design work products be completed before any programming or testing occurs. This makes it hard to adapt to projects with evolving requirements.
One temptation is to switch to an incremental model (Figure 4.1) like the prototyp- ing model or Scrum. Incremental process models involve customers early and often and therefore reduce the risk of creating product that is not accepted by the customers. There is a temptation to encourage lots of changes as stakeholders view each prototype and realize that functions and features they now realize they need are missing. Often, developers do not plan for prototype evolution and create throwaway prototypes.
Figure 4.1 Incremental model for prototype development
Implementation
Analysis & Design
Requirements
Evaluation
Testing
Initial Planning
Deployment
56 PART ONE THE SOFTWARE PROCESS
Recall that the goal of software engineering is to reduce unnecessary effort, so proto- types need to be designed with reuse in mind. Incremental models do provide a better basis for creating an adaptable process if changes can be managed wisely.
In Section 3.5, we discussed the pros and cons of several agile process models other than Scrum. Agile process models are very good at accommodating the uncer- tain knowledge about the stakeholders’ real needs and problems. Key characteristics of agile process models are:
∙ Prototypes created are designed to be extended in future software increments. ∙ Stakeholders are involved throughout the development process. ∙ Documentation requirements are lightweight, and documentation should
evolve along with the software. ∙ Testing is planned and executed early.
Scrum and Kanban extend these characteristics. Scrum is sometimes criticized for requiring too many meetings. But daily meetings make it hard for developers to stray too far from building products that stakeholders find useful. Kanban (Section 3.5.2) provides a good lightweight tracking system for managing the status and priorities of user stories.
Both Scrum and Kanban allow for controlled introduction of new requirements (user stories). Agile teams are small by design and may not be suitable for projects requiring large numbers of developers, unless the project can be partitioned into small and independently assignable components. Still, agile process models offer many good features that can be incorporated into an adaptable process model.
The spiral model (Figure 4.2) can be thought of as an evolutionary prototyping model with a risk assessment element. The spiral model relies on moderate stakeholder
Figure 4.2 Spiral model for prototype development
Determine Objectives
Identify Risks
Prototype 1
Prototype 2
Plan Next Iteration
Development and Testing
Prototype 3
CHAPTER 4 RECOMMENDED PROCESS MODEL 57
Creative, knowledgeable people perform software engineering. They adapt software processes to make them appropriate for the products that they build and to meet the demands of the marketplace. We think that using a spiral-like approach that has agil- ity built into every cycle is a good place to start for many software projects. Develop- ers learn many things as they proceed in the development process. That’s why it is important for developers to be able to adapt their process as quickly as practical to accommodate this new knowledge.
4 .1 Re Q u i R e m e n t s De f i n i t i o n
Every software project begins with the team trying to understand the problem to be solved and determining what outcomes are important to the stakeholders. This includes understanding the business needs motivating the project and the technical issues which constrain it. This process is called requirements engineering and will be discussed in
involvement and was designed for large teams and large projects. Its goal is to create extensible prototypes each time the process is iterated. Early testing is essential. Doc- umentation evolves with the creation of each new prototype. The spiral model is somewhat unique in that formal risk assessment is built in and used as the basis for deciding whether to invest the resources needed to create the next prototype. Some people argue that it may be hard to manage a project using the spiral model, because the project scope may not be known at the start of the project. This is typical of most incremental process models. The spiral is a good basis for building an adaptable process model.
How do agile process models compare to evolutionary models? We’ve summarized some of the key characteristics in a sidebar.
Agile 1. Not suitable for large high-risk or mission
critical projects. 2. Minimal rules and minimal documentation 3. Continuous involvement of testers 4. Easy to accommodate product changes 5. Depends heavily on stakeholder
interaction 6. Easy to manage 7. Early delivery of partial solutions 8. Informal risk management 9. Built-in continuous process
improvement
Spiral 1. Not suitable for small, low-risk projects 2. Several steps required, along with documen-
tation done up front 3. Early involvement of testers (might be done
by outside team) 4. Hard to accommodate product changes until
prototype completed 5. Continuous stakeholder involvement in
planning and risk assessment 6. Requires formal project management and
coordination 7. Project end not always obvious 8. Good risk management 9. Process improvement handled at end of project
chaRacteRistics of agiLe moDeLs
58 PART ONE THE SOFTWARE PROCESS
more detail in Chapter 7. Teams that fail to spend a reasonable amount of time on this task will find that their project contains expensive rework, cost overruns, poor product quality, late delivery times, dissatisfied customers, and poor team morale. Requirements engineering cannot be neglected, nor can it be allowed to iterate end- lessly before proceeding to product construction.
It’s reasonable to ask what best practices should be followed to achieve thorough and agile requirements engineering. Scott Ambler [Amb12] suggests several best prac- tices for agile requirements definition:
1. Encourage active stakeholder participation by matching their availability and valuing their input.
2. Use simple models (e.g., Post-it notes, fast sketches, user stories) to reduce barriers to participation.
3. Take time to explain your requirement representation techniques before using them.
4. Adopt stakeholder terminology, and avoid technical jargon whenever possible. 5. Use a breadth-first approach to get the big picture of the project done before
getting bogged down in details. 6. Allow the development team to refine (with stakeholder input) requirement
details “just in time” as user stories are scheduled to be implemented. 7. Treat the list of features to be implemented like a prioritized list, and imple-
ment the most important user stories first. 8. Collaborate closely with your stakeholders and only document requirements at
a level that is useful to all when creating the next prototype. 9. Question the need to maintain models and documents that will not be referred
to in the future. 10. Make sure you have management support to ensure stakeholder and resource
availability during requirements definition.
It is important to recognize two realities: (1) it is impossible for stakeholders to describe an entire system before seeing the working software, and (2) it is difficult for stakeholders to describe quality requirements needed for the software before seeing it in action. Developers must recognize that requirements will be added and refined as the software increments are created. Capturing stakeholders’ descriptions about what the system needs to do in their own words in a user story is a good place to begin.
If you can get stakeholders to define acceptance criteria for each user story, your team is off to a great start. It is likely that stakeholders will need to see a user story coded and running to know whether it has been implemented correctly or not. There- fore, requirements definition needs to be done iteratively and include the development of prototypes for stakeholder review.
Prototypes are tangible realizations of project plans that can be easily referenced by stakeholders when trying to describe desired changes. Stakeholders are motivated to discuss requirements changes in more concrete terms, which improves communica- tion. It’s important to recognize that prototypes allow developers to focus on short- term goals by only focusing on users’ visible behaviors. It will be important to review
CHAPTER 4 RECOMMENDED PROCESS MODEL 59
prototypes with an eye to the quality. Developers need to be aware that using proto- types may increase the volatility of the requirements if stakeholders are not focused on getting things right the first time. There is also the risk that creating prototypes before the software architectural requirements are well understood may result in pro- totypes that must be discarded, wasting time and resources [Kap15].
4 .2 pR e L i m i na Ry aRc h i t e c t u R a L De s i g n
The decisions required to develop a solid architectural design are discussed in Chapter 10, but preliminary design decisions must often be made as requirements are defined. As shown in Figure 4.3, at some point in time, architectural decisions will need to be allocated to product increments. According to Bellomo and her colleagues [Bel14], early understanding of requirements and architecture choices is key to managing the development of large or complex software products.
Figure 4.3 Architectural design for prototype development
2.Identifyff Key Scenarios
3. C reate
A pplication
O veeerview
1. Identify Architecture Objectives
4.IdentifyffKeyIssues
5. D
efi ne
C an
di da
te S
ol uuttt
io ns
60 PART ONE THE SOFTWARE PROCESS
Requirements can be used to inform architecture design. Exploring the architecture as the prototype is developed facilitates the process of detailing the requirements. It is best to conduct these activities concurrently to achieve the right balance. There are four key elements to agile architectural design:
1. Focus on key quality attributes, and incorporate them into prototypes as they are constructed.
2. When planning prototypes, keep in mind that successful software products combine customer-visible features and the infrastructure to enable them.
3. Recognize that an agile architecture enables code maintainability and evolv- ability if sufficient attention is paid to architectural decisions and related quality issues.
4. Continuously managing and synchronizing dependencies between the functional and architectural requirements is needed to ensure the evolving architectural foundation will be ready just in time for future increments.
Software architecture decision making is critical to the success of a software system. The architecture of a software system determines its qualities and impacts the system throughout its life cycle. Dasanayake et al. [Das15] found that software architects are prone to making errors when their decisions are made under levels of uncertainty. Architects make fewer bad decisions if they can reduce this uncer- tainty through better architectural knowledge management. Despite the fact that agile approaches discourage heavy documentation, failing to record design deci- sions and their rationale early in the design process makes it hard to revisit them when creating future prototypes. Documenting the right things can assist with pro- cess improvement activities. Documenting your lessons learned is one of the rea- sons that retrospectives should be conducted after evaluating the delivered prototype and before beginning the next program increment. Reuse of previously successful solutions to architectural problems is also helpful and will be discussed in Chapter 14.
4 .3 Re s o u Rc e est i m at i o n
One of the more controversial aspects of using spiral or agile prototyping is estimat- ing the time it will take to complete a project when it cannot be defined completely. It is important to understand before you begin whether you have a reasonable chance of delivering software products on time and with acceptable costs before you agree to take on the project. Early estimates run the risk of being incorrect because the project scope is not well defined and is likely to change once development starts. Estimates made when the project is almost finished do not provide any project man- agement guidance. The trick is to estimate the software development time early based on what is known at the time and revise your estimates on a regular basis as require- ments are added or after software increments are delivered. We discuss methods of estimating project scope in Chapter 25.
Let’s examine how an experienced software project manager might estimate a proj- ect using the agile spiral model we have proposed. The estimates produced by this
CHAPTER 4 RECOMMENDED PROCESS MODEL 61
method would need to be adjusted for the number of developers and the number of user stories that can be completed simultaneously.
1. Use historic data (Chapter 23), and work as a team to develop an estimate of how many days it will take to complete each of the user stories known at the start of the project.
2. Loosely organize the user stories into the sets that will make up each sprint1 (Section 3.4) planned to complete a prototype.
3. Sum the number of days to complete each sprint to provide an estimate for the duration of the total project.
4. Revise the estimate as requirements are added to the project or prototypes are delivered and accepted by the stakeholders.
Keep in mind that doubling the number of developers almost never cuts the devel- opment time in half.
Rosa and Wallshein [Ros17] found that knowing initial software requirements at the start of a project provides an adequate but not always accurate estimate of project completion times. To get more accurate estimates, it is also important to know the type of project and the experience of the team. We will describe more detailed estima- tion techniques (e.g., function points or use case points) in Part Four of this book.
4 .4 fi R st pRotot y p e co n st Ru c t i o n
In Section 2.5.2 we described the creation of prototypes as a means of helping the stakeholders move from statements of general objectives and user stories to the level of detail that developers will need to implement this functionality. Developers may use the first prototype to prove that their initial architectural design is a feasible approach to delivering the required functionality while satisfying the customer’s per- formance constraints. To create an operational prototype suggests that requirements engineering, software design, and construction all proceed in parallel. This process is shown in Figure 4.1. This section describes steps that will be used to create the first prototypes. Details of best practices for software design and construction appear later in this book.
Your first task is to identify the features and functions that are most important to the stakeholders. These will help define the objectives for the first prototype. If the stakeholders and developers have created a prioritized list of user stories, it should be easy to confirm which are the most important.
Next, decide how much time will be allowed to create the first prototype. Some teams may choose a fixed time, such as a 4-week sprint, to deliver each prototype. In this case, the developers will look at their time and resource estimate and determine which of the high-priority user stories can be finished in 4 weeks. The team would then confirm with the stakeholders that the selected user stories are the best ones to include in the first prototype. An alternative approach would be to have the stakeholders
1 Sprint was described (Section 3.4) as a time period in which a subset of the system user stories will be delivered to the product owner.
62 PART ONE THE SOFTWARE PROCESS
and developers jointly choose a small number of high-priority user stories to include in the first prototype and use their time and resource estimates to develop the sched- ule to complete the first prototype.
The engineers working at National Instruments published a white paper that out- lines their process for creation of a first functional prototype [Nat15]. These steps can be applied to a variety of software projects:
1. Transition from paper prototype to software design 2. Prototype a user interface 3. Create a virtual prototype 4. Add input and output to your prototype 5. Engineer your algorithms 6. Test your prototype 7. Prototype with deployment in mind
Referring to these seven steps, creating a paper prototype for a system is very inexpensive and can be done early in the development process. Customers and stakeholders are not usually experienced developers. Nontechnical users can often recognize what they like or do not like about a user interface very quickly once they see it sketched out. Communications between people are often filled with misunder- standings. People forget to tell each other what they really need to know or assume that everyone has the same understanding. Creating a paper prototype and reviewing it with the customer before doing any programming can help avoid wasted time build- ing the wrong prototype. We will talk about several diagrams that can be used to model a system in Chapter 8.
Creating a prototype user interface as part of the first functional prototype is a wise idea. Many systems are implemented on the Web or as mobile applications and rely heavily on touch user interfaces. Computer games and virtual reality applications require a great deal of communication with end users to operate correctly. If custom- ers find a software product easy to learn and use, they are more likely to use it.
Many misunderstandings between developers and stakeholders can be alleviated by beginning with a paper prototype of the user interface. Sometimes stakeholders need to see the basics of the user interface in action to be able to explain what they really like and dislike about it. It is less expensive to throw away an early user interface design than to finish the prototype and try to put a new user interface on top of it. Designing user interfaces that provide good user experiences is discussed in Chapter 12.
Adding input and output to your user interface prototype provides an easy way to begin testing the evolving prototype. Testing software component interfaces should be accomplished before testing the code that makes up the component’s algorithms. To test the algorithms themselves, developers often use a “test frame” to ensure their implemented algorithms are working as intended. Creating a separate test frame and throwing it away is often a poor use of project resources. If properly designed, the user interface can serve as the test frame for component algorithms, thereby eliminat- ing the effort required to build separate test frames.
Engineering your algorithms refers to the process of transforming your ideas and sketches into programming language code. You need to consider both the functional
CHAPTER 4 RECOMMENDED PROCESS MODEL 63
requirements stated in the user story and the performance constraints (both explicit and implicit) when designing the necessary algorithms. This is the point where addi- tional support functionality is likely to be identified and added to the project scope, if it does not already exist in a code library.
Testing your prototype demonstrates required functionality and identifies yet undis- covered defects before demonstrating it to the customer. Sometimes it is wise to involve the customer in the testing process before the prototype is finished to avoid developing the wrong functionality. The best time to create test cases is during require- ments gathering or when use cases have been selected for implementation. Testing strategies and tactics are discussed in Chapters 19 through 21.
Prototyping with deployment in mind is very important because it helps you to avoid taking shortcuts that lead to creating software that will be hard to maintain in the future. This is not saying that every line of code will make it to the final software product. Like many creative tasks, developing a prototype is iterative. Drafts and revi- sions are to be expected.
As prototype development occurs, you should carefully consider the software archi- tectural choices you make. It is relatively inexpensive to change a few lines of code if you catch errors before deployment. It is very expensive to change the architecture of a software application once it has been released to end users around the globe.
Room Designer Considering First Prototype
The scene: Doug Miller’s office.
The players: Doug Miller, software engineer- ing manager; Jamie Lazar, software team mem- ber; Vinod Raman, software team member.
The conversation: (A knock on the door. Jamie and Vinod enter Doug’s office.)
Jamie: Doug, you got a minute?
Doug: Sure, Jamie, what’s up?
Jamie: We’ve been thinking about the scope of this SafeHome room design tool.
Doug: And?
Vinod: There’s a lot of work that needs to be done on the back end of the project before people can start dropping alarm sensors and trying furniture layouts.
Jamie: We don’t want to work on the back end for months and then have the project can- celled when the marketing folks decide they hate the product.
Doug: Have you tried to work out a paper prototype and review it with the marketing group?
Vinod: Well, no. We thought it was important to get a working computer prototype quickly and did not want to take the time to do one.
Doug: My experience is that people need to see something before they know whether they like it or not.
Jamie: Maybe we should step back and cre- ate a paper prototype of the user interface and get them to work with it and see if they like the concept at all.
Vinod: I suppose it wouldn’t be too hard to program an executable user interface using the game engine we were considering using for the virtual reality version of the app.
Doug: Sounds like a plan. Try that approach, and see if you have the confidence you need to start evolving your prototype.
safehome
64 PART ONE THE SOFTWARE PROCESS
4 .5 pRotot y p e eva Luat i o n
Testing is conducted by the developers as the prototype is being built and becomes an important part of prototype evaluation. Testing demonstrates that prototype com- ponents are operational, but it’s unlikely that test cases will have found all the defects. In the spiral model, the results of evaluation allow the stakeholders and developers to assess whether it is desirable to continue development and create the next prototype. Part of this decision is based on user and stakeholder satisfaction, and part is derived from an assessment of the risks of cost overruns and failure to deliver a working product when the project is finished. Dam and Siang [Dam17] suggest several best- practice tips for gathering feedback on your prototype.
1. Provide scaffolding when asking for prototype feedback. 2. Test your prototype on the right people. 3. Ask the right questions. 4. Be neutral when presenting alternatives to users. 5. Adapt while testing. 6. Allow the user to contribute ideas.
Providing scaffolding is a mechanism for allowing the user to offer feedback that is not confrontational. Users are often reluctant to tell developers that they hate the product they are using. To avoid this, it is often easier to ask the user to provide feedback using a framework such as “I like, I wish, What if” as a means of providing open and honest feedback. I like statements encourage users to provide positive feed- back on the prototype. I wish statements prompt users to share ideas about how the prototype can be improved. These statements can provide negative feedback and con- structive criticism. What if statements encourage users to suggest ideas for your team to explore when creating prototypes in future iterations.
Getting the right people to evaluate the prototype is essential to reduce the risk of developing the wrong product. Having development team members do all the testing is not wise because they are not likely to be the representative of the intended user population. It’s important to have the right mix of users (e.g., novice, typical, and advanced) to give you feedback on the prototype.
Asking the right questions implies that all stakeholders agree on prototype objec- tives. As a developer, it’s important to keep an open mind and do your best to convince users that their feedback is valuable. Feedback drives the prototyping process as you plan for future product development activities. In addition to general feedback, try to ask specific questions about any new features included in the prototype.
Be neutral when presenting alternatives allows the software team to avoid mak- ing users feel they are being “sold” on one way to do things. If you want honest feedback, let the users know that you have not already made up your mind that there is only one right way to do things. Egoless programming is a development philosophy that focuses on producing the best product the team can create for the intended users. Although it is not desirable to create throwaway prototypes, egoless programming suggests that things that are not working need to be fixed or
CHAPTER 4 RECOMMENDED PROCESS MODEL 65
discarded. So try not to become too attached to your ideas when creating early prototypes.
Adapt while testing means that you need a flexible mind-set while users are work- ing with the prototype. This might mean altering your test plan or making quick changes to the prototype and then restarting the testing. The goal is to get the best feedback you can from users, including direct observation of them as they interact with the prototype. The important thing is that you get the feedback you need to help decide whether to build the next prototype or not.
Allow users to contribute ideas means what it says. Make sure you have a way of recording their suggestions and questions (electronically or otherwise). We will dis- cuss additional ways of conducting user testing in Chapter 12.
Room Designer Evaluating First Prototype
The scene: Doug Miller’s office.
The players: Doug Miller, software engineer- ing manager; Jamie Lazar, software team mem- ber; Vinod Raman, software team member.
The conversation: (A knock on the door. Jamie and Vinod enter Doug’s office.)
Jamie: Doug, you got a minute?
Doug: Sure, Jamie, what’s up?
Jamie: We completed the evaluation of the SafeHome room design tool working with our marketing stakeholders.
Doug: How did things go?
Vinod: We mostly focused on the user interface that will allow users to place alarm sensors in the room.
Jamie: I am glad we let them review a paper prototype before we created the PC prototype.
Doug: Why is that?
Vinod: We made some changes, and the marketing people liked the new design better, so that’s the design we used when we started programming it.
Doug: Good. What’s the next step?
Jamie: We completed the risk analysis and since we did not pick up any new user stories, we think it is reasonable to work on creating the next incremental prototype since we are still on time and within budget.
Vinod: So, if you agree, we’ll get the developers and stakeholders together and begin planning the next software increment.
Doug: I agree. Keep me in the loop and try to keep the development time on the next prototype to 6 weeks or less.
safehome
4.6 go, no-go De c i s i o n
After the prototype is evaluated, project stakeholders decide whether to continue development of the software product. If you refer to Figure 4.4, a slightly different decision based on the prototype evaluation might be to release the prototype to the
66 PART ONE THE SOFTWARE PROCESS
end users and begin the maintenance process. Sections 4.8 and 4.9 discuss this deci- sion in more detail. We discussed the use of risk assessment in the spiral model as part of the prototype assessment process in Section 2.5.3. The first circuit around the spiral might be used to solidify project requirements. But it really should be more. In the method we are proposing here, each trip around the spiral develops a meaningful increment of the final software product. You can work with the project user story or feature backlog to identify an important subset of the final product to include in the first prototype and repeat this for each subsequent prototype.
A pass through the planning region follows the evaluation process. Revised cost estimates and schedule changes are proposed based on what was discovered when evaluating the current software prototype. This may involve adding new user stories or features to the project backlog as the prototype is evaluated. The risk of exceeding the budget and missing the project delivery date is assessed by comparing new cost and time estimates against old ones. The risk of failing to satisfy user expectations is also considered and discussed with the stakeholders and sometimes senior manage- ment before deciding to create another prototype.
The goal of the risk assessment process is to get the commitment of all stakeholders and company management to provide the resources needed to create the next prototype. If the commitment is not there because the risk of project failure is too great, then the project can be terminated. In the Scrum framework (Section 3.4), the go, no-go decision might be made during the Scrum retrospective
Figure 4.4 Recommended software process model
Requirements Engineering
Preliminary Architectural Design
Estimate Required Project Resources
Prototype Becomes Software Release
Maintain Software
Go, No-Go Decision
Evaluate Prototype
Redefine Scope
Construct Next Prototype
Evolve System
Construct 1st Prototype
Project Conception
End Project
CHAPTER 4 RECOMMENDED PROCESS MODEL 67
meeting held between the prototype demonstration and the new sprint planning meeting. In all cases, the development team lays out the case for the product owners and lets them decide whether to continue product development or not. A more detailed discussion of software risk assessment methods is presented in Chapter 26.
4 .7 pRotot y p e evo Lu t i o n
Once a prototype has been developed and reviewed by the development team and other stakeholders, it’s time to consider the development of the next prototype. The first step is to collect all feedback and data from the evaluation of the current proto- type. The developers and stakeholders then begin negotiations to plan the creation of another prototype. Once the desired features for the new prototype have been agreed upon, consideration is given to any known time and budget constraints as well as the technical feasibility of implementing the prototype. If the development risks are deemed to be acceptable, the work continues.
The evolutionary prototyping process model is used to accommodate changes that inevitably occur as software is developed. Each prototype should be designed to allow for future changes to avoid throwing it away and creating the next prototype from scratch. This suggests favoring both well-understood and important features when setting the goals for each prototype. As always, the customer’s needs should be given great importance in this process.
4.7.1 New Prototype Scope The process of determining the scope of a new prototype is like the process of determining the scope of the initial prototype. Developers would either: (1) select features to develop within the time allocated to a sprint, or (2) allocate sufficient time to implement the features needed to satisfy the goals set by the developers with stakeholder input. Either approach requires the developers to maintain a prioritized list of features or user stories. The priorities used to order the list should be determined by the goals set for the prototype by the stakeholders and developers.
In XP (Section 3.5.1), the stakeholders and developers work together to group the most important user stories into a prototype that will become the next release of the software and determine its completion date. In Kanban (Section 3.5.2), developers and stakeholders make use of a board that allows them to focus on the completion status of each user story. This is a visual reference that can be used to assist developers using any incremental prototype process model to plan and monitor the progress of the software development. Stakeholders can easily see the feature backlog and help the developers order it to identify the most useful stories needed in the next prototype. It is probably easier to estimate the time required to complete the selected user stories than to find the user stories that need to fit into a fixed time block. But the advice to keep prototype development time to 4 to 6 weeks should be followed to ensure ade- quate stakeholder involvement and feedback.
68 PART ONE THE SOFTWARE PROCESS
4.7.2 Constructing New Prototypes A user story should contain both a description of how the customer plans to interact with the system to achieve a specific goal and a description of what the customer’s definition of acceptance is. The development team’s task is to create additional software components to implement the user stories selected for inclusion in the new prototype along with the necessary test cases. Developers need to continue commu- nication with all stakeholders as they create the new prototype.
What makes this new prototype trickier to build is that software components cre- ated to implement new features in the evolving prototype need to work with the components used to implement the features included in the previous prototype. It gets even trickier if developers need to remove components or modify those that were included in the previous prototype because requirements have changed. Strategies for managing these types of software changes are discussed in Chapter 22.
It is important for the developers to make design decisions that will make the software prototype more easily extensible in the future. Developers need to document design decisions in a way that will make it easier to understand the software when making the next prototype. The goal is to be agile in both development and documen- tation. Developers need to resist the temptation to overdesign the software to accom- modate features that may or may not be included in the final product. They also should limit their documentation to that which they need to refer to during development or when changes need to be made in the future.
4.7.3 Testing New Prototypes Testing the new prototype should be relatively straightforward if the development team created test cases as part of the design process before the programming was com- pleted. Each user story should have had acceptance criteria attached to it as it was created. These acceptance statements should guide the creation of the test cases intended to help verify that the prototype meets customer needs. The prototype will need to be tested for defects and performance issues as well.
One additional testing concern for evolutionary prototypes is to ensure that adding new features does not accidentally break features that were working correctly in the previous prototype. Regression testing is the process of verifying that software that was previously developed and tested still performs the same way after it has been changed. It is important to use your testing time wisely and make use of the test cases that are designed to detect defects in the components most likely to be affected by the new features. Regression testing is discussed in more detail in Chapter 20.
4 .8 pRotot y p e Re L e a s e
When an evolutionary prototyping process is applied, it can be difficult for developers to know when a product is finished and ready for release to the customers. Software devel- opers do not want to release a buggy software product to the end users and have them decide the software has poor quality. A prototype being considered as a release candidate must be subjected to user acceptance testing in addition to functional and nonfunctional (performance) testing that would have been conducted during prototype construction.
User acceptance tests are based on the agreed-upon acceptance criteria that were recorded as each user story was created and added to the product backlog. This allows
CHAPTER 4 RECOMMENDED PROCESS MODEL 69
user representatives to verify that the software behaves as expected and collect suggestions for future improvements. David Nielsen [Nie10] has several suggestions for conducting prototype testing in industrial settings.
When testing a release candidate, functional and nonfunctional tests should be repeated using the test cases that were developed during the construction phases of the incremental prototypes. Additional nonfunctional tests should be created to verify that the performance of the prototype is consistent with the agreed-upon benchmarks for the final product. Typical performance benchmarks may deal with system response time, data capacity, or usability. One of the most important nonfunctional requirements to verify is ensuring that the release candidate will run in all planned run-time envi- ronments and on all targeted devices. The process should be focused on testing limited to the acceptance criteria established before the prototype was created. Testing cannot prove a software product is bug free, only that the test cases ran correctly.
User feedback during acceptance testing should be organized by user-visible func- tions as portrayed via the user interface. Developers should examine the device in question and make changes to the user interface screen if implementing these changes will not delay the release of the prototype. If changes are made, they need to be verified in a second round of testing before moving on. You should not plan for more than two iterations of user acceptance testing.
It is important, even for projects using agile process models, to use an issue track- ing or bug reporting system (e.g., Bugzilla2 or Jira3) to capture the testing results. This allows developers to record test failures and makes it easier to identify the test cases that will need to be run again to verify that a repair properly corrects the prob- lem that was uncovered. In each case the developers need to assess whether the changes can be made to the software without causing a cost overrun or late product delivery. The implications of not fixing a problem need to be documented and shared with both the customer and senior managers who may decide to cancel the project rather than committing the resources needed to deliver the final project.
The issues and lessons learned from creating the release candidate should be doc- umented and considered by the developers and stakeholders as part of the project postmortem. This information should be considered before deciding to undertake future development of a software product following its release to the user community. The lessons learned from the current product can help developers make better cost and time estimates for similar projects in the future.
Techniques for conducting user acceptance testing are discussed in Chapters 12 and 20. A more detailed discussion on software quality assurance is presented in Chapter 17.
4 .9 ma i n ta i n Re L e a s e so f t wa R e
Maintenance is defined as the activities needed to keep software operational after it has been accepted and delivered (released) in the end-user environment. Maintenance will continue for the life of the software product. Some software engineers believe that the majority of the money spent on a software product will be spent on maintenance activ- ities. Corrective maintenance is the reactive modification of software to repair problems
2 https://www.bugzilla.org/. 3 https://www.atlassian.com/software/jira.
70 PART ONE THE SOFTWARE PROCESS
discovered after the software has been delivered to a customer’s end user. Adaptive maintenance is reactive modification of software after delivery to keep the software usable in a changing end-user environment. Perfective maintenance is the proactive modification of the software after delivery to provide new user features, better program code structure, or improved documentation. Preventive maintenance is the proactive modification of the software after delivery to detect and correct product faults before they are discovered by users in the field [SWEBOK4]. Proactive maintenance can be scheduled and planned for. Reactive maintenance is often described as firefighting because it cannot be planned for and must be attended immediately for software systems that are critical to the success of the end-users’ activities. Figure 4.5 shows that only 21 percent of the developers’ time is typically spent on corrective maintenance.
For an agile evolutionary process model like the one described in this chapter, developers release working partial solutions with the creation of each incremental prototype. Much of the engineering work done is preventive or perfective maintenance as new features are added to the evolving software system. It is tempting to think that maintenance is handled simply by planning to make another trip around the spiral. But software problems cannot always be anticipated, so repairs may need to be made quickly and developers may be tempted to cut corners when trying to repair the broken
4 SWEBOK refers to the Software Engineering Body of Knowledge, which can be accessed using the following link: https://www.computer.org/web/swebok/v3.
Figure 4.5 Distribution of maintenance effort
Perfective (50%)
Adaptive (25%)
Preventive (4%)
Corrective (21%)
CHAPTER 4 RECOMMENDED PROCESS MODEL 71
software. Developers may not want to spend time on risk assessment or planning. Yet, developers cannot afford to make changes to software without considering the pos- sibility that the changes required to fix one problem will cause new problems to other portions of the program.
It is important to understand the program code before making changes to it. If developers have documented the code, it will be easier to understand if other people need to do the maintenance work. If the software is designed to be extended, main- tenance may also be accomplished more easily, other than emergency defect repairs. It is essential to test the modified software carefully to ensure software changes have their intended effect and do not break the software in other places.
The task of creating software products that are easy to support and easy to main- tain requires careful and thoughtful engineering. A more detailed discussion on the task of maintaining and supporting software after delivery is presented in Chapter 27.
1. Requirements engineering ∙ Gather user stories from all stakeholders. ∙ Have stakeholders describe acceptance
criteria user stories. 2. Preliminary architectural design
∙ Make use of paper prototypes and models. ∙ Assess alternatives using nonfunctional
requirements. ∙ Document architecture design decisions.
3. Estimate required project resources ∙ Use historic data to estimate time to
complete each user story. ∙ Organize the user stories into sprints. ∙ Determine the number of sprints needed
to complete the product. ∙ Revise the time estimates as use stories
are added or deleted. 4. Construct first prototype
∙ Select subset of user stories most important to stakeholders.
∙ Create paper prototype as part of the design process.
∙ Design a user interface prototype with inputs and outputs.
∙ Engineer the algorithms needed for first prototypes.
∙ Prototype with deployment in mind. 5. Evaluate prototype
∙ Create test cases while prototype is being designed.
∙ Test prototype using appropriate users. ∙ Capture stakeholder feedback for use in
revision process. 6. Go, no-go decision
∙ Determine the quality of the current prototype.
∙ Revise time and cost estimates for completing development.
∙ Determine the risk of failing to meet stakeholder expectations.
∙ Get commitment to continue development.
7. Evolve system ∙ Define new prototype scope. ∙ Construct new prototype. ∙ Evaluate new prototype and include
regression testing. ∙ Assess risks associated with continuing
evolution. 8. Release prototype
∙ Perform acceptance testing. ∙ Document defects identified. ∙ Share quality risks with management.
9. Maintain software ∙ Understand code before making changes. ∙ Test software after making changes. ∙ Document changes. ∙ Communicate known defects and risks to
all stakeholders.
RecommenDeD softwaRe pRocess steps
72 PART ONE THE SOFTWARE PROCESS
4 .10 su m m a Ry
Every project is unique, and every development team is made up of unique individuals. Every software project needs a road map, and the process of developing software requires a predictable set of basic tasks (communication, planning, modeling, construc- tion, and deployment). However, these tasks should not be performed in isolation and may need to be adapted to meet the needs of each new project. In this chapter, we suggested the use of a highly interactive, incremental prototyping process. We think this is better than producing rigid product plans and large documents prior to doing any programming. Requirements change. Stakeholder input and feedback should occur early and often in the development process to ensure the delivery of useful product.
We suggest the use of an evolutionary process model that emphasizes frequent stakeholder involvement in the creation and evaluation of incremental software pro- totypes. Limiting requirements engineering artifacts to the set of minimal useful documents and models allows the early production of prototypes and test cases. Plan- ning to create evolutionary prototypes reduces the time lost repeating the work needed to create throwaway prototypes. Making use of paper prototypes early in the design process can also help to avoid programming products that do not satisfy customer expectations. Getting the architectural design right before beginning actual develop- ment is also important to avoiding schedule slippage and cost overruns.
Planning is important but should be done expeditiously to avoid delaying the start of development. Developers should have a general idea about how long a project will take to complete, but they need to recognize that they are not likely to know all the project requirements until the software products are delivered. Developers would be wise to avoid detailed planning that extends beyond planning the current prototype. The developers and stakeholders should adopt a process for adding features to be implemented in future prototypes and to assess the impact of these changes on the project schedule and budget.
Risk assessment and acceptance testing are an important part of the prototype assessment process. Having an agile philosophy about managing requirements and adding new features to the final product is important as well. The biggest challenges developers have with evolutionary process models is managing scope creep while delivering a product that meets customer expectations and doing all this while deliv- ering the product on time and within budget. That’s what makes software engineering so challenging and rewarding.
pRo b L e m s a n D po i n t s to po n D e R
4.1. How does the Extreme Programming (XP) model differ from the spiral model in its treat- ment of incremental prototypes?
4.2. Write the acceptance criteria for the user story that describe the use of the “favorite places” or “favorites” feature found on most Web browsers that you wrote for Problem 3.7 in Chapter 3.
4.3. How would you create a preliminary architectural design for the first prototype for a mobile app that lets you create and save a shopping list on your device?
4.4. Where would you get the historic date needed to estimate the development time for the user stories in a prototype before it is written?
CHAPTER 4 RECOMMENDED PROCESS MODEL 73
4.5. Create a series of sketches representing the key screens for a paper prototype for the shop- ping list app you created in Problem 4.3.
4.6. How can you test the viability of the paper prototype you created for Problem 4.5?
4.7. What data points are needed to make the go, no-go decision during the assessment of an evolutionary prototype?
4.8. What is the difference between reactive and proactive maintenance?
Design element: Quick Look icon magnifying glass: © Roger Pressman
74
What is it? At the end of the day, people build computer software. The human aspects of software engineering often have as much to do with the success of a project as the latest and greatest technology.
Who does it? Individuals and teams do soft- ware engineering work. In some cases, one person has much of the responsibility, but in most industry-grade software efforts, a team of people does the work.
Why is it important? A software team will be successful only if the dynamics of the team are right. It is essential for software engineers on a team to play well with their colleagues and with other product stakeholders.
What are the steps? First, you need to try to emulate personal characteristics of successful
software engineers. Next, you should appreci- ate the complex psychology of software engi- neering work so that you can navigate your way through a project without peril. Then, you need to understand the structure and dynam- ics of software teams. Finally, you should appreciate the impact of social media, the cloud, and other collaborative tools.
What is the work product? Better insight into the people, the process, and the product.
How do I ensure that I’ve done it right? Spend the time to observe how successful software engineers do their work, and tune your approach to take advantage of the strengths they project.
Q u i c k L o o k
agile team . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 global teams . . . . . . . . . . . . . . . . . . . . . . . . . . 80 jelled team . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 psychology, software engineering . . . . . . . . . 75 social media . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
team attributes . . . . . . . . . . . . . . . . . . . . . . . . 77 team structures . . . . . . . . . . . . . . . . . . . . . . . . 78 team toxicity . . . . . . . . . . . . . . . . . . . . . . . . . . 77 traits, software engineer . . . . . . . . . . . . . . . . 75
k e y c o n c e p t s
C H A P T E R
5 In a special issue of IEEE Software, the guest editors [deS09] make the follow- ing observation:
Software engineering has an abundance of techniques, tools, and methods designed to improve both the software development process and the final product. However, software isn’t simply a product of the appropriate technical solutions applied in appropriate technical ways. Software is developed by people, used by people, and supports interaction among people. As such, human characteristics, behavior, and cooperation are central to practical software development.
Without a team of skilled and motivated people, success is unlikely.
Human Aspects of Software Engineering
CHAPTER 5 HUMAN ASPECTS OF SOFTWARE ENGINEERING 75
5 .1 ch a r ac t e r i st i c s o f a so f t wa r e eng i n e e r
So you want to be a software engineer? Obviously, you need to master the technical stuff, learn the skills required to understand the problem, design an effective solution, build the software, and test it in an effort to develop the highest-quality products pos- sible. You need to manage change, communicate with stakeholders, and use appropri- ate tools as needed. We will discuss these things at great length later in this book.
But there are other things that are equally important—the human aspects that will make you effective as a software engineer. Erasmus [Era09] identifies seven traits that are present when a software engineer exhibits “superprofessional” behavior.
An effective software engineer has a sense of individual responsibility. This implies a drive to deliver on her promises to peers, stakeholders, and her management. It implies that she will do what needs to be done, when it needs to be done in an over- riding effort to achieve a successful outcome.
An effective software engineer has an acute awareness of the needs of other team members, the stakeholders requesting changes to an existing software solution, and the managers who have overall control of the project. He observes the environment in which people work and adapts his behavior to take both into account.
An effective software engineer is brutally honest. If she sees a flawed design, she points out the flaws in a constructive but honest manner. If asked to distort facts about schedules, features, performance, or other product or project characteristics, she opts to be realistic and truthful.
An effective software engineer exhibits resilience under pressure. Software engi- neering is always on the edge of chaos. Pressure comes in many forms—changes in requirements and priorities, demanding stakeholders, and overbearing managers. An effective software engineer manages pressure so that his performance does not suffer.
An effective software engineer has a heightened sense of fairness. She gladly shares credit with her colleagues. She tries to avoid conflicts of interest and never acts to sabotage the work of others.
An effective software engineer exhibits attention to detail. This does not imply an obsession with perfection. He carefully considers the broader criteria (e.g., perfor- mance, cost, quality) that have been established for the product and the project in making his daily technical decisions.
Finally, an effective software engineer is pragmatic. She recognizes that software engineering is not a religion in which dogmatic rules must be followed, but rather a discipline that can be adapted based on the circumstances at hand.
5 .2 th e ps yc h o L o gy o f so f t wa r e eng i n e e r i ng
In a seminal paper on the psychology of software engineering, Bill Curtis and Diane Walz [Cur90] suggest a layered behavioral model for software development (Figure 5.1). At an individual level, software engineering psychology focuses on rec- ognition of the problem to be solved, the problem-solving skills required to solve it, and the motivation to complete the solution within the constraints established by outer layers in the model. At the team and project levels, group dynamics becomes the
76 PART ONE THE SOFTWARE PROCESS
dominating factor. Here, team structure and social factors govern success. Group com- munication, collaboration, and coordination are as important as the skills of an indi- vidual team member. At the outer layers, organizational behavior governs the actions of the company and its response to the business milieu.
5 .3 th e so f t wa r e te a m
In their classic book Peopleware, Tom DeMarco and Tim Lister [DeM98] discuss the cohesiveness of a software team:
We tend to use the word team loosely in the business world, calling any group of people assigned to work together a “team.” But many of these groups just don’t behave like teams. They may not have a common definition of success or any identifiable team spirit. What is missing is a phenomenon that we call jell.
A jelled team is a group of people so strongly knit that the whole is greater than the sum of the parts. . . .
Once a team begins to jell, the probability of success goes way up. The team can become unstoppable, a juggernaut for success. . . . They don’t need to be managed in the traditional way, and they certainly don’t need to be motivated. They’ve got momentum.
Figure 5.1
Business Milieu
Company
Project
Team
Individual
Software
Problem
Organizational Behavior
Group Dynamics
Cognition and Motivation
A layered behavioral model for software engineering (adapted from [Cur90]) Source: Adapted from Curtis, Bill, and Walz, Diane, “The Psychology of Programming in the Large: Team and Organizational Behavior,” Psychology of Programming, Academic Press, 1990.
CHAPTER 5 HUMAN ASPECTS OF SOFTWARE ENGINEERING 77
DeMarco and Lister contend that members of jelled teams are significantly more productive and more motivated than average. They share a common goal, a common culture, and in many cases, a “sense of eliteness” that makes them unique.
There is no foolproof method for creating a jelled team. But there are attributes that are normally found in effective software teams.1 Miguel Carrasco [Car08] sug- gests that an effective software team must establish a sense of purpose. An effective team must also inculcate a sense of involvement that allows every member to feel that his skill set and contributions are valued.
An effective team should foster a sense of trust. Software engineers on the team should trust the skills and competence of their peers and their managers. The team should encourage a sense of improvement, by periodically reflecting on its approach to software engineering and looking for ways to improve their work.
The most effective software teams are diverse in the sense that they combine a variety of different skill sets. Highly skilled technologists are complemented by mem- bers who may have less technical background but are more empathetic to the needs of stakeholders.
But not all teams are effective and not all teams jell. In fact, many teams suffer from what Jackman [Jac98] calls “team toxicity.” She defines five factors that “foster a potentially toxic team environment”: (1) a frenzied work atmosphere, (2) high frus- tration that causes friction among team members, (3) a “fragmented or poorly coor- dinated” software process, (4) an unclear definition of roles on the software team, and (5) “continuous and repeated exposure to failure.”
To avoid a frenzied work environment, the team should have access to all infor- mation required to do the job. Major goals and objectives, once defined, should not be modified unless absolutely necessary. A software team can avoid frustration if it is given as much responsibility for decision making as possible. An inappropri- ate process (e.g., unnecessary or burdensome work tasks or poorly chosen work products) can be avoided by understanding the product to be built and the people doing the work and by allowing the team to select the process model. The team itself should establish its own mechanisms for accountability (technical reviews2 are an excellent way to accomplish this) and define a series of corrective approaches when a member of the team fails to perform. And finally, the key to avoiding an atmosphere of failure is to establish team-based techniques for feedback and problem solving.
In addition to the five toxins described by Jackman, a software team often struggles with the differing human traits of its members. Some people gather information intu- itively, distilling broad concepts from disparate facts. Others process information lin- early, collecting and organizing minute details from the data provided. Some team members are comfortable making decisions only when a logical, orderly argument is presented. Others are intuitive, willing to make a decision based on “feel.” Some work
1 Bruce Tuckman observes that successful teams go through four phases (forming, storming, norming, and performing) on their way to becoming productive (http://en.wikipedia.org/ wiki/Tuckman%27s_stages_of_group_development).
2 Technical reviews are discussed in detail in Chapter 16.
78 PART ONE THE SOFTWARE PROCESS
hard to get things done long before a milestone date, thereby avoiding stress as the date approaches, while others are energized by the rush to make a last-minute dead- line. Recognition of human differences, along with other guidelines presented in this section, provide a higher likelihood of creating teams that jell.
5 .4 te a m st ru c t u r e s
The “best” team structure depends on the management style of your organization, the number of people who will populate the team and their skill levels, and the overall problem difficulty. Mantei [Man81] describes a number of project factors that should be considered when planning the structure of software engineering teams: (1) diffi- culty of the problem to be solved, (2) “size” of the resultant program(s) in lines of code or function points,3 (3) time that the team will stay together (team lifetime), (4) degree to which the problem can be modularized, (5) required quality and reli- ability of the system to be built, (6) rigidity of the delivery date, and (7) degree of sociability (communication) required for the project.
Over the past decade, agile software development (Chapter 3) has been suggested as an antidote to many of the problems that have plagued software project work. The agile philosophy encourages customer satisfaction and early incremental delivery of software, small highly motivated project teams, informal methods, minimal software engineering work products, and overall development simplicity.
A small, highly motivated project team, also called an agile team, adopts many of the characteristics of successful software project teams discussed in Section 5.3 and avoids many of the toxins that create problems. However, the agile philosophy stresses individual (team member) competency, coupled with group collaboration as critical success factors for the team. Channeling creative energy into a high- performance team must be a central goal of a software engineering organization. Cockburn and Highsmith [Coc01a] suggest that “good” software people can work within the framework of any software process, and weak performers will struggle regardless. The bottom line, they contend, is that “people trump process” but that even good people can be hampered by an ill-defined process and poor resource support. We agree.
To make effective use of the competencies of each team member and to foster effective collaboration through a software project, agile teams are self-organizing. A self-organizing team does not necessarily maintain a single team structure. The team makes the changes needed to its structure to respond to the changes in the develop- ment environment or changes in the evolving engineering problem solution.
Communication between team members and all project stakeholders is essential. Agile teams often have customer representatives as team members. This fosters respect among the developers and stakeholders, as well as providing avenues for timely and frequent feedback on the evolving products.
3 Lines of code (LOC) and function points are measures of the size of a computer program and are discussed in Chapter 24.
CHAPTER 5 HUMAN ASPECTS OF SOFTWARE ENGINEERING 79
5 .5 th e im pac t o f so c i a L me d i a
E-mail, texting, and videoconferencing have become ubiquitous activities in software engineering work. But these communication mechanisms are really nothing more than modern substitutes or supplements for the face-to-face contact. Social media is different.
Begel [Beg10] and his colleagues address the growth and application of social media in software engineering when they write:
The social processes around software development are . . . highly dependent on engineers’ abilities to find and connect with individuals who share similar goals and complementary skills, to harmonize each team member’s communication and teaming preferences, to collaborate and coordinate during the entire software lifecycle, and advocate for their product’s success in the marketplace.
In some ways, this “connection” can be as important as face-to-face communica- tion. The value of social media grows as team size increases and is magnified further when the team is geographically dispersed.
Social networking tools (e.g., Facebook, LinkedIn, Slack, Twitter) allow degrees- of-separation connections among software developers and related technologists. This allows “friends” on a social networking site to learn about friends of friends who may have knowledge or expertise related to the application domain or problem to be solved. Specialized private networks built on the social networking paradigm can be used within an organization.
Team Structure
The scene: Doug Miller’s office prior to the initiation of the
SafeHome software project.
The players: Doug Miller (manager of the SafeHome software engineering team), Vinod Raman, Jamie Lazar, and other members of the product software engineering team.
The conversation: Doug: Have you guys had a chance to look over the preliminary info on SafeHome that marketing has prepared?
Vinod (nodding and looking at his teammates): Yes. But we have a bunch of questions.
Doug: Let’s hold on to that for a moment. I’d like to talk about how we’re going to structure the team, who’s responsible for what . . .
Jamie: I’m really into the agile philosophy, Doug. I think we should be a self-organizing team.
Vinod: I agree. Given the tight time line and some of the uncertainty, and the fact that we’re all really competent [laughs], that seems like the right way to go.
Doug: That’s okay with me, but you guys know the drill.
Jamie (smiling and talking as if she was recit- ing something): We make tactical decisions, about who does what and when, but it’s our responsibility to get product out the door on time.
Vinod: And with quality.
Doug: Exactly. But remember there are constraints. Marketing defines the software increments to be produced—in consultation with us, of course.
safehome
80 PART ONE THE SOFTWARE PROCESS
It is very important to note that privacy and security issues should not be over- looked when using social media for software engineering work. Much of the work performed by software engineers may be proprietary to their employer and disclosure could be very harmful. For that reason, the distinct benefits of social media must be weighed against the threat of uncontrolled disclosure of private information.
5 .6 gL o ba L te a m s
In the software domain, globalization implies more than the transfer of goods and services across international boundaries. For the past few decades, an increasing num- ber of major software products have been built by software teams that are often located in different countries. These global software development (GSD) teams have unique challenges that include coordination, collaboration, communication, and specialized decision making. Approaches to coordination, collaboration, and communication are influenced by the team structure that has been established. Decision making on all software teams is complicated by four factors [Gar10a]:
∙ Complexity of the problem. ∙ Uncertainty and risk associated with the decision. ∙ The law of unintended consequences (i.e., a work-associated decision has an
unintended effect on another project objective). ∙ Different views of the problem that lead to different conclusions about the
way forward.
For a GSD team, the challenges associated with coordination, collaboration, and communication can have a profound effect on decision making. Figure 5.2 illustrates the impact of distance on the challenges that face a GSD team. Distance complicates
Figure 5.2 Factors affecting a GSD team
Barriers and Complexity
Distance
Communication CoordinationCollaboration
Complicates
Attenuate
Introduces Accentuates the need for
Reduces
CHAPTER 5 HUMAN ASPECTS OF SOFTWARE ENGINEERING 81
communication, but, at the same time, accentuates the need for coordination. Distance also introduces barriers and complexity that can be driven by cultural differences. Barriers and complexity attenuate communication (i.e., the signal-to-noise ratio decreases). The problems inherent in this dynamic can result in a project that becomes unstable.
5 .7 Su m m a ry
A successful software engineer must have technical skills. But, in addition, he must take responsibility for his commitments, be aware of the needs of his peers, be honest in his assessment of the product and the project, be resilient under pressure, treat his peers fairly, and exhibit attention to detail.
The psychology of software engineering includes individual cognition and motiva- tion, the group dynamics of a software team, and the organizational behavior of the company. A successful (“jelled”) software team is more productive and motivated than average. To be effective, a software team must have a sense of purpose, a sense of involvement, a sense of trust, and a sense of improvement. In addition, the team must avoid “toxicity” that is characterized by a frenzied and frustrating work atmosphere, an inappropriate software process, an unclear definition of roles on the software team, and continuous exposure to failure.
Agile teams subscribe to the agile philosophy and generally have more autonomy than more conventional software teams with rigid member roles and external manage- ment control. Agile teams emphasize communication, simplicity, feedback, courage, and respect.
Social media tools are becoming an integral part of many software projects, provid- ing services that enhance communication and collaboration for a software team. Social media and electronic communication are particularly useful for global software devel- opment where geographic separation can precipitate barriers to successful software engineering.
Pro b l e m S a n d Po i n t S to Po n d e r
5.1. Based on your personal observation of people who are excellent software developers, name three personality traits that appear to be common among them.
5.2. How can you be “brutally honest” and still not be perceived (by others) as insulting or aggressive?
5.3. How does a software team construct “artificial boundaries” that reduce their ability to communicate with others?
5.4. Write a scenario in which the SafeHome team members make use of one or more forms of social media as part of their software project.
5.5. Referring to Figure 5.2, why does distance complicate communication? Why does distance accentuate the need for coordination? What types of barriers and complexities are introduced by distance?
Design element: Quick Look icon magnifying glass: © Roger Pressman
