如何寫系統(tǒng)分析書
如何寫系統(tǒng)分析書 By Cooljob, Chinacode,yu_jin, i.q. 想請大家一起來談談在軟件工程中我們所做的第一步： 系統(tǒng)分析 系統(tǒng)分析，我個人認為這里應該出來系統(tǒng)的靈魂性的文檔。這樣的文檔應該說出以下內(nèi) 容（視項目而定）： 1、系統(tǒng)需求說明 說明系統(tǒng)是一個什么樣的系統(tǒng)，用市場上現(xiàn)有的系統(tǒng)來類比，用客戶（或是我們自己） 需要一個什么樣的系統(tǒng)進行說明，力求完整。并對系統(tǒng)的發(fā)展可擴充性進行描述（現(xiàn)在 沒有哪個系統(tǒng)是一次OK的）。說明與現(xiàn)有的系統(tǒng)有什么相同什么不同，說明未來系統(tǒng)的 發(fā)展方面以及可移值性等能預見的事情。 2、系統(tǒng)資源說明 對系統(tǒng)所需要的軟件、硬件資源進行說明。描述系統(tǒng)所需要的所有的TCO成本。包括人 員、時間、設備、系統(tǒng)、一次性投入資金、持續(xù)性投入資金這樣的所有資源。 3、系統(tǒng)可行性分析 對系統(tǒng)的實施中的資源進行分析，說明投入的合理性和必然性，對其中的所有不可預見 性的投入進行合理的量化說明，來說明系統(tǒng)的實施的可行性。 作為開發(fā)前期的工作，我覺得還應該包括：總體設計和詳細設計。 總體設計 這個階段必須回答的關(guān)鍵問題是：“概括地說，應該如何解決這個問題？” 首先，應該考慮幾種可能的解決方案。例如，目標系統(tǒng)的一些主要功能是用計算機自動 完成還是用人工完成；如果使用計算機，那么是使用批處理方式還是人機交互方式；信 息存儲使用傳統(tǒng)的文件系統(tǒng)還是數(shù)據(jù)庫……。通常至少應該考慮下述幾類可能的方案： 低成本的解決方案 系統(tǒng)只能完成最必要的工作，不能多做一點額處的工作。 中等成本的解決方案 這樣的系統(tǒng)不僅能夠很好地完成預定的任務，使用起來很方便，而且可能還具有用戶沒 有具體指定的某些功能和特點。雖然用戶沒有提出這些具體要求，但是系統(tǒng)分析員根據(jù) 自己的知識和經(jīng)驗斷定，這些附加的能力在實踐中將證明是很有價值的。 高成本的“十全十美”的系統(tǒng) 這樣的系統(tǒng)具有用戶可能希望有的所有功能和特點。 系統(tǒng)分析員應該使用系統(tǒng)流程圖或其他工具描述每種可能的系統(tǒng)，估計每種方案的成本 和效益，還應該在充分權(quán)衡各種方案的利弊的基礎上，推薦一個較好的系統(tǒng)（最佳方案 ），并且制定實現(xiàn)所推薦的系統(tǒng)的詳細計劃。如果用戶接受分析員推薦的系統(tǒng)，則可以 著手完成本階段的另一項主要工作。 上面的工作確定了解決問題的策略以及目標系統(tǒng)需要哪些程序，但是，怎樣設計這些程 序呢？結(jié)構(gòu)設計的一條基本原理就是程序應該模塊化，也就是一個大程序應該由許多規(guī) 模適中的模塊按合理的層次結(jié)構(gòu)組織而成?？傮w設計階段的第二項主要任務就是設計軟 件的結(jié)構(gòu)，也就是確定程序由哪些模塊組成以及模塊間的關(guān)系。通常用層次圖或結(jié)構(gòu)圖 描繪軟件的結(jié)構(gòu)。 詳細設計 總體設計階段以比較抽象概括的方式提出了解決問題的辦法。詳細設計階段的任務就是 把解法具體化，也就是回答下面這個關(guān)鍵問題：“應該怎樣具體地實現(xiàn)這個系統(tǒng)呢？” 這個階段的任務還不是編寫程序，而是設計出程序的詳細規(guī)格說明。這種規(guī)格說明的作 用很類似于其他工程領域中工程師經(jīng)常使用的工程藍圖，它們應該包含必要的細節(jié)，程 序員可以根據(jù)它們寫出實際的程序代碼。通常用ＨＩＰＯ圖（層次圖加輸入／處理／輸 出圖）或ＰＤＬ語言（過程設計語言）描述詳細設計的結(jié)果。 我想這樣的文檔系統(tǒng)的思路是一個慢慢積累的過程，如一些開發(fā)人員所說，我們現(xiàn)在有 太多的形式上的東西，它并不是一個程序員真正需要的系統(tǒng)分析／設計書，對于系統(tǒng)的 設計到實施到最后的代碼以及驗收有太多的改動和變化，我們正在一個極不規(guī)范的系統(tǒng) 中生存，所以我們不可能有太多的選擇，只能草草應付了事。所以需要探索得出一個真 正適合我們的文檔模式，這個模式或是說模板能為我們的代碼工作減少負擔，帶來更多 的動能。 1。現(xiàn)在的應用和以前大不一樣 現(xiàn)在的應用是一種龐大的集成，包括跨平臺， 網(wǎng)絡，數(shù)據(jù)庫等等，而且新技術(shù)的出現(xiàn)越來越快，任何人都無法精通甚至是掌握 全部技術(shù)。 簡單例子：現(xiàn)在有windows,unix,linux等平臺，有sql server,oracle,sybase等 數(shù)據(jù)庫，有C++,vb,delphi等工具，誰能全部精通呢？如果不能，那么如何確定是 windows+sql server+delphi好還是unix+oracle+C++合適？ 2?？蛻魶]有需求 我做過銀行，電信等大客戶，也做過各種小客戶。他們無一例外的說“我要做一個OA系統(tǒng) ”，“我要做一個企業(yè)網(wǎng)”，“我要做一個。。?！薄？伤麄儫o法確定要實現(xiàn)什么，因為：很 少有用戶是真正由于業(yè)務的需求而做項目的；而且他們也不清楚能夠?qū)崿F(xiàn)什么(因為他們 不懂notes,不懂企業(yè)網(wǎng))。 3。需求與環(huán)境的變化 由于在項目開發(fā)前客戶沒有實質(zhì)性的需求，加上軟件開發(fā)人員不熟悉客戶的業(yè)務，就導 致在開發(fā)過程中需求的不斷變化，嚴重時將導致分析與設計作廢。 4。對象化的工具和過程化的程序 現(xiàn)在的開發(fā)工具已經(jīng)很對象化了，而我們開發(fā)的程序卻很過程化。也就是說你雖然努力 的模塊化，層次化，可只要運行環(huán)境有所變化，你還要不斷地修改，再修改源碼。這說 明我們確實需要把實際中的做法修改一下。 一個項目如果做到了80%的時候才真正明確則個系統(tǒng)是什么樣子的話，我認為是設計者 的失敗。我認為在設計階段不但應該做好傳統(tǒng)做法的各種文檔和論證，而且，應該做一 些具體的設計工作了。比如，系統(tǒng)的整體運行設計及系統(tǒng)各功能模塊的具體設計。而且 這些設計應當都有詳細的設計說明書。當這些說明書完成后，應當能做到，隨便找個程 序員他都能只通過看某功能模塊的設計說明書就能夠開始代碼的開發(fā)而不用再重新思考 該怎樣去做了，程序員在這里就真的只是一個設計者的實現(xiàn)工具。 當然，現(xiàn)在的系統(tǒng)都越來越繁雜越來越龐大越來越向集成性質(zhì)靠攏，似乎是沒有多少人 能掌握具體用什么做效果是否如何如何，但關(guān)鍵就是這里。莫非真的沒有人能做到這點 嗎？非也！只不過是目前的顯示情況是，設計人員的水平偏低，有些公司的設計人員根 本就沒有多少的開發(fā)經(jīng)驗，他又怎能了解太多的系統(tǒng)呢。系統(tǒng)設計在目前看來似乎是個 拿錢多干活少的工作，但這是不正常的現(xiàn)象。培養(yǎng)一個程序員根本不用花多大的力氣， 一個人只要不太笨不太蠢，給他一個機會，相信就能掌握某門技術(shù)或方法。但要掌握若 干種方法，就不是能夠通過速成解決的了。 問題也在于此。目前似乎所有的系統(tǒng)設計人員都能夠設計所有的東西。其實不然。很多 人都有知識的局限性，這就決定他只能對某些方向的東西做出決策和設計?？蛻艄倘徊?知道他要做什么，但我們應該知道。如果在前期能夠多接觸用戶多深入實際，把設計人 員當成客戶工作中的一員， 他就能夠真正了解到客戶的需求，當然也就能夠為他做出合適的設計。 至于說到各種系統(tǒng)之間的好壞對比，我想，任何東西都沒有絕對，有的只是某些方面的 權(quán)衡。比如性能或空間的權(quán)衡或者價格和性能的權(quán)衡，或者就是功能側(cè)重上的權(quán)衡等等 等如此而已。計算機里的東西沒有哪一樣的存在不是包含了這種權(quán)衡在內(nèi)的。雖然從商 務上似乎總想說服用戶什么東西好什么東西不好，其實從技術(shù)上講無所謂好和不好，有 的只是區(qū)別及該區(qū)別所針對的問題而已。 所以，不見得非要在用戶決定之前由系統(tǒng)設計的人員事先來為各種方案做個排隊，只需 要了解用戶的需求，然后從大方向上決定一個方向再做具體設計就可以了。 從過去的實踐角度舉例來說。首先，認同兩個說法： 1。項目(或說工程)有三個主要方面：功能，時間，成本。 2。系統(tǒng)分析的任務：將用戶的業(yè)務邏輯轉(zhuǎn)化為程序邏輯，計算時間和成本。 讓我們來做一個概要設計： 1。功能：簡單的信息發(fā)布系統(tǒng)。 2。系統(tǒng)分析員根據(jù)項目的時間和成本，在充分權(quán)衡各種方案的利弊的基礎上提出SQL SERVER+CORBA+DELPHI的方案。 。。。 用戶很滿意，OK， 開始詳細設計： 1。為方便用戶的安裝使用三層結(jié)構(gòu)。 2?？蛻舳税畔⒎植己筒樵儍蓚€模塊。 3。使用各種圖或語言描述各種函數(shù)，過程，模塊，層次。 。。。 一切順利，開始編碼。 。。。 編碼完成，用戶試用，這時用戶提出：在客戶端要能實時跟蹤信息的變化，而你卻發(fā)現(xiàn) DELPHI的CORBA不支持回調(diào)！轉(zhuǎn)用其它方案時間上不可能，補救措施也不靈(比如使用ti mer，但客戶的網(wǎng)絡環(huán)境不允許多個用戶的頻繁刷新)，怎么辦？ 現(xiàn)在來分析一下問題出在哪里： 1。有人會說系統(tǒng)分析員不真正了解客戶的需求，可這不可能(項目時間的限制)也不現(xiàn)實 (不可能讓分析員到每個崗位都去操作一下)。 2。有人會說系統(tǒng)分析員的知識和經(jīng)驗不足，可現(xiàn)實卻是分析員認為應該的，客戶覺得沒 必要，而客戶覺得必須的分析員又不可理解。這是不同的工作造成的，俗話說隔行如隔 山。 3。有人會說系統(tǒng)分析員的水平不夠，可問題絕大部分是出在細節(jié)而不是大方向上，掌握 全部細節(jié)可能嗎？ 這里就是一個長期困擾我的問題：細節(jié)(而不是方向)往往成為成功與失敗的關(guān)鍵(注意， 這里的成功是包含了時間和成本的)，而細節(jié)是不可能全部發(fā)現(xiàn)與分析清楚的。 如何在這種不完整的需求上構(gòu)造完整的系統(tǒng)呢？或是根本不可能呢？我認為這個過程中 不足的地方就是：把東西做死了，沒有切實地為用戶著想。很多人在做設計時，可能考 慮的最多的是實現(xiàn)上的方便，而不是系統(tǒng)的擴展及更新。需知道，用戶的需求是在不斷 變化的，如果總是在設計前就“善意”地替用戶假設，是難以預料后事的結(jié)局的。 所以我想，在設計階段就因該把可能出現(xiàn)的問題都擺到桌面上討論，包括其特點及效果 和后果，而不是自以為是地好心地替用戶“假設”。 其實一個系統(tǒng)設計的優(yōu)劣，其系統(tǒng)的擴展性能是一個很重要的指標，一個單純就事論事 地針對某件事情而做出的“專用”系統(tǒng)是沒有任何遠見的。
如何寫系統(tǒng)分析書