基于快速應用開發的功能點增量迭代模型

夏驕雄， 劉 政， 劉緒彬， 宋 陽， 袁佳錦

（1.上海市教育委員會 信息中心，上海 200003；2.百度（中國）有限公司，上海 201203；3.上海大學 計算機工程與科學學院，上海 200444；4.上海理工大學 光電信息與計算機工程學院，上海 200093）

當前，軟件項目的需求變化越來越快，功能越來越多，架構越來越復雜，軟件開發模型的演變和發展也越來越紛繁復雜［1－4］.傳統的瀑布模型、螺旋模型、快速原型等早已不能適應越來越復雜和不斷變化的需求及市場環境［5－6］.因此，計算機領域的專家學者、IT 領域從業人員都進行了大量工作，提出了一些讓軟件開發團隊具有快速交付、即時響應的價值觀和原則.至20世紀90年代末，極限編程、自適應軟件開發、動態系統開發等一系列敏捷軟件開發（agile software development）方法相繼被提出［7－8］.

敏捷軟件開發是一種以人為核心、迭代、循序漸進的開發軟件方法，目標是提高開發效率和響應能力.但是在具體應用階段，敏捷開發對于開發人員而言，由于用戶需求的不確定性，往往就演變成邊做邊改模式，違背了執行敏捷開發的基本原則［9－10］.因此，本文針對這一情況，根據多種軟件開發模型，結合客觀實際，提出了一套具體實施敏捷開發的步驟模型，即基于快速應用開發的功能點增量迭代模型（incremental story iteration model on rapid application development，ISI－RAD）.

1 常用軟件開發模型

軟件開發模型是指軟件開發全部過程、活動和任務的結構框架，它明確規定了要完成的主要活動和任務［1］.與本文提出的基于快速應用開發的功能點增量迭代模型ISI－RAD 有關的軟件開發模型或方法有：邊做邊改模型［11］、快速應用開發RAD 模型［12－13］、增量模型［14］和敏捷軟件開發方法［7－10，15］.

1.1 邊做邊改模型

邊做邊改模型是一種類似于作坊式的軟件開發方法，既沒有規格說明書，也沒有設計文檔.開發過程中，開發人員拿到項目立即根據需求編寫程序，調試通過后生成軟件的第一個版本.在提供給用戶使用后，如果程序出現錯誤，或者用戶提出新的要求，開發人員重新修改代碼，直到用戶滿意為止.因此，開發人員需要根據用戶不斷變化的需求進行一次又一次的修改.對于需求簡單、規模較小的項目，邊做邊改模型非常合適、非常靈活、需求響應快.

在需求復雜、結構龐大的項目中，由于缺少規劃和設計環節，忽略需求環節，軟件結構隨著修改次數的不斷增加而變得復雜且混亂，給軟件開發帶來較大風險.且由于沒有考慮測試和程序的可維護性，沒有任何開發設計文檔，軟件的維護十分困難.

1.2 RAD 模型

RAD模型是一種增量型的軟件開發過程模型，具有極短的開發周期.RAD 模型是傳統生命周期模型的一類“高速”變種，通過大量使用可復用的構件，采用基于構件的建造方法獲得快速開發的效果.在用戶需求能夠被較好理解、軟件邊界固定和明確的情況下，RAD 模型能夠在極短的時間內創造出功能完善的系統.其基本流程包括業務建模、數據建模、過程建模、應用生成、測試及反復五大部分.

對于大型應用系統的開發而言，RAD 模型需要足夠的人力資源支撐，開發人員和用戶必須在短時間內做好整個系統的需求分析，并確保交互溝通的實時性和暢通性，否則將嚴重影響RAD 模型的使用效率.對于不能合理劃分模塊化的應用系統，或者性能需求較高且構件接口需要調整的應用系統，RAD 模型并不具備很強的適應性.RAD 模型不適合于大范圍使用沒有應用經驗的技術，否則任何一個小問題都會影響整個開發過程的進度.

