買方將項目的全過程作為一個整體發包給同一個賣方的合同。需要特別注意的是，總承包合同要求只與同一個賣方訂立承包合同，但并不意味著只訂立一個總合同。可以采用訂立一個總合同的形式，也可以采用訂立若干個合同的形式。

• 采用總承包合同的方式一般適用于經驗豐富、技術實力雄厚且組織管理協調能力強的賣方，這樣有利于發揮賣方的專業優勢，保證項目的質量和進度，提高投資效益。
• 采用這種方式，買方只需與一個賣方溝通，容易管理與協調

單項承包合同

--1對多，一個甲方分別對多個乙方，項目要集成要控制要協調

一個賣方只承包項目中的某一項或某幾項內容，買方分別與不同的賣方訂立項目單項承包合同。

采用項目單項承包合同的方式有利于吸引更多的賣方參與投標競爭，使買方可以選擇在某一單項上實力強的賣方。同時也有利于賣方專注于自身經驗豐富且技術實力雄厚的部分的建設，
但這種方式對于買方的組織管理協調能力提出了較高的要求。

經合同約定和買方認可，賣萬將其承包項目的一部分或幾部分項目( 非項目的主體結構)再發包給具有相應資質條件的分包方，與分包方訂立的合同稱為項目分包合同。

需要說明的是，訂立項目分包合同必須同時滿足5個條件，即:

• 經過買方認可。
• 分包的部分必須是項目非主體工作。
• 只能分包部分項目，而不能轉包整個項目。
• 分包方必須具備相應的資質條件。
• 分包方不能再次分包。

賣方在原承包合同范圍內向買方負責，而分包方與賣方在分包合同范圍內向買方承擔連帶責任。如果分包的項目出現問題，買方既可以要求賣方承擔責任，也可以直接要求分包方承擔責任。//這個除非是三方合同，否則比較難以實現

總價合同--

風險乙方大

要求準確定義要采購的產品或服務，工作范圍、性質和工作量清楚。

雖然允許范圍變更，但通常會導致價格提高。

從付款的類型上來劃分，總價合同又可以分為固定總價合同、總價加激勵費用合同、總價加經濟價格調整合同和訂購單。

固定總價合同： --風險在賣方，在乙方；

2)總價加激勵費用合同FPIF

總價加激勵費用合同(Fixed Price Incentive Fee, FPIF) 為買方和賣方都提供了一定的靈活性，它允許有一定的績效偏差，并對實現既定目標給予財務獎勵。

獎勵的計算方法可以有多種，但都與賣方的成本、進度或技術績效有關。例如，規定目標工期以及提前完工的獎金。績效目標一開始就要制定好，而最終的合同價格要待全部工作結束后根據賣方績效加以確定。在FPIF合同中，要設置一個價格.上限(最高限價、天花板價格)，賣方必須完業中作并且要承擔高于上限的全部成本，也就是說，買方付款的總數不得超過最高限價。

?A項目： 項目總價11萬，限價12萬；乙方實際花費9萬，節省2萬，節省部分分攤甲方60%；---------9萬+2*0.4=9.8萬；

B項目，項目總價11萬，限價12萬；乙方實際成本高了，全部自己承擔，甲方支付12萬；

成本補償合同：---買方風險大，適用范圍：產品和服務無法明確定義，工作性質范圍和工作量不好定義

成本補償合同以賣方從事項目工作的實際成本作為付款的基礎，即成本實報實銷。在這種合同下，買方的成本風險最大。這種合同適用于買方僅知道要一個什么產 品但不知道具體工作范圍的情況，也就是工作范圍很不清楚的項目。當然，成本補償合同也適用于買方特別信得過的賣方，想要與賣方全面合作的情況。

成本加固定費用合同(Cost Plus Fixed Fee, CPFF)為賣方報銷履行合同工作所發生的一切合法成本(即成本實報實銷)，并向賣方支付一筆固定費用作為利潤，該費用以項目初始估算成本 (目標成本)的某一百分比計算。

費用只能針對已完成的工作來支付，并且不因賣方的績效而變化。

除非項目范圍發生變更，費用金額維持不變。這是最常用的成本補償合同，對賣方有--定的制約作用。例如，表13-2是一個成本加固定費用合同的示例。

