Merge branch 'master' of 118.25.96.118:/home/git/ParnasClements1986

1 files changed, 146 insertions, 173 deletions

diff --git a/parnas-a-rational-design-process.rst b/parnas-a-rational-design-process.rst
index c713ccd..1067296 100644
--- a/parnas-a-rational-design-process.rst
+++ b/parnas-a-rational-design-process.rst
@@ -17,8 +17,7 @@
 通篇总结
 -------------------------------------------------------------------------
 
-伍泰炜 OK
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+伍泰炜
 
 读完全文之后，我感觉作者能把前面十几页的内容写出那么多字，真是十分了不
 起，可能这就是科研工作者的特长吧，把一个东西反复讲述，使得论文的篇幅变
@@ -61,8 +60,7 @@
 Page 1
 ------------------------------------------
 
-徐梦旗 OK
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+(徐梦旗 翻)
 
 理性设计过程: 如何、为何要仿制它
 
@@ -79,11 +77,10 @@ Page 1
 
 
 
-Page 2
+Page 2 
 ----------------------------------------------------------
 
-田遍地  OK
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+(田遍地  翻)
 
 ... 理性设计过程: 如何、为何要仿制它
 
@@ -108,11 +105,10 @@ I. 寻找哲人之石： 为什么要理性设计过程？
 
 
 
-Page 3
+Page 3 
 -----------------------------------------------
 
-徐闰钞 OK
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+(徐闰钞 翻)
 
 （所有可以被归类为“自顶向下”的方法都是我们希望有一种合理又系统的软件设计方法的结果。）
 
@@ -145,11 +141,10 @@ II. 为什么软件设计“过程”总是理想化？
 
 
 
-Page 4
+Page 4 
 -------------------------------------------------------------------
 
-吴贞娴 OK
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+(吴贞娴 翻)
 
 5. 用人就会有人为错误。无论我们的决策过程多么理性，无论我们的相关事实
    收集和组织多么好，我们都将会犯错。
@@ -179,11 +174,10 @@ III . 尽管如此， 为什么描述理性理想化过程是有用的呢?
 
 
 
-Page 5
+Page 5 
 ---------------------------------------------------------------
 
-余慧  OK
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+(余慧  翻)
 
 （与吴贞娴翻译的最后一段同： 上文所提及的内容，很明显为每个深思熟虑过
 的人所知、为坦诚的人所承认。尽管如此，我们仍旧能看到以软件设计过程为主
@@ -215,11 +209,10 @@ Page 5
 
 
 
-Page 6
+Page 6 
 --------------------------------------------------------------------------
 
-魏含饴 OK
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+(魏含饴 翻)
 
 5． 外部人员对项目进展定期审查对良好的管理不可或缺。 如果项目试图紧随
     理想过程，审查就会更容易。
@@ -254,17 +247,18 @@ V． 理性设计过程是什么？
 每一个工作产品的审查以及对生成的可执行代码的测试。
 
 
-Page 7
+Page 7 
 ---------------------------------------------------------------------
 
-叶红霞 OK
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+(叶红霞 翻)
 
 （在实施本文描述的过程时，我们对每一个工作产品进行了广泛而系统的审查，
 并对生成的可执行代码进行了测试。）
 
 
-A. 建立并记录需求
+A.  建立并记录需求
+````````````````````````````````````````````````````````````````````````````````
+
 
 
 要成为理性的设计师， 为了成功，我们必须知道我们必须做什么。  我们将其
@@ -296,8 +290,7 @@ A. 建立并记录需求
 Page 8
 --------------------------------------------------------------------------
 
-王如韵 OK
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+(王如韵 翻)
 
 - 它可以解决争议; 我们不再需要成为应用程序专家或咨询应用程序专家。
 
@@ -324,131 +317,118 @@ Page 8
 
 
 
-Page 9
+Page 9 
 ---------------------------------------------------------------------
 
-蒋佳玲 OK
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
+(蒋佳玲 翻)
 
 我们通过把关注点分离（ **Separation of Concerns** ）到章节，来获得需求
 文档的完整:
 
-—— 指定软件运行的机器。 机器不必是硬件 —— 对于一些系统，这一节可能仅仅
-   包含语言参考手册的名字；
+- 指定软件运行的机器。 机器不必是硬件 -- 对于一些系统，这一节可能仅仅包含语言参考手册的名字；
 
