1 / 11

November 9, 2006

Extensions of COSYSMO to Represent Reuse 21 st International Forum on COCOMO and Software Cost Modeling. November 9, 2006. All models are wrong…. …but some of them are useful. Also, they may have to be modified based on experience/further analysis. Agenda.

oberon
Download Presentation

November 9, 2006

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Extensions of COSYSMO to Represent Reuse21st International Forum on COCOMO and Software Cost Modeling November 9, 2006

  2. 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. 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

More Related