四步创新软件开发模型

作者：黄绍良　来源：希赛网

　　今天大部份软件工程项目失败的主要原因是我们采用40年前的软件开发模式， 30年前的计算机应用思维。从业人员采用过时的方法，落后的思维，所以大部份项目未能为业主带来预期的效益，满足业主的要求。

　　40年前计算机开始进入商业用途之初期，没有任何开发体系可以应用，所以从业人员在表格上整理逻辑，编写程序，测试及对程序进行Debugging，然后移交，今天从业人员在脑中开展系统的逻辑，进行程序编写，过去的Debug变成今天的Fix（修改），成为边想、边做、边改的“三边模式”来进行软件开发。30年前软件的主要应用目的是运营自动化，提升企业部门的执行效率，今天大部份从业人员还是以自动化为软件开发的主要目标。软件工程失败的主要原因不是技术应用的问题，是从业人员未能把握客户思维，交付客户期盼的交付物，导致项目在开发过程中不断修改和返工，为项目带来延误和超支。

　　往往我们把客户的期盼当作系统的功能需求，这是一个错误的观念。要知道客户的期盼（我们口中所说的客户需求）是要做什么，这是客户投资的最终目标。但系统或功能需求却是该如何做，是技术应用的手段。知道“要做什么”，才知道“该如何做”。我们未能把握客户的期盼（要做什么），如何能够提供高效的技术手段来达到目的呢！所谓“条条大道通罗马”，只要知道了目标，我们有很多选择采用不同的手段来达到。过去的问题在于我们把目标当成手段来处理，一步一摸索，在过程中不断开路搭桥，纵然最终能够抵达目的地，但这种执行模式能不浪费时间，精力和金钱吗！

　　今天的软件工程的终极要求与过去数十年软件工程的终极要求有很大的差异。过去自动化时代的软件工程主要是技术的应用，提升运营效率，以技术的应用方法为项目的最终目标。今天的信息化软件工程必须考虑和提供业主希望获得的投资价值，着重于科技如何能够带出相对的投资价值和运营效益为目的。可惜我们还是利用过去数十年前的技术开发思维和应用方法来进行项目交付，未能有效地面对项目属性和交付目的的转变做出相应的调整。让项目中大部份的工作量停留在编程，测试，修改和返工上。我们采用过时的方法，落后的思维来面对今天软件工程的挑战，如何能够在软件工程方面带出创新，引领未来呢？

计算机是逻辑学

　　“四步创新软件开发”的要旨在于摆脱过去软件工程对需求的重视，从逻辑的思维去实现最终目标。软件工程项目多基于规范性的逻辑应用，任何软件工程项目的最终交付都必须包含两个部分，一个是业务逻辑（即业务应用流程）、另一个是系统逻辑（即程序执行流程）。业务逻辑是任何系统在最终实际的业务层面所体现出的逻辑，就是“要做什么”；而系统逻辑是指系统为了满足业务上的能力而在系统层面所体现出的逻辑，就是“该如何做”。无论是业务逻辑还是系统逻辑，它们存在的目的都是为了交付最终的价值或达到项目的目标。所以在没有明确相关的业务逻辑和系统逻辑时，要想建立出交付价值的相关逻辑是十分复杂的。一般来说，业务逻辑是范围所处的层面，而系统逻辑是功能需求所处的层面。

　　为了明确主要的构思，我们不以软件工程项目为例来带出相关的构思，而是以其它工程项目为例来说明这些构思。这样做是为了让读者可以摆脱软件工程中的原有思维，以一个新的角度来看待软件项目。不知大家是否还记得“工匠与专家”的故事，这里我们将会以一个内部装潢设计专家的角度来说明如何利用一个新的房间为例，带出四部开发方法的主要构思。     

　　假设我们要利用一个空房间，使用的目的可能是作为办公室、会议室、书房或者其他的用途。那么在决定了这个最终目的后，便需要决定房间中所需的家具和布置，房间可以是空房间、也可以是有些家具的房间。

