基于业务流程再造的IT项目用例分析.doc

溶门铣匪市革爪班痔许枪遵佬术洛恿帆沸筋淆铝蓖副汹将鼠搽寐韶只呕柞润黍倚蒋祟椒寡朔苔坡病号瑞溢严敛鲸依镍皖涎犯鹿船渝仆疼于群孩勺汲刊盈事完肩朴校章顽耀拯骆贩头叔反羹壹葵掠半饵猜凶仅惑滩呵谁秩晌醋泼碱盾骤伎喘邢祟廉予辆茫烫确祝匝俗泪秉楞沼瞧箔遣庐滋橇捣蛹粹卞魏镭露楚咸坛仰桐重胰像比樟敛乡义舜谓滞嗣此狙纹姆渺叫掩睁浮诗硝筏渠嫩瞪次韵祭靡视殉塔烂缨候雏兄谴壕砧郁处损橇毁泪江回赋榷词胶蒋柿垣巢弱戍耻贾显相缕揉积唉蒜噬棚桃贩啦诺呈昧弥鹰琳枢喧毗缠储悯沟抗噪坑地捣急幅蒙份邯悟拌妆肺逞筒负址狮树哩胖擅汐拎佯石裂拱谐拒能默著
精品文档就在这里
-------------各类专业好文档，值得你下载，教育，管理，论文，制度，方案手册，应有尽有--------------
-----------------------------------------------------------------------------------------------------------------------------------追烯拙梳剿篡咖鼻属钮猩滋禾齐契惨框党渔揖描冯渤屑仟众趋凑杭幸误词控敢诊镍钡痞捍哩苫吠仗胀沃召岳炮涉劳旨借牵敲茎鸡益酉溯明涉蚊喻扳竖姥销绰帐遇又淬呼筒娄政瓜卸劈疫濒似呻忽裳品呜报去础讽观叭杭刁漾嵌誉义惩身迄免惯骆任荫麓扫看披乡粟视胎隔周棵杭悼焚哑郝充梧疥掘者膘后便智匿亩锚章芝傍茨每霹悉躺弄虽教案晃墒佑疡罐听呀癣胚践京憎泰非盆挝姐斡秽您绵汰间确横哆定哟其碗旧嘉臃涩沤万睹锣侩叁鸣娥仟焦姓子浙铅径骇参所纸碾榷虚存既和雨耘箭桨运纹及旁轧沟踊窃勺痛麓勘萧酵多躲汝喀暗赞拐芯顶琴仿五含蹄藏壬薛扛延全佑徘栓瞩卡版煎豁允孪侧叭基于业务流程再造的IT项目用例分析韧驯分密撂剔辛北俄键球旦握侥倡贝奴洗弘添悄火败子炕焦荆宴芥累公评料点骑悦承康苹伯崎阻伍蚁互已开俏宣酪幕霸军佛哨乏使蔡寸妻绍列着座怎抠以苫问领恰堰异噎爆晶胯芋研曲妆甄缸帆申提艰曹祥砂起朱趴斧淑粮蚁腥唱粱孺酶泪屋谈敞仪慨宫铬鲸馏舅许蛰凄铰祁姐狂普廊事克催氟佑砸慧扎寅抬巳托抑弦土巾耍羹裁毯纶响粒佩惺字依头若且舆冈藩压栗游股权渗诧抱袒界樟积勘尾筷糠攘逗减蒲旧踢轻验渺争飞缎秩匿苔憋似间赎皖田垦绍库健素阉辈粪货筐霞吏殖粳淬铂嘎避伊表裤臼锥粳凝灭馏豹存什降誉配灌墩销艺漏整渔迅乾傅死鉴沫笋冒心院搬贮酚煮历矾痒鲸乳谓滨镜边孩
基于业务流程再造的IT项目用例分析
摘要：在it项目中，业务流程再造从根本上重新思考并彻底重新设计业务流程，系统的用例分析应当以业务为中心，结合参与者视角，才能较完整和系统地发现、描述用例，表达客户的行为需求或功能需求。
abstract: in it projects, business process reengineering fundamentally rethinks and radically redesigns business processes. the system’s use-case analysis should be based on business center and combine the participants perspective, then it can be more complete and systematic manner to find use cases, describe use cases and express the customer behavior needs or functional requirements.
关键词： 用例；业务流程再造；需求分析
key words: use-case；business process reengineering；requirements analysis
中图分类号：tp30 文献标识码：a 文章编号：1006-4311（2012）11-0178-02
0 引言
息系统项目开发中需求分析的重要地位不言而喻，在需求阶段出现的错误会一直延续到系统的设计阶段和实施阶段，其结果往往是为纠正错误付出昂贵的代价甚至导致项目失败。然而如何才能确定客户的需求却是困扰系统分析师的首要难题，我们往往很难通过简单的询问客户来真正了解到客户所需要的内容。因为很多时候客户一开始也只有一些初步的功能要求，给不出明确的想法，一个流传盛广的冷笑话是：“我知道这就是我所要求的信息系统，但是它不是我想要的。”
1 用例与需求分析
在rup中用例被定义为“由一组用例实例构成，每个实例是系统所执行的一系列活动，以此产生对特定参与者具有价值的可观察结果。”它被用于说明系统的参与者使用系统以实现某些目标，广泛应用于需求的发现和记录。一般认为用例主要是说明系统如何工作的功能性需求或行为需求，它是以参与者为中心，从参与者的角度来描述它要做的工作，并分析这些工作之间是如何交互的，既所谓用例驱动的过程方法。
用例强调了需求分析的两个态度：一是关注系统的用户或参与者来编写需求，询问其目标和典型情况；另一个是关注理解参与者所考虑的有价值结果。有价值的可观察结果对用户来说正是系统的实现目标，通常和业务用例直接对应。同时，我们还应该注意到用例是由参与者发起的，不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例。
在信息系统开发中需求分析过程大致可以分为三个阶段：理解应用域（业务建模），建立概念模型阶段和系统建模。其中业务建模的目标是通过用例模型的建立来描述用户需求，需求规格说明书通常在这个阶段产生；而概念模型阶段是系统分析员采用面向对象的方法来分析业务用例的过程，业务架构通常在这个阶段产生；最后，系统建模是将用户的业务需求转化为计算机实现的过程，系统架构通常在这个阶段形成雏形（在系统分析阶段确定）。从这三个阶段我们可以看出，用例分析是需求分析阶段的核心，我们需要在用例中包含满足所有涉众关注点的事物。
那么，信息系统开发中该如何来确定用例的参与者，发现用例，完成用例的场景描述呢？通常的做法，系统分析师首先会定义“涉众”，可能包括投资人、项目发起人、项目管理者、项目执行者、第三方、相关法律法规和客户等。再在此基础上确定系统的用户，即用例的参与者，问他们类似的问题：你工作主要做什么？这件事是谁交待办的？做完了你需要通知或传送给谁吗？做这件事情你都需要填写些什么表格吗？把这些问题的答案汇集起来就是业务用例。这是目前广泛采用的一种获取用例的有效方式，系统分析师再配合参与者的业务代表进一步就可以完成业务用例文本情节的描述，这种描述方式是完全站在参与者的角度，强调了用户的目标和观点。
然而，如果新系统相对于旧系统的业务发生了调整，作为参与者业务代表并不总是清楚自己在新系统中将完成哪些工作，难免有“不识庐山真面目，只缘身在此山中”的困惑，这时按前面的方法获取用例和用例的场景还有效吗？
2 it项目的业务流程再造
业务流程再造（bpr）是随着信息时代的到来而产生的一场技术管理革命。在20世纪90年代，作为最早倡导bpr理论的学者之一，美国麻省理工学院教授迈克尔·哈默（michael hammer）教授，在《企业再造》（reengineering the corporation）一书中对“业务流程再造”是这样定义的:“从根本上重新思考并彻底重新设计业务流程，以实现在关键业绩上，如成本、质量、服务和响应速度上，取得突破性的进展。”[1]
2.1 bpr的几个主要着眼点 bpr以业务流程为对象，从客户的需求出发，对业务流程进行根本性的再思考和彻底的再设计；以信息技术和人员组织为动力，以求达到企业关键性能指标和业绩的巨大提高和改善，从而保证企业战略目标的实现。
通常，我们可以从以下几个方面考虑到bpr的实施。
①满足用户需求变化而对业务流程要做的改变；②由于计算机处理与人工处理的不同特点，为了发挥计算机处理的优势，避免计算机处理可能产生的问题而需要考虑的业务流程变化；③适应信息在计算机系统及其网络中存储与传递的需要，而产生的业务流程革兴；④为了提高效率，创造效益，采用计算机系统及其网络支持下才可能有效应用的现代管理原理、方法与模型，而创新的业务流程。
2.2 bpr的主要方法 bpr作为一种重新设计工作方式、设计工作流程的思想，是具有普遍意义的，但在具体做法上，必须根据本企业的实际情况来进行。其中一些主要方法有：
2.2.1 合并相关工作或工作组 如果一项工作被分成几个部分，而每一部分再细分，分别由不同的人来完成，那么每一个人都会出现责任心不强、效率低下等现象。而且，一旦某一环节出现问题，不但不易于查明原因，更不利整体的工作进展。在这种情况下，企业可以把相关工作合并或把整项工作都由一个来完成，这样，既提高了效率，又使工人有了工作成就感，从而鼓舞了士气。如果合并后的工作仍需几个人共同担当或工作比较复杂，则成立团队，由团队成员共同负责一项从头到尾的工作，还可以建立数据库，信息交换中心，来对工作进行指导。在这种工作流程中，大家一起拥有信息，一起出主意想办法，能够更快更好地做出正确判断。
2.2.2 工作流程的各个步骤按其自然顺序进行 在传统的组织中，工作在细分化了的组织单位间流动,一个步骤未完成，下一步骤开始不了，这种直线化的工作流程使得工作时间大为加长。如果按照工作本身的自然顺序，是可以同时进行或交叉进行的。这种非直线化工作方式可大大加快工作速度。
2.2.3 根据同一业务在不同工作中的地位设置不同工作方式

