1、1,項目模擬/實戰(zhàn)訓練第一部分 軟件工程,2,本講內(nèi)容,1軟件工程概述 2軟件工程過程和活動 3軟件過程模型 4 軟件過程成熟度模型CMM,3,1 軟件工程概述,1.1 軟件的概念 1.2 為什么要軟件工程 1.3 什么是軟件工程 1.4 參考書目,4,1.1 軟件的概念,定義 Program + Data Structure + Documents 軟件的性質(zhì) 復雜性 難以描述性 不可見性 變化性,易于副本的大批量生產(chǎn) 強合作性,5,1.2 為什么要軟件工程,軟件危機 爆發(fā)時間 1967年NATO的研究組首次提出 1968年NATO軟件工程會議首次提出軟件工程概念 1968-2013, 近4

2、0多年 “危機”一詞 軟件危機依然存在,Crisis！,6,1.2 為什么要軟件工程,軟件危機面對的問題 藝術(shù) vs. 標準化 錯誤的發(fā)現(xiàn) 軟件需求獲取 軟件支持和維護 開發(fā)速度 vs. 市場需求 開發(fā)周期過長、開發(fā)成本過高 研發(fā)風險 軟件開發(fā)中的復雜的協(xié)作(人員,問題,過程) 不同角色的軟件神話(管理者,用戶,開發(fā)者,大眾),7,1.2 為什么要軟件工程,采用什么方法緩解危機 硬件 ? 建筑學? 拍電影? 軟件工程！,8,1.3 什么是軟件工程,Fritz Bauer: “建立和應(yīng)用完善的工程原理以便經(jīng)濟地得到在真實機器上可靠和有效運行的軟件。 特點：重原理、輕技術(shù)、無度量 IEEE： (1

3、)應(yīng)用系統(tǒng)的有規(guī)則的定量的方法開發(fā)、使用和維護軟件；即應(yīng)用工程于軟件。 (2)研究(1)中的方法 特點：粗糙,9,1.3 什么是軟件工程,Definition 軟件工程是以質(zhì)量為核心，為了經(jīng)濟地開發(fā)滿足客戶需求的軟件而研究、建立和應(yīng)用的系統(tǒng)化的、有規(guī)則的、可度量的和可控制的工程原則、方法，涉及到軟件過程、項目管理、開發(fā)方法、軟件復用、軟件度量、開發(fā)工具，甚至企業(yè)文化等各個方面。,10,1.3 什么是軟件工程,11,1.4 軟件工程參考書目,12,2 過程和活動,2.1 軟件過程的概念 2.2 問題定義活動 2.3 可行性研究活動 2.4 需求分析活動 2.5 設(shè)計活動 2.6 實施活動 2.7

4、 測試活動 2.8 部署活動,13,2.1 軟件過程的概念,軟件過程的定義 軟件過程由開發(fā)或維護軟件及其相關(guān)產(chǎn)品的一系列活動構(gòu)成，這些活動從不同的方面定義了軟件開發(fā)中的步驟、交付物、涉眾及其職責等流程要素,14,2.1 軟件過程的概念,Process,控制/約束,輸入,資源,輸出,15,2.1 軟件過程的概念,What,How,Change,16,2.1 軟件過程的概念,17,2.1 軟件過程的概念,Basic Activities(基礎(chǔ)活動) 問題定義，需求，設(shè)計，實b現(xiàn)，軟件驗證，集成，軟件演進/維護，退役 Umbrella Activities (輔助性活動) 軟件項目跟蹤和控制，正式的

5、技術(shù)復審，軟件質(zhì)量保證，軟件配置管理，文檔編制，復用管理，度量，風險管理，,Something that covers or protects. 保護物覆蓋或保護的事物,18,2.2 問題定義活動,What 問題定義是軟件開發(fā)過程當中的一個定義要解決的問題并確定系統(tǒng)范圍的活動。 Why 形成一個早期判斷，達成一個最初共識 When 項目日程表的最前端 占整個軟件開發(fā)時間中的比例很小,19,2.2 問題定義活動,Who 系統(tǒng)分析師、出資方領(lǐng)導、出資方技術(shù)人員、開發(fā)方領(lǐng)導和項目經(jīng)理 Where 客戶現(xiàn)場,20,2.2 問題定義活動,How,21,2.3 可行性研究活動,What 可行性研究是以相對

