A Quantitive Context Model of Software Process Patterns and Its Application Method∗

Jiakuan Ma, Yasha Wang Software Engineering Institute, School of EECS, Peking University, Beijing 100871

{jiakuan.ma, wangys}@sei.pku.edu.cn

Contact author: Yasha Wang(wangys@sei.pku.edu.cn).

Abstract Defining proper process is an important way of

improving software quality and development productivity. However, software process design is a common issue faced by many organizations. The introduction of process patterns provides an effective solution to the challenge. In previous studies, natural language is commonly employed to describe the context of process patterns, which not only decreases the accuracy of pattern selection made by users, but also goes against the implementation of computer aided experience extraction. Aiming at such a problem, we propose in this paper a quantitive context model of software process patterns and its corresponding application method. A concrete example is also presented in order to further illuminate our idea,. In the end, we briefly introduce the relative tool support in PKUPM (PeKing University Project Management). 1. Introduction

A software process can be defined as a set of activities, methods, practices, and transformations that people use to develop and maintain software and the associated products(e.g., project plans, design documents, code, test cases, and user manuals) [1]. Because software is complex in logic, easy to change, hard to be measured and verified, software processes that fit the peculiarities of the corresponding projects and organizations should be carefully designed [2]. However, software process design turns to be another common issue faced by many organizations in practice. Whether a high quality process that accords with the situation of an organization can be constructed is largely depended on the experience of experts involved. The introduction of relative standards, such as CMM, CMMI, ISO 9000, has notably meliorated

the status, where process design is much too relied upon certain individuals. Lots of best practices broadly proven by the industry are solidified into these standards and absorbed by many companies with the adoption of the standards. Still, the problem has not been completely solved. Standards like CMM relate to the whole lifecycle of software, give advisable guidance for every process area, and provide models for process improvement. But these process standards are on a very abstract level. Although they present the requirement specification of a software process (i.e., what to do), little detailed description on realization of the requirements (i.e., how to do them) is referred. The gap is usually complemented according to actual situations in an organization by either internal (say, SEPG members) or external experts (say, professional consultants), who have a deep insight into the standards as well as rich experiences in practice. Therefore, it can be seen that the very detail of realization is still not covered in standards like CMM, nor is the context information on process application.

As an effective means of solving the issues in process design, pattern theory is introduced to software process management field, and so emerges the concept of process pattern, which is defined as a collection of general techniques, actions, and/or tasks (activities) for developing software [4]. A process pattern not only describes a problem raised in process design, but also illuminates the context where the problem exists. Moreover, there can be several process patterns contraposing one same problem, so different solutions can be given under different contexts. Such a mechanism provides more information on the proper situation of applying a process pattern, and more concrete solution description aiming at a certain context makes it easier to be implemented in practice. As a helpful supplement for process standards like CMM, process pattern has been more and more widely applied.

