1、精選優質文檔-傾情為你奉上課程名稱： 軟件工程 實驗項目：患者監護體統實驗報告 實驗地點： 專業班級： 學號： 學生姓名： 指導教師： 年 月 日可行性分析1.可行性研究的前提說明對所建議開發的軟件的基本要求，如：A. 功能：監護系統要隨時接受每個病人的生理信號(脈搏、體溫、血壓、心電圖等)，定時記錄病人情況以形成患者日志，當某個病人的生理信號超出醫生規定的安全范圍時向值班護士發出警告信息；此外，護士在需要時還可以要求系統打印出某個病人的病情報告。B. 性能：1、本系統要求反應時間不得低于2s.2、定期對數據庫備份C. 輸出如報告、文件或數據：本系統要求輸出的數據有：查詢信息、報表、警報控制信

2、號D 在安全與保密方面的要求：掛號科的工作人員負責病人基本信息的輸入，住院部的醫護人員負責病人住院日志的情況，管理員負責系統的維護2.技術可行性a 經費、投資方面的來源和限制：各種硬件和工作人員工資需至少10萬元b 硬件、軟件、運行環境和開發環境方面的條件和限制：軟件需求：操作系統WINDOWS 2000 Advance Server以上；數據庫服務器端軟件ORACLE 9I， Delphi 7.0。硬件需求：10M以上的LAN接入網絡帶寬，P4 3.0G Xeon CPU /1G內存/360G(10K) SCSI硬盤的服務器，P3以上微機（帶網卡）的客戶機，P4 3.0G Xeon CPU

3、/1G內存/36G(10K) RAID硬盤的數據庫服務器本系統采用Delphi 實現，依靠其強大的控件系統，Oracle數據庫管理系統和用c語音編制的傳感器驅動相結合，能在2個月內開發出系統。3.經濟可行性某醫院目前由于完全采用純人工的方式來完成工作的，醫務人員要一邊關注某些病人的情況，一邊還要忙著對其它的病人進行醫療診斷，工作量大，耗時比較多，所以工作效率低。根據目前醫院內部員工的日人工成本為：x人 * y元/人z元。我們還不能計算出因效率低下而給醫院帶來的無形經濟損失，如果指導這一部分也看作是成本，那將遠遠超出目前的計算數額。而如果開發出一個能滿足業務要求的醫療計算機監護系統，在采用生命周

4、期的前提下，從問題識別到系統實施、評價、維護，開發周期如果以兩年計，共需人工成本m元，各種軟硬件成本n元，日常維護費用o元，共計成本費用p元，略高/低于兩年的人工費用總和。同樣，我們也無法估計算出則于系統的開發應用使醫院運營效率提高而帶來的無形的巨額經濟效益，由于系統能在未來較長的一段時間內穩定地發揮作用，這對于醫院的提高管理水平很大的幫助，才能使A醫院早日接入到總行的更高層次的網絡體系中，可以更加廣泛的吸收各方面的信息資源，可為醫院業務在將來的擴張打下堅實的基礎，其經濟效益將更上一層樓。4.法律可行性法律可行性是考慮要開發系統是否存在任何侵犯、妨礙和責任問題，用戶操作可行性考慮待開發軟件的運

5、行方式在用戶組織內是否行得通，現行管理制度、人員素質、操作知識是否可行。由于在本系統中是有合同作為雙方合作的基礎，所以不會存在任何侵犯、妨礙和責任問題。即使存在了，也可以根據合同進行分析，一定有人會負責任，所以此系統完全可以進行開發。由以上經濟、技術、操作和法律四方面的分析可以看出，本系統的開發時機成熟，從多種角度考慮，都是可行的。5結論本系統值得投資。患者監護系統需求分析報告一、問題定義1、待開發的軟件系統的名稱：患者監護系統。2、整體描述：通過患者監護系統隨時接收患者的生理信號定時形成患者日志，當超出限定范圍時向值班護士發出警告，以便及時發現病情。另外，在需要時導出病人的病情報告，方便隨時

