這篇的主肘為~系統分析師
System Analyst,簡稱SA.
主要的工作內容為需求性分析...
通常SA會是由PG所轉任~
SA的背景大多為程式設計師,但這並非絕對..
只是我所接觸過的SA,大多數的背景都是程式設計師出來的.
那麼當一個稱值的SA基本功力,應該是在念書時期就可以慢慢培養的.
例如經典聖經,系統分析與設計,或是UML.
那麼何謂UML呢.?
UML是Unified Modeling Language的簡稱,中譯為「統一塑模語言」。其中:
●Unified:UML是一種標準語言,廣泛運用於全世界。
●Modeling:UML用途在於塑模(Modeling),也就是畫軟體藍圖。
●Language:UML是一種塑模語言,而非程式語言或標示語言。
也就是說,UML是軟體系統發展人員用以建造模型,而這些模型使得工作團隊能夠:將系統具象化(Visualization)、將系統結構及行為規格化(Specification)、建構(Construction)系統、以及記錄(Documentation)發展系統過程中之各項決策。
在來談一下SA的主要工作內容大制上的方向.
其實SA並沒有制式的工作內容,整體上還是以公司需求為主.
總結,SA的內容為
1.使用者訪談、需求分析
2.專案可行性評姑
3.專案時程安排
4.專案進度控管、監督
SA .. 系統分析
SD .. 系統設計
?? .. 制度分析
?? .. 制度設計
?? .. 管理分析
?? .. 管理設計
管理要有制度
制度要有系統
系統要有程式
總結,SA的內容為
1.使用者訪談、需求分析
2.專案可行性評姑
3.專案時程安排
4.專案進度控管、監督
===========
系統 是制度的實現
SA 訪談使用者是沒制度的公司
SA 需求分析沒制度的公司
管理是
主管制度者
執行制度者
都知道要如何作
且稽核也知道你的方法與結果是否有依照制度
...
怎麼是去訪談使用者
...
系統分析是給程式設計者
不需要了解全部的系統架構
可以很簡單的去寫單一個物件
??????????????????
抽象,抽象,再抽象.
一個系統哪需要那麼多制度?
已一般的公司來說,這麼多制度就不用做事了.
已一般的公司而言,制度還沒完全.就叫你回家吃自己.
已學校教的SA,SD或書本上看的論理,法則...使用者訪談,風險評估....上線測試,維護..都沒錯.但對一個沒實務經驗的來說太抽象了.不知怎麼著手.不知怎麼評估.
如果用資深PG去做SA來說,不但學得快.而且可以很快的評估這個東西可不可做.可不可行.
一個問題來,心中馬上可以擬定很多方案.
對一家公司來說.制度會應時間不斷的在變.
以一家公司而言,規則會按需求不停的在修.
所以你訂一些很多堅硬的規範.我是覺得不適合台灣這種都是中小企業為主而且又是多變的環境.
分項越經細,執行越困難
資訊化社會,經常把很東西一切再切
看起來很有系統
也顯得很有深度
事實上,只有大型企業、公家機關,吃這一套
90%的企業,真的用不到!!
理論有標準;實務有經驗!
理論可參考;實務得應變!
必須兩者互相融合!因時因地制宜囉!
+1
說得好,需要信徒嗎??