基于快速原型模型建立商业呼叫中心SPOMP的应用研究

摘要：本文从快速原型（Rapid Prototyping，RP）这一软件生命周期模型的原理出发，结合呼叫中心（Call Center，CC）软件项目外包的现状，提出应用快速原型模型于呼叫中心软件项目的外包管理，试图以软件工程的工程化和标准化思维来解决呼叫中心软件项目外包的问题。本文重点分析了呼叫中心软件项目外包现状，提出适合用快速原型来解决问题，并给出了应用快速原型模型建立呼叫中心软件项目外包管理平台（Software Project Outsourcing Management Platform，SPOMP）的方法集和工具集。

关键词：快速原型（Rapid Prototyping，RP），呼叫中心（Call Center，CC），软件项目外包管理平台（Software Project Outsourcing Management Platform，SPOMP）

总言

对于软件产品的生产，软件工程领域有很多理论和实践成果，已成为一门学科。软件工程的意义在那里呢？有两点：一是工程化，即工序流程加方法集和工具集；二是标准化，开发和共享都必须有标准作为基础。软件工程理论本身是源于软件开发的实践，但更多是工程理论具体应用的产物。基于软件工程的认知，对于软件项目的管理，就必须建立起一个平台，这个平台有一套完成软件产品的工序流程，每道工序有相应的方法和工具来产生成果，并辅以标准使他人或下道工序可理解工作成果并继续完成下道工序的工作。

对于呼叫中心软件项目的外包管理，搭建一个怎样的平台来满足呼叫中心的软件产品需求就是本文探讨的核心。外包性的软件项目，体现在软件工程的生命周期里，需求阶段无疑是决定软件外包成功的关键因素，因此探讨建立呼叫中心SPOMP的中心就是如何有效地完成需求工作。围绕需求，研究在呼叫中心软件项目外包下，应用快速原型模式建立呼叫中心SPOMP是本文的立足点。

1．背景

对于呼叫中心应用解决方案的提供商，集成是一个高度发散的概念，同时具有深度内敛的意义。因为集成，就必须为自己定位在呼叫中心行业中的作用，就必须寻找在呼叫中心行业中的优势，才不至于涉猎非我所长的业务和逆向产业链上下游。依托电信运营商的背景，集成呼叫中心供应商和信息软件开发商，为各行各业建立专业呼叫中心，发挥呼叫中心作为企业运营核心的作用，这是当前电信呼叫中心的一个明确性做法。

当前呼叫中心市场，以信息软件开发商和以电信运营商作为呼叫中心应用解决方案的集成商是两大主流。既然市场存在可替代的角色出现，就要求我们重视同竞争对手在应用解决方案上的差异，显然客户可感知的软件产品是竞争的关键点，也是差异化的关注点。

客户对于呼叫中心背后电信的运营能力和供应商的设备性能都存在一定程度盲区，但对于呈现在客户面前的软件产品，客户却可以评头论足。换句话说，客户关注的是呼叫中心应用解决方案的最终成果，即是呼叫中心信息软件。一道菜后面的工序如何繁杂、原料如何华奢、配料如何精致，食客最终感知的是菜的色、香、味，于是乎如何做出色香味俱全的菜，背后的工序和原料及配料讲究就不可少。如之，作为呼叫中心应用解决方案的最终感知产品的信息软件，其差异化决定了竞争能力。面对同样的需求，信息软件开发商显然具有更高的需求响应和实现能力，因其工程化和标准化程度较之电信呼叫中心软件项目的外包性质要高。如何提高电信呼叫中心的需求响应和实现能力，建立其软件项目外包配套的管理平台即是本文的论述点。

本文所指的呼叫中心是以广州电信商业呼叫中心为背景，衍生到在呼叫中心运营和建设上具有同样问题和类似特点的软件项目外包。以电信网络运营为基础，建设呼叫中心平台提供商业外包的；具有既定呼叫中心平台架构和业务软件基础框架，为不同行业和不同企业提供不同应用的呼叫中心行业应用解决方案；依赖呼叫中心集成商进行前期呼叫中心的建设和维护，包括呼叫中心应用解决方案中配套软件的开发；以呼叫中心平台和业务软件为产品持续性地提供呼叫中心整体解决方案，以产生社会和经济效应，并带来营收；这是大致描述了本文所指呼叫中心的基本特点，这些特点也决定了选用快速模型模式来建设呼叫中心SPOMP的合理和适用。

