改善開發流程，先了解整體歷程

改善開發流程，先了解整體歷程
文/李延華 (記者) 2008-04-27

應用程式生命周期管理(ALM)囊括的範圍
從專案的發想、形成、分析設計、開發、測試到上線，提供輔助、管理與監控機制。
在專案開始之前，企業應先評估專案的可行性，定義專案的範圍、衡量維護的能力與成本，以及可能的好處。

Application Lifecycle Management
應用程式生命周期管理，縮寫是ALM，可以降低軟體專案的投資風險

軟體是企業重要的神經系統，然而根據統計，
專案的成功率大約只有3成，失敗原因在於軟體開發的高複雜性。

軟體生命周期管理是囊括分析、設計、開發、測試、上線各階段的工作與管理機制。
事實上在專案開始之前，企業應先評估專案的可行性，
定義專案的範圍、衡量維護的能力與成本，以及可能的好處。
如果投資與收穫不成正比，那麼便應該考量其他替代方案。

當專案進入分析階段，需求的搜集與確認是很重要的第一步，
如果系統分析師沒有正確掌握使用者需求，致使最後開發出來的軟體，
不符合使用者期待，那麼調整與修正的成本，將難以估計。

另一個面向是需求確認的精準度，例如「很快」、「簡單」、「很高」、「很低」等形容詞，
缺乏衡量的具體標準，應該透過量化的數據，搭配視覺化的呈現，確保雙方的溝通沒有模糊地帶。

在設計與開發階段，開發者可透過塑模工具建構系統的架構，然後透過轉換機制，
將模型轉換成程式碼框架，再撰寫詳細的邏輯判斷規則。
現在有不少開發工具已內建單元測試的功能，可協助開發者自動化產生單元測試程式。

隨著程式的開發，假如都能逐步累積的單元測試，可為程式碼的正確性建立紮實的測試基礎。
若再輔以功能測試與壓力測試，就不用擔心系統上線後仍暗藏未知的地雷。

其他還包括文件與程式碼版本的控管，使用者變更需求在所難免，
但如果沒有一套完整的溝通與管理流程，變動將埋下系統不穩定的因子。
當需求改變，若沒有通知到相關人員，對於生產力也是一種傷害。

另一個管理的重點，在於程式碼的新增、修改與刪除皆需經過授權。
有了版本的控管機制，除了避免新舊版本的程式碼相互覆蓋，造成錯亂的情況，
也可防止有心人士竊取或竄改團隊的心血結晶。
至少任何更動與修改的行為，管理系統會留下記錄。

雖然IT主管都知道ALM的重要性，然而由於相關工具的價格並不便宜，
再加上老闆們未必看得到ALM帶來的好處，因此企業導入的比例不高，
寧願投資可以為企業賺錢的解決方案。
但若站在避免損失、維護商譽、保障投資的角度，
它絕對是改善軟體開發品質與成效必要的機制與手段。文⊙李延華

Portfolio Management
組合管理
在啟動軟體專案之前，應有一段評估的過程，
範圍包括專案的規模、可運用的預算、人力資源、能力、時間及上線後的維運成本。

組合管理主要是根據投資潛在的報酬率及減少重複投資的層面，
找出耗費成本在開發創新功能所產生的問題。
評估的重點包括分析專案的風險、決定專案使用的技術與基礎架構、
持續與高階主管互動，確認專案符合業務目標。

Requirement Visualization
需求視覺化
傳統的需求管理，是在訪談使用者之後，記錄使用者的需求，
然後系統分析師再根據需求設計軟體，交由工程師開發。

然而當使用者看到系統時，常常反應實際開發出來的系統與想像中的不同。
因而衍生出「雛型開發」的作法，先讓使用者看到初步發展的規模，
確認無誤後再開發細節。
需求視覺化的構想與雛型開發很相似，
強調先讓使用者看到實際的介面與流程，逐步討論每一個步驟，確認無誤後，再開發實際的功能。

Modeling
塑模
軟體設計與開發需要一份藍圖，因為軟體開發絕對不能是任意、隨性與採取且戰且走的形式。
一般來說，建構軟體的設計藍圖便稱為塑模。

目前最流行的塑模語言是UML（Unified Modeling Language），可以協助企業界定的系統範圍，
找出系統的主要參與者與支援性的參與者，並觀察系統內部的工作人員、資訊系統、共通使用的術語、概念、及工作流程。

Configuration Management
建構管理
在軟體架構單純、工作切割簡單的開發模式，程式碼可能是儲存在每個工程師的電腦中。
但隨著軟體複雜性的提高，及開發規模越來越大，再加上人員分散的開發型式。
為了避免版本的混亂與錯誤，專案團隊必須實施軟體建構管理。

建構管理包括文件、程式碼及函式庫的版本控管，現在許多產品可做到版本之間的差異比對，
並加入流程與授權等控管機制，以避免有心人士非法存取程式碼。

Code Convention
程式碼慣例
以多人的開發團隊來說，很難要求與期待開發團隊的所有成員，都有能力撰寫高品質的程式。
然而為了確保系統的可維護性，專案團隊必須建立一套寫程式的慣例。

開發成員的異動在所難免，加上一套軟體的生命周期約有80%耗費在維護上，
藉由程式碼慣例可以強化軟體的可讀性，當所有工程師都遵循相同的命名規則、
判斷方式及註解寫法，所有成員都可以快速地了解程式碼。

Change Request Management
變更請求管理
變更請求是指在軟體發展生命周期內產生的，
包括缺陷、功能增強、需求變更等，所有需要改動專案相關內容的請求。
軟體系統牽一髮而動全身，某個模組的修改，可能連動其他部分導致後續整合的困難，或者使得某些問題不斷發生。

多數企業是以書面形式記錄和管理變更請求，但這類方法往往使後續的追蹤變得不易，
導致變更管理流程難以貫徹，因此有系統地管理變更請求，是降低成本避免錯誤的必要機制。

Unit Test
單元測試
單元測試是測試的最小單位，每開發一個模組，就對應一個測試程式。
傳統的想法認為應先寫程式，再寫測試程式，這種做法看似合理，但當系統接近完成時，
開發者往往不知從何下手，因此放棄寫測試程式，而且修改的成本很高。

然而先寫測試程式令開發者感到困惑，而且很耗費時間。
因此市場上已有開發工具提供自動化的機制，透過設定開發者每完成一個模組，就可以產生單元測試程式。

Load Test
壓力測試
壓力測試是一段持續對系統加壓的過程，以試圖找出系統的效能瓶頸，
或者了解系統可以承受的極限。人工加壓的方式，成本較高，而且可能有盲點。

執行壓力測試前，必須先錄製測試腳本，並設定加壓的模式，
包括執行單一或者多個腳本、逐步增加使用者，還是瞬間湧入大量使用者等。
壓力測試工具，會依設定模擬巨量使用者登入操作系統，並記錄各項效能指標，作為企業分析的依據。

Function Test
功能測試
功能測試的重點是確認程式執行的正確性。程式碼的修改在所難免，
但如果每次的修改，要以人工確認系統沒有錯誤，不僅麻煩，而且不保險。

透過功能測試工具，只要設定好腳本及檢查項目，例如系統該有的彈出視窗、顏色或訊息回應，
以及功能流程是否有誤、選單是否顯示預期的內容，及網頁連結是否正常等，工具將記錄所有過程。執行一次之後，即可確認系統的正確性。