The diagram above looks like the bottom of the one in Overview of Semi-Classical Estimating. As a brief review, the development environment is applied to the consumer product size, made up of both estimated function points and enriched SNAP points, to arrive at the producer product size. This size is the primary driver to a mathematical model that will generate the project effort and schedule. In the original diagram, it was specified that the both traditional and agile cost drivers were applied. In this diagram, we have specified that COCOMO and CORADMO were the models that should be used. The diagram specifies COCOMO i because it might be either COCOMO I, COCOMO II or COCOMO III.
When it was developed, the first version of the Constructive Cost Model (COCOMO) was simply called COCOMO. When COCOMO II was released, there had to be a way to distinguish between the two of them. Obviously, some people referred to this first release as COCOMO I. Others called it COCOMO 81, after the year that it was published. In any case, COCOMO 81 was really a family of models. There was Basic, Intermediate and Detailed versions. There were really two variations of Intermediate COCOMO. The thing that they all have in common is that source lines of code (SLOC) is the primary driver for the model. This is not surprising. At that time, project managers normally estimated based on SLOC. They felt they knew how many SLOC the members of there team would produce across the life of the project. They knew that if there team members could produce 500 SLOC per month across the life cycle, then they would be writing 1,000 SLOC during the coding phase. These numbers were very tricky because they would change based on the size and staffing level of the project. COCOMO allowed account for these. COCOMO explained why projects could only be compressed so much and that you could not trade staff months for staff level. In other words, you could not take a project that was estimated for 10 people for 12 months and run it with 20 people for 6 months. This has been an issue for some agile proponents who say that you can add staff to an agile project without penalty. If this is true, it is only true to a certain extent. When the team size exceeds 9, it is questionable whether you still have an agile project at all.
At about the same time that Barry Boehm (no relation to Raymond Boehm) was developing COCOMO, Allan Albrecht was developing the function point measure. It was not considered in COCOMO 81. It seemed that SLOC and function points were like apples and oranges. You could count SLOC or function points, but you could not translate one into the other. Then, Capers Jones looked at the problem. He wanted to be able to estimate the number of function points in an existing system based on the number SLOC. He did the analysis on existing systems and developed tables that would convert SLOC into function points. For example, if an application required 125,000 SLOC of COBOL, then it was probably about 1,000 function points. The technique was called backfiring. Estimating professionals started using the tables in reverse to turn the number of function points into SLOC. For example, if they counted 1,000 function points for a development project, they estimated that it would take 125,000 SLOC of COBOL to implement it. The 125,000 SLOC could be fed into COCOMO to estimate how long it might take to develop the software.
Between 1995 and 2000, copies of COCOMO II started to surface. The book, Software Cost Estimation with COCOMO II, along with a CD was released in 2000. COCOMO II is substantially different from COCOMO 81. On the input side, it accepts either SLOC or function points. If you enter function points, then you must enter the programming language. This lets COCOMO II do the equivalent of a reverse backfiring. COCOMO II has two models, an Early Design model and a Post-Architecture model. Both models use the same size input. However, the Early Design model has less cost drivers because it is assumed that you know less about the nature of the project than you will at Post-Architecture time. The COCOMO II book also describes an application point model that might be used in an Integrated Computer-Aided Software Engineering (ICASE) environment. There are other members of the COCOMO II Suite including a COnstructive Commercial-Off-the Shelf (COCOTS) integration cost moel, a COnstructive QUALity MOdel that deals with defect introduction and removal, the COnstructive PROcess-Improvement MOdel (COPROMO) to estimate productivity gains that might result from new processes or technologies and Expert COCOMO with can be used for project risk assessment.
Both COCOMO 81 and COCOMO II used cost drivers. (Not Basic COCOMO 81 but the other models did.) They were similar but the COCOMO II versions were more refined. In either case, not all 1,000 function point applications would be expected to require the same effort and schedule to implement. Both COCOMO 81 (except the Basic model) and COCOMO II use cost drivers. These alter the estimated schedule and effort based on several factors. There are drivers that pertain to the application being developed. For example, is reliability a big consideration. It is for anything that is real-time and embedded into medical equipment; it may not be for a dating application. There are drivers that are associated with the development process. For example, are their full life cycle Computer Aides Software Engineering (CASE) tools in use? There is a provision to specify the capabilities and experience of the team that is building the application.
In summary, with COCOMO II we have modern size measurements being used. We have drivers for many of the vagaries of system development. Now if it estimated for an agile development process we would be all set. It does not. As Meat Loaf always sang, “two out of three ain’t bad.” Unfortunately, two out of three is not enough. For that reason, two other models were added to the COCOMO II Suite: The COnstructive Rapid Application Development (RAD) schedule estimation MOdel (CORADMO) and its companion, the COnstructive Phased Schedule & Effort MOdel (COPSEMO). CORADMO utilizes COPSEMO so any future references to the former implies use of the latter. CORADMO basically took the result of COCOMO II and adjusted it for non-waterfall software development using a variety of techniques that are typically found in agile development. From a semi-classical estimating perspective, these models together can be used to estimate the first release of an agile project. Subsequent releases often use enriched SNAP points, which are outside the scope of COCOMO II.
In 2011, I published An Approach to Early Lifecycle Estimating for Agile Projects. The thesis presented an approach to estimating functional size early in the life cycle. However, to illustrate how estimates could be done, I used USC COCOMO II.2000.0. and CORADMO to generate an estimate of effort and schedule for one of the functional estimates.
In 2014, Govind Singh Rajput and Ratnesh Litoriya published Conrad Agile Method for Agile Software Cost Estimation. Their model used COCOMO II and the COPSEMO extension. It basically modifies CORADMO for an agile development environment. It is designed to estimate for Dynamic Systems Development Method (DSDM), Agile Unified Process (AUP), Scrum, Feature-driven Development (FDD) and Adaptive Software Development (ASD). They have added cost drivers for Multi-Site Development (MULSITE) and Daily Basis Customer Interaction with Vendor Teams (DBCI). Agile practitioners find multi-site development to be disadvantageous, but it is a fact of life in many work environments today. Likewise, interaction, and hopefully co-location, with customers is a must with agile development but sometimes customer interaction may be limited. The authors claim that Degree of Collaboration Support (DCLAB) is also new, but it appears to be the same as the existing CORADMO driver Collaboration Efficiency (CLAB). In CORADMO, CLAB is a function of the COCOMO II Multisite Development (SITE), Team Cohesion (TEAM) and Personnel Experience (PREX) drivers.
A few words should be said about Agile COCOMO II. It is used to do estimation by analogy. If you have a project and know all of the COCOMO II cost drivers, then you can estimate how long a similar project would take if you knew the cost drivers for that new project. If you had similar projects, then few cost drivers would be different. Using Agile COCOMO II might be simpler than using COCOMO II. This is why this model has been named Agile COCOMO II. There are no special considerations about using an agile development process.
In early 2016, the University of Southern California Center for System and Software Engineering presented an overview of he proposed COCOMO III model. There would be new and changed cost drivers. Agile development was definitely considered and story points would be one of the size drivers, along with function points and SNAP points. In less than two years, this would change.
In late 2017, the University of Southern California Center for System and Software Engineering presented an update on the progress and scope of COCOMO III. Function points and SNAP points will still be considered as the size drivers of the model. There is now no plan for story points to be driving the model. This is very reasonable given the variability of story points from project to project. Unfortunately, there is no plan to estimate agile projects at all. The only mention of agile projects is in conjunction with hybrid projects where some of the “low-medium criticality” components are developed using agile development techniques. This is good to have, but does not address the most common problems facing agile development teams. Agile development need to estimate the time and staff level until the next release. At this point, it does not look like COCOMO III will be answering this need directly.