　　所以，在知道最终用途后，我们（扮演了装潢设计师）才会明确有哪些家具，这些家具便是交付物的定义。也许我们明确知道需要一张桌子，不管是从家具店购买、还是找工匠打做，我们一定要依据最终交付物定义来思考。更明确的说，知道一张桌子使用的最终目的，是用来放置计算机、放置一个咖啡器、用来书写、或者是用来开会还是装饰，更甚者是可以放置计算机、可以办公、可以放置一个咖啡器的办公桌。其中一样或多样都可以是说明需要一张桌子的最终目的。这是我们在理解了这些最终目的后在价值层面思考后获得的最终交付物说明，这些最终目的构成了说明交付物的依据。而思考的方法就是PCDM。

　　最终的目的已经构成最终交付物的主要构思，加上应用的地域和环境，将会直接影响最终交付物的外观和大小。例如，试想我们为一个仅有15平米的办公室，进行装修布局。客户明确指出了，在该办公室中可以有3个经理办公、同时可以满足某一经理爱喝咖啡的习惯、还需满足另外一个经理需要经常与其他员工在办公室见面和会谈的工作要求。那么，这些目的和应用的环境（15平米）将会影响到交付物（办公桌子和椅子）的外观。

　　有了需要一张桌子的最终目的和建立的交付物定义，接下来我们要考虑的便是这件交付物的外观（Appearance），是圆的、方的、长方形的、椭圆形的、折合型的，需要抽屉的，需要附加柜的（如放置咖啡器），桌腿是三叉脚的、四角的，是需要两边竖立或交叉对立支撑的（如需要经常面见员工）。这些外观的设计直接影响交付物的外表。另外，考虑外观的时候需要考虑拜访的应用环境（如15平米），桌子是放在中央还是角落、或是平常依附角落用的时候放到中央。这些也会影响交付物的外观。该阶段我们可以称为交付物的外观阶段，如一张桌子到底是什么样的。

　　当明确了最终目的和外观后，最后进入建造或采购过程的时候才考虑所采用的组合技术和材料，包括桌子的组合是透过钉子、螺丝结合或是焊接。这些技术的应用将会影响交付物的质量和投资成本。而不同的技术仍然可以打造同样的结果，如钉子组合或螺丝结合（当然是木螺丝）都可以组合不同的交付组件。该阶段也被称为建造阶段（Construct），而该阶段的成功归功于前期交付物和交付物的外观获得客户的认可，这样在建造过程中将会把客户的需求变更降到最低，甚至消失。

　　当然，我们需要把交付物（如桌子）与实际的应用环境（如15平米的经理办公室）相结合，看看是否能够演绎出预期的最终目的，如是否满足了某一经理及需要摆置电脑又需要摆置咖啡器的目的。该阶段称为演绎（Demonstrate）阶段，它可以让交付物与环境结合成一个完整的验收过程。环境包括应用的部门、人员、培训、硬件配置等。

    

四步创新软件开发

图表 1：四步创新软件开发

　　四步开发方法的主要构思是：在我们失去了业务操作流程的时候，我们可以从项目的价值或目标来考虑和确定出项目的交付物定义；同时我们可以利用这些交付物定义来建立每个交付组件所对应的业务操作流程，通过业务操作流程带出每个交付组件的数据定义和界面定义；最终，根据这些数据定义和业务操作流程我们可以将构建交付物的任务划分为多个子任务来完成；当我们将所有的交付组件建造完后，可以将实际构建成的交付组件应用到客户所需的业务之中，带出在项目初期确立的目标或价值。

 

　　四步软件开发方法共分为四个阶段，它们分别是：

　　1）第一阶段称为目的阶段，它开始于项目赞助人给出项目说明，结束于交付物定义。在该阶段中，我们通过使用PCDM构建出项目的交付物定义和最终目的。该阶段需要相关受益人的确认，包括项目赞助人和项目干系人。

　　2）第二阶段称为外观阶段，它开始于交付物定义，结束于交付物的外观建立完成。该阶段的产物包括，业务流程定义、数据定义、界面定义；同时数据定义和界面定义构成交付物的外观。这里需要使用的方法是系统操作规范（SOP）。该阶段需要项目赞助人认可和确认交付物的业务流程。