-—— 指定软件与外界通信必须使用的接口；
+- 指定软件与外界通信必须使用的接口；
 
-—— 对于每个输出，指定所有情况下的值（用软件可检测到的系统状态表示）；
+- 对于每个输出，指定所有情况下的值（用软件可检测到的系统状态表示）；
 
-—— 对于每个输出，指定软件需要多频繁或多快速重新计算它；
+- 对于每个输出，指定软件需要多频繁或多快速重新计算它；
 
-—— 对于每个输出，指定精确度。
+- 对于每个输出，指定精确度。
 
-—— 如果要求系统易于更改，则需求文件必须包括可能发生更改的地方。 你无法
-   设计一个系统，可以让所有东西都同样容易更改。 哪些东西最有可能更改，
-   不应该由程序员判断。
+- 如果要求系统易于更改，则需求文件必须包括可能发生更改的地方。 你无法设计一个系统，可以让所有东西都同样容易更改。 哪些东西最有可能更改，不应该由程序员判断。
 
-—— 需求还必须讨论由于不希望发生的事件发生了，系统无法满足需求时系统应
-   该做什么。 大多数需求文档忽略了这些事件; 它们只讨论当一切都完美的情
-   况，却把出现部分故障时该做什么留给程序员去决定。
+- 需求还必须讨论由于不希望发生的事件发生了，系统无法满足需求时系统应该做什么。 大多数需求文档忽略了这些事件; 它们只讨论当一切都完美的情况，却把出现部分故障时该做什么留给程序员去决定。
 
-我们希望大家清楚，除非定义了每一个需求，否则无法编写正确的软件。 一旦
-成功地指定了每一个需求，您就已经完全指定了系统的需求。
+我们希望大家清楚，除非定义了每一个需求，否则无法编写正确的软件。 一旦成功地指定了每一个需求，您就已经完全指定了系统的需求。
 
 
 
 
-Page 10
+Page 10 
 ----------------------------------------------------------------------------
 
-应舸
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-为了确保文档的统一性和完整性，文档编写的组织过程背后必须有一个简单的数学模型。
-我们的模型是由我们在实时系统上的工作所激发的，但正因为如此，它具有完全一般性。
-所有系统都是实时系统。
-
-我们假设对于实时控制系统，理想的产品不是纯数字计算机，而是由控制模拟计算机的数字计算机组成的混合计算机。
-
-模拟计算机将输入测量的连续值转换为连续输出。当离散事件发生时，数字计算机带来模拟计算机计算功能的离散变化。
+(应舸 翻)
 
-实际系统即是该混合系统的数字近似。
+为确保文档的一致性与完整性， 文档组织结构背后必须有一个简单的数学模型。  我们的模型是由我们在实时系统上的工作所启发的。 但因为所有系统都是实时系统， 它是完全通用的。
 
-与其他工程领域一样，我们首先描述这个“理想”系统，然后指定允许的公差来编写我们的规范。
-在我们的需求文档中，我们认为输出的地位远高于输入。如果我们得到输出值是正确的，那么没有人会介意我们甚至采用不读取输入的方法。
+我们假设， 对于实时控制系统来说，理想的产品不是纯数字计算机，而是混合计算机。 混合计算机由控制模拟计算机的数字计算机组成。  模拟计算机将输入的连续值转换为连续输出。 当离散事件发生时，数字计算机给由模拟计算机计算的函数带来离散变化？？？。 实际的系统是该混合系统的数字近似。  与其他工程领域一样，写软件规范时， 我们首先描述“理想”系统， 然后指定允许的误差。 在需求文档中， 我们认为， 输出重要性高于输入。 如果输出值是正确的，即使我们不读取输入，也没人会介意。 因此，在过程第一阶段，关键是 **识别所有输出** 。 我们的需求文档， 其核心是由表格形式表示的数学函数集合。 每个函数都有一组外部状态变量， 且输出单个值。 文献 [8]中给出了以这种方式生成的完整文档例子， [9]中对该例子有讨论。
 
-因此，该过程第一阶段的关键是识别所有输出。
+.. _B:
 
