International Journal of Modern Engineering Research (IJMER)

www.ijmer.com Vol.2, Issue.4, July-Aug. 2012 pp-2377-2383 ISSN: 2249-6645

On the Estimation of the Software Process Maturity using

COCOMO II’s Effort Estimation based on CMMI

Yousef Alkouni Alghdr1, M. Afshar Alam2, Muqeem Ahmed3

Department of Computer Science,Jamia Hamdard Delhi India
Department of computer science Jamia Millia Islamia Delhi India

Abstract: Software resource estimation methods and process. Therefore, the fundamental way of ensuring the
models have had a major impact on successful software software quality is to improve the software productivity of
engineering practice. They provide milestone budgets and the enterprises. And the software productivity of the
schedules that help projects determine when they are enterprises depends on their software development
making satisfactory progress and when they need capability, especially the maturity of software development
corrective action. The software capability maturity model is and production. Software cost estimation is the process of
a most popular model to enhance software processes with predicting the effort required to develop a software
the goal of developing best quality of the software which [3].These types of process becomes one of the major
are under the control of budget and schedule. The last challenges which also the most expensive component in
stage of updating of the software cost estimation model, software development. While software cost estimation may
constructive cost model has a different set of seventeen cost be simple in concept, it is difficult and complex in reality
drivers and a set of five scale factors. The Process maturity [4]. The different estimation models have been developed;
is one of the important five scale factors whose ratings are most of them have disappeared without any kind of
based on the software capability maturity model. This rigorous evaluation. The main reason for that was that these
paper is an attempt to determine the effect of process types of models were not good and precise enough [5]. The
maturity on the software development effort by deriving a other reason was that the people who are working in the
new set of constructive cost model II’s process maturity software development prefer to use their own estimation
rating values based on the most recent version of CMM, techniques rather than improving and applying the work of
i.e., capability maturity model integration. The effect of the the others. The most of the organizations have relied on
constructive cost model II’s process maturity scale factor is experience and „„Price-to-win‟‟ strategies for getting past
determined by considering the ideal scale factor competitors. Despite the emergence of concepts like
methodology. Precedentedness shows all prediction because of the rapidly changing technologies, the Software
accuracies compared to the generic, constructive cost Capability Maturity Model one can never rely completely
model II estimation. on experience based estimation in the software industry
which renders the experience-based estimates ineffective.
I. Introduction The price-to-win strategy is not very favorable for most of
The Software is one the most important and yet the organization [6].Hence the requirement of effective cost
one of the most economically challenging technologies of model arises to account for the effort spent on the
the current era. As a purely intellectual product, it is among developing software systems. It is an important input to
the most labor intensive, complex, and error-prone software cost estimation models. The Capability Maturity
technologies in human history [1]. The software industry is Model for software was enveloped by Software
not untouched by the quality by the quality movement that Engineering Institute to describe the principles and
dramatically affected the product of other industries. But practices underlying software process maturity. Its aim is to
constant demand from the industry for cheaper and better help organizations improve their software process maturity
software, make this goal (quality of software) more through an evolutionary path and process predictability [7].
challenging. Each and every company knows, to remain Despite the fact that the Software Engineering Institute has
competitive, it must deliver quality product at time and released the Capability Maturity Model Integration, which
within budget[2].Consequently many software companies is the updated version of the original CMM, COCOMO II
has turned to software process improvement as a way of still relies on SW-CMM to assess its process maturity scale
enhancing the quality of their products ,reducing the cost factor.
and accelerating the development process. The delivery of This paper is an attempt to describes the effect of
the software on time, within the budget and with the process maturity on software development effort by
expected functionalities and quality is a challenge for all deriving a new set of constructive cost model II‟s process
software development organizations. Inaccurate estimations maturity rating values based on the most recent version of
in software development industry is one of the most serious CMMI capability maturity model integration.
problems that cause the software failure[2].It is also well
known that the quality of software products depends on the II. Review of Literature
software development capabilities and the quality of the The Software development become an important part for
maintenance process to a great extent. Thus an organization many organizations; software estimation is gaining an ever
have no possesses well-trained developers, it will be increasing importance in effective software project
difficult to them to build the foundation which supports management. Boehm was the first researcher who
successful improvement of the software development considered the software estimation from an economic point

