Application of Generalized Stochastic Petri-net to Quantitative
Evaluation of Software Process
Osamu MIZUNO, Yuji HIRAYAMA, Shinji KUSUMOTO and Tohru KIKUNO
Department of Information and Computer Sciences,
Faculty of Engineering Science, Osaka University
1-3 Machikaneyama, Toyonaka, Osaka 560, Japan
E-mail: o-mizuno@ics.es.osaka-u.ac.jp

1. Introduction

As the complexity and size of software increase, project
management becomes important to develop reliable software cost-e ectively within speci ed time constraints.
In order to manage a software project e ectively, it isnecessary to establish a control method based on the objective and quantitative evaluation data on the current
status of the software project.
We have already presented quantitative evaluations of
the software development process described by Generalized Stochastic Petri-net (GSPN)[3]. However, the evaluations in [3] cannot deal with the development periodsuciently because of restrictions on the GSPN model.
This paper de nes a new hierarchical model for software project by extending the previous GSPN modeland by introducing the concept of \workload", and proposes a method to evaluate the software process fromthe viewpoints of the quality, cost and delivery date.
As the result, the new model can take the in uence ofhuman factors into account, and thus can evaluate thedynamic aspect of software project. Finally, the resultsof the case study of the proposed method provide us withsome implications on software project management.
2. Fundamental Model

2.1 Extended GSPN [3]

A Petri-net is one of the most powerful models for representing and analyzing concurrent processes such as thoseoccurring in software development process. A stochastic
Petri-net is an extended model of a Petri-net by incorporating timing information. It has two types of transitions: timed transition and immediate transition. An
immediate transition is the transition whose ring delay
is zero. A timed transition needs speci ed time to re.
Marsan et al. have proposed a generalized stochastic
Petri-net (GSPN) [8] whose transition has exponential
distributed ring rate. A GSPN has been used extensively to model and analyze dynamic behaviors of systems and software processes. However, a GSPN cannot totally evaluate the important factors of software
project.
So, we have extended a GSPN in order to quantitatively evaluate software processes from the viewpointsof quality, cost and delivery. In the extended GSPN,
a token has some attributes, which are useful for activity evaluation. Additionally, each transition of theextended GSPN has an execution function which is evaluated in time of ring. The value of each attribute of thetoken is updated by evaluating the execution functions.
2.2 Problems of extended GSPN

The extended GSPN model[3] did not include the following factors which a ect the behaviors of the developers:
1. Communication overheads
Communication
overheads are recognized to be serious in the software development. For example, it is impossible for
one thousand developers to complete the software
in a month that completed for one thousand manmonths[1]. The major reason is that the increaseof developers induces the increase of overheads forcommunications among the developers.
2. Di erence of experience The capability of eachdeveloper is strongly related to the productivity
and quality of software. It is reported that there arelarge individual di erences in programming performance and developers with high performance tend
to develop programs with fewer faults[9][11].
3. Confusion by incompletenessThe design andcoding activities mainly include translation workfrom input products into output products. For example, the coding activity is described as translation work from the design speci cations into thesource code. In such translation activities, if there
are some omissions of required description on the
input products, it needs corresponding inquiries,
and then communication overheads increase[2].
4. Stress by delivery date Usually, a delivery dateor a deadline is xed for each activity on the development plan. As the deadline closes in, stress ondevelopers gets serious and could a ect their performance negatively. It is reported that stress causedby the deadlines or short development time incurs
the high incidence of errors and faults[4].
111

111

111

111

In a practical development, since these factors change
the development period dynamically, it is very dicultto estimate the period precisely. The method in [3] simpli es the estimation by assuming that the value of thedevelopment period always becomes constant. Thus theperiod cannot be evaluated suciently in the previous
model.
3. Key Idea of Solution

