軟件項目管理規(guī)范

疾病管理平臺疾病管理平臺 軟件開發(fā)管理規(guī)范軟件開發(fā)管理規(guī)范 生效日期 2016 2 19 受控編號 文件編號 BD jsgf002 版次 Ver1 0修改狀態(tài) 總頁數(shù) 30 正文 28 附錄 0 編制 李杰審核 王懷鋒批準 付光偉 山東諾安諾泰信息系統(tǒng)有限公司 軟件開發(fā)行為規(guī)范軟件開發(fā)行為規(guī)范 為了把公司已經(jīng)發(fā)布的軟件開發(fā)過程規(guī)范有效地運作于產(chǎn)品開發(fā)活動中 把各種規(guī)范 逐步形成工程師的作業(yè)規(guī)范 特制定本軟件開發(fā)行為規(guī)范 以達到過程控制的目的 與軟件開發(fā)相關(guān)的所有人員 包括各級經(jīng)理和工程師都必須遵守本軟件開發(fā)行為規(guī)范 對違反規(guī)范的開發(fā)行為 必須按照有關(guān)管理規(guī)定進行處罰 本軟件開發(fā)行為規(guī)范的內(nèi)容包括 軟件需求分析 軟件項目計劃 概要設計 詳細設計 編碼 需求管理 配置管理 軟件質(zhì)量保證 數(shù)據(jù)度量和分析等 本軟件開發(fā)行為規(guī)范 采用以下的術(shù)語描述 規(guī)則規(guī)則 在軟件開發(fā)過程中強制必須遵守的行為規(guī)范 建議建議 軟件開發(fā)過程中必須加以考慮的行為規(guī)范 說明說明 對此規(guī)則或建議進行必要的解釋 示例示例 對此規(guī)則或建議從正或反兩個方面給出例子 本軟件開發(fā)過程行為規(guī)范由研究技術(shù)管理處負責解釋和維護 目目 錄錄 1 軟件需求分析5 2 軟件項目計劃9 3 概要設計11 4 詳細設計14 5 編碼18 6 需求管理19 7 軟件配置管理21 8 軟件質(zhì)量保證23 9 數(shù)據(jù)度量和分析25 1 軟件需求分析軟件需求分析 1 1 軟件需求分析必須在產(chǎn)品需求規(guī)格的基礎上進行 并保證完全實現(xiàn)產(chǎn)品需求規(guī)格的定義 軟件需求分析必須在產(chǎn)品需求規(guī)格的基礎上進行 并保證完全實現(xiàn)產(chǎn)品需求規(guī)格的定義 1 2 當產(chǎn)品的需求規(guī)格發(fā)生變更時 必須修訂軟件需求規(guī)格文檔 軟件需求規(guī)格的變更必須 當產(chǎn)品的需求規(guī)格發(fā)生變更時 必須修訂軟件需求規(guī)格文檔 軟件需求規(guī)格的變更必須 經(jīng)過評審 并保存評審記錄 經(jīng)過評審 并保存評審記錄 1 3 必須對軟件需求規(guī)格文檔進行正規(guī)檢視 必須對軟件需求規(guī)格文檔進行正規(guī)檢視 1 4 軟件需求分析過程活動結(jié)束前 必須經(jīng)過評審 并保存評審記錄 軟件需求分析過程活動結(jié)束前 必須經(jīng)過評審 并保存評審記錄 1 5 在對軟件需求規(guī)格文檔的正規(guī)檢視或評審時 必須檢查軟件需求規(guī)格文檔中需求的清晰 在對軟件需求規(guī)格文檔的正規(guī)檢視或評審時 必須檢查軟件需求規(guī)格文檔中需求的清晰 性 完備性 兼容性 一致性 正確性 可行性 易修改性 健壯性 易追溯性 易理解性 性 完備性 兼容性 一致性 正確性 可行性 易修改性 健壯性 易追溯性 易理解性 易測試性和可驗證性 性能 功能 接口 數(shù)據(jù) 可維護性等內(nèi)容 易測試性和可驗證性 性能 功能 接口 數(shù)據(jù) 可維護性等內(nèi)容 說明 參考建議1 1到1 16 1 1 采用以下檢查表檢查軟件需求規(guī)格文檔中需求的清晰性 采用以下檢查表檢查軟件需求規(guī)格文檔中需求的清晰性 序號問題 1所有定義 實現(xiàn)方法是否清楚地表達了用戶的原始要求 2在功能實現(xiàn)過程 方法和技術(shù)要求的描述上 是否沒有背離了功能的實 際要求 3是否沒有不能理解或造成誤解的描述 1 2 采用以下檢查表檢查軟件需求規(guī)格文檔中需求的完備性 采用以下檢查表檢查軟件需求規(guī)格文檔中需求的完備性 序號問題 1需求定義中是否包含了有關(guān)文件 指質(zhì)量手冊 質(zhì)量計劃以及其它有關(guān) 文件 種所規(guī)定的需求定義所應該包含的所有內(nèi)容 2需求定義是否包含了有關(guān)功能 性能 限制 目標 質(zhì)量等方面的所有 需求 3功能性需求是否覆蓋了所有非正常情況的處理 4是否對各種操作模式 如正常 非正常 有干擾等 下的環(huán)境條件都作 了規(guī)定 5是否對所有功能與時間因素有關(guān)的方面都作了考慮 6是否標識出了所有與時間因素有關(guān)的功能 它們的時間準則是否都說明 了 時間準則的最大 最小執(zhí)行時間是否都定義了 7是否標識并定義了在將來可能會變化的需求 8是否定義了系統(tǒng)所有的輸入 9是否標識清楚了系統(tǒng)輸入的來源 10是否標識出了系統(tǒng)的輸出 11是否說明了系統(tǒng)輸入 輸出的類型 12是否說明了系統(tǒng)輸入 輸出的值域 單位 格式等 13是否說明了如何進行系統(tǒng)輸入的合法性檢查 14是否定義了系統(tǒng)輸入 輸出的精度 15是否定義了系統(tǒng)性能的各個方面 16在不同負載情況下 是否規(guī)定了系統(tǒng)的處理能力 17在不同情況下 是否規(guī)定了系統(tǒng)的響應時間 18是否充分定義了關(guān)于人機界面的需求 19是否對需求定義進行了可行性分析和相關(guān)文件 資料 是否已歸檔 20是否對影響需求實現(xiàn)的因素進行了調(diào)查 調(diào)查結(jié)果是否已歸檔 21是否有經(jīng)濟效益分析 分析結(jié)果是否已歸檔 22是否詳細描述了有關(guān)硬件 軟件 操作人員 操作過程等方面的安全性 23是否評估了本項目對用戶 其它系統(tǒng) 環(huán)境的影響特性 24是否按完成時間 重要性對系統(tǒng)功能 外部接口 性能進行了優(yōu)先排序 1 3 采用以下檢查表檢查軟件需求規(guī)格文檔中需求的兼容性 采用以下檢查表檢查軟件需求規(guī)格文檔中需求的兼容性 序號問題 1界面需求是否使軟硬件系統(tǒng)具有兼容性 2需求定義的文檔是否滿足項目文檔編寫標準 在矛盾時 是否有適當?shù)?標準可供選擇 1 4 采用以下檢查表檢查軟件需求規(guī)格文檔中需求的一致性 采用以下檢查表檢查軟件需求規(guī)格文檔中需求的一致性 序號問題 1各個需求之間是否一致 是否有沖突和矛盾 2所規(guī)定的模型 算法和數(shù)值方法是否相容 3是否使用了標準的術(shù)語和定義形式 4需求是否與其軟硬件操作環(huán)境相容 5是否說明了軟件對其系統(tǒng)和環(huán)境的影響 6是否說明了環(huán)境對軟件的影響 7所采用的技術(shù)是否與用戶要求的技術(shù)一致 1 5 采用以下檢查表檢查軟件需求規(guī)格文檔中需求的正確性 采用以下檢查表檢查軟件需求規(guī)格文檔中需求的正確性 序號問題 1需求定義是否滿足標準的要求 2算法和規(guī)則是否有科技文獻或其它文獻作為基礎 3是否定義了對在錯誤 風險分析中所標識出的各種故障模式和錯誤類型 所需的反應 4是否參照了有關(guān)的標準 5是否對每一個需求都給出了理由 理由是否充分 6對設計和實現(xiàn)的限制是否都有論證 1 6 采用以下檢查表檢查軟件需求規(guī)格文檔中需求的可行性 采用以下檢查表檢查軟件需求規(guī)格文檔中需求的可行性 序號問題 1需求定義是否使軟件的設計 實現(xiàn) 操作和維護都可行 2所規(guī)定的模型 數(shù)值方法和算法是否對待解決問題合適 是否能夠在相 應的限制條件下實現(xiàn) 3是否能夠達到關(guān)于質(zhì)量的要求 1 7 采用以下檢查表檢查軟件需求規(guī)格文檔中需求的易修改性 采用以下檢查表檢查軟件需求規(guī)格文檔中需求的易修改性 序號問題 1對需求定義的描述是否易于修改 如是否采用良好的結(jié)構(gòu)和交叉引用表 等 2是否有冗余的信息 是否一個需求被定義了多次 1 8 采用以下檢查表檢查軟件需求規(guī)格文檔中需求的健壯性 采用以下檢查表檢查軟件需求規(guī)格文檔中需求的健壯性 序號問題 1是否有容錯的需求 1 9 采用以下檢查表檢查軟件需求規(guī)格文檔中需求的易追溯性 采用以下檢查表檢查軟件需求規(guī)格文檔中需求的易追溯性 序號問題 1是否可從上一階段的文檔中找到需求定義中的相應內(nèi)容 2需求定義是否明確地表明前階段中提出的有關(guān)需求和設計限制都已被覆 蓋了 3需求定義是否便于向后繼開發(fā)階段查找信息 1 10 采用以下檢查表檢查軟件需求規(guī)格文檔中需求的易理解性 采用以下檢查表檢查軟件需求規(guī)格文檔中需求的易理解性 序號問題 1是否每一個需求都只有一種解釋 2功能性需求是否以模塊方式描述的 是否明確地標識出了其功能 3是否有術(shù)語定義一覽表 4是否使用了形式化或半形式化的語言 5語言是否有歧義性 6需求定義中是否只包含了必須的實現(xiàn)細節(jié)而不包含不必要的實現(xiàn)細節(jié) 是否過分細致了 7需求定義是否足夠清楚和明確使其能夠作為開發(fā)設計規(guī)約和功能性測試 數(shù)據(jù)的基礎 8需求定義的描述是否將對程序的需求和所提供的其它信息分離開來了 1 11 采用以下檢查表檢查軟件需求規(guī)格文檔中需求的易測試性和可驗證性 采用以下檢查表檢查軟件需求規(guī)格文檔中需求的易測試性和可驗證性 序號問題 1需求是否可以驗證 即是否可以檢驗軟件是否滿足了需求 2是否對每一個需求都指定了驗證過程 3數(shù)學函數(shù)的定義是否使用了精確定義的語法和語義符號 1 12 采用以下檢查表檢查軟件需求規(guī)格文檔中的性能需求描述 采用以下檢查表檢查軟件需求規(guī)格文檔中的性能需求描述 序號問題 是否精確的描述了所有的性能需求和可容忍的性能降低程度 對每一個 性能應包含兩方面的內(nèi)容 1 a 在最壞情況的執(zhí)行結(jié)果 2 b 本性能失效后 對系統(tǒng)產(chǎn)生的影響 1 13 采用以下檢查表檢查軟件需求規(guī)格文檔中功能需求描述 采用以下檢查表檢查軟件需求規(guī)格文檔中功能需求描述 序號問題 1是否清楚 明確地描述了所有的功能 2所有已描述的功能是否是必須的 是否能滿足任務書或系統(tǒng)目標的要求 1 14 采用以下檢查表檢查軟件需求規(guī)格文檔中的接口需求描述 采用以下檢查表檢查軟件需求規(guī)格文檔中的接口需求描述 序號問題 1是否清楚地定義了所有的接口 3所有接口是否必須 各接口間的關(guān)系是否一致 正確 1 15 采用以下檢查表檢查軟件需求規(guī)格文檔中的數(shù)據(jù)需求描述 采用以下檢查表檢查軟件需求規(guī)格文檔中的數(shù)據(jù)需求描述 序號問題 1在某異常數(shù)據(jù) 如條件 標志等 下 是否有真正沒有考慮到的結(jié)果 2對異常數(shù)據(jù)產(chǎn)生的結(jié)果是否作了精確的描述 1 16 采用以下檢查表檢查軟件需求規(guī)格文檔中的可維護性需求描述 采用以下檢查表檢查軟件需求規(guī)格文檔中的可維護性需求描述 序號問題 1需求定義中是否包括了可行的系統(tǒng)維護方法 2軟件系統(tǒng)間的關(guān)系是否是松耦合的 即能否保證在對某部分修改后 產(chǎn) 生最小的連鎖效應 僅供內(nèi)部使用8 2 軟件項目計劃軟件項目計劃 2 1 軟件項目計劃必須以產(chǎn)品 軟件項目計劃必須以產(chǎn)品 軟件的需求規(guī)格為基礎 當發(fā)生需求更改時 必須修訂軟件軟件的需求規(guī)格為基礎 當發(fā)生需求更改時 必須修訂軟件 開發(fā)計劃 開發(fā)計劃 說明 軟件項目計劃必須依據(jù)需求規(guī)格進行制定 項目計劃中的工作產(chǎn)品和工作任務應 保證能完全實現(xiàn)需求規(guī)格的定義 當需求更改時 必須考慮需求更改的相關(guān)性 修訂相 應軟件開發(fā)計劃 2 1 制定軟件項目計劃的活動制定 必須遵守 制定軟件項目計劃的活動制定 必須遵守 軟件項目計劃規(guī)范軟件項目計劃規(guī)范 2 2 軟件經(jīng)理對軟件項目計劃的制定和結(jié)果負責 軟件經(jīng)理對軟件項目計劃的制定和結(jié)果負責 2 3 軟件經(jīng)理和相關(guān)參與軟件項目計劃的制定和評審的人員 在參與計劃制定之前必須經(jīng)過 軟件經(jīng)理和相關(guān)參與軟件項目計劃的制定和評審的人員 在參與計劃制定之前必須經(jīng)過 軟件工程和軟件項目計劃制定流程的培訓 軟件工程和軟件項目計劃制定流程的培訓 2 2 對于軟件項目計劃中各項工作產(chǎn)品和工作任務 必須進行規(guī)模和工作量的軟件估計 并 對于軟件項目計劃中各項工作產(chǎn)品和工作任務 必須進行規(guī)模和工作量的軟件估計 并 在軟件項目計劃文檔中記錄估計的方法和估計數(shù)據(jù) 在軟件項目計劃文檔中記錄估計的方法和估計數(shù)據(jù) 說明 參考建議2 4到2 8 2 4 可以使用 可以使用PERT統(tǒng)計估計 專家判定平均法 經(jīng)驗類比估計 公式計算等方法 或以上統(tǒng)計估計 專家判定平均法 經(jīng)驗類比估計 公式計算等方法 或以上 方法的組合 進行軟件估計 方法的組合 進行軟件估計 示例 PERT統(tǒng)計估計和經(jīng)驗類比估計的結(jié)合 PERT統(tǒng)計估計值 最大估計 4 期望估計 最小估計 6 估計記錄如下 工作產(chǎn) 品任務 最大估計期望估計 根據(jù)經(jīng)驗 類比獲得 最小估計PERT估計 規(guī)模工作量規(guī)模工作量規(guī)模工作量規(guī)模工作量 XX版本 增加 XX特性 話統(tǒng)模 塊概要 設計 文檔頁 數(shù) 45 增 加 修 改模塊 設計數(shù) 目 12 12天文檔頁 數(shù) 42 增 加 修 改模塊 設計數(shù) 目 10 10天文檔頁 數(shù) 30 增 加 修 改模塊 設計數(shù) 目 5 5天文檔頁 數(shù) 41 增 加 修 改模塊 設計數(shù) 目 10 9 5天 期望估計值是根據(jù)XX版本的話統(tǒng)模塊設計的數(shù)據(jù)獲得 僅供內(nèi)部使用9 2 5 對某項工作產(chǎn)品和任務的軟件 同時采用兩種或以上的方法進行估計 以避免一種方法 對某項工作產(chǎn)品和任務的軟件 同時采用兩種或以上的方法進行估計 以避免一種方法 的偏差 的偏差 2 6 盡量采用歷史經(jīng)驗數(shù)據(jù)進行軟件估計 盡量采用歷史經(jīng)驗數(shù)據(jù)進行軟件估計 2 7 參照 參照 軟件估計指導書軟件估計指導書 進行軟件估計 進行軟件估計 2 8 軟件估計對應項目的任務分解結(jié)構(gòu)進行 軟件估計對應項目的任務分解結(jié)構(gòu)進行 說明 軟件估計對于項目的任務分解結(jié)構(gòu)對應得越清晰 越細致 相應的估計越準確 2 9 在 在 軟件項目計劃軟件項目計劃 中必須包括項目管理活動的計劃 中必須包括項目管理活動的計劃 2 10 在 在 軟件項目計劃軟件項目計劃 中包括軟件重用計劃 包括重用軟件部件的計劃和開發(fā)可重用軟件中包括軟件重用計劃 包括重用軟件部件的計劃和開發(fā)可重用軟件 部件的計劃 部件的計劃 2 11 在在 軟件項目計劃軟件項目計劃 包括人員的培訓計劃 包括人員的培訓計劃 說明 項目人員計劃包括需要的人員類型 數(shù)量和技術(shù)等級的要求 相關(guān)人員的開始工 作時間 工作周期 接受培訓的計劃等 2 12 對軟件項目進行風險分析與評估 對軟件項目進行風險分析與評估 說明 可能存在的風險領(lǐng)域含 需求的不明確和變更 外部的限制與對外的依賴 人力 資源的到位情況 人力資源的技術(shù)等級滿足要求狀況 技術(shù)問題等 對風險的分析與評估實踐包括 從已知的情況推導出潛在風險 對風險進行分析 得出 潛在風險可能引發(fā)的問題的影響 潛在風險發(fā)生的可能性大小 風險發(fā)生的時間段等 排列風險的重點次序 對風險記錄成文件 屬于軟件項目計劃中的一部分 風險經(jīng)受風險影響人審核 并取得他的同意 根據(jù)需要 在開發(fā)過程中對風險文檔進行維護和修訂 2 3 對應工作任務 制定項目的文檔計劃 對應工作任務 制定項目的文檔計劃 2 4 軟件項目計劃中應該包括正規(guī)檢視活動計劃 軟件質(zhì)量保證計劃 軟件配置管理計劃 軟件項目計劃中應該包括正規(guī)檢視活動計劃 軟件質(zhì)量保證計劃 軟件配置管理計劃 軟件質(zhì)量保證計劃和軟件配置管理計劃可以和軟件項目計劃在同一份文檔中 也可以分開為三軟件質(zhì)量保證計劃和軟件配置管理計劃可以和軟件項目計劃在同一份文檔中 也可以分開為三 份文檔 份文檔 僅供內(nèi)部使用10 說明 參考建議2 13 2 13 軟件質(zhì)量保證計劃和軟件配置管理計劃作為獨立的計劃文檔 軟件質(zhì)量保證計劃和軟件配置管理計劃作為獨立的計劃文檔 2 14 軟件項目計劃必須是整個項目開發(fā)過程的計劃 包括測試 軟件項目計劃必須是整個項目開發(fā)過程的計劃 包括測試 2 15 測試經(jīng)理對照整個開發(fā)計劃建立軟件驗證與確認計劃 軟件驗證與確認計劃可作為獨立 測試經(jīng)理對照整個開發(fā)計劃建立軟件驗證與確認計劃 軟件驗證與確認計劃可作為獨立 的計劃文檔 的計劃文檔 2 5 必須對項目工作進行分解 確定項目的工作任務 任務的責任人 資源要求 時間要求 必須對項目工作進行分解 確定項目的工作任務 任務的責任人 資源要求 時間要求 項目的進度 項目的進度 2 6 必須分析任務之間的依賴性 確定并明確標識項目的關(guān)鍵路徑 必須分析任務之間的依賴性 確定并明確標識項目的關(guān)鍵路徑 2 7 軟件項目計劃軟件項目計劃 必須按照文檔模板的要求編寫 項目組可根據(jù)項目的實際情況 對文必須按照文檔模板的要求編寫 項目組可根據(jù)項目的實際情況 對文 檔模板中的內(nèi)容進行裁減 項目組對文檔模板內(nèi)容的裁減必須得到上級管理部門 包括產(chǎn)品計檔模板中的內(nèi)容進行裁減 項目組對文檔模板內(nèi)容的裁減必須得到上級管理部門 包括產(chǎn)品計 劃處 軟件工程組劃處 軟件工程組SEPG 的審核批準 的審核批準 2 8 軟件項目計劃必須經(jīng)過評審 軟件項目計劃必須經(jīng)過評審 說明 參考建議2 16 2 16 軟件項目計劃的評審采用以下檢查表 軟件項目計劃的評審采用以下檢查表 序號序號問題問題 1軟件項目計劃是否完全反映 對應 軟件需求說明書 里的需求 2軟件項目計劃是否有開發(fā)方法的說明 3軟件項目計劃是否有資源需求的說明 4軟件項目計劃是否包含風險管理計劃 5軟件項目計劃是否包含了版本發(fā)布的機制 6軟件項目計劃是否標識了所有必須的培訓計劃 7 軟件項目計劃是否標識了所有內(nèi)部和外部的傳遞關(guān)系 8 軟件項目計劃是否標明了項目的依賴關(guān)系 9 軟件項目計劃是否標明了角色和職責 10 軟件項目計劃是否標明了匯報的機制 11軟件項目計劃是否說明了跟蹤和監(jiān)控機制 12軟件項目計劃是否包含 軟件質(zhì)量保證計劃 和 軟件配置管理計劃 13軟件項目計劃是否包含項目開發(fā)使用的工具 14軟件項目計劃是否包含項目的各里程碑的說明 15進度中是否標明了軟件項目計劃的關(guān)鍵路徑 僅供內(nèi)部使用11 2 17 參加 參加 軟件項目計劃軟件項目計劃 評審的人員 除軟件經(jīng)理和項目組人員外 必須有產(chǎn)品經(jīng)理 上評審的人員 除軟件經(jīng)理和項目組人員外 必須有產(chǎn)品經(jīng)理 上 級管理部門 包括軟件工程組級管理部門 包括軟件工程組SEPG SQA人員 人員 2 18 軟件項目計劃軟件項目計劃 通過評審后 軟件經(jīng)理組織相關(guān)人員對任務進行承諾 簽定工作任務通過評審后 軟件經(jīng)理組織相關(guān)人員對任務進行承諾 簽定工作任務 書 書 2 9 必須對 必須對 軟件項目計劃軟件項目計劃 進行配置管理 進行配置管理 軟件項目計劃軟件項目計劃 的更改必須經(jīng)過評審 的更改必須經(jīng)過評審 2 10 在開發(fā)活動中 必須按照項目跟蹤與監(jiān)控計劃和體制 對照 在開發(fā)活動中 必須按照項目跟蹤與監(jiān)控計劃和體制 對照 軟件項目計劃軟件項目計劃 跟蹤 跟蹤 項目開發(fā)的實際結(jié)果和性能 項目開發(fā)的實際結(jié)果和性能 2 11 當實際結(jié)果和 當實際結(jié)果和 軟件項目計劃軟件項目計劃 發(fā)生偏離時 必須進行分析 根據(jù)分析結(jié)果標明糾正發(fā)生偏離時 必須進行分析 根據(jù)分析結(jié)果標明糾正 措施 必要的情況下 要及時修訂措施 必要的情況下 要及時修訂 軟件項目計劃軟件項目計劃 2 12 在軟件項目跟蹤監(jiān)控活動中 必須定期進行總結(jié)和評審 撰寫開發(fā)狀態(tài)報告 在軟件項目跟蹤監(jiān)控活動中 必須定期進行總結(jié)和評審 撰寫開發(fā)狀態(tài)報告 2 19 根據(jù)項目的特點 報告的周期可以為周 雙周 月 根據(jù)項目的特點 報告的周期可以為周 雙周 月 2 13 在軟件開發(fā)各里程碑階段結(jié)束前 必須進行階段評審 對軟件項目進行重估計 必要 在軟件開發(fā)各里程碑階段結(jié)束前 必須進行階段評審 對軟件項目進行重估計 必要 的情況下修訂的情況下修訂 軟件項目計劃軟件項目計劃 2 20 必須提供相應資源 包括工具和人員等 進行軟件項目計劃和項目跟蹤監(jiān)控活動 必須提供相應資源 包括工具和人員等 進行軟件項目計劃和項目跟蹤監(jiān)控活動 2 14 在軟件項目計劃和項目跟蹤監(jiān)控過程活動中 必須進行數(shù)據(jù)度量和分析 在軟件項目計劃和項目跟蹤監(jiān)控過程活動中 必須進行數(shù)據(jù)度量和分析 說明 參見 9 數(shù)據(jù)度量和分析 軟件開發(fā)行為規(guī)范3 概要設計 僅供內(nèi)部使用12 3 概要設計概要設計 3 1 概要設計要以軟件需求規(guī)格為基礎 必須保證需要實現(xiàn)的需求規(guī)格已經(jīng)被設計 概要設計要以軟件需求規(guī)格為基礎 必須保證需要實現(xiàn)的需求規(guī)格已經(jīng)被設計 3 2 當需求規(guī)格發(fā)生變更時 必須修訂相關(guān)概要設計文檔 當需求規(guī)格發(fā)生變更時 必須修訂相關(guān)概要設計文檔 3 3 在概要設計文檔或需求管理文檔中 必須記錄 驗證需求和概要設計的跟蹤關(guān)系 在概要設計文檔或需求管理文檔中 必須記錄 驗證需求和概要設計的跟蹤關(guān)系 說明 需求和概要設計的跟蹤關(guān)系可參考建議3 1 3 1 采用需求 子系統(tǒng) 模塊的跟蹤矩陣表記錄需求和概要設計的跟蹤關(guān)系 采用需求 子系統(tǒng) 模塊的跟蹤矩陣表記錄需求和概要設計的跟蹤關(guān)系 3 4 必須保證概要設計文檔和代碼的一致性 當發(fā)生設計更改時 必須修訂相應設計文檔 必須保證概要設計文檔和代碼的一致性 當發(fā)生設計更改時 必須修訂相應設計文檔 3 5 必須對概要設計文檔進行正規(guī)檢視 必須對概要設計文檔進行正規(guī)檢視 3 6 概要設計過程結(jié)束前 必須通過評審 并保存評審記錄 概要設計過程結(jié)束前 必須通過評審 并保存評審記錄 3 7 設計更改必須經(jīng)過相關(guān)評審 并保存評審記錄 設計更改必須經(jīng)過相關(guān)評審 并保存評審記錄 3 8 對概要設計文檔的正規(guī)檢視或評審 必須檢查概要設計文檔的清晰性 完備性 規(guī)范性 對概要設計文檔的正規(guī)檢視或評審 必須檢查概要設計文檔的清晰性 完備性 規(guī)范性 一致性 正確性 數(shù)據(jù) 功能性 接口 詳細程度 可維護性 性能 可靠性 可測試性 可一致性 正確性 數(shù)據(jù) 功能性 接口 詳細程度 可維護性 性能 可靠性 可測試性 可 追溯性 追溯性 說明 參考建議3 2 3 2 采用以下檢查表檢查概要設計文檔的清晰性 采用以下檢查表檢查概要設計文檔的清晰性 序號問題 1程序結(jié)構(gòu) 包括數(shù)據(jù)流 控制流和接口的描述是否清楚 3 3 采用以下檢查表檢查概要設計文檔的完備性 采用以下檢查表檢查概要設計文檔的完備性 序號問題 1設計目標是否定義 2需求規(guī)格評審中不完整的需求 TBD 是否都已經(jīng)解決 3如果以前定義的不完整的需求 TBD 發(fā)生了改變 本設計是否能夠支持 4是否對不完整需求 TBD 的影響進行了評估 5對有可能不能實現(xiàn)的設計是否有風險管理計劃 6是否對設計模式進行了描述 3 4 采用以下檢查表檢查概要設計文檔的規(guī)范性 采用以下檢查表檢查概要設計文檔的規(guī)范性 軟件開發(fā)行為規(guī)范3 概要設計 僅供內(nèi)部使用13 序號問題 1文檔是否符合公司模板和寫作要求 3 5 采用以下檢查表檢查概要設計文檔的一致性 采用以下檢查表檢查概要設計文檔的一致性 序號問題 2 程序 模塊 函數(shù) 數(shù)據(jù)成員的名稱是否保持一致 3 設計是否反映了真正的操作環(huán)境 硬件環(huán)境 軟件環(huán)境 4 對系統(tǒng)設計的多種可能的描述之間是否保持一致 例如 靜態(tài)結(jié)構(gòu)的描 述和動態(tài)描述 3 6 采用以下檢查表檢查概要設計文檔的正確性 采用以下檢查表檢查概要設計文檔的正確性 序號問題 1設計在計劃 預算 技術(shù)上是否可行 2邏輯是否正確和完備 3 7 采用以下檢查表檢查概要設計文檔的數(shù)據(jù)描述 采用以下檢查表檢查概要設計文檔的數(shù)據(jù)描述 序號問題 1是否對所有的數(shù)據(jù)成員 參數(shù) 對象進行了描述 2是否所有需要的數(shù)據(jù)結(jié)構(gòu)都進行了定義 或者定義了不需要的數(shù)據(jù)結(jié)構(gòu) 3是否所有的數(shù)據(jù)成員都進行了足夠詳細的描述 數(shù)據(jù)成員的有效值區(qū) 間是否定義 4共享和存儲數(shù)據(jù)的使用是否描述清楚 3 8 采用以下檢查表檢查概要設計文檔的功能性要求 采用以下檢查表檢查概要設計文檔的功能性要求 序號問題 1模塊的規(guī)格是否和軟件需求文檔中的功能需求和軟件接口規(guī)格要求保 持一致 2 是否給每個子模塊確定了抽象算法 3設計和算法是否能滿足模塊的所有需求 3 9 采用以下檢查表檢查設計的接口描述 采用以下檢查表檢查設計的接口描述 序號問題 1是否描述了接口的功能特征 2接口是否便于查錯 3接口相互之間 和其他模塊 和需求說明書及接口規(guī)格書保持一致 4對接口的數(shù)量和復雜度進行了有效的平衡 使接口數(shù)量控制在一個較小 數(shù)量 每個接口具有可接受的復雜度 5是否所有的接口都能描述了必要的類型 數(shù)量 質(zhì)量等信息 6操作界面是否考慮了用戶 例如 提供準確 清晰 有用的提示信息 3 10 采用以下檢查表檢查設計的詳細程度 采用以下檢查表檢查設計的詳細程度 軟件開發(fā)行為規(guī)范3 概要設計 僅供內(nèi)部使用14 序號問題 1是否估計了每個子模塊的規(guī)模 代碼的行數(shù) 是否可信 2是否考慮了足夠數(shù)量及代表性的系統(tǒng)狀態(tài) 3詳細程度是否足夠進行下一步的詳細設計 3 11 采用以下檢查表檢查設計的可維護性 采用以下檢查表檢查設計的可維護性 序號問題 1是否模塊化設計 2模塊是否為高內(nèi)聚 低耦合 3 12 采用以下檢查表檢查設計的性能 采用以下檢查表檢查設計的性能 序號問題 1是否進行了性能模型分析 2是否描述了所有的性能參數(shù) 例如 實時性能約束 存儲空間 速度 要求 磁盤I O空間 3 進程是否有時間窗 例如 需要 加鎖 的標記 信號燈 某些代 碼執(zhí)行時需要屏蔽中斷 4程序執(zhí)行過程中的關(guān)鍵路徑是否都被標識和經(jīng)過分析 3 13 采用以下檢查表檢查設計的可靠性 采用以下檢查表檢查設計的可靠性 序號問題 1設計是否考慮了檢錯和恢復措施 例如 輸入檢查 2是否考慮了異常情況 3是否完全準確描述了所有的出錯情況 4設計是否能夠滿足所有系統(tǒng)集成方面的要求 3 14 采用以下檢查表檢查設計的可測試性 采用以下檢查表檢查設計的可測試性 序號問題 1設計是否能夠被實驗 演示或檢視以顯示它滿足了需求 2設計是否能夠使用以前的測試代碼 是否能夠進行增量式的測試 3 15 采用以下檢查表檢查設計的可追溯性 采用以下檢查表檢查設計的可追溯性 序號問題 1是否每一部分的設計都可以追溯到需求說明書 接口規(guī)格說明書 或 其他產(chǎn)品文檔 2是否所有的設計決策都可以追溯到財務分析 3對所繼承下來的那些特別和不常用的特性對目前設計的影響是否進行 了分析 4對所繼承設計中已知的風險是否進行了定位和分析 軟件開發(fā)行為規(guī)范4 詳細設計 僅供內(nèi)部使用15 4 詳細設計詳細設計 4 1 詳細設計要以軟件需求規(guī)格和概要設計為基礎 必須保證需要實現(xiàn)的需求規(guī)格已經(jīng)被設 詳細設計要以軟件需求規(guī)格和概要設計為基礎 必須保證需要實現(xiàn)的需求規(guī)格已經(jīng)被設 計 必須保證概要設計定義的所有模塊已經(jīng)被詳細設計 計 必須保證概要設計定義的所有模塊已經(jīng)被詳細設計 4 2 當需求規(guī)格或概要設計發(fā)生變更時 必須修訂相關(guān)詳細設計文檔 當需求規(guī)格或概要設計發(fā)生變更時 必須修訂相關(guān)詳細設計文檔 4 3 在詳細設計文檔或需求管理文檔中 必須記錄 驗證需求 概要設計 詳細設計的跟蹤 在詳細設計文檔或需求管理文檔中 必須記錄 驗證需求 概要設計 詳細設計的跟蹤 關(guān)系 關(guān)系 說明 需求 概要設計 詳細設計的跟蹤關(guān)系可參考建議4 1 4 1 采用需求 子系統(tǒng) 模塊 函數(shù)的跟蹤矩陣表記錄需求 概要設計 詳細設計的跟蹤關(guān) 采用需求 子系統(tǒng) 模塊 函數(shù)的跟蹤矩陣表記錄需求 概要設計 詳細設計的跟蹤關(guān) 系 系 4 4 必須保證詳細設計文檔和代碼的一致性 當發(fā)生設計更改時 必須修訂相應設計文檔 必須保證詳細設計文檔和代碼的一致性 當發(fā)生設計更改時 必須修訂相應設計文檔 4 5 必須對重要的詳細設計文檔進行正規(guī)檢視 必須對重要的詳細設計文檔進行正規(guī)檢視 說明 參考建議4 2 4 2 根據(jù)模塊的復雜度 規(guī)模和在軟件系統(tǒng)中的重要程度 選擇重要的詳細設計文檔進行正 根據(jù)模塊的復雜度 規(guī)模和在軟件系統(tǒng)中的重要程度 選擇重要的詳細設計文檔進行正 規(guī)檢視 在產(chǎn)品中 進行正規(guī)檢視的詳細設計文檔比例要達到規(guī)檢視 在產(chǎn)品中 進行正規(guī)檢視的詳細設計文檔比例要達到60 4 6 詳細設計過程結(jié)束前 必須通過評審 并保存評審記錄 詳細設計過程結(jié)束前 必須通過評審 并保存評審記錄 4 7 設計更改必須經(jīng)過相關(guān)評審 并保存評審記錄 設計更改必須經(jīng)過相關(guān)評審 并保存評審記錄 4 8 對詳細設計文檔的正規(guī)檢視或評審 必須檢查詳細設計文檔的清晰性 完備性 規(guī)范性 對詳細設計文檔的正規(guī)檢視或評審 必須檢查詳細設計文檔的清晰性 完備性 規(guī)范性 一致性 正確性 數(shù)據(jù) 功能性 接口 詳細程度 可維護性 性能 可靠性 可測試性 可一致性 正確性 數(shù)據(jù) 功能性 接口 詳細程度 可維護性 性能 可靠性 可測試性 可 追溯性 追溯性 說明 參考建議4 3 4 3 采用以下檢查表檢查詳細設計文檔的清晰性 采用以下檢查表檢查詳細設計文檔的清晰性 序號問題 1是否所有的單元和進程的設計目的都已文檔化 2單元設計 包括數(shù)據(jù)流 控制流 接口描述是否清楚 3單元的整體功能是否描述清楚 4 4 采用以下檢查表檢查詳細設計文檔的完備性 采用以下檢查表檢查詳細設計文檔的完備性 軟件開發(fā)行為規(guī)范4 詳細設計 僅供內(nèi)部使用16 序號問題 1是否提供了所有程序單元的規(guī)格 2是否描述了所采用的設計標準 3是否確定了單元應用的算法 例如 PDL 4是否列出了單元的所有調(diào)用 5是否記錄了設計繼承的歷史和已知的風險 4 5 采用以下檢查表檢查詳細設計文檔的規(guī)范性 采用以下檢查表檢查詳細設計文檔的規(guī)范性 序號問題 1文檔是否遵從了公司的標準 2單元設計是否使用了要求的方法和工具 4 6 采用以下檢查表檢查詳細設計的一致性 采用以下檢查表檢查詳細設計的一致性 序號問題 1在單元和單元的接口中數(shù)據(jù)成員的名稱是否保持一致 2所有接口之間 接口和接口規(guī)格書之間是否保持一致 3詳細設計和概要設計文檔是否能夠完全描述 正在構(gòu)建 的系統(tǒng) 4 7 采用以下檢查表檢查詳細設計的正確性 采用以下檢查表檢查詳細設計的正確性 序號問題 1是否有邏輯錯誤 2需要使用常量名稱的地方是否有錯誤 3是否所有的條件都被處理 switch case 4分支所處的狀態(tài)是否正確 邏輯沒有搞反 4 8 采用以下檢查表檢查詳細設計的數(shù)據(jù)描述 采用以下檢查表檢查詳細設計的數(shù)據(jù)描述 序號問題 1是否所有聲明的數(shù)據(jù)塊都已經(jīng)使用 2定位于單元的數(shù)據(jù)結(jié)構(gòu)是否已經(jīng)描述 3如果有對共享數(shù)據(jù) 文件的修改 對數(shù)據(jù)的訪問是否按照正確的共享協(xié) 議進行 例如 通過信號燈同步進程 4是否所有的邏輯單元 事件標記 同步標記都已經(jīng)定義和初始化 5是否所有的變量 指針 常量都已經(jīng)定義并初始化 4 9 采用以下檢查表檢查詳細設計的功能性要求 采用以下檢查表檢查詳細設計的功能性要求 序號問題 1設計是否使用了指定的算法 2設計是否能夠滿足需求和目的 4 10 采用以下檢查表檢查詳細設計的接口描述 采用以下檢查表檢查詳細設計的接口描述 序號問題 1參數(shù)表是否在數(shù)量 類型和順序上保持一致 2是否所有的輸入輸出都已經(jīng)正確定義并檢查過 軟件開發(fā)行為規(guī)范4 詳細設計 僅供內(nèi)部使用17 3所傳遞參數(shù)的順序是否描述清楚 4參數(shù)傳遞的機制是否確定 5通過接口傳遞的常量和變量是否與單元設計的相同 例如 函數(shù)中定 義的常量不能在所調(diào)用的子過程中被修改 6傳入 傳出函數(shù)的參數(shù) 控制標記是否都已經(jīng)描述清楚 7是否以度量單位描述了參數(shù)的值區(qū)間 準確性和精度 4 11 采用以下檢查表檢查詳細設計的詳細程度 采用以下檢查表檢查詳細設計的詳細程度 序號問題 1代碼和文檔間的展開率是否小于10 1 2對模塊的所有需求都已經(jīng)定義 3詳細程度是否足夠開發(fā)和維護代碼 4 12 采用以下檢查表檢查詳細設計的可維護性 采用以下檢查表檢查詳細設計的可維護性 序號問題 1單元是否是高內(nèi)聚和低外部耦合 例如 單元的改變不會在內(nèi)部出現(xiàn) 不可預見的影響 同時對其他單元的影響最小 2是否這種設計是復雜度最小的設計 3開始部分的描述是否符合公司的要求 例如 目的 作者 環(huán)境 非 標準特性 開發(fā)歷史 輸入輸出參數(shù) 使用的文件 數(shù)據(jù)結(jié)構(gòu) 引用此 單元的其他單元 注釋 4 13 采用以下檢查表檢查詳細設計的性能 采用以下檢查表檢查詳細設計的性能 序號問題 1進程是否有時間窗 2是否所有的時間和空間的限制都已明確 4 14 采用以下檢查表檢查詳細設計的可靠性 采用以下檢查表檢查詳細設計的可靠性 序號問題 1初始化時是否使用了默認值 是否正確 2訪問內(nèi)存時是否進行了邊界檢查 以保證地址正確 隊列 數(shù)據(jù)結(jié)構(gòu) 指針 等等 3對輸入 輸出 接口和結(jié)果是否進行了錯誤檢查 4對所有錯誤情況都安排了有意義的消息反饋 5特殊情況下的返回碼是否和文檔中定義的全局返回碼一致 6是否考慮了異常情況 4 15 采用以下檢查表檢查詳細設計的可測試性 采用以下檢查表檢查詳細設計的可測試性 序號問題 1是否每個單元都可以被測試 演示 分析或者檢視 以確認滿足需求 2設計中是否包括輔助測試的檢查點 例如 條件編譯代碼 斷言等 3是否所有的邏輯都是可測的 軟件開發(fā)行為規(guī)范4 詳細設計 僅供內(nèi)部使用18 4是否描述了本單元的測試驅(qū)動模塊 測試用例集 測試結(jié)果 4 16 采用以下檢查表檢查詳細設計的可追溯性 采用以下檢查表檢查詳細設計的可追溯性 序號問題 1是否每一部分的設計都可以追溯到需求 2是否每一個設計決策都可以追溯到效益分析 3是否所有的設計決策都可以追溯到成本 效益分析 4是不是描述了每個單元的詳細需求 5單元需求是否能夠追溯到軟件規(guī)格文檔 SSD 1 軟件規(guī)格文檔是 否能夠跟蹤到單元需求 6是否有到代碼的引用或者包括代碼本身 軟件開發(fā)行為規(guī)范5 編碼 僅供內(nèi)部使用19 5 編碼編碼 5 1 編碼必須以設計文檔為基礎 必須保證所有的設計都被編碼實現(xiàn) 當設計發(fā)生變更時 編碼必須以設計文檔為基礎 必須保證所有的設計都被編碼實現(xiàn) 當設計發(fā)生變更時 必須修改相關(guān)代碼 必須修改相關(guān)代碼 5 2 必須保證設計文檔和代碼的一致性 當代碼的修改已經(jīng)造成設計更改時 必須修訂相應 必須保證設計文檔和代碼的一致性 當代碼的修改已經(jīng)造成設計更改時 必須修訂相應 設計文檔 設計文檔 5 3 必須對重要的代碼進行正規(guī)檢視 必須對重要的代碼進行正規(guī)檢視 說明 參考建議5 1 5 1 根據(jù)模塊 函數(shù) 根據(jù)模塊 函數(shù) 單元單元 進程的復雜度 規(guī)模和在軟件系統(tǒng)中的重要程度 選擇重要的代進程的復雜度 規(guī)模和在軟件系統(tǒng)中的重要程度 選擇重要的代 碼進行正規(guī)檢視 在產(chǎn)品中 進行正規(guī)檢視的代碼比例要達到碼進行正規(guī)檢視 在產(chǎn)品中 進行正規(guī)檢視的代碼比例要達到40 5 4 在代碼已經(jīng)基線化后 對代碼的更改必須通過評審 并保存評審記錄 在代碼已經(jīng)基線化后 對代碼的更改必須通過評審 并保存評審記錄 5 5 代碼必須遵守相關(guān)的編程規(guī)范規(guī)定 代碼必須遵守相關(guān)的編程規(guī)范規(guī)定 5 6 對代碼的正規(guī)檢視和評審 必須依照相關(guān)編程規(guī)范規(guī)定檢查編程規(guī)范符合情況 對代碼的正規(guī)檢視和評審 必須依照相關(guān)編程規(guī)范規(guī)定檢查編程規(guī)范符合情況 軟件開發(fā)行為規(guī)范6 需求管理 僅供內(nèi)部使用20 6 需求管理需求管理 6 1 產(chǎn)品項目必須安排人員負責需求管理的職責 產(chǎn)品項目必須安排人員負責需求管理的職責 說明 職責參見建議6 1 6 1 需求管理的職責至少應包括以下內(nèi)容 需求管理的職責至少應包括以下內(nèi)容 序號內(nèi)容 1在產(chǎn)品項目整個生存周期內(nèi) 管理系統(tǒng)需求和它們的分配 并對其建立文檔 2實現(xiàn)對系統(tǒng)需求及其分配的更改 6 2 必須建立文檔標識分配到軟件中的產(chǎn)品系統(tǒng)需求 必須建立文檔標識分配到軟件中的產(chǎn)品系統(tǒng)需求 說明 文檔的內(nèi)容參見建議6 2 6 2 標識分配到軟件中的產(chǎn)品系統(tǒng)需求的文檔至少應包含以下內(nèi)容標識分配到軟件中的產(chǎn)品系統(tǒng)需求的文檔至少應包含以下內(nèi)容 序號內(nèi)容 1影響和確定軟件項目活動的非技術(shù)性需求 即 協(xié)議 條件 合同條款等 2對軟件的技術(shù)需求 3 用于確認軟件產(chǎn)品滿足分配需求的驗收標準 6 3 相關(guān)人員必須接受需求管理活動方面的培訓 相關(guān)人員必須接受需求管理活動方面的培訓 說明 參見建議6 3 6 3 培訓至少包括以下內(nèi)容培訓至少包括以下內(nèi)容 序號內(nèi)容 1項目所使用的方法 標準 規(guī)程 2應用領(lǐng)域的知識 6 4 必須對對經(jīng)過評審和批準的需求文檔進行管理和控制 必須對對經(jīng)過評審和批準的需求文檔進行管理和控制 說明 參見建議6 4 6 4 對經(jīng)過評審和批準的需求至少應采用以下方法進行管理和控制 對經(jīng)過評審和批準的需求至少應采用以下方法進行管理和控制 序號內(nèi)容 1在配置管理計劃 SCMP 中將需求文檔定義為CI 2對需求文檔進行配置管理 3 相應的參考文檔進行變更 維護 6 5 必須對需求變更采用嚴格的變更控制流程控制 必須對需求變更采用嚴格的變更控制流程控制 說明 參見建議6 5 軟件開發(fā)行為規(guī)范6 需求管理 僅供內(nèi)部使用21 6 5 變更控制流程至少應包含以下內(nèi)容 變更控制流程至少應包含以下內(nèi)容 序號內(nèi)容 1 對變化的影響進行評估 2經(jīng)過CCB組織的評審 3 通知受影響的組和個人 4 跟蹤解決該問題 直到關(guān)閉 6 6 必須在開發(fā)過程中對需求進行跟蹤 必須在開發(fā)過程中對需求進行跟蹤 說明 參見建議6 6 6 6 需求跟蹤活動至少應包括以下內(nèi)容 需求跟蹤活動至少應包括以下內(nèi)容 序號內(nèi)容 1按照公司模板制定 需求跟蹤說明書 2跟蹤需求狀態(tài)的變化 3 需求的跟蹤和分配經(jīng)過評審 6 7 在需求管理活動中必須建立相關(guān)度量記錄 在需求管理活動中必須建立相關(guān)度量記錄 說明 參見建議6 7 6 7 對需求活動的度量至少應包含以下內(nèi)容 對需求活動的度量至少應包含以下內(nèi)容 序號內(nèi)容 1需求的數(shù)量 2需求的狀態(tài) 3 需求的類型 4 需求的更改次數(shù) 6 8 需求管理活動和其文檔必須接受上級管理部門 產(chǎn)品項目經(jīng)理 需求管理活動和其文檔必須接受上級管理部門 產(chǎn)品項目經(jīng)理 SQA的評審 的評審 軟件開發(fā)行為規(guī)范7 軟件配置管理 僅供內(nèi)部使用22 7 軟件配置管理軟件配置管理 7 1 產(chǎn)品項目要任命配置管理的人員和組織 在整個配置管理活動中明確他們的職責 產(chǎn)品項目要任命配置管理的人員和組織 在整個配置管理活動中明確他們的職責 說明 參考建議7 1 7 1 參照 參照 軟件配置管理規(guī)范軟件配置管理規(guī)范 和和 軟件配置管理指導書軟件配置管理指導書 任命 任命SCM組織 組織 7 2 產(chǎn)品項目必須制定軟件配置管理計劃 產(chǎn)品項目必須制定軟件配置管理計劃 SCMP 指導整個配置管理活動 指導整個配置管理活動 說明 參考建議7 2 7 2 項目經(jīng)理根據(jù) 項目經(jīng)理根據(jù) 配置管理計劃 模板 配置管理計劃 模板 負責制定配置管理計劃 負責制定配置管理計劃 7 3 軟件配置管理計劃必須包括如下的內(nèi)容 軟件配置管理計劃必須包括如下的內(nèi)容 序號內(nèi)容 1 對各階段應受控的配置項進行選擇 分類 標識 2 定義配置項 CI 的命名慣例 3定義版本號命名方案 4制定培訓計劃 5定義相關(guān)SCM流程 6制定相應配置評審計劃和方法 7 4 軟件配置管理計劃必須經(jīng)過由開發(fā)人員 產(chǎn)品項目經(jīng)理 軟件配置管理計劃必須經(jīng)過由開發(fā)人員 產(chǎn)品項目經(jīng)理 SQA參加的評審 并獲得批準 參加的評審 并獲得批準 并基線化 并基線化 7 5 軟件配置管理計劃和軟件項目開發(fā)計劃必須同步變更 軟件配置管理計劃和軟件項目開發(fā)計劃必須同步變更 7 6 問題跟蹤要有一套流程支持 該流程要包括問題的描述 分類 評估 設計 實現(xiàn) 驗 問題跟蹤要有一套流程支持 該流程要包括問題的描述 分類 評估 設計 實現(xiàn) 驗 證 歸檔的整個生命過程 證 歸檔的整個生命過程 7 7 變更申請要有一套流程支持 該流程要保證該變更申請 針對已基線化的配置項 有一 變更申請要有一套流程支持 該流程要保證該變更申請 針對已基線化的配置項 有一 個初始化 分類 設計 評估 分派 實現(xiàn) 驗證 歸檔的整個過程 個初始化 分類 設計 評估 分派 實現(xiàn) 驗證 歸檔的整個過程 7 8 每個版本有一個符合規(guī)范的版本描述文檔 每個版本有一個符合規(guī)范的版本描述文檔 7 9 必須定義流程指導配置狀態(tài)發(fā)布 必須定義流程指導配置狀態(tài)發(fā)布 說明 參考建議7 3 7 3 在配置管理計劃中描述配置狀態(tài)發(fā)布的周期 內(nèi)容和模板 在配置管理計劃中描述配置狀態(tài)發(fā)布的周期 內(nèi)容和模板 軟件開發(fā)行為規(guī)范7 軟件配置管理 僅供內(nèi)部使用23 7 10 配置項 配置項 CI 的變更和配置管理活動的運行狀態(tài)通知到相關(guān)的部門組織和個人 的變更和配置管理活動的運行狀態(tài)通知到相關(guān)的部門組織和個人 7 11 定期對變更申請 定期對變更申請 CR 的處理情況進行統(tǒng)計并將統(tǒng)計和分析結(jié)果進行發(fā)布 發(fā)布內(nèi)容至的處理情況進行統(tǒng)計并將統(tǒng)計和分析結(jié)果進行發(fā)布 發(fā)布內(nèi)容至 少包括 單位時間內(nèi)處理的少包括 單位時間內(nèi)處理的CRs數(shù)量 數(shù)量 CRs分布統(tǒng)計表 分布統(tǒng)計表 CRs流通量統(tǒng)計表 流通量統(tǒng)計表 CRs狀態(tài)分布統(tǒng)狀態(tài)分布統(tǒng) 計表等 計表等 說明 參考建議7 4 7 4 建議正常情況 建議正常情況2周發(fā)布一次 更改頻繁時是周發(fā)布一次 更改頻繁時是1周 更改較少時是周 更改較少時是3周周 7 12 建立可以體現(xiàn)開發(fā)版本和基線版本兩種不同受控程度的配置庫系統(tǒng) 建立可以體現(xiàn)開發(fā)版本和基線版本兩種不同受控程度的配置庫系統(tǒng) 說明 參考建議7 5 7 5 建議使用 建議使用SCM工具的分支功能實現(xiàn)不同類型的版本控制工具的分支功能實現(xiàn)不同類型的版本控制 7 13 制定一個基線化流程指導建立基線 制定一個基線化流程指導建立基線 說明 參考建議7 6 7 6 建議在配置管理計劃中對流程進行描述 該流程要保證基線化過程中的物理配置審計 建議在配置管理計劃中對流程進行描述 該流程要保證基線化過程中的物理配置審計 PCA 功能配置審計 功能配置審計 FCA SQA評審和審計等過程 評審和審計等過程 7 14 內(nèi)外的發(fā)布必須只能來自基線庫 內(nèi)外的發(fā)布必須只能來自基線庫 7 15 產(chǎn)品項目經(jīng)理 產(chǎn)品項目經(jīng)理 SQA要定期對要定期對SCM的活動和其文檔進行評審的活動和其文檔進行評審 檢查 輸出評審檢查 輸出評審 檢查結(jié)檢查結(jié) 果 制定并實施改進措施果 制定并實施改進措施 7 16 相關(guān) 相關(guān)SCM評審要制定相應的評審要制定相應的Checklist進行指導 評審要有記錄 進行指導 評審要有記錄 軟件開發(fā)行為規(guī)范8 軟件質(zhì)量保證 僅供內(nèi)部使用24 8 軟件質(zhì)量保證軟件質(zhì)量保證 8 1 產(chǎn)品項目組要有相關(guān)的 產(chǎn)品項目組要有相關(guān)的SQA人員和組織 并開展人員和組織 并開展SQA活動 活動 8 2 產(chǎn)品項目產(chǎn)品項目SQA的組織活動必須通過如下檢查 的組織活動必須通過如下檢查 序號 問題 1產(chǎn)品項目是否建立一個獨立的 能夠支持那些要求獨立性活動的SQA組織 對所有項目 SQA功能是否到位 2SQA組是否有一個向產(chǎn)品組之上的管理者 管理部門報告的渠道 3是否為組織進行SQA活動提供足夠的資源和費用 4SQA組的成員是否接受了培訓以完成他們的SQA活動 5項目的軟件相關(guān)成員是否接受了有關(guān)SQA組任務 職責 權(quán)利等的相關(guān)培 訓 6上級管理部門是否對產(chǎn)品項目的SQA活動及其結(jié)果進行了定期評審 7產(chǎn)品項目經(jīng)理是否定期和事件驅(qū)動地參與評審SQA活動 8SQA組活動及其工作產(chǎn)品是否接受了SQA組之外的專家進行的定期評審 9 項目組是否制定一個執(zhí)行SQA活動的計劃SQAP 如制定了SQA計劃 計 劃的制訂是否按照已文檔化的組織的SQA規(guī)程和SQA計劃模版執(zhí)行 8 3 產(chǎn)品項目必須有產(chǎn)品項目必須有SQA計劃 計劃 SQA計劃必須通過如下檢查 計劃必須通過如下檢查 序號 問題 1 制定SQA計劃的活動是否按照公司的相關(guān)規(guī)范進行 如果存在偏差 是否 形成了偏差文檔 并得到研究技術(shù)管理處的批準 2 SQA計劃是否符合公司規(guī)范中SQA計劃模板的要求 如果存在偏差 是否形 成了偏差文檔 并得到研究技術(shù)管理處的批準 3 SQA活動是否按照SQA計劃進行 4 SQA計劃是否經(jīng)過計劃中涉及的相關(guān)組和個人的評審 并得到SQA經(jīng)理 產(chǎn) 品項目經(jīng)理的批準 5 SQA計劃和軟件項目計劃是否在項目的里程碑處進行了修改 修改是否得到 批準 SQA計劃和軟件項目開發(fā)計劃是否同步變更 8 4 SQA必須對產(chǎn)品軟件開發(fā)過程進行過程審計 必須對產(chǎn)品軟件開發(fā)過程進行過程審計 說明 參考建議8 1 8 1 要對以下的過程進行審計 需求分析過程 軟件概要設計過程 軟件詳細設計過程 軟 要對以下的過程進行審計 需求分析過程 軟件概要設計過程 軟件詳細設計過程 軟 件測試過程 版本發(fā)布過程 配置管理過程 變更控制過程 需求管理過程 件測試過程 版本發(fā)布過程 配置管理過程 變更控制過程 需求管理過程 8 5 SQA的過程審計必須通過如下的檢查 的過程審計必須通過如下的檢查 序號 問題 1產(chǎn)品項目是否明確定義了各種軟件活動過程 定義的活動過程是否經(jīng)過SQA 和相關(guān)管理部門的批準 軟件開發(fā)行