COCOMO

COCOMO ( Constructive Cost Model) is an algorithmic cost model that is used in the software development cost or effort estimates. With the help of mathematical functions is a connection between some software metrics and the cost of a project is presented.

It flows more firm-specific parameters into the calculation that determines how many person-months or person-years are necessary in order to realize a software project. Furthermore, the total duration of the project, can be estimated. COCOMO is based on diverse experience that has been made in heavy industry, such as at Boeing, in software development. The procedure was as early as 1981, developed by Barry W. Boehm, Software engineer at Boeing.

  • 2.1 ADA COCOMO
  • 2.2 COCOMO II

Method

Definitions and assumptions

  • The primary cost factors ( cost driver ) for the model are the Delivered Source Instructions ( DSI) of the project.
  • The period of development begins with the start of the product design and ends with the completion of product integration and acceptance tests. The expenses of the other phases are determined separately.
  • A COCOMO man-month or Staff Month ( SM) consists of 152 hours of work, a year of 12 months of work which in turn consist of 19 working days. That the persons month already considered vacation or sick time.
  • COCOMO is based on good management on the part of the developer and the customer, and assumes that unproductive times are kept to a minimum.
  • COCOMO assumes that the requirement specification befalls any fundamental change according to the requirements phase. A significant change in the specification also draws a change in the cost estimate itself.

Delivered Source Instructions ( DSI)

As a basis for calculating the number of lines of code to be delivered in KDSI ( 1000 ( K) delivered source instructions [1 KDSI = 1000 instructions ] ) must be determined. Only software is called Delivered, which the customer is also passed as part of the product. This definition includes code that was written for support software or testing from. The estimation of this size on many factors (eg programming language) dependent and is not handled by COCOMO. Source Instructions comply with the written and executable computer instructions from developers. In addition to the comments, this definition includes so even generated code. Instructions are largely based on the then still popular punch cards. So Boehm Instructions defined in his work as a card image. Delivered Source Instructions, as well as lines of code or function points are software metrics for measuring the size of software.

Determine complexity

Then you have to decide whether they are working on a simple ( "organic mode" ), moderate ( "semi- detached" ) or complex ( "embedded" ) project. This Projektmodi are central points in COCOMO 81, which represent the differences in the work process in the different work domains. The choice of project mode has a significant influence on the result of the calculation - the formula for the calculation remains the same and only change the coefficients.

Organic Fashion

The Organic mode corresponds to small to medium sized software projects. Most involved in the project already have in-depth experience with similar projects in this company and the used software and hardware. This ensures a low overhead in communication, since the parties already have a precise idea of ​​the product to be created. Documentation of specifications and interfaces are not strictly enforced, making this regard negotiations will be completed faster and the resulting additional costs ( diseconomies of scale) is kept low. Other features of the Organic modes are stable development environments with little new technologies, minimal need for new innovations and little time pressure.

Semidetached mode

The Semidetached mode is intended for projects where the size and complexity between organic and embedded mode can be situated. These are medium-sized projects ( between 50 and 300 KDSI ) whose components already have a medium level of experience in the development of such systems or where there is a team of experienced and inexperienced colleagues or the team has only a portion of domain experience. Projects meeting this mode are more complex, require more sophisticated interaction routines and flexible interfaces.

Embedded Mode

The embedded mode is characterized by its tight, inflexible structures and policies. This is also the biggest difference from the other two, rather loosely guided modes, dar. It aims largely on security-related projects (eg flight assistance systems, systems for banks), which are very inflexible with respect by changes in specifications and interfaces. In addition, projects of embedded fashion usually new developments with little to no comparable previous projects. For this reason, these projects are also distinguished by the fact that they start with a relatively long analysis and design phase. If these phases have been completed, as many developers are commissioned in parallel with it, to implement the system and test. This already corresponds to the test effort of intermediate projects (amounting to 8000 DSI) to large projects ( 128000 DSI) in Organic fashion.

Calculate expense

The effort PM in person months is then calculated as a factor m, multiplied by a power n of the metric number.

  • Simple:
  • Moderate:
  • Complex:

Example: At 100 KDSI the person-months are about 300 pm for a simple project, about 500 pm for a mid-heavy project and about 900 pm for a complex project.

