北京x軟件股份有限公司項目執(zhí)行流程程序文件58程序文件

1、1目的及適用范圍1.1 為規(guī)范項目業(yè)務中項目執(zhí)行過程，達到項目的成本、進度、質量的統一，特制定本程 序；1.1 本程序文件適用于XXX公司項目業(yè)務中項目執(zhí)行；1.2 本程序文件由xxx公司 制定，其解釋權及修改權屬于：1.3 本程序文件從2003年 月口起執(zhí)行；2】職責2.1 項目中心負責項目執(zhí)行的總體進程,并對執(zhí)行的最終結果負貴；2.2 項目中心（副）總監(jiān)和執(zhí)委會負責在關鍵節(jié)點監(jiān)控和協調資源：2.3 質量控制部負責對項目執(zhí)行過程中的里程碑產生的相關成果和文檔進行質量控制，并 將符合規(guī)范的成果放入資源中心存檔；3 定期戰(zhàn)略質詢流程3.1 決策委員會同意簽訂合同后，項目部項目經理（在項目銷售流程

2、中的準項目經理）制 訂項目計劃書，并交給質量控制部進行質量檢驗，若質檢未通過，項目經理修改項 目計劃書，3.2 若質檢通過，項目計劃交由執(zhí)委會審批，如果未通過，項目經理重新修改項目計劃 書；3.3 如果審批認可，項目經理將項目計劃遞交給客戶評審，若未通過，項目經理修改項 目計劃書3.4 若客戶評審通過，進行項目資源安排，若所需資源在項目中心本身內，由項目總監(jiān)完 成資源安排，若所需資源跨項目中心外的多個部門，由執(zhí)委會完成資源安排；3.5 獲得所需資源后，項目經理進行需求分析，交質量控制部進行質量檢驗，若質檢未通 過，項目經理修改需求分析；3.6 若質檢通過，專家委員會對需求分析內容進行評審，若未

3、通過，項目經理修改需求分 析內容；3.7 若通過內容評審，項目經理將需求分析交給客戶評審，若未通過，項目經理修改需求 分析，若通過，項目經理進行總體設計，同時將需求分析相關成果和文檔放入資源中 心存檔；3.8 質量控制部對總體設計進行質量檢驗，若未通過，項目經理修改總體設計，若通過， 專家委員會對總體設計內容進行評審，若未通過內容評審，項目經理修改總體設計內 容，3.9 若通過內容評審，項目經理將總體設計交給客戶評審，若未通過客戶評審，項目經理 修改總體設計，若通過客戶評審，項目經理安排項目進行系統實現，同時相關成果和 文檔放入資源中心存檔；3.10質量控制部對系統實現結呆進行功能測試，若未通

4、過，項目經理安排項目組成員修改 系統實現：3.11若通過功能測試，質量控制部進行質量檢驗，若未通過，項目經理安排項目組成員修 改系統實現；3.12若通過質檢，專家委員會對系統實現進行驗收，若未通過，項目經理安排項目組成員 修改系統實現；3.13若通過專家委員會驗收，項目經理將系統實現相關成果交給客戶驗收，若未通過，項 目經理安排項目組成員修改系統實現；3.14若通過客戶驗收，質量控制部將相關成呆和文檔放入資源中心存檔，同時項目經理安 排項目組成果進行項目推廣；3.15項目經理進行項目總結，交給專家委員會進行評審，若未通過，項目經理修改項目總 結；3.16若通過評審，質量控制部將相關成果和文檔放

5、入資源中心存檔：4 相關文件4.1 項目計劃書4.2 質量控制項目計劃評審報告4.3 綜合評審記錄4.4 客戶評審記錄（含項目計劃、需求分析、總體設計等需要和客戶溝通的關鍵壞節(jié)）4.5 項目資源調度單4.6 需求分析說明書4.7 質量控制需求分析說明書評審報告4.8 資源中心驗收單4.9 總體設計說明書4.10概要設計說明書4.11詳細設計說明書4.12質量控制系統設計報告評審記錄4.13系統實現相關文檔（略）4.14系統測試總結報告4.15軟件缺陷報告4.16評審規(guī)程4.17客戶驗收單4.18項目總結項目計劃書項目名稱項目編號項目經理項目任務描述項目總時間及關鍵里程碑設置項目人力資源項目費用

6、預計審批人意見：總監(jiān)：副總監(jiān)：執(zhí)委會:備注：抄送財務部、人力資源部時間項目啟動計劃評審記錄記錄編號:時間：年 月曰項目編號:【頁目名稱:項目啟動計劃編號:開發(fā)部門:PM:評審地點:參加評審人員:評審內容（評審中審議通過的內容在“”中劃“丿”否則劃“ x ”）：1)頃目的目的是否明確？2)對頃目的規(guī)模是否進行佶算?3)是否進行頃目啟動的預算?4)階段輸出結果是否明確?5)其它方面評審意見:評審結論:填表:審批:項目啟動計劃評審由項目管理部門組織評審。3.評審完成后由開發(fā)體系決策層SMG批準。本頁不足記述結果時可以加入附頁.附頁格式自行設計總頁數包括本頁與所有附頁。開發(fā)計劃評審記錄記錄編號：時間：

