0軟件項(xiàng)目管理信息科學(xué)與工程學(xué)院軟件工程系崔煥慶2023/12/61RoadMap

項(xiàng)目結(jié)束

項(xiàng)目執(zhí)行控制

項(xiàng)目計(jì)劃

項(xiàng)目初始2023/12/62前情回顧項(xiàng)目立項(xiàng)階段甲方：招標(biāo)書、乙方選擇、簽署合同乙方：項(xiàng)目分析、競(jìng)標(biāo)、簽署合同項(xiàng)目章程：確認(rèn)項(xiàng)目存在的文件，包括對(duì)項(xiàng)目的確認(rèn)、對(duì)項(xiàng)目經(jīng)理的授權(quán)和項(xiàng)目目標(biāo)的概述等。生存期模型：瀑布、V、增量、原型、螺旋、漸近模型。3第二篇軟件項(xiàng)目計(jì)劃2023/12/64RoadMap

合同計(jì)劃

風(fēng)險(xiǎn)計(jì)劃

溝通計(jì)劃

人力計(jì)劃

質(zhì)量計(jì)劃

成本計(jì)劃

時(shí)間計(jì)劃

集成計(jì)劃范圍計(jì)劃

項(xiàng)目結(jié)束

項(xiàng)目執(zhí)行控制

項(xiàng)目計(jì)劃

項(xiàng)目初始5第2章范圍計(jì)劃2023/12/66為什么進(jìn)行范圍計(jì)劃？

做過(guò)項(xiàng)目的人可能會(huì)有這樣的經(jīng)歷：一個(gè)項(xiàng)目做了很久，感覺(jué)總是做不完，就像是一個(gè)無(wú)底洞。用戶總是有新需求要項(xiàng)目開(kāi)發(fā)來(lái)做，就像用戶在“漫天要價(jià)”，而開(kāi)發(fā)方在“就地還錢”。實(shí)際上，這里涉及一個(gè)“范圍管理”的概念。項(xiàng)目哪些該做，做到什么程度，哪些不該做，都是由“范圍管理”來(lái)決定的。缺乏正確的項(xiàng)目范圍界定是導(dǎo)致項(xiàng)目失敗的主要原因之一。項(xiàng)目管理中最重要也是最難做的就是確定項(xiàng)目范圍。2023/12/67

開(kāi)發(fā)軟件系統(tǒng)最為困難的部分就是準(zhǔn)確說(shuō)明開(kāi)發(fā)什么。

——弗雷德里克·布魯克斯2023/12/68什么是范圍管理1.什么是范圍？

產(chǎn)生項(xiàng)目產(chǎn)品所包括的所有工作及產(chǎn)生這些產(chǎn)品所用的過(guò)程。產(chǎn)品范圍界定——產(chǎn)品或服務(wù)范圍的特征和功能。工作范圍界定——項(xiàng)目工作的完成，為的是能交付一個(gè)有特殊特征和功能的產(chǎn)品。2.范圍管理

對(duì)項(xiàng)目包括什么和不包括什么的定義與控制過(guò)程。用于確保項(xiàng)目組和項(xiàng)目干系人對(duì)作為項(xiàng)目結(jié)果的項(xiàng)目產(chǎn)品以及生產(chǎn)這些產(chǎn)品所用到的過(guò)程，有一個(gè)共同的理解。2023/12/69本章要點(diǎn)一、關(guān)于軟件需求二、需求管理過(guò)程三、編寫需求規(guī)格的方法四、任務(wù)分解定義五、任務(wù)分解方法六、任務(wù)分解結(jié)果的檢驗(yàn)七、案例分析2023/12/610軟件需求的重要性

40%~60%的問(wèn)題是在需求分析階段埋下的隱患。40%的開(kāi)發(fā)總費(fèi)用是返工開(kāi)銷。70%~80%的返工是需求方面的錯(cuò)誤導(dǎo)致的。80%的失敗項(xiàng)目是需求分析不明確造成的。總之，好的需求管理是項(xiàng)目成功的第一位因素。采用需求管理可以給項(xiàng)目組帶來(lái)很多的好處，直至項(xiàng)目取得成功。2023/12/611項(xiàng)目失敗的原因分析No.

