软件开发流程和相关规范

1、文件编号std-zs-kf-2010-000 中山森中山森创创信息技信息技术术有限公司有限公司 版本/修改a/0 文件名称文件名称软件开发流程和相关规范页数共 101 页 中山森创信息技术有限公司中山森创信息技术有限公司 软件开发流程和相关规范软件开发流程和相关规范 版权所有，未经双方许可不得复制或对外传阅版权所有，未经双方许可不得复制或对外传阅 目目 录录 1软件配置管理规范软件配置管理规范.7 1.1.配置管理目标.7 1.2.配置管理的主要内容.7 1.3.配置管理角色、职责及权限.8 1.3.1.配置经理.8 1.3.2.项目负责人.8 1.3.3.配置管理员（cmo）.9 1.3.4

2、.开发人员.9 1.3.5.软件测试人员.9 1.3.6.软件维护人员.10 1.3.7.质量保证人员.10 1.3.8.角色、权限图.10 1.4.配置管理过程.12 1.5.配置管理工具及环境.13 1.5.1.文件服务器.13 1.5.2.配置管理工具.13 1.5.3.配置服务器.13 1.6.配置管理计划.14 1.6.1.配置工具的选择.14 1.6.2.配置库的基本目录结构.14 1.6.3.权限设置.15 1.6.4.配置项标识规定.15 1.6.5.协作开发规定.15 1.6.6.其它.15 1.7.配置项管理.15 1.7.1.配置项标识号命名规范.16 1.7.2.配置项

3、名称命名规范.17 1.7.3.程序文件、数据文件.18 1.8.基线建立及变更管理.18 1.9.文档版本管理.19 1.9.1.文档版本及版本号的概念.19 1.9.2.版本号的定义及生成方法.20 1.9.3.定版的具体操作方法.21 1.9.4.定版的具体操作方法.21 1.10.软件版本管理.21 1.10.1.定版的具体操作方法.21 1.10.2.版本号的定义及生成方法.22 1.10.3.定版的具体操作方法.23 1.10.4.在 vss 上定版的具体操作方法.23 1.10.5.版本发布流程.24 1.10.6.版本保存.25 1.11.公用程序库的建立及维护.25 1.12

4、.配置库的安全管理.25 1.12.1.版本保存.25 1.12.2.配置服务器的安全控制.26 1.12.3.配置库备份.26 1.12.4.配置管理平台维护.26 1.13.工作空间管理.26 1.14.变更文件的审批与确认.27 2软件质量保证规范软件质量保证规范.28 2.1概述.28 2.1.1目标.28 2.1.2方针.28 2.1.3核心内容.28 2.2质量保证活动组织与职责.29 2.2.1质量保证组织结构图.29 2.2.2角色与职责.29 2.3工作规程.33 2.3.1工作流程图.33 2.3.2指定质量保证人员及参与项目策划确认.34 2.3.3早期活动及建立质量保证

5、计划.34 2.3.4项目计划的评审.34 2.3.5质量保证计划的分步实施及报告.34 2.3.6质量保证计划的维护.35 2.3.7质量保证总结报告.36 2.4质量保证计划.36 2.4.1质量目标.36 2.4.2质量保证活动要点.36 2.4.3质量保证报告制度.38 3软件开发过程规范软件开发过程规范.39 3.1引言.39 3.2软件开发过程.39 3.3需求开发过程.39 3.3.1目的.39 3.3.2前提.39 3.3.3主要活动.39 3.3.4流程规范.40 3.1.1需求定义流程规范.42 3.1.2需求分析内容.42 3.4总体设计过程.43 3.4.1目的.43

6、3.4.2前提.43 3.4.3主要活动.43 3.4.4流程规范.44 3.5概要设计过程.45 3.5.1目的.45 3.5.2前提.45 3.5.3主要活动.45 3.5.4流程规范.46 3.6详细设计过程.49 3.6.1目的.49 3.6.2前提.50 3.6.3主要活动.50 3.6.4流程规范.50 3.7系统实现过程.51 3.7.1目的.51 3.7.2前提.51 3.7.3主要活动.51 3.7.4流程规范.52 3.8软件测试过程.52 3.9系统运行过程.53 3.9.1目的.53 3.9.2前提.53 3.9.3主要活动.53 3.9.4流程规范.54 3.10软件

7、维护过程.54 4 4软件测试过程规范软件测试过程规范.54 4.1软件测试目的.54 4.2软件测试过程.55 4.3软件测试过程与软件开发过程关系.57 4.4测试计划.57 4.4.1软件测试计划.57 4.4.2测试需求.58 4.5测试设计.58 4.5.1单元测试方案.58 4.5.2集成测试方案.58 4.5.3系统测试方案.59 4.5.4测试工具设计.59 4.6测试实现.59 4.6.1测试用例编制.59 4.6.2测试工具实现.59 4.7测试执行.59 4.7.1单元测试.59 4.7.2集成测试.60 4.7.3系统测试.60 4.7.4用户测试.60 4.8测试结束

