2.3 物件導向的模型
2.4 敏捷方法
2.5 軟體專案計畫
傳統開發模型：瀑布模型、快速原型模型。
演化開發模型：增量模型、螺旋模型。
物件導向開發模型：噴泉模型、構件整合模型。
形式化開發模型：轉換模型、淨室模型。
計畫時期：
開發時期：
軟體執行與維護
使用維護
1.瀑布模型
將軟體生存週期各項活動規定位依線性順序聯結的若干階段的模型。它包括可行性分析、專案開發計畫、需求分析、概要設計、詳細設計、編碼、測試和維護。它規定了由前至後、相互銜接的固定次序。
瀑布模型法適合於在軟體需求比較明確、開發技術比較成熟、工程管理比較嚴格的場合下使用。
特點：
存在問題：不適合需求模糊的系統。（在實際開發過程中，為了保證軟體產品的質量，每個階段完成之後，要對其階段的工作和成果做出客觀評價，如發現問題，就應停止前行，沿著所經歷的階段返回）
系統分析階段的常用技術：
系統分析階段的軟體工具：
系統設計階段的軟體工具：
程式設計階段：
2.快速原型模型
從獲得使用者基本需求說明的基礎上，投入少量人力和物力，快速建立乙個原始模型，使使用者及時執行和看到模型的概貌和使用效果，並對需求說明進行補充和精化，提出改進意見，開發人員進一步修改完善，如此迴圈迭代，知道得到乙個使用者滿意的模型為止。
從原型法的基本思想中可以看到，使用者能及早看到系統模型，在迴圈迭代修改和完善過程中，使使用者的需求日益明確，從而消除了使用者需求的不確定性，同時從原型到模型的生成，周期短、見效快，對環境變化的適應能力強。
（1）功能選擇
（2）構造原型
根據使用者初步需求，開發出乙個可以應用的系統，它應滿足上述的由使用者提出的基本要求。在構造乙個原型時，應當強調著眼於預期的評估，而不是為了正規的長期使用。
（3）執行和評價原型
在試用中能親自參加和面對乙個實在的模型，能較為直觀和明確地進一步提出需求，提出修改意見。通過執行原型對軟體需求規格說明進行評價和確認。評價要有使用者參與，注意來自使用者的反饋資訊。
（4）修改和完善原型
根據修改意見進行修改，以得到新的系統原型，然後再進行試用和評價，這樣經過有限次的迴圈反覆，逐步提高和完善，知道得到乙個使用者滿意的系統模型為止。根據原型實現的特點和環境，可以把原型作為實驗的工具，用完就丟棄；也可以使原型全部或部分地稱為最終系統的組成部分。
特點：
種類：
3.軟體演化模型
階段式開發：增量模型
系統設計時分片交付，可使使用者在使用某些基本功能的同時，開發剩餘的功能。這樣通常會並行地存在兩個系統：生產系統和開發系統。執行或生產系統是當前被客戶或使用者所使用的系統。而開發系統是準備用於替代當前生產系統的下乙個版本。
增量：小而可用的軟體。
特點：在前面增量的基礎上開發後面的增量，每個增量的開發可用瀑布或快速原型模型迭代的思路。
螺旋模型
其基本思想是使用原型及其他方法以盡可能地降低風險。理解這種模型的簡易方法，是把它看作在每個階段之前都增加了風險分析過程的快速原型模型。
每個階段開始時的任務是，確定該階段的目標、為完成這些目標選擇方案及設定這些方案的約束條件。接下來的任務是，從風險角度分析上一步的工作結果。努力排除各種潛在的風險，通常用建造原型的方法來排除風險。如果風險不能排除，則停止開發工作或大幅度地削減專案規模。如果成功地排除了所有風險，則啟動下乙個開發步驟，在這個步驟的工作過程相當於純粹的瀑布模型。最後是評價該階段的工作成果並計畫下乙個階段的工作。
特點：瀑布模型+快速原型+風險分析
迭代過程：乙個螺旋式週期。
4.形式化方法模型
形式化方法模型是一種基於數學的開發技術，主要採用數學的方法與表示體系描述軟體的性質，表示軟體規格說明，然後進行一系列自動或半自動的程式轉換，最後轉換為計算機系統能夠接受的目標程式系統。
是基於形式化語言和程式變換的模型，因此也稱為變換模型。從軟體需求形式化說明開始，經過一系列的數學變換和正確性證明，最終得到系統的目標程式。形式化方法使開發者應用乙個嚴格的數學符號體系來表示、構造和驗證系統，從而大大提高軟體的可靠性。
兩種技術：
特點：5.淨室模型
形式化過程模型的乙個擴充套件，稱為淨室軟體工程或淨室模型，它除了強調分析和設計上的嚴格性，以及使用基於數學的正確性證明來對設計模型的每個元素進行形式化驗證外，還強調了統計質量控制技術。其基本思想是：力求在分析和設計階段就消除錯誤，確保正確，然後在無缺陷或「潔淨」的狀態下實現軟體的製作。
關鍵技術：
形式化：
1.噴泉模型
特點：2.構件整合模型
特點：構建技術目前的三種流行標準：
基於構件的未來軟體生產線：
應用構建提取車間-》應用構件庫-》構建生產車間（基礎構建、功能構件、介面構件、使用者介面構件）-》構件庫-》組裝車間-》應用系統
3.面向agent的軟體工程
自主性agent應是具有自身計算功能的自動控制行為的實體。它能夠在非選定的模式下和動態變化的環境中，不用外界直接操縱，根據其內部狀態和感知到的環境資訊，決定和控制自身的行為。這是agent區別於「物件」的乙個重要特徵。
agent具有以下特點：
agent與物件（object）的區別：
面向agent的高層建模：
物件導向方法在aose中的應用
1.xp（extreme programming，極端程式設計方法）
2.cockburn的水晶系列方法
3.asd（adaptive software development，自適應軟體開發）方法
4.scrum方法
5.fdd（feature-driven development 方法）
極限程式設計愛好者和敏捷方法一般將不斷變化的需求看作是乙個自然、不可避免、理想的軟體開發專案的乙個方面。他們認為在專案中任何時候適應不斷變化的需求是一種更為現實和更好的方法，而不是在乙個專案開始時試圖確定所有需求、付出努力控制變化。
問題定義
目的：
任務：編寫「系統目標與範圍的說明」
可行性研究
目的：研究專案是否可能實現和值得進行（用最小的代價，在盡可能短的時間內確定）
研究的內容：
系統效益包括：
技術可行性
執行可行性
法律可行性
研究的步驟：
系統流程圖：
軟體風險分析
盡可能的量化不確定性的程度及每個風險導致的損失的程度，為軟體開發的實施計畫提供參考。
風險識別：
可用不同的方法對風險進行分類。從巨集觀上看，可將風險分為專案風險、技術風險和商業風險。
風險**：
通常，專案計畫人員與管理人員、技術人員一起，進行兩項風險估計活動：
估計風險對專案和產品的影響
在風險分析過程中進行風險評價得時候，應當建立乙個三元組：[ri, li, xi]
其中，ri是風險、li是風險出現的可能性、xi是風險的影響。在做風險評價時，應當進一步檢驗在風險估計時所得到的估計的準確性，嘗試對已暴露的風險進行優先排隊，並著手考慮控制或消除可能出現風險的方法。
在做風險評價時，按以下步驟執行：
風險的駕馭和監控：
常見的軟體系統風險：後門/陷阱門、人為錯誤、拒絕使用、輻射、盜用、無法使用、火災和自然災害、偽造、硬體故障、假冒、不準確的或過時的資訊、故意對資料或程式進行破壞、邏輯炸彈、錯誤傳遞、程式編制錯誤、破壞活動、廢物利用、超級處理、偷竊行為、計算機病毒。
專案實施計畫
質量保證計畫
軟體測試計畫
文件編制計畫
使用者培訓計畫
綜合支援計畫
軟體分發計畫
軟體工程 軟體生存週期
與任何事物一樣，軟體也有乙個孕育 誕生 成長 成熟 衰亡的過程，這個過程稱為軟體生存週期 軟體生命週期 詳細的劃分如下圖 它們的主要任務如下 制定規劃 可行性分析 確定要開發軟體系統的總目標，給出它的功能 效能 可靠性以及介面等方面的要求。由系統分析員和使用者合作，研究該項任務的可行性，解決問題的可...
軟體工程（二）軟體生存週期與軟體過程
乙個軟體從開始立項起，到廢棄不用為止，統稱軟體的生存週期。典型的軟體生存週期的主要活動包括 需求分析 明確使用者需要解決的問題，分析員根據對問題的理解提出關於系統目標與範圍的說明，從使用者視角對需求進行定義和分析，用需求模型的形式準確地表達出來 軟體分析 在需求模型的基礎上，從開發人員視角對軟體需求...
《軟體工程方法與實踐》 2 4 軟體生存週期
同任何事物類似，軟體也有乙個從生到死的過程，這個過程一般稱為軟體生存週期或生命週期 software development life cycle，sdlc 一般地，軟體生存週期可劃分為定義 開發和執行3個時期，每個時期又細分為若干個階段。把整個軟體生存週期劃分為若干階段，使得每個階段有明確的任務，...