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

软件配置项标识编码规则设计方案XX201X1. 背景1.1. 服务外包中迁移在服务外包中，难度较大的阶段为服务外包的迁移工程。服务迁移工程难度大的主要原因之一，是没有实施迁移前准备标准和迁移后的验收标准。也就是在服务成熟到何种程度包括管理与技术成熟度，服务才能够向外包方进行迁移，以便发包方有效控制服务外包中的风险，达到服务外包的目的。服务外包迁移前应达到的准备标准包括管理标准与技术标准，技术标准是管理标准的基础。技术标准是在服务外包迁移中的必要条件，管理标准是服务外包迁移中的充分条件。不同服务业务在外包迁移中，具有不同的技术标准，但是具有相同的管理标准ISO20000规定了管理相关的内容。因为不同的服务业务具有不同的服务技术标准要求，因此正对IT服务外包业务应根据业务的特点编制相关的技术标准要求。IT服务外包业务可以包括：l IT系统基础平台维护服务外包l IT系统支撑环境维护服务外包l 应用系统的维护服务外包1.2. 服务外包迁移标准内容每类服务有可以分成：运营服务（一线服务）、支持性服务（二线服务）、变更性服务（三线服务）。在IT服务外包中风险较大的是运营服务，因为运营服务一直是直接在客户的生产环境实施，一旦发生错误，有可能给客户造成无法挽回的损失。目前一般风险较大的运营服务，有客户自己承担，不进行外包。支持性服务也是在客户生产环境实施，但是一般需要进行策划与实施结果测试。由于支持服务具有一定的技术性，因此这种服务外包迁移前应按照技术标准要求通过验收。只有通过技术标准验收的服务才能够实施服务外包的迁移。变更性服务是在其他环境中测试完成后，在反映到生产环境中。因此变更性服务与系统建设期的系统开发存在不同的风险。在系统建设期，可以进行充分的测试与试运行测试。在变更性服务由于工期与成本的原因，可能不能充分进行测试与试运行。1.3. 服务外包迁移中标准需求服务外包方为了及时提供服务需要将分包方的技术成果迁移到外包方处，因此分包方向服务外包方进行服务迁移时，在服务迁移时，迁移哪些内容，迁移的内容在迁移前应到技术标准要求应进行验证与确认。若是没有达到服务外包迁移技术标准，很显然是增加服务外包迁移的风险。在服务外包迁移实施中，需要对服务外包迁移内容结果进行验证，因此需要服务外包迁移结果验证与确认的技术标准要求。1.4. 应用软件服务迁移标准需求分析在应用软件系统维护服务外包的迁移中，技术标准主要是针对分包方迁移给外包方的所有技术成果物。对这些成果物需要相关的技术标准要求，以便在服务外包迁移过程，分包方与外包方能够有效沟通与交接，确保服务能够连续，不因为服务外包迁移发生中断或服务水平下降。为了确保分包方与外包方能够有效进行技术沟通，首先需要明确出工程成果物的标识标准配置项标识编码标准。这一标准能够是双方能够正确地在配置管理库中找到所需要的配置项。为了能够有效避免交付过程中，使用错误的成果物。就需要双方共同承认的成果物的编码规则或标准。由此得出结论：软件配置项标识编码规则，是IT应用系统维护服务外包的技术标准中的基础。2. 方案的目的与目标2.1. 目的通过提供一般软件配置项编码规则，为企业的软件配置项的管理提供自动化处理的解决方案，以便有效实现在不同软件系统或组件之间实现复用与共享，实现提高软件企业开发效率与质量的目的。2.2. 目标通过按照软件配置项编码规则对软件配置项进行编码，应达到如下目标：l 能够有效实现配置项纵向跟踪。如：应用系统分解成多少子系统，子系统分解多少功能。l 能够识别出配置项的类型。如：根据配置项编码识别出配置项是功能配置项还是数据配置项等等。l 能够确定配置项对应的电子物理名称的编码。如根据配置项的逻辑标识，能够确定其电子文件名称、以及其配置项父配置项的电子文件名称或其父配置项的目录名称及其与配置管理相关属性信息。3. 方案原则3.1. 方法l 软件配置项的配置管理编码方法，建议采用正交编码方法。l 在每个维度是全面的，及包含所有的内容分类。l 每个内容分类是唯一的，相互之间不重叠、不交叉，并且没有遗漏。3.2. 技术要求编码规范应适应环境的要求。环境技术要求如下：l 为了确保在管理工程中能有效识别与处理，在编码规范中，采用字母与数字等。l 与操作系统文件与目录名称规则兼容。l 在不同语言操作系统中兼容。4. 方案考虑的维度建议方案考虑的维度：l 软件系统各个视图结构一个系统可从多个维度进行描述，因此需要多种视图。多个视图之间是存在逻辑关系的。一个系统是从上至下分解，因此一个大的主题可以分解子主题，分解中可以进行合并与抽象，形成性的编码规则体系。n 逻辑视图结构。如：应用软件系统、子系统、功能、组件、模块、类、方法。n 外部视图结构。如：画面，画面迁移图。n 部署视图结构。如：网络结构图、应用软件部署结构图、软件组件部署设计书n 动态视图结构。如：动态结构图、动态链接图n 数据视图结构。如：概念数据描述（业务分析工程）、逻辑数据模型描述（需求开发工程）、物理数据模型描述（设计工程）、数据定义程序（实现工程）、数据维护（维护工程）。u 数据关系图u 数据字典u 数据码表u 数据完整规则l 软件系统元素关系n 部署组件关系，如：支撑平台结构图、应用软件支撑环境结构图、应用软件部署结构图n 关系视图结构。如：外部视图与逻辑视图中组件之间关系，外部视图与数据时之间关系l 软件生命周期中工程。如：业务分析工程、需求开发工程、设计工程、实现工程、测试工程、交付实施工程、维护工程、引退工程。l 软件生命周期中工作类型及其输出的工作产品。如：评审、缺陷处理、需求管理、变更管理。5. 方案编制应考虑内容软件配置标识应考虑如下维度：l 对象维度n 逻辑对象实体对象实体n 对象视角实体不同对象，可以由多个角度进行描述n 对象描述实体不同视角，可以形成多个描述文档实体l 工程维度n 业务分析n 需求定义n 设计n 实现n 测试n 交付l 过程类别n 评审n 缺陷n 配置管理l 来源维度n 开发n 开源n 采购n 开发环境提供l 产品类别n FrameWorkn 基盘n 软件包n 系统n 产品l 系统环境n 基础n 软件应用支撑环境n 应用软件6. 编码设计方案6.1. 通用件通用件无任何行业特点。在应用软件中通用件是作为基盘方式被应用的。基盘在企业中，可以存在多种。如C语言基盘、JAVA语言基盘、.NET基盘等。可能在不同的软件开发部门，各自存在基盘。因此，需要企业以组织结构为单位定义其基盘的编码规则。6.2. 借用件复用件的编号应采用被复用件的编号。6.3. 产品图样编号产品图样编号一般采用隶属编号。也可以采用分类编号。参见附录A产品图样和设计文件编号应与企业计算机辅助管理代码相协调7. 基本原则7.1. 图样和文件编号一般可采用下列字符：09 阿拉伯数字；AZ 拉丁字母（O、I 除外）；短横线、圆点、/ 斜线。7.2. 编号的基本原则1) 科学性选择事物或概念的最稳定的本质属性或特征作为信息分类的基础和依据。2) 系统性将选定的事物、概念的属性或特征按一定排列顺序予以系统化，并形成一个合理的科学分类体系。3) 唯一性一个代码只能唯一地标识一个分类对象。4) 可延性要设置收容类目，以便保证增加新的事物和概念时，不致打乱已建立的分类体系，同时，还应为下级信息管理系统在原有基础上的延拓、细化创造条件。5) 规范性同一层级代码的编写格式必须统一。8. 一般要求8.1. 每个产品、部件、零件的图样和文件均应有独立的代号。9. 工程定义工程名称工程代码英文缩写英文业务分析01BABusiness Analyze需求开发02RDRequirement Develop概要设计03BDBasic Design详细设计04DDDetail Design程序设计05PDProgram Design编码06CDCoding单体测试07UTUnit Test结合测试08CTCombine tTest系统测试09STSystem Test实施交付10ADApplication Delivery运行维护11OMOperations & Maintenance10. 对象深度设计方案深度按照5级设计。即业务分析，可以将一个系统划分成5级深度。L0：2位数字，不足2位，前面用0补齐。L1：2位数字，不足2位，前面用0补齐。L2：2位数字，不足2位，前面用0补齐。L3：2位数字，不足两位，前面用0补齐。L4：2位数字，不足两位，前面用0补齐。11. 对象类型编码设计对象类型编码作为补充说明编码，可以省略。对象类型编码采用英文缩写，缩写字母为2位。12. 对象语言类型编码设计外包环境中，同一种对象存在多种语言版本，因此需要语言编码。语言编码为2位字母。中文时，编码可省略。常用语言缩写编码如下：语言编码缩写语言DE德文EN英文ES西班牙文FR法文IT意大利文JA日文RU俄文ZH中文语言编码如下：语言编码缩写语言AR阿拉伯文BE白俄罗斯文BG保加利亚文CA加泰罗尼亚文CS捷克文DA丹麦文