Transforming Size into Schedule and Effort uses 26 cost drivers in the equations that are used to estimate effort and schedule. The diagram above shows how these cost drivers are divided. There are 5 scale factors. The scale factors influence the size of the project. The size is raised to a power that is a function of these 5 scale factors. Like the name implies, the effort multipliers multiply the amount of effort necessary to complete the job.  The multipliers can have values of less than one which will reduce the amount of effort necessary. The equations make a distinction between the first 16 effort multipliers and the last 5. The first 16 are taken from the COCOMO II software cost estimation model. The last 5 are from the CORADMO model which is intended to take the estimates from COCOMO and post process them based on the use of certain agile and rapid application development techniques. The CORADMO cost drivers are also used a little differently than the COCOMO ones. At least one of the CORADMO effort multipliers impacts effort and schedule differently.

While scale factors and effort multipliers are used differently by the estimating equations, from a practical point of view they are the same. An estimator must choose the most appropriate values for each of the cost drivers in order to get the best estimate of effort and schedule. A developer should also look to optimize these values when possible. For example, one of the scale factors is precedentedness measures whether the organization has experience with similar projects. A lack of experience will mean that the project will require more effort. A strategy around this might be to partner with a firm experienced with this type of project or to hire people who are experienced. The rest of the post will present the definitions and values associated with the scale factors.

Precedentedness (PREC)

This measures how much the product being developed is similar to previously developed products. Consider the organizations’s understanding of the objectives and experience working with related systems. If there is new hardware or software involved in this project, then the precedentedness will be lower. Following is a short description of the amount of prededentedness along with the scale factor values to use:

• Very Low – thoroughly unprecedented – 6.2
• Low – largely unprecedented – 4.96
• Nominal – somewhat unprecedented – 3.72
• High – generally familiar – 2.48
• Very High – largely familiar – 1.24
• Extra High – thoroughly familiar – 0

Development Flexibility (FLEX)

This measures the degree to which the product must conform to some preexisting specification. This might be a requirements document, some type of external interface specifications or both. Any premium placed on early completion also detracts from this measurement. Following is a short description of the amount of flexibility along with the scale factor values to use:

• Very Low – rigorous – 5.07
• Low – occasional relaxation – 4.05
• Nominal – some relaxation – 3.04
• High – general conformity – 2.03
• Very High – some conformity – 1.01
• Extra High – general goals – 0

Architecture / Risk Resolution (RESL)

This measure is both a scale factor and a CORADMO effort multiplier. It only needs to be evaluated once. For example, if it has a value of high for scale factor, then it must also be high for the effort multiplier. For calculation purposes, a high scale factor will have a different value than a high effort multiplier. CORADMO effort multipliers may impact effort and schedule differently.

An application’s architecture considers its user interface, use of commercial off the shelf (COTS) components, hardware, technology and performance. These components are all necessary, but all carry an element of risk. Finding out that there is a performance problem right before a schedule release can be devastating. This scaling factor/effort multiplier considers the amount of time dedicating to establishing the architecture as well as the percent of required architects that were available to the project. For the RESL rating to be extra high, 40% of the schedule should be devoted to architecture and 120% of the required architects should be available.

Risk management requires the identification of risk items as well as plans to resolve them. Risk items can be critical or non-critical. From 2 to 4 critical items are considered to be a nominal number. Following is a short description of the architecture / risk resolution showing how many of the risk items have mitigation plans along with the scale factor and effort multiplier values to use:

• Very Low – little (20%) – 7.07 for scale factor – 1 for effort/schedule multiplier
• Low – some (40%) – 5.65 for scale factor – 1 for effort/schedule multiplier
• Nominal – often (60%) – 4.24 for scale factor – 1 for effort/schedule multiplier
• High – generally (75%) – 2.83 for scale factor – .94/.95 for effort/schedule multiplier
• Very High – mostly (90%) – 1.41 for scale factor – .88/.91 for effort/schedule multiplier
• Extra High – full (100%) – 0 for scale factor – .82/.86 for effort/schedule multiplier

Team Cohesion (TEAM)

This measures the ability of the team to work together. Team does not mean only the developers. Team in this context includes all of the stakeholders. Their objectives and cultures should be consistent. They should be ready to accommodate one another’s objectives. Experience of the stakeholders in operating as a team is a plus. There should be team building activities to foster this cohesion. Following is a short description of the extent of team cohesion along with the scale factor values to use:

• Very Low – very difficult interactions – 5.48
• Low – some difficult interactions – 4.38
• Nominal – basically cooperative interactions – 3.29
• High – largely cooperative – 2.19
• Very High – highly cooperative – 1.10
• Extra High – seamless interactions – 0

Process Maturity (PMAT)

This measures the organizations process maturity as defined by the Software Engineering Institute’s (SEI) Capability Maturity Model (CMM). Following is a mapping from the SEC CMM to the scale factor values to use:

• Very Low – CMM Level 1 (lower half) – Initial – Every organization starts at this level, even if it has made no effort to identify its software development processes. – 7.80
• Low – CMMI Level 1 (upper half) – Still Initial – An organization has begun to identify and document their software development processes. – 6.24
• Nominal – CMM Level 2 – Repeatable – An organization has identified and repeatable processes that they can use for software development. – 4.68
• High – CMM Level 3 – Defined – Sets of development processes have been defined, documented and accepted as the standard practices of the organization. – 3.12
• Very High – CMM Level 4 – Managed – The software development processes are quantitatively managed using agreed upon measures and metrics. – 1.56
• Extra High – CMM Level 5 – Optimizing – At this level an organization is using the measurements and metrics that were identified in previous levels to continually improve and innovate the development processes. Very few organizations have achieved this level. – 0