Top10Factors

平均值

1

Inadequaterequirementsspecification

4.5

2

Changesinrequirements

4.3

3

Shortageofsystemsengineers

4.2

4

Shortageofsoftwaremanagers

4.1

5

Shortageofqualifiedprojectmanagers

4.1

6

Shortageofsoftwareengineers

3.9

7

Fixed-pricecontract

3.8

8

Inadequatecommunicationsforsystemintegration

3.8

9

Insufficientexperienceasteam

3.6

10

Shortageofapplicationdomainexperts

3.6

Scale:5=VerySerious3=Serious1=NoSerious

Source:Carnegie-MellonUniversity,SoftwareEngineeringInstitute2023/12/612什么是軟件需求需求是指用戶對(duì)軟件的功能和性能的要求，就是用戶希望軟件能做什么事情，完成什么樣的功能，達(dá)到什么性能。正在構(gòu)建的系統(tǒng)必須符合的條件或具備的功能?！猂ational用戶解決某一問(wèn)題或達(dá)到某一目標(biāo)所需的軟件功能。系統(tǒng)或系統(tǒng)構(gòu)件為了滿足合同、規(guī)約、標(biāo)準(zhǔn)或其他正式實(shí)行的文檔而必須滿足或具備的軟件功能?！狹erlinDorfman、RichardH.Thayer2023/12/613軟件需求的層次業(yè)務(wù)需求表示組織或客戶高層次的目標(biāo)。業(yè)務(wù)需求通常來(lái)自項(xiàng)目投資人、購(gòu)買產(chǎn)品的客戶、實(shí)際用戶的管理者、市場(chǎng)營(yíng)銷部門或產(chǎn)品策劃部門。業(yè)務(wù)需求描述了組織為什么要開(kāi)發(fā)一個(gè)系統(tǒng)，即組織希望達(dá)到的目標(biāo)。使用前景和范圍文檔來(lái)記錄業(yè)務(wù)需求，這份文檔有時(shí)也被稱作項(xiàng)目輪廓圖或市場(chǎng)需求文檔。

2023/12/614軟件需求的層次業(yè)務(wù)需求用戶需求描述的是用戶的目標(biāo)，或用戶要求系統(tǒng)必須能完成的任務(wù)。用例、場(chǎng)景描述和事件―響應(yīng)表都是表達(dá)用戶需求的有效途徑。也就是說(shuō)用戶需求描述了用戶能使用系統(tǒng)來(lái)做些什么。

2023/12/615軟件需求的層次業(yè)務(wù)需求用戶需求功能需求規(guī)定開(kāi)發(fā)人員必須在產(chǎn)品中實(shí)現(xiàn)的軟件功能，用戶利用這些功能來(lái)完成任務(wù)，滿足業(yè)務(wù)需求。功能需求有時(shí)也被稱作行為需求，因?yàn)榱?xí)慣上總是用“應(yīng)該”對(duì)其進(jìn)行描述：“系統(tǒng)應(yīng)該發(fā)送電子郵件來(lái)通知用戶已接受其預(yù)定”。功能需求描述是開(kāi)發(fā)人員需要實(shí)現(xiàn)什么。

