軟體過程改進

軟體過程改進，就是在軟體過程工程中為了更有效地達到最佳化軟體過程的目的同施的改善或改變其軟體過程的一系列活動。

基本介紹

• 中文名：軟體過程改進
• 外文名：Software Process improvement，SPI
• 簡稱：SPI

簡介

對於軟體企業來說，軟體過程是整個企業最複雜、最重要的業務流程，軟體產品就是軟體企業的生命，改進整個企業的業務流程，最重要的還是要改進它的軟體過程。多年以來，人們認識到要想高效率、高質量和低成本地開發軟體，必須以改善軟體生產過程為中心，全面開展軟體工程和質量管理手段。這是世界各國軟體產業都要走的路，中國軟體產業之所以落後，不是因為技術落後，而是對軟體生產的管理落後。CMM就是結合了質量管理和軟體工程的雙重經驗而制定的一套針對軟體生產過程的規範。由此可見，對軟體生產過程的管理在整個軟體企業的管理中起了決定性作用。因此，從這種意義上講，軟體企業的BPR和CMM軟體過程改進在實施對象是一致的。

軟體過程改進

在世界範圍內，軟體項目需求正以非常快的速度增長，並且這種增長看起來還遠未達到目的。這種增長已經導致軟體開發活動急劇性的增長，已使得對用於構築軟體的過程，正確的說法是軟體過程，得到更多的關注。軟體過程可以定義為人們用來開發和維護軟體以及相關產品（如：工程計畫、設計文檔、規章、檢測事例及用戶手冊）的一組活動、方法、實踐及轉換。軟體過程重要性的提高已經引起了對軟體過程改進的要求，這就需要過程分析和評估的方法。

原則

SPI的五條核心原則分別是：

1·注重問題 2·強調知識創新3 ·鼓勵參與 4·領導層的統一 5·計畫不斷地改進。

“問題的解決是過程改進的核心，實踐不僅是SPI組的目標也是它的起點。”這條原則為過程改進人員指明了目標，明確了方法。SPI就是要在實踐中發現軟體過程中的問題，並在實踐中尋找和找到解決問題的辦法，可以說過程改進就是在不斷發現問題和解決問題的過程中不斷向前發展。

軟體過程改進

“改進是一種知識的創新，SPI是受知識的驅動的”。這條原則強調了知識創新在SPI中的作用，提醒了SPI人員在注重知識創新的同時更要注重知識的傳播和擴散。

通常從事SPI工作的做法是，過程改進僅僅是過程改進人員的事情，其他人員只是被動地接受。而“合作促使改進產生”這條原則給予了我們很好的啟發和提示。它告訴我們，過程改進不僅僅是一個人或幾個人的事情，而是整個組織的事情。只有鼓勵大家都積極參與，讓這些人基於自身的經驗和職業的判斷力來實實在在地設計和開發新的過程，才能使設計出來的過程真正為他們所理解，為他們所用，從而實現過程的成功。這也是我們在過程改進工作中容易疏忽的地方。

“SPI的關鍵點在於改變軟體開發的方式。然而，改變人的行為並不是件容易的事。”這條原則分析了我們在這項工作中可能會遇到的困難和阻力，本書中也不忘為我們提供了如何克服這些問題的可行方法、建議和實例。

“改進必須是綜合了各個層次的人的力量。”SPI人員一定要保證SPI的目標與組織的整體目標是一致的，因為只有這樣才能保證SPI工作得到各個領導層的贊同、支持和投入，才能綜合利用各個層次的力量來推動SPI工作的前進。這是預防過程改進項目風險的重要手段。

“改進應該是一個不斷持續的過程。”這一原則進一步提示和告誡SPI人員一定要認識到改進的不斷持續的特性。到達頂點並不重要，關鍵的是，你現在處在一個上升??達一個目標你就創造了另一個更高的目標，這個目標對我們的過程和環境都具有重要的意義。

必要性

SPI的最根本利益其實在於，他能夠極大的提高項目成功的幾率，這是大家都追求的。當然需要明確定義這裡的“項目成功”的含義，不是客戶要求三個月完工，最後按時交工，就是成功。而是綜合平衡進度、交付後質量、成本等若干要素後所達到的最優狀態。 ；在項目管理三要素中，項目干係人通常會把進度當作第一目標，結果相當多趕進度完成的項目，在交付後面臨者大量的後續修改，甚至推翻重來。如果把這部分開銷算到項目中去，項目早已失敗的一塌糊塗了。

