ppt3 軟體過程
一、 軟體過程模型
1． 瀑布模型：每個過程階段獨立，直到上乙個過程完成，下乙個過程才啟動
其間伴隨著過程反覆
瀑布模型的缺點是過程進行中對應變更比較困難。
問題：將專案生硬地劃分成幾個明顯不同的階段，這使得響應客戶的需求比較困難，所以這個模型適用於需求能夠較好地理解的情況
2． 進化式開發：描述與開發交替進行
探索式：其目標是與客戶一起工作，從最初的需求草案進化到最後的系統。應該從理解最清楚的需求開始。
拋棄式：目的是理解系統需求。從理解較差的需求開始
問題：缺乏過程可見性；系統結構通常較差；需要特殊的工具和技術 (例如採用快速建立原型的語言)
適用性：中小型互動式系統；大型系統的一部分 (如使用者介面)；生命周期短的系統
3． 形式化的系統開發
基於用形式化數學轉換將系統描述轉換成乙個可執行程式
轉換是保證正確性的，所以程式是符合描述的。
具體實現如ibm的淨室(cleanroom)過程軟體開發
問題：應用這項技術需要專門的技能和訓練；系統的某些方面難以形式化描述，例如使用者介面
適應性：適合於嚴格的系統，特別是安全性和保密性要求極高的系統
4． 面向復用的開發
基於已有的元件或者cots系統的系統重用
5． 過程反覆：系統需求在專案進行期間總是進化的，所以對大型系統來說經常是早期階段反覆的過程；反覆可以應用於任何通用過程模型
兩個混合模型
a. 增量式開發：系統不是一次交付，而是將要求的功能分成多次增量進行開發和交付
使用者需求是有優先順序的。優先順序最高的需求包含在最初的增量中。
一旦乙個增量的開發開始時，需求就要凍結。雖然後面的增量可以繼續進化
優勢：客戶要求的功能隨著每次增量被交付，所以系統功能可以較早看到
較早的增量可以作為原型幫助引出後面增量的需求
專案總體失敗的風險降低
最高優先順序的系統服務由於是最早增量，得到最多的測試
極限程式設計：基於非常小的功能增量的開發和交付的一種新的方法；依靠連續的**改進，使用者參與到開發團隊一起開發，是敏捷開發的一種
b. 螺旋式開發
將過程表示為螺旋線，而不是用一系列活動和活動間的回溯來表示
螺旋線中的每個迴路表示過程中的乙個階段
沒有固定的階段。螺旋線中的迴路根據需要選取
風險需要明確評估、然後在過程中解決
二、 軟體設計方法
1． 資料流模型：包括資料元素，資料操作，資料流向
2． 實體-關係模型
3． 結構模型
4． 物件模型：將資料與操作封裝視為物件，具有一定的屬性，各個物件之間連線構成模型
ppt4
一、 專案管理
1． 軟體專案管理涉及的行為，是為了確保軟體及時並按照進度的要求交付，同時滿足開發或者採購該軟體的機構的需求專案管理是需要的，因為軟體開發總是受到預算和進度的約束，這些約束是由開發該軟體的機構所設定的。
2． 軟體管理的特別之處：
產品是無形的
產品是靈活可變的，其它產品中這是比較少見的。
軟體工程學科被認為還是不完整的，跟機械、電子工程等學科不同
軟體開發過程是非標準化的
許多軟體專案是一次性的專案
3． 專案計畫的型別：
質量計畫，有效性驗證計畫，配置管理計畫（支援系統的整合計畫，使每個開發人員可以在管理中訪問工程**和文件，超找變更，編譯連線元件並生成系統），維護計畫，人員發展計畫
4． 活動組織
里程碑：是乙個過程活動的終點，瀑布過程可以定義明顯的進度里程碑
可交付物：是交付給客戶的專案結果
5． 專案排程
將專案分解成多個任務，估算完成每個任務需要的時間和資源
併發地組織任務以形成勞動力的優化利用
使得任務間的依賴性最小化以避免乙個任務等待另乙個任務帶來的延遲
依賴於專案管理者的直覺和經驗
甘特圖：活動的時間條形圖
6． 風險管理
風險包括專案風險、產品風險和業務風險
過程：風險識別：識別專案、產品和業務風險
風險分析：評估這些風險出現的可能性及其後果
風險規劃：制訂計畫說明如何規避風險或降低風險對專案的影響
風險監控：監控整個專案過程中的風險
管理者要扮演多種角色，其中最主要的活動是規劃、估算和進度
ppt5
1． 需求工程：
建立使用者需求以及使用和開發的約束的過程
需求工程過程中生成的需求本身是系統服務和約束的描述
2． 需求的雙重功能：
可能是乙個合同標書的基礎 – 所以必須公開解釋
可能是合同本身的基礎 – 所以必須詳細定義
這兩種情形都可能稱為需求
3． 需求的型別：
使用者需求：關於系統服務和約束的自然語言加上方塊圖表述。為客戶撰寫。較為粗略。
系統需求：乙個結構化的文件寫出系統的服務。作為客戶和承包商之間的合同內容。較為細緻。
軟體描述：乙個詳細的軟體描述可以作為設計或實現的基礎。為開發人員撰寫。
4． 功能與非功能需求
功能需求：系統需要提供的服務的表述，系統應該如何響應特定輸入，系統在特定的情形下應該如何動作。
非功能需求：系統提供的服務或功能上的約束，例如時間約束、開發過程約束、標準等。
領域需求：需求從系統應用領域中得出，反映了領域的特徵。
5． 需求應該具有完整性和一致性
完整性：需要的所有服務都應該給出描述
一致性：在系統服務的描述上應該沒有衝突和矛盾
6． 非功能需求分類
產品需求：描述交付產品的行為，如執行速度、可靠性等
機構需求：機構政策和程式的結果，如過程標準、實現要求
外部需求：系統外部因素和開發過程，如互操作性要求、法律要求等
7． 需求的度量：
8． 領域需求
從使用領域中得到，描述反映領域的特徵和性質
可能是新的功能需求、已有需求的約束或者定義乙個特定的計算
如果領域需求不被滿足，系統可能無法工作
如：問題：
易懂性不夠：需求使用應用領域中的語言表達；開發系統的軟體工程師往往無法理解
不夠清晰明了：領域專家能夠很好的理解領域知識所以他們不願把領域需求表達得更加清晰明了
9． 使用者需求：
應該描述功能性和非功能性需求，使得沒有具體的技術知識的系統使用者也能理解
使用者需求用自然語言、表和方塊圖定義
自然語言的問題：
不夠清楚：為了使得文件易讀，保證精確性是困難的
需求混亂： 功能性和非功能性需求會混在一起
需求合併：幾個不同的需求可能放在一起表達
10． 系統需求
比使用者需求更詳細的描述
作為系統設計的基礎
可以作為系統合同的一部分
系統需求可用結構化的自然語言、pdl或者格式化的語言來撰寫
11． 需求和設計：
自然語言的問題：
二義性：需求的讀者和作者必需對同一詞語有同樣的解釋。自然語言是做到這點比較困難，因為自然語言存在二義性。
隨意性太大：同一件事情可能在描述中用好幾種不同的方式講述.
模組化不夠：自然語言的結構不足以構建系統需求
改用結構化的語言描述
12． 需求文件
需求文件是對系統開發者要求的正式表述
應該包括系統定義和需求描述
不是設計文件，陳述的是系統應該做什麼而不是怎麼做。
13． ieee 需求標準
ppt6 需求工程過程
1． 共通的過程：需求匯出，需求分析，需求驗證，需求管理
2． 可行性研究
決定乙個建議的系統是否值得做
3． 匯出和分析
也叫需求匯出或者需求發現
相關的技術人員和客戶一起工作以發現應用領域、系統提供的服務、系統的執行限制
可能涉及終端使用者、管理者、維護工程師、領域專家等專案相關人員。
需求分析有三種活動
區分. 識別實體之間的結構關係
提取. 識別實體中的一般特性
發散. 識別看乙個問題的不同方式
4． 面向視點的需求匯出
專案相關人員不同的問題視點，這種多視點的分析是重要的，因為分析系統需求沒有單個正確的方式
過程模型：
視點識別：發現接收系統服務的視點，以及識別每個視點提供的服務
視點組織：組織相關的視點形成層次結構。通用的放在較高的層次。
視點文件：對被識別的視點和服務描述的精煉。
視點系統對映：將分析轉化為物件導向的設計
橢圓. 來自視點和交付給視點的資料
控制資訊從每個方框的頂部出入
資料從每個方框的右側出來
異常顯示在方框的底部
場景完成後預期的下乙個事件的名稱表示在乙個粗線框中
5． 用例
6． 序列圖：目錄管理的序列圖
序列圖中：方塊表示活動，橫向箭頭表示轉移，縱向直線表示時間
7． 需求的有效性驗證
證明系統中定義的需求是客戶真正想要的
需求錯誤的代價是很高的，所以有效性驗證非常重要
需求有效性驗證技術：
需求評審：對需求做系統性的手工分析
原型開發：用乙個可執行的系統模型來檢查需求。在第8章詳述
測試案例生成：檢查需求的易測性
自動一致性分析：檢查結構化需求描述的一致性
8． 需求管理過程包括規劃和變更管理
ppt7 系統模型
一系統建模
系統建模有助於分析者理解系統功能，模型可用來和客戶溝通
不同的模型從不同的角度來描述系統
從外部來看，是對系統上下文或系統環境建模
從行為來看，是對系統行為建模
從結構上看，是對系統的體系結構和系統處理的資料的結構建模
二系統模型型別
資料處理模型，說明資料在不同的階段如何被處理的。（資料流圖）
組成模型，說明系統中的實體是如何由其它實體組成的。（實體-關係圖）
體系結構模型，說明構成整個系統的主要子系統。（體系結構圖）
分類模型，說明實體間怎樣具有共同特性。（物件類/繼承關係圖）
激勵/響應模型，說明系統對事件的響應。（狀態轉換圖）
1． 上下文建模
上下文模型用來說明系統的邊界
更多課程資料請到大學課程網學習
軟體工程複習總結
1.軟體危機 指在計算機軟體的開發和維護過程中所遇到的一系列嚴重問題。產生軟體危機的原因 與軟體本身的特點有關 來自於軟體開發人員的弱點 2.軟體工程學的3要素 方法，工具，過程。3.軟體生命週期由軟體定義，軟體開發，執行維護三個時期組成。4.軟體定義時期的3個階段 問題定義，可行性研究，需求分析。...
軟體工程複習
一 考試複習範圍 1 軟體工程基本概念 基本原理 2 需求分析，結構化分析 物件導向分析，結構化分析建模 物件導向分析建模 3 軟體設計，結構化程式設計，概要設計 詳細設計 4 軟體測試 二 考試題型 單項選擇題 簡答題 綜合應用題 要求會畫 資料流圖 軟體結構圖 用例圖 類圖 n s盒圖 pad圖...
軟體工程複習
第1章軟體工程概述 1 軟體危機的典型表現 軟體危機是指在計算機軟體的開發和維護過程中所遇到的一系列嚴重問題。概括地說，軟體危機包含下述兩方面的問題 如何開發軟體，以滿足對軟體日益增長的需求 如何維護數量不斷膨脹的已有軟體。軟體危機典型表現 對軟體開發成本和進度的估計常常很不準確。使用者對 已完成的...