DevSuite 实践之瀑布篇（一）

谈到瀑布模型，我想懂的人可能一听到这个词，瞬间就在想，都已经被淘汰的方法论了，还提它作甚？

 

那真的已经被淘汰了吗？我说是未必，虽然现在的确敏捷很流行，但是敏捷不一定适合所有的开发类型，在一些特殊的行业或者特殊的产品中，瀑布还是很实用的，它们本来就不会追求敏捷，只在乎质量，所以敏捷恰恰对于他们来说没有意义。

 

我想你应该能够猜到这些行业或者软件是什么了，其实想想也很多的，比如银行的交易系统，股票交易系统，军事航电系统等等，这类系统都有一些相似点：

 

开发周期长：一般一套系统，即使表面功能看起来比较简单，都可能需要开发一年两年时间，因为这种系统界面上只要实现基本的功能就行了，而后台要保证数据的完整性和正确性，不能出一点点差错，大家知道这种交易软件，出一点差错就是几千万，几个亿的资金量变化了。

 

更新速度慢：这类系统一般不会经常更新，一句话，只要够用就行了，只有实在不够用的时候才会想到要更新，人家国外的股票系统，用了几十年了都没换过，为什么呢？之前没出过问题啊，现在好像用用也还行，干嘛要去换，一换万一出问题怎么办呢？

 

需求变更少：一般这类系统，由于垄断性的原因，使用的人只能使用着，而无法要求需求这么改或者那么改，所以就意味着一般不需要去做需求变更的。我们经常到银行存取钱，看到他们的系统一般都是Unix、Linux下的，这个倒还好说，但是看看他们的操作界面，真的只能以惨不忍睹来描述了，我自己做出系统的界面都比他们那个漂亮很多。那些银行员工难道就没意见，不可能的，但是虽然不漂亮，对于正常的存取钱的使用好像也没什么影响，所以对于这种界面的需求变更一般就忽略过去了，可能等个五年十年时间，累积了一定需求了以后，再花个五年时间开发一套新系统，到时估计界面就好看点了。

 

你说这类系统如果用敏捷怎么来搞？ 所以瀑布其实还是有一定的用武之地的，下面来看一下瀑布模型的结构图：

 

 

这是一个比较全面的瀑布流程图，从可行性研究，到需求分析、概要设计、详细设计都覆盖了，然后是编码、单元测试、组装测试、确认测试、运行与维护，最后退役，整个一个完整的软件生命周期。

 

这些一个个的流程，包括软件工程本身，甚至是瀑布模型这个概念，其实都是理论性的东西，都是些方法论，它们的提出，只是对于软件开发工作的一个方向性指导，但是具体如何去实施，其实是另一个重要的命题了。

 

伟人说过，实践是检验真理的唯一标准，所以我们所有的理论知识，需要通过实际的操作来应用才能知道这个理论是否有用，那我们本文的目的是为了跟大家探讨如何在实际开发中操作来实现瀑布模型。

 

对于瀑布模型，由于它的流程有严格的顺序，所以本文的介绍也是按照流程的顺序来进行的。对于大部分的产品或者项目的开发来说，一般都需要借助专业的研发管理工具来进行管理，不然整个开发过程质量将无法得到控制，对于瀑布模型来说，这个就更加重要了，所以本文的介绍，会结合业界最专业的研发管理系统 DevSuite 来进行介绍。

 

首先简单了解一下 DevSuite 系统，DevSuite系统是ALM领域巨头美国 TechExcel 公司通过几十年在该领域不断摸索、不断累积经验、不断创新而开发出来的一整套软件生命周期管理系统，它覆盖了产品的概念形成、需求分析、项目规划、到任务跟踪和质量测试等全生命周期管理，可以帮助有效地控制需求、资源、工期和质量，规范和改进产品研发过程，提高产品质量和工作效率。

 

我们接下来就开始结合 DevSuite 来分析如何实现一个产品在瀑布模式下从可行性分析开始最后到交付的整一个过程。

 

 

 

对于瀑布模型而言，第一个过程就是可行性研究，然后就是需求分析，概要设计和详细设计，我们把这几个过程都归类成一个过程，叫做需求设计阶段，因为这个阶段做的事情，基本上就是把这个产品需要完成什么样的功能给提炼并设计出来，不管你是需求分析还是概要设计，还是详细设计，最终目的都是为了这个，所以我们把它们算成一类。

 

 

 

那我们来看看在 DevSuite 中如何来完成这个过程的呢？DevSuite系统中有专门管理需求的模块，大家可以在如下的界面中看到，

 

 

 

 

对于任何的需求点，不管是客户的需求还是自己公司的一些想法，最终都会转化成一个设计文档来让开发来实现，所以在 DevSuite 中，我们首先需要将客户的需求或者自己公司的一些想法创建到需求管理这个视图中。

 

 

 

创建需求的过程很简单，DevSuite可以定义各种类型的字段，使得任何的需求都能在这里被描述得很清楚，如果原始的文档时保存在Word格式里的话，DevSuite还能自动将Word格式里的需求导入进来，甚至是你在Word里修改，然后可以直接同步到DevSuite里。

 

 

 

对于已经创建或者导入进来的需求，DevSuite通过工作流对其进行管理，所谓的工作流就是一个需求从刚刚提出到可行性分析，再到设计，然后是审核，最后交付开发去完成的这么一个流程，当然这个是一个最简单的功能，DevSuite中还可以根据需要自定义任何复杂或者简单的工作流程，这种流程的设计，使得一个需求一般情况下只要走完一个流程就能成为一个可开发的功能点了（当然，还有可能是被放弃或者延迟到下一个版本）。

 

 

 

在需求设计过程中，DevSuite能够记录跟踪记录任何一次的修改，以便你可以随时查看以前的设计甚至回滚到之前多少天的设计上。

 

 

 

当所有需求完成设计并审核通过以后，就可以开始记录开发阶段了。

 

 

 

对于开发阶段，首先要做一下项目规划，也就是说这个产品或者说这些需求点计划什么时间内完成，会投入多少人力资源等信息。

 

 

 

在DevSuite中有相应的项目规划模块（如下图），可以帮助定义项目的计划开始与结束时间，并且还可以根据投入的人力资源以及实际的工作进展来分析项目是否能够按时完成。此外，还提供了甘特图，可以看到项目的实时进度。

 

 

 

 

 

在项目规划模块中，我们还可以设计更加细致的计划，比如我们想把可行性分析以及需求分析与设计那个过程也一并来规划一下，这样子的话，这个规划就是对于整个产品生命周期的一个规划了，而不是之前从开发过程开始的规划。对于这种规划，我们一般需要建立许多个里程碑，比如完成需求提取是一个里程碑，完成设计也是一个，完成开发当然也算，最后完成测试更是一个，每个里程碑之间有严格的时间规划，比如第一个里程碑从2013年1月开始，10月份结束，那第二个里程碑就得从11月开始，当然 DevSuite 允许中间有些缓冲地带，可以提前或者延迟一段时间，方便由于估算的不精确导致最终的时间不精确。

 

 

 

完成项目规划以后，就要真正开始的开发工作了。