- 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
- 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
软件需求变更处理流程
1、需求变更的原因分析
需求变更的表现形式是多方面的,如老板临时改变想法、项目预算增加或减少、客户对功能的需求改变等。在IT项目中,变更可能来自方案服务商、客户或产品供应商等,也可能来源于项目组内部。虽然需求变更的表现形式千差万别,但究其根本不外乎以下几种原因:
(1)、范围没有圈定就开始细化
细化工作是由需求分析人员完成的,一般是根据用户提出的描述性的、总结性的短短几句话去细化的,提取其中的一个个功能,并给出描述(正常执行时的描述和意外发生时的描述)。当细化到一定程度后并开始系统设计时,范围会发生变化,那细节用例的描述可能就有很多要改动。如原来是手工添人的数据,要改成根据信息系统计算出来,而原来的一个属性的描述要变成描述一个实体等。
(2)、没有指定需求的基线
需求的基线是指是否容许需求变更的分界线。随着项目的进展,需求的基线也在变化。是否容许变更的依据是合同以及对成本的影响,比如软件整体结构已经设计出来是不容许改变需求范围的,因为整体结构会对整个项目的进度和成本有初步预算。随着项目的进展,基线将越定越高(容许的变更将越少),其过程如下:变更请求à比较基线à变更实现。
(3)、没有良好的软件结构适应变化
组件式的软件结构就是提供了快速适应需求变化的体系结构,数据层封装了数据访间逻辑,业务层封装了业务逻辑,表示层展现用户表示逻辑。但适应变化必须遵循一些松祸合原则,各层之间还是存在一些联系的,设计要力求减少会对接口入口参数产生变化。如果业务逻辑封装好了,则表示层界面上的一些排列或减少信息的要求是很容易适应的。如果接口定义得合理,那么即使业务流程有变化,也能够快速适应变化。因此,在成本影响的容许范围内可以降低需求的基线,提高客户的满意度。
2、如何控制需求变更
按照现代项目管理的概念,一个项目的生命周期分为启动、实施、收尾三个过程。需求变更的控制不应该只是项目实施过程考虑的事情,而是要分布在整个项目生命周期的全过程。为了将项目变更的影响降低到最小,就需要采用综合变更控制方法。综合变更控制主要内容有找出影响项目变更的因素、判断项目变更范围是否已经发生等。
进行综合变更控制的主要依据是项目计划、变更请求和提供了项目执行状况信息的绩效报告。为保证项目变更的规范和有效实施,通常项目实施组织会有一
(1)、项目启动阶段的变更预防
对于任何项目,变更都无可避免,也无从逃避,只能积极应对,这个应对应该是从项目启动的需求分析阶段就开始了。对一个需求分析做得很好的项目来说,基准文件定义的范围越详细清晰,用户跟项目经理扯皮的幌子就越少。如果需求没做好,基准文件里的范围含糊不清,被客户抓住空子,往往要付出许多无谓的牺牲。如果需求做得好,文档清晰且又有客户签字,那么后期客户提出的变更就超出了合同范围,需要另外收费。这个时候千万不能手软,这并非要刻意赚取客户的钱财,而是不能让客户养成经常变更的习惯,否则后患无穷。相对于需求来说,什么WBS、风险管理、计划进度都是次要的,只要需求做好了就会一帆风顺。
(2)、项目实施阶段的需求变更
成功项目和失败项目的区别就在于项目的整个过程是否是可控的。项目经理应该树立一个理念——“需求变更是必然的、可控的、有益的”。项目实施阶段的变更控制需要做的是分析变更请求,评估变更可能带来的风险和修改基准文件。控制需求渐变需要注意以下几点:
需求一定要与投入有联系,如果需求变更的成本由开发方来承担,则项目需求的变更就成为必然了。
如何做好需求变更管理?——需求变更流程规范
流程说明:
需求来源:客户提交相关需求变更
审核需求变更:评估如果实现该需求,需要的时间、人力成本多少;并评估对项目工期影响有多大?判断那些需求能够目前解决,那些需要留到下一版本解决。最后输出一份审核确认表反馈给客户,和客户进行商讨。参与评审的人员要包含项目经理,项目组长,测试组长,市场人员。
配置管理员:对变更需求进行记录,需求文档进行更新,并通知相关人员
项目组长:负责调整相关开发进度表,评估任务时间,分发给相关开发人员
测试组长:根据变更需求和开发进度,对测试进度进行相对应调整,并修改测试需求分析书,分发需求更新给相关测试人员。测试人员对用例进行补充,修改。
客户提交的变更需求最后必须让客户进行签字确认。
2、需求变更流程(内部提出需求变更)
1)执行条件:
对项目进度不会影响严重
与客户原始需求无偏差
图:需求变更流程(内部提出需求变更)
2)流程说明:
内部需求变更来源:公司内部人员发现逻辑,需求上的问题,或功能上的建议以及开发、测试人员提出的需求不一致内容。
需求变更类型:需求有误、需求有遗漏、需求不明确。
需求变更审核:内部提交的需求应该经过项目经理,项
文档评论(0)