過程和生命周期的建模

1、chapter 2,第二章過程和生命周期的建模,,chapter 2,軟件過程之父的經(jīng)典諺語,,chapter 2,,chapter 2,過程的一般定義,,chapter 2,Process includes:,all major process activities所有主要過程活動resources used, subject to set of constraints 資源占用、服從于一組約束(such as schedule)

2、intermediate and final products中間和最終產品subprocesses, with hierarchy or links分層或鏈接的子過程entry and exit criteria for each activity每個活動的入口和出口標準sequence of activities, so timing is clear活動的順序，活動期是很清楚的guiding principles, in

3、cluding goals of each activity指導原則，包括每個活動的目標constraints for each activity, resource or product對每一個活動、資源或產品的約束,chapter 2,軟件過程,軟件過程是將用戶的需求轉化成有效的軟件解決方案的一系列活動。過程具有一系列的性質：時間性、并發(fā)性、嵌套性和度量性等。許多軟件組織無法正確定義和控制這一過程，但這恰恰是組織改進的關鍵。,

4、chapter 2,軟件過程（續(xù)）,過程的好壞由結果狀態(tài)與預期狀態(tài)的差異決定，也就是目標成果質量的好壞。規(guī)程（Procedure）是人們對客觀事物運動規(guī)律的理解和掌握，是規(guī)范了的過程。軟件過程是為了獲得高質量軟件產品所需要完成的一系列任務的框架，它規(guī)定了完成各項任務的工作步驟。軟件過程必須科學、合理，才能開發(fā)出高質量 的軟件產品。,chapter 2,軟件過程的活動,框架活動是軟件工程必須的大步驟、是決定產品如何出現(xiàn)、存在的重要

5、活動。它包括一組軟件工程工作任務并指出什么算完(里程碑)? 交付出什么?質量保證點是什么? 軟件工程工作任務因產品特性而選用不同的過程模型展開。最上層的框架活動是定義、開發(fā)、維護。有了模型它就可以把這三大步驟細化了。,chapter 2,保護性（傘形）活動是為保證高質量產品出現(xiàn)、存在的活動。它凌駕于框架活動之上，故謂之“傘形”,典型的傘形活動是：軟件項目追蹤和管理文檔的準備和制作軟件配置管理軟件質量保證正式技術評審可重用

6、管理軟件度量(指本項目特殊的度量)風險管理,chapter 2,,為開發(fā)高質量的軟件需要完成的任務的框架。,chapter 2,軟件過程（續(xù)）,軟件過程又稱軟件生命周期（ Life cycle ），是軟件生命周期內為達到一定目標而必須實施的一系列相關過程的集合。早期：立項、需求分析、設計、編碼、測試、交付、維護、退役,chapter 2,軟件過程（續(xù)）,現(xiàn)在的軟件生命周期過程包括：早期：立項、需求分析、設計

7、、編碼、測試、交付、維護、退役又加入了：管理各種活動、質量保證環(huán)境基礎設施配置、文檔管理等。,chapter 2,,chapter 2,軟件生命周期的階段劃分,(1)可行性研究與計劃(2)需求分析(3)總體設計 上游 (4)詳細設計(5)實現(xiàn)(6)集成測試(7)確認測試 下游(8)使用和維護（根據(jù)國標《計算機軟件開發(fā)規(guī)范》）,,,,,,,,,,,定義時期,開發(fā)時期

8、,維護時期,chapter 2,新的國際標準定義的軟件生存過程（1995 ISO/IEC 12207）,,軟件生存期過程,支持過程,組織過程,主要過程,,,,,,,獲取過程,供應過程,開發(fā)過程,運行過程,維護過程,文檔編制過程,配置管理過程,質量保證過程,驗證過程,確認過程,聯(lián)合評審過程,審核過程,問題解決過程,管理過程,基礎設

