伊永菊，黃蓓麗，王文輝

中山大學(xué)附屬第六醫(yī)院 信息網(wǎng)絡(luò)中心，廣東 廣州 510655

基于CMMI的醫(yī)院信息系統(tǒng)需求管理

伊永菊，黃蓓麗，王文輝

中山大學(xué)附屬第六醫(yī)院 信息網(wǎng)絡(luò)中心，廣東 廣州 510655

需求管理貫穿于整個軟件需求工程之中，也是軟件能力成熟度集成模型（CMMI）中關(guān)鍵的過程域。針對當(dāng)前醫(yī)院信息系統(tǒng)（HIS）的特點(diǎn)以及項(xiàng)目實(shí)施過程中需求管理方面薄弱的現(xiàn)狀，本文以CMMI的需求管理為理論基礎(chǔ)，把過程化的思維引入到需求管理中，結(jié)合需求管理流程設(shè)計了需求管理體系。以此作為構(gòu)建HIS項(xiàng)目需求管理模式的基礎(chǔ)，提出了以需求評審、建立功能基線、需求變更控制、需求跟蹤為基本活動內(nèi)容的HIS需求管理過程模型，并在實(shí)際項(xiàng)目中將需求分類為出錯性需求和功能性需求，進(jìn)一步對模型進(jìn)行了改進(jìn)與完善。

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

0 引言

醫(yī)院信息系統(tǒng)（Hospital Information System，HIS）通過計算機(jī)網(wǎng)絡(luò)將醫(yī)院事務(wù)統(tǒng)一到一個平臺，規(guī)范醫(yī)療流程，增強(qiáng)了患者和醫(yī)院之間的信任度[1]。但是，許多醫(yī)院的HIS項(xiàng)目實(shí)施并不順利，矛盾的焦點(diǎn)多集中在醫(yī)院的個性化現(xiàn)場需求[2]。一方面，HIS項(xiàng)目實(shí)施中存在著“甲方想做好、乙方想做少、現(xiàn)場乙方員工想省事”的現(xiàn)實(shí)問題，HIS供應(yīng)商盡量回避醫(yī)院的需求；另一方面，醫(yī)院需求具有特殊性，需求變更頻繁，且由于知識鴻溝等客觀因素臨床科室不會去考慮需求的合理性。因此，醫(yī)院與HIS供應(yīng)商之間建立完整、清晰和穩(wěn)定的需求，是軟件用戶獲取高質(zhì)量軟件的有效手段。

醫(yī)院信息化項(xiàng)目實(shí)施周期長、涉及部門眾多，相對于其他行業(yè)的信息化進(jìn)程而言，具有較大的復(fù)雜度[3]。醫(yī)院信息化建設(shè)的成功更需要有效的需求管理。

1 HIS需求管理的意義

軟件需求是利益相關(guān)者對于未來系統(tǒng)的期望。需求分析是軟件生命周期的第一個階段，需求管理貫穿于整個軟件生命周期[4]。

醫(yī)院信息化建設(shè)是一個逐步演進(jìn)、螺旋上升的過程，HIS的需求是隨著人們對信息化的體驗(yàn)和觀念的轉(zhuǎn)變而不斷更新，環(huán)境的改變、技術(shù)的演進(jìn)和醫(yī)院的發(fā)展等因素都會引發(fā)新的HIS需求。

需求變更對醫(yī)院信息化的影響可以概括為以下3個方面：① 大量頻繁的需求變更會極大地加大項(xiàng)目的人員、費(fèi)用開支，需求以失控的狀態(tài)進(jìn)入軟件過程，可能直接導(dǎo)致項(xiàng)目的失?。虎?在一個復(fù)雜的信息系統(tǒng)中，需求之間具有一定的內(nèi)在聯(lián)系，而相關(guān)的需求則構(gòu)成需求鏈。如果遺漏需求鏈中的某些環(huán)節(jié)，就可能在實(shí)施變更過程中引入一些難以察覺的錯誤，將從源頭上失去了項(xiàng)目的質(zhì)量保證，嚴(yán)重時可導(dǎo)致系統(tǒng)崩潰；③ 需求變更的實(shí)施是醫(yī)院信息部門、軟件供應(yīng)商與一線用戶相互協(xié)作的過程。軟件供應(yīng)商和用戶在是否采用變更問題上常常產(chǎn)生分歧，此時需要信息部門協(xié)調(diào)，如果處理不當(dāng)，使組織處于被動反應(yīng)式的環(huán)境中，士氣低落，增加了項(xiàng)目的失敗風(fēng)險。

因此，醫(yī)院信息部門需要有科學(xué)的方法管理這些需求，使之能逐步實(shí)現(xiàn)，不斷完善信息系統(tǒng)，促進(jìn)醫(yī)院業(yè)務(wù)流程變革，使醫(yī)院業(yè)務(wù)和軟件功能逐步達(dá)到趨同。

