山東大學軟件過程管理復習綱要

1、項目管理支持活動有哪些？

配置管理，度量和分析，決策分析。

2、CMM/CMMI、PSP、TSP、RUP、XP、SCRUM、PDCA、MSG、SEPG、WBS、SPI

CMM——軟件能力成熟度模型（CapabilityMaturity Model，CMM）是美國卡內基.梅隆大學軟件工程研究所（SEI）聚集了世界各地軟件進程管理者的檢驗和智慧而產生的軟件進程改進的指點性模型。該模型經過世界各地軟件組織的實際利用，證明其對軟件進程改進具有建設性作用。

CMMI——軟件能力成熟度模型集成（CapabilityMaturity Model Integration）

PSP——個體軟件進程（Personal SoftwareProcess）是1種可用于控制、管理和改進個人工作方式的自我延續改進進程，是1個包括軟件開發表格、指南和規程的結構化框架。

TSP——團隊軟件進程（Team SoftwareProcess）是1個已被良好定義和證明的支持構建和管理團隊的最好實踐，指點團隊中的成員如何有效地計劃和管理所面臨的項目開發任務，告知管理人員如何指點軟件開發隊伍。

RUP——Rational統1進程（Rational Unified Process）由Rational公司推出的1種軟件進程框架。包括6條開發經驗，迭代式開發、管理需求、使用基于構建的體系結構、可視化建模、驗證軟件質量、控制軟件變更。

XP——極限編程（eXtreme Programming）是敏捷進程中最負盛名的1個，其名稱“極限”2字的含義是指把好的開發實踐應用到極致。

SCRUM——是1種迭代式增量的敏捷軟件開發進程，包括了1系列時間和預定義角色的進程骨架。

PDCA——（Plan-Do-Check-Action計劃-履行-檢查-行動）PDCA循環式能使任何1項活動有效進行的1種合乎邏輯的工作程序，特別是在質量管理中得到了廣泛的利用。

MSG——管理層指點組（Management SteeringGroup，MSG）

SEPG——軟件工程進程組（SoftwareEngineering Process Group，SEPG）

WBS——工作分解結構（Work BreakdownStructure）是以可交付成果為導向的對滿足項目目標和開發交付產物的項目相干工作進行的分解。

SPI——軟件進程改進（Software ProcessImprovement，SPI）

3、軟件進程與軟件質量的關系

軟件產品的質量取決于開發軟件的進程管理的質量，對1個軟件組織來說，可以通過軟件進程改進來提高其所開發的軟件產品的質量。

4、PROBE估算產品范圍的基本流程

（1） 概要設計

初步設計，為了輔助估算而進行的1種類似于搭積木的游戲的工作。

（2） 代理辨認

根據概要設計的結果，為每塊“積木”制定適合的類型，定義適合的相對大小，從而肯定其范圍。

（3） 估算并調劑程序范圍

代理范圍與程序范圍常常不1樣，以面向對象程序設計語言為例，1般情況下，除類和類中的方法以外常常還有1些代碼在類的外部或方法的外部，估算的時候也需要斟酌這些代碼。另外，由于估算本質上是1種主觀判斷，因此難免出現偏差，而且，這類偏差不能簡單地根據上1次的偏差進行補償修正。

（4） 估算并調劑資源

對項目所需資源的估計也是由代理范圍通過線性回歸的方法進行調劑計算而得。

（5） 計算預測區間

在取得了調劑后的估算結果以后，還需要對估算結果進行評價，通常采取的方法就是計算預測區間。

5、相干性和顯著性描寫甚么

相干性——描寫的是兩組變化的數據之間相互關聯的程度。

顯著性——描寫的是兩組數據的相干關系出現的偶然程度，顯著性越小越好。

6、利用PROBE方法估算范圍時，A，B，C，D4類方法的數據要求是甚么

7、質量指標的含義和計算（Yield、A/FR、PQI、評審速度、DRL）

Yield——用以度量每一個階段在消除缺點方面的效力。

Phase Yield（某個階段缺點消除的效力）=100*（某個階段發現的缺點個數）/（某個階段注入的缺點個數+進入該階段前遺留的缺點個數）

Process Yield（第1次編譯之前消除缺點的效力）=100*（第1次編譯前發現的缺點個數）/（第1次編譯前注入的缺點個數）

A/FR——是1個用以指點軟件工程師公道安排評審和測試時間的指標。

A/FR=PSP質檢本錢/PSP失效本錢

（1）理論上，A/FR的值越大，常常意味著越高的質量。

