某軟件公司質(zhì)量管理體系

1、秘密僅限于內(nèi)部使用質(zhì)量管理體系培訓教材（一）北京博思美亞科技發(fā)展公司公司標準軟件過程體系文件導讀0.軟件生命周期模型1.4.軟件開發(fā)過程2.4.技術(shù)類評審1.1. 0項目估算指南1.4. 6標準軟件過程總體裁剪指南1.52公司標準軟過程體系文導讀目錄1、概述 1.1.1 目的 1.1.2 適用范圍1.1.3 引用文1.1.4 術(shù)語 1.1.5 參考資料1.2、公司標準軟過程的開發(fā)2.2.1 開發(fā)歷程2.2.2 公司標準軟過程總體結(jié)構(gòu)5.3、軟過程體系文9.3.1 過程管理9.3.2 軟開發(fā)過程1.13.3 項目管理1.1.3.4 資源管理1.2.3.5 指南性文1.3.1、概述1.1 目的本文

2、件對公司軟件過程及其體系文件的總體結(jié)構(gòu)進行描述，為與軟件過程的開發(fā)、維護、改進、執(zhí)行、管理和跟蹤等有關(guān)的人員學習、理解和使用軟件過程體系文件提供指南。1.2 適用范圍適用于SEPG、高層經(jīng)理、項目經(jīng)理、軟件開發(fā)人員、測試人員、軟件質(zhì)量保證人員、軟件配置管理人員及其他支持人員為了按規(guī)范開展各自的業(yè)務活動，學習、理解和使用軟件過程體系文件。1.3 引用文件無。1.4 術(shù)語無。1.5 參考資料? Software Project Management Guidebook( Version 2.0) ， Process Strategie，s Inc.?軟件工程實踐者的研究方法，(美)Roger S.

3、 Pressman®,黃柏素、梅宏譯，機械工業(yè)出版社出版，1999年 10月?實踐中的CMM INFOSYS 公司實施軟件項目之過程，潘卡?杰羅特著，楊慧鳴、李光龍澤，2001 年 7 月2、公司標準軟件過程的開發(fā)2.1開發(fā)歷程為了使軟件過程保持長期穩(wěn)定并能持續(xù)改進， 必須開發(fā)組織（即公司）級的 標準軟件過程。為此，公司組織了以軟件工程過程組（SEPG）為主體的標準軟件過程開發(fā)和文件編寫組，具體實施上述任務。公司標準軟件過程是在公司范圍 內(nèi)的軟件項目全面執(zhí)行CMM二級的基礎上，在軟件工程一般理論的指導下，收 集公司全部軟件項目所采用的軟件過程，經(jīng)過分析、歸納、提煉、分類、總結(jié)等 一系

4、列步驟開發(fā)而成；又在開發(fā)標準軟件過程的基礎上，形成了描述這些標準軟 件過程的相互關(guān)聯(lián)的程序文件體系。本程序文件體系對組成標準軟件過程的基本軟件過程要緊，以及軟件過程要素之間的關(guān)系（軟件過程結(jié)構(gòu)）進行描述，描述的重點放在過程的可操作性上。 此外，與此相關(guān)聯(lián)，開發(fā)或編寫了公司的軟件過程數(shù)據(jù)庫、與軟件過程相關(guān)的文 檔庫、軟件生命周期描述文件和標準軟件過程裁剪指南。它們和公司標準軟件過 程一起，組成了公司的軟件過程資產(chǎn)。公司的軟件過程資產(chǎn)為規(guī)范公司軟件項目的軟件過程提供了基礎和保證。 各 軟件項目按標準軟件過程裁剪指南， 根據(jù)項目的實際情況（主要是客戶需求）對 公司標準軟件過程進行裁剪，開發(fā)適合項目特

5、定特性的項目軟件過程； 項目軟件 過程開發(fā)的重點在軟件過程的可用性， 以及附加到該項目的價值。項目以項目定 義的軟件過程為基礎，制訂項目軟件開發(fā)計劃；按計劃執(zhí)行項目的軟件開發(fā)活動， 產(chǎn)生相應的軟件工作產(chǎn)品及其他開發(fā)成果； 開發(fā)過程中的數(shù)據(jù)以及項目結(jié)束后進 行總結(jié)的數(shù)據(jù)，經(jīng)過一定的手續(xù)，反饋到公司的軟件過程數(shù)據(jù)和軟件過程相關(guān)文 檔庫，豐富公司的軟件過程資產(chǎn)。如此反復循環(huán)，促使軟件過程得以持續(xù)改進。以上過程和關(guān)系可以用圖1表示。圖中：|表示實體,例如分配到軟件的需求”|表示活動,例如 選擇項目的軟件生命周期”圖中上半部分用粗線框圍起來的部分即公司的軟件過程資產(chǎn)部分，它由描述 公司標準軟件過程的程序

6、文件、 軟件過程數(shù)據(jù)庫、與軟件過程相關(guān)的文檔庫、軟件生命周期描述文件和標準軟件過程裁剪指南組成。下半部分則描述公司軟件過程資產(chǎn)的利用過程： 軟件項目按標準軟件過程裁 剪指南，根據(jù)項目的實際情況（主要是客戶需求）對公司標準軟件過程進行裁剪， 開發(fā)適合項目特定特性的項目軟件過程； 制訂項目軟件開發(fā)計劃，并按計劃執(zhí)行 項目的軟件開發(fā)活動；將項目數(shù)據(jù)（包括開發(fā)過程中的數(shù)據(jù)以及項目結(jié)束后進行 總結(jié)的數(shù)據(jù)）反饋到公司的軟件過程數(shù)據(jù)庫和軟件過程相關(guān)文檔庫。1 公司軟件過程資產(chǎn)的開發(fā)和利用2.2 公司標準軟件過程總體結(jié)構(gòu)圖 2 為公司標準軟件過程的總體結(jié)構(gòu)。由于本公司的產(chǎn)品（項目） 除了純軟件產(chǎn)品（項目）外，

