做軟體開發專案規劃時, 常會碰到助理問我一個問題, SA,SD和SE的差別在那裡 ?

做軟體開發專案規劃時, 常會碰到助理問我一個問題, SA,SD和SE的差別在那裡 ?

這個問題我以前也有過, 還頗為困擾, 系統分析和系統設計及系統工程到底有什麼差別 ? SA和SD的工作又有何不同 ? 這兩者的養成教育又有何差異 ?在過去, SA,SD及SE的確很難區分, 甚至這些角色常常會透過軟體工程師來混合發展。

隨著IT領域的發展, SA,SD及SE漸漸的成為了大型專案必需要的專業分工, 這三者間是有相當的差異的, 不管是養成過程, 甚或是未來的發展, 都大相徑庭, 而要成為一名稱職的PM, 是要能區分出這三者的差異, 才能妥善的安排工作的。

[SA,系統分析師]

SA是 System Analysis 的縮寫, 一般稱為系統分析, 主要的工作就是透過一系列的分析工作, 把客戶想要的結果產生方式, 以各種文件表達出來, 讓開發團隊可以根據這些文件實作出這個結果。

這樣的解釋比較文縐縐一點, 用個通俗一點的方式比喻, 就像是要做出一道宮保雞丁時, 就會有食譜一樣, 裡面會介紹需要的材料及做菜的順序, 然後裡面也會強調要以怎樣手法才能產生出某種效果, 以促進色香味。

這樣的過程裡, SA是較為偏重於在工作流程和處理邏輯的, 透過SA, 開發團隊才可以理出整個系統的架構, 一種做事的脈絡, 以及系統和工作間的關連性, 最重要的, 是這些結果都會被SA呈現在文件中, 而非放在少數人的腦袋裡。

SA不僅止是要針對電腦裡的東西去運作及規劃, 還包括了現實世界裡的實體流程及組織。在很多的情況下, 配合新系統的組織及流程, 是要由SA來執行的。總結起來, 在一個開發案裡, SA執行以下的工作：

· 藉由系統需求書, 使用者的現有標準作業流程來建立出符合期望的新作業流程及搭配流程的系統功能及模組規劃
· 依據功能及模組規劃案, 定出初步的資料庫內容及系統與使用者間的權限搭配規範
· 定出各個軟體零件的規範, 如物件, 函數庫, ...等等
· 設計新的標準作業流程, 並把系統功能或模組綁入這些流程中
· S.A依據客戶的環境及需求, 尋找合適的SD來搭配

而SA也有以下的特色：
· 對於系統在怎樣的環境及用什麼開發工具, 並不十分在意, 良好的S.A產生出來的文件, 使用不同的開發工具都應該可以完成, 產生相同的結果, 但那一種最合適, 由SD決定
· SA偏重於流程及執行邏輯的表達
· SA著重於軟體邏輯, 對開發工具的學習並不是十分重要, 所以會一種語言即可, 主要是以該語言工具來實踐邏輯觀。
· SA一定要有全局觀, 也就是不能拘泥於一個角度或是一個局部去思考問題, 這一點是尋找優秀SA時最困難的。因為在規劃模組及功能時, 一定要同時考量到所有直接相關及間接相關的程序及邏輯問題, 因此要有全局觀。

相較於SD, SA更側重在邏輯及工作順序搭配的表達, SA並不需要去關切使用什麼作業系統或是什麼開發工具, 如前特色所述, 好的SA文件, 可以用任何一種開發工具來實現。當然, SA不受限於IT技術, 但卻會有專業領域的限制。

很少有SA同時專精於數個領域的, 熟悉汽車業運作規範的SA, 在金融業的開發案裡, 就很難討好, 反之亦然。但SD沒有這種限制, 基本上SD可以和任何行業的專案開發團隊配合運作。

會如此的原因是SA是偏重於流程及管理分析及重新再造工作的。而作業流程, 除了少數領域裡共通性高, 在核心流程上, 是需要長期鑽研的。前面提及的汽車及金融業就是一例。

所以, 一個SA必需具備以下的能力,資歷及專業訓練：

1. 至少熟悉一種程式開發語言
2. 熟悉軟體工程, 對於開發工具的元素及特色熟悉
3. 對管理制度或作業流程設計熟悉
4. 熟悉UML或類似的系統描述工具
5. 邏輯能力良好
6. 良好的溝通能力, 主要作為瞭解需求之用
7. 相關的業界熟悉度

