軟件工程理論與實踐課件：第2章 過程和生命周期的建模

1、SOFTWARE ENGINEERINGModeling the Process and Life cycle 過程和生命周期的建模本章的主要內(nèi)容What we mean by a process 過程的含義Software development products 軟件開發(fā)的產(chǎn)品processes, and resources 過程和資源Several models of the software development process 軟件開發(fā)過程的若干模型Tools and techniques for process modeling 過程建模的工具和技術軟件工程理論與實踐2.1the

2、 meaning of process 過程的含義 A process defines who is doing what, when and how, in order to reach a certain goal. 過程定義了誰在作什么，什么時間怎樣作。以便完成一個確定的目標 Software Engineer ProcessNew or changedrequirementNew or changedsystem軟件工程理論與實踐What is ProcessA Series of steps involving activities, constraints, and resourc

3、es that produce an intended output of some kind. 一系列涉及到活動、約束和資源的步驟，他們產(chǎn)生某種類型的有目的的輸出 A process usually involves a set of tools and techniques 一個過程通常涉及一系列的工具和技術 軟件工程理論與實踐Process Characteristics過程的特征 1.The process prescribes all of the major process activities 過程規(guī)定了所有主要過程活動2.Process uses resources, subj

4、ect to a set of constraints (such as schedule ),and produces intermediate and final products 過程使用資源、服從于一組約束(比如進度約束)，產(chǎn)生中間結(jié)果和最終產(chǎn)品。3.The process may be composed of subprocesses that are linked in some way. The process may be defined as a hierarchy of processes, organized so that each subprocess has its

5、 own process model 可由子過程組成，這些子過程用某種方式鏈接起來。過程可以定義為分層的過程等級結(jié)構，以便每個子過程具有自己的過程模型。軟件工程理論與實踐Process Characteristics過程的特征 4.Each process activity has entry and exit criteria , so that we know when the activity begins and ends. 每個過程活動具有有入口和出口標準，這樣可以知道活動何時開始及何時結(jié)束。5.The activities are organized in a sequence,

6、so that it is clear when one activity is performed relative to the other activities. 活動以一定順序組織，因此，一個活動相對于其他活動何時完成是很清楚的。6.Every process has a set of guiding principles that explain the goals of each activity 每個過程具有一系列的指導原則，以解釋每個活動的目標7.Constraints or controls may apply to an activity, resource or prod

7、uct 約束與控制可以應用到任何活動、資源或產(chǎn)品中。軟件工程理論與實踐 When the process involves the building of some product, we sometimes refer to the process as a life cycle.當過程涉及到某些產(chǎn)品的開發(fā)時，有時把這種過程稱為生命周期 The software development process is sometimes called the software life cycle.軟件開發(fā)過程有時被稱為軟件生命周期 Life Cycle生命周期軟件工程理論與實踐 They impos

8、e consistency and structure on a set of activities.它使一組活動有了一致性和結(jié)構 The process structure guides our actions by allowing us to examine, understand, control, and improve the activities that comprise the process.過程結(jié)構用檢查、理解、控制和改善組成過程的活動來指導我們的行為 Enabling us to capture our experiences and pass them along t

9、o others.過程的重要性還在于它能使我們獲得經(jīng)驗并把它傳授給別人 Processes are important過程的重要性 軟件工程理論與實踐軟件過程是將用戶的需求轉(zhuǎn)化成有效的軟件解決方案的一系列活動。過程具有一系列的性質(zhì)：時間性、并發(fā)性、嵌套性和度量性等。許多軟件組織無法正確定義和控制這一過程，但這恰恰是組織改進的關鍵。軟件過程軟件工程理論與實踐軟件過程軟件生命周期過程包括：早期：立項需求分析設計編碼測試交付維護退役現(xiàn)在又加入：質(zhì)量保證管理各種活動環(huán)境基礎設施配置文檔管理軟件工程理論與實踐軟件生存期的階段劃分（根據(jù)國標計算機軟件開發(fā)規(guī)范）(1)可行性研究與計劃(2)需求分析(3)總體

