Ⅰ 软件配置管理过程包括哪些活动
创建配置管理计划、创建配置库、基线管理、版本控制、发布管理、配置库审计、日常维护和监管。
Ⅱ 基线（配置管理）
基线”是一个很常见的术语，在配置管理和项目管理里面都能看到，而且还有很多衍生的术语，例如基线提升、基线化、基线审计，等等等等。 我个人以前对微软的那套开发流程（就是proct cycle model）以及PSP、TSP了解比较多一些，这些流程里面对“基线”的概念提的不多。但接触RUP、MSF以及项目管理以后，看到到处都有baseline，就觉得迷惑了。 经过我自己的理解，以及和几个同事的讨论，现在我觉得我们通常看到的“基线”这个术语有两个意思： 1）代表多个源代码文件的一组版本。 比如有三个文件，aaa.c、bbb.c和ccc.h。可以对这三个文件做一个基线，取aaa.c的版本1.1，取bbb.c的版本1.3，取ccc.h的版本1.0。(1.1,1.3,1.0)就是一个基线。换句话说，通常在vss和cvs里面做label，就是在做基线。 这种基线对“构建审计”特别有用：在做build的时候，可以先对所有源文件做一个label，取名为"Build2394"，然后再编译、集成。这样，以后如果要找到和build 2394对应的原文件，只需要到vss或者cvs里面把所有文件对应label Build2394的版本取回来就可以了。 2）代表文档的一个稳定状态。 比如有一个项目设计文档，当设计基本完成，开发即将开始的时候，需要把这个文档固定下来，内容不能再频繁改变，否则开发人员就无所适从了，可能导致每个人所参照的文档并不是同一个文档。用一句上海这里的生活用语来说，就叫做要把这个文档“敲定”。 一个文档如果经过讨论被通过了，被固定了，就可以说这个文档被“基线化”了，然后所有人就可以在这个“基线”的基础上工作。 当然，文档不可能一成不变，所以当对文档的修改仍然会不断进行，但这种修改并不会随时随地的添加到被“基线化”了的文档中去。因为既然是“基线”，就不能随便动。 但是到了一定时候，修改积累到一定程度，就需要把很多修改合并到原来的文档中去了，并生成一个新版本的文档作为团队中所有的人的参考标准，并把老的版本淘汰掉。这就叫做“基线提升”。 以上就是我个人对“基线”这个术语的两种不同含义的理解，大家可以讨论讨论看，是不是差不多就是这个意思。
Ⅲ 配置管理流程
制定配置管理计划
配置管理员制定《配置管理计划》，主要内容包括配置管理软硬件资源、配置项计划、基线计划、交付计划、备份计划等。CCB审批该计划。
配置库管理
配置管理员为项目创建配置库，并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。配置管理员定期维护配置库，例如清除垃圾文件、备份配置库等。
版本控制
在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于不能保证新版本一定比老版本“好”，所以不能抛弃老版本。版本控制的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。
配置项的状态有三种：“草稿”、“正式发布”和“正在修改”，本规程制定了配置项状态变迁与版本号的规则。
变更控制
在项目开发过程中，配置项发生变更几乎是不可避免的。变更控制的目的就是为了防止配置项被随意修改而导致混乱。
修改处于“草稿”状态的配置项不算是“变更”，无需CCB的批准，修改者按照版本控制规则执行即可。
当配置项的状态成为“正式发布”，或者被“冻结”后，此时任何人都不能随意修改，必须依据“申请→审批→执行变更→再评审→结束”的规则执行。
配置审计
为了保证所有人员（包括项目成员、配置管理员和CCB）都遵守配置管理规范，质量保证人员要定期审计配置管理工作。配置审计是一种“过程质量检查”活动，是质量保证人员的工作职责之一。
Ⅳ 管理配置的基本操作有哪些三种
管理配置的基本操作有这三种：1.事前控制、2.即时控制、3..事后控制。
事前控制是指一个组织，在一项活动正式开始之前所进行的管理上的努力。
即时控制是在某项活动或工作过程中进行的控制。
事后控制即发生在行动或任务终了之后的控制。
制定配置管理计划
配置管理员制定《配置管理计划》，主要内容包括配置管理软硬件资源、配置项计划、基线计划、交付计划、备份计划等。CCB审批该计划。
配置库管理
配置管理员为项目创建配置库，并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。配置管理员定期维护配置库，例如清除垃圾文件、备份配置库等。
Ⅳ 软件开发中,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)的改变。真是形象而且精炼啊。
Ⅵ 管理员应在什么时候建立网络基线
建立网络基线，前期准备工作包括以下几个部份：
1) 网络拓扑结构图：在结构图里，要力求完整展示网络的物理结构，详细标识出网络中路由器、交换机、防火墙、服务器类型、管理设备的位置；甚至数据流向等；
2) 了解网络现有的管理策略，网络配置情况，对哪些服务、访问做了优化和管理；
3) 掌握确定网络的繁忙时段、业务高峰时段、空闲时段等；
4) 将上述3点形成翔实的文档。 确定范围和目标 建立网络基线最重要的就是要确定基线的范围和目标（基线参数）。网络是复杂的，我们不可能也很难将所有设备、主机或链路的信息全部加入到基线里来，这就需要管理者按其重要程度对网络进行划分，然后确定建立基线的范围； 而且不同的设备、主机或链路所关注的参数也不尽相同，比如服务器更多的是关注安全和性能，网络则是流量、利用率等，这些都需要管理员在录入基线数据之前就确定好。
Ⅶ 软件配置管理的过程描述
一个软件研发项目一般可以划分为三个阶段：计划阶段、开发阶段和维护阶段。然而从软件配置管理的角度来看，后两个阶段所涉及的活动是一致，所以就把它们合二为一，成为“项目开发和维护”阶段。 一个项目设立之初PM首先需要制定整个项??研发计划之后，软件配置管理的活动就可以展开了，因为如果不在项目开始之初制定软件配置管理计划，那么软件配置管理的许多关键活动就无法及时有效的进行，而它的直接后果就是造成了项目开发状况的混乱并注定软件配置管理活动成为一种“救火”的行为。所以及时制定一份软件配置管理计划在一定程度上是项目成功的重要保证。
在软件配置管理计划的制定过程中，它的主要流程应该是这样的：
CCB根据项目的开发计划确定各个里程碑和开发策略；
CMO根据CCB的规划，制定详细的配置管理计划，交CCB审核；
CCB通过配置管理计划后交项目经理批准，发布实施。 这一阶段是项目研发的主要阶段。在这一阶段中，软件配置管理活动主要分为三个层面：
⑴主要由CMO完成的管理和维护工作；
⑵由SIO和DEV具体执行软件配置管理策略；
⑶变更流程。这三个层面是彼此之间既独立又互相联系的有机的整体。
在这个软件配置管理过程中，它的核心流程应该是这样的：
⑴CCB设定研发活动的初始基线；
⑵CMO根据软件配置管理规划设立配置库和工作空间，为执行软件配置管理计划做好准备；
⑶开发人员按照统一的软件配置管理策略，根据获得的授权的资源进行项目的研发工作；
⑷SIO按照项目的进度集成组内开发人员的工作成果，并构建系统，推进版本的演进；
⑸CCB根据项目的进展情况，审核各种变更请求，并适时的划定新的基线，保证开发和维护工作有序的进行。
这个流程就是如此循环往复，直到项目的结束。当然，在上述的核心过程之外，还涉及其他一些相关的活动和操作流程，下面按不同的角色分工予以列出：
各开发人员按照项目经理发布的开发策略或模型进行工作；
SIO负责将各分项目的工作成果归并至集成分支，供测试或发布；
SIO可向CCB提出设立基线的要求，经批准后由CMO执行；
CMO定期向项目经理和CCB提交审计报告，并在CCB例会中报告项目在软件过程中可能存在的问题和改进方案；
在基线生效后，一切对基线和基线之前的开发成果的变更必须经CCB的批准；
CCB定期举行例会，根据成员所掌握的情况、CMO的报告和开发人员的请求，对配置管理计划作出修改，并向项目经理负责。
综上所述，配置管理的工作流程如图1所示：
Ⅷ CMMI中的的配置管理是什么
配置管理是CMMI模型中一个支撑过程域。
配置管理是指：应用技术和管理手段来识别和记录配置项的功能和物理特性，控制其变更，记录和报告变更的过程和实现状态，并检查与项目需求之间的符合度；通过配置管理可以有效的管理工作产品与工作产品之间的一致性，合理的控制和实施变更以维护对项目范围与边界条件的一致的理解。
一般CM过程描述了配置管理活动的内容、规范和方法，以建立和维护软件开发过程中各种产品的完整性和一致性。
CM使用到以下几个重要的术语：
配置项：处于配置管理之下的软件或/和硬件的集合体。这个集合体在配置管理过程中作为一个实体出现。
基线： 已经通过正式复审和批准的某规约或产品，它因此可以作为进一步开发的基础，并且只能通过正式变更控制过程来改变；基线有一组配置组成，这些配置构成了一个相对稳定的状态，不能再被任何人随意修改。
配置标识：识别产品的结构、产品的构件及其类型，为其分配唯一的标识符，并以某种形式提供对它们的存取。
控制：通过建立产品基线，控制软件产品的发布和在整个软件生命周期中对软件产品的修改。
状态统计：记录并报告构件和修改请求的状态，并收集关于产品构件的重要统计信息。
配置审计：通过第三方（例如：软件质量保证工程师）来确认产品的完整性并维护构件间的一致性，即确保产品是一个严格定义的构件集合；
配置管理员：根据本过程的规定，在本公司内部具体实施与操作本过程的人员/角色。根据实施的层级的不同，配置管理员可以区分为“产品配置管理员”和“项目配置管理员”两个角色，一般产品配置管理员是专职的，项目配置管理员有项目成员兼职。
Ⅸ 配置管理中的配置基线如何理解
论坛专家长河观点：基线，baseline，就是基准的意思，但如何记录这个事实上的基准呢，就是打一个快照，然后，定义这个快照为某个状态的基线