1.寻找哲学家的石头（ps:哲学家的石头，真善美结合体，此处意思应为，完美的解决方案？）：为何我们想要一个理性的设计过程
一个完美的理性人是他做的每一件事情都由一个好的理由。他采取的每一步都可以被证明是达成一个设计好的目标的最好的方式。我们大多数人都倾向于认为自己是理性的专家。但是，对大多数研究者来说，通常的软件设计过程表现的相当非理性。软件设计者开始时并没有对期望的行为和实现约束有一个明确的声明。他们在没有对为什么他们以他们做事情的方式有明确说明的情况下做了一系列的决定。他们的推理过程很少被解释。
我们之中很多人对这样的一个设计过程并不满意。这就是为什么有对软件设计，编程方法，结构化编程以及相关课题的研究。理想情况下，我们希望我们的程序来源于一个明确的需求，统一，我们希望定理是从出版的公理推导出的。所有被认为组织严密的方法论都源于我们想要有一个理性的系统的软件设计过程。
本论文将给你带来既有好的消息也有坏得消息。坏消息是，以我们的观点，我们永远找不到哲学家的石头。我们永远也找不到一个可以让我们以完美的理性方式来设计软件的流程。好消息是，我们可以复制他。我们可以想其他人展现我们的方法，就好像我们是理性的设计者，并且在开发和维护中如此做事值得的。
2.为什么软件设计过程总是非理想化的呢？
我们从来没有看到过一个软件项目以理性的方式进行。原因如下：
（1)大多数情况下，发布软件构建任务的人不准确的知道他们相应什么并且部能够告诉我们他们知道的全部内容。
(2) 就算我们知道需求，设计软件还有许多其他内容需要知道。许多细节只有到实现的时候我们才知道。有些时候我们发现我们的设计不能使用，需要会对。由于我们试着最小化浪费的工作，理想的是设计可能来自于非理性的过程。
(3)就算我们在开始前就知道相关的内容，经验表明人类不能够完全了解为了设计和构建一个正确的系统需要考虑的很多细节。设计软件的过程是我们为了使用可控数量信息工作而尝试抽象的过程。然而，在我们抽象之前，我们注定会犯错。
(4）经我们可以掌握需要的细节，除了试验项目外所有的项目注定会因外部原因而改变。其中有一些改变会使前期的设计失效。这导致没有一个软件是由理性化的设计过程产出的。
(5)人为错误只有不使用人时才可以避免。就算在抽象之后，也会犯错。
(6)我们经常受先入为主的设计理念，我们发明的想法，从其他相关项目获取的理念或者从课堂上听到的理念。有时候我们为了尝试或使用一个理念而开发一个项目。这些理念可能并不是由理性过程中的需求分析获得的。
(7)我们经常由于经济原因会被鼓励使用为其他项目开发的组件。在其他情况下我们会被鼓励和其他症状开发的项目共享我们的组件。结果程序可能对所有的项目都不是理想的，也就是说，我们开发的软件不是仅仅基于需求，也因为它是足够好的，所以我们就节省精力了。
由于以上原因，软件设计者在理性的，不犯错误的，从明确的需求的情况下进行设计是不现实的。以前没有程序在这种情况下开发，估计以后也不会有。甚至于教科书和论文中的小开发项目也是部真实的。它们被不断的修改知道作者认为能够表达他期望他已经完成的东西，而不是确实发生的事情。
3.然而为什么描述一个理想化的理想设计过程是有用的？
对于每一个细心的思考者来说，上面说的是显而易见的，并且是被诚实的人所承认的。除了我们看到的软件设计过程的讨论者，以软件设计方法为工作的人和描述理性软件设计过程的创意市场的课程设计者。这些人想达到什么目的呢？
如果我们有一个理想的设计过程但是不能够完全遵循，我们可以尽量接近并且我们可以写我们将要构建的软件的文档，如果我们遵循理性的设计过程。这就是我们说复制理性的设计过程的含义。
下面是复制理性设计过程的一些原因：
（1）设计者需要指导。当我们承担一个大项目时，我们很容易被大量的任务包围。我们不确定需要先做什么。对理想化的设计过程的理解能够帮助我们知道如何处理。
（2）我们会逐渐接近理性的设计，如果我们尝试遵循一个流程而不是基于临时的想法。例如，尽管我们部能够知道设计一个理想系统的所有知识，但是在编码之前，为寻找这些知识的努力会帮助我们设计的更好，回退的更少。
（3）当一个组织承担很多软件项目是，有一个标准是有利的。这有利于设计走查，人员，想法和模块从一个项目到另一个项目转换。如果我们需要遵循一个标准，那么这个标准应该是理性的。
（4）如果我们承诺进行理想的流程，那么度量项目的流程会更容易。我们可以以流程的需要来比较项目的成效。我们可以确认我们在哪些方面做的好，哪些方面做的不好。
（5）外部人员对项目规律性的流程检查是好的管理的基础。如果项目遵循一个理想话的路程，那么会更便于检查。
4.开发流程的描述能够告诉我们什么?
流程描述的最有效产出是项目产品。对于流程的每一个阶段，本论文说：
(1)我们下面要工作的产品?
(2)我们的工作产品要满足的标准?
(3)需要什么样的人来进行工作?
(4)工作中他们需要哪些信息？
任何部以工作产品描述的流程的管理都只能被会读心术的人完成。只有我们知道要完成哪些产品并且知道它们需要满足的标准，我们才可以检查项目和评价流程。
5.什么是理想化的设计流程？
本小节描述理性的理想化的设计过程应该尝试遵循的东西。每一步都要有对该步需要完成的工作产品的详细描述。
对流程的描述部应该只包含测试和检查。虽然，这两者是不可忽略的。当一个作者应用本文种描述的流程时，我们包含对每个工作产品的可扩展的和系统化的检查和对可执行代码的测试。检查流程在11页和17页讨论。
A。构建和需求文档
如果我们是理性的设计者，我们必须知道我们需要做什么会成功。这个信息应该被记录在一个工作产品中作为文档要求。在我们对需求开始设计之前。
（I)为什么我们需要一个需求文档？
（1）我们需要一个地方来记录用户向我们描述的系统预期的行为。我们需要一个文档供用户或他的代表检查。
（2）我们想要避免在设计程序的过程中需求的随意变更。面向系统开发的软件开发者经常对应用是不熟悉的。有一个对可视行为的明确定义使他们可以决定怎样是对用户最好的。
(3)我们想避免重复和不可持续。没有需求文档的情况下，许多文档解决的问题会被软件设计者、软件编码者、检查者，一次又一次询问。这增加了工作成本并且可能答案并不统一。
(4)一个完整的需求文档对于估算建立系统工作量和其他资源是必须的（但并不足够）。
（5）需求文档是对避免人员流动的损失的保障。我们从需求中获取的知识可能会随人员流动而丢失。
（6)需求文档为测试计划提供了一个好的基础。如果没有需求，我们就不知道怎么测试。
（7）需求文档可以在系统使用很长时间后仍然被使用，勇于约束未来的变更。
（8）需求文档可以避免软件开发者之间的争论。如果我们有一个完整的和准确的需求文档，我们就不需要或咨询需求专家。
（II）什么内容被写入需求文档？
对理想化的需求文档的定义很简单。它需要包括你开发可供用户接受的软件需要的所有知识，没有其他内容。当然，我们可能使用对已有信息的引用，如果那些信息是准确并经过良好组织的。一个理想化的需求文档，可接受的标准如下：
（1）每一个陈述需要对所有的可接收的产品有效。没有东西依赖于实现决定。
（2）文档需要完整，也就是说，如果产品满足所有的陈述，那么，产品就是可接受的。
（3）在开发前部能够明确确定的信息，不完整的部分需要明确说明。
（4）产品需要被组织作为引用文档而不是对系统的陈述性的介绍。尽管编写这样一份文档是困难的，一个引用比浏览一个介绍性的东西，但是从长远来说，是节省工作量的。本阶段获取的信息被记录以容易被整个项目过程中引用的形式。
（III）谁编写需求文档？
（1）理想情况下，需求文档有用户或他们的代表编写。实际上，用户很少具有编写该文档的能力。另一方面，软件开发者必须编写一个草稿文档然后被检查最终被用户认同。
（IV）需求规格说明书背后的数学模型是什么？
为了保证文档的完整性和可持续性，在文档组织背后必须有一个简单的数学模型。下面的模型是由对实时系统的工作产生的，但是因为这，它是完全通用的。所有的系统都可以被描述为一个实时系统，尽管对实时性要求不高。
模型鉴定理想的产品不是一个纯粹的数字计算器，是一个由模拟计算器控制的数字计算器。模拟计算器将持续的输入值转换为持续的输出值。一个纯粹的数字计算器或纯粹的模拟计算器是通用模型的特例。将要开发的系统是一个进行数字估算的混合系统。就像在其他工程领域里一样，我们可以首先通过对系统的描述我们的规格说明书，然后细化可以接受的容忍度。需求文档重视输出过于重视输入。如果输出的值是正确的，没有人会在乎输入值甚至是否被读取。需求文档的核心是以表格形式描述的一系列数学方法。每一个表格描述多个状态变量经一个方法计算后的值。
（V)需求文档应该怎样组织？
需求文档的完整性可以通过抽象的独立来获取以下部分：
(1)计算机规格说明：程序需要运行的机器规格。这个机器不是指硬件。对于一些软件来说，这部分仅仅指出帮助手册语言。
读后感：对需求的明确定义，以文档辅助设计。通过不断的估计和调整计划，获取交付日期，避免软件黑洞情况。