三個(gè)層次2023/12/616軟件需求的層次業(yè)務(wù)需求用戶需求功能需求系統(tǒng)需求用于描述包含多個(gè)子系統(tǒng)的產(chǎn)品（即系統(tǒng)）的頂級(jí)需求。系統(tǒng)可以只包含軟件系統(tǒng)，也可以既包含軟件又包含硬件子系統(tǒng)。人也可以是系統(tǒng)的一部分，因此某些系統(tǒng)功能可能要由人來(lái)承擔(dān)。2023/12/617軟件需求的層次業(yè)務(wù)需求用戶需求功能需求非功能性需求系統(tǒng)需求對(duì)產(chǎn)品的功能描述作了補(bǔ)充，它從不同方面描述了產(chǎn)品的各種特性。這些特性包括可用性、可移植性、完整性、效率和健壯性，它們對(duì)用戶或開(kāi)發(fā)人員都很重要。其他的非功能需求包括系統(tǒng)與外部世界的外部界面，以及對(duì)設(shè)計(jì)與實(shí)現(xiàn)的約束。2023/12/618軟件需求的層次業(yè)務(wù)需求用戶需求功能需求非功能性需求約束和假設(shè)系統(tǒng)需求限制了開(kāi)發(fā)人員設(shè)計(jì)和構(gòu)建系統(tǒng)時(shí)的選擇范圍。2023/12/619軟件需求的層次業(yè)務(wù)需求用戶需求功能需求軟件需求規(guī)格Softwarerequirementspecification非功能性需求約束和假設(shè)系統(tǒng)需求2023/12/620軟件需求的層次編號(hào)功能需求1提供病歷信息錄入2提供病歷信息的條件查詢3提供統(tǒng)計(jì)、月統(tǒng)計(jì)、年統(tǒng)計(jì)，并提供打印功能編號(hào)性能需求1必須支持100個(gè)客戶的同時(shí)訪問(wèn)2應(yīng)該在10秒內(nèi)必須從10000條記錄中檢索出需要的患者信息3應(yīng)該在2分鐘之內(nèi)給出季度統(tǒng)計(jì)報(bào)告2023/12/621本章要點(diǎn)一、關(guān)于軟件需求二、需求管理過(guò)程三、編寫需求規(guī)格的方法四、任務(wù)分解定義五、任務(wù)分解方法六、任務(wù)分解結(jié)果的檢驗(yàn)七、案例分析2023/12/622需求工程

需求工程是應(yīng)用已證實(shí)有效的技術(shù)、方法進(jìn)行需求分析，確定客戶需求，幫助分析人員理解問(wèn)題并定義目標(biāo)系統(tǒng)的所有外部特征的一門學(xué)科。需求工程需求管理需求開(kāi)發(fā)需求獲取需求分析需求規(guī)格編寫需求驗(yàn)證變更管理2023/12/623

需求獲取是通過(guò)各種途徑獲取用戶的需求信息（原始材料），產(chǎn)生《用戶需求說(shuō)明書》。

需求獲取依據(jù)工具與技術(shù)成果項(xiàng)目章程干系人登記冊(cè)訪談焦點(diǎn)小組會(huì)議引導(dǎo)式研討會(huì)群體創(chuàng)新技術(shù)群體決策技術(shù)問(wèn)卷調(diào)查觀察原型法需求文件需求管理計(jì)劃需求跟蹤矩陣2023/12/624需求獲取用戶要求基線需求擴(kuò)展需求軟件需求主要任務(wù)：是和用戶方的領(lǐng)導(dǎo)層、業(yè)務(wù)層人員訪談把握用戶的具體需求方向和趨勢(shì)，了解現(xiàn)有的組織架構(gòu)、業(yè)務(wù)流程、硬件環(huán)境、軟件環(huán)境、現(xiàn)有系統(tǒng)的運(yùn)行狀況等信息。2023/12/625需求獲取方法開(kāi)始前：做好準(zhǔn)備，寫出訪談提綱進(jìn)行中：要注意聆聽(tīng)和引導(dǎo)結(jié)束后：要寫感謝信旁敲側(cè)擊的方式復(fù)述，復(fù)述，復(fù)述聆聽(tīng)不要指導(dǎo)兩個(gè)人去訪談讓被訪者上司安排不要問(wèn)太多2023/12/626需求獲取方法頭腦風(fēng)暴法（集思廣益會(huì)）德?tīng)柗萍夹g(shù)（1）根據(jù)問(wèn)題的特點(diǎn)，選擇和邀請(qǐng)相關(guān)專家。（2）將與問(wèn)題有關(guān)的信息提供給專家，請(qǐng)他們各自獨(dú)立發(fā)表自己的意見(jiàn)，并寫成書面材料。（3）管理者收集并綜合專家們的意見(jiàn)后，將綜合意見(jiàn)反饋給各位專家，請(qǐng)他們?cè)俅伟l(fā)表意見(jiàn)。如果分歧很大，可以開(kāi)會(huì)集中討論；否則，管理者分頭與專家聯(lián)絡(luò)。（4）如此反復(fù)多次，最后形成代表專家組意見(jiàn)的方案。2023/12/627需求獲取方法其他方法：需求研討會(huì)用例模型角色扮演原型法Q&A郵件提問(wèn)電視電話會(huì)議訪談2023/12/628需求的分析、整理和確認(rèn)

目標(biāo)：要知道每個(gè)需求的“為什么”；從“如何實(shí)現(xiàn)”

“實(shí)現(xiàn)什么”；分析隱含需求。ID需求描述理由所有者優(yōu)先級(jí)狀態(tài)需求跟蹤矩陣2023/12/629需求獲取注意問(wèn)題1、識(shí)別真正的客戶2、正確理解客戶的需求3、具備較強(qiáng)的忍耐力和清晰的思維4、使用符合客戶語(yǔ)言習(xí)慣的表達(dá)5、提供需求開(kāi)發(fā)評(píng)估報(bào)告6、尊重開(kāi)發(fā)人員和客戶的意見(jiàn)，妥善解決矛盾7、劃分需求的優(yōu)先級(jí)8、說(shuō)服和教育客戶2023/12/630需求分析需求階段設(shè)計(jì)階段編碼階段開(kāi)發(fā)測(cè)試驗(yàn)收階段運(yùn)行階段1x3x-6x10x15x-40x30x-70x1000x2023/12/631需求分析模型當(dāng)前系統(tǒng)邏輯模型物理模型目標(biāo)系統(tǒng)模型化物理模型怎么做具體化抽象化實(shí)例化邏輯模型做什么導(dǎo)出理解需求表達(dá)需求2023/12/632需求分析活動(dòng)1、以圖形表示的方式描述系統(tǒng)的整體結(jié)構(gòu)，包括系統(tǒng)的邊界與接口。2、向用戶提供可視化的界面，用戶可以對(duì)需求做出自己的評(píng)價(jià)。3、以模型描述系統(tǒng)的功能項(xiàng)、數(shù)據(jù)實(shí)體、外部實(shí)體、實(shí)體間的關(guān)系、實(shí)體之間的狀態(tài)轉(zhuǎn)換。2023/12/633處理需求不明確問(wèn)題的方法1、讓用戶參與開(kāi)發(fā)。2、開(kāi)發(fā)用戶原型界面。3、需求討論會(huì)議。4、強(qiáng)化需求分析與評(píng)審。2023/12/634需求規(guī)格需求分析工作完成的一個(gè)基本標(biāo)志是形成了一份完整的、規(guī)范的需求規(guī)格說(shuō)明書。需求規(guī)格說(shuō)明書的編制是為了使用戶和軟件開(kāi)發(fā)者雙方對(duì)該軟件的初始規(guī)定有一個(gè)共同的理解，使之成為整個(gè)開(kāi)發(fā)工作的基礎(chǔ)。2023/12/635軟件需求規(guī)格說(shuō)明的原則從現(xiàn)實(shí)中分離功能，即描述要“做什么”而不是“怎樣實(shí)現(xiàn)”。采用一定的規(guī)格說(shuō)明語(yǔ)言。如果被開(kāi)發(fā)軟件只是一個(gè)大系統(tǒng)中的一個(gè)元素，那么整個(gè)大系統(tǒng)也包括在規(guī)格說(shuō)明的描述之中。規(guī)格說(shuō)明應(yīng)該包括系統(tǒng)運(yùn)行環(huán)境。規(guī)格說(shuō)明應(yīng)該是一個(gè)認(rèn)識(shí)模型。規(guī)格說(shuō)明應(yīng)該容許不完備性并允許擴(kuò)充。SRS實(shí)例2023/12/636需求驗(yàn)證內(nèi)容1、需求的正確性2、需求的一致性3、需求的完整性4、需求的可行性5、需求的必要性6、需求的可檢驗(yàn)性7、需求的可跟蹤性8、最后簽字與其他軟件需求或高層需求不相矛盾驗(yàn)證是否所有可能的狀態(tài)、狀態(tài)變化、轉(zhuǎn)入、產(chǎn)品和約束都在需求中描述驗(yàn)證每一項(xiàng)需求都必須是在已知系統(tǒng)和環(huán)境的權(quán)能和限制范圍內(nèi)可以實(shí)施。驗(yàn)證需求是否是用戶需要的驗(yàn)證是否能寫出測(cè)試案例來(lái)滿足需求，如用演示、檢測(cè)等來(lái)確定產(chǎn)品是否確實(shí)按需求實(shí)現(xiàn)了每項(xiàng)需求以一種結(jié)構(gòu)化的，粒度化的方式編寫并單獨(dú)標(biāo)明。避免大段大段的敘述2023/12/637需求變更管理1、確定變更控制過(guò)程2、建立軟件變更委員會(huì)3、進(jìn)行變更影響分析4、跟蹤變更影響的產(chǎn)品5、建立基準(zhǔn)和控制版本6、維護(hù)變更的歷史記錄7、跟蹤每項(xiàng)需求的狀態(tài)8、衡量需求穩(wěn)定性選擇、分析、決策項(xiàng)目進(jìn)度、資源、工作量、項(xiàng)目范圍、對(duì)其他需求的影響確定、已實(shí)現(xiàn)、暫緩、新增、變更記錄需求基線的數(shù)量和每周或每月的變更2023/12/638變更申請(qǐng)需求方開(kāi)發(fā)方忽略選擇變更方式SCCB評(píng)估項(xiàng)目經(jīng)理自行決定根據(jù)評(píng)估結(jié)果拒絕接受本次修改下個(gè)版本再修改修改合同相關(guān)信息修改相關(guān)需求修改相應(yīng)的項(xiàng)目計(jì)劃需求變更管理過(guò)程2023/12/639本章要點(diǎn)一、關(guān)于軟件需求二、需求管理過(guò)程三、編寫需求規(guī)格的方法四、任務(wù)分解定義五、任務(wù)分解方法六、任務(wù)分解結(jié)果的檢驗(yàn)七、案例分析2023/12/640編寫需求規(guī)格的方法原型方法結(jié)構(gòu)化分析法面向?qū)ο蟮挠美治龇üδ芰斜矸P(guān)聯(lián)模型行為模型數(shù)據(jù)模型結(jié)構(gòu)化模型面向?qū)ο竽Ｐ推渌椒?023/12/641編寫需求規(guī)格實(shí)例——關(guān)聯(lián)模型ATM系統(tǒng)分支賬目系統(tǒng)分支柜臺(tái)系統(tǒng)維護(hù)系統(tǒng)安全系統(tǒng)數(shù)據(jù)應(yīng)用總帳目系統(tǒng)2023/12/642編寫需求規(guī)格實(shí)例——行為模型預(yù)訂機(jī)票準(zhǔn)備機(jī)票記帳行班目錄記帳文件旅行社訂票單航班費(fèi)用旅客機(jī)票2023/12/643編寫需求規(guī)格實(shí)例——狀態(tài)機(jī)模型微波爐2023/12/644編寫需求規(guī)格的思維方法：六頂思考帽2023/12/645本章要點(diǎn)一、關(guān)于軟件需求二、需求管理過(guò)程三、編寫需求規(guī)格的方法四、任務(wù)分解定義五、任務(wù)分解方法六、任務(wù)分解結(jié)果的檢驗(yàn)七、案例分析2023/12/646WBS(WorkBreakdownStructure)任務(wù)分解的過(guò)程將一個(gè)項(xiàng)目分解為更多的工作細(xì)目或者子項(xiàng)目，使項(xiàng)目變得更小、更易管理、更易操作。任務(wù)分解的結(jié)果WBS（任務(wù)分解結(jié)構(gòu)）。WBS面向可交付成果的。Workpackages（工作包）WBS的最低層次的可交付成果代表項(xiàng)目經(jīng)理監(jiān)督和控制項(xiàng)目進(jìn)度的最低層工作。工作包也可以指代說(shuō)明和報(bào)告、一件特殊的硬件設(shè)備（如：特定的服務(wù)器）。2023/12/647WBS(WorkBreakdownStructure)WBS第1層WBS第2層工作包2023/12/648WBS的清單類型

