系統分析與設計 - 快速指南

---

---

系統分析與設計 - 概述

系統開發是一個系統化的過程，包括規劃、分析、設計、部署和維護等階段。在本教程中，我們將主要關注：

• 系統分析
• 系統設計

系統分析

這是一個收集和解釋事實、識別問題並將系統分解成其組成部分的過程。

進行系統分析的目的是為了研究系統或其部分，以識別其目標。這是一種解決問題的技術，可以改進系統並確保系統的所有元件都能高效地工作以實現其目標。

分析指定了系統應該做什麼。

系統設計

這是一個規劃新的業務系統或替換現有系統，透過定義其元件或模組以滿足特定需求的過程。在規劃之前，您需要徹底瞭解舊系統，並確定如何最好地使用計算機以有效地執行。

系統設計側重於如何實現系統目標。

系統分析與設計 (SAD) 主要關注：

• 系統
• 流程
• 技術

什麼是系統？

“系統”一詞源於希臘語“Systema”，意思是任何一組元件為了實現某種共同目標而建立的有組織的關係。

系統是“根據計劃將相互依賴的元件有序地組合在一起以實現特定目標”。

系統的約束

系統必須具有三個基本約束：

• 系統必須具有一定的結構和行為，這些結構和行為旨在實現預定義的目標。

• 系統元件之間必須存在互連性和相互依賴性。

• 組織的目標比其子系統的目標具有更高的優先順序。

例如，交通管理系統、工資系統、自動圖書館系統、人力資源資訊系統。

系統的屬性

系統具有以下屬性：

組織性

組織性意味著結構和秩序。它是元件的排列，有助於實現預定的目標。

互動性

它由元件彼此之間執行的方式定義。

例如，在一個組織中，採購部門必須與生產部門互動，工資部門與人事部門互動。

相互依賴性

相互依賴性意味著系統的元件如何相互依賴。為了正常執行，元件根據特定計劃進行協調和連結。一個子系統的輸出是另一個子系統所需輸入。

整合性

整合性關注的是系統元件如何連線在一起。這意味著即使每個部分執行獨特的函式，系統各部分也在系統內一起工作。

中心目標

系統的目標必須是中心的。它可能是真實的或陳述的。一個組織宣告一個目標並運作以實現另一個目標的情況並不少見。

為了成功地設計和轉換，使用者必須儘早瞭解計算機應用程式的主要目標。

系統的要素

下圖顯示了系統的要素：

輸出和輸入

• 系統的首要目標是產生對使用者有用的輸出。

• 輸入是進入系統進行處理的資訊。

• 輸出是處理的結果。

處理器

• 處理器是系統中將輸入實際轉換為輸出的要素。

• 它是系統的操作元件。根據輸出規範，處理器可以完全或部分地修改輸入。

• 隨著輸出規範的變化，處理也會發生變化。在某些情況下，輸入也會被修改以使處理器能夠處理轉換。

控制

• 控制元素引導系統。

• 它是控制輸入、處理和輸出活動模式的決策子系統。

• 計算機系統的行為由作業系統和軟體控制。為了保持系統的平衡，輸出規範決定了需要什麼和多少輸入。

反饋

• 反饋在動態系統中提供控制。

• 正反饋是常規性質的，它鼓勵系統的效能。

• 負反饋是資訊性質的，它為控制器提供行動資訊。

環境

• 環境是組織執行的“超系統”。

• 它是影響系統的外部元素的來源。

• 它決定了系統必須如何執行。例如，組織環境中的供應商和競爭對手可能會提供影響業務實際績效的約束。

邊界和介面

• 系統應由其邊界定義。邊界是識別其元件、流程和與其他系統介面時的相互關係的限制。

• 瞭解給定系統的邊界對於確定其與其他系統的介面性質以成功設計至關重要。

• 瞭解給定系統的邊界對於確定其與其他系統的介面性質以成功設計至關重要。

系統的型別

系統可以分為以下型別：

物理系統或抽象系統

• 物理系統是有形的實體。我們可以觸控和感受它們。

• 物理系統可以是靜態的，也可以是動態的。例如，桌子和椅子是計算機中心的物理部分，它們是靜態的。程式化的計算機是一個動態系統，其中的程式、資料和應用程式可以根據使用者的需求而改變。

• 抽象系統是非物理實體或概念，可能是真實系統的公式、表示或模型。

開放系統或封閉系統

• 開放系統必須與其環境互動。它接收來自系統外部的輸入並向系統外部提供輸出。例如，必須適應不斷變化的環境條件的資訊系統。

• 封閉系統不與其環境互動。它與環境影響隔離開來。在現實中，完全封閉的系統很少見。

自適應系統和非自適應系統

• 自適應系統以改進其效能和生存的方式響應環境變化。例如，人類、動物。

• 非自適應系統是不響應環境的系統。例如，機器。

永久系統或臨時系統

• 永久系統持續很長時間。例如，商業政策。

• 臨時系統是為特定時間建立的，之後它們會被拆除。例如，DJ系統是為一個節目設定的，節目結束後會拆除。

自然系統和人造系統

• 自然系統是由自然創造的。例如，太陽系，季節系統。

• 人造系統是人造系統。例如，火箭、水壩、火車。

確定性系統或機率性系統

• 確定性系統以可預測的方式執行，並且系統元件之間的互動是可以確定的。例如，兩個氫分子和一個氧分子構成水。

• 機率性系統表現出不確定的行為。確切的輸出是未知的。例如，天氣預報，郵件遞送。

社會系統、人機系統、機器系統

• 社會系統由人組成。例如，社交俱樂部，社團。

• 在人機系統中，人和機器都參與執行特定任務。例如，計算機程式設計。

• 機器系統是忽略人為干預的系統。所有任務都由機器執行。例如，自主機器人。

人造資訊系統

• 它是一個相互連線的資訊資源集，用於在直接管理控制 (DMC) 下管理特定組織的資料。

• 該系統包括硬體、軟體、通訊、資料和應用程式，用於根據組織的需求生成資訊。

  人造資訊系統分為三種類型：

• 正式資訊系統 - 它基於資訊以備忘錄、指示等形式從管理層到下層管理層的流動。

• 非正式資訊系統 - 這是以員工為基礎的系統，用於解決日常工作相關問題。

• 計算機系統 - 此係統直接依賴於計算機來管理業務應用程式。例如，自動圖書館系統、鐵路訂票系統、銀行系統等。

系統模型

示意圖模型

• 示意圖模型是一個二維圖表，顯示系統元素及其連結。

• 不同的箭頭用於顯示資訊流、物質流和資訊反饋。

流程系統模型

• 流程系統模型顯示了將系統結合在一起的物質、能量和資訊的規律流動。

• 例如，程式評估和審查技術 (PERT) 用於以模型形式抽象現實世界系統。

靜態系統模型

• 它們表示一對關係，例如活動-時間或成本-數量。

• 例如，甘特圖提供了活動-時間關係的靜態圖。

動態系統模型

• 商業組織是動態系統。動態模型近似於分析師處理的組織或應用程式型別。

• 它顯示了系統的持續、不斷變化的狀態。它包括：

  • 進入系統的輸入

  • 發生轉換的處理器

  • 處理所需的程式

  • 處理後產生的輸出。

資訊類別

與管理級別和管理者決策相關的，有三類資訊。

戰略資訊

• 此類資訊由最高管理層用於制定未來幾年的長期規劃政策。例如，收入趨勢、金融投資、人力資源和人口增長。

• 此類資訊藉助決策支援系統 (DSS) 獲得。

管理資訊

• 此類資訊由中層管理人員用於短期和中期規劃，以月為單位。例如，銷售分析、現金流預測和年度財務報表。

• 它藉助管理資訊系統 (MIS) 獲得。

運營資訊

• 此類資訊由低層管理人員用於日常和短期規劃，以執行日常運營活動。例如，維護員工考勤記錄、逾期採購訂單和當前可用庫存。

• 它藉助資料處理系統 (DPS) 獲得。

系統分析和系統設計之間的區別

引言

系統分析和系統設計是軟體系統開發生命週期中的兩個關鍵階段。雖然它們經常被互換使用，但它們具有不同的目的，並涉及不同的方法。本文將深入探討系統分析和系統設計之間的關鍵區別、它們在開發過程中的作用以及每個階段使用的技術。

系統分析

系統分析是軟體開發專案的初始階段，在這個階段，系統的需求被收集、分析和記錄。它涉及理解問題領域、識別利益相關者以及定義系統的範圍和目標。

系統分析中的關鍵活動

• 需求收集− 確定使用者和利益相關者的需求和期望。

• 需求分析− 分析收集到的需求，以確保其一致性、可行性和完整性。

• 可行性研究− 評估擬議系統的技術、經濟和運營可行性。

• 流程建模− 建立圖表和模型來表示當前和擬議的業務流程。

• 資料建模− 定義系統中的資料實體、屬性和關係。

系統分析中使用的技術

• 訪談− 透過面對面或線上訪談收集利益相關者的資訊。

• 調查− 使用問卷從大量受訪者那裡收集資料。

• 觀察− 觀察當前系統執行情況，以瞭解其流程和工作流程。

• 文件分析− 檢查現有的文件、報告和手冊。

• 原型設計− 建立系統的簡化模型或模型，以收集反饋並改進需求。

系統設計

系統設計是後續階段，在這個階段，系統的詳細規範被制定。它涉及設計體系結構、元件、介面和資料結構，以實現分析階段中定義的需求。

系統設計中的關鍵活動

• 體系結構設計− 確定系統的整體結構和元件。

• 元件設計− 設計各個元件及其互動。

• 介面設計− 指定元件之間以及與外部系統之間的介面。

• 資料設計− 設計資料庫模式和資料結構。

• 詳細設計− 為每個元件建立詳細規範，包括演算法和資料流。

系統設計中使用的技術

• 統一建模語言 (UML)− 一種標準化的建模語言，用於視覺化、規範、構建和記錄軟體系統。

• 資料流圖 (DFD)− 說明資料流經系統的圖表。

• 實體關係圖 (ERD)− 表示資料庫中實體及其之間關係的圖表。

• 決策樹− 顯示流程中可能的結果和決策的圖表。

• 狀態轉換圖− 表示系統可以處於的不同狀態以及它們之間轉換的圖表。

系統分析和系統設計之間的關鍵區別

系統分析和系統設計之間的關係

系統分析和系統設計緊密相連。分析階段的輸出（需求文件）作為設計階段的輸入。設計規範必須與需求一致，以確保開發的系統滿足使用者和利益相關者的需求。

結論

系統分析和系統設計是軟體系統開發中必不可少的階段。雖然它們具有不同的作用和方法，但它們共同努力以確保最終產品滿足所需的需求併為使用者創造價值。透過有效地進行系統分析和設計，組織可以開發高質量、高效且使用者友好的軟體系統。

系統分析與設計 - 通訊協議

本文涵蓋了不同層次的通訊、關鍵協議及其實際意義。

引言

有效的通訊在現代網路系統中至關重要，因為它確保了不同裝置、應用程式和服務之間無縫的互動。通訊協議作為標準化的規則集，能夠在這些系統中實現互操作性、可靠性和安全性。從早期的電報到現代的網際網路通訊，協議已經發展到滿足不斷增長的資料交換和複雜應用程式的需求。

本文探討了通訊的概念以及管理資料傳輸的各種型別的協議，重點關注這些協議在當今數字領域的意義。

通訊概述

從技術角度來看，通訊是指兩個或多個系統之間的資料交換，無論是在本地還是透過網路。為了促進這種交換，必須遵守特定的規則，以確保傳送方和接收方能夠相互理解。這包括資料格式、傳輸方法和錯誤檢查。

通訊型別

同步與非同步通訊−

• 同步− 資料即時傳送和接收（例如即時視訊會議）。

• 非同步− 資料可以獨立傳送和處理（例如電子郵件、訊息）。

單播、廣播和組播通訊−

• 單播− 一對一通訊（例如客戶端-伺服器請求）。

• 廣播− 一對多通訊（例如電視廣播、乙太網資料）。

• 組播− 一對選定多（例如，與選定參與者的視訊會議）。

半雙工和全雙工通訊−

• 半雙工− 一次在一個方向上進行資料傳輸（例如對講機）。

• 全雙工− 同時傳輸和接收（例如電話）。

協議：通訊的支柱

協議是一組規則，定義瞭如何在網路之間傳輸和接收資料。它規定了通訊的各個方面，從資料的格式到確保其交付的機制。協議在各個層次上執行，每個層次都針對網路中的特定功能。

協議的重要性

• 標準化− 協議確保來自不同製造商和環境的裝置可以通訊。

• 可靠性− 協議包含錯誤檢查和糾正機制。

• 互操作性− 它們允許具有不同架構的系統進行通訊。

• 效率− 透過將資料組織成資料包或幀來有效地傳輸資料。

OSI 模型：分層方法

為了理解通訊中使用的不同協議，我們需要探索開放系統互連 (OSI) 模型，它提供了一個分為七層的網路通訊框架。

• 物理層− 處理資料的物理傳輸（例如電纜、交換機）。

• 資料鏈路層− 管理直接連線節點之間的資料傳輸（例如 MAC 地址、乙太網）。

• 網路層− 處理跨網路的資料路由（例如 IP）。

• 傳輸層− 提供錯誤檢查並保證資料交付（例如 TCP）。

• 會話層− 管理應用程式之間的會話（例如，建立和終止連線）。

• 表示層− 將資料轉換為應用程式層所需格式（例如加密、壓縮）。

• 應用層− 與終端使用者應用程式互動（例如 HTTP、FTP）。

OSI 模型中的每一層都有自己的一套協議，每個協議都執行特定功能以促進通訊。

常用協議及其功能

傳輸層協議

• TCP（傳輸控制協議）− TCP 是面向連線的，透過在傳送方和接收方之間建立連線來確保資料可靠地傳輸。它使用錯誤檢查機制並確保資料按順序到達，這使其成為需要準確性的應用程式（例如 Web 瀏覽、電子郵件）的理想選擇。

• UDP（使用者資料報協議）− UDP 是無連線的，這使其比 TCP 更快。但是，它不能保證資料的交付，這使得它對於對時間敏感的應用程式（如流媒體）有用，在這些應用程式中，速度比完美的準確性更重要。

網際網路層協議

• IP（網際網路協議）− IP 負責定址和路由資料包，以確保它們到達正確的目的地。它在網路層執行，並使用地址來識別傳送方和接收方。

• IPv4 與 IPv6− IPv4 是使用最廣泛的版本，具有 32 位地址方案。IPv6 是 IPv4 的繼任者，使用 128 位地址來適應網際網路上不斷增長的裝置數量。

應用層協議

• HTTP/HTTPS− HTTP（超文字傳輸協議）是全球資訊網資料通訊的基礎。HTTPS 透過加密增加了一層安全性，這對於 Web 上的安全通訊至關重要。

• FTP（檔案傳輸協議）− 用於在計算機之間傳輸檔案。雖然廣泛使用，但它已被更安全的替代方案（如 SFTP 和 FTPS）所取代，這些替代方案包含加密。

• SMTP（簡單郵件傳輸協議）− 促進電子郵件的傳送。通常與 IMAP 或 POP 結合使用以從伺服器檢索電子郵件。

• DNS（域名系統）− 將人類可讀的域名（例如 www.example.com）轉換為計算機可以理解的 IP 地址。

無線協議

• Wi-Fi (IEEE 802.11)− 一套用於無線區域網 (WLAN) 的標準，使裝置能夠透過無線網路進行通訊。

• 藍牙− 用於裝置之間的短距離通訊，例如將無線耳機連線到手機。

安全協議：確保安全通訊

隨著網路威脅的增加，安全協議已成為維護資料完整性、機密性和身份驗證不可或缺的一部分。多個協議協同工作以保護傳輸中的資料。

• SSL/TLS（安全套接字層/傳輸層安全）− 這些協議透過加密資料來保護網路（尤其是網際網路）上的通訊。由於存在漏洞，SSL已被TLS取代。

• IPsec（網際網路協議安全）− 一套用於保護網際網路協議 (IP) 通訊的協議，透過對通訊會話中的每個 IP 資料包進行身份驗證和加密來實現。

• SSH（安全外殼）− 提供一種安全的方法，用於透過不安全的網路進行遠端登入和其他安全網路服務。

通訊協議的未來

隨著技術的不斷發展，對更快、更安全、更可靠的通訊協議的需求也在不斷增長。正在開發新的協議以適應新興技術，包括物聯網 (IoT)、5G 網路和量子計算。

• 5G 協議− 第五代行動網路承諾提供更快的傳輸速率、更低的延遲以及對物聯網裝置的更好支援，這需要新的協議，例如 5G-NR（新無線電）和 5GC（5G 核心網路）。

• 物聯網通訊協議− MQTT（訊息佇列遙測傳輸）和 CoAP（受限應用協議）等協議輕量級，非常適合物聯網裝置對低功耗和低頻寬的要求。

• 量子通訊協議− 隨著量子計算的發展，研究人員正在探索利用量子糾纏和疊加來建立安全通訊通道的新協議，這可能會徹底改變加密和網路安全。

結論

通訊和協議構成了現代網路的基礎，使裝置和系統能夠高效、可靠和安全地進行通訊。隨著技術的進步，管理資料交換的協議也在不斷發展，以適應更高的速度、增強的安全性和處理更多裝置的能力等新要求。未來充滿了令人興奮的前景，5G 和量子通訊等進步將重新定義我們對通訊協議的思考和使用方式。

系統設計中的水平和垂直擴充套件

引言

隨著應用程式和系統規模和複雜性的增長，確保它們保持高效和響應迅速成為一個關鍵挑戰。這導致了對可擴充套件性的討論，即系統處理增加的負載的能力。可擴充套件性可以透過兩種主要方法實現：水平擴充套件（橫向擴充套件）和垂直擴充套件（縱向擴充套件）。這兩種方法都有其獨特的優勢、挑戰和最佳使用案例。在本文中，我們將詳細探討水平和垂直擴充套件的概念，討論它們各自的架構、優點和侷限性，以及如何為特定場景選擇正確的擴充套件方法。

什麼是擴充套件？

在深入探討水平和垂直擴充套件的細節之前，瞭解擴充套件的含義至關重要。

擴充套件是指調整資源（例如計算能力、儲存或網路功能）的過程，以確保應用程式能夠處理不斷增長的需求，而不會犧牲效能。隨著系統規模的增長以及面臨更多使用者、更多事務或增加的資料吞吐量，擴充套件確保系統保持其效率，不會成為瓶頸。

擴充套件有兩種基本方法：垂直擴充套件和水平擴充套件。

垂直擴充套件（縱向擴充套件）

垂直擴充套件，或縱向擴充套件，是指透過向單個機器或伺服器新增更強大的資源來增強其容量。這些資源可能包括：

• 新增更多 CPU（中央處理器）。

• 增加 RAM（隨機存取儲存器）。

• 擴充套件儲存容量（SSD/HDD）。

