Search

Unrealistic project plans and cost overruns create problems for software professionals and their clients. In spite of much research and numerous attempts to learn from experience, the problem of inaccurate, frequently overoptimistic cost estimates hasn't been solved. This article summarizes some knowledge that could improve the estimation accuracy, but we still lack some knowledge that hinders us from being able to produce accurate estimates. [ABSTRACT FROM PUBLISHER]

The article presents a discussion of methods by which software clients can avoid the selection of providers with cost estimates that are overoptimistic. The guidelines that can be followed in order to avoid the situations of delivery problems and cost overruns that can result from the selection of overoptimistic bids are described. The need for companies to analyze the possibility that the bidding process could be associated with cost overruns is mentioned, noting that surveys cite several reasons for cost overruns but typically ignore the bidding process as a contributing factor.

The article presents a discussion on the use of formal models vis-a-vis expert judgment in software development. It discusses the differences between the two types of estimation where it is pointed out that the essential difference lies in the quantification step or the final step where the input is transformed into the effort estimate. Magne Jorgensen and Barry Boehm discuss each model and come up with a conclusion that the two estimation methods are complementary but Jorgensen presents a stronger point for judgment-based methods.

The article presents several studies where software professionals estimated development effort, given various types and amounts of misleading and irrelevant information, and evaluates techniques that could help reduce the impact of misleading and irrelevant information on the estimation work. When estimating the most likely effort, software professionals should ensure that everyone involved in the estimation understands clearly that the purpose is to derive the most likely use of effort, exclude estimators that access misleading or irrelevant information that can bias the estimates, and exclude estimators with vested interests in the outcome.

Increased realism in software engineering experiments is often promoted as an important means of increasing generalizability and industrial relevance. In this context, artificiality, e.g., the use of constructed tasks in place of realistic tasks, is seen as a threat. In this paper, we examine the opposite view that deliberately introduced artificial design elements may increase knowledge gain and enhance both generalizability and relevance. In the first part of this paper, we identify and evaluate arguments and examples in favor of and against deliberately introducing artificiality into software engineering experiments. We find that there are good arguments in favor of deliberately introducing artificial design elements to 1) isolate basic mechanisms, 2) establish the existence of phenomena, 3) enable generalization from particularly unfavorable to more favorable conditions (persistence of phenomena), and 4) relate experiments to theory. In the second part of this paper, we summarize a content analysis of articles that report software engineering experiments published over a 10-year period from 1993 to 2002. The analysis reveals a striving for realism and external validity, but little awareness of for what and when various degrees of artificiality and realism are appropriate. Furthermore, much of the focus on realism seems to be based on a narrow understanding of the nature of generalization. We conclude that an increased awareness and deliberation as to when and for what purposes both artificial and realistic design elements are applied is valuable for better knowledge gain and quality in empirical software engineering experiments. We also conclude that time spent on studies that have obvious threats to validity that are due to artificiality might be better spent on studies that investigate research questions for which artificiality is a strength rather than a weakness. However, arguments in favor of artificial design elements should not be used to justify studies that are badly designed or that have research questions of low relevance. [ABSTRACT FROM AUTHOR]

The article presents information on Evidence-Based Software Engineering (EBSE) used by the practitioners. EBSE aims to improve decision making related to software development and maintenance by integrating current best evidence from research with practical experience and human values. This means one does not expect a technology to be universally good or universally bad, only more appropriate in some circumstances and for some organizations. Furthermore, practitioners will need to accumulate empirical research about a technology of interest and evaluate the research from the viewpoint of their specific circumstances. This aim is decidedly ambitious, particularly because the gap between research and practice can be wide. EBSE seeks to close this gap by encouraging a stronger emphasis on methodological rigor while focusing on relevance for practice. This is important because rigor is necessary in any research that purports to be relevant. Moreover, because most software engineering (SE) research has not influenced industrial practice, there's also a pressing need to prevent SE research from remaining an ivory tower activity that emphasizes academic rigor over relevance to practice. INSETS: Asking the Right Question.;Useful Information Sources.;Evidenced-Based Software Engineering QSA..

Software development effort estimates are frequently too low, which may lead to poor project plans and project failures. One reason for this bias seems to be that the effort estimates produced by software developers are affected by information that has no relevance for the actual use of effort. We attempted to acquire a better understanding of the underlying mechanisms and the robustness of this type of estimation bias. For this purpose, we hired 374 software developers working in outsourcing companies to participate in a set of three experiments. The experiments examined the connection between estimation bias and developer dimensions: self-construal (how one sees oneself), thinking style, nationality, experience, skill, education, sex, and organizational role. We found that estimation bias was present along most of the studied dimensions. The most interesting finding may be that the estimation bias increased significantly with higher levels of interdependence, i.e., with stronger emphasis on connectedness, social context, and relationships. We propose that this connection may be enabled by an activation of one's self-construal when engaging in effort estimation, and a connection between a more interdependent self-construal and increased search for indirect messages, lower ability to ignore irrelevant context, and a stronger emphasis on socially desirable responses. [ABSTRACT FROM PUBLISHER]

Studies in laboratory settings report that software development effort estimates can be strongly affected by effort-irrelevant and misleading information. To increase our knowledge about the importance of these effects in field settings, we paid 46 outsourcing companies from various countries to estimate the required effort of the same five software development projects. The companies were allocated randomly to either the original requirement specification or a manipulated version of the original requirement specification. The manipulations were as follows: 1) reduced length of requirement specification with no change of content, 2) information about the low effort spent on the development of the old system to be replaced, 3) information about the client's unrealistic expectations about low cost, and 4) a restriction of a short development period with start up a few months ahead. We found that the effect sizes in the field settings were much smaller than those found for similar manipulations in laboratory settings. Our findings suggest that we should be careful about generalizing to field settings the effect sizes found in laboratory settings. While laboratory settings can be useful to demonstrate the existence of an effect and better understand it, field studies may be needed to study the size and importance of these effects. [ABSTRACT FROM AUTHOR]