第三章軟件項目管理

第三章軟件項目管理主講：肖丁dxiao@;北京郵電大學通信軟件工程中心203二月2023提綱3.1項目管理過程3.2風險管理3.3軟件質量和效率度量3.4軟件項目估算3.5軟件項目進度安排3.6項目組織結構設計3.7項目過程監(jiān)控303二月20233.1項目管理過程項目的定義：是為創(chuàng)造獨特產品、服務或其它成果而進行的一次性工作。項目的屬性：（對比常規(guī)運作）一次性/獨特性；目標的確定性/過程的不確定性；時間、成果、需求的滿足；確定性項目目標允許修改；不確定性活動的整體性/過程的漸進性；項目組織的臨時性和開放性；對資源的依賴性；403二月20233.1項目管理過程項目管理的定義：是以項目為對象的系統(tǒng)管理方法。即：由柔性組織（臨時/專門）運用：知識、技術、工具、手段進行：高效率的計劃、組織、執(zhí)行、控制實現(xiàn)：項目過程的動態(tài)管理、項目目標的綜合協(xié)調與優(yōu)化。軟件項目管理的定義：為了使軟件項目能夠按照預定的成本、進度、質量順利完成，而對人員、產品、過程和項目進行分析和管理的活動。503二月2023項目的全目標管理：面向系統(tǒng)（可交付的軟件）、組織（運營該軟件的組織）、人員（組成該組織的人員）；全面滿足質量、進度、費用的要求。項目的全過程管理：啟動過程---確定目標、范圍；計劃過程---時間、任務、進度；執(zhí)行過程---實施所需的任務；控制過程---監(jiān)控度量項目的進程；結束過程---驗收603二月20233.1項目管理過程軟件項目管理的對象是軟件工程項目。它所涉及的范圍覆蓋了整個軟件工程過程。。為使軟件項目開發(fā)獲得成功，關鍵問題是必須對軟件開發(fā)項目的工作范圍、可能風險、需要資源（人、硬件／軟件）、要實現(xiàn)的任務、經歷的里程碑、花費工作量（成本）、進度安排等做到心中有數(shù)軟件項目管理可以提供上述信息。軟件項目開始于技術工作開始之前，持續(xù)進行于軟件實現(xiàn)過程中，終止于軟件工作過程結束。703二月20233.1項目管理過程項目管理過程包括下列任務：人員的組織與管理，軟件度量，項目計劃，風險管理，質量保證，軟件過程能力評估，配置管理等。軟件項目的主要活動包括：3.1.1啟動一個軟件項目3.1.2度量3.1.3估算3.1.4風險分析3.1.5進度安排3.1.6追蹤和控制3.1.7結束項目803二月20233.1.1啟動一個軟件項目在制定軟件項目計劃之前，必須

明確項目的目標和范圍考慮候選的解決方案標明技術和管理上的要求有了這些信息，才能確定合理、精確的成本估算，實際可行的任務分解以及可管理的進度安排。903二月20233.1.2度量進行度量工作，是為了了解產品開發(fā)的技術過程和產品本身。度量開發(fā)過程的目的是為了改進過程，度量產品的目的是為了提高產品的質量。度量的作用是為了有效地定量地進行管理。管理人員和技術人員可利用這些度量來了解軟件工程過程的實際情況和它所生產的產品質量。問題：請思考，哪些是可度量的指標？1003二月20233.1.3估算在軟件項目管理過程中關鍵的活動就是制定項目計劃。做計劃必須就需要的人力（以人月為單位）、項目持續(xù)時間（以年份或月份為單位）、成本（以元為單位）做出估算。這種估算大多是利用以前的花費做為參考而做出的。如果新項目與以前的一個項目在大小上和功能上十分類似，則新項目可以參考老項目。假使項目背景完全生疏，只憑過去的經驗做出估算可能就不夠了。1103二月20233.1.3估算現(xiàn)在已有了許多用于軟件開發(fā)的估算技術。其共同特點是：

事先建立軟件工作范圍以軟件度量（以往的度量）為基礎作出估算項目被分解為可單獨進行估算的小塊管理人員大多使用不止一種估算技術，并用一種估算技術做為另一種估算技術的交叉檢查。1203二月20233.1.4風險分析風險的概念：可能發(fā)生的危險。包括兩個要素：

風險=損失*可能性軟件項目風險是由項目的不確定性造成的。比如：在構建一個軟件時，總是存在某些不確定性。

用戶要求是否能確切地被理解？在項目最后結束之前要求實現(xiàn)的功能能否建立？是否存在目前仍未發(fā)現(xiàn)的技術難題？在項目出現(xiàn)嚴重誤期時是否會發(fā)生一些變更？等等。1303二月20233.1.4風險分析風險分析對于軟件項目管理是決定性的，然而現(xiàn)在還有許多項目不考慮風險就著手進行。所謂風險分析實際上就是一系列風險管理步驟，其中包括風險識別、風險估計、風險優(yōu)化、風險管理策略、風險解決和風險監(jiān)督。這些步驟貫穿在軟件工程過程中。1403二月20233.1.5進度安排對于進度安排，需要考慮的是：

預先對進度如何計劃？工作怎樣就位？如何識別定義好的任務？

