A Hybrid Software Process Simulation Model
Paolo Donzelli and Giuseppe IazeollaLaboratory for Computer Science and CERTIA Research Center* University of Rome “Tor Vergata”
Roma, Italy
{donzelli, iazeolla}@info.uniroma2.it
*Work partially supported by the CERTIA Research Center, and by the UNIROMA2-UMD-WVU Co-operation agreement on
Concurrent Engineering and Simulation Modeling in Software Process Optimization. Keywords:
Software Process Modeling, Simulation Modeling, Hybrid Simulation.
Abstract
This paper deals with simulation modeling of software processes and proposes the combination of three traditional modeling methods (analytical, continuous and discrete-event) into a unique hybrid two-level modeling approach. At the higher abstraction level, the process is modeled by a discrete-event queuing network, which represents the component activities (i.e. service stations), their interactions, and the exchanged artifacts. The implementation details of the introduced activities are given at the lower abstraction level, where the analytical and continuous methods are used.
The proposed approach is applied to a waterfall-based software process to study the effects of requirements instability on various process quality attributes, as effort, delivery time, productivity, rework percentage, and product quality. Simulation results show that the use of the model can provide both qualitative and quantitative suggestions on how to change the software process to improve its quality or to achieve specific organizational goals.
The model is primarily designed to represent the behaviour of hypothetical projects, to allow researchers to view the implications of their assumptions. However, with small improvements, it can be extended to become a tool for analysing and predicting the behaviour of actual projects.
1. Introduction
Software companies are looking for ways to respond to competitive pressures and to reach new quality levels by reengineering and improving their production and operational processes.
Software process improvement activities can benefit from the application of software process models to assess and analyze the as-is process, to design the to-be process, to forecast process trajectories for a better project control, and to simulate outcomes under different what-if conditions, without affecting the actual environment.
Most of the process models used by the software community are analytical models, which provide average data on process behavior. Examples of such models are: Function Point-based models [1] to estimate the final product size and associated effort, the COCOMO model [2] to estimate schedule and effort for a given software product, the Rayleigh model [3] to shape the staffing profile, and the Reliability Growth models [4] to estimate the testing effort. Besides providing average data, these models cover only a strict subset of the process attributes, separate the effects of such attributes (e.g. the development effort from product defect density), and do not permit analysis of the process behavior in a perturbed environment (e.g. changes in product requirements, staff reductions, etc).
More detailed and realistic predictions of the process behavior require more sophisticated models, generally based on simulation techniques. However, existing process simulation techniques also have their drawbacks, in that they only enhance the analysis of some aspects of the process, at a cost to other aspects. Such techniques are in fact either of discrete-type (discrete-event queuing based) [5] or of
continuous-type (system dynamics based) [6, 7, 8], thus neglecting in either case the fact that the software process shows both discrete system aspects and continuous system ones. Only rarely such techniques are a combination of continuous-type and discrete-type simulations [9], and even more rarely a combination of three methods: analytical, continuous-type simulation, and discrete-type simulation.
This paper contribution is the proposal and the experimental validation of the three-method combination (analytical, continuous simulation, and discrete-event simulation) into an unique hybrid two-level modeling approach. The two levels describe the process from two different views: the less detailed, and the more detailed view. In the less detailed view, the process is seen as network of
activities; in the more detailed view, each activity is fully described. At the higher abstraction level (less detailed view), the discrete-event method is used, while the analytical and the continuous-type methods are used at the lower abstraction level (more detailed view).
In addition, as many times documented in simulation literature [10], hybrid modeling reduces the time-complexity of the simulation run, by by replacing detailed-level simulation components with analytical equations, whose computation requires much less time than the computation of the sequence of events necessary to obtain similar results from the detailed-level components.
A simulation technique is used to solve the hybrid model. The QNAP2 simulation package [11] is used, which includes many features that support hybrid modeling.
It is generally argued that simulation solutions are unlikely to give exact forecasts of the real process behavior. However, they nevertheless give projections as to how the process would behave under given assumptions on external and internal factors, stimulate debate and provide a way to learn about, and to improve, the software process.
From such a perspective, the proposed hybrid modeling approach is applied to a waterfall-based software process, and some example applications of the developed model are discussed. In particular, the model is applied to study the effects of requirements instability on various process quality attributes, as effort, delivery time, productivity, rework percentage, and product quality. The confidence in model representativeness is obtained by model validation against real-life process behaviors.
This work is one of the results of the joint co-operation between the University of Roma-TorVergata, the Enterprise-University Consortium CERTIA, the Software Engineering Laboratory of the University of Maryland and the CERC Research Center of the University of West Virginia, on the "Concurrent Engineering and Simulation Modeling in Software Process Optimization" enterprise-university project. The paper is organized as follows. Section 2 briefly introduces the proposed modeling approach. In Section 3 such an approach is applied to model a waterfall-based software process. Some example applications of the developed model are presented and discussed in Section 4. Section 5 discusses model validation, and Section 6 gives conclusions and plans for future work.
2. The Hybrid Modeling Approach
The software process is composed of various activities (e.g., the development of the specification document, the change of the specification document following requirements changes, the correction of the design document on the basis of defects discovered during the testing, etc.). Some activities are sequential, others may be carried on concurrently. Activities collaborate to develop the final product through the exchange of artifacts. Activities need resources (e.g. personnel, computer time, etc.) to carry on the required tasks and may collide on the use of the same resources.
The software process does therefore show both discrete system aspects (start/end of an activity, reception/release of an artifact by an activity) and continuous system ones (resources consumption by an activity, percentage of developed product, percentage of discovered defects).
As stated in Section 1, this composite (discrete-continuous) nature of the software process is disregarded by pure continuous and pure discrete current approaches. Some approaches, as in [9], include both continuous and discrete representations, however at the expense of the simulation-run time-complexity. In order to reduce such a complexity, simulation methodology [10] suggests an approach in which some of the simulative components are replaced by analytical ones. Such an approach, named hybrid simulation, is here applied. In particular, the suggested approach introduces two abstraction levels, a higher abstraction and a lower abstraction level, to represent the software process by a combination of three methods: the analytical, the continuous and the discrete-event method.
At the higher abstraction level, the discrete-event modeling method is used. The process is modeled by a discrete-event queuing network, which models the component activities, their interactions, and the exchanged artifacts. The queuing model is a direct replica of the software process, with service stations used to represent activities, and circulating customers used to represent artifacts that move from one activity to another. Each activity can on its turn be described by a set of service stations to represent the component sub-activities. Some activities/sub-activities may consume resources (e.g. personnel, time), whereas others may just perform co-ordination tasks, simulating managerial policies (e.g. whether or not to release a process artifact to the next development stage depending on its quality level).
The lower abstraction level gives the implementation details of the service stations (i.e. activities) introduced at the higher level. Here the analytical and continuous methods are used. In particular each activity is modeled by either an analytical average-type function, or by a continuous type time-varying function, or by a combination thereof. Such functions are used to express the amount of resources, or time, or effort that various service stations use to simulate the corresponding activities or sub-activities.
3. A Waterfall-based Software Process Model
In this Section the suggested approach is applied to model a waterfall-based software process. The software process taken into consideration is illustrated in Figure 1, where both the component activities and the exchanged artifacts are shown. According to the waterfall paradigm, the software process consists of a series of sequential phases; and the software product is the conclusive artifact of a series of intermediate artifacts: requirements, specification, high-level design, low level design, code, system-tested code and acceptance-system-tested code.
Although phases are sequential, their respective activities can run concurrently, because of the simultaneous execution of work activities (that generate the artifacts mentioned above) and rework activities (necessary to fix defects or introduce requirement modifications). Artifacts generated by activities aiming at fixing defects are defects reports or corrections reports (e.g. low-level design defects reports, code correction reports, etc.). Artifacts generated by activities that introduce modifications due to requirements instability are changes or increments (e.g. specification changes, high-level design increments, etc.).
As shown in Figure 1, the modeled process thus consists of partly sequential and partly concurrent activities. In particular, the activities take into account are both development activities, i.e. Specification (SP), High Level Design (HLD), Low Level Design (LLD), and Implementation (IMP), and testing activities, i.e. System Test (ST), and Acceptance Test (AT).
According to our modeling approach, the software process is translated into a two-level model, consisting of a higher and a lower abstraction level.
requirements requirements changes requirements increments
Specification (SP) Activity
High Level Design (HLD) Activity
Low Level Design (LLD) Activity Implementation (IMP) Activity System Test (ST) Activity Acceptance Test (AT) Activity specification SP changes SP increments SP corrections reports
high level design HLD changes HLD increments HLD corrections reports
low level design LLD changes LLD increments LLD corrections reports code code changes code increments code corrections reports system-tested code system-tested code changes system-tested code increments system-tested code corrections reports
high level design defects reports
low level design defects reports
code defects reports specification defects reports
d e f e c t s r e p o r t s acceptance-tested code acceptance-tested code changes acceptance-tested code increments (the final SW_product)
SP HLD LLD IMP ST AT time Process Phases over Time
P ro ce ss A ct iv iti es
Figure 1- The modeled software process
The main process attributes the developed model deals with are effort (W), delivery time (T), productivity (P), rework percentage (RWK), and product defect density (DFD). However, it provides valuable insights into many other aspects of the modeled process. For example, process and sub-activities staffing profile, effort distribution, phase duration, rework due to defects or requirements instability, size and number of defects of the final product and of the intermediate artifacts, number of defects revealed by testing or review activities, number of defects injected by a development activity.
3.1. The higher abstraction level
At this level, the discrete-event modeling method is used: the process is modeled as a discrete-event queueing network. In particular, two different types of queueing networks are used: one to model the
development activities (SP, HLD, LLD, IMP), and another to model the testing activities (ST, AT). Figure 2 illustrates the type of queueing network used to model the development activities. For the sake of the example, the LLD activity is taken into consideration.
Figure 2 – Higher abstraction level of the LLD activity
The main service stations are the "work station", the "external rework station", the "internal rework station" and the "review station".
The “work station” simulates the development of the low-level design on the basis of the received high-level design. Depending on the received HLD changes, and HLD increments, the “external rework station” simulates the modification of the already released low-level design, and yields the corresponding output artifacts (LLD changes and LLD increments). Similarly, on the basis of the received HLD corrections reports and LLD defects reports, the “internal rework station” simulates the correction of the released low-level design, and yields the corresponding LLD corrections reports. Finally, the “review station” simulates the review performed on the low-level design, on the LLD changes, and on the LLD increments. No review is performed on the LLD correction reports, assumed with no defects. In other words, it is assumed that no further defects (bad fixes) are injected during the correction activities performed by the “internal rework station”.
The “start”, “release” and “store” stations in Figure 2 are assumed to be zero service-time stations, since they perform co-ordination activities only.
work station start station
external rework station
internal rework station
review station store station release station low-level design LLD changes LLD increments LLD corrections reports low-level design LLD changes LLD increments (to be released) low-level design LLD changes LLD increments (to be corrected) LLD defects reports (due to previous activities)
LLD defects reports (due to locally injected defects)
high-level design HLD changes HLD increments HLD corrections reports
The “ start station” takes care of routing the input artifact to the appropriate service station. Although a simple FIFO queueing discipline has been used, other solutions could be adopted to implement more sophisticated managerial policies. For example, defects and correction reports could be given a higher priority than changes and increments, by employing a priority queueing discipline.
The “ release station” and the “ store station” take care of the release of the artifacts. The low-level design, the LLD changes and the LLD increments are released by the “ release station” only if no defects have been found by the “ review station” . On the contrary, the “ release station” creates the corresponding defects reports (e.g. SP, HLD and LLD defects reports), feeding them back to the activities responsible for the defects (i.e. SP, HLD, LLD), and sends the faulty artifacts to the “ store station” . Here they are held until all the LLD corrections reports corresponding to the released defects reports will be received (i.e. the faulty artifacts will be corrected). Also in this case different managerial policies could be implemented. For example, a decision could be made to release the faulty artifacts without waiting for them to be corrected.
As example of the testing activities, Figure 3 illustrates the queueing network used to model the AT activity. The main service stations are the "work testing station", and the "external rework testing station".
Figure 3 - Higher abstraction level of the AT activity
The “ work testing station” simulates the acceptance testing of the system-tested code, whereas the “ external rework testing station” simulates the acceptance testing of the system-tested code changes and increments. Again, the system-tested corrections reports are assumed without defects. The “ start” ,
work testing station start station
external rework testing station
store station release station
system-tested code ST code changes ST code increments St code corrections reports
acceptance-tested code AT code changes AT code increments AT code corrections reports acceptance-tested code, changes and increments (to be corrected) acceptance-tested code, changes and increments (to be released) AT code defects reports (to previous activities)
“ release” and “ store” stations are similar to the homonymous ones in Figure 2.
The higher abstraction level of the entire process is illustrated in Figure 4, where the queueing networks used to model the various activities have been connected according to Figure 1, with some details left out for the sake of clarity.
Figure 4 – Higher abstraction level of the process
By exploiting the queueing network graphical representativeness, the higher abstraction level provides
SP HLD LLD IMP ST AT requirements, changes and increments AT-tested code, changes and increments
a high visibility of the modeled process and corresponding managerial policies, improving early verification and validation of the built model.
3.2. The lower abstraction level
At the lower abstraction level the analytical and the continuous modeling methods are used. Here the dynamic behavior of the service stations previously introduced is modeled by an analytical average-type function, or by a continuous average-type time-varying function, or, more likely, by a combination thereof. In particular, for each station a set of functions is adopted, suitable to express the aspects of the software process to investigate (e.g. delivery time, effort, personnel, defect density, etc.). Such a set can be easily enriched, updated or changed depending on the maturity level of the particular context, on its evolution, and on the model’s goals.
The functions used by the service stations in this paper model can be grouped into some broad categories: 1) COCOMO-like functions, to estimate the size of the output artifacts on the basis of the size of the input ones; 2) COCOMO-like functions, to estimate the effort and the delivery time required to perform the corresponding tasks; 3) reliability growth models, to represent the testing defect pattern in the “ work testing station” and “ external rework testing station” of the testing activities; 4) the Rayleigh model, to shape the effort density of the “ work station” of the development activities (a constant function is assumed for all the other stations); 5) other functions, obtained from empirical observations in research and industrial environments [12, 13], to model the defect generation within the “ work station” and “ external rework station” of the development activities, and the defect removal effectiveness of the review stations. Such functions are rather simplistic and mainly used to provide a flavor of the described approach. However, the model could be easily customized to accommodate more sophisticated models that better fit the real organization behavior.
For the sake of brevity only the functions used by the “ work station” of the LLD activity (Figure 2) are presented. Further details can be found in [14, 15].
The LLD “ work station” simulates the development of the low-level design, starting from the high-level design, as shown in Figure 5.
work station low-level design size: LLD_size effort: WHLD + 0,39W defectiveness: [DSP, DHLD, ID, 0, 0] high-level design size: HLD_size effort: WHLD defectiveness: [DSP, DHLD, 0, 0, 0] time st af f T 0,39W st af f E (t)
Figure 5 – Lower abstraction level of the “ work station”
The artifacts are described by a set of three attributes: size, total development effort and defectiveness. Size is of immediate evidence, and, according to [13], it is expressed in high-level design units, for the high-level design artifact, and in low-level design units, for the low-level design artifact. The defectiveness attribute is described by an array whose j-th element is the amount of defects injected into the artifact by the j-th development activity (j = SP, HLD, LLD, IMP). For example, the defectiveness of the high-level design is given by D= [DSP, DHLD, 0, 0], where DSP (or DHLD) is the amount of defects injected into the artifact by the SP (or HLD) activity. The effort attribute is the effort that has been spent to develop the artifact itself since the beginning of the process. Thus, it encompasses also the effort spent to develop all the artifacts from which it has been derived.
On the basis of the size, effort and defectiveness attributes of the input artifact, the “ work station” computes the corresponding attributes of the output artifact, besides the delivery time (or station service time), T, and the required personnel over time, E(t), as illustrated in Figure 5.
Such quantities may have random deviations, and are therefore simulated according to gaussian-like probability distributions.
More in detail, the average size of the low-level design is first derived from the size of the high-level design by use of COCOMO-like size estimator:
1 + 1 _ 1 _ _LLD size a HLD sizeb c average =
pseudo-random generator. The COCOMO-like time and effort estimators: 2 2 _ 2 c b size LLD a T = + 3 3 _ 3LLD sizeb c a W = +
are then used to compute the random delivery time (T), and the random development effort (W). On the basis of T and W, the instantaneous staff level (E(t)), necessary to produce the low-level design artifact, is computed by use of the Rayleigh model, supported by a large amount of current literature and by marketed prediction tool as SLIM [3]:
2 2 2 2 T t W = E(t) T t e −
Unlimited staff availability is assumed. In other words, it is assumed that the organization can always supply the personnel necessary to fit the E(t) curve demand for personnel. The model, however, can easily accept more realistic assumptions on finite staff conditions.
According to Putnam's assumption [3], the output artifact is released at time T, that is when the staff level E(t) reaches its peak. Thus the “ work station” takes 0,39W (i.e. the E(t) integral up to T) as the development effort to yield the low-level design. This value (0,39W) is then added to the effort of the high-level design (WHLD) to obtain the corresponding attribute of the low-level design (WHLD + 0,39W).
The development sub-activity is error prone, so some defects may be injected (injected defects, ID) into the low-level design, according to a given defect density (defects per unit of size, DD). Quantity ID is obtained by multiplying the random low-level design size (LLD_size) times the defect density, DD:
DD size LLD
ID= _ ×
Defect density is a parameter the simulator uses to summarize the effects of various factors (personnel skill, team structure, supporting tools, programming language, product type, etc) on the defectiveness of a given development activity. More elaborate defect injection models could be easily accepted, as for example models in [16].
4. Example application of the Model
In this section, the two-level simulation model introduced above is applied to compare two possible software development scenarios. In both scenarios, the simulator consists of the higher level component, graphically illustrated in Figure 4, and of a series of lower level components, each of them describing a service station, as, for example, graphically illustrated in Figure 5 for the work-type station. In such a way, the lower level staffing profile, effort and size estimation models are embedded within the service stations of the higher level.
In the first scenario a stable set of requirements is assumed. That is, it is assumed that the initial requirements do not change during the product development. In the second scenario, a certain amount of instability in the requirements is simulated, by allowing the user to add new requirements, or change some of the old ones. In particular, an increment of 15% and a change of 20% of the initial requirements during the product development are simulated.
The process attributes taken into account are effort (W), delivery time (T), productivity (P), rework percentage (RWK), product defect density (DFD) and some sub-attributes thereof (final product size, process staffing profile, staffing profile over single activities, defects pattern, etc.).
In order to simulate the first scenario, a requirements artifact of 1500 Function Points is fed in input to the process model. Simulation results give a final software product size of 116 KLOC and the following process attributes values: W = 500 person-weeks; T = 68 weeks; P = 6.3 LOC/person-hour; RWK = 17%; DFD = 0.9 defects/KLOC.
Figure 6 illustrates the dynamics of the personnel during the development. In particular, it shows both the staffing profiles for all the single process activities (SP, HLD, LLD, IMP, ST and AT), and for the entire project.
0 3 6 9 12 15 0 8 16 24 32 40 48 56 64 72 80 88 96 week st af f E (t ) SP HLD LLD IM P ST AT project
Figure 6 – Staffing profile in case of stable requirements
In the second scenario, the user may both add new requirements, and change some of the previous ones, by feeding requirements increments and changes artifacts. In particular, increments and changes are regularly fed into the process, to simulate a continuous requirements increment and change activity. Over the development time, the requirements growths from the initial amount of 1500FP to an amount of 1500FP+20%, while the 15% of the initial requirements are changed.
0 3 6 9 12 15 1 15 29 43 57 71 85 99 1 1 3 1 2 7 week st a ff E (t ) stable unstable
Figure 7 – Effects of requirements instability on the staffing profile
Figure 7 illustrates the effects of such instability over the staffing profile. The profiles are similar in the two scenarios at the beginning of the project and diverge when the effects of the new and changed requirements increase.
The effects of requirements instability over the main process attributes are instead summarized in Figure 8, where they are compared with the corresponding attributes obtained in case of stable requirements.
The model results show that a substantial increase of effort (W) and delivery time (T) is introduced, of the 38% and the 60%, respectively. This can be partly explained by considering the rework effort needed to deal with the changed and new requirements (the size of the final product is 125 KLOC now), and partly by considering the effort required to detect and remove the further defects injected. In fact, due to requirements instability, the rework percentage has more than doubled (a 150% increase), the productivity has clearly dropped (a 21% decrease), and the defect density of the final product has increased (a 66% increase). Size W T P RWK DFD st a b le un st a b le 0% 20% 40% 60% 80% 100%
Figure 8 - Effects of requirements instability upon process attributes
Figure 9 details the components of the effort that play a significant role in differentiating the two scenarios. In particular, Figure 9 compares the amount of effort spent in fixing defects (internal rework stations), in dealing with new and changed requirements (external rework stations), and in detecting defects (review and work testing stations). Requirements instability yields a 210 person-weeks of external rework, and a clear increase of review (20%), testing (17%), and internal rework (18%) effort.
in te rn a l re w o rk e xt e rn a l re w o rk re vi e w te st in g st a b le un st a b le 0 20 40 60 80 100 120 140 e ffo rt W
Figure 9 – Details about the effort components
It is worth noting that the model can be easily adapted to provide more information about the activities necessary to deal with new and changed requirements, for example by substituting each external rework station with two separate stations, one for the changes and one for the increments.
Finally, the model allows us to analyze the reasons behind the increment of the final product defect density (DFD) experimented in case of unstable requirements or, in other terms, at what extend the defect detection process is hindered by the requirements instability.
S P H L D L L D IM P S T A T un fo un d stable unstable 0 200 400 600 800 1000 d e f e c t s
The defects detection patterns for the two scenarios are compared in Figure 10.
For each scenario, Figure 10 shows the amount of defects revealed by the review stations of the development activities (SP, HLD, LLD and IMP), by the rework and internal rework stations of the testing activities (ST and AT), and the amount of defects of the final product (i.e. unfound defects). By comparing the amounts of found and unfound defects in Figure 10, it can be inferred that requirements instability reduces the process total defect removal effectiveness, bringing it down to a value 89% from an initial value of 95%.
The above-described application is only one of the possible ones of the model. Besides providing support to deal with requirements instability, the model can in fact be applied, for example, to study and compare the effects that different defect detection policies can have on the process behavior [17].
5. Model Validation
Validation is obtaining a good level of confidence in the representativeness of the simulation model against real-life situations. To validate the simulation model, experiments are to be carried out to reproduce empirically known facts in the simulation experiment.
Many experiments have been carried out to validate the model. The one this paper presents consists in reproducing the effects of a specific defect detection policy on the process performance. The experimented policy is the defect detection policy known as “ find as much as early as possible” . It is empirically known that such a policy improves the process delivery time (T), effort (W), productivity (P) and rework percentage (RWK). If the simulation model reproduces such improvements, we get better confidence in its representativeness of real-life situations.
For the sake of conciseness, the software development scenario with stable requirements is used, in other words, as said above, the scenario in which the size of the initial requirements (1500 Function Points) does not change during product development.
The validation experiment consists in studying the effects of three different defect detection policies (P1, P2 and P3). The three policies are characterized by different allocations of the defect detection
resources along the life cycle, however yielding the same final product quality (simply measured in product defect density, DFD). Such allocations are simulated by introducing 3 different levels of defect detection effectiveness (DDE) for the process defect detection activities (SP-review, HLD-review, LLD-review, IMP-review, ST and AT). To this purpose, DDE is used as a model input variable (expressed in terms of percentage of removed defects) for the review and testing stations in Figures 2 and 3 to simulate their detection effectiveness. In summary, it is assumed that in P1 (or Early Detection policy) the DDEs are higher in the initial activities of the lifecycle, in P2 (or Middle Detection policy) the DDEs are higher in the middle activities of the lifecycle, in P3 (or Late Detection policy), the DDEs are higher in the final activities of the lifecycle.
Comparison is made by analyzing how the values of the process attributes W, T, P, and RWK (DFD is constant) change from P1 to P2 to P3.
Figure 11 compares the staffing profiles obtained by simulation for the Early and Late Detection policies. They confirm the empirically known facts that when the Early Detection policy is applied a reduction of delivery time (T) and effort (W), represented by the area under the curve, is obtained.
0 2 4 6 8 10 12 1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 1 0 6 week st a ff E (t ) early late
W T P RWK DFD 0% 20% 40% 60% 80% 100% P1 - Early P2 - Middle P3 - Late
Figure 12- Comparison of process attributes for Early, Middle and Late policies
To further illustrate this point, Figure 12 has been obtained, which gives a synthetic view of the normalized values of the process effectiveness factors for all the 3 policies (P1, P2, and P3). It can be seen that moving from the Early to the Late Detection policy, the effort (W), the delivery time (T) and the rework percentage (RWK) increase, whereas the productivity (P) decreases. As assumed, the final product quality (DFD) at the lifecycle conclusion is the same for the three policies.
6. Conclusions
In general, simulation results show that the use of the model can stimulate debate, and provide both qualitative and quantitative suggestions on the ways to change the software process to improve its quality, or to achieve specific organizational goals.
In turn, the application of the proposed modeling approach shows that it provides a powerful method to accurately model and analyze software processes, helping in bridging the gap between modelers and process experts. The software process is described in terms of highly representative graphical models (queuing networks), providing a better visibility of the modeled process, of its operational environment and managerial policies, whereas the component activities are described in terms of well known analytical and continuous models, easily and quickly updateable. The produced models are highly flexible, being easily adaptable to the characteristics and the maturity level of the production environment, and updateable to follow its evolution (as advocated by such software process improvement methods as the Capability Maturity Model or the Quality Improvement Paradigm).
Plan for future work includes the application of the modeling method to less conventional process paradigms, such as the spiral paradigm and the concurrent engineering paradigm.
7. References
[1] Albrecht, A.J. “ Measuring application development productivity” , Proceedings of IBM Application
development Joint SHARE/GUIDE Symposium, Monterey, CA, 1979.
[2] Bohem, B.W. Software Engineering Economics. Prentice-Hall, N.J., 1981.
[3] Putnam, L.H. and W. Meyer. Measures for Excellence: Reliable Software on Time within Budget.
Prentice-Hall, N.J., 1992.
[4] Fenton, N.E., and Pfleeger S.H. Software Metrics: A Rigorous and Practical Approach. International
Thomson Computer Press, UK, 1997.
[5] Hansen, G.A. "Simulating Software Development Processes", Computer, pp 73-77, IEEE, January 1996.
[6] Abdel-Hamid, T.K. and S.E. Madnick. Software Project Dynamics: An Integrated Approach.
Prentice-Hall, Englewood Cliffs, N.J., 1991.
[7] Rus, I., J. Collofello, and P. Lakey. “ Software Process Simulation for Reliability Strategy Assessment” ,
International Workshop on Software Process Simulation Modeling (ProSim'98), Silver Falls, Oregon, June 1998.
[8] Calavaro, G.F.,Basili V.R., Iazeolla G. "Simulation Modeling of Software Development Process",
Proceedings of the 7th European Simulation Symposium, Erlangen-Nuremberg, GE, October 1995.
[9] Martin, R.H., D. Raffo. "A model of the Software Development Process Using bith Continuous and
Discrete Models", International Journal of Software Process Improvement and Practice (to appear).
[10] simulation literature – cost/benefit of hybrid modelling
[11] SIMULOG. QNAP 2 User Guide ver. 9.3. Simulog, 1986.
[12] Kan, S. H. Metrics and Models in Software Quality Engineering. Addison-Wesley Publishing Company,
MA, 1994.
[13] SEL-95-105. “ Software Process Improvement Guidebook” , Software Engineering Laboratory Series,
NASA-GSFC, Greenbelt, MD. 1996.
[14] Donzelli, P. and Iazeolla G. “ A multi-level hybrid approach to model software development processes” ,
Proceedings of 9th European Simulation Symposium Simulation, Passau, Germany, October 1997.
[15] Donzelli, P. and Iazeolla G. “ Performance Modelling of Software Development Processes” , Proceedings
of 8th European Simulation Symposium Simulation, pp 339-346, Genova, Italy, October 1996.
[16] Stutzke M., Agrawal M., Smidts C. "A stochastic model of human error during software development",
Proceedings of the combined 9th European Software Control and Metrics Conference and the 5th conference for the European Network of Clubs for Reliability and Safety of Software, pp 302-310, Roma, Italy, May 27-29, 1998.
[17] Donzelli, P. and Iazeolla G. “ A Software Process Simulator for Software Product and Process
Improvement” , Proceedings of the International Conference on Product Focused Software Process Improvement (Profes’99), Oulu, Finland, June 22-24, 1999.
Author Biographies
PAOLO DONZELLI is an Advisor with the Department of Informatics, Telecommunications and Statistics of the Office of the Prime Minister, Rome, Italy. Formerly, he served as an engineering officer with the Italian Air Force, and then he was with Cranfield University (UK), as senior research fellow. Dr Donzelli received a doctorate Laurea degree from the University of Naples “ Federico II” (Italy), a MSc degree from the Cranfield University (UK), and a PhD degree from the University of Rome at Tor Vergata (Italy). His research interests
include software process improvement, requirements engineering and business process modelling.
GIUSEPPE IAZEOLLA is full professor of Computer Science, Software Engineering Chair, Faculty of Engineering, University of Roma at TorVergata, Italy. His research is in the areas of software engineering and information system engineering, in relation to system performance and dependability modeling and validation.
