軟體方法如何影響項目的生命周期

⑴ 如何選擇軟體開發的生命周期

文本Tag：軟體開發 隨著用戶需求的多樣化，軟體系統開始越來越復雜了，而復雜性帶來的結果是軟體開發管理越來越困難。然而，許多軟體開發團隊卻沒有適時地改變其管理模式。因此，越來越多的軟體開發項目呈現出管理失控和混亂的跡象，軟體開發的整個生命周期已經越來越成為人們關注的焦點。 為什麼軟體開發項目的管理是這么困難呢？原因在於許多軟體開發團隊沒有選擇合適的管理工具。一般來說，在軟體開發過程中會有許多不確定的、經常變化的因素，如果在軟體開發過程中缺乏合適的管理工具，這將會導致開發人員無法統一開發行為和思路。例如，在實現項目的各階段和各種角色（架構師、項目經理、開發人員、測試人員等）的方法和思路並不一致，不但會對設計、質量、代碼管理和部署產生負面影響，而且還會導致開發成本增加。 那麼，我們應該怎樣管理好軟體開發的各種因素呢？就像教科書上經常所說的一樣，如果我們能夠很好的管理軟體生命周期每一個階段的質量，也就很好的管理了整個軟體開發的整個過程。因此，如何最大程度地管理好開發過程成為目前業界討論的焦點。本文介紹了在軟體開發過程中一種常用的管理工具：軟體生命周期模式，以及其概念和選擇方法。 軟體開發工作本身是需要一個周期來完成的，而在周期的內部則包含了很多因素。一個因素的不穩定，在周期推移的過程中都很可能會造成類似生物學領域的蝴蝶效應----非洲的一隻蝴蝶扇動翅膀可能會造成美洲大陸的一場龍卷風。這說明每一個事情都可能會對其它的事情產生連鎖反應。因此，任何軟體開發項目都必須進行適當的組織和管理，然後才能按預期計劃成功地執行項目。也說是說，規劃良好的軟體開發生命周期將能夠實現在更短的開發周期內構建軟體的願景。 同任何事物一樣,一個軟體產品或軟體系統也要經歷孕育、誕生、成長、成熟、衰亡等階段，這一般稱為軟體生命周期。軟體開發生命周期(SDLC)是指軟體開發的全部過程、活動和任務的結構框架。許多軟體開發工具廠商都提出過各種軟體生命周期方法論，它們有人將SDLC解釋為一組步驟或者里程標(Milestone)。但無論是誰的解釋，SDLC的一般步驟包括：確定問題、可行性分析與開發計劃、收集需求、分析與設計、編碼開發、測試、安裝、維護。 生命周期法也稱結構化系統開發方法，是目前國內外較流行的軟體系統開發方法。尤其在開發復雜的大系統時，顯示出無比的優越性。它的基本思想是：將軟體工程學和系統工程的理論和方法引入到軟體系統的開發中，按照用戶至上的原則，採用結構化、模塊化自頂向下對系統進行分析和設計。具體的說，是通過把整個軟體生命周期劃分為若干階段，使得每個階段有明確的任務，使規模大、結構復雜和管理復雜的軟體開發變的容易控制和管理。它的優點是強調系統開發過程的整體性和全局性，強調在整體優化的前提下考慮具體的分析設計問題，即自頂向下的觀點。它從時間角度把軟體開發和維護分解為若干階段，每個階段有各自相對獨立的任務和目標，從而降低了系統開發的復雜性，提高了可操作性。 （2）軟體生命周期模式 對於不同的軟體系統，可以採用不同的開發方法、以及運用不同的管理方法和手段。實際上，軟體生命周期法在開始的時候只是一個概念。因此，在應用軟體開發生命周期法時，許多開發團隊會把這一個概念進行工具化，這一個工具化就是軟體開發生命周期模式。通過軟體開發生命周期模式，我們能清晰、直觀地看到軟體開發的全過程。 在過去的10年中，軟體生命周期模式及其許多變體獲得了廣泛的認可。在各種軟體開發方法和過程改進模式中的技術革新也得到了承認，如Rational Unified Process(RUP)、Capability Maturity Model(CMM)、ISO 9000-3 等。典型的幾種生命周期模式包括：瀑布模式、演化模式、螺旋模式、快速原型模式、噴泉模式和混合模式等。在這里只介紹其中最常用的幾種模式： ①瀑布模式：它首先是由Royce提出，該模式由於酷似瀑布聞名。在該模式中首先確定需求，然後擬定規格說明，在通過驗證後方可進入計劃階段。因此，瀑布模式中至關重要的一點是只有當一個階段的文檔獲得認可才可以進入下一個階段。瀑布模式通過強制性規約來確保每個階段都能很好的完成任務，但是實際上卻往往難以辦到。因為整個瀑布模式幾乎都是以文檔驅動的，這對於非專業的用戶來說是難以閱讀和理解的。雖然瀑布模式有很多很好的思想可以借鑒，但是在過程能力上有天生的缺陷。內容導航 ②演化模式：它主要是針對事先不能完整定義需求的軟體開發。它的方法是用戶先給出待開發系統的核心需求，並且在核心需求實現後，再提出反饋以支持系統的最終設計和實現。也就是說：開發人員首先會根據用戶的需求開發核心系統，然後提供給用戶試用；用戶試用後再提出增強系統能力的需求；最後開發人員再根據用戶的反饋，實施迭代開發。實際上，這個模式可看作是重復執行的多個瀑布模式。演化模式要求開發人員把項目的產品需求分解為不同組，以便分批循環開發。但這種分組並不是隨意性的，而是要根據功能的重要性及對總體設計的基礎結構的影響而作出判斷。 ③螺旋模式：它是瀑布模式與演化模式相結合，並加入兩者所忽略的風險分析所建立的一種軟體開發模式。螺旋模式基本的做法是在瀑布模式的每一個開發階段之前，引入非常嚴格的風險識別、風險分析和風險控制。直到採取了消除風險的措施之後，才開始計劃下一階段的開發工作。否則，項目就很可能被暫停。另外，如果有充足的把握判斷遺留的風險已降低到一定的程度，項目管理人員還可作出決定讓餘下的開發工作採用另外的生命周期模式，如演化模式，瀑布模式或自定的混合模式。 ④過程開發模式：它又叫混合模式或元模式，是指把幾種不同模式組合成一種混合模式，它允許一個項目能沿著最有效的路徑發展。因為上述的模式中都有自己獨特的思想，現在的軟體開發團隊中很少說標準的採用那一種模式的，因為模式和實際應用還是有很大的區別的。實際上，許多軟體開發團隊都是在使用幾種不同的開發方法組成他們自己的混合模式。 最後，我們來總結一下。螺旋模式是典型的迭代式生命周期模式，而RUP則是近代迭代式生命周期的代表。與螺旋模式相比，RUP將風險管理放在更重要的地位。最新的迭代式生命周期模式的代表是模式驅動架構（MDA）和敏捷（Agile）軟體開發。MDA模式是基於可執行規格說明的思想，是現代轉換模式的代表，其核心技術是組件技術。而敏捷開發生命周期的典型代表是XP編程，是把傳統的系統設計和實現由敏捷軟體開發過程中的驗收測試、重構和測試驅動所取代；把傳統的集成和部署由敏捷軟體開發中的持續集成和短周期所取代。 其實上，無論是瀑布開發模式還是螺旋開發模式，軟體生命周期模式的發展實際上是體現了軟體工程理論的發展。在最早的時候，軟體的生命周期處於無序、混亂的情況。一些人為了能夠管理和控制軟體的開發過程，就把軟體開發嚴格的區分為多個不同的階段，並在階段間加上嚴格的審查，這就是軟體開發模式產生的起因。它們體現了人們對軟體過程的一個希望：嚴格控制、確保質量。 （1）評估軟體開發范圍和需求 當軟體所有參與人員都能理解軟體開發的范圍和需求時，就能為軟體開發可能遇到的突發事情和未來變化建立一個技術基線。這個技術基線、基礎規則和假設應該包含識別和評估軟體的功能性。一般來說，在前期需求明確的情況下可盡量採用瀑布模式或改進型的瀑布模式。而在不確定性因素很多時或很多需求無法計劃的情況下，應該盡量採用增量迭代模式或螺旋模式。 （2）確定軟體開發規模和階段劃分 確定軟體的開發規模是決定開發管理工具的重要一步，也是最為關鍵的步驟。因為確定開發規模和階段劃分是明確軟體開發生命周期的驅動動力，它可用來約束在開發過程中所採用的行動和資源，以及限制可以提供的選項。例如，對於規模小的建議採用瀑布模式；而在資金和成本無法一次到位情況下可以採用增量模式；而對於完全多個獨立功能的開發可以在需求階段就分功能並行,但每個功能內可以遵循瀑布模式原則；而其他項目一般可採用迭代模式。 （3）選擇合適的軟體開發生命周期模式 一個定義良好的軟體生命周期模式，可以很好的指導我們的開發工作，使漫長的開發工作易於控制。事實上，我們也可以任意定義自己喜歡的軟體生命周期模式。但是，如果生命周期模式定義不合理，卻會制約我們的開發過程。因此，選擇一個軟體開發模式不應當將其作為一次性的活動來考慮。因為隨著開發項目的進展，未知內容會逐漸變為已知內容，並且新的和意料之外的問題和風險都會隨之出現。所以，選擇開發模式應該要根據實際情況來進行，然後在此基礎上再加以裁減以作出適當的修改和改良。 （4）跟蹤和度量開發模式的效率 在軟體開發模式選定後，應該要定時跟蹤和度量開發模式的效率。例如，記錄那些相關的信息和得到的經驗教訓。通過這樣做的目的是為了記錄一個最佳開發模式的選擇過程，以獲得選擇開發模式的經驗性。因此，跟蹤信息應當被不斷的收集起來，並且同原始模式和基線進行比較。