2 需求管理模型

能力成熟度模型集成（Capability Maturity Model Integration，CMMI）是由卡耐基梅隆大學(xué)軟件工程研究所所提出的軟件過程能力成熟度模型，已逐步成為IT業(yè)的標(biāo)準(zhǔn)，該模型按軟件過程的不同成熟度劃分了5個階段等級，其中1級成熟度最低，5級成熟度最高，從2級到5級包含25個過程域[5]（2級7個、3級14個、4級2個、5級2個）。需求管理屬于成熟度2級過程域，是其他許多過程域?qū)嵤┑那疤帷?/p>

需求管理是CMMI2的第1個關(guān)鍵過程域。其特定目標(biāo)為：管理需求、標(biāo)識需求和項(xiàng)目計劃及工作產(chǎn)品的不一致性。其對應(yīng)的特定實(shí)踐包括獲得對需求的理解；獲取項(xiàng)目參與者對需求的承諾；管理需求變更；維護(hù)對需求的雙向可追溯性和標(biāo)識項(xiàng)目計劃和工作產(chǎn)品與需求的不一致性[6]。

基于CMMI2級需求管理過程框架包括4個過程：①需求評審；② 建立功能基線；③ 控制需求變更；④ 需求追蹤。

需求評審是需求確認(rèn)的主要手段，確認(rèn)需求是否具有完整性、可行性、無歧義性和可驗(yàn)證性等特征。需求評審是為了及時找出需求中潛在的問題，然后與相關(guān)的組就需求進(jìn)行協(xié)商，從而得到約定。

評審?fù)ㄟ^的需求應(yīng)當(dāng)形成功能基線，納入需求管理庫[7]。功能基線是項(xiàng)目后續(xù)開發(fā)的依據(jù)和需求管理的基礎(chǔ)，且功能基線只有通過正式的變更控制規(guī)程才可以更改。

控制需求變更是指對需求從提出變更申請、變更評估到變更的具體實(shí)施進(jìn)行控制的過程。它通過對功能基線實(shí)施配置管理來完成，需求變更活動的實(shí)施遵循CMMI2級配置管理過程中對變更控制活動的要求。

需求跟蹤使得每一項(xiàng)需求均能追溯到相應(yīng)的設(shè)計、代碼和測試用例，同時各階段的工作產(chǎn)品也能反向追溯到初始的需求[8]。需求跟蹤的目的是建立與維護(hù)需求、設(shè)計、編程、測試之間的一致性, 確保所有的工作成果符合用戶需求。

3 HIS需求管理的實(shí)現(xiàn)方案

3.1 現(xiàn)場需求

CMMI2 對需求管理過程域第一個特殊實(shí)踐“獲得對需求的理解”的表述為：隨著項(xiàng)目的進(jìn)展，所有的活動或領(lǐng)域都會接收到需求，為了避免需求蔓延，要建立標(biāo)準(zhǔn)來指定接收需求的正式途徑。接收需求的活動是引導(dǎo)需求提供者共同進(jìn)行需求分析以確信對需求性質(zhì)和含義的理解達(dá)到共識。

HIS實(shí)施現(xiàn)場的需求復(fù)雜而緊急[9]，根據(jù)需求的性質(zhì)，將需求分類為出錯性需求和功能性需求。出錯性需求是指系統(tǒng)Bug、邏輯錯誤和數(shù)據(jù)錯誤；功能性需求是指系統(tǒng)功能增加、功能優(yōu)化和流程改造。

以我院的信息化建設(shè)為例，按照醫(yī)院HIS實(shí)施現(xiàn)場的實(shí)際情況，現(xiàn)場需求評審?fù)ㄟ^后，信息部門將需求分為出錯性需求和功能性需求，出錯性需求的優(yōu)先級一般高于功能性需求的優(yōu)先級。

現(xiàn)場需求的來源是多方面的，如用戶抱怨、患者投訴、部門建議、各種協(xié)調(diào)會議等，需求的采集不僅僅是收集，更重要的是識別[10]。為了避免需求泛濫，所提出的需求必須是明確的、形式化的，這就需要在收集需求的源頭控制規(guī)范需求的產(chǎn)生過程。我院HIS需求申請單，見表1。

表1 我院醫(yī)院信息系統(tǒng)需求申請表

3.2 HIS需求管理模型

根據(jù)CMMI2級需求管理過程框架要求和HIS需求的特殊性，我院信息科提出了出錯性需求管理模型和功能性需求管理模型。這兩個需求管理模型均符合需求評審、建立功能基線、控制需求變更和需求追蹤4個過程。出錯性需求管理模型，見圖1?？剖倚枨蠼涌谌颂岢鲂枨?，科室負(fù)責(zé)人審批，信息部門審批，軟件開發(fā)組評審并開發(fā)，信息部門組織測試，測試通過后由軟件開發(fā)組備份并更新版本。由于出錯性需求的優(yōu)先級是最高的，處理流程相對簡單，處理周期較短。自2012-9-29至2013-12-31，共收集出錯性需求899條，目前未處理的出錯性需求82條。

