李維

北京大學第三醫(yī)院 信息管理中心，北京 100191

基于RUP的醫(yī)院信息系統(tǒng)需求管理研究與實踐

李維

北京大學第三醫(yī)院 信息管理中心，北京 100191

1 需求管理的產(chǎn)生和影響

針對當前醫(yī)院信息系統(tǒng)的特點以及建設過程中需求管理方面薄弱的現(xiàn)狀，本文以RUP的需求管理為理論基礎， 把過程化的思維引入到需求管理中，將整個需求管理過程劃分為三個階段:需求的準備階段、需求分析與定義階段、需求的維護階段。以此作為構建醫(yī)院信息系統(tǒng)項目需求管理模式的基礎，提出了以需求驗證確定、需求變更控制、需求跟蹤及偏差調(diào)整為基本活動內(nèi)容的醫(yī)院信息系統(tǒng)的需求管理過程模型，并在實際項目中加以應用和驗證，進一步對模型進行了改進與完善。

醫(yī)院信息系統(tǒng)；需求管理；過程模型

醫(yī)院信息系統(tǒng)建設的核心是應用軟件系統(tǒng)，軟件需求具有明顯的模糊性、多變性和主觀性的特點，需求是軟件項目最難把握的問題，也是軟件開發(fā)過程中最復雜的一項工作。根據(jù)2008～2009年度中國醫(yī)院信息化調(diào)查顯示，在對HIT（Health IT）應用軟件產(chǎn)品存在問題的回答中，排在第二位的問題是產(chǎn)品沒有真正站在客戶需求的角度設計，易用性不佳，比例為37.46%。在所有參與醫(yī)院對于信息化發(fā)展障礙因素的回復中，供應商缺乏提供滿足需求產(chǎn)品與服務能力分列信息化發(fā)展障礙因素的前五位，這些都直接與需求管理有關。

分析醫(yī)院信息化項目需求變更頻繁的原因，主要有以下兩點：

⑴ 行業(yè)特點決定 一般來講，醫(yī)院信息化項目實施周期長、涉及部門眾多，相對其他行業(yè)的信息化進程而言，具有較大的復雜度。系統(tǒng)建設之初通常不能確定最終解決方案的全部功能和需求，所以需求變更是經(jīng)常的事。

⑵ 開發(fā)過程中沒有規(guī)范化的需求變更管理 用戶對信息系統(tǒng)缺乏全面地了解，在前期只能提出很少、很模糊的需求；信息部門需求獲取和分析工作不夠細致，導致項目范圍的蔓延或用戶的不滿意。

需求變更對醫(yī)院信息化的影響雖然是多方面的，但可以概括為以下三個方面:

(l) 增加醫(yī)院信息化人員及費用開支，影響實施進度 大量頻繁地需求變更會極大地加大項目的人員、費用開支，增加實施風險，嚴重時可能直接導致項目的失敗。

(2)影響醫(yī)院信息系統(tǒng)的質(zhì)量 在一個復雜的信息系統(tǒng)中，需求之間具有一定的聯(lián)系，而相關的需求則構成需求鏈。如果評估變更影響到遺漏需求鏈中的某些環(huán)節(jié)，就可能在實施變更過程中引入一些難以察覺的錯誤，這些錯誤一般難以被測試人員發(fā)現(xiàn)，將直接影響系統(tǒng)的質(zhì)量，嚴重時可導致系統(tǒng)崩潰。

(3)影響信息部門與用戶之間的合作關系 需求變更的實施是供應商、信息部門與一線用戶相互協(xié)作的過程。供應商和用戶在是否采用變更問題上常常產(chǎn)生分歧，如果處理不當，相互之間的信任關系變得越來越差，甚至由合作關系轉(zhuǎn)變?yōu)橐环N對抗關系。

2 基于RUP的需求管理過程研究

RUP 是Rational 公司定義的統(tǒng)一軟件開發(fā)過程，是一種比較完善的需求管理機制，本文在借鑒RUP的基礎上,提出了需求管理過程的概念, 在需求管理中也引入過程化思想，把整個需求管理過程分為三個階段: 需求準備階段、需求定義階段和需求維護階段, 各個階段的定義和任務如表1所示。

