一、軟件開發生命週期（SDLC）
1、從0到1
計劃 分析 設計 實施 測試 維護
2、從1到n
很多個版本
二、傳統的軟件過程模式
兩種基本類型：
1、線性
2、迭代
不同模式的關鍵質量考慮因素：
1、用戶的參與（適應變化）
2、發展效率，軟件管理的複雜性
3、軟件的質量
現有的模型：
瀑布模型、v模型、增量模型、原型法、螺旋模型
三、不同模型的介紹和比較
1、瀑布型
瀑布模型又稱爲經典生命週期，他提出了一個系統的，順序的軟件開發方法。通過概念，啓動，分析，設計，施工，測試，實施和維護最終提供完整的軟件支持
缺點：1、實際項目很少遵循該順序，雖然線性模型可以加入迭代，但是它是用間接的方式實現的，容易造成混亂。
2、客戶難以清楚的描述所有的需求，而瀑布模型要求客戶明確的需求，很難適應許多項目在開始階段的不確 定性。
3、客戶要有足夠的耐心，只有在項目接近尾聲的時候才能得到可執行程序。對於系統存在的重大缺陷，如果 在可執行程序評審之前沒有得到發現，將可能造成很大的風險。
4、在某些項目中會導致阻塞狀態，由於任務之間的依賴性，開發團隊一些成員要等待另一些成員工作完成， 等待時間可能超過花在工作生產上的時間
2、v型
瀑布模型的延伸
v模型描述了質量保證工程與溝通、建模以及早期構建相關工程的關係。隨着沿着v模型左側步驟向下推進，基本問題需求逐步細化，形成了對問題及解決方案的詳盡且技術性的描述。一旦編碼結束，團隊沿着v 模型向上推進，本質執行了一系列測試，這些測試驗證了團隊沿着v 模型左側向下推進時所生的每個模型。實際上v 模型和瀑布模型沒有本質上的區別。但是v模型提供了一種將驗證和確認動作應用於早期軟件工程工作的直觀方法。
3、增量模型
在許多情況下，初始的軟件需求有明確的定義，但是整個開發過程卻不宜單純運用線性模型。同時，可能迫切需要爲用戶迅速提供一套功能有限的軟件產品，然後在後續版本中再進行細化和擴展功能。在這種條件下，需要選用一種以增量的形式生產軟件產品的過程模型。例如，採用增量模型開發文字處理軟件，在第一個增量中提供基本的文件管理、編輯和文檔生成功能;在第二個增量中提供更爲複雜的編輯和文檔生成功能;在第三個增量中提供拼寫和語法檢查功能;在第四個增量中提供高級頁面排版功能。需要注意的是，任何增量的過程流都可能使用下一節中討論的原型範型。注：如果你的客戶要求你在一個不可能完成的時間內提交作品，那麼向他建議屆時肢體叫一個或幾個增量，此後再提交其他的幾個增量
4、原型模型
很多時候，客戶定義了軟件的一-些基本任務，但是沒有詳細定義功能和特性需求。另一種情況下，開發人員可能對算法的效率、操作系統的適用性和人機交互的形式等情況並沒有把握。但是通常情情況下，採用原型開發範型(prototyping paradigm)是最好的解決辦法。雖然原型可以作爲一個獨立的過程模型，但是更多的時候是作爲一種技術。當需求很模糊的時候，原型開發模型都能幫助軟件開發人員和利益相關者更好地理解究竟需要做什麼。原型開發範型開始於溝通。軟件開發人員和其他利益相關者建議定義軟件的整體目標，明確已知的需求，並大致勾畫出以後再 客戶有一個合理進一步定義的東西。然後迅速策劃一個原型開發選代並進行建模(以“快 的要求，但是對速設計”的方式)。快速設計要集中在那些最終用戶能夠看到的方面(比如細節）。沒有思路，那麼不妨先開發。快速設計產生了一個原型。對原型進行部署，然後由利益相關者進行評估。根據利益相關者的反饋信息，進一步精煉軟件的需求。在原型系統不斷調整以滿足各種利益相關者需求的過程中，採用迭代技術，同時也使開發者逐步清楚用戶的需求。
5、螺旋模型
螺旋模型基本做法是在“瀑布模型”的每一個開發階段前引入一個非常嚴格的風險識別、風險分析和風險控制，它把軟件項目分解成一個個小項目。每個小項目都標識一個或多個主要風險，直到所有的主要風險因素都被確定。
螺旋模型強調風險分析，使得開發人員和用戶對每個演化層出現的風險有所瞭解，繼而做出應有的反應，因此特別適用於龐大、複雜並具有高風險的系統。對於這些系統，風險是軟件開發不可忽視且潛在的不利因素，它可能在不同程度上損害軟件開發過程，影響軟件產品的質量。減小軟件風險的目標是在造成危害之前，及時對風險進行識別及分析，決定採取何種對策，進而消除或減少風險的損害.風險驅動。
四、敏捷開發和極限編程（xp）
敏捷開發宗旨：
一：個體及交互比流程與工具更具價值
二：可用的軟件比冗長的文檔更有價值三：與客戶的協作比合同談判更有價值
四：對變化的響應比遵循計劃更有價值
十二個原則：
1.我們最優先要做的是通過儘早、持續交付有價值的軟件來使客戶滿意。
2.即使在開發的後期，也歡迎需求變更。敏捷過程利用變更爲客戶創造競爭優勢。
3.經常交付可運行軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。
4.在整個項目開發期間，業務人員和開發人員必須天天都在一起工作。
5.圍繞有積極性的個人構建項目。給他們提供所需的環境和支持，並且信任他們能夠完成工作。
6.在團隊內部，最富有效果和效率的信息傳遞方法是面對面交談。
7.可運行軟件是進度的首要度量標準。
8.敏捷過程提倡可持續的開發速度。責任人(sponsor). 開發者和用戶應該能夠長期保
持穩定的開發速度。
9.不斷地關注優秀的技能和好的設計會增強敏捷能力。
10.簡單一使不必做的 工作最大化的藝術一是必 要的。
11.最好的架構、需求和設計出自於自組織團隊。
12.每隔-定時間，團隊會反省如何才能更有效地工作，並相應調整自己的行爲。
並不是每一個敏捷過程模型都同等使用這12項原則，一些模型可以選擇忽略(或至少
淡化)一項或多項原則的重要性。然而，上述原則定義了一種敏捷精神，這種精神貫穿於本
章提出的每一個過程模型。
極限編程：
極限編程中有四個核心價值是我們在開發中必須注意的：溝通（Communication）、簡單（Simplicity）、反饋（Feedback）、勇氣（Courage）、此外還擴展了第五個價值觀：謙遜（Modesty）。 XP用“溝通、簡單、反饋、勇氣和謙遜”來減輕開發壓力和包袱；無論是術語命名、專著敘述內容和方式、過程要求，都可以從中感受到輕鬆愉快和主動奮發的態度和氣氛。這是一種幫助理解和更容易激發人的潛力的手段。XP用自己的實踐，在一定範圍內成功地打破了軟件工程“必須重量”才能成功的傳統觀念。
主要要求：1、配對編程 2、任務版和進度控制
五、軟件配置管理（SCM）
1、scm在軟件中的任務是跟蹤和控制軟件的變化。
2、SCM的做法包括版本控制和設置基線。
3、爲什麼要進行版本控制（SCM）？
對於個人：
恢復到過去的版本；
比較兩個不同的版本；
將完整版本歷史記錄推送到其他位置；
從該版本撤回到歷史版本；
對於團隊合作：
在多個合作者中間通信分享合併工作；
記錄不同開發人員的個性化作品以進行審覈；
4、cmdb（配置管理數據庫和簽入遷出審覈）
5、基線
在計算機術語中，基線是項目儲存庫中每個工件版本在特定時期的一個“快照”。它提供一個正式標準，隨後的工作基於此標準，並且只有經過授權後才能變更這個標準。建立一個初始基線後，以後每次對其進行的變更都將記錄爲一個差值，直到建成下一個基線。
6、（1）本地版本控制系統（LVCS）——本地完整倉庫（少用）
簡介：在硬盤上保存補丁集（補丁是指文件修訂前後的變化）；通過應用所有的補丁，可以重新計算出各個版 本的文件內容。大多數採用某種簡單的數據庫來記錄文件的歷次更新差異。
優點：簡單、很多系統中都有配置
適合管理文本文件
缺點：不支持網絡
支持類型單一
（2）集中式版本控制系統（CVCS）——服務器完整的倉庫
簡介：有一個單一的集中管理的服務器，保存所有文件的修訂版本，而協同工作的人們都通過客戶端連到這臺服務器，取出最新的文件或者提交更新。
每個人都可以在一定程度上看到項目中的其他人正在做些什麼。而管理員也可以輕鬆掌控每個開發者的權限，並且管理一個 CVCS 要遠比在各個客戶端上維護本地數據庫來得輕鬆容易。
優點：適合多人團隊協作開發
代碼集中話管理
缺點：單點故障
必須連網操作，無法單擊本地工作
（3）分佈式版本控制系統（DVCS）——本地和服務器都有完整的倉庫
簡介：客戶端並不只提取最新版本的文件快照，而是把代碼倉庫完整地鏡像下來。這麼一來，任何一處協同工作用的服務器發生故障，事後都可以用任何一個鏡像出來的本地倉庫恢復。 因爲每一次的克隆操作，實際上都是一次對代碼倉庫的完整備份。
可以指定和若干不同的遠端代碼倉庫進行交互。這樣，你就可以在同一個項目中，分別和不同工作小組的人相互協作。
最常用：Git、Mercurial（HG）
優點：適合多人團隊協作開發
代碼集中化管理
可以離線工作
每個計算機都是一個完整倉庫
7、版本控制特點
a， 可靠：只要我們需要，就可以保持版本不變; 允許備份；
b,多個文件：跟蹤項目的版本，而不是單個文件
c,有意義的版本：有什麼變化，他們爲什麼做？
d,恢復：全部或部分恢復舊版本
e,比較版本
f,審查歷史：整個項目或個人檔案
g,不僅僅是代碼：散文，圖像......
h,它應該允許多個人一起工作：
- 合併：結合與以前的通用版本不同的版本
- 跟蹤責任：誰做了這個改變，誰觸及了那行代碼？
- 並行工作：允許一個程序員自己工作一段時間（不放棄版本控制）
- 工作進行中：允許多個程序員共享未完成的工作（不中斷別人，不放棄版本控制）