第1章軟體專案管理概述1.1專案與軟體專案的概念

專案定義和特徵

——專案是為了創(chuàng)造一個唯一的產(chǎn)品或提供一個唯一的服務而進行的臨時性的努力。特徵：

目標性相關性週期性獨特性約束性不確定性結果的不可逆轉性專案與軟體專案的概念臨時性專案有明確的開始與截止日期專案合同的起止日期當達到專案的目標時即專案的截止日期；或專案被中止/取消的日期專案的臨時性並不意味著專案所提交的產(chǎn)品或服務也是一次性的（一次性紙杯的生產(chǎn)）專案所面臨的市場機遇往往也是臨時性的（沒有企業(yè)願意在2009年生產(chǎn)北京奧運的徽章）專案組也往往是臨時性的，當專案結束時，專案組也隨之解散（或釋放）專案與軟體專案的概念獨特的產(chǎn)品或服務專案所產(chǎn)生的產(chǎn)品或服務是獨一無二的（包括合同的簽訂人、位置等方面的資訊）對於批量生產(chǎn)的商品（例如空調(diào)或冰箱）則不具備獨特性，而例如北京聯(lián)通計費專案則具有獨特性諮詢和會計審計服務專案與軟體專案的概念以下哪些是專案呢？上課野餐活動集體婚禮社區(qū)保安開發(fā)微軟的操作系統(tǒng)每天的衛(wèi)生保潔神舟飛船計畫?專案與軟體專案的概念

日常運作專案上課野餐活動集體婚禮社區(qū)保安開發(fā)操作系統(tǒng)每天的衛(wèi)生保潔神州飛船計畫專案與軟體專案的概念

由美國國防部（DoD）資助軟體工程協(xié)會（SEI）開發(fā)U.S.Army,Navy,AirForceFederalAviationAdministrationNationalSecurityAgencySoftwareEngineeringInstituteADP,Inc.AT&TLabsBAEBoeingComputerSciencesCorporationEERSystemsEricssonCanadaErnstandYoungGeneralDynamicsHarrisCorporationHoneywellKPMGLockheedMartinMotorolaNorthropGrummanPacificBellQ-LabsRaytheonReutersRockwellCollinsSAICSoftwareProductivityConsortiumSverdrupCorporationTeraQuestThomsonCSFTRW專案與軟體專案的概念專案與日常運作的區(qū)別：專案是一次性的，日常運作是重複進行的專案是以目標為導向的，日常運作是通過效率和有效性體現(xiàn)的專案是通過與專案經(jīng)理及其團隊工作完成的，而日常運作是職能式的線形管理專案存在大量的變更管理，而日常運作則基本保持持續(xù)的連貫性的專案與軟體專案的概念軟體專案的特點

除了專案的特徵，軟體專案還具有以下特點：

軟體是邏輯實體，不是具體的物理實體，具有抽象性

軟體的開發(fā)受電腦系統(tǒng)的限制，對硬體系統(tǒng)有不同程度的

依賴

軟體具有複雜性特點，其開發(fā)成本昂貴，制約因素很多專案與軟體專案的概念

不同因素相互作用圖示專案與軟體專案的概念

實現(xiàn)專案目標的制約因素本章內(nèi)容提要

專案與軟體專案的概念

1.1

專案管理的概念

1.2

軟體專案生命期與管理過程

1.3

本書內(nèi)容的組織

1.4

本章小結1.5

復習思考題1.61.2專案管理的概念專案管理就在我們身邊解決一個問題組織一個活動創(chuàng)造一個新事務跟蹤一個具體的任務當我們覺得資源缺乏的時候……生活中的專案生日聚會野餐活動集體婚禮社會中的大專案微軟的操作系統(tǒng)阿波羅計畫神州飛船計畫專案管理的概念專案管理的定義專案管理是以專案為對象，通過使用知識、技能、工具和方法來組織、計畫、實施並監(jiān)控專案，使之滿足專案目標需求的過程。軟技巧Samples（領導、團隊建設、衝突解決、激勵、訓練、協(xié)商、溝通、傾聽）硬技能Samples（計畫、跟蹤、控制、報告）專案管理的概念軟體專案管理的必要性無規(guī)則、混亂的開發(fā)狀態(tài)，進度滯後，費用超支等失敗的例子很多業(yè)務失敗，合同糾紛，法律訴訟，客戶投訴等困擾軟體業(yè)美國1999年軟體專案的統(tǒng)計專案管理的概念軟體危機就是軟體生產(chǎn)能力和業(yè)務發(fā)展需求不相適應的現(xiàn)象就是弱的軟體生產(chǎn)能力和強的業(yè)務發(fā)展需求之間的矛盾軟體危機表現(xiàn)開發(fā)過程隨心所欲時間計畫和費用估算缺乏現(xiàn)實的基礎管理者主要在應付突發(fā)事件對產(chǎn)品品質(zhì)缺乏客觀基礎軟體開發(fā)的成敗建立在個人能力基礎上專案管理的概念成功的專案滿足或者超過干係人的期望專案管理的概念專案管理的基本內(nèi)容PMBOK:AguidetotheProjectmanagementBodyOfKnowledge

專案管理的概念PMBOK9個知識領域的關係專案管理的概念PMBOK9大過程領域專案管理的概念PMBOK5大過程組本章內(nèi)容提要

專案與軟體專案的概念

1.1

專案管理的概念

1.2

軟體專案生命期與管理過程

1.3

本書內(nèi)容的組織

1.4

本章小結1.5

復習思考題1.61.3軟體專案生命期與管理過程軟體專案生命期

計畫階段定義系統(tǒng)，確定用戶的要求或總體研究目標，提出可行的方案，包括資源、成本、效益、進度等的實施計畫。進行可行性分析並制定粗略計畫。需求分析階段確定軟體的功能、性能、可靠性、介面標準等要求，根據(jù)功能要求進行數(shù)據(jù)流程分析，提出初步的系統(tǒng)邏輯模型，並據(jù)此修改專案實施計畫。軟體設計階段它包括系統(tǒng)概要設計和詳細設計。在概要設計中，要建立系統(tǒng)的整體結構，進行模組劃分，根據(jù)要求確定介面。在詳細設計中，要建立演算法、數(shù)據(jù)結構和流程圖。軟體專案生命期與管理過程編碼階段把流程圖翻譯成程式，並對程式進行調(diào)試。測試階段通過單元測試，檢驗模組內(nèi)部的結構和功能；通過集成測試，把模組連接成系統(tǒng)，重點尋找介面上可能存在的問題；確認測試，即按照需求的內(nèi)容逐項進行測試；系統(tǒng)測試，就是到實際的使用環(huán)境中進行測試。單元測試和集成測試由開發(fā)者自己完成，確認測試和系統(tǒng)測試則由用戶參與完成。運行維護階段它一般包括三類工作，為了修改錯誤而做的改正性維護；為了適應環(huán)境變化而做的適應性維護；為了適應用戶新的需求而做的完善性維護，有時會成為二次開發(fā)，進入一個新的生命期，再從計畫階段開始。軟體專案生命期與管理過程

——不要強行照搬書上的軟體工程生命週期軟體專案生命期與管理過程專案生命週期階段概念（Concept）開發(fā)（Development）實施（Implementation）結束（Termination）思考專案生命週期中風險最大的是哪個階段？專案生命週期中衝突最多的是哪個階段？軟體專案生命期與管理過程專案生命週期的影響軟體專案生命期與管理過程軟體專案管理過程

軟體專案管理的核心啟動計畫控制結束軟體專案生命期與管理過程專案管理過程包括的主要工作制定技術目標組建專案組制訂專案計畫處理範圍變化控制實際進展整理、完善技術檔案形成知識網(wǎng)路軟體專案生命期與管理過程影響專案成功的因素專案的目標、範圍是否明確是否獲得領導的積極支持專案的組織是否健全、穩(wěn)定是否建立了有序的、有效的、良好的溝通管道是否具有有效、全面的專案管理，嚴格的變更控制是否建立了良好的、積極的、團隊合作的工作氛圍專案經(jīng)理PM的經(jīng)驗軟體專案生命期與管理過程專案生命期中的幾個概念

——專案生命期中與時間相關的重要概念

檢查點(CheckPoint)

它指在規(guī)定的時間間隔內(nèi)對專案進行檢查，比較實際現(xiàn)狀與計畫之間的差異，並根據(jù)差異進行調(diào)整里程碑(MileStone)它是完成階段性工作的標誌，不同類型的專案里程碑不同基線(BaseLine)它指一個(或一組)配置項在專案生命期的不同時間點上，通過正式評審而進入正式受控的一種狀態(tài)本章內(nèi)容提要

專案與軟體專案的概念

1.1

專案管理的概念

1.2

軟體專案生命期與管理過程

1.3

本書內(nèi)容的組織

1.4

本章小結1.5

復習思考題1.61.4本書內(nèi)容的組織RoadMap