⑵ 軟體的生命周期

軟體生命周期是指從軟體定義、開發、使用、維護到報廢為止的整個過程，一般包括問題定義、可行性分析、需求分析、總體設計、詳細設計、編碼、測試和維護。
問題定義就是確定開發任務到底「要解決的問題是什麼」，系統分析員通過對用戶的訪問調查，最後得出一份雙方都滿意的關於問題性質、工程目標和規模的書面報告。
可行性分析就是分析上一個階段所確定的問題到底「可行嗎」，系統分析員對系統要進行更進一步的分析，更准確、更具體地確定工程規模與目標，論證在經濟上和技術上是否可行，從而在理解工作范圍和代價的基礎上，做出軟體計劃。
需求分析即使對用戶要求進行具體分析，明確「目標系統要做什麼」，把用戶對軟體系統的全部要求以需求說明書的形式表達出來。
總體設計就是把軟體的功能轉化為所需要的體系結構，也就是決定系統的模塊結構，並給出模塊的相互調用關系、模塊間傳達的數據及每個模塊的功能說明。
詳細設計就是決定模塊內部的演算法與數據結構，也是明確「怎麼樣具體實現這個系統」。
編碼就是選取適合的程序設計語言對每個模板進行編碼，並進行模塊調試。
測試就是通過各種類型的測試使軟體達到預定的要求。
維護就是軟體交付給用戶使用後，對軟體不斷查錯、糾錯和修改，使系統持久地滿足用戶的需求。
軟體的生命周期也可以分為3個大的階段，分別是計劃階段、開發階段和維護階段。 瀑布模型
有時也稱為V模型，它是一種線型順序模型，是項目自始至終按照一定順序的步驟從需求分析進展到系統測試直到提交用戶使用，它提供了一種結構化的、自頂向下的軟體開發方法，每階段主要工作成果從一個階段傳遞到下一個階段，必須經過嚴格的評審或測試，以判定是否可以開始下一階段工作，各階段相互獨立、不重疊。瀑布模型是所有軟體生命周期模型的基礎。
原型+瀑布模型
原型模型本身是一個迭代的模型，是為了解決在產品開發的早期階段存在的不確定性、二義性和不完整性等問題，通過建立原型使開發者進一步確定其應開發的產品，使開發者的想像更具體化，也更易於被客戶所理解。原型只是真實系統的一部分或一個模型，完全可能不完成任何有用的事情，通常包括拋棄型和進化型兩種，拋棄型指原型建立、分析之後要扔掉，整個系統重新分析和設計；進化型則是對需求的定義較清楚的情形，原型建立之後要保留，作為系逐漸增加的基礎，採用進化型一定要重視軟體設計的系統性和完整性，並且在質量要求方面沒有捷徑，因此，對於描述相同的功能，建立進化型原型比建立拋棄型原型所花的時間要多。原型建立確認需求之後採用瀑布模型的方式完成項目開發。
增量模型
與建造大廈相同，軟體也是一步一步建造起來的。在增量模型中，軟體被作為一系列的增量構件來設計、實現、集成和測試，每一個構件是由多種相互作用的模塊所形成的提供特定功能的代碼片段構成。增量模型在各個階段並不交付一個可運行的完整產品，而是交付滿足客戶需求的一個子集的可運行產品。整個產品被分解成若干個構件，開發人員逐個構件地交付產品，這樣做的好處是軟體開發可以較好地適應變化，客戶可以不斷地看到所開發的軟體，從而降低開發風險。
一些大型系統往往需要很多年才能完成或者客戶急於實現系統，各子系統往往採用增量開發的模式，先實現核心的產品，即實現基本的需求，但很多補充的特性(其中一些是已知的，另外一些是未知的)在下一期發布。增量模型強調每一個增量均發布一個可操作產品，每個增量構建仍然遵循設計-編碼-測試的瀑布模型。
迭代模型
早在20世紀50年代末期，軟體領域中就出現了迭代模型。最早的迭代過程可能被描述為「分段模型」。迭代，包括產生產品發布（穩定、可執行的產品版本）的全部開發活動和要使用該發布必需的所有其他外圍元素。所以，在某種程度上，開發迭代是一次完整地經過所有工作流程的過程：（至少包括）需求工作流程、分析設計工作流程、實施工作流程和測試工作流程。
實質上，它類似小型的瀑布式項目。所有的階段（需求及其它）都可以細分為迭代。每一次的迭代都會產生一個可以發布的產品，這個產品是最終產品的一個子集。