8、.60 5 5设计和开发评审指南设计和开发评审指南.61 5.1目的.61 5.2范围.61 5.3角色和职责.61 5.3.1主审人.61 5.3.2评审专家.62 5.3.3质量保证人员.62 5.3.4记录员.62 5.3.5顾客和用户代表.62 5.3.6相关领导和部门管理人员.62 5.4评审时机.62 5.5评审的基本要求.62 5.6评审依据.63 5.7评审内容.63 5.8评审方式.63 会签评审.63 会议评审.63 5.9工作程序.64 5.9.1成立评审组.64 5.9.2提供资料.64 5.9.3评委发表意见.64 5.9.4形成评

9、审结论.65 5.9.5评审资料的归档.65 5.9.6跟踪管理.65 6 6编码规范编码规范.66 6.1编制目的.66 6.2c#编码标准.66 6.2.1一般命名规范.66 6.2.2ado.net 命名规范 .67 6.2.3winform control 命名规范.67 6.2.4webcontrol 命名规范.68 6.2.5命名约定.69 6.2.6注释.69 6.2.7代码编写格式.70 6.2.8c#细节规范.73 7 7unixunix 开发环境规范开发环境规范.74 7.1源程序版本管理.74 7.2开发用户环境设置.75 7.3项目目录结构.75 7.4软件测试：.76

10、 8 8软件单元测试工作指南软件单元测试工作指南.76 8.1目的.76 8.2单元测试工作内容及其流程.76 8.3单元测试需求获取.77 8.4单元测试测试策略.77 8.5单元测试工作机制.77 9 9软件集成测试工作指南软件集成测试工作指南.78 9.1目的.78 9.2集成测试工作内容及其流程.78 9.3集成测试需求获取.79 9.4集成测试测试策略.79 9.5集成测试工作机制.79 1010软件系统测试工作指南软件系统测试工作指南.79 10.1目的.80 10.2系统测试工作内容及其流程.80 10.3系统测试需求获取.80 10.3.1功能性测试需求.81 10.3.2性能

11、测试需求.81 10.3.3其它测试需求.81 10.4系统测试策略.82 10.4.1系统测试类型和目标.82 10.4.2采用的测试技术.82 10.5系统测试的工作机制.82 1111软件开发文档编制规范软件开发文档编制规范.83 11.1引言.83 11.2使用说明.83 11.3常用工具格式规范.84 11.4总体设计说明书编制规范.84 11.5需求规格说明书编制规范.85 11.6概要设计说明书编制规范.86 11.7数据库设计说明书编制规范.86 11.8软件维护手册编制规范.87 11.9用户手册编制规范.88 11.10附件.89 1212软件开发部门职责篇软件开发部门职责

12、篇.89 12.1软件部门职责.89 12.1.1售前咨询.89 12.1.2项目规划.89 12.1.3需求分析.90 12.1.4软件原型.90 12.1.5软件开发.91 12.1.6软件测试.91 12.1.7软件实施.91 12.1.8总结验收.92 12.1.9产品升级.93 12.1.10知识管理.93 12.1.11内部培训.93 12.1.12开发流程标准化.93 12.2岗位职责.93 12.2.1技术总监.93 12.2.2项目经理.93 12.2.3系统分析员.94 12.2.4高级程序员.94 12.2.5程序员.94 12.2.6测试工程师.94 12.2.7软件实

13、施人员.95 附录附录.95 word 开发文档格式模板开发文档格式模板.95 rose模板规范目录结构模板规范目录结构.99 软件开发文档清单软件开发文档清单.100 1软件配置管理规范软件配置管理规范 1.1.配置管理目标配置管理目标 通过实施配置管理活动，令项目开发团队工作在一个规范的配置管理平台上，从而提高 软件产品质量、提高软件开发的整体工作效率，达到用户满意。同时，通过配置管理活动， 将项目开发过程中所有的产出、开发活动、管理活动等进行记录，以方便今后的软件维护及 类似项目的参照。 1.2.配置管理的主要内容配置管理的主要内容 软件开发的配置管理主要包括以下内容： 配置项标识的管理

14、； 配置库的建立及变更管理； 版本控制； 配置管理计划编制； 公用程序库的建立及维护； 配置库的安全管理； 小组协作管理； 工作空间管理； 1.3.配置管理角色、职责及权限配置管理角色、职责及权限 在配置管理平台下，软件开发人员按照不同的角色的要求、根据系统赋予的权限来执行 相应的动作。具体主要涉及下列的角色和分工： .3.1.配置经理配置经理 负责指导和控制部门配置管理的各项具体活动的进行，为项目经理的决策提供建议。配 置经理由指定的专人兼任，其具体职责为以下几项： 建立、管理部门配置管理平台； 建立项目配置库； 配置库的备份等安全管理； 制定配置管理规范； 辅助项目组建立配置

15、管理环境； 审核配置管理计划； 指导项目组配置管理活动； 监督、考核各项目组配置管理活动的执行情况。 .3.2.项目负责人项目负责人 项目负责人根据配置管理员的建议，批准、监督该项目配置管理的各项活动并控制它们 的进程。其具体职责为以下几项： 参与规划、制定和修改项目配置管理策略； 批准、发布配置管理计划； 决定项目起始基线和开发里程碑； 建立基线，审核基线变更申请； 制定配置管理相关权限策略； 监控配置管理过程； 项目负责人可以查看该项目配置库中配置项，在允许的权限内可以对配置项进行增、删、 改。 .3.3.配置管理员（配置管理员（cmocmo） 各项目组指定配置

