軟體專案管理(CMM)經驗談(1)(轉)
編者按:
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 輸出成果
[@more@]
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 輸出成果
[@more@]
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7839396/viewspace-958441/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 軟體專案管理(CMM)經驗談(1) (轉)專案管理
- 軟體專案管理(CMM)經驗談(2) (轉)專案管理
- 軟體專案管理(CMM)經驗談(2)(轉)專案管理
- 軟體專案管理(CMM)經驗談——附錄《產品部開發規範》專案管理
- 軟體專案測試管理經驗談
- 談談軟體專案管理的重要性1(轉)專案管理
- 淺談專案管理軟體(轉)專案管理
- 我的軟體專案過程管理經驗(轉)
- 軟體專案管理原則談(轉)專案管理
- 專案管理經驗談:怎樣做專案計劃(轉)專案管理
- 談談軟體專案管理的重要性(轉)專案管理
- 我的軟體專案過程管理經驗
- 談談軟體專案管理的重要性2(轉)專案管理
- 談談軟體專案管理的重要性3(轉)專案管理
- 軟體開發專案管理經驗分享:專案全生命週期管理專案管理
- 小軟體專案的管理(經典轉載)
- Linus 談軟體開發管理經驗
- 專案管理經驗談——來自專案管理群的討論專案管理
- 《軟體專案經驗總結》
- 專案管理體制改革的經驗和成效(轉)專案管理
- 對軟體專案管理的探討(1)(轉)專案管理
- 專案管理經驗談——來自專案管理群的討論薦專案管理
- Linus Torvalds談軟體開發管理經驗
- ERP專案實施經驗談(轉)
- 工程專案經理部組織經驗談(轉)
- 解析軟體專案管理(轉)專案管理
- 軟體專案管理心得(轉)專案管理
- 外包專案的管理經驗交流(轉)
- 軟體專案質量管理(轉)
- 專案管理與軟體工程(轉)專案管理軟體工程
- 成功專案管理的20條經驗(轉)專案管理
- 來上課!專案管理全景沙盤演練經驗分享(內附專案管理軟體分析)專案管理
- 專案團隊管理的失敗經驗(轉)
- 多年來外包專案的管理經驗交流(轉)
- 微軟資深經理人的專案管理經驗(轉)微軟專案管理
- 魯布革工程的專案管理經驗(轉)專案管理
- 專案管理泛泛談(轉)專案管理
- 軟體專案管理如何避免“黑洞”(轉)專案管理