如何寫系統分析書



想請大家一起來談談在軟件工程中我們所做的第一步：系統分析。 

在之前見到呂布由 NEASE轉發過來的一個文章，深覺國人的計算機系統能力還需要提高，而更多的代碼人 在找一個對系統更好的開發體系和方式，在代碼聯盟之前的一些貼子中也有i.q他們提 出的這樣的問題，所以我想就這樣的事來與大家共同探討，這樣這個 CCU.Programming.Engineering才有更深的意義，希望我們中國的代碼人能吸取更多更 好的理論和實際的經驗，有附合我們實際情況的系統分析、開發方法、步驟以及文檔。 

系統分析，我個人認為這里應該出來系統的靈魂性的文檔。這樣的文檔應寫什么樣 的內容，表達什么樣的意思是我想在這里與大家談的問題。 我覺得應該說出以下內容（視項目而定）： 

1、系統需求說明 說明系統是一個什么樣的系統，用市場上現有的系統來類比，用客望（或是我們自己） 需要一個什么樣的系統進行說明，力求完整。并對系統的發展可擴充性進行描述（現在 沒有哪個系統是一次OK的）。說明與現有的系統有什么相同什么不同，說明未來系統的 發展方面以及可移值性等能預見的事情。 

2、系統資源說明 對系統所需要的軟件、硬件資源進行說明。描述系統所需要的所有的TCO成本。包括人 員、時間、設備、系統、一次性投入資金、持續性投入資金這樣的所有資源。 

3、系統可行性分析 對系統的實施中的資源進行分析，說明投入的合理性和必然性，對其中的所有不可預見 性的投入進行合理的量化說明，來說明系統的實施的可行性。 以上為我所想到的系統應出現的前三樣文檔，不知大家有什么想法，請賜教。 :) 

作為開發前期的工作，好象也就這么些。但我覺得不夠。還應該包括：總體設計和詳細設計 總體設計 這個階段必須回答的關鍵問題是：“概括地說，應該如何解決這個問題？” 

首先，應該考慮幾種可能的解決方案。列如，目標系統的一些主要功能是用 計算機自動完成還是用人工完成；如果使用計算機，那么是使用批處理方式還是 人機交互方式；信息存儲使用傳統的文件系統還是數據庫……。通常至少應該考慮 下述幾類可能的方案： 

低成本的解決方案。 
系統只能完成最必要的工作，不能多做一點額處的工 作。 

中等成本的解決方案。 
這樣的系統不僅能夠很好地完成預定的任務，使用 起來很方便，而且可能還具有用戶沒有具體指定的某些功能和特點。雖然用戶沒 有提出這些具體要求，但是系統分析員根據自己的知識和經驗斷定，這些附加的 能力在實踐中將證明是很有價值的。 

高成本的“十全十美”的系統。 
這樣的系統具有用戶可能希望有的所有功 能和特點。 系統分析員應該使用系統流程圖或其他工具描述每種可能的系統，估計每種 方案的成本和效益，還應該在充分權衡各種方案的利弊的基礎上，推薦一個較好 的系統（最佳方案），并且制定實現所推薦的系統的詳細計劃。如果用戶接受分 析員推薦的系統，則可以著手完成本階段的另一項主要工作。 

上面的工作確定了解決問題的策略以及目標系統需要哪些程序，但是，怎樣設 計這些程序呢？結構設計的一條基本原理就是程序應該模塊化，也就是一個大程 序應該由許多規模適中的模塊按合理的層次結構組織而成。總體設計階段的第二 項主要任務就是設計軟件的結構，也就是確定程序由哪些模塊組成以及模塊間的 關系。通常用層次圖或結構圖描繪軟件的結構。 

