軟件企業(yè)的軟件生存周期模型_第1頁
軟件企業(yè)的軟件生存周期模型_第2頁
軟件企業(yè)的軟件生存周期模型_第3頁
軟件企業(yè)的軟件生存周期模型_第4頁
軟件企業(yè)的軟件生存周期模型_第5頁
全文預(yù)覽已結(jié)束

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡介

軟件企業(yè)的軟件生存周期模型

1軍民軟件能力成熟度模型中國的航天系統(tǒng)長期以來一直進(jìn)行著應(yīng)用軟件的研究和應(yīng)用。20世紀(jì)90年代中期,原航天工業(yè)聯(lián)合會(huì)發(fā)布了相關(guān)要求,將軟件納入完整的模擬器產(chǎn)品表,并進(jìn)行軟件管理,并規(guī)定了規(guī)范工程管理對(duì)模擬器軟件的應(yīng)用。然而,隨著軟件復(fù)雜度和規(guī)模的不斷提高,傳統(tǒng)的軟件工程化方法在保證軟件質(zhì)量和進(jìn)度方面已顯得力不從心,新的理論和方法不斷地被研究和實(shí)踐。本文首先介紹“軍用軟件能力成熟度模型”的基本內(nèi)容。然后對(duì)當(dāng)前我國在航天器軟件工程化推行中存在的問題進(jìn)行分析,提出了將“軟件能力成熟度模型”思想和內(nèi)容進(jìn)行本地化,以解決軟件工程化推行中存在的問題,進(jìn)而提升軟件研制能力的相關(guān)建議。2軟件能力成熟度于cmmi1.2年—軟件能力成熟度模型簡介20世紀(jì)80年代,美國國防部為了評(píng)估其軟件承包商的能力,委托卡內(nèi)基—梅隆大學(xué)的軟件工程研究所(SEI)提出了一種“軟件能力成熟度模型”(CMM),1991年推出1.0版,2000年升級(jí)為集成能力成熟度模型(CMMIntegration,CMMI)。美國國防部要求軟件承研單位的CMMI等級(jí)達(dá)到三級(jí)以上,NASA要求航天軟件的研制單位達(dá)到CMMI四級(jí)以上。2000年6月,我國國務(wù)院頒發(fā)了《鼓勵(lì)軟件產(chǎn)業(yè)和集成電路產(chǎn)業(yè)發(fā)展的若干政策》(18號(hào)文件),鼓勵(lì)組織實(shí)施CMMI認(rèn)證。針對(duì)國防領(lǐng)域,2003年發(fā)布了《GJB5000-2003軍用軟件研制能力成熟度模型》,2008年又發(fā)布了《GJB5000A-2008軍用軟件研制能力成熟度模型》(簡稱GJB5000A),內(nèi)容來源于CMMIV1.2版,略有刪減。GJB5000A中軟件能力成熟度模型將軟件研制能力成熟度分為5個(gè)等級(jí),分別是初始級(jí)、已管理級(jí)、已定義級(jí)、已定量管理級(jí)和優(yōu)化級(jí)。每個(gè)成熟度等級(jí)由若干過程域組成,其中初始級(jí)不包含任何過程域;已管理級(jí)包含配置管理、測量與分析、項(xiàng)目監(jiān)控、項(xiàng)目策劃、過程和產(chǎn)品質(zhì)量保證、需求管理、供方協(xié)議管理等過程域;已定義級(jí)包含決策分析和決定、集成項(xiàng)目管理、組織過程定義、組織過程焦點(diǎn)、組織培訓(xùn)、產(chǎn)品集成、需求開發(fā)、風(fēng)險(xiǎn)管理、技術(shù)解決方案、確認(rèn)、驗(yàn)證等過程域;已定量管理級(jí)包含組織過程績效、定量項(xiàng)目管理等過程域;優(yōu)化級(jí)包含原因分析和決定、組織創(chuàng)新和部署等過程域。每個(gè)過程域由若干目標(biāo)組成(包括各個(gè)過程域獨(dú)自的專用目標(biāo)和所有過程域都包含的共用目標(biāo)),每個(gè)目標(biāo)又由若干實(shí)踐組成?!败娪密浖芰Τ墒於饶P汀睂?duì)初始級(jí)組織的軟件研制過程無任何要求。軟件開發(fā)組織要達(dá)到除初始級(jí)之外的某個(gè)成熟度等級(jí),除了需要實(shí)施該成熟度等級(jí)包含的過程域之外,還需實(shí)施比該成熟度等級(jí)低的所有等級(jí)所包含的過程域,當(dāng)一個(gè)過程域包含的所有目標(biāo)均被實(shí)現(xiàn)時(shí),則認(rèn)為該過程域已被實(shí)現(xiàn)。筆者認(rèn)為,軟件能力成熟度模型的核心思想主要體現(xiàn)在以下幾個(gè)方面:(1)將軟件開發(fā)活動(dòng)的整體視為一個(gè)過程,而不只是將軟件工程活動(dòng)視為一個(gè)過程,即關(guān)注軟件開發(fā)活動(dòng)各個(gè)方面的過程化,而不僅是工程活動(dòng)的過程化;(2)重視測量數(shù)據(jù),包括軟件的規(guī)模、質(zhì)量、進(jìn)度等,強(qiáng)調(diào)用數(shù)據(jù)說話;(3)重視組織資產(chǎn)的積累和應(yīng)用,強(qiáng)調(diào)成果不歸個(gè)人所有,不做重復(fù)性開發(fā);(4)強(qiáng)調(diào)本地化的實(shí)踐。3目前,該項(xiàng)目的開發(fā)不足3.1新研軟件研制流程對(duì)比2005年,航天科技集團(tuán)公司發(fā)布了軟件工程化管理要求方面的標(biāo)準(zhǔn),對(duì)航天器軟件生存周期及各階段的管理提出了要求,其中,在軟件生存周期的選擇上只規(guī)定了一種“瀑布模型”,如圖1所示。2013年,根據(jù)新的發(fā)展形勢在多個(gè)方面對(duì)原標(biāo)準(zhǔn)進(jìn)行了修訂和完善,如在軟件生存周期上,按繼承性程度的不同提出了4類軟件研制流程,但依然是基于“瀑布模型”的裁剪,其中新研軟件仍采用完整“瀑布模型”。從圖1可看出,新研軟件的研制流程共分為10個(gè)階段,順序執(zhí)行。但近年來,由于航天器整器研制周期縮短,而整器測試時(shí)間加長等原因,使得產(chǎn)品研制的時(shí)間大大壓縮。對(duì)于硬件而言,新研產(chǎn)品可以通過方案階段先期開展技術(shù)攻關(guān),來解決研制周期不足問題;軟件產(chǎn)品卻很難做到,因?yàn)檐浖男枨蟠_定較晚,往往需要到初樣開始后的較長時(shí)間,而且越是技術(shù)狀態(tài)新的型號(hào),軟件需求下達(dá)越晚。對(duì)于為整星各個(gè)分系統(tǒng)提供服務(wù)的軟件(如數(shù)據(jù)管理軟件),往往具有“三最”特點(diǎn):需求下達(dá)最晚,軟件交付給航天器最早,(交付前)軟件研制周期最短。因此,往往前面的許多階段都還未完成,就直接進(jìn)入航天器測試階段。在這種情況下,新研軟件很難按照?qǐng)D1要求的流程開展研制活動(dòng),實(shí)際操作過程中不能按照既定的軟件研制技術(shù)流程進(jìn)行的現(xiàn)象非常普遍,使得多個(gè)階段的工作難以落實(shí),未發(fā)揮應(yīng)有的作用。3.2多為單一,不能有效保證軟件開發(fā)整體需求首先是對(duì)軟件開發(fā)工作量和進(jìn)度缺少可信的數(shù)據(jù)采集和分析。由于軟件具有修改便利、可不斷完善等特點(diǎn),又由于系統(tǒng)聯(lián)試前留給軟件開發(fā)的時(shí)間不足等客觀原因,導(dǎo)致軟件在開發(fā)期間存在大量交付“半成品”的現(xiàn)象。同時(shí)相對(duì)于航天器研制主線而言,軟件產(chǎn)品的開發(fā)工作易被忽視,其進(jìn)度也可根據(jù)需要伸縮,在此過程中軟件開發(fā)自身的工作量、進(jìn)度往往沒有被客觀地記錄,而是跟著航天器系統(tǒng)設(shè)計(jì)進(jìn)行,最初制訂的軟件開發(fā)計(jì)劃往往寫完后即束之高閣,無法指導(dǎo)實(shí)際的軟件開發(fā)。其次,對(duì)于各個(gè)階段出現(xiàn)的問題、故障(bug)、記錄和統(tǒng)計(jì)也很不全面,如開發(fā)方測試、分系統(tǒng)聯(lián)試中發(fā)現(xiàn)的大部分問題未被記錄,航天器整器測試中只分析、統(tǒng)計(jì)占一小部分的問題。由于缺少對(duì)工作量、進(jìn)度、質(zhì)量等多方面數(shù)據(jù)的采集、統(tǒng)計(jì)、分析,使得某些深層次問題被掩蓋。例如當(dāng)前航天器軟件開發(fā)遇到的一個(gè)重要問題是:軟件開發(fā)未完成即交付航天器,軟件質(zhì)量的保證主要靠航天器整器測試。充分的航天器整器測試是當(dāng)前航天器軟件質(zhì)量保證的“強(qiáng)項(xiàng)”。因?yàn)橐环矫?測試環(huán)境與真實(shí)環(huán)境的相似度更高,這對(duì)軟件問題的暴露非常有利;另一方面,當(dāng)前航天器整器測試的周期變長,同時(shí)測試對(duì)軟件測試的項(xiàng)目也大量增加,與過去相比,航天器整器測試階段對(duì)軟件功能、性能的覆蓋率要高很多。依靠航天器整器測試這個(gè)強(qiáng)項(xiàng)來確保航天器軟件的質(zhì)量,雖然很有效,但也存在一些問題和隱憂。1測試邏輯復(fù)雜系統(tǒng)測試(如航天器整器測試)對(duì)于規(guī)模不大、邏輯不很復(fù)雜的軟件,是可以保證質(zhì)量的,但是對(duì)于規(guī)模龐大、邏輯復(fù)雜的軟件,很可能無法保證測試的充分性,因?yàn)閮?nèi)部的一些邏輯可能測不到。目前的航天器軟件(嵌入式)的規(guī)模還不算大(例如很少有源代碼超過10萬行的),邏輯也不是十分復(fù)雜,隨著后續(xù)軟件功能的復(fù)雜化,這種過分依賴系統(tǒng)測試的做法是存在隱患的。2測試成本的計(jì)算資料顯示,美國軍用軟件的系統(tǒng)測試時(shí)間只占開發(fā)時(shí)間的4.8%;ESA的航天器整器測試時(shí)間也很短,主要測試接口,產(chǎn)品本身的質(zhì)量由產(chǎn)品交付前的研制階段來保證,其航天器整器測試的成本是按小時(shí)計(jì)算的。相比而言,我國航天器軟件開發(fā)的時(shí)間一般為4~5個(gè)月,而航天器整器測試時(shí)間初樣一般1年以上,正樣一般8個(gè)月以上。現(xiàn)有的做法對(duì)于軟件開發(fā)而言,效率不高。因?yàn)榻桓肚傲艚o軟件開發(fā)的時(shí)間不足,使得軟件無法按照最有效的開發(fā)方法進(jìn)行,只能先解決最緊迫的編碼問題,其他工作產(chǎn)品后補(bǔ);同時(shí),由于航天器整器測試的時(shí)間非常長,在此過程中軟件更改的空間很大,很容易導(dǎo)致需求提出方在初期不進(jìn)行充分考慮,提出不正確、不合理的需求,而在測試過程中頻繁修改,導(dǎo)致軟件的不斷返工。3航天器整器測試時(shí)間將進(jìn)一步縮短長時(shí)間的航天器整器測試,使得其研制周期較長,成為我國與國外航天器競標(biāo)中的弱項(xiàng)。隨著市場化競爭,航天器研制周期和成本可能會(huì)進(jìn)一步壓縮,研制過程逐步與國際接軌,航天器整器測試時(shí)間必然要縮短。但在現(xiàn)有的軟件研制模式下,由于軟件的質(zhì)量過依賴于航天器電性能測試,一旦測試時(shí)間壓縮,對(duì)軟件質(zhì)量會(huì)造成重大影響。3.3軟件復(fù)用的原因由于軟件復(fù)用缺少軟件開發(fā)組織的參與,如缺少組織級(jí)的軟件復(fù)用庫和使用指南、復(fù)用規(guī)程等,沒有指定人員對(duì)復(fù)用軟件模塊的質(zhì)量、維護(hù)負(fù)責(zé)。航天器軟件的復(fù)用往往體現(xiàn)出與“人”相關(guān)、與“項(xiàng)目”相關(guān)。與“人”相關(guān)是指只有開發(fā)人員本人能夠復(fù)用其過去開發(fā)的模塊,其他人不會(huì)用;與“項(xiàng)目”相關(guān)是指只有在兩個(gè)非常相似的航天器間才會(huì)復(fù)用,而且多數(shù)情況下復(fù)用者是知其然不知所以然。這種隨意性給軟件復(fù)用的質(zhì)量、效率都帶來了不利影響。4基于原子型的生存周期建模針對(duì)前文中分析的當(dāng)前航天器軟件工程化實(shí)施中存在的不足,結(jié)合對(duì)軟件能力成熟度模型的研究和應(yīng)用,提出以下幾點(diǎn)解決措施。軟件能力成熟度模型非常強(qiáng)調(diào)本地化,要求組織建立適合自己的可用的組織過程資產(chǎn)集和工作環(huán)境。例如對(duì)于生存周期模型,其明確提出“生存周期模型可以對(duì)各種顧客或各種情況開發(fā),因?yàn)橐粋€(gè)生存周期模型不可能適合所有情況”。針對(duì)當(dāng)前新研軟件的特點(diǎn),筆者開發(fā)了一種“原型瀑布模型”,以實(shí)現(xiàn)生存周期與實(shí)際軟件研制流程相符,并更好地保證交付前的軟件質(zhì)量(如圖2所示)。該模型的特點(diǎn)是采用目標(biāo)分解法,將軟件開發(fā)分成兩個(gè)階段:第一階段,采用原型法開發(fā),以快速實(shí)現(xiàn)支持系統(tǒng)功能檢查的軟件功能,滿足航天器第一階段目標(biāo);第二階段,待原型完成交付且用戶需求基本明確后,再按照瀑布模型開展研制工作,經(jīng)歷一個(gè)完整的開發(fā)過程,以確保軟件的功能完整、性能滿足要求、質(zhì)量可靠,滿足航天器第二階段目標(biāo)。2組織資產(chǎn)管理軟件能力成熟度模型里頻繁出現(xiàn)的一個(gè)詞是“組織資產(chǎn)”,要求在軟件的策劃、開發(fā)、測試中都要使用組織已有的資產(chǎn),并將在新的開發(fā)過程中形成的代碼、文件、數(shù)據(jù)、經(jīng)驗(yàn)等納入組織資產(chǎn)。軟件能力成熟度模型要求被復(fù)用的資產(chǎn)得到管理,要保證享有權(quán)限的人員能夠很方便地獲取到組織資產(chǎn);在具體項(xiàng)目中,使用了組織資產(chǎn)要留下記錄;項(xiàng)目開發(fā)完成后,要提煉出組織資產(chǎn)提交到組織資產(chǎn)庫。因此,軟件能力成熟度模型不是簡單地提出軟件要“復(fù)用”的要求,而是提出了很多具體的、操作性較強(qiáng)的軟件復(fù)用實(shí)施的方法和要求,并非常強(qiáng)調(diào)將其上升為組織行為,這對(duì)于提升航天器軟件的復(fù)用能力,減少重復(fù)開發(fā),提高質(zhì)量和效率,具有非常重要的現(xiàn)實(shí)意義。3項(xiàng)目監(jiān)控管理方面。首先應(yīng)建立兩種指標(biāo)要解決問題、提升能力,首先要發(fā)現(xiàn)問題和隱患,并了解導(dǎo)致問題的原因。按照軟件能力成熟度模型的思想,根據(jù)本單位特點(diǎn)對(duì)項(xiàng)目的進(jìn)度偏離情況、發(fā)生的更改、存在的風(fēng)險(xiǎn)、資源到位情況等進(jìn)行監(jiān)控;同時(shí)對(duì)規(guī)模、進(jìn)度、工作量、質(zhì)量、變更等指標(biāo)進(jìn)行分解,設(shè)計(jì)多個(gè)能夠表征這些指標(biāo)的測量項(xiàng),確定采集時(shí)機(jī)、存儲(chǔ)方法、分析方法、采集人員、復(fù)核人員、分析人員等。對(duì)軟件開發(fā)中存在的深層次問題,以“數(shù)據(jù)”為判斷依據(jù),減少憑經(jīng)驗(yàn)、憑印象等不科學(xué)方法使用的概率。4軟件能力成熟度模型軟件工程主要關(guān)注軟件工程過程,而對(duì)軟件工程的輔助、支持等方面的過程關(guān)注不夠,例如策劃、監(jiān)控、測量分析、質(zhì)量保證、組織培訓(xùn)等,使得軟件工程過程經(jīng)常由于“配套設(shè)施”跟不上,導(dǎo)致實(shí)施困難很大。軟件能力成熟度模型則更加關(guān)注軟件開發(fā)活動(dòng)的整體,即如何對(duì)軟件開發(fā)活動(dòng)的各個(gè)方面進(jìn)行過程化,其中包括工程活動(dòng)的過程化。實(shí)踐證明,通過對(duì)項(xiàng)目管理、支持、過程管理等工程以外的活動(dòng)也充分重視,實(shí)施過程化的管理、

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

最新文檔

評(píng)論

0/150

提交評(píng)論