4

Recently, I've been getting familiar with COCOMO II model to calculate the effort (person-months) and duration (calendar time in months) required to develop a mobile application. To calculate the effort, the following formula should be used according to COCOMO II Model Definition Manual.

PM = A * Size^E * (Product of EMs)

In the equation, Size should be expressed in KSLOC (thousands of source lines of code). How am I supposed to know KSLOC of my mobile application when no single line of code has been written yet? Do people usually just make an educated guess or do they, for example, use similar projects as a basis for their estimation? Or are there some specific methods for estimating the SLOC in situations when you don't have any code yet?

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
JZ555
  • 151
  • 1
  • 3

3 Answers3

5

The only way to get the SLOC input to COCOMO is to estimate that. There are different estimation approaches that you can use to try to come up with an estimate for the size of the software application under design. You can consider decomposition and recomposition, estimation by analogy, proxy-based estimates, and expert judgement in groups to estimate the size to use as an input into COCOMO.

The method you choose is likely to be determined by your environment. For example, if you don't have a group of knowledgable people, you really can't use expert judgement in groups. If you do, you can use any number of techniques (including the other ones that I mention) as an individual contribution to the group estimating effort.

If you have good historical projects, then you can use estimation by analogy or proxy-based estimates to compare with previous projects or components. If you have a previously made component that is similar in size and scope, then you can count that. However, if you are using a new programming language or don't have a good history of past estimates, then the best method would be to keep decomposing the work into smaller, easily estimated pieces, estimate those, and then roll the total back up.

Something else to consider would be to use function points in COCOMO II instead of SLOC. Given a set of requirements, it may be easier to count the number of function points rather than attempt to estimate the number of SLOC.

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
  • I will accept this as the answer because it explains different approaches for estimating SLOC and that was what I was looking for. However, after reading Jerry's answer, I'm seriously considering using function points instead of SLOC. – JZ555 Sep 28 '16 at 19:50
  • 1
    Boehm's "Software Engineering Economics", which originally described the COCOMO methodology, suggests doing as detailed a decomposition as possible on the proposed design, to get down to chunks small enough that you CAN do good SLOC estimates on the individual chunks, and then adding them up. – John R. Strohm Sep 28 '16 at 20:32
  • My personal enlightenment moment came in an internal fight many years ago, at a certain company. I was convinced that an estimate on an internal project was way too low, but I had to be able to prove my case. Because COCOMO was widely accepted there, I did a COCOMO estimate, as best I could. I was very surprised when I saw that COCOMO agreed very closely with my "gut instinct" estimate. When I showed my supervisor the results, she asked me if I'd be surprised to learn she'd drawn the same conclusion about the original estimate. – John R. Strohm Sep 28 '16 at 20:35
  • @JohnR.Strohm I actually have a copy of Software Engineering Economics somewhere, but I know that Steve McConnell presented a lot of methods to do estimation in Software Estimation: Demystifying the Black Art. I do think that decomposition and recomposition is probably the best method and is widely applicable, even in conjunction with other methods. – Thomas Owens Sep 28 '16 at 21:22
4

First, you should probably be aware that this has been cited as a problem with COCOMO for some time. A fair number of people think that alternatives, such as function point analysis, make more sense (and some at least claim that experience bears out its superiority).

That said, it doesn't seem to me that you've really given separate alternatives. On one hand you note: "educated guess." On the other, you point to "use similar projects as a basis for their estimation."

I think these are really the same thing. Looking at similar projects is basically just a method of educating (or maybe reeducating) yourself on project sizes. Realistically, for most people this is a nearly necessary step though. At least in my experience, most contributors on most projects don't really know how many lines of code ended up in that project without doing some looking (and given things like code reuse, that usually involves quite a bit more than running wc on the project's directory tree(s) too).

My own take: lines of code does more to distract than help. Looking at a previous project and saying: "that took about six months, and this is around twice the size, so it'll probably take around a year" tends to be at least as accurate with a lot less work. If you want to add more work to refine that, then yes, I've found function points to be a reasonable approach--it's usually fairly straightforward to translate a set of requirements into at least some notion of function points (and if you can't, it's usually because the requirements lack the detail necessary to give a meaningful estimate).