-我们需求文档的核心可以被表述为表格形式的一组数学函数。每个函数都将单个输出的值指定为与应用程序相关的外部状态变量的函数。
-以这种方式生成的完整文档的一个例子，我们将在本文[9]中给出并在[8]中讨论。
-
-B.设计并记录模块结构
-
-除非产品很小，小到能由单个程序员来做，否则我们必须想一想如何将工作分解为任务，即模块。 此阶段应生成的文档为 **模块指南 (Module Guide)** 。 模块指南定义各模块的职责， 把我们的设计决策 (design decision) 封装在该模块。 模块里可以有子模块，也可以单独作为一个工作任务。
+B. 设计并记录模块结构
+````````````````````````````````````````````````````````````````````````````````
+    
+除非产品很小，小到能由单个程序员来做，否则我们必须考虑如何将工作分解为几个工作任务，即模块。 此阶段应生成的文档为 **模块指南 (Module Guide)** 。 模块指南定义各模块的职责， 把我们的设计决策 (design decisions) 封装在各模块。 模块里可以有子模块，也可以单独作为一个工作任务。
 
 
-Page 11
+Page 11 
 -----------------------------------------------------------------------
 
-徐焕众
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+(徐焕众 翻)
 
 模块指南用来避免重复，避免空隙，实现 **关注点分离 (separation of concerns)** 。 最重要的， 当产品有问题时， 用来帮助维护人员找出对应的模块。 记录设计决策的文档与在维护阶段使用的文档是同一个文档。
 
 如果我们努力地将信息隐藏 (information hiding) 或 关注点分离 (separation of concerns) 应用于大型系统，那么肯定会产生大量模块。 没有其他结构，只是简单列出模块名的指南，只对熟悉系统的人有帮助。 而我们的模块指南是树形结构的， 它将系统划分成几大模块，并以相同的方式细分每个模块，直到所有模块都非常小为止。 这种文档的例子， 参见[3]。 对这一办法及其好处的讨论，参见[15，6]。
 
 C. 设计并记录模块接口
+````````````````````````````````````````````````````````````````````````````````   
 
-高效快速的软件生产需要使程序员能独立工作。 模块指南定义了模块职责，但没有给出足够的信息使得每个人能去独立实现模块。 为此，每个模块必须指定精确的接口。 每个模块都必须有 **模块接口规范 (Module Interface Specification)** ； 规范必须正式，并提供每个模块的黑箱图片 (black box picture)。 规范由资深设计师撰写， 并由接口实现者与接口使用者一起评审。 一个模块的接口规范只需包含足够使其他模块的程序员使用该模块功能的信息， 而不需要其他信息。 接口实现者也需要 **模块接口规范** 。·
+高效快速的软件生产需要使程序员能独立工作。 模块指南定义了模块职责，但没有给出足够的信息使得每个人能去独立实现模块。 为此，每个模块必须指定精确的接口。 每个模块都必须有 **模块接口规范 (Module Interface Specification)** ； 规范必须正式，并提供每个模块的黑箱图片 (black box picture)。 规范由资深设计师撰写， 并由接口实现者与接口使用者一起评审。 一个模块的接口规范只需包含足够使其他模块的程序员使用该模块功能的信息， 而不需要其他信息。 接口实现者也需要 **模块接口规范** 。· 我们写的文件由两者使用。
 
 
-Page 12
+Page 12 
 ------------------------------------------------------------------------------
 
-何可人 
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+(何可人 翻)
 
-我们生产的文件由两者使用。
-虽然，每一此类文件都由一个人专门负责，但它们实际上是由那些负责实现这些模块的人，使用这些模块的人以及对这个模块的设计感兴趣的其他人，例如：评审，谈判产生的。这些规范的主要内容有：
--  一系列可被其他模块用程序（被称为“访问程序”）调用的的程序。
--  这些访问程序的参数。
--  这些访问程序对彼此的影响。
--  必要时的时序约束和精度限制。
--  不期望事件的定义（禁止发生的事）
-在许多方面，这个模块的规格类似于要求文件。但是，符号和组织的使用更适合于我们在这个过程中所关注的软件到软件的接口。
-已发表的例子和解释包括[Ii]，[2]，[i]，[5]。
+虽然，每人负责写一个文件， 但这些文件实际上是在模块实现者、模块使用者， 对模块设计感兴趣的人（如审稿人）商议过程中产生的。  这些规范文件的主要内容有：
 
-D.	设计并记录模块的内部结构
+-  被访程序 (access program)： 可被其它模块中的程序调用的程序列表。
 