在CPIF合同下，如果賣方的實際成本低于目標成本，節余部分由雙方按--定比例分成(例如，按照80/20的比例分享，即買方80%，賣方20%);如果賣方的實際成本高于目標成本，超過目標成本的部分由雙方按比例分擔(例如，基于賣方的實際成本，按照20/80的比例分擔，即買方20%，賣方80%)。

?A項目： 成本9萬；節省2萬；節省部分40%給乙方；所以9+2*0.4=9.8

B項目： 成本14萬，超支3萬；超支部分甲方需要支持60%；11萬+3*0.6=12.8萬；

成本加獎勵費用合同(Cost Price Award Fee, CPAF) 為賣方報銷履行合同工作所發生的一切合法成本(即成本實報實銷)，買方再憑自己的主觀感覺給賣方支付一筆利潤，完全由買方根據自己對賣方績效的主觀判斷來決定獎勵費用，并且賣方通常無權申訴。

//獎勵甲方定

工料合同， 工作范圍和性質清楚，但是工作量不清楚，買方擔工作量風險；賣方擔單價風險；

工料合同(Time and Material, T&M)是指按項目工作所花費的實際工時數和材料數，按事先確定的單位工時費用標準和單位材料費用標準進行付款。這類合同適用干中作性質清楚，工作范圍比較明確，但具體的工作量無法確定的項目。

在這種合同下，買方承擔中等程度的成本風險，即承擔工作量變動的風險，而賣方則承擔單價風險。因此，工料合同在金額小、工期短、不復雜的項目上可以有效使用，但在金額大、工期長的復雜項目.上不適用。

工料合同是兼具成本補償合同和總價合同的某些特點的混合型合同。在不能很快編寫出準確工作說明書的情況下，經常使用工料合同來增加人員、聘請專家以及尋求其他外部支持。這類合同與成本補償合同的相似之處在于，它們都是開口合同，合同價因成本增加而變化。

在授予合同時，買方可能并未確定合同的總價值和采購的準確數量。因此，如同成本補償合同，工料合同的合同價值可以增加。很多組織會在工料合同中規定最高價格和時間限制，以防止成本無限增加。另--方面，由于合同中確定了一-些參數，工料合同又與固定單價合同相似。當買賣雙方就特定資源類別的價格( 例如，高級工程師的小時費率或某種材料的單位費率)取得一致意見時，買方和賣方就預先設定了單位人力或材料費率(包含賣方利潤)。

• 工作范圍很明確具體，用總價合同。
• 工作性質清楚，范圍不清楚，工作不復雜，又需要快速簽訂合同，則使用工料合同。
• 如果工作范圍不清楚，則使用成本補償合同。
• 如果雙方分擔風險，則使用工料合同; 如果買方承擔成本風險，則使用成本補償合同; 如果賣方承擔成本風險，則使用總價合同。
• 如果是購買標準產品，且數量不大，則使用單邊合同。

合同當事人之間無法就某一事項協商達成一 致意見，該事項就成為一個爭議事項。解決爭議的方法主要有替代爭議解決方法(包括調解、仲裁等)和訴訟。替代爭議解決方法由雙方共同聘請的第三方提出解決方案;訴訟是向執法機關提出控告、申訴，要求評判曲直是非。

按照慣例，這兩種解決方法通常是相互排斥的，即如果約定了仲裁且約
定了仲裁裁決的終局性，就不能向法院訴訟。仲裁是當事人自愿約定的，通常也會約定仲裁裁決具有終局的約束力。
在解決合同爭議的方法中，其優先順序為談判(協商)、調解、仲裁、訴訟。

1)按索賠的目的分類
按索賠的目的分類，可分為工期索賠和費用索賠。

• 工期索賠就是要求買方延長項目工期,使原規定的完工日期順延,從而避免違約罰金的發生;
• 費用索賠就是要求買方(或賣方)補償費用損失，進而調整合同價款。

2)按索賠的依據分類
按索賠的依據分類，可分為合同規定的索賠、非合同規定的索賠。合同規定的索賠是指索賠涉及的內容在合同文件中能夠找到依據，買方(或賣方)可以據此提出索賠要求。這種索賠不太容易發生爭議;非合同規定的索賠是指索賠涉及的內容在合同文件中沒有專門的文字敘述，但可以根據該合同某些條款的含義，推論出一定的索賠權。

3)按索賠的業務性質分類
按索賠的業務性質分類，可分為工程索賠和商務索賠。

