USC IITV Presentation Template

University of Southern California Center for Systems and Software Engineering

IFCnSSCM-23

Realistic Software Cost Estimation for F6 Fractionated Space Systems

© & A W Brown BES/MSEE & USC CSE 0d03d8219ba2d691a68c602e661df9f0.doc – 1 of 55 v 0.3 04/02/00 University of Southern California IFCnSSCM-23 – Realistic Software Cost Estimation for F6 Center for Systems and Software Engineering

A. Winsor Brown, Ramin Moazeni {AWBrown, Moazeni}@CSSE.USC.edu

© 2018 A W Brown BES/MSEE & USC CSSE 0d03d8219ba2d691a68c602e661df9f0.doc – 2 of 55 v1.0 - 05/03/18 University of Southern California IFCnSSCM-23 – Realistic Software Cost Estimation for F6 Center for Systems and Software Engineering

Goals of Presentation

Context  DARPA’s System F6: Future Fast, Flexible, Fractionated, Free- Flying Spacecraft united by Information eXchange  Incremental Commitment Models (ICMs)  Constructive Incremental Commitment Cost Model [AKA Constructive Integrated Cost Model] (COINCOMO) & Tool Software Cost Estimation Approaches for an F6 Conclusions  ICMs provide frameworks for estimation  Lower effort, but longer schedule  Significantly lower overall risks (system and software)

Context: F6 Future Fast, Flexible, Fractionated, Free-Flying Spacecraft united by Information eXchange (Courtesy Dr. Owen Brown’s Briefing for BAA) • Microsat-like modules • Intra-module connectivity – Wireless data – Wireless power transfer • Inter-module connectivity – Wireless data • Robust, secure, self-forming wireless network

• Resource sharing across modules – Computation, etc. • Cluster Orbits

Context: ICMs For Systems/Acquisitions, including  Directed Systems of Systems  Systems For Software Subsystems  Parallels to Rational Unified Process (RUP)  Differences from Systems

ICM LC Processes for Systems (Hw, Sw & Pw)

ICM Activity Categories and Level of Effort

RUP/MBASE Application Development Model1

1 (efforts not to scale) © 2018 A W Brown BES/MSEE & USC CSSE 0d03d8219ba2d691a68c602e661df9f0.doc – 11 of 55 v1.0 - 05/03/18 University of Southern California IFCnSSCM-23 – Realistic Software Cost Estimation for F6 Center for Systems and Software Engineering

I L L C I P R C C C O R R O A D C R

ICM-Sw/RUP Activity/Process Model

Why Multiple Build Software Systems Simplest: Early Functionality in the hands of ALL users  Architecture/Core plus some functionality  Implies Full Qualification/Acceptance Sw Testing each software build so systems can go into Integration & Test earlier

Increasingly Complex Systems  Multiple, diverse "platforms"  Different "foci" of functionality (in each build)  Network Centric Systems Operation  Evolution/federation of legacy systems  System of Systems by design

© 2018 A W Brown BES/MSEE & USC CSSE 0d03d8219ba2d691a68c602e661df9f0.doc – 14 of 55 v1.0 - 05/03/18 Possible Overlapping Software Development Spirals University of Southern California IFCnSSCM-23 – Realistic Software Cost Estimation for F6 Center for Systems and Software Engineering Traditional Deliver And Enhance InceptionOverlapsElaboration Construction AcrossTransition Software Builds

Inception Elaboration Construction Transition

Evolve During Transition [After Sw IOC] Inception Elaboration Construction Transition

Inception Elaboration Construction Transition

Evolve After Architecture Complete Inception Elaboration with Evol. Req. Construction Transition

Incept. Elaboration Construction Transition

I. Elab. Construction Transition . . .

ICM Showing Multi-Build Software in a System

ICM Showing Multi-Build Software in DSOS (N layers)

MBASE/RUP/ICM-Sw Concurrent Activities

I L L C I P R C C C O R R O A D C R

COCOMO II Estimation Covers

COCOMO II with COPSEMO (for I&T)

COPSEMO: Phased Schedule and Effort Dist.