⑶ 軟體生命周期，常說是三個時期八個階段，請問這三個時期的八個階段分別是什麼

軟體計劃與可行性研究階段、需求分析階段、軟體設計階段、軟體編碼階段、軟體測試階段和軟體運行與維護階段。

1、軟體計劃與可行性研究階段：此階段是軟體開發方與需求方共同討論，主要確定軟體的開發目標及其可行性。

2、需求分析階段：在確定軟體開發可行的情況下，對軟體需要實現的各個功能進行詳細分析。需求分析階段是一個很重要的階段，也是在整個軟體開發過程中不斷變化和深入的階段，能夠為整個軟體開發項目的成功打下良好的基礎。

軟體常見周期模型：

1、瀑布模型

瀑布模型首先由Royce提出。該模型由於酷似瀑布聞名。在該模型中，首先確定需求，並接受客戶和SQA小組的驗證。

然後擬定規格說明，同樣通過驗證後，進入計劃階段…可以看出，瀑布模型中至關重要的一點是只有當一個階段的文檔已經編制好並獲得SQA小組的認可才可以進入下一個階段。

2、迭代式模型

迭代式模型是RUP推薦的周期模型，也是我們在這個系列文章討論的基礎。在RUP中，迭代被定義為：迭代包括產生產品發布（穩定、可執行的產品版本）的全部開發活動和要使用該發布必需的所有其他外圍元素。

