业务配置流程

业务配置流程
业务配置流程

现在PTN的业务配置主要是以太网专线业务的配置,以下是配置流程:

一、接口IP地址的设置:

1、设置接口的IP地址,可自动分配,亦可手动分配;目前使用自动分配。

2、在分配IP地址前须将端口的模式修改为三层,在三层属性选项中使能Tunnel使能状态。

3、创建链路时会弹出下图;在自动分配IP选项中选择‘是’即可。

二、创建静态Tunnel

1、对于Tunnel的创建,在主视图的路径下创建,如下图选择;

2、创建时名称要根据实际的路径命名、其他选项默认,注意在‘创建反向Tunnel’的前要打‘√’,因为Tunnel是单向的。单击下一步。

3、如下图:在Ingress选入源节点、Egress选入宿节点、Transit选入中间网元。单击‘下一步’。

4、在出、入接口的选项中选入对应的接口。比如12-29雪峰大厦的1-EG2-1与12-28千越百货的1-EG2-2相连,依次选入各对应的接口。单击“自动分配标签”。出入标签会重新分配的。单击下一步。

5、如下图:检查正向和反向Tunnel的对应的下一跳地址是否能在同一网段,无误单击应用。静态Tunnel 创建完成。

文类型为FFD、检测报文周期为3.3S,单击右下角应用。在对端的网元做相同的操作(即在上塘2)。

7、选中Tunnel右击,出现如图菜单,单击查询LSP状态。

A、出现下图信息,远端可用与近端可用即表示Tunnel是连通的。

B、如出现下图信息:初始化状态,表示Tunnel不通。可检查。

C、修改有问题的Tunnel参数:检测方式为人工、检测报文类型为FF

D、检测报文周期3.3。

D、选中Tunnel右击。在弹出的菜单中如图查询。

E、即可获取LSP状态、LSP缺陷类型、LSP缺陷位置信息,返回到对应站点检查配置出错的地方。

一、创建以太网专线业务:

1、在主视图路径下创建以太网专线业务。

2、创建业务时业务名称需修改,其他默认。选择源宿网元、端口、VLAN值。单击下一步。

了。

4、上下行标签的修改:选择自动分配标签,如下图。其他各参数都是默认。单击高级按钮、

5、在高级选项卡里各参数设置为“无”(各地区的要求不同)。点击确定、应用、完成就ok。

三、业务验证

1、在主视图路径下选择L2VPN业务管理,显示如下图的选项卡,填写业务ID,单击过滤即可。

的业务流量。然后单击‘开始’或‘复位开始’。

3、以下是业务流量截图分别用户侧和网络侧业务流量。这是业务正常的情形。

4、以下是用户侧物理端口的流量截图。是业务正常的情形。

5、业务不正常的情况:以下是有发送没有接受的情形;也有只有接受没有发送的情况。

如果有发送没有接受报文说明用户侧业务不通网络侧是通的;如果有接受没有发送报文则说

明网络侧业务不通用户侧是通的;如果显示网络侧或者用户侧‘查询为空,错误代码:46587’表,明业务为配置。如下截图:

6、常见的影响业务的告警信息:

ETH_LOS: 以太网端口连接丢失告警

(1)端口已使能但端口的网线或光纤没有连接好;

(2)网线或光纤故障;

(3)对端发送部分故障;

(4)本端接收部分故障。

MPLS_Eunnel_LOCV: Tunnel连通性丢失告警

1、物理链路故障;

2、网络出现严重的拥塞;

3、对端设备故障;

ETH_LINKK_DOWN: 网口连接故障告警

1、本端网元和对端网元的端口工作模式不一致,造成协商失败。

2、端口内环回。

3、单板故障

ETH_APS_SWITCH_FAIL: 表示保护倒换失败告警

原因:APS保护组两端配置不一致

ETH_APS_LOST : 告警表示APS帧丢失

1、对端网元未配置APS保护。

2、APS保护组两端配置不一致。

3、APS保护组状态未激活。

4、保护通道业务中断。

软件配置管理流程

配置管理流程规定 (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)配置库的日常操作和维护 开发人员

中国移动集客业务IT支撑手段需求规范-功能需求总册(2017版)

中国移动集客业务IT支撑手段需求规范 ——功能需求总册 (2017版) 中国移动通信有限公司网络部 2017年6月

目录 前言 (3) 1.综述 (3) 2.整体规划 (3) 2.1总体目标 (4) 2.2建设思路 (4) 3.资源数据相关功能需求 (5) 3.1预覆盖信息管理功能 (5) 3.2业务及客户信息管理功能 (6) 4.售前支撑相关功能需求 (6) 4.1资源查询管理功能 (7) 4.2需求勘察管理功能 (7) 4.3售前方案生成功能 (7) 5.售中开通相关功能需求 (7) 5.1项目总览功能 (8) 5.2进度管控功能 (8) 5.3业务开通、变更(调整)、停复机、拆机功能 (8) 5.4资源、业务数据自动分配和激活 (9) 5.5告警验证及交维验收管理 (9) 6.售后保障相关功能需求 (9) 6.1告警监控功能 (10) 6.2投诉处理功能 (10) 6.3割接管理功能 (11) 6.4重点保障功能 (11) 7质量管理相关功能需求 (11) 7.1集客业务性能监控功能 (12) 7.2集客业务质量拨测功能 (12) 7.3业务质量统计和呈现 (12) 8.综合呈现相关功能需求 (13) 8.1集客业务综合呈现功能 (14) 8.2信息报送和客户服务 (15) 9.基础管理 (15) 9.1机构管理 (15) 9.2账号管理 (15) 9.3权限管理 (15) 9.4视图管理 (15) 10.与集团规划的对应关系 (16)

前言 李跃总裁在2016年总经理研讨会上提出“要加快深耕集客市场,进一步 做大收入规模,今年实现集团通信及信息化收入份额的“三分天下有其一”, 并向集客市场收入份额第一的主导运营商努力。” 集客经营已成为驱动收入增长的“三驾马车”之一,要举全集团之力, 着力提升产品、资源和支撑能力,大力持续拓展集客市场,从流程、资源、 质量三方面全力推进以集团客户SLA为中心,政企业务对内一体化支撑、对 外一体化呈现的一站式服务支撑体系建设。 为提升集客运维效率,丰富支撑手段,总部汇总梳理了集客业务IT支撑手段功能需求规范,为总部及各省公司集客业务IT支撑手段的建设和完善提供参考指引 1.综述 集客业务IT支撑手段,应满足集客业务售前、售中、售后全流程覆盖的管理需求,满足集客业务不同组网方式和业务流程端到端的管理需求,满足面向管理应用和面向生产应用的需求,实现集客业务支撑、网络运维和客户服务的IT 化和流程化。 该总册从整体视角,对集客业务IT支撑的各类功能进行概况描述,包括集客资源相关功能、售前售中流程相关功能、售后保障相关功能、质量管理相关功能、综合呈现一体化支撑相关功能。 分册从全生命周期视角,根据功能特点和使用对象,对集客资源、售前流程、售中流程、售后保障、质量管理、综合呈现等相关需求以分册形式进行展开描述,主要包括具体功能点、功能描述及实现原理。 2.整体规划 根据2017年网络工作会的部署,集客支撑工作要持续对标主要竞争对手,以流程、资源、质量三条主线为抓手,以支撑手段“全覆盖”为载体,继续进行体系优化和能力提升工作,实现集客业务“开通快、质量好、服务优”的目标。

软件配置管理过程指导说明书(超级实用)

软件配置管理过程指导说明书

目录 1 前言 (2) 1.1 目的 (2) 1.2 适用范围 (2) 1.3 术语名词解释 (2) 2 角色和职责说明 (3) 3 输入 (4) 4 入口准则 (4) 5 配置管理实施 (4) 5.1 配置库结构 (4) 5.1.1 配置库 (4) 5.1.2 配置管理库系统 (6) 5.2 配置管理流程 (6) 5.2.1 配置管理流程图 (6) 5.2.2 配置变更流程图 (7) 5.3 配置标识 (8) 5.3.1 配置库划分 (8) 5.3.2 配置库结构 (8) 5.3.3 配置项命名 (11) 5.3.4 版本编号规范 (11) 5.4 配置管理活动 (12) 5.4.1 制定配置管理计划 (12) 5.4.2 建立配置库 (12) 5.4.3 建立配置项 (12) 5.4.4 基线建立及发布过程 (12) 5.4.5 配置变更 (13) 5.4.6 配置审计 (15) 5.4.7 备份 (16) 6 输出 (16) 7 出口准则 (16) 8 本过程裁剪规定 (16)