（2）太高的A/FR常常意味著做了過量的評審，反而會致使開發效力的降落。作為指南，

（3）在PSP中A/FR的期望值就是2.0

PQI——（Process Quality Index，進程質量指標）用以度量PSP進程的整體質量。范圍是從0.0⑴.0。

PQI=設計質量*設計評審質量*代碼評審質量*代碼質量*程序質量。

設計質量：設計的時間應當大于編碼的時間

設計評審質量：設計評審的時間應當大于設計時間的50%

代碼評審質量：代碼評審時間應當大于編碼時間的50%

代碼質量：代碼的編譯缺點密度應當小于10個/千行

程序質量：代碼單元測試缺點密度應當小于5個/千行

l  評審速度——（Review Rate）是1個用以指點軟件工程師展開有效評審的指標。高質量的評審又需要軟件工程師投入足夠的時間進行評審。在PSP的實踐中，代碼評審速度小于200 LOC/小時，文檔評審速度小于4 Page/小時。

DRL——（Defect-Removal Leverage，缺點消除效力比）度量的是不同缺點消除手段消除缺點的相對效力。

DRL=其他階段每小時發現的缺點數/該測試階段每小時發現的缺點數

8、兩階段小組評審的進程，如何估算小組評審以后評審對象遺留的缺點數（不知道為何，感覺會出計算題，建議看懂。）

（1）小組評審只有兩個人參加。假定評審人員A和B分別發現了a個缺點和b個缺點，其中c個缺點兩人同時發現。利用捕魚（統計學中經典的估算池塘中魚總數的方法，即先捕1網，對所有捕獲的魚進行標記，再將魚放回池塘，過1段時間，再捕1網，那末通過該網中被標記的魚的數目和未被標記的魚的數目比例，便可大致測算全部池塘的魚總數的方法。這個是解釋，考試不用寫。打字手疼。）的思想，選擇a-c和b-c中較大值，如果相等則可以任選1值。假定a-c是選定的值，那末就能夠估算出評審對象經太小組評審以后，還遺留a*b/c-(a+b-c)個缺點。

    （2）小組有多人參加。小組評審如果有多人參與，那末情況就會相對復雜，我們采取1個簡化的計算方法，即選擇某個獨立發現缺點最多的評審員作為A，而其他所有參與人員的整體作為B。那末我們依然可使用上述的方式來估算小組評審以后評審對象中遺留的缺點數。

9、失效本錢、質檢本錢、預防本錢的差異

是質量本錢的3個組成部份

失效本錢——分析失效現象、查找緣由、做必要的修改所消耗的本錢。

質檢本錢——評價軟件產品，肯定其質量狀態所消耗的本錢。

預防本錢——辨認缺點根本緣由、采取措施預防其再次產生所消耗的本錢。

為了操作方便，在PSP中對上述定義稍作簡化，PSP中主要關注失效本錢和質檢本錢，而預防本錢1般包括在總結階段和平時評審檢查表的保護中，因此，不專門進行計算。PSP中定義的失效本錢為編譯時間和單元測試時間之和，PSP中定義的質檢本錢為設計評審時間與代碼評審時間之和。

10、           PSP中各設計模板的作用  

（1） OST（OperationalSpecification Template，操作規格模板）描寫的是系統與外界的交互，具體而言，是描寫“用戶”與待設計系統的正常情況和異常情況下的交互。可以用來定義測試場景和測試用例，也能夠作為和系統用戶討論需求的基礎，特別是操作相干的需求描寫。

（2） FST（FunctionalSpecification Template,功能規格模板）描寫的是系統對外的接口，這是1種靜態的描寫，在FST中提供的典型信息包括類和繼承關系、外部可見的屬性和外部可見的方法等。在使用FST模板的時候，消除2義性非常重要。因此，應盡可能用情勢化符號來描寫方法行動。

（3） SST（StateSpecification Template，狀態規格模板）可以精肯定義程序的所有狀態、狀態之間的轉換和伴隨每次狀態轉換的動作。在SST模板中，需要描寫以下信息——所有狀態的名稱、所有狀態的扼要描寫、在SST中需要使用的參數和方法的名稱與描寫、狀態轉換的條件、伴隨狀態轉換而產生的動作。

（4） LST（LogicalSpecification Template，邏輯規格模板）可以精確描寫系統的內部靜態邏輯。為了消除描寫的2義性，1般建議用偽代碼配合情勢化符號來描寫設計結果。在LST模板中，需要描寫以下信息——關鍵方法和靜態邏輯、方法的調用、外部援用、關鍵數據的類型和定義。

