目錄

一、軟件的生命周期?

1、什么是生命周期？

2、每個階段都要做些什么？?

二、常見的開發模型

1、瀑布模型

2、螺旋模型

3、增量模型、迭代模型?

4、敏捷模型

scrum模型

三個角色

五個會議

---

一、軟件的生命周期?

1、什么是生命周期？

生命周期是指從生命的開始到結束的這一段時間，以人為例，就是生命從孕育開始，中間經歷童年、少年、青年、中年、老年，最終到死亡；而軟件、產品也是如此，軟件的生命周期是從需求的產生，再經過需求的計劃、設計，程序開發，程序測試等階段，最終到軟件不再維護時，軟件的生命周期也就結束了。

那什么是需求呢？

首先需求分為用戶需求與軟件需求

用戶需求：可以理解為是甲方提出的要求，如果沒有甲方，那么就是終端用戶使用產品時必須要完成的任務。其需求一般比較簡略，往往是一句簡單的話。

比如：實現?個軟件的登錄功能，或者你朋友說，幫我寫一個作業。那么你朋友就是甲方（當然，作為你的甲方肯定要他給你工資哈）。

軟件需求：或者叫功能需求，該需求會詳細描述開發人員必須實現的軟件功能。軟件需求也是測試人員進行測試工作的基本依據。

那么軟件需求與用戶需求有什么區別？

用戶需求：

幫我寫一個作業。

軟件需求：

需要你和他反復的溝通了解更加詳細具體的需求,來制定解決方案

比如：

“什么作業”? “計算機作業”

“什么時候交”? “下周”

.........

最終理解清楚用戶需求之后，知道朋友想要你幫他做python作業，那么再去研究其要求，怎么做等等的具體步驟，這就是軟件需求

具體的軟件測試會做成一份文檔，提供給開發人員及測試人員。

了解了需求，我們現在來看一個案例

假如我想要建造?套房子，房子的?命周期（流程）是什么樣的？

因此，我們就得到了軟件（開發）的生命周期：

需求分析??計劃??設計??編碼??測試??運行維護

2、每個階段都要做些什么？?

需求分析：分析用戶需求是否合理，分別從市場需求、技術等方面進行分析，最后會輸出需求等文檔。

計劃：對成立的需求執行需求執行計劃，比如，多長時間內完成該需求，每個時間段具體完成哪些功能，最后會輸出計劃等文檔。

設計：將需求細化成一個個任務，團隊成員各司其職領取任務并進行技術計劃，最后輸出技術等文檔。

編碼：開發人員參考需求文檔、設計文檔、交互圖等文件進行代碼的編寫，最后輸出代碼等文檔。

測試：測試人員需要介入到軟件的測試中，參考測試用例對軟件進行測試，最后輸出測試用例、測試設計與計劃、測試報告等文檔。

運行維護：測試項目結束后，項目需要進行上線，并對產品進行線上的維護，線上維護主要分為三個方面：修護性維護、完善性維護和預防性維護。

二、常見的開發模型

1、瀑布模型

瀑布模型在軟件工程中占有重要地位，是所有其他模型的基礎框架。瀑布模型的每?個階段都只執行一次，因此是線性順序進行的軟件開發模式。

而瀑布模型其缺陷也很明顯，由于周期太長，產品很遲才能被看到和使用，可能會導致需求/功能過時。并且測試的后置，會使得前面各階段遺留的風險推遲到測試階段才被發現，導致項目大面積返工，失去及早修復的機會。而且必須留有足夠的時間給測試人員，否則導致測試不充分，將缺陷直接暴露給用戶。

因此，瀑布模型適用于需求固定的小項目。

2、螺旋模型

螺旋模型在瀑布模型的基礎上，每個階段都引入了風險分析+原型

風險分析很好理解，就是對當前階段可能存在的問題以及風險進行評估，并進行解決，重新輸出文檔。那么什么是原型？

原型就是一個需求在完成開發之后的一個模型，我們需要對這個模型來進行考核評估，如果該模型是合理的，那就進行下一階段，如果不合理，那就回爐重造。

螺旋模型強調嚴格的全過程分險管控，強調各開發階段的質量，解決了瀑布模型對許多些規模龐大、復雜度高、分險大的項目的無力問題。但是，項目中可能存在的分險性與分險管理人員的技能水平有直接關系，同時也加大了需求人員、資金、時間的增加和投入，可能導致項目的成本過高。

?因此，螺旋模型適用于規模龐大，復雜度高、分險大的項目。

3、增量模型、迭代模型?

?

增量開發模型，鼓勵用戶反饋，在每個迭代過程中，促使開發小組以一種循環的、可預測的方式驅動產品的開發。因此，在這種開發模式下，每一次的迭代都意味著可能有需求的更改、構建出新的可執行軟件版本，意味著測試需要頻繁進行，測試人員需要與開發人員更加緊密地協作。

迭代模型與增量模型是有區別的，就如下圖所示：

增量是逐塊建造的概念。先完成一部分功能，發布后，再根據需求增加新的功能再發布，就比如抖音，最開始只有刷視頻的功能，再后面就上線了商城購物功能。

迭代是反復求精的概念。把所有功能都進行簡化，保留最基礎的功能進行上線發布，然后再對已有的功能進行優化完善，是一個不斷優化的過程。

這兩個模型通常被混合使用，適用于大型的、需求不明確的項目。

4、敏捷模型

敏捷模型主要旨在幫助項目快速適應變更請求。因此，敏捷模型的主要目的是促進項目的快速完成。

敏捷模型中有?個重要的《敏捷宣言》，宣言內容：

個體與交互重于過程和工具

可用的軟件重于完備的文檔

客戶協作重于合同談判

響應變化重于遵循計劃

簡單來說，這幾句話的意思就是要注重實在的交流，隨機應變，不用循規蹈矩。

敏捷開發有很多種方式，其中scrum是比較流行的一種。

scrum模型

scrum模型是敏捷模型中的一種，又稱為迭代式軟件增量開發模型。

在scrum模型中主要有三個角色和五個重要會議

三個角色

scrum由product owner(產品經理)、scrum master(項?經理)和team(研發團隊)組成

product owner負責整理user story(用戶故事，也就是需求)，定義其商業價值，對其進行排序，制定發布計劃，對產品負責。

scrummaster負責召開各種會議，協調項目，為研發團隊服務。

研發團隊則由不同技能的成員組成，通過緊密協同，完成每?次迭代的目標，交付產品。?

五個會議

發布計劃會議：product owner負責講解user story，對其進行估算和排序，發布計劃會議的產出就是制定出這?期迭代要完成的story列表，sprint backlog。

迭代計劃會議：項?團隊對每?個story進行任務分解，分解的標準是完成該story的所有任務，每個任務都有明確的負責人，并完成工時的初估計。

每日例會：每天scrum master召集站立會議，團隊成員回答昨天做了什么今天計劃做什么，有什么問題。

演示會議：迭代結束之后，召開演示會議，相關人員都受邀參加，團隊負責向大家展示本次迭代取得的成果。期間?家的反饋記錄下來，由product owner整理，形成新的story。

回顧會議：項目團隊對本期迭代進行總結，發現不足，制定改進計劃，下?次迭代繼續改進，以達到持續改進的效果。