产品基线配置项有哪些

⑴ 软件开发中,LE基线,LA基线,还有SOM分别是什么意思

基线(baseline)——经过正式审查和认可作为以后进一步演进的基础，并且只有通过正式的更改控制规程才能进行更改的规格说明或产品。[IEEE—STD—610]
注：很多资料写为进一步开发的基础，但我觉着演进这个词比较贴切。维基这样定义基线：In configuration management, a "baseline" is an agreed-to description of the attributes of a proct, at a point in time, which serves as a basis for defining change. A "change" is a movement from this baseline state to a next state. The identification of significant changes from the baseline state is the central purpose of baseline identification. 意为：在配置管理中，“基线”是一个被认可的产品属性的描述，这个时间点作为基础服务于定义的变化。“变化”是基线状态移动到下一状态的运动过程。基线识别的中心目的是通过基线状态的显着变化进行的。）
软件基线库(software baseline library)——
用以存放配置项和相应的记录的仓库的内容。基线配置管理(baseline configuration management)——建立经正式审查和认可并作为进一步开发工作的基础的基线。有些软件工作产品，如软件设计和代码，应该有在预定点上建立的基线，并且对这些基线应该施加严格的更改控制过程。当与顾客打交道时，这些基线提供控制和稳定性。
基线管理(baseIine management)——在配置管理中，运用技术和行政指令指定一些文档和对这些文档的更改，这些文档在配置项的生存期内的某些特定时刻，正式标识出和建立起基线。[IEEE—STD—610]

基线的分类

基线分类：按照线性过程开发的软件工作产品分为Allocate、Requirement、Design、Coding、Integration、Test等阶段，可以相应的把基线分为需求基线、设计基线、产品基线等。（注：曾经见过有公司把基线分为十几个类的，感觉实无此必要，徒增繁重的工作，也没有见到管理上有什么优势。以老张的实际经验，分为需求基线和产品/项目基线两类就够用了，无论开发模式是线性或者敏捷、迭代、螺旋，这两类都游刃有余了。

概念漂移”来自数据挖掘，这样说的：概念漂移(concept drift)通常是指隐含内容(hidden context)的改变会或多或少从根本上导致目标概念(target concepts)的改变。真是形象而且精炼啊。

⑵ 阿里云基线要怎么配置啊

打包配置有两种类型，一种是总的配置，作为基线模版。一种是每个热修复发布单中的配置项，成为单项配置。单项配置根据基线模版生成，单项配置可参考以下说明。

• dexpatch 配置说明

• 代码库地址： 构建整包时主工程的git代码库地址

• 分支： 构建整包时的代码分支

• 打包脚本：后台服务器上运行的构建脚本

参考来源：网页链接

⑶ 关于项目管理中配置管理的实现过程，配置项的知识请教以及相比版本管理的差异

你的理解更多是“产品集成”的概念，即怎么把几个产品模块或构件组合成一个产品，但这不是配置管理的概念。
配置管理：简称CM（Configuration Management的缩写），标识、控制和管理变更的一种管理活动。它控制配置项的修改和发行；记录和报告配置项的状态和变更；保证配置项的完整性、一致性和正确性；以及控制配置项的储存、装载和交付。
根据这个定义，配置管理的主要工作包括：
1）配置库的管理活动。配置库现在工具非常多，例如GIT、SVN、CVS、VSS等等。通常会根据开发所处的阶段，设立开发库、受控库与产品库。
2）标识配置项，即需要定义如何去标识配置项。配置管理中受控制的对象被称为配置项，是生命周期中创建的信息，包含程序、数据、文档，分基线配置项和非基线配置项两类。特别是你的产品最终是如何标识的，比如怎样定义V1.0.0的规则。
3）基线的管理。是一组经过正式审查并且达成一致的规范或工作产品，是下一阶段工作的基础。怎样确定、发布基线，怎样管理基本的变更。
4）配置项变更管理。可以根据不同的配置项、不同的开发周期，明确变更的管理规则。
5）配置项状态管理与配置审计 。

