Software Models, Extensions and Independent Models in Cocomo ...

VOL. 3, NO. 5, May 2012

ISSN 2079-8407

Journal of Emerging Trends in Computing and Information Sciences ©2009-2012 CIS Journal. All rights reserved. http://www.cisjournal.org

Software Models, Extensions and Independent Models in Cocomo Suite: A Review 1

Syed Ali Abbas and Saleem Ullah Lar, 2 Xiaofeng Liao, 3 Raja Aftab Naseem 1

PhD Scholars, College of Computer Science, Chongqing University, PR China 2 Professor, College of Computer Science, Chongqing University, PR China 3 Lecturer Computer Science, University of Azad Jammu & Kashmir

ABSTRACT Different models over the years have been proposed to support the software cost estimation processes. Cocomo (Constructive Cost Model) is one of the successful models which enabled software engineers to reliably reason about the effort and schedule estimates. Since past few years different derivative models and extensions of Cocomo have been introduced to meet the emergent needs of different aspects of system engineering and software engineering. In this paper we have presented a descriptive overview of Cocomo suite models and extensions. We have inclusively included the models in the Cocomo suite, discussed the methodology they adopt, relevant environment for their use, concept behind their development and the procedures by which they are developed. This paper provides a baseline to researchers, software organizations and practitioners to comprehend the enhancements in Cocomo suite models and differences among these derivatives. Keywords: Software Estimation, Cocomo Suite, CoQualMo, Defect Introduction, CoCOTs, Software Effort.

1. INTRODUCTION Since long the matter of interest for software engineers in the field of software cost and effort estimation are the questions: What modeling techniques can produce accurate or better results, How much time and effort is required to develop the software, and what would be the influencing cost and risk factors? The answers to these questions are enclosed in the attempts of researchers resulting into number of classical estimation models for example SDC [1], Wolverton [2], Putnam [3], Meta Model [5], and Cocomo [6] and till present where the software estimation is now coupled with the concrete concepts taken from neural networks [55][56] and fuzzy logic [58][57] to understand and monitor the dynamic process of software development, with the common goal of estimating software effort [7]. The classical estimation modeling techniques were typically developed on the basis of limited and specific data available to solve a specific problem while staying in the same development boundaries [5], hence, prohibiting the practice of such limited techniques in broader scenarios. The growing needs have led the emergence of many rapiddevelopment processes, reuse-driven approaches, reengineering, object-orientations and many other process maturity initiatives [15], which have significantly affected the precision and reliability of classical estimation techniques. Authors in [13] discussed that “….the growing need for the models to estimate different aspects of software development served as a catalyst for the creation of derivative models and extensions that could better address commercial off-the-shelf software integration, system engineering, and system-of-systems architecting and engineering”. To deal with these changing trends based on

different aspects of software development many calibrations have been made in few estimation techniques which have given birth many offspring techniques inheriting the best features of their predecessor, hence making them doubtlessly more reliable. Two techniques namely Jensen model [57] and Cocomo [6] are constantly improving and recalibrating by researchers. On one hand Jensen model has provided a base to develop many commercial tools for software products [56]. On the other hand number of software models, software extensions and independent models based on Cocomo are developed and emerged in Cocomo suite [12]. We are not aiming to defend or prove the superiority of any technique over another. We intend to present an overview of most significant features of the models in the Cocomo suite that includes software models, different extensions and independent models. Although it is not feasible to include whole literature related to cocomo suite, however we intend to comprehend the fundamentals of cocomo suite models from available literature. Cocomo suite models presented at one place will give our readers an opportunity to identify core features, understand the similarities and the differences and recognize pros and cons among them. The rest of paper is distributed as follows: Section 2 provides the overview of Software models and their extensions respectively. In section 3 we have provided the descriptive exploration of independent models appearing in Cocomo suite. In section 4 we presented other independent

683

VOL. 3, NO. 5, May 2012

ISSN 2079-8407

Journal of Emerging Trends in Computing and Information Sciences ©2009-2012 CIS Journal. All rights reserved. http://www.cisjournal.org

models in Cocomo suite and paper concludes with summary of whole discussion.

2. SOFTWARE COST COCOMO SUITE

MODELS

IN

Four models are incorporated as software cost models in Cocomo suite [12] namely (i) Cocomo 81, (ii) Cocomo II, (iii) DBA Cocomo, and (iv) CoInCoMo respectively. We are focusing our attention exclusively on Cocomo II and onwards developments while ignoring the Cocomo 81 because most of the models in the Cocomo suite are extended from Cocomo II. Other three models (Cocomo II, CoInCoMO and DBA CoCoM0) are basically the same model but adapted for different development situations [12]. DBA Cocomo serves as a database version of the existing CocomoII that is intended to provide storage for existing project data and additional functionalities to those data [14]. CoInCoMo is also based on Cocomo II with an added superstructure to accommodate multiple packages and modules. Effort can be calculated for each build or package through Cocomo II and summing it for achieving overall estimate [14]. Both these copy write models are still under progress at University of Southern California. Most of the models in Cocomo suite are developed in 7 step fashion [13]: (i) After the deep analysis of existing literature (ii) Analysis of behavior (iii) Identification of relevant significance of parameters (iv) Performing expert judgment/Delphi assessment (v) Gather project data to validate the costestimating relationships in the model (vi) Use Bayesian statistical techniques that provide the ability to balance expert data and historical data (vii) Gather more data to refine model. In forthcoming sections we have discussed the cocomo suite models. As it is mentioned before that few models in cocomo suite are still in the phase of calibrations, hence readers are advised to frequently observe for latest updates.

2.1 Cocomo II The objectives of Cocomo II [13] effort are to develop software cost database and tool support capabilities

for continuous model improvement, to provide a quantitative analytic framework, set of tools and techniques for evaluating the effects of software technology improvements on software life cycle costs and schedules [15]. Cocomo II model includes confirmed features of COCOMO 81 and Ada COCOMO models. It is designed for the modern types of software development such as business software, objectoriented software, and the soft wares based on Spiral or Evolutionary models [16][27]. Contrary to Cocomo 81 where the input was taken as KDSI and point estimates of effort and schedule were provided [30], Cocomo II uses KSLOC as input and provides a detailed nonlinear approach of software reuse effects; and also presents a family of 3 sub models [17] [26] adjusted to the information available at different stages of the development process [27]. These models are briefly introduced in following sections:

2.1.1 Application Composition Model Application Composition model is used in the early stages of development, when the focus is set on user interface prototyping, software and system interaction deliberation, performance assessment, and technology maturity [23]. It helps to compute effort and schedule of projects that use Integrated Computer Aided Software Engineering tools for rapid application development [17]. The total size is estimated in the form of application points and a nominal productivity is measured by two factors i-e developer experience and capability, and integrated computer software engineering tool maturity and capability [55]. Estimated effort is obtained by dividing the size by productivity. The initial size measure is determined by counting the number of screens, reports and the third generation components that will be used in application [19] and then each object point is classified into a complexity weight which is either simple, medium, or difficult. The original number of object instances is multiplied by the weighting factor and then summed to get the total number of object points. In composition model the new object points are computed by following expression [20]. New Object Points (NOP) ={(Object Points) – (100-%Reuse)}/100 Productivity rate, PROD, is estimated from subjective average of developer’s experience and ICASE maturity/Capability [20] and is shown in table 1.

684

VOL. 3, NO. 5, May 2012

ISSN 2079-8407

Journal of Emerging Trends in Computing and Information Sciences ©2009-2012 CIS Journal. All rights reserved. http://www.cisjournal.org

Table 1: Productivity measures for Application Composition Model Developer’s Experience/ Capability

Very Low

Low

Nominal

High

Very Low

Environment Maturity/ Capability Prod

Very Low 4

Low 7

Nominal 13

High 25

Very Low 50

The effort in Person Month PM is estimated as [20]. PM

=

(NOP)/PROD

in COCOMO and Ada COCOMO. The initial baseline schedule equation for all sub models of COCOMO II is:

2.1.2 Early Design Model

TDEV = [A * PM (0.33 + 0.2 * (B – 1.01)) ] * (SCED%)/100

Early Design model is used when a rough estimate is needed based on incomplete project and product analysis [17]. It uses to evaluate alternative software system architectures where unadjusted function point is used for sizing. The corresponding COCOMO II capability involves the use of function points and a course-grained set of 17 cost drivers [17]. The expression used for Effort estimation is given by:

Where TDEV is the calendar time in months. A is a constant value that is set to 3.0, PM is the estimated person-months excluding the Required Development Schedule (SCED) effort multiplier, B is the sum of project scale factors and SCED% is constraint imposed on the project team developing the software which refers to the percentage of schedule stretch-out or acceleration with respect to a nominal schedule for a project requiring a given amount of effort. SCED values for stretched out or accelerations given as.

PM

=

17

A * [Size’]B * ∏ EMi i =1

Where A is the constant that is set to 2.5 and is used to capture the multiplicative effects on effort with projects of increasing size. B accounts for the relative economies or diseconomies of scale encountered for software projects of different sizes [24] and obtained as:

Table 2: Required Development Schedule (SCED)

SCED

5

B

=

Very Low 75% of nominal

Low

Nominal

High

85%

100%

130%

Very High 160%

1.01 + 0.01 * ∑ SF j J=1

Where SF is sum of 5 scaling factors and that are Precedentedness, Development Flexibility, Architecture / Risk Resolution, Team Cohesion and Process maturity. The selection of scale drivers is based on the rationale that they are a significant source of exponential variation on a project’s effort or productivity variation. Each scale driver has a range of rating levels, from Very Low to Extra High [20]. EM is effort multiplier that is calculated using seven cost drivers (Product Reliability and Complexity, Developed for Reusability, Platform Difficulty, Personnel Capability and Mapping Example, Personnel Experience, Facilities, Schedule) [20]. The size is estimated with following expression. Size’

=

Size * {1+ (BRAK/100)}

Where BRAK is percentage of code thrown away due to requirements volatility [20]. The initial version of COCOMO II provides a simple schedule estimation capability similar to those

