文档库 最新最全的文档下载
当前位置:文档库 › BMS40Ch03系统配置工具

BMS40Ch03系统配置工具

第三章 系统配置工具(SCT)

3.1 概述

系统配置工具(System Configure Tool)是SynchroBMS系统的二次开发人员对整个系统进行常规配置(包括后台脚本配置、数据库属性、全局变量、子系统监控点配置、区域配置、IO驱动设置)、高级配置(包括权限配置、时间表配置、联动配置、历史数据配置)的工具。

所有的监控点(变量)以子系统、设备、变量的三层逻辑结构分层进行组织。SCT运行和配置界面如图3-1-1和3-1-2所示。

图3-1-1

图3-1-2

3.2 脚本配置详解

3.2.1 控制脚本

二次开发人员采用脚本语言编写控制逻辑。一段相对独立的(不引用其它同类代码块)

控制逻辑脚本代码称为一个控制逻辑块。

3.2.2 创建和修改后台控制脚本文件

1.确定参加控制脚本的变量

在编辑后台脚本控制语言之前必须首先确定系统中都有哪些变量参与了后台控制操作。为此,用户可以在变量列表中通过鼠标右键访问如图3-2-1所示的快捷菜单中的【加入脚本配置】命令来将一个或者多个变量加入到脚本配置中。

图3-2-1

注意:同一变量只能加入一次。如果试图将一个变量多次加入脚本配置,SCT将将弹出如图3-2-2所示的对话框提示SCT拒绝加入请求。

图3-2-2

2.获得变量的全名

在参加联动配置的变量列表单击鼠标右键可以访问快捷菜单,如图3-2-3所示。控制命令【复制变量名】将把变量的形如“[子系统].[设备].[变量]”的变量的全名复制到Windows操作系统剪切板上,该操作是Windows操作系统提供的标准功能,它支持任何形式的Windows 【粘贴】 命令。

图3-2-3

3.将变量全名加入到脚本文件中

在需要引用该变量全名的位置通过Windows标准的【粘贴】功能或者Ctrl + V加速键功能可以将变量的全名插入到当前光标所在位置。

要使用Windows标准【粘贴】功能,在需要插入变量全名的位置单击鼠标右键将显示如图3-2-4所示的快捷菜单,选择【粘贴】即可。

图3-2-4

4.删除控制变量

对于在脚本配置中没有使用到的变量,可以将该变量从脚本配置中删除。当用户在树形视图的【脚本配置】项上执行鼠标单击操作时,在列表视图中显示了所有用户已经加入到联动配置中的变量及其ID,选择欲从脚本配置中删除的变量,单击工具栏按钮【删除】中“删除控制变量”,或者在列表视图内单击鼠标右键访问如图3-2-3所示的快捷菜单的控制命令“删除控制变量”,该变量将被从脚本配置中删除,但它仍然保存在其所在的设备下。

3.2.3 脚本配置页面

脚本配置页面如图3-2-5所示:

图3-2-5

在页面的编辑区域内,用户可以输入任何VBScript语句。由于脚本编辑区采用了语法单元分色显示功能,可以帮助用户在一定程度上减少语法错误。

1.脚本语言

SCT采用VBScript语言作为后台控制脚本语言来控制联动过程。作为SynchroBMS系统后台控制程序的脚本语言应该具有下列形式:

Option Explicit

1) Option Explicit语句:

该语句一般出现在程序的开始位置,指出在本程序中的程序语句符合严格语法检查的需要;该语句可以省略。

2) Control.ReadTag (ByVal Tagname, ByVal TagQuality, ByVal TagValue)方法: 该方法由实时数据库服务器实现,调用此方法将读取指定变量的质量值和变量值;

该方法有如下参数:

A.Tagname 欲读取的变量的全名。例如:DS.Door.OpenDoor;

B.TagQualty欲读取的变量的质量值。

C.TagValue 欲读取的变量的质量值。取值与变量类型有关;

3) Control.WriteTag (ByVal Tagname, ByVal TagValue)方法:

该方法由实时数据库服务器实现,调用此方法将改变指定变量的变量值;

该方法有如下参数:

A.Tagname 欲改变的变量的全名。例如:DS.Door.OpenDoor;

B.TagValue 欲改变的变量的质量值。取值与变量类型有关;

4) Control.MsgBeep (ByVal freq, ByVal delay) 方法:

该方法由实时数据库服务器实现。调用此方法后当脚本执行时计算机的蜂鸣器将发出指定频率和持续时间提示音;

该方法有如下参数:

A.ByVal freq 提示音的频率;

B.ByVal delay 提示音的持续时间;

2.示例:

下例演示了在安防子系统、门控子系统和照明子系统三个子系统间联动的一个典型的联动处理过程:当安防系统处于布防状态时,如果探头监测到有非法入侵,探头将自动报警,此时触发脚本处理逻辑:关闭大门,将射灯打开并将其开度置为50,同时将摄像头转向大门进行监控。

1)联动脚本:

Option Explicit

Dim OutName1

Dim OutName2

Dim OutName3

Dim OutName4

Dim N1Quality

Dim N1Value

OutName1 = "安防子系统.探头.报警状态"

OutName2 = "门控子系统.大门.关门"

OutName3 = "照明子系统.射灯.开度"

OutName4 = "安防子系统.摄像头.转向大门"

N1Quality = 0

control.ReadTag OutName1, N1Quality, N1Value

If N1Value = TRUE Then

Control.WriteTag OutName2, TRUE

Control.WriteTag OutName3, 50

Control.WriteTag OutName4, TRUE

Control.MsgBeep 1000, 100

End If

2)解释:

A.Option Explicit:通知脚本处理引擎执行一个严格的语法检查过程;此例中在使用变量之前首先必须定义变量;

B.下列语句声明并初始化本次参与脚本控制的变量的全名:

Dim OutName1

Dim OutName2

Dim OutName3

Dim OutName4

Dim N1Quality

Dim N1Value

OutName1 = "安防子系统.探头.报警状态"

OutName2 = "门控子系统.大门.关门"

OutName3 = "照明子系统.射灯.开度"

OutName4 = "安防子系统.摄像头.转向大门"

N1Quality = 0

C.变量读取过程, 由实时数据库服务器调用。逻辑处理过程,由实时数据库服务器调用,用户必须保留过程名:

Control.ReadTag OutName1, N1Quality, N1Value

D.If value = TRUE Then …:判断变量的当前值是否满足联动触发条件:如果变量OutName1的当前取值满足联动触发条件,即安防子系统的探头当前处于报警状态,则继续联动处理过程;否则退出联动处理过程;

