軟件工程與項目管理(第2版) 課件 （王素芬）第11、12章　統(tǒng)一建模語言(UML)、軟件項目管理

11.1概述

11.2UML概念模型

11.3UML的靜態(tài)建模機制

11.4UML的動態(tài)建模機制

11.5UML面向?qū)崿F(xiàn)機制

11.6UML建模工具11.1概述11.1.1什么是UMLUML是UnifiedModelingLanguage(統(tǒng)一建模語言)的簡稱，是基于對象管理組織(ObjectManagementGroup，OMG)進行標準化、軟件成果的式樣化和圖形化的一種語言。Booch在其經(jīng)典的一書TheUnifiedModelingLanguageUserGuide中對UML進行過詳細的定義：UML是對軟件密集型系統(tǒng)中的制品進行可視化、詳細、構(gòu)造和文檔化的語言。其中的制品是指在軟件開發(fā)過程中的各個階段所產(chǎn)生的各種各樣的成果物，如模型、源代碼、測試用例等。UML代表著面向?qū)ο蠹夹g(shù)的軟件開發(fā)方法的發(fā)展方向，在國際上越來越得到重視，現(xiàn)已成為國際軟件行業(yè)建模語言的標準，目前已經(jīng)占有面向?qū)ο蠹夹g(shù)市場的90%以上。11.1.2UML的發(fā)展史20世紀80年代中期至90年代初面向?qū)ο蠹夹g(shù)正逐漸被普及和廣泛應用中，伴隨著面向?qū)ο蠹夹g(shù)的迅猛發(fā)展，也相繼出現(xiàn)了各種各樣的方法論，如1988年RebeccaWirfsBrock提出的職責驅(qū)動(RCR)卡片法、1991年PeterCoad提出的OOA/OOD方法、1991年GradyBooch提出的Booch方法等。由于方法論的不同使得對同一個問題的描述表示法也有所不同，這樣就在軟件行業(yè)中系統(tǒng)開發(fā)者之間產(chǎn)生了很大的混亂。1994年10月，由GradyBooch和JimRumbaugh首先將Booch和OMT統(tǒng)一起來，并于1995年發(fā)布了成為統(tǒng)一方法的UM0.8版(UnifiedMethod)，1996年6月發(fā)布了統(tǒng)一建模語言UML0.9版(UnifiedModelingLanguage)，2002年11月出現(xiàn)了UML1.4版，此后，每隔幾年就會進行版本更新，現(xiàn)在已經(jīng)發(fā)布了最新的UML2.5版。UML的發(fā)展歷史如圖11.1所示。11.1.3UML的特點UML具有以下特點：(1)面向?qū)ο蟆ML支持面向?qū)ο蠹夹g(shù)的主要概念，提供了一批基本的模型元素的表示圖形和方法，能簡潔明了地表達面向?qū)ο蟮母鞣N概念。(2)可視化，表示能力強。通過UML的模型圖能清晰地表示系統(tǒng)的邏輯模型和實現(xiàn)模型，可用于各種復雜系統(tǒng)的建模。(3)獨立于過程。UML是系統(tǒng)建模語言，獨立于開發(fā)過程。(4)獨立于程序設計語言。用UML建立的軟件系統(tǒng)模型可以用Java、VC++、SmalltaIk等任何一種面向?qū)ο蟮某绦蛟O計來實現(xiàn)。(5)易于掌握使用。UML圖形結(jié)構(gòu)清晰，建模簡潔明了，容易掌握使用。使用UML進行系統(tǒng)分析和設計，可以加速開發(fā)進程，提高代碼質(zhì)量，支持動態(tài)的業(yè)務需求。UML適用于各種規(guī)模的系統(tǒng)開發(fā)。能促進軟件復用，方便地集成已有的系統(tǒng)，并能有效處理開發(fā)中的各種風險。11.1.4UML的應用領域UML的目標是以面向?qū)ο髨D的方式來描述任何類型的系統(tǒng)，具有很寬的應用領域。其中最常用的是建立軟件系統(tǒng)的模型，但它同樣可以用于描述非軟件領域的系統(tǒng)，如機械系統(tǒng)、企業(yè)機構(gòu)或業(yè)務過程，以及處理復雜數(shù)據(jù)的信息系統(tǒng)，具有實時要求的工業(yè)系統(tǒng)或工業(yè)過程等?？傊?，UML是一個通用的標準建模語言，可以對任何具有靜態(tài)結(jié)構(gòu)和動態(tài)行為的系統(tǒng)進行建模。UML適用于系統(tǒng)開發(fā)過程中從需求規(guī)格描述到系統(tǒng)完成后測試的不同階段。(1)在需求分析階段，可以用用例來捕獲用戶需求。通過用例建模，描述對系統(tǒng)感興趣的外部角色及其對系統(tǒng)(用例)的功能要求。(2)在分析階段，主要關心問題域中的主要概念(如抽象、類、對象等)和機制，需要識別這些類以及它們相互間的關系，并用UML類圖來描述。為實現(xiàn)用例，類之間需要相互協(xié)作，可以用UML動態(tài)模型來描述。在分析階段，只對問題域的對象(現(xiàn)實世界的概念)建模，而不考慮定義軟件系統(tǒng)中技術(shù)細節(jié)的類。這些技術(shù)細節(jié)將在設計階段引入。(3)在設計階段為構(gòu)造階段提供更詳細的規(guī)格說明。編程(構(gòu)造)是一個獨立的階段，其任務是用面向?qū)ο缶幊陶Z言將來自設計階段的類轉(zhuǎn)換成實際的代碼。UML模型還可作為測試階段的依據(jù)。系統(tǒng)通常需要經(jīng)過單元測試、集成測試、系統(tǒng)測試和驗收測試。不同的測試小組使用不同的UML圖作為測試依據(jù)：(1)單元測試使用類圖和類規(guī)格說明；(2)集成測試使用部件圖、合作圖；(3)系統(tǒng)測試使用用例圖來驗證系統(tǒng)的行為；(4)驗收測試由用戶進行，以驗證系統(tǒng)測試的結(jié)果是否滿足在分析階段確定的需求。總之，UML適用于以面向?qū)ο蠹夹g(shù)來描述任何類型的系統(tǒng)，而且適用于系統(tǒng)開發(fā)的不同階段，從需求規(guī)格描述直至系統(tǒng)完成后的測試和維護。11.1.5基于UML的設計過程運用UML進行面向?qū)ο蟮南到y(tǒng)分析設計，其過程通常由以下3個部分組成：(1)識別系統(tǒng)的用例和角色。首先對項目進行需求調(diào)研，依據(jù)項目的業(yè)務流程圖和數(shù)據(jù)流程圖以及項目中涉及的各級操作人員，通過分析，識別出系統(tǒng)中的所有用例和角色；接著分析系統(tǒng)中各角色和用例間的聯(lián)系，再使用UML建模工具畫出系統(tǒng)的用例圖，同時，勾畫系統(tǒng)的概念層模型，借助UML建模工具描述概念層的類圖和活動圖。(2)進行系統(tǒng)分析，并抽取類。系統(tǒng)分析的任務是找出系統(tǒng)的所有需求并加以描述，同時建立特定領域模型。建立域模型有助于開發(fā)人員考查用例，從中抽取出類，并描述類之間的關系。(3)系統(tǒng)設計，并設計類及其行為。設計階段由結(jié)構(gòu)設計和詳細設計組成。①結(jié)構(gòu)設計是高層設計，其任務是定義包(子系統(tǒng))，包括包間的依賴關系和主要通信機制。包有利于描述系統(tǒng)的邏輯組成部分以及各部分之間的依賴關系。②詳細設計就是要細化包的內(nèi)容，清晰描述所有的類，同時使用UML的動態(tài)模型描述在特定環(huán)境下這些類的實例的行為。11.2UML概念模型11.2.1UML的構(gòu)成UML主要由3類元素構(gòu)成：基本構(gòu)造塊(BasicBuildingBlock)、規(guī)則(Rule)和公共機制(CommonMechanism)。11.2.2UML的基本構(gòu)造塊UML基本構(gòu)造塊包括3種類型：事物(Thing)、關系(Relationship)和圖(Diagram)。事物又分為以下4種類型：(1)結(jié)構(gòu)事物(StructuralThing)。UML中的結(jié)構(gòu)事物包括類(Class)、接口(Interface)、協(xié)作(Collaboration)、用例(UseCase)、主動類(ActiveClass)、構(gòu)件(Component)和節(jié)點(Node)。(2)行為事物(BehavioralThing)。UML中的行為事物包括交互(Interaction)和狀態(tài)機(StateMachine)。(3)分組事物(GroupingThing)。UML中的事物是包(Package)。(4)注釋事物(AnnotationalThing)。UML中的注釋事物是注解(Note)。關系有以下4種類型：(1)依賴(Dpendency)：表示一個A對象發(fā)生變化，可能會引起另一個B對象的變化，則稱B對象依賴于A對象。(2)關聯(lián)(Association)：表示一種對象和另一種對象有聯(lián)系，是一種結(jié)構(gòu)化關系。(3)泛化(Generalization)：表示對象的一般類和特殊類之間的關系，相當于C++中的繼承關系。(4)實現(xiàn)(Realization)：表示一種A模型元素(如類)與另一種B模型元素(如接口)連接起來，其中B模型只是行為的說明，而真正的實現(xiàn)則由A模型來完成。UML有4種視圖和9種圖：(1)用例視圖(UseCaseDiagram)：從用戶角度描述系統(tǒng)功能，并指出各功能的操作者。(2)靜態(tài)視圖(StaticDiagram)：包括類圖、對象圖和包圖。(3)動態(tài)視圖(DynamicDiagram)：描述系統(tǒng)的動態(tài)模型和組成對象間的交互關系，包括狀態(tài)圖和活動圖；描述對象間的交互關系，包括時序圖和合作圖。(4)實現(xiàn)圖(ImplementationDiagram)：包括組件圖和配置圖。在UML中建模主要分為靜態(tài)建模和動態(tài)建模兩類。(1)靜態(tài)建模主要是對客觀事物靜態(tài)結(jié)構(gòu)的一種抽象，它所反眏的是目標系統(tǒng)的靜態(tài)數(shù)據(jù)。UML提供了豐富的靜態(tài)建模機制，包括用例圖、類圖、對象圖、包圖等，其中尤以用例圖和類圖最為重要。(2)動態(tài)建模則強調(diào)的是系統(tǒng)的行為，它所建立的模型或者可以執(zhí)行，或者表示執(zhí)行時的時序狀態(tài)或交互關系。動態(tài)建模包括協(xié)作圖、時序圖、活動圖、狀態(tài)圖4個圖形，是UML的動態(tài)建模機制。11.2.3UML的規(guī)則和其他語言一樣，UML是有一套規(guī)則的，這些規(guī)則描述了一個結(jié)構(gòu)良好的模型看起來應該像什么。一個結(jié)構(gòu)良好的模型應該在語義上是前后一致的，并且與所有的相關模型協(xié)調(diào)一致。UML具有用于描述如下事物的語義規(guī)則：(1)命名：為事物、關系和圖起名。(2)范圍：給一個名稱以特定含義的語境。(3)可見性：怎樣讓其他人使用或看見名稱。(4)完整性：事物如何正確、一致地相互聯(lián)系。(5)執(zhí)行：運行或模擬動態(tài)模型的含義是什么。UML的規(guī)則鼓勵(不是強迫)專注于最重要的分析、設計和實現(xiàn)問題，這些問題將促使模型隨時間的推移而具有良好的結(jié)構(gòu)。11.2.4UML的公共機制UML有4種貫穿整個語言并且一致應用的公共機制：(1)規(guī)格說明。規(guī)格說明提供了一個語義底版，它包含了一個系統(tǒng)的各模型的所有部分，并且各部分相互聯(lián)系，并保持一致性。因此，UML的圖只不過是對底版的簡單視覺投影，每一個圖展現(xiàn)了系統(tǒng)的一個特定的方面。(2)修飾。UML表示法中的每一個元素都有一個基本符號，可以把各種修飾細節(jié)加到這個符號上。(3)通用劃分。在對面向?qū)ο笙到y(tǒng)建模中，至少有兩種劃分方法，一種是對類和對象的劃分，一種是接口和實現(xiàn)的分離。(4)擴展機制。它包括構(gòu)造型、標記值和約束。構(gòu)造型擴展了UML的詞匯，它允許創(chuàng)造新的構(gòu)造塊，這個新構(gòu)造塊既可從現(xiàn)有的構(gòu)造塊派生，又專門針對要解決的問題；標記值擴展了UML構(gòu)造塊的特性，允許創(chuàng)建詳述元素的新信息；約束擴展了UML構(gòu)造塊的語義，它允許增加新的規(guī)則或修改現(xiàn)有的規(guī)則。11.3UML的靜態(tài)建模機制11.3.1用例圖無論在面向?qū)ο箝_發(fā)中還是在傳統(tǒng)的軟件開發(fā)中，人們總是根據(jù)典型的使用情景來了解用戶需求。這些使用情景是非正式的，難以建立正式文檔。在UML中可以通過用例圖(UseCaseDiagram)來構(gòu)造目標系統(tǒng)的用例模型，它通過用例來捕獲用戶需求，通過用例建模來描述對系統(tǒng)感興趣的外部角色及其對系統(tǒng)(用例)的功能要求。它從系統(tǒng)外部觀察系統(tǒng)，而不涉及技術(shù)上如何做這些事。1.用例模型用例模型(UseCaseModel)描述的是外部執(zhí)行者(Actor)所理解的系統(tǒng)模型。用例模型用于需求分析階段，它的建立是系統(tǒng)開發(fā)者和用戶反復討論的結(jié)果，表明了開發(fā)者和用戶對需求規(guī)格達成的共識。首先，它描述了待開發(fā)系統(tǒng)的功能需求；其次，它將系統(tǒng)看作黑盒，從外部執(zhí)行者的角度來理解系統(tǒng)；最后，它驅(qū)動了需求分析之后各階段的開發(fā)工作，不僅在開發(fā)過程中保證了系統(tǒng)所有功能的實現(xiàn)，而且用于驗證和檢測所開發(fā)的系統(tǒng)，從而影響到開發(fā)工作的各個階段和UML的各個模型。在UML中，一個用例模型由若干個用例圖描述，用例圖的主要元素是用例和執(zhí)行者。2.用例從本質(zhì)上講，一個用例(UseCase)是用戶與計算機之間的一次典型交互過程。在UML中，用例被定義成系統(tǒng)執(zhí)行的一系列動作，動作執(zhí)行的結(jié)果能被指定執(zhí)行者察覺到。在UML中，用例表示為一個橢圓。概括地說，用例具有以下特點：(1)用例捕獲某些用戶可見的需求，實現(xiàn)一個具體的用戶目標。(2)用例由執(zhí)行者激活，并給執(zhí)行者提供確切的值。(3)用例可大可小，但它必須是對一個具體的用戶目標實現(xiàn)的完整描述。3.執(zhí)行者執(zhí)行者是指用戶在系統(tǒng)中所扮演的角色，其圖形化的表示是一個小人。圖11.2中有兩個執(zhí)行者：學生和管理員。在系統(tǒng)中有許多學生，但他們均起著同一種作用，扮演著相同的角色，所以用一個執(zhí)行者表示。一個用戶也可以扮演多種角色(執(zhí)行者)，例如一個老師還可以是管理員。在處理執(zhí)行者時，應考慮其作用，而不是人或工作名稱。這一點是很重要的。不帶箭頭的線段將執(zhí)行者與用例連接到一起，表示兩者之間交換信息，稱之為通信聯(lián)系。執(zhí)行者觸發(fā)用例，并與用例進行信息交換，單個執(zhí)行者可與多個用例聯(lián)系；反過來，一個用例也可與多個執(zhí)行者聯(lián)系。對同一個用例而言，不同執(zhí)行者起著不同的作用，他們可以從用例中取值，也可以參與到用例中。需要注意的是，盡管執(zhí)行者在用例圖中是用類似于人的圖形來表示的，但執(zhí)行者未必是人。通過實踐，我們發(fā)現(xiàn)執(zhí)行者對提供用例是非常有用的。面對一個大系統(tǒng)，要列出用例清單常常十分困難。這時可先列出執(zhí)行者清單，再對每個執(zhí)行者列出它的用例，這樣問題就會變得很容易解決。4.使用和擴展除了執(zhí)行者與用例之間的連接外，還有另外兩種類型的連接，用以表示用例之間的使用和擴展關系。使用和擴展(UseandExtend)是兩種不同形式的繼承關系。當一個用例與另一個用例相似，但所做的動作多一些時，就可以用到擴展關系。當一個用例使用另一個用例時，這兩個用例之間就構(gòu)成了使用關系。一般來說，如果在若干個用例中有某些相同的動作，則可以把這些相同的動作提取出來單獨構(gòu)成一個用例(稱為抽象用例)。例如，圖11.3中學位課程的學習包括課程設計，因此二者構(gòu)成了使用關系；學位課程的學習比專業(yè)課程的學習有更多的要求，因此二者構(gòu)成了擴展關系。擴展與使用都意味著從幾個用例中抽取那些公共的行為并放入一個單獨用例中，而這個用例被其他幾個用例使用或擴展，但使用和擴展的目的是不同的。5.用例模型的獲取幾乎在任何情況下都會使用用例。用例用來獲取需求、規(guī)劃和控制項目。用例的獲取是需求分析階段的主要任務之一，而且是首先要做的工作。大部分用例將在項目的需求分析階段產(chǎn)生。隨著工作的深入，更多的用例會被發(fā)現(xiàn)，這些用例都應及時增添到已有的用例集中。用例中的每個用例都是一個潛在的需求。(1)獲取執(zhí)行者。獲取用例首先要找出系統(tǒng)的執(zhí)行者。可以通過用戶回答一些問題的答案來識別執(zhí)行者。(2)獲取用例。一旦獲取了執(zhí)行者，就可以對每個執(zhí)行者提出問題以獲取用例。11.3.2類圖類圖(ClassDiagram)專門用于捕獲系統(tǒng)的詞匯表。(1)類：具有相同屬性、操作、關系的對象集合的總稱。在UML中類通常被畫成矩形。(2)類圖：描述類和類之間的靜態(tài)關系，在系統(tǒng)的整個生命周期都是有效的。與數(shù)據(jù)模型不同，它不僅顯示了信息的結(jié)構(gòu)，同時還描述了系統(tǒng)的行為。類圖是定義其他圖的基礎。在類圖的基礎上，狀態(tài)圖、協(xié)作圖等進一步描述了系統(tǒng)其他方面的特性。(3)名稱：每個類都必須有一個名字，用來區(qū)分其他的類。類名是一個字符串，稱為簡單名字。(4)屬性：指類的命名的特性，常常代表一類取值。類可以有任意多個屬性，也可以沒有屬性?？梢灾粚懮蠈傩悦部梢栽趯傩悦蟾项愋蜕踔寥笔∪≈?。根據(jù)圖的詳細程度，每條屬性可以包括屬性的可見性、屬性名稱、類型、缺省值和約束特性。UML規(guī)定類的屬性的語法為：可見性屬性名：類型?=?缺省值{約束特性}常用的可見性有Public、Private和Protected3種，在UML中分別表示為“+”“-”和“#”。類型表示該屬性的種類。它可以是基本數(shù)據(jù)類型，如整數(shù)、實數(shù)、布爾型等，也可以是用戶自定義的類型。一般它由所涉及的程序設計語言確定。約束特性則是一個用戶對該屬性性質(zhì)約束的說明。(5)操作：是類的任意一個實例對象都可以調(diào)用的，并可能影響該對象行為的實現(xiàn)。該項可省略。操作用于修改、檢索類的屬性或執(zhí)行某些動作。它們被約束在類的內(nèi)部，只能作用到該類的對象上。UML規(guī)定操作的語法為：可見性操作名(參數(shù)表)：返回類型{約束特性}(6)約束：在UML中，可以用約束表示規(guī)則。約束是放在括號“{}”中的一個表達式，表示一個永真的邏輯陳述。(7)組織屬性和方法：在畫類圖時沒有必要將全部的屬性和操作都畫出來。實際上，在大部分情況下也不可能在一個圖中將類的屬性和操作都畫出來，只將感興趣的屬性和操作畫出來就可以了?？梢杂谩?..”表示還有屬性或方法沒有畫出來。使用類圖進行建模的幾個建議如下：(1)不要試圖使用所有的符號。在UML中，有些符號僅用于特殊的場合和方法中，只有當需要時才去使用。(2)根據(jù)項目開發(fā)的不同階段，用正確的觀點來畫類圖。如果處于分析階段，則應畫概念層類圖；當開始著手軟件設計時，應畫說明層類圖；當考察某個特定的實現(xiàn)技術(shù)時，則應畫實現(xiàn)層類圖。(3)不要為每個事物都畫一個模型，應該把精力放在關鍵的領域。最好只畫幾張較為關鍵的圖，經(jīng)常使用并不斷更新修改。(4)使用類圖的最大危險是過早地陷入實現(xiàn)細節(jié)。為了避免這一危險，應該將重點放在概念層和說明層。11.3.3對象圖對象圖(ObjectDiagram)用于捕獲實例和連接。UML中對象圖與類圖具有相同的表示形式。對象圖可以看作是類圖的一個實例。對象是類的實例。對象之間的鏈是類之間的關聯(lián)的實例。鏈的圖形表示與關聯(lián)相似。對象與類的圖形表示相似，即為劃分成兩個格子的長方形。下面的格子可省略，上面的格子顯示對象名和類。對象名格式為 對象名：類名類名和對象名下面有下畫線；下面的格子記錄對象的屬性以及值的列表，其格式為 屬性：類型?=?值類型可以省略。對象圖常用于表示復雜的類圖的一個實例。11.3.4包圖隨著系統(tǒng)的逐漸變化，理解和修改這個系統(tǒng)也就變得更加困難，最好的方法是將復雜問題分解為多個簡單的問題。包(Package)是一種組合機制，把許多類集合成一個更高層次的單位，形成一個高內(nèi)聚、低耦合的類的集合。不僅僅是類可以運用包的機制，任何模型元素都可以運用包的機制(比如用例)。如果沒有任何啟發(fā)性原則來指導類的分組，則分組方法就會很隨意。在UML中，最有用和強調(diào)最多的原則就是依賴性。通常，包圖所顯示的是類的包以及這些包之間的依賴關系。嚴格地說，這里所講的包和依賴關系都是類圖中的元素，因此包圖僅僅是另一種形式的類圖。包的圖示類似于書簽卡片的形狀，由兩個長方形組成。小長方形(標簽)位于大長方形的左上角。如果包的內(nèi)容(比如類)沒被圖示出來，則包的名字可以寫在大長方形內(nèi)，否則包的名字寫在小長方形內(nèi)，如圖11.4所示。如果兩個包中的任意兩個類之間存在依賴關系，則這兩個包之間也存在依賴關系。包的依賴有一個重要的特性，即不傳遞性。例如，若包C依賴于包B，包B依賴于包A，則包C不依賴于A，因為包A中的類的改變只直接影響到包B中的相應類，只要包B中被包C引用的類的接口不發(fā)生變化，包C就不會因包A的變化而受到影響。層次結(jié)構(gòu)的這種非傳遞特性正是人們經(jīng)常采用層次結(jié)構(gòu)的原因之一。顯然，如果依賴關系具有傳遞性，則當?shù)讓影恍薷暮螅淇赡懿暗姆秶鷷浅４?，從而使修改的范圍變得難以控制。減小包與外界接口的一種方法是將包中與外界有聯(lián)系的操作都取出來，組成一個小子集，對外只提供這個小子集。包的可見性限定了包中某些類只對本包中的類可見；同時，在包中可加入一些額外的公有類來表示包的公有行為。包的概念本身對于減少依賴關系并沒有必然的幫助。但是，利用這種機制有助于更方便地發(fā)現(xiàn)在何處存在依賴，從而有助于通過適當?shù)姆纸M、打包等手段來減少依賴關系。此外，包還是保持系統(tǒng)整體結(jié)構(gòu)簡明、清晰的重要工具。對于一個已經(jīng)存在的系統(tǒng)，通過查看包中的類就可以推斷出包之間的依賴關系。包圖是一個很有用的工具，特別是對于改進系統(tǒng)的結(jié)構(gòu)非常有幫助。改進系統(tǒng)結(jié)構(gòu)的基本步驟是：先將類劃分成一些包并分析包的依賴關系，然后減少這些依賴關系。11.4UML的動態(tài)建模機制11.4.1協(xié)作圖協(xié)作圖(CollaborationDiagram)是動態(tài)視圖的另一種表現(xiàn)形式，它強調(diào)參加交互的各對象的組織。協(xié)作圖只對相互間有交互作用的對象和這些對象間的關系建模，而忽略了其他對象和關聯(lián)。協(xié)作圖可以被視為對象圖的擴展，但它除了展現(xiàn)出對象間的關聯(lián)外，還顯示出對象間的消息傳遞過程。協(xié)作圖包含以下3個元素：(1)對象(Object)。協(xié)作圖中的對象與時序圖的概念是一樣的，但是在協(xié)作圖中，無法表示對象的創(chuàng)建和撤銷，所以對于對象在圖中的位置沒有限制。在協(xié)作圖中用矩形表示對象，內(nèi)部是對象的名字。(2)鏈(Link)。協(xié)作圖中的鏈和對象圖中的鏈所用的符號是一樣的，即一條連接兩個類角色的實線。(3)消息(Message)。協(xié)作圖中的消息類型與時序圖中的相同，但是為了說明交互過程中消息的時間順序，可以在消息上添加順序號，也可以添加箭頭表示接收消息的對象。UML中的協(xié)作圖如圖11.5所示。11.4.2時序圖時序圖(SequenceDiagram)描述了對象之間傳遞消息的時間順序，用來表示用例中的行為順序，是強調(diào)消息時間順序的交互圖。時序圖包含以下4種元素：(1)對象(Object)。對象代表時序圖中的對象在交互中扮演的角色。將對象置于時序圖的頂部意味著在交互開始時對象就已經(jīng)存在了，如果對象的位置不在頂部，那么表示對象是在交互的過程中被創(chuàng)建的。(2)生命線(Lifeline)。生命線代表時序圖中的對象在一段時期內(nèi)的存在。每個對象底部都有一條垂直的虛線，用于表示該對象的生命線。(3)激活(Activation)。激活代表時序圖中的對象執(zhí)行一次操作的時期。每條生命線上的窄條矩形表示活動期。(4)消息(Message)。消息用于表示對象之間的交換信息的類。UML中的時序圖如圖11.6所示。11.4.3活動圖活動圖(ActivityDiagram)是一種描述系統(tǒng)行為的圖，它用于展現(xiàn)參與行為的類所進行的各種活動的順序關系，類似于程序流程圖?；顒訄D包括以下7種元素：(1)動作狀態(tài)(ActionState)。對象的動作狀態(tài)是活動圖的最小單位的構(gòu)成塊，表示原子動作。動作狀態(tài)使用平滑的圓角矩形表示，動作狀態(tài)所表示的動作寫在圓角矩形內(nèi)部。(2)活動狀態(tài)(ActivityState)。對象的活動狀態(tài)可以被理解成一個組合，它的控制流由其他活動狀態(tài)或動作狀態(tài)組成?；顒訝顟B(tài)的表示圖標也是平滑的圓角矩形，并可以在圖標中給出入口動作、出口動作等信息。(3)動作流(ActionFlow)。所有動作狀態(tài)之間的轉(zhuǎn)換流稱為動作流。與狀態(tài)圖的轉(zhuǎn)換相同，活動圖的轉(zhuǎn)換也用帶箭頭的直線表示，箭頭的方向指向轉(zhuǎn)入的方向。(4)分支(Branch)與合并(Merge)。分支與合并描述了對象在不同的判斷結(jié)果下所執(zhí)行的不同動作。在活動圖中分支與合并用小空心的菱形表示。(5)分叉(Fork)與匯合(Join)。分叉用于將動作流分成兩個或者多個并發(fā)運行的分支，而匯合則用于同步這些并發(fā)分支，以達到共同完成一項事務的目的。分叉和匯合都使用加粗的水平線段表示。(6)泳道(Swimlane)。泳道將活動圖中的活動劃分為若干組，并把每一組指定給負責這組活動的業(yè)務組織即對象。泳道區(qū)分了負責活動的對象，明確地表示了哪些活動是由哪些對象進行的。每個活動只能明確地屬于一個泳道。泳道用垂直實線繪出，垂直線分隔的區(qū)域就是泳道。(7)對象流(ObjectFlow)。對象流是動作狀態(tài)或者活動狀態(tài)與對象之間的依賴關系，表示動作使用對象或者動作對對象的影響。對象流用帶有箭頭的虛線表示。如果箭頭從動作狀態(tài)出發(fā)指向?qū)ο?，則表示動作對對象施加了一定的影響。如果箭頭從對象指向動作狀態(tài)，則表示該動作使用對象流所指向的對象?；顒訄D與狀態(tài)圖的區(qū)別如下：(1)活動圖著重表現(xiàn)從一個活動到另一個活動的控制流，是內(nèi)部處理驅(qū)動的流程。(2)狀態(tài)圖著重描述從一個狀態(tài)到另一個狀態(tài)的流程，主要有外部事件的參與。UML中的活動圖如圖11.7所示。11.4.4狀態(tài)圖狀態(tài)圖(StateDiagram)是描述一個實體基于事件反應的動態(tài)行為，顯示了該實體如何根據(jù)當前所處的狀態(tài)對不同的事件做出反應。通常，創(chuàng)建UML狀態(tài)圖是為了研究類、角色、子系統(tǒng)、或組件的復雜行為。狀態(tài)圖可由表示狀態(tài)的節(jié)點和表示狀態(tài)之間轉(zhuǎn)換的帶箭頭的直線組成。狀態(tài)圖包括5種元素：狀態(tài)(State)、轉(zhuǎn)換(Transition)、初始狀態(tài)(StartState)、終結(jié)狀態(tài)(EndState)和判定(Decision)。UML中的狀態(tài)圖如圖11.8所示。11.5UML面向?qū)崿F(xiàn)機制11.5.1組件圖組件圖描述了軟件的各種組件和它們之間的依賴關系。每一個組件圖只描述系統(tǒng)實現(xiàn)中的某一方面，是系統(tǒng)的代碼物理模塊，當系統(tǒng)中的所有組件結(jié)合起來后，就可以完整地表示整個系統(tǒng)的實現(xiàn)視圖。組件圖中通常包含3個元素：組件(Component)、接口(Interface)和依賴關系(Dependency)。UML中的組件圖如圖11.9所示。(1)組件。組件是定義了良好接口的物理實現(xiàn)單元，是系統(tǒng)中可替換的物理部件。組件可以是源代碼組件、二進制組件或一個可執(zhí)行的組件。在UML中，組件用一個左側(cè)帶有突出兩個小矩形的矩形來表示。(2)接口。接口是一個類提供給另一個類的一組操作。組件可以通過其他組件的接口來使用那些組件中定義的一些操作。組件的接口分為兩種：①導入接口(ImportInterface)：提供給訪問操作的組件使用。②導出接口(ExportInterface)：由提供操作的組件提供。接口和組件之間的關系分為兩種：①實現(xiàn)關系(Realization)：接口和組件之間用實線連接表示實現(xiàn)關系。②依賴關系(Dependency)：接口和組件之間用虛線箭頭連接。(3)依賴關系。依賴關系表示組件圖中各組件之間存在的關系類型。UML的組件圖中依賴關系的表示方法與類圖中依賴關系的表示方法相同，都是一個由客戶指向提供者的虛線箭頭。組件圖的依賴關系如圖11.10所示。11.5.2配置圖配置圖描述了運行軟件的系統(tǒng)中硬件和軟件的物理結(jié)構(gòu)。配置圖中包含兩個元素：節(jié)點(Node)和關聯(lián)關系(Association)。配置圖可以顯示節(jié)點以及它們之間的必要連接，也可以顯示這些連接的類型，還可以顯示組件和組件之間的依賴關系，但是每個組件必須存在于某些節(jié)點上。UML中的部署圖如圖11.11所示。(1)節(jié)點是表示在運行時代表計算資源的物理元素。節(jié)點通常擁有一些內(nèi)存，并具有處理能力(如處理器、設備)，在UML中是用一個立方體來表示的。(2)關聯(lián)關系是表示各節(jié)點之間的通信路徑，在UML中是用一條實線來表示的。11.6UML建模工具11.6.1RationalRoseRationalRose是由美國Rational公司開發(fā)的一種面向?qū)ο蟮慕y(tǒng)一建模語言的可視化建模工具。利用該工具可以建立用UML描述的軟件系統(tǒng)模型，而且可以自動生成和維護C++、Java、VB、Oracle等語言和系統(tǒng)的代碼。RationalRose包括了統(tǒng)一建模語言UML、面向?qū)ο蟮能浖こ蘋OSE以及對象建模技術(shù)OMT。其中，統(tǒng)一建模語言UML是由UML業(yè)內(nèi)的三位創(chuàng)始人、面向?qū)ο箢I域的大師級人物——Booch、Rumbaugh和Jacobson通過對早期面向?qū)ο蠹夹g(shù)的研究而創(chuàng)建的，而這三位大師都曾經(jīng)擔任過Rational公司的首席工程師。2002年，Rational軟件公司被IBM公司收購，現(xiàn)已成為IBM的第五大品牌。RationalRose在建模方面具有以下特點：(1)保證模型和代碼的高度一致，實現(xiàn)真正意義上的雙向工程。(2)支持多種語言，如C++、VB、VC++、Java、PB等。(3)為團隊開發(fā)提供了強有力的支持，提供了SCM軟件配置管理功能。(4)支持模型的Internet發(fā)布，提供了基于HTML版本的發(fā)布功能。(5)生成使用簡單且定制靈活的文檔。(6)支持常用關系型數(shù)據(jù)庫的無縫連接建模。11.6.2MicrosoftOfficeVisioMicrosoftOfficeVisio是微軟公司開發(fā)的產(chǎn)品。它能夠很好地幫助IT和商務專業(yè)人員輕松地可視化、分析和交流復雜信息。它能夠?qū)㈦y以理解的復雜文本和表格轉(zhuǎn)換為一目了然的Visio圖表。該軟件通過創(chuàng)建與數(shù)據(jù)相關的Visio圖表(而不使用靜態(tài)圖片)來顯示數(shù)據(jù)，這些圖表易于刷新，并能夠顯著提高生產(chǎn)率。目前OfficeVisio2007有兩種獨立版本：OfficeVisioProfessional和OfficeVisioStandard。OfficeVisioStandard2007與OfficeVisioProfessional2007的基本功能相同，但前者包含的功能和模板是后者的子集。OfficeVisioProfessional2007提供了數(shù)據(jù)連接性和可視化功能等高級功能，而OfficeVisioStandard2007并沒有這些功能。UML模型圖模板是MicrosoftOfficeVisio中提供的一個輕量級的建模工具之一，它能夠為創(chuàng)建復雜軟件系統(tǒng)的面向?qū)ο蟮哪Ｐ?模型是建模系統(tǒng)的一種抽象表示，它從特定的視角并在某一抽象級別上指定建模系統(tǒng))提供全面的支持。該模板包括下列工具、形狀和功能：(1)?UML模型資源管理器：它提供模型的樹視圖(樹視圖是顯示于UML導航器窗口中的一種層次結(jié)構(gòu)，其中的各個UML元素或視圖(圖表)都用圖標表示，UML模板自動創(chuàng)建模型的樹視圖)和在視圖間進行瀏覽的手段。(2)預定義的智能形狀：這些形狀表示UML標注中的元素并支持UML圖類型的創(chuàng)建。通過對這些程序進行編程，使其行為方式同UML語義相符。(3)易于訪問“UML屬性”對話框：可通過這些對話框?qū)⒚Q、特性、操作和其他屬性添加到UML元素中。(4)動態(tài)語義錯誤檢查：用于標識和診斷錯誤，例如缺少數(shù)據(jù)或錯誤地使用了UML表示法。(5)對用MicrosoftVisualC++6.0或MicrosoftVisualBasic6.0創(chuàng)建的項目進行反向工程，以生成UML靜態(tài)結(jié)構(gòu)模型。(6)對MicrosoftVisualStudio.NET中創(chuàng)建的項目進行反向工程并生成UML靜態(tài)結(jié)構(gòu)模型。(7)從UML模型中的類定義將代碼框架生成到C++、VisualC#?或MicrosoftVisualBasic中。(8)標識特定語言錯誤的代碼檢查實用程序，該實用程序可以避免代碼被指定的目標語言(為生成代碼而指定)編譯。(9)創(chuàng)建用于UML靜態(tài)結(jié)構(gòu)、活動、狀態(tài)圖、組件和部署圖的報告。當前市場上基于UML可視化建模的工具很多，如RationalRose、MicrosoftVisio、OracleDesigner、PlayCase、CABPWin、CAERWin、SybasePowerDesigner等。12.1項目與項目管理