16、管理员，配置管理员根据配置管理计划执行该项目各项配置管理任务， 其具体职责为以下几项： 编制、提交配置管理计划； 严格管理配置项的操作权限； 执行版本控制流程； 执行变更控制方案； 建立开发人员的工作空间； 对开发人员进行相关的培训； 项目小组开发协作管理； 各配置项的日常管理与维护； 识别配置管理过程中存在的问题并拟就解决方案； 向配置经理、项目负责人定期汇报项目组配置管理情况。 配置管理员可以查看该项目配置库中配置项，在允许的权限内可以对配置项进行增、删、 改。 .3.4.开发人员开发人员 开发人员的职责就是根据软件配置管理计划和相关规定，按照软件配置管理工具的使用 方式来完

17、成开发任务。 开发人员可以查看、修改项目配置库中有权限的配置项，但不允许对配置项进行永久删 除操作。 .3.5.软件测试人员软件测试人员 软件测试人员的职责就是根据软件配置管理计划和相关规定，按照软件配置管理工具的 使用方式来完成软件测试任务。 软件测试人员可以查看软件的相关开发文档，在权限范围内可以对配置项增加、修改， 但不允许对配置项进行永久删除操作。 .3.6.软件维护人员软件维护人员 软件维护人员的职责就是根据软件配置管理计划和相关规定，按照软件配置管理工具的 使用方式来完成软件维护任务。 软件维护人员可以查看、修改该人员负责维护的软件的相关开发文档、源程序

18、，在权限 范围内可以对配置项增加、修改，但不允许对配置项进行永久删除操作。 .3.7.质量保证人员质量保证人员 质量保证人员的职责就是根据软件配置管理计划和相关规定，按照软件配置管理工具的 使用模型来完成质量保证任务。 质量保证人员可以查看软件的相关开发文档，在权限范围内可以对配置项增加、修改， 但不允许对配置项进行永久删除操作。 .3.8.角色、权限图角色、权限图 以下角色、权限图主要针对 vss 配置管理工具。 角色 project 配置经理 项目经理配置管理员开发人员软件测试人员质量保证人 员 准备阶段 rrcarcad r (ca 授权) r r (ca 授

19、权) 需求分析阶段 rrcarcad r (ca 授权) rr 系统设计阶段 rrcarcad r (ca 授权)无 r 系统实现阶段 rrcarcad r (ca 授权)无无 系统测试阶段 rrcarcadrcarcar 系统维护阶段 rrcarcad r (ca 授权)无 r 质量保证 rrrcadrrrca 项目管理 rrcarcadr 无 r 配置管理 rrrcadrrr 测试管理 rrrcadrrcar 个人工作库 r 无 rcadrcad 无无 项目共享库 rrcarcadrrr 项目基线库 r r (ca 授权) rcad r (ca 授权)r (ca 授权) rca 注： 1.

20、权限 r表示具有 read 权限。 c表示具有 check in/check out 权限。 a表示具有 add/rename/delete 权限。 d表示具有 destroy 权限。 无表示不具有该项权限。 授权表示需要项目负责人根据需要配置相应权限。 2.由于配置管理员具有最高权限，可以进行任何操作，但执行非 read 操作时必须经 项目负责人同意。 3. 个人工作空间允许拥有者进行任何操作，包括 destroy 操作。 1.4.配置管理过程配置管理过程 开 始 配置管理策划 评审 不通过 建立配置管理环境 通过 配置、标识和 管理 变更控制版本控制 基线审核和发 布 报告状态 发布产品

21、结束 配置管理的策划由项目组配置管理员负责，策划的结果为配置管理计划； 配置管理策划的评审由开发部配置经理、项目经理进行评审，形成相关的评审纪录； 配置管理环境由开发部配置经理负责； 配置库的具体管理由配置管理员负责，形成相关的记录，包括配置项信息登记表 、配置管理周报、配置管理工作表、软件配置管理评分表、变更申 请记录表、应用软件版本发布申请表、版本记录表、变更文件审批与 确认登记表。 1.5.配置管理工具及环境配置管理工具及环境 .5.1.文件服务器文件服务器 在开发部建立独立的文件服务器，文件服务器的主要作用为： 提供共享程序服务 将常用应用程序（包括开发工具、数据库工具、

22、管理工具等）存放共享目录下，方便各 开发人员随时使用，并提供共享目录以便各开发人员上传共享程序。 提供共享资料服务 将常用资料存放共享目录下，方便各开发人员随时使用，并提供共享目录以便各开发人 员上传共享文档。 提供开发人员个人空间 为每个开发人员建立个人目录，开发人员可将关键文档在文件服务器上进行备份。此为 开发人员的私有目录，别人无权访问。 .5.2.配置管理工具配置管理工具 可采用以下配置管理工具： microsoft visual sourcesafe(vss) 基于 windows 的开发采用 microsoft visual sourcesafe(vss)作为配置管理