• 增加網路頻寬容量。

從本質上講，垂直擴充套件是透過升級其元件或將其替換為更強大的版本來使單臺機器更強大。

垂直擴充套件

在垂直擴充套件中，應用程式繼續在同一臺物理機器上執行，但機器的功能得到了改進。例如，如果託管在伺服器上的應用程式由於請求數量增加而變慢，垂直擴充套件可能包括將該伺服器替換為更強大的伺服器（例如，從 16 核處理器升級到 32 核處理器）。

架構保持不變——仍然只有一臺機器或節點，儘管它功能更強大。

垂直擴充套件的優點

• 簡單性− 垂直擴充套件通常很簡單，因為它不需要對應用程式架構進行重大更改。您只需向現有伺服器新增更多資源。

• 降低複雜性− 管理單個伺服器降低了操作的複雜性，包括維護和監控。

• 一致性− 由於系統執行在一臺機器上，因此更容易維護資料一致性，尤其是在涉及資料庫的情況下，其中一致性保證至關重要。

• 適合單體應用程式− 單體應用程式緊密耦合，難以分解成更小的元件，它們可能受益於垂直擴充套件，因為整個應用程式執行在一臺機器上。

垂直擴充套件的侷限性

• 單點故障− 只有在一臺機器處理整個應用程式的情況下，它就成為單點故障。如果伺服器崩潰或面臨硬體問題，整個系統可能會崩潰。

• 資源限制− 最終，物理伺服器只能升級到一定程度。可以向單臺機器新增的 CPU、RAM 或儲存量是有限的。這個“上限”可能會限制長期可擴充套件性。

• 成本− 高階伺服器和元件價格昂貴。將伺服器升級到最先進的硬體選項可能會導致大量的預付成本。

• 升級期間的停機時間− 根據系統的情況，升級硬體（例如新增 RAM 或儲存）可能需要關閉伺服器，這會導致停機時間。在關鍵任務系統中，即使是短暫的停機時間也可能帶來問題。

水平擴充套件（橫向擴充套件）

水平擴充套件，或橫向擴充套件，是指向系統新增更多機器或節點，有效地將負載分配到多個裝置。它不是升級單臺機器的效能，而是向叢集新增更多機器來分擔負載。

水平擴充套件架構

在水平擴充套件中，架構設計用於分散式系統，其中多臺伺服器（或節點）協同工作以處理增加的負載。

例如，一個訪問量激增的網站可能會新增更多伺服器來處理額外的請求。通常會使用負載均衡器將流量均勻地分配到這些伺服器，確保沒有任何一臺機器過載。在分散式資料庫系統中，水平擴充套件意味著將資料劃分到多臺機器（分片）以處理更多事務或更大的資料集。

水平擴充套件的優點

• 理論上沒有限制− 水平擴充套件的最大優勢之一是理論上可以新增無限多的伺服器。隨著需求的增長，您可以繼續新增機器，從而提供無限的可擴充套件性。

• 容錯性− 由於涉及多臺機器，如果一個節點發生故障，系統可以使用剩餘的節點繼續執行。這種冗餘提供了更高的容錯性。

• 規模經濟− 與投資一臺高階機器相比，水平擴充套件允許使用許多低端機器。從長遠來看，這可能更經濟高效，尤其是在雲環境中，資源可以動態分配。

• 更適合雲和分散式應用程式− 水平擴充套件非常適合雲原生和分散式系統，例如微服務架構，其中應用程式的不同部分可以在不同的伺服器上獨立執行。

水平擴充套件的侷限性

• 複雜性增加− 管理多臺伺服器比管理一臺伺服器本身更復雜。它需要更復雜的工具來進行編排、監控和負載均衡。

• 資料一致性問題− 在分散式系統中，維護多個節點之間的資料一致性可能具有挑戰性，尤其是在需要強一致性的應用程式中（例如金融應用程式）。

• 網路開銷− 隨著伺服器數量的增加，節點之間的通訊也會增加，這可能會導致網路延遲和開銷。確保機器之間高效通訊成為一個關鍵問題。

• 擴充套件整個堆疊− 對於某些工作負載，水平擴充套件可能需要將整個應用程式堆疊（例如資料庫、快取和處理系統）設計為水平分佈，這可能需要大量的重構。

水平擴充套件與垂直擴充套件：比較

混合方法

在許多情況下，組織同時使用水平和垂直擴充套件。例如，他們可能首先使用垂直擴充套件來滿足最初的需求，然後隨著需求的增加轉向水平擴充套件。在 AWS 或 Google Cloud 等雲環境中，自動擴充套件功能允許公司根據負載無縫地在兩者之間切換。

有些系統還採用混合架構，對某些元件（例如資料庫）使用垂直擴充套件，而對其他元件（例如 Web 伺服器）使用水平擴充套件。這種混合方法可以兼顧兩者的優勢，但代價是增加了架構的複雜性。

何時選擇水平或垂直擴充套件

水平擴充套件和垂直擴充套件的選擇取決於幾個因素：

• 應用程式架構− 分散式系統或微服務自然適合水平擴充套件，而單體應用程式更容易垂直擴充套件。

• 預算− 在雲中，水平擴充套件可能更經濟高效，因為可以根據需要啟動額外的例項。垂直擴充套件由於昂貴的硬體而可能導致高成本。

• 一致性要求− 需要嚴格資料一致性的應用程式（例如銀行系統）可能更喜歡垂直擴充套件，因為資料管理更簡單。

• 預期增長− 如果您的應用程式預計會快速增長，則水平擴充套件可能更合適，因為它提供了理論上無限的可擴充套件性。

結論

水平擴充套件和垂直擴充套件都是系統架構中的關鍵概念，各有其獨特的優勢和挑戰。垂直擴充套件簡單易行，但受限於硬體限制，而水平擴充套件提供了幾乎無限的可擴充套件性，但代價是增加了複雜性。瞭解這些擴充套件方法的細微差別對於構建高效、可靠和可擴充套件的系統至關重要，尤其是在更多應用程式遷移到雲原生架構時。

選擇合適的擴充套件策略取決於應用程式的架構、預算和可擴充套件性需求等因素。在當今雲驅動的環境中，結合水平和垂直擴充套件優勢的混合方法可能提供最大的靈活性和成本效益。

系統設計中的容量估算

引言

容量估算是系統設計中至關重要的環節，它涉及預測處理預期工作負載所需資源的過程，例如伺服器容量、儲存、網路頻寬和資料庫效能。正確的估算可以防止系統瓶頸，降低運營成本，並確保流暢的使用者體驗。本文探討了容量估算中涉及的基本概念、估算方法、工具和注意事項，尤其是在大型分散式系統中。

理解容量估算

定義和重要性：將容量估算解釋為一種規劃策略，以確保系統能夠在不發生故障的情況下處理預期和峰值工作負載。

關鍵指標

• 吞吐量− 每秒事務數或每秒請求數。

• 延遲− 完成事務或請求所需的時間。

• 響應時間− 使用者等待響應的總時間。

• 負載和併發性− 併發使用者數或運算元。

• 利用率− 已使用容量的百分比。

• 業務影響− 概述過度配置的成本影響以及配置不足的風險。

容量估算中的基本概念

• 容量與效能− 區分容量（側重於服務數量，例如處理的請求數）和效能（強調服務質量，例如響應時間）。

• 可擴充套件性− 討論如何設計系統以水平擴充套件（新增更多例項）和垂直擴充套件（升級資源）。

• 系統瓶頸− 瓶頸型別（CPU、記憶體、I/O、網路）及其對容量的影響。

容量估算步驟

1. 定義需求− 確定預期工作負載、峰值流量和可用性需求。

2. 分析歷史資料− 使用歷史系統資料查詢模式並識別趨勢。

3. 系統建模−

   • 工作負載建模− 描述工作負載的型別和強度（例如，讀密集型與寫密集型操作）。

   • 資源消耗建模− 量化每個工作負載的資源使用情況（CPU、記憶體、磁碟I/O）。

   • 併發性和擴充套件因子− 包括併發性因素，並檢查每個資源如何受到影響。

4. 進行負載測試− 執行壓力和負載測試以驗證模型並識別瓶頸。

5. 估算增長− 根據業務預期預測工作負載增長。

6. 配置資源− 計算專案容量所需的資源，並考慮峰值使用情況的裕度。

容量估算技術

分析技術

• 排隊論− 用於預測不同負載條件下的效能。

• Little’s Law（利特爾定律）− 應用於穩態系統，用於估算到達率、吞吐量和響應時間之間的關係。

經驗技術

• 負載測試− 模擬真實世界負載以確定最大處理容量。

• 模擬建模− 建立系統的虛擬模型以分析資源利用率和流量模式。

• 預測技術−

  • 機器學習模型− 利用歷史資料和預測模型來預測容量。

  • 時間序列分析− 分析過去的工作負載模式以預測未來的需求趨勢。

容量估算工具

負載測試工具

• Apache JMeter− 用於模擬網路負載和測試系統性能。

• Gatling− 一個用於 Web 應用程式的高效能負載測試工具。

監控和分析工具

• Prometheus & Grafana− 用於監控、警報和視覺化即時指標。

• Datadog− 提供效能監控，並針對資源閾值提供即時警報。

容量規劃和預測工具

• Amazon CloudWatch− 提供監控和自動擴充套件建議。

• Google Stackdriver− GCP 的監控和日誌記錄，具有基於資源的容量規劃。

• 自定義解決方案− 構建自定義指令碼和工具來收集、分析和預測特定於系統需求的資料。

容量估算中的挑戰

• 需求不確定性− 需求變化和不可預測的峰值。

• 不斷變化的系統架構− 基礎設施或軟體更改時的挑戰。

• 分散式系統複雜性− 在跨區域或資料中心擴充套件分散式系統時的複雜性增加。

• 資源依賴性− 資源之間複雜的相互依賴關係可能導致瓶頸或擴充套件問題。

• 成本效益平衡− 在成本考慮與所需的效能水平之間取得平衡。

有效容量估算的最佳實踐

• 定期進行容量審查− 根據不斷變化的工作負載，定期審查和更新容量計劃。

• 利用自動化− 實施用於負載測試、監控和擴充套件的自動化工具。

• 構建冗餘− 設計具有故障轉移和冗餘的系統，以避免單點故障。

• 監控和警報− 為關鍵指標設定警報，以便及早發現瓶頸。

• 與利益相關者合作− 使容量計劃與業務目標、預算限制和預期增長保持一致。

結論

容量估算是系統設計中主動採取的一步，它確保了成本、效能和使用者滿意度之間的平衡。透過理解核心概念、採用有效的估算技術和使用正確的工具，系統架構師可以預測容量需求並構建健壯、可擴充套件的系統。容量估算是一個持續進行的過程，如果做得正確，可以節省成本，提高效能並最佳化使用者體驗。

Web伺服器和代理在系統設計中的作用

本文介紹了在準備系統設計和架構時 Web 伺服器和代理的角色。

瞭解 Web 伺服器

定義

Web 伺服器是透過網際網路向客戶端提供 Web 內容的軟體或硬體。

功能

• 處理 HTTP 請求和響應。

• 儲存和提供靜態內容（HTML、CSS、JavaScript）。

• 執行動態應用程式（例如，透過 CGI、PHP 或 Spring Boot 等框架）。

Web 伺服器示例

• Apache Tomcat

• Apache Http Server

• Nginx

• Microsoft IIS

Web 伺服器的核心職責

內容交付

• 響應對網頁和資源的請求。

• 提供靜態檔案並呈現動態內容。

資源管理

• 管理連線和會話。

• 負載均衡以處理多個請求。

安全特性

• 透過 SSL/TLS 支援 HTTPS。

• 基本身份驗證和訪問控制。

瞭解代理

定義

代理伺服器充當客戶端和目標伺服器之間的中間體。

代理型別

• 正向代理− 客戶端用於訪問網際網路。

• 反向代理− 位於 Web 伺服器前面，代表它們處理請求。

常見用例

• 快取

• 過濾

• 內容交付

代理的角色

效能最佳化

• 快取經常訪問的內容以減少載入時間。

• 透過壓縮內容來減少頻寬使用。

安全增強

• 隱藏客戶端 IP 地址以實現匿名性。

• 防止攻擊（例如，DDoS – 分散式拒絕服務）。

訪問控制

• 根據規則過濾流量（例如，組織中的內容過濾）。

• 執行公司關於 Web 訪問的策略。

Web 伺服器和代理之間的相互作用

它們如何協同工作

• 代理將請求轉發到 Web 伺服器並將響應轉發回客戶端。

• 涉及反向代理後面的多個 Web 伺服器的負載均衡技術。

現實世界的例子

您可以討論一個使用代理伺服器來增強 Web 伺服器的效能和安全的場景。

挑戰和注意事項

Web 伺服器挑戰

• 處理高流量。

• 管理安全漏洞。

代理挑戰

• 正確配置代理以獲得最佳效能。

• 在匿名性和安全性與可用性之間取得平衡。

最佳實踐

• 定期更新伺服器和代理的安全補丁。

• 實施監控工具來跟蹤效能和安全威脅。

Web 伺服器的進步

Web 伺服器正在經歷重大的轉變，這是對速度和可擴充套件性需求的驅動。微服務架構的興起促使開發人員採用輕量級 Web 伺服器，這些伺服器可以有效地處理大量請求。諸如Docker和Kubernetes之類的技術促進了容器化，允許應用程式在隔離的環境中執行。這種方法提高了資源利用率並簡化了部署。

此外，無伺服器計算的整合正在徹底改變傳統的 Web 伺服器模型。像 AWS Lambda 和 Azure Functions 這樣的平臺使開發人員能夠響應事件執行程式碼，而無需管理伺服器基礎設施。這不僅降低了運營開銷，而且還允許根據需求自動擴充套件。

安全仍然是重中之重，TLS（傳輸層安全）和 HTTP/3 協議的進步增強了資料保護並減少了延遲。人工智慧驅動的安全解決方案的採用也在增加，有助於即時識別和減輕威脅。

叢集和負載均衡

叢集和負載均衡簡介

叢集和負載均衡對於現代應用程式至關重要，以確保它們在各種負載下具有可擴充套件性、高可用性和良好的效能。以下解釋了它們的重要性。

叢集

• 高可用性− 叢集確保如果一臺伺服器宕機，其他伺服器可以接管，最大限度地減少停機時間並確保持續可用性。

• 可擴充套件性− 透過向叢集新增更多節點，應用程式可以處理更多使用者和更多資料，而不會降低效能。

• 容錯性− 叢集設計為即使在單個節點發生故障時也能繼續執行，從而增強了應用程式的彈性。

• 資源管理− 將工作負載分配到多個節點，最佳化資源使用並防止任何單個節點成為瓶頸。

負載均衡

• 高效的資源利用率− 負載均衡將傳入流量分配到多臺伺服器，確保沒有任何一臺伺服器過載，從而最佳化資源利用率。

• 效能提升− 透過平衡負載，應用程式可以更快地響應使用者請求，從而增強整體使用者體驗。

• 冗餘− 負載均衡確保如果一臺伺服器發生故障，流量可以重定向到其他正在執行的伺服器，從而提供冗餘。

• 可擴充套件性− 可以輕鬆地透過向池中新增更多伺服器來擴充套件，允許應用程式無縫地處理越來越多的流量。

叢集的關鍵概念

叢集型別

• 高可用性 (HA) 叢集− 用於容錯和最小化停機時間。

• 負載均衡叢集− 將工作負載分配到多個節點。如果一個節點發生故障，請求將轉移到下一個節點。

• 儲存叢集− 用於在分散式系統中管理資料。

• 叢集解決方案示例− Kubernetes、Apache Kafka、Hadoop。

負載均衡的關鍵概念

目標− 避免任何單臺伺服器過載，減少響應時間並最佳化資源使用。

負載均衡器型別

• 硬體負載均衡器− 專用裝置。

• 軟體負載均衡器− 在商品硬體或虛擬例項上執行。

• DNS 負載均衡− 使用 DNS（域名系統）將請求路由到不同的伺服器。

負載均衡演算法和技術

• 輪詢− 請求依次分配到伺服器。

• 最少連線− 將流量定向到活動連線最少的伺服器。

• 加權輪詢和最少連線− 根據容量為伺服器分配權重。

• IP 雜湊− 根據客戶端的 IP 地址路由請求。

• 隨機− 將請求路由到隨機伺服器。

• 動態負載均衡− 根據當前伺服器效能進行調整。

負載均衡的工具和技術

• Nginx− 一個流行的開源反向代理和負載均衡器。

• HAProxy− 一個快速可靠的用於基於 TCP 和 HTTP 的應用程式的負載均衡器。

• AWS 彈性負載均衡 (ELB)− 用於 AWS 資源（包括 EC2 和容器）的負載均衡。

• Azure 負載均衡器− 管理 Microsoft Azure 上應用程式的流量。

• Traefik− 一個用於微服務的現代負載均衡器，內建對 Kubernetes 的支援。

叢集技術和架構

• Apache Kafka− 一個支援叢集的分散式流處理平臺。

• Kubernetes− 管理容器化應用程式並自動擴充套件。

• Apache Cassandra− 一個為叢集和容錯而設計的分散式NoSQL資料庫。

• 活躍-活躍與活躍-被動叢集− 在活躍-活躍架構中，叢集中的所有節點（伺服器）都同時積極處理請求。在活躍-被動架構中，任何時候只有一個節點（或主要節點集）積極處理請求，而其他節點處於待機狀態。

為不同應用程式配置負載均衡器

• Web應用程式− 使用HTTP/HTTPS負載均衡。

• 資料庫負載均衡− 平衡讀寫請求（例如，使用MySQL）。

• 微服務和API− 使用負載均衡配置API閘道器。

• 即時應用程式− 配置WebSocket負載均衡以實現低延遲。

監控和維護叢集和負載均衡系統

監控的重要性− 保證正常執行時間、效能並檢測問題。

監控工具

• Prometheus和Grafana− 指標收集和視覺化。

• Datadog和New Relic− 雲和本地環境的端到端監控。

• ELK Stack− 用於負載均衡器和叢集事件的日誌分析。

• 常見的維護任務− 更新配置、擴充套件/縮減、處理節點故障。

識別和解決常見的負載均衡和叢集問題。

以下是負載均衡和叢集中常見問題的概述，以及識別和解決這些問題的策略。這些問題通常與配置錯誤、容量限制和網路約束有關，有效地解決這些問題有助於保持高可用性和效能。

負載分配不均

症狀− 一些伺服器CPU或記憶體使用率很高，而其他伺服器則未充分利用。

原因− 這可能是由於負載均衡演算法配置不當（例如，如果伺服器的處理能力不相等，輪詢可能效果不佳）或在加權輪詢或最少連線演算法中權重設定不正確。

解決方案

調整負載均衡演算法，使其與應用程式的需求相匹配。使用加權負載均衡方法來匹配伺服器容量。

