Stephan, thanks for your comments, I totally agree and have a few additional insights that I hope you find useful. Please refer to COCOMO II estimation model manual link at the bootom of my post as it is an excellent reference and answers most of your questions.

Re: assessment of team’s capability – the model does take this into consideration, see 3.2.1.3 Personnel Factors on page 31. While it does take time to establish historical data, the model does supply default historical data – gotta start somewhere right?

Re: projects complexity – see Product Complexity (CPLX) on page 26 and subsequent tables – I think the model does a great job on factoring in complexity.

Re: mapping a user requirement to a # of LOC – this is implicitly implied in the Documentation Match to Life-Cycle Needs (DOCU) on page 29. However, you need to explicitly do so using like a requirements traceability matrix for example. One really good way I have seen this done is either mapping a use case or a feature to LOC’s.

Re: how to account for code generation, visual mappers, and really just configuring as opposed to coding – excellent question! See Counting Unadjusted Function Points (UFP) on page 4 for an approach that we have found to work on non-coded items, but are, in the end, converted into LOC’s. I have found this approach easy to do and still remain quite accurate.

As you peruse through the documentation, you will see many other factors such as the organizations maturity as related to SEI’s Capability Maturity Model, code reuse, both in the sense of reusing code from another project and developing this projects code to be reusable, etc. Pretty extensive.

While this model is not the “silver bullet,” it is, in my humble opinion, the best estimation model we have to date.