基于服務(wù)化理論指導(dǎo)下的合同管理信息系統(tǒng)的需求開(kāi)發(fā)與構(gòu)建實(shí)現(xiàn)

韓瀟影，劉利民

?

基于服務(wù)化理論指導(dǎo)下的合同管理信息系統(tǒng)的需求開(kāi)發(fā)與構(gòu)建實(shí)現(xiàn)

韓瀟影，劉利民

（甘肅省氣象局氣象信息與技術(shù)裝備保障中心，甘肅 蘭州 730020）

通過(guò)服務(wù)化理論的引入和實(shí)踐，應(yīng)用自頂向下的設(shè)計(jì)方法，基于.NET開(kāi)發(fā)構(gòu)建了覆蓋合同起草、審批、存檔全流程信息化支撐的合同管理信息系統(tǒng)。圍繞用戶和業(yè)務(wù)兩個(gè)主體進(jìn)行需求的分析與開(kāi)發(fā)，基于原型交互進(jìn)行業(yè)務(wù)的梳理與確認(rèn)；開(kāi)發(fā)構(gòu)建中以分層設(shè)計(jì)為基礎(chǔ)，實(shí)現(xiàn)了前端UI層、中間層和數(shù)據(jù)服務(wù)層的完全獨(dú)立和開(kāi)放。整體應(yīng)用建設(shè)在需求開(kāi)發(fā)與設(shè)計(jì)階段投入資源過(guò)半，但是整體建設(shè)投資比傳統(tǒng)應(yīng)用開(kāi)發(fā)減少了約1/3；在良好的業(yè)務(wù)擴(kuò)展框架基礎(chǔ)上，同時(shí)兼顧了良好的投資效益比。

服務(wù)化；合同管理；信息系統(tǒng)；需求開(kāi)發(fā)；構(gòu)建實(shí)現(xiàn)

0 引言

合同作為企業(yè)生產(chǎn)經(jīng)營(yíng)過(guò)程的重要法律文書(shū)依據(jù)，是企業(yè)管理過(guò)程中的重要資源。為了改變現(xiàn)有的手工管理過(guò)程，將數(shù)據(jù)轉(zhuǎn)化為可以提供決策的信息，單位決定建立合同管理信息系統(tǒng)，一期建設(shè)目標(biāo)為合同相關(guān)文件和數(shù)據(jù)的信息化，包括合同業(yè)務(wù)流程的信息化支撐。

在本次合同管理信息系統(tǒng)建設(shè)過(guò)程中，通過(guò)服務(wù)化理論的引入和實(shí)踐，自頂向下的設(shè)計(jì)以及項(xiàng)目分包編碼等方法的支撐，較好的實(shí)現(xiàn)了初期建設(shè)任務(wù)，并為以后的業(yè)務(wù)擴(kuò)展打下了良好的架構(gòu)支撐基礎(chǔ)。

1 服務(wù)化理論的選擇

合同管理信息系統(tǒng)在建設(shè)之初就需要考慮未來(lái)其它業(yè)務(wù)模式[1]的擴(kuò)展（如車(chē)輛管理、耗材管理等）并考慮多終端的應(yīng)用可能，所以在需求分析階段，就否定了傳統(tǒng)的CS應(yīng)用開(kāi)發(fā)部署模式。

在綜合分析之后，決定采用基于服務(wù)化理論的系統(tǒng)規(guī)劃與設(shè)計(jì)，在實(shí)際設(shè)計(jì)中服務(wù)器只會(huì)向客戶端發(fā)送JSON，主要的設(shè)計(jì)步驟包括：整體架構(gòu)設(shè)計(jì)，業(yè)務(wù)需求抽象與建模，服務(wù)規(guī)劃與層次劃分，服務(wù)內(nèi)流程、數(shù)據(jù)、契約（接口）定義和技術(shù)選型。業(yè)務(wù)服務(wù)化意味著后端無(wú)法再繼續(xù)使用非服務(wù)化場(chǎng)景下的技術(shù)（如動(dòng)態(tài)頁(yè)面技術(shù)），雖然傳統(tǒng)框架（如SpringMVC、Mybatis、Hibernate、Structs、Entity-Framework、ASP.NET MVC、ASP.NET Web Form等）同樣也可以實(shí)現(xiàn)服務(wù)化，但這些框架在最初創(chuàng)建時(shí)都會(huì)考慮非服務(wù)化場(chǎng)景，當(dāng)服務(wù)器僅僅向客戶端發(fā)送JSON時(shí)，這些框架顯得臃腫和低效，并且此類傳統(tǒng)框架基本上都是利用反射機(jī)制創(chuàng)建和運(yùn)行，反射意味著運(yùn)行性能的部分損失；所以合同管理信息系統(tǒng)開(kāi)發(fā)過(guò)程中選擇直接使用ASP.NET Web API作為底層服務(wù)實(shí)現(xiàn)的驅(qū)動(dòng)。