7、年 月曰項目編號：項目名稱：項目計劃編號：開發(fā)部門：PSM:評審地點：參加評審人員：評審內容：評審意見：評審結論：填表：審批：1. 幵發(fā)計劃評審由項目管理部門組織評審。2. 評審完成后由開發(fā)體系決策層SMG批準。3本頁不足記述結果時.可以加入附頁.附頁格式自行設計總頁數包括本頁與所有附頁。開發(fā)計劃檢查表（開發(fā)計劃評審附頁）項目名稱：項目編號:檢杳項目檢杳內容檢查結果得分、質量目標1、是否符合質量體系的要求？2、如果不符合質量體系的要求，是否按要求編 制質量計劃？二、階段劃分1是否明確劃分各階段？2、各階段的輸入、輸出標準是否明確？3、是否明確各階段提交物？4是否明確各階段質量目標？5是否明確提

8、出各階段檢杳點？三、產品清單1、是否明確提交給客戶的產品清單（產品名稱 、提交時間、客戶接受方式、責任入、驗收標 準）？2、是否明確提交給項目監(jiān)控部門的產品清單 （產品名稱、提交時間、提殳力式、責任人）？四、技術管理1、是否明確開發(fā)環(huán)境（軟件、硬件環(huán)境）？是否明確開發(fā)工具？是否明確開發(fā)方法？4、是否采用新技術？5、是否考慮軟件復用？五、組織結構1、是否確定項目小組成員，并將其劃分成多個 Team ?2、是否明確各個小組成員的職責？六、風險管理1、是否預測了與項目有關的主要風險？2、是否采取跟蹤、監(jiān)測措施以減小風險或避免 風險的產生？七、相關性1、是否考慮了項目的外部相關活動？2、是否考慮了項目

9、的內部相關活動？八、資源預算1、是否田了有關資源的直力圖？2、是否預算了項目的工作量并劃分給小組成 員？九、配置管理1、是否制定了配置管理計劃表？檢查人/日期：批準人/曰期:風險評估與控制（開發(fā)計劃評審附頁）開發(fā)計劃名稱：計劃編號：評審部門：序 號風險描述風除發(fā)住可能性風險級別風險現值風險控制措施1客戶需求不明確2客戶需求變化3開發(fā)人員缺乏足夠的行業(yè)知識和專業(yè)知識4源碼.文檔的控制5工作階段劃分不明確.人員分工不合理6多部門配合7開發(fā)隊伍不穩(wěn)定或缺乏人力資源8預算超支9缺乏對技術復用的考慮10時間緊11存在技術難點、采用新技術12檢查點設立不合理13缺乏對突發(fā)郭件的考慮1評風險不限于表中己魁的

10、.應依據評審的具休惰況增加風険通。并將各i填寫完整。2.風險描述：描述當繭辺程中QJ烤發(fā)生的風洽。風洽友主曰能性：風險發(fā)生的概率.以百分敬表示.為0到1定為0.05。岡險級別：風洽友三適咸捋失的嚴至程隈.以0、10表 示.兵B10級為最玄級。風洽觀值：風險發(fā)生巧影注與風洽級別的康枳風險15制ISffi：皺防風險發(fā)宇的捨懈。雋頁/共頁軟件問題報告記錄編號：-時間：年 月 日項目編號：項目名稱：軟件項編號：軟件項名稱：版本號：問題描述：報告人簽字/日期：修改描述（主要是修改后與修改前的對比，如所用資源的變化、提交時間的變化、功能的變化等）： 修改人簽字/日期：填寫：審批：1.冋題描述欄中可以填寫冋

11、題現象及其產生原因.如果有用戶的書面說明.則可以直接引用。 2 修改描述一欄描述問題的確切原因.修改辦法以及修改后的效果3-本頁不足記述時.可以有附頁.格式自定?？傢摂蛋ū卷撆c所有附頁。綜合評審記錄（公司）評審對彖（項目名稱及編號）評審項類（如合同、投標方案等）-評審人時間業(yè)務板塊（產品中心、項目中心、服務中心、營銷中心）評審意見財務部評審意見質量控制部評審意見技術委員會評審意見專家委員會評審意見最終意見：通過修改修改內容時間項目資源調度單項目經理項目名稱項目編號項目的跨中心（部門）資源調度緣由申請人審批人正式調用時間:起：止：備注：抄送財務、人力資源部時間軟件需求分析說明書1. 引言1.1

12、 的說明編寫軟件需求說明書的目的，指出預期的讀者。1.2背景（1）待開發(fā)的軟件系統的名稱；（2）本項目的任務提出者、開發(fā)者、用戶及實現該軟件的計算中心或計算機網絡：（3）該軟件系統同其他系統或其他機構的基本的相互來往關系。1.3參考資料列出所用的參考資料，如：（1）本項目的經核準的計劃任務書或合同、上級機關的批文；（2）屬于本項目的其他己發(fā)表的文件；（3）本文件中各處引用的文件、資料，包括所需用到的軟件開發(fā)標準。（4）列出這些文件資料的標題、文件編號、發(fā)表口期和岀版單位，說明能夠得到這些文件資料的來源。1 4術語列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。2. 項目概述本部分描述

