摘 要 本文提出了一個基于CMM的對日軟件過程管理解決方案,并通過對一個典型的對日軟件開發項目的實施,驗證了本方案在提升對日軟件過程管理能力方面的成效。
關鍵詞 CMM; KPA; 軟件外包; 對日軟件開發; 解決方案
1 引言
軟件外包已經成為全球IT行業的大趨勢,我國由于地緣、文化、歷史傳承等多方面的優勢,迅速成為日本軟件制造、服務的外包基地。但是日本企業普遍有一個特點,就是對質量要求相當嚴格,可以說是精益求精。因此如何提升企業在對日軟件開發上的軟件過程管理能力是對日軟件出口企業亟待解決的問題。CMM作為軟件過程改進的指南及評估標準,已經得到了眾多國家軟件產業界的認可,并且在北美、歐洲和日本等國家及地區得到了廣泛的應用。CMM正是解決我國眾多對日軟件出口企業軟件過程管理能力的利器。
2 CMM簡介
CMM(Capability Maturity Model,能力成熟度模型)是由美國卡內基梅隆大學的軟件工程研究所(SEI:Software Engineering Institute)開發的軟件過程持續改進模型。最初是受美國國防部委托,開發一種模型,用以評估軟件承包商能力,并且給出幫助軟件組織改進軟件過程的過程能力成熟度框架。而后,隨著逐步地完善及擴展,現在它已成為在全世界推廣實施的一種軟件評估標準,用于軟件開發過程和軟件開發能力的評估和改進。
CMM把軟件開發機構按照不同開發水平劃分為5個級別:Initial(初始化)、Repeatable(可重復)、Defined(已定義)、Managed(已管理)和Optimizing(優化中)。它是一個由低到高的演進框架。
3 對日軟件過程管理的CMM解決方案
3.1 CMM解決方案概述 本文中,作者針對對日軟件開發企業所面臨的問題,結合國內外已有的研究成果以及作者本人在對日軟件外包企業多年的軟件開發和管理經歷,提出了對日軟件開發的CMM解決方案。
本方案在CMM2級和3級的基礎上對若干KPA進行了裁減和修改,尤其是針對對日軟件開發過程中的某些重點問題對某些若干關鍵過程域(KPA, Key Process Area )的關鍵實踐進行了提煉、合并形成了新的關鍵過程——變更管理過程,作為對日軟件外包項目中的一個關鍵過程域,它將對變更進行更為系統和有效的管理。本方案重點研究了對日軟件外包項目中的需求管理、變更管理、項目計劃和跟蹤、質量保證、配置管理及培訓等若干過程。每個過程都體現了若干個關鍵過程域在實際對日軟件開發過程中的應用。重點通過對每個過程的責任人、輸入、入口準則、過程活動、出口準則及輸出等幾個方面的描述,達到解決該過程中現存問題的目的。
3.2 CMM解決方案在實際對日軟件外包項目中的應用分析 本節以一個實施了本方案的典型的對日軟件外包項目為例,通過數據的分析與比較,驗證了本方案在提升對日軟件出口企業軟件過程管理能力方面的成效。
3.2.1 測試數據分析 本項目有效代碼行共81528行,在集成測試全部完成后一共發現1521個缺陷,其中通過代碼復查發現缺陷940個,占總缺陷數的61.8%。在最后交付后由日方進行的系統測試中發現了14個缺陷,僅占總缺陷數的0.92%。通過代碼復查來查找和排除缺陷大大提高了單體測試和集成測試的工作效率,同時也降低了錯誤在后期被發現的可能性。經過統計,我們發現通過代碼復查缺陷發現率為9個/小時,而單體測試中缺陷發現率為4.5個/小時。代碼復查的缺陷修復率達到3.3分鐘/個,而單體測試則要13.2分鐘/個。由此可見代碼復查是非常有效的一種錯誤排除手段。 本項目的缺陷分布圖如圖1所示。
同時,通過對缺陷報告的統計,我們得出了下面的缺陷嚴重程度分布圖,其中A類缺陷最為嚴重,可能導致整個系統的癱瘓。B類缺陷將使得某一特定功能無法完成。C類缺陷可以通過其他類似功能的途徑來避免。D類缺陷屬于輕微缺陷,不影響到業務功能的實現。通過圖2我們可以看出本項目主要的缺陷都集中于D類缺陷。
圖1 不同階段缺陷數分布圖
圖2 缺陷類型分布圖
3.2.2 重要指標比較 經過本案在項目開發過程中的實施,本項目在質量、成本、進度三方面都較以前的項目有了較大的進步。第一,產品質量得到提高,代碼的缺陷率及返工次數大大減少,缺陷的危害性也得到降低。第二,開發效率顯著提高,這使得項目成本得到了很好的控制。第三,開發過程的透明化使得項目進度非常容易控制。為了增強說服力,此處挑選了另兩個未經本案實施的對日軟件外包項目,在幾個重要度量指標上將這三個項目作了一番比較。
首先介紹一下此三個項目的基本情況: 表3.1 項目簡介
|
本例 |
項目1 |
項目2 |
項目名 |
Smile系統 |
馬自達設備管理系統 |
X-CRM系統 |
項目規模 |
中 |
大 |
小 |
開發時間 |
4個月 |
6個月 |
1.5個月 |
總工數 |
81.2人月 |
112.5人月 |
6人月 |
開發工具 |
Bea Weblogic Oracle 10g Jsp/Servlet |
Bea Weblogic Oracle 10g Jsp/Servlet |
Tomcat3.2.3 SQLServer2000 Jsp/Servlet |
有效代碼 |
81528行 |
164060行 |
16000行 |
缺陷分布 |
復查:940 UT:499 IT:68 ST:14 |
復查:1350 UT:1053 IT:541 ST:79 |
復查:未復查 UT:189 IT:30 ST:35 |
1)遺留缺陷率 遺留缺陷率代表了一個軟件的交付質量,是評判一個軟件好壞的重要指標。此三個項目的遺留缺陷率是通過軟件交付后日方的系統測試(ST)所測出的缺陷比上總代碼行數而得出。從圖3可以看出本項目的遺留缺陷率要明顯低于另兩個項目,日方系統測試所發現的缺陷平均每萬行代碼不到三個,同時沒有發現任何重大的缺陷,因此本項目也非常順利地通過了日方的驗收。而項目2在交付后仍發現了較多的缺陷,可以說是一個失敗的項目。
2)無缺陷比率 無缺陷比率是在給定的階段內沒有缺陷的產品部件所占的百分比。通過無缺陷比率曲線可以看出在整個開發過程中軟件質量是如何提高的。高質量的軟件它的缺陷比率曲線應當呈一個遞增狀態,到最后達到一個高的質量標準。此處我們根據每個測試階段無缺陷的程序數所占的百分比來計算出這三個項目的無缺陷比率。
從圖4可以看出本項目的無缺陷比率呈一個上升的趨勢,說明隨著項目的推進,項目的質量在得到不斷地提升。雖然在前期的代碼復查中發現了較多的問題,但這使得后期遺留下來的問題得以減少,從而降低了整個測試階段的成本。相比較來看,項目2未進行代碼復查的工作(因此Review階段的無缺陷比率是100%),導致單體測試時發現了較多的缺陷,同時在軟件交付后仍遺留了較多的缺陷。項目1則介于兩者之間,由于它沒有執行嚴格的軟件過程控制,因此對于整體質量的把握并不是很好。但由于采取了諸如代碼復查等控制質量的措施,使得它的整體質量也呈一個較好的走勢。
 圖4 無缺陷比率
