第2章 軟件項目管理基礎ppt課件

1、第二章 軟件工程管理根底 主要內容一工程管理概述軟件工程管理的概念、目的和特點 工程管理包括4種根本活動工程的幾個階段 工程管理根本概念 義務和活動任務產品和任務包 任務分解構造 義務模型技藝矩陣組織組織構造圖軟件工程管理方案主要內容二工程管理活動 方案工程組織工程控制工程終結工程主要內容三2.1 工程管理概述 軟件工程管理是為了使軟件工程可以按照預定的本錢、進度、質量順利完成，而對本錢、人員、進度、質量、風險等進展分析和管理的活動。軟件工程管理的根本目的是為了讓軟件工程，尤其是大型工程的整個軟件生命周期都能在管理者的控制之下，以預定本錢按期、按質的完成軟件，然后交付用戶運用。 軟件工程管理的

2、特殊性軟件是純知識產品，其開發(fā)進度和質量很難估計和度量，消費效率也難以預測和保證。軟件系統(tǒng)的復雜性也導致了開發(fā)過程中各種風險的難以預見和控制。 工程管理包括4種根本活動方案：方案涉及詳細規(guī)定出要獲得的結果(要什么?)；產生這些結果所需求的活動和義務(做什么？怎樣做?) ；決議時間表和估計所需的資源(何時做?用什么做?)。 組織：組織規(guī)定了工程的組織和角色、責任的定義?？刂疲嚎刂拼_定正在進展的活動何時偏離了方案。 終止：終止是終了工程。 工程可以分成幾個階段 1、工程概念階段：關于工程的想法開場出現(xiàn)，通常伴隨著本錢效益分析和技術可行性研討。 2、工程定義階段：包括以下活動 問題定義：客戶和工程經

3、理定義系統(tǒng)的規(guī)模、目的日期。 初始的軟件工程管理方案SPMP：工程經理提供對工程總的看法、工程結果的描畫、任務分解構造、角色和責任、工程時間表、所需資源的預算和怎樣定義和處置風險的描畫。 初始的軟件體系構造3、工程開場階段：工程經理設置了工程的根底設備，雇用參與者，把他們組成團隊，并總結工程。工程開場包括以下活動根底設備設立：工程經理必需為工程的根底設備制定需求。這些需求描畫了工程參與者之間的交流渠道。 技藝定義：工程經理定義開發(fā)者的技藝和興趣，并在技藝矩陣中記錄它。 團隊集合：工程經理分配團隊參與者，定義團隊功能且選擇團隊指點。工程經理也為團隊成員定義所需的額外培訓和課程。最后，工程經理為團

4、隊分配任務包。 工程總結：工程經理，團隊指點和客戶正式開場啟開工程。4、工程穩(wěn)定形狀階段：團隊指點要擔任跟蹤團隊形狀和在團隊會議上提出問題。包括以下活動 工程規(guī)模定義控制風險管理工程重方案5、工程終止：提交工程結果并搜集工程歷史。主要活動有 交付客戶驗收測試安裝事后分析2.2 工程管理根本概念 在工程方案中一個主要的義務是把整個任務包分解成更小的義務。這包括2件事：定義適宜的義務定義義務間的依賴關系 2.2.1 義務和活動 義務是一項曾經定義得很好的任務，該任務可分配給一個工程參與者或分配給一個團隊。 義務是管理有關工程任務的最小的單元。義務包括對義務和繼續(xù)時間的描畫，還包括分配給所扮演角色的

5、參與者。 2.2.2 任務產品和任務包 任務包描畫了要消費的任務產品，要完成任務所需求的資源，所希望的繼續(xù)時間，輸入之間的相互依賴，也詳細闡明了驗收規(guī)那么和相關的個體或組織的單元的名字。 任務包是重要的管理產物，我們把它們分配給參與者去做。在義務定義之后可以定義任務包。 任何交付給用戶的任務產品叫交付品，例如用戶手冊。2.2.3 任務分解構造 在一個工程中，全體義務的層次描畫叫任務分解構造WBSWorkBreakdownStructure 。 任務分解構造是一個要做任務的非常簡單的模型。菱形符號表示整體與部分的關系,菱形符號一側表示整體;三角形符號表示普通與特殊的關系,三角形符號一側表示普通實

6、體 留意:任務分解構造不表示活動的順序。 2.2.4 義務模型 義務經過暫時的依賴關系聯(lián)絡起來。例如建屋頂?shù)牧x務不能在建墻義務終了前開場。 義務及其依賴關系的集合叫義務模型或者網絡圖。 兩條粗線段之間的各分支義務可以并行操作完成義務有一個繼續(xù)時間，由工程經理在工程開場前估算。一旦知道了義務間依賴關系和義務的繼續(xù)時間，工程經理能計算出工程能被完成的最短能夠時間。該時間在義務模型中表現(xiàn)為最長途徑，即關鍵途徑。關鍵途徑經過工程的第一項義務到最后一項義務，其長度由義務的繼續(xù)時間相加計算出來。在關鍵途徑上的義務延遲會導致整個工程的延遲，從而使工程延期。義務的最遲完成時間是在不耽擱工程的其他要完成的義務時

7、，義務能被推遲的最大時間。2.2.5 技藝矩陣 技藝矩陣是在工程中關于要完成義務的人的技藝、知識和興趣的一張簡單表。技藝矩陣的一行(或列)表示來自任務分解構造的任務單元義務、活動和工程功能。一列(或行)表示工程參與者。我們把3種工程區(qū)分開：主要技藝、次要技藝和興趣。主要技藝使一個人能勝任指點一個任務單元。次要技藝使一個人能參與義務。興趣表示在義務中一個人感興趣但不具備該技藝。2.2.6 組織 組織由組織單元及其交互(聯(lián)絡、溝通)組成。最小組織單元是一個參與者也叫個人或成員。一組參與者能組成部門、處或小組。2.2.7 組織構造圖 組織的表現(xiàn)及其信息構造通常叫組織圖。 軟件度量面向規(guī)模的度量規(guī)模：

