7#&0%,,....J.f.f.f.n .x ..H.x.f/B /b8/*/./////://////Chapter 9. Conclusions and Future Work 9.1 Conclusions This research grew out of the need of software development organizations to decrease cycle time, in order to increase their competitiveness in the marketplace. The objective of this research has been to provide a model that allows the questions posed in Chapter 1, concerning the impact of process improvements on software development cycle time, to be answered. The approach to answering those questions has been to use system dynamics modeling to model the software development process, allowing experimentation with the system. The result of this research has been the concept of building extensible system dynamics models, a specification for an extensible concurrent incremental software development model, a definition for a metric set to be collected by software organizations wishing to begin a process improvement program, and an executable concurrent incremental software development model integrated with a software inspection process improvement. The concept of extensible system dynamics models allows process improvements to be "plugged in" to existing software process models. By specifying an extensible software process model, such as an extensible concurrent incremental software development model, the impact of process improvements on software development cycle time can be evaluated with minimal modeling. In order to evaluate a new process improvement, only the new process steps and their interface with the existing software process model need to be implemented. The existing software process model may be reused. As was shown in Chapter 8, the process improvement modules may be reused by being "plugged in" to different process models, such as waterfall development. Once a library of process improvement modules exists, researchers and software project managers will be able to create custom software development processes for evaluation. The specification of the concurrent incremental software development model is the accumulation of knowledge gathered from the literature and industry, regarding the cause-effect relationships that exist in concurrent incremental software development and impact software development cycle time and quality. The model specification provides a foundation for discussion and debate of these cause-effect relationships, and can ultimately lead to new insights concerning cycle time and new techniques for reducing cycle time. The metric set that was defined for use with the concurrent incremental software development model provides a starting point for software development organizations wishing to begin a process improvement program. The metric set, once collected, may be entered into the executable model and "played back" for analysis. The reward for collecting this set of metrics can be a decrease in software development cycle time. Chapter 1 discussed a number of questions that software organizations face, when considering the implementation of a process improvement. The executable concurrent incremental software development model, integrated with the software inspection process improvement, gives researchers and software project managers at software organizations the ability to answer these questions and make informed decisions. The executable model allows controlled experiments to be run to examine different strategies for reducing software development cycle time, as was shown in Chapters 7 and 8, thus, providing a more scientific approach to the decision-making process. In addition, the executable model can 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. The concurrent incremental software development model has some unique features compared to other published models. The model, being extensible, contains a level of detail not found in non-extensible models. Non-extensible models contain only the elements of software development that are pertinent to their narrowly defined problem. The concurrent incremental software development model is richer in detail and allows for a greater range of experimentation than the published software development models produced by Abdel-Hamid [AM91] and Madachy [Mad96]. The model's extensibility allows an almost endless amount of experimentation, given that new process improvements may be "plugged in" to it, thus, providing a model with even greater detail of the software development process. In addition to it's detail and extensibility, the model differentiates itself from the two other published models with respect to its ability to model concurrent incremental software development. The models produced by Abdel-Hamid and Madachy only allow waterfall software development. Finally, the concurrent incremental software development model allows the user to be involved in the simulation. As a management simulator, it allows a variety of management decisions to be made by the user in response to the current state of development. The models produced by Abdel-Hamid and Madachy were not designed to allow the user to interact with them during a simulation. These contributions provide the foundation for further study of process improvements and their impact on cycle time. Based on the results that have been achieved thus far, this approach seems promising. As a result, there is a great deal of future work that will be pursued in this area. 9.2 Future Work The first bit of future work is to define a standard application program interface (API) between extensible process models and process improvement modules. The API is a layer that would exist between an extensible process model and one or more process improvement modules, in order to provide a standard interface for the flow of information and materials between them. For example, a process improvement module might communicate through the API to an extensible process model that it needs a certain amount of manpower to complete a task. In response, the extensible process model could provide a flow of manpower to the process improvement module through the API. Exactly what form the API will take is not yet known and remains an area of future research. The current implementation of extensible system dynamics models allows for process improvement modules to be "plugged in" to them, but does not guarantee true "plug and play" ease of integration, due to the lack of a standard interface. Once an API is defined that extensible process models and process improvement modules must adhere to, integration with extensible process models, and portability of process improvement modules among them, will be greatly simplified. Given a standard API and the ease of porting process improvement module among extensible process models, the next logical step would be to build a library of process improvement modules. Ideally, one could implement process improvements 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 the cost and development time [PCCW93]. Once a library of process improvements exists that achieves true "plug and play" ease of integration with extensible process models, an intelligent process definition assistant could be constructed. Given quality, cost, and/or cycle time attributes, the assistant would assemble a process from an extensible process model and a collection of process improvement modules. Once the executable process model has been assembled, one could run simulations to determine whether it achieves the overall project goals, and if not, adjust their desired attributes and assemble a new process model for further experimentation. Given a collection of extensible process models and a library of process improvement modules, it would be desirable to have a suite of test cases to exercise them. Each test case would define a scenario that has been observed during software development. For example, one scenario might be adding people to a late project, resulting in the project being even later. In developing a test suite, one would need to define much of the problem behavior that exists in software development organizations, in order test whether the models could accurately reproduce it. The mere development of a test suite would advance theories on the cause-effect relationships existent in software development. The ability of these process models to simulate real software projects and the problematic behavior that they exhibit, makes them a powerful tool for training. It would be desirable to simplify the user interface of the concurrent incremental software development model for use as a management simulator. Using the management simulator, software engineering students and software management trainees could be subjected to a variety of common scenarios that occur during software development. The cost of gaining management experience through the use of a simulator would be much less than learning on the job, and with fewer pitfalls. Finally, the last bit of future work would be to combine the suggestions for future work above, with the use of the concurrent incremental software development model in software development organizations, in order to help them decrease their cycle time and increase their competitiveness in the marketplace. vy{|!LB.LN^ _ONNVH/. n/(N-@POg n *,( n(h n G~`` n"H0(ie|`X n g6 n()n n"LPp"QA"Kp QI0 nRh Rƺn n!LB.LN^ _ONNVH&n(k0+ke|`d/./+N-@POgL/. /+N-@POg8 n()n n"LPp"Q nCp"QI0Rk'LB.LN^ _ONNVH n (*( n&h n I|`B n"H0(ie |` n-h `. n (f (f (,f~`&&&& @ '7L 5Jl|O="_$&&&!!!! !! !!!!! mNormal continued reference table captionquote 1Normal flush leftlistW  $$  0  L)%&; M%&& !" HH(FG(HH(d'`jb=/pRH8-:LaserWriter 7.2 Macintosh HD:References\Times Helvetica(E:Chapter 7 - Validationjim collofellojim collofello