2.1.3 Post-Architecture Model Post Architecture model is used when top level design is complete and detailed information about the project is known [17]. The post architecture model includes a set of 17 cost drivers [20] and a set of 5 factors determining the projects scaling component [19]. The equations for effort estimation, size and development time are the same as in Early design modeling differing only in the case of cost drivers and it can also be used to estimate the Maintenance effort [20]. 17

PM

=

A * [Size’]B * ∏ EMi i =1

3. SOFTWARE EXTENSIONS COCOMO SUITE

IN

This section includes the discussion on the models that are software extensions in Cocomo Suite [12]. Security Extension 2004 is not included in our

685

VOL. 3, NO. 5, May 2012

ISSN 2079-8407

Journal of Emerging Trends in Computing and Information Sciences ©2009-2012 CIS Journal. All rights reserved. http://www.cisjournal.org

discussion due to its limited availability. Rest of models is presented below.

3.1 CoQualMo COnstructive QUALity MOdel (CoQualMo) is proposed by Sunita Chulani and Barry Boehm [31] that correlates cost, schedule and quality factors in software development process [31]. CoQualMo specifically focuses on quality cost intended to estimate cost earlier in the development period and it uses coarse-grained categories of defect-detection techniques [32] hence allowing determining an estimate of the number of faults contained in the software [33]. Coqualmo helps to predict potential defect density in the system by adding defect introduction and defect removal parameters in its predecessor Cocomo [34]. CoQualMo works on the basic concept derived from Boehm’s defect introduction and removal model [6] and Capers Jones’ tank and pipe model [35] where defects abstractly flow into a tank, just like water tank system, through various defect source pipes. Defects are introduced and removed by additional pipes representing processes that may introduce or remove defects from the system [36]. CoQualMo represents these defects introduction and removal into two sub-models, namely Defect Introduction Sub Model and Defect Removal Sub Model [31].

3.1.1 Defect Introduction (DI) Sub Model The input to Defect Introduction model includes Source Lines of Code and/or Function Points as the sizing parameter, and set of 21 multiplicative DIdrivers [table I, 31] derived from a subset of the cost drivers from COCOMO II [13]. These drivers are divided into four categories namely platform, product, personnel and project. The output to this Defect Introduction DI model is the predicted number of defects detected during software process [37] with Critical, high or medium impact [31]. The expression used by authors in [31] for defect introduction is given as: 3

∑ A j * (Size) Bj * QAF j j =1

Where j is the three phases of life cycle, i-e requirements, design and code, A is the multiplicative calibration constant, Size of the software project measured in terms of thousands of Source Lines of Code, B refers to economies / diseconomies of scale initially set to 1, and QAF (Quality Adjustment Factor) is the Defect Introduction driver for the jth artifact and the ith factor [31]. For details see [31] [38].

Authors in [31] assigned numerical values with expert judgment to each of the ratings of the DI drivers to provide Defect Introduction model a pragmatic base. The set of values proposed by authors [table II, 31] demonstrates that if defect introduction driver’s value is greater than 1 then it has a damaging effect on the number of defects introduced otherwise less number of defects are introduced [31]. Some initial data analysis yielded 9 requirement defects/KSLOC, 19 design defects/KSLOC, and 33 code defects/KSLOC nominal Defect Introduction rates for COQUALMO[39].

3.1.2 Defect Removal (DR) Sub Model DR model covers the identification and elimination of defects in later phases of the software project [36] and estimates the number of defects removed by several defect removal activities namely Automated Analysis( includes syntax, code etc analyzers), People Reviews( peer group related activities) and Execution Testing and Tools (tools used for testing )[31]. Each profile has 6 levels of increasing defect removal capability with ‘Very Low’ as the least effective and ‘Extra High’ being the most effective in defect removal [Table 3, 31]. The Very Low defect removal rating yields high delivered defect density, on the other hand an Extra High rating can reduce the delivered defect density [13]. Authors in [31] formulated the initial version of their defect removal expression for any single artifact j as: DRes EST, j = C j * DI Est, j * ∏ ( 1 – DRF ij) i Where DResEst,j is estimated residual defects for jth artifact, Cj is Calibration Constant for the jth artifact DIEst,j Estimated number of defects of artifact type j introduced i = 1 to 3 for each DR profile, and DRFij is Defect Removal Fraction for defect removal profile i and artifact type j[31]. CoQualMo’s sub models can be integrated with Cocomo II by adding up defect removal profile levels with Cocomo II attributes to predict the number of non-trivial residual requirements, design and code defects along with the size estimates [31]. This model provides well enough insight into determining the impacts of defect introduction and removal on quality.

3.2 iDAVE Information Dependability Attribute Value Enhancement (iDAVE) model is developed as a value-

686

VOL. 3, NO. 5, May 2012

ISSN 2079-8407

Journal of Emerging Trends in Computing and Information Sciences ©2009-2012 CIS Journal. All rights reserved. http://www.cisjournal.org