1 前言 1.1 目的 用于描述配置管理作用和过程,规范配置管理的实施过程、活动和操作。 1.2 适用范围 适用于在软件生命周期中对各类软件项目的配置管理活动。 1.3 术语名词解释 CCB:Configuration Control Board,配置管理委员会,每个项目组需要建立项目级的CCB作为变更控制权威。CCB由质量工程师、项目经理、测试经理、配置管理员构成,有时也可以包括客户代表、上级质量部门主管。CCB组长可以是质量工程师或质量部领导,但不能是项目经理。 软件配置项:是指软件工程过程中所生产或使用的任何元素,或者是纳入软件产品的元素。它可以是说明书、计算机程序、数据结构或者开发软件产品所使用的工具等,包括:项目文档,源代码,执行程序,相关设备及资料。 软件配置管理:对软件配置项的管理称为软件配置管理。软件配置管理的目的是建立和维护软件项目整个生命周期中工作产品的完整性和可追溯性。 软件工作产品:由定义、维护和使用一个软件过程所产生的任何人工制品,包括过程描述、计划、规程、计算机程序和相关文档,无论是否打算将它们交给客户或最终用户。 软件产品:可交付给客户或最终用户的软件工作产品的子集称作软件产品 基线:基线,是开发过程中标识出的里程碑所交付的一个或多个配置项,也即指一个(或一组)配置项在项目生命周期的不同时间点上通过正式评审而进入正式受控的一种状态它有如下特征:(1)已经过正式的评审和批准;(2)作为项目发展和产品升级的基础。(3)基线变更必须经过CCB审批。 变更控制:对配置项的更改进行评价、协调、认可或不认可以及执行更改的过程。 版本发布:指从项目的配置库中将需交付给客户的所有配置项组装成一个完整的软件产品。即交付给客户的一个包括可执行程序和文档的发布基线称为发布(release)。 配置审计:可以分为物理审计和功能审计。物理审计审查配置项的外在特征的正确性与一致性,主要考查软件受控库的结构、内容及其它相关信息,以验证基线和描述它的文档的一致性;功能审计审查配置项内容的正确性与一致性,主要考核配置项在实现功能上的一致性,功能审计主要通过评审和测试报告体现。 物理审计的内容包括: ? 确认配置项标识的正确性; ? 确认已受控配置项的更改是受到控制的; ? 验证配置库内容与相应记录之间的一致性; ? 验证配置管理活动与相应记录之间的一致性; ? 验证配置管理工作是否符合适用的标准和规程; ? 验证配置管理系统与系统备份的有效性、一致性等。 功能审计的内容包括: ? 验证当前基线所含配置项对前一基线所含配置项的追溯性; ? 确认当前基线所含配置项均正确反映了项目需求; ? 评估基线的完整性; ? 验证当前基线和各基线间所含配置项的一致性; 验证配置库内容的完备性和正确性等。

配置管理流程

配置管理流程 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配置管理范围工具、用途说明:

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

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

配置管理岗位职责

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

石料生产线流程及设备配置

一、石料生产线介绍 易普泰克生产的全套石料生产线设备,为您提供全面的技术支持,该石料生产线主要由振动给料机、颚式破碎机、反击式破碎机、振动筛、皮带输送机、集中电控等设备组成;设计产量一般为50-500吨/小时。为满足客户不同的加工需要,可配备圆锥式破碎机、除尘设备等。可用于硬质石灰石、花岗石、玄武岩、河卵石、冶金渣等多种物料的骨料及人工造砂作业,适用于水电、建材、高速公路、城市建设等行业的应用。根据不同的工艺要求,各种型号的设备进行组合,满足客户的不同工艺要求。 二、石料生产线流程 石料生产线设备工作原理是大块石料经料仓由振动给料机均匀地送进颚式破碎机进行粗碎,粗碎后的石料由皮带输送机送到反击式破碎机进行进一步破碎;细碎后的石料由皮带输送机送进振动筛进行筛分,筛分出几种不同规格的石子,满足粒度要求的石子由成品皮带输送机送往成品料堆;不满足粒度要求的石子由皮带输送机返料送到反击式破碎机进行再次破碎,形成闭路多次循环。成品粒度可按照用户的需求进行组合和分级,为保护环境,可配备辅助的除尘设备。 三、石料生产线优势 该石料生产线自动化程度高,成套生产线除了对设备的开机停机及日常维护之外,几乎不需要人工操作。其生产效率高,运行成本低,产量大,收益高,成品石子粒度均匀、粒形好,符合国家高速用料要求。 易普泰克生产设计的破碎筛分联合设备在工艺流程的设计中,由于各级破碎设备匹配合理,以及严谨的空间交叉布局,因此它具有占地面积小,投资经济效益高,碎石料品质好,石粉产出率低等的特点为,同时配有先进的电控操作系统,确保了整个流程出料通畅,运行可靠,操作方便,高效节能。 石料生产线的设备配置主要依据客户对石料规格以及产量和石料的用途来确定,我们提供售前、售中、售后的全面服务,依据客户生产现场来配置流程,力求为客户做到最合理、最经济的生产线。 四、石料生产线设备组成及其特点 振动给料机直线振动式给料机,具有振动平衡、工作可靠、寿命长等特点,可为破碎机械连续,均匀喂料,并对物料进行粗筛分. 颚式破碎机分为粗碎颚式破碎机和细碎颚式破碎机,是生产选矿的第一道工序,可以把大小不一的原料破碎成颗粒均匀的小块,以便于下道工序用,本机也可用以生产路基石以及建筑用石子骨料。 反击式破碎机本系列破碎机能处理边长100~500毫米以下物料,其抗压强最高可达350兆帕,具有破碎比大,破碎后物料呈立方体颗粒等优点。 振动筛圆振动筛引进德国技术制造的高效振动筛。适宜采石场筛分砂石料,也可供选煤、选矿、建材、电力及化工等行业作产品分级用。 圆振动筛工作特点:用块偏心作为激振力,激振力强。 筛子横梁与筛箱采用高强度螺栓,结构简单,维修方便快捷; 采用轮胎联轴器,柔性连接,运转平稳; 采用小振幅,高频率,大倾角结构,使该机筛分效率高、处理最大、寿命长、电耗低、噪音小。

软件配置管理控制程序A0

程序文件 软件配置管理控制程序 文件编号 版木A0 贞数第1贞共6贞 編制部门研发部 生效日期2018年09月05日 修改页 文件编号修改条款修改内容修改人/日期生效日期全文首次发行 分发部门会签 编制审核批准□业务部□研发部□采购部□生产韶□质量部□行政部

软件配置管理控制程序 软件配這皆理贯穿于软件整个生命周期,对规范软件版本、源代码、文件、工具、现成软件等控 制要求,确世配置标识、变更控制、配置状态记录等活动要求。使用配置管理工具保证软件质量使公 司的所有软件开发项目的软件配置管理活动都能按照统一的要求进行。 适用于本公司所有的软件项目,并贯穿于软件生存周期全过程。 3.1项目经理 负责指过配置管理人员: 负责审批配置管理il ?划; 负责执行配置管理il 划。 3. 3质量部 > 负责跟踪配置管理il ?划的实施。 4.1术语泄义 软件配置管理:是标识和确定系统中配置项的过程,在系统整个生存周期内控制这些项的投放和变更, 记录并报告配置的状态和变更要求,验证配置项的完整性和正确性。 软件配置项:为配置管理的目的而作为一个单元来看待的硬件/软件成分。 基线:一组拥有唯一标识号的需求、设计、源代码文件以及柑应的可执行代码、构造文卷和用户文档 构成一条基线。基线一经放行,就可以作为从配置管理系统检索源代码文卷(配苣项〉和生成可执行 文卷的工具" 4.2配置管理讣划编制 所有项目在指;4^项目开发计划时,都应有项目经理指定配置管理人员,然后由配置管理人员编写 《配置管理计划》,也可以包含在《软件开发计划中》,配置管理讣划至少应包括的内容: ? 配置管理人员的组成及分工 2. 范围 3. 职责 3.2 配置管理人员 4. 工作程序

全业务支撑体系建设

建立面向全业务端到端支撑体系 随着全业务市场竞争的日益激烈,公司已逐步向全业务运营拓 展。为了尽快满足日益增强的全业务支撑服务保障需求,进一步提升网络对市场的服务支撑能力,完善全业务端到端支撑体系。 网络部全业务室对外作为全业务支撑的统一接口,对内作为网络部支撑工作枢纽,协调相关部室,负责集团客户网络的业务接入传输和客户端设备的维护工作;负责合同约定范围内的客户端其他设备的维护工作,配合客户做好我公司责任范围之外设备的维护工作。负责PON (驻地网)网络维护工作。负责WLAN 网络维护工作。

第一章集团信息化支撑体系建设 一、集团信息化网络支撑 随着集团信息化业务的快速发展,集团信息化支撑的建设越来越重要。集客维护支撑工作较原有维护工作,在工作范畴、工作内容、工作要求均有不同的特点,首先需要跨多专业维护管理,交换+数据+传输+ 庞杂的接入/客户侧技术等。其次需要进行售前勘查、售中开通、售 后保障的全生命周期管理,最后需要对不同级别的客户、不同的业务,有不同的操作要求、操作规范,体现面向客户的差异化管理。 1、集客支撑工作内容 1)组织协调为集团客户部门提供售前、售中、售后的全程技术支持,落实相关资源调配。重点提供售前技术支撑、网络资源核查、协调业务开通、故障处理和通信保障等服务。 2)为集团客户提供差异化网络服务。在既有网络服务的基础上,为不同需求的客户提供不同的网络质量和服务质量的差异化网络服务。

3)整合网络能力和维护能力,挖掘网络服务内容,最大限度地发挥网络运行效率和经济效益。 4)制订集团客户网络服务工作规范和流程,建立健全集团客户网络服务工作体系。 5)整合完善客户网络服务支撑手段。加强客户网管、故障单管理、代维管理等支撑系统建设提高资源核查、业务开通及服务保障能力,满足客户端到端、差异化的服务需求。 2、各部门(室)相关职责 集团客户部: 1)负责集团客户需求的确认及客户售前相关协调工作。负责集团客户业务变更申请及客户售中相关协调工作。 2)负责集团客户售后维系工作,配合网络部进行相关网络调整、网络割接等客户解释工作。 工程建设中心: 1)负责现场勘查、接入点选择,配合前期方案制定等工作。 2)负责整个集团信息化的施工管理。 3)组织集团信息化业务整改等工作。 全业务支撑室:1)配合集团客户部,牵头组织各专业室进行集团信息化解决方案的制定、参与现场需求调查,参加项目建设的随工和验收。牵头解决集团客户网络维护中涉及各专业和各部门的问题。 2)负责集团客户网络本地资源的核查、协调业务开通及其他售中服务支撑,协助完成集团客户项目实施过程中的项目管理工作。

集客业务“流程式”快速开通优化方案及落地手册

集客业务“流程式”快速开通优化方案及落地手册 (版本 V1.0) 中国移动通信集团公司网络部 二零一七年六月

一、项目背景 集客业务开通普遍采用一单一议的“项目式”的开通方式,每个客户每项业务均需按照先勘察后开通的方式实施。“项目式”开通方式存在环节多、流程长等问题,以某省为例,省内集团专线开通平均时长超15天(未剔除客户及物业入场等因素),影响开通效率、降低客户体验。 现有集团专线(含双跨与本地)的开通流程环节中,由于网络资源信息的与客户之间缺乏关联,导致开通过程存在以下几点痛点: 1、必须勘:网络资源状态与前端客户信息缺乏关联,使得售前支撑阶段必须经过勘察环节。 2、现场勘、勘察长:资源信息的准确性使得必须开展现场勘察,勘察周期长。 3、建设长:资源状态的非实时使得每次开通都得走工程建设流程,开通环节及周期长。 二、优化思路与关键节点 集客专线业务开通参照家庭宽带“装机快开”模式,通过引入集团客户(楼宇)标准化地址,建立“资源-标准地址-客户”的关联模型,将预覆盖资源信息向前台推送,从业务受理时即可判断客户预覆盖情况,建立“流程式”开通模式,按需勘察、建设,解决开通“必须勘、现场勘、勘察长”的问题,推动业务开通从“项目式”向“流程式”转变,提升开通效率。 具体关键控制点如下:

1、引入标准地址:通过引入集团客户(楼宇)标准化地址,建立“资源-标准地址-客户”的关联模型,首先参照家客建立集客的标准地址库,然后将标准地址与资源关联,明确客户所在地的网络资源,根据预覆盖定义,呈现客户的资源覆盖结果(厚、薄、无)及资源可用情况,有效支撑政企业务发展。具体举措要求见总部重点工作《集客标准化地址管理优化方案及落地手册》。 2、资源信息前推:通过标准化地址将预覆盖资源信息向前台推送,从业务受理时即可判断客户预覆盖情况,从而节省售前勘察环节。 3、快速开通流程:通过开通工单上标准地址的资源状态,判断专线是否有覆盖,对于无覆盖(或者无标准地址)的工单,则继续传统较长的建设开通过程;但是对于有覆盖的工单,则可以走类似家宽开通的快速开通流程,使得专线开通从“项目式”向“流程式”转变,大大缩短专线开通时长。 三、项目落地实施步骤及要求 (一)建立集客标准化地址模型 要实现“流程式”的专线开通,首先需引入集团客户(楼宇)标准化地址,建立“资源-标准地址-客户”的关联模型,从而实现客户资源状态的实时呈现。该部分的具体方案已另行项目落实,具体举措要求见总部重点工作《集客标准化地址管理优化方案及落地手册》。 (二)“流程式”流程优化方案 引入标准地址库后,为实现客户网络资源覆盖状态推向前端成为可能,也为实现流程式快速开通提供了基础。

软件配置管理流程

软件配置管理流程

目录 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 配置审计 (7) 1.9.1 配置审核的类别 (7) 1.9.2 配置审核执行的时机 (7) 1.9.3 不符合项的处理 (7) 2.0.0 配置状态报告 (7) 2.0.1 配置状态报告的目的 (7) 2.0.2 配置状态报告记录的内容 (7) 2.0.3 配置状态报告的生成 (7) 2.1.0 发行管理 (8) 2.1.1 交付管理 (8) 2.1.1 软件配置管理员的处理规范 (8) 2.1.1.1 现阶段使用的版本配置服务器 (8) 2.1.1.2 主要操作流程 (8) 2.1.1.3 版本规范化处理 (8) 2.1.1.4 客户反馈问题处理 (8) 2.软件基线化规范 (9) 2.1 正常开发期 (9) 2.2 版本发布期 (9) 2.3 项目发布期 (9) 2.4 项目维护期 (9)

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

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

软件配置管理控制程序

配置管理控制程序 历史记录

目录

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) 在配置管理系统中, 基线就是一个配置项或一组配置项在其生命周期的不同时间点上经过正式评审而进入正式受控的一种状态这些配置项构成了一个相对稳定的逻辑实体, 而这个过程被称为基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素( 配置项) 的一个版本, 且只确定一个版本。一般情况下, 基线一般在指定的里程碑处创立, 并与项目中的里程碑保持同步。每个基线都将接受配置管理的严格控制, 基线中的配置项被冻结”了, 不能再

配置管理过程

配置管理过程 版本: 发布时间: 文件变更记录

目的 本文档描述了软件开发项目的标准软件配置管理过程。该过程向软件开发项目中与配置管理有关的人员提供说明和行动指南,使开发人员、测试人员、项目管理者、质量保证人员以及客户能方便地通过软件配置管理获得有用的信息。 适用范围 机构:质量部、产品部、开发部 业务:软件项目的配置管理活动。 概述 本过程包括建立配置库设置访问权限、组建CCB、制定配置管理计划、发布基线、基线变更管理、配置状态记录、配置审计、备份配置库、产品发布、移交项目资产入资产库十个子过程。 本过程是描述项目如何计划配置管理活动,并在整个软件的生命周期中如何执行配置管理活动的。软件配置管理是CMMI的一个重要组成部分,其目在于建立和维护在项目的整个生命周期内软件项目产品的完整性。 名词术语 基线:已经通过正式的同级评审而获得认可,可以作为一个基本纲领为今后工作服务并且只能通过正式的变更控制过程才可改变的一个或多个软件配置项。 定义基线:在项目策划过程中,对基线的个数、时间和条件,以及包含工作产品的定义。 建立基线:根据项目计划中的定义,在实施过程中,经由评审组评审和软件配置控制委员会批准,建立起来的由特定工作产品组成的基线。 配置项:由配置管理视为一个单一整体而进行处理的工作产品(例如:在软件生存周期各阶段所产生的各种形式和各种版本的文档、程序、数据等)以及完成工作产品所需的软件工具和支持系统。 软件配置控制委员会:ConfigurationControlBoard,简称CCB,负责评价和批准(或不批准)建立基线,评价和批准(或不批准)对基线化配置项所提出的变更,并负责保证那些已批准的变更能得到实施的组。 物理配置审计:Physicalauditsauthenticate,简称PCA,审计软件产品的完整性,以确保其包含全部应有的元素、文档与数据。 功能配置审计:Functionalconfigurationaudit,简称FCA,审计软件产品的正确性,以确保其性能和基线化的需求相一致。 流程图 过程定义

