In October 1968, fifty software engineers from eleven different countries, "all concerned professionally with software", attended a NATO Science Committee conference in Garmish, Germany. While most discussions were focused on the technical sides 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 - unneeded 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 remember the NATO conference and to analyze the future direction of software. These events became known as the first serious look at the imminent "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 idea of a software life cycle (SLC) to represent the series 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 discussions and publications in the software industry. By the late 1970s, the dispute resulted in the mantra, "Stop the life cycle, I want to get off!" regardless of the differing views, the need for a documented software development process continued firmly. In 1970, W.W. Royce identified several phases in a typical SLC. Royce and Barry Boehm recommended that controlling the entry and the exit points from each phase in the process would improve quality and perhaps increase productivity. For instance, the design of software module interfaces should be delayed until the requirements have been specified, thus reducing the amount of rework. Their model was informally labeled the "waterfall model" SLC because it was graphically portrayed in a manner similar to the following figure. Software development activities "flow" from block to block in the graphic.

In fact, the majority of project activities do not proceed linearly. Often, developers need to revert to a previous phase to follow up on issues that were not sufficiently 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 the following figure.
The Iterative
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 kinds 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 kinds of projects, a one size SLC cannot possibly fit all. The modern viewpoint is that distinctive 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 "Selecting Software Development Life Cycles". We will explain several of the more modern SLCs, and how a project manager can decide which one to use. We will also describe the process groups from the Project Management Body of Knowledge (PMBOK) Guide - initiating processes, planning processes, executing processes, and closing processes - and how they map to software life cycle phases.

For simplicity's sake, each article in this blog will describe project activities by pegging them to the common "waterfall with iterations" life cycle. Though many software practices have changed significantly 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 idea 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 explain how each of the article in this blog fits into the overall software process by looking at where we are in the product development life cycle.


software development, life cycle, project manager
The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.
Copyright 2017 SPMInfoBlog.
Designed by TechPlus