• 工程索賠是指涉及項目執行過程中的施工條件、技術、范圍等變化引起的索賠，一 般發生頻率高，索賠費用大;
• 商務索賠是指在項目執行過程中的設備采購、運輸、保管等方面引起的索賠事項。

4)按索賠的處理方式分類
按索賠的處理方式分類，可分為單項索賠和總索賠。

• 單項索賠就是采取一事一索賠的方式，即按每- -件索賠事項發生后，報送索賠通知書，編報索賠報告，要求單項解決支付，不與其他的索賠事項混在一起;
• 總索賠又稱為綜合索賠或一攬子索賠，即對整個項目中所發生的數起索賠事項，綜合在一起進行索賠。

3.合可索賠流程
項目發生索賠事件后，一-般先由監理工程師調解，若調解不成，由政府建設主管機構進行調解，若仍調解不成，由經濟合同仲裁委員會進行調解或仲裁。

在整個索賠過程中，遵循的原則是索賠的有理性、索賠依據的有效性、索賠計算的正確性。

索賠具體流程如下。
(1)提出索賠要求。當出現索賠事項時，索賠方以書面的索賠通知書形式，在索賠事項發生后的28天以內，向監理工程師正式提出索賠意向通知。
(2)報送索賠資料。在索賠通知書發出后的28天內，向監理工程師提出延長工期和(或)補償經濟損失的索賠報告及有關資料。索賠報告的內容主要有總論部分、根據部分、計算部分和證據部分。

索賠報告編寫的一.般要求如下。
。索賠事件應該真實。
。責任分析應清楚、準確、有根據。
。充分論證事件給索賠方造成的實際損失。
。索賠計算必須合理、正確。
。文字要精煉、條理要清楚、語氣要中肯。

(3)監理工程師答復。 監理工程師在收到送交的索賠報告有關資料后，于28天內給予答復，或要求索賠方進一步補充索賠理由和證據。

(4)監理工程師逾期答復后果。監理 工程師在收到承包人送交的索賠報告的有關資料后28天未予答復或未對承包人作進- - 步要求，視為該項索賠已經認可。

(5)持續索賠。當索賠事件持續進行時，索賠方應當階段性向監理工程師發出索賠意向，在索賠事件終了后28天內，向監理工程師送交索賠的有關資料和最終索賠報告,監理工程師應在28天內給予答復或要求索賠方進-步補充索賠理由和證據。逾期未答復，視為該項索賠成立。.

(6)仲裁與訴訟。監理工程師對索賠的答復，索賠方或發包人不能接受，即進入仲裁或訴訟程序。

配置項的狀態可分為“草稿”“正式”和“修改”三種。

配置項的版本號規則與配置項的狀態相關。
(1)處于“草稿”狀態的配置項的版本號格式為0.YZ, YZ的數字范圍為01~99。
隨著草稿的修正，YZ的取值應遞增。YZ的初值和增幅由用戶自己把握。

(2)處于“正式”狀態的配置項的版本號格式為X.Y，X為主版本號，取值范圍為
1~9。Y為次版本號，取值范圍為0~9。

配置項第一次成為 “正式”文件時，版本號為1.0。
如果配置項升級幅度比較小，可以將變動部分制作成配置項的附件，附件版本依次為1.0，1.1, .。.當附件的變動積累到一定程度時，配置項的Y值可適量增加，Y值增加一定程度時，X值將適量增加。當配置項升級幅度比較大時，才允許直接增大X值。

(3)處于“修改”狀態的配置項的版本號格式為X.YZ。配置項正在修改時，一般
只增大Z值，X.Y值保持不變。當配置項修改完畢，狀態成為“正式”時，將Z值設置為0，增加X.Y值。參見上述規則(2)。

?基線通常對應于開發過程中的里程碑(Milestone)， - - 個產品可以有多個基線，也可以只有一個基線。

交付給外部顧客的基線-般稱為發行基線(Release)， 內部開發使用的基線一般稱為構造基線(Build)。

對于每一個基線，要定義下列內容:建立基線的事件、受控的配置項、建立和變更基線的程序、批準變更基線所需的權限。

在項目實施過程中，每個基線，都要納入配置控制，對這些基線的更新只能采用正式的變更控制程序。