如何制定配置管理流程

如何制定配置管理流程 【IT168 技术文章】 以下是我们在实际工作中遇到的一个例子,这个例子充分说明了正确的工作流程对于保证软件产品质量的重要意义。 1. 问题描述 某一开发团队为其客户开发业务软件,系统上线之后存在着很多的业务需求变更,同时也有很多业务部门在使用过程中所发现的软件缺陷,我们把需求变更和软件缺陷统称为变更。开发团队需要迅速响应客户所提出变更请求,把相应的软件版本修复及时地安装到生产系统上去。 为了保证产品质量,该开发团队建立了以下的软件发布流程: 图1 这四个环节分别对应以下四种环境: 开发环境:开发实现客户的变更请求 测试平台:开发团队把软件发布给客户之前做内部系统测试 准生产环境:客户把软件发布到生产系统之前做验收测试 生产系统:最终的生产系统 当开发团队将变更实现提交用户验收测试时,凡是没有通过验收测试的变更将被拒绝,只有通过验收测试的变更才会被部署到生产系统上去。整个流程如下图所示,假设开发团队总共实现了3个变更,其中变更1和变更2通过了系统测试被提交用户验收测试,但只有变更1通过了用户验收测试,最终只有变更1被部署到生产系统上。 3. 改进建议 为了避免以上所述的这些质量陷阱,我们应该改进现有的配置管理流程。 (1)建立闭环的质量保证流程 造成以上质量隐患的根本原因是系统代码没有被作为一个整体来处理,并且在发布过程中我们发布的是源代码,正确的流程(也是业界较为通行的做法)应该发布构建后的目标码而非源代码。我们可以建立一个闭环的质量保证流程(如下图所示)来批量地进行软件发布。

图6 其中系统测试过程中发现的缺陷应该被开发人员及时改正,然后再做构建,再测试,直到达到一个比较稳定的版本才会发布到验收测试环节。同样的,验收测试中发现的问题也会回到开发环节进行修复。这应该是一个多次循环的过程,不断地发现错误,然后改正,再测试。这个循环到什么时候结束呢?这个取决于各个软件项目的实际情况: 最理想的情况当然是到所有的缺陷都被改正为止,但是所花的时间比较长,可能赶不上项目的进度要求,现实工作不大可能做到这一点。 折衷的情况是所有严重的缺陷(即那些影响系统使用的的缺陷)都必须被改正,但允许有一些已发现的缺陷遗留到后面再去解决,前提是所遗留的缺陷不会影响其他变更的实现。大家平时在一些商用软件的新版本中经常可以见到发布说明(Release Notes)中所列的已知缺陷(Known Defects)就是属于这种情况。 我们向开发团队提出这个建议后,马上遭到项目经理的反对:“客户有些紧急的变更需要马上实现并交付生产运营,几乎没有时间来走这样完整的闭环流程。” (2)区别对待缺陷和新增功能 通过进一步了解我们发现紧急的变更一般是指影响系统正常使用的软件缺陷,这些缺陷需要及时的修复;而新增功能请求一般不是那么紧急的,允许开发团队有一段时间来开发实现。但开发人员目前是把所有紧急和非紧急的变更请求混杂在一起实现的,往往是一个紧急的缺陷已经修复,但另外一个正在开发中的新增功能也修改了同一组文件版本,造成两者之间的版本依赖,从而导致紧急的缺陷修复不能按时提交。 我们建议把缺陷的修复工作和新增功能的开发工作区分开来,这就涉及到多个版本的并行开发,开发团队主要面临以下三个版本的开发: v1.0中的缺陷修复 v1.0的新增功能版本v1.1 下一个版本v2.0 这样缺陷修复和新增功能开发相互独立,保证紧急的缺陷修复不会受到新增功能的影响。

