1、三、系統開發過程 五個時期 各種系統開發方法學在范圍、復雜性、完善程度以及方法上有專門大的不同。盡管有的方法學分三個時期，有的分15個時期，然而每個方法學所描述的要完成的活動差不多上是相同的。本章要闡述的最重要的一點是：最好的方法學是那些始終把用戶考慮到里面去的方法學。過去的情況是，用戶治理人員與信息服務開發組合作來完成系統的一般功能講明書，然后，由信息服務人員來進行系統開發。現在，系統開發是各占50%的比例；因此，用戶治理人員應該特不熟悉系統開發的大體過程，特不應該熟悉他們單位自己使用的方法學。 系統開發過程可分為五個時期來描述。這五個時期是： 1.第時期系統開始和可行性研究 2.第時期系統

2、分析和設計 3.第時期程序設計 4.第時期轉換和實現 5.第時期實現后的評價 第時期系統開始和可行性研究是在為開發一個建議的系統提供人力和資源之前完成的。第時期多數的工作和編寫的資料是第時期的輸入。在第時期系統分析和設計期間，系統分析員與用戶一起工作以編寫詳細的功能和系統的講明書。將這些講明書交給程序員，然后開始第時期程序設計。在第時期轉換和實現期間，一旦軟件開發出來，則建立數據文件，轉換現有系統，同時實現新系統。第時期實現后的評價。在開始了系統壽命期中的生產時期之后，提出(經常被忽略的)實現后的評價要求。 具體開發過程 下面將逐步地描述系統開發過程。至于具體的細節、相互的阻礙、方法、形式等，

3、用戶治理人員應該與信息服務經理聯系，與他們討論公司當前使用的方法學，同時再看看公司內部描述方法學的手冊。 1.第時期系統開始和可行性研究 在第時期的活動中專門少有與其他四個時期的活動相一致的。此處所提供的方法包括關于受拒絕后的再次服務請求的方法以及將技術轉移可能性的研究合并到諸過程中這些內容。第時期最終的產品有兩個部分。第一部分是實際的可行性研究報告，它包含對建議的或改進的系統的描述以及利潤/成本分析。第二部分是系統的初步設計。它關于估價成本和利潤是必要的。該初步設計是第時期系統分析和設計的直接輸入。 將系統的初步設計并入可行性研究的依據是，多數可行性研究是以概念而不是以設計為基礎的。假如在描

4、述系統目標上花的時刻太少，那么成本可能，甚至利潤可能將是錯誤的。用概念來指導可行性研究注定會導致成本過高，而且用戶不中意。在系統初步設計上所花費的時刻是值得的，即使拒絕可行性研究也是如此。因為所編寫的資料將必定會被證實其他項目中是有價值的。 下述編號的活動與表20.9.2的系統開發責任矩陣相對應。 (1)提交服務請求 圖20.5.1講明了包括對受拒絕的請求再次請求處理的一種方法。所請求的服務怎么講是用戶做的，因此，應該由用戶著手進行。我們鼓舞用戶治理人員請求信息服務人員的關心，然而應該再一次強調，業務領域的治理人員應該對各種大小的服務請求都提供合適的資料。 (2)估價服務請求 正如在責任矩陣中

5、所注釋的那樣，信息服務治理人員只能承諾小的項目(由公司的方針所確定的小項目)。 (3)指定可行性研究組 信息服務經理和用戶經理共同來指定適當的混合的人選以組成可行性分析研究組。該組至少由一名系統分析員和一名用戶代表組成。可行性研究組的大小取決于可行性研究的范圍和時刻限制。 用戶代表應該熟悉當前專業領域的所有工作，用戶經理、總經理助理，或專業領域分析員是合理的候選者，用戶的系統分析員，具有計算機信息處理基礎知識的情況差不多越來越普遍了。 必須指定一個人擔任可行性研究組的組長，哪怕只是兩個人的可行性研究組也需要一個組長。直到1980年為止，多數的可行性研究組和項目組是由一個高級系統分析員或一個項目

6、負責人來領導的。在信息服務部門中，這兩種人是固定分工做這項工作的。目前越來越多的公司采取如此一種政策，即由用戶擔任項目組組長。這種將要緊責任下放給最終用戶的做法將進一步鼓舞用戶參與系統設計。在這種政策上取得成功經驗的那些公司差不多指派了一些具有杰出治理經驗和具有某些計算機和信息處理知識的用戶人員擔任項目組組長。在任何情況下，組長必須對該組的工作有一個總的安排。假如要求一個用戶代表既作為可行性研究組或項目組的組長而同時又要求他接著履行業務領域的職責，那么該項目是確信要失敗的。有好些公司差不多采納了一種政策，即自動地指派受系統阻礙最大的業務領域的經理作為可行性研究組和項目組的領導以后該經理將從原來

7、的工作職責中解脫出來，而用他(她)的全部時刻治理可行性研究(或項目)組。這種人事安排差不多成為當今的主流，其困難是用戶經理需要離開原來主管的業務部門少則兩個月多則三年后才能回他原來的工作崗位上。 (4)標列約束條件 在系統開發的過程一開始，可行性研究組與信息服務人員和用戶經理緊密合作標列出設備、成本、進度、規程、軟件以及操作上的約束條件。它們可能限制建議的系統的定義和設計。 (5)整理現有系統的資料 整理現有系統資料的要緊理由是：假如可行性研究組不充分了解現有系統，那么他們就不可能有效地完成所建議的系統的初始設計。差不多建立起來的多數人工系統并沒有通過真正的設計。在這些系統中，必須從手稿整理出

