中小型軟件項目的一種過程管理模型

摘 要：軟件工程化的概念已提出多年，其發展已經進入成熟階段，但軟件項目的問題卻層出不窮。在根據實際工作中出現的問題，結合軟件工程中的幾種常用過程模型，融入過程管理的理念及要素，并借鑒敏捷開發思想，總結一套適用于中小型非軍方項目的過程管理模型；采用調查分析法、實踐法經過一年半的軟件開發實踐及過程管理實踐，得出一套這樣的過程管理模型。內部的QoD項目的開發數據證明該方法對于中小型軟件的有效性。模型的優點在于結合多種模型在中小型項目中的優勢。

關鍵詞：過程模型；代碼先行；顧客包含；功能性WBS；模塊性WBS

中圖分類號：TP311文獻標識碼：B文章編號：1004373X(2008)2008603

Development Management Process f_or Small and Medium Scale Non-military Software Project

ZHAO Yanfeng1，LIU Shiwei2

(1.Xi′an University of Finance Economics，Xi′an，710061，China;2.College of Software，Northwestern Polytechnical University，Xi′an，710065，China)

Abstract：The software engineering concept is put f_orward many years ago and has stepped into its mature phase.But increasing types of issue have emerged in software development engineer.According to the problem aroused in actual work，some of usually used software developing process，elements of process management and principles of agile development are combined.Goal of this paper is to find a set of software development process f_or small and medium scale non-military software projects.The investigation method and practice method are adopted during the past one and half years.Afterwords a model which satisfies our purpose is f_ound.Internal project QoD can prove the effiencecy of such model.The advantage of this model is many advantages of each process management model is combined in the small and medium scale software projects.

Keywords：process model;code first;customer-involved;functional WBS;modular WBS

1 引 言

軟件工程發展到現在，最缺的不是一個開發框架，而是真正的把某一個框架運用到實際當中去^［1］。然而，瀑布模型過于單向，處理變更比較困難；國標GB 8567-88的陳舊及數據的冗余有些不適合快速的項目開發；CMM的實施不菲的成本及靈活性差的特點把很多團隊拒之門外；V模型沒有加入對迭代的處理；RUP大量文檔及角色只學習就需要很多的時間，其所要求的剪裁又需要一定的實際項目管理經驗，諸多因素使得軟件過程的管理一直處于混亂之中。各種開發模型有各自的階段劃分方法和憂缺點，如何選擇和剪裁適合本團隊的開發過程是個普遍存在的問題。

本文就中小型項目的開發，結合瀑布模型及敏捷開發的思想，加之對RUP的理解，對軟件過程進行了一次適當的剪裁并加入了一些個人的觀點。本文所討論的軟件開發是針對外部項目，而非自主研發式的項目。

2 項目開發各階段的主要工作

2.1 項目定義階段

本階段的主要目標是確定本項目的名稱、范圍、利益相關方、風險、約束和經濟可行性等。

2.2 需求獲取階段

首先，當接到任何一個項目時，域分析是必要的步驟，這是以顧客為導向的項目的初始表征，因為聽不懂顧客的語言就跟本不可能深入了解顧客在各自專業內的需求。在這個階段可以采用把顧客加入到開發團隊中的做法，每天利用50%的時間與顧客進行溝通交流。剩余50%時間的主要工作，做出原型，并準備第二天要溝通的問題。每天是一個迭代的過程，直到把顧客本次要完成的需求記錄完善。

第二步則是對整體的需求進行分析，這種分析主要包括以下內容：

（1） 把顧客提出的需求進行歸納整理，并用顧客語言進行描述，確保無二義性。

（2） 分析有那些是顧客提出但不正確的條目。“需要不等于需求”，軟件項目工作者在與顧客一起工作的過程中如何有效地導出顧客需求，在需求過程中起到極其重要的作用。

（3） 對相應的過程提出改進建議。“沒有流程再造的IT不是真正的IT”，企業的機構經常調整，管理流程隨時有可能變化，這時有一個資深的企業管理咨詢專家將會給顧客的產品提供很高的附加值以及增加更多的無形利潤。

（4） 需求歸類，形成初步的功能性WBS(Work Breakdown Structures )，即按照功能模塊把需求分類，然后根據顧客提供的優先級進行初步的版本劃分，這也是在本階段第三步中要與顧客共同確定的項目主要里程碑之一。

第三步則把分析的結果反饋給顧客，共同確定好一套要實施的工作方案，此過程仍然為一個迭代過程，直到達到顧客滿意。此時可以簽署需求合同及相應的版本開發計劃。最后把所有的需求加入《顧客需求列表》

2.3 提出項目解決方案及計劃階段

本階段最終的目的是向顧客提供可供選擇的解決方案。每條解決方案至少應該包括，預計采用的軟件語言、參照的（網絡）協議、配套的硬件設施、該方案的緊急度、重要程度、優先度、易用性、可擴展性、實現復雜、技術難度等。每項可以按分數1~10逐步增強進行打分，在把每項加權系統相乘的結果累加。

理論上，希望把所有的解決方案都提交給顧客并進行討論，確定最終采用的方案。在實際運行中，往往是先把最好的一套方案拿給顧客，如果不能說服顧客同意，則根據顧客的關注焦點從剩余的方案中選擇，多套方案在競標中也是相當有益的。

