需求变更管理基本理论,项目管理论文.docx

《需求变更管理基本理论,项目管理论文.docx》由会员分享，可在线阅读，更多相关《需求变更管理基本理论,项目管理论文.docx（18页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、需求变更管理基本理论,项目管理论文题目 第一章 第二章 需求变更管理基本理论3.1 3.2 3.3 3.4 3.5 4.1 - 4.2 4.3 - 4.5 总结/以下为参考文献 第二章 变更管理基本理论 2.1 需求变更管理概述 在软件开发中，对于怎样进行需求开发，准确捕捉需求有较多的研究，而对于需求变更的管理，一直没有得到相应的重视。很多调查数据表示清楚，需求变化的管理不当往往会导致项目失败。 需求从最开场就是项目最重要的内容，是整个系统的蓝图，同时也是检验标准。在实际的软件项目开发经过中，需求是不断发生变化的，这样对于需求管理而言愈加具有难度，对于需求变更的成功管理往往会决定项目成败的关键

2、。 2.2 需求变更影响分析 需求确定之后，或者是用户基于项目进展，了解到了更多的细节，所以对已经计划的项目功能有了新的看法，或者是开发人员基于项目开发的实际情况，对项目中一些与项目的计划、资源产生冲突的功能进行调整，要么简化要么取消，当然在双方沟通基础之上。由此就产生了需求变更。 需求变更会造成多方面的影响： 影响项目周期及预算。需求变更往往会带来额外的工作量，需要投入更多的资源和时间，有可能导致项目延期，开发费用上升。 影响软件项目最终的质量。需求变更往往是在比拟紧急的状况下提出的，为了保证项目既定周期和费用，开发人员不得不赶工，由此留下了隐患。可能产生新的漏洞，或者降低了最终交付的软件产

3、品的质量。 影响项目最终的部署。主要包括最终的测试和验收。需求变动将带来新的内容，增加了部署的工作量和难度。 2.3 常见变更管理经过 2.3.1 敏捷类 在 XP 方式方法中，开发人员往往采取集中开发的方式，便于信息沟通28.当需求变化发生时，用户和开发人员一起分析新的需求，并确定优先级，一起决定下一次迭代经过需要完成的需求。 在 Scrum 方式方法中，有很多个周期，每个经过中，将不处理需求变更。本阶段中产生的变更都作为下一周期的输入。每个周期结束时，用户和开发人员要进行总结，并做好下一个周期的准备。 2.3.2 经过控制类 在 CMM 和 CMMI 方式方法中，需求变更管理睬产生很多影响

4、。在 ISO9000 中就要求对变更进行快速响应，并且要有风险评估，需要评估所有的请求，通过之后就能够开场施行，并且进行相应的记录。不同的方式方法会对包括配置管理、风险管理、项目计划等产生影响。 RUP 是一个迭代的开发流程，项目开发包括起始、细化、构建和产品化四个阶段27.RUP 以为需求的变化是一定会出现的，因而要求采取一定的管理经过，并集成到系统中去。 在 ICM 方式方法中，有多个迭代步骤，各个步骤与下个步骤的需求分析工作同时进行，同时也有一定的评估机制。 2.4 常见需求变更管理工具 2.4.1 Telelogic 的 DOORS DOORS 是当前比拟流行的需求工具。它是专门为企业

5、级别用户设计的，并有一定的可扩展性。它能够分析，管理，追踪需求信息，提供了直观的沟通方式，完好的变更建议流程和审核系统以及高级别的验证功能。这些都便于确保项目的实际与需求计划相一致2.4.2 IBM Rational 的 ClearQuest ClearQuest 是一个能自动跟踪缺陷及变更的系统26.它能使工作简化，另外它还能够作为管理工具，进行相关业务逻辑管理。 2.5 功能点估算方式方法 2.5.1 软件成本概念和规模估算 成本 在经济学上的定义是 生产一定产量所支付的费用 2.借鉴该定义能够得出，软件成本就是为软件项目最后支付的费用，该费用由规模以及各个要素的单价决定。 由于软件项目与