11、           正確的狀態機設計應當滿足哪些要求

1個設計正確的狀態機的狀態轉換必須滿足兩個條件，即必須滿足完全性和正交性。狀態轉換完全性是指對狀態機中任何1個狀態，對應的所有條件組合，下1個狀態的轉換都有定義。狀態轉換正交性是指對狀態機中任何1個狀態，其所有下1個狀態的轉換條件不能相同，簡言之，在1個正確狀態機中，任何1個狀態，當對應的條件組合1樣時，其下1個狀態必須唯1定義。

對狀態機的驗證，通常采取以下步驟進行，

（1） 檢驗狀態機，消除死循環和圈套狀態。

（2） 檢查狀態轉換，驗證完全性和正交性。

（3） 評價狀態機，檢驗是不是體現設計意圖。

12、           PSP中驗證設計主要有哪些方法？各有甚么優勢和不足

包括狀態機驗證、符號化驗證、履行表驗證、跟蹤表驗證、正確性驗證。

（1） 狀態機驗證步驟如上

（2） 符號化履行驗證的基本思想是將描寫設計的邏輯規格（1般用偽代碼程序表示）用代數符號來表示，然后系統地展開分析和驗證。具體步驟以下：辨認偽碼程序中的關鍵變量；將這些變量用代數符號表示，重寫偽碼程序；分析偽碼程序的行動。

優缺點：

符號化驗證的方法實行簡單，可以給出1般化的驗證結果，很多時候常常是唯1提供全面驗證的方式。

這類方法通經常使用在驗證1些復雜算法中，特別是對遺留系統的改造中，常常利用這類方法來辨認和理解原本的設計。

但是這類驗證方法不適用于有復雜邏輯的場合，而且，純手工的驗證方法也容易引入1些人為的毛病。

（3） 履行表驗證用1種有序的方法來跟蹤偽碼程序的履行狀態，分析程序行動，從而驗證設計。具體步驟以下：辨認偽碼程序的關鍵變量；構建表格，表格左邊填入主要程序步驟，右邊填入關鍵變量；初始化被選定的變量；跟蹤被選擇的關鍵變量的變化情況，從而判斷程序行動。

優缺點：

履行表驗證可以用以復雜邏輯的驗證，實行簡單，結果可靠。

而這類方法也有1些不足，比如每次只能驗證1個用例，手工驗證既耗時，也容易出錯等。

（4） 跟蹤表驗證方法是對履行表驗證方法的1種擴充。具體步驟以下：辨認偽碼程序的關鍵變量；構建表格，表格左邊填入主要程序步驟，右邊填入關鍵變量；初始化被選定的變量；辨認將偽碼程序符號化的機會，并加以符號化；定義并且優化用例組合；跟蹤被選擇的關鍵變量的變化情況，從而判斷程序行動。

（5） 正確性檢驗將偽碼程序當做數學定理，采取情勢化方法加以推理和驗證。這類方法的步驟以下：分析和辨認用例；對復雜偽碼程序的結構，利用正確性檢驗的標準問題逐項加以驗證；對不能明確判斷的復雜程序結構，使用跟蹤表等輔助驗證。

13、           解釋客戶需求、產品需求和產品組件需求的區分和聯系

（1） 客戶需求描寫的是客戶的期望。客戶在實際工作中碰到了1些具體問題，希望通過軟件系統來幫忙解決這些問題，客戶的這類解決問題的欲望，常常就代表為客戶需求。

（2） 產品需求描寫的是開發團隊所提供的解決方案，即針對客戶需求，開發團隊設計出1個可以幫助客戶解決工作中碰到的問題的方案。該方案常常就表述為產品需求。產品需求是對客戶需求的1個提煉和精化，把客戶需求真正表述為開發人員夠理解的語言，一樣，產品需求需要進行驗證，以確保客戶的真實意圖得到了體現。

（3） 產品需求組件描寫的是組成產品的各個組件的需求價格，與產品需求相比，這是在更細小的顆粒上，更加細致地描寫了上述解決方案中的某個組建的功能、性能、情勢等。

14、           產品集成有哪些典型的策略，優缺點是甚么

產品集成策略包括大爆炸集成、逐1添加集成、集簇集成、和扁平化集成等。

（1） 大爆炸集成策略，將所有已完成的組件放在1起，進行1次集成。測試用例最少，每一個用例測試次數最少，但是，難以定位缺點位置，系統越復雜，范圍越大，問題越突出。