　　3）第三阶段称为构建阶段，它开始于数据定义和界面定义，结束于最终解决方案的生成；这里解决方案是指实际的、有相关技术方案构成的最终交付的系统。这里最终的解决系统需要项目赞助人的测试和确认。该阶段的主要任务是编程和测试，同时我们不准备强制任何方法和技术标准，这里可以自由地选择适当的技术标准来构建最终的解决方案。      

　　4）第四阶段称为演示阶段，该阶段将最终的解决方案放置到相应的环境中进行组合，来产生最终的效益。这里我们需要明确每个解决方案的环境组合，包括系统配置、用户培训、用户测试。

　　四步创新软件开发的生命周期包括四个主要阶段：目的阶段，外观阶段，构建阶段，和最后的演示阶段。与传统的软件开发模式相比较，四步创新软件开发的每一个阶段都可以培养有关的专业人员，目的阶段可以培养优秀的业务和系统分析人员，外观阶段可以培养业务流程改做和软件设计人才，构建阶段让技术人员尽情发挥本身的技术知识和应用能力，演示阶段培养优秀的综合性软件工业人才。这些都是我们目前大部份企业所希望做到但没有办法做到的最终成果。

　　第一步：目标阶段

　　任何项目在起动的第一时间必须明确项目的范围，才能够控制开发过程中的范围变动。在今天的信息化时代，要为未来的运营模式成立前建立工程的范围是相当困难的任务，我们过去采取逃避的方式，不去尝试建立项目范围，把精力虚耗在把握客户需求（业务逻辑）上，同时把客户需求作为功能需求（系统逻辑）来处理，所以我们一直没有一套高效的办法为客户构建所需的系统，满足客户投资的最终目的。

　　我设计的项目组件分拆发（Project Component Decomposition Method, PCDM）是一套建立信息化系统工程范围的手段（详情请参阅发表在希赛网的“项目组件分拆法PCDM”一文），可以在相对较短的时间联同业主即主要项目干系人共同分析项目的最终交付需求，从交付需求中整理出业务逻辑和系统逻辑。

　　第二步：外观阶段

　　也许这个阶段以“内观”代替外观比较贴切，但实际上这个阶段的工作保护两个主要目的，一是让客户认同未来交付的成果，二是建立系统的规格。

　　外观阶段主要是对未来需要交付的系统执行操作规划（System Operation Planning, SOP）,建立未来的业务逻辑和系统逻辑，同时依据业务逻辑建立系统的数据流，利用系统逻辑建立用户界面。让客户认同未来系统的操作流程，明确过程中的各种界面设计和内容，构建了工程核心的业务逻辑和创建了系统的核心价值，减低开发过程中的返工需求。这个阶段的主要交付包括未来的业务定义，数据定义和界面定义三部分。

　　交付组件为什么可以明确业务流程

　　PCDM的交付组件是如何限定每个组件内的业务流程或业务逻辑呢！这是因为：     

　　1）每个交付组件都是在独立的价值层面上来进行定义的，它们仅仅围绕价值的交付来进行建立相关的交付组件。每个组件最多说明到通过做什么来生成价值，而不涉及业务逻辑和系统逻辑。

　　2）每个交付组件都会明确从那些方面来生成相应的结果或效果，这样可以在独立的价值层面上从不同方面来确保最终的系统可以交付所期盼的价值。而如何做和做什么是交付价值的逻辑与系统和业务逻辑相互分离。

　　3）这样每个组件通过价值层面的逻辑来指出通过哪些相关的工作内容来交付价值，同时这些工作内容是价值层面的描述。当我们为每个交付组件建立相关的业务流程时，我们根据业务环境所选择的业务逻辑在价值层面上的映射必须与交付组件的内容一致，使得业务逻辑可以完全符合价值层面的要求来交付相关的价值，否则我们很难控制每个价值的交付过程或业务流程。

