软件配置项标识编码规则设计方案解读.docx

上传人:b****6 文档编号:7561850 上传时间:2023-01-25 格式:DOCX 页数:11 大小:20.08KB
下载 相关 举报
软件配置项标识编码规则设计方案解读.docx_第1页
第1页 / 共11页
软件配置项标识编码规则设计方案解读.docx_第2页
第2页 / 共11页
软件配置项标识编码规则设计方案解读.docx_第3页
第3页 / 共11页
软件配置项标识编码规则设计方案解读.docx_第4页
第4页 / 共11页
软件配置项标识编码规则设计方案解读.docx_第5页
第5页 / 共11页
点击查看更多>>
下载资源
资源描述

软件配置项标识编码规则设计方案解读.docx

《软件配置项标识编码规则设计方案解读.docx》由会员分享,可在线阅读,更多相关《软件配置项标识编码规则设计方案解读.docx(11页珍藏版)》请在冰豆网上搜索。

软件配置项标识编码规则设计方案解读.docx

软件配置项标识编码规则设计方案解读

软件配置项标识编码规则设计方案

刘宏

2011-9-18

Mail:

lh@

 

1. 背景

1.1. 服务外包中迁移

在服务外包中,难度较大的阶段为——服务外包的迁移工程。

服务迁移工程难度大的主要原因之一,是没有实施迁移前准备标准和迁移后的验收标

准。

也就是在服务成熟到何种程度——包括管理与技术成熟度,服务才能够向外包方进行

迁移,以便发包方有效控制服务外包中的风险,达到服务外包的目的。

服务外包迁移前应达到的准备标准——包括管理标准与技术标准,技术标准是管理标

准的基础。

技术标准是在服务外包迁移中的必要条件,管理标准是服务外包迁移中的充分

条件。

不同服务业务在外包迁移中,具有不同的技术标准,但是具有相同的管理标准——

ISO20000 规定了管理相关的内容。

因为不同的服务业务具有不同的服务技术标准要求,因此正对 IT 服务外包业务应根据

业务的特点编制相关的技术标准要求。

IT 服务外包业务可以包括:

●IT 系统基础平台维护服务外包

●IT 系统支撑环境维护服务外包

●应用系统的维护服务外包

1.2. 服务外包迁移标准内容

每类服务有可以分成:

运营服务(一线服务)、支持性服务(二线服务)、变更性服

务(三线服务)。

在 IT 服务外包中风险较大的是运营服务,因为运营服务一直是直接在客户的生产环境

实施,一旦发生错误,有可能给客户造成无法挽回的损失。

目前一般风险较大的运营服务,

有客户自己承担,不进行外包。

支持性服务也是在客户生产环境实施,但是一般需要进行策划与实施结果测试。

由于

支持服务具有一定的技术性,因此这种服务外包迁移前应按照技术标准要求通过验收。

有通过技术标准验收的服务才能够实施服务外包的迁移。

变更性服务是在其他环境中测试完成后,在反映到生产环境中。

因此变更性服务与系

统建设期的系统开发存在不同的风险。

在系统建设期,可以进行充分的测试与试运行测试。

在变更性服务由于工期与成本的原因,可能不能充分进行测试与试运行。

1.3. 服务外包迁移中标准需求

服务外包方为了及时提供服务需要将分包方的技术成果迁移到外包方处,因此分包方

向服务外包方进行服务迁移时,在服务迁移时,迁移哪些内容,迁移的内容在迁移前应到

技术标准要求应进行验证与确认。

若是没有达到服务外包迁移技术标准,很显然是增加服

务外包迁移的风险。

在服务外包迁移实施中,需要对服务外包迁移内容结果进行验证,因此需要服务外包

迁移结果验证与确认的技术标准要求。

1.4. 应用软件服务迁移标准需求分析

在应用软件系统维护服务外包的迁移中,技术标准主要是针对分包方迁移给外包方的

所有技术成果物。

对这些成果物需要相关的技术标准要求,以便在服务外包迁移过程,分

包方与外包方能够有效沟通与交接,确保服务能够连续,不因为服务外包迁移发生中断或

服务水平下降。

为了确保分包方与外包方能够有效进行技术沟通,首先需要明确出工程成果物的标识

标准——配置项标识编码标准。

这一标准能够是双方能够正确地在配置管理库中找到所需

要的配置项。

为了能够有效避免交付过程中,使用错误的成果物。

就需要双方共同承认的成果物的

编码规则或标准。

由此得出结论:

软件配置项标识编码规则,是 IT 应用系统维护服务外包的技术标准中

