TFS配置管理项目配置管理计划V11.docx

TFS配置管理项目配置管理计划V11.docx

《TFS配置管理项目配置管理计划V11.docx》由会员分享，可在线阅读，更多相关《TFS配置管理项目配置管理计划V11.docx（30页珍藏版）》请在冰豆网上搜索。

TFS配置管理项目配置管理计划V11

凯德商用

TFS配置管理项目

配置管理计划

V1.1

作者：

杨荣峰

日期：

2012-12-03

审批：

日期：

变更记录

版本编号

内容

日期

执行人

批准日期

批准人

V1.0

创建文档

2012-12-03

杨荣峰

2012-12-03

V1.1

定稿

2012-12-05

杨荣峰

V1.1

新增2.3.3和2.3.4章节内容

2012-12-06

杨荣峰

1引言

1.1目的

本文件的目的是为凯德商用配置管理员提供制订软件配置管理计划的依据，以此对凯德商用公司内所有项目进行软件配置管理，提高软件质量，降低软件开发成本。

1.2定义和缩写词

名词定义

SCCB

软件变更控制委员会（SoftwareChangeControlBoard）

SCM

软件配置管理（SoftwareConfigurationManagement）

SQA

软件质量保证（SoftwareQualityAssurance）

CL

配置库（ConfigurationLibrary）

CI

配置项（ConfigurationItem）：

是一组功能或者物理属性的组合，在配置管理过程中，配置项被作为一个单一的实体对待

CR

变更请求（ChangeRequest）

RD

需求开发（RequirementDevelop）

DS

设计（Design）

CO

编码（Coding）

ST

系统测试（SystemTesting）

RL

发布（Release）

审计

对配置管理的独立的查检过程，确认受控配置项满足需求并就绪。

功能审计

审核配置项的实际性能是否符合它的需求

物理审计

验证在配置库中建立基线的配置项是否为正确的版本

PMO

项目管理办公室

BL

基线（Baseline）

基线就是配置项在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态

2组织、角色及职责

2.1软件变更控制委员会（SCCB）

2.1.1职责

∙评审配置管理计划，批准配置管理计划的生效。

∙批准各阶段各类配置管理库的启用和配置管理项/单元标识的有效性。

∙评审和批准对软件基线变更的变更申请。

（主要活动）

∙审定由配置管理库制造的软件生成的正确性。

∙定期或事件驱动审核软件基线和配置管理活动。

2.1.2组织人员名单

姓名

角色

项目组角色

杨巍

组长

IT经理

杨荣峰

成员

项目经理

XXX

成员

业务人员

2.2软件配置管理组（SCM组）

2.2.1职责

∙项目各阶段配置管理库的建立和管理，流策略的实现；

∙制订和维护软件配置管理计划；

∙负责软件基线的更新，审核已执行的对基线的变更；

∙负责对软件基线库的存取管理；

∙定期发布软件配置管理报告、配置管理组行动记录。

2.2.2组织人员名单

姓名

角色

说明

XXX

软件配置管理员

实施本项目的配置管理

XXX

软件变更控制管理员

具体负责本项目的变更控制

XXX

软件质量保证人员

制定《质量保证计划》；

产品检查；过程审计；

跟踪问题处理；度量和报告

2.3角色与职责

2.3.1软件配置管理员

2.3.1.1软件配置管理员

IT部软件配置管理员必须由专人担任，并具有以下规定的2部分工作职责：

⏹组织级工作职责

∙制定配置管理计划；

∙建立并维护配置管理库；

∙建立并发布基线；

∙物理审计（PCA）；

∙跟踪并关闭变更申请；

∙报告配置状态。

⏹项目级工作职责

∙为项目组建立初始的配置库；

∙配合项目经理，制定基于TFS的开发策略和流程；

∙设定TFS中数据的访问权限；

∙执行开发库、受控库和产品库等分支库之间的合并，并在适当时候为版本打标签（label）；

∙定期或事件驱动地执行项目的构建（Build）；

∙执行所有版本的发布；

∙定期备份TFS配置库；

∙定期或事件驱动地进行软件配置状态报告；

∙配合软件质量保证人员（SQA）和项目管理人员进行配置审核；

∙解决日常使用中遇到的TFS系统问题，对TFS系统进行性能优化；

∙对开发人员进行配置管理、工具等相关知识、技能的培训。

2.3.2软件变更控制管理员