⑷ 描述軟體,軟體項目,軟體產品的生命周期以及三者的生命周期之間的關系 在線等

軟體生命周期(SDLC，Systems Development Life Cycle,SDLC)是軟體的產生直到報廢的生命周期

軟體項目的生命周期分為以下5種類型：
A: 編碼修正模型：未成型的系統規范－>不斷的編碼修正—>發布
¨ B: 漸進模型：最初概念－>設計和實施最初原型－>不斷的精化原型直到可以被接受（開發一個版本－>交付該版本－>得到用戶反饋－>並入用戶反饋）－>完成和交付最終版本
¨ C: 瀑布模型：軟體概念<－>需求分析<－>架構設計<－>詳細設計<－>編碼和調試<－>系統測試
¨ D: 螺旋模型：確定目標，備選方案，約束條件－>識別和解決風險－>評價備選方案－>計劃下一個迭代－>交付下一迭代解決方法－>確定目標，備選方案，約束條件
¨ E: 沒有模型， 完全根據實際情況進行調整

產品生命周期（proct life cycle），簡稱PLC，是產品的市場壽命，即一種新產品從開始進入市場到被市場淘汰的整個過程。

軟體生命周期包括軟體項目的生命周期和產品生命周期，

⑸ 軟體生命周期的周期模型