Jerry Coffin
  • 44,385
  • 5
  • 89
  • 162
  • 1
    `On one hand you note: "educated guess." On the other, you point to "use similar projects as a basis for their estimation."` I worked in aerospace for 5 years. Customers (primarily various US government agencies) can audit you and your project proposals when they submit RFPs. They liked to see parametric models like COCOMO or SLIM, especially when calibrated with industry or organizational data. Since you need to have an estimate as an input to these, being able to defend that estimate with some kind of historical data is also good. (1/2) – Thomas Owens Sep 28 '16 at 18:13
  • Having a rigorous estimation process using historical data and valid mathematical models can be useful in some environments. Those are also the types of environments where I would expect COCOMO to be used, and also the environments where the projects tend to be a fixed-price contract (especially where the proposal methodology is reviewed and the lowest bidder may not win if they can't support their bid) and have more stable up-front requirements. (2/2) – Thomas Owens Sep 28 '16 at 18:15
  • @ThomasOwens: I quite agree. If, however, you can't point to some defensible data to form the basis for your estimate, I'd question whether that guess qualifies as "educated". An educated guess requires...education. – Jerry Coffin Sep 28 '16 at 18:16
  • I guess my point is that not all educated guesses are created equal. An educated guess based on years of experience is different than being able to point at specific projects and modules and map your current project to those. Both are estimates, but not of the same quality. At the end of the day, though, I think the best thing to do would be to use function points as your input to COCOMO II rather than SLOC, since the approaches to function points are based on your current project's requirements and don't rely on the size of past projects. – Thomas Owens Sep 28 '16 at 18:19
  • I am still looking for the answer to a very simple question: "What is a function point?" There's a related question: "How do you measure function points after-the-fact, from an existing software product, to refine your estimating process?" The Wikipedia article also points out that "Albrecht observed in his research that Function Points were highly correlated to lines of code,[7] which has resulted in a questioning of the value of such a measure if a more objective measure, namely counting lines of code, is available." – John R. Strohm Sep 28 '16 at 20:28
  • @JohnR.Strohm: Care to link to that question? Isn't found in a quick search. – Jerry Coffin Sep 28 '16 at 21:07
  • @JerryCoffin: Sorry. Those are questions I personally have, not questions here on P.SE (or elsewhere in the StackExchange family). I have yet to see a definition of "function point" anywhere. I have yet too see any explanation of how to count them, that didn't involve hiring a high-dollar function points consultant. Finally, the SLOC correlation, to me, puts the final nail in the coffin. SLOC is easy to estimate, if you know what you're going to code, or can find someone who knows it. – John R. Strohm Sep 29 '16 at 13:26
  • @JohnR.Strohm: Function points are points you assign based on functionality. Basically you walk through a user specification of functionality, and estimate the complexity of each item there. Most models also ask you to estimate the degree to which you can reuse existing code. Based on those, you assign a number of points to each piece of functionality. You add those together to get the function points for the project as a whole. – Jerry Coffin Sep 29 '16 at 14:41
  • As to SLOC being easy to estimate: I've seen people claim that, but most such estimates I've seen look (to me) like Joel's famous "six to eight weeks", with little basis in reality or correlation to the final product. At least IMO, function points vs. SLOC mostly comes down to providing a framework that gives some guidance about how to get from what you *do* know to at least some meaningful estimate of what you want to know. The same procedure estimating SLOC instead of points should produce similar results. The big difference is that SLOC depends heavily on language, but points don't. – Jerry Coffin Sep 29 '16 at 14:50
  • I should probably add: quite a few function point estimation tools are basically oriented toward CRUD programs (and similar) so if you're doing something radically different from that, it may be difficult to apply them to your project. For example: http://groups.engin.umd.umich.edu/CIS/course.des/cis525/js/f00/harvey/FP_Calc.html, estimates function points based primarily on things like the number of files and customer inquiries it needs to support. Applying this to, say, writing a compiler, would be difficult at best. – Jerry Coffin Sep 29 '16 at 15:02
  • 1. It is known that your final product will be delivered in some programming language. 2. It is known that language MATTERS. It would therefore seem self-evident that your estimating process must take the language into account. SLOC estimates do this implicitly, as you are initially estimating SLOC in the language. If function points are language-independent, as you say, then a function point-based estimating process must include adjustment factors for language. – John R. Strohm Sep 29 '16 at 17:42
  • @JohnR.Strohm: On a large project, you can typically plan on multiple languages being used, and when you're doing an initial estimate, it's rarely clear exactly which parts will be implemented in what language. Yes, you probably need to adjust (to at least some degree) based on language, but probably less than most beginners think, especially for larger projects. – Jerry Coffin Sep 29 '16 at 18:06
  • @JerryCoffin, when you are planning on delivering a project with multiple computer software configuration items, each in a different language, it makes sense to estimate them separately. This is part of the "decompose/recompose" model discussed elsewhere in this question. – John R. Strohm Sep 30 '16 at 16:20
  • @JohnR.Strohm: I'll repeat (since you apparently didn't pay attention the first time) that when you're doing the estimate, it's not always clear which language(s) will be used for what parts. IOW, what you're advocating means you can't even start the estimate until long after you need it finished. – Jerry Coffin Sep 30 '16 at 16:24
  • @JerryCoffin: Language matters. Choice of language can make a significant, even massive, difference in total effort expended on a project. 30% is not unusual. Order-of-magnitude differences have been seen. Pratt & Whitney documented 2x programmer productivity improvement, at 1/4 defect density, JUST from using Ada: ALL OTHER THINGS *WERE* EQUAL. Without knowledge of your target language, your estimate AT BEST will have a much larger uncertainty in it. At worst, it may be worthless. – John R. Strohm Oct 06 '16 at 15:01
  • @JohnR.Strohm: For the moment, let's just assume that's all 100% true. Does any of that change the fact that when you estimate a large project, you won't know what language is going to be used for every single part of the project? No, it does not. That's not arrogance or condescension. That's simply facing reality. Large projects sometimes take *decades* to complete. Assuming languages you know at the time of estimation will be the best available when the project is completed what would be arrogant. – Jerry Coffin Oct 06 '16 at 15:06