而产品集成是如何把一个产品逐步的从一个个模块或组件，最后组合成一个产品的过程。
1）首先产品的技术结构上要能够支持，如果模块不能相互独立和拆解，谈不上灵活的组合。
2）在开发实现上，需要有一个集成的策略，哪些先实现，哪些后实现，哪些可以先进行集成
3）需要建立 集成的环境，使开发好的模块可以在集成环境中进行调试
4）通常开发完成后，需要进行源代码的编译，并打包成一个测试包，然后装在集成环境中，进行调试，以确认各个模块之前是否可以兼容和运转，这时通常会进行测试工作。
5）如果你想进行ABC组合，或者AC组合，那么都需要进行相应的编译、打包（例如形成EXE）过程，然后在集成环境中进行联调和测试。

⑷ 什么是基线配置管理“配置库目录结构”

基线 是 项目一个特定时间的快照，是前一阶段的总结，后一阶段开始的基础。
配置库目录结构 就是存放项目配置项 的原始目录结构。

⑸ 什么是配置项管理

按管理的严格程度，配置项一般分3个等级：
（1）纳入基线管理的配置项
纳入基线管理的配置项是指变化时要走严格变更手续的配置项，需要做变更申请，要审批。审批一般分2种严格程度：
i) 项目经理或分CCB审批就可以，一般是局部的小的变更。
ii）变更控制委员会（CCB）审批
纳入基线前，一般要经过评审或测试（称为验证）和质量保证。
(2) 没有纳入基线但是也不能随意变更的配置项，一般称为受控项
这类配置项不需要变更申请，但是要经过配置管理员或项目经理的允许才可以变更。
基线项与受控项写的权限要唯一，一般是CM或PM有唯一的写权限。
（3）非受控项
对变更不做控制。

拟纳入基线管理的配置项状态变化一般是先非受控，然后受控，最后基线化。变更时，先检出（checkou）进行修改，修改完毕后再检入（checki）转为受控，等待验证（测试或评审），通过验证后进行基线化。

拟纳入受控而不入基线的配置项状态变化一般是先非受控，然后受控。变更时，检出进行修改，修改完毕后再检入提交受控。

纳入基线管理的时机是管理平衡问题，一般是当配置项基本稳定后才纳入基线管理，如果处与频繁的变动之中，纳入基线后会增加管理成本，如单元测试通过后一般不形成基线，因为此时代码并不稳定，但是可以作为受控项，也不能任意变化。这个问题的判断也和项目组的规模有关系，如果规模很大，涉及到的人员很多，也可能需要建立基线。在系统测试后要形成基线，一般称为产品基线，此时系统基本稳定了，可以对外发布，为更多的人所了解和使用了。代码在没有纳入基线但是受控后（提交测试人员测试了），也不能随便变更了，要经过配置管理员的批准，并通知测试人员。

⑹ 常见的软件配置项有哪些

csci是计算机软件配置项(computer
software
configuration
item)简称，在软件设计文档中经常用到。
配置与配置项
在配置管理中，“配置”和“配置项”是重要的概念，“配置”是在技术文档中明确说明并最终组成软件产品的功能或物理属性。因此“配置”包括了即将受控的所
有产品特性，其内容及相关文档，软件版本，变更文档，软件运行的支持数据，以及其他一切保证软件一致性的组成要素，相对与硬件类配置，软件产品的“配置”
包括更多的内容并具有易变性。
受控软件经常被划分为各类配置项（configuraion
items,
cis），这类划分是进行软件配置管理的基础和前提，cis是逻辑上组成软件系统的各组成部分。比如一个软件产品包括几个程序模块，每个
程序模块及其相关文档和支撑数据可能被命名为一个ci。一个系统包括的cis的数目是一个与设计密切相关的问题，关于怎样将一个软件系统划分为不同的
cis将在以下有关章节中阐述，注意如果一个产品同时包括硬件和软件部分，一般一个ci也同时包括软件和硬件部分，一个纯软件的ci通常也称之为软件配置
项（csci）。本规范的ci一般指csci，软硬件的配置管理有一些相通的地方，但因为软件更易于修改，所以软件配置管理是一个更应该系统化的过程。
基线与基线管理
各cis随软件开发活动的进展，会有越来越多的部件进入受控状态。一般地，软件开发过程从概念演绎和需求分析开始，然后是设计，各cscis的编码或写
作，集成测试，最后是用户手册的编写等。软件配置管理包括了在软件生命周期的时间分散点上对各cis进行标识并对对他们的修改进行控制的过程。在一个开发
阶段结束或一组功能开发完成后，要对相应的cis进行基线化并形成各类基线。在配置管理系统中，基线就是一个ci或一组cis在其生命周期的不同时间点上
通过正式评审而进入正式受控的一种状态，而这个过程被称为“基线化”。每一个基线都是其下一步开发的出发点和参考点。
每个基线都将接受配置管理的严格控制，对其的修改将严格按照变更控制要求的过程进行，在一个软件开发阶段结束时，上一个基线加上增加和修改的基线内容形成下一个基线，这就是“基线管理”的过程，因此基线具有以下属性：
通过正式的评审过程建立
基线存在于基线库中，对基线的变更接受更高权限的控制
基线是进一步开发和修改的基准和出发点。
一般地，第一个基线包含了通过评审的软件需求，因此称之为“需求基线”，通过建立这样一个基线，受控的系统需求成为进一步软件开发的出发点，对需求的变更被正式初始化、评估。受控的需求还是对软件进行功能评审的基础。