23、工具。 基于 unix 下的开发采用 samba 作为磁盘映射工具，microsoft visual sourcesafe(vss) 作为配置管理工具。 cvs 工具 基于 unix 下的开发采用 cvs 作为程序版本控制工具，同时在 windows 环境下 用vss 建立项目文档等配置项的管理环境。 .5.3.配置服务器配置服务器 在开发部建立统一的配置服务器，逐步进行配置库的集中管理，项目组内部不再单 独设立配置服务器。 配置服务器今后将成为软件开发的项目库，记录所有软件开发项目的开发及维护过 程。对新项目的开发，项目负责人可以申请查阅配置库中相类似的项目资料，以更好地 把握

24、新项目的开发。 配置服务器也是开发部的公用程序库服务器。各项目组在项目开发过程中有义务将 通用的程序模块放入公用程序库中，被其他项目组使用，达到程序共享，避免重复开发。 公用程序库的建立及维护见第八章。 1.6.配置管理计划配置管理计划 配置管理计划应细化以下内容： .6.1.配置工具的选择配置工具的选择 配置管理计划中明确采用的配置工具，如采用 unix 下的 cvs 工具，还必须编写完善 的配置操作脚本，并注明使用方法。 .6.2.配置库的基本目录结构配置库的基本目录结构 根据具体的项目设置配置库的基本目录结构，并进行基本的解释，一般可以包含以下的 一级目录及二

25、级目录： 01 项目工作库 01 准备阶段 02 需求分析阶段 03 系统设计阶段 04 系统实现阶段 05 系统测试阶段 06 运行推广阶段 07 系统维护阶段 02 项目管理库 01 质量保证 02项目管理 03配置管理 04测试管理 03 项目共享库 01 项目模版 02 项目规范 03 项目制度 04 共享资料 04 项目基线库 01 计划基线 02 需求基线 03 设计基线 04 产品基线 05 个人工作库 下设每个项目组成员的目录 06 其他 .6.3.权限设置权限设置 明确项目组成员对各配置目录的操作权限。 .6.4.配置项标识规定配置项标识规定 根据

26、项目规模和实际情况的不同，在项目的配置管理计划中详细规定配置项标识的命名 规则。 .6.5.协作开发规定协作开发规定 在项目的配置管理计划中，必须对项目组的协作开发作相应的规定，比如，项目成员每 日的工作是否必须提交？更改了公用头文件如何通知项目组成员？等等，具体项目具体规定。 .6.6.其它其它 1.7.配置项管理配置项管理 配置项是配置管理的对象，主要包括各种开发/测试文档、源程序、测试脚本、关键数 据、项目报告、会议纪要等。通过建立配置库对配置项的维护、变更等进行管理，对配置项 要进行统一的配置标识管理及名称管理。配置标识就是为产品的结构、产品的构件及其类型，

27、 分配唯一的标识符，具体项目可根据项目规模和实际情况的不同，在项目的配置管理计划中 进一步补充、删减、细化配置项标识的命名规则。开发部的配置项标识及名称总体规则如下： .7.1.配置项标识号命名规范配置项标识号命名规范 配置项标识号命名规则： 项目名标识-配置类别-子系统标识-组成部分标识-模块标识-配置项特殊标识， 其中中的内容可根据系统规模和实际情况有所省略，项目名标识、配置项特殊标 识一般是约定俗成的英文代码名。 下表列出了我们在项目中使用的配置类别命名： 配置类别配置类别说明说明常用配置项特殊标识举例常用配置项特殊标识举例 pdp(project development

28、plan) 项目开发计划 cmp(configure management plan)配置管理计划 qap(quality assurance plan)质量保证计划 frr(feasibility research report)可行性研究 init准备阶段其他文档准备阶段其他文档 crs(client requirement statement)客户需求 srs(software requirement statement) 需求规格说明书 ra(requirement analyse)需求分析阶段其他文档需求分析阶段其他文档 eis(external interface statemen

29、t)外部接口规范说明文档 hld(holistic design)概要设计文档总体方案：-totle dds(detail design statement)详细设计文档 dbd(database design)数据库设计文档数据字典：-dictionary design 设计阶段其他文档设计阶段其他文档 软件架构设计： -architecture；阶段计划： -plan；阶段总结报告： -summarize scode(source code)源代码文件 ecode（executable code）执行代码文件 cf(configure file)配置文件 code实现阶段其他文档实现阶段其

30、他文档 阶段计划：-plan；阶段总结 报告：-summarize utest(unit test)单元测试文档单元测试记录：-record itest(integration test)集成测试文档集成测试记录：-record test测试阶段文档测试阶段文档 测试计划：-plan；测试方案： -scheme；测试案例：-case 测试记录：-record；测试问 题：-problem；测试分析报 告:-summarize man软件说明书和手册 操作手册：-operate；用户手 册：-user；维护手册：- maintenance；安装手册：-setup issue产品发行文档产品发行文

31、档发行记录：-record delivery交付阶段文档交付阶段文档 switch切换阶段文档切换阶段文档切换方案：-scheme smsyyyymm0199 (software maintain statement) 软件维护说明书 maintain维护阶段其他文档维护阶段其他文档维护记录：-record pds(project development summarize)项目开发总结报告 rtm(requirement track matric)需求跟踪矩阵 cryyyymm0199(change record)变更控制号 pryyyymmddaz(peer review)评审号 trai