-一旦指定了模块接口，其实现可以作为独立任务被执行，但评论除外。但是，在我们开始编码之前，我们希望在模块设计文档中记录主要的设计决策。这个文档旨在开始编码前对设计进行有效的检验，并向未来的维护程序员解释代码背后的意图。
-在某些情况下，模块只是被简单地分成一个个子模块，而设计文档被当制作是另一个模块指南。在这种情况下，该模块的设计过程应在上面的步骤B处重新开始。而在其他情况下，我们首先应描述其内部数据结构；
+-  被访程序的参数。
+   
+-  被访程序对彼此的影响。
+   
+-  时间约束与精度约束 （如果需要）。
+   
+-  意外事件 (undesired events) 的定义（禁止发生的事）
+   
+许多方面，模块规范类似需求文件。 但是，模块规范所使用的符号与文档结构更适合描述软件与软件的接口。 已发表的例子和解释有 [11]，[2]，[1]，[5]。
+
+
+D. 设计并记录模块内部结构
+````````````````````````````````````````````````````````````````````````````````      
+
+一旦指定了模块接口， 实现可以作为独立任务去执行。 但是，开始编码之前， 我们想在模块设计文档中记录主要的设计决策。 这个文档允许我们编码前对设计有效的评审， 并向未来的维护程序员解释代码背后的意图。
 
+在某些情况下， 模块只是被简单地分成几个子模块， 设计文件是另一个模块指南。 在这种情况下，该模块的设计过程在上面的步骤 B_ 处继续。 
 
-Page 13
+
+Page 13 
 -------------------------------------------------------------------------------
 
-袁世家
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+(袁世家 翻)
 
-在另一些情况中，我们从描述内部数据结构开始；还有一些情况是，数据结构被子模块使用（和隐藏）。对于每一个访问函数，我们引用一种函数或者描述数据结构上的影响的LD关系。对于每一个模块所返回给使用者的数值，我们都提供了另一种数学函数，这个抽象函数将数据结构的值和其返回值一一对应。对于每一个不确定的事件，我们描述了怎样去检查它。最后，我们还提供了一种证明方法，这种使用此类性质来编程的观点可以满足模型的规格。
+在另一些情况下，我们从描述内部数据结构开始； 还有一些情况是， 这些数据结构被子模块实现（并隐藏）。 对于每个被访程序，我们包括一个函数 [1] 或者 LD-关系 [14], 用来描述对数据结构的影响。 对于模块返回给调用者的每个数值，我们提供叫做抽象函数的数学函数，这个函数将数据结构的值映射到返回值？？？。 对于每个意外事件， 我们描述了怎样去检查发现它。 最后，我们还提供一个"验证"， 一个拥有这些属性的程序会满足模块说明的论据？？？。
 
-我们继续分解子模块，直到每个工作任务小到我们能够忽略它，并且当程序员离开该工程后可以继续工作。
-如果我们不能编写一个可读的高级语言，例如，如果没有可用的编译器，我们使用伪代码作为文档的一部分。我们发现由另外某个人写伪代码而不是最终的程序员写代码，并且让两个程序员负责两种代码的连贯性是很有用的。
+**继续分解设计子模块，直到每个工作任务足够小， 小到万一负责这个模块的程序员离开项目， 我们也可以承担丢弃它并重新开始的代价** 。
 
-E  设计并且记录使用层次结构
+如果无法用易读的高级语言编程，例如，如果没有可用的编译器，就把伪代码作为文档的一部分。 写伪代码的不是最终程序员， 并让他与最终程序员负责确保两种代码一致。 这么做很有用 [7]。
 
-一旦我们知道所有的模型和它们的许可程序，就可以设计使用的层次结构。他被方便地记录为二进制矩阵，当且仅当位置（a,b）的入口为真，程序A的正确性取决于系统中是否存在正确的程序B。使用层级结构定义了可以由删除整个程序并且没有重写任何程序获得的子集。这对于分阶段递交，故障弱化系统，和程序集合的发展很重要。
+E. 设计并且记录使用层级 (uses hierarchy)
+````````````````````````````````````````````````````````````````````````````````         
+一旦知道所有的模块与它们的被访程序， 就可以设计使用层级。 为记录方便， **用一个真值矩阵表示使用层级** ，当且仅当程序A的正确性取决于程序B的正确性， 矩阵的（A,B）位置为真。 使用层级定义了一组子集组成的集合， 这个集合可以由删除整个程序并且不需要重写任何程序获得。 使用层级对于分阶段交付， 软失败(fail-soft)系统，和开发程序家族很有用。
 