1.3 增量模型

增量模型是融合了瀑布模型的基本成分和快速原型模型的迭代特征，采用時間進展的交錯線性序列，使每一個線性序列都能產生軟件產品一個可發布的“增量”.通常情況下，使用增量模型產生的第一個增量就是核心產品，實現了軟件最基本的需求.增量模型引進了增量包的概念，只需要某個需求增量包產生，就可以進行相應的開發.用戶對每一個增量的使用和評估都將作為下一個增量發布的新特征和功能，這個過程在每一個增量發布后不斷重復，直到最終產生完善的產品.

增量模型的缺陷在于：一是要求軟件本身具備開放式的體系結構，以便加入的增量不破壞已經構造完整的系統整體；二是增量模型的靈活性能夠適應開發過程中需求的變化，但是仍存在退化為邊做邊改模型的可能性，使軟件開發過程的控制失去整體性；三是如果增量包之間存在相交的情況，而且未加以正確處理，將導致系統分析的重新實施.

1.4 敏捷軟件開發方法

敏捷軟件開發又稱敏捷開發，是20世紀90年代開始逐漸引起廣泛關注的新型軟件開發方法.相對于“非敏捷”而言，敏捷開發更強調軟件開發中人的作用，包括：開發人員團隊與業務專家之間的緊密協作、面對面的溝通、頻繁交付新的軟件版本、緊湊而自我組織型的團隊、能夠較好適應需求變化的代碼編寫和團隊組織方法等.

正是由于敏捷開發過于強調人的作用，極易導致開發過程與工具的使用相對減少、完整開發過程的文檔留存相對薄弱、針對性的人與人溝通效率趨于瓶頸、軟件維護的后期成本趨于擴大等問題，從而讓敏捷開發模型失去約束，喪失活力，蛻化為邊做邊改模型.

2 ISI－RAD模型的基本結構

由于常用的軟件開發模型或多或少都會存在一些問題，在實際應用中往往需要結合幾個模型一起來完成軟件的開發工作.所以，本文借鑒以前的研究成果［16］，提出了一套具體實施敏捷開發的步驟模型，即ISI－RAD模型.

ISI－RAD 模型是利用RAD 模型、增量模型及敏捷開發方法的綜合優勢，結合其它軟件開發模型的優點，摒棄缺點，以實際經驗和實踐總結出來的一套改良型的敏捷開發模型，其基本結構如圖1所示.ISI－RAD模型主要由RAD 部分、增量部分和功能點（story）迭代部分組成.

2.1 RAD 部分

ISI－RAD 模型選取RAD 模型的業務建模、數據建模、過程建模等流程對軟件系統進行切分，把其切分成若干個獨立的模塊［17］.這樣，軟件系統的基本結構趨于簡單化，方便管理，開發人員團隊可以分組進行任務的完成，并可以自行安排任務的完成.

圖1 ISI－RAD模型基本結構Fig.1 Basic structure of ISI－RAD model

2.2 增量部分

ISI－RAD模型通過使用增量模型，生成一個增量周期序列，其中第一個增量定義為軟件系統的核心功能，實現最基本的功能需求.然后，把各個模塊的第一個增量提取出來進行需求分析，分析后進行story拆分并進行原型設計.最后，用戶對當前增量的使用意見都作為下一個增量發布的新特征和功能.

增量部分的過程是在每一個增量發布后不斷重復，直到產生最終的完善產品.過程中對story拆分并進行原型設計的目的在于把重要的story優先開發出來，利用成熟的增量模型進行風險控制，加大對ISI－RAD 模型實施的依據，使得軟件系統的開發是宏觀有序的，而不是隨意的［18］.

2.3 story迭代部分

ISI－RAD模型通過使用敏捷軟件開發方法，把拆分好的story存放在項目進度池和缺陷（bug）狀態池中，如圖2所示.假設有功能點story 1～15進行迭代，從而取得所需要的迭代結果，交付用戶不同可用的版本［15］.

