軟件模型之螺旋模型

《軟件模型之螺旋模型》由會員上傳分享，免費在線閱讀，更多相關內(nèi)容在行業(yè)資料-天天文庫。

1、螺旋模型SpiralModel簡介1988年，BarryBoehm正式發(fā)表了軟件系統(tǒng)開發(fā)的"螺旋模型"，它將瀑布模型和原型模型結(jié)合起來，強調(diào)了其他模型所忽視的風險分析，特別適合于大型復雜的系統(tǒng)。螺旋模型沿著螺線進行若干次迭代，圖中的四個象限代表了以下活動：（1）制定計劃：確定軟件目標，選定實施方案，弄清項目開發(fā)的限制條件；（2）風險分析：分析評估所選方案，考慮如何識別和消除風險；（3）實施工程：實施軟件開發(fā)和驗證；（4）客戶評估：評價開發(fā)工作，提出修正建議，制定下一步計劃。存在的問題螺旋模型由風險驅(qū)動，強調(diào)可選方案和

2、約束條件從而支持軟件的重用，有助于將軟件質(zhì)量作為特殊目標融入產(chǎn)品開發(fā)之中。但是，螺旋模型也有一定的限制條件，具體如下：（1）螺旋模型強調(diào)風險分析，但要求許多客戶接受和相信這種分析，并做出相關反應是不容易的，因此，這種模型往往適應于內(nèi)部的大規(guī)模軟件開發(fā)。（2）如果執(zhí)行風險分析將大大影響項目的利潤，那么進行風險分析毫無意義，因此，螺旋模型只適合于大規(guī)模軟件項目。（3）軟件開發(fā)人員應該擅長尋找可能的風險，準確地分析風險，否則將會帶來更大的風險一個階段首先是確定該階段的目標，完成這些目標的選擇方案及其約束條件，然后從風險角度

3、分析方案的開發(fā)策略，努力排除各種潛在的風險，有時需要通過建造原型來完成。如果某些風險不能排除，該方案立即終止，否則啟動下一個開發(fā)步驟。最后，評價該階段的結(jié)果，并設計下一個階段。各個階段的說明該模型是快速原型法，以進化的開發(fā)方式為中心，在每個項目階段使用瀑布模型法。這種模型的每一個周期都包括需求定義、風險分析、工程實現(xiàn)和評審4個階段，由這4個階段進行迭代。軟件開發(fā)過程每迭代一次，軟件開發(fā)又前進一個層次。螺旋模型基本做法是在“瀑布模型”的每一個開發(fā)階段前引入一個非常嚴格的風險識別、風險分析和風險控制，它把軟件項目分解成一

4、個個小項目。每個小項目都標識一個或多個主要風險，直到所有的主要風險因素都被確定。螺旋模型強調(diào)風險分析，使得開發(fā)人員和用戶對每個演化層出現(xiàn)的風險有所了解，繼而做出應有的反應，因此特別適用于龐大、復雜并具有高風險的系統(tǒng)。對于這些系統(tǒng)，風險是軟件開發(fā)不可忽視且潛在的不利因素，它可能在不同程度上損害軟件開發(fā)過程，影響軟件產(chǎn)品的質(zhì)量。減小軟件風險的目標是在造成危害之前，及時對風險進行識別及分析，決定采取何種對策，進而消除或減少風險的損害。螺旋模型的優(yōu)勢包括1）設計上的靈活性,可以在項目的各個階段進行變更。2）以小的分段來構(gòu)建大

5、型系統(tǒng),使成本計算變得簡單容易。3）客戶始終參與每個階段的開發(fā),保證了項目不偏離正確方向以及項目的可控性。4）隨著項目推進,客戶始終掌握項目的最新信息,從而他或她能夠和管理層有效地交互。5）客戶認可這種公司內(nèi)部的開發(fā)方式帶來的良好的溝通和高質(zhì)量的產(chǎn)品。經(jīng)常遇到的問題螺旋模型的解決方案用戶需求不夠充分允許并鼓勵用戶反饋信息溝通不明在項目早期就消除嚴重的曲解剛性的體系(Overwhelmingarchitectures)開發(fā)首先關注重要的業(yè)務和問題主觀臆斷通過測試和質(zhì)量保證,作出客觀的評估潛在的不一致在項目早期就發(fā)現(xiàn)不一

6、致問題糟糕的測試和質(zhì)量保證從第一次迭代就開始測試采用瀑布法開發(fā)在早期就找出并關注風險螺旋模型的缺陷1）采用螺旋模型需要具有相當豐富的風險評估經(jīng)驗和專門知識，在風險較大的項目開發(fā)中，如果未能夠及時標識風險，勢必造成重大損失。2）過多的迭代次數(shù)會增加開發(fā)成本，延遲提交時間?！奥菪Ｐ汀钡暮诵木驮谟谀恍枰趧傞_始的時候就把所有事情都定義的清清楚楚。您輕松上陣，定義最重要的功能，實現(xiàn)它，然后聽取客戶的意見，之后再進入到下一個階段。如此不斷輪回重復，直到得到您滿意的最終產(chǎn)品。每輪循環(huán)包含如下六個步驟：1.確定目標，可選項，以

7、及強制條件。2.識別并化解風險。3.評估可選項。4.開發(fā)并測試當前階段。5.規(guī)劃下一階段。6.確定進入下一階段的方法步驟。優(yōu)勢每個階段都有指定的起點和終點，過程最終可以被客戶和開發(fā)者識別（通過使用里程碑），在編寫第一行代碼之前充分強調(diào)了需求和設計，這避免了時間的浪費以及跳票的風險，同時還可以盡可能地保證實現(xiàn)客戶的預期需求。提取需求和設計提高了產(chǎn)品質(zhì)量，因為在設計階段捕獲并修正可能存在的漏洞要比測試階段容易很多，畢竟在組件集成之后來追蹤特定的錯誤要復雜很多。最后，因為前兩個階段生成了規(guī)范的說明書，當團隊成員分散在不同地

8、點的時候，瀑布模型可以幫助實現(xiàn)有效的知識傳遞。缺點通?？蛻粢婚_始并不知道他們需要的是什么，而是在整個項目進程中通過雙向交互不斷明確的；而瀑布模型是強調(diào)捕獲需求和設計的，但在這種情況下，現(xiàn)實世界的反復無償就顯得瀑布模型有些不切實際了。除此以外，即使給定了客戶需求，根據(jù)這些需求在一定的精確性范圍內(nèi)（瀑布模型所建議的）估算時間和成本是非常困難的。因此