任何辦公的流程處理；設計一種商務信函列印系統並投放市場。這個概念是不清晰的，但卻是最高層的業務需求的原型。這個概念都會伴隨著一個目的，例如在一個銀行押匯系統 的目的是提高工作的效率。這個目的將會成為系統的核心思想，系統成敗的評判標准。99年政府部門上了大量的OA系統，學過一點Lotus Notes的人都發了財（IBM更不用說了），但是更普遍的情況是，許多的政府部門原有的處理模式並沒有變化，反而又加上了自動化處理的一套流程。提高工作效率的初衷卻導致了完全不同的結果。這樣的軟體究竟是不是成功的呢？
從概念提出的那一刻開始，軟體產品就進入了軟體生命周期。在經歷需求、分析、設計、實現、部署後，軟體將被使用並進入維護階段，直到最後由於缺少維護費用而逐漸消亡。這樣的一個過程，稱為生命周期模型（Life Cycle Model）。
典型的幾種生命周期模型包括瀑布模型、快速原型模型、迭代模型。 （Waterfall Model）首先由Royce提出。該模型由於酷似瀑布聞名。在該模型中，首先確定需求，並接受客戶和SQA小組的驗證。然後擬定規格說明，同樣通過驗證後，進入計劃階段…可以看出，瀑布模型中至關重要的一點是只有當一個階段的文檔已經編制好並獲得SQA小組的認可才可以進入下一個階段。這樣，瀑布模型通過強制性的要求提供規約文檔來確保每個階段都能很好的完成任務。但是實際上往往難以辦到，因為整個的模型幾乎都是以文檔驅動的，這對於非專業的用戶來說是難以閱讀和理解的。想像一下，你去買衣服的時候，售貨員給你出示的是一本厚厚的服裝規格說明，你會有什麼樣的感觸。雖然瀑布模型有很多很好的思想可以借鑒，但是在過程能力上有天生的缺陷。
然而輕易拋棄瀑布模型的觀點也是非常錯誤的，瀑布模型還是所有軟體開發模型的基礎，體現了軟體開發的本質過程。對於一些大型 的軟體項目，試圖過於簡化瀑布的前期的需求和設計階段，用一個簡單的原型或者迭代來模擬未來的系統，並試圖幫助確認和挖掘客戶的需求，是不可能的，不僅此時離客戶的最終需求和隔山萬千重，系統的架構也會隨著過程而有很大被拋棄和大幅調整的過程，原型也就起不到原型的作用，成本和時間反而浪費，所以前期的功課還是少不了的，尤其對於復雜系統。即使對於簡單如定製一件衣服，在給客戶提出修改的時候，它要基本是一件衣服，而不是幾塊布片，否則客戶無從提出進一步的需求，前期的功夫也是白費的。 迭代式模型是是RUP（Rational Unified Process，統一軟體開發過程，統一軟體過程)推薦的周期模型，也是我們在這個系列文章討論的基礎。在RUP中，迭代被定義為：迭代包括產生產品發布（穩定、可執行的產品版本）的全部開發活動和要使用該發布必需的所有其他外圍元素。所以，在某種程度上，開發迭代是一次完整地經過所有工作流程的過程：（至少包括）需求工作流程、分析設計工作流程、實施工作流程和測試工作流程。實質上，它類似小型的瀑布式項目。RUP認為，所有的階段（需求及其它）都可以細分為迭代。每一次的迭代都會產生一個可以發布的產品，這個產品是最終產品的一個子集。迭代的思想如圖所示。
迭代和瀑布的最大的差別就在於風險的暴露時間上。「任何項目都會涉及到一定的風險。如果能在生命周期中盡早確保避免了風險，那麼您的計劃自然會更趨精確。有許多風險直到已准備集成系統時才被發現。不管開發團隊經驗如何，都絕不可能預知所有的風險。」
由於瀑布模型的特點（文檔是主體），很多的問題在最後才會暴露出來，為了解決這些問題的風險是巨大的。在迭代式生命周期中，您需要根據主要風險列表選擇要在迭代中開發的新的增量內容。每次迭代完成時都會生成一個經過測試的可執行文件，這樣就可以核實是否已經降低了目標風險。 快速原型（Rapid Prototype）模型在功能上等價於產品的一個子集。注意，這里說的是功能上。瀑布模型的缺點就在於不夠直觀，快速原型法就解決了這個問題。一般來說，根據客戶的需要在很短的時間內解決用戶最迫切需要，完成一個可以演示的產品。這個產品只是實現部分的功能（最重要的）。它最重要的目的是為了確定用戶的真正需求。在我的經驗中，這種方法非常的有效，原先對計算機沒有絲毫概念的用戶在你的原型面前往往口若懸河，有些觀點讓你都覺得非常的吃驚。在得到用戶的需求之後，原型將被拋棄。因為原型開發的速度很快，設計方面是幾乎沒有考慮的，如果保留原型的話，在隨後的開發中會為此付出極大的代價。至於保留原型方面，也是有一種叫做增量模型是這么做的，但這種模型並不為大家所接受，不在我們的討論之內。 上述的模型中都有自己獨特的思想，其實現在的軟體組織中很少說標準的採用那一種模型的。模型和實用還是有很大的區別的。
軟體生命周期模型的發展實際上是體現了軟體工程理論的發展。在最早的時候，軟體的生命周期處於無序、混亂的情況。一些人為了能夠控制軟體的開發過程，就把軟體開發嚴格的區分為多個不同的階段，並在階段間加上嚴格的審查。這就是瀑布模型產生的起因。瀑布模型體現了人們對軟體過程的一個希望：嚴格控制、確保質量。可惜的是，現實往往是殘酷的。瀑布模型根本達不到這個過高的要求，因為軟體的過程往往難於預測。反而導致了其它的負面影響，例如大量的文檔、繁瑣的審批。因此人們就開始嘗試著用其它的方法來改進或替代瀑布方法。例如把過程細分來增加過程的可預測性。 1988年，Barry Boehm正式發表了軟體系統開發的螺旋模型，它將瀑布模型和快速原型模型結合起來，強調了其他模型所忽視的風險分析，特別適合於大型復雜的系統。
螺旋模型沿著螺線進行若干次迭代，圖中的四個象限代表了以下活動：
（1） 制定計劃：確定軟體目標，選定實施方案，弄清項目開發的限制條件；
（2） 風險分析：分析評估所選方案，考慮如何識別和消除風險；
（3） 實施工程：實施軟體開發和驗證；
（4） 客戶評估：評價開發工作，提出修正建議，制定下一步計劃。
螺旋模型由風險驅動，強調可選方案和約束條件從而支持軟體的重用，有助於將軟體質量作為特殊目標融入產品開發之中。但是，螺旋模型也有一定的限制條件，具體如下：
（1） 螺旋模型強調風險分析，但要求許多客戶接受和相信這種分析，並做出相關反應是不容易的，因此，這種模型往往適應於內部的大規模軟體開發。
（2） 如果執行風險分析將大大影響項目的利潤，那麼進行風險分析毫無意義，因此，螺旋模型只適合於大規模軟體項目。
（3） 軟體開發人員應該擅長尋找可能的風險，准確地分析風險，否則將會帶來更大的風險
一個階段首先是確定該階段的目標，完成這些目標的選擇方案及其約束條件，然後從風險角度分析方案的開發策略，努力排除各種潛在的風險，有時需要通過建造原型來完成。如果某些風險不能排除，該方案立即終止，否則啟動下一個開發步驟。最後，評價該階段的結果，並設計下一個階段。