6、短的時間和相對低的成本來確定給定的問題在其約束條件內(nèi)是否有解、有幾種解以及哪個是最佳解。 Why 必須要先確立滿足約束條件的方案是否存在、是否可行、是否最優(yōu)，然后再在最優(yōu)方案的基礎(chǔ)上進行開發(fā),22,2.3 可行性研究活動,When 項目的早期階段 占整個軟件開發(fā)時間中的比例較小，但比問題定義活動所消耗的時間長 Who 系統(tǒng)分析師、出資方領(lǐng)導、出資方技術(shù)人員、用戶代表、開發(fā)方領(lǐng)導、項目經(jīng)理、架構(gòu)設(shè)計師、領(lǐng)域?qū)＜?、財?wù)人員、市場人員、軟件質(zhì)量保證（SQA，Software Quality Assure）人員等 Where 客戶現(xiàn)場。,23,2.3 可行性研究活動,How,How,24,2.4 需求

7、分析活動,What 需求：主要是在產(chǎn)品構(gòu)建之前確定的系統(tǒng)必須符合的條件或具備的功能，它們是關(guān)于系統(tǒng)將要完成什么工作的一段描述語句，它們必須經(jīng)過所有相關(guān)人員的認可，其目的是徹底地解決客戶的問題。 需求文檔 一組需求的集合 用戶需求文檔、系統(tǒng)需求文檔和軟件規(guī)約文檔,25,2.4 需求分析活動,功能性需求和非功能性需求 功能性需求：描述了系統(tǒng)應(yīng)該做什么，即具備的功能或服務(wù)。（輸入、輸出和計算等） 非功能性需求：描述了系統(tǒng)必須遵守的約束條件。（響應(yīng)時間、吞吐量 、可靠性、可移植性、可擴展性、易用性、安全性、資源要求、可復用性、技術(shù)要求、文化和政策需求、法律需求、道德要求、隱私要求，等等） 描述需求的標

8、準 是完整的、正確的、必要的、無歧義的、可行的、可驗證的以及被設(shè)置了優(yōu)先級別的。,What,26,2.4 需求分析活動,Why 需求不一致、模糊、矛盾 需求變更 客戶忽略領(lǐng)域常識/知識/術(shù)語 客戶集中于現(xiàn)有系統(tǒng)的不足之處，而忽略了系統(tǒng)要實現(xiàn)的關(guān)鍵功能 零碎、無組織、不明確、表達不清 不分輕重緩急,27,2.4 需求分析活動,When 項目的早期階段？,貫穿于整個軟件開發(fā)過程的需求活動,28,2.4 需求分析活動,Who 系統(tǒng)分析師、需求闡釋者、客戶代表、用戶代表、開發(fā)方領(lǐng)導、項目經(jīng)理、架構(gòu)設(shè)計師、領(lǐng)域?qū)＜?、財?wù)人員、市場人員、軟件質(zhì)量保證（SQA，Software Quality Assure

9、）人員、程序員、測試人員、部署人員、技術(shù)文檔編寫人員、培訓人員等。 Where 調(diào)研時，在客戶現(xiàn)場 編寫軟件需求規(guī)約文檔時，可以在開發(fā)單位 復審相關(guān)的需求文檔時，根據(jù)需要來安排,29,2.4 需求分析活動,How,30,2.5 設(shè)計活動,What 設(shè)計： 是在系統(tǒng)的約束條件下（如預算、時間、人力資源、用戶軟、硬件環(huán)境和用戶對系統(tǒng)的操作能力等），為了實現(xiàn)系統(tǒng)的功能性需求和非功能性需求，而找到并描述的一種遵循高質(zhì)量的通用原則的方法，其交付文檔能夠指導開發(fā)人員實現(xiàn)系統(tǒng)。,31,2.5 設(shè)計活動,總體設(shè)計 根據(jù)軟件需求規(guī)約文檔，確定一個合理的軟件體系結(jié)構(gòu)。這個體系結(jié)構(gòu)包括合理地劃分組成系統(tǒng)的模塊、模塊

10、間的調(diào)用關(guān)系以及模塊間的接口關(guān)系。軟件體系結(jié)構(gòu)還從總體方面決定了系統(tǒng)的可擴充性、可維護性，以及系統(tǒng)的性能等。總體設(shè)計的設(shè)計粒度較大，有時也被稱為概要設(shè)計、架構(gòu)設(shè)計。,32,2.5 設(shè)計活動,詳細設(shè)計 詳細設(shè)計地任務(wù)是在總體設(shè)計的基礎(chǔ)上進一步確定如何實現(xiàn)目標系統(tǒng)，包括系統(tǒng)的數(shù)據(jù)對象的設(shè)計、人機接口的設(shè)計以及模塊邏輯的詳細設(shè)計。 設(shè)計部件的粒度 系統(tǒng)、子系統(tǒng)、框架、構(gòu)件、組件、模塊、類、方法等,33,2.5 設(shè)計活動,Why 軟件架構(gòu)是軟件系統(tǒng)的核心 應(yīng)對復雜多變的情況，同時保持完整性 應(yīng)對系統(tǒng)在擴展功能當中出現(xiàn)的問題 大規(guī)模復用的有效基礎(chǔ) 項目管理的基礎(chǔ),34,2.5 設(shè)計活動,When 項目的