⑺ 配置管理和变更管理方法

变更常有

所在银行科技部已经建立了比较完善的项目管理体系和质量保障体系，但要应对分行或支行需求变更和相关软件版本配置管理的问题，如果没有一整套的解决措施和工具的支持，就会出现以下问题：

1)分行反映的缺陷更改不能快速响应，不能快速分配缺陷到指定的开发人员，只能依靠口头或文档的传输，缺乏一个整合开发商服务人员、产品经理(或项目经理)、开发团队领导、开发人员、分行领导的信息传递和交流的平台。

2)分行的需求变更不能快速响应。分行的需求变更和软件版本配置只能依靠手工备份，因而，自身不能快速有效地管理各系统的版本，缺乏版本基线的管理策略。

针对以上问题，可以考虑采用软件配置管理这一关键域的思路系统地解决以上问题。配置管理是整个集成软件项目正常运作的一个管理支撑平台，其目的就是将有关该项目的客户、客户服务人员、产品经理(或项目经理)、开发团队领导、开发人员、高层领导等项目干系人的工作协同起来，实现高效的沟通，及时地共享工作成果。

配置管理的基本功能包括配置标识、变更控制、配置状态发布和配置审计。变更控制是配置管理的重要内容，其目的是为了在动态中保证配置项的完整性、一致性和可回溯性，保证配置项的变更过程规范、受控、有完整记录，受影响的各方均能及时了解情况，并协调一致。

控制不可少

变更控制是通过创建产品基线，在产品的整个生存周期中控制它的发布和变更。配置控制指在配置项标识正式确定之后，对配置项特别是对已提交的代码、相关文档和数据等的变更进行系统地跟踪和控制的过程，主要包括变更的'提出、确定配置项的控制等级、变更的评价、变更的处置、实施经批准的变更、对变更进行验证和结束变更。变更控制的目的是建立一套控制软件修改的机制，保证生产符合质量标准的软件和保证每个版本的软件包含所有必需的元素及工作在同一版本中的各元素中可以正常工作，以确定在变更控制过程中控制什么，如何控制，谁控制变更、何时接收变更、批准和检验。

配置项级别

1)已基线化的配置项是指已完成该配置项的审核和批准，并且成为创建或修改其他配置项的输入。例如：一个设计文档已审核、通过、签发，并且成为编码活动的基础。

2)受管理和受控的配置项是指已提交审核，但还没有批准通过的配置项。例如：一个正在进行审核的设计文档。

3)受控的配置项指已置于版本控制，但项目组不能直接进行改动的配置项。例如：用户提供的软件、购买的工具、产品标准等等。

变更请求的状态

软件变更、软件优化和软件bug都是产生变更的原因。变更申请人(用户或产品经理)提出变更时，首先要对受控的配置项的修改提出一个变更请求，说明对软件变更的需求。这是因为变更控制过程是通过变更请求的流动来实现的，而且对软件的任何请求都必须和相应的变更请求对应。

变更请求的状态包括：

1)提交：变更请求提交给配置管理员;

