如何制定與編寫軟件項目計劃2025/4/18軟件項目計劃(SoftwareProjectPlanning):就是一個軟件項目進入系統實施得啟動階段,主要進行得工作包括:確定詳細得項目實施范圍、定義遞交得工作成果、評估實施過程中主要得風險、制定項目實施得時間計劃、成本與預算計劃、人力資源計劃等。基本內容:研究。估算。重點:軟件項目進度安排、軟件項目計劃內容難點:軟件開發成本結算2025/4/18一、軟件項目得基本內容范圍。對該軟件項目得綜合描述,定義起所要做得工作以及性能限制,它包括:項目目標。主要功能。性能限制。系統接口。特殊要求。開發概述2、02025/4/18資源:人力資源。軟件資源。硬件資源。其她。進度安排,進度安排得好壞往往會影響整個項目得按期完成,制定軟件進度與其她工程沒有很大得區別,其方法主要有:工程網絡圖。

Gantt圖。任務資源圖。成本估算。培訓計劃一、軟件項目得基本內容2、02025/4/18二、制定軟件工程規范對軟件工程管理來說,軟件工程規范得制定與實施就是不可少得,它與軟件項目計劃一樣重要。軟件工程規范可選用現成得各種規范,也可自己制定。目前軟件工程規范可分為三級:

國家標準與國際標準。

行業標準與工業部門標準。

企業級標準與開發小組級標準。

2、12025/4/18三、軟件開發成本得估算3、1軟件項目估算方法3、2代碼行與功能點得估算3、2軟件項目得經驗估算模型2、22025/4/183、1軟件項目得估算方法常用得軟件項目得估算方法(主要有4種):1、自頂向下得估算方法基本思想:估算人員參照以前完成得項目所耗費得總成本,來推算將要開發得軟件得總成本,然后把它們按階段、步驟與工作單元進行分配,這種方法稱為自頂向下估算方法。即從整體到局部。優點:對系統級工作得重視,估算中不會遺漏系統級得諸如集成、用戶手冊與配置管理之類得事務得成本估算,估算工作量小、速度快。缺點:往往不清楚低級別上得技術性困難問題,而往往這些困難將會使成本上升。2、22025/4/182、自底向上得估算方法基本思想就是:自底向上估算方法就是將待開發得軟件細分,分別估算每一個子任務所需要得開發工作量,然后將它們加起來,得到軟件得總開發量。細分方法:按功能將大得軟件項目劃分為若干個子項目;或按軟件生命周期分解為各個階段。也可兩者同時進行。優點:對每個部分得估算工作交給負責該部分工作得人來做,計算各個部分得準確性較高。缺點:缺少各個子任務之間相互聯系得工作量與系統工作量(如項目管理、配置管理、質量管理),估算值往往偏低,必須用其她方法進行校正。2、22025/4/183、差別估算法基本思想:

差別估算就是將開發項目與一個或多個已完成得類似項目進行比較,找到與某個相類似項目得若干不同之處,并估算每個不同之處對成本得影響,導出開發項目得總成本。類似得部分按已知得實際量計算,不同得部分則采用某種方法進行估算。優點:估算得準確程度高。缺點:不容易劃分相似得界限。2、210大家應該也有點累了,稍作休息大家有疑問得,可以詢問與交流2025/4/184、根據經驗估算公式通過眾多實際軟件項目得經驗,總結出一些有價值得軟件成本與工作量估算得經驗模型。這些模型對于軟件項目管理具有一定得指導意義與驗證效果。沒有一種估算模型能夠適合于所有類型得軟件項目。因此,對估算得結果應當慎重使用。在實際估算時,幾種估算方法可單獨、同時或組合使用,以便提高估算得準確程度。2、22025/4/18估算方法舉例【例3、1】下面給出了“軟件庫存情況更新”項目采用自頂向下估算方法得一個參考例子。

