关于软件文档的胡思乱想

7月1日，一个自发的非官方技术组织——防务软件工程（俗称“5000圈”“测评圈”）由于行业标准《GJB438C》的征求意见而热闹起来，出现了“弹幕”的效果。为什么会出现这种效果呢？

业内人士均深有体会，现在防务软件工程中文档似乎成为了难点之一。

以作者的理解，文档是信息的载体，它保证信息在两个维度的保持与传递，首先是对象维度（空间界面），市场人员的文档反应了市场需要和用户需求，它是为了将这些信息的状态保持下来，并传递给需求分析人员进行分析，其他文档如：需求规格说明、设计规格说明、测试说明、使用规格说明、技术状态说明、设计报告、测试报告以及各种记录等都是这个目的；第二个维度——时间维度（时间界面），100年前，其实人类世界大部分的信息都是通过文档传递来的，而对于软件来说，这个维度的信息保持与传递决定了软件的使用、维护和进化。

以上的原理大家都是非常了解的，而现在文档所出现的问题却聚焦在“形式”，搞开发的人都知道，文档的形式和内容是统一体而不是两张皮，GJB438的意义也不仅是一个形式规范，同时也是一个内容指南。

介质——

纸？

电？

生物介质？

表述形式，这涉及到了信息表达形式，这里会有自然语言（中文／英文／法文……）、平面图、三维模型、时序模型、状态机……

平面图

时序模型

状态机

信息特征，这才是核心——形式与内容的统一，拿《软件需求规格说明》举例，应该写什么？哪些必须写？写到什么程度（粒度）？用什么表述形式来表达是充分的、完整的、一致的？

这些并不是通过一个文档形式模版可以定义的，因为它涉及到研发过程定义和过程能力，这导致文档规范不是一种教条的存在，而是需要根据其使用对象进行本地化落地。

那么另外一个问题出现了，这种本地化的做法信息需要者是否接受？

防务软件工程领域文档的接受者是谁呢？吊诡的是，当前软件开发者对于文档的需求并不迫切，而对于软件文档提出严格要求的用户却不是真正文档的使用者（用户文档除外），软件开发者自然会觉得在文档上投入的大量时间就是浪费时间，我们可以理解用户或者管理层从CM（Configuration Management）角度考虑文档的重要性，但是却往往是关注了形式而失去了实质——通过评审纳入配置管理的文档仍然不能保证与软件程序的一致性。

大量的事实证明，文档工作是可以通过自动化手段完成的，而软件工程师更多的是关注需求分析、设计实现、验证确认，用现在时髦的MBSE（基于模型的系统工程）其实软件全生命周期都可以使用模型表达，那么文档可以说完全可以自动化生成，那么也很方便的解决了需求管理的问题，软件的充分性和完整性、一致性、正确性都可以通过模型仿真、形式化证明等方法来验证，而不是通过审查成千上万页难以溯源的文档来验证，我希望这一天早点来到。这是很多软件工程工具厂商应该关注的一个增长点（拿走不谢😄）