2.商业呼叫中心现状

软件项目外包本身所具有的特点，加以广州电信商业呼叫中心软件外包项目为背景分析当前软件外包现状，期以加深对软件外包和呼叫中心软件外包的理解，从而为广州电信商业呼叫中心建立SPOMP以及以之推广作为具有类似特点的呼叫中心的软件项目外包管理。因此，此现状既是共性与个性的结合，那么所探讨建立的呼叫中心SPOMP既可用于特定的广州电信商业呼叫中心也当可适之于具有类似特点的呼叫中心，除问题相似，更在于软件工程的应用在软件外包上应当根据具体情况寻找对应模式以解决。

现状的分析出发于软件外包特点，并结合实际广州电信商业呼叫中心的软件外包项目，因此现状所指出的问题不特定指那个项目，而是从项目中提升到具有通用的高度。本文就从软件工程生命周期的几个环节谈谈当前呼叫中心的软件项目外包现状。

2.1 需求认知的折扣

需求认知的折扣体现在两方面：一是需求传递过程，需求信息失去第一手的效应；二是需求理解上，各环节有各自取向。这里把需求作三方面的划分：一是项目初始需求；二是项目移植平台的需求；二是项目维护的需求变更。这三面需求都存在一定程度的需求传递和需求理解上折扣，如项目初始需求从客户口头到书面的不规范需求；再到客户经理的业务需求理解和技术人员的技术需求理解，最后才到外包公司的项目经理，这个过程通过几番传递和理解，需求失真是相当严重；再如项目维护的需求变更，客户的需求是有一个过程，从对业务软件的零认识到具体操作后的了解，一般在维护初期有大量的需求提出，此时，在客户和外包商之间需求难以取得平衡，当客户对业务软件操作时间越长，提出维护的需求变更可能具有更大的技术难度，此时，外包开发商未必能支撑开发从而导致外包开发商在需求上顾左言他。

对于需求认知折扣的问题，快速原型模式可有效解决；对于外包开发商因需求变更无法支撑开发，可在设计过程要求其提供架构设计，从而避免外包开发商在需求认知上打折扣；同时，应对需求响应机制做变革，尤其是项目初始需求，如在需求响应上，对客户提出的一些不可理喻之类的需求应当有一套完善的响应机制，包括技术上和业务上说服客户并寻求解决方案。

2.2需求界定的模糊

需求范围，实际上就是确定要开发出怎样的一个软件产品，界定功能从根本上抑制了客户不合理的需求。需求界定，目的就是给软件开发方（电信呼叫中心的外包商）和软件需求方（电信呼叫中心的客户）一个明确的功能范畴，回答的就是要做什么？在一个特定行业里，软件具有通用性和一般意义上的功能需求，言则，呼叫中心行业的软件也是如此。但行业软件不能代替具体个体的软件需求，更何况呼叫中心的软件是面对各行各业，基础架构可以相同，但具体功能块的意义却存在一定特异性。

对于呼叫中心软件，在需求阶段，需求的界定仍然是不可或缺的，但目前存在两个思维上的陷阱：一是需求的界定依赖经验，一般没有任何需求过程就直接交付外包商去进行设计开发；二是追求功能上的通用性，重于可配置的说法，而对架构的通用性却没有任何归纳和提升，舍本逐末可见一斑。除这两点影响到需求的界定，需求认知的折扣也一定程度上使需求的界定南辕北辙。

这里有个例子，在电话呼入的关联应用界面上，根据经验，电信方提出在弹屏上显示的客户资料可由客户自己配置并给出常用的资料字段意义，这一点是针对所谓可配置的提法又是借鉴当前一些客户的弹屏资料需求，从业务功能上说没什么可挑剔，但从技术上分析，却是相当粗浅。表现在数据库和性能设计上有过多负担，在界面编排上则过于粗糙，而在业务管理上也不能达到通用软件（从一个客户移植到另一个客户，不需要代码改造而直接进行业务配置）的意义。