In order to solve the problems, this paper proposes a
new concept of \workload" which describes uctuationof the development period and the product size. Next,
three factors: developers' experience level, completion
rate of products and deadline for activities, are incorporated to take the dynamic in uence of human factors
into account. (About these factors, subsection 4.1 will
describe in detail.)
Generally speaking, an e ort is used to measure theamount of the activity. But, the e ort doesn't become
clear until the activity is over, and thus the e ort is
not suitable to determine the amount of uncompleted
activity. Additionally, the e ort includes not only theamount of work needed for purely execution of the activity, but also the amount of communication among thedevelopers.
For example, let us consider an activity of 10 mandays. Even if this activity is performed by a developerin 10 days, it could not be performed by 10 developers
in a day. One of the main reasons is that time to communicate among the developers increases as the numberof developers increases.
Here, we newly de ne the term \workload" of an activity as the total time needed for a developer who has
the standard capability to complete the activity. Additionally, the eciency of the activity under such a condition is quanti ed as 1. The value of eciency depends
on the environment, such as the number of the developers, the necessity of communication and performance of
CASE tools. Then, the development time is calculated
as the result of dividing the workload by the eciencyof the activity.
Example 1 Now we consider the following two casesof an activity whose workload is 20 hours.
Case 1: Two developers, with the standard capability
execute the activity and ten percent of the total development time is spent for communication.
the activity for 10 hours, then the attained workload becomes 18 (=10 2 0.9).
2 2

Case 2: Four developers, with the standard capability,
execute the activity and twenty percent of the total
development time is spent for communication.
For this case, if each developer takes part in
the activity for 5 hours, then the attained workload
becomes 16 (=5 4 0.8).
2 2

In the proposed model, the workload is assigned toeach activity depending on the input products for theactivity. For example, for the coding activity, the larger
the size of design speci cations, the larger workload is
assigned. For the debug activity, the more the number offaults contained in input products, the larger workload
is assigned. Consuming of the workload assigned to an
activity corresponds to the progress of the activity inthe development. Growth of product can be modeled bychanging the values of the size or the number of faults
in the output product.
4. New Hierarchical Model

The proposed model is a hierarchical model which consists of Project Model and Process Model. Figure 1
shows the outline of the hierarchical model.
Project model includes three key components: activities, developers and products. Some attributes are attached to each of them.
Process model includes a set of activity models which
include speci cations of design, coding, review, test, debug activities, and so on. Activity model is describedby an extended GSPN.

AAAAAAAAAAAAA
AAAAAAAAAAAAA
AAAAAAAAAAAAA
AAAAAAAAAAAAA
AAAAAAAAAAAAA
AAAAAAAAAAAAA
AAAAAAAAAAAAA
AAAAAAAAAAAAA
AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAA
Project model

activities{A i}developers{M i}products{P i}deliverfiring rates oftransitions

updateattribute values

model fordesign,coding and debug

r1

r2

r3

r4

r5

r6

r7

model forreview and test

Process model

Figure 1: Outline of hierarchical model
4.1 Project model

Project model focuses on three key components: activities, products and developers, and attaches several attributes to each of them. (See Table 1)
An activity has eight kinds of attributes, which are
type, entry/exit condition, input/output product, workforce, deadline and workload. (1) Type shows the type of
the activity, such as design, coding, review, test, debug
and so on. (2) Entry condition and (3) exit condition
specify conditions for beginning and ending the activity,

Table 1: Project template
Attributes of activity Aitype
entry condition
exit condition
input productoutput productworkforce
deadline
workload

Attributes of product P

isize
number of faults
completion rate

Attribute of developer Miexperience level

respectively. (4) Input product describes a set of products given to the activity as the input products and thedegree to which each of input products a ects the determination of workload assigned to the activity as tuples.
(5)Output product describes a set of output products developed in the activity and the weight assigned to eachof the products. The variations of product size and number of faults are distributed to the products according
to each weight. Thus, the sum of each weight is required
to be one. (6) Workforce speci es the developers who
engage in the activity and the ratio of time in which
each of developers can engage in the activity to his or
her business hours as tuples. (7) Deadline represents theappointed date for the completion of the activity xed
on the development plan. (8) Workload represents theworkload assigned to the activity and consumed amountof it as a tuple.
A product has three kinds of attributes, which aresize, the number of faults and completion rate. (1) Size
represents the product size in document pages or thelines of source code. (2) Number of faults counts faults inthe product. (3) Completion rate represents the extent
to which omissions or obscurities are excluded from theproduct as a rate.
A developer has an attribute experience level which isdetermined according to his/her length of service. We
classify developers' experience levels into the following
three levels: novice, standard and expert level. They
are quanti ed as discrete values 1, 2 and 3, respectively.
Example 2 Table 2 shows an example of Project model

description. This project is composed of ve activities(A1 ; ; A5 ), seven products and three developers. Notethat workloads of activities A1 ; ; A5 and attributesof all products except for initial input product P0 are
determined during the execution of the model. Thus,
they are not yet speci ed in Table 2.
Parallel execution of several activities can easily bede ned by utilizing both entry condition of activity andcompletion rate of product. For example of the parallel
execution, refer to [6].
111