1.

變化計(jì)數(shù)器1.1

比較兩個(gè)版本的程序1.1.1

預(yù)處理1.1.2

文件比較1.1.3

結(jié)果處理1.2

找出修改后的程序中增加和刪除的代碼行1.2.1

找出增加的代碼行1.2.2

找出刪除的代碼行1.3

統(tǒng)計(jì)修改后的程序中增加和刪除的代碼行數(shù)1.3.1

統(tǒng)計(jì)增加代碼行數(shù)1.3.2

統(tǒng)計(jì)刪除代碼行數(shù)1.4

統(tǒng)計(jì)總的代碼行數(shù)1.5

設(shè)定標(biāo)記以指示修改的次數(shù)1.6

在程序的頭部增加修改紀(jì)錄2023/12/649WBS的圖表類型飛行系統(tǒng)飛行器支持設(shè)備設(shè)施測(cè)試與評(píng)價(jià)項(xiàng)目管理培訓(xùn)數(shù)據(jù)系統(tǒng)工程管理支持性項(xiàng)目管理活動(dòng)設(shè)備培訓(xùn)設(shè)施培訓(xùn)服務(wù)培訓(xùn)技術(shù)命令工程數(shù)據(jù)管理數(shù)據(jù)實(shí)物模型運(yùn)作測(cè)試開(kāi)發(fā)測(cè)試基地大樓維護(hù)設(shè)施組織層次的中間層次的補(bǔ)給站層次機(jī)身引擎通信系統(tǒng)導(dǎo)航系統(tǒng)消防系統(tǒng)2023/12/650WBS的圖表類型家庭裝修設(shè)施結(jié)構(gòu)墻體地板門窗廚房廁所洗浴空調(diào)照明通訊潔具燃具風(fēng)機(jī)垃圾櫥柜水池上水管下水道龍頭閥門過(guò)濾網(wǎng)2023/12/651WBS的圖表類型軟件產(chǎn)品發(fā)行版本5.0項(xiàng)目管理項(xiàng)目需求詳細(xì)設(shè)計(jì)構(gòu)建整合測(cè)試管理會(huì)議規(guī)劃培訓(xùn)資料用戶文檔軟件培訓(xùn)資料用戶文件軟件培訓(xùn)資料用戶文件軟件培訓(xùn)資料用戶文件軟件2023/12/652WBS的圖表類型文藝演出節(jié)目劇務(wù)后勤經(jīng)營(yíng)策劃編導(dǎo)排練表演化妝道具燈光音響交通就餐住宿安全廣告銷售票務(wù)財(cái)務(wù)2023/12/653任務(wù)分解步驟確認(rèn)并分解項(xiàng)目的組成要素確定分解標(biāo)準(zhǔn)確定分解是否詳細(xì)確定項(xiàng)目交付成果驗(yàn)證分解的正確性(建立編號(hào))2023/12/654分解標(biāo)準(zhǔn)生存期功能組成項(xiàng)目的組織單位。。。。2023/12/655分解標(biāo)準(zhǔn)應(yīng)統(tǒng)一學(xué)生管理按照生命期分解規(guī)劃需求設(shè)計(jì)編碼測(cè)試提交按照產(chǎn)品組成分解1.1

