系統分析與設計考點

系統分析與設計

第一章 系統分析與設計入門

系統開發生命周期（System Development Life Cycle，SDLC）是指這樣的一個過程，包括： 了解資訊系統對業務需求的支援，設計系統、建構系統，以及把系統移交給使用者。

SDLC分為四個階段：計劃、分析、設計、實作。

- 計劃階段是了解為什麼要建立資訊系統和确定項目團隊将如何來開發它的基本過程，要确定系統的業務價值、進行可行性分析和制訂項目計劃。

- 分析階段說明此系統由誰來用、用作什麼、在哪裡用，以及什麼時候用這些問題，要提出分析政策、收集資訊和建構一組分析模型。

- 設計階段确定系統将如何運作，涉及硬體、軟體和網絡基礎設施，要完成實體設計、架構設計、界面設計、資料庫和文檔規格以及程式設計。

- 實作階段要建立、安裝和維護系統。

系統開發方法論是指以規範化方法實作SDLC，可分為以過程為中心的方法論、以資料為中心的方法論和面向對象方法論。

結構化設計：瀑布式開發、并行開發；

快速應用開發：階段性開發、原型開發、抛棄原型開發；

靈活開發：XP（極限程式設計）；

選擇方法論需要考慮的問題：

- 使用者需求的清晰度；

- 技術的熟悉程度；

- 系統複雜度；

- 系統可靠性；

- 短時間進度；

- 進度可見性；

系統分析員需要的技能類别：技術、 業務、分析、人際交往、管理和道德修養。

分析員分類：業務分析員、系統分析員、基礎設施分析員、變更管理分析員。

第二章 項目啟動

項目啟動：項目啟動是組織建立和評估新系統最初目标和預期的時間點。此過程的第一步是通過開發該系統的需求來确定系統的業務價值。下一步是由分析員進行可行性分析，確定項目在技術、組織、經濟上的可行性。如果可行，系統将會被準許，開始項目開發。

系統需求：系統需求是指描述建立系統的業務原因和系統預期帶來的價值的文檔。大多數包括五個元素：

- 項目發起者：發起項目的人或組織；

- 業務要求：發起項目的與業務相關的原因；

- 業務需求：系統所能提供的業務能力；

- 業務價值：系統将為組織建立的收益；

- 特殊問題：與系統實作以及項目決策有關的一些特殊方面或限制。

可行性分析：分析與所提議的系統的風險相關的内容，包括：

- 技術可行性：關注系統是否能被建立的問題。

- 經濟可行性：關注系統是否應該建立的問題，

- 組織可行性：評估系統将在多大程度上被使用者接受，以及如何融入到組織的日常運轉中。

技術可行性的主要内容：

- 使用者和分析員對應用的熟悉程度；

- 對技術的熟悉程度；

- 項目規模；

- 新系統與組織内現有技術的相容性；

經濟可行性分析的步驟：

1. 确定花費和收益。主要包括開發費用、操作費用、有形收益、無形收益等。

2. 給花費和收益指派。

3. 确定現金流。一般計算累計淨現金流，即到某年為止累計的所有收益與費用的差。

4. 确定投資回報率。投資回報率（ROI）指的是投資在項目上的錢所賺取的平均回報比率，計算方法為用項目的淨收益（總收益-總費用）除以總費用。

5. 确定平衡點。平衡點指的是公司從淨現金流中回收它對項目的原始投資所需要的年數。計算方法為（1）确定累計現金流的數字由負變正的年份n（2）（第n年的淨現金流 - 到第n年底累計的淨現金流） / 第n年的淨現金流 + n - 1。

6. 确定淨現值。現值考慮了金錢的時間價值。淨現值NPV = 現值總收益 - 現值總費用。如果NPV大于0，項目在經濟上就是可行的。

項目選擇：一旦可行性分析完成後，報告将與修訂過的系統需求一起交給審定委員會，由委員會來決定是否準許該項目、取消該項目或推遲決策。

第三章 項目管理

項目管理：項目管理就是計劃和控制待開發的系統，使其在特定時間範圍内，以最低的成本完成正确功能的過程。項目經理的主要職責就是管理衆多任務以及協調各個角色之間的關系。

