StarTeam 配置管理

StarTeam 配置管理
StarTeam 配置管理

Starteam内部培训资料

1.starteam概述

软件配置管理作为软件开发过程的必要环节和软件开发管理的基础,支持和控制着整个软件生命周期。若要有效地实施软件配置管理,除了培养软件开发者的管理意识外,更重要的是使用优秀的软件配置管理工具。Starteam是由borland公司推出的很好的配置管理工具,2004年最受欢迎软件排名的前三,目前已经有2005版本。

StarTeam 系列包括 StarTeam Server、StarTeam (Windows 和 Cross-Platform 客户机)、StarTeam Web Edition、StarDisk 以及与第三方产品的各种集成,其中包括 Test Director、Borland JBuilder以及 Microsoft Project。StarTeam可以选择不同的数据库来进行服务器配置,数据库包括:MSDE, Microsoft SQL Server, IBM DB2, Informix, Sybase SQL Server, 或Oracle。综合服务平台项目组使用的是Microsoft SQL Server。

1.1 Starteam程序包

Starteam安装程序包里包含以下内容:

A.StarTeam Client是一个Windows应用程序,提供了一个直观的GUI显示项目、视图、文件夹和文件等等。StarTeam可以与当今许多流行的IDE进行集成,例如:Microsoft’s Visual https://www.360docs.net/doc/c210267542.html,、Jbuilder、C#Builder、Delphi和Oracle。StarTeam可以与PVCS和SourceSafe协同工作,从而允许你转换已存在的SCM项目到StarTeam中。它也提供了一个命令行的接口(stcmd)。

B.StarDisk可以让用户通过一个虚拟的StarDisk驱动器和TCP/IP协议访问文件修订。StarDisk与Windows的集成,提供了对StarTeam的透明访问。

C.跨平台客户端使得可以在支持Java版本1.4或更高的平台上使用命令行接口,这可以使得UNIX用户也可以访问StarTeam。

D.WebEdition通过标准的浏览器方式访问项目库。WebEdition允许用户将文件检入、检出StarTeam、PVCS或VSS库,同时也可以创建、编辑和报告变更请求,还能参与团队讨论。

E.使用StarTeam SDK还可以创建定制化的客户端。

1.2Starteam安装

Starteam 的安装比较简单,没有什么特别的难点。

1)点击setup.exe,进入安装的菜单,选择“Install Products”,starteam将可以安装的

全部显示出来,选择需要安装的内容即可:

next即可。

1.3 Starteam开发模式

starteam提供三种开发模式:本地开发模式、异地互联模式与异地复制模式。

本地开发模式

该模式适用于所有能够访问公司局域网的项目组。如公司研发项目,在公司场所实施开发的应用项目等。该模式的项目组,使用Windows StarTeam Client 客户端。项目组各成员使用StarTeam Client 与公司StarTeam Server 相连。

异地互联模式

该模式适用于在异地开发,无法访问公司的内部网,但能够通过Internet 访问公司的配置管理服务器的项目组。实施该模式的项目组,使用StarTeam WebEdition 或StarTeam Client 客户端工具。该模式下,项目组成员通过接入Internet 网络作为StarTeam 客户端连接到公司StarTeam 服务器。

异地复制模式

该模式下,项目组建立单独的配置管理环境,定期将配置数据上传到公司的配置管理数据库中。该模式适用于在异地开发,网络条件无法保障与公司配置管理服务器连接的项目组。实施该模式的项目组,独立创建项目组配置管理环境,需要定期将配置库文件FTP 到公司指定服务器上,由公司配置管理员将配置数据导入公司配置管理数据库中。

2.StarTeam入门介绍

2.1 项目/项

2.1.1项目

StarTeam 使用项目、视图和文件夹来组织存储在StarTeam库中的项。项目提供了一个组织的附加层次,它为视图提供了一个层次结构,同时也提供了在项目级分配访问权限的机会。通过创建项目,可将文件置于版本控制之下、设置需求、跟踪更改请求、管理任务、审核用户操作以及对项目进行讨论。可在同一个服务器配置上创建多个项目。

每个项目均至少有一个视图,称为初始视图或根视图。项目就是这个项目下所有视图的

集合。

2.1.2项

StarTeam模型使用项,如文件、需求、变更请求、主题、任务和审核日志。这六项组成了starteam的主要内容,也是starteam的主要框架。

大多数常用的项是可以版本化的,就是说,StarTeam存储了项的修订历史并允许你查看和比较不同修订的内容。

项也可以被分支,就是说,它们可以由其它项(那些项就成为了它们的祖先)派生出来。分支项可以与派生出它的原始项进行合并。分支的概念在文档管理系统中并不多见。然而,这一能力对软件配置管理来说则是基础。开发员经常需要在保持原有开发路径的同时作出或大或小的变更。

StarTeam的协作性的框架体系结构支持多种类型的项,并可以根据客户的需要开发和添加更多的项。下表列出了StarTeam的当前版本所支持的项的类型:

2.2视图

starteam中的配置项目是以视图的形式显示给用户。在一个starteam项目中,存在至少一个和多个视图。视图代表了特定配置下的项的集合。

当你打开一个StarTeam项目时,你可以选择默认(或主)视图或者选择另外一个视图。项目的默认视图通常包含用于主要开发的配置。其他视图可以派生于这个视图,也就是说是以它为基础创建出来并具有不同的行为。

2.3 文件夹/文件

2.3.1文件夹

每一个StarTeam视图包含一个文件夹层次,用来组织它的项。文件夹反映了视图代表的配置的逻辑组织结构。文件夹通常具有如下这样的命名:源代码、项目计划、用户手册等。

可以通过对文件夹的操作,实现对6个配置项的访问权限。

文件夹在你需要创建共享项的不同配置时也是有用的。你可以在视图之间或视图内部共享文件夹、文件、变更请求、任务和主题,只要这些视图使用同一个服务器配置。文件夹被共享后,两个视图的用户就都可以访问它的内容了,包括子文件夹及其内容。

2.3.2 文件

StarTeam的基本的配置项就是文件,文件可以是各种类型的格式,starteam唯一的特性

之一是文件信息的灵敏显示。

2.4 变更请求

在 StarTeam 中,更改请求组件提供了一个缺陷跟踪系统,借此可以记录产品、项目或服务中的缺陷并提出可能的改进建议。利用更改请求组件可以:

■将更改请求放入特定的文件夹。

■将更改请求链接到文件、需求、主题或其它更改请求。

■在签入文件的同时将缺陷标记为已解决,在一个应用程序中执行一项操作。

■自动将下一个内部版本标签与已解决的缺陷相关联,使测试者准确知道应该测试哪一个内部版本。

■自动接收与您可能需要修复或检验的更改请求有关的电子邮件。

2.5 需求

通过在StarTeam 中使用需求,业务分析员、管理者、开发者、QA 职员及其他人可以:■以层次化格式组织业务、用户和功能需求。

■指出需求间的依存关系。

■随时查看所有需求层。

■按重要程度确定需求优先级。

■确定需求更改的影响。

■使用需求进行工作估计。

■确定创建需求的人员。

■通知将要负责实现需求的人员。

■在整个生命周期对需求进行跟踪,从提交时起直到完成或拒绝。

■通过将需求链接到文件、更改请求和主题来提供需求上下文。

2.6 任务

任务可以让本地和远程用户汇报分配给他们的工作任务的情况。任务组件可以与MS Project和StarTeam的其他组件进行协同工作,或者作为独立的组件与StarTeam的组件一起工作。

借助该组件,团队成员可以指出何人应在何时做何事、查看当前任务状态、估计完成某项任务所需时间、记录完成该任务所花时间以及将估计时间与实际时间进行比较。由于

S tarTeam 既包含版本控制系统又包含更改请求系统,所以利用它还可以将任务链接到与其相关联的文件、产品缺陷或建议。任务组件既可以独立使用,又可以对来自Microsoft Project 的数据进行交互操作。它能以树格式或列表格式显示任务,前一种格式可清楚地显示任务与子任务之间的关系,后一种格式允许对任务进行排序、分组、查询,或选择所要显示的特定字段。为了提高效率,每项任务均显示有图标,用以标识任务的状态、优先级、里程碑以及需要注意的事项。

