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

基于业务流程再造的IT项目用例分析摘要：在it项目中，业务流程再造从根本上重新思考并彻底重新设计业务流程，系统的用例分析应当以业务为中心，结合参与者视角，才能较完整和系统地发现、描述用例，表达客户的行为需求或功能需求。abstract: in it projects, business process reengineering fundamentally rethinks and radically redesigns business processes. the systems 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-020 引言息系统项目开发中需求分析的重要地位不言而喻，在需求阶段出现的错误会一直延续到系统的设计阶段和实施阶段，其结果往往是为纠正错误付出昂贵的代价甚至导致项目失败。然而如何才能确定客户的需求却是困扰系统分析师的首要难题，我们往往很难通过简单的询问客户来真正了解到客户所需要的内容。因为很多时候客户一开始也只有一些初步的功能要求，给不出明确的想法，一个流传盛广的冷笑话是：“我知道这就是我所要求的信息系统，但是它不是我想要的。”1 用例与需求分析在rup中用例被定义为“由一组用例实例构成，每个实例是系统所执行的一系列活动，以此产生对特定参与者具有价值的可观察结果。”它被用于说明系统的参与者使用系统以实现某些目标，广泛应用于需求的发现和记录。一般认为用例主要是说明系统如何工作的功能性需求或行为需求，它是以参与者为中心，从参与者的角度来描述它要做的工作，并分析这些工作之间是如何交互的，既所谓用例驱动的过程方法。用例强调了需求分析的两个态度：一是关注系统的用户或参与者来编写需求，询问其目标和典型情况；另一个是关注理解参与者所考虑的有价值结果。有价值的可观察结果对用户来说正是系统的实现目标，通常和业务用例直接对应。同时，我们还应该注意到用例是由参与者发起的，不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例。在信息系统开发中需求分析过程大致可以分为三个阶段：理解应用域（业务建模），建立概念模型阶段和系统建模。其中业务建模的目标是通过用例模型的建立来描述用户需求，需求规格说明书通常在这个阶段产生；而概念模型阶段是系统分析员采用面向对象的方法来分析业务用例的过程，业务架构通常在这个阶段产生；最后，系统建模是将用户的业务需求转化为计算机实现的过程，系统架构通常在这个阶段形成雏形（在系统分析阶段确定）。从这三个阶段我们可以看出，用例分析是需求分析阶段的核心，我们需要在用例中包含满足所有涉众关注点的事物。那么，信息系统开发中该如何来确定用例的参与者，发现用例，完成用例的场景描述呢？通常的做法，系统分析师首先会定义“涉众”，可能包括投资人、项目发起人、项目管理者、项目执行者、第三方、相关法律法规和客户等。再在此基础上确定系统的用户，即用例的参与者，问他们类似的问题：你工作主要做什么？这件事是谁交待办的？做完了你需要通知或传送给谁吗？做这件事情你都需要填写些什么表格吗？把这些问题的答案汇集起来就是业务用例。这是目前广泛采用的一种获取用例的有效方式，系统分析师再配合参与者的业务代表进一步就可以完成业务用例文本情节的描述，这种描述方式是完全站在参与者的角度，强调了用户的目标和观点。然而，如果新系统相对于旧系统的业务发生了调整，作为参与者业务代表并不总是清楚自己在新系统中将完成哪些工作，难免有“不识庐山真面目，只缘身在此山中”的困惑，这时按前面的方法获取用例和用例的场景还有效吗？2 it项目的业务流程再造业务流程再造（bpr）是随着信息时代的到来而产生的一场技术管理革命。在20世纪90年代，作为最早倡导bpr理论的学者之一，美国麻省理工学院教授迈克尔哈默（michael hammer）教授，在企业再造（reengineering the corporation）一书中对“业务流程再造”是这样定义的:“从根本上重新思考并彻底重新设计业务流程，以实现在关键业绩上，如成本、质量、服务和响应速度上，取得突破性的进展。”12.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或