摘要：本文從快速原型（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的效應

商業呼叫中心SPOMP的生命周期模型實現了軟件項目外包的工程化，實現了工程化的SPOMP對項目進度有清晰和透徹的掌握；同時其方法集和工具集標準化了軟件項目外包的工作成果，標準化的SPOMP對項目的工作成果有主導性和決定權。

1）SPOMP使商業呼叫中心對外包的軟件項目具有技術主導性

擁有技術主導性就對軟件廠商提出的項目延期和資源利用上有透徹把握。如軟件廠商提出因某個需求的實現而影響了項目開發進度，可以從技術試驗報告或從需求規格說明書以及詳細設計說明書這些標準工作成果找出是否合乎實情。再如不同的軟件架構可能對服務器提出不同的要求，最大化利用服務器資源可以節省硬件資源成本，如果概要設計軟件部署上，軟件廠商可能為了簡化軟件開發難度而采用犧牲硬件資源，技術主導性將遏止這種現象的發生。

技術主導性帶來的效應：項目延期的控制；硬件資源成本的控制；項目質量的把握。

2）SPOMP使商業呼叫中心實現對項目進度的有效控制

項目進度和紀律，這幾乎并無關系的兩個含義，但卻是正相關。只要按照軟件工程的紀律來，項目進度才能有效控制。為什么？科學的理論和深刻的教訓都告訴軟件從業者，按照一定的工序完成標準的工作成果是軟件取得成功的唯一秘訣。

因此，項目進度一定要放在SPOMP上去控制，也一定按照SPOMP的工程化和標準化去完成生命周期內的工作成果。

3）SPOMP有效地解決了商業呼叫中心存在的問題

SPOMP生命周期應用快速原型模型原理有效地解決了需求認知折扣和需求界定模糊的問題；SPOMP使商業呼叫中心在項目控制上居于主動性地位，解決項目控制錯位的問題；SPOMP標準化的工作成果避免出現工作成果的零亂問題；SPOMP通過工作成果的標準化來實現設計和編碼過程的參與；SPOMP的標準化工作成果有利于健全測試驗收和維護流程。

結束語

商業呼叫中心軟件項目外包的管理是一個持續性并需要不斷提升效益生產能力的過程，需要也必須依賴一套行之有效的工序流程以及相應的方法和工具，謂之平臺。平臺是針對于威權機制或說是強人體制，目的是保證政策的有機性和連貫性。把軟件外包的管理寄托在某一優秀管理者上，是不切實際而且無法保證該管理者永遠是清晰和正確的，也無法保證威權的永恒，一人聽斷，安能盡善。善于搭建平臺來保證事業或組織的可持續性發展而避免將自己塑造為偶像或強者形象，才是一名優秀的管理者。工序將做到各司其職、各就其位，職責明確，分工明晰；流程將保證工序成果的標準化移交；方法和工具是實現工序成果的手段；顯然還需要配套的體系，如是，平臺也。

總結

以上是生活随笔為你收集整理的基于快速原型模型建立商业呼叫中心SPOMP的应用研究的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。