　　四步开发方法在PCDM交付物定义的引导下，使得我们构建项目的业务操作流程的时间和精力将会被缩短、质量将会被提高。

　　交付组件与业务模块

　　交付组件就是一种业务模块，所以它可以获得所有业务模块的优点。但是，它与业务模块还是有一些本质区别的。

　　1）交付组件是在价值层面对交付组件进行描述，与具体的业务流程或业务逻辑基本分离，不受到具体的业务流程影响。

　　2）交付组件可以是交付物定义的组件，同时也可以是由方案所直接转变而成的交付成果或组件。同时每个交付组件可以包含一个或多个业务模块。

　　3）交付组件主要是针对价值而言的，么个交付组件都通过它自身所描述的工作内容来对交付价值，或通过不同方面的效果或成果使得最终的某一交付物可以生成最终价值的描述。而业务模块主要是为了业务层面的维护、复用和解耦，在一个项目中业务模块可能很难明确的在价值层面被描述出来。这是因为它所贡献的效果可能针对的是另一个价值。

　　4）交付组件是通过PCDM方法来确立的。而业务模块基本上是根据在交付组件内的业务逻辑进行的解耦获得的，它更加利于复用其它价值层面。

　　5）交付组件是与效益或价值同时扩充和维护的，而业务模块是被包含在交付组件内变更的。

　　6）交付组件可以说成是价值层面的逻辑，而业务模块是业务层面的逻辑。

     

　　业务定义

　　业务定义中所指明的系统模块是从业务角度来看待的，是PCDM的交付物定义中所包括的内容，它与具体的技术使用无关；如API的调用序列。而且它也不是编程语言中所指的模块，如像JAVA中提供的包或组件等。同时它也不完全等价于PCDM中所建立的交付组件；一个交付组件可以是一个业务模块，同时也可以是一个和多个业务模块的组合。在进行业务层面的系统模块说明前，我们还是明确一下业务流程在开发体系中的一些本质作用，这样我们就可以较为清楚地理解业务层面的系统模块这一概念。

　　回顾在PCDM中所描述的案例，我们的最终交付物在下图中描述有关的业务模块（交付组件）和数据组合（数据组）。

图表 2：PCDM分拆后的最终交付物定义（包括初步数据组合）

 

　　每个交付组件可以是一种业务模块，它指明了该模块内应当完成那些任务来带出客户期盼的价值。但是交付组件并不是从业务层面思考获得的，而是从价值层面构成的定义；而这个定义却指明了业务层面应当完成的任务。可能一个交付组件要包括一个或多个业务模块的组合（这依赖于定义业务模块的方法）。实际上每个业务模块仍然可以明确地存在于价值层面上，对于任何不同项目价值层面可能会有所不同，会出现一个交付组件包含多个业务模块的现象。由于业务模块的本身特性和价值层面描述具有同一性的交付组件，使得我们构建的业务流程必然对应了相关的系统接口或组合。所以在制定操作流程时，我们仍然需要考虑到价值层面，即每个业务点不是单纯从客户使用角度建立，更应当将从业务角度来考虑每个业务点中如何来贡献出项目的价值。

　　由于每个业务点的制定都考虑到了价值的贡献，所以一个或多个业务点的输入和输出所构成的业务模块与实际的系统接口调用组合都是用来产生相应价值的，它们之间构成了明确的对应关系。

　　交付物定义明确指明了每个业务流程上的工作内容，使得交付物所对应的目标可以细化到业务层面，这样我们可以知道流程中的业务逻辑与项目价值的对应关系。这就是我们建立业务流程的主要目的：通过交付物定义来明确在交付物内的业务逻辑与价值之间的对应关系，可以帮助我们分离不同价值的业务逻辑，从而使得该交付组件或所对应的业务模块具有高内聚低耦合性。同时这些业务模块可以由相应的系统接口构成，而且这些系统接口的定义和实现完全可以依照不同的技术标准来制定。而这些业务模块要么是交付组件，要么一同构成了交付组件。

