February 9, 2023
Volume 20, issue 6

Download PDF version of this article PDF

Three-part Harmony for Program Managers Who Just Don't Get It, Yet

Open-source software, open standards, and agile software development

Guenever Aldrich, Danny Tsang, Jason Mckenney

Side by side on my piano keyboard... Paul McCartney wrote about two-part harmony in the song "Ebony and Ivory."

The lyrics could apply to DoD (Department of Defense) systems acquisition, which is unique in comparison to commercial software product development. Demanding requirements, stakeholder buy-in, and longer development timeframes for the DoD don't require just two-part harmony; an entire choir is needed, working in concert to deliver robust systems that typically operate for decades.

This article examines three tools in the system acquisitions toolbox that can work to expedite development and procurement while mitigating programmatic risk: OSS (open-source software), open standards, and the Agile/Scrum software development processes are all powerful additions to the DoD acquisition program management toolbox.ⁱⁱ

As with all tools, it is better to have them on hand and not need them, than not have a particular tool and need it.

Just as the commercial world relies on software for almost every aspect of everyday life, so does the DoD. As such, the ability to quickly develop, integrate, and deploy software into new and existing military systems is a critical component for allowing the United States to maintain a technological edge over peer and near-peer adversaries.

The DoD's 2018 cyber strategy "prioritizes the challenge of great-power competition and recognizes that DoD must defend forward to counter U.S. competitors' long-term, coordinated campaigns of malicious activity to gain political, economic and military advantage," according to a DoD official on Capitol Hill.⁴ Along with defending forward, the cyber strategy pushed for processes to expedite development and deployment of systems.

Building on the cyber strategy and looking to expedite the ability to develop, integrate, and field software-based capabilities, a February 2022 memo from the office of the Deputy Secretary of Defense, titled "Department of Defense Software Modernization," focused on providing a strategy for quickly delivering capabilities to the field. "The Department's adaptability increasingly relies on software, and the ability to securely and rapidly deliver resilient software capability is a competitive advantage that will define future conflicts."²⁷

Open-Source Software

The 2018 DoD cyber strategy directed that software acquisition provide preferential treatment to OSS, and with good reason: If used properly, OSS can mitigate long-term risk and be a tool for keeping sustainment costs down by helping to prevent vendor lock, and the same applies to open standards. It is important to note that open-source software is different from an open standard, which is discussed in the next section.

OSS typically refers to software source code that is freely available for modification and redistribution. There is no universally agreed-upon definition of open-source software; this article uses the official DoD definition: "software for which the human-readable source code is available for use, study, reuse, modification, enhancement, and redistribution by the users of that software."²⁶

Software licensing is a very big deal—it not only protects the intellectual property of the developer, but also ensures that customers receive the support for which they have contracted. OSS is typically licensed under one of the many available open-source licenses. Following are the most common licenses (and families of licenses) in the order of least to most permissive:

• GNU GPL (General Public License) – Free copyleftⁱⁱⁱ license for software and other kinds of works. GPL is intended to guarantee the freedom to share and change all versions of a program—to make sure it remains free software for all its users.⁸

• MIT license – A permissive^iv free software license developed by the Massachusetts Institute of Technology in the late 1980s. As a permissive license, it puts only very limited restriction on reuse and is compatible with GNU GPL.¹³ The difference between an MIT license and GNU GPL is that it allows for software reuse in proprietary software.

• BSD (Berkley Software Distribution) – A family of permissive free software licenses that impose minimal restrictions on the use and distribution of covered software. This is different from copyleft licenses (GPL and MIT), which have share-alike^v requirements.¹⁵

• Apache – Also a permissive free software license, drafted by the Apache Software Foundation. It allows for using the software for any purpose, distributing and modifying it, and distributing modified versions.¹ Differences between Apache and the MIT and GPL licenses are that (a) Apache contains a patent license and retaliation clause¹² and (b) it is not a copyleft license.

Typically, software released with an open-source license encourages decentralized development and open collaboration, which can speed up the development process. Depending on the license, there are varying levels of permissiveness regarding linking, redistribution, modification, and private use.^vi

There are downsides to the DoD focusing on OSS, security being the most visible. Using software code products that are developed and maintained externally in mission-critical systems potentially creates a security risk by providing a path for adversaries to introduce harmful or malicious code into military systems. A lower-profile risk is that sharing code specifically developed for the DoD could disclose key innovations critical to the nation's defense.²¹

