軟件工程建設監理軟件工程建設監理1主要內容軟件工程概述軟件質量與質量保證軟件工程項目的實施與監理主要內容軟件工程概述2一、軟件工程概述

一、軟件工程概述

3軟件工程的定義Boehm：運用現代科學技術知識來設計并構造計算機程序及為開發、運行和維護這些程序所必需的相關文件資料IEEE：軟件工程是開發、運行、維護和修復軟件的系統方法FritzBauer：建立并使用完善的工程化原則，以較經濟的手段獲得能在實際機器上有效運行的可靠軟件的一系列方法軟件工程的定義Boehm：運用現代科學技術知識來設計并構造計4軟件工程的定義軟件工程是用工程、科學和數學的原則與方法研制、維護計算機軟件和有關技術及管理方法。三個組成要素：方法、工具和過程。中心思想：是把軟件當作一種工業產品，要求“采用工程化的原理與方法對軟件進行計劃、開發和維護”。 目的：不僅是為了實現按預期的進度和經費完成軟件生產計劃，也是為了提高軟件的生產率與可靠性。軟件工程的定義軟件工程是用工程、科學和數學的原則與方法研制、5軟件工程的目標付出較低的開發成本達到要求的軟件功能取得較好的軟件性能開發的軟件易于移植需要較低的維護費用能按時完成開發工作，及時交付使用軟件工程的目標付出較低的開發成本6軟件工程目標之間的相互關系圖低開發成本易于維護按時交付高可靠性高性能互斥關系互補關系軟件工程目標之間的相互關系圖低開發成本易于維護按時交付高可靠7軟件工程的原則抽象(abstraction)信息的隱藏(informationhiding)模塊化(modularity)局部化(localization)一致性(consistency)完全性(completeness)可驗證性(verifiability)軟件工程的原則抽象(abstraction)8軟件工程的七條原理用分階段的生命周期計劃嚴格管理應該把軟件生命周期分成若干階段，并相應制定出切實可行的計劃，然后嚴格按照計劃對軟件的開發和維護進行管理。Boehm認為，在整個軟件生命周期中應指定并嚴格執行6類計劃：項目概要計劃、里程碑計劃、項目控制計劃、產品控制計劃、驗證計劃、運行維護計劃。軟件工程的七條原理用分階段的生命周期計劃嚴格管理9軟件工程的七條原理堅持進行階段評審錯誤發現的越晚，改正它要付出的代價就越大軟件的質量保證工作不能等到編碼結束之后再進行，應堅持進行嚴格的階段評審，以便盡早發現錯誤軟件工程的七條原理堅持進行階段評審10軟件工程的七條原理實行嚴格的產品控制用戶需求經常變更采用基準配置管理等科學的產品控制技術順應用戶的功能要求。當需求變動時，其它各個階段的文檔或代碼隨之相應變動，以保證軟件的一致性。采納現代程序設計技術提高軟件開發的效率，又可以減少軟件維護的成本軟件工程的七條原理實行嚴格的產品控制11軟件工程的七條原理結果應能清楚地審查軟件是一種富有邏輯性的知識產品軟件開發小組的工作進展情況可見性差，難于評價和管理為更好地進行管理，應根據軟件開發的總目標及完成期限，盡量明確地規定開發小組的責任和產品標準，從而使所得到的標準能清楚地審查。軟件工程的七條原理結果應能清楚地審查12軟件工程的七條原理開發小組的人員應少而精當開發小組為N人時，可能的通訊信道為N(N-1)/2,可見隨著人數N的增大，通訊開銷將急劇增大。承認不斷改進軟件工程實踐的必要性不斷總結經驗，收集進度和消耗等數據，進行出錯類型和問題報告統計，以評估新的軟件技術的效果，指明須重視的問題。軟件工程的七條原理開發小組的人員應少而精13軟件的生存期開發軟件有一個孕育、誕生、成長、成熟、衰亡的生存過程。這個過程即為計算機軟件的生存期軟件生存期的六個步驟：計劃、需求分析、設計、程序編碼、測試及運行維護軟件生存期劃分的原則：各階段任務盡可能獨立軟件的生存期開發軟件有一個孕育、誕生、成長、成熟、衰亡的生存14軟件的生存期軟件的生存期15制定計劃確定要開發軟件系統的總目標給出功能、性能、可靠性以及接口等方面的要求完成該軟件任務的可行性研究估計可利用的資源(計算機硬件、軟件、人力等)、成本、效益、開發進度制定出完成開發任務的實施計劃，連同可行性研究報告，提交管理部門審查制定計劃確定要開發軟件系統的總目標16需求分析和定義確定對待開發軟件提出的需求進行分析并給出詳細的定義編寫軟件需求說明書或系統功能說明書及初步的系統用戶手冊提交管理機構評審需求分析和定義確定對待開發軟件提出的需求進行分析并給出詳細的17軟件設計概要設計—把各項需求轉換成軟件的體系結構。結構中每一組成部分都是意義明確的模塊，每個模塊都和某些需求相對應詳細設計—對每個模塊要完成的工作進行具體的描述，為源程序編寫打下基礎編寫設計說明書，提交評審軟件設計概要設計—把各項需求轉換成軟件的體系18程序編寫、軟件測試程序編寫

根據軟件設計方案，編寫程序代碼結構。結構中每一組成部分都是意義明確的

軟件測試單元測試，查找各模塊在功能和結構上存在的問題并加以糾正組裝測試，將已測試過的模塊按一定順序組裝起來按規定的各項需求，逐項進行有效性測試，決定已開發的軟件是否合格，能否交付用戶使用程序編寫、軟件測試程序編寫19運行、維護改正性維護運行中發現了軟件中的錯誤需要修正適應性維護為了適應變化了的軟件工作環境，需做適當變更完善性維護為了增強軟件的功能需做變更運行、維護改正性維護運行中發現了軟件中的錯誤需要修正20軟件生存期模型軟件生存期模型是跨越整個生存期的系統開發、運作和維護所實施的全部過程、活動和任務的結構框架瀑布模型演化模型螺旋模型噴泉模型增量模型軟件生存期模型軟件生存期模型是跨越整個生存期的系統開發、運作21瀑布模型瀑布模型22演化模型由于在項目開發的初始階段人們對軟件的需求認識常常不夠清晰，因而使得開發項目難于做到一次開發成功，出現返工再開發在所難免。做兩次第一次只是試驗開發，其目標只是在于探索可行性，弄清軟件需求第二次則在此基礎上獲得較為滿意的軟件產品演化模型由于在項目開發的初始階段人們對軟件的需求認識常常不夠23演化模型需求分析快速設計建立原型評價原型修改原型開發產品丟棄型—原型開發之后，已獲取了更為清晰的需求信息演式型—原型作為軟件最終產品的一部分，可滿足用戶的部分需求，進一步在此基礎上開發，則可增加需求，實現后再交付使用。演化模型需求分析快速設計建立原型評價原型修改原型開發產品丟棄24螺旋模型螺旋模型沿著螺線旋轉，在四個象限上分別表達了四個方面的活動，即：制定計劃──確定軟件目標，選定實施方案，弄清項目開發的限制條件風險分析──分析所選方案，考慮如何識別和消除風險實施工程──實施軟件開發客戶評估──評價開發工作，提出修正建議螺旋模型螺旋模型沿著螺線旋轉，在四個象限上分別表達了四個方面25螺旋模型