對於基於雲的解決方案，請考慮使用自動擴充套件策略，以便在高負載條件下自動新增資源。

會話永續性（粘性會話）問題

粘性會話，也稱為會話親和性，是一種負載均衡技術，用於確保使用者的請求在整個會話過程中始終定向到同一臺伺服器。

症狀− 使用者意外登出或在重定向到不同的伺服器時丟失會話資料。

原因− 如果使用者的請求被路由到不同的伺服器，則負載均衡器可能未配置粘性會話，從而導致會話連續性丟失。

解決方案

在負載均衡器上啟用會話永續性（粘性會話），以確保來自同一會話中給定客戶端的請求被路由到同一臺伺服器。

對於更具可擴充套件性的解決方案，請實現分散式會話管理（例如，將會話資料儲存在資料庫或Redis等分散式快取中），以避免依賴於單個伺服器。

配置漂移

症狀− 節點之間行為不一致，例如不同的軟體版本或配置。

原因− 手動配置更改導致叢集節點之間不匹配。

解決方案

使用Ansible、Puppet或Chef等配置管理工具，確保所有節點的配置一致。

實施基礎設施即程式碼 (IaC) 實踐，使用 Terraform 等工具來強制執行版本化和一致的配置狀態。

DNS負載均衡中的DNS快取問題

症狀− 即使之後，客戶端也會被定向到不健康的節點。

原因− 客戶端或中間解析器中的DNS快取可能會保留已停用或故障節點的IP對映。

解決方案

減少DNS記錄的生存時間 (TTL)，以確保基於DNS的負載均衡器中更改的更快傳播。

使用故障轉移DNS記錄，如果主節點不可訪問，則將流量重定向到備用節點。

日誌記錄和監控挑戰

症狀− 缺乏對流量模式、負載不平衡或故障排除延遲的洞察。

原因− 負載均衡器和叢集節點上的監控或日誌記錄不足。

解決方案

整合Prometheus、Grafana或Datadog等監控工具以獲取即時指標。

使用集中式日誌記錄（例如，ELK Stack或Fluentd）來聚合來自不同節點的日誌並提供統一訪問。

設定警報系統，以通知管理員異常模式，例如突然的流量峰值、伺服器故障或高延遲。

叢集和負載均衡的未來

叢集和負載均衡的趨勢

• 邊緣計算− 將叢集部署到更靠近資料來源的位置以降低延遲。

• 人工智慧驅動的負載均衡− 使用機器學習來最佳化請求路由。

• 無伺服器架構− 無伺服器對傳統負載均衡的影響。

• 潛在挑戰− 管理分散式系統的複雜性增加，安全問題。

系統開發生命週期

有效的系統開發生命週期 (SDLC) 應產生滿足客戶期望、在時間和成本評估範圍內完成並能有效地在當前和計劃的資訊科技基礎設施中有效執行的高質量系統。

系統開發生命週期 (SDLC) 是一種概念模型，其中包括在整個生命週期中開發或更改系統的策略和程式。

SDLC 用於分析人員開發資訊系統。SDLC 包括以下活動：

• 需求
• 設計
• 實現
• 測試
• 部署
• 運營
• 維護

SDLC 的階段

系統開發生命週期是一種系統化的方法，它明確地將工作分解成實現新的或修改後的資訊系統所需的階段。

可行性研究或規劃

• 定義現有系統的問題和範圍。

• 概述新系統並確定其目標。

• 確認專案可行性並制定專案進度表。

• 在此階段，還考慮系統的威脅、約束、整合和安全性。

• 在此階段結束時，將建立整個專案的可行性報告。

分析和規範

• 收集、分析和驗證資訊。

• 定義新系統需求和原型。

• 評估替代方案並確定需求的優先順序。

• 檢查終端使用者的需求並增強系統目標。

• 在此階段結束時，將準備一份軟體需求規格說明書 (SRS) 文件，其中指定系統的軟體、硬體、功能和網路需求。

系統設計

• 包括應用程式、網路、資料庫、使用者介面和系統介面的設計。

• 將SRS文件轉換為邏輯結構，其中包含可以程式語言實現的詳細和完整的規範集。

• 制定應急計劃、培訓計劃、維護計劃和運營計劃。

• 審查擬議的設計。確保最終設計必須滿足SRS文件中規定的要求。

• 最後，準備一份設計文件，該文件將在後續階段使用。

實施

• 透過編碼將設計實現到原始碼中。

• 將所有模組組合到訓練環境中，以檢測錯誤和缺陷。

• 測試計劃將生成包含錯誤的測試報告，該測試計劃包括測試相關的任務，例如測試用例生成、測試標準和測試資源分配。

• 將資訊系統整合到其環境中並安裝新系統。

維護/支援

• 包括系統安裝後所需的所有活動，例如使用者的電話支援或現場支援。

• 實施軟體在一段時間內可能發生的更改，或在軟體部署到客戶位置後實施任何新要求。

• 它還包括處理殘餘錯誤並解決系統中即使在測試階段後也可能存在的任何問題。

• 大型系統可能需要較長時間的維護和支援，而小型系統則只需要較短的時間。

系統分析和設計的生命週期

下圖顯示了分析和設計階段系統完整的生命週期。

系統分析師的角色

系統分析師是一個徹底瞭解系統並透過提供適當的方向來指導系統開發專案的人。他是一位專家，擁有在每個階段執行所需開發任務的技術和人際交往能力。

他努力使資訊系統的目標與組織目標相匹配。

主要角色

• 透過各種事實調查技術定義和理解使用者的需求。

• 透過獲得使用者共識來確定需求的優先順序。

• 收集事實或資訊並獲取使用者的意見。

• 進行分析和評估，以獲得更使用者友好的適當系統。

• 提出許多靈活的替代解決方案，選擇最佳解決方案，並量化成本和效益。

• 繪製某些規範，這些規範易於使用者和程式設計師以精確和詳細的形式理解。

• 實施系統的邏輯設計，該設計必須是模組化的。

• 計劃在系統使用一段時間後進行評估的週期性，並根據需要修改系統。

系統分析師的屬性

下圖顯示了系統分析師應具備的屬性：

人際交往能力

• 與使用者和程式設計師互動。
• 促進團隊合作並領導小型團隊。
• 管理期望。
• 良好的理解、溝通、銷售和教學能力。
• 能夠自信地解決問題的激勵者。

分析能力

• 系統研究和組織知識
• 問題識別、問題分析和問題解決
• 良好的常識
• 權衡取捨的能力
• 對學習新組織的好奇心

管理技能

• 理解使用者的術語和實踐。
• 資源和專案管理。
• 變更和風險管理。
• 透徹理解管理職能。

技術技能

• 掌握計算機和軟體知識。
• 緊跟現代發展潮流。
• 瞭解系統設計工具。
• 掌握新技術的廣度知識。

系統分析與設計 - 需求確定

引言

在系統分析和設計領域，需求確定是一個至關重要的階段，它為成功的軟體開發奠定了基礎。它涉及收集、分析和記錄利益相關者的需求和期望，以確保最終系統滿足其預期目的。本文探討了需求確定的重要性、其方法、挑戰和最佳實踐，為新手和經驗豐富的實踐者提供全面的概述。

需求確定的重要性

需求確定至關重要，原因如下：

• 明確目的——清晰定義的需求有助於利益相關者理解系統的目的和功能，減少歧義。

• 滿足利益相關者——儘早參與利益相關者並準確捕捉他們的需求，從而提高對最終產品的滿意度。

• 成本和時間效率——完善的需求文件最大限度地減少了後期開發階段代價高昂的變更風險，從而提高了專案生命週期的效率。

• 風險管理——儘早識別潛在問題，使團隊能夠在風險升級之前制定策略來降低風險。

• 開發框架——需求作為系統設計、編碼、測試和實施的指導，確保整個開發過程中的協調一致。

需求確定方法

在需求確定階段可以採用多種方法，每種方法都有其優缺點：

訪談

訪談涉及與利益相關者直接討論，以引出他們的需求和偏好。訪談可以是有結構的、半結構的或無結構的，允許靈活地收集資訊。

優點

• 直接獲取使用者見解。

• 有機會進行後續提問和澄清。

缺點

• 耗時。

• 如果沒有仔細管理，可能會出現有偏差的回應。

調查問卷

調查問卷允許從更大範圍的利益相關者群體中收集資料。它們可用於收集定量資料，從而更容易分析趨勢和共同需求。

優點

• 快速覆蓋廣泛受眾。

• 可以提供統計資料。

缺點

• 資訊深度有限。

• 潛在的回應率低。

研討會和焦點小組

研討會和焦點小組在協作環境中召集利益相關者討論需求。這種方法鼓勵互動，並可能產生創造性的解決方案。

優點

• 促進協作和討論。

• 產生多樣化的想法和觀點。

缺點

• 主導性聲音可能會掩蓋較安靜的參與者。

• 需要熟練的引導才能有效。

觀察

觀察包括在使用者的自然環境中研究他們如何與現有系統互動。這種方法可以揭示隱藏的需求和工作流程。

優點

• 提供現實世界的背景。

• 可以發現使用者可能無法表達的問題。

缺點

• 非常耗時。

• 觀察者偏差可能會影響結果。

文件分析

審查現有文件（例如使用者手冊、系統規範和業務流程圖）可以深入瞭解現有系統，併為新需求提供資訊。

優點

• 利用現有知識。

• 識別現有系統的差距。

缺點

• 文件可能已過時或不完整。

• 需要專業知識才能有效地進行解讀。

需求確定的挑戰

儘管需求確定非常重要，但它也充滿了挑戰：

• 需求變更——隨著專案的進展，利益相關者可能會改變他們的需求，使流程複雜化。

• 利益相關者衝突——不同的利益相關者可能具有衝突的需求或優先順序，使得達成共識變得困難。

• 溝通障礙——由於術語、假設或不同視角而可能出現誤解，導致需求不完整或不正確。

• 資訊不完整——利益相關者可能無法完全理解他們的需求，導致需求存在差距。

• 時間限制——緊張的專案時間表可能會迫使團隊匆忙完成需求確定階段，從而增加出錯的可能性。

有效需求確定的最佳實踐

為了克服挑戰並提高需求確定的有效性，請考慮以下最佳實踐：

• 儘早並經常讓利益相關者參與——從一開始就讓使用者和利益相關者參與，並在整個專案過程中保持持續溝通。

• 使用多種技術——採用多種方法來收集全面的見解並驗證結果。

• 清晰地記錄需求——使用清晰、簡潔的語言和結構化格式（例如，用例、使用者故事）來記錄需求，以便於參考。

• 確定需求優先順序——與利益相關者一起根據業務價值、可行性和緊迫性確定需求的優先順序，確保首先滿足關鍵需求。

• 定期進行審查——與利益相關者定期審查需求，並在必要時進行驗證和調整，確保整個專案中的協調一致。

• 利用原型設計——使用原型或線框圖來視覺化需求並收集反饋，幫助利益相關者澄清他們的需求。

• 保持可追溯性——建立可追溯性矩陣，跟蹤從初始收集到設計、開發和測試的需求，確保滿足所有需求。

結論

需求確定是系統分析和設計過程中至關重要的一步。通過了解其重要性、採用適當的方法、應對挑戰和遵循最佳實踐，組織可以大大提高專案成功的可能性。有效執行的需求確定階段不僅能夠產生滿足使用者需求的系統，還能促進協作，降低風險，最終促進利益相關者的滿意度和業務成功。

系統分析與設計 - 系統實施

引言

• 系統實施在專案管理和IT中的定義和意義。

• 彌合設計與運營之間差距的作用。

• 實施新系統關鍵步驟的概述。

實施規劃

定義範圍和目標

• 理解專案目標。

• 將實施與業務戰略保持一致的重要性。

資源分配

• 確定資源（人力、技術和財務）。

• 資源規劃和時間表管理。

風險評估

• 識別潛在的實施風險。

• 制定應急計劃以降低風險。

選擇正確的實施方法

大爆炸式方法

• 一次性用新系統替換舊系統。

• 立即過渡的優缺點。

分階段實施

• 分階段逐步部署。

• 控制範圍和使用者適應性的好處。

並行實施

• 同時執行舊系統和新系統。

• 驗證和測試的優勢。

試點實施

• 在有限的區域部署系統以評估效能。

• 在全面推廣之前降低風險的好處。

為變革做準備

變更管理

• 建立開放的系統變更文化。

• 應對新系統抵制的策略。

培訓計劃

• 設計培訓以確保使用者熟練掌握。

• 持續學習和支援在成功實施中的作用。

溝通規劃

• 在整個實施過程中讓利益相關者知情。

• 清晰透明溝通的技術。

測試和質量保證

測試的重要性

• 測試型別（例如，單元測試、整合測試、使用者驗收測試）。

• 上線前確保可靠性和效能。

使用者驗收測試 (UAT)

• 使用者在真實場景中驗證的重要性。

• 收集反饋並改進系統。

質量控制措施

• 定義效能和使用者滿意度的基準。

• 實施反饋迴圈以持續改進。

系統上線和推廣

最終準備

• 驗證系統功能和安全性。

• 建立資料遷移和備份流程。

執行推廣

• 遵循清晰的已記錄上線策略。

• 監控效能並管理使用者諮詢。

實施後支援

• 幫助臺和技術支援計劃。

• 推廣後快速響應問題的重要性。

評估和監控

評估系統性能

• 評估功能、速度和可靠性的指標。

• 收集定量和定性資料。

使用者反饋和調整

• 收集使用者反饋以衡量滿意度。

• 根據實際使用者的需求規劃更新或修改。

維護和持續改進

• 建立維護計劃以確保持續的可靠性。

• 找出系統改進的機會。

案例研究和最佳實踐

成功實施的示例

• 簡要案例研究，重點介紹各種方法（例如，分階段、試點）。

經驗教訓

• 常見的挑戰以及如何克服這些挑戰。

• 無縫實施的最佳實踐。

結論

系統實施關鍵步驟的回顧：

• 強調精心規劃和執行的戰略重要性。

• 關於靈活性和適應性在成功實施中的作用的最終思考。

系統分析與設計 - 系統規劃

什麼是需求確定？

需求是新系統的一個重要特徵，可能包括資料的處理或捕獲、控制業務活動、生成資訊和支援管理。

需求確定包括研究現有系統並收集詳細資訊，以瞭解需求是什麼，它是如何工作的，以及應該在哪裡改進。

需求確定的主要活動

需求預測

• 它根據以往經驗預測系統的特性，包括某些問題或特性以及新系統的需求。

• 它可以導致分析那些沒有經驗的分析師可能忽略的領域。但如果採取捷徑並在調查中引入偏差，那麼需求預測就可能是不完整的。

需求調查

• 它研究當前系統並記錄其功能以進行進一步分析。

• 它是系統分析的核心，分析師使用事實調查技術、原型設計和計算機輔助工具來記錄和描述系統功能。

需求規範

• 它包括確定需求規範的資料分析、新系統功能的描述以及指定將提供哪些資訊需求。

• 它包括對事實資料的分析、基本需求的識別和需求滿足策略的選擇。

資訊收集技術

事實調查技術的主要目標是確定組織的資訊需求，分析師使用這些資訊來準備使用者能夠理解的精確SRS。

理想的SRS文件應：

• 完整、明確且無專業術語。
• 指定操作、戰術和戰略資訊需求。
• 解決使用者和分析師之間可能存在的爭議。
• 使用圖形輔助工具，簡化理解和設計。

有各種資訊收集技術：

訪談

系統分析師透過訪談從個人或群體那裡收集資訊。分析師可以是正式的、法律的、玩政治的，或者是非正式的；因為訪談的成功取決於分析師作為訪談者的技能。

它可以透過兩種方式完成：

• 非結構化訪談——系統分析師進行問答環節以獲取系統的基本資訊。

• 結構化訪談——它包含標準問題，使用者需要以封閉式（客觀）或開放式（描述性）格式回答。

訪談的優點

• 這種方法通常是收集定性資訊的最佳來源。

• 這對那些書面表達能力不強或沒有時間填寫問卷的人來說非常有用。

• 資訊可以立即輕鬆驗證和交叉檢查。

• 它可以處理複雜的問題。

• 透過徵求意見，很容易發現關鍵問題。

• 它彌合了誤解方面的差距，並最大限度地減少了未來問題。

問卷調查

分析師使用這種方法從大量人員那裡收集關於系統各個問題的資料。

問卷調查有兩種型別：

• **開放式問卷** - 它包含易於正確解釋的問題。它們可以探討問題，並引導到具體的答案方向。

• **封閉式問卷** - 當系統分析師有效地列出所有可能的、相互排斥的答案時，就會使用這類問題。

問卷調查的優點

• 它在調查不在同一地點的使用者興趣、態度、感受和信念方面非常有效。

• 在需要了解給定群體中多大比例的人贊成或反對擬議系統的特定功能的情況下，它非常有用。

• 在為系統專案制定任何具體方向之前，它有助於確定總體意見。

• 它更可靠，並能提供誠實回覆的高度保密性。

• 它適用於收集事實資訊和統計資料，可以透過電子郵件和郵寄發送。

記錄、流程和表單的審查

審查現有的記錄、流程和表單有助於深入瞭解系統，描述當前系統的功能、操作或活動。

優點

• 它幫助使用者在向他人施加影響之前，自己瞭解一些關於組織或運營的知識。

• 由於程式手冊和表格描述了現有系統的格式和功能，因此它有助於在短時間內記錄當前的操作。

• 它可以清楚地瞭解組織中處理的交易，識別處理的輸入並評估績效。

• 它可以幫助分析師從必須支援的操作方面來理解系統。

• 它描述了問題、受影響的部分和擬議的解決方案。

觀察

這是一種透過注意和觀察人員、事件和物件來收集資訊的方法。分析師訪問組織以觀察當前系統的執行情況並瞭解系統的需求。

優點

• 這是一種直接收集資訊的方法。

• 在收集資料的真實性受到質疑，或者系統某些方面的複雜性妨礙終端使用者清晰解釋的情況下，它非常有用。

• 它產生更準確可靠的資料。

• 它能找出所有不完整和過時的文件方面。

聯合應用程式開發 (JAD)

這是IBM開發的一項新技術，它將所有者、使用者、分析師、設計師和構建者聚集在一起，利用有組織和密集的研討會來定義和設計系統。經過JAD培訓的分析師擔任研討會的促進者，他們擁有一些專業技能。

JAD的優點

• 它透過替代數月的傳統訪談和後續會議來節省時間和成本。

• 它適用於支援聯合解決問題的組織文化。

• 促進多個層級的員工之間的正式關係。

• 它可以帶來創造性的設計開發。

• 它允許快速開發並提高資訊系統的擁有權。

二次研究或背景閱讀

這種方法廣泛用於透過訪問收集到的資訊來收集資訊。它包括營銷人員從任何內部或外部來源使用的任何先前收集的資訊。

優點

• 隨著網際網路的普及，它更容易訪問。

• 它以低成本和時間提供有價值的資訊。

