软件项目需求变更六大原则及应对之道

软件项目需求变更六大原则及应对之道
软件项目需求变更六大原则及应对之道

软件项目需求变更六大原则及应对之道

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

需求变更管理的需求

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

需求变更的出现主要是因为在项目的需求确定阶段,用户往往不能确切地定义自己需要什么。用户常常以为自己清楚,但实际上他们提出的需求只是依据当前的工作所需,而采用的新设备、新技术通常会改变他们的工作方式;或者要开发的系统对用户来说也是个未知数,他们以前没有过相关的使用经验。随着开发工作的不断进展,系统开始展现功能的雏形,用户对系统的了解也逐步深入。

于是,他们可能会想到各种新的功能和特色,或对以前提出的要求进行改动。他们了解得越多,新的要求也就越多,需求变更因此不可避免地一次又一次出现。

这时,如果开发团队缺少明确的需求变更控制过程或采用的变更控制机制无效,抑或不按变更控制流程来管理需求变更,那么很可能造成项目进度拖延、成本不足、人力紧缺,甚至导致整个项目失败。

当然,即使按照需求变更控制流程进行管理,由于受进度、成本等因素的制约,软件质量还是会受到不同程度的影响。但实施严格的软件需求管理会最大限度地控制需求变更给软件质量造成的负面影响,这也正是我们进行需求变更管理的目的所在。

六大原则

实施需求变更管理需要遵循如下原则:

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

需求基线。

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

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

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

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

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

应对之道

需求变更控制一般要经过变更申请、变更评估、决策、回复这四大步骤。如果变更被接受,还要增加实施变更和验证两个步骤,有时还会有取消变更的步骤。变更控制流程如图所示。针对变更控制流程,笔者在实际工作中总结出了软件开发人员在需求变更管理实践中的几点对策:

相互协作很难想像遭到用户抵制的项目能够成功。在讨论需求时,开发人员与用户应该尽量采取相互理解、相互协作的态度,对能解决的问题尽量解决。即使用户提出了在开发人员看来"过分"的要求,也应该仔细分析原因,积极提出可行的替代方案。

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

安排专职人员负责需求变更管理有时开发任务较重,开发人员容易陷入开发工作中而忽略了与用户的随时沟通,因此需要一名专职的需求变更管理人员负责与用户及时交流。

合同约束需求变更给软件开发带来的影响有目共睹,所以在与用户签订合同时,可以增加一些相关条款,如限定用户提出需求变更的时间,规定何种情况的变更可以接受、拒绝接受或部分接受,还可以规定发生需求变更时必须执行变更控制流程。

区别对待随着开发进展,有些用户会不断提出一些在项目组看来确实无法实现或工作量比较大、对项目进度有重大影响的需求。遇到这种情况,开发人员可以向用户说明,项目的启动是以最初的基本需求作为开发前提的,如果大量增加新的需求(虽然用户认为是细化需求,但实际上是增加了工作量的新需求),会使项目不能按时完成。

如果用户坚持实施新需求,可以建议用户将新需求按重要和紧迫程度划分档次,作为需求变更评估的一项依据。同时,还要注意控制新需求提出的频率。

选用适当的开发模型采用建立原型的开发模型比较适合需求不明确的开发项目。开发人员先根据用户对需求的说明建立一个系统原型,再与用户沟通。一般用户看到一些实际的东西后,对需求会有更为详细的解释,开发人员可根据用户的说明进一步完善系统原型。

这个过程重复几次后,系统原型逐渐向最终的用户需求靠拢,从根本上减少需求变更的出现。目前业界较为流行的叠代式开发方法对工期紧迫的项目的需求变更控制很有成效。

用户参与需求评审作为需求的提出者,用户理所当然是最具权威的发言人之一。实际上,在需求评审过程中,用户往往能提出许多有价值的意见。同时,这也是由用户对需求进行最后确认的机会,可以有效减少需求变更的发生。

软件工程项目管理计划书(完整版)

储蓄业务项目管理计划书 1.简介 1.1 项目概述 本项目要开发一个银行系统,系统一共分为储蓄业务、贷款业务、外汇交易、网上银行、信用卡业务和系统管理六个子系统。本团队负责其中的有关储蓄业务的子系统。通过团队合作开发整个子系统,使团队成员获得软件工程开发的实际训练。本系统采用目前主流的B/S开发架构,将与整个银行系统一起发布。不单独发布。交付的产品包括可执行的文件、源代码、技术文档与用户使用手册等。本系统的开发过程中的主要工作是子系统需求分析、系统总体设计、子系统源代码开发、子系统测试、交付团长进行最后的集成、整个系统的测试。关键里程碑是制定项目管理计划书、制定需求设计规格说明书初稿、制定系统设计报告的初稿、进行子系统运行情况的检查与测试、进行系统集成后的运行情况的检查与测试。项目所需工具是个人电脑和开发工具。进度为11周,工程量为3人/天。 1.2 项目范围说明 (1)提交文档:项目管理计划、需求规格说明,设计报告、测试报告、用户使用手册和项目个人总结。其中项目总结为每人一份,每个小组所有成员的总结装订在一起;其余文档每组提交一份。每个团队可将各小组的文档综合到一起,各小组也可自行分开提交,具体方式由团队内部协商确定。所有文档需要提交电子版和打印稿。 (2)源程序检查:一共两次。第一次检查每个小组的子系统运行情况。第二次检查每个团队内六个小组集成后完整的银行系统运行情况,检查完成后需要提交程序源文件和可执行的系统。程序检查安排在上机时间进行。 1.3 软件项目计划书的演化 软件项目计划书在第三周周末前经由小组讨论、共同撰写、汇总整合三步骤形成初稿,第四周以后根据项目的进展可以对其进行修改,需要有组员提出修改意,在全体会上讨论通过,并由组长整理修改意见并作出相应的修改。其余组员同步获得更新稿。 2.项目组织管理 2.1 过程模型

需求变更的代价