8、代碼行數(shù)LOC、KLOC消費率：PL = L/EE:任務量人月每行代碼平均本錢：CL = S/LS：軟件總本錢，人民幣或美圓文檔與代碼比： DL = Pd/LPd：軟件文檔頁數(shù)代碼出錯率：EQRL = Ne/LNe：代碼錯誤數(shù)缺陷：依賴程序設計言語不利于精巧的設計開發(fā)前、初期難以估算只適于過程式程序設計言語 軟件工程估算Putnam模型1978年，Putnam提出大型軟件工程任務量估算模型。 軟件交付時任務量最大，參與人員最多任務量與交貨時間的4次方成反比，提早10%的時間要添加52%的任務量。任務量隨時間的添加不呈線性增長趨勢，參與開發(fā)的人數(shù)不應該一成不變。2.2.8 軟件工程管理方案 軟件

9、工程管理方案SPMP中的文件在工程總結大會之前創(chuàng)建，并且當義務完成和步驟更新的時候被更新，這種更新將貫穿整個工程。SPMP的運用者包括管理者和開發(fā)者。SPMP有五部分。1.引見1.1 工程概略1.2 工程交付品1.3 文檔的演化1.4 參考書1.5 定義和縮寫表2.工程組織2.1 過程模型2.2 組織構造2.3 組織邊境和接口2.4 工程責任3.管理過程3.1 管理目的和優(yōu)先級3.2 假設，依賴和限制3.3 風險管理3.4 監(jiān)視和控制機制4.技術過程4.1 方法，工具和技術4.2 軟件文檔4.3 工程支持功能5.任務元素，日程表和預算軟件工程管理方案SPMP 2.3 工程管理活動 在工程定義期

10、間，工程經理的主要活動是定義組織構造和定義任務產品、義務、時間表和角色。團隊指點在工程定義階段的最后時辰參與工程，他們的主要任務是在穩(wěn)定形狀下監(jiān)視和管理團隊。 2.3.1方案工程 定義問題、確定初始義務模型和組織構造、評價所需的資源，如人員和資金。這一階段要完成以下的任務： 1問題陳說：記述了當前情況、要支持的功能和系統(tǒng)要運用的環(huán)境，也要定義客戶希望的產品、交付日期和一套驗收規(guī)范，能夠也指定了開發(fā)環(huán)境中的限制，例如要用的編程言語。2頂層設計：頂層設計描畫了系統(tǒng)的軟件體系構造，應由軟件構造師完成。軟件構造師定義主要的子系統(tǒng)及其效力，但還不定義子系統(tǒng)的界面。3軟件工程管理方案SPMP：描畫了工程的

11、一切管理方面，特別是任務分解構造、日程表、組織、任務包和預算。2.3.2組織工程 雇用參與者、確定技藝、為參與者分配角色和責任并組織指點與工程總結有關的會議。 1設立交流設備2定義技藝3分配管理角色4分配技術角色5處置技藝缺乏6選擇團隊規(guī)模三個成員。 四個成員。 五個或六個成員。這是規(guī)模理想的軟件開發(fā)團隊。 七個成員。 八個和更多成員。7聚集團隊(為每個團隊組織參與人員)8總結會議9對工程范圍達成一致在工程總結完成和對工程范圍獲得一致后，工程進入穩(wěn)定形狀。 2.3.3控制工程 工程監(jiān)視、風險管理和工程協(xié)議。 為了在工程穩(wěn)定階段做出有效的決議，工程經理需求準確的形狀信息。不幸的是，搜集準確的形狀

12、信息非常困難。 可以用如下一些工具來搜集形狀信息。1. 會議2. 度量規(guī)范：3.風險管理：風險管理關注工程定義中能夠存在的問題，并希望在嚴重影響交付日期或預算之前闡明這些內容。風險管理的關鍵點是能準確及時地報告風險和問題。風險管理的第一步是定義風險。風險可以是管理方面的，也可以是技術方面的。 標明風險的優(yōu)先級能使工程經理專注于關鍵風險的管理。風險按它們能變成問題的能夠性，以及當風險變成問題時，對工程發(fā)生的潛在影響，能被分成4類：很能夠的，存在高潛在影響不太能夠的，存在高潛在影響很能夠的，存在低潛在影響不太能夠的，存在低潛在影響。 2.2.4終結工程 在工程終結階段工程經理為客戶預備了驗收測試、管理系統(tǒng)集成、測試和在客戶方的安裝。最后工程經理檢查工程總結。 1驗收系統(tǒng)。 2安裝。 3回想。2.7 軟件過程及軟件成熟度模型CMM背景開發(fā)組織：經過CMM度量找到本人的優(yōu)勢和差距客戶：尋求適宜的開發(fā)商開展1986年11月，美國卡內基.梅隆大學，啟動1991年8月，公開發(fā)布CMM v1.01993年2月，CMM 1.1近幾年來，CMM又推出了2.0 版本，同時進入了ISO 體系，稱為 ISO/IEC15504 或SPICE.2.7 CMM根本概念關鍵過程域：描畫軟件過程的屬性，經過完成一組相互關聯(lián)的活動，實現(xiàn)一組對建立過程才干至關重要的目的