Innovate 2010 IBM開發者大會記事
上週參加了每年慣例的 IBM 開發者大會。Innovate 2010 IBM開發者大會活動主頁。從 2007 年的 Jazz 、2008 年 Rational Team Concert、一直到今年的主題「Let's build a smarter planet」，仍然聚焦在團隊的協同開發工作。這一點也不令人意外。軟體系統的複雜度與日俱增，軟體開發的工作早就脫離了單一平台、單一技術、單一開發者就能獨力完成的時代。由複數成員組成開發團隊，完成一項專案已經是常態現象。而《人月神話》一書中提到團隊成員愈多，則互相交流的活動量就愈頻繁，溝通成本也就愈高。因此能夠降低溝通成本，有效協同團隊成員活動的工具，自然就日益重要了。
不過連續說了這麼多年的協同開發，今年的協同重點自然也不會原地踏步。從一開始談如何實現協同開發，今年已經進展到如何在協同開發的基礎上，追求軟體生產效率，改善軟體品質以及促進創新機會 (Efficiency, Quality, Innovation)。
New thinking: software & systems econometrics
第一場共同議程，指出目前的軟體專案皆面臨著兩種處境：一、 Complexity ，例如複數的系統平台與技術；二、Fiscal & Societal Impact ，例如上述人月神話所提及的成員交流活動與溝通成本。儘管在導入協同開發工具 (如 Rational Team Concert) 之後，可以降低我們在這兩方面的成本，但想進一步改善軟體品質、促進創新，仍需進一步地規劃評量機制。
在簡報中提到，全球500大企業使用的軟體中，只有千分之三在開發過程有評量機制，屬於受管理的軟體專案。其他都是不受管理的專案。
Top Reasons for Software Litigations:Source: Capers Jones, Measurement, Metrics and Industry Leadership, 2009 and Software Engineering Best Practices, McGraw Hill, 2010
- Unstable, changing requirements
- Inadequate quality control and poor quality measures
- Inadequate progress tracking
- Inadequate cost and schedule estimating
- False promises by marketing and sales personnel
Innovate 2010 「創新開發，迎向智慧新世代」議程簡報
管理學常說「能量化者方能管理」。此議程便指出，想要進一步提升軟體質量，就必須要建立成本、品質與風險的評量機制 (measures of cost, quality and risk)。
Software is the invisible thread enabling systems-of-systems
軟體是一條看不見的線，實現系統的系統。
嗯，非常有哲理的一句話。附帶一提，這次大會的上午議程，提供同步口譯服務，那句中文是口譯人員翻的。
Agile systems and software delivery practices with outcome-based management is a better approach.
Innovate 2010 「智慧型產品創新關鍵報告」議程簡報
在專案開始時，就要制定軟體質量評量與監控制度，選擇正確的量測工具，才能掌握現況，有利於因為開發中的各種變化。
持續整合的黃金期限是一天。
針對上述內容， IBM 提供的解決方案就是 Jazz.net 與 Rational Team Concert 。
座談時間
如何進行員工培訓
- 制定統一的開發流程。
- 選擇標準化的開發工具平台。
- 善用指導者的角色。註: 這是 Agile/XP 中的 pair programming 之應用，新進人員與資深人員結對作業，在工作中實現經驗與技術的傳承。
UML 的優點
- 可以從不同的面相(非source code)呈現軟體的內部關係與系統架構。
- 高真實度的模型。註: 這要看工具，能實現塑模開發的工具才能做到。
- 應用語意性高的語言，描述客戶的業務流程。
Cloud computing
協同開發新紀元，軟工開發新標準
下午軟工議程的前兩場，主要延續上午的內容。以 IBM 內部的活動為案例，說明他們如何在軟體專案中，運用 Jazz 與 RTC 實現上午議程所敘的協同開發與軟體評量制度。 其中提到了系統開發作業程序規範中，要制定文件格式標準，令文件為「可產出的」。這便是在實現當初 Jazz.net 所承諾的事 (See: What is Jazz)。
我補充說明一下，這裡說的文件，基本上指的是寫在程式碼或工作內容中的文件。再由工具去組織裡面的內容，產出像 Word .doc, PDF 這類的「報表文件」。錯誤的方式是讓團隊成員直接把文件內容寫在 Word .doc 這種完全沒有增加專案開發進度的地方。我的慣用解釋是： compiler 又不能把 .doc 裡的內容變成可執行的程式，寫在裡面只是做白工。
語法快譯通
此議程介紹的主角是 IBM 開發的 EGL 程式語言。 IBM 說 EGL 是一種「business language」，讓開發者專注在設計商業流程的語言。
就我這十幾年來的經歷觀察所見，近十年來的主流程式語言 (Java 除外)，都力求讓程式人員將他們的精力放在流程的設計之上，而不要在糾結於結構中。在開發應用軟體的過程中，把我們的腦力投注在思考如何改善流程。而不是去想這個欄位是要 public 還是 private ，或是那個方形介面要如何塞進圓形接口這些事。所以像 Python, Ruby, JavaScript 受到的重視與日俱增。例如美國 SEC 就提議以 Python 作為描述金融流程的報表語言 (See: Python Could Become the Language of Finance)。
EGL 的語法，外觀介於 Python 與 Ruby 之間。但是它有著一個很特殊的行為，使它別樹一幟。EGL 它可以把 EGL 程式碼，編譯成 COBOL, RPG, Java 或 JavaScript (Ajax) 程式碼，進一步地結合現有的 COBOL, RPG, Java, JavaScript (Ajax) 程式。如果各位有看過《Vala入門》，可以從 Vala 語言與 C 語言的結合方式，想像 EGL 的行為。
EGL 在 IBM 的軟體服務方案中，主要用於協助客戶進行「mainframe modernize (大型系統現代化)」。因為 IBM 的客戶中，有許多資訊系統仍然在大型主機上健壯地運作著。而它們都是用 COBOL 開發的，維護者也是 COBOL, RPG 等語言的程序員，並不了解 Web 這種現代化系統架構。協助這些客戶與他們的 COBOL 程序員，將他們的資訊系統轉換到 Web 上，就成了重要的「現代化」工作。
簡報中提到 IBM 以 EGL 協助美國維吉尼亞州的 Chesapeake 市政府，在90天內，投入 2 個COBOL程序員人力(Chesapeake 市政府資訊部人員)，完成了既有市政資訊系統的現代化。讓市民都可以透過 Web 2.0 的介面使用市政資訊系統。國內也有銀行業者與醫學中心的案例，同樣是利用 EGL 達成大型系統的現代化需求。 EGL 的解決方案，提供了低成本、易於管理以及漸進轉移的優點。
駭客漫步在雲端
這個議程的氣氛很歡樂，一方面是議程內容本身很活潑，另一方面則是講者 Lim 的口音。因為講者 Lim 是新加坡人，一上台就用新加坡口音的閩南語說自己的中文說不好，所以要講英語。只是新加坡口音的英語也是很難懂的，跟日本口音英語有得拼。全場聽到他在說「史馬的(smart)」、「靠(cloud)」等等，另添趣味。幸好我常聽日本口音英語，所以聽起來還挺習慣的，哈哈。
簡報中提到軟體專案要求三項目標，即 Fast, Good, Cheep ，但是每個軟體專案只能具有其中兩項。這讓我想到強襲魔女的笑話，卡爾斯蘭人有軍人、知性與誠實三種氣質，但任何一個卡爾斯蘭人只能擁有其中兩種氣質... 呃，扯遠了。
簡報中說明了許多 Web 軟體的漏洞與安全問題。對於有 Web 軟體開發經驗的人，應該不難理解那些案例。最後是廣告時間，介紹 IBM WebAppScan 有什麼好處。 WebAppScan 可以進行 Web 軟體的白箱與黑箱測試，抓出潛在的安全漏洞。最有價值的是它的產出報表，不只是記錄安全漏洞，還能針對這些漏洞，提出可行的解決方式，讓程序員可以依照它的修正建議，修補漏洞。