軟件開發(fā)過程大觀——軟件開發(fā)過程改進(jìn)為什么能幫助軟件質(zhì)量提升？

?

軟件發(fā)展的二個典型趨勢

1、軟件規(guī)模日益擴(kuò)大。類似摩爾定律，功能類似的軟件系統(tǒng)的規(guī)模大約每18個月翻一番，每5年，功能類似的軟件系統(tǒng)的規(guī)模擴(kuò)大為原來系統(tǒng)的10倍。

2、軟件在整個系統(tǒng)中的比重日益增加。20世紀(jì)60年代，F-4戰(zhàn)機(jī)中，由軟件來完成的功能約占整體功能的8%，21世紀(jì)，F-22戰(zhàn)機(jī)中，由軟件來支持的功能則達(dá)到了整體功能的80%

以上趨勢使得軟件軟件質(zhì)量問題越來越突出。

軟件規(guī)模日益擴(kuò)大，使得軟件越來越難做；軟件比重的日益增加，使得軟件質(zhì)量問題的影響越來越廣泛和嚴(yán)重。

軟件開發(fā)項(xiàng)目經(jīng)常陷入包括軟件質(zhì)量不佳、項(xiàng)目進(jìn)度延期、成本超支、客戶不滿……等等的“焦油坑”。

在傳統(tǒng)行業(yè)，質(zhì)量管理和企業(yè)管理方面的經(jīng)驗(yàn)和理論表明，產(chǎn)品的質(zhì)量取決于過程的質(zhì)量。

用工程化的思想來管理軟件開發(fā)，借鑒傳統(tǒng)行業(yè)在質(zhì)量管理方面的經(jīng)驗(yàn)，可以在一定程度上緩解上述問題。

軟件工程，是研究以一種高效的方式提供高質(zhì)量軟件產(chǎn)品的工程學(xué)科。

?

軟件開發(fā)過程的發(fā)展歷史

20世紀(jì)50年代，沒有成熟的程序設(shè)計(jì)語言，軟件開發(fā)需要直接面對硬件環(huán)境。

20世紀(jì)60年代，軟件作坊（Softwarecrafting）誕生。

軟件開發(fā)的特殊性被發(fā)現(xiàn)：

1、軟件可以復(fù)制。不需要昂貴的生產(chǎn)線就可以復(fù)制軟件。

2、軟件比硬件容易修改。由此形成了“Codeand fix”的開發(fā)方法。

但軟件隨意的修改，也帶來了嚴(yán)重的隱患：軟件的演化更加隨意，跟蹤困難，最終形成了類似意大利式面條的局面（“一團(tuán)糟”）。

此期間也形成了倡導(dǎo)自由精神的黑客文化和牛仔風(fēng)格的牛仔式程序員（他們采用急速而草率的方式，可以連續(xù)通宵達(dá)旦的連續(xù)工作多天，在截至日期前完成存在很多缺陷的代碼）。

?

20世紀(jì)70年代，形式化方法與瀑布過程。

程序編碼應(yīng)該更加精心的組織，在設(shè)計(jì)之前，需要經(jīng)過更加仔細(xì)的需求工程。

形式化方法，在可伸縮性和易用性方面存在很多困難。

?

20世紀(jì)80年代，生產(chǎn)率和可伸縮性。

在過程標(biāo)準(zhǔn)方面的投入，可以減少軟件開發(fā)過程的返工，顯著提高軟件生產(chǎn)率。

美國國防部DoD與CMU聯(lián)合成立了? SEI來制定過程標(biāo)準(zhǔn)。

?

20世紀(jì)90年代，并發(fā)過程和順序過程。

關(guān)注產(chǎn)品上線時間，導(dǎo)致并發(fā)過程的興起，并行工程的風(fēng)險(xiǎn)帶來風(fēng)險(xiǎn)驅(qū)動的螺旋模型。

1991年，SEI發(fā)布CMM1.0; 1993年，SEI發(fā)布CMM1.1。

