基于CMMI及DevOps的軟件開發(fā)及管理數(shù)字化體系的應(yīng)用實(shí)踐

◆李鶴群 王 丹/ 文

基于CMMI及DevOps的軟件開發(fā)及管理數(shù)字化體系的應(yīng)用實(shí)踐

◆李鶴群 王 丹/ 文

CMMI模型在國內(nèi)軟件開發(fā)行業(yè)的普及，旨在不斷提升軟件開發(fā)質(zhì)量，提高開發(fā)效率。然而，由于缺少行之有效的CMMI部署解決方案，使得流程文檔過于泛濫，度量數(shù)據(jù)收集分析工作量大等問題日益凸現(xiàn)。文中作者結(jié)合親身實(shí)踐及DevOps的概念，介紹了如何將CMMI模型部署到軟件開發(fā)和管理系統(tǒng)中，從而確保模型有效落地實(shí)施的實(shí)踐。

CMMI；DevOps；軟件開發(fā)及管理體系；數(shù)字化

1 引 言

自2002年CMMIv1.1發(fā)布以來，CMMI模型的應(yīng)用和認(rèn)證在軟件開發(fā)行業(yè)內(nèi)成燎原之勢不斷發(fā)展。其中CMMI-DEV模型的應(yīng)用最為廣泛，2014～2017年SEI的官方數(shù)據(jù)[1]顯示，中國通過CMMI3級(jí)的軟件企業(yè)有2528家，通過高成熟度CMMI4及CMMI5級(jí)的軟件企業(yè)有353家，而全世界通過認(rèn)證的國家共有5747家，僅中國就占50%。雖然通過了CMMI3級(jí)甚至高成熟度等級(jí)的評(píng)估，CMMI-DEV模型在國內(nèi)軟件企業(yè)的應(yīng)用仍然存在很多問題，在汽車電子軟件開發(fā)行業(yè)中更加明顯。問題主要體現(xiàn)在：

（1）流程文檔過多過濫；

（2）流程復(fù)雜，執(zhí)行效率低，人工流轉(zhuǎn)等待時(shí)間長；

（3）度量數(shù)據(jù)的收集及分析工作量大；

（4）CMMI的四大領(lǐng)域（工程、支持、組織、項(xiàng)目管理）涉及開發(fā)、質(zhì)量及PMO等多個(gè)組織，協(xié)同性差；

（5）軟件行業(yè)人員流動(dòng)率高，導(dǎo)致重復(fù)的培訓(xùn)、評(píng)估和改進(jìn)活動(dòng)，增加了許多成本。

總之，CMMI定位為精細(xì)化管理，需要過程、交付、量化數(shù)據(jù)來支撐，如果僅依賴人員檢查、海量的Excel文件匯總，勢必導(dǎo)致技術(shù)人員抵觸，CMMI的優(yōu)勢無法發(fā)揮，因此構(gòu)建一套使CMMI真正落地實(shí)施的IT解決方案是汽車行業(yè)亟待解決的難題。本文以作者所在公司的實(shí)際實(shí)踐為例，介紹CMMI3的落地實(shí)施IT解決方案的開發(fā)過程。

2 DevOps概念

DevOps是一組過程、方法與系統(tǒng)的統(tǒng)稱，如圖1[2]所示，它用于促進(jìn)開發(fā)（應(yīng)用程序/軟件工程）、項(xiàng)目管理和質(zhì)量保障（QA）部門之間的溝通、協(xié)作與整合。從實(shí)現(xiàn)上來講，DevOps通過構(gòu)建全生命周期的工具鏈，打通工程開發(fā)過程之間的溝通壁壘，減少線下文檔的管理，實(shí)現(xiàn)自動(dòng)化、跨團(tuán)隊(duì)的線上協(xié)作開發(fā)。通過實(shí)現(xiàn)流程的自動(dòng)化、度量數(shù)據(jù)的自動(dòng)化收集、分析功能，從而減少度量數(shù)據(jù)收集和分析工作，同時(shí)實(shí)現(xiàn)CMMI的精細(xì)化管理。

3 運(yùn)用DevOps概念設(shè)計(jì)lT解決方案

3.1 功能梳理

圖1 DevOps概念

CMMI3共包含18個(gè)過程域，各個(gè)過程域之間有著緊密的聯(lián)系和功能重疊，如果逐一通過工具實(shí)現(xiàn)，必然會(huì)產(chǎn)生冗余功能及過多接口。因此，開發(fā)CMMI落地的IT解決方案的首要任務(wù)就是梳理這些過程域，識(shí)別可以合并或優(yōu)化的過程域，整合為幾個(gè)大的功能，作為IT解決方案的需求。本次開發(fā)不包括供應(yīng)商管理（SAM）過程域、組織培訓(xùn)管理（OT）過程域。根據(jù)DevOps的概念，將CMMI3的其余16個(gè)過程域歸類劃分為三大類（工程領(lǐng)域、過程領(lǐng)域、管理領(lǐng)域）共計(jì)10項(xiàng)功能，其具體功能描述，實(shí)現(xiàn)的CMMI過程域[3]以及所屬DevOps領(lǐng)域的對(duì)應(yīng)關(guān)系如下表所示。

圖2 功能梳理

3.2 系統(tǒng)架構(gòu)設(shè)計(jì)

基于DevOps的概念，設(shè)計(jì)系統(tǒng)的架構(gòu)。從項(xiàng)目管理、工程開發(fā)、質(zhì)量管理三大領(lǐng)域應(yīng)用入手，針對(duì)梳理的十大系統(tǒng)功能，構(gòu)建工程開發(fā)縱向集成、項(xiàng)目管理及質(zhì)量管理橫向集成的兩條工具鏈，如圖2所示。

縱向打通工程開發(fā)全生命周期，包括需求、設(shè)計(jì)、開發(fā)、編譯、構(gòu)建、測試、打包、發(fā)布、配置的工具集成。DevOps強(qiáng)調(diào)的重點(diǎn)是跨工具鏈的「自動(dòng)化」。例如，針對(duì)集成編譯活動(dòng)，傳統(tǒng)的方式是通過編寫冗長的集成編譯手冊(cè)，在每個(gè)開發(fā)階段手工完成編譯、排錯(cuò)、集成、打包、測試的重復(fù)工作，但在基于DevOps開發(fā)的平臺(tái)下，通過預(yù)先設(shè)置編譯參數(shù)，包括編譯對(duì)象、編譯環(huán)境選擇、編譯時(shí)機(jī)等，實(shí)現(xiàn)數(shù)字化的“集成編譯手冊(cè)”，不僅方便工程師理解，而且可以通過系統(tǒng)實(shí)現(xiàn)全自動(dòng)執(zhí)行，整個(gè)過程可被追蹤和審計(jì)，不僅解決了CMMI模型要求的文檔留證問題，而且執(zhí)行效率大大提升。

表：功能梳理及對(duì)應(yīng)關(guān)系表

橫向打通開發(fā)、管理、質(zhì)量保證等多個(gè)“組織”的壁壘。DevOps強(qiáng)調(diào)的重點(diǎn)是跨團(tuán)隊(duì)的線上協(xié)作，也就是通過IT系統(tǒng)，實(shí)現(xiàn)信息的實(shí)時(shí)精確傳遞。傳統(tǒng)的SQA檢查方式，可能是通過一個(gè)冗長的Checklist來執(zhí)行，包括對(duì)所有開發(fā)過程和開發(fā)產(chǎn)品是否執(zhí)行、是否按照正確的過程執(zhí)行、是否輸出正確的結(jié)果、是否經(jīng)過正確的評(píng)審等多個(gè)檢查項(xiàng)開展質(zhì)量保證活動(dòng)。通過橫向集成，很多過程已經(jīng)部署在基于DevOps開發(fā)的平臺(tái)上，流轉(zhuǎn)的工作流完全參照組織的CMMI3級(jí)軟件開發(fā)過程模型定制，工作產(chǎn)物的模板也定制在平臺(tái)中，并且規(guī)定了其中的必填項(xiàng)要素，大大節(jié)省了SQA過程和產(chǎn)品檢查以及溝通的時(shí)間。

圖3為基于DevOps概念的系統(tǒng)架構(gòu)設(shè)計(jì)[4]。應(yīng)用層通過界面化的形式實(shí)現(xiàn)計(jì)劃的編制及監(jiān)控、需求的開發(fā)、追溯、集成、測試用例開發(fā)及管理，以及強(qiáng)大的報(bào)表功能供項(xiàng)目經(jīng)理、QA以及工程師從不同視角關(guān)注項(xiàng)目的進(jìn)度、質(zhì)量、風(fēng)險(xiǎn)等狀況；控制層為具體的功能實(shí)現(xiàn)邏輯，工作流根據(jù)組織的相關(guān)過程定義定制開發(fā)，合并重復(fù)工作項(xiàng)，并實(shí)現(xiàn)部分文檔的電子化；數(shù)據(jù)層包含過程庫（過程定義、模板、指南、檢查單等）、復(fù)用庫（軟件復(fù)用組件、測試用例等）、項(xiàng)目經(jīng)驗(yàn)教訓(xùn)庫、度量數(shù)據(jù)庫（包括組織過程能力績效數(shù)據(jù)、KPI等）以及組織風(fēng)險(xiǎn)庫，所有的數(shù)據(jù)供控制層調(diào)用，返回到應(yīng)用層進(jìn)行展示及各種操作；最底層為基礎(chǔ)開發(fā)平臺(tái)層，包括郵件服務(wù)、持續(xù)集成服務(wù)、自動(dòng)化測試相關(guān)的服務(wù)等，用于支撐整個(gè)系統(tǒng)的運(yùn)行。