7、還包括軟件和硬件兼有的產(chǎn)品（項目），考慮到過程的完整性以及便于理解軟件過程和其他過程之間的接口關(guān)系，圖中的項目開發(fā)過程反映了軟件和硬件兼有的產(chǎn)品的整個開發(fā)過程，但其中非軟件過程部分均采用虛線，以示區(qū)別。有關(guān)內(nèi)容說明如下：（ 1）項目、項目生命周期和軟件生命周期項目是由一組有起止日期、相互協(xié)調(diào)的受控活動組成的獨特過程，該過程要求達到符合包括時間、成本和資源等約束條件在內(nèi)的規(guī)定要求的目標，其結(jié)果將產(chǎn)生產(chǎn)品。而軟件項目則是為了開發(fā)軟件產(chǎn)品（包括系統(tǒng)）而建立的項目。項目和產(chǎn)品都具有一定的生命周期。項目生命周期是指從項目啟動到項目結(jié)束為止的時間間隔。項目生命周期一般包括：?初期策劃階段（主要是可行性分析

8、）；?開發(fā)策劃階段（開發(fā)前的人、財、物等的計劃和準備）；?實施階段（具體實施項目開發(fā)計劃，保證項目的質(zhì)量、成本、進度的順利完成） ；?結(jié)束階段（評審、鑒定及項目交付和組織結(jié)束工作）。在整個項目生命周期，所涉及的過程可以分為兩類：?項目開發(fā)過程（和被開發(fā)產(chǎn)品的實現(xiàn)直接相關(guān)）；?項目管理過程（對項目的開發(fā)過程進行管理和控制）。軟件生命周期則是指軟件產(chǎn)品的生命周期，即是指從設想軟件產(chǎn)品開始到軟件不再供使用為止的時間間隔。軟件生命周期一般包括：概念階段、需求階段、設計階段、實現(xiàn)階段、測試階段、安裝和調(diào)整階段、運行和維護階段，有時還包括退役階段。顯然， 項目生命周期和軟件生命周期在時間上是相關(guān)的，但在概

9、念上是完全不同的。項目生命周期不會超過該項目所開發(fā)的軟件產(chǎn)品的生命周期。（ 2）項目開發(fā)過程圖中的下部表示項目的開發(fā)過程。它從客戶需求開始，通過系統(tǒng)分析，將客戶需求分解成軟件部分的需求和硬件部分的需求（從此處項目將分成軟件項目和硬件項目兩部分）。其中，軟件項目從軟件需求定義階段、設計階段、實現(xiàn)階段、測試階段、驗收交付階段到項目總結(jié)，表示整個軟件開發(fā)的結(jié)束。一般來說，作為軟件開發(fā)項目到此就意味著結(jié)束了，但軟件產(chǎn)品的生命周期并未結(jié)束。軟件產(chǎn)品交付后，將經(jīng)歷使用過程中的維護階段（維護階段的時間可能和項目合同有關(guān)） ，直到最后產(chǎn)品退役。（ 3）項目管理過程圖中的中部表示項目的管理過程，即對項目的開發(fā)過

10、程實施管理的過程。對于軟件和硬件兼有的項目來說，項目管理的主要過程如下：?初期策劃（主要針對系統(tǒng)分析、可行性分析進行策劃）；?開發(fā)策劃（開發(fā)前的人、財、物等的計劃和準備）；?項目跟蹤與監(jiān)控（對項目初期的系統(tǒng)分析、可行性分析，以及項目開發(fā)過程中軟件需求定義、設計、實現(xiàn)、測試、驗收交付等活動進行跟蹤與監(jiān)控）；球件質(zhì)量保證（SQA,對項目的軟件過程和軟件產(chǎn)品的符合性進行質(zhì)量監(jiān)控，它貫穿于軟件項目的始終）；球件配置管理（SCM,為確保軟件產(chǎn)品的完整性和正確性進行的管理，它貫穿于軟件項目的始終）；?需求管理（為確保滿足客戶需求進行的管理，它貫穿于項目的始終）；?評審過程（包括同行評審等技術(shù)類評審和計劃評

11、審等管理類評審）；?項目結(jié)束處理（包括項目的鑒定、驗收、交付，以及進行項目總結(jié)）。此外，在項目管理活動中，還可能有以下管理過程：?項目培訓；?組間協(xié)調(diào)等。（ 4）過程資產(chǎn)本公司的軟件過程資產(chǎn)分兩個層次：公司級資產(chǎn)和項目級資產(chǎn)。a. 公司級資產(chǎn)包括：?過程數(shù)據(jù)庫（含軟件過程和其他過程的資產(chǎn)）；?過程相關(guān)文檔庫；?人力資源庫。b. 項目級資產(chǎn)包括：?項目控制數(shù)據(jù)庫（項目經(jīng)理控制，用于保存項目數(shù)據(jù)，以便對項目進行跟蹤與監(jiān)控）；?SQA管理庫（SQA控制，用于保存項目的軟件質(zhì)量保證數(shù)據(jù)）； ?SCM管理庫（SCM控制，用于保存項目的軟件配置管理數(shù)據(jù)）； ?SCM庫（SCM控制，用于保存項目的所有配置項

12、）。通過一定的手續(xù)，項目的項目控制數(shù)據(jù)庫和SQA 管理庫中的數(shù)據(jù)，經(jīng)過選擇，將補充到公司的過程數(shù)據(jù)庫和過程相關(guān)文檔庫中。此外，根據(jù)實際需要，總部一級也可能需要有人力資源庫。2 軟件過程結(jié)構(gòu)圖3、軟件過程體系文件公司的軟件過程體系文件的組成如圖 3所示。圖3軟件過程體系文件按文件的使用目的，公司的軟件過程體系文件分為五類： 過程管理、軟件開 發(fā)過程、項目管理、資源管理和指南。3.1過程管理過程管理是指對軟件過程進行管理，此類文件的使用人員主要是對軟件過程進行開發(fā)、維護、改進的人員，例如SEPG 成員、項目經(jīng)理、SQA 等。有關(guān)文件說明如下：（ 1）標準軟件過程開發(fā)與維護秋用人員：SEPG和軟件過

13、程描述文件編寫人員。?內(nèi)容提要：本文件對如何開發(fā)和管理公司的標準軟件過程、如何編寫軟件過程描述文件、如何編寫標準軟件過程裁剪指南等作出了規(guī)定。（ 2）過程描述文件編寫規(guī)范（一）?使用人員：軟件過程描述文件編寫人員。?內(nèi)容提要：為能分解成若干過程元素的較大過程編寫的描述文件編寫規(guī)范。（ 3）過程描述文件編寫規(guī)范（二）?使用人員：軟件過程描述文件編寫人員。?內(nèi)容提要：為沒有明顯的入口和出口準則的過程（例如日常管理類的過程）編寫的描述文件編寫規(guī)范。（ 4）質(zhì)量管理體系數(shù)據(jù)庫管理和維護文件秋用人員：SEPG項目經(jīng)理、SQA和數(shù)據(jù)庫的管理和維護人員。?內(nèi)容提要：本文件對公司的軟件過程數(shù)據(jù)庫和與過程相關(guān)文

