計劃軟體如何看周期

⑴ 軟體的生命周期是什麼

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

具體分為以下階段：

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

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

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

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

1、概要設計。

2、詳細設計。

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

4、測試。

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

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

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

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

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

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

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

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

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

軟體常見周期模型：

1、瀑布模型

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

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

2、迭代式模型

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

⑶ .軟體生命周期分為哪幾個階段簡要說明各階段的主要任務

軟體生命周期分為問題定義、可行性研究、需求分析、開發階段、維護這5個階段。各個階段的主要任務是如下。

1、問題定義

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

2、可行性研究

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

3、需求分析

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

4、開發階段

開發階段由四個階段組成：概要設計、詳細設計、實現、測試

五、維護

維護包括四個方面：

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

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

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

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

(3)計劃軟體如何看周期擴展閱讀：

軟體常見周期模型：

1、瀑布模型

瀑布模型首先由Royce提出。該模型由於酷似瀑布聞名。在該模型中，首先確定需求，並接受客戶和SQA小組的驗證。然後擬定規格說明，同樣通過驗證後，進入計劃階段…可以看出，瀑布模型中至關重要的一點是只有當一個階段的文檔已經編制好並獲得SQA小組的認可才可以進入下一個階段。

瀑布模型通過強制性的要求提供規約文檔來確保每個階段都能很好的完成任務。但是實際上往往難以辦到，因為整個的模型幾乎都是以文檔驅動的，這對於非專業的用戶來說是難以閱讀和理解的。

2、迭代式模型

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

所以，在某種程度上，開發迭代是一次完整地經過所有工作流程的過程：（至少包括）需求工作流程、分析設計工作流程、實施工作流程和測試工作流程。實質上，它類似小型的瀑布式項目。RUP認為，所有的階段（需求及其它）都可以細分為迭代。

3、快速原型模型

快速原型模型在功能上等價於產品的一個子集。瀑布模型的缺點就在於不夠直觀，快速原型法就解決了這個問題。一般來說，根據客戶的需要在很短的時間內解決用戶最迫切需要，完成一個可以演示的產品。這個產品只是實現部分的功能（最重要的）。

它最重要的目的是為了確定用戶的真正需求。在我的經驗中，這種方法非常的有效，原先對計算機沒有絲毫概念的用戶在你的原型面前往往口若懸河，有些觀點讓你都覺得非常的吃驚。在得到用戶的需求之後，原型將被拋棄。

因為原型開發的速度很快，設計方面是幾乎沒有考慮的，如果保留原型的話，在隨後的開發中會為此付出極大的代價。至於保留原型方面，也是有一種叫做增量模型是這么做的，但這種模型並不為大家所接受的。

⑷ 軟體生命周期

一般軟體的生命周期（開發）：
1、需求獲取；
竟可能詳細的獲取需求，也就是客戶需要做哪些事情，哪些想用軟體實現，對每個關鍵點的細節越詳細越好；
需要獲取不可能一次獲取的；在與客戶交流前要制定相應的計劃，這次要獲取哪些需求，哪些優先順序高，哪些一定要搞清楚，哪些可以放到後面再細化.......；在多次獲取需求後，要對需求整理，分類，文檔要盡可能標准一些，詳細記錄好各種需求變化，對一些模糊點也要註明，為後期的需求管理打好基礎；

2、需求分析；
需求分析就是要將前面獲取的需求信息，盡可能的轉化為技術需求，是對前面獲取到得需要一個整理過濾和重新劃分與定義的過程；相應文檔要非常清晰，明了，不要採用模糊的語言；同時要做好後期需求修改的維護准備，需求維護對整個項目的進度、質量都有很大關系，要非常重視；

3、設計；
1）架構設計；
2）資料庫設計；
3）功能細化；
4）詳細設計；
文檔要盡可能的標准（框架結構圖、數據流圖、各功能模塊流程圖、......）；

4、開發；
1）編碼；
2）UT測試；

5、測試；
主要是集成測試和系統測試；
很重要，是保證產品質量的重要環節（基礎是前面幾個環節不能太糟糕）；

6、上線及維護；
試運行；（對出現的問題修改，再使運行，反復多次後才可正式發布，有些人將這個環節歸為測試中，也是可以的，側重點不一樣；）
正式交付使用，之後進入後期的維護期；