圖1 出錯性需求管理模型

圖2 功能性需求管理模型

功能性需求管理模型，見圖2。科室需求接口人提出需求，科室負(fù)責(zé)人審批，相關(guān)主管部門審批，信息部門審批后需要需求相關(guān)部門協(xié)調(diào)確定方案，軟件開發(fā)組評審并開發(fā)，信息部門組織測試，測試通過后由軟件開發(fā)組備份并更新版本。由于功能性需求大部分是醫(yī)院個性化需求，涉及醫(yī)院業(yè)務(wù)流程重整，一般處理周期較長。自2012-9-29至2013-12-31，共收集功能性需求1153條，目前未處理的功能性需求213條。

4 結(jié)論

在醫(yī)院信息化建設(shè)過程中各利益方對系統(tǒng)開發(fā)的參與都是通過對軟件需求的表達(dá)來實(shí)現(xiàn)的，因此系統(tǒng)需求是整個開發(fā)過程中的核心。本文提出基于CMMI級的需求管理過程模型，該模型給軟件組織的需求管理提供了具體的過程指南，應(yīng)用該模型可以解決軟件組織在需求管理中存在的主要問題。同時，本文也給出了該模型的具體實(shí)現(xiàn)方案，并以此實(shí)現(xiàn)方案為基礎(chǔ)實(shí)現(xiàn)高效的HIS出錯性需求管理和功能性需求管理，有效地控制需求變更給醫(yī)院信息化建設(shè)過程帶來的影響。

下一步將進(jìn)一步完善該模型，使其適應(yīng)需求管理發(fā)展的需要，并進(jìn)一步分析899條出錯性需求和1153條功能性需求的分布情況，以醫(yī)院信息化建設(shè)帶動醫(yī)院業(yè)務(wù)流程的協(xié)調(diào)性，實(shí)現(xiàn)信息系統(tǒng)更好地為醫(yī)院運(yùn)營服務(wù)、為醫(yī)院創(chuàng)造價值，提高醫(yī)院對信息化產(chǎn)品的滿意度。

[1] 李鵬.對我國醫(yī)院信息化建設(shè)面臨問題的思考[J].中國病案,2013, 14(6):37-39.

[2] 付云.我國醫(yī)院信息化現(xiàn)狀分析及發(fā)展對策[J].醫(yī)學(xué)信息,2010, 23(3):563.

[3] 李維.基于RUP的醫(yī)院信息系統(tǒng)需求管理研究與實(shí)踐[J].中國醫(yī)療設(shè)備,2010,(4):43-45.

[4] Elizabeth M,Hull C,Ken Jackson,et al.需求工程[M].北京:清華大學(xué)出版社,2003.

[5] Suzanne Robertson,James Robertson. Mastering the requirements process[M].北京:人民郵電出版社,2003.

[6] Dean Leffingwell,DonWidrig.Managing software requirements:Ause case approach[M]. 2版.北京:中國電力出版社,2004.

[7] 王勇,張發(fā)勇,周順平.CMMI軟件配置管理的理論與實(shí)踐[J].計算機(jī)工程與應(yīng)用,2004,(23):105-107.

[8] 蘇秦,何進(jìn).軟件質(zhì)量過程[M].北京:科學(xué)出版社,2008:176-187.

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

[10] 羅云模,謝志敏.CMMI軟件過程改進(jìn)與評估[M].北京:電子工業(yè)出版社,2004:104-187.

Research on HIS Requirement Management Based on CMMI

YI Yong-ju, HUANG Bei-li, WANG Wen-hui
Information Network Center, the Sixth Affiliated Hospital of Sun Yat-sen University, Guangzhou Guangdong 510655, China

Requirement management runs throughout the software requirement engineering and it is also an important process area in CMMI (Capability Maturity Model Integration). Contraposing the current HIS (Hospital Information System) characteristics and weak requirement management during the project implementation process, this paper proposed a CMMI-based model and introduced the processoriented thinking into the requirement management, which was divided into four process models: reviewing requirement, baseline, change control, tracking and adjustment. In practice, the error handling requirement process model and functional requirement process model were established for further improvement of the model.

hospital information system; requirement management; process model; error handling requirement; functional requirement

R197.3；R197.324

C

10.3969/j.issn.1674-1633.2016.06.049

1674-1633(2016)06-0159-03

2015-07-02

2015-07-10

王文輝，高級工程師，中山大學(xué)附屬第六醫(yī)院信息網(wǎng)絡(luò)中心主任。

作者郵箱：chujv29292929@126.com