（2） 逐1添加集成策略，與大爆炸集成策略完全相反，采取1次添加1個組建的方式進行集成。優點是很容易定位缺點的位置，但是需要測試的用例最多，大量的回歸測試會消耗很多時間。

（3） 集簇集成策略，是對逐1添加集成策略的改進，為了提升測試效力，把有相似功能或有關聯的模塊優先進行集成，構成可以工作的組件，然后以組件為單位繼續進行較高層次的集成。優點是可以盡早取得1些可以工作的組件，有益于其他組件測試工作的展開。缺點是過于關注個別組件，缺少系統的整體觀，不能盡早發現系統級的缺點。

（4） 扁平化集成策略，要求盡快構建1個可以工作的扁平化系統，優先集成高層的部件，然后逐漸將各個組件、模塊的真正實現加入系統。優點是可以盡早發現系統層面的缺點，缺點是為了確保完成系統，需要大量的打“樁”，即提供1些直接提供返回值的偽實現。這類測試方式常常不能覆蓋全部系統應當處理的多種狀態。

15、           項目計劃階段需要制定哪些計劃？約定的內容是甚么？

任務計劃、日程計劃、質量計劃、風險計劃等

項目各項計劃完成以后，需要與各類計劃的相干干系人展開評審工作，解決計劃中相互矛盾與不1致的地方，并取得參與項目的各方對項目計劃的許諾。

(1)辨認每項計劃所需支持，并與相干干系人協商許諾。

(2)記錄所有的許諾，包括完全的許諾和臨時的許諾，并確保由適當層次的人員簽署。

(3)適時與資深管理人員1起審查許諾。

16、           甚么是風險？風險應對的方法。

風險，可能會給項目目標的實現帶來負面影響的潛伏問題。

風險管理是1個延續的、前瞻的進程，此進程是項目管理的重要部份。有效的風險管理是通過相干干系人的合作與參與，盡早且積極地辨認風險，制定項目風險管理計劃。風險管理須同時斟酌有關本錢、進度、績效及其他風險的內部及外部來源。由于在項目早期進行變更或修正的工作負荷，通常比在項目后期來得容易、花費較低及較不具破壞性，所以，初期及積極的風險偵測是重要的。風險管理大致分成兩部份，即風險辨認和風險應對。

風險應對的方法

風險轉嫁

風險轉嫁是指通過某種安排，在放棄部份利益的同時，將部份的項目風險轉嫁到其他的團隊或組織。比如有的公司采取外包的方式，把1部份有技術風險的產品組件交由其他公司開發，在放棄部份收益的同時，也規避了技術風險。

風險解決

風險解決是指采取1些有效措施，使得風險的來源不再存在。這常常是1種預防性的手段。比如針對項目面臨的技術風險，采取技術調研或引進技術專家的手段，使得原本的風險來源不再存在或存在可能性極低，從而測試解決該風險。

風險減緩

風險減緩是指容忍風險的存在，采取1些措施監控風險，不讓風險對項目終究目標的實現造成負面影響。1般情況下，都需要制定相應的風險減緩計劃。理性對待每一個關鍵性的風險，研究可選擇的應對方案，并對每一個風險皆制定相應的行動進程，是風險減緩計劃的關鍵內容。特定風險的風險減緩計劃包括規避、下降及控制風險產生可能性的技術和方法，或下降風險產生時遭受的損失程度的方法，或上述二者。監控風險，當風險超過設定的閾值時，實行風險減緩計劃，以使受沖擊的部份回歸到可接受的風險等級。只有當風險結果評定為高或沒法接受時，才相應制定風險減緩計劃和緊急應變計劃，其它其他情況只需要適當監控便可。

17、           掙值管理方法的原理

（1）BAC表示依照PV值的曲線，當項目完成的時候所需預算或時間

（2）本錢差異CV = EV-AC，表示的是已完成的的工作與所消耗的本錢的差異。可以表示為消耗的時間，也能夠表示為消耗的資金。

（3）本錢差異指數CPI = EV/AC，表示單位本錢創造的價值。<1表示超支，=1表示與預期1致，>1表示本錢低于預期。

（4）日程偏差SV = EV – PV，表示進度偏差。<0表示進度落后，=0表示進度正常，>0表示進度超前。

（5）日程偏差指數SPI = EV/PV

（6）預計完成本錢EAC = AC+(BAC-EV)/CPI = BAC/CPI，表示的是依照目前的進展和本錢消耗情況，全部項目完成的時候所需消耗的本錢。

