軟件生存期過程（3）

6 獲取過程

　　獲取過程包含需方的活動和任務。此過程從定義軟件產品或服務的獲取需求開始。接著就是準備并公布標書、選擇供方和管理獲取過程，直到系統的驗收。有這種需求的機構可以叫做擁有者。該擁有者可以就任一項或全部獲取活動與某機構簽訂合同，該機構將根據獲取過程開展相應的活動。本章中的需方可以是擁有者或者是代理人。

　　此過程含有下述活動：
　　a.開始和范圍定義；
　　b.招標的準備；
　　c.合同的準備、談判及修改；
　　d.對供方的監督；
　　e.驗收和完成。

　　6.1 開始和范圍定義
　　本項活動含有下述任務：

　　6. 1.1 需方將認定獲取、開發或改進一個軟件產品（該軟件產品可能是一個系統的一部分）或服務的概念或需求，并依此開始該獲取過程。

　　6.1.2 需方將詳細地定義系統需求，此需求在已存在的限制條件下開發系統是可行的。

　　6.1.2.1 該系統需求定義最好包括與設計、測試和遵守標準及開發過程有關的關鍵性、安全性和保密性要求。

　　6.1.2.2 該系統需求將遵循開發過程（第8章）定義并形成文檔。

　　6.1.3 如果需方不能定義系統需求，則將制訂一個定義它們的計劃。這個計劃將指定提出這些需求的一個機構，最好包括一一些活動，如進行可行性研究、制作原型和模型。

　　6.1.4 系統需求一旦定義，需方將依據風險分析來考慮獲取系統所能采用的方案。這些方案包括：
　　a.購買能滿足需求的現貨產品；
　　b.在內部開發產品或得到服務；
　　c.通過合同開發產品或得到服務；
　　d.上述a、b、c條的結合；
　　e.提高現有的系統、產品或服務。

　　6.1.5 當要獲得一個現貨產品的時候，需方將保證能滿足下述條件：
　　a.該軟件滿足它的需求；
　　b.有必須的文檔；
　　c.可滿足所有權和使用權；
　　d. 有未來的產品支持計劃。

　　6.1.6 需方將制訂一個獲取計劃。此計劃要對系統需求作出定義，并定義對所計劃的系統的使用、將執行的合同的類型、所涉及的機構的責任、將使用的支持的概念、所考慮到的風險以及管理這些風險的辦法。并將該計劃寫成文檔。

　　6.1.7 需方將定義系統的驗收策略和準則，并將其寫成文檔。

　　6.2 招標的準備
　　此項活動含有下述任務：

　　6.2.1 需方將制作一份系統獲取需求的文檔（即標書），其內容視第6.1.4條中所選的獲取選擇方案而定。該系統獲取文檔最好包括：
　　a.系統需求；
　　b.工作描述；
　　c.投標者須知；
　　d.產品或服務清單；
　　e.合同條款；
　　f.子合同條款；
　　g.技術限制（例如目標環境）。

　　6.2.2 需方將決定本標準的哪些過程、活動和任務適合它的項目并對其進行適當的剪裁。需方將特別指明可以使用的支持過程（第11章）和它們的執行機構，這樣供方就可以在它們的建議中定義達到每個特定支持過程的方法。

　　6.2.3 系統的獲取文檔將定義合同的里程碑，以便作為對獲取的監督（見第 11. 3條）的一部分將檢驗和審計供方的進度。

　　6.2.4 系統的獲取需求最好交給實施獲取活動任務的機構。

　　6.3 合同的準備、談判和修改
　　此項活動由下述任務組成：

　　6.3.1 需方最好建立一個選擇供方的規程，其中包括建議的評價準則和對需求的依從程度。

　　6.3.2 需方最好在對供方的建議、能力以及需要考慮的其它因素進行評價的基礎上選擇一個供方。

　　6.3.3 需方可以與其它各方一道為項目而剪裁本標準。但是，在需方與其它各方之間達成協議時，最后的剪裁決定將由需方做出。

　　6.3.4 然后，需方將準備就一項合同與供方進行談判。談判中提出系統的需求、成本、提供產品或服務的日程。該合同將提及與可重復使用的現貨產品有關的產權、使用權和所有權。

　　6.3.5 在合同的執行期內，需方將通過與供方（即控制合同變化的另一當事方）進行談判來控制合同的變化。應當研究合同的變化對項目計劃、成本、質量和日程的影響。