10、設計(4)詳細設計(5)實現(xiàn)(6)集成測試(7)確認測試(8)使用和維護上游下游軟件工程理論與實踐軟件生命周期（Software Life Cycle）如同任何事物一樣，軟件也有一個孕育、誕生、成長、成熟、衰亡、演化的生存過程；為了用工程化方式有效地管理軟件的全過程，軟件的生存過程也可以劃分為好幾個階段，由此逐步形成“軟件生命周期”的概念；它是一個從用戶需求開始，經(jīng)過開發(fā)、交付使用，在使用中不斷增補修訂，直至讓位于新軟件的全過程；概括地說，軟件生命周期由軟件定義、軟件開發(fā)和運行維護3個時期組成，每個時期又進一步劃分成若干個階段。軟件工程理論與實踐軟件定義時期問題定義階段：界定問題的范圍，確切地

11、定義問題；可行性研究階段：研究問題的范圍，探索這個問題是否值得去解，是否有可行的解決辦法；需求分析階段：確定目標系統(tǒng)必須具備哪些功能；另外，要估計完成該項工程所需要的資源和成本，制定工程進度表。軟件工程理論與實踐軟件開發(fā)時期具體設計和實現(xiàn)在前一個時期定義的軟件?？傮w設計階段：設計出實現(xiàn)目標系統(tǒng)的幾種可能的方案，權衡利弊推薦一最佳方案，并制定實現(xiàn)最佳方案的詳細計劃，以及設計軟件的體系結(jié)構；詳細設計階段：設計出程序的詳細規(guī)格說明；編碼和單元測試階段：寫出正確的、容易理解、容易維護的程序模塊；綜合測試階段：通過各種類型的測試使軟件達到預定的要求。集成測試/驗收測試/現(xiàn)場測試/平行運行軟件工程理論與實

12、踐運行維護（軟件維護）時期維護階段的關鍵任務是：通過各種必要的維護活動使軟件系統(tǒng)持久地滿足用戶的需要。通常的4種維護活動：改正性維護：診斷和改正使用過程中發(fā)現(xiàn)的軟件錯誤；適應性維護：修改軟件以適應環(huán)境的變化；完善性維護：根據(jù)用戶需要改進或擴充軟件使之更完善；預防性維護：修改軟件從而為將來的維護活動做好準備。軟件工程理論與實踐新的國際標準定義的軟件生存過程（1995 ISO/IEC 12207）軟件生存期過程支持過程組織過程主要過程獲取過程供應過程開發(fā)過程運行過程維護過程文檔編制過程配置管理過程質(zhì)量保證過程驗證過程確認過程聯(lián)合評審過程審核過程問題解決過程管理過程基礎設施過程改進過程培訓過程 2.

13、2 software process modeling軟件過程模型 軟件工程理論與實踐Why software process modeling為什么建立軟件過程模型？ Some model are prescriptions for the way software development should progress, and others are descriptions of the way software development is done in actuality.有些模型是軟件開發(fā)應遵循的步驟，有些描述了完成軟件開發(fā)的實際步驟。軟件工程理論與實踐Why software

14、process modeling為什么建立軟件過程模型？ Writes down a description of development process, forms a common understanding of the activities, resources, and constraints involved in software development.形成對軟件開發(fā)中涉及到的活動、資源和約束的共同理解。 Helps the development team find inconsistencies, redundancies, and omissions in the pr

15、ocess and in its constituent parts.有助于開發(fā)小組發(fā)現(xiàn)過程及其組織成分中的不一致、冗余和遺漏。 軟件工程理論與實踐Why software process modeling為什么建立軟件過程模型？ The model reflects the goals of development, such as building high-quality software finding faults early in development, and meeting required budget and schedule constraints. 反映開發(fā)的目標(如

16、構建高質(zhì)量軟件、早期發(fā)現(xiàn)錯誤、滿足預算和開發(fā)進度)。 Every process should be tailored for the special situation in which it will be used.根據(jù)每個過程將被使用的特殊情況對其進行裁剪。 軟件工程理論與實踐Typical process models典型的過程模型 Waterfall model 瀑布模型Prototyping 原型化模型V-model V-模型Operational specification 操作說明模型Transformational model 變換模型Phased development:

17、 increments and iteration 增量和迭代模型Spiral model 螺旋模型軟件工程理論與實踐Waterfall model瀑布模型System DesignProgram DesignCodingUnit & Inte-gration TestingSystem TestingAcceptance TestingOperation & MaintenanceRequirements Analysis軟件工程理論與實踐Characters of Waterfall model瀑布模型的特性 One development stage should be complete

18、d before the next begins. Steps dont goes backward.一個階段必須在另一個開發(fā)階段開始之前完成，步驟不能返回。 軟件工程理論與實踐瀑布模型特點階段間具有順序性和依賴性必須等前一階段的工作完成之后，才能開始后一階段的工作前一階段的輸出文檔就是后一階段的輸入文檔推遲實現(xiàn)的觀點清楚地區(qū)分邏輯設計與物理設計，盡可能推遲程序的物理實現(xiàn)軟件工程理論與實踐瀑布模型特點質(zhì)量保證的觀點每個階段都必須完成規(guī)定的文檔，沒有交出合格的文檔就是沒有完成該階段的任務。每個階段結(jié)束前都要對所完成的文檔進行評審，以便盡早發(fā)現(xiàn)問題，改正錯誤。軟件工程理論與實踐 Merits of

19、 Waterfall model瀑布模型的優(yōu)點 Has been used to prescribe software development activities in a variety of contexts.已被用于在各種情況下規(guī)定軟件開發(fā)活動。 Is very useful in helping developers lay out what they need to do.幫助開發(fā)人員明確需要做什么 軟件工程理論與實踐 Merits of Waterfall model瀑布模型的優(yōu)點 Easy to explain to customers who are not familiar

20、 with software development 易于向不熟悉開發(fā)的顧客作出解釋 It makes explicit which intermediate products are necessary in order to begin the next stage.清楚說明了下一階段的開發(fā)需要哪些中間產(chǎn)品 More complex models are really just embellishments of the waterfall. 更復雜的模型是它的修改。其他模型的基礎 軟件工程理論與實踐 Merits of Waterfall model瀑布模型的優(yōu)點 其他:可強迫開發(fā)人員采

21、用規(guī)范的方法（例如，結(jié)構化技術）嚴格地規(guī)定了每個階段必須提交的文檔要求每個階段交出的所有產(chǎn)品都必須經(jīng)過質(zhì)量保證小組的仔細驗證 瀑布模型的成功在很大程度上是由于它基本上是一種文檔驅(qū)動的模型軟件工程理論與實踐Shortage of Waterfall model瀑布模型的缺點 The biggest problem with waterfall model is that it does not not reflect the way code is really developed 瀑布模型的最大問題就是它不能反映實際的代碼開發(fā)方式。軟件工程理論與實踐Software development p

22、rocess in reality實際的軟件開發(fā)過程Requirements Analysis需求分析System Design系統(tǒng)設計Program Design程序設計Program implementation執(zhí)行Unit Testing單元測試Integration Testing集成測試System Testing系統(tǒng)測試Delivery交付Maintenance維護軟件工程理論與實踐Shortage of Waterfall model瀑布模型的缺點 The model imposes a project management structure on system develop

23、ment 這個模型給系統(tǒng)開發(fā)強加了一種項目管理結(jié)構.Fail to treat software as a problem-solving process. present a manufacturing view. 沒能把軟件看成是一個問題解決的過程，僅表達了一種制造觀點。The model tells us nothing about the typical back-and-forth activities that lead to creating a final product. 模型沒告訴我們開發(fā)最終產(chǎn)品所需的典型的不斷改進的活動。軟件工程理論與實踐要求用戶不經(jīng)過實踐就提出完整準確