E.Control.WriteTag OutName2, TRUE:向变量OutName2指向的变量发送控制命令TRUE,即向门控子系统的大门发送关门命令;

F.Control.WriteTag OutName3, 50:向变量OutName3指向的变量发送控制命令50,即将照明子系统的射灯开度设置为50;

G.Control.WriteTag OutName4, TRUE:向变量OutName4指向的变量发送控制命令TRUE,即将安防子系统的摄像头转向大门执行监控;

H.Control.MsgBeep 1000, 100:驱动计算机蜂鸣器发出频率为100,持续时间为1000毫秒的提示音;该语句可以省略;

3.打开和保存脚本文件

1)脚本文件与系统路径配置工具

默认状态下,当用户欲对联动配置进行创建或修改时,系统从注册表中读取LinkScriptPath 的值作为联动脚本控制文本的存储路径。如果读取失败,则不加载任何文件,此时用户既可以使用系统路径配置工具SCT进行脚本文本存储路径的设置,又可以通过后台控制脚本页面上的【打开】功能来指定脚本控制文件,这时如果使用了【保存】功能,则该脚本文件的存储路径将被存储到系统注册表中。

2) 打开脚本文件

单击后台控制脚本页面上的【打开】将弹出如图3-2-6所示的打开文件对话框。

图3-2-6

当用户指定了脚本控制并打开文件后,脚本文本将全部显示在页面的脚本语言编辑区内,此时可以修改当前打开的文件。

3) 保存脚本文件

单击后台控制脚本页面上的【保存】将弹出如图3-2-7所示的保存文件对话框。

图3-2-7

当用户完成对配置脚本的创建或修改后,必须保存配置脚本到磁盘文件中。配置脚本的存盘文件是一标准的TXT格式的文本文件。确定保存路径后,SCT将把该文件的路径存到注册表中作为脚本文本的存储路径。

4) 语法检查

单击后台控制脚本页面上的【语法检查】,SCT将对当前的脚本文件进行相应的语法检查。如检查通过,弹出如图3-2-8所示的对话框。

图3-2-8

如发现错误,弹出如图3-2-9所示的对话框。

图3-2-9

3.3 数据库配置详解

3.3.1 数据库配置与实时数据库服务器

实时数据库服务器使用数据库配置信息进行实时数据库的工作方式和预留空间设置,对历史数据库进行预留空间和数据转储时间间隔设置。

3.3.2 数据库配置与OPC客户端程序

OPC客户端程序使用SCT配置的实时数据库中指定的事件和报警的数目来初始化动态内存交换库。

3.3.3 数据库属性配置页面

数据库属性配置页面如图3-3-1所示。

图3-3-1

3.3.4 实时数据库属性配置

1.工作模式:实时数据库的工作模式可以有定时上报和响应查询两种。

2.数据更新率:来自设备的数据的更新率,范围:1~10。

3.报警的项目数:实时数据库为报警预留的空间大小,范围:50~500。

4.事件的项目数:实时数据库为事件预留的空间大小,范围:50~500。

3.3.5 历史数据库属性配置

1.数据库容量:历史数据库的容量大小,范围:1~100。

2.数据库转储时间:每隔多长时间开始一次转储。

3.报警的项目数:历史数据库为报警预留的空间大小,范围:150~1500。

4.事件的项目数:历史数据库为事件预留的空间大小,范围:150~1500。

3.4 全局变量配置详解

3.4.1 子系统与全局变量

在SynchroBMS 4.0系统中,提供预定义全局变量,用于描述与系统状态、操作和与之相连接的子系统的连接运行状态。全局变量变量均以美元符号($)开头。在系统建立一个新项目时自动创建,并由系统相关操作赋值。全局变量可在整个应用程序内各种脚本和动画连接中使用。

系统提供通讯质量的全局变量,用于对每个子系统OPCserver通讯质量的监测状态的反馈。每个子系统通讯质量,通过8个变量表现和设置。系统预定义16个子系统(子系统最大个数) 的通讯质量的全局变量。

描述表如下:

变量名称 GlobalID

类型说明取值范围

$子系统X工作状态0.X.1 只读开关量 True---表示通讯正常

False--表示通讯失败

X~[1,16]

$子系统X请求总数0.X.2 只读整形所有访问成功的请求总数 X~[1,16]

[0,0Xffffffff]

$子系统X错误总数0.X.3 只读整形所有的返回失败和无返回

的错误总数

X~[1,16]

[0,0Xffffffff]

$子系统X错误

百分比值(错误

率)

0.X.4 只读浮点错误总数/请求总数 X~[1,16]

$子系统X气压计值(Barometer)0.X.5 只读整形 1)

子系统X通讯质量的气

压计监视器。气压计监视所

有的访问请求总数和所有

的返回失败和无返回错误

总数。

2)每当一个调用错误发生

时,气压计增2或更多。每

当一次成功时,气压计减1。

如错误值相对较大,气压计

值也会相对较大。

3)气压计的最小值为0。

X~[1,16]

[0,65535]

$边界限值 0.X.6 读写整形气压计算法的边界设定值,

预定义为25。

[1,65535]

$故障限值 0.X.7 读写整形气压计算法的故障设定值,

预定义为50。

通常:$边界限值〈$故障

限值

[1,65535]

$诊断周期 0.X.8 读写整形气压计算法的诊断周期设

定值,单位为秒,预定义为

60。

[1,65535]

1) 对每个子系统通讯质量的判断,主要通过Barometer法监测。“$气压计值”主要根

据$请求总数、$错误总数的计算得到。对于“$气压计值”超过“$边界限值”、“$故障限值”,会产生相应的超限事件记录。

2) 当“$气压计值”超过“$边界限值”时,系统自动产生一条系统消息类型,优先级

为600,描述内容为“BA系统通讯负载超过边界限值!”的事件记录。

3) 当“$气压计值”超过“$故障限值”时,系统自动产生一条系统消息类型,优先级

为900,描述内容为“BA系统通讯负载超过故障限值!”的事件记录。

4) 对于读写类型全局变量,如$边界限值、$故障限值、$诊断周期,都可以在运行态

时修改量值。

3.4.2 全局通讯质量变量

在右上列表视图部分,可观察到每个子系统的通讯质量类型的全局变量的属性和设置值。如图所示。

其中,对于每个子系统的$边界限值、$故障限值、$诊断周期的设置,请参考3.5.2一节说明。

图3-4-1

3.5 子系统配置详解

3.5.1 子系统与OPC服务器

SynchroBMS系统设计中,采用一个OPC服务器实现一个子系统的功能,因此要求用户在配置子系统信息时必须知道该子系统的功能是由哪一个OPC服务器来实现的。由于采用了COM/DCOM技术,要访问组件应该提供该组件的CLSID或者ProgID,而 ProgID以字符串形式标识了具体的组件,简单且易于识别,所以SCT采用要求ProgID的方式来确定OPC服务器。

每一个子系统对应的ProgID,请询问提供OPC服务器的厂家。

3.5.2 子系统属性页面

子系统属性页面如图3-5-1所示。

图3-5-1

1.子系统ID:由SCT赋予的全局唯一的值;用户不得修改;

2.名称:标识子系统名称;子系统不允许重名;长度不得超过32个字符长度;如果设备名称有重复,则SCT弹出如图3-5-2所示的对话框提示设置出错。

图3-5-2

3.域名分隔符:变量全名显示时,分隔子系统、设备、变量的字符。OPC服务器建议用户使用字符“.”作为域名分隔符,但也允许其它字符,如“/”、“\”等作为域名分隔符,具体使用的域名分隔符请参阅OPC服务器提供商的说明文档;

4.数据访问服务器ProgID:实现该子系统数据访问功能的OPC数据访问服务器的ProgID,以字符串形式表示;

5.事件与报警服务器ProgID:实现该子系统事件与报警功能的OPC事件与报警服务器的ProgID,以字符串形式表示。

6.边界限值:气压计算法的边界设定值,预定义为25。

7.失败限值:气压计算法的故障设定值,预定义为50。

通常:$边界限值〈$故障限值

8.诊断扫描周期(秒):气压计算法的诊断周期设定值,单位为秒,预定义为60。

3.5.3 设备配置详解

3.5.3.1 逻辑设备与物理设备

对SCT而言,设备是必须存在的。但是在实际工程当中,设备的概念是非常模糊的,甚至有些子系统直接控制各个采集点。为了达到统一配置的目的,用户可以将具有相似属性的采集点(例如:同一楼层)组织为一个逻辑设备,这样在系统配置中,该逻辑设备完全等同于物理设备。

3.5.3.2 设备属性页面

设备属性页面如图3-5-3

所示。

图3-5-3

1.子系统ID :由SCT 产生的一个全局唯一的值;该值不允许修改;

2.设备ID :由SCT 产生的一个在设备所属子系统内部唯一的值,该值不允许修改;

3.名称:用户定义的设备名称;同一子系统内的设备不允许重名;长度不得超过64个字符长度;如果设备名称有重复,则SCT 弹出如图3-5-4

所示的对话框提示设置出错。

图3-5-4

3.5.4 变量配置详解

变量即数据采集点。

3.5.

4.1 变量基本属性配置

变量的基本属性页面如图3-5-5所示。

图3-5-5

1.子系统ID :变量所属的子系统的ID ;

设备内的变量不允许重名。如果变量名称有重复,则SCT 弹出如

2.设备ID :变量所属的设备的ID ;

3.变量ID :变量的ID ;

4.类型:变量的类型;

5.名称:变量名称。同一图3-5-6所示的对话框提示设置出错。

图3-5-6

6.注释:对变量的注释信息。

注意:变量名称必须小于96字符长度;

3.5.

4.2 数据采集属性

5-7所示。

数据采集属性页面如图

3-

图3-5-7

1.设备地址:标识变量所对应的数据采集设备的地址;

只读表示该变量的值不能通过控制命令被改变,读写表 8所示。

2.数据地址:标识变量在数据采集设备中的数据地址;

3.功能号:根据协议而变;

4.辅助功能号:根据协议而变5.属性:标识该变量的读写属性;示该变量的值可以被控制命令改变;

6.刷新周期:变量的值的变化周期。

3.5.

4.3 离散量的工程属性配置

离散量的工程属性配置页面如图

3-5-

图3-5-8

1.初始值:设置系统开始运行时变量的值的设置与报警属性有一定关联,例如:。初始值如果初始值为“关”,而报警属性中设置了“关报警”,那么系统自运行时开始就会一直发送“关报警”,直到变量的值改变为“开”。

2.工程转化方法:设置变量的测量值与工程值之间的转化方式:

消息字符应的消息;该消息描述了当前变量的取值;消息字符统才将有变量改变的值记录到历史数据库中。

9所示。

1) 直接转化:测量值为1时工程值为1,测量值为0时工程值为0。2) 反转转化:测量值为1时工程值为0,测量值为0时工程值为1。

3.开消息:变量的值为“开”时所对应的消息,该消息描述了当前变量的取值;串的长度必须小于16个字符长度。

4.关消息:变量的值为“关”时所对串的长度必须小于16个字符长度。

5.登录灵敏度:设置每隔多少时间系3.5.4.4 离散量的报警属性配置

离散量的报警属性配置页面如图

3-5-

图3-5-9

1.开报警:若开报警前的复选框被核选,取值为“开”时报警;若开报警前的复小于16字符长度。

若关报警前的复小于16字符长度。

若应答报警前的 10所示。

则当变量选框未被核选,则即使变量取值为“开”仍不会报警。

1) 开描述:报警信息发送时的开报警的描述,字符长度应2) 严重等级:此变量的“开报警”的严重性等级,取值范围:1-1000。

2.关报警:若关报警前的复选框被核选,则当变量取值为“关”时报警;选框未被核选,则即使变量取值为“关”仍不会报警。

1) 关描述:报警信息发送时的关报警的描述,字符长度应2) 严重等级:此变量的“关报警”的严重性等级,取值范围:1-1000。

3.应答报警:设置是否在实时报警窗口中对该变量的报警信息进行应答。复选框被核选,则允许用户在实时报警窗口中应答该报警信息,否则为不允许应答。

3.5.

4.5 模拟量的工程属性配置

模拟量的工程属性配置页面如图

3-5-

图3-5-10

1.初始值:浮点型数据,设置系统开始初值,最小工程值<=初始值<=最大工程值:浮点型数据,设置变量值的下限,最小工程值必须小于最大工程值,否则

运行时变量的程值。

2.最小工

SCT 将弹出如图3-5-11

所示的对话框提示用户修改该值。

图3-5-11

3.最大工程值:浮点型数据,设置变量值的上限,最小工程值必须小于最大工程值。

必4.最小测量值:浮点型数据,设置最小工程值所对应的原始变量值的下限,最小测量值须小于最大测量值,否则SCT 将弹出如图3-5-12

所示的对话框提示用户修改该值。

图3-5-12

5.最大测量值:浮点型数据,设置最大的原始变量值的上限,最小测量值必变量测量值转换成工程值的方法:

单位,例如:安培、伏特、度等,字符据,设置响应变量改变的阀值。当变量值的变化范围超过了变化统才将有变量改变的值记录到历史数据库中。

工程值所对应须小于最大测量值。