表 1 需求管理過程的劃分

3 需求管理過程模型

圖 1 需求管理過程模型

RUP的主要指導原則就是以構架為中心，系統(tǒng)的實現(xiàn)是通過多次迭代完成的。早期的迭代需要盡快確定系統(tǒng)構架，在以后的迭代中逐步去完成系統(tǒng)的全部功能。迭代的過程是對需求逐步理解和細化的過程，也是不斷的添加新需求的過程。每次迭代完成及時與用戶溝通，并在以后的迭代中不斷去修正、填充需求,使其變得正確、穩(wěn)定。

本文建立的需求管理過程模型如圖1，其中包括需求采集、需求分析、需求確定、需求變更管理、偏差調(diào)整、需求跟蹤、需求狀態(tài)跟蹤和需求驗證和評審等子過程，最關鍵過程是需求確定和需求變更控制。各種子過程是迭代的且互有重疊, 它們貫穿于需求管理過程的整個生命周期,只是在生命周期的不同階段的側(cè)重不同而已。

4 門診流程改造項目的需求管理實踐

我院從1998年開始進行大規(guī)模信息系統(tǒng)建設，以包括收費劃價取藥的門診系統(tǒng)取代了之前的單機收費系統(tǒng)，后來又逐步增加了掛號系統(tǒng)、電話預約系統(tǒng)、候診系統(tǒng)、門診導醫(yī)系統(tǒng)等，能夠較好地完成以財務為中心的業(yè)務需要。隨著醫(yī)療衛(wèi)生行業(yè)信息化的發(fā)展，醫(yī)院信息系統(tǒng)已由原來的以財務為中心的思想向以病人為中心的思想進行過渡，需要逐步建設起以門診醫(yī)生工作站為中心的門診系統(tǒng)。

門診業(yè)務流程改造項目是在優(yōu)化現(xiàn)有流程的基礎上對信息系統(tǒng)進行大規(guī)模的改造項目。任務包括建立病人就診卡發(fā)卡中心、實現(xiàn)自動分診叫號、建立門診醫(yī)生工作站、實現(xiàn)網(wǎng)上檢查檢驗結(jié)果查詢，并升級現(xiàn)有的收費、掛號、發(fā)藥、檢驗、住院模塊，使其實現(xiàn)讀卡功能。項目幾乎涉及門診所有業(yè)務部門，包括臨床、醫(yī)技、財務、后勤等范疇，內(nèi)容龐雜，因此應用有效的需求管理顯得尤為重要。

4.1 需求確定

首先采用了問卷調(diào)研的方式來獲取用戶的原始需求。我們給門診業(yè)務涉及到的各個科室、各個職能部門都發(fā)放了問卷，問卷采用統(tǒng)一的格式。如表2所示。

表 2 原始需求調(diào)研問卷

其次，結(jié)合用戶原始需求，項目組根據(jù)業(yè)務流程、相關數(shù)據(jù)標準、業(yè)務標準等寫出軟件需求文檔。

然后，返回業(yè)務部門征求修改意見，進行補充、刪減、改正，得到需求初稿，并采用統(tǒng)一格式歸檔。

最后，組織開發(fā)人員、信息管理中心、使用部門代表參加，對初稿進行詳細討論和分析，對存在歧義的部分加以確定，得到正式的需求文檔，雙方簽字認可。

經(jīng)過歷時一個月的討論、分析、再討論、再分析，項目組基本獲得了較穩(wěn)定的需求框架，形成了概要設計。根據(jù)實際業(yè)務不同，有些需求要重復上述過程兩輪甚至更多，即在需求確定過程中的迭代。 圖2是使用UML繪制的改造后的門診流程圖，能夠清晰準確地表示門診就診過程中時間順序及對象間的關系，這樣，無論開發(fā)人員、管理人員、使用人員均能建立一個沒有歧義的新的門診流程。

圖 2 用UML描述改造后的門診流程圖

4.2 需求變更管理

在項目核心模塊——醫(yī)生工作站模塊的試運行階段，首先選定各個相關臨床科室的一名醫(yī)生作為該科室的需求變更收集人，負責收集整理該科室醫(yī)生提出的各項需求變更。項目組與軟件供應商每周召開會議討論這些需求，將需求按照對業(yè)務的影響程度，分出優(yōu)先級，包括立即執(zhí)行、推遲執(zhí)行、拒絕，并給予回復。

根據(jù)上述的需求管理過程模型，可以得到項目需求變更的具體流程如圖3所示。

圖 3 需求變更管理流程

范圍變更控制流程中的每個活動由指定的角色或組織來完成。

需求的變更不是一步到位的，隨著項目的推進，最初設計不夠完善之處會逐漸暴露，在不同的階段達到不同的完善程度。項目在試運行階段，通過每周的例會，提出并討論突出問題，逐步細化、明確，加以修改，隨著使用的深入，問題又會暴露出來，修改后再修改。如醫(yī)生站的模板使用，由簡單的藥品處方模板擴充到診療模板，再根據(jù)需要擴充到包含檢驗檢查的模板。一般來說細化的過程經(jīng)過兩三次迭代需求問題就能得到解決。

4.3 用軟件實現(xiàn)需求變更管理過程

當接受變更請求后，應將相應的變更記錄在案，可根據(jù)具體情況采用適合自己情況的記錄方法。由于本項目是改造項目，需求變更涉及到眾多新老系統(tǒng)，不適宜采用全新的軟件來管理，所以選擇了上手較為容易，功能相對簡單的開源軟件Mantis缺陷跟蹤系統(tǒng)實現(xiàn)需求變更管理。項目實施過程中使用該軟件查看就醫(yī)卡子系統(tǒng)需求，軟件將用戶提交的這些問題按人員角色、當前狀態(tài)（新建、打回、已確認、已分配、已解決等）分別顯示。

通過需求數(shù)據(jù)庫，可以方便地對需求的變化，即增加、修改，做出完善的記錄。同時，還可以在需求數(shù)據(jù)庫中顯示需求的層次性，高層需求逐步分解為低層需求，從而使需求能夠有良好的組織形式，便于追溯。此外，也可以通過查看需求狀態(tài)，了解項目進展的情況。

4.4 需求變更影響因素分析

借助軟件工具，經(jīng)過一段時間的積累和總結(jié)，可以從變更類型、變更原因、變更源三個方面來分析需求變更。變更類型包括：新增需求、刪除需求、修改需求。變更原因可分為：缺陷修復、遺漏需求、功能增強、產(chǎn)品策略、設計改進、范圍縮減、冗余功能、荒廢的功能、錯誤的需求、解決沖突……變更源是變更的來源，它包括：缺陷報告、工程要求、項目經(jīng)理、市場部門、開發(fā)人員的分析、設計評審反饋、技術組討論、客戶討論反饋。如圖4所示。

圖 4 變更分類分析

收集從門診醫(yī)生站試運行階段（2008年5月～2009年2月）采集到的需求變更數(shù)據(jù)，按照上面的變更分類，可以得到表3的數(shù)據(jù)，在這一階段內(nèi)處理的105次的需求變更中，有35次（33%）變更都是因為程序運行錯誤，針對這一原因應當提高設計的質(zhì)量，加強測試的力度。有23次（22%）是界面和易用性方面的問題，針對這一原因應當增強與使用人員的溝通，細化需求分析等。這個周期內(nèi)影響需求穩(wěn)定性的因素大都來自于設計的改進，可以針對影響需求穩(wěn)定性的根源采取適當?shù)拇胧?。這種方法使項目組能夠有效地定位變更的原因，能夠有的放矢地減少需求變更所帶來的負面影響。

表 3 需求變更數(shù)據(jù)分類統(tǒng)計

5 總結(jié)