32、n培训记录和培训文档培训记录：-record project项目其他文档 注 1：粗体部分的配置类别是按软件生存周期的阶段划分的，如配置项具有明确的阶段 性，但不属于某类具体的配置类别，则纳入所属阶段的配置类别中；如是贯穿项目多个 阶段或归属于项目整体的配置项，且不属于某类具体的配置类别，则纳入“project”配置 类别中。 .7.2.配置项名称命名规范配置项名称命名规范 开发技术文档名称通过项目名称标识或项目简称文档类别名称进行命名，主要包括以下文 档： 可行性研究报告； 项目开发计划； 配置管理计划 质量保证计划； 测试计划； 程序开发规范； 需求规格说明书； 总体设计说明

33、书； 概要设计说明书； 详细设计说明书； 数据库设计说明书； 用户手册； 维护手册； 部分文档名称命名时需附加相关信息，主要包括以下文档： 项目周报：项目名标识或项目简称“_项目周报_yyyymmdd” 软件开发进度月报：项目名标识或项目简称“_月报_yyyymmdd” 子项目周报：项目名标识或项目简称“_子项目简称_周报_yyyymmdd” 质量周报：项目名标识或项目简称“_质量周报_yyyymmdd” 会议纪要：项目名标识或项目简称“_会议纪要_yyyymmdd” 软件维护说明书：项目名标识或项目简称“_软件维护说明书_yymm0199” 变更记录：项目名标识或项目简称“_变更记录_yym

34、m0199” 评审记录：项目名标识或项目简称“_评审记录_yymmddaz” 说明：斜体部分根据实际情况用相应内容替代。 .7.3.程序文件、数据文件程序文件、数据文件 按项目开发规范要求执行。 1.8.基线建立及变更管理基线建立及变更管理 基线的是已经正式通过审核批准的某阶段成果，它可作为进一步开发的基础，并且只能 通过正式的变化控制过程改变。一般在某阶段成果通过评审后，对该成果建立基线，纳入基 线管理。（在项目开发的里程碑阶段一般要建立项目基线）。开发过程的阶段成果可以纳入 基线管理的主要有：项目开发计划、测试计划、质量保证计划、业务需求说明书、需求分析 说明书、总体设计说明

35、书、概要设计说明书、程序开发规范、数据库设计说明书、软件维护 手册、用户手册、测试案例、已通过测试的软件版本等。 对项目的每个基线对应一个唯一的标识号。基线标识可采用“bl” +“基线版本号” “-”+“基线日期（yymmdd）表示。 基线类别定义如下：需求基线、设计基线、测试基线、代码基线 基线版本号由 2 个数字组成，格式为：bl1.0 第一位：对每个基线类型（需求基线、设计基线、测试基线、代码基线等），都从 1 开始，增改编幅或重要性比例大于 10，则在原来的基础上加 1。 第二位：增改编幅或重要性比例小于 10，则在原来的基础上加 1 例如： “bl1.0-050101”表示 进入基线

36、管理的阶段成果，是经过评审通过的，配置管理员对其必须进行严格的权限控 制，一般只允许读取，不允许修改，确实需要修改的，执行变更管理流程。 变更管理的一般流程是： a) 获得/提出变更请求； b) 变更预计影响的评估，包括可能受影响配置项以及对资源、进度、质量等影响 的分析，描述实施方案； c) 项目经理审核并决定是否批准，必要时报请领导批准； d) 如变更请求被接受，由配置管理员从配置库中检出配置项，赋予相关人员修改 的权限； e)项目组实施变更，修改配置项的内容，提交确认，如不通过则返回项目组继续 修改； f)配置管理员回收相关权限，把配置项检入，形成新基线版本，发布新版本，并 发布变更通知

37、给所有相关人员，包括项目组成员、质量保证人员、测试人员及 其它部门人员等。 1.9.文档版本管理文档版本管理 .9.1.文档版本及版本号的概念文档版本及版本号的概念 文档的版本用于区别文档的不同状态。每个版本都有唯一的版本号进行标识。版本的概 念对于文档不同的阶段还可以细分为草稿版本（draft versions）、版本（versions）。 草稿版本号：未定稿的文档的版本号称为草稿版本号。 版本号：已定稿的文档的版本号称为版本号。 .9.2.版本号的定义及生成方法版本号的定义及生成方法 草稿版本号 未定稿的文档，在经过修改后，如果觉得有需要，可由负责编写文档的人员

38、制定出新的 草稿版本号。 草稿版本号由前缀加 2 个数字组成，格式为：draft 0.1 第一位：固定为 0 第二位：在原来的基础上加 1 草稿版本号的起始标识为：draft 0.1 草稿版本号的变动：第 2 位数字在原来的基础上加 1。 例如： draft 0.2 - draft 0.3 draft 0.8 - draft 0.9 版本号的生成 定稿的文档，每次的修订后，视文档的重要性由不同权限的人员制定出新的版本号。一 般的文档或者重要文档中的单个文档是可由负责编写文档的人员制定出新的版本号。重要的 文档如需求规格说明书详细设计等阶段性文档，由项目配置管理员与项目经理协商， 在征得项目经理