配置庫可以分開發庫、受控庫、產品庫3種類型。
(1)開發庫(Development Library), 也稱為動態庫、程序員庫或工作庫，用于開發人員當前正在開發的配置實體，如:新模塊、文檔、數據元素或進行修改的已有素。動態中的配置項被置于版本管理之下。動態庫是開發人員的個人工作區，由開發員自行控制。庫中的信息可能有較為頻繁的修改，只要開發庫的使用者認為有必要，需對其進行配置控制，因為這通常不會影響到項目的其他部分。

(2)受控庫(Controlled Library),也稱為主庫，包含當前的基線加上對基線的變受控庫中的配置項被置于完全的配置管理之下。在信息系統開發的某個階段工作結束將當前的工作產品存入受控庫。

(3)產品庫(Product Library), 也稱為靜態庫、發行庫、軟件倉庫，包含已發不用的各種基線的存檔，被置于完全的配置管理之下。在開發的信息系統產品完成系試之后，作為最終產品存入產品庫內，等待交付用戶或現場安裝。
?

配置控制委員會(Configuration Control Board, CCB)，負責對配置變更做出評估、審批以及監督已批準變更的實施。

CCB建立在項目級，其成員可以包括項目經理、用戶代表、產品經理、開發工程師、測試工程師、質量控制人員、配置管理員等。CCB不必是常設機構，完全可以根據工作的需要組成，例如按變更內容和變更請求的不同，組成不同的CCB。小的項目CCB可以只有一個人，甚至只是兼職人員。
通常，CCB不只是控制配置變更，而是負有更多的配置管理任務,例如:配置管理計劃審批、基線設立審批、產品發布審批等。

負責在整個項目生命周期中進行配置管理活動，具體有:

• 編寫配置管理計劃。
• 建立和維護配置管理系統。
• 建立和維護配置庫。
• 配置項識別。
• 建立和管理基線。
• 配置狀態報告
• 配置審計。
• 發布管理和交付。
• 對項目成員進行配置管理培訓。

配置管理計劃是對如何開展項目配置管理工作的規劃，是配置管理過程的基礎，應該形成文件并在整個項目生命周期內處于受控狀態。配置控制委員會負責審批該計劃。
配置管理計劃的主要內容為:
1）覆蓋的主要活動包括配置標識、配置控制、配置狀態報告、配置審計、發布管理與交付。

2）實施這些活動的規范流程
(3)實施這些活動的時間計劃。
(4)負責實施這些活動的人員或組織，以及他們和其他組織的關系。

包括下述任務:

• 標識和記錄變更申請，
• 分析和評價變更，
• 批準或否決變更申請，
• 變更的實施
• 變更的驗證和確認
• 發布已修改的配置項

配置狀態報告( Configuration Status Reporting ) : 也稱配置狀態統計[Configuration Status Accounting],其任務是有效地記錄和報告管理配置所需要的信息,目的是及時、準確地給出配置項的當前狀況,供相關人員了解,以加強配置管理工作。

配置狀態報告應該包含以下內容。
[1]每個受控配置項的標識和狀態。一旦配置項被置于配置控制下,就應該記錄和保存它的每個后繼進展的版本和狀態。
[2]每個變更申請的狀態和已批準的修改的實施狀態。
[3]每個基線的當前和過去版本的狀態以及各版本的比較。
[4]其他配置管理過程活動的記錄。

配置審計(Configuration Audit)也稱配置審核或配置評價，包括功能配置審計和物
理配置審計，分別用以驗證當前配置項的一-致性和完整性。配置審計的實施是為了確保項目配置管理的有效性，體現了配置管理的最根本要
求一-不允許出現任何混亂現象，例如:

• 防止向用戶提交不適合的產品，如交付了用戶手冊的不正確版本。
• 發現不完善的實現，如版本不符合規格說明或未按變更請求實施變更。
• 找出各配置項間不匹配或不相容的現象。
• 確認配置項已在所要求的質量控制審核之后納入基線并入庫保存。
• 確認記錄和文檔保持著可追溯性。

1)功能配置審計--配置項的一致性---
功能配置審計(Functional Configuration Audit) 是審計配置項的一 致性(配置項的實際功效是否與其需求- -致)，具體驗證以下幾個方面。

• 配置項的開發已圓滿完成。
• 配置項已達到配置標識中規定的性能和功能特征。
• 配置項的操作和支持文檔已完成并且是符合要求的。

2)物理配置審計--驗證配置項的完整性
物理配置審計( Physical Configuration Audit)是審計配置項的完整性(配置項的物理存在是否與預期一致)，具體驗證如下幾個方面。