在本階段進行的不僅是與顧客交流方案的選擇問題，還有一點很重要的是要根據已做好的計劃，參照顧客的時間表討論是否能在必要的時間參與到項目中。如每周進行一次細節上的需求確認及偏航糾正，這種會議是減小項目失敗可能性的一種較易現實的途徑。

2.4 設計階段

設計階段最重要的是要有經驗豐富的系統分析師及系統架構師。在設計階段可以采用結對設計的方式，融合眾人之長，設計一個易擴展的軟件框架。對已知的工作進行分解，做出模塊性WBS，并明確每個版本必須實現的功能。

設計所產生的文檔只需要記錄模塊之間的關系，而不需要過多地考慮繁瑣的細節，這也是下一個階段推薦敏捷開發的原因之一。對于項目的估算，建議采用功能點估算法，如圖1所示。

2.5 實現階段

實現階段最重要的就是按照本團隊的編碼規范進行編碼工作。作者建議在編碼階段采用結對編程的方法，采用每日站立會議、顧客故事、測試先行、代碼重構、代碼共有、每日集成的文法，在此期間，代碼的規范性是一定要保持，并應采取一定的監督機制^［2］。

本階段不建議采用大量的軟件過程文檔，而是采用“代碼說話”（code talk）的方法，這一方面取決于變量、方法的命名規范，即前面所提到的編碼規范；另外一方面，多用注釋以代替文檔，而只在文檔中記錄重要的模塊間及重要類之的相互關系，其他細節放在注釋中闡明，這樣就盡可能地減少了文檔與代碼之間的互相查找，也在最大程度上避免了代碼與文檔之間不匹配的問題。

另外，在模塊間相關代碼發生更改之后，要對設計中的文檔進行更新，此謂“先代碼，后文檔”。

在本階段要定期（每周）與顧客會面，對上一周所遇到的尚未討論的細節問題進行確定。此時，顧客可能會提出一些新的想法，這也就是主動“擁抱變化”，而非死扣合同^［2］。

伴隨著每日的集成，對于特定的內部版本需要進行內部測試，至少應每周1次，并記錄BUG出現的次數、級別、類別，并于下周會議上查看修復了多少，尚存多少沒有修復，記錄沒有修復的原因。以數據和事實說話，統計有多少BUG是在編碼時可以避免的，有多少是由于設計失誤等引起的返工。這些數據可以協助建立本組織的知識庫，這是屬于知識管理的一部分，在此不做深入討論。經過若干迭代，實現了第一版本中的所有需求后，α版已經可以發布。

2.6 顧客測試階段

對于顧客，很少會知道如何對軟件進行驗證測試，這時把測試團隊在開發階段寫的測試用例修改整理為顧客語言，就是一個很好的范本。把這個文檔提交給顧客，并指導顧客進行測試。另外，有些顧客也會擁有自己的測試團隊，他們會用自己的方式進行測試。如果通過，則β版可以準備發布。

在交付前還要提供給顧客相應的《顧客手冊》、《版本發布說明》，這也是產品交付時的必要部分，有時還需要根據顧客的要求或合同做相應的技術培訓。

2.7 維護階段

維護階段主要工作是對β版中沒有發現的BUG進行修改，并根據新的需求對系統進行升級。對于新的需求，要做的是從提出項目解決方案及計劃階段開始迭代執行此過程模型。如果是較大的調整或升級，則從需求獲取階段開始迭代執行此過程模型。

3 應用實例

作者應用此過程模型開發了QoD（Quality of Delivery）數據統計分析軟件，該項目屬于公司的內部管理軟件。在開發中，把如上過程框架應用到了實際工程中。結果如圖2所示：

（1） 由1.0α版當初的4條需求，發展到2.0β版的19條需求；

（2） 由項目初始時，項目提出者一人的支持，發展到2.0β版本12名顧客經常使用；

（3） 項目組共3人，采用瀑布模型的開發估算，項目周期8周，預計開發中產生5個新需求。采用本開發框架后，實際周期為5周，共 15個新需求。

4 結 語

本軟件開發過程模型，結合了很多軟件開發過程的特點，目的是最短時間內交付以顧客為中心的軟件產品。實際應用的統計數字證明，本項目僅在時間上就節約了37.5%，顧客需求導出度提升了200%，代碼返工率大大減小。在中小型項目的開發中起到了一定的增效劑作用。本軟件開發過程的重要里程碑和主要文檔列表如表1所示。

參考文獻

［1］Anon.The Mythical Man-Month ［M］．北京:清華大學出版社，2002．

［2］Laurie Williams.Pair Programming Illuminated ［M］．北京:清華大學出版社，2003．

［3］ISO9000-2000標準 ［S］．2002.

［4］Anon.Software Project Management-A Unified Framework ［M］．北京:清華大學出版社，2000．

［5］馮平鴿，楊民獻．軟件過程改進的CMM模型［J］．中小企業科技，2007(3):22-23.

［6］韓曉鴻，申艷光，張艷麗，等．探討CMM，PSP和TSP對軟件過程持續改進的意義和方法［J］．科技資訊，2007（4）：109.