第四章 一种适用于中小软件项目的需求变更流程
4.1 需求变更管理流程（URCP）的内容
软件项目在开发过程中不可避免会出现需求的变化。对于中小软件项目来说，抗风险能力相对较弱，同时项目周期、资源等也是相对紧张，因此需要做出快速、准确的判断并加以实施。
一般来说流程包括：
§ 需求变更申请
§ 需求变更审核
§ 需求变更实施
§ 需求变更验收
这要求项目开发团队和客户建立起比较流畅的沟通机制，一般情况下，都会成立变更管理委员会（CCB），专门负责项目相关的变更事务。由双方项目相关人员组成。
CCB 主要工作包括：
1. 评估变更请求并决策。
2. 批准变更请求并负责实施。
3. 拒绝变更请求。
在项目计划阶段就要成立 CCB,当项目需求发生变更时，由 CCB 组织相关人员审核并产生更改记录。之后还要负责批准的变更的实施和验收。
根据前面章节提出的内容，本文结合中小软件项目的特点，设计出一个适用于中小软件项目的基于 UML 的需求变更管理流程（URCP, UML Based Requirement ChangeProcess），图 4-1 介绍了 URCP 的基本流程：
主要包括以下几个步骤：
§ 需求变更申请
§ FPT 需求变更评估
§ CCB 需求变更评审
§ 需求变更实施
§ 需求变更验收总结
下面将对各个环节展开论述。
4.2 URCP 的实施步骤
4.2.1 步骤一：功能点工作小组（FPT）的建立
4.2.1.1 概述
成立专门的功能点工作小组（FPT,Function Point Team）这是本论文根据中小软件项目的特点提出的一个重要的研究成果。
通常客户的需求变更提交到 CCB,由其进行评审并做出最终决定。但是在实际的项目中，CCB 的组成成员一般来自客户和开发双方的代表，各自的专业知识很难达成共识，而且会有经验不足等问题存在。尽管有的 CCB 在评审过程中会广泛听取客户，项目经理，开发人员，甚至专家建议，但是这样的评审机制，往往会使得需求变更的评审流于形式，更注重表面的流程的正规化，而忽视了隐藏在背后的需求变更最关键的问题-变更带来的代价和影响估算。
针对中小项目的特点，作者建议成立功能点估算工作组，由此需求变更的影响评估工作将由 CCB 转交给 FPT,这样做的最大的好处就是，专业的知识交由专业的 FPT 处理，CCB 则根据 FPT 反馈的评审结果综合其他评审结果，进行整体决策过程。与 CCB对需求变更进行评审相比，FPT 更能脱离干系人主观意见的干扰，真实的将需求变动带来的代价展现给项目的所有参与人员。以供后续的评审使用。
4.2.1.2 人员组成
FPT 的人员须由开发方最有开发能力的团队组成，他们是对项目开发细节最了解的人员。能够真实和准确的将工作量，风险等进行评估。而不是粗略的，或者基于其他压力而隐藏了其中的巨大风险。
另外 FPT 的人员也可以包括项目经理和客户的相关人员。项目经理能够从整上进心决策。而客户则能够及时反馈信息，便于进行双向反馈，从而更加准确的描述变更。
4.2.1.3 工作内容
当新的需求变更被提交过来之后，FPT 会根据需求描述将其转化为 UML 图例，包括用例图，类图、和顺序图。在与客户以及项目经理充分沟通的基础上，完成针对项目实际的设计、实施等状况对该变更进行最合理和可靠的技术层面的评审。所以，FPT 的工作内容包括：
§ 充分沟通，获得较为完整的需求变更描述§ 完成 UML 图的分析和设计§ 工作量和风险评估§ 提交评估结果到 CCB4.2.2 步骤二：需求变更申请
变更一般由用户申请，要么新增功能，要么修改现有的功能。提出的申请必须有正式的流程。可以使用变更申请表来记录。可以根据项目的具体情况，既可以使用相关的软件工具，也可以使用纸质的方式。
变更申请表是媒介载体，从变更提出的第一时间就必须创建。在提出的初期阶段，可以包括以下各项：
§ 变更编号§ 变更描述§ 变更原因§ 初步的风险分析需求变更申请表由客户初步完成，然后提交给项目变更委员会 CCB,作为需求变更管理表的一部分内容，后续的变更管理将由 CCB 统一进行管理。
4.2.3 步骤三：FPT 需求变更评估
4.2.3.1 需求变更获取
变更提交后，CCB 将会进行初步评审，从而决定是否需要进行开发方面的评估。这个内容将转移到功能点工作小组 FPT 去完成。
所以，FPT 的需求变更来源于 CCB,得到这个初步的申请表之后，FPT 内部将进行相关的评估工作，如果需要与客户、项目经理等进行进一步的沟通，则需要提交 CCB,由 CCB 来统一组织讨论和沟通等活动。
4.2.3.2 UML 图设计
在得到比较详细的需求变更文档后，FPT 就可以展开具体的分析工作了。根据前文的论述，在中小软件项目中，只需要设计出相关的用例图、类图和顺序图即可。
用例图主要用来描述系统的行为，应当尽可能详细的展示可能的系统逻辑，以免造成后续的功能点遗漏。为了实现这个目标，可能需要与客户反复的讨论。让客户积极的参与进来，让他们能清楚的知道开发人员的思路是否反映了他们的意图。这对于整个的需求管理都很重要。
类图反映了了设计上的复杂性。类图的设计基本上是由开发人员来进行，根据设计经验和项目的具体特点，在充分反映变更要求的基础上完成。
顺序图主要反映了软件框架中各个元素的动态行为。顺序图由开发人员来完成。最终的成果将和其他 UML 图表结合起来决定功能点的估算。
4.2.3.3 UFPA 评估
根据前文提出的一种适用于中小项目的功能点估算方法 UFPA,在完成的变更 UML图的基础上，进行以下各项工作， 这里只是列出了 UFPA 相关的工作内容，具体细节请参见 3.3.4 章节内容。
§ 通过用例图识别系统的边界和范围§ 通过类图识别数据功能点§ 估算数据功能点的复杂度§ 通过顺序图识别事务功能点§ 估算事务功能点的复杂度§ 确定值调整因子§ 计算校正后的功能点4.2.3.4 估算结果反馈与修正
PFT 在此基础上形成初步的变更评估报告。应当将次报告通过 CCB 反馈给客户进行确认。要看到，这个过程和报告都不是一部到位的，需要和客户进行深入的讨论和分析，根据各个干系人的反馈，很可能需要进行修改。在双方达到共识后，才会产生最终的版本和评估结果。
值得注意的一点是，这个过程的每一个环节都需要在变更控制表中进行记录，并获得用户认可，这将是后续所有工作的依据。
4.2.3.5 生成变更估算报告
在 FPT 和客户以及项目经理等相关人员的反复讨论和分析之后，将会产生最终的变更工作量评估报告。FPT 应该正式提交给 CCB,由 CCB 进行后续的综合评审。
4.2.4 步骤四：CCB 需求变更评审
CCB 收到变更请求后，由项目经理先评估变更来源、理由、影响、代价。一些初步的处理包括：
· 内容不清楚的请求，退回要求补充信息· 删除明显错误的变更请求在形成初步的变更申请表后，CCB 将其转移到功能点工作组 FPT,进行工作量的功能点估算，FPT 经过和各方关系人充分分析讨论的基础上，提交详细的，比较客观准确的反映变更代价的评估报告。最后 CCB 将基于所有的数据和项目实际情况进行综合评审。
这里 FPT 的输出结果作为主要参考。因为对于中小项目而言，最紧缺的永远是时间和工作量，CCB 因此就能够做出比较客观的判断，如果变动代价过大，对项目影响严重，就可以具体的展示给客户，寻求客户的理解和支持。
如果变动的代价在项目的风险承受能力范围内，那么需求变更将得到批准，并进入正式实施阶段。
值得注意的是，在这个过程中，所有的相关活动，包括会议、讨论、修正等都要详细记录到需求变更管理表中。
4.2.5 步骤五：需求变更实施
在得到 CCB 的批准后，变更进入实施阶段。根据中小软件项目的特点以及作者的经验，可以将需求变更作为全新的需求进行管理，这样做的好处就是项目所有的需求都在统一的管理方式之前。
值得一提的是，由于 FPT 的存在及其工作，事实上已经完成了一部分的开发任务，即分析和设计任务已经基本完成，因此这也会加速需求变更的实施过程，从而为项目整体进度节省出时间和工作量。
项目经理将制作详细的实施计划，进度检查，保证最终结果和要求一致。在这个过程中，需求变更表主要记录开发的主要活动和节点，便于项目整体控制和监督。
4.2.6 步骤六：需求变更验收与总结
在需求变更完成后，CCB 应该组织相关人员进行验收，而不是等到整个项目结束后才进行验收。主要的参考依据是变更申请表和 FPT 提交的经过批准的设计文档。
在顺利通过验收后，CCB 应当对变更进行总结，以便为后续的变更提供参考。同样的，相关的信息都应该保存到变更管理表中。