6.工程转化方法:设置1) 线性转化法:用测量值和工程值的线性插值进行转化。

2) 平方根转化法:用测量值的平方根进行转化。

7.工程单位:字符串型数据,设置模拟变量的取值长度必须小于16字符。

8.变化灵敏度:浮点型数灵敏度时,系统将触发某些动作。

9.登录灵敏度:设置每隔多少时间系

注意:请确认变量的最小、最大工程值在正常范围内!

13所示。

3.5.

4.6 模拟量的报警属性设置

模拟量的报警属性设置页面如图

3-5-

图3-5-13

1.报警限报警:报警限将报警划分为低低、低、高、高高四个类型。

值小于或等于报警1) 报警类型:如果低低、低报警被前的复选框被核选,则当变量的工程值时产生并发送报警;如果高、高高报警前的复选框被核选,则当变量的工程值大于或等于

报警值时产生并发送报警。

2) 报警值:报警值的有效取值范围为最小工程值和最大工程值之间的值;如果有两个或两值 < 高高报警值

个以上的报警类型被核选,则必须保证如下关系:

低低报警值 < 低报警值 < 高报警 否则SCT 则显示如图3-5-14

所示的对话框提示用户操作有误。

图3-5-14

2.偏差限报警:是以变量的当前值相对标值上下浮动的百分比来定义的,分 – 偏差报警目标值) / (最大值 – 最小值)) * 100;

最小于等于报警值时产生报警。

严重性程度,取值范围为1-1000,取值越大,则表示严重根据变量值在给定时间内的变化率来确定是否报警;

间 – 上一次值变统中的严重性程度,取值范围为1-1000,取值越大,则表示严重置是否在实时报警窗口中对该变量的报警信息进行应答。若应答报警前的 3-5-15所示。

于偏差报警目为下偏差和上偏差。

偏差 = ((变量当前值由于偏差有正负,在偏差范围内相对偏差报警目标值上下波动的模拟量最小分界值称为当前值,相对偏差报警目标值上下波动的模拟量最大分界值称为最大当前值:

最小当前值 = 偏差报警目标值 - (偏差 / 100) * (最大值 – 最小值);

最大当前值 = 偏差报警目标值 + (偏差 / 100) * (最大值 – 最小值)。

1) 偏差报警目标值:计算偏差的基值。

2) 下偏差报警:如果被选中,则当偏差小3) 上偏差报警:如果被选中,则当偏差大于等于报警值时产生报警。

4) 报警值:偏差的百分比值。

5) 严重等级:该报警在系统中的性程度越高。

3.变化率报警:变化率 = ((当前值 – 上一次值) / (最大值 – 最小值)/(当前时化的时间)) * 100%。

4.严重等级:该报警在系性程度越高。

5.应答报警:设复选框被核选,则允许用户在实时报警窗口中应答该报警信息,否则为不允许应答。

3.5.

4.7 区域属性设置

变量区域属性设置页面如图

图3-5-15

1.存在的区域:标识当前的地址;

2.所属区域:标识变量所属的区域;

一个或全部备选区域到所属区域;

3.6 区域配置详解

区域即数据采集点的逻辑集合。

3.6.1 区域基本属性配置

变量的基本属性页面如图3-6-1所示。

3.添加、添加全部:从存在的区域选择4.删除、删除全部:从存在的区域选择一个或全部所属区域到备选区域;

图3-6-1

1.ID :区域所属的系统ID ;

3.6.2 区域监控变量属性配置

区域的监控变量属性配置页面如图3-6-2所示。

2.名称:区域的名称;

3.注释:对区域的注释;

图3-6-2

1. 子系统:子系统名称列表;

表;

2. 设备: 子系统所属设备名称列

3. 可供添加的监控变量:当前可供选择变量名称列表,可添加到区域所属变量中;

属区域;

3.7 I/O 驱动配置详解

为解决OPC 客户端程序对第三方OPC Server 的接入,需要将BMS 中的点信息同第三方OPC 系存储为另外一个配置文件中,文件后缀为.3rd;该文3.7.1 I/O 驱动配置详解

1. 在“管理与配置”根节点下添加“I/O 驱动”节点以配置第三方驱动, 如图3-7-1所示。

4. 当前已包含的监控变来:当前区域已选择子系统、设备的变量名称列表;

5. 添加、添加全部:从当前可供选择变量名称列表中选择一个或全部变量到所6. 删除、删除全部:从存在的区域选择一个或全部所属变量到当前可供选择变量名称列表;

Server 的ItemID 建立对应关系;

为尽量不影响配置文件,将该对应关件在BMS 配置文件加载时被加载,在BMS 配置文件存储时被存储;

对点信息的配置操作保持SCT

原风格不变;

图3-7-1

2. 当焦点位于树视图中时,可以从菜单栏或者工具栏在该节点下添加一类驱动, 如图

3-7-2

所示。

图3-7-2

此时属性栏将显示该驱动的属性。如图。

3-7-3

所示

图3-7-3

3. 当焦点位于树视图中时,可以从菜单栏或者工具栏在OPC驱动节点下添加具体厂家的

OPC驱动程序,如图3-7-4所示。

图3-7-4

此时属性栏将显示该驱动的属性,可以修改名称,配置。如图3-7-5所示。

图3-7-5

绑定到子系统:指出那一个被连接的子系统的驱动由该OPC驱动来实现。如图3-7-6所示。

图3-7-6

只列出尚未配置的子系统:只显示未指定ProgID的子系统名称;

列出全部子系统:显示全部子系统名称;

搜索:单击该按钮将检索指定条件的子系统,名称将被列出在列表框中;

确定:列表框中被选择的子系统被设置为被绑定的子系统;

取消:不设置;

OPC DA ProgID:指出该OPC数据访问服务器的ProgID。如图3-7-7所示。

图3-7-7

连接到:可以从本地或远程计算机选择OPC数据访问服务器;

版本:指定OPC数据访问服务器的版本;

搜索:单击该按钮将检索指定条件的ProgID,名称将被列出在列表框中;

确定:列表框中被选择的ProgID被设置为OPC数据访问服务器的ProgID;

取消:不设置;

OPC AE ProgID:指出该OPC数据访问服务器的ProgID。如图3-7-8所示。

图3-7-8

操作同上;

4. 当焦点位于树视图中时,可以从菜单栏或者工具栏在OPC驱动程序下添加映射变量,映

射变量不添加到树的节点,只显示在列表中。如图3-7-9所示。

图3-7-9

此时属性栏将显示OPC 驱动程序中的点和SynchroBMS 系统配置的点。如图3-7-10所示。

图3-7-10

选择各自的点后,在树的下方的编辑框中将显示变量的全名;

