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
閱讀完整內容

談談OCP

作者：
圖片
看到「好人難為」一文，主角是一位專班學生，看來他似乎很委曲，因此我在意見箱內提議，他可以好好研究一下軟體設計的第一原則：Open-Closed Principle (OCP)，或許可以解決他的困擾，這件事涉及到軟體工程的教育與訓練的問題，也就是說，學以致用的問題，因此有必要寫一篇短文以OCP為例，來談談軟體設計原則的運用，這些原則並非軟體發展的食譜(cookbook)，而是發展者必須放在心裡的「指引」(guideline)，這種指引必須落實成為diciplines，其他如設計樣式(design patterns)也具有指引特性，因此才能廣泛運用，也就是說，可以重覆使用(reuse)，學習時最好蒐集一些範例，可能有助於這些設計原則或樣式的運用，有如念法律的人必須研究一些判例一樣，學習軟體發展方法時也不例外。 OCP是物件導向方法的核心，1988年由Bertrand Meyer在他的著作" Object-Oriented Software Construction "一書提出，它是說：「軟體實體必須能夠延伸但不能修改」(Software entities should be open for extension but closed for modification)，換言之，必要時可以延伸軟體實體的功能但不必修改它，該軟體實體可以是類別、模組、功能、程式、或組件，完全看你用在何處。Meyer的原意是說，類別實作(或程式)除了須要除錯外，如要改變功能或增加新功能時不得改變父類別(superclass)，而由子類別(subclass)來達成，子類別可以利用繼承(inheritance)機制重用父類別的屬性或作業元，但可改變或增減其功能，因此繼承不旦可以重用父類別的實作，同時可以延伸原功能，該子類別的介面可以異於父類別的介面，這是一般具有物件導向的人所熟悉的繼承機制。 到1990年代OCP被重新定義為，新介面可以繼承自「抽象類別」，但非繼承實作部分，原介面不得修改，也就是說，你設計的組件或模組不能改變，當需求改變時，你可以增加新程式以延伸該模組的功能，但不能改變你也許認為十分完美而能作業的原程式，請看下圖(R.C. Martin)， 左邊圖形表示，如果Client想使用另一個Server時，Client必須改變，因為兩者皆是concrete，這樣就不
閱讀完整內容