+（蓝珲的理解： 文中提到的程序， 容易引起混淆， 其实就是模块。 真值矩阵其实描述了模块之间的依赖关系。 例如， 有1,2,3,4四个模块， 3依赖1, 1依赖2, 2依赖4。 {4}, {2,4}, {1, 2, 4}, {3,1,2,4} 这些子集都可以组成独立程序。）
 
 
-Page 14
+Page 14 
 ------------------------------------------------------------------------------
 
-陈肖飞 OK
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+(陈肖飞 翻)
 
 F. 编写程序
+````````````````````````````````````````````````````````````````````````````````
 
 在设计和文档编制完成后，我们就可以编写代码了。我们发现这件事进展的迅速
 而顺利。我们认为，代码注释不应该包含文档中已经有的内容。否则，系统维护
@@ -475,11 +455,10 @@ A． 当前的文档有什么问题？ 为什么它不便使用？ 为什么它�
 
 
 
-Page 15
+Page 15 
 ----------------------------------------------------------------------------
 
-陈俊蕾 OK
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+(陈俊蕾 翻)
 
 文档中多余的注解是没必要的，且会使系统维护变得更加昂贵。 除此之外，还
 会增加代码与原文档不符的可能性。
@@ -505,70 +484,66 @@ VI. 文件在此过程中充当什么样的角色？
 
 
 
-Page 16
+Page 16 
 ------------------------------------------------------------------------------
 
-王海榕
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+(王海榕 翻)
 
 如何避免这些问题？
 
-文档在理想的设计过程中满足了开发人员和后期维护程序员的需求。上面提到的
-每个文档都记录了设计决策，并作为设计其余部分的参考文档。但是，它们也提
-供了维护人员所需要的信息。由于这些文档在整个软件构建过程中都被用作参考
-手册，因此它们将是成熟的，可以在以后的工作中使用并且始终是最新的。我们
-设计过程中的文档不是事后才想到的;它被认为是项目的主要产品之一。可以使
-用一些检查来增加完整性和一致性。这种文档处理方法的一个主要优点是改善了
-神话中的人月效应[4]。当新程序员加入项目时不需要依赖老员工为他们提供项
-目信息。他们将拥有一个最新的和理性的可用文档集合。我们通过花费大量精力
-设计每个文档的结构来避免“意识流”和“执行流”文档。我们通过声明文档必须回
-答的问题来定义文档并将这一原则贯彻到各个部门。我们试图为每一个必须包含
-的事实找到一个位置，并确保只有一个这样的位置。只有在确定了文档的结构之
-后，我们才开始编写它。如果我们编写许多特定类型的文档，我们就为这些文档
-编写并发布一个标准组织[5]。我们所有的文档都是按照指导软件设计的相同原
-则设计的，即关注点分离。系统的每个方面都在一个部分中描述，而在该部分中
-没有其他内容。当审查我们的文件时，我们会审查它们是否符合文件规则以及是
-否具有准确性。
-
-
-
-Page 17.a
+理想设计过程中， 文档既满足了开发人员需求， 也满足了维护人员的需求。上
+面提到的每个文件都记录了设计决策，并在剩余的设计中作为参考文件使用。
+这些文件也提供了软件维护人员所需要的信息。由于这些文件在整个软件开发过
+程中被用作参考手册，因此它们将是成熟的，并且已经准备好在以后的工作中被
+用到。 这些文件总是及时更新的。 在我们设计过程中， 文档不是事后才想到
+的产品; 而是被看作是项目的主要产品之一。 一些检查可用来增加其完整性和
+一致性。
+
+这种产生文档的方法，其主要优点是可以减轻 **神话的人月效应 (The
+Mythical Man Month effect)** [4]。 当新人加入时, 不需要依赖老员工来提
+供项目信息。 因为新人拥有一个最新的且理性的文件集。
+
+为避免“意识流 (stream of consciousness)”和“执行流 (stream of
+execution)”， 我们花大力气来设计每个文件的结构。 通过声明文件必须回答
+的问题, 我们来定义文件； 我们将这一原则贯彻至文件的每小节。 在文件中，
+我们试图为每一个必须要包括的事实找一个位置，并确保只有一个这样的位置存
+在。 只有在确定了文件的结构之后，我们才开始写。 如果我们要写许多特定类
+型的文件，我们就为它们编写并发布一个标准结构[5]。 我们所有的文件都是按
+照与指导软件设计相同的原则来设计的，即关注点分离。 我们要开发的系统的
+每个方面都只在一节中描述， 且在该节不含其他内容。 当我们的文件被审查时，
+我们会审查它们是否符合文档规则以及是否准确。
+
+
+
+
+
+Page 17 
 --------------------------------------------------------------------------------
 