13、影響產品和其需求的一般因素。此處并不說明具體的需求，其描述的內容僅 僅是為了更容易理解、深化需求規(guī)格,其用意是為從多方面、多角度考慮需求以提供思維參 考點。2.1-般描述本節(jié)描述軟件開發(fā)項目的意圖、應用目標、作用范圍以及其他應向讀者說明的有關該軟 件開發(fā)的背景材料，解釋待開發(fā)產品和其相關的其他產品或項目的關系。 如果本產品是獨立的，而且自含全部內容，應在此說明。 如果所定義的產品是一個較人系統或項目中的一個組成部分，那么在此需要描述如下內容： 要概述這個較大的系統或項目的每一個組成部分的功能，并說明其接口； 指出本產品主要的外部接II （不需要詳細描述，詳細描述放在其他章節(jié)中）： 描述所使用的

14、計算機硬件、外用設備。這里僅僅是一個綜述性描述。【技巧】在本節(jié)的描述中，用一個方框圖來表達一個較大的系統或項EI的主要組成部分、相互聯系和外部接口址非常 有幫助的?！咎嵝炎⒁狻勘竟?jié)所描述的既不是設計方案，也不是在方案設計時的約束條件，它僅僅為方案設計時的約束條件提供了一個 可以解釋的理由。2. 2功能簡述對待的軟件產品功能提供一個摘要?！炯记伞?編制功能的一種方法是制作功能表，以便客戶或第一次讀這個文件的人很容易理解： 用方框圖來表達不同的功能和它們的關系有益于理解?！咎狨⒖偂?方框圖不是產品的設計.而只是一種有效的解釋方式。 木節(jié)不是具體需求的陳述，只是對具體需求部分中為什么要對一些需求做

15、出描述的鋪墊。2. 3用戶特點本節(jié)描述產品最終用戶（包括操作員、維護員和系統工作人員等）具有的受教育水平、工作經驗及技 術專長等一般特點。如果系統的大多數用戶是一些臨時的用戶，那么就要求系統包含如何完成基本功能的提示，而不是假設用戶已經從過去的會議或從閱讀用戶指南中了解到這些細節(jié)。2. 4假定和約束給出影響軟件需求說明書中陳述的需求的每一個因素。這些因素不是軟件的設計約束，但是它們的改 變可能影響到需求說明書中的需求。這些假定和約束條件可能包括：管理方針；運行環(huán)境，包括硬件設備和支持軟件的限制；與其他應用 間的接II;并行操作；實時功能；審查功能；控制功能；所需的高級語言：通信協議；應用的臨界

16、點；安 全保密方面的考慮等?！咎嵝炎⒁狻勘竟?jié)中描述的因素是軟件需求所依據的基石，當這些基石發(fā)生不可抗拒或控制的 改變時對產品需求將造成影響。本節(jié)的內容不能用來陳述具體需求或強加若干特殊的設計約束，而應對具體需求 部分中的某些具體需求或設計約束的描述提供理由。3. 具體需求本章應包括軟件開發(fā)者在建立設計時需要的全部細節(jié)。本章的編寫應該遵循如下基本原則： 遵循可驗證性、無歧義性等的準則，對每一個需求細節(jié)作具體描述； 在軟件需求說明書前言、項目概述、附錄部分的有關討論中，要提供對任何一個具體需求交叉引 用的背景； 按符合邏輯的和可讀的方式組織； 詳細描述每一個需求，使得該需求應達到的目標能夠用指定的

17、方法進行客觀的驗證。【提醒注總】每一項需求的描述都應包括至少5個方面的內容：功能需求：性能需求：屈性需求：外部接口需求：設計約束。 3.1功能需求用文字、圖表或數學公式詳細描述被開發(fā)軟件的輸入、處理、輸出以及在上述過程中發(fā)生的基本 操作。對于每一類功能或者有時對于每一個功能，這部分通常由引言、輸入、處理、輸出四個部分組 成：3.1.1引言（1）描述該功能要達到的目標、所采用的方法和技術：（2）清楚說明功能意圖的由來和背景。3.1.2輸入（1）詳細描述該功能的所有輸入數據，如：輸入源、數量、度量單位、時間設定、有效輸入范圍（包 括精度和公差）。（2）操作員具體的操作控制細節(jié)的需求。其中有名字、操

18、作員活動的描述、控制臺或操作員的位置。 例如：當打印檢查時，要求操作員進行格式調整。（3）指明引用的輸入接口資料。3. 1.3處理描述為獲得預期輸出結果，對輸入數據及中間參數進行的全部操作。它包括如下的說明：（1）輸入數據的有效性檢査手段；（2）操作的順序和處理過程，包括事件的時間設定；（3）異常情況的響應，例如：溢出、通信故障、錯誤處理等；（4）受操作影響的參數：（5）降級運行的要求；（6）用于把系統輸入變換成相應輸出的任何方法（方程式、數學算法、邏輯操作等）。（7）輸出數據的有效性檢査手段。3,1.4輸出（1）詳細描述該功能所有輸出數據，例如：輸出目的地、數量、度量單位、時間關系、有效輸出