确定:单击该按钮后,这两个点将建立映射关系。如图3-7-11

所示。

图-6-11

5. 在列表视图中点击数据项时将在属性栏显示相应的属性,具体操作与在树形视图中的操

作一致;

6. 必须点击属性栏的确定按钮,属性值才会被修改;

存储:在配置文件所在位置,驱动的映射文件将被创建,该文件与配置文件同名,但后缀为.3rd;

3.8 系统点表视图配置详解

系统点表视图主要功能,是对权限、时、历史数据服务提供监控点和区域的拖放数据源。系统点表视图配置界面如图3-8-1示。

3

间表、联动所

配置管理工具简介

配置管理工具简介 要说配置管理工具,就要说到配置管理,因为配置管理工具是软件配置管理过程中所使用的一些工具,要了解配置管理工具,首先就必须了解配置管理。 一、配置管理工具的定义:软件配置管理的定义有很多,现在我只说一个我 觉得定义的必要好的定义。它是:“协调软件开发使得混乱减到最小的技术叫做软件配置管理,它是一种标识、组织和控制修改的技术,目的是使错误达到最小并有效地提高生产效率。”它贯穿整个软件生命周期并应用于整个软件工程过程,是软件工程中用来管理软件开发的规范,也是CMM(软件能力成熟度模型)二级中关键过程域。软件配置管理是软件质量改进的核心环节,它贯穿于整个软件生命周期,为软件改进提供了一套解决办法与活动原则。 二、软件配置管理的目标: 软件配置管理的目标是标识变更、控制变更、确保变更、和报告变更,它主要完成以下几种任务:标识、版本管理、变更控制、配置审计和配置报告。 三、配置管理工具的主要功能: 配置管理工具作为配置管理过程中使用的工具就理所当然的具有以下功能: 1).并行开发支持:因开发和维护的原因,要求能够实现开发人员同时在同 一个软件模块上工作,同时对一个代码部分做不同的修改,即使是跨地域 分布的开发团队也能互不干扰,协同工作,而又不失去控制。 2).修订版管理:跟踪一个变更的创造者、时间和原因,从而加快问题和缺 陷的确定。 3).版本控制:能够简单、明确地重现软件系统的任何一个历史版本。 4).产品发布管理:管理、计划软件的变更,与软件的发布计划、预先定制 好的生命周期或相关的质量过程保持一致;项目经理能够随时清晰地了解 项目的状态。 5).建立管理:基于软件存储库的版本控制功能,实现建立过程自动化。 6).过程控制:贯彻实施开发规范,包括访问权限控制、开发规则的实施等。 7).变更请求管理:跟踪、管理开发过程中出现的缺陷、功能增强请求或任 务,加强沟通和协作,能够随时了解变更的状态。 8).代码共享:提供良好的存储和访问机制,开发人员可以共享各自的开发 资源。 四、常见配置管理工具简介: 配置管理工具有很多,一下我对一些常见的配置管理工具做一简单的介绍。 1.元老:CCC、SCCS、RCS 上个世纪七十年代初期加利福利亚大学的Leon Presser教授撰写了一篇论文,提出控制变更和配置的概念,之后在1975年,他成立了一家名为Soft Tool的公司,开发了自己的配置管理工具:CCC,这也是最早的配置管理工具之一。 在软件配置管理工具发展史上,继CCC之后,最具有里程碑式的是两个自由软件:Marc Rochkind 的SCCS (Source Code Control System) 和Walter Tichy 的RCS (Revision Control System),它们对配置管理工具的发展做出了重大的贡献,直到现在绝大多数配置管理工具基本上都源于它们的设计思想和体系架构。 2.中坚:Rational Clear Case

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

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

软件配置管理报告

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

辑要页

摘要: 主题词:

文档修改记录

1范围............................................................................................... 1.1标识.......................................................................................... 1.2系统概述...................................................................................... 1.3文档概述......................................................................... 1........... 2引用文挡........................................................................................... 3软件配置管理情况综述............................................................................. 4软件配置管理基本信息............................................................................. 5专业组划分及权限分酉己.......................................................................... 6配置项记录......................................................................................... 7变更记录........................................................................................... 8基线记录........................................................................................... 9入库记录...........................................................................................

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 配置项记录 本章所列出项目的所有配置项,包括配置项名称、配置项最后发布日期、配置项控制力度(控制力度可分为基线管理、非基线管理(受到管理和控制))、配置项版本变更历史、配置项变更累计次数等内容。

配置管理系统

配置管理系统(北大软件 010 - 61137666) 配置管理系统,采用基于构件等先进思想和技术,支持软件全生命周期的资源管理需求,确保软件工作产品的完整性、可追溯性。 配置管理系统支持对软件的配置标识、变更控制、状态纪实、配置审核、产品发布管理等功能,实现核心知识产权的积累和开发成果的复用。 1.1.1 组成结构(北大软件 010 - 61137666) 配置管理系统支持建立和维护三库:开发库、受控库、产品库。 根据企业安全管理策略设定分级控制方式,支持建立多级库,并建立相关控制关系;每级可设置若干个库;配置库可集中部署或分布式部署,即多库可以部署在一台服务器上,也可以部署在单独的多个服务器上。 1. 典型的三库管理,支持独立设置产品库、受控库、开发库,如下图所示。 图表1三库结构 2. 典型的四库管理,支持独立设置部门开发库、部门受控库、所级受控库、所级产品库等,如下图所示。

图表2四级库结构配置管理各库功能描述如下:

以“三库”结构为例,系统覆盖配置管理计划、配置标识、基线建立、入库、产品交付、配置变更、配置审核等环节,其演进及控制关系如下图。 图表3 配置管理工作流程 1.1.2主要特点(北大软件010 - 61137666) 3.独立灵活的多级库配置 支持国军标要求的独立设置产品库、受控库、开发库的要求,满足对配置资源的分级控制要求,支持软件开发库、受控库和产品库三库的独立管理,实现对受控库和产品库的入库、出库、变更控制和版本管理。

