一種穩(wěn)定的倒A型軟件開發(fā)模型

陳詩軍，王慧強，陳 強，林俊宇，向平葉，田雪鋒

(1. 中興通訊股份有限公司 無線預研部，廣東 深圳 518000 2. 哈爾濱工程大學計算機 科學與技術(shù)學院，黑龍江 哈爾濱 150001)

一種穩(wěn)定的倒A型軟件開發(fā)模型

陳詩軍1，王慧強2，陳 強1，林俊宇2，向平葉1，田雪鋒1

(1. 中興通訊股份有限公司 無線預研部，廣東 深圳 518000 2. 哈爾濱工程大學計算機 科學與技術(shù)學院，黑龍江 哈爾濱 150001)

針對傳統(tǒng)的V型軟件研發(fā)過程模型存在的不穩(wěn)定性問題，本文從需求對產(chǎn)品質(zhì)量和研發(fā)的關(guān)鍵作用出發(fā)對其進行改進，提出了以需求為中心的倒A型穩(wěn)定的研發(fā)過程模式，并基于該模式建立研發(fā)需求體系及其關(guān)聯(lián)的過程控制活動；同時進一步提出以可用性理論為依據(jù)建立質(zhì)量屬性需求體系，并分析了質(zhì)量控制活動和策略。最后闡述了新研發(fā)模式的實踐情況，并對其影響和應(yīng)用前景進行了展望。

計算機軟件；研發(fā)過程控制；需求；質(zhì)量屬性；可用性

0 引言

軟件開發(fā)模型是跨越整個軟件生存周期的系統(tǒng)開發(fā)、運行、維護所實施的全部工作和任務(wù)的結(jié)構(gòu)框架，在軟件開發(fā)過程中有著至關(guān)重要的作用。目前存在許多著名的產(chǎn)品開發(fā)模型，如瀑布模型、迭代模型、增量模型等等[1-3]，如表1所示。

而目前在實際項目開發(fā)過程中，應(yīng)用的最為廣泛的還是迭代模型和作為瀑布模型的變種V型模型。迭代模型被認為其是最貼合實際的研發(fā)模型，實際上是一次輸出沒有達到目標要求，或者需要優(yōu)化補充，或者產(chǎn)生故障（從某種意義上看，故障是沒有滿足需求的結(jié)果）。因此迭代模型和瀑布模型從本質(zhì)上來說，是需求成熟度的一種表現(xiàn)形式，迭代次數(shù)越少，需求成熟度越高，而瀑布模型是需求度高度成熟的模型。從一定程度上講，瀑布模型或V型模型是迭代次數(shù)為零的迭代模型，而軟件開發(fā)的理想過程就是符合V型模型。

在研發(fā)過程中，需求具有其他因素無法取代的核心作用。但在現(xiàn)階段軟件研發(fā)過程中，需求卻是最薄弱、最受到忽視的一個環(huán)節(jié)，或者無從做起。大多數(shù)產(chǎn)品是以設(shè)計為中心的研發(fā)模式，或者是以測試為中心的研發(fā)模式，這些模式共同的顯著特點為需要首先完成產(chǎn)品的開發(fā)，然后根據(jù)測試和使用情況進行優(yōu)化和修訂。這些研發(fā)思維導致了較差的產(chǎn)品質(zhì)量、成本和研發(fā)周期。

本文從V型研發(fā)模型的不足出發(fā)，提出以需求為中心的研發(fā)過程模式，建立了倒A型穩(wěn)定的研發(fā)過程模型，提高質(zhì)量過程的可操作性和有效性，為企業(yè)生產(chǎn)出高品質(zhì)的產(chǎn)品和服務(wù)提供重要保障。

表1 現(xiàn)有產(chǎn)品開發(fā)模型分析對比

1 V型模型的不足

Paul Rook在1980年代提出了典型V型研發(fā)模型[5]，并被各種軟件開培訓教科書收錄作為典型案例，如下圖2所示，其由總體設(shè)計、概要設(shè)計、詳細設(shè)計、編碼等組成v型的左半邊；然后單元測試、集成測試、系統(tǒng)測試組成v型的右半邊，每一個測試環(huán)節(jié)和左邊有一定的對應(yīng)關(guān)系。

從2圖中可以清楚地看出這個模型從時間和層次關(guān)系上清楚地描述了研發(fā)過程和測試驗證過程的對應(yīng)關(guān)系。但存在一個重要的缺陷，即無法說明表示設(shè)計過程和測試過程之間的聯(lián)系。在本文介紹的建立以需求為中心的研發(fā)模型中，給出一個相對v型模型更加穩(wěn)定的模型。

圖2 V型開發(fā)模型

2 以需求為中心的倒A型研發(fā)模型

需求在產(chǎn)品研發(fā)中充當著全局引導的重要作用，是產(chǎn)品質(zhì)量之“源”。明確的需求，可以使計劃具有實際意義，是研發(fā)工作有序化的前提，能夠促進版本需求管理，使測試和設(shè)計相互獨立和彼此驗證成為可行。

3.1 以需求為中心的基本研發(fā)模型

如果把“把事情一次做好”作為研發(fā)的理念，則必須有一個明確的目標需求定義，這個明確的需求既是研發(fā)實現(xiàn)的約束，也是測試驗收的標準[6]。基于這一思想，以需求為中心的研發(fā)過程的基本模型如圖3所示。

圖3 以需求為中心的研發(fā)過程的基本模型

在上圖中，可以看到基本模型和以往模型有幾個非常顯著的不同：

1）穩(wěn)定性。在v型模型的基礎(chǔ)上，需求成為連接兩個分支的關(guān)鍵，因此使這個研發(fā)模型具有穩(wěn)定質(zhì)量的結(jié)構(gòu)。

2）需求代替設(shè)計成為整個研發(fā)的中心，需求成為設(shè)計過程和測試過程遵守的共同參照。在具體研發(fā)過程中，還可以把需求說明看成設(shè)計方案和測試用例的檢查單，用來檢查兩個過程的對需求的滿足情況。

3）研發(fā)和測試兩個分支是相互獨立的，這和以往的研發(fā)模型有著本質(zhì)的區(qū)別。在以往的模型中，盡管設(shè)計和測試在時序上是兩個階段，但在邏輯上，測試實際上以設(shè)計的相關(guān)輸出為依據(jù)，如設(shè)計文檔、代碼等等，實際上是以設(shè)計為中心研發(fā)模型。

3.2 倒A型研發(fā)模型

在絕大多數(shù)研發(fā)過程定義的v型研發(fā)模型中，分為系統(tǒng)設(shè)計、概要設(shè)計、模塊設(shè)計、編碼與調(diào)試，以及對應(yīng)的系統(tǒng)測試、集成測試、單元測試等。在目前的較大規(guī)模軟件公司中，這個研發(fā)過程在時序上基本能夠得到保證，但這是一個不穩(wěn)定的模型，在實踐中往往弱化為以設(shè)計為中心或者以測試為中心的模式，在上面的章節(jié)也論述過這些模式存在的諸多問題。

在每一層如果要達到盡量少的迭代而產(chǎn)生的代價，也必須有明確的需求定義。這些不同層次的需求一方面從上向下層層分解，另一方面把同層次的研發(fā)和測試聯(lián)系起來，形成完整的需求體系，使得研發(fā)質(zhì)量控制成為圍繞以需求為中心的穩(wěn)定的倒A型體系結(jié)構(gòu)。如下圖4所示。

系統(tǒng)需求，來源于用戶、運營商、設(shè)備制造商等干系人提出的需求。系統(tǒng)需求是總體設(shè)計和系統(tǒng)測試共同的標準。

子系統(tǒng)需求，來源于系統(tǒng)測試向子系統(tǒng)分解而來的需求，以及總體設(shè)計產(chǎn)生的一部分新的需求。子系統(tǒng)需求是子系統(tǒng)設(shè)計和子系統(tǒng)集成測試標準。

模塊需求，來源于子系統(tǒng)需求分解來的需求，以及子系統(tǒng)設(shè)計新產(chǎn)生的一部分需求。模塊需求是模塊詳細設(shè)計和單元測試的標準。

圖4 倒A型研發(fā)模型

3.3 基于可用性理論的需求質(zhì)量屬性定義

就像產(chǎn)品要完成某些功能一樣，軟件功能（或者某種實體）是軟件質(zhì)量的基礎(chǔ)，只有在確定的功能上談質(zhì)量才有意義。但在目前研發(fā)過程中，人們往往割裂功能和質(zhì)量，這樣的例子在很多研發(fā)項目中非常常見，如產(chǎn)品研發(fā)過分強調(diào)先把功能打通，然后根據(jù)測試結(jié)果進行優(yōu)化。按照這種方法很難使得研發(fā)隊伍秉承一次把產(chǎn)品質(zhì)量做好的思想，人們往往會為這種方法付出巨大的代價。產(chǎn)品的架構(gòu)受制于質(zhì)量屬性，如果前期產(chǎn)品研發(fā)質(zhì)量屬性沒有重點考慮，后期將會涉及到架構(gòu)級別的改動，這對產(chǎn)品來說，意味著大大提高成本和延長產(chǎn)品推出周期。