課程概述

合同管理

生存期

團隊管理

任務分解需求管理

規(guī)模估算

成本估算

進度估算

進度計畫

風險計畫

跟蹤控制

配置管理

專案結束本章內(nèi)容提要

專案與軟體專案的概念

1.1

專案管理的概念

1.2

軟體專案生命期與管理過程

1.3

本書內(nèi)容的組織

1.4

本章小結1.5

復習思考題1.61.5本章小結專案與軟體專案管理的概念、特點、過程及其重要性。專案是為實現(xiàn)一個獨特目的而進行的臨時性任務，專案具有獨特性、臨時性及需要資源等特性，每個專案都有一個專案發(fā)起人並含有不確定性。專案管理的三項約束是指管理專案的範圍、時間和成本這三個維度。專案管理是指在專案活動中運用相關的知識、技能、工具和技術，以滿足專案要求的活動。利益相關者是指參與專案或受專案活動影響的人。專案管理框架包括利益相關者、專案管理知識領域和專案管理工具與技術。知識領域包括專案綜合管理、專案範圍、專案時間、專案成本、專案品質(zhì)、人力資源、專案溝通、專案風險和專案採購管理。過程管理在軟體專案管理中有著重要的作用，通過不斷地優(yōu)化和規(guī)範過程，可以幫助企業(yè)提高軟體生產(chǎn)能力。軟體專案管理的核心是專案規(guī)劃和專案跟蹤控制。本章內(nèi)容提要

專案與軟體專案的概念

1.1

專案管理的概念

1.2

軟體專案生命期與管理過程

1.3

本書內(nèi)容的組織

1.4

本章小結1.5

復習思考題1.61.6復習思考題1.什麼是專案？它與多數(shù)人的日常工作有什麼不同？2.分別列舉三個專案活動的例子和三個不屬於專案活動的例子。3.專案管理與一般管理有什麼不同？4.簡述軟體專案管理的過程。5.用你自己的話解釋三項約束的含義是什麼，並通過一個你熟悉的實例解釋三項約束。6.分別舉出一個成功的和失敗的軟體專案的例子。第2章軟體專案合同管理本章內(nèi)容提要

合同管理概述合同管理概述

2.1

需方合同環(huán)境

2.2

供方合同環(huán)境

2.3

企業(yè)內(nèi)部合同環(huán)境

2.4

本章小結

2.5

復習思考題

2.62.1合同管理概述合同的概念

——合同是使賣方負有提供具體產(chǎn)品和服務的責任，買方負有為該產(chǎn)品和產(chǎn)品服務付款的責任的一種雙方相互負有義務的協(xié)議。合同定義了合同簽署方的權利與義務，以及違背協(xié)議會造成的相應法律後果；合同監(jiān)督專案執(zhí)行的各方履行其權利和義務，它是具有法律效力的檔；圍繞合同，存在合同簽署之前和合同簽署之後的一系列工作。合同管理概述技術合同

軟體專案合同主要是技術合同；技術合同是法人之間、法人和公民之間、公民之間以技術開發(fā)、技術轉讓、技術諮詢和技術服務為內(nèi)容，明確相互權利義務關係所達成的協(xié)議；技術合同有三種環(huán)境：需（甲）方環(huán)境、供（乙）方環(huán)境和內(nèi)部環(huán)境；技術合同一般包括主合同和合同附件。

合同管理概述專案名稱；專案的技術內(nèi)容、範圍、形式和要求；專案實施計畫、進度、期限、地點和方式；專案合同價款、報酬及其支付方式；專案驗收標準和方法；各方當事人義務或協(xié)作責任；技術成果歸屬和分享及後續(xù)改進的提供與分享規(guī)定；技術保密事項；風險責任的承擔；違約金或者損失賠償額的計算方法、仲裁及其它。

軟體專案主合同至少應包括以下內(nèi)容合同管理概述系統(tǒng)的商務報價表；系統(tǒng)的需求規(guī)格說明書；專案的工程進度計畫書；技術服務承諾；培訓計畫；移交的用戶文檔和技術文檔；場地和環(huán)境準備要求；測試與驗收標準；初驗與終驗報告樣式範本；工程實施的分工介面定義。

軟體專案中常有以下合同附件合同管理概述合同生存期

合同準備合同終止合同管理合同簽署合同生存期的4個階段

合同生存期的4個階段

合同生存期的4個階段本章內(nèi)容提要

合同管理概述合同管理概述

2.1

需方合同環(huán)境

2.2

供方合同環(huán)境

2.3

企業(yè)內(nèi)部合同環(huán)境

2.4

本章小結

2.5

復習思考題

2.62.2需方合同環(huán)境企業(yè)在需方合同環(huán)境下，關鍵要素是提供準確、清晰和完整的需求，選擇合格的供方並對採購對象（採購對象包括產(chǎn)品服務、人力資源等）進行必要的驗收。這個需求可能來自於企業(yè)內(nèi)部的需要，也可能是在為客戶開發(fā)的軟體專案中的一部分，通過尋找合適的軟體開發(fā)商，將部分軟體外包給其他的開發(fā)商。需方合同環(huán)境合同準備招標書定義(採購需求定義)

啟動一個專案主要是由於存在一種需求，招標書定義主要是需方的需求定義，也就是甲方(買方)定義採購的內(nèi)容。供方選擇

招標檔確定後，就可以通過招標的方式選擇供方（乙方或者賣方）。合同文本準備

如果需方選擇了合適的供方（軟體開發(fā)商），需方應該與供方（軟體開發(fā)商）簽訂一個具有法律效力的合同；簽署合同之前需要起草一份合同文本。

需方合同環(huán)境招標書定義過程需方申請需求定義商務條件確定驗收標準確定資料彙集採購需求認可編寫招標檔招標檔需方合同環(huán)境供方選擇過程招標檔招標檔招標收集供方的建議書評定供方最終供方確定供方名單建議書需方合同環(huán)境合同文本準備過程採購資料合同草案制定合同草案評審合同草案修訂合同草案確定合同草案需方合同環(huán)境合同簽署合同簽署過程就是正式簽署合同，使之成為具有法律效力的檔；同時，根據(jù)簽署的合同，分解出合同中需方(甲方)的任務，並下達任務書，指派相應的專案經(jīng)理負責相應的過程。需方合同環(huán)境合同簽署過程合同草案談判日程確定合同草案提交合同條款協(xié)商合同簽署文本確定合同簽署文本任務書下達任務書合同簽署文本審閱合同簽署合同草案任務書任務書需方合同環(huán)境合同管理

——對於企業(yè)處於需方(甲方)的環(huán)境，合同管理是需方對供方(乙方)執(zhí)行合同的情況進行監(jiān)督的過程，主要包括：對需求對象（採購對象）的驗收驗收過程是需方對供方交付的產(chǎn)品或服務進行驗收檢驗，以保證它滿足合同條款的要求。對違約事件處理在合同的執(zhí)行過程中，如果供方發(fā)生與合同要求不一致的問題，導致違約事件，需要執(zhí)行違約事件處理過程。

需方合同環(huán)境驗收過程需求資料合同文本驗收清單制定驗收清制評審驗收計畫制定編寫驗收報告驗收問題處理計畫驗收報告確認驗收計畫執(zhí)行驗收報告需方合同環(huán)境違約事件處理過程違約事件報告違約事件通告處理方式確定處理違約事件處理報告提交違約事件處理報告需方合同環(huán)境合同終止

當專案滿足結束的條件，專案經(jīng)理或者合同管理者應該及時宣佈專案結束，終止合同的執(zhí)行，通過合同終止過程告知各方合同終止合同終止過程合同合同有關文檔歸檔合同終止通知專案執(zhí)行總結專案總結IBM軟體外包的一些策略IBM軟體外包的一些策略本章內(nèi)容提要

合同管理概述合同管理概述

2.1

需方合同環(huán)境

2.2

供方合同環(huán)境

2.3

企業(yè)內(nèi)部合同環(huán)境

2.4

本章小結

2.5

復習思考題

2.62.3供方合同環(huán)境企業(yè)在供方(乙方)合同環(huán)境下，關鍵要素是瞭解清楚需方（甲方）的要求並判斷企業(yè)是否有能力來滿足這些需求。作為軟體開發(fā)商，更多擔任的是供方的角色。

供方合同環(huán)境合同準備

企業(yè)作為供方，其合同準備階段包括三個過程：專案分析專案分析是供方分析用戶的專案需求，並據(jù)此開發(fā)出—初步的專案計畫，作為下一步能力評估和可行性分析之用。專案競標能力評估；可行性分析；參加競標。合同文本準備一般是需方(甲方)提供合同的框架結構，並起草主要內(nèi)容，供方(乙方)提供意見。供方合同環(huán)境專案分析過程