8、資料。假如一個建議的系統是改進一個現有的計算機信息系統，那么可行性研究組只需要保證現有資料的完整性和保持最新版本就行了。現有系統所形成的任何資料將給設計時期提供有價值的輸入(假如批準開發該系統)。即便建議的系統遭到拒絕，也能對現有系統提供差不多的資料，同時可能透徹地理解理有系統。現有系統的資料由四部分組成：系統報告和資料；系統數據文件；系統數據元以及講明現有系統的數據、信息和工作流程的圖表。前三部分(報告、文件和數據元)可分類如下：當前使用的，而且在建議的系統中以目前的形式保留下來； 當前使用的，然而修改后才在建議的系統中使用； 當前使用的，然而在建議的系統中將被刪除而不再保留的。 例如，列出

9、所有現有的報告和標準的資料，并按上述分類給定一種狀態。在報告上將標明相對周期(如，每天，每周)以及分發范圍。 關于現有系統的所有數據文件都標明有關的存儲介質(如，35的卡片，磁帶，馬尼拉折紙機，磁盤等等)以及存儲方式。例如，一個名字一地址文件能夠存儲在許多張35的卡片上，同時按名字的字母順序排列。一個人工系統所保存的文件數總是令人吃驚的，即便關于業務領域治理人員也是如此。為了完善現有文件的資料，將每個文件的記錄的樣式和簡單描述附在文件表中。系統數據元(即，社會保險號，顧客名，貨號等等)是直接列出的，而不必關系有關的文件。數據元經常在幾個文件中重復出現。除了狀態指示符之外，假如數據的名字不能自我

10、講明，則必須對每個數據數據元進行描述。有關數據元的其他信息還包括更新要求(如，每天，每周，每月，或依照需要更新等等)、來源(如，代辦處，資料，系統，工作人員等等)以及職責(如，部門名和負責更新者的職務)。圖20.9.3講明在整理現有系統資料時數據元可能采納的一種典型格式。 我們通過將系統簡化為輸入、處理和輸出等幾個差不多組成部分來表示整理現有系統資料的工作過程。然后用圖形描繪出各部分之間的邏輯關系。有多種圖像表示技術來做這件事。最為流行的(盡管不一定是最好的)是流程圖。其他的更為結構化”的技術還有：IBM公司的層次化輸入處理輸出圖(HIPO)，汽泡圖，數據流框圖，南茜斯奈德曼(Nassi-Sh

11、neiderman)圖，渥尼爾(Warner)框圖以及判定表。當前工作過程的圖像描述提供了系統的數據、信息和工作流程的一個概貌。它著重強調系統中操縱工作流程的那些數據元。這些圖應該刻劃人工和計算機的處理步驟，同時以適當的順序安排每一處理步驟。通常以能最好地顯示出工作過程的方式來組織和提供這些圖。它們能夠是由一些隨機事件、功能或按小的和大的周期來驅動的子系統，也能夠是若干子系統；既能夠是層次的，也能夠是混合的。專門少有幾個系統是完全順序的，因此，在多數情況下能夠應用模塊方法。 (6)調查研究技術轉移的可能性 為了更好地利用現有的技術，許多公司正在進行將有關技術轉移到他們的系統開發方法學中可能性的

12、調查。鼓舞調查技術轉移的可能性和(或)可行性的政策必將帶來人力資源的大量節約。特不對程序員和分析員更是如此。合適的技術轉移將使這些人的工作集中于還沒有現成軟件的特定行業的應用領域。 技術轉移可能性的調查是從走訪那些差不多實現的，而且與所建議的系統有類似規模和工作的系統。可行性研究組還應該調查商品軟件目錄，以便找到適合的可應用的軟件。假如認為技術轉移是可行的，則可行性研究組講明如何樣使用這些技術以及為適應現有環境所要求的修改范圍。 假如使用標準的方法來進行技術轉移潛力調查，那么提出要求的公司應該采取與具有類似要求的其他公司合作的政策。 (7)完成建議系統的初步設計可行性研究組要走訪專業人員以獲得

13、一般的系統要求，然后，將這些要求轉換成初步的系統設計。設計過程是交互的，用戶經理和可行性研究組需要經常就設計思想和方法等交換意見，用生動的文字和圖形講明來形成建議的系統初步設計的資料，這些生動的文字(用非技術詞匯)描述了所建議的系統的差不多工作過程，而且常常同時附有圖形講明。這些文字圖表也將列舉出那些大大違背現有工作方式而建議的系統所期望的手續、手段和方法。這些文字圖像也將描述建議的系統與人工系統以及建議系統必須與之兼容的自動系統之間的關系。圖形講明將建議的系統的過程簡化為它們的組成部分，同時強調各部分之間的邏輯關系。 (8)確定項目范圍 可行性研究組與信息服務人員以及用戶治理人員合作可能初步

14、設計中所刻劃的系統的復雜程度。并對開發項目今后的每一個時期進行人力資源要求的可能(用戶，信息服務人員及其他人員)。此外，還注意到培訓和計算機機時要求。 (9)預備利潤/成本分析報告 一旦完成初步設計同時確定了項目的范圍，則能夠開始利潤/成本分析。不幸的是，由于用戶和信息服務治理人員都希望加快可行性研究時期，因此，一些關鍵的步驟被省略了，因此造成在利潤、成本可能上的錯誤。僅僅依照一種概念是不可能精確的反映出利潤和成本的。設計中的某些步驟是必不可少的。 另一種在形成公司決策過程中所隱含的錯誤將不可幸免地把那些難以確定的利潤也算成資金收入。當今許多復雜的，綜合的系統為公司的利益做出了重大的貢獻，而做

15、到如此程度是因為它們經歷了漫長的、不可捉摸和難以預見的道路。評價信息服務項目的好處和價值是一個主觀的過程，它要求具有成本和利潤方面的實際的知識。此外，決策者關于正的和負的不確定的利潤要有透徹的理解。使用美元作為所有成本和利潤的統一的計量標準大大地簡化了評價工作。那種把不確定的利潤引入盈利圖表(為了“建立更好的顧客關系”或“提高威信”)的作法會造成在“底線”中復合的錯誤。底線經常被盲目地同意作為一種信條。事實上，在那種情況下，估價是取最好的情況(理想的)和最壞的(荒謬的)情況之間。然而，假如將不確定的利潤化成美元，那么決策者將以更好的推斷代替那種不準確的可能。 估價建議的信息系統的最好途徑是針對