下面主要介紹如何在需求環(huán)節(jié)就對產(chǎn)品的質(zhì)量屬性進行分析和定義，約束產(chǎn)品開發(fā)，包括研發(fā)和測試，把產(chǎn)品的質(zhì)量一次做好。

3.3.1 質(zhì)量需求定義

在新的研發(fā)模型中，我們引入了質(zhì)量需求的概念。這種考慮是基于“把事情一次做好”研發(fā)理念的延續(xù)。如果要達到有效的全程產(chǎn)品質(zhì)量控制，必須從最早的階段開始考慮質(zhì)量，也就是必須從需求階段就需要引入質(zhì)量需求和控制。因此在需求說明中，必須要對產(chǎn)品質(zhì)量的要求進行定義，這種質(zhì)量方面的要求隨著需求的分解和落實，一起分解到下一層進行實現(xiàn)。產(chǎn)品質(zhì)量方面的要求實際上就是產(chǎn)品的質(zhì)量屬性。圖5是質(zhì)量需求模型的說明。

上述模型具有兩個明顯的特點：

1 功能（包括實體）和質(zhì)量屬性是相互關(guān)聯(lián)在一起的；

2 在需求分解的時候，質(zhì)量屬性也和功能一樣向下層進行分解。

圖5 質(zhì)量需求模型

3.3.2 基于可用性理論的需求質(zhì)量屬性定義方法

需求的質(zhì)量屬性定義有很多種，在實踐中可以根據(jù)項目的實際情況采取合適的方式，只要滿足上節(jié)基本模型描述的原理。在實際項目中往往采用可用性理論作為質(zhì)量屬性定義方式。

可用性定義反映了在完成用戶功能需求同時，還要關(guān)注需求的滿足程度的需要[7]。現(xiàn)在重新審視研發(fā)中的需求，實現(xiàn)任何需求都需要考量需求的滿足程度才算完整，這種滿足程度實際上就是需求的質(zhì)量屬性。需求質(zhì)量屬性從可用性三個方面為出發(fā)點進行分析：

1 有效性。任何需求本質(zhì)上都有一個程度的概念，不同的需求的衡量標準可能不同；

2 效率。任何需求本質(zhì)上都有一個效率的概念，反映在資源方面的代價；

3 滿意度。其主要由兩個方面來考量：

（1）滿足了需求有效性和效率方面的要求，能夠有效提高用戶滿意度，因此需要在有效性和效率方面盡可能地深入、全面地挖掘定義用戶提出的或者潛在的需求質(zhì)量屬性；

（2）對有效性和效率之外的無效情況，也需要采取有效的、合適的措施，提高用戶滿意度，因此需要定義無效性處理策略。另外用戶易用性方面，特別是操作、界面方面，也直接影響用戶的滿意度，也需要明確定義。

在研發(fā)的具體實踐中，對需求質(zhì)量屬性定義采用了上述可用性概念，結(jié)合實踐對可用性的三個方面作了進一步的定義和擴展，使得在項目中具有更高的可操作性，如表2所示：

表2 需求質(zhì)量的可用性定義

3.4 研發(fā)過程中基本質(zhì)量控制活動

以需求為中心的研發(fā)過程基本模型中定義了需求、設(shè)計和測試為研發(fā)的三個基本過程，并且需求是整個研發(fā)的中心。從基本模型可以確定新的研發(fā)模式的一些基本質(zhì)量控制活動，下圖6是實際的以需求為中心研發(fā)過程中的質(zhì)量活動。

上述過程中特點：

圖6 以需求為中心研發(fā)過程中的質(zhì)量活動

1 需求說明：主要由項目人員安排組織進行需求先期分析，給出需求說明，具體實施可以以研發(fā)人員或者測試人員為主實施，研發(fā)和測試人員都參加評審。需求定義評審之后對需求的影響、復雜度等基本有了較準確地分析，這時候可以緊接著進行工作量估算、計劃安排等。

2 設(shè)計方案：主要由設(shè)計人員完成，測試人員參加評審。

3 測試用例：主要由測試人員完成，研發(fā)人員參加評審。

4 測試報告：主要由測試人員完成，研發(fā)人員參加評審。

