摘要:提升資訊軟體品質 CMMI 學習營
特別在週六 (11/15) 起了個大早，準備到 中央大學參加 「提升資訊軟體品質 CMMI 學習營」
不知道是不是今天天氣特別好的關係，高速公路上真的是一路塞呀 @@ 本來預計 40 分鐘會到的，卻整整又多開了 半小時
第一場是 逢甲的薛念林副教授 「軟體設計對軟體品質的影響」
可惜的是，到的時候都已經是都過一半了 Orz
薛副教授有在實作大學的教務系統經驗並用 JAVA 在開發，團隊的開發流程則用 CMMI 。
這場的內容蠻豐富的，設計的概念和實作上會遇到的問題都有談到
像實作 OO 規劃時應該要考慮內聚力，在 class 要確認彼此之間的耦合，以及class 中的 Method 的角色定位。
也有提到 Interface、Abstraction 和一些 Design Pattern 會影響軟體品質的作法
後半場大多都是說Design Model Driven 的重要性
寫程式大家都知道說畫圖是件很重要的事，但真正從畫圖開始到 coding 卻寥寥無幾。我想這也是因為在台灣的軟體開發環境也有很大的關係吧！
以往一般的公司都會要程式人員包山又包海的完成所有的東西，從需求一直到軟體完成。 ( 誰管有沒有文件，程式會動就好了 )
因為軟體是看不見摸不著的，所以沒有辦法像建築工程般都是先畫圖再實作。而是先教大家先實作後再畫圖
所以，也許這也就導致現在的資管系出來的學生會畫圖的沒幾位吧。
沒有將整個軟體全貌畫出來 (用 4+1 View) 的話，我們就會像 小時候所看到的 瞎子摸象般 「摸到象腿說它是柱子」
實在是太貼切了，這不也是應照了軟體開發時的一個問題。
然而，Model 也佔了很重要的角色，因為這可讓團隊之間有
接下來則討論「設計是藝術？」
說實在的，起初我一直都還是認為設計就是藝術。副教授這時舉了一個很妙的例子
程式開發就如同作菜，對一般家庭主婦而言，煮菜是一門藝術，但對大廚而言卻是一種工程。
因為大廚要每一次作出來的菜都要一樣好吃！！若是有一次不好吃就有可能會被評為手藝差
寫程式不也是如此，一專職的程式設計師所寫出來的品質、效能每次所交付出來的都是要維持一定的水準不是嗎？
也提到工作方式和創意是完全不衝突的，舉了一些建築相關的例子。很棒！
=====================================================================
第二場 CMMI 整合工具 周立如總經理 赫石軟體公司 http://www.hermesoftware.com/index.php
這是一套 Web AP 的 CMMI 導入的自動化軟體
功能有
可以將各種 UML 工具所繪製全數匯入至系統，並且還可以自動產生 System Requirement Spec
自動計算 Function Point
需求項目可以 分類
Change Requirement 和 UC 的 Mapping 關係 (可細到文件檔)
但操作面來說的話能有 client 的程式會更方便，這樣子作業才不會頓頓的。
且整合的功能只有 Bug Tracking 、 subversion
可以客製化的項目似乎目前還沒有看到
設定的過程對一般的開發公司來說實在多了點，要非常了解其產出和要追蹤的項目才能知道要如何去使用此系統
另外和程式之間的整合目前也還沒有，這一點真的是很可惜。
====================================================================
第三場是 架構品質分析方式 ATAM 介紹 鄭有進 教授
ATAM 的全名 The Architecture Tradeoff Analysis Method ，它是 Agile 的一種
其實小的不才，今天才第一次聽過這個東東。大致上把聽到的 po 上來
目標
- 架構的過程要文件化
- 不要為了Pattern 而用 Pattern
這真的是很多技術導向的程式設計師有的通病，有太多人根本說不清楚到底是為了什麼功能而用此設計的。
看到書上說這個寫法好、因為以前解決了某個問題，就瘋狂地使用 Pattern ( 或某技術 ) 。
完全不看看和目前的專案 (需求) 功能是否相符
這也意謂著程式的開發難度、維護度、效能上都會有著考驗。
像自已就有遇過，系統上明明就沒有動態切換物件的需要，但 SA 卻把商業邏輯層全部都用 configuration 動態載入，多了一堆的interface 和 class
適時地使用 Pattern 的課題就顯得格外重要
Input
- 需求
- 架構分析
- 分析架構師來分類，可以對應需求
Ouput
- 架構要可以進行簡報 ( 1 小時左右 )
- 定義 Business Goal
- Mapping 架構 和效能
- 定義架構所產生的風險，若此風險跨了一個以上的 UC 則代表為 Trade Off
- 風險分類、主題化
中間還特別提到 VSTS 的 TFS 中的 work item 的Area 如何使用
Interation 大家都知道可以按時間軸來分
但 Area 會填的就比較少，所以就可以借由 Area 來做分類
就先放個網址 http://www.sei.cmu.edu/architecture/ata_method.html
看得懂英文的朋友就先到這裡去了解一下吧！！
====================================================================
最後是問題討論
- 定義 ALM 和 範圍
- 定流程過多導致 團隊效率差
- 定流程過少則不易管理
- 執行力問題
- 不同工具之間的整合困難
其實今天來聽課的人，大多都是大專院校的人來 ，也有一些業界的人士。 可以在這裡聽到 CMMI 導入過程所遇到的困難真的是收獲很多。
像有一位是做 CMMI 服務導入，他們幫客戶導入時會發現不單單只有流程問題，連導入的工具都格外重要。
除了要讓團隊願意接受流程的改變外，還要讓大家可以利用工具來降低大家的工作量。這樣子才能事半工倍
活動免費還提供午餐、點心和飲料，經濟部工業局有這樣子的培訓計畫真的很不錯，各位有興趣的人可以多注意。