愚见：不如在架构设计上预留接口来应对不同客户不同弹屏资料的需求，就是在技术设计上达到通用软件的意义而非业务管理上。因要求业务管理上的通用性，不但影响性能更导致界面粗糙，而就目前来看，几乎每个新客户都要进行或多或少的技术改造，既然如此，不如在架构上设计好这些不同业务应用，避免给客户造成软件粗鄙的感觉。关于需求界定的文章，笔者另有专述。

2.3项目控制的错位

值得大书特书的是项目在各个阶段延期现象的普遍性，更离奇的是对外包商在延期上的纵容，导致延期的原因在于没有有效的利用软件工程方法和工具来控制，使外包商在项目进度上处于主导地位，此为错位体现之一；项目各阶段工作成果离预期相去甚远，原因则在于对项目工作过程的控制几乎为零，通过项目例会和几张excel表完全无法达到实质控制的效果，反而被外包商的延期引发我方的工作目标和工作计划修改，此为错位体现之二。 技术上使外包商居于主导地位，在项目进度和项目质量以及项目资源调配上都极大影响着我方的效益。

要从根本上解决这个问题，就是要建立一套运作机制和一个技术平台，在技术上使我方居于主导地位。任何试图不从技术上寻找控制方法的都将失败，没有实力就无法达到控制目的，只能任由技术控制方来主导项目进展。技术控制方才清晰知道需求能否以及如何实现，何时以及是否可完工。关于项目控制中的主导地位问题，笔者在其他文章中有专门阐述。

2.4工作成果的零乱

零乱，项目阶段性工作成果不齐全和工作内容不到位。软件生命周期的每一个阶段，外包商并没有提供齐全的工作成果，即便提供了部分成果，其离标准软件工程的要求还有相当大差距，“偷工减料”并不足以为反应这种现象，只能用“得过且过”来刻画外包商应付电信方软件需求的心态。软件工程在之所以成为一门学科，有其理论和实践，表现出极大生命力，呼叫中心软件开发无疑是大型的软件工作，利用软件工程来完成是绝对有必要的；而软件工程演变到今天，文档重于代码，既是大多数有经验软件开发人员所认同，也体现了工程化和标准化的思想，更是今天庞大软件开放与共享的基石。在软件项目外包中，对电信方而言，要的就是软件的文档成果，如果电信方自己可以产生代码就不需要外包了。

2.5设计开发过程的零控制

一旦把需求交付给外包商，直到测试验收，中间的设计开发控制目前是处于空白的。实际上，这一部分的完成主体就是外包商，但问题是电信方所提交的需求本身就或是不完善或是没有得到客户认可的，而测试验收上往往没有验收依据和标准，如之，如果不对设计开发进行一定控制，项目延期便是司空见惯的了。在技术一定要由我方主导，尤其在设计上，需求分析和概要设计是必须控制到位的，也必须是我方主导完成的。

面对一个问题或一件事，完成或解决不能基于“不会”的心态，只有“不能”做到，也只有信息“不全”导致解决起来有难度，“不会”要去学去试验而不能成为借口。外包商的项目延期是因技术的“不会”还是“不能”就需要电信方有技术上的分析，而不能听凭外包商之言语，如果是技术“不能”或信息“不全”则可以另找解决方案，如是“不会”则不能迁就。要避免外包商的“不会”就要在设计上要求外包商对需求做充分的技术分析，包括有技术难度的开发量和开发周期并进行一定的试验，一切要建立在试验基础上作分析。如果外包商在设计上已经肯定了需求上是完全可以实现，那么开发中出现因“不会”导致的延期就是外包商的问题。如果设计过程中，经过试验，某些功能需求在技术上存在“不能”的程度，那么就当寻找替代解决方案并向客户反馈。

充分的设计、分析、试验是避免项目延期的关键步骤，但在当前是缺失的。项目延期是设计开发过程零控制带来的问题之一，需求变更找不到切入点则是问题之二。在设计过程中，要做代码开发量估计，细分模块并落实到具体实现者和完成时间，即是控制的粒度。当前电信方是控制到系统级和功能级的粒度，而在菜单级或按钮级上是没有控制的，这首先是具体问题的引发无法有效定位，更核心的是需求变更时找不到切入点，以至于对需求变更（包括设计开发过程的变更和系统维护过程中的变更）的响应度低，反应在需求上就是不能很肯定地给予确认或否认。在设计过程上，细化到菜单和按钮，界面和性能都需要一一给出，严格按照标准设计文档要求完成。

