Software process control without calibration

Software process control is important for large enterprise since it is essential for software project management. Boehm [10, 12--15, 20] argues that the best way to do software process control is reusing old proven models (e.g. COCOMO for effort, COQUALMO for defects, etc) while tuning them to local data in order to obtain accurate estimates. This however suggests that historic data is available related to the use of these models in previous software projects. This is not the case, as the availability of relevant historic data related to the use of the above models in a specific software environment is scarce, whether due to the lack of documentation or the unwillingness of companies to disclose such data [63].;To bypass this problem, we implemented a system called STAR. This system uses a combination of an AI search algorithm and a back-select algorithm to determine recommended work that needs to be done on a software project. STAR also has the ability to use multiple models in the evaluation of recommended practice; a feature that is not available in any previous work to the best of our knowledge. The models used are part of the USC family of software engineering models [15] and include: COCOMO II for effort, COQUALMO for defects, a schedule model for development time, and the Madachy [55] threat model for risk assessment.;Upon implementing STAR, we observed stable results that were comparable to those generated by tools currently used, while bypassing the local tuning problem that those tools face. In addition, we were able to tackle several issues related to software process control using STAR. So, in the future we recommend that, in situations where local tuning data isn\u27t available, we exploit the uncertainty of not having local tuning data by searching for stable conclusions withing the space of possible recommendations using AI search engines similar to STAR

Understanding the value of software engineering technologies

Abstract-When AI search methods are applied to software process models, then appropriate technologies can be discovered for a software project. We show that those recommendations are greatly affected by the business context of its use. For example, the automatic defect reduction tools explored by the ASE community are only relevant to a subset of software projects, and only according to certain value criteria. Therefore, when arguing for the value of a particular technology, that argument should include a description of the value function of the target user community

Case-Based Reasoning for Reducing Software Development Effort

Department of ComputingRefereed conference pape