管理人員對結束時間如何掌握？如何識別和監(jiān)控關鍵路徑？對進展如何度量？如何建立分隔任務的里程碑。1503二月20233.1.5進度安排軟件項目的進度安排與任何一個工程項目的進度安排基本相同。首先識別一組項目任務，再建立任務之間的相互關聯(lián)；然后估算各個任務的工作量，分配人力和其它資源，制定進度時序1603二月20233.1.6追蹤和控制由項目管理人員負責追蹤在進度安排中標明的每一個任務。如果任務實際完成日期滯后于進度安排，則管理人員必須確定在項目的中間里程碑上進度誤期所造成的影響。還可對資源重新定向對任務重新安排（做為最壞的結果）可以修改交付日期以調整已經暴露的問題。用這種方式可以較好地控制軟件的開發(fā)。1703二月2023提綱3.1項目管理過程3.2風險管理3.3軟件質量和效率度量3.4軟件項目估算3.5軟件項目進度安排3.6項目組織結構設計3.7項目過程監(jiān)控1803二月20233.2風險管理進度過分緊迫；預算過分緊張；性能過分的超群，軟件可靠性要求過高；人員缺乏經驗，組織結構不適宜；期望過高而不現(xiàn)實；沒有明確或理解合同的條款；軟件規(guī)模估計不恰當；管理部門缺乏經驗；風險分析和管理不恰當；缺乏政策性支持；不熟悉技術或過程；不熟悉必要的硬件；需求不一致（或定義不充分）；需求不斷變動；軟件開發(fā)計劃不恰當；軟件開發(fā)過程模型不適用；缺乏軟件工程技術和方法；缺乏自動化工具的支持；常見的軟件風險類別：進度、經費、性能、組織、管理、人事、過程、方法、工具等。如下例證：1903二月20233.2風險管理對軟件項目的管理部門來說，在做出與規(guī)定費用、按規(guī)定時間交付規(guī)定產品、或達到規(guī)定性能水平的決斷時，風險是永遠存在的。軟件項目管理部門因風險而導致工作失敗有三種方式：產品達不到規(guī)定的功能及性能水平、實際費用過高、交付過遲等。就一個項目而言，其面臨的風險可分為五個方面：技術（與功能和性能有關）、保障性（與性能有關）、計劃（與信息環(huán)境有關）、費用和進度（與人員有關）。2003二月20233.2風險管理技術風險：可以定義為發(fā)展某項新設計所包含的風險，發(fā)展這項設計可能因為受到某些新的約束條件的作用而使性能水平原封未動，甚至反而有所下降。許多技術風險往往是由于對新系統(tǒng)和新設備提出前所未有的性能要求造成的。計劃風險：是包括獲取和使用一些可能不受軟件項目控制但又可能影響軟件項目方向的可用資源和活動。計劃風險一般不會與改善技術水平有直接關系。計劃風險可按一些因素的性質和來源分類，這些因素有可能中斷軟件項目實施計劃。造成軟件中斷的因素主要以下幾種：（1）與軟件項目直接有關的高層權力機構決策造成的中斷；（2）一些影響軟件項目的事件或行動造成的中斷；（3）主要由于一些不能預見的與生產有關的問題造成的中斷；（4）因能力不足造成的中斷。2103二月20233.2風險管理保障性風險：是與系統(tǒng)的部署和維護有關的風險，這些系統(tǒng)指目前正在研制或正在部署的系統(tǒng)。保障性風險包含有技術和計劃兩個方面風險的特征。費用和進度風險：一些性能和設計技術問題有時要靠增加費用和延長進度來解決，這往往會使問題變得復雜化。費用和進度增長指預計軟件項目費用和進度與實際費用和時間之間的差異。因此，費用和進度增長會造成兩個主要的費用/進度風險區(qū)：預計時定下不合理的低費用/進度目標所造成的風險；要想滿足合理的費用/進度目標，軟件項目就必須給定一個謹慎的風險。2203二月20233.2.1風險估計是否所有項目都要進行風險分析。

No,風險分析成本較高，只有當軟件的成本、性能、作用、與其他系統(tǒng)間的關系對于重要的系統(tǒng)有比較大的影響時，即軟件的風險對整個系統(tǒng)的成敗有關鍵影響時，才有必要進行風險分析和管理。風險估計的步驟1.明確項目的目標、策略、可以使用的方法和資源；2.保證項目的目標和結果是可度量的，并標明使用的資源；3.制定項目成功的標準集合；（見下頁）4.根據(jù)估計的結果確定是否進行風險分析。2303二月20233.2.1風險估計度量項目成功的標準：

1.最大限度的收益；（1-5對開發(fā)方）

2.最小的費用；

3.最小的風險損失；

4.最大限度的市場；

3.最小的周期性波動；

6.形成有益的形象；

7.最佳的服務質量；（對用戶方）

8.最高的增長率；

9.員工的滿意度最高；

10.公司的聲望最高。2403二月20233.2.2風險分析步驟一：風險識別（已知-未知）根據(jù)已知的風險事件，標識潛在風險項：收集信息，標明相關的風險。觀察風險的征兆，理解其原因。收集信息：主要依靠過去的經驗和一些著名的案例，考慮類似的因素并進行常識性的判斷。（如需求變動的風險）判斷收集到的信息是否有用。信息分類：如：有風險（經常發(fā)生的情況）、可預見的風險（較高概率發(fā)生）、不可預見的風險（事前很難預料），原因可分為：缺乏信息、管理和時間等。2503二月2023風險識別–