⑹ 從軟體工程的三要素以及軟體生命周期各個方面來談談使用面向對象的方法如何進行軟體系統的開發與維護，並

摘要 軟體工程方法為軟體開發提供了「如何做」的技術。它包括了多方面的任務，如項目計劃與估算、軟體系統需求分析、數據結構、系統總體結構的設計、演算法過程的設計、編碼、測試以及維護等。

⑺ 什麼是軟體的生命周期軟體生命周期分哪幾個階段

軟體的生命周期是指軟體的產生直到報廢或停止使用的生命周期。

具體分為以下階段：

一、問題定義：要求系統分析員與用戶進行交流，弄清「用戶需要計算機解決什麼問題」然後提出關於「系統目標與范圍的說明」，提交用戶審查和確認。

二、可行性研究：一方面在於把待開發的系統的目標以明確的語言描述出來，另一方面從經濟、技術、法律等多方面進行可行性分析。

三、需求分析：弄清用戶對軟體系統的全部需求，編寫需求規格說明書和初步的用戶手冊，提交評審。

四、開發階段：開發階段由四個階段組成：

1、概要設計。

2、詳細設計。

3、實現：根據選定的程序設計語言完成源程序的編碼。

4、測試。

五、維護：維護包括四個方面：

1、改正性維護：在軟體交付使用後，由於開發測試時的不徹底、不完全、必然會有一部分隱藏的錯誤被帶到運行階段，這些隱藏的錯誤在某些特定的使用環境下就會暴露。