• 它作為主要研究的先驅，並確定主要研究的重點。

• 研究人員可以使用它來判斷研究是否值得，因為它提供了所用程式和收集過程中遇到的問題。

可行性研究

可行性研究可以被認為是初步調查，它幫助管理層決定是否應該對系統進行可行性研究。

• 它確定改進現有系統、開發新系統以及為系統進一步開發產生改進的估計的可能性。

• 它用於獲取問題的概要，並確定是否存在可行或適當的解決方案。

• 可行性研究的主要目標是確定問題的範圍，而不是解決問題。

• 可行性研究的輸出是一個正式的系統建議書，作為決策檔案，其中包括擬議系統的完整性質和範圍。

可行性分析中涉及的步驟

執行可行性分析時，應遵循以下步驟：

• 組建專案團隊並任命專案負責人。

• 開發系統流程圖。

• 確定當前系統的缺陷並設定目標。

• 列舉滿足目標的替代方案或潛在候選系統。

• 確定每個替代方案的可行性，例如技術可行性、運營可行性等。

• 權衡每個候選系統的效能和成本效益。

• 對其他方案進行排名並選擇最佳候選系統。

• 向管理層提交最終專案指令的系統建議書以供批准。

可行性型別

經濟可行性

• 它使用成本/效益分析方法評估候選系統的有效性。

• 它以組織的收益和成本表示候選系統的淨收益。

• 經濟可行性分析 (EFS) 的主要目標是在投資資金投入提案之前，估計候選系統的經濟需求。

• 它更傾向於能夠透過最早和最高的資金回報以及開發候選系統所涉及的最低風險來最大化組織淨值的替代方案。

技術可行性

• 它調查每個實施方案的技術可行性。

• 它分析並確定現有技術是否能夠支援該解決方案。

• 分析師確定是否需要升級或添加當前技術資源以滿足新的需求。

• 它確保候選系統提供適當的響應，以及它在多大程度上能夠支援技術增強。

運營可行性

• 它確定系統在開發和實施後是否有效執行。

• 它確保管理層應支援擬議的系統，並且其運作在當前的組織環境中是可行的。

• 它分析使用者是否會受到影響，以及他們是否接受可能影響系統效益的修改後的或新的業務方法。

• 它還確保候選系統的計算機資源和網路架構是可行的。

行為可行性

• 它評估和估計使用者對新系統開發的態度或行為。

• 它有助於確定系統是否需要特別努力來教育、再培訓、轉移和改變員工在新的業務開展方式上的工作狀態。

進度可行性

• 它確保專案應在給定的時間約束或進度內完成。

• 它還驗證和確認專案截止日期是否合理。

結構化分析

分析師使用各種工具來理解和描述資訊系統。其中一種方法是使用結構化分析。

什麼是結構化分析？

結構化分析是一種開發方法，允許分析師以邏輯的方式理解系統及其活動。

這是一種系統的方法，它使用圖形工具來分析和改進現有系統的目標，並開發新的系統規範，使用者可以輕鬆理解。

它具有以下屬性：

• 它是圖形化的，指定了應用程式的表示。

• 它將流程分解，以便清晰地顯示系統流程。

• 它是邏輯的而不是物理的，即系統的元素不依賴於供應商或硬體。

• 這是一種從高階概述到低階細節的方法。

結構化分析工具

在結構化分析中，各種工具和技術用於系統開發。它們是：

• 資料流程圖
• 資料字典
• 決策樹
• 決策表
• 結構化英語
• 虛擬碼

資料流程圖 (DFD) 或氣泡圖

這是Larry Constantine開發的一種技術，用於以圖形形式表達系統的需求。

• 它顯示了系統各個功能之間的資料流，並指定了當前系統是如何實現的。

• 它是設計階段的初始階段，它將需求規範按功能分解到最低的細節級別。

• 其圖形化性質使其成為使用者和分析師或分析師和系統設計師之間良好的溝通工具。

• 它概述了系統處理哪些資料、執行哪些轉換、儲存哪些資料、產生哪些結果以及結果在哪裡流動。

DFD的基本元素

DFD易於理解，在所需設計不明確且使用者需要一種符號語言進行溝通時非常有效。但是，它需要大量的迭代才能獲得最準確和完整的解決方案。

下表顯示了設計DFD時使用的符號及其意義：

DFD型別

DFD有兩種型別：物理DFD和邏輯DFD。下表列出了區分物理DFD和邏輯DFD的要點。

上下文圖

上下文圖透過一個DFD幫助理解整個系統，該DFD概述了系統。它從提及主要流程（細節很少）開始，然後採用自上而下的方法，給出流程的更多細節。

下面顯示了餐飲管理的上下文圖。

資料字典

資料字典是系統中資料元素的結構化儲存庫。它儲存所有DFD資料元素的描述，即資料流、資料儲存、資料儲存中儲存的資料以及流程的詳細資訊和定義。

資料字典可以改善分析師和使用者之間的溝通。它在構建資料庫中扮演著重要的角色。大多數資料庫管理系統 (DBMS) 都將資料字典作為標準功能。例如，參考下表：

決策樹

決策樹是一種透過描述決策並避免溝通問題來定義複雜關係的方法。決策樹是一個圖表，它顯示了水平樹框架內的替代行動和條件。因此，它描述了首先、其次等等要考慮哪些條件。

決策樹描述了每個條件及其允許的操作之間的關係。方形節點表示操作，圓形節點表示條件。它迫使分析師考慮決策的順序，並確定必須做出的實際決策。

決策樹的主要侷限性在於，它的格式中缺乏資訊來描述可以進行測試的其他條件組合。它是條件和操作之間關係的單一表示。

例如，參考下面的決策樹：

決策表

決策表是一種以精確易懂的方式描述複雜邏輯關係的方法。

• 在結果操作取決於一個或多個獨立條件組合發生的情況下，它非常有用。

• 它是一個矩陣，包含用於定義問題和操作的行或列。

決策表的組成部分

• 條件存根 - 它位於左上角象限，列出了所有要檢查的條件。

• 動作存根 - 它位於左下象限，概述了為滿足此類條件而執行的所有操作。

• 條件項 - 它位於右上角象限，提供了對條件存根象限中提出的問題的答案。

• 動作項 - 它位於右下象限，指示條件項象限中對條件的答案所產生的適當操作。

決策表中的條目由決策規則給出，這些規則定義了條件組合和行動過程之間的關係。在規則部分：

• Y 表示條件的存在。
• N 表示條件不滿足。
• 動作前的空白 - 表示應忽略它。
• 動作前的 X（或勾號）表示應執行它。

例如，參考下表：

結構化英語

結構化英語源於結構化程式語言，它對過程的描述更加易懂和精確。它基於過程邏輯，使用旨在執行操作的構造和祈使句。

• 當必須考慮程式中的序列和迴圈，並且問題需要帶決策的行動序列時，它最有效。

• 它沒有嚴格的語法規則。它用順序決策結構和迭代來表達所有邏輯。

例如，參見以下操作序列：

if customer pays advance 
   then 
      Give 5% Discount 
   else 
      if purchase amount >=10,000 
         then 
            if  the customer is a regular customer 
               then Give 5% Discount 
            else  No Discount
         end if 
      else No Discount  
   end if 
end if 

虛擬碼

虛擬碼不符合任何程式語言，並用簡單的英語表達邏輯。

• 它可以在物理設計期間和之後指定物理程式設計邏輯，而無需實際編碼。

• 它與結構化程式設計一起使用。

• 它取代了程式的流程圖。

選擇合適的工具的指導原則

使用以下指導原則來選擇最適合您需求的工具：

• 在高階或低階分析中使用 DFD 來提供良好的系統文件。

• 使用資料字典來簡化結構，以滿足系統的需求。

• 如果存在許多迴圈且操作複雜，則使用結構化英語。

• 如果要檢查大量條件且邏輯複雜，則使用決策表。

• 如果條件的順序很重要，並且只有少量條件需要測試，則使用決策樹。

系統分析與設計 - 系統設計

系統設計是彌合問題域和現有系統之間差距的階段，以可管理的方式進行。此階段側重於解決方案域，即“如何實現？”

在此階段，SRS 文件將轉換為可實現的格式，並決定系統將如何執行。

在此階段，系統開發的複雜活動將被劃分為幾個較小的子活動，這些子活動相互協調以實現系統開發的主要目標。

系統設計的輸入

系統設計採用以下輸入：

• 工作說明

• 需求確定計劃

• 現狀分析

• 擬議的系統需求，包括概念資料模型、修改後的 DFD 和元資料（關於資料的資料）。

系統設計的輸出

系統設計給出以下輸出：

• 擬議系統的基礎設施和組織變化。

• 資料模式，通常是關係模式。

• 定義表/檔案和列/資料項的元資料。

• 功能層次圖或網頁地圖，以圖形方式描述程式結構。

• 程式中每個模組的實際或虛擬碼。

• 擬議系統的原型。

系統設計的型別

邏輯設計

邏輯設計與系統的資料流、輸入和輸出的抽象表示有關。它描述了輸入（來源）、輸出（目的地）、資料庫（資料儲存）、過程（資料流），所有這些都以滿足使用者需求的格式呈現。

在準備系統的邏輯設計時，系統分析師會詳細說明使用者需求，這實際上決定了系統輸入和輸出的資訊流以及所需的資料來源。使用資料流圖、E-R 圖建模。

物理設計

物理設計與系統的實際輸入和輸出過程有關。它側重於如何將資料輸入系統、驗證、處理和顯示為輸出。

它透過定義精確指定候選系統功能的設計規範來生成工作系統。它關注使用者介面設計、流程設計和資料設計。

它包括以下步驟：

• 指定輸入/輸出媒體、設計資料庫和指定備份程式。

• 計劃系統實施。

• 制定測試和實施計劃，並指定任何新的硬體和軟體。

• 更新成本、效益、轉換日期和系統限制。

架構設計

它也稱為高階設計，側重於系統架構的設計。它描述了系統的結構和行為。它定義了系統開發過程中各個模組的結構和關係。

詳細設計

它遵循架構設計，並側重於每個模組的開發。

概念資料建模

它是組織資料的表示，包括所有主要實體和關係。系統分析師為當前系統開發一個概念資料模型，該模型支援擬議系統的範圍和需求。

概念資料建模的主要目標是儘可能多地捕獲資料的含義。如今，大多陣列織使用 E-R 模型進行概念資料建模，該模型使用特殊符號來儘可能多地表示關於資料的含義。

實體關係模型

這是一種用於資料庫設計中的技術，有助於描述組織中各種實體之間的關係。

E-R 模型中使用的術語

• 實體 - 它指定應用程式中不同的現實世界專案。例如：供應商、專案、學生、課程、教師等。

• 關係 - 它們是實體之間有意義的依賴關係。例如，供應商供應商品，教師教授課程，則供應和課程是關係。

• 屬性 - 它指定關係的屬性。例如，供應商程式碼、學生姓名。E-R 模型中使用的符號及其含義：

下表顯示了 E-R 模型中使用的符號及其意義：

兩組資料之間可以存在三種關係：一對一、一對多和多對多。

檔案組織

它描述了記錄如何在檔案中儲存。

有四種檔案組織方法：

• 序列 - 記錄按時間順序儲存（按輸入或發生的順序）。示例 - 電話費記錄、ATM 交易、電話佇列。

• 順序 - 記錄按關鍵欄位的順序儲存，該欄位包含唯一標識記錄的值。示例 - 電話簿。

• 直接（相對） - 每條記錄都基於裝置上的物理地址或位置進行儲存。地址是根據記錄關鍵欄位中儲存的值計算出來的。隨機化例程或雜湊演算法進行轉換。

• 索引 - 記錄可以使用索引順序和非順序地進行處理。

比較

檔案訪問

可以使用順序訪問或隨機訪問訪問檔案。檔案訪問方法允許計算機程式讀取或寫入檔案中的記錄。

順序訪問

檔案中的每條記錄都從第一條記錄開始處理，直到到達檔案結尾 (EOF)。當需要在任何給定時間訪問大量檔案記錄時，這種方法非常高效。儲存在磁帶上的資料（順序訪問）只能順序訪問。

直接（隨機）訪問

記錄是透過知道它們在裝置上的物理位置或地址來定位的，而不是它們相對於其他記錄的位置。儲存在 CD 裝置上的資料（直接訪問）可以順序或隨機訪問。

組織系統中使用的檔案型別

以下是組織系統中使用的檔案型別：

• 主檔案 - 包含系統當前資訊。例如，客戶檔案、學生檔案、電話簿。

• 表文件 - 是一種很少更改並以表格格式儲存的主檔案型別。例如，儲存郵政編碼。

• 事務檔案 - 包含從業務活動生成的日常資訊。用於更新或處理主檔案。例如，員工的地址。

• 臨時檔案 - 系統在需要時建立和使用。

• 映象檔案 - 它們是其他檔案的精確副本。有助於最大限度地減少原始檔案無法使用時的停機風險。每次修改原始檔案時，都必須修改它們。

• 日誌檔案 - 包含主記錄和事務記錄的副本，以便記錄對主檔案所做的任何更改。它有助於審計，並在系統發生故障時提供恢復機制。

• 存檔檔案 - 包含其他檔案歷史版本的備份檔案。

文件控制

文件化是記錄資訊以供參考或操作目的的過程。它可以幫助需要它的使用者、管理人員和 IT 員工。重要的是，準備好的文件必須定期更新，以便輕鬆追蹤系統的進度。

如果系統在實施後執行不正常，則文件可以幫助管理員瞭解系統中的資料流，從而糾正缺陷並使系統正常執行。

程式設計師或系統分析師通常建立程式和系統文件。系統分析師通常負責準備文件以幫助使用者學習系統。在大公司中，包括技術撰寫人在內的技術支援團隊可能會協助準備使用者文件和培訓材料。

優點

• 它可以減少系統停機時間，降低成本並加快維護任務。

• 它提供了對現有系統正式流程的清晰描述，並有助於瞭解輸入資料型別以及如何生成輸出。

• 它提供了一種在技術使用者和非技術使用者之間有效溝通系統資訊的有效方法。

• 它有助於培訓新使用者，以便他們可以輕鬆理解系統流程。

• 它幫助使用者解決諸如故障排除等問題，並幫助管理者做出更好的組織系統最終決策。

• 它為系統的內部或外部工作提供了更好的控制。

文件型別

在系統設計方面，主要有以下四種文件：

• 程式文件
• 系統文件
• 操作文件
• 使用者文件

程式文件

• 它描述了所有程式模組的輸入、輸出和處理邏輯。

• 程式文件過程從系統分析階段開始，並在實施過程中繼續。

• 此文件指導程式設計師構建模組，這些模組由內部和外部註釋以及易於理解和維護的描述良好地支援。

操作文件

操作文件包含處理和分發線上和列印輸出所需的所有資訊。操作文件應清晰、簡潔，並儘可能線上提供。

它包含以下資訊：

• 程式、系統分析師、程式設計師和系統標識。

• 列印輸出的排程資訊，例如報表、執行頻率和截止日期。

• 輸入檔案及其來源、輸出檔案及其目標。

• 電子郵件和報表分發列表。

• 所需的特殊表格，包括線上表格。

• 操作員的錯誤和資訊訊息以及重新啟動程式。

• 特殊說明，例如安全要求。

使用者文件

它包括與系統互動的使用者指南和資訊。例如，使用者手冊、幫助指南和教程。使用者文件對於培訓使用者和參考用途非常有價值。它必須清晰、易懂，並且所有級別的使用者都可以輕鬆訪問。

使用者、系統所有者、分析師和程式設計師共同努力開發使用者指南。

使用者文件應包括：

• 清晰描述所有主要系統功能、能力和限制的系統概述。

• 源文件內容、準備、處理和樣本的描述。

• 選單和資料輸入螢幕選項、內容和處理說明的概述。

• 定期生成或根據使用者請求提供的報表的示例，包括樣本。

• 安全和審計跟蹤資訊。

• 對特定輸入、輸出或處理要求的責任說明。

• 請求更改和報告問題的程式。

• 異常和錯誤情況的示例。

• 常見問題解答 (FAQ)。

• 如何獲得幫助以及更新使用者手冊的程式說明。

系統文件

系統文件作為 IS 的技術規範以及如何實現 IS 的目標。使用者、管理人員和 IS 所有者無需參考系統文件。在進行修改時，系統文件為理解 IS 的技術方面提供了基礎。

• 它描述了 IS 中的每個程式以及整個 IS 本身。

• 它描述了系統的功能、實現方式、每個程式在整個 IS 中相對於執行順序的目的、傳遞到程式和從程式傳遞的資訊以及整體系統流程。

• 它包括資料字典條目、資料流圖、物件模型、屏幕布局、源文件以及啟動專案的系統請求。

• 大部分系統文件是在系統分析和系統設計階段準備的。

• 在系統實施過程中，分析師必須檢查系統文件以驗證其完整性、準確性和最新性，包括在實施過程中所做的任何更改。

設計策略

自頂向下策略

自頂向下策略使用模組化方法來開發系統設計。之所以這樣稱呼它，是因為它從頂部或最高級別模組開始，然後移向最低級別模組。

在此技術中，將識別用於開發軟體的最高級別模組或主模組。主模組根據每個模組執行的任務，細分為幾個更小、更簡單的子模組或段。然後，每個子模組進一步細分為下一級別（更低級別）的幾個子模組。將每個模組細分為幾個子模組的此過程將持續進行，直到識別出無法進一步細分的最低級別模組。

自底向上策略

自底向上策略遵循模組化方法來開發系統設計。之所以這樣稱呼它，是因為它從底部或最基本的級別模組開始，然後移向最高級別模組。

在此技術中，

• 將識別最基本或最低級別的模組。

• 然後，根據每個模組執行的功能將這些模組組合在一起，以形成下一級別（更高級別）的模組。

• 然後，將這些模組進一步組合以形成下一級別（更高級別）的模組。

• 將幾個更簡單的模組組合在一起以形成更高級別模組的此過程將持續進行，直到實現系統開發過程的主模組。

結構化設計

結構化設計是一種基於資料流的方法，有助於識別正在開發系統的輸入和輸出。結構化設計的目標是最大限度地降低程式的複雜性並提高其模組化程度。結構化設計還有助於描述系統的功能方面。

在結構化設計中，系統規範作為圖形化表示軟體開發中涉及的資料流和過程式列的基礎，藉助 DFD 來實現。為軟體系統開發 DFD 後，下一步是開發結構圖。

模組化

結構化設計將程式劃分為小型獨立模組。這些模組以自頂向下的方式組織，詳細資訊顯示在底部。

因此，結構化設計使用稱為模組化或分解的方法來最大限度地降低複雜性，並透過將問題細分為較小的部分來管理問題。

優點

• 首先測試關鍵介面。
• 它提供抽象。
• 它允許多個程式設計師同時工作。
• 它允許程式碼重用。
• 它提供控制並提高士氣。
• 它使識別結構更容易。

