【正文】 估價建議的信息系統的最好途徑是針對系統凈值(收入減去成本)估量正的和負的不確定利潤。當今許多復雜的，綜合的系統為公司的利益做出了重大的貢獻，而做到這樣程度是因為它們經歷了漫長的、不可捉摸和難以預見的道路。 (8)確定項目范圍 可行性研究組與信息服務人員以及用戶管理人員合作估計初步設計中所刻劃的系統的復雜程度。可行性研究組還應該調查商品軟件目錄，以便找到適合的可應用的軟件。通常以能最好地顯示出工作過程的方式來組織和提供這些圖。整理現有系統的資料：系統數據元報告標題 系統數據元日期系統標題 醫(yī)療信息系統標識 MLS目前的需要修改需要刪除更 新要求來源職責編號標題描述1名字患者住院表住院處2首字母“““3姓“AR““4子女數“AR““5性別男或女““6婚姻狀況AR““““ AR當需時 我們通過將系統簡化為輸入、處理和輸出等幾個基本組成部分來表示整理現有系統資料的工作過程。例如，一個名字一地址文件可以存儲在許多張35的卡片上，并且按名字的字母順序排列。如果一個建議的系統是改進一個現有的計算機信息系統，那么可行性研究組只需要保證現有資料的完整性和保持最新版本就行了。如果要求一個用戶代表既作為可行性研究組或項目組的組長而同時又要求他繼續(xù)履行業(yè)務領域的職責，那么該項目是肯定要失敗的。 用戶代表應該熟悉當前專業(yè)領域的所有工作，用戶經理、總經理助理，或專業(yè)領域分析員是合理的候選者，用戶的系統分析員，具有計算機信息處理基礎知識的情況已經越來越普遍了。 下述編號的活動與系統開發(fā)責任矩陣相對應。第二部分是系統的初步設計。第Ⅴ階段——實現后的評價。過去的情況是，用戶管理人員與信息服務開發(fā)組合作來完成系統的一般功能說明書，然后，由信息服務人員來進行系統開發(fā)?，F在，系統開發(fā)是各占50%的比例；因此，用戶管理人員應該非常熟悉系統開發(fā)的大體過程，特別應該熟悉他們單位自己使用的方法學。在開始了系統壽命期中的生產階段之后，提出(經常被忽略的)實現后的評價要求。它對于估價成本和利潤是必要的。 (1)提交服務請求提交服務請求說明了包括對受拒絕的請求再次請求處理的一種方法。 必須指定一個人擔任可行性研究組的組長，哪怕只是兩個人的可行性研究組也需要一個組長。有好些公司已經采用了一種政策，即自動地指派受系統影響最大的業(yè)務領域的經理作為可行性研究組和項目組的領導以后該經理將從原來的工作職責中解脫出來，而用他(她)的全部時間管理可行性研究(或項目)組。現有系統所形成的任何資料將給設計階段提供有價值的輸入(如果批準開發(fā)該系統)。一個人工系統所保存的文件數總是令人吃驚的，即便對于業(yè)務領域管理人員也是如此。然后用圖形描繪出各部分之間的邏輯關系。它們可以是由一些隨機事件、功能或按小的和大的周期來驅動的子系統，也可以是若干子系統；既可以是層次的，也可以是混合的。如果認為技術轉移是可行的，則可行性研究組說明怎樣使用這些技術以及為適應現有環(huán)境所要求的修改范圍。并對開發(fā)項目今后的每一個階段進行人力資源要求的估計(用戶，信息服務人員及其他人員)。評價信息服務項目的好處和價值是一個主觀的過程，它要求具有成本和利潤方面的實際的知識。為了便于理解不確定利潤(例如，增加服務，減少發(fā)票上的錯誤，加快周轉期等)，應該產生一個成本和收入的一覽報表。它還包括一般的系統設計和開始第Ⅱ階段(系統分析和設計)的一個框架。一旦項目獲如通行命令，則開始第Ⅱ階段—系統分析和設計。因為在第Ⅱ階段結束之前程序員實際上并不參與進來，所以可以將指定程序員一事推遲到第Ⅱ階段結束時再進行。究竟怎樣組成項目組為好，顯然要進行權衡。許多公司的經理人員有一種錯誤的概念，即如果將項目組人員增加一倍，那么完成項目的時間就應該減少一半。由于項目成員之間的關系復雜，因而使得生產效率降低。因此有必要簽署一個書面的人員委托書。在這種情況下，需要經理直接參與、定期督促和采取干預措施。（P114）相對的項目工作量 上端說明了由項目組(用戶和信息服務人員)和非項目組成員的用戶對項目工作貢獻的相對百分比。根據經驗，信息服務人員負責信息系統方面的培訓，而用戶則負責專業(yè)領域的培訓。在活動點上加上三種標志之一以指出該活動的狀態(tài)。 下面的方法可以用來估計價格、人員以及相應的時間要求。 ④計算上、下四分點和中點，并且標上尺度。為了解決問題和確定系統要求，項目組成員定期與有關用戶見面。在聯機系統中，檢查響應時間要求以確定這種時間要求是否太緊迫，能否適當放寬要求而又致于對運行效率產生較大的影響；或者確定這種響應時間的要求是否不能滿足。在目前系統的資料中包含了可繼續(xù)使用的數據元。 (17)建立控制和后援的方法 為了保證信息系統的正確性、可靠性和完整性，在設計時就要考慮加進控制手段。 (18)完成詳細設計 詳細的系統設計是分析輸入/輸出、處理、控制和后援要求的結果。HIPO以及渥寧(Warnier)圖。流程圖之所以較為流行，主要是由于它是最早出現的設計方法。 Warnier框圖可以用來設計整個系統、數據結構、報表內容以及數據元的編碼。然而，精心設計的解說詞可以而且應該用來支持圖形設計技術。它也給預測者提供一個機會來評價那些業(yè)已建議的事情(如系統設計)，從而有可能給出一些建設性的建議。這些人應該是沒有直接參與本項目的。參加者提供出討論的建議，而秘書則記錄下來以形成資料。 (21)準備輸出格式 在系統開發(fā)過程中，到目前這一階段為止，我們已經提及了輸出并描述了其有關的內容，但是程序員需要知道具體的輸出形式(即應該怎樣在輸出設備上出現)?，F在項目組可以著手標列和確定所有的程序，而這些程序是使得建議的信息系統運轉所要求的。 用戶的介入集中在系統開發(fā)的過程前段(第Ⅱ階段)和后段(第Ⅳ和Ⅴ階段)。這種系統并不能滿足用戶的要求，而且維護的代價很高。 (25)安排順序和分配程序 一個信息系統的軟件包，可能要求幾百個程序。 (27)編制、測試程序和編寫程序資料。在并行工作之后，系統轉變到業(yè)務領域。在測試期間用戶人員是實際的參加者。 整個系統的測試實際上是分兩個部分完成的。用戶手冊和有關的培訓對于系統的最后成功是至關重要的。控制 系統工作概述 有些文件和數據庫需要新建，而其他一些則需要從現有的轉換成適合的格式。因此，最好的策略是：在并行工作開始之前(或者在不要求并行操作的情況下，在系統實現時)正好完成建立和轉換工作。由于必須維護文件和數據庫，所以及時性是十分重要的。為此，必須在系統投入生產前，對它進行評價。通常在第Ⅳ階段完成后的3～6個月之間進行系統實現后的評價。這些利益或負荷提供了評價整個信息系統效率的直接輸入數據。這種被動地改進系統的方法其效率遠比由定期的系統檢查來保證的主動的方法要差得多。兩次檢查之間的間隔時間是根據系統的復雜性和易變性來決定的。很少有在系統開發(fā)過程中不犯錯誤而實現一個系統的。利用在系統設計時已建立起來的某些標準(例如，在峰值工作負荷時的響應時間)，將實際的性能與預期的性能進行比較。委托并進行評價活動的好處是獲得更高質量的系統并且使用戶更為滿意。有些公司放棄并行工作，盡管這種做法有很大的危險，但是這樣將把力量集中在成功地實現一個新系統上。并行工作是常用的手段，特別是當系統故障相當大地影響到公司的運營時更是如此，在并行工作期間，用戶和信息服務人員被分散開了，因為兩個系統都需要維護。用戶部門也可能負責抄寫和錄入數據的工作。與系統有關的信息服務人員和用戶人員的義務和責任 一個有各地分號的大型百貨商店實現了一個聯機銷售點(POS)系統并將用戶手冊分發(fā)給每一個POS終端地點。然而，在編寫和編譯這種手冊時必須考慮到能為預期的用戶所理解，而且不會被錯誤地解釋。用戶手冊至少包括： 一旦證實所有子系統的功能是適合的，則有“生存的”數據來測試整個系統?？梢钥隙?，一部分驗收測試過程必須在系統設計和程序設計方面進行較小的修改。項目組與用戶管理人員以及信息服務審計組合作，共同研究以設計出一項轉換計劃。開發(fā)任一給定的程序的一般的方法本質上是相同的。在安排程序編制順序時，主程序員應考慮如下問題： ①建立和維護測試文件的需要 ②程序的依賴性(此處一個程序依賴于另一個程序的部分或全部的輸出) ③程序的長度和復雜性 根據程序員專業(yè)知識的水平、工作效率以及對系統熟悉的程序分配程序。 (24)指定程序員組長 通常項目組長是一個系統分析員或是一個用戶，他并不直接參與程序設計工作。用戶介入最多的情況將反復出現在系統設計需要澄清的時候，有時也出現為第Ⅳ階段(轉換與實現)，作一些初始計劃的時候。對每一個程序，項目組編輯下述的資料： ①程序語言的種類(例如，COBOL、BASI