COINCOMO – 1 COCOMO + COPSEMO

COINCOMO Direction – 1b COCOMO + COPSEMO:

COINCOMO – 2 Multiple Build Capability from COINCOMO 2.0

Multi-Build COCOMO II COINCOMO Sums Across Builds For Est. Build x Build x+1 Build x+2

New Carried Modify Build x Build x Modify Build x+1 New, New Carried etc. Reused and Build x+1 COTS New Build x+2 New, Reused and COTS New, Reused and Box size notional for effort. COTS

Multiple Subsystems Overlapping Builds

Outline

Context

Software Cost Estimation Approach for an F6

Conclusions

Hypothesized (builds, capabilities and SLOC/build)  Common Operating Environment  Service Based Architecture Middleware  Common Services  Small satellites  Power Generation  Space-Ground (S/G) Communication  Micro satellites  A Sensor Payload  A Radar Payload

 An Actuator Payload

Software Capabilities of F6 Modules Module Build SLOC Software Capabilities 1 30K Communication, Minimal Information Assurance, Minimal Operating System (OS) abstraction, Initial System Services 2 40K Minimal Analysis Services, Minimal COE Data Store Services, Software Support Services, More Information Assurance, More OS Abstraction 3 30K Complete Information Assurance, Complete OS abstraction, Complete Analysis Services

Software Capabilities of F6 Modules Module Build SLOC Software Capabilities 1 5K Initial prototype with Executable Power; Architecture and possibly minimal S/G functionality Comm.; 2 15K Expand or replace initial prototype and with more capabilities, more Payloads functionality, and bug fixes in carried Sensor code and Radar. 3 15K Complete Functionality, and bug fixes in carried code

Software Capabilities of F6 Modules Module Build SLOC Software Capabilities 1 10K Initial prototype with Executable Architecture and possibly minimal functionality 2 20K Expand or replace initial prototype Payload with more capabilities, more Actuator functionality, and bug fixes in carried code 3 20K Complete Functionality, and bug fixes in carried code

Using the COINCOMO 2.0 tool  COCOMO model as a base2: estimated the software Effort (PM) and Schedule (M) for each module  COPSEMO model to separate the man power loading across Elaboration and Construction phases  COPSEMO model to add additional effort and schedule for Inception and Transition phases Used a spreadsheet to combine efforts AFTER aligning the beginning of Elaboration with the end of Construction Used COINCOMO for a monolithic equivalent

2 COCOMO calculates effort and schedule for the Elaboration and Construction phases of a build with new code and code carried forward from the previous build treated as re-used code with very favorable re-use parameters. © 2018 A W Brown BES/MSEE & USC CSSE 0d03d8219ba2d691a68c602e661df9f0.doc – 36 of 55 v1.0 - 05/03/18 University of Southern California IFCnSSCM-23 – Realistic Software Cost Estimation for F6 Center for Systems and Software Engineering

COINCOMO’s Component = COCOMO Project

COINCOMO’s COPSEMO for Single Component

COINCOMO naming conventions

COINCOMO Systems, Sub-Systems and Components  System is conceptual aggregator of Sub-Systems  Sub-System is aggregator for (software) Components  Component = COCOMO Project  Sub-Component = COCOMO Module

A CSV output of COINCOMO facilitates “aggregation” using a spreadsheet  Schedule after anchor point alignment  Effort per phase per build after anchor point alignment

Generated Spreadsheet with Totals