16、系統凈值(收入減去成本)估量正的和負的不確定利潤。為了便于理解不確定利潤(例如，增加服務，減少發票上的錯誤，加快周轉期等)，應該產生一個成本和收入的一覽報表。 表20.9.4講明如何使用最少的成本類不來表示一次性的和重復使用的成本。這些成本可由預算中心提出，同時把公司作為一個整體來考慮。成本類不有：勞力，材料和設備，旅差以及其他各種成本。關于每一類，在第一列指出一次性成本可能(開發)，而在系統壽命期的水平線上指出可重復使用的成本可能(生產)。公司項目在凈值能夠從可能收入中扣除成本計算出來，同時依照公司政策對流淌現金打折扣。 (10)依照可行性研究做出決策 完成可行性研究后，除了技術補充之外所有

17、報告和資料全部交給信息處理政策委員會以便實施。技術補充包括預備可行性研究所要求的背景信息。它還包括一般的系統設計和開始第時期(系統分析和設計)的一個框架。信息服務政策委員會感興趣的要緊是初始服務請求、范圍、圖解講明和利潤/成本分析。 信息服務政策委員會能對可行性研究施加阻礙。信息服務政策委員會能夠： 拒絕建議。 批準建議并對該建議的開發和實現指定一個最高優先數。 批準系統并給它指定一個比最高優先數小的優先數，同時將請求放在所有建議的系統隊列的適當位置(定期檢查隊列，當所請求的資源可用時，委員會給當時是最高優先數的項目發出通行命令)。 2.第時期系統分析和設計 專門少有幾個項目能在批準可行性研究

18、后立即實現。在得到批準和項目開始之間的可能時刻可能是兩年或兩年以上。一旦項目獲如通行命令，則開始第時期系統分析和設計。在第時期，將描述所有輸入/輸出的格式和內容，同時完成詳細的系統設計。第時期的最后一步活動是預備程序講明，其中包括各種程序模塊的講明書。重要的是牢記在第時期和第時期不編制程序。一個普遍容易犯的錯誤(經常與系統的質量和運行維護的水平緊密相關)是壓縮第時期，使它提早完成以便開始第時期程序設計。粗糙的系統設計必將成倍、甚至三倍地增長項目所要求的程序設計量。 (11)指定項目組 與可行性研究組一樣，項目組也應該有一個或多個系統分析員和一至多個來自所建議的系統范圍內各業務方面的用戶代表。假

19、如可能的話，還要給項目組指派一名信息服務審計員，他不作為專職人員，而作為安全和操縱方面的顧問。因為在第時期結束之前程序員實際上并不參與進來，因此能夠將指定程序員一事推遲到第時期結束時再進行。可行性研究組的成員不一定差不多上項目組成員。在第時期結束到第時期開始之間的這一段時刻里，通常委派他們到其他項目去。然而我們建議，只要可能則盡量將原有可行性研究組的人員指派到項目組。項目組的組長能夠是信息服務人員，也能夠是用戶。 某些單位有按業務領域組織的固定的項目組。例如，某個項目組專門負責人力資源開發方面的老的系統的維護和新系統的開發，而另一項目組則負責會計和財務方面等等。另一種方法是項目組必須由信息服務

20、人員和用戶專業人員共同組成，而且是以項目為基礎來指定項目組。究竟如何樣組成項目組為好，顯然要進行權衡。按專業組成的項目組專門難預料在任務過多時或任務不足時由于人員不足或過剩所帶來的損失。然而，這種項目組織使得項目組成員有更多的機會積存開發專業領域應用的經驗。信息服務項目組組織的最好方式或許是既按專業領域組織而同時又保持一定的靈活性，使得項目組成員能在各項目組織之間流淌，以便達到飽滿的工作負荷。 依照項目的復雜程度和涉及范圍的大小，每個項目組都有不同的最佳人數。項目組長的能力是一個重要的因素。有些地點，一個經理能有效地治理20個以上的人員，而另一些經理卻連治理3個人都有困難。項目組的大小以及相對

21、進度這些是用戶、信息服務人員以及公司的經理感興趣的問題。許多公司的經理人員有一種錯誤的概念，即假如將項目組人員增加一倍，那么完成項目的時刻就應該減少一半。實際情況并非如此。一個能夠直接分成若干個相同大小模塊的簡單項目，用兩倍的人力，能夠在原定的一半時刻里實現。然而，絕大多數的項目是復雜的，有的甚至是極為復雜的，這就要求在所有項目組成員間進行內部協調。 圖20.9.5講明增大項目組的規模時，將會發生的情況。在某確定的數目之前，每增加一個指派到項目組的人員都增大了對項目的貢獻。在這之后，每增加一個人實際上減少了項目組每個人對項目工作的貢獻。圖上有一點是增人員的反射界線，超過那一點，再增加人關于項目

22、的目標來講反而起相反作用。由于項目成員之間的關系復雜，因而使得生產效率降低。在為了滿足項目限期而采取緊急措施的情況下，有時經理人員要求將所有資源轉移到緊急的項目上，圖20.9.5形象的講明了當一個項目組人員太多時，將會出現的情況。這時將不可能進行內部協調。當頭都不明白尾在做什么的時候，即使每一個成員都忙于從事某種與項目有關的工作，項目的進度依舊要停頓下來。 關于每一個確定的項目組都有最佳規模。與項目有關的所有經理和公司行政人員都應當專門好地掌握如此一個格言：與其過分地擴大項目組織規模，造成欲速則不達的局面，還不如推遲項目的實現時刻。 (12)可能人員要求并進行人員托付 一個項目的成功與否在專門

