軟件項目開發(fā)的課件

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

2、什么要軟件工程軟件危機面對的問題藝術 vs. 標準化錯誤的發(fā)現軟件需求獲取軟件支持和維護開發(fā)速度 vs. 市場需求開發(fā)周期過長、開發(fā)成本過高研發(fā)風險軟件開發(fā)中的復雜的協(xié)作(人員,問題,過程)不同角色的軟件神話(管理者,用戶,開發(fā)者,大眾)71.2 為什么要軟件工程采用什么方法緩解危機硬件 ?建筑學?拍電影?軟件工程！81.3 什么是軟件工程Fritz Bauer:“建立和應用完善的工程原理以便經濟地得到在真實機器上可靠和有效運行的軟件。特點：重原理、輕技術、無度量IEEE：(1)應用系統(tǒng)的有規(guī)則的定量的方法開發(fā)、使用和維護軟件；即應用工程于軟件。(2)研究(1)中的方法特點：粗糙91.3 什么

3、是軟件工程Definition軟件工程是以質量為核心，為了經濟地開發(fā)滿足客戶需求的軟件而研究、建立和應用的系統(tǒng)化的、有規(guī)則的、可度量的和可控制的工程原則、方法，涉及到軟件過程、項目管理、開發(fā)方法、軟件復用、軟件度量、開發(fā)工具，甚至企業(yè)文化等各個方面。 10 A Quality FocusProcessMethodsCASE Tools1.3 什么是軟件工程111.4 軟件工程參考書目122 過程和活動2.1 軟件過程的概念2.2 問題定義活動2.3 可行性研究活動2.4 需求分析活動2.5 設計活動2.6 實施活動2.7 測試活動2.8 部署活動132.1 軟件過程的概念軟件過程的定義軟件過程

4、由開發(fā)或維護軟件及其相關產品的一系列活動構成，這些活動從不同的方面定義了軟件開發(fā)中的步驟、交付物、涉眾及其職責等流程要素 142.1 軟件過程的概念Build theSystem控制 預算,計劃表,標準輸入需求資源人員,工具輸出代碼,文檔Process控制/約束輸入資源輸出152.1 軟件過程的概念WhatHowChange162.1 軟件過程的概念172.1 軟件過程的概念Basic Activities(基礎活動)問題定義，需求，設計，實b現，軟件驗證，集成，軟件演進/維護，退役Umbrella Activities (輔助性活動)軟件項目跟蹤和控制，正式的技術復審，軟件質量保證，軟件配置

5、管理，文檔編制，復用管理，度量，風險管理，Something that covers or protects. 保護物覆蓋或保護的事物182.2 問題定義活動What問題定義是軟件開發(fā)過程當中的一個定義要解決的問題并確定系統(tǒng)范圍的活動。Why形成一個早期判斷，達成一個最初共識 When項目日程表的最前端占整個軟件開發(fā)時間中的比例很小 192.2 問題定義活動Who系統(tǒng)分析師、出資方領導、出資方技術人員、開發(fā)方領導和項目經理 Where客戶現場 202.2 問題定義活動How212.3 可行性研究活動What可行性研究是以相對短的時間和相對低的成本來確定給定的問題在其約束條件內是否有解、有幾種解

6、以及哪個是最佳解。 Why必須要先確立滿足約束條件的方案是否存在、是否可行、是否最優(yōu)，然后再在最優(yōu)方案的基礎上進行開發(fā) 222.3 可行性研究活動When項目的早期階段占整個軟件開發(fā)時間中的比例較小，但比問題定義活動所消耗的時間長Who系統(tǒng)分析師、出資方領導、出資方技術人員、用戶代表、開發(fā)方領導、項目經理、架構設計師、領域專家、財務人員、市場人員、軟件質量保證（SQA，Software Quality Assure）人員等Where客戶現場。232.3 可行性研究活動HowHow242.4 需求分析活動What需求：主要是在產品構建之前確定的系統(tǒng)必須符合的條件或具備的功能，它們是關于系統(tǒng)將要完

7、成什么工作的一段描述語句，它們必須經過所有相關人員的認可，其目的是徹底地解決客戶的問題。 需求文檔一組需求的集合 用戶需求文檔、系統(tǒng)需求文檔和軟件規(guī)約文檔 252.4 需求分析活動功能性需求和非功能性需求 功能性需求：描述了系統(tǒng)應該做什么，即具備的功能或服務。（輸入、輸出和計算等）非功能性需求：描述了系統(tǒng)必須遵守的約束條件。（響應時間、吞吐量 、可靠性、可移植性、可擴展性、易用性、安全性、資源要求、可復用性、技術要求、文化和政策需求、法律需求、道德要求、隱私要求，等等） 描述需求的標準是完整的、正確的、必要的、無歧義的、可行的、可驗證的以及被設置了優(yōu)先級別的。 What262.4 需求分析活動

