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

疾病管理平臺軟件開發(fā)管理規(guī)范

文獻編號：BD-jsgf002生效日期：受控編號：版次：修改狀態(tài)：總頁數(shù)30正文28附錄0編制：李杰審核：王懷鋒同意：付光偉山東諾安諾泰信息系統(tǒng)有限公司

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