結構圖

結構圖是設計模組化自頂向下系統的推薦工具，它定義了系統開發的各個模組以及各個模組之間的關係。它顯示了系統模組及其相互之間的關係。

它由一個圖表組成，該圖表包含代表模組的矩形框、連線箭頭或線。

• 控制模組 - 它是指導較低級別模組（稱為下級模組）的較高級別模組。

• 庫模組 - 它是一個可重用模組，可以從圖表中的多個點呼叫。

我們有兩種不同的方法來設計結構圖：

• 變換中心結構圖 - 當所有事務都遵循相同的路徑時使用。

• 事務中心結構圖 - 當所有事務不遵循相同的路徑時使用。

使用結構流程圖的目標

• 鼓勵自頂向下設計。

• 支援模組的概念並識別合適的模組。

• 顯示系統的規模和複雜性。

• 識別每個功能中易於識別的功能和模組的數量。

• 描述每個可識別功能是否為可管理的實體，或者是否應將其分解成更小的元件。

影響系統複雜性的因素

為了開發高質量的系統軟體，必須開發良好的設計。因此，在開發系統設計時，主要關注的是軟體設計質量。高質量的軟體設計是指最大限度地減少軟體開發中複雜性和成本支出的設計。

與系統開發相關的兩個重要概念有助於確定系統的複雜性，它們是**耦合**和**內聚**。

耦合

耦合是衡量元件獨立性的指標。它定義了系統開發中每個模組對其他模組的依賴程度。實際上，這意味著系統中模組之間的耦合越強，系統就越難實現和維護。

每個模組都應該與其他模組具有簡單、清晰的介面，並且模組之間共享的資料元素數量應最小。

高耦合

這類系統具有程式單元之間的互連，這些單元相互依賴。對一個子系統的更改會對其他子系統產生重大影響。

低耦合

這類系統由獨立或幾乎獨立的元件組成。一個子系統的更改不會影響任何其他子系統。

耦合度量

• **內容耦合** - 當一個元件實際修改另一個元件時，被修改的元件完全依賴於修改它的元件。

• **公共耦合** - 透過組織系統設計以便可以從公共資料儲存區訪問資料，從而在某種程度上降低耦合量。

• **控制耦合** - 當一個元件傳遞引數來控制另一個元件的活動時。

• **標記耦合** - 當使用資料結構將資訊從一個元件傳遞到另一個元件時。

• **資料耦合** - 當僅傳遞資料時，元件透過這種耦合連線。

內聚

內聚是衡量其元件之間關係密切程度的指標。它定義了模組的元件相互依賴的程度。實際上，這意味著系統設計人員必須確保：

• 他們不會將基本流程分割成碎片化的模組。

• 他們不會將DFD中表示為流程的無關流程組合成毫無意義的模組。

最好的模組是功能內聚的模組。最差的模組是偶然內聚的模組。

最低程度的內聚

偶然內聚存在於其各部分彼此無關的元件中。

• **邏輯內聚** - 將多個邏輯相關的函式或資料元素放在同一個元件中。

• **時間內聚** - 當用於初始化系統或設定變數的元件按順序執行多個函式時，但這些函式透過所涉及的時間相關聯。

• **過程內聚** - 將函式組合在一個元件中只是為了確保此順序。

• **順序內聚** - 當一個元件的一部分的輸出是其下一部分的輸入時。

系統分析與設計 - 軟體部署

引言

**軟體部署**是將軟體應用程式或更新發布和安裝到目標環境（例如生產伺服器、使用者裝置或雲基礎設施）的過程，以使其可供終端使用者或客戶使用。它包含多個階段，包括準備、安裝、配置、測試，有時還包括部署後支援。

在**軟體開發生命週期 (SDLC) 中，部署**是將軟體從開發階段過渡到即時執行狀態的關鍵階段，為使用者提供其價值。部署過程可能因專案的複雜性和組織對軟體管理的方法（例如敏捷或DevOps實踐）而異。

以下是其在SDLC中的重要性概述：

實現使用者的價值

• **SDLC 的目標** - SDLC 中的每個階段（例如計劃、設計、開發和測試）都旨在構建滿足使用者需求的產品。但是，部署是這項工作實際實現並呈現給終端使用者的階段，使其成為所有先前階段的最終結果。

• **對業務的影響** - 部署對於交付新功能、解決錯誤和應用改進至關重要，這直接影響客戶滿意度和業務價值。

確保生產環境的穩定性和可靠性

• **風險管理** - 受控部署允許組織管理與即時環境變化相關的風險。透過使用分階段推出或藍綠部署等方法，可以最大限度地減少問題，從而提高穩定性。

• **質量保證** - 儘管在部署之前完成了測試，但部署過程通常包括最終檢查、特定於環境的配置和監控，以確保應用程式在生產環境中穩定。

支援持續整合和交付 (CI/CD)

• **敏捷性和響應能力** - 在現代 SDLC 實踐中，特別是敏捷和 DevOps，部署與 CI/CD 管道緊密相連，其中程式碼更改會自動進行測試和部署。這允許頻繁更新，幫助企業快速響應使用者反饋和市場需求。

• **自動化優勢** - 部署自動化最大限度地減少人為錯誤，提高一致性，並加快部署過程，符合 CI/CD 的目標。

增強安全性和合規性

• **安全補丁和更新** - 部署對於確保應用程式安全和最新至關重要。及時部署安全補丁可以防止漏洞被利用。

• **合規性** - 對於許多行業而言，合規性標準需要特定的部署實踐和文件，這些對於實現法規遵從性至關重要。

最佳化資源利用和成本效率

• **高效利用資源** - 自動化和計劃良好的部署管道有助於減少停機時間，釋放資源用於其他開發和運營任務。

• **節省成本** - 部署最佳化（例如零停機策略或容器化）可以透過最大限度地減少中斷和最大限度地提高生產環境中的資源效率來降低成本。

促進改進反饋

• **部署後監控** - 部署還為在真實環境中觀察應用程式效能和收集使用者反饋奠定了基礎。此反饋迴圈對於持續改進和規劃未來的開發週期至關重要。

• **問題識別** - 在測試環境中可能不明顯的問題可能會在部署過程中出現，從而為改進軟體和SDLC流程本身提供見解。

軟體部署模型型別

• **本地部署** - 軟體部署在組織基礎設施內的傳統模型。

• **雲部署** - 使用 AWS、Azure、Google Cloud 等雲提供商。

• **混合部署** - 本地和雲解決方案的組合。

• **持續部署 (CD)** - 介紹 CI/CD 管道和自動化部署。

• **容器化部署** - 使用 Docker、Kubernetes 和其他容器化工具。

部署策略和方法

• **藍綠部署** - 執行兩個相同的環境以減少停機時間。

• **金絲雀釋出** - 逐步向一部分使用者推出更新。

• **滾動部署** - 逐步部署到系統的一部分以降低風險。

• **A/B 測試** - 部署不同的版本以衡量效能和使用者響應。

• **特性開關** - 啟用某些使用者的特性而無需完全部署。

部署過程的關鍵元件

• **構建自動化** - 用於自動化構建的工具和實踐（例如，Jenkins、GitLab CI）。

• **配置管理** - 管理軟體環境（例如，Ansible、Chef）。

• **部署中的測試** - 測試型別（例如，冒煙測試、迴歸測試）。

• **釋出管理** - 跟蹤版本、文件和發行說明。

• **監控和日誌記錄** - 用於跟蹤應用程式執行狀況的工具和策略（例如，Prometheus、Grafana、ELK 堆疊（包括 Elasticsearch、Logstash、Kibana 和 Datadog））。

軟體部署中的工具和技術

• **CI/CD 工具** - Jenkins、CircleCI、GitLab CI/CD 等。

• **配置管理工具** - Ansible、Puppet、Chef。

• **容器化工具** - Docker、Kubernetes、Helm。

• **雲平臺** - AWS、Azure、Google Cloud 用於部署自動化。

• **監控工具** - Grafana、Prometheus、ELK 堆疊用於可觀察性。

• **版本控制系統** - Git、SVN 用於管理部署程式碼版本。

軟體部署中的挑戰

• **環境一致性** - 開發、測試和生產環境之間的差異。

• **回滾和故障** - 處理部署故障並確保系統穩定性。

• **安全問題** - 保護部署管道並管理敏感資料。

• **依賴項管理** - 處理版本衝突和庫依賴項。

• **擴充套件和負載管理** - 將更新部署到可擴充套件系統中的挑戰。

有效部署的最佳實踐

• **自動化** - 自動化重複性部署任務的重要性。

• **測試** - 部署前的持續整合和測試。

• **文件** - 保持清晰、最新的部署文件。

• **監控** - 建立強大的監控和警報系統。

• **回滾計劃** - 制定必要的快速回滾策略。

軟體部署的未來

• **邊緣計算和部署** - 將軟體部署到靠近資料來源的位置以減少延遲。

• **無伺服器部署** - 使用 FaaS（函式即服務）和無伺服器平臺。

• **部署中的人工智慧** - 用於部署最佳化的預測分析。

• **CI/CD 的發展** - 持續一切 (CI/CD/CT) 及其在部署中的作用。

結論

本質上，部署是軟體實現其預期目的、向終端使用者交付其好處並使企業能夠從投資中獲益的地方。流暢、可靠的部署過程對於將開發工作與使用者期望保持一致、維持運營連續性以及支援軟體產品的持續發展至關重要。

使用 Docker 的示例部署工作流

設定專案

為應用程式中的每個服務（例如，Web 應用程式、資料庫）定義 Dockerfile。

如果要一起管理多個服務，請編寫 Docker Compose 檔案（例如，“docker-compose.yml”）。

Spring Boot 應用程式的示例 Dockerfile

# Start with an official Java runtime as the base image
FROM openjdk:17-jdk-alpine

# Set the working directory
WORKDIR /app

# Copy the application jar file into the image
COPY target/myapp.jar myapp.jar

# Expose the port the app will run on
EXPOSE 8080

# Run the application
ENTRYPOINT ["java", "-jar", "myapp.jar"]

構建 Docker 映象

docker build -t myapp:latest .

正確標記映象以管理登錄檔中的不同版本（例如，“myapp:v1.0”）。

在容器中執行本地測試

使用 Docker Compose 或單個 Docker 容器在隔離的環境中執行測試。

docker-compose up -d
docker-compose exec webapp ./run-tests.sh

確保所有服務都在執行並透過測試。

將映象推送到 Docker 登錄檔

將 Docker 映象推送到容器登錄檔（例如，Docker Hub、Amazon ECR 或私有登錄檔）以使其可供部署環境訪問。

登入並推送映象：

docker login -u username -p password
docker tag myapp:latest username/myapp:v1.0
docker push username/myapp:v1.0

部署到暫存環境

從登錄檔**拉取映象**到暫存伺服器：

docker pull username/myapp:v1.0

根據暫存環境設定使用 Docker Compose 或 Kubernetes 進行部署。

在暫存環境中執行任何其他整合或驗收測試。

監控日誌和指標

使用Docker命令檢查日誌和應用程式健康狀況。

docker logs -f container_name

如果使用監控工具（例如，Grafana，Prometheus），請確認應用程式指標在可接受的閾值範圍內。

批准並部署到生產環境

一旦測試在預釋出環境中透過，就從註冊中心拉取映象並將其部署到生產環境。

執行Docker Compose或Kubernetes命令以啟動生產環境中的服務。

docker pull username/myapp:v1.0
docker run -d -p 8080:8080 username/myapp:v1.0

實施回滾機制

確保已儲存先前版本的映象。如果出現問題，請重新部署最後一個穩定版本。

docker pull username/myapp:v0.9
docker run -d -p 8080:8080 username/myapp:v0.9

使用CI/CD管道自動化工作流程

設定一個CI/CD管道（例如，GitHub Actions，GitLab CI，Jenkins），該管道自動化此工作流程，包括構建、測試、推送和部署階段。

CI/CD管道指令碼示例（GitHub Actions）：

name: Docker CI/CD

on:
  push:
    branches:
      - main

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      
      - name: Build Docker image
        run: docker build -t username/myapp:${{ github.sha }} .
      
      - name: Log in to Docker Hub
        run: echo "${{ secrets.DOCKER_PASSWORD }}" | docker login -u ${{ secrets.DOCKER_USERNAME }} --password-stdin

總結

此工作流程自動化了Docker化應用程式的構建、測試和部署階段，提供了本地和遠端測試、回滾策略以及自動化的CI/CD管道以簡化流程。

功能性需求與非功能性需求

軟體開發中需求的介紹

功能性需求

定義系統應該做什麼。它們定義系統必須具備的特定行為、特性和功能，以滿足使用者的需求。這些需求通常表示為系統應執行的動作或任務。

示例

• 使用者身份驗證 - 系統必須允許使用者使用使用者名稱和密碼登入。

• 資料處理 - 系統必須即時處理和驗證使用者輸入。

• 報表 - 系統必須每月生成銷售報表。

非功能性需求

定義系統應該如何執行。它們定義系統必須遵守的質量屬性、效能標準和約束。這些需求側重於可用性、可靠性、安全性、可擴充套件性等方面。

示例

• 效能 - 系統必須能夠處理多達1000個併發使用者，響應時間少於2秒。

• 安全 - 系統必須確保所有敏感資訊的加密。

• 可用性 - 系統必須易於使用，並且殘疾使用者也可以訪問。

功能性需求的型別

• 使用者介面需求 - 與UI元件、佈局和設計相關的需求（例如，搜尋欄）。

• 業務需求 - 描述業務規則和策略（例如，系統應根據位置應用稅率）。

• 資料管理需求 - 定義系統如何處理資料輸入、儲存和處理。

• 管理需求 - 系統管理的功能，例如使用者角色管理或訪問控制。

用例示例

描述一個示例功能需求以及它如何幫助實現業務目標。

非功能性需求的型別

效能需求

• 響應時間 - 系統對給定輸入或請求做出反應所需的時間。

• 吞吐量 - 指系統在給定時間段內可以處理資料或完成任務的速率。

• 延遲 - 指使用者操作與其對應的系統響應之間的時間延遲。

示例

響應時間 - 對於93%的使用者，頁面載入時間應小於2秒。

可擴充套件性需求

系統處理資料量、使用者或事務增長能力。

示例 - 系統應支援多達10,000個併發使用者。

安全需求

資料保護、加密和訪問控制的需求。

示例 - 密碼必須在儲存之前進行雜湊和加鹽處理。

可用性需求

與系統易用性和可學習性相關的需求。

示例 - 所有核心功能都應在不超過三次點選的情況下即可訪問。

可靠性和可用性需求

定義系統的預期正常執行時間和容錯能力。

示例 - 系統應具有99.9%的正常執行時間。

可維護性和可移植性

易於維護、除錯和遷移的需求。

示例 - 程式碼應遵循已記錄的標準以確保可維護性。

法律和合規性需求

系統必須遵守的法規和標準（例如，GDPR——通用資料保護條例）。

示例 - 使用者必須同意根據GDPR使用資料。

收集需求的技術

與利益相關者和使用者訪談，以瞭解預期。

調查問卷，用於收集來自大量受眾的反饋。

研討會和頭腦風暴會議，用於協作式需求收集。

觀察和跟班學習，以瞭解現實世界中的使用者互動。

文件分析，現有系統和策略。

原型設計和樣機，用於視覺化需求並收集反饋。

記錄功能性和非功能性需求

需求文件

• 軟體需求規格說明書（SRS）文件 - 用於詳細捕獲功能性和非功能性需求。

• 敏捷使用者故事和驗收標準 - 定義每個需求的“完成”狀態。

使用圖表

• 用例圖 - 視覺化功能性需求。

• 流程圖和序列圖 - 用於流程流和系統互動。

非功能性文件

• 質量屬性場景 - 在場景中描述非功能性需求（例如，“在伺服器發生故障的情況下，系統應在3分鐘內恢復”）。

• 最佳實踐 - 確保需求清晰、可測試且具有優先順序。

管理功能性和非功能性需求的挑戰

• 歧義和誤解 - 模糊的需求會導致誤解。使用清晰、具體的語言。需求變更：需求可能會頻繁變更；使用敏捷方法來提高靈活性。

• 功能性和非功能性目標之間的衝突 - 可能需要權衡（例如，安全性和可用性）。

• 優先順序問題 - 可能會忽略高優先順序的非功能性需求（如安全性）。

• 利益相關者一致性 - 確保所有利益相關者都同意優先順序和定義。

管理和驗證需求的最佳實踐

• 讓利益相關者參與 - 定期徵求利益相關者的反饋，以確保需求與期望相符。

• 優先順序排序需求 - 根據對業務的重要性對功能性和非功能性需求進行排序。

非功能性需求的測試

負載測試，用於效能需求。

可用性測試，用於使用者體驗。

安全審計，用於安全性和合規性需求。

迭代審查和改進，定期檢查需求的完整性和相關性。

使用自動化，使用JIRA、Confluence和Trello等工具即時跟蹤需求，以確保可追溯性。

總結

對功能性和非功能性需求採取平衡的方法對於構建強大、以使用者為中心的軟體系統至關重要。本文重點介紹了這些需求的定義、型別以及收集、記錄和驗證這些需求的方法，確保軟體專案既符合使用者期望，又符合技術標準。

什麼是資料流圖？

資料流圖介紹

DFD的定義

DFD可以解釋為系統中資料流動的圖形表示。

目的和重要性

• 用於視覺化資料在系統中的移動和互動。

• 幫助開發人員、業務分析師和利益相關者在無需瞭解技術複雜性的情況下理解流程。

主要優勢

• 簡化複雜流程。

• 提高技術和非技術利益相關者之間溝通的清晰度。

DFD元件和符號

• 流程 - 用圓圈或圓角矩形表示。描述每個流程如何將輸入轉換為輸出。

• 資料儲存 - 用開放式矩形表示，象徵著資料在系統中儲存的位置。

• 資料流 - 箭頭表示元件之間的資料移動，並標註正在傳輸的資料型別。

• 外部實體（源/宿） - 用正方形表示，表示與系統互動的外部系統或使用者。

帶簡單用例的DFD示例

資料流圖的型別和級別

• 上下文圖（0級） - 高階DFD，將整個系統顯示為單個流程以及外部實體。

• 1級DFD - 將主流程分解為子流程，包括資料流和儲存。

• 2級及以上 - 進一步分解以獲得更詳細的檢視，通常用於大型或複雜的系統。

建立資料流圖 - 分步指南

• 步驟1 - 識別外部實體（誰/什麼與系統互動）。

• 步驟2 - 定義主流程（主要系統功能）。

• 步驟3 - 繪製實體和流程之間的資料流。

• 步驟4 - 識別儲存資訊以進行處理的資料儲存。

• 步驟5 - 根據需要將高階圖表分解為較低級別，以細化並新增細節。

• 提示 - 使用一致的標籤，儘可能避免交叉線，並確保所有元件都具有清晰的標籤。

不同系統的DFD示例