19、的范W （包括精度和公差）、非法值的處理、出錯信息；（2）指明引用的輸出接口資料?！炯记伞靠梢杂昧斜淼姆绞剑ɡ鏘PO表即輸入、處理、輸出表的形式人逐項定雖和定性地敘述對軟件所提出的功能 要求?！咎嵝炎⒁狻繉粗赜谳斎胼敵鲂袨榈南到y來說，需求說明書應指走所有有意義的輸入、輸出對及冥序列。當一個系統要求 記憶它的狀態(tài)時,需要這個序列，使得它可以根據本次輸入和以前的狀態(tài)做出響應。這種情況猶如有限狀態(tài)機。3. 2性能需求從整體來說，本節(jié)應具體說明軟件、或人與軟件交互的靜態(tài)或動態(tài)數值需求。靜態(tài)數值需求可能包括：支持的終端數，支持并行操作的用戶數，處理的文卷和記錄數， 表和文卷的大小等。動態(tài)數值需求可能

20、包括：欲處理的事務和任務的數量，以及在正常情況下和峰值工作條件下一定時間 周期中處理的數據總量等。所有這些需求都必須用可以度量的術語來敘述。例如：95%的事務必須在小于Is時間內處理完，不然, 操作員將不等待處理的完成。精度說明對該軟件的輸入、輸出數據精度的要求，可能包括傳輸過程中的精度。時間特性要求說明對于該軟件的時間特性要求，如對響應時間、更新處理時間、數據的轉換和傳送時間、解題時間 等的要求。靈活性說明對該軟件的靈活性的要求，即當需求發(fā)生某些變化時，該軟件對這些變化的適應能力，如：操作 方式上的變化、運行環(huán)境的變化、同其他軟件的接II的變化、精度和有效時限的變化、計劃的變化或改進 等。對

21、于為了提供這些靈活性而進行的專門設計的部分應該加以標明。3. 3軟件屬性需求在軟件的需求之中有若干個屬性，下面列舉一部分。【提醍注總】下列屬性決不能理解為是一個標準的或完整的清單，而應根據項目實際情況予以列舉。3. 3.1正確性3. 3. 2健壯性3. 3.3安全保密性這里指的是保護軟件的要素，以防止各種非法的訪問、使用、修改、破壞或者泄密。這個領域的 具體需求必須包括：利用可靠的密碼技術，掌握特定的記錄或歷史數據集，給不同的模塊分配不同的 功能，限定一個程序中某些區(qū)域的通信，計算臨界值的檢查等。3. 3.4易使用性3. 3. 5可理解性3. 3. 6可維護性這里規(guī)定若干需求以確保軟件是可維護

22、的。例如：軟件模塊所需要的特殊的耦合矩陣，為微型裝置指 定特殊的數據/程序分割要求等。3. 3. 7可測試性3. 3. 8可移植性這里規(guī)定把軟件從一種壞境移植到另一種壞境所要求的用戶程序、用戶接I I兼容方面的約束等。3. 4外部接口需求3. 4.1用戶接口（1）提供用戶使用軟件產品時的界面需求。例如，如果系統的用戶通過顯示終端進行操作，就必須指 定如下要求：對屏幕格式的要求，報表或菜單的頁面顯示格式和內容，用戶命令的格式，輸入輸 出的相對時間，程序功能鍵的可用性。（2）列出輸出錯誤信息的格式。3. 4.2硬件接口（1）指出軟件產品與系統碩部件之間每一個接11的邏輯特點。（2）指出硬件接口支持

23、的設備。（3）描述軟件與硬件接門之間以及碩件接I I與支持設備之間的約定。3 4 3軟件接口描述項目待開發(fā)軟件產品與其它有關軟件的接II關系，并指出這些軟件的以下內容：名字、助記 符、規(guī)格說明號、版本號、來源?！咎嵝炎⒁狻繉τ诿恳粋€接口，應說明與軟件產品相關的接口軟件的目的，并根據信息的內 容和格式定義接口，這里不必詳細描述任何已有完整文件的接口，只要引用定義該接口的文 件即可。3. 4.4通訊接口說明各種通信接11及協議，例如局部網絡的協議等。3. 5設計約束3.5.1其它標準的約束描述由現有的標準或規(guī)則派生的要求。例如：報表格式、數據命名、財務處理、審計追蹤等等。3. 5. 2硬件設備的約

24、束描述在各種硬件約束下運行而產生的軟件要求，可能的約束有碩件配置的特點（接I I數、指令系統等）, 內存儲器和輔助存儲器的容量等。3. 6數據需求【提醒注意】 此部分內容一般在數據要求說明書中進行描述，如果項目軟件產品規(guī)模較小，系統復雜程度較低，數拯需求較簡 單，也可在此章中描述。 此部分內容也可能在功能需求中予以說明。3. 6.1數據描述（1）列出作為控制和引用而使用的靜態(tài)數據元素（2）列出動態(tài)輸入數據元素（3）列出動態(tài)輸出數據元素（4）列出軟件內部生成的數據元素3. 6. 2數據獲?。?）列出提供輸入數據的機構（2）列出數據輸入介質和設備（3）列出數據輸出介質和設備3. 7其它專門需求根據