2 合同業(yè)務(wù)管理范圍

合同信息管理系統(tǒng)對(duì)合同從起草、審批、存檔的全流程做信息化管理，實(shí)現(xiàn)紙質(zhì)合同的數(shù)據(jù)信息化存檔，基于信息化數(shù)據(jù)的快速檢索；對(duì)合同相關(guān)附件、回款記錄、以及回款發(fā)票信息的存檔和檢索。在合同管理信息系統(tǒng)中，將完整覆蓋整個(gè)合同管理的業(yè)務(wù)范圍，對(duì)于合同洽談、審批痕跡等，都需要做到數(shù)據(jù)采集與信息化存檔管理。

圖1 合同業(yè)務(wù)流程圖

3 需求開(kāi)發(fā)過(guò)程概述

在需求調(diào)研與開(kāi)發(fā)階段，圍繞用戶和業(yè)務(wù)兩個(gè)主體展開(kāi)[2]，主要的工作任務(wù)是理清業(yè)務(wù)，充分理解并挖掘用戶界面、用戶交互。在合同信息管理系統(tǒng)中，因?yàn)樾枰紤]未來(lái)其它業(yè)務(wù)模式的擴(kuò)展，所以對(duì)于系統(tǒng)業(yè)務(wù)相關(guān)的組織結(jié)構(gòu)和用戶的管理，是在合同業(yè)務(wù)管理范圍之上的；按照前述的合同業(yè)務(wù)流程清單，通過(guò)和具體的業(yè)務(wù)人員做訪談、溝通，按照業(yè)務(wù)環(huán)節(jié)、業(yè)務(wù)操作的結(jié)構(gòu)總結(jié)出具體的需求闡述，以及其他必要的非功能性需求定義（如對(duì)安全性、性能、使用環(huán)境、用戶主題等的描述說(shuō)明）。

3.1 合同業(yè)務(wù)管理的“用戶”開(kāi)發(fā)

任何應(yīng)用系統(tǒng)的設(shè)計(jì)與開(kāi)發(fā)，最重要的原則就是用戶交互[3]。用戶是應(yīng)用系統(tǒng)的中心，所有其他一切都圍繞用戶開(kāi)展。在服務(wù)化的應(yīng)用系統(tǒng)中，一個(gè)具體的功能被定義為服務(wù)，使用服務(wù)的用戶可以是人，還可能是其他內(nèi)部或外部系統(tǒng)。如在合同到期前通過(guò)郵件系統(tǒng)自動(dòng)告知合同所有人，此時(shí)的郵件系統(tǒng)就是合同管理信息系統(tǒng)的一個(gè)潛在的用戶。在合同管理信息系統(tǒng)中，最終的用戶定義如下表1。

表1 用戶定義表

Tab.1 User defined tables

3.2 合同業(yè)務(wù)管理的“業(yè)務(wù)”梳理與開(kāi)發(fā)

業(yè)務(wù)的梳理與開(kāi)發(fā)[4]主要分兩類，一是每一類用戶分別參與哪些業(yè)務(wù)，二是一個(gè)業(yè)務(wù)分別有哪些用戶參與。在需求開(kāi)發(fā)過(guò)程中，重點(diǎn)是理清每一個(gè)業(yè)務(wù)中包含哪些環(huán)節(jié)，每一個(gè)環(huán)節(jié)中包含哪些操作。也就是說(shuō)，從結(jié)構(gòu)化的角度，一個(gè)業(yè)務(wù)由多個(gè)環(huán)節(jié)構(gòu)成，一個(gè)環(huán)節(jié)由多個(gè)操作構(gòu)成；環(huán)節(jié)與操作分別對(duì)應(yīng)了設(shè)計(jì)及后續(xù)階段的模塊和功能。在同一個(gè)環(huán)節(jié)中，業(yè)務(wù)操作之間應(yīng)該具有高內(nèi)聚度。在Web用戶界面上，同一個(gè)環(huán)節(jié)的多個(gè)操作通常表現(xiàn)為一兩個(gè)完整的頁(yè)面，其中包含一個(gè)入口頁(yè)面，其他業(yè)務(wù)操作可以通過(guò)局部視圖、對(duì)話框等方式與用戶進(jìn)行交互操作。