風險檢查表舉例需求階段：可能的風險事件包括：項目目標不清；項目范圍不明確；用戶參與和溝通少；對業(yè)務了解不夠，缺少領域知識；對需求了解不夠；沒有進行可行性研究；2603二月2023風險識別–

風險檢查表舉例設計階段：可能的風險事件包括：項目隊伍缺乏經驗，比如缺乏有經驗的系統(tǒng)分析員；沒有變更控制計劃；倉促計劃，可能帶來進度風險；漏項；2703二月2023風險識別–

風險檢查表舉例開發(fā)階段：可能的風險事件包括：開發(fā)環(huán)境未準備好；設計錯誤帶來的實施困難；程序員開發(fā)能力差；項目范圍改變；項目進度改變；人員變動；開發(fā)團隊內部溝通不暢；沒有切實可行的測試計劃；測試人員經驗不足；2803二月20233.2.2風險分析步驟二：單個風險分析 估計每個風險的大小及其出現(xiàn)的可能性：度量風險的后果和嚴重程度。選擇一種度量尺度：命名尺度、序次尺度、坐標尺度、比例尺度等；將待估計的風險信息（敘述性、定性、定量三種類型）與度量尺度相對應，確定風險等級；消除風險估計中的主觀判斷的偏差。（缺乏可以用來進行判斷風險的信息，只能憑自己的觀念和偏好進行主觀理解，與客觀情況必然存在著偏差。）2903二月20233.2.2風險分析步驟三：多個風險分析：要考慮風險間的相互作用。（第二步考慮的是單個風險的影響）考慮各種風險的綜合影響后，對已識別風險發(fā)生的可能性及其后果給出最終的量值；標明風險優(yōu)先程度，以便予以適當安排；考慮其它可替代的方案，尋求可以避免風險的基本方法。3003二月20233.2.3風險評估第一步：確定風險評估標準，確定風險的后果，判定該風險是否可以忍受；第二步：確定風險最終的級別（風險特征的三個方面：發(fā)生頻率、損害的嚴重性、發(fā)生的時刻可知性）；第三步：把系統(tǒng)風險和“對照風險”相比較，確定系統(tǒng)風險是否可以接受。（<<可接受；>>不可能接受；≈不適合接受）3103二月20233.2.3風險評估什么是“對照風險”呢？對照風險是一組單個風險的集合，也可是對項目造成最大損害的一個或多個風險。對照風險考慮了風險間可能發(fā)生的耦合或復合情況。對照風險說明了在把系統(tǒng)作為整體條件下，風險會造成系統(tǒng)失敗或成功的概率。3203二月20233.2.4風險管理任務風險管理的任務：制定風險計劃：

風險管理計劃—RMP和風險排除計劃—RA（aversion）P。（確定風險可接受目標；調整新的“對照風險”；尋求可替代的解決方案。）進行風險控制：

執(zhí)行風險計劃中體現(xiàn)風險排除策略的控制機制。（確定風險排除策略：后果、時間和頻率；確定風險排除戰(zhàn)術：建立在軟件工程過程基礎上；建立風險管理計劃：有關工作編入文檔｛風險狀態(tài)估計RES說明項目的總體狀況，風險管理計劃RMP說明如何在一個項目中施行風險分析和管理程序，風險排除計劃RAP是排除風險的詳細計劃｝。）對風險進行監(jiān)管：監(jiān)管軟件工程過程和產品，確定風險排除策略是否達到預期目標，是否有可能進一步改進風險排除計劃，為控制新的風險提供一些必要的決策信息等。3303二月2023提綱3.1項目管理過程3.2風險管理3.3軟件質量和效率度量3.4軟件項目估算3.5軟件項目進度安排3.6項目組織結構設計3.7項目過程監(jiān)控3403二月20233.3軟件質量和效率度量度量是任何工程項目最基礎的工作，軟件工程也不例外。LordKelvin：如果誰能夠度量他所說的事物并能用數(shù)字來表示它時，則說明他了解了它；但當他不能度量它，也不能用數(shù)字表示出來時，則說明他對那種事物的知識還比較貧乏、不足；這也可能是了解的開始，但在他的思想中很難達到科學的境地。軟件度量的范圍涉及很廣，在軟件項目管理范圍內，應主要關心生產率與質量的度量，即根據(jù)投入的工作量，對軟件開發(fā)活動和開發(fā)成果的質量作出度量。3503二月20233.3.1為什么要進行度量表明軟件產品的質量；弄清軟件開發(fā)人員的生產率；定量管理給出使用了新的軟件工程方法和工具所得到的（在生產率和質量兩方面）的效益；建立項目估算的“基線”；過程改進幫助調整對新的工具和附加培訓的要求。3603二月20233.3.2軟件度量方式軟件工程過程的直接度量包括所投入的成本和工作量。軟件產品的直接度量包括產生的代碼行數(shù)（LOC）、執(zhí)行速度、存儲量大小、在某種時間周期中所報告的差錯數(shù)。軟件產品的間接度量包括功能性、復雜性、效率、可靠性、可維護性和許多其它的質量特性。3703二月20233.3.2軟件度量方式集中在軟件工程過程的輸出。軟件滿足用戶要求的程度。集中在軟件的性能指標而不是軟件開發(fā)全過程上。收集與直接度量有關的軟件工程輸出信息和質量信息。提供直接度量的尺度。收集有關人們開發(fā)計算機軟件所用方式的信息和人們理解有關工具和方法的效率的信息。3803二月20233.3.3面向規(guī)模的度量面向規(guī)模的度量是對軟件和軟件開發(fā)過程的直接度量?？梢越⒁粋€面向規(guī)模的數(shù)據(jù)表格來記錄項目的某些信息。該表格應列出在過去幾年完成的每一個軟件開發(fā)項目和關于這些項目的相應面向規(guī)模的數(shù)據(jù)。3903二月20233.3.3面向規(guī)模的度量工作量和成本是針對軟件開發(fā)全過程的，而不是僅針對編碼。4003二月20233.3.3面向規(guī)模的度量對于每一個項目，可以根據(jù)表格中列出的基本數(shù)據(jù)計算簡單的面向規(guī)模的生產率和質量的度量。 生產率＝KLOC／PM（人月） 質量＝錯誤數(shù)／KLOC