• 要交付的配置項是否存在。
• 配置項中是否包含了所有必需的項目。

發布管理和交付活動的主要任務是:有效控制軟件產品和文檔的發行和交付,在軟件產品的生存期內妥善保存代碼和文檔的母拷貝。

[1]存儲。

應通過下述方式確保存儲的配置項的完整性:?選擇存儲介質使再生差錯或損壞降至最低限度。根據媒體的存儲期,以一定頻次運行或刷新已存檔的配置項。將副本存儲在不同的受控場所,以減少丟失的風險。

[2]復制。復制是用拷貝方式制造軟件的階段。
應建立規程以確保復制的一致性和完整性。應確保發布用的介質不含無關項(如軟件病毒或不適合演示的測試數據)。應使用適合的介質以確保軟件產品符合復制要求,確保其在整個交付期中內容的完整性。

[3]打包。應確保按批準的規程制備交付的介質。應在需方容易辨認的地方清楚標出發布標識。

[4]交付。供方應按合同中的規定交付產品或服務。

[5]重建。應能重建軟件環境,以確保發布的配置項在所保留的先前版本要求的未來一段時間里 是可重新配置的。

當事人訂立合同，采取要約、承諾方式。

要約是希望和他人訂立合同的意思表示，該意思表示應當內容具體確定，表明經受要約人承諾，要約人愿意受該意思表示約束;

• 要約邀請是希望他人向自已發出要約的意思表示，例如寄送的價目表、拍賣公告、招標公告、招股說明書、商業廣告等，都是要約邀請。
• 投標人根據招標內容在約定期限內向招標人提交的投標文件，也可以看作是-一種要約。
• 另外，如果商業廣告的內容符合要約規定的，則視為要約。

法律分析：

要約，是當事人一方向對方發出的希望與對方訂立合同的意思表示。發出要約的一方稱要約人，接受要約的一方稱受要約人。不一定是甲方或者乙方。

要約邀請，是當事人訂立合同的預備行為，只是引誘他人發出要約，不能因相關人的承諾而成立合同。在發出要約邀請以后，要約邀請人撤回其邀請，只要沒給相關人造成信賴利益的損失，要約邀請人一般不承擔責任，如寄送的價目表、拍賣公告、招標公告、招股說明書、商業廣告等為要約邀請。因為要約邀請只是作出希望別人向自己發出要約的意思表示。因此，要約邀請可以向不特定的任何人發出，也不需要在要約邀請中詳細表示，無論對于發出邀請人還是接受邀請人，都沒有約束力。

要約可以撤回。撤回要約的通知應當在要約到達受要約人之前或者與要約同時到達受要約人。要約可以撤銷。撤銷要約的通知應當在受要約人發出承諾通知之前到達受要約人。有下列情形之- -的，要約不得撤銷:
(1)要約人確定了承諾期限或者以其他形式明示要約不可撤銷。
(2)受要約人有理由認為要約是不可撤銷的，并已經為履行合同作了準備工作。

有下列情形之一的，要約失效:
(1)拒絕要約的通知到達要約人。
(2)要約人依法撤銷要約。
(3)承諾期限屆滿，受要約人未作出承諾。
(4)受要約人對要約的內容作出實質性變更。

承諾是受要約人同意要約的意思表示。承諾應當以通知的方式作出，但根據交易習慣或者要約表明可以通過行為作出承諾的除外。承諾應當在要約確定的期限內到達要約人。.要約沒有確定承諾期限的，承諾應當依照下列規定到達:
(1)要約以對話方式作出的，應當即時作出承諾，但當事人另有約定的除外。
(2)要約以非對話方式作出的，承諾應當在合理期限內到達。

要約以信件或者電報作出的，承諾期限自信件載明的日期或者電報交發之日開始計算。信件未載明日期的，自投寄該信件的郵戳日期開始計算。要約以電話、傳真等快速通訊方式作出的，承諾期限自要約到達受要約人時開始計算。

承諾生效時合同成立，承諾通知到達要約人時生效。承諾不需要通知的，根據交易習慣或者要約的要求作出承諾的行為時生效。