www.ijmer.com 2377 | Page

 International Journal of Modern Engineering Research (IJMER)
www.ijmer.com Vol.2, Issue.4, July-Aug. 2012 pp-2377-2383 ISSN: 2249-6645
of view, and came up with the cost estimation model, input, a set of seventeen Effort Multipliers or cost drivers
COCOMO in 1981, after investigating a large set of data in which are used to adjust the nominal effort to reflect the
the 1970‟s (Boehm, A, and Chulani,2000). Putnam also software product being developed. The seventeen
developed an early model known as, the Software Lifecycle COCOMO II factors are shown in Table 1 [10].
Management, (Putnam, 1978).The software estimation
includes the effort/schedule estimation, quality estimation, a. Effort Estimation
risk analysis, etc. The most accurate software estimation The equation a is formulated the COCOMO II
can provide powerful assistance for software management effort estimation model. The effort estimates by both early
decisions (Boehm, 2000). The most new computational design and post-architecture models. The inputs are the size
techniques are used for cost estimation that are non- of software development, a constant A, an exponent E, and
algorithmic in the 1990‟s. The researchers have turned their the number of Effort Multipliers (EM). The number of
attention to different approaches which are based on soft effort multipliers depends on the model being used.
computing methods that include artificial neural networks, N
fuzzy logic models and genetic algorithms. The Artificial E
neural network is able to generalize from trained data set. PM= A × SIZE × Π ΕΜi (a)
Over a known set of training data, a neural-network i=1
learning algorithm constructs rules that fit the data and
predicts previously unseen data in a reasonable manner Where the constant A=2.94, and the exponent E will be
(Schofield, 1998). The most popular estimation methods described in the bellow.
are discussed in detail by Khatibiand J (2011). The
COCOMO, SLIM and Albrect‟s function point methods b. Scale Factors
that measures the amount of functionality in a system were The study accomplished by [12] presents the conclusion
all based on linear regression techniques by collecting data that the most critical input to the COCOMO II model is
from historical project as the major input to their models. size, so, a good size estimate is very important for any good
The different algorithmic methods are deliberated as the model estimation. The Size in COCOMO II is consider as a
most popular methods and many researchers used the special cost driver, so it has an exponential factor, E. The
selected algorithmic methods (Musilek, et al. 2002; Yahiya, exponent E in equation 2 is an aggregation of five scale
et al. 2008; Lavazza and Garavaglia 2009; Yinchuan et al. factors. All scale factors have rating levels. These rating
2009; Sikka et al. 2010).The Software estimation levels are Very Low, Low, Nominal, High, Very High and
techniques can support the planning and tracking of Extra High. Each rating level has a weight W, which is a
software development projects. The efficiently controlling quantitative value used in the COCOMO II model. The five
the expensive investment of software development is of COCOMO II scale factors are shown in Table1
prime importance (Gray, MacDonell and Gray, 1997; N
Jingzhou and Guenther, 2008; Kastro and Bener, 2008;
Strike et al., 2001). ImanAttarzadeh and Siew Hock Ow E= B + 0.01× ∑ SFj (b)
(2010) proposed amodels which is based on COCOMO II j=1
and fuzzy logic to the NASA dataset and found that the
proposed model performed better than ordinary COCOMO Where B is a constant = 0.91. A and B are constant values
II model and also achieved the results which were closer devised by the COCOMO team by calibrating to the actual
to the actual effort. The relative error for proposed model effort values for the 161 projects currently in COCOMO II
using two-side Gaussian membership functions is found to database.
be lower than that of the error obtained using ordinary
COCOMO II. A novel neuro-fuzzy Constructive Cost Table 1. Scale factors of COCOMO II.
Model is used for software cost estimation and this model
Scale Factor Description
carried some of the desirable features of a neuro-fuzzy
approach, such as learning ability and good interpretability,
Precedentedness Reflects the previous experience of the
while maintaining the merits of the COCOMO model
organization.
(XishiHuang et al., 2005).
Development
Reflects the degree of flexibility in the
III. Background
Flexibility
development process.
A. COCOMO II Model
The COCOMO was originated in 1981[8], and became one
of most popular cost estimation models of the 1980s. But Risk Resolution Reflects the extent of risk analysis carried
the COCOMO faced different difficulties in the 90s, and out.
different complications in cost estimation of software that (RESL)
were developed to a new life cycle processes such as non- Reflects how well the development team
sequential and rapid development process models, reuse- Team Cohesion knows
driven approaches, and object-oriented approaches each other and work together.
[9].Thus, COCOMO II was published initially in the annals Process
of software engineering in 1995 with three sub models; an Reflects the process maturity of the
application-composition model, an early design model and Maturity organization.
a post-architecture model. The COCOMO II has, as an
www.ijmer.com 2378 | Page
 International Journal of Modern Engineering Research (IJMER)
