the process cycle

8/3/2019 The Process Cycle

1/9

The process cycleby Nazim H. Madhavji

Historically, the process of softwaredevelopment has played a n impo rtantrole in the field of softw are engineering.A num ber of software life-cycle modelshave been developed in the la st thr eedecades. These models, although helpfulis giving general guidance to softwaredevelopers, do not expose myriad detailstha t a re critical in any large softwaredevelopment project. Recentdevelopments, however, have unfoldedmany hidden aspec ts of the softwa reprocess, giving rise t o a new disciplineth at we call software processengineering. This paper depictssoftware process in the context ofsoftware environments, examinesrecen t developments in th e process fieldand proposes th e concept ofprocesscycle, which embodies the scope ofengineering and evolution of softwareprocesses. The paper describes thedetails of the process cycle, includingsuch issues as the role of corporategoals and policies in th e engineering,management, performance andimprove ment of software processes ; hetransformation of the process artifactsthrou gh the process cycle; ole ofhum an beings in this (meta-) process;and comm unications in the cycle.

The great results of the scientific investigation of naturewe are agreed upon knowing, but how much of our studyare we bound to give to the processes by which thoseresults are reached? The results have their visible bearingon hu man life. But all processes, too, all the items of fact,by which those resul ts are reached and e stablish ed, areinteresting.Matthew Arnold [11

1 IntroductionThe software development process (hereafter referred to a ssoffwure process) comprises software engineering activities,including technical and managerial ones, that are carried234

out in the production of softw are. The scope of these adi v-ities includes determination and specification of system andsoftware requirements ; analysis and man ageme nt of risk ;software prototyping ; design; implementation ; verificationand validation; software quality control and assurance;integration of components; docume ntation; manage ment ofsoftware configurations and versions ; manag emen t of data ;evolution of software; project managem ent; software evalu-ation; software contracting; software acquisition; commis-sioning and decommissioning of software etc. For over threedecades now, software process has played a major role inthe field of software engineering. Over this period, the stu dyof software processes has led to the development of variouslife-cycle approaches that may be employed in engineeringsoftware.As early as 1956, Benington [2] proposed the nine-phasestage-wise model for the development of large softwaresystem s. An improvem ent of this model, now widely knownas the waterfall model, was proposed in 1970 by Royce [3 ].This model added two new key concepts to the stage-wisemodel; explicit feedback loops and the initial idea of what isnow termed prototyping. In parallel, other attempts atimproving software process resulted in the transformationalapproach by Balzer et al. [ a ] . Thi s is an automatic para-digm to convert the form al specification of a softw aresystem into a program that satisfies th e specification. Simi-larly, Basili and Turne r [ 7] , in aiming to reduce the productdelivery time of the waterfall model, proposed an evolution-ary model, which advocates early and frequent productdelivery cycles with a focus on small incremental develop-deliver-measure-adjust steps. Subsequen tly, another tr ans-formational approach, the L S T model, was proposed byLehman et al. [8]. This model represents software processas a multi-step sequence. Each step involve s base and targetrepresentations that may also be viewed as specificationand im plementation. Only the first step has no predecessorrepresentation or specification. More recently, in 1986,Boehm presented the spiral model of software development[9 ], a distinguishing feature of which is its risk-drivenapproach. A typical cycle in the spiral proceeds throughiterative sequencing of steps leading to risk analysis andresolution for a give n portion of the sof twar e product. If therisk cannot be fully resolved, the process leads to evolution-ary prototypes, possibly taking simulation into account;otherwise, the basic waterfall type or transformational stepsare followed.Among the benefits of these life-cycle models ar e th atthey help us to become aware of, and gain an increasedunderstanding of, the software process; and to determine

So f tware Engineering Jo u rn a l Sep temb er 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.


2/9

the o rder of global activities involved in the production ofsoftware. These benefits may result in improved productquality, increased effectiveness of methods a nd tools,reduced software development and maintenance costs, andincreased customer and developer satisfaction.A limitation of these models, however, is that they hideimportant process details that are crucial for the success ofsoftware projects. For example, these models are tooabstract to convey the details of0 the process steps required to resolve customer reportedsoftware problems.0 triggering and term inating conditions of an activity.0 the state of a product component before, during, andafter a process step.0 the notational, methodological, operational and othertools to be used in different process steps.0 the inputs and outpu ts of a n activity, and the sourcesand destinations of the da ta.0 the manner in which data flow from one activity toanother.0 the roles played by huma ns in the process.0 the constraints on the process steps.0 how communication among humans is supported.0 where parallel and sequ ential process steps exist.At best, fragments of such process information are infor-mally described in various documents. This situation maynot lead the process to hav e a syn ergistic effect on softwaredevelopment, and evolve with the ch anging needs of thesoftware project. It is then not surprising that, even in thepresence of life-cycle models , the maturit y of softw are pro-cesses in software projects is g enerally disappointingly low[lo, 111, and the management, control and improvement ofthese processes ha s been extremely difficult.However, recent work ha s begun to expose, in a scientificmanner, myriad details underlying the software life-cycle.Detailed process knowledge such as that described above,and which has been largely intuitive, is now being madeexplicit, by describ ing it formally in the form of processmodels or process programs [12]. This has led to tightlyrelated matters such as understanding what we know anddo not know about processes to be able to describe them;creating formalisms suitable for describing and representingprocesses; automating the software process ; and developingmethodologies, tools, and e nvironments for engineering andcontro lling the evolutio n of pro cesses . In fact, all this h as

given rise to a new discipline, which we call here softwareprocess engineering.In this paper, we examine recent developments that maylead to improved software environments. This improvementmay help us in engineering and controlling the evolution ofsoftware processes, as well as in using these to guide soft-ware developm ent. We present our concept of process cycle,which reveals and unifies a number of issues involved inthe engineering, evolution and performance of softw are pro-cesses. For example, among other details, the process cyclepoints out0 the separation of concern amon g project-free, project-specific, and application software-specificgoals and policies.0 how these goals an d policies relate to

0 developm ent of generic process models.0 tailoring, instantiation and en actment of processes.0 perform ance of pro cesse s (i.e. developm ent ofsoftware).

0 the separation of concern among the different roles ofhuman beings (e.g. process engineers, process managersand pro cess performers) in the different parts of the processcycle.the feed-front and feedback links through the proce sscycle, thereby supporting process evolution.0 a v ariety of organisational structures (e.g. from singleuser to distributed organisations) in which the process cyclecan be used.In the following, we overview the evolution of softwareenvironments and we describe the process view of softwareenvironments. We also presen t the concept of process cycle.2 Software environments and softwareprocessSoftware environments, through their evolution in the 1970sand 1980s (characterised by their concern for specificmethods, isolated or integrated tools, programming-in-the-small and programm ing-in-the-large), have h ad two p n n -cipal goals. One is the production of high-quality software,and the other is the production of this so ftware withinbudget and on time, through the use of automated tools.Although there have been improvem ents in software qualityand produc tivity, the scale and increasing complexity of th eproblems being tackled have kept the two stated goals outof our reach. One of the reasons is tha t early environm ents

Levels issues FocusD Software process engineering and evolution ProcessC Softw are processes ProcessB Software product engineering and evolution ProductA Software products Product

methods, tools, people

methods, tools, people

Fig. 1 Levels of abstraction in software environmentsSoftware Engineering Journal Septem ber 1991 235



3/9

did not capture software process significantly, and what-ever process was captured is hard-wired in the tools in theenvironments. Consequently, the environments are notadaptable to varying software development situationsdurin g the software life-cycle.Consider, for example0 an individual tool such as Make 1131, which helps sim-plify recompilation of a set of affected modules after achange.0 an integrated programming environment such as theCornell Program Synthesizer [141, which supports intelli-gent editing and invocation of tools in a given program mingcontext.0 a project support environment such as ISTAR [15],which provides a fram ework for hierarchical processes.They ca pture only small parts of the entire softwareprocess. Besides, changing these buried processes to meetthe evolving needs of software projects, implies too frequenta modification of these sys tem s to make it practical.Recent work in software environments, however, hasyielded a view whereby software process is at the heart ofan environment, guiding and controlling software develop-ment [16, 171. An im portant aspect of such a process-oriented environm ent is that all the elem ents of a softwareproject are explicitly integrated through the medium of soft-ware process: for example, human beings in their varioustechnical and managerial roles; software tools; productparts and their states at various time; in [he process;timing, budgetary, data source and destination, goals, poli-cies, and other constraints acting on the developmentprocess; the development activities and the order in whichthey are to be carried out etc. Thus, the correct and smoothrunning of a n environm ent (and consequently the quality ofthe software produced therein) depends significantly on thequality of the software process in the environment.Such an environment would simplify the evolution ofsoftware process by providing m ethods, tools and engineersto plan, enact and change processes. By tuning processesaccording to the needs of the software project at hand andwithin impending constraints, there would be explicitcontrol on the quality, budget and s chedules of the so ftwaresystem being produced.This view is captured in Fig. 1,which shows four levelsof abstrac tion in a process-oriented software environme nt.Level A represents software products engineered in theenvironme nt. Level B represents methods, tools and humanbeings engaged in the engine ering and evolution of softw areproducts. Level C represents software processes used to inte-grate these methods, tools and human beings during soft-ware production. Finally, level D represents methods, toolsand human beings engaged in the engineering and evolu-tion of software processes fo r use in the environment. Theright-hand column of the Fig ure shows that, at levels A an dB, the focus in the environment is on software products;whereas, at levels C and D, the focus is on software pro-cesses.

In such heterogeneous environments, there are severalpossible views we can envisage: for exam ple, scale of theproblems solved [M I ; types of architectures used [ 19 ];role of hum an beings involved; and t axonom y of the toolsused. In this paper, however, we shall concentrate on thesoftware process view of such environments. More specifi-236

~ -..

cally, we shall focus on level D of Fig. 1,where we canexamine the issues involved in engineering and evolution ofsoftware processes.3 A process view of software environmentsNoting that software process is only a means to a n end, theprocess view enables us to see the way the process is enpi-neered, the way the process evolves and the processes thatare being used to grow software. We can thus visualise acomplete process enginering and evolution environment.However, an important point to note here is that softwareprocess is dynamic, making it difficult to manage. One wayto engineer and control the evolution of such a dyn amicentity is to describ e and define models of software pro-cesses ; customise these models ; instantiate processesensuing from these models; interpret these processes; andimprove them using m onitoring, change management andother appropriate tools.3.1 Process description and definitionA starting point for process improvement is to describe thecurrent process as used in software development. Theprocess model inherent in this description is called adescriptive model [20, 211. Describing a process m eansmaking the software process explicit. This involves model-ling the actual software process, using an appropriateprocess modelling methodology [22, 231. In this modellingeffort, we need to consider the asp ects of the scale of theproce ss model, the fact of ev olution of th e model, and thescale and evolution of the software products bu ilt using theimplied process [a].he central part of such a method-ology that de als with the design of a p rocess model needs toaddress the formalisms which may be used to representprocess models.Several different formalisms have recently been proposedto address these needs. Below, we briefly sketch a represen -tative sam ple of these .0 Process programming languages [16, 251 : formalismsakin to conventional programming languages, supportinglinguistic paradigms such as algorithmic, object-oriented,rule-based, applicative etc.0 Design and analysis paradigm [26]: a visual formal-ism for describing activities, objects, agents, com municationchannels, process states and transitions, based on tech-niques and tools used for software design and analysis.0 Behavioural approach 1271: a formalism for describingthe abstractions of software creation and evolution activ-ities, with a focus on the effects which the activitiesproduce, rather t han the specific procedures used to producethose effects.0 Method-defining schema [281 : an entity-relationshipattribute data model used as a formalism to describe aschem a for representing a fam ily of d esign methods, whichmay be customised for a particular design method andinstantiated for a particular problem.0 Rules [29, 301 : a formalism for modelling the softwareprocess in terms of precondition, activity and postcondi-tions, where the precondition must be true for a particularactivity to be executed, and one of the postcond itionsbecomes true after the activity terminates.0 Plan [311: a formalism for representing processes as

Software Engineer ing Journal September 1991



4/9

hierarchical plans to achieve goals, where high-level goalsare decomposed into subgoals and process actions such astool invo cations are selected to satisfy the subgoals.0 ETVX [32] : a formalism in which a process is com-posedof activities , each with a l ist of entr y criteri a (E), a setof task descriptions (7),a validation procedure (V) nd a listof exit criteria (X).0 Functional approach [33]: where a process isdescribed as a collection of activities, possibly hierarchical,which are characterised by their input and output relation-ship.0 Knowledge-based approach [3]:here a process isviewed a s a set of inter-related tasks performed by anetwork of loosely coupled, intelligent agents, who caninteract and reason about how to best produce products andconsume resources, even when planned processes breakdown.Although all of the above described formalisms attempt torepresent process models, it is as yet too early to know howthey will fare in the development and evolution ofindustrial-scale processes. However, as a step towardsobtaining a deeper understanding of the differentapproaches, a comparison of alternative languages andapproaches for representing software processes based on acommon benchmark problem has recently been carried out[35]. The aspects considered in this comparison includebreadth and depth coverage of the benchmark problem;volume (number of pages) required for the solution; objec-tives in language design; basic representation formalisms;basic components; functionality; behaviour; and languagebase.Whe reas descriptive processes focus on the existing waysof developing software, &fined processes focus on thedesired ways of developing software, thus proceedingtowards process improvement. Defined processes are alsoreferred to as presmj%ive processes [%I, since they pre-scribe the tasks to be completed and the order in which theyare to be completed. Yet another category of processes iscalled jroscrzjtive [371 ; hese processes operate by prohibi-ting inappropriate programmer actions. In a recent paper[%I,e show how corporate goals and policies, aimed atengineering reliable software processes, can result in unre-stricted, prescriptive and proscriptive processes.There are many desirable properties of defined processes.For example0 they have, or should have, reasons supporting theirdefinition [381.0 they convey information readily, e.g. for following theprescribed process m odel.0 they have several perspectives, e.g. functional, txhav-ioural and organisational [391.0 they describe and integrate different levels ofabstractions.0 they have formally defined syntax and sem antics [ 2 5 ] .0 they are reusable, e.g. due to their properties, such asrefinable, tailorable and portable.0 they are comprehensive, i.e., broad and deep.0 they are modular with well defined interfaces, for easeof evolution [NI.These properties may not be present in described processes.

Among the key benefits of a described or defined processare the facts that0and an y differences can be brought to reason.0standards among software developers.0 i t canbereused .0 it can simplify process management, control andautomation.0 it can help identify process measurements points.0 it can become the basis for the next level of pro cessimprovement.0 t may enable effective communication about softwareprocesses.0 it may support co-operative work am ong humanbeings.Ultimately, these benefits, along w ith dom ain-specific know-ledge, can result in higher quality of software because atevery step there is commitment to problem understandingand the m ethod of solving the problem.3.2 Process customisation and instantiation

it can be measured against actual or other processes,it can be used to promote process understanding and

For an y process model to be effective in the specific projectat hand, there is a need to cu stomise the model according tothe project goals [ 23 , 41431 . This may be achieved bycharac terisin g variou s aspects of the project (e.g. produ ctand process reliability, software productivity, resource con-strain ts, and effectiveness of the usage of tools, methodsand languages); setting up project goals; assessing howthese goals are supported by the adopted process model;tailoring the process model to suit project goals; using thetailored process model in the project; and assessing andfine-tuning the model on an on-going basis.The customisation process would be simplified consider-ably if process models were organised hierarchically,leading from generic models at the top of the hierarchy tospecific models at the bottom. For exam ple, at the top levelof gen erality , we envisio n one or more generic models ,perhaps catering for widely different developmentapproaches, e.g. integration of existing com ponents versuscustom development versus evolutionary development.These m odels should contain considerable detail or point toplug-in components for the detail. They should also beaccompanied by guidance for customisation, matching upcomponent (or alternative) choices with project goals etc.We can then form a customised model, by selecting theappropriate base generic model and following the tailoringguidance for that base. This form s a template for the projector perhaps for a class of system s for a given organisation.If not already carried out, a tailored process model needsto be instantiated [44, 51 with project-specific parameters,so that the instantiated process can be performed with ahigh degree of precision. Th is requires planning for instanti-ation [%I, which partly depends on such project-specificmatters as project goals and policies; product structure;organ isatio n of the developm ent team; project schedules;and availability of hum an, tool and other resources.In addition, many aspects of the process being instanti-ated need to be considered at this point. Exa mples of theseinclude information flowing through various process steps;specific conditions for triggering and terminating activities;

Software Engineer ing Journal September 1991 237



5/9

parallelisation and s equentialisation of activities; specificprocess measurement milestones; roles played by humanbeings in the process ; components of the planned softwaresystem and how they relate to various process steps, includ-ing the states taken by these components and process steps;and the interface between the process and the interactingtools. Note also that process instantiation can occur stati-cally (Le. before process enaction) or dynamically (i.e. duringsoftware development).3.3 Process enactmentAn important step beyond instantiating a process model isinterpreting the resultant process description, thereby enact-ing the planned softw are process. The interpretation of aprocess description can be man ual or automated.Manually interpreted process descriptions assist humanbeings in following the implied process m odels during soft-ware development. These processes are likely to be per-missive, leaving humans with the freedom to makecontextual decisions that, for whatever reasons, might nothave been pre-p lanned. Thu s, these descriptions, althoughinformative, do not generally include context-sensitiveextraneous details as they can be difficult to follow, toapply in other circumstances or to change.

Man ual interpretation of pro cess descriptions is thereforeparticularly useful where there is uncertainty or variabilityin the so f twa re process [ M I r when crea tive d eci sion sare involved. Examp les include0 high-level managerial processes, such as staff motiva-tion and g roup co-ord ination, where process ste ps orproduct representation may not be well structured ordefined; where these may be highly contextual or one-of-a-kind; or when they involve human feelings, politics, satis-faction etc.0 low-level technical processes, such as design and reviewtasks, which require creative judgement; are often unclear;or when these are subject to unforeseen, extemal pressure(e.g. customer dem ands and m arket forces).Machine-interpreted process descriptions, on the other hand,can take a more active role than manual ones by carryingout pre-programmed plans. In this automated support forthe software process, what cannot be programmed formachine interpretation is left for humans to perform; thesupport system then either awaits representable results ofthe intermediate huma n process, in order to further interpre tthe process description, or takes its appropriate pro-grammed action.Thus, these programmed descriptions may be suited toestablished and proven software processes: e.g. ones whichdo not have a high degree of un certainty; are not liable tochange frequently; have clearly defined steps and their ord-ering; have clearly defined conditions and exceptions thatcan occur during these steps; have clearly defined represen-tations of produ ct parts, the state s these parts can assumeand the relationships amongst these parts; and are likely tobe required repeatedly. In addition, machine-interpretedprocess descriptions imply the need for automated execu-tion mechanisms and process programming languages inwhich to program software processes. Such languages maywell need to support a mixed variety of paradigms, such a salgorithm, object-oriented, rule-based, graphical etc. [161.238

Another important issue in the enactment of processes isthe degree of flexibility in the software process. Manuallyinterpreted processes are difficult to enforce. Th is is becauseit is not practical to enforce constraints at each minuteprocess step in the software lifecycle. However, the dangerof not b eing able to enforce processes is that m anagem entcan quickly lose control of a softw are project, leading to achaotic situation. Staff education, training and motivationare seen as ways to escape rom this predicament [M I.In contrast, automatically interpreted processes aresimpler to enforce. This is because process constraints arepliable in the form of softw are. How ever, the dan ger ofover-zealous process automation is that it can lead us tobelieve that concrete progress is being made when, in fact,it may be cu rtailing the creativity of software developers[381. Process understanding [& I, and judicious decisions

on what and how to automate in a given environmentalcontext, are seen as ways of escapin g from this predica-ment.3.4 Process impr ovem entOnce the desired process is defined and is in use, here isgenerally continuous pressure to manage and to improve it[40]. Resisting this pressure, or to procrastinate changes,may mean degrading the quality of the housing environ-ment and thus the quality of the products developed within.Some reasons for the pressure to change include0 he software process may be faulty.0 he software process may be missing certain importantsteps, rendering it ineffective.0 the software process may be generic and needs to becustomised in order to obtain specific results.0 he assumptions under which the software process wasengineered are no longer valid.0 competitive pressure (such as imp roving cost, schedule,quality, performance or process maturity in general) is Seenas a way to maintain your relative position in the market-place.0 the dynam ics of geo-politics, huma n beings and tech-nology can have an effect on the softw are process.Avenues that can be pursued for tackling this problem ofchange include introducing process assessment andimprovement programmes [49, 501; increasing the aware-ness of software process amongst the developers; keepingprocess under control ; measuring qualitative and quantitat-ive aspects of software process [513 ; understanding processevolution, describing dependencies among objects, andrecording and using process data to assess the impact ofchange [401 ; and m onitoring the software process.4 The process cycleFig. 2 (hereafter referred to a s the process cycle) is a conciseand integrated view of eng ineering, managem ent, per-formance and imp rovement of softw are processes. Theprocess cycle, bounded by the three sectors A, B an d C,defines the scope of the total set of process step s necessaryfor the development and evolution of softw are processes. Itthus represents all the key issues discussed above.In addition, the cycle defines the key roles played byhuma n beings, categories of tools used, goals and policies




6/9

governing the processes, and inter-relationships and feed-back am ong the different roles. The feed-front and feedbacklink s a a m he th ree sectors comp lete a cycle of pro cessengineering, management, performance and improvement ;hence, the nam e processcy&.4.1

In sector A, process engineers design, construct and improvegeneric process models accord ing to project-free goals andpolicies. These goals and policies concern the process ofdeveloping process models (i.e. how the process modellersdo their job) and the contents of process models (i.e. whatjob the process m odellers do). Here, project-free implies thatthe goals and policies should be applicable to classes ofprocess models and classes of application software pro-ducts, rather than a specific process model and a specificapplication software product.For example, for a class of risky process models, thegoals and policies might strongly suggest that processmodels are designed and simulated, and insist that humaninterpretation is a central part of process enaction. Simi-larly, for a class of application software characterised a smission critical, the project-free goals and policies mightsuggest m odelling of certain p rocess steps to encourage theuse of formal methods for software development, and strictdesign and code review procedures.Sector A also shows the provision of process engineeringand evolution tools which process engineers may use toproduce and improve process descriptions. Because th egoals and policies in this se ctor are project-free, the engi-neered pro cess descriptions simplify the problem of p rocessevolution and reuse across software projects. In addition,these process descriptions play an important role in settingprocess standards in an organisation.4 .2 Sector B: managing software processesThe descriptions developed in sector A are then adoptedand customised by process managers (depicted in sector Bof the proce ss cycle) for use in specific software projects.Here, process managers are subjected to project-specificgoals and policies that influence the customisation process.For example, these goals and policies might impose particu-lar approval procedures for resource allocation in the soft-ware project, specific product and process inspectioncheckpoints etc. Similarly, for the prod uction of a p articularsecure software system, such goals and policies mightrequire some predetermined levels of skill in the usage ofcertain tools that may not have been considered as a stan-dard for the development of all secure system s. A processcustomised to meet these goals and policies thus needs tocapture appropriate steps to allow for dynamic resourceallocation, inspection checkpoints and staff training pro-grammes.Customised process descriptions need to be instantiatedwith project-specific parameters (e.g. assigning a particularperson to a specific role), according to the project-specificgoals and policies, and the current s tates of the productparts and the developing team. These instantiated descrip-tions are then released for interpretation, thereby enactingthe implied software process.In general, instantiated process descriptions are enactedto integrate with related and previously activated processesSoftware Engineer ing Journal September 1991

Sector A : engineering process mo dels

in the software project. The process management team thusneeds to have the ability to identify trouble-spots (i.e. cor-rupted process parts) in the process; dyna mically isolate thecorrupted parts without freezing the rest of the process; fixthe faulty parts, perhaps including dynamic restructuring,recustomising and re-instantiating the process parts; ndeventually embed the modified process parts in the totalprocess.Problems with the process may not be due only to theprocess steps themselves, but also to the stat e of theproduct; various changes in project-specific policies, goals,schedules, staff, organisation etc. Many of these changes ar enot predictable, and th us pose a serious threat to thesmoo th functioning of the process.There is thus a need for appropriate process managementand improvement tools to aid this managem ent task. Spe-cific tools might focus on process monitoring, debugging,simulating, assessing, measuring, visualising, configuring,versioning etc. Although there may be similarities betweenthe tools used in sector B and those used in sector A, themajor difference is that in the latter sector the tools operateon genenc descriptions within a simulated environment;whereas, in the form er sector, the tools generally operate onspecific descriptions within both simulated and actualenvironments.4.3 Sector C: performing software processesIn sector C, process performers (i.e. software developers)carry out software process, in order to build and improvethe application software. This act is shown in the processcycle by a thin, dow nward , broken arrow from the enactedsoftware process to the process performing tools. Duringsoftware developm ent, the process perform ers are subjectedto application software-specific goals and policies. Forexample, there are usually specific software requirementsthat hav e to be satisfied in the design of a system .The process cycle also shows the need for process per-forming tools that these performers might use in the devel-opment process. Although there may be similarities in thetools used here to those used in sectors A and B, the funda-mental difference is that these tools operate on applicationsoftware parts; whereas those in sectors A and B operate onprocess parts.4.4 Feedback and imfwovementsAn important aspect of the process cycle is that there isfeedback about the process being used in sector C. Feedbackgenerated by process performers is passed on to project-specific process managers. This communication is shownby a thick broken arrow and a solid arrow from the runningprocess to the process management tools. The feedbackmight include the smoothness with which the assignedtasks are being carried out; any bottlenecks in the develop-ment process; negative effects due to certain timing ordevelopment constraints ; the need for additional processstep s or removal of su perfluous ones etc. Process manage-ment tools would also provide feedback, by gathering somequalitative and quantitative da ta about the active process.The feedback received in sector B can be used in twoimportant ways by process managers. First, this informa-tion can be used to fine-tune and make m ajor improvementsto the project-specific processes. The beneficiaries of these

239



7/9

Fig. 2 The process cycleimprovem ents are process performers in sector C. Secondly,the feedback can be used by process managers to make gen-eralisations about po ssible improvements in project-free,orgeneric, software processes. The beneficiaries of these gen-eralisations are process engineers in sector A, who receivethe feedback to make improvem ents to their process models.Thi s cycle of building generic process models, tailoring andenacting them, communicating feedback for improvementsfrom process performers to managers, and from managersto engineers, is continuous 1401.Finally, note that the feedback generated, or received, atany sector does not necessarily stay within the processcycle. In fact, it is important tha t, by some osmotic action atthe outer ring of the cycle, such feedback is conveyed to thecorporate levels for improvem ents to goals and policies.4.5 Roles and distribution of responsibilitiesThe role structures within process engineering, processmanaging and process performing teams are implicit in theprocess cycle. For example, the process engineering teammight be composed of a think tank working on the th eeretical aspects of the softw are process, e.g. process under-standing, formalism s, semantics, idealised or unconstrainedimprovements etc. ; managers concentrating on the impactof software process goals and policies on process m odels;and designers and implementors actually building, simulat-ing and improving idealised process models, and analysingprocess feedback. Similarly, process managing and processperforming teams may be approp riately organised.

Another important point a bout the process cycle is that itpermits d istribution of process-related responsibilitiesacross sectors A, B an d C. At one extreme is the so-calledI-design-you-adapt cenario. For instance, the process engi-neer builds a generic process model, and the processmanag er adopts and customises it for a specific project; the240

manager instantiates a customised process model and theprocess performer cames it out. This scenario is most likelyto take place in large organisations and institutions, oftendistributed, where a person is employed to play a specificrole.At the other extreme is the so-called do-it-yourself sce-nario. For instance, a module tester might build a genericprocess model to ensure that each test case is considered inthe testing process; test results are tied to the appropriatetest case; bugs are logged for further analysis; and a self-reminder of the analysis task is sent. The same tester mightthen custom ise this generic process model to allow for localsystem con figuration; for example, steps might be added toobtain the test cases, save test results along with the testcases, perform autom atic logging of the bu gs etc. Followingcustomisation, the tester might instantiate the processdescription with specific tools and their options, requireddirectory and file names, and other technical particularities.Once this process is in place, it might be enacted so as toassist in their task of testing modules. This scenario is mostlikely to take place in individual situations (technical ormanagerial) in a software project, where one person mayplay several roles, albeit at different moments.5 SummaryUnderstanding software processes is critically important forproducing high-quality software within budget and on time.Traditional softw are life-cycle paradigms give only generalguidance on the development and evolution of software.Fundamentally, beyond these life-cycle paradigms, w e needto unfold many hidden lower level process details so as topresent an improved understanding of the developmentprocess. These process details, like conventional software,need to be supported by methods, tools and environments inorder to have a better grasp on the evolution of software

Software Engineering Journal September 1991



8/9

systems, as well as the development process itself. Thesupport for software processes includes mechanisms formaking processes explicit and reusing them; tailoring andinstantiating generic processes to suit project-specific needs ;enacting processes; measuring and characterising processdetails; and controlling process evolution. Together, processunderstanding and process support have given rise to a newdiscipline, which we call software process engineering. Th isdiscipline has far-reaching implications, both in academiaand the software industry.It is, however, interesting to note that both process under-standing and the supporting technology are invariablyintertwined. For instance, without adequate process under-stand ing (e.g. process dynamics), some aspects of the sup-porting technology cannot be effective (e.g. the tools neededto change processes). Similarly, without appropriate sup-porting technology (e.g. process-m etric tools), some aspectsof the process a re difficult to understand (e.g. those basedon precise or quantitative measures of the behaviouralaspects of the softw are process)*. It would then appear that,over the next decade, process understanding and processsupport would progress hand-in-hand with one proddingthe other.In this paper, we have identified four key levels ofabstraction in a p rocess-oriented software environm ent (seeFig. 1):

A software products.B software product engineering and evolution facili-ties.C softwareprocess.D software process engineering and evolution facili-ties.These are aimed at supporting the evolution of softwareproducts, as well a s software processes.In addition, we have proposed the concept of processcycle (see Fig. 2), which reveals and unifies a number ofissues involved in the engineering, evolution and per-formance of software processes. The cycle separates theconcem for engineering generic process models, managingproject-specificprocesses and performing enacted processes.The implementation of this separation of concem in anestablishment requires careful organisational and environ-mental planning, and discipline amo ngst the engagedprocess developers (from the corporate to the technicalprocess levels). Only when we have attained a high degreeof personal, group and organisational discipline in theprocess field are we likely to see sig nificant improvement insoftware quality. As yet, we have a long and winding roadahead of us.6 AcknowledgementsThe author would like to thank Vic Basili, Mark Dowson,Karen H uff, Gail Kaiser, Tak uya Katayam a, Marc Kellner,Nashira (Chou-ch)Keshavjee, John M cDermid, Haus i Muller,David Notkin, Lee Osterweil, Martyn O dd , Dewayne Perry,Bill Riddle, Dieter Rom bach, Walt S cacchi, Wilhelm Schafer,* This intertwining is visualised here as a network of interdepen-dent sub-components of process understand ing and process tech-nology. This view is considerably more general than Osterweilsview of research deadlock between the need for a process prog-ramming language and the need to write process programs [171.Software Engineering Journal Septembe r 1991

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

[ I ] ARNOLD, M.: Literature and science 1865in CULLER, D.A.(Ed.): Poetry and criticism of Matthew Arnold (HoughtonMifflin, Boston, 1961)[2] BENINGTON, H.D.: Production of large computer prog-rams, Proc. ONR Symp. on Advanced ProgrammingMethods for Digital Computers, June 1956, pp. 1527 (seealso Ann. Hist. Comput., October 1983,pp. 35CL361 and Proc.9th Int. Conf. on Software Engineering, 1987 (IEEE Com-puter Society Press) pp. -310)[3] ROYCE, W.W.: Managing the development of large soft-ware systems. Proc. IEEE Wescon, August 1970, pp. 1-9(seealso Proc.9th Int. Conf. on Software Engineering, 1987(IEEE Computer Society Press) pp. 3%338)[4] BALZER, R. : A global view of automatic program-ming.Third Joint Int. Conf. on Artificial Intelligence, Stan-ford University, August 1973, pp. 494-49 9[51 BALZER, R.: Transform ational implementation: anexample, EEE Tram. , 1981, SE-7 , (l), p . S 1 4[6] BALZER, R., CHEATHAM, T.E., and GREEN, C.: Softwaretechnology in the 1990s: using a new paradigm, IEEE Com-puter, November 1983, pp. 3 M[7 ] BASILI, V.R., and T URNER, AJ.: Iterative enhancement: apractical 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 m ethodology,AC M Softw.Eng. Not., 1984,9, (2), pp. 3%53[9 ] BOEHM. B.W.: A spira l model of software developm ent andenhancement, IEEE Computer, May 1988, pp. 61-72 (seealso ACMSoftw. Eng. Not., Aug ust 1986, pp. 14-24)101 HUMPHREY, W.S., KITSON, D.H., and U S E , T.C.: Thestate of software engineering practice: a preliminary report.Proc. 11th Int. Conf. on Software Engineering, Pittsburgh,Pennsylvania, May 1989, pp. 277-288 (IEEE ComputerSociety Press)

111 HUMPHREY, W.S., KITSON, D.H., and GALE, J.: A com-parison of U S . and Japanese software process maturity.Proc. 3th Int. Conf. on Software Engineering, Austin, Te xas,May 1991, pp. 3 8-4 9 (IEEE Computer Society Press)[121 TULLY, C. (Ed.): Represen ting and enactin g the softwareprocess. Proc. 4th Int. Software Process Workshop,Moretonhampstead, Devon, UK, May 1988 (see also AC MSIGSOFT, 14, (4) (ACM Press))[13] FELDMAN,S.I.: MAKE a program for maintaining com-puter programs, Softw. Pract. Ex)., 1979,9, pp. 2252 65[14] TEITELBAUM, T., and REPS, T.: The Comell programsynthesizer: a syntax directed programming environment,Commun.ACM, 1981 ,24, (9), pp. 56.3573[15] DOWSON, M.: ISTAR ~ an integrated project supportenvironment,IEEE Softw., November 1987, pp. 6 1 5[16] OSTERWEIL, L.: Software processes are software too.Proc. th Int. Conf. on Software E ngineering, M onterey, Cali-fomia, 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., andYOUNG, M.: Foundations for the Arcadia environmentarchitecture.hoc. ACM SIGPLANjSIGSOFTSymp. on Soft-ware 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 devel-opment environments, IEEE Tram. , 1991, SE-17. (3), pp.

241



9/9

ZKk295 (see also Proc. lot h Int. Conf.on Software Engineer-ing, Singapore, April 1988 (IEEE Computer society Press)PP.M)[1 9] PENEDO, M.H., a nd RIDDLE, W.E.: Guest eidtors In tr eduction: software engineering environment architectures,

[20] DOWSON, M.: The structure of the software process,AC MSIGSOFT S f t w . E%. Not., 1986,11, (4), pp. 6 4[21 ] WILEDEN, J.C., an d DOWSON, M. (Ed.): The softwareprocess and software environements. Proc. nt. Workshop,Coto de Caza, Trabuco C anyon, Califomia, August 1986 (seealso ACM SIGSOFT Softw. Eng. Not., 11, (4), and panel dis-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 programmingto the spiral model. Proc. 4th Int. Software Process Work-shop, Moretonhampstead, Devon, UK, May 1988 (see alsoACMSIGSOFT, 14, (4), pp. 4&56 (ACMPress))[Z ] MADHAVJI, N.H., an d SCHkFER , W.: P rism = metho-dology + process-oriented environment, IEEE Tram., 1991,SE-17, (11) (see also Proc. 12th Int. Conf. on SoftwareEngineering, Nice, France, March 1990 (IEEE ComputerSociety 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 AC M SIGSOFT, 14, (4), pp.12C128)

[25] SUTTON, S. Jr., HEIMBIGNER, D., and OSTERWEIL. L.J.:Language constructs for managing change in process-centred environments. Proc. Fourth ACM SIGSOFT Symp.on Software Development Environments (see also ACMSoftw.Eng.Not., 199 0,15 , (6), pp. 2&217)[2 6] HUMPHREY, W.S., and KELLNER, M.1.: So ftware processmodelling: principles of entity Process models. Proc. 11thInt. Conf. on Software Engineering (IEEE C omputer SocietyPress ), Pittsbu rgh, Pen sylvania, M ay 1989, pp. 331-342[2 7] WILLIAMS, L.G.: Software process modelling: a behav-ioural approach. Proc. 10th Int. Conf. on Software Engineei-ing, Singapore, April 1988, (IEEE Computer h e t y Press)pp. 174-186[28] POTTS, C.: A generic model for representing designmethods. Proc. 11th Int. Conf. on Software Engineering,Pittsburg h, Pennsylvania, May 1989 (IEEE Computer SocietyPress)pp. 217-220[El] KAISER, G.E., FEILER, P.H., and POPOVICH, S.S.: Intelli-

IEEE T Y U ~ S . ,988, SE- 14, (6), pp.68M%

gent assistance for software development and maintenance,IEEE Sftw., May 1988, pp. W 9-KENS H., JUNKERMA, G., PEUSCHEL, B.,SCMFER, W., and VAGTS, K.J.: A first step towardsknowledge-based process modelling in MADHAVJI, N.H.,SCH&FER, W., and WEBER, H. (Eds.): nt. Conf. on SystemDevelopment Environments and Factories, Berlin, May 1989(Pitman ) pp. 4%58HUFF, K.E., and LESSER, V.R.: A plan-based intelligentassistant that supports the software development process.Proc. ACM SIGSOFT/SIGPLAN Software E ngineeringSymp. on Practical S oftware Development Environments (seealso ACM SIGPLAN Not., February 1989, 24, (2), pp.97-106)RADICE, R A , ROTH, N.K., OHARA, A.C. Jr., and CIAR-FELLA, W.A.: A programming process architecture, IBMSyst.,1985,24, (2), pp. 7%90KATAYAMA, T.: A hierarchical and functional softwareprocess description and its enaction. Proc. 11th Int. Conf. onSoftware Engineering, Pittsburgh, Pensylvania, May 1989(JEEE Computer Society Ress)pp. S 3 5 2[341 MI, P., andSCACCHI, W.: A knowledge-based environmentfor modeling and simulating software engineering processes,IEEE Trans.,1990,KDE-2, (3), pp. ZSW94[35] KELLNER,M.I., and ROMBACH, H.D.: Comparisonsof soft-

242

ware process descriptions. Proc. 6th Int. Software ProcessWorkshop, Hokkaido,Japan, October 1990[36 ] ZAVE, P.: Lets put m ore emphasis on prescriptivemethods. Proc. Int. Workshop, Cot0 de Caza, TrabucoCanyon, Caliiomia, August 1986 (see also AC M SIGSOFTSoftw. Eng. Not., 11, (4), pp. %100)[37 ] HEIMBIGNER, D.: ProS aiption v ersu s prescription inprocesscentred environments. Proc. 6th Int. SoftwareProcess Workship, Hokkaido,Japan, O ctober 1990

[38] MADHAVJI, N.H., TOUBACHE, K., and HONG, W.:Towards building reliable process models. Technical ReportRoM -91.1, School of Com puter Science, McGill University,Montreal, March 1991, p. 28[39] KELLNER, M.I.: Reprex ntation formalisms for softwareprocess modeling. Proc.4th Int. Software Process Workshop,Moretonhampstead, Devon, UK, May 1988 (see also ACMSIGSOFT, 14, (4), pp. 9%%)[ U ] MADHAVJI,N.H.: The Prism model of changes. Proc.13thInt. Conf. on Software Engineering, Austin, Texa s, May 1991(IEEE Computer SocietyPress)pp. 1 6 1 7 7[4 1] BASILI, V.R., and ROMBACH, H.D.: Tailoring the softwareprocess to projmt goals and environments. Proc. 9th Int.Cod. n Software Engineering, Monterey, Califomia, April1987, (IEEE Computer Society Press) pp. 3 45 35 7[42 ] BOEHM, B., and BELZ, F.: Experiencewith the spir al modela s a process model generator. Proc. 5th Int. Workshop onthe Software Process, Kennebunkport, Maine, USA, October1989 (ACMPress)[43 ] BOEHM, B.W.: W hat we really need are process model gen-erators. Proc. 11th Int. Cod. n Software Engineering, Pitts-burgh, Pennsylvania, May 1989 (IEEE Computer SocietyPress)p. 397[ U ] NOTKIN, D.: The relationship between software development environments and the software process. Proc. ACMSIGPLAN/SIGSOFT November 88 Symp. on SoftwareDevelopment Environments, Boston, M assachusetts (see alsoACM SICPLAN Not., 1988,24, (Z), pp. 107-109)[45] PERRY, DE.: Policy and product-directed process instanti-ation.Proc. 6th Int. Software Process Workshop, Hokkaido,Japan, October 1990[4 6] LEHM AN, M.M.: Pro cess models, process programs, prog-ramming Support. Proc. 9th Int.Cod. n Software Engineer-ing, M onterey, California, April 1987, (IEEE ComputerSociety Press) pp. 14-16[4 7] LEHMAN, M.M.: Some reservations on software processprogramming. Proc. 4th Int. Software Process Workship,Moretonhampstead, Devon, UK, May 1988 (see also ACM

[4 8] CURTIS, B., KRASNER, H., SHEN, V., and ISCOE, N.: Onbuilding software process models under the lamppost. Proc.9t h Int. Conf. on Software E ngineering, Monterey, California,April 1987 (IEEE Computer Society Press)pp. 96-103[4 9] HUMPHREY, W.S.: Software process management(Addison-Wesley,Reading, Massachusetts, 1989)[ 5 0 ] BASILI, V.R., and ROMBACH, H.D.: The TAME projtxt:towards improvement oriented software environments,IEEETrans., 1988,SE-14, (6), pp. 759-773[5 1] SELBY, R.W., PORTER, A.A., SCHMIDT, D.C., andBERNEY, J.: Metric-driven analysis and feedback systemsfor enabling empirically guided software Development. Proc.13th Int. Conf. on SoftwareEngineering,Austin,Texas, May1991 W E E Computer society Press) pp. ?8%298

srcsom,14, (4), pp. 111-112 (ACM press))

Th e author is the A cting Director of the School of ComputerScience, Mcill University, 3480 University Stnet, Montreal,Quebec, Canada H3A 2A7.Th e paps was received on 1s t July 1991.


the process cycle

Documents