Calhoun: The NPS Institutional Archive DSpace Repository

Theses and Dissertations 1. Thesis and Dissertation Collection, all items

2019-09 PORTFOLIO LEVERAGING -BASED OPEN ARCHITECTURE

Sweeney, Robert J.

Monterey, CA; Naval Postgraduate School http://hdl.handle.net/10945/63508

Downloaded from NPS Archive: Calhoun

NAVAL POSTGRADUATE SCHOOL

MONTEREY, CALIFORNIA

THESIS

PORTFOLIO MANAGEMENT LEVERAGING SOFTWARE-BASED OPEN SYSTEMS ARCHITECTURE

by

Robert J. Sweeney

September 2019

Thesis Advisor: Raymond D. Jones Second Reader: Robert F. Mortlock Approved for public release. Distribution is unlimited. THIS PAGE INTENTIONALLY LEFT BLANK Form Approved OMB REPORT DOCUMENTATION PAGE No. 0704-0188 Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instruction, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and , Paperwork Reduction (0704-0188) Washington, DC 20503. 1. AGENCY USE ONLY 2. REPORT DATE 3. REPORT TYPE AND DATES COVERED (Leave blank) September 2019 Master’s thesis 4. TITLE AND SUBTITLE 5. FUNDING NUMBERS PORTFOLIO MANAGEMENT LEVERAGING SOFTWARE-BASED OPEN SYSTEMS ARCHITECTURE 6. AUTHOR(S) Robert J. Sweeney 7. PERFORMING NAME(S) AND ADDRESS(ES) 8. PERFORMING Naval Postgraduate School ORGANIZATION REPORT Monterey, CA 93943-5000 NUMBER 9. SPONSORING / MONITORING AGENCY NAME(S) AND 10. SPONSORING / ADDRESS(ES) MONITORING AGENCY N/A REPORT NUMBER

11. SUPPLEMENTARY NOTES The views expressed in this thesis are those of the author and do not reflect the official policy or position of the Department of Defense or the U.S. Government. 12a. DISTRIBUTION / AVAILABILITY STATEMENT 12b. DISTRIBUTION CODE Approved for public release. Distribution is unlimited. A 13. ABSTRACT (maximum 200 words) The Section 809 Panel for streamlining and codifying acquisition was tasked with providing a recommendation to Congress regarding ways to streamline and improve the Department of Defense (DoD) acquisition . As part of its final report, the 809 Panel recommends a transition from a “program-centric” to a “portfolio-centric” defense acquisition model. By aligning common , the 809 Panel believes it can ultimately achieve acquisition efficiencies resulting in decreased life-cycle costs and increased speed to field capabilities. This paper will analyze whether the 809 Panel’s recommendation to move to a portfolio-centric model has potential to decrease life-cycle costs and decrease the time it takes to field capabilities to the warfighter. The scope of this analysis is limited to software-intensive weapon systems.

14. SUBJECT TERMS 15. NUMBER OF Modular Open Systems Approach, MOSA, Open Systems Architecture, OSA, Future PAGES Airborne Capability Environment, FACE, open architecture, OA, software, 809 Panel, 95 portfolio management 16. PRICE CODE 17. SECURITY 18. SECURITY 19. SECURITY 20. LIMITATION OF CLASSIFICATION OF CLASSIFICATION OF THIS CLASSIFICATION OF ABSTRACT REPORT PAGE ABSTRACT Unclassified Unclassified Unclassified UU NSN 7540-01-280-5500 Standard Form 298 (Rev. 2-89) Prescribed by ANSI Std. 239-18

i THIS PAGE INTENTIONALLY LEFT BLANK

ii Approved for public release. Distribution is unlimited.

PORTFOLIO MANAGEMENT LEVERAGING SOFTWARE-BASED OPEN SYSTEMS ARCHITECTURE

Robert J. Sweeney Civilian, Department of the Navy BS, Austin Peay State University, 2003 MS, Walden University, 2006

Submitted in partial fulfillment of the requirements for the degree of

MASTER OF ADMINISTRATION

from the

NAVAL POSTGRADUATE SCHOOL September 2019

Approved by: Raymond D. Jones Advisor

Robert F. Mortlock Second Reader

Marco S. DiRenzo Academic Associate, Graduate School of Business and Public Policy

iii THIS PAGE INTENTIONALLY LEFT BLANK

iv ABSTRACT

The Section 809 Panel for streamlining and codifying acquisition was tasked with providing a recommendation to Congress regarding ways to streamline and improve the Department of Defense (DoD) acquisition system. As part of its final report, the 809 Panel recommends a transition from a “program-centric” to a “portfolio-centric” defense acquisition model. By aligning common requirements, the 809 Panel believes it can ultimately achieve acquisition efficiencies resulting in decreased life-cycle costs and increased speed to field capabilities. This paper will analyze whether the 809 Panel’s recommendation to move to a portfolio-centric model has potential to decrease life-cycle costs and decrease the time it takes to field capabilities to the warfighter. The scope of this analysis is limited to software-intensive weapon systems.

v THIS PAGE INTENTIONALLY LEFT BLANK

vi TABLE OF CONTENTS

I. INTRODUCTION...... 1 A. BACKGROUND ...... 1 B. PURPOSE ...... 1 C. PROBLEM ...... 2 D. METHOD ...... 2

II. BACKGROUND ...... 3 A. CURRENT PROGRAM-CENTRIC MANAGEMENT MODEL...... 3 B. NEED FOR A DIFFERENT MODEL ...... 5

III. LITERATURE REVIEW ...... 7 A. PROGRAM-CENTRIC VS. PORTFOLIO-CENTRIC MODEL ...... 7 1. Organizational Alignment ...... 8 2. Organizational Challenges ...... 9 3. Portfolio-Centric Technical Characteristics ...... 10 B. OPEN SYSTEMS ARCHITECTURE ...... 12 1. OSA Pillars ...... 13 2. Holistic Approach ...... 14 C. ORGANIZATIONAL USE OF PORTFOLIO-CENTRIC MODEL ...... 14 1. Automotive Industry ...... 14 2. Smart Phones ...... 15 3. Rockwell Collins ...... 16 4. NAVSEA ...... 18 D. PRODUCT LINE SOFTWARE COST MODEL ...... 19 E. FACE OPEN SYSTEMS STANDARD ...... 21 1. Threats to Portability ...... 24 2. FACE Solutions to Portability Threats ...... 24 F. FUNCTIONAL DECOMPOSITION ...... 25 G. DATA RIGHTS ...... 27

IV. DISCUSSION ...... 29 A. PROGRAMMATIC ANALYSIS ...... 29 1. Cost Analysis ...... 29 2. Portfolio Management Organization ...... 37 B. HOLISTIC OPEN SYSTEM ARCHITECTURE APPROACH ...... 42 1. Functional Decomposition ...... 43 vii 2. Reference Architecture ...... 59 3. Data Rights ...... 66

V. CONCLUSION ...... 67 A. RECOMMENDATION ...... 67 B. FUTURE RESEARCH ...... 67

APPENDIX. EXAMPLE COPLIMO SCALING FACTORS ...... 69

LIST OF REFERENCES ...... 71

INITIAL DISTRIBUTION LIST ...... 75

viii LIST OF FIGURES

Figure 1. Program-Centric Organization ...... 3

Figure 2. Program and Portfolio Relationships. Source: PMI (2004)...... 9

Figure 3. AUTOSAR Consortium. Source: AUTOSAR (n.d.)...... 15

Figure 4. Rockwell Collins Open Architecture Migration. Source: Howington (2016)...... 17

Figure 5. PEO IWS Portfolio Management Process. Source: Emery (2010)...... 19

Figure 6. Example FACE Architectural Segments. Source: The Open Group (2017)...... 22

Figure 7. FACE Technical Domain Usage ...... 23

Figure 8. Example Functional Decomposition Process. Source: Guertin, Sweeney, and Schmidt (2015)...... 27

Figure 9. COPLIMO Tool Interface with Example Inputs ...... 34

Figure 10. COPLIMO Example Results...... 35

Figure 11. Cost Savings Across Example Portfolio ...... 36

Figure 12. Portfolio PMO Concept ...... 41

Figure 13. Portfolio PEO Concept ...... 42

Figure 14. Track and ID Functional Decomposition ...... 43

Figure 15. Functional Decomposition overlaid on FACE architecture. Adapted from The Open Group (2017)...... 62

Figure 16. Navigation and Guidance Processor ...... 63

Figure 17. Terrain Avoidance Processor ...... 63

Figure 18. System Management Processor ...... 64

Figure 19. C2 Processor ...... 64

Figure 20. ISR and EW Processor ...... 65

Figure 21. Weapons Processor ...... 65 ix THIS PAGE INTENTIONALLY LEFT BLANK

x LIST OF TABLES

Table 1. Functionally Decomposed Components ...... 45

Table 2. Platform-Specific Services...... 59

Table 3. I/O Services Components ...... 61

xi THIS PAGE INTENTIONALLY LEFT BLANK

xii LIST OF ACRONYMS AND ABBREVIATIONS

AA assessment and assimilation ACT annual traffic change ADS-B automatic dependent surveillance—broadcast AFRAC adapted-software fraction AIS Automatic Identification System API Application Programming Interface AUTOSAR Automotive Open Systems Architecture BCA business case analysis BDA battle damage assessment C2 command and C/S/P cost, and performance CAS Collision Avoidance System CAAS Common Avionics Architecture System CM percent code modified COPLIMO Constructive Product Line Investment Model COTS commercial off-the-shelf CS Capability Set DB DIB Defense Industrial Base DM percent design modified DOCU degree of documentation DoD Department of Defense DVE degraded visual environment EGI Embedded Global Positioning System Inertial EO/IR electro optical infrared EVM EW electronic warfare FACE Future Airborne Capability Environment FM flight management FMV full motion video xiii FP flight plan FOS Family of Systems FVL Future Vertical Lift GPS Global Positioning System IASE integrated aircraft survivability equipment ICTB Integrated Capability Technical Baseline ID Identification IDD Interface Design Document IHMS integrated health monitoring system IM percent of integration required for adapted software IOS Input/Output Segment IP Intellectual Property IR infrared IRCM infrared counter measure ISR intelligence, reconnaissance, surveillance IWS Integrated Warfare Systems JTRS Joint Tactical Radio System KSA knowledge, skills, abilities KSLOC 1000 Source Lines of Code LCS Littoral Combat Ship M meters MOSA Modular Open Systems Approach MTB Mission technical Baseline NAVAIR Naval Air Systems Command NAVSEA Naval Sea Systems Command NPV Net Present Value OS OSA Open Systems Architecture OSS Operating System Segment PCS Portable Component Segment PEO Program Executive Officer PFRAC product-specific fraction xiv PM Program Manager PMI Institute PMO Office POSIX Portable Operating System Interface PSIZE product size PSS Platform Specific Service RADALT radar altimeter RCR Relative Cost of Reuse RCWR Relative Cost of Writing for Reuse RELY required reliability RFI Request for information RFRAC reused-software fraction ROI return on investment RUSE cost associated with development for reuse SAR Synthetic Aperture Radar SLOC Source Lines of Code SU software understanding SYSCOM Systems Command TACAN Tactical Air Navigation System TAPO Technical Applications Program Office TAWS Terrain Awareness Warning System TD Technical Data TOI Target of Interest UAI Universal Armament Interface UAS Unmanned Aircraft System UNFM programmers’ relative unfamiliarity with the software

xv THIS PAGE INTENTIONALLY LEFT BLANK

xvi ACKNOWLEDGMENTS

I would like to thank my wife, Amber Rittenhouse, for pushing me to pursue further education opportunities. She moved across the country to allow me to attend the Naval Postgraduate School and provided opportunities for me to dedicate time to my studies. Your compassion and understanding for my needs during this educational opportunity have allowed me to complete this thesis and all coursework for an MBA without delay.

I would also like to thank my thesis advisor, Ray Jones, and second reader, Dr. Robert Mortlock. You provided a sounding board for me to bounce ideas off as well as pushed me to critically think about the research I was tackling. My thesis is better for it.

xvii THIS PAGE INTENTIONALLY LEFT BLANK

xviii I. INTRODUCTION

A. BACKGROUND

The “Section 809 Panel for Streaming and Codifying Acquisition” was tasked with providing a recommendation to congress regarding ways to streamline and improve the Department of Defense (DoD) acquisition system (Serbu, 2018). As part of their final report, the 809 Panel is recommending a transition from a “program-centric” to a “portfolio-centric” defense acquisition model (Serbu, 2018). Their plan entails empowering portfolio acquisition executives to perform technical and programmatic portfolio management of similar or common capabilities and systems (Serbu, 2018). The portfolio-centric management model would include portfolio acquisition executives possessing requirements visibility across the Services. This management model will provide the ability to deploy capabilities across the current “stove-piped programs” or “cylinders of excellence” currently established within the individual Services. By aligning common requirements, the 809 Panel believes they can ultimately achieve acquisition efficiencies resulting in decreased life-cycle costs and increased speed to field capabilities.

A few members of the Defense Industrial Base (DIB) already employ portfolio management within their individual companies. Some of these companies have successfully created both software and hardware product lines resulting in lower production costs, increased market share, and increased profits.

