软件配置项标识编码规则设计方案解读
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
软件配置项标识编码规则设计方案
刘宏
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.方案编制应考虑内容
软件配置标识应考虑如下维度:
●对象维度
⏹逻辑对象实体——对象实体
⏹对象视角实体——不同对象,可以由多个角度进行描述
⏹对象描述实体——不同视角,可以形成多个描述文档实体
●工程维度
⏹业务分析
⏹需求定义
⏹设计