圖2 ISI－RAD模型中的項目進度池和bug狀態池Fig.2 Project schedule pool and the bug state pool of ISI－RAD model

項目進度池是存放story的地方，包含待評審、待開發、開發中、待測試、測試中、待驗收、驗收中、完成共8個狀態.

Bug狀態池是存放story相關bug的地方，包含當前、已解決、不存在（誤報或者無法復現）共3個狀態.

3 ISI－RAD模型中story迭代過程

ISI－RAD模型中story迭代過程主要由項目進度池迭代過程和bug狀態池迭代過程組成.

3.1 項目進度池迭代過程

項目進度池的功能是裝載軟件系統開發的整個過程，負責跟蹤軟件系統開發的進度情況，便于形成軟件系統開發的進度報告，其迭代過程如圖3所示.

圖3 項目進度池迭代過程Fig.3 Iterative procedure of the project schedule pool

項目進度池迭代步驟如下：

步驟1 把拆分好的story放入項目進度池，設置狀態為待評審狀態.

放入的方式有兩種：

a.先對整個軟件系統開發進行需求分析設計，然后再拆分story，對story進行評級，根據級別把優先級高的拿到第1期去做.

b.只針對優先級高的story 進行需求分析設計，然后拆分，直接納入第1期去做.

方式a的優點在于整個軟件系統開發過程有統一規劃，各節點的拼裝都是在規劃藍圖下完成的；其缺點是類似于瀑布模型，需要等到整個需求分析完成后才能進行下一步，雖然拆分后可以實施敏捷開發，但是在這一步造成的“非敏捷”狀態，將引發長期的阻塞.

方式b的優點是相對于方式a更靈活，只需要大致知道軟件系統的結構規劃即可，針對較高優先級的需求，優先分析設計及拆分，盡早投入開發；其缺點是以后模塊集成時，可能存在設計缺陷，不能滿足后續的需求，需要更改第1期的代碼.

步驟2 需求人員跟開發人員、測試人員一起，對拆分好的story進行評審.

評審內容包括業務上是否合理、技術上是否可行，story是否過大，對story的測試是否確認等.這一步幾乎是所有角色都需要參與的，把第1 期的story給相關人員進行評審，評審合格后納入待開發狀態，不合格的需要退回上一步修改.

步驟3 對處于待開發狀態的story，參照需求文檔進行詳細設計.

詳細設計的關鍵在于了解相應story在整個軟件系統開發中的作用.詳細設計完成以后，指定相應的開發責任人，由該責任人對該story 負責，參照story優先級自行決定何時將story的狀態更改為開發中狀態.假如由于需求不合理，評審的時候沒有充分考慮，導致后期story詳細設計時無法實現的問題，則與相關責任人溝通.若確實需要進行重新需求分析，則將該story的狀態更改為待評審狀態，使之重新評審.

步驟4 對處于開發中狀態的story，測試人員給出針對該story的測試用例.測試用例的提出，有助于開發人員在開發完成后進行自測，提高代碼質量，減少溝通成本.當開發人員自測通過后，將該story的狀態更改為待測試狀態，若不通過則繼續開發.

步驟5 測試人員搭建測試環境.

測試人員給出針對該story測試用例之后，需要搭建相應的測試環境，然后參照story的優先級，將該story的狀態更改為測試中狀態.

步驟6 測試人員進行測試實施.

測試人員按照該story的測試用例，在相應的測試環境對該story 進行測試.測試通過后將該story加入整個軟件系統，并進行集成測試.集成測試通過后，將該story的狀態更改為待驗收狀態；若測試未通過，則生成1個bug，并給予相應的“高、中、低”3個狀態.

Bug若標識為“高”狀態，則需要中斷當前story的開發，即刻修復該bug；若標識為“中”狀態，則需要等待當前story開發完成后，進入待測試狀態，再修復該bug；若標識為“低”狀態，則按照開發人員自己的進度安排，自行決定何時進行修復，但必須在軟件系統交付之前給予解決.