6、了解病人情況。3、系統功能目標：系統能夠隨時接收病人的生理信號（血壓、體溫、脈搏、心電圖等），監視病員的病癥；定時記錄病人情況以形成患者日志（定時更新病歷）；當某個病人的生理信號超出醫院的規定的安全范圍時向值班護士發出警告信息（病員出現異常情況時報警）；同時，護士在需要時還可要求系統打印某個病人的病情報告（隨機地產生某一病員的病情報告）。4、技術要求和限制條件 (1)當病人的生理信號發生變化時，都應增加相關病人病歷庫的記錄； (2)系統的外部項至少包括：病人、護士。二、需求分析1、功能需求：1.1功能的劃分： 把系統劃分為接收信號階段、信號分析階段和產生日志和病情報告階段的功能。1.2功能描述

7、：1、接收信號階段：病人發出生理信號進行接收，按照時鐘定時取樣。2、信號分析階段：通過和系統中的正常信號范圍比較分析，得到警告信息或輸出正常。3、產生日志和病情報告階段：系統根據分析情況輸出相應的報告結果。交給值班護士2、性能需求：2.1系統基本要求：響應時間：系統的響應時間不能超過1分鐘警告時間及次數：每隔三分鐘重復警告一次，每次警告時間持續一分鐘。主存容量：內存：128MB RAM 磁盤容量：不小于顯示器：256色,800*600以上的兼容顯示器 使用標準兼容的打印機。2.2數據管理能力要求 說明需要管理的文卷和記錄的個數、表和文卷的大小規模，要按可預見的增長對數據及其分量的存儲要求作出估

8、算。 2.3故障處理要求 列出可能的軟件、硬件故障以及對各項性能而言所產生的后果和對故障處理的要求。輸出發生錯誤時，在系統的代碼部分進行修改。3、外部接口說明3.1界面布局屏幕布局： 頂端上分布菜單欄（設置各種功能按鈕），中間部分為操作的輸出預覽。如：輸出病人的心電圖生理信號時輸出波形圖，輸出病人日志和病情報告時輸出預覽的圖表格式。菜單布局：在屏幕上端設置功能按鈕，按鈕上簡練標志操作功能。輸入輸出要求；對脈沖等數字的信號定義為精度為2的小數并用表格的格式分類表示（范圍是0-100）；而對于心電圖等需要波形的圖要用波形圖軟件導出。日志和病情報告將日期（如2008-10-28）、病人基本情況（表格

9、）形式輸出。錯誤信息顯示格式； 在中央出現并閃爍對話框同時發出警告聲，提示存在錯誤。讓用戶選擇重試或者關閉此次操作。3. 2存儲位置和輸出情況關于病情報告的信息全部放在病情報告的文本框里。信息格式是表格描述，各問題的解答都放在幫助中，信息格式用文檔寫出。用表格的形式打印病人的日志，包括姓名、時間、各器官生理信號，并用圖表的形式畫出波形圖。給出各范圍內信號的值，并作出相應的評價。4、分析數據要求導出系統的物理模型：分析數據對各數據及模塊進行分析，畫出IPO圖、E-R圖及狀態圖如下：4、1各數據的數據字典IPO表系統：患者監護系統 作者：模塊：接收信號 日期：編號： 01 被調用：接收信號系統 調

10、用：生理信號輸入：患者生理信號 輸出：系統識別的生理信號處理：將接收的患者生理信號轉化為系統識別的生理信號并輸出局部數據元素：患者生理信號 注釋：接收信號模塊的IPO圖IPO表系統：患者監護系統 作者：模塊：信號分析 日期：編號： 02 被調用：信號分析系統 調用：生理信號輸入：患者生理信號 輸出：病人危機信號（或正常信息） 處理：將接收的患者發出的生理信號與系統的生理信號范圍并輸出相應結果局部數據元素：患者生理信號 注釋：信號分析的IPO圖IPO表系統：患者監護系統 作者：模塊：發出警告 日期：編號： 03 被調用：警告系統 調用：病人危急信息輸入：患者警告信息 輸出：警告聲響 處理：接收患