14、檔庫的管理和維護作出了規(guī)定?？紤]到將來需要擴充ISO9001 要求的其他數(shù)據(jù)庫，故起此名。（ 5）軟件生命周期模型描述文件?使用人員：項目經(jīng)理以及參與項目軟件過程定義的有關(guān)人員。?內(nèi)容提要：本文件對公司所確定的軟件生命周期模型進行描述，作為公司的過程資產(chǎn)之一，供項目選擇適合項目情況的軟件生命周期模型時參考。（ 6）標識規(guī)范?使用人員：對被標識對象進行標識的人中員。?內(nèi)容提要：為規(guī)范包括文件、表格、產(chǎn)品的標識而制訂的規(guī)范。（ 7）術(shù)語秋用人員：SEPG和軟件過程描述文件編寫人員。?內(nèi)容提要：本文件定義了本軟件過程體系文件所使用的專用術(shù)語。（ 8）文件控制程序?使用人員：文件管理人員。?內(nèi)容提要：

15、本文件對文件的編寫、評審、批準、發(fā)布、發(fā)放、回收等文件管理要求作出了規(guī)定，是整個質(zhì)量管理體系所要求的用于對受控文件進行管理的文件。3.2 軟件開發(fā)過程軟件開發(fā)過程是指與軟件開發(fā)有關(guān)的過程，相關(guān)文件的使用人員主要是和軟件開發(fā)有關(guān)的人員。（ 9）軟件開發(fā)過程程序文件?使用人員：項目經(jīng)理以及參與項目軟件過程定義的有關(guān)人員。?內(nèi)容提要：本程序文件針對本公司軟件項目所采用的典型開發(fā)過程，分解成過程要素進行描述，供各軟件項目根據(jù)標準軟件過程裁剪指南，定義項目自己的軟件過程時使用。3.3 項目管理與項目管理有關(guān)的文件如下：（ 10）客戶需求管理程序文件?使用人員：項目經(jīng)理、SQA、 SCM 和軟件開發(fā)人員。

16、?內(nèi)容提要：本文件是為了確保項目滿足客戶需求和如何確保滿足客戶需求，為項目編寫的有關(guān)客戶需求管理的程序文件。（ 11）項目策劃程序文件?使用人員：項目經(jīng)理以及參與項目策劃的其他有關(guān)人員。?內(nèi)容提要：為指導軟件項目進行項目的初期策劃和開發(fā)策劃而編寫的程序文件。（ 12）項目跟蹤與監(jiān)控程序文件?使用人員：高層經(jīng)理、項目經(jīng)理、SQA、 SCM 和軟件開發(fā)人員。?內(nèi)容提要：指導軟件項目在項目計劃執(zhí)行過程中如何對項目進行跟蹤與監(jiān)控的程序文件。（ 13）項目總結(jié)程序文件?使用人員：項目經(jīng)理、SQA、 SCM 和軟件開發(fā)人員。?內(nèi)容提要：指導軟件項目在項目結(jié)束階段如何進行項目總結(jié)的程序文件。（ 14）軟件質(zhì)

17、量保證程序文件秋用人員：SQA、項目經(jīng)理、SCM和軟件開發(fā)人員。?內(nèi)容提要：指導軟件項目的SQA 如何執(zhí)行項目的軟件質(zhì)量保證活動，以及項目的其他人員如何配合的程序文件。（ 15）軟件配置管理程序文件秋用人員：SCM、項目經(jīng)理、SQA和軟件開發(fā)人員。?內(nèi)容提要：指導軟件項目的SCM 如何執(zhí)行項目的軟件配置管理活動，以及項目的其他人員如何配合的程序文件。（ 16）組間協(xié)調(diào)程序文件?使用人員：項目經(jīng)理、SQA、 SCM 和軟件開發(fā)人員。?內(nèi)容提要：項目在進行項目策劃時，應考慮有無組間協(xié)調(diào)的情況，本程序文件提供這方面的要求和指導。（ 17）技術(shù)類評審程序文件?使用人員：項目經(jīng)理、軟件開發(fā)人員、SQA

18、以及其他參與評審的人員。?內(nèi)容提要：本程序文件為項目進行技術(shù)類評審（包括同行評審及其他類型的技術(shù)評審）規(guī)定要求和提供指導。（ 18）高層驗證程序文件?使用人員：高層經(jīng)理、項目經(jīng)理、SQA、 SCM 和軟件開發(fā)人員。?內(nèi)容提要：在公司標準軟件過程的開發(fā)和改進以及項目在執(zhí)行軟件開發(fā)活動的過程中，高層經(jīng)理應在哪些環(huán)節(jié)進行驗證，如何進行驗證？項目的有關(guān)人員如何配合？本程序文件為高層經(jīng)理的驗證活動提出要求并提供指導。3.4 資源管理資源管理主要包括人力資源、設備、環(huán)境等方面的管理。（ 19）培訓程序?使用人員：公司培訓組、高層經(jīng)理、項目經(jīng)理、SQA、 SCM 和軟件開發(fā)人員。?內(nèi)容提要：對公司級培訓和項

19、目級培訓的實施要求作出規(guī)定，包括培訓需求的收集、培訓計劃、培訓實施和培訓總結(jié)等。3.5 指南性文件目前提供以下指南性文件：（ 20）項目估算指南?使用人員：項目經(jīng)理及其他參與估算的人員。?內(nèi)容提要：本指南為項目估算的方法（例如：規(guī)模估算、工作量估算等）提供指南。（ 21）標準軟件過程總體裁剪指南?使用人員：項目經(jīng)理及其他參與項目軟件過程定義的人員。?內(nèi)容提要：總體裁剪指南是公司標準軟件過程裁剪指南中的高層裁剪指南（或一般性裁剪指南）。它為軟件項目在對公司標準軟件過程進行裁剪時，提供對一般性活動進行裁剪的指南；裁剪結(jié)果為項目進行詳細的過程裁剪提供框架性的指導方針（詳細裁剪指南分散在各程序文件的“