2.7 主题

主题是指线索化对话,即指示消息相关方式的系列消息。每一系列消息构成一个树,以初始消息为树根。可将主题组件所提供的线索化对话置于特定的项目文件夹并链接到特定的项目项。例如,可将某个主题链接到由该主题讨论产生的更改请求和文件修订。

StarTeam将线索对话与StarTeam的文件夹层次关联到一起。通过主题组件,可以发起关于项目的一般问题,或者是启动关于某个问题的非常针对性的讨论,如某个特性的实现;而主题的响应可以造成这些问题的解决,对话的历史记录对于项目来说甚至显得非常重要,未来的团队成员可以使用它:

1、更好的对决策重新评估;

2、避免重新尝试先前已经发现为错误的解决方案;

3、理解为什么某个特定的解决方案对问题来说是必须的,并且没有替代的方案能够满足所有需要满足的条件。

与新闻组类似,主题为讨论提供了一个社区,从而项目中的每一个人可以互相交流而无须使用不可跟踪和非线索的e-mail消息。主题驻留在一个被版本化的集中性的区域中,经过正反双方或经过多方的讨论后,就可以进行相应的任务分配了。

2.8 审核日志

StarTeam 审核日志是按时间顺序所做的记录,其中累积的数据记载了对文件夹、文件、需求、更改请求、任务和主题所执行的操作。每个日志条目均显示有执行操作的用户、执行操作的日期和时间、类名(项类型)、事件(操作类型)、视图名以及项目名。使用筛选器或查询可以查找特定项的所有条目。

对于大多数项而言,可能的事件有添加、分支、注释、创建、删除、修改、移动自、移动至和共享。对于文件,事件可能还包括转换、编辑、改写项、锁定、断开锁以及解锁。日志条目本身不能进行移动、共享、修改或分支。如果StarTeam 窗口的Audit(审核)选项卡未显示任何条目,可能是管理员已禁用了审核日志功能。

3.StarTeam的管理

3.1 配置starteam server

3.1.1 使用 Server Tools 创建服务器配置:

1 在安装了 StarTeam Server 的计算机上,选择开始 > 程序 > StarTeam > StarTeam Server x.x StarTeam Server。出现 Server Tools (服务器工具)对话框。

2 单击 New (新建)。此操作将显示 Create a New Configuration (创建新配置)对话框,可在其中定义新配置。

3 在 Configuration name (配置名称)文本框中输入一个唯一的名称。

4 在 Repository Path (储存库路径)文本框中,输入或浏览到 StarTeam Server 将创建服务器配置文件的位置。

5 从 Database Type (数据库类型)列表框中选择一种数据库类型。可以选择Microsoft SQL Server/MSDE 和 Oracle。一旦创建了服务器配置,便无法更改数据库类型。

6 选择或取消选择 Create new StarTeam database and ODBC data source (创建新StarTeam 数据库和 ODBC 数据源)。默认情况下会选中此选项。

7 在 Initial Hive Settings (初始配置单元设置)中,选择 Default (默认)或Custom (自定义)配置单元选项。

8 如果选择 Default(默认)配置单元,则更改储存库路径将会更改默认配置单元设置。如果选择 Custom (自定义)配置单元,则更改储存库路径不会产生这种影响。

9 如果创建的是 Custom (自定义)配置单元,可以覆盖默认配置单元设置。可更改以下任何字段:

■ Name (名称):配置单元的唯一名称。默认名称是 DefaultName。

■ Archive path (存档路径):配置单元 Archives 目录的路径。默认值

■ Cache path (高速缓存路径):配置单元 Cache 目录的路径。默认值为

■ Maximum cache size (最大高速缓存大小):“高速缓存”可以使用的最大硬盘空间兆字节数。默认值为设置此选项时可用磁盘空间的 20%。

■ Cache cleanup interval(高速缓存清理时间间隔):相邻的高速缓存清理/ 刷新操作之间间隔的秒数。默认值为 600。范围是 60 (1 分钟)到 3153600 (1 年)。

■ Storage limit threshold (存储限制阈值):总磁盘空间中可用于配置单元的百分比。达到此百分比时,便不能再向配置单元添加存档。默认值为总磁盘空间的95%。

10 填完上述信息后,单击 Next (下一步)。此操作将显示 Create a [Database] DataSource (创建 [Database] 数据源)对话框的第一个屏幕。必须输入的信息取决于所选择的数据库。创建完服务器配置后,便不能更改 ODBC 数据源。Microsoft SQL Server 或 MSDE 数据库要求输入以下信息:

■ Host name (主机名)

■ Sys Admin (sa) password (系统管理员密码)

■ ODBC data source name (ODBC 数据源名称)

■ New database name (新数据库名)

■ New database login name (新数据库登录名)

■ New database password (新数据库密码)

■ Confirm database password (确认数据库密码)

以下是 Create a Microsoft SQL Server/MSDE Database (创建 Microsoft SQLServer/MSDE 数据库)对话框的示例:

对于 Oracle 数据库,请在以下字段中输入文本:

■ TNS service name (TNS 服务名)

■ System password (系统密码)

■ New ODBC datasource name (新 ODBC 数据源名称)

■ New schema user name (新模式用户名)

■ New schema password (新模式密码)

■ Confirm schema password (确认模式密码)

11 填完上述信息后,单击 Next (下一步)。

a 对于 Microsoft SQL Server 或 MSDE 数据库,将出现 Create a Microsoft SQLServer/MSDE Data Source(创建 Microsoft SQL Server/MSDE 数据源)对话框。

1 查看该对话框。

2 如果要编辑数据文件和事务文件的大小或位置,请取消选中 Use defaultconfiguration (使用默认配置)并进行更改。Microsoft 根据许可证将 MSDE数据库的大小限制为 2048 MB。如果需要更大的数据库,必须购买 MicrosoftSQL Server 许可证。

3 如果信息正确,请单击 Finish (完成)。将显示一条消息,指出已成功创建服务器配置。

b 对于 Oracle 数据库,将出现 Create an Oracle Data Source (创建 Oracle 数据源)对话框。

1 查看该对话框。

2 根据需要编辑 Tablespace name (表空间名)、Initial Size (初始大小)和Location (位置)。

3 如果信息正确,请关闭该窗口。将显示一条消息,指出已成功创建服务器配置。

12 完成新服务器配置后,它会出现在 Server Tools (服务器工具)对话框中,且其状态为 New (新)。选择该配置,然后单击 Start Server (启动服务器)。StarTeamServer 随即会初始化数据库并创建默认配置单元和文件夹。初始化过程可能需要几分钟。StarTeam Server 完成此活动后,该服务器配置的Status (状态)列会从 New (新)变为 Running (正在运行)。

13 在服务器配置开始运行后,单击 Exit (退出)关闭 Server Tools (服务器工具)对话框。

3.1.2 启动和停止服务器配置

1.启动服务器配置:

1)在安装了 StarTeam Server 的计算机上,选择开始 > 程序 > StarTeam > StarTeamServer x.x > StarTeam Server。出现 Server Tools (服务器工具)对话框。

2)选择要启动的服务器配置,然后单击 Start Server (启动服务器)。

3) 服务器配置完成启动过程后, Status (状态)列会变为 Running (正在运行)。单击Close (关闭)以关闭 Server Tools (服务器工具)对话框。

2.停止服务器配置:

1) 在安装了 StarTeam Server 的计算机上,选择开始 > 程序 > StarTeam > StarTeamServer x.x > StarTeam Server。此操作将显示 Server Tools(服务器工具)对话框。

2) 选择要停止的服务器配置,然后单击 Shut Down (关闭)。系统将显示以下消息:

3) 单击 OK (确定)。

4) 当服务器配置的 Status (状态)列从 Running (正在运行)变为 Ready (就绪)时,服务器配置即被停止。

5) 单击 Exit (退出)关闭 Server Tools (服务器工具)对话框。

3.2 创建starteam 项目

