7# 6`.#.#0#0'2U2c&4444 4"44H4x45u 5E5*60/&55556B555555Chapter 5. Concurrent Incremental Software Development 5.1 Introduction This chapter specifies a concurrent incremental software development model. The concurrent incremental software development model is an extensible model that allows process improvement modules to be "plugged in," in order to evaluate their impact on software development cycle time. The model forms a foundation that allows researchers and software project managers to experiment with strategies for reducing software development cycle time via process improvements. In addition, the model specification provides a foundation for discussion and debate of the factors that affect cycle time. An overview of the concurrent incremental software development process is provided in Section 5.2. Section 5.3 provides the concurrent incremental software development model specification. 5.2 Concurrent Incremental Software Development This section provides a general overview of concurrent incremental software development. Section 5.2.1 describes the concurrent incremental software development process. Section 5.2.2 discusses the sources of data used to specify the model. 5.2.1 Description of the Concurrent Incremental Software Development Process Concurrent incremental software development is a variation of incremental software development. Increments may be developed concurrently, with varying degrees of overlap. Each increment is a complete waterfall model, consisting of requirements analysis, preliminary design, detailed design, code and unit test, integration test, and system test phases. The goal of the requirements phase is to identify the customer's requirements for the software system. The result of the requirements phase is a document that specifies the behavior of the software system and its external interfaces. The exit criteria for the requirements phase is a review, and subsequent rework, of the documents produced. After the specification phase is the preliminary design phase. The goal of the preliminary design phase is to design the software architecture and interfaces. The architectural design addresses how the software system's architecture will fulfill the customer's requirements. The exit criteria for the preliminary design phase is a review, and subsequent rework, of the documents produced. Following the preliminary design phase is the detailed design phase. The goal of the detailed design phase is to create low-level designs that address how the functionality of the software system will be implemented. Detailed design documents enumerate the data structures, modules, algorithms, and interfaces required to implement the system. Plans for unit, integration, and system test may also be developed during this phase. The exit criteria for the detailed design phase is a review, and subsequent rework, of the documents produced. After the detailed design phase is the code and unit test phase. The goal of the code and unit test phase is to translate the detailed design into an executable program. Unit testing is performed on code modules, in order to reveal any flaws that may have been introduced into the code. The exit criteria for the code and unit test phase is a review and unit testing, and subsequent rework, of the code produced. Following the code and unit test phase is the integration test phase. The goal of the integration test phase is to test the interfaces and interaction of code modules after they are integrated into partial system builds. The exit criteria for the integration test phase is the execution of all integration test cases, and subsequent rework of the defects that were discovered. The final step is the system test phase. The goal of the system test phase is to ensure that the resulting software system performs reliably. The exit criteria for the system test phase is the execution of all system test cases, and subsequent rework of the defects that were discovered. 5.2.2 Sources of Data The concurrent incremental software development model specification is based on an analysis of two broad topics: process improvements aimed at cycle time reduction and the dynamics of the software development process, essentially, the interactions of a software development organization's process, products, and people. Information on these topics came from reviews of the literature and analysis at a software development organization. The initial literature review, discussed in Chapter 2, provided an overview of the types of process improvements that are being implemented industry-wide. Case studies of process improvements were examined, specifically, to understand how they impacted the development process and reduced cycle time. A second, broader literature review was performed to examine the dynamics of software development, in general. The literature review was conducted in order to identify and understand the low level cause-effect relationships that produce the feedback structure in software development. Much of this information, regarding cause and effect, is embedded within journal articles as anecdotal experience. The value of conducting literature reviews lies in the large amount of experience that may be drawn upon from across the software industry, enabling one to produce generalizations about the dynamics of the software development process. General industry-wide experiences provided a foundation for the theory underlying the concurrent incremental software development model specification. Specific information about a single organization was gathered in order to refine theories and put them to the test. Software project managers and developers were interviewed with the goal of understanding the development process and the underlying cause-effect relationships. In addition, metrics were gathered to further refine the model and its theory. The software development organization that was studied as part of this research is part of a larger company that performs government contracting work. At any one time, multiple projects are under development within the larger organization. The development process employed by the software project teams is a form of concurrent incremental software development. The projects studied typically last from one to two years and consist of three to five increments, with each increment lasting from four to six months. The software produced by these projects often includes everything from graphical user-interfaces to real-time software. The software developers studied at this company appear to respond to project situations in a manner similar to that discussed in the literature. The response of project personnel to particular project scenarios represents the unwritten process of the software development organization and is an important part of the model theory. An example of the unwritten process is the way in which project personnel respond to a project that has fallen behind schedule. Typical responses may include increasing work intensity, working overtime, adding people to the project, and deleting functionality. Discussions with project personnel indicate that their responses to common project scenarios are not atypical. Overall, the process, products, and people of the software organization are similar to what is revealed in the literature, for organizations of similar size. 5.3 Modeling Concurrent Incremental Software Development This section specifies a concurrent incremental software development model. Section 5.3.1 provides definitions of terms used to specify the model. Section 5.3.2 specifies the purpose of the concurrent incremental software development model and its intended audience. Section 5.3.3 specifies the model boundary, what is included and excluded from the model. Section 5.3.4 specifies the structure of the model. Appendices D and E contain the design and implementation of the concurrent incremental software development model, respectively. The model was implemented using ithink, a modeling tool used to create system dynamics models [ith94]. 5.3.1 Definitions Experienced Engineer - An experienced engineer has experience with the particular type of project being developed. Experience is not necessarily a function of the length of employment, for example, an engineer with ten years of experience may never have had the experience of developing a real-time application, so he would be classified as a new engineer. New Engineer (Inexperienced Engineer) - A new engineer is an engineer with no experience with the particular type of project being developed. A new engineer will require some time to become familiar with the application domain before he can become as productive as an experienced engineer. Development - Development is defined as the period of time encompassing the creation, evaluation and rework of requirements and specification, preliminary design, detailed design, code and unit test, and integration test. Development also includes the creation and evaluation of system test cases. System Test - System test is defined as the period of time encompassing the execution of test cases and the rework of defects discovered. System test occurs at the end of each development increment. Phase - Phase is defined as the stage of the product life cycle. Phases include requirements and specification, preliminary design, detailed design, code and unit test, integration test and test. The test phase is divided between Development and System Test, as defined above. 5.3.2 Model Purpose and Audience The problem that the concurrent incremental software development model shall address is the question of how to dramatically reduce software development cycle time. The model shall implement a theory of software development based on an understanding of the process, products, and people in a software development organization. The model shall fulfill three objectives: 1) it shall allow researchers and software project managers to experiment with strategies for reducing software development cycle time through process improvements; 2) it shall provide a foundation for discussion of the factors affecting software development cycle time; and 3) it shall provide a tool for hands-on training to illustrate the advantages and disadvantages of strategies for reducing software development cycle time. The first objective of the model is to function as a platform for experimentation with process improvements to examine their effects on software development cycle time. The process improvements may be as simple as changes in management strategy or may actually involve adding new process steps to the concurrent incremental software development model. In the first case, management strategies are implemented through the use of sliders or inputs to the model during simulation of a project. An example of a management strategy may be employing only the best or most experienced engineers for the job. In the second case, adding new process steps to the specified concurrent incremental software development model can be implemented by plugging in a process improvement module. An example of adding new process steps to the specified model is adding a software inspection module that may be plugged in and which may be switched on or off to determine its effect on software development cycle time. The specified model provides the flexibility for numerous experiments to be executed. The second objective of the specified model is to provide a foundation for discussion of the factors affecting software development cycle time. The models inputs, outputs and underlying theory explicitly define those factors deemed to have the greatest impact on software development cycle time. The model and associated documentation can facilitate a discussion concerning the factors that affect cycle time and can potentially lead to new techniques for reducing cycle time and new theories about cycle time. The third objective of the model is to provide a tool for hands-on training to illustrate the advantages and disadvantages of strategies for reducing software development cycle time. Once researchers and software project managers have experimented with strategies for reducing cycle time using the model, they may relay their findings to others through hands-on training. One example scenario that could be illustrated is that the temptation to add engineers to a late project, if followed, can make the project even later. Another paradoxical example scenario that could be illustrated is that expending extra effort on quality assurance activities can lead to an overall reduction in a projects cycle time. New findings, as well as old lessons, may be communicated to researchers and software project managers through project scenarios simulated using the model. 5.3.3 Model Boundary The concurrent incremental software development model shall implement a single software project in isolation of other projects that may be under development concurrently. The process followed by the project shall be a form of incremental development. Multiple increments can be developed concurrently under this variation of incremental development, hence the name concurrent incremental software development model. Each increment shall consist of phases from requirements specification through system test. Low-level dependencies between individual work products, such as a requirement to code module "A" before module "B", will not be considered in this model. Post-release maintenance activities are also outside the scope of this model. The model shall not be intended for small, one-man projects, nor for large, several-year projects consisting of a hundred engineers. The typical project that the model shall simulate will last from one to two years. The project shall consist of one to three increments. The size of the project team shall range from just a few to a few dozen engineers. The project personnel considered by the model shall consist of engineers developing the product. Support personnel that do not directly participate in development activities will not be included in the model. The software project management functions shall be controlled through the user interface of the model. The software project management functions influence, but do not directly affect, the actions of the engineers working on the software project. The software project management functions ultimately impact the software development cycle time, product quality and engineering effort. The project controls available for management shall fall into four categories: 1) product definition, 2) project scheduling, 3) quality assurance, and 4) human resources. The product definition controls will allow the management of the size of the product, the technical risk involved in developing the product, and the addition of new product requirements during development of the product. The project scheduling controls will allow management of the number of increments, the size of each increment, the desired duration of each increment, the desired duration of the development and test phases in each increment, and the level of concurrency with other increments. The quality assurance controls will allow the management of the percentage of manpower allocated to evaluation activities and whether or not software inspections will be used. The human resources controls will allow the management of the size of the workforce, the mix of engineering experience, and the amount of overtime engineers work. In order to control a project in ways not currently specified, process improvement modules may be plugged in to the specified concurrent incremental software development model. Chapter 2 discussed an analysis and classification of cycle time reduction methods that was performed, in order to guide the specification of the model. Eight classes of cycle time reduction methods were identified: 1) methods that increase productivity, 2) methods that reduce rework, 3) methods that maximize reuse, 4) methods that reduce product complexity, 5) methods that eliminate or simplify tasks, 6) methods that maximize task concurrency, 7) methods that reduce undiscovered work, and 8) methods that reduce risk. The concurrent incremental software development model was specified with hooks to allow process improvements from each class to be plugged in to the specified model. Appendix C contains a mapping from numbered paragraphs in Chapter 2, describing the eight classes of cycle time reduction methods, to numbered paragraphs in the Model Structure Specification. 5.3.4 Model Structure Specification The model structure specification describes the major subsystems that shall define the concurrent incremental software development model and the components that shall be contained within each subsystem. The model structure specification also details the interaction that will take place between the components contained within the subsystems. The model shall consist of three major subsystems: software project management, human resources, and software production. Figures 5.1 and 5.2, shown below, provide a high-level view of the model structure specification. Figure 5.1 is a cause-effect diagram depicting the interaction between the three subsystems in the model structure specification. Figure 5.2 is a more detailed cause-effect diagram of the model structure specification, depicting the intra- and inter-subsystem interaction.  Figure 5.1: Cause-Effect Diagram of the Specified Model (Level 1). Figure 5.1 depicts a high-level view of the interaction between the three subsystems in the model structure specification. Each box in Figure 5.1 represents a section in the specification, as indicated by the number in parentheses. The arrows in Figure 5.1 represent cause-effect relationships between the subsystems. The labels on the arrows indicate, at a high-level, the nature of the cause-effect relationship. Figure 5.2 depicts a low-level view of the interaction between the three subsystems in the model structure specification. Each box in Figure 5.2 represents a section in the specification, as indicated by the number in parentheses. The arrows in Figure 5.2 represent cause-effect relationships between the subsystems. An arrow to, or from, a box that contains other boxes, indicates that all boxes contained in the larger box are involved in the cause-effect relationship. Due to the complexity of the cause-effect relationships depicted in Figure 5.2, it is necessary to refer to the sections involved in each relationship to understand the specific cause-effect relationship taking place.  Figure 5.2: Cause-Effect Diagram of the Specified Model (Level 2). The model structure specification is in a numbered natural language paragraph format, with essentially one idea per numbered paragraph. Nested paragraphs provide further decomposition of ideas that are presented in parent paragraphs. The numbered natural language paragraph format was chosen, as opposed to more formal specification languages, because it is easy to learn. The effort that the reviewers of the specification had available was limited, so the need for a specification technique that required minimal training to understand was the deciding factor in choosing the numbered natural language paragraph format. 5.3.4.1 Project Management Subsystem The Project Management Subsystem shall be responsible for modeling the management activities of human resources and software production. With respect to the system dynamics model, the user will be responsible for making project management decisions and following through with the appropriate actions using the simulator user-interface. 5.3.4.1.1 Human Resource Management Human resource management shall consist of management activities (inputs) and management feedback (outputs). 5.3.4.1.1.1 Management Activities (Inputs) Human resource management activities shall include: determining project staffing levels, the hours worked by engineers, and the experience level of the engineering staff. 5.3.4.1.1.1.1 Management of Project Staffing Levels The level of staffing on a software project will be determined by the number of engineers that were originally allocated in the project plan and the number of engineers transferred onto, or off of, a project, as a result of unexpected circumstances during production. 5.3.4.1.1.1.1.1 Management of Planned Staffing Levels Planned staffing levels of experienced and inexperienced engineers will be determined before software production begins. The planned staffing levels during development and test may be constant or variable. Staffing levels will be planned for each increment of project development. 5.3.4.1.1.1.1.2 Management of Unplanned Staffing Transfers Unplanned staffing transfers of experienced and inexperienced engineers may occur at any time during software production. Engineers may be transferred onto, or off of, each increment of project development. 5.3.4.1.1.1.2 Management of the Hours Worked by Engineers The hours worked by engineers will be determined by the average percentage of each work-day allocated to the project and the amount of overtime spent each work-day. 5.3.4.1.1.1.2.1 Management of the Average Percentage of Each Work-Day Allocated to the Project The average percentage of each work-day allocated to the project will be determined before software production begins and may be changed at any time during software production. The average percentage of each work-day allocated to the project will determine the number of hours spent working on the project each work-day. 5.3.4.1.1.1.2.2 Management of the Overtime Spent Each Work-Day The amount of overtime spent each work-day may be changed at any time during software production. The amount of overtime spent each work-day will increase the number of hours spent working on the project each work-day. 5.3.4.1.1.1.3 Management of the Engineering Experience Level The experience level of the engineering staff, the mix of experienced and inexperienced engineers working on a project, may be changed at any time during software production. Before software production begins, the management of the planned staffing levels will determine the engineering experience level. During software production, the engineering experience level may be managed through unplanned staffing transfers to reach the desired experience level. Assimilation of inexperienced engineers will occur automatically. 5.3.4.1.1.2 Management Feedback (Outputs) Human resource management feedback shall include: project staffing levels, the hours worked by engineers, and the experience level of the engineering staff. 5.3.4.1.1.2.1 Feedback of Project Staffing Levels The total number of engineers currently working on the increment shall be provided as feedback for management consideration. 5.3.4.1.1.2.2 Feedback of the Hours Worked by Engineers The current average number of man-hours worked daily by each engineer shall be provided as feedback for management consideration. 5.3.4.1.1.2.3 Feedback of the Experience Level of the Engineering Staff The current levels of experienced and inexperienced engineers working on the increment shall be provided as feedback for management consideration. 5.3.4.1.2 Software Production Management Software production management shall consist of management activities (inputs) and management feedback (outputs). 5.3.4.1.2.1 Management Activities (Inputs) Software production management activities shall include: estimating the size of project development, estimating the size of project testing, deciding on the technical risk of the project, deciding on the number of increments for project development, determining the size of each increment, determining the dependence of each increment upon the other increments, deciding on the degree of increment concurrency, choosing the duration of each increment, allocating work-days to development vs. test, deciding on the manpower allocated to evaluation activities, and deciding whether to allow new requirements to be added during development. 5.3.4.1.2.1.1 Estimated Development Size The estimated development size of a project will be determined before software production begins. The estimated size at project conception is the number of work products (or similar size measure) estimated to be required to complete the project. 5.3.4.1.2.1.2 Estimated Test Size The estimated test size of a project will be determined before software production begins. The estimated size at project conception is the number of test cases (or similar size measure) estimated to be required to complete testing of the software. 5.3.4.1.2.1.3 Technical Risk The technical risk of a project will be determined before software production begins. Technical risk is defined as the level of difficulty of a project under development. 5.3.4.1.2.1.4 Number of Increments The number of increments of project development will be determined before software production begins. Each increment includes development and test activities. 5.3.4.1.2.1.5 Size of Increments The size of each increment of project development will be determined before software production begins. The estimated development and test sizes of the project are distributed among the planned increments. 5.3.4.1.2.1.6 Dependence of Increments The dependence of each increment upon the other increments will be determined before software production begins. Dependence of one increment upon another increment is a measure that indicates the percentage of work products (or similar size measure) from another increment that will be used in order to complete this increment. 5.3.4.1.2.1.7 Concurrency of Increments The level of concurrency of each increment with every other increment will be determined before software production begins. The level of concurrency is defined as the degree to which two increments overlap, and will be specified by stating that one increment may begin after a certain percentage of another increment has been completed. 5.3.4.1.2.1.8 Duration of Increments The duration of each increment will be determined before software production begins and may be changed at any time during software production. The duration of each increment is defined as the planned number of work-days allocated to complete development and test activities. 5.3.4.1.2.1.9 Allocating Work-Days to Development Vs. Test The allocation of work-days to the development and test phases in each increment will be performed before software production begins. The allocation of work-days to the development and test phases will determine the planned completion time of each phase within each increment. 5.3.4.1.2.1.10 Allocating Manpower to Evaluation Activities The percentage of manpower allocated to evaluation activities will be determined before software production begins and may be changed at any time during software production. The evaluation activity shall consist of evaluating, with respect to quality, the work products necessary for software development, such as designs, code units, and test cases. Examples of evaluation activities are reviews and inspections. 5.3.4.1.2.1.11 New Requirements New requirements may be added to a project at any time during development. The increase in the development and test sizes due to new requirements will model the additional work required when new requirements are added to a project after development has commenced. 5.3.4.1.2.2 Management Feedback (Outputs) Software production management feedback shall include: the status of development work, the status of test work, the allocation of manpower to development and testing activities, the shortage/excess of scheduled man-hours, the exhaustion level of the engineering staff, the cycle time of the project, the effort expended on the project, the average work intensity level of the engineering staff, and the quality of the product. 5.3.4.1.2.2.1 Feedback of Development Status The current status of development shall be provided as feedback for management consideration. The development status will be reported as the amount of work remaining for generation, evaluation, and rework activities. 5.3.4.1.2.2.2 Feedback of Test Status The current status of testing shall be provided as feedback for management consideration. The test status will be reported as the amount of work remaining for execution and rework activities. 5.3.4.1.2.2.3 Feedback of Manpower Allocation The current allocation of manpower shall be provided as feedback for management consideration. The allocation of manpower will be reported as the amount of manpower allocated to informal training, generation, evaluation, and rework activities during development phases; and informal training, test execution, and rework activities during system test. 5.3.4.1.2.2.4 Feedback of Man-Hour Shortage/Excess The current reported shortage or excess of scheduled man-hours, as calculated by engineers working on the increment, shall be provided as feedback for management consideration. 5.3.4.1.2.2.5 Feedback of Engineers' Exhaustion Level The current level of exhaustion of engineers working on the increment shall be provided as feedback for management consideration. 5.3.4.1.2.2.6 Feedback of Project Cycle Time The total number of work-days expended to complete the increment shall be provided as feedback for management consideration. During the project, the current work-day will be provided as feedback. 5.3.4.1.2.2.7 Feedback of Project Effort The total number of man-hours expended to complete the increment shall be provided as feedback for management consideration. The man-hours expended will be reported as the amount expended on informal training, generation, evaluation, and rework activities during development phases; and informal training, test execution, and rework activities during system test. 5.3.4.1.2.2.8 Feedback of the Average Work Intensity The average work intensity level of engineers, for the duration of the increment, shall be provided as feedback for management consideration. 5.3.4.1.2.2.9 Feedback of Product Quality Upon completion of the project, the total number of defects remaining in the product shall be provided as feedback for management consideration. 5.3.4.2 Human Resources Subsystem The Human Resources Subsystem shall be responsible for modeling project staffing levels, the hours worked by engineers, and the engineers' experience level. 5.3.4.2.1 Project Staffing Levels The level of staffing on a software project shall be determined by the number of engineers that were originally allocated in the project plan and the number of engineers transferred onto, or off of, a project, as a result of unexpected circumstances during production. 5.3.4.2.1.1 Planned Staffing Levels Planned staffing levels of experienced and inexperienced engineers will be determined before software production begins. The planned staffing levels during development and test may be constant or variable. Planned changes to the planned staffing level will occur at predefined intervals. During development, the planned staffing level shall change at the start of ten intervals, each interval will last ten percent of the original planned work-day duration for development. During test, the planned staffing level shall change at the start of three intervals, each interval will last thirty-three percent of the original planned work-day duration for test. The difference in the number of intervals for development and test reflect the difference in duration of development and test. The development phase has more intervals than the test phase, because it typically lasts longer than the test phase. 5.3.4.2.1.2 Unplanned Staffing Transfers Unplanned staffing transfers of experienced and inexperienced engineers may occur at any time during software production. Engineers may be transferred onto, or off of, a project. Transfers will not occur instantaneously, they shall be subject to a delay, due to the time needed to reallocate engineers to, or from, other projects and due to the time needed for the engineers to complete or transfer tasks to others personnel [McL79], [AM91]. 5.3.4.2.2 Hours Worked by Engineers The hours worked by engineers on a project shall be determined by the average percentage of each work-day allocated to the project and the amount of overtime spent each work-day. 5.3.4.2.2.1 Average Percentage of Each Work-Day Allocated to the Project The average percentage of each work-day allocated to the project shall determine the number of hours spent working on the project each work-day. 5.3.4.2.2.2 Overtime Spent Each Work-Day The amount of overtime spent each work-day will increase the number of hours spent working on the project each work-day. 5.3.4.2.3 Engineering Experience Level All engineers are not equal in their abilities. Different levels of engineering experience will lead to different levels of productivity and quality. In addition to being less productive and committing more errors, less experienced engineers will require informal training, on the part of experienced engineers, to improve their performance. 5.3.4.2.3.1 Definition of Engineering Experience For the purpose of modeling, two levels of experience shall exist: inexperienced engineers and experienced engineers. Over time, a smooth transition will take place that will transform inexperienced engineers into experienced engineers. 5.3.4.2.3.1.1 Definition of Experienced Engineer An experienced engineer has experience with the particular type of project being developed. Experience is not necessarily a function of the length of employment, for example, an engineer with ten years of experience may never have had the experience of developing a real-time application, so he would be classified as an inexperienced engineer. 5.3.4.2.3.1.2 Definition of Inexperienced Engineer An inexperienced engineer is an engineer that has no experience with the particular type of project being developed. An inexperienced engineer will require some time to become familiar with the application domain before he can become as productive as an experienced engineer. 5.3.4.2.3.2 Productivity of Inexperienced Vs. Experienced Engineers The productivity of inexperienced engineers will be less than the productivity of experienced engineers [Chr78], [Wei73], [Oka82], [Toe77], [BV80], [Boe81], [AM91]. 5.3.4.2.3.3 Quality due to Inexperienced Vs. Experienced Engineers The number of errors committed by inexperienced engineers will be higher than the number of errors committed by experienced engineers [End75], [Mye76], [AM91]. 5.3.4.2.3.4 Assimilation of Inexperienced Engineers Over time, inexperienced engineers will make a smooth transition to being experienced engineers. The assimilation of inexperienced engineers shall be a result of informal training provided by experienced engineers [Bot82], [CC79], [CKI88], [AM91]. As a result of the time required of experienced engineers to train inexperienced engineers, there will be a practical limit to the number of inexperienced engineers that may be absorbed by a project [Bro78], [AM91]. The limit to the number of inexperienced engineers on a project is a function of the number of experienced engineering man-hours available and the man-hours spent daily to informally train each inexperienced engineer. 5.3.4.3 Software Production Subsystem The Software Production Subsystem shall be responsible for modeling the engineering activities of software development and testing. A number of dynamic relationships will be modeled in the Software Production Subsystem, as a result, it will be specified in terms of its component elements, namely software development, software testing, engineering productivity, product quality, manpower allocation, and progress reporting. 5.3.4.3.1 Software Development Software development shall be defined as the period of time encompassing the following phases: requirements and specification, preliminary design, detailed design, code and unit test, and integration test. Each phase shall consist of three activities: generation, evaluation, and rework. Software development shall also include the generation, evaluation, and rework of system test cases. 5.3.4.3.1.1 Software Generation Activity The generation activity shall consist of generating work products necessary to software development, such as designs, code units, and test cases. The sum total of all work products is a measure of project size. The size of a project shall be a function of four factors: the estimated size at project conception, the underestimation of size at project conception, overhead due to incremental development, and the addition of new requirements during development. The work-days required to complete the software generation activity is a function of its size and the manpower allocated to the activity. 5.3.4.3.1.1.1 Estimated Size at Project Conception The estimated size at project conception is defined as the number of work products (or similar size measure) estimated to be required to complete the project. 5.3.4.3.1.1.2 Underestimation of Size at Project Conception The underestimation of size at project conception will model the growth of the estimated size, as a result of a greater understanding of the project. As development progresses, details of the early phases of development are explored and often lead to a growth in the size of the project, as a result of a better understanding of the problem and a realization of a lack of completeness of early phase work products [Bur82], [Boe81], [Dal77], [AM91]. 5.3.4.3.1.1.3 Overhead Due to Incremental Development Overhead due to incremental development will model the additional work required when a form of incremental development is employed. There shall be two types of overhead that occur as a result of incremental development: overhead due to dependence on another increment and overhead due to dependence on another increment being developed concurrently. 5.3.4.3.1.1.3.1 Overhead Due to Dependence Overhead due to dependence is defined as the development overhead incurred by one increment as a result of dependence on another increment. Dependence of one increment upon another increment is a measure that indicates the percentage of work products (or similar size measure) from another increment that will be used in order to complete this increment. Overhead due to dependence includes modification, redocumentation, re-review, and rework of work produced in another increment. 5.3.4.3.1.1.3.2 Overhead Due to Concurrency Overhead due to concurrency is defined as the development overhead incurred by one increment as a result of dependence on another increment, should the two increments be developed concurrently. The overhead incurred by the dependent increment includes work, such as development and scaffolding, necessary to take the place of work that would have been completed during another increment and used in the dependent increment, had the two increments been developed sequentially. 5.3.4.3.1.1.4 Size Due to New Requirements The size due to new requirements will model the additional work required when new requirements are added to a project after development has commenced [CM93], [Dav95], [CKI88]. 5.3.4.3.1.1.5 Work-Days Required to Complete the Software Generation Activity The work-days required to complete the software generation activity is a function of its size and the manpower allocated to this activity. The total manpower available is a function of the total staff size and their productivity. The software generation activity must compete with the training, evaluation, and rework activities for a share of the total manpower available. 5.3.4.3.1.2 Software Evaluation Activity The evaluation activity shall consist of evaluating, with respect to quality, the work products necessary to software development, such as designs, code units, and test cases. Examples of evaluation activities are reviews and inspections. The purpose of evaluation activities is to find errors that exist in work products. The software evaluation activity is a compromise between speed and effectiveness. During the course of a project, the compromise between speed and effectiveness will fluctuate with respect to the current situation. The factors that will affect the compromise are: the desired evaluation rate, the amount of work awaiting evaluation, the manpower allocated to the evaluation activity, and the maximum acceptable evaluation rate. 5.3.4.3.1.2.1 Desired Evaluation Rate The desired evaluation rate is defined as the planned rate of evaluation. The desired evaluation rate, by definition, is an acceptable compromise between speed and effectiveness. Generally, more thorough, and therefore slower, evaluations will result in a higher percentage of errors being found. At some point, however, extra thoroughness will result in diminishing returns with regard to error detection [Sho83], [Boe81], [AM91]. 5.3.4.3.1.2.2 Work Awaiting Evaluation The amount of work awaiting evaluation may have an impact on the rate at which work products are evaluated. Manpower will be allocated to the evaluation activity with the goal of meeting a specified turn-around time for evaluation of work products. If the amount of work awaiting evaluation is greater than can be evaluated in the specified time, given the desired evaluation rate and the manpower allocated, the rate of evaluation will be increased to meet the specified evaluation turn-around time [Har82], [AM91]. An increase in the evaluation rate, however, will most likely result in finding a lower percentage of errors. 5.3.4.3.1.2.3 Manpower Allocated to the Evaluation Activity Manpower will be allocated to the evaluation activity with the goal of meeting a specified turn-around time for evaluation of work products, at the desired evaluation rate. There will be, however, an upper limit to the percentage of total manpower that will be allocated to the evaluation activity. During periods of high schedule pressure, a reduction of the upper limit may occur [Gil88], [Sho83], [Gla82], [Fag76], [Har82], [AM91]. 5.3.4.3.1.2.4 Maximum Acceptable Evaluation Rate There will be a maximum acceptable evaluation rate. Despite large amounts of work awaiting evaluation and pressures to meet deadlines, the rate of evaluation will not exceed the maximum acceptable evaluation rate. 5.3.4.3.1.3 Software Rework Activity The rework activity shall consist of fixing flaws found during the evaluation activity. The amount of rework existing at any one time is dependent upon the number of errors committed, the evaluation effectiveness, and the manpower allocated to the rework activity. Errors that are committed during development and detected during evaluation activities become rework. 5.3.4.3.2 Software Testing Software testing shall be defined as the period of time encompassing the execution of system test cases and the rework of defects discovered as a result of the test cases. Software testing shall occur at the end of each increment. 5.3.4.3.2.1 System Test Execution Activity The test execution activity shall consist of executing test cases for the purpose of discovering defects that exist in the software. The system test execution activity is a compromise between speed and effectiveness. The effectiveness of the test activity to detect defects is related to the size of the test execution activity. The size of the test activity shall be a function of four factors: the estimated size at project conception, the underestimation of size at project conception, overhead due to incremental development, and the addition of new requirements during development. The work-days required to complete the system test execution activity is a function of its size and the manpower allocated to this activity. 5.3.4.3.2.1.1 System Test Effectiveness The system test effectiveness is a measure of the ability of system test execution activities to detect defects. There will be a compromise between speed and effectiveness when performing system test. Generally, more thorough, and therefore slower, testing will result in a higher percentage of defects being found. At some point, however, extra thoroughness will result in diminishing returns with regard to defect detection. Thoroughness, with respect to the model, is defined as the ratio of development size to test size. The larger the test size, as compared to development, the more thorough and more effective system test becomes. 5.3.4.3.2.1.2 Estimated Size at Project Conception The estimated size at project conception is defined as the number of test cases (or similar size measure) estimated to be required to complete testing of the software. 5.3.4.3.2.1.3 Underestimation of Size at Project Conception The underestimation of size at project conception will model the growth of the estimated size, as a result of a greater understanding of the project. As development progresses, details of the early phases of development are explored and often lead to a growth in the size of the project, as a result of a better understanding of the problem and a realization of a lack of completeness of early phase work products [Bur82], [Boe81], [Dal77], [AM91]. As the size of development increases, the size of test will also grow, in order to fully test the increased development size. 5.3.4.3.2.1.4 Overhead Due to Incremental Development Overhead due to incremental development will model the additional work required when a form of incremental development is employed. There shall be two types of overhead that occur as a result of incremental development: overhead due to dependence on another increment and overhead due to dependence on another increment being developed concurrently. 5.3.4.3.2.1.4.1 Overhead Due to Dependence Overhead due to dependence is defined as the test overhead incurred by one increment as a result of dependence on another increment. Dependence of one increment upon another increment is a measure that indicates the percentage of work products (or similar size measure) from another increment that will be used in order to complete this increment. Overhead due to dependence includes regression testing and rework of work produced in another increment. 5.3.4.3.2.1.4.2 Overhead Due to Concurrency Overhead due to concurrency is defined as the test overhead incurred by one increment as a result of dependence on another increment, should the two increments be developed concurrently. The overhead incurred by the dependent increment includes work, such as additional testing of scaffolding and other development work, necessary to take the place of work that would have been completed during another increment and used in the dependent increment, had the two increments been developed sequentially. 5.3.4.3.2.1.5 Size Due to New Requirements The size due to new requirements will model the additional testing work required when new requirements are added to a project after development has commenced [CM93], [Dav95], [CKI88]. When new requirements are added to development, new test work will be added, such that the ratio of development work to testing work will remain the same. 5.3.4.3.2.1.6 Work-Days Required to Complete the System Test Execution Activity The work-days required to complete the system test execution activity is a function of its size and the manpower allocated to this activity. The total manpower available is a function of the total staff size and their productivity. The system test execution activity must compete with the training and test rework activities for a share of the total manpower available. 5.3.4.3.2.2 System Test Rework Activity The system test rework activity shall consist of fixing defects found during the system test execution activity. The amount of rework existing at any one time is dependent upon the number of errors committed during development, the evaluation effectiveness, defect regeneration, test effectiveness, and the manpower allocated to the rework activity. Errors committed during development that escape detection during evaluation activities become defects which may multiply before leaking into the system test phase. Defects that are committed during development and detected during test execution activities become test rework. 5.3.4.3.3 Engineering Productivity Engineering productivity shall be defined as the actual productivity, as opposed to the potential productivity, of engineers working on the project. The factors that shall influence the engineering productivity are: the average percentage of each work-day allocated to the project, the amount of overtime spent each work-day, the engineers' work intensity level, the engineers' experience level, the learning curve of a project, communication overhead, and the technical risk of a particular project. 5.3.4.3.3.1 Definition of Potential Productivity Potential productivity is defined as the maximum level of productivity attainable by each engineer per work-day, given the current project environment. 5.3.4.3.3.2 Definition of Actual Productivity Actual productivity is defined as the level of productivity currently being achieved by each engineer per work-day. Actual productivity is always less than or equal to the potential productivity. 5.3.4.3.3.3 Average Percentage of Each Work-Day Allocated to the Project The average percentage of each work-day allocated to the project will determine the number of hours spent working on the project each work-day. Spending more hours working on the project each work-day will increase the potential productivity. 5.3.4.3.3.4 Overtime Spent Each Work-Day The amount of overtime spent each work-day will increase the number of hours spent working on the project each work-day. Spending more hours working on the project each work-day will increase the potential productivity. 5.3.4.3.3.5 Engineers' Work Intensity Level The work intensity level of engineers is defined as the percentage of their potential productivity put forth each work-day. The work intensity level will be affected by schedule pressure and by the engineers' exhaustion level. 5.3.4.3.3.5.1 Schedule Pressure Engineers will work at a comfortable intensity level, below their potential, when neutral schedule pressure exists [Bro78], [GP77], [PG80], [BZ79], [Boe81], [SM68], [AM91]. As schedule pressure increases, the work intensity level will increase, in an attempt to finish the project on schedule [Lar82], [Ibr78], [McG78], [Boe81], [AM91]. As schedule pressure decreases, the work intensity level will decrease to a comfortable level and will often have the effect of allowing the work to fill the time available [Boe81], [Ibr78], [AM91]. There will be upper and lower bounds on the work intensity level. 5.3.4.3.3.5.2 Engineers' Exhaustion Level When engineers work at above normal intensity levels, their level of exhaustion will increase. When engineers work at normal or below normal intensity levels, their level of exhaustion will decrease. Extended periods of working at above normal intensity levels may result in a level of exhaustion that causes an engineering breakdown, a period of time when engineers will not work above their normal intensity level, in order to recover from their exhaustion [McG78], [AM91]. 5.3.4.3.3.6 Engineers' Experience Level The level of engineering experience is defined as the mix of inexperienced and experienced engineers working on a project. The experience level of the engineering staff will increase with respect to the percentage of experienced engineers in the mix. A higher experience level will lead to a higher potential productivity, as experienced engineers are assumed to be more productive than inexperienced engineers. 5.3.4.3.3.7 Learning Curve The learning curve of a project is defined as the learning, and efficiencies due to learning, that take place during the course of a project. As development progresses, engineers will become more familiar with the project, process, and tools. As the engineers become more familiar with their development environment, they will learn how to be more efficient and, thus, their potential productivity will increase [CKI88], [Wei82], [She72], [Aro76], [AM91]. 5.3.4.3.3.8 Communication Overhead Communication overhead is defined as the communication that must take place when multiple engineers are working together. The overhead takes the form of increased verbal communication between team members, increased formality of documentation, and increased modularity of the software and the associated interface definitions [Tau77], [Con68], [AM91]. Communication overhead will increase with an increase in the number of engineers working on a project, which will result in a decrease in potential productivity [Bro78], [Sho83], [Mil76], [Zel78], [SS75], [AM91]. 5.3.4.3.3.9 Technical Risk Technical risk is defined as the level of difficulty of the project under development. Complex application domains, such as real-time software, will result in an increased technical risk. Additionally, application domains that the engineers are unfamiliar with will result in an increased technical risk. An increase in technical risk will result in a decrease in potential productivity [Chr78], [AM91]. 5.3.4.3.4 Product Quality Product quality shall be defined as the number of errors and defects in a product. The factors that shall influence the product quality are: the engineers' experience level, the development phase, the technical risk of a particular project, the engineers' work intensity level, and defect regeneration. 5.3.4.3.4.1 Definition of Error An error is defined as a flaw in a work product that was created in the current development phase. 5.3.4.3.4.2 Definition of Defect A defect is defined as a flaw in a work product that was created in a prior development phase. 5.3.4.3.4.3 Engineers' Experience Level The level of engineering experience is defined as the mix of inexperienced and experienced engineers working on the project. The experience level of the engineering staff will increase with respect to the percentage of experienced engineers in the mix. A higher experience level will lead to fewer errors committed, as experienced engineers are assumed to commit fewer errors than inexperienced engineers. 5.3.4.3.4.4 Development Phase The phase of development may impact the number of errors committed per work product. More difficult development phases will be more error prone [Mar82], [Alb76], [Jon81], [Boe81], [Tha78], [AM91]. 5.3.4.3.4.5 Technical Risk Technical risk is defined as the level of difficulty of the project under development. Complex application domains, such as real-time software, will result in an increased technical risk. Additionally, application domains that the engineers are unfamiliar with will result in an increased technical risk. An increase in technical risk will result in an increase in errors committed [Sho83], [AM91]. 5.3.4.3.4.6 Engineers' Work Intensity Level The work intensity level of engineers is defined as the percentage of their potential productivity put forth each work-day. As engineers work harder, they will commit more errors [Mil83], [PF79], [Rad82], [DeM82], [Shn80], [TD80], [AM91]. 5.3.4.3.4.7 Defect Regeneration Defect regeneration is defined as the process by which defects escaping detection lead to the generation of new errors. An example of defect regeneration is producing code based on a flawed design. The code will contain errors as a direct result of the defective design [Boe81], [McC81], [AM91]. Defect regeneration can occur on an intra- or inter-increment basis. Defect regeneration will only occur on an inter-increment basis, however, if dependencies exist between increments. 5.3.4.3.5 Manpower Allocation Manpower shall be a measure that combines the total daily man-hours available with the current actual productivity, to provide a level of effort available for project activities. Manpower shall be divided between training and either development or test activities, depending on the current phase. Manpower shall be allocated on a daily basis. 5.3.4.3.5.1 Manpower Allocated to Training Informal training will be provided to inexperienced engineers by experienced engineers, in order to assimilate them into the work force [Bot82], [CC79], [CKI88], [AM91]. Manpower shall be allocated to training first, in order to meet its requirements, before development or test activities are considered. The manpower required daily for training is a function of the number of inexperienced engineers and the daily informal training time each requires. The daily informal training time required by an inexperienced engineer will decrease during his transition to an experienced engineer. 5.3.4.3.5.2 Manpower Allocated to Development Manpower shall be allocated to development from the pool of manpower existing after training. The development activities that will compete for manpower on a daily basis are generation, evaluation, and rework. When considering the allocation of manpower, priority shall be given first to evaluation, then rework, and finally, generation. 5.3.4.3.5.2.1 Manpower Allocated to the Evaluation Activity Manpower will be allocated to the evaluation activity from the pool of manpower existing after training. Manpower shall be allocated to the evaluation activity with the goal of meeting a specified turn-around time for evaluation of work products, at the desired evaluation rate. There will be, however, an upper limit to the percentage of total manpower that will be allocated to the evaluation activity. During periods of high schedule pressure, a reduction of the upper limit may occur [Gil88], [Sho83], [Gla82], [Fag76], [Har82], [AM91]. 5.3.4.3.5.2.2 Manpower Allocated to the Rework Activity Manpower will be allocated to the rework activity from the pool of manpower existing after training and evaluation. Manpower shall be allocated to the rework activity with the goal of meeting a specified turn-around time for rework of work products. 5.3.4.3.5.2.3 Manpower Allocated to the Generation Activity Manpower will be allocated to the generation activity from the pool of manpower existing after training, evaluation, and rework. All of the manpower remaining after these activities shall be allocated to the generation of work products. 5.3.4.3.5.3 Manpower Allocated to Testing Manpower shall be allocated to testing from the pool of manpower existing after training. The testing activities that will compete for manpower on a daily basis are execution and rework. When considering the allocation of manpower, priority shall be given first to rework and then to execution. 5.3.4.3.5.3.1 Manpower Allocated to the Rework Activity Manpower will be allocated to the rework activity from the pool of manpower existing after training. Manpower shall be allocated to the rework activity with the goal of meeting a specified turn-around time for rework of work products. 5.3.4.3.5.3.2 Manpower Allocated to the Execution Activity Manpower will be allocated to the execution activity from the pool of manpower existing after training and rework. All of the manpower remaining after these activities shall be allocated to the execution of test cases. 5.3.4.3.6 Progress Reporting Progress reporting is an activity performed by engineers that shall be concerned with the evaluation of the difference between the planned production progress and the actual production progress. The constant evaluation of progress will result in a transition from perceiving and using the planned progress for project completion estimates to perceiving and using the actual progress for project completion estimates. The eventual realization of the actual progress can affect schedule pressure and may lead to engineers reporting a shortage of man-hours necessary to complete the project on time. 5.3.4.3.6.1 Definition of Planned Progress Planned progress is defined as the rate of progress assumed in the original project plan. 5.3.4.3.6.2 Definition of Actual Progress Actual progress is defined as the rate of progress that is actually occurring on a project. 5.3.4.3.6.3 Definition of Perceived Progress Perceived progress is defined as the rate of progress perceived by engineers working on a project. Engineers will not evaluate progress uniformly during the course of a project. There will be a smooth transition from the way in which engineers evaluate progress during the early stages of production and the way in which engineers evaluate progress during the later stages of production. 5.3.4.3.6.3.1 Perceived Progress During Early Stages of Production During the early stages of a project, it is difficult to assess the percentage of the project that is complete [Mil83], [AM91]. As a result, during the early stages of production, the perceived progress shall be a reflection of the percentage of resources consumed [DeM82], [Bab82], [AM91]. 5.3.4.3.6.3.2 Perceived Progress During Later Stages of Production Toward the later stages of a project, it becomes more evident how productive the engineers have been, because their work products are much more visible and many more resources have been consumed, and as a result, perceived progress shall be a reflection of actual work products completed vs. resources consumed [Bab82], [AM91]. 5.3.4.3.6.4 Schedule Pressure Schedule pressure is a state of mind held by engineers working on a project. Schedule pressure shall occur in three forms: negative, neutral, and positive. Negative schedule pressure will result from the perception that progress is ahead of schedule, neutral schedule pressure will result from the perception that progress is right on schedule, and positive schedule pressure, often just called schedule pressure, will result from the perception that progress is behind schedule. All forms of schedule pressure will impact the engineers' work intensity level. 5.3.4.3.6.5 Reported Man-Hour Shortage When engineers perceive that they are behind schedule, they will feel schedule pressure and will increase their work intensity level. If the engineers fall far enough behind schedule, their maximum work intensity level will not be sufficient to meet the schedule and they will report a shortage of man-hours [AM91]. Similarly, when engineers perceive that they are ahead of schedule, they will feel negative schedule pressure and will decrease their work intensity level. If the engineers get far enough ahead of schedule, their minimum work intensity level will still enable them to beat the schedule and they will report a surplus of man-hours [AM91]. 5.4 Summary This chapter specifies a concurrent incremental software development model that provides a foundation for discussion and debate of the factors that affect software development cycle time. The design and implementation of the theory, using system dynamics techniques, are shown in detail in Appendices D and E, respectively. The executable model allows researchers and software project managers to experiment with strategies for reducing software development cycle time via process improvements. Chapter 6 specifies a software inspection module that may be "plugged in" to the concurrent incremental software development model. vy{|D6& dMD203  0 ,Times .+!Project Management + (5.3.4.1)dMD20z  w(Human Resources + (5.3.4.2)dMD200  4(7Software Production + (5.3.4.3)dMD20 0d6MD20րրdMD20dMD200 d6MD20 րր dMD20dMD200Id6MD20HHdMD20dMD20 qpd$MD20@dMD20dMD20"qTqktktppkpktktppkd$MD20kIdMD20dMD20"#sqJQJQMKJpJQJQMKJd$MD20@#IdMD20dMD20"CqJQJMNQJpJQJMNQJd$MD20@CIdMD20dMD20"qpd$MD20I dMD20dMD20#_gr> # (lnwork force needed  JjJjJj@0FLXP"0H0 P4#PH ` *@$ R@*dMD20` &q* ( (l-work force available  J)J)J)0PN 0` "9` `ŀf(@`H0`8@ @  `($@$dMD20Cc`?u_H@ _ ? +progress reports  NGNGNFik@`H@(%$8" X PpE `:!X dMD20M`#q + (l*schedule, size, quality J%J%J%X ' p P~p  j DT@ PfC@B%@5$`dMD20@@  (work force available dMD20<rB  ?o@,Times .(H Software (T Production (` Management + (5.3.4.1.2)dMD20<r  ?o(HHuman (T Resource (` Management + (5.3.4.1.1)dMD20 @'@  $(Project Management + (5.3.4.1)dMD20 @^@  [(Human Resources + (5.3.4.2)dMD20S  Q(Software Production + (5.3.4.3)dMD206O  4M( %Project (# Staffing + Levels (1 (5.3.4.2.1)dMD20VO  YM+ 1Hours (n Worked by + Engineers ( (5.3.4.2.2)dMD20@R@  O( Engineering + Experience + Level ( (5.3.4.2.3)dMD20  ( Software ( Development + (5.3.4.3.1)dMD20<@t@  ?q(F Software + Testing (B (5.3.4.3.2)dMD206@`@  :^(C Manpower * Allocation * (5.3.4.3.5)dMD206`  :^(C Progress (O Reporting ([ (5.3.4.3.6)dMD20   ( Engineering * Productivity + (5.3.4.3.3)dMD20<@t@  ?q+mProduct * Quality (B (5.3.4.3.4)dMD20 0d6MD20dMD20dMD200(qd6MD20'@'@o@o@dMD20dMD200Yd6MD20WWdMD20dMD2004}d6MD204@|@|@4@dMD20dMD200(xqd6MD20'w'oowdMD20dMD200d6MD20dMD20dMD2004}d6MD204@|@|@4@dMD20dMD200MYd6MD20MMWWdMD20dMD200AYd6MD20W?W?dMD20dMD2003|d6MD2033{{dMD20dMD2003|Hd6MD2033F{F{dMD20dMD200id6MD20ggdMD20dMD200tXd6MD20sW@W@sdMD20dMD200zd6MD20yππydMD20dMD20"2<qkssonkspkssonksd$MD20@1rdMD20dMD20"|FqHPHLMPHpHPHLMPHd$MD20@{ H dMD20dMD20 X/q-66-/-6p-66-/-6d$MD20@W5dMD20dMD20"h^qpd$MD20@gdMD20dMD20"X@qpxpxutpppxpxutpd$MD20@WodMD20dMD20 {"q((##(p((##(d$MD20@{'@dMD20dMD20"| Gqpd$MD20@{ ` dMD20dMD20"|<)Gqahhaeghpahhaeghd$MD20@{<@`h dMD20dMD20 JH"q((!"(p((!"(d$MD20@J@G'dMD20dMD20 (KZqEWN^EWL^KZNXEWpEWN^EWL^KZNXEWd$MD20@'DW@dMD20dMD20"|3q((!"(p((!"(d$MD20@|`'`dMD20dMD20"[x6qpd$MD20@ZwdMD20dMD20"]0q=oDxDxCoAr=qDxp=oDxDxCoAr=qDxd$MD20@DwdMD20dMD20"q+44+-+4p+44+-+4d$MD20@4`dMD20dMD20"SsKq@JJ@DDJp@JJ@DDJd$MD20@R``IdMD20dMD20 jjqgmjmjgjpgmjmjgjd$MD20@`j``j`dMD20dMD20 Qqpd$MD20@`P`@dMD20dMD20  VqSZZSWYZpSZZSWYZd$MD20@``YdMD20dMD20 ccq`fc`cfcp`fc`cfcd$MD20@`b`bdMD20dMD20"qpzpvvzpppzpvvzpd$MD20@`odMD20dMD20"()qpd$MD20@'dMD20dMD20"-q((##(p((##(d$MD20@@' dMD20dMD20 DSqQZZSTQZpQZZSTQZd$MD20@D``YdMD20dMD20"D)q6<<6:<<p6<<6:<<d$MD20@`D < `dMD20dMD20"q+44+-+4p+44+-+4d$MD20@@@4`dMD20@8 : @ !"##'$G$R%%EeEfJJ! @ @< @@ 7HY|, - Hj7e !#$G%&&&G)k-/33167=ABCtEeEgEGMJJӿӫ⦰Ζ|!p@@ @!@$! !@@ @!@$! ! !! ! ! !!!!!!!!! !!!.JJILLN0NTNNOOPQR)RdS4SnTTrUUVW YYDYZZZ[K[\&\O\\_k_``aabobc2cSd"dIeeg g1hEhiikrkllnqnoxop_pqr rssst{tvvFؿݺ!!!!!!!!!!!!!p IvFvvwwxNxpy}y},}U51d4Sr$QO!)'3o$U,QxSɿؿ !!!!!!! !!!!!!!IfX{J[~u>l1zn×tĠńŤ+ 1ʹ) +ӎӯ6ֲ_؋{ٛۀ۞"rߠ/O7#^:W3]l!!!!!!!!!!!O^|ht!!!!!! `Normal continued definitions figure titlefigure referenceI $$&$`  p(=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abc %&,4<DeIJOU[b2hnxs{y>SOQn RO:Xh=c>{?@AEBCD.EFG"HQIKJ+K!L<MNOPQRS6TNUVqWXYuZ)[\]^Y_3`ta$b c!JvF !" HH(FG(HH(d'hjb=/pR=HE-:LaserWriter 7.2 $Macintosh HD:Chapter 6 - Inspections\Times HelveticaIII(EBmodel spec v1.0CISDEM John Tvedt1Ph.D., Chapter 4 John Tvedt