20、詳細裁剪指南”中）。（ 22）軟件過程體系文件導讀（即本文件）秋用人員：SEPG高層經(jīng)理、項目經(jīng)理、軟件開發(fā)人員、測試人員、軟件質(zhì)量保證人員、軟件配置管理人員等為了按規(guī)范開展各自的業(yè)務活動，需要學習、理解和使用軟件過程體系文件的所有人員。?內(nèi)容提要：對公司標準軟件過程開發(fā)的背景、開發(fā)過程、標準軟件過程的總體結(jié)構(gòu)，以及相應的軟件過程體系文件進行導讀性的說明。軟件生命周期模型目錄1、概述 1.5.1.1 目的 1.5.1.2 適用范圍1.5.1.3 引用文件1.5.1.4 術(shù)語 1.5.1.5 參考資料1.5.2、軟件生命周期模型描述1.62.1 瀑布模型1.6.2.2 原型瀑布模型1.7.2.3

21、 增量模型1.8.2.4 增量的迭代過程模型2.02.5 快速應用開發(fā)模型2.03、幾種模型的比較2.2.4、其它模型采用說明2.2.5、附 2.2.1、概述1.1 目的描述公司級定義的軟件生命周期模型，供項目策劃時根據(jù)項目的具體情況選擇或裁剪使用，由此確定軟件項目開發(fā)過程的各種不同的階段以及各階段的執(zhí)行順序。1.2 適用范圍適用于本公司的軟件項目策劃。1.3 引用文件?軟件開發(fā)過程程序文件( QMS-OP01-V1.0)?標準軟件過程開發(fā)和維護( QMS-PSM01-V1.0)?項目策劃程序文件( QMS-PTM02-V2.0)1.4 術(shù)語?軟件生命周期從軟件設想開始到軟件不再使用而結(jié)束的時

22、間周期。軟件生命周期一般包括系統(tǒng)分析、軟件需求分析、設計、實現(xiàn)、測試、驗收、運行和維護各階段，有時還包括退役階段。?軟件過程有關(guān)開發(fā)和維護軟件及其相關(guān)產(chǎn)品(例如：項目計劃、設計文檔、代碼、測試用例、用戶手冊等)的活動、方法、實踐和變更的集合。1.5 參考資料?軟件工程Java語言實現(xiàn)，Stephen R. SchacK,袁兆山等譯，機械工業(yè)出版社，1999年 9月?軟件工程實踐者的研究方法，Roger S. Pressmanf,黃柏素、梅宏等譯,機械工業(yè)出版社，1999 年 10 月?«Software Project Management Guidebook, Frank J. K

23、och著，2001 年 7 月?實用軟件工程鄭人杰、殷人昆、陶永雷著，清華大學出版社，1997 年4月?軟件需求， Karl E. Wiegers 著，陸麗娜、王忠民、王志敏等譯，機械工業(yè)出版社，2000年 7月?統(tǒng)一軟件開發(fā)過程，Ivar Jacobson Grady Booch、James RumbaughW, 周伯生、馮學民、樊東平等譯，機械工業(yè)出版社，2002年1 月2、軟件生命周期模型描述所有的項目軟件開發(fā)過程都應遵循一個生命周期模型，每個模型都具有能夠幫助實際軟件項目進行控制及協(xié)調(diào)的特征。定義生命周期模型的目的在于將本質(zhì)上無序的活動有序化，在開發(fā)策劃期間，必須仔細考慮項目的特征和目

24、標之后，再選擇生命周期模型。本文件根據(jù)組織內(nèi)項目的類型，描述常用的幾個軟件生命周期模型，項目可根據(jù)實際情況選擇或按規(guī)定剪裁使用，但應注意與公司的標準軟件開發(fā)過程相兼容。見附錄 “軟件過程結(jié)構(gòu)圖”， 其中的項目軟件開發(fā)過程即為一個選擇瀑布模型的典型項目過程。2.1 瀑布模型（ 1）模型描述該模型首先由Royce1970提出，又稱線性順序模型，包括圖21所示的典型的幾個階段，其重要特點是：只有當一個階段的文檔已編制好，且該階段的產(chǎn)品得到 SQA 認可后，該階段才算完成；測試或驗證在每個階段都必須執(zhí)行；一旦產(chǎn)品完成提交用戶，其后的任何修改均屬于維護階段。如果需求明確、能較好理解且較穩(wěn)定，可以考慮選擇

25、瀑布模型。圖 2 1 瀑布模型（ 2）缺點由于其線性順序的特點，故只有在項目開發(fā)的后期才能得到具有全部功能的軟件版本；如果有未定義或未實施的需求，將會引起重復勞動，甚至開發(fā)出的產(chǎn)品不是用戶所需要的。（ 3）本企業(yè)適合的項目類型操作系統(tǒng)產(chǎn)品；譯星產(chǎn)品；嵌入式產(chǎn)品開發(fā)；對日軟件外包項目等。2.2 原型瀑布模型（ 1）模型描述原型模型本身是一個迭代的模型，是為了解決在產(chǎn)品開發(fā)的早期階段存在的不確定性、二義性和不完整性等問題，通過建立原型使開發(fā)者進一步確定其應開發(fā)的產(chǎn)品，使開發(fā)者的想象更具體化，也更易于被客戶所理解。原型只是真實系統(tǒng)的一部分或一個模型，完全可能不完成任何有用的事情，通常包括拋棄型和進化

26、型兩種，拋棄型指原型建立、分析之后要扔掉，整個系統(tǒng)重新分析和設計；進 化型則是對需求的定義較清楚的情形， 原型建立之后要保留，作為系逐漸增加的 基礎，采用進化型一定要重視軟件設計的系統(tǒng)性和完整性，并且在質(zhì)量要求方面沒有捷徑，因此，對于描述相同的功能，建立進化型原型比建立拋棄型原型所花 的時間要多。原型建立確認需求之后采用瀑布模型的方式完成項目開發(fā)，原型+瀑布模型的開發(fā)流程如圖2-2所示：多次迭代原型逐漸完善圖22原型+瀑布模型以下情形建議考慮選擇原型+瀑布模型：a.項目包含一種新技術(shù)，例：新硬件、新的開發(fā)語言、新的系統(tǒng)架構(gòu)等；b.需求不很清楚；c.存在關(guān)于性能、可靠性和可行性方面的主要的、未解