8、Why需求不一致、模糊、矛盾需求變更客戶忽略領域常識/知識/術語 客戶集中于現有系統(tǒng)的不足之處，而忽略了系統(tǒng)要實現的關鍵功能零碎、無組織、不明確、表達不清不分輕重緩急 272.4 需求分析活動When項目的早期階段？貫穿于整個軟件開發(fā)過程的需求活動282.4 需求分析活動Who系統(tǒng)分析師、需求闡釋者、客戶代表、用戶代表、開發(fā)方領導、項目經理、架構設計師、領域專家、財務人員、市場人員、軟件質量保證（SQA，Software Quality Assure）人員、程序員、測試人員、部署人員、技術文檔編寫人員、培訓人員等。Where調研時，在客戶現場編寫軟件需求規(guī)約文檔時，可以在開發(fā)單位復審相關的需求

9、文檔時，根據需要來安排292.4 需求分析活動How302.5 設計活動 What 設計：是在系統(tǒng)的約束條件下（如預算、時間、人力資源、用戶軟、硬件環(huán)境和用戶對系統(tǒng)的操作能力等），為了實現系統(tǒng)的功能性需求和非功能性需求，而找到并描述的一種遵循高質量的通用原則的方法，其交付文檔能夠指導開發(fā)人員實現系統(tǒng)。312.5 設計活動 總體設計根據軟件需求規(guī)約文檔，確定一個合理的軟件體系結構。這個體系結構包括合理地劃分組成系統(tǒng)的模塊、模塊間的調用關系以及模塊間的接口關系。軟件體系結構還從總體方面決定了系統(tǒng)的可擴充性、可維護性，以及系統(tǒng)的性能等?？傮w設計的設計粒度較大，有時也被稱為概要設計、架構設計。322.

10、5 設計活動詳細設計 詳細設計地任務是在總體設計的基礎上進一步確定如何實現目標系統(tǒng)，包括系統(tǒng)的數據對象的設計、人機接口的設計以及模塊邏輯的詳細設計。設計部件的粒度系統(tǒng)、子系統(tǒng)、框架、構件、組件、模塊、類、方法等332.5 設計活動Why軟件架構是軟件系統(tǒng)的核心應對復雜多變的情況，同時保持完整性應對系統(tǒng)在擴展功能當中出現的問題大規(guī)模復用的有效基礎 項目管理的基礎 342.5 設計活動When項目的中、早期階段？工作量早期 中期 后期項目時間大小貫穿于整個軟件開發(fā)過程的設計活動352.5 設計活動Who主要包括架構設計師、軟件設計員、復用工程師、設計復審員、項目經理、財務人員、軟件質量保證（SQA

11、，Software Quality Assure）人員和需求變更者等Where建議在軟件企業(yè)內部進行設計 362.5 設計活動How372.6 實施活動What編碼：是將軟件設計結果轉換成用某種程序設計語言書寫的程序。單元測試：是把一個模塊作為獨立的程序單元進行測試，以保證它能夠正確執(zhí)行規(guī)定的功能。 集成：是指將單獨的軟件構件合并成一個整體的軟件系統(tǒng)。集成分為集成子系統(tǒng)和集成系統(tǒng)兩個級別：382.6 實施活動Why以實施為中心的軟件開發(fā)弱化的需求 弱化的設計 對實施人員的過度依賴 392.6 實施活動Why將單元測試作為實施的一部分When項目的中、后期階段 工作量早期 中期 后期項目時間大小

12、貫穿于整個軟件開發(fā)過程的實施活動402.6 實施活動Who包括實施員、代碼復審員、集成員、測試工程師、測試員、項目經理、架構設計師、軟件設計員、復用工程師、SQA人員和財務人員等Where建議在軟件企業(yè)內部進行開發(fā) 412.6 實施活動How422.7 測試活動What測試：是選擇適當的測試用例執(zhí)行被測程序的過程，其目的在于發(fā)現程序錯誤。 缺陷：是系統(tǒng)任一方面（包括需求、設計或代碼）的缺點。該缺點會促成或潛在的促成一個或多個失敗發(fā)生。錯誤：是指程序中的缺陷所產生的不正確結果。失?。寒斠粋€程序不能運行或者其表現不可被接受時稱為失敗。失敗是系統(tǒng)執(zhí)行中出現的情況。失敗源于代碼缺陷。單元測試、集成測試