StarTeam 项目通常建立在文件夹层次基础之上,这些文件夹位于您的计算机上,或位于您在共享文件服务器上的个人目录中。在下面的图中,左侧窗口显示的是位于计算机的项目的工作文件夹;右侧窗口显示的是StarTeam 项目视图。

不过,您的工作文件夹及其子文件夹不必与该StarTeam 项目完全一样。例如,您可以从StarTeam 项目中省略工作文件夹中的子文件夹,或只将现有StarTeam 项目中的特定子文件夹复制到工作文件夹。您可以在任何服务器配置上创建项目,只要您具有在该位置创建项目所需的权限。创建项目时,必须输入项目名并指定工作文件夹的位置。创建项目时,会同时在StarTeam中创建该项目的初始视图以及根文件夹。默认情况下,它们会采纳与项目相同的名称,但如果您愿意,可在以后更改这些名称。

创建StarTeam 项目具体步骤:

1 在您的计算机上创建一个名为“01工作库”的文件夹,并在其中放置若干文件。

2 选择开始 > 程序 > StarTeam > StarTeam x.x。

3 将“01工作库”文件夹从您的计算机拖动到 StarTeam 主窗口。出现 New ProjectWizard (新建项目向导)。

4 如果尚未将所需的服务器配置添加到您的计算机工作站,请单击 Add Server (添加服务器)。此操作将显示 Add Server (添加服务器)对话框。

在对话框中:

a 在 Server Description (服务器说明)文本框中输入服务器的描述名。服务器名必须唯一。它不区分大小写,且不能包含冒号 (:)、正斜线 (/) 或反斜线 (\),但可包含空格或撇号。

b 在 Server Address (服务器地址)文本框中,输入确切的计算名或 IP 地址。如果需要浏览查找确切的名称,请单击 Browse (浏览)按钮。

c 在 TCP/IP Endpoint (TCP/IP 端点)文本框中输入端点。端点是指端口号。

d (可选)选中 Compress Transferred Data (压缩传输数据)复选框,以压缩在您的计算机与该服务器配置之间传输的数据。

e (可选)如果要防止未授权方通过不安全的网络线路读取在您的计算机与该服务器配置之间传输的数据,请选中 Encryption (加密)类型复选框。加密类型(从上到下)按速度排序。每种加密类型都比其上面的类型慢,但更安全。

f 单击 OK (确定)。重新打开 New Project Wizard (新建项目向导)。在打开现有项目或从 starTeam 菜单栏中选择 Tools (工具) > Server Administration (服务器管理)时,也可以添加服务器连接。

5 从服务器列表框中选择服务器配置,然后单击 Next (下一步)继续。出现 Log Onto [server: port] (登录到 [server:port])对话框。

6 输入 Administrator 作为 User Name (用户名),输入 Administrator 作为Password (密码)。出现 New Project Wizard: Project Name (新建项目向导:项目名)对话框。

7 在 Project Name (项目名)文本框中输入名称。如果创建项目时使用的是拖放方法,则默认项目名为所放文件夹的名称。

8 在 Project Description (项目说明)文本框中输入说明。

9 单击 Next (下一步)继续。出现 New Project Wizard: Working Folder (新建项目向导:工作文件夹)对话框。默认的工作文件夹名称为放入 StarTeam 的文件夹的名称。请勿更改该名称,因为您将要从此位置添加文件。

10 单击 Next (下一步)。出现 New Project Wizard: Child Folders (新建项目向导:子文件夹)对话框。

11 如果工作文件夹有子文件夹,可在此对话框中将其选定,然后单击 Exclude (排除)将其从 StarTeam 文件夹层次中省略掉。要重新列出已排除的文件夹,请单击Reset (重置)。

12 要完成项目,请单击 Finish(完成)。StarTeam 随即将在项目窗口中显示初始视图。3.3 向项目视图添加文件

点击not in view 文件的右键,选择菜单中的“Add Files”,显示下面的对话框:

加入文件的描述信息,点击“ok”即可。

3.4 创建其它项目视图

Starteam提供在项目视图的基础上创建新视图的功能。创建分支视图:

1 在已经存在的项目中,选择 View (视图) > Select View (选择视图)。然后选择出现在列表顶端的初始视图。此视图将成为新视图的父视图。

2 在 View (视图)或上下文菜单中,选择 New (新建)。出现 New View Wizard(新建视图向导)。

3 在下拉 View type (视图类型)框中,选择 Branch all (全部分支),以便将新视图中的所有项都设置为更改时分支。

4 输入View name (视图名称),并在 View description (视图说明)文本框中输入Branching view。

5 单击 Next (下一步)。出现 New View Wizard: Root Folder (新建视图向导:根文件夹)对话框。

6 从树中为此视图选择根文件夹。如果是对整个父视图进行分支,必须使用父视图的根文件夹。然后单击 Next (下一步)。出现 New View Wizard: Working Folder(新建视图向导:工作文件夹)对话框。

7 单击 Finish (完成)。

3.5 添加组

在starteam中,将用户分成组,可以方便对用户权限的管理,这里介绍一下如何添加一个组。从您的计算机工作站创建组:

1 从 StarTeam 菜单栏中选择 Tools (工具) > Server Administration (服务器管理)。出现 Server Administration (服务器管理)对话框。

2 单击 User Manager (用户管理器)。登录后,或者如果您已经登录,会出现 User Manager (用户管理器)对话框。

3 从 Groups (组)树中选择 All Users (所有用户)组作为新组的父项。Borland 建议将每个新组均作为 All Users (所有用户)组或其某一子组的子项。

4 单击 New Group (新建组)。出现 New Group Properties (新建组属性)对话框。

5 点击“确定”即可增加一个组信息。

3.6 添加用户

添加用户步骤:

1 从 StarTeam 菜单栏中选择 Tools (工具) > Server Administration (服务器管理)。出现 Server Administration (服务器管理)对话框。

2 选择已经配置好的服务器。

3 单击 User Manager (用户管理器)。登录后,或者如果您已经登录,会出现 UserManager (用户管理器)对话框。

4 从 Groups (组)树中选择 All Users (所有用户)组。所有用户都必须是此组的成员。

5 单击 New User(新建用户)。出现 New User Properties(新建用户属性)对话框。

6 输入信息,点击“确定”即可。

7 点击新增人员的名字,点击右键,会出现下列对话框:

选择“Add Named User License”之后,此用户就可以登陆了。

8 对于已经存在的用户,可以用右键的“Suspend account”功能将此用户权限收回,可以用“Reactivate Account”功能将此帐号再次激活。

3.7 设置访问权限

在starteam中,对于每个项都有权限访问的设置。具体的操作步骤如下:

1.点击需要设置访问权限的项目,点击右键,选择access rights….

2.对于此文件夹下关联的文件夹、子文件夹、文件、CR、requirement、task、topic都可以分别进行权限的设置。

3.点击“add”将权限赋给一个user或者一个group。

注意:选择的时候,确定选择了grant/deny。对于一个配置项,如果没有赋予grant权限,则千万不要赋予deny,否则,会导致这个配置项不能用。

4.StarTeam的使用

4.1 使用starteam客户端

1.运行starteam客户端,显示出如下窗口:

软件配置管理计划模板

卷号DEPLOY 卷内编号DEPLOY005 密级组内 HD20090917SR005 通用型行政审批服务协同管理平台 配置管理计划 1.2 项目承担部门:java第四组 撰写人(签名):区允文 完成日期:2010年8月4日 本文档使用部门:■主管领导■项目组 □客户(市场)□维护人员□用户 评审负责人(签名):江威龙 评审日期:2010/8/4

目录 1.简介4 1.1目的4 1.2范围4 1.3定义、首字母缩写词和缩略语4 1.4参考资料4 1.5概述4 2.项目配置4 2.1组织结构4 2.2职责和接口5 2.3工具、环境和基础设施5 3.配置管理活动6