在三者之中, SA是最接近PM的, 所以SA在做生涯規劃時, 不妨以PM做為下一個發展的專業目標。

[SD, 系統設計師]

一般來說, SD在生涯規劃裡, 並不是SA或是PM。當然, 一定要硬來一次也沒有什麼不可以, 但要走這條路, 就要趁早轉職, 因為SD畢竟是較為幕後的工作, 在與客戶的溝通協調上, 並不會有太高的要求, 也較不需要公司管理層面的全局觀。

表面上看起來, SD沒有SA那麼多的工作要求, 但實際上SD是最需要天賦的工作, 不管是畫面的構成, 操作的手順及調整, 甚至於元件的定義及物件的規範, 全都需要一些天賦。很多軟體, 功能很強, 但怎麼看怎麼不順眼, 或者怎麼用就怎麼憋扭, 功能帶來的效益, 全都被這些毛病給遮蓋掉了, 這就是SD的問題。

另外, SD也扮演了系統最佳化的推手。SA所規劃出來的要求及佈置, 都只是邏輯上的構思, 在不同的工具上, 可能有更好的方法可以表現, 也可能會難以展示, 這都需要藉由SD對使用環境及開發工具的瞭解, 來進行調整和規劃。

舉例來說, 同樣是一套財務軟體, 在WINDOWS XP, MAC, X WINDOWS下, 就會有很不一樣的展現模式和技巧。如果再搭配上不同的開發工具, 如C++, JAVA, .NET, PHP, ...那差異更多。對SA而言, 這些東西他都不用去考慮, 但SD就不同了, 這些不同的地方, 並不僅僅只是如此而已, 有時還會包括了開發成本及時間問題, SD的重要度, 由此可知。

在一個客製化專案裡, SD的工作內容如下：

· 設計畫面元素規範
· 設計頁面結構及規則
· 設計系統操作畫面, 並編定欄位規範及防呆處理
· 設計權限管理與系統操作機制
· 撰寫使用手冊
· 調整DB之各項定義, 使其符合畫面欄位規範及操作搭配
· 配合SA撰寫系統開發文件, 供程式師CODING之用
· 撰寫UI(使用者介面)測試計劃書

而做為一名稱職的SD, 以下的條件, 是必要的：

1. 至少對一個作業系統極為熟悉, 對於這個作業系統的各個元件特性及API, 有充分的瞭解
2. 熟悉2種以上的開發工具, 而專案所需的工具, 必需是其擅長的之一, 其熟悉度包含了標準安裝裡的各個函數庫, 系統常數, 物件定義, 語法, 主要的輔助工具開發廠商, 及重要的工具使用方法
3. 具一定的美學感
4. 至少能使用一種繪圖工具軟體
5. 曾經擔任職業軟體工程師三年以上

可以這樣說, SA給了系統靈魂和神經系統, SD則是給了系統軀體和外觀, 兩者的結合, 才能產生出正確, 美觀又好用的系統。如果你覺得自己是個不太愛和太多人打交道的IT人, 又對使用者介面有那麼點執著及天賦, 那麼, SD絕對是適合你的好選擇。

[SE, 系統工程師]

就某種角度來看, SE對PM而言, 算是萬金油, 只要做IT專案, 那就一定用得上, 差別只是要選那一個專業的SE而已。系統建置安裝要SE, 使用者環境要SE, 甚至到硬體選擇及佈建, 都要用到SE, 有什麼IT專案跟這個沒有關係呢 ?

當然, 雖然SE是到處都吃得開, 但相對的也是專案裡面最沈默及少有聲音的一群。他們的工作基本上就是建構出一個可以執行系統的環境, 系統要如何展現, SE可以給SA和SD一些建議, 但建議時機通常都是在系統運行出了些非系統可以掌握的問題後。

系統工程師基本條件上, 和SD最為接近, 但有一點不同, 就是不需要有很好的軟體開發經驗, 也就是不太需要會寫程式。但要對作業系統, 服務器系統, 網路運用環境有相當程度的瞭解。

SE通常是三者中最為博學一員, 好的SE雖然不一定要程式寫的呱呱叫, 但卻不能對編程一無所知, 對作業系統及開發工具也要有一定的熟悉度, 甚至部份網管有關的工作也要有所涉獵, 所以算得上是專案裡的萬金油。