-周佳威 
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-这样生成的文档既不简单也不轻松，但也不枯燥。我们利用表格、公式和形式符
-号来增加信息的密度。我们的组织规则防止了信息重复，其结果是文档化，必须
-非常认真地阅读，但回报读者详细和准确的信息。为了避免传统文档中出现混淆
-和不一致的术语，我们使用了特殊括号和类型化字典系统。我们必须定义的许多
-术语中的每一个都包含在一对显示其类型的括号符号中。对于每个这样的类型，
-我们都有一个只包含该类型定义的字典。虽然刚开始阅读的读者会发现!+terms+l、
-%terms%、#terms#等符号的存在，但是令人不安的是，像我们这样文档的普通用
-户会发现括号中隐含的类型信息使文档更容易阅读。使用由类型构成的字典使我
-们不太可能为同一个概念定义两个术语，或者为同一个术语赋予两个含义，同时
-特殊的括号符号使对已介绍但未定义或已定义但从未使用过的术语进行机械检查
-变得很容易。现在，我们如何伪造理想过程?
-
-上面描述了我们希望遵循的理想流程以及在此流程中生成的文档。我们通过生成
-文档来伪造这个过程，如果我们以理想的方式做事，就会生成这些文档。我们试
-图按我们所描述的顺序制作这些文件。如果我们不能得到一条信息，我们就会注
-意到在文档的一部分中，信息应该去哪里并继续设计，就好像该信息会按照预期
-发生变化一样。如果发现错误，我们将更改它们，并在随后的文档中进行相应的
-更正。我们将文档作为设计的媒介，在所有级别的设计决策都被批准纳入文档之
-前，不会考虑任何设计决策。无论我们在途中遇到多少困难，最终的文档都将更
-容易理解和适应。我们没有展示事情实际发生的方式，我们展示的是我们希望事
-情发生的方式和事情的方式。
-
-
-Page 18
------------------------------------------------------------------------------------
+(周佳威 翻)
+
+这样生成的文档读起来不容易、不轻松，但也不枯燥。 我们用表格、公式和正式符号来增加信息密度。 我们文档结构规则避免了信息重复。  这样的文档必须聚精会神地读， 但是会回馈给读者以详细准确的信息。
 
-方梓安 OK
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+为避免传统文档遍布着混淆的与不一致的术语的情况， 我们用一种由特殊括号与类型字典组成的术语系统。 每个必须定义的术语都被嵌在一对括号符号中， 括号符号反应了术语的类型。  对每个类型，我们有一个字典， 字典包含了对该类型的定义。 虽然刚开始阅读我们文档的读者会觉得 !+terms+!、 %terms%、 #terms# 这些符号干扰了阅读， 但是经常读我们文档的用户会觉得这些特殊括号隐含的类型信息反而会使阅读变容易。 类型字典减少了我们为同一个概念定义两个术语， 或者为同一个术语给出两个定义的可能。 特殊括号对已经引入但但未定义， 或已定义但从未使用过的术语进行机械检查变得容易。
 