Proceedings of the Sixth International Conference on Quality Software (QSIC'06)0-7695-2718-3/06 $20.00 © 2006

Previous studies commonly employ natural language to depict the context of a process pattern. However, it can lead to unseemly choice of process patterns because of ambiguous understanding by users. Besides, it brings difficulties in computer aided processing of process pattern, making computer aided process data analysis and experience extraction hard to implement. Therefore, in this paper, we introduce a quantitive context model of process patterns, which unambiguously express information like ‘when to use the pattern’, ‘what kind of consequence can the pattern generate under certain input’ via a quantitive model. We also propose a corresponding procedure of applying the model. In the end, PKUPM, a project management tool supporting the process pattern mechanism mentioned above is presented.

The rest of this paper is structured as follows: Section two provides a brief study on related work and compares our work with them; section three presents the quantitive context model and its application procedure; section four depicts an concrete illustration; in section five relative tool support in PKUPM is introduced; section six summarizes the work and outlines some future directions. 2. Related work

Since [3] first proposed the concept of software process pattern, how to describe a process pattern has been an important research topic all through. Although different studies provides diversified constituent elements for a process pattern, which differ in number and names, their main connotation can be summarized as the three elements referred in this paper: problem, solution and context.

[4, 5, 6] discuss the generic conceptual model of software process patterns. In [4, 5], all the process patterns are described in a uniform way: ‘force’, ‘solution’, ‘initial context’ and ‘resulting context’. Among these four elements, ‘force’ and ‘solution’ have the same meaning as the ‘problem’ and ‘solution’ of a process pattern referred in this paper; while ‘initial context’ and ‘resulting context’ respectively presents the proper scene before using a certain process pattern and the possible new scene after applying it, which together constitute the ‘process pattern context’ we proposed. [6] organizes all the process patterns into three categories (i.e. lifecycle pattern, activity pattern and workflow pattern) according to their abstraction extent. For example, a lifecycle pattern is described by ten attributes. Except for ‘Name’, ‘Classification’, ‘Also known as’, ‘example’ and ‘Related patterns’, in the remaining five major elements, ‘intent’ and ‘workflow’ have the same meaning as the ‘problem’

and ‘solution’ referred in this paper; ‘Motivation’, ‘Applicability’ and ‘Consequence’ each depict the process context from a different point of view , which together make up the ‘context’ we mentioned here.

Some other research summarizes process patterns existing in a given area, and defines corresponding description model for them. Some representative work includes [7, 8, 9]. For example, [7] sums up some important process patterns in architecture review, and describes an architecture review pattern via four aspects: ‘Description’, ‘Typical Review Flow’, ‘Use This When’ and ‘Limitations’, where ‘Description’ and ‘Typical Review Flow’ can be mapped to ‘Problem’ and ‘Solution’ that we leverage to depict a process pattern, and ‘Use This When’ and ‘Limitations’ respectively list the advantages and disadvantages of applying the pattern, which correspond to the positive and negative factors that have mutual interaction and need to be balanced according to user preference in our process pattern context.

In the above description model, the context of a process pattern is presented by natural language. In this paper, however, our main work aims at introducing a quantitive context model to improve the depiction of process pattern context, and thus increase the operability of process patterns in practice.

Applying quantitive (especially statistic) method in software process is not a totally new idea. For instance, [10, 11] adopt simple linear regression in statistics, and the widely used COCOMO[12] can also be seen as an improvement on simple linear regression (adding logarithm operation into the linear equation). Nevertheless, in this existing process estimation, statistic method is applied on entities like the whole software process or project, which is of large granularity. Because of the complex information embodied in the analysis, the preciseness and reliability of the result is somewhat weakened. In this paper, we employ the simple linear regression method on process patterns and corresponding project fragments, which curtails the number and complexity of corresponding factors involved, therefore provides possibility of improving the estimation. 3. Quantitive context model and its application method 3.1. Second-order headings

In previous studies, the context a process pattern is commonly described by natural language. However, such a mechanism may reduce the operability of a process pattern. To further explain possible problems that might occur in practice, now we illustrate some of

Proceedings of the Sixth International Conference on Quality Software (QSIC'06)0-7695-2718-3/06 $20.00 © 2006

them by a concrete example elicited from [7].For the sake of convenience, only two process patterns on architecture review are involved in the discussion: SARB (Software Architecture Review Board) Review and Blitz Review, whose natural language form of contexts are listed in Table 1 and Table 2 respectively:

Table 1. SARB Review’s context described by

natural language SARB Review

1) both the size and complexity of the architecture to be reviewed are large. 2) the expected quality of the architecture to be reviewed is high 3) both the time and cost budgets are high

Table 2. Blitz Review’s context described by

natural language Blitz Review

1) both the size and complexity of the architecture to be reviewed are small. 2) the expected quality of the architecture to be reviewed is low 3) both the time and cost budgets are low

Such two context descriptions are likely to lack

enough operability in practice due to the following two reasons:

Firstly, there may be uncertainties when applying such two patterns. The adjectives such as ‘small’ and ‘high’ are all relative words, whose actual meanings can vary greatly in different users’ mind. In such a case, correctness of the ultimate decision is highly depended on the experience of users themselves.

Secondly, there may be discontinuities when applying such two patterns. When estimated values of all the variables mentioned above (e.g. size, complexity, time budget, etc.) are medium, even if users can understand the meanings of two contexts, they still have to fully depend on their self-experience to choose one pattern that fits the situation better, for there is no useful information provided above in such a case.

In order to solve the problem, we propose a quantitive context model for process patterns. With the introduction of quantitive idea, the improved context model gets closer to actual application scene, which further increases the operability of process patterns. Because of the various contents, types and methods of software development, users may have different concerns on a process pattern. Therefore, our model is customizable: users can enact the number and type of variables in the model due to their actual needs in application.

Definition 1: (Environment parameter vector). An environment parameter vector is a collection of organization or project parameters that influence the input and effect when implementing a process pattern. It can be denoted as a m-tuple: 1 2, ,...en mV en en en=< > ,

where ien is an organization or project parameter. enV can have different elements in a given process pattern, which is left to be enacted by designers and/or users of process patterns. Typical parameters include: a. Object size. Measurement of size varies with the different types of the object involved in different process patterns. Taking an architecture review for example, its object size is the size of architecture to be reviewed, which can be measured using the method given in [13]. b. Object complexity. Similar with object size, Process patterns may have respective special measurement of complexity. Still in case of an architecture review, its object complexity is determined by the complexity of the architecture to be reviewed, whose value can be obtain by using the method given in [10]. Definition 2: (Estimated parameter vector). Estimated parameter vector is an estimation of the input and effect when implementing a process pattern. It can be denoted as a n-tuple:

1 2, ,...es nV es es es=< > ,

where ies is a parameter that represents one aspect of input or effect as a result of implementing the process pattern. As enV , the content of esV is left to designers and/or users of process patterns. Typical parameters include: a. Cost. Cost is an estimation of money spent when applying the pattern, so it is usually measured by monetary units. b. Time. Time is an estimation of the duration when applying the pattern, which is usually measured by hours, days and so on. c. Quality. Quality is an estimation of the extent to which the artifacts fulfill the expectation of users. It can be gained through scoring. Definition 3: (Estimation operator) Estimation operator is a transformation rule from enV

to esV , which can be denoted as an n-tuple::

1 2, ,... n∆ =< ∆ ∆ ∆ > , where : .i en es iV V es∆ → In this paper, the multiple linear regression model, which is widely used and gain great success in economics, sociology and so forth [14], has been adopted as the concrete form of i∆ . So