專案分析任務書招標檔需求管理者確定需求分析需求分析評審專案風險分析專案初步實施規(guī)劃初步實施規(guī)劃評審專案規(guī)模估算需求分析報告專案初步計畫供方合同環(huán)境專案競標過程

需求分析報告專案計畫技術能力要求確定人力源要求確定企業(yè)能力評定評估結果評審能力評估結果資金、管理要求確定實現(xiàn)環(huán)境要求確定用戶支持保證評估用戶資金保證評估可行性分析需求成熟度評估編寫專案建議書參加競標專案決策專案建議書供方合同環(huán)境合同文本準備採購資料合同草案制定合同草案評審合同草案修訂合同草案確定合同草案供方合同環(huán)境合同簽署供方的合同簽署過程也類似於需方的合同簽署過程，但是這個階段對於供方的意義是重大的，它標誌著一個軟體專案的有效開始，這個時候，應該正式確定供方的專案經(jīng)理。這裏需要說明的是專案任務書，專案任務書明確專案的目標、必要的約束，同時授權給專案經(jīng)理。專案任務書是專案正式開始的標誌，同時也是對專案經(jīng)理有效授權的依據(jù)。專案經(jīng)理需要對這個任務書進行確認。具體活動描述可以參見需方的合同簽署過程。供方合同環(huán)境合同管理

——企業(yè)處於供方的環(huán)境，合同管理主要包括：合同跟蹤管理過程合同修改控制過程違約事件處理過程產(chǎn)品交付過程產(chǎn)品維護過程供方合同環(huán)境合同執(zhí)行跟蹤管理過程

——合同跟蹤管理過程是供方跟蹤合同的執(zhí)行過程。

專案計畫專案計畫審批合同執(zhí)行管理規(guī)劃合同執(zhí)行跟蹤管理專案進展報告合同責任落實需求變更處理產(chǎn)品驗收供方合同環(huán)境合同修改控制過程

——

合同修改控制就是管理合同變更的過程。合同變更請求求合同變更評估合同變更評估合同修改策略確定合同修改處理相關活動產(chǎn)品調(diào)整處理結果報告處理報告供方合同環(huán)境違約事件處理過程

——

類似需方的情況，在此不再贅述。產(chǎn)品交付過程

——

產(chǎn)品交付過程是供方向需方提交最終產(chǎn)品的過程。

提交產(chǎn)品提交產(chǎn)品審查產(chǎn)品提交用戶雙方簽字認可通知相關各方供方合同環(huán)境產(chǎn)品維護過程

——

產(chǎn)品維護過程是供方對提交後的軟體產(chǎn)品進行後期維護的工作過程。維護需求求維護需求記錄維護分類響應策略雙方簽字認可維護需求評估維護協(xié)議確立維護任務下達維護任務單供方合同環(huán)境合同終止

——

在合同終止過程中，供方應該配合需方的工作，包括：專案的驗收、雙方認可簽字、總結專案的經(jīng)驗教訓、獲取合同的最後款項、開具相應的發(fā)票、獲取需方的合同終止的通知、將合同相關檔歸檔。合同合同有關文檔歸檔合同終止通知專案執(zhí)行總結專案總結本章內(nèi)容提要

合同管理概述合同管理概述

2.1

需方合同環(huán)境

2.2

供方合同環(huán)境

2.3

企業(yè)內(nèi)部合同環(huán)境

2.4

本章小結

2.5

復習思考題

2.62.4企業(yè)內(nèi)部合同環(huán)境內(nèi)部環(huán)境概述

——

企業(yè)內(nèi)部專案實施管理的核心是確定任務範圍和確保相關各方進行有效的配合，這可以通過相關各方之間的“協(xié)議”來保證，此處“協(xié)議”可視為“合同”。企業(yè)內(nèi)部專案“合同”無特別的商業(yè)約束。

本章內(nèi)容提要

合同管理概述合同管理概述

2.1

需方合同環(huán)境

2.2

供方合同環(huán)境

2.3

企業(yè)內(nèi)部合同環(huán)境

2.4

本章小結

2.5

復習思考題

2.62.5本章小結軟體專案技術合同的執(zhí)行過程可以劃分為四個階段，即：合同準備、合同簽署、合同管理與合同終止。針對企業(yè)在不同合同環(huán)境中承擔的不同角色，又可將合同管理分為需方合同管理、供方合同管理及內(nèi)部合同管理。作為軟體企業(yè)，一般是處於供方(乙方)的角色，因此，軟體企業(yè)的專案經(jīng)理應該重點掌握供方(乙方)的合同管理過程。合同標誌一個專案的真正開始，通過專案任務單明確專案經(jīng)理，從此，專案經(jīng)理可以真正行使相應的職責和權力。本章內(nèi)容提要

合同管理概述合同管理概述

2.1

需方合同環(huán)境

2.2

供方合同環(huán)境

2.3

企業(yè)內(nèi)部合同環(huán)境

2.4

本章小結

2.5

復習思考題

2.62.6復習思考題1.在你曾參與的軟體專案中，你是作為需方還是供方?2.假設你是某軟體企業(yè)的專案經(jīng)理，企業(yè)在競標一個軟體專案，現(xiàn)在需要你編寫一份合同文本的草案，請你試著編寫一份合同文本。3.假設你所在的單位準備加強內(nèi)部資訊化建設，試圖找一家軟體公司開發(fā)一個單位綜合資訊管理系統(tǒng)，請你擬定一份系統(tǒng)業(yè)務需求。第3章軟體開發(fā)過程管理本章內(nèi)容提要CMM和ISO9000

傳統(tǒng)軟體開發(fā)生命週期模型

擴展軟體開發(fā)生命週期模型

3.1品質(zhì)計畫

3.4案例分析

3.5本章小結

3.6復習思考題

3.73.23.3

軟體過程是指人們用於開發(fā)和維護軟體及其相關產(chǎn)品的一系列活動、方法、實踐和革新。軟體開發(fā)過程管理是指在軟體開發(fā)過程中，除了先進技術和開發(fā)方法外，還有一整套的管理技術。軟體過程改進是針對軟體生產(chǎn)過程中會對產(chǎn)品品質(zhì)產(chǎn)生影響的問題而進行的，它的直接結果是軟體過程能力的提高?，F(xiàn)在常見的軟體過程改進方法：ISO9000，SW-CMM和由多種能力模型演變而來的CMMI。3.1CMM和ISO90003.1.1SW-CMM和CMMI

SW-CMM簡介為了保證軟體產(chǎn)品的品質(zhì)，1991年美國卡內(nèi)基·梅隆大學軟體工程研究所（CMU/SEI）將軟體過程成熟度框架進化為軟體能力成熟度模型（CapabilityMaturityModelForSoftware，簡稱SW-CMM），併發(fā)布了最早的SW-CMM1.0版。

SW-CMM為軟體企業(yè)的過程能力提供了一個階梯式的進化框架，階梯共有五級。3.1.1SW-CMM和CMMI1初始級2可重複級3已定義級4已管理級5優(yōu)化級無序、混亂的軟體過程。依賴個別人的努力和機遇。建立基本的專案管理過程。相似專案，重複以往成果。文檔化、標準化和標準的軟體軟體過程。軟體過程和產(chǎn)品品質(zhì)有詳細的度量標準。持續(xù)的對過程進行改進。圖CMM分級標準3.1.1SW-CMM和CMMIKPA及KP除第一級外，SW-CMM的每一級都是按完全相同的結構組成的。每一級包含了實現(xiàn)這一級目標的若干關鍵過程域（KPA），每個KPA進一步包含若干關鍵實施活動（KP），無論哪個KPA，它們的實施活動都統(tǒng)一按六個公共屬性進行組織，即每一個KPA都包含六類KP：

1.目標

2.實施保證

3.實施能力

4.執(zhí)行活動

5.度量分析

6.實施驗證3.1.1SW-CMM和CMMICMMI簡介由於不同領域能力成熟度模型存在不同的過程改進，重複的培訓、評估和改進活動以及活動不協(xié)調(diào)等一些問題。於是由美國國防部出面，美國卡內(nèi)基·梅隆大學軟體工程研究所（CMU/SEI）於2001年12月發(fā)佈的CMMI1.1版本包括四個領域：軟體工程（SW）、系統(tǒng)工程（SE）、集成的產(chǎn)品和過程開發(fā)（IPPD）、採購（SS）。3.1.1SW-CMM和CMMI

CMMI有兩種不同的實施方法連續(xù)式－－主要是衡量一個企業(yè)的專案能力階段式－－主要是衡量一個企業(yè)的成熟度

CMMI的五個臺階完成級管理級定義級量化管理級優(yōu)化級

每一個臺階都是上面一階臺階的基石。要上高層臺階必須首先踏上較低一層臺階。

3.1.2ISO9000品質(zhì)標準

ISO9000

所謂“ISO9000”不是指一般意義上的一個品質(zhì)保證標準，而是一族系列標準的統(tǒng)稱。

