dynamic evolution of software processes to evolve software systems during their development

SOFTWARE PROCESS IMPROVEMENT AND PRACTICESoftw. Process Improve. Pract. 2004; 9: 229–238Published online in Wiley InterScience (www.interscience.wiley.com). DOI: 10.1002/spip.208

Dynamic Evolution ofSoftware Processes toEvolve Software Systemsduring their Development‡

Research SectionSami Beydeda1*,† and Volker Gruhn2

1 Bundesamt fur Finanzen, Abteilung Informationsverarbeitung,Friedhofstr. 1, 53225 Bonn, Germany2 University of Leipzig, Chair of Applied Telematics/e-Business,Klostergasse 3, 04109 Leipzig, Germany

A software system, once deployed into its target environment, might need to be modified forvarious reasons. The reasons might be specific to that software system, such as failures, or,more general, such as changes in the environment in which the software system is embedded.Depending on the reason, a modification might obviously not only be restricted to a particularsoftware system. It might also concern other existing software systems and particularly alsosoftware systems under development.

The modification of a software system under development is merely a problem of modifyingits development process, also called software process. Such modifications generally cannotbe automatically carried out by autonomous process support systems due to the complexityinherent in software processes and in the necessary modifications. It usually needs to be guidedby a human process manager. A process support system can, however, offer the human processmanager certain services to assist in modifying a software process. One of these services is thatof decision support.

This article describes a decision support system developed in the ESPRIT project ProcessInstance Evolution (PIE). One of the features of the decision support system is an extendabledatabase of decision models, each of which is capable of generating specific information to assistthe process manager. One of these models is that of risk analysis. Risk analysis, as used in thiscontext, encompasses assessment of the impact of a possible modification on certain softwareprocess attributes before actually changing a software process. Copyright 2004 John Wiley &Sons, Ltd.

KEY WORDS: process evolution; decision support; risk analysis

∗ Correspondence to: Sami Beydeda, Bundesamt fur Finanzen, Abteilung Informationsverarbeitung, Friedhofstr. 1, 53225 Bonn,Germany†E-mail: [email protected]‡ The chair of Applied Telematics/e-Business is endowed by Deutsche Telekom AG.

Copyright 2004 John Wiley & Sons, Ltd.

Research Section S. Beydeda and V.Gruhn

1. INTRODUCTION

One of the objectives of software engineeringresearch is to obtain means of decreasing timeto market of software products. A motivation ofthis type of research is that nowadays time tomarket is one of the main competition factors in thesoftware industry. A software company intendingto differentiate from its competitors can achievethis by such means. Another motivation to decreasetime to market, or, more generally, to decrease thethroughput time of a software process is a decreaseof process risk. The development of a softwaresystem is generally based on certain assumptionsconcerning the customers, competitors, marketsetc. Many of these assumptions have a specificreference date in the future, particularly at the end ofdevelopment, and can therefore be subject of interimchange. Even though the likelihood that such anassumption changes during development generallydecreases with the throughput time of the softwareprocess, it cannot be totally removed. We thusrequire the means to tackle changes in assumptions.Such a change in the assumptions of a softwareprocess can also impact the software system asthe product to be developed. For instance, existingsoftware systems are often changed in response toaltered customers’ quality requirements, and thisin turn can require a software company to changeaccordingly software systems under development.

The modification of a software system underdevelopment is merely a problem of modifying itsdevelopment process. Such modifications generallycannot be automatically carried out by autonomousprocess support systems due to the complexityinherent in software processes and in the neces-sary modifications. A process support system can,however, offer a human process manager certainservices to assist in modifying a software process.

Basic services for modifying software processesinclude the following (Alloui et al. 2000):

1. Monitoring support. The software process has tobe monitored together with its environment inorder to detect internal and external problems.A software process-internal problem may bethat of staff reduction, while a software process-external problem may be that of changes incustomers’ quality requirements.

2. Decision support. After identifying the need toevolve a software process, solutions eliminating

the problems detected have to be generated. Forinstance, in the case of the software process-external reason given above, a solution couldbe to insert activities in the software processimproving test data generation. Furthermore,these solutions have to be compared witheach other according to a specific criterion inorder to select the most promising alternative.A criterion suitable for this purpose is, forinstance, risk minimization.

