Copyright (c) 1990 Patrick D. Scannell Used by permission "Software Engineering Process Archaeology, An Overview" (Transcript of a lecture by Grant Money, D.S.A.) (Doctor of Software Archaeology) To trace the development of the Software Engineering Process, we must begin in the late Pleurassic period (so named because the air was very dense and it was hard to breathe.) It was during this period that violent geological upheavals brought to the earth's surface large deposits of silicon and germanium crystals, and the first crude programs, barely more than undifferentiated collections of single-bit organisms such as the primitive kilobyte, crawled out of the sea and began to live and thrive on silicon. More complex forms, such as structures and arrays, began to evolve. It was during the Ice Ages of the Fortybeloic period, however, that programs began to thrive and multiply. Unlike the dinosaurs who preferred a warmer climate, software produced its own heat and operated better in a colder environment. However, in the warmer Kerocene epoch which followed, the competition between programs became more fierce, and the first carnivorous programs such as viruses began to develop. Parasitic organisms such as statistics gathering tools also evolved during this period. During these periods, thousands of strains of primitive programs evolved, thrived for a while, and died out. But it was not until the advent of the customer that programs began to assume the importance that they have today. The oldest known customer, Pithecanthropurchaser, was discovered at Olduvai Gorge by Dr. Louis B. Sneaky. Fossil remains and other evidence indicate that the Pithecanthropurchaser whose remains Dr. Sneaky discovered died while waiting for a customer service line to take him off hold. (Of course, the average life span of the Pithecanthropurchaser was only about 35 years, so this is not too surprising.) The next step in the evolution of software was the invention of the requirements document. Until the requirements document, programs were purchased without being expected to do anything specific, or in some cases because they had done something interesting and the purchaser hoped that they might do it again. There was, however, no clear perception that a certain input might result in a certain output. The first requirements document is believed to have been a gift from aliens who carved it on a large basalt block, as dramatized in the movie "2001." The existence of requirement specs led purveyors of software to experiment with interbreeding of programs in order to produce desired characteristics. Gregor Mental, a monk, discovered that certain characteristics (such as Help Key Support) were recessive, but could be passed on to future generations of software. Thus a program with both the recessive help function and the dominant no help would not have help key support, but the offspring of two such programs would have one chance in four of having this characteristic. (What we would now call a feature.) Meanwhile, the first steps toward a Software Engineering Process Aggregation had been taken. The so-called "Midas" (or "Through the Goose") model, popular during the Middle Ages and Early Renaissance, looked like this: FRONT VIEW SIDE VIEW _______ __________________ / \ | | /\ ENG /\ | | / \ / \ Customer | | / \()/ \ =======| |===== \ PLM ||MFG / Input | | \ || / | | \_||_/ |___________________| As the diagram shows, this model allowed Engineering, PLM and Manufacturing to go round and round in circles, while Customer input went in one end and out the other without stopping. The next model, used throughout most of the 20th century, was the "Osmosis" model: ______________________________ CUSTOMER | | | | INPUT -------->| PLM | R&D | Mfg |---> PRODUCT |_________|_________|_________| This model has the advantage, for the customer, that some of the customer's requirements may, with some luck, filter through into the product by a process similar to osmosis. But what, we may ask, is the model of the '90s and beyond? Predictions, of course, are dangerous, but many scientists now believe that the "Osmosis" model will be replaced by the so- called "Milli Vanilli" model (sometimes also referred to as the "Tom Sawyer" model) in which the customers actually produce the software themselves, and the producer sells it back to them at a profit. Naturally, this model presents great challenges to the marketing and sales organizations. Thus, to summarize, we see that the development of software engineering process has made considerable progress over the past few eons, and yet in the end we must conclude that it still makes very little sense. Thank you. Good night.