軟件的生命周期

軟件的生命周期第1頁，課件共15頁，創(chuàng)作于2023年2月?liqianmu@126.com22023/7/281、引言(1)什么是軟件工程定義1：軟件工程是指導(dǎo)計算機軟件開發(fā)和維護的工程學(xué)科。采用工程的概念、原理、技術(shù)和方法來開發(fā)與維護軟件，把經(jīng)過時間考驗而證明正確的管理技術(shù)和當(dāng)前能夠得到的最好的技術(shù)方法結(jié)合起來，這就是軟件工程。定義2：軟件工程是研究和應(yīng)用如何以系統(tǒng)性的、規(guī)范化的、可定量的方法去開發(fā)、操縱和維護軟件、即把工程應(yīng)用到軟件上。(2)什么是軟件生命期定義3：軟件生命期是指軟件產(chǎn)品從考慮其概念開始，到該軟件產(chǎn)品不再能使用為止的整個時期。一般包括概念階段、需求階段、設(shè)計階段、實現(xiàn)階段、測試階段、安裝階段以及交付使用階段、運行階段和維護階段。有時還有退役階段。這些階段可以有重復(fù)，執(zhí)行時也可以有迭代。

第2頁，課件共15頁，創(chuàng)作于2023年2月?liqianmu@126.com32023/7/28(3)什么是軟件開發(fā)生命期定義4：軟件開發(fā)生命期是指軟件產(chǎn)品從考慮其概念開始到該軟件產(chǎn)品交付使用使用為止的整個時期。一般包括概念階段、需求階段、設(shè)計階段、實現(xiàn)階段、測試階段、安裝階段，以及交付階段。這些階段可以有重疊，執(zhí)行時也可以有迭代。(4)什么是軟件開發(fā)過程定義5：把用戶的要求轉(zhuǎn)變成軟件產(chǎn)品的過程叫做軟件開發(fā)過程。此過程包括對用戶的要求進行分析，解釋成軟件需求，把需求變換成設(shè)計，把設(shè)計用代碼來實現(xiàn)，測試該代碼，有時還要進行代碼安裝和把軟件交付運行使用。注意：這些活動可以重疊，執(zhí)行時也可以有迭代。定義6：進行一組有組織的活動以把用戶的要求轉(zhuǎn)化成軟件產(chǎn)品。

第3頁，課件共15頁，創(chuàng)作于2023年2月?liqianmu@126.com42023/7/282、軟件開發(fā)模型的發(fā)展在整個軟件開發(fā)的發(fā)展過程中，為了要從宏觀上管理軟件的開發(fā)和維護，就必須對軟件的發(fā)展過程有總體的認識和描述，即要對軟件過程建模。幾十年來，軟件開發(fā)生命周期模型的的發(fā)展有了很大變化，提出了一系列的模型以適應(yīng)軟件開發(fā)發(fā)展的需要。在這里我們提出以下一些主要的軟件開發(fā)模型：1．編碼—修正模型(codeandfixmodel)第4頁，課件共15頁，創(chuàng)作于2023年2月?liqianmu@126.com52023/7/282、軟件開發(fā)模型的發(fā)展弊端：首先，代碼缺少統(tǒng)一規(guī)劃，低估了設(shè)計的重要性，使得代碼結(jié)構(gòu)隨著修改次數(shù)的增加變得越來越壞。以至錯誤越來越難改，甚至無法改。第二，即使有的軟件設(shè)計得很好，但往往其結(jié)果并非用戶所需要的。造成軟件開發(fā)的風(fēng)險非常大。這主要是因為沒有重視需求而造成的。第三，由于對測試、維護修改方面考慮不周，使得代碼的維護修改非常困難。所以，當(dāng)開發(fā)的軟件規(guī)模不斷擴大時，這種開發(fā)模型就會引起嚴重的后果，必須加以改進。第5頁，課件共15頁，創(chuàng)作于2023年2月?liqianmu@126.com62023/7/282、軟件開發(fā)模型的發(fā)展2．瀑布模型(waterfallmodel)由于吸取軟件開發(fā)早期的教訓(xùn)，人們開始將軟件開發(fā)視為工程來管理。類似其他工程的管理，軟件開發(fā)也具有一定的工序。于是，“軟件生命周期”這一概念真正被提了出來，并將軟件生命周期劃分成了：制定計劃、需求分析和定義、軟件設(shè)計、程序編寫、軟件測試、運行和維護這六個步驟。在這一基礎(chǔ)上，WinstonRoyce在1970年提出了著名的“瀑布模型”。瀑布模型規(guī)定了包括上述六個工程活動，并且規(guī)定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落，并試圖解決編碼—修正模型所帶來的問題。然而軟件開發(fā)的實踐表明，上述各項活動之間并非完全是自上而下，呈線性因式。實際情況中，每項開發(fā)活動大部分具有以下特點：