項目管理的原理是在三個重要的要素之間進行權衡：系統大小、完成項目的時間、項目成本。

估算項目規模的方法：

1. 經驗法：用計劃階段花費的時間除以一個行業标準比例來推測整個項目所需的時間。

2. 功能點法：分為三步：（1）項目經理根據新系統需要的代碼行數估算系統大小。（2）把估算結果轉換成開發這個系統所需的人月數。（3）根據項目從開始到完成的月數制定估算時間表。

工作計劃：一個動态進度表，它會記錄跟蹤項目過程中所需完成的各種任務，并根據任務完成情況做出适當的調整。

工作計劃資訊可以使用甘特圖或PERT圖展示。甘特圖主要描述任務的持續時間，PERT圖主要描述任務的依賴關系。

關鍵路徑：從項目起始到項目結束過程中最長的路徑。

人員配備：包括确定項目需要多少人，每個項目成員的角色，為團隊設定一個彙報程式，根據項目的需要發揮每個人的特長。

項目協調活動：将有效的開發實踐放在合适的位置以及轉移風險。

協調項目活動的三種技術：

- 計算機輔助軟體工程（CASE）：一類自動控制軟體，能自動化所有或部分開發過程。

- 标準：項目團隊在開發過程中必須遵循的正式準則和方針。

- 文檔：包括整個SDLC過程中所有任務的詳細資訊，即項目曆史記錄。

第四章 需求确定

as-is system：目前系統，不一定是計算機操縱的。

to-be system：新系統，基于更新的需求。

需求：陳述系統必須要做的事或者系統必須具備的特征。業務需求解釋系統是做什麼的，系統需求描述系統應當如何運作。功能需求直接關系着要面對的過程或者它必須包含的資訊，非功能需求關系着系統必須具有的特性，比如性能和可用性。

分析階段需要建立需求定義、用例、過程模型、資料模型等可傳遞物。

需求分析的基本過程：

1. 了解現有系統；

2. 确定要改進的地方；

3. 開發新系統的需求；

需求分析技術：

- 業務過程自動化（BPA）：使用計算機技術做某些事情時保持基本的業務操作本質不變。問題分析和根本原因分析是兩種通用的BPA活動。

- 業務過程改進（BPI）：要做出一些改進，可以更好地利用技術帶來的新機會或模仿競争對手正在做的事情。時限分析、基于活動的代價和非正式基準是三種通用的BPI活動。

- 業務過程再工程（BPR）：改變組織運作的一些基本方式。結果分析、技術分析和活動消除是險種通用的BPR活動。

需求收集技術：

- 面談：與一個或多個人碰面并問他們問題。面談過程有5個基本步驟：選擇通路對象，設計面談問題，準備面談活動，進行面談，以及面談後續工作。

- 聯合應用開發（JAD）：讓項目團隊、使用者和管理人員一起工作來确定系統的需求。

- 問卷：用在需要調查大量的人所掌握的資訊和觀點的情況。

- 文檔分析：複查現有的檔案并檢查系統本身。

- 觀察：檢視過程如何被執行。

第五章 用例分析

用例：一個用例包含了構造部分過程模型所需的全部資訊，它以一種非正式的、簡單的方式來表達。一個用例有一個名稱、編号、重要性級别、概要描述、主要參與者、觸發事件、主要的輸入輸出和執行用例所需要的主要步驟清單。通過審查功能需求能夠确定用例。

第六章 過程模組化

資料流圖（Data Flow Diagram, DFD）是一種最為常用的過程模組化技術，它以圖形的方式描述系統業務流程以及系統内的資料傳遞。

資料流圖的基本元素：

- 過程：為特定業務原因而執行的活動或功能。每個過程至少有一個名稱（動名詞短語）、一個描述、一個編号、一個輸入資料流（沒有輸入不可能産生輸出）和一個輸出資料流（沒有輸出代表該過程什麼都沒有做）。

- 資料流：單個資料或是資訊的邏輯集合。每個資料流至少有一個名稱（名詞）、一個描述、以及開始于或結束于一個過程。