www.ijmer.com Vol.2, Issue.4, July-Aug. 2012 pp-2377-2383 ISSN: 2249-6645
Table 2. Cost drivers of COCOMO II. lower levels to higher levels are cumulative. For example,
Cost Driver Description level 3 organizations should show compliance with all key
process areas in levels 2 and 3. The CMM process maturity
RELY Required Software Reliability framework is presented in Table 4
DATA Data base size
RUSE Developed for Reusability Table 4. The Framework of CMM.
DOCU Documentation needs
CMM
CPLX Product Complexity
Key Process Area
TIME Execution Time Constraints Level
STOR Main storage Constraints Level 1 None
PVOL Platform Volatility Requirements Management
ACAP Analyst Capability Software Project Planning
PCAP Programmer Capability Software Project Tracking and
APEX Application Experience Level 2 Oversight
PLEX Platform Experience Repeatable Software Subcontract Management
LTEX Language and Tool Experience Software Quality Assurance
PCON Personnel Continuity Software Configuration
TOOL Use of Software Tools Management
SITE Multisite Development Organization Process Focus
SCED Required Development Schedule Organization Process Definition
Training Program
The procedure for determining procedure maturity Level 3
which is the factor of interest in this study- is organized Integrated Software Management
around the SEI-CMM, Table 3 Defined
Software Product Engineering
Table 3. The rating levels ,values, and Process
Intergroup Coordination
Maturity Scale Factor.
Peer Reviews
Process CMM CMM CMM CMM CMM CMM
maturity Level 4 Quantitative Process Management
Level 1 Level 1 Level Level Level Level Managed Software Quality Management
Description Defect Prevention
(lower) (upper) 2 3 4 5 Level 5
Technology Change Management
Rating Very Very Extra Optimizing
Low Nominal High Process Change Management
Levels Low High High
All the organizations are supposed to start at level
Values 7.80 6.24 4.68 3.12 1.56 0.00 1. Which is known as Initial level? At this level, few
processes are defined, and the success depends on
individual effort which makes the software process
The CMM level 1 is for organizations that don‟t unpredictable because it changes as work progresses.
focus on processes or documenting lessons learned. The Project Schedules, budgets, functionality, and product
CMM level 1is for organizations that have implemented quality are also unpredictable. Every key process area has a
most of the requirements that would satisfy CMM level 2. set of goals, capabilities, key practices, measurements and
In CMM‟s published definition, level 1 (lower half) and verification practices. The goals state the scope, boundaries,
(Upper half) are grouped into level 1. and intent of a key process area. A key practice describes
“what” should happen in that key process area. There are a
total of 52 goals and 150 key practices.
B. The CMM Based Process Maturity
The Software Engineering Institute at Carnegie-Mellon
University published the CMM is used to rate an IV. Methodology
organization‟s process maturity [11]. It provides a number The methodology of our work is the primary data collection
of requirements that all organizations can use in setting up tool was a questionnaire that has been used to collect a data
the software processes used to control software product from individual projects, i.e., each and every questionnaire
development. There are five levels of process maturity, should be applied only on one of the project. The
level 1 (lowest half) to level 5 (highest). The CMM questionnaire is based on “COCOMO II cost estimation”
specifies “what” should be in the software process rather
than “when” or “for how long”. To be rated at a particular A. The Data Collection
level, the organization should demonstrates capabilities in The data collection procedures 55 questionnaires
a set of Key Process Areas associated with a specific distributed to 20 software development organizations, 35
CMM level. The capabilities demonstrated in moving from questionnaires were returned. Some of the questionnaires
could not be verified by project managers or senior project
www.ijmer.com 2379 | Page
 International Journal of Modern Engineering Research (IJMER)