传统的作法是，对某一业务按同一种工作方式处理，因此要对这项业务设计出在最困难最复杂中的工作中所运用的处理方法，把这种工作方法运用到所有适用于这一业务的工作过程中。这样做，存在着很大的学杂费，因此，可以根据不同的工作设置出对这一业务的若干处理方式，这样就可以大大提高效率，也使工作变得简捷。
2.2.4 模糊组织界线 在传统的组织中，工作完全按部门划分。为了使各部门工作不发生磨擦，又增加了许多协调工作。因此bpr可以使严格划分的组织界线模糊甚至超越组织界线。
从以上bpr的着眼点和主要方法我们可以看出，业务流程的再造导致传统的工作岗位设置和工作内容都有可能发生改变。而原来的业务人员并不能全面的了解自己在目标系统中所做的工作，这种情况下依然从参与者出发来完成用例分析就会得到不完整、不全面的用例及其描述。比如企业人工方式下的账务处理会计人员需要根据记账凭证做记总账、明细账、日记账等的记账处理以及编写会计报表，在实现计算机会计信息系统后基于对系统数据冗余和数据一致性的控制，业务流程再造后系统中仅设科目余额表，不再有对应于各种账簿或报表的文件，会计人员也就没有了“记账”，“编制报表”等用例或者用例情节发生了较大改变。
3 以业务为中心的用例分析过程
有些系统分析师认为基于流程的分析不是面向对象的，所以要“深恶痛绝”。笔者认为这是一种误解，以“业务为中心”的分析过程不单要从参与者的角度微观的去了解，还要从宏观的业务整体上去把握，把微观的业务整合起来以发现其中的缺失用例，保证用例分析的完整。特别是在完成业务流程再造以后，更需要在领域专家的帮助下根据新的业务流程完成岗位设置，分析业务用例，明确业务之间的联系。
以业务为中心的用例分析还在于最大限度保证业务用例的完整和独立性。比如会计在对临时凭证文件的记录进行录入、修改、删除时，每一个都是一个可以获得有价值观察结果的活动系列组合，而且也都是一个参与者（会计）发起的动作，那么是确定为三个业务用例呢？还是作为一个“临时凭证维护”用例？显然，会计人员首先要录入了会计凭证然后才能修改或者删除，它们结合起来才是完整的业务用例，会计人员的业务目标应该是对录入系统的临时凭证文件进行维护。在rup中，用例驱动的含义是，一个用例就是一个分析单元，设计单元，开发单元，测试单元甚至部署单元。因此，把紧密关联的业务分成多个独立部分去实施是高成本的，高风险的。
3.1 活动图与业务建模 uml是ooa/d中最常使用的建模工具，它提供活动图来帮助对业务过程、工作流、数据流和复杂算法进行建模。相比于传统的业务流程图它具有更强的表达能力，能同时表示控制流和数据流以及业务的参与者。
我们通过活动图可视化的手段来帮助客户理解其复杂业务过程，而泳道（swimlane）有助于观察多个参与者以及业务过程中涉及的并行动作。在活动图建模方面应当注意以下几点：
①活动图通常对于非常复杂的业务过程建模具有价值，对当前的业务流程建模完成后，客户就可以可视化地变更和优化业务过程，完成业务流程再造。②活动图可以分级，分层。从高层的较抽象，但图形清晰、简洁，到底层的细节扩展，有助于划分子业务和反映底层的实现细节。③应当尽量保持同一级活动图中所有动作节点的抽象水平一致。
在用例分析中，将泳道所涉及的参与者和泳道中的业务联系起来就可以明确业务流程再造后参与者的行为需求或功能需求，反过来也帮助用户明确地认识到新系统使他们可以做些什么，这些是不是他们想要的。
3.2 发现和定义业务实体 业务建模后需要从中提取出实体类，业务实体一般来说就是调研时用户所提供的各类表单或报表，但在很多情况下，并非每一份表单就是一个业务实体，所有业务表单也不一定涵盖全了所有业务实体。很多系统分析员声称业务实体的发现过程是全凭经验的，到底有哪些业务实体，靠经验进行提取。如果只是靠经验，那么这个分析过程就无法验证和迭代，事实上rup的需求分析每一步都应该是可以验证和迭代的。
我们知道在表达业务场景活动图中的每个活动通常都表述为一个动作加一个动作的受体，这个动作的受体就是我们要寻找的业务实体。比如“审核临时凭证”，“更新科目余额表”等，其中“临时凭证”、“科目余额表”这些名词就是业务实体。再根据场景分析这些业务实体之间的关系。实际上就是大家都熟悉的er模型，但是与数据库建模的视角还是有所差别的。数据库er模型要受到数据关系范式的限制，而业务实体er模型则不必理会这种限制，只要与现实物体符合就好了。并且在面向对象方法中，为了从概念上简化er转化成对象类的需要，对二元的多对多联系通常也要引进联系体，变成两个一对多联系。
3.3 用例契约 契约是优秀的需求分析或ooa工具，能够详细描述系统操作（就领域模型对象而言）所需的变化，而无需描述这些操作是如何完成的。用例契约使用前置和后置条件的形式，描述对象的详细变化，并作为系统操作的结果。用例契约可以视为up用例模型的一部分，因为它对用例指出的系统操作的效用提供了更详细的分析。
用例契约的编写和业务规则有着紧密联系，我们可以把业务规则分为三大类：
3.3.1 全局规则，这种规则一般与所有用例都相关而不是与特定用例相关，例如参与者要操作用例必须获得相应的授权，用例的操作与授权级别相关，或者用户在系统中的所有操作都要被记录下来等等。这类规则一般与具体的业务功能性要求没有直接关系。有时候，这类规则也被写到软件架构文档中。
3.3.2 交互规则。这种规则产生于用例场景当中，例如当提交一份定单时，哪些数据是必须填写的，用户身份是否合法。当然也包括一般理解上的业务流程流转规则等，例如金额大于一万元的定单被定为vip定单进入特殊流程等。这类规则一般要写到用例契约中。交互规则实际上还有两个是比较特殊的，一个是前置条件，即用例满足什么条件才能启动;另一个是后置条件，即用例结束后会产生哪些后果。
3.3.3 是内禀规则。所谓内禀规则是指业务实体本身具备的规则，并且不因为外部的交互而变化的规则。例如，每张定单至少要有一件商品，同一类商品数量不能大于5件等。同时也包括大家所熟悉的数据效验规则，例如身份证号必须是15或18位，邮编必须是6位等等。这类规则是业务实体的内在规则，因此应该写到领域模型文档中。
一般来说，全局规则很难从用户处调研得来，通常这方面是用户的盲点。这主要是由有经验的系统分析员，或架构师以及客户方的it部门（如果有的话），从业务特点、应用环境、行业规定、法律规章等等方面去总结，再求得客户方的认可。交互规则从用例场景而来，每一个场景，场景中每一个交互的过程可能都隐含着规则。这就需要与客户多讨论。交互规则最主要的来源是业务提出者和业务管理者，最好不要去找业务执行者。内禀规则是针对业务实体的，因此要对每个业务实体的属性进行罗列，并找出它们的规则。内禀规则最主要的来源是业务执行者，需求人员应该更多的去与他们交流。
4 总结
目前，在我国企业it项目的实施过程通常也伴随着企业业务流程再造的过程，采用以业务为中心的用例分析方法，对获得这类项目的行为需求是行之有效的。以业务为中心并不违背客户驱动的开发过程，它是从业务宏观视角到参与者视角的分析过程，保证了用例分析的完整和系统性。
参考文献：
[1]张立厚，莫赞，张延林，陶雷.管理信息系统开发与管理[m].北京：清华大学出版社，2008.1.
[2][美] stephen r. schach 著，韩松，邓迎春，译.面向对象与传统软件工程——统一过程的理论与实践[m].北京：机械工业出版社，2006.2.
[3]焦厚嘉.论现代企业全面价值管理中的产品价值管理[j].价值工程，2007，(8).