111

4.2 Activity model

Activity model is prepared for each type of activities
such as design, coding, review, test and debug. The descriptions of Activity models are given using extended
GSPN. Figure 2 shows the description of the design activity. In the extended GSPN, a token has three attributes: product size s, the number of faults f andconsumed workload w. These attributes are used torepresent the current status of development that varies
over the execution of each activity model.
Each transition corresponds to the developers' behavior such as thinking, writing and communicating or
event which occurs during an activity. Places correspond to waiting states for occurrences of behaviors or
events.
In addition, each transition has a function (called execution function) to be evaluated on its ring. The execution of the functions updates the attribute values of
the token.
Example 3 Figure 2 shows a description of the design activity. Here, we consider three kinds of developers' behaviors in the design activity: communicating
among developers, thinking needed for problems solution and writing for putting down the solution in documents. Transitions t1 , t2 and t3 in Figure 2 correspondto communicating, thinking and writing, and are given
the ring rates rcm ; rth and rwr , respectively. The ringrate rcm of transition t1 means that the average ring
delay of transition t1 is 1=rcm .
attributes of tokens product size
f number of faults
w consumed workloadt 1 rcmt2

r th

t3 rwrP2

P1
transition

t1

executionfunction

-

t3
s=s+1
w=w+1 f = f + 1
t2(with rate pin)

Figure 2: Design activity model
4.3 Firing rate of transitions

The ring rates of the transitions are formulated by thefollowing ten functions fcm , fth , fwr , fpr , frd , fdt , fmd ,fps , flc and fin . These functions should be concretely
speci ed based on the property of the target project.
In the following, M is the number of developers engaged in the activity, L is the developer's experiencelevel, 6L is the sum of each developer's experience, S
is the total size of the input products, R is the completion rate of the input products, F is the number offaults of the input products, D is the number of thedays from the current date to the deadline of the activity. Kcm ; Kth ; Kwr and Kin are parameters given toeach activity and concerned with communicating, thinking, writing and fault injection rate, respectively.
(1) Communicating rate rcm
rcm = fcm (M; L; R)(2) Thinking rate rth
rth = fth (M; L)(3) Writing rate rwr
rwr = fwr (M; L)(4) Preparing rate rpr
rpr = fpr (M; L; S )(5) Reading rate rrd
rrd = frd (M; L)(6) Fault detecting rate rdt
rdt = fdt (M; L; S; F )(7) Fault modifying rate rmd
rmd = fmd (M; L)(8) Testcase passing rate rps
rps = fps (M )(9) Fault localizing rate rlc
rlc = flc (M; L; S; F )Here, we will explain the functions used in the designand coding activity. Functions fcm; fth and fwr makeit possible to dynamically determine the frequency ofcommunications or the diculty in thinking and writing according to the number of developers and the experience levels of developers or completion rates of input
products.
Example 4 In the design activity, rcm is concretely

formulated as follows.

M2
rcm = Kcm 2
6L 2 R

Next, rth and rwr are concretely formulated as follows.
6L M = K 6L
r =K
th

th 2

rwr = Kwr 2

M

6L

2

th 2

2 M = Kwr 2 6L
M
On the other hand, rcm; rpr ; rrd ; rdt and rmd are usedin the review activity, rcm ; rpr ; rps; rdt and rwr are usedin the test activity and rcm ; rlc and rmd are used in the

debug activity.

4.4 E ects of transition ring

Activity model handles fault injections in the design activity as the stochastic events whose occurrences depend
on fault injection rate pin. In general, pin is formulatedby the following function:(10) Fault injection rate pin
pin = fin (M; L; R; D)
Example 5 In the design activity, pin is concretely
formulated as follows.
pin = Kin 2

M
2 M
LRD

By using this function, it is possible to take accountof dynamic in uence on the fault injection rate causedby the deadline of the activity or developers' experiencelevels.
Moreover, the increases of product size at every ring of writing transition and consumption of workload
at every ring of thinking transition are described by
the corresponding execution functions. At each ringof transition, the values of token's attributes can bechanged by evaluating its execution function.
Example 6 In the design activity model depicted in

