求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
要资料
 
追随技术信仰

随时听讲座
每天看新闻
 
 
目录
第一部分:SEBoK介绍
SEBoK 简介
系统工程导论
SEBoK 用户和用途
第二部分:系统工程基础
系统基础
系统方法在工程系统中的应用
系统科学
系统思维
用模型表示系统
第三部分:系统工程与管理
系统工程 STEM 概述
基于模型的系统工程 (MBSE)
生命周期过程简介
生命周期模型
概念定义
系统定义
系统实现
系统实施
系统集成
系统验证-1
系统验证-2
系统部署和使用
系统部署
系统操作
系统维护
Logistics
系统工程管理
技术规划
评估和控制
决策管理
风险管理
配置管理
信息管理
质量管理
度量管理
业务和任务分析
业务和任务分析
系统工程标准
相关标准
系统工程标准的应用
系统工程标准的校准与比较
服务的生命周期管理
第四部分:系统工程的应用
产品系统工程
服务系统工程
企业系统工程
Systems_of_Systems(SOS)
医疗系统工程
第五部分:启用系统工程
支持业务和企业执行系统工程
支持团队执行系统工程
支持个人执行系统工程
第六部分:系统工程相关领域
系统工程和环境工程
系统工程和工业工程
系统工程与地理空间/大地测量工程
系统工程和项目管理
系统工程和软件工程
系统工程与质量属性
第七部分:系统工程实施实例
系统工程实施示例:信息系统
系统工程实施示例:防御系统
系统工程实施示例:交通系统
系统工程实施示例:医疗系统
系统工程实施示例:空间系统
系统工程实施示例:管理系统
系统工程实施 : 矩阵示例
第八部分:新兴的知识
新兴的主题
 
 
目录
服务系统工程阶段
译者:火龙果Alice
174 次浏览
 

本文描述了服务系统开发过程(SSDP)的各个阶段以及每个阶段的预期输出;为了与传统的系统工程(TSE)过程更紧密地结合,概念和可行性阶段已经被组合成一个单一的服务策略/概念,正如SEBoK系统工程和管理文章中讨论的那样。SSDP的所有阶段都采用类似的迭代方法来充分理解企业能力、企业过程影响、信息技术(IT),以及技术影响和客户期望。Lin和Hsieh(2011)很好地总结了新服务开发过程。信息技术基础设施图书馆(ITIL)阶段名称被特意添加到SSDP中,以显示IT和技术之间所需的一致性。读者应该记住,尽管IT对整个端到端系统至关重要,但在SSDP的所有阶段都必须考虑到服务技术开发需求。

服务策略/概念

服务策略/概念是进入SSDP的入口。这个概念可能由最终用户(企业客户或消费者)、业务经理、工程组织、新的web服务设计人员、新的技术发展和/或信息技术趋势产生。服务概念是服务理念的最高层次,它通常处理向哪些市场提出什么服务,以及这些市场中的哪些人提出什么服务。

然后,集成服务开发团队(ISDT)对该概念进行高级可行性评估,以评估对企业流程能力、运营能力和/或新技术开发(访问、基础设施、运营支持系统(OSS)、服务支持系统(SSS)和业务支持系统(BSS))的需求/影响。它还应该考虑对服务治理、社会、文化和人类行为的任何影响。可行性评估还对开发时间和开发成本给出了正负30%的估计,这是进入业务案例的入口点,可以评估在给定的约束和估计条件下,服务是否可行开发和推向市场。此时,一个决策(决策门)决定是否要开发服务。

如果业务用例是可行的,那么将开发服务的详细业务描述。这包括要包括的功能和特性、开发阶段、要解决的市场、目标市场中的客户以及期望从服务中获得的客户体验(即定义服务的非功能需求,如服务质量(QoS)、可用性、可靠性和安全考虑因素以及服务中的产品)。该描述允许对预期的人机交互、社交网络、技术需求和操作需求进行详细的研究。还应该包括治理和组织过程需求,以生成“服务描述”作为此阶段的主要输出。

服务系统工程(SSE)在理解和引出企业服务概念方面扮演着重要的角色。显然,理解预期服务所需的端到端业务流程是其成功开发、部署和客户满意度的基础。SSE与业务流程管理(BPM)、社会科学和认知科学合作,以引出预期的服务操作,包括目标受众、售前、销售和售后客户服务流程。