12.2ISO9000國際標準簡介

12.3CMMI

12.4ISO9000與CMMI的比較

12.5軟件項目管理過程

12.6模板和表格12.1項目與項目管理1.項目項目是現(xiàn)代管理學中的一個重要分支。美國項目管理協(xié)會(PMI)對項目的定義：項目是為完成某一獨特的產(chǎn)品或服務所做的一次性努力。從根本上說，項目就是一系列的相關工作。中國項目管理研究委員會對項目的定義是：項目是一個特殊的將被完成的有限任務。它是在一定時間內(nèi)，滿足一系列特定目標的多項相關工作的總稱。根據(jù)這個定義，項目實際包含3層含義：(1)項目是一項有待完成的任務，有特定的環(huán)境和要求。(2)在一定的組織機構(gòu)內(nèi)，利用有限資源(人力、物力、財力等)，在規(guī)定的時間內(nèi)(指項目有明確的開始時間和結(jié)束時間)為特定客戶完成特定目標的階段性任務。(3)任務要滿足一定性能、質(zhì)量、數(shù)量、技術(shù)指標等要求。2.項目管理按PMI的定義：項目管理就是“在項目活動中運用一系列的知識、技能、工具和技術(shù)，以滿足或超過相關利益者對項目的要求”。中國項目管理研究委員會對項目管理總結(jié)為：“項目管理”一詞具有兩種不同的含義，其一是指一種管理活動，其二是指一種管理學科。前者是一種客觀的實踐活動，后者是前者的理論總結(jié)；前者以后者為指導，后者以前者為基礎。項目管理貫穿整個項目的生命期，是對項目的全過程管理。項目管理具有以下基本特征：(1)項目管理的對象是項目。(2)系統(tǒng)工程思想貫穿項目管理的全過程。(3)項目管理的組織具有一定的特殊性。(4)項目管理的體制是基于團隊管理的個人負責制，項目經(jīng)理是整個項目組中協(xié)調(diào)、控制的關鍵。(5)項目管理的要點是創(chuàng)造和保持一個使項目順利進行的環(huán)境，使置身于這個環(huán)境的人們能在集體中協(xié)調(diào)工作以完成預定的目標。(6)項目管理的方法、工具和技術(shù)手段具有先進性。3.項目管理的基本內(nèi)容PMI編寫的《項目管理知識體系》(PMBOK)將項目管理劃分為9個知識領域：范圍管理、時間管理、成本管理、質(zhì)量管理、人力資源管理、溝通管理、采購管理、風險管理和綜合管理。(1)項目綜合管理：其包括3個基本的子過程，即制訂項目計劃、項目計劃執(zhí)行及綜合變更控制。(2)項目范圍管理：PMBOK將其分成5個階段，即啟動、范圍計劃、范圍界定、范圍核實及范圍變更控制。(3)項目時間管理：PMBOK提出，項目時間管理由5項任務組成，即活動定義、活動排序、活動時間估計、項目進度編制及項目進度控制。(4)項目成本管理：包括4個過程，即制訂資源計劃、成本估計、成本預算及成本控制。(5)項目質(zhì)量管理：主要包括4個過程，即質(zhì)量規(guī)劃、質(zhì)量控制、質(zhì)量保證及全面質(zhì)量管理。(6)項目人力資源管理：包括這幾個主要的過程，即人力資源規(guī)劃、招聘與解聘、篩選、定向、培訓、績效評估、職業(yè)發(fā)展及團隊建設。(7)項目風險管理：PMBOK將其歸納為4個主要過程，即風險識別、風險估計、風險應對計劃及風險控制。(8)項目溝通管理：包括一些基本的過程，即編制溝通計劃、信息傳遞、績效報告和管理收尾。(9)項目采購管理：主要包括編制采購計劃、編制詢價計劃、詢價、選擇供應商、合同管理及合同收尾。而中國項目管理研究委員會則將項目管理的內(nèi)容概括為2個層次、4個階段、5個過程、9大知識領域、42個要素及多個主體。4.項目管理的要素在項目管理過程中，是以3個要素為中心進行管理的：時間(Time)、成本(Cost)和質(zhì)量(Quality)。12.2ISO9000國際標準簡介ISO9000族標準是國際標準化組織于1987年制定的，后經(jīng)不斷修改完善而成的系列標準。現(xiàn)已有90多個國家和地區(qū)將此標準等同轉(zhuǎn)化為國家標準。我國等同采用ISO9000族標準的國家標準是GB／T19000族標準。該標準是國際標準化組織承認的中文標準。一般的軟件企業(yè)的活動主要由3方面組成，即經(jīng)營、管理和開發(fā)。在管理上又主要表現(xiàn)為行政管理、財務管理和質(zhì)量管理。ISO9000標準族主要針對質(zhì)量管理，同時涵蓋了部分行政管理和財務管理的范疇。ISO9000標準族并不是產(chǎn)品的技術(shù)標準，而是針對企業(yè)的組織管理結(jié)構(gòu)、人員和技術(shù)能力、各項規(guī)章制度和技術(shù)文件、內(nèi)部監(jiān)督機制等一系列體現(xiàn)企業(yè)保證產(chǎn)品及服務質(zhì)量的管理措施的標準。具體地講ISO9000標準族就是在以下4個方面規(guī)范質(zhì)量管理的。(1)機構(gòu)。標準明確規(guī)定了為保證產(chǎn)品質(zhì)量而必須建立的管理機構(gòu)及其職責權(quán)限。(2)程序。企業(yè)組織產(chǎn)品生產(chǎn)必須制定規(guī)章制度、技術(shù)標準、質(zhì)量手冊和質(zhì)量體系操作檢查程序，并使之文件化、檔案化。(3)過程。質(zhì)量控制是對生產(chǎn)的全部過程加以控制，是面的控制，不是點的控制。從根據(jù)市場調(diào)研確定產(chǎn)品、設計產(chǎn)品、采購原料，到生產(chǎn)檢驗、包裝、儲運，其全過程按程序要求控制質(zhì)量，并要求過程具有標識性、監(jiān)督性和可追溯性。(4)總結(jié)。不斷地總結(jié)、評價質(zhì)量體系，不斷地改進質(zhì)量體系，使質(zhì)量管理呈螺旋式上升。通俗地講就是把企業(yè)的管理標準化，而標準化管理生產(chǎn)的產(chǎn)品及其服務，其質(zhì)量是可以信賴的。ISO9000族標準認證也可以理解為質(zhì)量體系注冊，它是由國家批準的、公正的第三方認證機構(gòu)依據(jù)ISO9000族標準，對企業(yè)的質(zhì)量體系實施評定，向公眾證明該企業(yè)的質(zhì)量體系符合ISO9000族標準，可提供合格產(chǎn)品，公眾可以相信該企業(yè)的服務承諾和企業(yè)產(chǎn)品質(zhì)量的一致性。12.3CMMI12.3.1CMMI的基本概念能力成熟度模型(CMM)是由美國軟件工程學會制定的一套專門針對軟件產(chǎn)品的質(zhì)量管理和質(zhì)量保證標準。該標準最初是為美國軍方選擇軟件產(chǎn)品提供商時評價軟件企業(yè)的軟件開發(fā)質(zhì)量保證能力而制定的，所以稱為軟件企業(yè)能力成熟度模型。該標準將軟件企業(yè)的能力成熟度劃分為5個等級，級別越高表明該企業(yè)在提供合格軟件產(chǎn)品方面的能力越強。CMMI全稱是CapbilityMaturityModelIntegration，即軟件能力成熟度模型集成，它由美國國防部與卡內(nèi)基梅隆大學和美國國防工業(yè)協(xié)會共同開發(fā)和研制，于2002年4月推出了系統(tǒng)工程和軟件工程的集成成熟度模型。CMMI是一套融合多學科的、可擴充的產(chǎn)品集合，同時也是工程實踐與管理方法。CMMI能夠解決現(xiàn)有的不同CMM模型的重復性、復雜性，并降低由此引起的成本，縮短改進過程。它將軟件CMM2.0版草案(SW-CWW)、EIA過渡標準731(系統(tǒng)工程CMM)及IPD-CMM集成為一體，同時還與ISO15504相兼容。與原有的能力成熟度模型CMM相比，CMMI的涉及面更廣，專業(yè)領域覆蓋軟件工程、系統(tǒng)工程、集成產(chǎn)品開發(fā)和系統(tǒng)采購。CMMI有兩種表現(xiàn)方法，一種是大家很熟悉的和軟件CMM一樣的階段式表現(xiàn)方法，另一種是連續(xù)式的表現(xiàn)方法。這兩種表現(xiàn)方法的區(qū)別是：階段式表現(xiàn)方法仍然把CMMI中的若干個過程區(qū)域分成了5個成熟度級別，幫助實施CMMI的組織建立一條比較容易實現(xiàn)的過程改進發(fā)展道路。而連續(xù)式表現(xiàn)方法則將CMMI中過程區(qū)域分為4大類：過程管理、項目管理、工程以及支持。對于每個大類中的過程區(qū)域，又進一步分為基本的和高級的。這樣，在按照連續(xù)式表示方法實施CMMI的時候，一個組織可以把項目管理或者其他某類的實踐一直做到最好，而其他方面的過程區(qū)域可以完全不必考慮。12.3.2CMMI的體系結(jié)構(gòu)CMMI的體系結(jié)構(gòu)由5個成熟度級組成(參見表12.2)，具體定義如下：12.4ISO9000與CMMI的比較這里主要比較CMMI和ISO9000質(zhì)量標準體系中的9001的異同。在基本原理方面，ISO9001和CMMI都十分關注軟件產(chǎn)品質(zhì)量和過程改進。尤其是ISO9000:2000版標準增加持續(xù)改進、質(zhì)量目標的量化等方面的要求后，在基本思路上和CMMI更加接近。它們之間的主要的差別是狀態(tài)上的差別。ISO9001側(cè)重于“機構(gòu)保證在設計、開發(fā)、生產(chǎn)、安裝及服務過程中與指定的要求一致”。而CMMI側(cè)重于“支持一個機構(gòu)評估及改進它們的系統(tǒng)的工程能力”及“指出機構(gòu)選擇的模型的不足之處”。CMMI和ISO9001闡述了一個機構(gòu)應該如何制定他們的標準，然后如何檢查是否按照標準進行了實施。ISO9001所關注的是確保執(zhí)行人員所完成的過程記錄是否有效，并且開發(fā)的產(chǎn)品是否滿足質(zhì)量要求。CMMI以成熟度能力為層次進行評價。這兩個標準都涉及了產(chǎn)品的開發(fā)和產(chǎn)品的質(zhì)量，但CMMI對產(chǎn)品的設計和開發(fā)的細節(jié)作了較多要求，而ISO9001則對產(chǎn)品的開發(fā)過程和產(chǎn)品本身的質(zhì)量細節(jié)作了較多要求。ISO9001要求與質(zhì)量管理體系相關的所有工作人員的經(jīng)過授權(quán)并簽字的質(zhì)量記錄。它還要求足夠的資源，包括提供必要的員工培訓等。從ISO9001的角度來看CMMI，至少CMMI的第2級及以上級別才能和ISO9001相提并論。由此可見ISO9001和CMMI既有區(qū)別又相互聯(lián)系，兩者不可簡單地互相替代；取得ISO9001認證并不意味著完全滿足CMMI某個等級的要求，取得CMMI第2級(或第3級)并不能籠統(tǒng)地說滿足了ISO9001的要求。CMMI和ISO9001的出發(fā)點都是通過對生產(chǎn)過程進行管理，來確保產(chǎn)品的質(zhì)量。雖然它們之間有很多區(qū)別，但也有相似之處。比如，通過ISO9001認證的組織，可以基本滿足CMMI第2級的標準和很多CMMI第3級的要求。因為CMMI中的很多要求并沒有列入ISO9000標準之中，所以，CMMI第1級的組織也可能獲得ISO9001的登記和注冊。同樣，有些ISO9001規(guī)定的內(nèi)容并沒有列入CMMI標準。一個CMMI第3級組織獲得ISO9001認證幾乎沒有困難，一個CMMI第2級組織申請ISO9001認證也有明顯優(yōu)勢。12.5軟件項目管理過程項目管理的目的就是規(guī)范項目管理過程，使項目在預定成本之內(nèi)，保質(zhì)保量地按計劃完成任務。在軟件項目開發(fā)過程和軟件項目管理過程中經(jīng)常容易出現(xiàn)以下問題：(1)對目標理解不清楚。(2)對需求定義不明確。(3)目標不合理。(4)沒有策劃任務。(5)資源和技能不充分。(6)溝通不是很有效。(7)優(yōu)先級沖突。(8)沒有控制的變更等?；谝陨先菀壮霈F(xiàn)的問題，建立項目管理過程，規(guī)范項目管理的過程就顯得非常必要。表12.3軟件項目管理過程12.5.1項目組織結(jié)構(gòu)軟件項目組織結(jié)構(gòu)并不是固定不變的，可以根據(jù)項目的具體情況略有不同。一般的軟件項目組織結(jié)構(gòu)如圖12.1所示。12.5.2項目啟動明確項目目的、目標，制訂項目啟動計劃，進行初步的規(guī)模估算，確定項目信息和目標，啟動項目。1.參與角色高層經(jīng)理指定相關人員，根據(jù)合同書或立項的意向，編寫《立項建議報告》或《工作陳述》，策劃啟動活動。2.啟動準則(1)合同尚未簽訂，需要提前啟動項目。(2)根據(jù)業(yè)務的需要，或高層經(jīng)理的指示。(3)合同已經(jīng)簽訂。3.過程活動(1)項目啟動。若是產(chǎn)品項目，則由高層經(jīng)理指定的人員，負責編寫《立項建議報告》，申請項目啟動；若是合同項目(包括外包項目)，則由高層經(jīng)理指定的人員，負責編寫《工作陳述》，申請項目啟動。(2)啟動階段的計劃，計劃包括：①確定項目進行需求和項目整體策劃活動需要使用的資源，分配職責。②在需求調(diào)研或產(chǎn)品功能定義前，不能進行全部開發(fā)過程的策劃，可以先策劃需求調(diào)研或產(chǎn)品功能定義階段的計劃，確定項目進行項目策劃活動需要使用的資源，分配職責，稱之為啟動計劃，并在《立項建議報告》(或《工作陳述》)中描述。③如果需求已基本明確，則可以在《立項建議報告》中不編寫需求階段計劃，只編寫項目策劃的計劃，在立項評審通過后，進行項目整體策劃，編寫《項目計劃》。(3)立項評審。高層經(jīng)理對《立項建議報告》或《工作陳述》進行管理評審，評審通過后下達《項目任務書》。(4)下達項目任務書，內(nèi)容包括項目編號、項目名稱、項目經(jīng)理、項目成員、具體項目任務等。(5)召開項目啟動會議。參加會議的人員必須通過項目需求對項目進行基本了解，然后就可以召開項目啟動會議。項目啟動會議可以包括如下議程：項目概況介紹和工作綜述；相關共同利益者簡介；項目成員及任務介紹；項目計劃；闡述項目估算和進度安排的計算結(jié)果；需要共同探討的技術(shù)細節(jié)；項目將要使用的工作過程；如何運用從以往項目中取得的經(jīng)驗教訓；對公司定義的軟件生命周期或標準工作過程的剪裁；對新工具和技術(shù)的使用；項目所需硬件資源和軟件許可，并討論是否從其他項目組獲得或共享；如何驗證軟件需求；產(chǎn)品交付所包含內(nèi)容；項目目前的狀況。(6)確定項目基本信息。由項目經(jīng)理、QAL、CML及其他參與策劃人員共同進行項目的策劃，確定項目基本信息。4.工作產(chǎn)品這個階段的工作產(chǎn)品包括《工作陳述》《立項建議報告》《管理評審記錄》和《項目任務書》。5.結(jié)束準則這個階段的結(jié)束準則是《立項建議報告》或《工作陳述》文檔已經(jīng)通過評審，下達了《項目任務書》，并已經(jīng)納入配置管理中，同時明確了項目的基本信息。112.5.3項目過程定義根據(jù)項目的具體情況選擇生命周期模型。1.參與角色這個階段的參與角色有項目經(jīng)理及相關人員。2.啟動準則這個階段的啟動準則是項目的《需求分析報告》(《需求規(guī)格說明書》)、《立項建議報告》(《工作陳述》)已經(jīng)完成。3.過程活動(1)選擇生命周期模型：項目經(jīng)理根據(jù)項目的特征從組織批準的生命周期模型中選擇合適的生命周期模型。(2)描述項目定義過程：依據(jù)選定的生命周期模型對項目定義過程進行說明，如果選擇了瀑布或迭代模型，還要說明每個階段需要完成的主要工作內(nèi)容。4.工作產(chǎn)品這個階段的工作產(chǎn)品為《項目計劃》和項目生命周期模型。5.結(jié)束準則這個階段的結(jié)束準則是項目過程定義完成。12.5.4工作分解結(jié)構(gòu)進行產(chǎn)品和任務分解，建立項目的WBS，同時進行軟件估計。1.參與角色項目經(jīng)理根據(jù)《需求分析報告》(《需求規(guī)格說明書》)、《立項建議報告》(《工作陳述》)等，進行頂層工作結(jié)構(gòu)分解，以便估計項目的范圍。2.啟動準則這個階段的啟動準則是《需求分析報告》(《需求規(guī)格說明書》)、《立項建議報告》等文檔已經(jīng)完成。3.過程活動項目經(jīng)理負責分解項目的任務和產(chǎn)品。(1)根據(jù)任務分解的規(guī)則對產(chǎn)品開發(fā)工作進行結(jié)構(gòu)分解。(2)根據(jù)《軟件估計指南》進行軟件估計。4.工作產(chǎn)品這個階段的工作產(chǎn)品為《項目進度表》《項目計劃》工作分解結(jié)構(gòu)和《軟件估計表》。5.結(jié)束準則這個階段的結(jié)束準則是完成了工作分解結(jié)構(gòu)。12.5.5制訂風險計劃1.參與角色這個階段的參與角色有項目經(jīng)理、測試負責人、市場人員、QAL、CML以及其他相關風險分析人員。2.啟動準則收集項目的有關資料，包括項目的背景、項目的需求、項目的目標、系統(tǒng)的技術(shù)方案、WBS、對軟件的估計結(jié)果等。風險識別要針對這些對成本、資源、進度的策劃進行，以保證識別的客觀性。同時要保證風險管理活動的執(zhí)行者具有這方面的經(jīng)驗或者接受必要的培訓。3.過程活動(1)識別風險。項目經(jīng)理向預先指定的風險分析小組成員分發(fā)需求文檔、WBS、軟件估計表以及《項目計劃》，并分發(fā)《軟件風險分類表》。風險分析人員可參照《軟件風險分類表》輔助進行風險識別，填寫此表作為風險識別工作產(chǎn)品提交給項目經(jīng)理，由項目經(jīng)理負責收集、合并成《風險管理表》。(2)制訂風險管理策略，包括：①項目經(jīng)理對風險進行跟蹤并填寫跟蹤記錄。②制訂風險報告的機制。(3)分析風險。①分析小組成員對已經(jīng)識別出來的風險逐條分析，主要分析方面包括：·分析每個風險對項目成本、進度、質(zhì)量的影響。·分析風險發(fā)生的嚴重程度。風險嚴重程度通常分為5個等級：特別嚴重、嚴重、一般、輕微、基本可忽略?！し治鲲L險發(fā)生的概率(風險概率以百分比計算，從1%～100%)?！し治鲲L險發(fā)生的條件?！ご_定風險可能發(fā)生的生命周期(風險的生存期)?！ご_定每個風險的責任人以及其他相關共同利益者。②根據(jù)分析結(jié)果(風險發(fā)生的嚴重程度和發(fā)生概率)計算風險等級：風險等級?=?風險嚴重程度?×?發(fā)生概率風險嚴重程度的原則：A.特別嚴重(5) B．嚴重(4) B．一般(3)D.輕微(2) E.基本可以忽略(1)風險發(fā)生概率分為3個區(qū)間：A.1%～35%(低) B.36%～70%(中) C.71%～100%(高)③按照風險等級的高低排序，風險等級高的優(yōu)級高。④分析人員將分析結(jié)果記錄至《風險管理表》中。(4)確定風險計劃。①確定風險的基本策略可以分為以下幾種：·避免風險：在滿足用戶要求的前提下改變或是降低要求。·控制風險：采取行動減小風險的影響。·轉(zhuǎn)移風險：再分配風險需求以降低風險?！じ欙L險：監(jiān)控并周期性地評估風險并調(diào)整風險參數(shù)?！そ邮茱L險：接受風險，不采取任何措施。②針對風險管理表中等級高(A和B)的風險給出風險緩解計劃。③根據(jù)對風險的分析，確定風險產(chǎn)生的原因，制訂降低或避免風險的策略并記錄在風險管理表中，同時相關的措施也應該體現(xiàn)到項目進度表中。對風險等級為A的風險必須制訂緩解計劃，對風險等級為B的風險，可以視具體情況來確定是否制訂緩解計劃。由每個風險的責任者確定該風險管理計劃(包括緩解計劃和應對計劃)，應該包括以下元素：負責人、所需要的資源、開始日期、活動、預計結(jié)束日期、取得的結(jié)果。確定風險管理策略時，應該綜合考慮為控制和緩解風險所投入的成本、人力資源和風險本身發(fā)生對項目的影響之間的差距。舉例說明：同級評審耗費成本，但同級評審減少了工作產(chǎn)品中出現(xiàn)缺陷的可能性，同級評審減少了缺陷出現(xiàn)的后果——重復勞動，雖然同級評審耗費成本，但節(jié)約的超過了耗費的。完成風險計劃，填寫《風險管理表模板》。4.工作產(chǎn)品這個階段的工作產(chǎn)品為《風險管理表》的風險計劃部分。5.結(jié)束準則這個階段的結(jié)束準則是風險計劃審查通過。12.5.6制訂項目文檔管理識別需要收集的資料、資料的內(nèi)容和形式，制定管理資料的規(guī)程。資料是用以支持項目在各方面所要求的各種資料。資料管理的對象包括：(1)客戶提供的資料，如制度、報表、行業(yè)標準和資料等。(2)項目現(xiàn)有和待收集的參考資料，如網(wǎng)上資料、出版物、其他項目文檔。(3)項目管理方面的資料，如項目周報、評審記錄、會議紀要等。(4)采購方和供應方的資料，如合同、供應方評定資料等。資料的形式包括電子媒體、印刷材料、多媒體、照片等。1.參與角色項目經(jīng)理或指定人員根據(jù)《需求分析報告》(《需求規(guī)格說明書》)、已完成的《項目計劃》的內(nèi)容，策劃項目的資料管理。2.啟動準則這個階段的啟動準則是識別了項目資料。3.過程活動(1)策劃常規(guī)的項目資料，記錄在項目計劃中的配置管理庫層次結(jié)構(gòu)及權(quán)限分配表中。(2)建立確保資料的專屬性和安全性的要求和規(guī)程。(3)建立對歸檔資料的借閱機制，具體規(guī)定各類資料的允許借閱人和審批機制。(4)確定項目資料的識別、收集和分發(fā)規(guī)則，以便具體實施項目資料管理。4.工作產(chǎn)品這個階段的工作產(chǎn)品為《項目計劃》。5.結(jié)束準則這個階段的結(jié)束準則是已策劃了項目資料管理。12.5.7制訂項目培訓計劃策劃項目需要的知識和技能以支持項目執(zhí)行。培訓的成本雖然很高，但是不培訓所需付出的代價更高。1.參與角色項目經(jīng)理與項目組成員等一起制訂項目的培訓計劃。2.啟動準則項目的《需求分析報告》(《需求規(guī)格說明書》)、《工作陳述》、《項目計劃》中的WBS等文檔已經(jīng)完成。3.過程活動(1)確定完成項目所需的知識領域和技能。(2)將所列知識領域歸入以下類別：每人都應掌握的知識領域；組內(nèi)一些成員掌握的知識領域，這些成員可以培訓其他人員；公司內(nèi)部其他項目組成員掌握，并可以提供培訓的知識領域；公司內(nèi)部沒有人了解，但是可以通過自學掌握的知識領域；需要外部(也許來自客戶)培訓的知識領域；從上述領域中分離出那些需要任選培訓的知識領域。(3)識別出可以提供培訓的人員。(4)選擇提供必要知識和技能的機制。(5)將所選擇的機制納入項目計劃中，并估算各知識領域所需的培訓時間，不包括組織級的培訓需求。(6)實施培訓，并將培訓的經(jīng)驗和教訓記錄在《項目總結(jié)報告》中。4.工作產(chǎn)品這個階段的工作產(chǎn)品為《項目計劃》中的培訓計劃。5.結(jié)束準則這個階段的結(jié)束準則是《項目計劃》中的培訓計劃已經(jīng)完成。12.5.8制訂項目監(jiān)控過程制訂項目監(jiān)督計劃和過程并控制活動，直到項目結(jié)束。1.參與角色這個階段的參與角色是項目經(jīng)理。2.啟動準則這個階段的啟動準則是《項目計劃》已經(jīng)完成。3.過程活動(1)確定項目監(jiān)控需要的資源，主要包括成本跟蹤、工作量報告、項目管理和進度。(2)分配職責：確定項目監(jiān)控人及職責和權(quán)限；確定有關人員，理解分配給他們的職責和權(quán)限并接受任務。對于小型項目，可能是項目經(jīng)理作為項目監(jiān)控人員，進行項目監(jiān)控活動。(3)確定需求管理的共同利益者并確定其參與時機。項目經(jīng)理列出項目監(jiān)控相關的具體的共同利益者清單和參與時機。共同利益者參與項目監(jiān)控的主要活動包括對照計劃評估項目，審查各項承諾并解決問題，審查項目風險，審查資料管理活動，審查項目進展以及管理糾正措施直到結(jié)束。(4)制訂糾正措施審批規(guī)程。4.工作產(chǎn)品這個階段的工作產(chǎn)品為《項目計劃》中的項目監(jiān)控計劃。5.結(jié)束準則這個階段的結(jié)束準則是《項目計劃》中的項目監(jiān)控計劃文檔已完成。12.5.9制訂項目進度表制訂項目進度表時應以軟件估計為基礎，確保預算分配的任務復雜度和任務依賴性得到管理。1.參與角色項目經(jīng)理根據(jù)項目軟件估計表、WBS和策劃結(jié)果編制項目進度表。2.啟動準則這個階段的啟動準則是項目的《需求分析報告》(《需求規(guī)格說明書》)、《軟件估計表》、WBS已經(jīng)完成。3.過程活動(1)項目經(jīng)理確定項目進度。編制和維護項目的預算和進度一般包括：確定對資源和設施的承諾的或預期的可用性；確定各項活動的時間段落；確定突發(fā)的從屬進度；確定活動之間的依賴性；確定活動進度和里程碑，以支持準確的度量進度；確定向顧客交付產(chǎn)品的里程碑；確定各個活動的持續(xù)時間；確定里程碑的時間跨度；根據(jù)實現(xiàn)該進度的置信度水平確定管理儲備；利用適當?shù)臍v史數(shù)據(jù)驗證進度；確定可能增加的資金需求。(2)項目經(jīng)理確定重大里程碑。規(guī)定里程碑是為了確保在該點完成某些可交付工作產(chǎn)品。里程碑可以按事件或按日期規(guī)定。如果是按日期規(guī)定的里程碑，一旦確定，往往很難更改。(3)項目經(jīng)理確定約束條件。要盡可能早地確定限制項目管理者做出靈活選擇的因素，通過檢查工作產(chǎn)品和任務的屬性(如任務工期、資源、輸入和輸出)，往往可以揭示出制約因素。(4)項目經(jīng)理確定任務的依賴性。項目的各項任務一般可以按規(guī)定的順序來完成。了解以前成功完成的任務有助于確定任務的依賴性。可以用來幫助確定任務活動最佳順序的工具有關鍵路徑法、大綱評價和審查技術(shù)、基于資源的進度安排法。(5)?QAL根據(jù)策劃結(jié)果，將項目實施階段的質(zhì)量保證任務寫入項目進度表中。(6)項目經(jīng)理與CML共同確定項目建立的計劃、產(chǎn)品發(fā)布計劃、配置審計的計劃等。(7)評審策劃的結(jié)果，并將其體現(xiàn)在《項目進度表》中，包括評審類型、參加評審的人員和評審時間。(8)項目經(jīng)理負責將降低或避免風險策略的相關措施體現(xiàn)在《項目進度表》中。(9)項目經(jīng)理負責將客戶活動、供方管理、項目培訓等活動體現(xiàn)在《項目進度表》中。4.工作產(chǎn)品這個階段的工作產(chǎn)品為《項目進度表》。5.結(jié)束準則這個階段的結(jié)束準則是《項目進度表》文檔已經(jīng)完成。12.5.10合成項目計劃和從屬計劃合成項目計劃和從屬計劃，以描述項目已定義過程。合成項目計劃時，要考慮組織、顧客以及最終用戶的當前的和預計的需求和目標。1.參與角色項目經(jīng)理負責合成項目計劃和從屬計劃。2.啟動準則這個階段的啟動準則是《項目計劃》和從屬計劃已存在。從屬計劃可以包括《項目監(jiān)控計劃》、《度量計劃》、《質(zhì)量保證計劃》、《配置管理計劃》等。3.過程活動(1)項目經(jīng)理評審項目從屬計劃，確定是否與項目計劃一致。(2)項目經(jīng)理將從屬計劃與項目計劃相結(jié)合。(3)項目經(jīng)理結(jié)合開發(fā)的關鍵因素和項目風險按順序安排任務進度。在進度安排中要考慮的因素有以下內(nèi)容：任務的規(guī)模和復雜程度、集成和測試問題、顧客和最終用戶的需求、關鍵資源的可用性、關鍵人員的可用性。(4)項目經(jīng)理在預計的資源與可用的資源之間求得平衡。(5)如果現(xiàn)有資源不足，一般通過以下方式實現(xiàn)它們之間的平衡：降低或延緩實現(xiàn)技術(shù)性能要求，協(xié)商得到更多的資源，尋求提高生產(chǎn)率的途徑，采購，對項目人員的技能組合加以調(diào)整，修訂從屬計劃或進度。4.工作產(chǎn)品這個階段的工作產(chǎn)品為合成后的《項目計劃》和《項目進度表》。5.結(jié)束準則這個階段的結(jié)束準則是合成的《項目計劃》已經(jīng)完成。12.5.11獲得對計劃的承諾讓所有負責實施和支持該項目計劃實施的相關者得到承諾。承諾活動涉及項目內(nèi)、外所有相關共同利益者之間的互動行為。應該讓作出承諾的個人或團體相信，這項工作能夠在規(guī)定的成本、進度和性能條件下完成。1.參與角色項目經(jīng)理負責與項目組內(nèi)人員、相關共同利益者協(xié)商，獲得對項目計劃的承諾。2.啟動準則這個階段的啟動準則是《項目計劃》和項目從屬計劃等已經(jīng)完成。3.過程活動(1)承諾的原則：承諾人自愿做出承諾；承諾是公開的；承諾人有責任執(zhí)行承諾的內(nèi)容；在承諾期限之間如果很清楚不可能按期完成，則必須通知相關方，應對承諾內(nèi)容進行變更，協(xié)商新的承諾。(2)承諾方式：①組織內(nèi)部承諾：請求承諾可以由項目經(jīng)理或QAL負責組織項目計劃的評審，以E-mail的形式發(fā)給高層經(jīng)理、其他評審人員和項目組全體人員。②組織外部承諾：可以根據(jù)參加承諾的相關方的要求，選擇適合的方式。(3)獲得計劃承諾主要進行以下步驟：①與相關的共同利益者共同確定必要的支持，協(xié)商承諾。為了保證所有的任務得到承諾，可以用項目進度表作為檢查表。②將所有承諾形成文件。文件包括全部的承諾，確保相關人員在承諾文檔上簽字。承諾必須形成文件，以保證理解一致，保證可以溯源和維護。承諾可以附件說明，指出與這種承諾關系相關的風險。承諾的方式可以是簽字、郵件、傳真等方式。如果有郵件或傳真件，則高層經(jīng)理及其他必要的人員可以不在文檔上簽字，打印名字即可。要將文檔與承諾的證據(jù)(郵件或傳真等)保存在一起。③高層經(jīng)理審查承諾。4.工作產(chǎn)品這個階段的工作產(chǎn)品為評審通過的《項目計劃》。5.結(jié)束準則這個階段的結(jié)束準則是《項目計劃》已評審通過，并已納入配置管理。12.5.12評審由于評審要評定項目的狀態(tài)或技術(shù)，并對下一步的工作做出指導，因此評審必須做好充分的準備，并且評審后必須有明確的結(jié)論。1.參與角色項目經(jīng)理指定評審負責人，評審負責人負責組織評審。2.啟動準則這個階段的啟動準則是待評審的工作產(chǎn)品已經(jīng)完成。3.過程活動(1)評審策劃：項目經(jīng)理根據(jù)項目的進展確定評審的時間、評審的主要內(nèi)容和通過評審希望達到的目的，確定評審的負責人。將策劃的結(jié)果記錄到《項目進度表》中。(2)組織和準備：為了確保評審的成功和順利，項目經(jīng)理必須做好評審的組織和準備工作。(3)評審前溝通：在評審正式進行之前，負責人應該與參加評審的人員進行溝通并通知QAL，確定評審的時間、地點、內(nèi)容、目標和議程，溝通的方式既可以是舉行一個會議，也可以通過電子郵件或電話等方式來進行，同時將評審相關的材料提前分發(fā)給參加評審的人員，建議參加評審的人員在評審前要通過這些材料了解評審的內(nèi)容，必要時可以向負責人索要進一步的材料。(4)評審：評審開始后，必要時負責人介紹背景和目標，然后根據(jù)議程使用適當?shù)臋z查表進行評審。當所有的議程都得到了評審，有了明確的結(jié)論后，評審負責人向參加評審的全體人員重申對每項議程做出的結(jié)論，確保沒有歧義后可以結(jié)束本次評審。必要時可以安排再次的評審。(5)評審記錄：記錄員記錄評審的問題和做出的決定，評審結(jié)束后，將評審記錄和評審問題管理表整理送評審負責人確認后分發(fā)給參加評審的所有人員，同時將評審記錄歸檔。(6)評審問題管理：評審負責人按評審問題管理表的記錄檢查評審問題的處理結(jié)果，確認問題已經(jīng)得到解決后，關閉這個問題。當所有問題都解決后，將評審問題管理表歸檔。(7)評審類型：包括管理評審、技術(shù)評審、同級評審和項目經(jīng)理評審。①管理評審：管理評審的目的是監(jiān)控項目的實際進展，確定項目在進度、成本、資源等方面的狀態(tài)。項目當前的狀態(tài)不能滿足目標或要求時，應當采取適當?shù)募m正措施，可參考的措施有變更項目的計劃、變更項目的資源、變更項目的工作范圍等。管理評審關注的焦點應當是項目的狀態(tài)，而不應過多地涉及技術(shù)問題，技術(shù)問題應當通過技術(shù)評審來解決。②技術(shù)評審：技術(shù)評審的目標是檢查軟件工作產(chǎn)品是否滿足規(guī)格要求和相關的標準，是否能夠完成預定的目標，是否可以作為下一階段工作的輸入。技術(shù)評審一般要求參加者應當有相應的資歷。技術(shù)評審主要關注以下幾個方面的問題：軟件產(chǎn)品是否能夠完成預定的功能；軟件產(chǎn)品是否能夠覆蓋所有的需求；軟件產(chǎn)品是否符合相關的標準和規(guī)范；軟件工作產(chǎn)品是否一致并且完整等。技術(shù)評審的結(jié)果記錄在《同級評審和技術(shù)評審記錄》中。③同級評審：同級評審需要《同級評審過程》和《同級評審工作指南》。④項目經(jīng)理評審：項目經(jīng)理的評審主要指的是項目管理者在合適的層次上跟蹤項目關鍵實踐的執(zhí)行。項目經(jīng)理應定期地或事件驅(qū)動地參加項目里程碑處和項目組內(nèi)部的評審，應評審以下方面：·評定項目的風險，評審技術(shù)、成本、人員、進度等性能?！ぴu審項目的關鍵計算機資源的使用?！そ鉀Q較低層次上無法解決的問題?！し峙浜驮u審措施條款并跟蹤到結(jié)束?！㈨椖康臓顟B(tài)通知受影響的組。同時，項目經(jīng)理也應當定期地參與對項目的需求管理、項目策劃、項目跟蹤與監(jiān)督、QA、CM、工程過程、過程改進、培訓等活動的評審。項目經(jīng)理的評審結(jié)果可以記錄在管理評審記錄或會議紀要中，并對發(fā)現(xiàn)的問題跟蹤解決。4.工作產(chǎn)品這個階段的工作產(chǎn)品為《項目進度表》。5.結(jié)束準則這個階段的結(jié)束準則是評審中發(fā)現(xiàn)的問題已全部關閉，質(zhì)量保證人員評審和審計了項目跟蹤與監(jiān)控活動的工作產(chǎn)品及結(jié)果報告。12.5.13跟蹤項目計劃估計值定期對項目計劃中的估計參數(shù)在實際實施中的實際值進行跟蹤，將實際值與計劃中的估計值加以比較，從中識別明顯的偏離并進行調(diào)整。1.參與角色根據(jù)《項目計劃》，項目經(jīng)理跟蹤項目策劃中估計參數(shù)的實際值。2.啟動準則這個階段的啟動準則是《項目計劃》等文檔已經(jīng)完成，項目已經(jīng)開始執(zhí)行。3.過程活動(1)跟蹤項目進度，有以下幾個步驟：①項目經(jīng)理根據(jù)開發(fā)成員每天的《項目日報》，跟蹤進度并更新項目進度表。②項目計劃變更或重大事件發(fā)生時，重新估計里程碑的進度。每個里程碑結(jié)束時，項目經(jīng)理將里程碑的實際完成日期填入《項目狀態(tài)報告》中。③如果實際進度數(shù)據(jù)超出閾值，則項目經(jīng)理分析原因，采取糾正措施，必要時變更項目計劃。項目進度表更新后，項目經(jīng)理要注意項目關鍵路徑的變化，調(diào)整關鍵任務保證關鍵路徑長度滿足項目工期要求。(2)跟蹤項目工作量，有以下幾個步驟：①每個里程碑結(jié)束時，項目經(jīng)理從《項目日報》中匯總出項目的工作量數(shù)據(jù)，填入《項目狀態(tài)報告》。當實際工作量超出閾值時，則分析原因并采取糾正措施，必要時變更項目計劃。②項目計劃變更或重大事件發(fā)生時，重新估計項目的工作量。項目結(jié)束時，項目經(jīng)理根據(jù)匯總《項目日報》的工作量數(shù)據(jù)，填寫項目各類活動的實際工作量，分析工作量的分布情況。對工作量的分布情況分析也可以作為組織財富的內(nèi)容之一，為過程改進提供依據(jù)。(3)跟蹤需求。在每個里程碑進行過程中如果發(fā)生需求變更，將需求變更數(shù)據(jù)及影響填寫入《項目狀態(tài)報告》中的需求跟蹤表中。項目經(jīng)理分析需求變更比率，當需求變更比率異常時，分析原因，定量分析需求變更對規(guī)模、工作量、進度等的影響，采取相應的糾正措施。(4)跟蹤項目規(guī)模。當項目計劃變更時或重大事件發(fā)生(如需求變更)時，重新對規(guī)模進行估計。里程碑結(jié)束時，將規(guī)模的實際值填入《項目狀態(tài)報告》的項目數(shù)據(jù)匯總之《規(guī)模數(shù)據(jù)表》中。當規(guī)模發(fā)生較大偏差時，分析原因，采取糾正措施，必要時變更項目計劃。(5)跟蹤評審和測試的缺陷數(shù)據(jù)。項目經(jīng)理將同級評審和技術(shù)評審發(fā)現(xiàn)的缺陷填入《同級評審和技術(shù)評審記錄》中。開發(fā)人員或測試人員完成測試工作后，將缺陷數(shù)據(jù)填入BUGBASE或其他缺陷記錄工具中。(6)跟蹤關鍵依賴關系，有以下幾個步驟：①項目經(jīng)理按計劃向關鍵依賴產(chǎn)品的接收方通報產(chǎn)品的狀態(tài)，例如開發(fā)進度、存在問題、可能提前或滯后完成的時間和原因等。②項目經(jīng)理要及時向提供方通報對于關鍵依賴產(chǎn)品要求的變化情況，例如變更功能、可能會提前或滯后的時間和原因等。③按計劃根據(jù)驗收準則驗收關鍵依賴產(chǎn)品。④當發(fā)生問題時，由問題涉及的雙方或多方協(xié)商解決。如問題不能得到解決，項目經(jīng)理向高層經(jīng)理匯報，直到問題關閉。(7)跟蹤項目培訓：項目經(jīng)理將培訓實施的具體時間及培訓講義等資料，發(fā)給將要參加培訓的所有人員。在培訓期間，參加培訓的人員要向項目經(jīng)理匯報培訓進展情況。匯報可以寫在項目日報中。培訓結(jié)束后，將培訓的實際情況記錄在《項目狀態(tài)報告》的培訓跟蹤表中。(8)跟蹤項目資料管理：將項目資料管理中發(fā)現(xiàn)的問題，記錄在《配置管理活動報告》中，跟蹤