承諾可以撤回。撤回承諾的通知應當在承諾通知到達要約人之前或者與承諾通知同時到達要約人。受要約人超過承諾期限發出承諾的，除要約人及時通知受要約人該承諾有效的以外，為新要約。受要約人在承諾期限內發出承諾，按照通常情形能夠及時到達要約人，但因其他原因承諾到達要約人時超過承諾期限的，除要約人及時通知受要約人因承諾超過期限不接受該承諾的以外，該承諾有效。

承諾的內容應當與要約的內容- -致。 受要約人對要約的內容作出實質性變更的，為新要約。有關合同標的、數量、質量、價款或者報酬、履行期限、履行地點和方式、違約責任和解決爭議方法等的變更，是對要約內容的實質性變更。承諾對要約的內容作出非實質性變更的，除要約人及時表示反對或者要約表明承諾不得對要約的內容作出任何變更的以外，該承諾有效，合同的內容以承諾的內容為準。

企業標準由企業組織制定，并按省、自治區、直轄市人民政府的規定備案。

對已有國家標準、行業標準或者地方標準的，鼓勵企業制定嚴千國家標準行業標準或者地方標準要求的企業標準，在企業內部適用。

強制性標準；推薦性標準。

按照新的采用國際標準管理辦法，我國標準與國際標準的對應關系有

• 等同采用(identical, IDT)、等同采用是指技術內容相同，沒有或僅有編輯性修改，編寫方法完全相對應;
• 修改采用(modified, MOD)、修改采用是指與國際標準之間存在技術性差異，并清楚地標明這些差異以及解釋其產生的原因，允許包含編輯性修改;
• 等效采用( equivalent, EQ)?等效采用(修改采用)是指主要技術內容相同，技術上只有很少差異，編寫方法不完全相對應;
• 非等效采用(not equivalent, NEQ)非等效采用是指與相應國際標準在技術內容和文本結構.上不同，它們之間的差異沒有被清楚地標明。非等效還包括在我國標準中只保留了少量或者不重要的國際標準條款的情況，非等效不屬于采用國際標準，

• 《軟件工程術語》(GB/T 11457- -2006)、
• 《信息處理數據流程圖、程序流程圖、系統流程圖、程序網絡圖和系統資源圖的文件編輯符號及約定》(GB 1526-1989)
• 《信息處理系統計算機系統配置圖符號及約定》(GB/T 14085--1993)等標準。

對于配置管理，有以下三種基線:

• 功能基線(最初通過的功能配置);
• 分配基線(最初通過的分配的配置)、
• 產品基線( 最初通過的或有條件地通過的產品配置)。

《信息技術軟件生存周期過程》(GB/T 8566-2007)等標準。

《計算機軟件文檔編制規范》(GB/T 8567- 2006)和

《計算機軟件需求規格說明規范》(GB/T 9385- -2008) 等標準。

GB/T 8567- -2006 詳細給出了25種文檔編制的格式(但在文檔的歸類中，卻只給出了其中的18種文檔)，

包括可行性研究(研究)報告、

1. GB/T8567--2006

給出了這25種文件的具體內容，使用者可根據實際情況對該標準進行適當剪裁。
GB/T 8567- -2006還規定了面向對象的軟件應編制以下文檔:總體說明文檔、用例圖文檔、類圖文檔、順序圖文檔、協作圖(通信圖)文檔、狀態圖文檔、活動圖文檔、構件圖文檔、部署圖文檔、包圖文檔。

?2. GB/I9385- 2008

GB/T9385--2008詳細描述了SRS應該包含的內容及編寫格式。該指南為軟件需求實踐提供了一個規范化的方法，不提倡將軟件需求說明劃分成等級，避免將它定義成更小的需求子集。該指南規定，SRS的內容應該包括以下4個方面。

(1)前言:包括目的、范圍、定義、簡稱和縮略語、引用文件、綜述。.
(2)總體描述/總體需求/概要需求

? ? ?包括產品描述、產品功能、用戶特點、約束、假設和依賴關系、需求分配。
(3)具體需求/詳細需求
(4)支持信息:附錄和索引。

SRS應該具有以下特性:無歧義性、完整性、可驗證性、- -致性、可修改性、可追蹤性(向后追蹤、向前追蹤)、運行和維護階段的可使用性。

《信息技術軟件產品評價質量特性及其使用指南》(GB/T 16260- -2006) 等標準。

GB/T 16260- -2006分為四個部分，分別是GB/T 16260.1- -2006、GB/T 16260.2-
2006、GB/T 16260.3- -2006 和GB/T 16260.4- -2006。 GB/T 16260.1- -2006中提出了軟件生存周期中的質量模型，如圖26-1所示。

