1、IT項目管理原則項目管理原則 圍繞軟件開發，提出了以下基本原則。圍繞軟件開發，提出了以下基本原則。第一：選取適宜的開發范型第一：選取適宜的開發范型 在系統設計中，經常需要權衡軟件需在系統設計中，經常需要權衡軟件需求、硬件需求以及其它因素之間的相互制約和影響，適應需求的易求、硬件需求以及其它因素之間的相互制約和影響，適應需求的易變性。選用適宜的開發范型，以保證軟件開發的可持續性，并使最變性。選用適宜的開發范型，以保證軟件開發的可持續性，并使最終的軟件產品滿足客戶的要求。終的軟件產品滿足客戶的要求。第二：采用好的設計方法第二：采用好的設計方法 在軟件設計中，通常需要考慮軟件的模在軟件設計中，通常需

2、要考慮軟件的模塊化、信息隱蔽、局部化、一致性以及適應性等問題。采用合適的塊化、信息隱蔽、局部化、一致性以及適應性等問題。采用合適的設計方法，支持這些問題的解決和實現。設計方法，支持這些問題的解決和實現。第三條：提供高質量的工程支持第三條：提供高質量的工程支持 如其它工程一樣，需要提供高質如其它工程一樣，需要提供高質量的工程支持，例如配置管理、質量保證等，才能按期交付高質量量的工程支持，例如配置管理、質量保證等，才能按期交付高質量的軟件產品。的軟件產品。第四條原則：有效的第四條原則：有效的IT項目管理項目管理 IT項目管理的管理，直接影響項目管理的管理，直接影響可用資源的有效利用，提高軟件組織的

3、生產能力。僅當對軟件過程可用資源的有效利用，提高軟件組織的生產能力。僅當對軟件過程實施有效管理時，才能實現有效的實施有效管理時，才能實現有效的IT項目管理。項目管理。概論概論第一部分第一部分管理到底是個啥東東？成功的管理者應該是什么樣軟件生存周期模型IT項目管理的主要領域及其相互關系關于項目成功的討論：關于項目成功的討論：什么樣的項目是成功的項目？ 完成預定業務目標？ 客戶滿意？ 盈利？.業務目標業務目標進度進度Time成本成本Cost范圍范圍Scope項目經理項目經理如何把握管理如何把握管理1 面向目標的管理方式 目標對交付物的強調（別人給你的目標是什么？）工作的分解方式（你給別人的目標是什

4、么？）2 前期的投入大以換取執行階段的相對穩定 計劃3 項目需求多變以及資源緊張的推動 跟蹤4 大量信息交換帶來的溝通管理的需求 模板5 由抽象到具體的管理過程 分解以往的成果可以被重復使用學習過程較長（關注方法而耐心）6 高管理成本換取低出錯率從而降低總體成本 周期關注“管理周期”項目的生命周期項目的生命周期項目計劃項目計劃確定需求確定需求項目選擇項目選擇項目執行項目執行項目控制項目控制項目評估項目評估項目結束項目結束定義定義計劃計劃實施實施收尾收尾軟件開發流程分為軟件開發流程分為:需求確認需求確認概要設計概要設計詳細設計詳細設計編碼編碼單元測試單元測試集成測試集成測試系統測試系統測試維護維

5、護 概念計劃開發公用基礎模塊建立參考架構管理產品族 確認設計重用的機會生產較簡單的派生產品使用決定性的測試GBM （Global Brand M anagerPDT投資組合管理確認市場機會/產品競爭力（可選）流程度量早期警告指示完美的行評審點執行階段性的時間和投資等客戶$APPEALS確定用戶采購標準確認所有市場混合因素設計渠道IPMT發布項目管理完整的依賴關系管理關鍵路徑分析/恢復方法驗證生命周期概念決策評審點計劃決策評審點可獲得性決策評審點壽命終止決策評審點研發流程研發流程(IPD)管理控制整個流程管理控制整個流程項目經理在IPD中PDT團隊的角色及義務領導項目組指導產品從概念設計到市場接

6、受保證實現設計、收益、市場份額及利潤目標解決沖突管理項目制定項目計劃及預算確定/管理參與項目的人員/資源（與職能部門經理協調）跟蹤相對于項目基線的進展與管理層溝通提供項目進展狀況準備并確定決策評審點作為產品領導提供對項目組成員的工作績效評審的輸入高級管理組項目領導職能部門領導核心小組成員PDT是臨時小組 在項目開始時成立 在產品成功發布后解散 PDT成員在概念階段一起作整個項目的計劃PDT成員在計劃階段一起管理整個項目一個專業的經理需要那些素質？一個專業的經理需要那些素質？管理的知識相關的行業知識 業務與技術知識領導能力 (Leadership) 制定目標的能力執行的能力 - 計劃以及控制能力

7、溝通的能力 包括協調沖突分析決策能力應變承壓能力三種知識，五種能力三種知識，五種能力IBM Leadership Competencies for ManagersFOCUS TO WINCustomer InsightBreakthrough ThinkingDrive to AchieveMOBILIZE TO EXECUTETeam LeadershipStraight TalkTeamworkDecisiveness/Decision MakingSUSTAIN MOMENTUMBuilding Organizational CapabilityCoaching/Developing

8、TalentPersonal DedicationTHE COREPassion for the business成功的管理者應該是什么樣成功的管理者應該是什么樣對專業管理人士的最真實的考驗不是你知道怎樣做，而是在你不知道時也知道如何行動。決策決策 = “我不知道我不知道” + 人人管理者的若干規則：管理者的若干規則：弄清團隊業務的目標、所面臨的問題，以及機會理解團隊中的處突是必然的識別團隊項目和業務的干系人，以及他們的利益關系利用組織的政治色彩，并利用政治手段獲得優勢善于應用管理(Manage - Process)與領導(Lead - Vision)不要因小事而停滯不前，迷失了項目的整體目標

9、有效的利用好時間計劃、計劃、再計劃，跟蹤、跟蹤、再跟蹤從實踐中獲取經驗尋求別人的反映與資深的管理者進行探討多學習，多閱讀管理者常犯的錯誤：管理者常犯的錯誤：拒絕承擔個人責任只控制工作成果不能因人施管經理僅僅是職員的伙伴附和錯誤的一方忘卻利潤的重要性只專注日常業務問題未能培育人才IT項目管理項目管理講些啥東東？講些啥東東？問題：問題：“軟件”的定義？“IT項目管理”的定義？“IT項目管理”的“方法”有啥？“IT項目管理”管理啥？ 軟件軟件計算機系統中的程序及其文檔。程序是計算任務的處計算機系統中的程序及其文檔。程序是計算任務的處理對象和處理規則的描述；文檔是為了便于了解程序所需的闡理對象和處理規

10、則的描述；文檔是為了便于了解程序所需的闡明性資料。明性資料。 工程工程將理論和所學的知識應用于實踐的科學。將理論和所學的知識應用于實踐的科學。 IT項目管理項目管理是將系統化的、規范的、可度量的方法應用于是將系統化的、規范的、可度量的方法應用于軟件的開發、運行和維護的過程，即將工程化應用于軟件中。軟件的開發、運行和維護的過程，即將工程化應用于軟件中。IT項目管理還包括上述方法的研究。項目管理還包括上述方法的研究。從癥狀追溯到根本原因從癥狀追溯到根本原因需求沒有滿足需求沒有滿足需求混雜需求混雜模塊難集成模塊難集成系統很難維護系統很難維護缺陷發現晚缺陷發現晚不好的質量不好的質量不好的性能不好的性能

11、開發人員協作難開發人員協作難構建和發布問題構建和發布問題不正確的需求不正確的需求含糊不清的溝通含糊不清的溝通脆弱的架構脆弱的架構 過分的復雜性過分的復雜性未發現的不一致未發現的不一致測試不充分測試不充分 主觀的估計主觀的估計瀑布行的開發瀑布行的開發不可控的變更不可控的變更缺乏自動化缺乏自動化癥狀癥狀根本原因根本原因IT項目管理實踐項目管理實踐迭代開發迭代開發需求管理需求管理基于組件的架構基于組件的架構 可視化建模（可視化建模（UML）持續的質量驗證持續的質量驗證管理變更管理變更 持續的質量驗證持續的質量驗證 不好的質量不好的質量 未發現的不一致未發現的不一致測試不充分測試不充分 主觀的估計主觀