3)缺陷數/KLOC 在測試階段發現的缺陷數/KLOC體現了產品在這個階段開始和結束時的質量水平。經驗表明,如果一個產品在集成測試中的缺陷數/KLOC小于0.5,在系統測試中小于0.2,那么它通常不會再有什么遺留的問題。本項目的缺陷數/KLOC在集成測試中為0.8,系統測試為0.17,從集成測試的數據來看仍顯得略微偏高。但相比另兩個項目,進步還是明顯的。從下圖來看,本項目的缺陷數/KLOC呈一個穩步下降的趨勢,不過由于集成測試階段發現的缺陷較多,我們可以推測本項目在系統集成方面做得并不是很好。項目1的缺陷數/KLOC雖然也呈遞減趨勢,但在每個階段的缺陷數仍比較多。項目2則在質量上存在著更為嚴重的問題,不僅每個階段的缺陷數較多,而且在系統測試階段又有略微的上升。由于產品交付后仍存在著較多的缺陷,因而這個項目是不成功的。
4)生產率 通過本方案的實施,本項目不僅在軟件質量(缺陷率)上得到了很好的控制,同時在生產效率上也有了較大的提高。
圖6 生產率
4 結論 本方案在CMM能力成熟度模型的基礎上,結合對日軟件外包項目獨有的特點,針對其在開發過程中所存在的問題,在保證目標完整性的前提下對CMM中的KPA加以修改和裁剪,同時創新性地對若干KPA進行提煉及合并,提出了基于CMM理論的對日軟件外包項目的軟件過程方法,并通過在一個典型的對日軟件外包項目中的實際應用的數據分析與比較,得出本方案在提升對日軟件出口企業軟件過程管理能力方面的成效。隨著企業開展CMM活動的深入,今后的研究重點將放在CMM更高的成熟度級別在對日軟件外包項目的過程管理中的實施應用。
|