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