- 資料存儲：以某種方式存儲的資料集合。每個資料存儲至少有一個名稱（名詞）、一個編号、一個輸入資料流、一個輸出資料流。

- 外部實體：位于系統範圍之外但與系統産生互動的人、部門或其他系統。每個外部實體至少有一個名稱、一個描述。

DFD圖的層次結構一般分為上下文圖、0層DFD圖、1層DFD圖。

常見的DFD圖錯誤：

- 沒有過程移動的資料流（外部實體到外部實體、外部實體到資料存儲等）。

- 沒有輸入或輸出的資料存儲。

- 雙向移動的資料流。

- 沒有輸入或輸出的過程。

- 輸入和輸出的資料流名相同。

第七章 資料模組化

實體關系圖（Entity Relationship Diagram, ERD）是一幅顯示業務系統中資料建立、存儲和使用的圖。

實體關系圖的基本元素：

- 實體：資料模型中的基本構造子產品，是人物、地點、事件等類型的資料，代表擁有多個執行個體或事物的一類東西。

- 屬性：從實體中捕獲到的各種類型的資訊，通常會将實體名稱的某些形式作為字首銜接到屬性前，使其能清楚地表示它屬于哪個實體。一個或多個屬性可以作為辨別符，這些屬性可以唯一辨別實體中的執行個體。

- 關系：實體之間的關聯。關系有兩個屬性：基數和模态。基數指的是父執行個體對子執行個體的比例，可以是1：1、1：N、M：N。模态指的是子實體的一個執行個體能否在沒有相關父實體的執行個體的情況下存在。

建立實體關系圖的步驟：

1. 确定實體。

2. 為每個實體添加适當的屬性。

3. 繪制實體間的線條用于表示它們是如何互相關聯的。

實體類型：

- 獨立實體：可以在沒有其他實體幫助下存在的實體。這些實體都擁有由自身屬性建立的辨別符

- 依賴實體：子實體需要父實體的屬性去唯一辨別一個執行個體，這種情況下子實體被稱為依賴實體，它的辨別符最少由一個父實體的屬性表示。

- 關聯實體：為了幫助捕獲存在于另外兩個實體之間的關系的資訊。

規範化：

- 第一範式（1NF）：不包含重複的屬性。

- 第二範式（2NF）：滿足第一範式，且除辨別符外的屬性必須依賴整個辨別符，而不能是部分依賴。

- 第三範式（3NF）：滿足第二範式，且沒有屬性依賴非辨別符屬性（即不存在傳遞依賴）。

第八章 轉換到設計

設計活動的主要輸入：分析階段确定的需求。

設計階段最主要的可傳遞物：系統規格，包括實體過程模型、實體資料模型、架構設計、軟硬體規格、界面設計、資料存儲設計和程式設計。

建構系統的方法：

- 内部開發定制系統。優點：能夠靈活且有創造性地解決業務問題，能在公司内部建立技術性的和功能性的知識。缺點：消耗人工。

- 購買系統軟體包并配置它。優點：節約人工，更加高效。缺點：可能無法滿足所有需求，需要建立工作區來滿足。

- 外包。優點：節約人工。缺點：可能危及公司機密資訊，對将來發展不利。

影響擷取政策的因素：

- 業務需要：獨特的業務需要選擇内部開發；通用的業務需要選擇購買軟體包；非核心的業務需要選擇外包。

- 内部經驗：有功能性和技術性經驗選擇内部開發；有功能性經驗選擇購買軟體包；不存在經驗選擇外包。

- 項目技術：想要開發内部技術選擇内部開發，否則選擇購買軟體包或外包。

- 項目管理：内部開發需要較高的項目管理能力和被證明的方法論。否則應選擇購買軟體包或外包。

- 時間限制：如果時間是一個限制因素，那麼應當首先考慮購買軟體包。内部開發需要有較為靈活的時間限制。利用外包建立系統所需的時間取決于系統和外包商的資源。

選擇一個擷取政策的方法：可選矩陣通過列出若幹候選方法的可用資訊，使得各方法很容易進行比較，幫助項目團隊做出這個決定。需求建議書、資訊需求書、引用需求書都是收集有關可選方案的精确資訊的方法。此時，項目團隊會決定由誰來完成設計階段中的各個部分，以及使用哪個軟體包。

