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

类别:Java 点击:0 评论:0 推荐:

 

前言:

       在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,待续!

本文地址:http://com.8s8s.com/it/it16377.htm