做自己的系統分析師

這幾天我在看軟考的《系統分析師教程》，六百多頁的書看了兩百多頁，現在感覺心裡很複雜。再加上前幾天和以前幾個要好同僚聚會，談到軟體系統的設計時有些争論，讓我不得不寫些什麼。希望此文能以此文同中國從事軟體開發的同行共勉。

前言

說來很不巧，我畢業于四川外語學院，沒有受到過大學裡面正規計算機課程的教育，在軟體設計上的所有技能，基本上都是學習人家的代碼，和看微軟網站上的那些TechNotes。當時之是以選擇英語院校，希望讀懂人家的技術文檔，是其中的一個原因。畢竟從現在很流行的Windows到Unix，他們的技術文檔大都是英文寫的。扯遠了，其實開發一個好的系統，看懂有價值的技術資料是一個因素，更重要的因素在于對系統的分析和設計。

由于自己沒有受到過真正的計算機方面的理論教育，是以最初，在進行軟體開發的時候心裡面特别沒有底，在寫代碼的時候，我都特别小心，生怕寫出來的程式在結構上不合理，執行效率低下。工作了一段時間，開始自己設計軟體的系統的一部分，當時又怕自己設計出來的系統在結構上不合理，使後期開發無法進行。是以，我一都在思考軟體的設計方法，不斷的總結。

一直以來，我把系統設計、分析看成是一件很神聖的工作，雖然自己很早聽說過有這樣的考試認證，但是還是沒有去報名，甚至沒有去買考試用書。其原因就是我認為自己應該先多寫代碼，多接觸工程實踐，多積累一些經驗，然後再來接受系統分析的工程方法。而現在，我在這行幹了五年，我想我的經曆應該可以讓我來接受正規的系統分析方法了吧！ 是以，我要把我學習的過程和我以前在工作中對系統分析的一些經驗寫出來，希望大家批評、指教！

第一篇 系統分析到底分析些什麼

一句話，系統分析就是“分析軟體系統在它的生存周期與生存環境中，各個對象與它的關系 ”，記住是關系，這是我這幾天看書，然後結合自己的開發經曆所得出的結論。

一個大型的軟體系統，它所涉及的關系多，是以這個系統做起來就複雜；一個小的軟體，它所涉及的關系少，是以這個軟體做起來就簡單。但是在通常的情況下，這些關系需要系統分析人員去發現，通過各種手段：翻閱資料、采訪相關人員等等。如果越多的關系被系統分析人員發現，那麼系統分析員對系統的設計可能就越全面，系統結構對未來的不确定因素的适應能力可能會更強。

在這裡，我一直在強調“可能”。在我開始思考系統設計之前，我就覺得隻要我掌握了正确的系統分析方法，那麼我設計出來的系統在結構上是最合理的，在性能上是最穩定的，這個系統近乎是一個完美的系統。現在看來，這種想法很幼稚，作為對關系的分析，本身就和個人的經驗、價值觀有直接的、非常緊密的聯系。是以我們要正确的對待系統分析師這個職業，他不是神，他隻是一個将系統的開發風險盡可能降低到最低的人。

第二篇 如何分析

并不是每個公司都有自己專門的系統分析師，但是每個公司都有自己的系統分析工作，我想這是中國大多數軟體公司所面臨的現狀吧。我們不能夠因為沒有系統分析師的存在，而把那些客觀存在，需要我們去分析的東西丢在一邊，最後隻能是搬起石頭紮自己的腳。

看了《系統分析教程》之後，讓我對如何做系統分析有了新的認識，但是裡面提到的各種方法，動不動就要小組支援，安排會議，這些活動檔次太高，咱們平時做的那些系統玩不起，那是不是是以我們就放棄系統分析呢？答案是否定的。我認為，軟體系統的規模有大小，系統分析的規模也有大小，不同規模的系統，它的分析方法也應該不一樣，下面我把我分析的方法寫出來，希望大家批評指教。

接到一個工程後，腦子裡對這個工程大緻有個數，然後就把開發工具打開，開始幹了（這種方法很土，和軟體工程方法是背道而馳的）。 但是，當代碼寫道一定程度的時候一定要停下來，你要對以做的開發做記錄。記錄什麼呢？比如：重要的處理過程，窗體的名稱以及它的功能描述以及你當時認為有用的東西。然後繼續寫代碼。在後來的開發過程中，當你回複前一段時間寫的代碼而不能馬上了解它的意思的時候，你就得馬上記錄。當軟體快開發到一半的時候，這時你對軟體的整體構架比較清晰了，你就得分析出軟體的基礎子產品，回顧以前的記錄文檔，看是否有其它子產品也擁有你分析出來的基礎子產品的功能，如果有，那麼就得對程式進行調整。調整完成之後，你就可以繼續後面的開發了，系統做到這個地步，一般成功的把握就有90％了。這種方法隻适合于做規模比較小的系統，例如一般的進銷存系統，功能比較單一的小軟體。

