【系統規劃】

1、系統規劃步驟

（1）對現有系統進行初步調查

（2）分析和確定系統目標

（3）分析子系統組成和基本功能

（4）擬定系統實施方案

（5）進行可行性研究，編寫可行性研究報告，召開可行性論證會

（6）制定系統建設方案

2、可行性研究

經濟、技術、法律、用戶使用

3、成本效益分析（盈虧臨界分析）

4、凈現值（凈現值率）

5、投資回收期（靜態、動態）

6、投資回報率（回收率、收益率）

【軟件工程】

1、軟件工程的概念

計算機科學、數學、管理學

2、軟件的生命周期

可行性研究、需求分析、概要設計、詳細設計、實現、組裝測試、確認測試、使用、維護、報廢

3、軟件開發方法

形式化（數學理論為基礎）、非形式化；自頂向下、自底向上；

凈室軟件工程（形式化開發方法）

逆向工程：

完備性，抽象程度越高，離代碼越遠

設計模型（實現級）

程序和數據結構信息（結構級）

對象模型、數據和控制流模型（功能級）

UML狀態圖和部署圖（領域級）

抽象程度越來越高

4、軟件開發模型

瀑布模型、演化模型（原型）、螺旋模型、噴泉模型、統一過程、V模型、敏捷開發方法

瀑布模型：適應于需求明確，且需求不變的開發、缺點是不適用于需求易變的需求，問題往往到項目開發后期才會暴露，導致無法有效的解決，導致項目延期、成本超出預算等問題。

演化模型：制作原型，讓用戶參與，不斷改進形成新版本，使用于需求不明確、風險不可控，用戶過多參與。

螺旋模型：基于瀑布模型和演化模型，著力于風險控制，迭代，每次都迭代一個新版本，且每個版本遵循瀑布模型的步驟。

噴泉模型：以用戶需求為動力、以對象為驅動的模型，主要用于描述面向對象的軟件開發過程。自底向上

統一模型：通用開發模型；用例驅動，以架構為中心，迭代和增量；包括初始、細化、構建、移交四個步驟，每個過程都需要技術評審。

V模型：每個階段和測試對應，提供開發周期，編碼——單元測試、詳細設計——集成測試、概要設計——系統測試、需求分析——驗收測試

敏捷開發：適用于中小項目、小步快走、需求模糊且需求不明確

5、軟件開發環境

6、軟件開發工具

7、軟件過程的管理

【需求獲取方式】

1、用戶訪談

概念：包括結構化和非結構化兩種。結構化是指事先準備好一系列問題，有針對的進行。非結構化是只列出一個粗略的想法，根據訪談的具體情況發揮。準備訪談、主持訪談、訪談的后續工作。

優點：有較好的靈活性，有較寬廣的應用范圍。

缺點：用戶較忙，難以安排時間。面談時信息量巨大，記錄較為困難。溝通需要很多技巧，需要分析師具有足夠的領域知識。還可能會遇到對企業來說較機密和敏感的話題。

2、問卷調查

概念：由于用戶訪談最大的難處在于很多關鍵人員時間有限，不易安排過多的時間，而且用戶較多，不可能一一訪談。因此需要借助問卷調查。

優點：與用戶訪談相比，問卷調查可以在短時間內，以低廉的代價從大量的數據中收集數據；問卷調查允許用戶匿名填寫，大多數情況會提供真實信息；問卷調查結果比較好整理和統計。

缺點：缺乏靈活性。雙方未見面，無法捕獲表情獲取隱含信息，用戶也沒有機會立即澄清對問題有含糊或錯誤的回答；僅僅一張表格可能用戶不認真對待，導致信息不全面；不利于對問題展開回答，無法了解一些細節問題；回答的數量往往比預期要少。

最好的方法是將問卷調查和用戶訪談結合使用。先問卷調查再進行訪談。

提高返還率：

（1）向所有工作人員解釋問卷的目的

（2）說明這份問卷是客戶的每個人都要填寫的

（3）拜托相關領導進行督促

（4）更改問卷的問題，減少回答所需的時間

（5）參加一次客戶的全體會議，解答和解釋問題

（6）設置一些獎品或獎勵激勵返還

3、采樣

概念：采樣是指從種群中系統的選出具有代表性的樣本集的過程，通過認真研究所選出的樣本集，可以從整體上揭示種群的有用信息。對于信息系統而言，現有系統的文檔就是種群。

優點：采樣不僅可以用于收集數據，還可以用于采集訪談用戶或者是采集觀察用戶。通過采樣技術，選擇部分而不是選擇整體，不僅加快了數據收集過程，而且加快了效率，從而降低了開發成本。采樣技術采用了數理統計的原理，能減少數據收集的偏差。

缺點：對系統分析師的經驗和能力依賴很強，要求系統分析師具有較高的水平和豐富的經驗。

采樣樣本大小公式：

4、情節串聯板

概念：通常就是一系列圖片，系統分析師通過圖片來講故事，圖片的順序與活動事件的順序一致，通過一系列圖片說明會發生什么。