39、同意后制定出新的版本号。 版本号由前缀加 2 个数字组成，格式为：ver 1.0 第一位：增改编幅或重要性比例大于 10 第二位：增改编幅或重要性比例小于 10 版本号的起始标识为：ver 1.0 版本号的变动：根据其实际情况选择相应位置的数值加 1，并将该位置右边的所有数值 置 0。 例如： ver 1.1 - ver 1.2 .9.3.定版的具体操作方法定版的具体操作方法 文档的定版必须在文档开始处按模板要求填写表格。并在 checkin 到 vss 时将该版本 的改动内容填写到 comment 中。同时还要遵照变更文件审批与确认的规定执行（详见本文 相关段落）。 1.9.4

40、.1.9.4.定版的具体操作方法定版的具体操作方法 示例 1，文挡封面处： xxx 系统系统 需求规格说明书需求规格说明书 示例 2，文挡信息部分： 文档编号版本号密级 xxx-srs1.1秘密 sun trend 中山市森创公司 开发部文档 名称：xxx 系统_需求规格说明书共 120 页 修订历史记录 日期日期版本号版本号修订内容修订内容修订人修订人评审号评审号变更控制号变更控制号 2010.06.090.9新建张三 2010.06.121.0 根据评审问题修改 章节 1.1.3 张三xxx-pr20040612 2010.07.081.1在 1.2.4 中在增 加 张三xxx-cr200

41、40601 1.10. 软件版本管理软件版本管理 .10.1. 定版的具体操作方法定版的具体操作方法 版本用于区别软件产品的不同状态。每个版本都有唯一的版本号进行标识。版本的概念 对于不同的软件产品和不同的阶段还可以细分为测试版本（test versions）、版本 （versions）。 测试版本号：提供测试的可执行文件的版本称为测试版本号。 版本号：通过测试的可执行文件的版本称为版本号。 秘密/机密/绝密当前版本号 .10.2. 版本号的定义及生成方法版本号的定义及生成方法 测试版本号 可执行文件的各部分通过单元测试，总体编译通过，由项目配置管理员与项目经理

42、协商， 在项目经理同意下制定出新的测试版本号。 测试版本号由前缀加 2 个数字组成，格式为：test 0.1 第一位：固定为 0 第二位：在原来的基础上加 1 测试版本号的起始标识为：test 0.1 测试版本号的变动：第 2 位数字在原来的基础上加 1。 例如： test 0.2 - test 0.3 test 0.18 - test 0.19 版本号的生成 可执行文件的各部分通过单元测试，总体编译通过，并通过了系统测试，由项目配置管 理员与项目经理协商，在项目经理同意下制定出新的版本号。 版本号由前缀加 4 个数字组成，格式为：ver 其中，后两个数字可选，即如果后两个数字

43、同时为 0 时，可以同时省去。但版本号一 定是两个或四个数字。 第一位：系统整个框架性设计改动或者业务功能的增改编幅或重要性比例大于 10 第二位：系统部分设计改动或者业务功能的增改编幅或重要性比例大于 5 第三位：系统的代码改动或者业务功能的增改编幅或重要性比例小于 5 第四位：对系统的 bug 修改或者业务功能的增改编幅或重要性均微小。 版本号的起始标识为：ver 1.0 版本号的变动：根据其实际情况选择相应位置的数值加 1，并将该位置右边的所有数值 置 0。如果在同一次的修订中，同时出现两个或以上位置的数值都符合改变的情况时，只 需按照符合条件的最左位的数值加 1，并将该位置右边的所有数

44、值置 0。如果后两个数字同 时为0 时，可以同时省去。 例如： ver - ver - ver 1.2 ver - ver ver - ver ver - ver .10.3. 定版的具体操作方法定版的具体操作方法 每个项目必须有一份版本记录表。当需要生成一个测试版本时，填写测试版本一栏 信息。当某一个测试版本通过了测试，有条件生成一个版本时，在该测试版本所对应的一行 中填上版本一栏信息。当某一个版本需要发布，在该版本所对应的一行中填上发布一栏信息

45、测试版本号和版本号均由项目配置管理员与项目经理协商，在项目经理同意下制定。 版本号栏可根据实际情况填写，发布版本号为空。 版本类型栏选择填写以下之一：测试版本、版本、发布。 对于测试版本的注释栏填写该测试版本与上一测试版本的不同之处，对于版本的注释栏 填写该版本对应的测试版本号以及与上一版本的不同之处，对于发布的注释栏填写该版本发 布对应的版本号以及对生产的影响等情况。 项目负责人栏电子文档填写项目负责人姓名，纸质文件由项目负责人签名。 配置管理员栏电子文档填写项目配置管理员姓名，纸质文件由项目配置管理员签名。 其他相关人员栏如有需要电子文档填写其他相关人员姓名，纸质文件由其他相关人员签 名。

46、其他相关人员如公司经理。 项目配置管理员负责填写版本记录表，并对vss 库中的源代码加上版本号并填 上注释。 版本记录表 项目名称： 序号版本号定版日期版本类型注释项目负责人配置管理员其他相关人员 .10.4. 在在 vssvss 上定版的具体操作方法上定版的具体操作方法 在 vss 上，可以通过加 lable 的功能实现对系统中所有的源代码文件进行加版本号的 管理。 当需要加测试版本号是，选择所有源代码的最高一级目录，为其加上 lable，lable 为： test0.1（0.1 为具体的测试版本号），并在 comment 中填上该测试版的定版日期和注释。 操作完成后，vss

