軟體專案管理（CMM）經驗談——附錄《產品部開發規範》

編者按：
CMM認證是當今IT界最熱的話題之一，這表明中國軟體企業已開始重視與軟體專案管理有關的問題了。為了瞭解國內軟體企業對軟體專案管理的認識程度以及他 們在軟體專案管理方面的具體做法，日前，記者採訪了開思、東方通、瑞星三家純軟體公司的相關負責人。三家公司中，東方通業已開始按照CMM規範進行軟體開 發。在採訪中，三家公司的負責人分別介紹了各自企業在軟體專案管理方面的經驗。開思公司的產品總監石巨集峰先生還為記者詳細講解了開思公司的《產品部開發規 範》。

經過整理，我們將東方通和瑞星兩家公司的負責人在採訪中所說的主要內容刊登於此。我們相信，其具有一定的認識價值。另外，我們將開思公司《產品部開發規 範》的一部分也刊登於此——我們並不認為開思的規範就是最好的規範。對軟體專案管理而言，普適性是不存在的，好壞是相對的，適用不適用才是絕對的——我們 相信，其具有一定的參照價值。　


加強相關教育和培訓

朱律瑋（東方通科技首席軟體設計師）

楊樺（東方通科技總經理助理）　　　

東方通科技從去年底開始為參加CMM認證（二級）做準備。擬議中正式參評的時間是今年11月。在這之前我們會請國內諮詢公司的有關專家和國外的評估師進行 兩次預評估。

半年多來，我們覺得一切還算順利。起初我們擔心程式設計人員會有牴觸情緒——因為每完成一天的工作或一道工序或一個專案後都要做記錄、編文件、寫報告，較之以 前，工作量無疑是增加了——後來看看，大家對執行CMM規範還是理解的、支援的。

按照CMM規範開展工作後，到目前為止，公司的運營成本是增加了——因為要增加管理人員、撰寫文件也需要人手——但從長遠看，其會帶來降低成本、提高質 量、提高使用者滿意度等好處。對此，我們確信不疑。

與國外相比，我們在軟體工程管理方面的差距不僅表現為管理體制、管理方法、管理思想的陳舊，整個軟體業的落後才是根源。

個人英雄主義情結、喜歡單打獨鬥是我們的民族性之一，其在軟體人才身上表現得尤為明顯，已成為中國軟體企業做大的一個瓶頸。造成這種狀況的原因，除了國內 軟體業的發展水平不高、軟體專案規模不大和軟體企業管理者自身素質不高外，還有很重要的一點，即與軟體工程管理有關的教育內容幾乎沒有。在國外，PSP和 GSP均為軟體專業學生的必修課，可在國內，這兩門課在學校裡至今還沒有開起來。國外施行的是定崗培訓，比如撰寫文件就是一門專業課，專門有人修它，畢業 後拿它來“安身立命”，國內則是大家過獨木橋，統統都學寫程式。應該說，目前國內同行對軟體工程管理的重要性已有了一定的認識，但在相關人員的培訓上下的 力氣仍遠遠不夠。

其實人才才是最關鍵的。現在軟體業最缺的人才之一就是產品經理，他們是軟體工程管理的主角。產品經理必須具備以下素質：具有長期的軟體開發經驗——般來 講，要在8年以上；瞭解使用者的需求；對產品熟、對市場熟——他可以不瞭解一個產品的底層技術，但必須瞭解其功能，能把握其發展方向；具有協調能力。總之， 產品經理並不一定非常聰明，並不需要在某一方面特別突出，但要八面玲瓏。這樣的人才太難找了。東方通的產品經理都是自己培養的。

CMM規範並非只適用於大型軟體企業，其也適用於中小型企業。CMM規範只是一個框架、綱要性質的東西。企業在落實它時要細化一次；企業將其落實到具體的 某個專案時，要再細化一次；中小企業可以不像大型企業那樣將CMM規範細化得那麼細，夠用就好，不要教條。

實施CMM規範、通過CMM認證有如下一些好處：確定工作流程和方式，從而使產品的質量和開發的可延續性有了保證；可以提高企業在使用者中的信譽度，增加企 業與強勢公司競爭的籌碼；可以承接國際大公司的外包專案———美國公司願意找印度公司來承接其外包專案，就是因為印度公司對CMM規範普遍比較重視，通過 CMM認證的軟體企業也多；公司不再受制於人，人走了，事照做，這是一個公司成熟的表現。


軟體商業化的必要手段

談文明（北京瑞星科技股份有限公司研發部經理）

中國軟體產業發展時間不長，雖然已有部分技術達到國際水平，但由於商業環境還不夠完善，在軟體技術的商業化與軟體工程管理等方面，與國際同行相比，還存在 差距。

只有率先將技術先進的產品推向市場的公司才會贏得利潤。在瑞星，技術商品化已被當作一種制度，它有助於提高整個企業的素質。

瑞星意識到在充滿競爭的環境中要獲得成功，天才人物是必不可少的，但他們並不是全部。目前，一個軟體工程的成功更多地要依靠科學家、工程師、製造人員和銷 售人員的協同努力。

