Preparation of Papers for AIAA Technical Conferences s3

Realistic Software Cost Estimation for Fractionated Space Systems

A Winsor Brown1, Ramin Moazeni2, and Barry Boehm3 University of Southern California Center for Systems and Software Engineering, Los Angeles, CA 90089-0781

Fractionated Space Systems, as exemplified by Defense Advanced Research Projects Agency's Future Fast, Flexible, Fractionated, Free-Flying Spacecraft united by Information eXchange (DARPA’s System F6), represent real challenges to software cost estimation. The concept is a traditional 'monolithic' spacecraft is replaced by a cluster of wirelessly interconnected spacecraft modules to create a virtual satellite, delivering capability which is at least equivalent to the monolithic spacecraft. Concurrently, they significantly enhance flexibility and system robustness, and reduce risk throughout the mission life and the spacecraft development cycle. Such systems present real challenges to software cost estimation which arise from both the concept of a Directed System of Systems (DSOS) and the reduced risk which is primarily achievable only through the application of an Incremental Commitment Model (ICM). This paper will briefly introduce a next-generation synthesis of the spiral model and other leading process models into the ICM, which is being piloted or considered for adoption in some parts of Department of Defense (DoD). The ICM emphasizes architecting systems (or DSOSs) to encapsulate subsystems (or systems) undergoing the most rapid change; and architecting the incremental development process by having agile systems engineers handling longer-range change traffic to rebaseline the plans for future increments while largely plan- driven teams develop and continuously verify and validate (V&V) the current increment, as is usually required for safe or secure software. One approach being followed for estimating the software development cost of the Fractionated Space Craft Systems of Systems (FSSOS) is based on the Constructive Incremental Commitment Cost Model (COINCOMO) model and its tool which currently implements together in one tool the Constructive Cost Model (COCOMO II), the Constructive Phased Schedule and Effort Model (COPSEMO) and a Constructive Security Cost Model (COSECMO). COINCOMO has an added super-structure to accommodate multiple suppliers of independent software subsystems and multiple builds (or incremental deliveries). Many software systems components today rely on Commercial-Off-the-Shelf (COTS) sub-components and/or reuse of (potentially proprietary) open-source or legacy components which are treated like COTS components rather than reused, modified components, and adapted/reused open-source subcomponents, as well as new code. The COINCOMO model also accommodates them without the name-space explosion that happened in COCOMO II. COINCOMO 2.0 is implemented in a database-centric fashion designed with the ability to save and reuse any of the sets of parameters thus making it much easier to do what-if and evolving estimates.

I. Overview of the Incremental Commitment Life Cycle Process (ICM) An overview of the ICM life-cycle process1,2 is shown in Fig. 1. In comparison to the software-intensive, single development increment delivery Rational Unified Process (RUP) by IBM/Rational Corporation, the ICM also addresses hardware and human factors integration. It extends the RUP phases to cover the full system life cycle, including the following anchor-point milestones: Exploration Commitment Review (ECM), Valuation Commitment Review (VCM), Foundations Commitment Review (FCM), and one or more Development Commitment Review (DCR) and Operations Commitment Review (OCR). The ICM anchor-point milestones are focused on synchronizing the high degree of concurrency surrounding complex systems development with the stakeholder commitments needed to move forward. These milestones look at concurrent activities, which may span independently developed systems, with a view toward synchronizing, stabilizing, and assessing risk before obtaining commitment to proceed to the next phase.

1 Assistant Director and Instructor, USC Center for Systems and Software Engineering, SAL332 MC 0781 2 PhD Candidate, USC Computer Science Department, SAL 329 M/C 0781 3 Director and TRW Professor of Computer Science, USC Center for Systems and Software Engineering, SAL328 M/C 0781; AIAA Fellow.