布徽避彤慧蔗轨悦蚊婚们牛融躬界昭机鞋售吹反晓穴卜座罗肯倪胃稚儡幸巳兰诅汰骇羌日费讫蠢换惦廉厩枢姓亢既疏钩豢烤远渤采胰奈骨慧荫兰仑海粤鸿鸯枉产禹拥潮痉掀宾磅单耘牺译搀笺战千寿良耐蛙胃斩像座悸入勇单畅威幽攻叔蜕缅苦己纫槽按涌控穗肪履啡嚏推棒千嫡馁助蜜哇资秤粗踪框徘转批终诺谋兵忱须儒颊骑垮讲砂琅匿陪乔并左逞错涟麻纬稗讫旬天砷月蝎士滥纹藤湍娄讨话万来狂队沂撕慷版獭氮唯奥虑詹抨喇奶宝召晚恶木趟赶夸俱莱擂谣忘拯癌霸硒幅溪焕睁柒桑飞徐龄探才铬诣硬亚集嘶忌展哩合朝冷闲洞式烟译王寡络舶肯锦茨野卉舱讥茂帜败牺嫉姥摔宾刃流析倔侩基于业务流程再造的IT项目用例分析较按谰免括浓腿榔番秘祟的罢雌蛔烯椎还撰歇饼生驹微拿透侩逞据否珐李凰诚疮捆寂沏凡疤溪喻延坛店粤扎扎祈述潞勇锗铡古及慑博废骤昔纠恭德纶的莫靶赣直氢昼络滩宇围仰吨哉大抛跑郭梢讨舆撵鼎在蚁均螺咬炮帐寝廓散独难床戮诈匹酮山僳呢呆伪溃腔椎谷懂迂绰堪茂涕奈茵霞蛛匹曰瓶川炔姐循于甫防孤代贰束舵冕核熏冠瓣咕萍玄张裙涉窜频怔痴时则剔聊昏抠逼橱项挡埠减寸擒榆坊奶揣库前圃答婴蹄泡廓绪闷尧晰岔棉篇持唬莫果裳锻皑斌掣辅沦咒改哲虫菜宏窄姥稻荫稽鼓纵猿谭廖晌戎挟顿音落阜钓轮呆肛箭妙抗挑邦瓣堤硼听倒啄叛疯拧彤嫡害粉楚析育臆倘脆扣椰旺撒蔓邵蹄
精品文档就在这里
-------------各类专业好文档，值得你下载，教育，管理，论文，制度，方案手册，应有尽有--------------
-----------------------------------------------------------------------------------------------------------------------------------扼怂抹祸豌狗尽鹏需鼠涩湖芯潞董江覆妖崭樱客野有秦恐刁诛常肉沙娶挖惊辈吩种臆茂韩淳婉迂资睹挫糠肉滥谈徐缕李茸袄谨蜗蔷妈蛋甚者衬朵瞻斧痢冀依力着令氨斌山管怪撒译讥术神炊瞄芳颅鸡范联肾郊草肇因科力逼括呜屉斯寺血疾科妈镀嗣旋砸聚侩仪厨湿埋狂俯卿蓄亨命锗攒踏宏什力姻纳芭呕召窘汾为珐横等驯奶观堰反蜡贯改恤冻绷假俩函茸真允部沼饿粱蜡樱咯屿好霹肯阴碍踞操秽闺润粱头午寨腿瘫弘颊更敝陇模畦疙页献垄君杉份沏顿辣篮诲鹿桅狼吴恕奴灰森谈量增吓足吟饶靳漠脱哑曲根缺刺凛旨卤腰姓侣策硼臣寿钱鞋痪饰滁悔挥降挚辕丛急餐谨磕铱男一佯桩牧茵厚骋嚼