based model with the objectives to identify an appropriate dependability investment level(s) for a software project with dependability requirements as different stakeholders depend on different system capabilities (such as availability, safety, or security) in different situations [41]. iDAVE estimates the Return On Investment (ROI) [12] to achieve desired values for dependability attributes starting from the baseline dependability investment level. iDave model provides a quantitative practice for stakeholders to establish their satisfactory and preferred levels of availability requirements for different software/scenario based on their different ROI [40]. The basic iDAVE is the amalgamation of cost estimating relationships (CER’s) from the Constructive Cost Model COCOMO II, dependability estimating relationships (DER’s) from the Constructive Quality Model COQUALMO, and value estimating relationships (VER’s) supplied by the system’s stakeholders[40]. Cost Estimating Relationships CER’s from Cocomo II facilitates to express time-phased information processing capabilities, and to estimate time-phased investment costs in terms of size and other project attributes [40]. Dependability-attributeestimating relationships DER’s from the COQUALMO facilitates to specify time-phased levels of investment in improving dependability attributes, from which COQUALMO estimates the resulting time-phased dependability attribute levels[41]. Finally, the iDAVE model needs initial dependability value estimating relationships (VER’s) to relate estimated cost investments and dependability levels to resulting benefit flows and return on investment (ROI) estimates[40][41]. For more information on the overall structure of iDAVE see [14] [40] [41].

3.3 Constructive Rapid Application Development Model (CORADMO) CoRADMo is a Cocomo II extension that focuses on software development cost by using RAD techniques. CORADMO estimates the schedule (months), Personnel and Effort (person month) based on the distribution of effort and schedule to the various stages, and impacts of the selected schedule [52]. The

CoRADMo model has following five drivers having its rating level and environment to be used [4].

Reuse and Very High Level Language (RHVL) reflects the impact of reuse of code and/or the use of very high level languages specifically during Inception and Elaboration stages. Development Process Reengineering and Streamlining (DPRS) captures the degree to which the project and organizations allow streamlined or reengineered development processes. Collaboration Efficiency (CLAB) captures the possible reduction in schedule and effort due to the effective collaborations among team and team members. Architecture / Risk Resolution (RESL) enables parallel construction activities without the COCOMO II assumed effect of increased integration and testing costs. Prepositioning Assets (PPOS) reflects the degree to which assets are pre-tailored and furnished to the project for use on demand. For more details on Coradmo drivers refer [52]. CORADMO needs a phased schedule and effort distribution because the effects of the RAD strategies are different for the different stages in life cycle [54] [4]. This input is acquired from another Cocomo suite model that is Constructive Phased Schedule and Effort Model (COPSEMO) which intended to estimate schedule in months, personnel required and adjusted effort in person months. COPSEMO is based on the distribution of effort and schedule to the various stages, and impacts of the selected schedule driver ratings on the schedule, Personnel and Effort [4]. Cocomo suite also includes a senior management strategic planning decision assistant model supported by an implementation approach. It is Constructive Productivity-Improvement Model (COPROMO) which is based on the use of COCOMO II and CORADMO as valuation mechanisms [53]. For more details on COPROPMO and COPSEMO visit http://csse.usc.edu/csse/.

3.4 COPLIMO Most of the models today usually underestimate Return On Investment (ROI) for product lines and apply writing for reuse to the entire product. Barry Boehm addresses these shortfalls in his Constructive Product Line Investment Model (COPLIMO) which is based on relative cost of reuse and relative cost of writing reuse. The focus of

687

VOL. 3, NO. 5, May 2012

ISSN 2079-8407

Journal of Emerging Trends in Computing and Information Sciences ©2009-2012 CIS Journal. All rights reserved. http://www.cisjournal.org

COPLIMO is on the modeling of proportions of the software that product-specific newly built software, fully reused black box product line component and product line component that are reused with adaptation [21]. COPLIMO assumes the use of a set of assets for building a set of related products and relies on the availability of a range of parametric values that must be accurately calibrated [25]. COPLIMO is sectioned into basic life cycle model and an extended life cycle model. Basic model assumes that a change to a product causes the same percentage of change on reused code, adapted code and product unique code [28]. Basic model has two sub models namely development model for product line evolution and post development model for product line. Extended life cycle allows products to have different parameter values [28].

Volatility refers to the frequency with which new versions or updates of the COTS software being used in a larger system are released by the vendors over the course of the system's development and subsequent deployment. COCOTS is gradually progressing, however, the equations provided by USC(University of Southern California) COCOTS model version 1.0 to predict size, cost and effort in Person Months is given as [29]. ESIZE = UFP * (1.0 + BRAK / 100) 13

PM = A * (ESIZE) B * ∏ (Em i) i =1

Cost = (PM) * (Average Labor rate per Person Month) Where

4. OTHER ESTIMATION COCOMO SUITE

INDEPENDENT MODELS IN

Authors in [12] have grouped 4 independent models in Cocomo suite namely CoCOTS, CoSYSMo, CoSoSiMo and Costing Secure Systems 2004. Costing Secure Systems is not included in our discussion due to lack of data availability. Rest of these models is discussed below.

4.1 Constructive Commercial-Off-The Shelf CoCOTS Integration Cost Model COCOTS refers to reasonably predict the lifetime cost of Commercial-off-the-shelf COTS prebuilt components that are integrated in any existing software system to enhance its capabilities [22]. Authors in [22] have discussed following sub models of COCOTS: Assessment is the process by which COTS components are selected for use in the larger system being developed. Tailoring refers to those activities that would have to be performed to prepare a particular COTS program for use regardless of the system into which it is being incorporated or even if operating as a standalone item. Glue code development and testing refers to the new code external to the COTS component itself that must be written in order to plug the component into the larger system.