1 American Institute of Aeronautics and Astronautics Figure 1. Overview of the Incremental Commitment Life-Cycle Process The ICM identifies the following key process principles as critical success factors: • Stakeholder Satisficing1: Identify and engage key stakeholders (i.e., those critical to success) early and often to validate and re-validate requirements, solutions and plans, and to discuss potential and proposed changes. • Incremental and Evolutionary Growth of System Definition and Stakeholder Commitment: Establish and apply a robust framework for evolution, including stakeholder interaction and agreement processes that gradually build understanding and trust, enabling objective tradeoff analyses and resulting in incremental commitments to plans to move forward. • Iterative System Development and Definition: Iteratively refine tradeoff analyses, requirements, solutions, and plans based on new information, new needs, and new technologies. • Concurrent System Definition and Development: Define, analyze, and refine requirements and solutions concurrently, especially in environments in which legacy and commercial components factor into the solution. Refine requirements as more is known about constraints on the solution and to adapt to changes in mission and business needs. • Risk Management Through Risk-Driven Anchor-Point Milestones: Apply risk-driven milestones to synchronize and stabilize activities and products that are concurrent, iterative, and evolving. Evaluate business, technical, and operational feasibility by independent experts, discuss risks and risk-management plans, and decide whether or not to proceed. Figure 1 also shows how ICM spans the full life cycle process from concept exploration to operations. Each phase concludes with an anchor point milestone review. At each anchor point, there are four options, based on the assessed risk of the proposed system. Some options involve go-backs. The sets of options result in many possible process paths.

1 "The word satisfice was coined by Herbert Simon as a portmanteau of 'satisfy' and 'suffice' meaning to “meet criteria for adequacy, rather than to identify an optimal solution.” [Wikipedia; Satisficing: http://en.wikipedia.org/wiki/Satisficing.]

2 American Institute of Aeronautics and Astronautics The total system (or DSOS) life cycle is divided into two stages: Stage I of the ICM (Definition) has three decision nodes, each with four options per node, culminating with incremental development in Stage II (Development and Operations). Stage II has an additional two decision nodes, again with four options per node. One can use ICM risk patterns to generate frequently-used processes with confidence that they will fit the situation. Initial risk patterns can generally be determined in the Exploration phase. One then proceeds with definition and development approach as a proposed plan with risk-based Feasibility Evidence at the VCR milestone and each subsequent milestones, adjusting plans and updating Feasibility Evidence in later phases as necessary. Risks associated with the system drive the life cycle process. Information about the risk(s) (feasibility assessments) supports the decision to proceed, adjust scope or priorities, or cancel the program.

II. The Constructive Incremental Commitment Cost Model (COINCOMO) Tool The vision behind the development of the COINCOMO Tool has been to build a base to integrate all of the components of the COCOMO "suite" of software development estimation tools, including the COCOMO II Charts [extension], COPSEMO, COSECMO, CORADMO, and COCOTS; and the systems engineering extensions COSYSMO and COSOSIMO. In addition, COINCOMO must 1) cover all software development activities included in multiple, full WinWin Software Development Spirals (corresponding to all four Phases of MBASE (Model-Based Architecting & Software Engineering)/RUP development life cycle; see Fig. 2), each producing fieldable software; and 2) accommodate the multiple (from different organizations), builds (or deliveries) and systems.

Figure 2. RUP with MBASE Anchor Point The current version of the COINCOMO tool is based on the COCOMO II, COPSEMO, and COSECMO models with the added super-structure to accommodate the multiple packages, builds (or deliveries) and systems, as described in several papers.3,4,5 The original COCOMO I model used the waterfall model for its anchor points: the cost and schedule estimates covered the effort between Software Requirements Review (SRR) and Initial [software] Operational Capability (IOC). That model, which dates back to the 1970s6 has been recognized as an appropriate subset of the possible process models under the appropriate conditions7. Current terminology for anchor points, as used in COCOMO II, requires a more general approach8. The co-evolution of the RUP in the late 1980s led to the obvious alignment of the anchor points (and their assessments) as gate-keepers to the RUP "phases”: Inception Readiness Review (IRR) for Inception phase; Life Cycle Objectives (LCO) for Elaboration; Life Cycle Architecture (LCA) for Construction; and IOC, with a Transition Readiness Review (TRR), for Transition; and a Product Release Review (PRR) to

3 American Institute of Aeronautics and Astronautics formalize the end of the "Transition". These anchor points, super-imposed on the RUP activities diagram, are shown in Fig. 2. Also highlighted in Fig. 2 is the area from LCO to IOC, i.e., the Elaboration and Construction phases, and the covered activities that are included in the total effort that a COCOMO II estimation covers. Builds made using the COCOMO II model follow either the "once-through" or "incremental" development strategies, as described in Appendix B of the IEEE's J-STD-016-1995 (IEEE) 9. In both cases, there is only one system integration and qualification test, which are two of the primary activities taking place during the Transition phase. These two development strategies are in contrast to the "evolutionary" strategy which develops a system in builds, where the first build incorporates part of the planned capabilities, the next build adds more capabilities, and so on, until the system is complete. If the builds follow the "evolutionary" strategy, including their integration with the system to be deployed, they are often fully tested and delivered to the acquirer, in which case all the phases of RUP are repeated for each build. However, how the phases overlap is not depicted in RUP; Fig. 3 shows the possible overlaps across builds Figure 3. Overlaps Across Software Builds and Fig. 4 shows one possible scenario of evolutionary, multi-build software development in systems development increments in an ICM context.