招生管理1.2

分班管理1.3

學(xué)生檔案管理1.4

學(xué)生成績(jī)管理2023/12/656分解標(biāo)準(zhǔn)應(yīng)統(tǒng)一不能同時(shí)使用兩種標(biāo)準(zhǔn)進(jìn)行分解招生管理分班管理學(xué)生檔案管理學(xué)生成績(jī)管理規(guī)劃需求設(shè)計(jì)編碼測(cè)試提交2023/12/657WBS字典WBS編碼縮寫描述標(biāo)準(zhǔn)歷時(shí)費(fèi)用負(fù)責(zé)人備注描述和定義WBS中的元素，以及其他的計(jì)劃信息，如預(yù)算、工期、責(zé)任人等。2023/12/658WBS字典WBSDICTIONARYControlAccountIDNo.WorkPackageNo.DateofUpdateResponsibleOrganization/IndividualWorkPackageDescriptionAcceptanceCriteriaDeliverablesAssumptionResourcesAssignedDurationScheduleMilestonesCostDueDateInter-dependenciesBeforeAfterthisworkthisworkPackage________________Package________________Approvedby:PM:

_________Date:________2023/12/659本章要點(diǎn)一、關(guān)于軟件需求二、需求管理過(guò)程三、編寫需求規(guī)格的方法四、任務(wù)分解定義五、任務(wù)分解方法六、任務(wù)分解結(jié)果的檢驗(yàn)七、案例分析2023/12/660任務(wù)分解方法使用指南類比法自上而下自下而上心智圖法2023/12/661使用指南一些組織通常都會(huì)為特定項(xiàng)目制訂WBS的格式和內(nèi)容。例如：美國(guó)國(guó)防部（DOD）要求項(xiàng)目承包方基于DOD提供的WBS建議準(zhǔn)備WBS，并據(jù)此審查承包方的成本建議和基于WBS的自身內(nèi)部成本估算。很多組織提供開(kāi)發(fā)WBS的準(zhǔn)則和模板，以及過(guò)去項(xiàng)目的WBS樣例。