2)拒绝：变更控制委员会拒绝变更请求;

3)接受：变更控制委员会接受变更请求;

4)挂起：变更请求被挂起，以后再作决定;

5)已验证：更改已执行和验证;

6)关闭：验证并归档配置项，更新的配置项提交给用户(例如：通过版本发布)。

变更请求的类型

1)增强型：变更请求要求对已批准的项目功能进行增强。

2)改进型：变更请求不会造成功能更改，但使配置项的维护更加有效率。

3)纠错型：变更请求对错误进行修正(诸如bug)。

变更请求的优先级

在评价变更请求的优先级时，要对请求变更的配置项进行系统的分析，确定变更影响范围和修改的程度，确定变更的级别，为确定是否有必要记录变更提供参考依据。变更请求的优先级可分为三类：

1)高：严重地影响一些用户或许多用户。

2)中：对用户造成不方便，或是可以采取相应的变通方法处理的主要问题。

3)低：小问题。

修改完后签入(Check in)

对变更的处理，要按照变更控制规程，将变更请求及其相关附件提交软件配置控制委员会审批。配置管理组根据审批意见处理变更请求。

只有配置管理员具有Check in权限。在进行Check in之前，确认下面的事项：

1)所有对配置项所做的修改被批准;

2)所有的更改都经过审核或验证;

3)所对应的变更请求已经被保存起来;

4)所有相关的审核记录被保存;

5)Check in时须注明Check in因，如对应的变更请求。

从数据库中签出(Check out)

1)对于文档，配置管理员在更改审批人同意后，从配置库中Check out配置项，发给项目组成员修改。

2)Check out时须注明Check out原因，如将要修改的问题。

3) 配置管理员一定要在配置状态发布中跟踪被Check out出来的配置项。

⑻ 基线的计算机类

基线(Baseline)，基线是软件文档或源码(或其它产出物)的一个稳定版本，它是进一步开发的基础。所以，当基线形成后，项目负责SCM的人需要通知相关人员基线已经形成，并且哪儿可以找到这基线的版本。这个过程可被认为内部的发布。至于对外的正式发布，更是应当从基线了的版本中发。
基线是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。
参与项目的开发人员将基线所代表的各版本的目录和文件填入他们的工作区。随着工作的进展，基线将合并自从上次建立基线以来开发人员已经交付的工作。变更一旦并入基线，开发人员就采用新的基线，以与项目中的变更保持同步。调整基线将把集成工作区中的文件并入开发工作区。 建立基线的三大原因是：重现性、可追踪性和报告。
重现性是指及时返回并重新生成软件系统给定发布版的能力，或者是在项目中的早些时候重新生成开发环境的能力。可追踪性建立项目工件之间的前后继承关系。其目的在于确保设计满足要求、代码实施设计以及用正确代码编译可执行文件。报告来源于一个基线内容同另一个基线内容的比较。基线比较有助于调试并生成发布说明。
建立基线后，需要标注所有组成构件和基线，以便能够对其进行识别和重新建立。 建立基线有以下几个优点：
基线为开发工件提供了一个定点和快照。
新项目可以从基线提供的定点之中建立。作为一个单独分支，新项目将与随后对原始项目（在主要分支上）所进行的变更进行隔离。
各开发人员可以将建有基线的构件作为他在隔离的私有工作区中进行更新的基础。
当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。
可以利用基线重新建立基于某个特定发布版本的配置，这样也可以重现已报告的错误。 定期建立基线以确保各开发人员的工作保持同步。但是，在项目过程中，应该在每次迭代结束点（次要里程碑），以及与生命周期各阶段结束点相关联的主要里程碑处定期建立基线：
生命周期目标里程碑（先启阶段）
生命周期构架里程碑（精化阶段）
初始操作性能里程碑（构建阶段）
产品发布里程碑（产品化阶段） 第一次提出的软件配置项就构成基线配置项。基线分类列表如下：
–系统功能说明。系统模型，项目计划，进度安排，系统需求规格说明书，系统架构设计说明书；
–软件需求规格说明。包括：软件需求规格说明书，图形分析模型、过程、原型、数学规格说明；
–设计规格说明。包括：数据设计、软件结构设计、界面设计、对象的描述等；验收规格说明；
–测试规格说明。包括：测试计划、测试用例、测试预期结果、测试记录、测试报告等；
–数据库描述。包括：数据模式、记录结构、数据项描述；
–模块规格说明。包括：模块功能、模块算法、模块接口等描述；
–运行系统。包括：模块代码、链接模块、数据库、支持及工具程序等；
–用户文档。包括：安装说明、操作说明、用户手册等；培训计划；维护文档，包括：故障报告、维护手册、更改记录等；
–项目采用的有关标准和规程。

