软件生存期内全部的软件配置是软件产品的真正代表,必须使其保持精确。软件工程过程中某一阶段的变更,均要引起软件配置的变更,这种变更必须严格加以控制和管理,保持修改信息,并把精确、清晰的信息传递到软件工程过程的下一步骤。
变更控制包括建立控制点和建立 告与审查制度。
对于一个大型的软件来说,不加控制的变更很快就会引起混乱。因此变更控制是一项最重要的软件配置任务。图11.17给出了变更控制的过程。
存取和同步控制流如图11.18所示。根据经批准的变更请求和EC(),软件工程师从项目数据库中检出要变更的配置对象。存取控制功能保证了软件工程师有 检出该对象的权限,而同步控制功能则封锁(lock)了项目数据库中的这个对象,使得当前检出的版本在没有被置换前不能再更新它。当然,对这个对象还可以 检出另外的副本,但对其也不能更新。软件工程师在对这种成为基线的对象做了变更,并经过适当的软件质量保证和测试之后,把修改版本登入项目数据库,再解除 封锁(unlock)。
软件的变更通常有两类不同的情况:
(1)为改正小错误需要的变更。它是必须进行的,通常不需要从管理角度对这类变更进行审查和批准。但是,如果发现错误的阶段在造成错误的阶段的后面,例如 存实现阶段发现了设计错误,则必须遵照标准的变更控制过程,把这个变更正式记入文档,把所有受这个变更影响的文档都做相应的修改,中国自学编程 整理首 发,www.zxbc.cn。
(2)为了增加或者删掉某些功能、或者为了改变完成某个功能的方法而需要的变更。这类变更必须经过某种正式的变更评价过程,以估计变更需要的成本和它对软 件系统其他部分的影响。如果变更的代价比较小且对软件系统其他部分没有影响,或影响很小,通常应批准这个变更。反之,如果变更的代价比较高,或者影响比较 大,则必须权衡利弊,以决定是否进行这种变更。如果同意这种变更,需要进一步确定由谁来支付变更所需要的费用。如果是用户要求的变更,则用户应支付这笔费 用;否则,必须完成某种成本/效益分析,以确定是否值得做这种变更。
应该把所做的变更正式记入文档,并相应地修改所有有关的文档。
这种变更 告和审查制度,对变更控制来说起了一个安全保证作用。在一个SCI成为基线之前,可以对所有合理的项目和技术申请进行非正式的变更;一旦某个 scI经过正式的技术评审并得到批准,它就成了基线。以后如果需要对它变更,就必须得到项目负责人的批准(限于局部的修改),或者必须得到变更控制负责人 的批准(当这个变更影响到其他SCI时)。这种变更有时要求有变更申请、变更 告、工程变更顺序等,但必须对每一项变更进行评价并对所有的变更进行跟踪和 复审。
当软件产品已经交付用户使用后,如果有变更要求,就必须有正式的变更控制制度,其过程在图11.17中已经给出。
根据软件项目的规模和特点,变更控制负责人可以只是一个人——项目管理人,也可以是一个小组,包括软件、硬件、数据库工程、市场经销等各方面的代表。变更 控制负责人的责任是从全局的观点出发,评价变更的影响。例如,该项变更会对软件造成什么影响项变更会对性能造成什么影响项变更会使用户对产品的感 觉发生什么变化项变更会对软件产品的质量和可靠性造成什么影响nbsp; 文章知识点与官方知识档案匹配,可进一步学习相关知识MySQL入门技能树数据库组成表31556 人正在系统学习中
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!