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

2019-11-17 04:40:16

字體：大中小

來源：轉載

供稿：網友

truely眼中的設計定義：設計的過程就是將事務處理抽象成計算機模型的過程。

　　1. 首先要明白設計遠比編程重要。

　　2. 平時注重練習自己的思維嚴謹性和從全局考慮問題的能力。建立冷靜思考問題的處事態度。

　　3. 設計時（尤其是數據庫設計時）不要完全被規矩約束，設計好比作詩，懂得韻律是對的，但完全被韻律所束縛，就作不出好詩了。

　　4. 多做設計，經常總結自己的不足之處和成功之處，向他人請教。

　　5. 專門去找別人設計的漏洞和不足，也是提高自己設計水平的重要手段。

　　（記住：這個好方法不要順便外傳，自己知道就行了，嘻嘻-:）

　　6. 經驗是重要的，但假如觀念老化而不善于總結提高，所謂的經驗就成為束縛自己進步的枷鎖。

　　7. 學好數學非凡是理論數學如數學分析、運籌學、數學模型等。多玩策略性經營游戲也是有益的。推薦《帝國時代》和《模擬首都3000》以及《大富翁4》。（但不要沉陷在里面）

　　8. 根據項目情況和開發平臺工具的特點確定最佳的設計方法。模塊化設計方法和面向對象設計。兩種設計方法的結合使用。

　　9. 將復雜無序的過程用模塊化的方法進行分解，但要注重事務間的聯系，并且用開放的眼光去設計。

　　10. 設計時對嚴謹性、靈活性、開發效率、客戶要求四個方面做衡量取舍。

　　11. 設計時還要根據整個工程的進度安排和客戶對軟件的要求而決定是否設計得足夠靈活和嚴謹。

　　12. 復雜而無條理是最糟的設計，簡單實用并不一定是最好的，但一定不是最壞的。（不要說我偷懶喲）

　　13. 練習自己良好的表達能力，能用清楚明確而且簡單的描述表達出自己的基本思路。

　　14. 在一個項目中建立統一的系統分析模式和文檔模板，同時，一個項目中必須至少有一個人對整個系統設計進行檢查和進行全局的考慮。

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

　　bylsfboy

　　系統分析員基本功：

　　好的系統分析員都是從優秀的程序員中產生的，堅實的編程功底、豐富的經驗是今后做系統分析的基礎。

　　沒有對系統本身進行過透徹剖析過，很難領會到其中一些難以言述的精華。但并不等于好的程序員就能夠成為好的系統分析員。

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

　　系統分析員思想：

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

　　任務難度的猜測能力

　　系統分析員要具備快速的任務難度猜測能力以及具備快速確定開發小組人員構成和任務劃分的能力。（我將這條歸為思想，而不是能力）昆蟲自然會長出翅膀，而思想卻需要長期的浸潤。要做到這點，需要大量的思考、學習。設計遠比編程重要。當今軟件業的發展，各種開發工具的出現，編程已經不是什么問題，

　　程序員的工作某種程度上講是將別人現成的東西拼湊堆砌起來。系統分析員要清楚的熟悉到，現在大多數程序員沒有學會怎么去整體的了解一個系統，有些甚至不了解編程（這不是說他們不會寫代碼）。可視化的開發工具加五花八門的控件，程序員可以偷點懶了。（這可不是夸大，我好幾年的治理工作，接觸過大量的程序員）基于技術，跳出框架。基于現有技術結合用戶需求思考問題，設計時跳出框架。

　　系統分析員思想：

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

　　系統分析員的要害

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

　　系統分析員的預備工作

　　統一的各種文檔模式，這其中包括今后軟件變量、字段命名規則。我推薦用pb制定的規則做基礎，通過改造成為適合自身實用的標準。統一的文檔治理。統一的分析軟件。比如說rose（uml太規范，國內的軟件治理水平根本用不上，只不過盡量應用，你自己對系統分析的理解有好處）

　　方法是思想的放映，在具體方法上就不多說了。我托人從u$a弄到幾本書，用于面向對象系統開發的使

　　用》、《面向對象的分析》、《項目治理》等都是很不錯的，推薦大家看看。

　　我在拙作“在中國沒有人懂計算機“里發了點牢騷，聽說挨了部份人（習慣性的）罵。其實，bbs本來就是發泄的地方，在這里從來就罕有有內容的文章。自從“維納斯“登陸深圳后，大家更著眼于從宏觀看中國的it業了。中國it這棵小樹，說實在的，長到今天實在是不輕易。一些人提出了“反對微軟霸權“的口號，不少人呼喚中國“硅谷“的出現。微軟的成功不是技術的成功，更多的是商業運作的成功。

中國it這棵樹能長多高，取決于他所植根于的土壤。而現在的事實是，這片土壤實在是太貧瘠了！假如按我們現在的思路和搞法，是長不成大樹，更別指望能結出“微軟“，“硅谷“這樣豐碩的果實。假如說，我們的軟件技術落后美國十年，我們的硬件制造技術則落后美國二十年，我們的治理水平落后美國至少三十年。而最終決定發展速率的恰恰是我們的死穴──低劣的治理水平。低劣的治理水平的形成的原因有著深厚的背景和多方面的原因。

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

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

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

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

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

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

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

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

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

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

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

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

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

　　在理解和分析用戶的需求時，應說服用戶明白：建立計算機應用系統并不是簡單地用計算機代替手工勞作，它更應該是治理思想的一次革命，是現用戶模式的一次升華和提高。假如系統不能高于現實，開發的系統將長期陷入需求的反復修改，其軟件的生命周期也短了。

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

　　需求分析(您可以采用usecasedriven的方法進行需求分析)在明確需求分析的基礎上,確定需要采用的系統分析方法(結構化/面向對象/構件式)應用您的開發團隊所確定采用的分析/設計方法,進行系統分析.根據您所采用的分析方法,依次或反復進行系統設計/建模.

　　任何一套軟件系統的模型的建立,是必須的根據所建立模型的性質上,依次或反復進行系統實現題是這樣

　　的，我用pb編程已有一年半時間，其間也做過7，8個程序，有自己獨立開發的，也有和別人合作完成的。

　　大部份都是與用戶談一談，了解了用戶的基本需求后，就立即開始編寫程序，其間頂多有不懂的地方再向用戶了解情況，直到編程完成。從來也沒有想過什么別的，就算有文檔一類的東西也多是編完了再寫。但往往事后維護量非凡大，用戶反映缺少功能，或者認為遍出來的東西并非他所想要的。雖然最后都完成了，但感覺非凡費勁。也看了一些軟件工程方面的書，但總感覺不實用，因此想看看別人是怎樣做的，是否自己看書方法不對，沒有把握系統分析方面的精髓。
同時我感到自己長期以來，在編程方面沒有絲毫進步，是否與沒有理論基礎有關。

上一篇：統一建模語言(UML)的現狀及發展

下一篇：協議型網絡游戲外掛制作之外掛窗口