物件導向分析和設計 續一

第二部分

一、

1．

是up和大多數其他現代方法中的關鍵實踐。

2．在這種生命週期方法中，開發被組織成一系列固定的短期（如三星期）小專案，稱為迭代。每次迭代都產生經過測試、整合並可執行的區域性系統。每次迭代都具有各自的需求分析、設計、實現和測試活動。

3．迭代的輸出不是實驗性的或將丟棄的原型，迭代開發也不是構造原型。與之相反，其輸出是最終系統的產品子集。

4．迭代開發的策略：第一次迭代用於一些核心功能，後續迭代擴充套件這些功能。

二、

1．

在應付專案開發過程中的變更，迭代開發與傳統式的瀑布方式有根本的區別。瀑布式過程是在實現之前，企圖全面和正確的規格化、凍結，以及「簽署」需求集和設計，以此與軟體開發中不可避免的變更進行抗爭。與其相反，迭代和進化式開發抱以接受變更和改寫的態度，並以此為真正本質的驅動力。

2．提倡瀑布方式一般源於推測和風聞，而非實踐證實。與之相反，迭代和進化式開發為實際證據所支援，研究表明其失敗的機率更小，與更理想的生產率和缺陷率相關。

3．整個迭代進化式開發是乙個**收斂的過程。早期迭代遠離系統的「真實路徑」。通過反饋和調整，系統向最適宜的需求和設計收斂。在後期的迭代中，很少會在需求上產生顯著變化，但是存在這種可能性。這種後期的變化可能會給組織帶來業務競爭優勢。

三、

1．

敏捷開發方法通常應用時間定量的迭代和進化式開發、使用自適應計畫、提倡增量交付幷包含其他提倡敏捷性的價值和實踐。 2．

敏捷建模的關鍵：建模（畫

uml圖

……）的目的是為了理解，而非文件化。

3．多使用

uml草圖的快照。

第三部分

初始階段是建立專案共同設想和基本範圍的比較簡短的起始步驟。

一、

1．

初始階段的目標並不是完成所有需求或產生可信的預算或專案計畫。

2．初始階段是預見專案的範圍、設想和業務案例。解決涉眾是否就專案設想基本達成一致，專案是否值得繼續進行認真研究。

二、

1．

一般不超過一周。如果預先就決定專案必須進行，那麼時間會更短暫。這時候，初始階段可能只包含第一次需求研討會，並為第一次迭代制定計畫，然後快速進入細化階段。

2．初始階段更關注對基本範圍的理解以及

10%的需求，這主要是以文字表達。

第四部分

一、

1．

需求就是專案必須提供的能力和必須遵從的條件。

2．需求分析的最大挑戰就是尋找、溝通和記錄什麼是真正的需要的，並能夠清楚地講解給客戶和開發團體的成員。

二、

1．

瀑布式需求

l信任全面的，早期的需求對專案的功效。

l實際上，單一的瀑布式實踐是導致專案失敗的最大因素

l實際上，

65%的瀑布式定義的特性的作用是很小或無用的。

2．進化式需求

l統計表明，在整個專案過程中，平均有

25%的需求是變化的。

l歡迎需求的變更，作為專案的基本驅動力。

l在大部分的需求被分析和定義前就開始進行程式設計和測試。

三、

).

1．功能性

(functional)

：特性、功能、安全性。

2．可用性

(usability)

：人性化因素、幫助、文件。

3．可靠性

(reliability)

：故障頻率、可恢復性、可**性。

4．效能

(performance)

：響應時間、吞吐量、準確性、有效性、資源利用率。

5．可支援性

(supportability)

：適應性、可維護性、國際化、可配置性。

四、

1．

用例模型：一組使用專案的典型場景。主要用於功能（行為的）需求。（重點）

2．補充性規格說明

3．詞彙表

4．設想

5．業務規則

物件導向分析和設計

物件導向分析和設計 第一部分 概述及簡介 一 什麼是物件導向分析和設計 ooad ooad 的實質就是從物件的角度來考慮問題領域及邏輯解決方案。ooa 注重於發現和描述物件。ood 注重於定義邏輯軟體物件。物件導向和面向功能的區別 以圖書館資訊系統為例。二 ooad 的主要過程 三 乙個簡單的 oo...

物件導向分析和設計

側重於現實生活中那些語義被應用程式獲取的事物，在需求分析中所構造的物件說明了現實世界系統的靜態結構並將其組織為可用的片段 處理應用系統中使用者可見的計算機問題，所分析的物件可能會被預計時不時地發生較快的變化 用於分析如何滿足系統功能性需求的模型 狀態模型 表達系統的詳細需求，為軟體的進一步分析和設計...

物件導向分析設計

1.物件導向的分析與設計方法與結構化的分析設計方法有什麼不同？結構化設計是面向過程設計，是從計算機處理問題的角度來工作 即 輸入 運算 輸出 的模式。是過程驅動 物件導向的分析設計是以物件為單位，考慮物件的屬性和方法，分析問題時以乙個具體的流程 事務過程 為單位，考慮它的實現。是用例驅動 2.物件導...