工學(xué)軟件項目計劃

0軟件項目管理信息科學(xué)與工程學(xué)院軟件工程系崔煥慶2024/7/11RoadMap

項目結(jié)束

項目執(zhí)行控制

項目計劃

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

合同計劃

風(fēng)險計劃

溝通計劃

人力計劃

質(zhì)量計劃

成本計劃

時間計劃

集成計劃范圍計劃

項目結(jié)束

項目執(zhí)行控制

項目計劃

項目初始5第2章范圍計劃2024/7/16為什么進行范圍計劃？

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

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

——弗雷德里克·布魯克斯2024/7/18什么是范圍管理1.什么是范圍？

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

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

40%~60%的問題是在需求分析階段埋下的隱患。40%的開發(fā)總費用是返工開銷。70%~80%的返工是需求方面的錯誤導(dǎo)致的。80%的失敗項目是需求分析不明確造成的?？傊?，好的需求管理是項目成功的第一位因素。采用需求管理可以給項目組帶來很多的好處，直至項目取得成功。2024/7/111項目失敗的原因分析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,SoftwareEngineeringInstitute2024/7/112什么是軟件需求需求是指用戶對軟件的功能和性能的要求，就是用戶希望軟件能做什么事情，完成什么樣的功能，達到什么性能。正在構(gòu)建的系統(tǒng)必須符合的條件或具備的功能?！猂ational用戶解決某一問題或達到某一目標所需的軟件功能。系統(tǒng)或系統(tǒng)構(gòu)件為了滿足合同、規(guī)約、標準或其他正式實行的文檔而必須滿足或具備的軟件功能?！狹erlinDorfman、RichardH.Thayer2024/7/113軟件需求的層次業(yè)務(wù)需求表示組織或客戶高層次的目標。業(yè)務(wù)需求通常來自項目投資人、購買產(chǎn)品的客戶、實際用戶的管理者、市場營銷部門或產(chǎn)品策劃部門。業(yè)務(wù)需求描述了組織為什么要開發(fā)一個系統(tǒng)，即組織希望達到的目標。使用前景和范圍文檔來記錄業(yè)務(wù)需求，這份文檔有時也被稱作項目輪廓圖或市場需求文檔。

2024/7/114軟件需求的層次業(yè)務(wù)需求用戶需求描述的是用戶的目標，或用戶要求系統(tǒng)必須能完成的任務(wù)。用例、場景描述和事件―響應(yīng)表都是表達用戶需求的有效途徑。也就是說用戶需求描述了用戶能使用系統(tǒng)來做些什么。

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

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

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

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

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

目標：要知道每個需求的“為什么”；從“如何實現(xiàn)”

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

1.

變化計數(shù)器1.1

比較兩個版本的程序1.1.1

預(yù)處理1.1.2

文件比較1.1.3

結(jié)果處理1.2

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

找出增加的代碼行1.2.2

找出刪除的代碼行1.3

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

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

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

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

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

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

招生管理1.2

分班管理1.3

學(xué)生檔案管理1.4

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

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

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

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