進度管理

進度管理就是采用科學的方法，確定進度目標，編制進度計劃和資源供應計劃，進行進度控制，在與質量、成本目標協調的基礎上，實現工期目標。

具體來說，包括以下過程：

(1) 活動定義：確定完成項目各項可交付成果而需要開展的具體活動

(2) 活動排序：識別和記錄各項活動之間的先后關系和邏輯關系

(3) 活動資源估算：估算完成各項活動所需要的資源類型和效益

(4) 活動歷時估算：估算完成各項活動所需要的具體時間

(5) 進度計劃編制：分析活動順序、活動持續時間、資源要求和進度制約因素制訂項目進度計劃

(6) 進度控制：根據進度計劃開展項目活動，如果發現偏差，則分析原因或進行調整

進行活動資源估算的方法主要有專家判斷法、替換方案的確定、公開的估算數據、估算軟件和自下而上的估算

(1) 專家判斷法。專家判斷法通常是由項目管理專家根據以往類似項目經的驗和對本項目的判斷，經過周密思考，進行合理預測，從而估算出項目資源。

(2) 替換方案的確定。資源估算是為了給項目預算明確空間，為早期的資源籌備提供數據，如果某項活動存在替代方案，或提供的資源有替代支持可能，則需要明確聲明。

(3) 公開的估算數據。有些公司會定期地公開一些生產率或人工費率數據，其中包括很多國家和地區的勞動力交易、材料和設備信息

(4) 估算軟件。依靠軟件的強大功能，可以定義資源可用性、費率，以及不同的資源日歷。

(5) 自下而上的估算。把復雜的活動分解為更小的工作，以便于資源估算。將每項工作所需要的資源估算出來，然后匯總即是整個活動所需要的資源數量。

?進度管理模型

COCOMO模型?

COCOMO模型：常見的軟件規模估算方法。常用的代碼行分析方法作為其中一種度量估計單位，以代碼行數估算出每個程序員工作量，累加得軟件成本。模型按其詳細程度可以分為三級:

(1) 基本COCOMO模型是一個靜態單變量模型，它用一個以已估算出來的原代碼行數 (LOC) 為自變量的經驗畫數計算軟件開發工作量。

(2) 中間COCOMO模型在基本COCOMO模型的基礎上，再用涉及產品、硬件人員、項目等方面的影響因素調整工作量的估算。

(3) 詳細COCOMO模型包括中間COCOMO模型的所有特性，將軟件系統模型分為系統、子系統和模塊3個層次，更進一步考慮了軟件工程中每一步驟（如分析、設計）的影響

COCOMOⅡ模型?

COCOMOⅡ模型: COCOMO的升級，也是以軟件規模作為成本的主要固素考慮多個成本驅動因子。該方法包括三個階段性模型，即應用組裝模型、早期設計階段模型和體系結構階段模型。包含三種不同規模估算選擇: 對象點、功能點和代碼行

進度安排的常用圖形描述方法有 Gantt 圖 （甘特圖）和項目計劃評審技術（Program Evaluation& Review Technique，PERT）圖

?

關鍵路徑法

關鍵路徑：是項目的最短工期，但卻是從開始到結束時間最長的路徑。進度網絡圖中可能有多條關鍵路徑，因為活動會變化，因此關鍵路徑也在不斷變化中

關鍵活動：關鍵路徑上的活動，最早開始時間-最晚開始時間。通常，每個節點的活動會有如下幾個時間:
(1) 最早開始時間（ES），某項活動能夠開始的最早時間。

(2) 最早結束時間（EF），某項活動能夠完成的最早時間。EF=ES+工期

(3) 最遲結束時間（LF）。為了使項目按時完成，某項活動必須完成的最遲時間

(4) 最遲開始時間（LS）。為了使項目按時完成，某項活動必須開始的最遲時間。LS-LF-工期

這幾個時間通常作為每個節點的組成部分，如圖所示

順推：最早開始ES=所有前置活動最早完成EF的最大值；最早完成EF=最早開始ES+持續時間

逆推：最晚完成LF=所有后續活動最晚開始LS的最小值；最晚開始LS=最晚完成LS-持續事件
?

