osim03_rus_2.pdf. It's a snapshot of the page taken as our search engine crawled the Web.
The web site itself may have changed. You can check the current page or check for previous versions at the Internet Archive. Yahoo! is not affiliated with the authors of this page or responsible for its content.
A Systematic Methodology for Developing Discrete Event Simulation Models of Software Development Processes




Abstract So far there have been several efforts for
developing software process simulators. However, the
approaches for developing the simulators seem to have been ad-
hoc and no systematic methodology exists. Since modeling and
simulation in support of software development should become
more popular (and there are signs that it does), there is a need
for migrating modeling from craft to engineering. This article
proposes such a systematic method, focused on the development
of discrete simulation-based decision models, but extensible to
other modeling approaches as well.

Keywords Software process modeling and simulation, quality
assurance, process model and simulation method and
engineering, discrete event modeling.

I. I
NTRODUCTION

ost publications that describe simulation models for
software development processes do not address the
process followed for developing these models. That
leads us to believe that they are developed ad-hoc, in isolation,
many from scratch, and that there are no systematic and
documented ways of developing them. For system dynamics
models, some authors describe their approach for developing
the models [4][6]. For discrete event models, no process has
been published that describes the development of such a
model.
Reflecting on how a software process simulator has been
developed and sharing this process with other model
developers is very valuable, as it allows approaching
simulation in a systematic manner and provides guidance and
support to the modeling community. The application of such a
methodology will enhance the quality of the resulting model
(including its reusability and maintainability) and will reduce
development effort and duration.
In this article we present a method for systematically
developing discrete event simulation models for software

Ioana Rus is with the Fraunhofer Center for Experimental Software
Engineering, College Park, MD, 20740, USA (corresponding author's phone:
301-403-8971; fax: 301-403-8976; e-mail: irus@fc-md.umd.edu).
Holger Neu is with the Fraunhofer Institute Experimental Software
Engineering (IESE), Sauerwiesen 6, 67661 Kaiserslautern, Germany (e-mail:
Holger.Neu@iese.fraunhofer.de).
Jürgen Münch is with the Fraunhofer Institute for Experimental Software
Engineering (IESE) in Kaiserslautern, Germany (e-mail:
muench@iese.fraunhofer.de).

development processes, which is derived from the authors
collective experience from building a few simulators.
We focus on describing the development process of a
discrete event simulator, but this can easily be applied to
different modeling approaches. For identifying and describing
the modeling process, we suggest applying practices and
principles from software engineering.
The intended audience for this article is the modeling and
simulation community of practice.
This article is organized as follows: Section II presents the
activities of the proposed method. For each of the activities,
we will present a description and will illustrate it with
examples from our own work. Section III contains a summary
and conclusions, and Section IV highlights directions for
future work.
II. P
ROPOSED METHOD

This method considers the development of a new simulation
model without reusing or incorporating existing components.
If reuse is considered (either incorporating existing
components or developing for reuse), then the method has to
be changed to address possible reuse of elements.
We believe that the life cycle of a simulation model for
long-term use is similar to the one of software, consisting of
three main phases: development, deployment, and operation,
including maintenance and evolution (after all, a simulation
model is a software product, too). The activities within these
phases can have different time order and dependencies,
therefore, the resulting life cycle can take on different forms,
such as waterfall, iterative, or even agile.
The activities throughout the life cycle can be divided in
two categories: engineering and management activities. Since
most of our experience is related to the development phase of
a simulator, this is what we will focus on in this article.
The engineering activities for model development are:
Requirements identification and specification for the
model to be built;
Analysis and specification of the modeled process;
Design of the model;
Implementation of the model;
Verification and validation throughout development.


The management activities are:
A Systematic Methodology for Developing
Discrete Event Simulation Models of Software
Development Processes
Ioana Rus, Holger Neu, and Jürgen Münch
M


Model development planning and tracking;
Measurement of the model and of the model
development process;
Risk management refers to identification and
tracking of risk factors, and mitigation of their
effects. Some of the risk factors are: changes in
customers requirements, changes in the description
of the modeled process, non-availability of data for
the quantitative part of the model.

During the life cycle of a simulation model, different roles
are involved. In the development phase, mainly the model
developer and the customer are involved. We did pair
modeling for creating the first version of the static process
model and influence diagram. This seems very useful because
the discussion about the model and the influences is very
inspiring.
A. Simulator requirements identification and specification
During the requirements activity, the purpose and the usage
of the model have to be defined. According to this, the
questions that the model will have to answer are determined
and so is the data that will be needed in order to answer these
questions. Sub-activities of the requirements specification are:

1) Definition of the goals, questions, and the necessary
metrics
A goal-question-metrics-(GQM) [1][3] based approach for
defining the goal and the needed measures seems appropriate.
GQM can also be used to define and start an initial
measurement program if needed.
The purpose, scope and level of detail for the model is
described by the goal. The questions that the model should
help to answer are formulated next. Afterwards, parameters
(metrics) of the model (outputs) have to be defined that (once
their value is known) will answer the questions. Then the
model input parameters have to be defined, which are
necessary for determining the output values. The input
parameters should not be considered as final after the
requirements phase; during the analysis phase they will
usually change.

2) Definition of usage scenarios
Define scenarios (use cases) for using the model. For
example, for answering the question: How does the
effectiveness of inspections affect the cost and schedule of the
project?, a corresponding scenario would be: All input
parameters are kept constant and the parameter inspection
effectiveness is given x different values between (min, max).
The simulator is executed until a certain value for the number
of defects per KLOC is achieved, and the values for cost and
duration are examined for each of the cases.
For traceability purpose, scenarios should be tracked to the
questions they answer (for example, by using a matrix).
3) Development of test cases
Test cases can be developed in the requirements phase.
They help to verify and validate the model and resulting
simulation.

4) Validation of requirements
The customer has to be involved in this activity and must
agree with the content of the resulting model specification
document. Changes can be made, but they have to be
documented.
Throughout this article, we will illustrate the outputs of the
activities by using some excerpts from a discrete event
simulator developed by us at IESE. This model and simulator
supports managerial decision-making for planning the system
testing phase of software development. The simulator offers
the possibility of executing what-if scenarios with different
values for the parameters that characterize the system testing
process and the specific project. By analyzing the outputs of
the simulator, its user can visualize predictions of the effects
of his/her planning decisions.

Example for step 1) and step 2):
Goal: Develop a model for decision support for
planning of the system testing phase, such that trade-
offs between duration, cost, and quality (remaining
defects) can be analyzed and the most suitable
process planning alternative can be selected, in the
context of organization x.

Questions to be answered:
Q1: When to stop testing in order to reach a
specified quality (number of defects expected to
remain in the delivered