後來我把這種分析方法命名為攀岩式分析，作為一個攀登者，需要的是力氣和勇氣來面對面前的大山，然後邁出第一步，攀登一截就打下一個釘子固定好，然後繼續攀登，就算不小心失足，由于有前面的釘子固定，也不至于掉下萬丈深淵。

在沒有系統分析團隊支援的情況下，這種方法可以在一定程度上降低軟體系統的開發和維護風險

當拿到一個系統開發任務的時候，先整理出開發任務中的資料對象，然後然後分析他們之間的關系，通過關系的分析，找出隐藏的資料對象；确定軟體的功能架構，根據功能架構，畫出資料流圖和控制流圖；分析基本的功能架構，然後做出一個基本的系統，然後拿給“上司 ”看。 

以上的描述是我碰到的真是情況後的處理辦法，這個辦法結合了結構化分析和原型開發中容易操作部分。

在很多時候，我們可能接到一個比較大的開發任務，而拿到手裡的卻是一頁草草幾十字的“需求分析”，并且可能是有問題的需求分析。因為那頁紙上寫的内容實際上也是系統分析範疇中的資料，但是裡面卻雜糅子產品功能描述、資料實體描述、資料存儲描述等等資訊。而我們該怎麼辦，撒手不幹了？

這時，首先要做的就是挑出裡面的名詞，将其做成矩陣，對有關系的名詞打上标記，并注明是什麼關系。在這個分析中，肯定會遇到問題，而我們要做的就是先把這些問題記錄下來，這些問題最好不要立即去問“上司”們，因為他們可能也不清楚。

接下來要做的是根據那份“需求分析”，指定出系統的功能架構，分析出最基本的架構，然後從最基本的架構着手，對架構的功能作進一步分解，然後再繪制的資料流圖和控制流圖，在繪制資料流圖的時候，提取資料實體，建立基本的資料庫（如果需要使用資料庫的話），當然這個做法和《系統分析師教程》中的提到的方法也是大相徑庭的，但是沒有辦法，因為我們連對象之間的關系都沒有弄清楚，哪裡來的邏輯分析嚴密的資料實體分析呀，為了工作，硬着頭皮也要上啊。

接下來就是按照上面的設計，把系統做出來，然後叫上司看，讓上司多提意見，稱上司在看程式的機會，順便把押在手裡面的問題拿出來，問題能解決多少算多少吧，然後繼續開發，然後繼續讓上司審查，上司越高興，問題解決的周期就越短，反之則越長。

這些都是我的土方法，是沒有辦法的辦法呀，工作還要繼續幹，并且還要幹好呢！

第三篇 是系統分析師還是程式員？

我本來打算把這篇的标題定為“系統分析師和程式員的關系”，在我看了兩個網友的留言後，我決定放棄這個标題，一個網友評論說，系統分析師應該消失，因為現在的原型化開發已經讓系統分析師失去了價值；一位網友評論說，他在一個七八十人的小公司裡面工作，認為系統分析師存在的必要性很大，并且說如果沒有系統分析師的隊伍，可能會失去競争力。我認為這兩種看法都過于偏激，因為他們都沒有考慮到，不論是系統分析師和程式員還是其它搞開發的人員，他們都是軟體公司的一部分。

作為一個軟體公司，作為一個企業，都有自己的生存法則，大公司有大公司的活法，小公司有小公司的活法。大公司實力大，人數多，能夠接到大的項目，那麼他必然要有自己專門的系統分析師團隊來維護公司正常的業務營運；而小公司，通常接到的項目都比較小，人數又有限，要想支援一個專業的系統分析師團隊是不可能的。我現在就在一個小公司裡面工作，接到任務後，直接就和客戶打交道，直接從客戶那裡擷取他的需求資訊，然後自己整理資料，分析系統的結構，然後編碼，然後測試，這些事情是沒有人來為我完成的。

是以我認為，系統分析師可以有兩種定義：一種從職務的角度來定義：這個人是我們公司的系統分析師；一種是從專業的角度來定義：這個人具備系統分析的專業知識。但不管從哪種角度來定義，它們都具備同一個特點：他們都要完成系統分析的工作。

分析本身就是一項複雜的活動，它的複雜不僅展現在它所涉及對象本身，還涉及到指導分析的方法論。而這些都是通用的哲學，他同樣可以知道我們在其它領域更好的開展活動。是以對于系統分析這項活動，作為一個程式員，也要去學習它，實踐它，這對我們是有好處的。

是以，不管我們所處的環境如何，是大公司還是小公司，至少我們都應該做自己的系統分析師。

到此，有關我對系統分析師的感慨寫完了，這篇文章隻是我個人對系統分析師的看法，局限性很大，還希望大家多多指教。