PDF给仍然不理解的项目经理的三部和声
开源软件、开放标准和敏捷软件开发
格内弗·奥尔德里奇，丹尼·曾，杰森·麦肯尼
在我的钢琴键盘上并排... 保罗·麦卡特尼在歌曲《黑檀木与象牙》中写到了两部和声。
歌词可以应用于美国国防部（Department of Defense，DoD）的系统采购，这与商业软件产品开发截然不同。对于国防部而言，严苛的需求、利益相关者的支持以及较长的开发周期不仅仅需要两部和声；需要整个合唱团同心协力，才能交付通常运行数十年的强大系统。
本文探讨了系统采购工具箱中的三种工具，它们可以协同工作以加快开发和采购速度，同时降低项目风险：OSS（开源软件）、开放标准和敏捷/Scrum软件开发流程，这些都是国防部采购项目管理工具箱的强大补充。ii
与所有工具一样，拥有工具而不需使用，总比需要工具而没有要好。
正如商业世界几乎在日常生活的方方面面都依赖软件一样，国防部也是如此。因此，快速开发、集成和部署软件到新的和现有的军事系统中，是美国保持对同侪和近同侪对手技术优势的关键组成部分。
根据一位美国国防部在国会山官员的说法，国防部2018年网络战略“优先考虑大国竞争的挑战，并认识到国防部必须向前防御，以对抗美国竞争对手旨在获取政治、经济和军事优势的长期、协调一致的恶意活动”。4 除了向前防御，网络战略还推动了加快系统开发和部署的流程。
在网络战略的基础上，并着眼于加快开发、集成和部署基于软件能力的能力，国防部副部长办公室2022年2月的一份备忘录，题为“国防部软件现代化”，重点是为快速向战场交付能力提供战略。“国防部的适应性越来越依赖于软件，安全且快速地交付弹性软件能力的能力，将是决定未来冲突的竞争优势。”27
开源软件
2018年国防部网络战略指示软件采购应优先考虑OSS，这是有充分理由的：如果使用得当，OSS可以降低长期风险，并成为通过帮助防止供应商锁定来降低维护成本的工具，开放标准也是如此。重要的是要注意，开源软件与开放标准不同，这将在下一节中讨论。
OSS通常指的是可以自由修改和再分发的软件源代码。对于开源软件，没有普遍认可的定义；本文采用国防部的官方定义：“软件，其人类可读的源代码可供该软件的用户使用、学习、重用、修改、增强和再分发。”26
软件许可非常重要——它不仅保护开发者的知识产权，还确保客户获得他们合同约定的支持。OSS通常根据许多可用的开源许可证之一进行许可。以下是最常见的许可证（和许可证系列），按从最不宽松到最宽松的顺序排列
• GNU GPL（通用公共许可证） – 软件和其他类型作品的免费著作权共有iii许可证。GPL旨在保证共享和更改程序所有版本的自由——以确保它始终是所有用户的自由软件。8
• MIT许可证 – 麻省理工学院在1980年代后期开发的宽松iv自由软件许可证。作为一种宽松许可证，它对重用施加的限制非常有限，并且与GNU GPL兼容。13 MIT许可证和GNU GPL之间的区别在于，它允许在专有软件中重用软件。
• BSD（伯克利软件发行版） – 一系列宽松的自由软件许可证，对受保护软件的使用和分发施加的限制最少。这与著作权共有许可证（GPL和MIT）不同，后者具有相同方式共享v要求。15
• Apache – 也是一种宽松的自由软件许可证，由Apache软件基金会起草。它允许将软件用于任何目的，分发和修改它，以及分发修改后的版本。1 Apache与MIT和GPL许可证之间的区别在于：（a）Apache包含专利许可证和报复条款12，并且（b）它不是著作权共有许可证。
通常，以开源许可证发布的软件鼓励分散式开发和开放协作，这可以加快开发过程。根据许可证的不同，关于链接、再分发、修改和私人使用，存在不同程度的宽松性。vi
国防部专注于OSS也存在缺点，安全是最明显的。在任务关键型系统中使用外部开发和维护的软件代码产品，可能会通过为对手引入有害或恶意代码到军事系统提供途径，从而造成安全风险。一个不太明显的风险是，共享专门为国防部开发的代码可能会泄露对国家防御至关重要的关键创新。21
与恶意代码被引入系统相关的风险可以通过对安全漏洞进行彻底评估来降低，并通过使用学术上严谨的流程在整个生命周期中进行管理。当前国防部的流程称为SCRM（供应链风险管理vii）。SCRM被国防部定义为“通过识别、评估和减轻从始至终对国防部供应链的威胁、漏洞和中断来管理风险的过程，以确保任务效能”；25 NIST（美国国家标准与技术研究院）的新出版物《系统和组织的网络安全供应链风险管理实践》3为开发人员和供应商提供了软件供应链安全指南，内容包括最佳实践和安全评估。
通过实施NIST的C-SCRM（网络安全-SCRM）计划23，软件风险得到了进一步降低。具体实践包括在整个企业中集成C-SCRM；建立正式计划；了解和管理关键产品、服务和供应商；了解企业的供应链；与关键供应商密切合作；将关键供应商纳入弹性和改进活动；评估、审计、与所有供应商（而不仅仅是大型供应商）持续且一致地沟通；以及协作规划系统的整个预期生命周期。作为供应商关系的一部分，与供应商和第三方供应商的合同应包括旨在满足企业C-SCRM计划要求的措辞。
第二个风险，共享专门为国防部开发的代码，可以通过使用MOSA（模块化开放系统方法）来降低，以防止关键的国防创新泄露给对手。MOSA“是一种综合的业务和技术战略，旨在在系统生命周期内实现有竞争力和负担得起的采购和维护”。24 这种系统采购方法创建了一个可分离模块的架构，这些模块可以由多个供应商开发，并允许保护关键模块，从而在允许国防部从OSS中获益的同时，降低暴露给对手的风险。这些模块通常是专有和OSS的混合，可以在主要系统平台的整个生命周期中逐步添加、移除或替换，从而为增强竞争和创新提供机会。21
OSS是国防部采购剧本中的重要工具；如果使用得当，它有助于创建竞争环境，并允许长期使用的国防系统通过缩短开发、集成和实施周期时间来跟上技术的快速发展。关键在于最初正确评估OSS的安全漏洞，并创建一个采购和维护环境，在该环境中，软件和安全人员进行持续评估。
开放标准
为了保持并行性，我们本想以BBC的最佳二重唱开始本节；但“雾蒙蒙的露水”viii 实际上并不适合讨论开放标准。开放软件标准是采购项目经理的另一个重要工具。这些标准向公众开放，并通过正式的协作和共识驱动的过程开发（或批准）和维护。它们专门设计用于促进互操作性和数据交换，并旨在广泛采用。与OSS一样，对于开放标准，没有普遍认可的定义，因此在这里我们使用W3C（万维网联盟）的定义：任何人都可以公开访问和使用的标准。许多其他组织都有包含相同或相似原则的定义，28 包括：OpenStand，17 国际电信联盟，11 开源倡议，14 和欧洲自由软件基金会。7
W3C确保其标准可以无版税使用。这意味着它不受使用费的约束，因此，买家倾向于使用它们，因为人们相信它们在系统的整个生命周期内会更便宜。由于网络效应ix 和供应商之间竞争的加剧，它们还可能为访问提供多种实现方式，包括商业和开源。10 多种实现方式可以降低采购项目中供应商锁定的风险。常见的开放标准示例包括：XML（消息传递）、HTML（互联网显示）和SQL（数据库）。
在国防采购中使用开放标准的另一个好处是简化开发和互操作性。国防部系统需要在系统和子系统之间，以及在整个生命周期（从开发到处置）中具有互操作性。开放标准专门旨在建立使应用程序可互操作的协议，这使开发更有效率，并且它们通过提高跨边界交换数据的能力来帮助消除供应商锁定。22 可以合理预期供应商在国防部项目的系统生命周期中来来往往；开放标准是帮助确保数据免受过时或弃用x 应用程序影响的一种方法，因为它们可以重新实现以确保持续可访问性。16
回到围绕开发、维护和更新开放标准的流程：W3C的开放标准流程是严格且不断发展的，以满足成员的需求，并且专注于创建促进公平、响应性和向前发展的正式指南。根据W3C的说法，技术规范要被定义为开放标准，必须满足以下一系列要求：20
• 透明性。 所有技术讨论、正当程序和会议记录均存档，并在决策中可参考。
• 相关性。 新的标准化取决于对市场需求的分析。
• 开放性。 任何人都可以参与：个人、行业、公众、学术界和政府。
• 公正和共识。 通过流程保证公平性，并权衡每个参与者的担忧。
• 可用性。 免费访问标准文本和清晰的实施规则。
• 维护。 持续的修订、更正和测试过程。
EXI（高效XML交换）和谷歌的协议缓冲区（Protobuf）标准提供了开放标准和专有标准之间的比较。EXI是一种开放标准，用于以二进制格式表示XML数据，并受上述W3C要求的约束。Protobuf是一种开源（非开放标准）数据格式，用于服务器间通信和数据存储；它由谷歌开发，目前主要为满足谷歌的需求而维护，尽管谷歌在GitHub上提供了源代码，个人或团队可以在论坛上讨论建议或功能，或提交代码合并请求；但是，关于合并更改的任何决定最终都由谷歌的开发团队决定。9
正式的W3C流程和经过调整的谷歌流程之间的这种划分，是真正开放标准和为单个组织设计的专有标准之间的区别。重要的是要注意，EXI并非因为它是开放标准就“优于”Protobuf。但是，为了与当前的国防部采购指南保持一致，项目应在可能的情况下评估并考虑利用开放标准26。
国防部采用EXI等开放标准的一个主要好处是，它可以成为利益相关者并为标准定义过程做出贡献。Protobuf标准由谷歌维护，国防部不太可能（如果必要）参与标准的开发过程。如果开放或专有标准由于过时的技术或业务失败而不再维护，那么国防部承担开放标准的维护可能比专有标准更具成本效益。
开放标准的潜在缺点是，标准的更新可能会在审批过程中丢失，或者对时间敏感的更改可能需要太长时间才能完成共识过程。
总而言之，第二佳二重唱xi 是流浪者乐队的“纽约童话”，它也不适用于讨论开源软件或开放标准。第二差二重唱——亚瑟·穆拉德和希尔达·贝克演唱的“你是我想要的人”（更广为人知的是音乐剧《油脂》）——确实适合敏捷软件开发：“我感到一阵寒意，它们正在成倍增加；我正在失去控制；因为你提供的力量；它令人兴奋。” 在项目经理的工具箱中拥有如此强大的工具：真是令人兴奋！
敏捷/Scrum软件开发
当保持并行结构时，在项目经理的软件开发工具箱中引入第三个工具（例如：音乐三重奏）时，二重唱就不起作用了。这是一个难题：我个人偏爱英国乐队奶油乐队，而杰森·麦肯尼则偏爱贝多芬的作品1xii，这是一组三重奏。两者都很棒！奶油乐队的最佳歌曲（完全是个人观点）“你的爱的阳光”的歌词，非常符合敏捷软件开发流程：“我已经等了很久；才能到达我要去的地方。” 政府采购一直在寻找和等待强大的工具，这些工具可以使软件开发更加高效和有效。如果使用得当，敏捷流程可以帮助做到这一点。
从头开始，敏捷指的是一系列价值观，这些价值观侧重于开发方和客户之间频繁的沟通，并且还提倡具有更紧密反馈循环的短期迭代开发周期。敏捷xiii 流程基于增量开发步骤。其思想是以部分交付项目，而不是一次性交付。
敏捷开发流程有一套社区内使用的特定术语，以进行高效沟通18，为了有效地讨论敏捷软件开发，需要定义这些术语
• 待办事项列表（也称为冲刺待办事项列表） – 待办事项清单——项目范围内的完整项目列表，按技术领导确定的优先级排序。
• 每日站会 – 在冲刺（见下文）中每天举行的15分钟协调和同步会议，开发团队成员在会上说明他们前一天完成的、影响今天要做的工作、他们将在当天完成的工作，以及他们是否有任何障碍。
• 发布。 下一组要发布的功能的高级时间表。此工件在scrum（见下文）流程之外，但可以提高scrum团队的成功率。
• Scrum。 这些敏捷价值观的实现，其中包含每日站会、用户故事待办事项列表和短期的（一到四周）冲刺。
• 冲刺。 短期的开发周期，团队在其中创建潜在可交付的产品功能。冲刺，scrum术语中的迭代，通常持续一到四周。
• 故事。 可以估算和测试的需求、功能和/或业务价值单元。故事描述了为产品创建和交付功能而必须完成的工作。故事是沟通、计划和谈判的基本单位。
• 故事点。 用于表达对完全实现产品待办事项或任何其他工作所需总体工作量的估计的度量单位。常用比例为一到七个故事点，其中一是最简单的，七是最困难的。
在敏捷软件开发环境中使用scrum非常重要，以至于它值得单独成段（可能还有一首歌）。Scrum提供了一个框架，可以帮助开发团队协同工作。5 Scrum明确承认团队在开始时并没有所有信息，并促进协作。它们由scrum主管领导，旨在成为一种支持工具，通过经验学习，促进团队自组织以有效率地推动问题向前发展，并帮助团队适应不断变化的需求。scrum主管的角色因项目而异，但从最高层面来说，他们是开发团队的指挥。他们消除开发人员道路上的障碍和阻碍xiv，并努力促进不仅是每日站会，还有团队的向前发展。19 他们确保敏捷宣言的宗旨得到满足。
正如敏捷宣言2 中所述，敏捷软件开发流程的主要宗旨之一是，当客户和开发团队能够并且愿意成为协作环境的一部分时，它们的效果最佳。在真正的敏捷软件环境中，重点是做这项工作的人，解决方案是通过不仅在开发团队之间，而且还与客户之间的协作来实现的。简而言之，敏捷开发在共识建立和协作文化（而不是命令和控制文化）存在的环境中蓬勃发展。6
四个关键宗旨中的另一个是：响应变化胜过遵循计划。2 这意味着接受（如果不是欢迎）开发过程中不断变化的需求，即使是在流程后期也是如此。这并不是说接受需求蔓延，而是接受需求变化——这是一个关键的区别。接受需求变更使承包商能够快速发展系统，以确保国防部能够保持对近同侪对手的技术优势。
将敏捷与其他软件开发方法区分开来的第三个宗旨是，关注做这项工作的人以及他们如何协同工作，或者正如宣言所说：个人和互动胜过流程和工具。2 人们响应政府提出的要求，他们开发软件。政府利益相关者和承包公司都需要营造一个重视人才的环境。流程和工具很有价值，但如果没有人工输入，它们就无法响应不断变化的环境，也可能无法满足不断变化的客户需求。
敏捷软件开发的四个宗旨中的最后一个，可工作的软件胜过全面的文档，2 对于国防部来说是一次巨大的文化转变，考虑到国防部系统的寿命（看看B-52或AWACS），这一个宗旨可能没有那么大的价值，因为为国防部生产的系统和软件可能需要持续几代人。然而，简化文档编制和创建更有效的文档编制将是巨大的进步。使用协作和跨职能团队的原则，并在与开发并行创建文档，可以简化整个流程。采用MBSE（基于模型的系统工程）xv 是简化合同要求的文档编制的另一种方式，这种做法已经融入到国防部中。
套用爱莉安娜·格兰德的歌曲“挣脱束缚”中的歌词，这就是我挣脱束缚的部分。国防部和联邦政府的承包模式需要摆脱传统的软件开发方法，开始拥抱更灵活的开发环境，使用真正的敏捷开发流程，而不仅仅是口头上说说而已。更灵活的开发模式将允许需求不断发展以应对当前的威胁，并有可能加快采购流程。
正在取得进展——例如，持续接受和集成MBSE到国防部系统采购中；减少传统的纸质合同交付成果；以及政府采购项目办公室重新调整其团队，以便与系统开发团队更好地协调，从而实现更好的沟通，并减少因误解需求和“锦上添花”而浪费的时间。
没有灵丹妙药。xvi 采购计划中的每个开发决策都涉及权衡。项目经理与开发团队一起，需要沟通并有意识地意识到这些权衡。这三种工具——开源、开放标准和敏捷软件开发——加上良好的沟通，可以确保更有效率和更有效地利用政府资源。
本文真的应该以合唱作品的歌词结尾，这在三位作者之间引起了很多讨论。像“扬起旧战车”这样的船歌？像贝多芬的“庄严弥撒曲”这样的古典作品？还是平克·弗洛伊德的“墙上的另一块砖（第二部分）”？经过多次讨论，我们用格洛丽亚·埃斯特凡的歌词送给大家：走出黑暗；我看到了光明。xvii
脚注
i. 有趣的事实：保罗·麦卡特尼创作“黑檀木与象牙”作为与史蒂夫·旺达合唱的二重唱，这是旺达在英国的第一个冠军单曲。2007年，BBC听众宣布这首歌是有史以来最糟糕的二重唱。
ii. 感谢您阅读脚注。请务必查看参考文献和补充阅读。我们花了很多时间建立一个全面的列表，其中提供了更深入的信息。
iii. 著作权共有是一种授予分发和修改知识产权的权利的做法，但要求在从该财产创建的衍生作品中保留相同的权利。著作权共有以许可证的形式存在，可用于维护从计算机软件到文档、艺术、科学发现，甚至某些专利的作品的版权条件 (https://zh.wikipedia.org/wiki/Copyleft)。
iv. 维基百科对宽松许可证的定义是，那些对如何使用、修改和再分发软件仅施加最低限度限制的许可证，通常包括免责声明 (https://zh.wikipedia.org/wiki/%E9%9D%9E%E4%B8%93%E5%B1%9E%E8%AE%B8%E5%8F%AF%E8%AF%81)。
v. 相同方式共享是一个版权许可术语，用于描述要求作品的副本或改编作品以与原始作品相同或相似的许可证发布的 works 或许可证。著作权共有许可证是具有相同方式共享条件的自由内容或自由软件许可证 (https://zh.wikipedia.org/wiki/%E7%9B%B8%E5%90%8C%E6%96%B9%E5%BC%8F%E5%85%B1%E4%BA%AB)。
vi. 此列表从原始列表截断，原始列表可在 https://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licences 查看。
vii. 国防部对SCRM的方法在国防部指令4140.01（2019）中有详细说明：来自负责采购和维护的国防部副部长的国防部供应链物料管理政策；以及来自首席信息官的 DODI 8500.1，网络安全。
viii. “雾蒙蒙的露水”是一首爱尔兰民谣，记录了1916年的复活节起义，并鼓励爱尔兰人为爱尔兰的事业而战，而不是为大英帝国而战，当时许多人都在第一次世界大战中这样做 (https://zh.wikipedia.org/wiki/%E9%9B%BE%E8%92%99%E8%92%99%E7%9A%84%E9%9C%B2%E6%B0%B4_(%E8%88%9B%E5%85%B0%E6%B0%91%E8%B0%A3))。
ix. 网络效应是一个经济学术语，牛津词典将其定义为一种现象，即产品或服务随着使用人数的增加而获得额外的价值。即时消息和谷歌都经历了网络效应。
x. 弃用是指受支持但不推荐使用的软件或编程语言功能。它是可能会被逐步淘汰的东西，但目前可以使用 (https://www.techopedia.com/definition/24828/deprecated#:~:text=Deprecated%20refers%20to%20a%20software,be%20used%20in%20the%20meantime)。
xi. 最佳和最差二重唱的完整列表可在 http://news.bbc.co.uk/2/hi/entertainment/7031695.stm 找到。
xii. 有趣的事实：作品1献给利希诺夫斯基王子，并于1795年在他的家中首次演出。
xiii. 关于敏捷流程的最佳个人信息来源是敏捷联盟 (https://www.agilealliance.org/)。
xiv. 没有歌曲，而是一部呆伯特漫画 (https://dilbert.com/strip/2017-02-08)——最好的scrum漫画之一。
xv. MBSE是另一篇论文的主题。航空航天公司的洪·卢和斯科特·奈杰尔撰写了一篇很棒的介绍性文章《采购的未来是MBSE》，发表在海军部信息技术杂志CHIPS上 (https://www.doncio.navy.mil/chips/ArticleDetails.aspx?id=15594)。
xvi. 并引用鲍勃·席格和银弹乐队或霍桑高地乐队的歌曲“银弹”中的一句妙语：至少你拥有我的……心。你知道你闪耀得如此明亮。
xvii. 格洛丽亚·埃斯特凡的“走出黑暗”并不是真正意义上的合唱歌曲，但它的确有一个合唱团。
作者格内弗·奥尔德里奇的注释：撰写本文对我这个硬件人员来说帮助很大，我刚接触软件开发管理。丹尼、杰森和我们开发团队的其他成员在向我解释概念（通常是反复解释）方面提供了巨大的帮助。理想情况下，这可以帮助其他仍然不理解的经理。我们都想感谢马克·比斯利，感谢他成为国防部系统中使用开源软件的安全方面的知识源泉，并感谢斯科特·伯贡齐，感谢他成为我们的软件开发专家并回答了很多问题。
参考文献和补充阅读
1. Apache软件基金会。2004年。Apache许可证，版本2.0； https://apache.ac.cn/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. 什么是 Scrum? (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 操作系统 (GNU Operating System). 2007. GNU 通用公共许可证 (GNU General Public License); https://gnu.ac.cn/licenses/gpl-3.0.html。
9. 谷歌 (Google). 贡献 Protocol Buffers (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. 我应该使用哪个许可证? MIT vs. Apache vs. GPL (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). MIT 许可证 (The MIT license); https://open-source.org.cn/licenses/MIT。
14. 开源促进会 (Open Source Initiative). 软件的开放标准要求 (Open standards requirement for software); https://open-source.org.cn/osr。
15. 开源促进会 (Open Source Initiative). 3 条款 BSD 许可证 (The 3-clause BSD license); https://open-source.org.cn/licenses/BSD-3-Clause。
16. OpenStand. 2014. 开放标准对应用程序开发至关重要的 5 个理由 (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. 那么 scrum master 是做什么的呢? (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. 高效 XML 交换 (EXI) 格式 1.0 (第二版) (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. 高效 XML 交换与 Protocol Buffers 在通用指挥与控制中的应用 (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. 网络安全供应链风险管理 (C-SCRM) (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 是航空航天公司 (The Aerospace Corporation) 的高级项目主管，她目前正在支持美国国防部 (DOD) 应对为 5G 和其他商业用途重新分配电磁频谱的影响。她曾是一名军官，在国防部武器系统采购方面拥有超过 20 年的经验。她拥有伦斯勒理工学院 (Rensselaer Polytechnic Institute) 的 BS 和 MS 学位；以及空军技术研究所 (Air Force Institute of Technology) 的 MS 学位。
Danny Tsang 是航空航天公司 (The Aerospace Corporation) 软件架构与工程部门的工程专家。他在研究和开发软件原型以改进卫星任务管理和地面处理方面拥有超过五年的经验。他拥有德克萨斯大学圣安东尼奥分校 (University of Texas at San Antonio) 的计算机科学 BS 和 MS 学位，目前正在弗吉尼亚理工大学 (Virginia Tech) 攻读计算机科学博士学位。
Jason McKenney 是航空航天公司 (The Aerospace Corporation) 软件系统与采购部门的高级工程专家。他在软件开发、集成和测试活动方面拥有超过 20 年的经验。他的大部分职业生涯都在商业公司中度过，开发软件、设计持续集成管道以及领导小型团队。他是关于敏捷地面软件系统集成和测试报告的主要作者。他拥有肯塔基大学 (University of Kentucky) 的电信学士学位和加州州立大学多明格斯山分校 (California State University – Dominguez Hills) 的 MBA 学位。
最初发表于 Queue 杂志 第20卷，第6期—
在 数字图书馆 中评论这篇文章
更多相关文章
Amanda Casari, Julia Ferraioli, Juniper Lovato - 超越存储库
关于开源的现有研究大多选择研究软件存储库而不是生态系统。开源存储库通常指的是版本控制系统中记录的工件，偶尔包括围绕存储库本身的交互。开源生态系统指的是存储库的集合、社区、他们的互动、激励机制、行为规范和文化。开源的去中心化性质使得对生态系统进行整体分析成为一项艰巨的任务，社区和身份以有机和不断发展的方式交叉。尽管存在这些复杂性，但对软件安全和供应链日益增加的审查使得在进行关于开源的研究时，采取基于生态系统的方法至关重要。
Jessie Frazelle - 开源固件
开源固件可以通过使固件的行为更加可见并且不太可能造成危害，从而帮助将计算带到一个更安全的地方。本文的目标是使读者感到有能力向可以帮助推动这一变革的供应商提出更多要求。
Marshall Kirk McKusick, George V. Neville-Neil - FreeBSD 5.2 中的线程调度
一个繁忙的系统每秒钟会做出数千个调度决策，因此做出调度决策的速度对于系统的整体性能至关重要。本文——摘自即将出版的书籍《FreeBSD 操作系统设计与实现》——以开源 FreeBSD 系统为例，帮助我们理解线程调度。最初的 FreeBSD 调度器是在 20 世纪 80 年代为大型单处理器系统设计的。尽管它在今天的环境中仍然运行良好，但新的 ULE 调度器是专门为优化多处理器和多线程环境而设计的。本文首先研究了最初的 FreeBSD 调度器，然后描述了新的 ULE 调度器。
Bart Decrem - 桌面 Linux：你在哪里？
桌面 Linux 已经走了很长一段路——而且这是一段过山车般的旅程。在互联网泡沫的顶峰时期，大约在 Red Hat 首次公开募股时，人们期望 Linux 在短时间内在桌面上起飞。几年后，在股市崩盘和几家备受瞩目的 Linux 公司倒闭之后，评论员们很快宣称桌面 Linux 胎死腹中。
© 保留所有权利。