25、軟件和用戶組織的特性等，某些需求在這里描述，下面列舉一部分?！咎狨⒖偂肯铝行枨箜棝Q不能理解為是一個標準的或完整的清單，而應根據項目實際悄況予以列舉。3. 6.1數據庫本項對作為項目產品的一部分進行開發(fā)的數據庫規(guī)定一些需求，它們可能包括：(1)在功能需求中標識的信息類別;(2)使用的頻率(3)存取能力；(4)數據元素和文卷描述符；(5)數據元素、記錄和文卷的關系;(6)靜態(tài)和動態(tài)的組織；(7)數據保存要求?！咎狨⒖偂咳绻褂靡粋€現有的數據庫包，這個數據庫包應在“軟件接口”中命名，并在那里詳細說明。3. 6. 2數據管理能力說明需要管理的文卷和記錄的個數、表和文卷的人小規(guī)模，要按可預見的增長對

26、數據及其分量的存儲 要求做出估算。3. 6. 3操作這里說明用戶組織之中各種方式的操作。例如：(1)用戶初操作；(2)交互作用操作的周期和無人操作周期；(3)數據處理支持功能：(4)后援和恢復操作?！咎狨⒖偂窟@里的內容有時定“用戶接口”的一部分。3. 6. 4故障處理4. 運行環(huán)境規(guī)定4. 1設備列出運行該軟件所需要的碩設備。說明其中的新型設備及其專門功能，包括：(1) 處理器型號及內存容量；(2) 外存容量、聯機或脫機、媒體及其存儲格式，設備的型號及數量；(3) 輸入及輸出設備的型號和數量，聯機或脫機；(4) 數據通信設備的型號和數量；(5) 功能鍵及其他專用碩件。4. 2支持軟件列出支持

27、軟件，包括要用到的操作系統、編譯(或匯編)程序、測試支持軟件等。4. 3接口說明該軟件同其它軟硬件之間的接11、數據通信協議等。4. 4控制說明控制該軟件的運行的方法和控制信號，并說明這些控制信號的來源。【提醒注總】木章中的內容有時在前面的章節(jié)中已說明。5. 支持信息支持信息指目錄表、索引和附錄。 目錄表和索引很重要，而且應按照可以接受的文件規(guī)則來編寫。 對一個實際的需求說明書來說，如有必要應該編寫附錄。附錄中可能包括：(1) 輸入輸出格式樣本，成本分析研究的描述或用戶調查結果；(2) 有助于理解需求說明書的背景信息；(3) 軟件所解決問題的描述；(4) 用戶歷史、背昇、繹歷和操作特占(5)

28、交叉訪問表。菽先后次序進行編星使一些不完全的軟件需求得以完善：(6) 特殊的裝配指令用于編碼和媒體，以滿足安全、輸出、初始裝入或其他要求。當包括附錄時，需求說明書必須明確地說明附錄是不是需求要考慮的部分。總體設計說明書6.引言1.5目的說明編寫概要設計說明書的目的，指出預期的讀者。1.6背景（4）待開發(fā)的軟件系統的名稱；（5）本項目的任務提出者、開發(fā)者、用戶及實現該軟件的計算中心或計算機網絡：（6）該軟件系統同其他系統或其他機構的基本的相互來往關系。1.7參考資料列出所用的參考資料，女口：（5）本項目的經核準的計劃任務書或合同、上級機關的批文；（6）屬于本項目的其他已發(fā)表的文件；（7）本文件中

29、各處引用的文件、資料，包括所需用到的軟件開發(fā)標準。（8）列出這些文件資料的標題、文件編號、發(fā)表口期和岀版單位，說明能夠得到這些文件資料的來源。1.8術語列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。7總體設計2. 2需求規(guī)定簡要說明對本系統的主要的輸入輸出項目、處理的功能與性能等的要求。2. 3運行環(huán)境簡要地說明對本系統的運行環(huán)境（包括硬件環(huán)境和支持環(huán)境）的規(guī)定。2. 4基本設計概念和處理流程說明本系統的基本設計概念和處理流程，盡量使用圖表的形式。2. 5結構用一覽表及框圖的形式說明本系統的系統元素（各層模塊、子程序、公用程序等）的劃分，扼要說明 每個系統元素的標識符和功能，分層次

30、地給出各元素之間的控制與被控制關系。2. 6功能需求與程序的關系用如卜的矩陣圖說明各項功能需求的實現同各塊程序的分配關系：程序1程序2程序m功能需求1J功能需求2功能需求n2. 7人工處理過程說明在本軟件系統的工作過程中不得不包含的人工處理過程。2. 8尚未解決的問題說明在概要設計過程中尚未解決而設計者認為在系統完成之前必須解決的各個問題。8. 接口設計3. 1用戶接口說明將向用戶提供的命令和它們的語法結構，以及軟件的回答信息。3. 2外部接口說明本系統同外界的所有接11的安排包括軟件與硬件之間的接11、本系統與各支持軟件之間的接11關 系。3. 3內部接口說明本系統之內的各個系統元素之間的接

31、11的安排。9. 運行設計4. 1運行模塊組合說明對系統施加不同的外界運行控制時所引起的各種不同的運行模塊組合，說明每時每種運行所歷經 的內部模塊和支持軟件。4. 2運行控制說明每一種外界的運行控制的方式方法和操作步驟。4. 3運行時間說明每種運行模塊組合將占用各種資源的時河。10. 系統數據結構設計5. 1邏輯結構設計要點給出本系統內所使用的每個數據結構的名稱、標識符以及它們之中每個數據項、記錄、文卷和系的標 識、定義、長度及它們之間的層次的或表格的相互關系。5. 2物理結構設計要點給出本系統內所使用的每個數據結構中的每個數據項的存儲要求，訪問方法、存取單位、存取的物理 關系（索引.設備、存