11、者的警告信息通過系統發出警告聲響局部數據元素：患者警告信息 注釋：發出警告的IPO圖IPO表系統：患者監護系統 作者：模塊：定時取樣 日期：編號： 04 被調用：定時取樣系統 調用：設定時刻輸入：某一時刻患者生理信號 輸出：系統識別的生理信號處理：將某一時刻接收的患者的生理信號轉化為系統識別的生理信號并輸出局部數據元素：患者生理信號 注釋：定時取樣的IPO圖IPO表系統：患者監護系統 作者：模塊：更新日志 日期：編號： 05 被調用：更新日志系統 調用：生理信號輸入：患者生理信號 輸出：患者日志 處理：將接收的患者生理信號輸出為患者日志局部數據元素：患者生理信號 注釋： 更新日志的IPO圖IP

12、O表系統：患者監護系統 作者：模塊：產生病請報告 日期：編號： 06 被調用：產生病情報告系統 調用：患者日志輸入：患者日志 輸出：病情報告 處理：將患者日志批量處理輸出病情報告局部數據元素：患者日志 注釋：產生病情報告的IPO圖4.2系統的實體聯系圖患者產生日志產生病情報告分析護士分析患者號姓名房間號性別姓名日志號日期所屬患者姓名護士號患者監護系統的圖4.3系統狀態圖閑置取樣定時檢測分析信號判斷是否超出范圍警告發出聲響護士查看結束更新日志更改患者日志產生報告輸出病情信息生理信號時鐘危急信息警告信息病情報告患者監護系統狀態圖軟件結構：系統的數據流程分析當用戶進入醫院門診管理信息系統時，首先會員

13、需要登陸系統或者新用戶需要注冊相關信息。在新用戶注冊信息時，需認真填寫注冊信息，如果出現重名現象，需要重新填寫用戶名。會員登陸后可以預約門診，系統處理用戶的預約信息。醫院管理人員可以編輯醫生信息和科室信息，查看預約門診數據，這些信息將返回到醫生信息中，并且系統根據這些信息處理用戶的預約。系統的數據流程圖如圖2所示。5、修正系統開發計劃數據精度應達到兩個小數點以后，心電圖的圖形界面應該更清晰的寫出時間、正常范圍。在原有開發計劃的基礎上重點進行接口的實現，人機界面的數據設計、體系結構設計和界面的友好性需要進一步提高需要進一步設計系統的具體實現方案。患者監護系統總體設計說明書1.1需求規定醫院計算機

14、監護系統:監護系統要隨時接受每個病人的生理信號(脈搏、體溫、血壓、心電圖等)，定時記錄病人情況以形成患者日志，當某個病人的生理信號超出醫生規定的安全范圍時向值班護士發出警告信息；此外，護士在需要時還可以要求系統打印出某個病人的病情報告。1.2運行環境本系統是基于C/S模式的采用Delphi實現的管理信息系統（Management Information System）。數據庫服務器由Oracle9實現。為使系統能夠正常運行，軟硬件環境需求如下：軟件需求：操作系統WINDOWS 2000 Advance Server以上；數據庫服務器端軟件ORACLE 9I， Delphi 7.0。硬件需求：1

15、0M以上的LAN接入網絡帶寬，P4 3.0G Xeon CPU /1G內存/360G(10K) SCSI硬盤的服務器，P3以上微機（帶網卡）的客戶機，P4 3.0G Xeon CPU /1G內存/36G(10K) RAID硬盤的數據庫服務器1.3基本設計概念和處理流程系統流程圖如下：系統數據流圖如下：1、頂層數據流圖：查詢病人信息記錄病人情況醫院計算機監護系統傳感器護士打印報告護士患者日志輸入：輸出：輸入病人生理信號發出報警信號查詢結果2、各模塊數據流圖1.4結構醫院病人監護系統生理信號輸入控制子系統病人基本信息管理子系統警報子系統病人病情管理子系統生理信號輸入管理定時時間調節信息輸入信息修改