软件变更控制管理员负责指导和控制配置管理的各项具体活动的进行，为项目经理的决策提供建议。

其具体职责为以下几项：

基线的建立，变更的批准。

注：

SCCB组长：

负责组织项目中CCB的相关活动，代表CCB组签名审批。

SCCB成员：

参与基线建立和变更的讨论，来源于项目组各类成员的代表，特别是开发类角色的代表。

2.3.3甲方应用经理

根据凯德实际情况，甲方应用经理在软件配置管理过程中应担负的主要职责有：

∙批准建立基线和标识配置项；

∙批准基线的发布；

∙评审与批准基线的变更；

∙批准由基线库生成产品。

2.3.4乙方项目经理

乙方项目经理在软件配置管理过程中应担负的主要职责有：

∙协助配置管理员制定《配置管理计划》；

∙定义基线和配置项；

∙提出发布申请；

∙推动项目的配置管理工作；

∙组织评审。

注：

乙方项目经理除了上述职责外，还需要参与进行甲方应用经理在软件配置管理过程中的职责活动。

2.3.5开发人员

开发人员在软件配置管理过程中应担负的主要职责有：

∙根据分配基线，生成自己负责的配置项，如项目文件、程序代码、调试报告等，并将这些配置项加入到开发库中；

∙执行TFS中的Checkout->Edit->Checkin，实现各种变更；

∙根据需要在TFS受控库中填写变更请求单。

2.3.6测试人员

测试人员在软件配置管理过程中具有以下职责：

∙负责生成自己负责的配置项并加入开发库，如系统测试计划，测试报告等；

∙在配置管理员生成实现基线版本后，提取基线版本进行测试；

∙对测试过程中新发现的问题，在TFS中填写异常报告单；

∙验证受控库中跟自己相关的（已被标识为“已解决”，验证人为自己）的变更；

∙确认异常已解决，且没有引入新的异常之后，验证通过；否则验证失败。

3管理工具与软硬件资源

3.1工具选择

项目采用Microsoft公司的TeamFoundationServer2010进行软件配置管理。

3.2软硬件资源

3.2.1网络

局域网（Windows平台，AD域环境）

3.2.2服务器

在TFS的环境中，使用两台计算机来安装和配置TeamFoundationServer，TeamFoundationServer的服务部署在一个服务器上（称为应用层服务器），TeamFoundationServer的数据库安装在另一个服务器上（称为数据层服务器）。

一个服务器承载TeamFoundationServer使用的SharePointWeb应用程序，另一个服务器还承载TeamFoundationServer使用的SQLServerReportingServices实例。

以下是TFS服务器的设置情况：

主机名

TFS角色

内存

CPU

硬盘

网络设置

XXX

应用层服务器

8GB

1个处理器，3.6GHz

230GB

IP：

XXX

XXX

数据层服务器

8GB

4个处理器，2.6GHz

驱动器阵列，480GB

IP：

XXX

3.2.3操作系统

可以在运行以下操作系统之一的服务器上安装TeamFoundationServer2010。

●带有ServicePack2（SP2）的WindowsServer2003（DatacenterEdition、EnterpriseEdition或StandardEdition）32位版本

●WindowsServer2003R2（DatacenterEdition、EnterpriseEdition或StandardEdition）32位版本

●带有SP2的WindowsServer2003R2（DatacenterEdition、EnterpriseEdition或StandardEdition）32位版本

●WindowsServer2008SP2

●WindowsServer2008R2

3.2.4人员配置

SCM人员：

专职1名

4配置管理活动

4.1配置项标识

4.1.1配置项标识

4.1.1.1配置项的分类

1.项目产品组成部分的工作成果：

∙计算机程序。

如：

源代码、可执行程序等；

∙描述计算机程序的文件。

如：

需求定义、系统分析、系统设计、测试规格说明书、测试计划、安装手册、发布说明、用户手册等；

∙数据。

如：

项目数据、测试数据等。

2.项目管理和机构支撑过程产生的文件：

∙合同类文件。

如:

建议书，用户意向书，合同等；

∙过程管理类文件。

如：

QA及各种过程管理文件，周报和日报，培训记录和培训文等；

∙工具和运行环境。

如：

项目管理和机构支撑过程产生的文件，系统运行平台及环境。

4.1.1.2配置项标识

4.1.1.2.1文件标识

1.配置项标识信息

配置项标识信息包含如下内容：

Ø项目名称

Ø组名（如有）

