DM-ISO-软件配置管理方案计划控制程序.doc

《DM-ISO-软件配置管理方案计划控制程序.doc》由会员分享，可在线阅读，更多相关《DM-ISO-软件配置管理方案计划控制程序.doc（11页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、-!文件发行及分发状况分发部门收文章发行章份数发行部门变更履历No.版本修订日期修订内容修订者123456789101112131415161718制作审核批准张琦1 目的软件配置管理（SCM）贯穿于整个软件生命周期，是管理软件产品所有资产及其变更，维护整个软件研发过程的重要活动，无论是对于管理人员还是研发人员都有着重要的意义。本程序文档明确规定了公司软件配置管理活动的目标、指导方针和过程定义，为公司软件配置管理提供所应遵循的计划、策略、方法、程序及工具等一般化说明。2 定义贯穿于整个软件生命周期，应用技术上和管理上的指导原则和具体方法，用来识别和记录配置项（例如程序源代码、软件库包、文档资料

2、等）的功能特征和物理特征；管理或控制这些特征的变更；记录和报告变更的处理和执行的状态；以及验证其是否符合特定的需求。简单地说，就是关于软件资产的管理。主要包括两个方面： 管理软件资产的合理存放和访问，包括其演进、变更或变化的记录，并加以流程上的控制； 关注软件系统的集成和交付，保障团队合作顺畅，等等。3 范围软件配置管理的主要内容包括： 制定配置管理计划 创建配置管理环境 标识配置项 管理基线和发布活动 变更控制 配置状态监控和报告 配置审计本程序文档适用于公司所有软件产品和项目在各个阶段标识的软件配置管理，并利用“配置管理工具”完成配置项标识、版本控制、变化控制、审计和状态统计等任务或活动。

3、4 职责配置控制委员会（CCB）负责人负责指导和控制软件配置管理的各项具体活动的进行，并为产品经理/项目经理的决策提供建议。其具体工作职责如下： 制定总体配置管理策略及访问控制策略； 评审和审批配置管理计划； 审核重大变更； 评审和审核有关软件基线的设置和更改； 组织CCB的各种例会； 根据配置管理员的报告决定相应的对策。配置管理员根据配置管理计划执行各项管理任务，定期向CCB提交报告，并列席CCB的例会。其具体工作职责如下： 参与制定和修改配置管理计划 监控并定期检查各配置项的管理与维护状况； 监督执行版本控制和变更控制方案； 过程支持； 完成配置审计并提交报告； 对开发人员进行相关的培训；

4、 软件配置管理工具的日常管理与维护； 识别开发过程中存在的问题并制定解决方案。产品经理 / 项目经理产品经理/项目经理是整个软件产品和项目研发活动的负责人，他根据配置控制委员会的建议，批准本产品或项目相关的配置管理的各项活动并控制它们的进程。其具体工作职责如下： 制定本产品或项目的软件配置管理策略； 制定并发布本产品或项目的配置管理计划； 批准或确认配置项的标识，以及软件基线的建立； 决定本产品或项目的开发工作里程碑； 变更控制和管理； 接受并审阅配置控制委员会的报告。开发、测试及运维团队开发、测试及运维团队的职责就是根据项目组织确定的配置管理计划和相关规定，按照配置管理工具的使用模型来完成产

5、品的开发、测试、实施和运维任务，包括各配置项的管理与维护、版本控制和变更控制、过程支持等活动。5 程序5.1 制定配置管理计划 如果没有特殊要求，软件配置管理计划将被包含在软件开发总体计划中，无需单独编制文档。否则，产品经理/项目经理将依照软件配置管理计划的模板，在配置管理员的协助下，制定本项目的软件配置管理计划。1) 制定本项目的配置管理策略和指导方针2) 确定配置管理需使用的资源3) 确定配置管理的项目干系人，分配责任，并确定其介入时机4) 定义标识配置项的准则5) 制订基线计划6) 制订配置库备份计划7) 制订变更控制流程8) 制订审批计划5.2 建立配置库 配置管理员在软件产品或项目研

6、发正式立项后，建立配置管理库，使用Git/Gitlab作为配置库管理工具； 配置库分为“开发库”和“受控库”：“开发库”用于存放在软件研发过程中产生和收集的各种程序代码、软件库包和开发技术文档等，由产品负责人/项目经理和开发团队负责管理和维护；“受控库”保存已被审定的软件配置项，由配置管理员负责管理和维护； 配置管理库必须设置权限。只有产品/项目组成员、配置管理员、质量保证部门和其他被授权的相关人员能够访问配置管理库，进行相应的操作。5.3 标识配置项所谓的配置项，即软件过程中生成或收集的各种制品或信息，主要包括： 程序源代码、各种脚本、可执行程序、软件库包等； 软件过程中产生的各种工程技术文

7、档； 各种数据； 标识配置项又称识别配置项。确认需要纳入配置管理的配置项，确定配置项的获取时间和所有者，为识别的配置项分配唯一的标识；接着，利用之前建立的配置管理系统或配置管理库来存放配置项；最后通过评审或测试后，由配置项组成基线，作为未来开发的基础。5.4 建立基线 在配置管理中，所谓的基线（Baseline），就是一个配置项或一组配置项在其生命周期的特定时间点上通过正式评审而进入正式受控的一种状态。 每一个基线都是其下一步开发的出发点和基准点，且必须通过正式的变更流程来变更。 重要的检查点（CheckPoint）是里程碑（Milestone），重要的里程碑就形成基线（很多情况下，通过在每个