32、儲區(qū)域）.設計考慮和保密條件。5. 3數據結構與程序的關系說明各個數據結構與訪問這些數據結構的各個程序之間的對應關系，可采用如卜的矩陣圖的形式：程序1程序2程序m數據結構1數據結構2 / V數據結構n / V/ 711. 系統出錯處理設計6. 1出錯信息用一覽表的方式說明每種町能的出錯或故障情況出現時，系統輸出信息的形式、含意及處理方法。6. 2補救措施說明故障出現后可能采取的變通措施，包括：（1）后備技術革新：說明準備采用的后備技術，當原始系統數據萬一丟失時啟用的副本的建立和啟動 的技術，例如周期性地把磁盤信息記錄到磁帶上去就是對于磁盤媒體的一種后備技術；（2）降效技術：說明準備采用的后備技

33、術，使用另一個效率稍低的系統或方法來求得所需結果的某些 部分，例如一個自動系統的降效技術可以是手工操作和數據的人工記錄；（3）恢復及再啟動技術：說明將使用的恢復再啟動技術，使軟件從故障點恢復執(zhí)行或使軟件從頭開始 重新運行的方法。6. 3系統維護設計說明為了系統維護的方便而在程序內部設計中做出的安排，包括在程序中專門安排用于系統的檢查與 維護的檢測點和專用模塊。詳細設計說明書12. 引言1.9目的說明編寫詳細設計說明書的目的，指出預期的讀者。1. 10背景（7）待開發(fā)的軟件系統的名稱；（8）本項目的任務提出者、開發(fā)者、用戶及實現該軟件的計算中心或計算機網絡:（9）該軟件系統同其他系統或其他機構的

34、基本的相互來往關系。1.11 參考資料列出所用的參考資料，如：（9）本項目的經核準的計劃任務書或合同.上級機關的批文；（10）屬于本項目的其他己發(fā)表的文件；（11）本文件中各處引用的文件、資料，包括所需用到的軟件開發(fā)標準。（12）列出這些文件資料的標題、文件編號、發(fā)表口期和岀版單位，說明能夠得到這些文件資料的來源。1. 12術語列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。13. 軟件系統的結構用一系列圖表列出本軟件系統內的每個程序（包括每個模塊和子程序）的名稱、標識符 和它們之間層次結構關系。14. 模塊n設計說明（n是模塊序號）從本章開始，將概要設計產生的功能模塊進行細化，形成

35、若干個可編程的程序單元,逐 個地給出各個層次中的每個程序的設計考慮。以下給出的提綱是針對一般情況的。對于一個具體的模塊,尤其是層次比較低的模塊或 子程序，其很多條目的內容往往與它所隸屬的上一層模塊的對應條目的內容相同,在這種情 況下，只要簡單地說明這一點即可。3. 1程序描述給出對該程序的簡要描述,主要說明安排設計本程序的目的意義，并且還要說明本程序 的特點（如是常駐內存還是非常駐內存；是否子程序;是可重入的還是不可重入的；有無覆 蓋要求；是順序處理還是并發(fā)處理；3. 2功能說明該程序單元應具有的功能，可采用IPO圖（即輸入輸出圖）的形式。3. 3性能說明對該程序的全部性能要求，包括對精度、靈

36、活性和時間特性的要求。3. 4結構用圖表的形式給出程序單元的結構。3. 5程序邏輯用框圖或過程性描述語言的形式表示各程序單元的控制流程。3. 6輸入項給出對每一個輸入項的特性,包括名稱、標識、數據的類型和格式、數據值的有效范圍、 輸入的方式、數量和頻度、輸入媒體、輸入數據的來源和安全保密條件等等。3. 7輸出項給出對每時每一個輸出項的特性，包括名稱、標識、數據的類型和格式，數據值的有效 范圍、輸出的形式、數量和頻度、輸出媒體、對輸出圖形及符號的說明、安全保密條件等等。 3. 8算法詳細說明本程序單元所選用的算法，具體的計算公式和計算步驟。3. 9接口用圖表的形式說明本程序所隸屬的上一層模塊及隸

37、屬于本程序的下一層模塊、子程序， 說明參數賦值和調用方式。3. 10數據結構說明與本程序相直接關聯的數據結構（數據庫、數據文卷），用圖表描述數據結構與模塊的關系。3.11存儲分配和數組分配確定每個模塊的存儲量及數組定義。3.12單元說明說明程序單元標識、調用方式、參數說明。3. 13注釋設計說明準備在本程序中安排的注釋，如：（1）加在模塊首部的注釋：（2）加在各分枝點處的注釋：（3）對各變量的功能、范缺省條件等所加的注釋；（4）對使用的邏輯所加的注釋等等。3.14限制條件說明本程序運行中所受到的限制條件。3. 15尚未解決的問題說明在程序單元的設計中尚未解決而設計者認為在軟件完成之前應解決的問