在軟體商業化的過程之中，建立規範化的易於操作的軟體開發行為規範是首先要做的工作。針對防毒軟體的特點，瑞星專門設計了瀑布模型結合增量模型的開發方 式，即將專案分階段來實現。首先實現市場最需求的核心功能，然後在此基礎上繼續開發，每個單獨的階段都採用瀑布模型的開發方式。

具體地說，一個基本的軟體開發流程包括需求階段、系統設計階段、詳細設計階段、編碼階段、單元測試階段、整合測試階段、系統測試階段、軟體釋出軟體維護階 段。其中決定軟體開發成功與否的關鍵階段是：軟體需求管理、軟體計劃管理、軟體質量管理和軟體配置管理。

為了在使用者和處理使用者需求的軟體專案組之間達成共識（使用者由終端使用者、高層領導、銷售人員和市場調查人員組成），“軟體需求規格說明書”是必不可少的。經 過正式的評審和確認，其將成為後續工作的基礎。

軟體專案的實施過程是根據軟體專案的資源、約束條件和執行能力確定的，因此需要制定合理的軟體工程管理計劃，這是專案經理的職責之一。專案經理應定期檢查 “專案開發計劃書”，按照當前專案開發的實際情況，對其進行調整。

為了保證每一個軟體產品都合乎需求，需要設立一個負責專案監督和協調的SQA。其會對軟體產品是否符合定義好的軟體過程中的相應部分進行審查、複審和測 試。公司高層主管應該定期參與、評審SQA的活動。

軟體配置管理是指在整個工程期間對專案的所有軟體配置項進行規範化管理。如採用版本控制軟體對軟體配置項版本進行版本控制，採用基線管理方法對變化進行控 制，即在遵循軟體工程標準的基礎上對整個軟體進行控制和管理，維護其完整性、一致性和可跟蹤性。

瑞星努力營造的是一個廣泛的網路，研發、製造、銷售、分銷和服務，連續進行。圍繞著產品、市場和開發階段而不是單純的技術來組織各項工作。為了這個目的， 標準操作是必不可少的。


附錄：開思公司《產品部開發規範》　（摘要）

說明：第一部分為《目錄》，從中可以看出開思公司《產品部開發規範》的整體架構；第二部分為《開發規範概述》，從中可以看出開思公司在軟體專案管理方面的 一些具體做法。

1　　目　錄

1　目的

2　開發規範概述

2．1　應用專案管理管理開發過程

2．2　標準的階段性開發工作

2．2．1　總體規劃

2．2．2　專案立項

2．2．3　需求分析

2．2．4　系統分析

2．2．5　系統設計

2．2．6　編碼實現

2．2．7　專案測試

2．2．8　文件製作

2．2．9　專案驗收

2．2．10　專案版本化釋出

2．3　專案組織

3　開發工作規範

3．1　總體規劃階段

3．1．1　專案需求報告

3．1．1．1　工作定義

3．1．1．2　前序工作及輸入成果

3．1．1．3　具體工作內容

3．1．1．3．1　資料收集（可選）

3．1．1．3．2　資料研究（可選）

3．1．1．3．3　專案需求報告編制

3．1．1．3．4專案需求報告討論準備

3．1．1．3．5　專案需求報告討論

3．1．1．3．6　專案需求報告修改

3．1．1．3．7　專案需求報告驗收

3．1．1．4　參與者及職責

3．1．1．5　輸出成果及後序工作

3．1．2　技術可行性實驗（可選）

3．1．3　專案計劃書

3．2　專案立項

3．2．1　立項申請

3．2．2　專案立項評估

3．2．3　專案進度計劃

3．2．4　專案立項審批

3．3　需求分析

3．3．1　資料收集

3．3．2　需求分析編制

3．3．3　討論準備

3．3．4　需求分析討論

3．3．5　需求分析修改

3．3．6　需求分析驗收

3．4　系統分析

3．4．1　系統分析準備

3．4．2　確定問題域

3．4．3　需求建模

3．4．4　建立分析物件模型

3．4．5　系統分析合併

3．4．6　系統分析測試

3．4．7　系統分析修改（測試後）

3．4．8　系統分析驗收

3．5　系統設計

3．5．1　系統設計準備

3．5．2　介面設計

3．5．3　建立設計模型

3．5．4　系統設計合併

3．5．5　物件持久化設計

3．5．6　詳細設計

3．5．7　系統設計測試

3．5．8　系統設計修改（測試後）

3．5．9　系統設計驗收

3．6　編碼實現

3．6．1　編碼準備

3．6．2　編碼

3．6．3　編碼單元測試（測試工作）

3．6．4　單元測試後編碼修改

3．6．5　編碼聯調

3．6．6　整合測試（測試工作）

3．6．7　整合測試後編碼修改

3．6．8　系統測試（測試工作）

3．6．9　系統測試後編碼修改

3．6．10　編碼驗收

3．7　專案測試

3．7．1　系統分析測試

3．7．2　系統設計測試

3．7．3　專案測試方案

3．7．4　單元測試

3．7．5　整合測試

3．7．6　系統測試