3.1配置库6 3.1.1配置库架构6 3.1.2权限分配7 3.1.3配置库层次及开发活动说明:8 3.2配置标识9 3.2.1标识方法9 3.2.2项目基线10 3.3配置项11 3.4配置和变更控制11 3.4.1变更请求的处理和审批11 3.4.2变更控制委员会 (CCB)11 3.4.3变更过程中的活动11 3.4.4变更过程中的变更请求状态12 3.4.5保存变更历史记录13 3.4.6变更请求中受影响配置项的变更13 3.5配置状态统计14 3.5.1项目介质存储和发布进程14 3.5.2报告和审计14 4.里程碑15 5.培训和资源15 6.分包商和厂商软件控制15 7.附录15

配置管理计划 1.简介 1.1目的 为了使项目相关的各种资源便于查看,修改,不至于凌乱;为了让各个开发人员方便高效地协同合作;为了项目的版本便于管理,作出此配置管理计划。 1.2范围 项目进行中所得出的所有工件都要遵守此计划,包括文档以及源代码,以及硬件。 1.3定义、首字母缩写词和缩略语 CM:配置管理。 CCB:变更控制委员会。 CI:配置项。包含文档、程序。 Baseline:基线。 CR:变更请求。 PCA:物理审计。 FCA:功能审计。 1.4参考资料 《华南农业大学软件学院实训讲义》 《华南农业大学项目阶段评审工件》 1.5概述 此文档对项目开发过程中的配置方面作出约束,开发以及变更都要按照要求来做。 2.项目配置 2.1组织结构

软件配置管理规定

软件配置管理规定? 为进一步加强软件配置管理工作,明确软件配置原则,规范软件配置流程,制定本规定。 一、配置原则? 1、软件配置遵循安全性、适用性、 2、单经济性与正版化得原则,不得配置非正版软件。? 位使用得商业软件、OEM软件、免费软件均需纳入配置管理,不得配置与工作无关得各类软件。?3、优先采用场地授权(许可)方式配置软件。 二、配置流程 1、软件使用部门根据本部门各岗位工作需要,编制岗位软件需求清单,填写《软件使用需求申请表》(附件1)。 2、信息化部门统计、汇总软件使用部门报送得《软件使用需求申请表》,对软件使用部门需要得相关软件进行统一测试与试用,综合考虑软件得价格、兼容性、安全性与售后服务等因素,确定软件选型,明确软件名称与版本.涉及使用免费软件得,更新《可使用免费软件清单》(附件2)。 3、信息化部门依据单位软件使用管理台账,梳理单位软件需求与现有软件许可得差异。单位软件许可不足得,编制《软件采购计划表》(附件3)。 4、财务部门要将软件采购纳入单位年度预算。财务、资产管理部门指导信息化部门完成软件采购。软件采购合同要明确软件名称、版本、授权方式、许可数量、使用年

限、兼容性与售后服务等要求。?5、财务、资产管理部门指导信息化部门做好软件采购相关资料管理工作,重点就是软件采购合同、软件授权证书、软件安装序列号等资料得管理工作。? 6、信息化部门负责软件使用管理日常工作。?7、单位采购得软件,因以下情况申请报废得,需经过信息化部门鉴定,严格履行资产处置报批手续:?(1)已经达到规定得最低使用年限,且无法继续使用得.?(2)未达到规定得最低使用年限,因技术进步等原因无法继续使用得。?(3)未达到规定得最低使用年限,因计算机硬件报废,且无法迁移到其她计算机上继续使用得. 8、信息化部门在单位新采购软件、报废软件与调整可使用免费软件清单后,更新《软件使用情况汇总表》(附件4)。

软件开发项目配置管理工具的选择

软件开发项目配置管理工具的选择 通过软件配置管理,将对软件系统中的多重版本实施系统的管理;全面记载系统开发的历史过程,包括为什么修改,谁作了修改,修改了什么;管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制,完整、明确地记载开发过程中的历史变更,形成规范化的文档,不仅使日后的维护和升级得到保证,而且更重要的是,这还会保护宝贵的代码资源,积累软件财富,提高软件重用率,加快投资回报…… 每一个软件项目,无论是工程类项目,还是产品类项目,都必须经历需求分析、系统设计、编码实现、集成测试、部署、交付、维护和支持的过程。在这个过程中,将生成各种各样不同的工件,包括文档、源程序、可执行代码、支持库。更可怕的是,频繁出现的变更是不可避免的,因此面向如此庞大且不断变动的信息集,如何使其有序、高效地存放、查找和利用就成为了一个突出的问题。 针对这一问题,最早的开发人员尝试过的解决办法是通过手工来实现: 1)文档:每次修改时都另存为一个新的文件,然后通过文件名进行区分,例如"XXX 软件需求说明书V1.0,XXX软件需求说明书V1.1,XXX 软件需求说明书V2.0.",并且在文件中注明每次版本变化的内容; 2) 源代码:每次要修改时就将整个工程目录复制一份,将原来的文件夹进行改名,例如"XX 项目V1.0、XX 项目1.01、.",然后在新的目录中进行修改; 但是这种方法,不仅十分繁琐,容易出错,而且会带来大量的垃圾数据。如果是团队协同开发或者是项目规模较大时,还是会造成很大的混乱。很显然,这样简陋的方法是无法应对这一问题的。后来,有人尝试从制造工业领域引入了"配置管理"这一概念,通过不懈的研究与实践,最终形成了一套管理办法和活动原则,这也就是软件配置管理。 通过软件配置管理,将对软件系统中的多重版本实施系统的管理;全面记载系统开发的历史过程,包括为什么修改,谁作了修改,修改了什么;管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制,完整、明确地记载开发过程中的历史变更,形成规范化的文档,不仅使日后的维护和升级得到保证,而且更重要的是,这还会保护宝贵的代码资源,积累软件财富,提高软件重用率,加快投资回报。 常见的配置管理工具 正如前面所述,由于软件配置管理过程十分繁杂,管理对象错综复杂,如果是采用人工的办法不仅费时费力,还容易出错,产生大量的废品。因此,引入一些自动化工具是十分有裨益的,这也是做好配置管理的必要条件。 正是因为如此,市场上出现了大量的自动化配置管理工具,这些工具的实现原理与基本机制

软件配置管理流程

配置管理流程规定 (Ver1.0) 拟制:___________________ 审核:___________________ 签发:___________________

目录 1.配置管理流程 (3) 1.1概述 (3) 1.2总体流程图 (3) 1.3软件需求分析阶段 (4) 1.4软件设计阶段 (4) 1.5制定配置管理计划 (4) 1.6配置库管理 (4) 1.6.1相关人员分配权限 (4) 1.6.2配置项 (5) 1.7版本控制 (6) 1.8变更控制 (6) 1.9配置审计 (8) 1.9.1配置审核的类别 (8) 1.9.2配置审核执行的时机 (8) 1.9.3不符合项的处理 (8) 2.0.0配置状态报告 (8) 2.0.1配置状态报告的目的 (8) 2.0.2配置状态报告记录的内容 (8) 2.0.3配置状态报告的生成 (9) 2.1.0发行管理 (9) 2.1.1交付管理 (9) 2.软件基线化规范 (10) 2.1正常开发期 (10) 2.2版本发布期 (11) 2.3项目发布期 (13) 3.Jira配置管理 (14)

1.配置管理流程 1.1概述 规范配置管理活动,确保配置项正确地唯一标识并易于存取,保证基准配置项的更改受控,明确基线状态,在贯穿整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2总体流程图

1.3软件需求分析阶段 参加需求分析会议,配置管理负责人记录,有关文档提交归档。如《需求分析》。 1.4软件设计阶段 参加设计阶段,为了详细制定配置管理计划。针对需求分析报告进行系统设计,配置时应说明系统设计的版本与需求分析报告版本的对应关系。设计书评审通过后,建立设计基线。 1.5制定配置管理计划 配置管理员制定配置管理计划,主要内容包括配置管理软硬件资源、配置项计划、备份计划等,审批该计划。 1.6配置库管理 配置管理员为项目创建配置库,并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。 1.6.1相关人员分配权限 项目经理: 1)与(有关负责人员)协商确定项目起始基线 2)接受配置管理计划,并按相关规定贯彻执行; 3)接受配置控制委员会的报告。 4)提出配置管理计划的修改要求; 5)提出管理管理的建议和要求。 配置管理员 1)编制配置管理计划; 2)执行配置项管理; 3)执行版本控制和变更控制方案; 4)编制配置状态报告; 5)配置库的建立和权限分配; 6)配置管理工具的日常管理与维护; 7)配置库的日常操作和维护 开发人员