螺旋模型26噴泉模型迭代重復演進無間隙各階段間無明顯界限噴泉模型迭代27噴泉模型需求獲取與分析系統測試程序生成構件設計類層次結構噴泉模型需求獲取與分析系統測試程序生成構件設計類層次結構28增量模型適合于知識型的軟件系統的開發不要求一開始就有完整的軟件系統需求，先完成基本子集的開發，然后不斷增加功能，反復進行，直到滿足用戶需求始終在軟件人員和用戶的參與下完成， 特別適用于研究性質的實驗室軟件（用戶需求不明確）增量模型適合于知識型的軟件系統的開發29總結階段階段成果計劃問題定義關于規模和目標的報告書

可行性研究系統的高層邏輯模型：數據流圖成本/效益分析

需求分析系統的邏輯模型：數據流圖（MSC圖）數據字典（類清單、對象間關系）算法描述

設計概要設計系統流程圖、

層次圖

、結構圖(SDL)詳細設計編碼規格說明(SDL)軟件測試綜合測試方案和結果完整性一致的軟件配置

運行維護完整準確的維護記錄

總結階段階段成果計劃問題定義關于規模和目標的報告書系統的高30二、軟件質量與質量保證

二、軟件質量與質量保證

31軟件質量因素可直接度量的因素只能間接度量的因素度量和量度度量(Measurement)度量是對開發過程進行檢測，以提高開發過程的質量和勞動生產率量度(Metrics)量度是度量的結果或度量中一個項的抽象表示，做為評價質量和勞動生產率的基礎軟件質量因素可直接度量的因素32量度模型－Boehm模型Boehm模型量度模型－Boehm模型Boehm模型33量度模型－McCall模型McCall模型量度模型－McCall模型McCall模型34量度模型－ISO模型ISO模型（軟件質量需求評價準則）（軟件質量度量評價準則）（軟件質量設計評價準則）量度模型－ISO模型ISO模型（軟件質量需求評價準則）（軟件35各因素間的影響各因素間的影響36軟件質量保證質量保證策略以檢測為重點以過程管理為重點以新產品開發為重點

軟件質量保證質量保證策略37軟件質量保證活動技術方法和開發過程的選用正式技術評審的實施多層次軟件測試標準的執行文檔及其修改的控制度量和報告制度記錄和記錄保存SQA小組活動

軟件質量保證活動技術方法和開發過程的選用38開發過程的選用瀑布模型演化模型螺旋模型噴泉模型增量模型開發過程的選用瀑布模型39開發方法、語言的選用開發方法結構化開發方法面向對象（OO）的開發方法形式化開發方法語言規格說明語言設計語言原型開發語言編程語言開發方法、語言的選用開發方法40正式技術評審的實施軟件評審是一個“過濾器”正式技術評審(FTR，FormalTechnicalReviews)有時稱為“走查(walkthrough)”正式技術評審的實施軟件評審是一個“過濾器”41正式技術評審FTR的目標發現軟件在功能、邏輯和實現上的錯誤驗證評審的軟件符合需求保證軟件按照已確定的標準表述使軟件以統一方式開發使項目更易于管理FTR可以作為一個訓練基地，使初級工程人員觀察到軟件分析、設計和實現不同的處理方法。也能促進人們變得更加熟悉正式技術評審FTR的目標42正式技術評審(續)(一)評審會議3~5人參加會前準備，每個人工作量不超過2小時會議時間2小時評審結束時，必須作出決定接受該產品，不再作進一步修改該產品錯誤嚴重，拒絕接受(改正后也必須進行另一次評審)暫時接受該產品(小錯誤已經發現，必須改正，但沒有必要進行另外的評審)正式技術評審(續)(一)評審會議43正式技術評審(續)(二)評審報告和記錄保存報告評審了什么產品？誰評審的？發現了什么？結論是什么？記錄確定該產品中問題的大小成為生產者修改錯誤時的行動項的校對表還要建立一個跟蹤過程，以保證問題列表中的項都被正確的改正了正式技術評審(續)(二)評審報告和記錄保存44正式技術評審(續)(三)評審指南評審產品，不評審生產者建立一個議事日程，并遵循它限制爭論和辯駁說明問題大小，不要企圖解決所有提出的問題作記錄限制參與人數和堅持充分準備為可能評審的產品開發一張檢查表為FTR安排資源和時間表對所有的評審人員進行有意義的培訓評審你早期的評審正式技術評審(續)(三)評審指南45標準的執行產品質量是企業的生命，標準是產品的基礎，沒有標準，就無產品質量可言軟件工程國際標準體系ISO/IEC的軟件工程標準體系結構框架ISO/IEC12207和ISO/IECTR15504ISO9000-3(1993)/GB/T19000.3(1994)CMM-57-標準的執行產品質量是企業的生命，標準是產品的基礎，沒有標準，46標準的類別Standard(標準)Specification(規范)Criterion(準則)Guidance(指南)Convention(約定)標準的類別Standard(標準)47標準的范圍國際：ISO(國際標準化組織)區域：NATO(北大西洋組織)CJK(中、日、韓)國家：GB(中國)ANSI(美國國家標準協會)FIPS(美國商務部國家標準局聯邦信息處理標準)BS(英國國家標準)DIN(德國國家標準)JIS(日本工業標準)

卜標準的范圍國際：ISO(國際標準化組織)卜48標準的范圍行業：IEEE(美國電氣和電子工程師協會)ACM(美國計算機協會)DOD(美國國防部)MIL-standard(美國軍用標準)HB(中國航空標準)GJB(中國軍用標準)廠標：IBM(國際商業機器公司)