3.5 研發(fā)后期的質(zhì)量控制和活動

產(chǎn)品研發(fā)后期，需求逐漸收斂、研發(fā)團隊重點工作轉(zhuǎn)為解決故障和對系統(tǒng)的優(yōu)化兩個方面。從產(chǎn)品來說， 無論是故障還是優(yōu)化都帶來質(zhì)量成本，都是研發(fā)管理盡量減少和避免的。從另一方面，故障和優(yōu)化又可以看成對產(chǎn)品新產(chǎn)生的外部需求。

因此后期的故障和優(yōu)化從過程角度可以按照需求的研發(fā)過程進行，即包括故障（優(yōu)化）解決方案、設(shè)計方案、測試用例等基本過程，并進行相應(yīng)的評審等質(zhì)量活動；同時故障和優(yōu)化給產(chǎn)品帶來質(zhì)量成本，必須形成反向的閉環(huán)控制措施，用來進行過程數(shù)據(jù)測量、過程改進等。

圖7 研發(fā)后期的質(zhì)量控制

對故障和優(yōu)化的反向分析包括以下幾個方面：

· 問題在研發(fā)過程的哪個階段引入的

· 問題引入對應(yīng)哪個需求

· 解決問題花費的人力和時間是多少

4 以需求為中心研發(fā)過程實例

下面以一個比較典型的系統(tǒng)產(chǎn)品項目為例，說明一個具體項目中采用以需求為中心研發(fā)過程的情況。某大型3G CDMA基站系統(tǒng)項目，具有兩組相同的項目組，分別采用V型開發(fā)模式和以需求為中心的研發(fā)模式進行開發(fā)對比。下面將以該系統(tǒng)3年的開發(fā)數(shù)據(jù)為例，從開發(fā)周期和版本變更通過率兩個指標進行對比分析。

圖8 開發(fā)周期對比

從圖8可以看出，采用以需求為中心研發(fā)模式的團隊總體研發(fā)時間明顯小于采用V型開發(fā)模式的團隊。采用V型開發(fā)模式的研發(fā)人員的研發(fā)時間占據(jù)了90%，其中幾乎大部分時間都在軟件調(diào)試或者問題攻關(guān)，且絕大多數(shù)的版本變更不受控制，沒有文檔，也沒有經(jīng)過評審，僅剩余10%的時間用于學習擴充團隊自身。而采用以需求為中心的研發(fā)模式的研發(fā)人員能夠使用60%的時間進行研發(fā)，40%的時間進行學習與討論，節(jié)省了大量的時間與人力成本，為學習型團隊打下基礎(chǔ)。

圖9 版本變更通過率與一次變更通過率對比

從圖9可以看出，采用以需求為中心研發(fā)模式團隊在時間上有著充分的質(zhì)量保證的時間，使得產(chǎn)品能夠有能力作分步實施，階段提交使用，具有清晰的產(chǎn)品規(guī)劃曲線，版本變更通過率高達100%，高于V型開發(fā)模型，其中一次變更通過率為75%遠高于V型開發(fā)模型。通過對需求進行嚴格評審保證了需求的完備性和質(zhì)量屬性，從源頭上明確了研發(fā)和測試的目標，大大減少了后期產(chǎn)生故障和優(yōu)化任務(wù)的可能性，尤其是避免了原理性、系統(tǒng)級別的研發(fā)缺陷。另外明確的需求定義也為項目估算、計劃等提供了可靠的基礎(chǔ)，非常顯著地提高了項目管理的科學性和有效性。

以需求為中心的研發(fā)過程明確了需求作為研發(fā)中心的地位，同時也建立了一整套過程控制規(guī)范，促進了設(shè)計過程和測試過程，從根本上解決了以設(shè)計為中心的一系列問題。

以需求為中心的研發(fā)過程中，在有效的前向控制的基礎(chǔ)上，也可以有效地進行反向跟蹤和改進。在具體實踐中，對產(chǎn)品研發(fā)過程中產(chǎn)生的故障進行引入的需求以及研發(fā)環(huán)節(jié)進行分析。通過反向分析可以不斷進行過程改進，完善需求規(guī)范、設(shè)計規(guī)范以及測試規(guī)范，形成一個閉環(huán)的研發(fā)質(zhì)量控制系統(tǒng)。隨著實踐的深入、不斷的積累，逐漸形成一個高質(zhì)量的研發(fā)過程規(guī)范、高水平的研發(fā)隊伍。

