Free Trial

Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.


  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint
Share this Page URL
Help

Chapter 1. Introduction

Chapter 1. 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 sequence 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 quality and perhaps increase productivity. For example, the design of software module interfaces should be delayed until the requirements 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)



  

You are currently reading a PREVIEW of this book.

                                                                                                                    

Get instant access to over $1 million worth of books and videos.

  

Start a Free 10-Day Trial


  
  • Safari Books Online
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint