Addressing New Technologies

Transcription

1 c S I E 1 a COCOMO 2.0: Addressing New Technologies Barry Boehm I I th COCOMOISCM Forum October 10,1996 Barry Boehm - 1

2 C I S I E I Outline + Candidate Software Silver Bullets + Likely Future Software Practices Marketplace + Challenges and COCOMO 2.0 Responses -Applications Composition - New Processes - Reuse and Product Line Management -Very High Level Languages (upcoming) - COTS Integration (upcoming) - New Software quality technologies (upcoming) + COCOMO 2.0 status + Conclusions Barry Boehm - 2

3 A c I S E Candidate Software Silver Bullets Candidate Application Generators, Applications Composition New Processes Object-Orientation Reuse and Product Line Management Payoffs Quick, cheap software User-programmable Quick, cheap software (e.g. via rework reduction) Good match to many domains Quick, cheap software via reuse of classes, patterns, Quick, cheap software -- Issues Scope, scalability, extendability, interoperability Complementary management techniques (e.g. cost modeling) Scope, scalability, interoperability Weak match to some domains Determining ROI success conditions Barry Boehm - 3

4 c IS 1 E 1 Candidate Software Silver Bullets Candidate Payoffs Issues - -- Enterprise Architecture COTS Hypercode, New CASE Environments New Quality Technologies: Cleanroom, PSP Interoperability, cross-domain reuse Cheap, powerful software Rides commercial technical curves Quick, cheap software Evolution support - Reduce defect rates Accommodating technical change System domain issues remain Accommodating special needs Interoperability Evolution con trollability Scalability System, domain issues remain Scalability Interaction with existing technologies (e.g., inspections) Barry Boehm - 4

5 Universrty of Southern Cal~forn~a I C I 1 S ~ E The future of the software practices marketplace \ User programming (55M performers in US in year 2005) - - pplication enerators (0.6M) Application composition (0.7M) Infrastructure (0.75M) System integratio (0.7M) Barry Boehm - 5

6 a C S IE ( COCOMO 2.0 Coverage of Future SW Practices Sectors User Programming: No need for cost model Applications Composition: Use object counts or object points -Count (weight) screens, reports, 3GL routines System Integration; development of applications generators and infrastructure software - Prototyping: Applications composition model -Early design: Function Points and 7 cost drivers - Post-architecture: Source Statements or Function Points and 17 cost drivers - Stronger reuselreengineering model Barry Boehm - 6

7 Center for software Engineering I c I S IE I r, Outline + Candidate Software Silver Bullets + Likely Future Software Practices Marketplace W + Challenges and COCOMO 2.0 Responses -Applications Composition - New Processes - Reuse and Product Line Management - Very High Level Languages (upcoming) -COTS Integration (upcoming) - New software quality technologies (upcoming) + COCOMO 2.0 status + Conclusions Barry Boehm - 7

8 A I c I S IE I Applications Composition + Challenge: - Modeling rapid applications composition' with graphical user interface (GUI) builders, client-server support, objectlibraries, etc. + Response: -Object-Point sizing and costing model - Reporting estimate ranges rather than point estimates Barry Boehm - 8

9 Step 1 : Assess Object-Counts: estimate the number of screens, reports, and 3GL components that will comprise this application. Assume the standard definitions of ihese objects in your ICASE environment. Step 2: Classify each object instance into simple, medium and difficult complexity levels depending on values of characteristic dimensions. Use the following scheme: For Screens 11 For Reports I # and source of data tables # and source of data tables I Total <8 Total 8+ Contained <3 [ simple 1 simple [ medium (1 0 or 1 i simple ( simple ( medium i simple 1 medium 1 difficult I 2or3 1 difficult >8 I medium 1 difficult 1 difficult 1 difficult I Step 3: Weigh the number in each cell using the following scheme. The weights reflect the relative effort required to implement an instance of that complexity level. Obiect Tvpe I Complexity-Weight 1 Simple I Medium 1 Difficult 1 Step 4: Determine Object-Points: add all the weighted object instances to get one number, the Object-Point count. Step 5: Estimate percentage of reuse you expect to be achieved in this project. Compute the New Object Points to be developed, NOP = (Object-Points) (100-%reuse) / 100. Step 6: Determine a productivity rate, PROD=NOP/person-month, from the following scheme: Developer's experience and capability CASE maturity and capability PROD 10 Step 7: Compute the estimated person-months: PM=NOP/PROD. Barry Boehm - 9

10 I c I S I E SW Costing and Sizing Accuracy vs. Phase Size (DSI) + Cost ($) Relative 1.25~ Size X Range Product Detail Concept of Rqts. Design Design Accepted Operation Spec. Spec. Spec. Software A A A A A A Feasibility Plans Product Detail Devel. and -wu, nncirrn Y' I Design and Rqts- Phases and Milestones Test Barry Boehm - 10

11 a I C I S ( E I New Processes + Challenges -Cost and schedule estimation of composable mixes of prototyping, spiral, evolutionary, incremental development, other models + Responses - New milestone definitions N Basic requirements consensus, life-cycle architecture - Replace development modes by exponent drivers - Post-Initial Operational Capability (IOC) evolution N Drop maintenanceheuse distinction Barry Boehm - 11

12 Schedule Estimation I C I S IE I APP= I Comp Spiral-type Basic Rqts nsensus Ev. Dev., Spiral IOC Accept. Test SYS Devel W'fall, IncDev, EvDev, Spiral-type Spiral-type Spiral Basic Rqts SWISys IOC Consensus Arch. Accept. Review Test Barry Boehm - 12

13 & 1 C ( S I E I Life-cycle Architecture as Critical Milestone Candidate Critical I Concerns Milestones Complete Requirements Specifications Beta-Test Code Life-Cycle Architecture I I I I Premature decisions, e.g. user interface features Inflexible point solutions Gold plating High-risk downstream functions Inflexible point solutions Capabilities too far from user needs Provides flexibility to address concerns above Further concerns: Predicting directions of growth, evolution High-risk architectural elements Barry Boehm - 13

14 - c ( S E ( Nature of Life-Cycle Architecture + Definition of life-cycle requirements envelope + Definition of software components and relationships - physical and logical - data, control, timing relationships - shared assumptions - developer, operator, user, manager views + Evidence that architecture will accommodate requirements envelope + Resolution of all life-cycle-critical COTS, reuse, and risk issues Barry Boehm - 14

15 & Univers~ty of Southern California I c ( S I E I New Scaling Exponent Approach Nominal person-months = A*(size)**B B = 1.O (exponent driver ratings) - B ranges from 1.O1 to drivers; ratings from 0 to 5 Exponent drivers: - Precedentedness - Development flexibility - Architecture1 risk resolution -Team cohesion -Process maturity (being derived from SEI CMM) Barry Boehm - 15

16 I c I ET S Outline + Candidate Software Silver Bullets + Likely Future Software Practices Marketplace + Challenges and COCOMO 2.0 Responses -Applications Composition - New Processes -Reuse and Product Line Management -Very High Level Languages (upcoming) -COTS Integration (upcoming) - New Software quality technologies (upcoming) + COCOMO 2.0 status + Conclusions Barry Boehm - 16

17 Ada PROCESS MODEL: KEY DISTINCTIONS "ALL TOO FREQUENT PROCESS MODEL" LOTS OF PEOPLE HORDES OF PEOPLE TRYING TO LONG I&T PHASE WRITING CDRLs UNDERSTAND DESIGN, MAKE PROGRESS R MASSIVE $3,. % SDDDs AS-BUILT Ada PROCESS MODEL SMALL, TOP TEAM WORKING ARCHITECTURE, RESOLVING HIGH-RISK ITEMS INCREMENT 3

18 Reuse and Product Line Management + Challenges - Estimate costs of both reusing software and developing software for future reuse - Estimate extra effects on schedule (if any) + Responses - New nonlinear reuse model - Cost of developing reusable software expanded from Ada COCOMO - Gathering schedule data Barry Boehm - 17

19 i Function Points, SLOC, and Backfiring + EffortIFP varies by language level (LL) - But so does effortisloc! + Proposed approach - SLOC, LL ==> Effort: Compute effort as F (SLOC as ~ GL) Apply stage multipliers - UFP, LL ==> Effort (.[JGL;y]) Computer effort as F UFP Apply stage multipliers

20 4GL Cost and Schedule Effects [Verner-Tate, Correspondence school information system + Estimated size: 15 KDSI ALL [4GL], 95 KDSl COBOL + Actual size: 13.9 KDSl ALL, 93.6 KDSl equiv. COBOL + Data on phase distribution of effort and schedule

21 4GL Estimates vs. Actuals Quantity COCOMO- COCOMO- Recom. COBOL 4GL Actual Use Size 93.6KSLOC Schedule I= 11.6Mo GLA1.6 Effort 247.5PM Mix:62.7 Plans&Rqts COBOL Prel Design *4G L D D/C UT/I&T GL

22 ! Effort Distribution Relative to 3GL Development Rapid APP- Devel. Spiral-type Ev. Dev., Spiral LCO, LCA SAT Sys Devel Spiral-type L a Waterfall, Spiral-type LCA W'fall, IncDev, EvDev, Spiral, Design-to-Cost, etc. Det. Design I I Code, Integ., Test SAT

23 Function Points and TANSTAAFL (There Ain't No Such Thing As A Free Lunch) "EffortlFP varies by language level" means both "Something like FP's are needed for productivity metric across language levels (vs. SLOC)".c and "FP's are a poor language-independent effort estimator"

24 COTS Integration + Challenge: - Estimate costs, schedules of complex COTS integration activities + Responses: - Separately address COTS platforms, COTS tools via existing cost drivers -Rough experimental model of COTS integration into product Barry Boehm - 22

25 COTS Integration Consider as experimental downstream COCOMO 2.0 addition Continue to use current cost drivers for COTS tool and platform effects COTS portions of application: Use Loral-type weighted COTS external interfaces as size add-on - Separate COTS-App, COTS-COTS, COTS-Platform interface factors - Develop 5-step technical complexity scales for each, including other Loral factors such as release interval - - Use activity based csting approach for COTS acquisition-related costs 513 Of95 Barry Boehm - 23

26 COTS Cost and Risk Modeling: Some Results from USC-CSE Affiliates' Workshop Cost Risk Driver * * COTS immaturity and lack of support *.It Staff inexperience with COTS integration, COTS Incompatibility of COTS with * * - Application * Licenses, tailoring, training - Other COTS, reused software - Computing platform, infrastructure - Performance, scalability, reliability,... rqts. * Lack of COTS evolution controllability Barry Boehm - 24

27 A C I S BE I Reuse and Product Line Management Challenges -Estimate costs of both reusing software and developing software for future reuse -Estimate extra effects on schedule (if any) + Responses - New nonlinear reuse model - Cost of developing reusable software expanded from Ada COCOMO -Gathering schedule data Barry Boehm - 17

28 dddmhl C 1 S ( E I Nonlinear Reuse Effects Data on 2954 NASA modules 1.O Relative / / Usual Linear Assumption I I I I o Amount Modified I Barry Boehm - 18

29 I - C I S BE Reuse and Reengineering Effects Add Assessment & Assimilation increment (AA) -Similar to conversion planning increment Add software understanding increment (SU) -To cover nonlinear software understanding effects -Apply only if reused software is modified Results in revised Adaptation Adjustment Factor (AAF) - Equivalent DSI = (Adapted DSI) * (AAF1100) -AAF = AA + SU + 0.4(DM) (CM) (IM) Barry Boehm - 19

30 & I C 1 S IE I Prototype of Software Understanding Rating I Increment Structure Application Clarity Self - Descriptiveness Very low cohesion, high coupling, spaghetti code. No match between program and application world views. Obscure code; documentation missing, obscure or obsolete. SU Increment to 50 ESLOC. Moderately low 1 ~easonabl~ cohesion, high well - coupling. structured; some weak areas. Some correlation between program and application. Some code commentary and headers; some useful documentation. Moderate correlation between program and application. Moderate level of code commentary, headers, documentations. High cohesion, low coupling. --- Good correlation between program and application. Good code commentary and headers; useful documentation; some weak areas. Strong modularity, information hiding in datalcontrol structures. Clear match between program and application world views. Self - descriptive code; documentation up-to-date, well-organized, with design rationale. Barry Boehm - 20

31 CB S ME I Center for Sortware Engineering COTS Integration + Challenge: - Estimate costs, schedules of complex COTS integration activities + Responses: - Separately address COTS platforms, COTS tools via existing cost drivers -Rough experimental model of COTS integration into product Barry Boehm - 21

32 a 1 c 1 S IE I COTS Integration Consider as experimental downstream COCOMO 2.0 addition Continue to use current cost drivers for COTS tool and platform effects COTS portions of application: Use Loral-type weighted COTS external interfaces as size add-on - Separate COTS-App, COTS-COTS, COTS-Platform interface factors -Develop 5-step technical complexity scales for each, including other Loral factors such as release interval Use activity based costing approach for COTS acquisition-related costs Barry Boehm - 22

33 A I c 1 S IE I COTS Cost and Risk Modeling: Some Results from USC-CSE Affiliates' Workshop Cost Risk Driver COTS immaturity and lack of support Staff inexperience with COTS integration, COTS Incompatibility of COTS with - Application - Other COTS, reused software - Computing platform, infrastructure - Performance, scalability, reliability,... rqts. Licenses, tailoring, training Lack of COTS evolution controllability Barry Boehm - 23

34 Unwersity of Southern California c I S BE I Examples of COTS Integration Cost Driver Scales COTS Defect Verv Low Very robust,mature COTS Low Some defects;rarely serious Nominal - Moderate level of defects; occasionallly serious High Many defects; some serious Very High Many serious interacting defects 1 i"-- Effort Multi liers 1 COTS Volatility Major change every 12 months; Minor: 1 month Major: 6 months Minor: 2 weeks Major: 2 months Minor: 1 week Major: 2 weeks Minor: 2 davs Effort Barry Boehm - 24

35 Legacy Software Reengineering + Challenge: -Varying reengineering efficiencies based on tool applicability, source-target system differences + Response: -Exploratory model based on NlST IRS data Barry Boehm - 25

36 c I S IE I NlST Reengineering Case Study [Ruhl-Gunn, IRS Centralized Scheduling Program Mix of batch, database querylupdate, on-line processing 50 KSLOC of COBOL74,2.4 KSLOC of assembly code Unisys with DMS network database Reengineer to SQL database, open systems Tools for program and data reengineering Barry Boehm - 26

37 I c I S IE I NlST Reengineering Automation Data Proqram Group Automated Manual Batch 96% 4% Batch with SORT 90% 10% Batch with DBMS 88% 12% Batch, SORT, DBMS 82% 18% l nteractive 50% 50% Barry Boehm - 27

38 I c I S IE 6 COCOMO 2.0 Cuwent Status Model structure iterated with Affiliates - Largely converged - Recent function point backfiring refinements being considered Model being calibrated to Affiliates', other data - Currently around 65 solid data points Model being beta-tested by Affiliates - Reasonable results so far Barry Boehm - 28

39 I c I S I E I 37 Current COCOMO 2.0 Affiliates (L 1 ) Commercial Industry (9) - AT&T, Bellcore, CSC, EDS, Motorola, Rational, Sun, TI, Xerox Aerospace Industry (lo) - E-Systems, Hughes, Litton, Lockheed Martin, Loral, MDAC, Northop Grumman, Rockwell, SAIC, TRW Government (3) - AFCAA, USAF Rome Lab, US Army Research Labs FFRDC's and Consortia (5) - Aerospace, IDA, MCC, SEI, SPC Barry Boehm - 29

40 A c ( S E ( Conclusions. Gone are the simple days - Proliferation of process models, COTSIreuse opportunities, languages + COCOMO 2.0 trying to cope with trends - Composable, tailorable model elements + Would appreciate feedback on approach Barry Boehm - 30