realistic software cost fractionated space systems a. winsor

University of Southern CaliforniaCenter for Systems and Software Engineering

IFCnSSCM-23

Realistic Software Cost Estimation for F6

Fractionated Space Systems

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

© & A W Brown BES/MSEE & USC CSE EC19b=PrsntRealisticSwCEforF6v2.doc – 1 of 41 v 0.2 04/02/00

IFCnSSCM-23 – Realistic Software Cost Estimation for F6


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)

© 2008 A W Brown BES/MSEE & USC CSSE EC19b=PrsntRealisticSwCEforF6v2.doc – 2 of 41 v1.0 - 10/28/08



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 IRR

LCA

IOC

PRR

LCO

CCD

1 (efforts not to scale)



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




Overlaps Across Software Builds

Inception Elaboration Construction Transition

Inception Elaboration Construction Transition

Evolve During Transition [After Sw IOC]

Evolve After Architecture Complete

Incept. Elaboration Construction Transition

Inception Elaboration with Evol. Req. 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 IRR

LCA

IOC

PRR

LCO

CCD

COCOMO II Estimation Covers

© 2008 A W Brown BES/MSEE & USC CSSE EC19b=PrsntRealisticSwCEforF6v2.doc – 1 v1.0 - 10/28/08
3 of 41



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

NewBuild x

ModifyBuild x

ModifyBuild x+1

Carried

NewBuild x+1

Carried

Build x+1 Build x+2

Carried

NewBuild x+2

etc.New,

Reused andCOTS

New,Reused and

COTS New,Reused and

COTSBox size notional for effort.




Multiple Subsystems Overlapping Builds




Outline

Context

Software Cost Estimation Approach for an F6

Conclusions




Software Cost Estimation Approach for an F6 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 Data Store Services, Software Support Services, More Information Assurance, More OS Abstraction

COE

3 30K Complete Information Assurance,Complete OS abstraction, Complete Analysis Services





1 5K Initial prototype with Executable Architecture and possibly minimal functionality

2 15K Expand or replace initial prototype with more capabilities, more functionality, and bug fixes in carried code

Power; S/G

Comm.; and

Payloads Sensor

and Radar. 3 15K Complete Functionality, and bug

fixes in carried code





1 10K Initial prototype with Executable Architecture and possibly minimal functionality

2 20K Expand or replace initial prototype with more capabilities, more functionality, and bug fixes in carried code

Payload Actuator

3 20K Complete Functionality, and bug fixes in carried code




Software Cost Estimation Approach for an F6 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.




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

Software Cost Estimation Approach for an F6

Conclusions




PM & M of the Fractionated Modules Total Fractionated Software Development Effort and Schedule spread over three builds

Build 1 Incept. Elab. Const. Trans.

Effort (PM) 13.76 54.94 173.94 27.47Schedule(M) 2.01 6.21 10.58 2.01 Total Fractionated Sw Devel. E&S - Build 2 Incept. Elab. Const. Trans. Effort (PM) 32.92

131.66

416.90

65.83

Schedule(M) 2.37 7.31 12.44 2.37 Total Fractionated Sw Development Effort & Schedule - Build 3 Incept. Elab. Const. Trans. Effort (PM) 6.61 26.44 83.72 13.22 Schedule(M) 2.33 7.19 12.25 2.33 Cumulative Schedule(M) 21.17 28.48 40.92 43.29 Cumulative Total Fractionated Sw Development Effort= 917.42 1047.41 Build1= 270.11 Build2= 647.31 Build3= 129.99 Cumulative Schedule(M) 43.25 50.44 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 © 2008 A W Brown BES/MSEE & USC CSSE EC19b=PrsntRealisticSwCEforF6v2.doc – 35 of 41 v1.0 - 10/28/08



Monolithic Counterpart (cont.) Effort and Schedule Estimates for a Single Build, Monolithic, Conventional Satellite

Incept. Elab. Const. Trans. TotalEffort (PM) 66.18 264.73 838.31 132.26 1301.48

Schedule (M)

4.04 12.47 21.23 4.04 41.78




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




Sw Cost Estimating Conclusions – 2 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)




Sw Cost Estimating Conclusions – 3 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


realistic software cost fractionated space systems a. winsor

Documents