观点：CIO应慎选软件开发模型

企业CIO在带领IT团队进行独立软件开发或与软件厂商合作开发，甚至在购买商品化软件后进行二次开发时，都应制定合理的软件开发模型。

据了解，广明亚服装有限公司1999年开始进行信息化建设，当时购买了北京一家软件厂商的财务管理软件，但软件应用1年多后，由于软件开发商不提供维护和软件产品落后（当时在DOS下运行）等原因被淘汰。此后，该公司又选择与浙江本地一家软件厂商合作，定制开发ERP，但由于这家软件厂商实力有限，2002年，其定制开发计划宣告失败。

经历两次失败后，广明亚服装有限公司选择了独立开发ERP软件。目前，该公司独立开发的ERP软件中，人事管理、仓库管理、订单管理、采购管理、生产管理、质量管理、财务管理等模块已经在良好运行，并且该公司还获得了杭州市高新技术产业辅助资金。

其实，像广明亚服装有限公司这样独立开发应用软件并取得成功的企业很多，如宝钢、武钢、益昌薄板、宝供物流、斯达纸业等。他们在进行独立软件开发过程中，无疑都在面临一个问题，如何选择有效的软件开发模型，以更好的理解、发现、诊断、修正软件开发过程中出现的问题，并对软件开发过程中积累下来的经验进行再利用。但软件开发模型的应用绝不仅仅限于这些企业，在独立软件开发，定制、合作开发，甚至购买商品化软件后的二次开发过程中，每一个企业CIO都应考虑适宜的软件开发模型。

磨刀不误砍柴工

目前，大多数大型软件产品都由几十万甚至上千万行源代码构成，例如：Windows95操作系统就由大约1100万行代码组成。每一行代码都可能影响到程序的其它部分，并且各个部分之间又互相影响，一个小小的错误就可能导致整个系统的崩溃。

而且，一些软件项目从一开始就存在许多不确定性因素。这种不确定性首先来自用户需求的不确定。这是因为软件开发者很难详细了解企业业务部门的需求，甚至业务部门在看到产品之前也不清楚自己到底需要什么，所以从项目开发的自始至终，业务部门都可能会有新的需求提出，这致使系统结构不断修改，最终面目全非。

其次，设计不能完全预测。有时，一个设计师认为可行的方案，在实现时可能行不通，或者最初的设计方案存在很大的缺陷而没有及时发现，又或者突然出现一个设计师未料到的技术难点阻挡了软件开发项目的进度。这从另一方面说明了从设计到实现实际上有很多不可预测性。

第三，业务部门需求不断变化，如果最初的需求没有了解得很清楚，可能整个项目很快就会陷在不断变化的需求之中不能自拔。

其四，客观条件不确定，在项目进展过程中，可能会有人员流动，可能会有资源的调整，可能会有这样或那样的客观条件的限制而阻挡了项目的正常进行。 另外，开发人员的过分乐观、外部的压力和项目管理的混乱等因素也会影响软件项目的开发进度，并带来大量不可预知的风险。

然而，在降低软件产品的复杂性、不确定性以及抵御风险能力上，各种软件开发模型的能力和作用是不同的。为避免影响开发进度和导致项目失败，作为企业信息化领导者的CIO应在软件开发前制定合理的软件开发模型和开发方法，致力于软件整体设计、分解并宏观掌控软件的开发步骤和方向，而不要急于编码——磨刀不误砍柴工，前期的投入和整体的掌控会使软件开发项目获得很好的回报。

3个基础支撑软件模型

据了解，瀑布模型最早由Royce在1970年提出，其开发周期为一有顺序性发展与管理程序的集合，其过程排列后，酷似瀑布，故得名。在该模型中，首先确定需求，并接受客户和SQA(软件质量保证)小组的验证，然后拟定规格说明，通过验证后，进入设计、编码、测试、维护阶段。

而迭代式模型是RUP（统一软件过程）组织推荐的周期模型，在RUP中，迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。RUP组织认为，所有的阶段都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，而这个产品是最终产品的一个子集。

为改善面向对象开发的可管理性，玻姆在1998年又提出了一个结合宏观和微观视角的螺旋开发模型，它以活动为主，用来处理资源较为缺乏的瀑布式软件开发模型，尤其应用于需求改变较不频繁的软件开发项目中。

企业CIO在独立软件开发，定制、合作开发，购买商品化软件后的二次开发过程中，往往会听到增量式、进化式、演进式、V型、锯齿型等等各种软件开发模型，但在这些模型中，瀑布式、迭代式、螺旋式模型往往是其开发基础，其它模型多是基于这3种模型的排列与组合或变种而来。例如，增量式和演进式都是迭代式的一部分，增量式适用于软件架构风险较小、但开发工作量较大的软件开发项目，其构建阶段需要多次迭代来实现，每次迭代都在上一次迭代的基础上增加实现一部分系统功能，而演进式适用于项目架构风险较大，需要多次迭代的项目。再如，V型实际上也是迭代的演变，锯齿型则是V型的变种。