B. PURPOSE

The purpose of this paper is to answer the question: Can the DoD achieve acquisition efficiencies by shifting from program-centric management to portfolio-centric management for software intensive weapons systems, which result in decreased life-cycle costs and increased speed to field capabilities? The scope of this paper will focus on the feasibility of a software capability portfolio-centric management approach on software intensive weapon systems using an open systems architecture (OSA) to answer this question.

1 C. PROBLEM

The DoD has traditionally managed their programs using a program-centric management approach. This has led Congress to question whether this management approach is driving program costs higher and leading to ever longer program . The question then becomes can managing DoD programs as portfolios of programs and products lower costs and shorten development and fielding schedules?

The program-centric management approach is heavily engrained in the culture, , and of the DoD. DoD Program Managers (PM) are responsible for cost, schedule, and performance for the entirety of their program. They are not responsible for the success of other programs and are incentivized to think in a stove-piped fashion by current resourcing models. The program managers are funded, in essence, to execute their acquisition program baseline from scratch. Their mindset is focused on minimizing to their program. The program managers believe that risk and control are tightly coupled, and risk will be injected if they do not fully control every aspect of the program. This fact leads to the need of a portfolio manager with the authorities to dictate the direction a program takes: A portfolio manager that attempts to harmonize capabilities.

D. METHOD

I will use a qualitative research method to analyze the concepts and characteristics associated with portfolio-centric management and how it differs from program-centric management. The focus will be on the management software intensive weapon system programs. As part of my discussion I will conduct a business case analysis (BCA) leveraging concepts identified through the literature review. I will use the concepts gathered from the literature to establish an example portfolio-centric organization. I will recommend a technical approach to weapon systems portfolio management by reviewing the literature to understand if there are any open, consensus-based, software platform standards that can be leveraged. I will also review the literature for the key concepts that must be used by an organization to successfully deploy a product-line architecture supporting portfolio-centric software management.

2 II. BACKGROUND

A. CURRENT PROGRAM-CENTRIC MANAGEMENT MODEL

The current DoD acquisition system is designed around a program-centric management model. A singular PM has cradle to grave cost, schedule, and performance (C/S/P) responsibility for the platform as well as all the technology payloads that accompany the platform. While the PM reports operationally to a Program Executive Officer (PEO) and receives technical direction from a System Commander (SYSCOM), they have the programmatic authority and budget to execute the program. An example of an organization using a program-centric management is depicted in Figure 1.

Figure 1. Program-Centric Organization

3 In the current model the PEOs are executive managers of multiple programs or in some cases the PEO can also function as PM for large or classified programs (Undersecretary of Defense for Acquisition, Technology, and [USD(AT&L)], 2017). Each Program Management Office (PMO) that falls under the PEO will be assigned a PM by the acquisition executive (USD(AT&L), 2017). The PM is responsible for executing the approved Acquisition Program Baseline (USD(AT&L), 2017). The PM is also responsible for the acquisition strategy, business approach, managing risk, creating competition, Intellectual Property (IP) Strategy, Modular Open System Approach (MOSA), development of initial program baseline, Earned Value Management (EVM), and cost control (USD(AT&L), 2017).

As depicted in the organization Figure 1, the funding is aligned to platform requirements and provided directly to the program centric PMOs. The PMO then provides funding to a System Command (SYSCOM) to staff the program office with multiple competencies such as engineering, , contracting, legal, program management, test and , and logistics.

Every PMO is also reliant on industry to develop the weapons system. While the PM is responsible for oversight of the contractor developing the system, the PM and the program office staff does not always possess enough technical insight into the system design to truly control the technical direction of the program. This leaves the industrial- base to work in seclusion with little to no oversight to define proprietary hardware and software architectures (Sweeney, Guertin, & Schmidt, 2015). This forces the DoD into systems built for specific platforms or proprietary product-lines (Sweeney et al., 2015). The resulting product-lines and architectures have limited the government’s ability to populate a competitive marketplace with third-party vendors to add new capabilities, alter current capabilities, or assume the role of a capability integrator (Sweeney et al., 2015). This program-centric management approach has given rise to numerous dissimilar, non- interoperable OSAs (Sweeney et al., 2015). These open architectures have provided minimal benefits to the DoD and often resulted in a lack of competitive awards eliminating the numerous benefits of OSAs (Sweeney et al., 2015).

4 B. NEED FOR A DIFFERENT MODEL

There are several issues with the current program-centric model. This model the PEO has no actual control of the financial for the program within their PEO’s purview. The PEO may be of superior rank to the PM and have approval authority for the acquisition program baseline, but the PM ultimately controls the execution of the program. Another issue is the lack of independent funding for the SYSCOM. This leads to a conflict of interest and a reliance on the PM to fund the staff that are supposed to act as the independent technical authority. This issue is based on my experience as an acquisition professional, employed by a SYSCOM, and matrixed to program office. While the SYSCOM possessed the authority to drive the technical direction of the program, the program office staff made up of a majority SYSCOM. Personnel became engrained in the culture of the program office and ultimately did what was best for the individual program even it was detrimental to the technical direction that the SYSCOM was giving.

The PM is also responsible for a MOSA and IP strategy, but this strategy is centered around their unique program requirements. While leveraging MOSA and a good IP strategy is beneficial to an individual program, the true benefits of MOSA cannot be realized without a portfolio approach. The fact that the MOSA and the IP strategy are program specific limits the power of these and make it impossible to leverage IP developed on program X on program Y. Also, the PMO is often reliant on a contractor to develop the details of the MOSA strategy and at the time of contract award there are not enough technical details to develop a sound IP strategy.

In the age of complex and expensive weapons systems and limited , there is a need for a different way of doing business. This fact is why the Section 809 Panel is recommending a cultural shift from a program-centric management model to a portfolio- centric management model for all types of DoD systems. The DoD must be able to consolidate its resources into product-lines that can be readily developed from reusable components, quickly upgraded or modified. By leveraging products across a portfolio of systems the DoD can theoretically drive down costs and reduce the time that it takes to field new capabilities and weapons systems. OSA and product-line engineering have different goals and objectives, but the combination of the two approaches might represent 5 a panacea that can ultimately drive down costs and shorten fielding times (Guertin & Clements, 2010). The combination of OSA and product-line engineering involves a central shift of organizational behavior, resourcing, and business practices (Guertin & Clements, 2010).

6 III. LITERATURE REVIEW

A. PROGRAM-CENTRIC VS. PORTFOLIO-CENTRIC MODEL

There has been a tradition of creating hardware-based product lines to control life- cycle costs and allow for the quick production of various products (Faust & Verhoef, 2003). Now with the advent of software intensive systems, there must be a shift to a product line approach for software capabilities.

When first generation computers were originally developed, they were designed and developed in a program-centric model (Schach, 2007). Now with the increased use of information technologies, a small number of companies are developing systems starting with software-based product lines from inception (Faust & Verhoef, 2003). According to Faust and Verhoef (2003), this is normally seen in companies that are developing small scale information systems. Large companies that develop large complex information systems struggle with managing products across their national or global enterprises leading to a program-centric management approach (Faust & Verhoef, 2003). A few symptoms that lead down the path of a program-centric management approach include unique customer requirements, highly customized systems, decentralized control and modification, and geographical distribution of the organization (Faust & Verhoef, 2003).

Product-line engineering is a widely leveraged method to design and develop portfolios of software components (Günter, Clements, McGregor, Muthing, & Schmid, 2004). In a 2004 IEEE Software article Günter et al. describes the basis of product-line engineering as a core set of components coherently designed and developed as a framework or collection of software artifacts specifically built to be leveraged across a portfolio. According to the same authors, this approach to engineering can lead to significant economic benefits versus developing software in a program-centric approach. The main economic benefit that companies emphasize is return on investment (ROI), even though there are other financial benefits to be had including lower life cycle maintenance costs and the evolution of the components and systems leveraging the reusable components over time (Günter et al., 2004).

7 1. Organizational Alignment

To achieve the strategic goals of lower costs and shorter schedules, the organization will need to shift their thought process. Portfolio-centric management approaches have a different organizational and cultural construct than a traditional program-centric model. The organizational structure of a portfolio-centric organization focuses their efforts on the best strategies and processes to design, develop, and test common components for the portfolio vice the program. The organization takes advantage of commonality across the portfolio. (Günter et al., 2004). To reap the cost and schedule benefits, the entire portfolio- centric organization requires training and reskilling, product-line engineering processes need to be developed and instantiated, and a culture of sharing and transparency instilled (Günter et al., 2004).

The Project Management Institute (PMI) distinguishes between management of a program and a portfolio. Their definition of a program is akin to a platform for the context of this paper. PMI defines a program as collection of associated , managed together to attain benefits and control not achieved through managing them independently (Project Management Institute [PMI], 2004). The programs may also consist of portions of associated work separate from the individual projects included in the program (PMI, 2004). PMI (2004) describes a portfolio as a group of projects and/or programs and related efforts organized and managed in a way that furthers strategic business and organizational goals. According to the PMI (2004), the areas of effort under the portfolio may not necessarily related.

PMI also distinguishes between program management and portfolio management. Program management is considered the unified administration of a program to attain the individual program’s strategic purposes and goals (PMI, 2004): “Portfolio management is the centralized management of one or more portfolios, which includes identifying, prioritizing, authorizing, managing, and controlling projects, programs, and other related work, to achieve specific strategic business objectives” (Ross & Shaltry, 2005). A portfolio management organization is shown in Figure 2.

8

Figure 2. Program and Portfolio Relationships. Source: PMI (2004).

PMI considers portfolio management to be a distinct a , normally aligned to a specific team led by a portfolio manager (Ross & Shaltry, 2006). Portfolio management is a continuous set of interconnected processes, which balance related efforts within the portfolio (Ross & Shaltry, 2006). In the DoD, the PEO is equivalent to a portfolio manager, the PMO is the program manager, and an integrated product team lead would be equivalent to the .

2. Organizational Challenges

An organization that is making a shift from a program-centric management approach to a portfolio-centric approach will encounter challenges. The hardest challenge is shifting the culture within the organization. Program-centric organizations have created unique platform solutions resulting in containerized programs (Sweeney et al., 2015). The goals and objectives of the organization must shift to emphasis identifying common capabilities that cut horizontally across multiple programs (Sweeney et al., 2015). This shift in thinking will require program managers to better understand programmatic risk and assist portfolio managers with managing shared risk across programs (Sweeney et al., 2015). 9 Another challenge is financial. Organizations will be required to invest in a common product-line and align financial resources across the programs in the portfolio. The product-line requires appropriate resourcing up front for an organization to see the benefits of a portfolio-centric approach. Funding vertical stovepipes to create uncoordinated, unique solutions is not a suitable approach to establish shared technical artifacts, test environment, and life-cycle support (Sweeney et al., 2015).

The organization will also need to survey its workforce to verify that it possesses the correct set of knowledge, skills, and abilities (KSAs) to adopt a portfolio-centric management approach (Sweeney et al., 2015). Organizations making the shift require a workforce that is highly skilled in and portfolio management.

3. Portfolio-Centric Technical Characteristics

To shift from a program-centric to a portfolio-centric management model will require the organization to rethink how their systems and capabilities are designed and developed. Product-line engineering describes a process where components are engineered to take advantage of common functionality, while isolating the uniqueness (Günter et al., 2004). Software developed for a portfolio-centric management approach must be deliberately developed to meet the needs of the entire product-line. Deliberate reuse is achieved through portability and (Schach, 2007). Software components are portable if it is quicker and less costly to adapt the already developed component for execution on another (, development tools, computing hardware, and operating system) architecture than to redevelop the component (Schach, 2007). Portability can be more readily achieved through abstraction of software functionality from the underlying computing platform, which leads to greater reusability of components.

Software reusability is leveraging components of one system in a product-line to empower the development of a separate system in the product-line to meet differing customer requirements and functionality (Schach, 2007). Software reuse does not just consist of the source code that makes up the component, but it could be the components design, training materials, test data, or programmatic estimates (Schach, 2007).

10 a. Types of Reuse

There are two types of reuse: opportunistic/accidental and systematic/deliberate (Schach, 2007). According to Schach (2007), Opportunistic reuse occurs when a developer of a new product realizes that software components of an existing product can be leveraged across to new product. In contrast, systematic reuse occurs when software components are deliberately designed and developed specifically for future reuse in other products (Schach, 2007).

b. Benefits of Deliberate Reuse

One benefit of systematic reuse is artifacts are designed and developed for use in future products (Schach, 2007). Components that are built for deliberate reuse are systematically designed and developed to be leveraged across a family of systems (Günter et al., 2004). Schach (2007) believes this fact makes components easier and safer to leverage in other systems. The artifacts developed for deliberate reuse are generally more robust, well documented, and thoroughly tested (Schach, 2007). They are usually developed leveraging software standards, normalized design and development practices, and frequently exhibit a consistency of coding style that facilitates cost effective code maintenance (Schach, 2007). If a company can take advantage of a reusable software component multiple times, then they may recoup or even profit from their initial investment in the component.

