【正文】 LET為 23，因此事件 10的 LET=232=21 21 類似地，事件 9的LET=211=20 20 事件 8有兩個離開它的作業(yè) 89和 810，因此LET=min{200,216}=15 15 按此方法，不難沿著 PERT圖從右到左的逆序算出每個事件的 LET 18 12 11 6 6 2 關(guān)鍵路徑 （ CPM， Critical Path Method） ： 從起點到終點，可以有許多條路徑，我們把 耗時最長的路徑稱作關(guān)鍵路徑。關(guān)鍵路徑耗時等于整個工程的耗時，因此，要想縮短工程時間，就必須找出關(guān)鍵路徑，并研究如何減少關(guān)鍵路徑的耗時。 6 1 0 0 2 6 10 11 5 3 4 8 7 9 2 4 2 4 3 6 3 1 2 1 2 0 0 0 0 2 6 6 8 12 12 15 15 21 23 23 21 20 15 18 12 11 6 6 2 關(guān)鍵路徑上事件的 EET＝ LET 關(guān)鍵路徑的事件必須準時發(fā)生，作業(yè)的實際持續(xù)時間不能超過估計持續(xù)時間。否則工程不能按時完成。 6 1 0 0 2 6 10 11 5 3 4 8 7 9 2 4 2 4 3 6 3 1 2 1 2 0 0 0 0 2 6 6 8 12 12 15 15 21 23 23 21 20 15 18 12 11 6 6 2 機動時間： 不在關(guān)鍵路徑上的作業(yè)有一定程度的機動余地 ——實際開始時間可以比預定時間晚一些，或者實際持續(xù)時間可以比預定的持續(xù)時間長一些，而不影響整個工程的完成時間。一個作業(yè)可以有的全部 機動時間＝ (LET)結(jié)束 － (EET)開始 －持續(xù)時間 (1) (3) (11) (4) (3) (6) (6) (5) (5) 活動網(wǎng)絡(luò)圖 ? 在制定進度計劃時仔細考慮和利用 PERT圖中的機動時間，往往能夠安排出既節(jié)省資源又不影響最終竣工時間的進度表。 ? 從上圖可見，清理前三面墻窗戶的作業(yè)都有相當多的機動時間，即這些作業(yè)可以晚些開始或者持續(xù)時間長一些 (少用一些資源 )； ? 此外，刮第 第 4面墻上舊漆和給第 1面墻刷新漆的作業(yè)也都有機動時間，且這些機動時間之和大于清理前三面墻窗戶需要用的工作時間。 ? 因此，有可能僅用 10個工人在同樣時間內(nèi) (23小時 )完成這項工程。 2 4 8 10 12 14 18 20 16 6 22 刮舊漆 刷新漆 清理 時間 (小時 ) 工序 活動網(wǎng)絡(luò)圖 這個方案不僅比前面的方案節(jié)省人力，而且改正了前圖的一個錯誤：因為給第 3面墻刷漆的作業(yè) 46不僅必須在給第 1面墻刷完漆之后 (24作業(yè)結(jié)束 )，而且還必須在把第 3面墻刮凈之后(23作業(yè)和 34虛作業(yè)結(jié)束 )才能開始。全部工程需要 23小時，而不是 22小時。 活動網(wǎng)絡(luò)圖 1 1 0 0 2 2 2 6 12 12 10 21 21 11 23 23 5 8 11 3 6 6 4 6 6 8 15 15 7 12 18 9 15 20 2 4 2 4 3 6 3 6 2 1 2 0 0 0 0 (0) (0) (1) (0) (3) (4) (0) (11) (0) (6) (5) (3) (5) (0) (0) 舊木板房刷漆工程 完整 PERT圖 進度管理實踐 —MS Project T11(M8) 10 T12 T9(M6) 7 T11 T5,T7(M7) 15 T10 T3,T6(M4) 15 T9 T4(M5) 25 T8 T1(M1) 20 T7 T1,T2(M3) 5 T6 T2,T4(M2) 10 T5 10 T4 T1(M1) 15 T3 15 T2 8 T1 依賴關(guān)系 持續(xù)時間 任務(wù) MS Project—活 動網(wǎng)絡(luò)圖 4/7/05 8天 14/7/05 15天 4/8/05 15天 25/08/05 7天 5/9/05 10天 19/9/05 15天 11/8/05 25天 10天 20天 5天 25/7/05 15天 25/7/05 18/7/05 開始 10天 完成 T8 M5 T4 T2 T3 M1 M3 T7 T6 M2 T5 M4 M7 T10 T12 M8 T11 M6 T9 T1 MS Project甘特圖 4/7 1 1/7 1 8/7 2 5/7 1/8 8/8 1 5/8 2 2/8 2 9/8 5/9 1 2/9 1 9/9 T4 T1 T2 M1 T7 T3 M5 T8 M3 M2 T6 T5 M4 T9 M7 T10 M6 T11 M8 T12 開始 完成 人員分配 4/7 1 1/7 1 8/7 2 5/7 1/8 8/8 1 5/8 2 2/8 2 9/8 5/9 1 2/9 1 9/9 T4 T8 T11 T12 T1 T3 T9 T2 T6 T10 T7 T5 Fred Jane Anne Mary Jim 質(zhì)量管理 ? 質(zhì)量是產(chǎn)品的生命線，不論任何產(chǎn)品，質(zhì)量都是極端重要的。 ? 軟件產(chǎn)品開發(fā)周期長，需耗費巨大的人力、物力，更必須特別注意保證產(chǎn)品質(zhì)量。 軟件質(zhì)量的定義 ? 軟件質(zhì)量就是 “ 軟件與明確的和隱含定義的需求相一致的程度 ” ，即軟件與明確描述的功能和性能需求、文檔中明確描述的開發(fā)標準以及任何專業(yè)開發(fā)的軟件產(chǎn)品都應(yīng)該具有的隱含特征相一致的程度。 軟件質(zhì)量的定義 ? 上述定義強調(diào)了以下三個重要的方面： – 軟件需求是進行 質(zhì)量 度量的基礎(chǔ)，不符合需求就是質(zhì)量不高。 – 規(guī)范化的標準定義了一些開發(fā)準則以指導軟件開發(fā)，如果不遵照這些準則，則極有可能導致質(zhì)量不高。 – 往往會有一些隱含的需求沒有明確地提出來，如軟件的可維護性等，忽略了這些隱含需求，軟件的質(zhì)量也難以保證。 軟件質(zhì)量是一個多因素的復雜混合，這些因素隨著不同的應(yīng)用和用戶而變化。 軟件質(zhì)量模型 ? 軟件質(zhì)量與軟件的內(nèi)部特性及其組合有關(guān)。要度量軟件質(zhì)量，就應(yīng)根據(jù)這些內(nèi)部特性（即軟件屬性）建立起軟件度量模型，進而構(gòu)建軟件質(zhì)量度量體系。 ? 從管理角度對軟件質(zhì)量進行度量的 McCall軟件質(zhì)量模型如下： 軟件質(zhì)量模型 產(chǎn)品修改 產(chǎn)品轉(zhuǎn)移 產(chǎn)品運行 可理解性 可維護性 靈活性 可測試性 可移植性 可重用性 互運行性 輕便性 正確性、健壯性、效率、完整性、可用性、風險 ? 上述模型反映了用戶在使用軟件產(chǎn)品時的三種不同的傾向：產(chǎn)品運行、產(chǎn)品修改和產(chǎn)品轉(zhuǎn)移 。 軟件質(zhì)量的屬性 ? 正確性 系統(tǒng)滿足規(guī)格說明和用戶目標的程度，在預定環(huán)境下能正確完成預期功能的程度。 ? 健壯性 在硬件發(fā)生故障、輸入數(shù)據(jù)無效、操作錯誤等意外環(huán)境下，系統(tǒng)能做出適當響應(yīng)的程度。 ? 效率 為了完成預定功能，系統(tǒng)需要的計算資源的多少。 ? 完整性 對未經(jīng)授權(quán)的軟件使用請求或數(shù)據(jù)訪問的企圖，系統(tǒng)能夠控制（或禁止）的程度。 軟件質(zhì)量的屬性 ? 可用性 系統(tǒng)在完成預定功能時令用戶滿意的程度。 ? 風險 按預定的成本和進度開發(fā)系統(tǒng)，并且使得用戶滿意的概率。 ? 可理解性 理解和使用軟件的容易程度。 ? 可維護性 診斷和改正在運行現(xiàn)場發(fā)現(xiàn)的錯誤所需要的工作量大小。 軟件質(zhì)量的屬性 ? 適應(yīng)性 修改或改進正在運行的系統(tǒng)需要的工作量大小 ? 可測試性 軟件容易測試的程度。 ? 可移植性 把軟件從一軟硬件環(huán)境移植到另一配置環(huán)境時，需要的工作量大小。 ? 可重用性 在其他應(yīng)用中該軟件可以被使用的程度或范圍。 軟件質(zhì)量的屬性 ?互運行性 把該軟件系統(tǒng)和另一軟件系統(tǒng)結(jié)合起來所需要的工作量大小。 ?輕便性 允許軟件能夠從一臺計算機很容易地傳輸?shù)搅硪慌_需要運行的計算機上的能力。 軟件質(zhì)量管理 軟件質(zhì)量管理就是確保軟件有較少缺陷，并達到軟件系統(tǒng)既定目標。 ? 一個機構(gòu)的質(zhì)量管理者的職責是確保軟件產(chǎn)品質(zhì)量達到客戶要求。 ? 理論上，質(zhì)量管理只包含制定軟件質(zhì)量規(guī)程和軟件開發(fā)標準，以及檢查是否所有的工程人員都遵守了這些規(guī)章和標準。但實際上，質(zhì)量管理內(nèi)容遠不止這些。 ? 好的質(zhì)量管理者致力于培養(yǎng)“質(zhì)量文化”，讓每個參與產(chǎn)品開發(fā)的人都有強烈質(zhì)量意識。他們鼓勵團隊對自己的工作質(zhì)量負責，鼓勵他們探求改善質(zhì)量的途徑和方法，鼓勵團隊每一員對軟件質(zhì)量特征量化的研究。 軟件質(zhì)量管理活動 軟件質(zhì)量管理有以下三個主要活動組成： 1） 質(zhì)量保證 (Quality Assurance) 建立起機構(gòu)質(zhì)量規(guī)程和標準的整體框架，這是生產(chǎn)高質(zhì)量軟件的保證。 2） 質(zhì)量規(guī)劃 (Quality Planning) 從這個框架中選擇適當?shù)馁|(zhì)量規(guī)程和標準，進行改寫使之適應(yīng)于特定軟件項目。 3） 質(zhì)量控制 (Quality Control) 定義并設(shè)計軟件過程，確保軟件開發(fā)團隊嚴格遵守項目質(zhì)量規(guī)劃和標準。 軟件質(zhì)量管理活動 ? 質(zhì)量管理應(yīng)該與軟件項目管理相分離，這樣質(zhì)量管理就不會屈從于項目預算和進度。 ? 應(yīng)該由一個獨立的團隊專門負責質(zhì)量管理，并應(yīng)該向項目管理者的上級領(lǐng)導匯報。 ? 軟件質(zhì)量管理者不應(yīng)該參與具體的開發(fā)工作，而應(yīng)該負責整個機構(gòu)的質(zhì)量管理。 質(zhì)量管理與軟件開發(fā) D1 D2 D3 D4 D5 可交付產(chǎn)品 質(zhì)量保證 質(zhì)量規(guī)劃 質(zhì)量控制 軟件開發(fā)過程 質(zhì)量管理過程 軟件質(zhì)量保證 QA活動為達到高質(zhì)量軟件提供了一個框架。QA過程包括對軟件開發(fā) 過程標準 或軟件 產(chǎn)品標準 的定義和選擇。這些標準應(yīng)該融合在軟件開發(fā)的過程或過程中。 質(zhì)量標準 在質(zhì)量保證過程中要制定兩種類型的標準： ? 產(chǎn)品標準 定義了所有要提供的產(chǎn)品的特征 ，包括：文檔標準，如生成的需求文檔的結(jié)構(gòu)；文檔編寫標準，如定義對象類時注釋頭的標準寫法；還有編碼標準，它規(guī)定了如何使用某種程序設(shè)計語言。 ? 過程標準 這些標準定義了軟件開發(fā)必須遵循的過程，包括描述、設(shè)計、有效性驗證過程的定義，以及對在這些過程中產(chǎn)生的文檔描述。 產(chǎn)品標準與過程標準 產(chǎn)品標準 設(shè)計評審形式 需求文檔結(jié)構(gòu) 規(guī)程標題結(jié)構(gòu) Java編程規(guī)范 項目計劃格式 變更請求形式 過程標準 設(shè)計評審行為 提交文檔給 CM 版本發(fā)放過程 項目計劃批準過程 變更控制過程 測試記錄過程 ? 封裝了最成功的經(jīng)驗 ——避免重犯過去的錯誤。 ? 提供了質(zhì)量保證過程的框架 ——質(zhì)量控制的任務(wù)只要保證這些標準嚴格執(zhí)行就可以了。 ? 有助于工作的連貫性 ——由一個人著手進行的工作別人可以接著做。 標準的重要性 質(zhì)量規(guī)劃 ? 質(zhì)量規(guī)劃描述希望得到的產(chǎn)品的質(zhì)量要求及其評定辦法，并且定義最重要的質(zhì)量屬性。 ? 質(zhì)量規(guī)劃應(yīng)該定義質(zhì)量的評定過程。 ? 也應(yīng)該說明采用哪個組織的標準，如果有必要還要定義新的標準。 質(zhì)量規(guī)劃 ? 產(chǎn)品介紹 ：說明產(chǎn)品、產(chǎn)品的意向市場及對產(chǎn)品性質(zhì)的預期。 ?