24、的需求，在許多情況下都是不切實際的僅僅通過寫在紙上的靜態(tài)的規(guī)格說明，很難全面正確地認識動態(tài)的軟件產(chǎn)品將本來非線性的軟件開發(fā)過程人為地加以線性化，不符合實際中的軟件開發(fā)情況軟件開發(fā)耗時長，可運行版本要等到項目后期才能得到，一旦在后期發(fā)現(xiàn)錯誤，付出的代價將是巨大的。 “由文檔驅(qū)動”的這個事實也是瀑布模型的一個主要缺點,這可能導致最終開發(fā)出的軟件產(chǎn)品不能真正滿足用戶的需要瀑布模型缺點軟件工程理論與實踐Enhance of Waterfall model加強的瀑布模型Validate確認Verify驗證Requirements AnalysisSystem DesignProgram DesignCo

25、dingUnit & Integration TestingSystem TestingAcceptance TestingOperation & MaintenancePrototyping原型化軟件工程理論與實踐Enhance of Waterfall model加強的瀑布模型 Prototype is a partially developed product that enables customers and developers to examine some aspect of the proposed system and decide if it is suitable or

26、 appropriate for the finished product. 原型就是部分開發(fā)的產(chǎn)品，這個產(chǎn)品能使顧客和開發(fā)人員檢驗所建議系統(tǒng)的某些方面，并且判斷它對最終產(chǎn)品是否合適。Validation ensures that the system has implemented all of the requirements, so that each system function can be traced back to a particular requirement in the specification. (built the right product) 確認保證系統(tǒng)實現(xiàn)

27、了所有的需求，這樣每個系統(tǒng)功能可以回溯到系統(tǒng)說明的一個特定需求上。Verification ensures that each function works correctly. (built it right) 驗證確保每個功能正確運作。軟件工程理論與實踐V-model V-模型Validate Requirements確認需求Verify Design驗證設計Requirements AnalysisOperation & MaintenanceAcceptance Testing驗收測試System TestingSystem DesignUnit & Inte-gration Test

28、ingProgram DesignCoding軟件工程理論與實踐瀑布模型的變種，增加了測試活動與分析和設計的關系強調(diào)測試活動與分析和設計之間的關聯(lián)：單元測試和集成測試校驗程序設計；系統(tǒng)測試校驗（verify）系統(tǒng)設計； 系統(tǒng)測試是軟件作為整個基于計算機系統(tǒng)的一個元素，與計算機硬件、外設、某些支持軟件，數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合在一起，在實際運行環(huán)境下對計算機系統(tǒng)進行一系列的測試。驗收測試確認（validate）需求；與瀑布模型關注文檔和工作產(chǎn)品不同，V模型的關注點是軟件開發(fā)各階段的活動以及正確性，因此V模型是以活動驅(qū)動的。V-model V-模型軟件工程理論與實踐本質(zhì)是把瀑布模型中一些隱含的

29、迭代過程明確出來，使開發(fā)活動和驗證活動的相關性更加明顯；V模型使抽象等級的概念也更明顯：所有從需求到實現(xiàn)部分的活動關注的是建立更多的系統(tǒng)詳細表述，而所有從實現(xiàn)到交付運行的活動關注的是對系統(tǒng)的驗證和確認。和瀑布模型一樣，都是對軟件開發(fā)過程過份簡單、理想化的抽象，對需求變化的適應性差。V模型的改良之處與存在的問題軟件工程理論與實踐Prototyping 原型化模型PROTOTYPEREQUIREMENTSPROTOTYPEDESIGNPROTOTYPESYSTEMTESTLIST OF REVISIONSLIST OF REVISIONS修改列表LIST OF REVISIONSrevise pr

30、ototype修改原型user/customerReview評審SYSTEMREQUIREMENTS(sometimes informal or incomplete有時是非正式或不完全)DELIVEREDSYSTEM交付軟件工程理論與實踐Prototype 原型A Prototype is a partially developed product that enables customers and developers to examine some aspect of the proposed system and decide if it is suitable or appropr

31、iate for the finished product.一個原型就是部分開發(fā)的產(chǎn)品，這個產(chǎn)品能使顧客和開發(fā)人員檢驗所建議系統(tǒng)的某些方面，并且判斷它對最終產(chǎn)品是否適合。軟件工程理論與實踐由于要求能夠快速建立可供運行的模型，原型不可能象最終產(chǎn)品一樣面面俱到；客戶：不可把原型當作軟件的正式運行版本；開發(fā)人員：同上。還必須牢記原型中沒有考慮質(zhì)量因素的部分；使用前要與用戶達成一致：原型只是模型而已。使用原型必須要注意的問題軟件工程理論與實踐Operational specification操作說明模型Execute and Revise執(zhí)行和修改Operational Specification 操

32、作說明（problem-oriented）testSystem Requirements（sometimes informal or incomplete）Delivered system交付使用的系統(tǒng)Transformed Specification（implementation-oriented）面向?qū)崿F(xiàn)軟件工程理論與實踐Transformational model 變換模型Compare with requirements；update and needed與需求進行比較；必要時加以更新Formal Specification形式化說明Transform變換 TestFormal Dev

33、elopment Record正式開發(fā)記錄Sequence of transformations plus rationale for them一系列的變化及其基本原理Delivered SystemSystem Requirements（sometimes informal or incomplete）Transform 2Transform 1軟件工程理論與實踐Using automated support, the transformational process applies a series of transformations to change a specification

34、into a deliverable system.利用自動化工具的支持，變換過程使用一系列變換把需求變成一個可交付使用的系統(tǒng)（Balzer 1981） compiling 編譯 Sample transformation can include changing the data representations 改變數(shù)據(jù)表示 selecting algorithms 選擇算法 optimizing 優(yōu)化 軟件工程理論與實踐Phased development: increments and iteration 階段化開發(fā)：增量和迭代模型Build Release 1構建版本1Build Re

35、lease 2構建版本2Build Release 3構建版本3Use Release 1使用版本1Use Release 2使用版本2Use Release 3使用版本3TimeUsers用戶Developers開發(fā)人員Development Systems開發(fā)系統(tǒng)Production Systems產(chǎn)品系統(tǒng)軟件工程理論與實踐Incremental Development 增量開發(fā)Iterative Development 迭代開發(fā)軟件工程理論與實踐the system as specified in the requirements documents is partitioned int

36、o subsystems by functionality. The releases are defined by beginning with one small, functional subsystem and then adding functionality with each new release.需求文檔中指明的系統(tǒng)按功能劃分為子系統(tǒng)。定義發(fā)布時首先是定義一個小的、具有一定功能的子系統(tǒng)，然后在每一個新的發(fā)布中增加新的功能 Incremental Development:增量開發(fā) delivers a full system at the very beginning and

37、the changes the functionality of each subsystem with new release.是在一開始就移交一個完整的系統(tǒng)，然后在每一個新的發(fā)布版本中改變每一個子系統(tǒng)的功能。 Iterative development:迭代開發(fā) 軟件工程理論與實踐優(yōu)點：Training can begin on an early release. 培訓可以在早期的版本中開始 Market can be created early for functionality that has never before been offered. 可以為那些以前從未實現(xiàn)的功能提前開拓

38、市場 Frequent releases allow developers to fix unanticipated problems globally and quickly, as they are reported form the operational system.當在使用的系統(tǒng)中有未預料的問題報告時，在新版本中開發(fā)人員可以全面快速修正這些問題 The development team can focus on different areas of expertise with different releases. 開發(fā)小組可以把不同的發(fā)布版本針對不同的領域 軟件工程理論與實踐難