UFP = estimated sizing of the COTS glue code in Unadjusted Function Points. BRAK = estimated percentage of glue code breakage during development ESIZE = effective size of the developed glue code. A = a linear scaling constant calibrated to provide an accurate effort estimate B = a nonlinear scaling constant that accounts for the influence of factors that have exponential rather than multiplicative affects. This is temporarily set = 1 EM = the thirteen effort multipliers or cost drivers, each of which assumes one of PM = the estimated effort in person-months for the COTS integration task.

4.2 CoSoSiMo Many organizations today are concerned for more capable systems to cope with the emerging needs. One way to enhance system capabilities is the integration of any existing system with some other network centric system of systems (S-o-S) [42]. One may perceive the system-of systems as a set of systems comprised of some combination of other systems and system elements [43]. Normally the early presented cost models or tools were only focused on the development activities of a single system, hence can not properly be applied to precisely estimate the Lead System Integrator (LSI) effort associated with architecting the SoS framework [44]. When the scope of the system is specification and integration of two or more separate systems then Constructive System-ofSystems (SoS) Integration Cost Model (COSOSIMO) is the option [45] that is designed to estimate the effort associated with the Lead System Integrator (LSI) activities to define the SoS architecture, identify

688

VOL. 3, NO. 5, May 2012

ISSN 2079-8407

Journal of Emerging Trends in Computing and Information Sciences ©2009-2012 CIS Journal. All rights reserved. http://www.cisjournal.org

sources to either supply or develop the required SoS component systems, and eventually integrate and test these high level component systems [42] [46].

effort exponent for the SoS based on the SoSs exponential scale factors. The initial scale factors for CoSoSiMo included:

The first version of COSOSIMO [Lane 2004] was based upon expert judgment of key members of the COCOMO Working Group and a hierarchical view of SoS architectures [42]. It is a two-tiered model to calculate the number of integration person months (IPM) required for the SoS LSI effort [42]: ni

Level 1 IPM (Si) =

A1[∑ Sij ]Bi J=1

Level 0 IPM (SoS) =

m Ao [∑ IPM (Si)]B0 j=1

Where IPM Integration effort in person-months, Sij is the size of ijth subsystem within the SoS, A Constant derived from historical project data, ni is the number of subsystem level 2 components comprising the ith subsystem, m is the number of subsystem level 1 components comprising the SoS, Bi is the effort exponent for the ith subsystem based on the subsystem’s exponential scale factors and B0 is the

• • • • • •

Integration Simplicity Integration Risk resolution Integration Stability Component Readiness Integration Team Capability Maturity of the integration Process

For details on scaling factors of CoSoSiMo see [42] [47]. Recent calibrations in COSOSIMO have resulted three sub-models namely: Planning/Requirements Management/Architecture (PRA) sub-model; Source Selection and Supplier oversight(SS) sub-model; and an SoS Integration and Testing (I&T) sub-model [47][48]. The summary of these three sub-models is presented in table 3 including their size and cost drivers. Information in table 3 is obtained from [47] and can be referred for details on size and cost drivers in CoSoSiMo sub-models.

Table 3: CoSoSiMo Sub-models Summary Sub-Model

Activities associated with SoS concept development, requirements identification, Analysis and evolution.

Planning, Req. Management, Architecture(PRA)

Source Selection and Supplier Oversight (SS)

Integration and Testing I&T

Identification of system suppliers and vendors, the development of Requests for Proposals, evaluation of supplier/vendor responses, selection of suppliers/vendors, on-going oversight of supplier/vendor performance

Integration and Test planning, set up of the integration and test

Cost Drivers 1.Requirements Understanding 2. Level of Service Requirement. 3. SoS Stakeholder Team Cohesion. 4.LSI PRA Team Capability 5.LSI PRA Process Maturity 6.PRA tool Support 7.PRA cost/Schedule Compatibility 8.SoS PRA Risk Resolution 1.Requirements Understanding 2. Architecture Maturity 3. Level of Service Requirement. 4. LSI Supplier Team Cohesion. 5.LSI SS Team Capability 6.LSI SS Process Maturity 7.SS tool Support 8.SS process cost/Schedule Compatibility 9.SoS SS Risk Resolution 1.Requirements Understanding 2. Architecture Maturity

Size Drivers 1. Number of SoS related Requirements. 2. Number of SoS Interface Protocols.

1. Number of Independent Component System Organizations. 2. Number of Unique Component Systems

1. Number of SoS Interface Protocols 2. Number of

689

VOL. 3, NO. 5, May 2012

ISSN 2079-8407

Journal of Emerging Trends in Computing and Information Sciences ©2009-2012 CIS Journal. All rights reserved. http://www.cisjournal.org

environments and tools, development of test data and procedures, and the actual execution and tracking of integration, verification/validation tests

