軟件生命週期
軟件生命週期，又稱爲 軟件生存週期 或 系統開發生命週期，是軟件的產生直到報廢的生命週期，週期內有以下八個階段：
- 問題定義
- 可行性研究
- 需求分析
- 概要設計（總體設計）
- 詳細設計
- 編碼與單元測試
- 綜合測試
- 軟件維護
這種按時間分程的思想方法是軟件工程中的一種思想原則，即按部就班、逐步推進，每個階段都要有定義、工作、審查、形成文檔以供交流或備查，以提高軟件的質量。
產品生命週期
產品生命週期，又稱 商品生命週期。是指產品從準備進入市場開始到被淘汰退出市場爲止的全部運動過程，是由需求與技術的生產週期所決定。是產品或商品在市場運動中的經濟壽命，也即在市場流通過程中，由於消費者的需求變化以及影響市場的其他因素所造成的商品由盛轉衰的週期。主要是由消費者的消費方式、消費水平、消費結構和消費心理的變化所決定的。一般分爲導入期、成長期、成熟期、衰退期四個階段。
軟件開發模式
瀑布模型
瀑布模型 是最典型的預見性的方法，嚴格遵循預先計劃的需求分析、設計、編碼、測試的步驟順序進行。步驟成果 作爲衡量進度的方法，例如需求規格，設計文檔，測試計劃和代碼審閱等等。
瀑布模型的主要問題：它的嚴格分級導致的自由度降低，項目早期即作出承諾導致對後期需求的變化難以調整，代價高昂。瀑布模型在需求不明並且在項目進行過程中可能變化的情況下基本是不可行的。
原型模型
快速原型模型 允許在需求分析階段對軟件的需求進行初步的非完全的分析和定義，快速設計開發出軟件系統的原型，展示待開發軟件的全部或部分功能和性能，用戶對該原型進行測試評定，給出具體改善的意見以及豐富的細化軟件需求，開發人員進行修改完善。這個過程是迭代的。
缺點： 快速建立 起來的系統加上 連續的修改 可能會造成產品質量低下。
增量模型
增量模型 是一種進化式的開發過程，也稱爲有計劃的產品改進模型。它從一組給定的需求開始，通過構造一系列可執行中間版本來實施開發活動。第一個版本納入一部分需求，下一個版本納入更多的需求，依此類推，直到系統完成。每個中間版本都要執行必需的過程、活動和任務。它是原型模型和瀑布模型的結合。與原型模型不同之處： 它強調每一個增量均發佈一個可操作 產品，它不需要等到所有需求都出來，只要某個需求的增量包出來即可進行開發。增量模型的特點：
- 在
穩定的框架和平臺上，來開發和增加具體的業務功能 - 每個增量之間
相對獨立，各個增量可以並行開發 - 增量
內部是瀑布模型
優點：
- 人員分配靈活，一開始不需要投入大量人力
- 先推出核心的產品，在後續增加相應的功能
- 增量能夠有計劃的管理技術風險
- 適用於
需求經常變更的軟件開發過程
缺點：如果增量包之間存在相交的情況未很好的處理，則必須做全盤的系統分析。
螺旋模型
- 在
原型模型基礎上，進行多次原型反覆並增加風險評估，形成螺旋模型。 - 螺旋模型強調風險管理，因此該模型適用於 大型系統 的開發。
敏捷開發
敏捷開發 是一種從1990年代開始逐漸引起廣泛關注的新型軟件開發方法，是一種能應對快速變化需求的軟件開發能力。敏捷開發的核心是：保證實時可交付，頻繁交付可運行的版本。先做出最核心的功能，再來迭代增加新功能。
相對於"非敏捷"，它更強調程序員團隊與業務專家之間的緊密協作、面對面的溝通（認爲比書面的文檔更有效）、頻繁交付新的軟件版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重在軟件開發中人的作用。敏捷軟件開發主張：適度的計劃、進化開發、提前交付 與 持續改進，並且鼓勵快速與靈活的面對開發與變更。
四個原則：
- 遞增，而不是連續的：如果開發實踐是真正的敏捷精神，那麼交付的工作軟件是一小部分一小部分遞增的。不必等到一個階段完全完成後纔開始另一個，工作也不是向大的發佈日期而努力。完成的工作，但並不是業務最終期限，驅動着敏捷交付。但敏捷精神也承認業務操縱着最後截止日期。
- 避免不必要的開銷：如果實踐仍然是真正的敏捷精神，那麼團隊就致力於儘可能多地減少項目計劃和文檔。與其討論要做什麼，然後再寫下來，不如趕緊動手去做，否則，就是在浪費時間在工作的工作上。在工作對工作中，敏捷精神有利於實際的工作交付工作軟件。而且它也值面對面的交流通過郵件和其他書面文件。
- 協作：根據需求，團隊成員一直與其它人進行交互，以及一些外部利益相關者。在敏捷教練世界中，整個團隊的負責人Lisa Crispin能夠解決所有問題，在問題出現之前 。真正的敏捷精神團隊是自助的。他們分配需要做的工作。雖然每個成員承擔的任務都在他們的專業技能範圍內，他們還是需要與團隊協作的。沒有人的工作是孤立的，也沒有團隊本身是獨立工作的。沒有業務利益相關者，以及諸如用戶體驗方面的外部專家的重大投入，團隊就不可能使項目向前發展，
- 說真話：爲了保證真正的敏捷，團隊探討的與項目相關的一切都要是真實的。在一些至關重要的專業領域，如衝刺測試的編碼技能，他們承認存在差距。關於實際生產力，他們的要講事實；這也就是說，在y時間內，團隊是否有能力做到x。他們承認錯誤。說真話是一項挑戰，因爲他們害怕承認缺點會讓他們顯得很弱。但敏捷精神知道說出事實需要勇氣。承認問題需要信心，然後快速地去解決問題。
敏捷開發的方法有時候被誤認爲是無計劃性和紀律性的方法，實際上更確切的說法是敏捷開發強調適應性而非預見性。適應性的方法集中在快速適應現實的變化。當項目的需求起了變化，團隊應該迅速適應。這個團隊可能很難確切描述未來將會如何變化.
- 對比增量模型：
兩者都強調在較短的開發週期提交軟件，但敏捷開發的週期可能更短，並且更加強調隊伍中的高度協作。 - 對比瀑布模型：
兩者沒有很多的共同點，相對來講，敏捷方法強調的是能將盡早將盡量小的可用的功能交付使用，並在整個項目週期中持續改善和增強。
成熟度模型標準（CMM）
CMM標準用來預測企業所開發的系統和軟件工程能力。一共五個等級：