成本＝元／LOC

文檔＝文檔頁數(shù)／KLOC4103二月20233.3.3面向規(guī)模的度量大多數(shù)爭議是是否使用代碼行數(shù)（LOC）做為度量的依據(jù)。支持者認為LOC是所有軟件開發(fā)項目的必然產物，它能夠很容易地被計算；現(xiàn)在許多既存的軟件估算模型都是使用LOC或者KLOC做為關鍵輸入的；而且大量以LOC為根據(jù)的文獻和數(shù)據(jù)已經存在。反對者們認為LOC度量與程序設計語言有關，它們不適用于設計很好且較短的程序，也不適合于非過程型語言。若在估算中使用，很難達到要求的詳細程度（計劃者必須在分析和設計遠未完成之前就要估算出需要生產的LOC）。4203二月20233.3.4面向功能的度量面向功能的軟件度量是對軟件和軟件開發(fā)過程的間接度量。面向功能度量主要考慮程序的“功能性”和“實用性”，而不是對LOC計數(shù)。該度量是一種叫做功能點方法的生產率度量法，利用軟件信息域中的一些計數(shù)和軟件復雜性估計的經驗關系式而導出功能點FP。4303二月20233.3.4面向功能的度量面向不同應用的輸入數(shù)面向不同應用的輸出(報告、屏幕信息、錯誤信息)數(shù)不同即時查詢的計數(shù)邏輯主文件(邏輯上的一組數(shù)據(jù)，可以是一個數(shù)據(jù)庫的一部分，也可以是一個單獨的文件)數(shù)。與系統(tǒng)中其他設備通過外部接口讀寫信息的次數(shù)使用者自行擬定一些準則來確定一個系數(shù)，帶有主觀性。4403二月20233.3.4面向功能的度量計算功能點，使用如下的關系式：

FP＝總計數(shù)×(0.65＋0.01×SUM(Fi))Fi（i＝1..14）是復雜性校正值，它們應通過逐一回答下一頁的提問來確定。Fi的取值0..5：

0

沒有影響

1

偶然的

2

適中的 3

普通的

4

重要的 5

極重要的SUM（Fi）是求和函數(shù)。4503二月20233.3.4面向功能的度量1.

系統(tǒng)是否需要可靠的備份和恢復？2.

是否需要數(shù)據(jù)通信？3.

是否有分布處理的功能？4.

是否性能成為關鍵？3.

系統(tǒng)是否運行在現(xiàn)有的高度實用化的操作環(huán)境中？6.

系統(tǒng)是否需要聯(lián)機數(shù)據(jù)項？7.

聯(lián)機數(shù)據(jù)項是否需要建立多重窗口顯示和操作，以處理輸入處理。8.

主文件是否聯(lián)機更新？9.

輸入、輸出、文件、查詢是否復雜？10.

內部處理過程是否復雜？11.

程序代碼是否可復用？12.

設計中是否包括了轉移和安裝？13.

系統(tǒng)是否設計成可以重復安裝在不同機構中14.

系統(tǒng)是否設計成易修改和易使用？4603二月20233.3.4面向功能的度量一旦計算出功能點，就可仿照LOC的方式度量軟件的生產率、質量和其它屬性：

生產率＝FP／PM（人月） 質量＝錯誤數(shù)／FP

成本＝元／FP

文檔＝文檔頁數(shù)／FP4703二月20233.3.4面向功能的度量功能點度量的支持者認為FP與程序設計語言無關，它所依據(jù)的是在項目評估早期就可能知道的數(shù)據(jù)。反對者認為這種方法需要某些“魔術手法”：在其計算中依賴的是主觀因素而不是客觀實際。

信息域的數(shù)據(jù)事后很難收集，而且FP沒有直接的物理意義，它只不過是一個數(shù)字。4803二月20233.3.5軟件質量度量質量度量貫穿于軟件工程的全過程中以及軟件交付用戶使用之后。在軟件交付之前得到的度量可作為判斷設計和測試質量好壞的依據(jù)。這一類度量包括程序復雜性、有效的模塊和總的程序規(guī)模。在軟件交付之后的度量則把注意力集中于還未發(fā)現(xiàn)的缺陷數(shù)和系統(tǒng)的可維護性方面。4903二月20程序復雜性度量程序復雜性主要指模塊內程序的復雜性。它直接關聯(lián)到軟件開發(fā)費用的多少、開發(fā)周期的長短和軟件內部潛伏錯誤的多少。（1）代碼行度量法（2）McCabe度量法（3）Halstead度量法5003二月2023代碼行度量法源代碼行數(shù)度量法基于兩個前提：程序復雜性隨著程序規(guī)模的增加不均衡地增長；控制程序規(guī)模最好是采用分而治之的辦法。統(tǒng)計一個程序模塊的源代碼行數(shù)目，以源代碼行數(shù)做為程序復雜性的度量。設每行代碼的出錯率為每100行源程序中可能有的錯誤數(shù)目。Thayer曾指出，程序出錯率的估算范圍是從0.04％～7％之間，每行代碼的出錯率與源程序行數(shù)之間不存在簡單的線性關系5103二月2023代碼行度量法Lipow指出，對于小程序，每行代碼出錯率為1.3%～1.8％；對于大程序，每行代碼的出錯率增加到2.7％～3.2％之間，這只是考慮了程序的可執(zhí)行部分，沒有包括程序中的說明部分。Lipow及其他研究者得出一個結論：對于少于100個語句的小程序，源代碼行數(shù)與出錯率是線性相關的。隨著程序的增大，出錯率以非線性方式增長。5203二月2023McCabe度量法McCabe度量法，又稱環(huán)路復雜性度量，是一種基于程序控制流的復雜性度量方法。它基于一個程序模塊的程序圖中環(huán)路的個數(shù)，因此計算它先要畫出程序圖。程序圖是退化的程序流程圖。流程圖中每個處理都退化成一個結點，流線變成連接不同結點的有向弧。5303二月20235403二月2023（2）McCabe度量法程序圖僅描述程序內部的控制流程，完全不表現(xiàn)對數(shù)據(jù)的具體操作，以及分支和循環(huán)的具體條件。計算環(huán)路復雜性的方法：根據(jù)圖論，在一個強連通的有向圖G中，環(huán)的個數(shù)由以下公式給出：

V(G)＝m－n＋p

其中，V(G)是有向圖G中環(huán)路個數(shù)，m是圖G中弧數(shù)，n是圖G中結點數(shù)，p是圖G中的強連通分量個數(shù)。在例示中，n＝11，m＝13，p＝1，則有

V(G)＝m－n＋p＝13－11＋1＝3.等于程序圖中弧所封閉的區(qū)域數(shù)。5503二月2023（2）McCabe度量法環(huán)路復雜度取決于程序控制結構的復雜度。當程序的分支數(shù)目或循環(huán)數(shù)目增加時其復雜度也增加。環(huán)路復雜度與程序中覆蓋的路徑條數(shù)有關。環(huán)路復雜度是可加的。例如，模塊A的復雜度為3，模塊B的復雜度為4，則模塊A與模塊B的復雜度是7。5603二月2023McCabe度量法McCabe建議，對于復雜度超過10的程序，應分成幾個小程序，以減少程序中的錯誤。這種度量的缺點是：對于不同種類的控制流的復雜性不能區(qū)分

簡單IF語句與循環(huán)語句的復雜性同等看待

嵌套IF語句與簡單CASE語句的復雜性是一樣的

模塊間接口當成一個簡單分支一樣處理一個具有1000行的順序程序與一行語句的復雜性相同（3）Halstead度量法采用一組基本的度量值，這些度量值可以通過編碼之后，或者提前到設計完成之后得到。預測的Halstead長度：n1表示不同的操作符個數(shù)；n2表示不同操作數(shù)的個數(shù)；則H=n1

log2n1+n2

log2n2操作符包括：算術運算符、賦值符、數(shù)組操作符、邏輯運算符、分界符，關系運算符等操作數(shù)包括變量和常量5703二月2023Halstead度量法實際的Halstead長度N1為程序中實際的操作符總個數(shù)；N2為程序中實際的操作數(shù)總個數(shù)；則H=N1+N2程序的詞匯表詞匯表為不同的操作符種類數(shù)和不同的操作數(shù)種類數(shù)的總和，用n表示；則n=n1+n25803二月2023（3）Halstead度量法5903二月2023SUBROUTINESORT（X，N）

DIMENSIONX（N）

IF（N.LT.2）RETURN

DO20I=2,N

DO10J=1,I

IF（X（I）.GE.X（J））GOTO10

SAVE=X（I）

X（I）=X（J）

X（J）=SAVE

10CONTINUE

20CONTINUE

RETURN

END

運算符

計數(shù)

運算對象

計數(shù)

可執(zhí)行語句結束7X6

數(shù)組下標6I5

＝

5J4IF（

）2N2DO222

，2SAVE2

程序結束111.LT.1

n2＝7N2＝22.GE.1

GOTO101

n1＝10N1＝28

Halstead度量法預測的詞匯量H=n1

log2n1+n2

log2n2=10log210+7log27=52.87實際的詞匯量N=N1+N2=28+22=50程序的詞匯表n=n1+n2=10+7=176003二月2023Halstead度量法程序量V，表明程序在“詞匯上的復雜性”V=(N1+N2)log2(n1+n2)V*

表示只有兩個操作符的情況程序量比率：L=V*/V

