Software Evolution

ion is a bounding process. It determines the operational range of E-type systems. The bounds required for such systems are, generally, imprecise, even unclear and subject to change. Some of the boundaries will be well defined by prior practice or related experience, for example. Others are adopted on the basis of compromise or recognised constraints. Still others will be uncertain, undecidable or verging on the inconsistent. This situation may be explicitly acknowledged or remain unrecognised until exposed by chance or during system operation. Since applications and the domains to which they apply and in which they operate are dynamic, always changing, and E-type system (in particular) must be continually reviewed and, where necessary, changed to ensure continuing validity of execution results in all situations that may legitimately arise. In the context of evolution, fuzziness of bounds arises from several sources. The first relates to the, in general, unlimited, number of potential application properties from which those to be implemented and supported must be selected. The detail of system functional and nonfunctional properties and system behaviour also cannot be uniquely determined. A limited set must be selected for implementation on the basis of the current state of knowledge and understanding, experience, managerial and legal directives and so on. Precise bounds of the operational domains are, in general, equally undetermined. The uncertainty is overcome by provisionally selecting boundaries within which the system is to operate to provide satisfactory solutions at some level of precision and reliability, in some defined time frame, at acceptable cost. Inevitably however, once a system is operational, the need or desire to change or extend the area of validity, whether of domains or of behaviours, will inevitably arise. Without such changes, exclusions will become performance inhibitors, irritants and sources of system failure. In summary, the potential set of properties and capabilities to be included in a system is, in general, unbounded and not uniquely selectable. Even a set that appears reasonably complete may well exceed what can be accommodated within the resources and time allocated for system implementation. As implemented, system boundaries will be arbitrary, largely determined by many individual and group decision makers. Inevitably, the system will need to be continually evolved by modifying or extending domains it defines, and explicitly or implicitly assumes, so as to satisfy changing constraints, newly emerging needs or changed environmental circumstances. But, unlike those of the domain, once developed and installed, system boundaries become solid, increasingly difficult and costly to change, interpret and respect, fault prone, slow to modify. A user requiring a facility not provided by the system may, in the first instance, use stand-alone software to satisfy individual or local needs. This may be followed by direct coupling of such software tightly to the system for greater convenience in cooperative execution. But problems such as additional execution overhead, time delays, performance and reliability penalties and sources of error will emerge, however the desired or required function is invoked and the results of execution passed to the main system. Omissions become onerous; a source of performance inhibitors and user dissatisfaction. A request for system extension will eventually follow. The history of automatic computation is rich with examples of functions first developed and exploited as stand-alone application software, migrating inwards to become, at least conceptually, part of an operating or run time system and ultimately integrated into Software Evolution 21 some larger application system or, at the other extreme, into hardware (chips). This is exemplified by the history of language and graphics support. The evolving computing system is an expanding universe with an inward drift of function from the domains to the core of the system. The drift is driven by feedback about the effectiveness, strengths, weaknesses, precision, convenience and potential of the system as recognised during its use and the application of results. 1.6.7 The Consequence: Continual System Evolution Properties such as those mentioned make implementation and use of an E-type system a learning experience. Its evolution is driven, in part, by the ongoing experiences of those that interact with or use the results of execution directly or indirectly, of those who observe, experience or are affected by its use as well as those who develop or maintain it. The system must reflect any and all properties and behaviours of the application being implemented or supported, the domains in which the application is being executed, pursued and supported, and everything that affects the results of execution. It must be a model-like reflection8 of the application and its many operational domains. However as repeatedly observed, the latter are unbounded in the number of their properties. They, therefore, cannot be known entirely by humans during the conscious and unconscious abstraction and reification decisions that occur from conception onwards. The learning resulting from development, use and evolution plays a decisive role in the changes that must be implemented throughout its lifetime in the nature and pattern of its inevitable evolution. Evolution of E-type applications, systems, software and usage practices is clearly intrinsic to computer usage. Serious software suppliers and users experience the phenomenon as a continuing need to acquire successive versions, releases and upgrades of used software to ensure that the system maintains its validity, applicability, viability and value in an ever-changing world. Development and adaptation of such systems cannot be covered by an exhaustive and complete theory if only because of human involvement in the applications, the partially arbitrary nature of procedures in business, manufacturing, government, the service sector and so on, and the potential unboundedness of the domain boundaries (Turski 1981). Inherently, therefore, the software evolution process is, at least to some extent, ad hoc.