2、適應性維護：是為適應環境的變化而修改軟體的活動。

3、完善性維護：是根據用戶在使用過程中提出的一些建設性意見而進行的維護活動。

4、預防性維護：是為了進一步改善軟體系統的可維護性和可靠性，並為以後的改進奠定基礎。

⑻ 軟體開發的生命周期

同任何事物一樣,一個軟體產品或軟體系統也要經歷孕育、誕生、成長、成熟、衰亡等階段，一般稱為軟體生存周期（軟體生命周期）。把整個軟體生存周期劃分為若干階段，使得每個階段有明確的任務，使規模大，結構復雜和管理復雜的軟體開發變的容易控制和管理。通常，軟體生存周期包括可行性分析與開發項計劃、需求分析、設計（概要設計和詳細設計）、編碼、測試、維護等活動，可以將這些活動以適當的方式分配到不同的階段去完成。
軟體生命周期(SDLC，軟體生存周期)是軟體的產生直到報廢的生命周期，周期內有問題定義、可行性分析、總體描述、系統設計、編碼、調試和測試、驗收與運行、維護升級到廢棄等階段，這種按時間分程的思想方法是軟體工程中的一種思想原則，即按部就班、逐步推進，每個階段都要有定義、工作、審查、形成文檔以供交流或備查，以提高軟體的質量。但隨著新的面向對象的設計方法和技術的成熟，軟體生命周期設計方法的指導意義正在逐步減少。
軟體生命周期(SDLC)的六個階段
1、問題的定義及規劃
此階段是軟體開發方與需求方共同討論，主要確定軟體的開發目標及其可行性。
2、需求分析
在確定軟體開發可行的情況下，對軟體需要實現的各個功能進行詳細分析。需求分析階段是一個很重要的階段，這一階段做得好，將為整個軟體開發項目的成功打下良好的基礎。"唯一不變的是變化本身。"，同樣需求也是在整個軟體開發過程中不斷變化和深入的，因此我們必須制定需求變更計劃來應付這種變化，以保護整個項目的順利進行。
3、軟體設計
此階段主要根據需求分析的結果，對整個軟體系統進行設計，如系統框架設計，資料庫設計等等。軟體設計一般分為總體設計和詳細設計。好的軟體設計將為軟體程序編寫打下良好的基礎。
4、程序編碼
此階段是將軟體設計的結果轉換成計算機可運行的程序代碼。在程序編碼中必須要制定統一，符合標準的編寫規范。以保證程序的可讀性，易維護性，提高程序的運行效率。
5、軟體測試
在軟體設計完成後要經過嚴密的測試，以發現軟體在整個設計過程中存在的問題並加以糾正。整個測試過程分單元測試、組裝測試以及系統測試三個階段進行。測試的方法主要有白盒測試和黑盒測試兩種。在測試過程中需要建立詳細的測試計劃並嚴格按照測試計劃進行測試，以減少測試的隨意性。
6、運行維護
軟體維護是軟體生命周期中持續時間最長的階段。在軟體開發完成並投入使用後，由於多方面的原因，軟體不能繼續適應用戶的要求。要延續軟體的使用壽命，就必須對軟體進行維護。軟體的維護包括糾錯性維護和改進性維護兩個方面。