27、決的問題；d.用戶界面對系統(tǒng)成功是很關(guān)鍵的，但不很清楚。(2)缺點由于原型并非最終產(chǎn)品，如果原型不能利用，可能導致成本的增加；同時會 引起客戶的誤解，以為產(chǎn)品即將完成。(3)本企業(yè)適合的項目類型新領(lǐng)域的應用項目的開發(fā)； Web開發(fā)項目等。2.3 增量模型(1)模型描述增量模型是一種進化軟件過程模型，融合了線性順序模型的基本成分(重復 地應用)和原型模型的迭代特征，如下圖所示。當使用增量模型時，第一個增量 往往是核心產(chǎn)品，即實現(xiàn)了基本的需求；核心產(chǎn)品交用戶使用(或進行更詳細的 復審)，使用和/或評估的結(jié)果是下一個增量的開發(fā)計劃，該計劃包括對核心產(chǎn)品 的修改，使其能更好的滿足用戶的需要， 并發(fā)布一

28、些新增的特點和功能。增量模 型和原型模型不一樣，強調(diào)每一個增量均要發(fā)布一個可操作產(chǎn)品。 早期的增量是 最終產(chǎn)品的 可拆卸”版本，但能提供用戶服務功能和用戶評估的平臺。 增量模型 開發(fā)流程見圖2 3。圖2 3增量模型(2)缺點由于增量模型的靈活性，往往容易退化成邊做邊改方法，使軟件過程的控制 喪失了整體性，最終的產(chǎn)品也不是開放的，而是成為維護人員的惡夢。(3)本企業(yè)適合的項目類型各種中、大規(guī)模的項目類型；已有系統(tǒng)技術(shù)路線發(fā)生改變但需求明確的移植 類項目2.4 增量的迭代過程模型(1)模型描述該模型是一個不斷迭代和增量的過程，迭代過程首先要處理一組客戶的業(yè)務 需求，這些業(yè)務需求合起來能夠掘所開發(fā)產(chǎn)

29、品的可用性。其次，迭代過程要解決最突出的風險問題。后續(xù)的迭代過程建立在前一次的迭代過程末期所產(chǎn)生的產(chǎn)品 之一。一個增量不一定是對原有產(chǎn)品的增加， 尤其在生命周期初期，開發(fā)人員可 能用更加詳細和更加完善的設計來代替最初簡單的設計。在較后的階段，增量通常是對原有產(chǎn)品的增加。采用此種模型最好是基于構(gòu)件和有相應的構(gòu)件開發(fā)工具 (如：RUP、配置管理工具等)。迭彳11迭彳t 2迭彳t 3圖24增量的迭代模型(2)缺點需要相當?shù)娘L險評估的技術(shù)；每個迭代循環(huán)控制不好會變成邊做邊改模式(3)本企業(yè)適合的項目類型較復雜的應用項目。2.5 快速應用開發(fā)模型(1)模型描述快速應用開發(fā)模型(RAD)是一個線性順序的軟

30、件開發(fā)模型，強調(diào)極短的 開發(fā)周期(2-3個月)。該模型是線性順序模型的一個 高速”變種，如果需求理 解得很好，且約束了項目范圍，就可通過使用基于構(gòu)件或可得用軟件包的建造方 法獲得快速開發(fā)?？焖賾瞄_發(fā)模型流程見圖 2-5。適用于信息系統(tǒng)應用軟件 的開發(fā)。圖2 5快速應用開發(fā)模型(2)缺點對大型的、但可伸縮的項目，RAD需要足夠的人力以創(chuàng)建足夠的 RAD小組 RAD要求開發(fā)者和用戶在一個很短的時間內(nèi)完成一個系統(tǒng)，如果雙方中的任何 一方?jīng)]完成約定，都會導致 RAD項目失敗。(3)本企業(yè)適合的項目類型具有可重用的構(gòu)件庫和CASE工具的應用項目；信息系統(tǒng)等。3、幾種模型的比較軟件生命周期模型是否首先定

31、義好絕大部分的需求？是否有多個開發(fā)周期？是否有中間軟件發(fā)布瀑布模型有無無原型+瀑布模型沒有有有增量模型有有可能增量的迭代模型沒有有有快速應用開發(fā)模型沒有有可能4、其它模型采用說明如果在實際工作中，基于特定項目的經(jīng)驗積累和總結(jié)，可能需要形成新的軟 件生命周期模型，此時可依照一定的規(guī)程（參見標準軟件過程開發(fā)和維護要求 項目策劃程序文件）將其定義和描述加入到本文件中。5、附錄附錄1軟件過程結(jié)構(gòu)圖說明：圖中 項目軟件開發(fā)過程”一層延伸到產(chǎn)品退役，即體現(xiàn)出軟件的生命 周期。采用不同的生命周期模型在該層面的 系統(tǒng)分析”和 軟件開發(fā)”階段對應不 同的過程。軟件過程結(jié)構(gòu)圖軟件開發(fā)過程目錄1、概述 2.6.1.

32、1 目的 2.6.1.2 適用范圍2.6.1.3 引用文件2.6.1.4 術(shù)語 2.6.1.5 參考資料2.7.2、過程總體描述2.7.2.1 過程概述2.7.2.2 結(jié)構(gòu)描述2.8.2.3 過程級裁剪指南2.9.3、過程元素3.0.3.1 系統(tǒng)分析3.0.3.2 軟件需求分析3.5.3.3 結(jié)構(gòu)設計4.1.3.4 詳細設計4.5.3.5 編碼 5.0.3.6 集成測試5.3.3.7 系統(tǒng)測試5.7.3.8 驗收 6.0.3.9 驗收 6.4.3.10 軟件問題管理6.8.4、附 7.1.附2.31中大型軟件工程項目的標準軟件開發(fā)過程 72附2.32中小型軟件工程項目的標準軟件開發(fā)過程 73附

33、2.33小型軟件工程項目的標準軟件開發(fā)過程7. 4附3.11系統(tǒng)架構(gòu)和業(yè)務需求說明書文檔編寫規(guī)范 75附錄3.12可行性分析報告文檔編寫規(guī)范7. 7附錄3.13系統(tǒng)需求規(guī)格說明書文檔編寫規(guī)范7. 8附錄3.21需求分析方法指南8.4附錄3.22結(jié)構(gòu)化分析法8.5附錄 3.2 3 面向?qū)ο蠓治龇ǎ∣OA） 8.6附錄3.24快速原型法8.7附錄3.25軟件需求規(guī)格說明書文檔編寫規(guī)范8. 8附錄3.26測試計劃文檔編寫規(guī)范9. 2附錄3.31軟件結(jié)構(gòu)設計說明書文檔編寫規(guī)范9. 4附錄3.41軟件詳細設計說明書文檔編寫規(guī)范9. 8附錄3.51測試報告文檔編寫規(guī)范1. 00附錄3.61集成工作單1.0