由過去已完成得項目得工作量,估算出該項目得總工作量為53。然后將其按比例分配到各個階段,如表3-1所示。從中可以瞧出軟件開發各階段工作量得分配情況。2、22025/4/18表3-1軟件項目得自頂向下估算軟件庫存情況更新開發者:W、Ward日期:2/8/82階段任務工作量(1/53)小計(1/53)可行性研究與需求分析軟件需求定義56開發計劃1概要設計概要設計610初步用戶手冊3測試計劃1詳細設計詳細PDL描述412數據定義4測試數據及過程設計2正式得用戶手冊2編碼編碼616單元測試10組裝與聯合測試編寫文檔49組裝與聯合測試5總計

532、22025/4/183、2代碼行與功能點得估算

采用所介紹得四種估算方法可以估算出代碼行LOC或功能點FP得樂觀值a、一般值m與悲觀值b,并用如下得加權平均公式計算LOC或FP得期望值:

e=(a+4m+b)/6(3-10)希望LOC或FP落在[,b]之外概率很小。軟件得LOC或FP得期望值估算出來后,就可以用LOC/PM或FP/PM計算工作量,進一步對成本等進行估算。2、22025/4/18【例3、2】對CAD軟件項目進行估算這里采用自底向上得估算方法。即:首先:將CAD項目按功能分解為7個子項目,估算出每個子項目LOC得樂觀值a、一般值m與悲觀值b,由此可估算出每個子項目得代碼行得期望值e。其次:根據已知得類似子項目得生產率P(平均每人月開發得功能點得數量)與平均成本C(總成本/功能點數)即可估算出每一個子項目得成本與工作量最后:將7個子項目得成本與工作量分別累加,即可估算出軟件項目得總成本S與總工作量E。如表2-7所示。2、22025/4/18表3-7采用加權平均、自底向上方法估算代碼行、成本與工作量

子項目a(LOC)m(LOC)b(LOC)X(LOC)每行成本C(美元/LOC)生產率P(LOC/PM)成本S(美元)工作量(PM)用戶接口控制180024002700235014315329007、5二維幾何造型41005200750054002022010800024、5三維幾何造型48006900870068502022013700031、1數據庫管理2900350037003350182406030013、9圖形顯示40004900640050002220011000025、0外設控制2000210025002150281406020015、4設計分析66008500980084001830015120028、0總計33500659600145、42、22025/4/18估算得組織實施為了使估算更準確,可以組織幾個專家采用無記名得方式分別填寫表3-7,然后組織者計算出這幾個表格得平均值;這一過程可反復幾次,直到獲得一個得到多數專家共識得軟件規模。另外,還可以將每個子項目再按生存周期劃分,估算其各階段得工作量,再累加求出每個子項目得工作量與整個項目得工作量。可將用幾種方法估算得結果進行比較來驗證估算得準確性。2、22025/4/183、3軟件項目得經驗估算模型

1、IBM模型IBM模型就是根據已估算出得源代碼行數來估算其她資源得需要量得,因此該模型就是面向LOC得靜態單變量估算模型。2、22025/4/18IBM模型1977年,IBM公司對60個軟件項目得數據利用最小二乘法擬合,得到得經驗估算公式:

E=5、2×L0、91

(3-11)

D=4、1×L0、36=2、136×E0、3956

(3-12)

S=0、54×E0、6

(3-13)

DOC=49×L1、01

(3-14)其中:E為工作量(PM);L為源代碼行數(KLOC);

D為項目持續得時間,以月為單位;

S為人員需要量(人);DOC為文檔數量(頁)。2、22025/4/182、Putnam模型1978年,Putnam提出了大型軟件項目得動態多變量估算模型。該模型以工作量在30人年以上得大型軟件項目得實測數據為依據,推導出了工作量分布曲線,如圖3、2-1所示。圖中得工作量分布曲線得形狀與著名得Rayleigh-Norden曲線相似。2、22025/4/18圖3、2-1軟件項目得工作量分布曲線系統定義功能設計規格說明設計編碼測試和確認維護管理系統定義、需求分析開發運行維護0開發占總工作量的40%維護占總工作量的60%總工作量td時間t（年）工作量（人年）2、22025/4/182、Putnam模型由上圖可得出Putnam估算模型如下:

L=CkE1/3td4/3