CMM針對組織級的軟件過程標(biāo)準(zhǔn)粒度較粗，還需要考慮更小的組織單位，即個人軟件過程（PSP）和小組軟件過程（TSP）。

SEI在CMM基礎(chǔ)上，進(jìn)一步提煉組織級軟件過程改進(jìn)的一般性理論框架，發(fā)布了IDEAL模型。IDEAL模型就像是傳統(tǒng)行業(yè)質(zhì)量管理的PDCA模型在軟件行業(yè)的推廣，是一種比較通用的理論框架。

?

2000年，敏捷方法，基于價值的方法

敏捷方法，如自適應(yīng)軟件開發(fā)、Crystal方法、動態(tài)系統(tǒng)開發(fā)、XP、FDD、Scrum等

基于價值的方法，低風(fēng)險(xiǎn)高動態(tài)變化的，適用于輕量級的敏捷開發(fā)方法，高風(fēng)險(xiǎn)低變更（固定）的，適用于規(guī)范化的計(jì)劃驅(qū)動的方法。

2000年，SEI發(fā)布了CMMI1.0，2010年，發(fā)布了CMMI1.3.

?

2010年，DevOps的出現(xiàn)，方法、工具、技術(shù)上引發(fā)了一些新的變化。

精益方法（lean Development）是支撐DevOps的理論基礎(chǔ)。

DevOps的開發(fā)工具集和整體解決方案的出現(xiàn)。

虛擬化的平臺技術(shù)如云計(jì)算、容器，微服務(wù)架構(gòu)，自動化技術(shù)

?

PSP(Personal Software Process)

一種個人級用于控制、管理和改進(jìn)工程師個人工作方式的持續(xù)改進(jìn)過程。

包括數(shù)據(jù)記錄表格、過程操作指南、規(guī)程

PSP過程度量包括：

1、度量時間

2、度量缺陷

3、度量規(guī)模

過程質(zhì)量的度量指標(biāo)包括：

1、Yield，度量每個階段在消除缺陷方面的效率。

（1）Phase Yield，表示某個階段缺陷消除的效率。

（2）Process Yield，表示在第一次編譯前消除缺陷的效率。

2、A/FR，Appraisal toFailure Ratio，質(zhì)檢失效比。A/FR=質(zhì)檢成本/失效成本。

A/FR用于指導(dǎo)工程師合理安排評審和測試時間。A/FR越高，質(zhì)量越高，也意味著過多的評審。

3、PQI，Process QualityIndex，過程質(zhì)量指標(biāo)。用于度量PSP過程的整體質(zhì)量。

4、Review Rate，評審的速度。用戶指導(dǎo)工程師開展有效評審的指標(biāo)。

統(tǒng)計(jì)表明，代碼評審速度小于200代碼行（LOC）/小時，文檔評審速度小于4頁（Page）/小時，就可以保證工程師有效的發(fā)現(xiàn)足夠多的缺陷。

?

TSP(Team Software Process)

一種小組級用于控制、管理和改進(jìn)小組工作方式的持續(xù)改進(jìn)過程。

?

過程改進(jìn)參考模型和標(biāo)準(zhǔn)

1、CMM

過程控制和過程管理的方法。可用于軟件過程改進(jìn)、過程評估、軟件能力評價。

18個關(guān)鍵過程域。

2、CMMI

整合了三個模型。

25個關(guān)鍵過程域。

3、SPICE(Software ProcessImprovement and Capability Determination)，軟件過程改進(jìn)和能力鑒定標(biāo)準(zhǔn)。軟件過程評估國際標(biāo)準(zhǔn)。

4、ISO/IEC 15504，軟件過程評估標(biāo)準(zhǔn)，是SPICE的演化。

5、ISO/IEC 12207，軟件生命周期過程標(biāo)準(zhǔn)。

6、ISO 9000

?

2017-12-14

--------------------------------------

總結(jié)

以上是生活随笔為你收集整理的软件开发过程大观——软件开发过程改进为什么能帮助软件质量提升？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。