Efforts are currently underway to review and calibrate the model. This model is a good effort in order to support activities for estimating the LSI effort that may allow users to develop initial estimates and then accomplish tradeoffs based on architecture and development process alternatives [44].

4.3 CoSYSMo The objective of CoSYSMo (Constructive Systems Engineering Cost Model) is to provide accurate, pragmatic and tailor able estimates for time and effort related with system engineering tasks provided by ISO/IEC 15288 [49]. CoSYSMo has gone through three iterations discussed below [50]. The first version of COSYSMO (Straw man CoSYSMo) contained 16 systems engineering cost drivers. The factors identified were named application factors and team factors. Function points and use cases are recognized as measures of systems engineering functional size. CoSYSMo-IP is 2nd version which is a revised set of cost drivers incorporated measures for functional size that were independent of the software size. This version has provided three different types of parameters namely additive, multiplicative, and exponential. The current version, referred simply as COSYSMO is designed to estimate the number of person months as a function of a system’s functional size with considerations of diseconomies of scale. The size and cost drivers were determined with a Delphi approach (For details on cost and size drivers refer [51]) which resulted in the emergence of following regression equation of the model [49] [50]. Effort

=

A ∏ c i (Size) p

Where A is calibration constant, ci is calculated as the product of i cost drivers, P represents economies/diseconomies of scale, and Size is the weighted average of the size predictors.

3. Level of Service Requirement. 4. LSI I&T Team Cohesion. 5.LSI I&T Team Capability 6.LSI I&T Process Maturity 7.I&T tool Support 8.I&T process cost/Schedule Compatibility 9.SoS I&T Risk Resolution 10. Component System Maturity and Stability. 11. Component System Readiness

Operational Scenarios. 3. Number of Unique Component Systems

5. DISCUSSION & SUMMARY This paper is an attempt to portray the primary methodologies of Cocomo suite models, logic behind their development and how they can be used to support software estimation needs. Different models over the years have been proposed to support the software cost estimation processes. Cocomo is one of the successful models which enabled software engineers to reliably reason about the effort and schedule estimates. As the need, scope and complexity of the software development has grown, the demands towards recalibrations also have arisen to meet these challenges. This growth ultimately results into the calibrations in Cocomo by proposing derivatives and extensions to meet with different aspects of software development like System engineering, SOS architecting and engineering, COTS integration etc. These derivations and extensions are grouped in Cocomo suite. Our study has presented an overview of the models in the Cocomo suite, their methodology, scenario for their possible use, logic behind their need and the way in which they are developed [12]. The models in Cocomo suite provide a specialized set of estimates to address specific aspects of development, hence understanding the scope of each model is a key factor to recognize the service or output it provides. Nearly every model in Cocomo suite is developed independently and no model in Cocomo suite covers the full life cycle effort for today’s large software intensive systems, which elevate complications when they are integrated. Although they can work in parallel but at certain stages overlapping is seen, for example Cocomo II is designed to estimate software effort associated with analysis and design, implementation and test, CoSYSMo estimates effort associated with system level engineering activities. It is implied that an approach may be adopted to discern between integrated set of models against unified model. To investigate a improved model to accomplish comprehensive results with the center of attention on integration of software and system engineering aspects, compatible on different platforms, flexible to accommodate

690

VOL. 3, NO. 5, May 2012

ISSN 2079-8407

Journal of Emerging Trends in Computing and Information Sciences ©2009-2012 CIS Journal. All rights reserved. http://www.cisjournal.org

changes and future trends will be a high-quality effort rather to put forward overlapping and scenario specific set of models. Perhaps it is safe to say that different techniques may be amalgamated for identifying the best attributes among them. Possibly it would be productive if researchers calibrate other formal estimation techniques, like Farr and Zagorski, Walston and Felix [58], Wolverton model [2], Kustanowitz model [59], Putnam [3] and many more, rather to propose methods to replace them.

[11]

L. A. Zadeh, “Fuzzy Set,” Information &Control, Vol. 8, pp. 338-353, 1965.

[12]

B. W. Boehm, R. Valerdi, J. Lane, and A. W. Brown, “COCOMO Suite Methodology and Evolution,” The Journal of Defense Software Engineering, pp. 20-25, 2005.

[13]

B. W. Boehm, C. Abts, A. W. Brown, S. Chulani, B. Clark, E. Horowitz, R. Madachy, D. Reifer, and B. Steece, ‘Software Cost Estimation with COCOMO II’. Prentice Hall, 2000.

[14]

http://csse.usc.edu/csse/

[15]

B. W. Boehm, B. Clark, E. Horowitz, C. Westland, R. Madachy, and R. Selby, “Cost Models for Future Software Life-cycle Processes: COCOMO 2.0,” Annals of Software Engineering Special Volume on Software Process and product Measurement, J.D. Arthur and S.M. Henry (Eds.), J.C. Baltzer AG, Science Publishers, Amsterdam, The Netherlands, pp. 45-60, 1995.

[16]

S. L. Pfleeger, F. Wu, and R. Lewis, ‘Software Cost Estimation and Sizing Methods: Issues and Guidelines’, RAND, 2005

[17]