47、 对该目录一下的所有子目录及文件均加上相同的 lable 和 comment。 当需要加版本号时，选择所有源代码的最高一级目录，按右键并选择显示历史信息，然 后在信息中选中标有该版本对应的测试版本号的 lable，双击。在回显框上，修改 lable， 加上当前的版本号，修改后的 lable为：test0.1ver（0.1为具体的测试版本号, 为具体的版本号），并在 lablecomment 中填上该版本的定版日期和注释。操作完成后，vss对该 目录一下的所有子目录及文件均改为相同的 lable 和 lablecomment。 当某一版本需要发布时，按上述操作，选择

48、对应的 lable，并在相应的 lablecomment 中加上发布日期及注释。 1.10.5.版本发布流程版本发布流程 项目组软件版本发布流程如下图所示： 序号序号 流程流程 责任人责任人相关人员相关人员文件文件/ /记录记录说明说明 a01 配置管理 员 配置管理 员 、软件 开发人员 用户测试 报告、开 发、维护文 档、应用 软件版本发 布申请表 开发及维护文 档必须存放项 目配置库中 a02 各项目部 门负责人、 局领导 项目经理、 开发人员 应用软件 版本发布申 请表 严格审核出部 门、公司的技 术文档。 a03 配置管理 员、 相关 部门 项目经理 软件版本、 技术 资料 a04

49、软件接收 部门 开发人员书面通知书内容包括：版 本发布原因、 版本业务功 能、安装时间、 影响范围、安 装后业务验证 内容 a05 项目负责 人 开发人员必要时提供现 场技术支持。 a06 用户、测 试组 开发人员业务验证测 试报告 根据需要进行 a07 项目负责 人 维护人员、 开发人员 必要时现场技 术支持 a08 开始 a01提交版本发布申请 a02审核版本发布申请 a03版本交付 是否需要业务 部门验证测试 a04业务验证测试通知 是 a05版本安装技术支持 否 a06业务验证测试 a07系统运行技术支持 a08保存版本 结束 配置管理 员 综合人员光盘可备份配置库 时进行备份 1.1

50、0.6. 版本保存版本保存 配置管理员必须保证发布版本源程序的完整性及一致性，质量保证人员保证发布版本的 文档的完整性，配置经理及对每一次发布的版本，在配置库中对应地建立版本标识，随配置库备份 刻录光盘时，交综合人员登记并永久保存，综合人员应在光盘标签上标注光盘内容、备份时间、提 交人员，以便查阅。对光盘的查阅必须经部门负责人同意。 1.11. 公用程序库的建立及维护公用程序库的建立及维护 公用程序主要包括： 公用函数模块：提供某一特定功能。 公用类模块：提供具有通用性的类的定义及方法实现。 加密模块：各项目组涉及加密的功能模块由专人开发。 自行开发实用工具：各项目组开发的实用工

51、具。 实现某一功能的完整程序；例如采用 socket 的通讯程序。 具有普遍实用的程序框架；例如 sco unix 下终端程序框架。 其他； 各项目组在项目开发过程中应注意提炼公用程序，共同建设好公用程序库，为今后的项 目开发省时省力。配置经理建立及维护公用程序库，接受、审核公用程序，定期公布公用程 序清单。项目负责人可以根据需要提出使用公用程序的申请，部门负责人审核同意后，配置 经理提供相应程序。 1.12. 配置库的安全管理配置库的安全管理 .12.1. 版本保存版本保存 项目负责人必须明确每个项目成员的操作权限，对配置项的永久删除权限必须严格控制。 .12

52、.2. 配置服务器的安全控制配置服务器的安全控制 配置经理负责配置服务器的系统管理，不允许其他人登录配置服务器进行操作。配置经 理必须做好配置服务器的病毒防范及网络安全控制。 .12.3. 配置库备份配置库备份 配置经理负责进行配置库的备份，主要有： 1)每日备份 每日下班前，配置经理备份配置库中所有配置项，每周循环。 2)每月备份 配置经理每月定期备份文件服务器的共享目录及配置服务器中配置库文件，刻录光 盘由综合人员存放，填写配置库备份登记表。 .12.4. 配置管理平台维护配置管理平台维护 配置经理负责配置管理平台的维护，填写开发部配置管理平台维护日志、配置

53、管 理平台信息表，具体包括： 建立项目配置库； 维护相关人员的权限： 系统软件升级； 病毒防范； 系统资源维护； 1.13.工作空间管理工作空间管理 整个配置库是一个统一的工作空间，可以进一步划分为个人空间、项目组空间和共享空 间这三类工作空间。个人空间是开发人员的私有工作空间，开发人员在自己的个人空间进行 开发活动，不会受到他人的影响，也不会影响到其他开发人员，在个人开发空间开发出的成 果，最终提交到项目组空间中。项目组空间是开发团队的成果空间以及团队共享空间，对项 目组空间的配置项的操作，配置管理员必须做好权限控制及协调管理。共享工作空间是项目 组中子项目组共同工作的空间，子项目组成员拥有

