Chapter Introduction

Fifty software engineers from 11 different countries, "all concerned professionally with software," attended a NATO Science Committee conference in Garmish, Germany in October 1968. While most discussions were focused on the technical aspects of design, production, implementation, distribution, and service of software, there were also reports on "the difficulties of meeting schedules and specifications on large software projects." This may have been the first public recognition of the importance of software project management—needless to say, those difficulties of "schedules and specifications" continue to trouble us today. Shortly afterward, 22 international leaders in software development from academia, industry, and research laboratories gathered at Hedsor Park, a corporate retreat near London, to commemorate the NATO conference and to analyze the future direction of software. These events became known as the first sober look at the impending "software crisis." Following this awakening to the serious impact software could have on human lives, improvements in the process of software development began to be introduced. Among them was the concept of a software life cycle (SLC) to represent the seguence of events that occur in software development. The definition of an SLC, as well as arguments for and against its raison d'etre, has been the subject of many conversations and publications in the software industry. By the late 1970s, the controversy resulted in the mantra, "Stop the life cycle, I want to get off!" Despite the differing views, the need for a documented software development process persisted. In 1970, W.W. Royce identified several phases in a typical SLC. Royce and Barry Boehm suggested that controlling the entry and the exit points from each phase in the process would improve guality and perhaps increase productivity. For example, the design of software module interfaces should be delayed until the reguirements have been specified, thereby reducing the amount of rework. Their model was informally labeled the "waterfall model" SLC because it was graphically portrayed in a manner similar to Figure 1-1. Software development activities "flow" from block to block in the graphic.

Figure 1-1. The " Waterfall" Software Life Cycle (SLC)

Figure 1-1. The " Waterfall" Software Life Cycle (SLC)

In reality, most project activities do not proceed linearly. Often, developers are required to revert to a previous phase to follow up on issues that were not adequately addressed at that time. When, in the design phase, a missing or incorrect requirement is discovered, the developer does not plow ahead, but revisits the requirements specifications phase. When the requirements specification is once again believed to be complete and correct, the design phase is reentered and begun again. To accommodate this iterative nature of software development, backward arrows were added to what was becoming the industry standard life cycle graphic, as illustrated in Figure 1-2.

Figure 1-2. The Iterative " Waterfall" Model Software Life Cycle (SLC)

Figure 1-2. The Iterative " Waterfall" Model Software Life Cycle (SLC)

Now, there are lots of people who feel that the waterfall model is old-fashioned or simplistic, having long ago outlived its usefulness—the very name seems wrong, since water cannot "fall" uphill to accommodate the backward arrows. All sorts of new models have been depicted to better show how the "real world" works, or how software can be developed faster, or how customers can become more engaged in the process to improve functionality. The spiral model, the evolutionary rapid prototyping model, the V-shaped model, and others have emerged to solve one issue or another. Today, most practitioners might agree that there are so many different types of projects, a one size SLC cannot possibly fit all. The modern viewpoint is that unique projects require unique models, or combinations of models, to succeed. We will discuss the choice of appropriate SLC models, or modified versions of SLC models, in Chapter 4. "Selecting Software Development Life Cycles." We will describe several of the more modern SLCs, and how a project manager can decide which one to use. We will also explain the process groups from the Project Management Body of Knowledge® (PMBOI^) Guide—initiating processes, planning processes, executing processes, and closing processes—and how they map to software life cycle phases.

For simplicity's sake, each chapter in this book will describe project activities by pegging them to the common "waterfall with iterations" life cycle. Though many software practices have changed considerably since the 1970s, tens of thousands of developers learned to use the language of the first SLC as part of a common vocabulary. The terms phase, iteration, entry criteria, exit criteria, concept exploration, maintenance, and so forth, have been passed on to succeeding generations of analysts, designers, and programmers. No matter what kind of software project, or its size or scope, the phases of concept exploration through retirement will take place one way or another. The old faithful SLC provides a cradle-to-grave snapshot of project steps, be they large or small. It is for this reason that we have chosen to describe how each of the chapters in this book fits into the overall software process by looking at where we are in the product development life cycle.

* PREVIOUS

* PREVIOUS

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment