Process models, process programs, programming support

One way of responding to a keynote speaker is to put the expressed views into context, pointing to highlights in the address, suggesting areas where alternative viewpoints might have been presented, exposing any chinks in the armour of the otherwise solid structure erected by the speaker. Logistics have made it impossible for this respondent to see the paper to be presented to ICSE9 by Professor L Osterweil before generating his own written response,. The above approach cannot, therefore, be taken. Instead, I raise a fundamental issue that follows from a comparison of the respective approaches to process modelling taken by Osterweil and myself. What is expressed here reflects my current understanding of his views on Process Programs and Process Programming, my reaction to what I believe he will present. I can only hope that this will not do too much violence to views to be expressed in his Proceedings paper or in the Keynote lecture itself. To set the scene and to provide a basis and framework for discussion, let me first summarize my view of studies of the software development process in terms of my own involvement in them. f To the best of my knowledge, the first such study was a 1956 paper by Benington [BEN56]. In this, a process model with basic characteristics of that subsequently termed the 'Waterfall Model', was first presented. Current interest in the software development process makes it most appropriate that this historic paper is to re-presented at this conference. In 1968/9, totally unaware of the earlier paper, I engaged in a study whose conclusions were presented in a confidential report entitled 'The Programming Process' [LEH69]. This has now become available in the open literature [LEH85, chapter 3] and is, I believe, as relevant today as at the time it was written. It was this study and the continuing research it triggered that subsequently led my colleagues and me to the concepts of process models, evolution dynamics, program evolution and support environments. Our earliest process models reflected the dynamics of the process [LEH85, chs. 5-9, 14, 16, 19]. By the mid 70's, at about the time that Barry Boehm [BOE76] popularized the Waterfall model first proposed by Royce [ROY70], my studies had led to a search for better understanding of the total process of software development. This total process was seen as extending from initial verbalization of the problem to be solved or computer application to be implemented, through delivery of the product and over its subsequent evolution. The search was expressed through the development and refinement of a sequence of Process Models [LEH85 chs. 3, 7, 14, 20, 21, 2]. It was directed towards first formulating a model of an ideal process ('ideal' though unachievable in the sense of the 'ideal' cycle of thermodynamics). Such a model would constitute a general paradigm. A practical process would be obtained by instantiation in terms of relevant concepts, available technologies, specific implementation environments, process constraints and so on. This development of process models culminated in the LST model [LEH84] and its subsequent analysis and application as presented at the first two Process Workshops [SPW84, 86]. The importance of that model is not only in the process it depicts. It is a canonical model of software development and of development steps. What has all this to do with process programs? Process programs, as described by Osterweil, are also process models. They are models constructed from linguistic elements expressed and structured in programmatic form. They are intended to define a procedure for achieving some desired end from an initial starting point and are expressed in terms of expressions in a natural or formal language. The procedure is implemented by executing the primitive actions named in the program. A process program to describe a process that, if followed, will permit execution of some specific task in its environment, can be systematically developed, top-down, in a manner equivalent to top-down development of a procedural program. The Osterweil approach is essentially equivalent, in the context of process modelling, to the use of procedural programming (in contrast to styles such as functional, imperative and so on). Its power is defined by the properties of the language used in relation to available execution mechanisms. In fact, a process program is precisely that - a procedural program whose value depends on the constructability of a mechanism that can execute it mechanically, human intervention being restricted primarily to the provision of information. This is a view that Osterweil will not dispute; in the papers that I have seen the algorithmic nature of process programs is repeatedly stressed. And therein lies the rub. The approach is fine, almost certainly useful, when comprehensive models of the phenomenon, the domain and the system that are the subject of the program are known and understood, when strategies and algorithms for achieving the desired ends are known a priori, when computational, managerial and administrative practices are fully defined. It is useless, indeed meaningless, if such phenomenological and algorithmic models do not exist [TUR86], if progress in definition (and execution) of the process is a function of the process itself.