需求变更管理

需求变更管理（精选8篇）

需求变更管理 篇1

摘要：计算机信息系统集成项目管理中的需求变更管理是控制项目范围的关键, 特别是电信行业竞争的日趋激烈, 支撑系统日趋复杂, 变更日趋频繁。只有利用项目管理中的需求变更管理的思路并结合行业特性才能积极适应当前频繁的需求变更, 保证项目的正常进行。

关键词：项目管理,需求变更,变更七步法

一项调查表明, 大约70%的信息系统集成项目的软件开发项目超出了估算的时间, 大型项目平均超出计划交付时间20%至50%, 90%以上的软件项目开发费用超出预算, 并且项目越大, 超出项目计划的程度越高。软件开发不同于其他产品的制造, 软件的整个过程都是设计过程 (没有制造过程) ;另外, 软件开发不需要使用大量的物质资源, 而主要是人力资源;并且, 软件开发的产品只是程序代码和技术文件, 并没有其他的物质结果。基于上述特点, 软件项目管理与其他项目管理相比, 有很大的独特性。因此, 只有对信息系统集成项目实施科学规范项目管理, 才能规范项目需求、降低项目成本、缩短项目工期、保证信息工程质量。

1 对项目管理的认识和体会

经过这几年来参与及管理项目的工作, 认为要有效的实施项目管理, 可以从以下几个方面进行考虑。

首先要界定项目规模的大小, 大项目和小项目的管理方式不完全一样。但从另一个角度来看, 项目的大与小并没有本质的区别, 很多方法是共通的。总体而言, 大中型项目, 软件开发主要分为六个阶段:立项阶段、启动阶段、计划阶段、执行阶段、控制阶段及收尾阶段。小项目也同样分为六个阶段, 但比较模糊, 侧重点也不一样。

1.1 项目立项阶段

一般来说, 大中型的项目必须进行项目的可行性研究分析, 小项目根据实际情况进行可行性研究分析后, 才会对项目进行立项。很多项目在进行可行性研究时会出现很多问题, 如:研究深度不够, 质量不高, 不能满足决策的需要;不重视多方案论证和比较, 无法进行优选;调查研究得不够, 导致项目投资收益计算失真;可行性研究报告的编制缺乏独立性、公正性和客观性;等等。对此, 首先要正确认识可行性研究的阶段划分与功能定位。其次, 按要求进行可行性研究, 正确确定其依据。第三, 采用科学的方法与先进的技术。第四, 建立科学的决策体系和管理机制。

1.2 项目启动阶段

项目启动阶段需要界定工作目标及工作任务;获得老板或高层的支持;组建优秀的项目团队;准备充足的资源;建立良好的沟通。

项目管理中最重要、最难做的工作就是界定工作目标及工作任务, 也就是确定项目的范围。缺少正确的项目范围定义和核实, 是项目失败的主要原因。

对于组件优化的项目团队, 要根据公司管理的实际情况结合项目规模来进行组织, 如果是大中型项目, 存在许多跨职能部门的活动, 以矩阵型组织结构进行最有效。如果是小项目则以垂直方案成立一个专门的项目组。

建立一套良好的沟通渠道。每一个项目都有一系列的干系人, 对项目的成功都有影响, 项目经理必须通过沟通来控制这些影响。项目经理要对三个方面的人负责任, 一是客户, 让客户满意, 达成客户的目标;二是公司领导, 达成公司的目标;三是项目组成员。客户和管理层往往不能站在项目的总体目标上看问题, 项目经理则要使决定符合项目的总体目标, 因此要花时间沟通, 以项目的总体目标协调各方的关系并获得支持。

项目启动要召开项目启动会议, 项目启动会议主要是建立正式的团队, 提供团队成员的角色和职责, 提供绩效管理方法, 向成员提供项目范围和目标。项目启动还要召开针对客户的项目启动会议, 在这个会议上项目经理会与客户确立正式的交流渠道, 项目综合描述, 让项目参与人员相互了解, 建立以项目经理为核心的管理制度。

1.3 项目计划阶段

创建和维护定义了项目活动的计划, 核心是人力、时间、进度。

将项目分解为可管理的活动, 也就是我们通常所说的WBS。通过对项目的目的的理解, 确定工作主要分为哪几个部分, 自上而下将大的部分分解为下一个层次, 将每个构成要素再分解为子构成要素, 逐级完成, 直到能够分派作业并监测。通过WBS的使用, 使项目成本可以估算, 是项目各项计划和控制措施编制的基础和主要依据, 保证了项目结构的系统性和完整性, 可以建立完整的项目保证体系, 便于执行和实现目标要求, 为建立项目信息沟通系统提供依据, 便于把握信息重点, 是项目范围变更控制的依据以及项目风险管理计划编制的依据。

项目进度计划是确定每项活动的开始和完成时间。如果开始和完成时间不现实, 项目就不可能按进度计划完成。制定项目进度计划首先要对WBS中确定的可交付成果的产生所必须完成的具体活动进行定义, 得到活动列表;然后通过前导图法、箭头图法或关键路径法工具和技术将活动顺序进行安排, 决定活动之间的逻辑关系;接着利用类比法、专家估计法、基于WBS的子活动估计方法或量化估计方法对活动工期进行估算;最后依据上面提到的活动定义、活动排序和活动历时估算等数据的获得, 反复进行改进, 获得适合本项目的进度计划。

1.4 项目执行和控制阶段

一般来说项目的执行和项目控制和计划是紧密结合在一起, 特别是执行和控制。在执行过程中会有很多不可预见的因素在影响着计划的按期执行。如不可抗拒力、需求变更、人员变更、成本超支、项目延期、性能下降等等各种问题。这些在项目执行阶段出现的问题都必须通过控制阶段进行有效的控制和规避。

项目执行、控制阶段主要进行进度控制、成本控制和质量控制。

进度控制:

项目进度控制是依据项目进度计划对项目的实际进展情况进行控制, 使项目能够按时完成。有效的项目进度控制关键是监控项目的实际进度, 及时、定期的将它与计划进度进行比较, 并立即采取必要的纠正措施。其内容包括:对造成进度变化的因素施加影响, 确保得到各方认可;查明进度是否已经发生变化;在实际变更发生时进行管理;进度控制应和其他控制进程紧密结合, 并且贯穿于项目的始终。

成本控制:

项目成本控制是指项目组织为保证在变化的条件下实现其预算成本, 按照事先拟订的计划和标准, 通过采用各种方法, 对项目实施过程中发生的各种实际成本与计划成本进行比较、检查、监督、引导和纠正, 尽量使项目的实际成本控制在计划和预算范围内的管理过程。项目成本控制是以项目各项工作的成本预算、成本基准计划、成本绩效报告、变更申请和项目成本管理计划为依据;以成本变更控制系统、绩效测量、补充计划编制和计算机工具等方法进行的。

质量控制:

全面质量管理强调追求顾客满意、注重预防而不是检查, 强调管理层对质量的责任以及全员参与, 持续改进。质量控制是以工作结果、质量管理计划和工作定义及检测列表为依据;以检验、统计抽样、核对表、排列图、直方图、散点图、控制图、流程图、趋势分析和6δ管理法为工具进行的。

1.5 项目收尾阶段

项目结束时, 项目经理要将最终系统方案提交给用户, 完成项目所有的交付物, 收集项目全部信息并结束项目, 完成或终止合约, 签署项目结束的相关文件。

项目结束时, 依然要开会, 主要有七大主题:技术绩效、成本绩效、进度计划绩效、项目计划与控制、项目沟通、识别问题与解决问题、意见和建议。同时也要总结经验教训。

项目团队得到客户满意评价的最好方式, 是向客户提交一份项目满意程度调查报告, 从客户那里得到好的反馈, 作为公司项目成功完成的案例证明。

2 实际项目中遇见的问题和解决办法

在实际工作中经常遇见有关需求管控方面的问题, 特别是电信门户网站的项目中和综合业务支撑系统的项目尤为突出, 这两个项目分别体现了需求管控的不同方面。

在电信门户网站项目的建设之初, 电信公司提出了一个整体的网站建设构想, 涉及的面很广并且关键功能是需要和电信的BSS域和OSS域的相关生产系统有交互, 功能比较复杂。同时要求的工程时限又非常的紧。鉴于这种情况, 组织项目组的相关成员进行了需求讨论, 并结合电信公司对时限的要求。决定将这个整体的网站建设构想分为一期和二期, 将电信公司比较紧迫的需求列入一期, 其他部分的需求列入二期。同时, 在需求分析中发现, 其提出的部分需求与电信集团公司下发的CTG-MBOSS的规范以及省级规划有冲突。如积分计算、管理、发布要求在网站实现, 但实际积分管理在省级的规划是在BSS域中的计费系统实现。在与电信公司再次沟通中, 为了保证工程进度, 他们同意了我们提出的分二期建设的建议;但是对于我们提出的部分需求和上级规范冲突的问题, 他们尽管确认了该需求确实有冲突, 但还是要求我们必须按照要求实现。为了规避这部分的需求风险, 我们在进行概要设计的阶段, 特别考虑了这个问题, 一方面按照电信公司的要求设计了积分管理的整个功能架构, 同时开发了与计费的接口模块。随后, 项目正常进行, 直至一期上线。在上线后三个月, 省级的计费系统中的积分管理功能启用, 上级电信公司发文要求所有的积分计算要以计费为准, 鉴于在作系统架构设计的时候考虑到了这个风险, 预留了接口, 所以只进行了很小的接口调测工作就顺利的完成了此次变更。一个月后, 电信公司决定在五·一期间开展“短信文学”和“七彩铃音”原创大赛、“电信·宽带专家”杯原创FLASH设计大赛活动, 需在电信门户网站设置活动专栏。并明确提出了具体的活动内容和功能需求。其中在“七彩铃音”部分有个关键需求是“作品定制功能”, 要求能够通过网站或短信可将作品定制为铃音。由于原来的网站系统架构中并没有与之对应的功能。经过对对端系统的业务了解, 发现所有的铃声都必须上传至特定的彩铃网站的服务器上, 在统一由该网站更新至彩铃平台。并且由不能确保所有的用户都申请了彩铃业务, 还需要和业务支撑系统进行交互, 并替没有彩铃业务的用户申请彩铃业务后, 才能实现作品定制功能。如果要做成这样一方面业务流程极其复杂, 开发工作量极大, 必然无法在要求的时限内完成;另一方面这些彩铃作品对彩铃平台造成了非常大的压力, 可能会影响彩铃平台的正常运行。在与电信公司的沟通中我们明确提出了该需求存在的这些问题, 同时也提出了一个变通的建议:将“作品定制功能”改为大赛结束后, 将上榜作品批量更新到彩铃平台, 再由用户通过彩铃网站, 按照自己的喜好进行定制。这样就可以规避这些问题, 同时也保证了比赛的正常进行。电信公司最终采纳了这个方案。

综合业务支撑系统对于电信公司来说是一个非常重要的生产系统。在做二期工程的时候, 尽管说做了五个月的需求调查工作, 形成了3000多页的需求文档。但是在二期工程分阶段分模块逐步上线, 原有的一期系统还在继续使用的同时, 出现了非常多的需求和故障, 内容几乎涉及到一期及二期的所有方面。重要的需求和故障无法跟踪, 大量的需求被延误。需求几乎到了无法控制的边缘。为了改变这种被动局面, 加强对需求管控, 我们上了一套问题跟踪系统, 将所有的需求、故障都放到这个平台上进行流转。并规范了故障处理流程、需求处理流程、测试流程、发布流程等等一系列的业务流程。通过这个平台和这些流程, 将一期的正常运维需求和二期的开发需求进行了分离, 保证了一期的正常运行。由于在流程中增加了审批环节, 避免了一些无效的需求;同时对合理的需求进行了统一的规划和安排, 降低了大量需求对正常开发进度的影响;对于重要的需求可以进行跟踪;很容易的了解每个成员的工作负荷, 进行有效的调整和均衡。通过这套系统也提高了客户的满意度, 使得二期项目得以有序进行。

总的来说在电信门户网站项目中比较成功的对需求进行了一定的掌控, 避免了需求的冲突和需求变更引发的项目风险。主要归功于了解了电信的CTG-MBOSS的规范和省级电信公司的IT建设的规划, 才能在跟客户进行有效沟通的前提下做好需求管控。在综合业务支撑系统中由于没有预计到需求变更的频繁, 导致需求几乎失控, 但通过问题跟踪系统和各种业务流程保证了需求变更的可控, 也提高了客户的满意度。

3 如何进行需求变更管理

通过此次过程对需求变更管理有了更深刻认识, 尽管说很多需求变更管理的方法在实际工作中都得到了的应用和体现。但是整体的思路还是得到了进一步的梳理, 特别是教授的“变更七步法”及其相配套的表格, 更是体现了变更控制的思想, 可以在日后指导项目管理中的工作。

第一步:先把理由说清楚

(1) 客户提交的变更必须基于书面形式。

(2) 客户提交的变更必须有充分理由。如果变更被拒绝, 对业务的负面影响;如果变更被接受, 对业务的正面影响。

第二步:能否实现做评估

(1) 从实现的方式上考虑新的变更是否可以实现。

(2) 在这里不需要考虑代价。

第三步:可以实现看进度

(1) 进度几乎是绝大多数项目的第一要素。

(2) 要考虑对活动级别的影响。

第四步:变更成本要算足

(1) 人员相关的变更成本。

(2) 是否需要额外的成员。

(3) 项目组需要增加的工时。

(4) 要考虑非人力成本的投入。如软、硬件、资料等。

第五步:资料不得有马虎

(1) 变更对质量的多方面影响。

(2) 分阶段影响 (需求、设计、编码、测试、维护) 。

(3) 对项目的可靠性、安全性、可维护性、可用性的影响。

第六步:评完TQC (时间、质量、成本) , 风险再细分

(1) 可能对团队士气的负面影响。

(2) 可能引发的间接任务对工期的负面冲击。

(3) 开发方的成本负担可能超出力所能及的范围。

(4) 客户避免成为强力“IT杀手”。

第七步:主意请大家拿

(1) 前面六个步骤分别由不同的角色做出, 而是否接受变更要请大家评判。

(2) 要考虑变更粒度、组织规模、业务模式、项目特点等。

结合目前我公司所承接电信行业软件项目的特点。认为除课堂上教授的“变更七步法”外, 还要考虑电信行业的特点, 不管是做BSS还是OSS项目的, 都必须首先遵循《中国电信CTG-MBOSS规范》, 再考虑省级电信公司的IT建设的滚动规划, 再结合电信公司的实际需求。在项目签订合同之初就要将项目管理中的各种流程, 特别是需求变更流程以合同附件的形式纳入到合同中, 这样就可以在发生变更的时候就可以有一个明确的流程来进行管控。才能应对电信行业频繁变化的需求, 保证项目的正常进行。

参考文献

[1]Harold Kerzner.项目管理[M].北京:电子工业出版社, 2005.

需求变更管理 篇2

项目名称： 长益高速收费数据分析系统一、概述

因湖南省高速公路联网拆分系统软件升级，导致长益下属收费站入口和出

口交易数据、拆分数据、代收拆分数据无法获取。而现阶段省高管局监控中心无法在上报报表日期内提供拆分数据，从而导致长益高速收费数据分析系统无法输出相关报表。经过深入了解和分析，在与业主方多次探讨后，提出以下变更说明。

二、变更内容

 MTC实收和流量

原始情况：

人工收费系统出口站收费数据和出口流量的导入，是由收费站工作

人员从站级拆帐网下载的“收费数据统计报表”并再录入部分细分数据，导入长益收费数据分析系统。

变更后：

收费站工作人员在分析系统中MTC实收功能模块中只录入出口各车

型实收收入、各车型流量、免费车流量、绿通车流量、系统外收入、绿通车减免金额、免费车减免金额、手工票金额。

运营部工作人员在分析系统中MTC实收功能模块中导入本路段各站

进，其他路段出的代收流量的各车型估算流量。其中包括各车型流量、绿通车流量、免费车流量。

 MTC实得

原始情况：

人工收费系统实得数据的导入，是由收费站工作人员从站级拆帐网

下载的“拆帐统计报表”，导入长益收费数据分析系统。

代收实得的导入，是由运营部工作人员从拆帐网下载的“长张高速

公司名称，版本号

2公路联网收费实际分配收入统计表”，导入长益数据分析系统。

变更后：

运营部工作人员在分析系统中MTC实得功能模块中导入估算MTC各

车型拆分收入。其中包括本路段各车型收入、系统外收入及代收业主各车型收入、系统外收入。

 报表输出

由于原始基础数据的变更，所导致从数据模型上的建立发生了变化，从而将导致原长益数据分析系统输出报表无法根据原来基础数据的数据输出，需要转换为估算的数据输出，需要对所有的报表进行修改。

需要修改的报表有以下：













































 公司－绿色通道车辆 公司－收费站拆帐情况表 公司－单车收费标准计算表 公司－流量对比表 公司－各类车流量收入比重对比图 公司－各类车流量收入比重表 公司－实征率 公司－高速免费车 公司－收费车流量统计 公司－ETC收费车与免费车 公司－月流量分析 公司－ETC征费情况 公司－月收入图 公司－月收费情况总表 公司-收费车流量与收入统计 路劲-收入影响因素对比表 路劲-项目每月输入及车流汇总表 路劲-各站每月收入及车流汇总表 路劲-历年路费收入图 路劲-历年次票车流量图 路劲-日报 省局-交通流量统计月报表 省局-绿色通道和免费车公司名称，版本号

 省局-其他收入分项统计

 三年同天对比-1月

 三年同期对比-2月

 三年同天对比-3月

 三年同期对比-4月

 三年同期对比-5月

 三年同期对比-6月

 三年同期对比-7月

 三年同期对比-8月

 三年同期对比-9月

 三年同期对比-10月

 三年同期对比-11月

 三年同期对比-12月

 周报-高速公路

 周报-总表

 周报-流量图

 周报-收入图

 周报-老路

 月报-月收费

 月报-财务系统内金额拆帐

 月报-月度收费情况

需求变更管理 篇3

1 需求变更流程

软件项目配置管理就是作为变更控制而引入到软件项目中的,其关键任务是控制变更活动,做到更灵活应变。管理需求变更,这个特定实践实现各项需求在项目推进期间发生演变的同时,对需求的变更进行管理。关于维护和控制需求基线以及确保项目使用有关需求和需求变更的信息。在项目推进期间,需求会由于各种各样原因而发生变更。随着原来的需要发生变化和工作的推进,将会产生一些附加的需求,因此必然要对现行的需求做出相应的变更。有效地管理这些需求和需求变更相当重要。有必要了解每个需求的来源,并且做出变更理由的文件。项目经理可能希望跟踪相应的需求变化度量数据,以便判断是否需要采取新的控制措施或对已有的控制做出调整。

变更管理是描述了纳入配置管理的配置项进行变更的完整流程。根据新需求、项目进度报告、客户意见反馈、软件工作产品复审记录等不同的原因提出变更申请,由项目小组或变更控制委员会(SCCB)分析其影响,确定变更请求的拒绝、接受或搁置,并根据不同的决定进行不同的处理,一直到变更请求被处理。具体流程图如图1所示。

一旦采用了严格的变更控制管理流程,才能了解变更造成的影响,所有项目组成员才了解变更,形成共识,接受变更。缺少对变更有效的控制,往往会造成配置管理的无序,导致项目返工、延期,甚至失败。

2 高校机房管理系统

高校机房管理系统主要是根据高校实验室的实际需求,针对实验室管理的具体业务特点,开发具有一定先进性、实用性和可扩展性强应用系统。主要功能模块包括:用户管理,设备管理、课程管理和系统管理功能模块。它面向的用户有学生、教师和管理员,它们可以根据用户不同权限,很方便的使用本系统提供的各项服务功能,以达到更佳的教学效果,并提高实验室的管理水平。系统功能结构如图2所示。

3 需求变更的实现

需求变更是软件开发过程中最重要环节,既然需求变更不可避免,如何将需求变更带来的风险有效化解就成为至关重要的问题。需求变更管理通过定义一个规范的流程来处理需求变更,力图使需求变动影响到工作产品尽可能的少,保证在需求发生变化的情况下项目仍能取得成功。通过“需求变更记录表”(见表1)进行记录,并通过“变更跟踪累计表(见表2)”累计需求变更对工作时间的总影响,以便对项目进行管理。

4 系统功能的扩展

4.1 外部扩展功能

当高校机房管理系统开发出来,发现还需要增加代理上网服务,可以控制各个实验室的上课时候的上网,即有些课程是需要让学生上网的,而有些是关掉外部网络,不给学生上网玩游戏、qq之类的。这就只需要在添加一部代理服务器(使用Linux代理),添加服务器后的拓扑图如图3所示。

代理服务器,是通过设置IP代理(192.168.32.50),让实验室里面的电脑通过内部网络,实现它的代理功能,可以控制实验室电脑访问外部网络的目的。具体实现代理服务网络结构图如图4所示。

4.2 内部功能扩展

现在想要在增加实验室申请的功能。有时候,实验室是空的,没人上课,而一些教学活动又需要用到实验室,这样就可以提出实验室使用申请,以更大程度的提高实验室的使用率,又可以满足各种教学活动的需求,管理起来也比较方便。

从流程来看,首先用户需要查看课程表,看看哪个实验室,在什么时间有空,可以供使用,然后用户只需要填写实验室使用的相关表,提交申请,管理员收到申请,批复后就可以使用了。具体流程如图5所示。

考虑到机房管理系统中已经有课程管理项,可以把它添加到课程管理中,设置为“课程申请”就是申请使用实验室。实现功能扩展后的实验室管理系统的整体功能图如图6所示,虚线表示新增的功能项。

5 结束语

在系统开发的过程中,往往会出现用户需求的变更,而随之而来的系统功能的变更,这给系统的开发者带来很多的麻烦,甚至导致系统的可用性较差。通过CMMI中的需求变更管理理论,来指导系统的开发,实现系统功能的扩展,就显得轻松、容易得多,它可以提高系统开发者的工作效率。

参考文献

[1]CMMI Product Team.Capability Maturity Model Integration(CMMI)Version1.2[Z].2006.

[2]郑琰.用CMMI指导需求管理[J].中国金融电脑,2005(1).

软件开发中的需求分析和需求变更 篇4

关键词：需求分析,需求变更,需求管理

1、引言

软件需求分析工作是软件生存周期中重要的一步，也是决定性的一步，只有通过软件需求分析，才能把软件功能和性能的总体概念描述为具体的软件需求规格说明，从而奠定软件开发的基础。

随着社会工业化、信息化以及计算机及其应用技术的迅速发展，各种各样的软件和系统也随之出现，软件开发人员所面临的应用系统的复杂性越来越高，规模也越来越大，支持系统开发的基础软件面临着系统的复杂性、多样性、不间断性和自适应性等一系列关键问题的挑战。需求分析的重要性和必要性也就体现出来了，需求分析的质量好坏直接影响整个软件工程的进展及最终的结果。Bell和Thayer提出，"不充分、相互矛盾以及非完全的软件需求描述是影响软件设计质量的一个非常关键的因素"。他们指出"设计一个系统的需求并不总是非常清楚的，特别是对于较为复杂的系统设计，需要采用工程的观点，对待开发软件系统的需求进行系统地分析和设计"。

2、需求分析概述

2.1 需求分析

需求分析的工作就是通过和用户进行交互以获取软件系统的需求，对它们进行描述和分析，产生规范化的需求文档，并要确保所产生的用户需求是完整的、一致的和准确的。

需求分析的类型我们可分为两大类：功能性需求和非功能性需求。功能性需求主要说明了系统可以完成的所有事情，涉及与本系统有接口的其他系统的所有事情。它是用户最主要的需求，通常包括系统的输入、系统要完成的功能、系统的输出以及其他。非功能性需求是软件开发过程中必须遵守的约束，是对可以使用的资源和软件质量的各个方面的限制。

2.2 需求分析的任务

软件需求分析的任务是确定系统要完成的工作，而不是怎样完成它的工作。它所做的工作就是深入描述软件的功能和性能，确定软件设计的限制和软件同其他元素的接口细节，定义软件的有效性要求，研究用户要求，准确地表达被接受的用户要求，确定被开发软件系统的系统元素，最后将功能和信息结构分配到这些系统元素中。因此，需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的"做什么"的问题，如图1。

由此可知，实现步骤是：

·获得当前系统的物理模型；

·抽象出当前系统的逻辑模型；

·建立目标系统的逻辑模型。

最终目标系统的具体物理模型是由它的逻辑模型经实例化，即具体到某个业务领域而得到的。

2.3 需求分析过程

软件需求分析的过程具体可分为信息获取、需求建模和需求报告产生三个阶段。

2.3.1 信息获取阶段：

主要任务是将各种信息从不同的用户角度不加选择地收集到一起。信息的收集过程可采用很多种方式，比如：采访、访谈、问卷调查、直接参与业务实践等方法，无论采用哪种方法，其主要目的是用户都能够表达他们的需求目标。在信息获取过程中，用户所表达的需求会有产生冲突和矛盾的地方，这时就需要需求人员进行协调，最终达成一致意见。在此过程中，需求分析人员应具有与人沟通能力，有良好的理解和表达能力，同时能总体规划，抽象和分解，确认事务本质。通过该阶段的工作，得到一个目标明确，需求完整的描述文档。

2.3.2 需求建模阶段：

需求分析的目的是通过对待开发软件系统预期实现目标的分析，识别出所有相关的概念和关系，建立需求模型。建立需求模型需要一套完善的需求分析理论的支持。现在有许多建模语言，其中最常用的有统一建模语言（UML）、统一开发过程（RUP）以及自动规约的知识获取（KAOS）等等。

2.3.3 需求报告产生阶段：

基于前两个阶段的工作，需求分析人员最终将提交出待开发软件系统的需求分析报告。其中重点包括分析系统的组件对象、领域约束和行为需求，以及从模型中抽取出基本的领域概念字典和涉及的资源信息等。这样的模型必须是一致的，明确的和完整的。这份报告将作为下一步开发的规范文件，并成为衡量设计是否达到需求要求的唯一标准。

3、需求变更及对策

自上个世纪60年代以来，软件工程思想逐渐形成与发展，出现了很多软件开发模型和方法，例如瀑布模型、演化模型、螺旋模型和智能模型等。而在90年代以后，卡耐基软件学院推出了CMM（软件过程成熟度模型），更是对于软件开发的过程管理，提出了确切的衡量指标。但是，近期的研究表明，仍有50%的项目会拖延交付，有30%以上的项目会超出预算，软件开发领域的项目情况比软件工程刚刚提出的时候相比，只是有很小的提高。分析项目失败的主要原因，大概有需求变更、沟通、技术能力、管理方法等方面的原因，但其中需求变更是导致项目没有按照预期完成而失败的最主要原因之一。所以如何处理好需求的变更将对项目的成败产生重要的影响。

3.1 需求变更的原因

3.1.1 问题域的复杂性越来越高。

在我国，从宏观上讲，正处于改革开放的历史时期，各行各业的体制改革正在热火朝天的开展，国家大力提倡管理创新和科技创新，因此，企业的各种标准、流程、事务都处于重组规范的过程中，因而系统需求的不明确、处于不断变化的状态也合情合理，导致问题域的复杂性越来越高。

3.1.2 交流障碍。

需求分析过程所涉及人员具备的背景知识不同，需求人员一般是以软件及其相关专业为主体的专业，而用户方是以自身业务为主体的专业的，他们考虑问题的角度不同，扮演的角色不同，认识上容易混淆，产生误解（自然语言的多义性，一语双关等），相互之间的交流存在一定的困难。

3.1.3 完整性问题。

因专业背景，技术等方面的原因，导致用户很难准确地把系统需求表达给需求分析人员，业务方面的局限导致开发方也很难准确获取客户方的真实的需求。这样的结果就导致用户对问题的陈述往往是不完备的，导致需求也是不完整的。

3.1.4 需求变动过多。

客户方对需求的重视程度不够，对自身业务的抽象程度不够，导致需求不够细化明确，对需求经常做变动，而需求的不断变更，导致后继工作不能按计划完成，从而影响整个系统的开发。

3.2 相应对策

软件需求变更是不可避免的，也是不可回避的，既然如此，就应该以正确的心态去面对它，解决它所带来的一系列问题。在进行软件需求分析的过程中，可以从以下几个方面来积极地应对需求变更。

3.2.1 思想认识上

好的软件产品取决于好的需求分析，而这是需要客户和开发人员之间的很好的交流和合作，因此，培养正确的需求意识是必要的，也是合作双方需要努力的，同时，开发人员更应该发挥积极主动的作用。

需求分析人员的思想意识：应对需求变化的意识，随着用户对系统需求的认识在不断加深和业务流程在不断变化，需求也在不断的增加、变化，这就需要需求人员正确对待用户需求的变化，运用新技术主动应对需求的不断变化。寻求用户支持的意识，因为不可能一次就完全了解用户的需求，而且在系统开发过程中还需要用户不断的参与到其中，因而寻求用户的支持是必须的。维权意识, 在系统的开发过程中，为了避免出现和减少与用户间的摩擦，合作的双方应该签订一份协议，在协议中明确规定双方应承担的责任和义务，在一定程度上减少双方之间的摩擦和随意的需求变更。

客户的思想意识：充分认识需求分析的重要性，认识到低质量的需求可能导致的严重后果，主动地参与需求分析。同时也要意识到由于技术、人力等资源的限制，计算机并不能解决当前存在的所有问题，并且软件产品的开发需要一定的时间，所以在向开发人员提出系统需求时，不能需求过多。最后，客户方还要有减少需求变化的意识，因为需求的变更，在一定程度上，会增加开发的成本和工期的延长。

3.2.2 项目管理上

需求调研前期的准备工作。在需求调研前将掌握的资料进行汇总，制定需求开发的计划，制定人员培训计划，对项目参与人员进行培训。

划定项目范围，拟定协议，明确项目的范围，有效地防止在开发过程范围不受控制的扩展，同时，要与客户方拟定一个协议，明确指出项目包括和不包括的特性和功能界线。

需求版本的控制。应该有专人负责需求文档的更新、管理、发布和版本控制等，组内每个成员必须能够得到当前版本，每一个公布的需求文档应该包括一个修正版本的历史状况，包括变更内容、日期和原因等。

3.2.3 技术支持上

当需求变更时，为了更好的适应需求的变化，需求人员可采用技术对策，比如：原型法、敏捷开发方法和软件复用技术等。需求人员还可以采用需求管理工具，需求管理工具有：CA公司的CA-Super Project&Project Software和Rational公司的Analys Studio等。

4、结束语

需求分析，在软件开发过程中是必须要面临的一个环节，由于自身的特点，软件需求分析过程中发生的变化也较多，如何有效的减少需求的变更，要求需求人员和客户方都要有正确的思想认识，在开发过程中积极合作，通过制定协议制定各方要承担的责任和义务，树立减少需求变更的意识，积极地采用新的技术支持来应对变更。需求分析文档要规范，合作的双方要精诚合作，分析和总结实践经验，努力提高技术水平，确保软件开发工作按照正确的方向进行，最终获得成功。

参考文献

[1].郑人杰殷人昆陶永雷.实用软件工程[M].清华大学出版社, 1997

[2].李师贤张珞玲.需求分析的常见问题及其对策分析[J].计算机工程, 2002, (1)

[3].陈宏烨赵文刚.基于软件开发的需求分析及需求管理[J].甘肃科技, 2008, (1)

软件项目的需求变更及对策 篇5

什么是需求分析?

要知道需求变更是什么, 首先要知道什么是需求分析。

需求分析是指理解客户需求, 就软件功能与客户达成一致, 估计软件风险和评估项目成本代价, 最终形成开发计划的一个复杂过程。需求分析的成果形成需求说明书。

什么是需求变更?

根据软件工程思想定义, 需求说明书一般要经过论证, 如果在需求说明书经过论证以后, 需要在原有需求基础上追加和补充新的需求, 或对原有需求进行修改和削减, 均属于需求变更。

二、需求变更的原因及影响

1. 需求变更原因

一方面是用户:他们是项目需求的提出者。一个十分常见的现象是用户提出需求以后, 在软件开发过程中用户改变了需求, 这只能迫使开发工作返工, 丢弃一些无法修正的部分。无疑这会造成一定的损失, 但又无法完全避免。要求用户一次性把需求讲清楚, 并且不允许此后需求有任何变更, 这是不现实的。只能尽量减少需求变更, 降低它所造成的影响。

二是系统因素:在系统内部, 如计算机硬件、系统软件或数据的变更要求与其相适应。

三是外部环境因素:与软件运行相关的工作制度或法规、政策的变更, 或是业务要求变更导致的需求变更。

四是需求分析阶段工作缺陷:需求调研、分析、定义和评审工作不够充分, 致使需求规格说明中隐含着问题, 在开发过程中才有所发现。或者需求开发中开发人员与用户沟通不够充分, 如未能如实获得用户的潜在需求等。

软件需求一旦出现变更, 它可能要涉及到一些相关的代码和文档的修改, 为此要把这一变更通知到所有相关人员。提出需求变更有可能在开发的任何阶段, 并且随着项目的进展, 越晚的需求变更引起的损失越大。

2. 需求变更给软件的开发工作带来的影响

需求变更对软件开发的影响是多方面的, 概括的看, 包括以下三个方面:

(1) 增加项目的人员、费用开支, 影响开发进度。需求变意味着原先的需求调研、分析的结果与预期的软件实现存在偏差, 需要进行需求变更。这无疑要增加项目的人员、费用的开支, 并对开发进度造成影响。更有甚者, 如果变更频繁, 可能对项目造成较大影响, 严重时可能直接导致项目的失败。

(2) 影响软件质量。在一个复杂的软件系统中, 需求之间具有一定的联系, 相关需求可构成需求链。如果由于需求变更导致需求链的某些环节脱节, 就可能引起一些难以察觉的错误。当需求变更没能及时修改项目的设计、开发文档时, 这些错误一般难以被测试人员发现, 将直接影响系统质量, 严重时可导致系统崩溃。

(3) 影响开发者与用户之间的合作关系。需求变更的实施是用户和开发者相互协作的过程。开发者和用户在是否采用变更问题上常常产生分歧, 如果没有恰当处理, 影响双方的互信, 从而影响项目开发进程。同时需求变更也会在项目开发人员之间产生分歧, 影响合作关系。

三、采取的对策

1. 首先是预防

尽量做好需求分析工作, 以期减少需求变更的频次, 为此在需求分析阶段着重处理好以下问题, 力图使需求分析的结果更接近目标。

(1) 培养正确的需求意识。优秀软件产品建立在优秀的需求基础之上, 而高质量的需求又来源于客户与开发人员之间有效的交流与合作。因此, 双方的参与者都需要认识到:要想获得成功, 自己需要什么, 合作方又需要什么。只有这样, 才能建立融洽的合作关系。因此, 培养正确的需求意识是双方都需要努力的, 而开发人员在这个阶段应该发挥更加积极主动的作用。

首先, 需求分析人员应该接受一定的正规培训, 以提高与人沟通的能力、缓解矛盾的能力、善于倾听和询问的技巧, 以及收集整理资料的能力等。在参与具体项目时, 分析人员也应主动学习一些项目所涉及的具体应用领域的基本知识, 以更好地理解用户的需求。

其次, 开发单位应该对那些不想花时间在需求分析上的用户明确指出:如果用户不能充分地支持并参与, 项目很可能会失败;开发单位还可以通过学习一些前车之鉴的真实案例警告用户:低质量的需求分析可能导致严重的后果。通过对用户代表和管理人员的培训, 使他们真正理解需求分析的重要性和忽略需求带来的风险, 并对计算机系统有一个大体的了解, 这样用户才能够主动地参与需求分析。

同时, 正因为不可能一次就完全了解用户的需求, 而且在系统开发过程中还需要不断地请用户参与, 因此与用户的沟通是需要贯穿始终的。需求分析中所采取的一些策略可能会让用户觉得意外和难以接受。因此, 需求分析人员需要对用户解释一些做法的必要性和合理性, 以得到用户最大的支持与合作。

(2) 从业务需求入手。用户认识到了需求分析的重要性, 但可能仍然不知道从何处入手表达自己的需求。这时可以从业务需求入手, 任何企业对自己的经营运作目标应该是比较清楚的, 这样的经营背景让用户不仅有话说, 也让开发者有章可循。需求分析不可以完全与它所处的背景相脱离, 只有当系统真正置身于它的社会和组织环境中, 它的需求才能清晰地反映出来。

(3) 充分利用需求来源。有了以上需求背景, 就比较容易做到有的放矢了。需求分析人员可以直接与系统未来的操作者探讨他们希望有什么样的软件;观察系统的潜在用户当前的日常工作以获取有价值的信息;系统的使用者可能有很多, 可以将他们分类以简化需求;最后一定要与真正的决定者达成协议:对于有冲突的需求如何权衡, 对于直接用户的众多需求如何取舍等。

同时, 用户往往对计算机期望过高, 认为计算机可以解决当前存在的所有问题, 因此会提出很多的功能需求, 并且希望在很短的时间内看到成效。但是, 由于技术、人力等资源的限制, 并不一定能够在设定的时间期限内满足用户所有的期望, 这时就应该尽早确定出交付的产品应具备的最重要功能, 即设定需求的优先级。

在这个阶段, 可以采用UML中的用例图帮助用户和需求分析人员之间的交流。一个用例图描述用户可以用软件产品执行的一个任务。它不是从软件的性能和系统的行为方面出发, 而是从用户到底能够用这个软件产品干什么入手。这样的方式用户比较熟悉, 容易沟通;而且不会在需求分析的一开始就陷入过于细节化的设计, 也有助于避免分析人员添加一些与所需任务无关的自认为很好的功能。

(4) 提供选择方案。由于用户对软件系统缺乏经验, 或者由于用户的运作机制还未完善, 或者由于其他种种原因, 用户可能仍然不能对一些需求做出明确的说明, 收集整理的需求中可能仍然存在一些不确定因素。这时可提出几份比较详细的方案。附带不同做法的优点, 供用户选择或者启发用户确定需求。

如果需求分析做得好, 文档清晰且又有客户签字, 那么后期客户提出的变更就超出了合同范围, 需要另外收费。这个时候, 开发方一定要据理力争, 此时这并非要刻意赚取客户的钱财, 而是不能让客户养成经常变更的习惯, 否则后患无穷。

2. 分级管理客户需求

软件开发项目中, “客户永远是对的”和“客户是上帝”并不完全的正确, 因为在已经签定的项目合同中, 任何新需求的变更和增加除了影响项目的正常进行以外, 还影响到了客户的投入收益, 所以有的时候项目经理反倒应该为客户着想。

对于项目中的需求变更, 可以实行分级管理, 以达到对需求变更的控制。

一级需求变更是关键性的需求, 这种需求如果不满足, 意味着整个项目不能正常交付使用, 前期工作也会被全部否定。这个级别的需求是必须满足的, 否则就意味着否定自已的项目成员和成员的所有努力, 所以定为“Urgent”。

二级需求变更是后续关键性需求, 它不影响前面工作内容的交付, 但不加以满足, 新的项目内容无法提交或继续, 所以是“Necessary”。一般新模块关键性的基础组件, 属于这个级别。

三级需求是后续重要的需求, 如果不被满足会令整体项目工作的价值下降, 为了体现项目价值, 也是开发人员自已的技术价值的证明, 所以定为“Needed”。一般性的重大的有价值的全新模块开发, 属于这个级别。

以上三个等级是应该实施的, 但时间性上可以作优先级的排列。

四级需求是改良性需求, 没有满足这类需求并不影响已有功能的使用, 但如果实现了则会更好, 定级为“Better”。界面和使用方式的需求, 一般在这个档次。

五级需求是可选性需求, 更多的是一种设想, 以及一种可能, 通常只是客户的的一种个人喜好而已, 定级为“Maybe”。

对于四级需求, 如果时间和资源条件都允许的话, 不妨做下去。对于五级需求, 正如对它的描述一样做与不做是“Maybe”。

3. 加强需求变更的控制

在需求分析阶段工作完成后, 需求变更仍可以会发生, 因此就要加强对需求变更的控制, 主要有以下原则:

(1) 建立需求基线。需求基线是需求变更的依据。在开发过程中, 需求确定并经过评审后 (用户参与评审) , 可以建立第一个需求基线。此后每次变更并经过评审后, 都要重新确定新的需求基线。

(2) 制订简单、有效的变更控制流程, 并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时, 这个流程具有一定的普遍性, 对以后的项目开发和其他项目都有借鉴作用。

(3) 成立项目变更控制委员会 (CCB) 或相关职能的类似组织, 负责裁定接受哪些变更。CCB由项目所涉及的多方人员共同组成, 应该包括用户方和开发方的决策人员在内。

(4) 需求变更一定要先申请然后再评估, 最后经过与变更大小相当级别的评审确认。

(5) 需求变更后, 受影响的软件计划、产品、活动都要进行相应的变更, 以保持和更新的需求一致。

(6) 妥善保存变更产生的相关文档。

这六大原则看起来简单, 但真正实施起来有难度, 还需要依据理论知识配合开发项目组的实际工作情况, 在实践中不断摸索总结。

四、总结

软件项目的需求变更是对软件产品的质量、成本、工期带来巨大的影响。通过预防性措施和加强需求变更的控制与管理, 将需求变更的频次大幅度降低, 从而为软件项目的顺利实施打下坚实基础。

参考文献

[1]王莉吴洁明:软件项目中的需求变更管理的研究[J].计算机技术与发展, 2007, 17 (1) :120～121

[2]王强:软件开发项目中的需求变更管理[J].电脑知识与技术 (学术交流) , 2007, (11)

[3]李师贤张珞玲:需求分析的常见问题及其对策分析[J].计算机工程, 2002, 28 (1) :7～8

浅议IT项目需求变更问题与对策 篇6

客观地说, 需求变更这种情况的出现几乎是必然的, 因此如何解决需求管控, 并对其进行有效处理就变成了IT项目经理的必修课。IT项目需求之所以变化, 是IT项目需求本身的复杂性造成的。与传统项目比较, IT项目的需求相对模糊, 变动较大, 主观随

浅议IT项目需求变更问题与对策

□文/田辉

意性较强, 具体体现在以下三个方面:

1、需求的准确描述。

需求来源于客户, 但很少有客户会很认真地准备需求文档。笔者在项目当中经常见到的情况都是甲方简要的提出自己的需求 (三言两语而已) , 或者甲乙双方在需求沟通会上做一个业务设想的沟通交流, 这样造成了需求最初来源的简易化和随机化。一般情况下, 乙方会根据沟通会上的情形对甲方需求进行还原, 最终形成上百页的需求文档, 并交由甲方签字确认, 以此作为需求的文字来源。如此操作在表面上看来是完备的, 但实际工作当中, 需求往往来源于甲方不同部门、不同层次的业务人员, 不同的人员对业务的理解自然也带有自身的本位想法, 对系统的关注角度也不尽相同。这可能就此造成了需求的矛盾与歧义 (此问题是可以在甲方层面上协调解决的) 。甲方确认需求当然是毫无疑义的, 但甲方是否系统的、全面的审阅了乙方还原后的需求汇总, 那就不得而知了。

同时, 甲乙双方对于需求的理解也有一定的差距, 比如作一个登录用户的认证功能, 对于甲方来说可能有自己先入为主的认识, 很可能乙方也已经有了自己的理解, 在这样的沟通过程中, 甲乙双方很可能就迅速达成了“共识”, 当按照乙方理解开发出来的最终产品呈现在对此功能已经有了设想的甲方面前的时候, 此功能的需求文档就成了双方掰持不清的糊涂账。

另外, 由于甲乙两方在业务知识层面上属于两个不同的方向, 这样很可能造成需求的完整度不足。一般来说, 甲方对业务更为了解, 技术业务层面了解相对较少;反之, 乙方亦然。这样就造成了双方沟通需求的时候, 甲方提供的需求完整度不足, 比如, 甲方提供了必须实现的业务需求, 乙方忠实地作了记录, 并根据沟通了解了甲方的需求内容, 但甲方只是提供了自己的需求、想要的功能, 要知道系统是由多个功能模块组成的, 甲方很可能把一些其自认为是常用的功能模块作为必须功能而未作阐述, 这就造成了需求功能的缺失。

需求的详细准确程度也是一个大问题, 在明确需求的时候, 往往甲乙两方只是对某一需求达成了共识, 但可能并不明确这个达成共识的需求具体如何实现, 也许乙方的实现并非甲方所愿, 如甲方要求实现某种数据检索, 乙方的实现方式只能支撑低量级的数据量, 碰巧实战当中要检索的数据量是天量级的, 这就造成功能失效。

2、明确需求工期不足。

需求的生成也是需要工期的, 对于甲方来说, 需求由乙方前来调研, 开完需求调研会, 再开几个碰头会, 需求调研应该就算完成了。对于乙方项目经理来说, 这种工作恐怕只是开始。如前文所述, 需求的准确获取需要大量时间, 还需要相当一部分人力资源, 对需求进行推敲、确定。但在实际工作当中, 甲乙双方的上层很难认同这种耗费时间且没什么直接效益的工作, 如此就造成了如下现象:项目经理为保证需求的准确性拼命拖时间;甲乙双方上层因为见不到成果不断对项目组施加压力;由于需求的反复沟通修改, 项目组成员也对此感到疲乏厌倦, 希望尽快了结此项工作;多方权衡的结果, 很可能就造成项目经理的退让。在这样情况下诞生的需求文档, 其有效性、稳定性就有可能是有限的。

3、项目需求变化极快。

不同于工程类项目, IT项目的变化极快, 尤其是互联网类型的项目。前文中我们了解了需求不完整这一情况, 需求调研的不完备、不准确都会给后边的项目实施带来变数。在互联网时代, 业务的诞生几乎是爆炸式的, 新的业务往往会对现有的项目造成影响, 甚至是颠覆性的影响, 这也给项目实施带来困难。

在项目实施当中, 随着时间的推移, 用户、业务都在发生转变, 由于操作人员、系统、业务流程之间的关系发生变化, 业务发生变化, 自然需求也跟着变化。在互联网项目当中, 往往某些项目带有突发的革命性需求, 如甲方设计一个搜索网站, 必须保证与业界同类型的网站保持一致, 若业界出现了一个全新的极受用户欢迎的业务, 那就必须把此项功能加入, 否则可能本项目就算完成, 也不能达成甲方项目设计的初衷。此案例中的需求变化对项目造成的影响可以说是颠覆性的。

二、IT项目管理需求变更对策

以上几点是笔者分析项目需求变化的原因, 对于这样的需求变化, 必须有对于需求变更的管控办法或者处理策略, 否则这些需求变更造成的项目成本增加、进度推迟恐怕会毁了项目实施。笔者认为, 对于上文所提到的项目需求不完备等情况, 由于现时情况不太可能得到彻底的解决, 因此只能在后续的项目需求管控当中进行补救处理。

1、需求评审流程化处理。对于需求的变更、增添认定均需要走专门的流程。可能有不少同行感觉这样要求有点多余, 但笔者认为新的需求变化都是在业务演进过程中逐步出现的, 对于需求变更的评审, 有助于项目组加强对业务需求本质的把握与理解, 有可能通过对新需求的评估, 推断出业务的演进方向, 或者增加项目需求的完备程度。同时, 对需求的评估也可以使项目组更好地把握现有的工作进展情况。

2、需求确认。任何需求的变更, 都不可避免地影响到项目的工作量, 进而影响到进度, 且项目需求来源于甲方, 因此需求的确认必须有甲方的签字确认。对于乙方来说, 所有的这些需求的实现都是有投入成本的, 这些成本的来源就是甲方的“签字”确定的需求或需求变更。笔者曾经历过一个IT项目, 在该项目实施过程当中, 为避免风险, 邀请一个甲方业务人员作为业务指导, 项目期间项目组对甲方代表

提要本文以新疆上市公司2007~2008年数据以及反映业绩状况的三个指标 (盈亏状况、净利润增长率和净资产收益率) 为依据, 说明业绩状况与股利分配方式的关系, 进而提出在制定股利政策时, 必须充分考虑自身业绩状况以及未来发展规划, 更要注意股利分配行为与其业绩状况相匹配, 只有这样公司才能得到良性健康发展。

配方式指标名称指标定义盈亏状况

净利润增长率净资产收益率

净利润大于零时为盈利, 净利润小于零时为亏损

净利润增长率= (本年净利润-上年净利润) /上年净利润净资产收益率=净利润/平均净资产×100%

表1指标名称及定义

所占比例 (%)

(三) 股利分配情况。

目前, 上市公司的股利分配方式主要包括现金股利、股票股利、公积金转增股本和混合股利分配方式, 从新疆上市公司2007~2008年的分配情况来看也是以上四种方式, 并且近两年在新疆上市公司中没有纯粹的股票股利分配方式, 股票股利分配方式只在混合股利分配方式中出现。

样本公司2007~2008年股利分配方式情况见表2、表3。 (表2、表3) 从表2平均数看出:样本公司的股利分配方式主要采取了派发

新疆上市公司业绩状况及股利分配方式

□文/孙晓立

一、新疆上市公司业绩状况与股利分配情况分析

(一) 样本选择。为了考察上市公司业绩状况与其股利分配行为的关系, 本文以新疆上市公司连续两年 (2007~2008年) 的年报作为分析基础, 样本选择以2007年30家上市公司和2008年32家上市公司为对象。

(二) 指标选择。公司的业绩状况主要以三组财务指标说明, 即盈亏状况、净利润增长率及净资产收益率, 详见表1。 (表1)

的意见言听计从, 根据其要求对项目的某些部分进行大量变更, 因此延误了项目工期, 且发现项目上线后, 某些其建议功能并不为甲方整体认可, 为此还得修改, 其间造成了不少无用的工作, 此部分项目投入没有任何意义。这一案例表明, 项目需求的变更应经过甲方官方同意, 若甲方业务决策人员知悉此问题, 就可能避免这部分无效投入。

3、项目计划冗余准备。项目计划冗余准备是指在项目计划当中, 对项目投入准备一定比例的富余量。在具体项目实施项目中, 项目变更几乎是不可避免的, 这些变更包括需求变化、风险的发生等多种情况, 若在项目收支许可的范围内做一定的冗余准备, 在较小的变更发生时, 就可以通过项目计划当中的富余资源处理, 从而保证项目实施进度。平心而论, 这种操作办法是要让乙方投入更多的成本来完成项目, 对乙方不太公平, 但在商业项目当中, 若能尽早完成项目, 就可以保证乙方的大部分利益, 适当的平衡一下投入上的取舍, 也是很好的解决办法。同时, 本办法也适用于项目的风险处理。

4、商务处理办法。

笔者曾经见过一个工程项目, 在此项目合同中确定了工程的基本工作量预估, 并明确当实际工作量超过预估工作量的10%以内时, 由乙方自行承担;若超过10%限度, 根据超出工作量多少, 结合合同约定的单价进行处理。此案例给了我们另一个解决项目变更的办法:通过商务合同中对工作量的约定, 来保障项目的实施。案例当中的实际工作量异常, 可视为IT项目当中的需求调研不完备, 或是需求变更造成的实际工作量增加, 若在商务合同当中明确有关工作量、超额工作量的约定, 就可以按照合同约定解决由于需求变更而造成的项目成本、进度问题。

摘要：IT项目管理是项目管理在IT领域的应用。由于信息技术行业的特点I, T项目管理除了具有项目管理普遍特性外, 还具有需求变化快、需求变更频繁等特点, 造成IT项目管理难度相对较大、项目成本、进度控制不力等现象, 因此对IT项目的需求管控和项目实施过程中的项目需求变更对策就成了IT项目管理操作上的一个重点, 也成为广大IT项目经理在项目管理方向上探讨的一个焦点。

关键词：项目管理,需求管控,成本控制

参考文献

[1]吕凌.IT项目行业管理现状以及发展趋势[J].高科技产业, 2004.4.

需求变更管理 篇7

软件的设计过程与迭代

在开发软件的过程中, 迭代是一个重要的风险源。因为软件体系内各个组件间的依赖关系十分复杂, 需求变更影响的传播, 让设计软件的过程必须不断重复、迭代设计:首先, 下游活动经常会因为上游活动过程的变化而不断重组或更改;其次, 在上游的活动需要下游活动进行信息反馈时, 上游活动就会因为下游活动的改变而重新进行设计;最后, 当下游活动因某些情况而不可用时, 基本都会导致相关活动的重做。所以要想减少不必要的迭代, 加强对设计活动的理解将是一个很好的方法, 同时这个方法, 还能帮助降低开发软件的风险。

对需求变更传播风险的评估需要确定的变更影响的波及范围, 而软件体系中的各种依赖关系则是进行分析的基础。传统的如PERT网、CMP等项目管理工具, 只能应用在平行与顺序结构的活动中, 是无法对迭代处理进行直接处理的, 而且对设计过程中的变化与重组也是不支持的。而DSM这种分析变更需求传播风险的工具, 不但可以将元素间复杂的依赖关系清晰的反映出来, 同时还可以将设计过程中的各种迭代与反馈都表示出来, 这种紧凑的形式对于可视化分析复杂系统来说是非常有利的。此外, DSM还能同时支持聚类或划分等算法的优化, 并且因为这些算法都是基于矩阵运算之上的, 所以更方便在计算机上进行操作。

DSM建模

DSM模型是一种通过n×n方阵像是来分析复杂系统并对其进行建模的工具。在DSM中, 各种组成系统的元素都通过相同的顺序排列在矩阵的第一列、第一行。对软件的体系结构进行分解, 使其成为一组相互关联的组件, 通过DSM模型对组件的依赖关系进行描述。对角线元素在其中并不是用来秒速系统关系的, 予以填充;而行与列间的关系, 则是每列中的元素对相应行中的元素的影响。对角线下的元素代表组件进行的正向前馈信息, 而其上的信息则代表逆向反馈信息。在进行软件设计时, 反馈信息的出现将会导致设计活动的迭代与反复, 进而致使工期延误与成本超支。

DSM模型不但可以将系统中的迭代与反馈都直观的表现出来, 同时还可以支持模块的重组, 并最大限度的消除反馈, 下图为某个较为简单的软件系统的DSM模型和划分结果:

在这一模型中, 组件B、C被组件A影响, 而组件A依赖组件C, 组件C与A之间是耦合关系。在进行划分前, DSM模型中有两个反馈信息, 在划分后就只余下一个反馈信息。因为组件C和组件A间的耦合关系, 是无法将反馈信息完全消除的。但是若将组件C与A当做一个整体, 两者间的耦合关系就成了内部关系, 而整个系统也就分成了{A, C}、{B}和{D}这三个模块, 这样也就消除了其中的反馈信息。而进行划分运算就是为了利用对系统组成元素的重组, 最大限度的将模块间反馈信息消除, 进而使设计迭代的风险得以降低。

分析变更传播风险的具体内容

从变更传播过程的角度来说, 变更传播就是从变更源头通过某些变更路径达到变更的目标。这种有变更传播而带来的风险不但会通过变更目标体现出来, 同时还和变更路径与源头有关。变更从某一角度来说, 变更目标的风险是由变更源与进行变更传播的实体来决定如何表现的。所以, 本文的观点是, 完整的变更传播风险在进行分析时应该包括以下几点:

在这些内容中, 变更传播风险值代表的是软件体系中潜藏与组件中的风险的大小。而变更传播所带来的影响则是变更源与参与实体能够对软件设计造成的整体影响结果。

变更传播风险有何含义

虽然软件需求的改变是确定, 但同时它也是不确定的。它的确定是因为在开发软件的过程中, 需求是一定会发生改变的。它的不确定指的则是发生变更的需求是哪些、发生变更的可能性有多大和这种变更会对软件系统造成怎样的影响, 这些都是不确定的。而这种不确定性也正是对需求变更风险进行评估的基础。

所谓风险, 指的就是在某中特定的危险情况到到来的后果及这种可能性的组合。本文的观点是, 变更传播风险是需求变更影响程度、传播概率的总和。软件的需求变更传播所带来的风险就可以化为两个方面, 即与影响性相关以及与发生可能性相关, 以下是相关定义:

第一, 所谓变更传播概率, 指的就是某一个组件在出现变更时, 和它有直接关联的其他组件也出现变更的可能性。

第二, 所谓变更影响概率, 指的就是当某一个组件所发生的变更直接通过某些途径传播到另一个组件时, 受到影响的组件必须重新进行设计的可能性。

第三, 所谓的变更传播风险, 指的就是变更传播概率及其影响概率二者的乘积。

在定义的第一条与第二条中, 都特别指出了“直接”影响, 而通过它们决定出来的变更传播风险, 即第三条定义中谈到的, 是直接变更传播风险。如果组件A的变更会对组件B造成影响, 但是却不会对组件C产生直接影响, 而组件B出现的变更却会对组件C造成影响。同时, 组件C和组件A间的那种间接性的变更储备风险则不再第三条定义中。

变更传播风险模型的应用

将DSM的变更需求传播风险分析模型当做基础, 向开发与管理软件项目提供一个评估风险的思路:

第一, 对于在开发软件初期无法得到的代码行与功能点等各种信息, 将软件体系结构当做载体, 将需求变更影响传播当做衡量标准来评估软件项目的风险, 这一点是与软件项目管理中越早进行风险评估越好的原则相符的。

第二, 从变更传播概率及其影响概率这两点上, 对变更传播的分析进行定义, 并研究那些被影响的实体。对每个组件中潜藏的风险值的大小进行评估, 并确定出该组件在传播的过程中所扮演的角色, 找到关键的风险源。