需求变更的代价 让我们先来看一个需求变更的典型案例:Steven刚出任项目经理,并承接了一个中型软件项目。公司再三叮咛他一定要尊重客户,充分满足客户需求。项目开始比较顺利,但进入到后期,客户频繁的需求变更带来很多额外工作。Steven动员大家加班,保持了项目的正常进度,客户相当满意。但需求变更却越来越多。为了节省时间,客户的业务人员不再向Steven申请变更,而是直接找程序员商量。程序员疲于应付,往往直接改程序而不做任何记录,很多相关文档也忘记修改。很快Steven就发现:需求、设计和代码无法保持一致,甚至没有人能说清楚现在系统“到底改成什么样了”。版本管理也出现了混乱,很多人违反配置管理规定,直接在测试环境中修改和编译程序。但在进度压力下,他也只能佯装不知此事。但因频繁出现“改好的错误又重新出现”的问题,客户已经明确表示“失去了耐心”。而这还只是噩梦的开始。一个程序员未经许可擅自修改了核心模块,造成系统运行异常缓慢,大量应用程序超时退出。虽然最终花费了整整3天的时间解决了这个问题,但客户却投诉了,表示“无法容忍这种低下的项目管理水平”。更糟糕的是,因为担心系统中还隐含着其他类似的错误,客户高层对项目的质量也疑虑重重。随后发生的事情让Steven更加为难:客户的两个负责人对界面风格的看法不一致,并为此发生了激烈争执。Steven知道如果发表意见可能会得罪其中一方,于是保持了沉默。最终客户决 定调整所有界面,Steven只好立刻动员大家抓紧时间修改。可后来当听说因修 改界面而造成了项目一周的延误后,客户方原来发生争执的两人这次却非常一致,同时气愤地质问Steven:“为什么你不早点告诉我们要延期!早知这样才不会 让你改呢!”Steven很无耐,疑惑自己到底错在哪里了。对软件需求和需

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

软件开发工程需求变更经管及应对之道研究 变化并不是人们最害怕的,最怕的是跟不上变化的步伐。同样,在软件开发过程中需求的变更会给开发带来不确定性,但只要把需求变更作为重点、难点小心加以控制,软件开发的进度、成本和质量也就有了"安全"的基础。 需求变更经管的需求 需求变更是因为需求发生变化。根据软件工程思想,需求说明书一般要经过论证,如果在需求说明书经过论证以后,需要在原有需求基础上追加和补充新的需求或对原有需求进行修改和削减,均属于需求变更。 需求变更的出现主要是因为在工程的需求确定阶段,用户往往不能确切地定义自己需要什么。用户常常以为自己清楚,但实际上他们提出的需求只是依据当前的工作所需,而采用的新设备、新技术通常会改变他们的工作方式。或者要开发的系统对用户来说也是个未知数,他们以前没有过相关的使用经验。 随着开发工作的不断进展,系统开始展现功能的雏形,用户对系统的了解也逐步深入。于是,他们可能会想

到各种新的功能和特色,或对以前提出的要求进行改动。他们了解得越多,新的要求也就越多,需求变更因此不可避免地一次又一次出现。 这时,如果开发团队缺少明确的需求变更控制过程或采用的变更控制机制无效,抑或不按变更控制流程来经管需求变更,那么很可能造成工程进度拖延、成本不足、人力紧缺,甚至导致整个工程失败。当然,即使按照需求变更控制流程进行经管,由于受进度、成本等因素的制约,软件质量还是会受到不同程度的影响。但实施严格的软件需求经管会最大限度地控制需求变更给软件质量造成的负面影响,这也正是我们进行需求变更经管的目的所在。 六大原则 实施需求变更经管需要遵循如下原则: 1.建立需求基线。需求基线是需求变更的依据。在开发过程中,需求确定并经过评审后(用户参与评审),可以建立第一个需求基线。此后每次变更并经过评审后,都要重新确定新的需求基线。

软件需求规格说明书标准模板

软件需求规格说明书 文件编号: QMS—PROC-RD02 版本:1.0 受控签章

修改历史

目录 1引言 (2) 1.1目的 (2) 1.2背景 (2) 1.3术语 (2) 1.4预期读者与阅读建议 (2) 1.5参考资料 (2) 1.6需求描述约定 (2) 2.项目概述 (2) 2.1系统功能 (2) 2.2业务描述 (2) 2.3数据流程描述(可选) (2) 2.4用户的特点 (2) 2.5运行环境要求 (2) 2.6设计和实现上的限制 (2) 3.功能需求的描述 (2) 4.非功能需求 (2) 4.1系统性能要求 (2) 4.2系统安全及保密要求 (2) 4.3系统备份与恢复要求 (2) 4.4系统日志 (2) 5.外部接口说明 (2) 6.其他需求 (2) 7 需求变更识别 (2) 8.功能列表 (2) 9.附件 (2)

1引言 1.1 目的 说明编写这份软件需求规格说明书的目的,如:通过本文档定义XXX产品的需求,以求在项目组员与相关成员之间达成一致的需求描述。 1.2 背景 描述系统产生的背景,包括: a.需开发的软件系统的名称,和英文缩写(可选),项目编号(可选); b.列出此项目的任务提出者、开发者 c.软件系统应用范围、用户。 d.产生该系统需求的原因或起源,如社会背景、市场发展、政策趋势、原有系统局限性 1.3 术语 列出本文件中用到的专门术语、术语定义、外文首字母组词的原词组。也可用附件说明。或放到本文件的最后。 1.4 预期读者与阅读建议 描述本文档的主要读者,以及这些读者在阅读时的阅读重点与建议。可用列表的方式列 1.5 参考资料 列出有关的参考资料,如: a.本项目经核准的计划任务书或合同、上级机关的批文; b.属于本项目的其他已发表的文件; c.本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 d.行业标准和规范。 列出这些文件资料的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的来源。

软件工程--图书管理系统项目开发总结报告

软件工程--图书管理系统项目开发总结报告 设计题目:图书管理系统 小组成员:非常“2+3” 指导老师: 2013年6月1日

