B. W. Boehm and P. N. Papaccio, "Understanding and Controlling Software Costs," IEEE Transactions on Software Engineering, 14(10), pp. 1462-1477, 1988.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....Effort Productivity Table 7. Overview of the projects data collected after the errors have been fixed COMMUNICATIONS OF THE ACM October 1996 Vol. 39, No. 10 115 Software Product Reuse and Software Productivity Reuse has been advocated as a means of reducing development cost. For example, in [9], reuse of classes is identified as one of the most attractive strategies for improving productivity. As productivity is often considered an exponential function of software size, a reduction in the amount of software to be created could provide a dramatic savings in development costs [8] The ....

Boehm, B.W., and Papaccio, P.N. Understanding and controlling software costs. IEEE Trans. Software Eng. 14, 10 (Oct. 1988), 1462--1476.

....program testing continues to grow as does the demand for complex, and predictively reliable programs. It is no longer acceptable to postpone the assurance of software quality until prior to a product s release. Delaying corrections until testing and operational phases may lead to higher costs [2], and it may be too late to improve the system significantly. Recent research in the field of computer program reliability has been directed towards the identification of software modules that are likely to be fault prone, based on product and or process related metrics, prior to the testing ....

B. W. Boehm and P. N. Papaccio, "Understanding and controlling software costs," IEEE Trans. on Software Engineering, vol. 14, no. 10, pp. 1462--1477, October 1988.

....used as the final product, new requirements can be met by making further increments changes to the prototype . This has led to the evolutionary approaches for software development, an approach which has been introduced under different names. In [16] it is referred to as evolutionary delivery, in [17] as the spiral model, and in [18] as iterative enhancement. In evolutionary approaches there is no essential difference between the development and maintenance phases. In both phases, the system evolves by a sequence of adjustments, which have become necessary due to changes in the requirements. ....

B. W. Boehm and P. N. Papaccio, "Understanding and controlling software costs," IEEE Transactions of Software Engineering, 14(10), pp. 1462-1477, 1988.

....the amount of testing that can be performed. Furthermore, defects frequently lead to failure of operational software. Barry Boehm tells us that 3 to 10 failures per thousand lines of code (KLOC) are typical for commercial software, and 1 to 3 failures per KLOC are typical for industrial software [BOEH88]. With a rate of 0.01 failures per KLOC for its shuttle code, however, NASA has demonstrated that lower defect counts can be achieved [HEND94] The cost of correcting defects increases as software development progresses for example, the cost of fixing a requirements fault during operation can be ....

Boehm, B.W. and P.N. Papaccio, "Understanding and Controlling Software Costs," IEEE Transactions on Software Engineering, October 1988, Vol. 12, No. 9, pp. 929-940.

....of most single factor measures of program volume, complexity and control. Other researchers have sought a metric which would identify problematic components early in the life cycle. Studies have shown that approximately 20 percent of a software system is responsible for 80 percent of the errors [Boehm and Papaccio 1988]. It is possible that such error prone modules exhibit some measurable attribute to identify them as design stress points. In Basili s study [1981] the measures V(G) calls, LOC, executable statements, revisions and Halstead s effort metric E were correlated with errors. The metric with the ....

Boehm, B. and P. Papaccio (1988), "Understanding and Controlling Software Costs", IEEE Transactions on Software Engineering, SE-14, 10, pp. 1462-1477.

....The program manager should correlate effort measures with the software size measures. If the size measures are tracking above the plan curve, it may indicate that the size of the software has grown well beyond the estimate, requiring the expenditure of more staff hours than originally planned [BOEHM87]. Insufficient development progress: By correlating effort measures with the development and milestone performance measures, the program manager can determine if the contractor is trying to make up delays by adding staff to the contract. This may not be successful; according to one of Brooks ....

