软件配置管理主要包括哪些基本过程
软件配置管理是贯穿软件开发过程始终的一项工作。
对于一个软件项目来说,软件配置管理规范至少包括以下的内容: (1)配置项及其命名规则。
(2)配置库文件目录结构。
(3)角色和权限定义。
(4)配置项变更流程。
(5)配置项发布。
(6)基线定义和基线变更。
项目中的基线有两个方面:一是作为里程碑的基线;另一个是模块的阶段性成果基线(对工作产品而言),一般来说都要避免变更基线。
对这两种不同的基线,其影响的范围不同,确立和变更方式也不一样。
项目的基线变更控制委员会由客户代表、产品经理、项目经理和技术经理组成,对发布的里程碑类基线的变更必须由变更控制委员会确认并由QA进行变更记录,所有被变更影响的配置项都需要重新同步后再次发布;而对于仅仅作为工作状态保留的基线,一般只需要建立基线的小组确认更改并在QA进行记录即可。
什么是基线库?
基线是软件文档或源码(或其它产出物)的一个稳定版本,它是进一步开发的基础.所以,当基线形成后,项目负责SCM的人需要通知相关人员基线已经形成,并且哪儿可以找到这基线了的版本.这个过程可被认为内部的发布.至于对外的正式发布,更是应当从基线了的版本中发布. 基线是项目储存库中每个工件版本在特定时期的一个“快照”。
它提供一个正式标准,随后的工作基于此标准,并且只有经过授权后才能变更这个标准。
建立一个初始基线后,以后每次对其进行的变更都将记录为一个差值,直到建成下一个基线。
所谓基线库,就是同类的基线组成的库,一般由配置管理员设立。
基线是什么
展开全部 基线【base line】指的是在三角网测量中,经精确测定长度的直线段。
政治地理: 1.基线:又称领海基线,是陆地和内水同领海的分界线,是划定领海、毗连区、专属经济区和大陆架宽度的起算线。
??? 2.基线——经流动相冲洗,柱与流动相达到平衡后,检测器测出一段时间的流出曲线。
一般应平行于时间轴。
计算机类 基线(Baseline),基线是软件文档或源码(或其它产出物)的一个稳定版本,它是进一步开发的基础.所以,当基线形成后,项目负责SCM的人需要通知相关人员基线已经形成,并且哪儿可以找到这基线了的版本.这个过程可被认为内部的发布.至于对外的正式发布,更是应当从基线了的版本中发布. 基线是项目储存库中每个工件版本在特定时期的一个“快照”。
它提供一个正式标准,随后的工作基于此标准,并且只有经过授权后才能变更这个标准。
建立一个初始基线后,以后每次对其进行的变更都将记录为一个差值,直到建成下一个基线。
参与项目的开发人员将基线所代表的各版本的目录和文件填入他们的工作区。
随着工作的进展,基线将合并自从上次建立基线以来开发人员已经交付的工作。
变更一旦并入基线,开发人员就采用新的基线,以与项目中的变更保持同步。
调整基线将把集成工作区中的文件并入开发工作区。
建立基线的三大原因是:重现性、可追踪性和报告。
重现性是指及时返回并重新生成软件系统给定发布版的能力,或者是在项目中的早些时候重新生成开发环境的能力。
可追踪性建立项目工件之间的前后继承关系。
其目的在于确保设计满足要求、代码实施设计以及用正确代码编译可执行文件。
报告来源于一个基线内容同另一个基线内容的比较。
基线比较有助于调试并生成发布说明。
建立基线后,需要标注所有组成构件和基线,以便能够对其进行识别和重新建立。
建立基线有以下几个优点: 基线为开发工件提供了一个定点和快照。
新项目可以从基线提供的定点之中建立。
作为一个单独分支,新项目将与随后对原始项目(在主要分支上)所进行的变更进行隔离。
各开发人员可以将建有基线的构件作为他在隔离的私有工作区中进行更新的基础。
当认为更新不稳定或不可信时,基线为团队提供一种取消变更的方法。
您可以利用基线重新建立基于某个特定发布版本的配置,这样也可以重现已报告的错误。
使用 定期建立基线以确保各开发人员的工作保持同步。
但是,在项目过程中,应该在每次迭代结束点(次要里程碑),以及与生命周期各阶段结束点相关联的主要里程碑处定期建立基线: 生命周期目标里程碑(先启阶段) 生命周期构架里程碑(精化阶段) 初始操作性能里程碑(构建阶段) 产品发布里程碑(产品化阶段) 软件工程: 什么是基线?第一次提出的软件配置项就构成基线配置项。
基线分类列表如下: –系统功能说明。
系统模型,项目计划,进度安排; –软件需求规格说明。
包括:图形分析模型、过程、原型、数学规格说明; –设计规格说明。
包括:数据设计、体系结构设计、界面设计、对象的描述等;验收规格说明; –测试规格说明。
包括:测试计划、测试用例、测试预期结果、测试记录等; –数据库描述。
包括:数据模式、记录结构、数据项描述; –模块规格说明。
包括:模块功能、模块算法、模块接口等描述; –运行系统。
包括:模块代码、链接模块、数据库、支持及工具程序等; –用户文档。
包括:安装说明、操作说明、用户手册等;培训计划;维护文档,包括:故障报告、维护要求、更改记录等; –项目采用的有关标准和规程。
字体、排版: 基线(Baseline)是大部分字母所“坐”在的,字体的下降部之上的直线。
下图红色的直线就是基线。
[英文排版术语]英文排版术语 色谱: 基线是检测器在没有进样时信号随时间的变化曲线,一般为噪音随时间的变化曲线,正常情况下在灵敏度不是很高时为一平直的线.
基线体重是什么意思
测量学:基线【base line】指的是在三角网测量中,经精确测定长度的直线段。
政治地理:1.基线:又称领海基线,是陆地和内水同领海的分界线,是划定领海、毗连区、专属经济区和大陆架宽度的起算线。
???2.基线——经流动相冲洗,柱与流动相达到平衡后,检测器测出一段时间的流出曲线。
一般应平行于时间轴。
计算机类基线(Baseline),基线是软件文档或源码(或其它产出物)的一个稳定版本,它是进一步开发的基础.所以,当基线形成后,项目负责SCM的人需要通知相关人员基线已经形成,并且哪儿可以找到这基线了的版本.这个过程可被认为内部的发布.至于对外的正式发布,更是应当从基线了的版本中发布. 基线是项目储存库中每个工件版本在特定时期的一个“快照”。
它提供一个正式标准,随后的工作基于此标准,并且只有经过授权后才能变更这个标准。
建立一个初始基线后,以后每次对其进行的变更都将记录为一个差值,直到建成下一个基线。
参与项目的开发人员将基线所代表的各版本的目录和文件填入他们的工作区。
随着工作的进展,基线将合并自从上次建立基线以来开发人员已经交付的工作。
变更一旦并入基线,开发人员就采用新的基线,以与项目中的变更保持同步。
调整基线将把集成工作区中的文件并入开发工作区。
建立基线的三大原因是:重现性、可追踪性和报告。
重现性是指及时返回并重新生成软件系统给定发布版的能力,或者是在项目中的早些时候重新生成开发环境的能力。
可追踪性建立项目工件之间的前后继承关系。
其目的在于确保设计满足要求、代码实施设计以及用正确代码编译可执行文件。
报告来源于一个基线内容同另一个基线内容的比较。
基线比较有助于调试并生成发布说明。
如何有效控制需求变更
需求变更对软件开发项目成败有重要影响,既不能一概拒绝客户的变更要求,也不能一味地迁就客户,所以实施需求变更之前必须做好控制。
需求变更控制的目的不是控制变更的发生,而是对变更进行管理,确保变更有序进行。
(1)明确合同约束,建立需求基线 需求变更给软件开发带来的影响有目共睹,所以在与客户签订合同时,可以增加一些相关条款,如限定客户提出需求变更的时间,规定何种情况的变更可以接受、拒绝或部分接受,还可以规定发生需求变更时必须执行变更管理流程。
虽然软件开发合同很难在签订之初就能够精确定义每项需求,单靠合同是帮不上忙的,但也不能忽视合同的约束力。
明确和树立需求基线是需求变更的依据。
在开发过程中,需求确定并经过评审后(客户参与评审),建立第一个需求基线。
此后每次变更并经过评审后,都要重新确定新的需求基线,做到小需求可以变更,但大方向要力保不频繁变更。
例如,对于项目中的需求,可以实行分级管理,以达到对需求变更的控制和管理。
(2)建立变更审批流程 在实践中,人们往往不愿意为小的需求变更去执行正规的需求管理过程,认为降低开发效率,浪费时间。
正是这种观念才使需求变更变得不可控,最终导致项目的失败。
因此,小的需求变更也要经过正规的需求管理流程,否则会积少成多,积重难返。
明确需求变更审批环节、审批人员、审批事项、审批流程。
这么做的目的有两个:一是将客户下达变更的流程尽可能地规范化,减少张嘴就来的非必要、非紧急、非合理、非高层领导意图的无效变更。
二是留下书面依据,为今后可能的成本变更和索赔准备好“变更账”。
凡未履行审批程序的“变更”,一律是无效变更不予受理。
(3)分级管理变更,定时批量处理 软件开发项目中,“客户永远是对的”和“客户是上帝”并不完全正确,因为在已经签定的项目合同中,任何新需求的变更和增加除了影响项目的正常进行以外,还影响到客户的成本投入收益。
因此,用户不断提出对项目进度有重大影响的需求对双赢也并不是好事。
当遇到客户提出需求,不及时处理可能会使项目不能验收通过时,也不能一味拒绝不予开发。
因此,当客户坚持变更新需求时,可以建议客户将新需求按重要和紧迫程度划分档次,作为需求变更评估的一项依据。
例如,每周或每两周甚至每月召开一次需求变更专题会议,集中研究处理这些零碎变更事项,主动控制好工作节奏,尽量避免由于处理零碎变更而影响项目进度。
针对会议结果可向客户正式提交一份需求变更计划,注明变更引起的时间、成本、工期代价和增加工作量等。
要求客户配合需求变更计划,确定变更时限,控制变更规模,过时变更不候,离谱变更不做,保大局弃小变。
(4)安排专职人员负责变更管理 有时开发任务较重,开发人员容易陷入开发工作中而忽略了与客户的随时沟通。
因此,需要安排一名专职的需求变更联络人员,负责与客户及时交流,跟踪和汇报需求变更完成进度和情况。
同时,可以成立项目变更控制小组,负责裁定接受哪些变更,小组由项目所涉及的多方人员共同组成,应该包括客户方和开发方的决策人员在内。
(5)确认客户是否接受变更的代价 要让客户认识到变更都是有代价的,要和客户一起判断需求变更是否依然进行。
例如,变更是没有问题的,但是要明确客户能否接受由此引起的如进度延迟、费用增加、效率下降等问题。
一般来说,如果客户认为该变更是必须的(不是其上级领导拍脑袋提出的)就会接受这些后果。
通过与客户协商,这样开发团队即使没有回报,也不会招致公司和客户双方的埋怨。
如果客户认为该变更虽然有必要但是可以暂缓,双方签署备忘录后留待以后解决。
如果客户认为该变更可有可无,多数情况下会取消变更。
这样即可防止频繁变更,也让客户认识到不是所有的需求都需要变更。
计算机软件配置项是什么
CSCI是计算机软件配置项(Computer Software Configuration Item)简称,在软件设计文档中经常用到。
配置与配置项在配置管理中,“配置”和“配置项”是重要的概念,“配置”是在技术文档中明确说明并最终组成软件产品的功能或物理属性。
因此“配置”包括了即将受控的所 有产品特性,其内容及相关文档,软件版本,变更文档,软件运行的支持数据,以及其他一切保证软件一致性的组成要素,相对与硬件类配置,软件产品的“配置” 包括更多的内容并具有易变性。
受控软件经常被划分为各类配置项(Configuraion items, CIs),这类划分是进行软件配置管理的基础和前提,CIs是逻辑上组成软件系统的各组成部分。
比如一个软件产品包括几个程序模块,每个 程序模块及其相关文档和支撑数据可能被命名为一个CI。
一个系统包括的CIs的数目是一个与设计密切相关的问题,关于怎样将一个软件系统划分为不同的 CIs将在以下有关章节中阐述,注意如果一个产品同时包括硬件和软件部分,一般一个CI也同时包括软件和硬件部分,一个纯软件的CI通常也称之为软件配置 项(CSCI)。
本规范的CI一般指CSCI,软硬件的配置管理有一些相通的地方,但因为软件更易于修改,所以软件配置管理是一个更应该系统化的过程。
基线与基线管理各CIs随软件开发活动的进展,会有越来越多的部件进入受控状态。
一般地,软件开发过程从概念演绎和需求分析开始,然后是设计,各CSCIs的编码或写 作,集成测试,最后是用户手册的编写等。
软件配置管理包括了在软件生命周期的时间分散点上对各CIs进行标识并对对他们的修改进行控制的过程。
在一个开发 阶段结束或一组功能开发完成后,要对相应的CIs进行基线化并形成各类基线。
在配置管理系统中,基线就是一个CI或一组CIs在其生命周期的不同时间点上 通过正式评审而进入正式受控的一种状态,而这个过程被称为“基线化”。
每一个基线都是其下一步开发的出发点和参考点。
每个基线都将接受配置管理的严格控制,对其的修改将严格按照变更控制要求的过程进行,在一个软件开发阶段结束时,上一个基线加上增加和修改的基线内容形成下一个基线,这就是“基线管理”的过程,因此基线具有以下属性:通过正式的评审过程建立 基线存在于基线库中,对基线的变更接受更高权限的控制基线是进一步开发和修改的基准和出发点。
一般地,第一个基线包含了通过评审的软件需求,因此称之为“需求基线”,通过建立这样一个基线,受控的系统需求成为进一步软件开发的出发点,对需求的变更被正式初始化、评估。
受控的需求还是对软件进行功能评审的基础。
请问里程碑和基线有什么区别?
展开全部 里程碑:里程碑是人为设置的一个项目进阶标志位。
一般都会定义阶段的scope,到了里程碑这个点对项目状态进行管理评审,看看是不是达到了阶段的目标,从而决定项目走向。
基线:阶段或过程工作产品达到某一要求,可以作为下一阶段的工作基础,称为基线化。
被基线化的工作产品的变更是需要走严格的变更管理流程的。
一般来说,一个里程碑的达成可能有若干种工作产品进行了若干次的基线化动作。
...
软件配置管理和质量保证
软件配置管理目的:● 通过使用配置管理软件,遵守版本控制、变更控制等规程,保证所有配置项的完整性和可跟踪性。
范围:● 适用于公司的软件开发项目,它规定了软件配置管理活动的具体规程及其工作产品。
角色与职责:● 配置管理员:编制项目配置管理计划;创建并维护配置库。
● 配置变更控制委员会(SCCB):审批配置变更申请。
● 软件开发组成员:在权限内使用配置管理工具操作配置库。
● 项目SQA人员:审计配置管理活动的规范性。
主要活动:1 在项目早期(在项目计划初稿后,并与项目计划一起评审)编制项目配置管理计划。
● 确定项目配置管理员。
● 项目经理和项目配置管理员共同指定项目组的SCCB。
● 项目经理与项目配置管理员按确定的软件生命周期,识别出项目要进行控制的软件配置项和纳入配置管理的日期。
● 项目经理与项目配置管理员依据项目定义软件过程,共同确定项目的基线,并标识每个基线的配置项。
● 项目经理确认由项目配置管理员制定的在软件生命周期各个阶段配置项的使用权限清单。
● 项目配置管理员按照《配置管理计划模板》制定项目的SCM计划。
● 项目配置管理员根据项目所使用的开发工具确定项目使用的配置管理工具。
● 项目配置管理员根据项目计划的变动,适时调整项目的SCM计划。
具体规程见《项目跟踪与监控过程》计划变更相关步骤。
● 由项目主管主持,项目经理、公司配置管理主管、项目配置管理员、软件工程组、软件相关组参加对配置管理计划书的评审。
具体规程参见《同行评审过程》。
2 按照配置管理计划,进行项目的配置库管理。
● 项目配置管理员规划、建立项目的目录结构。
该结构支持对配置项的存储和检索功能。
● 项目配置管理员根据项目的规模,规划和配置管理工具相关的配置库结构。
● 项目配置管理员依据经项目经理确认的权限清单对目录结构进行权限分配,以达到在相关组之间或配置库内部之间进行共享和传输。
● 项目配置管理员将配置项用配置管理工具统一管理,将软件工作产品存放在指定的服务器的软件基线库中。
● 项目配置管理员保证由软件基线库制造的产品的正确生成。
● 公司配置管理员定期对服务器的软件开发库、软件基线库进行备份,对配置项的归档版本提供存储和恢复功能。
工程变更与设计变更的区别
设计变更;主要由设计师考虑到各种情况,对原有设计进行的变更。
变更设计:由甲方考虑到实际需要,而不是设计师导致的设计缺陷,要求的变更。
差别在于主体不同工程变更是个总称,包括设计变更、施工变更。
设计变更是由设计单位发起,施工变更是由施工单位发起,明白吗?明白后流程也就很清楚了,责任也就清晰了。
你所问的问题我想是指:施工变更与设计变更的区别。
设计变更是工程施工过程中保证设计和施工质量,完善工程设计。
纠正设计错误以及满足现场条件变化而进行的设计修改工作。
包括由建设单位、设计单位、监理单位、施工单位及其它单位提出的设计变更。
一般主要形式有原设计单位出具的设计变更通知单和由施工单位征得由原设计单位同意的设计变更联络单两种。
设计文件一经审查通过,任何单位和个人不得随意更改。
由于项目建设条件的改变或施工实际需要更改原设计,必须经过深入的调查研究并充分论证,还必须遵守项目合同中的全部规定。
业主单位提出的设计变更主要涉及到:已经批准的建设规模、基本原则、主要技术标准、主要功能体系、主要部位,对外部群体景观、主要使用功能和主要施工方案有重大影响,如建筑物整体布局,道路、河涌、管线总体走向或高程,大面积地基处理,大面积路基路面结构,群体建筑立面效果,房屋建筑、桥涵的主要基础型式,设备系统主要工艺及主要参数,主要材料和设备等。
设计单位提出的设计变更,应本着对工程技术、工期、投资等三大控制相结合的原则,对设计过程中的错、漏及优化问题,及时提出变更申请。
对变更理由、内容及相关专业影响等,应从全局考虑并详细说明,按程序报批。
监理单位提出的设计变更,主要是在施工过程中,发现现场情况与设计图纸不符合,或为了减少投资,缩短工期,确保质量和安全生产,更好地推进工程建设,根据规范合理提出变更要求。
施工单位在施工过程中,遇到一些原设计未预料到的具体情况需要进行处理而发生的设计变更。
如工程管道安装过程中遇到未考虑到的设备和管墩在原设计标高处无安装位置,或是由于资源市场的原因,如材料供应或施工条件不成熟需改用其它材料代替等。
工程签证的涵义及内容施工过程中的工程签证,主要是指施工企业就施工图纸、设计变更所确定的工程内容以外,施工图预算或预算定额取费中未含有而施工中又实际发生费用的施工内容所办理的签证,如由于施工条件的变化或无法遇见的情况所引起工程量的变化。
1、由于建设单位原因,未按合同规定的时间和要求提供材料、场地、设备资料等造成施工企业的停工、窝工损失。
2、由于建设单位原因决定工程中途停建、缓建或由于设计变更以及设计错误等造成施工企业的停工、窝工、返工而发生的倒运、人员和机具的调迁等损失。
3、在施工过程中发生的由建设单位造成的停水停电,造成工程不能顺利进行,且时间较长,施工企业又无法安排停工而造成的经济损失。
4、在技措技改工程中,常遇到在施工过程中由于工作面过于狭小、作业超过一定高度,造成需要使用大型机具方可保证工程的顺利进行,施工企业在发生时应及时将现场实际条件和施工方案通告建设单位,并在征得建设单位同意后实施,此时施工企业应办理工程签证。
5、对于检修、维修工程、零星维修项目大都没有正规的施工图纸,往往在检修前由施工企业提出一套检修方案,检修完毕后办理工程签证,然后依据工程签证办理工程结算。
此时工程签证工作尤其重要,直接关系到检修结算工作的顺利进行。