Ø文件种类

Ø版本编号

Ø文件撰写时间

Ø文件撰写作者

Ø文件修订记录

2.配置项标识

1）文件标识方法

注：

以下由方括号“[]”括起的部分表示一个可选项。

●标识项目信息

Ø命名方式：

<项目缩写><文件种类>[<_子系统名称>][<_模块名称>]

Ø命名示例：

MES2.2详细设计说明书

Ø适用范围：

软件系统所有交付文件。

●标识版本变化

Ø命名方式：

<项目缩写><文件种类>[<_子系统名称>][<_模块名称>]V<发布版本号>

Ø命名示例：

MES2.2详细设计说明书_平台工具_监控服务V1.1

Ø适用范围：

适用于有版本变化的文件。

●标识文件撰写时间

Ø命名方式：

<项目缩写><文件种类>[<_子系统名称>][<_模块名称>]<_撰写日期>

Ø命名示例：

MES2.2会议纪要_生产应用_20121205

Ø适用范围：

会议记录、项目报告等。

注：

对同一内容，在同一天有两个以上的会议时，需要在年月日后加序号。

序号为三位数，从001开始往后编写。

如：

MES2.2会议纪要_生产应用_20121205_001

●标识文件撰写作者

Ø命名方式：

<项目缩写><文件种类><_撰写人名称>]<_撰写日期>

Ø示例：

MES2.2项目周报_张三_20121205

Ø适用于：

项目周报、成员工作周报、年终工作总结等等。

●文件标识

文件首页应该包括如下信息：

项目名称、文件名称、文件作者、本文件的版本更新历史、版本号、日期等。

以下为参考示例：

4.1.1.2.2源程序标识

源程序标识信息包含如下内容：

Ø版权所有者

Ø文件名称

Ø文件功能描述

Ø创建标识（创建人、创建日期）

Ø修改标识

Ø修改描述

注：

每次修改必须新增修改标识与修改描述项

以下为参考示例：

4.1.1.2.3版本号标识

形式：

主版本号[.从版本号][.维护版本号]

注：

由方括号“[]”括起的部分表示一个可选项。

Ø主版本号

对系统进行了重大调整或局部修改累积较多时增加主版本号。

版本号升级由项目经理决定。

Ø从版本号

与上一版本相比，对系统功能或性能进行了少量的增加或修改时增加从版本号，主版本号不变，维护版本号复位为0。

版本号升级由项目组长决定。

Ø维护版本号

　　与上一版本相比，修改了少量系统Bug时增加维护版本号，主版本号和从版本号不变。

版本号升级由项目组长决定。

通常来说，通过系统测试后软件系统版本号变为V1.0，软件系统第一次发布时版本号为V1.0.0，从版本号和维护版本号均为0。

4.1.2里程碑设置

4.1.2.1项目基线

基线是软件文档或源码（或其它产出物）的一个稳定版本,它是进一步开发的基础。

当基线形成后，SCM需要通知相关人员基线已经形成、哪儿可以找到此基线版本。

基线提供了一个正式标准，随后的工作基于此标准，并且只有经过SCCB或项目经理授权后才能变更这个标准。

建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建立下一个基线。

当建立下一个基线时，初始基线将合并自从上次建立基线以来开发人员每次对其进行的变更（已经交付的工作成果）。

变更一旦并入基线，开发人员就采用新的基线，以与项目中的变更保持同步。

以下是项目中常用的基线及其主要内容：

∙需求基线（SRS_BL）：

在需求分析阶段结束后，《用户需求说明书》、《软件需求规格说明书》经过了评审。

∙计划基线（PLN_BL）：

《项目计划》、《质量保证计划》、《配置管理计划》等经过了评审。

∙设计基线（DESIN_BL）：

《概要设计说明书》、《详细设计说明书》、《数据库设计说明书》等设计阶段工作产品经过了评审。

∙代码基线（CODE_BL）：

通过代码单元测试，《集成测试计划》、《集成测试用例》、《集成测试报告》等工作产品也经过了评审。

∙测试基线（TEST_BL）：

通过集成测试，《系统测试计划》、《系统测试用例》、《系统测试报告》等工作产品也经过了评审。

∙发布基线（RELEASE_BL）：

通过软件系统验收测试与正式的配置审核，产生了作为最终产品交付用户的配置项的集合。

4.1.2.2里程碑设置

里程碑

到达时间

需求基线