2.6测试验收和维护的流程和机制不健全

测试的无的放矢、验收的无根据、维护的随意性，问题的根源在于没有一定流程和机制。测试什么；测试后的问题如何跟踪；根据什么验收；验收的标准是什么；谁来做网络、平台等的维护；如何响应需求变更；回答这些问题对当前来说相当沉重，往往随机而定，推搪工作责任便因此而产生。

关于维护流程有个不得不提到的误区就是当前流程或约定的惯性做法，就是故障维护（包括网络、服务器、平台、软件、终端）由技术人员（不明白这个“技术”定义的范围，是懂软件、懂网络、懂平台、懂终端还是要懂什么，反正逮个知道IT概念的就是技术人员）来负责响应，而需求变更则由客户经理（始终不明白是做什么的，但非技术人员是可以肯定的）来响应。这样的误区是源于一个传统思维，那就是故障是关于技术方面，而需求是关于业务方面的，理所当然故障就是技术人员来响应，而需求变更则是客户经理的职责范围。

实际上需求是真正的技术活，在软件工程里，系统分析师是负责需求阶段工作，而系统分析师是在软件工程领域是最高级别的工程师。很简单的一个道理，面对一个需求，要回答能不能实现和多大变动以及工作量等（这些关涉到上文提到的需求变更切入点问题），客户经理是回答不了的，只有对之前软件设计有充分掌握并且具备相当高设计开发技术的系统分析师才能回答，而通过客户经理转述的需求就表现出需求传递过程的折扣，而且需要与客户几个回合的确认。信息的传递每经过一个环节，就被当事人用自己的理解方式和思维能力加工一次；需求变更的响应要做技术风险和技术实现评估，一旦需求误解导致的软件返工在时间和成本上都是难以想象的。对于故障维护的响应，则没有多大的技术活，只要知道这个软件的功能，描述下故障情景则相当容易，这对于客户经理来说胜任是可以肯定的，除非客户经理对客户的软件是零认识。

这里要做一个概念区分：故障维护的响应和解决故障维护是两个层面的问题，需求变更的响应和需求变更的实现也是如此。故障的响应需要的就是把问题描述清楚，然后转给维护人员解决，并没有技术含量，解决故障才需要技术含量，所以故障的响应并不一定非要技术人员；需求变更的响应则一定需要技术人员，而且非得是系统分析师级才能定位需求，并作技术风险和技术实现的评估。建立其故障和需求变更的响应流程的机制是迫切的，而对于后面支撑的故障维护和需求实现同样如此。

3.快速原型模型简介

软件开发模型（Software Development Model）是指软件开发全部过程、活动和任务的结构框架，包括需求、设计、编码和测试等阶段，有时也包括维护阶段。早期的瀑布模型采用线性过程来开发软件，存在软件需求不明确带来的开发风险，快速原型模型则克服该缺点，其本质上是迭代的。

快速原型的思想核心是原型概念，在获得基本需求后，快速建立一个可以运行的软件原型，通过原型反馈，加深对系统理解，使用户在试用过程中受到启发，对需求说明进行补充和精确化，消除不协调的系统需求，逐步确定各种需求，从而获得合理、协调一致、无歧义的、完整的、现实可行的需求说明。通过建立原型并反馈原型，可以达到理解需求，在开发团队和用户业务需求上达成共识。

快速原型模型允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义，快速设计开发出软件系统的原型，该原型向用户展示待开发软件的全部或部分功能和性能；用户对该原型进行测试评定，给出具体改进意见以丰富细化软件需求；开发人员据此对软件进行修改完善，直至用户满意认可之后，进行软件的完整实现及测试、维护。

快速原型模型的两个关键思想：一是原型的原理；二是快速的思想。经过对基本需求的快速分析，快速搭建一个原型模型，通过对原型的不断试用、评价、反馈、改进以提高软件质量，并交付最终满足用户需求并真正实现了用户需求的产品。快速原型从迭代的角度，可从图3-1 快速原型的迭代表示图；结合软件开发全过程，可从图3-2 快速原型模型图中切入快速原型的需求分析阶段。

原型开发步骤：

1）快速分析

在分析人员与用户密切配合下，迅速确定系统的基本需求，根据原型所要体现的特征描述基本需求以满足开发原型的需要。