34、1附錄3.62集成測試工作單1.02附錄3.91軟件維護實施計劃文檔編寫規(guī)范1 03附錄3.10 1軟件問題報告單1.04附錄3.10 2軟件問題狀態(tài)登記表 1.091、概述1.1 目的本程序文件定義了公司內(nèi)部的軟件開發(fā)過程，以指導和規(guī)范軟件項目中開發(fā)過程的定義和相應的實施。1.2 適用范圍整個公司內(nèi)的軟件項目。1.3 引用文件過程描述文件編寫規(guī)范(一)(QMS-PSM02-V1.0)標準軟件過程的開發(fā)和維護(QMS-PSM01-V1.0)軟件生命周期模型描述文件(QMS-PSM05-V1.0)客戶需求管理程序文件( QMS-PTM01-V2.0)技術(shù)類評審程序文件( QMS-PTM09-V1

35、.0)軟件配置管理程序文件( QMS-PTM09-V1.0)術(shù)語 ( QMS-PSM07-V1.0)1.4 術(shù)語?過程：把輸入轉(zhuǎn)換為輸出的一組彼此相關(guān)的活動。?構(gòu)造：將源代碼進行編譯、連接、生成目標代碼的過程。?構(gòu)造環(huán)境：主要指與源碼一起進行編譯、連接的環(huán)境，在C 語言中一般是指由編譯、連接命令、環(huán)境參數(shù)、操作語句等構(gòu)成的一系列腳本程序的組合。?白盒測試：基于源碼進行的測試，主要的形式包括語句覆蓋、分支覆蓋、路徑覆蓋等。?黑盒測試：基于目標代碼的測試，主要的形式為功能測試。?回歸測試：對新增的功能或更正錯誤的部分(包括與其相關(guān)的部分)進行的測試，而不是對軟件系統(tǒng)全面的測試。其他術(shù)語參見術(shù)語文件

36、。1.5 參考資料?軟件能力成熟度模型CMM 方法及其應用，楊一平等著，人民郵電出版社， 2001 年 4月?實踐中的CMMINFOSYS公司實施軟件項目之過程，潘卡 杰羅特著，楊慧鳴、李光龍澤，2001 年 7 月? Managing the Software Process Watts S. Humphrey, Addison Wesley Longman, Inc, 1989? Recommended Approach to Software Developmen t SEL-81-305， 1992.6?軟件需求， Karl E. Wiegers 著，陸麗那、王忠民、王志敏等譯，機械工

37、業(yè)出版社，2000年 7月?軟件工程Java語言實現(xiàn)，Stephen R. SchacK,袁兆山等譯，機械工業(yè)出版社，1999年 9月?軟件工程實踐者的研究方法，Roger S. Pressmanf,黃柏素、梅宏等譯，機械工業(yè)出版社，1999 年 10 月?國際信息技術(shù)軟件生存周期過程指南GB/T8566-2002?軍標軟件開發(fā)與文檔編制SJ20778-20002、過程總體描述2.1 過程概述軟件開發(fā)過程是指軟件產(chǎn)品開發(fā)活動中所有階段、任務的組合。該過程可劃分為一系列子過程，包括： 系統(tǒng)分析、軟件需求分析、設計、 編碼、 測試、 驗收、維護， 每個子過程又由一系列任務和活動組成，如設計過程又可

38、分為結(jié)構(gòu)設計和詳細設計。本程序文件描述公司通用的軟件開發(fā)過程的組成（稱之為“過程元素 ”） 、彼此之間的關(guān)系（輸入、輸出接口），以及相應的裁剪指南。具體的軟件開發(fā)項目可以根據(jù)其范圍、規(guī)模和復雜度，確定軟件生命周期模型，參見軟件生命周期模型描述文件；然后根據(jù)通用的軟件開發(fā)過程和裁剪指南，確定項目具體的軟件開發(fā)過程。本程序文件涉及的裁剪指南分為兩個層次，一層為過程級，主要針對不同的項目所采取的過程的剪裁，以定義不同的典型過程；另一層為過程元素內(nèi)部，主要針對元素內(nèi)部的各個任務的剪裁。2.2 結(jié)構(gòu)描述軟件開發(fā)過程在整個標準軟件過程中的位置及組成見下圖2.2 1。2.21 軟件過程結(jié)構(gòu)圖本程序文件所描述

39、的軟件開發(fā)過程的元素的組成見下表:程元素階段需求分析設計實現(xiàn)測試驗收維護系統(tǒng)分析V軟件需求分析V結(jié)構(gòu)設計V詳細設計V編碼V集成測試VV系統(tǒng)測試V驗收V維護V每個過程元素的具體描述和工作要求見本程序文件第三節(jié)的過程元素”描述。2.3過程級裁剪指南活動口裁剪屬性開發(fā)過程全過程（附錄 2.31）執(zhí)行簡化過程1 1（附錄 2.32）執(zhí)行簡化過程1 2（附錄 2.3 2）執(zhí)行簡化過程21 （附錄 2.3 3）執(zhí)行簡化過程22（附錄 2.3 3）執(zhí)行軟件開發(fā)過程中的技術(shù)類評審方式見技術(shù)類評審程序文件中相應裁剪指南3、過程元素以下分別對軟件開發(fā)過程中的各個元素進行描述。3.1 系統(tǒng)分析3.1.1 元素概述系

40、統(tǒng)分析的目的是形成一個清楚的、 完整的、一致的和可驗收測試的系統(tǒng)需 求規(guī)格說明書，與其它過程元素的關(guān)系如下圖所示：來自客戶的需求可以是招標書、項目說明書或意向書等任何形式的客戶需 求。系統(tǒng)分析是整個軟件生命周期的開始，應分析待開發(fā)系統(tǒng)特定的預期使用要 求，以規(guī)定系統(tǒng)需求。在此階段，系統(tǒng)工程組要用一種反復迭代的方法逐漸擴充、完善系統(tǒng)需求， 使其達到完整；對系統(tǒng)結(jié)構(gòu)進行設計，建立系統(tǒng)的頂層結(jié)構(gòu)，并標出硬件部分、 軟件部分和人工操作部分。應確保所有系統(tǒng)需求分配到各部分中。 分配以各部分 的系統(tǒng)需求及其相關(guān)系統(tǒng)結(jié)構(gòu)應形成文檔，對軟件必須要實現(xiàn)的每個功能和每個 要滿足的關(guān)鍵點進行詳細描述。通過實施本過程