16、信息查詢生理信號安全范圍控制警報病情查詢病情報告打印1.5人工處理過程1、傳感器輸入信號間隔時間由用戶輸入2、生理信號安全范圍需要用戶輸入2接口設計2.1用戶接口本系統的用戶界面如下所示菜單快捷功能鍵區 用戶輸入界面（系統顯示界面）提交區3.2外部接口 本系統采用C/S模式，由Delphi實現的管理信息系統（Management Information System）。通過ADO連接與數據庫服務器相連。3系統數據結構設計3.1邏輯結構設計要點給出本系統內所使用的每個數據結構的名稱、標識符以及它們之中每個數據項、記錄、文卷和系的標識、定義、長度及它們之間的層次的或表格的相互關系。4系統出錯處理設

17、計 4.1補救措施1. 聯機事務處理(OLAP)是建立在TCP/IP 協議上，有多階段事務處理響應控制，保證事務處理前后臺一致性。2. 數據庫處理事務失敗自動回滾技術，保證數據庫表的數據一致性和完整性。3. 重要數據的校驗檢查。4. 各個子系統的操作監控，異常情況報告；并提供報表等跟蹤記錄。5. 提供友好的用戶界面和幫助信息及配合嚴格的檢查，減少用戶出錯機會。 詳細設計說明書1 引言1.1 編寫目的 在完成了患者監護系統的可行性研究、需求分析和概要設計的基礎上，為了進一步實現將軟件需求和各項功能具體化，提出了這份詳細設計說明書。此詳細設計說明書對患者監護系統的解決方案，功能分配，模塊化分，總體

18、結構，輸入輸出和各模塊間接口設計，運行設計及出錯設計等方面作了全面的具體詳盡的說明，作為軟件測試人員及軟件維護人員進行測試及維護時的參照。預期讀者：設計和編碼人員、測試人員、醫院計算機網絡系統管理和維護人員。1.2 背景 醫院是一個與人民生命安全密切相關的重要機構，在高度信息化的今天，人們對醫療衛生的要求也越來越高。為了隨時觀察危重病人的病情變化，抓住時機及時搶救，也為了減少醫院護士的人數和工作量，醫院迫切需要一個患者監護系統。醫療病房監護系統便是以計算機為工具，通過對病人病情的信息進行處理，不僅把護士從繁瑣的行走奔波中解脫出來，而且醫生能夠迅速的對癥下藥，并且優化了醫療體系，使其高效化，簡易

19、化，智能化，也提高了透明度和互動性。u 項目名稱：患者監護系統u 本項目的任務提出者：某醫院u 本項目的開發者：浙江大學生醫 05 級學生周慧娟、徐白露、盧曉萍u 將運行此監護系統的計算機網絡系統：某醫院的網絡系統u 本系統擬定的用戶：各大醫院重癥監護病房的值班護士及其網絡維修中心的相關人員u 該患者監護系統從病情檢測系統獲取患者生理信息，向病情診斷系統和病情緊急處理系統傳送信息，為醫院各重癥科系的醫生提供診斷依據，同時也減少醫護人員每天的額工作量1.3 定義本患者監護系統在開發時注意到使用專業術語會對今后的系統使用者造成不變，故而所有相關詞匯使用了簡潔并通俗易懂的詞匯，系統使用者不會出現此系

20、統詞匯看不懂的問題，故而在此對系統及文件使用的相關詞匯不作任何定義。3 程序設計說明從本章開始，逐個地給出各個層次中的每個程序的設計考慮。3.1 主窗體3.1.1 程序描述本程序實現的模擬醫院的監護系統，實時地監測 ICU 病房的患者的生理信號，動態的生成患者日志、可選擇病人及不同的時間段監測的數據進行打印。當患者的生理信號超過正常的界限時，產生警報，傳給醫生和護士。3.1.2 功能實時地監測 ICU 病房的患者的生理信號，包括心電信號、體溫、脈搏、收縮壓、舒張壓、呼吸頻率等的動態監測全方位地觀察地病人生理變化。動態的生成患者日志、可選擇病人及不同的時間段監測的數據進行打印。當 ICU 監護系