作用強化品質(zhì)管理，提高企業(yè)效益；增強客戶信心，擴大市場份額；獲得了國際貿(mào)易“通行證”，消除了國際貿(mào)易壁壘；節(jié)省了第二方審核的精力和費用；在產(chǎn)品品質(zhì)競爭中永遠立於不敗之地；有效地避免產(chǎn)品責任；有利於國際間的經(jīng)濟合作和技術交流。3.1.3三者之間的比較

選擇SW-CMM還是CMMI的考慮實施企業(yè)的業(yè)務特點。實施企業(yè)對過程改進的熟悉程度。實施企業(yè)對過程改進專案的預算。實施企業(yè)是否可以使用階段式的演進路線。實施CMM與CMMI可以平滑的轉換。

ISO9001與CMM的關係ISO9001和CMM既有區(qū)別又相互聯(lián)繫，兩者不可簡單地互相替代。取得ISO9001認證並不意味著完全滿足CMM某個等級的要求。取得CMM第2級(或第3級)不能籠統(tǒng)地認為可以滿足ISO9001的要求。本章內(nèi)容提要CMM和ISO9000

傳統(tǒng)軟體開發(fā)生命週期模型擴展軟體開發(fā)生命週期模型

3.1品質(zhì)計畫

3.4案例分析

3.5本章小結

3.6復習思考題

3.73.23.3

軟體生命週期軟體從需求確定、設計、開發(fā)、測試直至投入使用，並在使用中不斷地修改、增補和完善，直至被新的系統(tǒng)所替代而停止該軟體的使用的全過程。

可劃分為以下子階段

1.可行性研究

2.需求分析和定義

3.總體設計

4.詳細設計

5.編碼（實現(xiàn)）

6.軟體測試、運行/維護據(jù)此相繼產(chǎn)生了瀑布模型、螺旋模型、進化模型、原型模型、增量模型等。本節(jié)分別對這幾種傳統(tǒng)的軟體開發(fā)生命週期模型予以介紹。

3.2傳統(tǒng)軟體開發(fā)生命週期模型3.2.1瀑布模型系統(tǒng)需求軟體需求分析設計編碼測試運行瀑布模型總結文檔驅動的模型階段間具有順序性和依賴性專案開發(fā)週期較長實際專案很少按照該模型給出的順序進行3.2.2原型模型3.2.2原型模型Prototypingmodel特點在需求定義之前，需要快速構建一個系統(tǒng)根據(jù)構建系統(tǒng)的優(yōu)缺點，用戶給開發(fā)人員提出回饋意見根據(jù)回饋意見修改軟體需求規(guī)格，以便系統(tǒng)可以更正確地反映用戶的需求減少各種假設以及風險3.2.3增量模型增量1增量2增量3增量4第一個增量發(fā)佈第二個增量發(fā)佈第三個增量發(fā)佈第四個增量發(fā)佈開發(fā)進度3.2.3增量模型

增量模型總結融合了瀑布模型和原型的迭代特徵。每一個增量均發(fā)佈一個可操作產(chǎn)品。3.2.4進化模型建造/修改原型聽取用戶意見用戶測試運行原型

這個模型可看作是重複執(zhí)行的多個瀑布模型。3.2.5螺旋模型原型1原型2原型3可運行原型需求計畫生存期計畫開發(fā)計劃集成與測試軟體需求需求確認設計確認與驗證

軟體產(chǎn)品設計詳細設計風險分析風險分析風險分析驗收測試實現(xiàn)集成與測試單元測試編碼開發(fā)、驗證下一產(chǎn)品實施工程提交線評審累計成本風險分析評價方案，識別風險、消除風險制訂計畫決定目標方案和限制客戶評估3.2.5螺旋模型

螺旋模型總結

基於風險驅動的開發(fā)模型,使用原型法或其他方法來儘量降低風險。適用於需求不明確的大規(guī)模軟體專案本章內(nèi)容提要CMM和ISO9000

傳統(tǒng)軟體開發(fā)生命週期模型

擴展軟體開發(fā)生命週期模型

3.1品質(zhì)計畫

3.4案例分析

3.5本章小結

3.6復習思考題

3.73.23.33.3.1極限模型極限模型簡介

2001年，為了避免許多公司的軟體團隊陷入不斷增長的過程泥潭，一批業(yè)界專家一起概括出了一些敏捷開發(fā)過程的方法：SCRUM，Crystal，特徵驅動軟體開發(fā)（FeatureDrivenDevelopment，簡稱FDD），自適應軟體開發(fā)（AdaptiveSoftwareDevelopment，簡稱ASD），以及最重要的極限編程（eXtremeProgramming,簡稱XP）。

3.3.1極限模型極限編程將開發(fā)階段的4個活動（分析、設計、編碼和測試）混合在一起，在全過程中採用迭代增量開發(fā)、回饋修正和反復測試。

3.3.1極限模型XP開發(fā)模型核心思想：交流（Communication）簡單（Simplicity）回饋（Feedback）進?。ˋggressiveness）

3.3.1極限模型優(yōu)點採用簡單計畫策略，不需要長期計畫和複雜模型，開發(fā)週期短；在全過程採用迭代增量開發(fā)、回饋修正和反復測試的方法，能夠適應用戶經(jīng)常變化的需求。

缺點目前主要在小規(guī)模專案上應用並取得成功，但是否適用於中等規(guī)模或大規(guī)模軟體產(chǎn)品，需慎重考慮；由於這個模型較新產(chǎn)品交付後維護成本是否降低，不能確定；對編碼人員的經(jīng)驗要求高

3.3.2Rational統(tǒng)一過程（RUP）3.3.2Rational統(tǒng)一過程（RUP）

用例驅動

Concise,simple,andunderstandable

以體系結構為中心

Effectivebasisforlarge-scalereuse

增量和迭代開發(fā)基於風險前驅的原則，漸進地展開分析、設計及其相關活動，每個迭代都會提供一次驗證和調(diào)整模型機會，推動軟體品質(zhì)的提升。3.3.3微軟產(chǎn)品開發(fā)週期模型微軟產(chǎn)品週期模型產(chǎn)品規(guī)劃階段測試階段產(chǎn)品開發(fā)階段發(fā)佈階段M1…MnCCZBBRTM/WRC1…RCnAlphaGoldenMastersBetaProductVisionFunctionSpecQFEsRTM/WQAMnM0本章內(nèi)容提要CMM和ISO9000

傳統(tǒng)軟體開發(fā)生命週期模型

擴展軟體開發(fā)生命週期模型

3.1品質(zhì)計畫

3.4案例分析

3.5本章小結3.6復習思考題

3.73.23.33.4.1品質(zhì)與品質(zhì)規(guī)劃

軟體品質(zhì)是“所有描述電腦軟體優(yōu)秀程度的特性的組合”。軟體品質(zhì)度量模型由三層組成第一層為品質(zhì)特性第二層為品質(zhì)子特性第三層稱為度量3.4.1品質(zhì)與品質(zhì)規(guī)劃ISO／IEC9126–1991（GB／T16260–1996）標準標準定義的6個品質(zhì)特性功能性可靠性易使用性高效性可維護性可移植性

品質(zhì)規(guī)劃指識別哪些品質(zhì)標準適用於軟體專案，並確定如何滿足這些標準的要求

3.4.2品質(zhì)體系、品質(zhì)手冊和品質(zhì)計畫

品質(zhì)體系指為保證產(chǎn)品、過程或服務品質(zhì)，滿足規(guī)定（或潛在）的要求，由組織機構、職責、程式、活動、能力和資源等構成的有機整體。

品質(zhì)手冊

是描述企業(yè)品質(zhì)體系的檔。品質(zhì)計畫是品質(zhì)管理（品質(zhì)計畫編制、品質(zhì)保證和品質(zhì)控制）的第一過程域。3.4.2品質(zhì)體系、品質(zhì)手冊和品質(zhì)計畫

品質(zhì)體系、品質(zhì)手冊和品質(zhì)計畫之間的關係品質(zhì)體系好比一個國家的法制機構，品質(zhì)手冊就如同憲法，是品質(zhì)體系的文檔化的體現(xiàn)。而為每個專案制定的品質(zhì)計畫類似地方法規(guī)，它在符合品質(zhì)手冊的前提下，根據(jù)自身的要求與特殊性，通過適當?shù)牟脺p修正而來。

關係圖3.4.3專案品質(zhì)計畫的內(nèi)容

專案實施總體目標品質(zhì)時間成本三者是一個相互制約、相互影響的統(tǒng)一體，其中任一專案標變化，都會引起另兩個目標變化，並受其制約。

專案分類品質(zhì)傾斜型體系工期傾斜型體系成本傾斜型體系3.4.3專案品質(zhì)計畫的內(nèi)容

編寫軟體品質(zhì)計畫涉及的範圍相當廣，不論是專案選型、軟體開發(fā)各階段，還是配置管理、崗位職責與團隊組織，又或是其他如專案制度的制定等等方面，都應該是包含在專案品質(zhì)計畫中的內(nèi)容。3.4.4品質(zhì)目標