8、配置项或每组配置项的特定整体版本上打标签来完成）。 配置计划里的基线一般由产品负责人或项目经理来驱动和管理，而非配置管理员。5.5管理并控制变更 变更请求，包括新功能、需求变更、功能增强，也包括缺陷。（变更申请人） 评估，分配给合适的人去处理变更，并检查以确保它们确实被处理了。（产品负责人/项目经理、CCB） 控制对配置项的变更，如果要改它，需要合适的人同意。（CCB、产品负责人/项目经理） 改好后，检查和验证，才能入库。（CCB、产品负责人/项目经理） 变更的发布。（配置管理员） 基线的变更 ：基线以内的，不用走变更流程，但产品负责人或项目经理要决定是否进行回归测试，以保证更改不会对基线造成

9、未预料的影响；基线外要走变更流程。 所有配置项的变更历史必须记录在配置项内，包括：日期、版本号、变更请求号、变更内容、修改人等。软件配置项与基线版本5.6 配置审计执行审计以验证配置项符合特定的标准或需求。配置审计内容包括：1) 评估基线的完整性2) 检查配置记录是否正确反映了配置项的配置情况3) 审核配置项的结构完整性4) 对配置项进行技术评审5) 验证配置项的完备性和正确性6) 验证是否符合配置管理标准和规程5.7 配置状态报告 能够及时、随时地给出配置项的当前状况，报告所有配置项以及变更请求的状态，以便于加强配置管理工作： What：发生了什么事？ Who：谁做的此事？ When：此事是

10、什么时候发生的？ Why：为什么做此事？5.7 软件配置项与基线版本配置管理员确保软件产品或项目组按照“软件产品版本管理规范”给每个配置项分配唯一的标识。如果配置项的标识不遵循“软件产品版本管理规范”，配置项的标识定义必须通过CCB的审定。类型版本号修订软件配置项组织内产生的文档参照“文件控制程序”参照“文件控制程序”程序代码、脚本、软件库包等参照“版本号管理”和“发布前的版本策略”参照“版本号管理”和“发布前的版本策略”从组织外获取的保留外来的版本号软件基线B.0：从1.0开始B+15.8 备份 配置管理员定期，或在一些关键时间点进行配置库的备份，填写“备份日志”，提交给管理层及项目干系人等

11、。5.9 制度化已定义过程 要形成可以指导现在和未来多个软件开发项目的配置管理过程规范。这样的规范不是一成不变的。要收集相关的信息、数据和反馈，并基于此进行软件配置管理的持续改进。6 过程实践6.1 精简的配置管理方法和流程关键活动是：制定配置管理计划、源代码管理和文档管理成本和需求决定了配置管理的力度。我们不追求完美无缺的配置管理，够用就行，配置管理执行的成本和代价应当控制在预算之内。 所有项目成员都要对其工作成果进行配置管理，最低要求是保证重要工作成果不发生混乱 配置管理规范清晰明了，便于执行，不增加额外过多的负担 源代码和文档分开管理6.2 版本号管理 基于GNU风格的方案： 主版本号

12、. 子版本号 . 修正版本号 . 编译 (构建) 版本号 Major_Version_Number.Minor_Version_Number.Revision_Number.Build_Number示例：1.2.1，2.0，5.0.0 build-13124 产品初版本时，版本号可以为0.1或0.1.0，也可以为 1.0 或 1.0.0； 当产品进行了局部修改或缺陷修复后，主版本号和子版本号都不变，修正版本号加1； 当产品在原有的基础上增加了部分功能，主版本号不变，子版本号加1，修正版本号复位为0，因而可以被省略掉； 当产品进行了重大修改，或者新增功能累积较多，而导致项目整体发生全局变化时，主

13、版本号加1； 编译版本号一般是编译器或构建工具在编译或构建过程中，按一定规则自动生成的，我们只定义其格式，并不进行人为控制。6.3 发布前的版本策略（alpha）版此版本表示目前仅仅是一个初步完成品，通常只在开发者内部交流，或者发布给专业测试人员进行内测。一般而言，该版本软件的bug较多，普通用户最好不要安装。（beta）版该版本相对于版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过大规模的公测来进一步消除。这一版本通常是免费发布，用户可从相关的站点下载。通过一些普通用户特别是专业爱好者的测试，将结果反馈给开发者，开发者们再进行有针对性地修改。ZBB（Zero Bug Bu

14、ild）版某天的版本要把在之前（例如48小时前）记录的Bug都解决掉。（gamma）版有时也称RC（发布候选版），该版本已经相当成熟了，与即将发行的正式版相差无几，如果用户实在等不及了，尽可以装上一试。RC（发布候选版）Release Candidate，即：发布候选版，有时也叫（gamma）版。它不是最终的版本，而是公开发行最终版（RTM=Release To Manufacture）之前的最后一个版本。Trial（试用版）得益于互联网的迅速发展，试用版在最近的几年里颇为流行。该版本软件通常都有时间限制，过期之后用户如果希望继续使用，一般得交纳一定的费用进行注册或购买。有些试用版软件还在功能上做了一定的限制。6.4 持续集成6.5 基于Git-flow的分支模型