Feasibility of a Software Process Modeling Library based on MATLAB / Simulink

Feasibility of a Software Process Modeling Library based on MATLAB / Simulink T. Birkhoelzer University of Applied Sciences Konstanz, Braunegger Str. 55, 7846 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]. This requires not only elaborate, ready to use models [], but also the means to quickly build and adapt models [] 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 References to articles are confined to ProSim 005. Additional references could be given but wouldn t add insight. Page 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., 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 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.. 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 integrator (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. 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 time 3. 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 4 (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., 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. The notation /s resembles the formula of an integration in the Laplace-domain. 3 As said, the focus is not on the models per se. Therefore, the algorithm itself is here omitted for brevity. 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. T. Abdel-Hamid, S. Madnick, Software project dynamics: an integrated approach, Prentice-Hall, Englewood Cliffs, NJ, 99.. 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 005), St. Louis, May 005, pp. 83-9. 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 005), St. Louis, May 005, pp. 85-88. 4. F. Brooks, The mythical man month, Addison-Wesley, 995. 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 005), St. Louis, May 005, pp. 73-8. 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 005), St. Louis, May 005, pp. 0-6. 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 005), St. Louis, May 005, pp. 55-59. 8. R. Madachy, People applications in software process modeling and simulation, Proceedings of the 6th International Workshop on Software Process Simulation and Modelling (ProSim 005), St. Louis, May 005, pp. 60-63. 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 005), St. Louis, May 005, pp. 39-43. Page 4 of 8

-K- TotalWorkforce Add -K- -K- Learning speed Training effort s Learning Add 0 Constant max Max min Min Productvity Working s OutputRate Experienced workf orce AccumulatedOutput Fig.. Learning Workforce module CalculatedDate CalculatedEndDate PromisedEndDate 3 Time PromisedDate Time Decision TargetWorkf orce z Unit Delay AvailableWorkforce WorkForce Embedded MATLAB Function Fig.. 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 Add Compare To Zero <= 0 STOP Stop Simulation Divide Add CalculatedEndDate OutputRate 40 PromisedEndDate Av ailableworkf orce TotalWorkforce 40 AccumulatedOutput Clock Time Management Review Learning Workforce 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 >= 00 0 Constant du/dt Derivative Switch s Integrator Rework s Integrator Subtract Compare To Constant >= 00 Compare To Constant AND Logical Operator U ~= U/z Detect Change boolean Data Type Conversion Fig. 6. Generic Phase Model Memory Analy sisphase DesignPhase 00 Constant Initiate OR OR ImplementationPhase AnalysisPhase QueueEmpty Memory TestPhase Release STOP State Machine BreakDownPhaseStop Simulation DesignPhase Logical Operator OR ImplementationPhase Out CLK Complete WorkBreakDown DataIn DataOut InputEnable Empty OutputEnable Queue 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