9、施過程,改進過程,培訓過程,,,,,,,,,,,,,,,,,,,,chapter 2,注意： 軟件過程標準有很多種。例如：ISO9000、ISO/IEC12207、CMM、CLEANROOM、ISO/IEC15504、NASA-SEL 和BOOTSTRAP等,每種標準都有一定的特點和適用范圍.,chapter 2,軟件過程各階段內容● 可行性研究 任務 了解用戶要求和現(xiàn)實環(huán)境。從技術、經(jīng)濟、市場等方

10、面研究并論證開發(fā)該軟件系統(tǒng)的可行性。 △技術可行性 當前的軟件開發(fā)方法和工具能否支持需求的實現(xiàn)； △操作可行性 用戶能否在特定的環(huán)境下使用這個軟件； △經(jīng)濟可行性 開發(fā)和使用、維護這個軟件的成本能否被用戶所接受。 工作產品 可行性報告,chapter 2,● 需求分析 任務：確定用戶對軟件系統(tǒng)的需求：△功能需求

11、軟件必須要完成的功能；△性能需求 軟件的安全性、可靠性、可維護性、精度、錯誤處理、適應性、用戶培訓等；△運行環(huán)境約束 待開發(fā)的軟件產品必須滿足的環(huán)境要求,chapter 2,● 需求分析 過程△需求分析人員必須與用戶不斷、反復地交流和商討，使用戶需求逐步準確、一致、完全?！鞣椒?結構化分析方法、面向對象的分析方法等△工具 Rational Rose等 工作產品 △

12、軟件需求規(guī)格說明書SRS △用戶需求定義文檔。,chapter 2,● 概要設計 任務 根據(jù)SRS建立目標軟件系統(tǒng)的總體結構、設計全局數(shù)據(jù)庫和數(shù)據(jù)結構，規(guī)定設計約束，制定組裝測試計劃等等。 原則 △ 堅持功能模塊內部高內聚，功能模塊之間松耦合的 △ 堅持與需求規(guī)格說明書的一致性 方法 △ 結構化方法 △ 面向對象方法,chapte

13、r 2,● 概要設計 工作產品 概要設計規(guī)格說明書 數(shù)據(jù)庫或數(shù)據(jù)結構設計說明書 集成測試計劃,chapter 2,● 詳細設計 任務 細化概要設計所生成的各個模塊, 并詳細描述 程序模塊的內部細節(jié)(算法，數(shù)據(jù)結構等)，形 成可編程的程序模塊，制訂單元測試計劃 工作產品 詳細設計規(guī)格說明書, 單元測試計劃,chapte

14、r 2,● 實現(xiàn)任務 根據(jù)詳細設計規(guī)格說明書編寫源程序，并對程序進行調試、單元測試、系統(tǒng)集成，驗證程序與詳細設計文檔的 一致性方法 以詳細設計規(guī)格說明書為依據(jù)、基于某種程序設計語言進行編碼 結構化程序設計 面向對象程序設計工作產品 源程序代碼,chapter 2,● 單元測試任務 對模塊進行測試途徑 黑盒測試

15、 白盒測試工作產品 單元測試報告,chapter 2,● 集成測試任務 組裝測試應滿足概要設計的要求。途徑 測試模塊連接的正確性； 測試系統(tǒng)或子系統(tǒng)的I/O； 測試系統(tǒng)的功能和性能。工作產品 滿足概要設計要求的程序、組裝測試報告,chapter 2,● 確認測試 任務 根據(jù)軟件需求規(guī)格說明書，測試軟件系統(tǒng)是否滿足用戶的需求 方法 用戶參與，以軟件需求規(guī)

16、格說明書為依據(jù)進行確認測試工具 專用測試工具 工作產品 可供用戶使用的軟件產品(文檔，源程序),chapter 2,● 使用和維護 任務 軟件工作環(huán)境不斷變化，軟件也必然跟著變化，軟件必須不斷進化以滿足客戶的需求變化，這是軟件產品最根本的特性。 軟件維護占用軟件開發(fā)60%以上的工作量。 正確性維護 擴充性維護

