-
7/30/2019 Kes 2008 v4 Final
1/8
Petri net-based simulation and analysis of the software
development process
Gordan Topic1, Dragan Jevtic2 and Marijan Kunstic2
1 Ericsson Nikola Tesla d.d, Krapinska 45,
10000 Zagreb, Croatia, [email protected] Faculty of
electrical engineering and computing, Unska 3,
10000 Zagreb, Croatia, [email protected]
Abstract. This paper explores improvements which can be achieved
by
applying Petri nets to the modeling, simulation and analysis of
the software
development process. The huge complexity of this process, in
conjunction with
the demand for rapid reaction to market pressure, hard limits on
time and cost,
and the fluidity of human resource organization can make it
considerably
difficult to establish a confident software development process.
Simulations of
such processes using Petri net models show considerable benefits
with respect
to real factors such as resource requirements, representation of
critical borders,
the effects of resource deficit, delays in process phases,
etc.
Keywords: software development, process modeling, colored Petri
net
1 Introduction
Software development is a complex process, which requires
precise planning and
realization to meet specific requests. A large portion of
software development belongs
to the telecommunications sector in which specific software
components, which can
be broadly dispersed, act together to deliver a requested
service.
However, software is like a living being, continuously absorbing
good and bad
characteristics from its creators, particularly the
organizational skills and competences
of the development team. Furthermore, it does not tolerate
forced development, e.g.
urgent delivery. Good and high quality software is a reflection
of a competent,
organized and satisfied team. Thus, it seems reasonable to
invest effort into quality
assurance. At times, a manager must react quickly to satisfy
changing marketdemands. However, manufacturing and business
processes require an optimal time
plan, adjusted to specific conditions. It is often necessary to
predict the time required
for software development, together with team proportions, while
maintaining high
quality of the software product. Various methods to discover the
process dynamics
have been proposed mostly based on modeling and simulation. In
this paper, we
present an approach to software development process (SWDP)
modelling, simulation
and analysis using Colored Petri Nets (CPN). Potential benefits
lie in process design
-
7/30/2019 Kes 2008 v4 Final
2/8
and analysis, and in organizational improvements prior to the
SWDP and during its
various phases.
The software development process based on the waterfall model
frequently used in
telecommunication industry is described in section 2. A model of
the SWDP realized
using colored Petri nets, along with a short review of Petri
nets is given in section 3.
Results of simulation experiments and process analysis are
elaborated upon in section
4, followed by a conclusion.
2 The Software Development Process
Complex information systems as manufactured goods require a high
organizational
level for software development. In practice, small companies
habitually considerdirect writing of program code in their software
development. However, real software
development implies much more and high quality software
development requires a
high level of business organization and sometimes very complex
processes of
software production.
2.1 Phases of Software Development
The Waterfall model is document-driven where each step yields
artifacts in the form
of documents. According to the waterfall model of the SWDP [3],
a simplified SWDP
can be defined as a business process consisting of four phases.
The first phase is
analysis. The analysis phase starts with gathering requirements
into an input
document for the SWDP. It consists of an exact definition of the
customer or clientrequirements for the requested software. The
start of this phase is marked by a
decision point, or so-called tollgate, labeled as TG0 (Fig.
1).
Fig. 1. A rough representation of the SWDP depicted in four
phases with sub-processes.
This phase terminates with tollgate TG2, where a major decision
must be made
according to the progress of this phase. The decision can be
based on the results of
requirement analysis, costs estimation and/or a system study,
i.e. in sub-processes of
this phase. If the progress of the SWDP is satisfactory, the
next phase, called the
-
7/30/2019 Kes 2008 v4 Final
3/8
design phase, begins. In this phase, the requirements are
decomposed and broadly
analyzed by performing taskplanning, moduledesign, coding and
basic testing (fig.
1). The results are program units, i.e. software modules. The
design phase terminates
by concurrent execution of encoding and basic tests for all
software modules. The
next control point, the Milestone labeled MS3, marks the
beginning of the testing
phase. Software modules have to be tested in a simulated
functional environment,
along with the related hardware, which is commonly developed as
a parallel activity
[1]. Tollgate TG4 marks the start of the delivery phase of the
SWDP, which
encompass different final activities, such as product packing,
creating an install
shield, writing user documentation and quality reporting (Fig.
1). The last part of the
SWDP is marked by tollgate TG5. The main phases of the SWDP
follow the
arrangement shown in fig. 1 in theory. However, many of these
process activities are
of concurrent nature, i.e. are executed in parallel with various
interconnections.
2.2 Organization, structure and documentation
The SWDP incorporates a well-organized project structure, which
must be skillfully
managed according to human resource potential. This section
describes the
organization and layered structure of the SWDP, which we
modeled, simulated and
analyzed using the CPN model.
Three management levels exist in the SWDP hierarchy, each of
which provides a
corresponding document. The highest level of the management
structure consists of
managers who care about the fluent flow of software development.
This team is
comprised of aproject manager and a software quality manager.
The project manager
manages the entire project team and determines the job dynamics
according topredefined objectives. The software quality manager is
responsible for monitoring and
predicting the quality of the product, as well as maintaining
and improving the
development process.
A system analystis a highly competent person with adequate
experience, placed in-
between the high and low levels of the management hierarchy. His
knowledge of
hardware and software systems must be broad enough to perform
sub-process system
analysis (fig. 1) and to create hardware and software
specifications.
Finally, the lowest level of the management team consists of
technical managers,
which are responsible for the technical characteristics of
product realization. These
include configuration and testing performed by software
architects and hardware
engineers. Their practical knowledge is joined with some special
branches depending
on the needs of the SWDP, such as design, testing, hardware
engineering, etc. Their
activity is mainly focused on the specification of product
functionality.After inspecting software documents during the
analysis phase, software architects
create an implementation proposal document, while hardware
engineers perform the
same task on the hardware side. Software and hardware
implementations appear in the
documentation as a specification of its functionalities. The
configuration manager
prepares a configuration plan, while the test manager writes a
test plan prerequisite
for system testing and functionality verification. As mentioned
earlier, in each sub-
process activity, the responsible person creates the specific
documentation.
-
7/30/2019 Kes 2008 v4 Final
4/8
3 Software development modeling and simulation using Petri
nets
Modeling business processes provides clear descriptions and
better understanding of
complex processing phenomena. Process modeling and simulation
have been
previously used for various process solution estimations,
selection of the most
suitable cases and resource optimization. A simulation model of
the SWDP is an
approximate description of a real process or a system of
processes. In general,
simulation of a model allows for a quantitative analysis and
gives answers to "what-
if" questions. The SWDP is composed of a large number of
interconnected elements,
where human resources carry out the essential functions. The
focus of our simulations
was the usage of human resources and their relation to process
dynamics.
3.1 A short review of Petri net models
A Petri net is a mathematical representation of a discrete
distributed system. As a
modeling language, it graphically depicts the structure of a
distributed system as a
directed bipartite graph with annotations. A Petri net consists
of places, transitions,
and directed arcs. Arcs run between places and transitions.
Places may contain any
number of tokens. Execution of Petri nets is non-deterministic,
i.e., multiple
transitions can be enabled at the same time, making Petri nets
well-suited for
modeling the concurrent behavior of distributed systems [2,
5].
The formal definition of a Petri net describe it as a 5-tuple (
S, T, F, M0, W), where:
S, TandFare the set of places, transitions, and directed arcs,
respectively. Set F is subject to the constraint that no arc may
connect two places or two
transitions, or more formally: F (ST) (TS) M0 : S is an initial
marking, where for each places S, there are ns
tokens.
W:F+ is a set of arc weights, which assigns to each arcf F
somen+ denoting how many tokens are consumed from a place by a
transition,
or alternatively, how many tokens are produced by a transition
and put into
each place.
Colored Petri nets are a high-level extension of basic Petri
nets which support
hierarchical structuring, timed transition executions, and where
every token has a
value. Token interaction must be defined and associated to each
transition. Each token
can carry a time stamp denoting the time at which the token is
ready. A hierarchical
process structure can be constructed by substitution transitions
of so-called sockets
and ports interconnecting the Petri net on a lower level for
that transition. Fusionplaces are level independent. Once created,
a fusion place interconnects related Petri
nets on different levels. These properties annotate CPN as an
appropriate model for
systems in which communication, synchronization and resource
sharing are
fundamental [4].
-
7/30/2019 Kes 2008 v4 Final
5/8
3.2 A CPN model of the development process
Our CPN model of the SWDP has a hierarchical structure created
from a total of 19
colored Petri nets which are arranged to correspond to the SWDP
hierarchy in three
levels: level 1 is entitled theprocess level, level 2 the
sub-processlevel and level 3 the
operative level (Fig. 2). Each lower level is composed as set of
Petri subnets. Subnets
on level 2 are driven by and connected to their unique
substitution transitions from the
upper level. In reality, the execution of a substitution
transition on level 1 activates
the execution of a subnet on level 2 and then returns to level
1. Analogously, the part
of the transition set on level 2 is exchanged by subnets from
level 3. Generally, each
substitution transition is based on the Petri net of a lower
level. The global
hierarchical model is illustrated in fig. 2.
In our SWDP model, we used a timed CPN consisting of 120 places,
of which 25
fusion and 41 socket places. The model contained 74 transitions,
of which 18
substitution transitions were included. The number of simple
colors declared was 4: 2
compound and 2 colors with time dimension. The total number of
variables that
support token movement was 10.
Fig. 2. An illustration of the applied CPN model structure for
the SWDP arranged in three
levels.
The simulation model was constructed to provide information
regarding human
resource allocation, which can be defined as a certain number of
team members
allocated in 9 different project roles. Changing the initial
conditions in the CPN
model corresponds to a change in the number of team members in
the SWDP. The
initial conditions of the simulation model are variables for
project specifications,
human resources, project documentation, auxiliary and time
variables for different
process phases. Many simulations were performed by changing the
initial conditions
-
7/30/2019 Kes 2008 v4 Final
6/8
of the CPN model, which manifested in results containing
different numbers of
members in the project team.
3.3 Process modeling and data gathering
Modeling and simulation using the CPN model can, in general, be
used for process
learning, performance improvement and cost reduction in the
SWDP. Our simulations
were focused on the optimization of human resources subject to
certain financial and
time constraints.
The most complicated part of process modeling is gathering the
data needed for the
simulation. Our data sources were derived and collected from
project documentation,
quality measuring results, observation and measurements of
process activities, and
from own experiences as project team members from other parallel
or finished
projects. The project and time plans, role, and process
description documents can
provide enough information for fundamental estimation. However,
additional
information must be collected and extracted from quality
measurement records and
through empirical approaches.
4 Results of simulation experiments
As mentioned earlier, documentation in the SWDP was used for
transferring
knowledge from an idea to a real software product. The SWDP
described in this
paper, operates with 22 different project documents. The
expected benefit of our
simulation was to discover the time and cost function for the
modeled processregarding human resource usage, which we consider
the most important factor in the
SWDP. The target was to determine the bordering cases for which
project
requirements could be satisfactorily managed. The SWDP was
defined as a project
with the following limitations:
- Project duration for the SWDP could not exceed 2.000 hours, i.
e. approximatelyone year.
- The cost could not exceed a value of 40.000 man/hours, with
minimum usage ofhuman resources.
Process modeling and simulation were performed by CPNtools [4].
Initial values of
the variables in the CPN represented team members corresponding
to the number of
designers and testers in the development team. A hundred
separate simulations were
performed with various initial input variables for designers and
testers. The total
number of members in the entire development team was defined as
the sum of the
designers, testers and other members that were recognized as
essential to the team. All
simulations resulted in a prediction of the amount of time
needed for project duration
and the effective time interval needed for software product
development.
The graphs in fig. 3 show the relation between project duration,
the number of
designers and testers, and the cost obtained via simulation. The
graph on the left
shows the solution space in which various numbers of team
members could complete
the project in the proposed time period. Considering the cost
criteria, i.e. a maximum
-
7/30/2019 Kes 2008 v4 Final
7/8
of 40.000 man/hours, significantly cuts the surface area and
additionally restricts the
number of project team members (represented by the white areas
on both diagrams in
Fig. 3). The acceptable parts of the surfaces in the graphs with
respect to the defined
project conditions are shown in white. The optimal number of
members was found for
the given structure of the SWDP. Namely, the optimal team
consisted of 25 members,
i. e. 9 designers, 9 testers and 7 mandatory members, such as
quality managers, which
appear in big projects.
Fig. 3. The graph on the left shows project duration, while the
graph on the right shows cost
estimation, both in relation to the number of designers and
testers in the development team.
Such a team could develop the requested software product
effectively during 1511 hand with minimal cost of 37 775 man/hours.
Based on this result, team member load
was calculated for all process roles, depicted in fig. 4.
According to the graph,
designers consume the largest part of total development time
(691,7 hours/man),
followed by testers (600,4 hours/man).
Fig. 4. Human resource time spent for different roles in the
SWDP.
The dynamics of time consumption over the SWDP phases is
depicted in fig.5. It
shows the time distribution from phase to phase, where the
increment between phases
represents amount of time used (Fig. 5). The most time, in this
case, was spent in the
testing phase.
-
7/30/2019 Kes 2008 v4 Final
8/8
Fig. 5. The diagram of time spent over process phases.
Additional simulations were performed in which the basic SWDP
model was
extended to represent tandem projects in order to utilize human
resources in periods
when human resources were without tasks in the current SWDP. It
proved beneficial
for total cost saving and increased job effectiveness. The
optimal solutions for the
SWDP applied to two parallel projects with the same human
resources resulted in up
to 24% reductions of cost and development time. However, they
increased single
development time for both projects.
5 Conclusion
Any business process can be realized and verified with an
equivalent Petri net model.
Thus, decision-making and management can be additionally
supported with
simulation and analysis of such models for SWDP pre-planning
and, moreover,during its phases. The main obstacle in process
modeling is finding apposite data in
advance, which may well represent the process entities for which
existing
requirements have to meet available resources. This can be, for
example, the amount
of time needed for an expert to solve the problem. On the other
hand, the simulation
results provide various allocations of SWDP resources, which
decision-makers and
management could consider as relevant selections for the
observed SWDP.
References
1. W. E. Perry, Effective Methods for Software Testing, Third
Edition, Published by John
Wiley & Sons, Inc., 2006.2. J. Desel and G. Juhs, "What Is a
Petri Net? Informal Answers for the Informed Reader",
Hartmut Ehrig et al. (Eds.): Unifying Petri Nets, LNCS 2128, pp.
1-25, 2001.
3. I. Jacobson, G. Booch, J. Rumbaugh, The Unified Software
Development Process,
Addison-Wesley, 1999.
4. K. Jensen, Coloured Petri Nets Basic Concepts, Analysis
Methods and Practical Use
Vol. 1 and Vol. 2, Springer, 1996.
5. J. L. Peterson, Petri net theory and the modeling of systems,
Prentice-Hall, 1981.