More Realistic Estimates First run used all nominal driver settings Second run used more realistic Drivers settings  SF:  PREC = Low  FLEX = LOW  RESL = VH (required: Architecting Sweet-spot  TEAM = 50% H to VH (required by a DSOS)  PMAT = VH (CMM Level 5 organizations)  EAFs:  RELY = VH  APEX H (SubSystems)  CPLX = 50% H to VH  APEX N (COE)  REUSE = VH  PLEX ?? (we used L)  ACAP = ?? (we used H)  LTEX = 50% H to VH  PCAP = ?? (we used H)  SITE = XH (1st Sys.)

 PCON = ?? (we used H)  SITE = N-XH (subseq.)

More Realistic Estimates (cont.) Generated second run taking advantage of COINCOMO’s DataBase centricity:  Replicated all elements of system(s): subsystems & components  Renamed systems (only): subsystems & components unchanged  Changed driver settings in one component; copied to other instances (builds) of same component 

Outline

Context

Conclusions

PM & M of the Fractionated Modules Total Fractionated Software Development Effort and Schedule spread over three builds Incep Elab Const Trans Build 1 t. . . . Effort 13.7 54.9 173.9 27.4 (PM) 6 4 4 7 Schedule( M) 2.01 6.21 10.58 2.01 Total Fractionated Sw Devel. Incep Const Trans E&S - Build 2 t. Elab. . . Effort 32.9 131. 416.9 65.8 (PM) 2 66 0 3 Schedule( M) 2.37 7.31 12.44 2.37 Total Fractionated Sw Development Effort & Incep Elab Const Schedule - Build 3 t. . . Trans. Effort 26.4 (PM) 6.61 4 83.72 13.22 Schedule( 2.33 7.19 12.25 2.33

M) Cumulative 21.1 28.4 43.2 Schedule(M) 7 8 40.92 9 Cumulative Total Fractionated Sw 917. 1047. Development Effort= 42 41 Build 270. Build 647. Build 129.9 1= 11 2= 31 3= 9 Cumulative 43.2 50.4 Schedule(M) 5 4 62.69 65.02

Monolithic Counterpart

Also has three payloads of 50K SLOC: Sensor, Radar and Actuator

A satellite bus might need 75K SLOC for  Navigation and Control (N&C)  Command and Telemetry (C&T) including s/g comm.  Power Conditioning  Fault Management & Recovery  Thermal Management

Total of 225K SLOCs

Monolithic Counterpart (cont.)

Effort and Schedule Estimates for a Single Build, Monolithic, Conventional Satellite Incept. Elab. Const. Trans. Total Effort (PM) 66.18 264.73 838.31 132.26 1301.48 Schedule 4.04 12.47 21.23 4.04 41.78 (M)

Sw Cost Estimating Conclusions – 1

COCOMO II, or some other cost model, Along with COPSEMO, or its equivalent in some other cost model, Had to be used for each build because  Nobody has experience with developing software for an F6  Traditional Cost Estimating Ratios (CERs) don't work without sufficient data

Complications in parametric estimates for F6  Differences between the teams producing the software  Amounts of carried code and their reuse factors change with the number of times the code is carried (these factors influence what software cost estimators call "Equivalent SLOC", or ESLOC, for the carried code which in- turn impacts the effort and schedule) When calculating the total schedule in a multi-build approach, only the parts up to an overlap are counted.  Total Efforts are additive  Schedule is cumulative (at the longest subsystem build)

F6 Surprises (?)  Total estimated software development effort of our example fractionated system vs. the monolithic system:  F6 with Incremental Builds: 1047 Person Months (PM)  Monolithic satellite and single build: 1301 PM  A 20% decrease in effort cost for the fractionated system (which happens because the smaller pieces of the fractionated approach are not as impacted by the diseconomies of scale for the larger monolithic approach)  Schedule  The fractionated system would take about 65 months  41 months for the monolithic system

Sw Cost Estimating Conclusions – 4 Risks  Lower risk of Multiple Build F6: not big bang  With the multiple, overlapping builds: greater assurance that more of the software will be fully functional by the planned launch date.  There are also clear systems' costs savings with the ability to launch replacement parts without changes to the software  Future savings with the fractionated system approach: Lower penalties for enhanced functionalities launched  Radically changing a sensor would probably take only take 38 calendar months & 188 PM of effort, assuming  COE is reused without significant change  Sensor code is completely re-written

COINCOMO Conclusions

UI needs to be developed to assist in spawning estimates Spreadsheet calculations were done in less than an hour because csv file was properly organized. Spreadsheet combination is probably best because of multiple ways to do things  Non-COE Components might start AgileArchitecting after Elaboration/Foundation of System/COE  Since Sub-Systems are not on the longest path, perhaps they should be not start their next build until Transition is almost complete