summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--parnas-a-rational-design-process.rst2
1 files changed, 1 insertions, 1 deletions
diff --git a/parnas-a-rational-design-process.rst b/parnas-a-rational-design-process.rst
index 4ec5b47..dce8d62 100644
--- a/parnas-a-rational-design-process.rst
+++ b/parnas-a-rational-design-process.rst
@@ -513,7 +513,7 @@ VII. 现在, 我们如何佯装理想的过程?
(Page 19)
-我们几年前为演示理想过程所写的软件需求文档,可作为这个过程取得成功的一个例证 [9]。通常,人们会假设需求文件是在编码前产生的,之后就不会再被使用了。 然而,事实证明并非如此。满足该需求文档的软件的原始版本,现在仍在修订。软件每次更改后,负责测试的机构大量使用这个文档来选择他们要做的测试。当需要新的改变时,需求文档被用于描述什么必须改变、什么不能改变。软件投入使用后,这个过程中产生的第一份文档一直被用了很多年。明确的消息是,如果精心制作文档,它将在很长时间都有用。反过来说,如果文档将被广泛使用,那么就值得把它制作好。
+我们几年前为演示理想过程所写的软件需求文档,可作为这个过程取得成功的一个例证 [9]。通常,人们会假设需求文件是在编码前产生的,之后就不会再被使用了。 然而,事实证明并非如此。满足该需求文档的软件的原始版本,现在仍在修订。软件每次更改后,负责测试的机构大量使用这个文档来选择他们要做的测试。当需要新的改变时,需求文档被用于描述什么必须改变、什么不能改变。软件投入使用后,这个过程中产生的第一份文档一直被用了很多年。明确的信息是,如果精心制作文档,它将在很长时间都有用。反过来说,如果文档将被广泛使用,那么就值得把它制作好。
成为一个理性的设计师很难,而且我们可能永远做不到。在我们尝试遵循这个过程当中,我们常发现在一些地方继承了一个没有明确理由的设计决策。 一个例子是我们要用的等式中的常数。当我们询问常量的推导时, 我们发现,要么推导不存在,要么推导无效。当进一步追问时,我们被告知做这个决策是“因为它有效 ( **because it works** )”。在这种情况下,设计师可以立一个研究项目去找出为什么它起作用, 或简单地“不要纠结继续吧 ( **Get On With It**) ”。为我们的工作付费的人已经把 **GOWI** 作为对许多此类问题的标准回答,并且我们不认为真正的工作会有所不同。然而, 每当我们把“因为它有效”作为决策理由时,我们将记录这个坦诚的理由,而非误导以后的软件维护者去认为我们那么做有什么深刻的、哲学的原因。