第九章 架構設計

軟體系統可劃分為四種基本功能：資料存儲、資料通路邏輯、應用邏輯、表示邏輯。有三種基本的架構能夠把這些功能配置設定到不同的計算機上：

- 基于伺服器的架構：伺服器完成所有的功能。

- 基于用戶端的架構：用戶端負責表示邏輯、應用邏輯和資料通路邏輯，伺服器負責資料存儲。

- C/S架構：用戶端負責表示邏輯，伺服器負責資料存儲和資料通路邏輯。其中，在瘦C/S架構中，伺服器執行應用邏輯；在胖C/S架構中，伺服器和用戶端共同負責應用邏輯。

兩層C/S架構中有兩組計算機：一個用戶端和一組伺服器。三層C/S架構中有三組計算機：用戶端、一組應用伺服器、一組資料庫伺服器。

選擇架構考慮的因素：

- 基礎設施費用。

- 開發工作量。

- 開發難度。

- 界面容量。

- 控制和安全性。

- 可擴充性。

架構設計：架構設計指定了架構的各個方面及其所使用的硬體和軟體的布局。

設計架構時需要考慮的四種重要的非功能需求：

- 操作性需求：指定了系統完成任務所需的操作環境及其随時間可能的改變，如技術環境、系統內建、可移植性和可維護性。

- 性能需求：中心是性能問題，如系統速度、容量、可用性與可靠性。

- 安全性需求：防止資訊系統崩潰和資料丢失的能力，如通路控制、加密與驗證、病毒控制等。

- 文化與政治需求：針對使用系統的不同國家所特有的需求（多語言、使用者制定、未聲明的術語和法律）。

硬體與軟體規格：硬體與軟體規格是用來描述需要什麼樣的硬體和軟體來支援應用的文檔。當建立文檔時，要列出需要用于支援系統的硬體。然後，盡可能詳細地對其進行描述，再記錄運作于每個硬體構件的軟體，和所有伴随的費用，如技能教育訓練、維護和延長保證以及許可協定。項目團隊與采購部門将一起工作來獲得硬體和軟體。

第十章 使用者界面設計

使用者界面設計原則：

- 布局：為不同目的而使用的螢幕和文檔的組織區域。使用者界面設計的首要元素是螢幕、表格或報表的布局，它通常通過矩形描述，而且其頂部用于導航，中間區域用于輸入和輸出，而底部是狀态欄。

- 内容提示：界面使使用者通過最小努力了解它包含的資訊的能力。

- 審美學：設計賞心悅目的界面。

- 使用者經驗：設計使用者界面時，要考慮到使用者的計算機水準。大多數界面應該被設計來支援新手/初學者使用者和有經驗的使用者。

- 一緻性：通常涉及一個計算機系統的界面，以便于同一個系統的所有部分都以相同方式工作。

- 使使用者投入最小化：所有界面都應該要友善使用者，例如通過隻需不多于3次的點選就能從主菜單到達執行操作。

使用者界面設計過程：

1. 使用場景開發：描述了使用者執行操作的普遍使用模式。

2. 界面結構設計：建立對界面基本結構進行定義的界面結構圖（Interface Structure Diagram, ISD），顯示系統所有界面以及它們之間是如何連接配接的。

3. 界面标準設計：界面标準是跨越系統中所有螢幕、表格和報表的基本設計元素。

4. 界面設計原型：界面設計原型是一個實體模型或是對計算機螢幕、表格或報告的模拟。常用的方法有故事版、HTML原型和語言原型。

5. 界面評估：目标是了解如何改進界面設計。有啟發式評估、走查式評估、互動式評估、正式可用性測試等方法。

導航設計的首要原則：錯誤預防、簡化錯誤恢複、使用一緻的文法順序。

導航控制的類型：代碼、菜單、直接操作。

消息：系統響應使用者以及通知其關于互動狀态的一種方式。常見的消息類型有錯誤消息、确認消息、确定消息、延遲消息和幫助消息。