需求分析与工程

创建服务需求文档,描述服务功能、服务实体、实体之间预期的交互,以及支持服务所需的面向客户和面向内部的功能/流程。该描述应该在概念上包括预期的服务水平协议(sla)和服务提供者流程的义务,如果在服务操作期间存在任何程度的不合规。

除了前面描述的TSE活动之外,SSE需求分析和工程流程必须开发以客户为中心的服务视图,以分析SLA、QoS、价值共创、监控和评估需求,以符合预期/计划的SLA。此分析将确定在服务操作期间是否需要对服务进行动态更改,以纠正故障、重新配置、管理或适应/自适应可能的性能下降。

除了传统的服务生命周期管理(LCM)流程之外,还必须为服务水平管理(SLM)流程和系统开发需求。根据SLA,需要监控、度量和评估关键性能指标(kpi)、技术性能度量(TPMs)和服务性能度量(SPMs)。

SSE需求分析处理了对治理、业务、服务、操作和支持过程的支持系统,从而派生出对技术、信息系统、过程和企业组织的需求。接口需求、信息流和数据需求也在需求分析的范围内。主要输出是服务需求文档(SRD)。

SSE在描述日常操作的服务需求方面起着关键作用。这包括客户服务中心需求和网络基础设施提供商、内容提供商、服务提供商、基于服务的应用程序提供商以及服务的客户管理流程之间的接口。所有这些在服务操作计划(sop)和操作技术计划(OTPs)中都有详细描述。

系统设计/开发

SRD、SOP和OTP对于不同业务系统实体之间所需的业务功能、操作、接口和信息流有足够的细节,可以分析、识别和推荐端到端适用的架构框架;对服务系统实体之间的可选方案进行权衡分析;描述和分配服务体系结构各级实体之间的关系(交互)。详细的需求在较低的级别工作,为实体开发人员生成规范,包括数据结构、数据流图和分配的性能需求。

  1. 服务目录管理,
  2. 服务水平管理,
  3. 容量 管理,
  4. 可用性管理,
  5. 服务连续性管理,
  6. 安全管理,
  7. 供应商/供应商管理。

服务集成、验证和确认

SSE 定义了服务无缝运行的集成和接口要求。 在这方面,系统工程师扮演集成者的角色,以确保正确的数据生成并流经构成所提供服务的所有不同系统。 目标是确保客户(消费者或内部)获得执行业务、运营、服务和客户流程所需任务所需的信息。 服务集成、验证和确认计划需要包括端到端的验证和 确认程序,用于对先前测试的服务系统进行计划的动态配置/重新配置所需的任何新开发或调整。 (另见 系统验证。)

系统工程师使用许多不同的视角来创建这些计划。 这些包括:

  • 端到端服务(服务验证测试计划),
  • 客户服务(运营准备测试计划),
  • 服务提供商(网络验证测试计划),
  • 服务系统实体互操作性/接口测试计划,
  • 内容提供者(内容验证测试计划),
  • 应用程序(用户验收测试计划)。

服务转换/部署

服务系统可能会发生非常迅速的变化,并且可以添加新的增强功能、新功能或新应用程序作为增量开发、新开发或对服务产品的适应。 服务系统工程师审查新要求,以评估对服务系统实体、技术、流程和组织进行更改的可行性,以及它们对服务产品的影响。 服务转换/部署阶段从服务开发中获取输入,以计划服务插入、技术插入、流程调整和实施,同时对现有服务的影响最小。 在此阶段,将特别注意集成、验证和验证测试计划以及回归测试,以确保新开发与现有服务完美配合。

ITIL v. 3 (OGC 2007) 建议在过渡/部署阶段采用以下流程:

  • 过渡规划和支持,
  • 更换管理层,
  • 服务资产和配置管理,
  • 发布和部署管理,
  • 服务验证和测试,
  • 评估,
  • 知识管理。

服务运营/持续服务改进 (CSI)

服务运营管理向客户提供端到端服务的各个方面的日常活动。 它管理在指定服务级别内向客户提供合同服务所需的服务、技术和基础设施的运营、管理、维护和供应。 ITIL v. 3 中的主要服务运营流程是

  • 事件管理,
  • 事件管理,
  • 问题管理,
  • 请求履行,
  • 访问管理。

用于实施技术和工具的持续服务改进 (CSI) 计划以持续改进服务、监控、测量和分析流程和服务指标是必不可少的。

