




版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報(bào)或認(rèn)領(lǐng)
文檔簡介
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 過程建模的工具和技術(shù)軟件工程理論與實(shí)踐2.1the
2、 meaning of process 過程的含義 A process defines who is doing what, when and how, in order to reach a certain goal. 過程定義了誰在作什么,什么時(shí)間怎樣作。以便完成一個(gè)確定的目標(biāo) Software Engineer ProcessNew or changedrequirementNew or changedsystem軟件工程理論與實(shí)踐What is ProcessA Series of steps involving activities, constraints, and resourc
3、es that produce an intended output of some kind. 一系列涉及到活動(dòng)、約束和資源的步驟,他們產(chǎn)生某種類型的有目的的輸出 A process usually involves a set of tools and techniques 一個(gè)過程通常涉及一系列的工具和技術(shù) 軟件工程理論與實(shí)踐Process Characteristics過程的特征 1.The process prescribes all of the major process activities 過程規(guī)定了所有主要過程活動(dòng)2.Process uses resources, subj
4、ect to a set of constraints (such as schedule ),and produces intermediate and final products 過程使用資源、服從于一組約束(比如進(jìn)度約束),產(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 可由子過程組成,這些子過程用某種方式鏈接起來。過程可以定義為分層的過程等級(jí)結(jié)構(gòu),以便每個(gè)子過程具有自己的過程模型。軟件工程理論與實(shí)踐Process Characteristics過程的特征 4.Each process activity has entry and exit criteria , so that we know when the activity begins and ends. 每個(gè)過程活動(dòng)具有有入口和出口標(biāo)準(zhǔn),這樣可以知道活動(dòng)何時(shí)開始及何時(shí)結(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. 活動(dòng)以一定順序組織,因此,一個(gè)活動(dòng)相對于其他活動(dòng)何時(shí)完成是很清楚的。6.Every process has a set of guiding principles that explain the goals of each activity 每個(gè)過程具有一系列的指導(dǎo)原則,以解釋每個(gè)活動(dòng)的目標(biāo)7.Constraints or controls may apply to an activity, resource or prod
7、uct 約束與控制可以應(yīng)用到任何活動(dòng)、資源或產(chǎn)品中。軟件工程理論與實(shí)踐 When the process involves the building of some product, we sometimes refer to the process as a life cycle.當(dāng)過程涉及到某些產(chǎn)品的開發(fā)時(shí),有時(shí)把這種過程稱為生命周期 The software development process is sometimes called the software life cycle.軟件開發(fā)過程有時(shí)被稱為軟件生命周期 Life Cycle生命周期軟件工程理論與實(shí)踐 They impos
8、e consistency and structure on a set of activities.它使一組活動(dòng)有了一致性和結(jié)構(gòu) The process structure guides our actions by allowing us to examine, understand, control, and improve the activities that comprise the process.過程結(jié)構(gòu)用檢查、理解、控制和改善組成過程的活動(dòng)來指導(dǎo)我們的行為 Enabling us to capture our experiences and pass them along t
9、o others.過程的重要性還在于它能使我們獲得經(jīng)驗(yàn)并把它傳授給別人 Processes are important過程的重要性 軟件工程理論與實(shí)踐軟件過程是將用戶的需求轉(zhuǎn)化成有效的軟件解決方案的一系列活動(dòng)。過程具有一系列的性質(zhì):時(shí)間性、并發(fā)性、嵌套性和度量性等。許多軟件組織無法正確定義和控制這一過程,但這恰恰是組織改進(jìn)的關(guān)鍵。軟件過程軟件工程理論與實(shí)踐軟件過程軟件生命周期過程包括:早期:立項(xiàng)需求分析設(shè)計(jì)編碼測試交付維護(hù)退役現(xiàn)在又加入:質(zhì)量保證管理各種活動(dòng)環(huán)境基礎(chǔ)設(shè)施配置文檔管理軟件工程理論與實(shí)踐軟件生存期的階段劃分(根據(jù)國標(biāo)計(jì)算機(jī)軟件開發(fā)規(guī)范)(1)可行性研究與計(jì)劃(2)需求分析(3)總體
10、設(shè)計(jì)(4)詳細(xì)設(shè)計(jì)(5)實(shí)現(xiàn)(6)集成測試(7)確認(rèn)測試(8)使用和維護(hù)上游下游軟件工程理論與實(shí)踐軟件生命周期(Software Life Cycle)如同任何事物一樣,軟件也有一個(gè)孕育、誕生、成長、成熟、衰亡、演化的生存過程;為了用工程化方式有效地管理軟件的全過程,軟件的生存過程也可以劃分為好幾個(gè)階段,由此逐步形成“軟件生命周期”的概念;它是一個(gè)從用戶需求開始,經(jīng)過開發(fā)、交付使用,在使用中不斷增補(bǔ)修訂,直至讓位于新軟件的全過程;概括地說,軟件生命周期由軟件定義、軟件開發(fā)和運(yùn)行維護(hù)3個(gè)時(shí)期組成,每個(gè)時(shí)期又進(jìn)一步劃分成若干個(gè)階段。軟件工程理論與實(shí)踐軟件定義時(shí)期問題定義階段:界定問題的范圍,確切地
11、定義問題;可行性研究階段:研究問題的范圍,探索這個(gè)問題是否值得去解,是否有可行的解決辦法;需求分析階段:確定目標(biāo)系統(tǒng)必須具備哪些功能;另外,要估計(jì)完成該項(xiàng)工程所需要的資源和成本,制定工程進(jìn)度表。軟件工程理論與實(shí)踐軟件開發(fā)時(shí)期具體設(shè)計(jì)和實(shí)現(xiàn)在前一個(gè)時(shí)期定義的軟件??傮w設(shè)計(jì)階段:設(shè)計(jì)出實(shí)現(xiàn)目標(biāo)系統(tǒng)的幾種可能的方案,權(quán)衡利弊推薦一最佳方案,并制定實(shí)現(xiàn)最佳方案的詳細(xì)計(jì)劃,以及設(shè)計(jì)軟件的體系結(jié)構(gòu);詳細(xì)設(shè)計(jì)階段:設(shè)計(jì)出程序的詳細(xì)規(guī)格說明;編碼和單元測試階段:寫出正確的、容易理解、容易維護(hù)的程序模塊;綜合測試階段:通過各種類型的測試使軟件達(dá)到預(yù)定的要求。集成測試/驗(yàn)收測試/現(xiàn)場測試/平行運(yùn)行軟件工程理論與實(shí)
12、踐運(yùn)行維護(hù)(軟件維護(hù))時(shí)期維護(hù)階段的關(guān)鍵任務(wù)是:通過各種必要的維護(hù)活動(dòng)使軟件系統(tǒng)持久地滿足用戶的需要。通常的4種維護(hù)活動(dòng):改正性維護(hù):診斷和改正使用過程中發(fā)現(xiàn)的軟件錯(cuò)誤;適應(yīng)性維護(hù):修改軟件以適應(yīng)環(huán)境的變化;完善性維護(hù):根據(jù)用戶需要改進(jìn)或擴(kuò)充軟件使之更完善;預(yù)防性維護(hù):修改軟件從而為將來的維護(hù)活動(dòng)做好準(zhǔn)備。軟件工程理論與實(shí)踐新的國際標(biāo)準(zhǔn)定義的軟件生存過程(1995 ISO/IEC 12207)軟件生存期過程支持過程組織過程主要過程獲取過程供應(yīng)過程開發(fā)過程運(yùn)行過程維護(hù)過程文檔編制過程配置管理過程質(zhì)量保證過程驗(yàn)證過程確認(rèn)過程聯(lián)合評審過程審核過程問題解決過程管理過程基礎(chǔ)設(shè)施過程改進(jìn)過程培訓(xùn)過程 2.
13、2 software process modeling軟件過程模型 軟件工程理論與實(shí)踐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ā)應(yīng)遵循的步驟,有些描述了完成軟件開發(fā)的實(shí)際步驟。軟件工程理論與實(shí)踐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ā)中涉及到的活動(dòng)、資源和約束的共同理解。 Helps the development team find inconsistencies, redundancies, and omissions in the pr
15、ocess and in its constituent parts.有助于開發(fā)小組發(fā)現(xiàn)過程及其組織成分中的不一致、冗余和遺漏。 軟件工程理論與實(shí)踐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ā)的目標(biāo)(如
16、構(gòu)建高質(zhì)量軟件、早期發(fā)現(xiàn)錯(cuò)誤、滿足預(yù)算和開發(fā)進(jìn)度)。 Every process should be tailored for the special situation in which it will be used.根據(jù)每個(gè)過程將被使用的特殊情況對其進(jìn)行裁剪。 軟件工程理論與實(shí)踐Typical process models典型的過程模型 Waterfall model 瀑布模型Prototyping 原型化模型V-model V-模型Operational specification 操作說明模型Transformational model 變換模型Phased development:
17、 increments and iteration 增量和迭代模型Spiral model 螺旋模型軟件工程理論與實(shí)踐Waterfall model瀑布模型System DesignProgram DesignCodingUnit & Inte-gration TestingSystem TestingAcceptance TestingOperation & MaintenanceRequirements Analysis軟件工程理論與實(shí)踐Characters of Waterfall model瀑布模型的特性 One development stage should be complete
18、d before the next begins. Steps dont goes backward.一個(gè)階段必須在另一個(gè)開發(fā)階段開始之前完成,步驟不能返回。 軟件工程理論與實(shí)踐瀑布模型特點(diǎn)階段間具有順序性和依賴性必須等前一階段的工作完成之后,才能開始后一階段的工作前一階段的輸出文檔就是后一階段的輸入文檔推遲實(shí)現(xiàn)的觀點(diǎn)清楚地區(qū)分邏輯設(shè)計(jì)與物理設(shè)計(jì),盡可能推遲程序的物理實(shí)現(xiàn)軟件工程理論與實(shí)踐瀑布模型特點(diǎn)質(zhì)量保證的觀點(diǎn)每個(gè)階段都必須完成規(guī)定的文檔,沒有交出合格的文檔就是沒有完成該階段的任務(wù)。每個(gè)階段結(jié)束前都要對所完成的文檔進(jìn)行評審,以便盡早發(fā)現(xiàn)問題,改正錯(cuò)誤。軟件工程理論與實(shí)踐 Merits of
19、 Waterfall model瀑布模型的優(yōu)點(diǎn) Has been used to prescribe software development activities in a variety of contexts.已被用于在各種情況下規(guī)定軟件開發(fā)活動(dòng)。 Is very useful in helping developers lay out what they need to do.幫助開發(fā)人員明確需要做什么 軟件工程理論與實(shí)踐 Merits of Waterfall model瀑布模型的優(yōu)點(diǎn) 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. 更復(fù)雜的模型是它的修改。其他模型的基礎(chǔ) 軟件工程理論與實(shí)踐 Merits of Waterfall model瀑布模型的優(yōu)點(diǎn) 其他:可強(qiáng)迫開發(fā)人員采
21、用規(guī)范的方法(例如,結(jié)構(gòu)化技術(shù))嚴(yán)格地規(guī)定了每個(gè)階段必須提交的文檔要求每個(gè)階段交出的所有產(chǎn)品都必須經(jīng)過質(zhì)量保證小組的仔細(xì)驗(yàn)證 瀑布模型的成功在很大程度上是由于它基本上是一種文檔驅(qū)動(dòng)的模型軟件工程理論與實(shí)踐Shortage of Waterfall model瀑布模型的缺點(diǎn) The biggest problem with waterfall model is that it does not not reflect the way code is really developed 瀑布模型的最大問題就是它不能反映實(shí)際的代碼開發(fā)方式。軟件工程理論與實(shí)踐Software development p
22、rocess in reality實(shí)際的軟件開發(fā)過程Requirements Analysis需求分析System Design系統(tǒng)設(shè)計(jì)Program Design程序設(shè)計(jì)Program implementation執(zhí)行Unit Testing單元測試Integration Testing集成測試System Testing系統(tǒng)測試Delivery交付Maintenance維護(hù)軟件工程理論與實(shí)踐Shortage of Waterfall model瀑布模型的缺點(diǎn) The model imposes a project management structure on system develop
23、ment 這個(gè)模型給系統(tǒng)開發(fā)強(qiáng)加了一種項(xiàng)目管理結(jié)構(gòu).Fail to treat software as a problem-solving process. present a manufacturing view. 沒能把軟件看成是一個(gè)問題解決的過程,僅表達(dá)了一種制造觀點(diǎn)。The model tells us nothing about the typical back-and-forth activities that lead to creating a final product. 模型沒告訴我們開發(fā)最終產(chǎn)品所需的典型的不斷改進(jìn)的活動(dòng)。軟件工程理論與實(shí)踐要求用戶不經(jīng)過實(shí)踐就提出完整準(zhǔn)確
24、的需求,在許多情況下都是不切實(shí)際的僅僅通過寫在紙上的靜態(tài)的規(guī)格說明,很難全面正確地認(rèn)識(shí)動(dòng)態(tài)的軟件產(chǎn)品將本來非線性的軟件開發(fā)過程人為地加以線性化,不符合實(shí)際中的軟件開發(fā)情況軟件開發(fā)耗時(shí)長,可運(yùn)行版本要等到項(xiàng)目后期才能得到,一旦在后期發(fā)現(xiàn)錯(cuò)誤,付出的代價(jià)將是巨大的。 “由文檔驅(qū)動(dòng)”的這個(gè)事實(shí)也是瀑布模型的一個(gè)主要缺點(diǎn),這可能導(dǎo)致最終開發(fā)出的軟件產(chǎn)品不能真正滿足用戶的需要瀑布模型缺點(diǎn)軟件工程理論與實(shí)踐Enhance of Waterfall model加強(qiáng)的瀑布模型Validate確認(rèn)Verify驗(yàn)證Requirements AnalysisSystem DesignProgram DesignCo
25、dingUnit & Integration TestingSystem TestingAcceptance TestingOperation & MaintenancePrototyping原型化軟件工程理論與實(shí)踐Enhance of Waterfall model加強(qiáng)的瀑布模型 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)品,這個(gè)產(chǎn)品能使顧客和開發(fā)人員檢驗(yàn)所建議系統(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) 確認(rèn)保證系統(tǒng)實(shí)現(xiàn)
27、了所有的需求,這樣每個(gè)系統(tǒng)功能可以回溯到系統(tǒng)說明的一個(gè)特定需求上。Verification ensures that each function works correctly. (built it right) 驗(yàn)證確保每個(gè)功能正確運(yùn)作。軟件工程理論與實(shí)踐V-model V-模型Validate Requirements確認(rèn)需求Verify Design驗(yàn)證設(shè)計(jì)Requirements AnalysisOperation & MaintenanceAcceptance Testing驗(yàn)收測試System TestingSystem DesignUnit & Inte-gration Test
28、ingProgram DesignCoding軟件工程理論與實(shí)踐瀑布模型的變種,增加了測試活動(dòng)與分析和設(shè)計(jì)的關(guān)系強(qiáng)調(diào)測試活動(dòng)與分析和設(shè)計(jì)之間的關(guān)聯(lián):單元測試和集成測試校驗(yàn)程序設(shè)計(jì);系統(tǒng)測試校驗(yàn)(verify)系統(tǒng)設(shè)計(jì); 系統(tǒng)測試是軟件作為整個(gè)基于計(jì)算機(jī)系統(tǒng)的一個(gè)元素,與計(jì)算機(jī)硬件、外設(shè)、某些支持軟件,數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合在一起,在實(shí)際運(yùn)行環(huán)境下對計(jì)算機(jī)系統(tǒng)進(jìn)行一系列的測試。驗(yàn)收測試確認(rèn)(validate)需求;與瀑布模型關(guān)注文檔和工作產(chǎn)品不同,V模型的關(guān)注點(diǎn)是軟件開發(fā)各階段的活動(dòng)以及正確性,因此V模型是以活動(dòng)驅(qū)動(dòng)的。V-model V-模型軟件工程理論與實(shí)踐本質(zhì)是把瀑布模型中一些隱含的
29、迭代過程明確出來,使開發(fā)活動(dòng)和驗(yàn)證活動(dòng)的相關(guān)性更加明顯;V模型使抽象等級(jí)的概念也更明顯:所有從需求到實(shí)現(xiàn)部分的活動(dòng)關(guān)注的是建立更多的系統(tǒng)詳細(xì)表述,而所有從實(shí)現(xiàn)到交付運(yùn)行的活動(dòng)關(guān)注的是對系統(tǒng)的驗(yàn)證和確認(rèn)。和瀑布模型一樣,都是對軟件開發(fā)過程過份簡單、理想化的抽象,對需求變化的適應(yīng)性差。V模型的改良之處與存在的問題軟件工程理論與實(shí)踐Prototyping 原型化模型PROTOTYPEREQUIREMENTSPROTOTYPEDESIGNPROTOTYPESYSTEMTESTLIST OF REVISIONSLIST OF REVISIONS修改列表LIST OF REVISIONSrevise pr
30、ototype修改原型user/customerReview評審SYSTEMREQUIREMENTS(sometimes informal or incomplete有時(shí)是非正式或不完全)DELIVEREDSYSTEM交付軟件工程理論與實(shí)踐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.一個(gè)原型就是部分開發(fā)的產(chǎn)品,這個(gè)產(chǎn)品能使顧客和開發(fā)人員檢驗(yàn)所建議系統(tǒng)的某些方面,并且判斷它對最終產(chǎn)品是否適合。軟件工程理論與實(shí)踐由于要求能夠快速建立可供運(yùn)行的模型,原型不可能象最終產(chǎn)品一樣面面俱到;客戶:不可把原型當(dāng)作軟件的正式運(yùn)行版本;開發(fā)人員:同上。還必須牢記原型中沒有考慮質(zhì)量因素的部分;使用前要與用戶達(dá)成一致:原型只是模型而已。使用原型必須要注意的問題軟件工程理論與實(shí)踐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)軟件工程理論與實(shí)踐Transformational model 變換模型Compare with requirements;update and needed與需求進(jìn)行比較;必要時(shí)加以更新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軟件工程理論與實(shí)踐Using automated support, the transformational process applies a series of transformations to change a specification
34、into a deliverable system.利用自動(dòng)化工具的支持,變換過程使用一系列變換把需求變成一個(gè)可交付使用的系統(tǒng)(Balzer 1981) compiling 編譯 Sample transformation can include changing the data representations 改變數(shù)據(jù)表示 selecting algorithms 選擇算法 optimizing 優(yōu)化 軟件工程理論與實(shí)踐Phased development: increments and iteration 階段化開發(fā):增量和迭代模型Build Release 1構(gòu)建版本1Build Re
35、lease 2構(gòu)建版本2Build Release 3構(gòu)建版本3Use Release 1使用版本1Use Release 2使用版本2Use Release 3使用版本3TimeUsers用戶Developers開發(fā)人員Development Systems開發(fā)系統(tǒng)Production Systems產(chǎn)品系統(tǒng)軟件工程理論與實(shí)踐Incremental Development 增量開發(fā)Iterative Development 迭代開發(fā)軟件工程理論與實(shí)踐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ā)布時(shí)首先是定義一個(gè)小的、具有一定功能的子系統(tǒng),然后在每一個(gè)新的發(fā)布中增加新的功能 Incremental Development:增量開發(fā) delivers a full system at the very beginning and
37、the changes the functionality of each subsystem with new release.是在一開始就移交一個(gè)完整的系統(tǒng),然后在每一個(gè)新的發(fā)布版本中改變每一個(gè)子系統(tǒng)的功能。 Iterative development:迭代開發(fā) 軟件工程理論與實(shí)踐優(yōu)點(diǎn):Training can begin on an early release. 培訓(xùn)可以在早期的版本中開始 Market can be created early for functionality that has never before been offered. 可以為那些以前從未實(shí)現(xiàn)的功能提前開拓
38、市場 Frequent releases allow developers to fix unanticipated problems globally and quickly, as they are reported form the operational system.當(dāng)在使用的系統(tǒng)中有未預(yù)料的問題報(bào)告時(shí),在新版本中開發(fā)人員可以全面快速修正這些問題 The development team can focus on different areas of expertise with different releases. 開發(fā)小組可以把不同的發(fā)布版本針對不同的領(lǐng)域 軟件工程理論與實(shí)踐難
39、點(diǎn):在把每個(gè)新的增量構(gòu)件集成到現(xiàn)有軟件體系結(jié)構(gòu)中時(shí),必須不破壞原來已經(jīng)開發(fā)出的產(chǎn)品必須把軟件的體系結(jié)構(gòu)設(shè)計(jì)得便于按這種方式進(jìn)行擴(kuò)充,向現(xiàn)有產(chǎn)品中加入新構(gòu)件的過程必須簡單、方便,也就是說,軟件體系結(jié)構(gòu)必須是開放的軟件工程理論與實(shí)踐Spiral model螺旋模型Determine Goals、目標(biāo)Alternatives、方案Constraints限制Plan計(jì)劃Evaluate AlternativesAnd Risks方案和風(fēng)險(xiǎn)評估Develop And Test開發(fā)和測試軟件工程理論與實(shí)踐螺旋模型螺旋模型沿著螺線旋轉(zhuǎn),在四個(gè)象限上分別表達(dá)四個(gè)任務(wù)區(qū)域,即:制定計(jì)劃確定軟件目標(biāo),選定實(shí)施方案
40、,弄清項(xiàng)目開發(fā)的限制;風(fēng)險(xiǎn)分析分析所選方案,考慮如何識(shí)別和消除風(fēng)險(xiǎn);實(shí)施工程實(shí)施軟件開發(fā);客戶評估評價(jià)開發(fā)工作,提出修正建議,并計(jì)劃下一個(gè)階段的任務(wù);軟件工程理論與實(shí)踐從涉及到的風(fēng)險(xiǎn)角度看待軟件開發(fā)過程,把開發(fā)活動(dòng)和風(fēng)險(xiǎn)管理結(jié)合起來。螺旋模型的基本思想是,盡量降低風(fēng)險(xiǎn)。 理解這種模型的一個(gè)簡便方法,是把它看作在每個(gè)階段之前都增加了風(fēng)險(xiǎn)分析過程的快速原型模型軟件項(xiàng)目中的風(fēng)險(xiǎn):人員硬件設(shè)備項(xiàng)目的生存能力等螺旋模型軟件工程理論與實(shí)踐實(shí)質(zhì)上相當(dāng)于在瀑布模型的每個(gè)階段開始前引入風(fēng)險(xiǎn)分析,并由客戶對階段性產(chǎn)品做出評審,這對保證軟件產(chǎn)品質(zhì)量十分有利;由于引入風(fēng)險(xiǎn)分析等活動(dòng),測試活動(dòng)的確定性增強(qiáng)了;螺旋模型最
41、外層代表維護(hù),開發(fā)與維護(hù)采用同樣方式,使維護(hù)得到與開發(fā)同樣的重視。螺旋模型的優(yōu)點(diǎn)軟件工程理論與實(shí)踐主要適合內(nèi)部開發(fā),否則風(fēng)險(xiǎn)分析必須在簽訂合同前完成,或者爭取客戶的最大理解;只適合大型軟件項(xiàng)目的開發(fā),否則,每個(gè)階段的風(fēng)險(xiǎn)分析將占用很大一部分資源,增加成本;對開發(fā)人員的風(fēng)險(xiǎn)分析能力是極大的考驗(yàn),否則,模型將退化到瀑布模型,甚至更糟。螺旋模型的缺點(diǎn)軟件工程理論與實(shí)踐噴泉模型進(jìn)一步開發(fā)運(yùn)行狀態(tài)集成和測試階段編碼階段面向?qū)ο笤O(shè)計(jì)階段面向?qū)ο蠓治鲭A段需求階段維護(hù)期“噴泉”體現(xiàn)了面向?qū)ο筌浖_發(fā)過程迭代和無縫的特性軟件工程理論與實(shí)踐注意事項(xiàng) 為避免使用噴泉模型開發(fā)軟件時(shí)開發(fā)過程過于無序,應(yīng)該把一個(gè)線形過程
42、作為總目標(biāo)面向?qū)ο蠓缎捅旧硪蠼?jīng)常對開發(fā)活動(dòng)進(jìn)行迭代或求精噴泉模型軟件工程理論與實(shí)踐敏捷方法敏捷過程(2001/2敏捷軟件開發(fā)宣言 The Manifesto of the Agile Alliance )敏捷方法的價(jià)值觀個(gè)體和交互勝過過程和工具可以工作的軟件勝過面面俱到的文檔客戶合作勝過合同談判響應(yīng)變化勝過遵循計(jì)劃軟件工程理論與實(shí)踐敏捷過程的原則最優(yōu)先要做的是通過盡早的,持續(xù)的交付有價(jià)值的軟件來使客戶滿意即使到了開發(fā)的后期,也歡迎改變需求.敏捷過程利用變化來為客戶創(chuàng)造競爭優(yōu)勢經(jīng)常性地交付可以工作的軟件,交付的間隔可以從幾周到幾個(gè)月,交付的時(shí)間間隔越短越好在整個(gè)項(xiàng)目開發(fā)期間,業(yè)務(wù)人員和開發(fā)人員
43、必須天天都在一起工作圍繞被激勵(lì)起來的個(gè)人來構(gòu)件項(xiàng)目.給他們提供所需要的環(huán)境和支持,并且信任他們能夠完成工作軟件工程理論與實(shí)踐敏捷過程的原則 (續(xù))在團(tuán)隊(duì)內(nèi)部,最具有效果并且富有效率的傳遞信息的方法,就是面對面的交談工作的軟件是首要的進(jìn)度度量標(biāo)準(zhǔn)敏捷過程提倡可持續(xù)的開發(fā)速度.責(zé)任人、開發(fā)者和用戶應(yīng)該能夠保持一個(gè)長期的、恒定的開發(fā)速度不斷地關(guān)注優(yōu)秀的技能和好的設(shè)計(jì)會(huì)增強(qiáng)敏捷能力簡單是根本的最好的架構(gòu)、需求和設(shè)計(jì)出自于自組織的團(tuán)隊(duì)每隔一段時(shí)間,團(tuán)隊(duì)就會(huì)在如何才能更有效地工作方面進(jìn)行反省,然后相應(yīng)地對自己的行為進(jìn)行調(diào)整軟件工程理論與實(shí)踐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)敏捷過程軟件工程理論與實(shí)踐極限編程是敏捷過程中最富盛名的一個(gè),其中“極限”的含義是指把最好的開發(fā)實(shí)踐運(yùn)用到極致。目前極限編程已經(jīng)成為一個(gè)典型的開發(fā)方法,廣泛應(yīng)用于需求模糊且經(jīng)常改變的場合。特點(diǎn):對變化和不確定性反應(yīng)更快速,更敏捷快速的同時(shí)保持可持續(xù)的開發(fā)速度極限
46、編程(eXtreme Programming, XP)軟件工程理論與實(shí)踐客戶作為開發(fā)團(tuán)隊(duì)的成員使用用戶素材短交付周期(每兩周完成一次迭代)驗(yàn)收測試結(jié)對編程測試驅(qū)動(dòng)的開發(fā)集體所有(程序代碼屬于整個(gè)開發(fā)小組,每個(gè)成員都有修改代碼的權(quán)利,都對全部代碼負(fù)責(zé))極限編程的有效實(shí)踐軟件工程理論與實(shí)踐持續(xù)集成(一日內(nèi)多次集成,不斷回歸測試)可持續(xù)的開發(fā)速度(周工作時(shí)間不超過40小時(shí),連續(xù)加班不超過兩周)開放的工作空間及時(shí)調(diào)整計(jì)劃重構(gòu)使用隱喻(隱喻是把整個(gè)系統(tǒng)聯(lián)系在一起的全局視圖,描述系統(tǒng)如何運(yùn)做,如何把新功能加入到系統(tǒng)中)極限編程(eXtreme Programming, XP)軟件工程理論與實(shí)踐極限編程的整
47、體開發(fā)過程體系結(jié)構(gòu)試探制訂交付計(jì)劃難點(diǎn)試探驗(yàn)收測試迭代開發(fā)不確定的估計(jì)確定的估計(jì)隱喻交付計(jì)劃最新版本需求新用戶故事差錯(cuò)下一次迭代用戶認(rèn)可小交付測試用例用戶故事軟件工程理論與實(shí)踐極限編程的迭代過程制訂迭代計(jì)劃站立會(huì)議代碼共享編程驗(yàn)收測試交流與討論未完成的任務(wù)用戶故事交付計(jì)劃項(xiàng)目速率任務(wù)分配下一個(gè)任務(wù)或未通過驗(yàn)收的模塊測試用例差錯(cuò)用戶認(rèn)可小交付共享的信息新用戶故事新項(xiàng)目速率新功能最新版本結(jié)對編程與人員輪換;持續(xù)地優(yōu)化設(shè)計(jì);循環(huán)冗余檢測軟件工程理論與實(shí)踐2.3 Tools and Techniques for Process Modeling過程建模工具和技術(shù) 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ù)可供選擇。標(biāo)記符號(hào)的選擇依賴于你想在模型中獲取什么。符號(hào)可以是文本方式的,它把過程表達(dá)為函數(shù);也可以是圖形的,它把過程描述為正方形和箭頭組成的分層結(jié)構(gòu);也可以是圖形加文本組合的,它把圖形化的描述與表格和函數(shù)組合起
50、來,以詳細(xì)描述高層的說明。 軟件工程理論與實(shí)踐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.動(dòng)態(tài)模型能夠執(zhí)行過程,用戶能夠看到中間過程和最后的結(jié)果是如何
51、轉(zhuǎn)化的。軟件工程理論與實(shí)踐The elements of a process are viewed in terms of seven types:過程元素有以下7種類型:Activity 活動(dòng)Sequence 順序Process model 過程模型Resource 資源Control 控制Policy 策略O(shè)rganization 組織結(jié)構(gòu)Static Modeling: Lai Notation 靜態(tài)模型:Lai符號(hào)軟件工程理論與實(shí)踐Activity(活動(dòng)): 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. 此元素與幾個(gè)因素有關(guān):該活動(dòng)之前和之后發(fā)生的事情、所需資源、什么觸發(fā)了活動(dòng)、約束活動(dòng)的規(guī)則、如何描述算法
53、和經(jīng)驗(yàn),以及如何把活動(dòng)和項(xiàng)目小組聯(lián)系起來。軟件工程理論與實(shí)踐Sequence(順序): The order of activities. 活動(dòng)的順序。The sequence can be described using triggers, programming constructs, transformations, order, or satisfaction of conditions. 順序可以用觸發(fā)器、程序結(jié)構(gòu)、變換、排序或滿足的條件來描述。軟件工程理論與實(shí)踐Process model(過程模型): A view of interest about the system.關(guān)于系統(tǒng)興
54、趣的觀點(diǎn)。Parts of the process may be represented as a separate model, either to predict process behavior or to examine certain characteristics. 部分過程可以表示成分離的模型,用來預(yù)測過程行為或分析一定的特性。 軟件工程理論與實(shí)踐Resource(資源): A necessary item, tool, or person. 必需的事項(xiàng)、工具或人員。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è)備、時(shí)間、辦公空間、人員、技術(shù)等。過程模型確定每個(gè)活動(dòng)需要的各種資源的數(shù)量。軟件工程理論與實(shí)踐Control(控制): An external influence over process enactment.對執(zhí)行過程的外部影響。The controls may be manual or automatic, human or mechanical. 控制可以是手
56、動(dòng)或自動(dòng)的、人工或機(jī)械的。軟件工程理論與實(shí)踐Policy(策略): A guiding principle.指導(dǎo)原則。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í)行,它可能包含一個(gè)規(guī)定的開發(fā)過程、必須使用的工具或強(qiáng)制性的管理模式。 軟件工程理論與實(shí)踐Organizat
57、ion(組織結(jié)構(gòu)): The hierarchical structure of process agents, with physical grouping corresponding to logical grouping and related roles. 過程代理的等級(jí)結(jié)構(gòu),使實(shí)際分組和邏輯分組及相關(guān)角色相對應(yīng)。The mapping from physical to logical grouping should be flexible enough to reflect changes in physical environment. 從實(shí)際分組到邏輯分組的映射必須足夠靈活以反映
58、實(shí)際環(huán)境的變化。 軟件工程理論與實(shí)踐Lais notation includes several templates, such as Artifact Definition Template, which records information about particular artifacts.(P64) Lai符號(hào)包括若干模板,如工件定義模板,該模板記錄特定的工件信息。Other templates define relations, process states, operations, analysis, actions, and roles. 其他的模板定義了關(guān)系、過程狀態(tài)、操作
59、、分析、活動(dòng)和角色。Graphical diagrams represent the relationships between elements, capturing the main relationships and secondary ones.(P65) 圖形范式表示了元素之間的相互關(guān)系,以獲取主要的關(guān)系和次要的關(guān)系。 Transition diagrams supplement the process model by showing how the states are related to one another. (P66) 變換圖是對過程模型的補(bǔ)充,它展示了狀態(tài)彼此之間是如何聯(lián)系的。 軟件工程理論與實(shí)踐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. 我們希望給出過程的
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
- 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
- 5. 人人文庫網(wǎng)僅提供信息存儲(chǔ)空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
- 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 二零二五年度建筑工程質(zhì)量責(zé)任協(xié)議書
- 二零二五年度新型抵押物抵押借款合同范本
- 二零二五年度成都職業(yè)規(guī)劃咨詢居間合同
- 2025版人工智能技術(shù)研發(fā)合作擔(dān)保合同
- 2025至2030年中國流平儀行業(yè)市場深度分析及投資潛力預(yù)測報(bào)告
- 2025版白酒產(chǎn)品售后服務(wù)合作協(xié)議
- 2025版發(fā)動(dòng)機(jī)大修與動(dòng)力性能再生產(chǎn)服務(wù)合同
- 二零二五版城市景觀綠化工程招投標(biāo)合同及養(yǎng)護(hù)協(xié)議
- 二零二五年度姜云離婚協(xié)議書:財(cái)產(chǎn)分割與子女教育
- 二零二五年度家具租賃合同與服務(wù)協(xié)議
- 2025屆天津市八年級(jí)英語第二學(xué)期期末達(dá)標(biāo)測試試題含答案
- 2025年物流無人機(jī)市場調(diào)研報(bào)告
- 中暑的臨床表現(xiàn)和急救措施
- 黨校班主任班級(jí)管理制度
- 檢測類安全管理制度
- “十五五”住房和城鄉(xiāng)建設(shè)發(fā)展規(guī)劃
- 品管圈在提高住院患者口服藥規(guī)范服用率中的運(yùn)用
- 喉炎病人護(hù)理課件
- 通信質(zhì)量員試題及答案
- DB23-T2701-2020-森林撫育技術(shù)規(guī)程-黑龍江省
- T/GXSXFS 005-2021肉牛精料補(bǔ)充料
評論
0/150
提交評論