假設論點
傳統的系統分析人員是由資工資管背景養成的,他們對技術很在行,可是對於使用者業務知識多半是沒概念。所以在需求訪談時往往掌握不到要點,要不就是使用者無法適切表達出來,以致於分析人員及使用者的認知往往差距很大,開發出來的系統便不符合實際需要或不好用。
所以最好的辦法是,由需求單位提自行提出規格書,因為規格一但開出來,交由程式設計開發,這樣就很容易了。
程式設計沒什麼困難,而且沒什麼價值,最有價值的是系統分析。你只要規格交付他們,他們依著你的規格,很快就能開發出你要求的軟體。
這樣的論點有點怪異,因為使用者根本不知道你的系統到底是什麼技術平台架構,而且使用者根本無心去管什麼資料是什麼,無心去想這麼細緻的問題。使用者和設計者永遠認知有蠻大的差距。
大家一起來討論看看,究竟這樣的觀念是不是正確
個人積分：1分
文章編號：9378142
個人積分：3分
文章編號：9378560
個人積分：0分
文章編號：9379368
個人積分：6709分
文章編號：9381334
以前我在軟體公司上班,公司就有一推豬頭上司,到處,偷,拐,騙,搶,找到一推Case.
然後找一些剛畢業,只會讀書,騎他的什麼都不會的大學生當SA,去需求訪談,然後就1,2,3......開出規格書.
規格書開完後丟給Programmer 去寫.寫到交貨日期在帶Programmer 去做簡報,結果做出來的不是使用者要的,有時補補貼貼可以改,有時可能全部重做.坦白的說,這些都是修表面的,有時1,2年內沒問題,久一點問題就一推.
經過我分析,問題很多.1.使用者不會表達.2.SA沒實務經驗. 3.Programmer 跟 SA 認知有落差....
於是我認為待在軟體公司根本不能進步.
所以我進入傳產公司,雖然錢比較少,但能跟作業人員站在同一線,東西馬上做,馬上請User做認證,坦白說也不用做多少分析,馬上問,馬上做,馬上改.我還是做程式領域的研究.企業知識,不會的馬上問,也不用想太多邏輯,直接叫User給你公式就好了.
個人積分：8分
文章編號：9392234