Duration of project

However, it can not be divided by any number of people the person-months to finish the product faster. As an example, often serves the discharge of a child - this can not be shortened by the use of nine women at one month. There are certain processes that need to run sequentially, and the more people are entrusted with a project, the need to invest more in communication.

COCOMO speaks of TDEV, time to develop ( development time ). The development time in months TDEV is then, according to Komplexitätsart, calculated according to:

  • Simple:
  • Moderate:
  • Complex:
  • For a simple project with 100 KDSI the COCOMO estimation gives PM = 302 months and TDEV = 21.9 months.
  • For a medium-scale project with 100 KDSI the COCOMO estimation gives PM = 521 months and TDEV = 22.3 months.
  • For a complex project with 100 KDSI the COCOMO estimation gives PM = 904 months and TDEV = 22.1 months.

In the COCOMO calculation of TDEV the minimum period is eight months.

Cost driver factors

The Advanced COCOMO method (Intermediate COCOMO ) takes account of additional so-called cost driver factors that either increase or decrease the calculated underlying. These are based on many experiences that have been measured at large companies. Such factors include, among others:

  • Reliability of the delivered system - is a mistake only disturbing or he puts lives at risk?
  • How large is the database that needs to be created?
  • How complex are the Ein-/Ausgabeverarbeitung and data structures?
  • How fast the system must deliver results?
  • How much memory requirements of the system?
  • How often it is expected that the system must be adapted to external frame operations? Here the bandwidth varies between once a year to monthly.
  • Team factors - what experience have team members in the analysis, in the programming language used, with software tools, with this particular hardware?
  • How close is the schedule?

As an example of how these factors influence the outcome, the following calculation is used:

Complex, 128 KDSI corresponds to 1216 PM (base calculation according to COCOMO ).

Explanation: The individual factors are a " total factor " multiplied up and multiplied by the base value for the effort. Formula: Adjusted value = Underlying * ( * Reliability * complexity memory requirements * Tool Use * Schedule )

However, these values ​​are only rough experience, each company must determine for themselves their own factors costs by monitoring and analysis of previously created projects.

Development

Boehm points out, lightly apply this model: " Basic COCOMO is good for rough order of magnitude estimates of software costs, but its accuracy is Necessarily limited Because of its lack of factors to account for differences in hardware constraints, personnel quality and experience, use of modern tools and techniques, and other project attributes known to have a significant influence on costs. " ( the COCOMO - based model is well suited for a rough estimate of the range of software costs. the accuracy of the model is necessarily limited because it him missing factors for differences in the hardware used, the personnel quality and experience, the use of modern tools and technology and other features that are known to have a significant impact on cost. ). A relatively accurate result you get only taking into account several, the project acting factors (see Intermediate and Detailed COCOMO ).

ADA COCOMO

ADA COCOMO is a further development of COCOMO 81 - which is very strongly influenced by batch processing and the waterfall process model - to adapt the TRW implementation of the ADA process model. This model includes risk management, architecture Skeletons, incremental implementation and testing and standardized software metrics. Main focus of the model are to reduce the communication overhead, avoid late reworking due to unstable requirements. The amendments to COCOMO 81 can be divided into three categories:

The rest of COCOMO 81 remained unchanged - the general shape with the different modes, etc.

COCOMO II

COCOMO II was also, like its two predecessors, developed by Barry W. Boehm and the first time in 1997 published. The official version has been known, however, published in 2000 in a book. COCOMO II represents the changes in the ' modern ' software development, with adjustments to new software development process models and new development methodologies (such as object oriented programming ). There are again, as distinguished 81, three different types of estimation in COCOMO, however, that these refer to the difference increased to the level of development of the project. The division into different Projektmodi was omitted.

Criticism

The COCOMO model is very limited for the estimation of the effort of a project suitable, since it is difficult to estimate the underlying Delivered Source Instructions based on a requirements specification. It also fails to recognize that software can often be expressed in modern high-level languages ​​with fewer lines more than the languages ​​at the time as COCOMO was developed. The imprecision of this estimate makes this method unsuitable for effort estimation.

Credentials

Source lines of code Barry Boehm Carl Hanser Verlag
196176
de