软件需求工程 高校教学平台 需求变更控制会规程

点击查看 软件需求工程 高校教学平台 卷首语

概述

目的

需求的变更的原因可能会来自市场、管理、客户、软硬件工程环境和测试等方面，对于这些变更来说，如果不控制或者控制不好就会导致项目陷入混乱、不能按进度执行或软件质量低下等一系列的问题。对于需求的变更既不能一概拒绝客户的要求，也不能一味地迁就客户，所以实施需求变更之前必须做好管理和控制。

需求变更控制是指正确判断内在或外在原因的变更所带来的影响，并且调整开发过程以控制和适应这些变化，是需求管理的主要工作之一。

需求变更控制的目的不是控制变更的发生，而是对变更进行管理，确保变更有序地进行。变更控制给项目风险承担者提供了正式的需求变更处理机制，通过这些处理机制，决策人就可以准确地分析需求变更给整个项目所带来的影响和波动，从而对需求变更进行判断以决定是否接受、拒绝或者延迟，最终确保项目开发范围可控。

本计划书规定了需求变更时软件开发小组的工作规范与流程，能有效保证变更的需求得到及时的补充与完善，保证软件质量的同时兼顾用户需求变更。

范围

软件工程管理和软件需求工程在线课程系统项目开发过程中所有软件需求的文档及软件本身的变更。

参考文献

• Early Approach to Software Engineering, Pallavi Gore, Kritika Saxena.

• Practical File of Software Engineering and Testing Laboratory, Aakash Raj.

• Software Engineering, Principles and Practice, 3rd Edition, Hans van Vliet.

• Program Manager’s Guidebook for Software Assurance, Dr. Kenneth E. Nidiffer,
  Timothy A. Chick, Dr. Carol Woody.

• Experimentation in Software Engineering, Claes Wohlin, Per Runeson, Martin
  Host, Magnus C. Ohlsson, Bjorn Regnell, Anders Wesslen.

• IEEE Computer Society/Software Engineering Institute Software Process
  Achievement (SPA) Award 2009, Satyendra Kumar, Ramakrishnan M.

• Michael Felderer, Wilhelm Hasselbring, Rick Rabiser, Reiner Jung: Software
  Engineering 2020, Fachtagung des GI-Fachbereichs Softwaretechnik, 24.-28.
  Februar 2020, Innsbruck, Austria. LNI P-300, Gesellschaft für Informatik
  e.V. 2020, ISBN 978-3-88579-694-7.

• Regina Hebig, Robert Heinrich: Combined Proceedings of the Workshops at
  Software Engineering 2020 Co-located with the German Software Engineering
  Conference 2020 (SE 2020), Innsbruck, Österreich, March 05, 2020. CEUR
  Workshop Proceedings 2581, CEUR-WS.org 2020.

• Steffen Becker, Ivan Bogicevic, Georg Herzwurm, Stefan Wagner: Software
  Engineering and Software Management, SE/SWM 2019, Stuttgart, Germany,
  February 18-22, 2019. LNI P-292, GI 2019, ISBN 978-3-88579-686-2.

• Stephan Krusche, Kurt Schneider, Marco Kuhrmann, Robert Heinrich, Reiner
  Jung, Marco Konersmann, Eric Schmieders, Steffen Helke, Ina Schaefer,
  Andreas Vogelsang, Björn Annighöfer, Andreas Schweiger, Marina Reich, André
  van Hoorn: Proceedings of the Workshops of the Software Engineering
  Conference 2019, Stuttgart, Germany, February 19, 2019. CEUR Workshop
  Proceedings 2308, CEUR-WS.org 2019.

• Peter Liggesmeyer, Gregor Engels, Jürgen Münch, Jörg Dörr, Norman Riegel:
  Software Engineering 2009: Fachtagung des GI-Fachbereichs Softwaretechnik
  02.-06.03. 2009 in Kaiserslautern. LNI P-143, GI 2009, ISBN
  978-3-88579-237-6.

• Jürgen Münch, Peter Liggesmeyer: Software Engineering 2009 - Workshopband,
  Fachtagung des GI-Fachbereichs Softwaretechnik 02.-06.03.2009 in
  Kaiserslautern. LNI P-150, GI 2009, ISBN 978-3-88579-244-4.

• 《软件工程——实践者的研究方法》，Roger S.Pressman，机械工业出版社

• 《软件需求（第三版）》，Karl Wiegers，Joy Beatty，清华大学出版社

• 《计算机软件产品开发文件编制指南》（GB 8567-88）

• Information Technology Project Management, Second Edition, Kathy Schwalbe,
  Course Technology.

• Successful Project Management, Gido, J. and Clements, J. South-Western
  Publishing.

• On Time and Within Budget: Software Project Management Practices and
  Techniques, 3rd Edition, Bennatan, E., Wiley.

• Software Project Management: A Unified Framework, Walker Royce,
  Addison-Wesley.

• IS Project Management Handbook, Doss, G., Prentice Hall.

• CMMI: Guidelines for Process Integration and Product ImprovementMary Beth
  Chrissis, Mike Konrad, Sandy Shrum.