Figure 2, for example, transitions t1 and t2 which represent communicating and thinking, respectively, can rewhen a token exists in place P1 . If communicating transition t1 res, it has no e ect on the attributes values,
and the token returns to place P1 and just time corresponding to the ring delay elapses.
If transition t2 res, by evaluating its execution function, consumed workload w increases by one, and thetoken moves to place P2 . When the token exist in place
P2 , only transition t3 which represents writing behavior
is enable. If transition t3 res, product size s increaseby one, and the number of faults f could increase according to fault injection rate pin. After the ring of t3 ,the token moves back to place P1 .
5. Execution of Model

The development process speci ed by the hierarchicalmodel is carried out by repeating the interactions between Project model and Activity models. In this section, we explain how this hierarchical model is carriedout.
Example 7 We apply the proposed model to the soft-

ware development process shown in Figure 3. Here, we
explain the execution of the model by using Activity A7 .
Activity A7 is the module design activity. Activity A7
is executed until it consumes all the assigned workload.
Now, assume that the execution of A7 has completed on
the 59th day. The assigned and consumed workload of
A7 are 172 and 117, respectively. The input and output
product of A7 are P4 and P7 , respectively.

On the 60th day, the following three steps are carriedout:
Step 1. Based on the the values of the attributes of theactivity, products and developers, Project model computes the ring rates of transitions of Activity models.
In this case, project model sets the values of Kcm ; Kthand Kwr as 0:1; 0:2 and 0:2, respectively. In Figure 4(a),the ring rate of A7 is calculated as follows:
12 = 0:10
rcm = Kcm
1 1
rth = Kth 1 = 0:20
rwr = Kwr 1 = 0:20
Step 2. Project model delivers the ring rates to thecorresponding Activity model (GSPN model), and thenProcess model executes the model. In Figure 4(b), a design activity model is executed by Process model withthe speci ed ring rate rcm ; rth and rwr . The GSPN
computes the current size of product(= 3) and consumed workload(= 8).
Step 3. Process model returns the execution results
to Project model. Then Project model updates relevant
attributes of activities and products based on the returned results. In Figure 4(c), at the end of the 60thday, consumed workload of A7 becomes 125, and thesize of P7 becomes 34.
22

2

of workload and by taking the in uence of human factor into account, it is possible to evaluate the dynamic
aspect of software project.
Experimental evaluations of the model by applying
real software development data are currently underinvestigation[5].
Acknowledgement

The authors would like to thank Professor Ichiro
Suzuki of the University of Wisconsin at Milwaukee forhis careful reading of the earlier version of this paperand helpful comments.

2

AAA
AAAAAAA
AAA
AA
AA
AAA
AA
AA
AAAAA AA
AAA
AAA
AA
AA
AAAAA AAAAA
AAA
AAA
AA
AA
AAA
AAA
AA
AA
AAA
AAA
AA
AA
AAA
AAA
AA
AA
AAA
AAAAA
AA AA
AA
AA AA
AA
AAAAAAA
AAAAA
AAA
Figure 3: Development process ow

Concept design

A1

Function design

A2

A3

Structure design

A4

A5

A6

Module design

A7

A8

A9

A 10

Coding

A11

A 12

A 13

A 14

Unit test

A15

A 16

A 17

A 18

Unit debug

A 19

A 20

A 21

A 22

Integration test

A 23

A 24

A25

Integration debug

A 26

A 27

A 28

Function test

A 29

A 30

Function debug

A 31

A 32

Verification test

A 33

Verification debug

A 34

6. Conclusion

This paper has proposed a new hierarchical model forsoftware project which can evaluate the software processfrom the viewpoints of the quality, cost and development
period. In the new model, by introducing the concept

References[1] Brooks F. P., Jr.: The Mythical Man-Month,
Addison-Wesley (1975).
[2] Curtis B., Krasner H. and Iscoe N.: \A eld
study of the software design process for large
systems", Communications of the ACM, Vol.31,
No.11, pp.1268-1287 (1988).
[3] Furusawa K. et al.:\Modeling and quantitativeevaluation of software process based on a Generalized Stochastic Petri-net", Proc. of 15th Software Reliability Symposium, pp.99-104 (1994)(inJapanese).
[4] Furuyama T., Arai Y. and Iio K.: \Fault generation model and mental stress e ect analysis", The
Journal of Systems and Software, Vol.26, pp.3142 (1994).
[5] Hirayama Y. et al.:\Hierarchical project management model based on quantitative evaluation ofsoftware process", Technical Report of IEICE.
FTS95-74 (1995-12)(in Japanese).
[6] Hirayama Y., Mizuno O., Kusumoto S. andKikuno T.: \Hierarchical project management
model for quantitative evaluation of software process", Proc. of the International Symposium on
Software Engineering for the Next Generation,
pp.40-49 (1996).
[7] Lee G. and Murata T.: \A -distributed stochastic Petri net model for software project time/cost
management", The Journal of Systems and Software,Vol.26, No.2, pp.149-165 (1994).
[8] Marsan A., Conte G. and Balbo G.: \A classof generalized stochastic Petri nets for the performance evaluation of multiprocessor systems",
ACM Transactions on Computer System, Vol.2,
No.2, pp.93-122 (1984).