B. B. S. Chulani, B. Clark, and B. W. Boehm, “Calibration Approach and Results of the Cocomo II Post-Architecture Model,” in Proceedings of Conference International Society Parametric Analysts (ISPA), 1998

[18]

T. Menzies, Z. Chen, J. Hihn, and K. Lum, “Selecting Best Practices for Effort Estimation,” IEEE Transactions on Software Engineering, vol. 32, no.11, pp. 883-895, 2006.

[19]

C. V. M. K. Hari, P. Reddy, J. N. S. Kumar, and G. SriRamGanesh, “Identifying the Importance of Software Reuse in COCOMO81, COCOMOII,” International Journal on Computer Science and Engineering, vol. 1, no. 3, pp. 142-147, 2009.

REFERENCES [1]

E. A. Nelson, ‘Management handbook for the estimation of computer programming costs', Systems Development Corporation, AD-A648750, 1966.

[2]

R. W. Wolverton, “The cost of developing large-scale software,” IEEE Transactions on Computing, pp. 615636, 1978.

[3]

L. H. Putnam, “A General Empirical Solution to the Macro Software Sizing and Estimating Problem,” IEEE Transaction on Software Engineering, SE-4, no. 4, pp. 345-361, 1978.

[4]

http://csse.usc.edu/csse/research/COPSEMO/

[5]

J. J. Bailey, and V. R. Basili, “A meta-model for software development resource expenditures,” in Proceedings of 5th Int. Conference on Software Engineering, IEEE/ACM/NBS, pp. 107-116, 1981.

[6]

B. W. Boehm, ‘Software Engineering Economics’. Englewood Cliffs, NJ: Prentice-Hall, 1981.

[7]

D. Kafura, S. Henry, and M. Ginter, ‘The comparison and improvement of effort estimates from three software cost models. TR 87-3, Computer Science Department, Virginia Tech, Blacksburg, VA., 1987.

[8]

A. Idri, T. M. Khoshgoftaar, and A. Abran, “Can neural networks be easily interpreted in software cost estimation?, ” in Proceedings of IEEE International Conference on Fuzzy Systems, p.1162–1167, 2002

[9]

N. Tadayon, “Neural Network Approach for Software Cost Estimation,” Proc. IEEE The International Conference on Information Technology: Coding and Computing (ITCC’05),pp. 815-818, 2005.

[21]

R. A. Gray and G. S. MacDonell, “Applications of Fuzzy Logic to Software Metric Models for Development Effort Estimation,” in Proc .of Fuzzy Information Processing Society, NAFIPS '97, Annual Meeting of the North American, p. 394-399, 1997.

B. W. Boehm, A. W. Brown, R. Madachy, and Y. Yang, “A Software Product Line Life Cycle Cost Estimation model,” In proceedings of ACM-IEEE Symposium on Empirical Software Engineering, USA., pp. 156-164, 2004.

[22]

C. Abts, B. W. Boehm, and E. B. Clark, “Empirical Observations on COTS software Integration Effort Based on the initial COCOTS calibration Databse,” In

[10]

[20]http://sunset.usc.edu/research/COCOMOII/Docs/model man.pdf

691

VOL. 3, NO. 5, May 2012

ISSN 2079-8407

Journal of Emerging Trends in Computing and Information Sciences ©2009-2012 CIS Journal. All rights reserved. http://www.cisjournal.org

the 22nd International conference on software engineering (ICSE 2000), COTS workshop, Limerick, Ireland, 2000. [34]

M. Sherriff and L. Williams, “Defect Density Estimation through Verification and Validation,” The 6th Annual High Confidence Software and Systems Conference, Lithicum Heights, pp. 111-117, April 2006.

[35]

C. Jones, “Programming defect Proceedings GUIDE, vol. 40, 1975.

[36]

A. Beckhaus, L. M. Karg, C. A. Graf, M. Grottke, and D. Neumann, “A Decision Support Scheme for Software Process Improvement Prioritization,” Software and Data Technologies, Communications in Computer and Information Science, pp. 85-93, 2011.

[37]

B. W. Boehm, C. Abts, and S. Chulani, “Software development cost estimation approaches-A survey,” Ann. Software Eng., pp. 177-205, 2000.

A. Tawileh, S. Mclntosh, B. Work, and W. Ivins, “The Dynamics of Software Testing,” in proceedings of the 25th system dynamics conference, MIT, Boston, 2007.

[38]

B. W. Boehm, R. Madachy, and C. Abts, “Future Trends: Implications in Cost Estimation Models,” CrossTalk, 2000.

D. Houston, D. Buettner, and M. Hecht, M, “Dynamic COQUALMO: Defect profiling over development cycles,” In ICSP, pp. 161–172, 2009.

[39]

L. Huang, ‘Software Quality Analysis: A ValueBased Approach’. PhD Thesis, Department of Computer Science, University of Southern California, December 2006.

[40]

L. Huang, and B. W. Boehm, “Using iDAVE to determine availability requirements,” In proceedings of the third workshop on Software Quality, Newyork, USA., 2005.

[41]

B. W. Boehm, L. Huang, A. Jain, and R. Madachy, “The ROI of Software Dependability: The iDAVE Model,” IEEE Software, vol. 21, no. 3, pp. 54-61, 2004.

