4.3 URCP 在项目中的应用
本节将结合第三章中介绍的项目案例，具体展示 URCP 流程的使用过程。
4.3.1 项目案例现状
4.3.1.1 系统整体需求分析
根据前面章节的介绍，该系统包括在线购物网站（B2C），呼叫中心系统（Call Center）和客户关系管理系统（CRM）这三大系统。在启动阶段，通过各方一致同意，获得的需求如下：
系统使用统一的中心数据库。
在线网站作为门户和购物平台与顾客交互。
呼叫中心系统负责接待顾客来电，功能包括下定单，售后服务等。
CRM 系统进行客户资料、订单的管理、数据分析和挖掘等。
综上设计出系统用例图，见图 4-2 所示：
基于上述需求，可以看出，数据中心是一个关键的中心枢纽部分，整个系统都围绕该数据来进行运转。
由于项目周期短，涉及的功能繁多，在初期和客户进行充分沟通的基础上，提出以下解决方案：
· 该项目基于三个已经成功运行的系统进行开发· 需要整合数据库，逻辑上应该只有一个中心库· 顾客在在线网站进行购物和知识学习。
· 顾客拨打呼叫中心，工作人员可以看到顾客历史数据，并根据需要分别在 CRM或者购物网站中进行相关管理操作，例如修改资料，订单管理等。
· 工作人员可以在 CRM 中进行顾客资料管理，并可以打开购物网站中的相关功能，进行管理。
4.3.1.2 需求变更的产生
第三章中介绍的项目案例存在的很多问题，在项目的实际执行中，遇到的最大的问题就是需求变更非常频繁，变更管理很不规范，导致项目的进度受到了严重挑战。
另一方面，客户缺乏相关的业务经验与项目经验，由此对开发人员做出的需求变动分析并不能准确理解，对变动的代价也没有直观和清晰的结论，导致双方的沟通效果较差，甚至产生了一定的互相埋怨和指责情绪。
在项目的初期，开发的主要精力放在了中心数据统一管理这个核心模块上，因为这是整个项目的基石。由于各方面的高度重视，该功能模块从分析、方案设计、实施都在计划内完成，获得了用户较高的赞赏。
随着中心数据功能的完成，各个子系统也相继开始进行连接和初步调试。这样用户也逐渐的开始使用各个子系统，对其中的功能细节逐步了解和熟悉。在经过初步的使用后，用户对整个项目的运行流程也开始进行总结和反思，提出了很多的修改意见：
§ B2C 网站的使用体验不符合他们的预期，需要进行修改
§ B2C 网站需要支持一定的结算机构
§ 购物网站与物流，仓库管理提供商之间的配合
§ Call Center 具体的业务逻辑需要细化、调整
§ CRM 系统中顾客资料的显示、管理方式等
这其中很多的需求是在项目初期没有细化考虑，甚至没有考虑过的。随着这些需求的提出，开发人员也是花费了大量的时间进行沟通、分析、开发，导致项目进度拖延。
同时更为不利的是，与用户产生了不少的误解。
这其中用户埋怨最多的问题是，系统是由三个相对独立的子系统集成而来，根据目前的设计方案，用户需要在各个系统之间进行频繁的切换。例如，当有顾客接入呼叫中心之后，呼叫中心软件只是简单的弹出该顾客的基本信息，如果工作人员需要修改客户的相关资料就需要通过链接进入 CRM 系统，如果要管理用户的订单信息，就要登录购物网站。用户在初次了解了系统功能后进行试用，基本可以接受这种使用模式。但是随着对系统的逐渐熟悉，还有对整个业务逻辑的总结，用户已经明确提出必须进行改变，他们需要一个统一的、流畅的操作过程。
由此，用户对系统的功能有了新的要求：需要一个统一的电话业务流程。功能包括，顾客电话接通呼叫中心后，系统能自动显示顾客所有的资料，包括基本信息、呼叫记录、订单记录等。这些都必须在统一的系统中处理，不能在几个系统中来回频繁转换。
这个需求变更使得开发人员和项目经理压力非常大，一方面，用户的要求也是有一定的合理性，另一方面，这次改动涉及面非常广，所有的系统都需要涉及，工作量的级别已经可以显着的影响项目进度。
作者正是在这个阶段开始考虑引入本文提出的 URCP 流程。
4.3.2 URCP 流程的部署
4.3.2.1 对客户和开发人员的相关培训
在作者负责项目之后，通过认真调查和分析，了解了项目中存在的问题，准备将论文的成果进行应用。
首要任务是对项目参与人员提供相应的知识培训。包括项目管理的基本知识、UML的基本知识、功能点估算等。经过简单的培训，在客户和开发人员直接建立了一种沟通语言，特别是 UML,使得客户能直观的感受并理解开发人员的设计成果，同时也能在一定程度上展示出自己真实的需求。这些对后续项目工作的展开奠定了关键的基础。
4.3.2.2 FPT 的建立
另外一个重要的工作就是成立功能点工作小组，这也是本文的主要研究成果之一，这个是后面工作的基础和参考。
首先需要得到项目经理的认可，可以从公司内部抽取优化的人员来组建团队。同时对团队的相关专业知识培训也是非常关键，这直接决定后面估算工作的质量和能力。当然，项目经理本身也是 FPT 的成员 之一。
其次需要得到客户的认可，在客户公司内部抽取相应的资源加入到 FPT 中来。这里最重要的是要让客户认识到，FPT 对于项目的重要意义，有利于需求变更的管理，保证项目质量和进度。
4.3.2.3 URCP 的建立
通过前期的充分准备，包括客户、开发人员、项目经理等相关人员的培训，基本上达成了一致共识，并在此基础上成立了功能点工作组。由此本论文提出的使用于中小软件项目的需求变更管理流程客观上已经有了启动的基础。
新的流程建立后，当一个新的需求变更产生时，客户会首先按照需求变更申请表的要求，认真总结自己的功能要求。在此基础上提出申请并提交至 CCB.
CCB 首先进行初步的审核。那些不完善或者明显有误的申请将会被退回，同时会与客户做详细的说明，争取获得用户的理解和支持。
通过初审的申请，将由 CCB 转移到功能点工作小组 FPT.FPT 首先根据需求描述，设计出 UML 图。然后将设计图同客户展开详细深入的讨论和分析，最后通过双方的确认和肯定。
之后 FPT 应用本文提出的估算模型，对需求变更造成的代价进行估算，同时可以反馈结果给客户。客户在看到具体的变更影响代价后，有可能会根据项目的实际情况对已有的需求改动进行修改。
接下来 FPT 会产生最终的估算报告，提交给 CCB 以作综合的变更评审。CCB 如果最后批准该变动，则将进入实施阶段，最后进行相应的检验和总结，如图 4-3 所示：
4.3.3 需求变更申请
通过部署 URCP,使得项目管理有了比较规范的程序。首先用户通过 CCB 正式提出功能变更的请求。
需求收集的程序，同样是用户对系统进行总结的程序。具体的需求变更控制表格可以根据实际情况设计，但是核心思想是，除了记录功能外，还要引导用户进行思考，为什么要提出这个改动要求，以及最终的要求是什么，最后还要让用户自己粗略的进行风险和成本估算。
4.3.4 FPT 需求变更评估
变更申请递交至 CCB 后，CCB 将会展开初步的评估。基于系统的现状，包括项目经理和开发人员都认为需求变动有一定合理性，但是需要认真仔细的进行评估，才能正式接受。
项目经理会对某些不太明确的要求与用户再进行沟通，对于太过于模糊的内容，要求进行补充，对于不太合理的要求，通过沟通后，进行了删减。
最终，用户需要变动的内容如下：
§ 提供集中的 Call Center 操作界面§ 可进行顾客基本资料维护，包括新建、查询、修改等§ 可进行历史呼叫记录查看§ 可进行订单维护，包括查询、修改、创建等CCB 初审通过后，该申请就提供给 FPT 进行详细的分析。
在计算出初步的估算结果后，需要将该结果及时反馈给用户和 CCB,并进行详细的分析说明。在这个过程中，项目各方面的干系人都应该充分理解估算内容，并在此基础上进行深入讨论。通过反复的沟通和确认，有一部需求功能会更觉详细，有一部分将需要进行修改，另外还有可能引入新的需求，当然，也有一部分需求会被移除。
经过各方面的反复论证后，FPT 将根据最终的估算数据，完成一份正式的估算报告，提交到 CCB.
4.3.5 CCB 需求变更评审
在得到 UFPT 的报告后，CCB 会把结果通知用户。由于用户已经具有了一定的 UML相关知识，就能容易的和开发人员进行沟通。用户直观的看到了自己的需求将如何被实现，以及比较客观的工作量分析，所以更能容易和开发人员达成一致。
另外，基于 UFPT 的报告，有些工作量大，但是又不是很必须或者紧迫的功能，在充分取得用户理解的基础上，也进行了删除或者简化。
CCB 会在此报告的基础上，综合公司的历史数据和该项目的实际情况，来确定本次需求改动的工作量。比如，公司的劳动生产率是 80 元/小时，一个功能点需要用时 2.5小时，根据前面章节计算出的电话订单系统的功能点总数为 77,所以总的成本估算为：
80 元/小时 X 77 功能点 X 2.5 小时/功能点 = 15400 元77 功能点 X 2.5 小时/功能点 = 192.5 小时 = 24.1 天在项目最后验收的阶段，该估算数据与实际数据相差 7 天，达到了比较好的效果，证明该方法还是有一定意义的。
4.4 URCP 应用成果
项目在前期的开发中的突出问题，就是客户不断的提出需求变更要求，项目的周期计划一度拖延。在经过一系列的准备工作之后，作者将本论文的成果应用到了项目中去，经过一段时间的磨合和调整，产生了比较好的效果，主要包括：
4.4.1 更加准确的描述需求
通过 UML 与客户建立了通用的沟通语言，与客户的沟通更加深入，客户能从开发人员的角度考虑问题，并且能较为容易的看懂开发人员的设计思路和方案。同时，客户利用 UML 可以将自己的想法比较准确的展示出来，开发人员也能更容易的明白客户的思路和想法，能更加准确的设计出客户需要的东西。
在本文的项目案例中，以往客户和开发人员各自描述各自的需求和理解，有时候其实互相并没有完全理解。使用 URCP 后，由于有了共同的语言，双方明显感觉交流更顺畅，更容易理解和沟通，有利于将需求变更较为准确的描述出来。
4.4.2 提高了风险评估能力
功能点工作小组的加入，使得项目对于变更可能造成的影响和代价有了相对准确的评估，便于直观的展示给客户，让客户体会到变更带来的影响，同时也能更好的理解开发人员的想法和立场，从而进行更有意义的变更。
在本文的项目案例中，以往开发人员对需求变更需要的工作量，很多时候是基于模糊的经验、案例等因素进行估算，往往比较笼统、与实际工作量相差可能会比较大。使用 URCP 后，在较为准确的需求描述之上，得到的估算结果也比较接近真实工作量。同时在 URCP 还可以有效的应对频繁发生的变更，将工作量进行相应的估算，从而提高了项目风险评估能力。
4.4.3 提高了项目开发能力
基于 UML 的功能点估算的前提是要设计好 UML 相关图例。而 UML 本身就是优秀的建模工具，可以直接用来进行系统设计。
另外一方面，功能点工作小组的最终输出，一旦需求变更获得项目变更管理委员会的批准，实际上就可以作为后续开发的设计方案，直接使用，从而节约了项目开发时间。
4.4.4 提高了项目管理水平
本文提出的流程既便于应用，又有一定的灵活性，同时无论是客户、开发人员还是项目经理或者项目相关人员，通过一系列的学习，培训，再经过互相之间沟通的不断深入，各个人员都感受到了一种积极的动力，各自的项目管理水平也相应的得到了提升，在项目的开发过程中，双方也更能进行有效的沟通和合作。
4.4.5 资源合理分配，提高了项目效率
通过新需求变更流程的使用，使得需求变更更加正规和有效，一些对项目影响太大，但是相对价值不高的需求变动将被暂缓甚至退回，从而可以集中优势资源，使得项目顺利开展。
在本文的项目案例中，对于前文提到的实际的需求变更情况，起初，根据开发小组的经验估算，需要至少 60 天左右的开发工作量。在使用本文提出的估算模型后，由前面的计算可知，需要 38.5 天。在项目最后验收的阶段，该估算数据与实际数据相差 7天，达到了比较好的效果，缩短了项目周期。
4.5 本章小结
本章首先介绍了一般的需求变更管理过程以及变更管理委员会的基本职责和工作内容。
接下来结合前面章节提出的需求变更评估模型，本文提出了一种适合中小软件项目的需求变更管理流程 URCP,并对其内容和步骤进行了详细论述。
之后将流程进行结合前面介绍的真实的软件开发项目。介绍了项目的现状，需求变更的产生原因等。
最后总结了 URCP 在实际项目案例中的应用成果。通过 UML 与客户建立了通用的沟通语言，功能点工作小组提高了风险评估能力，提高了项目开发能力，新的需求变更管理流程提高了项目管理水平，项目的资源得到了合理的调度，缩短了项目周期。