• 示例1 - 線上零售系統：上下文圖說明基本資料流（使用者、支付閘道器、庫存）。1級DFD，包含“下訂單”、“處理付款”、“管理庫存”等流程。

• 示例2 - 圖書館管理系統：上下文圖顯示圖書館工作人員、會員和資料庫作為實體。1級DFD，包含“借書”、“還書”、“更新會員資訊”等流程。

• 示例3 - 銀行系統：上下文圖說明客戶、銀行和ATM作為實體。1級DFD，包含“存款”、“取款”、“查詢餘額”等流程。

資料流圖在不同行業的應用

• 醫療保健 - 視覺化患者資料在不同部門（例如，入院、診斷、計費）中的流動。

• 電子商務 - 說明客戶從瀏覽到結賬和履行的旅程。

• 銀行和金融 - 顯示ATM、分支機構和線上平臺之間用於交易和賬戶管理的資料流。

• 教育 - 描繪學生的生命週期，從註冊到畢業，包括課程管理和記錄儲存。

• 案例研究示例 - 醫院患者資料管理的示例用例圖。

建立和使用資料流圖的最佳實踐

• 保持簡單 - 避免過度複雜化；使用分層DFD級別以提高畫質晰度。

• 使用一致的符號和標籤 - 標準化符號以提高可讀性和清晰度。

• 避免線條重疊 - 透過清晰地排列元件來最大限度地減少視覺混亂。

• 與利益相關者進行驗證 - 與使用者和利益相關者確認以確保準確性。

• 迭代和改進 - 隨著系統的發展而修改，尤其是在複雜的專案中。

• 示例提示 - 顯示雜亂的DFD與組織良好的DFD，以突出最佳實踐。

常見錯誤以及如何避免

• 未定義或含糊不清的標籤 - 為所有資料流和流程使用清晰、描述性的標籤。

• 高階DFD中細節過多 - 將更精細的細節保留在較低級別，以避免混亂。

• 缺少資料儲存或資料流 - 確保包含所有所需的資料儲存和移動。

• 外部實體放置不正確 - 將外部實體保留在系統的周邊。

• 流程未連線 - 確保每個流程都有輸入和輸出資料流。

資料流圖的高階概念和未來

擴充套件的DFD

使用DFD來說明基於事件或即時的數流。

DFD建立的自動化工具

Microsoft Visio、Lucidchart和線上DFD生成器。

自動化工具的好處

更快的更新、輕鬆共享和標準化。

將DFD與其他圖表整合

將DFD與實體關係圖(ERD)或用例圖結合使用，以獲得全面的檢視。

DFD在敏捷環境中的未來

能夠快速迭代、與使用者故事整合並在複雜的系統設計中保持持續的相關性。

總結

本指南深入講解了資料流圖 (DFD) 的用途、結構以及建立和使用方面的最佳實踐。DFD 在系統分析和設計中仍然具有價值，它提供了一種直接瞭解資料流和系統架構的方法。

資料流圖 - 型別和組成部分

資料流圖 (DFD) 的用途

資料流圖 (DFD) 是一種圖形表示，它說明了資料如何在系統內流動，突出了相互互動的流程、資料儲存和外部實體。DFD 對於理解、設計和記錄資料在系統中移動的方式至關重要。透過顯示資訊來自哪裡、去向哪裡以及沿途如何轉換，DFD 幫助分析師、設計師和利益相關者清楚地瞭解系統的功能和結構，而無需深入瞭解複雜的技術細節。

關鍵概念和優勢

關鍵概念

關鍵元素 - 資料流、流程、資料儲存和外部實體。

使用 DFD 的優勢

• 視覺化的清晰性和簡潔性。

• 有助於需求分析、設計階段和故障排除。

資料流圖的型別

資料流圖 (DFD) 是分層圖，用於視覺化系統內資訊流。它們分為不同的層次，每個層次都提供越來越多的細節。

0 級 DFD - 上下文圖

0 級 DFD 也稱為上下文圖，代表系統的最高級別檢視。

用途 - 它提供了系統的廣泛概述，顯示了與其互動的主要實體（或外部系統）以及主要的資訊流。

組成部分

• 單個流程 - 通常表示為帶有標籤的單個圓圈或矩形，指示系統的整體用途（例如，“訂單處理系統”）。

• 外部實體 - 表示與系統互動的實體的正方形，例如“客戶”和“倉庫”。

• 資料流 - 顯示外部實體和系統之間主要資料流的箭頭。

1 級 DFD - 主系統的分解

1 級 DFD 擴充套件了 0 級 DFD，將主系統流程分解為子流程。它顯示了系統處理資料的更多細節。

用途 - 將主要流程分解為更小的子流程，顯示系統內部的運作方式。

組成部分

多個流程 - 系統中的每個主要活動，例如“處理訂單”、“管理庫存”、“處理付款”和“履行訂單”，都顯示為一個單獨的流程。

資料儲存 - 由開放式矩形表示，資料儲存（如“訂單資料儲存”或“庫存資料儲存”）顯示資料在系統中儲存的位置。

資料流 - 更具體的資料流指示在流程之間以及與資料儲存和實體之間傳遞的資料。

示例 - 在訂單處理系統中，1 級 DFD 將顯示諸如“處理訂單”、“檢查庫存”、“處理付款”和“發貨訂單”之類的流程，這些流程透過資料流連線。每個流程都將與資料儲存和外部實體互動，顯示比 0 級圖更具體的互動。

2 級 DFD - 詳細的流程分解

2 級 DFD 對 1 級 DFD 中的某個流程進行了更深入的探討。它代表了更精細的細節級別。

用途 - 顯示單個流程中的詳細步驟，指示為完成系統功能的一部分而採取的精確操作。

組成部分

子流程 - 每個子流程都是 1 級流程中某個流程中更細化的步驟。例如，“檢查庫存”可能包括諸如“更新庫存”和“檢查庫存可用性”之類的步驟。

其他資料儲存 - 如有必要，可以包含特定於這些更精細步驟的其他資料儲存。

資料流 - 詳細的資料流顯示選定的 1 級流程中資訊的精確移動。

示例 - 對於訂單處理系統中的“處理訂單”流程，2 級 DFD 可能將其分解為諸如“驗證訂單”、“檢查庫存”、“授權付款”和“確認訂單”之類的步驟。資料流將指定在每個步驟中檢查、儲存或修改的資料，從而清晰地顯示工作流程。

每個 DFD 層次都提供了系統越來越詳細的檢視，從而更容易系統地理解和分析複雜的工作流程。

資料流圖的組成部分

流程

• 將流程定義為系統內資料的轉換。

• 用符號和示例進行說明，例如電子商務 DFD 中的“訂單處理”。

資料儲存

• 將資料儲存定義為系統內儲存資料的地方。

• 討論命名約定和示例，例如“客戶資料”或“庫存”。使名稱易於理解。

資料流

• 將資料流定義為資料在流程、資料儲存和外部實體之間採取的路徑。

• 用帶標籤的箭頭進行說明，並強調資料流命名的清晰性。

外部實體

• 將外部實體定義為系統控制範圍之外的資料來源或目標。

DFD 流程編號

在資料流圖 (DFD) 中，流程編號是一種結構化的方法，用於顯示不同流程層次之間的層次關係。這種編號方法有助於使 DFD 更易於閱讀和組織，允許檢視者追蹤流程的起源和系統內的連線。以下是跨 DFD 層次對流程進行編號的說明：

0 級 DFD（上下文圖）

單個流程編號 - 由於 0 級提供了系統的較高層次概述，因此它表示為單個流程，沒有任何子流程。此流程通常編號為“0”（例如，“訂單處理系統 (0)”）。

用途 - “0”標籤表示這是主系統，包含所有進一步的流程。

1 級 DFD

分解主流程 - 在 1 級中，主流程（流程 0）被分解為代表系統核心功能的子流程。

編號約定 - 1 級中的每個子流程都根據其在流程流中的位置編號為1、2、3 等。

例如，在訂單處理系統中：

流程 1 - “處理訂單”

流程 2 - “管理庫存”

流程 3 - “處理付款”

流程 4 - “履行訂單”

用途 - 此編號表示每個流程都是主系統內的主要功能。

2 級 DFD（及更高級別）

分解每個 1 級流程 - 在 2 級中，每個 1 級流程都進一步分解為更小的步驟或子流程。

編號約定 - 2 級子流程使用十進位制表示法來指示它們是 1 級流程的一部分。

例如，分解“處理訂單（流程 1）”：

流程 1.1 - “驗證訂單”

流程 1.2 - “檢查庫存”

流程 1.3 - “授權付款”

流程 1.4 - “確認訂單”

如果另一個 1 級流程（例如“管理庫存（流程 2）”）被分解：

流程 2.1 - “檢查庫存可用性”

流程 2.2 - “更新庫存”

更高級別 - 如有需要，可以在 3 級 DFD 中進一步分解 2 級子流程，它將使用 1.1.1、1.1.2 等編號。

DFD 流程編號的優勢

• 清晰度 - 編號幫助使用者快速識別和追蹤不同級別中的流程和子流程。

• 組織性 - 它顯示了流程的層次結構，指示高層流程如何分解為更精細的任務。

• 輕鬆參考 - 每個流程都有一個唯一的識別符號，可以輕鬆討論和分析系統內的特定步驟。

開發系統的 DFD 模型

引言

本文提供了一份關於資料流圖 (DFD) 的全面指南，重點介紹了開發過程、型別、優勢和涉及的挑戰。它涵蓋了有助於建立高效 DFD 的實用技術、工具和最佳實踐。本指南專為系統分析師、專案經理和學生而設計。

資料流圖 (DFD) 是系統分析和設計中的一種流行方法，有助於視覺化資料如何在系統內流動、其處理點和儲存位置。透過定義和表示資料從源到目的地的流動，DFD 有助於理解複雜系統的功能。

DFD 的重要性

• 將複雜系統簡化為可管理的部分。

• 提高對系統需求的理解。

• 有助於識別潛在的系統低效率或瓶頸。

使用資料流圖的優勢

DFD 為技術和非技術利益相關者都提供了許多好處：

• 增強溝通 - 為團隊提供通用的視覺化語言。

• 明確系統需求 - 識別輸入、流程和輸出。

• 高效的系統分析 - 促進識別冗餘或瓶頸。

• 改進設計質量 - 為最佳化的資料庫和系統設計奠定基礎。

資料流圖的開發過程

步驟 1：定義系統邊界和範圍

• 識別與系統互動的所有外部實體。

• 定義 DFD 範圍之內和範圍之外的內容。

步驟 2：識別核心流程

• 查明處理資料的流程。

• 考慮分解複雜的流程以提高畫質晰度。

步驟 3：識別資料儲存

• 確定資料將在系統中儲存的位置。

• 根據資料的管理方式對這些儲存進行分類。

步驟 4：識別資料流

• 建立實體、流程和儲存之間的資料流。

• 驗證是否表示所有必要的輸入和輸出。

步驟 5：構建上下文圖 (0 級 DFD)

• 建立最高級別的 DFD，顯示單個流程和外部實體。

• 透過資料流連線實體和主流程。

步驟 6：開發詳細級別 (1 級、2 級)

• 將上下文圖中的主流程分解為子流程。

• 每個級別都新增細節，確保資料流和連線的準確性。

步驟 7：驗證和審查

• 與利益相關者一起驗證 DFD 以確保完整性。

• 根據反饋調整圖表以解決任何差距。

建立資料流圖的工具

• Lucidchart - 提供一系列 DFD 符號和協作功能。

• Microsoft Visio - 常用於組織中建立 DFD。

• Draw.io - 用於建立 DFD 和其他型別圖表免費工具。

• SmartDraw - 提供模板和易於使用的 DFD 工具。

• Visual Paradigm - 支援所有級別的 DFD 和高階功能。

每個工具都提供支援特定需求的獨特功能，例如協作、模板可用性和匯出選項。

示例：電子商務訂單處理系統 DFD

上下文圖

電子商務系統包括客戶和支付閘道器等外部實體，這些實體在一個名為“訂單處理”的高階流程中表示。

0 級 DFD

訂單管理 - 接收和處理訂單。

庫存系統 - 管理產品可用性。

支付處理 - 處理來自支付閘道器的付款。

客戶資料庫 - 儲存客戶資訊和訂單歷史記錄。

開發 DFD 的挑戰

• 含糊不清的需求 - 不完整或不清楚的需求會導致 DFD 不準確。

• 複雜的系統 - 大型系統可能變得過於複雜，導致難以解釋的 DFD。

• 需求變更 - DFD 需要隨著需求變化而更新。

• 利益相關者意見不一致 - 對 DFD 的準確性或細節水平缺乏共識可能會延遲批准。

DFD 開發的最佳實踐

• 保持簡單 - 避免在較高 DFD 層次中出現不必要的複雜性。

• 讓利益相關者參與進來 - 早期與所有相關方進行協作。

• 使用一致的命名 - 清晰地標記實體、流程和資料儲存。

• 定期審查和改進− 透過迭代審查確保DFD的準確性。

• 限制圖表層級− 限制細節深度以避免過度複雜。

結論

資料流圖 (DFD) 是系統分析、設計和溝通的寶貴工具。它們能夠更好地理解系統功能和資料移動，為技術和非技術利益相關者提供清晰的認識。透過適當的開發和最佳實踐，DFD 有助於有效的設計、分析和持續的系統改進。

資料流圖 - 平衡

資料流圖和平衡介紹

什麼是資料流圖 (DFD)？

資料流圖 (DFD) 以視覺化的方式表示系統內的資料流，顯示過程、資料儲存、外部實體和資料流。DFD 是分層結構的−

• 上下文圖− 將系統作為單個過程的高階概述。

• 0級DFD− 將單個過程分解成主要功能。

• 1級及以上− 將過程進一步分解成子過程。

什麼是DFD中的平衡？

平衡是指在DFD的不同級別之間保持資料流的一致性。在將過程分解到較低級別時，進入或退出較高級別過程的所有資料流都應與該過程的較低級別DFD中的資料流匹配。

平衡是DFD中的一個基本概念，它確保圖表不同級別的資料保持一致性和清晰性。

資料流圖中平衡的重要性

平衡在DFD中起著至關重要的作用，因為它−

• 確保資料一致性− 防止不同級別之間的資料不匹配。

• 提高準確性− 維持系統分析中資訊的完整性。

• 增強清晰度− 幫助利益相關者理解系統功能，避免混淆。

• 支援有效的系統設計− 協助開發人員和分析師保持設計的可靠性和易於解釋性。

平衡不良的後果

• 資料不一致

• 對系統需求的誤解

• 系統設計和實現中的錯誤增多

DFD平衡的原則

從一個DFD級別移動到另一個級別時，平衡需要遵循以下原則−

• 資料流的一致性− 較高級別上的每個輸入或輸出都必須在較低級別上反映。

• 資料流對齊− 資料流的名稱和用途應在各個級別保持一致。

• 過程關聯− 確保分解後的DFD中的過程與父過程在邏輯上對齊。

資料流圖平衡的技術

技術1：使用級別平衡

分解過程時−

• 保持父DFD和子DFD之間的外部資料流相同。

• 例如，如果0級中的“銷售處理”過程具有“客戶訂單”和“訂單確認”的資料流，則1級必須直接或透過子過程反映這些流。

技術2：匹配資料儲存

資料儲存在各個級別必須一致。如果資料儲存出現在較高級別的DFD中，則在與分解過程相關的較低級別中也應出現。

技術3：一致的資料流命名

在DFD的所有級別使用一致的命名約定，以減少歧義並提高畫質晰度。

示例：DFD中的平衡

考慮一個線上圖書館管理系統。

0 級 DFD

圖書館系統包括−

過程− 借書、還書、更新目錄。

資料流− 借書請求、還書確認、目錄更新

1級DFD（分解“借書”）

子過程− 驗證會員資格、檢查圖書可用性、發放圖書。

資料流− 借書請求、會員驗證、圖書發放確認。

為了平衡，0級中與“借書”相關的所有資料流都必須出現在1級圖中。這包括−

1. 借書請求（從使用者到系統）

2. 圖書發放確認（從系統到使用者）

解釋

此處的平衡確保在0級進入或離開“借書”的任何資料流都保留在1級。這種一致性避免了資料在分解過程中“丟失”。

DFD平衡的工具

1. Lucidchart− 提供模板和工具來視覺化分層DFD，具有支援多級平衡的功能。

2. Microsoft Visio− 一個建立結構化DFD的強大工具，具有內建的對齊和平衡流的支援。

3. SmartDraw− 提供易於使用的DFD模板，有助於建立平衡的圖表。

4. Visual Paradigm− 提供自動檢查平衡DFD的功能，幫助分析師避免不一致。

5. Draw.io− 一個免費工具，支援多個DFD級別，使初學者更容易實現平衡。

資料流圖平衡中的挑戰

1. 資料流不一致− 當資料流在DFD級別之間命名或描述不一致時，就會出現一個常見問題，導致錯位。

2. 複雜的過程− 對於複雜的系統，在保持資料流一致性的同時分解過程可能很困難且耗時。

3. 範圍蔓延− 隨著系統的發展，新的需求可能會改變資料流，導致不平衡的圖表需要重新評估。

4. 利益相關者誤解− 對於不熟悉技術圖表的利益相關者來說，平衡可能難以解釋，導致對資料流一致性要求的混淆。

有效DFD平衡的最佳實踐

1. 維護單一事實來源− 使用主資料流列表，並在DFD演變時更新它。

2. 迭代驗證− 經常審查每個級別以確保資料流一致。

3. 標準化命名約定− 為每個資料流使用清晰、描述性的名稱，使平衡更簡單。

4. 限制級別− 避免過度分解，以防止DFD複雜性難以管理。

5. 利益相關者參與− 早期讓利益相關者參與進來，以協調期望並確保系統流的準確表示。

結論

平衡是資料流圖製圖的關鍵組成部分，它確保了各個級別的資料流完整性和一致性。掌握平衡技術允許系統分析師和開發人員生成可靠且易於理解的DFD，這些DFD準確地反映了系統功能。遵守最佳實踐並利用合適的工具可以簡化平衡過程，幫助維護系統模型的清晰度和可靠性。

資料流圖 - 分解

引言

資料流圖 (DFD) 是系統分析和設計中必不可少的工具，使利益相關者能夠視覺化系統內資訊流。在DFD的許多原則中，分解作為將複雜系統分解成可管理元件的關鍵概念脫穎而出。本文探討了DFD中的分解，包括其重要性、技術和實際應用。

理解DFD中的分解

分解是將大型複雜系統分解成更小、更易於管理的元件的過程。在DFD中，這涉及到將高階過程逐步詳細地分解成子過程，每個子過程都有其資料流和互動。

為什麼要分解？

• 簡化複雜系統的分析。

• 增強利益相關者的清晰度。

• 允許對系統特定部分進行詳細的文件記錄。

• 識別流程中的低效率、冗餘或瓶頸。

DFD分解的級別

