摘要

新資訊系統開發方法 - 敏捷式軟體開發
Keywords / New FAB Design Management Platform,Project Design Management,Agile Software Development,714
本文以敏捷式系統開發方法(Agile Development)開發的新廠設計管理平台(PDM)為例,說明此方法與傳統系統開發方法的差異處,並說明如何能分階段完成系統規劃與開發。希望能根據此經驗,提出敏捷式系統開發方法導入之建議,做為新資訊系統規劃發展參考使用。
前言
開發系統最常遇見的問題就是規劃時間過長、需求變更、人力短缺,很難有專職的分析、設計、建構、測試等人員,但又必需在短時間內完成所有系統開發建置流程 (計劃、分析、設計、建置、維護等),並即時開發符合專案所需的系統。敏捷式系統開發方法主要適用在開發週期短與需求不確定的專案,即使是在規劃初期,需求不明或需求持續改變時,利用其著重於同步開發與快速回饋而非事前規劃的方式,藉用敏捷式方法增加系統開發的彈性,以分階段的方式交付成果,逐步完善所有系統需求。隨著新建廠房工程專案逐年增加,人員的工作效率與系統化管理的需求也隨之提高,必須快速完成系統開發才能滿足專案的需求。
何謂敏捷式開發方法
所謂敏捷式開發方法並不是一個固定模式的開發方法,而是一種軟體開發的精神(Spirit),適合用來開發需求不確定或過程中不斷改變難以預測的專案。敏捷式開發的最大特色是同步開發與快速回饋,系統區分為不同模組同步開發,每個模組各自進行需求分析、設計、程式撰寫及測試等程序並循環。軟體開發的過程中,各階段都會隨著項目進行而逐漸完整,而非在一開始將所有的計畫與需求擬定完成。先讓使用者可以根據初步需求建立系統架構再深入進行細節開發,利用分階段交付的軟體,逐步引導使用者確認與調整細部需求 圖一 。
圖一、敏捷式開發方法模組

敏捷式開發的流程是不斷重複的,讓系統開發的成員只要專注於眼前的短期任務進行衝刺。在開發過程中,動態系統開發方法會隨需求改變而反覆調整,目的在於準時且於預算內將軟體開發完成。
敏捷式開發與傳統系統發展方法比較
軟體開發方法有許多不同方式,但大多數開發仍以傳統瀑布式為主軸。所謂瀑布式系統發展方法著重於在系統開發初期就有清楚的需求,強調完整的分析與設計文件。在開發的過程中分階段(需求分析、設計、實作、測試等)逐步完成,每個階段都清楚定義工作範疇及交付文件,前一階段完成後,才能進入下一階段的流程,使每個階段系統開發之工作清楚明確。
瀑布式系統發展主要精神是分階段執行,結構完整,但程式品質高。在進入下一階段前須先做評估以確保設計定義之完整,開發至下一階段後不能任意改變需求。若是需求改變,必須回到初始需求階段重新開發。相對來講,敏捷式開發要求不必這麼嚴謹,當需求改變時隨時可以承受需求變更,增加系統開發的彈性,並做適當的應對與改變。可在短時間內完成相對較小的功能,強調的是能儘早將部分功能先行交付使用,並在整個開發週期中持續改善和增強。
這兩種流程的本質差異(如 表一)在於:如何將專案分解成更細小的部分,這也決定產品交付的次數與品質的優劣,瀑布式只交付產品一次,並決定品質與功能是否契合使用者需求;而敏捷式會交付多次,或者稱為多個發行版本,功能會在反覆的開發過程中逐漸完整,而品質也會因為循序式的修正而減少錯誤。(如 圖二)
差異性 |
瀑布式 |
敏捷式 |
---|---|---|
規劃階段 |
需求分析及系統前期規劃完整 |
需求不明確能先分模組規劃進行 |
設計階段 |
清楚定義要交付的模組及文件,使開發之工作更明確及容易掌握,才能進行開發 |
各模組設計完即可進行開發,增加系統開發的彈性,交付多次能較快產出 |
開發階段 |
使用者對系統的產出回覆,以利回到規劃階段重新分析 |
依模組開發快速回饋產出回應,強調反覆與漸增的開發方式 |
需求變更 |
需回到規劃階段重新分析再開發 |
可依即時需求改變而反覆調整模組 |
交付週期 |
開發週期較長且過程中使用者參與不足 |
開發週期較短與使用者需有良好的溝通和互動機制 |
設計文件 |
設計和規劃之文件完整 |
不太重視文件而重視成果 |
圖二、敏捷式與瀑布式開發流程差異