17、 適應性維護 軟件產品的新版本,chapter 2,過程模型,軟件過程模型是軟件開發(fā)全過程、軟件開發(fā)活動以及它們之間關系的結構框架過程框架（process framework）：定義了若干小的框架活動，為完整的軟件開發(fā)過程建立了基礎。軟件通用過程框架：可適用于絕大多數(shù)的軟件項目的過程框架。,chapter 2,Reasons for modeling a process,To form a co

18、mmon understanding形成共同理解To find inconsistencies, redundancies, omissions發(fā)現(xiàn)矛盾、遺漏和冗余To find and evaluate appropriate activities for reaching process goal為達到過程目標發(fā)現(xiàn)和評估合適的活動To tailor a general process for the particular si

19、tuation in which it will be used根據(jù)每個活動將被使用的特殊情況對其進行裁減,chapter 2,溝通：這個框架活動包含了與客戶（包括所有共利益者Stakeholder）之間大量的交流協(xié)作，還包括需求獲取以及其他相關活動。策劃：為后續(xù)的軟件工程工作制定計劃。它描述了需要執(zhí)行的技術任務、可能的風險、資源需求、工作產品和工作進度計劃建模：包括創(chuàng)建模型和設計兩方面。創(chuàng)建模型有助于客戶和開發(fā)人員更好地理解軟件需

20、求，設計可以實現(xiàn)需求。構建：包括編碼和測試部署：軟件交付給用戶，用戶對其進行評測并給出反饋意見,chapter 2,Examples of process models,Waterfall model瀑布模型Prototyping原型化模型V-model V-模型Operational specification操作說明模型Transformational model變換模型Phased development: inc

21、rements and iteration增量和迭代模型Spiral model螺旋模型,chapter 2,Waterfall model瀑布模型,1970 W.royce 軟件開發(fā)過程與軟件生命周期是一致的 相鄰二階段之間存在因果關系 需對階段性產品進行評審,優(yōu)點： 軟件生命周期模型,使軟件開發(fā)過程可以在分析、設計、編碼、測試和維護的框架下進行 軟件開發(fā)過程具有系統(tǒng)性、可控性，克服了軟件開發(fā)的隨意性,缺點：

22、 項目開始階段用戶很難精確的提出產品需求，由于技術進步，用戶對系統(tǒng)深入的理解，修改需求十分普遍。 項目開發(fā)晚期才能得到程序的運行版本，這時修改軟件需求和開發(fā)中的錯誤代價很大。 采用線性模型組織項目開發(fā)經(jīng)常發(fā)生開發(fā)小組人員“堵塞狀態(tài)”，特別是項目的開始和結束。,chapter 2,Prototyping原型化模型,原型模型支持軟件需求開發(fā)，幫助用戶和開發(fā)人員理解需求，是軟件需求工程的關鍵。它產生的

23、正式需求文擋，是軟件開發(fā)的基礎。如果開發(fā)的原型是可運行的，它的若干高質量的程序片段和開發(fā)工具可用于工作程序的開發(fā)。原型的開發(fā)和評審是系統(tǒng)分析員和用戶/客戶共同參予的迭代過程，每個迭代循環(huán)都是線性過程,chapter 2,chapter 2,V-model V-模型,軟件開發(fā)過程與測試的對應,chapter 2,形式化開發(fā)方法,,形式化開發(fā)方法類似瀑布模型的軟件開發(fā)方法，其開發(fā)過程是用形式化數(shù)學轉換將系統(tǒng)描述轉換成一個可執(zhí)行程序，其形