项目平台配置管理计划

XX项目 平台配置管理计划文件修改控制 XX公司 2015年5月

目录 第1章引言 (3) 1.1.目的 (3) 1.2.术语定义 (3) 1.3.参考资料 (3) 第2章软件配置 (4) 2.1.软件配置环境 (4) 2.1.1 服务器软件环境 (4) 2.1.2 硬件环境 (4) 2.1.3 配置管理客户端 (4) 2.2.软件配置项 (4) 2.2.1 受控配置库 (4) 2.2.2 非受控配置目录 (5) 2.3.配置管理员 (5) 第3章软件配置管理计划 (4) 3.1 建立示例配置库 (4) 3.2 配置标识管理 (4) 3.3 配置库控制 (5) 3.3.1 权限控制 (5) 3.3.2 配置库的控制 (5) 3.3.3 建立软件库 (5) 3.3.4 软件配置更改 (5) 3.4 配置的检查和评审 (6) 3.5 配置库的备份 (7) 3.6 配置管理计划的修订 (7) 3.7 配置管理计划附属文档 (8) 第4章里程碑 (9) 附录1 文档命名规定 (1) 1、受控配置库文件命名规则 (1)

2、非受控配置库文件命名规则 (1) 3、提交文档文件命名规则 (2) 附录2 帐号及权限管理 (3) 附录3 配置库使用规定 (5)

第1章引言 1.1.目的 本文档目的在于对XX项目进行软件配置管理,提高软件质量,降低软件开发成本。 本文档内容主要参考研发中心相关的制度文档,并在这基础上整理成适合本项目的软件配置管理,为项目经理、配置管理员及相关人员提供日常的配置管理操作步骤。 1.2.术语定义 软件配置管理:简称SCM(Software Configuration Management 的缩写),是在项目开发中,标识、控制和管理软件变更的一种管理。配置管理的使用取决于项目规模和复杂性以及风险水平。软件的规模越大,配置管理就显得越重要。 基线:(BaseLine) 是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准,随后的工作基于此标准,并且只有经过授权后才能变更这个标准。建立一个初始基线后,以后每次对其进行的变更都将记录为一个差值,直到建成下一个基线。 配置管理员:项目组中负责配置管理工作的角色,该角色可以兼职。在某一开发阶段通过评审或某一质量检查点通过审核后,配置管理员负责统一添加或修改相关文档的最新有效版本以及审批人签字。 配置标识:(Configuration Identification)对软件项目在开发过程中的资源进行标识,以便识。 配置检查:(Configuration Audit)对软件配置管理过程中的行动进行检查。 1.3.参考资料 暂无

16软件配置管理报告

份号:001 密级: XXXXXXXX项目 软件配置管理报告 XXXX-RPB-R01.00 XXXXXXXX公司 XXXX年XX月XX日

辑要页

文档修改记录

目次 1 范围 (1) 1.1标识 (1) 1.2系统概述 (1) 1.3文档概述 (1) 2 引用文挡 (1) 3 软件配置管理情况综述 (1) 4 软件配置管理基本信息 (1) 5 专业组划分及权限分配 (1) 6 配置项记录 (1) 7 变更记录 (2) 8 基线记录 (2) 9 入库记录 (2) 10 出库记录 (2) 11 审核记录 (2) 12 备份记录 (2) 13 测量 (2) 14 主释 (2)

1 范围 1.1 标识 本条应描述本文档所适用的系统和软件的完整标识,适用时,包括其标识号、名称、缩略名、版本号和发布号。 1.2 系统概述 本条应概述本文档所适用的系统和软件的用途。它还应描述系统与软件的一般特性;概述系统开发、运行和维护的历史;标识项目的需方、用户、开发方和保障机构等;标识当前和计划的运行现场;列出其他有关文档。 1.3 文档概述 本条应概括本文档的用途和内容,并描述与其使用有关的保密性考虑。 2 引用文挡 本章应列出引用文档的编号、标题、编写单位、修订版及日期,还应标识不能通过正常采购活动得到的文档的来源。 3 软件配置管理情况综述 本章应描述软件配置管理活动进展,与软件配置管理计划的偏差;软件配置管理活动与规程是否相符;对不符合项所采取的措施;完成软件配置管理工作的工作量等。 4 软件配置管理基本信息 本章应概述软件配置管理的基本信息,包括项目负责人、各级软件配置管理机构组成人员和负责人、软件配置管理所用的资源(如计算机、软件和工具)等。 5 专业组划分及权限分配 本章应列出项目专业组的划分、各专业组的成员以及各成员的权限分配,如专业组可分为项目负责人、开发组、测试组、质量保证组、配置管理组等,权限可分为读出、增加、替换、删除等。 6 配置项记录 本章所列出项目的所有配置项,包括配置项名称、配置项最后发布日期、配置项控制力度(控制力度可分为基线管理、非基线管理(受到管理和控制))、配置项版本变更历史、配置项变更累计次数等内容。

配置管理流程

配置管理流程 Company Document number:WUUT-WUUY-WBBGB-BWYTT-1982GT

简介 业务目的: 为解决、控制过程及部分服务交付过程提供需要的配置项及其属性信息。 IT 目的: 1)建立一个完整的配置项管理框架,降低了无控制环境变更的危险性; 2)CMDB提高支援及各类服务活动的效率和品质,确保服务交付流程如连续性、容量等良好运作。 适用范围 此流程适用IT管理手册中定义的服务范围。 相关流程 IT服务管理手册 (QM-ITSM-2011) 服务规划及管理流程(OP-ITSM-004) 服务报告管理流程 (OP-ITSM-006) 事件和服务请求管理流程 (OP-ITSM-007) 问题管理流程 (OP-ITSM-008) 变更管理流程 (OP-ITSM-010) 发布管理流程 (OP-ITSM-011) 连续性管理流程 (OP-ITSM-012) 容量与可用性管理流程 (OP-ITSM-014) 信息安全管理流程 (OP-ITSM-015) 供应商管理流程 (OP-ITSM-017) 服务策划管理流程(OP-ITSM-019) 定义 术语表: 无 角色定义表

仪器种类代号

编号格式 主要设备按以下方式进行编号登记: XX9999YY XX = 仪器种类代号 9999 = 4至5位数字 YY = 地域代号内的缩写式代号 内容 流程解释 配置管理流程从配置规划、日常运维、配置审计、配置管理检讨的PDCA循环保障CI的完整性和有效性,其中配置规划包括配置管理应用的各类规则。 配置规划 (P) 5.2.1配置管理范围工具、用途说明:

软件配置管理规范.doc

软件配置管理规范1 1.简介 软件配置管理的目的是保证在整个软件生命周期中软件产品的完整性。 1.1 目的 本文档指导项目开展配置管理活动。 1.2 范围 本文档适用于SWL开发小组批准立项的软件项目。 1.3 文档结构 第一部分: 简介,包括本规范的目的、范围、词汇以及所涉及到的参考信息。 第二部分: 配置管理工作规范的正文,包括活动的流程图、进入能及退出的准则、所涉及的角色、相 关活动的阐述、验证与确认能及度量。 第三部分: 变更控制工作规范的正文,包括活动的流程图、进入能及退

出准则、所涉及的角色、相关 活动的阐述、验证与确认能及度量。 第四部分: 参考文献,列出了编写本规范所参考的相关的文献资料。 第五部分: 附录,本文中流程图的标准符号定义。 1.4 词汇表 CM (Configuration Management) 配置管理。 CCB (Change Control Board) 变更控制委员会。 CI (Configuration Item) 配置项,包含文档、程序。 CR (Change Request) 变更请求,对提出的要变更工件或流程的任何请求的统称。在变更请求中记录的信息 是有关当前问题、提议解决方案及其成本的起源和影响的信息。