54、对该空间的读写权限。共享工作空间根据 需要建立。 配置管理员及项目负责人必须做好工作空间的分配及管理。 1.14.变更文件的审批与确认变更文件的审批与确认 为了规范化管理，明确责任，避免风险，项目组要做好变更文件的审批与确认工作。 规定每个项目一本变更文件审批与确认登记表，在项目启动时由项目经理负责建立， 填写好项目名称和相关职责人员姓名。 在项目开发生命周期内，由项目组配置代表管理，不得遗失和毁坏。 属于下列情况之一者，必须有相关人员在变更文件审批与确认登记表上签字： 项目的各项计划的制定需要主管部门经理审批，并得到相关部门、相关组或客户的 确认。 对用户需求进行分析整理而成的文档需要经过相

55、关组和部门的确认，并得到用户的 认可。 各个阶段的技术文档要得到相关组和个人的认可。 项目组内所有的变更要得到项目经理的认可。 涉及到资源、约定的变更要得到主管部门经理的批准，并和相关部门进行协调确认。 所有的变更要通知所有受影响的组和个人。 工作产品交接需要相关人员确认。 工作汇报或状态报告需要上级主管确认。 凡签名者，均对相关内容负责，包括风险、保密和责任等方面。如果不能承担责任者， 则需要报送高一级经理批准。 签名者必须用黑色墨水笔认真书写自己真实、完整的姓名，不得随意涂改。 在项目交付完成后，将变更文件审批与确认登记表交开发部综合人员归档保存。 2软件质量保证规范软件质量保证规范 2.

56、1 概述概述 2.1.1 目标目标 本文档依据 cmm 2 级中软件质量保证的要求并结合公司软件开发实际情况对软件开发 项目建立一套可操作的质量保证规范,其目标是以独立审查方式，从第三方的角度监控软 件开发任务的执行,就软件项目是否正遵循已制定的计划、标准和规程给开发人员和管理层 提供反映产品和过程质量的信息和数据，提高项目透明度，同时辅助项目组取得高质量的软 件产品。 2.1.2 方针方针 质量保证工作必须严格按照质量保证规范实施和管理； 质量保证实施过程中所有有效记录必须纳入配置管理； 质量保证实施过程中软件产品、软件过程中存在的不符合问题必须得到处理，必要 时将问题反映给部门领导； 质量

57、保证人员必须熟悉各种标准及规范，明确影响产品质量的各种活动； 质量保证人员必须独立于项目组外，从第三方的角度监控软件开发任务的执行。 2.1.3 核心内容核心内容 规范项目开发过程：按照公司的项目管理方法和软件开发过程规范，并针对本项目 的实际情况，制定项目开发过程规范。 明确项目各项制度，建立良好的沟通机制 。 严格项目计划：制定明确的软件开发计划（包括各阶段计划），并进行必要的跟踪。 明确项目开发过程中各类角色的职责，为项目成员提供培训，确保项目成员具备实 施项目的能力 。 加强需求管理：需求是项目计划和所有活动的基层和依据，加强需求跟踪 。 加强项目阶段成果评审，评审通过后的成果，纳入基

58、线管理，严格执行变更控制流 程。 加强项目质量控制和质量保证，设立专门的、独立的测试小组和质量保证小组（质 量保证人员）。 2.2 质量保证活动组织与职责质量保证活动组织与职责 2.2.1 质量保证组织结构图质量保证组织结构图 项目的质量保证活动涉及到项目所有成员，具体结构如下： 部门领导 专家组 质量保证组 项目开发组测试组 子 项 目 组 子 项 目 组 2.2.2 角色与职责角色与职责 在质量保证活动中各角色的职责如下： 部门领导部门领导 为项目实施及质量保证活动提供资源； 对质量保证组报告中项目组内无法解决的问题予以支持、解决。 专家组专家组 参与本项目各阶

59、段成果评审，为项目组提供业务和技术支持。 质量保证负责人质量保证负责人 负责软件项目开发质量体系的建立； 各项目质量保证人员的指派； 负责质量保证计划维护和关键质量保证活动的审核认可； 将项目组内部无法解决的问题向部门领导报告，督促、申请帮助解决； 负责在质量保证活动实施过程中，逐步改进软件开发质量体系过程； 指导各项目组质量保证人员的质量保证工作。 质量保证人员质量保证人员 结合项目情况和软件开发质量体系，配合项目负责人制定项目规范； 负责编制项目质量保证计划，提交质量组评估报告； 跟踪监督项目及各子项目小组的实施过程，验证评审参与人的资质，监督评审过程 是否符合

60、规范要求； 代码走查（从规范性的角度）； 监督项目过程中的配置管理工作是否按照项目最初制定的配置管理计划和相关规范 进行； 质量保证人员帮助项目开发组、各子项目组发现问题，就问题与项目组达成一致， 督促项目组内部解决，无法内部解决或多次跟催仍没有得到解决的，向质量保证负 责人报告，申请帮助解决； 在质量保证活动实施过程中，收集新方法，提供过程改进的依据。 配置管理人员配置管理人员 编制和维护项目配置管理计划； 配置库的权限设置、空间管理与维护； 对开发人员进行相关的配置管理规程指导和培训； 识别配置管理过程中存在的问题并拟就解决方案； 代码走查，主要检查已实现功能模块是否和需求一