對(duì)于業(yè)務(wù)環(huán)節(jié)的需求開(kāi)發(fā)，主要集中在：如何進(jìn)入業(yè)務(wù)操作，業(yè)務(wù)操作需要哪些輸入數(shù)據(jù)，這些數(shù)據(jù)如何展示；對(duì)數(shù)據(jù)執(zhí)行何種操作，業(yè)務(wù)操作完成后會(huì)產(chǎn)生和返回哪些數(shù)據(jù)，這些數(shù)據(jù)如何展示。

具體在合同管理信息系統(tǒng)中，合同起草業(yè)務(wù)包括合同基本信息錄入，同時(shí)可能存在合同附件信息上傳；在合同存檔業(yè)務(wù)中，必須上傳合同附件信息。所以，對(duì)這兩個(gè)業(yè)務(wù)做梳理結(jié)果如圖2。

其中，【合同起草】作為一個(gè)業(yè)務(wù)模塊，包括合同基本信息錄入，合同附件上傳兩個(gè)功能環(huán)節(jié)；一個(gè)功能定義一個(gè)請(qǐng)求，一個(gè)功能完成一定的業(yè)務(wù)操作，多個(gè)功能共同構(gòu)成一個(gè)模塊。在具體實(shí)現(xiàn)中，功能被創(chuàng)建為模塊類的方法（函數(shù)），在數(shù)據(jù)庫(kù)中實(shí)現(xiàn)時(shí)被創(chuàng)建為存儲(chǔ)過(guò)程，其包含一組輸入?yún)?shù)、輸出參數(shù)或者輸入輸出參數(shù)?；诜?wù)化的實(shí)現(xiàn)，所有的功能都只向客戶端發(fā)送JSON 數(shù)據(jù)，而不會(huì)包含任何動(dòng)態(tài)前端代碼，比如 HTML、CSS 或 JS。

對(duì)于【合同附件上傳】分別定義兩個(gè)功能，其原則是“每一個(gè)環(huán)節(jié)僅僅只有一個(gè)用戶角色執(zhí)行各種操作”；同時(shí)考慮業(yè)務(wù)環(huán)節(jié)之間應(yīng)該具有低耦合關(guān)系，當(dāng)一個(gè)環(huán)節(jié)僅涉及一個(gè)用戶角色時(shí)，可以避免模塊之間的角色依賴。合同起草和合同存檔，都是通過(guò)獨(dú)立的角色在權(quán)限ACL（訪問(wèn)控制列表）控制下分別啟動(dòng)業(yè)務(wù)功能模塊的，合同起草時(shí)，完成合同基本信息的錄入；合同的審批與執(zhí)行信息由合同審批環(huán)節(jié)進(jìn)行確認(rèn)；合同附件信息可能在起草時(shí)已經(jīng)確認(rèn)，也可能在存檔時(shí)進(jìn)行最終的確認(rèn)。

對(duì)于【生成合同編號(hào)】業(yè)務(wù)功能，可以考慮以后臺(tái)服務(wù)的形式提供，但是實(shí)際開(kāi)發(fā)中考慮到存在提供靈活的合同編號(hào)預(yù)檢索功能的潛在要求，以前臺(tái)UI的形式進(jìn)行業(yè)務(wù)模塊功能的設(shè)計(jì)支撐，業(yè)務(wù)體現(xiàn)為一個(gè)獨(dú)立的“獲取合同編號(hào)”環(huán)節(jié)，對(duì)該功能在設(shè)計(jì)時(shí)直接定義具體的輸入?yún)?shù)、輸出參數(shù)，供后續(xù)開(kāi)發(fā)實(shí)現(xiàn)。

圖2“合同起草”與“合同存檔”業(yè)務(wù)環(huán)節(jié)定義

圖3 “生成合同編號(hào)”業(yè)務(wù)環(huán)節(jié)定義

3.3 合同信息管理系統(tǒng)的“原型”開(kāi)發(fā)