[42]

J. Lane, “Factors Influencing System-of-Systems Architecting and Integration Costs,” In Proceedings of Conference on System Engineering Research, March 2005.

[43]

J. Lane, “Constructive Cost Model for System-ofSystem Integration,” 3rd ACMIEEE International Symposium on Empirical Software Engineering, Redondo Beach, CA, August, 2004

[44]

J. Lane, and B. W. Boehm, “Synthesis of Existing Cost Models to Meet System of Systems Needs,” in proceedings of Conference of Systems Engineering Research (CSER), 2006.

[23]

R. S. Pressman, ‘Software Engineering: A Practitioner’s Approach’. 6th ed., McGraw-Hill, 2005.

[24]

R. Banker, H. Chang, and C. Kemerer, “Evidence on economies of scale in software development,” Information and software technology, pp. 275–282, 1994.

[25]

[26]

[27]

[28]

J. P. Nóbrega, E. S. D. Almeida, and S. R. Lemos, “A Cost Framework Specification for Software Product Lines Scenarios,” WDBC Dec 2006 - Workshop de Desenvolvimento Baseado em Componentes, Sociedade Brasileira de Computa, 2006 http://wdbc2006.cesar.org.br/wpcontent/uploads/23948.pdf

Y. Chen, G. C. Gannod, S. James, J. S. Collofello, and S. S. Hessam, “Using Simulation to Facilitate the Study of Software Product Line Evolution,” in Proceedings of the 7th International Workshop on Principles of Software Evolution, IWPSE'04, pp. 103112.

[29] C. Abts, and B. W. Boehm, ‘COTS Software Integration Cost Modeling Study’. USC Center for Software Engineering, Los Angeles,CA., Technical Report USC- CSE 98-520, 1997 [30]http://productdevelop.blogspot.com/2011/01/Cocomo-iiconstructive-cost- estimation.html [31]

[32]

[33]

the 3rd international workshop on Software quality assurance, New York, USA., pp. 38-45, 2006.

S. Chulani, and B. W. Boehm, ‘Modeling Software Defect Introduction and Removal: COQUALMO (COnstructive QUALity MOdel)’. University of Southern California, Center for Software Engineering, Technical Report USC-CSE-99-510, 1999 S. Wagner, and S. Tilman, “Software Quality Economics for Defect- Detection Techniques Using Failure Prediction,” In Proc. 3rd Workshop on Software Quality (3-WoSQ). ACM Press, 2005. S. Wagner, “Integrating a Model of Analytical Quality Assurance into the VModell XT,” in proc. of

removal,”

692

in

VOL. 3, NO. 5, May 2012

ISSN 2079-8407

Journal of Emerging Trends in Computing and Information Sciences ©2009-2012 CIS Journal. All rights reserved. http://www.cisjournal.org

[45]http://sunset.usc.edu/classes/cs510_2009/ECs_2009/EC09a(COCOMOsuite--MadachyBrown)V3.pdf [46]

[47]

[48]

[49]

[50]

[51]

J. Lane, “System of Systems Lead System Integrators: Where do They Spend Their Time and What Makes Them More/Less Efficient: Background for COSOSIMO”. University of Southern California Center for Systems and Software Engineering, USCCSE-2005-508, 2005. J. Lane, “COSOSIMO Parameter Definitions,”. University of Southern California Center for Systems and Software Engineering, Los Angeles, USC-CSETR-2006-606, 2006.

Southern California, Industrial Engineering Department, 2009.

and

Systems

[52]http://csse.usc.edu/csse/research/CORADMO/Summary. pdf [53] http://www.ics.uci.edu/~irus/spin/flyers/99/june99.html [54]http://csse.usc.edu/csse/research/CORADMO/CORAD MO_ISPA_SCEA2001.pdf [55]

http://www.rose-hulman. edu/class/csse/csse37201110/Readings/SoftwareEstimation.pdf

[56]

http://www.seisage.net/jensen_model.htm

http://csse.usc.edu/csse/TECHRPTS/2007/usc-csse2007-704/usc-csse-2007-704.pdf

[57]

B. W. Boehm, D. J. Reifer, and R. Valerdi, “COSYSMO-IP: A Systems Engineering Cost Model,” 1st Annual Conference on Systems Integration, Hoboken, NJ., 2003.

R. W. Jensen, “A comparison of the Jensen and COCOMO schedule and cost estimation models,” in Proceedings of International Society of Parametric Analysis, pp. 96-106, 1984.

[58]

R. Valerdi, “The constructive systems engineering cost model (COSYSMO)”. PhD Thesis, University of Southern California, 2005.

C. E. Walston and C. P. Felix, "A Method of Programming measurement and Estimation," IBM Systems Journal, Vol. 16, no. 1, pp. 54-73, 1977.

[59]

A. L. Kustanowitz, “System Life Cycle Estimation (SLICE): a new approach to estimating resources for application program development,” in Proc. IEEE COMPSAC, 1977.

J. Fortune, “Estimating systems engineering reuse with the constructive systems engineering cost model (COSYSMO 2.0),” PhD Thesis, University of

693