Air Force Software Sustainment and Maintenance of Weapons Systems (2020) / Chapter Skim
Currently Skimming:
3 Recommendations
3 Recommendations
Pages 28-43
The Chapter Skim interface presents what we've algorithmically identified as the most significant single chunk of text within every page in the chapter.
Select key terms on the right to highlight them within pages of the chapter.
From page 28... ...
software sustainment capabilities will be increasingly challenged. With an eye toward the current issues faced by the USAF software sustainment enterprise, the committee consulted with technical experts in government, academia, and defense and nondefense industry to identify opportunities to improve future efficiency and effectiveness of USAF software sustainment.
|
From page 29... ...
The committee found that practices that support the shift toward more agile software development methods included evolved software development automa tion tools, environments that supported rapid and frequent testing, and build cycles with many organizations adopting daily or continuous build and test processes to continuously maintain an operational system under development. The move to agile development methodologies will require a review of some of the procedures used in program management to allow those procedures to have the latitude to accommodate the agile software development process.
|
From page 30... ...
While USAF software sustainment organizations can and should benefit greatly from DevSecOps, there are unique aspects of some Department of Defense (DoD) software that will require more testing and analysis before deployment.
|
From page 31... ...
Changes to the main source code typi cally require review by at least one other engineer, and code review discussions are open and collaborative. • Unit test is ubiquitous, fully automated, and integrated into the software review pro cess.
|
From page 32... ...
As noted earlier, software sustainment is fundamentally a process of continuous software evolution, and the practices of continuous development and deployment to operation incor porated in DevSecOps should permit software sustainers to deliver incremental software improvements to end users more frequently, prioritize defect removal and new feature requests, and rapidly receive feedback on deployed software to support iterative development. More responsive software practices should allow program managers to adjust timing of software update deployments to the fleet, permitting more rapid upgrade cycles, and increased responsiveness to user requests.
|
From page 33... ...
The USAF software sustainment centers have traditionally been co-located with maintenance depots, significantly separated from national centers of commercial software development. This approach has re quired the USAF to recruit, train, and retain a workforce that is generally separate from the large commercial software development communities located in coastal metropolitan areas.
|
From page 34... ...
Sustainment organizations have felt compelled by regulation to manage organic and contractor software mainte nance workforce mixes in a manner similar to that imposed on hardware sustain ment efforts, but such regulations seem ill suited to the developmental nature of software sustainment. The USAF should carefully evaluate software sustainment con ractor and organic workforce mixed teams with an eye toward accessing key t talent, achieving operational and business efficiencies, and achieving maximum output per employee.
|
From page 35... ...
Many of the issues associated with USAF software sustainment result from incorrectly seeing software sustainment as equivalent to hardware sustainment. This false equivalence results in practices, such as organic software development organizations collocated with hardware maintenance depots, the application of hardware-focused regulations and legislation to hardware development, and the use of USAF financial processes and personnel practices more suitable to hardware maintenance than to software development.
|
From page 36... ...
Therefore, any system that is dependent on software to remain operational is always in a state of continuous engineering during sustainment.6 Based on those observations and statements, as well as information received by the study committee, it becomes apparent that software sustainment is merely software development by another name, and should be treated as such. This per spective creates an opportunity to evolve USAF software sustainment practices by adopting industry best practices associated with the incremental and continuous delivery of software.
|
From page 37... ...
This task of estimating software development impacts resource-constrained sustainment activities, which compete for resources with hardware sustainment activities, and projects and programs can find themselves re sourced at a level of effort that may not match user expectations for defect removal and feature delivery. This difficulty in estimating costs results in a misalignment of funding necessary to support software sustainment.
|
From page 38... ...
In agile methodology, development occurs in short time windows referred to as sprints, and at the conclusion of each set of sprints, the remaining work to be done, including the features that were not addressed in previous sprints, new user requests received during the sprint, and new defects and rework discovered during the sprint, are reprioritized by users and developers in tight synchronization. This movement of remaining work permits users to accelerate mission-critical needs, reprioritize feature delivery to address fast-tempo changes in operational require ments, accept the need to live with certain software defects so that higher priority fixes can be implemented first, manage and accept risk, and gain confidence in the responsiveness of the software sustainment team.
|
From page 39... ...
develop enterprise architectures. These recommended software architecture tenets are discussed further as follows: Software Architecture Tenet 1: Develop modular software with well-defined interfaces among key components.
|
From page 40... ...
Software Architecture Tenet 3: Establish data rights that align with the life cycle strategy. Having access to the right level of data and source code should enable effective maintenance.
|
From page 41... ...
These systems were suitable to the purpose at the time they were originally developed, but over time the ability to continuously support these systems has become increasingly expensive -- requiring expertise in software languages, legacy code bases, tool chains, and hardware architectures that are no longer widely supported. Providing software sustainment for these legacy platforms will continue to be increasingly challenging as new requirements for security, requirements for rehosting to new hardware archi tectures and cloud-based environments, and new interface requirements proliferate.
|
From page 42... ...
In addition, the organic USAF units that develop and sustain code are r esponsible for some systems that use legacy code for which current tooling may not be available. There is a burden, both financially and in workload, to maintain software tooling for these systems.
|
From page 43... ...
Recommendation 8: The U.S. Air Force should acquire data rights sufficient for software sustainment of its weapons systems, even when contractors hold agreements to sustain the system for the life cycle of the program.
|
Key Terms
This material may be derived from roughly machine-read images, and so is provided only to facilitate research.
More
information on Chapter Skim is available.