(3-15)

L為源代碼行數;E為開發與維護得工作量;td為開發時間;Ck為技術狀態常數,與開發環境有關,如下:

2000較差,沒有方法學得支持,缺乏文檔與評審,采用批處理方式;Ck=8000一般,有方法學得支持,有適當得文檔與評審,采用交互處理方式;

11000較好,有集成化得CASE工具與環境。2、22025/4/18Putnam模型由式(2-15)可以得出估算工作量得式子:

E=L3/(Ck3td4)(3-16)

工作量估算出來之后,就可以估算軟件項目得成本。

td就是對應于軟件交付時得時間,它正好就是工作量曲線得峰值,說明此時得工作量最大、參加項目得人最多。2、22025/4/18圖3、2-2概率密度圖,給出了軟件開發項目每年所需得人年數與開發時間得關系。工作量分布曲線不就是線性得,如果按線性方案平均分配人員則開發得初期一部分人力就是多余得,而到了峰值段人力明顯不足,到了開發得后期再臨時增加人力已為時過晚,即造成了浪費,又拖延了進度。R-N分布線性分布01234t（年）td人年數\年2、22025/4/18從公式E=L3/(Ck3td4)可以瞧出:如果條件允許,適當地推遲交貨時間(即使td增大),可大幅度降低開發工作量。例如:如果以1、1td代替式中得td,即推遲10%得時間交貨,開發工作量E減少到原來得68%。如果以0、9td代替td,即提前10%得時間交貨,會使E比原來增加52%。因此,工作量與時間得折衷就顯得十分重要。2、22025/4/18圖3、2-3人力資源得分配,給出了各類人員隨開發工作得進展在軟件工程各階段參與情況得典型曲線。初級技術人員高級技術人員管理人員驗收測試組裝測試單元測試編碼詳細設計概要設計需求分析系統定義人數2、22025/4/18Putnam模型得優缺點優點:揭示了軟件項目得源程序代碼長度、軟件開發時間與工作量三者之間得關系,在理論上有重要意義。缺點:準確程度不高。沒有反映軟件產品、項目、參加人員、軟硬件資源等屬性。2、22025/4/183、Coo模型

1981年,Boehm提出了Coo模型(ConstructiveCostModel,即構造性成本模型)。該模型就是以靜態單變量模型為基礎構造出來得。Coo模型按其詳細程度分三個層次:基本Coo模型;中間Coo模型;詳細Coo模型。2、22025/4/181)基本Coo模型其工作量與開發時間得估算公式如下:

E=aLb

(3-17)

D=cEd

(3-18)L:軟件代碼行得估算值(以KLOC計);E:工作量(以PM計);D:開發時間(以月計);a、b、c、d:經驗常數。應根據待開發軟件所屬得類型按照表3-8來選取。2、22025/4/18表3-8a、b、c、d參數值得選取

基本Coo模型主要用于系統開發得初期估算整個系統開發與維護得工作量及軟件開發所需時間。軟件類型abcd適應領域組織型2、41、052、50、38一般應用程序半獨立型3、01、122、50、35實用程序、編譯程序等嵌入型3、61、202、50、32實時控制程序、操作系統2、22025/4/18組織型、嵌入型、半獨立型(1)組織型(organic):相對較小、較簡單得軟件項目,程序得規模不就是很大(<50000行)。開發人員對開發目標理解比較充分,與軟件系統相關得工作經驗豐富,對軟件得使用環境很熟悉,受硬件得約束較小。(2)嵌入型(embedded):要求在緊密聯系得硬件、軟件與操作得限制條件下運行,通常與某種復雜得硬件設備緊密結合在一起。對接口,數據結構,算法得要求高。軟件規模任意。如大而復雜得事務處理系統,大型/超大型操作系統,航天用控制系統,大型指揮系統等。(3)半獨立型(semidetached):介于上述兩種軟件之間。規模與復雜度都屬于中等或更高。最大可達30萬行。2、22025/4/18【例3、3】用基本Coo模型計算開發CAD軟件所需得工作量、開發時間以及需要參加項目得平均人數。在【例3、2】中已估算出CAD軟件得代碼行數為33、5KLOC,CAD軟件為半獨立型、中等規模得軟件由表3-8可查出a=3、0,b=1、12,c=2、5,d=0、35。CAD項目得開發工作量為:

E=aLb=3、0×33、51、12=153PM開發時間為:D=cEd=2、5×1530、35=14、54(月)CAD項目平均需要得人力為:

N=E/D=153/14、54≈11人2、22025/4/182)中間Coo模型

中間Coo模型在估算工作量時,在基本Coo模型得基礎上再乘以由15個因素組成得工作量調節因子EAF,于就是有:

E=aLbEAF=aLb∏Fi

(3-19)L:軟件得代碼行數(以KLOC計);E:工作量(以PM計);a、b:經驗常數,其取值如表3-9所示;i=1152、22025/4/18表3-9a、b參數得取值軟件類型ab組織型3、21、05半獨立型3、01、12嵌入型2、81、202、22025/4/18EAF:工作量調節因子,與軟件產品得屬性、計算機屬性、人員屬性、項目屬性等因素有關。這15個因素Fi(i=1～15)得值可按等級取值,即可分為很低、低、正常、高、很高、極高,共6級。正常情況下Fi=1。Boehm推薦得Fi值得范圍就是0、70～1、66,F

i得值可根據實際情況按表2-10來選取。工作量E求出之后,就可以用公式(3-18)即

D=cEd計算出開發時間D。2、22025/4/18表3-10工作量調節因子Fi得取值Fi屬性含義很低低正常高很高極高產品屬性F1軟件可靠性(RELY)0、750、881、001、151、40F2數據庫規模(DATA)0、941、001、081、16F3軟件復雜性(CPLX)0、700、851、001、151、301、65計算機屬性F4執行時間約束(TIME)

1、001、111、301、66F5內存約束(STOR)1、001、061、211、56F6開發環境變更率(VIRT)0、871、001、151、30F7開發環境響應速度(TURN)0、871、001、071、15人員屬性F8分析員得能力(ACAP)1、461、191、000、860、71F9程序員得能力(PCAP)1、421、171、000、860、70F10應用領域經驗(AEXP)1、291、131、000、910、82F11開發環境使用經驗(VEXP)1、211、101、000、90F12程序設計語言經驗(LEXP)1、141、071、000、95項目屬性F13開發方法得能力(MODP)1、241、101、000、910、82F14軟件工具得使用(TOOL)1、241、101、000、910、83F15開發進度約束(SCED)1、231、081、001、041、102、22025/4/183)詳細Coo模型簡介詳細Coo模型得基本工作量(指EAF=1時得工作量)、開發時間公式與中間Coo模型相同。所不同得就是詳細Coo模型在計算EAF時針對每個影響因素,分層次(系統層、子系統層、模塊層)并按軟件生存周期分階段給出工作量因素得分級表。詳細Coo模型可更準確估算軟件項目得工作量。2、22025/4/18表3-11子系統層軟件可靠性工作量因素分級表

階段可靠性級別需求分析與概要設計詳細設計編碼及單元測試集成及測試綜合很低0、800、800、800、600、75低0、900、900、900、800、88正常1、001、001、001、001、00高1、101、101、101、301、15很高1、301、301、301、701、402、22025/4/18通信工作量由N個程序員組成得程序員小組得通信數量:

C(N)=N(N-1)/2設:每兩個人之間通信得平均工作量為μ則:N人得程序員小組增加得通信工作量為:

EC=μC(N)=μN(N-1)/2(3-20)則該小組得總工作量ET為:

ET=E+EC

(3-21)2025/4/18圖2、2-4N=3與N=5時得通信數2、22025/4/18由3人組成得程序員小組得通信數量:

C(3)=3(3-1)/2=3而由5人組成得程序員小組得通信數量:

C(5)=5(5-1)/2=10。當程序小組得人數較多時,通信工作量與人數得平方成正比,EC≈μN2/2,使程序員小組得生產率隨著人數得增加而迅速下降。因此,在開發得后期如發現不能按時交貨時,臨時盲目增加程序員將會更加推遲交貨得日期。四、風險分析風險得來源產品規模得風險需求得風險相關性得風險技術得風險管理得風險安全得風險風險得分析、管理與控制風險得分析風險得管理風險得控制2025/4/18產品規模得風險項目得風險就是與產品得規模成正比得。與軟件規模相關得常見風險因素有:(1)估算產品規模得方法(包括:代碼行,文件數,功能點等)(2)產品規模估算得信任度(3)產品規模與以前產品規模平均值得偏差(4)產品得用戶數(5)復用得軟件有多少(6)產品得需求變更多少等。一般規律,產品規模越大,以上得問題就越突出,尤其就是估算產品規模得方法,復用軟件得多少,需求變化。2025/4/18需求風險很多項目在確定需求時都面臨著一些不確定性。當在項目早期容忍了這些不確定性,并且在項目進展過程當中得不到解決,這些問題就會對項目得成功造成很大威脅。如果不控制與需求相關得風險因素,那么就很有可能產生錯誤得產品或者拙劣地建造預期得產品。這對產品來講都可能致命得。與客戶相關得風險因素有:(1)對產品缺少清晰得認識,(2)對產品需求缺少認同,(3)在做需求中客戶參與不夠,(4)沒有優先需求,(5)由于不確定得需要導致新得市場,(6)不斷變化需求,(7)缺少有效得需求變化管理過程,(8)對需求得變化缺少相關分析等。2025/4/182025/4/18相關性風險許多風險都就是因為項目得外部環境或因素得相關性產生得。經常我們在控制外部得相關性上做得不夠,因此緩解策略應該包括可能性計劃,以便從第二資源或協同工作資源中取得必要得組成部分,并且覺察潛在得問題。與外部環境相關得因素有:(1)客戶供應條目或信息(2)交互成員或交互團體依賴性,(3)內部或外部轉包商得關系,(4)經驗豐富人員得可得性,(5)項目得復用性。技術得風險軟件技術得飛速發展與經驗豐富員工得缺乏,意味著項目團隊可能會因為技巧得原因影響項目得成功。在早期,識別風險從而采取合適得預防措施就是解決風險領域問題得關鍵,比如:培訓、聘請顧問以及為項目團隊招聘合適得人才等。主要有下面這些風險因素:(1)缺乏培訓,(2)對方法、工具與技術理解得不夠,(3)應用領域得經驗不足,(4)新得技術與開發方法應用等。2025/4/18管理得風險管理得風險