　　由于业务模块的特性，使得业务逻辑和系统逻辑相互分离，同时确保它们是一致的。这样对于每个业务流程所带出的相关数据，我们可以通过业务模块来制定出明确数据定义，这些数据定义将会成为我们构建系统模块（或接口）和系统架构的基础。

　　我们可以通过“业务操作流程、数据定义、界面定义”来代替“需求调研、需求分析和系统设计”。虽然，我们还需详细的论述数据定义后才可以下该结论，但是在这里我们基本上明确了交付物可以通过系统操作流程带出的输入和输出制定出数据定义，这些数据定义构成了制定系统模块的基础。

    

　　业务定义：操作流程

　　为了使得业务操作流程的制定能够明确的表明，我们需要制定一些基本的限定：

• 每个业务操作流程必须指明一个开始点和完结点。
• 每个开始点和完结点，以时间、地点或时间的状态作为标注。
• 每个操作流程都会拥有一个或多个业务点。
• 每个业务点必须有明确的输入或输出，或者是二者兼有。
• 每个业务点必须从业务层面指明一个活动或操作，且只有一个。
• 每个业务点的输入和输出的数据属于业务层面的数据，但不一定不设计技术的信息。例如，记录客户信息中的客户号，有可能是一个技术信息，但是它是在业务层面的表达，所以不会涉及到技术的具体运用，如不会指明该客户号可能是一个哈希编码等等。
• 每个操作流程必须有明确的目标，同时这些目标要么是交付的价值，也就是对于交付组件所对应的价值在价值层面做出相关贡献。
• 每个业务点必须是自包含的、限定的，否则任何软件也无法实现一个非限定性的业务流程，即该业务流程是“不可计算的”。

图表 3：初步系统逻辑代表业务逻辑，附加初步数据组合说明

 

　　有了业务操作流程的精确定义，我们就可以为每个交付物的外观做出精确定义。

　　数据定义

　　对于系统操作流程中的每个输入或输出，都会成为我们制定数据定义的基础。这些输入和输出会构成相关业务模块和系统接口的基础。

　　在建立初步系统逻辑和业务逻辑抽，我们可以划分出业务模块，实际上一个交付组件（或方案所对应的组件）就是一个很好的业务模块。但是，由于不同价值层面的原因，在某一层面的交付组件有可能包含了明确的另外层面的多个交付组件。所以，我们需要将交付组件划分为更加明确的业务模块，而划分的规则就是在业务层面的高内聚和低耦合；即根据每个业务模块所对应的业务流程的输入和输出制定业务模块。

　　根据输入和输出建立该业务模块的数据定义，最终需要整合所有的数据定义成为系统的数据架构或数据定义。一般来说会有两种方法，面向过程和面向对象。面向过程可以分别建立业务模块和数据架构，而面向对象需要一同建立领域模型（业务层面的类模型）和动态模型（对象状态转移图），同时领域模型一般来讲是数据架构，而非业务模块；因为，如果以对象来标志业务模块的话，可能很难明确该模块所对应的业务目标，那么这种模块会丧失业务内聚性。另外，需要说明的是数据架构可以根据要使用的技术标准直接建立到系统层面，也可以仅仅建立业务层面的数据架构，这完全依赖于我们使用的技术标准。

　　最终我们需要利用数据架构建立业务模块的架构，以使得业务模块的架构可以与最终的包含在每个模块内系统模块或接口的架构相互对称。数据定义模型包含了业务模块、数据架构和业务模块的总体架构。而业务模块的总体架构仅仅是通过完善交付组件之间的关联（数据耦合）来完成的。

     

　　界面定义

　　业务流程与交付物外观”代替“需求与设计。可能细心的读者会问，怎么在四步方法中没有需求和设计这两个活动了呢？是的，在构建四步开发方法时确实将这两个活动从四步方法中移除了，我们是通过“业务流程与交付物外观”来代替“需求与设计”的。通过交付组件我们可以明确指出工作内容，同时可以使得业务逻辑和系统逻辑在交付组件上相互对应（或业务模块），这里的交付组件可以是交付物定义，也可以是方案所对应的一个个单一的组件。

