「ALM再創軟體品質新典範」系列報導

應用軟體生命週期的初現，使軟體開發脫離藝術創作的階段，轉而使用工程化的標準流程，並整合角色、流程、工具等各層面。我們後續將探討由週期理論朝向實踐過程中敏捷式開發流程成為主流、CASE工具自動化、角色專業分工等，各層面之現況與影響，並帶入使用者對應用軟體生命週期的經驗分享，從案例中瞭解企業如何讓使用者、軟體工程師、企業主管等目標一致的實際作法。

ALM專題系列之一　ALM再創軟體品質新典範

使用者期望程式提供穩定的服務
從應用的層面，程式就像一個黑盒子（Black Box），使用者輸入數據，輸出是具商業價值的資料。以生活中的事物比擬，用戶期望程式像販賣機，丟進銅板（數據），選擇渴望的商品（商業邏輯），蹦出來的是解渴的飲料（商業價值）。由此邏輯看待程式與販賣機的共通點是，直覺化使用、處理快速、容易維護、可靠，重點是快速地滿足需求。至於處理的過程是否像科技藝術品般精緻，使用者並不再乎、也感受不到，即使是內建機械手臂的販賣機，使用者得到飲料後便匆忙離去，市場的時間競爭不會讓他們有閒情逸緻欣賞機械手臂選擇商品的過程，並讓人們樂在其中。對使用者而言，美輪美奐的販賣機與鐵盒方塊型的機臺並沒有太大的不同，能提供快速解渴服務的便是好機器。

但事與願違，程式開發技術普及，使用者期望工程師依其需求產生成品，而不是由工程師設計完成，使用者只能依循其邏輯而已。如果需求無法達成，即使程式設計再精巧，使用者也可以另尋高手。

以開放源碼的為例，使用者在網路上即可下載符合需求的軟體，相對於商用軟體供應商，仰賴飛機運送產品光碟到使用者手上，已是數小時後的事了。只是，供應商直到最近才發覺，數小時交貨的歷程中，使用者仍在持續改變需求，這個並反應在產品售價，也就是企業追求的利潤上。
繼續閱讀

ALM專題系列之二　中小型企業最適用的敏捷式開發流程

應用軟體生命週期尋求方法論的解決方案，主要是為了實現管理手段，並整合開發角色、流程、技術等各層面。目前IT領域中，具體實現應用軟體生命週期的流程有兩種：整合的能力成熟度模型（CMMI）與敏捷式開發流程（Agile Programming）。前者適合大型企業或獨立軟體供應商等，具有為數較多的開發人員，以及講求制度的企業文化；後者則適用於各式開發團隊，也就成為我們此次探討的焦點。

應用軟體生命週期的方法論：角色、流程、工具
軟體開發生命週期方法論考量到角色、流程、技術等三個層面。對於中小企業的體質（例如開發團隊人數、企業文化、營運成本等）現況，雖然沒有絕對的方法論可規範軟體開發，我們也無法預期可以找到一個萬用的流程套用在所有專案上，其變因眾多，例如使用的技術、開發團隊的規模與地理位置、開發角色的工作風格、組織文化、市場風險等。此外，因為中小企業開發團隊人數不多，許多專案執行時，每個人常身兼多種角色，而敏捷式開發流程的彈性，則成為主流應用。

至於流程方法，主要是瀑布式（Waterfall Process）與敏捷式（Agile Process）兩種，後者也稱為反覆式（Iterative Process）。基本上企業的開發流程都可歸納為這兩種，只是本身並不知曉而已。這兩種流程的本質差異在於：如何將專案分解成更細小的部分，這也決定產品交付的次數與品質的優劣，瀑布式只交付產品一次，並決定品質與功能是否契合使用者需求；而敏捷式會交付多次，或者稱為多個發行版本（Release），功能會在反覆的開發過程中逐漸完整，而品質也會因為循序式的修正，而減少錯誤。
繼續閱讀