13、、系統(tǒng)測試、(alpha)、(Beta) 驗收測試 432.7 測試活動質量維度：描述質量的概念或評測質量的方法的不同視角 可靠性維度可用性維度性能維度測試用例：為特定目標開發(fā)的測試輸入、執(zhí)行條件和預期結果的集合。 442.7 測試活動When項目的后期階段？優(yōu)點縮短測試時間易于定位缺陷 避免錯上加錯 工作量早期 中期 后期項目時間大小452.7 測試活動Who主要包括測試工程師、測試員、軟件設計員、實施員、項目經理、部署工程師、部署員、SQA人員和財務人員等 Where建議單元測試、集成測試和系統(tǒng)測試在實施員所在的開發(fā)現場及其附近進行測試和驗收測試則完全在用戶現場測試 462.7 測試活動

14、(5/5)How472.8 部署活動What部署：是為確保最終用戶可以正常使用軟件產品而進行的活動。 根據產品類型，可以將部署分為三種模式:自定義安裝模式現場支持模式Internet模式 482.8 部署活動部署單元：由一個工作版本（可執(zhí)行構件集）、文檔（最終用戶支持材料和發(fā)布說明）和安裝工件組成 部署計劃：說明如何將產品從開發(fā)商轉移到用戶群兼容、轉換和遷移策略 部署時間表 部署順序用戶培訓 492.8 部署活動When項目的后期階段？工作量早期 中期 后期項目時間大小502.8 部署活動Who主要包括部署工程師、部署員、文檔編寫員、包裝員、實施員、項目經理、SQA人員和財務人員等Where一

15、部分工作可以在開發(fā)現場進行，如制定部署計劃、包裝產品、編寫相關文檔等；另一部分工作必須在用戶現場進行，如測試、驗收測試和用戶正式使用中的安裝、培訓工作等。512.8 部署活動How523 軟件過程模型3.1 過程模型概念3.2 線形順序模型系列3.3 演進模型系列3.4 其它模型系列3.5 過程模型的選擇533.1 過程模型概念為什么需要模型?模型幫助我們解釋事物如何工作模型能夠拓寬我們的視野(抽象)軟件過程模型一個過程模型是一個過程的抽象表示過程模型幫助我們更好地理解軟件開發(fā)543.1 過程模型概念(2/5)553.1 過程模型概念563.1 過程模型概念573.1 過程模型概念經典模型Li

16、near Sequential ModelWaterfall ModelV ModelDepartment of Defense ModelRAD ModelPrototyping ModelBuild-and-Fix Model Incremental ModelSpiral ModelConcurrent Development ModelXP ModelRUP Model583.2 線形順序模型系列線性順序模型analysisdesigncodetestSystem/informationengineering593.2 線形順序模型系列瀑布模型60特征接受上一階段的結果作為本階段的輸入

17、開發(fā)階段嚴格按線性方式進行對本階段的工作進行評審每一階段具有相關的里程碑和交付產品缺點缺乏靈活性，難以適應需求不明確或需求經常變化的軟件開發(fā)開發(fā)早期存在的問題往往要到交付使用時才發(fā)現，維護代價大適用在開發(fā)的早期階段軟件需求被完整確定3.2 線形順序模型系列61實際使用的瀑布模型3.2 線形順序模型系列623.2 線形順序模型系列V 模型633.2 線形順序模型系列RAD (Rapid Application Development)模型60 90 days643.3 演進模型系列原型模型Listen to customerbuild/revisemock-upcustomer test-dri

18、ves mock-up653.3 演進模型系列邊建邊改 ModelBuild first versionModify until client is satisfiedMaintenancephaseRetirementDevelopmentMaintenance663.3 演進模型系列邊建邊改 Model(續(xù))673.3 演進模型系列增量模型System/InformationengineeringanalysisdesignCodeTest增量一交付1analysisdesignCodetest增量二analysisdesignCodetest增量三analysisdesignCodete

19、st增量四Calendar Time交付2交付3交付5683.3 演進模型系列CustomerCommunicationRisk AnalysisEngineeringConstruction & ReleasePlanningCustomerEvaluationProject entryPoint axis螺旋模型693.3 演進模型系列XP 模型，一種敏捷開發(fā)方法703.4 其它模型系列構件組裝模型與瀑布模型對比713.4 其它模型系列應用構件提取車間構件生產車間標準規(guī)范 與 質量保證1基礎構件，2功能構件 3接口構件，4用戶界面構件 應用構件庫 構件庫組裝車間領域 1領域 2應用系統(tǒng) .

