一種基于GJB5000A二級軟件生命周期模型的本地化實施

孫秀芳 姜 凱

1(武漢軟件工程職業(yè)學院計算機學院 湖北 武漢 430205) 2(武漢中原電子集團有限公司研發(fā)中心 湖北 武漢 430205)

0 引 言

經(jīng)過長時間的發(fā)展,我國武器裝備從單純依靠硬件發(fā)揮戰(zhàn)斗力逐漸演變?yōu)檐浻布Y(jié)合共同決定著武器裝備的綜合性能,特別是隨著嵌入式軟件在武器裝備中廣泛而深入的應用,軟件也越來越起著神經(jīng)中樞的作用。在這種環(huán)境下,軟件運行一旦失效,就可能導致整個武器裝備失靈,造成嚴重后果。

我國為規(guī)范從事軍用軟件研制開發(fā)單位的軟件研制開發(fā)流程,原總裝備部電子信息基礎部于2008年3月推出了GJB5000A-2008《軍用軟件研制能力成熟度模型》,在該標準中給出了軍用軟件研制能力成熟度五級模型和相應軟件過程要求[1]。2013年,原總裝備部又發(fā)布了GJB8000-2013《軍用軟件研制能力等級要求》,其中規(guī)定承擔軍用軟件研制任務的單位應達到相應軍用軟件研制能力的等級要求[2]。截至2018年9月通過GJB5000A二級認證的軍用軟件研制單位135家,通過GJB5000A三級認證的軍用軟件研制單位67家[3],目前越來越多的單位在軟件開發(fā)管理活動中更加重視貫徹實施GJB5000A標準工作。

其中,GJB5000A二級為已管理級,其本地化實施后能確保其過程按照既定程序文件進行策劃并得到執(zhí)行,其開發(fā)過程遵循選定的軟件生命周期模型,從而最大限度保證軟件開發(fā)過程和軟件開發(fā)質(zhì)量。

隨著軍改的深入開展,市場化的競標項目越來越多,這些競標項目多為軟硬件相結(jié)合、需求穩(wěn)定、軟件研制周期短、功能實現(xiàn)程度高的新研產(chǎn)品。在此背景下,按照本單位軟件工程化體系中關于生命周期模型選型規(guī)定,由于增量模型和原型模型不滿足選型要求(它們適合需求不太明確的項目),一般會選擇典型的瀑布模型進行軟件工程化管理和實施。但是這些新研競標項目的研制周期比較短、研制任務重,軟件開發(fā)過程中質(zhì)量的控制就會面臨著時間和人力成本的雙重壓力,這樣依照典型的瀑布模型控制新研競標項目就會顯得力不從心。本文就針對選擇什么樣的生命周期模型才能更加適合新研競標型項目的軟件工程化實施這個問題進行探討,并將工作開展中的工程實踐和體會總結(jié)出來,提出一種新的較適合新研競標項目的軟件生命周期模型并進行了本地化實施,以滿足新研競標項目開發(fā)過程的這種實踐,希望能夠引起更多軟件工程化管理人員,就新研競標型項目如何更好地進行過程控制展開廣泛深入的討論。

1 GJB5000A二級軟件生命周期模型的適應性

GJB5000A標準對軟件研制能力成熟度等級進行合理劃分[4],總共包含成熟度等級5個,過程域22個,專用目標48個、專用實踐165個,共用目標2個、共用實踐12個。當前,從事相關軟件開發(fā)的單位大多按照原總裝備部規(guī)定的承擔相關軟件研制任務的單位,應達到GJB5000A標準中軟件研制能力相應等級的要求進行本地化實施,取得了很好的效果[5-6]。

按照GJB5000A對承擔軍用軟件研制能力成熟度等級要求,從事軍用軟件開發(fā)的單位在從事相關軟件項目開發(fā)必須達到二級(已管理級)以上的軟件研制能力成熟度要求。GJB5000A二級(已管理級)中共包含7個過程域19個目標。其中,項目策劃過程域是對軟件研制整個過程進行詳細策劃,從而保證項目有計劃的穩(wěn)步推進,是GJB5000A對軟件開發(fā)的一個重要要求,也是項目按期開展的重要保障。