+.. 上面描述了我们希望遵循的理想流程以及在此流程中生成的文档。我们通过生成
+   文档来伪造这个过程，如果我们以理想的方式做事，就会生成这些文档。我们试
+   图按我们所描述的顺序制作这些文件。如果我们不能得到一条信息，我们就会注
+   意到在文档的一部分中，信息应该去哪里并继续设计，就好像该信息会按照预期
+   发生变化一样。如果发现错误，我们将更改它们，并在随后的文档中进行相应的
+   更正。我们将文档作为设计的媒介，在所有级别的设计决策都被批准纳入文档之
+   前，不会考虑任何设计决策。无论我们在途中遇到多少困难，最终的文档都将更
+   容易理解和适应。我们没有展示事情实际发生的方式，我们展示的是我们希望事
+   情发生的方式和事情的方式。 (见下文方子安处）
 
-vii. 如何假装理想的过程？
+
+Page 18 
+-----------------------------------------------------------------------------------
+
+(方梓安 翻)
+
+VII. 现在， 如何假装理想的过程？
+``````````````````````````````````````````````````````````````````````````````     
 
 上文描述了我们希望遵循的理想过程，以及这一过程所产生的文档。 我们通过
 产生文档来假装这个过程。 我们用上文描述的顺序去试着产生一系列文件。 如
@@ -596,27 +571,25 @@ vii. 如何假装理想的过程？
 
 
 
-Page 20
+Page 19 
 ----------------------------------------------------------------------------------
 
-刘莉莉
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-从这个过程得到回报的例证是由我们几年前写的软件需求文档提供的，其作为理
-想过程演示的一部分[9]。通常，人们认为需求文档在编码开始之前就生成了，
-并且不会再使用它。然而，事实证明并非如此。那些满足我们的要求文件的软件，
-它的原始版本仍在进行修订。每次更改后就必须测试软件的组织，都会广泛使用
-我们的文档来选择他们所做的测试。当需要进行新的更改时，需求文档用于描述
-那些必须更改的内容和不能更改的内容。在软件投入使用后，该过程中生成的第
-一份文件一直被使用了很多年。可以明确的是，如果一个文档是经过精心制作的，
-那么它将在很长一段时间内发挥作用。相反，如果它将被广泛使用，那么正确的
-制作是值得的。成为一个理性的设计师是非常困难的，而且我们可能永远不能实
-现它。在我们尝试遵循这个过程的过程中，我们经常发现我们继承了一个由于未
-知原因而做出的设计决策的地方。例如我们想要使用的等式中常量的值。当我们
-要求推导常量时，我们发现它不存在或推导无效。当我们进一步按下时，我们被
-告知该决定是“因为它有效”。在这种情况下，设计师可以打开一个研究项目，找
-出它的工作原理，或者只是“继续使用它”。那些为我们工作付钱的人已经使用
-“GOWI”这样的标准回答去解决许多此类问题，并且我们并不认为真正的工作会有
-所不同。然而“因为它们起作用”，所以无论我们做出哪些决定，我们都会对我们
-的决定记录诚实的理由，而不是误导未来的维护者认为我们对我们所做的事情有
-深刻的哲学理由。
+(刘莉莉 翻)
+
+几年前我们写了一个软件需求文件，作为对理想过程演示的一部分，这个需求文件说明了这个过程是值得的[9]。  通常，人们认为需求文件是在编码前写成的， 编码完成后就不会再被使用了。 然而，事实证明并非如此。 那些满足我们的需求文件的软件， 它的初始版本仍在被修订。  每次更改软件后， 软件测试机构大量使用这个需求文件来选择他们的测试。 当需要新更改时， 用需求文件描述什么必须被改变、什么必须不变。  软件投入使用很多年后， 该过程中产生的第一份文件至今还在被使用。 可以明确的是，如果文件是经过精心制作的， 它将在很长时间内都有用。 如果文件将被大量使用，那么正确制作它很值得。
+
+成为一个理性的设计师很难，而且我们可能永远做不到。  在我们尝试遵循这个过程当中，我们常发现继承了某设计决策， 却不知道当初决策者的之所以决定的理由。  一个例子是等式中常量的值。当我们要常量的推导过程时， 我们发现它不存在、或者原先推导是不正确的。  当进一步追问时，我们被告知做这个决策是 “因为它起作用 ( **because it works** )”。  在这种情况下，设计师可以去研究它起作用的原因， 或者就简单地 “与它友好相处 ( **Get On With It (GOWI)**) ”。 给我们的工作付钱的人把 **GOWI** 作为对许多此类问题的标准回答。 我们并不认为真正的工作会有所不同。 然而， 每当我们把“因为它们起作用”作为决策理由时， 我们就诚实地把这个理由写下来， 以免误导将来的软件维护者去花心思想在我们的决策后面有什么深刻的理由。
+
+
+Page 20 
+----------------------------------------------------------------------------------
+
+(蓝珲 翻)
+
+**致谢**
+
+NRL的Stuart Faulk与John Shore为这篇文章提供了经过深思熟虑后的评论。
+
+美国海军与加拿大NSERC对本研究提供了资助。
+
+