table

By default SLOCCount uses a very simple estimating model for effort and schedule: the basic COCOMO model in the "organic" mode (see below for more about this). This model estimates effort and schedule, including design, code, test, and documentation time (both user/admin documentation and development documentation). Basic COCOMO is a nice simple model, and it's used as the default because it doesn't require any information about the code other than the SLOC count already computed.

However, basic COCOMO's accuracy is limited in part for the same reason - basic COCOMO doesn't take a number of important factors into account.
If you have the necessary information, you can improve the model's accuracy by taking these factors into account. You can at least quickly determine if the right "mode" is being used to improve accuracy. You can also use the "Intermediate COCOMO" and "Detailed COCOMO" models that take more factors into account, and are likely to produce more accurate estimates as a result. Take these estimates as just that - estimates - they're not grand truths.

To use the COCOMO model, you first need to determine if your application's mode, which can be "Organic", "embedded", or "semidetached". Most software is "organic" (which is why it's the default). Here are simple definitions of these modes:

Organic: Relatively small software teams develop software in a highly familiar, in-house environment. It has a generally stable development environment, minimal need for innovative algorithms, and requirements can be relaxed to avoid extensive rework.
Semidetached: This is an intermediate step between organic and embedded. This is generally characterized by reduced flexibility in the requirements.
Embedded: The project must operate within tight (hard-to-meet) constraints, and requirements and interface specifications are often non-negotiable. The software will be embedded in a complex environment that the software must deal with as-is.

By default, SLOCCount uses the basic COCOMO model in the organic mode. For the basic COCOMO model, here are the critical factors for --effort and --schedule:

Organic: effort factor = 2.4, exponent = 1.05; schedule factor = 2.5, exponent = 0.38
Semidetached: effort factor = 3.0, exponent = 1.12; schedule factor = 2.5, exponent = 0.35
Embedded: effort factor = 3.6, exponent = 1.20; schedule factor = 2.5, exponent = 0.32

Thus, if you want to use sloccount but the project is actually semidetached, you can use "--effort 3.0 1.12 --schedule 2.5 0.35" as options to sloccount to get a more accurate estimate.

For more accurate estimates, you can use the intermediate COCOMO models. For intermediate COCOMO, use the following figures:

Organic: effort base factor = 2.3, exponent = 1.05; schedule factor = 2.5, exponent = 0.38
Semidetached: effort base factor = 3.0, exponent = 1.12; schedule factor = 2.5, exponent = 0.35
Embedded: effort base factor = 2.8, exponent = 1.20; schedule factor = 2.5, exponent = 0.32