選擇軟件生命周期模型是GJB5000A二級項目策劃過程域中第一個專用目標(建立估計值)中第三個專用實踐(定義項目生存周期)輸出的典型工作產(chǎn)品,是實施GJB5000A二級的必經(jīng)步驟,其決定著整個軟件開發(fā)的過程、活動、時間順序、軟件輸入輸出工作產(chǎn)品以及軟件驗收交付的標準。可以這么說,軟件生命周期模型的定義決定了項目策劃的質(zhì)量,項目策劃的好壞直接決定了項目是否能夠正常開展及按時交付。

軟件生命周期模型都有其適應范圍,選擇合適的軟件生命周期模型是整個項目按期有條理往前推進的保證,是項目策劃的關鍵。典型的軟件生命周期模型如瀑布模型、增量模型和原型模型雖然能解決部分軟件項目策劃中的軟件生命周期選型問題[7],也能指導實際項目的開發(fā)過程活動,但這些模型大都只能適應部分狀態(tài)背景下的軟件開發(fā)管理活動,在當前新研競標型項目開發(fā)管理過程中,時間要求往往比較緊[8],任務量又繁重,人力資源又緊張,在這種情況下按照典型的軟件生命周期模型進行項目策劃,由于新研競標項目的需求明確且穩(wěn)定,根據(jù)軟件工程化體系文件要求會選擇典型的瀑布模型進行軟件開發(fā)過程和質(zhì)量的控制,但是典型的瀑布模型階段劃分多、要求順序執(zhí)行,不能跳過階段,每個階段輸出的產(chǎn)品必須完成評審后才能進入下一個階段,這種瀑布模型的時間跨度大,靈活性不足,就很難保證項目如期保質(zhì)保量地交付實施,所以找出一種更加適合的軟件生命周期模型用于指導新研競標型項目中軟件開發(fā)活動就顯得十分必要了。

2 典型軟件生命周期模型比較分析

軟件生命周期模型是描述軟件開發(fā)過程中各種活動如何執(zhí)行的模型[9]。它規(guī)定了軟件開發(fā)的全部活動劃分成哪些階段及其主要活動和執(zhí)行順序,因此要根據(jù)軟件項目實際特點選擇合適的軟件生命周期模型。

本單位在軟件工程化管理實施過程中引入了瀑布模型、增量模型和原型模型并進行了本地化實施,形成了軟件過程管理體系文件《QLD1224-2020-軟件生存周期選型指南-v1.9》。

2.1 瀑布模型使用分析

瀑布模型也稱為設計驅(qū)動模型,是最古老也是最被廣泛熟知的模型,起源于1960年,依照連續(xù)的階段進行軟件開發(fā)[10]。瀑布模型是全生命周期模型,也是軟件工程化項目開展過程中,選用最多的模型。在本單位實施過程中,包括系統(tǒng)需求分析階段、軟件需求分析階段、軟件設計階段、軟件實現(xiàn)和調(diào)試階段、確認測試階段、驗收交付階段、運行和維護階段等,各階段按順序進行,涵蓋了GJB5000A二級中所有過程域。瀑布模型優(yōu)缺點及適用范圍如下。

(1) 瀑布模型優(yōu)點:① 提供程序化規(guī)范化的管理流程指導軟件開發(fā);② 使用簡單,順序執(zhí)行,一個結(jié)束再開始一個;③ 過程中發(fā)現(xiàn)問題及時,利于項目階段成本控制;④ 過程控制可見性較強;⑤ 記錄軟件開發(fā)過程較全,便于管理維護。

(2) 瀑布模型缺點:① 直到項目結(jié)束,用戶才能獲得可用的軟件產(chǎn)品,過程周期長;② 無法預知變化情況,若發(fā)生需求遺漏,返工風險較大;③ 模型靈活性不高,不能跨階段操作;④ 會議多,文檔多;⑤ 不易變更。