在專案裡, SE所要執行的工作如下：

· 規劃及建置系統執行環境
· 安裝及設定使用者端環境
· SERVER安裝及設定
· 提供環境設置竟見給SA及PM
· 最佳化系統可靠度及效度
· 撰寫可靠度及效能測試計劃書
· 對電腦及相關週邊設備有一定熟悉度

而一名SE則有下列基本要求：

1. 至少熟悉一種作業系統, 尤其是讓系統的設定及微調等相關技術
2. 至少熟悉一種網路伺服器作業系統, 對如何設定及最佳化熟悉
3. 曾任軟體工程師職務一年以上或熟悉一種開發工具
4. 對網路環境有一定的認識, 尤其是一些通訊設置
5. 熟悉可靠度及效能的評估方法, 並瞭解與系統環境相關之設定

基本上, 如果擁有了像SD一樣的技術背景及個性, 但在美學上實在令人不敢恭維, 那麼SE算是極佳的選擇了。一般而言, SE的下一個生涯規劃, 會比較偏重於技術性兵種, 像是DBA或是網管, 對於IT產品比較有狂熱或愛好的人, SE是極佳的出路。

[在專案中的運用時機]

基本上SE是萬金油, 只要是IT的案子裡就一定要塞一個SE進去, 因為沒有IT專案不需要使用工程技術的, 差別只在使用何種工程技術而已。在套裝軟體的導入專案裡, SE負責處理軟體使用環境, 解決非系統性問題, 安置及調整資料庫和網路環境, 然後安裝啟動。所有系統運行所需要的條件, 都要由SE來解決和處理, 但這些工作全都不會出現在眾人的面前, 但卻又重要無比, 算得上是幕後的英雄。

會同時運用到SA,SD及SE的專案, 還是以客製化開發為主的。

在開發型專案裡, SA團隊要負責初期的需求調查及整體架構的規劃, 將所有的系統開發工作內容轉化成井井有條的文件, 並且適度的分割及派送, 並確保未來這些被分割的開發結果能夠在未來可以正確運作。

SD 則在SA的文件中去尋求系統呈現的一致性, 易用性及保證開發工具可以正確無誤的展現SA的要求結果。所以SD要負責操作界面的外觀設計, 訂定一致的展現規範, 設計系統操作畫面及操作手順, 同時配合SA完成系統開發文件。基本上, 開發文件中, 是包含系統使用手冊初稿的。

SD在設計時, 必需與SA充分配合, 以確保設計的系統符合需求及運作要求。

除了上述的工作內容外, 這三者都要撰寫測試計劃, SA著重在於資料的流動符合原先規劃的順序及結果測試, SD則著重在操作畫面中的防呆測試及操作介面的正確性, 而SE則在系統可靠度上進行規劃。

[軟體工程師何時轉職 ?]

每一個寫程式的人心裡都明白, 這工作不可能做一輩子。不單單是體力及腦力問題, 最重要的是寫程式, 經濟價值實在有限。

我不會否認有很多的程式高手, 但重點不在於你有多優秀, 而是有多少老闆願意付出和你努力成正比的薪資來顧用你。不是沒有這種工作, 而是如同鳳毛麟角, 而且, 這種工作通常你也做不久, 因為壓力太大, 消耗青春太劇烈了。

退一步來說, 你也不值得付出這麼多, 在良好的SA及SD的規劃下, 工程師只要達成一般標準, 就可以解決掉九成以上的軟體開發需求, 除非是機緣巧合, 或是你很有興趣, 否則另外那一成的工作, 你是很難有機會碰上, 或者, 就算碰上, 也沒法子養活你一輩子。

軟體工程師總有一天要轉職的, 這是他們的宿命。

當要轉職時, 他們有幾個選擇, SA, SD, SE, 出去當老闆及換一行等諸多選擇。看起來雖多, 但其實晚景淒涼, 因為寫程式都是關起來寫, 長期自閉的結果, 當他們想轉職時, 很難擁有足夠的人脈來支撐他們換個前途光明的事業。一般人羨慕IT人的高薪, 卻不曉得只是寅支卯糧, 沒有妥善的規劃, 後勢看跌的。

前面的五個選項, 基本上最後兩項只是充場面, 只有少數人才能選那兩個, 大多數軟體工程師還是要在前三者中選一個來發展的。

