CMM認證是當今IT界最熱的話題之一，這表明中國軟件企業已開始重視與軟件項目管理有關的問題了。為了了解國內軟件企業對軟件項目管理的認識程度以及他們在軟件項目管理方面的具體做法，日前，記者采訪了開思、東方通、瑞星三家純軟件公司的相關負責人。三家公司中，東方通業已開始按照CMM規范進行軟件開發。在采訪中，三家公司的負責人分別介紹了各自企業在軟件項目管理方面的經驗。開思公司的產品總監石宏峰先生還為記者詳細講解了開思公司的《產品部開發規范》。
經過整理，我們將東方通和瑞星兩家公司的負責人在采訪中所說的主要內容刊登于此。我們相信，其具有一定的認識價值。另外，我們將開思公司《產品部開發規范》的一部分也刊登于此——我們并不認為開思的規范就是最好的規范。對軟件項目管理而言，普適性是不存在的，好壞是相對的，適用不適用才是絕對的——我們相信，其具有一定的參照價值�！�
加強相關教育和培訓
朱律瑋（東方通科技首席軟件設計師）
楊樺（東方通科技總經理助理）
東方通科技從去年底開始為參加CMM認證（二級）做準備。擬議中正式參評的時間是今年11月。在這之前我們會請國內咨詢公司的有關專家和國外的評估師進行兩次預評估。
半年多來，我們覺得一切還算順利。起初我們擔心編程人員會有抵觸情緒——因為每完成一天的工作或一道工序或一個項目后都要做記錄、編文檔、寫報告，較之以前，工作量無疑是增加了——后來看看，大家對執行CMM規范還是理解的、支持的。
按照CMM規范開展工作后，到目前為止，公司的運營成本是增加了——因為要增加管理人員、撰寫文檔也需要人手——但從長遠看，其會帶來降低成本、提高質量、提高用戶滿意度等好處。對此，我們確信不疑。
與國外相比，我們在軟件工程管理方面的差距不僅表現為管理體制、管理方法、管理思想的陳舊，整個軟件業的落后才是根源。
個人英雄主義情結、喜歡單打獨斗是我們的民族性之一，其在軟件人才身上表現得尤為明顯，已成為中國軟件企業做大的一個瓶頸。造成這種狀況的原因，除了國內軟件業的發展水平不高、軟件項目規模不大和軟件企業管理者自身素質不高外，還有很重要的一點，即與軟件工程管理有關的教育內容幾乎沒有。在國外，PSP和GSP均為軟件專業學生的必修課，可在國內，這兩門課在學校里至今還沒有開起來。國外施行的是定崗培訓，比如撰寫文檔就是一門專業課，專門有人修它，畢業后拿它來“安身立命”，國內則是大家過獨木橋，統統都學寫程序。應該說，目前國內同行對軟件工程管理的重要性已有了一定的認識，但在相關人員的培訓上下的力氣仍遠遠不夠。
其實人才才是最關鍵的�，F在軟件業最缺的人才之一就是產品經理，他們是軟件工程管理的主角。產品經理必須具備以下素質：具有長期的軟件開發經驗——般來講，要在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 項目組織
每個項目指定一個項目經理進行管理，同時指定一個分析、設計人員（來自分析設計組）負責對技術問題的管理。當任務涉及到多個職能組的工作時（有些項目可能只涉及單一的職能組），由項目經理根據項目工作安排與職能組的組長進行協調，由職能組的組長來協助安排本組承擔的項目工作，指定組內人員來完成相關工作。項目經理根據各職能組長的安排匯總編制整個項目的進度計劃，并根據最終形成的項目計劃對項目進行控制和管理。
項目進行過程中需按照項目管理的要求對項目進行跟蹤、總結，各職能組的人員要對這些工作給予積極的支持和配合。產品委員會（或產品部內部）不定期組織人員對項目進行審查，確保項目的進度和質量。
項目完工后需要由產品委員會組織對項目進行驗收。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
