Feasibility of a Software Process Modeling Library based on
MATLAB / Simulink
T. Birkhoelzer1
1
University of Applied Sciences Konstanz, Braunegger Str. 55,
78462 Konstanz, Germany,
birkhoelzer@fh-kontanz.de
Abstract. Software is one of the key means to realize functionality of almost all modern technical systems. Thus software
related issues, questions, and problems are spreading into almost all engineering disciplines triggering there an associated
demand of software engineering practices, processes, and models. For technical computing, however, MATLAB / Simulink
is one of the most popular and widespread tools, especially in the software intensive areas of signal processing, control applications, and embedded systems. To promote software engineering in general and software process simulation especially
within this community, it would be advantageous to leverage this knowledge and acceptance. Therefore, a study was conducted to explore the feasibility of using MATLAB / Simulink as a tool for software process simulation in general and as a
base for a library of generic modeling blocks in particular.
Introduction
Intention
Software is one of the key factors to realize functionality of modern technical systems. This is true not only for power plants
or complex automation systems, but even for radios, household appliances, or sewing machines, for example. Therefore,
software production becomes an issue in almost all engineering disciplines, spreading the demand of software engineering
practices and software process knowledge beyond traditional computer or information sciences.
To promote these methodologies and knowledge, quantitative modeling and simulation can be a valuable resource [6]1. This
requires not only elaborate, ready to use models [1], but also the means to quickly build and adapt models [2] and even the
possibility to experiment with modeling by the user themselves [3]. Hence, efforts are undertaken to develop generic model
structures and libraries of generalized simulation blocks [5], [7], [8], [9].
With respect to the technical community, however, the existing approaches provide a substantial hurdle: The tools used for
process simulation so far are less known to many engineers, sometimes not even readily available. Effort is necessary to familiarize the users with the tool detracting them from the simulation issues at hand. Moreover, the willingness to learn and
use additional tools, which are not used for other daily work, is limited.
On the other hand, MATLAB / Simulink is a very popular and prevalent tool in technical computation, especially in the software intensive areas of signal processing, control applications, and embedded systems. Availability, knowledge, and acceptance of this tool are widespread, even respective classes are taught in many engineering curricula. Yet, to the knowledge of
the author, MATLAB / Simulink has not been used for software process simulation.
Therefore, the feasibility of using this tool for process simulation in general and as a base for a library of generic modeling
blocks in particular is discussed in this paper.
This study is based on essential requirements on a software process simulation environment, which are established in section 3. In section 4, it is evaluated by using typical modeling tasks, whether and how theses requirements are met. This paper
is focused on the capabilities of the MATLAB / Simulink environment, a comparison with other tools is left to future work.
Background on MATLAB / Simulink
The name MATLAB stands for Matrix Laboratory. It was originally designed to provide easy access to matrix calculations.
Therefore, the core data elements of MATLAB are matrices and vectors. Starting from that, MATLAB has evolved into many
other areas of technical computation. Moreover, the core functionality is supplemented by various toolboxes, e.g. signal processing and communications, mathematics and statistics, and even financial modeling and analysis.
Simulink is built on top of MATLAB. It provides a graphical environment for modeling, simulating, and analyzing dynamic
systems. A Simulink model consists of blocks connected by signals. It can be built in a graphical editor. Signals can be of
various types including vectors (busses) and structures. The block-library contains a wide array of functionality including
1References
to articles are confined to ProSim 2005. Additional references could be given but wouldn’t add insight.
Page 1 of 8
integrators, continuous and discrete transfer functions, logic operations, mathematical functions, signal routing, signal generators, and graphical displays (scopes).
Simulink can also be extended by additional tools and toolboxes. One of these is Stateflow, a graphical design and development tool for finite state machines.
Requirements on a Process Simulation Environment
The following requirements are considered as high level capabilities (it is beyond the scope of this study to establish an exhaustive catalog of fine grained details). They are grouped into two categories: modeling expressiveness, i.e. which types of
models need to be covered, and tool functionality, i.e. which essential modeling support is necessary.
Modeling expressiveness
• Continuous time (continuous state) dynamics (system dynamics). On an abstract level, many process aspects can be
modeled by continuous states (levels) and their rates of change, e.g. the experience of a workforce driven by learning rates,
the completion of an entity driven by productivity, or the quality of an artifact driven by error rates. Mathematical, such
system dynamic models consist of sets of ordinary differential equations. Usually, these differential equations are nonlinear.
Therefore, a software process simulation environment must be able to model, simulate and analyze such continuous time
dynamics.
• Discrete time (continuous state) dynamics. In technical systems, discrete time usually arises due to sampling, i.e. actions
taken at certain points in time only. For example, project staff might not change continuously (over time) driven by a hiring rate. Instead, it might be step-wise adjusted for the next time period based on a review and the resulting management
action. Mathematical, such discrete time dynamics are described by difference equations.
Therefore, a software process simulation environment should be able to model, simulate, and analyze such discrete time
dynamics.
• Discrete event dynamics. In a workflow perspective, activities are triggered by events, e.g. the completion of a preceding
activity. Tasks are moving through the chain of activities like parts in a production line. This is a typical notion of software
process models as well.
Therefore, a software process simulation environment must be able to model, simulate, and analyze such discrete event
dynamics.
• State-machines and automata. Control aspects of a process, e.g. the activation of process phases, can often be described
by a finite number of states and their respective transitions triggered by events. Mathematically, such dynamics are described by finite state-machines or automata. These are a special case of discrete event dynamics, however with distinct
notations and applications.
Therefore, a software process simulation environment should be able to model, simulate, and analyze such finite statemachines and automata.
Tool Functionality
• Support of modularization. In order to cope with complexity, models must be modularized. From a tool perspective,
modularization means: parts are encapsulated into components with well defined interfaces, which can be used and reused
as building blocks in other places and contexts.
A software process simulation environment must provide strong support for such modularization, i.e. it must be possible to
define modules and their interfaces and reuse such modules in (almost) arbitrary contexts as encapsulated entities. Moreover, it should be possible to form and use libraries of standard (but customizable) components.
• Hybrid models. In section 2.1, the need for different model types is outlined. Often these types are required in the same
model side by side to model different aspects appropriately.
Therefore, a process simulation environment must be able to integrate different model types seamlessly in an overall
model. This requires coexistence of respective blocks in a model, access to the appropriate (graphical) editing tools, easy
data and signal exchange, and transparent interoperability of the respective simulation algorithms.
• Extensibility. In each simulation environment, the library of available functionality or building blocks has its limitations.
Therefore, there should be a way to overcome these limitations by inserting own blocks of functionality, typically be reverting to a (general purpose) programming language.
Page 2 of 8
• Usability. On the one hand, usability is one of the most important criteria for each tool. Therefore, it ought to be considered in any tool evaluation. On the other hand, usability strongly depends on the experience, expectations, and background
of the user, e.g. a user experienced with a certain tool will find this tool intrinsically more “useable” than an unknown tool.
Therefore, usability per se is not considered in this evaluation (beside the fact, that the general familiarity of many engineers with MATLAB / Simulink is a main motivation of this study at all).
Feasibility Evaluation
In order to evaluate the simulation environment, modeling scenarios were chosen exemplary for a software process modeling
library. However, the focus in this context is on the capabilities and expressiveness of the tool, not on the models by themselves.
Learning Workforce
One of the most famous software engineering rules is Brooke’s law [4]: “Adding manpower to a late project makes it later”.
One of the reasons of this effect is the learning curve of the new workforce, which not only yields to a delayed increase in the
output rate but also consumes resources of the experienced workforce resulting in an initial drop of the output rate. A simple
model describing these effects is shown in Fig. 1.
There is one input (TotalWorkforce) and two outputs (OutputRate, AccumulatedOutput). Total workforce minus experienced
workforce yields the inexperienced or learning fraction, which is converted (trained) to experienced workforce by a learning
rate. The essential dynamic block is the integrator2 (the block called Learning): the input into this block is the rate, the output
the resulting level. The triangular blocks represent gains, which can be parameterized. Note, that the intention to use such a
block as a generic library block requires covering also a drop in the total workforce resulting in an immediate drop of the
experienced workforce (without negative learning). The two min/max-blocks in the model address this case.
The model is encapsulated into a module which can readily be incorporated into other models, see Fig. 4.
This module is an example of a continuous time (continuous state) or system dynamic model. Basic building blocks of such
models in MATLAB/ Simulink are integrators. However, there are also more complex building blocks available like derivatives, delays, transfer functions, or state space descriptions.
Staffing Control
As a simple example of a time-discrete component, the staffing of a project by management decisions is modeled. Normally,
staffing is not adjusted continuously, but only at certain time intervals after some form of project review.
To avoid distracting gains and scaling, all measures are normalized in the remainder, i.e. it is assumed that management interactions occur at unit time steps and a “workforce unit” produces one unit of output per time unit.
Fig. 2 shows the model of a staffing control. The time discrete nature is expressed by the block named Unit Delay, which
delays its input by one time unit.
The control algorithm itself is placed in the block Embedded MATLAB Function, which allows to extend the standard building blocks by own program code, in this case the algorithm to adjust the workforce depending on the promised end date, the
calculated end date, and the remaining time3.
Fig. 3 shows a simulation of this module in the loop with an ideal workforce, i.e. a workforce, which is immediately fully
productive: Caused by a 5% step increase of the workload at time 35 (Fig. 3a), the calculated end date initially increases from
40 to 42 (upper curve in Fig. 3b). The Staffing Control reacts by a step-wise increase of the workforce (lower curve in
Fig. 3b) such that the original end time target (40) is eventually met.
However, if this staffing strategy is combined with the model of a learning workforce described in section 3.1, see Fig. 4, the
results are much worse, see Fig. 5: The resulting end date is even later than without any management interaction (Brooke’s
law).
Even more importantly, this is an example of a hybrid model seamlessly integrating time continuous as well as time discrete
elements.
2
The notation 1/s resembles the formula of an integration in the Laplace-domain.
said, the focus is not on the models per se. Therefore, the algorithm itself is here omitted for brevity.
3As
Page 3 of 8
Iterative Process Model with General Purpose Phase Model
To test discrete event components, a simple iterative development process was chosen: A project is first broken down in several iteration packages and than processed in iterative cycles each consisting of an analysis, design, implementation, and test
phase. An overview of the respective model is shown in Fig. 7.
Rather than explaining the model in detail, just the aspects important for modeling capabilities and expressiveness are discussed in the following:
• Event-enabled or event-triggered blocks. All blocks in this model are event-enabled or event-triggered. This means, they
are executed only, if the respective event or signal occurs. This is used to model the asynchronous activation of the phases
in the development process.
• Parameterized generic phase model. For the purpose of this model, all process phases are identical: if the phase is enabled, the task assignment is executed until it is completed; changes in the output of the previous task might add rework as
additional work load. A model for such a behavior is shown in Fig. 6. This component is placed in a library and reused for
all four phases.
• Queue. The results of the work break down component are normalized sizes of work packages. These are stored in a
queue as a generic discrete event component to connect discrete event activities.
• State-machine. The activation logic for the different phases, i.e. the actual process model, is represented by a Stateflow
diagram, see Fig. 8. The syntax of this diagram is close to the respective UML notation of statechart diagrams.
• Integration of model types. The model contains continuous time (system dynamic) and discrete event components integrated and executed side-by-side.
Conclusion
MATLAB / Simulink is a known and established tool for computing tasks in the technical community used in many different
applications, many members of this community are familiar with its general concepts and usage.
The evaluation of section 3 indicates that the MATLAB / Simulink environment also provides all capabilities to model complex software process simulation issues: All necessary model types (i.e. continuous time, discrete time, discrete event, and
finite state models) are supported and can be seamlessly integrated. Modules can easily be defined, reused, and grouped into
module libraries. If necessary, blocks with additional (arbitrary) functionality can be defined by reverting to the MATLAB
programming environment. Due to this flexibility and expressiveness, insights, structures, models, and modules developed in
other tool environments might be easily incorporated.
Therefore, as a result of the feasibility study and targeting users in the technical community, the MATLAB / Simulink environment is considered an adequate base to develop process simulation models in general and a library of standard building
blocks for such models in particular.
References
1. T. Abdel-Hamid, S. Madnick, Software project dynamics: an integrated approach, Prentice-Hall, Englewood Cliffs, NJ, 1991.
2. N. Angkasaputra, D. Pfahl, “Towards and agile development method of software process simulation”, Proceedings of the 6th
International Workshop on Software Process Simulation and Modelling (ProSim 2005), St. Louis, May 2005, pp. 83-92.
3. T. Birkhölzer, E. Navarro, “Teaching by modeling instead of by models”, Proceedings of the 6th International Workshop on Software
Process Simulation and Modelling (ProSim 2005), St. Louis, May 2005, pp. 185-188.
4. F. Brooks, The mythical man month, Addison-Wesley, 1995.
5. K. Choi, D. Bae, T. Kim, “DEVS-based software process simulation modeling: formally specified, modularized, and extensible SPSM”,
Proceedings of the 6th International Workshop on Software Process Simulation and Modelling (ProSim 2005), St. Louis, May 2005, pp.
73-82.
6. A. Dantas, M. Barros, C. Werner, “Simulation models applied to game-based training for software project managers”, Proceedings of
the 6th International Workshop on Software Process Simulation and Modelling (ProSim 2005), St. Louis, May 2005, pp. 110-116.
7. D. Kirk, E. Tempero, “A conceptual model of the software development process”, Proceedings of the 6th International Workshop on
Software Process Simulation and Modelling (ProSim 2005), St. Louis, May 2005, pp. 155-159.
8. R. Madachy, “People applications in software process modeling and simulation”, Proceedings of the 6th International Workshop on
Software Process Simulation and Modelling (ProSim 2005), St. Louis, May 2005, pp. 160-163.
9. D. Raffo, U. Nayak, W. Wakeland, “Implementing generalized process simulation models”, Proceedings of the 6th International
Workshop on Software Process Simulation and Modelling (ProSim 2005), St. Louis, May 2005, pp. 139-143.
Page 4 of 8
-KTraining
effort
1
1
s
-K-
TotalWorkforce
Add1
Learning
speed
Learning
max
min
1
-K-
Add2
Max
Min
Productvity
0
Working
Constant
OutputRate
1
s
2
Experienced workf orce
AccumulatedOutput
Fig. 1. Learning Workforce module
1
CalculatedDate
CalculatedEndDate
2
PromisedDate
PromisedEndDate
3
Decision TargetWorkf orce
1
1
z
Time
AvailableWorkforce
Unit Delay
Time
WorkForce
Embedded
MATLAB Function
Fig. 2. Staffing Control module
a)
b)
Fig. 3. Staffing Control with ideal workforce: a) workload, b) calculated end date (upper curve) and available workforce (lower curve)
Page 5 of 8
WorkloadStep
Compare
To Zero
Add
<= 0
STOP
Stop Simulation
CalculatedEndDate
Divide
OutputRate
Add1
40
PromisedEndDate
Av ailableWorkf orce
TotalWorkforce
AccumulatedOutput
40
Time
Learning Workforce
Clock
Management Review
Scope
Fig. 4. Combined model: Staffing Control in the loop with Learning Workforce
a)
b)
Fig. 5. Staffing Control with Learning Workforce: a) workload, b) calculated end date (upper curve) and available workforce (lower curve)
Page 6 of 8
Enable
>= 100
1
InputCompletenss
du/dt
1
s
Derivative
Integrator2
Compare
To Constant1
>= 100
Rework
0
AND
U ~= U/z
Logical
Operator
Detect
Change
boolean
Data Type Conversion
Compare
To Constant
Constant
1
s
2
WorkRate
1
OutputCompleteTrigger
Switch
2
OutputCompleteness
Subtract
Integrator1
Fig. 6. Generic Phase Model
Memory1
Initiate
100
Analy sisPhase
InputCompletenss
OutputCompleteTrigger
OR
Constant
WorkRate
OR
OutputCompleteness
DesignPhase
AnalysisPhase
ImplementationPhase
QueueEmpty
TestPhase
Memory
InputCompletenss
OutputCompleteTrigger
STOP
Release
BreakDownPhaseStop Simulation
WorkRate
OutputCompleteness
State Machine
DesignPhase
InputCompletenss
OutputCompleteTrigger
WorkRate
Logical
Operator1
OR
Out1
DataIn
CLK
InputEnable
Complete
WorkBreakDown
OutputCompleteness
ImplementationPhase
DataOut
OutputEnable
Empty
InputCompletenss
OutputCompleteTrigger
Queue
WorkRate
OutputCompleteness
TestPhase
Fig. 7. Iterative Process Model
Page 7 of 8
Fig. 8. Process definition of the iterative process as Stateflow diagram
Page 8 of 8