系统具有三库无限级联合与分布部署特性,可根据企业管理策略建立多控制级别的配置库,设定每级配置库的数量和上下级库间的控制关系,并支持开发库、受控库和产品库的统一管理。 4.产品生存全过程管理 支持软件配置管理全研发过程的活动和产品控制,即支持“用户严格按照配置管理计划实施配置管理—基于配置库的实际状况客观报告配置状态”的全过程的活动。 5.灵活的流程定制 可根据用户实际情况定制流程及表单。 6.支持线上线下审批方式 支持配置控制表单的网上在线审批(网上流转审批)和网下脱机审批两种工作模式,两种模式可以在同一项目中由配置管理人员根据实际情况灵活选用。 7.文档管理功能 实现软件文档的全生命周期管理,包括创建、审签、归档、发布、打印、作废等,能够按照项目策划的软件文档清单和归档计划实施自动检查,并产生定期报表。 8.丰富的统计查询功能,支持过程的测量和监控 支持相关人员对配置管理状态的查询和追溯。能够为领导层的管理和决策提供准确一致的决策支持信息,包括配置项和基线提交偏差情况、基线状态、一致性关系、产品出入库状况、变更状况、问题追踪、配置记实、配置审核的等重要信息; 9.配置库资源的安全控制 1)系统采用三员管理机制,分权管理系统的用户管理、权限分配、系统操 作日志管理。 2)系统基于角色的授权机制,支持权限最小化的策略; 3)系统可采用多种数据备份机制,提高系统的数据的抗毁性。 10.支持并行开发 系统采用文件共享锁机制实现多人对相同配置资源的并行开发控制。在系统共享文件修改控制机制的基础上,采用三种配置资源锁以实现对并行开发的

海湾配置管理工具的使用

火灾自动报警系统是在保护对象发生火灾的情况下自动探测、显示发出火灾警报的装置。它广泛应用于现代化工厂、物资仓库、高层建筑、计算中心等建筑物内,对保证人民的生命和财产安全起着巨大作用。 火灾自动报警要经历安装、接线、调试、验收等诸多环节,其中调试是其中最重要的一个环节之一。说起调试,每个火灾自动报警系统都有其特有的调试软件,而每个厂家的调试软件只有其相关的调试人员才会接触到,相对于普通人来说也是比较神秘的,下面国产火灾报警品牌巨头一海湾的进行揭秘。 首先打开海湾调试软件工具,屏幕会出现输入密码界面 输入密码后进入GstCfg配置管理工具界面,界面有标题栏、工具栏、状态区域和编辑区域组成。

WRIVJ.A 右击状态区域内“控制器”可以添加控制器操作,GstCfg配置管理工具可添加的控制器有GST20C火灾报警控制器、GST500/5000 火灾报警控制器、GST900C火灾报警控制器、DH9000电气火灾控制器、以及KR9000可燃气体报警控制器。 控制器添加界面可以对控制器的名称,是否联网、以及新老国标等基本属性进行选择。

控制器添加完成后进入如下界面,在这了我们添加一个新国标地址号是01的GST500C型火灾报警控制器 欝E.H k^ITEHlJ-A A EW4U眠皿活冋1SB 畑:fi ------------------- ■ j ■* 可以在左侧框内的GST5000C控制器右击选择添加回路,选择回路数量进行添加。添加好的界面如下

图中右侧显示的就是设备定义的界面, 在这里可以完成对所有设 备定义数据的填写。最左边的一列是设备的二次码, 选中右击二次码 可以对其进行批量修改。 ML 士 HS-ti p -yi | mmv ■■ 離 ?皿心卸 Et? ■F ■?; *g ■ Mimi I q ? mum ? 卜 ii 1 卫 L J Ml?]i | iSH> M G . 口亠■史曲 ■ :石「 '| E P L \ b □ 1 B —帛?P L ?吐皿 Q fl 4 HKOt 阿沁0 □ ■ i 沁〈亍6 * 4 * V M IO? 1 t .:.?■:::? >Q 4 | 1 i ?l?St 1 I I 0W"*E 0 L j 0 $ 川1 otltlt D L Qb”利1 ? 上理_; M |?|| fn- AhB D u 51- PS.m 1 h 一 ^ b 白 會 nsn 0?i-5HE 0 £ a>*3 Rfl J ~0 4 "t Al M IMF t 曲祐i b 1 Q V [| (^ICM OCMH 0 k 1 H 「 1 口*飓6 I 口 4 if 1 W 1 wi?ir CW4HL D ._"L g fi 曾 'P ' wwii 1 "T "?■ #£ 厂 t 1 6 i i ' il DMAII D C n> A949I □ ;M bMtt i ? i> *!?■? 1 fi ;n t awt-^'S n U S *9 J 口 4 HUtil X 蘇Q k 汁”枕 0 I ;裁?1?2f ' t gMt 0 L as 1 4 i 31 i i g?p-M Q . k "■却捆 n ii ■ i 亦a 沁"厂 k H ■■盟耐 Q 4 |T ?J0? & MHK P 匚岭彗r.g 1 Q I * NIKI £M?E 0 =H 联1 I 4 i£ —慣呻一 MMNE 6 I ? * . 1

软件项目配置管理系统计划清单指导应用清单

中国核电集团 CHINA GUANGDONG NUCLEAR POWER GROUP 记录文件 项目编号 项目名称 CGN-IT-C3-A12-01 软件项目配置管理计划 版本编写审核审定批准生效时间A/0 注:如无受控文件标识(蓝色印章)则为非有效版本,以受控文件规定为准。 此文件属中国核电集团所有,未经许可,不得以任何方式外传。

修改记录页

目录 (一)基本信息 (4) (二)角色与职责 (4) (三)配置管理资源 (5) (四)权限分配 (5) (五)配置项计划 (6) (六)配置库基线 (7) (七)配置库备份计划 (8) (八)配置库状态报告 (8) (九)配置审核 (9) (十)审批意见 (9)

配置管理计划(一)基本信息 项目名称: 项目代号: 立项时间: 预计主要项目阶段有: 配置项目命名规则依据: (二)角色与职责

(三)配置管理资源 本项目使用配置管理工具对各配置项进行存储、版本管理,并提供更新、检索和历史版本的恢复。 提示: (1)配置管理员确定本项目的配置管理软件。例如采用Microsoft公司的TFS或者IBM公司的clearecase。 (2)配置管理员根据所采用的配置管理软件,确定计算机资源(考虑存、外存、CPU等)。 预计建库申请日期: 预计建库日期: 预计工作库需空间: (四)权限分配 项目成员访问配置库的ID及PASSWORD默认设置为与域的设置相同。 若个人要求另行设置的,由项目组配置管理员负责汇总后,提交给高级配置管理员调整设置。

(五)配置项计划 填写上面表格过程中,需要对照成果物列表逐项填写。

软件配置管理计划