12、的估計 Learning Roadmap迭代開發迭代開發管理需求管理需求基于組件的架構基于組件的架構可視化建模可視化建模 持續的質量驗證持續的質量驗證管理變更管理變更IT項目管理實踐項目管理實踐Learning Topic軟件開發過程軟件開發過程軟件項目管理軟件項目管理軟件需求管理軟件需求管理軟件架構軟件架構SOASOA，J2EEJ2EE，.Net.Net軟件設計與軟件設計與UMLUML軟件質量管理軟件質量管理軟件測試軟件測試軟件變更管理軟件變更管理IT項目管理項目管理IT項目管理：圍繞五大要項目管理：圍繞五大要素素(人員、進度、質量、人員、進度、質量、成本和需求的實現）進成本和需求的實現）進

13、行行“規劃和組織規劃和組織”、“領導和控制領導和控制”以及以及“評估評估”等責任等責任課程的考核課程的考核采用作業和考試相結合的方式，其中作業占50%，考試占50%，開卷。建議教學參考書建議教學參考書課程講義軟件項目管理：一個統一的框架-Software Project Management-A Unified FrameworkIT項目管理：實踐者的研究方法-Software Engineering: A practitioners Approach微軟技術叢書：快速軟件開發Mark C. Paulk, et al. “The Capability Maturity Model: Guide

14、lines for Improving the Software Process”. Addison-Wesley, Reading, Mass. 1995.Watts S Humphrey. Managing the Software ProcessM. The 26th printing. USA：Addison-Wesley，2000(5): 247-285軟件生存周期模型（軟件開發模型）軟件生存周期模型（軟件開發模型）軟件生存周期模型（軟件開發模型）軟件生存周期模型（軟件開發模型）基本概念基本概念）軟件生存周期模型）軟件生存周期模型IEEE Standard 12207.0-1996

15、把一個軟件生存周期模型描述為：一個包括軟件產品開發、運行把一個軟件生存周期模型描述為：一個包括軟件產品開發、運行和維護中有關過程、活動和任務的框架，覆蓋了從該系統的需求定和維護中有關過程、活動和任務的框架，覆蓋了從該系統的需求定義到系統的使用終止。義到系統的使用終止。中國計算機科學與技術百科全書中國計算機科學與技術百科全書 稱軟件生存周期模型為稱軟件生存周期模型為“軟件開發模型軟件開發模型”，并把它定義為：軟件，并把它定義為：軟件過程、活動、任務的結構框架。過程、活動、任務的結構框架。）基本的開發活動及其目標）基本的開發活動及其目標（1）軟件需求分析：是在一個抽象層上建立概念模型的活動，產）軟

16、件需求分析：是在一個抽象層上建立概念模型的活動，產生軟件需求規約，作為開發人員和客戶間契約的基礎，并作為以生軟件需求規約，作為開發人員和客戶間契約的基礎，并作為以后開發階段的輸入。后開發階段的輸入。（2）軟件設計：是指定義實現需求規約所需的結構，包括軟件體）軟件設計：是指定義實現需求規約所需的結構，包括軟件體系結構（數據和程序結構），以及詳細的處理算法，即所謂設計系結構（數據和程序結構），以及詳細的處理算法，即所謂設計規約，給出了實現軟件需求的軟件解決方案。規約，給出了實現軟件需求的軟件解決方案。（3）實現：即軟件編碼，是由設計規約到代碼的轉換。）實現：即軟件編碼，是由設計規約到代碼的轉換。

17、其中其中可選擇一些可用的構件，或以一種選定的語言，對給定的軟件項可選擇一些可用的構件，或以一種選定的語言，對給定的軟件項進行編碼。進行編碼。（）軟件測試：是指一種有規程的發現軟件錯誤的活動包（）軟件測試：是指一種有規程的發現軟件錯誤的活動包括軟件編碼測試、括軟件編碼測試、 軟件集成測試以及軟件合格測試等。軟件集成測試以及軟件合格測試等。（5）維護是在軟件發布之后所進行的開發或修改（）維護是在軟件發布之后所進行的開發或修改（modi-fication），包括對發現錯誤的修正以及對環境的變化所進行），包括對發現錯誤的修正以及對環境的變化所進行的必要調整等。的必要調整等。 完善性維護完善性維護 糾錯

18、性維護糾錯性維護 *演化性維護演化性維護 系統需求系統需求軟件需求軟件需求需求分析需求分析設設 計計編編 碼碼測測 試試運運 行行歸納邏輯：歸納邏輯： P P Q Q P P Q Q 瀑布模型瀑布模型 1970年，年，W.Royce Thebasis for most current practice and has many variations. Its name come from the progression of activities based on the output of one phase “falling” as input to the following phase

19、. It is driven by the needs to schedule project milestones which are provided by the completion of documents at each level or phase.（）（）項目的開發依次經過：需求、設計、編碼和單元測試、項目的開發依次經過：需求、設計、編碼和單元測試、 集成以及維護集成以及維護 這一基本路徑。這一基本路徑。 （）在每一階段提交以下產品：軟件需求規約、設計文檔、（）在每一階段提交以下產品：軟件需求規約、設計文檔、 實際代碼、測試用例、最終產品等。工作產品（又稱可實際代碼、測試用例、

20、最終產品等。工作產品（又稱可提交的產品，提交的產品，DeliverablesDeliverables） 流經流經“正向正向”開發的基本步開發的基本步驟路徑。驟路徑。 （）（）“反向反向”步驟流表示對前一個可提交產品的重復變更（又步驟流表示對前一個可提交產品的重復變更（又稱為稱為“返工返工”(Rework)(Rework)） 。 由于所有開發活動的非確定性，因此是否需要重復變由于所有開發活動的非確定性，因此是否需要重復變更，這僅在下一個階段或更后的階段才能認識到。更，這僅在下一個階段或更后的階段才能認識到。 返工不僅在以前階段的某一地方需要，而且對當前正返工不僅在以前階段的某一地方需要，而且對當

21、前正在進行的工作也是需要的。在進行的工作也是需要的。關于瀑布模型的幾點說明關于瀑布模型的幾點說明( (）瀑布模型的優點）瀑布模型的優點 雖然瀑布模型是一個比較雖然瀑布模型是一個比較“老老”的、甚至過時的開發模型，的、甚至過時的開發模型，但其優點為：但其優點為： 在決定系統怎樣做之前，存在一個需求階段，鼓勵對系在決定系統怎樣做之前，存在一個需求階段，鼓勵對系 統統“做什么做什么”進行規約（即設計之前的規約）。進行規約（即設計之前的規約）。 在建造構件之前，存在一個設計階段，鼓勵規劃系統結在建造構件之前，存在一個設計階段，鼓勵規劃系統結 構（即編碼之前的設計）。構（即編碼之前的設計）。 在每一階段

22、結束時進行復審，允許獲取方和用戶的參與。在每一階段結束時進行復審，允許獲取方和用戶的參與。 允許基線和配置早期接受控制。允許基線和配置早期接受控制。 前一步工作產品可作為下一步被認可的、文檔化的基線。前一步工作產品可作為下一步被認可的、文檔化的基線。（）（）瀑布模型存在的不足瀑布模型存在的不足 客戶必須能夠完整、正確和清晰地表達他們的需求；開發客戶必須能夠完整、正確和清晰地表達他們的需求；開發 人員一開始就必須理解其應用。人員一開始就必須理解其應用。 在開始的兩個或三個階段中，很難評估真正的進度狀態在開始的兩個或三個階段中，很難評估真正的進度狀態; ; 設計、編碼和測試階段都可能發生延期。設計

23、、編碼和測試階段都可能發生延期。 在一個項目的早期階段，過分地強調了基線和里程碑處在一個項目的早期階段，過分地強調了基線和里程碑處 的文檔的文檔; ;可能要花費更多的時間，用于建立一些用處不可能要花費更多的時間，用于建立一些用處不 大的文檔。大的文檔。 當接近項目結束時，出現了大量的集成和測試工作。當接近項目結束時，出現了大量的集成和測試工作。 直到項目結束之前，都不能演示系統的能力。直到項目結束之前，都不能演示系統的能力。（3）瀑布模型適用的情況瀑布模型適用的情況在開發中，向下、漸進的路徑占支配地位。也就是說，在開發中，向下、漸進的路徑占支配地位。也就是說， 需求已被很好地理解；并且需求已被

24、很好地理解；并且 過程設計人員也很清楚：開發組織非常熟悉為實現這一模過程設計人員也很清楚：開發組織非常熟悉為實現這一模 型所需要的過程（或經過培訓后，熟悉什么時候來支持這型所需要的過程（或經過培訓后，熟悉什么時候來支持這 一項目，以實現這一模型所需要的過程）。一項目，以實現這一模型所需要的過程）。因此為了避免產生過多因此為了避免產生過多的反復迭代工作，增加開發成本，的反復迭代工作，增加開發成本，一般在準備采用瀑布模型一般在準備采用瀑布模型(也包括其他模型也包括其他模型)時，需要考慮以下時，需要考慮以下2個問題：第一個問題是，過程設計人員必須對初始產品個問題：第一個問題是，過程設計人員必須對初始

25、產品(通常通常 是軟件需求規約，是軟件需求規約，SRS)的不確定性進行評估。的不確定性進行評估。 另一個問題是，組織是否具有熟練實施每個活動和另一個問題是，組織是否具有熟練實施每個活動和 任務的歷史經驗。任務的歷史經驗。13259101167121384增量增量1 1 1,2,5,9 1,2,5,9 增量增量2 2 3 3,6,7,4,10,11 ,6,7,4,10,11 增量增量3 3 8 8,12,13 ,12,13 管理管理增量規約增量規約增量設計增量設計糾錯性分析糾錯性分析增量實現增量實現增量1增量2增量33 增量模型增量模型該模型有一個假設，即需求可以分段，成為一系列增該模型有一個假

26、設，即需求可以分段，成為一系列增量產品，每一增量可以分別地開發。量產品，每一增量可以分別地開發。關于增量模型的幾點說明：關于增量模型的幾點說明：(1(1）增量模型的優點）增量模型的優點 作為瀑布模型的第一個變體，具有瀑布模型的所有優點。作為瀑布模型的第一個變體，具有瀑布模型的所有優點。 此外，它還有以下優點：此外，它還有以下優點： 第一個可交付版本所需要的成本和時間是很少的；第一個可交付版本所需要的成本和時間是很少的； 開發由增量表示的小系統所承擔的風險是不大的；開發由增量表示的小系統所承擔的風險是不大的； 由于很快發布了第一個版本，因此可以減少用戶需求由于很快發布了第一個版本，因此可以減少用

27、戶需求 的變更；的變更； 允許增量投資，即在項目開始時，可以僅對一個或兩允許增量投資，即在項目開始時，可以僅對一個或兩 個增量投資。個增量投資。 ( (）缺點：）缺點： 如果增量模型不適于某些項目，或使用有誤，則有如果增量模型不適于某些項目，或使用有誤，則有以下缺點：以下缺點： 如果沒有對用戶的變更要求進行規劃，那么產生的初始如果沒有對用戶的變更要求進行規劃，那么產生的初始 增量可能會造成后來增量的不穩定；增量可能會造成后來增量的不穩定； 如果需求不像早期思考的那樣穩定和完整，那么一些增如果需求不像早期思考的那樣穩定和完整，那么一些增 量就可能需要重新開發，重新發布；量就可能需要重新開發，重新

28、發布； 管理發生的成本、進度和配置的復雜性，可能會超出組管理發生的成本、進度和配置的復雜性，可能會超出組 織的能力。織的能力。 注：如果采用增量投資方式，那么客戶就可以對一些增量進注：如果采用增量投資方式，那么客戶就可以對一些增量進行招標。然后，開發人員按提出的截止期限進行增量開發，這行招標。然后，開發人員按提出的截止期限進行增量開發，這樣客戶就可以用多個契約來管理組織的資源和成本。樣客戶就可以用多個契約來管理組織的資源和成本。( (）該模型的適用情況）該模型的適用情況 在開始開發時，需求很明確，且產品還可被適當地分解為一些獨在開始開發時，需求很明確，且產品還可被適當地分解為一些獨立的、可交付

29、的軟件（構造增量：立的、可交付的軟件（構造增量：Build incrementsBuild increments如果一個增如果一個增量并不需要交付給客戶的話，那么這樣的增量通常稱為一個量并不需要交付給客戶的話，那么這樣的增量通常稱為一個“構造構造”(Build)。如果增量被交付，那么它們就被認為是發布版本。如果增量被交付，那么它們就被認為是發布版本(Released version)。 ）；）； 在開發中，期望盡快提交其中的一些增量產品。在開發中，期望盡快提交其中的一些增量產品。 例如：例如：一個數據庫系統，它必須通過不同的用戶界面，為不同類型的用戶一個數據庫系統，它必須通過不同的用戶界面，為

30、不同類型的用戶提供不同的功能。在這一情況下，首先實現完整的數據庫設計，并提供不同的功能。在這一情況下，首先實現完整的數據庫設計，并把一組具有高優先級的用戶功能和界面作為一個增量；以后，陸續把一組具有高優先級的用戶功能和界面作為一個增量；以后，陸續構造其它類型用戶所需求的增量。構造其它類型用戶所需求的增量。需求需求設計設計編碼編碼測試測試集成集成需求需求設計設計編碼編碼測試測試集成集成開開發發反反饋饋開開發發反反饋饋.核核 心心 系系 統統 開開 發發第第 二二 次次 迭迭 代代演化模型（演化模型（ Evolutionary modelEvolutionary model）是一種有彈性的過程模式

31、，由一些小的開發步組成，每一步歷是一種有彈性的過程模式，由一些小的開發步組成，每一步歷經需求分析、設計、實現和驗證，產生軟件產品的一個增量。通過經需求分析、設計、實現和驗證，產生軟件產品的一個增量。通過這些迭代，完成最終軟件產品的開發。這些迭代，完成最終軟件產品的開發。 針對事先不能完整地定義需求針對事先不能完整地定義需求 針對用戶的核心需求針對用戶的核心需求, ,開發核心系統開發核心系統 根據用戶的反饋根據用戶的反饋, ,實施活動的迭代實施活動的迭代關于演化模型的幾點說明關于演化模型的幾點說明(1(1）主要特征）主要特征 該模型顯式地把增量模型擴展到需求階段。由圖可以看出，該模型顯式地把增量

32、模型擴展到需求階段。由圖可以看出，為了第二個構造增量，使用了第一個構造增量來精化需求。為了第二個構造增量，使用了第一個構造增量來精化需求。這一精化可以有多個來源和路徑。這一精化可以有多個來源和路徑。 首先，如果一個早期的增量已向用戶發布，那么用戶會以變首先，如果一個早期的增量已向用戶發布，那么用戶會以變更要求的方式提出反饋，以支持以后增量的需求開發。更要求的方式提出反饋，以支持以后增量的需求開發。 第二，通過實實在在地開發一個構造增量，為以前還沒有認第二，通過實實在在地開發一個構造增量，為以前還沒有認識到的問題提供了可見性，以便實際地開始這一增量的工作。識到的問題提供了可見性，以便實際地開始這

33、一增量的工作。(2(2）與瀑布模型的關系）與瀑布模型的關系 在演化模型中，仍然可以使用瀑布模型來管理每一個演化的增量。在演化模型中，仍然可以使用瀑布模型來管理每一個演化的增量。一旦理解了需求，就可以像實現瀑布模型那樣開始設計階段和編碼階一旦理解了需求，就可以像實現瀑布模型那樣開始設計階段和編碼階段。段。(3(3）使用演化模型應注意的問題）使用演化模型應注意的問題 不能弱化需求分析階段的工作。其原因是：不能弱化需求分析階段的工作。其原因是：在項目開始時，考慮所在項目開始時，考慮所有需求來源的重要性和風險，對這些來源的可用性進行評估。只有采有需求來源的重要性和風險，對這些來源的可用性進行評估。只有

34、采用這一方法，才能識別和界定不確定的需求，并識別第一個增量中所用這一方法，才能識別和界定不確定的需求，并識別第一個增量中所包含的需求。包含的需求。(4(4）演化模型的長處和不足）演化模型的長處和不足 演化模型還具有以下優點：與增量模型是類似的。特別地，演化模型還具有以下優點：與增量模型是類似的。特別地， 在需求不能予以規約時，可以使用這一演化模型。在需求不能予以規約時，可以使用這一演化模型。 用戶可以通過運行系統的實踐，對需求進行改進。用戶可以通過運行系統的實踐，對需求進行改進。 與瀑布模型相比，需要更多用戶與瀑布模型相比，需要更多用戶/ /獲取方的參與。獲取方的參與。 缺點有：缺點有： 演化

35、模型的使用仍然處于探索階段，因此具有較大演化模型的使用仍然處于探索階段，因此具有較大 的風險，需要有力的管理。的風險，需要有力的管理。 演化模型的使用很容易成為不編寫需求或設計文檔的借口，演化模型的使用很容易成為不編寫需求或設計文檔的借口， 即使很好地理解了需求或設計。即使很好地理解了需求或設計。 用戶用戶/ /獲取方不易理解演化模型的自然屬性，因此當結果不獲取方不易理解演化模型的自然屬性，因此當結果不 夠理想時，可能產生抱怨。夠理想時，可能產生抱怨。5 螺旋模型螺旋模型 該模型是由該模型是由Dr. Barry Boehm Boehm 1988Dr. Barry Boehm Boehm 198

36、8開發的。開發的。 該模型將軟件生存周期的活動分為四個可重復的階段：該模型將軟件生存周期的活動分為四個可重復的階段： 規劃、風險分析、開發和評估：規劃、風險分析、開發和評估： 項目的進度是項目的進度是“螺旋螺旋”式的。式的。 risk analysis stageDevelopment stagePlanning stageEvaluation stagestartResource use其中：其中： 評估和風險分析階段都可作出一個決策：項目是否繼續。評估和風險分析階段都可作出一個決策：項目是否繼續。 螺旋循環的次數指示了已消耗的資源；螺旋循環的次數指示了已消耗的資源； 在規劃階段、風險分析階

37、段和開發階段均進行需求規約活在規劃階段、風險分析階段和開發階段均進行需求規約活 動；動； 在早期螺旋循環中，為了為最終的實現給出一些指導性決在早期螺旋循環中，為了為最終的實現給出一些指導性決 策，經常使用原型構造；策，經常使用原型構造；設計和實現活動一般是在開發階段進行；設計和實現活動一般是在開發階段進行； V&V 活動在開發階段和評估階段進行；活動在開發階段和評估階段進行； 驗證驗證/確認確認:一種評估活動一種評估活動驗證驗證（verification）：確定一個階段的產品是否達到）：確定一個階段的產品是否達到 前階段確立的需求的過程。前階段確立的需求的過程。 （實施過程質量控制的基

38、本措施）（實施過程質量控制的基本措施） 確認確認(veridation)：評價開發的軟件與需求是否一致的：評價開發的軟件與需求是否一致的 過程。過程。 （實施產品質量控制的基本措施）（實施產品質量控制的基本措施）活動1活動2活動3活動1活動2活動3關于螺旋模型的幾點說明：關于螺旋模型的幾點說明：(1(1）該模型關注解決問題的基本步驟）該模型關注解決問題的基本步驟: : 標識問題標識問題; ; 標識一些標識一些 可選方案，選擇一個最佳方案可選方案，選擇一個最佳方案; ; 遵循動作步驟，并實施遵循動作步驟，并實施 后續工作。其中只要完成了開發的一個迭代，開發的另后續工作。其中只要完成了開發的一個迭

39、代，開發的另 一個迭代就開始。一個迭代就開始。(2(2）螺旋模型的一個特征是，實際上只有一個迭代過程真正）螺旋模型的一個特征是，實際上只有一個迭代過程真正 開發可交付的軟件。因此開發可交付的軟件。因此, ,如果如果 項目的開發風險很大，或項目的開發風險很大，或 客戶不能確定系統需求，在更廣泛的意義上來講，還客戶不能確定系統需求，在更廣泛的意義上來講，還 包括系統或系統類型的要求，包括系統或系統類型的要求， 這時螺旋模型就是一個好的生存周期模型。這時螺旋模型就是一個好的生存周期模型。(3) (3) 與其它模型的關系與其它模型的關系 與演化模型一樣，螺旋模型也使用瀑布模型作為一個嵌入的過與演化模型

40、一樣，螺旋模型也使用瀑布模型作為一個嵌入的過程程- -即分析、設計、編碼、實現和維護的瀑布過程，是螺旋一周的組即分析、設計、編碼、實現和維護的瀑布過程，是螺旋一周的組成部分。成部分。 盡管螺旋模型和一些迭代模型在框架和全局體系結構方面是等盡管螺旋模型和一些迭代模型在框架和全局體系結構方面是等同的，但所關注的同的，但所關注的階段階段以及它們的以及它們的活動活動是不同的。是不同的。 具體地說：具體地說：標識客戶想要的是一個什么樣的系統；標識客戶想要的是一個什么樣的系統；確定風險確定風險和效益的可選路線；和效益的可選路線；選擇最優方案；選擇最優方案；開發系統；開發系統；評估完成情評估完成情況等；況等

41、；重新開始。重新開始。 即即 螺旋模型擴展了增量模型的管理任務范圍。而增量模型是基螺旋模型擴展了增量模型的管理任務范圍。而增量模型是基于以下假定：需求是最基本的、并且是唯一的風險源。而在螺旋模于以下假定：需求是最基本的、并且是唯一的風險源。而在螺旋模型中，決策和降低風險的空間是相當廣泛的。型中，決策和降低風險的空間是相當廣泛的。6 6 小結小結）所有模型的內在基本特征）所有模型的內在基本特征： 描述了開發的主要階段；描述了開發的主要階段； 定義了每一個階段要完成的主要活動；定義了每一個階段要完成的主要活動； 規約了每一個階段的輸入和輸出（產品）；規約了每一個階段的輸入和輸出（產品）； 提供了一

42、個框架，可以把必要的活動映射到該框架中。提供了一個框架，可以把必要的活動映射到該框架中。外征：軟件開發活動的組織外征：軟件開發活動的組織 內涵：求解軟件的計算邏輯內涵：求解軟件的計算邏輯）關于軟件開發風范）關于軟件開發風范 -開發活動的組織開發活動的組織:風格與準則風格與準則 盡管在實踐中，每一項盡管在實踐中，每一項IT項目管理都有自己特定的軟件開發項目管理都有自己特定的軟件開發過程，但軟件開發風范（過程，但軟件開發風范（paradigms）主要有五種，它們是：）主要有五種，它們是： 迭代（迭代（iterative）風范，）風范， 也稱為演化（也稱為演化（evolutionary）風范）風范;

43、 轉換（轉換（transformational）風范）風范; 螺旋（螺旋（ spiral）風范）風范; 瀑布（瀑布（ waterfall）風范，以及）風范，以及 第四代（第四代（fourth generation）風范。）風范。其中，轉換風范的過程模式其中，轉換風范的過程模式 基于待開發系統的形式化需求規約。基于待開發系統的形式化需求規約。 在此基礎上，通過一系列轉換，將這一形式化的在此基礎上，通過一系列轉換，將這一形式化的 需求規約轉化為它的實現。需求規約轉化為它的實現。 其中，如果需求規約發生變化的話其中，如果需求規約發生變化的話,可以重新應用可以重新應用 這些轉換這些轉換, 對其實現進行

44、更新對其實現進行更新. 對于形式化的表示，需要在研究環境之外所使用對于形式化的表示，需要在研究環境之外所使用 的環境中保持這一風范的環境中保持這一風范.其中，第四代風范其中，第四代風范 是圍繞特定語言和工具而設計的。這一風范的過程是圍繞特定語言和工具而設計的。這一風范的過程,依據高層依據高層 描述，自動生成代碼。描述，自動生成代碼。 軟件開發技術經常被認為經歷了以下四代：軟件開發技術經常被認為經歷了以下四代： 第一代是單個開發人員使用低級程序設計語言第一代是單個開發人員使用低級程序設計語言. 第二代第二代,使使用過程語言用過程語言,為多用戶開發軟件為多用戶開發軟件.第三代其主要特征是使用高級第

45、三代其主要特征是使用高級通用的語言通用的語言,為大量工業應用開發軟件為大量工業應用開發軟件.隨后隨后,出現并使用了高出現并使用了高級的非過程語言級的非過程語言,稱為第四代稱為第四代.第四代開發風范沒有廣泛地應用第四代開發風范沒有廣泛地應用,只是在一些特定的應用領只是在一些特定的應用領域得以應用域得以應用,并通常使用數據庫系統保持所有開發信息并通常使用數據庫系統保持所有開發信息.原因：原因： 這些特定語言和工具限制了開發中對其它技術的選擇這些特定語言和工具限制了開發中對其它技術的選擇; 為了完成軟件產品的開發為了完成軟件產品的開發,必須學習大量設計和實現工作必須學習大量設計和實現工作.軟件生存周

46、期過程軟件生存周期過程軟件開發涉及的基本問題軟件開發涉及的基本問題 軟件開發本質軟件開發本質軟軟件件生生存存周周期期過過程程定義定義軟軟件件生生存存周周期期模模型型軟軟件件工工程程生生存存周周期期過過程程活活動動與與定定序序形形成成軟件開發方法學軟件開發方法學 結構化方法結構化方法 面向對象方法面向對象方法 面向數據結構面向數據結構 方法方法 維也納開發方維也納開發方 法法(VDM)給給出出實實現現開開發發過過程程的的途途徑徑IT項目管理項目管理 管理活動管理活動 管理技術與方法管理技術與方法作用于作用于 1)做哪些工作做哪些工作? 2)誰做誰做? 3)如何組織這些工作如何組織這些工作? 4)

47、怎么做怎么做? 5)如何管理如何管理? IT項目管理知識結構項目管理知識結構二、二、軟件生存周期過程軟件生存周期過程 - -回答要做哪些回答要做哪些“工作工作”，而沒有回答如何進行，而沒有回答如何進行“工作工作” 1 1、基本概念、基本概念 為了表述軟件開發需要做為了表述軟件開發需要做“什么活什么活( (映射映射) )”, ,引入了以下三引入了以下三 個概念：個概念： 軟件過程軟件過程(process)(process)：活動的一個集合；：活動的一個集合； 活動活動(activity)(activity)：任務的一個集合；：任務的一個集合； 任務任務(task)(task)： 將輸入轉換為輸出

48、的操作。將輸入轉換為輸出的操作。 2 2 過程分類過程分類 按過程的主體按過程的主體, ,可分為三類過程可分為三類過程： 1 1）基本過程）基本過程(primary processes)(primary processes) 是指那些與是指那些與軟件生產軟件生產直接相關的活動集。直接相關的活動集。 2 2）支持過程）支持過程(supporting processes )(supporting processes ) 是有關各方按其目標所從事的一系列是有關各方按其目標所從事的一系列支持支持活動集。活動集。 3 3）組織過程）組織過程(institutional processes)(instit

49、utional processes) 是指那些與是指那些與軟件生產組織軟件生產組織有關的活動集。有關的活動集。 基本過程基本過程支持過程支持過程組織過程組織過程1 1）基本過程基本過程 又按過程中活動的不同主體，將基本過程（類）分又按過程中活動的不同主體，將基本過程（類）分 為為5 5個過程個過程：獲取過程、供應過程、開發過程、：獲取過程、供應過程、開發過程、 運行過程、維護過程運行過程、維護過程 獲取過程獲取過程基本過程基本過程支持過程支持過程組織過程組織過程組織為組織為供應過程供應過程開發過程開發過程運行過程運行過程維護過程維護過程例如例如1：開發過程開發過程 是是軟件開發者軟件開發者所從

50、事的一系列活動。所從事的一系列活動。 包括包括13個活動：個活動： 過程的實施準備過程的實施準備 系統需求分析系統需求分析 系統結構設計系統結構設計 軟件需求分析軟件需求分析 軟件體系結構設計軟件體系結構設計 軟件詳細設計軟件詳細設計 軟件編碼和測試軟件編碼和測試 軟件集成軟件集成 軟件合格測試軟件合格測試 系統集成系統集成 系統合格測試系統合格測試 軟件安裝軟件安裝 軟件驗收支持軟件驗收支持 （2 2）支持過程支持過程 又按過程中活動的不同主體，將支持過程（類）分為又按過程中活動的不同主體，將支持過程（類）分為 8 8個過程個過程：文檔過程、配置管理過程、質量保證、驗證過程、文檔過程、配置管

51、理過程、質量保證、驗證過程、確認過程、聯合評審、審計過程、確認過程、聯合評審、審計過程、 問題解決等。問題解決等。文檔過程文檔過程基本過程基本過程支持過程支持過程組織過程組織過程組織為組織為配置管理過程配置管理過程質量保證過程質量保證過程驗證過程驗證過程聯合評審過程聯合評審過程確認過程確認過程審計過程審計過程問題解決過程問題解決過程例如例如2:2:文檔過程文檔過程 是記錄由某一過程或活動所產生信息的過程是記錄由某一過程或活動所產生信息的過程 包括包括4 4個活動個活動：過程的實施準備：過程的實施準備 設計與開發設計與開發 制作與發行制作與發行 維護維護 其中的活動：其中的活動：過程的實施準備過

52、程的實施準備 主要任務主要任務：開發一個計劃，用于標識軟件產品生存周期中要開發一個計劃，用于標識軟件產品生存周期中要產生的文檔對于所標識的每一個文檔，應給出：產生的文檔對于所標識的每一個文檔，應給出： 標題或名字標題或名字 目的目的 讀者讀者 文檔輸入文檔輸入、開發、評審、修改、提交、存儲、開發、評審、修改、提交、存儲、維護以及配置管理等的規程和責任維護以及配置管理等的規程和責任其中的活動：其中的活動：設計與開發設計與開發 主要任務主要任務： 根據適用的文檔標準，設計每一文檔的格式、內根據適用的文檔標準，設計每一文檔的格式、內 容說明、圖表設置以及包裝等。容說明、圖表設置以及包裝等。 可以使用

53、自動化的文檔工具，確保每個文檔輸入可以使用自動化的文檔工具，確保每個文檔輸入數據的來源和適用性；數據的來源和適用性； 按文檔標準，編輯并評審每一文檔的格式、技術按文檔標準，編輯并評審每一文檔的格式、技術內容和表示風格在分發前需經主管人員批準。內容和表示風格在分發前需經主管人員批準。3 3組織過程組織過程（Organizational life cycle processesOrganizational life cycle processes）分為分為4 4個過程個過程：管理過程、基礎設施過程、培訓過程、改進過程管理過程、基礎設施過程、培訓過程、改進過程 管理過程管理過程基本過程基本過程支持過

54、程支持過程組織過程組織過程組織為組織為基礎設施過程基礎設施過程培訓過程培訓過程過程改進過程過程改進過程例如例如3 3：管理過程：管理過程 管理過程包括由管理其對應過程的任何一方所執行的一般管理過程包括由管理其對應過程的任何一方所執行的一般性活動和任務，管理人員負責：性活動和任務，管理人員負責：產品管理；產品管理；項目管理，以及項目管理，以及對所應用的那些過程（例如，獲取、供應、開發、運對所應用的那些過程（例如，獲取、供應、開發、運行、維護或支持過程）的任務管理。行、維護或支持過程）的任務管理。 主要活動包括主要活動包括: 過程的啟動和范圍定義過程的啟動和范圍定義 規劃規劃 實施與控制實施與控制

55、 評審與評估評審與評估 測量測量 收尾（收尾（closure） 其中的活動：其中的活動：過程的啟動和范圍定義過程的啟動和范圍定義 主要任務主要任務： 通過建立那些要承擔的過程的需求，啟動該管理過程通過建立那些要承擔的過程的需求，啟動該管理過程通過檢查執行并管理這些過程所需要的資源（人通過檢查執行并管理這些過程所需要的資源（人、物物 資資、技術和環境）是否可用技術和環境）是否可用、充分和適用，以及時間充分和適用，以及時間 上是否可達，來建立這些過程的可行性上是否可達，來建立這些過程的可行性必要的話，按各方共識，修改這些過程的需求，以必要的話，按各方共識，修改這些過程的需求，以達成完成準則達成完成

56、準則. . 其中的活動其中的活動: :規劃規劃 主要任務主要任務： 為過程的執行制定計劃。該計劃應包括有關活動和任務的為過程的執行制定計劃。該計劃應包括有關活動和任務的 描述，并標識即將提供的軟件產品。該計劃的主要內容描述，并標識即將提供的軟件產品。該計劃的主要內容: 既時完成任務的進度安排；既時完成任務的進度安排； 工作量的估計；工作量的估計； 執行任務所需要的適當資源；執行任務所需要的適當資源； 任務的分配；任務的分配； 職責的分派；職責的分派； 與任務或過程自身有關的風險與任務或過程自身有關的風險( (量化量化) )； 在整個過程中采用的質量控制測量；在整個過程中采用的質量控制測量； 與

57、過程執行有關的費用；與過程執行有關的費用； 環境和基礎設施的規約。環境和基礎設施的規約。 其中的活動其中的活動: :實施與控制實施與控制 主要任務主要任務： 啟動管理計劃的實施，以滿足所設定的目標和準則，并對過啟動管理計劃的實施，以滿足所設定的目標和準則，并對過程實施控制。程實施控制。 監督過程的執行，提供過程進展的內部報告，并按照合同的監督過程的執行，提供過程進展的內部報告，并按照合同的規定向需方提供過程進展的外部報告。規定向需方提供過程進展的外部報告。 調查、分析和解決在過程執行期間發現的問題。問題的解決調查、分析和解決在過程執行期間發現的問題。問題的解決可能導致對計劃的變更。對變更的影響

58、進行確定、控制和監督可能導致對計劃的變更。對變更的影響進行確定、控制和監督。問題及其解決方案應形成文檔。問題及其解決方案應形成文檔。 按協商確定的時間，報告過程進展情況，聲明按計劃進行，按協商確定的時間，報告過程進展情況，聲明按計劃進行，并解決進展中的疏漏情況。按照組織規程和合同的要求，這種并解決進展中的疏漏情況。按照組織規程和合同的要求，這種報告包括內部報告和外部報告。報告包括內部報告和外部報告。 其中的活動其中的活動: :評審與評估評審與評估 主要任務主要任務： 對軟件產品和計劃進行評價，以確定是否滿足需求。對軟件產品和計劃進行評價，以確定是否滿足需求。 對在過程執行期間完成的軟件產品、活

59、動和任務的評價結果對在過程執行期間完成的軟件產品、活動和任務的評價結果進行評估，以確定是否達到目標和完成計劃。進行評估，以確定是否達到目標和完成計劃。 其中的活動其中的活動: :測量測量 主要任務主要任務： 建立并維護測量承諾。確保滿足所有的測量過程的資源、人建立并維護測量承諾。確保滿足所有的測量過程的資源、人員和承諾的先決條件。該任務的結果是員和承諾的先決條件。該任務的結果是:給出了從管理到支持給出了從管理到支持測量過程的承諾，提供了在該標準已為測量過程標識并分配職測量過程的承諾，提供了在該標準已為測量過程標識并分配職責方面的人員能力，提供了可用于策劃和實施測量過程的資源責方面的人員能力，提

60、供了可用于策劃和實施測量過程的資源。 規劃測量過程。制定一個詳細的計劃以啟動、指導、監督并規劃測量過程。制定一個詳細的計劃以啟動、指導、監督并評價數據收集、分析、解釋和存儲活動。該任務執行的結果是評價數據收集、分析、解釋和存儲活動。該任務執行的結果是:提供了一些規劃信息，包括已定義的那些組織單元所需要的提供了一些規劃信息，包括已定義的那些組織單元所需要的信息以及已獲取并利用的所要求的支持技術。信息以及已獲取并利用的所要求的支持技術。 按計劃進行測量。根據測量計劃任務的輸出生成信息產品和按計劃進行測量。根據測量計劃任務的輸出生成信息產品和性能測量（值）。該任務執行的結果能保證：收集到數據、以性能測量（值