軟體生命週期三大階段（以傳統(tǒng)的瀑布模型為例）軟體定義軟體開發(fā)軟體使用與維護階段

需要監(jiān)控的關鍵元素問題定義

關於規(guī)模和目標的報告書可行性研究系統(tǒng)的高層邏輯模型：數(shù)據(jù)流圖，成本/效益分析需求分析系統(tǒng)的邏輯模型：數(shù)據(jù)流圖（MSC圖），數(shù)據(jù)字典（類清單、對象間關係），演算法描述總體設計可能的解法：系統(tǒng)流程圖，成本/效益分析推薦的系統(tǒng)結構：層次圖，結構圖詳細設計

編碼規(guī)格說明綜合測試綜合測試方案和結果完整性一致的軟體配置維護完整準確的維護記錄3.4.4品質(zhì)目標各階段的關鍵元素3.4.5專案品質(zhì)計畫的編寫

品質(zhì)計畫應說明專案管理小組如何具體執(zhí)行它的品質(zhì)策略。目的規(guī)劃出哪些是需要被跟蹤的品質(zhì)工作，並建立文檔，此文檔可以作為軟體品質(zhì)工作指南，幫助專案經(jīng)理確保所有工作按計畫完成。

編寫準則具體情況具體對待，沒有統(tǒng)一定律。

3.4.6按照品質(zhì)計畫實施有效的品質(zhì)控制

品質(zhì)計畫確定後，按其建立的品質(zhì)管理體系，各責任單位必須按PDCA品質(zhì)環(huán)的要求，實施有效的品質(zhì)控制。

品質(zhì)控制可分為兩個階段監(jiān)測控制品質(zhì)控制應貫穿於專案的整個過程。專案收尾的兩個階段專案評估專案終止專案收尾階段的品質(zhì)控制是一個非常重要而又容易忽視的內(nèi)容。本章內(nèi)容提要CMM和ISO9000

傳統(tǒng)軟體開發(fā)生命週期模型

擴展軟體開發(fā)生命週期模型

3.1品質(zhì)計畫

3.4案例分析

3.5本章小結

3.6復習思考題

3.73.23.33.5案例分析

HRMS系統(tǒng)即人力資源管理系統(tǒng)，是為某跨國企業(yè)的ISS部門而開發(fā)的。

HRMS系統(tǒng)生存期模型選擇過程針對本項目的開發(fā)特點，參考企業(yè)的生存期模型說明和軟體過程體系，決定採用迭代增量式模型。

3.5案例分析HRMS項目生存期模型

本章內(nèi)容提要CMM和ISO9000

傳統(tǒng)軟體開發(fā)生命週期模型

擴展軟體開發(fā)生命週期模型

3.1品質(zhì)計畫

3.4案例分析

3.5本章小結3.6復習思考題

3.73.23.33.6本章小結講述了軟體開發(fā)過程管理需要掌握的部分知識。介紹了ISO9000，CMM和CMMI三種常見的軟體過程改進方法，並比較了它們之間的異同，對於選取哪種方法給予了建議。詳細介紹了多種軟體開發(fā)生命週期模型的特點、優(yōu)缺點，對於軟體開發(fā)中的相當重要的專案選型工作提供了參照。此外還介紹了品質(zhì)計畫的定義和詳細的模版。(品質(zhì)計畫的制定對於軟體品質(zhì)控制的重要性非同小可，它涉及的範圍很廣，需要制定的內(nèi)容相當多，部分內(nèi)容讀者可以在其他章節(jié)去詳細瞭解。)本章內(nèi)容提要CMM和ISO9000

傳統(tǒng)軟體開發(fā)生命週期模型

擴展軟體開發(fā)生命週期模型

3.1品質(zhì)計畫3.4案例分析

3.5本章小結

3.6復習思考題

3.73.23.33.7復習思考題CMM和CMMI的五個級別分別是什麼？CMM和CMMI的關係是什麼？在軟體企業(yè)中推行ISO9000的意義何在？傳統(tǒng)的軟體開發(fā)生命週期可以分為哪幾個子階段？原型模型可以細分為哪兩種？它們的內(nèi)容是什麼？你覺得進化模型和螺旋模型有哪些相似之處嗎？它們的核心思想是什麼？品質(zhì)體系、品質(zhì)手冊和品質(zhì)計畫的聯(lián)繫何在？在需求分析階段需要監(jiān)控的關鍵元素是什麼？第4章軟體專案團隊管理本章內(nèi)容提要

軟體團隊管理概述

4.1

軟體專案組織計畫編制

4.2

軟體專案團隊人員的獲取

4.3

軟體團隊建設

4.4

案例分析4.5

本章小結

4.6復習思考題

4.74.1軟體團隊管理概述

專案團隊是軟體專案中最重要的因素，成功的團隊管理是軟體專案順利實施的保證。軟體專案團隊軟體專案開發(fā)團隊是通過將不同的個體組織在一起，形成一個具有團隊精神的高效率隊伍來進行軟體專案的開發(fā)。軟體專案團隊包括所有的專案干係人。軟體團隊管理概述

專案干係人

指參與專案和受專案活動影響的人，包括：專案發(fā)起人資助者供應商專案組成員協(xié)助人員客戶使用者專案的反對人軟體團隊管理概述軟體專案團隊的特徵是一個臨時性的團隊是跨職能的在軟體專案不同階段中團隊成員具有不穩(wěn)定性成員具有極大的流動性年輕化程度高軟體專案團隊屬於高度集中的知識型團隊員工業(yè)績難以量化考核軟體專案團隊非常注重自我

高效的軟體開發(fā)團隊是建立在合理的開發(fā)流程及團隊成員密切合作的基礎之上，團隊成員需共同迎接挑戰(zhàn)、有效的計畫、協(xié)調(diào)和管理各自的工作直至成功完成專案目標。軟體團隊管理概述軟體專案團隊管理美國專案管理協(xié)會(ProjectManagementInstitute，簡稱PMI)的《專案管理知識體系指南》(ProjectManagementBodyofKnowledge，簡寫為PMBOK)對專案人力資源管理的定義為：最有效地使用參與專案人員所需的各項過程。包括針對專案的各個利益相關方展開的有效規(guī)劃、合理配置、積極開發(fā)、準確評估和適當激勵等方面的管理工作。軟體團隊管理概述軟體專案團隊管理的定義軟體專案團隊管理就是運用現(xiàn)代化的科學方法，對專案組織結構和專案全體參與人員進行管理，在專案團隊中開展一系列科學規(guī)劃、開發(fā)培訓、合理調(diào)配、適當激勵等方面的管理工作，使專案組織各方面人員的主觀能動性得到充分發(fā)揮，以實現(xiàn)專案團隊的目標。軟體團隊管理概述軟體專案團隊管理的任務

軟體專案團隊管理主要包括：團隊組織計畫指確定、記錄與分派專案角色、職責，並對請示彙報關係進行識別、分配和歸檔。團隊人員獲取指獲得專案所需的並被指派到專案的人力資源（個人或集體）。團隊建設既包括提高利害關係者作為個人做出貢獻的能力，也包括提高專案團隊作為集體發(fā)揮作用的能力。個人的培養(yǎng)（管理能力與技術水準）是團隊建設的基礎。團隊的建設是專案實現(xiàn)其目標的關鍵。軟體團隊管理概述軟體專案團隊管理工作結構軟體團隊管理概述

軟體專案團隊管理的重要性是軟體專案管理中至關重要的組成部分是有效地發(fā)揮每個參與專案的人員作用的過程人員的組織管理是影響軟體開發(fā)專案品質(zhì)的決定性因素

如果企業(yè)要想在軟體開發(fā)專案上獲得成功，他們就需要認識到專案人力資源管理的重要性，瞭解專案人力資源管理的知識體系及範疇，並將有效的管理理論和方法引入專案管理的過程中，充分發(fā)揮專案人員的積極性與創(chuàng)造力來實現(xiàn)企業(yè)的目標。本章內(nèi)容提要

軟體團隊管理概述

4.1

軟體專案組織計畫編制

4.2

軟體專案團隊人員的獲取

4.3

軟體團隊建設

4.4

案例分析4.5

本章小結

4.6復習思考題

4.74.2軟體專案組織計畫編制專案組織計畫編制概述大多數(shù)軟體專案中，組織計畫是在最早的專案階段編制的。組織計畫編制的結果應在整個專案過程中定期審查以保證其連續(xù)的適用性。如果初始的組織編制不再有效，應及時修正。軟體專案組織計畫編制專案組織計畫編制的輸入專案介面人員配備需求制約組織計畫編制的方法和技術樣板人力資源慣例組織理論專案干係人分析組織計畫編制的輸出組織結構圖角色和責任分配人員配置管理計畫支持細節(jié)軟體專案組織結構設計和專案角色與職責分配是專案組織計畫編制的主要內(nèi)容。軟體專案組織計畫編制專案團隊的角色分類軟體專案經(jīng)理