39、點：在把每個新的增量構件集成到現(xiàn)有軟件體系結(jié)構中時，必須不破壞原來已經(jīng)開發(fā)出的產(chǎn)品必須把軟件的體系結(jié)構設計得便于按這種方式進行擴充，向現(xiàn)有產(chǎn)品中加入新構件的過程必須簡單、方便，也就是說，軟件體系結(jié)構必須是開放的軟件工程理論與實踐Spiral model螺旋模型Determine Goals、目標Alternatives、方案Constraints限制Plan計劃Evaluate AlternativesAnd Risks方案和風險評估Develop And Test開發(fā)和測試軟件工程理論與實踐螺旋模型螺旋模型沿著螺線旋轉(zhuǎn)，在四個象限上分別表達四個任務區(qū)域，即：制定計劃確定軟件目標，選定實施方案

40、，弄清項目開發(fā)的限制；風險分析分析所選方案，考慮如何識別和消除風險；實施工程實施軟件開發(fā)；客戶評估評價開發(fā)工作，提出修正建議，并計劃下一個階段的任務；軟件工程理論與實踐從涉及到的風險角度看待軟件開發(fā)過程，把開發(fā)活動和風險管理結(jié)合起來。螺旋模型的基本思想是，盡量降低風險。 理解這種模型的一個簡便方法，是把它看作在每個階段之前都增加了風險分析過程的快速原型模型軟件項目中的風險：人員硬件設備項目的生存能力等螺旋模型軟件工程理論與實踐實質(zhì)上相當于在瀑布模型的每個階段開始前引入風險分析，并由客戶對階段性產(chǎn)品做出評審，這對保證軟件產(chǎn)品質(zhì)量十分有利；由于引入風險分析等活動，測試活動的確定性增強了；螺旋模型最

41、外層代表維護，開發(fā)與維護采用同樣方式，使維護得到與開發(fā)同樣的重視。螺旋模型的優(yōu)點軟件工程理論與實踐主要適合內(nèi)部開發(fā)，否則風險分析必須在簽訂合同前完成，或者爭取客戶的最大理解；只適合大型軟件項目的開發(fā)，否則，每個階段的風險分析將占用很大一部分資源，增加成本；對開發(fā)人員的風險分析能力是極大的考驗，否則，模型將退化到瀑布模型，甚至更糟。螺旋模型的缺點軟件工程理論與實踐噴泉模型進一步開發(fā)運行狀態(tài)集成和測試階段編碼階段面向?qū)ο笤O計階段面向?qū)ο蠓治鲭A段需求階段維護期“噴泉”體現(xiàn)了面向?qū)ο筌浖_發(fā)過程迭代和無縫的特性軟件工程理論與實踐注意事項 為避免使用噴泉模型開發(fā)軟件時開發(fā)過程過于無序，應該把一個線形過程

42、作為總目標面向?qū)ο蠓缎捅旧硪蠼?jīng)常對開發(fā)活動進行迭代或求精噴泉模型軟件工程理論與實踐敏捷方法敏捷過程（2001/2敏捷軟件開發(fā)宣言 The Manifesto of the Agile Alliance ）敏捷方法的價值觀個體和交互勝過過程和工具可以工作的軟件勝過面面俱到的文檔客戶合作勝過合同談判響應變化勝過遵循計劃軟件工程理論與實踐敏捷過程的原則最優(yōu)先要做的是通過盡早的,持續(xù)的交付有價值的軟件來使客戶滿意即使到了開發(fā)的后期,也歡迎改變需求.敏捷過程利用變化來為客戶創(chuàng)造競爭優(yōu)勢經(jīng)常性地交付可以工作的軟件,交付的間隔可以從幾周到幾個月,交付的時間間隔越短越好在整個項目開發(fā)期間,業(yè)務人員和開發(fā)人員

43、必須天天都在一起工作圍繞被激勵起來的個人來構件項目.給他們提供所需要的環(huán)境和支持,并且信任他們能夠完成工作軟件工程理論與實踐敏捷過程的原則 (續(xù))在團隊內(nèi)部,最具有效果并且富有效率的傳遞信息的方法,就是面對面的交談工作的軟件是首要的進度度量標準敏捷過程提倡可持續(xù)的開發(fā)速度.責任人、開發(fā)者和用戶應該能夠保持一個長期的、恒定的開發(fā)速度不斷地關注優(yōu)秀的技能和好的設計會增強敏捷能力簡單是根本的最好的架構、需求和設計出自于自組織的團隊每隔一段時間，團隊就會在如何才能更有效地工作方面進行反省，然后相應地對自己的行為進行調(diào)整軟件工程理論與實踐SCRUM : Schwaber, K., & Beddle, M

