【正文】 分成更細小一層的輸入—處理—輸出的細目。從HIPO結構化方法所得到的好處往往被編寫系統資料所需要的大量繁瑣的文書工作所抵消了。使用Warnier框圖的依據是：應該圍繞著數據結構來設計系統。圖中的例子是一個擴展項判定表，它是許多判定表中的一種，一個判定表有一個條件分叉(在表的左上方)和活動分叉(在表的左下方)，一個條件項(右上方)以及一個活動項(右下方)。判定表的主要好處是必須考慮到每一種可能的替換者、選擇、條件、變元等。 上面討論的分析工具代替了一大段解說詞，而通常對解說詞的理解容易產生混淆。 沒有一種分析和設計的技術是最好的，最好的分析和設計技術是適合一個公司具體情況的各種技術的組合。按自頂向下方法進行設計時，通過最高一級的管理者來建立基本的系統目標，然后根據在公司每一級收集的輸入數據，在設計中增加后繼的細目層。模塊化的主導思想是“各個擊破”，而這是行之有效的。 結構預演是一種預測評價方法，它能有效地減少某些被忽略的或作錯的事情。預演的目的是給項目組提供有價值的反饋信息，而不是對系統的質量下判決性的結論。通常預演是在系統設計以及系統開發(fā)過程中其他一些關鍵點(如，測試計劃、程序描述等)完成之后才進行。項目組的某個成員或所有成員扮演“推薦者”的角色，并且解釋他們所承擔設計的系統的那一部分。根據對所提出的課題的知識和興趣來選擇“參加者”。秘書將對一些要點作書面記錄。中立經理的出席將促使參與預演的每一個人專心于他的工作(這一點有時是預演的一個問題)。在進行預演的前幾天將需要審查的材料(即系統設計)分發(fā)給參加者，協調員負責跟參加預演的所有人聯系和通信。這是通過一步一步地預演系統來進行的，有時可能還借助于某種設計工具。通常一次預演持續(xù)的時間不應超過一個半小時。如果必要，可以安排幾次會議來完成預演。預演是有價值的，它使得設計者在系統實現之前獲得重要的反饋信息。獲得硬件的過程通常是信息服務經理的責任。這種詳細的輸出說明稱之為輸出格式。 某些硬拷貝報告和資料要求事先打印好的表格紙，項目組與表格紙廠商的代表合作設計這種事先打印好的表格紙(例如，工資支票和短線)。 (22)描述數據項的說明書 數據項的說明書詳細規(guī)定了什么數據將輸入到系統以及它們怎樣被輸入到系統中。它的功能已經并入建議的系統的設計中，我們已經完成了建議的系統及其支持的數據庫的設計，并且還準備了所有輸入/輸出詳細的說明書。系統的圖形表示(流程圖、HIPO圖和其他)是標列所要求的程序的初始輸入。 ③由程序所產生的各種輸出的描述和格式 ④處理頻率(例如，每天、每周、聯機等) ⑤界限和限制(例如，輸入數據的順序，容量的限制，響應時間，最大值，最小值等) ⑥詳細說明書(例如，排序，編輯的標準，特殊的計算和邏輯操作，各種表格等)。這種通信(或與計算機的接口)是采取指令形式來進行的，而這些指令被編進計算機程序中。在第Ⅲ階段—程序設計階段將開發(fā)支持信息系統所要求的全部軟件。如果正確地完成了第Ⅱ階段而且用戶與項目組的協作是有“成效”的，那么用戶將很少介入程序設計階段，甚至完全不用介入。 不幸的是，有時用戶管理人員也較深地卷進了程序設計階段。這種情況是經常發(fā)生的，特別是在時間緊迫時，項目組常常收到一些強制性的命令要求產生尚未完成的產品。這種系統開發(fā)方式必然導致產生質量低劣的系統。這種系統整個壽命期的成本可能是一個高質量的系統的兩到三倍。管理程序設計工作的人應該是程序設計工作實際的參加者，因此，對于要求兩個人以上的程序設計工作，將由信息服務經理指定一個程序員組長。 程序員組長有時也稱作為主程序員。如果只需要管理一個下屬程序員，那么主程序員可能花80%的時間在產品的程序設計上。并不需要按照這些程序最終執(zhí)行的順序來編寫它們，在建立程序開發(fā)進度表時，必須考慮到許多變化的因素。由于經常將程序員分配到其他項目組，從而對專業(yè)知識和經驗的要求非常廣泛，所以使程序員與程序相匹配并非易事。由于程序開發(fā)有一個基本的模式，所以一種類似于用來監(jiān)督項目進度的技術可以用來監(jiān)督完成一個特定程序的進度。幾乎所有的主程序員和項目組長都經常使用這種公告板。 通常一個程序員在一給定的時間里將同時編制2～5個程序。它們是： ①準備一般的程序邏輯框圖 ②準備詳細的程序邏輯框圖 ③編寫程序(寫程序語句) ④測試和調試程序 ⑤編寫程序的資料 Ⅳ階段——轉換和實現 第Ⅳ階段的目標(轉換和實現)是把在第Ⅰ、Ⅱ和Ⅲ階段的工作結合成一個整體，并將信息系統實現到業(yè)務領域。 盡管在第Ⅳ階段已經分別測試了系統的各個成分(程序)，但這并不能保證把它們結合成一個整體時系統將正常工作。在第Ⅳ階段期間，項目組將培訓用戶運行信息系統，轉換現有文件以及建立數據庫。 (28)完成轉換計劃 轉換系統的處理本身就是一個系統，而且應該像最好的結果那樣來處理。該計劃包括：系統驗收測試，文件或數據的轉換，用戶培訓以及并行工作(如果必要的話)的細節(jié)。 (29)指導系統驗收測試 雖然已經測試了各個單獨的程序模塊，但是還沒有把它們結合成一體作為一個系統來處理。整體的測試將驗證全部系統軟件和應用軟件、輸入/輸出，文件和數據庫以及各種過程。在測試過程中，有可能發(fā)現錯誤(忽略了系統的某些方面)，某些過程的缺點將會暴露出來。如果系統是正確開發(fā)的，那么任何這種修改將只是微小地調整系統。這種推遲避免了通常敲打膝部那種反作用引起的改變而提交可觀的資源。這時，重大修改的要求才是一種分界清楚的標志，它表明有人忽略了他們對項目的責任。首先利用測試數據來驗證每一個子系統。測試數據是為了測試特定的環(huán)境而產生的，而“生存的”數據通常是來自過去處理使用的實際的數據。系統可能運行良好，但是由于計算機能力不夠大或是程序的效率不高，也可能導致不可接受的響應時間。每個信息系統都應該有一套用戶手冊，它們提供有關系統運行的命令和解釋。光有一套用戶手冊是不夠的，這些用戶手冊還必須是一種高質量的資料，它們能對系統的每一方面提供快速和容易的參照。系統的目標 工作流程和一般的操作方法 數據收集和更新的方法 其他(例如，術語唯一的詞匯表，硬件的描述和用法，性能的界限，等等) 用戶手冊的內容來自系統資料。 (31)提供用戶培訓大綱 如果不能跟培訓相關聯，那么用戶手冊的價值就很小。用戶培訓大綱的一般內容包括： 現有系統與新系統的差別 如何使用用戶手冊 如果沒有正規(guī)的培訓，銷售員將丟下他們自己的工作而去揣摹用戶手冊(有100頁以上)以了解系統的用途。在他們認識到問題不在于市場、產品質量或地點之前，百貨商店的這些分號幾乎要關閉。 (32)建立和轉換文件或數據庫 很難找到一個已實現的系統而不需要修改原有的文件或數據庫。用戶部門負責將手寫的數據統一格式并變成機器可談的形式。如果數據不是現成可用的或沒有用人工存儲起來(例如，存放在35的卡片上)，那么數據的準備工作可能耗費相當長的時間。數據的校對是將人眼現場檢查與計算機自動校驗結合起來進行的。在建立和轉換處理期間掌握時間是很重要的，因為一旦建立了一個文件或數據庫，此后就必然要對它們進行連續(xù)地更新。 (33)完成并行工作 并行工作意味著同時運行原有的系統和新的信息系統。完成并行工作是十分困難的，因為參加的人員仍然處于開始階段。項目組長和受影響的用戶管理人員以及有關的信息服務經理監(jiān)督并行工作的進程。 如果在并行工作期間出現了一次較大的故障，則應中斷并行工作并進行有關的修復工作。 如果公司改進他們的系統測試方法，那么信息服務和用戶人員就會自信他們有能力去實現一個系統。在某些情況下，由于時間和人力有限，不能進行并行工作，因而經理的代替辦法是直接實現新系統，并且要求進行充分的系統測試。由于其他緊急的信息系統項目需要人員，往往進行很少的，甚至不進行實現后的評價，不管好壞，系統就被接受了。任何信息系統在剛剛實現之后都將要求做某些“微小的調整”。因為一旦系統投入使用，即便實現前的測試設計得很好，也不可能完全暴露出某些在系統投入運行時必將出現的問題。 (34)調整成本 項目組長調整項目的成本以如實反映Ⅰ、Ⅱ、Ⅲ、Ⅳ階段的最終系統開發(fā)成本。 直到系統實現至少一個月之后，才有可能算出精確的、符合實際的成本數據。在系統運行的頭幾個月，由于存在著對改革的阻力，對系統的把握不夠以及非預期的問題等，因此，不宜立即進行系統實現后的評價。 項目組和用戶部門挑選和人員并指導系統實現后的評價以決定： 實際的與預期的性能的比較。 系統目標實現的程度。例如，系統能否給審計員提供非常及時的信息以進行更好的決策。幾乎任何基于計算機的系統都將導致非預期的利潤和耗費。坦率地計論錯誤。應該將項目組、用戶經理、用戶人員、其他信息服務人員或信息服務對策委員會坦率、詳細地討論的錯誤編寫成資料。 系統實現后的評價被提交給信息服務經理和用戶經理以便采取適當的措施。在這些系統中，所謂的改進工作是不超出例行維護的范圍的，而且是由于用戶的反映才作的。有很多原因會導致忽視定期檢查，因此，應該通過一個正式的書面檢查計劃來督促進行檢查。定期系統檢查是業(yè)務領域管理人員的責任。38 /