　　6.4 對供方的監督
　　此項活動由下述任務組成：

　　6.4.1 需方將按照合同所定范圍監督和評價供方的技術和進度，其中包括質量和成本。所用的手段最好適合于獲得的類型并包括下述活動，例如非正式的會面、合同所要求的評審、審計，以及（獨立的）驗證和確認。獨立的驗證和確認將分別根據第 11.3和11.4條進行。

　　6.4.2 需方最好與供方合作以便及時地提供全部必要的信息和解決尚未解決的問題。

　　6.5 驗收和完成
　　此項活動含有下述任務：

　　6.5.1 需方將根據已定義的策略和準則為驗收做好全部必要的準備。準備最好包括對測試用例、測試數據、測試過程和測試環境的準備。

　　6.5.2 需方將對交付的產品或服務進行驗收評審和驗收測試，當符合所有的驗收條件之后，從供方處驗收該產品或服務。驗收過程應符合第6.1.6條中的規定。

　　6.5.3 在驗收之后，需方最好按照第 11.2條采取交付產品的配置管理。

　　7 供應過程

　　此過程含有供方的活動和任務。

　　此過程的開始方法可以有兩種，－是決定準備一項建議以應答需方的標書（RFP）；二是就提供一個含有軟件的系統（或系統的一個部件、一個產品或一項服務）與需方簽訂合同或協議。接著就是規定為了管理和保證這個項目所需要的步驟和資源，其中包括制訂項目計劃和實施計劃，直至向需方交付系統、產品或提供服務。 供方按照第5章來管理這個過程。

　　此過程含有下述活動：
　　a. 開始；
　　b.準備投標；
　　c.簽訂協議；
　　d.編制計劃；
　　e.實施和控制；
　　f.評審和評價；
　　g.交付和完成。

　　7.1 開始
　　此項活動含有下述任務：

　　7.1.1 供方評審標書（RFP）中的需求，與公司的方針及其它規則相對照。

　　7.1.2 供方最好對是否投標或是否接受合同作出決定。

　　7.2 準備投標
　　此項活動含有下述任務： 供方最好定義和準備一份投標書。

　　7.3 簽訂協議
　　此項活動含有下述任務：

　　7.3.1 供方應當與需方就提供系統、產品或服務進行談判并簽訂合同。

　　7.3.2 作為修改控制機制的一部分，供方可以請求修改合同。

　　7.4 編制計劃
　　此項活動含有下述任務：

　　7.4.1 為了保證交付的系統、產品或服務的質量，供方應當全面評審合同中的系統獲取需求，以確定管理和保證項目的框架。

　　7.4.2 供方應當確定或選擇與項目的范圍、規模和復雜性相適合的軟件生存周期模型。應當把從本標準中選出的過程、活動和任務影射到該生存周期模型中。該生存周期模型應當包括可使用的開發環境，其中包括標準、方法和工具等。

　　7.4.3 供方應當規定管理和保證此項目的計劃需求。這種規定最好包括對資源的需求和需方的介入。

　　7.4.4 計劃需求一旦規定，供方應當根據風險分析，為開發該產品或提供該服務選擇方案。
　　可供選擇的方案有：
　　a.利用內部資源開發產品或提供服務；
　　b.用子合同方式開發產品或提供服務；
　　c.從內部或外部來源獲得現貨產品；
　　d.上述a、b二條結合。

　　7.4.5 供方應當以所計劃的需求和第7.4.4條中規定的可選方案為基礎制定項目管理計劃，并將其寫成文檔。
在這些計劃中應當規定下述事項：
　　a. 項目的組織機構，以及包括外部機構在內的每個機構的權利和責任；
　　b.開發環境，包括測試環境。庫、設備、儀器以及工程標準、步驟和工具；
　　c.生存期過程和活動的工作細目的結構，其中包括可交付的產品，與任務有關的經費預算、人員。物理資源、軟件的規模以及時間進度；
　　d.系統的質量需求管理。如果需要，可以另外制訂質量保證計劃；
　　e.系統安全和保密的關鍵需求管理。如果需要，另外制訂安全和保密計劃；
　　f.分包商的管理，其中包括對分包商的選擇。如果選擇了分包商，還包括分包商一需方的介入；
　　g.需方的介入，即按合同要求進行的評審和審計（見第11.3條）、非正式的會面、報告、修改和變更的實施、批準、驗收、對設施的使用等；
　　h.驗證和確認（見第11.4條），規定中應包括與獨立的驗證和確認機構接觸的方法；
　　i.質量保證（見第 11.5條）；
　　j.風險管理，此項管理包括對項目的潛在技術、成本和進度諸風險領域的管理；
　　k.保密方針，即在每個項目組織層次上有關“需要知道”和“接觸信息”的規則；
　　l.規則所要求的批準、證書、專有權利等； m.制定計劃、跟蹤和報告的方法；
　　n.人員培訓（見第 11. 7條）。