3.3 解決方案的實(shí)現(xiàn)

目前行業(yè)內(nèi)有較多實(shí)現(xiàn)上述解決方案的工具，例如Requistitepro，IBM的基于Jazz平臺(tái)的集成產(chǎn)品（Doors、RTC等）以及RDM等。下文介紹以Doors及RTC為基礎(chǔ)開發(fā)平臺(tái)實(shí)施的解決方案的具體落地實(shí)例。

3.3.1 項(xiàng)目集成管理的實(shí)現(xiàn)

將PDCA的管理思想部署到系統(tǒng)中，實(shí)現(xiàn)如圖4所示的功能。項(xiàng)目經(jīng)理在系統(tǒng)中進(jìn)行資源分派、任務(wù)分派以及制定項(xiàng)目計(jì)劃，并可以通過項(xiàng)目緯度查看計(jì)劃的開展情況；工程師則在系統(tǒng)中提交交付物、填寫工時(shí)，并可通過個(gè)人緯度查看個(gè)人任務(wù)的開展情況。在監(jiān)控環(huán)節(jié)，項(xiàng)目經(jīng)理通過系統(tǒng)提供的豐富的報(bào)表功能（如圖5所示），實(shí)現(xiàn)對(duì)進(jìn)度、缺陷、風(fēng)險(xiǎn)以及變更等執(zhí)行情況的全面監(jiān)控；QA則通過度量數(shù)據(jù)對(duì)項(xiàng)目過程執(zhí)行情況進(jìn)行監(jiān)控和分析，以便及時(shí)指出過程執(zhí)行中存在的問題并制定糾正措施，從而對(duì)計(jì)劃作出科學(xué)調(diào)整。

圖3 系統(tǒng)架構(gòu)

圖4 系統(tǒng)的集成管理功能

3.3.2 需求追溯的實(shí)現(xiàn)

傳統(tǒng)的需求追溯是通過表格來實(shí)現(xiàn)的。工程開發(fā)下游對(duì)上游的需求及設(shè)計(jì)進(jìn)行逐一追溯跟蹤，容易遺漏，導(dǎo)致變更追蹤出錯(cuò)。通過在系統(tǒng)中建立需求到設(shè)計(jì)、編碼、測試的關(guān)聯(lián)關(guān)系，系統(tǒng)自動(dòng)生成如圖6所示的需求追溯一覽，需求變更路徑清晰可見，省去了維護(hù)表格的大量人工工作量且避免出錯(cuò)。

3.3.3 持續(xù)集成的實(shí)現(xiàn)

結(jié)合工程開發(fā)的實(shí)際需求，系統(tǒng)部署了持續(xù)集成及測試功能。基于系統(tǒng)集成的配置管理功能，持續(xù)集成功能的實(shí)現(xiàn)相對(duì)容易。如圖7所示，集成服務(wù)器選用開源工具Jenkins，目前有很多通過Jenkins部署持續(xù)集成工作的指南和案例可供參考。基于CMMI3與DevOps概念的軟硬件開發(fā)及管理數(shù)字化系統(tǒng)也借鑒了Jenkins的部署經(jīng)驗(yàn)[5]。但是在測試部署的時(shí)候，融入了組織特有的測試方法及測試設(shè)備，包括與系統(tǒng)中測試用例管理庫的銜接等。

圖5 豐富的報(bào)表功能

圖6 需求追溯一覽

圖7 持續(xù)集成

4 結(jié) 語

借鑒DevOps的縱橫雙向集成的概念，將CMMI模型對(duì)軟件開發(fā)過程質(zhì)量的要求部署到可執(zhí)行的系統(tǒng)中，不僅實(shí)現(xiàn)了軟件開發(fā)和管理工作的自動(dòng)化、智能化，減少文檔的管理，提升流程執(zhí)行的效率和效果，而且系統(tǒng)通過自動(dòng)采集的度量數(shù)據(jù)分析反饋到過程改進(jìn)中，進(jìn)一步完善開發(fā)流程，形成良性的改善環(huán)，從而引導(dǎo)CMMI模型在企業(yè)的真正落地實(shí)施。

[1]CMMI I nstitute P ublished Appraisal Results (2014-2017), https://sas.cmmiinstitute.com/pars/ pars.aspx.

[2]WikiPedia, DevOps. https:// en.wikipedia.org/wiki/DevOps.

[3]CMMI Product Team, CMU/ SEI-2010-TR-033-2010. CMMI for Development, Version 1.3[S].

[4]肖威. 基于CMMI-DEV三級(jí)的中小軟件企業(yè)項(xiàng)目管理系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)[D]. 天津大學(xué),2015:48-50.

[5]韓金儒. 基于持續(xù)集成的DevOps系統(tǒng)核心模塊的設(shè)計(jì)與實(shí)現(xiàn)[D].北京大學(xué),2014:16-17.

(作者單位：泛亞汽車技術(shù)中心有限公司)