步驟7 需求人員確定驗收的具體安排.

需求人員根據任務安排，并參照story的優先級，確定驗收的先后順序，同時將相應story的狀態更改為驗收中狀態.

步驟8 需求人員和用戶共同實施驗收.

需求人員和用戶按照需求進行驗收.驗收通過后，將該story的狀態更改為完成狀態；若驗收不通過，通知開發人員和測試人員召開站會（dispatch meeting，指以站立方式召開的、約耗時10～15min的會議形式），討論不通過的理由［7］.如果確實是需求不完善或者變更造成的不通過，則必須進行story重新審核，再走一次流程即可.

3.2 Bug狀態池迭代過程

Bug狀態池用于裝載軟件系統開發過程中代碼bug的反饋，便于后期的質量評估.

Bug狀態池的迭代過程如圖4所示，其過程相對容易，只是記錄bug的當前狀態，需要關聯項目進度池里相應的story.如果開發人員提交測試后，測試人員發現存在bug，那么只需要將bug 放入bug狀態池中，開發人員則根據優先級，決定修復的先后次序.

圖4 bug狀態池迭代過程Fig.4 Iterative procedure of the bug state pool

4 ISI－RAD模型的優勢

由于ISI－RAD模型綜合了常用軟件開發模型的長處來完成軟件的開發工作，因此ISI－RAD模型的優勢就集中體現在工作精細化和周期快捷化等領域.

例如，在開發某公司運營系統的業績稽核功能時，根據用戶的要求，項目需求分別為訂單導入導出、與OA 系統交互獲取人員信息、訂單流程預覽、銷售報表查詢等，開發周期為2周.表1顯示分別以RAD 模型、增量模型、敏捷開發方法以及ISI－RAD模型為基礎成立4個開發小組，每個小組分配3人，完成該業績稽核功能的基本情況.

在表1的對比案例中，最先發布的是增量模型小組和ISI－RAD模型小組，但增量模型小組完成的并不是一個完整的模塊，而是一個系統的初級樣本.敏捷開發方法小組和ISI－RAD 模型小組可以持續發布，每天系統都會有變化.綜合來看，ISI－RAD 模型的優勢較為明顯，既包含增量模型的優先發布，又包含敏捷開發方法的持續集成.

RAD 模型的分領域開發能夠確保開發人員之間的相互不干擾.相對而言，敏捷開發方法如果開發人員過多，詳細設計將會非常零散，必須集結所有的人在一起才能完成，一旦有一個未確定，后期可能會引起蝴蝶效應，導致一系列story的修改.ISI－RAD模型由于其結合了RAD 模型的優勢，從而規避了敏捷開發方法的這個缺點.

ISI－RAD 模型繼承了敏捷開發的優勢，對軟件系統開發進度的掌控非常精細.相對于以往只能憑人力評估系統開發的大致進度而言，ISI－RAD 模型能夠進行超細粒度的story掌控，并提供有力的數據支撐和項目風險監控，監控報表如圖5所示.ISIRAD 模型中，所有story的狀態都可以明確標識，方便工作任務的分配，因此在開發過程中即使人員有所變動，也只可能影響開發過程中的1個story，而不會對開發的整個過程有太多影響.

表1 對比案例Tab.1 Comparative case

同時，ISI－RAD模型繼承了RAD 模型、增量模型、敏捷開發方法的優勢，對比如圖6 所示（見下頁）.它擯棄了原有RAD 模型需要足夠人力資源和要求用戶實現承諾的缺點，而保留了RAD 模型在極短時間內創造出“全功能系統”的優勢；它擯棄了原有增量模型容易退化為邊做邊改模型的缺點，而保留了增量模型可以快速交付的優勢；它擯棄了原有敏捷開發方法無規劃性的缺點，而保留了敏捷開發方法中項目進度及風險控制精細化的優勢［19］.

圖5 ISI－RAD模型中的項目風險監控報表Fig.5 Project risk monitor sheet of ISI－RAD model

