【軟件開發過程所有文檔獲取—>關注，私信】
1 概述
軟件生命周期包括軟件定義、軟件開發、軟件維護三個過程。
2 可行性分析
目的： 該軟件項目是否該做。
分析角度：
社會可行性：是否符合法律法規，是否有益社會發展，短時間內不被淘汰。
經濟可行性：項目成本預算，能否帶來收益。
技術可行性：該項目中涉及到的技術難點，當前技術能否完成該軟件項目。
產物：可行性分析報告或者白皮書。
3 需求分析
目的：了解客戶需求，明確客戶對軟件項目的要求。
分析內容：
功能需求：描述系統功能，一般來說會細化到每一個小的功能點，小到開發人員可以實現。
界面需求：界面整體布局、色彩、字體字號、系統皮膚、可視化大屏/app功能排版。
性能需求：系統并發能力、系統吞吐量、界面響應時間、系統高可用。
安全需求：敏感數據保護、密碼復雜度要求、數據備份與恢復、網絡安全策略、數據加密傳輸。
其他需求：不同角色擁有不同的功能權限和數據權限。
工具：腦圖、EXCEL功能表、數據流圖。
產物：需求規格說明書。
4 概要設計
目的：完成軟件項目的大概設計。
設計內容：
功能表：詳細的功能表格，包括核心字段描述及工期安排。
技術選型：選擇項目開發所使用的技術，包括編程語言、數據庫、框架、sdk。
架構圖：總體邏輯架構圖、核心業務流程圖、系統之間交互時序圖、系統部署架構圖、網絡拓撲圖。
接口梳理：對內接口梳理、對外接口梳理，接口規范制定（數據格式、權限認證、數據安全傳輸）。
界面設計：界面展示內容、界面操作、界面跳轉、數據權限（本階段可用EXCEL完成）。
工具：EXCEL功能表、UML建模工具(億圖圖示)。
產物：概要設計說明書。
5 詳細設計
目的：完成軟件項目功能實現的詳細做法。
設計內容：
數據庫設計：數據庫ER圖、數據庫建表語句、數據庫索引約束。
接口文檔：定義接口請求地址、請求方式、請求參數數據結構、響應結果數據結構。
算法規范：復雜的接口需要梳理算法邏輯，必要時需要編寫偽代碼或者示例代碼來描述。
界面設計：特殊界面需要設計界面原型圖。
工具：ER圖、Apipost接口文檔編輯工具、原型工具。
產物：詳細設計說明書。
6 編碼實現
目的：根據詳細設計說明書，選擇編程設計語言，完成編碼工作。
心得：初級開發人員在接到編碼工作時，沒有根據相關的設計文檔進行深入的業務梳理，急于完成任務導致考慮不周，使編碼工作不能適應需求的擴展、變化，這樣做會導致編碼邏輯不清、代碼冗余、系統性能差等種種問題；即使完成工作任務，后期維護起來非常費勁；此外一旦編碼有了一定進展，對于大多數人來說，就失去了重構的勇氣了。研發人員需要在業務梳理和思路設計上多花時間，正所謂，工欲善其事，必先利其器。積極使用應用軟件開發設計原則，提高系統內聚，降低系統耦合，增加代碼復用，減少代碼冗余，勤加注釋，易于維護。
7 測試
目的：發現軟件項目中尚未發現的問題。
方法：
黑盒測試：又叫功能性測試，只關注功能，不關注算法；包括邊界值分析和等價類劃分。
白盒測試：又叫結構性測試，關注內部算法是否正確；包括路徑覆蓋、條件覆蓋、語句覆蓋等。
灰盒測試：結合白盒測試和黑盒測試，既關注內部邏輯，又關注總終結果。
階段：
單元測試：最小功能模塊，是否滿足正常需求。
集成測試：對某個單元模塊集成接口的測試。
系統測試：對整體軟件系統的功能、性能的測試。
驗收測試：對軟件項目進行交付前的最后測試，對照需求規格說明書和交付標準，演示軟件項目功能是否滿足用戶需求和驗收標準；（用戶參與、數據真實）。
產物：測試分析報告、用戶操作手冊。
8 運行維護
目的：提供軟件產品交付之后的售后服務，保證軟件產品能夠持續工作。
分類：
正確性維護：發現軟件測試階段未發現的錯誤，維持軟件產品功能的正常運作。
適應性維護：軟件適應信息技術變化和管理需求變化而進行的修改。
完善性維護：增加新的系統功能和需求。
預防性維護：前瞻性的將一些將來會用到的功能加入到系統中，預防系統被淘汰。
產物：程序維護手冊。
9 軟件生命周期模型
概念：軟件生命周期同任何事物一樣，一個軟件產品或軟件系統也要經歷孕育、誕生、成長、成熟、衰亡等階段，一般稱為軟件生命周期（軟件生存周期）。軟件生命周期模型是指人們為開發更好的軟件而歸納總結的軟件生命周期的典型實踐參考。軟件生命周期(SDLC，軟件生存周期)是軟件的產生直到報廢的生命周期。為了使規模大、結構復雜和管理復雜的軟件開發變的容易控制和管理，人們把整個軟件生命周期劃分為若干階段，使得每個階段有明確的任務，整理出軟件生命周期模型。
常用模型：
瀑布模型
原型模型
V模型
敏捷開發模型
9.1 瀑布模型
模型說明：自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。
特點：順序性、依賴性、周期長。
劣勢：項目回溯成本高、效率低、不靈活。
瀑布模型
9.2 原型模型
模型說明：允許在需求分析階段對軟件的需求進行初步而非完全的分析和定義，需要迅速創建一個可以運行的軟件系統原型。
優勢：解決需求不明確和需求理解不一致問題。
劣勢：時間倉促，不斷修改，導致產品質量比較差。
原型模型
9.3 V模型
模型說明：軟件開發過程中的一個重要模型，由于其模型構圖形似字母V，故稱為V模型。
優勢：提高效率，縮短項目周期，節約時間。
劣勢：階段有順序性，并未實質提高測試的地位。
v模型
9.4 敏捷開發模型
模型說明：敏捷開發以用戶的需求進化為核心，采用迭代，循序漸進的方法進行軟件開發。在敏捷開發中，軟件項目在構建初期被切分成多個子系統，各個子系統的成果都經過測試，具備可視，可集成和可運行使用的特征。換言之，就是把一個大的項目分為多個相互聯系，但也可以獨立運行的小項目，并分別完成，在此過程中軟件一直處于可使用狀態。
敏捷開發模型
價值觀：在每項對比中，后者并非全無價值，但我們更看重前者！
—–個體和互動 高于 流程和工具。
—– 可用的軟件 高于 詳細的文檔。
—– 客戶協作 高于 合同談判。
—– 響應變化 高于 遵循計劃。
敏捷原則
1. 我們的最高目標是，通過盡早和持續地交付有價值的軟件來滿足客戶。
2.歡迎對需求提出變更——即使是在項目開發后期。要善于利用需求變更，幫助客戶獲得競爭優勢。
3.要持續交付可用的軟件，周期從幾周到幾個月不等，且越短越好。
4.項目過程中，業務人員與開發人員必須在一起工作。
5.要善于激勵項目人員，給他們以所需要的環境和支持，并相信他們能夠完成任務。
6.無論是團隊內還是團隊間，最有效的溝通方法是面對面的交談。
7.可用的軟件是衡量進度的主要指標。
8.敏捷過程提倡可持續的開發。項目方、開發人員和用戶應該能夠保持恒久穩定的進展速度。
9.對技術的精益求精以及對設計的不斷完善將提升敏捷性。
10.要做到簡潔，即盡最大可能減少不必要的工作。這是一門藝術。
11.最佳的架構、需求和設計出自于自組織的團隊。
12.團隊要定期反思如何能夠做到更有效，并相應地調整團隊的行為。
版權聲明：本文內容由互聯網用戶自發貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發現本站有涉嫌抄襲侵權/違法違規的內容， 請發送郵件至 舉報，一經查實，本站將立刻刪除。