⑼ 基线是什么

基线【base line】指的是在三角网测量中，经精确测定长度的直线段。
政治地理:
1.基线：又称领海基线，是陆地和内水同领海的分界线，是划定领海、毗连区、专属经济区和大陆架宽度的起算线。
???
2.基线——经流动相冲洗，柱与流动相达到平衡后，检测器测出一段时间的流出曲线。一般应平行于时间轴。
计算机类
基线(Baseline)，基线是软件文档或源码(或其它产出物)的一个稳定版本,它是进一步开发的基础.所以,当基线形成后,项目负责SCM的人需要通知相关人员基线已经形成,并且哪儿可以找到这基线了的版本.这个过程可被认为内部的发布.至于对外的正式发布,更是应当从基线了的版本中发布.
基线是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。
参与项目的开发人员将基线所代表的各版本的目录和文件填入他们的工作区。随着工作的进展，基线将合并自从上次建立基线以来开发人员已经交付的工作。变更一旦并入基线，开发人员就采用新的基线，以与项目中的变更保持同步。调整基线将把集成工作区中的文件并入开发工作区。
建立基线的三大原因是：重现性、可追踪性和报告。
重现性是指及时返回并重新生成软件系统给定发布版的能力，或者是在项目中的早些时候重新生成开发环境的能力。可追踪性建立项目工件之间的前后继承关系。其目的在于确保设计满足要求、代码实施设计以及用正确代码编译可执行文件。报告来源于一个基线内容同另一个基线内容的比较。基线比较有助于调试并生成发布说明。
建立基线后，需要标注所有组成构件和基线，以便能够对其进行识别和重新建立。
建立基线有以下几个优点：
基线为开发工件提供了一个定点和快照。
新项目可以从基线提供的定点之中建立。作为一个单独分支，新项目将与随后对原始项目（在主要分支上）所进行的变更进行隔离。
各开发人员可以将建有基线的构件作为他在隔离的私有工作区中进行更新的基础。
当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。
您可以利用基线重新建立基于某个特定发布版本的配置，这样也可以重现已报告的错误。
使用
定期建立基线以确保各开发人员的工作保持同步。但是，在项目过程中，应该在每次迭代结束点（次要里程碑），以及与生命周期各阶段结束点相关联的主要里程碑处定期建立基线：
生命周期目标里程碑（先启阶段）
生命周期构架里程碑（精化阶段）
初始操作性能里程碑（构建阶段）
产品发布里程碑（产品化阶段）
软件工程:
什么是基线？第一次提出的软件配置项就构成基线配置项。基线分类列表如下：
–系统功能说明。系统模型，项目计划，进度安排；
–软件需求规格说明。包括：图形分析模型、过程、原型、数学规格说明；
–设计规格说明。包括：数据设计、体系结构设计、界面设计、对象的描述等；验收规格说明；
–测试规格说明。包括：测试计划、测试用例、测试预期结果、测试记录等；
–数据库描述。包括：数据模式、记录结构、数据项描述；
–模块规格说明。包括：模块功能、模块算法、模块接口等描述；
–运行系统。包括：模块代码、链接模块、数据库、支持及工具程序等；
–用户文档。包括：安装说明、操作说明、用户手册等；培训计划；维护文档，包括：故障报告、维护要求、更改记录等；
–项目采用的有关标准和规程。
字体、排版:
基线(Baseline)是大部分字母所“坐”在的，字体的下降部之上的直线。下图红色的直线就是基线。

[英文排版术语]
英文排版术语

色谱：
基线是检测器在没有进样时信号随时间的变化曲线,一般为噪音随时间的变化曲线,正常情况下在灵敏度不是很高时为一平直的线.