2007/01/10

從高鐵售票系統看CMMI

對於Roger的《大砲開講 » Blog Archive » 高鐵售票系統品質差嗎?》 ,我有一些關於CMMI和軟體開發的想法。Roger 提到:

今天,在神通電腦網站瀏覽了一下,發現他們是通過「能力成熟度整合模式第三級(CMMI Level 3)評鑑」,是 CMMI 有問題?還是神通電腦專案協調出現問題呢?

很多國內廠商通過了能力成熟度整合模式評鑑後,軟硬體品質真的會改善嗎?真的會遵循這些程序嗎?還是把它擺在角落呢?


讀者,你認為是 CMMI 有問題?還是開發組織有問題?

我承認,我是不太喜歡CMMI,尤其不喜歡許多CMMI專家或軟工學者有意無意地忽視「人」的問題。在這個案例中,或許Roger 對於開發者的專案協調與程序遵循有疑問,我倒是覺得,開發者與CMMI,都有問題。

先看開發者。聯合報的新聞說,「神通電腦坦承:程式與旅客需求有落差」。我聽到這句話中有話說︰開發者認為這售票程式沒寫錯,但可惜的是,高鐵的旅客並不欣賞這「登機」用的售票程式。

嗯?「登機」的邏輯?我想起來了,飛機票常會超賣,我的確有過一大早去機場waiting的經驗。所以哩,旅客本來就該預期一個會超賣、會waiting的「飛機級高鐵」囉?

真是自以為是。

CMMI ML3 裡有個PA叫做 Validation,其目的在於證實未來提供的產品,放在預期的環境之後,能夠滿足其「預期的使用需求」。換句話說,Validation 是要確保 「你做了正確的事(You built the right thing)」。如果說,開發組織有機會,找些人來先行「體驗」一下這買票的過程,理應不難看出,旅客期待的高鐵是像坐火車、坐捷運,還是像坐飛機?(我還沒坐過高鐵,但是我坐飛機時可從來不用去售票機前買票!)

因此很明顯地,開發組織雖然通過了ML3,卻沒做好ML3裡的Validation;開發出來的程式或許符合SRS或RFP,但是不符合旅客們的預期。

不過,說完了開發的組織,這下我要說一說CMMI。其實CMMI不能算是開發流程,它其實是開發流程的「需求」,也就是說,你可以用各種奇奇怪怪的模型、方法、理論、實務,只要合乎那需求,那就 OK。那麼,CMMI給我們在「需求發展」上的指示是什麼?很簡單,要「用廣泛的方法確認需求」。

是該說CMMI精明,還是說不負責任?「用廣泛的方法確認需求」這真的太正確啦!卻也好像沒說一樣!我們開發者千方百計,不就是想搞楚清 What customers want? 不過,CMMI 的確也給了些例子,像是 product demo, prototype, simulation, scripts, scenario 等等。然而我依然覺得,這些例子都是一筆帶過,最終還是害那些不懂得顧客心理的開發組織,做一些自以為是的Validation,而非由外而內的 Validation。

最後,讀者,我的忠告︰你的顧客無法告訴你,他們不滿足的是什麼;但你仍然可以「用廣泛的方法確認需求」,把爛需求早點殺掉,以發掘顧客的不滿足是什麼。雖然是廢話,畢竟還是句正確的廢話!



備註︰
1. PA:Process Area,中譯作「流程領域」
2. Validation,中譯做「確認」
3. 需求發展︰Requirements Development,同樣是ML3的PA


參考:
CMMI的正式網站:http://www.sei.cmu.edu/cmmi/
CMMI 模式V1.1中文版:http://www.sei.cmu.edu/cmmi/translations/trad-chinese/models/

相關:大河馬的創意動物園: 大河馬看高鐵自動售票系統有評論高鐵售票系統UI的圖文評論。
Newer Post Older PostHome

《工商服務》

Random Post 試用中

Powered by Stuff-a-Blog

《同類的文章》



Widget by Hoctro

最近的文章

《最近的分享》