Cost models for future software life cycle processes: COCOMO 2.0

Boehm, Barry; Clark, Barbara A.; Horowitz, Ellis; Westland, J. Christopher; Madachy, Raymond; Selby, Richard W.

doi:10.1007/bf02249046

Cited by 596 publications

(475 citation statements)

References 18 publications

Supporting

Mentioning

431

Contrasting

Unclassified

Order By: Relevance

“…The COCOMO II model uses as scale factors (SFs) 5 elements, which include Precedentedness (PREC), Development Flexibility (EFEX), Architecture/Risk Resolution (RESL), Team Cohesion (TEAM) required among members such as user, customer, and developer, Process Maturity (PMAT) levels in Capability Maturity Model Integration (CMMI) of a development organization. These elements are used in the scale estimation formula as variables in the form of exponents [4].…”

Section: A Software Scale Adjustment Factormentioning

confidence: 99%

An Empirical Study on Adjustment Factors to Estimate Maintenance Cost of Applications Developed Using Components

Rhew¹

2014

LNSE

View full text Add to dashboard Cite

Abstract-Recently, the efficiency of software development is dependent on the use of component modules and open source. However, these need the additional cost and effort for understanding and modification, which is basic process in software maintenance. In this research, adjustment factor which shows the maintenance cost of the black box embedded software like the component module and open source is proposed. In order to calculate the maintenance and repair adjustment factor, we have classified type of application system based on maintenance and repair specialized company K. And the methods for determine whether the adjustment factor applicable to the application is proposed. Also it confirmed that it need to adjust maintenance cost about 8% in result of an analysis of data and the discussion with the person in charge and experts about application type in which the component is included.

show abstract

Section: A Software Scale Adjustment Factormentioning

confidence: 99%

An Empirical Study on Adjustment Factors to Estimate Maintenance Cost of Applications Developed Using Components

Rhew¹

2014

LNSE

View full text Add to dashboard Cite

show abstract

“…We present a brief summary of these case studies in Table 2, so that the size of each can be well understood. In this table, object points shown in Column 4 are estimated based on how many individual screens are displayed, how many reports are produced and number of 3GL modules developed in the system [29][30] . The value of No.…”

Section: Experimental Studiesmentioning

confidence: 99%

Source Code Prioritization Using Forward Slicing for Exposing Critical Elements in a Program

Ray

Kumawat

Mohapatra

2011

J. Comput. Sci. Technol.

View full text Add to dashboard Cite

Even after thorough testing, a few bugs still remain in a program with moderate complexity. These residual bugs are randomly distributed throughout the code. We have noticed that bugs in some parts of a program cause frequent and severe failures compared to those in other parts. Then, it is necessary to take a decision about what to test more and what to test less within the testing budget. It is possible to prioritize the methods and classes of an object-oriented program according to their potential to cause failures. For this, we propose a program metric called influence metric to find the influence of a program element on the source code. First, we represent the source code into an intermediate graph called extended system dependence graph. Then, forward slicing is applied on a node of the graph to get the influence of that node. The influence metric for a method m in a program shows the number of statements of the program which directly or indirectly use the result produced by method m. We compute the influence metric for a class c based on the influence metric of all its methods. As influence metric is computed statically, it does not show the expected behavior of a class at run time. It is already known that faults in highly executed parts tend to more failures. Therefore, we have considered operational profile to find the average execution time of a class in a system. Then, classes are prioritized in the source code based on influence metric and average execution time. The priority of an element indicates the potential of the element to cause failures. Once all program elements have been prioritized, the testing effort can be apportioned so that the elements causing frequent failures will be tested thoroughly. We have conducted experiments for two well-known case studies -Library Management System and Trading Automation System -and successfully identified critical elements in the source code of each case study. We have also conducted experiments to compare our scheme with a related scheme. The experimental studies justify that our approach is more accurate than the existing ones in exposing critical elements at the implementation level.

show abstract

“…Chulani 5 and Boehm et al 6 suggested that there are several ways to estimate the cost of software engineering. The various methods available suggest that there is no one way to estimate software development cost, and that it is a subjective matter.…”

Section: Trends In Costing Systemsmentioning

confidence: 99%

Budgeting and accounting of software cost: Part 1

Seetharaman

Senthilvelmurugan

Subramanian

2005

J Digit Asset Manag

View full text Add to dashboard Cite

Many organizations today invest hugely in developing and launching information systems. The costs include labor-related consultation, software development and design fees, as well as software and hardware expenditures. However, with the subjective nature of software development, the estimation of software cost is usually inaccurate. Such organizations generally consult a software vendor to deliver information systems based on a set of specific user requirements. Deterministic approaches to software development cost are often miscalculated, however, and the end result is usually a higher cost for the customer. The scope of this study is limited to the fundamentals of software cost estimation approaches and how the results of these cost models are used to determine software cost. This paper is not a software engineering model. It focuses on only a subset of the software development lifecycle (SDLC) pertaining to the estimation of software size and cost. This paper highlights the issues determining the size of software and how they relate to the accounting and budgeting of software cost through the estimation of various software metrics to empirically predict the cost involved before starting development. The paper also discusses how project and software costs are derived from the results obtained from the cost metrics. For this purpose, a practical six-step approach is derived and presented. Finally, the limitations are discussed and a conclusion is given. The paper consists of two parts. The first part deals primarily with a survey of literature reviewing the trends in costing systems and constructive cost models. The second part of the paper will deal with selected case studies, models, discussion, analysis and findings.

show abstract

Cost models for future software life cycle processes: COCOMO 2.0

Cited by 596 publications

References 18 publications

An Empirical Study on Adjustment Factors to Estimate Maintenance Cost of Applications Developed Using Components

An Empirical Study on Adjustment Factors to Estimate Maintenance Cost of Applications Developed Using Components

Source Code Prioritization Using Forward Slicing for Exposing Critical Elements in a Program

Budgeting and accounting of software cost: Part 1

Contact Info

Product

Resources

About