輸入設計：輸入設計的目标是簡單并輕松地為系統捕獲精确的資訊，基本原則有恰當地使用線上式和批處理，捕獲源頭資料和最少化擊鍵。

輸出設計：輸出設計的目标是把資訊呈現給使用者以便他們能毫不費力地準确了解它，基本原則有了解報表用法、管理資訊負荷量、歧視最小化。

第十一章 程式設計

結構圖：結構圖包括所有的在程式高層必須包含的功能構件，它們被排列在一個圖裡面，其排列順序代表構件之間的指令和控制關系。

有兩種基本的排列或結構方式将結構圖中的子產品連接配接起來：

- 事務結構：包括一個控制子產品，它調用可執行獨立任務的下屬子產品。少量傳入，大量傳出。

- 轉換結構：通過一系列下屬子產品将輸入轉變成輸出，而控制子產品描述轉換的發生。大量傳入，少量傳出。

建立結構圖的步驟：

1. 确定高層子產品，然後分解成較低的層次。

2. 在子產品間添加控制連接配接（如循環、條件等連接配接）。

3. 在子產品間添加耦合，子產品間可以互相傳送資訊。

4. 複查結構圖，直到沒有問題産生為止。

結構圖設計原則：

- 第一，建構高内聚的子產品，這樣每個子產品隻執行一個功能。

- 第二，子產品不應該是互相依賴的而應是松耦合的，子產品間應該用好的耦合方式連接配接起來。

- 最後，結構圖應該顯示高扇入低扇出，說明一個子產品應該有多個控制子產品，以及較少的下屬子產品。

程式規格：分析員對獨立的子產品進行的較長的描述，包括程式資訊、事件、輸入輸出、僞代碼。

第十二章 資料存儲設計

資料存儲格式的兩種基本類型：檔案和資料庫。

檔案是被優化以執行某一特定處理事務的資料電子序列，種類：

- 主檔案：儲存重要的業務資訊。

- 查找檔案：包含用于驗證主檔案字段的靜态值。

- 事務檔案：臨時存儲那些用于主檔案修改的資訊。

- 審計檔案：存儲在資料發生改變時記錄之前和之後的資料特征，以便當資料的整體性被質疑時可進行審計。

- 曆史檔案：存儲已經完成的、系統已不需要的處理事務。

資料庫是對在某一方面互相關聯的資訊組的集合，而資料庫管理系統（DBMS）是建立和操作這些資料庫的軟體。種類：

- 遺留資料庫：使用陳舊的、可能已經過時的技術，不會被用于開發新系統。

- 關系資料庫：基于表的集合。能高效地支援簡單類型。

- 面向對象資料庫：包含用對象類所表示的資料和過程。适合存儲複雜資料。

- 多元資料庫：将預算的數量資訊存儲在次元的交叉點上。适合存儲聚集的量化資訊。

優化關系型資料庫的兩個主要次元：

- 存儲效率的次元。規範化，去除備援資料。

- 通路速度的次元。去規範化。将備援資料重新放回。

除此之外，還可以通過聚類（将相似記錄存儲在鄰近存儲媒體上）以及建立索引（一張小型表，直接指向某些比對查詢要求的記錄）來提高速度。

第十三章 轉換到實作

管理程式設計的幾項任務：

- 管理程式設計過程：包括配置設定程式設計任務、協調各個活動、管理程式設計進度。

- 測試：包括編寫測試計劃、單元測試（確定單個程式或子產品按照預定的程式規格完成其功能）、內建測試（評估一組子產品或程式能否準确無誤地運作）、系統測試（確定所有的程式和子產品可以準确無誤地執行）、驗收測試（确定系統已經完成，并且系統的開發完全符合其業務需求，包括alpha測試（使用準備好的資料）與beta測試（使用真實資料））。

- 文檔開發：包括系統文檔（幫助程式員和系統分析員更好地了解應用軟體、開發系統、維護系統，一般在開發前建立）與使用者文檔（幫助使用者作業系統，一般在開發過程中建立）。

使用者文檔包括三種：

- 參考文檔：當使用者想要學習如何執行一個指定功能時使用。

- 程式手冊：說明怎麼樣去執行業務任務。

