The role of process models in software and systems development and evolution

Abstract

In seeking to maximise opportunity for achieving common understanding and real progress on specific issues, the announcement for the 5th Process Workshop adopts a somewhat narrow view of the role of Process Models. By so focussing the discussion, the fact that desirable characteristics of models will vary with the purpose for which they are to be used, the benefit one hopes to derive from their development or use and the value attached to benefit to gained from such activity has had to be disregarded. Yet process models can serve many purposes as summarised, for example, in the introduction to the Proceedings of the 4th workshop [SPW88] and also on the attached table. Though the roles included in that table are neither newly identified nor controversial they are listed so that they may be kept in the back of our minds as the Workshop discussion progresses.The individual importance of these roles can clearly not be ordered or even quantified. Their relative significance will depend on the goals of the work during which they are developed or used. The primary motivation underlying my work with process models over the past years has been the search for a better understanding of the software development and evolution process. This has led to conclusions which are, perhaps, self evident to many Computer Scientists, [DEM79], [FET88], [VAR79, 89] (as extreme examples) and others [BON77]. They are, however, not widely understood by the general public and, more importantly, by those involved in the definition and acquisition of computer systems for specific applications. In view of the increasing dependence of mankind on computers and, hence, on software it appears important to bring these, explicitly, into the open and to also examine their implications in the narrower confines of the topics discussed in the process workshop series.In the first instance my studies concentrated on an examination of models of program evolution in recognition of the fact that understanding and controlling that phenomenon demanded understanding and control of the programming process [LEH69, 85a]. This investigation led directly to the SPE classification scheme in which E-type programs, in particular, are defined as programs that implement applications or solve problems from and in the real world. In developing this schema process models played a fundamental role [LEH80b]. These models had no direct or immediate relationship to development practice but, nevertheless, led to the insight that is reflected in the LST process model [LEH84] that later formed the conceptual underpinning of a working environment [LEH85b].The work led to the view that an E-Type program is a model of a model of a … model of an application in the real world [LEH80b]. This abstract total-process model was enriched by Turski's view [TUR81] which regarded successive model pairs as a theory and a model of that theory or, equally, as a specification and an implementation of that specification. At the First Process Workshop [SPW84] Turski's interpretation of the “three-legged” model was, in fact, to see both the real world application (concept) and the final implementation as models of a specification that forms the bridge between concept and realisation. Equally, the source and target representations at the core of each step of the LST process, for example, may be viewed as a theory and a model of that theory.From Turski's view it follows that each implementation is Godel incomplete. Its properties, including functional properties, cannot be completely known from within the system. By their involvement in the development process and through system usage humans become an integral part of the system. It is their insights, viewpoints, theories, algorithms, definitions, formalisations, reactions, interpretations and so on that drive and direct the abstraction, refinement and evolution processes. They determine the degree of satisfaction that the final solution system yields. Hence it may be observed that for any software system implementing a solution to a real world problem, modelling some aspect of the real world, there exists a degree of Godel-type uncertainty about its properties [LEH89]. The definition, specification and development process must seek to limit this uncertainty so that it is of no practical significance; reflecting only abstract representational incompleteness.This is not the only type of uncertainty related to program behaviour under execution relative to the operational environment. A primary property of E-type programs is the fact that installation and operation of a system change the application and its operational domain. Implicitly if not explicitly, the system includes a model of itself. Also the acts of conceiving, developing, installing, using and adapting a software system change understanding of the application and its needs, methods of solution, the relative value of specific features of system functionality, opportunities for enhancement and human perception of all these. This leads to declining satisfaction with the system unless the system is adapted to the new reality. Because of the many feedback paths the system displays Heisenberg-type uncertainty [LEH77]. The more precise the knowledge of the application, of system properties and of their respective domains the less satisfaction does the solution system deliver in terms of what are, at the time of usage, the system properties perceived to be desirable. Mismatch between system properties and human needs and desires cannot be removed, except momentarily. Development, adaptation and evolution processes and their management are key to minimisation of the consequences of this inherent uncertainty.There is also a third type of uncertainty. The domain of an E-type application is, in general, unbounded and, effectively, continuous. The solution system is finite and discrete. The process of deriving one from the other involves a variety of abstractions on the basis of assumptions, about the application, its domain, perceived needs and opportunities, human responses to real world and solution system events, computational algorithms, theories about all these and so on. Some assumptions will be explicitly stated, others will be implicit. All will be built into the final system. But the real world is essentially dynamic, forever changing. Even without feedback effects as discussed above, exogenous changes in the real world will change the facts on which the assumption set is based. However careful and complete the control on the validity of assumptions is at the time they are built into the system some, at least, will, at best, be less than fully valid when the program is executed, or better, when the results of execution are applied. That is when, to be fully satisfactory, a program needs to be correct. Initial correctness at the time of implementation is merely a means to an end. The assumption set must be maintained correct without significant delay by appropriate changes to program or documentation texts, an impossible task even if assumptions could be precisely pinpointed. Pragmatic uncertainty in system behaviour is inevitable.This analysis leads to the following Uncertainty Principle for Computer Application: The outcome of software system operation in the real world is inherently uncertain with the precise area of uncertainty also not knowable.This position paper is not the place to explore this assertion in detail. Some aspects have been discussed elsewhere [LEH77, 89]. More immediately the principle throws a new light on the expectations to be associated with Software Engineering, the system and software development process and the models constructed to represent that process. One may have many views of the process. The new one that emerges from the above discussion is of software engineering in general and the software development and evolution (maintenance) process in particular as the means to minimise uncertainty, the consequences of uncertainty and the maintenance of user satisfaction. Project models must reflect this responsibility