軟件產品質量可以通過測量內部屬性(典型地是對中間產品的靜態測度),也可以通過測量外部屬性(典型地是通過測量代碼執行時的行為)，或者通過測量使用質量的屬性來評價。
目標就是使產品在指定的使用環境下具有所需的效用。

過程質量有助于提高產品質量，產品質量又有助于提高使用質量。

GB/T 16260.1- -2006定義了6個質量特性和21個質量子特性，它們以最小的重疊描述了軟件質量。質量特性和質量子特性，如表26-6所示。

1.提出與接受變更申請
但在評估前應以書面形式的提出。一般項目經理，或者項目配置管理員負貴該相關信息的收集，以及對變更申請的初審。
2.對變更的初審
3.變更方案論證
變更方案的主要作用，首先是對變更請求是否可行實現進行論證，如果可能實現，則將變更請求由技術要求轉化為資源需求，以供CCB決策。

4. CCB審批

審查過程，是項目所有者根據變更申請及評估方案，決定是否變更項目基準。評審過程常包括客戶、相關領域的專業人士等。審查通常是文檔會簽形式，重大的變更審查可以包括正式會議形式。
審查過程應注意分工，項目投資人雖有最終的決策權，但通常技術上并不專業。所以應當在評審過程中將專業評審、經濟評審分開，對涉及項目目標和交付成果的變更,客戶的意見應放在核心位置。
5.發出變更通知并組織實施
評審通過，基準的調整，包括項目目標的確認，最終成果、工作內容和資源、進度計劃的調整。
需要強調的是，變更的通知，不只是包括項目實施基準的調整，更要明確項目的交付日期、成果對相關干系人的影響。如變更造成交付期的調整，應在變更確認時發布，而非在交付前公布。

6.變更實施的監控
要監控的，除了調整過的基準中，涉及變更的內容外，還應當對項目的整體基準是否反映項目實施情況負責。通過監控行動，確保項目的整體實施工作是受控的。變更實施的過程監控，
通常由項目經理負責基準的監控。管理委員會監控變更明確的主要成果、進度里程碑等，可以通過監理單位完成。
7.變更效果的評估
變更評估可以從以下幾個方面進行評估:
(1)首要的評估依據，是項目的基準。
(2)還需結合變更的初衷來看，變更所要達到的目的是否已達成。
(3)評估變更方案中的技術論證、經濟論證內容與實施過程的差距并促發解決。
8.判斷發生變更后的項目是否已納入正常軌道
?

(1)對進度變更的控制:包括以下主題。
。判斷項目進度的當前狀態。
●對造成進度變化的因素施加影響。
?查明進度是否已經改變。
。在實際變化出現時對其進行管理。

(2)對成本變更的控制:包括以下主題。

• 對造成費用基準變更的因素施加影響。
• 當變更發生時，管理這些實際的變更。
• 保證潛在的費用超支不超過授權的項目階段資金和總體資金。
• 監督費用績效，找出與費用基準的偏差。
• 準確記錄所有的與費用基準的偏差。
• 防止錯誤的、不恰當的或未批準的變更被納入費用或資源使用報告中。.
• 就審定的變更，通知利害關系者。
• 采取措施，將預期的費用超支控制在可接受的范圍內。

? ? ? ?項目費用控制查找正、負偏差的原因，它是整體變更控制的一- 部分。
?

(3)對合同變更的控制:
合同變更控制系統規定合同修改的過程。
它包括文書工作、跟蹤系統、爭議解決程序以及批準變更所需的審批層次。
合同變更控制系統應當與整體變更控制系統結合起來。
?

版本發布準備

(1)進行相關的回退分析。
(2)備份版本發布所涉及的存儲過程、函數等其他數據的存儲及回退管理。
(3)備份配置數據，包括數據備份的方式，如Dmp方式。
(4)備份在線生產平臺接口、應用、工作流等版本。
(5)啟動回退機制的觸發條件。
(6)對變更回退的機制職責的說明;如通知相關部門，確定需要回退的關聯系統和
回退時間點等。

回退步驟:
(1)通知相關用戶系統開始回退。
(2)通知各關聯系統進行版本回退。
(3)回退存儲過程等數據對象。
(4)配置數據回退。
(5)應用程序、接口程序、工作流等版本回退。
(6)回退完成通知各周邊關聯系統。
(7)回退后進行相關測試，保證回退系統能夠正常運行，如進行SHAKEDOWN測試。
(8)通知用戶回退完成。
?