44、. (2002). Agile Software Development with Scrum. NJ: Prentice Hall. Crystal : Cockburn, A. (2002). Agile Software Development. Boston: Addison-Wesley. Feature Driven Development (FDD) : Peter Coad, Eric Lefebvre, and Jeff De Luca (1999). Java Modeling In Color with UML: Enterprise Components and Pro

45、cess. Prentice Hall.Adaptive Software Development (ADP) : James A. Highsmith III (2000). Adaptive Software Development, Dorset House Publishing. extreme Programming (XP)敏捷過程軟件工程理論與實踐極限編程是敏捷過程中最富盛名的一個，其中“極限”的含義是指把最好的開發(fā)實踐運用到極致。目前極限編程已經(jīng)成為一個典型的開發(fā)方法，廣泛應用于需求模糊且經(jīng)常改變的場合。特點：對變化和不確定性反應更快速，更敏捷快速的同時保持可持續(xù)的開發(fā)速度極限

46、編程（eXtreme Programming, XP）軟件工程理論與實踐客戶作為開發(fā)團隊的成員使用用戶素材短交付周期（每兩周完成一次迭代）驗收測試結(jié)對編程測試驅(qū)動的開發(fā)集體所有（程序代碼屬于整個開發(fā)小組，每個成員都有修改代碼的權利，都對全部代碼負責）極限編程的有效實踐軟件工程理論與實踐持續(xù)集成（一日內(nèi)多次集成，不斷回歸測試）可持續(xù)的開發(fā)速度（周工作時間不超過40小時，連續(xù)加班不超過兩周）開放的工作空間及時調(diào)整計劃重構使用隱喻（隱喻是把整個系統(tǒng)聯(lián)系在一起的全局視圖，描述系統(tǒng)如何運做，如何把新功能加入到系統(tǒng)中）極限編程（eXtreme Programming, XP）軟件工程理論與實踐極限編程的整

47、體開發(fā)過程體系結(jié)構試探制訂交付計劃難點試探驗收測試迭代開發(fā)不確定的估計確定的估計隱喻交付計劃最新版本需求新用戶故事差錯下一次迭代用戶認可小交付測試用例用戶故事軟件工程理論與實踐極限編程的迭代過程制訂迭代計劃站立會議代碼共享編程驗收測試交流與討論未完成的任務用戶故事交付計劃項目速率任務分配下一個任務或未通過驗收的模塊測試用例差錯用戶認可小交付共享的信息新用戶故事新項目速率新功能最新版本結(jié)對編程與人員輪換；持續(xù)地優(yōu)化設計；循環(huán)冗余檢測軟件工程理論與實踐2.3 Tools and Techniques for Process Modeling過程建模工具和技術 There are many choi

48、ces for modeling tools and techniques, you decide what you want to capture in your process model. Your choice for notation depends on what you want to capture in your model. The notations range from textual ones that express processes as functions, to graphical ones that depict processes as hierarch

49、ies of boxes and arrows, to combinations of pictures and text that link the graphical depiction to tables and functions elaborating on the high-level illustration. 一旦決定了在過程模型中獲取什么內(nèi)容，就有很多的建模工具和技術可供選擇。標記符號的選擇依賴于你想在模型中獲取什么。符號可以是文本方式的，它把過程表達為函數(shù)；也可以是圖形的，它把過程描述為正方形和箭頭組成的分層結(jié)構；也可以是圖形加文本組合的，它把圖形化的描述與表格和函數(shù)組合起