其實無論是敏捷式或是瀑布式開發,都有其優缺點與適用範圍,只要選擇專案適用的開發流程即可。若是軟體複雜度低與規格定義明確,專案週期較長,且需求變更幅度不大的系統,可選擇使用瀑布式,較適合大型專案;對於無法釐清或訂定明確需求規格,開發過程中需求會不斷變動,只能在反覆的開發過程中逐漸完整,且在短期間內需要交付的專案可選擇使用敏捷式。
敏捷式開發之實務應用
PDM (Professional Design Management)系統是一套以Web為基礎的專案設計管理系統,針對新廠設計部門的設計進度管控與資料集中管理系統,希望能讓設計人員透過此平台掌握設計進度,並可即時追蹤落後項目,而亦可將所有設計相關資料集中管理,並且透明化,使此平台成為設計部門即時溝通的作業平台。
在初期規劃階段,雖清楚開發之方向與所需達到的成果,但設計部門對細部功能需求及透過系統化管理執行尚未完全掌握,需求隨時有改變的可能,如增加合約文件電子傳簽、2D&5D設計圖面不同版本歸檔與訂單(Purchase Order)進度系統管控等。此外,部分子系統亦被要求能在最短時間上線使用。
在與使用者共同討論並定義系統需求及規格後,依敏捷式開發方法規劃系統架構,先將系統分為各個獨立模組,分為版本管理、簽核流程、進度管控、週日報及發包介面等模組,再將較複雜的功能切割為更小的子模組,如在進度模組內有不同類型的控管,可再細分為圖面進度、發包進度、文件進度等。先定案的模組即可先行開發,過程中需求也面臨持續改變,但事先規畫已保留擴充彈性,可即時的加入新模組而不影響開發進行。(如 圖三)
圖三、PDM 模組開發流程

針對PDM的各項功能討論,將系統分成標準資料庫(Master Database)與專案資料庫(Project Database)兩個部份開發。
Master Database:針對設計資料標準版與設計相關或參考之資料庫的建立,並且提供設計報告之上傳中心,以集中管理各專案階段之相關報告。(如 圖四)
圖四、PDM 首頁-Master Database

Project Database:在設計階段的各專案設計進度的管控,配合專案里程碑,規劃排程,如CAD設計圖、5D FAB、(Package Bidding Status)、合約文件、(Submittal Plan)等各項時程資訊。(如 圖五)
圖五、PDM 專案頁-Project Database

系統主要分為三個階段上線,第一階段為首頁、專案首頁及上傳文件版次管理功能,第二階段是週日報與合約文件及傳簽,第三階段是設計圖面進度及訂單相關進度,其餘子功能也在第三階段後陸續上線。三個階段的開發時程都約為一個半月,而子功能也在一個月內完成上線。在程式編碼過程中必須注意要制定統一格式,以確保程式的可讀性,可擴充性,易維護性,提高程式的運行效率及穩定性。透過測試驗証與使用者問題回饋,對變更做出快速反應,再回到設計階段改善先前既有的規劃設計,並確保重構不會造成各模組間的衝突。每隔一段時間就將完成測試之模組上線使用,分批上線也可以得到使用者更細部的回饋做為系統改善的依據。
若PDM以傳統系統開發方法導入,則在初期需求不明確時便必須花費許多時間釐清才能開始規劃與分析。但在設計和開發階段又會因使用者的需求變動而再回到分析階段重新規劃,在時間上和需求改變上就無法達到要求。而導入敏捷式開發方法,可快速開發符合軟體生命週期之系統建置循環流程,即使功能需求不明確,但經過不斷的循環分析、設計、開發、測試與修正,使得能在開發階段不間斷的反覆回饋和因應各項需求變更修正,並在期限內逐步交付成果。
結論
新工處的系統開發往往在不斷重覆的進行,每一次新的開發都會依據實際操作的經驗回饋與新進的需求來進行修正,逐步的使其完善,而敏捷式軟體開發就非常適合使用在此環境下,快速的反應需求並以較短時間來完成系統開發。朝此一思維前進,將使軟體開發工作變得更為便捷,更為順手。目前我們已導入此一開發模式來發展新建廠工程從專案初期規劃、到設計發包、到施工管理、到最後品質驗收等相關的管理系統,此模式將使在需求不甚明確或不斷改變的情況下亦能進行軟體開發工作,並保留足夠的彈性供未來調整,有效縮短系統開發的流程與時程。相信未來在面對更趨複雜的建廠管理系統,敏捷式軟體開發絕對是我們成功的一項利器。
參考文獻
- Agile Methodology : http://agilemethodology.org/
- 維基百科:http://zh.wikipedia.org/wiki/%E6%95%8F%E6%8D%B7%E8%BB%9F%E9%AB%94%E9%96%8B%E7%99%BC
- 湯金翰,2010,「新一代軟體開發者選擇敏捷式系統發展方法輪之傾向」,碩士論文,國立政治大學資訊管理研究所。
留言(0)