　　7.5 執行和控制
　　此項活動包括下述任務：

　　7.5.1 供方應當實施和執行使第7.4條制訂的項目計劃。

　　7.5.2 供方應當分別根據開發過程（第8章）、操作過程（第9章）或維護過程（第10章）開發、操作或維護軟件。

　　7.5.3 供方應當在合同所定的整個生存周期內監督和控制項目產品或服務的進展和質量。這應當是一個連續的、反復進行的任務，它應當提供：
　　a.監督技術性能、成本和進度的進展情況，報告項目的狀況；
　　b.問題的識別、記錄、分析和解決。

　　7.5.4 供方應當管理和控制分包商，向其傳達全部必要的合同需求，以保證交給需方的所有的產品或服務都符合主合同的要求。

　　7.6 評審和評價
　　此項活動包括下述任務：

　　7.6.1 在適當的情況下，供方最好根據合同進行評審活動、與需方進行接觸和通信。

　　7.6.2 供方應當進行或支持非正式的會面、驗收評審和驗收測試，按照合同和項目計劃的規定與需方一起進行合同所要求的評審和正式的審計。審計應當按照第11。3條進行。

　　7.6.3 供方應當向需方提供關于評價、評審、審計、測試、改正工作和解決問題的報告。

　　7.6.4 為了按照合同和項目計劃的規定評審產品或服務，供方應當讓需方使用供方和分包商的設備。

　　7.6.5 供方應當按照合同和項目計劃的規定，與獨立的驗證和確認機構或測試機構（見第11.4條）進行接觸。

　　7.6.6 供方應當根據11.5條實施項目的質量保證。實施軟件的質量保證時可以用ISO 9003—87或其它類似的指南。

　　7.7 交付和完成
　　此項活動包括下述任務：

　　7.7.1 供方應按照合同的規定交付系統。

　　7.7.2 供方應當對已交付的系統向需方提供支持。

　　7.7.3 供方應當考察需方對已交付的系統是否滿意。

　　8 開發過程

　　開發過程包括開發者的活動和任務。此過程包括需求分析、設計、編碼、集成、測試、軟件安裝和驗收等活動。完成下面所列出的全部活動。按照合同，軟件開發者的責任從軟件需求分析開始，以軟件鑒定測試終止。但是，通常軟件是作為整個系統的一部分實現的。軟件的需求分析與整個系統需求分析、系統設計有關，故軟件開發者有可能要參加系統需求分析。系統設計，或從系統需求分析、系統設計中獲取必要的信息。軟件鑒定測試完成后，還要把軟件集成到整個系統中去。所以，本過程列出了系統的開發過程所包含的所有活動。軟件開發者按照合同的規定來確定此過程所包含的活動。開發者也可以完成需方所要求的其它活動。

　　此過程由下述活動組成：
　　a.建立過程；
　　b.系統需求分析；
　　c.系統設計；
　　d.軟件需求分析；
　　e.軟件體系結構設計；
　　f.軟件的詳細設計；
　　g.軟件編碼；
　　h.軟件集成；
　　i.軟件鑒定測試；
　　j.系統集成；
　　k.系統鑒定測試；
　　l.驗收所需要的安裝和支持。

　　8.1 建立過程
　　此項活動含有下述任務：

　　8.1.1 開發者應當將開發過程的活動映射到為軟件項目所建立的生存周期模型中。如果沒有建立一個生存周期模型，就應當建立一個。所選擇的活動可以是重疊的或相互有關聯的，而且也可以反復交替地一實施。

　　8.1.2 開發者應當實施第11章指定的支持過程，這些過程是按照第6.2.2條的決定支持開發活動所必須的。

　　8.1.3 如果在合同中沒有約定，開發者應當選擇、剪裁和使用適當的內部的標準、方法、步驟和計算機編程語言，這些是由開發者的組織為了實施開發活動和支持各種過程已用文檔建立起來的。

　　8.1.4 開發者應當制訂進行開發過程的活動計劃。該計劃應當包括與開發和鑒定的全部需求（包括安全和保密需求）有關的特定的標準、方法、行為和責任。如果需要，要分別制訂計劃。這些計劃應當形成文檔并得到實施。

　　8.1.5 在軟件的開發或維護中可以使用不交付項。但是，應當保證：
　　a.在可交付軟件交給需方之后，它的操作和維護與這些不交付項無關；
　　b.這些項變成可交付項。

　　8.2 系統需求分析
　　此項活動含有開發者應當執行或支持的下述任務：

　　8.2.1 如第6.1和6.2條所規定，應當對獲取和系統的要求進行分析，以建立系統需求。系統需求應當說明：系統的功能和性能；安全、保密、人機工程、接口、操作和維護需求；設計限制和鑒定的要求。這些系統需求應當寫成文檔。

　　8.2.2 應當對這些系統需求進行評價，使其包括下述準則：可跟蹤性；與獲取及系統要求的一致性；可測試性；以及設計、操作和維護的可行性。

　　8.3 系統設計
　　此項活動含有開發者應當執行和支持的下述任務：

　　8.3.1 應當建立一個高層的系統體系結構。應當在系統的體系結構中體現系統的需求，該系統體系結構要表現出系統的內部結構以及硬件、軟件和人工操作的配置。應當保證：系統需求已完全分配給硬件配置項（HCI）、軟件配置項（SCI）和人工操作。分配給 HCI、 SCI和人工操作的系統體系結構和系統需求要寫成文檔。

　　8.3.2 應對HCI、SCI和人工操作的系統體系結構和需求進行評價，使其包括下述準則：可跟蹤性、與系統需求的一致性、設計和所用標準恰當，以及操作和維護的可行性。

　　8.4 軟件需求分析
　　對于每個SCI，此項活動含有開發者應當執行的下述任務：

　　8.4.1 開發者應當確定各種需求并將其寫成文檔，其中包括與第2.5條相一致的質量特性規格說明（可操作性、可靠性、可用性、有效性、可維護性和可移植性）。
　　該文檔描述：
　　a.功能和能力規格說明，其中包括性能、物理特性、運行軟件的環境條件；
　　b.用戶文檔；
　　c.安全規格說明，其中包括與操作和維護的方法、環境影響和人員傷害有關的說明；
　　d.保密規格說明，其中包括對敏感性信息或資料的危害有關的說明；
　　e.人機工程和人一機規格說明，其中包括與人工操作、人機對話、對人員的限制有關的規格說明，以及那些對于人的錯誤和能力很敏感的、需要人集中注意力的領域的說明；
　　f.處理器、存儲設備或數據通道所用的硬件處理和資源儲備的規格說明；
　　g.數據定義和數據庫的需求；
　　h.已交付軟件在操作和維護現場上的安裝和驗收的需要；
　　i.用戶操作和執行的需求；
　　j.用戶維護需求。

　　8.4.2 開發者應當確定SCI的外部接口的需求并將其寫成文檔。

　　8.4.3 開發者應當對SCI的鑒定要求寫成文檔。

　　8.4.4 開發者應當對需求作出評價，使其包括下面指出的準則：
　　a.對系統需求和系統設計的可跟蹤性；
　　b.與系統需求的外部一致性；
　　c.各種軟件需求之間的內部一致性；
　　d. 軟件需求的可測性；
　　e.軟件需求的測試范圍；
　　f.軟件設計、操作和維護的可行性。

　　8.4.5 開發者應當依據第11.3條進行合同所要求的評審，以決定軟件需求的完善和恰當。當評審完成時，就應當建立SCI需求的基線。

　　8.5 軟件體系結構設計
　　對于每個SCI，此項活動含有開發者應當執行的下述任務：

　　8.5.1 開發者應當把SCI的工程需求轉變為一個體系結構，該體系結構應描述它的頂層結構和定義它的主要部分。它應當保證此項工程和SCI的鑒定要求已完全分配給了各個部分，并對其進行了細化以便進行詳細設計。應當建立SCI體系結構的文檔。

　　8.5.2 開發者應當為SCI外部接口的設計、SCI的各軟件部分之間的設計建立一個頂層的設計文檔。

　　8.5.3 開發者應當為數據庫建立一個頂層的設計文檔。