软件配置管理计划示例 计划名国势通多媒体网络传输加速系统软件配置管理计划 项目名国势通多媒体网络传输加速系统软件 项目委托单位代表签名年月日 项目承办单位北京麦秸创想科技有限责任公司 代表签名年月日 1 引言 1.1 目的 本计划的目的在于对所开发的国势通多媒体网络传输加速系统软件规定各种必要的配置管理条款,以保证所交付的国势通多媒体网络传输加速系统软件能够满足项目委托书中规定的各种原则需求,能够满足本项目总体组制定的且经领导小组批准的软件系统需求规格说明书中规定的各项具体需求。 软件开发单位在开发本项目所属的各子系统(其中包括为本项目研制或选用的各种支持软件)时,都应该执行本计划中的有关规定,但可以根据各自的情况对本计划作适当的剪裁,以满足特定的配置管理需求。剪裁后的计划必须经总体组批准。 1.2 定义 本计划中用到的一些术语的定义按GB/T 11457 和GB/T 12504。 1.3 参考资料

◆GB/T 11457 软件工程术语 ◆GB 8566 计算机软件开发规范 ◆GB 8567 计算机软件产品开发文件编制指南 ◆GB/T 12504 计算机软件质量保证计划规范 ◆GB/T 12505 计算机软件配置管理计划规范 ◆国势通多媒体网络传输加速系统软件质量保证计划 2 管理 2.1 机构 在本软件系统整个开发期间,必须成立软件配置管理小组负责配置管理工作。软件配置管理小组属项目总体组领导,由总体组代表、软件工程小组代表、项目的专职配置管理人员、项目的专职质量保证人员以及各个子系统软件配置管理人员等方面的人员组成,由总体组代表任组长。各子系统的软件配置管理人员在业务上受软件配置管理小组领导,在行政上受子系统负责人领导。软件配置管理小组和软件配置管理人员必须检查和督促本计划的实施。各子系统的软件配置管理人员有权直接向软件配置管理小组报告子项目的软件配置管理情况。各子系统的软件配置管理人员应该根据对子项目的具体要求,制订必要的规程和规定,以确保完全遵守本计划规定的所有要求。 2.2 任务

软件配置管理计划示例

软件配置管理计划示例 作者:赵文锋计划名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.各子系统的配置管理人员具体负责实施各自的配置管理工作,并参与各子系统的功能配置检查和物理配置检查;

配置管理工具SVN

软件配置管理工具SVN配置和使用说明 战立章 2008年6月

目录 第I 条第一章SVN的安装和使用说明 (1) 1.1SVN(Subversion)简介 (1) 1.2服务器SVN(Subversion)的安装和配置 (2) 1.2.1安装指南 (3) 1.2.2服务器的设置 (3) 1.3客户端TortoiseSVN的安装和配置 (5) 1.3.1安装指南 (5) 1.3.2TortoiseSVN使用说明 (5) 第II 条参考文献 (11)

第I 条第一章SVN的安装和使用说明 1.1SVN(Subversion)简介 在开源领域,并行版本控制(CVS)一直是版本控制的选择。CVS(Concurrent Versions System)本身是一个自由的软件,它对用户的非限制性和对网络操作的支持—可以允许大量的分散在不同地域的程序员共享他们的工作(特性)成果,非常符合开源软件领域合作的精神。但是像许多其他工具一样,伴随着软件技术的革新,CVS开始露出了衰老的痕迹。所以,设计者在继承CVS优秀特性的基础上设计了Subversion,并把它作为CVS新的继承者。与CVS类似,程序员依然可以使用Subversion构建一个开源软件系统的版本控制过程,但设计者在设计Subversion过程中,努力弥补了CVS的一些明显的缺陷。下面将通过与CVS对比,简单的介绍Subversion为版本控制领域带来的一些新的特性。 1.版本化的目录 CVS只记录单个文件的历史,但是Subversion实现了一个可以跟踪目录树更改的虚拟版本化文件系统,记录文件和目录的所有版本。 2.真实的版本历史 CVS只记录单个文件的历史,所以CVS对那些可能发生在文件上,但会影响所在目录内容的操作(CVS并不跟踪记录目录的变更,见特性1说明)并不支持。因此,例如,复制和重命名,这些可能改变工作目录内容的操作CVS并不支持。而且在CVS中,如果一个文件搬到另一个地方或者改名,版本号将重新编。同时CVS也不支持在工作目录下用一个内容完全不同的文件来覆盖目录下的同名文件而不继承原来文件的版本历史。而在Subversion中,可以对工作目录下的文件或者目录进行拷贝和改名操作,还可以进行添加和删除操作,而且所有的新加的文件都从一个新的、干净的版本开始。 3.原子提交 在Subversion中,一系列的修改要么全部提交到版本库,要么一个也不提交,这样可以帮助用户构建一个提交修改的逻辑块,防止部分修改添加到版本库。 4.版本化的元数据 在Subversion版本控制系统中,每一个文件或目录都有自己一套完整的属性键和它们的值,可以建立并存储任何键/值对,并且属性是随着时间流逝逐渐纳入版本控制的。

校务通管理系统软件项目配置管理计划案例

软件项目配置管理计划案例 本案例选自《软件项目管理案例教程》(韩万江,机械工业出版社)一书,项目案例为《校务通管理系统》,该项目的配置管理计划如下: 1. 引言 包括目的、缩写词和参考资料,具体内容略。 2.组织及职责 配置管理的角色和职责见表1。 表1:配置管理角色职责表 3.配置管理环境 由于本项目属于中小型项目,工期也不很长,而且项目组人员对Visual SourceSafe也比较熟悉,所以采用Visual SourceSafe作为配置管理工具。 3.1配置库目录结构

3.2用户及权限 4.配置管理活动 4.1 配置项标志 4.1.1 命名规范 本项目配置项命名规范由5个字段组成,从左到右依次为:公司、项目、类型、编号和版本号,如图1所示。这些字段用一横线(-)分隔。

图1:配置项命名规范 4.1.2 主要配置项 QTD-School –RM –SRS-v1.0 公司:3个字符 项目:最长10个字符 类型:最长5个字符 编号:最长8位数字/字符 版本号:V m.n

4.1.3 项目基线 在Visual SourceSafe中基线由LABLE标志,字母必须为大写。基线管理由项目执行负责人确认、SCCB授权,由配置管理员执行。 表5 4.1.4 配置项的版本管理 配置项可能包含的分支从逻辑上可以划分成4个不同功能的分支:主干分支、私有分支、小组分支、集成分支。让它们分别对应4类工作空间。 这四类工作空间(分支)由项目执行负责人统一管理,根据各开发阶段的实际情况定制相应的版本选取规则,来保证开发活动的正常运作。在变更发生时,应及时做好基线的推进。 对配置项的版本管理在不同分支具有不同的策略: (1)主干分支 系统默认自动建立的物理分支——主干分支(/main),基线均以LABLE方式出现在主干分支上。 (2)私有分支 如果多个开发工程师维护一个配置项时建议建立自己的私有分支。配置管理员对其基本不与管理,如个别私有空间上的版本树过于冗余,将对其冗余版本进行限制。 (3)小组分支 如果出现小组共同开发一配置项,该分支可视为项目组内部分组的私有空间,存放代码开发过程中的版本分支,由项目组内部控制。

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