41、元素，完成系統(tǒng)架構(gòu)和業(yè)務需求說明書(附錄3.1 1)可行性分析報告(附錄3.1 2)和系統(tǒng)需求規(guī)格說明書(附錄3.1 2), 為軟硬件開發(fā)人員正確建立所要求的系統(tǒng)提供基礎。如上圖所示，系統(tǒng)需求規(guī)格說明書應包括分配到軟件部分的需求和分配 到硬件部分的需求兩部分。但在本文件中，如無特別說明，系統(tǒng)需求均指系統(tǒng)分 配給軟件部分的需求，也屬于客戶需求；系統(tǒng)需求規(guī)格說明書均指系統(tǒng)分配 給軟件部分的需求的規(guī)格說明書。3.1.2 人口準則和出口準則(1)入口準則要素判斷準則招標書、項目說明書或意向書等客戶需求已接受(2)出口準則要素判斷準則可行性分析報告經(jīng)過評審并批準執(zhí)行系統(tǒng)架構(gòu)和業(yè)務需求說明書系統(tǒng)需求規(guī)格說

42、明書進行了評審并經(jīng)SCCB批準作為客戶需求基線評審發(fā)現(xiàn)的問題已關(guān)閉3.1.3 任務(1)系統(tǒng)架構(gòu)和業(yè)務需求定義及系統(tǒng)可行性分析，具體過程如下圖所示:可行性分析來自客尸的需求可行性分析報告a. 系統(tǒng)架構(gòu)識別?收集和逐條列出所有系統(tǒng)的高層需求（指最高層的產(chǎn)品業(yè)務目標）。?描述滿足這些高層需求系統(tǒng)必須實施的基本功能，著重從系統(tǒng)壽命（使用期限） 、性能、安全、可靠性和數(shù)據(jù)項等方面的問題去考慮。?通過這些功能描述，得到識別軟件程序和所有主要接口的系統(tǒng)架構(gòu)。?詳細說明所有主要數(shù)據(jù)接口的格式（如：文件、顯示、打印輸出等）。b. 重用分析?如果客戶要求的功能與已有的產(chǎn)品很相似，則可評審已有的產(chǎn)品的系統(tǒng)架構(gòu)和業(yè)

43、務需求說明書、 系統(tǒng)需求規(guī)格說明書、 用戶手冊和相關(guān)源代碼等來識別重用候選項。選擇較強的候選薦并估算相應的成本，評價其可靠性等，根據(jù)將開發(fā)項目的具體情況，對是否選用重用項作出一個相對折中的選擇。?調(diào)整體系結(jié)構(gòu)來說明采用的可重用軟件，把所有重用分析的結(jié)果以重用建議的形式記錄下來，寫入系統(tǒng)架構(gòu)和業(yè)務需求說明書文檔中。c. 業(yè)務需求定義?清楚地定義系統(tǒng)必須如何在其業(yè)務環(huán)境下運行，包括針對所有主要業(yè)務模式的業(yè)務方案腳本，又稱使用實例。形成的描述寫入系統(tǒng)架構(gòu)和業(yè)務需求說明書文檔。?由于最終用戶是系統(tǒng)的直接使用者，需要時可請他們作為產(chǎn)品代表，幫助建立業(yè)務方案腳本。d. 系統(tǒng)架構(gòu)和業(yè)務需求的評審?就系統(tǒng)架構(gòu)

44、和業(yè)務需求請系統(tǒng)和領(lǐng)域?qū)＜疫M行評審。e. 可行性分析?在上述結(jié)果的基礎上，進一步分析高層需求，從技術(shù)、經(jīng)濟、商業(yè)以及管理等方面進行可行性研究。?編寫可行性研究報告。?對可行性分析報告進行評價，作出項目是否可行的判斷和決策。如果項目可行，則進入下一過程；否則終止系統(tǒng)分析。（ 2）開發(fā)系統(tǒng)需求系統(tǒng)需求的開發(fā)過程如下圖所示。a. 細化需求?基于高層需求和系統(tǒng)概念及體系結(jié)構(gòu)，向下定義子系統(tǒng)層的所有需求，即細化的用戶工作流程。如果系統(tǒng)很大（有很多子系統(tǒng)）或如果將與其它系統(tǒng)接口，就要清楚地定義所有外部接口。?確定系統(tǒng)性能和可靠性需求。如果某個接受準則對應到某條需求（如：滿足特定的響應時間），則需說明這條需

45、求的測試準則。b. 編寫系統(tǒng)需求規(guī)格說明書?在用戶已有業(yè)務系統(tǒng)的層面，識別需要滿足需求的輸入和輸出的數(shù)據(jù)，用結(jié)構(gòu)化或面向?qū)ο蟮姆治龇椒?，派生出軟件必須實施的底層功能和算法。定義所有的文件、報告和顯示等，并指出哪些數(shù)據(jù)用戶必須能夠修改等。?保持設計和語言的中立性，即集中在軟件需要做什么方面，而不是怎么做。?創(chuàng)建一個追溯矩陣來映射每個底層的功能或數(shù)據(jù)說明使其能夠得到實現(xiàn)。?將上述結(jié)果形成文件，完成系統(tǒng)需求規(guī)格說明書的編寫，作為軟件開發(fā)的基礎。c. 系統(tǒng)需求規(guī)格說明書評審?對系統(tǒng)需求規(guī)格說明書進行同行評審。評審后的系統(tǒng)需求規(guī)格說明書必須經(jīng)SCCB 批準，作為需求基線，納入配置庫。3.1.4 工作產(chǎn)品

46、?系統(tǒng)架構(gòu)和業(yè)務需求說明書?可行性分析報告?系統(tǒng)需求規(guī)格說明書?追溯表（ MT-PTM01B） （ MT-PTM01C）3.1.5 職責（ 1）系統(tǒng)工程組：負責完成本過程元素所要求的所有活動，并填寫追溯表 （見客戶需求管理程序文件） 。（ 2）項目經(jīng)理：負責制訂系統(tǒng)分析階段的計劃（在執(zhí)行過程中可能需要進行計劃修訂）；管理、度量此過程，并負責安排同行評審。（3） SCM:統(tǒng)計已定義的需求項的個數(shù)和已進行說明的需求的百分比，填 寫客戶需求統(tǒng)計表（見客戶需求管理程序文件） 。3.1.6 資源和能力要求?必要的培訓資源?支持系統(tǒng)需求分析的設備?支持系統(tǒng)需求分析的工具3.1.7 度量?統(tǒng)計已定義的需求項

