 討論區主頁 軟體工程管理
從軟體品質看高鐵售票系統的烏龍事件 | 無發表權 |
| 樹狀顯示 | 新的在前 | 前一個主題 | 下一個主題 | 頁尾 |
| 發表者 | 討論內容 |
|---|---|
| Member | 發表時間: 2007-01-12 08:59 |
Not too shy to talk   註冊日: 2005-04-07 來自: 發表數: 29 |
從軟體品質看高鐵售票系統的烏龍事件 由國內‘ 已通過 CMMI Level-3 評鑑 ’的某大知名資訊系統廠商 S 公司承包設計的台灣高鐵售票系統，在各界的注目與關切之下，竟然還是發生了重複訂位售票及系統不穩等烏龍事件，讓全國民眾對於國內軟體公司的能力再一次引發了質疑。
據瞭解，S 公司‘ 已通過 CMMI Level-3 評鑑 ’的部門，正是負責承包設計的台灣高鐵售票系統的那個部門。 據瞭解，台灣高鐵售票系統的承包合約是 S 公司利潤比較好的合約之一，也無低價搶標賠錢承包的問題。 事關台灣高鐵營運這麼重要的電腦訂位售票系統，在系統不穩定的情況下推出，很多朋友們都好奇不知道 S 公司是如何進行系統測試的 ? 以 CMMI 的觀點而言，該如何看待與改善這個問題呢 ? |
| Lancelot | 發表時間: 2007-01-12 12:03 |
Just popping in 註冊日: 2007-01-12 來自: 發表數: 1 |
Re: 從軟體品質看高鐵售票系統的烏龍事件 QA 很重要, 需要真真實實的實務經驗, 所以相關各Stakeholders要找對人.
而主持CMMI的人也是如此 . |
| iamkpp | 發表時間: 2007-01-17 09:25 |
Just popping in 註冊日: 2006-09-20 來自: 發表數: 1 |
Re: 從軟體品質看高鐵售票系統的烏龍事件 我的看法不一樣
我覺得是軟體上線前的測試不足 第一 雖然說資源充足(前文說是利潤不錯的合約 沒有削價競爭) 但是時程緊迫 趕著啟用 你資源再充足 也沒有用囉 例如 30個人三個月完工-->>如果想放90人進去 一個月就能完成 是不合實際的 第二 在時程趕著緊急啟用下 最先犧牲的就是測試與品質 這種錯誤 應該是缺少大量資料多台測試機的黑箱測試 以上是我的淺見 希望各位前輩不吝指正
|
| damnit | 發表時間: 2007-01-18 21:51 |
Just popping in 註冊日: 2005-09-25 來自: 發表數: 15 |
Re: 從軟體品質看高鐵售票系統的烏龍事件 就算這樣子的討論，想收到的效果是什麼？所呈現的就是一堆猜測與咒罵，但是整件事有比較明顯嗎？或者讓大家知道問題真正的原因，以及要如何來記取教訓，或者說給軟體開發商什麼樣的啟示？畢竟，從別人的失敗經驗去學習，防範自己不犯下別人的錯誤才是真正的聰明人。
如果可以，應該透過貴協會的力量，請 S 廠自己將整個專案的歷程及經驗教訓寫一篇來分享大家吧，如果提出不出來，大概就只有兩個狀況，S 廠的高層自覺管理階層做了很多錯誤的決策很丟臉，要不然就是根本沒有專案的 Lessons Learned，如果是後者的話，應該可以取消他們的 CMMI ML3 評鑑資格了。 要不然，貴協會也應該協請一下工業局，向廠商施壓一下，叫他們配合提出經過情形及檢討報告，畢竟他們的 CMMI ML3 輔導及評鑑都有工業局的專案補助，提報告應該是合理的，全民都在看！ |
| Terry | 發表時間: 2007-01-25 08:44 |
Just popping in 註冊日: 2005-04-11 來自: 發表數: 19 |
Re: 從軟體品質看高鐵售票系統的烏龍事件 我認為承包本案票務系統設計的 S 公司有沒有通過 CMMI 評鑑並不是重點，本案重點還是測試工作沒有做好，關鍵應在於一開始就沒有把測試計畫做好，測試個案的設計也不夠週延，即使是需求規格有問題，嚴謹的測試個案的設計與模擬測試也應該可以在正式上線前發現問題才對吧。
我建議 貴協會可以多開辦一些有關軟體測試的課程。 |
| 樹狀顯示 | 新的在前 | 前一個主題 | 下一個主題 | 頁首 |
| 無發表權 | |