如何成為一個好的系統分析員

系統分析 業務建模 truely眼中的設計定義：設計的過程就是將交易處理抽象成電腦模型的過程。 
1. 首先要明白設計遠比編程重要。 
2. 平時注重訓練自己的思維嚴謹性和從全域考慮問題的能力。建立冷靜思考問題的處事態度。 
3. 設計時（尤其是資料庫設計時）不要完全被規矩約束，設計好比作詩，懂得韻律是對的，但完全被韻 律所束縛，就作不出好詩了。 
4. 多做設計，經常總結自己的不足之處和成功之處，向他人請教。 
5. 專門去找別人設計的漏洞和不足，也是提高自己設計水平的重要手段。 
（記住：這個好方法不要順便外傳，自己知道就行了，嘻嘻-:） 
6. 經驗是重要的，但如果觀念老化而不善於總結提高，所謂的經驗就成為束縛自己進步的枷鎖。 
7. 學好數學特別是理論數學如數學分析、運籌學、數學模型等。多玩策略性經營遊戲也是有益的。推薦 《帝國時代》和《類比首都3000》以及《大富翁4》。（但不要沉陷在裡面） 
8. 根據項目情況和開發平台工具的特點確定最佳的設計方法。模組化設計方法和物件導向設計。兩種設 計方法的結合使用。 
9. 將複雜無序的過程用模組化的方法進行分解，但要注重事務間的聯絡，並且用開放的眼光去設計。 
10. 設計時對嚴謹性、靈活性、開發效率、客戶要求四個方面做衡量取捨。 
11. 設計時還要根據整個工程的進度安排和客戶對軟體的要求而決定是否設計得足夠靈活和嚴謹。 
12. 複雜而無條理是最糟的設計，簡單實用並不一定是最好的，但一定不是最壞的。（不要說我偷懶喲） 
13. 訓練自己良好的表達能力，能用清晰明確而且簡單的描述表達出自己的基本思路。 
14. 在一個項目中建立統一的系統分析模式和文件範本，同時，一個項目中必須至少有一個人對整個系統 設計進行檢查和進行全域的考慮。 
再談如何成為一個好的系統分析員？ 

bylsfboy 

系統分析員基本功： 

好的系統分析員都是從優秀的程式員中產生的，堅實的編程功底、豐富的經驗是今後做系統分析的基礎。 
沒有對系統本身進行過透徹剖析過，很難領會到其中一些難以言述的精華。但並不等於好的程式員就能夠 成為好的系統分析員。 

合理的知識結構。語言能力、文字表達能力、技術的全面性等是對系統分析員的基本要求。比如說c/s和3 層開發，如果僅僅對netscape公司的產品熟悉還不夠，還需要瞭解比如微軟等產品，並且要瞭解他們中產 生曆史,發展思路，技術優劣，以應付各種窮追猛打的提問。但更重要的是，這是你為應用定製技術要求 的前提。 

系統分析員思想： 

全域觀念是系統分析員必須具備的觀念。如果系統分析員設計時太注重細節，往往會陷入在某個問題上糾 纏不清的泥潭。（93年，我論文指導老師的一席話影響了我隨後幾年對軟體開發的理解----今後電腦會 越來越快，多寫幾行代碼少寫代碼無關緊要，最重要的是整體；一開始就錯了，某個部份編得再好，也是 沒有用的） 

任務難度的預測能力 

系統分析員要具備快速的任務難度預測能力以及具備快速確定開發小組人員構成和任務劃分的能力。（我 將這條歸為思想，而不是能力）昆蟲自然會長出翅膀，而思想卻需要長期的浸潤。要做到這點，需要大量 的思考、學習。設計遠比編程重要。當今軟體業的發展，各種開發工具的出現，編程已經不是什麼問題， 程式員的工作某種程度上講是將別人現成的東西拼湊堆砌起來。系統分析員要清楚的認識到，現在大多數 程式員沒有學會怎麼去整體的瞭解一個系統，有些甚至不瞭解編程（這不是說他們不會寫代碼）。可視化 的開發工具加五花八門的控制項，程式員可以偷點懶了。（這可不是誇大，我好幾年的管理工作，接觸過大 量的程式員）基於技術，跳出架構。基於現有技術結合使用者需求思考問題，設計時跳出架構。 

系統分析員思想： 