3．8　文件編制

3．8．1　開發文件整理

3．8．2　使用者文件編制

3．8．3　宣傳資料編寫

3．9　專案驗收

3．10　專案版本化釋出

4　專案工作總結

4．1　專案任務數

4．1．1　總任務數

4．1．2　階段任務數

4．2　輸出成果

2　　開發規範概述

2．1　應用專案管理管理開發過程

產品部接受的各種開發任務均以專案形式出現，包括：新產品開發，產品維護（錯誤修改、功能增強、缺陷完善等），產品客戶化開發及維護等，全程使用專案管理 方法進行控制和管理。

根據專案規模和難易有大、小，繁簡之分。每個專案的完成周期要控制在6個月以內，專案規模控制在60個人月內。過大的專案需要拆分成多個小的專案來完成。 30個人月以上的專案稱為大專案，10個人月以內的專案稱為小專案。

每個專案要根據具體情況拆分成工作階段，即里程碑，以便對專案進度的有效控制與檢測。

2．2　標準的階段性開發工作

2．2．1　總體規劃

全面規劃專案工作的內容，確定目標市場、技術指標和應用要求，劃定專案工作範圍和交付成果，明確專案實現的總體設想和實施方案；確定專案中的新技術的可行 性；明確專案需要用到的各種資源，估算專案的工作量和成本。

2．2．2　專案立項

產品部對要進行的開發專案進行立項申請，提交專案資料。由公司的有關人員對專案進行一系列的風險評估。

通過風險評估的專案，由產品部進行詳細進度計劃安排，落實時間進度、資源（人員／裝置、內部／外部）、技術、資金和費用等，相關資源和資金使用計劃要詳細 列出。

最後所有的專案申請資料、風險評估報告及產品進度計劃都要報給公司上級領導審批，進行立項評審。

立項通過的專案才能進入正式的開發工作。

2．2．3　需求分析

根據專案需求報告界定的工作範圍和應用方案的設計思路，進一步深入細化應用方案，描述將要開發出計算機系統中包含的各項業務是如何做的，及業務流程、相關 理論、運算公式、原理、業務資料、單據報表格式等。

2．2．4　系統分析

根據專案需求分析，對將要建立的滿足使用者需求的計算機系統進行分析。在系統分析過程中採用物件導向分析技術（OOA）劃分需求的問題域，對每一個問題域進 行分析和抽象，對其中的事物和它們之間的關係產生正確的認識，找出描述問題域及其系統責任所需的類及物件，定義這些類和物件的屬性與服務，以及它們之間所 形成的結構、靜態聯絡和動態聯絡。最終產生一個符合使用者需求，並能夠直接反映問題域和系統責任的物件導向的分析模型。

2．2．5　系統設計

根據專案需求分析和系統分析，針對具體實現中的人機介面、資料儲存、任務管理等內容，運用物件導向設計技術（OOD）進行系統設計。主要包括UI設計、對 象設計和資料庫表設計。

2．2．6　編碼實現

根據系統設計的結果，運用物件導向的方法進行程式編碼（OOP）以實現系統設計的內容。

編碼過程就是用具體的資料結構來定義物件的屬性，用具體的語言來實現服務流程圖所表示的演算法。在物件設計階段形成的物件類和關係最後被轉換成特殊的程式設 計語言、資料庫或者硬體的實現。

2．2．7　專案測試

對系統分析、系統設計、程式編碼等運用物件導向的方法進行測試（OOT）。專案的測試工作貫穿專案的整個開發過程。主要包括：分析（OOA）測試、設計 （OOD）測試和編碼（OOP）測試，以及整合測試和系統測試。

2．2．8　文件製作

跟隨專案開發過程應產生的文件主要包括三類：

（1）開發文件：分析、設計、編碼、測試以及各種開發管理文件等資料；

（2）使用者文件：線上幫助，安裝指南，使用手冊，技術手冊，培訓教材等；

（3）宣傳資料：產品介紹資料，產品白皮書，產品宣傳PPT，演示光碟等。

2．2．9　專案驗收

對完工的專案按照驗收步驟進行驗收。驗收過程中對專案的情況給予評價。

2．2．10　專案版本化釋出

對驗收通過的專案進行版本控制，整理專案版本包含的內容並版本化，釋出產品釋出通告。

2．3　專案組織

每個專案指定一個專案經理進行管理，同時指定一個分析、設計人員（來自分析設計組）負責對技術問題的管理。當任務涉及到多個職能組的工作時（有些專案可能 只涉及單一的職能組），由專案經理根據專案工作安排與職能組的組長進行協調，由職能組的組長來協助安排本組承擔的專案工作，指定組內人員來完成相關工作。 專案經理根據各職能組長的安排彙總編制整個專案的進度計劃，並根據最終形成的專案計劃對專案進行控制和管理。

專案進行過程中需按照專案管理的要求對專案進行跟蹤、總結，各職能組的人員要對這些工作給予積極的支援和配合。產品委員會（或產品部內部）不定期組織人員 對專案進行審查，確保專案的進度和質量。

專案完工後需要由產品委員會組織對專案進行驗收。