c. Potential Negative Impacts of Systematic Reuse

There are cost and schedule impacts to implementing systematic reuse within a company. According to Schach (2007), designing and developing for reuse can be initially expensive. A company must make time in the project schedule to specify, design, develop, test, and document reusable software components (Schach, 2007). Schach (2007) also believes that if proper product-line is not achieved, there may be no guarantee that the components will be reused leading to the risk that a company will not recoup the initial investment of designing and developing the potentially reusable artifact.

11 d. Impediments to Reuse

There are several impediments to software reusability. These include “not invented here” syndrome, quality assurance, lack of visibility, unwillingness to invest resources upfront for reuse, data rights issues, and lack of source code. Not invented here syndrome occurs when software developers would rather design and develop a component possessing similar or equivalent functionality from scratch (Schach, 2007). According to Schach (2007), software developers will also balk at integrating a reusable component if the software developer is unsure of the quality or pedigree of component. The software developer may feel that a reusable component with a poor pedigree will induce faults into a system (Schach, 2007). It is Schach’s (2007) believe that software developers are also hesitant to leverage Commercial Off-the-Shelf (COTS) components because there may be a lack source code to be analyzed. Without the source code, software developers will assume there is a risk to integrate third-party reusable components into their system.

Some companies design and develop several reusable components but lack the ability to propagate components across multiple products. This may because developers have limited visibility into the other components developed within the company (Schach, 2007). A company may not have a catalog detailing the components and functionality that were developed for reuse.

Companies also may be unwilling to invest in the initial design and development of reusable software components with no guarantee of a ROI (Schach, 2007). Companies may not have the appropriate data rights to use components developed by another company or may not be willing to extend data rights to another company to use their reusable components (Schach, 2007). This can lead to costly legal issues.

B. OPEN SYSTEMS ARCHITECTURE

Another way to decrease costs and compress development schedules for new capabilities, is to create a competitive and innovative marketplace. This is where OSA comes into the picture. OSA is an approach to architecting systems through decomposing requirements into hardware and software services, which are executed within defined computing platform boundaries and layers (Department of Defense [DoD], 2013). OSA 12 also brings a robust to facilitate competition (DoD, 2013). DoD (2013) has mandated the use of OSA and that system requirements be based on open, consensus-based standards to the maximum extent possible. OSA systems are derived from components developed by multiple companies creating a competitive environment. This competition creates an environment that innovates capability advancements and allows for technology refreshes more quickly than traditional proprietary systems (Guertin & Clements, 2010). The OSA components adhere to publicly available, consensus-based standards which allows for a competitive environment where any supplier or developer can provide innovative components (Guertin & Clements, 2010).

1. OSA Pillars

Based on the DoD open systems architecture contract guidebook for program managers (2013), The OSA model is defined by five principles or pillars. According to DoD (2013), these principles include:

1. System designs are based on open standards that support loose coupling and high cohesion of components allowing for independent .

2. An enterprise investment strategy for portfolios that maximize reuse of proven hardware and software designs thus minimizing system costs.

3. Innovative sustainment approaches for software employing established technology insertion, technology refresh, and software upgrade and patching methods.

4. Leveraging continuously updated and transparent system design artifacts that are peer reviewed by government, academia, and industry to substantially lower development risk.

5. A vetted data rights strategy to ensure competition and availability of substitute solutions and sources.

13 2. Holistic Approach

The benefits of OSA have been stifled by uncoordinated acquisition processes and can only be realized through the deliberate use of OSA (Sweeney et al., 2015). According to Sweeney et al. (2015), this requires organizations to take a holistic, approach ensuring maximum benefits.

A holistic OSA approach begins by identifying and managing a set of common software components (Sweeney et al., 2015). These common components are identified by functionally decomposing system capabilities (Sweeney et al., 2015). The integration of these capabilities into a system is enabled using a standardized, open, consensus-based technical reference framework and reinforced by an objective driven IP strategy. These three fundamental pillars (functional decomposition, technical reference framework, and IP strategy) of a holistic OSA approach provide the basis of a portfolio-centric management approach (Sweeney et al., 2015).

C. ORGANIZATIONAL USE OF PORTFOLIO-CENTRIC MODEL

The DoD should not attempt to shift to a portfolio-centric management approach without first gaining a further understanding of other markets that employ this approach. There are a few commercial and DoD related organizations that are successfully employing portfolio management to control cost and decrease the time it takes to get new products to market.

1. Automotive Industry

The automotive industry traditionally leveraged a portfolio-centric management approach to gain efficiencies and cut costs within their hardware product lines. The hardware centric culture is evolving with the advent of the Automotive Open Systems Architecture (AUTOSAR, n.d.) standard. This standard defines an OSA computing platform for use across the automotive industry (AUTOSAR, n.d.). The standard is developed by an open, consensus-based, standards body that contains over 100 different auto and component manufacturers (AUTOSAR, n.d.). Figure 3 shows the membership of the AUTOSAR consortium.

14

Figure 3. AUTOSAR Consortium. Source: AUTOSAR (n.d.).

AUTOSAR’s goal is to create an open computing platform that supports portability, composability, and integration of software components across the vehicle life cycle (AUTOSAR, n.d.). This goal supports the cost effective and timely modification and upgrades of software capabilities across a fleet of vehicles. The way that AUTOSAR achieves this technically is through a standard software architecture containing layers of abstraction and a functional decomposition (AUTOSAR, n.d.). They also describe IP strategies at the different boundary layers of the architecture.

2. Smart Phones

The smart phone market is dominated by two major players, Apple and Google. Both companies leverage a product line computing platform and have created a portfolio of product offering that leverage common computing platforms. Apple and Google leverage product-line architectures to drive down development costs and decrease the time it takes to get new products and capabilities to market. These two companies differ however in their adoption of OSA principles.

15 a. Apple

Apple leverages a portfolio centric management approach for its iOS computing platform but does not fully adopt OSA principles. Apple sustains proprietary rights for the computing platform controlling every stage of the process ranging from to production release (Yoon, 2014). The iOS computing platform only executes on Apple’s hardware leaving the customer with little choice or options when it comes to Apple products. Contributions to Apple’s product-line come from within the company potentially capping innovation (Yoon, 2014).

b. Google

Google leverages a portfolio-centric management approach for its Android computing platform but unlike Apple, Google has adopted OSA principles more broadly. Google has an OSA policy, which allows smart phone manufacturers to configure and customize the Android computing platform on each product within Android portfolio or marketplace (Yoon, 2014). Google also allows the manufacturers to determine how they adopt the product-line and configure the computing platform. This provides the equipment manufacturers and the consumers more flexibility and choice. This open model also promotes and contributions to the computing platform from equipment manufacturers, end users, service providers as well as Google. This consortium of contributors provides a greater chance of innovation and development of disruptive technologies.

3. Rockwell Collins

Rockwell Collins (now Collins Aerospace) is a manufacturer of commercial and defense avionics systems. Rockwell Collins was an early adopter of product-line engineering for software intensive weapons systems. They developed a computing platform for use across their portfolio of avionics offerings.

Rockwell Collins developed a set of software intensive avionics built on their Common Avionics Architecture System (CAAS) product-line architecture for the U.S. Army (Clements & Bergey, 2005). The Army’s Technical Applications Program Office

16 (TAPO) required CAAS across its portfolio of special operations rotary wing platforms to reduce development, maintenance, and integration costs (Clements & Bergey, 2005). Rockwell Collins has since leveraged the CAAS architecture to expand its portfolio including other fixed-wing and rotary-wing platforms.

The CAAS was initially developed when Rockwell Collins leveraged its commercial investment in its common reusable element software and its Flight2 product- line architecture (Clements & Bergey, 2005). Rockwell Collins used this investment to create a product-line avionics system based on common computing platform (Clements & Bergey, 2005). This architecture formally became CAAS. Rockwell Collins has since modified their CAAS architecture to leverage the FACE Standard and create a product-line OSA architecture that is open inside and outside the company. Rockwell Collin’s product- line strategy is shown in Figure 4.

Figure 4. Rockwell Collins Open Architecture Migration. Source: Howington (2016).

By using the CAAS architecture and Rockwell Collin’s ability to effectively manage a product line architecture, TAPO was able to achieve substantial cost and schedule benefits (Clements & Bergey, 2005). These savings were realized through reduced costs, reduced cost and time to field new capability, lower 17 capability integration costs, an increased reuse of technical artifacts and software components, and a decrease in flight test hours (Clements & Bergey, 2005). Rockwell Collin’s product-line success was a motivator for the establishment of the FACE consortium.

4. NAVSEA

The Naval Sea Systems Command (NAVSEA) has organized one of its PEOs to be a mission system portfolio manager. PEO Integrated Warfare Systems (IWS) acts as the portfolio manager that deploys common mission systems to the ship platform PEOs. This model has allowed NAVSEA to consolidate the number of systems that are deployed across its portfolios of ships, submarines, and aircraft carriers.

As a portfolio manager for shipboard mission systems, PEO IWS leverages a product line engineering approach (Emery, 2010). PEO IWS accomplishes portfolio management by performing and defining a computing platform architecture at the PEO IWS level (Emery, 2010). PEO IWS then flows the component product description to the directorate levels for development (Emery, 2010). Once the components are developed, they are deployed to a platform along with the product-line computing platform (Emery, 2010). PEO IWS’s portfolio management process is depicted in Figure 5.

18

Figure 5. PEO IWS Portfolio Management Process. Source: Emery (2010).

NAVSEA’s goals for leveraging a portfolio-centric management approach include strategic component reuse across Combat Systems. This strategic reuse will reduce integration and test costs for new capabilities, improve system interoperability, and simplifies operator cross-training (Emery, 2010). By modularizing the software into components, NAVSEA can isolate changes to the system reducing test and certification costs (Emery, 2010). Leveraging a standard computing platform across programs, NAVSEA has eliminated the barriers to entry for small and medium size companies to develop new innovate technologies and transfer these technologies to programs of record (Emery, 2010).

D. PRODUCT LINE SOFTWARE COST MODEL

In order to reap the economic benefits of a portfolio-centric software management approach, companies must develop a BCA describing the situation where the costs of the can be amortized across two or more programs (Günter et al., 2004).

19 The ROI on a product line can be defined as ROI = Savings / Investment (Günter et al. 2004). The economic benefits of a portfolio-centric approach increase as the number of products or programs that a company has in a product line increases (Günter et al., 2004).

Currently the only available tool for calculating software costs for a portfolio is the Constructive Product Line Investment Model (COPLIMO). COPLIMO was developed by at University of Southern California (Boehm, Brown, Madachy, & Yang, 2004). The COPLIMO model is based on the Constructive Cost Model (COCOMO) II model also developed by Barry Boehm. COCOMO II calculates the effort necessary to develop software using KSLOC, several scaling factors, and an assumption of no reuse. (Boehm et al., 2004) The COPLIMO model uses the COCOMO II model but extends it to take new, modified, and reused software into account as well as the effort to assimilate or integrate software into the next programs (Boehm et al., 2004). The COPLIMO Model also looks at software maintenance costs over five years (Boehm et al., 2004). According to Boehm et al. (2004), the model calculates an annualized maintenance KSLOC size based on the new, modified, and reused size and leverages the same calculations and scaling factors from the development phase (Boehm et al., 2004).

Software product line investment cost models must address investment costs and savings (Boehm et al., 2004). In the COPLIMO model, this is captured by the Relative Cost of Writing for Reuse (RCWR) and the Relative Cost of Reuse (RCR) (Boehm et al., 2004). RCWR signifies additional cost of engineering reusable software as a portfolio of programs and products, compared with the cost of engineering the software intended for a unique program (Boehm et al., 2004). The RCR represents the cost of leveraging the already developed, reusable software in a new program relative to developing new capabilities from scratch (Boehm et al., 2004).

The COPLIMO model consists two key components. They are a development cost model for product-lines and an annualized sustainment addition: “COPLIMO makes several simplifying assumptions about the uniformity and stability of the portions of the software that involve product-specific newly-built software, fully reused black-box product-line components, and product-line components that are reused with adaptation (Boehm et al., 2004). 20 E. FACE OPEN SYSTEMS STANDARD

Parts of this section were adapted from a working paper previously written by Robert Sweeney (Sweeney, 2013)

The benefits of design reuse are compounded when the architecture or computing platform is standardized and reused (Schach, 2007). According to Schach, this type of reuse is achieved through the deployment of software product-lines. “The idea is to develop a software architecture common to a number of software products and instantiate this architecture when developing a new product (Schach, 2007).”

Software product lines are designed with variation points (Faust & Verhoef, 2003). These variation points are a portion of the software that allows flexibility supporting variability across multiple systems (Faust & Verhoef, 2003). The FACE reference architecture defines 8 total variation points; 5 architectural segments and 3 interfaces (The Open Group, 2017). The FACE reference architecture provides a technical reference framework that defines a standardized computing platform.

The FACE Standard is developed by a consensus body called the Open Group FACE Consortium. The FACE standard was specifically developed to support portfolio management of software intensive capabilities for weapon systems and is currently the only open consensus-based standard that support these goals.