而瀑布式、迭代式、螺旋式3种模型本身也相互关联，比如螺旋式与瀑布式软件开发模型有相同的活动内容，但螺旋式对每个活动都增加了数个部分，如风险管理、再利用、雏型等等，称之为周期或环绕（见螺旋式软件开发模型图）。而螺旋式每一个周期遵循瀑布式软件开发模型，即包含决定目标、明确说明限制条件、评估与选择不同方案、确认风险、分析与解决风险、系统发展与验证、计划下一阶段系统产品等内容，但这种模型又可以看作是迭代模型的一种特例，即单次迭代。从这个角度看，螺旋式模型也包含着迭代模型，因此，可以把螺旋模型看作是瀑布式模型和迭代式模型的排列与组合。

开发模型需慎选

瀑布式、迭代式、螺旋式3种模型虽然都是对软件生命周期管理的方法，相互之间也存在一定关系，但3种模型的应用环境和特点却相差很多。

例如瀑布模型强调开发的阶段性，强调早期计划及需求调查，强调产品测试，但其带来的结果往往是系统交付客户之后才发现原先对于需求的理解是错误的，系统设计中的问题要到测试阶段才能被发现；对于项目风险的控制能力较弱；软件项目常常延期完成或开发费用超出预算，项目开发进度往往会被意外发生的问题所打乱，需要进行返工或其他一些额外的开发周期，造成项目延期或费用超支。

另外，在传统的瀑布模型中，需求和设计中的问题是无法在项目开发的前期被检测出来的，只有当第一次系统集成时，这些设计缺陷才会在测试中暴露出来，从而导致一系列的返工：重新设计、编码、测试，进而导致项目的延期和开发成本的上升。

但在早期的软件开发中和现在很多简单的软件开发项目中，瀑布式开发模型应用还很普遍。对于需求简单、目标明确的单一部门级应用软件或大型应用软件的部分简单模块均可采用此种方式，例如简单的办公软件应用或ERP模块中简单、单一的物流、财务、库存软件开发可采用此种模型。

迭代模型与瀑布模型相比有很多优势，其首先允许变更、优化系统需求，通过向业务部门演示迭代所产生的部分系统功能，研发人员可以尽早地收集业务部门对于系统的反馈，及时改正对业务部门需求的理解偏差，从而保证开发出来的系统真正解决他们的问题，其次，可逐步集成元素，在传统的项目开发中，由于要求一下子集成系统中所有的模块，集成阶段往往要占到整个项目很大比例的工作量（最高可达40%），这一阶段的工作经常不确定并且非常棘手。

在迭代式模型中，集成可以说是连续不断的，每一次迭代都会集成一些新的系统功能，但要集成的元素都比过去少得多，所以工作量和难度都是比较低的。另外，迭代式开发模型还可以帮助企业尽早降低软件开发风险，提高IT团队士气以及生成更高质量的产品。由于每次迭代都会产生一个可运行的系统，通过对这个可运行系统进行测试，企业在早期的迭代中就可以及时发现缺陷并改正，性能上的瓶颈也可以尽早发现并处理。因为在每次迭代中总是不断地纠正错误，企业可以得到更高质量的产品。

因此可以看出，迭代式模型解决的主要是对于风险的控制问题，传统的开发流程中系统的风险要到项目开发的后期（主要是测试阶段）才能够被真正降低。而迭代式开发中的风险可以在项目开发的早期通过几次迭代尽早地解决。因此，在大型应用软件的开发过程中，企业应尽量采用迭代方式，把要开发的应用软件分成数个可以完成的阶段性目标，以降低企业软件开发风险。

但需要指出的是，并不是企业应用迭代式模型开发软件后就万无一失，如果对迭代式模型本身缺乏严格的过程管理，生命周期模型很可能退化为一种原始的无计划的“试－错－改”模式。而且因为不断地在进行调整和完善，过早地让业务部门接触尚未测试稳定和完善的软件功能，对开发人员及业务部门人员都会产生负面影响。

而螺旋模型基本的做法是在“瀑布模型”的每一个开发阶段之前，引入非常严格的风险识别、风险分析和风险控制。直到采取了消除风险的措施之后，才开始计划下一阶段的开发工作。其强调了严格的全过程风险管理和各开发阶段的质量，并提供机会以检讨项目是否有价值继续下去，但其因为引入非常严格的风险识别，风险分析和风险控制，对风险管理的技能水平提出了很高要求，并需要大量的人才、资金和时间投入。对于普通企业采用此种方式独立开发或联合开发软件则有些得不偿失，估计只有像微软那样财力、物力、人力齐备的软件公司才会考虑采用此种模型。

但这里还要强调的一点是，在一般情况下，企业软件开发与软件模型之间并不存在对应关系，企业CIO在带领IT团队进行独立开发、联合开发过程中，瀑布式、迭代式、螺旋式3种模式及其衍生模型都可以使用，它们之间的区别主要在对项目风险的控制能力、及时收集用户的反馈信息以及及早对软件进行测试能力上的不同。

来源：信息系统工程