2）构造原型

在快速分析的基础上，根据基本需求说明尽快实现一个可行的系统。这里要求具有强有力的软件工具的支持，并忽略最终系统在某些细节上的要求，如安全性、坚固性、例外处理等等，主要考虑原型系统能够充分反映所要评价的特性，而暂时删除一切次要内容。

3）运行原型。

这是发现问题、消除误解、开发者与用户充分协调的一个步骤。

4）评价原型

在运行的基础上，考核评价原型的特性，分析运行效果是否满足用户的愿望，纠正过去交互中的误解与分析中的错误，增添新的要求，并满足因环境变化或用户的新想法引起的系统要求变动，提出全面的修改意见。

5）修改

根据评价原型的活动结果进行修改。若原型未满足需求说明的要求，说明对需求说明存在不一致的理解或实现方案不够合理，则根据明确的要求迅速修改原型。

本文着重于快速原型模型开发过程中需求分析阶段利用原型进行若干次迭代，从而有效地获取和理解用户需求。在需求分析阶段进行迭代，其成果就是需求说明，有需求说明可进入设计编码，并作为最后测试验收依据。基于原型模型原型的商业呼叫中心SPOMP正是在快速和原型两个核心思想上，强化需求分析阶段的工作成果，使外包商的设计和开发有出发点而不偏离需求方向，同时在各个开发阶段提出相应方法集和工具集来管理软件外包。利用了快速原型模型的原理，并按照软件开发生命周期的阶段来给出SPOMP是本文的立足点。

3.商业呼叫中心SPOMP

软件项目外包需求阶段是关键和核心环节，对于商业呼叫中心的软件外包也是如此，如你要把一件事交给起他人完成，总要清楚描述你对这件事希望达到的效果。既需求是重要的，那么在建立SPOMP上，关注需求阶段的工作便是核心。快速原型模型的特点就关注需求阶段的工作，同时从商业呼叫中心的特点出发，用快速原型模型实现建立其SPOMP具有优势。同时，呼叫中心外包的业务软件是集成软件，需求上需要反复认可，也是利用快速原型模型建立SPOMP的出发点。商业外包呼叫中心的平台和业务软件基础架构是固定的，商业外包时根据行业和企业的特定需求开发业务应用，此时在快速原型的需求提供上可以利用之前的软件架构和业务应用作为原型，而不需要再次去搭建原型。

3.1 建立SPOMP的出发点

建立商业呼叫中心SPOMP的关键是需求阶段的工序和工具，同时，需要在软件外包的整个过程按照软件工程的快速原型模型来监控和完成，同样需要给予一定方法和工具来配合完成，才能建立完善的SPOMP。这里简单总结下为什么要用快速原型模型来建立商业呼叫中心的SPOMP？即基于怎样的出发点？

1）商业呼叫中心软件外包的现状决定应从软件生命周期的各阶段上加强控制，而商呼叫中心软件外包中需求分析阶段是核心，因此采用快速原型模型来建立SPOMP；

2）商业呼叫中心平台和软件基础架构以及商业外包的性质，决定了在快速建立模型上有优势和低成本；

3）商业呼叫中心软件外包贯穿的软件开发过程都存在控制问题，因此需要在快速原型模型基础上加强对软件开发各阶段的控制；

4）借助快速原型模型的原理作好需求分析阶段，同时按照软件生命周期的开发过程给出方法集和工具集来建立SPOMP；

所要建立的商业呼叫中心SPOMP是基于快速原型模型的快速和原型原理来控制需求分析阶段，同时快速原型模型本身就是软件生命周期模型，包含完整的软件开发过程，基于软件外包现状，在连贯需求分析阶段上设计一些方法配合工具来控制软件外包的设计、编码、测试过程，使外包项目在进度和成本上得到有效控制。商业呼叫中心SPOMP就是针对软件外包项目，应用快速原型模型的原理建立商业呼叫中心软件外包过程的方法集和工具集，给出SPOMP整体软件生命周期，即工序，同时为每个工序制定方法和工具。

3.2 商业呼叫中心SPOMP