3. Change support. After having selected a par-ticular alternative, it has to be implemented,requiring actual change of the software process.Generally, the modification necessary is decom-posed into single atomic modifications, and thesoftware process is modified according to them.

4. Evolution strategy support. The single activities asa whole necessary to modify a software processcan be considered as a process, the changemeta-process. A process support system cansupport the change meta-process by offeringan evolution strategy support.

The objective of this article is twofold. We haveseen that in some cases software has to be evolvedeven during its development and that this can beaddressed by evolving its development process.Firstly, this article technically describes a concretesystem for software process evolution with empha-sis on decision support aspects. This is covered inSection 2. Secondly, the article conceptually con-siders decision support aspects by explaining atechnique that can be used to assess the risk inherentin a possible modification of the development pro-cess. This is covered in Section 3. Section 4 showsthe application of the risk assessment technique byexample and Section 5 finishes the article with ourconclusions.

2. GENERIC DECISION SUPPORT

The approach of model-based decision supportwas developed during a project, Process InstanceEvolution (PIE) (Cunin 2000, Cunin et al. 2001), anESPRIT Framework IV LTR project supported bythe European Community. The main part of theproject started in February 1999 and finished in July2001. One of the objectives of the PIE project was thedevelopment of a system supporting the evolutionof human-intensive, long-living, and distributedprocesses.

Copyright 2004 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2004; 9: 229–238

230

Research Section Dynamic Evolution of Software Process

PIE applications

PIE services

PIE infrastructure

Modeling Evolutionstrategy

Decision& change

Monitoring

Automotive industry Insurance

Execution

Figure 1. Overall architecture of the PIE system (Dami et al. 2001)

Decision support framework

Model1 Model2

Modeln

ModelModel

Modelk

...

Decision modeldatabase

Figure 2. Conceptual architecture of the decision support component

2.1. Overall Architecture of the PIE System

The system developed in the PIE project consists ofthree levels, as shown in Figure 1 (Dami et al. 2001):

1. The top level consists of the application sup-ported by the system. Besides software develop-ment, we, in particular, considered applicationsfrom the insurance and automotive industry.

2. The middle level, called service layer, includesthe services provided by the system for sup-porting the application at the top level. Theservices mainly consist of Monitoring Support,Decision Support, Change Support and EvolutionStrategy Support. Furthermore, this level alsoincludes services for modeling and execution(enactment) of processes.

3. The bottom level, called infrastructure layer, rep-resents the PIE infrastructure providing generalservices required by components at the ser-vice layer. The infrastructure layer particularlyaddresses process interoperability and mobil-ity issues, often encountered in federations ofheterogeneous and distributed components.

2.2. Decision Support Component

The Decision Support component is designedaccording to the client/server paradigm. In thefollowing, we explain the conceptual and technicalarchitecture of the Decision Support server andshow an example of a Decision Support client.

2.2.1. Decision Support ServerThe underlying concept of model-based decisionsupport is to have a generic decision supportframework that includes an extendable database ofdecision models. Examples of such decision modelsare those for generating alternatives or models forrisk analysis. As new requirements can arise duringthe use of such decision support tools, a featureof model-based decision support is its extensibility;new models can be added to the database if needed.

Conceptually, the Decision Support server main-tains a database of models that includes the algo-rithm explained later as well as other algorithmsfor decision and risk analysis, as shown in Figure 2.These models can be loaded into the Decision Sup-port server during runtime if needed and can be


231


Com

mun

icat

ion

laye

r

Persistent store layer

GU

I lay

er

Model layer

Kernel

Communication Data flow

HTTP-Server

Middle-ware

Figure 3. Technical architecture of the decision support server

executed with the necessary data. This data, spec-ified by the corresponding model, can be accessedvia the PIE Infrastructure.

The functionality of the Decision Support com-ponent strongly depends on the models availablethrough its model database. Existing models notinvolved in a decision can be exchanged by newerversions and new models can be registered withoutrecompiling or stopping the whole component.