DFD中的分解遵循分層方法，從系統的最抽象表示開始，逐步深入到更精細的細節。

上下文圖

上下文圖表示最高的抽象級別。它將整個系統描繪成一個單一過程，並關注−

• 外部實體

• 系統與其環境之間主要的資料流

示例− 圖書館管理系統的上下文圖可能會顯示諸如借書和還書之類的過程，而無需詳細說明這些任務是如何在內部管理的。

1級DFD

1級DFD將上下文圖中的單個過程分解成主要子過程。它顯示−

• 過程之間的內部資料流

• 與這些過程互動的資料儲存

示例− 借書可能會分解成−

1. 檢查使用者憑據

2. 檢索圖書詳細資訊

3. 更新資料庫

N級DFD

更高級別的DFD（2級、3級等）將過程進一步分解成更細粒度的任務。這種迭代細節化持續進行，直到每個過程都足夠簡單，可以直接實現。

分解DFD的步驟

分解需要系統步驟來確保準確性和一致性−

步驟1− 識別關鍵流程

從需要詳細說明的高階過程（來自上下文圖）開始。選擇涉及多個任務或重要互動的過程。

步驟2− 定義子過程

對於每個高階過程，識別執行特定任務的子過程。確保子過程與系統目標一致。

步驟3− 對映資料流

詳細說明資料如何在子過程、資料儲存和外部實體之間移動。使用清晰一致的標籤。

步驟4− 與利益相關者進行驗證

與利益相關者一起審查分解後的圖表，以確保完整性和準確性。這可以防止誤解並收集反饋。

步驟5− 根據需要進行迭代

根據複雜性或利益相關者的需求進一步改進子過程。

DFD分解中的最佳實踐

為了實現有效的分解，請考慮以下最佳實踐−

堅持一致性

在各個級別保持一致的符號、標籤和命名約定。

避免過度分解

過多的級別會使理解複雜化。當過程足夠簡單以供實現時停止。

關注功能

根據功能分解過程，而不是任意劃分。

使用模組化設計

確保子過程儘可能獨立執行。

記錄每個級別

為每個DFD級別提供文件，解釋其元素和關係。

常見挑戰和解決方案

挑戰1− 資料流重疊

解決方案− 清晰地定義過程的邊界並確保正確的標籤。

挑戰2− 缺乏利益相關者的投入

解決方案− 讓利益相關者參與審查和驗證階段。

挑戰3− 範圍蔓延

解決方案− 將分解限制在專案範圍內。在一開始就定義清晰的邊界。

挑戰4− 過程的錯誤表示

解決方案− 與領域專家合作以準確地描繪過程。

分解在現實世界場景中的應用

分解廣泛用於各個領域來設計和最佳化系統。一些例子包括−

軟體開發

分解有助於將系統功能分解成模組，指導開發人員構建可擴充套件和可維護的軟體。

業務流程再造

透過視覺化工作流程，組織可以識別流程中的瓶頸、冗餘或低效之處。

醫療系統

分解後的DFD有助於對映患者資料流，確保醫療記錄的安全高效管理。

電子商務平臺

電子商務系統使用分解來定義關鍵流程，例如訂單管理、庫存跟蹤和支付處理。

結論

分解是資料流圖不可或缺的方面，它使系統分析師和設計人員能夠解開復雜性並建立高效的系統。透過系統地分解高階流程，分解可以促進清晰度，增強協作，並確保更好的系統設計。隨著組織越來越依賴結構化的方法進行系統開發，掌握DFD分解對於分析師和利益相關者來說仍然是一項重要的技能。

系統設計 - 資料庫

系統設計和資料庫簡介

系統設計是構建可擴充套件、高效和強大的軟體解決方案的關鍵方面。系統設計的核心在於資料庫，這是一個結構化的儲存庫，用於儲存、組織和檢索系統操作必不可少的資料。

資料庫在系統設計中的作用不容忽視。它們確保資料一致性，支援併發操作，並構成業務邏輯的基礎。本節將探討基礎概念，包括資料庫在系統設計中的重要性及其用途概述。

資料庫型別

資料庫有多種形式，每種形式都適用於特定的用例。瞭解它們的型別對於為給定系統選擇合適的資料庫至關重要。

1. 關係資料庫 (RDBMS)− 透過使用外部索引鍵以關係格式儲存資料。示例包括 MySQL、PostgreSQL 和 Oracle。這些資料庫使用結構化查詢語言 (SQL) 來管理預定義模式中的資料。

2. NoSQL 資料庫− 非關係型資料庫。包括文件儲存（如 MongoDB）、鍵值儲存（如 Redis）和列式資料庫（如 Cassandra）。這些資料庫針對靈活性和水平擴充套件進行了最佳化。

3. NewSQL 資料庫− RDBMS 和 NoSQL 資料庫的混合體，在保持 ACID（原子性、一致性、隔離性、永續性）一致性的同時提供可擴充套件性。示例：CockroachDB、VoltDB、Google Spanner。

4. 記憶體資料庫− 將資料儲存在 RAM 或磁碟中，例如 H2、Redis 和 Memcached，它們透過將資料儲存在 RAM 中來優先考慮速度。

5. 圖資料庫− 它們使用具有節點、邊和屬性的圖結構來表示和儲存資料。示例包括 Neo4j 和 ArangoDB，適用於關係密集型資料，例如社交網路。

資料庫系統設計的主要組成部分

資料庫系統設計不僅僅是選擇一種資料庫型別。它包含幾個組成部分：

• 模式設計− 資料結構的藍圖。

• 索引− 增強查詢效能。

• 分片− 對資料庫進行分割槽以實現可擴充套件性。

• 複製− 確保高可用性和容錯性。

• 一致性模型−

  • 強一致性− 節點之間立即實現資料一致性。

  • 最終一致性− 在分散式系統中為了效能而優先考慮。

資料庫規範化和模式設計

模式設計是系統效率的核心，它涉及將資料組織成表並定義關係。本節將探討：

規範化− 透過將表分成更小的單元來消除資料冗餘並提高一致性的過程。

反規範化− 規範化的反面，用於需要更快讀取操作的系統。

最佳實踐：

1. 瞭解資料訪問模式。

2. 選擇規範化和反規範化之間的正確平衡。

3. 使用 ER 圖等工具設計模式。

現實場景和逐步的模式示例將說明這些概念。

資料庫可擴充套件性和效能最佳化

現代系統需要高度可擴充套件和高效能的資料庫。關鍵策略包括：

1. 垂直擴充套件− 為單個伺服器新增更多資源。

2. 水平擴充套件− 將負載分佈到多個伺服器。

3. 快取− 使用 Redis 或 Memcached 等工具來儲存經常訪問的資料。

4. 查詢最佳化− 編寫高效的查詢並使用索引。

5. 負載均衡− 均勻地分配資料庫查詢。

系統設計中的 NoSQL 與 SQL

在系統設計中選擇 NoSQL 和 SQL 至關重要。本節比較這兩種範例：

SQL 資料庫

優點− 資料完整性、ACID 一致性、強大的查詢功能。

缺點− 對非結構化資料的靈活性有限。

NoSQL 資料庫

優點− 可擴充套件性、無模式設計、針對大資料進行了最佳化。

缺點− 一致性保證較弱（例如，最終一致性）。

資料庫系統設計中的挑戰

設計資料庫系統充滿了挑戰：

1. 處理高併發流量− 每秒管理數百萬個查詢。

2. 一致性與可用性− 高可用性是指設計為長時間連續執行而不會出現故障的系統。CAP 定理突出了權衡。該定理指出，分散式資料儲存不可能同時提供以下三種保證：一致性、可用性和分割槽容錯性。

3. 資料安全− 確保符合 GDPR（通用資料保護條例）等標準。

4. 備份和恢復− 實施故障轉移策略。

資料庫系統設計的未來趨勢

資料庫的未來正在受到技術進步的影響，例如：

1. AI 驅動的資料庫− 利用機器學習進行查詢最佳化。

2. 區塊鏈資料庫− 用於資料完整性的去中心化系統。

3. 邊緣資料庫− 針對物聯網和邊緣計算進行了最佳化。

結論

資料庫是系統設計的基石。從模式規劃到可擴充套件性，精心設計的資料庫可確保系統能夠隨著需求的變化而發展和適應。透過理解本文中討論的原則，開發人員和架構師可以構建既強大又可擴充套件的系統。

LLD 中身份驗證和授權的區別

什麼是身份驗證？

身份驗證是確認使用者在計算機系統上宣告身份的行為。與身份識別相反，身份驗證是驗證個人或事物身份的過程。必須驗證個人身份，必須使用數字證書驗證網站的有效性，必須對文物進行碳年代測定，並且產品或檔案不得是偽造的。

確定聲稱的使用者身份的過程稱為身份驗證。這是安全程式的第一階段。在小於或等於以下時間完成身份驗證過程：

• 密碼− 最流行的身份驗證因素是使用者名稱和密碼。當用戶提供正確的資訊時，系統將驗證 ID 並授權訪問。

• 一次性 PIN 碼− 僅允許訪問一個會話或事務。

• 身份驗證應用程式− 生成安全程式碼，允許透過第三方訪問。

• 生物識別識別− 要訪問系統，使用者必須提供指紋和眼部掃描。

在提供訪問許可權之前，系統可能需要正確驗證多個因素。這種多因素身份驗證 (MFA) 要求通常允許提供超出密碼本身所能提供的額外保護。

什麼是授權？

授權是為資源分配許可權/特權的能力，它與一般的資訊安全和特定的計算機安全、訪問控制有關。“授權”在更正式的意義上是指建立訪問策略的過程。在系統安全中，授權是指授予對指定資源或功能的訪問許可權的過程。該術語通常與訪問控制和客戶端許可權互換使用。

許可權可以允許某人從伺服器下載特定檔案，或向特定使用者提供程式的管理員訪問許可權。

在安全環境中，始終需要認證才能獲得授權。在組織管理員授予對請求資源的訪問許可權之前，使用者必須首先確認其身份。

身份驗證與授權

身份驗證和授權是登入過程中的兩個獨立階段。要正確實現 IAM 解決方案，必須瞭解兩者之間的區別。

假設一個人在家人度假期間靠近一扇關著的門來照顧寵物。個人需要以下物品：

• 獲得了鑰匙型別的身份驗證− 就像門鎖系統只允許具有正確憑據的使用者訪問一樣，它只向具有適當鑰匙的使用者提供訪問。

• 以許可證形式進行授權− 一旦進入室內，個人就可以進入廚房並有權開啟裝有寵物食品的櫥櫃。個人可能沒有許可權進入臥室稍微休息一下。

在本例中，身份驗證和授權一起使用。您有權進入寵物保姆的家（身份驗證），這使您可以訪問特定位置（授權）。

輸入/輸出和表單設計

輸入設計

在資訊系統中，輸入是經過處理以產生輸出的原始資料。在輸入設計期間，開發人員必須考慮輸入裝置，例如 PC、MICR、OMR 等。

因此，系統輸入的質量決定了系統輸出的質量。設計良好的輸入表單和螢幕具有以下屬性：

• 它應該有效地服務於特定目的，例如儲存、記錄和檢索資訊。

• 它確保正確且準確地完成。

• 它應該易於填寫且簡單明瞭。

• 它應該關注使用者的注意力、一致性和簡潔性。

• 所有這些目標都是通過了解有關以下方面的基本設計原則來實現的：

  • 系統需要哪些輸入？

  • 終端使用者如何響應表單和螢幕的不同元素。

輸入設計的目標

輸入設計的目標是：

• 設計資料輸入和輸入過程

• 減少輸入量

• 為資料捕獲設計源文件或設計其他資料捕獲方法

• 設計輸入資料記錄、資料輸入螢幕、使用者介面螢幕等。

• 使用驗證檢查並開發有效的輸入控制。

資料輸入方法

設計適當的資料輸入方法對於防止在輸入資料時出錯非常重要。這些方法取決於資料是由客戶在表單上手動輸入然後由資料輸入操作員輸入，還是由使用者直接在 PC 上輸入。

系統應透過以下方式防止使用者出錯：

• 清晰的表單設計，留出足夠的空間以便清晰地書寫。
• 清晰的填寫表單說明。
• 清晰的表單設計。
• 減少按鍵次數。
• 立即提供錯誤反饋。

一些流行的資料輸入方法包括：

• 批處理輸入方法（離線資料輸入方法）
• 線上資料輸入方法
• 計算機可讀表單
• 互動式資料輸入

輸入完整性控制

輸入完整性控制包括許多方法，可以消除終端使用者常見的輸入錯誤。它們還包括對各個欄位值的檢查；既包括格式，也包括所有輸入的完整性。

使用事務日誌建立資料輸入和其他系統操作的審計跟蹤，這提供了資料庫中所有更改的記錄，以便在發生任何故障時提供安全性和恢復手段。

輸出設計

任何系統的輸出設計都是最重要的任務。在輸出設計過程中，開發人員需要確定所需的輸出型別，並考慮必要的輸出控制和原型報表佈局。

輸出設計的目標

輸入設計的目標是：

• 開發能夠滿足預期目的並避免產生不需要的輸出的輸出設計。

• 開發滿足終端使用者需求的輸出設計。

• 交付適當數量的輸出。

• 以適當的格式形成輸出，並將其定向到正確的人員。

• 使輸出能夠及時用於做出正確的決策。

現在讓我們來看一下各種型別的輸出：

外部輸出

製造商為印表機建立和設計外部輸出。外部輸出使系統能夠觸發接收者採取行動，或向接收者確認行動。

一些外部輸出被設計成周轉輸出，它們以表單的形式實現，並作為輸入重新進入系統。

內部輸出

內部輸出存在於系統內部，由終端使用者和管理人員使用。它們支援管理層的決策和報告。

管理資訊系統產生三種類型的報告：

• 詳細報告 - 它們包含幾乎沒有過濾或限制的當前資訊，用於協助管理規劃和控制。

• 彙總報告 - 它們包含趨勢和潛在問題，這些問題經過分類和總結，專為不想檢視詳細資訊的管理人員生成。

• 例外報告 - 它們包含例外情況，在向管理人員呈現資訊之前，會根據某些條件或標準過濾資料。

輸出完整性控制

輸出完整性控制包括用於識別接收系統的路由程式碼，以及用於確認成功接收由網路協議處理的訊息的驗證訊息。

列印或螢幕格式的報告應包括報告列印的日期/時間和資料。多頁報告包含報告標題或描述以及頁碼。預印表格通常包含版本號和有效日期。

表單設計

表單和報表都是輸入和輸出設計的產物，是包含指定資料的業務文件。主要區別在於表單提供資料輸入欄位，而報表純粹用於閱讀。例如，訂單表單、就業申請和信用申請等。

• 在表單設計過程中，設計人員應該瞭解：

  • 誰將使用它們

  • 它們將在哪裡交付

  • 表單或報告的目的

• 在表單設計中，自動化設計工具增強了開發人員建立表單和報表原型並將其提交給終端使用者進行評估的能力。

良好表單設計的目標

良好的表單設計對於確保以下方面至關重要：

• 透過提供正確的順序、資訊和清晰的標題來保持螢幕簡潔。

• 透過使用適當的表單來滿足預期目的。

• 確保準確填寫表單。

• 透過使用圖示、反向影片或閃爍游標等使表單更具吸引力。

• 方便導航。

表單型別

單頁表單

• 這是一種手動或機器準備並在紙上列印的單份表單。對於原始副本的額外副本，碳紙被插入副本之間。

• 這是一種設計、列印和複製最簡單且最便宜的表單，使用量較少。

套裝/撕頁式表單

• 這些是紙張，其中一次性碳紙插入單元集中，用於手寫或機器使用。

• 碳紙可以是藍色或黑色，標準等級中等強度。通常，藍色碳紙最適合手寫表單，而黑色碳紙最適合機器使用。

連續條/摺疊式表單

• 這些是多個單元表單，以連續條的形式連線，每個表單對之間都有穿孔。

• 對於大批次使用，這是一種成本較低的方法。

無碳複寫紙 (NCR)

• 它們使用無碳紙，這種紙張具有兩種化學塗層（膠囊），一種在紙張正面，另一種在紙張背面。

• 施加壓力時，這兩個膠囊相互作用併產生影像。

測試和質量保證

需要在每個開發階段檢查軟體系統預期的行為和進展方向，以避免工作重複、時間和成本超支，並確保在規定時間內完成系統。需要在每個開發階段檢查軟體系統預期的行為和進展方向，以避免工作重複、時間和成本超支，並確保在規定時間內完成系統。

系統測試和質量保證有助於檢查系統。它包括：

• 產品級質量（測試）
• 流程級質量。

讓我們簡要了解一下：

測試

測試是一個過程或活動，它根據指定的使用者需求檢查軟體的功能和正確性，以提高系統的質量和可靠性。它是系統開發中一種昂貴、耗時且關鍵的方法，需要對整個測試過程進行適當的規劃。

成功的測試是能夠發現錯誤的測試。它以明確的意圖執行程式以查詢錯誤，即使程式失敗。這是一個評估系統的過程，旨在建立一個強大的系統，主要關注系統的薄弱環節或軟體。

系統測試的特點

系統測試從模組級別開始，然後逐步整合整個軟體系統。在測試系統時，會在不同的時間使用不同的測試技術。對於小型專案，由開發人員進行；對於大型專案，由獨立的測試小組進行。

系統測試階段

測試涉及以下階段：

測試策略

這是一個宣告，它提供有關用於測試系統的各個級別、方法、工具和技術的資訊。它應該滿足組織的所有需求。

測試計劃

它提供了一個測試系統的計劃，並驗證被測系統是否滿足所有設計和功能規範。測試計劃提供以下資訊：

• 每個測試階段的目標
• 用於測試的方法和工具
• 每個測試活動所需的責任和時間
• 工具、設施和測試庫的可用性
• 規劃和執行測試所需的程式和標準
• 成功完成測試過程的因素

測試用例設計

• 為要測試的系統的每個模組確定多個測試用例。

• 每個測試用例都將指定如何測試特定需求或設計決策的實現，以及測試成功的標準。

• 測試用例以及測試計劃作為系統規範文件的一部分或稱為測試規範或測試描述的單獨文件進行記錄。

測試流程

它包含應遵循的步驟以執行每個測試用例。這些程式在稱為測試過程規範的單獨文件中指定。本檔案還指定報告測試結果的任何特殊要求和格式。

測試結果文件

測試結果檔案包含有關已執行的測試用例總數、錯誤數量和錯誤性質的簡要資訊。然後根據測試規範中的標準評估這些結果，以確定測試的總體結果。

測試型別

測試可以有多種型別，根據要發現的錯誤型別進行不同型別的測試：

單元測試

也稱為程式測試，它是一種測試，其中分析師獨立地測試或關注每個程式或模組。其目的是至少執行模組的每個語句一次。

• 在單元測試中，無法保證程式的準確性，並且難以詳細測試各種輸入組合。