　　8.5.4 開發者應當評價SCI的體系結構、接口和數據庫的設計，使其包括下面指出的各項：
　　a. 對SCI需求的可跟蹤性；
　　b.與SCI需求的外部一致性；
　　c.各部分需求之間的內部一致性；
　　d.所使用的設計方法和標準是否恰當；
　　e.詳細設計、操作和維護的可行性。

　　8.5.5 開發者應當依據第11.3條進行合同所要求的評審，以決定分配給各部分的需求和 SCI體系結構設計方法的完善和恰當。

　　8.6 軟件的詳細設計
　　對于每個SCI，此項活動含有開發者應當執行的下述任務：

　　8.6.1 開發者應當詳細設計SCI的每個軟部件。應當盡量地將各個軟部件詳細劃分為含有軟件單元的較低的層次，以便進行編碼、編譯和測試。應當保證該軟件的需求已完全分配給從軟部件到軟件單元的整個軟件。應當把該詳細設計寫成文檔。

　　8.6.2 開發者應當寫出與SCI的外部接口、各軟部件之間和各軟件單元之間的詳細設計文檔。接口的詳細設計應當足夠詳細以便于編碼。

　　8.6.3 開發者應當寫出數據庫的詳細設計文檔。

　　8.6.4 開發者最好寫出軟件用戶手冊的最初版本。

　　8.6.5 開發者應當為測試軟件單元規定測試要求和時間進度，并將其寫成文檔。測試要求中最好包括在軟件需求限定上的重點軟件單元。

　　8.6.6 開發者應當為軟件的集成規定測試要求和時間進度，并將其寫成文檔。

　　8.6.7 開發者應當評價軟件的詳細設計和測試要求，使其包括下面的準則：
　　a. 對SCI需求的可跟蹤性；
　　b.與體系結構設計的外部一致性；
　　c.各部件和單元的需求之間的內部一致性；
　　d.所使用的設計方法和標準是否恰當；
　　e.測試、操作和維護的可行性。

　　8.6.8 開發者應當依據第11.3條進行合同所要求的評審，以決定分配給各個部分和單元的需求以及 SCI詳細設計方法是否完善和恰當。

　　8.7 軟件編碼
　　對于每個SCI，此項活動含有開發者應當執行的下述任務：

　　8.7.1 開發者應當進行下述開發并建立文檔：
　　a.開發每個軟件單元和數據庫；
　　b.為測試每個軟件單元和數據庫而開發的測試過程和數據；
　　c.為進行軟件集成而開發的測試過程和數據。

　　8.7.2 開發者應當測試每個軟件單元和數據庫，以保證它們符合需求。測試結果應當寫成文檔。

　　8.7.3 必要時，開發者應當更新軟件的用戶手冊。

　　8.7.4 開發者應當評價軟件的代碼和測試結果，使其包括下面的準則：
　　a. 對SCI需求和設計的可跟蹤性；
　　b.與 SCI需求和設計的外部一致性；
　　c.各單元需求之間的內部一致性；
　　d.各單元的測試范圍；
　　e.使用的編碼方法和標準是否恰當；
　　f.集成、操作和維護的可行性。

　　8.8 軟件集成
　　對于每個SCI，此項活動含有開發者應當執行的下述任務：

　　8.8.1 開發者應當制訂計劃把各個軟件單元和軟部件集成為SCI。該計劃應當包括測試要求、步驟、數 據、責任和時間表。該集成計劃應當寫成文檔。

　　8.8.2 在依據集成計劃開發集合體時，開發者應當集成軟件的單元、部件和進行測試。應當保證每個集 合體都能滿足SCI的需求，并且在集成活動結束時形成完全集成的SCI。集成和測試的結果應當寫成文 檔。

　　8.8.3 必要時，開發者應當更新用戶手冊。

　　8.8.4 為了進行軟件的鑒定測試，開發者應當為每個SCI開發寫出一個完整的測試集、測試用例（輸 入、輸出、測試準則）和測試步驟。開發者應當保證集成后的SCI可以進行軟件鑒定測試。

　　8.8.5 開發者應當對集成計劃、設計、代碼、測試、測試結果和用戶手冊進行評價，使其包括下面的準 則：
　　a. 對 SCI需求的可跟蹤性；
　　b.與 SCI需求的外部一致性；
　　c.內部一致性；
　　d.SCI需求的測試范圍；
　　e.使用的測試方法和標準是否恰當；
　　f.是否符合預期的結果；
　　g.鑒定測試、操作和維護的可行性。