針對前一頁的例子：V=(28+22)log2(10+7)=2046103二月2023Halstead度量法程序員工作量EE=V/L或E=H×log2(n1+n2)×[(n1×n2)/(2×n2)]程序的潛在錯誤BB=(N1+N2)log2(n1+n2)/3000B=V/3000一個程序對75個數(shù)據(jù)庫表共訪問1300次，對150個操作符共使用了1200次，那么預測該程序的錯誤數(shù)：B=(1300+1200)log2(75+150)∕3000=6.56203二月20236303二月20233.3.6使用軟件度量LOC/PM(FP/PM)不能用來評價單個系統(tǒng)的性能，因為有許多因素都會影響生產率。人的因素：軟件開發(fā)組織的規(guī)模和專長；（90%）問題因素：問題的復雜性和對設計限制，以及需求的變更次數(shù)；（40%）過程因素：使用的分析與設計技術、語言和CASE工具的有效性，及評審技術；（50%）產品因素：計算機系統(tǒng)的可靠性和性能需求；（140%）資源因素：CASE工具、硬件和軟件資源的有效性。（40%）6403二月20233.3.6使用軟件度量功能點和LOC已被公認是比較精確的軟件開發(fā)工作量和成本預測工具。使用軟件度量建立項目基線，管理部門能夠建立改進軟件工程過程的目標，從而評價項目的生產率和質量。建立基線：根據(jù)歷史經驗，在軟件工程過程的銜接處劃出一條基線，在此基線上附有一些用于度量的經驗目標信息，作為工程過程評估的依據(jù)，判斷工程過程的完成是否達到預想的要求。質量度量數(shù)據(jù)一旦收集到，軟件開發(fā)組織就可以根據(jù)它們來調整其軟件工程項目，以消除那些對軟件開發(fā)有重大影響的差錯產生的根源。6503二月20233.3.6使用軟件度量為了幫助計劃、成本和工作量估算，基線的數(shù)據(jù)應當具有下列屬性：數(shù)據(jù)必須合理、精確，應避免單純根據(jù)以往項目進行“盲目估算”；應從盡可能多的項目中收集數(shù)據(jù)；數(shù)據(jù)必須一致；基線數(shù)據(jù)的應用必須與要做估算的工作類似。6603二月2023提綱3.1項目管理過程3.2風險管理3.3軟件質量和效率度量3.4軟件項目估算3.5軟件項目進度安排3.6項目組織結構設計3.7項目過程監(jiān)控6703二月20233.4軟件項目估算軟件項目管理過程開始于項目策劃。項目策劃的首要活動就是估算(Estimation)。估算所需的資源、成本及進度。估算資源、成本和進度時需要經驗、有用的歷史信息、足夠的定量數(shù)據(jù)。---確定基線估算本身帶有風險。估算往往存在某些不確定性?，F(xiàn)在已使用的實用技術是成本和工作量估算。6803二月20233.4.1估算的影響因素項目的復雜性較大程度地影響到估算的不確定性。項目規(guī)模越大，劃分越困難，模塊間的連接越復雜，估算的風險越高。估算與風險6903二月20233.4.1估算的影響因素項目的規(guī)模越大，項目劃分越困難，項目元素間的連接復雜，估算風險越高；項目的結構化程度越高，功能分解和信息分層越容易，項目估算能力越強；歷史信息的有效性影響估算的風險；其他風險：項目范圍不確定、用戶要求經常變更。7003二月20233.4.2軟件項目策劃項目策劃目標：提供一個能使項目管理人員對資源、成本和進度做出合理估算的框架。項目策劃的步驟：（1）項目策劃的首要任務是確定軟件范圍：包括功能、性能、限制、接口和可靠性。

-成本和進度的估算都與功能有關；(采用功能分析的原因) -性能包括處理和響應時間的需求；

-限制表示外部硬件、可用存儲或其他現(xiàn)有系統(tǒng)對軟件的限制。

功能、性能和限制要一起估算。7103二月20233.4.2軟件項目策劃

-接口：軟件和硬件間的接口、軟件間的接口、人機接口、軟件運行前后的一系列過程；必須明確通過接口的信息轉換。

-可靠性：很難在策劃階段使用量化的可靠性，只能通過軟件的一般性質規(guī)定一些具體要求來保障可靠性。通過這些規(guī)定的具體要求來調整工作量和成本的估算公式。7203二月20233.4.2軟件項目策劃（2）項目策劃的第二個任務是對完成該項目所需的資源進行估算。7303二月20237403二月20233.4.2軟件項目策劃（3）第三步，軟件成本和工作量估算-很難精確，因為變化因素太多：人、技術、環(huán)境、政治等都會影響最終成本和工作量。

-得到可靠的成本和工作量的方法有：

>估算推到項目后期進行（必須事前度量）

>使用相對簡單的分解技術生成項目的成本和工作量的估算結果。

>為軟件成本和工作量估算開發(fā)或配備一個經驗模型；

>獲取一個或更多的自動估算工具。7503二月20233.4.3利用分解技術進行估算當一個待解決的問題過于復雜時，我們可以把它進一步分解一組較小的問題，直到分解后的子問題變得容易管理為止。然后，再定于它們的特性。可以從兩個不同的角度進行分解：問題分解；過程分解；首先要解決的軟件規(guī)模問題。7603二月20233.4.3利用分解技術進行估算基于問題的估算。應用LOC/FP度量。作為估算變量；作為基線度量；功能分解，估算LOC/FP，導出每個功能的成本和工作量。為每個功能計數(shù)值分別計算“樂觀”Sopt、‘可能’Sm、‘悲觀’Spess值，