24、式化系統(tǒng)開發(fā)過程如下：,chapter 2,Operational specification操作說明模型,chapter 2,Transformational model變換模型,chapter 2,軟件需求描述被精練成一個用數(shù)學符號表達的詳細的形式化描述設計、實現(xiàn)和單元測試等開發(fā)過程由轉換過程替代，在轉換的過程中，每個步驟增加細節(jié)，直到形式化描述被轉換變成一個可執(zhí)行程序。,chapter 2,特點及優(yōu)缺點,用嚴格的、數(shù)學的符

25、號體系來規(guī)約、開發(fā)和驗證基于計算機的系統(tǒng)。解決軟件開發(fā)過程使用其它范型難以克服的二義性、不完整性和不一致性?？梢援a生無缺陷軟件的承諾。費時、昂貴、難溝通，需要培訓 是建造重要的、安全的、生命攸關的軟件的開發(fā)者可以考慮開發(fā)范型。比如：航空電子、醫(yī)療設備軟件的開發(fā)。,chapter 2,Phased development model階段化開發(fā)模型,chapter 2,increments and iterat

26、ion增量和迭代模型,chapter 2,增量模型,chapter 2,特點,增量 小而可用的軟件特點 在前面增量的基礎上開發(fā)后面的增量 每個增量的開發(fā)可用瀑布或快速原型模型 迭代的思路,chapter 2,Spiral model螺旋模型,確定目標備選方案約束,評估備選方案和風險,實施計劃,開發(fā)與測試,chapter 2,Boehm在1988年提出 螺旋模型 == 線性模型 十 迭代.原型十

27、系統(tǒng)化 螺旋模型適用于計算機軟件整個生命周期,chapter 2,螺旋模型的使用,軟件工程項目從螺旋中心開始啟動，沿順時針方向前進。 第一圈 產生產品規(guī)格說明； 第二圈 產生一個用于開發(fā)的原型； 第三圈 產生軟件產品的初始版本； 第四圈 產生軟件產品比較完善的新版本 ……,chapter 2,螺旋模型的優(yōu)點,符合人們認識現(xiàn)實世界和軟件開發(fā)

28、的客覌規(guī)律支持軟件整個生命周期保持瀑布模型的系統(tǒng)性、階段性利用原型評估降低開發(fā)風險開發(fā)者和用戶共同參與軟件開發(fā)，盡早發(fā)現(xiàn)軟件中的錯誤不斷推出和完善軟件版本，有助于需求變化，獲取用戶需求，加強對需求的理解,chapter 2,構件集成模型（專用過程模型）,chapter 2,特點,融合了螺旋模型的特征基于構件庫支持軟件開發(fā)的迭代方法軟件重用基于構件的開發(fā)可以縮短大約70%的開發(fā)周期，降低84%的項目成本。

29、 統(tǒng)一軟件開發(fā)過程就是基于構件開發(fā)模型的代表。使用統(tǒng)一建模語言。,chapter 2,Rational 統(tǒng)一過程,統(tǒng)一過程嘗試從傳統(tǒng)軟件過程中挖掘最好的特征和性質，單一敏捷軟件開發(fā)中許多好的原則來實現(xiàn)。RUP是一種以“用例驅動、以體系結構為核心、迭代及增量”的軟件過程框架。由UML方法和工具支持Rational Unified Process（RUP） 是軟件工程的過程。它提供了在開發(fā)組織中分派任務和責任的紀律化方法。它的目標是在

30、可預見的日程和預算前提下，確保滿足最終用戶需求的高質量產品。RUP以適合于大范圍項目和機構的方式捕捉了許多現(xiàn)代軟件開發(fā)過程的最佳實踐,chapter 2,Rational Unified Process 有四個階段：先啟 – 定義整個項目的范圍精化 – 制定項目計劃、描述功能、建立體系架構框架 和可執(zhí)行的“體系結構基線”構建 – 構造軟件產品產品化 – 將軟件產品移交到最終用戶手中,chapter 2,階