• CMMI® Distilled: A Practical Introduction to Integrated Process Improvement,
  Second Edition, By Dennis M. Ahern, Aaron Clouse, Richard Turner.

• CMMI® SCAMPI Distilled Appraisals for Process Improvement, By Dennis M.
  Ahern, Jim Armstrong, Aaron Clouse, Jack R. Ferguson, Will Hayes, Kenneth E.
  Nidiffer.

• 军用软件能力成熟度模型可重复级实施指南，石柱，中国标准出版社

• 战略管理(原书第6版)，Greey Johnson & Kevan Scholes，王军等译，人民邮电出版社

• 复杂产品系统创新管理，陈劲，科学出版社

• Product Management，4thedition，Donald R. Lehmann & Russell S.
  Winer，McGraw-Hill Companies，Inc.

• 基于ITIL®的IT服务管理基础篇，Jan van Bon，章斌译，清华大学出版社

• 创新管理-获取持续竞争优势，宁钟，机械工业出版社

• 软件编档导论，金波，清华大学出版社

• 计算机软件工程规范国家标准汇编，中国标准出版社

• 《“软件需求工程”教学安排 20200926》

• 《[G25]“高校教学平台”项目可行性报告》

• 《[G25]“高校教学平台”项目章程》

• 《[G25]“高校教学平台”项目计划》

• 《[G25]“高校教学平台”需求工程计划》

• 《[G25]“高校教学平台”前景与范围》

• 《[G25]“高校教学平台”质量保证计划》

• 《[G25]“高校教学平台”软件需求规格说明书》

角色与职责

角色分配与职责

表2-1 项目角色分配与对应职责

角色	职责	人员分配
CCB主席	变更控制委员会主席 如果CCB 意见不一致，一般情况下主席有最终的决策权；为每一个变更请求选定评估者和修改者。	xxx
CCB	负责评估 那些被提交上来的变更请求，针对这些变更的目的、要求和影响来决策：同意实施一项变更请求，并且在会议上安排相关的变更实施负责人，和相关联的协作组织；拒绝某一项变更请求，给出拒绝理由；制定项目的启动计划时就要建立项目CCB，它是在项目计划阶段建立的，将确定的CCB成员纪录到配置管理计划中，且发通知给项目组和相关组， 当基线正式建立或发生变更时，需召开CCB会议，并进行会议记录，会后形成《CCB会议纪要》放入项目配置库，并把会议结果发送给CCB成员及相关组。 变更评审 CCB收到变更请求后，会有专门人员（PM）先做一个初步分析，主要是评估变更来源、变更理由、变更影响、变更代价；某些变更会在这个阶段做出一些初步的处理，例如：表述不清楚地变更请求，打回给申请者补充信息；删除那些明显错误的变更请求；一些简单且影响小的变更（内部来源）可以直接分配人员处理；项目变更控制是一个动态过程，它开始于项目的变化，结束于变更验证。要对整个变更过程进行详细的纪录，以便于对项目进行总结。	xxx
评估者	应CCB 主席的要求，负责分析可能受提议的变更影响的人；可以是技术人员、客户、 市场人员或集这几个角色于一身者	xxx
修改者	负责在工作产品中实现变更的人，响应已批准的变更请求	xxx
提议者	新变更请求的提交者	xxx
请求接受者	接受提交的变更请求的人	xxx
验证者	确定变更是否已正确实现的人	xxx

各成员联系方式

表2-2 项目成员联系方式

姓名	角色	联系电话	电子邮件
邢卫	项目发起人	13958030163	wxing@zju.edu.cn
林海	项目发起人		lin@cad.zju.edu.cn
金波	项目发起人		jb21cn@zju.edu.cn
邵健	项目发起人	0571-87951277	jshao@cs.zju.edu.cn
博主本人	项目经理 设计总监 开发人员 测试人员	xxx	ZJU.SLM@gmail.com ZJU_SLM@studentambassadors.com
xxx	软件质量监督 开发人员 测试人员	xxx	xxx
xxx	设计总监 美工 开发人员 测试人员	xxx	xxx
xxx	测试经理 开发人员 测试人员	xxx	xxx
xxx	质量经理 开发人员 测试人员	xxx	xxx
xxx	产品经理 开发人员 测试人员	xxx	xxx

决策制定

指定决策过程规定

1. 建立需求基线。需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后可以建立第一个需求基线。此后每次变更并经过评审后都要重新确定需求基准线。

2. CCB的组成结构为项目所涉及的多方人员，包括用户放和开发方的决策人员。

3. 需求变更需要先申请再评估，最后经过与变更大小相当级别的评审确认。

4. 不论是因为什么产生的变更，遇到了就要正确的、合理的分析、评估，给项目以正确的指导。如果项目前期进行了大量的调研、跟踪、分析、评审，并请客户尽早参与，许多变更是可以避免的。如果，技术框架设计的可扩展，程序设计的可扩容的话，当发生变更时也可以把变更对项目产生的影响控制到最小。