PMI開(kāi)發(fā)了一個(gè)WBS實(shí)踐標(biāo)準(zhǔn)為制作和應(yīng)用WBS提供準(zhǔn)則和指南，其中還包含了WBS樣例庫(kù)，涵蓋了很多行業(yè)領(lǐng)域各種類型的項(xiàng)目,如：網(wǎng)頁(yè)設(shè)計(jì)、電信、、服務(wù)業(yè)外包、軟件開(kāi)發(fā)等。PMI會(huì)員免費(fèi)下載(WWW.PMI.ORG)，非會(huì)員需購(gòu)買。WBS模板2023/12/662自上而下與自下而上自上而下法是創(chuàng)建WBS的傳統(tǒng)方法，即：從項(xiàng)目最大項(xiàng)開(kāi)始，將它們分解成下一級(jí)的項(xiàng)。這個(gè)過(guò)程實(shí)際上就是對(duì)工作的進(jìn)一步細(xì)分。該方法適用于對(duì)整個(gè)項(xiàng)目有宏觀技術(shù)把握的項(xiàng)目經(jīng)理使用。自下而上法項(xiàng)目組成員首先識(shí)別出盡可能多的與項(xiàng)目有關(guān)的具體任務(wù)；隨后，將這些具體的任務(wù)集中分類并組織成概要任務(wù)或WBS中的較高層次。該方法通常比較耗時(shí)。項(xiàng)目經(jīng)理通常運(yùn)用該方法處理全新的系統(tǒng)。2023/12/663心智圖法（MindMapping)

心智圖法，又稱思維導(dǎo)圖，是一種從核心思想向外輻射出分支的方法，用以組織思路和想法。該方法可以讓人們以非線性方式構(gòu)想，用形象的無(wú)結(jié)構(gòu)化的方法定義WBS的項(xiàng)，隨后可以直接將信息轉(zhuǎn)化成圖表格式。2023/12/664心智圖法（MindMapping)1、首先在紙的中心畫一個(gè)彩圖，既明確主題，且刺激創(chuàng)意性思維。2、多用圖畫，醒目，利于記憶。3、以粗體字書寫，這樣更清晰，便于閱讀，便于反饋。4、字詞以線相連，這樣形成一個(gè)基本框架結(jié)構(gòu)。5、多用單個(gè)的詞語(yǔ)，這樣每個(gè)詞語(yǔ)間連接起來(lái)更自如，聯(lián)想空間更大，更自由，更多變。6、多用各種顏色，同樣是為了醒目，強(qiáng)化記憶。7、大腦應(yīng)盡可能地保持“自由”，這樣可以充分利用其創(chuàng)造性。任何關(guān)于事物應(yīng)朝何處發(fā)展及是否應(yīng)包括在思維導(dǎo)圖中等方面的“思維”，都會(huì)直接使大腦創(chuàng)造性思維減速。2023/12/665心智圖法（MindMapping)2023/12/666心智圖法（MindMapping)2023/