21、統對應的床位中有病人，則可以進行監護，否則可以添加完病人后，開始進行監測。同時，當 ICU 監護系統中的病人要退出 ICU 病房，則可以進行移出 ICU 病房。也可以在主窗體查看病病人的詳細信息。主要數據傳遞過程如下圖：3.1.3 性能開始監護：病人已連接到該 ICU 病床，可以啟動監護系統，接受由傳感器等其它硬件系統傳來的生理數據，開始動態的監測各個病人的各項生理指標。暫停監測：當病人進行其它活動（如戶外活動等）而暫停監護，并不移除該患者在這個監護系統上相應的信息，可隨時回來再進行監護。病人信息：方便醫生護士查閱相應監護病床上的相應患者，展示了病人的基本信息及主要病癥信息。生成日志：當有進行

22、監護時，可實時地生成相應的患者日志，供醫生和護士查閱,并且可根據時間、患者來選擇打印所需的報告。添加病人：和醫院的病人管理系統實現互相調用。當有病人需要進行監護時，可從醫院的信息中心調入相應的信息，無需再人工進行輸入。移出病人：當病人不需要再進行監護時，可移出 ICU 病房，空出的監護床位可以等待下一個監護患者入住。報警信號：當進行監護的病人，其生理信號超過設置的安全界限時，響應出相應的警報信息。如體溫35 、舒張壓60、脈搏37.5、收縮壓140、脈搏90 時相應的數值顏色為紅色，表示該項生理信號過高。3.1.4 輸人項及其輸出項a.任意選擇已有監護病人的 ICU 病床，點擊開始監護，進行監

23、護狀態；點擊暫停監護，則進入暫停監護的狀態；點擊病人信息，可查看相應病人信息；點擊移除病人，可將改病人從 ICU 病房調出，停止對其監護。b.若選擇沒有病人的 ICU 病床，點擊添加，即可將醫院中其它需要進行重癥監護的病人，入住 ICU 病床，進行監護。c.開始監護后，心電信號以波形形式，實時的顯示在 ECGView 中，體溫以體溫計的形式，舒張壓、收縮壓、脈搏、呼吸頻率以數字的形式在顯示在數據框中（如上圖顯示）。其相應得到實時的生理信號，隨著監護的過程，實時保存在患者的病情數據庫中。 采樣時間、體溫、舒張壓、收縮壓、脈搏、呼吸頻率的等數據的類型和格式，數據值的有效范圍：3.1.5 算法由于我

24、們編寫的軟件沒有和實際的硬件設備相連接在一起，所以需要有模擬的實時生理信號的傳遞給患者監護系統，因此主要的生理信號的算法包括心電波形圖及體溫、舒張壓等生理信號的數據。a. 心電波形：（心電波形數據來源為心電實驗得到的，用 sql 在數據庫中讀取）with query1 dobeginclose;sql.Clear;sql.Add(select * from Heart.DB where時間:p1);ParamByname(p1).AsInteger:=n+1;prepare;open;end;b. 體溫、舒張壓、收縮壓、脈搏、呼吸頻率數據：beginfor j:=0 to 30 do begi

25、nshape201.height:= random(j)-110;shape202.top:=24+(shape201.height+110);TextStr1:=floattostr(shape201.height+465)/10);if (shape201.height-85)then begin /過低shape201.brush.color:=clgreen;shape202.brush.color:=clgreen;endelse begin/正常shape201.brush.color:=clyellow;shape202.brush.color:=clyellow;end;end

26、;Textdouble0:=Random;Textdouble1:=Random;TShouSuoYa:=10*(6*Textdouble1+8)+10*Textdouble0;TextStr3:=FloatToStrF(TShouSuoYa,ffFixed,3,0) ;LabelICU2_1.Caption:= TextStr3;beginif TShouSuoYa140thenLabelICU2_1.Color:=clred/該患者血壓不正常，收縮壓偏高!顯示為紅色else LabelICU2_1.Color:=clblack;end;Textdouble0:=Random;Textdou