軟體企業(yè)最基層的管理人員，負責分配資源、確定優(yōu)先順序、協(xié)調(diào)與客戶之間的溝通，儘量使專案團隊一直集中於正確的目標。專案經(jīng)理需要領導、決策、組織、控制和創(chuàng)新方面的能力。系統(tǒng)分析員

主要從事需求獲取和研究，是專案中業(yè)務與技術間的橋樑。系統(tǒng)分析員應該善於簡化工作、善於協(xié)調(diào)，並且具有良好的人際溝通和書面溝通技巧，必須具備業(yè)務和技術領域知識，需要熟悉用於獲取業(yè)務需求的工具，同時還要掌握引導客戶描述出需求的方法。軟體專案組織計畫編制系統(tǒng)設計員根據(jù)軟體需求說明書進行構架設計、資料庫設計和詳細設計，負責在整個專案中對技術活動和工件進行領導和協(xié)調(diào)。軟體開發(fā)人員負責按照專案所採用的標準來進行單元開發(fā)與測試。軟體開發(fā)人員需要能夠迅速並準確地理解系統(tǒng)設計員的設計文檔，並能快速地進行代碼開發(fā)和單元測試。系統(tǒng)測試人員負責對測試進行計畫、設計、實施和評估。軟體專案組織計畫編制軟體配置管理人員負責策劃、協(xié)調(diào)和實施軟體專案的正式配置管理活動的個人或小組。品質(zhì)保證人員負責計畫和實施專案品質(zhì)保證活動的個人或小組，以確保軟體開發(fā)活動遵循軟體過程標準。軟體專案組織計畫編制專案角色與職責分配過程定義和分配工作的過程是在專案啟動階段開始運作並且是重複進行的。一旦專案組決定了採用的技術方法，他們將建立一個工作分解結構圖(WBS)來定義可管理的工作要素。接著，他們指定活動定義，進一步確定WBS中各個活動所包含的工作，最後指派工作。軟體專案組織計畫編制定義和分配工作的一個框架軟體專案組織計畫編制

定義和分配工作的過程包括四個部分確定專案要求；定義工作如何完成；把工作分解為可管理的部分；制定工作職責。軟體專案組織計畫編制組織分解結構(OBS)OBS（組織分解結構）是一種特殊的組織結構圖，它建立在一般組織結構圖的基礎上，根據(jù)公司各部門的具體單元或者子公司的組織單元將一般組織結構圖再進行更詳細地分解。專案經(jīng)理通常使用OBS來分配工作任務。責任分配矩陣(RAM)RAM就是將工作分解結構圖(WBS)中的每一項工作指派給OBS中的執(zhí)行人而形成的一個矩陣。軟體專案組織計畫編制專案組織結構設計專案組織結構定義

專案的組織結構，是具體承擔某一專案的全體職工為實現(xiàn)專案目標，在管理工作中進行分工協(xié)作，在職務範圍、責任、權力方面所形成的結構體系。組織結構的本質(zhì)是員工的分工協(xié)作關係。設計組織結構的目的是為了實現(xiàn)專案的目標。所以，組織結構是實現(xiàn)專案目標的一種手段。組織結構的內(nèi)涵是人們在職、責、權方面的結構體系。所以，組織結構又可簡稱為權責結構。軟體專案組織計畫編制專案組織結構體系主要包括：職能結構，即完成專案目標所需的各項業(yè)務工作及其比例和關係；層次結構，即各管理層次的構成，又稱為組織的縱向結構；部門結構，即各管理部門的構成，又稱為組織的橫向結構；職權結構，即各層次、各部門在權力和責任方面的分工及相互關係。軟體專案組織計畫編制

軟體專案的基本組織結構及其比較在實際的專案管理中，主要有三種基本的專案組織形式——直線性、職能性和矩陣形。

直線性組織結構直線性組織最大的優(yōu)點在於可以防止多重指令和防止雙頭管理現(xiàn)象的出現(xiàn)，對於一個部門來說可以避免出現(xiàn)接收多個相互矛盾指令的情況。軟體專案組織計畫編制

直線性組織結構軟體專案組織計畫編制

職能性組織結構在職能組織結構中，工作部門的設置是按照專業(yè)職能和管理業(yè)務來劃分的。職能組織結構有利於發(fā)揮職能部門的專業(yè)管理作用和專業(yè)管理專長，能適應生產(chǎn)技術發(fā)展和間接管理複雜化的特點。但如果多維指令產(chǎn)生衝突，則將使得下級部門無所適從，容易造成管理混亂。軟體專案組織計畫編制

職能性組織結構軟體專案組織計畫編制

直線型組織職能結構直線型組織職能結構在職能組織結構的基礎上引入線性組織結構在命令源上單一和一致性的優(yōu)點，可以防止組織中出現(xiàn)矛盾的指令，同時，保持線性指揮的前提下，在各級領導部門下設置相應的職能部門，分別從事各項專門業(yè)務。軟體專案組織計畫編制

矩陣形組織結構矩陣組織結構的主要特點是按兩大類型設置工作部門。其命令源是非線性的，因而橫向管理部門和縱向管理部門各自負責的工作和管理內(nèi)容必須明確。軟體專案組織計畫編制

三種組織結構的優(yōu)缺點及比較線性組織結構特點反應迅速靈活；運營成本較低；指令唯一且責任明確；低正規(guī)化和高度集權度的結構會導致高層資訊超載；隨著規(guī)模的擴大制定決策變得非常緩慢；高層經(jīng)理會陷入日常經(jīng)營活動而無法做好長期性的資源配置工作。軟體專案組織計畫編制

職能制組織形式特點在人員利用上有較大的彈性和適應性；個別專家可被不同專案利用；部門中的專家可以被組織起來共用知識和經(jīng)驗；在個別人離開專案甚至上級組織時仍可以保持技術上的延續(xù)性；職能部門有自己的常規(guī)工作，這些工作常常優(yōu)先於專案考慮，客戶常被忽略；職能部門中沒有一個人對專案全權負責，不能引起對專案的高度責任感；協(xié)調(diào)性差；不易形成對專案的系統(tǒng)化管理系統(tǒng)。軟體專案組織計畫編制矩陣制組織形式特點專案管理強調(diào)的重點是，專案經(jīng)理個人負責管理專案以保證專案在規(guī)定費用之內(nèi)按期完成；由於專案組織覆蓋於職能部門之上，因此人力資源管理方便，且專案可充分利用職能部門的技術優(yōu)勢；對客戶反應迅速；專案決策權力需要在專案組織和職能部門二者之間平衡從而帶來一定困難；多個專案之間優(yōu)化專案目標是矩陣制的一個優(yōu)點但也由此帶來專案之間的資源競爭從而互相影響；由於專案人員至少有兩個上級：專案經(jīng)理和職能部門經(jīng)理，容易造成上級命令的不統(tǒng)一，從而帶來管理混亂。本章內(nèi)容提要

軟體團隊管理概述

4.1

軟體專案組織計畫編制

4.2

軟體專案團隊人員的獲取

4.3

軟體團隊建設

4.4

案例分析4.5

本章小結

4.6復習思考題

4.74.3軟體專案團隊人員的獲取

通過組織計畫編制過程決定了軟體專案所需的人員之後，需要做的就是確定如何在合適的時間獲得這些人員。專案經(jīng)理的確定確定與指派專案經(jīng)理是專案啟動階段的一個重要工作。專案經(jīng)理是專案組織的核心和專案團隊的靈魂，對專案進行全面的管理。他的管理能力、經(jīng)驗水準、知識結構、個人魅力都對專案的成敗起著關鍵的作用。專案經(jīng)理的工作目標是負責專案保質(zhì)保量按期交付。在專案決策過程中，專案經(jīng)理不僅要面對專案班子中有著各種知識背景和經(jīng)歷的專案管理人員，又要面對各利益相關方以及客戶。軟體專案團隊人員的獲取

對專案經(jīng)理的主要要求在本行業(yè)中某一技術領域中具有權威，技術過硬；任務分解能力強；注重對專案成員的激勵和團隊建設，能良好的協(xié)調(diào)專案小組成員的關係；具備較強的客戶人際關係能力；具有很強的工作責任心，能夠接受經(jīng)常加班的要求；應更注重管理方面的貢獻，勝過作為技術人員的貢獻。軟體專案團隊人員的獲取專案團隊人員的確定在專案經(jīng)理確定之後，專案經(jīng)理就要與公司相關人員一起商討如何通過招聘流程獲取專案所需的人力資源，這種招聘過程可以是面向內(nèi)部員工，也可以面向社會人力資源。對軟體專案團隊中成員的主要要求：具備特定崗位所需的不同技能，這可能是設計、編碼、測試、溝通等能力；適應需求和任務的變動；能夠建立良好的人際關係，與小組中其他成員協(xié)作；能夠接受加班的要求；認真負責、勤奮好學，積極主動，富於創(chuàng)新。本章內(nèi)容提要