總浮動時間：在不延誤項目完工時間且不違反進度制約因素的前提下，活動可以從最早開始時間推遲或拖延的時間量，就是該活動的進度靈活性。正常情況下，關鍵活動的總浮動時間為零

總浮動時間=最遲開始LS-最早開始ES 或 最遲完成LF - 最早完成EF 或 關鍵路徑-非關鍵路徑時長。

自由浮動時間：是指在不延誤任何緊后活動的最早開始時間且不違反進度制約因素的前提下，活動可以從最早開始時間推遲或拖延的時間量

自由浮動時間=緊后活動最早開始時間的最小值-本活動的最早完成時間

?

質量管理

?質量是軟件產品特性的綜合，表示軟件產品滿足明確（基本需求）或隱含（期望需求）要求的能力。質量管理是指確定質量方針、目標和職責，并通過質量體系中的質量計劃、質量控制、質量保證和質量改進來使其實現的所有管理職能的全部活動;

主要包括以下過程：

(1) 質量規劃：識別項目及其產品的質量要求和標準，并書面描述項目將如何達到這些要求和標準的過程。

(2) 質量保證：一般是每隔一定時間（例如，每個階段末）進行的，主要通過系統的質量審計（軟件評審）和過程分析來保證項目的質量。

(3)質量控制：實時監控項目的具體結果，以判斷它們是否符合相關質量標準，制訂有效方案，以消除產生質量問題的原因

信息技術 軟件產品評價 質量特性及其使用指南 GB/T 16260-2002

?

?

?McCal質量模型

軟件評審

質量兩個必要條件：設計的規格說明書符合用戶標準，稱為設計質量

程序按照設計規格說明書所規定的情況正確執行，稱為程序質量

軟件容錯技術?

軟件容錯技術：容錯就是軟件遇到錯誤的處理能力，實現容錯的手段主要是元余，包括下面四種冗余技術:

結構冗余：分為靜態、動態、混合冗余三種，當錯誤發生時對錯誤進行備份處理

信息冗余：為檢錯和糾錯在數據中加上一段額外的信息，例如校驗碼原理

時間冗余：遇到錯誤時重復執行，例如回滾，重復執行還有錯，則轉入錯誤處理邏輯。

冗余附加技術：是指為實現結構、信息和時間冗余技術所需的資源和技術，包括程序、指令、數據、存放和調動它們的空間和通道等。在屏蔽硬件錯誤的容錯技術中

【例題】軟件質量保證是軟件項目控制的重要手段，（? ）是軟件質量保證的主要活動之一、
A、風險評估????????B、軟件評審????????C、需求分析 ????????D、架構設計
答案: B
解析:軟件質量保證是軟件質量管理的重要組成部分。軟件質量保證主要是從軟件產品的過程規范性角度來保證軟件的品質。其主要活動包括: 質量審計（包括軟件評審)）和過程分析

【例題】ISO/IEC軟件質量模型中，易使用性是指與使用所需的努力由一組規定或隱含的用戶對這樣使用所作的個別評價有關的一組屬性，其易使用性的子特性不包括（? ）
A、易理解性????????B、易學性????????C、易分析性????????D、易操作性
答案：C
解析：純記憶，也可以從易使用性的特點去分析，應該是軟件容易使用、理解、操作等，針對用戶層面的，不會涉及到是否易分析設計。

風險管理

風險管理就是要對項目風險進行認真的分析和科學的管理，這樣，是能夠避開不利條件、少受損失、取得預期的結果并實現項目目標的，能夠爭取避免風險的發生或盡量減小風險發生后的影響。但是，完全避開或消除風險，或者只享受權益而不承擔風險是不可能的。

風險管理計劃編制：如何安排與實施項目的風險管理，制定下列各步的計劃

風險識別：識別出項目中已知和可預測的風險，確定風險的來源、產生的條件、描述風險的特征以及哪些項目可以產生風險，形成一個風險列表。

風險定性分析:? 對已經識別的風險進行排序，確定風險可能性與影響、確定風險優先級、確定風險類型