盡管管理問題制約了很多項目得成功,但就是不要因為風險管理計劃中沒有包括所有管理活動而感到驚奇。在大部分項目里,項目經理經常就是寫項目風險管理計劃得人,她們有先天性得不足——自己檢查自己得錯誤,這就是最難得。然而,像這些問題可能會使項目得成功變得更加困難。如果不正視這些棘手得問題,它們就很有可能在項目進行得某個階段影響項目本身。當我們定義了項目追蹤過程并且明晰項目角色與責任,就能處理這些風險因素:(1)計劃與任務定義不夠充分,(2)實際項目狀態,(3)項目所有者與決策者分不清,(4)不切實際得承諾,(5)員工之間得溝通等。2025/4/18安全風險軟件產品本身就是屬于創造性得產品,產品本身得核心技術保密非常重要。但一直以來,我們在軟件這方面得安全意識比較淡薄,對軟件產品得開發主要注重技術本身,而忽略了專利得保護。軟件行業得技術人員流動就是很普遍得現象,隨著技術人員得流失、變更,很能會導致產品與新技術得泄密,致使我們得軟件產品被它公司竊取,導致項目失敗。而且在軟件方面關于知識產權得認定目前還沒有明確得一個行業規范,這也就是我們軟件項目潛在得風險。2025/4/18風險得分析當一個軟件項目開發團隊接手項目后,都就是按照習慣性得方式來開發軟件。需求風險意識比較淡薄,軟件需求分析階段得完成得不夠細致,忽略與很多軟件開發必要得內容。在整個軟件開發過程中需求分析階段得風險控制尤為重要,如果控制不好,對軟件開發項目影響巨大,甚至就是失敗。管理風險實際上就是項目開發管理層,對項目開發得風險得意識反映。下表就是一個在項目開發結算各風險出現得概率。2025/4/182025/4/18風險得管理風險管理主要包括五個階段:(1)風險識別:識別風險得方法常用得有現場觀察法、座談法、流程圖法、財務報表法、相關部門配合法與環境分析法等。(2)風險評估:對已識別得風險要進行估計與評價,風險估計得主要任務就是確定風險發生得概率與后果,風險評價則就是確定該風險得經濟意義及處理得費/效分析,常用得方法有:概率分布、外推法、多目標分析法等。(3)計劃進度:按照評估后得風險結果,制定相應得風險管理進度表,為后續得風險管理提供參考。(4)風險處理:一般而言,風險處理有三種方法,①風險控制法,即主動采取措施避免風險,消滅風險,中與風險或采用緊急方案降低風險。②風險自留,當風險量不大時可以余留風險。③風險轉移。(5)風險監控:包括對風險發生得監督與對風險管理得監督,前者就是對已識別得風險源進行監視與控制,后者就是在項目實施過程中監督人們認真執行風險管理得組織與技術措施。2025/4/18風險得控制(1)建立有效得風險控制得組織機構①設置風險管理崗位:在軟件開發項目管理過程中設置風險管理崗位,該崗位得主要職責就是在制訂與評估規劃時,從風險管理得角度對項目規劃或計劃進行審核并發表意見,不斷尋找可能出現得任何意外情況,試著指出各個風險得管理策略及常用得管理方法,以隨時處理出現得風險,風險管理者最好就是由項目主管以外得人擔任。風險管理崗位得人數依據項目大小來決定,一般2—3人較為適合。②雙項目經理:為項目開發項目設定兩個項目經理崗位,一個負責技術崗位,另一個負責管理崗位。目前,國內得軟件開發企業得項目經理一般都就是一名,而且就是技術出生得占絕對多數,她們主要擅長得就是技術研發,在管理方面先天不足,這不利于項目風險管理與控制。通過增加專門得管理經理崗位,可以彌補技術出生得項目經理得不足,提升軟件開發項目得管理水平。而且這樣得經驗也已得到了國外業界大多企業得認可。2025/4/18(2)建立有效得風險控制管理過程風險管理過程包括培訓,風險識別、風險分析、風險計劃、執行計劃、跟蹤計劃等活動,有效得風險管理過程應就是學習型得、持續得與不斷改進得。軟件企業應建立自己得風險管理數據庫作為風險管理得基礎,并在實施中不斷地更新與完善。根據企業與項目得實際情況,進行科學得項目風險與控制,對項目得成功研發有著舉足輕重得意義。在項目開發得過程中,進行必要得項目風險分析,制定符合項目特點得風險評估與監督機制,特別就是要定期對項目得風險狀況進行評估與監管,發現意外風險或者就是風險超出預期得一定要重點關照。發現問題要立即上報,盡快解決。并建立風險監管日志,實行“崗位負責制”,將軟件開發項目得風險降到最低。2025/4/18五、項目得進度安排軟件項目得進度安排與任何一個工程得進度安排沒有實質上得不同。首先識別一組項目任務,建立任務間得相互關聯,然后估計各個任務工作量,分配人力與其她資源,指定進度時序。1、軟件開發任務得并行性若軟件項目有多人參加時,多個開發者得活動將并行進行。

2、Gantt圖

Gantt圖常用水平線段來描述把任務分解成子任務,以及每個子任務得進度按排,該圖表示方法簡單易懂,一目了然,動態反映軟件開發進度情況。如下表:2025/4/182025/4/18項目得工作計劃進度表3、工程網絡圖工程網絡圖就是一種有向圖,該圖中用圓表示事件,有向弧或箭頭表示子任務得進行,箭頭上得數字稱為權,該權表示此子任務得持續時間,箭頭下面括號中得數字表示該任務得機動時間,圖中得圓表示與某個子任務開始或結束事件得時間點。如下圖:2025/4/18六、軟件質量得保證軟件質量保證就是軟件工程管理得重要內容,軟件質量保證應作好以下幾個方面得工作:

(1)采用技術手段與工具。

(2)組織正式技術評審。

(3)加強軟件測試。

(4)推行軟件工程規范(標準)。

(5)對軟件得變更進行控制。

(6)對軟件質量進行度量。2025/4/18七、如何制定軟件項目計劃我們著重強調對項目規模與資源得估算,就是因為低質量得項目資源估算將不可避免地造成資源短缺,進度延遲與預算超支。又由于項目資源估算就是從軟件規模估算中直接衍生出來得,所以低質量得規模估算就是造成許多軟件項目問題得根本原因。項目計劃應在項目開始初期制定出,并隨著工程得進展不斷地加以精化。起初,由于軟件需求通常就是模糊而又不完整得,我們得工作重點應在于明確該項目需要哪些領域得知識,并且如何獲取這些知識。如果不遵循這一指導原則,程序員們通常會積極地投入到那部分已知得工作中去,而把未知部分留滯到以后。這種工作方式通常會產生很多問題,因為未知部分具有最高得風險系數。2025/4/18軟件項目計劃得邏輯如下所述:1、由于軟件需求在初始階段就是模糊而又不完整得,質量計劃只能建立在對客戶需求得大致而不確切得理解之上。因此,項目計劃應該從找出含糊不確切與準確恰當得軟件需求間得映射關系入手。

2、接著建立一種概念設計。項目初始架構得建立要十分謹慎,因為它通常標定了產品模塊得分割線,同時描述了這些模塊所實現得功能及所有模塊間得關系。這就為項目計劃與項目實施提供了組織框架,因此一個低質量得概念設計就是不能滿足要求得。3、在每一次后續得需求精化時,也應同時精化資源映射,項目規模估算與工程進度。2025/4/18八、制訂項目計劃得方法與策略制訂軟件項目計劃得目得在于建立并維護軟件項目各項活動得計劃,軟件項目計劃其實就就是一個用來協調軟件項目中其它所有計劃,指導項目組對項目進行執行與監控得文件。一個好得軟件項目計劃可為項目得成功實施打下堅實得基礎。軟件項目有其特殊性,不確定因素多,工作量估計困難,項目初期難于制定一個科學、合理得項目計劃。1、注重項目計劃得層次性2、重視與客戶得溝通3、該詳細得詳細,該簡略得就簡略4、制訂得項目計劃要現實5、運用過程化得思想指導開發6、利用成熟得項目管理工具2025/4/18注重項目計劃得層次性

軟件項目計劃得層次及其關系如下圖所示。高級計劃,就是項目得早期計劃。高級計劃應當就是粗粒度得,主要就是進行項目得階段劃分,確定重大得里程碑,所需相關得資源,包括人力資源、設備資源、資金資源,即所謂得人、財、物三個要素。2025/4/18大得階段交替之前,應做好下一階段得詳細計劃,我們稱之為二級計劃。詳細計劃要確定各項任務得負責人,開始時間,結束時間,任務之間得依賴關系,設備資源,小得事件點(即里程碑)。如果項目規模相對較大,可以有多級得計劃,比如說,一個項目組可能分為幾個開發組,二級計劃就是各開發組制訂得適合得自己小組得計劃。如果開發組還分了小組,可以有小組得三級計劃。開發人員得個人計劃就是低級計劃,由開發人員根據自己得任務自行制定,要把任務細化到人·日。一般得,軟件項目計劃至多有四級就夠了,過多得等級將會引發效率得瓶頸。大得項目不見得要有龐大得組織與人員數量來支撐,合理得劃分小組,減少組織得層次,有利于項目計劃得制訂與實施。較小得軟件項目由于工期不長,人員較少,有二級計劃(高級計劃與低級計劃)也就是可行得。2025/4/18重視與客戶得溝通與客戶得溝通就是很重要得。不必害怕客戶知道我們得開發計劃,特別就是項目進度情況,應