開發模型是軟體工程中指導開發的開發思想、開發體系。
最初始的模型，上個世紀七十年代提出，盛極一時，全球百分之九十的專案都用瀑布模型。
軟體計畫、需求分析、軟體設計、程式編碼、軟體測試、執行維護。每個階段都會有輸出產物，是乙個很經典的模式。但是每個階段都依賴於上一階段，不能應對客戶需求變更。
瀑布模型總結：只能適應於需求明確的專案，需求不明確的專案千萬不能用瀑布模型。
定位於需求不明確的專案。在專案初期會構造乙個簡易系統（可以是介面無後台功能，也可以是一套初步的系統）。一般用於需求分析階段。
在原型模型基礎上，逐步完善逐步演變，形成最終的成熟軟體。
先把核心部分做出來，週期可能為完整專案的百分之二十，完成後又開發第二個模組、乙個乙個模組開發。好處就是，先把核心模組做完給使用者看，以後每個模組給使用者時都會審核核心模組，避免了做完專案後核心需求得改的情況。
融合了原型模型（原始版本）、瀑布模型（各個階段）、演化模型（逐步完善）各種模型。
引入了風險分析。
強調測試貫穿始終，在需求分析時就開始驗收測試和系統測試，而不是像瀑布模式一樣在最後進行測試。
物件導向的模型，迭代，無間隙。
極大提高軟體開發復用性。
適用於小型專案，xp程式設計（極限程式設計）僅適用於小專案。敏捷開發(對內對外的溝通)，功能簡單（不需要過度設計）。
業務需求
系統用來做什麼，巨集觀方面的想法。
使用者需求
和使用系統的人溝通，收集各個使用者角度的需求。要把使用者需求轉換為系統需求。
系統需求
系統需求分為：功能需求（軟體的功能）、效能需求（非功能需求：安全性、可靠性）、設計約束。
自頂向下，逐步求精
模組獨立（高內聚、低耦合）
模組大小適中
減少呼叫深度(父模組呼叫子模組,子模組再呼叫其他模組叫呼叫深度)
模組多扇入，少扇出(多被呼叫，少呼叫其他模組，說明模組復用性比較高)
單入口，單出口
模組的作用域應該在模組之內
功能是可**的
內聚：模組內部元件之間的聯絡
耦合：模組與模組之間的聯絡
黑盒測試
白盒測試
灰盒測試
桌前檢查：程式設計師自己檢視**
**走查：人工執行**（邏輯在程式設計師的大腦裡面跑一次）
**審查：程式設計師之間交叉檢查**
立項階段 -> 開發階段 -> 維護階段 -> 消亡階段
易分析性（**需要容易看懂），易改變性（**要有低耦合度），穩定性，可測試
改正性維護：改正bug。
適應性維護：適應環境（軟體環境，硬體環境）。
完善性維護：擴充功能，使系統更完善。
預防性維護：預防性工作（文件，**重構，在bug未出之前改正，如00年的時間問題，提前公升級叫預防性，事後叫改正性維護）。
衡量軟體承包方的能力成熟度模型。
軟體設計師教程目錄
第1章 計算機系統知識 1.1計算機系統基礎知識1 1.2計算機體系結構1 1.3安全性 可靠性與系統效能評測基礎知識34 第2章 程式語言基礎知識51 2.1程式語言概述5 1 2.2語言處理程式基礎6l 第3章 作業系統知識94 3.1作業系統基礎知識94 3.2處理機管理98 3.3儲存管理 ...
軟體設計師複習（一）
1 常用的虛擬儲存器由 主存 輔存 兩級儲存器組成。2 中斷向量可提供 中斷服務程式的入口位址 3 為了便於實現多級中斷巢狀，使用 堆疊 來保護斷點和現場最有效。4 dma工作方式下，在 主存與外設 之間建立了直接的資料通路。5 利用報文摘要演算法生成報文主要的目的是 防止傳送的報文被篡改 6 防火...
軟體設計師考試總結
我們剛開始為了這次考試，自發結成乙個小組。自己卻因為時間安排上的問題與自己的組員嚴重脫節。經過一段時間的自己看書學習，覺得效果很差，就去找師哥師姐幫忙了。慶幸的是在師哥師姐的帶領下自己也算是跟上了隊伍的節奏！個人覺得在其中需要注意的幾點 備考階段 小組學習 在這個階段一定要跟小組一起學習討論，有疑問...