23、大程度上依靠于用戶與公司經理、其他專業領域人員以及某些范圍內信息服務人員(如，數據庫治理員，聯系用戶的人員等等)。由于某人(或某部門)不記得或不承認往常的口頭上的托付，會使得許多緊急項目被延誤。因此有必要簽署一個書面的人員托付書。應該造表列出在系統開發過程中所直接參與到的項目組的人員和其它人員(如訪問用戶人員、收集數據人員等)，并同時列出在每一時期對他們的相對的時刻要求(見表20.9.6)。項目的人力要求來自于可行性研究報告。圖20.9.6 可能人員要求 沒有書面人員托付而進行的項目確信會產生不必要的延誤，甚至可能失敗。本書把項目開發的重要性放到一個恰當的位置。在項目中所涉及到的許多人并不在項

24、目組內。由于這些的多數都理解他們的例行活動比項目所涉及的任何外部事物更為重要，因此一個書面托付是必不可少的。不幸的是，項目托付有時超過了他們按常規分配的工作負荷。在這種情況下，需要經理直接參與、定期督促和采取干預措施。圖20.9.7關于在各個時期人員托付的相對要求上給讀者一個感性的認識。圖20.9.7的底部描繪了在系統開發的每一時期占總的項目工作量的百分比，對每一時期提供了項目工作量百分比的一個范圍。公司的政策以及系統開發方法學將阻礙到相對百分比。例如， 一種強調設計時期()的方法學將必定有更為清晰定義的程序功能講明書。因此減少了程序設計工作所要求的時刻。作為一個規則(到目前為止)，花在第時期

25、(系統分析和設計)上的工作量是與花在第時期(程序設計)上的工作量成反比的。在一個設計良好的系統中，第時期將具有比第時期更大的工作量。圖20.9.7 相對的項目工作量 圖20.9.7的上端講明了由項目組(用戶和信息服務人員)和非項目組成員的用戶對項目工作貢獻的相對百分比。注意，在第時期期間，30%的工作量是由不在項目組的用戶做的。在第時期(系統分析和設計)期間，項目組必須不斷地在每一級與用戶進行通信。在程序設計期間，僅僅在外圍才涉及到用戶。在第時期(實現和轉換)，在培訓、測試、數據轉換和并行操作中都涉及到用戶。在第時期中項目組和用戶肩并肩工作，直到實現系統。在第時期，將系統轉交給用戶。 (13)

26、人員培訓 為了在系統開發過程中進行有效的交流，可能要求關于在設計數據庫時所涉及的用戶以及在生產調度中所涉及的信息服務人員進行培訓。依照經驗，信息服務人員負責信息系統方面的培訓，而用戶則負責專業領域的培訓。 那個活動的產品是一張表，表中列出要求某種培訓的人員的名字和頭銜。每行表中都注明那種培訓的簡單描述，包括地點、負責人以及打算的時刻等。有些培訓將要求立即進行，而另一些培訓(比如數據錄入)將推遲到項目接近實現時進行。 (14)建立詳細進度表 通過使用一種標準的系統開發方法，治理人員能夠建立時期標志(見表20.9.2的活動5，10，19，23，27，29，32，33，和36)，然后，利用歷史統計數

27、據和經驗來可能中間和最后活動完成的日期。項目組組長必須與信息服務人員以及業務領域的治理人員緊密合作以保證在系統開發過程中在各關鍵點有足夠的人員。 系統開發過程本質上是線性的(一個活動接著一個活動)，而且是不難用適當的準則(方法學)和合理的可能來監視的。表20.9.8講明了一個典型的信息系統項目進度表。在活動點上加上三種標志之一以指出該活動的狀態。假如情況表明該活動是不必要的，則在活動號上加一個圓圈。假如一個特定的活動正在著手進行，則在相應的活動號上劃一個對角線。一旦活動完成則將對角線改成交叉線“”。有時也用甘特表來給出項目進展的圖形輪廊。 在開始一組有時期標識的活動之前，要預備一個更為詳細的進

28、度表，來單獨安排這些中間活動。關于要求多于兩周時刻的那些活動將以兩周為增量來安排進度。表20.9.9講明了對具有時期標志E的那些活動的一個詳細的信息系統項目進度表。表20.9.8 信息系統項目進度表階 段+具有時期標志完成的活動時期標志 活動可能的開始時刻 實際的開始時刻 提早或推遲的天數 可能的完成日期 實際完成的日期 提早或推遲的天數A 1 2 3 4 5 198W.9.1 198W.9.1 DS 198W.10.1 198W.10.15 12BB 6 7 8 9 10 198W.10.1 198W.10.20 14B 198W.11.1 198X.12.1 22BC 11 12 B131

29、4 15 16 17 18 19 198X.9.15 198 Y.9.1 13A 198X.12.25 198X.12.20 3AD B2021 22 23 198Y.1.15 198Y.1.15 DS 198Y.2.15E 24 25 26 27 198Y.3.1 198Y.6.30F 28 29 198Y.6.1 198Y.7.15G 30 31 32 198Y.6.25 198Y.9.10H 33 198Y.10.1 198Y.10.31I 34 35 36 198Y.11.1 198Z.2.11 =已開始的活動=已完成的活動0 =不要求采取措施+對應于圖20.9.3中的方法學*直到實現

30、可行性研究之前，并不進行第時期活動的可能A =提早的工作天數 B =推遲的工作天數DS=正在進行表20.9.9 信息系統項目進度表具有時期標志E的活動時期標志E細節活 動 可能的開始時刻 實際的開始時刻 提早或推遲天數可能的完成日期 實際的完成日期 提早或推遲天數24 指定程度組長 198y,3.1 198y,3.825 安排順序和分配程序 198y,3.5 198y,3.1226 安排程序預備進度 198y,3.15 198y,3.2527aKG*2編定、測試程序并編寫程序資料 198y,4.1 198y,4.1127bKG*2同上 198y,4.15 198y,4.3027cKG*2同上

