Web 2.0 - 別人的 bug 自己修

作者：
最近因為接了行政職，生活開始忙碌了起來。為了能夠讓訊息暢通與方便行程的安排，忍痛買了 BlackBerry 黑莓手機。黑莓手機手機在國外賣的嚇嚇叫，他的 QWERT 功能讓習慣電腦操作的人愛不釋手，實際使用後，發現它的好處不只這些。

國外的系統在介面的使用上的確著墨很多，BB 的介面讓你很快的建立一個會議 --- 一隻手就可以辦到。查詢聯絡人的資料也是，即便你有上千筆的聯絡人，也可以在很短的時間內找你要的人，然後寫 email, 送 MMS 或打電話給他。資工系的學生通常會以『沒有美感』來作為介面設計不好的藉口，這個觀念應該要改。

回到主題來談談錯誤的管理。BB 雖然功能強大，但還是會有錯誤。寫過程式的我們都知道程式的錯誤難免，也可以忍受 --- 只要他們有專業的報修制度。我打過幾次電話，前兩次電話響了近三分鐘都沒有回應，直到第三次才有人來接，但回應是『晚上沒有技術人員，請我白天再打』。我猜想他們的流程大概是這樣子的吧：
  1. customer reports the bug through phone
  2. help desk records the bug, ask the engineer resolve the problem on line if they are available. If the engineer are not available, ask the customer call later. 
現在的手機功能太強，就像是一個小秘書，沒有小秘書兩三天還得了？所有的工作都停擺了。顧客可沒有辦法配合他們的維修流程啊（白天大家忙得要命，哪有時間打電話)。於是我上了 google, 打上錯誤訊息，一下子跑出好多的解決方案。看了第一個方法，我就解決了我的問題。BB 他們做了什麼？什麼都沒有做，只是許多閒暇 人事透過 web 2.0 將他們的錯誤解決方法寫在部落格上，透過許多人不斷的回應，於是最佳解決方案就出來了。或許報修的流程要改一下：
  1. customer reports the bug through phone
  2. ask the customer to "google their problem", if not resolved, go step 3.
  3. help desk records the bug, ask the engineer resolve the problem on line if they are available. If the engineer are not available, ask the customer call later. 
你說我怪BB的服務不好嗎？其實還好，畢竟現在是 web 2.0 的世界了，我們所依靠的是全世界的朋友，不只是廠商。
生活樂趣

留言

張貼留言

這個網誌中的熱門文章

CMMI是什麼?

作者：
CMMI(Capability Maturity Model Integration) 將軟體開發流程視為一種工程 ( 製造 ) 流程，利用控制、量測、改善 (control, measure, and improve) 等循序漸進的方法，達到軟體流程改善的一個框架。 CMMI 是在美國國防部 DoD 以及國防工業協會 (NDIA) 的支持下， CMU 的軟體工程學院 (Software Engineering Institute, SEI) 發展出來的模型。 CMMI 中許多的概念與原理來自於創立 SEI 軟體流程計畫 (software process program) ，並曾任職於 IBM 、領導大型系統軟體開發的 Watts Humphrey 。根據 IBM 與 SEI 的經驗， Humphrey 將廣泛運用在製造流程中的統計流程控管 (Statistical process control, SPC) 的概念，加以修正、擴充後運用於軟體流程管理中。 在一方面，定義軟體開發流程中的各種活動與其彼此間的關係，是將軟體開發流程視為一種製造流程，並實施量化控制的前提之一。在另一方面，由於這些活動相當繁多、複雜且彼此牽動，故唯有在軟體開發活動結構定義清楚之後，方能找出可量測事物，並根據其關連性推論量測值的意義。 CMMI 將軟體開發相關活動的實務作法分為 25 個流程領域 (process area, PA) ，定義其需管理的項目，含一般目標、特定目標、具體作法等，並找出其彼此間的關連性。 依性質來分，這些 PA 分屬於流程管理、專案管理、工程、與支援等四大類 流程管理 ： CMMI 的目的是流程改善，因此流程的定義、維護、修正等均為重要活動。 專案管理 ：因為軟體開發、維護均以專案為單位，以便在專案進行前進行人力、資源、時間、經費計算以及專案進行中管控，如需求變更、進度監控等。 工程 ：軟體開發實質上涵蓋許多軟體工程的原理與具體作法，如需求發展、分析、應用設計、系統設計、實作、測試、部署、維護等相關活動，這些活動需要加以管理。 支援 ：支持前三類活動進行之環境與工具之支援活動等，例如提供產出物與組態管控、議題追蹤等活動。 CMMI 有連續式 (continuous) 與階段 (staged) 式兩種表示法。採用連續表示法
閱讀完整內容

CRC cards - 非正規物件導向發展技術

作者：
圖片
最近看到Kent Beck與Martin Fowler講的一句『諺語』，說："Stick with simple tool, like pencil, paper, and whiteboard. Communication is more important than whizbang." 我才想到PO這篇短文，提供學生們(至少選我開授的OOSE的學生)參考。這句諺語我認為最重要的是『溝通』，溝通在軟體發展的過程中十分重要，尤其想使用『敏捷方法』發展軟體的工程師們更為重要(可參考Agile Alliance在2001年發表的『宣言』(manifesto)，此地不宜對宣言多做闡述)，問題是你要使用何種工具或方法來溝通？我想除use cases外，CRC cards可能是最佳工具之一，它是隨時隨地可得的低技術工具，易學易用。 軟體開發與維護時，工作夥伴的合作十分重要，換言之，團隊合作是發展工作成敗的關鍵，夥伴合作必須有好的工具或技術協助，CRC cards可能是適當的工具之一，據我所知，在台灣發展軟體的工程師很少使用像CRC cards這種簡單但被認為是一種『驚奇』(wonderful)的發明 (David Bellin, et al. 1997)，而這種技術雖然簡單，但卻可避免發展早期陷入太細節或者產生雜亂且定義不清楚的類別，因此希望這篇報導能引起從事軟體發展的人士注意到這種『老而彌堅』的技術，而且也希望各界人士能予指正。 CR C cards (Class-Responsibility-Collaborator cards) 是1989由Kent Beck與Ward Cunningham所共同介紹 (http:\\c2.com/doc/oopsla89/paper.html)， 其出現時期與WWW相同，至今約有20幾年的歷史，這個工具開始是用來教導新學員如何學習物件導向的觀念與程式製作，後來的演變卻超乎在教室內的需要，而成為軟體分析、設計以及敏捷思考的工具。CRC cards的軟體發展方法屬於一種非正規方法 (informal approach)，雖然屬非正規方法，但CRC cards可做為正規方法的輸入或前端作業，如Booch方法、James Rumbaugh, et al. 的OMT、Ivar Jacoson, et al.的OOS
閱讀完整內容

課程改進

作者：
今年在輔大招開的TSCE11，其中在Panel Discusion中(主題：軟體核心能力)，我提議軟工教育訓練由OO modeling概念開始，而程式則依據models來撰寫，這種提議可能須修改教學程序，不過我認為，「軟體核心能力」的目的乃是要建立優良的軟體系統，而models比複雜的程式容易描述系統，也比較容易保養系統，因為其抽象層次較高，也符合程式語言以及軟體發展方法的演變之故。我提出這種意見，希望對軟體工程教育有興趣的人士能夠討論，提供意見。
閱讀完整內容