The risk associated with malicious code being introduced into a system can be mitigated by conducting through thorough assessments for security vulnerabilities and being managed, through the entire life cycle, using an academically rigorous process. The current DoD process is called SCRM (supply chain risk management^vii). SCRM is defined by the DoD as "the process for managing risk by identifying, assessing, and mitigating threats, vulnerabilities, and disruptions to the DoD supply chain from beginning to end to ensure mission effectiveness;"²⁵ and the NIST's (National Institute of Standards and Technology's) new publication, "Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations"³ provides software supply-chain security guidance to developers and suppliers on best practices and evaluating security.

Through the implementation of NIST's C-SCRM (Cybersecurity–SCRM) program,²³ software risks are further mitigated. Specific practices include integrating C-SCRM across the enterprise; establishing a formal program; knowing and managing critical products, services, and suppliers; understanding an enterprise's supply chain; closely collaborating with critical suppliers; including critical suppliers in resilience and improvement activities; assessing, auditing, communicating consistently and continuously with all suppliers (not just the large ones); and collaboratively planning for the system's entire anticipated life cycle. As part of the supplier relationship, contracts with suppliers and third-party vendors should include language that implements measures designed to meet the requirements of the enterprise C-SCRM plan.

The second risk, sharing code developed specifically for the DoD, can be mitigated by using a MOSA (modular open systems approach) to prevent critical defense innovations from being leaked to adversaries. MOSA "is an integrated business and technical strategy to achieve competitive and affordable acquisition and sustainment over the system life cycle."²⁴ This approach to systems acquisition creates an architecture of severable modules, which can be developed by multiple vendors, and allows critical modules to be protected, thereby reducing risk of exposure to adversaries while allowing the DoD to benefit from OSS. The modules are typically a mix of proprietary and OSS and can be incrementally added, removed, or replaced throughout the life cycle of a major system platform to afford opportunities for enhanced competition and innovation.²¹

OSS is an important tool in DoD's acquisition playbook; used properly, it helps create a competitive environment and allows long-lived defense systems to keep pace with the rapid evolution of technology by decreasing development, integration, and implementation cycle times. The key is initially properly assessing OSS for security vulnerabilities and creating an acquisition and sustainment environment where ongoing assessments are conducted by software and security personnel.

Open Standards

For the sake of parallelism, we wanted to start this section with the BBC's best duet; but "The Foggy Dew"^viii doesn't really lend itself to a discussion of open standards. Open software standards are another important tool for acquisition program managers. These are standards made available to the general public and are developed (or approved) and maintained via a formalized collaborative and consensus-driven process. They are specifically designed to facilitate interoperability and data exchange and are intended for widespread adoption. Like OSS, there is no universally agreed-upon definition of open standard, so here we use the W3C (World Wide Web Consortium) definition: a standard that is openly accessible and usable by anyone. Many other organizations have definitions that encompass the same or similar principles,²⁸ including: OpenStand,¹⁷ International Telecommunication Union,¹¹ Open Source Initiative,¹⁴ and the Free Software Foundation Europe.⁷

W3C ensures that its standards can be used without royalties. This means it is not encumbered by usage fees, and, as such, buyers tend to prefer using them because it is believed they will be cheaper across the system's life cycle. They also potentially offer multiple implementations, both commercial and open source, for access because of network effects^ix and increased competition among vendors.¹⁰ Multiple implementations can reduce the risk of vendor lock to an acquisition program. Examples of common open standards include: XML (messaging), HTML (Internet display), and SQL (databases).

Another benefit of using an open standard in a defense acquisition is streamlined development and interoperability. DoD systems need to have interoperability across systems and subsystems, but also throughout the life cycle, development to disposal. Open standards specifically seek to establish protocols that make applications interoperable, which makes development more efficient, and they help remove vendor lock by increasing the ability to exchange data across boundaries.²² It is reasonable to expect vendors to come and go during the system life cycle of a DoD program; open standards are one way to help ensure data is protected from obsolescence or deprecated^x applications, as they can be reimplemented to ensure continuous accessibility.¹⁶

Circling back to the processes surrounding developing, maintaining, and updating open standards: The W3C process for an open standard is rigorous and consistently evolving to meet the needs of the membership and is focused on creating formal guidance that promotes fairness, responsiveness, and forward progress. According to W3C, for a technical specification to be defined as an open standard, it must meet the following set of requirements:²⁰

• Transparency. All technical discussions, due process, and meeting minutes are archived and referenceable in decision-making.

• Relevancy. New standardization is dependent on analysis of market needs.