20、123472各種模型的比較模型優(yōu)點缺點瀑布模型規(guī)范，文檔驅動系統(tǒng)可能不滿足客戶真正的需求快速原型克服了瀑布型的缺點增量模型開發(fā)早期回報明確，易于維護要求開放的軟件體系結構螺旋模型風險驅動，適用于大型項目開發(fā)風險分析人員需要有經驗且經過充分訓練733.5 過程模型的選擇軟件工程過程模型的選擇是基于:項目的應用特點采用的方法和工具需要的控制交付的產品743.5 過程模型總結在前期需求明確，盡量采用瀑布模型用戶沒有信息系統(tǒng)使用經驗，需求分析人員技能不足，采用原型不確定因素很多，無法一下子計劃，采用增量或螺旋需求不穩(wěn)定，采用增量資金和成本無法一次到位，采用增量可以各種模型合并使用，但每一次必須要有明確

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

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

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

24、 能力成熟度模型CMM825.優(yōu)化級4.已管理級3.已定義級2.可重復級1.初始級標準、一致的過程有紀律的過程可預測的過程持續(xù)改進的過程軟件過程成熟度的5個等級4 能力成熟度模型CMM83 CMM提供了一個成熟度等級框架：1級-初始級、2級-可重復級、3級-已定義級、4級-已管理級和5級-優(yōu)化級。 1.初始（initial）級： 軟件過程的特點是無秩序的，甚至是混亂的。幾乎沒有什么過程是經過妥善定義的，成功往往依賴于個人或小組的努力。 2.可重復（repeatable）級： 建立了基本的項目管理過程來跟蹤成本、進度和功能特性。制定了必要的過程紀律，能重復早先類似應用項目取得的成功。4 能力成熟

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

26、 Process Area，簡稱KPA）達到某個成熟度級別，該級別（以及較低級別）的所有關鍵過程域都必須得到滿足，并且過程必須實現制度化。4 能力成熟度模型CMM86缺陷預防、技術更新管理、過程更改管理定量過程管理軟件質量管理機構過程焦點、機構過程定義、培訓大綱、綜合軟件管理、軟件產品工程、組間協(xié)調、同行評審需求管理、軟件項目計劃、軟件項目跟蹤和監(jiān)督、軟件分包合同管理、軟件質量保證、軟件配置管理能力成熟度級別中的關鍵過程域18個優(yōu)化級已管理級已定義級可重復級初始級4 能力成熟度模型CMM6個7個2個3個87能力成熟度模型集成CMMICapability Maturity Model Integ

27、rationCMM的成功導致了各種模型的衍生，每一種模型都探討了某一特定領域中的過程改進問題SW-CMM：適用于軟件開發(fā)SE-CMM：系統(tǒng)工程能力成熟度模型SA-CMM：適用于軟件獲取SECAM：系統(tǒng)工程能力評估模型People CMM：討論軟件組織吸引、開發(fā)、激勵、組織和留住人才的能力EIA/IS 731：替代SW-CMM和SECAMIPD-CMM：適用于集成化產品開發(fā)FAA-CMM：集成了SE-CMM、 SA-CMM、 SW-CMM88相應的國際標準： ISO/IEC 12207（軟件生存周期過程） ISO/IEC 15288（系統(tǒng)生存周期過程） ISO/IEC 15504（軟件過程評估）

28、模型的繁衍導致模型框架、術語等方面的矛盾和不一致包含在當代工程中各種各樣的學科和工程是密切交叉在一起的，應用不同模型時效率低下且容易混淆，常常要付出極其昂貴的代價美國國防部、美國國防工業(yè)委員會和SEI/CMU于1998年啟動CMMI項目，希望CMMI是若干過程模型的綜合和改進，是支持多個工程學科和領域的系統(tǒng)的、一致的過程改進框架。4 能力成熟度模型CMM892000年發(fā)布第一個CMMI模型CMMI-SE/SW/IPPD V1.0：集成了SW-CMM、EIA/IS 731、IPD CMM V0.982002年1月發(fā)布CMMI-SE/SW/IPPD V1.1，美國國防工業(yè)委員會在第一屆CMMI國際研討會上宣布， CMMI V1.1將至少穩(wěn)定五年不變CMMI模型提供兩種表示法： 階段式模型和連續(xù)式模型4 能力成熟度模型CMM90階段式模型階段式模型的結構類同于軟件CMM，它關