您的当前位置:首页正文

软件开发项目需求变更管理及应对之

2020-07-04 来源:步旅网
软件开发项目需求更改管理及应付之

软件开发工程需求更改经管及应付之道研究

变化其实不是人们最惧怕的,最怕的是跟不上变化的步伐。相同,在软件开发过程中需求的更改会给开发带来不确立性,但只需把需求更改作为要点、难点当心加以控制,软件开发的进度、成本和质量也就有了 \" 安全 \" 的基础。

需求更改经管的需求

需求更改是因为需求发生变化。依据软件工程思想,需求说明书一般要经过论证,假如在需求说明书经过论证此后,需要在原有需求基础上追加和增补新的需求或对原有需求进行改正和减少,均属于需求更改。

需求更改的出现主假如因为在工程的需求确立阶段,用户常常不可以切实地定义自己需要什么。用户经常认为自己清楚,但实质上他们提出的需求不过依照目前的工作所需,而采纳的新设施、新技术往常会改变他们的工作方式。或许要开发的系统对用户来说也是个未知数,他们从前没有过有关的使用经验。

跟着开发工作的不停进展, 系统开始显现功能的雏形,用户对系统的认识也逐渐深入。于是,他们可能会想

1 / 6

软件开发项目需求更改管理及应付之

到各样新的功能和特点,或对从前提出的要求进行变动。他们认识得越多,新的要求也就越多,需求更改所以不行防止地一次又一次出现。

这时,假如开发团队缺乏明确的需求更改控制过程或采纳的更改控制体制无效,抑或不按更改控制流程来经管需求更改,那么很可能造成工程进度迟延、成本不足、人力紧缺,甚至致使整个工程失败。自然,即便依照需求更改控制流程进行经管,因为受进度、成本等要素的限制,软件质量仍是会遇到不一样程度的影响。但实行严格的软件需求经管会最大限度地控制需求更改给软件质量造成的负面影响,这也正是我们进行需求更改经管的目的所在。

六大原则

实行需求更改经管需要依照以下原则:

1. 成立需求基线。需求基线是需求更改的依照。在开发过程中,需求确立并经过评审后 ( 用户参加评审 ) 个需求基线。今后每次更改并经过评审后,都要从头确立新的需求基线。

2 / 6

,能够成立第一

软件开发项目需求更改管理及应付之

2. 制定简单、有效的更改控制流程,并形成文档。在成立了需求基线后提出的全部更改都一定依照这个控制流程进行控制。

同时,这个流程拥有必定的广泛性,对此后的工程开发和其余工程都有借鉴作用。

3. 成立工程更改控制委员会 (CCB) 或有关职能的近似组织,负责裁定接受哪些更改。 CCB 由工程所波及的多方人员共同构

成,应当包含用户方和开发方的决议人员在内。

4. 需求更改必定要先申请而后再评估,最后经过与更改大小相当级其余评审确认。

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

6. 妥当保留更改产生的有关文档。

应付之道

需求更改控制一般要经过更改申请、 更改评估、决议、答复这四大步骤。假如更改被接受,还要增添实行变

更和考证两个步骤,有时还会有撤消更改的步骤。更改控制流程以下图。针对更改控制流程,笔者在实

3 / 6

软件开发项目需求更改管理及应付之

际工作中概括总结出了软件开发人员在需求更改经管实践中的几点对策:

互相协作 很难想像遇到用户抵制的工程能够成功。在议论需求时,开发人员与用户应当尽量采纳互相理解、互相协作的态度,对能解决的问题尽量解决。即便用户提出了在开发人员看来 \" 过分 \" 的要求,也应当认真剖析原由,踊跃提出可行的代替技术方案。

充足交流 需求更改经管的过程很大程度上就是用户与开发人员的交流过程。软件开发人员一定学会认真听取用户的要求、考虑和假想,并加以剖析和整理。同时,软件开发人员应当向用户说明,进入设计阶段此后,再提出需求更改会给整个开发工作带来什么样的冲击和不良结果。

安排专职人员负责需求更改经管 有时开发任务较重,开发人员简单堕入开发工作中而忽视了与用户的随时交流,所以需要一名专职的需求更改经管人员负责与用户实时交流。

合同拘束 需求更改给软件开发带来的影响众所周知,所以在与用户签署合同时,能够增添一些有关条

4 / 6

软件开发项目需求更改管理及应付之

款,如限制用户提出需求更改的时间,规定何种状况的更改能够接受、拒绝接受或部分接受,还能够规定发生需求更改时一定履行更改控制流程。

差别对待 跟着开发进展,有些用户会不停提出一些在工程组看来的确没法实现或工作量比较大、对工程进度有重要影响的需求。碰到这类状况,开发人员能够向用户说明,工程的启动是以最先的基本需求作为开发前提的,假如大批增添新的需求 ( 固然用户认为是细化需求,但其实是增添了工作量的新需求 ) ,会使工程不可以准时达成。假如用户坚持实行新需求,能够建议用户将新需求按重要和紧急程度区分品位,作为需求更改评估的一项依照。同时,还要注意控制新需求提出的频次。

采纳合适的开发模型 采纳成立原型的开发模型比较合适需求不明确的开发工程。开发人员先依据用户对需求的说明成立一个系统原型,再与用户交流。一般用户看到一些实质的东西后,对需求会有更加详尽的解说,开发人员可依据用户的说明进一步完美系统原型。这个过程重复几次后,系统原型渐渐向最后的用户需求聚拢,从根本上减少需求更改的出现。目前业

5 / 6

软件开发项目需求更改管理及应付之

界较为流行的叠代式开发方法对工期紧急的工程的需求更改控制很有收效。

用户参加需求评审 作为需求的提出者,用户理所自然是最具威望的讲话人之一。实质上,在需求评审过程中,用户常常能提出很多有价值的建议。同时,这也是由用户对需求进行最后确认的时机,能够有效减少需求更改的发生。

6 / 6

因篇幅问题不能全部显示,请点此查看更多更全内容