交流状态

CCB作出决策后，须指派专人对变更数据库中的变更请求状态进行更新，并将新的状态通过电子邮件等方式传达给变更的提议者以及受此变更影响的其他人员。

重新协商原先约定

当发生变更时，正规的流程需要走变更申请，申请后组织人员对变更进行分析、评审，以判断变更是否必要，对项目的影响有多大。又必要又紧急的需求要排到开发计划中，尽快安排开发；对必要不紧急的需求要考虑是否可以放到下一版本安排开发；对紧急不必要的需求，要根据项目实际情况考虑，是否可以不要？对不紧急也不必要的需求应该直接砍掉，无须变更。评审完成后，对于需要安排开发的变更需求，先整理变更需求说明书，以帮助开发人员、测试人员了解变更内容，指导技术人员开发。

变更请求状态

图4-1 变更请求状态

开始条件

需求变更提出人填写书面变更申请——《需求变更申请书》，并将申请书发送至项目经理。

表5-1 需求变更申请书

需求变更申请书
项目名称		版本号
申请组织		申请人		申请日期
变更原因：
变更需求详细描述：
需求变更违约责任：
拟追加经费		拟追加工作量		项目组成员变动
用户意见
项目负责人意见	签字：

任务计划

评估请求

变更控制委员会（CCB）填写《需求评估报告》

表6-1 需求评估报告

需求评估报告
评估内容	描述	备注
预算成本评估
负责程度评估
主要风险评估	主要风险
	假定条件
	制约因素
工作量评估	WBS分解
	产品规模估计
	工作量评估
其他因素评估
评估结果
项目经理意见
签字：

做出决策

对于每一个被批准的变更请求，变更控制委员会（CCB）的成员都应当对其确立一个优先级，并根据实际开发进度确定可行的最终实现日期，该日期的选取可以服从某一特定的工作版本或发布版本的发行日期，并在该版本中实现此变更。

执行变更

在变更请求通过批准后，修改者与开发者将针对变更后的需求开展下一步的工作，并及时在全局更新当前的变更状态，以供需求和开发的管理工作，并便于组内成员查看和跟踪进度。

通知受变更影响的各方

变更控制委员会（CCB）在做出针对需求变更的决策后，将更新变更请求的状态并通知所有工作产品受到影响，并且有可能参与到后续修改工作的所有团队成员。

受到影响的工作产品包括需求文档、项目章程与计划文档、产品设计描述、产品基础架构以及前期完成的模型、用户界面相关组件等方面。

验证

验证变更

团队当中的所有成员对于需求变更进行验证，在确认变更被全体成员知晓的同时，确保了修改后的规格说明、设计计划、用例和模型能够正确地反映和覆盖到变更的各方面。

此外，团队通过追踪受变更影响的跟踪性信息，找出产品系统中因受此变更影响而必须进行再次验证的各个部分。对于下游工作产品的变更，还需由各小组成员通过测试或评审来进行验证。

安装产品

当变更验证完成后，修改者上线并安装更新后的产品以便于团队所有成员获取，并重新定义基线从而反映这一变更的验证。

结束状态

• 变更请求的当前状态为“已否决”、“已取消”或“已结束”。

• 所有完成修改的工作产品都已经安装到系统中合适的位置。

• 变更的细节和变更请求的当前状态已经通知了提议者、变更控制委员会（CCB）主席、项目经理以及其他与变更相关的项目参与者。

• 完成需求的跟踪矩阵的全部更新。

变更控制状态报告

确定用于总结变更控制数据库内容的相关图表、变更细则和报告模版。

模版以时间作为变化量，通过时间的推移表现出不同阶段变更请求的状态和数量的变化，从而使项目经理可以根据这些报告来跟踪项目的状态。

附录

变更请求数据项

表10-1 变更请求数据项

角色	职责
变更的来源	请求变更的职能域，可能包括的小组有市场部、管理层、软件工程部、测试部等职能部门
ID	分配给每个请求的标识标签或序列号
变更类型	变更类型变更请求的类型，例如需求变更、提议的增强或缺陷报告
提交日期	提议者提交变更请求的日期
更新日期	最近修改变更请求的日期
描述	用自由格式的文本描述正在请求的变更
实现的优先级	CCB 赋予每个变更的相对重要性，例如低、中和高
修改者	实现这一变更的主要负责人姓名
提议者	提交这一变更请求的人名，注意包括此人的联系方式
提议者设置的优先级	提议者赋予每个变更的相对重要性，例如：低、中和高
实现版本	计划实现已批准变更的产品版本或工作版本号
项目	要求变更的项目名称
响应文本	对变更请求做出响应的自由格式的响应文本，随着时间的推移可以有多个响应文本，产生了新的响应文本后不要修改旧的响应文本
状态	变更请求的当前状态，具体这些状态选项参照文章第三章
标题	对已提议变更的一行概要介绍
验证者	负责确定变更是否已正确实现的人员姓名
变更的来源	请求变更的职能域，可能包括的小组有市场部、管理层、软件工程部、测试部等职能部门