31、段結束標志著重要的里程碑,chapter 2,迭代和階段,迭代 是一個基于確定計劃和評估標準并且產生一個可執(zhí)行發(fā)布版（內部的或外部的）的獨特活動序列。,chapter 2,規(guī)程,chapter 2,初啟階段(Inception),確定項目開發(fā)的目標和范圍定義主要的需求：用例以及主要的用例場景根據(jù)一些主要的用例場景來構建一個基本架構估算開發(fā)周期和成本估計潛在的風險主要實踐活動－用例建模 注意：用例模型可以列舉大多數(shù)所需的用例和參

32、與者，但其中可能只有10％的用例會被詳細描述，這樣就足以建立起有關系統(tǒng)的范圍、目標和風險的高層的大致構想,chapter 2,手機開發(fā)項目 – 初啟階段,,chapter 2,精化化階段,精化化階段不是一個需求或設計階段，而是一個迭代實現(xiàn)核心架構并降低高風險的階段 在細化前不需要定義大多數(shù)需求，10％的詳細用例書寫出來即可 先處理具有風險的元素，開始實際產品代碼的編寫，產生可執(zhí)行架構 除了極少數(shù)理解良好的問題外需要多次迭代,cha

33、pter 2,精化階段,,chapter 2,構建階段,盡快完成軟件產品的開發(fā)迭代實現(xiàn)遺留下來的風險較低和比較容易的元素，準備部署 在保證開發(fā)進度的同時達到足夠的軟件質量獲得一些有用的版本 (alpha, beta等),chapter 2,構建階段,……,,chapter 2,轉化階段,獲得涉眾的認同：產品部署已經(jīng)完成并且滿足預定的質量標準盡快達到最終穩(wěn)定的產品基線,chapter 2,統(tǒng)一過程的模型,用例模型：用例與用戶之間

34、關系(交互時)分析模型：系統(tǒng)的行為初步分配給一組對象設計模型：系統(tǒng)靜態(tài)結構定義為子系統(tǒng)、類、接口， 并定義由子系統(tǒng)、類和接口之間的協(xié)作所實現(xiàn)的用例實現(xiàn)模型：構件（表現(xiàn)為源代碼）和類到構件的映射實施模型：計算機的物理節(jié)點和構件到這些節(jié)點的映射測試模型：用于驗證的測試用例,chapter 2,Tools and Techniques for Process Modeling過程建模工具和技術,Choose Language or

35、 Notation：選擇語言或符號Static model：顯示了輸入轉化為輸出的過程Dynamic model：能夠執(zhí)行過程,用戶可以看到中間過程和最后結果是如何轉化的,chapter 2,Static Modeling,Example: Lai notationActivity活動Sequence順序Process Model過程模型Resource資源Control控制Policy策略Organization組織

36、結構State tablesinformation about the completeness of each artifact at a given time.在給定時間內每個工件完成情況的信息Transition diagramshow the states are related to one another展示了彼此之間是如何聯(lián)系的,工具和技術,chapter 2,State Table and Transition

37、 Diagram靜態(tài)表和變換圖,Parked:((state_of(car.engine)=off)(state_of(car.gear)=park)(state_of(car.speed)=stand)),chapter 2,Dynamic process models,Enables enaction of process to see what happens to resources and artifacts as ac

38、tivities occur當活動發(fā)生時能觀察到資源和工件發(fā)生了什么Simulate alternatives and make changes to improve the process模擬替代方案并作出改良來改進過程Example: systems dynamics model,chapter 2,Marvel process language,Three constructs: classes, rules, tool

39、envelopes類、規(guī)則、工具封裝Three-part process description:rule-based specification of process behavior基于規(guī)則的過程行為說明object-oriented definition of model’s information process模型信息的OO定義set of envelopes to interface between Marvel a

40、nd external software tools外部軟件工具和Marvel接口之間的一組封裝,chapter 2,Desirable properties of process modeling tools and techniques過程建模工具和技術中有價值的屬性,Facilitates human understanding and communication有利于人們的理解與交流Supports process impro