| 導購 | 订阅 | 在线投稿
分享
 
 
 

軟件項目管理(CMM)經驗談

來源:互聯網  2008-06-01 02:25:51  評論

(張鳳岐2001年07月04日 (電腦商報)

編者按:

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項目組織

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

項目進行過程中需按照項目治理的要求對項目進行跟蹤、總結,各職能組的人員要對這些工作給予積極的支持和配合。産品委員會(或産品部內部)不定期組織人員對項目進行審查,確保項目的進度和質量。

項目完工後需要由産品委員會組織對項目進行驗收。

(張鳳岐 2001年07月04日 (電腦商報) 編者按: 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 項目組織 每個項目指定一個項目經理進行治理,同時指定一個分析、設計人員(來自分析設計組)負責對技術問題的治理。當任務涉及到多個職能組的工作時(有些項目可能只涉及單一的職能組),由項目經理根據項目工作安排與職能組的組長進行協調,由職能組的組長來協助安排本組承擔的項目工作,指定組內人員來完成相關工作。項目經理根據各職能組長的安排彙總編制整個項目的進度計劃,並根據最終形成的項目計劃對項目進行控制和治理。 項目進行過程中需按照項目治理的要求對項目進行跟蹤、總結,各職能組的人員要對這些工作給予積極的支持和配合。産品委員會(或産品部內部)不定期組織人員對項目進行審查,確保項目的進度和質量。 項目完工後需要由産品委員會組織對項目進行驗收。
󰈣󰈤
王朝萬家燈火計劃
期待原創作者加盟
 
 
 
>>返回首頁<<
 
 
 
 
 熱帖排行
 
 
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有