parnas-a-rational-design-process.rst: 添加致谢一节

1 files changed, 12 insertions, 0 deletions

diff --git a/parnas-a-rational-design-process.rst b/parnas-a-rational-design-process.rst
index b6f9001..d1450c2 100644
--- a/parnas-a-rational-design-process.rst
+++ b/parnas-a-rational-design-process.rst
@@ -542,3 +542,15 @@ Page 19 - 刘莉莉 OK
 几年前我们写了一个软件需求文件，作为对理想过程演示的一部分，这个需求文件说明了这个过程是值得的[9]。  通常，人们认为需求文件是在编码前写成的， 编码完成后就不会再被使用了。 然而，事实证明并非如此。 那些满足我们的需求文件的软件， 它的初始版本仍在被修订。  每次更改软件后， 软件测试机构大量使用这个需求文件来选择他们的测试。 当需要新更改时， 用需求文件描述什么必须被改变、什么必须不变。  软件投入使用很多年后， 该过程中产生的第一份文件至今还在被使用。 可以明确的是，如果文件是经过精心制作的， 它将在很长时间内都有用。 如果文件将被大量使用，那么正确制作它很值得。
 
 成为一个理性的设计师很难，而且我们可能永远做不到。  在我们尝试遵循这个过程当中，我们常发现继承了某设计决策， 却不知道当初决策者的之所以决定的理由。  一个例子是等式中常量的值。当我们要常量的推导过程时， 我们发现它不存在、或者原先推导是不正确的。  当进一步追问时，我们被告知做这个决策是 “因为它起作用 ( **because it works** )”。  在这种情况下，设计师可以去研究它起作用的原因， 或者就简单地 “与它友好相处 ( **Get On With It (GOWI)**) ”。 给我们的工作付钱的人把 **GOWI** 作为对许多此类问题的标准回答。 我们并不认为真正的工作会有所不同。 然而， 每当我们把“因为它们起作用”作为决策理由时， 我们就诚实地把这个理由写下来， 以免误导将来的软件维护者去花心思想在我们的决策后面有什么深刻的理由。
+
+
+Page 20 - 蓝珲 OK
+----------------------------------------------------------------------------------
+
+**致谢**
+
+NRL的Stuart Faulk与John Shore为这篇文章提供了深思熟虑后的评论。
+
+美国海军与加拿大NSERC对本研究提供了资助。
+
+