www.ijmer.com Vol.2, Issue.4, July-Aug. 2012 pp-2377-2383 ISSN: 2249-6645
staff; therefore, 16 questionnaires were rejected and PM (P, Actual): the actual development effort for the
eliminated from this study. Therefore, 40 questionnaires project P.
were analyzed. The datasets were returned from different PM (P, Process Maturity): COCOMO II estimate excluding
fields like banking, insurance, communication, simulation, the Process Maturity Scale Factor.
web development, etc. The questionnaires were distributed
to software organizations that have already achieved one of We performed the following steps to complete the Ideal
the CMMI levels, and spanned the range of its levels, from scale factor-Process maturity analysis on our datasets:
level 1) to level 4, i.e., 8 data points were collected from 1. The first step Compute the PM (P, Scale Factor
each level. For each project, there was a meeting with the Attribute), using the following formulas:
project manager or team leader for each project, who would 17
be filling out the forms, in order to clarify each question to E
ensure that it was well understood and each manager would (d)
answer consistently. PM= A × SIZE × Π ΕΜi
i=1
B. The Data Analysis where A is a model constant, EM is a set of seventeen
The questionnaires were checked for consistency and went effort multipliers as shown in Table 1, and
through a data validation process, based on some 4
constraints determined in [6]. There are four aspects that E= B + 0.01× ∑ SF_But_ProMatj (e)
would be extracted and computed: for each questionnaire. j=1
 The set of seventeen COCOMO II's cost drivers. To Where B is a model constant, and scale factor_But the
deal with these seventeen cost drivers, we computed process maturity refers to scale factors except Process
their multiplication. A sample of the cost drivers is Maturity, including Precentedenes REC, Flexibility,
shown in Table 5. Resolution, and Team.
2. Compute the ideal scale factor (P, Scale Factor
 The set of five exponential scale factors. To deal with Attributes) using equation 6.
these five scale factors, we computed their summation. 3. Group Ideal Scale Factor (P, Scale Factor Attributes) by
A sample of these scale factors is shown in Table 6 the current CMM process maturity rating (i.e., VL, L,
(excluding the last row). N, H, VH).
4. Compute the mean value for each group as ideal scale
 The Actual effort in Person Months, which extracted for factor -Process maturity value for that rating.
the person hours, as shown in Table 7.
This step involves the computation of the mean value of
 We collected the project size as a thousand lines of ideal scale factor-process maturity for each CMM rating