4 American Institute of Aeronautics and Astronautics Figure 3. ICM Showing Multi-Build Software in Systems

III. Software Engineering Reasons for Multi-Build, Overlapping RUP Cycles in ICM The selection of multiple builds with overlapping MBASE/RUP cycles within the definition and development phases of ICM was done for sound systems/software engineering reasons. The primary reason for multiple builds was based on producibility in the face of risks, in particular the fact that F6 Systems are unprecedented. An all or nothing approach to the software development (also known as a "big-bang" approach) does not make sense. With multiple builds, the program has a chance to re-scope either pieces of software or whole systems at the decision points based on Feasibility Evidence. The selection also provides the ability to generate and demonstrate (in an earth-based test environment) some of the system's capabilities earlier than is possible in a big-bang approach, and those capabilities should involve many of the "risky" bits, like communications with the constellation of spacecraft modules and network management of the constellation. Employing overlapping, concurrent builds for the different sub-systems (or systems of a DSOS) was also selected for sound systems/software engineering reasons. Assuming there is not a software development resource restriction, and that developers have appropriate "application" domain experience, then getting the teams to work concurrently is the smartest thing to do from an overall software development effort perspective: the efforts of the teams are additive and not based on the total Source Lines-of-Code (SLOC) count being used on any given system. From a systems and software engineering perspective, producing builds that are fully systems-tested, even if parts of the build may use simulation and/or emulation, means that both the software-to-system-integration teams and systems-test teams can start to work earlier than in a big-bang approach. Also, the systems engineers and software architects can practice the concurrent "Agile Architecting and Stabilized Development" approach, espoused in ICM, for systems with high concerns for safety or security or requirements that are unstable or emerging. Finally, the early integration and test experience will also increase the acquirer’s confidence about the capabilities and architecture of the system.

IV. Overview of Fractionated Space Systems The concept of “fractionation” is introduced to describe the decomposition of a system into distinct modules (or possibly systems) which if assembled, will represent the capabilities of a monolithic system 10. Fractionated Space Systems, as described by DARPA’s System F6, is a satellite architecture where the capabilities of a conventional monolithic satellite are distributed across fractionated network of nodes connected through a robust, secure, self- forming wireless network, while remaining physically disconnected, creating a “virtual satellite.” Each fractionated

5 American Institute of Aeronautics and Astronautics module can provide one or more unique capabilities such as command and telemetry, navigation and control, a sensor, radar, an actuator, etc. The fractionated modules, however, may also replicate the capability of another fractionated module. The capabilities of the resulting virtual satellite are equivalent to, or possibly greater than (consider a synthetic aperture sensor), that of conventional monolithic satellite. The concept of a virtual satellite, can be considered as a “system of systems” where only the needed fractionated module can be launched and logged into the virtual satellite network. A Common Operating Environment (COE), which provides supporting functionalities as services, can provide capabilities such as command and telemetry, wireless network management, data storage, etc. Resource sharing can be done among fractionated modules that are within range for communication including data storage, data sharing (payloads, and command and telemetry), communication with ground stations, etc.11 The power generation capability is designed to serve the fractionated modules (or systems). Transmission of power to the fractionated modules within range will be controlled through, and possibly carried over, the wireless network. Navigation and Control can also be fractionated into separated modules for determining the position and altitude of the system where one module determines its own position and altitude relative to the earth and the rest of the fractionated modules determine their positions against the navigation module.