....CMU SEI 92 TR 11 3.3 Staff 3.3.1 Purpose (Staff) Staff measures give the program manager insight into the staffing labor categories used on the contract. The program manager uses this insight to track the contractor s ability to maintain a sufficient level of staffing to complete the contract [BOEHM87] and to track the amount of the contractor s staff turnover. When used in conjunction with the effort measures, the program manager also gains insight into the number of part time people working on the contract and the amount of overtime being worked (regardless of whether or not it is ....

[Article contains additional citation context not shown here]

Boehm, B., "Understanding and Controlling Software Costs," IEEE Transactions on Software Engineering, October 1988.

....requirements, analysts seek to create a model that allows validation during systems development. Ideally, the models we build should also facilitate potential future user requirements. Studies underscore the critical nature of performing successful requirements analysis #Boehm 1981, Dunn 1984, Boehm Papaccio 1988# if the required system is not properly modelled, the cost of changes in latter phases of the systems development lifecycle increases dramatically. Object oriented analysis attempts to address the complexity of requirements modelling by leveraging the advantages of the object oriented ....

Boehm, B. & Papaccio, P. #1988#, `Understanding and controlling software costs', IEEE Transactions on Software Engineering 10, 1462#77.

....two models to control: the real world model and the persistent programming model, together with one mapping between them. The second major advantage of the persistence abstraction is that there is less code to be written, maintained and executed. This has two benefits in terms of software costs [4]. In nonpersistent environments, short term data has to be translated into a form suitable for a database management system or file system in order to store it for a long period; to use the data again, the inverse translation has to be performed. The complexity of this operation is especially ....

Boehm, B.W. "Understanding and controlling software costs". Proc. 10th IFIP World Congress, Dublin (September 1986), North-Holland, Amsterdam, pp. 703-714.

....cost of failure identification, fault diagnosis and fault removal. C 2 , effort per CPU test execution unit is assumed to be 1900 staff units. The effort to resolve failures after system release, C 3 , is assumed to be 600 staff units per failure. This cost is based on the observations of Boehm [1] and Dalal at al [2] that the cost of fixing a software fault after system release is an order of magnitude greater than the cost of fixing while testing. C 1 , C 2 , and C 3 were multiplied by a value of 75 to arrive at the value of the staff, assuming a loaded salary of 75 monetary units per ....

B. W. Boehm and P. N. Papaccio. "Understanding and Controlling Software Costs". IEEE Trans. on Software Engineering, 14(10):1462--1477, October 1988.

....number of faults at the class level. In conclusion, the results support the assumption that reuse in an OO software development results in lower rework effort. 4. Software Product Reuse and Software Productivity Reuse has been advocated as a means for reducing development cost. For example, in [9], reuse of classes is identified as one of the most attractive strategies for improving productivity. As productivity is often considered to be an exponential function of software size, a reduction in the amount of software to be created could provide a dramatic savings in development costs [8] ....

B. W. Boehm and P. N. Papaccio (1988). "Understanding and controlling software costs". IEEE Trans. on Software Engineering, 14(10), October.

....directories than the syntactic units to which most of us are accustomed. In order to support a technique such as the one described in this paper, an object store is required as a repository for modules. This requirement has been recognised by other researchers in the field, for example, Boehm [5] cites the provision of a project master data base or persistent object base as one of the important features distinguishing an Integrated Project Support Environment (IPSE) from a collection of ad hoc tools. The need for a uniform, homogeneous object storage facility is also identified by the ....

Boehm, B. W. "Understanding and Controlling Software Costs", Information Processing 86, pp. 703, 1986.

....codes is towards using AI techniques for building better, more reliable software, for automating the development process and for minimizing the costs of development cycle. DARPA recently performed an extensive analysis of software costs, using the database of representative DoD projects [BoPa88]. Knowledge Based Software Engineering technology is advised to be the efficient software economy measure for the next generation of the DoD programs. We anticipate the need for such high quality intelligent CASE tools to manage the growing volume of the system and application code in MOVIE and ....

Boehm, B. and Papaccio, P., "Understanding and Controlling Software Costs", IEEE Transactions on Software Engineering, October 1998, pp. 1462--1477.

....cost of failure identification, fault diagnosis and fault removal. C 2 , effort per CPU test execution unit is assumed to be 1900 staff units. The effort to resolve failures after system release, C 3 , is assumed to be 600 staff units per failure. This cost is based on the observations of Boehm [1] and Dalal at al. 2] that the cost of fixing a software fault after system release is an order of magnitude greater than the cost of fixing while testing. C 1 , C 2 , and C 3 were multiplied by a value of 75 to arrive at the value of the staff, assuming a loaded salary of 75 monetary units per ....

B. W. Boehm and P. N. Papaccio. "Understanding and Controlling Software Costs". IEEE Trans. on Software Engineering, 14(10):1462--1477, October 1988.

....and the aspects belonging in the situational method. The S 3 model is covered in section three, while the actual selection procedure is described in section four. The paper ends with conclusions and suggestions for further research. 2 Approach Practical experience and literature (for instance, Boehm 88; Bennatan 92; Euromethod 94ab] brought us to the assumption, that the required aspects in a situational method, indicated by the term project scenario, depend on both the project situation and the required project success. This assumption has led to the Success Situation Scenario (S 3 ) ....

.... product related indicators, are software specification quality factors, as found in, for instance [Gilb 88] ISO 91] and [SERC 92] Other, processrelated, performance indicators can be found in literature on software process improvement (for instance [Humphrey 89; Dion 92] and software costs [Boehm 88] Performance indicators related to the information produced by the information system were also found in the software product quality literature, as well as in [Swede 94] After the two reduction steps, we obtained 23 performance indicators, divided in a number of sub factors. The scenario ....

Boehm, B., and P. Papaccio, Understanding and Controlling Software Costs. In: IEEE Transactions on Software Engineering, Vol. 14, No. 10, pp. 14621477, October 1988.

....of myths and half truths. Weinberg 1971] The industry has a great lore about the factors affecting software productivity, but few facts are known. Bohem also cites a 25 to 1 ratio between the most productive and least productive software developers and a 10 to 1 difference in their error rates [Boehm 1988]. If the personal attributes of these most productive individuals can be understood, a number of exciting opportunities present themselves: ffl Understanding the characteristics of the most successful software developers could lead to the improvement of all software developers. ffl Once the ....