这里先给出基于快速原型模型的软件项目外包生命周期，后就生命周期各阶段给出方法和工具。软件外包和商业呼叫中心的商业外包性质决定了需求分析阶段的重要性；商业呼叫中心现状要求对软件外包的生命周期各个阶段加强控制；基于此，应用快速原型模型的原理，研究建立一套以快速原型模型为蓝本的适合商业呼叫中心软件外包管理的工序流程及相应的方法集和工具集，即商业呼叫中心SPOMP，目的是高效地理解用户需求和实现用户需求。

3.2.1 SPOMP的软件生命周期模型

以快速原型模型为基础建立SPOMP的生命周期模型，即工序，给出流程和每个环节需要提交的成果，涉及三方，分别是软件厂商、商业呼叫中心和客户。SPOMP的软件生命周期模型见图3-3 SPOMP的软件生命周期模型图。

1）需求定义

步骤一：需求定义是在商业呼叫中心和客户之间进行，主要是提取客户最基本需求，由客户描述其基本需求，商业呼叫中心制作出对应的行业或企业呼叫中心解决方案。

输入：客户基本需求；

输出：呼叫中心解决方案；

步骤二：应用快速原型模型的核心原理：快速、原型。根据提供给客户的初步呼叫中心解决方案选择行业相同或需求相似的已有客户呼叫中心软件作为原型，商业呼叫中心的商业外包性质在原型建立上就具有这个优势，不需要建立原型而是将已有业务软件作为原型。

输入：初步呼叫中心解决方案；

输出：行业相同或需求相似的呼叫中心业务软件作为原型；

如果客户提出的需求在业有呼叫中心软件里都没有原型的影子，首先这个可能性极其低，如果确实有存在，那么还是可以将这部分保留在呼叫中心解决方案中不作原型评价，而大部分需求存在原型的，则继续迭代。

步骤三：指导客户运行、评价原型，使客户对产品有实际体会，从而矫正自己的需求描述或提出需求变更和扩大需求范围，对商业呼叫中心软件产品本身也是一种营销。这个过程要开始应用快速原型模型的核心原理：迭代。客户运行后的评价结果，重复到步骤一，修改和完善呼叫中心解决方案，再到步骤二及步骤三。

输入：原型；

输出：原型评价结果；

需求定义应用快速原型模型原理完成需求确认，最终输出结果是客户的呼叫中心解决方案。

2）需求分析

需求定义的输出结果是呼叫中心解决方案，是与客户按照快速原型模型原理反复进行和确认的，需求相对明确和文档化。需求分析中，客户不再需要参与，而在软件外包厂商与商业呼叫中心进行。

首先商业呼叫中心交付解决方案予软件厂商，由软件厂商进行技术试验和工作量分析，完成需求规格说明书。技术试验要针对解决方案中具有较高难度的进行先期试验，如果未能实现或需要很长时间需要与客户明确，排除风险。技术试验要给出报告，同时加入到需求规格说明书里作为下个环节的参考。工作量分析在于给出进度，利于外包控制。

输入：呼叫中心解决方案；

输出：需求规格说明书、技术试验报告、项目进度表；

3）设计

设计阶段主要是由软件厂商完成，商业呼叫中心控制进度和审核工作成果。概要设计阶段要产生概要设计说明书，主要关注软件的业务架构和物理部署，业务架构看是否满足呼叫中心平台和解决方案以及二次开发；物理部署则要看是否存在硬件资源可节省之出，如灾备上不同方案对硬件资源的需求量是不同的。详细设计阶段的说明书要重点关注是否进行软件工作量估计，从而有效地把系统每个功能块纳入进度控制。

输入：需求规格说明书、项目进度表；

输出：概要设计说明书、详细设计说明书；

4）编码

编码主要是软件厂商完成，商业呼叫中心只需要按照详细设计说明书中给出每个功能块进度进行控制和跟踪即可。

5）测试验收

测试验收要分为两个步骤，测试在商业呼叫中心和软件厂商，验收在商业呼叫中心和客户。测试要根据不同情况来进行，集成系统要建议采用测试案例来。

步骤一：测试要分功能测试（含UI测试点）和性能测试，由软件厂商根据详细设计说明书出功能测试用例和系统性能测试用例，商业呼叫中心根据测试用例进行测试，并给出测试报告，由软件厂商根据测试修正系统。

输入：功能测试用例、系统性能测试用例；

输出：测试报告；

步骤二：验收要提供功能验收表，由客户进行验收。

输入：功能验收表；

输出：软件产品