code (KLOC), which is the baseline size in COCOMO level.
II.
We applied equation 1 To predict the effort in D. The Prediction Accuracy evaluation
person month, which is the basic COCOMO II‟s formula The purpose of this paper is on the degree to
[6]. At last this analysis, we got the estimated effort for the which the model‟s estimated effort measured in Person-
generic COCOMO II as well as the actual effort for this Month matches the actual effort. If the model is perfect
project. then for any project, Process maturity =Person month
matches. The most common criterion for the evaluation of
C. Ideal Scale Factor Analysis on Process Maturity the cost estimation models is the Relative Error or the
Boehm[7] has described normalization method Magnitude of Relative Error, which are shown below :
out contaminating effects of individual cost driver
attributes in order to get clear picture of that cost driver‟s Relative Error= (Person month matches-process
contribution. Since we have relatively similar situation, i.e., maturity)/process maturity (f)
we need to normalize out contaminating effects of a scale Magnitude of relative Error=(Person month Matches –
factor in process maturity rather than a cost driver. Process Maturity)│/ Process Maturity (g)
Therefore, for the given project P, compute the estimated The Relative Error and Magnitude of Relative Error values
development effort using the COCOMO II estimation are calculated for each project whose effort is predicted.
procedure, with one exception: do not include the value for Another criterion that is commonly used is the percentage
the Scale Factor Attribute being analyzed. Call this of predictions that fall within P % of the actual, denoted as
estimate PM (P, Scale Factor Attributes). Then the Ideal Predictions (P) [13],
Scale Factor, for this project/scale-factor combination is Prediction (P) = K / N (h)
defined as the value which, if used in COCOMO II, would K is the number of projects where magnitude of relative
make the estimated development effort for the project equal error is less than or equal to P, and N is the number of
to its actual development effort PM (P, Actual). i.e., projects. According to the [10], a standard method for
Ideal scale factor(P, Process Maturity) = assessing the COCOMO performance is prediction.
PM (P, Actual) / PM (P, Process Maturity) (c) Therefore we used this criterion to assess the COCOMO II
Where Ideal Scale Factor (P, Process Maturity): the ideal performance as compared to the proposed model. Table 5
scale factor on Process Maturity for project P. through Table 10 shows samples of the calculated data,
that represents one project from our forty datasets.

www.ijmer.com 2380 | Page

 International Journal of Modern Engineering Research (IJMER)
www.ijmer.com Vol.2, Issue.4, July-Aug. 2012 pp-2377-2383 ISSN: 2249-6645
Table 5. COCOMO II Effort Multipliers with their Cost Table 8. The generic COCOMO II Estimated effort.
Drivers
Cost Driver Value Description Value

RELY 1.1
∑ Scale Factors, 10.210
DATA 1 Estimated Effort, 158.04
RUSE 1
Magnitude Relative
DOCU 1.21 0.17
Error
TIME 1.26
Table 9. Ideal Scale Factor and Estimated effort without
STOR 1.01 process maturity value.

PVOL 0.77 Description Value

ACAP 0.61
∑ Scale Factors-BUT-
9.75
PCAP 0.68
Process Maturity
PCON 0.7 Estimated Effort, but-
156.14
APEX 0.71 Process Maturity

PLEX 0.75 Ideal Scale Factor, 0.92

LTEX 0.74
Table 10. Estimated effort with new process maturity
TOOL 0.68 values.
Description Value
SITE 0.76
∑ scale factors with
SCED 1 10.78
ISF-process maturity
CPLX 1.21
Estimated Effort with
163.87
Table 6. Scale factors of COCOMO II and their values. ISF-process maturity
Scale Factor Value
Precedentedness 2.62 Magnitude Relative
0.14
Flexibility 1.01
Error=
Risk Resolution 1.83
Team Cohesion 1.19
The new set of process maturity rating values under CMMI
Process Maturity .59 derived by applying our methodology to the datasets in
New process maturity .03 Table 11.

Table 7. The actual time, effort, size, estimated time,

and the cost drivers multiplication.
Description Value

Actual Time 165

Actual Effort 133.32
Size (KSLOC) 110
Estimated Time, T 173
П Cost Drivers, EM 0.344