6、传统的制造业比拟，并不是以消耗原材料和能源这种显而易见的方式进行的，而是主要消耗项目介入人员的脑力劳动成果，其估算相对愈加复杂一些。 根据前面的阐述，软件成本主要的与系统规模大小和各种生产要素的价格相关。一般来讲，生产要素包括开发人员的工资支出，开发设备、开发所使用的软件以及相关的培训等，这些因素的价格都取决于市场价格，相对来讲比拟容易确定。因而系统工作量的估算成为关键点。 需求风险与估算风险被以为是最主要的两个风险3.假如不能进行较为合理的估算，将会对项目的周期、预算等产生影响。软件规模估算往往是决定一个项目成功与否的关键4.当前流行的估算方式方法是代码行估算方式方法和功能点分析方式方法21

7、. 2.5.2 功能点估算介绍 功能点分析方式方法FPA由 Allan Albrecht 提出5.国际功能点用户协会之后提出了 IFPUG FPA 方式方法。 功能点估算方式方法是度量软件规模的一种估算方式方法15.主要思想是把软件系统根据组件进行分解。系统工作量的级别最后取决于系统功能点的多少。FPA使得开发人员与用户有可能使用统一的方式方法定义系统的功能需求。用户不需要理解复杂的开发经过，能够根据功能点对相应的工作量进行估算，把握项目的整体开发工作量。 该 FPA 在很多参数估算模型中使用12.2004 年发布了(IFPUG 功能点计数实践手册 4.2 版1819. 2.5.3 功能点估算

8、步 FPA 以为任何软件都是五种【要素组成20.主要包括数据功能和事务功能两大类型。按照 IFPUG 4.2,需要对下面内容进行估算： 数据功能包括： 内部逻辑文件Internal Logical File,ILF 外部接口文件External Interface File,EIF 事务功能包括： 外部输入External Input,EI 外部输出External Output,EO 外部查询External Query,EQ 计算步骤是首先估算出各部分的复杂度，再确定各个部分的权重，最终就能获得对应的功能点数。由于 IFPUG 提供了对应的参考手册，便于实际操作，因而得到了很大的应用和推广

9、。 FPA 的步骤主要包括： 1 确定功能点类别和需求范围。 2 估算数据功能的 FP. 3 估算事务功能的 FP. 4 计算未调整 FPUFP。 5 确定值调整因子VAF值。 6 计算调整后的 FPAFP。 该经过能够用图 2-1 愈加具体的讲明： 由此看出，FPA 不仅能够在项目需求分析阶段进行估算，可以用于改善软件项目管理全经过22. FPA 方式方法已成为软件度量的基础23.接下来会对各步骤展开阐述。 2.5.4 确定功能点类型和需求范围 功能点类别主要有下面几种： 1 开发型项目 计算初次提交的功能点。 2 加强型项目 计算对现有功能进行改良牵涉到的功能，包括增加、删除、改变等动作。

10、 3 应用型项目 计算已经部署的项目的功能点，通常也被作为基线功能点，反映了项目最终为用户提供的功能点。 需求边界是指系统的需求范围，规定了软件提供的功能，系统逻辑和数据的范围。 2.5.5 数据功能点估算 数据功能点是由系统维护并使用的，主要包括 ILF 和 EIF.即内部逻辑文件和外部接口文件。这里 文件 并不合适于当代信息系统10.它指的是能够一起访问的一组数据或信息，与实际部署的物理实体并没有关系。 2.5.5.1 辨别 ILF 和 EIF ILF 是数据或信息的组合。一般必须知足如下的规则： 1 数据知足需求定义。 2 数据由系统维护。 EIF 是一组被查询逻辑数据或信息。一般必须知

11、足如下的规则： 1 数据知足需求定义。 2 数据由系统引用。 3 数据不由系统维护。 4 数据在其他系统中维护。 由此能够看出数据假如是被应用维护就是 ILF,否则就是 EIF. 2.5.5.2 计算 ILF 和 EIF 复杂度 在辨别了 ILF 与 EIF 之后，FPA 通过 DET 及 RET 来估算： 1 数据元素类型DET ,Data Element Types2 记录元素类型RET,Record Element TypesDET 是可辨别的单一字段，一般应该知足： 1 知足需求定义，非重复，被系统维护。 2 知足需求定义，非重复，被系统引用。 3 通过逻辑经过实现维护和引用。 4 仅

12、对那些使用的 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

13、 辨别处理元 首先要把事务分解为处理元，基本原则： 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 是系统向外部输出

14、加工过的数据或者控制信息的逻辑经过。EO 向系统外部提供处理过的信息，至少包含改变数据的经过或者改变系统的行为。 EQ是外部从系统中查询数据、控制信息的逻辑。EQ不加工数据和信息，也不输出新数据。 EO和EQ的作用都是对外部输出数据或控制信息，能够通过下面的几个条件进行区分： 1 输出了导出数据。 2 包含数学运算。 3 包含对内部数据文件的处理逻辑。 4 改变了系统的行为或状态。 上述条件中，只要有一条知足，就能够以为是EO.除此之外，EQ必须获得系统的输出，引用了内部数据文件。 2.5.6.4 计算 EI、EO 和 EQ 复杂度 接下来需要估算这三者的复杂度，主要包括 FTR 和 DET

15、的计算。 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 中的字段。

16、硬编码的文本，如标题。 系统生成的时间戳。 系统生成的变量。 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来进行调整，通过这些系统特征来评价计算出的功能点的级别

17、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%.调整后的功能

18、点数AFPC计算方式方法如下： AFPC = UFPC x VAF 2.6 统一建模语言 UML 介绍 2.6.1 概述 UML 是统一建模语言的缩写，汲取了多年软件工程的成果，是面向对象开发的行业标准语言。UML 具有标准化和可视化的特点。利用 UML 建模便于对象和规则的重用，确保了开发经过的一致性，运行独立于实现，软件项目的建模、分析、设计将详细和直观化，也更容易进行项目的分析和控制。 2.6.2 用例图 用例是一个外部可见的系统内聚功能单元13.用例图Use Case Diagram通过简单的图形描绘叙述方式，描绘叙述了系统的层次构造，提供的服务以及相互之间的交互。用例表示提供应系统的

19、使用者的功能，是对这些功能的逻辑描绘叙述。 用例的表述形式通俗易懂，贯穿于系统开发的各个阶段。尤其在分析需求阶段，能够用来从多个视角捕获系统需求。用例图非常便于用户和开发人员理解和实现系统功能24. 2.6.3 类图 类是一种描绘叙述符号13.类能够使用它来对那些有着一样本质的对象进行一定抽象，能够描绘叙述其一样的构造，或者类似的行为。 在 UML 中，类图Class Diagram显示了系统内部静态数据之间的关系。 类图定义了类的属性和操作以及相应的约束条件14.类图不仅在设计阶段非常重要，在实现前阶段也同样发挥关键作用，占据重要地位。 2.6.4 顺序图 顺序图Sequence Diagr

20、am显示了系统的动态行为，能够很直观的展示出消息是怎样在系统内部传递和处理的。顺序图用于描绘叙述对象间动态交互能力25. 2.7 本章小结 本章首先介绍了需求变更的基本知识以及对项目的影响。 接下来介绍了常见变更经过，主要包括敏捷类的变更管理经过和侧重经过控制的变更管理经过。另外还介绍了当前比拟流行的需求变更管理经过和工具，主要包括Telelogic的DOORS和IBM Rational的ClearQuest. 之后介绍了功能点估算方式方法的基本内容。首先介绍了FPA的基本概念和经典步骤。接下来就重点介绍了几个关键内容，包括确定功能点类型和需求边界、各种类型功能点的估算、调整因子以及调整后的FP. 最后介绍了UML的基本知识，包括UML的基本概念以及几个常用的UML图标，包括用例图，类图和顺序图，包括它们各自的特点和用处，为后续章节做好了准备工作。