• Openness. Anybody can participate: individuals, industry, public, academia, and government.

• Impartial and consensus. Guarantees fairness through the process and weighing the concerns of each participant.

• Availability. Free access to standard text and clear rules for implementation.

• Maintenance. Ongoing process for revisions, corrections, and testing.

EXI (Efficient XML Interchange) and Google's Protocol Buffers (Protobuf) standard provide a comparison between an open standard and a proprietary standard. EXI is an open standard used to represent XML data in a binary format and subjected to the aforementioned W3C requirements. Protobuf is an open-source (not open-standard) data format used for interserver communication and data storage; it was developed and is currently maintained primarily for the needs of Google, although Google provides the source code on GitHub, and individuals or teams can discuss suggestions or features on forums or submit requests to merge code; however, any decisions about incorporating changes are ultimately up to Google's development team.⁹

This delineation between the formal W3C process and the moderated Google process is the difference between a truly open standard and a proprietary standard designed for a single organization. It is important to note that EXI is not "better" than Protobuf just because it is an open standard. To align with current DoD acquisition guidance, however, programs should evaluate and consider leveraging open standards²⁶ when possible.

One major benefit to the DoD of adopting an open standard such as EXI is that it is possible to become a stakeholder and contribute to the standards definition process. The Protobuf standard is maintained by Google, and it is unlikely the DoD could become (if necessary) involved in the standard's development process. In the case where an open or proprietary standard is no longer maintained because of a superseded technology or business failure, it is likely more cost-effective for the DoD to undertake maintenance of an open standard than a proprietary one.

A potential downside of an open standard is that updates to the standard can get lost in the approval process, or time-sensitive changes can take too long to wind through the consensus process.

To conclude, the second-best duet^xi is "The Fairytale of New York" by the Pogues, which also doesn't work for a discussion of open-source software or open standards. The second-worst duet— "You're the One That I Want" by Arthur Mullard and Hilda Baker (more commonly known from the musical Grease)—does lend itself to agile software development: "I got chills, they're multiplying; And I'm losing control; 'Cause the power you're supplying; It's electrifying." Having such a powerful tool in a program manager's toolbelt: It's electrifying!

Agile/Scrum Software Development

When maintaining a parallel structure, a duet doesn't work when introducing a third tool in a program manager's software development toolbox, such as: musical trios. This is a toss-up: My preference is the English band Cream, while Jason McKenney prefers Beethoven's Opus 1,^xii which is a trio of trios. Both are amazing! The lyrics of Cream's best song (totally opinion), "Sunshine of Your Love," very much fit in with agile software development processes: "I've been waiting so long; To be where I'm going." Government acquisitions have been looking and waiting a long time for powerful tools that can make software development more efficient and effective. Used properly, Agile processes can help do that.

Starting at the beginning, Agile refers to a collection of values that focus on frequent communication between the development side and the customer and that also promote short, iterative development cycles with tighter feedback loops. The Agile^xiii process is based on incremental steps of development. The idea is that a project is delivered in parts, rather than all at once.

The Agile development process has a specific set of terms used within the community to communicate efficiently,¹⁸ and in order to discuss Agile software development effectively, these terms need to be defined:

• Backlog (also called sprint backlog) – The to-do list—a full list of items within the project scope, ordered by priority determined by technical leadership.

• Daily standups – A 15-minute coordination and synchronization meeting held each day in a sprint (see below), where development team members state what they completed the day before that affects the work to be done today, what they will complete on the current day, and whether they have any roadblocks.

• Releases. A high-level timetable of the next set of functionalities for release. This artifact is outside of the scrum (see below) process, but improves scrum team success.

• Scrum. An implementation of those Agile values, which incorporates daily standups, a backlog of user stories, and short (one- to four-week) sprints.

• Sprint. A short cycle of development in which the team creates potentially shippable product functionality. Sprints, the scrum term for iterations, typically last between one and four weeks.

• Story. A requirement, feature, and/or unit of business value that can be estimated and tested. Stories describe work that must be done to create and deliver a feature for a product. Stories are the basic unit of communication, planning, and negotiation.

• Story points. Units of measurement for expressing an estimate of the overall effort required to fully implement a product backlog item or any other piece of work. A common scale is one to seven story points, where one is the simplest and seven is the most difficult.

