Time‐based software development

Abstract

Software projects are commonly late and over budget, causing the product to be late to market. Based on questionnaires and field research with software managers in Europe, the USA and Japan, seeks to isolate the management practices that accelerate software development. The results suggest that global differences are not pronounced: Japanese software factories have development processes structured similarly to their US and European counterparts; productivity is also roughly equivalent. To reduce development time, software managers currently achieve greater leverage from the management of people and the cross‐functional process than with the use of CASE tools and technology.

Software development productivity on a new platform: an industrial case study

“…adding a new developer may decrease the productivity, but improve lead-time), the improvement of productivity is usually seen as a way to Quality of platform's documentation 10 Runtime quality of the platform 10 Too much control in development process 9 Too optimistic planning, too big scope of projects 8 Lack of target platform in the design phase 7 Platform interface stability (API) 5 decrease the development time. Blackburn and Scudder [3] identified number of factors that reduce development time.…”

“…Often the simplest method of measuring the size is used, which is number of lines of code [3,4,21,30]. Maxwell et al [21] performed a study that involved an evaluation of the lines-of-code productivity metric.…”

“…Productivity issues are often referred to when discussing delays in software deliveries [3,4,28]. Although lead-time and productivity do not always correlate (i.e.…”

“…It is usually seen as the way to decrease cost and improve delivery time. The fact that software projects are often late and over budget [3,4,28] makes the problem important.…”

“…A well-known problem when dealing with productivity measures is the lack of metrics for measuring the size of the software. The most commonly used metric is the number of code lines [3,4,21,30]. We will discuss this and alternative metrics later in the paper.…”