在软件需求规格说明书批准时建立

计划基线

在项目计划批准时建立

设计基线

在概要设计、详细设计和数据库设计批准时建立

代码基线

在单元测试通过时为集成测试建立

测试基线

在集成测试时通过为系统测试建立

产品基线

在系统验收测试通过为产品发布时建立

4.2配置库的建立与管理

4.2.1配置库规划

4.2.1.1开发库

供开发使用的配置库，用于存放项目期间处于开发状态的相关文件和代码，以及存放项目组工作期间的相关沟通记录等。

开发库由SCM进行管理与维护，开发工程师可以根据权限进行访问；开发人员只能在开发库中自由使用、更改配置项。

4.2.1.2受控库

∙用于存放经过验证后的产品（包括基线产品）；

∙存放通过评审后的软件产品。

此区域的配置项由SCM管理与维护。

由于项目无代码开发，故将开发库与受控库合并到一起，通过文件夹区分开发库与受控库。

4.2.2项目规划

TFS中的项目名称使用“项目英文简称”的格式。

即项目的名称为：

CM。

4.2.3分支策略

初始为项目分别建立一个集成分支。

集成分支的名称使用“Main”命名。

4.2.4目录结构

4.2.4.1开发库目录结构

|--Main

|--Docs项目文档目录

|--MeetingMinutes事件活动、项目会议记录、评审记录

|--R&D设计

|--Requirement需求、需求反馈记录

|--Reference参考文档

|--Manual使用、安装和操作用户手册

|--SCM软件配置管理

|--Summarize经验及总结

|--Releases产品发布

|--Release_20121205项目交付物里程碑

4.2.5用户权限管理

4.2.5.1用户组

组名

说明

CM_ISS_PM

CM项目组乙方项目经理

CM_PM

CM项目组甲方项目经理

4.2.5.2用户组成员

组名

成员

CM_ISS_PM

杨荣峰

CM_PM

杨巍

4.2.5.3权限设置

在TFS中，可以为项目、每个目录和文件设置读写权限。

CM项目中主要对目录进行访问控制。

项目

根目录

CM_ISS_PM权限

CM_PM权限

CM

\Main

读写

只读

\Docs

读写

只读

\Releases

只读

只读

\Release_20121205

只读

只读

4.3配置控制

4.3.1变更控制范围

1.配置项由于审核或测试的需要而发布时，该配置项将纳入配置管理控制中；

2.出现下列情况时，配置项的版本需要更新：

∙评审发现错误，对配置项进行更正；

∙测试发现错误，对配置项进行更正；

∙审计发现错误，对配置项进行更正；

∙其他更改要求。

在上述前三种情况下，《审核报告》、《测试报告》或《审计报告》作为更改源。

其他情况下，项目组填写的《变更申请》是更改源。

3.出现下列情况时，不需要填写《变更申请》：

∙计划级的文档更改，如《项目估计》、《项目计划》；

∙《配置管理计划》、《质量保证计划》或《测试策略》；

∙测试工具或测试脚本（不属于提交给用户）。

4.当项目范围发生变化、风险发生并且采用了项目计划中没有指定的纠正措施、项目计划与实际情况偏离20%以上、由内部与外部审计而导致的纠正活动、项目计划中的任何修改条件满足等事件发生时，由项目经理组织相应的SCCB对要发生的变更进行评审；如果项目计划与实际情况偏离在2%之内，可以不进行审批配置项变更；如果项目计划与实际情况偏离在2%~10%之内，需要CCB进行审批。

4.3.2变更处理流程

4.3.3配置状态报告

《配置状态报告》发布分为定期和事件驱动两种方式，发送方式如下：

发布方式

发布频率

发布对象

发送方式

定期

两周一次

（包括基线变化）

项目组所有成员、SQA

e-mail

事件驱动：

基线发布

基线生成时

项目组所有成员、SQA、高层经理

e-mail

以下为《配置状态报告》：

4.3.4配置审计

SCM按照《配置审计检查单》对配置管理进行检查，审核完毕后填写《配置审计报告》。

配置审计定期每月一次，此外，每次软件版本发布时也要进行配置审计。

配置审计的主要内容如下：

∙检查基线的完整性和准确性，对于生成产品的基线是否存在遗漏；

∙基线的变更是否已完成；

∙基线变更所涉及到的其他配置项是否已作了修改；

∙基线中的各个配置项与SCM基线内容报告是否一致，是否存在遗漏。

