Scale Factors in Delivery Decisioning

 In the COCOMO (Constructive Cost Model) software cost estimation model, scale factors are attributes that have a significant impact on the software project's effort and cost. They influence how the effort varies with the size of the project. Specifically, the COCOMO II model uses five scale factors that are considered to be exponential drivers of cost.

I must first preface that this is my interpretation of COCOMO II with ad hoc applications to form simple discussions with less technical stakeholders.

The Scale Factors start with an understanding in these areas:

1. Precedentedness (PREC): Measures how similar the current project is to past projects. Higher familiarity and experience with similar projects can reduce the effort needed.
2. Development Flexibility (FLEX): Assesses the flexibility and willingness of the project to accommodate changes in requirements. Higher flexibility can reduce the effort.
3. Architecture/Risk Resolution (RESL): Evaluates the thoroughness of the architecture, risk analysis, and mitigation. Better risk management and architecture lead to less effort.
4. Team Cohesion (TEAM): Measures the ability of the team to work well together. Higher team cohesion reduces the communication overhead and effort.
5. Process Maturity (PMAT): Reflects the maturity of the software development process. Higher maturity in processes means more efficient development, reducing effort.

Each of these scale factors is rated on a scale from "Very Low" to "Extra High" (or a similar scale), and these ratings are used to compute an exponent in the effort estimation equation. The scale factors are critical because they account for non-linearities in the software development process, making the COCOMO II model more accurate for a variety of project types and sizes.

My Approach

I created an Excel worksheet, and keep in an "Assessment Artifact Repository" for reuse across all delivery efforts. I use this form to evaluate project efforts. I use the COCOMO II approach and rate each effort according to scale and Scale Factors in order (PREC, FLEX, RESL, TEAM, PMAT - Refer to Scale Factors Used below).:

1. Very Low - thoroughly unprecedented, rigorous, little (20%), very difficult interactions, SQ-CMM Level 1 Lower
2. Low - largely unprecedented, occasional relaxation, some (40%), some difficult interactions, SQ-CMM Level 1 Upper
3. Normal - somewhat unprecedented, some relaxation, often (50%), basically cooperative interactions, SQ-CMM Level 2
4. High - generally familiar, general conformity, generally (75%), largely cooperative, SW-CMM Level 3
5. Very High - largely familiar, some conformity, mostly (90%), highly cooperative, SW-CMM Level 4
6. Extra High - thoroughly familiar, general goals, full (100%), seamless interactions, SW-CMM Level 5

Scale Factors Used

1. Project Precedentedness scale driver (PREC): If the product is similar to several previously developed projects, then the precedentedness is high.
2. Development Flexibility scale driver (FLEX): 3 factors are involved here; software conformance in relationship with pre-established requirements and external interface specifications, and third relates to inflexibilities with the first two in conjunction with early completion constraints.
3. Architecture and known Risk Resolution scale driver (RESL): These factors are based on design thoroughness by Product Design Review (PDR) and and Risk Elimination by PDR. It also relates to the Life Cycle Architecture (LCA) milestones as well as to the waterfall PDR milestones. The RESL rating is the subjective weighted average of listed characteristics.
4. Development Team cooperation and cohesion scale driver (TEAM): This scale factor accounts for the sources of project turbulence and entropy because of the difficulties in synchronizing the project's stakeholders: users, customers, developers, maintainers, interfaces, and others.
5. Process Maturity scale driver (PMAT): The procedures for determining PMAT are organized around the Capability Maturity Model (CMM) rating of the organization, project, or group.

Formulas

In the COCOMO II model, the scale factors are used to compute the exponent E in the effort estimation formula. The formula to calculate E is:

E=b+0.01×∑5i=1SFi

where:
- b is a constant, typically 0.91 in the COCOMO II model.
- SFi represents the individual scale factors (PREC, FLEX, RESL, TEAM, PMAT), each rated on a scale that usually ranges from "Very Low" to "Extra High".

The ratings for each scale factor are mapped to numerical values according to the COCOMO II guidelines. These numerical values are summed up and multiplied by 0.01, which is then added to the constant b to determine the exponent E.

The calculated exponent E is then used in the primary COCOMO II effort estimation formula:

Effort=A×SizeE×∏nj=1EMj

where:

- A is a constant (typically 2.94 in the COCOMO II model).
- Size is the size of the software project in thousands of source lines of code (KSLOC).
- EMj are the effort multipliers associated with the 17 cost drivers.

The scale factors thus play a crucial role in determining the non-linear scaling of effort with respect to the project size.

Calculations

To keep it simple, I created a worksheet with these values for each Scale Factor. Score is determined using set values in Scale Factors, Value Set order.

1. Project Precedentedness scale driver (PREC):
   1. thoroughly unprecedented, 6.20
   2. largely unprecedented, 4.96
   3. somewhat unprecedented, 3.72
   4. generally familiar, 2.48
   5. largely familiar, 1.24
   6. thoroughly familiar, 0.00
2. Development Flexibility scale driver (FLEX):
   1. rigorous, 5.07
   2. occasional relaxation, 4.05
   3. some relaxation, 3.04
   4. general conformity, 2.03
   5. some conformity, 1.01
   6. general goals, 0.00
3. Architecture and known Risk Resolution scale driver (RESL):
   1. little (20%), 7.07
   2. some (40%), 5.65
   3. often (60%), 4.24
   4. generally (75%), 2.83
   5. mostly (90%), 1.41
   6. full (100%), 0.00
4. Development Team cooperation and cohesion scale driver (TEAM):
   1. very difficult interactions, 5.48
   2. some difficult interactions, 4.38
   3. basically cooperative interactions, 3.29
   4. largely cooperative, 2.19
   5. highly cooperative, 1.10
   6. seamless interactions, 0.00
5. Process Maturity scale driver (PMAT):
   1. SW-CMM Level 1 Lower, 7.80
   2. SW-CMM Level 1 Upper, 6.24
   3. SW-CMM Level 2, 4.68
   4. SW-CMM Level 3, 3.12
   5. SW-CMM Level 4, 1.56
   6. SW-CMM Level 5, 0.00

Worksheet Approach

How this works is that we select a scale, from Worst Case to Best Case, from Very Low to Extra High, and down through PREC, FLEX, RESL, TEAM, and PMAT.

• Worst Case scales thoroughly unprecedented (very low) and largely unprecedented (low)
• Case scales somewhat unprecedented (normal) and generally familiar (high)
• Best Case scales largely familiar (very high) and thoroughly familiar (extra high)

The Best Case score is 0.00 (zero). Each Scale Factor will have separate value selection.

For example, IF

• PREC == 3.72
• FLEX == 3.04
• RESL == 5.65
• TEAM == 4.38
• PMAT == 6.24

Would yield a total score of 23.03 where the results fall under Worst Case, Case, or Best Case. Ranges are:

• Worst Case between 31.62 and 25.28
• Case between 18.97 and 12.61
• Best Case between 6.32 and 0.00

This is a very quick and simple approach to achieving results that help driving decision making in the Delivery Exercises.

A Simpler Approach

We could look at the entire collection of Scale Factors and use a rating of 1 through 6 where

1 is Very Low
2 is Low
3 is Normal
4 is High
5 is Very High
6 is Extra High

In this case a 5 or 6 rating would be Best Case, where a rating of 3 or 4 would be Case, and a rating of 1 or 2 would be Worst Case. These quick outcomes could drive Decision Making on whether to proceed with Human Resources and/or Architecture. Of course, Best Case would yield the results and decision paths, while a Case outcome may lead to further Risk Assessments for the Architecture Value Chain Proposition (AVCP).

Code Approach

Using Software Code, approach results to calculate the exponent and effort...

Total scores can then be used by ML/AI to predict the outcome of the effort (project, delivery, sprint, etc.). We could write the code in R to get the exponent E as:

# Define the constant b
b <- 0.91

# Define the scale factors (SF1, SF2, SF3, SF4, SF5)
SF1 <- 3.5 # Example value for PREC
SF2 <- 2.8 # Example value for FLEX
SF3 <- 4.2 # Example value for RESL
SF4 <- 3.0 # Example value for TEAM
SF5 <- 5.0 # Example value for PMAT

# Calculate the sum of the scale factors
sum_SF <- SF1 + SF2 + SF3 + SF4 + SF5

# Calculate the exponent E
E <- b + 0.01 * sum_SF

# Print the result
print(E)

The calculated Effort using R

# Define the constant A
A <- 2.94

# Define the size of the software project in KSLOC (thousands of source lines of code)
Size <- 100 # Example value for Size

# Define the exponent E (calculated previously)
E <- 1.07 # Example value for E, you can use the previous calculation here

# Define the effort multipliers (EM1, EM2, ..., EMn)
EM1 <- 1.10 # Example value for an effort multiplier
EM2 <- 0.95 # Example value for another effort multiplier
EM3 <- 1.30 # Example value for another effort multiplier
# Add as many effort multipliers as required

# Combine the effort multipliers into a vector
EM <- c(EM1, EM2, EM3) # Add all effort multipliers here

# Calculate the product of the effort multipliers
product_EM <- prod(EM)

# Calculate the effort
Effort <- A * (Size^E) * product_EM

# Print the result
print(Effort)

Replace the example values for Size, E, and the effort multipliers (EM1, EM2, etc.) with the actual values for your project. This code will calculate and print the effort required for the software project.

Conclusion

There are many ways to assess effort, risk, and other factors. I usually start with the Simpler Approach, then use the Worksheet Approach to pinpoint areas of concerns. Using Sparx EA data, we can mine the results and drive Diagnostic, Predictions, and Prescribe courses of action. This is just one example I have used for the last 30 years and works. However, outside of human factors, there are many other factors to consider, such as hardware, software, location, and network. The old saying, "...only as strong as your weakest link..." applies here. The key is to be Open, Honest, and Objective.