HomeAbout UsBrowse This IssueBack IssuesNews DispatchesSubscribing to Army LogisticianWriting for Army LogisticianContact UsLinks































Post Production Software Support

Post production software support provides logistics support for maintaining and further developing the operational capability of Army systems. But what is post production software support, and how does it affect the cost of operating the systems?

Radar, satellite terminals, tactical communications, intelligence systems, sensors, position location, battle command systems, logistics information, and decision support systems—a quick look at military systems, both on the battlefield and supporting the warfighter, reveals that they nearly all require software to operate. The “net-centric” migration to integrating and sharing data and information among systems (across tactical, strategic, and information systems) increases the criticality of maintaining the operational software for these systems. With the ever-increasing criticality of maintaining software for the operational sustainment of systems, it is important that logisticians understand the elements and drivers of software support. This article presents the basic factors that influence software support and why its costs will increase in the future.

What is PPSS?

A system’s software is sustained through post production software support (PPSS), which encompasses all software activities required to ensure that fielded systems that are out of production continue to support their operational mission. Although simple in concept, PPSS encompasses a host of activities, including maintaining operational capabilities by correcting defects discovered in the field, ensuring compliance with information assurance requirements, adjusting software driven by changes in commercial off-the-shelf (COTS) releases, assisting users in the field, ensuring compliance with Department of Defense (DOD) and Department of the Army directives and policies (such as software blocking), and improving software maintainability and reliability. The effort associated with these activities is affected by a number of variables, such as the size of the software program, type of software applied, changes required, and complexity of the software in the systems.

In general, software size, changes required, and complexity are easily explained at the macrolevel.

Software size. The size of the program is generally counted as the lines of code (LOC). Using LOC has its roots in early programming, when each line of code generally contained a command for the software. The more complex the program, the more lines required to perform the function, and therefore the larger the number of lines. At a simplistic level, this holds true today, and the LOC often continues to be a measure of the size of the program—the more lines, the more effort required to maintain it.

Changes required.
This refers to what must be adjusted, updated, and so forth in a given period of time (usually a year). It is viewed as a subset of the LOC by actual numbers (LOC required changes) or as a percentage of the lines of code (x-percent of LOC has to be changed). Changes to those LOC must be accomplished using PPSS.

Complexity. This is a measure of the intricacy associated with a program. Increases in complexity are easily understood at the macrolevel but difficult to quantify. Complexity is generally accepted as the number of control paths and interfaces associated with the software. Control paths are the different branches the program potentially has, which are driven by subroutines and operands, such as if/then and calculation-driven subroutines. Interfaces are the points at which the program sends and receives information to and from external programs. As the Army moves to programs sharing more and more information across the “WARNET,” these interfaces will continue to increase. Although a doctoral dissertation could be developed on the details associated with measuring complexity, this basic definition will be used for this article.

Advantages of COTS

One of the acquisition initiatives implemented by the Army and DOD in the 1990s is having an ever-increasing effect on PPSS—the use of COTS software products. The benefits of applying COTS products include decreased development efforts (resulting in reduced development costs) and faster procurement (putting systems into the hands of the warfighter faster). Systems being used by our Soldiers today could still be on the drawing board if it were not for the use of COTS software. This shift in emphasis (from proprietary DOD software on a system to COTS) exploded in the late 1990s and is still prevalent today. COTS procurements have grown in breadth and depth across the entire defense establishment. In the PPSS world, application of COTS is bringing additional requirements associated with maintaining software—primarily license costs, security updates, and certification and accreditation.

Additional Costs of COTS Systems

Before the Army started using COTS software, it generally owned the software when the product was procured, including the source code. Any changes to the software were controlled, driven, and managed by the Army. If no changes were made to the software, there were no costs to maintain the software after its purchase. However, a COTS product generally brings with it a logistics tail associated with purchasing future licenses and integrating updates driven by the commercial vendor. Since the Army no longer owns the software, the Army is wed to the vendor as long as the COTS software is used.

The Army Communications-Electronics Command Software Engineering Center (SEC) is responsible for maintaining command, control, communications, computer, intelligence, sensors, and reconnaissance (C4ISR) systems in PPSS, and the impact of COTS licenses on those requirements is profound. In building the program objective memorandum (POM) for fiscal years (FYs) 2010 to 2015, these licensing costs are estimated to increase to about $100 million in FY 2010 (including installation and management) and to $140 million by FY 2015 (excluding some additional license costs associated with software blocking). Some of these costs are driven by new systems entering PPSS, including PPSS license costs associated with the Distributed Common Ground System-Army (DCGS–A).