簡單的說，情節串聯板就是使用工具向用戶說明（或演示）系統如何適合企業的需要，并表明系統將如何運轉。

工具分為靜態工具和動態工具。

優點：用戶友好，交互性強，對用戶界面提供了早期的評審。

缺點：花費的時間很多，使需求獲取的速度大大降低。

5、聯合需求計劃（JRP）

概念：是一個通過高度組織的群體會議來分析企業內的問題并獲取需求的過程。相對來說成本較高的需求獲取方法，但也是十分有效的一種。它通過聯合各個關鍵用戶代表，系統分析師，開發團隊代表一起，通過有組織的會議來討論需求。

JRP的原則：

（1）制定詳細的議程，嚴格按照議程進行

（2）按照既定的時間安排進行

（3）盡量完整的記錄會議內容

（4）會議期間盡量避免使用專業術語

（5）充分運用解決沖突的技能

（6）設置充分的間歇期

（7）鼓勵團隊去得一致性意見

（8）保證所有與會人員都能遵守事先約定的規則

【需求分析】

需求分析就是提煉、分析和仔細審查已經獲取的需求，以確保所有的項目干系人都明白其含義并找出其中的錯誤、遺漏或其他不足的地方。需求分析的關鍵是在于對問題的研究與理解。

需求分析的方法：

1、SA方法

結構化分析方法，其基本思想是自頂向下，追層分解，把一個大問題分解成若干個小問題，每個小問題再分解成更小的問題。經過逐層分解，每個最底層問題都是足夠簡單的，容易解決的，于是復雜的問題就迎刃而解了。

SA方法分析模型的核心是數據字典，圍繞這個核心有三個層次的模型，分別是數據模型，功能模型和行為模型（也成為狀態模型）。

一般使用E-R圖表示數據模型，用DFD表示功能模型，用狀態轉換圖（State Transform

Diagram，STD）表示行為模式。

數據流圖DFD：

是表達系統內數據的流動并通過數據流描述系統功能的一種方法。還被認為是一個系統模型

主要作用：

從數據傳遞和加工的角度，利用圖形符號通過逐層細分描述系統內各個部件的功能和數據在它們之間傳遞的情況，來說明系統所完成的功能。

（1）DFD是理解和表達用戶需求的工具，是需求分析的手段。

（2）DFD概括的描述了系統的內部邏輯，是需求分析結果的表達工具，也是系統設計的重要參考資料，是系統設計的起點。

（3）DFD作為一個存檔的文字材料，是進一步修改和充實開發計劃的依據。

DFD的4種基本符號：分別是數據流、加工、數據存儲和外部實體（數據源及數據終點）。

數據流：具有名字和流向的數據，用標有名字的箭頭表示

加工：是對數據流的變換，用圓圈表示

數據存儲：是可訪問的存儲信息，用直線表示

外部實體：位于被建模的系統之外的信息生產者或消費者，用標有名字的方框表示

DFD分層

（1）頂層圖：描述系統最高層的DFD，它的特點是將整個待開發的系統表示為一個加工，將所有外部實體和進出系統的數據流都畫在一張圖上。用來表示系統有什么輸入和輸出數據流，與哪些外部實體直接相關，可以把整個系統的范圍勾畫出來。

（2）0層圖：頂層圖中，系統本身就是一個加工，編號為0，對加工0的分解就是0層圖。

DFD繪制是一個自頂向下、由外到里的過程。

STD狀態轉換圖

實時控制系統主要是事件驅動的，因此行為模型是最有效的描述方式。STD通過描述系統的狀態和引起系統狀態轉換的事件，來表示系統的行為。

狀態：是任何可以被觀察到的系統行為模式，每個狀態代表系統的一種行為模式，用圓形框或橢圓框表示

事件：是在某個特定時刻發生的事情，它是對引起系統從一個狀態轉換到另一個狀態的外界事件的抽象。簡而言之，事件就是引起系統狀態轉換的控制信息。

數據字典

數據字典是在DFD的基礎上，對DFD中所有出現的命名元素都加以定義，使得每個圖形元素的名字都有一個確切的解釋。

數據字典的6個條目：

數據元素、數據結構、數據流、數據存儲、加工邏輯和外部實體

數據字典的作用

（1）按各種要求列表，列出條目，保證系統設計時不會遺漏

（2）相互參照，便于系統修改

（3）由描述內容檢索名稱

（4）一致性檢驗和完整性檢驗

2、OOA方法

UML是一種定義良好、易于表達、功能強大且普遍適用的建模語言。

UML的結構包括：構造塊、規則和公共機制。

構造塊：UML有三種基本構造塊，分別是事物、關系和圖。事物是UML的重要組成部分，關系把事物緊密連在一起，圖是多個關聯的事物的集合。

公共機制：達到特定目標的公共UML方法。

規則：構造塊如何放在一起的規定，包括為構造塊命名。

范圍-->給一個名字以特定含義的語境；

可見性-->怎樣使用或看見名字；

完整性-->事物如何正確、一致的相互聯系；

執行-->運行或模擬動態模型的含義是什么；

UML的5個系統視圖：