The FACE Standard defines requirements for each variation point in the architecture (The Open Group, 2017). The architectural segment variation points include the Operating System Segment (OSS), I/O Segment (IOS), Platform Specific Segment (PSS), Transport Services Segment (TSS) and the Portable Component Segment (PCS) (The Open Group, 2017). The interfaces include the Operating System (OS) Interface, I/O (IO) Interface Interface, and the Transport Services (TS) Interface (The Open Group, 2017). This layered architecture creates a federated architecture (Faust & Verhoef, 2003). Figure 6 describes the FACE reference architecture.

21

Figure 6. Example FACE Architectural Segments. Source: The Open Group (2017).

By creating this federated architecture, the FACE standard isolates the business impact to each of these segments and interfaces. This allows technical and business impacts to be aligned and well understood driving risk of the unknown out of the portfolio management approach (Faust & Verhoef, 2003).

The FACE consortium is an initiative to create a technical and programmatic environment enabling common software product-line architectures allowing for more rapid software capability integrations. The consortium’s goals include decreasing life-cycle costs and reducing the time to field new capabilities for DoD software aviation capabilities.

In the technical domain, the FACE Standard describes a standardized, hardware agnostic, common software computing platform. This platform defines requirements for architectural segments previously discussed. These segments define a container for modular software components. Key interfaces provide links for the

22 segments. The FACE Consortium established testable requirements for MOSA guidance, reducing or even eliminating vendor or platform specific software architectures.

In the business domain, the FACE consortium has documented the business model and the policies and procedures to establish and maintain a marketplace of FACE conformant software components that can be integrated into multiple platforms.

When the FACE Standard was originally conceived it was meant to establish an open architecture and a software product-line approach for DoD avionics, but because of the diversity of contributors, the FACE Standard quickly evolved into a generic software product-line standard spanning multiple technical domains depicted in Figure 7. It is unlikely that FACE can be used on all systems or for all capabilities in a given platform. The domains that the FACE Standard will benefit and has applicability to include:

• Loosely coupled, real-time, safe, embedded systems

• Loosely coupled, real-time, embedded systems

• Loosely coupled, non-real-time, embedded systems

• Loosely coupled, non-real-time, general purpose systems

• Service oriented, enterprise systems

Figure 7. FACE Technical Domain Usage

23 1. Threats to Portability

Program centric software is typically closely tied to both computing hardware, development tools, and operating systems creating threats to software portability. Different hardware architectures affect the binary code that is generated during compilation and even impacts the ordering of bytes in multi-byte data structures. Operating systems provide a of application programming interfaces (API) to the software developer. Different operating systems may provide unique or proprietary APIs that a software developer can utilize. Development tools such as , assemblers, linkers and archivers target specific hardware families and operating systems. languages also may represent low-level data types in a variety of manners.

Due to these threats to portability, porting an application to new hardware or operating systems often involves modifications to the application source code and in some cases (where OS specific APIs are directly used in the application source code) may even require updates to the application’s business logic. There are standard methods for interfacing software between languages such as Ada and C, but these techniques rely on the software developer to handle low-level data consistency and formatting issues.

2. FACE Solutions to Portability Threats

The FACE Standard prioritizes software portability at the source code level. The intent is to minimize the software development effort when porting to a new hardware platform or operating system. Operating system interfaces are prescribed by the FACE Technical Standard; All FACE conformant operating systems must provide the same interfaces with identical behavior. Applications that are FACE conformant can only utilize interfaces that are defined in the FACE Standard. No longer can an application make use of a proprietary operating system API. FACE conformant applications also do not directly access the hardware. Since the FACE Technical Standard is based on source code portability, this minimizes the effort necessary to migrate between software development environments. The source code of FACE conformant components can be migrated to another development environment/compiler because the compilers are based on

24 standards. These features minimize the effects of porting an application to another hardware platform or operating system.

Additionally, the FACE Standard defines a rigorous data architecture that must be used for all component communication. This data architecture addresses the low-level data representation issues. This minimizes the developer’s effort to manage data type conversions between hardware architectures or languages. Another feature of the FACE data architecture is the conceptual and logical representations of the data. No longer does a developer depend solely on an interface design document (IDD) to describe the syntax and semantic meaning of data within a system.

The FACE Standard leverages standard programming languages, operating system APIs, language runtimes and frameworks, and to minimize the effort and cost of porting software. The abstractions, patterns and standards defined and/or referenced in the FACE Standard assist with decreasing the overhead required to port software to new hardware or operating systems.

Lastly, the FACE Standard defines requirements that software components must be conform with. This bounds the number of interfaces that an application can utilize. The architectural segments force the software developer to modularize their software instead of creating a monolithic component. The use of architectural segments in the FACE Standard decreases software porting effort by isolating hardware details into specific software modules. The FACE Standard does not define a standard set of functionality or behavior for capabilities. The functionality and behaviors are defined through a functional decomposition, which is normally performed by the capability developer and lead system integrator.

F. FUNCTIONAL DECOMPOSITION

In order to increase reuse of software there must be a consorted effort to establish the core set of software capabilities within the portfolio. By leveraging product-line engineering techniques a common set of portable and reusable components is designed and developed (Schach, 2007). This is achieved by functionally decomposing the system requirements of the product-line and creating common reusable components that represent 25 common functions. Every system will have some unique functionality, but through product-line engineering, a component can have identical source code, but will be instantiated differently using configuration parameters (Günter et al., 2004). This can be accomplished statically at compile time or even dynamically at run-time.

Instead of starting from scratch, future systems are developed by selecting a standardized architecture and porting and integrating reusable components into the standardized architecture (Schach, 2007). According to Schach (2007), systems are now built by composing reusable components, potentially with the assistant of software design tools.

The functional decomposition begins with mission engineering where mission functions are decomposed into components. This decomposition is accomplished by analyzing what is called the “Kill Chain” (Sweeney et al., 2015). The kill chain describes the conceptual tasks that it will take to accomplish the mission. Naval Air Systems Command (NAVAIR) documents the functions decomposed from the conceptual tasks during the kill chain analysis in a Mission Technical Baseline (MTB) (Sweeney et al., 2015).

The next step in NAVAIR’s process is to assign the capabilities documented in the MTB to appropriate platforms and systems, which is described in the Integrated Capability Technical Baseline (ICTB) (Sweeney et al., 2015). A portfolio manager can then review the ICTB to capability development and integration roadmaps for a portfolio of programs. The ICTB is also leveraged to develop the core software components that provide core functions across the portfolio. The documented functional decomposition should include a brief component description, component functionality, component behavior, and component-to-component interoperability requirements (Sweeney et al., 2015). Figure 8 shows the functional decomposition process.

26 Figure 8. Example Functional Decomposition Process. Source: Guertin, Sweeney, and Schmidt (2015).

G. DATA RIGHTS

PMs overseeing systems not originally designed with OSA principles attempt to break vendor lock through costly purchases of the IP needed to upgrade or maintain their systems (Sweeney et al., 2015). To maximize the benefits of leveraging a portfolio-centric management model a robust and refined IP strategy must be developed (Sweeney et al., 2015). The IP strategy ensures that an organization possesses the ability to procure, develop, upgrade, modify, or integrate the components needed to achieve the portfolio’s goals and objectives.

