OOA/D的统一构建(UP)过程之一：需求分析阶段USE CASE

 

前言：

       在OOA/D的开发过程中有很多种，比如：up，xp,scrum,dsdm等，不管是那一种都要将项目分解成为一系列的子项目，每次的子项目就是一次迭代，在每次的迭代中对前一次的迭代进行refactory。以前曾经看过Craig Larman的一篇关于OOA/D的文章，里面对开发过程的描述令我获益匪浅，尤其是在实践中的体会更能让人有所启发。作者在对很多应用xp项目的了解中发现，当前没有任何一个成功案例，只是见到很多人宣称正在应用xp。作者的建议是采用更加轻量敏捷的UP方法。

        UP的特点是：迭代开发，TDD（test driven develop），pair programing等等。但是在实践中应该如何操作呢？这就是这篇文章所要讲述的一个UP构建过程。在整个构建过程中会始终贯穿Refactory和Iteration，这也是Up的精华。这是本人在实践中的应用过程，当然也不是十全十美，希望能在讨论中更加完善。

 

图A:UP的不同阶段

 

 

        S:表示开始(START)

        R表示优化(REFINE)

备注：每次的Iteration周期应该保持在10~15天之内，必须要保证deadline。如果发现无法按时完成计划，可以删简一些需求，以保证能按时获得一个比较稳定的版本。两次迭代的间隙中要保留充分的讨论review时间，以确定当前阶段大约还需要几次迭代，安排即将开始迭代的plan（包括refactory）。

 

一、           需求分析阶段

需求分析阶段当然离不开USE CASE。在UML中有一个USE CASE DIAGRAM，这在整个UP中的地位不是很高（这要看USE CASE和SUB USE CASE的数量和系统的复杂度），至少在当前阶段是不重要的。USE CASE DIAGRAM的用处在于可以很清晰的描述： USE CASE之间的关联；系统的整体架构，后面会有详细的描述。更重要的是 USE CASE，它是文字的描述，是对整个系统的需求分析。

1．1、抽象USE CASE 指导原则：(FURPS+)：

1.       Functional（功能性）: 特征, 能力, 安全

2.       Usability（可用性）: 人为因素, 帮助, 文档

3.       Reliability（可靠性）: 失败频率, 可恢复的能力, 可预见的能力

4.       Performance（执行性能）: 响应时间, 吞吐能力, 准确性, 实用性, 资源的使用

5.       Supportability（支持方面）: 适应能力, 可维护的能力, 配置能力;

+ 实现方面,接口方面,运行方面,打包方面

书写USE CASE要在以上的原则下考虑，当然面面俱到是不可能的，不要忘了我们还有REFACTORY和Iteration这两个利器。

 

1．2、 基本业务处理过程(EBP： Elementary Business Process)：

    A task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state.

很简单吧，USE CASE就是像上面的描述那样开始书写的。

1．3、USE CASE的使用者：

不同的USE CASE是针对不同的使用者的，在实际的应用中经常会犯过粗和过细的毛病。USE CASE不是万能的，不要指望通过USE CASE可以将所有的事情都说清楚。

比方说在CRM应用中，某企业的客户经理关心的是如何提高响应度和客户满意度，提高销售额等方面；而对于财务经理关心的是财务电算化提高的工作效率，关心财务数据的安全性等；对于IT经理关心的是如何实施，软硬件的性能；对于总经理可能关心的只是投入产出比。

因此对以上人员的需求描述是要分层次的，从高往低是：

 

河蚌过于详细，不属于USE CASE的内容，如果在USE CASE中出现了thread,socket等词汇时，就是写的过于详细了，因为这应该在Domain model以后才应该出现。因此USE CASE仅仅包括sea level 和fish level。而总经理最多只会看到Cloud level 和kite level。甲方CRM实施小组人员、需求分析人员（SA）、系统设计人员(SD)、PROGRAMER才是USE CASE的真正使用者。

千万要注意项目是在多次的Refactory和Iteration中完成的，不可能在一次的构建过程中将项目完成，否则那就不是UP而是Waterfall了，项目组的成员将会在客户需求的不断变化、技术风险、时间风险中饱受折磨，最终的产品必然面目全非，系统架构混乱不堪。相信谁也无法忘记曾经那牵一发而动全局的感受！

 

1．3、一个USE CASE的书写范例：

 

先这么多了，慢慢来，下次我们说说DOMAIN MODEL,待续！