Figure 3 shows the technical architecture of theDecision Support server consisting of five layers,namely, Communication layer, Persistent store layer,Graphical user interface layer, Model layer and Kernel:

• The Communication layer provides the necessarymeans for the communication of the DecisionSupport server to clients as well as to other PIEcomponents. It implements interfaces providingdifferent protocols. Clients can connect to theserver through RMI either as a Java appletor a stand-alone Java application. The servercomputes the data related to the current queryand sends a response to the client, whichdisplays the data

• The Graphical user interface layer contains graphi-cal elements to allow the models creating appro-priate graphical user interfaces to display data.

• The Model layer implements the conceptualdatabase shown in Figure 2. As the models arerepresented by Java classes.

• The Persistent store layer provides the necessaryservices for storing data obtained by other PIEcomponents or computed by decisions models.The reason for storing the data computed bymodels is to facilitate learning. Even thoughthe models available do not employ learningtechniques yet, the project manager can use thisdata as experience for future decisions.

• The Kernel mainly executes the models availablevia the Model layer. It gathers the necessarydata using services of other PIE componentsand invokes the corresponding model with therequired data.

2.2.2. Decision Support ClientAs mentioned before, services provided by theDecision Support server can be accessed by varioustypes of clients. Figure 4 shows the user interfaceof a client implemented as a Java applet. Thisfigure shows a client used for decision making insoftware development. In this particular scenario,two alternatives have been analyzed with respect tothroughput time. Two alternatives were available,namely, the alternatives Planning Amendment andRecovery Process. A probability distribution wascomputed for each of them and was showngraphically by the client. Furthermore, the clientdetermined that alternative Recovery Process entailsless risk with respect to throughput time andsuggested selecting it according to the Min Riskcriterion.


232


Figure 4. Decision support client implemented as Java applet

3. DECISION MODEL FOR RISK ANALYSIS

The decision model developed for risk analysiscan be used for comparing possible alternativeswith respect to the risk of two process parameters,throughput time and total costs. Throughput timerefers to the time needed to finish a process. Totalcosts refer to the costs incurred by the processuntil its completion. The main concept of our riskanalysis is to determine probability distributionsof these parameters for the various alternativesbased on their process models. These probabilitydistributions can be used to compute simplerisk measures such as the expected value and thevariance (Allen 1978) of the distribution, or the morecomplex value-at-risk measure (Jorion 1997) usedin finance. Having computed such risk measures,the utility (Pratt 1964) of each alternative can bedetermined, taking into account the preferences ofthe process manager. A useful side effect of thealgorithm is information indicating opportunities

for process optimization and also the likelihood ofsuch undesirable situations as a deadlock.

3.1. Related Work

Almost every decision problem is associated withrisk due to the uncertainty of the real world. Despiteits importance, there is no standard definition ofthe term risk and its interpretation depends onthe context (Fishburn 1984, Luce 1980, Jorion 1997).In this paper, we interpret the notion of risk inaccordance with Moskowitz and Bunn (Moskowitzand Bunn 1987) as the likelihood of an unfavorableoutcome.

Researchers have long considered risk analy-sis and decision problems under conditions ofuncertainty. Bernoulli and Bayes developed a for-mal framework which was further developed byRamsey (Ramsey 1931), von Neumann, and Mor-genstern (von Neumann and Morgenstern 1947),Arrow (Arrow 1963) and others. The method usedin this paper is based on this formal framework.


233


Unfortunately, existing process support systemsdo not sufficiently check process models beforeenacting. This means that after its enactment, aprocess can enter a deadlock state, causing seriousproblems van der Aalst 1998, Hofstede et al. 1998.The situation becomes even worse after changinga process. Although process changes can be asso-ciated with unpredictable side effects and risks,there are few publications addressing this prob-lem. Tarumi, Matsuyama, and Kambayashi (Tarumiet al. 1999) have proposed a cycle of Business ProcessTactics/Business Process Reengineering/BusinessProcess Simulation with emphasis on simulation.In their approach, simulation is used to evaluateprocesses and agents before introducing them tothe real work place.

3.2. Representation of a Process

The decision model for analyzing a process requiresa process model that does not necessarily needto include information concerning data flow. Thealgorithm rather requires as input a process modelthat only defines the control flow of the processand additional information describing its currentstate. Therefore, the graphical representation of theprocess model used is quite simple, consisting ofrectangles and edges between them. Nodes in thegraph represent activities of the process. Each nodepossesses two attributes. One of which representsthe costs of the resources required for the executionof the activity. The other represents the time neededto finish the activity under consideration.

Control flow within the process is representedby edges connecting the nodes. Since an activitycan have different outcomes and the subsequentactivity may depend on the outcome, a node canhave more than one outgoing control flow edge. Inthese cases, each outgoing edge is augmented witha probability to indicate the likelihood of takinga particular branch. Obviously, the sum of theprobabilities attached to the outgoing edges of oneactivity has to be exactly 1, and, in the case of onlyone succeeding activity, the probability attached tothe edge corresponds to 1. In our approach, thestate of a process is represented by a set consistingof the currently executed activities. Activities thatare not contained in this set are not executed andare considered to be idle. In addition to the twoparameters, time and costs of an activity, the setof currently executed activities also maintains two

other parameters for each activity. One of theseparameters is the probability of entering the activityand the other the costs incurred by the processenactment until entering the activity. Thus, thecost and the probability parameters attached to anexit node in the set of executed activities give thecorresponding values for finishing the process atthat particular node.

3.3. Process Time Schedule

The technique proposed is based on an algorithm togather process time schedule information. A processinstance time schedule is a set consisting of itemsthat indicate the end of process enactment. Theitems have attributes for total costs and for theprobability of finishing at the corresponding time.The algorithm generating the time schedule is givenin Figure 5. The basic idea of the algorithm is toconsider every possible execution thread of theprocess simultaneously. Starting with the set ofexecuting activities characterizing the current stateof the process, the currently terminated activity isdeleted from this set. Its subsequent activities areinserted either in the set of executed or waitingactivities, depending on the availability of therequired products and resources. Each time thefinal activity of the process is deleted from theset of executed activities, an item indicating thisevent is inserted into the time schedule. The itemcontains information concerning the total costs andthe probability of that event. After finishing theexecution of an activity, the set of waiting activitiesis searched for activities that have become readyto start, i.e. the required products and resourceshave become available. This loop is executed untilthe set of executed activities is empty, i.e. thereare no further threads of execution in the process.At this point, a nonempty set of waiting activitiesindicates a deadlock situation. The probabilityattached to each activity in the nonempty set givesthe likelihood of the particular deadlock situation.

3.4. Computation of Probability Distributionsand Risk Measures

The output of the above algorithm, i.e. the timeschedule for a particular process, can be used todetermine the probability distribution of both thethroughput time and the total costs. In order toobtain the probability for a particular time or cost


234


Figure 5. Algorithm for analyzing process instances

value, the time schedule is queried for that value. Ifthe time schedule contains several entries with thisparticular value, their probabilities are summed upto compute its probability.

After having identified a probability distribu-tion, statistical measures can be used to defineappropriate risk measures. As mentioned above,the expected value and the variance (Allen 1978)


235


of the distribution, or the more complex value-at-risk (Jorion 1997) defined on the basis of thedistribution, can be used as risk measures. On thebasis of such risk measures, a utility function (Pratt1964) can be defined, taking into account the prefer-ences and the risk aversion of the process manager.Thus, selecting an alternative involves computingthe utility of all available alternatives and thenselecting that alternative that dominates all oth-ers.

3.5. Process Optimization

The results of the algorithm can be used for threekinds of optimization. Firstly, the set of waitingactivities of an optimal process instance shouldalways be empty. Generally, a waiting activity indi-cates that the throughput time of a process instancecan be decreased by synchronizing predecessoractivities. Secondly, optimization can be achievedby analyzing the set of executed activities. A processinstance can be effectively improved with respect tothroughput time and total costs by improving thoseactivities that appear frequently in this set. Thirdly,the parameters of a process instance that deter-mine the shapes of the probability distributions forthroughput time and total costs are known. Thus,the shapes of these probability distributions can beformed as intended by altering these parameters.Specifically, this optimization can be automated ifsymbolic expressions are computed for the variousprobabilities.