4 結(jié)束語

本文討論了以需求為中心的研發(fā)過程模式，提出了一種倒A型穩(wěn)定研發(fā)過程模型，并創(chuàng)新地提出了以可用性理論為基礎(chǔ)的質(zhì)量屬性定義方法以及建立質(zhì)量屬性需求體系。傳統(tǒng)V型研發(fā)模式只是在開始的時候?qū)ο到y(tǒng)指標等做簡單的描述，這種研發(fā)模式需求無法滲入到研發(fā)過程的每個環(huán)節(jié)，因此無法對整個研發(fā)過程產(chǎn)生約束作用，通常會表現(xiàn)出自身的不穩(wěn)定性。新型研發(fā)模式通過需求定義、分解、驗證約束，深入到每個研發(fā)環(huán)節(jié)，對整個研發(fā)組織、研發(fā)過程是一個系統(tǒng)性的改革，基于這種新型研發(fā)模式的穩(wěn)定特征實現(xiàn)快速收斂輸出產(chǎn)品，是過程管理理論方面重要的理論創(chuàng)新。最終，結(jié)合實踐過程中過程文檔側(cè)面對傳統(tǒng)V型研發(fā)模式和倒A型研發(fā)模式的兩種研發(fā)過程作了一個形象的比較，則有完善需求文檔的系統(tǒng)可以令人有信心地作出一個滿意的產(chǎn)品，相反只有設(shè)計文檔的系統(tǒng)則是一個很大未知數(shù)。

[1] Basem S. El-Haik, Adnan Shaout, Software design for six sigma: A roadmap for excellence, Weily Press, 2010.

[2] Evi Septiana Pane, Riyanarto Sarno. Capability Maturity Model Integration (CMMI) for Optimizing Object-Oriented Analysis and Design (OOAD), Procedia Computer Science, 2015(72): 40-48.

[3] Zhen He, Thong Ngee Goh. Enhancing the Future Impact of Six Sigma Management. Quality Technology & Quantitative Management, 2015, 12(1): 83-92.

[4] 張友生, 李雄. 軟件開發(fā)模型研究綜述, 計算機工程與應(yīng)用, 2006, 03: 109-115.

[5] Paul Clements . Software Architecture in Practice.北京：清華大學出版社, 2003.

[6] Paul Clements. Evaluating Software Architectures.北京：清華大學出版社, 2003

[7] Kraig Finstad. The Usability Metric for User Experience. Interacting with Computers, 2010, 22(5): 323-327.

[8] Junji Zhi, Vahid Garousi-Yusifo?lu, Bo Sun. Cost, benefits and quality of software development documentation: A systematic mapping. Journal of Systems and Software, 2015, 99(1): 175-198.

Inverted A-Model for Stable Software Development

CHEN Shi-jun1, WANG Hui-qiang2, CHEN Qiang1, LIN Jun-yu2, XIANG Ye-ping1, TIAN Xue-feng1
(1. Wireless pre-research department , ZTE Corporation, Shenzhen 518000, China 2. College of Computer Science and Technology, Harbin Engineering University, Harbin 150001, China)

For the instability problem of the traditional V-model for software development, an improved A-model is proposed in this paper based on the key role of requirements for the quality of products and development. It is a stable development mode in a requirement-centered manner. On this basis, the requirement architecture and corresponding process control for the A-model is studied. Meanwhile, the theory of availability is treated as a foundation to build quality attribute requirement architecture, and the approaches and strategies of quality control is outlined too. Finally, the practices are demonstrated in the new development mode, and the application prospect of our model is forecasted.

Computer software; Development process control; Requirement; Quality attribute; Availability

TP393

: A

10.3969/j.issn.1003-6970.2016.12.002

國家科技重大專項(No.2011ZX03003-003-01)；國家自然科學基金項目(No.61370212)；中興產(chǎn)學研合作項目(No.2015ZTE01-01-12)

陳詩軍(1972-)，男，碩士，高級工程師，研究領(lǐng)域為無線定位、MIMO、信道仿真、通信產(chǎn)品開發(fā)。

王慧強(1960-)，男，博士，教授，研究領(lǐng)域為網(wǎng)絡(luò)安全、未來網(wǎng)絡(luò)、軟件可信性、無線定位。

本文著錄格式：陳詩軍，王慧強，陳強，等. 一種穩(wěn)定的倒A型軟件開發(fā)模型一種穩(wěn)定的倒A型軟件開發(fā)模型[J].軟件，2016，37（12）：07-12