B. Boehm. Understanding and controlling software costs. IEEE Trans. Software Engineering, 14(10):1462--1477, October 1988.

....of software production are now astronomical. It has been estimated [joe83] that, in America, software production and maintenance now costs 2 of the gross national product. Therefore even small savings made to the software life cycle will result in a vast reduction in economic expenditure. Boehm [boe86] gives four strategies for improving software productivity: 1. Write less code 2. Get the best from people 3. Avoid re work 4. Develop and use integrated project support environments Getting the best from people is the domain of managers. The other three topics provide the thrust for the work ....

....is discussed in chapter 7. 1.3 Using Integrated Project Support Environments If IPSE s make software cheaper to produce it must be ascertained that the definition of an IPSE is clear. Boehm distinguishes an IPSE from a collection of ad hoc tools by the amount of gross integration available [boe86]. The tools available in toolkits such as Unix work in isolation. Tools operate in isolation with no knowledge of other tools or of any special data structures being used. On the other hand in an IPSE the tools share common schemata. Each has specialised knowledge of the data being manipulated and ....

Boehm B. Understanding and Controlling Software Costs. Proceedings of the IFIP 10th World Computer Congress, pp 703-714 (1986)

....burden of myths and half truths. 4] The industry has a great lore about the factors affecting software productivity, but few facts are known. Bohem also cites a 25 to 1 ratio between the most productive and least productive software developers and a 10 to 1 difference in their error rates [5]. If the personal attributes of these most productive individuals can be understood, a number of exciting opportunities present themselves: ffl Understanding the characteristics of the most successful software developers could lead to the improvement of all software developers. ffl Once the ....

B. Boehm. Understanding and controlling software costs. IEEE Trans. Software Engineering, 14(10):1462--1477, October 1988.

....can take two forms. For a given set of qualities, the goal is usually to minimise quantities necessary to achieve them, for example to reduce effort (and therefore cost and or timescale) by being more efficient, eliminating steps, reducing rework, building simpler products or reusing components [Boehm88a]. For a given set of quantities, the goal is usually to maximise product qualities. Authors have generally found it easier to define quantities than qualities, but some definitions of quality do exist. McCall [McCall77] defines software quality factors according to a revision transition ....

....a single metric can represent the multi dimensional notion of complexity. There is a second class of studies that has recently started to emerge. Observations that faults do not fall uniformly across components of software products, but rather concentrate on a small subset of components (Boehm [Boehm88a] quotes a rule of thumb that 20 percent of a software system is responsible for 80 percent of its errors, cost and rework) has lead to research into pattern recognition or classification based approaches to identify and predict high risk components based on historical data. Porter proposed a ....

B. W. Boehm and P. N. Papaccio, "Understanding and Controlling Software Costs," IEEE Transactions on Software Engineering, vol. 14, pp. 1462-1477, 1988. 37

....be isolated in the logical representations only manifest themselves once coding and testing have begun. Since the costs associated with product adaptation are generally far higher at the code test stage, early detection of potential problems is of paramount concern from an economic standpoint (Boehm and Papaccio, 1988). Moreover, early assessment can also enhance the efficiency of resource allocation procedures, providing another opportunity for cost reduction (Lennselius et al. 1987) Useful measures that are available early in the development process are therefore generally preferred. 2.2 The Impact of ....

Boehm, B.W. and Papaccio, P.N., "Understanding and Controlling Software Costs", IEEE Transactions on Software Engineering 14 (10), October 1988, pp. 1462-1477.

No context found.

B. W. Boehm and P. N. Papaccio, "Understanding and Controlling Software Costs," IEEE Transactions on Software Engineering, 14(10), pp. 1462-1477, 1988.

No context found.

B. W. Boehm and P. N. Papaccio, "Understanding and Controlling Software Costs," IEEE Trans. on Software Engineering, vol. 14, no. 10, pp. 1462--1477, October 1988.

No context found.

Boehm, B. and P. Papaccio, "Understanding and Controlling Software Costs", IEEE Transactions on Software Engineering, Vol. SE-14, No. 10, pp. 1462- 1477, October 1988.

No context found.

Boehm, B. W., and Papaccio, P. N., "Understanding and Controlling Software Costs," IEEE Transactions on Software Engineering, October, 1988, pp. 14621477.

No context found.

Boehm, B. and P. Papaccio, "Understanding and Controlling Software Costs", IEEE Transactions on Software Engineering, Vol. SE-14, No. 10, pp. 1462-- 1477, October 1988.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC