• RSS订阅 加入收藏  设为首页
软件需求评估

软件需求变更量化评价方法

时间:2015-11-7 8:42:07  作者:曹济  来源:原创  查看:672  评论:0
内容摘要:针对IT项目的需求管理,IT项目的需求变更管理问题更为突出,例如没有提交书面的需求变更申请表、对于需求变更申请的评价过于笼统或单一、需求变更没有起到应有的约束作用等。要提高需求变更管理流程的有效性,应该仍然基于细化、量化的思路对于需求变更管理内容首先细化,然后对细化后的内容再进行量化评价,最后变更控制委员会做出公平合理的决策。

针对IT项目的需求管理,IT项目的需求变更管理问题更为突出,例如没有提交书面的需求变更申请表、对于需求变更申请的评价过于笼统或单一、需求变更没有起到应有的约束作用等。要提高需求变更管理流程的有效性,应该仍然基于细化、量化的思路对于需求变更管理内容首先细化,然后对细化后的内容再进行量化评价,最后变更控制委员会做出公平合理的决策。下面介绍的需求变更管理七步法就是遵循细化、量化的管理思路一个具体示例。

为了理解方便,首先介绍在需求变更管理过程中使用的变更申请表,如下表所示。该表主要由表头和七部分内容组成,记录了和需求变更管理相关的项目信息,以及变更申请、影响分析和CCB批准相关的信息。需求变更管理后续的步骤,包括更新WBSWBS监控和变更结束与项目中正常进行的任务管理采取相同的管理模式,此处不再详述。

下面结合表对于需求变更管理的操作细节以及量化评价方法进行介绍,为了容易记忆和形象起见,笔者特意将这种需求变更管理方法命名“需求变更七步法”,与需求变更管理申请表中的七部分内容相对应。

 IT项目需求变更申请表

项目名称:                   变更申请编号:                     

子系统名称:                  要求完成日期:            

有无附件:会议纪要 业务需求   其它       

阶段:    需求     设计       编码  测试

变更类型:需求     设计    

变更申请人:               申请人所属部门及职位:                       

变更申请日期:               

1.1 变更内容描述:

1.2 变更规模评价(功能点数量)

1.3 变更类型选择

新增功能

修改原有功能

删除现有功能

1.4业务变更必要性评价:

必须修改

强烈建议修改

最好修改

可改可不改

1.5 结合所选择的业务变更必要性评价级别,具体陈述修改对业务可能产生的正面影响

 

 

1.6 结合所选择的业务变更必要性评价级别,具体陈述如果不能实施建议的修改对业务可能产生的负面影响

2.1 技术评审      技术可行性评审意见  可行     不可行

2.2 技术实施方案简单描述(可选):

 

3. 变更对进度的影响(天)

3.1 列出实施需求变更所需额外的活动及其对应的预估时间(天数)

3.2 变更导致项目额外活动的工期总和(天数)

3.3 如有活动位于关键路径上,描述变更对于关键路径的影响(天数)

4. 变更对成本的影响 (元)

4.1 项目组需要额外的人员数目

4.2 直接人力成本(人时)

4.3 人时工资率(元)