PCA (Physical Configuration Audit) 物理审计,在配置管理系统中建成立基线的工件是否为“正确”版本。 FCA (Functional Configuration Audit) 功能审计,核心软件配置项的实际性能是否符合它的需求。 基线(Baseline) 己通过复审和批准的工件发布版,由此构成进一步演进或开发的公认基础,并且只能 通过正式程序,例如变更管理和配置控制才能进行更改。 CML (Configuration Management Library) 配置客理库,存储项目工件的所有版本,即存储项目的定义的配置项。 版本(Version) 某个工件的变体,工件的后期版本一般是在初期版本的基础上进行的扩展。 1.5参考信息 1.5.1 可追溯性 CMU/ SET-93-TR-024 Capability Maturity Model SM for Software, Version 1.1

配置管理岗位职责

配置管理员岗位职责 摘自:软件配置管理论坛 一、配置经理的基本技能与资格 资格: 能够重视配置管理工作; 能够按规范实施配置管理工作; 积极支持部门的配置管理方面的工作; 能够积极支持与帮助其他人员; 为部门的配置管理能力的提高贡献力量; 熟悉公司配置流程以及其他相关的流程; 为增进项目管理,对于项目内的困难和关键问题,能够及时反映到部门; 基本技能: 能够独立规划项目的配置管理工作; 熟练掌握配置管理的相关概念; 能够了解配置的相关工具,熟练使用技术工程部配置所使用的工具; 具有基本的与人沟通的技巧; 能够了解项目管理过程中的主要环节; 初步了解项目管理过程中的质量保证的各个方面; 了解部分系统和应用工具,如数据库ORACLE,前台开发工具DEPHI等; 二、配置经理的职责 作为一名配置人员,配置经理的职责就是能够与质量人员、测试人员等共同保证项目的质量。如:作为质量保证的成员之一,能够为整个技术工程部规范化管理的推进作贡献,如宣传规范化管理的知识,陈述规范化管理的利弊等;能够在项目进行的整个生命过程中,不断的与项目经理、QA、SCCB及项目成员进行配置管理规范化的沟通,为项目配置管理的规范化作出努力. 具体表现为: ?项目进行初期或首次进入项目中时,能够首先与项目经理、QA、SCCB及项目成员就项目的未来配置管理工作进行沟通,取得项目经理、QA、SCCB及项目全体成员对配置工作的认可与支持; ?积极了解项目情况,项目各阶段的进展,为更好的进行配置管理作努力; ?熟练并充分的利用配置管理工具的各方面的功能,提高配置管理的效率; ?为项目控制好版本,保证项目各阶段所使用的版本正确; ?及时发现项目问题,把问题及时反馈给项目经理、QA或SCCB,并积极协助解决; ?与项目内其他组成员,如开发组、测试组等协调工作,并能够很好的沟通; ?能够在项目中不断总结、分析,为项目内配置管理工作的进一步优化作贡献;

软件配置管理计划

您现在的位置:需求工程多媒体教学系统>> 教学资料>> 正文 软件项目配置管理范例. 一. 概述 1.1 目的和范围 本文档描述NewSkyCRM软件开发项目的软件配置管理计划,该计划向NewSkyCRM软件开发项目组以及相关受SCM活动影响的组和个人提供相应的说明和活动指南,使某某软件开发中心SCM方针能够在NewSkyCRM软件开发项目的SCM活动中得到贯彻。 本计划适用于NewSkyCRM软件开发项目的整个生命周期。 1.2 软件配置管理计划维护 本计划由NewSkyCRM项目经理和软件配置管理经理共同制订。如果计划中的SCM活动在实施中出现偏离,由软件配置管理经理按照《变更控制规程》及时维护。 1.3 参考资料 《电信NewSkyCRM产品软件开发计划书》,Version 1.3.0, NS.TEL-NewSkyCRM-CRM-RM-03; 《电信NewSkyCRM产品系统功能说明书》,Version 1.1.1, NS.TEL-NewSkyCRM-CRM-RM-02; 某某软件开发中心《软件配置管理过程》,Version 1.1,NS-PROC-SCM-001; 某某软件开发中心《软件配置管理计划规程》,Version 1.0, NS-PROC-SCM-002。 二. 角色与职责 2.1 软件配置管理代表

软件配置管理代表的职责是遵循某某软件开发中心《软件配置管理过程》及有关规程等文档进行软件配置管理活动。 表1软件配置人员表 2.2 配置控制委员会 NewSkyCRM软件开发项目配置控制委员会的职责是管理本项目内软件基线 的变更等操作和配置项/单元标识的审定。主席主持配置控制委员会的活动。 表2配置控制委员会 2.3 项目经理 NewSkyCRM软件项目经理必须履行某某软件开发中心《软件配置管理过程》及有关规程等文档中指定的有关项目经理的职责。 2.4 项目开发组 NewSkyCRM软件项目开发组必须履行某某软件开发中心《软件配置管理过程》及有关规程等文档中指定的有关项目开发组的职责。 表3项目组成员表

软件配置管理计划示例

软件配置管理计划示例 作者:赵文锋计划名CADCSC软件配置管理计划 项目名中国控制系统CAD工程化软件系统 项目委托单位 代表签名年月日 项目承办单位 代表签名年月日 1 引言 1.1 目的 本计划的目的在于对所开发的CADCSC软件规定各种必要的配置管理条款,以保证所交付的CADCSC软件能够满足项目委托书中规定的各种原则需求,能够满足本项目总体组制定的且经领导小组批准的软件系统需求规格说明书中规定的各项具体需求。 软件开发单位在开发本项目所属的各子系统(其中包括为本项目研制或选用的各种支持软件)时,都应该执行本计划中的有关规定,但可以根据各自的情况对本计划作适当的剪裁,以满足特定的配置管理需求。剪裁后的计划必须经总体组批准。 1.2 定义 本计划中用到的一些术语的定义按GB/T 11457 和GB/T 12504。 1.3 参考资料 ◆GB/T 11457 软件工程术语 ◆GB 8566 计算机软件开发规范 ◆GB 8567 计算机软件产品开发文件编制指南 ◆GB/T 12504 计算机软件质量保证计划规范 ◆GB/T 12505 计算机软件配置管理计划规范 ◆CADCSC 软件质量保证计划 2 管理

2.1 机构 在本软件系统整个开发期间,必须成立软件配置管理小组负责配置管理工作。软件配置管理小组属项目总体组领导,由总体组代表、软件工程小组代表、项目的专职配置管理人员、项目的专职质量保证人员以及各个子系统软件配置管理人员等方面的人员组成,由总体组代表任组长。各子系统的软件配置管理人员在业务上受软件配置管理小组领导,在行政上受子系统负责人领导。软件配置管理小组和软件配置管理人员必须检查和督促本计划的实施。各子系统的软件配置管理人员有权直接向软件配置管理小组报告子项目的软件配置管理情况。各子系统的软件配置管理人员应该根据对子项目的具体要求,制订必要的规程和规定,以确保完全遵守本计划规定的所有要求。 2.2 任务 在软件工程化生产的各个阶段中,与本阶段的阶段产品有关的全部信息在软件开发库存放,与前面各个阶段的阶段产品有关的信息则在软件受控库存放。在研制与开发阶段的阶段产品的过程中,开发者和开发小组长有权对本阶段的阶段产品作必要的修改;但是如果开发者或开发小组长认为有必要个性前面有关阶段的阶段产品时,就必须通过项目的配置管理小组办理正规的审批手续。因此,软件开发库属开发这个阶段产品的开发者管理,而软件受控库由项目的配置管理小组管理。软件经过组装与系统测试后,应该送入软件产品库,如欲对其修改,必须经软件配置管理小组研究同意,然后报项目总体组组长批准。关于软件配置要进行修改时的具体审批手续,将在第条中详细规定。 2.3 职责 在软件配置管理小组中,各类人员要互相配合、分工协作,共同担负起整个项目的软件配置管理工作。其中各类人员的分工如下: A.组长是总体组代表,他对有关软件配置管理的各项工作全面负责,特别要对更改建议的审批和评审负责; B.软件工程小组组长负责监督在软件配置管理工作中认真执行软件工程规范; C.项目的专职配置管理人员检查在作配置更改时的质量保证措施; D.各子系统的配置管理人员具体负责实施各自的配置管理工作,并参与各子系统的功能配置检查和物理配置检查;

