討論區快速選單
知識庫快速選單
傑米的攝影旅遊筆記 最紅的App開發語言:Kotlin 網路投保旅行平安險
[ 回上頁 ] [ 討論區發言規則 ]
台灣中小型軟體公司 無法有效管制軟體品質 之 癥結所在
更改我的閱讀文章字型大小
作者 : fcwang(fortran) 程式設計甘苦談優秀好手貼文超過200則
[ 貼文 231 | 人氣 2831 | 評價 2440 | 評價/貼文 10.56 | 送出評價 6 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/1/4 下午 11:07:33
談起軟體品質, 當然是講設計出來的程式碼執行的結果能符合當初客戶同意的規範. 如果兩者之間有差異, 有一套實用與合理的評等的標準.

要管制軟體品質, 個人認為必須有下列三項基本的條件 :

首要的條件 要有軟體品質管制的執行單位與人力. (經費問題)

第二項條件 每個軟體開發專案必須要求要有客戶(或用戶)同意並簽署的書面規範及相關的文件. (專案管理問題)

第三項條件 有一套實用與合理的評等的標準 與 執行軟體品質的方法.管制軟體品質才算有基本的條件. (品質管理問題)


所以, 軟體公司如果就上述的三項條件有一部分或全部的問題, 品質絕對無法有效管制. 台灣中小型軟體公司有此現象 所佔比率不算低.
這是個人所認為 "台灣中小型軟體公司之軟體品質問題" 的癥結所在.

您的看法如何 ?
作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/1/4 下午 11:33:57
the first step of SQA is software testing . this step is a basic of SQA
作者 : kagaya(kagaya) VC++優秀好手C++優秀好手貼文超過1000則人氣指數超過30000點
[ 貼文 1599 | 人氣 38709 | 評價 4590 | 評價/貼文 2.87 | 送出評價 115 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/1/5 上午 09:27:07
所謂 一分錢 一分貨
什麼樣的價錢有什麼樣的品質
這倒沒有什麼好奇怪的
作者 : kagaya(kagaya) VC++優秀好手C++優秀好手貼文超過1000則人氣指數超過30000點
[ 貼文 1599 | 人氣 38709 | 評價 4590 | 評價/貼文 2.87 | 送出評價 115 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/1/5 上午 09:29:43
以台灣這種流血殺價搶標案做出來的東西
想跟國外大案子的品質並駕齊驅
未免異想天開
作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/1/5 上午 11:24:51
the major reason is many firms have no this experience.
作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/1/5 下午 11:03:12

>談起軟體品質, 當然是講設計出來的程式碼執行的結果能符合當初客戶同意的規範. 如果兩者之間有差異, 有一套實用與合理的評等的標準.
>
>要管制軟體品質, 個人認為必須有下列三項基本的條件 :
>
>首要的條件 要有軟體品質管制的執行單位與人力. (經費問題)
>
>第二項條件 每個軟體開發專案必須要求要有客戶(或用戶)同意並簽署的書面規範及相關的文件. (專案管理問題)
>
>第三項條件 有一套實用與合理的評等的標準 與 執行軟體品質的方法.管制軟體品質才算有基本的條件. (品質管理問題)
>
>
>所以, 軟體公司如果就上述的三項條件有一部分或全部的問題, 品質絕對無法有效管制. 台灣中小型軟體公司有此現象 所佔比率不算低.
>這是個人所認為 '台灣中小型軟體公司之軟體品質問題' 的癥結所在.



>您的看法如何 ?


這是之後的問題,基本的問題是如何測試軟體,很多公司使用的方法,....都是錯的
作者 : fcwang(fortran) 程式設計甘苦談優秀好手貼文超過200則
[ 貼文 231 | 人氣 2831 | 評價 2440 | 評價/貼文 10.56 | 送出評價 6 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/1/5 下午 11:55:19
>這是之後的問題,基本的問題是如何測試軟體,很多公司使用的方法,....都是錯的

如何測試軟體, 必須有 QA 制度來規範. 沒有QA制度, 如何會有正確的測試方法. 例如 : 沒有用戶核可簽署的功能規範書當 Baseline, 如何判斷各項功能測試 Pass 或 Fail.

測試 (此處不談 Unit Test )方法, 也是要被設計出來的. 測試小組 與 軟體開發團隊 是獨立運作的, 但是屬於同一專案團隊.

當開發團隊在做系統分析的時候, QA Team 的人員必須參與開發團隊各項討論與會議, 以理解軟體系統各項功能面與非功能面(Aspect)的需求和規範.

當開發團隊在做系統設計的的時候, 測試小組的人員必須與開發團隊保持同步, 來設計合適的 Test Cases 與 Test Scenario. 以求測試可以在經濟且有效的方式來執行.

QA Team 的人員是在專案開工時, 就開始工作了, 不是軟體開發完成要測試的時候, 才開始工作.

所以, 我個人認為 QA 制度為先決條件. 很多公司沒有 (或不知如何) 建立 QA 制度, 當然 測試方法 就會無法規範.
作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/1/6 上午 10:26:33
many software firms didn't build up formal testing departments and they just use system testing skills ( black box testing ) . it is a only a temporary solution.
作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/1/6 上午 10:37:35
SQA is a complex and big issue ; it includes SRS , SCM, ST , SQA, audit , process , docs , ....
作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/1/6 下午 12:54:15
這些都不是問題,問題是真的會有人要做嗎? 以台灣這種不成材的sw firms
作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/1/11 下午 05:28:03
很簡單,就是無能又貪婪
作者 : fcwang(fortran) 程式設計甘苦談優秀好手貼文超過200則
[ 貼文 231 | 人氣 2831 | 評價 2440 | 評價/貼文 10.56 | 送出評價 6 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/1/11 下午 08:02:25

>所謂 一分錢 一分貨
>什麼樣的價錢有什麼樣的品質
>這倒沒有什麼好奇怪的

以前, 我在化工廠工作, 看到一位工場主管在斥責執班工程師 "壓力高, 你就把釋壓閥(relief Valve)打開, 讓壓力減輕, 而不去找尋為何壓力會提高的原因來根本解決, 那麼任何人都可以(取代你)來工作 ".
這一幕讓我畢生難忘.

軟體公司的經營者, 在面對強烈的競爭環境壓力下, 以低價搶標, 降低品質來彌補預算的不足, 這是最簡易的思維方式, 殺雞取卵的策略. 與前段話我所提的 執班工程師 打開釋壓閥作法如同一轍.
這種經營者比比皆是也, 成功的機會相對地渺茫.

根本解決的方案應該是尋求公司的生存利基所在, 加強核心技術, 讓自己有產品與價格優勢. 這種公司才能留住好的人才, 才會往良性循環的方向進展.

小公司必須有大公司的經營理念, 才有可能成為大公司. 堅持不隨波逐流的經營者, 才有較多的成功的機會.
作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/1/11 下午 09:50:26
軟體工程本是一種經驗的學科,這種工程學已經形之多年了,but 在台灣就是行不通, so .....
作者 : guybrush321(蓋柏拉許)
[ 貼文 13 | 人氣 1785 | 評價 70 | 評價/貼文 5.38 | 送出評價 2 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/1/14 上午 09:43:18
這是幾間公司看的情況:

1)如果主管本身能力還不錯,在公司又得賞識,那麼在這種公司上班是幸福,不過這類公司遇不可求,

2)業務統制一切,那麼這種公司主管能力不重要,重要的是能不能當夾心餅干,因為業務最大要你寫你就得寫,這時程式本
 身的功力就很重要。

3)一樣類型的產品一再重覆的寫?沒錯,我看到的是一個產品寫大概4~5次,對於寫軟體的人而言,不能達到分工和函式庫
 分享,這種公司可歸類地嶽,有寫不完的程式,外加無能的主管。

所以公司的管理問題才是根本原因,軟體管理反而相對簡單,因為內部虛秏是不會有多大產出。
作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/1/15 上午 11:46:52
tw is a labour oriented natation , so software industry is not suitable for it.
作者 : jasper(Jasper)討論區板主 程式設計甘苦談頂尖高手上班族的哈拉園地優秀好手貼文超過1000則人氣指數超過70000點
[ 貼文 1403 | 人氣 96053 | 評價 6980 | 評價/貼文 4.98 | 送出評價 42 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人fcwang註記此篇回應為很有道理 2012/1/17 上午 09:55:03
>>要管制軟體品質, 個人認為必須有下列三項基本的條件 :

>>首要的條件 要有軟體品質管制的執行單位與人力. (經費問題)

>>第二項條件 每個軟體開發專案必須要求要有客戶(或用戶)同意並簽署的書面規範及相關的文件. (專案管理問題)

>>第三項條件 有一套實用與合理的評等的標準 與 執行軟體品質的方法.管制軟體品質才算有基本的條件. (品質管理問題)

無法有效管制軟體品質的癥結應該是在第三項,沒有一套評定的標準,沒有標準、評定的方法,就算是有錢、有人也無法保證品質。

至於第二項,客戶同意接受,也並不代表軟體就達到其所要求或標準。某些狀況之下,不得不妥協,沒魚蝦也好,現實生活中,每個人都會碰到,但若著眼在〝軟體品質〞這點上,這就不能劃上等號。

在談如何測試軟體之前,應該先問〝軟體品質的定義是什麼?〞何謂好?何謂壞?分不清好壞,光談方法,也是白談。

就這個問題〝台灣中小型軟體公司無法有效管制軟體品質之癥結所在〞,我的看法是無知、無心,根本不知道什麼是好的軟體品質?也沒有心去了解,進而研究一套管制軟體品質的方法。
作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/1/17 下午 06:05:00
台灣根本就不存在軟體業,所以任何軟體相關的活動根本就是不存在
作者 : fcwang(fortran) 程式設計甘苦談優秀好手貼文超過200則
[ 貼文 231 | 人氣 2831 | 評價 2440 | 評價/貼文 10.56 | 送出評價 6 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/1/17 下午 10:09:32
>
>無法有效管制軟體品質的癥結應該是在第三項,沒有一套評定的標準,沒有標準、評定的方法,就算是有錢、有人也無法保證品質。
>
個人認為 軟體品質管制可設定軟體品質的評等, 有下列五種評等等級 :

第1類. 嚴重的缺失(Serious Defect) 軟體啟動後會使系統死結 (Dead Lock), 停滯不動或當機, 影響系統或應用程式的執行, 產生嚴重的災難.

第2類. 主要缺失(Major Defect) 沒有第1類的品質問題. 但軟體與主要功能(Major Functions)規格不符, 會影響到系統設計預期的結果(例如計算結果錯誤), 沒有替代方案, 也無法更正錯誤.

第3類. 中度缺失(Moderate Defect) 沒有第1類與第2類的品質問題 軟體與主要功能(Major Functions)規格不符, 會影響到系統設計預期的結果, 但軟體具有其它替代方案, 可以暫時避免或可以更正錯誤 .

第4類. 輕微缺失(Minor Defect) 沒有第1類至第3類的品質問題. 且軟體與主要功能(Major Functions)規格相符, 但次要功能(Minor Functions)與規格書不符, 或 與一般認知有明顯錯誤, 執行符合系統設預期的結果. 例如:介面或報表顯示格式錯誤.

第5類. 建議之改進(Informational / Suggestion) 客戶或開發團隊所提出之建議.

有第1類至第2類的品質問題, 絕對不可以導入 (Deploy)於生產環境 (Production Environment).

沒有第1類至第2類的品質問題, 但有第3類與第4類的品質問題的情況, 是否要導入到生產環境 則視與客戶的合約規範之品質要求. 品質要求規範的條文範例 " 第3類的品質問題數目少於5, 且第4類的品質問題數目少於15".

如果是內部的專案, 則是開發團隊與用戶(User)之間的默契. 開發團隊必須教育客戶(或用戶), 不可能有零錯誤 (No Error Free)的觀念, 才不會雞同鴨講.

第3類與第4類的品質問題可以等上線後再解決, 時間的壓力可以暫緩. 第5類並不算是品質問題, 雙方可協商無償或有償的方式, 依變更程序進行需求變更.


如果合乎品質要求功能規範 (Functional Specification), 而將應用軟體系統導入生產環境後, 才發現第1類與第2類的品質問題, 嚴重影響到業主(或用戶)的業務運行.

這時候, 專案負責人(PM)可能要去業主(或用戶)老闆面前罰站. 開發團隊也必須在最短的時間內排除第1類至第3類的品質問題, 讓應用軟體系統能夠有正確的執行結果.


>至於第二項,客戶同意接受,也並不代表軟體就達到其所要求或標準。某些狀況之下,不得不妥協,沒魚蝦也好,現實生活中,每個人都會碰到,但若著眼在〝軟體品質〞這點上,這就不能劃上等號。
>

軟體品質的評等必須是對照雙方同意的書面功能規範 (Functional Specification). 客戶既然接受該功能規範, 如果要求變更就必須依照變更程序進行變更, 功能變更可能會產生成本與時程的變更, 間接導入商務談判.
妥協或不妥協端是管理客戶的一項藝術, 不管如何 變更程序也是書面為之, 雙方專案負責人簽字才算數.



>在談如何測試軟體之前,應該先問〝軟體品質的定義是什麼?〞何謂好?何謂壞?分不清好壞,光談方法,也是白談。
>
>就這個問題〝台灣中小型軟體公司無法有效管制軟體品質之癥結所在〞,我的看法是無知、無心,根本不知道什麼是好的軟體品質?也沒有心去了解,進而研究一套管制軟體品質的方法。
>

國外公司如有技術有待改進之處 都會聘請賺業的顧問, 即使是大公司亦不例外. 國內軟體業必須要向國外借鏡.
作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/1/18 上午 10:18:29
those just are severity levels, but SQA covers many domains , such as SRS , audit , SW testing , SW architecture , SCM , SW maintenance , .....
作者 : jasper(Jasper)討論區板主 程式設計甘苦談頂尖高手上班族的哈拉園地優秀好手貼文超過1000則人氣指數超過70000點
[ 貼文 1403 | 人氣 96053 | 評價 6980 | 評價/貼文 4.98 | 送出評價 42 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/1/18 上午 11:27:13
曾參與一個日本富士通的小案子,最後是由我在台北面對日本人的驗收工作,對方依照規格書逐一校對。接受驗收之前,難道開發團隊就不會逐一核對嗎?

最近中國鐵路局先推出的售票網站就被罵死了,登不上去,卡死了。難道不知道春節期間會有流量問題嗎?台北的捷運、台灣高鐵,一開始也有類似問題?難道他們都明知有問題,也如期推出嗎?真是令人費解!

當我面對驗收時,不管是滿懷信心或是心虛,心中都有數,因為事先已經逐一檢查過,面對缺失部份,也備好了理由,或許用藉口、謊言會更貼切一點。不管怎麼說,至少我掌握了狀況。

對軟體品質的評等,我認為不該將有缺失的也列入其中,不及格就是不及格,不管是 59 分或是 0 分,通通都是一樣。60 到 100 之間再分等,才會有點意義。

有些東西在規格書上是不會明列的,像 SQL Injection 之類的,或許可以列入基本的必要條件中,但也只能限定在一般的狀況,但這〝一般〞又是指那一般?規格書不容易寫,所以也就會衍生出其他現實的問題,這就不在此多談。

軟體測試有很多種方法,軟體品質評等也有很多種,無一定論。

這篇文章:『拿軟體品質來評員工績效,沒搞錯吧?』http://www.zdnet.com.tw/enterprise/blog/0,2000085759,20126971,00.htm

結尾這樣寫著:

要度量軟體的品質,在軟體工程中比較常用的方式是計算“缺陷密度”,它的公式是軟體規模除上缺陷數,軟體規模可以用程式行數(line of code)或者功能點數(function point),缺陷數則通常是系統bug數。
作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/1/18 上午 11:40:49
the above is impossible in tw's software firms. i never seen any sw firms in tw that build SQA department.
作者 : fcwang(fortran) 程式設計甘苦談優秀好手貼文超過200則
[ 貼文 231 | 人氣 2831 | 評價 2440 | 評價/貼文 10.56 | 送出評價 6 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/1/18 下午 11:17:58

>曾參與一個日本富士通的小案子,最後是由我在台北面對日本人的驗收工作,對方依照規格書逐一校對。接受驗收之前,難道開發團隊就不會逐一核對嗎?
>

驗收測試之前, 必須先規劃驗收測試計劃, 由雙方以書面同意並核定. 依雙方同意的驗收測試計劃來執行, 因此, 驗收測試程序不會有爭議.
開發團隊必須自己先依雙方同意的驗收測試計劃來執行測試通過後, 才會邀請客戶作正式驗收. 並製作驗收測試報告, 測試結果符合預期條件, 才可以導入系統. 並且要有再版計劃給客戶, 讓客戶同意 缺失改善的時程.


>最近中國鐵路局先推出的售票網站就被罵死了,登不上去,卡死了。難道不知道春節期間會有流量問題嗎?台北的捷運、台灣高鐵,一開始也有類似問題?難道他們都明知有問題,也如期推出嗎?真是令人費解!
>
上述的現象可能的原因如下 :

1. 需求條件錯誤, 未能反映實際的系統負荷. (業主的責任)

2. 未執行壓力測試(Stress Test) 或壓力測試環境設定不符實際負荷需求 (開發團隊的責任)

3. 設計錯誤, 有潛在缺失未發現. (開發團隊的責任)

明知有問題,系統如期推出是被逼或故意是業主兩權相害取其輕的決策.


>有些東西在規格書上是不會明列的,像 SQL Injection 之類的,或許可以列入基本的必要條件中,但也只能限定在一般的狀況,但這〝一般〞又是指那一般?規格書不容易寫,所以也就會衍生出其他現實的問題,這就不在此多談。
>

規格書不容易寫,為了預防為來雙方爭議, 還是要寫得清楚.
作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/1/19 下午 12:39:31
but 又有多少公司會想好好寫規格 ? 又有多少公司在規格變動時做好需求管理 ?
作者 : jasper(Jasper)討論區板主 程式設計甘苦談頂尖高手上班族的哈拉園地優秀好手貼文超過1000則人氣指數超過70000點
[ 貼文 1403 | 人氣 96053 | 評價 6980 | 評價/貼文 4.98 | 送出評價 42 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/1/19 下午 01:59:41
>>1. 需求條件錯誤, 未能反映實際的系統負荷. (業主的責任)

上述民生的問題,一般人都知道,負責系統分析的人會不知道嗎?業主或許沒明講,但開發團隊知道問題卻不反應嗎?還是只依業主的意思而自我設限?

>>規格書不容易寫,為了預防為來雙方爭議, 還是要寫得清楚

規格書不該是用來預防爭議的,當它的功用是被設定在此,雙方的心態就有所偏差了,只想完成一件事,而不是想成就一個有品質的產品。

在網路上看到一個簡報,它是這樣寫著:
品質是
對製造商而言,符合規範
對使用者而言,滿足
帶來輕鬆賺錢的中間商及高士氣的團隊。

符合規範只是第一項,重點是使用者滿足及開發團隊要覺得有面子,是否有賺錢的中間商就看產品了。符合這些條件才能稱為有〝品質〞。

軟體的品質要從正確性、高效性、可靠性、安全性、可昇級性、可維護性去探討,而要有效管理軟體品質,就得在各個階段實施檢測,系統分析的方法、系統架構、程式碼的撰寫等等,都要有所規範,否則無法預料會有什麼疏忽而導致不可預測的後果。

軟體公司基本上不會有品管部門,要靠程式員自己檢驗,所以每一個程式員都該接受這方面的教育,只是我們大都只接受如何寫程式的教育,沒有人教如何測試程式。

不曉得 ozzy123 為何對台灣這麼瞧不上眼,不過他說的卻是事實,環境影響了一切,想改變就得革命,要革命就得先灌輸思想,有心之後找方法就簡單了。
作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/1/19 下午 05:20:06
台灣根本就不適合發展軟體
作者 : daniel(冷眼)討論區板主 VC++優秀好手遊戲程式設計優秀好手DirectX優秀好手C++優秀好手貼文超過1000則人氣指數超過70000點
[ 貼文 1564 | 人氣 84169 | 評價 6990 | 評價/貼文 4.47 | 送出評價 15 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/1/19 下午 05:33:42
>癥結所在
其實就在這呀.抱怨文一堆,只會抱怨確不會做事
作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/1/19 下午 07:56:56
所以大家都在抱怨, :-)
作者 : fcwang(fortran) 程式設計甘苦談優秀好手貼文超過200則
[ 貼文 231 | 人氣 2831 | 評價 2440 | 評價/貼文 10.56 | 送出評價 6 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/1/19 下午 09:41:06

>
>上述民生的問題,一般人都知道,負責系統分析的人會不知道嗎?業主或許沒明講,但開發團隊知道問題卻不反應嗎?還是只依業主的意思而自我設限?

開發團隊必須本專業領域的知識(Domain Knowledge), 依據客戶需求提供建議. 有些需求要變更, 有些需求要放棄, 有些需求可以完全保留. 變更或刪除都必須有足夠而充份的理由說明. 會發生問題是因客戶有盲點 又不願意給系統整合商(System Integrator) 賺錢, 尤其是 完全沒有經驗的業主與完全沒有經驗的開發團隊.

>規格書不該是用來預防爭議的,當它的功用是被設定在此,雙方的心態就有所偏差了,只想完成一件事,而不是想成就一個有品質的產品

依據個人過去的經驗, 軟體專案合約中有 "軟體功能規格書會視同合約的一部份" 的條文, 不能含糊. 所以要避免爭議是必要的, 也是被業主(尤其是大公司)所接受.


>在網路上看到一個簡報,它是這樣寫著:
>品質是
>對製造商而言,符合規範
>對使用者而言,滿足
>帶來輕鬆賺錢的中間商及高士氣的團隊。

製造業在同一產品之生產線上, 每日作業都是例行性工作; 而軟體業是以專案進行, 每日作業一直往前推進, 例行性工作並不多. 軟體業與製造業特性不同, 兩者品質觀點, 未必能有一致的理論與做法.


>軟體的品質要從正確性、高效性、可靠性、安全性、可昇級性、可維護性去探討,而要有效管理軟體品質,就得在各個階段實施檢測,系統分析的方法、系統架構、程式碼的撰寫等等,都要有所規範,否則無法預料會有什麼疏忽而導致不可預測的後果。
>

軟體品管是從需求訪談(Requirement Survey)就開始, 品質是依客戶所願意投入的軟體開發預算(與人力資源)與容許的時程, 而被設計出來的, 不能無線上綱.
Scope Management 是專案管理非常重要的課題. 如果Scope失控, 則會導致時程失控, 預算失控, 甚至專案失敗都有可能.


>軟體公司基本上不會有品管部門,要靠程式員自己檢驗,所以每一個程式員都該接受這方面的教育,只是我們大都只接受如何寫程式的教育,沒有人教如何測試程式。
>

沒有制度的軟體品管 每個 程式員做法可能不 一致 當然不可能產 生有品質的 軟體


>不曉得 ozzy123 為何對台灣這麼瞧不上眼,不過他說的卻是事實,環境影響了一切,想改變就得革命,要革命就得先灌輸思想,有心之後找方法就簡單了。
>

要革命就得先灌輸不同的思想,個人的經驗與 Jasper 兄有許多差異, 觀點的差異不正是值得您的參考.
作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/1/20 下午 12:55:30
SQA , IEEE 早就有規範了, 只是台灣的software firms 不想做吧了
作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/1/31 下午 06:00:40
the root-cause is 台灣的民族性
作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/2/7 下午 10:15:51
當軟體需求規格制定完成時,軟體開發就成唯一種勞力密集的工作,也就是與製造業無異
作者 : fcwang(fortran) 程式設計甘苦談優秀好手貼文超過200則
[ 貼文 231 | 人氣 2831 | 評價 2440 | 評價/貼文 10.56 | 送出評價 6 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/2/11 上午 10:30:43

>當軟體需求規格制定完成時,軟體開發就成唯一種勞力密集的工作,也就是與製造業無異


軟體業與製造業有截然的不同. 製造業的產品是規格一致, 軟體業的產品規格則不可能是一致的.

製造業的機台(或設備)只能執行一定內容與範圍的工作. 程式設計師不是機台, 他必須依每次工作的規範, 以腦力去執行產品(程式)的產出.

製造業是複製相同規格的產品, 軟體業必要的優勢是複製設計的模式 (Pattern), 而不是規格.
作者 : jasper(Jasper)討論區板主 程式設計甘苦談頂尖高手上班族的哈拉園地優秀好手貼文超過1000則人氣指數超過70000點
[ 貼文 1403 | 人氣 96053 | 評價 6980 | 評價/貼文 4.98 | 送出評價 42 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/2/12 上午 09:02:03
>軟體業與製造業有截然的不同. 製造業的產品是規格一致, 軟體業的產品規格則不可能是一致的.

這句話看起來怎麼怪怪的?不是有產品規格書嗎?不是該百分百的達到產品規格書的要求嗎?

程式設計師跟傳統製造業的工人是沒有兩樣的,或許只是書讀得多一點吧!但也不是百分百是如此,別以為工人就不讀書。

作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/2/12 下午 06:31:45
how to improve the production of programmers
http://blog.csdn.net/teamlet/article/details/5568646
作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/2/13 下午 01:45:26
在Pressman的教科書中談到基本的SQA定義:“品保即是與需求的一致性” , IEEE 830 - SRS 中就有一個要點就是規格的一致性
作者 : fcwang(fortran) 程式設計甘苦談優秀好手貼文超過200則
[ 貼文 231 | 人氣 2831 | 評價 2440 | 評價/貼文 10.56 | 送出評價 6 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/2/18 下午 09:28:40

>>軟體業與製造業有截然的不同. 製造業的產品是規格一致, 軟體業的產品規格則不可能是一致的.
>
>這句話看起來怎麼怪怪的?不是有產品規格書嗎?不是該百分百的達到產品規格書的要求嗎?
>

軟體業是以專案進行, 每個專案的軟體規範不會一致, 如果是相同的規範的話, 那就不用程式設計師來開發, 直接re-use.

軟體業像製造業的部份是複製軟體產品的光碟片和包裝的工作, 這部份的成本佔總成本的比例是非常少的.
作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/2/20 下午 01:19:29
都不要學,去公司工作在邊學邊做
作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/2/22 下午 04:35:36
當programmer 對 programming languages 的熟悉就能量化其產值,programming languages. 只是一種工具,而specification design 詳細完整, 此時programmers 與非軟體業的製造業的產線工人一樣,也就是personal software process 的方法 - 可量化.
作者 : jasper(Jasper)討論區板主 程式設計甘苦談頂尖高手上班族的哈拉園地優秀好手貼文超過1000則人氣指數超過70000點
[ 貼文 1403 | 人氣 96053 | 評價 6980 | 評價/貼文 4.98 | 送出評價 42 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/2/23 上午 09:33:32
整體的規範也許不同,但細分之下,還是有相同的,所以有很多是 Copy & Paste 再 Update 的。

re-use 的狀況也很多,翻翻提到物件導向的相關資料就知道了。

所以軟體開發也是可以量化的!
作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/2/23 下午 04:20:16
http://yunus.hacettepe.edu.tr/~sencer/cocomo.html#cocomo81
作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/3/2 下午 10:46:05
because many it firms just want to hire cheap engineers to code the codes without quality and they don't know how to qualify the software product.
作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/3/6 上午 11:04:47
quality is a big joke for Taiwan.
作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/3/30 下午 04:02:31
the kpa of CMMI level 3 is SQA. but many tw it firms own cmmi certification , but software quality still is poor.
作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/3/30 下午 04:05:42
sorry is level 2 - SQA
作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/4/6 上午 11:41:07
http://www.ifpug.org/
作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/4/7 上午 12:30:59
http://www.virtualmachinery.com/sidebar2.htm
作者 : rollboy(roller) 貼文超過200則人氣指數超過10000點
[ 貼文 396 | 人氣 24176 | 評價 370 | 評價/貼文 0.93 | 送出評價 62 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2013/11/26 上午 01:41:10
不知為何也逛進來這個討論主題了,
看著大家的熱烈討論我也受不了想來個感想發表 ...

我覺得, 這些軟體工程的問題根本終究還是回到"人"本身吧.
如果人本身沒有感覺到 軟體工程 的重要, 那麼它就不會那麼重要, 或者它根本就不重要.

我必須說一下我應該還算是個專案開發菜鳥,
多年以來我都只是窩在家裡自己寫code, 那時候也沒過有 軟體工程 這東西的想法,
幾年前剛進入職場, 一開始也是很完全沉浸享受自己的coding世界.

不過漸漸的開始感覺事情變的不一樣,
你必須跟別人co-work,
你看的到別人寫的code, 別人也看的到你寫的code ...
然後你開始挑剔為何別人寫code的layout總是不排好, 註解不寫清楚,
你甚至還跳出來主動幫忙修整好大家共用的function ...
我猜這應該是我開始對 軟體工程 有一點點意識, 不過當下實在說不出自己到底要的是什麼.

我還記得那年也跟其他部門的老手co-work, 但是當時一直覺得為何issue report 到老手那都會不了了之,
我也總是認為老手可能根本偷懶之類的 ...
但是最近突然頓悟, 發覺原因也許是因為沒有做好工作排程, 老手大概不干工作就這樣一直被插斷, 所以只總是默默的說了一句: 這個會在找時間處理.
我之所以頓悟是因為我現在亦是深受其擾.
如果開發需求總是來的又急又快, 那換走的可能就是開發品質了.

再說軟體開發本身, 我覺得有一問題是軟體本身實在是太彈性, 太易修改了,
所以常聽到工程師說"這個之後再改", "我先這樣處理, 其他的問題再找時間討論",
我相信我自己也常常看這種事, 而這種行為延伸出來的問題可能就會是 "先這樣做, 等到測試後發現問題再來改"

另外再說規格書開發這件事, 至少我現在看到的是有些規格書會變成是由開發者自己來寫,
然後開發者就又把規格書當設計書來寫 ... 變成充斥著一堆SW function name, 專有名詞再加上一些流程符號的文件, 文件已經不像是文件了 ...
若再從這樣的規格書去當作品質指標, 那大概人人都滿分吧 ...
我以前也著實對 規格書 的撰寫感到困擾, 但是最後我想通了, 規格書的重點應該就是清楚向別人宣告 "你到底想要一個什麼樣的功能跟產品"

我還是得再次重申程式設計對於我而言是興趣, 我也不是那麼專業,
而對於軟體工程的看法, 充其量也只是對現況做出一些檢討, 然後再來四處跟人家請問建議霸了(例如這裡),
實務經驗我累積的實在是少之又少, 唯一能作的就是把握每次的機會, 好好的練習一番.
作者 : fcwang(fortran) 程式設計甘苦談優秀好手貼文超過200則
[ 貼文 231 | 人氣 2831 | 評價 2440 | 評價/貼文 10.56 | 送出評價 6 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2013/11/26 上午 08:15:50

>我還是得再次重申程式設計對於我而言是興趣, 我也不是那麼專業,
>而對於軟體工程的看法, 充其量也只是對現況做出一些檢討, 然後再來四處跟人家請問建議霸了(例如這裡),
>實務經驗我累積的實在是少之又少, 唯一能作的就是把握每次的機會, 好好的練習一番.

To rollboy(roller):

看到最近您的 PO文對軟體工程實務的渴望, 卻未能得其門而入, 四處跟人家請問建議霸了(例如這裡),是無法解決問題的.
誠如我開宗明義所提 "經費,決心及專業"才是成功之道, 缺一不可.
個人願意以野人獻曝的態度, 提供您一些軟體開發專案管理實務的諮詢,個人的Profile有e-mail address 可供您聯繫!
作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2013/11/26 上午 10:15:26
Basically, SE is TW is useless. Because many IT firms are small and don't care quality of sw products. That's that
 
>我覺得, 這些軟體工程的問題根本終究還是回到'人'本身吧.
>如果人本身沒有感覺到 軟體工程 的重要, 那麼它就不會那麼重要, 或者它根本就不重要.
>
>我必須說一下我應該還算是個專案開發菜鳥,
>多年以來我都只是窩在家裡自己寫code, 那時候也沒過有 軟體工程 這東西的想法,
>幾年前剛進入職場, 一開始也是很完全沉浸享受自己的coding世界.
>
>不過漸漸的開始感覺事情變的不一樣,
>你必須跟別人co-work,
>你看的到別人寫的code, 別人也看的到你寫的code ...
>然後你開始挑剔為何別人寫code的layout總是不排好, 註解不寫清楚,
>你甚至還跳出來主動幫忙修整好大家共用的function ...
>我猜這應該是我開始對 軟體工程 有一點點意識, 不過當下實在說不出自己到底要的是什麼.
>
>我還記得那年也跟其他部門的老手co-work, 但是當時一直覺得為何issue report 到老手那都會不了了之,
>我也總是認為老手可能根本偷懶之類的 ...
>但是最近突然頓悟, 發覺原因也許是因為沒有做好工作排程, 老手大概不干工作就這樣一直被插斷, 所以只總是默默的說了一句: 這個會在找時間處理.
>我之所以頓悟是因為我現在亦是深受其擾.
>如果開發需求總是來的又急又快, 那換走的可能就是開發品質了.
>
>再說軟體開發本身, 我覺得有一問題是軟體本身實在是太彈性, 太易修改了,
>所以常聽到工程師說'這個之後再改', '我先這樣處理, 其他的問題再找時間討論',
>我相信我自己也常常看這種事, 而這種行為延伸出來的問題可能就會是 '先這樣做, 等到測試後發現問題再來改'
>
>另外再說規格書開發這件事, 至少我現在看到的是有些規格書會變成是由開發者自己來寫,
>然後開發者就又把規格書當設計書來寫 ... 變成充斥著一堆SW function name, 專有名詞再加上一些流程符號的文件, 文件已經不像是文件了 ...
>若再從這樣的規格書去當作品質指標, 那大概人人都滿分吧 ...
>我以前也著實對 規格書 的撰寫感到困擾, 但是最後我想通了, 規格書的重點應該就是清楚向別人宣告 '你到底想要一個什麼樣的功能跟產品'
>
>我還是得再次重申程式設計對於我而言是興趣, 我也不是那麼專業,
>而對於軟體工程的看法, 充其量也只是對現況做出一些檢討, 然後再來四處跟人家請問建議霸了(例如這裡),
>實務經驗我累積的實在是少之又少, 唯一能作的就是把握每次的機會, 好好的練習一番.
作者 : rollboy(roller) 貼文超過200則人氣指數超過10000點
[ 貼文 396 | 人氣 24176 | 評價 370 | 評價/貼文 0.93 | 送出評價 62 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2013/11/26 下午 09:32:59
但我還是得客觀的說一句, 今天是剛好讓我遇到這樣的環境, 所以才會有機會去省思軟體工程的問題.
雖然悶悶不樂, 但我應該是幸運的, 我確實從中學習到了東西...
作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2013/11/27 下午 03:39:50
http://www.sec.org.tw/
 
This is a site that provides some SE related lectures
作者 : fcwang(fortran) 程式設計甘苦談優秀好手貼文超過200則
[ 貼文 231 | 人氣 2831 | 評價 2440 | 評價/貼文 10.56 | 送出評價 6 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2013/12/1 下午 12:14:16

>但我還是得客觀的說一句, 今天是剛好讓我遇到這樣的環境, 所以才會有機會去省思軟體工程的問題.
>雖然悶悶不樂, 但我應該是幸運的, 我確實從中學習到了東西...

我相信您確實學習到了東西, 您知道軟體工程的重要性與問題的嚴重後果, 但是軟體工程真正的 Know-How 是在於如何把問題解決.
這不僅是技術問題, 也是管理問題. 這是要有管理與技術兼施, 才有可能突破你面臨的困境. 光是以技術的角度切入是難以達到理想的境地.
Microsoft Solurion Framework (MSF)有微軟的實務指引(Guideline) 你可以作為參考.

管理與執行力才是成功之道.
作者 : oldpgmr(OldPgmr)
[ 貼文 70 | 人氣 0 | 評價 20 | 評價/貼文 0.29 | 送出評價 26 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2014/1/14 下午 12:00:35
隨便逛逛 看到這個! 正好 這時 ETC 又爆皮陋! 大家 要是可以 就去 挖挖 這個系統是如何做的! 好好 做個 CASE Study 研究 保證 所有 導致 品質低落的 原因 都犯了!
作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2014/1/14 下午 12:26:00
make a complete system specification and then make a full software test plan. that's that.
作者 : rollboy(roller) 貼文超過200則人氣指數超過10000點
[ 貼文 396 | 人氣 24176 | 評價 370 | 評價/貼文 0.93 | 送出評價 62 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2014/1/17 下午 04:07:08
假設方法都有了, 但會發現最大的要素還是"人",
我要說的是假設你已經訂定好一件很周詳的規劃跟方法,
然後開始向下溝通, 不管是技術層面或管理層面,
總覺得最後結果會跟你想像的有些出入,
然後在花更多時間溝通 ...

10個人就會有10種想法,
可能會產生43個溝通路徑,
然後造成43個誤解跟overhead之類的 ....

不過這可能是純管理上的問題 ...
作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2014/1/17 下午 07:10:06
the major reason is many people don't know how to qualify software products .
作者 : idoncys(Hsu-春源)
[ 貼文 53 | 人氣 6713 | 評價 430 | 評價/貼文 8.11 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2014/2/13 上午 01:45:58
我沒待過中大型公司,也許大公司接了好幾百好幾千萬的案子,可能比較有機會去管理品質吧.個人不排斥這三個條件,但我自己跟我認識的都是5人以下的,像這樣規模的小公司恐怕三項條件沒有一個能符合.

前些日子去鹿港某橡膠製造業現場評估後報了個 ERP更新專案150萬,,聽系統意見說明的承辦人雖然認同我方系統但沒有決定權,事後是由一起吃飯閒聊的主管跟老闆出面打槍,他們直接用30萬訂上限,要完成從進料生產出貨庫存到會計流程,且轉移所有舊資料

>首要的條件 要有軟體品質管制的執行單位與人力. (經費問題)
30萬鐵定了錢,因為是完全專案客製化,而150萬要配置品質管制的單位與人力一樣會很吃力.

>第二項條件 每個軟體開發專案必須要求要有客戶(或用戶)同意並簽署的書面規範及相關的文件. (專案管理問題)
據我的經驗,這類從農地拔起的中小型鐵皮工廠不會有特別安排資訊類員工,而對他們要求派出熟悉系統到可以進行書面確認的可能性不高.對於我方拿出的系統規格書,一來看不懂,二來即使我方拿來當爭議的憑據也沒什真實效力.

>第三項條件 有一套實用與合理的評等的標準 與 執行軟體品質的方法.管制軟體品質才算有基本的條件. (品質管理問題)
客戶簡單一句某某功能不合用,往往就是對品質的否定,標準很簡單,合不合理的認定過程又迅速.

小公司面對的實況就是這樣,很多同業會真的用30萬去接,為了不賠錢,但會對品質付出多少關照呢.
作者 : idoncys(Hsu-春源)
[ 貼文 53 | 人氣 6713 | 評價 430 | 評價/貼文 8.11 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2014/2/13 上午 01:46:12
我沒待過中大型公司,也許大公司接了好幾百好幾千萬的案子,可能比較有機會去管理品質吧.個人不排斥這三個條件,但我自己跟我認識的都是5人以下的,像這樣規模的小公司恐怕三項條件沒有一個能符合.

前些日子去鹿港某橡膠製造業現場評估後報了個 ERP更新專案150萬,,聽系統意見說明的承辦人雖然認同我方系統但沒有決定權,事後是由一起吃飯閒聊的主管跟老闆出面打槍,他們直接用30萬訂上限,要完成從進料生產出貨庫存到會計流程,且轉移所有舊資料

>首要的條件 要有軟體品質管制的執行單位與人力. (經費問題)
30萬鐵定了錢,因為是完全專案客製化,而150萬要配置品質管制的單位與人力一樣會很吃力.

>第二項條件 每個軟體開發專案必須要求要有客戶(或用戶)同意並簽署的書面規範及相關的文件. (專案管理問題)
據我的經驗,這類從農地拔起的中小型鐵皮工廠不會有特別安排資訊類員工,而對他們要求派出熟悉系統到可以進行書面確認的可能性不高.對於我方拿出的系統規格書,一來看不懂,二來即使我方拿來當爭議的憑據也沒什真實效力.

>第三項條件 有一套實用與合理的評等的標準 與 執行軟體品質的方法.管制軟體品質才算有基本的條件. (品質管理問題)
客戶簡單一句某某功能不合用,往往就是對品質的否定,標準很簡單,合不合理的認定過程又迅速.

小公司面對的實況就是這樣,很多同業會真的用30萬去接,為了不賠錢,但會對品質付出多少關照呢.
作者 : fcwang(fortran) 程式設計甘苦談優秀好手貼文超過200則
[ 貼文 231 | 人氣 2831 | 評價 2440 | 評價/貼文 10.56 | 送出評價 6 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2014/2/13 上午 10:57:52

>我沒待過中大型公司,也許大公司接了好幾百好幾千萬的案子,可能比較有機會去管理品質吧.個人不排斥這三個條件,但我自己跟我認識的都是5人以下的,像這樣規模的小公司恐怕三項條件沒有一個能符合.
>

Hsu-春源 (idoncys)兄

你所敘述的情況是台灣小型資訊軟體公司的悲歌, 不接這個個案, 公司馬上會面臨生存的問題, 個人可以理解.

不過, 公司的組織行為與思維 如果不改變, 同樣(或更糟)的情況可能會繼續下去.

改變(Change)才會有轉機, 有陣痛也可能有風險, 是兩難. 改變還必須投入額外的資源.
但是變革是可以管理的 (Change Management是管理議題). 思維的改變是主要關鍵.

廣義的品質管理包括每個 Case的獲利能力, 管理良好的公司 對這個非常注重.

類似你所舉的個案, 公司決策者的決定(繼續沉淪 或 品質優先), 會影響公司的未來走向.

作者 : idoncys(Hsu-春源)
[ 貼文 53 | 人氣 6713 | 評價 430 | 評價/貼文 8.11 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人fcwang註記此篇回應為最佳解答 2014/2/13 下午 12:09:18
Fortran兄您好.

如果選項明顯如大字報可以區分繼續沉淪 或 品質優先,很難想像有人會點選對品質選擇沉淪,因為故意交付客戶品質不良的系統,造成操作環節的問題,最後會跟搬石頭砸自己的腳下場一樣.

如果由案子失敗的結果來推斷是品質不良造成,也不一定成立,畢竟影響層面太廣,反推只要品質顧好就能使案件成功,在接案之初恐怕也不敢這樣下斷論.況且品質好壞該由誰定義,單方堅持的品質結果也許另一方並不認同.

我覺得會造成對品質產生爭議的多半是源生自客戶百變的需求,一般的情況是對需求置之不理會被批為設計不良,處理起來則容易造成錯誤而被歸咎成品質不良,另外現階段擺平需求成功後,往往平靜一段時間又因新的需求改變或增加而面臨再次修改的命運,這樣的循環會周而復始的挑戰品質.

面對這樣的情況,思維要如何改變?

以足額組織架構來應戰就會有效嗎?我想光是誰是人才,誰提的見解有效可能就無法產生共識,君是否常聽聞業務帶回來的承諾被工程人員潑冷水甚至翻桌的?另外做這樣組織的改變,對於小公司而言,往往未享成事美果之前,就先敗壞了公司財物地基,錢又不能像紙一樣說燒就燒,燒過頭了怎辦.

小公司沒有多少籌碼可以附和組織改變的口號,所以改變不一定要擴編組織,如果有其他有效率的想法作法可以應對品質的挑戰,兵不用多呀.當效率達成,品質達陣,一樣可以確保每個case 的獲利.

我認同思維的改變是主要關鍵,但作法上不會輕易再朝擴編組織路線前進,個人認為應該將思維改向系統的改變,做出可以快速反應各式需求的系統,如果做不出來,其他的改變恐怕都無濟於事.

就像面對修車廠的黑手師傅,如果系統提供方式是告訴他每個料件都要先編品號才能打修車單,依照車輛的品牌,車型,年份來區分,您覺得系統會成功嗎?君有看過不同思維的系統嗎?
思維的改變也可以增加人手去想這個問題,並把系統做很大,但最終結果會真的是黑手師傅能用的上手的系統嗎?
作者 : fcwang(fortran) 程式設計甘苦談優秀好手貼文超過200則
[ 貼文 231 | 人氣 2831 | 評價 2440 | 評價/貼文 10.56 | 送出評價 6 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2014/2/13 下午 02:43:48

Hsu-春源 (idoncys)兄:


>>小公司沒有多少籌碼可以附和組織改變的口號,所以改變不一定要擴編組織,如果有其他有效率的想法作法可以應對品質的挑戰,兵不用多呀.當效率達成,品質達陣,一樣可以確保每個case 的獲利.

既然可以效率達成, 品質達陣, 又可以確保每個case 的獲利. 重要的點目標都能達成, 貴公司管理的績效應屬良好, 貴公司如能鴻圖大展, 成長為更大的公司時, 個人所提的看法就會用到.

>>我覺得會造成對品質產生爭議的多半是源生自客戶百變的需求,一般的情況是對需求置之不理會被批為設計不良,處理起來則容易造成錯誤而被歸咎成品質不良,
>>另外現階段擺平需求成功後,往往平靜一段時間又因新的需求改變或增加而面臨再次修改的命運,這樣的循環會周而復始的挑戰品質.

個人的觀點 是

1. 百變的需求是屬於"Scope"管理的問題, 你給客戶方便, 他就會隨便. "Scope"管理不佳, 就會導致 "Quality"的問題.

2. 在 SDLC (Software Developmnent Life Cycle)中 "Scope"的變動在需求分析階段 與 測試階段所耗費的成本 ,可能有相差數十倍的差距. 超出合理範圍的需求變更, 如果要求客戶必須付出額外的成本, 對跟Scope Management 會有一定的成效. PM如何與客戶溝通, 這一項非常重要.
作者 : idoncys(Hsu-春源)
[ 貼文 53 | 人氣 6713 | 評價 430 | 評價/貼文 8.11 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2014/2/13 下午 04:52:27
Fortran兄:

講到隨便,我的確一開始都是請專案客戶 [隨便] 開他要的,盡量天馬行空的去想,不要老是問說系統有沒有這功能那功能,而是告訴我們希望系統有什麼功能,講得出來就會做得出來,如果客戶有戒心,請款期就會拉長,等到主題都上線一些時間再請尾款,

我們是小公司,所有碰過的案例,一開始就全盤規劃的機率不高,會有個含糊的架構概念,但細節都是等著逐步被挖出來,很少使用者會有能力開TABLE欄位與寫規劃書的,如果一個案子等跟使用者談完細節再施工,做到後期會發現,前面談的往往不到整體的幾十分之一,即使是拿個舊的系統要求參考後換掉,也是一種省略需求描述的作法而已,等到架構比照辦理作出來了,才是藏在細節的魔鬼真正出現的時候.

打擊魔鬼要有好的方法才行,不然打不成還會被抓去交替,而沒有好的方法,縱使使用專案管理的角度幫忙進行,恐怕也是只有被罵成絆腳石的份,然後一起被消滅.

另外專案完成後並非就此終止,因為系統可能要陪伴客戶使用個10幾20年,沒有人可以很清楚記住10年前幫某客戶開什欄位,做了什流程,但10年後電話打來,要有辦法在電話掛斷以前回答客戶所指問題.如果電話打來要再去程式模組翻箱倒櫃,這系統的前途就堪慮了.

對於系統我的概念很簡單,就是必須具備類似最小單細胞生物的特性,可由此單細胞去任意變化出各式面貌與功能的個體,這單細胞跟任一專案無關,卻可變化出任何專案.實際的做法就是引用動態排列組合的概念,並將所有商業邏輯藏於客戶資料庫,系統再動態取出演譯.這跟動不動就將需求寫成程式碼的做法不同,我認為程式碼寫一次就好,所有的專案通通適用.為什麼要一個專案寫一套程式?造就管理上的困難.

講實體一點,系統施工就像只搬水泥跟砂到客戶端蓋房子一樣,揣摩客戶的想法後,從試捏打造開始,逐步建造出客戶心目中想要的房子,這跟搬一棟實體房子再去做敲打改造不一樣,一般的系統作法就是複製或繼承一堆現成的房子,然後 : 我給你一棟豪華別墅,算你500萬就好,如果廁所要開兩個窗,不行,因為改造功能浩大,除非另外加50萬,1年後要求 窗戶要改氣密或加大,不行.因為當初改窗戶的師傅已經離職,沒有人知道當初他怎麼挖出那道窗戶的.XD

系統如果可以透明化成文件管理,就可以將程式設計師的角色淡化掉,只需將系統分析與規劃做好,再請工讀生照文件的標準流程作業,要產生訂單管理,出貨管理,庫存管理,財務管理,租賃管理,施工管理,任一個想得到的管理主題都是簡單的事,這不是空口白話,而是實際上我們的作業模式.目前我的 WEB 網站 www.idon.com.tw 陸續將請工讀生將文件補齊,就可在WEB 上面看到各專案各式各樣的主題.

當導入系統有好的方法以後,可以解決客戶所有需求,專案管理的介入就會幫助更大,不管是業務或後勤工程方面.因為等文件備齊後,裡面就會有很多各專案的KNOW HOW,又是以文件型式存在,又可以線上DEMO,知識傳承的力量會倍增,也由於都是可讀性文件,由文件去兜出一個新的專案,就像在既有的基礎上,進行新的排列與組合工作, [喜歡這個主題嗎?好的,立即打包給你] ,包含panel,table,trigger,sp,window,與各式邏輯,專案經理也很容易邀請客戶一起線上驗證新管理主題的功能,此時專案經理的力量將可充分發揮.
作者 : ozzy123(ozzy) 資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4466 | 人氣 37262 | 評價 10860 | 評價/貼文 2.43 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2014/2/15 下午 07:18:02
http://www.embedded-wizard.de/tl_files/tara/tara/img/emwi6_ide_screenshot.png
A GUI application systems code generator for embedded platforms , C++ likes programming language .
 板主 : 徵求中
 > 資訊軟體 - 討論區
 - 最近熱門問答精華集
 - 全部歷史問答精華集
 - 資訊軟體 - 知識庫
  ■ 全站最新Post列表
  ■ 我的文章收藏
  ■ 我最愛的作者
  ■ 全站文章收藏排行榜
  ■ 全站最愛作者排行榜
  ■  月熱門主題
  ■  季熱門主題
  ■  熱門主題Top 20
  ■  本區Post排行榜
  ■  本區評價排行榜
  ■  全站專家名人榜
  ■  全站Post排行榜
  ■  全站評價排行榜
  ■  全站人氣排行榜
 請輸入關鍵字 
  開始搜尋
 
Top 10
評價排行
資訊軟體
1 ozzy 300 
2 fortran 220 
3 monkey 160 
4 SweetWo 130 
5 judas 120 
6 openmind 110 
7 Jasper 100 
8 好說 100 
9 Hsu-春源 90 
10 Steve 90 
資訊軟體
  專家等級 評價  
  一代宗師 10000  
  曠世奇才 5000  
  頂尖高手 3000  
  卓越專家 1500  
  優秀好手 750  
Microsoft Internet Explorer 6.0. Screen 1024x768 pixel. High Color (16 bit).
2000-2018 程式設計俱樂部 http://www.programmer-club.com.tw/
0.1875