ATC网友的问题：
请教一下在实际的项目中是如何真正做到迭代的?
例如,任何的需求变更,都从重新分析业务模型开始?
谢谢
解答：
首先我说明一点，并不是任何的需求变更都一定要从重新分析业务模型开始的。这是对迭代的误解，如果什么需求变更都要迭代，那么工作量根本是无法承受的，迭代也会变得无法控制，谁知道需求什么时候变更？迭代并不是因为需求变更而来的。
我们知道RUP倡导迭代的软件过程，RUP定义了四个阶段和九个核心工作流，也知道RUP是可以裁减的。先澄清一个观点，RUP中每一个迭代都可能贯穿这四个阶段和九个核心工作流，但不是一定就会。
要实现迭代的软件过程要做以下一些事：
首先，要定义软件生命周期，即根据项目实际情况和你所处组织的情况，从RUP中裁减出适合本组织和本项目的软件过程。简单说就是规划出本项目要产生哪些可交付物，而可付物决定了你要做哪些过程来产生它们。然后根据RUP定义出这些可交付物产生的流程，例如业务建模过程--->概念建模过程--->分析过程......
其次，要有里程碑计划。即将把上面定义出来的可交付物归纳出来，形成某个阶段我们应该完成哪些可交付物。例如里程碑一要完成业务用例模型、概念模型、分析模型.......；里程碑二要完成界面原型......
上面的工作是制定迭代计划的基础。一个迭代计划是说，在整个软件开发阶段中，根据实际情况，我们需要用几次反复来完成。而每一次反复，我们要完成哪些里程碑里的哪些可交付物。例如第一次迭代，我们要完成里程碑一里的业务用例模型、概念模型和里程碑二里的界面原型；第二次迭代我们要完成全部的里程碑一和全部的里程碑二；第三次迭代我们要完成.....而每一次的反复，我们都要重新检查和更新上一次反复的可交付物。
为什么制定迭代计划一定要先定义生命周期和里程碑呢？这是因为生命周期计划规定了每一次迭代要遵循的标准过程，即怎么做；里程碑计划规定了每个阶段交付哪些产品，即每一次迭代要做什么。迭代，是事先计划好的，不一定因为需求变更而变更，除非这个变更通过变更委员会评审决定后，才有可能调整迭代计划，事实上，如果迭代计划要调整，基本上整个软件计划可能都需要变更了。
所谓的迭代过程，就是在每一次反复的时候，按照生命周期计划里规定的实施流程一步步的，把每一个产生的可交付物根据新的需求，变更的需求，精化的要求，补充的内容再次完成一遍。
很多人混淆了迭代与变更管理，从形式上看，它们的确比较类似。但它们的目标和范围是不同的，或许可以类比为战略和战术的关系。在一个成熟的组织里，迭代是计划性的，不同的项目有不同的迭代次数和计划，而变更管理是管理性的，所有项目都遵循同样的管理流程。迭代是解决软件生命周期问题的，变更管理则是解决质量控制问题的。
不知道我的表述是否清楚了。很感谢你提这个问题，给我提供了一个想法，某天我会就RUP中软件过程是怎么实现的写点东西的。
，不错啊，小坛子，什么给我讲讲
re: 系统分析，业务建模，UML，RUP相关
[回复]
coffeewoo@263.net，这个邮箱不知您是否还在使用，曾发过邮件，未得到回复，呵呵，不知能否得到您的即时联系方式，我的MSN是abel_zhyb@hotmail.com，期待中。。。
审核能作为一个业务用例吗？
[回复]
在业务流程中，审核是经常的必须的环节，不知道在业务建模阶段，是否应该作为一个用例？如果是，则又导致用例非常多！麻烦解答一下！谢谢！
谢谢回答！
[回复]
我的意思主要是审核某种申请或文件，例如是审核物品申请，如样品申请、办公用品申请的审核等，
是否就可以算是一个用例呢？显然，这是存在受体的！也存在可观测的结果，如已审核后的申请表等。
如果把审核申请这一类也算是用例，可能会导致用例粒度太细。如果不包括审核XX申请这一类东西，似乎需求描述不太明确。
re: 系统分析，业务建模，UML，RUP相关
[回复]
另外，在商业模型中，通常一个角色，如部门经理或总经理，
大多会存在大量的申请需要审核，例如营销部门经理通常会审核退换货申请、发货申请、人员招聘申请等，而部门经理通常不是具体的申请流程的起点！
用例粒度的问题
[回复]
coffeewoo,非常感谢您的OO系统分析员之路系列！
这是难得的一个系统分析入门的好东东！
对我的触动和启发很多！非常感谢！
这里有些问题想请教一下，是关于用例粒度的！
你的文章提到：
"在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜。即一个用例可以描述一项完整的业务流程。"
”在用例分析阶段，用例的的粒度以每个用例能描述一个完整的事件流为宜。可理解为一个用例描述一项完整业务中的一个步骤。“
"在系统建模阶段，用例视角是针对计算机的，因此用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜。"
因此,如上所述，在业务建模阶段，似乎一个用例对应一个业务流程，如 申请费用 就对应一个费用申请的业务流程。
假设费用申请的流程或者过程是： 业务员提出费用申请，部门经理审核申请，财务主管审批。
显然，按照业务建模阶段 用例的粒度说明，业务员对应的用例是申请费用。是一个完整的业务流程
而部门经理对应的审核费用申请，财务主管的审核费用申请似乎也应该算是用例。
但是审核费用同时也是费用申请流程的一个步骤。也即审核费用的粒度应该与用例分析阶段的用例的粒度一致。
因此，我想问的是：
业务建模阶段，费用申请这个由业务员启动的用例可以描述一个完整的业务流程。
那么，类似部门经理的审核费用这样业务应该如何在业务模型中描述呢？因为审核费用是费用申请流程中的一个步骤，
若审核费用作为一个用例，它的粒度与业务员的费用申请的粒度应该是不一致的。
用例规约的事件流描述中可以引入其它的actor吗？
[回复]
大赞
这两天一直在咖啡小驻学习，对我这么一个初学者是莫大的帮助。
接着cloud的问题继续提问：
最近在做考勤系统的分析，也是遇到了cloud类似的苦恼。
针对“申请出差”这个用例，我是如下这样描述事件流的
1、员工提出出差申请
2、部门领导审批申请
3、人事专员审批申请
请问这样描述合适吗？应该怎样描述比较好，谢谢！
re: coffeewoo
[回复]
非常感谢coffeewoo及时地解答我的问题。
可能是我刚才没有描述清楚我的问题，我再详细描述一下。
我现在想做一个公司考勤系统，用于员工签到签退，各种假勤和加班等的申请与管理，人力资源部制定排班计划等。
本来已经画了一个rose图，不过现在手头没有，那我就用文字描述一下：
目前我抽象了几个actor：员工、人事专员、部门领导、公司主管
各个actor相关的usecase如下：
1、员工：签到、签退、申请加班、申请调班、申请休假、申请外出、查询个人排班、查询个人考勤
2、人事专员：排班、管理加班、管理调班、管理休假、管理外出、查看考勤统计报表
3、部门领导：管理加班、管理调班、管理休假、管理外出、查看考勤统计报表
4、公司主管：查看考勤统计报表
由于考勤系统中很多业务都是一个流程，所以我写的用例规约就是描述该用例对应的业务流程的步骤，以“申请出差”为例：
用例规约：申请出差
1. 用例名称
申请出差
1.1 简要说明
此用例描述员工通过考勤系统是如何进行申请出差操作的。
2. 事件流
计划外出的员工登录系统并选择“申请出差”后开始该用例。
2.1 基本流
1、员工提出出差申请
员工填写计划出差时间、地点和缘由
2、部门领导审批申请
系统提示部门领导审批申请，部门领导审批申请
3、人事专员审批申请
系统提示人事专员审批申请，人事专员审批申请
2.2 备选流
……
3. 前置条件
员工已登陆系统并选择“申请出差”操作。
我对用例规约的理解是描述actor为了实现usecase的目的，actor与业务系统交互的过程。
那么，我有几个问题：
1、用例规约中可以出现其它actor吗？比如说“申请出差”中的部门领导和人事专员
2、当actor发起一个usecase时，会产生一些信息，由系统主动传递给其它的actor，这个需要出现在用例规约中吗？比如说“申请出差”中的系统提示部门领导审批申请
3、当一个usecase的业务场景中，需要其它actor的行为，需要在用例规约中出现吗？比如说“申请出差”中的部门领导审批申请
coffeewoo，不知道我这样是不是说清楚了，谢谢
re: 上面那个问题
[回复]
coffeewoo，我还有一个想法就是引入工作流系统，不过想法还不成熟
每次申请时，都是员工提出申请，传递申请信息给考勤系统，然后考勤系统将申请信息传递给工作流系统，工作流系统将审批结果传递给考勤系统，考勤系统将审批结果传递给员工
不过感觉这样把部门领导审批给遗漏了。
请coffeewoo指点一二，谢谢！
最低0.47元/天 解锁文章
4562
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