The use of scrums in an Agile software development environment is important enough that it deserves its own paragraph (and probably a song, too). Scrums provide a framework that helps development teams work together.⁵ Scrums specifically acknowledge that the team doesn't have all the information at the beginning and foster collaboration. They are led by a scrum master and are designed to be an enabling tool for learning through experiences, promoting team self-organization to move problems forward in an efficient manner, and helping the team adapt to evolving requirements. The scrum master's role can vary from project to project, but in top-level terms, they are the conductor of the development team. They remove obstacles and roadblocks^xiv from the developer's path, and work to facilitate not only the daily standup meetings, but also the team's forward progress.¹⁹ They ensure that the tenets of the Agile Manifesto are met.

As laid out in the Agile Manifesto,² one of the principal tenets of Agile software development processes is that they work best when the customer and the development team are able and willing to be part of a collaborative environment. In a true Agile software environment, the focus is on the people doing the work, and solutions are arrived at through collaboration among not only the development team, but also with the customer. In short, Agile development thrives in an environment where consensus-building and a collaborative culture (as opposed to a command-and-control culture) exist.⁶

Another of the four key tenets is: Responding to change over following a plan.² This means accepting, if not welcoming, evolving requirements during the development process, even late into the process. This is not to say accepting requirements creep, but changing requirements—a key difference. Accepting changes to the requirements allows for contractors to evolve systems quickly to ensure that the DoD can maintain a technological advantage over near-peer adversaries.

The third tenet that separates Agile from other approaches to software development is the focus on the people doing the work and how they work together, or as the manifesto puts it: Individuals and interactions over processes and tools.² People respond to the requirements laid out by the government, and they develop the software. Both the government stakeholders and the companies contracted to do the work need to foster an environment where the people are valued. Process and tools are valuable, but they cannot respond to changing environments without human input, and they can be unable to meet evolving customer needs.

The last of the four tenets of Agile software development, Working software over comprehensive documentation,² is a huge culture shift for the DoD, and given the longevity of DoD systems (look at the B-52 or AWACS), this one may not hold as much value since the systems and software produced for the DoD may need to last for generations. Streamlining documentation, however, and creating more effective documentation will be huge. Using the principles of collaboration and cross-functional teams and creating documentation in parallel with development can streamline the overall process. Incorporating MBSE (model-based systems engineering)^xv is another way to streamline contractually required documentation, and this is a practice already being incorporated into the DoD.

To paraphrase Ariana Grande's song, "Break Free," This is the part when I break free. The DoD and the federal government's contracting paradigm need to break free from traditional software development methodologies and begin to embrace more flexible development environments using true Agile development processes instead of just paying lip service to the concept. More flexible development paradigms will allow requirements to evolve to meet current threats and can potentially accelerate the acquisition process.

Progress is being made—for example, the ongoing acceptance and integration of MBSE into DoD systems acquisition; the reduction of traditional paper-based contract deliverables; and government acquisition program offices realigning their teams to coordinate better with their system developers' teams for better communication and less lost time as a result of misunderstandings regarding requirements and "nice-to-haves."

There is no silver bullet.^xvi Every development decision in an acquisition program involves tradeoffs. The program managers, in conjunction with the development team, need to communicate and be consciously aware of these tradeoffs. These three tools—open source, open standards, and Agile software development—coupled with good communications can ensure a more efficient and effective use of government resources.

This article really should end with lyrics from a choral piece, and that has created a lot of discussion among the three authors. A sea shanty like "Roll the Old Chariot Along"? Something classical like Beethoven's "Missa solemnis"? Or "Another Brick in the Wall (Part II)" by Pink Floyd? After much discussion, we leave you with Gloria Estefan: Coming out of the dark; I see the light.^xvii

Footnotes

i. Fun fact: Paul McCartney wrote "Ebony and Ivory" as a duet sung with Stevie Wonder, and it was Wonder's first number-one hit in the United Kingdom. In 2007 BBC listeners declared the song the worst duet ever.

ii. Thank you for reading the footnotes. Make sure you look at References and Additional Reading. We spent a lot of time building a well-rounded list that provides more in-depth information.