(3) 瀑布模型適用范圍:① 需求清晰穩(wěn)定,開發(fā)方和用戶方易達成共同理解,需求變更較少;② 對質(zhì)量的要求高于對成本和進度的要求;③ 首次實施軟件工程化管理的團隊。

2.2 增量模型使用分析

增量模型從需求分析到驗收交付整個過程中采用增量開發(fā)的形式,第一個增量版本大多完成軟件的核心功能,滿足最終交付軟件產(chǎn)品的基本需求,一般不包含不確定的需求以及非核心的其他需求。在接下來的增量版本中逐漸實現(xiàn)非核心需求和逐步確定的原不確定需求,增量開發(fā)過程中識別的新的需求或積累的變更,可以需求變更的形式在第二次增量開發(fā)中完成。

(1) 增量模型優(yōu)點:① 人力資源分配更加合理靈活;② 在需求不穩(wěn)定的情況下將風險降到最低;③ 能夠較好地解決人力、資金和成本等無法一次到位的問題;④ 軟件可按版本逐次交付,首先交付核心功能版本滿足客戶主要功能的先使用。

(2) 增量模型缺點:① 對軟件開發(fā)管理團隊要求較高,風險管理和過程管理方面,最好有軟件工程化管理經(jīng)驗的人參與;② 軟件架構設計要求較高;③ 集成和測試難度大,概要設計階段要設計好;④ 需求變更概率大,需求變更控制較難,對配置管理人員要求較高。

(3) 增量模型適用范圍。依據(jù)本單位試點項目經(jīng)驗,增量模型適用于中大型項目以及一部分預研項目。增量模型適用的軟件項目有如下要求:① 用戶核心需求清楚,但具體需求不清晰不穩(wěn)定;② 項目開發(fā)人員不足;③ 產(chǎn)品可以分割成不同增量(構件)分別完成;④ 軟件開發(fā)團隊具有相關領域開發(fā)經(jīng)驗;⑤ 項目的風險較高;⑥ 用戶要積極表達需求,參與項目開發(fā)過程;⑦ 團隊具備軟件工程化管理經(jīng)驗。

2.3 原型模型使用分析

原型模型是一種支持用戶想法的開放模型,用戶在軟件生命周期的設計階段能起到積極的作用,以最大減少軟件開發(fā)過程中的風險。原型模型的優(yōu)缺點及適用范圍如下。

(1) 原型模型優(yōu)點:① 快速挖掘用戶需求;② 開發(fā)方和用戶方更易達成需求的共同理解;③ 降低了開發(fā)風險和開發(fā)錯誤發(fā)生率;④ 開發(fā)周期變短,工程進度更快;⑤ 降低了項目的人力物力成本。

(2) 原型模型缺點:① 軟件產(chǎn)品需要二次開發(fā),當輸出的原型產(chǎn)品被告知用戶不是最終運行的軟件產(chǎn)品時,用戶不太容易接受,給二次開發(fā)帶來了風險;② 增加了用戶對產(chǎn)品的期待性,用戶快速看到原型后,若接下來的開發(fā)無法完成,則會給用戶造成不好的印象;③ 最終產(chǎn)品不是開發(fā)的原型,原型僅是對用戶需求的充分挖掘的定義,最終的產(chǎn)品仍要考慮質(zhì)量和可維護性;④ 增加了最終產(chǎn)品的開發(fā)難度,用戶看到快速原型產(chǎn)品后,很可能會提出更高一級的需求,這無形增大了最終產(chǎn)品的開發(fā)難度。

(3) 原型模型適用范圍。本單位實際項目開發(fā)中,一些自研項目或用于驗證某些技術原理的項目會選用原型模型。原型模型適用的軟件項目應滿足以下條件:① 用戶需求不明確;② 用戶對交付的文檔質(zhì)量要求不高;③ 用戶要求能快速看到產(chǎn)品的概貌;④ 項目的主要目的用于展示或者驗證原理;⑤ 適合中小型項目開發(fā),不太適合大型項目開發(fā)。