4. EXAMPLE: SOFTWARE TESTING

4.1. Scenario Description

The example used to explain the algorithm is asoftware process model covering test activities.The process model is given in Figure 6 in the

form required by the algorithm. This figure showsthe process in its initial form (solid drawn lines)together with an extension (dashed lines), whichaims at improving the initial process. Each activityin this figure is augmented with two values: thefirst (second) indicates the time consumed by thecorresponding activity within the initial (revised)process. Obviously, since activity Determine TestAdequacy did not exist in the initial version, onlyone time value is given. Furthermore, probabilitiesare attached to edges. Again, the first probabilitygives that of the initial process and the second thatof the revised process. The objective of the analysisis to compare these two versions of the process,the initial process and the extended process, withregard to the time required for testing.

The initial process consists of five activities:Seeding artificial Errors, Generating Test Cases, Testing,Counting Artificial Errors, and Debugging. The initialprocess starts with seeding artificial errors intothe program under test. The objective of seedingartificial errors is to obtain an estimate of thenumber of errors remaining in the program aftertesting (Zhu et al. 1997). After seeding errors, testcases are generated. In the initial process, test casesare generated randomly, which, although cheap interms of cost and time, are inefficient in terms ofdetecting errors. After generating test cases, theprogram under test is executed with these testinputs and failures are registered. To determinethe quality of the test cases, the artificial errorsdetected are counted. Depending on the numberof the detected artificial errors, either test casegeneration is repeated or the testing process isfinished by debugging, i.e. removing all detectedfaults.

After carrying out several test processes accord-ing to the initial model, the tester recognizes thattest case generation has to be repeated several timesin order to achieve a sufficient quality. The reason is

Seedingartificialerrors

Generatingtest cases

Testing DebuggingDeterminetest adequacy

(1,1) (1,1.5) 2 (1,1) (0.5,0.5) (3,2)

(10%,60%)

(90%,40%)

70%

30%

Countingartificialerrors

Figure 6. A software testing process


236


obvious, generating test cases randomly. Therefore,the tester tries to optimize the process by generatingtest cases systematically by white-box techniques.Generally, white-box techniques require generatingtest cases on the basis of the source code, whichfulfill a certain control or data flow criterion.

But, before changing the process, the tester hasto determine which process will lead to savings,at least in time. Even in this simple example, itis almost impossible to predict which alternativedominates the other.

4.2. Determining the Probability Distributions

As explained above, the basic idea of the algorithmin Figure 5 is to consider all possible threads ofthe process enactment simultaneously. Since thenumber of all possible threads might be very large,only those that can occur with at least a probabilitypthres are considered. In our case, pthres was set to 0.01for the analysis of the processes.

After calculating the process time schedules ofboth processes, probabilities of equal time valuesare cumulated to a single value. The probabilitydistributions obtained in this way are depicted inFigure 7.

4.3. Using the Risk Measures for DecisionMaking

In our simple example, the revised process domi-nates the initial process by shorter throughput timesbeing more likely than in the initial process and highthroughput times being less likely as in the othercase, as shown by the probability distributions. Thisis also expressed by the expected value µ and thevariance σ 2 of the distributions.

In this simple case, a decision can be inducedsolely on the basis of the expected value and thevariance, since the revised process dominates theinitial process in both parameters. However, it isalso possible that one alternative dominates theother with respect to one parameter and vice versawith respect to the other parameter. In these cases,preferences of the process manager can be usedto calculate the utility (Pratt 1964) of an alternativeto compare with those of other alternatives. Forinstance, the process manager might be risk averse,i.e. the process manager would prefer the alternativehaving the least risk, although other alternativescan dominate this alternative with respect to theexpected throughput time or total costs.

0

0.02

0.04

0.06

0.08

0.1

0.12

0.14

0.16

0.18

0 10 20 30 40 50 60

Pro

babi

lity

Time in hours

Initial processRevised process

Alternativeµσ2

Initial process20.728181.295

Revised process14.86382.365

Figure 7. Probability distributions and statistical measures of the alternative processes