iii. Copyleft is the practice of granting the right to distribute and modify intellectual property with the requirement that the same rights be preserved in derivative works created from that property. Copyleft in the form of a license can be used to maintain copyright conditions for works ranging from computer software to documents, art, scientific discoveries, and even certain patents (https://en.wikipedia.org/wiki/Copyleft).

iv. Wikipedia's definition of permissive licenses are those that carry only minimal restrictions on how the software can be used, modified, and redistributed, usually including a warranty disclaimer (https://en.wikipedia.org/wiki/Permissive_software_license).

v. Share-alike is a copyright licensing term used to describe works or licenses that require copies or adaptations of the work to be released under the same or similar license as the original. Copyleft licenses are free content or free software licenses with a share-alike condition (https://en.wikipedia.org/wiki/Share-alike).

vi. This list is truncated from the original, which can be viewed at https://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licences.

vii. DoD's approach to SCRM is detailed in DoD instruction 4140.01 (2019): DoD Supply Chain Material Management Policy from the Office of the Under Secretary of Defense for Acquisition and Sustainment; and DODI 8500.1 from the Chief Information Officer, Cybersecurity.

viii. "The Foggy Dew" is an Irish ballad that chronicles the Easter rising of 1916 and encourages Irish people to fight for the cause of Ireland, rather than for the British Empire, as so many were doing in World War I (https://en.wikipedia.org/wiki/Foggy_Dew_(Irish_ballad)).

ix. Network effects is an economics term that the Oxford dictionary defines as a phenomenon whereby a product or service gains additional value as more people use it. Instant messaging and Google have both experienced network effects.

x. Deprecated refers to a software or programming language feature that is supported but not recommended. It is something that may be phased out but can be used for the moment (https://www.techopedia.com/definition/24828/deprecated#:~:text=Deprecated%20refers%20to%20a%20software,be%20used%20in%20the%20meantime).

xi. The full list of best and worst duets can be found at http://news.bbc.co.uk/2/hi/entertainment/7031695.stm.

xii. Fun fact: Opus 1 was dedicated to Prince Lichnowsky and was first performed in his house in 1795.

xiii. The best individual source for information about the Agile process is the Agile Alliance (https://www.agilealliance.org/).

xiv. No song, instead a Dilbert comic (https://dilbert.com/strip/2017-02-08)—one of the best scrum comics.

xv. MBSE is a topic for another paper. Hong Luu and Scott Nigel of The Aerospace Corporation have written a great introductory article, "The Future of Acquisitions is MBSE," published in CHIPS, the Department of the Navy's information technology magazine (https://www.doncio.navy.mil/chips/ArticleDetails.aspx?id=15594).

xvi. And queue a snappy quote from either a Bob Seger and the Silver Bullet Band or maybe Hawthorne Heights' song "Silver Bullet": At least you'll have my...heart. You know you shine sooo bright.

xvii. "Coming out of the Dark" by Gloria Estefan isn't truly a choral song, but it does feature a choir.

Author's note from Guenever Aldrich: Writing this article has been a huge help for me, a hardware person introduced to software development management. Danny, Jason, and the rest of our development team have been a huge help explaining—and often re-explaining—concepts to me. Ideally this helps other managers who just don't get it, yet. All of us want to give a thank you to Marke Beasely for being a font of knowledge about the security aspects of using open-source software in Department of Defense systems, and to Scott Bergonzi for being our software development expert and answering a lot of questions.

References and Additional Reading

1. Apache Software Foundation. 2004. Apache license, version 2.0; https://www.apache.org/licenses/LICENSE-2.0.

2. Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Martin, R. C., Mellor, S., Thomas, D., Grenning, J., Highsmith, J., Hunt, A., Jeffries, J. Kern, J., Marick, B., Schwaber, K., Sutherland, J. The Agile Manifesto. Agile Alliance; https://www.agilealliance.org/agile101/the-agile-manifesto/.

3. Boyens, J., Smith, A., Bartol, N., Winkler, K., Holbrook, A., Fallon, M. 2022. Cybersecurity supply chain risk management practices for systems and organizations. U.S. Department of Commerce, National Institute of Standards and Technology. NIST SP.800-161rl; https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-161r1.pdf.

4. Cronk, T. M. 2020. DoD's cyber strategy of past year outlined before Congress. DoD News. Department of Defense; https://www.defense.gov/News/News-Stories/Article/Article/2103843/dods-cyber-strategy-of-past-year-outlined-before-congress/#:~:text=The%202018%20Defense%20Department%20cyber,official%20said%20on%20Capitol%20Hill.

5. Drumond, C. What is scrum? Atlassian; https://www.atlassian.com/agile/scrum#:~:text=Scrum%20is%20a%20framework%20that,and%20losses%20to%20continuously%20improve.

6. Francino, Y. 2015. What is collaboration and why is it important to Agile methodologies? TechTarget; https://www.techtarget.com/searchsoftwarequality/answer/What-is-collaboration-and-why-is-it-important-to-Agile-methodologies.

7. Free Software Foundation Europe. Open standards; https://fsfe.org/freesoftware/standards/def.en.html.

8. GNU Operating System. 2007. GNU General Public License; https://www.gnu.org/licenses/gpl-3.0.html.

9. Google. Contributing to Protocol Buffers. GitHub; https://github.com/protocolbuffers/protobuf/blob/master/CONTRIBUTING.md.

10. Greenstein, S., Stango, V. 2007. Standards and Public Policy. New York, NY: Cambridge University Press.

11. International Telecommunication Union, Telecommunication Standardization Sector. Definition of "Open Standards"; https://www.itu.int/en/ITU-T/ipr/Pages/open.aspx.

12. Morris, J. 2016. Which license should I use? MIT vs. Apache vs. GPL. Exygy; https://www.exygy.com/blog/which-license-should-i-use-mit-vs-apache-vs-gpl.

13. Open Source Initiative. The MIT license; https://opensource.org/licenses/MIT.

14. Open Source Initiative. Open standards requirement for software; https://opensource.org/osr.

15. Open Source Initiative. The 3-clause BSD license; https://opensource.org/licenses/BSD-3-Clause.

16. OpenStand. 2014. 5 reasons open standards are essential to application development; https://open-stand.org/5-reasons-open-standards-are-essential-to-application-development/.

17. OpenStand. Principles; https://open-stand.org/about-us/principles/.

18. Radigan, D. Story points and estimation. Atlassian; https://www.atlassian.com/agile/project-management/estimation.

19. Rahman, J. 2021. So what does a scrum master do? scrum.org; https://www.scrum.org/resources/blog/so-what-does-scrum-master-do.

20. Schneider, J., Kamiya, T., Peinter, D., Kyusakov, R. 2014. Efficient XML Interchange (EXI) format 1.0 (second edition); https://www.w3.org/TR/exi.

21. Sherman, J. B. 2022. Software development and open source software. Memorandum for senior Pentagon leadership. Department of Defense; https://dodcio.defense.gov/portals/0/documents/library/softwaredev-opensource.pdf.

22. Tsang, D., Aldrich, G. 2022. Efficient XML interchange vs. Protocol Buffers for universal command and control. The Aerospace Corporation.

23. U.S. Department of Commerce, National Institute of Standards and Technology, Information Technology Laboratory. 2022. Cybersecurity Supply Chain Risk Management (C-SCRM); https://csrc.nist.gov/Projects/cyber-supply-chain-risk-management.

24. U.S. Department of Defense, Undersecretary of Defense, Research and Engineering, Advanced Capabilities. Modular Open Systems Approach; https://ac.cto.mil/mosa/.

25. U.S. Department of Defense. 2019. DOD supply chain material management policy. Office of the Under Secretary of Defense for Acquisition and Sustainment.

26. U.S. Department of Defense, Chief Information Officer. 2021. DoD open-source software FAQ; https://dodcio.defense.gov/open-source-software-faq/.

27. U.S. Department of Defense. 2022. Department of Defense Software Modernization; https://media.defense.gov/2022/Feb/03/2002932833/-1/-1/1/department-of-defense-software-modernization-strategy.pdf.

28. Wikipedia. Open Standard; https://en.wikipedia.org/wiki/Open_standard.

Guenever Aldrich is a senior project leader at The Aerospace Corporation, where she is currently supporting the DOD with the impacts of reallocation of the electromagnetic spectrum for 5G and other commercial uses. She is a former military officer and has over twenty years experience in DOD weapon system acquisition. She holds a BS and MS from Rensselaer Polytechnic Institute; and an MS from the Air Force Institute of Technology.

Danny Tsang is an engineering specialist in the Software Architecture and Engineering Department at The Aerospace Corporation. He has more than five years of experience researching and developing software prototypes to improve satellite mission management and ground processing. He has a BS and MS in computer ccience from the University of Texas at San Antonio, and is currently pursuing a PhD in computer science from Virginia Tech.

Jason McKenney is a senior engineering specialist in the Software Systems and Acquisition Department at The Aerospace Corporation. He has more than 20 years of experience with software development, integration, and test activities. Most of his career has been spent with commercial firms developing software, designing continuous integration pipelines, and leading small teams. He is a key author of a report on Agile ground software system integration and test. He has a BS in telecommunications from the University of Kentucky, and an MBA from California State University – Dominguez Hills.

Originally published in Queue vol. 20, no. 6—
Comment on this article in the ACM Digital Library