的基础。

2. 方案的目的与目标

2.1. 目的

通过提供一般软件配置项编码规则,为企业的软件配置项的管理提供自动化处理的解

决方案,以便有效实现在不同软件系统或组件之间实现复用与共享,实现提高软件企业开

发效率与质量的目的。

2.2. 目标

通过按照软件配置项编码规则对软件配置项进行编码,应达到如下目标:

●能够有效实现配置项纵向跟踪。

如:

应用系统分解成多少子系统,子系统分解多

少功能。

●能够识别出配置项的类型。

如:

根据配置项编码识别出配置项是功能配置项还是

数据配置项等等。

●能够确定配置项对应的电子物理名称的编码。

如根据配置项的逻辑标识,能够确

定其电子文件名称、以及其配置项父配置项的电子文件名称或其父配置项的目录

名称及其与配置管理相关属性信息。

3. 方案原则

3.1. 方法

●软件配置项的配置管理编码方法,建议采用正交编码方法。

●在每个维度是全面的,及包含所有的内容分类。

●每个内容分类是唯一的,相互之间不重叠、不交叉,并且没有遗漏。

3.2. 技术要求

编码规范应适应环境的要求。

环境技术要求如下:

●为了确保在管理工程中能有效识别与处理,在编码规范中,采用字母与数字等。

●与操作系统文件与目录名称规则兼容。

●在不同语言操作系统中兼容。

4. 方案考虑的维度

建议方案考虑的维度:

●软件系统各个视图结构

一个系统可从多个维度进行描述,因此需要多种视图。

多个视图之间是存在逻辑

关系的。

一个系统是从上至下分解,因此一个大的主题可以分解子主题,分解中

可以进行合并与抽象,形成性的编码规则体系。

⏹逻辑视图结构。

如:

应用软件系统、子系统、功能、组件、模块、类、方法。

 

⏹外部视图结构。

如:

画面,画面迁移图。

⏹部署视图结构。

如:

网络结构图、应用软件部署结构图、软件组件部署设计

⏹动态视图结构。

如:

动态结构图、动态链接图

⏹数据视图结构。

如:

概念数据描述(业务分析工程)、逻辑数据模型描述

(需求开发工程)、物理数据模型描述(设计工程)、数据定义程序(实现

工程)、数据维护(维护工程)。

◆ 数据关系图

◆ 数据字典

◆ 数据码表

◆ 数据完整规则

●软件系统元素关系

⏹部署组件关系,如:

支撑平台结构图、应用软件支撑环境结构图、应用软件

部署结构图

⏹关系视图结构。

如:

外部视图与逻辑视图中组件之间关系,外部视图与数据

时之间关系

●软件生命周期中工程。

如:

业务分析工程、需求开发工程、设计工程、实现工程、

测试工程、交付实施工程、维护工程、引退工程。

●软件生命周期中工作类型及其输出的工作产品。

如:

评审、缺陷处理、需求管理、

变更管理。

5. 方案编制应考虑内容

软件配置标识应考虑如下维度:

●对象维度

⏹逻辑对象实体——对象实体

⏹对象视角实体——不同对象,可以由多个角度进行描述

⏹对象描述实体——不同视角,可以形成多个描述文档实体

●工程维度

⏹业务分析

⏹需求定义

⏹设计

⏹实现

⏹测试

⏹交付

●过程类别

⏹评审

⏹缺陷

⏹配置管理

●来源维度

⏹开发

⏹开源

⏹采购

⏹开发环境提供

●产品类别

⏹FrameWork

⏹基盘

⏹软件包

⏹系统

⏹产品

●系统环境

⏹基础

⏹软件应用支撑环境

⏹应用软件

6. 编码设计方案

6.1. 通用件

通用件无任何行业特点。

在应用软件中通用件是作为基盘方式被应用的。

基盘在企业中,可以存在多种。

如 C 语言基盘、JAVA 语言基盘、.NET 基盘等。

工程名称

工程代码

英文缩写

英文

业务分析

01

BA

Business Analyze

9.  工程定义

可能在不同的软件开发部门,各自存在基盘。

因此,需要企业以组织结构为单位定义

其基盘的编码规则。

6.2. 借用件

复用件的编号应采用被复用件的编号。

6.3. 产品图样编号

产品图样编号一般采用隶属编号。

也可以采用分类编号。

参见附录 A

产品图样和设计文件编号应与企业计算机辅助管理代码相协调

 

7. 基本原则

7.1. 图样和文件编号一般可采用下列字符:

——0~9 阿拉伯数字;

——A~Z 拉丁字母(O、I 除外);

——短横线、·圆点、/ 斜线。

7.2. 编号的基本原则

1)  科学性选择事物或概念的最稳定的本质属性或特征作为信息分类的基础和依据。

2)  系统性将选定的事物、概念的属性或特征按一定排列顺序予以系统化,并形成一

个合理的科学分类体系。

3)  唯一性一个代码只能唯一地标识一个分类对象。

4)  可延性要设置收容类目,以便保证增加新的事物和概念时,不致打乱已建立的分

类体系,同时,还应为下级信息管理系统在原有基础上的延拓、细化创造条件。

5)  规范性同一层级代码的编写格式必须统一。

8. 一般要求

8.1. 每个产品、部件、零件的图样和文件均应有独立的代号。

需求开发

02

RD

Requirement Develop

概要设计

03

BD

Basic Design

详细设计

04

DD

Detail Design

程序设计

05

PD

Program Design

编码

06

CD

Coding

单体测试

07

UT

Unit Test

结合测试

08

CT

Combine tTest

系统测试

09

ST

System Test

实施交付

10

AD

Application Delivery

运行维护

11

OM

Operations & Maintenance

 

10.对象深度设计方案

深度按照 5 级设计。

即业务分析,可以将一个系统划分成 5 级深度。

L0:

2 位数字,不足 2 位,前面用 0 补齐。

L1:

2 位数字,不足 2 位,前面用 0 补齐。

L2:

2 位数字,不足 2 位,前面用 0 补齐。

L3:

2 位数字,不足两位,前面用 0 补齐。

L4:

2 位数字,不足两位,前面用 0 补齐。

11.对象类型编码设计

对象类型编码作为补充说明编码,可以省略。

对象类型编码采用英文缩写,缩写字母为 2 位。

12.对象语言类型编码设计

外包环境中,同一种对象存在多种语言版本,因此需要语言编码。

语言编码为 2 位字

语言编码缩写

语言

AR

阿拉伯文

BE

白俄罗斯文

BG

保加利亚文

CA

加泰罗尼亚文

CS

捷克文

DA

丹麦文

DE

德文

EL

希腊文

EN

英文

ES

西班牙文

ET

爱沙尼亚文

FI

芬兰文

FR

法文

HR

克罗地亚文

HU

匈牙利文

IS

冰岛文

IT

意大利文

IW

希伯来文

JA

日文

KO

朝鲜文

LT

立陶宛文

LV

拉托维亚文(列托)

MK

马其顿文

NL

荷兰文

语言编码缩写

语言

DE

德文

EN

英文

ES

西班牙文

FR

法文

IT

意大利文

JA

日文

RU

俄文

ZH

中文

母。

中文时,编码可省略。

常用语言缩写编码如下:

 

语言编码如下:

语言编码缩写

语言

NO

挪威文

PL

波兰文

PT

葡萄牙文

RO

罗马尼亚文

RU

俄文

SH

塞波尼斯-克罗地亚文

SK

斯洛伐克文

SL

斯洛文尼亚文

SQ

阿尔巴尼亚文

SR

塞尔维亚文

SV

瑞典文

TH

泰文

TR

土耳其文

UK

乌克兰文

ZH

中文

 

读书的好处

 

1、行万里路,读万卷书。

2、书山有路勤为径,学海无涯苦作舟。

3、读书破万卷,下笔如有神。

4、我所学到的任何有价值的知识都是由自学中得来的。

——达尔文

5、少壮不努力,老大徒悲伤。

6、黑发不知勤学早,白首方悔读书迟。

——颜真卿

7、宝剑锋从磨砺出,梅花香自苦寒来。

8、读书要三到:

心到、眼到、口到

9、玉不琢、不成器,人不学、不知义。

10、一日无书,百事荒废。

——陈寿

11、书是人类进步的阶梯。

12、一日不读口生,一日不写手生。

13、我扑在书上,就像饥饿的人扑在面包上。

——高尔基

14、书到用时方恨少、事非经过不知难。

——陆游

15、读一本好书,就如同和一个高尚的人在交谈——歌德

16、读一切好书,就是和许多高尚的人谈话。

——笛卡儿

17、学习永远不晚。

——高尔基

18、少而好学,如日出之阳;壮而好学,如日中之光;志而好学,如炳烛之光。

——刘向

19、学而不思则惘,思而不学则殆。

——孔子

20、读书给人以快乐、给人以光彩、给人以才干。

——培根

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 教学研究 > 教学案例设计

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1