服务系统工程工具和技术

在 SSE 的不同阶段,广泛使用了来自广泛领域的工具和技术。 它们不仅用于硬件、软件、信息系统和技术组件的开发,还用于 服务系统的组织、流程和数据结构的建模、定义和设计 另请参见用模型表示系统 ) )。 这些工具和技术包括预期或将要设计的服务的建模、 模拟、开发、测试台和社会环境方面。 这些工具分为三个主要领域:

  1. 业务流程管理(BPM),
  2. 服务设计流程,
  3. 服务设计管理。

业务流程管理(BPM) 通常处理流程管理场景以协调人员和系统,包括顺序工作流、直通式处理、案例管理、内容生命周期管理、协同流程工作和价值链参与。 系统工程师与服务经理一起调整业务 架构 与技术和 IT 架构。 业务流程建模符号 (BPMN) 是一种图形符号标准,用于描述任何给定工作流中流程的实现。 此表示法与 Web 服务业务流程执行语言 (WS-BPEL) 相关联,WS-BPEL 是一种用于通过实现 Web 服务技术来执行自动化业务流程的格式。 有关现有 BPM 工具和 BPM 套件的广泛评论,请参阅 Hantry 等人。 (2010),卡罗尔等人。 (2010), Andrikoupolous 等人。 (2010)、Lin 和 Hsieh (2011) 以及 Ward-Dutton (2010)。

服务设计过程 :架构框架 (AF) 和企业架构 (EA) 是 有助于将复杂 系统(另请参见 复杂性)拆分为相互关联的结构化形式的 标准。 他们描述了 产品的不同特性和服务。 系统工程建模工具,例如统一建模语言 (UML) (OMG 2010a) 和系统建模语言 (SysML) (OMG 2010b),有助于开发 AF 和 EA,并极大地影响复杂项目的持续发展和成功实施。 面向服务的架构 (SOA) 和系统与软件工程架构 (ISO/IEC/IEEE 2011) 是将架构原则应用于专门应用程序的标准。 架构工具的成功实施有助于识别关键接口并提高对组件和功能之间分配的理解。

基于模型的系统工程 (MBSE)、模型驱动架构 (MDA) 和面向模型的系统工程 (MOSES) 是 IT 逻辑(功能)、行为(操作)和物理设计常用工具的示例。 UML、UML 2.0 和 SysML 广泛用于描述操作场景、操作模式、用例和实体关系。 有关 MBSE、MDA 和 MOSES 的广泛评论,请参阅 Friedenthal (1998)、Estefan (2008)、Pezuela (2005)、Andrikopoulos 等。 (2010 年)和海伯森(2010 年)。

此外,权衡和工程分析使用不同的优化方法。 由于服务表现出显着的随机性,因此统计分析、需求预测、多目标优化、排队论和随机优化方法是用于建模和模拟服务系统行为的工具。 这些方法支持资源分配、设施数量、设施地理位置、车队路由和优化、服务系统可靠性和预测以及网络优化等不同领域的决策。 Daskin (2010) 对这些方法进行了很好的概述。

在服务设计过程 (SDP) 中,执行用于持续改进服务的技术和工具的实施规划。 这些工具支持监控、测量和分析流程和服务性能指标。 戴明循环(计划、执行、检查和行动 (PDCA) 被广泛用作 整个服务 质量改进的基础。精益制造、六西格玛 、泳道、平衡计分板、基准测试和差距分析方法通常用于服务评估和持续改进。

服务设计管理 :实施和管理系统工程过程的标准(IEEE 1220 (1998))有助于协调和同步所有服务系统工程过程,从而改善组织协作和改进服务交付(另请参见 系统工程标准 )。 已在软件工程中为产品评估 (ISO/IEC 14598 (1998)) 和产品质量 (ISO/IEC 9126 系列 (2003a, 2003b, & 2004)) 以及信息安全管理 (ISO 27001 (2005)) 制定了标准) 和评估系列 (ISO 15408 (2008a, 2008b, & 2009))。 ITIL v. 3 描述了 IT 服务管理的最佳实践,可以扩展到包括服务系统。


您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码: 验证码,看不清楚?请点击刷新验证码 必填



174 次浏览
欢迎参加课程:
MBSE(基于模型的系统工程)
系统思维与系统工程
系统工程方法与实践