6）运行维护

运维纳入日常商业呼叫中心外包客户维护体系，故障响应机制和处理流程必须有统一的规划和执行。软件厂商必须提供用户操作手册和维护手册。

3.2.2 SPOMP的方法集和工具集

SPOMP的软件生命周期模型给出了流程和阶段要出的成果，从工程化角度完成SPOMP的任务，接下来需要对阶段成果进行标准化，使成果可以在厂商、呼叫中心或客户之间达到共识并理解，要实现标准化的成果就要有一定方法和工具来完成。标准化的SPOMP工作成果，需要在软件工程理论上给出方法，同时配合工具来完成。

对于SPOMP的软件生命周期，与一般快速原型模型不无差别，同时，软件主要工作在于软件厂商，因此SPOMP的方法集和工具集主要是为软件厂商提一个原则性的思路，要求软件厂商按照标准化的软件方法来完成呼叫中心所需要的软件工作成果。

1）UML语言

UML既是一种建模方法，作为语言又是工具。在SPOMP上，不管基于怎样的程序开发语言，还是采用怎样软件开发方法，必须用UML来建模。需求规格说明书、概要设计说明、详细设计说明书都要求以UML的建模图形来完成。

无论对内对外，或是今后系统升级或是为其他系统借鉴，用UML建模型所得的成果都具有通用和标准化的意义。要求软件厂商在需求分析和设计阶段完成的成果用标准UML建模图完成。

2）COCOMOⅡ模型

对于软件工作量的分析，按照COCOMOⅡ模型来。软件工作量估算和技术试验分析是项目进度和软件成本控制的初始依据，必须严格要求软件厂商做到位。COCOMOⅡ模型本身也是方法和工具的集合，要求软件厂商按照标准来完成。

除按照UML语言和COCOMOⅡ模型来进行建模和工作量分析以完成标准工作成果，SPOMP还就商业呼叫中心本身实际情况对SPOMP生命周期阶段工作成果给出要求。

1）呼叫中心解决方案

针对不同客户给出行业性或企业独特性的呼叫中心解决方案，其内容必须包括呼叫中心平台组网和业务软件需求定义。业务软件需求定义要在与客户进行沟通不能过于专业，采用Visio工具给出流程和功能，或通过表格展示功能。

2）技术试验报告

技术试验报告是要求软件厂商对需求进行技术上预估计，在一些需求难点上先做技术试验。该报告含需求点、说明难度点和难度值、试验环境、试验过程（含代码）、试验结果（对项目及项目进度的影响）。报告本身就是一份含程序代码清单的技术说明书，技术试验报告是防止软件外包厂商以某个需求点有技术难度来解释项目延期原因，另一方面对于商业呼叫中心掌握项目技术主导权有决定性作用。

3）项目进度表

考虑到以往在项目上因为一些特别原因如封网，对于项目时间的调整比较频繁，因此要求软件厂商的项目进度表按PERT图来体现。在项目实施过程，可以按照：①绘制网络图；②网络计划计算；③求关键路径；④计算完工期及其概率；⑤网络计划优化；这五个步骤来完成。

项目进度表是项目控制的核心，同时对于详细设计阶段，进行具体代码块分析时，也需要在整体项目进度内对编码阶段的各个代码块进度给出完成时间点，尤其在一些里程碑功能点完成上就一定要有控制。 因此，SPOMP要求详细设计说明书里要给出代码块进度表，这主要是根据经验上要求的。

4）测试案例

测试用例按照软件测试方法中标准方法实现，含输入、过程、输出、结果等的描述。根据经验测试用例往往对难以全面覆盖，如果软件厂商有意掩盖内部测试时发现的BUG（项目到期，该BUG无法及时修正，只能隐瞒先交付），那么在测试用例上更无法有效体现。SPOMP要求软件厂商提供测试案例，做仿真测试。往往由于测试覆盖不全面，难以发现问题和不满足需求处，当交付客户使用后引发客户极大不满。仿真测试案例上，对于各个功能块或集成系统能够连成一体测试，覆盖性较全面，而且有利于发现边界BUG。

SPOMP经过一年的探索，生命周期基本确定，在具体方法和工具有待不断完善，如关于软件作坊的工件化思路和外包业务架构本人都有专门阐述。

3.2.3 SPOMP的效应</sp