（1）邏輯視圖：也稱為設計視圖，它表示了設計模型中在架構方面具有重要意義的部分，即類、子系統、包和用例實現的子集。

（2）進程視圖：是可執行線程和進程作為活動類的建模，它是邏輯視圖的一次執行實例，描述了并發與同步結構。

（3）實現視圖：對組成基于系統的物理代碼的文件和構件進行建模

（4）部署視圖：把構件部署到一組物理節點上，表示軟件到硬件的映射和分布結構

（5）用例視圖：是最基本的需求分析模型

事物

UML中的事物也稱為建模元素，包括結構事物、行為事物、分組事物、注釋事物；這些事物是UML模型中最基本的OO構造塊。

（1）結構事物：最靜態的部分，代表概念上或物理上的元素。UML有7種結構事物：類、接口、協作、用例、活動類、構件和節點。

（2）行為事物：動態部分，代表時間和空間上的動作。分交互和狀態機兩種。

（3）分組事物：是UML模型中組織的部分，可以看成是盒子，模型可以在其中進行分解。UML中只有一種分組事物稱為包。

（4）注釋事物：UML模型的注釋部分

關系

UML用關系把事物結合在一起，有如下四種：

（1）依賴：其中一個事物發生變化會影響另一個事物

（2）關聯：描述一組對象之間連接的結構關系

（3）泛化：是指一般化和特殊化的關系，描述特殊元素的對象可以替換一般元素的對象。

（4）實現：是類之間的語義關系，其中一個類指定了由另一個類保證執行的契約

圖

UML2.0包括14種圖

（1）類圖：描述一組類、接口、協作和它們之間的關系。類圖給出了系統的靜態設計視圖，活動類的類圖給出了系統的靜態進程視圖。

（2）對相圖：描述一組對象及他們之間的關系。靜態

（3）構件圖：描述一個封裝的類和它的接口、端口，以及由內嵌的構件和連接構成的內部結構。靜態

（4）組合結構圖：描述結構化類的內部結構，包括結構化類與系統其余部分的交互點。

（5）用例圖：描述一組用例、參與者及它們之間的關系。 靜態

（6）順序圖：由一組對象或參與者以及它們之間可能發送的消息構成。強調消息的時間次序的交互圖。 動態

（7）通信圖：強調收發消息的對象或參與者的結構組織。也稱為協作圖。動態

（8）定時圖：強調消息跨越不同對象或參與者的實際時間，而不僅僅是關心消息的相對順序。動態

（9）狀態圖：由狀態、轉移、事件和活動組成。強調事件導致的對象行為。 動態

（10）活動圖：將進程或其他計算結構展示為計算內部一步步的控制流和數據流。強調對象間的控制流程。動態

（11）部署圖：描述對運行時的處理節點及在其中生存的構件的配置。 靜態

（12）制品圖：描述計算機中一個系統的物理結構。通常與部署圖一起使用

（13）包圖：描述由模型本身分解而成的組織單元，以及他們之間的依賴關系。

（14）交互概覽圖：是活動圖和順序圖的混合物。

在OOA方法中，構建用例模型一般需要經歷4個階段，分別是識別參與者、合并需求獲得用例、細化用例描述和調整用例模型。其中前三個階段是必需的。

用例圖主要包括參與者、用例和通信關聯。

用例之間的關系

（1）包含關系：當可以從兩個或兩個以上的用例中提取公共行為時，應使用包含關系。

（2）擴展關系：如果一個用例明顯地混合了兩種或兩種以上的不同場景，即根據情況可能發生多種分支。

（3）泛化關系：當多個用例共同擁有一種類似的結構和行為時，可以將他們的共性抽象成父用例，其他用例作為泛化關系中的子用例。子用例是父用例的一種特殊形式。

包含關系和擴展關系都屬于依賴關系。

類之間的關系

（1）關聯關系：關聯提供了不同類之間的結構關系，將多個類的實例連接在一起。針對實例而不是類。

（2）依賴關系：一個類的變化會引起另一個類的變化。A的變化引起B變化，B依賴于A

（3）泛化關系：父類與子類之間的關系。繼承關系是泛化關系的反關系，子類繼承父類，父類是子類的泛化。

（4）聚集關系：表示類之間的整體和部分的關系，部分可以屬于多個整體，部分和整體的生命周期不同，汽車和輪子。

（5）組合關系：也表示類之間整體和部分的關系，部分只屬于一個整體，生命周期相同，公司和部門的關系。

（6）實現關系：將說明和實現聯系在起來。

3、PDOA方法

面向問題域的分析，更多的強調描述，而少強調建模。問題框架是PDOA的核心元素。

三種方法對比

（1）SA關注于功能的分層和分解，自上而下，逐步分解求精

（2）OOA方法遵循完全不同的思維方式，基于抽象、信息隱藏、功能獨立和模塊化這些基本理念對系統進行分析。

（3）PDOA的特點是重新將重點定位在問題域和需求上，通過對問題域的分類，向系統分析師提供具體問題的相關指南。PDOA豐富和完善了SA和OOA方法。

總結

以上是生活随笔為你收集整理的2023系统分析师综合知识必备知识点的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。