An IP strategy assists organizations with ensuring that all necessary technical data (TD), computer software, and data rights required for maintaining a product are accessible during the product’s life cycle (DoD, 2014). DoD (2014) describes maintaining the product includes replacing, repairing, modifying, upgrading, and technology insertion. “TD includes any recorded information of a scientific or technical nature (e.g., product design 27 or maintenance data, and computer . Computer software includes executable code, source code, code listings, design details, processes, flow charts, and related material” (DoD, 2014).

Leveraging standard technical reference frameworks and decomposing the functions provide increased opportunities for developing a cohesive IP strategy. Strategies that lack these two pillars of the holistic OSA approach will need to rely on having unlimited use rights to the software components so they can be modified or upgraded at will (Sweeney et al., 2015). Monolithic system architectures resulting from the lack of these two pillars thwart competitive capability and obsolescence upgrades.

28 IV. DISCUSSION

Based on my analysis, a shift from a program-centric to a portfolio-centric management approach may drive down life-cycle cost and decrease fielding times for software intensive weapon systems. For the DoD to understand potential benefits of portfolio-centric management for software capabilities, they will need to conduct a BCA, potentially restructure the acquisition organization, and establish a holistic OSA technical approach.

A. PROGRAMMATIC ANALYSIS

1. Cost Analysis

Parts of this section were adapted from an essay previously written by Robert Sweeney for Naval Postgraduate School, Economic Analysis and Defense Allocation, GB4071. This section was adapted with the explicit permission of the professor and thesis advisor. (Sweeney, 2018)

To achieve the first step of conducting a BCA on a potential portfolio, the DoD must select a product-line software costing tool. Currently COPLIMO is the only openly available cost tool specifically designed to assess life-cycle costs for software intensive portfolios. To justify my conclusion that there is a business case to shift to portfolio-centric management of weapons systems, I will leverage the COPLIMO tool and tune it with assumptions from my prior experience a software for avionics systems at Rockwell Collins and a software manager at NAVAIR.

a. Assumptions

For the cost estimation, I make several assumptions based on personal experience. The conceptual portfolio I chose to depict the benefits of software reuse is an aviation portfolio of five weapon system platforms. The life cycle of each platform includes a three- year development cycle and a five-year maintenance life cycle. Each platform’s development phase will begin in the second year of the previous platform’s development phase and the maintenance phase will begin immediately after development has concluded.

29 The first of my assumptions is that certain portfolios of platforms share similar if not identical capabilities. For example, all aviation platforms must be able to aviate, navigate, and communicate in a similar or identical fashion. In other words, the pilot must aviate with flight controls and instruments (FAA, 2018). Second, the pilot must navigate from a source and destination, and when needed, communicate outside of the aircraft (FAA, 2018). The second assumption is that all platforms have unique capabilities, therefore not all the software on a platform is designed for reusability. This could include platforms carrying unique weapons or have specially designed sensor suites.

I assume that the initial design and development of reusable software will be more costly and time intensive than the design and development for an individual platform. This is due to the identification and definition of requirements across platforms and the ability for software to adapt to different computing environments. Once the reusable software is developed, then it will result in lower design and development costs to integrate and leverage the same capability across several platforms than it would to redevelop the software for each individual platform. Future software modifications needed to add additional capability will also be less costly since all or portions of reusable software can be leveraged as a baseline for additional capability. Software maintenance and sustainment will be more cost effective due to the ability to make changes on one platform and deploy the reusable capability on many other platforms. My final assumption is that the computing environment will be standardized across the portfolio so that integration and adaptation modifications will be minimized. An example of an open computing environment designed for reuse in the aviation domain is FACE.

To calculate the costs of software reuse, I leveraged COPLIMO. COPLIMO models RCWR and the cost associated with development for reuse (RUSE), and then constrains to other cost drivers, Required Reliability (RELY) and Degree of Documentation (DOCU) (Boehm et al., 2004). The RUSE component will consider my assumption that design and development costs will be higher when the software is designed to meet the requirements of multiple platforms in a portfolio (Boehm et al. 2004).

30 b. Calculation of Benefits And Costs

In order to perform the BCA, I tuned the COPLIMO model based on experience. To tune the reuse model there are several inputs that must be provided. The COMPLIMO model accepts parameters quantifying the size of the software product-line, economies of scale factors, and effort scaling factors. Below is a list of software size parameters and my assumed values. A list of the economies of scale factors, effort scaling factors, and the assumed values can be found in the appendix: COPLIMO Scaling Factors.

c. Sizing Parameters

• Product size (PSIZE) in KSLOC (1000 Source Lines of Code): An estimate of the number of SLOC (Source Lines of Code) produced by the project (University of Southern California [USC], n.d.). I estimated approximately 17000 KSLOC or 17M SLOC based on the F-18 E/F software (Clark, McCurley, & Zubrow, 2015). The F-18 E/F is a fourth- generation fighter, and the software for future aviation platforms will only grow more complex. There will be some platforms that have less KSLOC and some platforms that have more KSLOC, but my assumptions are that currently the F-18 E/F represents the middle ground in both and software SLOC size.

• Product-specific fraction (PFRAC): This parameter represents the slice of the source code that is platform unique (USC, n.d.). Based on experience, I estimated this value to be approximately 40% of the KSLOC on each platform. For example, PFRAC represents capabilities for unique capabilities, sensors, and weapons systems.

• Adapted-software fraction (AFRAC): This parameter represents the slice of the of the product-line software adapted to meet requirements of each platform (USC, n.d.). Based on experience, I estimated this value to be approximately 15% of the KSLOC on each platform. For example, AFRAC represents capabilities with similar capability, but would need to

31 be configured for certain sensor suites or to meet requirements that are more specific.

• Reused-software fraction (RFRAC): This parameter represents the slice of the source code reused without modification (USC, n.d.). Based on experience, I estimated this value to be approximately 45% of the KSLOC on each platform. For example, RFRAC represents software providing capabilities that required by all platforms. These capabilities could include flight planning, navigation, guidance, fusion , , system health monitoring, etc.

• Annual change traffic (ACT): This parameter represents the fraction of a source code modified per year (USC, n.d.). I chose 10% per year, which I am assuming is a high percentage. Aviation software does not change in large percentages very often.

• Percent design modified (DM): This parameter represents the percentage of the software design adapted or modified to address new requirements or adapt to a new computing platform (USC, n.d.). Since the common design effort is accomplished on the first platform, I assumed 10%.

• Percent code modified (CM): This parameter represents the percentage of source code adapted or modified to address new requirements or adapt to a new computing platform (USC, n.d.). Since the common coding effort is accomplished on the first platform, I assumed 15%. This also matches the value chosen for AFRAC.

• Percent of integration required for adapted software (IM): This parameter represents the percentage of effort required to integrate adapted software into a new platform (USC, n.d.). I assumed this effort would be like the percentage of the adapted code, so I chose 15%.

32 • Assessment and Assimilation (AA): This parameter considers the effort required to evaluate the potential reusable source code and the effort required to assimilate the component’s code and documentation into the new application (USC, n.d.). I used 6% for this effort because if the design is performed correctly within the development phase of the first platform in the portfolio, then the reusable capabilities and their integration interfaces should be known.

• Software Understanding increment (SU): Measures the effort necessary to understand the source code (USC, n.d.). Since the example portfolio is made up of avionics software, which is highly structured and designed for understandability, I assumed a 10% value.

• Programmers’ relative unfamiliarity with the software (UNFM): This parameter measures the programmers’ familiarity with the software (USC, n.d.). 0.0 represents maximum familiarity and 1.0 represents maximum unfamiliarity (USC, n.d.). I chose 0.5, which represents some programmers with familiarity and some with no familiarity with the code.

All these inputs can be seen in the COPLIMO tool in the Figure 9 and the results of the COMPLIMO tool is shown in Figure 10.

33

Figure 9. COPLIMO Tool Interface with Example Inputs

34 Part I: Product Line Development Cost Estimation Summary:

# of Products 0 1 2 3 4 5 Effort (PM) No Reuse 0 18978 37956 56934 75912 94890 Product Line 0 24091 32903 41716 50529 59342 Product Line Savings 0 -5113 5052 15217 25382 35547 ROI 0 -1.00 0.99 2.98 4.96 6.95

Part II: Product Line Annualized Life Cycle Cost Estimation Summary: # of Products 0 1 2 3 4 5 AMSIZE-P 0 700.4 1400.8 2101.2 2801.6 3502.0 AMSIZE-R 0 262.7 262.7 262.7 262.7 262.7 AMSIZE-A 0 788.0 890.4 992.8 1095.3 1197.7 Total Equiv. KSLOC 0 1751.0 2553.8 3356.7 4159.5 4962.3 Effort (AM) (*2.94) 0 2398.4 3381.3 4336.3 5270.7 6188.9 5-year Life Cycle PM 0 11992.2 16906.6 21681.4 26353.5 30944.6 PM(N, 5)-R (+444) 0 36082.8 40997.1 45771.9 50444.0 55035.1 PM(N, 5)-NR 0 44717.6 89435.2 134152.9 178870.5 223588.1 Product Line Savings (PM) 0 8634.8 48438.1 88380.9 128426.5 168553.0

ROI 0 1.00 5.61 10.24 14.87 19.52 Devel. ROI 0 -1.00 0.99 2.98 4.96 6.95 Figure 10. COPLIMO Example Results

The output of the COPLIMO model is presented in Person Months or effort. The results based on the chosen inputs and scaling factors can be seen in Figure 10. In Figure 10, the focus should be on the product line savings in person months. To convert the person months to 2019 dollars, I assumed a $150,000 average annual burdened labor rate. The costs of a Person Months would be $12,500/month. The approximate savings across a five-platform portfolio is represented in Figure 11.

35 Savings (Person Months) All Platforms Platform 1 (Dev Platform 2 (Dev + Platform 3 (Dev + Platform 4 (Dev + Platform 5 (Dev Time (Year) (Savings in Person + Maint) Maint) Maint) Maint) + Maint) Months) 0 -1704.333333 -1704.333333 1 -1704.333333 1684 -20.33333333 2 -1704.333333 1684 5072.333333 5052 3 2749.56 1684 5072.333333 8460.666667 17966.56 4 2749.56 8677.22 5072.333333 8460.666667 11849 36808.78 5 2749.56 8677.22 14632.78 8460.666667 11849 46369.22667 6 2749.56 8677.22 14632.78 20608.9 11849 58517.46 7 2749.56 8677.22 14632.78 20608.9 26601.2 73269.66 8 8677.22 14632.78 20608.9 26601.2 70520.1 9 14632.78 20608.9 26601.2 61842.88 10 20608.9 26601.2 47210.1 11 26601.2 26601.2

Totals Savings in Person Months 8634.8 48438.1 88380.9 128426.5 168553 442433.3

Average Monthly Salary ($12,500.00) Savings in Person NPV Adjustment Time (Year) Months to 2019 $$'s (7% discount rate) 0 -$21,304,166.67 $ (21,304,166.67) 1 -$254,166.67 $ (237,538.94) 2 $63,150,000.00 $ 55,157,655.69 3 $224,582,000.00 $ 183,325,809.79 4 $460,109,750.00 $ 351,015,525.29 5 $579,615,333.33 $ 413,257,722.08 6 $731,468,250.00 $ 487,408,180.36 7 $915,870,750.00 $ 570,358,273.16 8 $881,501,250.00 $ 513,041,753.19 9 $773,036,000.00 $ 420,480,364.63 10 $590,126,250.00 $ 299,990,261.46 11 $332,515,000.00 $ 157,975,481.19

Total Savings in 2019 $$s $5,530,416,250.00 $ 3,430,469,321.23 Figure 11. Cost Savings Across Example Portfolio

The biggest challenge to estimating the cost of a portfolio is accurately representing the percentage of unique, modified, and reusable code. It will also be challenging to estimate the scaling factors. The last challenge is to accurately measure the overall KSLOC that will be needed to provide the capability.

d. Discount Rate

The discount rate estimation assumes that the start of the development phase of each of the platforms is staggered by one year. Each development phase will run three years. The maintenance period of each platform will be five years beginning immediately 36 after the development phase. This estimate does not consider any additional maintenance savings that might occur in year 6 and out.

For this estimation, platform 1 development will begin in 2019 and will use an average burdened salary of $150,000 per employee per year translating to $12,500 per person month. A discount rate of 7% will be applied to find the Net Present Value (NPV) of the savings in each year. The 7% rate was chosen due to the impacts that software reuse will have on the industrial base. If the DoD shifts to an OSA portfolio-centric management approach for software intensive systems, then some of the current development and maintenance efforts may be taken away from the industrial base and brought in-house.

e. Results

Based on my assumed tuning inputs to the COPLIMO tool and the 7% discount rate, there is an approximate savings of $3.4 billion across the portfolio during the combined development and maintenance phases. This represents a substantial savings to be realized in a software intensive portfolio of systems.

2. Portfolio Management Organization

Based on the available literature referenced in Chapter III, the use of a portfolio- centric management approach for software intensive systems is sporadic at best, but there are examples across commercial industry and the DoD where the model is used in practice. These industries include the automotive industry, smart phones and tablets, commercial and defense avionics, and one unique U.S. Navy organization.

The automotive manufacturers have leveraged the portfolio-centric management approach to design and develop automotive product-lines. These product-lines target different consumers, but the automobiles are produced from similar chassis, drivetrain, and engine components. This allows the automotive manufacturers to share production-lines and manufacturing tools. This consolidation reduces the size and training requirements of the workforce needed to manage multiple disparate product-lines. While the automotive product-lines have been centered around hardware, they have now established a consortium

37 to develop a software computing platform standard to support a product-line engineering approach.

The smartphone and tablet markets are dominated by Apple and Android devices. Apple and Google dominate the market due to their use of product-line architectures to drive down development costs and decrease the time it takes to get new products and capabilities to market. Both companies utilize a portfolio-centric management approach but leverage different business models and technical approaches.

Apple uses a closed architecture controlling the hardware and software computing platform, while allowing only applications to be developed and hosted on its environment. This model allows competition at the application layer, but stifles competition at the hardware and the software computing platform layers. Android however controls the software computing platform but allows customization of the human machine interface. Even though the software computing platform for Android is controlled, it is defined through and industry consortium from which an open, consensus-based standard is produced. Android allows for competition at the hardware and application layers, which allows for multiple phone manufacturers and application developers to innovate within these layers. The Android model is a great example of leveraging an open architecture portfolio-centric approach to drive competition and innovation.

In the avionics domain, manufacturers have created hardware and software product- lines within their respective organizations. These product-lines allow the companies to produce common hardware and software. The common hardware and software architectures can then be leveraged across a portfolio of commercial and defense rotary and fixed-wing platforms. These product-lines allow the manufacturers to focus on developing new and innovative capabilities while integrating reusable components to provide avionics capabilities meeting customer requirements. The product-lines allow the manufacturers to control program costs thus providing competitive pricing. The companies don’t have to reinvent the wheel for every new platform or customer that is requested. The shortfall to this approach is the hardware and software open architecture is only open to that unique manufacturer. Hardware and software from one avionics

38 manufacturer cannot be leveraged on another manufacturer’s systems without high integration costs.

One good representation of a portfolio-centric management approach within the DoD is NAVSEA. NAVSEA separates its platform and payload PEOs. NAVSEA’s payload PEO is PEO IWS. The Platform PEOs consist of PEO Carriers, PEO Littoral Combat Ship (LCS), PEO Submarines, and PEO Ships. NAVSEA’s portfolio-centric model centers around the management of hardware weapon replaceable assemblies as capabilities. While this is not necessarily the most efficient or cost-effective approach, it is better than a truly program centric model.

Based on my previous experience as an acquisition professional, there are other DoD SYSCOM’s that manage product-lines of weapon replaceable assemblies, but at a commodity PMO level. Examples of this model are the Navy’s PMA-209 Common Avionics PMO and the Army’s PM Aviation Systems PMO. The problem that these program offices run into is the fact that the platform PMOs do not trust the commodity PMOs to manage the programmatic C/S/P for capabilities that are required by the platforms. The commodity PMOs are also not given the appropriate authorities to force the platform PMs to adopt the commodity products.

a. Cross Cutting Organizational Concept

By drawing lessons from the literature, the DoD can develop an organizational structure that will support portfolio-centric management of its capabilities. Based on the organizational concepts and actual organizations discussed in Section III, the DoD needs to create cross cutting portfolio managers that have the authority to manage a common set of software intensive capabilities to be integrated into several platforms. This requires the portfolio manager to be adequately funded and be given C/S/P authority for the design, development, testing, training, and fielding of these capabilities. The platform and payload requirements need to be decoupled and flowed to either the portfolio manager or the platform manager. This takes a deliberate action by the requirements and resourcing offices to fight the urge to couple the platform and all of capabilities, which would hand over control to the platform manager for execution. Mission engineering needs to be conducted

39 to derive the set of common functions that are integrated into DoD weapon system platforms.

There are potentially two organizational constructs that could allow for a portfolio- centric management approach to successfully decrease costs and shorten fielding times. The first organizational approach creates portfolio program offices, which manage a portfolio of capabilities across mission area i.e., electronic warfare, navigation, communications, etc. These portfolio PMOs reside within the SYSCOM thus providing them with the technical authority for product line engineering. This technical authority coupled with a steady budget to manage the computing platform and the common capabilities provides the portfolio manager with the authority needed to cut across several disparate platform program offices. In this , the SYSCOM provides the mission engineering expertise to develop functional decompositions identifying common and unique capabilities across weapon system platforms. The functional decomposition are used by the requirements and resourcing offices and portfolio PMOs to properly scope the product-lines.

Platform PEOs manage a portfolio of platform types and subordinate PMOs develop platform unique capabilities. PEOs work closely with the SYSCOM to ensure that portfolio PMOs are meeting C/S/P for required capabilities and that proper communication and is conducted between platform and portfolio PMOs. Figure 12 describes a conceptual PMO portfolio management organization.

40

Figure 12. Portfolio PMO Concept

Another scenario involves creating a PEO for portfolio management that acts as PEO and the PM for portfolio management. PEO portfolio management has the authority for C/S/P for all programs falling within the PEO’s purview and is a peer rank to the platform PEOs. The PEO leverages human capital from the SYSCOM and performs the mission engineering with the support of the platform PEOs. PEO portfolio management also possess a chief that is responsible for technical decisions that impact the product line and capability portfolio. Figure 13 describes a conceptual PEO portfolio management organization.

41

Figure 13. Portfolio PEO Concept

The PEO portfolio manager has oversight for the computing platform architecture and standards, common core capabilities, common mission capabilities, architectural changes needed to accommodate platform unique capabilities, portfolio and product-line investment strategies, intellectual property strategy, portfolio resourcing, and all aspects of product-line engineering. The PEO portfolio manager crosscuts platform PEOs and works closely with all stakeholders to create a cost-effective technical solution meeting mission and fielding requirements.

B. HOLISTIC OPEN SYSTEM ARCHITECTURE APPROACH

To enable portfolio management, driving down costs and shortening fielding schedules for new capabilities, the technical approach should fundamentally leverage an OSA and product-line engineering techniques. This approach should include a functional decomposition, open consensus-based computing platform standards, and a cohesive intellectual property strategy.

42 1. Functional Decomposition

A functional decomposition is an important aspect of product line engineering. Capabilities must be decomposed to a granular level allowing components to execute as defined functions. These functions are derived through mission engineering and trace back to the mission objectives or tasks. The objectives define the high-level task that a set of functions will accomplish. Figure 14 describes a functional decomposition for the Track and ID tasks of an air warfare kill chain. These tasks are then broken down further to a set of components that perform a correlation, decision, track fusion, and track management functions. Now that the functions have been decomposed to a granular level they can be deployed to multiple systems.

Figure 14. Track and ID Functional Decomposition

To provide another relevant example of a functional decomposition, I will leverage the Future Vertical Lift (FVL) Request for Information (RFI) that was released in March of 2016. The RFI provides high level mission requirements for light and medium variants of DoD’s future rotary platform. The RFI describes to Capability Sets (CS1 and CS3) (Department of the Army [DA], 2016). CSs cover a broad mission set but attempt to 43 describe a family of systems with common capability requirements. According to the RFI, the “FVL CS 1 air vehicle is the smallest, most agile air vehicle in the FVL Family of Systems (FoS). The CS 1 air vehicle will conduct reconnaissance, light attack and light assault/lift operations in support of Army and Joint forces (DA, 2016 February).” “FVL CS 3 is intended to be a versatile medium lift air vehicle in the FVL Family of Systems (FOS). The CS 3 air vehicle will conduct Assault, Urban Security, Attack, Maritime Interdiction, Medical Evacuation, Humanitarian Assistance/Disaster Relief, Tactical Resupply, Direct Action, Non-combatant Evacuation Operation and Combat Search and Rescue operations in support of Army and Joint forces. (DA, 2016 March)”

Based on my knowledge of avionics systems, I list relevant requirements from the RFI, decompose requirements into more granular avionics and mission system components, and provide traceability of components back to the RFI requirements. I associate functional requirements to modular components and determine if components are common or platform unique. I also derive other potential core functions that provide infrastructure services to other components in the system. While this decomposition is based on documented requirements for FVL, it by no means is a complete solution and should only act as reference for how system requirements can be decomposed to a more granular level and allocated across a portfolio of software components and used across a portfolio of platforms.

a. FVL RFI Requirements

Table 1 provides a decomposition of the reusable components, a description of the components, and the requirements that trace to that requirement. The requirements in Table 1 are based on CSs in the Army’s FVL RFI released in 2016.

44 Table 1. Functionally Decomposed Components

Components Component CS1 and CS3 Common Platform Unique Derived Description Requirements Fulfilleda Requirements Requirements

Message Parser Parsing services for 5.1.10. Capable of rapid 5.6.2. Net-centric several types of communication reconfiguration connectivity to data-link messages enabling Battle Command on the enhance enroute (e.g., Link-16, Move; data receipt and transmit medical care capability Variable Message capability across all applicable (telemedicine) for Format, Common methods onboard critical care Data Link, etc.) and waveforms on enduring, as teams or paramedics defined in their well as, ad hoc networks. respective Interface Control Documents. 5.1.11. Capability to fuse information from off-board and on- board sensors, capable of providing translation across methods and waveforms to ensure inclusion of all desired information into common operating picture.

5.1.12. Capability to dynamically communicate with other service and joint assets, potentially re-task Joint Unmanned Aircraft Systems

5.1.13. Networked Situational Awareness of threat radar, and other detection systems connected to navigation system to adjust routes dynamically and call on external assets for jamming, as necessary.

5.2.3. Capability to fuse information from off-board and on- board systems. Track Manager Track management 5.1.11. Capability to fuse for a variety of information from off-board and on- different tracks board sensors, capable of providing (e.g., Link-16, Blue translation across methods and Force Tracker, waveforms to ensure inclusion of Automatic all desired information into Identification common operating picture. System, etc.) 5.2.1. Capability to detect, identify and affiliate friendly and enemy forces throughout the battle space

5.2.3. Capability to fuse information from off-board and on- board systems. Integrated Provides 5.1.13. Networked Situational Aircraft management of Awareness of threat radar, and Survivability ASE sensor suite other detection systems connected Equipment to navigation system to adjust (IASE) Manager routes dynamically and call on external assets for jamming, as necessary.

5.2.4. Capability to dynamically re- task sensors.

5.2.6. Detect, identify, and destroy air threats.

45 Components Component CS1 and CS3 Common Platform Unique Derived Description Requirements Fulfilleda Requirements Requirements

External Command and 5.1.12. Capability to dynamically Unmanned control functions communicate with other service Aircraft System for external UASs and joint assets, potentially re-task Controller Joint Unmanned Aircraft Systems

5.1.13. Networked Situational Awareness (SA) of threat radar, and other detection systems connected to navigation system to adjust routes dynamically and call on external assets for jamming, as necessary.

5.1.15.Man-Unmanned Teaming Level 4 Control of UAS (Level 5 Control for UAS Group 2 and smaller (except for Medical Evacuation) Unmanned system interoperability being able to control multiple vehicles and capable of optionally piloted/optionally manned

5.2.1. Capability to detect, identify and affiliate friendly and enemy forces throughout the battle space

5.3.2. Precision fires and engagement with ground elements, UAS, and wing man, capable of non-lethal effects for mobility “kills.”

Collision Inflight collision 5.1.7. Fully mission capable in all Avoidance detection and weather (except the most severe System (CAS) avoidance weather e.g., severe thunderstorms, turbulence, icing, hurricane force winds), night and degraded visual environment, moderate icing, Instrument Meteorological Conditions and Instrument Flight Rules

5.1.13. Networked Situational Awareness of threat radar, and other detection systems connected to navigation system to adjust routes dynamically and call on external assets for jamming, as necessary.

46 Components Component CS1 and CS3 Common Platform Unique Derived Description Requirements Fulfilleda Requirements Requirements

Terrain Terrain awareness 5.1.7. Fully mission capable in all Awareness alerting weather (except the most severe Warning System weather e.g., severe thunderstorms, (TAWS) turbulence, icing, hurricane force winds), night and degraded visual environment, moderate icing, Instrument Meteorological Conditions and Instrument Flight Rules.

5.1.14. Capable of four-axis autopilot system with automated 3- dimensional approach path system capable of obstacle avoidance in complex terrain.

Terrain Follower sensor fusion and 5.1.7. Fully mission capable in all guidance for close weather (except the most severe to terrain flight weather e.g., severe thunderstorms, operations turbulence, icing, hurricane force winds), night and degraded visual environment, moderate icing, Instrument Meteorological Conditions and Instrument Flight Rules.

5.1.14. Capable of four-axis autopilot system with automated 3- dimensional approach path system capable of obstacle avoidance in complex terrain. Electronic Manages passive 5.1.17. Air and ground target Warfare (EW) and active EW identification sensors. Manager functions 5.2.4. Capability to dynamically re- task sensors.

5.2.6. Detect, identify, and destroy air threats.

5.3.3. Capability to operate in a GPS denied or contested environment.

47 Components Component CS1 and CS3 Common Platform Unique Derived Description Requirements Fulfilleda Requirements Requirements

Weapons Provides 5.2.5 Ability to direct/employ Manager management and precision/non-precision area fire, communications to lethal and non-lethal munitions to Net Enabled fix, disengage or destroy a full Weapons spectrum of targets

5.2.7. Common architecture with Joint/Army fire support systems.

5.2.8. Capability to employ fires to fix, disengage, or destroy targets.

5.3.2. Precision fires and cooperative engagement with ground elements, UAS, and wing man, capable of non-lethal effects for mobility “kills.”

6.1.1. Aircraft must be able to deliver precision munitions (Semi Active Laser, Millimeter Wave, Infrared, GPS/Internal Navigation System, etc.) rangefinder/designator capability (for ranging and precision engagements). Platform will require Category 3 Target Location Error capability.

6.1.2. Aircraft must provide ability to engage targets off-axis from a range of 10 meters (m) to 3000+m rapidly for self-protection/offensive operations. Turreted / rapidly slewing for 360-degree protection

6.1.3. Provide capability for pod- mounting of specialty-type weapons/munitions (i.e., directed energy).

6.2.1. Air vehicle must allow for crew selectable precision munitions.

6.3.1. Platform shall support Universal Armament Interface (UAI) two-way on-board communication with “smart” munitions, and those munitions capable of receiving pre-launch guidance, fusing, selectable effects, flight profile or launch mode selection or other data.

6.3.2.2. Selectable warhead fusing/timing

6.3.2.4. Inventory/Weapon type recognition (e.g., variants of same munition)

6.3.3. Need to specify a provision for “wireless” communications

48 Components Component CS1 and CS3 Common Platform Unique Derived Description Requirements Fulfilleda Requirements Requirements

with munitions - e.g., induction, near-field radio frequency, etc.

Battle Damage Info and 5.1.11. Capability to fuse 5.6.2. Net-centric Assessment management of information from off-board and on- connectivity to (BDA) Manager battle damage of board sensors, capable of providing enhance enroute executed targets translation across methods and medical care capability waveforms to ensure inclusion of (telemedicine) for all desired information into onboard critical care common operating picture. teams or paramedics

Airspace Coordination, 5.1.13. Networked Situational Controller integration, and Awareness of threat radar, and regulation of the other detection systems connected airspace and to navigation system to adjust surveillance routes dynamically and call on external assets for jamming, as necessary.

Military Flight Flight management 5.1.13. Networked Situational Management capabilities for Awareness of threat radar, and patterns other detection systems connected and way point types to navigation system to adjust to include search routes dynamically and call on and rescue, in-air external assets for jamming, as refueling, etc. necessary.

5.3.3. Capability to operate in a GPS denied or contested environment.

6.3.2.3. Selectable flight profile or flight path

49 Components Component CS1 and CS3 Common Platform Unique Derived Description Requirements Fulfilleda Requirements Requirements

Civil Flight Flight management 6.3.2.3. Selectable flight profile or 1. Capable of Management capabilities for civil flight path operating in patterns and way operating in civilian point types. A key airspace component to Communication, 2. Capable of Navigation, conducting GPS Surveillance/Air approaches at civil Traffic airports Management

Flight Plan Merges the civil and 5.1.13. Networked Situational 1. Capable of Merger military flight plans Awareness of threat radar, and merging civil and into a single flight other detection systems connected military flight plans plan to navigation system to adjust routes dynamically and call on external assets for jamming, as necessary.

6.3.2.3. Selectable flight profile or flight path Navigation Hosts and provides 5.1.13. Networked Situational 1. Capable of Database read access to the Awareness of threat radar, and operating in civil navigation other detection systems connected operating in civilian database to navigation system to adjust airspace routes dynamically and call on external assets for jamming, as 2. Capable of necessary. conducting GPS approaches at civil 6.3.2.3. Selectable flight profile or airports flight path

50 Components Component CS1 and CS3 Common Platform Unique Derived Description Requirements Fulfilleda Requirements Requirements

Guidance Provides guidance 5.1.7. Fully mission capable in all calculations based weather (except the most severe upon civil and weather e.g., severe thunderstorms, military flight plan turbulence, icing, hurricane force data winds), night and degraded visual environment, moderate icing, Instrument Meteorological Conditions and Instrument Flight Rules

5.3.3. Capability to operate in a GPS denied or contested environment.

5.3.6. Precision 3-dimensional navigation and timing with precise position approach hold, automated low speed control for obstacle avoidance and coupled hover and position hold +/- 1 foot.

6.3.2.3. Selectable flight profile or flight path

51 Components Component CS1 and CS3 Common Platform Unique Derived Description Requirements Fulfilleda Requirements Requirements

Route Re- real-time route re- 5.1.7. Fully mission capable in all planner planning based on weather (except the most severe the current flight weather e.g., severe thunderstorms, plan, mission turbulence, icing, hurricane force assignments, and winds), night and degraded visual threats environment, moderate icing, Instrument Meteorological Conditions and Instrument Flight Rules

5.1.13. Networked Situational Awareness of threat radar, and other detection systems connected to navigation system to adjust routes dynamically and call on external assets for jamming, as necessary.

52 Components Component CS1 and CS3 Common Platform Unique Derived Description Requirements Fulfilleda Requirements Requirements

Pilot Control Autonomously 5.1.15. Man-Unmanned Teaming manages control of Level 4 Control of UAS (Level 5 the assigned air Control for UAS Group 2 and vehicle at any given smaller (except for Medical time Evacuation) Unmanned system interoperability being able to control multiple vehicles and capable of optionally piloted/optionally manned

5.3.6. Precision 3-dimensional navigation and timing with precise position approach hold, automated low speed control for obstacle avoidance and coupled hover and position hold +/- 1 foot.

5.4.1. Avionics/navigation systems capable of precisely locating and the ability to maintain distance, time, and heading as it closes with a moving maritime target (e.g., Auto Approach to a ship deck and coupled hover hold/precision position hold over water).

53 Components Component CS1 and CS3 Common Platform Unique Derived Description Requirements Fulfilleda Requirements Requirements

Data Fusion Provides a service 5.1.11. Capability to fuse for integrating data information from off-board and on- from a variety of board sensors, capable of providing sources into a translation across methods and common situational waveforms to ensure inclusion of awareness view in all desired information into real-time base on common operating picture. external sensors, internal sensors, and 5.1.17. Air and ground target net centric data identification sensors

5.2.1. Capability to detect, identify and affiliate friendly and enemy forces throughout the battle space

5.2.3. Capability to fuse information from off-board and on- board systems.

5.2.6. Detect, identify, and destroy air threats.

54 Components Component CS1 and CS3 Common Platform Unique Derived Description Requirements Fulfilleda Requirements Requirements

Target of Interest Management and 5.1.11. Capability to fuse (TOI) Manager info regarding information from off-board and on- potential targets of board sensors, capable of providing interest to include translation across methods and detection, waveforms to ensure inclusion of identification, all desired information into prioritization, and common operating picture. designation 5.1.17. Air and ground target identification sensors

5.1.18. Capability to dynamically re-task aircraft sensors with applicable helmet cueing and hands on collective and stick - type system.

5.2.1. Capability to detect, identify and affiliate friendly and enemy forces throughout the battle space

5.2.2. Capability to dynamically re- task Reconnaissance & Security assets

5.2.4. Capability to dynamically re- task sensors.

5.3.2. Precision fires and cooperative engagement with ground elements, UAS, and wing man, capable of non-lethal effects for mobility “kills.”

Sensor Cue Allows external 5.1.18. Capability to dynamically Manager cueing of FVL re-task aircraft sensors with sensors applicable helmet cueing

5.2.4. Capability to dynamically re- task sensors.

Radar Warning Provides radar 5.2.6. Detect, identify, and destroy warning capabilities air threats.

55 Components Component CS1 and CS3 Common Platform Unique Derived Description Requirements Fulfilleda Requirements Requirements

Command and Command and 5.1.8. Capability to operate in a 5.6.2. Net-centric 1. Capable of using Control (C2) control capabilities Global Positioning System denied connectivity to a variety of to include battle or contested environment. enhance enroute communication space management medical care capability devices to conduct and common 5.1.10. Capable of rapid (telemedicine) for C2 operating picture communication reconfiguration onboard critical care enabling Battle Command on the teams or paramedics 2. Manage a variety Move; data receipt and transmit of communication capability across all applicable devices methods and waveforms on enduring, as well as, ad hoc networks.

5.1.11. Capability to fuse information from off-board and on- board sensors, capable of providing translation across methods and waveforms to ensure inclusion of all desired information into common operating picture.

5.1.12. Capability to dynamically communicate with other service and joint assets, potentially re-task Joint Unmanned Aircraft Systems.

5.1.15.Man-Unmanned Teaming Level 4 Control of UAS (Level 5 Control for UAS Group 2 and smaller (except for Medical Evacuation) Unmanned system interoperability being able to control multiple vehicles and capable of optionally piloted/optionally manned

5.2.1. Capability to detect, identify and affiliate friendly and enemy forces throughout the battle space

5.2.2. Capability to dynamically re- task Reconnaissance & Security assets

5.3.2. Precision fires and cooperative engagement with ground elements, UAS, and wing man, capable of non-lethal effects for mobility “kills.”

56 Components Component CS1 and CS3 Common Platform Unique Derived Description Requirements Fulfilleda Requirements Requirements

Strike Manager Management of the 5.1.11. Capability to fuse strike package information from off-board and on- which includes the board sensors, capable of providing TOI, strike position, translation across methods and and the weapons waveforms to ensure inclusion of available to carry all desired information into out the strike common operating picture.

5.2.2. Capability to dynamically re- task Reconnaissance & Security assets

5.2.5. Ability to direct/employ precision/non-precision area fire, lethal and non-lethal munitions to fix, disengage or destroy a full spectrum of targets

5.2.7. Common architecture with Joint/Army fire support systems.

5.2.8. Capability to employ fires to fix, disengage, or destroy targets.

5.3.2. Precision fires and cooperative engagement with ground elements, UAS, and wing man, capable of non-lethal effects for mobility “kills.”

6.1.1. Aircraft must be able to deliver precision munitions (Semi Active Laser, Millimeter Wave, Infrared, GPS/Internal Navigation System, etc.) rangefinder/designator capability (for ranging and precision engagements). Platform will require Category 3 Target Location Error capability.

57 Components Component CS1 and CS3 Common Platform Unique Derived Description Requirements Fulfilleda Requirements Requirements

Auto Land Guidance required 5.1.14. Capable of four-axis for automated ship autopilot system with automated 3- and land-based dimensional approach path system approaches capable of obstacle avoidance in complex terrain.

5.3.6. Precision 3-dimensional navigation and timing with precise position approach hold, automated low speed control for obstacle avoidance and coupled hover and position hold +/- 1 foot.

5.4.1. Avionics/navigation systems capable of precisely locating and the ability to maintain distance, time, and heading as it closes with a moving maritime target (e.g., Auto Approach to a ship deck and coupled hover hold/precision position hold over water).

Position Service Provides current 5.3.3. Capability to operate in a Capability to location to GPS denied or contested provided current distributed environment. position to other components within components the platform

Time Service Provides current 5.3.3. Capability to operate in a Capability to time to distributed GPS denied or contested provided system components within environment. time based on the platform multiple time sources to other components Health Monitor Provides health 6.3.2.1. Continuous Built in Test and Fault monitoring and and/or health monitoring Manager management (HMFM) functionality

Sensor Imagery Provides sensor 6.3.2.5. Sensor pass-thru (e.g. IR and Video imagery and video warhead sensor image shown on to the pilot or battle Multi-Functional Display for management station targeting)

aSource: DA (2016).

58 2. Reference Architecture

The FVL RFI (2016) requires the FACE Standard be used for the open, consensus based OSA. The FVL RFI (2016) requires that the system “Provide an approach to implementing a Future Airborne Capability Environment (FACE) standard compliant Mission Systems Architecture (MSA), maintenance, sustainment, etc., and the strategies associated with them. MSA that could be common between FVL CSs.”

Now that the functions have been decomposed to reusable components, they can be conceptually deployed into the FACE architecture, specifically to the Portable Component Segment. Before the reusable components can be deployed to a reference FACE computing platform, the Platform Specific Services and the I/O Services components must be identified. To identify these components, I will make generic assumptions based on the requirements in the FVL RFI. The platform specific service components are described in Table 2 and the I/O services in Table 3.

Table 2. Platform-Specific Services

Platform Specific Service Description Joint Tactical Radio System (JTRS) Provides command control of the JTRS radio and acts as an abstraction between the reusable components and the radio which is based on the proprietary radio data interface

Embedded Global Positioning System Inertial (EGI) Provides command control of the EGI and acts as an abstraction between the reusable components and the radio which is based on the proprietary EGI data interface

Automatic Identification System (AIS) Provides command control of the AIS and acts as an abstraction between the reusable components and the radio which is based on the proprietary AIS data interface

Infrared (IR) Counter Measures (IRCM) Provides command control of the IRCM and acts as an abstraction between the reusable components and the radio which is based on the proprietary ICRM data interface

Hostile Fire Sensor Provides command control of the hostile fire sensor and acts as an abstraction between the reusable components and the radio which is based on the proprietary hostile fire sensor data interface DVE Sensor Provides command control of the DVE and acts as an abstraction between the reusable components and the radio which is based on the proprietary DVE data interface

59 Platform Specific Service Description Automatic Dependent Surveillance-Broadcast (ADS-B) Provides command control of the ADS-B and acts as an abstraction Sensor between the reusable components and the radio which is based on the proprietary ADS-B data interface

UAI Weapon Interface Module Provides command control of non UAI conformant weapons and acts as an abstraction between the reusable components and the radio which is based on the proprietary non UAI conformant weapons data interface

Data Loader Provides command control of the data loader and acts as an abstraction between the reusable components and the radio which is based on the proprietary data loader data interface

Weather Radar Provides command control of the weather and acts as an abstraction between the reusable components and the radio which is based on the proprietary weather radar data interface

Tactical Air Navigation (TACAN) Provides command control of the TACAN and acts as an abstraction between the reusable components and the radio which is based on the proprietary TACAN data interface

Radar Altimeter (RADALT) Provides command control of the RADALT and acts as an abstraction between the reusable components and the radio which is based on the proprietary RADALT data interface

Data Recorder Provides command control of the data recorder and acts as an abstraction between the reusable components and the radio which is based on the proprietary data recorder data interface

Electro-optical/Infra-red (EO/IR) Provides command control of the EO/IR and acts as an abstraction between the reusable components and the radio which is based on the proprietary EO/IR data interface Synthetic Aperture Radar (SAR) Provides command control of the SAR and acts as an abstraction between the reusable components and the radio which is based on the proprietary SAR data interface

EW Suite Provides command control of the EW suite and acts as an abstraction between the reusable components and the radio which is based on the proprietary EW suite data interface

Integrated Health Monitoring System (IHMS) Provides command control of the IHMS and acts as an abstraction between the reusable components and the radio which is based on the proprietary IHMS data interface Full Motion Video (FMV) Provides streaming media services to include FMV and streaming audio

Configuration Manager Provides platform specific configuration data to the reusable software components

60 Platform Specific Service Description Graphics Server Provides display services for multi-function displays and control display units to reusable software components

Table 3. I/O Services Components

I/O Service Description MIL-STD-1553 Abstracts the platform unique MIL-1553-STD device driver from the rest of the reusable software components and provides a normalized interface for the components to communicate with the MIL-1553-STD data bus

ARINC-429 Abstracts the platform unique ARINC-429 device driver from the rest of the reusable software components and provides a normalized interface for the components to communicate with the ARINC-429 data bus Discrete Abstracts the platform unique discrete device driver from the rest of the reusable software components and provides a normalized interface for the components to communicate with the discrete data

Further refinement of the decomposition needs to be conducted to describe the data and characterize behavior of the interfaces for each component. Now that the reusable and platform unique components are documented, the components are distributed to the architectural segments defined in the FACE Standard depicted in Figure 15.

61 Operating System Segment Radar Warning Nav DB Track Manager C2 Portable Components Segment Auto Land Guidance Route Re-Plan EW Manager CAS Message Parser Strike Manager Mil FM Sensor Cue Manager BDA Manager TAWS IASE Manager TOI Manager FP Merge Civ FM Weapons Terrain Follower External UAS Controller Data Fusion Pilot Controller Sensor Imagery Airspace Controller Position Time TS FACE defined interface Transport Services Segment

Routing

ARINC 653 IP Communication

TS FACE defined interface Encapsulated Device Platform-Specific Services Segment Platform-Specific Common Services “Business Logic” JTRS Weapons TACAN Platform-Specific FMV HMFM Configuration Device Services Hostile Fire Sensor EO/IR Data Loader ADS-B IRCM EGI IHMS DVE AIS Data Recorder SAR Platform-SpecificGraphics Services EW Suite Radar Alt Weather Radar Graphics Server

IO FACE defined interface I/O Services Segment

Discretes MIL-STD-1553 ARINC 429 Adapter to allow vendor supplied drivers to support the abstracted FACE Device Driver Device Driver Device Driver interface

Interface Hardware (e.g. MIL-STD-1553, Ethernet)

Hostile Data Weapons TACAN ADS-B EO/IR Fire IRCM Loader IHMS Sensor

Data Radar Weather DVE AIS SAR EW Suite EGI JTRS Recorder Altimeter Radar

Figure 15. Functional Decomposition overlaid on FACE architecture. Adapted from The Open Group (2017).

These functions are then conceptually distributed across processing hardware. In my example, I chose to depict the conceptual functional distribution on a computing platform consisting of a FACE conformant real time OS segment and interface. The OS allows for temporal partitioning of resources so that each component will be afforded its own processing time slice and memory location. The conceptual distribution of components across processing hardware is an example. A performance analysis needs to be performed to determine the appropriate component distribution into a real-world system. In the notional implementation shown below the architecture is logically deployed onto six processors which include a navigation and guidance processor (Figure 16), terrain avoidance processor (Figure 17), system management processor (Figure 18), command and

62 control processor (Figure 19), intelligence surveillance and Reconnaissance (ISR) and EW Processor (Figure 20), and a weapons processor (Figure 21).

FP Route Auto M IL FM C IV FM NAV DB Guidance Merge Re-Plan Land HMFM Graphics

TS TS TS TS TS TS TS TS I/O TS I/O Interface Interface Interface Interface Interface Interface Interface Interface Interface Interface Interface Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry

OS I/F OS I/F OS I/F OS I/F OS I/F OS I/F OS I/F OS I/F OS I/F

OS

Figure 16. Navigation and Guidance Processor

Terrain CAS TAWS MIL-STD-1553 I/O Follower ARINC 429 I/O Radar Service HMFM EG I TACAN Service Altimeter

TS TS TS TS TS TS TS I/O I/O I/O I/O I/O I/O Interface Interface Interface Interface Interface Interface Interface Interface Interface Interface Interface Interface Interface 1553 Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry ARINC Lib ra ry Bus Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry 429 Driver Driver

OS I/F OS I/F OS I/F OS I/F OS I/F OS I/F OS I/F OS I/F OS I/F

OS

Figure 17. Terrain Avoidance Processor

63 Time Position Pilot Service Service Manager Discrete I/O Config Data HMFM RF IHMSAntenna Data Loader Service Manager Recorder

TS TS TS TS TS TS TS TS I/O I/O I/O I/O I/O I/O Interface Interface Interface Interface Interface Interface Interface Interface Interface Interface Interface Interface Interface Interface Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry Driver Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry

OS I/F OS I/F OS I/F OS I/F OS I/F OS I/F OS I/F OS I/F OS I/F

OS

Figure 18. System Management Processor

Sensor TOI Radar Cue C2 Manager Warning Manager HMFM SAR EO/IR WeatRF herAntenna Radar DVE

TS TS TS TS TS TS TS TS TS I/O I/O I/O I/O I/O Interface Interface Interface Interface Interface Interface Interface Interface Interface Interface Interface Interface Interface Interface Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry

OS I/F OS I/F OS I/F OS I/F OS I/F OS I/F OS I/F OS I/F OS I/F

OS

Figure 19. C2 Processor

64 EW BDA Sensor IASE Airspace Manager Manager Imagery Manager Controller Hostile Fire HMFM FMV RF Antenna Sensor IRCM

I/O TS TS TS TS TS TS I/O TS I/O TS I/O TS Interface Interface Interface Interface Interface Interface Interface Interface Interface Interface Interface Interface Interface Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry

OS I/F OS I/F OS I/F OS I/F OS I/F OS I/F OS I/F OS I/F OS I/F

OS

Figure 20. ISR and EW Processor

St rike Weapons Manager Manager HMFM Weapons

I/O TS TS TS I/O TS Interface Interface Interface Interface Interface Interface Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry Lib ra ry

OS I/F OS I/F OS I/F OS I/F

OS

Figure 21. Weapons Processor

Once the components are developed and deployed on one system, they can then be put in a portfolio product catalog for use on other platforms. Also, due to the modularity of the components and the fact that they are deployed onto a standardized computing platform, these components can be modified, replaced, or upgraded with minimal impact to other components within the systems. would still need to be

65 conducted, but in theory there will be less impact than if the software is designed and developed as one large monolithic program.

3. Data Rights Strategy

Once reusable components are defined through functional decomposition, it is time to begin to document the data rights strategy. A data rights strategy considers the rate of change that a component incurs including modification or upgrades over the life cycle. The strategy also looks at how complex the function is, how many sources for the component exist, and the criticality for the system. The last consideration is which organization is ultimately responsible for technically maintaining the component.

Based on the software life-cycle consideration the organization needs to determine if an unlimited-use license, shared-unlimited-use license such as government purpose rights, or some type of limited use license model is the right model for each software component. If an organization is viewing a software component as a black box, then a limited use license, like a lease, might be the most cost-effective option. This allows for the software component to be replaced by another application meeting the same requirements if necessary. If the organization plans to use, upgrade, and maintain another organization’s software component, a shared-unlimited-use license is the correct approach. If an organization plans to share the software component and the associated artifacts with multiple organizations with no financial obligations, then an unlimited-use license should be considered.

Several stakeholders in the organization should be involved in the determination of the strategy. These stakeholders include the portfolio manager, program and product managers, , lawyers, contracting, logistics, and financial management personnel. This mix of programmatic and technical stakeholders will determine the most effective data rights strategy to meet the goals and objectives of the organization.

66 V. CONCLUSION

A. RECOMMENDATION

Based on my qualitative research, I have concluded that DoD can achieve acquisition efficiencies by shifting from program-centric management to portfolio-centric management for software intensive weapons systems. This fundamental shift in management approach will result in decreased life-cycle costs and increased speed to field capabilities.

I recommend that DoD pick a set of program and products as a pilot portfolio. To validate that the pilot portfolio leads to decreased life-cycle cost and increased speed of fielding capabilities, a BCA should be conducted using a properly tuned COPLIMO model. If the BCA validates the assumptions, then one of the two organizational realignments discussed in Chapter IV, should be implemented. Once the portfolio is established the requirements and resourcing office should invest in the initial development of a computing platform and reusable software components using a holistic open architecture approach.

B. FUTURE RESEARCH

There are several aspects of a portfolio-centric management approach that require further research. First additional research should be conducted to better tune the COPLIMO input parameters and scaling factors in order to perform a sensitivity analysis and validate the CBA assumptions and results. The scale factors offered by the current version of the COPLIMO tool should also be expanded to further refine the accuracy of the model. Second, the organizational model can be refined by establishing a better understanding of the resourcing, authorities, policies and procedures leveraged by organizations that have successfully move from a program-centric to portfolio-centric management model. Lastly, the example holistic OSA approach was centered around an aviation centric computing platform and set of reusable components. An effort should be made to analyze the open, consensus-based standards that are available in other weapons system domains.

67 THIS PAGE INTENTIONALLY LEFT BLANK

68 APPENDIX. EXAMPLE COPLIMO SCALING FACTORS

Economies of Scale Factors:

• PREC (precedentedness): Nom/Somewhat unprecedented

• FLEX (development flexibility): Low/Occasional relaxation

• RESL (architecture/risk resolution): Hi/Generally (75%)

• TEAM (team cohesion): Hi/Largely cooperative

• PMAT (process maturity): Nom/CMMI Level 3

Effort Scaling Factors:

• RELY (required software reliability): VH/Risk to human life

• DATA (database size): Nom/Moderate

• CPLX (product complexity): VH/Very Difficult

• RUSE (developed for reusability): VH/Across Product Line

• DOCU (documentation meets life-cycle requirements): Nom/Some life cycle needs uncovered

• TIME (execution time constraint): Hi/70% of the available execution time

• STOR (main storage constraint): Hi/70% of the available storage

• PVOL (platform volatility): Low/Major changes every 12 months

• ACAP (analyst capability): Hi/75th percentile

• PCAP (programmer capability): Hi/75th percentile

• PCON (personnel continuity): Hi/6% per year

69 • APEX (analyst experience): Hi/3 years

• PEX (programmer experience): Hi/3 years

• LANG (language experience): Hi/3 years

• TOOL (use of software tools): VH/Strong; moderately integrated

• SITE (multisite development): VH/Interactive multimedia

• SCED (required development schedule): Hi/130% of Nom

70 LIST OF REFERENCES

Department of the Army (2016). Future Vertical Lift (FVL) capability set #1 request for information. Retrieved from https://www.fbo.gov/index?s=opportunity&mode= form&tab=core&id=ac1bd318f3111aa70cfcace0248ee453

Department of the Army (2016). Future Vertical Lift (FVL) capability set #3 request for information. Retrieved from https://www.fbo.gov/index?s=opportunity&mode= form&tab=core&id=ac1bd318f3111aa70cfcace0248ee453

AUTOSAR (n.d.). An introduction to AUTOSAR. Retrieved from https://automotivetechis.files.wordpress.com/2012/05/lesson19_autosar.pdf

Boehm B., Brown A. W., Madachy R., & Yang, Y. (2004). A software product line life cycle cost estimation model (Report No. USCCSE2004-517). Retrieved from: https://sunset.usc.edu/TECHRPTS/2004/usccse2004-517/usccse2004-517.

Clark B., McCurley J., & Zubrow D. (2015). DoD software factbook. Retrieved from: https://resources.sei.cmu.edu/asset_files/WhitePaper/2015_019_001_453264.pdf

Clements, Paul, & Bergey, John (2005). The U.S. Army’s Common Avionics Architecture System (CAAS) product line: a case study (Report No. CMU/SEI-2005-TR-019). Retrieved from https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=7707

Department of Defense (2013). DoD open systems architecture contract guidebook for program managers. Washington, DC. Retrieved from https://www.dau.mil/cop/pm/_layouts/15/WopiFrame.aspx?sourcedoc=/cop/pm/D AU%20Sponsored%20Documents/DoD%20Open%20System%20Architecture% 20(OSA)%20Contract%20Guidebook%20for%20Program%20Managers- version%201.1-%20June%20%202013.pdf&action=default

Department of Defense (2014). Understanding and leveraging data rights in DoD acquisitions [Fact sheet]. Retrieved from https://www.dau.mil/cop/mosa/DAU% 20Sponsored%20Documents/Data%20Rights%20Focus%20Sheet%20final.pdf

Emery, K. (2010). Surface navy combat strategy. Wayne E. Meyer Institute of Systems Engineering. Retrieved from https://calhoun.nps.edu/bitstream/handle/10945/53751/Surface_Navy_Combat_Sy stems_Engineering_Strategy.pdf?sequence=1&isAllowed=y

Federal Aviation Administration (2018). Fly the aircraft first [Fact sheet]. Retrieved from https://www.faa.gov/news/safety_briefing/2018/media/SE_Topic_18-07.pdf

71 Faust, D., & Verhoef C. (2003). Software product line migration and deployment, Software-Practice and Experience, 33, 933–955. https://onlinelibrary.wiley.com/doi/pdf/10.1002/spe.530

Guertin, Nickolas, Sweeney, Robert, & Schmidt, Douglas C. (2015, May 13). Using open architecture to revolutionize capability acquisition. Presented at the Acquisition Research Symposium, Naval Postgraduate School, Monterey, CA.

Guertin, Nickolas, & Clements, Paul (2010). Comparing acquisition strategies: open architecture versus product lines. Proceedings of the Seventh Annual Acquisition Research Symposium, Naval Postgraduate School, Monterey, CA. Retrieved from https://calhoun.nps.edu/handle/10945/33466

Günter, Böckle, Clements, Paul, McGregor, John D., Muthing, Dirk, & Schmid, Klaus (2004, August). Calculating ROI for software product lines. IEEE Software, Volume 21 (3), pages 23–31, retrieved from https://ieeexplore.ieee.org/document/1293069

Howington, Jeffery A. (2016,). Advantages of certified FACE conformant software for industry (and their customers). Retrieved from https://www.defensedaily.com/wp-content/uploads/2016/11/Jeffry-Howington- Princippal-Business-Development-Manager-Rockwell-Collins-Government- Systems.pdf

The Open Group (2017). FACE technical Standard (Edition No. 3.0). Retrieved from https://publications.opengroup.org/c17c

Project Management Institute (2004). A guide to the project management body of knowledge (PMBOK guide). Newtown Square, Pa: Project Management Institute.

Ross, D. W. & Shaltry, P. E. (2005). The new PMI Program management standard and Portfolio management standard—impact on the profession—a preview. Paper presented at PMI® Global Congress 2005—North America, Toronto, Ontario, Canada. Newtown Square, PA: Project Management Institute. Retrieved from https://www.pmi.org/learning/library/new-pmi-program-project-management- standard-7441

Ross, D. W. & Shaltry, P. E. (2006). The new PMI standard for portfolio management. Paper presented at PMI® Global Congress 2006—EMEA, Madrid, Spain. Newtown Square, PA: Project Management Institute. Retrieved from https://www.pmi.org/learning/library/pmi-standard-portfolio-management-8216

Schach, Stephen R. (2007). Object oriented , Boston, MA: McGraw-Hill Education.

72 Serbu J. (2018, June 29). To streamline acquisitions, 809 panel presses DoD to adopt portfolio management. Retrieved from: https://federalnewsradio.com/defense- news/2018/06/to-streamline-acquisitions-809-panel-presses-DoD-to-adopt- porfolio-management/

Sweeney, Robert (2013). What is FACE [Working paper]. Patuxent River, MD: Naval Air Systems Command, Working Paper v7

Sweeney, Robert (2018). The cost benefits of software reuse [Working Paper]. Monterey, CA: Naval Postgraduate School

Sweeney, Robert, Guertin, Nickolas, & Schmidt, Douglas C. (2015). How the navy can use open architecture to revolutionize capability acquisition: The naval OSA strategy can yield multiple benefits. Proceedings of the Twelfth Annual Acquisition Research Symposium. Retrieved from https://apps.dtic.mil/docs/citations/ADA623433

Undersecretary of Defense for Acquisition, Technology, and Logistics (2017, August 10). Operation of the defense acquisition system (Department of Defense Instruction 5000.2). Washington, DC. Retrieved from https://www.esd.whs.mil/Portals/54 /Documents/DD/issuances/DODi/500002_DODi_2015.pdf

University of Southern California (n.d.). User manual, constructive software product line investment model [Fact sheet]. Retrieved from https://csse.usc.edu/csse/research/COPLIMO/

Yoon, Ilbae (2014). Platform policy and its effect on diffusion: The case study of Android and iOS (Master’s Thesis). Retrieved from https://www.researchgate.net/publication/279811131_Platform_policy_and_its_ef fect_on_diffusion_the_case_study_of_Android_and_iOS

73 THIS PAGE INTENTIONALLY LEFT BLANK

74 INITIAL DISTRIBUTION LIST

1. Defense Technical Information Center Ft. Belvoir, Virginia

2. Dudley Knox Library Naval Postgraduate School Monterey, California

75