對大量失敗項目的統計結果表明，最大的原因在於缺乏過程或者沒有很好的遵循已定義的過程。我們知道決定項目質量和生產率的要素有人、技術和過程，如果借用木筒的比喻，過程不見得是其中最寬的一條，但是當前它是最短的，所以它決定著木桶的盛水量。我們迫切的需要SPI，就是要把最短的木條儘快補上去。

只有基於良好的過程，人和技術才能發揮出最大的威力。

框架

軟體過程改進的框架包括以下幾個組成部分：

(1)軟體過程基礎設施

它包含組織管理基礎設施和技術基礎設施，可為軟體過程改進的活動提供必要的條件和支持。

(2)過程改進路線圖

它應提供表明有效軟體過程特徵的模型，以及逐步達到有效軟體過程的途徑，軟體組織依靠路線圖的指引可以朝著有效軟體過程前進。事實上，CMM（軟體能力成熟度模型）和SPICE提供的成熟度等級都屬於這種路線圖。當然，軟體組織從自身的實際情況出發對這些模型所作的裁剪版本，只要是適用的也應看成是過程改進路線圖。

(3)軟體過程評估方法

它是評估軟體組織現行和現用的軟體過程、做法和基礎設施的方法和技術。評估通常要對照過程改進路線圖，評估的結果要能表明，從提高過程有效性方面看哪些是強項，哪些是弱項。改進措施應能導致過程成熟度沿著改進路線圖提高過程成熟度。過程評估方法可以是公開適用的標準方法，例如SEI評估方法即基於CMM估價的內部過程改進CBA—IPI(CMMfbased appraisal for internal process improvement)或BOOTSTARAP方法，也是按SPICE規定的準則進行內部評估。

(4)軟體過程改進計畫

評估後把發現的問題轉化為軟體過程改進的行動計畫。這包括為改進過程基礎設施以及提高其有效性必須採取的措施，過程改進應能使改進的過程規範化並提高過程的有效性。

改進方法

按照軟體工程化的原則和方法實施軟體過程管理是軟體行業快速發展的一個重要原因。在這裡，軟體過程改進是指對軟體過程管理進行不斷改進和完善的活動。它是一項綜合併且需要持續開展的活動，它所面對的既是軟體開發的過程模型，同時也是針對每一個具體軟體項目的過程實例。

根據過程改進的驅動方式(目的)的不同，可以將軟體過程改進劃分為目標驅動和缺陷驅動兩種方式。目標驅動的過程改進模式是指根據一個預定的目標，自頂而下制定過程評價和度量模型，有目的地開展相關改進活動的過程改進模式：缺陷驅動的過程改進模式是指根據實際產生的關於過程缺陷的反饋信息，進行有針對性的改進活動的過程改進模式。

目前軟體行業實行的軟體過程改進方法大多屬於以上兩種類型。

改進步驟

不斷改進軟體開發過程是軟體工程的基本原理之一。也就是說軟體過程需要不斷完善，從非工程化的軟體開發方式轉變為工程化的軟體開發方式，按照軟體工程的系統方法進行軟體的工程活動和管理活動，不斷完善軟體過程的各個環節，提高軟體過程能力。隨著軟體過程能力的提高，一個軟體機構在完成軟體產品時在預算、進度、產品質量方面的風險能夠不斷降低。

無論哪一種軟體過程改進方案的實施都要從已有的軟體過程開始，改進工作需經歷一系列步驟。過程改進的步驟需要反覆進行。

(1)過程分析

考察和理解現有的過程，在一些情況下需要對過程的某些環節進行度量和定量分析，利用取得的數據來表明過程的狀況。同時，這些數據可以用來與過程改進後的狀況進行對比。

(2)確定改進

利用過程分析的結果，找出原有過程中質量、進度和成本的瓶頸。針對發現的問題，制定過程改進方案，提出需要採用什麼規程、方法和工具的建議。

(3)過程變更

實施過程變更，把新的規程、方法和工具安置於合適的過程環節上，並且與其他的軟體過程活動集成起來。

(4)培訓

沒有培訓的過程變更在大多數場合注定要失敗。有的單位在培訓工作不夠充分的情況下，強制推行過程變更，這樣做不會收到好的效果。

(5)調整過程變更

在初步實施過程變更後，不可能立即收到圓滿的效果，在過程修改後還可能會出現一些小的問題，這就需要進行適當的調整。此外，同時引入太多的變更是不切實際的。