第三, 将设计迭代当做主要对象, 利用DSM的结构特征, 对变更源及其参与实体做进一步的研究。找出不同组件在传播变更的过程中所具备的特点, 并研究变更传播所造成的影响。

事实上, 软件变更需求的形式有三种, 分别为增加、删除以及修改。而本文提出的DSM模型, 只在分析特定软件体系的静态变更传播风险时能够适用, 一旦需求的变更改变了软件体系中的各种关系时, 就只能重新建立DSM模型再评估传播风险了。而这也正是此种方法的限制所在。

第一, 增加、整合、拆分组件。若需求的变更让原软件的体系中出现了由组件增加、整合、拆分而形成的新软件结构, 就需要建立新的评估风险的DSM模型。

第二, 删除组件。若原有组件因为需求的变更而被删除, 而在DSM模型中, 被删除的部分恰好是没有输出信息的组件, 那么就需要对其他有关组件做出相应的调整。反之, 则接受其输出信息的那些组件将会因此受到影响, 此时则需要就要重新对变更传播风险进行分析了。

第三, 修改组件。如组件的修改只是针对自身的某些结构或功能进行调整, 并且不影响其它组件与其的接口, 那么软件的体系结构就不会在组成上出现变化。

总结:

需求变更管理 篇8

1 常用的需求变更控制流程

“需求管理”是C M M 2级的一个K P A (Key Process Area, 关键过程域) 。CMM2级中对”需求管理”的目的定义为:分配给软件的系统需求是受控的, 建立供软件工程和管理使用的需求基线;软件的计划, 产品和活动和系统需求是一致的

CMM对需求管理的建议可以归纳为三点:首先, 应该让有经验和有能力的人来做需求分析活动和需求管理活动;相关的人员应该接受培训。其次, 要对需求分析活动进行评审, 保证他们是可控制和管理的, 并且是软件需求是合适的。最后, 如果需求更改了, 必须对由此造成的其它软件计划, 工作产品等的更改必须加以规划, 识别, 评价;对这些更改要做风险评估;所以这些都需要文档化;并且传达给相关的人员并且一直跟踪这些变化。其中最后一点对需求变更控制提出了明确的要求。

鉴于以上要求, 很多公司和培训、咨询机构都设计了非常严密变更控制流程。

以本文作者所服务的通信行业软件公司 (以下简称“公司”) 为例, 为实施CMM管理体系, 将变更控制流程分为:变更请求、变更评审和分析、变更实施三大子过程。

在进行变更请求时, 需要提供 (预评估) 如下内容: (1) 需求变更内容的描述:变更类型 (增加/删除/修改) 、要求、对应的当前需求等; (2) 由此带来的对已有成果的影响 (设计、编码、测试等) ; (3) 对项目的影响 (项目进度的变化、资源需求的变化等) 。

为了表示对需求变更控制的重视, 公司特别强调了“需求变更评审”的重要性, 要求评审应该由项目经理组织, 高级经理 (项目经理的管理者) 、产品经理、市场 (代表客户) 、质量代表 (代表质量部和流程改进组) 、研发人员、需求管理员等各种角色应该参与到评审过程中, 并对变更负责。

分析公司制定的需求变更控制流程, 以及咨询公司的改进建议等, 给人形成了一种很不好的感觉, 那就是“变更是不好的, 所以应该严格控制变更”。而事实上, 在软件定义阶段, 由于客户对产品往往还不能形成一个完整的印象, 需求不明几乎是所有项目的共同起点。在需求变更时, 客户也不会很好的对变更带来的影响做详细评估, 而是简单的提出要求, 并且要求实时响应。而对于小型软件公司来说, 如果僵化的坚持“需求及其变更必须明确后再开始项目”, 就无法体现小公司灵活, 快速的特点, 在业界根本就无存活的可能。

公司制定的整个流程看起来完美无缺, 非常符合C M M审核的要求, 但是在执行中, 却遇到了以下问题:对于变更申请时必须填报的变更申请表, 客户及其接口都觉得内容过于繁复, 不愿意配合填报。客户更希望提出需求, 并得到响应。由于要求需求变更必须得到高级经理, 项目经理, 公司产品部, 客户, 需求管理人员等各方人员的认可, 并且在进行了深入评估后才能实施变更。因此, 任何变更都不可能实时实施, 实际执行结果是客户不能接受此过程, 认为公司效率低下, 给公司管理层和开发人员造成了很大压力。由于流程未遵循闭环管理原则, 因此, 一些需求公司已经实施, 但是未能及时反馈到需求提出者, 客户感觉需求未得到响应, 降低了客户感受。总之, 从根本上来说, 每个公司实施质量管理体系的目的都是为了更好的满足用户, 因此, 一个不能让客户满意的流程肯定不能说是一个好的管理流程。

2 简化的需求变更控制流程

2.1 流程设计原则

我们回头来看C M M的要求, 其关键是识别变更、评估变更、文档化变更、跟踪变更。要求这些并非一定要由客户来完成, 或者说公司级别来完成。CMM对评审的要求准则是应评审需求的变更, 而对评审的目的, 则可以遵循对需求管理的目的:在顾客和软件项目之间建立对顾客需求的共同理解。而对评审的方式, 参与人员并无机械的要求。

遵照以上要求, 本文提出了一种简化的需求变更控制流程。在小型软件企业中, 可以在如下几个方面来简化变更控制: (1) 简化变更请求。客户只要提出变更的要求, 变更的分析交由公司内部完成。 (2) 变更的权利交由项目级别决定。 (3) 改变变更评审为变更上报和跟踪。项目经理可以根据客户需求, 首先在项目层面实施变更, 但是, 项目经理必须对变更可能的影响等及时通知给高级经理、产品经理、公司级需求管理人员和客户。 (4) 在变更申请人、需求跟踪人员和项目经理发生变更冲突或者以上人员认为必要时, 再启动公司级别的变更控制评审。

2.2 简化需求变更控制流程

图1给出了简化后的需求管理流程。

[活动1-1]的负责人为需求提出者。

任何人都可以提出需求。即新的需求或者需求变更可以来源于和客户直接交流的市场人员, 产品人员, 客服服务人员, 也可以来源于研发者。客户交流的邮件、会议纪要等文件可以作为需求变更申请的附件。

[活动2-1]需求变更确认

活动2的负责人为项目经理, 活动2的实施者则包括含项目经理在内的所有项目组成员。

项目经理根据需求变更申请中的中描述的内容, 考虑其影响程度, 自行、召集项目成员, 或者将需求提交RRM进行需求变更的评审, 针对需求变更申请中的相关描述, 以及参考产品, 市场, 以及对相关组的影响等各方面的综合因素, 确认是否需进行修改, 修改人, 验证变更人, 修改方案等内容, 并及时跟踪将此信息。

项目经理是负责督促实施需求的人, 因此, 其有责任去了解需求, 分析需求, 以确保需求的清晰明确。

[活动2-2]需求设计和实现

[活动2-3]需求测试

以上可统称为需求实施活动。活动2中的需求实施活动和普通研发活动并无特别之处, 这里不做详述。

在活动2的描述中, 还提到了一个非常设的机构RRM (RequirementReview Meeting) 来处理异常流程和争端。作为流程的规定, 以下条件可促发RRM。

1) 未处理的新需求或者需求变更超过门限值。

2) 两次RRM的时间间隔超过门限值;

3) 需求提出者和项目经理对“不合理”“不合格”存在异议时, 或者其他项目经理、需求管理、项目负责部门、产品市场部等需求干系人觉得存在重大需求, 在项目级别不能达成解决, 或者一致意见而需要公司级别集体讨论时。

以上任何一个条件符合, 项目经理将组织RRM, 就项目遗留的需求进行讨论, 并给出结论。

管理好需求变更, 才能管理好项目。需求变更是不可避免的, 只要项目存在一日, 变更便会随时产生, 逃避变更、排斥变更都不能改变需求变更的事实。本文遵循CMM要求, 提出了一种需求变更控制方法。本文设计的方法主要应用于小型软件项目, 当然管理一个小型软件项目, 除了流程和工具的支持, 更重要的是项目管理者, 参与者, 支持者都应该在需求管理过程中多沟通, 勤实践, 并能积极借鉴业界管理体系的有益指导意见, 唯有如此, 才能更好的完成客户需求, 提高客户满意度。

参考文献

[1]SEI, Key Practices of the Capability Maturity ModelSM, Version1.1, 1993.

[2]中国标准研究中心.ISO9001:2000标准, 2000.