50、來，以詳細描述高層的說明。 軟件工程理論與實踐Type of model 模型的類型Static model depicts the process, showing that the inputs are transformed to outputs.靜態(tài)模型描述了過程，顯示了輸入轉(zhuǎn)化為輸出的過程。Dynamic model can enact the process, so the user can see how intermediate and final products are transformed over time.動態(tài)模型能夠執(zhí)行過程，用戶能夠看到中間過程和最后的結(jié)果是如何

51、轉(zhuǎn)化的。軟件工程理論與實踐The elements of a process are viewed in terms of seven types:過程元素有以下7種類型：Activity 活動Sequence 順序Process model 過程模型Resource 資源Control 控制Policy 策略Organization 組織結(jié)構Static Modeling: Lai Notation 靜態(tài)模型：Lai符號軟件工程理論與實踐Activity（活動）: Something that will happen in a process. 過程中將要發(fā)生的事情。This element

52、 can be related to what happens before and after, what resources are needed, what triggers the activitys start, what rules govern the activity, how to describe the algorithms and lessons learned, and how to relate the activity to the project team. 此元素與幾個因素有關：該活動之前和之后發(fā)生的事情、所需資源、什么觸發(fā)了活動、約束活動的規(guī)則、如何描述算法

53、和經(jīng)驗，以及如何把活動和項目小組聯(lián)系起來。軟件工程理論與實踐Sequence（順序）: The order of activities. 活動的順序。The sequence can be described using triggers, programming constructs, transformations, order, or satisfaction of conditions. 順序可以用觸發(fā)器、程序結(jié)構、變換、排序或滿足的條件來描述。軟件工程理論與實踐Process model（過程模型）: A view of interest about the system.關于系統(tǒng)興

54、趣的觀點。Parts of the process may be represented as a separate model, either to predict process behavior or to examine certain characteristics. 部分過程可以表示成分離的模型，用來預測過程行為或分析一定的特性。 軟件工程理論與實踐Resource（資源）: A necessary item, tool, or person. 必需的事項、工具或人員。Resources can include equipment, time, office space, peop

55、le, techniques, and so on. The process model identifies how much of each resource is needed for each activity. 資源包括設備、時間、辦公空間、人員、技術等。過程模型確定每個活動需要的各種資源的數(shù)量。軟件工程理論與實踐Control（控制）: An external influence over process enactment.對執(zhí)行過程的外部影響。The controls may be manual or automatic, human or mechanical. 控制可以是手

56、動或自動的、人工或機械的。軟件工程理論與實踐Policy（策略）: A guiding principle.指導原則。This high-level process constraint influences process enactment. It may include a prescribed development process, a tool that must be used, or a mandatory management style. 這種高層的過程約束影響過程的執(zhí)行，它可能包含一個規(guī)定的開發(fā)過程、必須使用的工具或強制性的管理模式。 軟件工程理論與實踐Organizat

57、ion（組織結(jié)構）: The hierarchical structure of process agents, with physical grouping corresponding to logical grouping and related roles. 過程代理的等級結(jié)構，使實際分組和邏輯分組及相關角色相對應。The mapping from physical to logical grouping should be flexible enough to reflect changes in physical environment. 從實際分組到邏輯分組的映射必須足夠靈活以反映

58、實際環(huán)境的變化。 軟件工程理論與實踐Lais notation includes several templates, such as Artifact Definition Template, which records information about particular artifacts.(P64) Lai符號包括若干模板，如工件定義模板，該模板記錄特定的工件信息。Other templates define relations, process states, operations, analysis, actions, and roles. 其他的模板定義了關系、過程狀態(tài)、操作

59、、分析、活動和角色。Graphical diagrams represent the relationships between elements, capturing the main relationships and secondary ones.(P65) 圖形范式表示了元素之間的相互關系，以獲取主要的關系和次要的關系。 Transition diagrams supplement the process model by showing how the states are related to one another. (P66) 變換圖是對過程模型的補充，它展示了狀態(tài)彼此之間是如何聯(lián)系的。 軟件工程理論與實踐We want to describe a model of the process and then watch as software shows us how the resources flow through activities to become outputs. 我們希望給出過程的