In addition to software licenses, COTS brings a logistics cost associated with security. Since most PPSS systems are not stand alone, information and data are passed among systems over tactical and strategic communications systems and the Global Information Grid. Maintaining information assurance on these systems is critical and is accomplished through the information assurance vulnerability alert (IAVA) process, in which software is updated by the vendor to maintain data integrity. This is best illustrated by the various releases of Microsoft to correct vulnerabilities in its software. Hackers and attackers often choose Microsoft because of its sheer size. Therefore, all Microsoft users are vulnerable to the flaws discovered by these hackers and attackers. Because of this, systems and computers with heavy use of Microsoft products generally apply patches as soon as possible to avoid information and operations vulnerabilities.

This same process is required of COTS products in PPSS systems. Efforts associated with IAVAs do not end with the installation of the patch. The system must be tested to ensure that the patch has no secondary effects on the operation of the system. This certification and accreditation process is performed on software after modifications are made and is required to be performed on weapon system software before it is released. DOD and the Department of the Army have rules and regulations associated with the certification and accreditation process that result in the system’s approval to operate on DOD networks.

Identifying PPSS Requirements

The factors discussed above affect the effort needed to maintain software at the system level. The overall process of building requirements across all systems is applied in developing the POM requirements for PPSS. In developing PPSS requirements, SEC groups requirements into three general areas as follows: senior leader directed (SLD), near-term readiness (NTR), and industrial base (IB).

For PPSS, SLD requirements are primarily “software blocking.” These efforts fund battle command software from a system-of-systems viewpoint to ensure that command and control and associated systems feeding data are upgraded across the board to maintain proper battle command. In the POM, SLD requirements are estimated to increase from $140 million in FY 2010 to $210 million in FY 2015.

PPSS NTR requirements are made up of four distinct pieces: license costs, IAVAs, certification and accreditation, and field software engineers (FSE). FSEs are the software engineers in the field providing critical support to maintain the operational capabilities of systems. They perform software fixes, debug, identify and isolate problems, assist in software release installation, make emergency corrections, and so forth. Failure to fund NTR requirements results in inoperable systems (no licenses to run systems), loss of authority to operate, elimination of technical support, and loss of systems security (which places warfighters at risk of malicious network attacks). The cost to operate NTR can almost be viewed as a funding “floor” in that, if not funded, systems must basically be shut down. In the POM, NTR requirements are estimated to increase from $210 million in FY 2010 to $316 million in FY 2015 (including those NTR costs associated with DCGS–A less some licenses in software blocking).

PPSS IB requirements are efforts to fix software problems discovered during use, updates to interfaces with other systems, and upgrades required to maintain operational capabilities (for example, updating threat information for sensor or analysis systems to ensure that the latest threat information is used by the system). In general, the drivers of IB requirements are software size, changes required, and complexity. Over time, the sheer size of software programs supporting a system tends to increase in size. Although, in itself, the size of a program does not drive the sustainment effort (for example, a large program may require minimal changes in proportion to its size), the effort to sustain a large program (the knowledge base required to understand the whole) does affect PPSS efforts.

With the growth in software complexity driven by both individual system software complexity and the effect of more systems sharing data across systems, most systems software requires some modification or updates every year. Increases in complexity are key variables in determining PPSS industrial base requirements. Taken collectively, the variables of software size, changes required, and complexity drive the IB requirements for PPSS.

Software is critical to ensuring the operational capabilities of today’s and tomorrow’s Soldier. Maintaining software is accomplished through PPSS requirements, which are built from three basic categories: SLD, NTR, and IB. The application of COTS products has provided our Soldiers with systems and capabilities that otherwise would have taken longer and cost more to develop. However, long-term PPSS comes with its own costs. Over the POM, PPSS-based requirements for SEC-supported systems total over $500 million in FY 2010 and increase to over $700 million in FY 2015, driven by factors such as the logistics costs associated with COTS products, the increased complexity and size of software in a system, and new systems entering PPSS. PPSS requirements must be funded to maintain the capabilities of systems required by our Soldiers in the field.

Marc W. Gutleber is a program analyst with the Army Communications-Electronics Command Software Engineering Center.