业务支撑架构设计文档

业务支撑系统架构设计文档

文档创建信息 文档修订记录 修改类型分为A– ADDED(增加)M– MODIFIED(修改)D– DELETED(删除)

目录 1引言 (4) 1.1编写目的 (4) 1.2背景 (4) 2系统架构设计 (4) 2.1系统概述 (4) 2.2设计约束 (9) 2.2.1 标准与规范 (9) 2.2.2 开发、运行环境 (9) 2.2.2.1 开发环境 (9) 2.2.2.2 运行环境 (9) 2.2.2.3 软件平台 (9) 2.2.2.4 硬件平台 (10) 2.3体系架构 (10) 2.3.1 技术框架 (10) 2.3.2 代码组织结构 (12) 2.3.3 配置文件组织结构 (13) 2.3.4 开发原则:数据与功能分离原则: (13) 2.3.5 关键技术点 (13) 2.3.6 技术难点与风险、预研成果概述 (15) 2.4子系统划分及说明 (15) 3附录 (15) 3.1本系统用到的缩写词、定义和术语 (15) 3.2参考资料 (15)

1引言 1.1编写目的 本文主要根据需求规格说明书,对业务支撑系统(以下简称BSS)进行的架构设计,并为bss的详细设计提供依据,同时为开发人员在开发过程中提供开发基础。 预期的读者:需求设计人员,产品相关负责人,详细设计人员,开发人员,质量管理人员,系统集成部署人员。 1.2背景 2系统架构设计 2.1系统概述 整个业务支撑系统由客户关系管理(CRM),计费(BILLING),商业智能(BI),合作伙伴管理(PRM),生产管理(IOM)五部分组成。采用统一的数据视图。

软件配置管理规范流程

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.无线网优中心负责WLAN AP部分维护职责。 2.设备维护中心负责AC部分和CMNET数据网维护职责。 3.网络服务中心负责所有类型集团客户专线(包括互联网专线、传输专线、语音专线、短彩信专线、APN专线、无线城市相关专线、平安城市相关专线、信息岛专线等)、IMS接入侧、地市层面放置在移动机房内业务平台的维护。 4.网络服务中心与传输维护中心分工界面 (1)传输接入类设备维护界面 网络服务中心负责维护: 基站或综合业务接入点机房内用于集团接入的语音、数据和传输设备及其间的连接线。 集团客户侧移动自主产权的传输、数据、语音设备和之间的连线。 (2)与传输外线专业界面划分 基站或综合接入点中,传输类设备下行端口至集团用户侧传输设备上行端口间的线路以光缆线路进入机房第一个ODF端子为界,端子以外部分由传输维护中心维护。 (3)与传输设备专业界面划分 基站或综合接入点内集客基站侧设备和传输设备之间以到传输设备的下行端口为分界点,下行端口以下的连线及设备归网络服务中

心维护。 (二)网络服务中心与集团客户部界面划分 1.客户侧应用终端类设备维护界面 以客户侧设备到客户端设备的第一个端口为界,端口以上连线及客户侧设备归网络服务中心维护,端口以下设备归客户自行维护或集团客户部维护。 2.与客户签订的延伸服务界定的设备和连线,如用户内部综合布线、电源、路由器、交换机、视频终端等,由集团客户部维护。 注1:网络部客户侧与集团客户客户端定义 客户端设备:在客户机房内用于实现客户专线业务的用户自有设备,包括路由器、交换机等组成用户业务平台的用户网络设备。客户端设备主要用于用户自己的业务网络平台,由用户进行设备选型、系统建设和维护。 客户侧设备:位于客户端和接入网交接处的设备,处于接入网末端,向上将业务上传至城域传送网接入节点,向下通过客户接口连接客户端设备。客户侧设备一般由运营商提供,安装在客户机房,根据不同的专线用户,客户侧设备包括数据业务设备,如移动自主产权的交换机、路由器、防火墙等;语音业务设备,如移动自主产权的PBX、IAD等设备;客户侧设备归移动公司网络部网络服务中心维护。 注2:关于ICT类项目 按照集团客户部ICT项目划分分类原则,可以将ICT项目分为五类:一卡通类、MAS类、工作手机类、行业平台类、其他系统集成类。

相关文档
最新文档