www.ijmer.com 2381 | Page

 International Journal of Modern Engineering Research (IJMER)
www.ijmer.com Vol.2, Issue.4, July-Aug. 2012 pp-2377-2383 ISSN: 2249-6645
Table 11. The New Process Maturity Rating values. The few number of different Process Areas are assigned
Process CM CM CMMI CM CM CMM to this level, and success still depends on individual effort
maturit MI MI Leve2 MI MI I that is very low and low rating levels in COCOMO II‟s
y Leve Leve Leve Leve Leve5 procedure maturity are categorized under CMMI level 1,
Descrip 1 1 3 4 Therefore, level 1 companies still need much effort to
tion lowe Uppe accomplish their projects, particularly for CMMI level 1
r r companies that rely on “heroes” to do the jobs and do not
Rating Very low Nomina High Very Extra show any compliance that would satisfy subsequent levels.
level low l high High The second observation is the nominal and high
New 6.44 3.45 2.34 1.34 .98 0.0 rating levels demonstrated a relatively obvious reduction in
Process the procedure maturity values, which appears as a deviation
Maturi first line in Figure 2. The underlying explanation behind
ty this reduction might be due to the major additions and
Values refinements that have occurred at CMMI maturity levels 2
and 3. As an example, going from seven key process areas
In the Figure 1, X axis represents the projects used in CMM level 3, to 14 process areas in CMMI level 3, and
in CMMI level 4 organization in our study and the Y axis just two were dropped. These additions and refinements in
represents the effort. Each project has three columns: the maturity levels 2 and 3 reflect their significance and
left column represents the actual effort, the middle column definitely will reduce the effort required to develop the
represents the generic COCOMO II effort estimation, and software systems in CMMI maturity levels 2 and 3
the right column represents the effort estimation for the organizations.
proposed COCOMO II model with new Ideal Scale Factor -
Process Maturity Values. Ideal Scale Factor Process Maturity VS COCOMO II
The figure shows that how the proposed model Process Maturity
give an estimated effort which is closer to the actual effort
than generic COCOMO II estimations due to some data
anomalies, especially for low levels companies that do not
have good and precise documentations for their historical
projects. This case is not absolute, i.e., in some little cases
like in CMMI level 1 (lower and upper) and level 2
datasets, the estimated efforts by the generic COCOMO II
were relatively closer to the actual effort than the proposed
model‟s estimation.
The proposed model here is uniformly
overestimated the effort for most of the 8 projects, so it
could still be a consistent model.
The black line in Figure 2 shows the current Figure 2. The Ideal scale factor -process maturity
process maturity scale factor values used in COCOMO II. values. vs
It shows that an increase in process maturity level COCOMO II’s process maturity values.
corresponds with a reduction in project effort. It shows the
new process maturity values derived from the ideal scale E. The Results of the Model Accuracy with ideal scale
factor-process maturity analysis. factor
The improvement in the model‟s accuracy has been realized
which is shown in the below after applying the derived
ideal scale factor-process maturity values back to our
datasets, in the below Table 12.

Figure 1. The Estimated and Actual effort in both

generic COCOMO II and COCOMO II with Ideal Scale
Factor-Process Maturity.

www.ijmer.com 2382 | Page

 International Journal of Modern Engineering Research (IJMER)