上面是個人實戰經驗的總結，希望能提供幫助！！！

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

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

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

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

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

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

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

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

(5)計劃軟體如何看周期擴展閱讀

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

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

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

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

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

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

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

文本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）跟蹤和度量開發模式的效率 在軟體開發模式選定後，應該要定時跟蹤和度量開發模式的效率。例如，記錄那些相關的信息和得到的經驗教訓。通過這樣做的目的是為了記錄一個最佳開發模式的選擇過程，以獲得選擇開發模式的經驗性。因此，跟蹤信息應當被不斷的收集起來，並且同原始模式和基線進行比較。

⑺ 怎樣估算軟體項目周期

項目是指以一定的成本在一定時間內取得預期收益的系列活動。項目的生命期是管理項目的重要指標，而對項目周期的估算則是管理項目的重要一環。本期項目管理介紹對軟體項目周期進行估算的技巧。
估算是軟體開發中很重要的一個環節：項目周期估算過短會造成人力低估、成本預算低估、日程安排過短，最終人力資源耗盡，成本超出預算，為完成項目不得不 趕工，影響項目質量，甚至導致項目失敗；項目周期估計過長表面看來影響不大，但是實際上也會帶來成本估計過高、充分效率低下的後果。周期估算如同蓋樓房中 打地基，是後續工作的基礎，它的影響會貫穿整個項目。
但軟體開發是一項非常復雜的工程，不僅包含需求分析、設計、編碼、測試、實施、維護等不同的子過程，還涉及到開發工具、開發人員、項目管理、風險等眾多因素，不同因素對估算產生的影響不盡相同。在進行軟體估算時（包括利用工具輔助估算）必須考慮到這些方面，否則估算結果就會和實際結果有很大的偏差。下面，我們對幾個常見的因素做一些探討。
軟體規模是項目估算的基礎
軟體規模通常指的是軟體的大小，可以通過程序代碼行的長度、功能函數的數量、資料庫中表的數量、資料庫的大小等要素來描述軟體規模。一般而言，軟體規模越大，所花費的開發周期就越長。但這並不是一個簡單的線性函數關系，也要考慮代碼重用問題。比如一個模塊代碼很長，但是可能包含了很多公用函數，那麼在估算時就應適當減少代碼行數量。
軟體項目中包含的功能模塊越多、越復雜（或者說軟體越大），開發周期越長。這個時間絕不是模塊開發時間的簡單疊加，因為模塊功能數量的增加直接帶來了軟 件模塊間相互關聯度、復雜度的成倍增加，這導致了在需求、設計等階段需要花費更多的時間，比單獨考慮一個模塊復雜得多。另一方面，對於產品化程度高的項目 開發，隨著模塊數量增加，開發周期的增加卻不是特別明顯。這是因為相當數量的模塊可以完全重用，實際開發量大大減少。
所以，在實際進行軟體開發周期估算的時候，軟體規模肯定是首先考慮的因素。具體估算時，在考慮軟體規模時要去除可重用的部分。另外，軟體功能之間的關聯所造成的復雜性也必須足夠重視。
風險影響周期
任何一個項目都或多或少存在風險，軟體項目開發過程中也避免不了這種情況而且有自己的特點。最常見的風險來自於：技術、客戶、項目人員等方面。開發周期估算時項目風險應該適當考慮，尤其是技術風險和客戶風險技術風險技 術風險主要來自於軟體本身的技術難度。對於一套成熟的產品，定製開發的技術風險相對非常小，因為重要的技術已經成型，客戶也很少有新的、能帶來高難度技術 問題的需求，這種風險較小。但是對於完全重新開發的項目，或是研發類的項目，技術風險必須特別重視。以開發平台為例，開發平台必須適合本項目所涉及的軟體 開發、滿足最終的需求，平台的錯誤選擇將導致龐大的開發工作量，即便滿足了用戶需求也可能造成系統效率低下、擴展性差的致命問題，軟體可能會很快被淘汰。
在實際估算中，建議將技術難度分為十級，每一級在初次估算的代碼行上增加10%，
最終估算代碼長度=初始估算代碼長度×(1+0.1×n)
假設模塊A的初次估計代碼行為15000行，但考慮技術難度高的風險，設定技術難度級別為二級，最終代碼行的估算數量為15000×(1+20%)=18000。
由於技術風險的分析是一項技術性很強的工作，要求做技術風險分析的人必須是技術專家，在相關技術領域有著豐富的經驗。對重大技術風險的分析結果必須要經過評審，保證准確性。
客戶風險客戶風險存在於客戶化項目中，客戶行業特點不盡相同，技術、理解水平也相差甚遠。在我經歷開發的項目中，80%的項目延期是由於客戶方的原因，而且這種風險可控性很低，對項目影響超過技術風險。
在開發周期估算前，項目經理要仔細分析客戶的具體狀況，包括客戶方的計算機水平、管理水平、可溝通程度，在此基礎上結合以往的經驗綜合判斷是否會對開發 帶來明顯的影響，可以按照上述的技術風險的方式將客戶分級，最終確定開發周期。在這個過程中，項目經理的經驗極其重要，對客戶的分析基本上要依賴經驗做判 斷，要求管理人員有大量的客戶經驗和行業分析能力。
項目團隊影響速度
對於軟體開發項目來說，人力資源是核心力量。人力資源對估算的影響表現在技術水平、理解能力、溝通能力等幾個方面。項目技術人員編程水 平、工作效率、團隊適應性、溝通能力等素質，都會對開發進度產生影響，其中技術水平是最關鍵的因素。評價程序員的技術水平可以從編程熟練程度、編程速度、 解決技術問題的能力等幾個因素考慮：編程熟練程度指的是程序員使用編程工具實現軟體的功能的熟悉程度；編程速度指的是完成某個功能的速度；解決技術問題的 能力可以反映程序員的技術功底如果以100%作為總和，這三個因素分別占的合適比例為70%、15%和15%。
軟體開發周期估算前，應對開發人員定級，建議按新手、初級程序員、中級程序員、高級程序員來劃分，每一級人員再評定上述三個因素。初次估算時可以假定開發人員為中級程序員，然後依據項目組實際人員的水平做修正，這樣結果的准確度能大大提高。
寶貴的經驗依據歷史數據估算軟體開發周期是一種比較常見的方法，這種方法以歷史軟體開發周期為依據，在估算時把當前軟體項目的情況與歷史數據加以對比，從而得出最終結果。
按照歷史數據估算開發周期的准確度還是相當高的，但這種方法只適用於對某類軟體的開發，比如某個行業業務系統的開發。當要估算的軟體與歷史軟體相差太 多，比如開發工具完全不同、或者項目類型完全不同，就不能再依賴這種方法，最起碼應該輔助使用其它估演算法。如果沒有歷史數據或是開發一種新領域軟體，可以 使用代碼行或功能點估演算法，在此基礎上再通過其它方法校正。
在實際使用歷史數據估演算法時，建議項目經理建立一個歷史項目資料庫。在庫中 包含以前所有項目的開發周期、項目規模、開發人員狀況、客戶狀況等詳細數據。當估算時根據當前項目的狀況在庫中尋找最類似的歷史項目，然後再比較兩個項目 之間在項目規模、項目風險、人力資源之間的區別，我們假定歷史項目開發周期為A，當前項目的周期可以依據下列公式得出：
估算項目周期 = A×(2×S+R+P+2×C)/6
S：代表軟體規模 R：代表風險 P：代表人力資源 C：代表客戶
（以上值均指當前項目與歷史項目的比率）
實際的比較因素應該不止這些，但軟體規模、風險、人力資源及客戶狀況是其中最重要的，對軟體開發的影響也最大，所以這個公式中只考慮了這些因素。其中軟體規模和客戶兩項占的權重最大，這也是根據項目管理經驗得出的，在實際使用歷史數據估演算法時還可以靈活加入其它因素

⑻ 軟體的生命周期

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

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

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

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

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

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

⑽ 什麼是軟體周期

一個軟體從開始計劃起，到廢棄不用止，稱為軟體生存周期。一般來說，軟體生存周包括計劃、開發、運行三個時期，每一時期又可分為若干更小的階段。計劃時期的主要任務是分析用戶要求，分析新系統的主要目標以及開發該系統的可行性。開發時期要完成設計和實現兩大任務具體。具體分為需求分析、概要設計、詳細設計、編碼、測試。其中編碼和測試是軟體開發期的最後兩個階段。運行時期是軟體生存周期的最後一個時期，軟體人員在這一時期的工作，主要是做好軟體維護。