18、           BAC、PV、EV、AC、CV、SV、CPI、SPI、EAC

(1)BAC（項目總預算）

(2)PV（PlanningValue，計劃價值）

(3)EV（EarnedValue，掙值）

(4)AC（ActualCost，實際本錢）

(5)CV（CostVariance，本錢差異）

(6)SV（ScheduleVariance，日程偏差）

(7)CPI（CostPerformed Index，本錢差異指數）

(8)SPI（SchedulePerformed Index，日程偏差指數）

(9)EAC（ExpectedAccomplished Cost，預計完成本錢。

l  BAC表示依照PV值的曲線，當項目完成的時候所需預算或時間

l  本錢差異CV = EV-AC

l  本錢差異指數CPI = EV/AC

l  日程偏差SV = EV – PV

l  日程偏差指數SPI = EV/PV

l  預計完成本錢EAC = AC+(BAC-EV)/CPI = BAC/CPI

（課本習題）

BAC 1000

PV 200

EV 50

AC 100

CV ⑸0

SV ⑴50

CPI 0.5

SPI 0.25

EAC 2000

ETC 1900

19、           項目跟蹤的意義

（1） 在項目進展進程中展開跟蹤活動的目的在于了解項目進度，以便在項目實際進展與計劃產生嚴重偏離時，可采取適當的糾正措施。展開及時有效地項目跟蹤就是期望及時發現和處理項目實際進展與計劃之間的偏差，從而消除積累的偏差對項目釀成的負面影響。

（2） 判斷項目進度滯后需要參照物，文檔化的項目計劃就是監控各項項目活動，溝通狀態及采取糾正措施的根據。

（3） 項目跟蹤除發現偏差以外，更重要的是管理針對偏差而采取的糾偏措施。

（4） 項目小組需要對項目糾偏措施進行跟蹤和管理，其目的是確保項目香足所采取的糾偏措施真正有效。

在項目進展進程中展開跟蹤活動的目的在于了解項目進度，以便在項目實際進展與計劃產生嚴重偏離時，可采取適當的糾正措施。

項目進度滯后與否需要參照物，即項目計劃。

項目跟蹤需要管理針對偏差而采取的糾偏措施。

20、           項目總結的目的和意義

（1） 軟件項目的特點決定了延續改良對軟件工程師的重要性。

（2） Rita Mae Brown在書中寫到的那樣“所謂的笨拙（Insanity）就是反復做一樣的事情，但是期望有不同的結果”

（3） 提供1個系統化的方式來總結經驗教訓、避免犯一樣的毛病、評估項目團隊績效、積累進程數據等。提供給項目團隊成員延續學習和改進的機會。

21、           配置項、基線

（1） 配置項是在配置管應當中作為單獨實體進行管理和控制的工作產品集合。

（2） 基線是配置項延續演進的穩定基礎。發布1個基線包括該基線所有的配置項和這些配置項的最新變更，因此，可以將基線作為接下來工作的基礎。典型的發布基線時間點為需求分析以后、設計完成以后、單元測試以后和終究產品發布。

22、           配置管理的目標和活動

配置管理的目的是建立與保護工作產品的完全性。

配置管理的活動

（1）   辨認配置項

（2）   建立配置管理系統

（3）   創建和發布基線

（4）   跟蹤變更要求

（5）   控制配置項變更

（6）   建立配置管理記錄

（7）   配置審計

23、           GQM方法原理

GQM從管理的目標動身，將目標歸納、分解為可度量的指標，并把這些指標提煉成可以丈量的值。實行進程是從上到下的分析進程和從下到上的履行進程。首先提出度量目標G（Goal）；然后將該目標細化為關于進程或產品的特定問題Q（Question）；這些問題以度量M（Metric）的方式得到回答。

GQM方法在3個層次上定義度量模型：

概念層（目標）

操作層（問題）

量化層（度量）

24、           自主團隊的特點

（1） 自行定義項目的目標

（2） 自行決定團隊組成情勢和成員的角色

（3） 自行決定項目的開發策略

（4） 自行定義項目的開發進程

（5） 自行制定項目的開發計劃

（6） 自行度量、管理和控制項目工作

25、           組織級進程改進的1般工作思路

（1） 啟動組織級的軟件進程改進

（2） 診斷存在的問題

（3） 給出改進計劃

（4） 建立基礎設施

（5） 履行改進計劃

（6） 分析結果

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