企業的流程管理一.般分為生產流程層、運作層、計劃層和戰略層4個層次

業務流程分析的主要方法有價值鏈分析法、客戶關系分析法、供應鏈分析法、基于ERP的分析法和業務流程重構等。

(1)價值鏈分析法。價值鏈分析法找出或設計出那些能夠使顧客滿意，實現顧客價值最大化的業務流程。價值鏈就是-一個創造價值的I工作流程，在這一總流程基礎上， 可把企業具體的活動細分為生產指揮流程、計劃決策流程、營銷流程、信息搜集與控制流程、資金籌措流程等。其中有些業務流程特別重要，對形成企業核心競爭力起著關鍵作用，這樣的業務流程稱為基本業務流程，對應于價值鏈中的基本活動;其他業務流程是對企業的基本經營活動提供支持和服務，稱為輔助業務流程，對應于價值鏈中的輔助活動。

(2)客戶關系分析法。客戶關系分析法就是把CRM用在業務流程的分析上。CRM的目標是建立真正以客戶為導向的組織結構，以最佳的價值定位瞄準最具吸引力的客戶，最大化地提高運營效率，建立有效的合作伙伴關系。從CRM的角度分析業務流程，企業的業務流程應當是以客戶與企業的關系，以及客戶行為為依據的，而不是傳統的按照企業內部管理來實施的。

(3)供應鏈分析法。供應鏈分析法是從企業供應鏈的角度分析企業的業務流程，它源于SCM.供應鏈是指用一個整體的網絡用來傳送產品和服務，從原材料開始一直 到最終客戶(消費者),它憑借-一個設計好的信息流、物流和資金流來完成。供應鏈分析法主要從企業內部供應鏈和外部供應鏈兩個角度來分析企業的業務流程，分析哪些流程處于供應鏈的核心環節。

(4)基于ERP的分析法。ERP的基本思想是將企業的業務流程看作是--個緊密聯接的供應鏈，將供應商和企業內部的采購、生產、銷售，以及客戶緊密聯系起來，對供應鏈上的所有環節進行有效管理，實現對企業的動態控制和各種資源的集成和優化，從而提升:企業基礎管理水平，追求企業資源的合理、高效利用。

(5)業務流程重構。通過重新審視企業的價值鏈,從功能成本的比較分析中，確定企業在哪些環節具有比較優勢。在此基礎上，以顧客滿意為出發點進行價值鏈的分解與整合，改造原有的業務流程，實現業務流程的最優化。有關業務流程重構的詳細知識，將在19.3節中進行介紹。

在流程設計過程中，為了更清晰地表達過程規則說明，陸續出現了- -些用于表示業務流程的工具，這些工具包括三類，分別是圖形工具、表格工具和語言工具。

其中常見的圖形工具包括程序流程圖、IPO 圖、N-S盒圖、問題分析圖、判定樹，表格工具包括判定表；語言工具包括流程設計語言；

(4)問題分析圖。問題分析圖( Problem Analysis Diagram， PAD)是繼PFD和N-S圖之后，又一種描述詳細設計的工具，它由日立公司于1979 年提出，也是一種支持結構化程序設計的圖形工具。

PAD也包含五種基本控制結構，并允許遞歸使用。PAD的執行順序是從最左主干線的上端的結點開始，自. 上而下依次執行。每遇到判斷或循環，就自左而右進入下一層，從表示下一層的縱線上端開始執行，直到該縱線下端，再返回.上一層的縱線的轉入處。如此繼續，直到執行到主干線的下端為止。可以以PAD為基礎，按照一個機械的變換規則編寫計算機程序，PAD具有清晰的邏輯結構、標準化的圖形等優點，更重要的是，它引導設計人員使用結構化程序設計方法，從而提高程序的質量。

BPR在追求顧客滿意度和員工追求自我價值實現的流程中帶來降低成本的結果，從而達到效率和效益改善的目的。

BPR在注重結果的同時，更注重流程的實現，并非以短期利潤最大化為追求目標，而是追求企業能夠持續發展的能力，因此，必須堅持

• 以流程為中心的原則、
• 團隊式管理原則(以人為本的原則)和
• 以顧客為導向的原則。