V. Software Cost Estimation of a Fractionated Space Systems We have applied the concept of the COINCOMO software cost estimation model to one possible configuration of a Fractionated Space System (actually a DSOS) to be developed and delivered following the ICM model. The following fractionated module capabilities are contemplated in the virtual satellite: - Common Operating Environment (COE) - Power Generation - Space-Ground (S/G) Communication - A Sensor Payload - A Radar Payload - An Actuator Payload The software development of each of these module's capabilities in the first operational increment of the virtual satellite will be done in three builds. With the exception of the COE, the first build is the development of an initial prototype, while the second and third builds involve development of more, or more-complete, capabilities. All but the first build are assumed to be developed while the previous build is the in transition phase as shown in Fig. 3. Table 1, below, describes the capabilities that are expected to be completed in each build along with a guestimate of the Source Lines of Code (SLOC) size. Table 1. Software Capabilities of Fractionated Spacecraft 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 COE Support Services, More Information Assurance, More OS Abstraction 3 30K Complete Information Assurance, Complete OS abstraction, Complete Analysis Services 1 5K Initial prototype with Executable Architecture and possibly minimal functionality Power; S/G Comm.; and Payloads Sensor 2 15K Expand or replace initial prototype with more capabilities, more and Radar. functionality, and bug fixes in carried code 3 15K Complete Functionality, and bug fixes in carried code Payload Actuator 1 10K Initial prototype with Executable Architecture and possibly minimal functionality

6 American Institute of Aeronautics and Astronautics 2 20K Expand or replace initial prototype with more capabilities, more functionality, and bug fixes in carried code 3 20K Complete Functionality, and bug fixes in carried code Each fractionated module (microsatellite), a satellite system in its own right, would contain the COE and provide one Payload, Power Generator, or S/G Communication. The monolithic satellite is also expected to have three payloads: Sensor, Radar and Actuator. In such a conventional monolithic satellite, the satellite bus might consist of: • Navigation and Control (N&C) • Command and Telemetry (C&T) • Power Conditioning • Fault Management & Recovery • Thermal Management Using the COINCOMO tool, the estimated the software Effort (PM) and Schedule (M) needed to develop software for each fractionated module and for the monolithic satellite has been calculated. The COINCOMO tool uses the COCOMO model as a base1, and the COPSEMO model to separate the man power loading between Elaboration and Construction, and adds additional effort and schedule for the Inception and Transition phases, as depicted in Fig. 5.

Figure 4. Sample of COPSEMO's Distribution Effort and Schedule Across Phases.

The monolithic satellite is expected to have three payloads: Sensor, Radar and an Actuator. Table 2. Effort and Schedule Estimates for a Single Build, Including a satellite bus of 75K SLOC, and three Monolithic Conventional Satellite. payloads each with 50K SLOC, the monolithic Monolithic (1 Build)Incept.Elab.Const.Trans.TotalEffort satellite would fly with 225K SLOCs of software. (PM)66.18264.73838.31132.261301.48Schedule(M)4.0412.4721.234.0441. The COINCOMO tool calculated a total effort of 78 about 1301 Person Months (PM) as shown in Table 2. Table 3 summarizes the calculated numeric Effort (Person Months, PM) and Schedule (Months, M) for development of the fractionated modules and should be compared to the numeric values in Table 2 summarizing the Effort (PM) and Schedule (M) for development of a conventional, monolithic, single-build satellite (which assumes no re-use).

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