31、198y,5.1 198y,5.1427dKG*2同上 198y,5.15 198y,5.3127eKG*2同上 198y,6. 198y,6.1427fKG*2同上 198y,6.15 198y,6.30*以時期標志D的活動 A=提早的工作天數B=推遲的工作天數實際開始時刻為準 os=正在進行 下面的方法能夠用來可能價格、人員以及相應的時刻要求。這種循環使用的方法使得一組人能意見一致，而且關于信息服務項目特不合適。我們假定參與可能的那些人能夠提出問題或具有任務方面的知識，而且能夠提出支持自己意見的重要的理由。參與建立信息系統項目進度表的人能夠包括項目組長、起作用的用戶經理以及其他有經驗的信息

32、服務人員(他們不一定與本項目有關)。我們通過以下幾個步驟來描述進行合理估價的方法。 項目組長介紹任務(例如，確定項目進度表的時期標志的日期)和相應的背景信息。 每一個參加者提交一個書面可能(成本、人員要求或時刻)。 項目組長(以線性比例)繪出該組每個成員的可能。 計算上、下四分點和中點，同時標上遲度。 要求其可能低于上、下四分點的那些參加者解釋他們低或高可能的理由。 項目組長就所標繪的可能召集一次公開的討論會。 重復步驟至，直到達到精確性要求不需要再循環為止。通過每一次循環，將降低可能的誤差。 可能是取中間值或(在適合時)取平均值。可能的誤差是包含危險的一種標志。 (15)與用戶人員交談 與用

33、戶交談的過程從本活動開始。為了解決問題和確定系統要求，項目組成員定期與有關用戶見面。與用戶交談及反饋的過程貫穿于系統開發的全過程。 關于詳細設計的差不多輸入是：(A)初始設計(來自可行性研究)，(B)對現有系統及其成分的評價(也是來自可行性研究)以及(C)輸入、處理以及輸出的要求(由用戶提供)。 項目組與有關的用戶人員檢查在可行性研究的初始設計中所描述的輸入/輸出要求和頻率，并依照需要及價值對每一種輸入/輸出進行評價。許多輸出是“有了更好”，然而卻不值得去產生它們。還能夠依照周期和時幀來可能輸入/輸出。通過可能頻率/價值比的平衡來優化周期的輸入和輸出。例如，假如每周情況報告能夠滿足需要，那么就

34、沒有必要再產生每天的情況報告。在聯機系統中，檢查響應時刻要求以確定這種時刻要求是否太緊迫，能否適當放寬要求而又致于對運行效率產生較大的阻礙；或者確定這種響應時刻的要求是否不能滿足。 目前系統的資料對設計提供了有價值的輸入。現有的報告、表格、原始資料等等，實際上能夠追蹤最終用戶以便確定該資料是否合適，是否及時等。假如是，還能做哪些工作來改進它們?項目組負責對現有的所有輸入和輸出進行修改。通過合并類似的輸入和(或)輸出以及消除多余的信息盡可能地減少重復。 初步交談的一個直接結果是對所建議的系統所有的輸出一般的描述(報告，顯示或事務)。依照周期、初始用戶、輸出介質、內容以及分布來描述每一種輸出。 (

35、16)講明數據庫要求 數據庫用來支持系統的處理，特不是支持系統的輸出。在目前系統的資料中包含了可接著使用的數據元。許多現有數據元的格式確信是需要改變的，還需要將支持系統功能要求所需要的其他數據元標列出來。 項目組設計和編制數據字典，在一部數據字典中所列出的數據具有維持每個數據元的差不多信息，而它們與數據庫或文件的組織形式無關。在表20.9.10給出的數據字典的例子中，包括對每個數據元指定了一個各自的前后參照號、標題、描述(假如必要的話)、是否被編碼、程序設計標識、存儲單元(字符)數、格式和存儲器大小(程序最初使用的)以及職責等。用戶必須給出負責的人或部門、存儲單元以及是否對數據元編碼等事項。表

36、20.9.10的數據字典形式，也能夠用來交叉引用在所有原始資料、報告、文件以及數據庫中出現的每一個數據元。 在標列出所有的數據元之后，項目組與數據庫治理員合作來進行記錄格式和文件的設計，或者，在數據庫環境下，他們設計數據庫的模式。此活動的輸出是數據字典以及有關文件和(或)數據庫模式的一份詳細的技術描述。表20.9.10 數據字典報告標題 數據字典 日期系統標題 標識編號標題 描述 編碼否標記字符數 字形/格式 存儲 職責原始資料(S)、報告(R)、文件(F)、或數據庫(D)工資支票(R) 工資登記簿(R) 工資主文件(F) 會計文件(F) 工時卡(S)1 社會保險號 職工 否99999 P 人

37、事 2 姓 否LNAME 13 (13) E 人事 3 名字 職工 否ENAME 10 (10) E 人事 4 名字首字母 職工 否MI 1 E 人事 5 部門 職工親屬 是DEPT 3 E 人事 6 性不 男或女 是SEX 1 E 人事 7 工資 月工資 否SAL 6 9999 P 人事 (17)建立操縱和后援的方法 為了保證信息系統的正確性、可靠性和完整性，在設計時就要考慮加進操縱手段。項目組將講明在系統設計時要嵌入所有物理上的和行政治理上的操縱。在系統的輸入、處理和輸出時期用以操縱系統的技術的范圍是廣泛的。在處理之前核對輸入，在處理期間使用諸如合理性檢查以及數字位檢查等技術以便最小化或消