風險定量分析:? 進一步了解風險發生的可能性具體由多大，后果具體由多嚴重。包括靈敏度分析、期望貨幣價值分析、決策樹分析、蒙特卡羅模擬。

風險應對計劃編制：對每一個識別出來的風險來分別制定應對措施，這些措施組成的文檔稱為風險應對計劃。包括消極風險（避免策略、轉移策略、減輕策略）；積極風險（開拓、分享、強大）

風險監控：監控風險計劃的執行，檢測殘余風險，識別新的風險，保證風險計劃的執行，并評價這些計劃對減少風險的有效性。

項目風險：作用于項目上的不確定的事件或條件，既可能產生威脅，也可能帶來機會。

• 通過積極和合理的規劃，超過90%的風險都可以進行提前應對和管理
• 風險應該盡早識別出來，高層次風險應記錄在章程里
• 應由對風險最有控制力的一方承擔相應的風險。
• 承擔風險程度與所得回報相匹配原則，承擔的風險要有上限

風險的屬性

(1) 隨機性：風險事件發生及其后果都具有偶然性(雙重偶然)，遵循一定的統計規律。

(2) 相對性：風險是相對項目活動主體而言的。承受力不同，影響不同。風險承受力影響因素：收益大小（收益越大，越愿意承擔風險）；投入大小（投入越大，承受能力越小）;主體的地位和資源（級別高的人能承擔較大的風險)

(3) 風險的可變性：條件變化，會引起風險變化。包括性質、后果的變化，以
及出現新風險

風險的分類

按照后果的不同，風險可劃分為純粹風險（無任何收益）和投機風險（可能
帶來收益）

按風險來源劃分，自然風險（天災）和人為風險（人的活動，又可分為行為風險、經濟風險、技術風險、政治和組織風險等）

按是否可管理劃分，可管理（如內部多數風險）和不可管理（如外部政策）也要看主體管理水平

按影響范圍劃分，局部風險（非關鍵路徑活動延誤）和總體風險（關鍵路徑活動延誤）

按后果承擔者劃分：業主、政府、承包商、投資方、設計單位、監理單位保險公司等。

按可預測性劃分:已知風險（已知的進度風險）、可預測風險（可能服務器故障）、不可預測風險（地震、洪水、政策變化等）

在信息系統項目中，從宏觀上來看，風險可以分為項目風險、技術風險和商業風險

項目風險是指潛在的預算、進度、個人（包括人員和組織）、資源、用戶和需求方面的問題，以及它們對項目的影響。項目復雜性、規模和結構的不確定性也構成項目的（估算）風險因素。項目風險威脅到項目計劃，一旦項目風險成為現實，可能會拖延項目進度，增加項目的成本

技術風險是指潛在的設計、實現、接口、測試和維護方面的問題，此外，規格說明的多義性、技術上的不確定性、技術陳舊、最新技術 （不成熟）也是風險因素。技術風險威脅到待開發系統的質量和預定的交付時間。如果技術風險成為現實，開發工作可能會變得很困難或根本不可能

商業風險威脅到待開發系統的生存能力，主要有以下5種不同的商業風險：
(1) 市場風險。開發的系統雖然很優秀但不是市場真正所想要的。
(2)策略風險。開發的系統不再符合企業的信息系統戰略
(3)銷售風險。開發了銷售部門不清楚如何推銷的系統
(4) 管理風險。由于重點轉移或人員變動而失去上級管理部門的支持
(5) 預算風險。開發過程沒有得到預算或人員的保證。

【例題】以下關于軟件風險的敘述中，不正確的是（? ）
A、風險是可能發生的事件
B、如果發生風險，風險的本質、范圍和時間可能會影響風險所產生的后果
C、如果風險可以預測，可以避免其發生
D、可以對風險進行控制
答案：C

【例題】以下敘述中，（? ）不是一個風險
A.由另一個小組開發的子系統可能推遲交付，導致系統不能按時交付客戶
B.客戶不清楚想要開發什么樣的軟件，因此開發小組開發原型幫助其確定需求
C.開發團隊可能沒有正確理解客戶的需求
D.開發團隊核心成員可能在系統開發過程中離職
答案:B
?