47、的個數(shù)和已進行說明的需求的百分比?質(zhì)量（同行評審缺陷統(tǒng)計）?完成本元素的工作所花費的工時3.1.8 詳細裁剪指南可裁剪屬性3.2.1元素概述系統(tǒng)構(gòu)架和業(yè)務需求定義及系統(tǒng)可行性分析執(zhí)行系統(tǒng)架構(gòu)識別執(zhí)行進行重用分析業(yè)務需求定義執(zhí)行文檔系統(tǒng)架構(gòu)和業(yè)務需求說明書評審開發(fā)系統(tǒng)需求3.2軟件需求分析執(zhí)行執(zhí)行可行性分析細化需求文檔執(zhí)行軟件需求分析是按照項目定義的軟件開發(fā)過程， 根據(jù)系統(tǒng)分配給軟件的需求（見系統(tǒng)需求規(guī)格說明書），進行軟件質(zhì)量特性規(guī)格說明的過程。 該過程包括 進一步明確軟件運行環(huán)境，明確對軟件的功能、性能和數(shù)據(jù)要求，以及軟件與硬 件、軟件與軟件之間的接口要求等，并對軟件需求進行驗證和文檔化，即完

48、成對 軟件需求的分析與規(guī)格定義。有關(guān)軟件需求的變更管理，請參見軟件配置管理程序文件。本元素在整個過程中的位置如下圖所示:結(jié)構(gòu)設計3.2.2 入口準則和出口準則（1）入口準則要素判斷準則客戶需求（系統(tǒng)需求規(guī)格說明書）?已由SCCB批準為基線? 已進入配置庫（2）出口準則要素判斷準則軟件需求規(guī)格說明書? 已經(jīng)過審查?已批準為開發(fā)基線? 已進入配置庫系統(tǒng)測試計劃? 已經(jīng)過審查? 已獲得批準? 已進入配置庫系統(tǒng)測試案例用戶手冊（概要）?已編寫3.2.3任務各工作階段如下圖所示:（1）準備階段a.必要時對軟件需求分析員進行相關(guān)培訓（包括有關(guān)的技術(shù)和業(yè)務知識培訓，以及有關(guān)的工具使用培訓）。b.審查客戶需求

49、，識別并解決影響軟件需求的問題。c.選擇適當?shù)男枨蠓治龇椒ǎ▍⒁姼戒?.21、附錄3.2 2、附錄3.2 3、 附錄3.2 4）,并準備相應的分析工具。建議采用的需求分析方法包括：結(jié)構(gòu)化分析法、面向?qū)ο蠓治龇ê涂焖僭?法等。如果需要采用上述分析法以外的其它需求分析法，應該得到SEPG的批準。? 吉構(gòu)化分析法采用結(jié)構(gòu)化的分析技術(shù)。后續(xù)過程（設計、實現(xiàn)）通常也應該采用結(jié)構(gòu)化技術(shù)。適用于中、小規(guī)模的軟件項目。?5向?qū)ο蠓治龇ú捎妹嫦驅(qū)ο蟮姆治黾夹g(shù)。后續(xù)過程（設計、實現(xiàn)）通常也應該采用面向?qū)ο蠹夹g(shù)。適用于各種規(guī)模的軟件項目。?快速原型法借助快速開發(fā)工具，以提供原型的方式，迅速掌握客戶對軟件的需求。適

50、用于客戶描述不清楚對軟件的全部或部分需求。建立滿足客戶需求的原型后，根據(jù)所采用的工具和實際需要確定是否重新進行軟 件需求規(guī)格定義。快速原型不能作為惟一的軟件需求規(guī)格表達方式，必須輔之以適當?shù)能浖枨笠?guī)格說明書?？焖僭头梢耘c結(jié)構(gòu)化分析或面向?qū)ο蠓治黾夹g(shù)結(jié)合使用。（ 2）收集、分析階段本階段需要與客戶不斷接觸、協(xié)商。通過對收集到的信息進行分析、歸納，界定出對軟件的需求，明確在目標產(chǎn)品中需要什么和以什么形式來表現(xiàn)。與客戶交流的基本形式通常有兩種：客戶訪談調(diào)查（正式的和非正式的）、書面調(diào)查（書面報告和調(diào)查表）。此外，通過對客戶使用的表格和所處的情景進行分析， 從而獲取需求，也是常用的方法。這些方法

51、對前面推薦的三種需求分析中采用的分析法與后續(xù)過程的設計和實現(xiàn)方法有一定的關(guān)聯(lián)關(guān)系，通常應該保持所選用的表達方法一致。詳見需求分析方法指南。除了調(diào)查客戶正常業(yè)務處理要求以外，特別需要關(guān)注的是異常處理和例外處理要求。這些處理要求往往在軟件需求中占有很大的比例，卻容易被忽視。收集、分析可重用的軟件或功能模塊，確定可用項。本階段的工作步驟如下：?編制工作計劃，特別是與受訪者協(xié)商確定調(diào)查、訪談日程安排。?運用選定的需求分析方法，收集、識別是、導出軟件需求。?收集、篩選、確定可能重用的軟件或功能模塊。（ 3）定義階段a. 根據(jù)軟件需求分析結(jié)果，選擇適當?shù)膶崿F(xiàn)方案并說明選擇理由，形成軟件系統(tǒng)的初步設計方案（包括對系統(tǒng)體系結(jié)構(gòu)、數(shù)據(jù)體系結(jié)構(gòu)和接口的初步設計） 。b. 描述軟件需求規(guī)格，編制軟件需求規(guī)格說明書（附錄3.2 5） 。c. 編制用于驗證和確認軟件需求是否得到滿足的方法系統(tǒng)測試計劃和系統(tǒng)測試案例，測試計劃的編寫規(guī)范見附錄3.26。d. 建立用戶手冊（概要） 。e. 填寫追溯表。參見客戶需求管理程序文件。（ 4）評審階段a. 評審 軟件需求規(guī)格說明書， 具體評審過程見技術(shù)類評審程序文件， 對軟件需求的評審準則包括：?系統(tǒng)需求和系統(tǒng)設計的可追溯性；?與系統(tǒng)需求的外