S=（Sopt+4Sm+Spess)/67703二月20233.4.3利用分解技術進行估算來自于歷史基線數(shù)據(jù)基于LOC/FP進行估算7803二月20233.4.3利用分解技術進行估算基于過程的估算。根據(jù)所采用的軟件過程將問題分解為一組較小的任務，估算每個任務的工作量。抽取軟件功能，給出實現(xiàn)功能的一系列軟件框架活動。估算各個軟件活動所需的工作量，估算成本時應考慮勞動力的不同成本。7903二月20233.4.3利用分解技術進行估算基于直接工作量進行估算8003二月20233.4.3利用分解技術進行估算對于一個大型的軟件項目，由于項目的復雜性，開發(fā)成本的估算不是一件簡單的事，要進行一系列的估算處理。主要靠分解和類推?；竟浪惴椒ǚ譃槿?。自頂向下的估算方法

自底向上的估計法差別估計法8103二月20233.4.3利用分解技術進行估算自頂向下的估算方法這種方法的主要思想是從項目的整體出發(fā)，進行類推。估算人員根據(jù)以前已完成項目所消耗的總成本（或總工作量），推算將要開發(fā)的軟件的總成本（或總工作量），然后按比例將它分配到各開發(fā)任務單元中去，再來檢驗它是否能滿足要求。這種方法的優(yōu)點是估算工作量小，速度快。缺點是對項目中的特殊困難估計不足，估算出來的成本盲目性大，有時會遺漏被開發(fā)軟件的某些部分。8203二月20238303二月20233.4.3利用分解技術進行估算自底向上的估算方法這種方法的主要思想是把待開發(fā)的軟件細分，直到每一個子任務都已經明確所需要的開發(fā)工作量，然后把它們加起來，得到軟件開發(fā)的總工作量。它的優(yōu)點是估算各個部分的準確性高。缺點是缺少各項子任務之間相互聯(lián)系所需要的工作量，還缺少許多與軟件開發(fā)有關的系統(tǒng)級（配置管理、質量管理、項目管理）工作量.8403二月20233.4.3利用分解技術進行估算差別估計法這種方法綜合了上述兩種方法的優(yōu)點，其主要思想是把待開發(fā)的軟件項目與過去已完成的軟件項目進行類比，從其開發(fā)的各個子任務中區(qū)分出類似的部分和不同的部分。類似的部分按過去的實際量自頂向下進行估算，不同的部分則采用自底向上方法進行估算。這種的方法的優(yōu)點是可以提高估算的準確程度，缺點是不容易明確“類似”的界限。8503二月20233.4.4專家評判技術由多位專家進行成本估算單獨一位專家可能會有種種偏見。最好由多位專家進行估算，取得多個估算值。有多種方法把這些估算值合成一個估算值。一種方法是簡單地求各估算值的中值或平均值。其優(yōu)點是簡便。缺點是可能會由于受一、二個極端估算值的影響而產生嚴重的偏差。一種方法是召開小組會，使各位專家們統(tǒng)一于或至少同意某一個估算值。優(yōu)點是可以摒棄蒙昧無知的估算值，缺點是一些組員可能會受權威或政治因素的影響。8603二月20233.4.4專家評判技術標準Delphi技術

①組織者發(fā)給每位專家一份軟件系統(tǒng)規(guī)格說明書和一張記錄估算值的表格，請他們進行估算。

②專家詳細研究軟件規(guī)格說明書的內容，對該軟件提出三個規(guī)模的估算值，即：

ai（最?。﹎i（可能）bi（最大），無記名地填寫表格，在填表的過程中，專家互相不進行討論但可以向組織者提問。

③組織者對專家們填在表格中的答復進行整理：

a.計算各位專家估算的期望值Ei;

b.對專家的估算結果分類摘要。

專家對此估算值另做一次估算。

④在綜合專家估算結果的基礎上，組織專家再次無記名地填寫表格。比較兩次估算的結果。若差異很大，則要通過查詢找出差異的原因。 ⑤上述過程可重復多次。最終可獲得一個得到多數(shù)專家共識的軟件規(guī)模（源代碼行數(shù)）。在此過程中不得進行小組討論。8703二月20233.4.5軟件估算的經驗模型軟件估算模型通常采用經驗公式來預測軟件項目計劃所需要的成本、工作量和進度數(shù)據(jù)。工作量是LOC/FP的函數(shù)用以支持大多數(shù)模型的經驗數(shù)據(jù)都是從有限的一些項目樣本中得到的。還沒有一種估算模型能夠適用于所有的軟件類型和開發(fā)環(huán)境。應該對估算模型進行調整，以反映當前項目的情況。方法：將數(shù)據(jù)代入模型中，將實際結果與預期結果進行比較，并進行調整，循環(huán)往復。8803二月20233.4.5軟件估算的經驗模型估算模型的結構。典型的估算模型是通過回歸分析得出，形式如下：E=A+B*（ev）C其中：A，B，C是常量，E是工作量，ev是估算變量（LOC/FP）可根據(jù)項目特性進行調整，如：復雜性、經驗、環(huán)境。分析三種模型IBM模型Putnam模型COCOMO模型8903二月20IBM模型E＝3.2×L0.91D＝4.1×L0.36

＝14.47×E0.35S＝0.54×E0.6DOC＝49×L1.01L是源機器代碼行數(shù)（KLOC），E

