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

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

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