ABSTRACT
The software profession’s first attempts at defining a life cycle for the development of software were unashamedly based on the assembly line concept that dominates manufacturing (see Exhibit 1). The fact that many of the businesses that moved into the area of software in the 1960s and 1970s were manufacturing industries reinforced this philosophy. People built the new product like they built the old product; they managed the way they were used to managing. Also, the nature of the systems being built at the time tended to reinforce the idea the software was a product to be produced, and that the production of this “product” had discrete phases through which it would pass before being shipped to the customer. One of the common characteristics of these systems was that the user’s requirements were often well defined and quite static. The computerized systems of the time often replaced existing systems, some of which were fully operational, albeit on paper. Even many of the engineering systems of the early computer decades of the 1950s through the early 1980s were deterministic endeavors in that the target functions of the systems were well understood, well defined, largely identifiable, and quite predictable. This was the era of the large COBOL systems, of the perennial designs and redesigns of payroll and accounting systems.