38、題。項目總結項目編號：項目類項：產品研發(fā)/項目/數據服務/組件開發(fā)/等部門名稱：目錄1. 引言2. 項目開發(fā)結果2.1軟件產品或軟件項目2.2主要功能和性能2.3項目規(guī)?？偨Y2.4項目人員總結2.5進度及工作量總結3. 項目評價3.1生產效率評價3.2技術方法評價3.3產品質量評價3.4出錯原因分析4. 經驗和教訓1.引言說明實際參加人員、時間及工作劃分：說明參加本項目的負責人、參加人員、起止時間及 實際工作量。按項目開發(fā)的階段劃分，細劃每位開發(fā)人員在各開發(fā)階段所用開發(fā)時間及實 際工作量。負責人：起止時間：計劃工作量：項目情況階段參加人員工作內容起止時間實際工作量需求分析A、B等等系統設計編碼

39、測試其它合計2.項目開發(fā)結果2.1軟件產品或軟件項目2.1.1軟件產品或軟件項目名稱：給出該軟件項目或軟件產品在項目任務書或開發(fā)計劃評 審等文件中確定的正式的項目名稱和項目編號；并給出該軟件項目或軟件產品正式 批準發(fā)布的版本標識。2.1.2程序量：按模塊進行劃分，給出該軟件項目或軟件產品的源程序的存貯容量。源代 碼用代碼行來表示，可執(zhí)行程序及其他程序可用字節(jié)來表示，文檔可用頁或字節(jié)來 表示。（源代碼一定要按模塊來統計）模塊名稱代碼行（千行）字節(jié)數（KB）源碼模塊1模塊2執(zhí)行程序等等注：源碼不填寫“字節(jié)數”，執(zhí)行無呈序只填寫“字節(jié)數” O2.1.3存儲介質：給出該軟件項目或軟件產品正式發(fā)布版本的

40、存儲介質及所需存儲介質及 其數量。2.2 主要功能和性能1）描述該軟件項目或軟件產品所實現的功能，根據需要說明該軟件項目或軟件產 品的有關性能指標。2）與最初的需求相比較，給出功能和/或性能上的差異并說明原因。2.3 項目規(guī)模總結根據軟件開發(fā)的各階段，總結該軟件項目或軟件產品完成的功能模塊數量與計劃的 對比，給出對比圖表，并對比較結果進行分析。階段計劃模塊數完成模塊數需求分析系統設計編碼測試合計2.4 項目人員總結總結該軟件項目或軟件產品開發(fā)各階段人員的變化情況與計劃的對比，并對比較結果進行分析。階段計劃人數實際人數增加人數減少人數變動人數需求分析系統設計編碼測試總計注：變動人數為人員更換數。

41、7口計劃人數實際人數變動人數2.5進度及工作量總結總結該軟件項目或軟件產品實際完成所用的時間及工作量與原計劃的對比。用圖表來表示。251從開發(fā)人員的角度進行總結：將每位開發(fā)人員開發(fā)該軟件項目或軟件產品起止時間和工作量與計劃進行比較，給出對比圖表，并對比較結果進行分析。I it lcJM I | 口實際H |開發(fā)人員計劃時間實際時間是否按時計劃M實際MABCD等等2.5.2從模塊的角度進行總結：將每一模塊完成的起止時間和工作量與計劃進行比較，給出對比圖表，并對比較結果進行分析。模塊名稱計劃時間實際時間是否按時計劃M實際M模塊1模塊2模塊3模塊4總計253從開發(fā)階段的角度進行總結：將每一階段完成的

42、起止時間和工作量與計劃進行比較，給出對比圖表，并對比較結果進行分析。階段計劃時間實際時間是否按時計劃M實際M需求分析系統設計編碼測試總計廠1需求分析系統設計編碼測試F計劃艸I 實際2.5.4從工作量的角度進行總結：將開發(fā)該軟件項目或軟件產品所用工作量與計劃進行比較，給出由于軟件問題報告所增加的工作量，給 出對比圖表，并對比較結果進行分析。批復工作量實際工作量計劃增加小計2.5.5從完成情況進行總結：將項目的總體進度和階段進度與計劃進行比較，說明此項目是正常完成、正常但增加工作量、延期但不增加 工作量、即延期乂增加工作量，并對比較結果進行分析。計劃時間實際時間批復工作量實際工作量結論注：以最后一

43、版的開發(fā)計劃中的開發(fā)進度為準，批復工作量包括由于軟件問題報告增加的工作量。3.項目評價3.1生產率評價評價生產率可以有兩種方法：代碼行數與人月數比較，或修改BUG數 與所用人月數的比較。我們可以采用任何一種。如果采用第一種方法， 應以模塊為單位進行比較；如果釆用第二種方法，應以各測試版本的BUG數、修改的BUG數、修改BUG所用的工作量及修改單位BUG所 用的工作量進行比較，總結評價項目的開發(fā)效率及相應的原因分析。模塊名稱代碼行（千行）匚作量代碼行/工作量模塊1模塊2等等3.2技術方法評價總結該軟件項目或軟件產品開發(fā)時所采用的各項技術。3.3產品質量評價可參考以下幾個方面進行產品質量的評價。1

