Abstract The amount of code in evolving software‐intensive systems appears to be growing relentlessly, affecting products and entire businesses. Objective figures quantifying the software code growth rate bounds in systems over a large time scale can be used as a reliable predictive basis for the size of software assets. We analyze a reference base of over 404 million lines of open source and closed software systems to provide accurate bounds on source code growth rates. We find that software source code in systems doubles about every 42 months on average, corresponding to a median compound annual growth rate of 1.21 ± 0.01. Software product and development managers can use our findings to bound estimates, to assess the trustworthiness of road maps, to recognise unsustainable growth, to judge the health of a software development project, and to predict a system's hardware footprint.

This paper reports on a survey amongst software groups in a multinational organization. The survey was initiated by the Software Process Improvement (SPI) Steering Committee of Philips, a committee that monitors the status and quality of software process improvement in the global organization. The paper presents and discusses improvement targets, improvement drivers, and metrics, and the degree to that they are being recognized in the software groups. The improvement targets ‘increase predictability’ and ‘reduce defects’ are being recognized as specifically important, joined for Capability Maturity Model (CMM) level three groups by ‘increase productivity’ and ‘reduce lead time’. The set of improvement drivers that was used in the survey appears to be valid. Three improvement drivers that were rated highest were: ‘commitment of engineering management’, ‘commitment of development staff, and ‘sense of urgency’. Finally, it could be seen that metrics activity, both in size and in quality, increases significantly for CMM level three groups. However, no consensus regarding what metrics should be used can be seen.

A study of the reasons for delay in software development is described. The aim of the study was to gain an insight into the reasons for differences between plans and reality in development activities in order to be able to take actions for improvement. A classification was used to determine the reasons. 160 activities, comprising over 15000 hours of work, have been analyzed. The results and interpretations of the results are presented. Insight into the predominant reasons for delay enabled actions for improvements to be taken in the department concerned. Because the distribution of reasons for delay varied widely from one department to another, it is recommended that every department should gain an insight into its reasons for delay in order to be able to take adequate actions for improvement.>