NGOSS系统架构认识

整理文档很辛苦,赏杯茶钱您下走!

免费阅读已结束,点击下载阅读编辑剩下 ...

阅读已结束,您可以下载文档离线阅读编辑

资源描述

NGOSS系统架构认识诸如B2B、B2C、C2C、电子支付这样提供Sa;系统的业务架构和技术架构能支撑动态变化和管理动态;方法论提供的不仅仅是开发过程和辅助工具的集合,更;1、SANRR方法论;NGOSS方法论支持过程迭代,过程迭代即包括4个;它包括五个实现步骤:;1.定义范围(Scope):通过对当前环境的描述;现的业务和功能的范围、边界;2.分析(Analyze):分析新增业诸如B2B、B2C、C2C、电子支付这样提供SaaS的电子商务运营商所提供的电子商务系统与电信运营商的BSS/OSS类似,都为运营性系统。所谓的运营性系统是指通过软件系统持续的建设和运营为客户(主要为外部客户)提供服务。运营过程的集成性、实时性和动态性、敏捷性,要求运营商的支撑系统必须能支撑动态变化的需求和在线实时管理变化的要求,要求支撑系统的业务业务架构和技术架构能支撑新的业务模式引进和局部功能模块重构的需要,保证新的运营支撑系统的业务架构和技术架构能支撑动态变化和管理动态变化。怎样让支撑系统能够这些需求相匹配呢?方法论提供的不仅仅是开发过程和辅助工具的集合,更是一种思想。将这些思想运用到具体的开发实践中,会极大地提高电子商务系统的开发效率和质量。1、SANRR方法论NGOSS方法论支持过程迭代,过程迭代即包括4个阶段的整体循回演进,也包括每个阶段自身的不断演进,这一方法被缩写为SANRR方法。它包括五个实现步骤:1.定义范围(Scope):通过对当前环境的描述和实现目标的设定,明确定义系统演进需实现的业务和功能的范围、边界。2.分析(Analyze):分析新增业务或功能与原有业务或功能的关系,并用模型化语言对新增业务或功能加以定义和描述。3.规格化(Normalize):分析新增业务或功能对原有业务流程、功能模型、信息模型、业务规则等的影响,将新增部分加入到原有模型中,形成一个统一的新模型。4.合理化(Rationalize):通过检查和验证,进行差异分析、冲突分析和冗余分析,列出和标明出现的问题。5.纠正(Rectify):针对上个步骤列出的问题,对产生问题的模型进行修改,重复4)和5)直到全部完成。NGOSS方法论不是重新创建的一套全新的方法,而是当今软件领域各类知识有机融合的产物,反映了当前一些最新的软件工程思想,因此,有些方法还在不断发展中,并未成熟。同时,NGOSS方法论中提出的一些方法还需要相应的可操作性的模板和工具的支持。因此,在方法论的应用上,首先要遵循的原则是充分领悟方法论所包含的思想原则、工作方法。只有在深刻领会其思想原则的基础上,才能有效利用市场上一些成熟的工具,协助电子商务系统的开发和建设。其次是不断积累相关知识,包括各种在电子商务系统开发过程中产生的中间结果和元素,为需求的不断改变和扩充提供可重用的组件,缩短业务部署和提供的时间,真正做到适应市场的变化。2、NGOSS架构视角该模型提供了从两类NGOSS应用者看系统的视角,一类是业务提供者的视角,一类是系统开发者的视角。两类应用者又分别从逻辑的和物理的两个层面看系统。逻辑层面关注解决方案中技术无关内容的定义,如业务流程、业务规则、信息模型等。物理层面关注解决方案中技术相关内容的定义和具体实施,如具体实现技术选择,COTS产品选择,运行方案等。这样构成了四个视角,分别是业务视角、系统视角、实现视角和部署视角。oNGOSS业务视角:在这一阶段,要明确系统的业务目标、范围和职责。利用eTOM和SID描述业务过程、业务实体、业务流程和业务规则,以适合管理环境和业务提供的需要。oNGOSS系统视角:在这一阶段,主要关注系统对象、对象行为和交互操作。利用eTOM、SID和TNA来建立功能模型、构件模型、流程模型和信息模型,明确对象间的信息交互,协调一致地支持业务过程的要求。oNGOSS实现视角:该视角主要关注如何利用硬件、软件和COTS,根据系统设计的要求具体实现一个特定的OSS系统。在这一阶段,要解决如何将技术中立规范中的设计转换为与技术相关的具体实现。oNGOSS部署视角:部署视角是从系统维护者的角度监控系统的执行,保证系统符合业务的需要;如果系统不满足需要,能够通过NGOSS的调整和控制机制,使其符合业务需求的变化。这些控制机制如基于过程管理中的流程定义,基于策略管理中的规则设置。oNGOSS知识库:NGOSS方法论提供了一种信息集中保存的机制,称为NGOSS知识库。NGOSS知识库中的信息来源于合作组和TMFNGOSS两个方面,包含三类知识:*现有的合作组织知识:包括软件业的已有成果,电信业的运营和业务知识*NGOSS知识:包括TMF定义的各种框架、模型、规则、技术方法等*共享知识:以上两类知识的通用部分。NGOSS的视角实际上来自于RUP用于描述系统架构的4+1视图模型:o逻辑视图(LogicalView):设计的对象模型(使用面向对象的设计方法时)。与ngoss的系统视角对应o开发视图(DevelopmentView):描述了在开发环境中软件的静态组织结构。与ngoss的实现视角对应。o进程视图(ProcessView):捕捉设计的并发和同步特征。ngoss没有直接单独为一个视图o物理视图(PhysicalView):描述了软件到硬件的映射,反映了分布式特性。与ngoss的部署视角对应。o用例视图(UseCases或Scenarios):描述业务需求及场景。与ngoss的业务视角对应。软件架构4+1视图模型3、eTOM业务分层模型eTOM所定义的三大流程区域:战略、基础设施和产品;运营;企业管理五大经济实体:(1)客户:企业通过销售产品向其提供服务的对象,是业务的焦点。(2)供应商:向企业提供所使用的产品或资源,直接或间接地支持企业的业务;合作伙伴,企业与其共同享有的业务区域的合作对象。(3)股东:为企业投资从而拥有企业的股份,SP从股东处获得财务资源。(4)雇员或员工:为企业工作,为企业追求和实现业务目标;SP获得雇员的服务来执行企业的流程。(5)其他企业利益相关者:不是以股票拥有者身份与企业签有协议或承诺,包括监管者、媒体、当地社团、政府、竞争对手等。层次结构分解对大量内容和细节进行组织的最好方法就是以多个层次或层面来构建信息,这样层面高的视图代表着概要视图,而且每一高级层面可以分解成更详细的低一级层面,即:层次结构分解。通过把eTOM划分成多级层面,使框架应用者可以参照eTOM不同的框架层面来安排其企业框架或流程实施,比如,根据第一级和第二级层面或根据第一、二、三级层面来安排。

1 / 4
下载文档,编辑使用

©2015-2020 m.777doc.com 三七文档.

备案号:鲁ICP备2024069028号-1 客服联系 QQ:2149211541

×
保存成功