系統分析員要有面向使用者的思想。系統分析員應當有能力將自己扮演成使用者，來瞭解要交付的項目看起來 想什麼樣式，感覺想什麼，從而瞭解使用者的想法並挑選出合理部份去開發。從這個意義上說，系統分析員 才能獲得有意義的見解去引導他的開發群組成員。系統分析員頭腦中要對項目結局有一個清楚的認識，並保 證項目不偏離方向。系統分析員要有根植於技術，高於技術思考問題的思想。純粹的程式員通常對最終結 果考慮的不是很多，當一種新的技術在市場上出現時，他們對能否按時交付的考慮就比較少，而強烈希望 他們的計劃能夠建立在新的技術之上。因此，系統分析員的想法和行動要象一個使用者，又要能夠站在技術 的高度，成為真正的使用者、程式員之間的代言人。 

系統分析員的關鍵 

獲得信任。系統分析員最重要的素質是獲得信任，這是成為優秀系統分析員的關鍵。成熟最為關鍵。成熟 可以為整個項目組提供正確的支援,能夠理解技術怎樣才能解決使用者的需求。 

系統分析員的準備工作 

統一的各種文檔模式，這其中包括今後軟體變數、欄位命名規則。我推薦用pb制定的規則做基礎，通過改 造成為適合自身實用的標準。統一的文件管理。統一的分析軟體。比如說rose（uml太規範，國內的軟體 管理水平根本用不上，只不過盡量應用，你自己對系統分析的理解有好處） 方法是思想的放映，在具體方法上就不多說了。我託人從u$a弄到幾本書，用於物件導向系統開發的使 用》、《物件導向的分析》、《專案管理》等都是很不錯的，推薦大家看看。 

我在拙作"在中國沒有人懂電腦"裡發了點牢騷，聽說挨了部份人（習慣性的）罵。其實，bbs本來就是 發泄的地方，在這裡從來就罕有有內容的文章。 

自從"維納斯"登陸深圳後，大家更著眼於從宏觀看中國的it業了。中國it這棵小樹，說實在的，長到今天 實在是不容易。一些人提出了"反對微軟霸權"的口號，不少人呼喚中國"矽谷"的出現。微軟的成功不是技 術的成功，更多的是商業運作的成功。中國it這棵樹能長多高，取決於他所植根於的土壤。而現在的事實是，這片土壤實在是太貧瘠了！如果按我們現在的思路和搞法，是長不成大樹，更別指望能結出"微 軟"，"矽谷"這樣豐碩的果實。如果說，我們的軟體技術落後美國十年，我們的硬體製造技術則落後美國 二十年，我們的管理水平落後美國至少三十年。而最終決定發展速率的恰恰是我們的死穴──低劣的管理 水平。低劣的管理水平的形成的原因有著深厚的背景和多方面的原因。 

系統分析工作是解決一個問題的工作,目標是將一個對電腦應用系統的需求轉化成實際的物理實現,其中 複雜就複雜在實際的面太多.在系統分析過程之中注意問以下的問題,可能會所進行的系統分析設計工作有 協助. 

1)您所完成的系統目的是什麼?注意不是功能要求,而是目的.也就是為什麼要建設、為什麼要現代建設。 

2）您所完成的系統有哪些方面參與，各方面的初衷是什嗎？那些人可能在系統建設中起重要作用，他們 會採取什麼樣的態度？你對他們有多少影響力？ 

3）您的系統是否有一個明確的評價標準？最好從參與的各方面都進行考慮。 

4）你的系統設計思想是什嗎？是否能夠得到各方面的認可。 

5）你對參與系統設計開發的人員瞭解嗎？他們的特長在哪裡，是否願意與你合作，為什嗎？你對他們有 足夠的影響力嗎？ 

6）你的系統開發計劃是否完善？你的計劃表有明確的階段嗎？任何一階段都應該怎樣完成？如何對這一 階段完成的情況進行評價？ 

7）你對所採用的系統開發方法以及工具是否熟悉？你的夥伴是否熟悉？ 

8）你所完成的系統是否有原型？電腦的或者物理的。 

以上的幾個問題都是在系統分析以及系統規劃時涉及到的，供各位參考。 

系統分析工作是解決一個問題的工作,目標是將一個對電腦應用系統的需求轉化成實際的物理實現,其中 複雜就複雜在實際的面太多.在系統分析過程之中注意問以下的問題,可能會所進行的系統分析設計工作有協助 

1)您所完成的系統目的是什麼?注意不是功能要求,而是目的.也就是為什麼要建設、為什麼要現代建設。在考慮系統目的時，我更多的側重於系統的最終目標考慮，因為一個系統不可能一下子完美，為系統留些 餘地。 

2）您所完成的系統有哪些方面參與，各方面的初衷是什嗎？那些人可能在系統建設中起重要作用，他們 會採取什麼樣的態度？你對他們有多少影響力？中國it行業的失敗之一就是人"太年輕"，一定要有領導的 支援，否則完蛋。不要認為自己對他們會有多少影響力，即便有，也要儘可能的認為是決策者再影響他 們。在中國，一個技術員，你算老幾？說到這裡我很悲哀。哪些人在系統中起重要作用並弄清楚他們的態 度，這點十分關鍵。 