通過對以上三種典型軟件生命周期模型特點、優(yōu)缺點和使用場景進行分析,基于對需求不同程度的理解,軟件項目負責人在選用軟件生命周期模型時可從以下幾點進行考慮:(1) 軟件需求明確且穩(wěn)定可靠時盡量選用瀑布模型;(2) 軟件核心需求比較明確且其他需求可逐步確定時盡量選用增量模型;(3) 軟件需求不明確且用戶不知道怎么表達需求時可選用原型模型。

3 新研競標項目軟件開發(fā)過程特點

近年來,隨著軍改的推進實施,公司參與相關部門市場化招標競標的項目越來越多,經(jīng)各項目組匯總分析,概括本公司參與競標項目的軟件開發(fā)大多具有以下特點:

(1) 多為嵌入式軟件,參與研發(fā)的項目多為陸面通信裝備項目,開發(fā)的軟件也多為運行在裝備中的嵌入式軟件,軟件的研制受到特定的硬件和軟件環(huán)境約束。

(2) 研發(fā)周期短,軟件的開發(fā)一般會納入裝備研制過程,隨裝備一起開發(fā)測試,與裝備一起交付,與硬件開發(fā)周期相比,軟件開發(fā)研制周期更短。

(3) 需求明確且穩(wěn)定,競標項目從競標任務書下達的那一刻起,就確定了該項目的所有功能、性能、對外接口要求等研制內(nèi)容,且在競標研制過程中,很少做出大的改變。

(4) 重視功能的實現(xiàn),較少對文檔有較高要求,競標型項目一般會要求參與競標的單位完成規(guī)定的功能,在功能都能夠達標的基礎上,會對性能進行測試,而對文檔則不會提出過多要求。

針對上述新研競標項目的四個特點,若選擇現(xiàn)有典型的瀑布模型,則必須按照其規(guī)定的七個階段完成相應活動、輸入的工作產(chǎn)品、輸出的工作產(chǎn)品等要求,嚴格按順序進行評審,走完整個全生命周期,這樣一來,雖然開發(fā)過程得到了保障,但實踐表明其研制周期就無法滿足要求,往往不能按期提交程序代碼,從而造成項目不能按期交標。

若選擇現(xiàn)有典型的增量模型,把軟件劃分為多個構件進行開發(fā),并依次集成和測試發(fā)布,至最終形成一個可發(fā)布的軟件版本,這就要求每次生成的軟件必須是一個可以發(fā)布并穩(wěn)定運行的軟件版本,對于依賴硬件支撐的嵌入式軟件產(chǎn)品很難做到按構件開發(fā)集成。實踐也表明這種逐步開發(fā)的軟件研制周期也很長、大部分工作耗費在了重復測試過程中,給競標型產(chǎn)品的按期交付帶來壓力。

由于本單位參與新研競標型的項目大都需求明確且穩(wěn)定一致,按照軟件工程化體系實施要求,則不適合選擇原型模型作為控制軟件開發(fā)過程的生命周期模型,原型模型對于需求不明確的項目具有較好的適應性。

由此可見,針對上述新研競標項目的特點及現(xiàn)有生命周期模型對其適應性分析后,可知現(xiàn)有模型已不能較好滿足其開發(fā)過程的管理要求。

4 簡明應用開發(fā)模型內(nèi)涵

新研競標型項目的軟件開發(fā)活動管理,按照公司軟件過程管理體系文件中的《QLD1224-2020-軟件生存周期選型指南-v1.9》進行件生命周期模型選型,應選用瀑布模型,然而考慮到瀑布模型中各階段產(chǎn)品和文檔須滿足出口準則后才能進行下一階段的軟件開發(fā)活動,對競標型項目軟件開發(fā)管理來說,這顯然不能滿足軟件研制周期的要求。在此情況下,結(jié)合本公司多年的軟件工程化實踐和工程開發(fā)經(jīng)驗,提出了一種以瀑布模型為參考基礎的“簡明應用開發(fā)模型”,以實現(xiàn)軟件生命周期模型與實際項目研制流程相符合。簡明應用開發(fā)模型如圖1所示。

圖1 簡明應用開發(fā)模型流程示意圖