　　1）我们可以独立地建立该交付组件的业务逻辑，这将带出明确的数据定义，同时也会带出相关的业务模块（如果交付组件内还可以分解出更明确的业务模块）。

　　2）由于业务模块和交付组件的原因，我们可以等价地利用交付组件或业务模块来建立出系统在业务层面所对应的架构；同时每个组件内都可以对应明确的系统接口或模块。

　　3）最终我们可以利用业务模块的架构来等价地建立出系统的架构，同时并不影响每个模块内系统逻辑的制定。

　　对于功能需求，我们利用业务模块将其屏蔽和限定在一个个的交付组件或业务模块内，使得我们根本不需要从系统角度来建立在项目初期根本就不存在的需求。实际上，客户一直不知道他自己的需求（功能需求），否则客户为什么在70%的失败率下还是要依靠我们来建立功能需求呢！

第三步：构建阶段

　　构建阶段的设立是为了使得技术人员可以更加自由地发挥他们的技术特长，从而构建的交付物不仅可以带出价值，而且是高质量、易维护应用软件。我们不准备详细的讨论每个技术规范和强制约束该使用那些技术规范，因为我们既不想加入到旷日已久的技术大战中，也不想再为“名词百出”的IT界增加新的辞藻。

　　技术标准选择

　　技术标准的选择是跟客户是无关的，而且大部份客户也不太理会。客户的主要目的是依赖技术人员的专长来为他搭建所需的应用系统，所以技术的应用完全可以由开分人员来进行选择。但是需要一个系统架构师来确认这个项目的统一技术标准，否则交付物将会因为技术标准的错误选择而失败。

　　这里我们仅仅说明交付物和操作流程是如何隔离不同技术方案的。这是因为：

• 对于与交付物对应的系统操作流程反映了出了业务的逻辑，同时我们有从业务角度建立出了业务的模块，使得每个业务模块之间的耦合度降到最低。
• 由于业务模块（数据定义的一部分）不依赖于具体技术的实现，所以我们可以非常自由地为每个业务模块赋予不同的技术方案，只要它们之间是相互一致的。
• 由于业务模块隔离了系统逻辑，使得每个业务模块的逻辑不会受到系统逻辑的变更影响，所以被包含在不同业务模块的技术方案之间不会被相互影响；对于整个系统架构而言，即使添加或拆除一个业务模块，也仅仅是增加和取消系统接口的调用，使得整个系统便于维护。
• 我们在定义了统一的技术标准规范后，独立地定义每个业务模块的系统接口调用和实现。

　　这里可以引入的技术标准可以包括如SOA、UML、BPEL等。同时也可以使用一些较早的技术标准，如面向过程的编程等等。因为所有的软件项目都不可能完全以一个技术标准来实现，如嵌入式系统完全可以涉及到更加接近底层的汇编语言。

    

接口定义

　　在统一了技术标准规范后便需要独立地定义每个接口的实现方法。接口定义不同于模块的建立，如面向对象中的一个对象可以是一个模块，而么个对象中的方法是一个接口。接口说明了在某一模块中引入另一个模块的目的和作用，也就是规定了模块之间的耦合。

　　系统中的每个接口，是依据业务模块和数据关系表来建立的。每个业务模块说明了系统接口是如何被相互调用而组成业务模块的。如“显示报名信息”是一个业务模块的话，从对象角度可能需要定义出两个对象，“Booking”和“Booking Layout”两个对象来分别完成“维护报名信息”和“报名信息屏幕布局”两个任务。注意，在该案例中我们没有说明具体的API是如何调用的。

　　所以，这里我们需要进一步强调业务模块的制定不要设计任何技术的信息，甚至定义某个对象的接口，不要忘记一个对象的接口有可能涉及系统的逻辑，而是的我们在选择技术标准时进入一个两难的境地。

　　编写测试

　　在选择每个系统模块或接口的实现方法前，最好根据技术标准和业务模块的定义制定出系统模块的测试文档和整个系统的测试文档。这对于任何技术标准都是需要的，这样我们不仅可以有根据的检验每个接口的实现，同时我们可以根据则是文档的制定让程序员更加明确每个程序实现的约束。

　　编程规范制定

　　无论哪种技术标准都会议自身的角度来强调编程的规范，试图从公众的角度加以限定几乎是不可能的。所以，这里我们仅仅说明编程中必须注意的事项，而与具体的技术规范无关。

　　1.  使用一致的和有意义的变量名；这几乎是所有纠错性维护的根源。才将任务试图根据业务模块或交付组件来分给不同的技术小组时，一定要制定一致的变量名和数据库的调用规范；如不要试图对同一个数据库中的表使用多个索引。

　　2.  代码注释规范。如果问维护中最大的难点是什么，无疑是对代码的理解，即使对于面向对象的程序而言，在没有代码时试图读懂程序也会是一个噩梦。

　　3.  使用参数。实际上，程序中数据大部分以变量形式出现，否则我们不必在这如此费神。这里的参数是指将一个常量也绑定到某一变量中来。至于是否有相关的语言可以帮助我们实现，我想现在不用我们指出，即使不太精通编程的非专业人员都会指出一两种来。

　　4.  代买编排版式需要统一，这会大大增加可读性。现在有大量的CASE工具来帮助我们实现。

　　5.  不要将嵌套的IF语句超过3个，虽然这不是必须的规定，但是它已经在业界获得一致的认可。

　　6.  对于任何API而言，在小组试图开发前需要明确相关API至少是在程序中使用的API的正确调用顺序。好像这点并不需要强调，只要你登录UCLA的网站，你就可以找到关于API构成BUG的相关数据挖掘的解决方案，那时你会知道这种错误的出现不仅是致命的，而且是十分普遍的。

　　最后我们没有明确指明如何进行测试的原因是不同技术规范有不同的测试需求和技巧。     

第四步：演示阶段

　　在演示阶段主要是通过将交付物与具体的应用环境相结合来带出客户所期盼的价值，从而使得项目可以得到验收。演示阶段主要有三个过程：

　　1）系统配置：即安装报告，明确指明系统的环境参数如何设置（如MySQL的安装信息），指明如何配置相关的系统参数（如设置路径变量等）。这部分也可以有系统维护人员来协助客户一同完成。

　　2）用户培训：由于新的系统的引入，我们还需要按照系统操作规范和交付系统的特征来撰写培训计划和流程，以使得客户可以明确如何使用和操控系统。

　　3）用户测试：当然最终需要客户按照项目交付物定义和操作流程来验收整个系统是否可以带出我们在项目初期所一同建立的价值。这部分的测试文档有客户自己制定。

四步创新软件开发的作用

　　任何开发方法都有其相应的作用，四步创新软件开发方法也不例外；它的作用是：

　　1）可以有效的隔离业务逻辑和系统逻辑，使得他们可以单独的处理；充分发挥了技术人员的技术特长。

　　2）具有高度的可维护性，使得我们可以根据客户提出的维护需求，仅仅修改和扩充相关的交付组件而已，不会影响其他组件的内部结构。

　　3）业务与技术可以单独地变更；也就是技术的变更不会影响业务的逻辑。

　　4）可以有效的融合其他技术标准，使得四步创新软件开发方法应用更加广泛。

　　在构建程序上，赋予了构建过程的灵活性，使得程序员可以仅仅考虑给予他们的任务；这样，加大了程序员的工作效率；最终将会减少开发的时间、减少资源的运用。

　　实际上，上述的论述过程也反映了自动化时代项目制定功能需求的一面，但不是全部。因为自动化时代仅仅描述了功能需求，但是还需要系统架构来划分模块来完成所有的功能需求。该过程更加适应于信息化时代；这也是为什么引入业务模块的一个根本的原因。虽然，该论述没有引入数据流与业务流的精确一一对应关系，但是它足以说明系统与业务存在着某种对应关系，使得我们可以从业务角度灵活地部署整个系统。