《配置管理文档.doc》由会员分享，可在线阅读，更多相关《配置管理文档.doc（31页珍藏版）》请在三一办公上搜索。
1、配置管理文档项目名称：格拉特尼美食梦工厂开发日期：2010-09-20至2011-01-14分类：配置管理文档指导教师：王崇文团队：2013页数：修订记录日期版本内容作者编写文档框架2013确定基线内容2013将文件进行编号，和整理，并体现在文档当中2013小组成员魏盛斌20072757闫志鑫20072759尹航20072760郑然20072766目录目录21引言31.1目的31.2术语定义31.3参考资料 32软件配置 52.1软件配置环境52.2软件配置项52.3配置管理员64 软件配置管理计划84.1建立示例配置库84.2配置标识管理94.2.1文档94.2.2程序94.2.3基线94.
2、3配置库控制104.3.1权限控制104.3.2配置库的控制104.3.3建立软件库104.3.4软件配置更改104.3.5配置文件清单的维护104.4配置的检查和评审114.5配置库的备份134.6配置管理计划附属文档135里程碑147附录1 文档命名规定157.1受控配置库文件命名规则157.2非受控配置库文件命名规则157.3提交文档文件命名规则159附录2 文档编码规范1710附录3 帐号及权限管理1811附录4 配置库使用规定201 引言1.1 目的本文档目的在于对格拉特尼美食梦工厂进行软件配置管理，提高软件质量，降低软件开发成本。本文档内容主要参考研发中心相关的ISO程序和制度文档
3、，并在这基础上整理成适合本项目的软件配置管理，为项目经理、配置管理员及相关人员提供日常的配置管理操作步骤。 1.2 术语定义软件配置管理：简称SCM（Software Configuration Management的缩写），是在项目开发中，标识、控制和管理软件变更的一种管理。配置管理的使用取决于项目规模和复杂性以及风险水平。软件的规模越大，配置管理就显得越重要。基线：(BaseLine) 是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个
4、基线。配置管理员：项目组中负责配置管理工作的角色，该角色可以兼职。在某一开发阶段通过评审或某一质量检查点通过审核后，配置管理员负责统一添加或修改相关文档的最新有效版本以及审批人签字。配置标识：（Configuration Identification）对软件项目在开发过程中的资源进行标识，以便识别。配置检查：（Configuration Audit）对软件配置管理过程中的行动进行检查。1.3 参考资料 研发中心配置管理制度产品的标识与可追溯性程序开发手册2 软件配置 2.1 软件配置环境2.1.1开发用计算机软件环境软件名称作用Windows 7/Windows XP/Windows Vist
5、a操作系统Adobe Flash Player 10.xflash运行环境Adobe Flex Builder 3flash开发环境TortiesSVN配置管理软件在整个项目过程或产品生命周期中,选择TortiesSVN作为配置管理工具。2.1.2 硬件环境无特殊要求。2.1.3配置管理客户端项目组成员在各自的计算机安装SVN客户端，项目组成员以分配的帐号访问配置服务器和登录配置管理系统，根据配置管理员设定的用户权限进项配置管理活动。2.2 软件配置项在本项目的实施过程中，将配置库分为受控配置库和非受控配置库两种受控配置库在本项目开发实施的整个过程中，根据不同阶段的配置管理划分8个受控配置目录
6、，只有配置管理员拥有增加和修改的权限，其它用户只有只读的权限。受控配置库的目录为：00初始环境配置01启动02需求分析03概要与详细设计04编码05测试06安装部署07项目管理与变更控制初始配置库的根目录中包含依然合得来小组的配置文件清单，该文档包括本项目开发过程中应该提交的文档的清单，在实际开发过程中，根据实际情况，可以在清单中酌情修改、增加和删除需要提交的文档。非受控配置目录在本项目开发过程中，设立了非受控配置目录。设立非受控配置目录的目的是为了统一管理和存放开发过程中产生的临时文档和过程性文档，没有格式及命名上的严格要求，使项目组成员在思考、设计时不受太多的限制和约束，能够更有效地发挥个
7、人能力，符合以人为本的原则。在项目初期，设立了以下三个目录：目录名称用途及说明小组工作区用于保存小组的公共代码和集体协作的文档个人代码提交区用于保存小组成员的个人代码，每个人都有单独的代码目录个人文档提交区用于保存小组成员的个人文档，每个人都有单独的文档目录在根据项目开发过程中，根据实际需要，可以酌情增加非受控配置目录。2.3 配置管理员技术支持经理在项目中担任配置管理员的工作。配置管理员负责：1. 指定配置计划2. 定期的查看配置库更新的内容3. 定期通知大家对稳定版本进行下载4. 协助组长进行交付物的检查和评审。34 软件配置管理计划4.1 建立示例配置库配置管理员在制定完计划后，建立符合
8、本项目的配置管理库。配置库建立在TortiesSVN上，目录结构可按照示例配置库提供的目录。对于本项目来说，需要划分多个子系统，因此要在确定子系统的划分后，在不同阶段下分别建立各子系统的配置目录。配置管理库建立完毕后，配置管理人员为小组其他成员分配帐号和权限 配置管理员应保管好配置管理工具的管理员权限，项目组中使用配置管理库的成员应该及时更改自己在配置管理工具的缺省设置密码。图1 项目管理文档列表4.1.14.2 配置标识管理4.2.1 文档根据配置管理计划和配置库中的文档清单，配置管理员要检查需要提交的文档是否都按时提交，文档数目是否符合，文档的标识、命名以及版本等是否符合程序规定。关于文档
9、的命名请参见附件 1 文档命名规定4.2.2 程序所有属于该项目的程序、分程序、模块和程序单元，都要按照由项目组和配置管理员制订的软件系统的命名约定的规定来标识。要求所有模块的源代码都需记录模块编号，且模块编号在整个系统中是唯一的。模块编号在系统设计完成之后，由项目组和配置管理员共同根据系统设计进行编制。4.2.3 基线所有属于本项目及其各子系统的各类基线，首先要按照计划书、软件需求规格说明书、软件项目详细分析设计说明书的规定确定其技术内容，在整个软件项目开发过程中定义以下两类基线：文档基线：本项目的文档基线的定义以里程碑的定义为准，将到达各阶段的里程碑时的文档作为基线，具体里程碑的定义参见第
10、4节“里程碑”。产品基线：产品基线包含两个，一个是系统上线时，一个是系统经过客户验证测试时，基线包含那时的所有程序代码和文档。配置管理员负责在项目开发的每一个里程碑处、每一个阶段性的版本发布时负责为整个配置库设立书签，划定配置管理基线，并以文档的方式记录下这些书签的定义。4.2.44.3 配置库控制4.3.1 权限控制配置管理员根据附录 3帐号及权限管理设置和调整项目组成员对配置项的权限。4.3.2 配置库的控制在项目开发和实施的整个过程中，配置管理员根据配置管理计划及管理规则对配置库应进行管理和控制。配置管理员负责检查项目组成员使用配置库是否正确。包括是否及时检入最新版本、是否添加了注释、是
11、否及时更改配置状态，是否存在项目组成员修改了不属于自己负责的配置项，项目组成员是否完成了自己负责的配置项的检入，测试版本的构造是否从配置库中取出等。4.3.3 建立软件库在项目的各个开发阶段，应建立起各阶段各子系统的软件开发库（软件开发工作区），同时建立起想对应的有关该系统及其子系统的软件受控库。在每个阶段结束或里程碑，需让各子系统提交相关的产品并送入软件受控库，由配置管理员统一管理，以后再有对产品的变更需求，应按照正常的变更程序来控制并检查相关的变更文档。当全部开发工作结束，需建立起软件产品库，将所有可交付的产品都送入软件产品库。4.3.4 软件配置更改软件配置的更改管理适用于全部项目的所有
12、文档和代码，其中包括整个项目的各个运行软件，也包括为项目专门开发的支持软件。l 对该项目各个子系统及其专用支持软件的基线及其集成系统的任何修改，必须得到项目负责人的批准并在本项目软件质量管理专员处备案才能进行配置更改；l 更改完成后的文档和代码等，需得到项目负责人认可，提交给配置管理员后，由配置管理员签入受控配置库；l 受控配置库中的文档，在文档末尾必须有修改记录部分，包括修改人、修改日期、修改内容等项，每次对于受控配置库中文档的修改，必须填写这些项。4.3.5 配置文件清单的维护l 配置文件清单的维护由配置管理员维护；l 项目初期，配置管理员与项目组成员一起对开发过程中可能产生的文档的进行预
13、计，并在配置文件清单中列出这些文档及其大致的计划提交时间；l 在实际开发过程中，文档提交可能会产生一些变化，如新增某些文档、原计划的一些文档不再单独产生、文档计划提交日期的变更等，项目组应该及时通知配置管理员，由配置管理员及时更改配置文件清单中的相应项。4.3.64.4 配置的检查和评审配置的检查和评审可通过配置管理制度的审核内容来进行检查。相关的审核内容如下表：审核分类审核内容检查情况发布审核发布文档是否清楚地定义发布的范围，包括应被纳入的更改请求？否所有已知缺陷/毛病(bug)是否已文档化？是是否有适当的文档，它标识重建该发布所需的环境（编译器版本、OS版本、compilation fla
14、gs，等等）？否是否有适当的文档，它说明构成该发布的成分及成分的版本？是发布的所有项是否彼此同步（在时间上一致）？是是否采用正确存储库中的正确成分的正确版本生成发布？是存储库/配置项审核存储库是否按SCM计划定义？否项是否已经进入正确的库？是是否按SCM计划中规定的命名约定项命名?是是否按照SCM计划，规定项的版本号？是是否按照SCM计划中规定的事件已经将所有项入库？例如：测试完成、客户的评审意见已采纳是项是否有所要求的文档以识别项、版本和更改历史？是更改实施审核是否全部所要求的更改请求均已结束？是是否更改请求标识出全部拟更改的项？是更改请求中所标识的全部要更改的项均已更改，被QC和在所要求的
15、QC后入库？否是否可能在项的任何两个版本中间区分更改？是项的文档是否足够，能向后追踪更改到相应的更改请求？是是否有恰当方法能回到以前的版本？是审核的其他方面是否对库作了恰当的备份?是是否已测试过从备份中恢复?是在群组成员的工作目录中是否有任何未经许可的成分？是是否有恰当的保密/批准手续以保证只有经授权的群组成员才能进行入库/出库？是配置管理员应配合研发中心产品管理部定期对项目进行配置管理的审核。在审核过程中，提供所需要的配置管理计划及相关资料，在项目开发结束后，需提交所有关于项目的软件配置库。4.4.14.5 配置库的备份在项目开发实施过程的各个阶段，配置管理员应定期做好软件配置库的备份，以防
16、造成劳动成果的丢失而给整个项目及小组带来的严重损失。在每个阶段或里程碑处在做完基线工作后应进行备份。备份文件应存放在不同的地方。本项目的备份按如下方式进行： 定期备份时间为每周备份一次 当达到一个里程碑时，对配置库进行一次备份 备份的文件要明确标明备份日期，除了在版本控制服务器中以外，还要在每个人电脑上进行备份4.6 配置管理计划附属文档配置文件清单：记录项目开发过程中应该产生的一些文档、描述及其提交计划等内容，是执行配置管理及检查的重要依据。该文档在项目开始的初期建立，确定开发过程中需要提交的大部分文档，并在项目开发过程中根据实际情况稍做更新。模块清单：模块清单记录了系统各个子系统、程序模块
17、的名称并分别进行项目内的唯一编号，是所有模块的源代码需记录模块编号的依据。模块清单在系统设计完成之后，由项目组和配置管理员共同根据系统设计进行编制。文档命名规定：参见附录1 文档命名规定帐号及权限管理：参见附录3 帐号及权限管理配置库日常使用规定：参见附录4 配置库日常使用规定4.6.15 里程碑本项目主要划分以下几个里程碑：里程碑特点1. 需求规格说明书完成 系统（或所有已确定子系统）的需求分析全部完成 已形成相应的需求分析说明书及其它附属文档 需求分析说明书已通过小组评审，并且客户（老师）一致认为需求分析阶段已结束，可以进入设计阶段2. 概要设计文档完成 系统（或所有已确定子系统）的概要设
18、计全部完成 已形成相应的概要设计说明书及其它附属文档 概要设计说明书已通过公司评审或与客户一致认为概要设计阶段已结束，可以进入详细设计阶段3. 详细设计文档完成 系统（或所有已确定子系统）的详细设计全部完成 已形成相应的详细设计说明书及其它附属文档 详细设计说明书已通过公司评审或与客户一致认为详细设计阶段已结束，可以进入编码阶段4. 数据库搭建完成 各个表的字段涵盖所有必要的属性 表之间的关联属性明确 数据库服务器能够稳定的工作5. 静态页面搭建完成 页面美观 包含各个子功能的模板页6. 各个功能块Web Service搭建完成 Web Service数据操作正确 Web Service响应时
19、间较短7. 客户端页面整合完成 页面之间的跳转正常，没有遗漏的功能和页面8. 整个网站整合部署完成 网站运行正常 服务器运行稳定9. 测试计划说明书完成 测试用例涵盖所有等价类 测试时间安排得当10. 测试分析说明书完成 针对测试出现的每一种实际情况作出有效的分析 对后续的修改能够起到帮助作用11. 文档整理和完善工作完成 对文档进行统一的编号和整理 再次确认文档的风格是否统一12. 课程答辩通过 大家得到满意的分数 能够条例的展示小组的作品67 附录1 文档命名规定本命名规定主要是针对文档的，不包含源代码文件和最终程序的命名规则。本规定主要包含以下三个方面的命名规则：1. 受控配置库文件命名
20、规则2. 非受控配置库文件命名规则3. 提交文档文件命名规则7.1 受控配置库文件命名规则受控配置库中的配置项文档（不含源代码和最终工作产品）名称应该按照如下格式命名：小组名称 _ 资料名称 _ 版本号项说明项目名称依然合得来小组资料名称开发计划书系统方案书需求分析说明书概要设计说明书详细设计说明书测试计划模块清单版本号V1.0例如：依然合得来小组_配置管理文档_v1.0.docx7.2 非受控配置库文件命名规则非受控配置库主要用于存放项目成员工作时产生的临时文档等，只要求提交时不致出错，对命名规则没有其它限制，由项目成员根据自己习惯对文档命名。7.3 提交文档文件命名规则同受控配置库的文件命
21、名规则。项目成员提交文档到文档提交区前，应该按照受控配置库的文件命名规则对文档命名，然后才提交道文档提交区中。89 附录2 文档编码规范文件编码原则技术文件的文档编号、编码规则如下表示：XXXX + XXX + XXX项目编号 文档类型号 文档流水号项目编号项目编号为4位，前两位为小组编号，后两位为标识版本。文档类型号用来标识软件开发中产生的某一类技术文档，用三位数字表示：文档类型号技术文档类型001系统方案书/新产品可行性报告002软件开发计划书003需求分析报告004概要设计说明书/设计说明书005测试计划006详细设计说明书007用户手册008程序设计规范009界面规范010数据库规范0
22、11测试用例说明书012软件测试分析报告013开发总结报告014安装手册015新产品初步可行性分析报告016测试方案017配置管理计划文档流水号只有当在同一文档分成几部分编写时才使用。对于技术文件来说，每一种技术文件的文件大小要取决于项关项目的规模大小和复杂程度。因为本项目比较大，根据系统情况拆分成了三个子系统，文档流水号分别为：001003。子系统一001子系统二002子系统三00310 附录3 帐号及权限管理一、帐号管理1、 配置管理库帐号l 在网络教室SVN服务器上为项目组的每个项目成员都建立帐号；l 帐号名与大家的学号相同；l 初始口令与网络教室登录密码一直；l 每个项目成员访问配置管
23、理服务器时，都应该用自己的帐号；二、权限管理权限管理分为两大部分的权限管理： 受控配置库的权限管理 非受控配置库的权限管理1、 受控配置库l 配置管理员对受控配置库拥有所有权限；l 项目组其他成员对受控配置库拥有只读权限；l 非项目组成员未经允许对整个配置库没有任何权限；2、 非受控配置库非受控配置库主要包含以下三个目录： 个人工作区 小组工作区 文档提交区小组工作区l 各小组的成员对所属小组目录拥有所有权限，对其它小组目录只有只读权限；l 项目管理人员和配置管理员对所有小组目录拥有所有权限；个人文档提交区l 用于文档提交；l 所有人对其拥有添加/只读修改删除和签入签出权限；l 配置管理员对其
24、拥有所有权限；个人代码提交区l 用于代码提交；l 所有人对其拥有添加/只读修改删除和签入签出权限；l 配置管理员对其拥有所有权限；11 附录4 配置库使用规定1、 项目组成员编写的与本项目有关文档、程序代码等，应该保存在配置库中；2、 文档在编写过程中，保存在配置库的非受控目录中，其中个人文档和代码保存在“个人工作区”的项目成员本人的目录下，小组文档保存在“小组工作区”的所属小组目录下；3、 每周第一个工作日开始，项目成员从非受控配置库中签出要编写、修改的文档或代码到本人的计算机，进行编写、修改工作；4、 每周最后一个工作日结束时，项目成员必须将签出的文档保存后签入到配置库中；5、 文档和代码
25、要提交到受控配置库中时，必须先提交给配置管理员，由配置管理员提交到受控配置库中；6、 当文档或代码通过评审或得到项目管理人员及客户的一致认为可以提交时，提交到“文档提交区”的目录中；7、 文档提交前应该按照附录1文档命名规定中的规定进行命名8、 项目组成员未经项目组允许不得更改他人的文档和代码；9、 任何文档、代码等，不能以压缩文件的方式签入配置库中；10、 每次评审结束，相关文档的批准人电子签名由批准人签写或经批准人授权配置管理员填写，然后由配置管理员负责签入配置库；11、 如果需要对受控配置库中的文档、代码进行变更，需得到项目负责人批准方能从受控配置库中取出更改；12、 更改完成后的文档，需得到项目负责人认可，提交给配置管理员后，由配置管理员签入受控配置库。
