《软件配置管理全解ppt课件.ppt》由会员分享，可在线阅读，更多相关《软件配置管理全解ppt课件.ppt（55页珍藏版）》请在三一办公上搜索。
1、软件配置管理,软件配置管理,CMMI对应实践配置管理基本概念配置管理活动产品发布流程配置管理工具介绍,配置管理（CM）,目的：通过配置标识、配置控制、配置状态报告和配置审计等活动，建立和维护工作产品的完整性。工作产品包括：提交给客户的产品，指定的内部工作产品，获得的产品、工具，以及被用于构建和描述这些工作产品的其他项。借助于配置管理系统的配置控制、变更管理和配置审计功能，使基线变更和工作产品发布得到监督和控制。,CM（一）,SG 1 Establish Baselines（建立基线），建立已识别工作产品的基线。SP1.1 Identify Configuration Items（识别配置项），
2、标识将要置于配置管理之下的配置项、组件和相关的工作产品。SP1.2 Establish a Configuration Management System（建立配置管理系统），建立和维护配置管理和变更管理系统，控制工作产品的完整性。SP1.3 Create or Release Baselines（建立或发布基线），创建或者发布基线，供内部使用或提交给客户。,CM（二）,SG 2 Track and Control Changes（跟踪并控制变更），跟踪和控制配置管理下工作产品的变更。SP2.1 Track Change Requests（跟踪变更申请），变更申请不只是关于新的或变更的工作产品
3、，还包括工作产品中的错误及缺陷。SP2.2 Control Configuration Items（控制配置项），主要是控制配置项的变更，一般会形成配置项的修订历史和基线的存档两种工作产品。,CM（三）,SG 3 Establish Integrity（建立完整性），建立和维护基线的完整性。SP3.1 Establish Configuration Management Records（建立配置管理记录），建立和维护描述配置项的记录。SP3.2 Perform Configuration Audits（实施配置审计），执行配置审计以维护配置基线的完整性。,第八章 软件配置管理,CMMI对应实践
4、配置管理基本概念配置管理活动产品发布流程配置管理工具介绍,配置管理定义,配置管理：包含版本控制、工作空间管理、并行开发控制、过程管理、权限管理、变更管理等内容。 软件配置管理：是在贯穿整个软件生命周期中建立和维护项目产品的完整性目标：软件配置管理的各项工作是有计划进行的；被选择的项目产品得到识别，控制并且可以被相关人员获取；已识别出的项目产品的更改得到控制；使相关组和个人及时了解软件基准的状态和内容。,存放配置项的数据库，常用两种形式：按配置项类型分类建库和按任务建库。按配置项的类型分类建库：适用于通用的应用软件开发机构。产品的继承性较强，工具比较统一，对并行开发有一定需求使用这样的库结构有利
5、于对配置项的统一管理和控制能提高编译和发布的效率。这样的库结构并不是面向各个开发团队的开发任务的，所以可能会造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦。,概念配置库,按任务建立相应的配置库适用于专业软件的研发机构，使用的开发工具种类繁多，开发模式以线性发展为主，没有必要把配置项严格的分类存储，人为增加目录的复杂性。特别是对于研发性的软件机构来说，还是采用这种设置策略比较灵活。配置库的日常工作：主要保证配置库的安全性，如：对配置库的定期备份、清除无用的文件和版本、检测并改进配置库的性能等。,概念配置库（续）,在项目开发过程中，配置库可分开发区、受控区和测试区三个区域，其各自存放的内
6、容及存取的规定为：开发区：开发区存放项目组所遵循的过程标准、参考资料、所有未经批准的配置项、已经批准但未纳入基线的配置项，此区域中的配置项由项目经理负责和控制，项目总结结束后删除。 受控区：受控区存放基线。此区域的配置项由项目经理或CCB评审批准后，由配置管理员从开发区更新而来，此区属配置管理员所有。测试区：该区仅为临时区，不作详细规定，测试通过后需删除该区。测试内容也可由配置管理员从受控区获取（get latest）到指定的路径进行测试。,概念配置库（续）,配置库使用建议流程图,软件工程师按如下原则使用配置库：只能访问开发区。在添加配置项后，按公司版本的约定打标识，给定一个初始版本；签入/签
7、出不需要更新标识；当工作产品完成之后，签入后，按公司版本约定打标识；如果需要再修改，则签出；修改完成后签入，三级或四级版本号加一，按打上面版本约定打标识依次类推，直到该配置项完全定稿。,配置库建议使用原则,配置管理员按如下原则使用配置库：拥有配置库的全部权限，建立配置库并分配操作权限；把评审通过的配置项根据评审后确定的版本，打上版本标识；根据审计过的版本控制表生成基线，从开发区把配置项移到受控区；之后，锁定该版本的工作产品；负责配置库的日常维护及备份；发布时定期或事件驱动从配置库生成配置状态报告。,配置库建议使用原则（续）,测试工程师按如下原则使用配置库：测试工程除了对测试区域及公共区域有权限
8、外，其他区域均无操作权限；当一个系统/变更测试通过之后，通知配置管理员，由配置管理员根据测试结果对相关配置项打标识。,配置库建议使用原则（续）,基线，由一个或若干个通过（正式）评审并得到确认的配置项组成，是项目进入下一个生命周期阶段的出发点（或基准）。 基线是软件文档或源码(或其它产出物)的一个稳定版本，它是进一步开发的基础，只有经过授权后才能变更。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。,概念基线,建立基线的原因：重现性：及时重新生成软件系统给定发布版本的能力，重新生成开发环境。可追踪性：建立项目工作产品之间的前后继承关系，确保设计满足要求、代码满足
9、设计及用正确的代码编译系统。报告：来源于基线之间内容的比较，有助于调试并生成发布说明。,概念基线（续）,建立基线的优点：为开发工作提供了一个定点和快照。新项目可以从基线提供的定点建立，作为一个单独分支，新项目将与随后对原始项目所进行的变更进行隔离。各开发人员可以将建有基线的工作产品作为他在隔离的私有工作区中进行更新的基础。当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。,概念基线（续）,常用的基线：需求基线（SRS_BL）：在需求分析阶段结束后，用户需求说明书、软件需求规格说明书经过了评审。计划基线（PLN_BL）：详细计划经过评审。设计基线（DESIN_BL）：在概要设计和详细
10、设计阶段结束后，设计阶段工作产品经过了评审。实现基线（CODE_BL）：代码和集成测试计划、用例、报告等工作产品经过了评审 。测试基线（TEST_BL）：系统测试计划、用例、报告等工作产品经过了评审。发布基线（RELEASE_BL）：通过软件系统验收测试与正式的配置审核，产生了作为最终产品交付用户的配置项的集合。,概念基线（续）,工作空间为开发人员提供独立的工作空间。工作空间是被设计用来防止用户之间的相互干扰。在企业里，一般对每个人的工作空间可以建立如下约定：开发人员在项目结束后在本地机器删除所有项目资料；严格按照开发环境的描述安装相关软件，搭建自已的工作平台；及时备份半成品，在开始修改配置项
11、之后检查当前配置项状态/版本号；不随意安装未经过批准的软件。,概念工作空间,对于大型的软件开发项目，无控制的变更将迅速导致混乱，使整个项目无法顺利进行下去而失败。变更控制就是通过结合人为的规程和自动化工具，以提供一个变化控制的机制。 变更控制的对象主要指配置库中的各基线配置项 变更管理的一般流程是：由开发人员或系统分析人员提出变更需求；由CCB（变更控制委员会）或项目经理审核并决定是否批准；配置管理员根据CCB或项目经理 的决定开放相应的权限，并形成记录备案；变更申请人员执行相应的变更。,概念变更控制,第八章 软件配置管理,CMMI对应实践配置管理基本概念配置管理活动产品发布流程配置管理工具介
12、绍,配置管理方针,项目组软件配置管理应有专人负责（称配置管理员）；中小型项目，由项目经理或指定专人担任配置管理员，负责项目配置管理。大规模项目，应建立配置管理小组（CM组），在项目经理领导或授权下负责项目配置管理。配置管理贯穿软件生命周期全过程，但分两个阶段：从需求到产品发布的开发阶段，配置管理由项目经理或指定专人负责；发布后进入产品维护阶段，由负责该产品技术支持部门指定的配置管理员负责。在整个开发阶段，各类工作产品（配置项）及其变更是项目配置管理的重点；而开发环境、测试环境和运行环境的描述文档则只作为配置项纳入配置管理，受到控制。在产品维护阶段，配置管理的重点则包括变更控制、版本控制和基线管
13、理。,项目启动后就应开始配置管理活动，包括：定义、标识配置项，定义基线，建立配置库和基线库，确定访问权限，控制配置库/基线库的签出（Check out）和签入（Check in）。在项目计划阶段，应编写配置管理计划（CM计划），与项目开发计划一起提交评审；在产品发布后进入维护阶段，也应编写CM计划。按评审确认的CM计划建立基线、审计配置库和基线，及时报告配置状态。每一个产品的所有配置项的变更均应得到管理和控制。 （每一个项目组的）软件产品最终集成（产品发布基线，或产品发布后的产品维护阶段定期生成的基线），由项目配置管理员负责实施，技术支持的配置管理员负责监督。,配置管理方针（续）,配置管理流程
14、图,代码类配置项（源代码、可执行代码以及相关的数据文件）的划分由项目组结合项目具体情况确定（例如，一个单元或模块的代码作为一个配置项），代码类配置项的命名必须结合软件产品的特征，而版本编号则应符合机构统一规定。开发环境、测试环境和运行环境描述，单独成文，并作为单独的配置项进行管理。文档类配置项，比如：需求类文档、计划类文档、设计类文档、测试用例/方案文档、测试报告、用户手册等。实际执行时项目组应遵照机构标准并结合项目具体情况加以适当裁剪。,配置项分类,配置项识别的参考标准：可能被两个或两个以上组使用的工作产品；无论是因为错误还是因为需求变更而导致变更的工作产品；工作产品相关依赖，其中一个变更会
15、导致另外一个变更；对项目非常重要的工作产品（环境类文档应当属于这一类）。机构应制定如下配置项标识命名规则：文档类配置项命名规则，文档版本编号规则，代码类配置项命名规则，单元（模块）源代码和执行码版本编号规则。,配置项识别及标识,编制配置管理计划,配置管理计划的形成时间：项目计划初步阶段形成草稿，项目计划细化阶段定稿，并与项目开发计划一起评审。根据机构标准软件过程中的列表，识别本项目中的配置项，并作为配置管理计划的一部分。在项目经理的指导下，配置管理员完成配置管理计划。,明确各类基线包含的工作产品及建立的时间、标识等。需求基线（SRS_BL）:在软件需求规格说明书批准时建立；计划基线（PLN_B
16、L）:在项目计划批准时建立；设计基线（DESIN_BL）:在概要设计、详细设计和数据库设计批准时建立；编码基线（CODE_BL）:在单元测试通过时为集成测试建立；测试基线（TEST_BL）:在集成测试时通过为系统测试建立；产品基线（RELEASE_BL）:在系统测试通过为产品发布时建立,配置管理计划定义基线,在项目计划初步阶段，必须明确与需求相关的配置项及基线生成时间，配置库结构及权限。确定职责和所需资源；确定软件项目配置项；确定基线条数、基线包含配置项、建立时间、审计人；确定要执行的活动及活动的进度安排。明确配置库目录及存取权限/方式；确定系统的开发环境、测试环境、运行环境；配置库的备份方式
17、。,配置管理计划文档化,配置管理审计,配置管理的审计活动一般分为两类，一是对基线的审计，二是对配置库的审计。基线审计是为了检查基线的正确性及一致性；配置库审计是为了保证配置库的完整性、可用性。基线审计一般按下面步骤进行：项目经理在基线生成之前填写基线计划及跟踪表；由指定专人根据基线计划及跟踪表对配置库进行审计；审计出的问题修改之后，由CCB批准后，配置管理员生成基线，并打基线标识。,在里程碑处或基线生成之后进行；由配置管理员或项目经理指定负责人对配置库进行审计，填写配置审计报告；主要内容包括：配置库结构是否正确，是否能正常签入签出；基线库的建立手续是否齐全；配置项版本历史信息是否正确；质量保证
18、工程师根据相关规程对配置管理过程进行审计，填写QA阶段审计报告中的“QA配置管理过程审计报告”，在确保配置管理活动按照要求开展。,配置管理审计,变更控制简述,变更控制做为配置管理的主要内容之一，在操作过程中有严格的控制流程，以保证配置项的一致性、有效性。一般变更控制的内容为：确定变更批准人的责任范围和权限；建立变更控制流程，实施变更控制；对配置项变更进行管理；对基线变更进行管理；设立两个变更授权机构：CCB、项目经理；CCB成员为项目级的，可因项目的不同而有所不同，由总工程师在项目任务书中定义。,变更控制流程图,在项目立项时，根据项目规模和特点，确定变更授权机构及其职责，并纳入立项报告及计划阶
19、段的配置管理计划；确定变更等级：变更等级一般由项目经理判断，并在配置管理计划中描述各自控制的变更，建议若是影响需求基线和产品基线的变更以及严重影响项目进度、成本、产品质量的重大变更提交CCB控制；其他变更（如：文字编辑、格式调整）由项目经理控制。,变更控制活动,对评审定稿配置项（简称受控项，代码类指通过集成测试之后）和基线（有重大缺陷）的所有变更在实施前均要通过变更授权机构的评审和批准；变更过程必须记录在配置项变更申请表。变更控制流程适用于开发过程中所有配置项变更，非以上提到的项可不填写配置项变更申请表，但需在修订页中说明。对于受控项，不论是项目经理还是CCB控制变更，其提请变更的流程相同，配
20、置管理员只负责受控项标识更新和配置项变更状态报告的填写，不参与其它活动；所有配置项变更申请表由项目经理负责提交配置管理员纳入受控库；配置管理员提交配置项变更记录给相关受影响人员。,变更控制要求,变更控制流程,变更申请人填写配置项变更申请表说明问题来源或修改原因；变更对其他配置项的影响，估计变更对项目造成的影响等。对于代码类变更，可以记录在BUG管理工具里，而不填写专门的配置项变更申请表，但在项目经理分配BUG时，必须分析变更所需花费的工时、工作量、成本及变更带来的风险，并填写在BUG管理工具中。如果代码类变更，对里程碑有影响，则必须填写配置项变更申请表。项目经理收到变更申请后，评估变更带来的影
21、响、分析变更所需花费的工时、工作量、成本及变更带来的风险等，并将评估结果应写入“审批意见”栏；然后提交变更授权机构（比如，CCB），若是不需要通过CCB的变更申请，则项目经理签署意见之后，即可执行变更。,变更控制人判断变更的大小采取合适的评审方式：签字或评审。若采取签字方式，变更控制人在变更控制栏填写审核意见，若采取评审方式，遵照评审规程执行；然后顺次执行以下步骤如果变更被拒绝申请，项目经理通知变更申请人，由项目经理提交配置管理员入库，变更结束；如果变更被批准，项目经理负责通知受影响的人员更改相关配置项，并指定项目组成员实施变更。修改人根据被批准的配置项变更申请表，根据标识规则从开发区里Che
22、ck out配置项实施变更；修改完后Check in并进行标识，在配置项变更申请表中进行变更描述，必要时可用附件。,变更控制流程（续）,文档类对象，由验证人验证修改结果并更新配置项变更申请表的状态（已更改），由配置管理员更新配置项变更状态报告，并在开发区处更新配置项标识；基线变更，由项目经理填写版本控制表，审计人员审计通过并CCB签字批准，交配置管理员生成基线；变更实施且被质量保证工程师验证签字后，由项目经理抄送相关人员（包括研发部经理、测试人员、文档人员、配置管理员、质量保证工程师等）并将配置项变更表交给配置管理员纳入CM库，同时更新配置项计划表中配置项状态，填写配置项计划表中配置项变更记录
23、。,变更控制流程（续）,产品构造简介,产品构造一般应在集成测试、系统测试前，及产品交付客户前进行；对于一些小的项目，根据项目具体情况，也可考虑只构造一次，即产品交付前。产品构造还需遵守如下原则：在构造产品之前，需要制定集成计划。CCB审定软件受控区构造的产品的生成。不论为内部或外部使用，有软件受控区构造的产品仅仅由软件受控区中的配置项和单元组成。,构造人员在本地机器或者其他目标计算机上为产品建立一个目录。若目录原来存在，则需要把目录清空。配置管理员将软件产品需要的配置项从配置管理库上的开发区中复制到这个路径下，然后对软件产品Build。配置管理员把集成的结果填写在集成计划中，然后提交给项目经理
24、。测试工程师从指定的位置得到构造后的产品进行测试，并把测试出的问题记录到BUG管理工具中；若测试通过，则通知配置管理员，由配置管理员根据集成计划中的配置项列表，按照标识规则改变配置项的标识； 如果软件产品需要修改，则从开发区把配置项按标识规则打上标识后，检出(check out)到目标计算机上，在相关人员修改好后检入(check in)，并按标识规则打上标识；重复以上步骤，直至无错误；若为产品发布构造，则需要把提交给客户的软件产品应该拷贝到光盘、硬盘等介质上。,产品构造步骤,配置管理的管理活动,两种CM管理的活动：1、跟踪配置管理活动：项目经理根据项目实际规模来确定配置库的备份策略，包括确定配
25、置库备份的频率及备份方式、路径等，并对这些策略以文档化的方式写进配置管理计划；配置管理员根据配置管理计划，对配置库进行备份，并对备份操作形成记录。配置管理员在工作周报中汇报每周配置管理的工作情况，提交CMG组长、项目经理及相关组或个人。配置管理员定期或事件驱动，负责配置管理状况（基线跟踪表、配置审计报告、配置管理问题清单、配置项变更记录、产品发布清单等）相关报告的编写，并报告给CMG组长、质量保证工程师、总工程师/研发部经理、项目经理及相关组或个人。2、验证配置管理活动：项目的质量保证工程师负责依据软件质量保证过程和项目的质量保证计划验证配置管理活动的执行符合配置管理计划和本过程。,第八章 软
26、件配置管理,CMMI对应实践配置管理基本概念配置管理活动产品发布流程配置管理工具介绍,产品发布类型,产品发布：产品的对外发布，整个项目结项；产品基线发布：产品对内发布，之后可以安装试点或进行Beta测试/用户测试（研发部经理/总工程师负责）；其他基线发布：计划基线、需求基线、设计基线、编码基线、测试基线等（项目经理负责）。,产品发布流程图,先由项目经理确认受影响的相关人员（如：项目组成员、测试人员、配置管理员、质量保证工程师）；配置管理员将最新的基线报告、配置项变更报告（记录）、版本控制表定期或事件驱动发布给受影响的组和个人；由项目经理确认受影响的组和个人都收到最新的基线报告、配置项变更报告（
27、记录）、版本控制表；基线发布。,普通基线发布步骤,先由项目经理提出产品基线发布申请，由总工程师/研发部经理确认受影响的相关人员（如：项目组成员、测试人员、配置管理员、质量保证工程师、相关业务部门）；配置管理员将最新的基线报告、配置项变更报告（记录）、版本控制表定期或事件驱动发布给受影响的组和个人；由项目经理确认受影响的组和个人都收到最新的基线报告、配置项变更报告（记录）、版本控制表；举行产品基线发布评审，由总工程师/研发部经理主持，评审通过之后，基线发布。,产品基线发布步骤,发布前准备：项目经理负责将版本控制表、产品发布申请表内容填写完整，并检查软件产品是否测试通过；配置管理数据库是否经过审计
28、、审计发现的问题是否得到解决；检查项目评审表验收结论，是否通过验收评审；产品发布申请：将版本控制表、产品发布申请表及产品发布通知单提交研发部经理或总工程师审核签字；产品封版产品发布：内部发布：由项目经理填写产品发布通知单以书面形式在所属部门发布产品；配置管理员填写产品发布清单；外部发布：各产品部配置管理员将母盘的安装目录、用户文档目录下的内容刻成光盘提交给用户并填写产品发布清单。,产品发布步骤,第八章 软件配置管理,CMMI对应实践配置管理基本概念配置管理活动产品发布流程配置管理工具介绍,VSS,Visual SourceSafe，即VSS，是微软公司为Visual Studio配套开发的一个
29、小型的配置管理工具,CVS,CVS是Concurrent Versions System（并行版本系统）的简称。它是著名的开放源代码的配置管理工具。,Rational Clear Case,Rational Clear Case是IBM公司的配置管理平台，它能自动追踪每一个文件和目录的变更情况，通过分支和归并功能支持并行开发。,Star Team,Star Team是Borland公司的产品，是企业级解决方案，具备强大的综合项目管理能力，能够提供一个高度集成的环境，实现控制文件版本、管理需求和变更、追踪缺陷和过程化的讨论、对项目管理所需任务进行管理。,Firefly,Firefly是Hansky(汉星天)公司的产品，该软件配置管理系统是Hansky软件开发管理套件中的重要组件，基于项目的分支和标记管理、支持分支比较和分支归并，支持并行开发、面向任务的开发模式、异地分布式开发，具有良好的跨平台能力。,谢谢！,