詳細設計 總體設計階段以比較抽象概括的方式提出了解決問題的辦法。 
詳細設計階段 的任務就是把解法具體化，也就是回答下面這個關鍵問題：“應該怎樣具體地實現這 個系統呢？” 這個階段的任務還不是編寫程序，而是設計出程序的詳細規格說明。這種規 格說明的作用很類似于其他工程領域中工程師經常使用的工程藍圖，它們應該 包含必要的細節，程序員可以根據它們寫出實際的程序代碼。 通常用ＨＩＰＯ圖（層次圖加輸入／處理／輸出圖）或ＰＤＬ語言（過程設計語言 ）描述詳細設計的結果。 我想這樣的文檔系統的思路是 一個慢慢積累的過程，如JJX同志所說，我們現在有太多的形式上的東東，它并不是一 個程序員真正需要的系統分析／設計書，對于系統的設計到實施到最后的代碼以及驗收 有太多的改動和變化，我們正在一個極不規范的系統中生存，所以我們不可能有太多的 選擇，只能抄抄應付了事。所以與大家一起探討一個真正適合我們的文檔模式，這個模 式或是說模板能為我們的代碼工作減少負擔，帶來更多的動能 :) 我認為就目前的開發思路，應用環境和編程方法來說，傳統的需求分析-系統分析 -概要設計-詳細設計-。。。已越來越不行樂。 

1。現在的應用和以前大不一樣。現在的應用是一種龐大的集成，包括跨平臺， 網絡，數據庫等等，而且新技術的出現越來越快，任何人都無法精通甚至是掌握 全部技術。 簡單例子：現在有windows,unix,linux等平臺，有sql server,oracle,sybase等 數據庫，有C++,vb,delphi等工具，誰能全部精通呢？如果不能，那么如何確定是 windows+sql server+delphi好還是unix+oracle+C++合適？ 
2。客戶沒有需求 我做過銀行，電信等大客戶，也做過各種小客戶。他們無一另外的說“我要做一個 OA系統”，“我要做一個企業網”，“我要做一個。。。”。可他們無法確定要 實現什么，因為：很少有用戶是真正由于業務的需求而做項目的；而且他們也不清 楚能夠實現什么(因為他們不懂notes,不懂企業網)。 
3。需求與環境的變化 由于在項目開發前客戶沒有實質性的需求，加上軟件開發人員不熟悉客戶的業務， 就導致在開發過程中需求的不斷變化，嚴重時將導致分析與設計作廢。 

4。對象化的工具和過程化的程序 現在的開發工具已經很對象化了，而我們開發的程序卻很過程化。也就是說你雖然 努力的模塊化，層次化，可只要運行環境有所變化，你還要不斷地修改，再修改轅 馬。 實際中是這樣說明我們確實需要把實際中的做法修改一下。 

一個項目如果做到了80%的時候才真正明確則個系統是什么樣子的話，我認為是設計者 的失敗。 我認為在設計階段不但應該做好傳統做法的各種文檔和論證，而且，應該做一些具體 的設計 工作了。比如，系統的整體運行設計及系統各功能模塊的具體設計。而且這些設計應當都 有詳細 的設計說明書。當這些說明書完成后，應當能做到，隨便找個程序員他都能只通過看某功 能模塊的 設計說明書就能夠開始代碼的開發而不用再重新思考該怎樣去做了，程序員在這里就真的 只是一個 設計者的實現工具。 當然，也象某些兄弟說的那樣，現在的系統都越來越繁雜越來越龐大越來越向集成性 質靠攏， 似乎是沒有多少人能掌握具體用什么做效果是否如何如何，但關鍵就是這里。莫非真的沒 有人能 做到這點嗎？非也！只不過是目前的顯示情況是，設計人員的水平偏低，有些公司的設計 人員根本 就沒有多少的開發經驗，他又怎能了解太多的系統呢。系統設計在目前看來似乎是個拿錢 多干活 少的工作，但這是不正常的現象。培養一個程序員根本不用花多大的力氣，一個人只要不 太笨不太 蠢，給他一個機會，相信就能掌握某門技術或方法。但要掌握若干種方法，就不是能夠通 過速成 解決的了。 問題也在于此。目前似乎所有的系統設計人員都能夠設計所有的東西。其實不然。很 多人都有 知識的局限性，這就決定他只能對某些方向的東西做出決策和設計。客戶固然不知道他要 做什么， 但我們應該知道。如果在前期能夠多接觸用戶多深入實際，把設計人員當成客戶工作中的 一員， 他就能夠真正了解到客戶的需求，當然也就能夠為他做出合適的設計。 
至于說到各種系統之間的好壞對比，我想，任何東西都沒有絕對，有的只是某些方面 的權衡。 比如性能或空間的權衡或者價格和性能的權衡，或者就是功能側重上的權衡等等等如此而 已。計算機 里的東西沒有哪一樣的存在不是包含了這種權衡在內的。雖然從商務上似乎總想說服用戶 什么東西好 什么東西不好，其實從技術上講無所謂好和不好，有的只是區別及該區別所針對的問題而 已。這就 象有人總在爭論linux和window到底誰好一樣。或許從“技術”上講，linux比window好， 但這其實 并不公正，因為漂亮的GUI界面和友好的人際交互同樣應該是“技術”中應該考慮到的一部 分。把所有 的東西結合起來一看就知道沒有絕對的好。所以，不見得非要在用戶決定之前由系統設計 的人員 事先來為各種方案做個排隊，只需要了解用戶的需求，然后從大方向上決定一個方向再做 具體設計 就可以了。 繼續我的發言。 