SA看起來最風光, 未來也是潛力最好的, 但很遺憾的, 軟體工程師裡, 只有少數人適合這個職務。因為這個工作是很需要和別人打交道的, 而好的軟體工程師通常這一點非常不擅長。

因此, 如果你自認為擅於溝通, 三姑六婆都是你的紅顏知己, 邏輯能力不錯, 又對管理有興趣, 那麼SA是你很好的選擇, 程式功力並不是你要考慮的重點。

相對的, 你對使用者介面很有心得, 而且在美感上也獲得了同事的一致讚賞, 程式功力也有那麼一點自信, 討厭和不是搞IT的人打屁聊天, 那不要懷疑, SD是你最佳的歸宿。

最後, 你覺得IT的世界對你充滿了吸引力, 無論是作業系統, 開發工具或是軟體及IT設備都是如此的吸引你, 人與人的接觸對你來說並不是人生的首要需求, 層出不窮的IT科技讓你陶醉其中, 那麼, SE絕對是你的首選。

要如何轉職, 每一個軟體工程師是要誠實面對自己的, 而不是依前途來決定自己要選什麼職務, 如果你依這種方式選, 以我個人在職場生涯的經驗, 這樣的人很難散發出光芒, 也難以有他期望的成就。所以, 現在在寫程式, 正在想要轉職的工程師, 請謹慎而且誠實的面對自己, 做出恰當的選擇。

[結語]

以上是個人提供給對於SA, SD及SE或到困惑的朋友, 做為參考及工作分配的依據。這三者的產生, 其實也是源於目前IT技術的成長過於快速, 所以必需針對軟體工程進行適切的分工, 才能應付好日益複雜的IT環境。

資訊系統開發過程及無奈

三階段資訊系統開發過程
1.需求分析 2.系統分析與設計 3.系統實施

七階段資訊系統開發過程
1.使用者需求分析 2.軟硬體需求分析 3.系統分析 4.系統設計 5.編碼 6.測試 7.操作與維護

這是書上所說的資訊系統開發過程，其實在怎麼簡化，最少都要三個階段才能完成一個系統，而我一直都是一人獨立開發，所以我自己在開發資訊系統的過程是
1.使用者需求分析 2.系統分析與設計 3.測試 4.操作與維護

資訊系統開發要考慮的人、方法、科技、企業經營四個構面，若這四個構面無法相互平衡，你的資訊系統將成效不彰、甚至失敗，不管你的資訊系統開發的在怎麼好都還是需要「人」，不管是開發者，操作者，都在於人，所以我說一個資訊系統的成敗，「成也在人，敗也在人」，而我自己從網管到系統導入管理到自己開發系統，常遇到
1.目標不明確，也就是說公司想要資訊化、開發電子商務，但卻不知道自己想要的是甚麼，目標在哪裡，只知道只要資訊化、電腦化，就能馬上提升公司營業額，創造利潤，但事實真的是這樣嗎？開發一套系統，開發一套符合企業本身的系統，有那麼簡單嗎？但中小企業的老闆普遍認為很簡單，只要請各資訊人員，就能完成，是這樣嗎？

開發人員，跟使用者洽談了解使用需求後，經由系統分析、規劃流程，架構，在進行設計，完成後給使用者測試，但若開發人員無法真正了解使用者需求，那他後面花的時間就等於是浪費，而這個使用者有兩種，1.公司，或老闆自己，2.使用系統的人，而這兩種人的需求都搞不清楚了，那開發人員這著你們的不清楚的需求開發了不清楚的資訊系統，那鐵定是個失敗的作業系統

2.資訊系統開發是一件非常複雜的工作，若一開始開發人員搞錯了方向，選錯了開發工具，又對於開發的語言不熟悉不了解，那你說他所開發的資訊系統會沒有問題嗎？讀書都知道要資訊系統開發的過程，但每個過程都做的不確實，會成功嗎？答案是不一定，但若成功不管是開發人員或操作人員都會很辛苦，若一開始搞錯了方向，那測試之後就會開始大改特改，若在選錯了開發工具，對開發語言不熟悉，那在修改程式就難上加難，而系統上線的時間有就會無限期的延長