小標準的范圍行業：IEEE(美國電氣和電子工程師協會)小49中國與SE有關的國家標準基礎：GB/T11457-89(SE術語)開發：GB8566-88(計算機軟件開發規范)文檔：GB8567-88(計算機軟件產品開發文件編制指南)GB9385-88(計算機軟件需求說明文件編制規范)GB9386-88(計算機軟件測試文件編制規范)質量：GB/T12504-90(計算機軟件質量保證計劃規范)管理：GB/T12605-90(計算機軟件配置計劃規范)90年以后，國家標準與國際標準從等效原則改為等同原則，均采用雙編碼。如GB/T19000.3(1994)-ISO9000-3(1993)中國與SE有關的國家標準基礎：GB/T11457-89(S50相關標準說明PDAM12207/AMD112207的過程結果CD15388系統生存期過程IS12207軟件生存期過程FDIS14764軟件維護TR15846軟件生存期過程軟件配置管理DTR16326軟件工程項目管理CD15939軟件度量過程FD14598-3軟件產品評價第三部分：開發者過程FD14598-4軟件產品評價第四部分：獲取者過程IS14598-5軟件產品評價第五部分：評價者過程FDIS15910軟件用戶文檔過程TR15271ISO/IEC12207使用指南ISO9000-3在軟件開發、供應和維護中的使用指南TR9294軟件文檔管理指南ISO/IEC15288計劃指南相關標準說明PDAM12207/AMD112207的過程51ISO9000-3-GB/T19000.3

質量管理和質量保證標準-在軟件開發、供應和維護中的使用指南ISO9000系列標準原為硬件制造業制定的標準，不能直接用于軟件業的生產曾試圖用改編的9001用于軟件業的生產由于軟件與硬件的性質截然不同，軟件為人工智能產品，實踐結果說明不行，于是以ISO9000系列標準的追加形式，專門制定了ISO9000-3。ISO9000-3-GB/T19000.352標準的目的和范圍本標準作為ISO9000/GB/T19000系列標準之一，旨在生產滿足需求的軟件而建議采用的控制手段和方法，即為從事軟件開發、供應和維護的組織建立質量管理體系提供指南本標準適用于軟件產品的整個生存期階段和任何生存期模型，也適用于合同提出特殊要求的產品標準的目的和范圍本標準作為ISO9000/GB/T19053標準的主要內容本標準在給出軟件質量管理體系要素時，沒有按照ISO9001/GB/T19991的形式給出，而是按下列三部分給出：質量體系-框架質量體系-生存期話動質量體系-支持活動標準的主要內容本標準在給出軟件質量管理體系要素時，沒有按照I54質量體系－框架這部分主要從管理上描述了構成了質量體系的組織機構、管理職責、質量體系的基本要求及構成質量體系的框架領導的職責、作用和采用的手段質量體系GB/T6583-ISO8402給質量體系定義為：為實施質量管理所具有的組織機構、職責、程序、過程和資源。這一定義給出了質量體系的五個要素，同時明確了質量管理的核心是建立適合企業實際的質量體系。質量體系應以深入細致的質量體系文件為基礎，應用系統的有序的方法將質量體系要素、需求和預防措施清楚地寫入文件質量體系是貫穿產品整個生存期的一個綜合過程，它強調的是在開發過程中的質量保證，以預防為主，而不是在問題發生后依靠糾正措施來解決問題。因此，應按質量體系要求制定并執行質量活動計劃

質量體系－框架這部分主要從管理上描述了構成了質量體系的組織機55質量體系－生存期話動合同評審需方需求規格說明開發策劃質量計劃設計與實現測試與驗證驗收復制、交付和安裝維護質量體系－生存期話動合同評審56質量體系-支持活動配置管理文檔控制質量記錄度量規則和慣例工具和方法采購配套的軟件產品培訓

質量體系-支持活動配置管理57CMMCMM(TheCapabilityMaturityModel)不是國際標準，是CMU/SEI于1986年在Mitre公司的協助下，用于幫助機構改進其軟件過程和聯邦政府要求能提供一種用來評價軟件承制方軟件能力的方法，開始工作經過五年的努力，于1991/1992公開發布了基線版1.0之后，1992/19931.1版、1997/19982.0版，2000推出了CMMI1.0版，它除了沿用CMM分級的形式外，還吸收了ISO/IECTR15504的一些特點CMMCMM(TheCapability58CMM（續）CMM是一個概念模型，它給出了一個軟件機構如何開發和維護高質量軟件產品的思路CMM也是一個描述模型，它描述了一個具有某個級別的軟件機構所具有的主要特征CMM又是一個系統框架，它為一個軟件機構改進其軟件過程能提供一種改進的途徑CMM（續）CMM是一個概念模型，它給出了一個軟件機構如何開59CMM結構CMM結構60CMM結構－成熟度級別CMM的頂層為成熟度級別(五級)1級：初始級(TheInitialLevel)2級：可重復級(TheRepeatableLevel)3級：已定義級(TheDefinedLevel)4級：已管理級(TheManaged)5級：優化級(TheOptimizingLevel)CMM結構－成熟度級別CMM的頂層為成熟度級別(五級)61CMM結構－關鍵過程域關鍵過程域除1級外，每個成熟度級都包含幾個關鍵過程域(KeyProcessAreas)它們確定了要實現一個成熟度級別所必須解決的問題和目標處于級別3的軟件機構一定要解決級別2和級別3中所有關鍵域中的問題；4、5級類推共有十八個關鍵過程域CMM結構－關鍵過程域關鍵過程域62CMM結構－關鍵過程域2級：

需求管理軟件項目計劃軟件項目跟蹤和監督軟件分包合同管理軟件質量保證軟件配置管理3級：

機構過程焦點機構過程定義培訓大綱

綜合軟件管理軟件產品工程組間協調同行評審4級：定量過程管理軟件質量管理5級：缺陷預防技術更新管理過程變更管理CMM結構－關鍵過程域2級：63CMM結構－共同特性每個關鍵過程由五部分組成，稱為共同特性(CommonFeatures)執行約定(如建立機構策略和領導關系等)執行能力(如資源、機構結構和培訓等)執行活動(如制定計劃和規程、執行和跟蹤及必要時采取的糾正措施等)度量和分析(如可采用的度量實例等)驗證實現(如管理部門和質量保證小組實施的評審和審核等)

CMM結構－共同特性每個關鍵過程由五部分組成，稱為共同特性64CMM結構－關鍵實踐在共同特性中的實踐，描述了要建立一個過程能力所必須完成的活動，即每一個關鍵過程都要用關鍵實踐的概念進行描述CMM有316個關鍵實踐(KeyPractices)關鍵實踐只描述“做什么？”不規定“怎么做？”如不指定生存期模型、不規定產品實現所采用的開發方法和工具，從而可以讓各個機構可以選擇自己的方法。但必須合理地說明關鍵實踐，以判斷是否有效地實現了關鍵過程域的目標CMM結構－關鍵實踐在共同特性中的實踐，描述了要建立一個過程65CMM應用軟件過程評價與軟件能力估價軟件過程評價(processassessment)和軟件能力估價(capabilityevaluation)的方法基本相同。但由于評價和估價的動機、目的、輸出和結果歸屬不同，使得在會談或采訪目的、訪問范圍所采集的信息和結果的表示方式，可能存在重要差別。所以，所采用的的詳細規程不同，培訓要求也不同評價是在開放、合作環境中進行的，目的在于暴露問題和幫助管理人員和技術人員改進他們所在機構的過程。所以，評價能否成功取決于他們對機構改進的支持。但更重要的是要通過各種座談會了解機杓構的軟件過程。評價的結果除了能確定機構所面臨的軟件過程問題外，最有價值的是明確機構改進軟件過程的途徑，促進制定進一步的行動計劃，使整個機構關注軟件過程的改進，提高整個機構改進行動計劃的動力和熱情

CMM應用軟件過程評價與軟件能力估價66軟件過程評價與軟件能力估價軟件能力估價是在更為面向審計的環境中進行。估價的目的與金錢有關，因為估價組的推薦意見將影響挑選承制方或投放資金的多少。估價過程的重點在評審巳文檔化的審計記錄上，這些記錄能揭示機構實際執行的軟件過程必須指出的是：評價和估價的結果不是不可比的。因為它們都是基于CMM的，其不同之處也是可以解釋的軟件過程評價與軟件能力估價軟件能力估價是在更為面向審計的環境67CMM應用－評價方法評價方法選擇評價小組填寫成熟度問卷進行響應分析現場訪問、會議和文檔評審提供基于CMM的調查結果清單制作關鍵過程域的剖面圖，以顯示該機構哪些區域巳滿足，哪些區域尚未滿足關鍵過程域的目標等CMM應用－評價方法評價方法68CMM與ISO標準比較CMM與ISO9000-3的設計思路不同，雖然都是著眼于軟件質量管理和軟件過程管理，它們最大的不同是：CMM強調的是持續的過程改進；ISO9000-3涉及的是可接受的質量體系最低標準還要指出的是：CMM中關于能力等級是針對每個軟件機構的；而ISO/IECTR15504中的能力等級是針對每個過程的CMM與ISO標準比較CMM與ISO9000-3的設計思路69文檔及其修改的控制在生產軟件時，修改(Change)是不可避免的，而不修改則是不正常的如果修改中有任何疏忽或處理不當，就非常容易把一個開發得很好的軟件帶入混亂！所以，只有當每個軟件修改可以被說明、分析、跟蹤和控制，而且所有需要知道的人都被通知到時，這樣才能保證軟件修改的質量軟件配置管理(SCM,SoftwareConfigurationManagement)就是用來對軟件文檔及其修改控制的

文檔及其修改的控制在生產軟件時，修改(Change)是不可避70軟件配置管理軟件生存期各個階段的交付項（包括描述程序的文檔、和程序(源代碼或可執行代碼)，以及包含在程序內部或外部的數據）組成整體軟件配置軟件配置管理就是對這些交付項修改的管理，因此，不難看出：一個開發組可以生產出幾百或上千種獨立的交付項，所有這些交付項形成一個相互依賴的層次網在開發和維護的各個步驟中需要不斷地再加工、修改和提高，因此任何交付項都可能有很多不同的版本，而且某一項的任何一種版本都與其它交付項的特定版本有關要防止相關交付項上下左右不一致引起的錯誤，是配置管理要具體解決的問題當然，解決這個問題的機制非常多，以至于需要一個獨立的配置管理計劃作為質量管理計劃的補充，而且應讓全體人員都知道，應該怎樣完成和控制他們它們的工作質量軟件配置管理軟件生存期各個階段的交付項（包括描述程序的文檔、71修改控制無控制的修改必將導致混亂。修改控制過程：修改控制無控制的修改必將導致混亂。修改控制過程：72修改過程修改過程73配置審計如何保證修改控制的正確實現，除了進行正式的技術評審(FTR)以外，還要進行軟件配置審計。通常檢查下列問題：(1)被批準的修改報告中修改巳經完成了嗎？(2)是否巳經進行了正式的技術評審？并表明技術的正確嗎？(3)軟件過程是否遵循了軟件工程標準？(4)修改是否在交付項中被完全實現？配置對象的屬性是否反映了該修改？(5)是否給出了修改者的姓名和修改的日期？(6)是否遵照了標識修改、記錄修改和報告修改的軟件配置管理規程？(7)所有的相關交付項都被更新了嗎？在有些情況下，配置審計作為正式技術評審的一部分。審計一般都由質量保證小組進行配置審計如何保證修改控制的正確實現，除了進行正式的技術評審(74軟件配置狀態報告軟件配置狀態報告是軟件配置管理的一項任務。它必須回答以下問題：(1)發生了什么事？(2)誰做了此事？(3)此事是什么時候發生的？(4)將影響到什么？配置狀態報告可存儲在一個聯機的數據庫中，使得軟件開發者和維護者可以通過關鍵詞分類訪問修改信息，管理者也可獲得與管理相關的信息軟件配置狀態報告軟件配置狀態報告是軟件配置管理的一項任務。它75度量度量的主要目的：(1)更好的理解產品的質量(2)評價過程的效率(3)改進項目層完成工作的質量討論的重點放在產品質量的量度上。(1)傳統(結構化)軟件的量度(2)面向對象軟件的量度度量度量的主要目的：76傳統軟件的量度軟件復雜性軟件可靠性軟件可用性軟件安全性

傳統軟件的量度軟件復雜性77面向對象軟件的量度OO軟件量度的使用和發展要比傳統軟件晚得多，其量度的主要目的與傳統軟件一樣任何產品的量度都取決于產品的特性。OO軟件與使用傳統方法開發的軟件根本不同。Berard定義了OO軟件五個特殊量度的特性：1.局域性(localization)2.封裝性(encapsulation)3.信息隱藏(informationhiding)4.繼承性(inheritance)5.抽象(abstraction)面向對象軟件的量度OO軟件量度的使用和發展要比傳統軟件晚得多78SQA小組的活動軟件質量保證由各種活動中的多個任務完成這些任務由做技術工作的人員和負責質量保證計劃、監督、記錄、分析及報告工作的SQA小組共同完成CMU/SEI推薦了一組有關質量保證中SQA小組的活動SQA小組的活動軟件質量保證由各種活動中的多個任務完成79SQA小組活動（續）為項目準備SQA計劃本計劃與開發項目計劃同時制定，由所有感興趣的相關部門進行評審。本計劃將控制由軟件工程小組和SQA小組執行的質量保證活動；在計劃中要確定以下各點：(1)需要執行的評價(2)需要執行的評審和審計(3)項目可采用的各種標準(4)錯誤報告和跟蹤過程(5)由SQA小組給出的各種文檔(6)為軟件項目組提供反饋信息的數量SQA小組活動（續）為項目準備SQA計劃80SQA小組活動（續）參與開發該頂目的軟件過程描述軟件工程小組要為進行的工作選擇一個過程。SQA小組要按照機構政策、內部軟件標準、外部確定的標準，以及軟件項目計劃其它部分的規定對過程描述進行評審評審軟件工程各項活動，以驗證其與巳定義的軟件過程的符合程度SQA小組要發現、記錄和跟蹤與過程的偏差，并對其是否巳經改正進行驗證審計指定的軟件工作產品，并對其是否符合巳定義的軟件過程相關部分進行驗證SQA小組對選出的工作產品進行評審；發現、記錄和跟蹤出現的偏差；對其是否巳經改正進行驗證；并定期向項目管理者報告工作結果SQA小組活動（續）參與開發該頂目的軟件過程描述81SQA小組活動（續）確保軟件工作和工作產品中的偏差巳被記錄在案，并按照已文檔化的過程進行處理偏差可以發生在項目計劃、過程描述、可采用的標準或技術工作產品中記錄任何不符合的部分，并報告給上級管理部門所有不符合的部分，必須受到跟蹤，直至它們得到解決SQA小組除上述活動外，還需要協調軟件修改的控制和管理，并幫助收集和分析軟件量度活動的信息SQA小組活動（續）確保軟件工作和工作產品中的偏差巳被記錄82三、軟件工程項目的實施與監理三、軟件工程項目的實施與監理83定義階段問題定義可行性研究需求分析定義階段問題定義84問題定義問題定義：要解決的問題是什麼?方法：對系統的實際用戶和使用部門負責人進行調研分析員扼要地寫出對問題的理解在用戶和使用部門負責人的會議上認真討論這份書面報告，澄清含糊不清或者錯誤理解階段成果：關于問題性質、工程目標和規模的書面報告（一份承建雙方都滿意的文檔）時間：不超過一天問題定義問題定義：要解決的問題是什麼?85問題定義的內容問題的范圍需要什么應用上下文假設性能要求外部接口協議 軟件工程標準，如模塊化，可測試性，可擴充性哪些要求是必須的，那些是任選的問題定義的內容問題的范圍86可行性分析的目標識別用戶要求評價系統的可行性進行經濟分析和技術分析把功能分配給硬件、軟件、人、數據庫和其它系統元素建立成本和進度限制生成系統規格說明，形成所有后續工程的基礎可行性分析的目標識別用戶要求87可行性分析的任務識別希望的功能和性能范圍確定系統的功能、性能、約束和接口將功能賦予一個或多個系統元素（即軟件、硬件、人等）提出一些候選方案并做評價對同一功能，可以分配不同的系統元素為選取最有效的分配方案，使用一組權衡準則進行評價可行性分析的任務識別希望的功能和性能范圍88可行性分析的類型經濟可行性（成本---效益分析）成本效益分析：長期利益、短期利益公司經營策略：市場前提技術可行性開發的風險：在給出的限制范圍內，能否設計出系統，并實現必須的功能和性能資源：開發人員的水平，硬件、軟件技術：相關技術的發展能否支持系統操作可行性用戶單位的行政管理，工作制度；使用人員的素質法律可行性合同，侵權，違法，責任，版權可行性分析的類型經濟可行性（成本---效益分析）89可行性分析報告階段性成果——可行性分析報告一般只有投資能取得較大效益的工程項目才繼續開發否則應及時中止工程項目，避免更大的浪費可行性研究的工作量大約占開發總工作量的5%可行性分析報告階段性成果——可行性分析報告90需求分析需求分析的目標

借助于當前系統的邏輯模型導出目標系統的邏輯模型。當前系統目標系統物理模型物理模型邏輯模型邏輯模型模型化具體化抽象化實例化怎么做做什么導出理解需求表達需求參考當前系統建立目標系統模型需求分析需求分析的目標當前系統目標系統物理模型物理模型邏輯模91需求分析的過程需求獲取需求表示需求驗證需求規格說明書總體設計通過不通過可行性分析報告需求分析的過程需求獲取需求表示需求驗證需求規格說明書總體設計92需求分析獲取的內容識別物理環境界面用戶或者人的因素功能文檔數據資源安全性質量保證需求分析獲取的內容識別物理環境93需求分析的表示模型化表示將需求定義用工具（例如數據流圖和數據字典）嚴格地描述出來分析方法結構化方法（自頂向下，逐步求精）面向數據流的結構化分析方法（SA）面向數據結構的Jackson方法(JSD)面向對象方法（OO）面向數據內容的面向對象分析方法(OOA)等需求分析的表示模型化表示94定義階段的監理定義階段監理的目標對軟件功能、性能和其它需求描述的正確性、完整性和清晰性給予評價定義階段監理的依據軟件需求說明書（GB856T——88）國標《計算機軟件開發規范》定義階段承建單位提交的文檔可行性研究報告項目開發計劃數據要求說明書需求規格說明書用戶手冊概要定義階段的監理定義階段監理的目標95定義階段的監理定義階段監理的控制內容系統定義的目標是否與用戶的要求一致系統需求分析階段提供的文檔資料是否齊全文檔中的所有描述是否完整清晰準確反映用戶要求與所有其它系統成分的重要接口是否都已經描述確定所開發項目的數據流與數據結構是否足夠所有圖表是否清楚，在不補充說明時能否理解定義階段的監理定義階段監理的控制內容96定義階段的監理定義階段監理的控制內容主要功能是否已包括在規定的軟件范圍之內，是否都已充分說明設計的約束條件或限制條件是否符合實際開發的技術風險是什么是否考慮過軟件需求的其它方案是否考慮過將來可能會提出的軟件需求是否詳細制定了檢驗標準，它們能否對系統定義是否成功進行確認有沒有遺漏，重復或不一致的地方軟件開發計劃中的估算是否受到了影響定義階段的監理定義階段監理的控制內容97設計階段概要設計將軟件需求轉化為數據結構和軟件的系統結構詳細設計通過對結構表示進行細化，得到軟件詳細的數據結構和算法。設計階段概要設計98設計階段設計階段的流程設計階段設計階段的流程99概要設計概要設計——將軟件需求轉化為數據結構和軟件的系統結構；概要設計只是描繪出軟件的總體框架，根據功能、性能需求和數據需求導出軟件的數據結構和系統結構。概括地說：概要設計進行數據設計和系統結構設計。概要設計概要設計——將軟件需求轉化為數據結構和軟件的系統結構100概要設計的任務概要設計制定規范。包括：閱讀和理解軟件需求說明書，確定軟件設計的目標，及實現的順序根據目標確定最合適的設計方法規定設計文檔的編制標準規定編碼的代碼體系，與硬件、操作系統的接口規約，命名規則等

概要設計的任務概要設計制定規范。包括：101概要設計的任務軟件系統結構的總體設計將復雜的系統功能劃分成模塊的層次結構確定每個模塊的功能、模塊間的調用關系、模塊間的接口等評估模塊劃分的質量及導出模塊結構的規則

處理方式設計確定為實現軟件系統功能需求所必需的算法，并評估算法性能確定為滿足軟件系統的性能需求所必需的算法和模塊間的控制方式確定外部信號的接收發送方式

概要設計的任務軟件系統結構的總體設計102概要設計的任務數據結構設計

確定軟件涉及的文件系統的結構、數據庫的模式及子模式，并進行數據完整性和安全性設計。確定輸入、輸出文件的詳細的數據結構結合算法設計，確定算法所必須的邏輯數據結構及其操作確定對邏輯數據結構所必需的那些操作的程序模塊；若需要與操作系統或調度程序接口所必須的控制表等數據時，確定其詳細的數據結構和使用規則；數據的保護性設計概要設計的任務數據結構設計103概要設計的任務編寫概要設計文檔數據庫設計說明書用戶手冊制定初步的測試計劃概要設計的任務編寫概要設計文檔104詳細設計詳細設計——通過對結構表示進行細化，得到軟件詳細的數據結構和算法詳細設計的任務確定軟件各個組成部分內的算法以及各部分的內部數據組織確定模塊內算法，用某種工具來表達確定模塊內的數據結構確定模塊間的接口細節為每個模塊設計測試選定某種過程的表達形式來描述各種算法；編寫詳細設計文檔詳細設計詳細設計——通過對結構表示進行細化，得到軟件詳細的數105設計階段的監理定義階段監理的依據詳細設計說明書（GB8567——88）概要設計說明書（GB8567——88）數據庫設計說明書（GB8567——88）國標《計算機軟件開發規范》設計階段的監理定義階段監理的依據106設計階段的監理定義階段監理的控制內容：分析軟件各結構成分與軟件需求之間的對應關系分析軟件各結構成分之間的聯系確認軟件設計在現有技術條件下和預算范圍內是否能按時完成確認軟件設計對于需求的解決方案是否實用確認軟件設計是否以一種易于翻譯成程序代碼的形式進行表達的確認軟件設計是否考慮了易維護性評估對該軟件的限制是否現實，是否與需求一致對于文檔、可測試性、設計過程...等等進行評估設計階段的監理定義階段監理的控制內容：107設計階段的監理設計階段監理單位提交的文檔設計階段監理細則設計階段監理周記概要設計監理報告詳細設計說明書的確認報告設計階段的監理設計階段監理單位提交的文檔108實施階段

系統實施目的：是把審核過的系統設計說明書轉化為可以實際運行的系統，交付用戶一個可以實際運行的信息系統。編碼軟件測試實施階段系統實施目的：是把審核過的系統設計說明書轉109軟件實現與測試的流程

準備編程代碼審查單元測試集成測試軟件系統缺陷管理與改錯軟件實現與測試的流程編程代碼審查單元測試集軟件系統缺陷管110編碼監理編碼監理的幾個方面：編程語言的選擇編程風格編碼方法相關文檔的編寫參考指標：可靠性規范性可讀性可維護性編碼監理編碼監理的幾個方面：111編程語言的選擇目標——編程困難低，測試程序量少，易于維護和閱讀。參考因素：系統用戶的要求可以使用的編譯程序可以得到的軟件工具工程規模程序員的知識軟件可移植性要求軟件的應用領域編程語言的選擇目標——編程困難低，測試程序量少，易于維護和閱112編程風格目標——源程序代碼的邏輯簡明清晰參考因素：程序內部文檔名字含義鮮明正確的注解程序清單數據說明數據說明的次序標準化多變量名字在一個語句中說明，按字母順序排列編程風格目標——源程序代碼的邏輯簡明清晰113參考因素：語句構造語句簡單直接避免復雜的條件測試，減少對“非”條件的測試避免大量使用循環嵌套和條件嵌套多使用括號使邏輯表達式和算數表達式清晰直觀輸入輸出校驗所有的輸入輸出檢查輸入項重要組合的合法性保持輸入格式簡單使用數據結束標志明確提交交互式輸入的請求設計良好的輸出表格給所有輸出數據加標志編程風格參考因素：編程風格114參考因素：效率——時間和容量效率是性能要求，在需求分析階段確定效率方面的要求效率是依靠設計來提高的程序的效率和程序的簡單程度是一致的。編程風格參考因素：編程風格115編碼方法模塊和模塊集成

常用的模塊策略：自頂向下自底向上線性監理人員應考慮：開發人員在選擇模塊應用和集成方案時，考慮問題的完善于成熟程度。可以通過面談和檢查文檔編碼方法模塊和模塊集成116編碼程序編碼應保證按照結構化的編程方法進行。程序中的每個模塊都只有一個入口和出口，模塊的長度限制在50~100個語句的范圍，使用自頂向下的流控制。監理人員應考慮：開發人員是否采用了結構化編程方法。可以通過編程者的工作，檢查程序文檔和察看代碼。編碼方法編碼編碼方法117高質量的文檔是減少編碼錯誤和提高可維護性的有利途徑。監理人員應通過采樣，通過樣本判定文檔質量高低。文檔編寫高質量的文檔是減少編碼錯誤和提高可維護性的有利途徑。文檔編118編碼監理要點：程序說明書，是否得到開發負責人認可是否按照系統設計報告進行程序設計編碼時發現與系統設計有矛盾，是否對系統設計進行了再討論檢查編碼是否按程序說明書進行是否對程序測試結果進行登錄與保管重要的程序是否由程序作者以外的人員進行了測試編碼監理的要點編碼監理要點：編碼監理的要點119通過分析和執行程序發現軟件不滿足質量要求的缺陷的過程測試是程序的一個分析和執行過程，其目的在于發現錯誤軟件測試通過分析和執行程序發現軟件不滿足質量要求的缺陷的過程軟件測試120軟件測試意義在一般軟件開發的總成本中，用在測試上的開銷要占30%到50%極端情況下，例如在關系到人的生命安全的軟件中（如飛機控制或核反應監控等軟件），測試費用可能相當軟件生存周期所有其它階段費用總和的3~5倍據美國工業界的統計，對商品化的順序程序來說，測試在時間和費用兩方面的花費都要占整個軟件開發周期總開銷的50%左右可以預料，分布式程序因為要增加死鎖檢測等內容，其測試花費勢必還要大些。如果能將測試效率提高，其經濟效益是顯而易見的軟件測試意義在一般軟件開發的總成本中，用在測試上的開銷要占3121軟件測試的原則軟件開發人員和管理人員首先應該盡早地和不斷地進行各種軟件質量保證活動軟件開發人員應避免檢查自已的程序,軟件質量保證活動應由獨立于軟件開發單位的機構來承擔在設計測試用例時，測試用例應包括輸入數據和與之對應的期望輸出結果兩部分，在輸入數據中，應當包括合理的輸入條件和不合理的輸入條件嚴格執行測試計劃，排除測試的隨意性充分注意測試的群集現象在進行各種分析和修復工作后，要做回歸測試軟件測試的原則軟件開發人員和管理人員首先應該盡早地和不斷地進122軟件測試的基本策略驗證、確認和測試靜態分析與動態測試黑盒測試與白盒測試軟件測試的基本策略驗證、確認和測試123軟件測試步驟單元測試單元測試系統測試確認測試集成測試單元測試被測模塊被測模塊被測模塊已經過測試的模塊已集成的軟件已確認的軟件可交付的軟件概要設計信息系統其它元素軟件需求詳細設計信息軟件測試步驟單元單元系統確認集成單元被測模塊被測模塊被測模塊124測試分類——基本類型單元測試集成測試系統測試文檔測試驗收測試測試分類——基本類型單元測試125單元測試合格的代碼正確、清晰、規范、一致、高效人工靜態檢查，發現30％－70％的邏輯設計和編碼錯誤（review）算法的邏輯正確模塊接口的正確性輸入參數有無正確性檢查調用其他方法接口的正確性出錯處理表達式、SQL語句的正確性單元測試合格的代碼126單元測試人工靜態檢查（review）常量、全局變量使用的正確性程序風格的一致性、規范性代碼是否可以優化注釋是否完整設計測試用例，執行待測程序盡可能覆蓋所有路徑至少檢查每個判斷語句的所有條件，確保所有的變量和參數都經過正常值和異常值的測試單元測試人工靜態檢查（review）127單元測試主要任務模塊接口測試模塊局部數據結構測試模塊邊界條件測試模塊中所有獨立執行路徑測試模塊的各條錯誤處理路徑測試邊界測試監理人員應檢查相關文檔《單元集成測試計劃》《單元測試用例》《單元測試錯誤報告》相關《評審記錄》、《變更記錄》等。單元測試主要任務128集成測試集成測試任務：穿越模塊接口的數據是否會丟失一個模塊的功能是否會對另一個模塊造成不利的影響各個子功能組合起來，是否達到預期要求的父功能全局數據結構是否有問題單個模塊的誤差累積起來是否會放大單個模塊的錯誤是否會導致數據庫錯誤集成測試集成測試任務：129集成測試分類非增量式集成測試把所有模塊按設計要求一次全部組裝起來，然后進行整體測試容易出現混亂。可能發現一大堆錯誤，為每個錯誤定位和糾正非常困難，且在改正一個錯誤的同時又可能引入新的錯誤，新舊錯誤混雜，更難斷定出錯的原因和位置。增量式集成測試程序一段一段地擴展，測試的范圍一步一步地增大錯誤易于定位和糾正，界面的測試亦可做到完全徹底關鍵模塊應盡早測試，并反復進行回歸測試。集成測試分類130集成測試相關文檔《單元集成測試計劃》《集成測試用例》《集成測試錯誤報告》相關《評審記錄》、《變更記錄》等集成測試相關文檔131系統測試系統測試——基于系統整體需求規格說明書，覆蓋系統所有組成部分分類：功能測試（可用性）用于測試應用系統的功能需求功能點的全覆蓋恢復測試主要檢查系統的容錯能力當系統出錯時，能否在指定時間間隔內修正錯誤并重新啟動系統壓力測試檢查程序對異常情況的抵抗能力迫使系統在異常的資源配置下運行系統測試系統測試——基于系統整體需求規格說明書，覆蓋系統所有132系統測試監理人員應檢查相關文檔：《系統測試計劃》《系統測試用例》《系統測試版本提交記錄》《系統測試錯誤報告》《系統測試報告》相關《評審記錄》、《變更記錄》等系統測試監理人員應檢查相關文檔：133文檔測試正式的review，檢查文檔的邏輯錯誤Livetesting，結合時間程序的使用而使用文檔文檔測試正式的review，檢查文檔的邏輯錯誤134驗收測試完成所有開發和測試后進行。基于客戶或最終用戶的需求規格說明書的最終測試，或基于用戶一段時間的使用后，看軟件是否滿足客戶要求。時機初驗終驗一般在用戶現場，真實用戶環境實施，也可在內部應用環境實施一般，驗收測試用例為系統測試用例的子集，可從系統測試用例中根據實際需要選取驗收測試完成所有開發和測試后進行。135測試監理要點測試監理要點:測試數據的選取及系統測試是否按測試計劃進行系統測試是否站在公正、客觀立場上進行的；系統測試是否由用戶參與，是否按照用戶手冊進行系統測試結果是否得到開發、運行、維護及用戶的負責人認可測試監理要點測試監理要點:136系統驗收階段系統驗收的條件系統驗收的組織結構系統驗收的流程系統驗收階段監理工作的內容系統驗收階段監理工作的控制要點系統驗收階段系統驗收的條件137系統驗收的條件承建單位、監理單位已準備好總結報告材料監理工程師已完成工程質量測試、檢驗并編寫完成工程項目質量鑒定書經預驗收各分項工程均達到合格以上的工程；對未完成工或預驗收時提出的修復、補救工程已處理完畢，并經監理工程師以及有關部門檢查合格按國家相關法規法律、技術標準和竣工文件的有關要求已編制完成竣工文件按規定已編制好工程項目竣工決算系統驗收的條件承建單位、監理單位已準備好總結報告材料138系統驗收的組織聯合驗收工組組項目監理小組綜合技術小組監理行政小組測試監理小組承建單位監理工程師業主單位軟件工程驗收階段組織機構圖系統驗收的組織聯合驗收工組組項目監理小組綜合技術小組監理行政139軟件工程項目驗收程序

項目收尾工作準備項目驗收文檔項目自檢提交驗收申請組成聯合驗收工作組項目初步驗收項目正式驗收簽發終驗報告頒發移交證書合格合格合格項目材料驗收合格是是是否否否承建單位監理單位軟件工程項目驗收程序

項目收尾工作準備項目驗收文檔項目自檢提140系統驗收階段監理的工作內容組成聯合驗收工作組項目材料驗收初步驗收正式驗收簽發終驗報告頒發移交證書、辦理固定資產移交

系統驗收階段監理的工作內容組成聯合驗收工作組141系統驗收階段監理的控制要點及時處理承建單位提交的初驗申請，審核初驗的必備條件審核承建單位初驗、終驗和工程整改計劃的可行性審核承建單位提交的驗收計劃及其方案，明確驗收目標、各方責任、驗收內容、驗收標準、驗收方式和驗收結果等內容對初驗中發現的質量問題進行評估，根據質量問題的性質和影響范圍，確定整改要求和整改后的驗收方式

審核承建單位提交的階段性付款申請協調業主單位和承建單位在驗收計劃、驗收目標、驗收范圍、驗收內容、驗收方法和驗收標準等方面達成一致，填報工程備忘錄監理機構應協助業主單位和承建單位完成工程移交工作

系統驗收階段監理的控制要點及時處理承建單位提交的初驗申請，審142結束語

軟件工程的監理機制剛剛起步，但已有的工程實踐證明，監理機制必將顯現出它在市場經濟環境下強大的生命力。通過強化軟件開發的標準化、規范化工程思想，軟件工程監理必將逐步規范化、專業化，形成成熟的市場運作模式。謝謝！結束語軟件工程的監理機制剛剛起步，但已有的工程實踐143軟件工程建設監理軟件工程建設監理144主要內容軟件工程概述軟件質量與質量保證軟件工程項目的實施與監理主要內容軟件工程概述145一、軟件工程概述

一、軟件工程概述

146軟件工程的定義Boehm：運用現代科學技術知識來設計并構造計算機程序及為開發、運行和維護這些程序所必需的相關文件資料IEEE：軟件工程是開發、運行、維護和修復軟件的系統方法FritzBauer：建立并使用完善的工程化原則，以較經濟的手段獲得能在實際機器上有效運行的可靠軟件的一系列方法軟件工程的定義Boehm：運用現代科學技術知識來設計并構造計147軟件工程的定義軟件工程是用工程、科學和數學的原則與方法研制、維護計算機軟件和有關技術及管理方法。三個組成要素：方法、工具和過程。中心思想：是把軟件當作一種工業產品，要求“采用工程化的原理與方法對軟件進行計劃、開發和維護”。 目的：不僅是為了實現按預期的進度和經費完成軟件生產計劃，也是為了提高軟件的生產率與可靠性。軟件工程的定義軟件工程是用工程、科學和數學的原則與方法研制、148軟件工程的目標付出較低的開發成本達到要求的軟件功能取得較好的軟件性能開發的軟件易于移植需要較低的維護費用能按時完成開發工作，及時交付使用軟件工程的目標付出較低的開發成本149軟件工程目標之間的相互關系圖低開發成本易于維護按時交付高可靠性高性能互斥關系互補關系軟件工程目標之間的相互關系圖低開發成本易于維護按時交付高可靠150軟件工程的原則抽象(abstraction)信息的隱藏(informationhiding)模塊化(modularity)局部化(localization)一致性(consistency)完全性(completeness)可驗證性(verifiability)軟件工程的原則抽象(abstraction)151軟件工程的七條原理用分階段的生命周期計劃嚴格管理應該把軟件生命周期分成若干階段，并相應制定出切實可行的計劃，然后嚴格按照計劃對軟件的開發和維護進行管理。Boehm認為，在整個軟件生命周期中應指定并嚴格執行6類計劃：項目概要計劃、里程碑計劃、項目控制計劃、產品控制計劃、驗證計劃、運行維護計劃。軟件工程的七條原理用分階段的生命周期計劃嚴格管理152軟件工程的七條原理堅持進行階段評審錯誤發現的越晚，改正它要付出的代價就越大軟件的質量保證工作不能等到編碼結束之后再進行，應堅持進行嚴格的階段評審，以便盡早發現錯誤軟件工程的七條原理堅持進行階段評審153軟件工程的七條原理實行嚴格的產品控制用戶需求經常變更采用基準配置管理等科學的產品控制技術順應用戶的功能要求。當需求變動時，其它各個階段的文檔或代碼隨之相應變動，以保證軟件的一致性。采納現代程序設計技術提高軟件開發的效率，又可以減少軟件維護的成本軟件工程的七條原理實行嚴格的產品控制154軟件工程的七條原理結果應能清楚地審查軟件是一種富有邏輯性的知識產品軟件開發小組的工作進展情況可見性差，難于評價和管理為更好地進行管理，應根據軟件開發的總目標及完成期限，盡量明確地規定開發小組的責任和產品標準，從而使所得到的標準能清楚地審查。軟件工程的七條原理結果應能清楚地審查155軟件工程的七條原理開發小組的人員應少而精當開發小組為N人時，可能的通訊信道為N(N-1)/2,可見隨著人數N的增大，通訊開銷將急劇增大。承認不斷改進軟件工程實踐的必要性不斷總結經驗，收集進度和消耗等數據，進行出錯類型和問題報告統計，以評估新的軟件技術的效果，指明須重視的問題。軟件工程的七條原理開發小組的人員應少而精156軟件的生存期開發軟件有一個孕育、誕生、成長、成熟、衰亡的生存過程。這個過程即為計算機軟件的生存期軟件生存期的六個步驟：計劃、需求分析、設計、程序編碼、測試及運行維護軟件生存期劃分的原則：各階段任務盡可能獨立軟件的生存期開發軟件有一個孕育、誕生、成長、成熟、衰亡的生存157軟件的生存期軟件的生存期158制定計劃確定要開發軟件系統的總目標給出功能、性能、可靠性以及接口等方面的要求完成該軟件任務的可行性研究估計可利用的資源(計算機硬件、軟件、人力等)、成本、效益、開發進度制定出完成開發任務的實施計劃，連同可行性研究報告，提交管理部門審查制定計劃確定要開發軟件系統的總目標159需求分析和定義確定對待開發軟件提出的需求進行分析并給出詳細的定義編寫軟件需求說明書或系統功能說明書及初步的系統用戶手冊提交管理機構評審需求分析和定義確定對待開發軟件提出的需求進行分析并給出詳細的160軟件設計概要設計—把各項需求轉換成軟件的體系結構。結構中每一組成部分都是意義明確的模塊，每個模塊都和某些需求相對應詳細設計—對每個模塊要完成的工作進行具體的描述，為源程序編寫打下基礎編寫設計說明書，提交評審軟件設計概要設計—把各項需求轉換成軟件的體系161程序編寫、軟件測試程序編寫

根據軟件設計方案，編寫程序代碼結構。結構中每一組成部分都是意義明確的

軟件測試單元測試，查找各模塊在功能和結構上存在的問題并加以糾正組裝測試，將已測試過的模塊按一定順序組裝起來按規定的各項需求，逐項進行有效性測試，決定已開發的軟件是否合格，能否交付用戶使用程序編寫、軟件測試程序編寫162運行、維護改正性維護運行中發現了軟件中的錯誤需要修正適應性維護為了適應變化了的軟件工作環境，需做適當變更完善性維護為了增強軟件的功能需做變更運行、維護改正性維護運行中發現了軟件中的錯誤需要修正163軟件生存期模型軟件生存期模型是跨越整個生存期的系統開發、運作和維護所實施的全部過程、活動和任務的結構框架瀑布模型演化模型螺旋模型噴泉模型增量模型軟件生存期模型軟件生存期模型是跨越整個生存期的系統開發、運作164瀑布模型瀑布模型165演化模型由于在項目開發的初始階段人們對軟件的需求認識常常不夠清晰，因而使得開發項目難于做到一次開發成功，出現返工再開發在所難免。做兩次第一次只是試驗開發，其目標只是在于探索可行性，弄清軟件需求第二次則在此基礎上獲得較為滿意的軟件產品演化模型由于在項目開發的初始階段人們對軟件的需求認識常常不夠166演化模型需求分析快速設計建立原型評價原型修改原型開發產品丟棄型—原型開發之后，已獲取了更為清晰的需求信息演式型—原型作為軟件最終產品的一部分，可滿足用戶的部分需求，進一步在此基礎上開發，則可增加需求，實現后再交付使用。演化模型需求分析快速設計建立原型評價原型修改原型開發產品丟棄167螺旋模型螺旋模型沿著螺線旋轉，在四個象限上分別表達了四個方面的活動，即：制定計劃──確定軟件目標，選定實施方案，弄清項目開發的限制條件風險分析──分析所選方案，考慮如何識別和消除風險實施工程──實施軟件開發客戶評估──評價開發工作，提出修正建議螺旋模型螺旋模型沿著螺線旋轉，在四個象限上分別表達了四個方面168螺旋模型

螺旋模型169噴泉模型迭代重復演進無間隙各階段間無明顯界限噴泉模型迭代170噴泉模型需求獲取與分析系統測試程序生成構件設計類層次結構噴泉模型需求獲取與分析系統測試程序生成構件設計類層次結構171增量模型適合于知識型的軟件系統的開發不要求一開始就有完整的軟件系統需求，先完成基本子集的開發，然后不斷增加功能，反復進行，直到滿足用戶需求始終在軟件人員和用戶的參與下完成， 特別適用于研究性質的實驗室軟件（用戶需求不明確）增量模型適合于知識型的軟件系統的開發172總結階段階段成果計劃問題定義關于規模和目標的報告書

可行性研究系統的高層邏輯模型：數據流圖成本/效益分析

需求分析系統的邏輯模型：數據流圖（MSC圖）數據字典（類清單、對象間關系）算法描述

設計概要設計系統流程圖、

層次圖

、結構圖(SDL)詳細設計編碼規格說明(SDL)軟件測試綜合測試方案和結果完整性一致的軟件配置

運行維護完整準確的維護記錄

總結階段階段成果計劃問題定義關于規模和目標的報告書系統的高173二、軟件質量與質量保證

二、軟件質量與質量保證

174軟件質量因素可直接度量的因素只能間接度量的因素度量和量度度量(Measurement)度量是對開發過程進行檢測，以提高開發過程的質量和勞動生產率量度(Metrics)量度是度量的結果或度量中一個項的抽象表示，做為評價質量和勞動生產率的基礎軟件質量因素可直接度量的因素175量度模型－Boehm模型Boehm模型量度模型－Boehm模型Boehm模型176量度模型－McCall模型McCall模型量度模型－McCall模型McCall模型177量度模型－ISO模型ISO模型（軟件質量需求評價準則）（軟件質量度量評價準則）（軟件質量設計評價準則）量度模型－ISO模型ISO模型（軟件質量需求評價準則）（軟件178各因素間的影響各因素間的影響179軟件質量保證質量保證策略以檢測為重點以過程管理為重點以新產品開發為重點

軟件質量保證質量保證策略180軟件質量保證活動技術方法和開發過程的選用正式技術評審的實施多層次軟件測試標準的執行文檔及其修改的控制度量和報告制度記錄和記錄保存SQA小組活動

軟件質量保證活動技術方法和開發過程的選用181開發過程的選用瀑布模型演化模型螺旋模型噴泉模型增量模型開發過程的選用瀑布模型182開發方法、語言的選用開發方法結構化開發方法面向對象（OO）的開發方法形式化開發方法語言規格說明語言設計語言原型開發語言編程語言開發方法、語言的選用開發方法183正式技術評審的實施軟件評審是一個“過濾器”正式技術評審(FTR，FormalTechnicalReviews)有時稱為“走查(walkthrough)”正式技術評審的實施軟件評審是一個“過濾器”184正式技術評審FTR的目標發現軟件在功能、邏輯和實現上的錯誤驗證評審的軟件符合需求保證軟件按照已確定的標準表述使軟件以統一方式開發使項目更易于管理FTR可以作為一個訓練基地，使初級工程人員觀察到軟件分析、設計和實現不同的處理方法。也能促進人們變得更加熟悉正式技術評審FTR的目標185正式技術評審(續)(一)評審會議3~5人參加會前準備，每個人工作量不超過2小時會議時間2小時評審結束時，必須作出決定接受該產品，不再作進一步修改該產品錯誤嚴重，拒絕接受(改正后也必須進行另一次評審)暫時接受該產品(小錯誤已經發現，必須改正，但沒有必要進行另外的評審)正式技術評審(續)(一)評審會議186正式技術評審(續)(二)評審報告和記錄保存報告評審了什么產品？誰評審的？發現了什么？結論是什么？記錄確定該產品中問題的大小成為生產者修改錯誤時的行動項的校對表還要建立一個跟蹤過程，以保證問題列表中的項都被正確的改正了正式技術評審(續)(二)評審報告和記錄保存187正式技術評審(續)(三)評審指南評審產品，不評審生產者建立一個議事日程，并遵循它限制爭論和辯駁說明問題大小，不要企圖解決所有提出的問題作記錄限制參與人數和堅持充分準備為可能評審的產品開發一張檢查表為FTR安排資源和時間表對所有的評審人員進行有意義的培訓評審你早期的評審正式技術評審(續)(三)評審指南188標準的執行產品質量是企業的生命，標準是產品的基礎，沒有標準，就無產品質量可言軟件工程國際標準體系ISO/IEC的軟件工程標準體系結構框架ISO/IEC12207和ISO/IECTR15504ISO9000-3(1993)/GB/T19000.3(1994)CMM-57-標準的執行產品質量是企業的生命，標準是產品的基礎，沒有標準，189標準的類別Standard(標準)Specification(規范)Criterion(準則)Guidance(指南)Convention(約定)標準的類別Standard(標準)190標準的范圍國際：ISO(國際標準化組織)區域：NATO(北大西洋組織)CJK(中、日、韓)國家：GB(中國)ANSI(美國國家標準協會)FIPS(美國商務部國家標準局聯邦信息處理標準)BS(英國國家標準)DIN(德國國家標準)JIS(日本工業標準)

卜標準的范圍國際：ISO(國際標準化組織)卜191標準的范圍行業：IEEE(美國電氣和電子工程師協會)ACM(美國計算機協會)DOD(美國國防部)MIL-standard(美國軍用標準)HB(中國航空標準)GJB(中國軍用標準)廠標：IBM(國際商業機器公司)

小標準的范圍行業：IEEE(美國電氣和電子工程師協會)小192中國與SE有關的國家標準基礎：GB/T11457-89(SE術語)開發：GB8566-88