- 使用者指南：教給使用者如何使用系統的主要構件。

第十四章 實施到新系統的轉換

變更是一個分為三步的過程：解凍、變革和再當機。

選擇轉換政策需要考慮的因素：

- 轉換類型：分直接轉換、并行轉換。

- 轉換位置：分引導轉換、階段轉換、同時轉換。

- 轉換子產品：分整個系統轉換、子產品化轉換。

實作後活動：實作後活動的目的是使新系統的使用制度化，即使它成為完成業務過程正規的、可接受的和正常的方式。

三個關鍵的實作後活動：支援（在使用系統時提供援助）、維護（繼續精煉和改進系統）和項目評估（分析項目以了解哪些活動得到了很好的執行，應該重複使用，哪些活動應當在将來項目中改進）。

第十五章 對象基礎

類是用來定義和建立特定執行個體或者對象的通用模闆。

對象是一個類的執行個體，每個對象有描述關于此對象資訊的屬性。

方法實作一個對象的行為。

封裝：把過程和資料合并成一個完整實體（對象）。

資訊隐藏：隻公開使用一個軟體子產品所需要的資訊給子產品的使用者。

多态：不同的對象類可以對同樣的資訊做不同的解釋。

動态綁定：将對象的類型确定延遲到運作時間的一種技術。

用任何一個面向對象開發方法來開發系統必須：（1）用例驅動（2）以架構為中心（3）疊代和增量。

四種基本的UML圖：用例圖、類圖、時序圖、行為狀态機圖。

用例圖用來說明系統主要功能以及不同與之互動的使用者。

用例圖基本元素：

- 參與者：一個人或與其他系統互動并能從中得到利益的系統。

- 用例：系統将要執行的，會用某種方式給一個參與者帶來利益的主要過程。

- 關聯關系：用例通過關聯關系與參與者連接配接在一起，用來顯示參與者與哪些用例互動。

- 系統邊界：用例被包含在系統邊界内，劃分了圖中哪些屬于系統内部，哪些屬于系統外部。

建立用例圖的步驟：

1. 确定用例。

2. 畫出系統邊界。

3. 放用例在圖上。

4. 确定參與者。

5. 添加關聯關系。

類圖顯示了系統中不随時間而變的類和這些類之間的關系。

類圖基本元素：

- 類：存儲和管理系統中的資訊。包括屬性清單和方法清單，可見性包括public(+)、protected(#)、private(-)。方法類型有Constructor（建立對象執行個體）、query（擷取資訊）、update（修改資訊）三種。

- 關聯：表示類與類之間的關聯。可以添加基數表示數量，可以添加小實心三角表示關聯的方向性。

- 泛化和聚合：泛化指一個類繼承另一個類。用指向父類的空心箭頭表示。聚合指一個類實際由其他類組合而成，聚合類一端有個菱形，同時與它的各個部分用直線相連。

建立類圖的步驟：

1. 确定類。

2. 确定屬性和方法。

3. 建立類之間的關聯。

時序圖是一個動态模型，用來示範參與用例中的類的執行個體和它們之間所傳遞的消息。

時序圖基本元素：

- 參與者：處于系統外部且從系統中獲益的人或系統。

- 對象：通過收發消息參與到序列中。

- 生命線：表示對象在序列中的生命周期。

- 控制焦點：穿插于生命線中間的扁長的矩形，辨別對象何時發送或者接收消息。

- 消息：在一個對象和另一個對象間傳遞的消息。

- 對象銷毀：當對象需要銷毀時，在其生命線的末端會用一個X加以标記。

行為狀态機圖顯示了某個類的執行個體在其不同生命周期的狀态，它會因對象響應事件而發生改變。

行為狀态機圖基本元素：

- 狀态：描述某個特定時間點的對象的值的集合，它描繪了對象生命周期内滿足特定條件、執行某些動作、或等待事務發生的點。狀态用圓角矩形表示，初始狀态用實心圓表示，最終狀态用一個套着實心圓的圓表示。

- 事件：觸發狀态改變的事情。寫在轉換箭頭上面。

- 轉換：表示對象從一個狀态轉變到另一個狀态。