2008年4月29日 星期二

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

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

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

最新主題
‧ 4/29 處理器新聞與文章 - Cray改採Intel處理器製造千兆次運算能力的超級電腦 (guruchin)
‧ 普京搬出克里姆林宮轉戰“白宮” (chengbengdan)
‧ 97年台中市市長盃跆拳道錦標賽 (110120)
‧ 怎么瘦小腿?怎么瘦小腿快?怎么瘦小腿好?(shouxiaotui)
‧ 當心網路陷阱 (daiqianwen)
‧ 《Beautiful Code》原來好的程式碼是這樣子寫出來的! (aone)
‧ 調皮的事情 (cenhhh)
‧ Skype 企業總機系統 89元 包月打到飽,免通話費。神擎科技 與 PChome線上購物 全球同步上市(morgeorge)
‧ 什麼是"H.M.D."? (urainbow)
‧ 旺角金魚街 Lifestyle Management Group Limited (jsjsjj)
‧ 從事資訊業的感想 (mygoca)
‧ iT邦幫忙推出針對回答的「回應」功能 (ithelp)
‧ TODO (aliceyeh)
‧ Sharp Series drum Cartridge chip resetter (blueera)
‧ 用Javascript試作Memento Pattern (fillano)
‧ 【好康】試用Gogrok軟體寫心得短文,就送POLO衫! (plus318)
‧ 假防毒公司之名、行病毒散布之實 (come2)
‧ 點部落推薦- 瓶水相逢.Net C#練習題系列 (dotjum)
‧ HSDc. 公佈六月份完整的系統分析課程 (Kenming)
‧ Blog開張測試...絕對值 (kupin)
‧ 有社區警衛就代表安全嗎?李恕權家宅遭匪入侵案的慘痛教訓~CoolBid購物情報-13-2008-04-21(mrjones)
‧ UML互助會,會員招募中! (271080)
‧ VIA CN700 規格 (superstanwu)
‧ 東京CCIE-Lab攻略(2008),心理建設篇 (kunnan0618)
‧ Barracuda Networks 為Salesforce.com全球用戶抵禦最新釣魚惡意軟體威脅 (chinamost)
‧ 策略和營運(完) (yinshih)
‧ [下載][Blog]zomplog-3.8.2繁體中文 (hanklu)
‧ 數字轉國字 (aqr199)
‧ 善用PGP加密工具的七大法寶 (pgp)
‧ 取得免費的McAfee防毒軟體 (ataru)
分享至PLURK 噗浪 分享至FACEBOOK 臉書

沒有留言: