孫秀芳 姜 凱

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

0 引 言

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

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

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

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

1 GJB5000A二級(jí)軟件生命周期模型的適應(yīng)性

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

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

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

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

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

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

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

2.1 瀑布模型使用分析

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

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

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

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

2.2 增量模型使用分析

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

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

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

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

2.3 原型模型使用分析

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

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

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

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

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

3 新研競(jìng)標(biāo)項(xiàng)目軟件開發(fā)過程特點(diǎn)

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

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

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

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

(4) 重視功能的實(shí)現(xiàn),較少對(duì)文檔有較高要求,競(jìng)標(biāo)型項(xiàng)目一般會(huì)要求參與競(jìng)標(biāo)的單位完成規(guī)定的功能,在功能都能夠達(dá)標(biāo)的基礎(chǔ)上,會(huì)對(duì)性能進(jìn)行測(cè)試,而對(duì)文檔則不會(huì)提出過多要求。

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

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

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

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

4 簡(jiǎn)明應(yīng)用開發(fā)模型內(nèi)涵

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

圖1 簡(jiǎn)明應(yīng)用開發(fā)模型流程示意圖

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

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

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

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

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

5 結(jié) 語

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