38、除在計算或處理中的過失誤差，記錄計數和長度核對是用來保證輸出正確性的許多技術的代表。 為了幸免在系統故障期間造成破壞，需要確定后援(備份)和校驗點/重新啟動的方法。這些方法描述了包含在系統中的克服故障的額外處理，在系統故障的情況下，利用備份文件和(或)備份事務日記從上一個“校驗點”來重新建立處理。在上一個校驗點“重新啟動”系統，并重新開始正常的運行。在系統處理周期期間，定期地建立校驗點將會使系統及時地保留在該點的所有處理，而且可不能被破壞。 (18)完成詳細設計 詳細的系統設計是分析輸入/輸出、處理、操縱和后援要求的結果。系統初步設計或系統一般設計只描繪了各要緊處理活動之間的關系，而系統詳細設

39、計則擴展到包括所有處理活動和有關的輸入/輸出。這是系統開發過程的基礎活動。正是這一步，將功能講明書與技術上和方法上的新設施結合一起以實現一個系統。詳細設計是前面所有工作的歸宿。此外，它也是該項目今后所有活動的一張藍圖。 在活動5中提到了用圖形講明系統設計所使用的若干技術(但沒有詳細討論)。那個地點我們簡單地討論其中三種技術流程圖。HIPO以及渥寧(Warnier)圖。用來形象地描述工作流程和總的系統設計的最流行的技術是流程圖。流程圖使用刻畫系統邏輯的一些專用符號并通過流線把這些符號相互連接起來以講明工作流程和數據流程。圖20.9.11給出了系統流程圖符號的一個子集。在圖20.9.12中，用流程

40、圖描繪了一個已投入運行的工資系統的一部分。 流程圖有一定的缺點。不像前面所討論的其他兩種技術，流程圖并不鼓舞分析員使用系統設計的自上而下或模塊化的方法。因此，用流程圖方法來設計系統，不僅難于設計，而且設計出的系統也難于理解和維護。流程圖之因此較為流行，要緊是由于它是最早出現的設計方法。 層次式輸入處理輸出法(又稱HIPO法)是在一層次體系中將系統設計按其詳細程度分層，依次地講明所有的輸入、處理和輸出的一種方法。圖20.9.13講明了一個工資系統的HIPO卷內容表(VTOC)。VTOC是在HIPO設計方法中所使用的幾種標準形式之一。整個系統被劃分成由若干邏輯模塊所組成的一個層次體系，并用VTOC

41、來描繪。此后，利用粗框圖和細框圖還能夠將這些模塊進一步劃分成更細小一層的輸入處理輸出的細目。通常由若干個VTOC將設計的層次體系統推進到依次的細目層。從HIPO結構化方法所得到的好處往往被編寫系統資料所需要的大量繁瑣的文書工作所抵消了。 Warnier框圖(在圖20.9.14中講明)能夠用來設計整個系統、數據結構、報表內容以及數據元的編碼。使用Warnier框圖的依據是：應該圍繞著數據結構來設計系統。Warnier框圖的最大優點是對各種環境的適用性。圖20.9.15中的例子是一個擴展項判定表，它是許多判定表中的一種，一個判定表有一個條件分叉(在表的左上方)和活動分叉(在表的左下方)，一個條件項

42、(右上方)以及一個活動項(右下方)。判定表并不是一個講明數據流和工作流的有效的工具，最好把它作為其他設計方法的補充。判定表的要緊好處是必須考慮到每一種可能的替換者、選擇、條件、變元等。與流程圖，HIPO圖以及其他設計方法不同使用Warnier框圖法，系統分析員不必考慮細節。圖20.9.11 部分系統流程圖符號圖20.9.12 簡化的工資支付系統流程圖工資系統 系統開始每月處理 月初每周處理 提交時刻卡片數據錄入按工時處理職工記錄 工資支票工資聯單更新工資文件月末 按月薪處理職工記錄 工資支票工資聯單更新工資文件系統結束圖20.9.14 Warnier框圖圖20.9.13 HIPO：卷內容表 上

43、面討論的分析工具代替了一大段解講詞，而通常對解講詞的理解容易產生混淆。然而，精心設計的解講詞能夠而且應該用來支持圖形設計技術。 沒有一種分析和設計的技術是最好的，最好的分析和設計技術是適合一個公司具體情況的各種技術的組合。總之，模塊化的自頂向下方法是當今必不可少的。按自頂向下方法進行設計時，通過最高一級的治理者來建立差不多的系統目標，然后依照在公司每一級收集的輸入數據，在設計中增加后繼的細目層。由于作為一個整體概念多數系統過于復雜，因此將系統分成若干個更容易理解的模塊。模塊化的主導思想是“各個擊破”，而這是行之有效的。 (19)指導用戶或信息服務部門預演。表20.9.15 一張判定表支付類型

44、工資 按工時處理 傭金時幀 周末 月末 周末 月末 周末 月末打印工資支票 打印工資聯單 結構預演是一種預測評價方法，它能有效地減少某些被忽略的或作錯的情況。它也給預測者提供一個機會來評價那些業已建議的情況(如系統設計)，從而有可能給出一些建設性的建議。預演的目的是給項目組提供有價值的反饋信息，而不是對系統的質量下判決性的結論。 項目組長應考慮何時開始結構預演。通常預演是在系統設計以及系統開發過程中其他一些關鍵點(如，測試打算、程序描述等)完成之后才進行。 參與結構預演中的人有：若干項目組成員，一個協調員，參加者，一位秘書，或許還包括一位不屬雙方的“中立的”經理。項目組的某個成員或所有成員扮演

45、“推舉者”的角色，同時解釋他們所承擔設計的系統的那一部分。協調員負責組織預演和協調“推舉者”與“參加者”之間的相互配合。依照對所提出的課題的知識和興趣來選擇“參加者”。這些人應該是沒有直接參與本項目的。秘書將對一些要點作書面記錄。通常邀請一個“中立的”經理參加第一次預演。中立經理的出席將促使參與預演的每一個人用心于他的工作(這一點有時是預演的一個問題)。 結構預演的方法是簡單的。在進行預演的前幾天將需要審查的材料(即系統設計)分發給參加者，協調員負責跟參加預演的所有人聯系和通信。在實際的預演期間，推舉者解釋系統設計以及有關的資料。這是通過一步一步地預演系統來進行的，有時可能還借助于某種設計工具

