第二章 变更管理基本理论
2.1 需求变更管理概述
在软件开发中，对于如何进行需求开发，准确捕捉需求有较多的研究，而对于需求变更的管理，一直没有得到相应的重视。很多调查数据表明，需求变化的管理不当往往会导致项目失败。
需求从最开始就是项目最重要的内容，是整个系统的蓝图，同时也是检验标准。在实际的软件项目开发过程中，需求是不断发生变化的，这样对于需求管理而言更加具有难度，对于需求变更的成功管理往往会决定项目成败的关键。
2.2 需求变更影响分析
需求确定之后，或者是用户基于项目进展，了解到了更多的细节，所以对已经计划的项目功能有了新的看法，或者是开发人员基于项目开发的实际情况，对项目中一些与项目的计划、资源产生冲突的功能进行调整，要么简化要么取消，当然在双方沟通基础之上。由此就产生了需求变更。
需求变更会造成多方面的影响：
· 影响项目周期及预算。需求变更往往会带来额外的工作量，需要投入更多的资源和时间，有可能导致项目延期，开发费用上升。
· 影响软件项目最终的质量。需求变更往往是在比较紧急的状况下提出的，为了保证项目既定周期和费用，开发人员不得不赶工，由此留下了隐患。可能产生新的漏洞，或者降低了最终交付的软件产品的质量。
· 影响项目最终的部署。主要包括最终的测试和验收。需求变动将带来新的内容，增加了部署的工作量和难度。
2.3 常见变更管理过程
2.3.1 敏捷类
在 XP 方法中，开发人员往往采取集中开发的方式，便于信息交流[28].当需求变化发生时，用户和开发人员一起分析新的需求，并确定优先级，一起决定下一次迭代过程需要完成的需求。
在 Scrum 方法中，有很多个周期，每个过程中，将不处理需求变更。本阶段中产生的变更都作为下一周期的输入。每个周期结束时，用户和开发人员要进行总结，并做好下一个周期的准备。
2.3.2 过程控制类
在 CMM 和 CMMI 方法中，需求变更管理会产生很多影响。在 ISO9000 中就要求对变更进行快速响应，并且要有风险评估，需要评估所有的请求，通过之后就可以开始实施，并且进行相应的记录。不同的方法会对包括配置管理、风险管理、项目计划等产生影响。
RUP 是一个迭代的开发流程，项目开发包括起始、细化、构建和产品化四个阶段[27].RUP 认为需求的变化是一定会出现的，因此要求采取一定的管理过程，并集成到系统中去。
在 ICM 方法中，有多个迭代步骤，各个步骤与下个步骤的需求分析工作同时进行，同时也有一定的评估机制。
2.4 常见需求变更管理工具
2.4.1 Telelogic 的 DOORS
DOORS 是目前比较流行的需求工具。它是专门为企业级别用户设计的，并有一定的可扩展性。它可以分析，管理，追踪需求信息，提供了直观的沟通方式，完整的变更建议流程和审核系统以及高级别的验证功能。这些都便于确保项目的实际与需求计划相一致2.4.2 IBM Rational 的 ClearQuest
ClearQuest 是一个能自动跟踪缺陷及变更的系统[26].它能使工作简化，另外它还可以作为管理工具，进行相关业务逻辑管理。
2.5 功能点估算方法
2.5.1 软件成本概念和规模估算
“成本”在经济学上的定义是“生产一定产量所支付的费用”[2].借鉴该定义可以得出，软件成本就是为软件项目最后支付的费用，该费用由规模以及各个要素的单价决定。
由于软件项目与传统的制造业比较，并不是以消耗原材料和能源这种显而易见的方式进行的，而是主要消耗项目参与人员的脑力劳动成果，其估算相对更加复杂一些。
根据前面的论述，软件成本主要的与系统规模大小和各种生产要素的价格相关。一般来说，生产要素包括开发人员的工资支出，开发设备、开发所使用的软件以及相关的培训等，这些因素的价格都取决于市场价格，相对来说比较容易确定。因此系统工作量的估算成为关键点。
需求风险与估算风险被认为是最主要的两个风险[3].如果不能进行较为合理的估算，将会对项目的周期、预算等产生影响。软件规模估算往往是决定一个项目成功与否的关键[4].目前流行的估算方法是代码行估算方法和功能点分析方法[21].
2.5.2 功能点估算介绍
功能点分析方法（FPA）由 Allan Albrecht 提出[5].国际功能点用户协会之后提出了 IFPUG FPA 方法。
功能点估算方法是度量软件规模的一种估算方法[15].主要思想是把软件系统按照组件进行分解。系统工作量的级别最后取决于系统功能点的多少。FPA使得开发人员与用户有可能使用统一的方法定义系统的功能需求。用户不需要理解复杂的开发过程，能够根据功能点对相应的工作量进行估算，掌握项目的整体开发工作量。
该 FPA 在很多参数估算模型中使用[12].2004 年发布了《IFPUG 功能点计数实践手册 4.2 版》[18][19].
2.5.3 功能点估算步
FPA 认为任何软件都是五种【要素组成[20].主要包括数据功能和事务功能两大类型。依照 IFPUG 4.2,需要对以下内容进行估算：
· 数据功能包括：
内部逻辑文件（Internal Logical File,ILF）
外部接口文件（External Interface File,EIF）
· 事务功能包括：
外部输入（External Input,EI）
外部输出（External Output,EO）
外部查询（External Query,EQ）
计算步骤是首先估算出各部分的复杂度，再确定各个部分的权重，最终就能获得对应的功能点数。由于 IFPUG 提供了对应的参考手册，便于实际操作，因此得到了很大的应用和推广。
FPA 的步骤主要包括：
（1） 确定功能点类别和需求范围。
（2） 估算数据功能的 FP.
（3） 估算事务功能的 FP.
（4） 计算未调整 FP（UFP）。
（5） 确定值调整因子（VAF）值。
（6） 计算调整后的 FP（AFP）。
该过程可以用图 2-1 更加详细的说明：
由此看出，FPA 不仅可以在项目需求分析阶段进行估算，也可用于改善软件项目管理全过程[22]. FPA 方法已成为软件度量的基础[23].接下来会对各步骤展开论述。
2.5.4 确定功能点类型和需求范围
功能点类别主要有以下几种：
（1） 开发型项目
计算首次提交的功能点。
（2） 加强型项目
计算对现有功能进行改进涉及到的功能，包括增加、删除、改变等动作。
（3） 应用型项目
计算已经部署的项目的功能点，通常也被作为基线功能点，反映了项目最终为用户提供的功能点。
需求边界是指系统的需求范围，规定了软件提供的功能，系统逻辑和数据的范围。
2.5.5 数据功能点估算
数据功能点是由系统维护并使用的，主要包括 ILF 和 EIF.即内部逻辑文件和外部接口文件。这里“文件”并不适合于现代信息系统[10].它指的是可以一起访问的一组数据或信息，与实际部署的物理实体并没有关系。
2.5.5.1 识别 ILF 和 EIF
ILF 是数据或信息的组合。一般必须满足如下的规则：
（1） 数据满足需求定义。
（2） 数据由系统维护。
EIF 是一组被查询逻辑数据或信息。一般必须满足如下的规则：
（1） 数据满足需求定义。
（2） 数据由系统引用。
（3） 数据不由系统维护。
（4） 数据在其他系统中维护。
由此可以看出数据如果是被应用维护就是 ILF,否则就是 EIF.
2.5.5.2 计算 ILF 和 EIF 复杂度
在识别了 ILF 与 EIF 之后，FPA 通过 DET 及 RET 来估算：
（1） 数据元素类型（DET ,Data Element Types）（2） 记录元素类型（RET,Record Element Types）DET 是可识别的单一字段，一般应该满足：
（1） 满足需求定义，非重复，被系统维护。
（2） 满足需求定义，非重复，被系统引用。
（3） 通过逻辑过程实现维护和引用。
（4） 仅对那些使用的 DET 计数。
RET 可以是 DET 的组合，一般应该满足：
（1） RET 为数据文件中的一个 DET 组。
（2） 两类数据文件都可以作为单独一个 RET 处理。
ILF/EIF 的复杂度计算步骤：
（1） 根据系统边界确定功能点是 ILF 还是 EIF.
（2） 查表 2-1 确定每个 ILF/EIF 的复杂度。
2.5.5.3 计算 ILF 和 EIF 未调整功能点数
接下来估算未调整前的 FP.根据下面的转换表 2-2 和表 2-3,可以得出最终的数据：
2.5.6 事务功能点估算
系统处理信息和数据的过程被称为事务处理功能，其估算主要包括 EI,EO,EQ 的计算。
2.5.6.1 识别处理元
首先要把事务分解为处理元，基本原则：
（1） 有意义的最小活动单元。
（2） 保证系统一致性。
如经过一定的运行，系统的状态不一致了，则该处理过程不是处理元。
2.5.6.2 识别处理逻辑
IFPUG 定义了 13 种处理元包含的处理逻辑。具体见下表 2-4.
- 13 -表中符号说明：
（1） 空白：可以包含。
（2） M:必须包含。
（3） M*:包含至少一种。
（4） N:不得包含。
2.5.6.3 识别 EI、EO 和 EQ
外部输入是系统处理数据或信息的过程。
EI 的识别规则[11]:
（1） 从外部输入了数据、控制信息。
（2） 或者更新了 ILF 或者改变了系统的行为/状态。
EO 是系统向外部输出加工过的数据或者控制信息的逻辑过程。EO 向系统外部提供处理过的信息，至少包含改变数据的过程或者改变系统的行为。
EQ是外部从系统中查询数据、控制信息的逻辑。EQ不加工数据和信息，也不输出新数据。
EO和EQ的作用都是对外部输出数据或控制信息，可以通过以下的几个条件进行区分：
（1） 输出了导出数据。
（2） 包含数学运算。
（3） 包含对内部数据文件的处理逻辑。
（4） 改变了系统的行为或状态。
上述条件中，只要有一条满足，就可以认为是EO.此外，EQ必须获得系统的输出，引用了内部数据文件。
2.5.6.4 计算 EI、EO 和 EQ 复杂度
接下来需要估算这三者的复杂度，主要包括 FTR 和 DET 的计算。
FTR 是在处理过程中引用的逻辑文件。处理功能可能是 EI/EO/EQ,逻辑文件是 ILF/EIF.
FTR 的估算规则如下：
（1） 被维护的逻辑文件可以计算为一个 FTR.
（2） 输入的逻辑文件可以计算为一个 FTR.
（3） 输入同时也被维护的逻辑文件，只计算为一个 FTR.
对数据文件进行的新建、编辑以及删除都是维护逻辑。EQ 一定没有 FTR.
EI/EO/EQ 中的 DET 估算规则如下：
（1） 下列字段算一个 DET
· 用户可识别的。
· 不重复的。
· 为实现逻辑处理而输入/输出系统。
（2） 内部数据往往不能作为 DET,例如：
· 由系统从 ILF 中获取的字段。
· 保存在 ILF 中的字段。
· 硬编码的文本，如标题。
· 系统生成的时间戳。
· 系统生成的变量。
（3） 向系统外发输出信息的逻辑可作为 DET,包括：
· 指示处理异常。
· 指示处理已完成。
· 确认处理是否继续。
（4） 输入操作计为一个 DET.
接下来需要计算事务功能点的复杂度。根据 IFPUG 给定的复杂性矩阵[9]
进行确定。见下表 2-5 和 2-62.5.6.5 计算 ILF 和 EIF 未调整功能点数
由此估算出未转换功能点数[9]
（UFP）。见下表 2-7 和 2-8.
2.5.7 确定值调整因子
除了数据功能和事务功能，应用系统还包括许多无法被这两种类型描述的因素。可以用VAF来进行调整，通过这些系统特征来评价计算出的功能点的级别[16]
这里仅仅进行简单的列出，仅供参考。
· 数据通信
· 分布式数据处理
· 性能
· 重度配置
· 处理速率
· 在线数据输入
· 最终用户使用效率
· 在线升级
· 复杂处理
· 可重用性
· 易安装性
· 易操作性
· 多场所
· 支持变更
对各项进行评估并为每个VAF赋予其影响程度值DI,取值可以参考以下的列表：
· 0不存在，或者无关
· 1偶尔相关
· 2中等相关
· 3平均相关
· 4较强相关
· 5完全强相关
14项GSC的和用来计算最终的影响程度 （ΣDI） .值调整因子（VAF）的计算方法如下[17]:
VAF = （ΣDI x 0.01） + 0.65
2.5.8 确定调整后的功能点数
根据上面的计算方法可见，UFP的最终结果的修正范围为±35%.调整后的功能点数（AFPC）计算方法如下：
AFPC = UFPC x VAF
2.6 统一建模语言 UML 介绍
2.6.1 概述
UML 是统一建模语言的缩写，吸取了多年软件工程的成果，是面向对象开发的行业标准语言。UML 具有标准化和可视化的特点。利用 UML 建模便于对象和规则的重用，确保了开发过程的一致性，运行独立于实现，软件项目的建模、分析、设计将具体和直观化，也更容易进行项目的分析和控制。
2.6.2 用例图
用例是一个外部可见的系统内聚功能单元[13].用例图（Use Case Diagram）通过简单的图形描述方式，描述了系统的层次结构，提供的服务以及互相之间的交互。用例表示提供给系统的使用者的功能，是对这些功能的逻辑描述。
用例的表述形式通俗易懂，贯穿于系统开发的各个阶段。尤其在分析需求阶段，可以用来从多个视角捕获系统需求。用例图非常便于用户和开发人员理解和实现系统功能[24].
2.6.3 类图
类是一种描述符号[13].类可以使用它来对那些有着相同本质的对象进行一定抽象，可以描述其相同的结构，或者相似的行为。
在 UML 中，类图（Class Diagram）显示了系统内部静态数据之间的关系。
类图定义了类的属性和操作以及相应的约束条件[14].类图不仅在设计阶段非常重要，在实现阶段也同样发挥关键作用，占据重要地位。
2.6.4 顺序图
顺序图（Sequence Diagram）显示了系统的动态行为，可以很直观的展示出消息是如何在系统内部传递和处理的。顺序图用于描述对象间动态交互能力[25].
2.7 本章小结
本章首先介绍了需求变更的基本知识以及对项目的影响。
接下来介绍了常见变更过程，主要包括敏捷类的变更管理过程和侧重过程控制的变更管理过程。另外还介绍了目前比较流行的需求变更管理过程和工具，主要包括Telelogic的DOORS和IBM Rational的ClearQuest.
之后介绍了功能点估算方法的基本内容。首先介绍了FPA的基本概念和经典步骤。接下来就重点介绍了几个关键内容，包括确定功能点类型和需求边界、各种类型功能点的估算、调整因子以及调整后的FP.
最后介绍了UML的基本知识，包括UML的基本概念以及几个常用的UML图标，包括用例图，类图和顺序图，包括它们各自的特点和用途，为后续章节做好了准备工作。