44、）歷次測試發(fā)現的BUG數；2）同種原因產生的BUG數:3）同種類型的BUG數；4）各等級的BUG數；5）同一 BUG出現的次數。3.4出錯原因分析分別對以上幾種情況繪制圖表，進行原因的分析。次數EUG數原因BUG數類型BUG數等級EUG數BUG名次數4. 經驗和教訓可以從以下幾方面總結開發(fā)中獲得的經驗及糾正錯誤或缺陷等問題的教訓。1）管理人員的管理水平；2）開發(fā)人員的合理分工；3）項目軟件經理PSM及開發(fā)人員的技術水平；4）開發(fā)人員的更換；5）開發(fā)人員的配合及協作；6）用戶的密切配合；7）需求及設計的更改；8）開發(fā)過程中計劃的合理調整等等評審規(guī)程狀態(tài)：草稿標識號：評審當前版本：1.0初始版前一

45、版本：修訂版發(fā)布日期：摘要本文詳細描述了軟件工作產品的評審規(guī)程。將要執(zhí)行評審的所有 項目的軟件工作產品都必須遵循該評審規(guī)程。修改歷史日期版本作者修改內容評審號更改請求號目錄1目的和范圍342評審角色342.1作者342. 2評審組長342. 3記錄員342.4其他參與人員343評審過程343. 1計劃階段353. 1. 1進入條件353. 1.2目的353. 1. 3活動353. 2準備階段353. 2. 1進入條件353. 2.2目的353. 2. 3活動363. 3執(zhí)行階段363. 3. 1進入條件363. 3.2目的363. 3. 3活動363. 4整理階段373. 4. 1進入條件37

46、3. 4.2目的373. 4. 3活動374附錄A評審活動檢查表385附錄B評審記錄表396附錄C評審通知 401目的和范圍本文檔主要描述了軟件工作產品的評審過程，目的是能夠及早和有效地發(fā)現并排 除軟件工作產品的缺陷。2評審角色在評審時有四種角色：作者、評審組長.記錄員及其他人員。這些角色在評審會上要承擔不同的 職責。角色的劃分必須遵循下而的原則： 作者和評審組長是必須的角色，且不能為同一人 記錄員可以是任何人員，也可由作者或評審組長兼任 其他人員在數量上沒有限制，可以來自與項目相關的其它組織或部門所有人員都必須具備相關的技術背景知識，對評審的軟件工作產品有足夠的了解，熟悉評審規(guī)程。2. 1作

47、者作者是指被評審的軟件工作產品的作者，其主要職責如下: 準備相關的評審資料 完成評審后的修改工作2. 2評審組長評審組長必須為該軟件工作產品所屬領域的高級技術人員，其主要職責如下： 指導作者組織并實施評審活動，對評審材料進行初審，確定參加評審的人員 按照評審規(guī)程主持評審會議 在評審會議上控制評審進度，提醒參加者不要在某一問題上花費過多時間 對評審中發(fā)現的問題進行分析判斷，確定處理辦法，建議為兩類：1. 問題項：當場確定為問題，需要解決2. 調查項：無法確定是否為主要問題，需要進一步調查確認 決定評審結果（通過和再評審）2. 3記錄員記錄員在評審會議中記錄發(fā)現的問題及相關的數據，其主要職責如下:

48、 填寫評審記錄表 作為評審員參與評審2.4其他參與人員其他人員評審軟件工作產品，回答問題.參與討論同時幫助解決問題。所有的參與人員都必須嚴 格遵循評審規(guī)程.3評審過程評審過程分為四個階段，每一階段都包含一定的任務描述，可以參考評審活動檢查表執(zhí)行評 審。評審活動檢查表是幫助評審人員正確執(zhí)行評審的工具，它與本章所描述的各階段的具體活動 是一致的。評審過程的四個階段為：計劃、準備、執(zhí)行和整理。每一階段必須順序地執(zhí)行，才能保證評審 成功。下而將詳細描述這四個步驟。3. 1計劃階段這是評審的第一階段，其每一步都有詳細說明，只有計劃階段的任務完成后才能進入準備階段。3. 1.1進入條件 軟件工作產品滿足規(guī)

49、范要求 軟件工作產品經過拼寫檢查3. 1.2目的 確保作者提供正確的評審材料 確保軟件工作產品滿足評審要求 確定評審員并明確其職責3. 1. 3活動 作者準備評審所需的材料，包含被評審的軟件工作產品、支持材料及評審表格等 技術委員會指定評審組長 評審組長檢查進入標準是否滿足 技術委員會確定參評人員。也可由技術委員會委托評審組長確定需要參加評審的人員 評審組長確認作者準備好所需要的材料 評審組長與作者共同確定評審會議口程3. 2準備階段3. 2. 1進入條件 評審材料己準備好 參加者對被評審的軟件工作產品具備必要的背景知識 評審組長確認評審材料符合要求3. 2.2目的 評審員明確自己的職貴 所有評審員在評審之前得到評審材料 確保評審員在評審之前閱讀評審材料，找出問題323活動 作者發(fā)評審會議通知給所有評審員 作者將評審材料分發(fā)給所有評審員 評審組長標識軟件工作產品的范圍，強調重點，提取問題 評審組長熟悉議程，確保評審進度 評審員仔細閱讀評審材料，在評審材料上做評注，找出問題 所有評審員記錄自己準備所花費的時間3. 3執(zhí)行階段執(zhí)行評審必須召開評審會議，所有評審員進行而對而地討論是必要的。3. 3.1進入條件 所有評審員得到評審材料 所有評審員根據自己的角色要求準備并且評審軟件工作產品 所