在實(shí)際的需求調(diào)研開(kāi)發(fā)過(guò)程中，終端用戶很難清晰的描述他們的實(shí)際需求，這給需求調(diào)研和分析帶來(lái)極大的阻力。實(shí)際建設(shè)過(guò)程中，通過(guò)采用原型設(shè)計(jì)的方式，制作一個(gè)相對(duì)較友好的交互原型，并且對(duì)原型也進(jìn)行了快速的迭代設(shè)計(jì)與開(kāi)發(fā)，實(shí)現(xiàn)了終端用戶需求的進(jìn)一步深入挖掘和完善。

合同信息管理系統(tǒng)的第一版原型設(shè)計(jì)，與第二版原型設(shè)計(jì)[5]，具體見(jiàn)圖4、圖5；實(shí)際開(kāi)發(fā)過(guò)程中，第二版開(kāi)發(fā)結(jié)果直接被復(fù)用為系統(tǒng)前端的成果，減小了重復(fù)開(kāi)發(fā)的工作量，實(shí)現(xiàn)了系統(tǒng)的快速開(kāi)發(fā)。

圖4 合同信息管理系統(tǒng)的第一版原型設(shè)計(jì)

圖5 合同信息管理系統(tǒng)的第二版原型設(shè)計(jì)與系統(tǒng)前端展示基本一致

4 應(yīng)用構(gòu)建過(guò)程概述

4.1 應(yīng)用構(gòu)建原則

動(dòng)態(tài)View：傳統(tǒng)的Web應(yīng)用動(dòng)態(tài)視圖通常是由服務(wù)器生成的。這意味著服務(wù)器不僅僅要執(zhí)行業(yè)務(wù)和數(shù)據(jù)操作，還必須負(fù)責(zé)View的創(chuàng)建，這是一個(gè)非常耗時(shí)的過(guò)程。實(shí)際上，在服務(wù)器完成響應(yīng)前，用戶其實(shí)是在等待當(dāng)中。既然如此，就不如盡快向客戶端響應(yīng)數(shù)據(jù)，完成請(qǐng)求，降低服務(wù)器負(fù)擔(dān)，由 客戶端自己完成數(shù)據(jù)呈現(xiàn)；客戶端能自己完成的事，就讓它們自己去完成；在此過(guò)程中，客戶端還可以提供更友好的交互體驗(yàn)。

無(wú)狀態(tài)：不在服務(wù)器端使用Session，不因?yàn)镾ession對(duì)服務(wù)器資源造成壓力。不使用Session使得整個(gè)應(yīng)用系統(tǒng)構(gòu)建在無(wú)狀態(tài)的HTTP協(xié)議之上。

數(shù)據(jù)排序：傳統(tǒng)排序一般要依賴于數(shù)據(jù)庫(kù)的ORDER BY或應(yīng)用服務(wù)器的內(nèi)存排序，無(wú)論如何都會(huì)增加服務(wù)器的負(fù)擔(dān)。實(shí)際除了數(shù)據(jù)庫(kù)分頁(yè)查詢需要的排序，所有其他排序不在服務(wù)器端完成，而是發(fā)送到客戶端后，由客戶端自己完成排序。開(kāi)發(fā)中選擇通過(guò)JS的Array.sort進(jìn)行排序處理。

異步：目前在Java中沒(méi)有實(shí)現(xiàn)請(qǐng)求、數(shù)據(jù)操作以及響應(yīng)的完善的異步支持，請(qǐng)求接收后將在請(qǐng)求上下文中同步完成請(qǐng)求處理和響應(yīng)。開(kāi)發(fā)中選擇.NET框架進(jìn)行開(kāi)發(fā)支撐，通過(guò)使用async/await實(shí)現(xiàn)異步操作支持，充分利用ADO.NET提供程序自身的異步操作方法，改善了性能。

4.2 應(yīng)用分層實(shí)現(xiàn)

合同信息管理系統(tǒng)整體的應(yīng)用分為三層設(shè)計(jì)實(shí)現(xiàn)：前端、中間層和數(shù)據(jù)服務(wù)[6]。