軟體團隊管理概述

4.1

軟體專案組織計畫編制

4.2

軟體專案團隊人員的獲取

4.3

軟體團隊建設

4.4

案例分析4.5

本章小結

4.6復習思考題

4.74.4軟體團隊建設軟體專案團隊的組建軟體專案團隊的組建工作包括：團隊成員的到位和專案組內(nèi)部的組織結構、角色分配和任務分工。團隊規(guī)劃主要包括：人數(shù)要求技術能力要求業(yè)務能力要求各類人員的比例需要強調(diào)的是必須明確技術能力和業(yè)務能力的要求，以及各類人員是否需要通過培訓以達到技術能力或業(yè)務能力的要求。軟體團隊建設微軟專案開發(fā)團隊舉例軟體團隊建設軟體開發(fā)專案組的主要成員是具有一定專業(yè)知識的技術人員，為了更好的發(fā)揮這些人員的作用，專案的管理人員應注意以下幾個原則：人盡其才公平原則透明原則給專案成員提供盡可能多的培訓機會正確處理人力資源的風險問題軟體團隊建設控制人員風險

以較低的代價進行及早的預防是降低人員風險的基本策略，具體來說可以從以下幾個方面對人員風險進行控制：保證開發(fā)組中全職人員的比例，且專案核心部分的工作應該儘量由全職人員來擔任，以減少兼職人員對專案組人員不穩(wěn)定性的影響；建立良好的文檔管理機制；加強專案組內(nèi)技術交流；對於專案經(jīng)理，可以從一開始就指派一個副經(jīng)理在專案中協(xié)同專案經(jīng)理管理專案開發(fā)工作，如果專案經(jīng)理退出開發(fā)組，副經(jīng)理可以很快接手。一般只建議在專案經(jīng)理這樣高度重要的崗位採用這種冗餘制的策略來預防人員風險，否則將會大大增加專案成本；為專案開發(fā)提供盡可能好的開發(fā)環(huán)境。軟體團隊建設團隊合作團隊意識就是團隊成員為了團隊的整體利益和目標而相互合作、共同努力的意願與作風。團隊意識的內(nèi)涵在團隊與其成員的關係方面，團隊意識表現(xiàn)在團隊成員對團隊的強烈歸屬感與一體感；在團隊成員之間的關係上，團隊意識表現(xiàn)為成員間的相互協(xié)作從而形成有機的整體；在成員對團隊的事務上，團隊意識表現(xiàn)為團隊成員對團隊事務的盡心盡力和全方位投入。軟體團隊建設團隊合作的指導方針作為一名團隊領導，我將：避免團隊目標向政治問題妥協(xié)；向團隊目標顯示個人的承諾；不用太多優(yōu)先順序的事物沖淡團隊的工作；公平,公正的對待團隊成員；願意面對和解決與團隊成員不良表現(xiàn)有關的問題；對來自員工的新思維和新資訊採取開放的態(tài)度。軟體團隊建設作為一名團隊成員，我將：展示對於個人角色和責任的真實理解；展示目標和以事實為基礎的判斷；和其他團隊成員有效的合作；使團隊目標優(yōu)先於個人目標；展示投身於任何專案成功所需的努力的願望；願意分享資訊、感受和產(chǎn)生適當?shù)幕仞?；當其他成員需要時給與適當?shù)膸椭?；展示對自己的高標準要求；支持團隊的決策；展示直接面對重要問題的勇氣和信念；以為團隊的成功奮鬥的方式體現(xiàn)帶頭作用；對別人的回饋做出積極的反映。軟體團隊建設團隊成員激勵激勵是用人的藝術，它通過研究人的行為方式和需求心理來因勢利導的激發(fā)人的工作熱情，改變?nèi)说男袨楸憩F(xiàn)，提高個人或組織績效。軟體專案團隊中，激勵是組織成員個人需要和專案需要的結合，一方面必須考察瞭解專案成員的需要，進行有針對性的激勵；另一方面，必須符合專案發(fā)展的需要，進行有目的的激勵。軟體團隊建設馬斯洛把人的需求分為五個層次：生理需要（衣食住等）安全需要（穩(wěn)定，身體安全，經(jīng)濟安全）社交需要（親情，友情，歸屬感）尊重需要（地位和自我尊重、認可和感激）自我實現(xiàn)需要軟體人員是追求自我實現(xiàn)需要的群體，學習機會、創(chuàng)造是對他們主要的激勵因素。對於企業(yè)來講，軟體企業(yè)的成長需要員工不斷學習，永遠創(chuàng)新，並且進行充分的團隊合作。軟體團隊建設團隊的學習團隊學習是提高團隊績效，保持其先進性的重要舉措。培訓可以給公司帶來巨大的經(jīng)濟效益，提高員工的自身能力，也是提高員工工作熱情和效率的重要一環(huán)。學習型組織是指通過培養(yǎng)彌漫於整個組織的學習氣氛、充分發(fā)揮員工的創(chuàng)造性思維能力而建立起來的一種有機的、高度柔性的、扁平的、符合人性的、能持續(xù)發(fā)展的組織。這種組織具有持續(xù)學習的能力，具有高於個人績效總和的綜合績效。軟體團隊建設軟體專案團隊成員績效評估管理績效評估的根本目的是為了完善工作，為了員工更好地發(fā)展。按照目的劃分，績效評估的類型有：獎金分配評估提薪評估業(yè)績評估人事評估職務評估晉升評估軟體團隊建設

績效評估遵循的原則公開性原則客觀、公正原則及時回饋原則敏感性原則，又稱區(qū)分性原則可行性原則多層次、多管道、全方位評價的原則績效評估經(jīng)?；⒅贫然脑瓌t本章內(nèi)容提要

軟體團隊管理概述

4.1

軟體專案組織計畫編制

4.2

軟體專案團隊人員的獲取

4.3

軟體團隊建設

4.4

案例分析4.5

本章小結

4.6復習思考題

4.74.5案例分析微軟團隊模型可以描述為專案組都是小型的、多元化的團隊專案組擁有嚴格的產(chǎn)品發(fā)佈期限專案組成員分工協(xié)作、各司其職，相互依賴、相輔相成專案組成員在統(tǒng)一的專案指導思想指引下，對各自的工作目標負責每一個成員都參與專案的設計和討論，並從過去的專案實踐中吸取經(jīng)驗。專案組成員在同一地點辦公，共同管理專案過程、制定相關決策。案例分析微軟MSF團隊角色和責任分配在MSF（微軟解決方案框架）團隊小組內(nèi)部，每個角色通過對小組本身負責（也對他們各自所屬的組織負責）實現(xiàn)該角色的品質(zhì)目標。在這種意義上，每個角色都對最終解決方案品質(zhì)的一部分負責。小組成員之間共同承擔職責（根據(jù)不同小組角色指派）。角色之間是相互依賴的，有以下兩個原因：就其必要性而言，把每個角色的工作分隔開來是不可能的；出於優(yōu)先的原因，如果每個角色都瞭解全局情況，那麼小組的效率會更高。案例分析

角色間相互依賴性的作用：相互的依賴性會鼓勵小組成員對由他們負責的直接區(qū)域以外的工作做出評論和貢獻，以確保小組所有的知識、能力和經(jīng)驗能夠被應用到解決方案裏。專案的成功屬於所有的小組成員，他們共同分享一個成功的專案所帶來的榮譽和回報，他們也同時希望，即使是一項不太成功的專案，也能做到全心投入並從中吸取教訓以完善他們的專長。案例分析

專案組中的職能劃分：產(chǎn)品管理角色程式管理角色開發(fā)角色測試角色用戶體驗角色發(fā)佈管理角色案例分析微軟MSF團隊組建模型案例分析微軟專案團隊結構以“三駕馬車”架構為核心的矩陣式組織結構。微軟的專案團隊由程式經(jīng)理、開發(fā)組、測試組組成。專案開始，由程式經(jīng)理到開發(fā)組、測試組選擇相應的成員，組成開發(fā)團隊，程式經(jīng)理對團隊成員沒有領導權，所有成員的領導權還是在各個團隊中。程式經(jīng)理發(fā)現(xiàn)開發(fā)人員工作有問題的時候會提交問題到開發(fā)組進行解決，當在同一層面上問題無法進行達成一致的時候，可以將問題上升到產(chǎn)品單元總經(jīng)理。案例分析微軟團隊模型的結構圖，反映了微軟專案團隊組織中的層級關係、隸屬關係、彙報關係案例分析微軟VSTS工具VSTS(VisualStudioTeamSystem)是一套高生產(chǎn)力的、集成的、可擴展的生命週期開發(fā)工具，它擴展了VisualStudio產(chǎn)品線，增強了軟體開發(fā)團隊中的溝通與協(xié)作。利用VisualStudioTeamSystem，開發(fā)團隊能夠在開發(fā)過程的早期以及在整個開發(fā)過程中確保更高的可預見性和更好的品質(zhì)。使用VisualStudioTeamSystem，Microsoft可以幫助不同的軟體開發(fā)小組開發(fā)更健壯的軟體系統(tǒng)。本章內(nèi)容提要