7 American Institute of Aeronautics and Astronautics Table 3. Effort (PM), and Schedule (M) of the Fractionated Modules: Fractionated COE - Build 1 Incept. Elab. Const. Trans. Effort (PM) 7.33 29.30 92.79 14.65 Schedule(M) 2.01 6.21 10.58 2.01 Fractionated COE - Build 2 Incept. Elab. Const. Trans. Effort (PM) 12.23 48.91 154.90 24.46 Schedule(M) 2.37 7.31 12.44 2.37 Fractionated COE - Build 3 Incept. Elab. Const. Trans. Effort (PM) 11.63 46.53 147.34 23.26 Schedule(M) 2.33 7.19 12.25 2.33 Fractionated Sensor, Radar, Power, S/G - Build 1 Incept. Elab. Const. Trans. Effort (PM) 1.05 4.18 13.25 2.09 Schedule(M) 0.51 1.59 2.70 0.51 Fractionated Sensor, Radar, Power, S/G - Build 2 Incept. Elab. Const. Trans. Effort (PM) 3.81 15.24 48.25 7.62 Schedule(M) 1.63 5.03 8.56 1.63 Fractionated Sensor, Radar, Power, S/G - Build 3 Incept. Elab. Const. Trans. Effort (PM) 4.71 18.86 59.72 9.43 Schedule(M) 1.75 5.40 9.20 1.75 Fractionated Actuator - Build 1 Incept. Elab. Const. Trans. Effort (PM) 2.23 8.92 28.15 4.46 Schedule(M) 0.99 3.06 5.21 0.99 Fractionated Actuator - Build 2 Incept. Elab. Const. Trans. Effort (PM) 5.45 21.79 69.00 10.89 Schedule(M) 1.83 5.66 9.63 1.83 Fractionated Actuator - Build 3 Incept. Elab. Const. Trans. Effort (PM) 6.61 26.44 83.72 13.22 Schedule(M) 1.95 6.01 10.24 1.95 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.47 Schedule(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

VI. Conclusion COCOMO II, or some other cost model, along with COPSEMO, or its equivalent in some other cost model, had to be used to get the cost and schedule for each build because nobody has experience with developing software for a Fractionated Space System: the traditional Cost Estimating Ratios (CERs) don't work without sufficient data. Also differences between the teams producing the software should be factored into the cost and schedule estimation. The 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.

8 American Institute of Aeronautics and Astronautics What seems surprising is the comparison of total estimated software development effort of our sample fractionated system vs. the monolithic system: 1047 Person Months (PM) versus 1301 PM for the monolithic satellite, about 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 dis-economies of scale for the larger monolithic approach). Schedule wise, the fractionated system would take about 65 months versus about 41 months for the monolithic system, but it does not have the all or nothing risk characteristics of the monolithic system. The differences between the risk inherent in the monolithic satellite and the risk in the inherent multi-build fractionated systems are significant. With the multiple, overlapping builds there will be 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. Also, there will be future savings with the fractionated system approach, since enhanced functionalities can be launched with much lower penalties: radically changing a sensor would probably take only take 38 calendar months and 188 person months of effort, assuming the COE is reused without significant change and the sensor code is completely re-written.

References

9 American Institute of Aeronautics and Astronautics 1 Committee on Human-System Design Support for Changing Technology [principally by Dr. Barry Boehm as a member of the committee], "System Development Process: The Incremental Commitment Model," Human-System Integration in the System Development Process: A New Look (2007), edited by Richard W. Pew and Anne S. Mavor, National Research Council, The National Academies Press, Washington, DC 20055. http://www.nap.edu/catalog.php? record_id=11893. 2 Boehm, B., "System Development Process: The Incremental Commitment Model," chapter 2 of Human-System Integration in the System Development Process: A New Look, 2007, with updated 2008 terminology and charts. USC Technical Report "USC-CSSE-2008-807 - System Development Process: The Incremental Commitment Model (Barry Boehm)" http://sunset.usc.edu/csse/TECHRPTS/2008/usc-csse-2008-807/usc-csse-2008-807.pdf 3 Brown, A. W., "COINCOMO – The COCOTS Integration Challenges," ISPA, June 2007. 4 Brown, A. W., Colbert, E., and Nguyen, V., "COINCOMO And Its New Supporting Tools" with Ed Colbert and Vu Nguyen, ISPA, May 2006. 5 Brown, A. W., and Meyers, S., "COINCOMO--Combining Elements of the COCOMO Suite", 2005 Joint ISPA/SCEA International Conference, Vol _, 2005, pp.. 6 Royce, W. W., "Managing the Development of Large Software Systems", Proceedings, IEEE Wescon, 1970, pages 1- 9. Also, Conference Paper 41801, Proceedings of the 9th International Conference on Software Engineering, Monterey, California, United States, IEEE Computer Society Press, pgs 328-338, 1987. 7 Boehm, B., and Port, D., "Escaping the Software Tar Pit: Model Clashes and How to Avoid Them", Software Engineering Notes, Association for Computing Machinery, January 1999, pp. 36-48. 8 Boehm, B., “Anchoring the Software Process,” IEEE Software, Vol. 13, No. 4. July 1996, pp 73-82. 9 "Trial-use standard for information technology software life cycle processes software development acquirer-supplier agreement", J-STD-016-1995, ISBN: 0-7381-0427-2 10 Brown, O., and Eremenko, P. "Fractionated Space Architectures: A Vision for Responsive Space". 4th Responsive Space Conference: Paper No. AIAA-RS4-2006-1002, Los Angeles, CA: American Institute of Aeronautics & Astronautics, 2006. 11 "System F6". Broad Agency Announcement, BAA07-31, DARPA 2007.