Feasibility of a Software Process Modeling Library based on MATLAB / Simulink
T. Birkhoelzer1
1University of Applied Sciences Konstanz, Braunegger Str. 55, 78462 Konstanz, Germany,
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 ap- plications, 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 con- ducted 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 fa- miliarize 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 soft- ware intensive areas of signal processing, control applications, and embedded systems. Availability, knowledge, and accep- tance 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 sec- tion 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 proc- essing 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
integrators, continuous and discrete transfer functions, logic operations, mathematical functions, signal routing, signal genera- tors, and graphical displays (scopes).
Simulink can also be extended by additional tools and toolboxes. One of these is Stateflow, a graphical design and develop- ment 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 ex- haustive 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 nonlin- ear.
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 hir- ing 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 de- scribed 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 state- machines 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. More- over, 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 re- verting to a (general purpose) programming language.
• Usability. On the one hand, usability is one of the most important criteria for each tool. Therefore, it ought to be consid- ered 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 engi- neers 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 them- selves.
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 deriva- tives, 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 inter- actions 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 build- ing 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
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 sev- eral 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 dis- cussed 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 en- abled, 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 inte- grated 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 com- plex 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 envi- ronment 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.
2 AccumulatedOutput
1 OutputRate
1 Working s -K-
T raining effort
-K- Productvity min
Min max
Max -K-
Learning speed
1 s Learning
0 Constant Add1 Add2
1 TotalWorkforce
Experienced workf orce
Fig. 1. Learning Workforce module
1 AvailableWorkforce z
1
Unit Delay CalculatedDate
PromisedDate
Time
WorkForce
TargetWorkf orce Decision
Embedded MAT LAB Function 3
T ime 2 PromisedEndDate
1 CalculatedEndDate
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)
WorkloadStep
STOP
Stop Simulation
Scope CalculatedEndDate
PromisedEndDate
Time
Av ailableWorkf orce
Management Review
AccumulatedOutput OutputRate TotalWorkforce
Learning Workforce Divide
<= 0 Compare
To Zero
Clock
Add1 Add
40 40
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)
2 OutputCompleteness
1
OutputCompleteTrigger
Switch Subtract
AND
Logical Operator 1
s Integrator2
1 s Integrator1
U ~= U/z
Detect Change du/dt
Derivative
boolean
Data Type Conversion 0
Constant
>= 100
Compare T o Constant1
>= 100
Compare To Constant Enable
2 WorkRate
1 InputCompletenss
Rework
Fig. 6. Generic Phase Model
Out1 CLK Complete WorkBreakDown
InputCompletenss
WorkRate
OutputCompleteTrigger
OutputCompleteness
TestPhase STOP
Stop Simulation QueueEmpty
Analy sisPhase
DesignPhase
ImplementationPhase
TestPhase
Release
BreakDownPhase State Machine
DataIn InputEnable OutputEnable
DataOut Empty Queue
OR
OR Memory1
Memory
Logical OR Operator1
Initiate
InputCompletenss
WorkRate
OutputCompleteTrigger
OutputCompleteness
ImplementationPhase InputCompletenss
WorkRate
OutputCompleteTrigger
OutputCompleteness
DesignPhase 100
Constant
InputCompletenss
WorkRate
OutputCompleteTrigger
OutputCompleteness
AnalysisPhase
Fig. 7. Iterative Process Model
Fig. 8. Process definition of the iterative process as Stateflow diagram