發展資訊系統就常遇到公司或老闆的目標就是賺錢，但藉而公司資訊化、電腦化，其實就初期，已在無形中幫公司節省了不少管理上的成本，簡化了許多作業流程，但這些成效老闆都看不見，資訊永遠只是花錢的工作，公司的負擔，在許多的中小企業一直都是這麼認為著，也讓許多資訊人員感到無奈，老闆永遠不會認為這是一種投資

[轉載]生活中的ERP

ERP (Enterprise Resource Planning)企業資源計畫，指的是具有品質管理、現場服務、維修管理、配銷、行銷和供應商管理等額外能力的系統。
還是不懂嗎？ 沒關係，看了這篇文章就懂了~~^^"
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
一天中午，丈夫在外給家裏打電話：「親愛的老婆，晚上我想帶幾個同事回家吃飯可以嗎？」（訂貨意向）

妻子：「當然可以，來幾個人，幾點來，想吃什麼菜？」
丈夫：「6個人，我們7點左右回來，準備些酒、烤鴨、番茄炒蛋、涼菜、蛋花湯……你看可以嗎？」（商務溝通）

妻子：「沒問題，我會準備好的，」（訂單確認）

妻子記錄下需要做的功能表（MPS計劃），具體要準備的菜：鴨 酒 番茄 雞蛋 調料──（BOM物料清單），發現需要：1只鴨，5瓶酒，4個番茄，──（BOM展開），炒蛋需要6個雞蛋，蛋花湯需要4個雞蛋（共用物料）。

打開冰箱一看（庫房），只剩下2個雞蛋（缺料）。

來到自由市場，妻子：「請問雞蛋怎麼賣？」（採購詢價）

小販：「1個1元，半打5元，1打9.5元。」妻子：「我只需要8個，但這次買1打。」（經濟批量採購）

妻子：「這有一個壞的，換一個。」（驗收，退料，換料）

回到家中，準備洗菜、切菜、炒菜──（工藝路線）

，廚房中有燃氣、微波爐、電飯堡──（工作中心）。

妻子發現拔鴨毛最費時間（瓶頸工序，關鍵工藝路線），用微波爐自己做烤鴨可能就來不及（產能不足），於是決定在樓下的餐廳裏買現成的（產品委外）。

下午4點，電話鈴又響：「媽媽，晚上幾個同學想來家裏吃飯，你幫準備一下。」（緊急訂單）

「好的，兒子，你們想吃什麼，爸爸晚上也有客人，你願意和他們一起吃嗎？」「菜你看著辦吧，但一定要有番茄炒雞蛋。

我們不和大人一起吃，6：30左右回來。」（呵呵，不能併單處理）

「好的，肯定讓你們滿意。」（訂單確認）

雞蛋又不夠了，打電話叫小販送來。（緊急採購）

6：30，一切準備就緒，可烤鴨還沒送來，急忙打電話詢問：「我是李太太，怎麼訂的烤鴨還沒送來。」（採購委外單跟催）

「不好意思，送貨的人已經走了，可能是堵車吧，馬上就會到的。」門鈴響了，「李太，這是您要的烤鴨。請在單上簽一個字。」（驗收、入庫、轉應付帳款）

6：45，女兒的電話：「媽媽，我想現在帶幾個朋友回家吃飯可以嗎？」（呵呵，又是緊急訂購意向，要求現貨）

「不行呀，女兒，今天媽媽已經需要準備兩桌飯了，時間實在是來不及，真的非常抱歉，下次早點說，一定給你們準備好。」

（哈哈，這就是ERP的使用侷限，要有穩定的外部環境，要有一個起碼的提前期）送走了所有客人，疲憊的妻子坐在沙發上對丈夫說：「親愛的，現在咱們家請客的頻率非常高，應該要買些廚房用品了（設備採購），最好能再雇個小保姆（連人力資源系統也有介面了）。」

丈夫：「家裏你做主，需要什麼你就去辦吧。」（通過審核）

妻子：「還有，最近家裏花銷太大，用你的私房錢來補貼一下，好嗎？」（哈哈哈哈，最後就是應收貨款的催要。還可再加上成本核算，總帳，決策分析等等）。

例如……送走了所有客人，妻子拿著計算器，準確地算出了今天的各項成本（成本核算）和節餘原材料（車間退料），並計入了日記帳（總帳），把結果念給丈夫聽（給領導報表），丈夫說道「值得，花了145.49元，請了好幾個朋友，感情儲蓄帳戶增加了若干」（經濟效益分析）。