4.4 人力成本分摊系数(一般介于2~3

4.5 费用合计(元)

5.1 变更对质量的影响级别

质量严重下降,系统不稳定等,出现致命问题

质量明显下降,功能使用受到影响或者性能明显下降,出现重要问题

质量可能下降,对功能和性能有一定影响,可能出现质量问题

5.2 变更可能造成的质量问题的具体描述

质量问题1

质量问题2

质量问题3

5.3 变更导致受影响的需求百分比例:

  变更导致的需求缺陷个数:

5.4 变更导致受影响的设计百分比例:

  变更导致的设计缺陷个数:

5.5 变更导致受影响的代码百分比例:

  变更导致的代码缺陷个数:

5.6 变更导致受影响的测试用例百分比例:

   变更导致的测试缺陷个数:

5.7 变更导致的试运行阶段缺陷个数:

6.1变更引起的风险级别

高级别风险

中等级别风险

低级别风险

6.2 风险的具体描述以及可能造成的负面后果

风险1

风险2

风险3

7.1  CCB对变更的意见

     接受      不同意  搁置     

7.2  意见补充:                       

7.3  签字

 CCB组长签字: 

                          CCB成员签字: 

                          CCB成员签字:

                          CCB成员签字:

                          CCB成员签字:

                              日期:            

下面针对上表中的七个部分进行描述,其中每个部分与下列的每个步骤相对应。

步骤一

为了有效管理需求变更,防止出现需求蔓延情形,所以在IT项目管理中一定要强调执行严格的需求变更管理流程。而最能体现需求变更管理流程的文档就是需求变更申请表了,故而在需求变更申请表中完整地反映了需求变更七步法每个步骤的要求。对于每次提交的需求变更申请,应该首先完成该表的表头,即与该需求变更申请相关的项目基本信息,以便为后续的需求变更管理工作提供参考信息。

步骤一中最主要的内容是度量变更需求的规模。需求规模是确定项目工期、成本、质量等关键管理指标的基础指标,所以首先要评价出改变的需求有“多大”,然后才能进行相应的后续评价。笔者建议在实际操作中最好用功能点度量需求规模,这样可以对历史的变更需求进行汇总分析。当然也可以使用模块数量等度量单位,但这些需求规模和工期、成本的关联性就不如功能点相对客观和透明。

除了要衡量变更需求的规模,还有一项重要内容是说明需求变更对于业务的必要性,对于那些可变可不变的需求最好不要改变,因为IT系统的质量通常越改越差,越改越不稳定。所以在评价需求变更必要性时采用定性评价的方式,确定需求修改的必要性,同时还应结合具体的需求修改对业务的正面影响和负面影响进行分析,从业务方面综合判断需求修改的必要性。

步骤二

IT项目的技术方在接收到客户的需求变更申请后,首先判断第一步所要求填写的内容是否完备,然后要对客户提交的变更申请进行技术可行性分析,即能否实现客户所提交需求变更。鉴于IT项目技术路线的多样性,一般的客户需求都能够实现。但涉及到非功能性需求变更则需要进行详细的技术方案分析,例如对于可靠性、响应速度等方面的要求,有时在现有的技术框架之内是实现不了的。对于那些实现难度比较大、风险比较高的需求变更,应该在本步骤进行说明,以便供CCB在决策时参考。

步骤三

工期作为IT项目的一个关键管理目标,需要始终给予高度关注。如果IT项目的需求变更通过了前两个步骤,则接下来就应该对于变更需求对项目工期的影响进行综合评价。有些需求看起来只是增加或修改单个需求功能,但是它可能会引起一系列相关需求功能的修改,例如修改电信计费系统的计价模式,将原有的根据流量计价模式改为包月计价加流量计价混合模式则会引起一系列的功能修改;有些在项目后期提出来的需求,例如在IT项目的系统测试阶段提出新的业务需求修改,此时不但要修改需求,还要修改设计、代码、测试用例、使用文档等一系列工作产品。

基于上述的分析,在评价需求变更对于工期可能的影响时,应首先识别需求变更会导致IT项目增加哪些额外的活动,并列出所有增加的活动并对每项活动的工期进行预估。在活动列表的基础上,还应该结合IT项目当前的进度网络图,识别新增活动对于项目关键路径的影响。对于那些位于项目关键路径上的额外活动应该给予更多的关注,确保需求变更活动对于IT项目工期的影响程度降至最低。

步骤四

IT项目需求变更还会直接增加项目成本,大部分项目的变更成本主要表现为人力成本,对于单纯的软件开发项目尤其如此。确定需求变更成本相对容易,以第一步骤中所给出的需求规模作为输入,然后根据组织的历史项目数据确定软件项目的生产率,即可得到需求变更所需的工作量。得到工作量之后再根据开发组织的人时工资率以及费用分摊系数得到开发组织的分摊人时工资率,将此工资率与前述的工作量相乘即可得到实现该次需求变更所需要的开发成本。

例如项目中需要额外增加大额订单统计功能以及VIP客户管理功能,根据功能点标准,这两个功能对应的功能可能分别是5个功能点(假定大额订单统计功能为平均复杂度)、24个功能点(假定VIP客户管理的数据功能为简单级别、增删改为简单级别、查询为简单级别、统计为平均级别,合计7+3*3+3+5=24),所以该次需求变更的规模为29个功能点;又假定该组织的软件项目生产率为0.5功能点/人天,所以实现该需求变更对应的额定工作量为58人天。假如开发组织的分摊人时工资率为836/人天(人员平均月工资为8000元,每周22工作日,费用分摊系数为2.3),则实现需求变更对应的费用即为48488元。

绝大部分IT开发组织在实际工作中并没有进行这种量化的成本评估,尤其没有将这种成本评估结果完全转换成钱数。这种做法可能给客户以错觉:许多客户认为软件需求变更可以不考虑额外成本,因为修改软件不过就是改改代码,没有什么工作量。这种情形下更需要IT开发组织自己主动“维权”,将每次需求变更的成本评估工作做到位。

步骤五

如果要比较需求变更对于项目工期、成本和质量的影响程度,那么质量无疑是受影响最长久的一个方面。如果因为需求变更导致项目出现明显的工期延误、成本超支、质量严重下降等情形,相比之下,需求变更对于工期和成本方面的影响只能算是“临时伤害”,而对于质量方面的影响则是“永久的痛”了。所以对需求变更可能引发的质量问题,尤其需要谨慎评估,避免出现“悔不当初”的情形。正是从保证IT系统的质量水平出发,IT开发组织通常尽可能避免对于系统进行反复修改。但有时如果不得不对系统进行修改(例如来自国家或行业政策法规的修改,导致系统的功能必须发生改变),那么也要在修改之前对质量影响进行尽可能全面的评估。对于质量影响的评价采用定性加定量预测的方式,首先根据主观经验判断当前修改可能对于质量影响的严重程度;然后基于组织的历史项目经验分别预报需求变更如何影响不同类型的质量活动的缺陷产出情况。

如果变更的需求是40个功能点,假定需求评审对应的缺陷密度为0.1缺陷/FP,那么需求评审发现的缺陷数量将增加4个;设计评审对应的缺陷密度为0.1缺陷/FP,那么设计评审将发现的缺陷数量额外增加4个;再假定组织在测试阶段的缺陷密度为0.4缺陷/FP,那么该需求变更将在测试阶段引发额外的16个缺陷;考虑IT系统进入试运行阶段后对应的缺陷密度是0.05/FP,那也就意味着本次需求变更将会在系统上线后引发额外的两个缺陷。

IT系统的质量问题往往具有较强的隐蔽性,所以通过上述的量化数据推断可以从统计意义说明缺陷数量的情况。在实际工作中分析质量影响时,还应该重点关注于5.2部分具体的质量问题描述,这样的具体分析更加有的放矢,需要的话应该预先采取相应的质量预防措施,具体措施可以包括取消当前的需求变更任务等。

步骤六

需求变更往往意味着追加功能,而追加功能则意味着更多的工作任务、更长的工期、更高的成本甚至更多的项目组成员,这一切都说明项目将面临更多的变数,也即我们常说的风险。对于风险应该预先进行识别,只有这样才可能提前采取防范或应对措施,从而化解危机。对风险的评价更多地基于项目经验,所以在确定风险的级别后,还应该重点描述变更可能带来的具体风险是什么,如何化解,如果不能化解,那么又应该如何去应对等。

例如异地开发的项目遇到需求变更后直接的后果是导致工期的延误;另一方面这种延误又会进一步加剧项目组成员“归心似箭”的心理,还会引起工作效率的下降,甚至会引起人员的流失。遇到这种风险要完全化解不太现实,所以项目经理(包括开发方的管理层)就需要开诚布公地与项目组成员说明项目所面临的情况,取得大家的信任,在此基础上再采取一些安抚措施,例如聚餐、短途郊游等集体活动,尽量降低这种风险对于项目的不利影响。

步骤七

在变更七步法中,第一步骤是由客户或业务部门所完成的,第二至第六步骤均由开发方或技术部门完成。第一步骤站在客户的角度,描述了“我要什么”;第二至第六步骤则站在开发的角度,描述了“你要承担的代价”。如何平衡甲乙双方各自的要求,就需要一个能同时代表双方利益的组织,这个组织就是变更控制委员会(Change Control Board)。变更委员会通常是由甲乙双方的代表组成,负责为需求变更做出决策。变更控制委员会主要权衡客户的变更要求和所承担的代价是否合理,类似一种讨价还价机制。

例如客户要变更的需求数量为29个功能点,技术实现没有明显风险,也不会造成明显的质量问题;可能导致工期延误两周;成本增加48488元。此时变更控制委员会就应该在变更业务的必要性、重要性与两周和48488元之间进行比较,这个变更值得吗?如果是,批准变更;如果完全不值得,拒绝变更;如果现在无法做出结论,可以暂时搁置,待时机成熟时再行决策。

所以第七步骤是在前述六个步骤的基础上权衡后作出的结论。至此,通过变更七步法就可以涵盖变更管理的主要内容。

阅读至此,读者认为可以直接采用变更管理七步法去管理IT项目的需求变更吗?笔者的答案是等待时机。等待我们的客户或业务人员能够主动认识到IT项目困境的主要原因就是需求变更不受控;等待他们克服“软件开发不需要什么成本”的认识;等待他们认识到予取予求不是一种可持续的合作模式等。等到这一天来临,采用变更管理七步法就是一个水到渠成的事情了。



标签:需求管理 需求跟踪 

csan.org.cn 版权所有 csan@csan.org.cn

京ICP备06052862号-2