目录 1.引言 (1) 1.1编写目的 (1) 1.2背景 (1) 1.3定义 (1) 1.4参考资料 (1) 2.项目概述 (2) 2.1项目简介 (2) 2.2开发环境 (2) 2.3开发成果 (2) 2.3.1产品 (2) 2.3.2主要功能和性能 (3) 2.3.3进度 (3) 2.3.4费用 (4) 3.开发总结 (4) 3.1项目整体部分 (4) 3.2需求及设计部分 (5) 3.3软件开发部分 (5) 4.开发工作评价 (5) 4.1对生产效率的评价 (5) 4.2对产品质量的评价 (6) 4.3对技术方法的评价 (6) 4.4出错原因的分析 (6) 5.未来展望 (6)

1.引言 1.1编写目的 近期结束了现代软件工程中关于图书馆管理系统的开发,这也是我第二次较为正式的组织团队成员进行开发工作。图书馆管理系统规模不算大,但是在组织的过程中,却还是发现“2+3”团队在很多地方的不足,现总结之。 预期读者:XX老师、项目小组。 1.2背景 软件系统的名称:图书管理系统 本项目的任务提出者:现代软件工程 开发者: 用户及实现该软件的计算机中心或计算机网络:互联网 该软件系统同其他系统或其他机构的基本的相互来往关系:无 1.3定义 .NET:Microsoft XML Web services 平台; IDE:集成开发环境; C/S:客户机/服务器结构; MVC:模型-视图-控制器的缩写,一种软件设计典范; CRUD:增删改查。 1.4参考资料 (1)、《软件工程导论——第5版》,张海藩编著,清华大学出版社 (2)、《实用软件工程》,Leszek A.Maciaszek Bruc Lee Liong著,机械工业出版社

需求变更

编者按: 作为软件开发人员或者软件系统客户,相信都遭遇过因为需求变更而需要修改系统的情况,一般说来客户会要求改变界面,改变操作方式,甚至改变业务,客户甚至会说:“当时我是那样要求的,不过现在我们的业务调整了”…这时需要中断正在进行的工作,需要查证以往的资料,需要修正计划,需要…… 在本期的月刊中,我们将围绕着“需求变更”这个主题展开讨论,希望对各位开发能有所帮助。让我们先来看一个需求变更的典型案例: Steven刚出任项目经理,并承接了一个中型软件项目。公司再三叮咛他一定要尊重客户,充分满足客户需求。项目开始比较顺利,但进入到后期,客户频繁的需求变更带来很多额外工作。Steven动员大家加班,保持了项目的正常进度,客户相当满意。 但需求变更却越来越多。为了节省时间,客户的业务人员不再向Steven申请变更,而是直接找程序员商量。程序员疲于应付,往往直接改程序而不做任何记录,很多相关文档也忘记修改。很快Steven就发现:需求、设计和代码无法保持一致,甚至没有人能说清楚现在系统“到底改成什么样了”。版本管理也出现了混乱,很多人违反配置管理规定,直接在测试环境中修改和编译程序。但在进度压力下,他也只能佯装不知此事。但因频繁出现“改好的错误又重新出现”的问题,客户已经明确表示“失去了耐心”。 而这还只是噩梦的开始。一个程序员未经许可擅自修改了核心模块,造成系统运行异常缓慢,大量应用程序超时退出。虽然最终花费了整整3天的时间解决了这个问题,但客户却投诉了,表示“无法容忍这种低下的项目管理水平”。更糟糕的是,因为担心系统中还隐含着其他类似的错误,客户高层对项目的质量也疑虑重重。 随后发生的事情让Steven更加为难:客户的两个负责人对界面风格的看法不一致,并为此发生了激烈争执。Steven知道如果发表意见可能会得罪其中一方,于是保持了沉默。最终客户决定调整所有界面,Steven只好立刻动员大家抓紧时间修改。可后来当听说因修改界面而造成了项目一周的延误后,客户方原来发生争执的两人这次却非常一致,同时气愤地质问Steven:“为什么你不早点告诉我们要延期!早知这样才不会让你改呢!”Steven很无耐,疑惑自己到底错在哪里了。

软件需求变更控制流程