1

I will provide an answer that will certainly not please you, but I have to raise your attention on some points.

In Computer Science, as for any science, before use a mathematical tool, you need to thoroughly assess if your intend use corresponds to the domain of validity of the tool. Are you sure it's the case here ?

Scientific foundation of COCOMO

Statistical estimation models such as COCOMO and alike are based on assumption on the characteristics of software and the development environment, as well as a large statistic of existing projects. The idea is that items sharing the same characteristics are relatively homogeneous.

For instance, the initial COCOMO was developed using regression analysis on a limited set of projects in one industrial branch. Of course, COCOMO II enlarges the base and the criteria taken into account. But it is also based on a statistical model assuming a large historical base. This is reminded in the manual you are referring to:

... assumptions about what life-cycle phases and labor categories are covered by its effort and schedule estimates. These and other definitions (...)were used in collecting all the data to which COCOMO II has been calibrated. If you use other definitions and assumptions, you need to either adjust the COCOMO II estimates or recalibrate its coefficients.

The method was updated in 2000. Otherwise said it dates from the prehistory. So it couldn't take into consideration technological shift in both development tools, and project management, nor characteristics of mobile development.

Do you really think that such method will TODAY have more precision on the estimates that a crystal ball found in the flea market ? -- sorry for being so direct--

The function point alternative

The function point method is something that is IMO simpler to apply than COCOMO. However, it has also its limitations:

  • first it estimates the overall effort mainly on the external characteristics of the project. This doesn't take into account boosting that you could achieve through software reuse in an object oriented world
  • again, it is based on accumulation of statistics on large number of projects, in the technology that you're targeting.

Again, do you have valid historical data here ?

Other approaches

Software estimates is a delicate subject since ever. There are a couple of methods that are less formal, but that provide usable numbers. For example:

  • analogous estimating: you take a similar project, and see how close and how different they are, and adapt the estimate accordingly. The funny thing here is that for the evaluation of the differences you work recursively: for the differences you could estimate the difference based on similar differences measured elsewhere, or you could use the other evaluation methods (including FP and COCOMO), but the level of uncertainty will be lower than starting estimate from the scratch, because you already have a common base which should in principle be a significant part of the overall. In your context, if there's no in house mobile experience, forget about this (unless you can find some existing open source projects and measure their size as starting point - but this supposes s.o. who has some experience to estimate the differences).
  • delphi method: you take a panel of experts (e.g. senior developers and/or project managers experience with the kind of project you envisage, eventually independent third parties such as expert from collaborative business partners) and come out with a group estimate. The key here, is that experts do not directly interact together, in order not to influence each other, but their individual estimates are aggregated.
  • variants where you could have direct interaction between experts are possible as well.
  • you can also take into account some risk management techniques and work for instance with a minimal and a worst case scenario to assess the rance of uncertainty.

In my own experience, these methods are extremely effective. The analogous method is good when there's significant historical data for similar projects. But when entering a new field, the delphi approach (eventually with different trust coefficient for the different participants, according to their respective success track) is I think the most effective. This is because the experts take into account all their knowledge on the project, including confidence on team effectiveness, development methods used, and the dergree o uncertainy and margin they think is necessary).

Conclusion

Some people claim all this is guestimate. They are fully right. But better start with an approximative guess to size the team and get a budget, than with no clue at all. In addition, estimating is not an exact science, and there are many potential sources of errors. So estimating must be reassessed periodically during the project.

Christophe
  • 74,672
  • 10
  • 115
  • 187