The intermediate COCOMO values for schedule are exactly the same as the basic COCOMO model; the starting effort values are not quite the same, as discussed in Boehm's book. However, in the intermediate COCOMO model, you don't normally use the effort factors as-is, you use various corrective factors (called cost drivers). To use these corrections, you then consider all the cost drivers, and multiply them by the effort base factor, to determine the final effort factor. Here are the cost drivers (from Boehm's book, table 8-2 and 8-3):

Cost Drivers		Ratings
ID	Driver Name	Very Low	Low	Nominal	High	Very High	Extra High
RELY	Required software reliability	0.75 (effect is slight inconvenience)	0.88 (easily recovered losses)	1.00 (recoverable losses)	1.15 (high financial loss)	1.40 (risk to human life)
DATA	Database size		0.94 (database bytes/SLOC < 10)	1.00 (D/S between 10 and 100)	1.08 (D/S between 100 and 1000)	1.16 (D/S > 1000)
CPLX	Product complexity	0.70 (mostly straightline code, simple arrays, simple expressions)	0.85	1.00	1.15	1.30	1.65 (microcode, multiple resource scheduling, device timing dependent coding)
TIME	Execution time constraint			1.00 (<50% use of available execution time)	1.11 (70% use)	1.30 (85% use)	1.66 (95% use)
STOR	Main storage constraint			1.00 (<50% use of available storage)	1.06 (70% use)	1.21 (85% use)	1.56 (95% use)
VIRT	Virtual machine (HW and OS) volatility		0.87 (major change every 12 months, minor every month)	1.00 (major change every 6 months, minor every 2 weeks)	1.15 (major change every 2 months, minor changes every week)	1.30 (major changes every 2 weeks, minor changes every 2 days)
TURN	Computer turnaround time		0.87 (interactive)	1.00 (average turnaround < 4 hours)	1.07	1.15
ACAP	Analyst capability	1.46 (15th percentile)	1.19 (35th percentile)	1.00 (55th percentile)	0.86 (75th percentile)	0.71 (90th percentile)
AEXP	Applications experience	1.29 (<= 4 months experience)	1.13 (1 year)	1.00 (3 years)	0.91 (6 years)	0.82 (12 years)
PCAP	Programmer capability	1.42 (15th percentile)	1.17 (35th percentile)	1.00 (55th percentile)	0.86 (75th percentile)	0.70 (90th percentile)
VEXP	Virtual machine experience	1.21 (<= 1 month experience)	1.10 (4 months)	1.00 (1 year)	0.90 (3 years)
LEXP	Programming language experience	1.14 (<= 1 month experience)	1.07 (4 months)	1.00 (1 year)	0.95 (3 years)
MODP	Use of "modern" programming practices (e.g. structured programming)	1.24 (No use)	1.10	1.00 (some use)	0.91	0.82 (routine use)
TOOL	Use of software tools	1.24	1.10	1.00 (basic tools)	0.91 (test tools)	0.83 (requirements, design, management, documentation tools)
SCED	Required development schedule	1.23 (75% of nominal)	1.08 (85% of nominal)	1.00 (nominal)	1.04 (130% of nominal)	1.10 (160% of nominal)

So, once all of the factors have been multiplied together, you can then use the "--effort" flag to set more accurate factors and exponents.

For example, imagine that you're examining a fairly simple application that meets the "organic" requirements. Organic projects have a base factor of 2.3 and exponents of 1.05, as noted above. We then examine all the factors to determine a corrected base factor. For this example, imagine that we determine the values of these cost drivers are as follows:

Cost Drivers		Ratings
ID	Driver Name	Rating	Multiplier
RELY	Required software reliability	Low - easily recovered losses	0.88
DATA	Database size	Low	0.94
CPLX	Product complexity	Nominal	1.00
TIME	Execution time constraint	Nominal	1.00
STOR	Main storage constraint	Nominal	1.00
VIRT	Virtual machine (HW and OS) volatility	Low (major change every 12 months, minor every month)	0.87
TURN	Computer turnaround time	Low (interactive)	0.87
ACAP	Analyst capability	Nominal (55th percentile)	1.00
AEXP	Applications experience	Nominal (3 years)	1.00
PCAP	Programmer capability	Nominal (55th percentile)	1.00
VEXP	Virtual machine experience	High (3 years)	0.90
LEXP	Programming language experience	High (3 years)	0.95
MODP	Use of "modern" programming practices (e.g. structured programming)	High (Routine use)	0.82
TOOL	Use of software tools	Nominal (basic tools)	1.00
SCED	Required development schedule	Nominal	1.00

By multiplying these driver values together in this example, we compute:

0.88*0.94*1*1*1*0.87*0.87*1*1*1*0.90*0.95*0.82*1*1

The correction from these is 0.438964094, which you multiply by the base factor (2.3 in this case) to determine a final effort factor. For this example, the final factor for the effort calculation is 1.01. You would then invoke sloccount with "--effort 1.01 1.05" to pass in the corrected factor and exponent. You don't need to use "--schedule" to set the factors (they default to the values for organic model), but you can set them manually anyway by setting "--schedule 2.5 0.38". You do need to use the --schedule option for embedded and semidetached projects. The final command would be:

sloccount --effort 1.01 1.05 --schedule 2.5 0.38 my_project