是工作量（PM），D是項目持續(xù)時間（月），S

是人員需要量（人），DOC是文檔數(shù)量（頁）。9003二月20IBM模型IBM模型是靜態(tài)單變量模型。在此模型中，一般指一條機器指令為一行源代碼。一個軟件的源代碼行數(shù)不包括程序注釋、作業(yè)命令、調試程序在內。對于非機器指令編寫的源程序，例如匯編語言或高級語言程序，應轉換成機器指令源代碼行數(shù)來考慮。定義:轉換系數(shù)＝機器指令條數(shù)／非機器語言執(zhí)行步數(shù)。如：Fortran的轉換系數(shù)為4~6。9103二月20Putnam模型Putnam模型是一種動態(tài)多變量模型。適用于大型項目，但也可以應用在一些較小的軟件項目中。它是假定在軟件開發(fā)的整個生存期中工作量有特定的分布。大型軟件項目的開發(fā)工作量分布可以用Rayleigh-Norden曲線表示。這個曲線把已交付的源代碼行數(shù)與工作量和開發(fā)時間聯(lián)系起來。9203二月20Putnam模型9303二月2023用Rayleigh-Norden曲線可以導出一個“軟件方程”L是源代碼行數(shù)（LOC），Ck是技術狀態(tài)常數(shù)，因開發(fā)環(huán)境而異。K是軟件開發(fā)與維護在內的整個生存期所花費的工作量（人年），td

是開發(fā)持續(xù)時間（年）9403二月20Putnam模型9503二月20COCOMO模型COnstructiveCOstModel(Boehm)結構型成本估算模型是一種精確、易于使用的成本估算方法。應用開發(fā)模式和成本驅動因子來反映項目的特性。在該模型中使用的基本量有以下幾個：1.DSI(DeliverySourceInstruction):源程序行數(shù)；1KDSI=1024DSI2.MM:開發(fā)工作量；（人月）1MM=19人日=152人時=1/12人年3.TDEV:開發(fā)進度；（月）由工作量決定9603二月20COCOMO模型基本COCOMO模型：是一個靜態(tài)單變量模型，它用源代碼行數(shù)（LOC）為自變量的（經驗）函數(shù)來計算軟件開發(fā)工作量。中間COCOMO模型：在用LOC為自變量的函數(shù)計算軟件開發(fā)工作量（此時稱為名義工作量）的基礎上，再用涉及產品、硬件、人員、項目等方面屬性的影響因素來調整工作量的估算。詳細COCOMO模型：包括中間COCOMO模型的所有特性，但用上述各種影響因素調整工作量估算時，還要考慮對軟件工程過程中每一步驟（分析、設計等）的影響。9703二月20.1基本COCOMO模型9803二月20.2中間COCOMO模型進一步考慮15種影響軟件工作量的因素，通過定下乘法因子，修正COCOMO工作量公式和進度公式，可以更合理地估算軟件（各階段）的工作量和進度。中間COCOMO模型的名義工作量與進度公式9903二月20.2中間COCOMO模型10003二月20.3詳細COCOMO模型詳細COCOMO模型的名義工作量公式和進度公式與中間COCOMO模型相同。工作量因素分級表分層、分階段給出。針對每一個影響因素，按模塊層、子系統(tǒng)層、系統(tǒng)層，有三張工作量因素分級表，供不同層次的估算使用。每一張表中工作量因素又按開發(fā)各個不同階段給出。使用這些表格，可以比中間COCOMO模型更方便、更準確地估算軟件開發(fā)工作量。10103二月2023軟件可靠性工作量因素分級表(子系統(tǒng)層)10203二月2023提綱3.1項目管理過程3.2風險管理3.3軟件質量和效率度量3.4軟件項目估算3.5軟件項目進度安排3.6項目組織結構設計3.7項目過程監(jiān)控10303二月20233.5軟件項目進度安排前置條件：已經選擇合適的軟件過程模型，確定了必須完成的軟件工程任務（問題分解），估算了工作量和資源（人員數(shù)），明確了項目的結束期限，甚至已進行了風險分析。項目進度安排和跟蹤創(chuàng)建任務網絡，保證按時完成工作；為每個任務確定責任，確保履行責任；10403二月20233.5軟件項目進度安排導致項目進度延誤的原因是：“某天某時”。項目管理者職責：定義所有的項目任務；建立任務網絡來描述任務之間的依賴關系；明確網絡中的關鍵路徑；跟蹤關鍵任務的進展，確保能在“某天某時”發(fā)現(xiàn)進度延誤情況?？傊盒枰敿毜捻椖窟M度表，監(jiān)督進度、控制項目。軟件項目進度安排—是活動。將工作量——〉任務---〉進度表分配10503二月20233.5軟件項目進度安排項目進度安排的指導原則：劃分/分解：將項目劃分成可管的活動、任務；相互依賴性：任務之間的依賴關系（順序、并發(fā)）；時間分配：任務量（人月或人日），起止時間。工作量確認：確保所分配工作量<可分配工作量。確定責任：安排進度計劃的每個任務都應指定人。明確結果：明確每個任務的輸出結果。確定里程碑：每個任務/任務組都應與一個項目里程碑相關聯(lián)。10603二月20233.5軟件項目進度安排軟件開發(fā)項目的進度安排有兩種方式：

（1）系統(tǒng)最終交付日期已經確定，軟件開發(fā)