在這里我只從過去的實踐角度舉例來說，至于理論方面實在 沒時間深入。 首先，認同兩個說法： 
1。項目(或說工程)有三個主要方面：功能，時間，成本。 
2。系統分析的任務：將用戶的業務邏輯轉化為程序邏輯，計算時間和成本。 

好，讓我們來做一個概要設計： 
1。功能：簡單的信息發布系統。 
2。系統分析員根據項目的時間和成本，在充分權衡各種方案的利弊的基礎 上提出SQL SERVER+CORBA+DELPHI的方案。 。。。 用戶很滿意，OK， 

開始詳細設計： 

1。為方便用戶的安裝使用三層結構。 

2。客戶端包含信息分布和查詢兩個模塊。 
2。使用各種圖或語言描述各種函數，過程，模塊，層次。 。。。 一切順利，開始編碼。 。。。 編碼完成，用戶試用，這時用戶提出：在客戶端要能實時跟蹤信息的變化， 而你卻發現DELPHI的CORBA不支持回調！轉用其它方按時間上不可能，補救 措施也不靈(比如使用timer，但客戶的網絡環境不允許多個用戶的頻繁刷 新)，怎么辦？ 現在來分析一下問題出在哪里： 
1。有人會說系統分析員不真正了解客戶的需求，可這不可能(項目時間的限 制)也不現實(不可能讓分析員到每個崗位都去操作一下)。 
2。有人會說系統分析員的知識和經驗不足，可現實卻是分析員認為應該的 客戶覺得沒必要，而客戶覺得必須的分析員有不可理解。這是不同的工作造 成的，俗話說隔行如隔山。 
3。有人會說系統分析員的水平不夠，可問題絕大部分是出在細節而不是大方 向上，掌握全部細節可能嗎？ 這里就是一個長期困擾我的問題：細節(而不是方向)往往成為成功與失敗的 關鍵(注意，這里的成功是包含了時間和成本的)，而細節是不可能全部發現 與分析清楚的。如何在這種不完整的需求上構造完整的系統呢？或是根本不 可能呢？ 你說的問題確實存在。而這種問題我就遇到過多次──當然都是別人做的設 計。 但我認為這個過程中不足的地方就是：把東西做死了，沒有切實地為用戶著 想。 很多人在做設計時，可能考慮的最多的是實現上的方便，而不是系統的擴展及 更新。需知道，用戶的需求是在不斷變化的，如果總是在設計前就“善意”地替用 戶假設，是難以預料后事的結局的。所以我想，在設計階段就因該把可能出現的問 題都擺到桌面上討論，包括其特點及效果和后果，而不是自以為是地好心地替用戶 “假設”。 其實一個系統設計的優劣，其系統的擴展性能是一個很重要的指標，一個單純 就事論事地針對某件事情而做出的“專用”系統是沒有任何遠見的。