11、中、早期階段？,工作量,早期 中期 后期,項目時間,大 小,貫穿于整個軟件開發(fā)過程的設(shè)計活動,35,2.5 設(shè)計活動,Who 主要包括架構(gòu)設(shè)計師、軟件設(shè)計員、復用工程師、設(shè)計復審員、項目經(jīng)理、財務(wù)人員、軟件質(zhì)量保證（SQA，Software Quality Assure）人員和需求變更者等 Where 建議在軟件企業(yè)內(nèi)部進行設(shè)計,36,2.5 設(shè)計活動,How,37,2.6 實施活動,What 編碼：是將軟件設(shè)計結(jié)果轉(zhuǎn)換成用某種程序設(shè)計語言書寫的程序。 單元測試：是把一個模塊作為獨立的程序單元進行測試，以保證它能夠正確執(zhí)行規(guī)定的功能。 集成：是指將單獨的軟件構(gòu)件合并成一個整體的軟件系統(tǒng)。集成分

12、為集成子系統(tǒng)和集成系統(tǒng)兩個級別：,38,2.6 實施活動,Why 以實施為中心的軟件開發(fā) 弱化的需求 弱化的設(shè)計 對實施人員的過度依賴,39,2.6 實施活動,Why 將單元測試作為實施的一部分 When 項目的中、后期階段,工作量,早期 中期 后期,項目時間,大 小,貫穿于整個軟件開發(fā)過程的實施活動,40,2.6 實施活動,Who 包括實施員、代碼復審員、集成員、測試工程師、測試員、項目經(jīng)理、架構(gòu)設(shè)計師、軟件設(shè)計員、復用工程師、SQA人員和財務(wù)人員等 Where 建議在軟件企業(yè)內(nèi)部進行開發(fā),41,2.6 實施活動,How,42,2.7 測試活動,What 測試：是選擇適當?shù)臏y試用例執(zhí)行被測程

13、序的過程，其目的在于發(fā)現(xiàn)程序錯誤。 缺陷：是系統(tǒng)任一方面（包括需求、設(shè)計或代碼）的缺點。該缺點會促成或潛在的促成一個或多個失敗發(fā)生。 錯誤：是指程序中的缺陷所產(chǎn)生的不正確結(jié)果。 失?。寒斠粋€程序不能運行或者其表現(xiàn)不可被接受時稱為失敗。失敗是系統(tǒng)執(zhí)行中出現(xiàn)的情況。失敗源于代碼缺陷。 單元測試、集成測試、系統(tǒng)測試、(alpha)、(Beta) 驗收測試,43,2.7 測試活動,質(zhì)量維度：描述質(zhì)量的概念或評測質(zhì)量的方法的不同視角 可靠性維度 可用性維度 性能維度 測試用例：為特定目標開發(fā)的測試輸入、執(zhí)行條件和預期結(jié)果的集合。,44,2.7 測試活動,When 項目的后期階段？ 優(yōu)點 縮短測試時間 易

14、于定位缺陷 避免錯上加錯,工作量,早期 中期 后期,項目時間,大 小,45,2.7 測試活動,Who 主要包括測試工程師、測試員、軟件設(shè)計員、實施員、項目經(jīng)理、部署工程師、部署員、SQA人員和財務(wù)人員等 Where 建議單元測試、集成測試和系統(tǒng)測試在實施員所在的開發(fā)現(xiàn)場及其附近進行 測試和驗收測試則完全在用戶現(xiàn)場測試,46,2.7 測試活動 (5/5),How,47,2.8 部署活動,What 部署：是為確保最終用戶可以正常使用軟件產(chǎn)品而進行的活動。 根據(jù)產(chǎn)品類型，可以將部署分為三種模式: 自定義安裝模式 現(xiàn)場支持模式 Internet模式,48,2.8 部署活動,部署單元：由一個工作版本（可