软件配置管理规定

软件配置管理规定 为进一步加强软件配置管理工作,明确软件配置原则,规范软件配置流程,制定本规定。 一、配置原则 1.软件配置遵循安全性、适用性、经济性和正版化的原则,不得配置非正版软件。 2.单位使用的商业软件、OEM软件、免费软件均需纳入配置管理,不得配置与工作无关的各类软件。 3.优先采用场地授权(许可)方式配置软件。 二、配置流程 1.软件使用部门根据本部门各岗位工作需要,编制岗位软件需求清单,填写《软件使用需求申请表》(附件1)。 2.信息化部门统计、汇总软件使用部门报送的《软件使用需求申请表》,对软件使用部门需要的相关软件进行统一测试和试用,综合考虑软件的价格、兼容性、安全性和售后服务等因素,确定软件选型,明确软件名称和版本。涉及使用免费软件的,更新《可使用免费软件清单》(附件2)。 3.信息化部门依据单位软件使用管理台账,梳理单位软件需求与现有软件许可的差异。单位软件许可不足的,编制《软件采购计划表》(附件3)。

4.财务部门要将软件采购纳入单位年度预算。财务、资产管理部门指导信息化部门完成软件采购。软件采购合同要明确软件名称、版本、授权方式、许可数量、使用年限、兼容性和售后服务等要求。 5.财务、资产管理部门指导信息化部门做好软件采购相关资料管理工作,重点是软件采购合同、软件授权证书、软件安装序列号等资料的管理工作。 6.信息化部门负责软件使用管理日常工作。 7.单位采购的软件,因以下情况申请报废的,需经过信息化部门鉴定,严格履行资产处置报批手续:(1)已经达到规定的最低使用年限,且无法继续使用的。 (2)未达到规定的最低使用年限,因技术进步等原因无法继续使用的。 (3)未达到规定的最低使用年限,因计算机硬件报废,且无法迁移到其他计算机上继续使用的。 8.信息化部门在单位新采购软件、报废软件和调整可使用免费软件清单后,更新《软件使用情况汇总表》(附件4)。

配置管理计划配置管理计划的案例

配置管理计划配置管理计划的案例 配置管理计划来自:://.chinaspis. 作者:林锐电子工业出版社出版发行 { 项目名称 } 配置管理计划文状态: [√] 草稿 [ ] 正式发布 [ ] 正在修改文标识: pany-Project-CM-PLAN 当前版本: X.Y 作者: 完成日期: Year-Month-Day 版本历史版本/状态作者参与者起止日期备注 目录 1.人员及职责 2.配置管理软硬资源 3.配置项计划 4.基线计划 5.配置库备份计划 附录:本计划审批意见 1.人员及职责 提示: (1)根据《项目计划》中的角色分配,确定配置管理员,CCB(配置控制委员会)成员。

(2)CCB的人数根据项目规模而定。一般地,项目经理是CCB的负责人。 角色人员职责、工作范围 配置管理员 (1)制定《配置管理计划》 (2)创建和维护配置库 CCB负责人 (1)审批《配置管理计划》 (2)审批重大的变更 CCB成员例如:审批某些配置项或基线的变更… 2.用于配置管理的软硬资源 提示: (1)配置管理员确定本项目的配置管理软。例如采用Microsoft公司的Visual SourceSafe或者Rationa公司的l ClearCase。 (2)配置管理员根据所采用的配置管理软,确定计算机资源(考虑内存、外存、CPU等)。 配置管理软硬资源说明配置管理软名称公司,软版本等计算机名称内存、外存、CPU等3.配置项计划 提示:配置管理员标识配置项,估计每个配置项的正式发布时间。标识符的参考格式为Project-Type…Type-Number。例如:类型主要配置项标识符预计正式发表时间计划 《项目计划》

软件配置管理规范标准

页眉 软件配置管理规范 1.简介 软件配置管理的目的是保证在整个软件生命周期中软件产品的完整性。 1.1 目的 本文档指导项目开展配置管理活动。 1.2 范围 本文档适用于SWL开发小组批准立项的软件项目。 1.3 文档结构 第一部分: 简介,包括本规范的目的、范围、词汇以及所涉及到的参考信息。 第二部分: 配置管理工作规范的正文,包括活动的流程图、进入能及退出的准则、所涉及的角色、相关活动的阐述、验证与确认能及度量。 第三部分: 变更控制工作规范的正文,包括活动的流程图、进入能及退出准则、所涉及的角色、相关活动的阐述、验证与确认能及度量。 第四部分: 参考文献,列出了编写本规范所参考的相关的文献资料。 第五部分: 附录,本文中流程图的标准符号定义。 1.4 词汇表 CM (Configuration Management) 配置管理。 CCB (Change Control Board) 变更控制委员会。 CI (Configuration Item) 配置项,包含文档、程序。 CR (Change Request) 变更请求,对提出的要变更工件或流程的任何请求的统称。在变更请求中记录的信息是有关当前问题、提议解决方案及其成本的起源和影响的信息。 PCA (Physical Configuration Audit) 物理审计,在配置管理系统中建成立基线的工件是否为“正确”版本。 FCA (Functional Configuration Audit) 功能审计,核心软件配置项的实际性能是否符合它的需求。 基线(Baseline)

己通过复审和批准的工件发布版,由此构成进一步演进或开发的公认基础,并且只能通过正式程序,例如变更管理和配置控制才能进行更改。 CML (Configuration Management Library) 配置客理库,存储项目工件的所有版本,即存储项目的定义的配置项。 版本(Version) 页脚 页眉 某个工件的变体,工件的后期版本一般是在初期版本的基础上进行的扩展。 1.5参考信息 1.5.1 可追溯性 CMU/ SET-93-TR-024 Capability Maturity Model SM for Software, Version 1.1 1.5.2 方针 SWL开发组项目开发与管理工作方针 1.5.3 过程/规范 项目计划与控制规范 1.5.4 指南 配置管理计划指南 基线策略指南 配置状态报告编制指南 配置审计工作活动指南 配置管理工具指南 VSS 使用指南 组织管理配置库使用指南 软件开发文档命名约定 1.5.5模板 配置管理计划 配置状态报告 配置审计报告 文档变更请求 1.5.6 检查表 无 1.5.7 培训 《软件配置管理教材》 《软件变更控制管理教材》 《Clear Case 配置管理培训教材》 1.5.7 工具 Clear Case Visual SourceSafe Visual Basic Office 97/2000/XP DreamWeaver PhotoShop

软件配置管理规范流程模板

软件配置管理规范 流程 1 概述 1.1 目的 本文档主要目的在于规范项目配置管理活动, 确保配置项正确地唯一标识而且易于存取, 保证基线配置项的更改受控, 明确基线状态, 在整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2 适用范围本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动, 针对项目不同在流程上作适当的删减。配置管理可采用各种工具及手工办法, 本文件以CVS( 并行版本系统) 配置管理工具为例, 规定公司的配置管理办法, 使用其它工具时也可对应本文件

的要求参照执行。 1.3 术语和缩略语 1.3.1 软件配置管理( Software Configuration Management, SCM) 软件配置管理是对软件修改进行标识、组织和控制的技术, 用来协调和控制整个过程。是经过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程, 确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。 1.3.2 配置项( Configuration Item, CI) 凡是纳入配置管理范畴的工 作成果统称为配置项, 配置项逻辑上组成软件系统的各组成部分, 一般是能够单独进行设计、实施和测试的。 每个配置项的主要属性有: 名称、标签、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里, 确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。 1.3.3 基线( Baseline) 在配置管理系统中, 基线就是一个配置项或一组配置项在其生命周期的不同时间点上经过正式评审而进入正式受控的一种状态这些配置项构成了一个相对稳定的逻辑实体, 而这个过程被称为基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素( 配置项) 的一个版本, 且只确定一个版本。一般情况下, 基线一般在指定的里程碑处创立, 并与项目中的里程碑保持同步。每个基线都将接受配置管理的严格控制, 基线中的配置项被冻结”了, 不能再

