朱方洲 周偉良
摘要:文章討論了軟件企業(yè)在采用同一度量方法度量軟件過程和產(chǎn)品得到的質(zhì)量差別卻很大的現(xiàn)狀。通過分析度量能力成熟度模型及通用過程改進(jìn)模型,研究得出組織要改進(jìn)度量效果,必須把精力集中于提高度量能力。本文提出了基于度量能力成熟度模型度量過程改進(jìn)方法及流程,通過案例實(shí)施明顯地提高了公司的項(xiàng)目管理的成熟度水平,使公司產(chǎn)品研發(fā)和項(xiàng)目管理的能力得到很大程度的提升。
關(guān)鍵詞:度量能力成熟度模型;過程改進(jìn);關(guān)鍵過程域
中圖分類號(hào):TP311文獻(xiàn)標(biāo)識(shí)碼:A文章編號(hào):1009-3044(2009)22-pppp-0c
軟件度量(Software Measurement)是通過各種不同的量度(metric)對(duì)軟件生命周期中的各個(gè)元素進(jìn)行度量(Measure),它能夠?yàn)轫?xiàng)目管理者提供有關(guān)項(xiàng)目的各種重要信息,同時(shí)也是進(jìn)行大多評(píng)估活動(dòng)的基礎(chǔ),軟件度量是提高軟件品質(zhì)的一個(gè)重要方法。度量本身并不能增強(qiáng)或削弱軟件過程的自適應(yīng)能力,但它能給出對(duì)軟件過程內(nèi)、外部的清晰和明確的理解,為軟件過程管理提供決策信息。度量從計(jì)劃階段到數(shù)據(jù)采集階段再到度量應(yīng)用階段都明確體現(xiàn)了度量的過程性,度量過程既是軟件過程域的一部分,又是軟件管理過程的一部分。度量軟件產(chǎn)品、過程的質(zhì)量的高低依賴一個(gè)穩(wěn)定、有效的度量過程,度量過程本身也需要不斷改進(jìn)。
通過對(duì)采用度量決策支持系統(tǒng)的軟件研發(fā)組織的研究分析發(fā)現(xiàn),采用同一方法的不同軟件研發(fā)組織研發(fā)的軟件產(chǎn)品及過程的質(zhì)量差別卻很大,這差異的原因可能在于組織的度量能力的高低[1]。因此如何改進(jìn)度量過程是目前亟需研究的重要課題。
1 度量能力成熟度模型
通過大量度量程序案例研究得出,一些軟件組織的軟件度量能力強(qiáng)于另外一部分組織,部分原因可能在于它們度量能力的不同,例如軟件組織在軟件度量某些方面較成熟。度量能力是指組織能采用較低成本的方式度量產(chǎn)品,過程及資源的范圍,得到實(shí)現(xiàn)商業(yè)目標(biāo)所需的信息[2]。
1.1 體系結(jié)構(gòu)
度量能力成熟度模型類似于CMM,也包含五個(gè)不同組織度量能力級(jí)別。每個(gè)成熟度級(jí)別由許多需要組織實(shí)現(xiàn)的關(guān)鍵過程域組成,當(dāng)軟件組織實(shí)現(xiàn)第二級(jí)別的所有關(guān)鍵過程域,就認(rèn)為軟件組織達(dá)到度量能力成熟度模型的第二級(jí),當(dāng)軟件組織實(shí)現(xiàn)第二和第三所有關(guān)鍵過程域,軟件組織達(dá)到第三級(jí),依次類推。
1.2 關(guān)鍵過程域
除等級(jí)1外,每個(gè)成熟度等級(jí)被分解成幾個(gè)關(guān)鍵過程域,指明了為改進(jìn)軟件組織能力成熟度應(yīng)關(guān)注的幾個(gè)區(qū)域,關(guān)鍵過程域識(shí)別出為了達(dá)到某個(gè)成熟度等級(jí)必須解決的問題。每個(gè)關(guān)鍵過程域識(shí)別出一串相關(guān)活動(dòng),當(dāng)這些活動(dòng)全部完成時(shí),能達(dá)到一組對(duì)增強(qiáng)度量能力至關(guān)重要的目標(biāo)。
為了使組織實(shí)現(xiàn)某個(gè)關(guān)鍵域,必須達(dá)到關(guān)鍵域上全部目標(biāo),當(dāng)在連續(xù)的基礎(chǔ)上,對(duì)所有項(xiàng)目均已達(dá)到一個(gè)關(guān)鍵區(qū)域的目標(biāo)時(shí),該組織達(dá)到以此區(qū)域?yàn)樘卣鞯亩攘磕芰σ?guī)范化。
2 度量過程改進(jìn)
軟件度量過程是軟件過程中進(jìn)行確認(rèn)、定義、收集和分析度量,以用于理解、評(píng)價(jià)、預(yù)測(cè)和控制軟件過程和軟件產(chǎn)品的部分。度量過程是軟件過程不可分割的組成部分。
2.1 基于度量改進(jìn)的通用過程模型
度量的對(duì)象是軟件過程中的各項(xiàng)活動(dòng)以及各階段活動(dòng)的中間產(chǎn)物,度量過程貫穿軟件的整個(gè)生命周期。度量過程包括分析度量需求、制定度量計(jì)劃、收集度量數(shù)據(jù)、分析數(shù)據(jù)等過程[3]。
圖1模型包含三個(gè)概念:組織面臨問題或目標(biāo)、可能原因或可能的解決方案及設(shè)計(jì)度量程序或可能解決方法的實(shí)驗(yàn);四個(gè)步驟為分析、方案的實(shí)施、分析及通過可行方案解決組織的問題或?qū)崿F(xiàn)組織目標(biāo)。該模型始于組織面臨問題或目標(biāo),假設(shè)不考慮組織面臨問題或目標(biāo)的大小情況。組織所遇到的問題可能牽涉到軟件設(shè)計(jì)者或軟件組織,不論是組織還是個(gè)人,度量過程改進(jìn)都必須經(jīng)歷上述四個(gè)步驟。軟件組織首先通過自身組織的情況、相關(guān)專業(yè)知識(shí)及常識(shí)來分析所遇到的問題,得出一個(gè)或多個(gè)可能原因;然后組織根據(jù)其研究能力、專業(yè)知識(shí)根據(jù)分析的原因推斷出其解決方案,多數(shù)情況下組織需要從多種原因中找出最可能的原因、多種方案中選出最優(yōu)的一種方案,并得出該方案需要的基礎(chǔ)數(shù)據(jù),為了收集與問題相關(guān)重要數(shù)據(jù),軟件組織設(shè)計(jì)試驗(yàn)或建立一套度量程序;最后組織通過確定的方案實(shí)現(xiàn)組織的目標(biāo)或解決所遇到的問題。
2.2有效度量程序關(guān)鍵要素
通過對(duì)度量成熟度模型及通用過程模型的分析,可以把M-CMM應(yīng)用到通用過程模型如下圖2所示。
分析發(fā)現(xiàn)M-CMM的所有關(guān)鍵過程域映射在通用過程模型的右半部分,這也說明軟件組織要改進(jìn)度量效果,必須把精力集中于度量能力。如果企業(yè)的目標(biāo)并沒有定位于M-CMM之內(nèi),從度量的觀點(diǎn)它們的目標(biāo)是可以變化的。度量過程首先必須把企業(yè)目標(biāo)轉(zhuǎn)換成度量目標(biāo),最終再把收集的數(shù)據(jù)及反饋情況解釋給軟件組織。
3 組織級(jí)軟件度量過程改進(jìn)實(shí)現(xiàn)
軟件度量過程改進(jìn)的建立需要在組織的環(huán)境中進(jìn)行考慮,創(chuàng)建組織級(jí)的軟件度量過程改進(jìn)需要將軟件度量與組織標(biāo)準(zhǔn)的軟件過程集成在一起,使軟件度量成為組織軟件開發(fā)活動(dòng)中的一個(gè)標(biāo)準(zhǔn)實(shí)踐[4]。不同的組織由于其目標(biāo)不同,所選擇的測(cè)量元是不同的。但是在不同的組織會(huì)擁有一些相同的度量模式。
3.1 度量過程改進(jìn)的目標(biāo)
在任何一個(gè)軟件組織中,組織實(shí)施過程改進(jìn)都需要花費(fèi)很大的人力、物力和財(cái)力,并學(xué)習(xí)采用新的過程。此外,還需要購置輔助工具(軟件支持系統(tǒng))、對(duì)員工進(jìn)行相應(yīng)的專業(yè)培訓(xùn)、度量及邀請(qǐng)專家現(xiàn)場(chǎng)進(jìn)行指導(dǎo)。通過過程改進(jìn),軟件組織達(dá)到本組織所需要的目標(biāo),如企業(yè)的經(jīng)濟(jì)效益、技術(shù)革新及高效的開發(fā)能力、產(chǎn)品的質(zhì)量及效率、客戶的高滿意度及減少成本等等。
為了有效實(shí)現(xiàn)組織的改進(jìn)目標(biāo),應(yīng)用卡普蘭和諾頓提出了平衡積分卡(The Balanced Scorecard,簡(jiǎn)稱BSC)理論,提出了平衡積分卡度量框架[5],提供了一些相關(guān)的問題和度量去判定組織的目標(biāo)和策略實(shí)現(xiàn)情況。它擴(kuò)展了軟件組織評(píng)價(jià)業(yè)績(jī)的指標(biāo)體系,不僅圍繞財(cái)務(wù)層面,而且還包括了顧客層面、內(nèi)部經(jīng)營(yíng)層面和學(xué)習(xí)成長(zhǎng)層面。對(duì)平衡積分卡的度量指標(biāo)進(jìn)行篩選時(shí),不但要遵循 SMART原則(即具體的Specific;可度量的 Measurable;可實(shí)現(xiàn)的Attainable;現(xiàn)實(shí)的 Realistic;有時(shí)限的Time—bound),而且要求各層面及各層面指標(biāo)之間呈因果鏈關(guān)系。上述四個(gè)方面主要內(nèi)容:
1) 財(cái)務(wù)層面:商業(yè)目標(biāo)及從項(xiàng)目所得利潤(rùn)。
2) 客戶滿意度:內(nèi)、外部客戶的滿意度,主要有性價(jià)比、平均故障時(shí)間及請(qǐng)求響應(yīng)時(shí)間等。
3) 軟件開發(fā)層面:軟件需求分析、開發(fā)、維護(hù)及服務(wù)過程的實(shí)踐及方法的改進(jìn),也包括組織人力資源的管理及協(xié)調(diào)能力的提高。
4) 學(xué)習(xí)和成長(zhǎng)層面:組織開發(fā)能力的提高,如全體職員的技術(shù)技能,領(lǐng)域知識(shí)的層次及員工的斗志等。
為達(dá)到改進(jìn)目標(biāo),可度量的指標(biāo)如下表:
通過這些改進(jìn)轉(zhuǎn)化為對(duì)現(xiàn)有和潛在客戶業(yè)務(wù)的擴(kuò)大,并最終轉(zhuǎn)化為財(cái)務(wù)業(yè)績(jī)的提高,即達(dá)到既定的目標(biāo)。
3.2 過程改進(jìn)的計(jì)劃
通常,軟件組織進(jìn)行過程改進(jìn),是由于軟件開發(fā)組織在管理過程中存在著問題,有改進(jìn)的需要。典型的問題如顧客的不滿、軟件的質(zhì)量缺陷、預(yù)算范圍內(nèi)無法按時(shí)交貨和過度返工,如果軟件組織的各層次人員都感覺到存在這些問題,推動(dòng)過程改進(jìn)計(jì)劃是比較有力的,得到組織中高層領(lǐng)導(dǎo)或高層管理的支持和參與的過程改進(jìn)是比較易于實(shí)施和推廣的。制定度量過程的計(jì)劃包括兩個(gè)方面的活動(dòng),一個(gè)是確認(rèn)范圍,一個(gè)是定義程序步驟[6]。確認(rèn)范圍根據(jù)是要明確度量需求的大小,以限定一個(gè)適合于企業(yè)本身需求的度量過程。因?yàn)樵谡麄€(gè)度量過程中是需要花費(fèi)人力物力等有限資源的,不切實(shí)際的大而全或不足以反映實(shí)際結(jié)果的需求都會(huì)影響度量過程的可靠性以及企業(yè)的發(fā)展能力。在確認(rèn)了范圍后,就需要定義操作及度量過程的步驟,在構(gòu)造的同時(shí)建立過程改進(jìn)計(jì)劃書。計(jì)劃書主要內(nèi)容如下表:
根據(jù)組織的戰(zhàn)略不同,改進(jìn)的目標(biāo),管理優(yōu)先級(jí),實(shí)踐運(yùn)行的層次,實(shí)施每次實(shí)踐對(duì)組織的價(jià)值也不相同。軟件工程過程組必須確定那些需要作過程改進(jìn),如何實(shí)現(xiàn)更改,以及如何獲得所需要的改進(jìn)。在實(shí)施計(jì)劃時(shí),過程組可以用度量成熟度模型的不同階段和關(guān)鍵領(lǐng)域來構(gòu)造部門可操作的行動(dòng)計(jì)劃和定義軟件過程。
3.3 建立過程改進(jìn)的組織架構(gòu)
設(shè)置過程改進(jìn)的角色和職責(zé)是啟動(dòng)和規(guī)劃過程改進(jìn)的一個(gè)關(guān)鍵部分。有些場(chǎng)合的討論會(huì)、工作組、或領(lǐng)導(dǎo)班子能夠承擔(dān)這些角色和職責(zé)。支持過程改進(jìn)的基礎(chǔ)架構(gòu)取決于多種因素,其中包括該組織的文化和規(guī)模,多樣性的軟件群體,和軟件過程改進(jìn)的方式選擇。
最好的基礎(chǔ)架構(gòu)和組織的各層次都有良好的協(xié)調(diào)配合。通常有三個(gè)或四個(gè)基礎(chǔ)架構(gòu)因素。
SEPG(Software Engineering Process Group)是指由軟件過程專家組成的團(tuán)隊(duì),負(fù)責(zé)在軟件組織內(nèi)推動(dòng)和促進(jìn)軟件過程改進(jìn)。
進(jìn)程行動(dòng)小組(Process Action Teams)是指由項(xiàng)目經(jīng)理和軟件工程師組成的團(tuán)隊(duì),負(fù)責(zé)軟件開發(fā)和改進(jìn)任務(wù),通常由SEPG和一些兼職專家領(lǐng)導(dǎo),任務(wù)一旦完成一般就解散的團(tuán)體。
度量專組應(yīng)該利用真實(shí)的項(xiàng)目對(duì)度量過程進(jìn)行測(cè)試和調(diào)整,然后才能將該過程應(yīng)用到整個(gè)組織中去,專組應(yīng)確保所有的項(xiàng)目都能理解并執(zhí)行度量過程,并幫助他們實(shí)現(xiàn)具體的細(xì)節(jié)。專組根據(jù)度量總結(jié)報(bào)告步審視度量過程是否滿足了企業(yè)的目標(biāo)需求,在進(jìn)一步確認(rèn)后應(yīng)進(jìn)行文檔化管理,使其成為企業(yè)組織軟件標(biāo)準(zhǔn)化過程中的一部分,同時(shí)定義工作的模板,角色,以及責(zé)任,今后組織按照已經(jīng)定義的度量標(biāo)準(zhǔn)來進(jìn)行過程的實(shí)施。
3.4 過程改進(jìn)的實(shí)施
過程的實(shí)施也包括兩方面的活動(dòng),一個(gè)是數(shù)據(jù)的采集,一個(gè)是數(shù)據(jù)的分析。數(shù)據(jù)的采集根據(jù)已定義的度量操作進(jìn)行數(shù)據(jù)的采集,記錄及存儲(chǔ)。此外,數(shù)據(jù)還應(yīng)經(jīng)過適當(dāng)?shù)男r?yàn)以確認(rèn)有效性。在進(jìn)行該項(xiàng)活動(dòng)時(shí)應(yīng)具有一定的針對(duì)性,對(duì)于不同的項(xiàng)目或活動(dòng)所需要的實(shí)際數(shù)據(jù)量是有差別的,而且對(duì)活動(dòng)狀態(tài)的跟蹤也是非常重要的。
數(shù)據(jù)的分析包括分析數(shù)據(jù)及準(zhǔn)備報(bào)告,并提交報(bào)告,當(dāng)然進(jìn)行評(píng)審以確保報(bào)告足夠的確實(shí)性是有必要的。這些程序步驟可能會(huì)需要更新,因?yàn)閳?bào)告可能沒有為使用者提供有益的幫助或使用者對(duì)報(bào)告中的內(nèi)容不理解,在這兩種情況下,都應(yīng)回饋并更新度量過程以再進(jìn)行數(shù)據(jù)分析。
3.5 持續(xù)過程的改進(jìn)
過程的改進(jìn)是一個(gè)不斷持續(xù)的過程。我們應(yīng)建立一種機(jī)制便于過程小組把有助于過程改進(jìn)的方法反饋給SEPG,并應(yīng)用與將來的過程改進(jìn)策略和計(jì)劃[7]。以外,對(duì)度量過程本身進(jìn)行評(píng)估,報(bào)告的使用者會(huì)對(duì)數(shù)據(jù)的有效性進(jìn)行反饋。這些反饋可能來自其他的活動(dòng),但一般都會(huì)溶入到度量過程新一輪的生命周期中去,對(duì)度量過程進(jìn)行新的確認(rèn)及定義。在整個(gè)改進(jìn)過程中不斷地根據(jù)反饋進(jìn)行監(jiān)督,并建立有效的項(xiàng)目管理工具集、有效的軟件開發(fā)工具集、有效的質(zhì)量保證和測(cè)試工具、有效的軟件過程和方法、有效的組織結(jié)構(gòu)及高效的管理者隊(duì)伍,以提高組織的競(jìng)爭(zhēng)力,實(shí)現(xiàn)企業(yè)階段目標(biāo)及終極目標(biāo)。
4 總結(jié)
軟件過程改進(jìn)是提高軟件組織開發(fā)能力的重要途徑,它具有的漸進(jìn)性、系統(tǒng)性、長(zhǎng)期性等特征,客觀上需要在軟件研發(fā)過程中持續(xù)地積累和有效地應(yīng)用,通過在項(xiàng)目的實(shí)施,過程改進(jìn)取得了一定的成果,明顯地提高了公司的項(xiàng)目管理、度量能力的成熟度,增強(qiáng)了項(xiàng)目管理的可視性和可預(yù)測(cè)性,降低了項(xiàng)目的風(fēng)險(xiǎn),提高了客戶的信任感和滿意度。
參考文獻(xiàn):
[1] Victor Basili, Lionel Briand, Steven Condon, Yong-Mi Kim, Walc'elio L. Melo, and Jon D.Valett. Understanding and Predicting the Process of Software Maintenance Releases.In Proceedings of the 18th International Conference on Software Engineering, pages 464–474, Berlin,Germany, May 25-29, 1996. IEEE Computer Society Press.
[2] Barbara Kitchenham, Shari Lawrence Pfleeger, and Norman Fenton. Towards a Framework for Software Measurement Validation. IEEE Transactions on Software Engineering, 21(12),December 1995.
[3] Frank Niessink and Hans van Vliet. Towards Mature Measurement Programs. In Paolo Nesi and Franz Lehner, editors, Proceedings of the Second Euromicro Conference on Software Maintenance and Reengineering, pages 82–88, Florence, Italy, March 8-11,1998. IEEE Computer Society.
[4] 楊海燕,趙巍,張力.軟件度量[M].北京:機(jī)械工業(yè)出版社,2004.
[5] 4. Software Engineering Institute, CMMI for Systems Engineering /Software Engineering, Version 1.1 (Staged Representation), CMU/SEI-2002-TR-004, Software Engineering Institute, Pittsburgh PA, December 2001..
[6] 9. Beth Layman and Charles Weber, "Measurement Maturity and the CMM: How Measurement Practices Evolve as Processes Mature,"Software Quality Practitioner,4,3,2002.
[7] Beth Layman and Joyce Statz, "Navigating the Speed Bumps for Measurement and Analysis,"Tutorial pre6sentation, SEPG Conference,March 2004, Orlando, FL.