15、執(zhí)行構(gòu)件集）、文檔（最終用戶支持材料和發(fā)布說明）和安裝工件組成 部署計劃：說明如何將產(chǎn)品從開發(fā)商轉(zhuǎn)移到用戶群 兼容、轉(zhuǎn)換和遷移策略 部署時間表 部署順序 用戶培訓,49,2.8 部署活動,When 項目的后期階段？,工作量,早期 中期 后期,項目時間,大 小,50,2.8 部署活動,Who 主要包括部署工程師、部署員、文檔編寫員、包裝員、實施員、項目經(jīng)理、SQA人員和財務(wù)人員等 Where 一部分工作可以在開發(fā)現(xiàn)場進行，如制定部署計劃、包裝產(chǎn)品、編寫相關(guān)文檔等； 另一部分工作必須在用戶現(xiàn)場進行，如測試、驗收測試和用戶正式使用中的安裝、培訓工作等。,51,2.8 部署活動,How,52,3 軟件

16、過程模型,3.1 過程模型概念 3.2 線形順序模型系列 3.3 演進模型系列 3.4 其它模型系列 3.5 過程模型的選擇,53,3.1 過程模型概念,為什么需要模型? 模型幫助我們解釋事物如何工作 模型能夠拓寬我們的視野(抽象) 軟件過程模型 一個過程模型是一個過程的抽象表示 過程模型幫助我們更好地理解軟件開發(fā),54,3.1 過程模型概念(2/5),55,3.1 過程模型概念,56,3.1 過程模型概念,57,3.1 過程模型概念,經(jīng)典模型 Linear Sequential Model Waterfall Model V Model Department of Defense Model

17、 RAD Model,Prototyping Model Build-and-Fix Model Incremental Model Spiral Model Concurrent Development Model XP Model RUP Model,58,3.2 線形順序模型系列,線性順序模型,59,3.2 線形順序模型系列,瀑布模型,60,特征 接受上一階段的結(jié)果作為本階段的輸入 開發(fā)階段嚴格按線性方式進行 對本階段的工作進行評審 每一階段具有相關(guān)的里程碑和交付產(chǎn)品 缺點 缺乏靈活性，難以適應(yīng)需求不明確或需求經(jīng)常變化的軟件開發(fā) 開發(fā)早期存在的問題往往要到交付使用時才發(fā)現(xiàn)，維護代價大 適

18、用 在開發(fā)的早期階段軟件需求被完整確定,3.2 線形順序模型系列,61,實際使用的瀑布模型,3.2 線形順序模型系列,62,3.2 線形順序模型系列,V 模型,63,3.2 線形順序模型系列,RAD (Rapid Application Development)模型,60 90 days,64,3.3 演進模型系列,原型模型,Listen to customer,build/revisemock-up,customer test-drives mock-up,65,3.3 演進模型系列,邊建邊改 Model,66,3.3 演進模型系列,邊建邊改 Model(續(xù)),67,3.3 演進模型系列,增

19、量模型,System/Information engineering,analysis,design,Code,Test,增量一,交付1,analysis,design,Code,test,增量二,analysis,design,Code,test,增量三,analysis,design,Code,test,增量四,Calendar Time,交付2,交付3,交付5,68,3.3 演進模型系列,CustomerCommunication,Risk Analysis,Engineering,Construction & Release,Planning,CustomerEvaluation,Pr

20、oject entryPoint axis,螺旋模型,69,3.3 演進模型系列,XP 模型，一種敏捷開發(fā)方法,70,3.4 其它模型系列,構(gòu)件組裝模型 與瀑布模型對比,71,3.4 其它模型系列,72,各種模型的比較,73,3.5 過程模型的選擇,軟件工程過程模型的選擇是基于: 項目的應(yīng)用特點 采用的方法和工具 需要的控制 交付的產(chǎn)品,74,3.5 過程模型總結(jié),在前期需求明確，盡量采用瀑布模型 用戶沒有信息系統(tǒng)使用經(jīng)驗，需求分析人員技能不足，采用原型 不確定因素很多，無法一下子計劃，采用增量或螺旋 需求不穩(wěn)定，采用增量 資金和成本無法一次到位，采用增量 可以各種模型合并使用，但每一次必須要

21、有明確的交付物和出口準則 編程人員經(jīng)驗較少，不宜采用快速的方法,75,4 軟件過程能力成熟度,76,4 能力成熟度模型CMM,CMM（Capability Maturity Model）即能力成熟度模型，是美國卡耐基梅隆大學軟件工程研究所（SEI）建立的，用于評價軟件機構(gòu)的軟件過程能力成熟度的模型。 此模型建立之初的主要目的在于提供一種評價軟件承接方能力的方法，為大型軟件項目的招投標活動提供一種全面而客觀的評審依據(jù)。而發(fā)展到后來，又同時被軟件組織用于改進其軟件過程。,77,軟件組織的成熟與不成熟,不成熟的軟件組織 軟件過程一般并不預先計劃，而是在項目進行中由實際工作人員及管理員臨時計劃 有時，