圖6 ISI－RAD模型開發周期粒度對照表Fig.6 Check list about development cycle size of ISI－RAD model

5 結束語

敏捷開發以快速反映及強調人員溝通為主要思想，但如果沒有好的管理策略，類似的開發方法不可能起到好的作用.基于快速應用開發的ISI－RAD 模型的提出，是解決這一問題的一種新思路，并經過實踐檢驗，表現出十分強壯的生存力.

［1］Roger S P.Software engineering：a practitioner’s approach［M］.New York：McGraw－Hill，2010.

［2］Jorge A，Steve E.Anchoring and adjustment in software estimation ［C］∥Proceedings of the European Software Engineering Conference on the Foundations of Software Engineering.Lisbon：ACM Press，2005：5－9.

［3］Václav T R.Software engineering：the current practice［M］.Boca Raton：CRC Press，2012.

［4］盛鋼，曹渠江.軟件開發統一過程應用研究［J］.上海理工大學學報，2003，25（1）：94－98.

［5］Roberto Z，Jorge L N A.Project management model for a physically distributed software development environment［C］∥Proceedings of the 36th Hawaii International Conference on System Sciences.Washington：IEEE Computer Society，2003：294－301.

［6］Pierre B，Robert D，Alain A，et al.Fundamental principles of software engineering——ajourney［J］.The Journal of Systems and Software，2002，62（1）：59－70.

［7］Tsun C，Dac－Buu C.A survey study of critical success factors in agile software projects［J］.The Journal of Systems and Software，2008，81（6）：961－971.

［8］Tore D，Torgeir D.Empirical studies of agile software development：a systematic review［J］.Information and Software Technology，2008，50（9／10）：833－859.

［9］Jean－Guy S，Rajesh V.Agile practices in software development－experiences from student projects［C］∥Proceedings of the 2006 Australian Software Engineering Conference.Sydney：IEEE Computer Society，2006：401－410.

［10］Frauke P.Requirements engineering in agile software development ［D ］. Germany： Fachhochschule Mannheim Diploma Thesis，2003.

［11］Sudarsan R，Steven J F，Ram D S，et al.A product information modeling framework for product lifecycle management［J］.Computer－Aided Design，2005，37（13）：1399－1411.

［12］Toni S，Tomislav D.Rapid application development using software factories［DB／OL］.［2013－09－30］.http： ∥ arxiv.org／ftp／arxiv／papers／1201／1201.0853.pdf.

［13］Ken S.Agile project management with scrum［M］.Redmond：Microsoft Press，2004.

［14］Alistair C.Using both incremental and iterative development［DB／OL］.［2013－09－30］.http：∥alistair.cockburn.us／Using＋both＋incremental＋and＋iterative＋development.

［15］Outi S，Pekka A.Agile methods in european embedded software development organisations：a survey on the actual use and usefulness of extreme programming and scrum［J］.IET Software，2008，2（1）：58－64.

［16］施佳，夏驕雄，張武.FSL－SP的研究［J］.計算機工程，2007，33（8）：182－184.

［17］Richard M S，Robert M N.Seven plus or minus two：a commentary on capacity limitations［J］.Psychological Review，1994，101（2）：357－361.

［18］Cleidson R B S，David R，Li－Te C，et al.Sometimes you need to see through walls—a field study of application programming interfaces［C］∥Proceedings of the 2004 ACM Conference on Computer Supported Cooperative Work.New York：ACM Press，2004：63－71.

［19］Zheng L，Shardrom J，Gang W，et al.A hybrid model based on agile development［C］∥Proceedings of the 2013 3rd International Conference on Electric and Electronics.Hong Kong：Atlantis Press，2013：149－153.

［20］Alessandro R，Andrea S.Concurrent object－oriented programming with agents［C］∥Proceedings of the 2013 Companion Publication for Conference on Systems，Programming，Languages and Applications：Software for Humanity.New York：ACM Press，2013：89－90.