第6頁，課件共15頁，創(chuàng)作于2023年2月?liqianmu@126.com72023/7/282、軟件開發(fā)模型的發(fā)展(1)從上一項開發(fā)活動接受該項活動的工作對象，作為輸入。(2)利用這一輸入，實施該項活動應(yīng)完成的工作內(nèi)容。(3)給出該項活動的工作成果，作為輸出傳給下一項開發(fā)活動。(4)對該項活動的實施工作成果進行評審。若其工作成果得到確認，則繼續(xù)進行下一項開發(fā)活動，如下圖中的向下箭頭所表示；否則返回前一項，甚至更前項的活動。盡量減少多個階段間的反復(fù)。以相對來說較小的費用來開發(fā)軟件。

第7頁，課件共15頁，創(chuàng)作于2023年2月?liqianmu@126.com82023/7/282、軟件開發(fā)模型的發(fā)展第8頁，課件共15頁，創(chuàng)作于2023年2月?liqianmu@126.com92023/7/282、軟件開發(fā)模型的發(fā)展但是瀑布模型同樣存在一些問題：首先，階段和階段劃分完全固定，階段間產(chǎn)生大量的文檔，極大地增加了工作量。第二，由于開發(fā)模型呈線性，所以當(dāng)開發(fā)成果尚未經(jīng)過測試時，用戶無法看到軟件的效果。這樣，軟件與用戶見面的時間間隔較長，也增加了一定的風(fēng)險。第三，前面未發(fā)現(xiàn)的錯誤傳到后面的開發(fā)活動中時，可能會擴散，進而可能會造成更不理想的后果。為此，常常在需求階段或設(shè)計階段平行地進行幾次快速原型，來消除風(fēng)險和不確定性。該模型長期以來已成為美國政府或軍方的軟件項目的主要標準。但是瀑布模型的一些根本性缺陷推動著人們繼續(xù)探索新的模型。相當(dāng)一部分人認為應(yīng)考慮采用形式化方法的轉(zhuǎn)換模型以減少人為的錯誤。第9頁，課件共15頁，創(chuàng)作于2023年2月?liqianmu@126.com102023/7/282、軟件開發(fā)模型的發(fā)展3．轉(zhuǎn)換模型其主要思想是用形式化的方法自動生成程序。主要步驟為：(1)采用形式化的規(guī)格說明書。(2)通過自動系統(tǒng)自動地變換成代碼。(3)必要時做一些優(yōu)化，改進性能。(4)交付用戶使用。(5)根據(jù)使用的經(jīng)驗來調(diào)整形式化的規(guī)格說明書。返回(1)重復(fù)整個過程。轉(zhuǎn)換模型的優(yōu)點是解決了代碼結(jié)構(gòu)經(jīng)多次修改而變壞的問題；減少了許多中間步驟，如設(shè)計、編碼、測試等等。但是，轉(zhuǎn)換模型仍有較大局限，表現(xiàn)在：(1)自動轉(zhuǎn)換在實際上僅適用于規(guī)模很小產(chǎn)品；或某些非常特定領(lǐng)域的產(chǎn)品。(2)用戶容易無計劃地修改，是否能保證向正確、優(yōu)化及改進方向發(fā)展呢?(3)需要非常龐大的支持體系。特別考慮到當(dāng)前技術(shù)飛速發(fā)展的特點，這種進行自動轉(zhuǎn)換的系統(tǒng)中應(yīng)該包含和維護的知識數(shù)量呈爆炸性(商品化的軟件，硬件平臺知識)。第10頁，課件共15頁，創(chuàng)作于2023年2月?liqianmu@126.com112023/7/284．平行瀑布模型現(xiàn)在考慮對瀑布模型的進一步改進。對瀑布模型的各個階段之間轉(zhuǎn)換時，不一定要求完全按順序進行。而是可以適當(dāng)并行開展各階段的開發(fā)工作。在上一個階段尚未完全結(jié)束前，就可開設(shè)后一階段的開發(fā)工作。例如，在需求分析完成60％時，就可開始進行這60％的已完成分析部分的設(shè)計工作。同時并行進行余留的40％的需求分析。根據(jù)不同情況可有不同的并行度。例如：(1)用戶想法不穩(wěn)定，比方說，每天變換想法，要求不太清楚的話，則增加并行度。(2)短期顯示成果的壓力大，則可增加并行度。例如，在某種場合，在某些人的眼光中，按期完成70％的測試后的程序，比做完100％的設(shè)計，但無一行代碼的印象好得多。(3)如果可靠性要求高；要求各方面控制和配合很嚴格；資源及預(yù)算嚴密；技術(shù)錯誤的后果嚴重時，則需減少并行度。一般，對小系統(tǒng)關(guān)系不大，但對于大型系統(tǒng)的開發(fā)，則需根據(jù)實際情況認真分析考慮，難以用一個固定衡量標準。第11頁，課件共15頁，創(chuàng)作于2023年2月?liqianmu@126.com122023/7/285．演進式開發(fā)模型由于在項目開發(fā)的初期，人們對軟件需求的認識常常不夠清晰，因而使得在進行項目開發(fā)時，難于做到一次開發(fā)成功。出現(xiàn)返工，再一次開發(fā)常常在所難免。有人說，標只在于探索可行性，弄清軟件需求；第二次則在第一次開發(fā)的基礎(chǔ)上獲得較為滿意的軟件產(chǎn)品。通常把第一次得到的試驗性產(chǎn)品稱為“原型”。如果系統(tǒng)十分復(fù)雜，就可能要開發(fā)多次，每次只開發(fā)系統(tǒng)的一部分功能。每次在前一次的基礎(chǔ)上，進行改進并擴大性能、功能，直到達到要求。顯然，這種依靠演進方式進行開發(fā)的演化模型在克服瀑布模型的缺點，減少由于軟件需求不明確而給工作帶來風(fēng)險方面，確有顯著的效果。這種開發(fā)模型的問題是不要把演進式開發(fā)模型實際執(zhí)行成原始的編碼—修正模型。第12頁，課件共15頁，創(chuàng)作于2023年2月?liqianmu@126.com132023/7/286．螺旋模型70年代和80年代，硬件技術(shù)不斷提高，軟件系統(tǒng)也不斷龐大。而當(dāng)我們面對一個復(fù)雜的大型軟件系統(tǒng)時，用“瀑布模型”還是“演化模型”都難于有效地完成項目。于是，BarryBoehm在1988年正式發(fā)表了軟件系統(tǒng)開發(fā)的“螺旋模型”。螺旋模型將瀑布模型和演化模型等結(jié)合起來，并且強調(diào)了其他模型均忽略了的風(fēng)險分析。這種模型特別適用于龐大而復(fù)雜的系統(tǒng)、高風(fēng)險的系統(tǒng)。對于這些系統(tǒng)，風(fēng)險是軟件開發(fā)不可忽視的、潛在的不利因素。它可能在不同程度上損害軟件開發(fā)過程或軟件產(chǎn)品的質(zhì)量。減小軟件風(fēng)險的目標是在造成危害之前，及時對風(fēng)險進行識別、分析，決定采取何種對策，進而消除或減少風(fēng)險的損害。螺旋模型如圖所示。第13頁，課件共15頁，創(chuàng)作于2023年2月?liqianmu@126.com142023/7/28第14頁，課件共15頁，創(chuàng)作于2023年2月?liqianmu@126.com152023/7/28螺旋模型更適合于大型軟件的開發(fā)，應(yīng)該說它對于具有高度風(fēng)險的大型復(fù)雜軟件系統(tǒng)的開發(fā)是最為實際的方法。螺旋模型實際上是吸收和綜合了過去各種軟件開發(fā)模型。每種模型都可用特定情況的螺旋模型來表示