 Journal of Computer and Communications, 2013, 1, 32-39 http://dx.doi.org/10.4236/jcc.2013.15006 Published Online October 2013 (http://www.scirp.org/journal/jcc) Open Access JCC Smart Devel op men t Proc ess Enact ment Based on Context Sensitive Seq uen ce Prediction Andreas Rausch, M ichael Deynet 1Chair of Software Systems Engineering, Department of Computer Science, TU Clausthal, Clausthal-Zellerfeld, Germany; 2Embed- ded Systems Development, Fraunhofer IESE, Kaiserslautern, Germany. Email: andreas.rausch@tu-clausthal.de, Michael.Deynet@iese.fraunhofer.de Received July 2013 ABSTRACT Actual software development processes define the different steps developers have to perform during a development project. Usually these development steps are not described independently from each other—a more or less formal flow of development step is an essential part of the development process definition. In practice, we observe that often the process definiti ons are hardl y used and ver y s e ldom “lived”. One reason is that the pre de fined gene ra l process f l ow does not reflect the specific constraints of the individual project. For that reasons we claim to get rid of the process flow definition as part of the development process. Instead we describe in this paper an approach to smartly assist developers in software process execution. The approach observes the developer’s actions and predicts his next development step based on the project process history. Therefore we apply machine learning resp. sequence learning approaches based on a general rule based process model and its semantics. Finally we show two evaluations of the presented approach: The data of the first is derived from a synthetic scenario. The second evaluation is based on real project data of an industrial enterprise. Keywords: Software Engineering; Software Pro ce s s De scription La ng uages; Software Processes; Process Enactment; Process Improve ment; Machine Learning; Sequence Prediction 1. Introduction Customers are placing growing demands on the software industry. They are looking for more complex products and at the same time that are easier to use, have higher quality, and are faster produced and shipped. The conti- nuous increase in size and functionality of those software systems [1] has now made them among the most com- plex man-made systems ever devised [2]. Following a statement of Boehm [3], th e ability of any industry enterprise to survive the rough market condi- tions will depend more and more on software and hence the capabilities to deliver in time, budget and quality re- quired software. For that reasons over the years, a variety of software process models have been designed to struc- ture, describe and prescribe the software systems con- structi o n pr oc ess. These models range from generic ones, like the w ater- fall model or the spiral model, to detailed models defin- ing not only major activities and their order of execution but also proposing specific notations and techniques of application, like for instance RUP or V-Mode ll XT—also called as rich process models. In the last decade agile process models, like Scrum or Kanban, have become more and more popular. Independently what kind of process model you apply, it can only strengthen your software development capa- bilities as long as you apply it correctly. But, there is huge gap between the defined and the applied develop- ment process [4-7]. As shown in [4-7] one reas on for th is discrepancy is that a predefined, even organization spe- cific adapted, development process model cannot reflect the specific constraints of the individual project. Tom DeMarco even mentioned about the nature of process models and methodologies in [8]. It doesn’t reside in a fat book, but rathe r it is inside the heads of people carry- ing out the w ork. Consequently following this idea, we describe in this paper an approach to smartly assist developers in soft- ware development process application. The basic idea is to observe the developer’s actions and thereby collect the development process knowledge inside the heads of people carrying out the work. Hence the project process history provides the process knowledge for our approach. Based on this process knowledge we predict the next de- velopment step. Therefore we apply machine learning  Smart Development Process Enactment Based on Context Sensitive Sequence Prediction Open Access JCC resp. sequence learning approaches based on a general rule based proces s model and i ts semant i c s . The rest of the paper is structured as follows: Section 2 contains a shore overview of the related work in the area of software process languages and sequence learning. In Section 3 we present an overview of our software process description language. Our approach for a smart devel- opment process enactment based on context sensitive sequence prediction is shown in Section 4. In the follow - ing Section 5 we show two evaluations of the presented approach: The data of the first is derived from a synthetic scenario. The second evaluation is based on real project data of an industrial enterprise. A short conclusion in Section 6 rounds the pa per up. 2. Basic Terms, Related Work and Objectives As already mentioned the goal of software processes is to help us to successfully develop and deliver (complex) software systems. A software process is a set of activities in a project which is execute d to develop and produce the desired software system. A software process description is a textual representation of a software process. To ela- borate software process description in a well-defined manner we use software process description language. Using software process description languages has many advantages: The clear defined syntax and semantics ena- ble a tool-based interpretation. Thus, controlling, plan- ning, and coordination of software projects can be (se- mi-)automated. Various software process description languages have been developed. A good overview of software process languages provides surveys like [9-13]. We distinguish between three different language paradigms: rule based languages (pre-/postconditions), net based languages (pe- tri nets, state machines), or imperative languages (based on programming languages). In addition there are lan- guages using multiple paradigms. Rule based languag es hav e loosely coupled steps, which are flexibly combinable. The advantage is that develop- ers can execute the step in their own manner. The disad- vantage is that there exists no tool support during process. Thus, there is a lower benefit for the developer during process execution. Imperative and net based languages implement the step order directly. The step order corresponds to a gen- erally valid order. Hereby, a tool based process execution is possible. The problem is that the order of the steps defined in the process description does not reflect the de- veloper ’s working method. For that reason our claim is to define a process de- scription language which prevents these disadvantages in a way that A) the development process model does not prescribe the order of development steps the developer has to ex- ecute B) the process enactment environment guides the de- veloper during process execution by context sensitive re- comme ndi ng the next development ste ps. Therefore we adapt sequence prediction approaches, which are a subgroup of machine learning approaches, to process enactment environments. Hartmann and Schrei- ber describe different sequence prediction algorithms in [14]. The sequence prediction technique which is adopt- ed in this paper is based on Davison/Hirsh [15] and Ja- cobs/Blockeel [16]. 3. Overview of the Process Description Language In this section we present a short overview of the con- cepts of our process modeling language. This language contains only elements which are needed to assist the user during process enactment. The language does not contain other elements like phases or roles although these concepts could be easily added. We have designed a pro- cess language based on pre-/postcondition. One key ele- ment in our language is a step which is an activity during process enactment. For example there are existing steps like “Map requirement to Component” or “Specify Com- ponent”. Every step has pre- and po stconditions , that describe if the user can start or stop the step execution. Furthermore, steps can contain a set of contexts. This can be an execu- tion context which is a subset of the product model (e.g. all classes within component c are in one execution con- text) or a “parameter” which describes a certain situation. This can be for example the implementation language, the used case tool, framework, the project, and so on. The number of step types is fix at project execution time; the number of context instances can vary (e.g. if a new product is added to the product model, one or more ex- ecution context instances are created corresponding to the process description). A more detailed description of our language can be found here [17-19]. 4. Smart Development Process Enactment Based on Context Sensitive Sequence Prediction For user (developer) assistance we have developed an approach to predict the next step the user wants to start. Our approach observes the last couple of started steps (and corresponding contexts) and tries to build a database where identified sequences are stored. As already mentioned our work is based on the work of Davison/Hirsh [15] and Jacobs/Blockeel [16] which will be presented in more detail in the next subsection.  Smart Development Process Enactment Based on Context Sensitive Sequence Prediction Open Access JCC 4.1. Overview of the Underlying Work IPAM is the work of Davison/Hirsh and addresses the prediction of UNIX commands. The approach imple- ments a first order markov model, so the prediction which is made is based on the last observed element. IPAM stores unconditional and conditional probabilities in a da- tabase. After each observation the entries of the database are updated as follows: ( )( ) ( ) P xyαPxy 1α ′=⋅ +− for x = current observation and y = last observation. The entries with x ≠ current observation are updated with: . is a parameter between 0 and 1. Davison/Hirsh recom- mend a value of . The work of Jacobs/Blockeel is based on IPAM but implements a higher order markov model. If was observed and the prediction for x was correct (e.g. has highest probability) new entries are stored to the database. Let C be the set of suffixes of yy… with . Let l be longest Suffix of with . The following new entries are stored to the database: P(z|cx)P(z|l),for allcCandz= ∈∈ observed ele- ments. 4.2. Our Approach The central part of our appro ach is the LookupDB which stores the experience data Figure 1 (middle box). Each of the elements of the LookupDB stores, among other things, a condition (cond), a step prediction , and a proba- bility (P). This describes th e probability (P) that the next step (prediction) will be started, given the occurrence of the step sequence cond. For example: An element of LookupDB can store the condition 1→2→3. When the steps 1→2→3 are observed, the probability that step 1 will be started is 0,9. Further, for each element in the condition sequence a set of relevant context pro babilities are stored. Those are these contexts which were observed in the past. For prediction (see Figure 1, right) of the next step all relevant elements of LookupDB are taken and for each of these elements an “actual probability” is calculated. Here, our approach considers the learned context relevance in LookupDB and the actual observed contexts in the cor- responding w indow. After prediction and after observation our algorithm learns this observation by updating the conditional prob- abilities and context relevance of all matching elements in the LookupDB (see Figure 1, left). In the following out approach is specified in a more detailed way. First, let us define some relevant elements of our meta model (see [17-19]): (1) Let S be index set which represents the set of Steps (2) Let C be index set which represents the set of Figure 1. Overview of the approach. Step: 1 2 3 1 2 3 1 2 3 1 2 3 1 2 3 1 2 3 1 2 3 1 ? ExcutionContext (IN): 4 5 6 4 5 6 7 8 9 7 8 9 4 5 6 7 8 9 4 5 6 4 ? ExecutionContext (OUT): 3 3 3 4 4 4 3 3 3 4 4 4 5 5 5 6 5 6 4 4 3 4 Kontext x: ................... Kontext y: ................... .... LookupDB Learning After each observation: For all elements in LookupDB which condition (Cond) matches to the last observed steps (without last step – this will be learned) and the Prediction matches to the last observed step: 1.Update P: P=alpha*P+(1-alpha) (see [22]) 2. Update Context relevance: For each Index i: For each line j (e.g. IN, OUT, …): let a be the actual context observation in [i,j] update context relevance K[a]=#observeda‘s in [i,j] / #observed contexts in [i,j] (this is the probability of a) 3. Update Context prediction: Let cbe the execution context tolearn (IN of the last observed step). Let l be a list of elements [Index:x,line] wherec is observed in actual context observation For all l: Update w: w=alpha*w+(1-alpha) 4. If last prediction was correct: Add new elements to LookupDB (see [23] for the algorithm) Prediction Let L be a list of (copied) elements of LookupDB which Cond matches tothe last observed steps (L contains copies of LookupDB –changes do not modify LookupDB) For all l ∈L: 1. For each Index i: For each line j (e.g. IN, OUT): let x be the actual context observation in [i,j] delete all K[y] in the Context relevance with y!=x in [i,j], e.g.: 2. Calcutales overall context relevance: ocr=arithmetic mean of all K[*] in the Context relevance of l 3. Calculate P_actual = P* ocr Predict the l with the highest P_actual. -2 K4=0,6 K4=0,5 … -1 K5=0,3 K4=0,4 … 0 K6=0,3 K4=0,5 … Index IN OUT … Index: -2 -1 0 IN: 4 5 6 OUT: 4 4 3 e.g. i=-2, j=IN: actual context observation in [i,j] c = 4 Index: -2 -1 0 Cond : 1 2 3 Prediction: 1 P= 0,9 Context relevance: Context prediction: [Index:0,IN] w = 0,9 [Index:0,OUT] w = 0,2 [Index:0,Kontext x] w = 0,2 [Index:1,IN] w = … … -2 K4=0,6 K7=0,5 K3=0,8 K4=0,5 K6=0,1 … -1 K5=0,3 K8=0,5 K3=0,1 K4=0,4 K5=0,2 … 0 K6=0,3 K9=0,7 K3=0,8 K4=0,5 K5=0,3 K6=0,2 … Index IN OUT Kontext x: Sequence of Steps and contexts startet from the user  Smart Development Process Enactment Based on Context Sensitive Sequence Prediction Open Access JCC Contexts (3) Let CC be index set which represents the set of Context Classifications. To address the past observed steps we need an index set I: (4) Let I be index set . The function observation returns the observed step at the index i, where i = 0 means the last observation, i = -1 the last but one observation, et cetera (see Figure 1 top right): (5) Furthermore, we need a function which returns the ob- served context at index i and at the Context Classification cc: (6) ( ) 2: DEF observationI CCC= ×→ In the example in Figure 1, observation 2(0,IN) re- turns 6. 4.3. LookupDB We define our LookupD B : (7) Let :{0,1,2, } DEF LOOKUPDB = … be Index Set Each element of LOOKUPDB r epres ents an element of the LookupDB. Every element of our LookupDB has a condition cond. We define (8) :{ } DEF CONDLOOKUPDB IS= ×× is the set of all step sequences of elements of the LookupDB. For example: The following elements exist for the LookupDB element shown in Figure 1: (69,−2,1), (69,−1,0), and (69,0,3) where 69 is the ID of the shown LookupDB element. Let ; describes the step of ldbat position i. (9) :{ } DEF = × Is the set that describes the length of the condition de- fined in (8). The following element exists for the Loo- kupDB element described above: (69,3). The condition length is 3. Let ; de- scribes the condition length of ldb. The set describes the predicted step of the element of the LookupDB: (10) :{ } DEF =× . (11) [ ] :{0,1 } DEF P LOOKUPDB= → defines the pro- bability of the element of the LookupDB that the pre- dicted step occurs. For the element in Figure 1(69,1) and . For easy handling describes the probability of the LookupDB element ldb. Theset CONTEXTWEIGHT describes a weight for each context classification (Figure 1: the lines of the table, e.g. IN, OUT), index (Figure 1: rows of the table) and context (number in the fields of the table) for each element of the LookupDB: (12) {} CONTE XTWEIGHT LOOKUPDB CCIC∈××× ×× The following elements describe the example in Fig- ure 1 at index 1, CC=IN: (69,, 1,5,3,10)IN KCONTEXTWEIGHT−∈ ; (3/10) de- fines the probability that the context K5 at position IN and index-1 is relevant. Now, we define a function that returns 1 if a specified entry of LookupDB corresponds to the last observed steps: (1) (){ } : 0,1 DEF match LOOKUPDB= ×→ ( ) ( ) [ ] , , 1if :for all,0 0 otherwise ldb qs ldb matchldboffset condobservation q offset q lenCond = − =∈− Anymore, we define the following function that finds a specific element from the set CONTEXTWEIGHT: (2) : DEF getCWLOOKUPDB CCIC CONTE XTWEIGHT =× ×× → ( ) , ,,:getCWldb cci ccw= with and ,, cwcw cwcw idldbcc cci iandc c== == 4.4. Prediction For prediction we define the following functions: (3) [ ] ( ) [ ] :{0,1 }0,1 DEF getAMCICC C=×××→ ( ) {( ,,,)}:with: arithmetic mean of all(is threshold) getAMCi ccc wamcamc w θθ = = > . (4) ( ) :{[0,1] } DEF fLOOKUPDBICC C=→ ××× ( )() { } [ ] ( ) ( ) :,,,with,0 and :2,for allandand :/ (,):,,, ldb fldbi cc c wilenCondc observationicciccw xy withxygetCWldb ccic = ∈− = = = The function f takes an entry of LOOKUPDB and re- turns a set of elements (ind ex,cc,c,w). w corresponds to the context weight of ldb for each index i and cc in ldb and for the corresponding c found in the observation. The function getAMC takes a set of elements (in- dex,cc,c,w) and returns the arithmetic mean of all w. ge- tAMC(f(ldb))returns a “parameter” that the element of the LookupDB (and the learned context weights inside) cor- responds to the observed contexts. The function getActualP takes an entry of LOO- KUPDB and calculates an actual P weight dependent on ldb and the actual observation (this weight is used to se- lect the best entry of LOOKUPDB for prediction): (5) [ ] : 0,1 DEF getActualP LOOKUPDB= → ( )( ) ( ) :} ldb getActualP ldbgetAMCfldbp= ∗ Now, we can describe the function to predict the next  Smart Development Process Enactment Based on Context Sensitive Sequence Prediction Open Access JCC step: (6) :( ) DEF makepredictionPow LOOKUPDBS= → (): )makeprediction ldbs with= ( )( ) :for maximalsprediction ldbgetActualP ldb= To predict the next step we call the function make pre- diction with a set of all elements ldb of LookupDB with match(ldb,0) = 1. 4.5. Learning To update the LookupDB, the following steps are done (note: is the step a prediction we made and we want to learn): If there exists no with ( ,1)ldb LENCOND∈ and ((,0),( 1))ldb observationCOND−∈ and ( ,(0)) s ldb observationPREDICTION∈ a new entry is added to the LookupDB (the entry with the shortest cond): (19) : {}{} { }{}{} {}{} { }{}{} DEF addEntryLOOKUPDB COND LENCOND PREDICTIONP LOOKUPDB COND LENCOND PREDICTIONP = × ×× × →× ×× × 00, 000 111 11 (,,, ): ( ,,,, addEntry ldbcondlcprep ldb condlcprep = with: • 1 01010 1 010 \, \,\ , \,\) ldb ldbcondcondlc lc pre prep p =∅ =∅= ∅ =∅=∅ • 01 010 1 0101 1,1, 1, 1 ,1 ldbldbcondcond lc lc prepre pp +=+= + =+= += • andn ldbn ldb • 01 (, 0,(1)) and ((,0),(1)) n observation condnobservationcond −∉ −∈ • 01 ( ,1)and( ,1)n lcn lc∉∈ • 01 ( ,(0)) and( ,(0)) s s n observation pren observationpre ∉ ∈ • 01 ( ,1)and( ,1)npnp αα −∉ −∈ Let : ( ) ( ) ,1 1( ,0)}. s matchldb and l observationPREDICTION= ∈ For each element the following steps are done: (20) { } :{}with: DEF updatePP LOOKUPDBP=×→ ( ) ( )( ) ( ) ( ) 01 0 1 10 , :,,, ,*1andp \{(ldb,pp)} updatePpldbpwith ldb pppldb pp p andldbppp αα = ∈∉ +− ∈= 1{(, *(1))} +− (see [15]) (21) { } : DEF updateContextweight CONTEXTWEIGHT= {}LOOKUPDB CONTEXTWEIGHT×→ ( ) 01 , :withupdateContextweight cwelcw= • For all ( ) 0 ,,, ,,ldb cc i cxycw∈ with 1 (,,, ,,)ldbelldb cc i cxycw≠⇒ ∈ • For all ( ) 0 ,,, ,,ldb cc i cxycw∈ with and () () 11 2,,,, ,, and (,, ,,1,1) cobservationi ccldbcci c xy cwldb cci cxycw = ⇒∈ + +∈ • For all with and ( )() 11 ,,, ,, and (,,,,,1) s cobservationildb cc icxy cwldb cci cxycw ≠⇒ ∉ +∈ This function updates the probabilities of the context information in ldb. If the last prediction was correct new entries are added to the LookupDB according to the work of Jacobs et al. [16]. Let be a subset of LOO- KUPDB w ith: (22) , :{ | DEFq i QldbLOOKUPDB cond= ∈ ( ) 1for all ,0 } s q observation ii lenCond = − ∈ Let be subset of LOOKUPDB with: (23) , :{ | DEFl i LldbLOOKUPDB cond= ∈ ( ) [ ] for all ,0} s ldb observation ii lenCond = ∈ Let ll be the element of L with the longest lenCond and P(ll)>0. The f unc t ion update LOOKUPDB is defined as: (7) {}{ } {} {} {} {} : {})({} {} { }{}{ }) ( } { DEF updateLOOKUPDBLOOKUPDB Q ll COND LENCOND PREDICTIONP CONTEXTWEIGHTLOOKUPDBCOND LENCOND PREDICTIONP CONT EXTWEIGHT =×× × × ××× → ×× × ×× ( ) 00000 0 , ,,,,,,:updateLOOKUPDBLDBql clcprepcw= ( ) 1111 11 ,,,, ,LDB c lcprepcw with (see [16]): • 0 10 1 {0,1, ,}and{0,1, ,,} ||||| | nLDBn m LDB withLDBqLDB … ∈……∈ += Let ldiff be . For all there is aninwith: ∈ • 0 1 1 ((,), )and((,1), ) for alland;and:((,0),(0)) q iscldiffelis cisldiffel oberservation c ∈ −∈ ∈ • 01 (,)and (,1)q llcldiffelllc∈ +∈ • 01 (,)and(,)for allqs preldiffels pres∈∈ • 00 1 (, )and(, 2)and(, 2)qppll ppldiffel pp∈∈ ∈ This function adds new entries to LookupDB by taking the entries which have predicted the observation correctly  Smart Development Process Enactment Based on Context Sensitive Sequence Prediction Open Access JCC and “extending” the corresponding conditions by adding the observation (see [16] for detail). 5. Evaluation 5.1. Synthetical Process For the evaluation of the approach described in Section 4 we derived a synthetic project scenario. In this scenario the requirements of the system are existent. The goal is to develop an architecture (components, classes) and a cor- responding implementation. The process description con- sists of 4 steps: 1) Identify component, 2) Map require- ment to Component, 3) Specify component (refine re- quirement), 4) Implement component. In the system two types of components exist: a) Com- plex/hardware related components. Here, the engineer has a prototypical method to develop the component (steps 2 - 4 are executed sequentially). b) Components which classes have a high coupling. Here, the engineer has a broad design method (step1; all steps 2; all steps 3; all steps 4). For evaluation three sequences of steps (with corres- ponding contexts) were build: i) Development of com- ponents only of the type a), ii) Development of compo- nents only of the type b), and iii) random mix of a) and b). Our approach is compared with the algorithm from Jacobs/Blockeel [16] which is the underlying sequence prediction technique of our approach. The results are shown in Figure 2. This figure contains two graphs for each scenario: The first (top) describes the total number of correct predictions and the second describes the per- centage distribution of correct prediction after each step (horizontal axis). The Jacobs Blockeel(JB) approach is shown in red color and our approach (MD) is shown in blue color. In all scenarios our approach predicts equal to or better than the Jacobs Blockeel algorithm. Remarkable is that in scenario 3 (the “real world” scenario) our approach pre- dicts the steps substantially better than the JB approach. After 2/3 of all steps our algorithm predicts always cor- rectly. On the other hand the algorithm of JB “drifts” to 53% correct predictions. 81% of correct predictions in scenario 3 might be an indication that our approach is more applicable. 5.2. Real Project Process In addition to the synthetical evaluation (described in section V.A) we evaluated our approach with real project data from anindustrial enterprise. Are there differences between these two evaluations? In the synthetical evalua - tion we described a process description using the de- scription language presented in Section 3. This is a rule based language which is flexibly executable for the en- gineer. On this basis, we derived three test data sets and evaluated our approach with these data. The evaluation of the industrial case study is based on real project data with 5.600 individual development steps. The underlying process description language of the industrial case study was a net based language. Therefore, the process descrip- tion (and the enacted process) is more stringent than our process used for evaluation in section V.A. Like in the synthetically evaluation our approach is compared with the approach of Jacobs/Blockeel. The results are shown in Figure 3 . Again, there are two cate- Figure 2. Results synthe t i c sc enario. 0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1 0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1 0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1 Total number correct predidctions Scenario 1 Scenario 2 Scenario 3  Smart Development Process Enactment Based on Context Sensitive Sequence Prediction Open Access JCC Figure 3. Results of the real project evaluation. gories shown: the first shows the total number of correct predictions and the second shows the percentage distri- bution of correct predictions after each step. Similar to the synthetic approach our approach generates more ac- curate predictions than the Jacobs/Blockeel approach. 6. Conclusions, Further Work Customers are placing growing demands on the software industry. The ability of any industry to survive the rough market conditions will depend more and more on soft- ware and hence the capabilities to deliver in time , budget and quality required software. For that reasons over the years, a variety of software process models have been designed. Software process models can only strengthen your software development capabilities as long as you apply it correctly. But, there is huge gap between the defined and the ap- plied development process. One reason is that the prede- fined general process flow does not reflect the specific constraints of the individual project. For that reasons we claim to get rid of the process flow definition as part of the development process. Instead we describe in this pa- per an approach to smartly assist developers in software process execution. The basic idea is to observe the developer’s actions and thereby collect the development process knowledge inside the heads of people carrying out the work. Hence the project process history provides the process know- ledge for our approach. Based on this process knowledge we predict the next development step. We apply a se- quence learning approach to predict the next develop- ment step with respect to project process knowledge. We have evaluated our approach on a synthetic and a real world project setting. In both settings our approach was able to provide more accurate predictions than clas- sical non context sensitive approaches. However the re- sulting accuracy of 75% to 90% is not high enough for a wide acceptance by developers. However if we present to 0 500 1000 1500 2000 2500 3000 3500 4000 4500 0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 Total number correct predictions  Smart Development Process Enactment Based on Context Sensitive Sequence Prediction Open Access JCC the developer not only a single development step predic- tion but instead presenting the best three predictions— similar to Google which presents a result list after a web query, the prediction accuracy rate would increase to 99.9%. Note, this resulting accuracy has been proved in the two presented evaluation scenarios. Based on such a prediction soundness a process en- actment framework could be widely accepted and applied by developers. The next step is to set up a broader empi- rical experiment to validate the applicability of our pro- cess enactment framework. Moreover additional research and application direc- tions of the presented approach are to support novice de- velopers (e.g. developers works in a new project/new company) by providing the experience data of other de- velopers. Using the experience data (of the developers of one or more projects) for organization-wide process im- provement (e.g. derive a standard process description of the available knowledge) could be another interesting direction to follow. REFERENCES [1] L. Northrop, P. Feiler, R. P. Gabriel, J. Goodenough, R. Linger, T. Longstaff, R. Kazman, M. Klein, D. Schmidt, K. Sullivan and K. Wallnau, “Ultra-Large-Scale Systems —The Software Challenge of the Future,” Software En- gineering Institute, Carnegie Mellon, Tech. Rep., 2006. http://www.sei.cmu.edu/uls/downloads.html [2] A. W. Brown and J. A. McDermid, “The Art and Science of Software Architecture,” In: F. Oquendo, Ed., ECSA, Ser. Lecture Notes in Computer Science, Vol. 4758, Springer, 2007, pp. 237-256. [3] B. Boehm, “Some Future Trends and Implications of Sys- tem and Software Engineering Processes,” Wiley InterS- cience, 2006. [4] D. Rombach, “Integrated Software Process and Product Lines, Unifying the Software Process Spectrum,” 2006. [5] M. Kabbaj, R. Lbath and B. Coulette, “A Deviation Ma- nagement System for Handling Software Process Enact- ment Evolution,” Making Globally Distributed Software Development a Success Story, 2008, pp. 186-197. [6] K. Mohamme d , L. Redouane and C. Bernard, “A Devia- tion-Tolerant Approach to Software Process Evolution,” Ninth International Workshop on Principles of Software Evolution in Conjunction with the 6th ESEC/FSE Joint Meeting, 2007, pp. 75-78. [7] D. Jean-Claude, K. Badara and W. David, “The Human Dimension of the Software Process. In: Software Process: Principles, Methodology, and Technology, Lecture Notes in Computer Science,” Bd. 1500, Springer US, 1999, pp. 165-199. [8] T. DeMarco and T. Lister, “Peopleware, Productive Pro- jects and Teams, Second Edition Featuring Eight All- New Chapters,” Dorset House Publishing Corporation, 1999. [9] K. Z. Zamli, “Process Modeling Languages: A Literature Review,” Dez-2001. http://myais.fsktm.um.edu.my/278/ [10] S. T. Acuna, “Software Process Modelling.” [11] P. Armenise, S. Bandinelli, C. Ghezzi und A. Morzenti, “A Survey and Assessment of Software Process Repre- sentation Formalisms,” International Journal of Software Engineering and Knowledge Engineering, Bd. 3, 1993, pp. 401-401. http://dx.doi.org/10.1142/S0218194093000197 [12] M. I. Kellner, “Representation Formalisms for Software Process Modeling,” Proceedings of the 4th International Software Process Workshop on Representing and Enact- ing the Software Process, Devon, United Kingdom, 1988, pp. 93-96. http://dx.doi.org/10.1145/75110.75125 [13] P. H. Feiler und W. S. Humphre y, “Software Process De- velopment and Enactment: Concepts and Definitions,” Software Process, 1993, Second International Conference on the Continuous Software Process Improvement, 1993, pp. 28-40. [14] M. Hartmann und D. Schreiber, “Prediction Algorithms for User Actions,” Proceedings of Lernen Wissen Adap- tion, ABIS, 2007, pp. 349-354. [15] B. D. Davison und H. Hirsh, “Predicting Sequences of User Actions,” Notes of the AAAI/ICML 1998 Workshop on Predicting the Future: AI Approaches to Time-Series Analysis, 1998. [16] N. Jacobs und H. Blockeel, “Sequence Prediction with Mix- ed Order Markov Chains,” Proceedings of the Belgian/ Dutch Conference on Artificial Intelligence, 2002. [17] M. Deynet, “User-Centric Process Descriptions,” Pro- ceedings of the 3rd International Conference on Software Technology and Engineering, Kuala Lumpur, Malaysia, 2011, pp. 209-214. [18] M. Deynet, “Kontextsensitiv Lernende Sequenzvorher- sage zur Erfahrungsbasierten Unterstützung bei der Soft- wareprozessausführung,” Dr. Hut, 2013. [19] M. Deynet, “Predicting User Actions in Software Pro- cesses,” 4th Workshop on Intelligent Techniques in Soft- ware Engineering at the European Conference on Ma- chine Learning and Principles and Practices of Know- ledge Discovery in Databases (ECML-PKDD), Athen, Ägypten, 2011.
|