27、ble1:=Random;TShuZhangYa:=10*(4*Textdouble1+5)+10*Textdouble0;TextStr4:=FloatToStrF(TShuZhangYa,ffFixed,3,0) ;LabelICU2_2.Caption:=TextStr4;beginifTShuZhangYa90thenLabelICU2_3.Color:=clred /該患者脈搏過快!顯示為紅色else ifTextStr221thenLabelICU2_4.Color:=clred /該患者呼吸過快!顯示為紅色else ifTHuXiPinLv=:rq1) and (日期=:rq1)

28、 and (日期=:rq1) and (日期=:rq1) and (日期=:rq1) and (日期=:rq2);ADODataSet1.CommandText:=str;ADODataSet1.Parameters0.Value:=date1-1;ADODataSet1.Parameters1.Value:=date2;ADODataSet1.Active :=true;ADODataSet1.Parameters0.Value:=date1-1;ADODataSet1.Parameters1.Value:=date2;dbchart1.Series0.DataSource:=ADOData

29、Set1;dbchart1.Series0.XLabelsSource:=時間;dbchart1.Series0.YValues.ValueSource:=體溫;dbchart2.Series0.DataSource:=ADODataSet1;dbchart2.Series0.XLabelsSource:=時間;dbchart2.Series0.YValues.ValueSource:=脈搏;dbchart3.Series0.DataSource:=ADODataSet1;dbchart3.Series0.XLabelsSource:=時間;dbchart3.Series0.YValues.V

30、alueSource:=收縮壓;dbchart4.Series0.DataSource:=ADODataSet1;dbchart4.Series0.XLabelsSource:=時間;dbchart4.Series0.YValues.ValueSource:=舒張壓;dbchart5.Series0.DataSource:=ADODataSet1;dbchart5.Series0.XLabelsSource:=時間;dbchart5.Series0.YValues.ValueSource:=呼吸頻率;詳細說明本程序所選用的算法，具體的計算公式和計算步驟。3.3.6 流程邏輯3.3.8 接口點擊

31、報警回顧，進入患者報警日志，可閱覽患者所有報警信號。點擊數據曲線回顧，可以查看相應選擇時間段，患者的生理信號變化曲線圖。3.3.9 限制條件程序未能實現自動管理數據的功能，使得病情數據庫存儲有一定的容量限制33.10 測試計劃能閱覽得到患者的報警生理信號的各項記錄，可根據時間選擇查看；能查看患者一天內各項生理信號的曲線圖。3.3.13 尚未解決的問題各項生理信號的曲線圖數據不能很好的顯示相應檢測階段的準確時間。3.4 系統設置系統設置包括密碼修改、用戶管理、退出系統3.4.1 程序描述密碼修改：本系統涉及到權限問題，管理員擁有所有權限，而其他用戶則不能進行修改用戶權限。權限設置主要是了安全保密

32、的因素考慮，保護患者的信息。用戶管理：系統管理員可以修改用戶，使某些用戶擁有操作病人監護系統的操作權限。退出系統：用戶退出應用程序，結束整個監護系統的運行。3.4.2 功能管理者可以修改用戶的密碼，可以設置是否允許使用者的登陸。用戶管理，可以增加刪除用戶退出系統，使用戶安全退出患者監護系統。3.4.3 性能密碼修改的窗體供管理者修改密碼。用戶管理可以增加刪除用戶。3.4.4 輸人項及輸出項輸入用戶名和原始密碼，輸入新密碼，修改生效后彈出確認對話框，否則修改無效提示修改無效并返回。3.4.5 算法修改密碼：form9.ADODataSet1.Edit;form9.ADODataSet1.FieldByName(PASSWORD).Text :=trim(edit2.Text);form9.ADODataSet1.Post;application.MessageBox(密碼已經修改，請記住新密碼,提示信息