配置管理流程-安内容摘要:

说明;或是由下级申请经上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。 功能基线是最初批准的功能配置标 识。 3. 13 指派基线 ( allocated baseline) 指派基线是指在软件需求分析阶段结束时,经过正式评审和批准的软件需求的规格说明。 指派基线是最初批准的指派配置标识。 3. 14 产品基 线 (product baseline) 产品基线是指在软件组装与系统测试阶段结束时,经过正式评审的批准的有关所开发的软件产品的全部配置项的规格说明。 产品基线是最初批准的产品配置标识。 3. 16 释放 ( release) 释放是指在软件生存周期的各个阶段结束时,由该阶段向下阶段提交该阶段产品 的过程。 它也指将集成与系统测试阶段结束时所获得的最终产品向用户提交的过程。 后面这个过程也中做交付 (delivery)。 软件配置管理 ( Software Configuration Management, SCM) 软件配置管理是对软件修改进行标识、组织和控制的技术,用来协调和控制整个过程。 是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。 配置管理的目标是记录软件产品的演化过程,确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。 配置 ( Configuration) 配置是在技术文档中明确说明并最终组成软件产品的功能或物理属性。 因此配置包括了即将受控的所有产品特性,其内容及相关文档、软件版本、变更文档、软件运行的支持数据,以及其他一切保证软件一致性的组成要素。 配置项 ( Configuration Item, CI) 凡是纳入配置管理范畴的工作成果统称为配置项( Configuration Item, CI),配置项逻辑上组成软件系统的各组成部分,一般是可以单独进行设计、实施和测试的。 5 配置项主要有两大类: 1)属于产品组成部分的工作成果, 例如需求文档、设计文档、源代码、测试用例等; 2)项目管理和机构支撑过程产生的文档。 这些文档虽然不是产品的组成部分,但是值得保存。 每个配置项的主要属性有:名称、标识符、文件状态、版本、作者、日期等。 所有配置项都被保存在配置库里,确保不会混淆、丢失。 配置项及其历史记录反映了软件的演化过程。 基线 ( Baseline) 在配置管理系统中,基线就是一个 CI 或一组 CIS 在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态, 这 些配置项构成了一个相对稳定的逻辑实体,而这个过程被称为“基线化”。 每一个 基线都是其下一步开发的出发点和参考点。 基线确定了元素(配置项)的一个版本,且只确定一个版本。 一般情况下,基线一般在指定的里程碑( Milestone)处创建,并与项目中的里程碑保持同步。 每个基线都将接受配置管理的严格控制,基线中的配置项被“冻结”了,不能再被任何人随意修改,对其的修改将严格按照变更控制要求的过程进行,在一个软件开发阶段结束时,上一个基线加上增加和修改的基线内容形成下一个基线。 基线的主要属性有:名称、标识符、版本、日期等。 通常将交付给客户的基线称为一个“ Release”,为内部开发用的基线则称 为一个“ Build”。 建立基线的好处: 1)重现性:及时返回并重新生成软件系统给定发布版的能力,或者是在项目中的早些时候重新生成开发环境的能力。 当认为更新不稳定或不可信时,基线为团队提供一种取消变更的方法。 2)可追踪性:建立项目工件之间的前后继承关系。 目的是确保设计满足要求、代码实施设计以及用正确代码编译可执行文件。 3)版本隔离:基线为开发工件提供了一个定点和快照,新项目可以从基线提供的定点之中建立。 作为一个单独分支,新项目将与随后对原始项目(在主要分支上)所进行的变更进行隔离。 4. 相关责 任人 项目经理 ( PM, Project Manager)。 项目经理是整个信息系统开发和维护活动的负责人,他批准配置管理的各项活动并控制它们的进程。 其具体工作职责如下: 1. 制定项目的组织结构和配置管理策略; 2. 批准、发布配置管理计划; 3. 决定项目起始基线和软件开发工作里程碑; 配置管理员( CMO, Configuration Management Officer)。 根据配置管理计划执行各项管理任务,定期向 CCB 提交报告,并 参加 CCB 的例会, 6 其具体工作职责如下: 1. 软件配置管理工具的日常 管理与维护; 2. 提交配置管理计划; 3. 各配置项的管理与维护; 4. 执行版本控制和变更控制方案; 5. 完成配置审计并提交报告; 6. 对开发人员进行相关的培训; 7. 识别开发过程中存在的问题并制定解决方案。 软件质量保证员( Software Quality Assurance, SQA) 1. 对配置过程进行监督审计 2. 对配置问题的处理跟踪检查 开发人员( Dev, Developer)。 1. 根据项目组织确定的配置管理计划和相关规定,按照配置管理 流程 完成开发任务。 2. 对产生的基线版本变更提出书面申请。 3. 按照文档、程序、系统、数据库统一命名的规定命名; 4. 每次修改执行“提交” “检出”操作和填写修改信息。 5 实施 流程细则 成立 配置管理小组( CCB) 明确职责 项目立项后 由项目经理负责组织成立 CCB,人员组成 37 人(奇数) ,决策机制为:一般情况下 决策 执行 少数服从多数的原则,特殊情况由项目经理或用户决策。 一般由下列人员组成 : 项目经理 PM; 配置管理员 CMO; SQA; 系统负责人 ;用户代表。 配置控制 小组( CCB, Configuration Control Board) 职责: 负责指导和控制配置管理的各项具体活动的进行,为项目经理的决策提供建议。 其具体工作职责如下 1. 批准配置项的标志,以及软件基线的建立; 2. 制定访问控制策略; 3. 建立、更改基线的设置,审核变更申请; 4. 根据配置管理员的报告决定相应的对策。 确定配置策略 配置策略确定的时机 CCB 成立后,由 CCB 组织会议根据项目的开发计划确定各个里程碑和开发策略,CMO 负责整理确定的项目基线和配置项列表,并在编制《配置管理计划》时列明,按约定的时机 收集配置项和建立初始基线。 配置项的范围 1) 技术文档( Documents):项目开发计划、需求分析报告、软件设计书、质量 7 保证计划、概要设计书、详细设计书、测试文档、技术报告、用户手册、总结报告等; 2) 程序( Program):阶段产品、计算机程序、源程序、释放产品等; 3) 工具( Tools):自动设计工具、开发工具、测试工具、维护工具等; 4) 交互文档( Communications):与客户或项目组内交互产生文档,如会谈记录、Email、会议纪要、 MSN 记录等。 5)管理评审文档 :各 阶段评审报告、变更记录等。 制定配置管理计划 《配置管理计划》的编制 通常情况下,由 CMO 在 项目 设计 合同签订 后,开始编制《配置管理计划》;如有特殊需要,根据合同或项目要求,由 CMO 在项目的某一阶段开始前制定《配置管理计划》。 《配置管理计划》的内容 : 模板见《配置管理计划》模板 《配置管理计划》应包括以下方面的内容: 1) 该项目对配置管理的要求; 2) 实施配置管理的责任人、组织及其职责; 3) 需要开展的配置管理活动及其进度安排; 4) 采用的方法和工具等。 《配置管理计划》由 CCB 负责审批。 配置项标识规则 配置项标识要求 1) 合同有明确标识和追踪要求时,由开发人员按合同要求进行标识,以保证满足合同追踪要求。 2)。
阅读剩余 0%
本站所有文章资讯、展示的图片素材等内容均为注册用户上传(部分报媒/平媒内容转载自网络合作媒体),仅供学习参考。 用户通过本站上传、发布的任何内容的知识产权归属用户或原始著作权人所有。如有侵犯您的版权,请联系我们反馈本站将在三个工作日内改正。