Guide to Advanced Empirical
Conceptualization of the Generic Software
Download 1.5 Mb. View original pdf
|
3299771.3299772, BF01324126
| 6.2. Conceptualization of the Generic Software Development Process While the workflow on the left-hand side of . 4 is static, the control-flow presented on the right-hand side contains some behavioural information. Both static and behavioural information contained in the generic software development (and verification) process are the basis for the creation of a related simulation model, e. g., using the System Dynamics (SD. As will be shown below, the process shown in Fig. 4 is actually a reusable pattern that captures the most important aspects of the workflow, including activities and artefacts, as well as resources that will be used. It also captures some behavioural aspects by specifying the possible states of an activity (or the resulting artefact) and the feasible state transitions. However, for the development of an SD simulation model more information is needed. First, measurement data are needed for model calibration. Second, additional information about managerial decision rules and control policies are needed in order to understand the causal relationships that govern the process behaviour. Table 3 lists attributes that often characterize the entities of the generic artefact development/verification process (second column, and gives typical examples third column. The transformation of these attributes into SD model parameters follows a regular pattern (cf. fourth column. The attribute efficiency of the entity activity always maps to a rate variable. Attributes of artefacts and resources usually map to level variables. However, there are situations where an attribute value of an artefact or resource is considered constant. In particular, this is the case when – for the purpose of the modelling task – it is of no interest to model the variation of an attribute value. An example is the number of designers involved in a design task which maybe controlled by processes outside the scope of the activities to be modelled, e.g. senior management policy. The fifth column of Table 3 indicates how the values of model parameters are determined. Level and rate variables are calculated by their defining functions. Constants are either defined by the model user (INPUT) or, in the case that they are used to calibrate the model, based on expert estimates (EST) or derived from available empirical data (EMP). Calibration constants are either deterministic (e.g., by taking the mean) or stochastic (e.g., by triangulation of expert estimates or by statistically fitting the distribution of empirical data). 5. Simulation Methods 133 Table 3 Mapping of generic process attributes to SD model parameters Process description System dynamics Entity Attribute Example Parameter type Quantification Artefact Size Design/specification document: Level Constant Level Constant Level Constant CALC (from flow rates) INPUT or EST or EMP – Function points (FP) – Pages Code document: CALC (from flow rates Lines of code (LOC) INPUT or EST or EMP Test plan: CALC (from flow rates Number of test cases INPUT or EST or EMP Quality Spec./design/code/test plan: Level Constant CALC (from flow rates) INPUT or EST or EMP – Defects injected, detected, corrected State Spec./design/code/test plan State values Level CALC (flow rates emulate state-transition logic) Activity Efficiency Spec./design/code/test plan Development (and rework) volume per time unit Verification (and validation) volume per time unit Defect injection, detection, correction (® rework) per time unit Rate CALC (based on attribute values of used Resources) Resource Size Workforce: Level CALC (from flow rates Number of architects, designers, programmers, testers, etc. Constant INPUT or EST or EMP Quality Workforce: Level CALC (from flow rates Training Constant INPUT or EST or EMP – Experience Productivity Development, verification, or validation technique: Constant INPUT or EST or EMP – Number of pages, FP, LOC, test cases developed, inspected, or tested per person and time unit (continued) 134 MM ller and D. Pfahl Figure 5 shows the network of individual cause-effect relationships (so-called base mechanisms) of a SD model of the generic process. The most creative – and difficult – part during simulation model creation is the identification of cause-effect relationships that essentially generate the dynamic behaviour of the system, i.e., the variation of level variables overtime. The control flows represented by the state- transition diagrams in Fig. 4 are not sufficient to explain the model behaviour, because they do not specify how relations between model variables change in response to value changes of the entities attributes. One possible network of base mechanisms that (qualitatively) provides exactly this information is shown in Fig. 5. Abase mechanism is represented as a directed graph connecting two nodes (model parameters, e.g., AB or AB. The arc that connects the nodes A and B can have a positive or a negative polarity, represented by “+” or “−” respectively. A positive polarity implies that B increases (or decreases, if A increases (or decreases. A negative polarity implies that B increases, if A decreases and vice versa. Using this encoding, the causal diagram in Fig. 5 can be read as follows. If the workforce (e.g., the number of designers) is increased, then both development (or rework) and verification rate increase. Process description System dynamics Entity Attribute Example Parameter type Quantification Effectiveness Development, verification, or validation technique: Constant INPUT or EST or EMP – Number of defects injected per document size unit Number of defects detected per document size unit Cost Workforce: Level CALC (from flow rates Variable cost (e.g., hourly rate) Constant INPUT or EST or EMP Development, verification, or validation tools: Level Constant CALC (from flow rates) INPUT or EST or EMP – Fixed costs (e.g., purchase price Variable costs (e.g., leasing cost, storage cost, energy cost) CALC calculated by simulation tool INPUT input by model user EST estimated by experts modelled either deterministic or stochastic EMP derived from empirical data (modelled either deterministic or stochastic) Table 3 (continued) 5. Simulation Methods 135 2. If development and verification rates increase, then project duration decreases because the artefact is developed faster. If the artefact size is increased, then project duration increases (because a larger artifact has to be developed at a given rate. If the defect threshold is increased (i.e., more defects per size unit have to be found before a re-verification is triggered, then possibly fewer rework cycles incl. re-verification) have to be performed. If fewer rework cycles (incl. re-verification) are performed, then project duration decreases. If more rework cycles are performed, then there is more learning and increased product maturity. If there is more learning, then development productivity increases and defect injection (per size unit) decreases. If defect injection (per size unit) decreases, then artefact quality increases. If artefact maturity increases, then defect detection (per size unit) decreases. If defect detection (per size unit) decreases, then artefact quality decreases. Figure 5 contains three underlined nodes (workforce, artefact size, and defect threshold. These nodes represent either calibration or input parameters of the simulation model. The parameter Defect Threshold specifies the number of defects needed to trigger a rework cycle. It determines whether a verification step needs to be repeated (cf. in Fig. 4 the state-transition diagram associated with artefact verification. The importance of the parameter Defect Threshold resides in the fact that it not only plays a crucial role in the decision to repeat the verification Learning Defect Injection (per size unit) Defect Detection (per size unit) Development (and Rework) Rate Download 1.5 Mb. Share with your friends:
|