ATC网友的问题：请教一下在实际的项目中是如何真正做到迭代的
例如,任何的需求变更,都从重新分析业务模型开始
谢谢
解答：首先我说明一点，并不是任何的需求变更都一定要从重新分析业务模型开始的。这是对迭代的误解，如果什么需求变更都要迭代，那么工作量根本是无法承受的，迭代也会变得无法控制，谁知道需求什么时候变更？迭代并不是因为需求变更而来的。
我们知道RUP倡导迭代的软件过程，RUP定义了四个阶段和九个核心工作流，也知道RUP是可以裁减的。先澄清一个观点，RUP中每一个迭代都可能贯穿这四个阶段和九个核心工作流，但不是一定就会。
要实现迭代的软件过程要做以下一些事：首先，要定义软件生命周期，即根据项目实际情况和你所处组织的情况，从RUP中裁减出适合本组织和本项目的软件过程。简单说就是规划出本项目要产生哪些可交付物，而可付物决定了你要做哪些过程来产生它们。然后根据RUP定义出这些可交付物产生的流程，例如业务建模过程--->概念建模过程--->分析过程......
其次，要有里程碑计划。即将把上面定义出来的可交付物归纳出来，形成某个阶段我们应该完成哪些可交付物。例如里程碑一要完成业务用例模型、概念模型、分析模型.......；里程碑二要完成界面原型......
上面的工作是制定迭代计划的基础。一个迭代计划是说，在整个软件开发阶段中，根据实际情况，我们需要用几次反复来完成。而每一次反复，我们要完成哪些里程碑里的哪些可交付物。例如第一次迭代，我们要完成里程碑一里的业务用例模型、概念模型和里程碑二里的界面原型；第二次迭代我们要完成全部的里程碑一和全部的里程碑二；第三次迭代我们要完成.....而每一次的反复，我们都要重新检查和更新上一次反复的可交付物。
为什么制定迭代计划一定要先定义生命周期和里程碑呢？这是因为生命周期计划规定了每一次迭代要遵循的标准过程，即怎么做；里程碑计划规定了每个阶段交付哪些产品，即每一次迭代要做什么。迭代，是事先计划好的，不一定因为需求变更而变更，除非这个变更通过变更委员会评审决定后，才有可能调整迭代计划，事实上，如果迭代计划要调整，基本上整个软件计划可能都需要变更了。所谓的迭代过程，就是在每一次反复的时候，按照生命周期计划里规定的实施流程一步步的，把每一个产生的可交付物根据新的需求，变更的需求，精化的要求，补充的内容再次完成一遍。
很多人混淆了迭代与变更管理，从形式上看，它们的确比较类似。但它们的目标和范围是不同的，或许可以类比为战略和战术的关系。在一个成熟的组织里，迭代是计划性的，不同的项目有不同的迭代次数和计划，而变更管理是管理性的，所有项目都遵循同样的管理流程。迭代是解决软件生命周期问题的，变更管理则是解决质量控制问题的。
不知道我的表述是否清楚了。很感谢你提这个问题，给我提供了一个想法，某天我会就RUP中软件过程是怎么实现的写点东西的。
在业务流程中，审核是经常的必须的环节，不知道在业务建模阶段，是否应该作为一个用例？如果是，则又导致用例非常多！麻烦解答一下！谢谢！
我的意思主要是审核某种申请或文件，例如是审核物品申请，如样品申请、办公用品申请的审核等，是否就可以算是一个用例呢？显然，这是存在受体的！也存在可观测的结果，如已审核后的申请表等。如果把审核申请这一类也算是用例，可能会导致用例粒度太细。如果不包括审核XX申请这一类东西，似乎需求描述不太明确。
另外，在商业模型中，通常一个角色，如部门经理或总经理，大多会存在大量的申请需要审核，例如营销部门经理通常会审核退换货申请、发货申请、人员招聘申请等，而部门经理通常不是具体的申请流程的起点！
非常感谢~很有启发！
coffeewoo,非常感谢您的OO系统分析员之路系列！这是难得的一个系统分析入门的好东东！对我的触动和启发很多！非常感谢！这里有些问题想请教一下，是关于用例粒度的！
"在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜。即一个用例可以描述一项完整的业务流程。"”在用例分析阶段，用例的的粒度以每个用例能描述一个完整的事件流为宜。可理解为一个用例描述一项完整业务中的一个步骤。“"在系统建模阶段，用例视角是针对计算机的，因此用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜。"
因此,如上所述，在业务建模阶段，似乎一个用例对应一个业务流程，如申请费用就对应一个费用申请的业务流程。假设费用申请的流程或者过程是：业务员提出费用申请，部门经理审核申请，财务主管审批。显然，按照业务建模阶段用例的粒度说明，业务员对应的用例是申请费用。是一个完整的业务流程而部门经理对应的审核费用申请，财务主管的审核费用申请似乎也应该算是用例。但是审核费用同时也是费用申请流程的一个步骤。也即审核费用的粒度应该与用例分析阶段的用例的粒度一致。因此，我想问的是：业务建模阶段，费用申请这个由业务员启动的用例可以描述一个完整的业务流程。那么，类似部门经理的审核费用这样业务应该如何在业务模型中描述呢？因为审核费用是费用申请流程中的一个步骤，若审核费用作为一个用例，它的粒度与业务员的费用申请的粒度应该是不一致的。
谢谢二位的耐心解答！
大赞这两天一直在咖啡小驻学习，对我这么一个初学者是莫大的帮助。接着cloud的问题继续提问：最近在做考勤系统的分析，也是遇到了cloud类似的苦恼。针对“申请出差”这个用例，我是如下这样描述事件流的1、员工提出出差申请2、部门领导审批申请3、人事专员审批申请
请问这样描述合适吗？应该怎样描述比较好，谢谢！
由于考勤系统中很多业务都是一个流程，所以我写的用例规约就是描述该用例对应的业务流程的步骤，以“申请出差”为例：
我对用例规约的理解是描述actor为了实现usecase的目的，actor与业务系统交互的过程。那么，我有几个问题：1、用例规约中可以出现其它actor吗？比如说“申请出差”中的部门领导和人事专员2、当actor发起一个usecase时，会产生一些信息，由系统主动传递给其它的actor，这个需要出现在用例规约中吗？比如说“申请出差”中的系统提示部门领导审批申请3、当一个usecase的业务场景中，需要其它actor的行为，需要在用例规约中出现吗？比如说“申请出差”中的部门领导审批申请
coffeewoo，不知道我这样是不是说清楚了，谢谢
coffeewoo，我还有一个想法就是引入工作流系统，不过想法还不成熟每次申请时，都是员工提出申请，传递申请信息给考勤系统，然后考勤系统将申请信息传递给工作流系统，工作流系统将审批结果传递给考勤系统，考勤系统将审批结果传递给员工
不过感觉这样把部门领导审批给遗漏了。
请coffeewoo指点一二，谢谢！
tocoffeewoo，我定义的管理加班的确只有审批，浏览、查询、统计等都归到查看考勤统计报表
之所以这样，我可能是有点仿coffeewoo给的那个图书馆的例子在那个例子中，借阅管理员的所有用例（除了查看借阅记录）都应该是借阅人的操作驱动的，而不是借阅管理员自己发起的
这样我就有一个疑问：在业务阶段，像“管理加班”和“颁发借阅证”这种不是由actor主动发起的事件，是不是应该作为用例出现？如果不作为用例出现，那这种事件如何体现在业务建模阶段？
感谢！问一个比较基本比较教条的问题：业务、概念和系统阶段分别应该产出哪些内容和图？
我只想回答第一个问题,可以的,两个actor同时对一个用例起作用是没问题的,关键在于如果你这么画了,那么在描述时就有必要在两个actor工作的这个用例场景中分别详细描述,因为归根结底,它属于两个不同场景的工作.用两个用例或许更清晰,不过你画成了一个,这说明你抽象了,但是在描述时还要描述清晰的.而且在系统用例阶段,并不是人才是actor,连一个子系统也可能是actor,所以,你既然已经得到了一个子系统,那么一个用例也可能指向另一个子系统.正好说到了子系统的概念,我想问一下coffeewoo,除了使用常见的UC矩阵(use/creat)方法来划分外,还有其他比较好的方法吗,或者你一般是怎么分的(拍脑瓜,凭经验的方法除外)^_^
谢谢，明白了许多。以后可能还有很多问题向coffeewoo和rwyx请教有一个问题就是在coffeewoo上面的回答中，提到检查和借书两个用例，我怎么感觉检查这个用例也不是主动用它，而是由读者的借书用例驱动
不得不说的是,你的这个做法是有效的,不过并没有解决我的提问.为什么呢呵呵因为你这个做法其实就UC矩阵的做发呀,只不过UC矩阵用的是矩阵中Create和use来归纳工作和实体,然后手动将U/C两类数据进行不断移行,形成U/C交集点得到各个子系统.而你的做法,虽然没有这么做,但你是将控制类和边界类与实体类进行分析合并,这个就等于是默默得在将use动作和create动作在不断的移行.到达user和create的交集.(coffeewoo式做法)
你的观点很清楚,也很明确,看起来我们最大的分歧点的确是在于子系统的定义,你的子系统的定义是为设计服务的,而我的子系统的定义则是为系统用例服务做指导的.另外,你用MVC模式和门面模式来阐述你的观点,还真是第一次见到有人这么说啊^_^以武会友的话,最后应该说一句"佩服"
谢谢!
谢谢您的回答.那我能不能做这样的理解,您给的那个例子中,业务过程视图部分是属于业务视角方面的,而用例实现是属于系统用例方面的,因为用例实现是有加入计算机进行理解与设计了;如果是这样的话,是不是要把用例实现的部分放到系统用例模型的文件夹中来.我有点搞蒙了.
关于用例实现，我想说明一下，用例实现通常是被作为分析视图来给出的，因为它想告诉的是系统究竟怎样完成这个用例，而用例实现的每一个用例都是系统用例。所以具体做的时候就应该在逻辑视图下建立一个分析视图，然后把系统用例的每一个用例拉进来做用例实现。还要说明的是用例实现和用例描述是两个概念，用例实现更倾向于用例中对象的合作（这个对象的概念是业务对象），而用例描述则专注于对用例本身的描述。前者已经说过了是属于分析模型，后者则属于系统用例部分的工作
现在学习UML有点晕了请问coffeewoo和rwyx：同一个用例可能有多个actor发起吗？比如说加班业务：员工申请加班，直接主管审批，然后部门助理可以设置加班，人事专员也可以设置加班这个时候是不是可以把部门助理和人事专员合并？
但是部门助理可以查看部门考勤情况，而人事专员可以设置考勤参数、查看公司考勤情况等（部门助理不可以）请问这种情况下，可以合并两个actor吗？这两天和同事讨论了很久都没有结果
多谢coffeewoo的回答为什么部门助理也可视为发起加班业务的actor，那人事助理是不是也可以？应该说只有员工申请加班，其他的actor才会共同奉献于加班业务
呵呵，我觉得吧，coffeewoo还是把系统用例和业务用例分出来吧，不然大家都会问这个问题的哦。
另外，回复duxiangyun一下，当你觉得几个actor多用例都有动作的话，那我建议你不要考虑对多个actor都明确分为“员工，主管，助理”，而是可以抽象一个actor，因为这个在设计人员设计时他会考虑某个actor有某些权限，而不会以职位来定死这个actor做什么。也就是说权限、职能、角色三者的关系：一个角色多个权限一个角色一种职能（纯业务角度上讲，理论上这个需求只有在客户明确要求的情况下才应该实现）一种职能多个权限（这个是考虑默认职能和权限的关系，但最终还是角色和权限的关系）
多谢coffeewoo的解答心中疑问.您回答的好快呀!感动中ing...偶刚开始学uml,刚学着使用Rose,再次感谢您的导航.以后可能很多疑问请教您哦!
在做分布式系统需求时,使用uml业务建模,是按服务器、客户端分开描述需求,还是一起描述
关于边界类和控制类有点疑问：比如我有一个对话框用来接收用户输入的e_mail，同时该对话框对该e_mail的合法性进行验证，比如不能缺少@符号....这个当然是设计好以后的，但是在分析阶段我是作为两个类出现的：边界类、控制类。但最后确实只有一个类，疑惑......
上面的疑问不知我写的是不是清晰？我在重新解释一下：我有一个业务，检验输入E_mail的合法性，分析模型我是这样建的：用户--边界类--控制类，实现的时候我是这样做的，建立一个Dialog类，其中含有boolIsValid();这个函数实现合法性检验。疑问产生了我发现这个控制类所作的一切实际上是这个边界类的一个功能。我想问：是我的分析模型建的不对，还是我的设计有问题？按你前面说的“需求可追溯”，我这里应该设计边界类和控制类，并给出实现，但我的做法是控制类所作的成了边界类的一个功能。在实际中是不是有这种情况？分析模型中的一些个分析类成为另一个分析类的一部分（作为这个类中的一个功能出现）。
您真是年轻的ＩＴ高手，因为某些原因，要学习＂系统分析＂有关知识，也就借这机会认识您了（昨晚才认识您哦），真有点相见恨晚的感觉！！！呵呵
俺是菜鸟，说过错了表打。
看那个例子中，usecaseview和logicview各有三个过程，其他都明白，就是不太清楚logicview中的BusinessModel是需求分析的产物还是系统设计的产物，或者说，BusinessModel是在什么阶段产生的，分析员做的还是设计师做的？谢谢
谢谢coffee兄这么快回复，我还是有些不清楚，能不能简单说一下BusinessModel和BusinessusecaseModel的关系。
为什么要把BusinessModel放到逻辑试图中？
我个人感觉放到用例视图中不是更合逻辑，层次更清楚吗？因为这样所有需求分析的产物都在用例试图中了。。。
hi..你好。这几天一直在学习你的提供的那个html的demo.有一些疑问：一：在你的目录分层的结构的基本用意是什么呢？如-UseCaseView|---Businessusecasemodel(A)|---Analysisusecasemodel(B)|---Systemusecasemodel(C)-LogicView|--SystemModel|--AnalysisModel|--BusinessModel|---BusinessEntityModel(D)问:1）“A“是否存放着业务建模的businessactor,businessusecase2）那么"B"它会放什么呢3)你在前面有谈到，你现在做的是系统用例实现，而不是"业务用例实现"？那么，请问，系统用例是从何推断出来的呢？它跟"业务用例"是什么关系吗？有没有可能，系统用例是通过"业务用例实现"的活动图来推断出来的？4）同上述3）的问题，那么，系统actor是如何从businessactor推断出来的呢
4)
你在用例分析系列中提到，业务建模应该完全是用户语言，业务视角，最终的产品的需求规格说明书，我想问个问题：一般的应用系统都会有“系统管理”这个模块，里面包含基础数据、用户、角色、权限和日志等控制功能，那么在业务建模中应该不会涉及到这些“计算机视角”的东西，是否在需求中也没必要描述这些功能，只描述对用户有直接业务价值的用例。
PS：俺用你的理论做了一个项目的业务模型，忽略计算机视角的东西，只得出10个业务用例，心中惶恐不安。。。
还有一个问题，也希望coffee兄一并解答，菜鸟无奈啊，见谅。。。
从俺的理解看来，在业务模型中似乎不应该出现include，extend这样的关系东西，因为用例的逻辑关系是在概念模型中分析出来的。
但是我的例子中有这样的问题：用户的需求明确含有查询、统计、汇总这样内容，但是我通过画活动图发现，这些功能的目的都是“检查数据”，所以似乎应该合成一个业务用例“检查数据”，但是这样又似乎忽略了客户的业务需求，如果分解开，感觉业务场景图画不好了，因为这是一个活动。。。
到底应该是查询、统计、汇总三个用例呢？还是“检查数据”一个用例，如果是后者，我的业务场景图不会画了。。。
hi，coffee，
coffee兄：能不能说一下系统用例模型中的角色是如何划分的，或者说划分角色的依据是什么？我遇到一个这样的问题，我做的系统用例模型中有一个角色叫“业务人员”，大部分系统用例的执行者都是它，为了减轻它的负担，或者说让图形更好安排，我想再增加一个角色叫“信息化人员”，在实际工作中，这两种角色在客户那边没有特别严格的区分，我想问的是：在系统角色方面，是否有这样的随意性？
我觉得建模应该有一个规模边界，对于很庞大的系统，用模型来描述，反而会因为太多的模型元素，而会导致无序和混乱。比如银行系统，银行面向客户提供很多服务，比如存款、贷款、结算、汇划、外汇、债券等等，还有很多衍生服务，这些服务都是依托一个庞大的系统来运作的，而且还在不断的优化改进中……这样一个庞大的系统，如果作为一个模型来维护，里面将有成千上万的用例；如果切分成不同的业务模块，又很难用一个唯一的标准来进行切分；目前的思路，只能按照开发任务来进行建模，但这样，势必又导致很多元素在不同模型中都有表达，并且表达不唯一。我们在建模方面也是刚起步，所以，感觉思路有些混乱，不知道咖啡兄有无好的建议，谢谢：）
coffee老兄，请教您一个问题，我们知道RUP有四个阶段和九个核心工作流，能不能谈谈，如何把RUP的软件过程的项目目标和软件工作量估计之间的关系呢？如何在项目初始阶段估计软件项目的工作量呢？在RUP中，如何估计软件的整体工作量呢？多谢啊！
coffeewoo老兄请教一个问题。比如现行开发一个贷款项目，该系统以socket的方式为其他系统提供贷款功能服务。如客户资料查询，循环额度贷款等。客户资料包括客户基本身份资料查询、账户资料查询以及客户授信额度查询3个子交易。循环额度又包括客户已贷款查询和贷款额度查询子交易。类似此类为其他系统提供服务的业务系统是否适合用oo来建模分析。如果适合又如何进行业务建模和系统建模呢。感觉上用面向过程的是否会更适合些？
针对举例设定消费者柜面程序为业务角色，服务提供者贷款业务系统提供的客户资料查询以及循环额度贷款为业务用例，那系统用例呢？是否两个一致呢？假定客户资料包括客户基本身份资料查询、账户资料查询以及客户授信额度查询3个子交易。是否3个子交易就可认为系统用例呢？业务用例是否就是开发系统为客户端程序提供的服务接口呢，系统用例为所提供接口的内部步骤呢？如果假定业务用例为服务接口，系统用例为内部步骤，而当内部步骤十分简单时，是否直接将业务用例转化为系统用例呢？另外如果设定资料查询为业务用例，描述业务场景的时候只有单泳道，这种情况是否正常呢？如果业务系统中的其他业务场景也大都为单泳道，这种情况是否正常需要进行改进呢？开发此类系统（即为其他系统提供服务的计算机系统）时，业务建模和系统建模，以及业务用例和系统用例的区别又在哪里呢？