1991
DOI: 10.1109/32.87283
|View full text |Cite
|
Sign up to set email alerts
|

Why is software late? An empirical study of reasons for delay in software development

Abstract: This paper describes a study of the reasons for delay in software development that was carried out in 1988 and 1989 in a Software Engineering Department. 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. One hundred and sixty activities, comprising over 15 000 hours of work, have been analyzed. Actions have been taken in the Depa… Show more

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
2
1
1
1

Citation Types

5
78
0
1

Year Published

1999
1999
2013
2013

Publication Types

Select...
4
2
2

Relationship

0
8

Authors

Journals

citations
Cited by 164 publications
(84 citation statements)
references
References 4 publications
5
78
0
1
Order By: Relevance
“…31 Rational Rose was the tool with the highest market share both worldwide and in Europe. 32 In 1998 it accounted for 33% of the market, with an increase of 79% on the previous year. 33 For this reason, the percentage found by our survey (52% for the year 1999) appears to be as one would expect.…”
Section: The Results Of the Survey And The Potential Demand For An Nlmentioning
confidence: 99%
“…31 Rational Rose was the tool with the highest market share both worldwide and in Europe. 32 In 1998 it accounted for 33% of the market, with an increase of 79% on the previous year. 33 For this reason, the percentage found by our survey (52% for the year 1999) appears to be as one would expect.…”
Section: The Results Of the Survey And The Potential Demand For An Nlmentioning
confidence: 99%
“…Many determinants of the studied projects were the same as the determinants of pre-agile projects [2,3,12,17]. Requirements could only be stabilized when the product and product use were clear enough.…”
Section: Discussionmentioning
confidence: 96%
“…Requirements engineering, in particular, enables effort estimation, project negotiation, progress tracking, and high test coverage [12]. Project management problems such as customer and management changes, unrealistic project plans, staffing problems, and inability to track problems early lead to delays [17]. Other determinants are software architecture, team size, and tooling.…”
Section: Related Workmentioning
confidence: 99%
“…However, effort estimation, planning, and development management for SPL are more complex and difficult than those for sequential development, because of inter-connected relationships between core assets and products, concurrency of their projects, and multiple deadline management [2]. In addition, there are still general problems with software effort estimation because of unplanned work [3] and requirements volatility [4]. The total cycle time can sometimes be longer than initially planned because of these problems.…”
Section: Introductionmentioning
confidence: 99%
“…Though the reasons why software effort estimation error appears have been shared among software professionals [3,9], it is still difficult to predict the amount of overrun and its variability, or the level of risk, in specific situations. The variability of effort estimation gives us more useful information than traditional minimum-maximum intervals to indicate its uncertainty [10].…”
Section: Introductionmentioning
confidence: 99%