制度設計
制度分析
系統分析
程式設計
鬼話連篇
優秀的系統分析師應該具備系統整合、邏輯思考、需求訪談??
系統分析來設定需求??
你嘛幫幫忙!!
分析兩個字
你不懂嗎?
系統分析師是依據選用平台相依性
轉換制度分析師的需求
系統分析重點在
分系統的專屬性作業
考慮到 使用平台
考慮到 使用元件
多數專案失敗的原因在於需求無法掌握,
古今中外的老生常談,
知道這回事但不知如何做的大有人在。
身為系統分析人員,
若在初步階段沒有一套可依循的方法,
後續的設計開發會遇到的困境將接踵而來,
心力也大多耗費在補洞救火,致使延宕開發時程。
因此,如何掌握需求是系統分析人員的「首要」任務,
並且根據2009年經濟部商業司「商業服務業e化人才專業職能調查」,
歸納出的4類e化人才中,
系統分析師是本產業最核心的角色之一,
其扮演商務與技術領域的溝通者,
兼具產業知識和程式設計的能力,
優秀的系統分析師應該具備系統整合、邏輯思考、需求訪談等3項重要能力。
真的都是鬼話連篇.
等你分析好了.單都被別人搶走了.
台灣講究的都是偷拐騙搶,價格低,有彈性..
以我程設師的立場.老闆要什麼,我只能說會.
以軟體開發而言,人家要什麼,你只能說行,那怕這東西跟原模型差很大.
單先搶先贏,哪有給你分析的空間.
有時間分析表示有人太閒. (與愛開會的主管有的拼)
Sales 支票隨便開, 背後 developer 怎麼在最少的資源(如時間)給出符合 spec 內容物就各憑本事了.
不過我也看過很敢開口的 developer, 雖然大部份的時間都是其他人在收拾善後..
先搶先贏, 讓客戶簽收現金入賬比較實際.
原模型? 那是甚麼, 可以吃嗎?
coding 無法發包計件
代表他是 coding house
不要理他
coding 發包 SA 才會寫的很清楚
albertachen提到:
coding 發包 SA 才會寫的很清楚
同意這一點, 但是要如何訓練出這種SA呀??
我都是 用畫面誘導法 訓練 SA
就是讓她 將畫面關聯定義好
不跟她 用口語補充說明
一次 兩次 三次
都會在五次內開始正確描述需求
這是文件製做部分, 我非常同意您的作法, 但是在這之前要如何訓練SA去了解需求呢?? 這也是很容易造成誤會的環節, 如果一開始就誤會了客戶的需求, 後面在怎麼分析也不會對的, 我都是先把他們帶去客戶端, 去"看"他們的END USER將來要如何操作他們的系統, 讓他們更能體會客戶的想法, 但是這方法很多時候沒辦法用, 因為客戶不給你看.....這要怎麼辦呀??
但是在這之前要如何訓練SA去了解需求呢??
SA 的需求來自
系統分析文件 來自制度分析文件
制度分析文件 來自制度規章文件
看現有的系統
先把他們帶去客戶端,
去"看"他們的END USER將來要如何操作他們的系統
那是開始扭曲系統規劃的第一步
制度分析文件才是驗收的標準
現有系統不是我們該去看的系統
SAP/Oracle/ADempiere 上系統部會去理會現有的流程
AS IS
TO BE
哪一個會結案