前端：考慮到未來(lái)的系統(tǒng)擴(kuò)展性，前端可以是桌面瀏覽器、移動(dòng)瀏覽器或者移動(dòng)原生應(yīng)用；從數(shù)據(jù)的角度，前端被設(shè)計(jì)為是可以識(shí)別JSON數(shù)據(jù)的應(yīng)用。實(shí)際開(kāi)發(fā)中基于Material Design Components（谷歌發(fā)布的可以同時(shí)滿足不同終端需要的Web組件），不使用其他第三方UI和數(shù)據(jù)框架，僅使用jQuery創(chuàng)建和操作動(dòng)態(tài)DOM，它們是基于H5和CSS3的代碼，可同時(shí)滿足在桌面和移動(dòng)瀏覽器上使用，為后期應(yīng)用的可移植性打好了基礎(chǔ)。

中間層：中間層選擇了.NET（C#）?？蛻舳苏?qǐng)求由Web API直接轉(zhuǎn)交給目標(biāo)服務(wù)API，再由服務(wù)API提交到數(shù)據(jù)庫(kù)，通過(guò)存儲(chǔ)過(guò)程執(zhí)行數(shù)據(jù)操作。當(dāng)數(shù)據(jù)操作完成后，返回結(jié)果到服務(wù)API，由服務(wù)API負(fù)責(zé)將數(shù)據(jù)轉(zhuǎn)換為JSON，最后由Web API將JSON發(fā)回客戶端。在整個(gè)過(guò)程中，參數(shù)映射、數(shù)據(jù)編碼（總是使用UTF-8）、數(shù)據(jù)結(jié)果集到實(shí)體類對(duì)象的轉(zhuǎn)換、實(shí)體類對(duì)象到JSON的轉(zhuǎn)換等都遵循服務(wù)設(shè)計(jì)的約定。

數(shù)據(jù)服務(wù)：數(shù)據(jù)庫(kù)復(fù)用了單位現(xiàn)有的SQL SERVER，簡(jiǎn)化部署與維護(hù)的成本。在不改變前端和中間層的情況下，數(shù)據(jù)服務(wù)還可以是MySQL或者是其他數(shù)據(jù)服務(wù)。為后續(xù)可能的數(shù)據(jù)庫(kù)平臺(tái)轉(zhuǎn)移提供了最大的便利。

圖6 合同信息管理分層實(shí)現(xiàn)-前端代碼輸出展示

實(shí)際開(kāi)發(fā)中基于分層的快速編碼[7]輸出見(jiàn)圖7、圖8，具體輸出內(nèi)容包括：

（1）前端代碼，包括所有必要的HTML、CSS和JS：

每一個(gè)功能的HTML文件和對(duì)話框HTML；

每一個(gè)功能的服務(wù)器API請(qǐng)求代碼，API請(qǐng)求參數(shù)封裝和驗(yàn)證，API返回JSON的解析和呈現(xiàn)（數(shù)據(jù)綁定）。

（2）中間代碼：

每一個(gè)功能API的參數(shù)封裝和映射，每一個(gè)實(shí)體類，以及每一個(gè)實(shí)體類的JSON序列化。JSON序列化不是通過(guò)反射實(shí)現(xiàn)的，而是完全通過(guò)TextWriter實(shí)現(xiàn)，效率更高；

圖7 合同信息管理分層實(shí)現(xiàn)-中間層代碼編碼

圖8 合同信息管理分層實(shí)現(xiàn)-數(shù)據(jù)庫(kù)代碼編碼

ADO.NET數(shù)據(jù)庫(kù)操作代碼，ADO.NET數(shù)據(jù)結(jié)果集合到實(shí)體對(duì)象的轉(zhuǎn)換代碼；

Web API基礎(chǔ)框架代碼。

（3）數(shù)據(jù)庫(kù)代碼：

每一個(gè)功能對(duì)應(yīng)的存儲(chǔ)過(guò)程，每一個(gè)存儲(chǔ)過(guò)程內(nèi)部的參數(shù)驗(yàn)證代碼，每一個(gè)存儲(chǔ)過(guò)程內(nèi)部的INSERT、UPDATE、DELETE和SELECT；

每一個(gè)分頁(yè)存儲(chǔ)過(guò)程內(nèi)分頁(yè)查詢代碼；

每一個(gè)存儲(chǔ)過(guò)程內(nèi)結(jié)果集或輸出參數(shù)的返回代碼；

每一個(gè)實(shí)體類對(duì)應(yīng)的視圖代碼，每一個(gè)視圖的實(shí)現(xiàn)。

5 項(xiàng)目實(shí)踐結(jié)果