ALM專題系列之三　整合式CASE工具自動化精簡開發流程

CASE工具的發展能具體實現軟體開發生命週期，不僅開發過程更自動化，而且已將工具功能逐步結合流程的需求，成為理論轉為實踐的重要關鍵。除了商業版的開發工具，企業也可選擇開放源碼的解決方案，但前者高度整合與技術資源，可免除開發團隊應用工具的技術瓶頸。

實現應用軟體生命週期的CASE工具特性
企業面對CASE工具，常質疑其輔助上的意義，而不是必備的特性，但近來開發工具逐步自動化，卻能減少開發人員處理例行式事務的人力耗費，讓企業體認開發工具的效益。此外，由於敏捷開發方法在反覆增量的過程，更仰賴自動化的輔助，當工具結合流程後，跳脫輔助的角色，便成為開發人員不可或缺的利器。

以往企業面對CASE工具，難以確定應何時導入，以及應用的時機。但現在為了軟體能儘速上市，不僅仰賴工具高度自動化，也必須考量到CASE工具所帶來的成本效益。以下列出目前CASE自動化的主要功能與特色：
●正向工程（程式碼產生）
●逆向工程（由現有程式產生原架構與設計邏輯）
●支援抽象且完整的敏捷式開發流程
●測試模型與自動化
●模型與程式碼的雙向、同步開發
●自動產生文件
●自動建構版本（Build）
●搭檔開發（Pair Programming）
●支援新的塑模標準與模型轉換技術
●第4代程式語言（4GLs）
●中央儲存庫（Repository）
繼續閱讀

ALM專題系列之四　開發角色轉變：團隊的功勞與工匠的苦勞
應用軟體生命週期依流程而搭配專業分工，將以往集一身於大成的開發工作，區分為分析人員、架構人員、開發人員、測試人員與管理人員等。專業分工不僅是配套措施而已，企業在軟體工程化的經驗中，發現專業分工的不足、權責不明，是導致軟體品質低落的因素之一。《人月神話》（經濟新潮社）一書作者Frederick Brooks提到，軟體開發團隊應如同一個外科手術小組，明確定義專業分工的角色與職掌，點明角色與分工的意義。

但我們更應瞭解到，人員與角色的區別。以企業中現行的狀況，無論是一對一或多對一的配置，只要每個角色的業務能準確地執行，縱使一個人負責多個角色仍不至於影響軟體品質，也就是應用軟體生命週期所要達成的目標。舉例而言，一位有歷練與認知的開發人員，當他實施測試工作時，應公正地驗證程式效能，不必然非區分不可，特別是中小企業中，無法負擔大型開發團隊的人事成本，而且敏捷式開發方法也未強制規定角色的配置。然而，分工卻帶來職業生涯上的衝擊。

許多開發人員經歷大學教育與資訊工作的歷練，磨練出撰寫複雜程式的能力，但這個角色的工作因為印度與大陸的崛起，受到就業競爭的挑戰。企業常將例行性、低技術性的程式撰寫工作，委託印度或大陸完成，甚至整個專案均透過外包，而營運中心僅需配置專案經理，供整合與驗收而已。摒除工具自動化，為專業分工的開發角色帶來的職業衝擊，敏捷開發方法更因為一人身兼多種角色的工作，而必須同時瞭解架構、測試、管理等，不僅只是程式撰寫的業務而已。

以下我們將針對應用軟體生命週期主要的角色：分析、架構、開發、測試、管理等，簡述其工作內容，以及其面對變革的職業衝擊。
繼續閱讀

ALM專題系列之五　「人」是應用軟體生命週期的關鍵

對企業而言，採用敏捷式開發方法是實現應用軟體生命週期的方式之一，在反覆淬煉的過程中，逐漸增強軟體品質，但不是用於確保軟體品質。此外，企業莫因為軟體開發工程化，而將人員比擬為另一種形式的工具，相對的，人員依舊是企業的重要資產，與創意來源。

