Extensions of COSYSMO to Represent Reuse

21st International Forum on COCOMO and Software Cost ModelingNovember 9, 2006

Ricardo Valerdi John Gaffney

Garry Roedler John Rieff

All models are wrong…

…but some of them are useful.Also, they may have to be modified based on experience/further analysis

3

Agenda

• Need for ability to accommodate reused and other types of non “new” requirements in COSYSMO

• Proposed approach• Derivation of Formulas

• Implementation Approach• Next steps

4

Need/Problem Addressed

• Initial (Academic) COSYSMO uses only total counts of requirements.

• COSYSMO is used for developing initial estimates as well as estimates during the course of project (for ETCs/EACs)

• Recognize that:– Actual projects can reuse requirements from prior

projects.– During the course of a project development,

requirements can be deleted or modified.– The costs of implementing new, modified, deleted,

and reused requirements differ.

5

Proposed Approach• Modify initial COSYSMO size driver counting rules to enable

representation of counts of new, modified, deleted, and reused requirements for each of the four categories of size drivers: system requirements, system interfaces, algorithms, and operational scenarios.

• Definitions of Types of Size Driver Elements– New: brand new element– Modified: existing element used with some change– Reused: existing element used without change– Deleted: element removed

• The counts of the four types are converted into one count, “equivalent new,” or “Erequirement” for each category of size driver.

– ERequirement, symbolized as ET, is analogous to “ESLOC” or equivalent new code count in the case of software.

– Similar to the software case, Erequirement is the weighted sum of the four types of requirements (e.g., new, reused), where the weights are the unit effort values relative to that for new.

6

Derivation of ET Formulas-1• Let:

– NN=count of new requirements; – NM=count of modified requirements; – NR=count of reused requirements;– ND=count of deleted requirements

• Then, NT=total count of requirements=NN+NM+NR+ND

• Define: ET=NN+(cM*NM)+(cR*NR)+(cD*ND); – Where: cM, cR, cD, are the unit effort values for a modified, a

reused, or a deleted requirement respectively, relative to that for a new requirement.

• Further, let NN=pN*NT; NM=pM*NT; NR=pR*NT; ND=pD*NT

– Where: pN, etc. are the proportions of each type of requirement,– And pN+pM+pR+pD=1

• Combining the formula for ET and relationships among NT, NN,etc. plus the fact that pN=1-pM-pR-pD, we obtain:

ET=[1-(pM*(1-cM))-(pR*(1-cR))-(pD*(1-cD))]*NT

7

Derivation of ET Formulas-2

• The factor [1-(pM*(1-cM))-(pR*(1-cR))-(pD*(1-cD))] is expected to be <1.0 usually, but could be >1.0, because:

We expect that cR≤ 1.0, but it is possible that cM>1.0 or cD>1.0 under some circumstances, and therefore, we assume only that 0<cM, 0<cR, and 0<cD.

• In the formula:ET=[1-(pM*(1-cM))-(pR*(1-cR))-(pD*(1-cD))]*NT ,

Recognize that NT symbolizes the weighted sum of the easy, nominal, and difficult requirements for any one of the four categories of size drivers, system requirements, etc.– Thus, this formula is applied for each of these four categories, and

therefore, we have ETT=Total equivalent new requirements; this is the overall COSYSMO size driver in the formula for systems engineering labor hours.

Where: ETT=∑ ETi, for i=1,2,3,4, corresponding to the four categories.

8

Implementation Approach

• Operationally, when employing the reused requirements capability in COSYSMO, the user would enter :

– The counts for the three levels of difficulty, “easy,” “nominal,” and “difficult,” for each of the four categories of requirements.

– The values of pM, cM, pR,cR, pD, and cD for each of the four categories of requirements. Note that the values of pMi, cMi, pRi , cRi ,pDi, and cDi are assumed to apply to the “easy,” “nominal,” and “difficult” counts for each category of requirement, “i.”

• The user would assign some “average” value for each of the parameters pMi, etc. that are taken to apply to all three requirements levels, e.g., “easy.”

• This approach has been incorporated into a prototype tool, called “COSYSMOR,” or “COSYSMO Risk/Reuse,” developed by John Gaffney.

– See the next page for the reuse data entry in COSYSMOR.

9

Requirements Types ** New Modified Reused DeletedPercent Rel. Cost Percent Rel Cost Percent Rel Cost Percent Rel Cost

50.00% 100.00% 20.00% 10.00% 30.00% 70.00% 0.00% 85.00%50.00% 100.00% 20.00% 10.00% 30.00% 70.00% 0.00% 85.00%50.00% 100.00% 20.00% 10.00% 30.00% 70.00% 0.00% 85.00%50.00% 100.00% 20.00% 10.00% 30.00% 70.00% 0.00% 85.00%

** Provide the Percent of each requirements category, e.g., "Systems Requirements", that is "Modified," "Reused" and "Deleted." Note that the percent that is "New" results from these three data entries automatically. Also, enter the "Relative Cost" for the "Modified," the "Reused" and the "Deleted" portions of each requirements category. The count of "Deleted" is expected to be zero for initial estimates. However, estimates revised during the course of execution of a project might well have some requirements "deleted," which would have to be reflected in a revised EAC (Estimate-At-Completion).The "Relative Cost" is the unit cost relative to that of the "New" requirements type. For example, if this figure were 10%, that would mean that that type, e.g., "Reused," costs per requirement 10% of what a new requirement of that category costs.If the % of "Modified" or "Reused" or "Deleted" differs among the "Easy," "Nominal," and "Difficult" in a category, e.g., "# of System Requirements," then you should enter the average of the three percentages.

Entry of Data Designating Requirements Types in COSYSMOR Prototype

User-defined Relative Cost and Proportions

10

Next Steps

• Test the use of the reuse capability in actual project situations.

• Extend “official” COSYSMO tool to incorporate the reuse capability

• We are rolling out the reuse capability together with schedule/labor spreading and cost “risk” estimating capabilities.

• Extend user manual coverage.• Modify model/tool implementation as

appropriate, based on experience and further analysis.

11

Author Contact Information

Ricardo Valerdi, MIT rvalerdi@MIT.EDU

John Gaffney, Lockheed Martin j.gaffney@lmco.com

Garry Roedler, Lockheed Martin garry.j.roedler@lmco.com

John Rieff, Raytheon John_E_Rieff@raytheon.com