軟體團隊管理概述

4.1

軟體專案組織計畫編制

4.2

軟體專案團隊人員的獲取

4.3

軟體團隊建設

4.4

案例分析4.5

本章小結

4.6復習思考題

4.74.6本章小結本章講述了軟體專案團隊管理的概念、特點、過程、方法及其在軟體專案管理中的作用與重要性。軟體專案團隊管理主要包括團隊組織計畫、團隊人員獲取和團隊建設三個部分。軟體企業(yè)是知識密集型的技術企業(yè)，其有沒有市場競爭力，能否快速發(fā)展，關鍵在於是否擁有一支具有高素質(zhì)的軟體人才隊伍。本章最後介紹了微軟團隊管理的MSF團隊角色、產(chǎn)品開發(fā)團隊結構並給出了Windows2000開發(fā)團隊的案例和VSTS團隊開發(fā)和管理工具。本章內(nèi)容提要

軟體團隊管理概述

4.1

軟體專案組織計畫編制

4.2

軟體專案團隊人員的獲取

4.3

軟體團隊建設

4.4

案例分析4.5

本章小結

4.6復習思考題

4.74.7復習思考題什麼是軟體專案團隊？它與其他企業(yè)的人力資源有什麼不同？什麼是軟體專案團隊管理？它是怎樣出現(xiàn)的？軟體專案團隊管理主要包括哪些個方面？簡述如何進行軟體專案的組織計畫編制。在軟體專案中，對專案經(jīng)理有哪些要求？團隊的學習對團隊的建設有哪些作用？學習完微軟專案團隊管理案例後，你有哪些收穫？第5章軟體專案需求管理本章內(nèi)容提要軟體專案需求管理概述

需求開發(fā)和管理過程

需求獲取方法

5.15.25.3需求分析建模方法

5.4需求管理工具

5.5案例分析

5.6本章小結

5.7復習思考題

5.85.1軟體專案需求管理概述影響軟體專案成敗的因素軟體開發(fā)的目標——按時按預算開發(fā)出滿足用戶真實需要的軟體。需求——一個軟體專案的開始階段。在軟體工程中，需求分析階段是包括客戶、用戶、業(yè)務或需求分析員、開發(fā)人員、測試人員、用戶文檔編寫者、專案管理者和客戶管理者在內(nèi)的所有的風險承擔者都需要參與的階段。軟體專案需求管理概述

需求定義

IEEE軟體工程標準辭彙表(1997年)中將需求定義為：用戶解決問題或達到目標所需的條件或權能(Capability)；系統(tǒng)或系統(tǒng)部件要滿足合同、標準、規(guī)範或其他正式規(guī)定文檔所需具有的條件或權能；一種反映上面(1)或(2)所描述的條件或權能的文檔說明。軟體需求包括以下幾個層次：業(yè)務需求（businessrequirement）用戶需求（userrequirement）功能需求（functionalrequirement）同時也包括非功能需求、軟體需求規(guī)格說明（softwarerequirementsspecification，SRS）等。軟體專案需求管理概述軟體專案需求管理概述軟體需求各組成部分關係

需求類型

在UP（統(tǒng)一過程）中，軟體需求是根據(jù)FURPS+模型來分類的，其中FURPS的含義如下：Functional（功能性）Usability（可用性）Reliability（可靠性）Performance（性能）Supportability（可支持性）“+”是指一些輔助性的和次要的因素：

Implementation（實現(xiàn)）Interface（介面）Operations（操作）Packaging(包裝)Legal（授權）軟體專案需求管理概述本章內(nèi)容提要軟體專案需求管理概述

需求開發(fā)和管理過程

需求獲取方法

5.15.25.3需求分析建模方法

5.4需求管理工具

5.5案例分析

5.6本章小結

5.7復習思考題

5.8需求過程所涉及的工作5.2需求開發(fā)和管理過程需求工程——也叫做需求過程或需求階段，包括需求開發(fā)和需求管理。需求開發(fā)——包括需求獲取、需求分析、編寫需求規(guī)格說明、驗證需求四個階段，在這四個階段執(zhí)行以下活動：確定產(chǎn)品所期望的用戶類；獲取每個用戶類的需求；瞭解實際用戶任務和目標以及這些任務所支持的業(yè)務需求；分析源於用戶的資訊以區(qū)別業(yè)務需求、功能需求、品質(zhì)屬性、業(yè)務規(guī)則，建議解決的方法和附加的資訊；

分解需求，並將需求中的一部分分配給軟體組件；瞭解相關屬性的重要性；劃分實施優(yōu)先順序；編寫需求規(guī)格說明和模型；評審需求規(guī)格，驗證對用戶需求的正確理解和認識。需求開發(fā)和管理過程需求管理——是一種用於查找、記錄、組織和跟蹤系統(tǒng)需求變更的系統(tǒng)化方法，可用於獲取、組織和記錄系統(tǒng)需求並使客戶和專案團隊在系統(tǒng)需求變更上保持一致。有效的需求管理在於維護清晰明確的需求闡述、每種需求類型所適用的屬性，以及與其它需求和其他專案工件之間的可追蹤性。需求管理活動包括定義需求基線評審需求變更並評估每項需求變更對軟體產(chǎn)品的影響從而決定是否實施它。以一種可控制的方式將需求變更融入當前的軟體專案。讓當前的專案計畫和需求保持一致。估計變更所產(chǎn)生的影響並在此基礎上協(xié)商新的約定實現(xiàn)通過需求可跟蹤對應的設計、源代碼和測試用例。在整個專案過程中跟蹤需求狀態(tài)及其變更情況。需求開發(fā)和管理過程

需求獲取

需求獲取的主要目的是從宏觀上把握用戶的具體需求方向和趨勢，瞭解現(xiàn)有的組織架構、業(yè)務流程、系統(tǒng)環(huán)境等，對任務進行分析、從而開發(fā)、捕獲和修訂用戶的需求，以建立良好的溝通管道和方式。需求獲取需要執(zhí)行以下活動：確定需求開發(fā)過程編寫專案視圖和範圍文檔獲取涉眾請求選擇每類用戶的產(chǎn)品代表建立典型的以用戶為核心的隊伍讓用戶代表確定用例召開應用程式開發(fā)聯(lián)繫會議分析用戶工作流程確定品質(zhì)屬性和其他非功能需求需求開發(fā)和管理過程

需求分析

需求分析包括提煉、分析和仔細審查已收集到的需求，為最終用戶所看到的系統(tǒng)建立一個概念模型以確保所有的風險承擔者都明白其含義並找出其中的錯誤、遺漏或其他不足的地方。分析用戶需求應該執(zhí)行以下活動：繪製系統(tǒng)關聯(lián)圖創(chuàng)建用戶介面原型分析需求可行性確定需求的優(yōu)先順序別為需求建立模型建立數(shù)據(jù)字典使用品質(zhì)功能調(diào)配需求開發(fā)和管理過程

需求規(guī)格說明軟體需求規(guī)格說明闡述一個軟體系統(tǒng)必須提供的功能和性能以及它所要考慮的限制條件,它不僅是系統(tǒng)測試和用戶文檔的基礎，也是所有子系列專案規(guī)劃、設計和編碼的基礎。需求分析完成的標誌是提交一份完整的軟體需求規(guī)格說明書（SRS）。軟體需求規(guī)格說明作為產(chǎn)品需求的最終成果必須包括所有的需求。在開發(fā)人員的組織中要為編寫軟體需求文檔定義一種標準範本。需求開發(fā)和管理過程需求規(guī)格說明範本123456a.引言目的文檔約定預期的讀者和閱讀建議產(chǎn)品的範圍參考文獻b.綜合描述產(chǎn)品的前景產(chǎn)品的功能用戶類和特徵運行環(huán)境設計和實現(xiàn)上的限制假設和依賴附錄c.外部介面需求附錄用戶介面附錄硬體介面軟體介面通信介面d.系統(tǒng)特性說明和優(yōu)先順序激勵/回應序列功能需求e.其他非功能需求性能需求安全設施需求安全性需求軟體品質(zhì)屬性業(yè)務規(guī)則用戶文檔f.其他需求g.附件辭彙表分析模型待確定問題的列表需求開發(fā)和管理過程

需求驗證驗證是為了確保需求說明準確、無二義性並完整地表達系統(tǒng)功能以及必要的品質(zhì)特性。需求驗證要求客戶代表和開發(fā)人員共同參與，對提交