系統分析員之路----系統分析員基本功 【網路】

//一時無法找到原作者，對不起了

好的系統分析員都是從優秀的程式設計師中產生的，堅實的程式設計功底、豐富的經驗是今後做系統分析的基礎。 

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

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

    系統分析員思想

    全域性觀念是系統分析員必須具備的觀念。

    如果系統分析員設計時太注重細節，往往會陷入在某個問題上糾纏不清的泥潭。（93年，我論文指導老師的一席話影響了我隨後幾年對軟體開發的理解——今後計算機會越來越快，多寫幾行程式碼少寫程式碼無關緊要，最重要的是整體；一開始就錯了，某個部份編得再好，也是沒有用的）系統分析員要有面向使用者的思想。系統分析員應當有能力將自己扮演成使用者，來了解要交付的專案看起來想什麼樣式，感覺想什麼，從而瞭解使用者的想法並挑選出合理部份去開發。從這個意義上說，系統分析員才能獲得有意義的見解去引導他的開發組成員。系統分析員頭腦中要對專案結局有一個清楚的認識，並保證專案不偏離方向。系統分析員要有根植於技術，高於技術思考問題的

    思想。純粹的程式設計師通常對最終結果考慮的不是很多，當一種新的技術在市場上出現時，他們對能否按時交付的考慮就比較少，而強烈希望他們的計劃能夠建立在新的技術之上。因此，系統分析員的想法和行動要象一個使用者，又要能夠站在技術的高度，成為真正的使用者、程式設計師之間的代言人。

    任務難度的預測能力

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

    系統分析員的關鍵

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

    系統分析員的準備工作

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

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

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

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

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

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

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

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

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

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

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

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

    系統分析員基本功

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

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

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

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

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

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/554557/viewspace-521260/，如需轉載，請註明出處，否則將追究法律責任。