AAAAAAAAAAAAAAAAA
Project Model
AAAAAAAAAAAAAAAAA
design activity A
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAAA
M
AAAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAA
model forAAAAAAAAAAAAAAAAAA
design,coding and debugr
AAAAAAAAAAAAAAAAAArr
AAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAArrr
AAAAAAAAAAAAAAAAAArmodel forAAAAAAAAAAAAAAAAAA
review and test
AAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAA
7
executing
7 workload =117/172

4

size = 43
c.rate = 1.0
size = 31
7 c.rate = 1.0

1 e.level = 1

1

2

3

Project Model
AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAA
M
P
firingAAAAAAAAAAAAAAAAA
rates
(A )
AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAA
executingworkload =117/172

7

1

7

7

deliver

design activity model
rcm = 0.10
rth = 0.20 r

wr = 0.20

45Process Model(a) Step 1

6

7

Token

s=3
w=8
Process Model(b) Step 2

Figure 4: Execution on the 60th day[9] Matsumoto K., Kusumoto S., Kikuno T. andTorii K.: \An experimental evaluation of term
performance in program development basedon model { Extension of programmer performance model", Journal of Information Processing, Vol.15, No.3, pp.466-473 (1992).
[10] Ra o D. M.: \Evaluating the impact of process
improvements quantitatively using process modeling", Proc. of CASCON93, Vol.1, pp.290-313(1993).
[11] Sackman H., Erickson W. J. and Grant E. E.:\Exploratory experimental studies comparing online and oine programming performance", Communications of the ACM, Vol.11, No.1, pp.3-11(1968).
[12] Tvedt J. D. and Collofello J. S.: \Evaluating
the e ectiveness of process improvements on software development cycle time via system dynamics modeling", Proc. of COMPSAC95, pp.318-325(1995).

Project Model
AAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAMP
AAAAAAAAAAAAAAAAAA
execution
results (A )AAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAA
design activity model
AAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAr
AAAAAAAAAAAAAAAAAAr
AAAAAAAAAAAAAAAAAAr
AAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAA
Process Model
AAAAAAAAAAAAAAAAAA
7

executingworkload = 125/172

size = 34

1

7

7

updatecmth(c) Step 3

wrTable 2: Example of project description
A1

type
entry c.
exit c.
input p.
output p.
workforce
deadline
A2

type
entry c.
exit c.
input p.
output p.
workforce
deadlineA3

type
entry c.
exit c.
input p.
output p.
workforce
deadlineA4

type
entry c.
exit c.
input p.
output p.
workforce
deadlineA5

type
entry c.
exit c.
input p.
output p.
workforce
deadline
P0

size
fault
c. rateM1

e. levelM2

e. levelM3

e. levelFD(A1 ,non-executed)(A1 ,consumed)(P0 ; 7:0)
(P1 ; 0:3); (P2 ; 0:5); (P3 ; 0:2)
(M1 ; 1:0)
20
PG
(A1 ,done)(A2 ,consumed)(P1 ; 1:2)
(P4 ; 1:0)
(M2 ; 1:0); (M3 ; 1:0)35
PG
(A1 ,done)(A3 ,consumed)(P2 ; 1:1)
(P5 ; 1:0)
(M1 ; 1:0)35
FT(A2 ,done), (A3 ,done)(A4 ,consumed)(P3 ; 2:0); (P4 ; 0:2); (P5 ; 0:25)(P6 ; 1:0)
(M2 ; 1:0)60
FTD
(A4 ,running)(A4 ,done),(A5 ,consumed)(P6 ; 2:4)
(P4 ; 0:45); (P5 ; 0:55)(M1 ; 1:0); (M3 ; 1:0)
65
8
0
1.0
3
2
1