The process cycle

by Nazim H. Madhavji
Historically, the process of software development has played an important role in the field of software engineering. A number of software life-cycle models have been developed in the last three decades. These models, although helpful is giving general guidance to software developers, do not expose myriad details that are critical in any large software development project. Recent developments, however, have unfolded many hidden aspects of the software process, giving rise to a new discipline that we call software process engineering. This paper depicts software process in the context of software environments, examines recent developments in the process field and proposes the concept of process cycle, which embodies the scope of engineering and evolution of software processes. The paper describes the details of the process cycle, including such issues as the role of corporate goals and policies in the engineering, management, performance and improvement of software processes ;the transformation of the process artifacts through the process cycle ;role of human beings in this (meta-) process ; and communications in the cycle.
The great results of the scientific investigation of nature we are agreed upon knowing, but how much of our study are we bound to give to the processes by which those results are reached? The results have their visible bearing on human life. But all processes, too, all the items of fact, by which those results are reached and established, are interesting.
Matthew Arnold [ 11

1 Introduction
The software development process (hereafter referred to as soffwure process) comprises software engineering activities, including technical and managerial ones, that are carried
234

out in the production of software. The scope of these adivities includes determination and specification of system and software requirements ; analysis and management of risk ; software prototyping ; design; implementation ; verification and validation; software quality control and assurance; integration of components; documentation; management of software configurations and versions ; management of data ; evolution of software; project management; software evaluation; software contracting; software acquisition; commissioning and decommissioning of software etc. For over three decades now, software process has played a major role in the field of software engineering. Over this period, the study of software processes has led to the development of various life-cycle approaches that may be employed in engineering software. As early as 1956, Benington [2] proposed the nine-phase stage-wise model for the development of large software systems. An improvement of this model, now widely known as the waterfall model, was proposed in 1970 by Royce [3]. This model added two new key concepts to the stage-wise model; explicit feedback loops and the initial idea of what is now termed prototyping. In parallel, other attempts at improving software process resulted in the transformational approach by Balzer et al. [ a ] . This is an automatic paradigm to convert the formal specification of a software system into a program that satisfies the specification. Similarly, Basili and Turner [7], in aiming to reduce the product delivery time of the waterfall model, proposed an evolutionary model, which advocates early and frequent product delivery cycles with a focus on small incremental developdeliver-measure-adjust steps. Subsequently, another transformational approach, the LST model, was proposed by Lehman et al. [8]. This model represents software process as a multi-step sequence. Each step involves base and target representations that may also be viewed as specification and implementation. Only the first step has no predecessor representation or specification. More recently, in 1986, Boehm presented the spiral model of software development [9], a distinguishing feature of which is its risk-driven approach. A typical cycle in the spiral proceeds through iterative sequencing of steps leading to risk analysis and resolution for a given portion of the software product. If the risk cannot be fully resolved, the process leads to evolutionary prototypes, possibly taking simulation into account; otherwise, the basic waterfall type or transformational steps are followed. Among the benefits of these life-cycle models are that they help us to become aware of, and gain an increased understanding of, the software process; and to determine Software Engineering Journal September 1991

Authorized licensed use limited to: Universidade Estadual Do Sudoeste da Bahia. Downloaded on August 17,2010 at 20:49:20 UTC from IEEE Xplore. Restrictions apply.

the order of global activities involved in the production of software. These benefits may result in improved product quality, increased effectiveness of methods and tools, reduced software development and maintenance costs, and increased customer and developer satisfaction. A limitation of these models, however, is that they hide important process details that are crucial for the success of software projects. For example, these models are too abstract to convey the details of
0 the process steps required to resolve customer reported software problems. 0 triggering and terminating conditions of an activity. 0 the state of a product component before, during, and after a process step. 0 the notational, methodological, operational and other tools to be used in different process steps. 0 the inputs and outputs of an activity, and the sources and destinations of the data. 0 the manner in which data flow from one activity to another. 0 the roles played by humans in the process. 0 the constraints on the process steps. 0 how communication among humans is supported. 0 where parallel and sequential process steps exist.

given rise to a new discipline, which we call here software process engineering. In this paper, we examine recent developments that may lead to improved software environments. This improvement may help us in engineering and controlling the evolution of software processes, as well as in using these to guide software development. We present our concept of process cycle, which reveals and unifies a number of issues involved in the engineering, evolution and performance of software processes. For example, among other details, the process cycle points out

At best, fragments of such process information are informally described in various documents. This situation may not lead the process to have a synergistic effect on software development, and evolve with the changing needs of the software project. It is then not surprising that, even in the presence of life-cycle models, the maturity of software processes in software projects is generally disappointingly low [lo, 111, and the management, control and improvement of these processes has been extremely difficult. However, recent work has begun to expose, in a scientific manner, myriad details underlying the software life-cycle. Detailed process knowledge such as that described above, and which has been largely intuitive, is now being made explicit, by describing it formally in the form of process models or process programs [12]. This has led to tightly related matters such as understanding what we know and do not know about processes to be able to describe them; creating formalisms suitable for describing and representing processes; automating the software process ; and developing methodologies, tools, and environments for engineering and controlling the evolution of processes. In fact, all this has

0 the separation of concern among project-free, projectspecific, and application software-specificgoals and policies. 0 how these goals and policies relate to 0 development of generic process models. 0 tailoring, instantiation and enactment of processes. 0 performance of processes (i.e. development of software). 0 the separation of concern among the different roles of human beings (e.g. process engineers, process managers and process performers) in the different parts of the process cycle. the feed-front and feedback links through the process cycle, thereby supporting process evolution. 0 a variety of organisational structures (e.g. from single user to distributed organisations) in which the process cycle can be used.
In the following, we overview the evolution of software environments and we describe the process view of software environments. We also present the concept of process cycle.

2 Software environments and software process

Software environments, through their evolution in the 1970s and 1980s (characterised by their concern for specific methods, isolated or integrated tools, programming-in-thesmall and programming-in-the-large), have had two pnncipal goals. One is the production of high-quality software, and the other is the production of this software within budget and on time, through the use of automated tools. Although there have been improvements in software quality and productivity, the scale and increasing complexity of the problems being tackled have kept the two stated goals out of our reach. One of the reasons is that early environments

Levels D

issues

Focus

C B

Software process engineering and evolution methods, tools, people Software processes Software product engineering and evolution methods, tools, people Software products

Process Process Product Product

Fig. 1 Levels of abstraction in software environments

Software Engineering Journal September 1991
235

Authorized licensed use limited to: Universidade Estadual Do Sudoeste da Bahia. Downloaded on August 17,2010 at 20:49:20 UTC from IEEE Xplore. Restrictions apply.

did not capture software process significantly, and whatever process was captured is hard-wired in the tools in the environments. Consequently, the environments are not adaptable to varying software development situations during the software life-cycle. Consider, for example an individual tool such as Make 1131, which helps simplify recompilation of a set of affected modules after a change. 0 an integrated programming environment such as the Cornell Program Synthesizer [ 141, which supports intelligent editing and invocation of tools in a given programming context. 0 a project support environment such as ISTAR [15], which provides a framework for hierarchical processes.
0

cally, we shall focus on level D of Fig. 1, where we can examine the issues involved in engineering and evolution of software processes.

3 A process view of software environments

Noting that software process is only a means to an end, the process view enables us to see the way the process is enpineered, the way the process evolves and the processes that are being used to grow software. We can thus visualise a complete process enginering and evolution environment. However, an important point to note here is that software process is dynamic, making it difficult to manage. One way to engineer and control the evolution of such a dynamic entity is to describe and define models of software processes ; customise these models ; instantiate processes ensuing from these models; interpret these processes; and improve them using monitoring, change management and other appropriate tools.

They capture only small parts of the entire software process. Besides, changing these buried processes to meet the evolving needs of software projects, implies too frequent a modification of these systems to make it practical. Recent work in software environments, however, has yielded a view whereby software process is at the heart of an environment, guiding and controlling software development [16, 171. An important aspect of such a processoriented environment is that all the elements of a software project are explicitly integrated through the medium of software process: for example, human beings in their various technical and managerial roles; software tools; product parts and their states at various time; in [he process; timing, budgetary, data source and destination, goals, policies, and other constraints acting on the development process; the development activities and the order in which they are to be carried out etc. Thus, the correct and smooth running of an environment (and consequently the quality of the software produced therein) depends significantly on the quality of the software process in the environment. Such an environment would simplify the evolution of software process by providing methods, tools and engineers to plan, enact and change processes. By tuning processes according to the needs of the software project at hand and within impending constraints, there would be explicit control on the quality, budget and schedules of the software system being produced. This view is captured in Fig. 1, which shows four levels of abstraction in a process-oriented software environment. Level A represents software products engineered in the environment. Level B represents methods, tools and human beings engaged in the engineering and evolution of software products. Level C represents software processes used to integrate these methods, tools and human beings during software production. Finally, level D represents methods, tools and human beings engaged in the engineering and evolution of software processes for use in the environment. The right-hand column of the Figure shows that, at levels A and B, the focus in the environment is on software products; whereas, at levels C and D, the focus is on software processes. In such heterogeneous environments, there are several possible views we can envisage: for example, scale of the problems solved [ M I ; types of architectures used [19]; role of human beings involved; and taxonomy of the tools used. In this paper, however, we shall concentrate on the software process view of such environments. More specifi-

3.1 Process description and definition

A starting point for process improvement is to describe the current process as used in software development. The process model inherent in this description is called a descriptive model [20, 211. Describing a process means making the software process explicit. This involves modelling the actual software process, using an appropriate process modelling methodology [22, 231. In this modelling effort, we need to consider the aspects of the scale of the process model, the fact of evolution of the model, and the scale and evolution of the software products built using the The implied process [a]. central part of such a methodology that deals with the design of a process model needs to address the formalisms which may be used to represent process models. Several different formalisms have recently been proposed to address these needs. Below, we briefly sketch a representative sample of these.

0 Process programming languages [ 16, 251 : formalisms akin to conventional programming languages, supporting linguistic paradigms such as algorithmic, object-oriented, rule-based, applicative etc. 0 Design and analysis paradigm [26]: a visual formalism for describing activities, objects, agents, communication channels, process states and transitions, based on techniques and tools used for software design and analysis. 0 Behavioural approach 1271: a formalism for describing the abstractions of software creation and evolution activities, with a focus on the effects which the activities produce, rather than the specific procedures used to produce those effects. 0 Method-defining schema [ 281 : an entity-relationship attribute data model used as a formalism to describe a schema for representing a family of design methods, which may be customised for a particular design method and instantiated for a particular problem. 0 Rules [ 29, 301 : a formalism for modelling the software process in terms of precondition, activity and postconditions, where the precondition must be true for a particular activity to be executed, and one of the postconditions becomes true after the activity terminates. 0 Plan [ 311 : a formalism for representing processes as
Software Engineering Journal
September 1991

236
~

-. .

Authorized licensed use limited to: Universidade Estadual Do Sudoeste da Bahia. Downloaded on August 17,2010 at 20:49:20 UTC from IEEE Xplore. Restrictions apply.

hierarchical plans to achieve goals, where high-level goals are decomposed into subgoals and process actions such as tool invocations are selected to satisfy the subgoals. 0 ETVX [32] : a formalism in which a process is composed of activities, each with a list of entry criteria (E), a set of task descriptions (7), a validation procedure (V) a list and of exit criteria (X). 0 Functional approach [33]: where a process is described as a collection of activities, possibly hierarchical, which are characterised by their input and output relationship. 0 Knowledge-based approach [3]: where a process is viewed as a set of inter-related tasks performed by a network of loosely coupled, intelligent agents, who can interact and reason about how to best produce products and consume resources, even when planned processes break down. Although all of the above described formalisms attempt to represent process models, it is as yet too early to know how they will fare in the development and evolution of industrial-scale processes. However, as a step towards obtaining a deeper understanding of the different approaches, a comparison of alternative languages and approaches for representing software processes based on a common benchmark problem has recently been carried out [35]. The aspects considered in this comparison include breadth and depth coverage of the benchmark problem; volume (number of pages) required for the solution; objectives in language design; basic representation formalisms; basic components ; functionality; behaviour; and language base. Whereas descriptive processes focus on the existing ways of developing software, &fined processes focus on the desired ways of developing software, thus proceeding towards process improvement. Defined processes are also referred to as presmj%ive processes [%I, since they prescribe the tasks to be completed and the order in which they are to be completed. Yet another category of processes is called jroscrzjtive [ 371 ; these processes operate by prohibiting inappropriate programmer actions. In a recent paper [%I,show how corporate goals and policies, aimed at we engineering reliable software processes, can result in unrestricted, prescriptive and proscriptive processes. There are many desirable properties of defined processes. For example
0 they have, or should have, reasons supporting their definition [381. 0 they convey information readily, e.g. for following the prescribed process model. 0 they have several perspectives, e.g. functional, txhavioural and organisational [391. 0 they describe and integrate different levels of abstractions. 0 they have formally defined syntax and semantics [25]. 0 they are reusable, e.g. due to their properties, such as refinable, tailorable and portable. 0 they are comprehensive, i.e., broad and deep. 0 they are modular with well defined interfaces, for ease of evolution [NI.

Among the key benefits of a described or defined process are the facts that

0 it can be measured against actual or other processes, and any differences can be brought to reason. 0 it can be used to promote process understanding and standards among software developers. 0 it canbereused. 0 it can simplify process management, control and automation. 0 it can help identify process measurements points. 0 it can become the basis for the next level of process improvement. 0 it may enable effective communication about software processes. 0 it may support co-operative work among human beings.
Ultimately, these benefits, along with domain-specific knowledge, can result in higher quality of software because at every step there is commitment to problem understanding and the method of solving the problem.

3.2 Process customisation and instantiation

For any process model to be effective in the specific project at hand, there is a need to customise the model according to the project goals [23, 41431. This may be achieved by characterising various aspects of the project (e.g. product and process reliability, software productivity, resource constraints, and effectiveness of the usage of tools, methods and languages); setting up project goals; assessing how these goals are supported by the adopted process model; tailoring the process model to suit project goals; using the tailored process model in the project; and assessing and fine-tuning the model on an on-going basis. The customisation process would be simplified considerably if process models were organised hierarchically, leading from generic models at the top of the hierarchy to specific models at the bottom. For example, at the top level of generality, we envision one or more generic models, perhaps catering for widely different development approaches, e.g. integration of existing components versus custom development versus evolutionary development. These models should contain considerable detail or point to plug-in components for the detail. They should also be accompanied by guidance for customisation, matching up component (or alternative) choices with project goals etc. We can then form a customised model, by selecting the appropriate base generic model and following the tailoring guidance for that base. This forms a template for the project or perhaps for a class of systems for a given organisation. If not already carried out, a tailored process model needs to be instantiated [44, 451 with project-specific parameters, so that the instantiated process can be performed with a high degree of precision. This requires planning for instantiation [%I, which partly depends on such project-specific matters as project goals and policies; product structure; organisation of the development team; project schedules; and availability of human, tool and other resources. In addition, many aspects of the process being instantiated need to be considered at this point. Examples of these include information flowing through various process steps; specific conditions for triggering and terminating activities;
237

These properties may not be present in described processes.

Software Engineering Journal September 1991

Authorized licensed use limited to: Universidade Estadual Do Sudoeste da Bahia. Downloaded on August 17,2010 at 20:49:20 UTC from IEEE Xplore. Restrictions apply.

parallelisation and sequentialisation of activities; specific process measurement milestones; roles played by human beings in the process; components of the planned software system and how they relate to various process steps, including the states taken by these components and process steps; and the interface between the process and the interacting tools. Note also that process instantiation can occur statically (Le. before process enaction) or dynamically (i.e. during software development).

3.3 Process enactment

An important step beyond instantiating a process model is interpreting the resultant process description, thereby enacting the planned software process. The interpretation of a process description can be manual or automated. Manually interpreted process descriptions assist human beings in following the implied process models during software development. These processes are likely to be permissive, leaving humans with the freedom to make contextual decisions that, for whatever reasons, might not have been pre-planned. Thus, these descriptions, although informative, do not generally include context-sensitive extraneous details as they can be difficult to follow, to apply in other circumstances or to change. Manual interpretation of process descriptions is therefore particularly useful where there is uncertainty or variability in the software process [ M I or when creative decisions are involved. Examples include
0

Another important issue in the enactment of processes is the degree of flexibility in the software process. Manually interpreted processes are difficult to enforce. This is because it is not practical to enforce constraints at each minute process step in the software lifecycle. However, the danger of not being able to enforce processes is that management can quickly lose control of a software project, leading to a chaotic situation. Staff education, training and motivation are seen as ways to escape from this predicament [MI. In contrast, automatically interpreted processes are simpler to enforce. This is because process constraints are pliable in the form of software. However, the danger of over-zealous process automation is that it can lead us to believe that concrete progress is being made when, in fact, it may be curtailing the creativity of software developers [ 381. Process understanding [&I, and judicious decisions on what and how to automate in a given environmental context, are seen as ways of escaping from this predicament.

3.4

Process improvement

Once the desired process is defined and is in use, there is generally continuous pressure to manage and to improve it [40]. Resisting this pressure, or to procrastinate changes, may mean degrading the quality of the housing environment and thus the quality of the products developed within. Some reasons for the pressure to change include

high-level managerial processes, such as staff motivation and group co-ordination, where process steps or product representation may not be well structured or defined; where these may be highly contextual or one-of-akind; or when they involve human feelings, politics, satisfaction etc. 0 low-level technical processes, such as design and review tasks, which require creative judgement; are often unclear; or when these are subject to unforeseen, extemal pressure (e.g. customer demands and market forces).

0 the software process may be faulty. 0 the software process may be missing certain important
steps, rendering it ineffective. 0 the software process may be generic and needs to be customised in order to obtain specific results. 0 the assumptions under which the software process was engineered are no longer valid. 0 competitive pressure (such as improving cost, schedule, quality, performance or process maturity in general) is Seen as a way to maintain your relative position in the marketplace. 0 the dynamics of geo-politics, human beings and technology can have an effect on the software process. Avenues that can be pursued for tackling this problem of change include introducing process assessment and improvement programmes [49, 501 ; increasing the awareness of software process amongst the developers; keeping process under control ; measuring qualitative and quantitative aspects of software process [513 ; understanding process evolution, describing dependencies among objects, and recording and using process data to assess the impact of change [ 401 ; and monitoring the software process.

Machine-interpreted process descriptions, on the other hand, can take a more active role than manual ones by carrying out pre-programmed plans. In this automated support for the software process, what cannot be programmed for machine interpretation is left for humans to perform; the support system then either awaits representable results of the intermediate human process, in order to further interpret the process description, or takes its appropriate programmed action. Thus, these programmed descriptions may be suited to established and proven software processes: e.g. ones which do not have a high degree of uncertainty; are not liable to change frequently; have clearly defined steps and their ordering; have clearly defined conditions and exceptions that can occur during these steps; have clearly defined representations of product parts, the states these parts can assume and the relationships amongst these parts; and are likely to be required repeatedly. In addition, machine-interpreted process descriptions imply the need for automated execution mechanisms and process programming languages in which to program software processes. Such languages may well need to support a mixed variety of paradigms, such as algorithm, object-oriented, rule-based, graphical etc. [ 161.

The process cycle

Fig. 2 (hereafter referred to as the process cycle) is a concise and integrated view of engineering, management, performance and improvement of software processes. The process cycle, bounded by the three sectors A, B and C, defines the scope of the total set of process steps necessary for the development and evolution of software processes. It thus represents all the key issues discussed above. In addition, the cycle defines the key roles played by human beings, categories of tools used, goals and policies
Software Engineering Journal September 1991

238

Authorized licensed use limited to: Universidade Estadual Do Sudoeste da Bahia. Downloaded on August 17,2010 at 20:49:20 UTC from IEEE Xplore. Restrictions apply.

governing the processes, and inter-relationships and feedback among the different roles. The feed-front and feedback links a a m the three sectors complete a cycle of process engineering, management, performance and improvement ; hence, the name process c& y.

4.1

Sector A : engineering process models

In sector A, process engineers design, construct and improve generic process models according to project-free goals and policies. These goals and policies concern the process of developing process models (i.e. how the process modellers do their job) and the contents of process models (i.e. what job the process modellers do). Here, project-free implies that the goals and policies should be applicable to classes of process models and classes of application software products, rather than a specific process model and a specific application software product. For example, for a class of risky process models, the goals and policies might strongly suggest that process models are designed and simulated, and insist that human interpretation is a central part of process enaction. Similarly, for a class of application software characterised as mission critical, the project-free goals and policies might suggest modelling of certain process steps to encourage the use of formal methods for software development, and strict design and code review procedures. Sector A also shows the provision of process engineering and evolution tools which process engineers may use to produce and improve process descriptions. Because the goals and policies in this sector are project-free, the engineered process descriptions simplify the problem of process evolution and reuse across software projects. In addition, these process descriptions play an important role in setting process standards in an organisation.

in the software project. The process management team thus needs to have the ability to identify trouble-spots (i.e. corrupted process parts) in the process; dynamically isolate the corrupted parts without freezing the rest of the process; f x i the faulty parts, perhaps including dynamic restructuring, recustomising and re-instantiating the process parts; and eventually embed the modified process parts in the total process. Problems with the process may not be due only to the process steps themselves, but also to the state of the product; various changes in project-specific policies, goals, schedules, staff, organisation etc. Many of these changes are not predictable, and thus pose a serious threat to the smooth functioning of the process. There is thus a need for appropriate process management and improvement tools to aid this management task. Specific tools might focus on process monitoring, debugging, simulating, assessing, measuring, visualising, configuring, versioning etc. Although there may be similarities between the tools used in sector B and those used in sector A, the major difference is that in the latter sector the tools operate on genenc descriptions within a simulated environment; whereas, in the former sector, the tools generally operate on specific descriptions within both simulated and actual environments.

4.3 Sector C: performing software processes

In sector C, process performers (i.e. software developers) carry out software process, in order to build and improve the application software. This act is shown in the process cycle by a thin, downward, broken arrow from the enacted software process to the process performing tools. During software development, the process performers are subjected to application software-specific goals and policies. For example, there are usually specific software requirements that have to be satisfied in the design of a system. The process cycle also shows the need for process performing tools that these performers might use in the development process. Although there may be similarities in the tools used here to those used in sectors A and B, the fundamental difference is that these tools operate on application software parts; whereas those in sectors A and B operate on process parts.

4.2 Sector B: managing software processes

The descriptions developed in sector A are then adopted and customised by process managers (depicted in sector B of the process cycle) for use in specific software projects. Here, process managers are subjected to project-specific goals and policies that influence the customisation process. For example, these goals and policies might impose particular approval procedures for resource allocation in the software project, specific product and process inspection checkpoints etc. Similarly, for the production of a particular secure software system, such goals and policies might require some predetermined levels of skill in the usage of certain tools that may not have been considered as a standard for the development of all secure systems. A process customised to meet these goals and policies thus needs to capture appropriate steps to allow for dynamic resource allocation, inspection checkpoints and staff training programmes. Customised process descriptions need to be instantiated with project-specific parameters (e.g. assigning a particular person to a specific role), according to the project-specific goals and policies, and the current states of the product parts and the developing team. These instantiated descriptions are then released for interpretation, thereby enacting the implied software process. In general, instantiated process descriptions are enacted to integrate with related and previously activated processes
Software Engineering Journal September 1991

4.4 Feedback and imfwovements

An important aspect of the process cycle is that there is feedback about the process being used in sector C. Feedback generated by process performers is passed on to projectspecific process managers. This communication is shown by a thick broken arrow and a solid arrow from the running process to the process management tools. The feedback might include the smoothness with which the assigned tasks are being carried out; any bottlenecks in the development process; negative effects due to certain timing or development constraints ; the need for additional process steps or removal of superfluous ones etc. Process management tools would also provide feedback, by gathering some qualitative and quantitative data about the active process. The feedback received in sector B can be used in two important ways by process managers. First, this information can be used to fine-tune and make major improvements to the project-specific processes. The beneficiaries of these
239

Authorized licensed use limited to: Universidade Estadual Do Sudoeste da Bahia. Downloaded on August 17,2010 at 20:49:20 UTC from IEEE Xplore. Restrictions apply.

Fig. 2 The process cycle

improvements are process performers in sector C. Secondly, the feedback can be used by process managers to make generalisations about possible improvements in project-free, or generic, software processes. The beneficiaries of these generalisations are process engineers in sector A, who receive the feedback to make improvements to their process models. This cycle of building generic process models, tailoring and enacting them, communicating feedback for improvements from process performers to managers, and from managers to engineers, is continuous 1401. Finally, note that the feedback generated, or received, at any sector does not necessarily stay within the process cycle. In fact, it is important that, by some osmotic action at the outer ring of the cycle, such feedback is conveyed to the corporate levels for improvements to goals and policies.

4.5 Roles and distribution of responsibilities

The role structures within process engineering, process managing and process performing teams are implicit in the process cycle. For example, the process engineering team might be composed of a think tank working on the thee retical aspects of the software process, e.g. process understanding, formalisms, semantics, idealised or unconstrained improvements etc. ; managers concentrating on the impact of software process goals and policies on process models; and designers and implementors actually building, simulating and improving idealised process models, and analysing process feedback. Similarly, process managing and process performing teams may be appropriately organised. Another important point about the process cycle is that it permits distribution of process-related responsibilities across sectors A, B and C. At one extreme is the so-called I-design-you-adaptscenario. For instance, the process engineer builds a generic process model, and the process manager adopts and customises it for a specific project; the
240

manager instantiates a customised process model and the process performer cames it out. This scenario is most likely to take place in large organisations and institutions, often distributed, where a person is employed to play a specific role. At the other extreme is the so-called do-it-yourself scenario. For instance, a module tester might build a generic process model to ensure that each test case is considered in the testing process; test results are tied to the appropriate test case; bugs are logged for further analysis; and a selfreminder of the analysis task is sent. The same tester might then customise this generic process model to allow for local system configuration; for example, steps might be added to obtain the test cases, save test results along with the test cases, perform automatic logging of the bugs etc. Following customisation, the tester might instantiate the process description with specific tools and their options, required directory and file names, and other technical particularities. Once this process is in place, it might be enacted so as to assist in their task of testing modules. This scenario is most likely to take place in individual situations (technical or managerial) in a software project, where one person may play several roles, albeit at different moments.

5 Summary
Understanding software processes is critically important for producing high-quality software within budget and on time. Traditional software life-cycle paradigms give only general guidance on the development and evolution of software. Fundamentally, beyond these life-cycle paradigms, we need to unfold many hidden lower level process details so as to present an improved understanding of the development process. These process details, like conventional software, need to be supported by methods, tools and environments in order to have a better grasp on the evolution of software
Software Engineering Journal September 1991

Authorized licensed use limited to: Universidade Estadual Do Sudoeste da Bahia. Downloaded on August 17,2010 at 20:49:20 UTC from IEEE Xplore. Restrictions apply.

systems, as well as the development process itself. The support for software processes includes mechanisms for making processes explicit and reusing them; tailoring and instantiating generic processes to suit project-specific needs ; enacting processes; measuring and characterising process details; and controlling process evolution. Together, process understanding and process support have given rise to a new discipline, which we call software process engineering. This discipline has far-reaching implications, both in academia and the software industry. It is, however, interesting to note that both process understanding and the supporting technology are invariably intertwined. For instance, without adequate process understanding (e.g. process dynamics), some aspects of the supporting technology cannot be effective (e.g. the tools needed to change processes). Similarly, without appropriate supporting technology (e.g. process-metric tools), some aspects of the process are difficult to understand (e.g. those based on precise or quantitative measures of the behavioural aspects of the software process)*. It would then appear that, over the next decade, process understanding and process support would progress hand-in-hand with one prodding the other. In this paper, we have identified four key levels of abstraction in a process-oriented software environment (see Fig. 1):

Kame1 Toubache, Brian Warboys and Herbert Weber for their suggestions and comments on this paper. This research was in part funded by the Natural Science and Engineering Research Council of Canada.

7 References
[ I ] ARNOLD, M.: Literature and science 1865 i CULLER, D.A. n (Ed.): Poetry and criticism of Matthew Arnold (Houghton Mifflin, Boston, 1961) [2] BENINGTON, H.D.: Production of large computer programs, Proc. ONR Symp. on Advanced Programming Methods for Digital Computers, June 1956, pp. 1527 (see also Ann. Hist. Comput., October 1983, pp. 35CL361and Proc. 9th Int. Conf. on Software Engineering, 1987 (IEEE Computer Society Press) pp. -310) [3] ROYCE, W.W.: Managing the development of large software systems. Proc. IEEE Wescon, August 1970, pp. 1-9 (see also Proc. 9th Int. Conf. on Software Engineering, 1987 (IEEE Computer Society Press) pp. 3%338) [4] BALZER, R.: A global view of automatic programming.Third Joint Int. Conf. on Artificial Intelligence, Stanford University, August 1973,pp. 494-499 [51 BALZER, R.: Transformational implementation: an example,IEEE Tram., 1981,SE-7, (l),pp. S 1 4 [6] BALZER, R., CHEATHAM, T.E., and GREEN, C.: Software technology in the 1990s: using a new paradigm, IEEE Computer, November 1983,pp. 3 M [7] BASILI, V.R., and TURNER, AJ.: Iterative enhancement: a practical technique for software development,IEEE Tram., 1975,SE-1, (4), pp. 392-396 [ S ] LEHMAN, M.M., STENNING, V., and TURSKI, W.M.: Another look at software design methodology,ACM Softw. Eng. Not., 1984,9, (2), pp. 3%53 [9] BOEHM. B.W.: A spiral model of software development and enhancement, IEEE Computer, May 1988, pp. 61-72 (see also ACMSoftw. Eng. Not., August 1986,pp. 14-24) 101 HUMPHREY, W.S., KITSON, D.H., and U S E , T.C.: The state of software engineering practice: a preliminary report. Proc. 11th Int. Conf. on Software Engineering, Pittsburgh, Pennsylvania, May 1989, pp. 277-288 (IEEE Computer Society Press) 111 HUMPHREY, W.S., KITSON, D.H., and GALE, J.: A comparison of US. and Japanese software process maturity. Proc. 13th Int. Conf. on Software Engineering, Austin, Texas, May 1991, pp. 38-49(IEEE Computer Society Press) [ 121 TULLY, C. (Ed.): Representing and enacting the software process. Proc. 4th Int. Software Process Workshop, Moretonhampstead, Devon, UK, May 1988 (see also ACM SIGSOFT, 14, (4) (ACM Press)) [13] FELDMAN, S.I.: MAKE a program for maintaining computer programs, Softw. Pract. Ex)., 1979,9, pp. 225265 [14] TEITELBAUM, T., and REPS, T.: The Comell program synthesizer: a syntax directed programming environment, Commun. ACM, 1981,24, (9),pp. 56.3573 [15] DOWSON, M.: ISTAR an integrated project support environment,IEEE Softw., November 1987,pp. 6 1 5 [16] OSTERWEIL, L.: Software processes are software too. Proc.9th Int. Conf. on Software Engineering, Monterey, Califomia, April 1987 (IEEE Computer Society Press)pp. 2-13 [17] TAYLOR, R.N., BELZ, F.C., CLARKE, L.A., OSTERWEIL, LJ., SELBY, R.W., WILEDEN, J.C., WOLF, A.L., and YOUNG, M.: Foundations for the Arcadia environment architecture.hoc. ACM SIGPLANjSIGSOFTSymp. on Software Development Environments, Boston, Massachusetts, November 1988, (see also ACM SZGPLAN Not., 24, (Z), pp. 1-13) [ 181 PERRY, D.E.. and KAISER, G.E.: Models of software development environments, IEEE Tram., 1991, SE-17. (3), pp.
~ ~

A software products. B software product engineering and evolution facilities.

C softwareprocess.
D software process engineering and evolution facilities. These are aimed at supporting the evolution of software products, as well as software processes. In addition, we have proposed the concept of process cycle (see Fig. 2), which reveals and unifies a number of issues involved in the engineering, evolution and performance of software processes. The cycle separates the concem for engineering generic process models, managing project-specificprocesses and performing enacted processes. The implementation of this separation of concem in an establishment requires careful organisational and environmental planning, and discipline amongst the engaged process developers (from the corporate to the technical process levels). Only when we have attained a high degree of personal, group and organisational discipline in the process field are we likely to see significant improvement in software quality. As yet, we have a long and winding road ahead of us.

6 Acknowledgements
The author would like to thank Vic Basili, Mark Dowson, Karen Huff, Gail Kaiser, Takuya Katayama, Marc Kellner, Nashira (Chou-ch)Keshavjee, John McDermid, Hausi Muller, David Notkin, Lee Osterweil, Martyn Odd, Dewayne Perry, Bill Riddle, Dieter Rombach, Walt Scacchi, Wilhelm Schafer,

* This intertwining is visualised here as a network of

interdependent sub-components of process understanding and process technology. This view is considerably more general than Osterweils view of research deadlock between the need for a process programming language and the need to write process programs [ 171.
September 1991

Software Engineering Journal

241

Authorized licensed use limited to: Universidade Estadual Do Sudoeste da Bahia. Downloaded on August 17,2010 at 20:49:20 UTC from IEEE Xplore. Restrictions apply.

ZKk295 (see also Proc. loth Int. Conf. on Software Engineering, Singapore, April 1988 (IEEE Computer society Press) PP. M) [19] PENEDO, M.H., and RIDDLE, W.E.: Guest eidtors Intre duction: software engineering environment architectures, IEEE TYU~S., SE-14, (6), pp. 6 M 1988, 8 % [20] DOWSON, M.: The structure of the software process, ACM SIGSOFT S f t w . E%. Not., 1986,11, (4),pp. 6 4 [21] WILEDEN, J.C., and DOWSON, M. (Ed.): The software process and software environements. Proc. Int. Workshop, Coto de Caza, Trabuco Canyon, Califomia, August 1986 (see also ACM SIGSOFT Softw. Eng. Not., 1 , (4), and panel dis1 cussion on The software process and software enviroments. Proc.8th Int. Conf. on Software Engineering, pp. 302-304) [22] BOEHM, B., and BELZ, F.: Applying process programming to the spiral model. Proc. 4th Int. Software Process Workshop, Moretonhampstead, Devon, UK, May 1988 (see also ACMSIGSOFT, 14, (4),pp. 4&56 (ACMP e s ) rs) [Z] MADHAVJI, N.H., and SCHkFER, W.: Prism = methodology + process-oriented environment, IEEE Tram., 1991, SE-17, (11) (see also Proc. 12th Int. Conf. on Software Engineering, Nice, France, March 1990 (IEEE Computer Society Press) pp. 277-288) [24] PERRY, D.E.: Problems of scale and process models. Proc. 4th Int. Software Process Workshop, Moretonhampstead, Devon, UK, May 1988 (see also ACM SIGSOFT, 14, (4), pp. 12C128) [25] SUTTON, S. Jr., HEIMBIGNER, D., and OSTERWEIL. L.J.: Language constructs for managing change in processcentred environments. Proc. Fourth ACM SIGSOFT Symp. on Software Development Environments (see also ACM Softw. Eng. Not., 1990,15, (6),pp. 2&217) [26] HUMPHREY, W.S., and KELLNER, M.1.: Software process modelling: principles of entity Process models. Proc. 11th Int. Conf. on Software Engineering (IEEE Computer Society Press), Pittsburgh, Pensylvania, May 1989,pp. 331-342 [27] WILLIAMS, L.G.: Software process modelling: a behavioural approach. Proc. 10th Int. Conf. on Software Engineeiing, Singapore, April 1988, (IEEE Computer h e t y Press) pp. 174-186 [28] POTTS, C.: A generic model for representing design methods. Proc. 11th Int. Conf. on Software Engineering, Pittsburgh, Pennsylvania, May 1989(IEEE Computer Society Press) pp. 217-220 [El] KAISER, G.E., FEILER, P.H., and POPOVICH, S.S.: Intelligent assistance for software development and maintenance, IEEE Sftw., May 1988,pp. W 9 -ES K N, H., JUNKERMA, G., PEUSCHEL, B., SCMFER, W., and VAGTS, K.J.: A first step towards knowledge-based process modelling in MADHAVJI, N.H., SCH&FER, W., and WEBER, H. (Eds.):Int. Conf. on System Development Environments and Factories, Berlin, May 1989 (Pitman) pp. 4%58 HUFF, K.E., and LESSER, V.R.: A plan-based intelligent assistant that supports the software development process. Proc. ACM SIGSOFT/SIGPLAN Software Engineering Symp. on Practical Software Development Environments (see also ACM SIGPLAN Not., February 1989, 24, (2), pp. 97-106) RADICE, R A , ROTH, N.K., OHARA, A.C. Jr., and CIARFELLA, W.A.: A programming process architecture, IBM Syst.,1985,24, (2), pp. 7%90 KATAYAMA, T.: A hierarchical and functional software process description and its enaction. Proc. 11th Int. Conf. on Software Engineering, Pittsburgh, Pensylvania, May 1989 (JEEE Computer Society Ress)pp. S 3 5 2 [341 MI, P., andSCACCHI, W.: A knowledge-based environment for modeling and simulating software engineering processes, IEEE Trans.,1990,KDE-2, (3), pp. ZSW94 [35] KELLNER, M.I., and ROMBACH, H.D.: Comparisonsof soft242

ware process descriptions. Proc. 6th Int. Software Process Workshop, Hokkaido,Japan, October 1990 [36] ZAVE, P.: Lets put more emphasis on prescriptive methods. Proc. Int. Workshop, Cot0 de Caza, Trabuco Canyon, Caliiomia, August 1986 (see also ACM SIGSOFT Softw. Eng. Not., 11, (4), pp. %100) [37] HEIMBIGNER, D.: ProSaiption versus prescription in processcentred environments. Proc. 6th Int. Software Process Workship, Hokkaido,Japan, October 1990 [38] MADHAVJI, N.H., TOUBACHE, K., and HONG, W.: Towards building reliable process models. Technical Report RoM-91.1, School of Computer Science, McGill University, Montreal, March 1991,p. 28 [39] KELLNER, M.I.: Reprexntation formalisms for software process modeling. Proc. 4th Int. Software Process Workshop, Moretonhampstead, Devon, UK, May 1988 (see also ACM SIGSOFT, 14, (4),pp. 9%%) [ U ] MADHAVJI, N.H.: The Prism model of changes. Proc. 13th Int. Conf. on Software Engineering, Austin, Texas, May 1991 (IEEE Computer Society Press)pp. 1 6 1 7 7 [41] BASILI, V.R., and ROMBACH, H.D.: Tailoring the software process to projmt goals and environments. Proc. 9th Int. C d on Software Engineering, Monterey, Califomia, April o. 1987,(IEEE Computer Society Press) pp. 345357 [42] BOEHM, B., and BELZ, F.: Experiencewith the spiral model as a process model generator. Proc. 5th Int. Workshop on the Software Process, Kennebunkport, Maine, USA, October 1989(ACM Press) [43] BOEHM, B.W.: What we really need are process model geno. erators. Proc. 11th Int. C d on Software Engineering, Pittsburgh, Pennsylvania, May 1989 (IEEE Computer Society Press) p. 397 [ U ] NOTKIN, D.: The relationship between software develop ment environments and the software process. Proc. ACM SIGPLAN/SIGSOFT November 88 Symp. on Software Development Environments, Boston, Massachusetts (see also ACM SICPLAN Not., 1988, 24, (Z), pp. 107-109) [45] PERRY, DE.: Policy and product-directed process instantiation. Proc. 6th Int. Software Process Workshop, Hokkaido, Japan, October 1990 [46] LEHMAN, M.M.: Process models, process programs, programming Support. Proc. 9th Int. C d on Software Engineero. ing, Monterey, California, April 1987, (IEEE Computer Society Press) pp. 14-16 [47] LEHMAN, M.M.: Some reservations on software process programming. Proc. 4th Int. Software Process Workship, Moretonhampstead, Devon, UK, May 1988 (see also ACM srcsom,14, (4),pp. 111-112 (ACMpress)) [48] CURTIS, B., KRASNER, H., SHEN, V., and ISCOE, N.: On building software process models under the lamppost. Proc. 9th Int. Conf. on Software Engineering, Monterey, California, April 1987 (IEEE Computer Society Press) pp. 96-103 [49] HUMPHREY, W.S.: Software process management (Addison-Wesley,Reading, Massachusetts, 1989) [50] BASILI, V.R., and ROMBACH, H.D.: The TAME projtxt: towards improvement oriented software environments,IEEE Trans., 1988, SE-14, (6),pp. 759-773 [51] SELBY, R.W., PORTER, A.A., SCHMIDT, D.C., and BERNEY, J.: Metric-driven analysis and feedback systems for enabling empirically guided software Development. Proc. 13th Int. Conf. on Software Engineering, Austin, Texas, May 1991 WEE Computer society Press) pp. ?8%298

The author is the Acting Director of the School of Computer Science, Mcill University, 3480 University Stnet, Montreal, Quebec, Canada H3A 2A7. The paps was received on 1stJuly 1991.
Software Engineering Journal September 1991

Authorized licensed use limited to: Universidade Estadual Do Sudoeste da Bahia. Downloaded on August 17,2010 at 20:49:20 UTC from IEEE Xplore. Restrictions apply.