服務(wù)化的本質(zhì)，無(wú)非就是client發(fā)起調(diào)用，中間層某個(gè)組件攔截調(diào)用信息，序列化后將信息傳輸?shù)絪erver端，server端收到調(diào)用請(qǐng)求后反序列化，根據(jù)請(qǐng)求詳細(xì)發(fā)起實(shí)際調(diào)用后返回響應(yīng)傳輸回給client端。本系統(tǒng)中基于對(duì)服務(wù)化理論的實(shí)際探索，在需求分析與開(kāi)發(fā)階段就貫徹自頂向下的服務(wù)化設(shè)計(jì)理念，功能模塊設(shè)計(jì)完全根據(jù)業(yè)務(wù)、權(quán)限、性能、交互和導(dǎo)航要求進(jìn)行開(kāi)發(fā)實(shí)現(xiàn)；在面向?qū)ο笤O(shè)計(jì)的基礎(chǔ)上提供更完善的“邏輯單元”復(fù)用性的設(shè)計(jì)與開(kāi)發(fā)，支持服務(wù)之間根據(jù)業(yè)務(wù)需求來(lái)組合調(diào)用。

通過(guò)基于快速迭代原型的需求開(kāi)發(fā)與設(shè)計(jì)，整體的開(kāi)發(fā)周期比傳統(tǒng)應(yīng)用開(kāi)發(fā)周期縮短了一半，實(shí)際人力投入減少約1/3；完全基于服務(wù)化理念的功能設(shè)計(jì)，可以較好的支撐后續(xù)業(yè)務(wù)范圍的擴(kuò)展，具有良好的投資效益比。

[1] 張昱, 田晉, 楊功廷. 校園黨校結(jié)業(yè)考試系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[J]. 軟件, 2015, 36(4): 73-75.

[2] 楊春霞, 王曉軍, 何子偉, 基于IRP的建設(shè)項(xiàng)目合同管理信息系統(tǒng)規(guī)劃[J], 建筑經(jīng)濟(jì), 2014(08): 5(12): 289-336.

[3] 永明, 蘇斌. 面向服務(wù)架構(gòu)體系的研究[J]. 計(jì)算機(jī)技術(shù)與發(fā)展, 2007 , 17(3): 132-134.

[4] 胡智慧, 朱斐. 基于B/S 架構(gòu)的培訓(xùn)部課程管理系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[J]. 軟件, 2015, 36(8): 79-83.

[5] 熊宗炬, 周波, 李劍陽(yáng). 突發(fā)事件應(yīng)急通信系統(tǒng)原型設(shè)計(jì)[J]. 軟件, 2016, 37(4): 04-07.

[6] 馬亮, 肖建軍, 劉錦文. 西部形變數(shù)據(jù)分中心在提升數(shù)據(jù)服務(wù)能力方面的探究[J]. 軟件, 2016, 37(01): 120-121.

[7] 焦華. 基礎(chǔ)編程的思考方法[J]. 軟件, 2018, 39(3): 57-62.

The Development and Construction of the Contract Management Information System Based on the Service Theory

HAN Xiao-ying, LIU Li-ming

(The meteorological information and technical equipment support center of the Gansu Meteorological Bureau, Lanzhou, Gansu, 730020)

Through the introduction and practice of service-oriented theory, the top-down design method is applied, and a contract management information system supporting the whole process of contract drafting, approval and archiving is built based on. NET development. Around the two main bodies of users and businesses, we need to analyze and develop requirements, and sort out and confirm business based on prototype interaction. Based on layering design, we realized the complete independence and openness of the front tier UI layer, the middle tier and the data service layer. The overall application construction has invested more than half of the resources in the demand development and design stage. However, the overall construction investment has been reduced by about 1/3 compared with the traditional application development. On the basis of a good business expansion framework, a good investment benefit ratio has also been taken into account.

Service; Contract management; Information system; Demand development; Construction and implementation.

p315.69

A

10.3969/j.issn.1003-6970.2018.11.025

韓瀟影(1982-)，女，工程師，主要研究方向：計(jì)算機(jī)科學(xué)與技術(shù)；劉利民(1972-)，男，高工，主要研究方向：大氣科學(xué)。

韓瀟影，劉利民. 基于服務(wù)化理論指導(dǎo)下的合同管理信息系統(tǒng)的需求開(kāi)發(fā)與構(gòu)建實(shí)現(xiàn)[J]. 軟件，2018，39（11）：110-115