Proceedings of the Sixth International Conference on Quality Software (QSIC'06)0-7695-2718-3/06 $20.00 © 2006

now we can have:

11 12 11 1

2 21 22 2 2

1 2

, ,..., ,...

... ......, ,...

m

m

n mn n nm

es enes en

es en

β β ββ β β

β β β

=

The parameter ijβ in this estimation model can be calculated using relative formulas in [14] and historical data. After a process pattern finishes its execution, new data is collected and used to calibrate these parameters. Definition 4: (Quantitive context model) Quantitive context model of a process pattern can be denoted as a three-tuple:

, ,en esQ CONTEXT V V− =< ∆ >

where enV 、 esV 和 ∆ are respectively given by previous definitions. 3.2．Application procedure The application procedure of a quantitive context model is as follows: Step 1: The user search for all the process patterns relative to the given problem (say, architecture review). The result is denoted as PPS , where

1 2{ , ,... }lPPS pp pp pp= . Step 2: The user gives value to environment parameter vector.

. 'en i iV en en← (1 )i m≤ ≤ ，where 'ien

is estimation for .en iV en Step 3: Estimated parameter vectors of every process pattern in PPS are calculated.

1. ( . )*( . )

mi i

es j i jk en kk

V es V enβ=

← ∆∑

(1 ,1 ,1 )i l j n k m≤ ≤ ≤ ≤ ≤ ≤

Step 4: Let selectpp be the pattern finally selected by

user. Apply the chosen pattern selectpp and collect real values for the estimated parameter vector

selectesV in the quantitive context.

Step 5: Calibrate the estimator using newly collected data. 4. An example

In section 3, we explain possible problems that might occur when applying traditional context model via two process patterns on architecture review. In this section, we still take the two patterns as an example. We will establish quantitive context model for them,

and illustrate the whole method we proposed in this paper by a concrete example.

First we should decide the parameters appearing in enV and esV . In this illustration,

,enV Size Complexity=< > ,

, ,esV Cost Time Quality=< > Here the size element and complexity elements in

enV are respectively measured by the method proposed

in [13] and [10]; for the three elements in esV , the cost and time elements are repectively measured by the actual money(united by Yuan) and time(united by day) spent, while quality is measured through scoring, as suggested in definition 1 and 2.

The whole application is presented as follow: Step 1: The user search for process patterns relative to architecture review, and get two candidate patterns: SARB Review and Blitz Review, whose historical data sets are listed in Table 3 and Table 4 respectively:

Table 3. Historical data of SARB Review Process pattern SARB Review Application Serial number

No.1 No.2 No.3

Size 93 71 43 Complexity 4.3 3.1 3.0 Cost 1550 1100 720 Time 4 4 3 Quality 3.9 4.1 4.3

Table 4. Historical data of Blitz Review

Process pattern Blitz Review Application Serial number

No.1 No.2 No.3 No.4

Size 31 22 29 41 Complexity 2.6 3.0 1.9 2.0 Cost 420 450 400 700 Time 2 2 2 2 Quality 3.3 2.9 3.7 3.5

By means of calculation formulas of linear

regression introduced in [14], we can get their estimators shown in Table 5 and Table 6 respectively:

Table 5. Estimator of the SARB Review

SARB Review

Proceedings of the Sixth International Conference on Quality Software (QSIC'06)0-7695-2718-3/06 $20.00 © 2006

Cost=13.09*Size+135.03*Complexity–247.93

Time=0.04*Size+0.19*Complexity+0.92

Quality=(-0.01)*Size-0.04*Complexity+4.72

Table 6. Estimator of the Blitz Review Blitz Review

Cost=19.02*Size+103.36*Complexity–337.75

Time = 2

Quality=(-0.01)*Size–0.69*Complexity+5.16

Step 2: The user gives value to environment parameter vector. Here he sets

. 69enV Size = , . 2.9enV Complexity = Step 3: Estimated parameter vectors of SARB Review and Blitz Review are calculated, the result are as follows: SARB Review: . 1047esV Cost = , . 5esV Time = ,

. 3.9esV Quality =

Blitz Review: . 1274esV Cost = , . 2esV Time = ,

. 2.5esV Quality = Step 4: The user ultimately chooses SARB Review due to his preference on quality. In execution time, the real data for estimated parameter vector are: Cost = 1100, Time = 5, Quality = 3.8 Step 5: Add the new data collected this time into historical data set and calibrate the estimator of SARB Review, which turns to be: Cost = 14.21*Size + 90.05*Complexity –162.66

Time = 0.06*Size + 1.49*Complexity + 4.96

Quality = -0.01*Size - 0.15*Complexity + 3.79 Till now, a complete application of quantitive context model has been finished. 5. Tool support

In PKUPM, we have added in process pattern supporting modules, which realize the experience management method based on quantitive context model mentioned in this paper. The overall architecture of PKUPM is shown below in Figure 1:

Figure 1.The overall architecture of PKUPM In PKUPM, the Project Plan module responsible for

making plan can access the Process Pattern Manager, which can choose proper process patterns from Process Pattern Base, utilize the value of estimated parameter vector in quantitive context models to assist the estimation in project plan, and build project plan skeleton based on the solution part of selected process patterns. Meanwhile, the Project Monitor module superintends the project execution, collects necessary data and stores it into Process Data Base during project

runtime. When the project is accomplished, the Experience Extractor module will access the data in Process Data Base to adjust the parameters of estimation operator in corresponding quantitive context models. 6. Conclusion

Process patterns can effectively organize software process. However, the adoption of a process pattern always depends on cost, time and other factors in a concrete program. The high engineering environment of software projects requires context information of process patterns to be as clear as possible, so that the decision makers can balance between the related restriction and make the best choice. Therefore, the quantitive context model and its application method are introduced to enhance the context information of process pattern, and they have also brought to realization in PKUPM.

As a kind of forecast information, the actual capability of quantitive context method highly depends on the estimator mentioned previously. Currently we adopt the classic multiple regression analysis model in statistics, and we will try to seek better substitutions in future. Relying on the cooperation with three Software Corporations in Kunming presently, we have already

Proceedings of the Sixth International Conference on Quality Software (QSIC'06)0-7695-2718-3/06 $20.00 © 2006

begun to amplify the process pattern mechanism and relative supporting tool we proposed in this paper. Collecting more effective process patterns through practice will be our major future work as well. 7. References [1] Paulk M.C., The Capability Maturity Model for Software. Software engineering project management, 2nd, Thayer, R.H., Los Alamitos, California, IEEE Computer Society Press, 1998, 48-59.. [2] Humphrey W.S., Managing the Software Process. Beijing. Tsinghua University Publishing House. 2002. [3] J. O. Coplien., A Generative Development-Process Pattem Language, Pattern Languages of Program Design, AddisonWesley Publishing Company, NewYork, pp. 183-237, 1995. [4] S. W. Ambler, Process Patterns: Building Large-Scale Systems Using Object Technology, CambridgeUniversity Press, New York, 1998. [5] S. W. Ambler, More Process Patterns: Delivering Large-Scale Systems Using Object Technology, Cambridge University Press, New York, 1999. [6] Heyuan Huang, and Shensheng Zhang, “Hierarchical process patterns: construct software processes in a stepwise way”, Systems, Man and Cybernetics, 2003. IEEE International Conference on Volume 2, 5-8 Oct. 2003 Page(s):1353 - 1358 vol.2 [7] Neil B. Harrison, “Patterns of Architecture Reviews”, ALR-2003-039, Avaya Labs [8] Lasse Harjumaa, Ilkka Tervonen, and Pekka Vuorio, “Improving Software Inspection Process with Patterns, Quality Software”, 2004. QSIC 2004. Proceedings. Fourth International Conference on 2004 Page(s):118 - 125 [9] Rikard Land, Ivica Crnkovi, and Stig Larsson, “Process Patterns for Software Systems In-house Integration and Merge–Experiences from Industry”, Software Engineering and Advanced Applications, 2005. 31st EUROMICRO Conference on 30 Aug.-3 Sept. 2005 Page(s):180 - 187 [10] Norman E.Fenton, and Shari Lawrence Pfleeger, Software Metrics: A Rigorous & Practical Approach, Beijing, Tsinghua University Publishing House, 2003. [11] Roger S. Pressman, Software Engineering: A Practitioner’s Approach, Fifth Edition. The McGraw-Hill Companies, Inc., 2001 [12] Boehm B.W, Software Engineering Economics, Prentice Hall, Englewood cliffs, NJ 1981. [13] Henry, S. and D. Kafura, “Software Structure Metrics Based on Information Flow”, IEEE Trans. Software Engineering, vol, SE-7, no.5, September 1981, pp. 510-518 [14] Jeffrey M.Wooldridge, Introductory Econometrics: A Modern Approach, South-Western College Pub, 2004.

Proceedings of the Sixth International Conference on Quality Software (QSIC'06)0-7695-2718-3/06 $20.00 © 2006