www.ijmer.com Vol.2, Issue.4, July-Aug. 2012 pp-2377-2383 ISSN: 2249-6645
Table 12. The Analysis of Accuracy Results References
Improveme [1] Miyazaki Y. and Mori K., “COCOMO Evaluation
COCOMO II nt and Tailoring,” in Proceedings of ICSE 8, IEEE-
Generic ACM-BCS, pp. 292-299, 1985.
Level [2] Al-Sakran H., “Software Cost Estimation Model
with New Based on Integration of Multi Agent and Case Based
COCOMO II Process Reasoning,” Journal of Computer Science, vol. 2,
Maturity no. 3
Values [3] OLGA F, LEONOR T, HELENA A.” Software
Level 1 Effort Estimation with Multiple Linear Regression:
43% 55% 9% review and practical application” Journal of
(Lower) Information Science and Engineering xx, xxx-xxx
Level 1 2011
30% 43% 11% [4] Jones C. “Software Cost Estimation in
(Upper) 2002,”Computer Journal of Defense Software
Level 2 18% 55% 34% Engineering, vol. 15, no. 6, pp. 4-8, 2002.
[5] Miyazaki Y. and Mori K. “COCOMO Evaluation
Level 3 18% 58% 47% and Tailoring,” Proceedings of ICSE 8, IEEE-ACM-
BCS, pp. 292-299, 1985.
Level 4 30% 77% 21% [6] Dillibabu R. and Krishnaiah K., “Cost Estimation of
a Software Product Using COCOMO II.2000 Model
a Case Study,” International Journal of Project
Management, vol. 23, no. 2, pp. 297-307, 2005.
The above Table shows the analysis of accuracy
[7] Jianguo Li, Jinghui Li, and Hongbo Li,” Research on
results that by applying the ideal scale factor procedure
Software Process Improvement Model Based on
maturity values into our datasets which had been collected
CMM” World Academy of Science, Engineering and
from CMMI organizations, the accuracy in all maturity
Technology 39 2008
levels increased by 9%, 11%, 34%, 47%, and 21%
[8] Boehm B., “Software Engineering Economics”,
respectively as we have already mentioned and justified,
Prentice Hall, 1981.
that level 3 has the highest percentage of improvement, and
[9] Boehm B., Clark B., Horowitz E., Westland C.,
the level 1has lowest percentage of improvement.
Madachy R., and Selby R., “Cost Models for Future
Software Life Cycle Processes: COCOMO 2.0,”
V. Conclusions Proceedings of Special Volume on Software Process
The software development cost estimation is very and Product Measurement, Amsterdam, pp. 45-60,
important in all the aspects of project such as budgeting,
1995.
planning and effective control of management. There are [10] Boehm B., Horowitz E., Madachy R., Reifer D.,
various software cost estimation models which have Clark B., Steece B., Brown A., Chulani S., and Abts
various inputs. The most important inputs to software cost C.,”Software Cost Estimation with COCOMO II”,
estimation models is the process maturity. According to Prentice Hall, 2000.
survey, the present values for the COCOMO II process [11] Yang Y. and Clark B., “COCOMO II.2003
maturity scale factor does not adequately reflect the impact Calibration Status,” http://sunset. usc.edu /events
of CMMI-based process maturity on development efforts.
/2003/ March_ 2003 /COCOMO_ II_2003_
Therefore, by using the ideal scale factor method and with Recalibration.
the aid of our datasets, we have identified the new process
[12] Musilek P., Pedrycz W., Sun N., and Succi G., “On
maturity values which better reflect the impact of CMMI
the Sensitivity of COCOMO II Software Cost
based process maturity on software development effort.
Estimation Model,” Proceedings of the 8th IEEE
The new values provide an improvement in COCOMO II Symposium on Software Metrics, IEEE Computer
model accuracies 9% for CMMI level one, 11% for CMMI Society, Washington, pp. 13, 2002.
level one, 34% for CMMI level two, 47% for CMMI level [13] Conte S., Dunsmore H., and Shen V., “Software
three, and 21% for CMMI level four organizations. In Engineering Metrics and Models, “Menlo Park, CA,
future the amount of datasets allocated to each CMMI Benjamin/Cummings, 1986.
maturity level could be expanded to get a clearer picture of
the impact of CMMI-based process maturity on software
development effort and the locally calibrating the proposed
model parameters to a particular organization, which
requires collecting data from more projects belonging to the
same Organization.

www.ijmer.com 2383 | Page