My prior blog post on product lines in DoD sustainment described the complexity of contractual relationships in a DoD software product line. Recall that a software product line is a collection of related products with shared software artifacts and engineering services that has been developed by a single organization in support of multiple programs serving multiple missions and different customers. A product line can reduce cost of development and support. In exchange, it can be a cause of conflicting priorities between customers, much like the similar problem in joint program management. This blog post describes a set of guidelines and goals for establishing governance and monitoring the product line for long-term success.
Technical debt communicates the tradeoff between the short-term benefits of rapid delivery and the long-term value of developing a software system that is easy to evolve, modify, repair, and sustain. Like financial debt, technical debt can be a burden or an investment. It can be a burden when it is taken on unintentionally without a solid plan to manage it; it can also be part of an intentional investment strategy that speeds up development, as long as there is a plan to pay back the debt before the interest swamps the principal.
A software product line is a collection of related products with shared software artifacts and engineering services that has been developed by a single organization intended to serve different missions and different customers. In industry, product lines provide both customer benefits (such as functionality, quality, and cost) and development organization benefits (such as time to market and price-margin). Moreover, these benefits last through multiple generations of products. This blog is the first in a series of three posts on sustaining product lines in terms of required decisions and potential benefits of proposed approaches. In this post, I identify the potential benefits of a product line and discuss contracting issues in the context of Department of Defense (DoD) programs.
This post was co-authored by Cecilia Albert and Harry Levinson.
At the SEI we have been involved in many programs where the intent is to increase the capability of software systems currently in sustainment. We have assisted government agencies who have implemented some innovative contracting and development strategies that provide benefits to those programs. The intent of the blog is to explain three approaches that could help others in the DoD or federal government agencies who are trying to add additional capability to systems that are currently in sustainment. Software sustainment activities can include correcting known flaws, adding new capabilities, updating existing software to run on new hardware (often due to obsolescence issues), and updating the software infrastructure to make software maintenance easier.
In the SEI's examination of the software sustainment phase of the Department of Defense (DoD) acquisition lifecycle, we have noted that the best descriptor for sustainment efforts for software is "continuous engineering." Typically, during this phase, the hardware elements are repaired or have some structural modifications to carry new weapons or sensors. Software, on the other hand, continues to evolve in response to new security threats, new safety approaches, or new functionality provided within the system of systems. In this blog post, I will examine the intersection of three themes--product line practices, software sustainment, and public-private partnerships--that emerged during our work with one government program. I will also highlight some issues we have uncovered that deserve further discussion and research.
In my preceding blog posts, I promised to provide more examples highlighting the importance of software sustainment in the U.S. Department of Defense (DoD). My focus is on sustaining legacyweapons systems that are no longer in production, but are expected to remain a key component of our defense capability for decades to come. Despite the fact that these legacy systems are no longer in the acquisition phase, software upgrade cycles are needed to refresh their capabilities every 18 to 24 months. In addition, significant modernization can often be made by more extensive, focused software upgrades with relatively modest hardware changes. This third blog post describes effective sustainment engineering efforts in the Army, using examples from across its software engineering centers. These examples are tied to SEI research on capability maturity models, agility, and the Architecture Analysis and Design Language (AADL) modeling notation.
In launching the SEI blog two years ago, one of our top priorities was to advance the scope and impact of SEI research and development projects, while increasing the visibility of the work by SEI technologists who staff these projects. After 114 posts, and 72,608 visits from readers of our blog, this post reflects on some highlights from the last two years and gives our readers a preview of posts to come.
The extent of software in Department of Defense (DoD) systems has increased by more than an order of magnitude every decade. This is not just because there are more systems with more software; a similar growth pattern has been exhibited within individual, long-lived military systems. In recognition of this growing software role, the Director of Defense Research and Engineering (DDR&E, now ASD(R&E)) requested the National Research Council (NRC) to undertake a study of defense software producibility, with the purpose of identifying the principal challenges and developing recommendations regarding both improvement to practice and priorities for research.
In my preceding blog post, I promised to provide more examples highlighting the importance of software sustainmentin the US Department of Defense (DoD). My focus is on certain configurations of weapons systems that are no longer in production for the United States Air Force, but are expected to remain a key component of our defense capability for decades to come, and thus software upgrade cycles need to refresh capabilities every 18 to 24 months. Throughout this series on efficient and effective software sustainment, I will highlight examples from each branch of the military. This second blog post describes effective sustainment engineering efforts in the Air Force, using examples from across the service's Air Logistics Centers (ALCs).
Our SEI blog has included thoughtful discussions about sustaining software, such as the two-part post "The Growing Importance of Sustaining Software for the DoD." Software sustainment is growing in importance as the lifetimes of hardware systems greatly exceed the normal lifetime of software systems they are partnered with, as well as when system functionality increasingly depends on software elements. This blog post--the first in a multi-part series--provides specific examples of the importance of software sustainment in the Department of Defense (DoD), where software upgrade cycles need to refresh capabilities every 18 to 24 months on weapon systems that have been out of production for many years, but are expected to maintain defense capability for decades.
Software sustainment is growing in importance as the inventory of DoD systems continues to age and greater emphasis is placed on efficiency and productivity in defense spending. In part 1 of this series, I summarized key software sustainment challenges facing the DoD. In this blog posting, I describe some of the R&D activities conducted by the SEI to address these challenges.
Department of Defense (DoD) programs have traditionally focused on the software acquisition phase (initial procurement, development, production, and deployment) and largely discounted the software sustainment phase (operations and support) until late in the lifecycle. The costs of software sustainment are becoming too high to discount since they account for 60 to 90 percent of the total software lifecycle effort.
My prior blog post on product lines in DoD sustainment described the complexity of contractual relationships in a DoD software product line. Recall that a software product line is a collection of related products with shared software artifacts and engineering...