46、。參加者提供出討論的建議，而秘書則記錄下來以形成資料。通常一次預演持續的時刻不應超過一個半小時。假如超過了那個時刻限制，那么一次預演會議將變得沒有實際效果。假如必要，能夠安排幾次會議來完成預演。 項目組評價所有的建議，同時把所有價值的建議并入到系統設計中。預演是有價值的，它使得設計者在系統實現之前獲得重要的反饋信息。 (20)選擇硬件 假如正在開發的系統要求額外的硬件支持，則需要選擇適當的硬件并進行訂貨。獲得硬件的過程通常是信息服務經理的責任。 (21)預備輸出格式 在系統開發過程中，到目前這一時期為止，我們差不多提及了輸出并描述了其有關的內容，然而程序員需要明白具體的輸出形式(即應該如何樣在

47、輸出設備上出現)。這種詳細的輸出講明稱之為輸出格式。項目組產生出顯示屏(VDU)格式，這種格式規定了諸如題目、標題、輸出形式等項，有時還應包括輸入形式。 某些硬拷貝報告和資料要求事先打印好的表格紙，項目組與表格紙廠商的代表合作設計這種事先打印好的表格紙(例如，工資支票和短線)。 項目組還負責設計和滿足在系統范圍內所有人工產生的報告和資料，同時與受有阻礙的用戶經理相配合進行修改、增加或刪除。 (22)描述數據項的講明書 數據項的講明書詳細規定了什么數據將輸入到系統以及它們如何樣被輸入到系統中。 (23)預備程序描述 系統開發進展到目前這一步，我們差不多對現有的系統作了詳盡的分析。它的功能差不多并

48、入建議的系統的設計中，我們差不多完成了建議的系統及其支持的數據庫的設計，同時還預備了所有輸入/輸出詳細的講明書。現在項目組能夠著手標列和確定所有的程序，而這些程序是使得建議的信息系統運轉所要求的。系統的圖形表示(流程圖、HIPO圖和其他)是標列所要求的程序的初始輸入。對每一個程序，項目組編輯下述的資料： 程序語言的種類(例如，COBOL、BASIC、FORTRAN) 程序解講詞的描述描述要執行的任務。 由程序所產生的各種輸出的描述和格式 處理頻率(例如，每天、每周、聯機等) 界限和限制(例如，輸入數據的順序，容量的限制，響應時刻，最大值，最小值等) 詳細講明書(例如，排序，編輯的標準，專門的計

49、算和邏輯操作，各種表格等)。 3.第時期程序設計 項目組現在能夠著手開始與計算機通信了。這種通信(或與計算機的接口)是采取指令形式來進行的，而這些指令被編進計算機程序中。這些計算機程序包括系統運轉所必需的軟件。在第時期程序設計時期將開發支持信息系統所要求的全部軟件。 用戶的介入集中在系統開發的過程前段(第時期)和后段(第和時期)。假如正確地完成了第時期而且用戶與項目組的協作是有“成效”的，那么用戶將專門少介入程序設計時期，甚至完全不用介入。用戶介入最多的情況將反復出現在系統設計需要澄清的時候，有時也出現為第時期(轉換與實現)，作一些初始打算的時候。 不幸的是，有時用戶治理人員也較深地卷進了程序

50、設計時期。這是第時期進行得專門糟糕，而且當開始程序設計時還沒完成的一種標志。這種情況是經常發生的，特不是在時刻緊迫時，項目組常常收到一些強制性的命令要求產生尚未完成的產品。由于系統開發過程的最終產品是軟件，因此有時過早地開始程序設計。這種系統開發方式必定導致產生質量低劣的系統。這種系統并不能滿足用戶的要求，而且維護的代價專門高。這種系統整個壽命期的成本可能是一個高質量的系統的兩到三倍。 (24)指定程序員組長 通常項目組長是一個系統分析員或是一個用戶，他并不直接參與程序設計工作。治理程序設計工作的人應該是程序設計工作實際的參加者，因此，關于要求兩個人以上的程序設計工作，將由信息服務經理指定一個

51、程序員組長。因此，項目組長仍然對整個項目負有責任。 程序員組長有時也稱作為主程序員。他(或她)可能只花10%的時刻在產品的程序設計上。假如只需要治理一個下屬程序員，那么主程序員可能花80%的時刻在產品的程序設計上。 (25)安排順序和分配程序 一個信息系統的軟件包，可能要求幾百個程序。并不需要按照這些程序最終執行的順序來編寫它們，在建立程序開發進度表時，必須考慮到許多變化的因素。在安排程序編制順序時，主程序員應考慮如下問題： 建立和維護測試文件的需要 程序的依靠性(此處一個程序依靠于另一個程序的部分或全部的輸出) 程序的長度和復雜性 依照程序員專業知識的水平、工作效率以及對系統熟悉的程序分配程

52、序。由于經常將程序員分配到其他項目組，從而對專業知識和經驗的要求特不廣泛，因此使程序員與程序相匹配并非易事。 (26)安排預備程序的進度 主程序員能夠利用程序進度表(表20.9.17)來安排和監督下屬程序員的活動以及任一給定程序的狀態。由于程序開發有一個差不多的模式，因此一種類似于用來監督項目進度的技術(表20.9.8和4.9.9)能夠用來監督完成一個特定程序的進度。表20.9.16繪出的甘特表是程序進度表(表20.9.17)的一種圖形表示，而且它是在公告板上能夠看到的一種通用的治理工具。幾乎所有的主程序員和項目組長都經常使用這種公告板。 (27)編制、測試程序和編寫程序資料。 通常一個程序員

53、在一給定的時刻里將同時編制25個程序。開發任一給定的程序的一般的方法本質上是相同的。它們是：圖20.9.16 程序的甘特進度表 預備一般的程序邏輯框圖 預備詳細的程序邏輯框圖 編寫程序(寫程序語句) 測試和調試程序 編寫程序的資料 4.第時期轉換和實現 第時期的目標(轉換和實現)是把在第、和時期的工作結合成一個整體，并將信息系統實現到業務領域。項目組和受阻礙的用戶部門大量地介入第時期的全過程中(見圖20.9.17)。表20.9.17 程序進度表報告標題 程序進度表 日期系統標題 材料要求 標識MR程序標題 標記 程序號 時刻百分比一般邏輯 詳細邏輯 編寫程序 測試和調試形成資料 可能的開始時間

54、 實際的開始時間 提早或推遲天數可能的完成時間 實際的完成時間 提早或推遲的天數每日更新程序 007MR Lois james 50 9.15 9.20 5B 10.30 11.30 21B治理程序 006MR Phil Morrison 100 9.15 9.15 0T 11.15 11.1 10A調度程序 008MR John Speer 80 10.1 1.1庫存狀態程序 042MR Marylou Cummings 40 / 10.15 10.20 4B 11.1材料清單程序 102MR Lois James 20 11.3 11.15 10B 1.15日審計程序 001MR Jim

55、Jones 100 12.1 3周審計程序 002MR John Speer 20 12.101.15 盡管在第時期差不多分不測試了系統的各個成分(程序)，但這并不能保證把它們結合成一個整體時系統將正常工作。因此，在第時期來完成整個系統的測試。在第時期期間，項目組將培訓用戶運行信息系統，轉換現有文件以及建立數據庫。在并行工作之后，系統轉變到業務領域。 (28)完成轉換打算 轉換系統的處理本身確實是一個系統，而且應該像最好的結果那樣來處理。項目組與用戶治理人員以及信息服務審計組合作，共同研究以設計出一項轉換打算。該打算包括：系統驗收測試，文件或數據的轉換，用戶培訓以及并行工作(假如必要的話)的細

56、節。轉換打算詳細地細述了用戶及信息服務人員的義務和責任，同時還規定了進行這些情況的時刻限制。 (29)指導系統驗收測試 盡管差不多測試了各個單獨的程序模塊，然而還沒有把它們結合成一體作為一個系統來處理。一個信息系統可能有100個以上的程序和一打以上的文件，必須把它們作為一個整體來處理以保證使工作協調并使用戶中意。整體的測試將驗證全部系統軟件和應用軟件、輸入/輸出，文件和數據庫以及各種過程。在測試期間用戶人員是實際的參加者。在測試過程中，有可能發覺錯誤(忽略了系統的某些方面)，某些過程的缺點將會暴露出來。能夠確信，一部分驗收測試過程必須在系統設計和程序設計方面進行較小的修改。假如系統是正確開發的

57、，那么任何這種修改將只是微小地調整系統。任何重大的修改應該推遲到系統實現之后，同時至少在進行生產性工作一年之后再進行。這種推遲幸免了通常敲打膝部那種反作用引起的改變而提交可觀的資源。這是因為為了減少重大修改的要求，項目組長和受阻礙的用戶治理人員將要停止信息系統的每一方面。這時，重大修改的要求才是一種分界清晰的標志，它表明有人忽略了他們對項目的責任。 整個系統的測試實際上是分兩個部分完成的。首先利用測試數據來驗證每一個子系統。一旦證實所有子系統的功能是適合的，則有“生存的”數據來測試整個系統。測試數據是為了測試特定的環境而產生的，而“生存的”數據通常是來自過去處理使用的實際的數據。 在測試聯機系

58、統時(現在響應時刻是關鍵問題)，為了測試系統的能力，包括了用幾種生存數據的測試會話。系統可能運行良好，然而由于計算機能力不夠大或是程序的效率不高，也可能導致不可同意的響應時刻。 (30)設計用戶手冊項目組設計一套用戶手冊，同時在對系統驗收測試的同時指導用戶的培訓活動。每個信息系統都應該有一套用戶手冊，它們提供有關系統運行的命令和解釋。用戶手冊和有關的培訓關于系統的最后成功是至關重要的。光有一套用戶手冊是不夠的，這些用戶手冊還必須是一種高質量的資料，它們能對系統的每一方面提供快速和容易的參照。用戶手冊至少包括： 系統的目標 系統的描述 工作流程和一般的操作方法 完成和理解輸入/輸出的命令 數據收

59、集和更新的方法 操縱 其他(例如，術語唯一的詞匯表，硬件的描述和用法，性能的界限，等等) 用戶手冊的內容來自系統資料。然而，在編寫和編譯這種手冊時必須考慮到能為預期的用戶所理解，而且可不能被錯誤地解釋。 (31)提供用戶培訓大綱 假如不能跟培訓相關聯，那么用戶手冊的價值就專門小。項目組的成員指導一系列的培訓課程以使得用戶熟悉系統。用戶培訓大綱的一般內容包括： 系統的用途和目標 現有系統與新系統的差不 系統工作概述 如何使用用戶手冊 與系統有關的信息服務人員和用戶人員的義務和責任 一個有各地分號的大型百貨商店實現了一個聯機銷售點(POS)系統并將用戶手冊分發給每一個POS終端地點。假如沒有正規的培訓，銷售員將丟下他們自己的工作而去揣摹用戶手冊(有100頁以上)以了解系統的用途。由于銷售人員不能處理差不多事務，因此使得顧客不再等待，而跑到其他地點買貨。在他們認識到問題不在于市場、產品質量或地點之前，百貨商店的這些分號幾乎要關閉。問題在于缺乏對系統用戶的訓練。 (32)建立和轉換文件或數據庫 專門難找到一個已實現的系統而不需要修改原有