該模型共包括需求分析階段、設計與開發(fā)階段以及驗收與交付階段等三個階段,比瀑布模型的七個階段減少了四個階段,研制過程周期大大壓縮。同時,該模型中設計與開發(fā)階段(含設計、編碼以及測試等)的開始時間、結(jié)束時間雖然具有先后順序,但活動時間可以重疊,可在所有活動完成后再進行階段評審,大大增加了軟件開發(fā)活動的靈活性。需求分析階段也一樣,當需求內(nèi)部評審通過后,就可以開始設計分析活動了,而不用像瀑布模型那樣,必須等到需求正式評審通過后,才能進行下一步的設計活動,這樣靈活安排活動,減少了時間資源和人力資源的消耗,使整個項目團隊的整體工程工作量得以減少,提高了工作效率。該模型輸出的工作產(chǎn)品包括程序、文檔和數(shù)據(jù)等都和瀑布模型一樣有較高質(zhì)量要求,一樣需要參照《GJB438B-2009軍用軟件開發(fā)文檔通用要求》進行編寫[11],絲毫沒有對文檔的質(zhì)量有降低標準,只是可以不用像瀑布模型那樣每個階段都要輸出特定的文檔并通過評審后才能進入到下一個階段。該模型通過本單位多個項目試點運行后表明,能夠較好地支持陸面設備競標項目中軟件開發(fā)活動的管理。為了更好地將該模型推廣至更多項目,特對該模型的優(yōu)缺點及適用范圍進行總結(jié)如下。

(1) 簡明應用開發(fā)模型的優(yōu)點:① 減少了設計與開發(fā)階段過程中產(chǎn)生的文檔,降低了管理人員通過文檔完成情況評估項目完成進度的錯誤看法;② 聚焦軟件開發(fā)活動于軟件代碼質(zhì)量的提升,使更多的工作量集中于軟件編碼實現(xiàn)與測試;③ 加快了軟件的實現(xiàn),壓縮了軟件研制過程周期,提高了項目組人員的生產(chǎn)效率;④ 提高了文檔的一致性和準確性,驗收階段一起提交按照GJB438B要求擬制的軟件文檔,同時保證了軟件文檔的質(zhì)量;⑤ 減少了項目的階段評審,與瀑布模型相比去掉或合并了非必要的管理評審和技術評審,節(jié)省了軟件開發(fā)管理時間,降低了軟件開發(fā)的管理費用。

(2) 簡明應用開發(fā)模型缺點:① 降低了需求管理的有效性,項目的階段評審控制和軟件文檔產(chǎn)品對整個開發(fā)過程指導的減少,不易保證階段之間的正確銜接以及及時發(fā)現(xiàn)并糾正開發(fā)過程中存在的缺陷,使需求追蹤變得不好控制;② 軟件開發(fā)過程的透明性和可管理性變?nèi)?使得模型的風險控制能力也減弱;③ 模型無法解決需求不明確或不準確的問題。

(3) 簡明應用開發(fā)模型適用范圍:① 軟件項目需求明確穩(wěn)定;② 軟件項目研制周期較短(項目周期建議小于12個月);③ 源代碼規(guī)模不大(源代碼行數(shù)建議不大于5萬行)。

每個軟件生命周期模型都有本身的優(yōu)點,也都存在自身的不足,也都有其適用的范圍。雖然不能建立一個完美的軟件生命周期模型適合所有的項目,但是建立一些合理可行且適合本地化實踐操作的軟件生命周期模型還是有必要的。

5 結(jié) 語

本文通過對典型軟件生命周期模型如瀑布模型、增量模型和原型模型分析討論,并結(jié)合多年來的工程經(jīng)驗和軟件工程化實踐,提出了一種以瀑布模型為參考基礎的簡明應用開發(fā)模型用于指導本單位某些實際工程項目的實施,本地化實踐表明該模型在保證軟件開發(fā)質(zhì)量的同時,又提高了軟件開發(fā)效率(也稱工程平均生產(chǎn)率=軟件的實際有效代碼規(guī)模/項目的實際工程工作量,量綱為LOC/人天),希望對已經(jīng)通過GJB5000A二級已管理級評價的單位或項目團隊有所幫助。