3）您的系統是否有一個明確的評價標準？最好從參與的各方面都進行考慮。不知道這樣說對不對，在系 統建設之前，對你的程式員、對你的領導要有至少不同的兩種評價。 

4）你的系統設計思想是什嗎？是否能夠得到各方面的認可。如果高明，對領導、對程式員都採用引導， 得到認可的最好辦法，就是讓他們認可他們自己的想法。（我力圖這樣做，但做得不好，系統分析員有一 點要學會韜光養晦，忍） 

5）你對參與系統設計開發的人員瞭解嗎？他們的特長在哪裡，是否願意與你合作，為什嗎？你對他們有 足夠的影響力嗎？軟體發展到一定的程度，不是編程，不是數學，而是管理。 

6）你的系統開發計劃是否完善？你的計劃表有明確的階段嗎？任何一階段都應該怎樣完成？如何對這一 階段完成的情況進行評價？ 

7）你對所採用的系統開發方法以及工具是否熟悉？你的夥伴是否熟悉？事實上，不是每種好的工具都要 使用，也並不一定都要他們熟練掌握。提醒諸位一句，當你將方案做得可以不依賴某個程式員，你在程式 員面前就無信任可言，因為從此程式員將受到更大的生存壓力。我堅決不在公司使用rose。 

8）你所完成的系統是否有原型？電腦的或者物理的。 

以上的幾個問題都是在系統分析以及系統規劃時涉及到的，供各位參考。 

這文章很好，我的話是："需求分析實際應該是問題分析"。含義是系統要解決的是問題。而不是使用者提出 的需求。經常發現系統完成後，客戶說"我的問題還沒有解決"。可是，需求分析稿上的目標都搞定了。 

既然是問題分析，所以，熟悉目標系統的知識就是必要的。甚至，可以說，一個好的系統分析員也應該是 好的業務專家。 

我很高興在這裡遇到許多分析高手，可以交串流分析中的問題。我贊同從來的觀點。在中國作分析重要的是 人氣，因為中國的企業級資訊系統的建設在很大程度上可以說並非確有需求，而是迫於某種壓力。使用者在 很多時候考慮的不是系統的長遠發展，而只是短期的成果，要求開發單位在很短的時間內完成一個很大的 系統的開發，沒有時間對系統進行周密的分析，在這種情況下，很多開發商就會粗分析，粗設計，儘快進 入編碼階段，這樣的系統的生命週期肯定不會很長。說了這麼多，只是想說，系統分析員確實應是業務和 管理專家，並且需要有很好的語言群組織能力，他需要根據問題域中存在的問題去儘力說服使用者，引導使用者 需求，畢竟，我們是專家，如果讓使用者牽著鼻子走，系統不會是成功的系統。（當然了，這要建立在使用者 是可引導的前提下）本人拙見。 

在理解和分析使用者的需求時，應說服使用者明白：建立電腦應用系統並不是簡單地用電腦代替手工勞 
作，它更應該是管理思想的一次革命，是現使用者模式的一次升華和提高。如果系統不能高於現實，開發的系統將長期陷入需求的反覆修改，其軟體的生命週期也短了。 

針對我對您的問題的理解,試著作如下一般性/理論性的回複: 

需求分析(您可以採用usecasedriven的方法進行需求分析)在明確需求分析的基礎上,確定需要採用的系統分析方法(結構化/物件導向/構件式)應用您的Team Dev所確定採用的分析/設計方法,進行系統分析.根據您所採用的分析方法,依次或反覆進行系統設計/建模. 

任何一套軟體系統的模型的建立,是必須的根據所建立模型的性質上,依次或反覆進行系統實現題是這樣 
的，我用pb編程已有一年半時間，其間也做過7，8個程式，有自己獨立開發的，也有和別人合作完成的。 
大部份都是與使用者談一談，瞭解了使用者的基本需求後，就立即開始編寫程式，其間頂多有不懂的地方再向使用者瞭解情況，直到編程完成。從來也沒有想過什麼別的，就算有文檔一類的東西也多是編完了再寫。但往往事後維護量特別大，使用者反映缺少功能，或者認為遍出來的東西並非他所想要的。雖然最後都完成了，但感覺特別費勁。也看了一些軟體工程方面的書，但總感覺不實用，因此想看看別人是怎樣做的，是否自己看書方法不對，沒有掌握系統分析方面的精髓。同時我感到自己長期以來，在編程方面沒有絲毫進步，是否與沒有理論基礎有關。