软件配置管理规范 流程 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解决了软件开发小组长期所面临的版本管理问题,它可能有效地帮助项目开发组的负责人对项目程序进行管理,将所有的项目源文件(包括各种文件类型)以特有的方式存入数据库。开发组的成员不能对该数据库中的

软件配置管理控制程序

配置管理控制程序 版本号修订内容编制人审阅人日期

历史记录

目录

1.引言 1.1目的 本程序文件定义了本组织的配置管理的过程,目的是规范公司的软件配置管理活动,使公司的所有软件开发项目的软件配置管理活动都能按照统一的要求进行。 1.2 使用范围 本文件适用于公司的所有软件项目。 1.3 名词和缩写 CM(Configuration Management) 配置管理 SCCB (Software Configuration Control Board) 软件配置管理控制委员会 CC (Configuration Controller) 配置管理员 工作产品(Work Products):项目技术开发和管理工作中产生的有价值的成果,例如源代码、数据和各种文档。 配置项(Configuration Item, CI):纳入到配置管理范畴作为单个实体对待的工作产品称为配置项[IEEE Std 610.12 - 1990 ];配置项包括:项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据,它们经评审和检查通过后进入软件配置管理。 基线(Baseline):一组拥有唯一标识号的需求、设计、源代码文卷以及相应的可执行代码、构造文卷和用户文档构成一条基线。基线一经放行,就可以作为从配置管理系统检索源代码文卷(配置项)和生成可执行文卷的工具。

2角色与职责 2.1软件配置管理组(CM) CM组是项目里的一个小组,根据项目大小,可以由一个人,或者多人组成,小组的成员称为配置管理员(CC),通常由公司的质量保证组安排,加入到项目组,由项目经理领导。 CM组建立并管理配置管理库系统。 CM组负责组织相关部门和人员进行有关CM活动的培训。 项目组的CM组负责在该项目的整个生命周期中进行配置管理活动。 2.2软件配置管理控制委员会(SCCB) SCCB建立在项目级,通常由项目经理、该项目的技术经理、软件开发工程师、资深工程师、测试经理/测试工程师以及CC组成。SCCB在项目策划阶段由项目经理负责筹建。 配置管理控制委员会负责审批软件配置管理计划; 配置管理控制委员会负责审批软件基线的建立; 配置管理控制委员会负责审批对软件基线配置项的变更; 配置管理控制委员会负责审核和批准产品发布。 2.3 SCCB负责人 SCCB负责人通常由项目经理担任,代表SCCB在有关文件上签署意见。 2.4 项目经理 定期或事件驱动地评审或审核CM活动。 2.5 测试组 负责审核《配置管理计划》任务列表中与测试有关的内容 2.6 开发组 负责审核《配置管理计划》任务列表中与开发有关的内容 2.7 QA组 负责审核《配置管理计划》任务列表中与QA有关的内容

软件配置管理规范流程

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) 在配置管理系统中,基线就是一个配置项或一组配置项在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态,这些配置项构成了一个相对稳定的逻辑实体,而这个过程被称为“基线化”。每一

软件配置管理题库【.10.26】

理论部分 1.你是怎么理解软件配置管理的? 软件配置管理为软件研发提供了基础性的支持环境,每个人都要面对软件配置管理,学习使用它,根据具体情况选择正确的策略和方法,以便从它那里充分受益。 2.软件配置管理的作用或意义? 在软件建立时变更是不可避免的,而变更加剧了项目中软件开发者之间的混乱。软件配置管理的目标就是为了标识变更、控制变更、确保变更正确实现并向其他有关人员报告变更。 3.IPD流程有几个决策评审点,几个技术评审点?各个技术评审点的作用? 4个:概念决策评审(CDCP)计划决策评审(PDCP)计划决策评审(PDCP)可获得性评审(ADCP) 目标、关注点、输入、输出 4.IPD流程分为哪几个阶段? 3个:市场管理(MM)、需求管理(OR)、继承产品开发(IPD) 5.IPD流程的核心思想是什么? 1.产品开发是投资行为 2.基于市场的创新 3.基于平台的异步开发模式和重用策略 4.技术开发和产品开发分离 5.跨部门协同 6.结构化并行开发流程 7.产品线和能力线并重 8.职业化人才梯队建设 你是如何理解软件工作成果的? 软件工作成果包含哪些? 管理、系统分析、设计、编码,还是产品管理、测试、文档、实施、维护 6.举例说明什么是配置项?配置项有哪些属性? 凡是纳入配置管理范畴的工作成果都是配置项 配置项有两大类:属于产品组成部分的工作成果;项目管理和机构职称过程产生的文档。 属性有:名称、标示符文件状态、版本、作者、日期…… 7.什么是配置库? 存放配置项的数据库,常用两种形式:按配置项类型分类建库和按任务建库。 如果让你为你们组的项目规划一个目录结构,你认为哪些目录是必须的? 1.项目立项与策划 2.需求分析

VNX初始化配置工具VIA介绍和配置指南

VNX初始化配置工具VIA介绍和配置指南 VIA工具是VNX Installation Assist的简写,顾名思义就是VNX的安装配置工具,用来完成对VNX Block或者Unified存储系统进行初始化配置或者升级安装。 VIA是一个运行在笔记本上的Jave编写的图形化工具,主要用途有: ●VNX系统安装完毕后,配置Control station,Data Movers和存储系统 ●支持从Block系统升级Unified存储系统的安装 ●激活License enabler,如CIFS,NFS,Replicator,File Level Retention和SnapSure 等 对于Unified存储系统的配置安装一定要使用VIA工具,如果是单独的Block系统安装配置,可以不使用VIA工具。 对于一套完整的Unified存储系统,在完成连线和加电后,一般使用VIA,可以完成如下的配置工作。 ●设置网络参数(CS和SP有不同的网络参数设置) ●修改缺省的密码等 ●设置Data Mover ●配置远程支持,也就是ESRS,这个在中国客户这里一般很少使用 ●激活各种license ●系统的健康检查 下面是一个利用VIA进行存储系统配置的step by step例子,供大家学习使用。 1.在笔记本桌面启动VIA, 连接VIA和Control station,并配置CS网络和笔记本在同 一子网内。VIA自动搜索没有配置的VNX系统。如下图所示:

2.搜索到没有配置的VNX系统,开始配置File部分,如下图所示,配置Control station 的网络部分。 3.正确配置完毕CS后,系统给出成功提示,如下图所示:

相关文档
相关文档 最新文档