「銀彈」無法解決所有的問題
過去，企業面對天才型或英雄型工程師的職業衝擊，現在將他們歸入流程之下，等於瓦解他們自主的能力，猶如要求一個身經百戰的士兵繳械，情何以堪。然而，人員、流程、工具等三者整合缺一不可，否則應用軟體生命週期形同具文。一些組織避免使用流程，代之以個人英雄主義和他們開發組的天才發揮；另一些團隊過於強調流程，試圖透過給團隊過多的過程來保證成功。之所以企業會有如此大的差異，在於聽信組織變革的神話，以及高估流程變更的能力，與低估其阻力。Frederick Brooks在其著名的《No Silver Bullets》一文中提到，沒有單一的方法論（無論是技術上或管理上），能將現有的軟體開發生產率提高一個數量級。我們知道，單一的解決方案不能解決任何問題，實際上，最終的成功必須包括所有的因素－－在人員（組織）和專案之間取得平衡，不能偏廢。

人治與法治之間的平衡：彈性的流程與以人為主
以法約束人的行為，這是軟體工程化強調流程的出發點，以及必然的趨勢。然而，臺灣本地人情事故管理特性使然，往往注重口頭命令與告誡治理業務，也就是人治。敏捷式開發流程既注重流程（法治），又兼具以人為本（人治）等，兩方都未偏廢。雖然敏捷開發方法不盡然適用所有中小型企業的開發團隊，但其優點是，僅規範原則、保有最大彈性，企業可以適其商業流程、人員習慣、組織特性、應用技術與工具等，逐步調整。

管理的反樣式（Anti-pattern）：人員的互動更勝於流程與工具
敏捷式方法面對3個重要的問題：程序不是很清楚、仰賴自動化工具、以及不重視系統結構，而重視快速滿足客戶需求。雖然軟體品質可以在漸進過程中逐步強化，但開發人員必須具備充足的經驗，以避免在變動過程中迷失方向，成為管理黑洞。
繼續閱讀

ALM專題系列之六　開發經驗談：團隊特質為ALM的關鍵指標

為了讓大家更瞭解應用軟體生命週期的應用現況，我們採訪鼎新、碩網、HSDC等3家廠商，分別代表大型、中型、小型等軟體開發團隊，探討其實際作法與分享經驗。

大型開發團隊自訂ALM系統
對於跨國性商業為主的企業或獨立軟體供應商，其開發人員可超過100人以上，屬於大型開發團隊，具高度自主的開發實力，不必仰賴其他廠商推動的解決方案。這類企業可傾向自行開發專屬的應用軟體生命週期系統，從需求、塑模到驗證等，以整合本身業務所需的商業運作邏輯為主要考量。

中型開發團隊：極致式搭配開放原碼工具
以10~15人組成的開發團隊，可歸類為中型的組織。中型開發團隊導入應用軟體生命週期，目的是加強軟體品質與產品競爭力，例如採用Rational解決方案，以及CMM驗證標準。由於Rational United Processes（RUP）清楚區分各個流程階段與分工角色，缺乏實際運作彈性，以及商業工具難以客製化與整合其他應用工具，所以這類開發團隊也從RUP轉向極致開發流程，並搭配開放源碼工具。這類團隊選擇開放源碼，主要是可取得開發工具原始碼的優點，為使用者提供自主的客製化與整合其他工具時使用，並歷經應用市場的驗證。

小型開發團隊培養柔軟的思考力
HSDc顧問賴信仁建議，本土的開發人員應邁向架構設計人員，培養抽象化結構設計的能力，他引用Martin Fowler所說：「Keeping Software Soft.」，以避免開發人員陷入「dirty work」的代工苦勞。他也採用80/20法則的觀點分析，本地的開發人員應充實架構設計能力，才能以20%的心力，獲取80%的利潤，擺脫大陸與印度不斷追趕的壓力。
繼續閱讀