需求变更控制流程 文档名称: 文档编号:___________________________ 归档日期:___________________________ 编写者: ________________ 孙_____________ 审核者:_______________________________ 批准者:_______________________________ *The information contained in this message is confidential and should not be disclosed to any third party whether or not you are the intended addressee indicated in the message. *本文件所含内容为保密信息,未经授权请勿随意复制、编改和泄露给任何第三方。 Copyright ?2009 xxx (Sha nghai) Ltd . All Rights Reserved 1.目的 指导项目部、软件部、质量部、测试部对产品的软件变更需求(简称CR进行控制和 管理,规范相应的作业流程,详细地定义了各流程环节中状态、角色和动作。 1.1明确流程中各角色的职责

1.2规范软件缺陷的变更过程 2.适用范围 所有项目的软件变更需求控制管理。 3.定义 CCB Cha ng Con trol Board 的缩写,指变更控制小组,由项目经理、产品经理、软件 开发小组长、软件部经理、测试部主管组成。 SCM Software Configuration Management 的缩写,软件配置管理员。 SQA软件质量保证 产品部门:简称PD 项目部门:简称PM 软件部门:简称SW 测试部门:简称TEST 质量部门:简称SQA 4.参考资料无 5.部门职责 5.1产品部 5.1.1制定产品战略规划,产品定位和定义。 5.1.2客户技术支持,需求分析与管理。 5.1.3提出需求变更申请到到质量部。 5.2质量部 5.2.1接收产品部提出的变更需求。 5.2.2成立项目需求变更评审(CCB小组,召集小组成员对需求变更进行评审。5.3项目部 5.3.1参与需求变更评审,确定需求变更的可行性。 5.3.2将评审通过的需求变更单以通知单的方式发到软件部和测试部。 5.4软件部 5.4.1对需求变更进行技术可行性评估,编写系统需求规格与可行性分析报告,包括技术实现方法、进度要求和风险分析结果以及建议等。 5.4.2确定需求变更信息,制定开发计划,安排代码设计,更新需求规格说明书。 5.5测试部 5.5.1参与需求变更评审工作。 5.5.2确定需求变更信息,制定测试计划,安排对新需求的功能测试。 5.6 CCB 负责对软件相关的变更需求(新需求、 bug修改、建议)进行审核,确定处理的方案。 6.作业流程

软件工程项目管理实施计划书(完整版)

. 储蓄业务项目管理计划书 1.简介 1.1 项目概述 本项目要开发一个银行系统,系统一共分为储蓄业务、贷款业务、外汇交易、网上银行、信用卡业务和系统管理六个子系统。本团队负责其中的有关储蓄业务的子系统。通过团队合作开发整个子系统,使团队成员获得软件工程开发的实际训练。本系统采用目前主流的B/S开发架构,将与整个银行系统一起发布。不单独发布。交付的产品包括可执行的文件、源代码、技术文档与用户使用手册等。本系统的开发过程中的主要工作是子系统需求分析、系统总体设计、子系统源代码开发、子系统测试、交付团长进行最后的集成、整个系统的测试。关键里程碑是制定项目管理计划书、制定需求设计规格说明书初稿、制定系统设计报告的初稿、进行子系统运行情况的检查与测试、进行系统集成后的运行情况的检查与测试。项目所需工具是个人电脑和开发工具。进度为11周,工程量为3人/天。 1.2 项目围说明 (1)提交文档:项目管理计划、需求规格说明,设计报告、测试报告、用户使用手册和项目个人总结。其中项目总结为每人一份,每个小组所有成员的总结装订在一起;其余文档每组提交一份。每个团队可将各小组的文档综合到一起,各小组也可自行分开提交,具体方式由团队部协商确定。所有文档需要提交电子版和打印稿。 (2)源程序检查:一共两次。第一次检查每个小组的子系统运行情况。第二

次检查每个团队六个小组集成后完整的银行系统运行情况,检查完成后需要提交程序源文件和可执行的系统。程序检查安排在上机时间进行。 1.3 软件项目计划书的演化 软件项目计划书在第三周周末前经由小组讨论、共同撰写、汇总整合三步骤形成初稿,第四周以后根据项目的进展可以对其进行修改,需要有组员提出修改意,在全体会上讨论通过,并由组长整理修改意见并作出相应的修改。其余组员同步获得更新稿。 2.项目组织管理 2.1 过程模型 表1.过程模型表

软件工程项目管理

学生社团管理系统 课程名称: 软件项目管理 课题名称:学生社团管理系统 专业:软件工程 班级:卓越131 学号:4323 4140 学生姓名:曹泰杨东东 指导教师:贾晓辉

2016年5月

项目范围管理 系统定义 该软件是学生社团开展社团工作的一个沟通平台,通过学生社团平台学生们可以及时得到新闻以及通知,社团管理员也能更方便的管理整个社团的运作。 项目背景 随着社会发展,新的科技不断涌现,计算机在我们的生活中扮演着越来越重要的角色,办公自动化、高效的处理工作成为我们追求的目标。日常生活中,计算机被应用到更多的领域,所以,学生社团事务处理也可以交给计算机,以帮我们更好、更快的完成工作。提高工作效率,简便的解决日常管理任务,是我们所追求的共同目标。 目前,我们对社团的管理还处于手动化,纸质化的一个阶段,而日益增长的需求已经不能靠原始的管理方式来完成所需的工作,社团管理系统的开发是为解决当前的需要而设计制作的一个管理系统,为社团的管理提供更好的管理支持,这样才能节省我们在社团管理方面所占用的资源。 学生社团是学校的一个以拓展学生业余兴趣爱好的组织,是一个非盈利的组织,社团通过组织具有共同爱好的学生在一起开展一些活动,来丰富学生的课余生活,提高学生的沟通能力和组织能力以及自我表现能力,在社团里志同道合的同学们可以尽情的发挥自己的特长,从而锻炼自己各方面的能力。 随着高校的扩招,大学生群体不断壮大,学生社团这样一个学生组织也不断的壮大,在丰富学生课余生活的同时,也让同学们学到了更多的知识,但是随着学生社团的壮大,学生社团以前纸质办公已经赶不上现在快节奏的办公效率,所以为了提高办事效率以及节约人力物力资源,开发这样一个学生社团管理系统来管理整个社团的日常事务是非常必要的。 高校社团文化日渐丰富,随之而来的繁琐的社团事务,使管理学生社团的工作变得不再那么容易,随着软件行业的发展,我们可以根据学生社团管理的需求来使用办公自动化来管理学生社团,介于社团事务的繁琐性,有必要开发这样一个系统来解决社团事务的繁琐性,提高办事效率。 开发意义 学生社团活动作为学校教育的补充和延伸而存在,作为高等院校学生综合素质培养的主要载体,是学生依据自己的需要而自由拓宽的天地,是大学生培养能力、增长知识、提高素质的一条重要途径,是提高学生综合素质的第二课堂。随着教育体制改革的不断变化,社团日益成为校园里凝聚力和号召力最强的群体。

软件需求变更控制流程

文档名称: 需求变更控制流程 文档编号: 归档日期: 编写者:孙 审核者: 批准者: *The information contained in this message is confidential and should not be disclosed to any third party whether or not you are the intended addressee indicated in the message. *本文件所含内容为保密信息,未经授权请勿随意复制、编改和泄露给任何第三方。 Copyright ?2009 xxx (Shanghai) Ltd . All Rights Reserved

1.目的 指导项目部、软件部、质量部、测试部对产品的软件变更需求(简称CR)进行控制和管理,规范相应的作业流程, 详细地定义了各流程环节中状态、角色和动作。 1.1明确流程中各角色的职责 1.2规范软件缺陷的变更过程 2.适用范围 所有项目的软件变更需求控制管理。 3.定义 CCB:Chang Control Board的缩写,指变更控制小组,由项目经理、产品经理、软件开发小组长、软件部经理、测试部主管组成。 SCM:Software Configuration Management的缩写,软件配置管理员。 SQA:软件质量保证 产品部门:简称PD 项目部门:简称PM 软件部门:简称SW 测试部门:简称TEST 质量部门:简称SQA 4.参考资料 无 5.部门职责 产品部 5.1.1制定产品战略规划,产品定位和定义。 5.1.2客户技术支持,需求分析与管理。 5.1.3提出需求变更申请到到质量部。 5.2 质量部 5.2.1接收产品部提出的变更需求。 5.2.2成立项目需求变更评审(CCB)小组,召集小组成员对需求变更进行评审。 5.3 项目部 5.3.1参与需求变更评审,确定需求变更的可行性。 5.3.2将评审通过的需求变更单以通知单的方式发到软件部和测试部。 5.4 软件部 5.4.1对需求变更进行技术可行性评估,编写系统需求规格与可行性分析报告,包括技术实现方法、进度要求和风险分析结果以及建议等。 5.4.2确定需求变更信息,制定开发计划,安排代码设计,更新需求规格说明书。 5.5 测试部 5.5.1参与需求变更评审工作。 5.5.2确定需求变更信息,制定测试计划,安排对新需求的功能测试。 5.6 CCB 负责对软件相关的变更需求(新需求、bug修改、建议)进行审核,确定处理的方案。 6.作业流程

软件工程与项目管理考试题(学生)

第一章练习题 一、单项选择题 1、软件是()。 A.处理对象和处理规则的描述 B.程序 C.程序、数据及文档 D.计算机系统 2、下列选项中()是软件开发中存在的不正确的观念、方法。 A.重编程、轻需求 B.重开发、轻维护 C.重技术、轻管理 D.以上三条都是 3、下列哪个阶段不属于软件生存周期的三大阶段()。 A.计划阶段 B.开发阶段 C.编码阶段 D.维护阶段 4、计算机系统就是()。 A.主机,显示器,硬盘,软驱,打印机等 B.CPU,存储器,控制器,I/O接口及设备 C.计算机硬件系统和软件系统 D.计算机及其应用系统 5、开发软件所需高成本和产品的低质量之间有着尖锐的矛盾,这种现象称做( )。 A.软件工程 B.软件周期 C.软件危机 D.软件产生 6、以下属于软件危机现象的是()。 A.软件开发进度难以预测 B.软件产品难以维护 C.软件缺少适当的文档资料 D.以上三条都是 7、软件工程的出现主要是由于()。 A.程序设计方法学的影响 B.其它工程科学的影响 C.软件危机的出现 D.计算机的发展 8、以下哪一项不属于项目成功要考虑的因素()。 A.工作范围与成本 B.进度计划 C.客户满意度 D.全都属于 9、以下对软件工程的解释正确的是()。 A.软件工程是研究软件开发和软件管理的一门工程科学 B.软件工程是将系统化的、规范化的、可度量化的方法应用于软件开发、运行和维护的过程C.软件工程是把工程化的思想应用于软件开发 D.以上三条都正确 10、一个项目是否开发,从经济上来说是否可行,归根结底是取决于()。 A.成本估算 B.项目计划

C.工程管理 D.工程网络图 11、软件生存周期包括可行性分析、需求分析、系统设计、编码、()、维护等活动。 A.应用 B.检测 C.测试 D.以上答案都不正确 12、一个软件从开始计划到废弃为止,称为软件的()。 A.开发周期 B.生存周期 C.运行周期 D.维护周期 13、软件计划时期的主要任务是:分析用户要求、新系统的主要目标以及()。 A.开发软件 B.开发的可行性 C.设计软件 D.运行软件 二、判断题 1、软件就是计算机系统中的程序、数据及其文档()。 2、程序是指计算机为完成特定任务而执行的指令的有序集合()。 3、数据是指被程序处理的信息()。 4、软件工程与项目管理是为研究克服软件危机应运而生的()。 5、软件危机是20世纪60年代以前产生的()。 6、软件缺少适当的文档资料属于软件危机现象之一()。 7、软件工程是把工程化的思想应用于软件开发()。 8、软件工程是研究软件开发和软件管理的一门管理科学()。 9、一个好的开发人员应具备的素质和能力不包括具有良好的书面和口头表达能力()。 10、软件工程学是理论研究,没有实际用途()。 11、项目管理过程就是制定计划然后按计划工作()。 12、软件生存周期包括需求分析、系统设计、程序设计、测试、维护,五个阶段()。 13、软件生存周期是指根据某一软件从被提出并着手开始实现,直到软件完成其使命被废弃为止的全过程()。 第二章练习题 一、单项选择题 1、以下哪个不属于问题定义的步骤()。 A.调查和调研 B.形成高层逻辑模型 C.沟通和交流 D.问题定义报告 2、以下哪个不属于问题定义的内容()。 A.问题的背景 B.开发的条件、环境要求 C.实现目标的方案 D.体系结构的设计 3、可行性分析是在系统开发的早期所做的一项重要的论证工作,它是该系统是否开发的决策依据,因此必须给出()的回答。 A.确定

软件工程及项目管理基础知识

软件工程及项目管理基础知识: 信息系统工程质量管理:质量计划、质量保证、质量控制软件质量因素:正确性、健壮性、安全性、可用性、适应性、效率、风险、可理解性、可维修性、可测试性、可移植性、可再用性、互运行性。项目进度控制的重要方法:规划、控制、协调进度控制所采取的措施如下:1 组织措施2 技术措施3 合同措施4 经济措施5 管理措施 影响进度因素:1 人的因素2 材料和设备的因素3 方法和工艺的因素4 资金的因素5 环境因素 成本管理由4个过程组成:1 资源计划过程2 成本估算过程3 成本预算过程4 成本控制过程 影响工程成本主要因素:1 项目属性2 人员属性3 项目成果属性4 计算机属性5 其他因素影响工程变更的主要因素:1 工程的生命周期2 工程的计划、组织和管理3 客户需求变化4 新技术、新工艺的影响5 其他外部因素和不可遇见的突发事件 何为风险?控制风险的方法:风险是指某种破坏或损失发生的可能性,风险管理是指识别,评估,降低风险到可以接收的程度并实施适当机制控制风险,保持在此程度之内的过程。控制风险的方法:1 对动作进行优先排序,风险高的优先考虑 2 评价风险评估过程中的建议,分析建议的可行性和有效性3 实施成本/效益分析4 结合技术、操作和管理类的控制元素,选择性价比最好的安全控制5 责任分配6 制定一套安全措施实施计划7 实现选择的安全控制 风险分析的方法与途径:定量分析和定性分析 项目风险管理应该包括:1 一个风险管理计划,应强调主要项目风险、潜在的影响、解决方案、降低风险的措施 2 一个风险预防计划或应急计划,包括降低风险所必需的资源、时间及成本概算3 一个在整个项目周期内自始至终对风险进行测定,跟踪及报告的程序4 应急费用,并将其列入预算。 项目定义并说明项目管理三要素之间的关系:所谓项目,就是在既定的资源和要求的约束下,为实现某种目的而相互联系的一次性工作任务,这个定义包括三层意思:一定的资源约束、一定的目标、一次性任务。项目三角形是指项目管理中范围、时间、成本三个因素之间相互影响的关系;质量处于三角形的中心。它会影响三角形的每条边,对三条边的任何一个更改都会影响质量;质量不是三角形的要素;是时间、成本和范围协调的结果。 项目管理的四大核心领域:范围管理、成本管理、时间管理、质量管理 项目管理的九大知识领域:范围管理、成本管理、进度管理、质量管理、人力资源管理、沟通管理、采购管理、风险管理和综合管理。 五大项目过程:项目的启动过程,项目计划过程,项目执行过程,项目监控过程,项目收尾过程 何为项目管理及特点:项目管理就是项目的管理者,在有限的资源约束下,运用系统的观点、方法和理论对项目涉及的全部工作进行有效的管理,即从项目的投资决策开始到项目结束的全过程进行计划、组织、指挥、协调、控制和评价,以实现项目的目标; 项目管理特点:1 项目管理是一项复杂的工作2 项目管理具有创造性3 项目管理需要集权领导并建立专门的项目组织4 项目负责人在项目管理中起着非常重要的作用。 软件的质量特性包括功能性、可靠性、易用性、效率、可维护性、可移植性等六个方面,每个方面都包含若干个子特性:功能性:适合性、准确性、互操作性、依从性、安全性;可靠性:成熟性、容错性、易恢复性;易用性:易理解性、易学性、易操作性;效率:时间特性、资源特性;可维护性:易分析性、易改变性、稳定性、易测试性; 可移植性:适应性、易安装性、遵循性、易替换性; 质量管理:在质量方面指挥和控制组织的协调的活动,指对确定和达到质量所必须的全总

如何应对软件开发中的需求变更

如何应对软件开发中的需求变更 【摘要】在软件项目开发的过程中,软件的需求变更是一个回避不了的问题,它的处理的好坏,更是决定软件开发项目是否能够顺利、完美、高效率得到实现的关键。本文针对STS8000测试系统在软件项目开发过程中出现的常见问题,探讨了如何应用项目需求变更管理、项目目标管理、版本更新管理与软件测试管理,从而帮助并促进软件开发人员开发出更加完美、高效、稳定、有质量的软件产品。 【关键词】需求变更管理;软件项目目标管理;版本更新管理;软件测试管理 随着软件系统的规模、复杂度日益上升,软件开发过程中的各种质量管理已经成为保证软件系统开发效率、质量、成本的关键性因素。软件行业在现在的众多行业里是一个极具挑战性和创造性的行业,体现了软件开发者的智慧和汗水,同时软件开发是一项复杂的系统工程,牵涉到许多方面的因素,在实际工作中,经常会出现各种各样的问题。如何总结、分析并解决软件开发过程中各种问题,对于项目开发人员与管理人员来说,是在今后的项目中取得成功的关键。 目前,STS8000系统在软件方面出现的问题主要有下面几方面: 1、客户不断提出新的需求。软件开发人员不断地陷于满足用户需求的过程中。似 乎,我们在需求上无能为力,我们永远在追赶客户的需求,满足他们的现状, 把N多家的客户需求都加进软件中,只要能实现的,我们尽量咬牙实现了。最 后,我们发现,我们的软件无比复杂,谁也不知道这个需求当时为什么是这样 的。因为无比复杂,所以稳定性更成了问题。代码互相交叉,根本无法理清有 多少交叉影响点。 2、改正了旧问题,又冒出更多新问题,问题层出不穷;维护的工程师都快崩溃了, 天天在祈求,千万别接到客户电话。对于修改现有代码适应新客户新项目,这 种情况出现的非常多。客户打电话说了一个需求,能技术达到就答应下来修改, 修改完就给客户覆盖,根本没有需求变更管理、版本更新管理。而这样的代码, 还不是一个特定客户一套特定定制化代码,是要给其他客户也更新的。很可能 这个客户好使,那个客户使用其他功能的时候就出了错。按下葫芦起了瓢,是 很常见的现象。 3、由于长期陷于满足用户需求的过程中,天长日久,软件工程师就会木然、倦怠, 会形成做一天和尚撞一天钟。有问题就打补丁,客户不嚷嚷就懒的修改,代码 不优化、不封装,界面不友好,架构更是没架构。模块难度、工期质量考核无 法量化,更无法与个人收入挂钩。 以上三个问题,其实归纳起来就一个关键点:如何处理好需求这个问题,从而使客户、公司、研发人员多方达到共赢。下面,就这个关键点,谈谈我的一些看法。 一、必须进行需求变更管理 软件,尤其项目型软件,不修改是不太可能的。但是,在修改软件时,不能进行就事论事的修改。否则很容易陷入到某一家客户具体的需求中,而不会考虑其他客户的需求兼容,

IT项目需求变更表申请表(实例)

需求、设计和开发变更表 产品名称龙岗政府在线升级改造项目 项目名称龙岗政府在线升级改造项目项目经理霍军良 变更申请人郭昊申请时间2007年7 月19 日变更类型 □新增需求需求变更□内部改进□产品缺陷 □系统环境变更□其他 变更描述 变更前的描述(若是新需求,则不需填写此栏): 区长信箱的管理部门(区长专线办)只能指定一个部门处理区长来信。 新需求或变更后的描述: 区长信箱收获的区长来信,区长专线办可以分发给多个部门处理。各个部门能够按照自己的处理方式反馈。处理结果要求集中在前台按照各个部门的处理结果按照列表显示。 变更影响的配 置项序号配置项影响描述当前版本需求变更受影响的文档版本号的更新 2.0.1 变更评审方式项目组裁决□召开评审会议□会签评审评审负责人霍军良评审成员宋雷鸣、郭昊、卞兆洋、梁伟 评审意见更改对产品组成部分的影响: 在区长信箱多了一些功能操作。增加了多部门处理方法! 更改方案描述: 在页面中选择好要分发的部门,然后在后台将部门数据传入到集合内,循环遍历集合中数据属性存入数据库相关表中。并删除原来数据。最后在系统的工作任务中建立任务调度时间设置在每天22:00。 变更对进度的影响 (天) 由于工作量不大,而且通过加班工作,对进度的影响可以 忽略不计。 第1 页共2 页

变更对成本的影响由于工作量不大,而且通过加班工作,对进度的影响可以 忽略不计。 变更对质量的影响添加这个新的需求会对系统测试案例等文档产生影响。对 配置库的影响是:受影响的文档版本号的更新。 变更引起的风险无 技术评审结论可以更改□拒绝变更 是否属不合格□是不是 评审人员签字评审负责人评审人评审人评审人评审人评审人评审人霍军良郭昊宋雷鸣卞兆洋梁伟 CCB意见 立即更改□推迟更改□拒绝变更 签字林文涛日期2007年7 月19 日 项目经理 确认 卞兆洋、郭昊在2007-7-18中午晚上加班修改完成。 签字霍军良日期2007年7 月19 日变更当前状态□已指派□已打开□已更改已验证 更改情况 已经对区长信箱收获的区长来信,区长专线办可以分发给多个部门处理。各个部门能够按照自己的处理方式反馈。处理结果集中在前台按照各个部门的处理结果显示在列表中。 更改人签字郭昊、卞兆洋日期2007年7 月19 日 更改验证情况 通过任务调度,已经测试通过,实现了分发给多个部门处理。 验证人签字刘艳君日期2007年7 月19 日变更配置项验证 变更的配置项责任人完成日期版本CMO审核结论 需求变更宋志强2007年7月19 日 1.01 已更改完成 第2 页共2 页

软件工程在软件开发中的作用

软件工程在软件开发中的作用 1、定义项目成功的标准在项目的开始,要保证风险承担者对于他们如何判断项目是否成功有统一的认 识。经常,满足一个预定义的进度安排是唯一明显的成功因素,但是肯定还有其他的因素存在,比如:增加市场占有率,获得指定的销售量或销售额,取得特定用户满意程度,淘汰一个高维护需求的遗留系统,取得一个特定的事务处理量并保证正确性。项目计划目标定义,包括进度,成本和质量(PP) 2、识别项目的驱动、约束和自由程度每个项目都需要平衡它的功能性,人员,预算,进度和质量同标。我们把以上五个项目方面中的每一个方面,要么定义成一个约束,你必须在这个约束中进行操作,要么定义成与项目成功对应的驱动,或者定义成通向成功的自由程度,你可以在一个规定的范围内调整。相关的详细信息,请参照我的《创建一种软件工程文化》(Creating a software Engineering Culture )(Dorset House ,1996)中的第一章。项目的假设和约束(PP) 3、定义产品发布标准在项目早期,要决定用什么标准来确定产品是否准备好发布了。你可以把发布标准基于:还存在有多少个高优先级的缺陷、性能度量、特定功能完全可操作、或其他方面表明项目已经达到了它的目的。不管你选择了什么标准,都应该是可实现的、可测量的、文档化的,并且与你的客户指的“质量”一致。项目的具体验收标准(PP) 4、沟通承诺尽管有承诺不可能事件的压力,从不作一个你知道你不能保证的承诺。和客户和管理人员沟通哪些可以实际取得时,要有好的信誉。你的任何以前项目的数据会帮助你作说服的论据,虽然这对于不讲道理的人来说没有任何可真正的防御作用。沟通计划,关键依赖和承诺(PP) 5、写一个计划有些人认为,花时间写计划还不如花时间写代码,但是我不这么认为。困难的部分不是写计划,困难的部分是作这个计划——思考,沟通,权衡,交流,提问并且倾听。你用来分析解决问题需要花费的时间,会减少项目以后会带给你的意外。项目计划(PP) 6、把任务分解成英寸大小的小圆石英寸大小的小圆石是缩小了的里程碑。把大任务分解成多个小任务,帮助你更加精确的估计它们,暴露出在其他情况下你可能没有想到的工作活动,并且保证更加精确、细密的状态跟踪。工作结构分解WBS (PP) 7、为通用的大任务开发计划工作表如果你的组经常承担某种特定的通用任务,如实现一个新的对象类,你需要为这些任务开发一个活动检查列表和计划工作表。每个检查列表应该包括这个大任务可能需要的所有步骤。这些检查列表和工作表将帮助小组成民确定和评估与他/她必须处理的大任务的每个实例相关的工作量。项目进度计划(PP) 8、计划中.在质且控制活动后应证百赐改工作 几乎所有的质量控制活动.如测试和技术评审.都会发现缺陷或其他提高的可能。你的项目进度或工作细分结构,应该把每次质量控制活动后的修改,作为一个单独的任务包括进去。如果你事实上不用作任何的修改,很好,你已经走在了本任务的计划前面。但是不要去指望它。项目质量计划,质量保证计划(PPQA) 9、为过程改进安排时间你的小组成员已经淹没在他们当前的项目中,但是如果你想把你的组提升到一个更高的软件工程能力水平,你就必须投资一些时间在过程改进上。从你的项目进度中留出一

需求变更七步法

软件需求变更管理七步法 典型场景:最近比较烦,烦客户!我们现在正在给长江市政府做一个电子政务项目,其中有一项功能是网上婚姻申请登记功能。因为前一段国家政策取消了强制性体检这个环节,所以我们的工作流程也相应的变更。 没想到客户从中得到启发:我们的许多工作流程做好后改动的可能性很大(例如政策调整、部门变动、领导班子重组等),干脆给我们做成可定制的功能,我们提一个最大的功能集合,你们做好了我们自己就可以随需而变,嗯,这样好! 可是对项目组来说这可是个灾难啊!因为可定制的功能往往意味着工作量的倍增! 分析:先说说大家对于这种现象的应对方法吧。最典型的是通过与客户的沟通来解决问题。怎么样沟通呢?因为尤其是对于软件项目的合同很难在签订之初就能够精确定义的每项功能,所以靠合同是帮不上忙的。 我和许多IT公司的老总们作交流,我开玩笑说我们IT公司都是清政府。为什么是清政府?清政府的特点之一就是丧权辱国的条约太多。大家往往只有苦笑:有什么办法呀,客户着急了就是一句潜台词:做不做,不想做滚蛋!想做的公司多着呢。 所以你看合同是没用的,那怎么办呢?通常都是通过感情联络争取客户的同情。就像上面的场景中谈到的一样,明明是不合理的要求,可是客户也会狡辩呀,“凭什么不给我们做,这可是合同范围内的工作!”。因为原来只说要实现工作流,而没有谈到定制的工作流算不算。问题出来了,看看怎么办吧。 当然了,如果现在遇到类似的问题,您的组织都可以举重若轻的化解,那您就不用往下看了。我们常听到一句话就是“合情合理”,大家说这有什么好希奇的呀,老生常谈!不过这句话在软件项目的变更管理中却有独特的表现形式。从感情上与客户去沟通很重要,但是您注意到它只做了一半工作,还有一半工作需要去讲理。大家会反驳我说:讲什么理!我们的客户就是上帝,让你做你就做!哪儿那么多废话呀你。 我注意到一个社会现象:客户方的直接项目负责人从年龄上来看往往有年轻化的趋势——三四十岁居多。这些人有什么特点呢?首先从教育程度上讲他们往往都接受过正规教育,所以还比较讲理——或者是因为现在职位还不够高(开玩笑)?其次这些人是真正希望在工作上出成绩的。当项目真遇到负面的风险时,他们愿意去说服自己的领导而不是不作为。 正是基于以上两点分析,我们先来介绍需求变更管理方法——变更管理七步法。七步法印证了我经常鼓吹的项目管理三部曲:细化、量化、图形化,七步法主要验证了细化和量化的必要性和好处。我们先来看看下面这幅图:

软件工程项目管理计划书(完整版)

储蓄业务项目管理计划书 简介 项目概述 本项目要开发一个银行系统,系统一共分为储蓄业务、贷款业务、外汇交易、网上银行、信用卡业务和系统管理六个子系统。本团队负责其中的有关储蓄业务的子系统。通过团队合作开发整个子系统,使团队成员获得软件工程开发的实际训练。本系统采用目前主流的B/S开发架构,将与整个银行系统一起发布。不单独发布。交付的产品包括可执行的文件、源代码、技术文档与用户使用手册等。本系统的开发过程中的主要工作是子系统需求分析、系统总体设计、子系统源代码开发、子系统测试、交付团长进行最后的集成、整个系统的测试。关键里程碑是制定项目管理计划书、制定需求设计规格说明书初稿、制定系统设计报告的初稿、进行子系统运行情况的检查与测试、进行系统集成后的运行情况的检查与测试。项目所需工具是个人电脑和开发工具。进度为11周,工程量为3人/天。 项目范围说明 (1)提交文档:项目管理计划、需求规格说明,设计报告、测试报告、用户使用手册和项目个人总结。其中项目总结为每人一份,每个小组所有成员的总结装订在一起;其余文档每组提交一份。每个团队可将各小组的文档综合到一起,各小组也可自行分开提交,具体方式由团队内部协商确定。所有文档需要提交电子版和打印稿。 (2)源程序检查:一共两次。第一次检查每个小组的子系统运行情况。第二次检查每个团队内六个小组集成后完整的银行系统运行情况,检查完成后需要提交程序源文件和可执行的系统。程序检查安排在上机时间进行。 软件项目计划书的演化 软件项目计划书在第三周周末前经由小组讨论、共同撰写、汇总整合三步骤形成初稿,第四周以后根据项目的进展可以对其进行修改,需要有组员提出修改意,在全体会上讨论通过,并由组长整理修改意见并作出相应的修改。其余组员同步获得更新稿。 项目组织管理 过程模型 表1.过程模型表

软件需求变更

编号:XZ174 软件需求(变更)通知书 委托方项目责任人签字:受托方项目责任人签字:___年__月__日___年__月__日说明:该变更通知书一式两份,委托方、受托方各执一份。

附件: 清欠车辆录入模块: 录入界面 1、其中,基本情况栏中的内容为自动获取,清欠情况为手工录入且非空。 2、清欠情况中,清欠方式为单选项。 3、当选择为开元汽车清欠时,清欠单位显示为:风险部,当选择为省公司清欠时,通过录 入该信息的账号获取其所属省公司,当选择为异地协助清欠、本单位清欠时,获取录入该信息的账号所属的单位。 此处添加确定、取消按钮。 清欠车辆确认模块: 该模块以列表形式显示,显示内容为: 清欠车辆审核模块: 该模块以列表形式显示,显示内容为: 1、只显示已经确认过的信息,未确认信息不显示。 2、可通过清欠单位、车辆所属单位、清欠方式、清欠时间段、风险等级、是否放车、车辆 处置结果进行查询。 3、可导出查询后的结果,或导出所有明细。 4、列表显示规则为以时间排序,以降序排列。 该模块点击查看后,显示内容为:

就地全面销售管理

自清欠之日(确认后)起10日内未完成销售(未审核),自第11日,该车辆资料自动转到车辆就地全面销售模块,同时增加销售价格项及车辆处置方式。 所属省公司销售管理 自清欠之日(确认后)起30日内未完成销售(未处置),自第31日,该车辆资料自动转到车辆省公司销售模块,同时增加销售价格项及车辆处置方式。 移交车辆 自清欠之日(确认后)起90日内未完成销售(未处置),自第91日,该车辆资料自动转到移交车辆模块,该模块可使用目前ERP中的移交车辆管理模块。 中心销售管理 待移交车辆审核确认后,该车辆信息转到中心销售管理模块下。 统计汇总模块 以省公司为单位,统计各阶段车辆数量,并允许导出所有车辆明细(清欠阶段为已确认车辆)具体显示表格如下:

相关文档
最新文档