• 與其他測試技術相比，它可以識別程式中的最大錯誤。

整合測試

在整合測試中，分析師測試多個模組一起工作的情況。它用於查詢系統與其原始目標、當前規範和系統文件之間的差異。

• 在這裡，分析師試圖查詢模組設計資料長度、型別和資料元素名稱不同規範的區域。

• 它驗證檔案大小是否足夠以及索引是否已正確構建。

功能測試

功能測試確定系統是否根據其規範和相關的標準文件正確執行。功能測試通常從系統的實現開始，這對於系統的成功至關重要。

功能測試分為兩類：

• 正向功能測試 - 它涉及使用有效輸入測試系統，以驗證產生的輸出是否正確。

• 反向功能測試 - 它涉及使用無效輸入和不需要的操作條件測試軟體。

系統測試規則

為了成功進行系統測試，您需要遵循以下規則：

• 測試應基於使用者的需求。

• 在編寫測試指令碼之前，應徹底瞭解業務邏輯。

• 應儘快完成測試計劃。

• 測試應由第三方進行。

• 它應該在靜態軟體上執行。

• 應針對有效和無效的輸入條件進行測試。

• 應審查和檢查測試以降低成本。

• 應在軟體上進行靜態和動態測試。

• 應記錄測試用例和測試結果。

質量保證

這是對系統或軟體產品及其文件的審查，以確保系統滿足需求和規範。

• 質量保證的目的是透過根據規範持續交付產品來增強客戶的信心。

• 軟體質量保證 (SQA) 是一種技術，它包括軟體專業人員應用的程式和工具，以確保軟體滿足其預期用途和效能的指定標準。

• SQA 的主要目標是向管理層提供軟體專案及其開發產品的正確和準確的可視性。

• 它在系統開發的整個生命週期中審查和稽核軟體產品及其活動。

質量保證的目標

進行質量保證的目標如下：

• 監控軟體開發過程和最終開發的軟體。

• 確保軟體專案是否正在實施管理層設定的標準和程式。

• 通知各個小組和個人有關 SQA 活動以及這些活動的結果。

• 確保軟體中未解決的問題得到上級管理層的處理。

• 識別產品、流程或標準中的缺陷，並予以修復。

質量保證級別

為了認證軟體產品，需要執行多個級別的質量保證和測試。

級別 1 - 程式碼走查

在此級別，檢查離線軟體是否存在任何違反官方編碼規則的情況。通常，重點放在文件檢查和程式碼註釋級別。

級別 2 - 編譯和連結

在此級別，檢查軟體是否可以在所有官方平臺和作業系統上進行編譯和連結。

級別 3 - 常規執行

在此級別，檢查軟體是否可以在各種條件下正常執行，例如特定數量的事件以及大小不同的事件規模等。

級別 4 - 效能測試

在此最終級別，檢查軟體的效能是否滿足先前指定的效能級別。

系統實施和維護

實施是確保資訊系統可執行的過程。它包括：

• 從零開始構建新系統
• 從現有系統構建新系統。

實施允許使用者接管系統執行以進行使用和評估。這包括培訓使用者作業系統並規劃順利轉換。

培訓

系統中的人員必須詳細瞭解他們的角色、如何使用系統以及系統能夠或不能做什麼。設計精良且技術精湛的系統的成功或失敗可能取決於它們的操作和使用方式。

培訓系統操作員

必須對系統操作員進行適當的培訓，以便他們能夠處理所有可能的執行，包括常規執行和非常規執行。應培訓操作員識別常見的故障、如何識別它們以及出現故障時應採取的步驟。

培訓包括建立故障排除列表，以識別可能出現的問題及其補救措施，以及在出現意外或異常問題時聯絡的個人姓名和電話號碼。

培訓還包括熟悉執行程式，這涉及逐步完成使用新系統所需的活動序列。

使用者培訓

• 終端使用者培訓是計算機資訊系統開發的重要組成部分，必須向員工提供培訓，使他們能夠自行解決問題。

• 使用者培訓包括如何操作裝置、對系統問題進行故障排除以及確定出現的問題是由裝置還是軟體引起的。

• 大多數使用者培訓都涉及系統本身的操作。必須設計培訓課程，以幫助使用者快速為組織動員。

培訓指南

• 設定可衡量的目標
• 採用適當的培訓方法
• 選擇合適的培訓場地
• 使用易於理解的培訓材料

培訓方法

講師主導式培訓

它涉及培訓師和學員，他們必須同時見面，但不一定在同一地點。培訓課程可以是一對一的，也可以是合作的。它分為兩種型別：

虛擬教室

在這種培訓中，培訓師必須同時與學員見面，但不一定在同一地點。這裡使用的主要工具包括：視訊會議、基於文字的網際網路中繼聊天工具或虛擬現實軟體包等。

普通教室

培訓師必須同時在同一地點與學員見面。這裡使用的主要工具包括黑板、投影儀、液晶投影儀等。

自定進度培訓

它涉及培訓師和學員，他們不需要在同一地點或同一時間見面。學員透過在方便時訪問課程來學習技能。它分為兩種型別：

多媒體培訓

在這種培訓中，課程以多媒體格式呈現，並存儲在 CD-ROM 上。它最大限度地降低了在沒有外部程式設計師幫助的情況下開發內部培訓課程的成本。

基於網路的培訓

在這種培訓中，課程通常以超媒體格式呈現，並開發為支援網際網路和內聯網。它為終端使用者提供即時培訓，並允許組織定製培訓需求。

轉換

這是從舊系統遷移到新系統的一個過程。它提供了一種易於理解和結構化的途徑，以改善管理層和專案團隊之間的溝通。

轉換計劃

它包含對新系統實施和投入執行期間必須發生的所有活動的描述。它預料到可能出現的問題以及解決這些問題的方案。

它包括以下活動：

• 命名所有要轉換的檔案。
• 確定在轉換期間開發新檔案所需的資料要求。
• 列出所有所需的新文件和程式。
• 確定每個活動中使用的控制措施。
• 確定每個活動的負責人。
• 驗證轉換進度。

轉換方法

有四種轉換方法：

• 並行轉換
• 直接切換轉換
• 試點方法
• 分階段實施方法

檔案轉換

這是將一種檔案格式轉換為另一種檔案格式的過程。例如，可以將 WordPerfect 格式的檔案轉換為 Microsoft Word 格式。

為了成功轉換，需要一個轉換計劃，其中包括：

• 瞭解目標系統和對現有系統的理解
• 團隊合作
• 自動化方法、測試和並行操作
• 持續支援以糾正問題
• 更新系統/使用者文件等

許多流行的應用程式都支援開啟和儲存相同型別的其他檔案格式。例如，Microsoft Word 可以開啟和儲存許多其他文字處理格式的檔案。

實施後評估審查 (PIER)

PIER 是一種用於評估專案結果並確定專案是否為流程、產品或服務帶來預期效益的工具或標準方法。它使使用者能夠驗證專案或系統是否在指定的時間段內和計劃的成本內達到了預期的結果。

PIER 透過評估專案的開發和管理流程來確保專案達到了其目標。

PIER 的目標

進行 PIER 的目標如下：

• 確定專案相對於預計成本、效益和時間表的成功程度。

• 確定為專案增加額外價值的機會。

• 確定專案的優缺點，以便將來參考並採取適當的行動。

• 透過改進成本估算技術，對專案的未來提出建議。

審查過程應包括以下工作人員：

• 專案團隊和管理層
• 使用者人員
• 戰略管理人員
• 外部使用者

系統維護/增強

維護是指將某些東西恢復到其原始狀態。增強是指新增、修改程式碼以支援使用者規範的變化。系統維護使系統符合其原始要求，增強透過結合新要求來增加系統能力。

因此，維護更改現有系統，增強為現有系統新增功能，而開發則替換現有系統。它是系統開發的重要組成部分，包括糾正系統設計和實施中的錯誤、更新文件和測試資料的活動。

維護型別

系統維護可分為三種類型：

• 糾正性維護 - 使使用者能夠執行修復和糾正剩餘問題。

• 適應性維護 - 使使用者能夠替換程式的功能。

• 完善性維護 - 使使用者能夠根據使用者的需求和不斷變化的需求修改或增強程式。

系統安全和審計

系統審計

這是一項調查，用於審查執行系統的效能。進行系統審計的目標如下：

• 比較實際效能和計劃性能。

• 驗證系統的既定目標在當前環境中是否仍然有效。

• 評估既定目標的實現情況。

• 確保基於計算機的財務和其他資訊的可靠性。

• 確保處理過程中包含所有記錄。

• 確保防止欺詐。

計算機系統使用情況審計

資料處理審計員審計計算機系統的使用情況以對其進行控制。審計員需要由計算機系統本身獲得的控制資料。

系統審計員

審計員的角色始於系統開發的初始階段，以便生成的系統是安全的。它描述了一種可以記錄的系統利用率的概念，這有助於負載規劃和決定硬體和軟體規格。它表明了計算機系統的明智使用以及系統可能的濫用。

審計跟蹤

審計跟蹤或審計日誌是一項安全記錄，其中包含誰訪問了計算機系統以及在給定時間段內執行了哪些操作。審計跟蹤用於詳細跟蹤系統上資料的更改方式。

它提供了交易在其處理過程中所受各種控制技術的證據檔案。審計跟蹤並非獨立存在。它們是作為追回丟失交易的會計的一部分進行的。

審計方法

審計可以透過兩種不同的方式進行：

圍繞計算機進行審計

• 獲取樣本輸入並手動應用處理規則。
• 將輸出與計算機輸出進行比較。

透過計算機進行審計

• 建立審計跟蹤，允許檢查選定的中間結果。
• 控制總數提供中間檢查。

審計注意事項

審計考慮使用敘述和模型來檢查分析結果，以識別由於功能錯位、流程或功能分割、資料流中斷、資料缺失、冗餘或不完整的處理以及未解決的自動化機會而導致的問題。

本階段的活動如下：

• 識別當前環境問題
• 識別問題原因
• 識別替代方案
• 評估和可行性分析每個方案
• 選擇和推薦最實用和合適的方案
• 專案成本估算和成本效益分析

安全

系統安全是指保護系統免受盜竊、未經授權的訪問和修改以及意外或非故意損壞。在計算機系統中，安全涉及保護計算機系統的所有部分，包括資料、軟體和硬體。系統安全包括系統隱私和系統完整性。

• 系統隱私涉及保護個人系統免受未經相關個人許可/知情的情況下訪問和使用。

• 系統完整性關注系統中原始資料和處理資料的質量和可靠性。

控制措施

有多種控制措施，可以大致分為以下幾類：

備份

• 根據時間緊迫性和大小，每天/每週定期備份資料庫。

• 以較短的時間間隔進行增量備份。

• 備份副本儲存在安全的遠端位置，這對於災難恢復尤其必要。

• 如果這是一個非常關鍵的系統並且在儲存到磁碟之前不能容忍任何中斷，則執行重複系統並映象所有事務。

物理訪問設施控制

• 物理鎖和生物識別身份驗證。例如，指紋
• 保安人員檢查身份證或入場證。
• 識別所有讀取或修改資料的人員，並在檔案中記錄。

使用邏輯或軟體控制

• 密碼系統。
• 加密敏感資料/程式。
• 培訓員工進行資料維護/處理和安全。
• 連線到網際網路時使用防病毒軟體和防火牆保護。

風險分析

風險是失去有價值東西的可能性。風險分析始於透過識別系統的漏洞及其影響來規劃安全系統。然後制定計劃來管理風險並應對災難。這樣做是為了評估可能發生的災難及其成本的機率。

風險分析是由具有不同背景的專家組成的團隊工作，例如化學品、人為錯誤和工藝裝置。

進行風險分析時，應遵循以下步驟：

• 識別計算機系統的所有元件。

• 識別每個元件面臨的所有威脅和危害。

• 量化風險，即評估威脅成為現即時的損失。

風險分析——主要步驟

由於風險或威脅在不斷變化，潛在損失也在不斷變化，因此高階管理人員應定期進行風險管理。

風險管理是一個持續的過程，它包括以下步驟：

• 識別安全措施。

• 計算實施安全措施的成本。

• 將安全措施的成本與威脅的損失和機率進行比較。

• 選擇和實施安全措施。

• 審查安全措施的實施情況。

面向物件方法

在面向物件的方法中，重點是將資訊系統的結構和行為捕獲到小型模組中，這些模組同時結合了資料和流程。面向物件設計 (OOD) 的主要目標是透過使其更易於使用來提高系統分析和設計的質量和生產力。

在分析階段，OO 模型用於彌合問題和解決方案之間的差距。它在系統不斷進行設計、適應和維護的情況下表現良好。它識別問題域中的物件，根據資料和行為對它們進行分類。

OO 模型具有以下好處：

• 它以低成本促進系統更改。

• 它促進元件的重用。

• 它簡化了整合元件以配置大型系統的問題。

• 它簡化了分散式系統的設計。

面向物件系統的元素

讓我們瞭解一下 OO 系統的特徵：

• 物件——物件是問題域中存在的東西，可以透過資料（屬性）或行為來識別。所有有形實體（學生、病人）和一些無形實體（銀行賬戶）都被建模為物件。

• 屬性——它們描述有關物件的資訊。

• 行為——它指定物件可以做什麼。它定義對物件執行的操作。

• 類——類封裝資料及其行為。具有相似含義和目的的物件組合在一起構成類。

• 方法——方法確定類的行為。它們只不過是物件可以執行的操作。

• 訊息——訊息是從一個物件到另一個物件的函式或過程呼叫。它們是傳送到物件以觸發方法的資訊。本質上，訊息是從一個物件到另一個物件的函式或過程呼叫。

面向物件系統的特性

面向物件系統具有以下幾個優點：

封裝

封裝是資訊隱藏的過程。它只是將過程和資料組合成一個單一實體。物件的データはシステムの他の部分からは隠され、クラスのサービスを通じてのみアクセスできます。これにより、オブジェクトによって使用されるメソッドの改善や修正が可能になり、システムの他の部分に影響を與えることなく行うことができます。

抽象化

這是一個選擇必要的メソッドと屬性を使用してオブジェクトを指定するプロセスです。ユーザーの視點からオブジェクトの本質的な特性に焦點を當てています。

關係

系統中的所有類都相互關聯。物件不是孤立存在的，它們與其他物件之間存在關係。

物件關係有三種類型：

• 聚合——它表示整體與其部分之間的關係。

• 關聯——在這種情況下，兩個類以某種方式相關或連線，例如一個類與另一個類一起執行任務，或者一個類作用於另一個類。

• 泛化——子類基於父類。這表示兩個類相似，但存在一些差異。

繼承

繼承是一個強大的特性，它允許透過繼承現有類的屬性和/或操作來從現有類建立子類。

多型性和動態繫結

多型性是採取多種不同形式的能力。它適用於物件和操作。多型物件是指其真實型別隱藏在超類或父類中的物件。

在多型操作中，不同類的物件可能以不同的方式執行操作。它允許我們僅通過了解物件的共同屬性來操作不同類的物件。

結構化方法與面向物件方法

下表說明了面向物件方法與傳統的結構化方法有何不同：

統一建模語言 (UML)

UML 是一種視覺化語言，允許您對流程、軟體和系統進行建模，以表達系統架構的設計。它是一種用於面向物件方式設計和記錄系統的標準語言，允許技術架構師與開發人員進行溝通。

它被定義為由物件管理組建立和分發的規範集。UML 是可擴充套件的和可伸縮的。

UML 的目標是提供一套通用的面向物件術語和圖表技術詞彙，它足夠豐富，可以對從分析到實現的任何系統開發專案進行建模。

UML 由以下部分組成：

• 圖——它是流程、系統或其一部分的圖形表示。

• 符號——它由在圖表中協同工作的元素組成，例如聯結器、符號、註釋等。

類的 UML 符號示例

例項圖-UML 符號

對物件執行的操作

對物件執行以下操作：

• 建構函式/解構函式——建立類的新的例項和刪除類的現有例項。例如，新增新員工。

• 查詢——訪問狀態而不更改值，沒有副作用。例如，查詢特定員工的地址。

• 更新——更改一個或多個屬性的值並影響物件的狀態。例如，更改員工的地址。

UML 的用途

UML 對以下目的非常有用：

• 模擬業務流程
• 描述系統架構
• 顯示應用程式結構
• 捕獲系統行為
• 模擬資料結構
• 構建系統的詳細規範
• 草繪想法
• 生成程式程式碼

靜態模型

靜態模型顯示系統的結構特徵，描述其系統結構，並強調構成系統的部分。

• 它們用於定義類名、屬性、方法、簽名和包。

• 表示靜態模型的 UML 圖表包括類圖、物件圖和用例圖。

動態模型

動態模型顯示系統的行為特徵，即系統如何響應外部事件。

• 動態模型識別所需的物件以及它們如何透過方法和訊息協同工作。

• 它們用於設計系統的邏輯和行為。

• UML 圖表表示動態模型包括序列圖、通訊圖、狀態圖、活動圖。

面向物件系統開發生命週期

它包括三個宏過程：

• 面向物件分析 (OOA)
• 面向物件設計 (OOD)
• 面向物件實現 (OOI)

面向物件系統開發活動

面向物件系統開發包括以下階段：

• 面向物件分析
• 面向物件設計
• 原型設計
• 實施
• 增量測試

面向物件分析

本階段關注確定系統需求，併為了理解系統需求而構建用例模型。用例是一個描述使用者和計算機系統之間互動的場景。該模型代表使用者的需求或使用者對系統的看法。

它還包括識別構成應用程式的問題域中的類及其與其他類之間的關係。

面向物件設計

本階段的目標是設計和細化在分析階段識別的類、屬性、方法和結構，以及使用者介面和資料訪問。本階段還識別和定義支援需求實現的附加類或物件。

原型設計

原型設計能夠幫助充分理解實現系統某些功能的難易程度。

它還可以讓使用者有機會評價設計的可用性和實用性。它可以進一步定義用例並使用例建模更容易。

實施

它使用基於元件的開發 (CBD) 或快速應用程式開發 (RAD)。

基於元件的開發 (CBD)

CBD 是一種工業化的軟體開發過程方法，它使用各種各樣的技術，例如 CASE 工具。應用程式開發從定製開發轉向組裝可互操作的預構建、預測試、可重用的軟體元件。CBD 開發人員可以組裝元件來構建完整的軟體系統。

快速應用程式開發 (RAD)

RAD 是一套工具和技術，可用於比傳統方法更快地構建應用程式。它並不取代 SDLC，而是對其進行補充，因為它更側重於過程描述，並且可以與面向物件方法完美結合。

其任務是快速構建應用程式並透過 Visual Basic、PowerBuilder 等工具增量實現使用者需求設計。

增量測試

軟體開發及其所有活動（包括測試）都是一個迭代過程。因此，如果我們只在產品完全開發後才進行測試，這將是一件代價高昂的事情。在這裡，增量測試就發揮了作用，產品在其開發的各個階段都會進行測試。