醫(yī)院信息系統(tǒng)化過程對所有參與者都是一個反復學習、迭代開發(fā)的過程。在醫(yī)院信息系統(tǒng)開發(fā)中，各利益方對系統(tǒng)開發(fā)的參與都是通過對軟件需求的表達來實現(xiàn)的，因此系統(tǒng)需求是整個開發(fā)過程中的核心線索，而對需求進行管理是協(xié)調(diào)信息系統(tǒng)質(zhì)量、成本和時間之間復雜關系的必由之路。做好系統(tǒng)需求及其變更的管理，既可以減少信息系統(tǒng)開發(fā)中的錯誤，又可以減少頻繁需求變更對系統(tǒng)開發(fā)的影響，從而降低系統(tǒng)開發(fā)成本，縮短開發(fā)時間。實踐證明，良好的需求管理對于降低系統(tǒng)開發(fā)成本和保障項目成功至關重要。

本文針對當前醫(yī)院信息系統(tǒng)項目的特點以及信息化項目在需求管理方面薄弱的現(xiàn)狀，利用軟件開發(fā)過程、需求工程的相關理論創(chuàng)建這類項目規(guī)范的需求管理過程，提出了基于RUP的需求管理模型, 把過程化的思維引入到需求管理中。與RUP 需求管理過程過于復雜相比, 提出的需求管理過程具有定義清晰、概念完整、可度量且易于操作等突出特點。在實際項目應用中, 有效抑制模糊需求、矛盾需求和變化需求等對軟件開發(fā)過程產(chǎn)生的不良影響, 規(guī)范整個項目的需求管理, 提高了需求管理的效率和效果。在信息系統(tǒng)更好地為醫(yī)院運營服務、為醫(yī)院創(chuàng)造價值，提高醫(yī)院對信息化產(chǎn)品的滿意度等方面，具有十分重要的現(xiàn)實意義。

[1] 李包羅.我國醫(yī)院信息系統(tǒng)面臨七大挑戰(zhàn)[J].中國電子商務, 2004(5):61-62.

[2] 張建成,田青,史艷華,等.應用軟件工程需求管理與范圍管理的差異性分析[J].信息技術與信息化,2008(1):41-43.

[3] 裴生雷.基于UML和RUP的信息系統(tǒng)需求分析[J].福建電腦, 2006(12) :124-125.

[4] 王莉,吳潔明.軟件項目中的需求變更管理的研究[J].計算機技術與發(fā)展,2007(1):119-120.

[5] 彭德良.基于RUP的統(tǒng)一變更管理[J].科學技術與工程,2007 (8):1762-1766.

[6] 王麗姿,劉子先,張建寧.基于BPR理論的醫(yī)院工作流程再造[J].中華醫(yī)院管理雜志,2006(3):204-207.

[7] 姜欣.基于UML的軟件需求方法分析[J].信息技術教學與研究, 2007(26):107-108.

[8] (美)杰克.T.馬丘卡.許江林,梁銅毓,劉景梅,譯.信息技術項目管理[M].第2版.北京:電子工業(yè)出版社.2007:85.

[9] 呂瀟,吳超英,王倩.迭代開發(fā)中需求管理技術的研究與應用[J].微計算機信息,2008(3):191-193.

[10] (德)Becker,J.劉祥艷,薄玉秋,譯.業(yè)務流程管理[M].北京:清華大學出版社,2004:18-30.

[11] 王堅,戴毅如,凌衛(wèi)青.柔性業(yè)務過程管理體系與方法[M].北京:電子工業(yè)出版社,2008:189-197.

[12] 王強.軟件開發(fā)項目中的需求變更管理[J].電腦知識與技術, 2007(6):168-169.

Research and Practice of RUP-based Requirement Management of Hospital Information System

LI Wei
Information Management Center,Peking University Third Hospital,Beijing 100191, China

R197.324；TP311.52

B

10.3969/j.issn.1674-1633.2010.04.017

1674-1633(2010)04-0043-04

2009-10-30

作者郵箱：liwei3@126.com

Abstract:Contraposing the current hospital information system characteristics and construction process of weak requirement management situation，this paper proposes a model of the RUP-based with the process of thinking being introduced into the requirement management. The whole requirement management process is divided into three stages: the preparation stage，analysis and definition stage, maintenance phase. A process model of requirement determine, validation, change control, tracking and adjustment is established, and proved in a practical application of projects.

Key words:hospital information system(HIS);requirement management;process model