237


5. CONCLUSIONS

A problem often encountered in practice is thatsoftware, even though still being in development,needs to be evolved due to various reasons suchas changes in user requirements. The evolution ofsoftware under development is merely an issue ofsoftware process evolution, and we therefore needthe appropriate means to change software processesduring their enactment.

We have described model-based decision supportas a generic approach to supporting the decisionprocess. The underlying idea of model-based deci-sion support is to have a generic framework thatis capable of loading the necessary decision modelsfrom an extendable model database and executingthem with the required data. The benefit of thisapproach is that the framework can be adapted torequirements of changing decision processes.

Furthermore, we have explained a decision modelfor analyzing processes to determine the risk ofcertain process parameters and to support theprocess manager in decisions related to processevolution. The technique requires a process modelthat only defines control flow within the process.Since this information can be easily provided formost processes, the technique is applicable to a widevariety of processes. Furthermore, the techniqueis automatable. After having entered the processmodel to be considered, analysis of the process iscarried out automatically.

REFERENCES

Allen AO. 1978. Probability, Statistics, and Queueing Theory.Academic Press, New York, USA.

Alloui I, Beydeda S, Cimpan S, Gruhn V, Oquendo F,Schneider C. 2000. Advanced services for processevolution: Monitoring and decision support. In EuropeanWorkshop on Software Process Technology (EWSPT),Springer Verlag: Berlin, 21–37.

Arrow KJ. 1963. Social Choice and Individual Values, 2ndedn. Wiley, New York, USA.

Cunin P-Y. 2000. The PIE project: an introduction. In 7thEWSPT European Workshop on Software Process Technology,Springer Verlag: Kaprun, Austria, 1–5.

Cunin P-Y, Greenwood RM, Francou L, Robertson I,Warboys B. 2001. The PIE methodology – concepts andapplication. EWSPT European Workshop on Software ProcessTechnology, Springer Verlag: Witten, Germany, 3–26.

Dami S, Cunin P-Y, and Francou L. 2001. Opera-tion manual of the PIE system – consolidated ver-sion. Technical report, ESPRIT Project ProcessInstance Evolution (PIE). Techreport number D1.10,http://www.cs.man.ac.uk/ipg/pie/public-e.htm.

Fishburn PC. 1984. Foundations of risk management: riskas a probable loss. Management Science 30: 396–406.

Greenwood M, Robertson I, Warboys B. 2000. A supportframework for dynamic organizations. In 7th EWSPTEuropean Workshop on Software Process Technology, SpringerVerlag: Kaprun, Austria, 6–20.

Hofstede A, Orlowska M, Rajapakse J. 1998. Verificationproblems in conceptual workflow specifications. Data andKnowledge Engineering 24(3): 239–256.

Jorion P. 1997. Value at Risk: A New Benchmark forMeasuring Derivatives Risk. Irwin Professional Publishing,Chicago, USA.

Luce RD. 1980. Several possible measures of risk. Theoryand Decision 12: 217–228.

Moskowitz H, Bunn D. 1987. Decision and risk analysis.European Journal of Operational Research 28: 247–260.

Pratt J. 1964. Aversion in the small and in the large.Econometrica 32: 122–136.

Ramsey FP. 1931. Truth and probability. In TheFoundations of Mathematics: Collected Papers of FrankP. Ramsey, Routledge and Kegan Paul: London, UK,156–198.

Tarumi H, Matsuyama T, Kambayashi Y. 1999. Evolutionof business processes and a process simulation tool. InAPSEC Asia-Pacific Software Engineering Conference, IEEEComputer Society Press: Takamatsu, Japan, 180–187.

van der Aalst WMP. 1998. The application of petri netsto workflow management. The Journal of Circuits, Systemsand Computers 8(1): 21–66.

von Neumann J, Morgenstern O. 1947. Theory of Games andEconomic Behaviour. Princeton University Press, Princeton,USA.

Zhu H, Hall PAV, May JHR. 1997. Software unit testcoverage and adequacy. ACM Computing Surveys 29(4):366–427.


238

dynamic evolution of software processes to evolve software systems during their development

Documents