软件配置管理规范流程

1 概述 1.1 目的 本文档主要目的在于规范项目配置管理活动,确保配置项正确地唯一标识并且易于存取,保证基线配置项的更改受控,明确基线状态,在整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2 适用范围 本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动,针对项目不同在流程上作适当的删减。配置管理可采用各种工具及手工办法,本文件以CVS(并行版本系统)配置管理工具为例,规定公司的配置管理办法,使用其他工具时也可对应本文件的要求参照执行。 1.3 术语和缩略语 1.3.1 软件配置管理(Software Configuration Management,SCM) 软件配置管理是对软件修改进行标识、组织和控制的技术,用来协调和控制整个过程。是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程,确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。 1.3.2 配置项(Configuration Item,CI) 凡是纳入配置管理范畴的工作成果统称为配置项,配置项逻辑上组成软件系统的各组成部分,一般是可以单独进行设计、实施和测试的。 每个配置项的主要属性有:名称、标签、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里,确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。 1.3.3 基线(Baseline) 在配置管理系统中,基线就是一个配置项或一组配置项在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态,这些配置项构成了一个相对稳定的逻辑实体,而这个过程被称为“基线化”。每一

软件配置管理工具+Vss+60实用指南

软件配置管理工具Vss6.0实用指南 一、版本管理的必要性 如果说70年代的软件危机导致了软件工程思想的诞生和理论体系的发展,那么80~90年代尤其是90年代软件产业的迅猛发展导致了另一种新思想的产生和实现,这就是软件的版本管理。 只要参加过软件开发的人都清楚,现在的软件项目完全由一个人来完成是难以想象而且也是不可能的,通常是有一个研发小组来共同分析、设计、编码和维护,并有专门的测试小组对已完成编码调试的软件进行全面的测试。在软件开发这个庞大而复杂的过程中,需要涉及到各个方面的人员,信息的交流反馈不仅仅是在研发小组的成员之间及各个研发小组之间,还存在于客户和研发者之间。所有的这些交流反馈意见信息都有可能导致对软件的修改,小的可能只是对某个源文件中的某个变量的定义改动,大到重新设计程序模块甚至可能是整个需求分析变动。在这个工程中,由于软件开发所固有的特征,可能会形成众多的软件版本,而且我们并不能保证不出现错误的修改,而这样的一个困难局面却又非常现实地摆在项目开发管理者的面前,他/她该如何有效地解决这些问题,具体地说就是如下一些问题: 1.怎样对研发项目进行整体管理; 2.项目开发小组的成员之间如何以一种有效的机制进行协调; 3.如何进行对小组成员各自承担的子项目的统一管理; 4.如何对研发小组各成员所作的修改进行统一汇总; 5.如何保留修改的轨迹,以便撤销错误的改动; 6.对在研发过程中形成的软件的各个版本如何进行标识,管理及差异识辨等等。 一个非常直接的反应,我们必须要引进一种管理机制,一个版本管理机制,而且是广义上的版本管理,它不仅需要对源代码的版本进行管理,而且还要对整个项目进行管理。以往的那种被誉为具有良好编程风格的做法,诸如在对他人的源程序进行修改时注释修改原因,修改人和日期,如果是多个成员同时进行了修改,那么需要进行及时的人工的差异比较和综合以便形成一个统一的新版本。这种做法在当前的大型软件的开发中已经越来越没有空间了,可以说是一种以小作坊的形式来面对软件的社会化大生产,再也不可能行得通了。 其实,版本管理的思想很早就存在于软件开发者的头脑之中,只是以往的认识没有现在人们所意识到的那样迫切。UNIX 的程序开发系统较早就提供了能够进行开发小组中源代码版本管理的工具,现在的Linux更是提供功能强大的能够跨平台的版本管理器,国外公司的基于Windows的版本管理器也已经有了比较成熟的产品,国内的研究单位如北京大学计算机系CASE实验室也在致力于这方面的工作。在众多的成熟产品和试验产品中,这里只将对使用比较广泛,有较大用户前景且又能较易获得的版本管理器产品Microsoft公司的Visual SourceSafe6.0进行详细的介绍,针对普通的研发小组的解决方案,及具体的实现。 二、Visual SourceSafe6.0(VSS6.0)简介 VSS6.0现在是作为Microsoft Visual Studio6.0这个开发产品家族的一员,如Visual C++6.0和Visual J++6.0一样。 1.VSS的简单工作原理 Microsoft的VSS6.0解决了软件开发小组长期所面临的版本管理问题,它可能有效地帮助项目开发组的负责人对项目程序进行管理,将所有的项目源文件(包括各种文件类型)以特有的方式存入数据库。开发组的成员不能对该数据库中的

配置管理计划

项目名称(The English Name)配置管理计划 XXX项目小组

修订表

审批记录

目录 1.引言 (5) 1.1目的 (5) 1.2适用范围 (5) 1.3参考资料 (5) 1.4术语和缩略语 (5) 2.人员与责任 (5) 3.用于配置管理的软硬件资源 (6) 4.配置库结构与权限 (6) 4.1配置库列表 (6) 4.2配置库结构 (6) 4.3人员权限 (6) 5.配置项计划 (7) 6.基线计划 (7) 7.配置库备份计划 (7)

1.引言 1.1目的 本计划的目的是定义软件项目组进行配置管理活动、任务和责任;定义支持配置管理的活动及报告的工具、技术和方法。 1.2适用范围 本计划定义项目组在项目期间的所有配置管理活动。 1.3参考资料 《配置管理指南》 《配置项变更规程》 《配置审核规程》 《基线生成产品规程》 1.4术语和缩略语 CCB:软件配置控制委员会、变更控制委员会 2.人员与责任 提示: (1)根据《项目计划》中的角色分配,确定配置管理员,CCB(配置控制委员会)成员。 (2)CCB的人数根据项目规模而定。一般地,项目经理是CCB的负责人。

3.用于配置管理的软硬件资源 提示: (1)配置管理员确定本项目的配置管理软件。例如采用Microsoft公司的Visual SourceSafe、Excel 或者CVS。 (2)配置管理员根据所采用的配置管理软件,确定计算机资源(考虑内存、外存、CPU等)。 4.配置库结构与权限 4.1配置库列表 4.2配置库结构 以课堂上讲授的配置库结构为主,各小组可以根据自己组的实际情况来调整。 4.3人员权限

软件配置管理规范

软件配置管理规范1.简介 软件配置管理的目的是保证在整个软件生命周期中软件产品的完整性。 目的 本文档指导项目开展配置管理活动。 范围 本文档适用于SWL开发小组批准立项的软件项目。 文档结构 第一部分: 简介,包括本规范的目的、范围、词汇以及所涉及到的参考信 息。 第二部分: 配置管理工作规范的正文,包括活动的流程图、进入能及退出 的准则、所涉及的角色、相关活动的阐述、验证与确认能及度 量。 第三部分: 变更控制工作规范的正文,包括活动的流程图、进入能及退出 准则、所涉及的角色、相关活动的阐述、验证与确认能及度量。 第四部分: 参考文献,列出了编写本规范所参考的相关的文献资料。 第五部分:

附录,本文中流程图的标准符号定义。 词汇表 CM (Configuration Management) 配置管理。 CCB (Change Control Board) 变更控制委员会。 CI (Configuration Item) 配置项,包含文档、程序。 CR (Change Request) 变更请求,对提出的要变更工件或流程的任何请求的统称。 在变更请求中记录的信息是有关当前问题、提议解决方案及 其成本的起源和影响的信息。 PCA (Physical Configuration Audit) 物理审计,在配置管理系统中建成立基线的工件是否为“正 确”版本。 FCA (Functional Configuration Audit) 功能审计,核心软件配置项的实际性能是否符合它的需求。 基线 (Baseline) 己通过复审和批准的工件发布版,由此构成进一步演进或开 发的公认基础,并且只能通过正式程序,例如变更管理和配 置控制才能进行更改。 CML (Configuration Management Library)

相关文档
最新文档