7#)1(.i.i/i/i/i/wX//// / //H0+x/0 0E1"*1L/i1"11"1"1Ls1"1"1"1"1"1"Software is a place where dreams are planted and nightmares harvested, where terrible demons compete with magical panaceas, a world of werewolves and silver bullets. [Cox90] Chapter 1. Introduction 1.1 Overview The rush to reengineer processes taking place in many organizations is the result of increasing competitive pressures to shorten development cycle time and increase quality. Reducing the time to produce software benefits not only the customer, but also the software organization. A number of benefits of reduced cycle time were listed by Collier [CC95]. Market life of the product is extended. Being the first to market along with the high cost of switching products can give a product a great advantage in capturing and obtaining a large market share. Higher profit margins. Being first to market gives a company greater freedom in setting profit margins. The ability to start later and finish on schedule. Starting later allows the use of technological advances that may not have been available to the competition. "According to a study released in January 1990 by United Research Co. of Morristown, N.J., six out of 10 CEOs listed shorter product development cycles as vital to their company..." [Per90]. Most of these cycle time reduction reengineering efforts attempt to take advantage of process improvement technology, such as that advocated by the Software Engineering Institute's Capability Maturity Model [PCCW93] and ISO 9000 [ISO92]. The implication is that a mature development process increases the quality of the work done, while reducing cost and development time [PCCW93]. Some software companies that have begun to mature their process have, indeed, reported cycle time reductions via process improvements [Dio93]. 1.2 Statement of the Problem A common problem faced by organizations attempting to shorten their cycle time is selecting among the numerous process improvement technologies to incorporate into their newly reengineered development process. Even though there is promising evidence trickling into the pages of computer publications, most companies are still skeptical of the investment that must be made before possible improvements will be experienced. These companies recognize that process improvements do not exist in isolation. The impact an improvement has may be negated by other factors at work in the particular development organization. For example, consider a tool that allows some task to be completed in a shorter period of time. The newly available time may just be absorbed as slack time by the worker, resulting in no change to cycle time. Thus, software organizations need to know, in advance of committing to the process improvement technology, the kind of impact they can expect to see. Without such information, software organizations will have a hard time convincing themselves to take action. In particular, a software organization needs to be able to answer the following types of questions: What types of process improvements will have the greatest impact on cycle time?; How much effort should be allocated to the improvement?; What will the overall impact be on the dynamics of software development?; How much will the process improvement cost?; How will the process improvement affect cycle time?; and How will this improvement be offset by reduced schedule pressure, reduced hiring and increased firing? Today, the limited mental models often used to answer these questions are insufficient. The mental models often fail to capture the complex interaction inherent in the system. "It is the rare [manager] whose intuition and experience, when he is presented with the structure and parameters of [only] a second order linear feedback system, will permit him to estimate its dynamic characteristics correctly," [Abd93]. 1.3 Proposed Solution to the Problem In order to solve the problem of selecting among alternative process improvements, this research proposes a model for evaluating the impact that process improvements will have on software development cycle time, if implemented. System dynamics modeling is used to model an organization's existing software development process, specifically, concurrent incremental software development. The process model includes information concerning process steps, product attributes, and the behavior of software developers. The process model may be executed, to simulate a project under development, in order to determine its software development cycle time. Additionally, the model has the capability for evaluating improvements to the process, with respect to their impact on cycle time. The process improvements may be as simple as changes to management strategy, or may actually involve adding new process steps to the existing process through the use of "plug in" process improvement modules. The model allows experimentation with a number of process improvements, enabling researchers and software project managers to make an informed choice between them. 1.4 Research Contributions There are four main contributions provided by this research: 1) an executable model, of a concurrent incremental software development process, that allows researchers and software project managers to experiment with strategies for reducing software development cycle time via process improvements, 2) a definition of a set of metrics that, when collected and entered into the executable model, may be "played back" for analysis, 3) a model specification that provides a foundation for discussion and debate on the factors that affect software development cycle time, and 4) the concept of an extensible system dynamics model, that allows process improvement modules to be "plugged in" to an existing model. These contributions advance both software engineering theory and practice. As discussed in Section 1.2, software organizations face a number of questions when considering the implementation of a process improvement. An executable model of a concurrent incremental software development process will give researchers and software project managers at software organizations the ability to answer their questions and make informed decisions. An executable model will allow controlled experiments to examine different strategies for reducing software development cycle time, thus, providing a more scientific approach to the decision-making process. In addition, an executable model may be used as a management simulator to provide hands-on training to illustrate the advantages and disadvantages of strategies for reducing software development cycle time. An executable model requires that metrics be collected and entered into the model, in order to simulate a project. The metrics required by the model define a metric set for collection by any software development organization wishing to begin a process improvement program. Once collected, the metric values may be entered into the model and "played back" for analysis. The reward for collecting this set of metrics can be a decrease in software development cycle time. A model specification will provide a foundation for discussion and debate on the factors that affect software development cycle time. The model specification represents an underlying theory about concurrent incremental software development that was formed via a literature review and analysis at a software development organization. The theory explains some of the factors that affect cycle time, such as rework, and explains how certain process improvements, such as inspections, affect those factors and, in turn, reduce cycle time. The power of modeling the theory is its ability to take into account a number of factors that affect cycle time to determine the global impact of their interactions, which would be quite difficult to ascertain without a simulation. The model theory, in conjunction with simulation, will result in a better understanding of the cause-effect relationships that underlie the development of software, thus, providing a foundation for discussion and debate of the factors that affect software development cycle time. The combination of an executable model and its underlying theory can potentially lead to new techniques for reducing cycle time and new theories about cycle time. The concept of an extensible system dynamics model, that allows process improvement modules to be "plugged in" to an existing model, has not been discussed in the literature. By specifying such a model, with the express goal of extensibility, the impact of process improvements on software development cycle time can be evaluated with minimal modeling. For each new process improvement, only the new process steps and their interface with the existing process model need to be implemented, the existing process model may be reused. In addition, the process improvement modules can potentially be reused by being "plugged in" to different process models, such as concurrent incremental software development and waterfall software development models. Extensible system dynamics models, like the concurrent incremental software development model, combined with a library of process improvement modules, will allow researchers and software project managers to create custom software development processes for evaluation. 1.5 Organization Chapter 2 provides an analysis and classification of software development cycle time reduction methods. Chapter 2 essentially forms the requirements for the types of process improvements that may be evaluated, with respect to their impact on software development cycle time. Chapter 3 provides background information and discusses current approaches for evaluating the impact of process improvements on cycle time. Chapter 4 describes the method used to build a system dynamics model. Chapter 5 provides the specification of the model of the existing process, namely, concurrent incremental software development, to be used for evaluating the impact of process improvements on software development cycle time. Chapter 6 discusses the creation of a process improvement module that may be "plugged in" to the model of the existing process. Chapter 7 describes the implementation and results of the model testing process. Chapter 8 provides a case study of evaluating a process improvement. Chapter 9 discusses conclusions and future work. vy{|})) @@78bn 4 T!l%i%z)¼ѯ몥› ! !! ! !!! ! !!!! ! ! ! !!! !  >Normal continuedbullet reference? $$ $$8 X!@00  Lp(){ T]%v()) !" HH(FG(HH(d'`jb=/pRHE-:LaserWriter 7.2 $Macintosh HD:Chapter 2 - CTR Methods\Times Helvetica()#sChapter 1 - IntroductionPredicting Cycle Time Reduction John D. Tvedt1.0chapter 1, introduction John D. Tvedt