22、即使軟件過程已計劃好，仍不按計劃執(zhí)行 沒有一個客觀的基準來判斷產(chǎn)品質(zhì)量，或解決產(chǎn)品和過程中的問題 對軟件過程步驟如何影響軟件質(zhì)量，一無所知，產(chǎn)品質(zhì)量得不到保證。而且，一些提高質(zhì)量的環(huán)節(jié)，如檢查、測試等經(jīng)常由于要趕進度而減少或取消,4 能力成熟度模型CMM,78,產(chǎn)品在交付前，對客戶來說，一切都是不可見的 沒有長遠目標，管理員通常只關(guān)注解決任何當前的危機 由于沒有實事求是地估計進度、預算，因此他們經(jīng)常超支、超時。當最后期限臨近，他們往往在功能性和質(zhì)量上妥協(xié)，或以加班加點方式趕進度,4 能力成熟度模型CMM,79,2.成熟的軟件組織 具有全面而充分的組織和管理軟件開發(fā)和維護過程的能力 管理員監(jiān)視軟

23、件產(chǎn)品的質(zhì)量以及生產(chǎn)這些產(chǎn)品的過程。 制定了一系列客觀基準來判別產(chǎn)品質(zhì)量，并分析產(chǎn)品和過程中的問題。 進度和預算可以按照以前積累的經(jīng)驗來制定，結(jié)果可行。預期的成本、進度、功能與性能和質(zhì)量都能實現(xiàn)，并達到目的。,4 能力成熟度模型CMM,80,能準確及時地向工作人員通報實際軟件過程，并按照計劃有規(guī)則地(前后一致，不互相矛盾)工作 凡規(guī)定的過程都編成文檔 軟件過程和實際工作方法相吻合。必要時，過程定義會及時更新，通過測試，或者通過成本-效益分析來改進過程。 全體人員普遍地、積極地參與改進軟件過程的活動。在組織內(nèi)部的各項目中，每人在軟件過程中的職責都十分清晰而明確，各守其責，協(xié)同工作，有條不紊，甚至

24、能預見和防范問題的發(fā)生。,4 能力成熟度模型CMM,81,CMM的組成,4 能力成熟度模型CMM,82,4 能力成熟度模型CMM,83,CMM提供了一個成熟度等級框架：1級-初始級、2級-可重復級、3級-已定義級、4級-已管理級和5級-優(yōu)化級。 1.初始（initial）級： 軟件過程的特點是無秩序的，甚至是混亂的。幾乎沒有什么過程是經(jīng)過妥善定義的，成功往往依賴于個人或小組的努力。 2.可重復（repeatable）級： 建立了基本的項目管理過程來跟蹤成本、進度和功能特性。制定了必要的過程紀律，能重復早先類似應(yīng)用項目取得的成功。,4 能力成熟度模型CMM,84,3.已定義（defined）級：

25、 己將管理和工程活動兩方面的軟件過程文檔化、標準化，并綜合成該機構(gòu)的標準軟件過程。所有項目均使用經(jīng)批準、剪裁的標準軟件過程來開發(fā)和維護軟件。 4.已管理（managed）級： 收集對軟件過程和產(chǎn)品質(zhì)量的詳細度量值，對軟件過程和產(chǎn)品都有定量的理解和控制。 5.優(yōu)化（optimizing）級： 整個組織關(guān)注軟件過程改進的持續(xù)性、預見及增強自身，防止缺陷及問題的發(fā)生。過程的量化反饋和先進的新思想、新技術(shù)促使過程不斷改進。,4 能力成熟度模型CMM,85,成熟度等級表明了一個軟件組織的過程能力的水平。除初始級外，每個成熟度等級都包含若干個關(guān)鍵過程域（Key Process Area，簡稱KPA） 達到

26、某個成熟度級別，該級別（以及較低級別）的所有關(guān)鍵過程域都必須得到滿足，并且過程必須實現(xiàn)制度化。,4 能力成熟度模型CMM,86,能力成熟度級別中的關(guān)鍵過程域18個,優(yōu)化級,已管理級,已定義級,可重復級,初始級,4 能力成熟度模型CMM,6個,7個,2個,3個,87,能力成熟度模型集成CMMICapability Maturity Model Integration,CMM的成功導致了各種模型的衍生，每一種模型都探討了某一特定領(lǐng)域中的過程改進問題 SW-CMM：適用于軟件開發(fā) SE-CMM：系統(tǒng)工程能力成熟度模型 SA-CMM：適用于軟件獲取 SECAM：系統(tǒng)工程能力評估模型 People CMM：討論