軟體工程----生命週期模型
生命週期模型
1. 1 .瀑布模型
瀑布模型是一個經典的軟體生命週期模型,一般將軟體開發分為可行性分析(計劃)、需求分析、軟體設計(概要設計、詳細設計)、編碼(含單元測試)、測試、執行維護等幾個階段,如圖所示。
瀑布模型中每項開發活動具有以下特點:
(l )從上一項開發活動接受其成果作為本次活動的輸入。
( 2 )利用這一輸入,實施本次活動應完成的工作內容。
( 3 )給出本次活動的工作成果,作為輸出傳給下一項開發活動。
(4 )對本次活動的實施工作成果進行評審。
缺點: 過程基本不可迭代,需求在開始的不確定性,錯誤到最後才能發現,開發程式呈現塞阻狀態
瀑布型簡單地說就是按照需求、設計、編碼、測試、軟體維護這個基本的順序來研發軟體,前面一個步驟不完成,後面的步驟不能開始,否則問題會滾到下個階段,帶來更多的問題。瀑布型簡單地說就是按照需求、設計、編碼、測試、軟體維護這個基本的順序來研發軟體,前面一個步驟不完成,後面的步驟不能開始,否則問題會滾到下個階段,帶來更多的問題。
2 . V 模型
如圖所示
V 模型的左邊下降的是開發過程各階段,與此相對應的是右邊上升的部分,即各測試過程的各個階段。
V 模型的優點在於它非常明確地標明瞭測試過程中存在的不同級別,並且清楚地描述了這些測試階段和開發各階段的對應關係。
3 .原型化模型
原型化模型的第一步是建造一個快速原型,實現客戶或未來的使用者與系統的互動,經過和使用者針對原型的討論和交流,弄清需求以便真正把握使用者需要的軟體產品是什麼樣子的。充分了解後,再在原型基礎上開發出使用者滿意的產品。
如圖所示:原型嚴格來說不算一種軟體生命週期模型,它只是一種獲取需求的方法,在實際工作中該方法是相當重要的方法。
增量模型也是原型化開發方法。如圖所示
模型要點:瀑布和原型模型相結合,強調版本升級。
該模式的特點是一次性地獲取全部的需求,然後做出分版本實現各需求的計劃,每個版本只實現一部分需求,通過多個版本逐步實現全部需求,而每個版本可以認為是一個“小瀑布”。
該模型的好處是可以儘快讓系統上線,讓客戶先使用部分功能,儘早實現系統的價值。
該模型比較能符合實際的情況,我們往往也是通過多個版本來逐步實現全部需求,但需求是不可能在一開始就完全確定的,實際情況是往往只能確定80%,而後期通過各版本我們還會獲取更多的新需求以及需求調整。將此模型稍微調整後,可以適用於大部分的實際專案。
4.螺旋模型
螺旋模型是一個演化軟體過程模型,將原型實現的迭代特徵與線性順序(瀑布)模型中控制的和系統化的方面結合起來。使得軟體的增量版本的快速開發成為可能。在螺旋模型中,軟體開發是一系列的增量釋出。螺旋模型的整個開發過程如圖所示。
圖中的螺旋線代表隨著時間推進的工作進展;開發過程具有周期性重複的螺旋線形狀。4個象限分別標誌每個週期所劃分的4 個階段:制定計劃、風險分析、實施工程和客戶評估。螺旋模型要點:統一了瀑布模型與原型模型,與增量模型相似,更強調風險分析。
1.軟體分多個版本開發,每個版本就是一次螺旋。
2.每個版本按照這樣的順序進行:
1)確定軟體目標,選取定實施方案,弄清專案開發的限制條件;(圖中左上象限)
2)分析所選取方案,考慮如何識別和消除風險;(圖中右上象限)
3)實施軟體開發;(圖中右下象限)
4)評價開發工作,提出修正建議,調整計劃。(圖中右下象限、左下象限)
3.需求不是一次獲取和實現的,通過多個螺旋來完善。
4.計劃也不是一次成型的,每次螺旋都需要調整。
該模型在實際工作中實用性還是相當高的,但可能是該模式很多資料都說得不太清楚,讓很多人會有一些誤解。
5 .迭代模型
噴泉模型:體現認識事物的迴圈迭代性,強調開發活動之間的無間隙性,無明顯的活動階段劃分,適用於物件導向的開發過程。如圖所示:
RUP (Rational Unified Process )軟體統一過程是一種“過程方法”,它就是迭代模型的一種。如圖所示。
RUP中的軟體生命週期在時間上被分解為4 個順序的階段,分別是:初始階段( Inception)、細化階段(Elaboration )、構建階段(Construction )和交付階段(Transition )。這4 個階段的順序執行就形成了一個週期。每個階段結束於一個主要的里程碑(MajorMileslones )。在每個階段的結尾執行一次評估以確定這個階段的目標是否己經滿足。
前面提到增量、進化、螺旋的共同特點是多個版本,而每個版本可以認為是一個“小瀑布”,對於每個版本,我們可以認為還是要先完成前一步才能做下一步。而RUP認為專案中的工作可以分成好幾類,而每一類工作在整個專案週期都是持續進行的,只是不同工作在專案的不同時期比重不太一樣.
按照時間順序,專案分為初始(inception)、細化(Elaboration)、構造(Construction)、交付(Transition)四個階段,
每個階段會有很多個小迭代。這四個階段其實很難說有明顯界限的,我覺得大家大概瞭解每個階段的工作內容就可以了。
按照工作的性質,專案的工作可以分為以下幾類:
商業建模(BusinessModeling)
需求(Requirements)
分析和設計(Analysis& Design)
實現(Implementation)
測試(Test)
部署(Deployment)
配置管理與變更管理(Configuration& Change Mgmt)
專案管理(ProjectManagement)
環境(Environment)
以上這些工作,在專案的不同時期工作量分佈是不太一樣的,如:商業建模、需求這些工作往往是頭大尾小,分析與設計、實現等是中間大兩頭小,專案管理、環境方面的工作一直都會持續進行。
RUP的思想打破了“需求-設計-編碼-測試”這樣的傳統瀑布模式,需求、設計、編碼、測試這些工作其實一直都在進行的,只是不同時間比重不一樣。這個思想是很符合“敏捷”的特點,也和實際情況非常吻合。
http://www.360doc.com/content/12/0117/17/8115939_180031753.shtml
相關文章
- 軟體工程生命週期軟體工程
- 【2】軟體生命週期
- 軟體測試--軟體生命週期
- 軟體測試生命週期
- 開發方法---軟體生命週期
- 軟體測試---BUG的生命週期
- 一圖總結:軟體測試原則|策略|模型|生命週期模型
- 安全軟體開發生命週期簡介
- 軟體開發的生命週期過程
- Django元件---Django請求生命週期和中介軟體Django元件
- 生命週期
- 簡單的介紹 Eloquent 模型生命週期模型
- View生命週期與Activity生命週期的關係View
- 軟體工程-軟體工程層狀模型(EHM)軟體工程模型
- vue - 生命週期Vue
- Fragment生命週期Fragment
- vue生命週期Vue
- spring生命週期Spring
- ubuntu生命週期Ubuntu
- Flutter - 生命週期Flutter
- sessionStorag 生命週期Session
- PHP 生命週期PHP
- maven生命週期Maven
- Activity生命週期
- React生命週期React
- Salesforce 生命週期管理(一)應用生命週期淺談Salesforce
- vue 生命週期梳理Vue
- java servlet 生命週期JavaServlet
- Android Activity生命週期Android
- Activity生命週期onDestroy
- React-生命週期React
- IOC與生命週期
- vue 生命週期深入Vue
- React元件生命週期React元件
- JPA概述、生命週期
- viewController的生命週期ViewController
- Servlet的生命週期Servlet
- Tomcat生命週期管理Tomcat
- React 元件生命週期React元件