Guide to Advanced Empirical
A Reference Simulation Model for Software
Download 1.5 Mb. View original pdf
|
3299771.3299772, BF01324126
- Navigate this page:
- 6.1. A Generic Software Development Process
| 6. A Reference Simulation Model for Software Development Processes This section shows a simulation model example and introduces the concept of a simulation reference process. The model is implemented as a stochastic SD model using the VENSIM ® tool. Based on the example, a comparison between SD simulation and DE simulation will be made, and the advantages and disadvantages of each technique discussed. 6.1. A Generic Software Development Process The following example presents a generic – in the sense of reusable and adaptable – implementation of a standard process typically occurring in any constructive software development phase. The left-hand side of Fig. 4 shows atypical development and verification workflow of any type of software-related artefacts. The workflow presentation uses the following symbols boxes (for artefacts, ovals (for activities, hexagons (for resources, and arcs (representing uses, produces, and consumes relationships. An artefact maybe, for example, a requirements, design, test, or code document. The actual artefact to be developed and verified is positioned in the centre of the workflow. Before the development of this artefact can start, some input information must be available. For example, a design documents needs to know which requirements have been specified in a previous project stage. The development activity transforms an available artefact input into anew or modified artefact, e.g., a set of requirements into a design document. This artefact is then checked in a verification activity. The result of the verification activity, e.g., an inspection, is a list of defects in the newly created or modified artefact, which in turn is the basis for rework of 5. Simulation Methods the artefact. The rework loop is indicated in Fig. 4 by the consumes-relationship between the artefact defect log and the development activity. No distinction is made between initial work and rework performed on previous output. Activities use resources, e.g., personnel (implying some cost, tools (also incurring some cost, and supporting certain techniques, techniques (implying a need to quantify productivity, and time. For larger simulation models, covering more than one stage of the software development process, instances of the generic workflow shown in Fig. 4 can be combined sequentially by connecting workflows that create predecessor artefacts with workflows that create successor artefacts, and concurrently to represent workflows conducted in parallel that produce separate instances of artefacts of the same type. The right-hand side of Fig. 4 shows the control of the workflow, expressed in terms of states that the artefact can assume in relation to its development (upper diagram) and verification activities (lower diagram, and the transitions between states, including the conditions for activating a transition. For example, a development activity related to the artefact requirements can either have not yet been started (“non-exist”), be active (active, or it can be completed (complete. The transition from “non-exist” into active is triggered as soon as the elapsed time t is greater than the defined starting time of the related development activity. A transition from active to complete is triggered, if all of the artefact inputs have been used up in producing the output document (e.g., a design or code document. If rework needs to be done in order to correct defects detected during verification, then a transition from complete back to active is triggered. The state-transition diagram associated with the verification activity is similar to that of the development activity. The only difference is its fourth state, repeat This state signals that a repetition of the verification activity is needed after rework of the defects found in time > design development start time design to do > 0 and des doc ver status <> active non-exist active complete design to do = 0 des doc dev status complete des doc > 0 and des doc dev status <> active des doc = 0 and design faults per FP pending > design doc quality threshold per FP des doc = 0 and design faults per FP pending > design doc quality threshold per FP non-exist active repeat complete Verification Activity consumes produces uses consumes consumes produces uses Artefact Input Development Activity Artefact (created / reworked) Artifact Defect Log Resources (Workforce, Tools, Time) Resources (Workforce, Tools, Time) Fig. 4 Generic artefact development/verification process 132 MM ller and D. Pfahl the previous verification round has been completed. The decision as to whether the verification step must be repeated depends on the number of defects found per size unit of the artefact. For example, if requirements size is measured in Function Points (FPs), then a threshold value can be defined in terms of defects per FP. If the number of detected defects per FP is larger then the defined threshold value, then verification has to be repeated, otherwise the document is considered (finally) complete after rework. Download 1.5 Mb. Share with your friends:
|