　　8.8.6 開發者應當依據第11.3條進行合同所要求的評審，以確定測試過程的完善和適當，并確定已經 做好軟件鑒定測試的準備。

　　8.9 軟件鑒定測試
　　對于每個SCI，此項活動含有開發者應當執行的下述任務：

　　8.9.1 開發者應當依據為 SCI確定的鑒定要求進行鑒定測試。應當保證對每項要求進行符合測試。應將鑒定測試結果寫成文檔。

　　8.9.2 必要時，開發者應當更新用戶手冊。

　　8.9.3 開發者應當對設計、代碼、測試、測試結果和用戶手冊進行評價，使其包括下面的準則：
　　a. 對SCI和系統需求的可跟蹤性；
　　b.與 SCI和系統需求的外部一致性；
　　c.內部一致性；
　　d.SCI和系統需求的測試范圍；
　　e.是否符合預期結果；
　　f.操作和維護的可行性。

　　8.9. 4 開發者應當依據第 11. 3條支持對 SCI的功能性配置審計（FCA）和物理配置審計（PCA）。在 FCA時，應當保證SCI的測試成功并符合需求，而且用戶手冊中充分描述SCI的操作和支持。在PC：A 時，應當保證SCI的設計和源碼完整并正確，反映了SCI的新技術。FCA和PCA的結果應當寫成文檔。如果同時開發硬件和軟件，FCA和PCA可以推遲到系統鑒定測試時進行。

　　8.9.5 在FCA和PCA成功地完成之后，開發者應當：
　　a.為系統集成、系統鑒定測試或適當時的安裝和驗收，更新和準備可交付的軟件；
　　b.為SCI的設計和編碼建立一個基線。

　　8.10 系統集成
　　此項活動含有開發者應當執行或支持的下述任務：

　　8.10.1 SCI應當與 HCI、人工操作和其它必要的系統一起集成到系統中去。當開發該集合體時，應當對照它們的需求進行測試。應當將集成和測試的結果寫成文檔。

　　8.10.2 應當為系統的每項已確定的需求進行系統鑒定測試開發一個完整的測試集、測試用例（輸入。輸出、測試準則）和測試步驟，并將其寫成文檔。開發者應當保證集成的系統已做好系統鑒定測試的準備。 8.10.3應當對集成的系統進行評價以使其包括下述準則：系統需求的測試范圍。、所使用的測試方法和標準是否恰當；是否符合預期結果；鑒定測試、操作和維護的可行性。

　　8.11 系統鑒定測試
　　此項活動含有開發者應當執行或支持的下述任務：

　　8.11.1 應當依據為系統建立的鑒定要求進行系統鑒定測試。應當保證每項系統需求都進行符合性測試，而且系統已做好交付準備。應當把鑒定測試的結果寫成文檔。

　　8.11.2 應當對系統進行評價以使其包括下述準則：系統需求的測試范圍；是否符合預期的結果；操作與維護的可行性。

　　8.11.3 本項需求不適用于已經進行過 FCA、PCA的 SCI。 SCI的 FCA和 PCA應當依據第 11.3條進行。在成功地完成FCA和PCA后，
　　a. 可交付的SCI應當更新并做好驗收安裝和支持的準備；
　　b.應當為每個SCI的設計和代碼建立基線。

　　8.12 驗收所需要的安裝和支持
　　此項活動含有下述開發者應當執行的任務：

　　8.12.1 開發者應當制定一個合同中指明的、在目標環境中安裝軟件的計劃。應當指出與軟件的安裝有關的必要的資源和信息并保證提供。開發者應當以適當的方式幫助需方得到與系統建立活動有關的信息。當所安裝的軟件替代了現有的系統時，開發者應當支持合同所要求的并行運行的活動。應當將安裝情況寫成文檔。

　　8.12.2 開發者應當依據安裝計劃安裝軟件。應當保證該軟件和數據庫能按照合同的規定初始化、執行和終止。應當把安裝情況及其結果寫成文檔。

　　8.12.3 開發者應當支持需方對軟件（或系統）的驗收評審和測試。驗收評審和測試應當考慮 FCA、 PCA、軟件鑒定測試和系統鑒定測試（如果進行系統鑒定測試）的結果。應當把驗收評審和測試的結果寫成文檔。

　　8.12.4 開發者應當按照合同的規定完成文檔和編碼并交付給需方。

　　8.12.5 開發者應當按照合同的規定向需方提供初始的和繼續的培訓和支持。

原文轉自：http://www.kjueaiud.com