1.軟件生命周期
軟件生命周期是指軟件從開(kāi)始研制到最終被廢棄所經(jīng)歷的各個(gè)階段。在不同的階段里，由不同的組織和人員執行不同的任務(wù)，需要消耗不同的資源。
生命周期常見(jiàn)的有：瀑布模型、V模型、敏捷開(kāi)發(fā)模型。
階段：需求分析->軟件設計->程序編碼->軟件測試->運行維護
1.1瀑布模型
瀑布模型是將軟件生存周期的各項活動(dòng)規定為按固定順序而連接的若干階段工作，包括問(wèn)題定義及規劃、需求分析、軟件設計、程序編碼、軟件測試和運行維護等六個(gè)基本活動(dòng)，并且規定了他們自上而下，相互銜接的固定次序，形如瀑布流水，逐級下落，具有順序性和依賴(lài)性，最終得到軟件產(chǎn)品。
因此，如果有信息未被覆蓋或者發(fā)現了問(wèn)題，那么最好 “返回”上一個(gè)階段并進(jìn)行適當的修改，項目開(kāi)發(fā)進(jìn)程從一個(gè)階段“流動(dòng)”到下一個(gè)階段，這也是瀑布模型名稱(chēng)的由來(lái)。
包括軟件工程開(kāi)發(fā)、企業(yè)項目開(kāi)發(fā)、產(chǎn)品生產(chǎn)以及市場(chǎng)銷(xiāo)售等構造瀑布模型。
每個(gè)階段規定的文檔需進(jìn)行評審，評審完后才可以進(jìn)入下一個(gè)階段。
優(yōu)點(diǎn)：
1）為項目提供按階段劃分的檢查點(diǎn)
2）當前一階段完成后，你只需要關(guān)注后一階段
3）可在迭代模型中應用瀑布模型
4）提供一個(gè)模板，這個(gè)模板使得分析，設計，編碼，測試和支持的方法可以在該模板下有一個(gè)共同的指導
缺點(diǎn)：
1）各個(gè)階段的劃分完全固定，階段之間產(chǎn)生大量的文檔，極大地增加了工作量。
2）由于開(kāi)發(fā)模型是線(xiàn)性的，用戶(hù)只有等到整個(gè)過(guò)程的末期才能見(jiàn)到開(kāi)發(fā)成果，從而增加了開(kāi)發(fā)風(fēng)險。
3）通過(guò)過(guò)多的強制完成日期和里程碑來(lái)跟蹤各個(gè)項目階段。
4）瀑布模型的突出缺點(diǎn)是不適應用戶(hù)需求的變化。
1.2V模型
通過(guò)開(kāi)發(fā)和測試同時(shí)進(jìn)行的方式來(lái)縮短開(kāi)發(fā)周期，提高開(kāi)發(fā)效率。其形狀像一個(gè)字母A，故稱(chēng)為V模型。
對應關(guān)系：
一般來(lái)講：?jiǎn)卧獪y試所對應的是詳細設計環(huán)節，也就是說(shuō)，單元測試的測試用例是和詳細設計一起出現的，在研發(fā)人員做詳細設計的時(shí)候，相應的測試人員也就把測試用例寫(xiě)了出來(lái)；集成測試對應概要設計，在做模塊功能分析及模塊接口，數據傳輸方法的時(shí)候，就把集成測試用例根據概要設計中模塊功能及接口等實(shí)現方法編寫(xiě)出來(lái)，以備以后作集成測試的時(shí)候可以直接引用；而系統測試，就是根據需求分析而來(lái)，在系統分析人員作系統分析，編寫(xiě)需求說(shuō)明書(shū)的時(shí)候測試人員就根據客戶(hù)需求說(shuō)明書(shū)，把最后能實(shí)現系統功能的各種測試用例寫(xiě)出來(lái)，為做最后系統測試作準備。驗收測試與用戶(hù)需求對應，是非設計流程。
適用范圍：
V模式是一種傳統軟件開(kāi)發(fā)模型，一般適用于一些傳統信息系統應用的開(kāi)發(fā)，而一些高性能高風(fēng)險的系統、互聯(lián)網(wǎng)軟件，或一個(gè)系統難以被具體模塊化的時(shí)候，就比較難做成V模式所需的各種構件，需要更強調迭代的開(kāi)發(fā)模型或者敏捷開(kāi)發(fā)模型。
1.3敏捷開(kāi)發(fā)模型
是一種以用戶(hù)需求進(jìn)化為核心（強調溝通、弱化文檔）、迭代、循序漸進(jìn)的開(kāi)發(fā)方法。強調以人為本，專(zhuān)注于交付對客戶(hù)有價(jià)值的軟件。是一個(gè)用于開(kāi)發(fā)和維持復雜產(chǎn)品的框架。就是把一個(gè)大項目分為多個(gè)相互聯(lián)系，但也可以獨立運行的小項目，并分別完成，在此過(guò)程中軟件一直處于可使用狀態(tài)。
1.3.1敏捷開(kāi)發(fā)的流程
1）產(chǎn)品負責人將整個(gè)產(chǎn)品設計成產(chǎn)品代辦列表。就是一個(gè)個(gè)需求列表。（可以理解為需求或者要做的事情）
2）召開(kāi)產(chǎn)品迭代計劃會(huì )議，確定哪些需求是需要在第一個(gè)迭代中完成的，評估迭代的時(shí)間（建議是2-4周），得到相應的迭代周期任務(wù)列表。
PS:提前發(fā)布功能需求列表，會(huì )議提倡所有團隊人員參與
3）把迭代的功能需求寫(xiě)在紙條上貼在任務(wù)墻，讓大家（自主認領(lǐng)）認領(lǐng)分配。（任務(wù)墻就是把未完成、進(jìn)行中、已完成的工作狀態(tài)貼到一個(gè)墻上，這樣大家都可以看到任務(wù)的狀態(tài)）
舉行每日站立會(huì )議，讓大家在每日會(huì )議上總結昨天做的事情，遇到什么困難，今天開(kāi)展什么任務(wù)。（每日站立會(huì )議，是在每天早上定時(shí)和大家在任務(wù)墻前站立討論，時(shí)間控制在15分鐘內）
繪制燃盡圖，保證任務(wù)的概況能夠清晰看到。（燃盡圖把當前的任務(wù)總數和日期一起繪制，每天記錄一下，可以看到每天還剩多少個(gè)任務(wù)，直到任務(wù)數為0，這個(gè)迭代就完成了)
PS:在開(kāi)發(fā)人員開(kāi)始開(kāi)發(fā)一個(gè)任務(wù)時(shí)，需要找來(lái)對應的測試人員講解該任務(wù)功能，以便測試人員有一致的理解，并且一開(kāi)始就進(jìn)行測試用例，自動(dòng)化系統測試腳本的開(kāi)發(fā)（若需要自動(dòng)化測試的話(huà)）。
4）評審會(huì )議是在迭代完成時(shí)舉行，要向客戶(hù)演示自己完成的軟件產(chǎn)品，并獲得客戶(hù)的反饋。
PS:很多用戶(hù)對軟件開(kāi)發(fā)是沒(méi)有概念的，他只知道自己有某種需求。所以就要通過(guò)不斷的讓用戶(hù)看到產(chǎn)品的模型，這個(gè)過(guò)程用戶(hù)才會(huì )逐步的對產(chǎn)品產(chǎn)生概念。
5）最后是總結會(huì )議，以輪流發(fā)言方式進(jìn)行，每個(gè)人都要發(fā)言，總結好的實(shí)踐和教訓，并落實(shí)到后續的開(kāi)發(fā)中。不要流于形式。
1.3.2.敏捷開(kāi)發(fā)適用原則
1、個(gè)人與互動(dòng)：重于流程與工具
----強調人與人的溝通，所以盡可能要集中化辦公。異地開(kāi)發(fā)模式容易讓人疲憊
個(gè)人技能要提高。尤其對于架構師要求很高。
管理者要多參與項目有關(guān)的事情。
減少對開(kāi)發(fā)人員的干擾，問(wèn)題集中整理問(wèn)。
2、可用的軟件：重于詳盡的文件
----強調文檔的作用。必要的文檔是必須的，具有傳承性。
3、與客戶(hù)合作：重于合約協(xié)商
----做好客戶(hù)引導?？蛻?hù)都是想在盡可能短的時(shí)間內，交付盡可能多的功能。
4、回應變化：重于遵循計劃
----無(wú)理變化，舉棋不定的結果，并不是說(shuō)都需要及時(shí)響應，會(huì )導致很多浪費。
二、筆試題
1、生命周期模型包括哪些階段？你們公司的開(kāi)發(fā)模型是什么？
聯(lián)系客服