以下为《配置审计检查单》的物理与功能审计检查点：

以下为《配置审计报告》：

《配置状态报告》和《配置审计报告》填写完毕后，归档于“\Docs\SCM”中，并邮件发送给业务负责人、项目经理，SCM报告的查阅权限由SCCB确定，由SCM实施控制。

4.4配置库备份与归档

4.4.1配置库备份

SCM制定配置库备份计划，指明“何人”在“何时”（频度）将配置库备份到“何处”。

备份频度

备份人

备份内容

备份方式

备份目录

备份保存时间

日均一次

SCM

配置库

增量备份

本机与备份服务器

一周

4.4.2配置库归档

项目结束时，SCM按CM项目结项规定对配置库进行归档。

5培训

5.1项目组培训

5.2项目经理及相关负责人培训

TFS功能介绍

TFS使用培训

TFS代码迁移培训

5.3配置管理员培训

TFS系统培训

6里程碑

TFS配置管理项目里程碑：

7附录

7.1配置管理概述

软件配置管理（SoftwareConfigurationManagement，SCM）是一种标识、组织和控制修改的技术。

软件配置管理应用于整个软件工程过程。

SCM活动的目标就是为了标识变更、控制变更、确保变更正确实现并向其他有关人员报告变更。

从某种意义上讲，SCM本质上是变更的管理。

SCM使软件产品和过程的变更变为受控的和可预见的，它要求并在TFS工具支持下能够做到以下几点：

1.谁做的变更？

2.软件有什么变更？

3.什么时间做的变更？

4.为何要变更？

7.2配置库建立

7.2.1配置库概念

保存与管理配置项的地方，称为配置库。

通过TFS配置管理软件，对软件系统的配置项进行管理和控制，则整个软件系统就可以称作配置库。

配置库的作用：

∙记录与配置相关的信息；

∙利用库中的信息评价变更的后果；

∙从库中可提取各种配置管理过程的管理信息可利用库中的信息查询回答相关配置管理的问题。

7.2.2配置库类别

7.2.2.1开发库

供开发使用的配置库，用于存放项目期间处于开发状态的相关文件和代码，以及存放项目组工作期间的相关沟通记录等。

由项目组配置管理员进行管理与维护，开发工程师可以根据权限进行访问。

7.2.2.2受控库

用于存放经过验证后的产品（包括基线产品）；建立测试区，用于存放开发工作结束后需要进入测试的配置项，以及为变更实施提供工作空间。

此区域的配置项由项目经理或SCCB评审批准后，由SCM从开发库中更新（move）而来，由SCM管理与维护。

7.2.2.3产品库

存放通过系统测试后的软件产品（等待交付客户运行和现场测试）。

由SCM管理与维护。

7.2.3配置库结构

7.2.3.1开发库结构

目录结构

一级目录

二级目录

存放工作产品示例

010.项目立项

《立项申请表》

《项目建议书》

《项目可行性分析报告》

《项目实施申请表》

《项目立项公告》

《可行性分析报告附表》

《立项评审检查表》

020.项目策划

010.项目策划

《项目总体计划》

《WBS》

《项目估计记录》

《计划变更申请表》

《项目计划申批表》

《特批申请表》

《项目实施计划》

020．配置计划

《配置管理计划》

030.测试计划

《整体测试计划》

040.质保计划

《质量保证计划》

030.需求开发

《需求规格说明书》

《产品功能列表》

《需求跟踪矩阵》

040.系统设计

010.架构设计

《架构设计说明书》

020.概要设计

《概要设计说明书》

030.详细设计

《详细设计说明书》

《数据库设计说明书》

050.编码

010.源代码

程序代码

020.安装包脚本

程序安装包脚步

030.安装包

程序安装包

080.测试

《测试问题报告》

《集成&确认测试计划》

《集成&确认测试用例》

《集成&确认测试报告》

070.用户文件

《产品发布说明》

《用户操作手册》

《用户安装手册》

《升级说明》

《升级包说明》

080.产品验收

《产品移交申请表》

《产品移交文件清单》

090.项目结项

《项目总结报告》

《项目结项评估报告》

100.项目管理

010.项目报告

《项目阶段报告》

《项目监控数据表》

020.配置报告

《软件变更申请表》

《软件变更报告单》

《发布申请表》

《配置状态报告》

《配置审计表》

《阶段活动报告》

030.会议记要

《会议纪要》

04