⑼ 軟體生命周期劃分成哪些階段

軟體計劃與可行性研究階段、需求分析階段、軟體設計階段、軟體編碼階段、軟體測試階段和軟體運行與維護階段。

1、軟體計劃與可行性研究階段：此階段是軟體開發方與需求方共同討論，主要確定軟體的開發目標及其可行性。

2、需求分析階段：在確定軟體開發可行的情況下，對軟體需要實現的各個功能進行詳細分析。需求分析階段是一個很重要的階段，也是在整個軟體開發過程中不斷變化和深入的階段，能夠為整個軟體開發項目的成功打下良好的基礎。

3、軟體設計階段（概要設計和詳細設計）：主要根據需求分析的結果，對整個軟體系統進行設計，如系統框架設計，資料庫設計等等。

4、軟體編碼階段：是將軟體設計的結果轉換成計算機可運行的程序代碼。在程序編碼中必須要制定統一，符合標準的編寫規范。以保證程序的可讀性，易維護性，提高程序的運行效率。

5、軟體測試階段：在軟體設計完成後要經過嚴密的測試，以發現軟體在整個設計過程中存在的問題並加以糾正。

6、軟體運行和維護階段：是軟體生命周期中持續時間最長的階段，包括糾錯性維護和改進性維護兩個方面。

(9)軟體方法如何影響項目的生命周期擴展閱讀

早期的軟體生命周期往往是說「軟體從計劃、需求開始，經歷分析設計、實現、部署、維護，直到最後逐漸消亡的」。

這是受到了第一個軟體生命周期模型---瀑布模型影響，上述語句實質上簡要的描述了瀑布型生命周期。

軟體生命周期不再只考慮瀑布型生命周期，另外常見的軟體生命周期模型有原型模型、螺旋模型、迭代模型。所以軟體生命周期說明應當不再包括瀑布型生命周期中的典型階段。

因此，對軟體生命周期及軟體生命周期模型採用如下定義：

1、軟體生命周期是指軟體的產生直到成熟的全部過程。

2、軟體生命周期模型是指人們為開發更好的軟體而歸納總結的軟體生命周期的典型實踐參考。