一、嵌入式系統架構

軟件脆弱性是軟件中存在的弱點(或缺陷)，利用它可以危害系統安全策略，導致信息丟失、系統價值和可用性降低。嵌入式系統軟件架構通常采用分層架構，它可以將問題分解為一系列相對獨立的子問題，局部化在每一層中，從而有效地降低單個問題的規模和復雜性，實現復雜系統的分解。但是，分層架構仍然存在脆弱性。常見的分層架構的脆弱性包括( )等兩個方面。

A：底層發生錯誤會導致整個系統無法正常運行、層與層之間功能引用可能導致功能失效

B：底層發生錯誤會導致整個系統無法正常運行、層與層之間引入通信機制勢必造成性能下降

C：上層發生錯誤會導致整個系統無法正常運行、層與層之間引入通信機制勢必造成性能下降

D：上層發生錯誤會導致整個系統無法正常運行、層與層之間功能引用可能導致功能失效

答案：B

解析：

脆弱性表示人、事物、組織機構等面對波動性、隨機性變化或者壓力時表現出來的變化趨勢，軟件脆弱性是指軟件中存在的弱點(或缺陷)，利用它可以危害系統安全策略，導致信息丟失、系統價值和可用性降低等。

通常在軟件設計時，分層架構由于其良好的可擴展性和可維護性被廣泛采納，但是，分層架構也存在眾多脆弱性問題，主要表現在以下兩個方面：

① 一旦某個底層發生錯誤，那么整個程序將會無法正常運行，如產生一些數據溢出、空指針、空對象的安全問題，也有可能會得出錯誤的結果;

②將系統隔離為多個相對獨立的層，這就要求在層與層之間引入通信機制，這種本來“直來直去’的操作現在要層層傳遞，勢必造成性能的下降。

一、嵌入式系統架構的兩種模式

1.層次化模式架構：位于高層的抽象概念與低層的更加具體的概念之間存在著依賴關系

高層抽象、底層具體，分為

封閉型：只能調用本層和下層

開放型：可以調用本層和下邊所有層

2.遞歸模式架構：需要將一個非常復雜的系統進行分解，并且還要確保分解過程是可擴展的，即只要有必要，該分解過程就可以持續下去

對復雜系統分解

（1）自頂向下：抽象到具體

（2）自底向上：構造域，達到子系統

?

二、嵌入式操作系統（EOS）

從嵌入式操作系統體系架構看，主要存在4種結構:整體結構、層次結構、客戶/服務器結構和面向對象結構。

整體結構也稱為模塊結構或無序結構，它是基于結構化程序設計的一種軟件設計方法

內核是操作系統的核心部分，它管理著系統的各種資源。內核可以看成連接應用程序和硬件的一座橋梁，是直接運行在硬件上的最基礎的軟件實體。目前從內核架構來劃分，可分為宏內核(即單體內核)和微內核。

任務管理是嵌入式操作系統最基本功能之一

1.整體結構

2.強實時調度算法（EDF）

（1）最早截止時間優先：截至時間越早越優先

（2）最低松弛度優先（LLF）：富裕時間越少越優先

（3）單調速率調度算法（RMS）：靜態的任務周期越短越優先

3.嵌入式通信方式

（1）共享內存

（2）信號量

（3）消息隊列

（4）socket遠程調用

（5）signals信號：異步事件

嵌入式實時操作系統與一般操作系統相比，具有許多特點。以下不屬于嵌入式實時操作系統特點的是（ )。

A：可裁剪性

B：實時性

C：通用性

D：可固化性

答案：C

解析：

RTOS專注于實時性需求的設計，具有專業化，因此沒有通用性。

? **問題：**實時操作系統主要用于有實時要求的過程控制等領域。因此，在實時操作系統中，對于來自外部的事件必須在( )。

A:一個時間片內進行處理

B:一個周轉時間內進行處理

C:一個機器周期內進行處理

D:被控對象允許的時間范圍內進行處理

答案：D

解析：

實時是指計算機對于外來信息能夠以足夠快的速度進行處理,并在被控對象允許的時間范圍內做出快速響應。

因此，實時操作系統與分時操作系統的第一點區別是交互性強弱不同，分時系統交互性強，實時系統交互性弱，但可靠性要求高；第二點區別是對響應時間的敏感性強，對隨機發生的外部事件必須在被控制對象規定的時間內做出及時響應并對其進行處理；第三點區別是系統的設計目標不同，分時系統是設計成一個多用戶的通用系統，交互能力強，而實時系統大都是專用系

三、嵌入式數據庫

與傳統數據庫相比，嵌入式數據庫系統有以下幾個主要特點: 嵌入式、實時性、移動性、伸縮性。

嵌入式數據庫按存儲位置的不同可分為三類: 基于內存方式、基于文件方式、基于網絡方式。

1.基于內存的數據庫系統（MMSB）：典型產品eXtremeDB

2. 基于文件的數據庫（FDB）：產品SQLite

3.基于網絡的數據庫（NDB）：由客戶端、通信協議、遠程服務器組成

沒網時在本地嵌入式數據庫存儲、有網同步到云嵌入式數據庫，不需要改數據庫驅動程序，將數據庫文件連接到應用程序，通過API訪問數據庫

特點：

（1）只允許應用程序對其訪問

（2）數據與程序不分離，交給應用程序

（3）不需要獨立安裝，與應用一起發布

（4）需要持久化能力

基于網絡的數據庫系統(Netware Database System，NDB)是基于4G/5G 的移動通信之上，在邏輯上可以把嵌入式設備看作遠程服務器的一個客戶端。以下有關NDB的敘述中，不正確的是( )。

A：NDB主要由客戶端、通信協議和遠程服務器等三部分組成

B：NDB的客戶端主要負責提供接口給嵌入式程序，通信協議負責規范客戶端與遠程服務器之間的通信，遠程服務器負責維護服務器上的數據庫數據

C：NDB具有客戶端小、無需支持可剪裁性、代碼可重用等特點

D：NDB是以文件方式存儲數據庫數據。即數據按照一定格式儲存在磁盤中，使用時由應用程序通過相應的驅動程序甚至直接對數據文件進行讀寫

答案：C

解析：

與嵌入式設備有關，就應該具有可剪裁性。

?

數據庫服務器架構: 數據庫客戶端通常通過數據庫驅動程序如JDBC、ODBC等訪問數據庫服務器，數據庫服務器再操作數據庫文件。數據庫服務是一種客戶端服務器模式，客戶端和服務器是完全兩個獨立的進程。它們可以分別位于在不同的計算機甚至網絡中。客戶端和服務器通過TCP/IP進行通信。這種模式將數據與應用程序分離，便于對數據訪問的控制和管理。

3.3.1 嵌入式數據庫架構: 嵌入式數據庫不需要數據庫驅動程序，直接將數據庫的庫文件鏈接到應用程序中。應用程序通過API訪問數據庫，而不是TCP/IP。因此，嵌入式數據庫的部署是與應用程序在一起的。

3.3.2 數據庫服務器和嵌入式數據庫對比如下:

3.3.3 數據庫服務器通常允許非開發人員對數據庫進行操作，而在嵌入式數據中通常只允許應用程序對其進行訪問和控制。

3.3.4 數據庫服務器將數據與程序分離，便于對數據庫訪問的控制。而嵌入式數據庫則將數據的訪問控制完全交給應用程序，由應用程序來進行控制。.

3.3.5 數據庫服務器需要獨立的安裝、部署和管理，而嵌入式數據通常和應用程序一起發布，不需要單獨地部署一個數據庫服務器，具有程序攜帶性的特點。

四、嵌入式中間件

應用與操作系統之間的軟件

分類

ESB、事務、分布式計算、RPC、對象請求、數據庫訪問、消息傳遞、基于XML

?

五、嵌入式系統的設計

1.基于架構的軟件設計（ABSD）

自頂向下，遞歸迭代

2.屬性驅動的軟件設計（ADD）

屬性驅動的軟件設計(ADD)是把一組質量屬性場景作為輸入，利用對質量屬性實現與架構設計之間的關系的了解(如體系結構風格、質量戰術等)對軟件架構進行設計的一種方法。

質量屬性為輸入

? 采用ADD方法進行軟件開發時，需要經歷評審、選擇驅動因子、選擇系統元素、選擇設計概念、實體化元素和定義接口、草擬視圖和分析評價等七個階段。

六、實時系統設計方法（DARTS）

將實時系統分解為多個并發任務

提供了分解與處理并發的設計

使用任務架構圖（TAD）來顯示分解并發任務的過程

組成部分

1.實時結構化分析方法（RTSA）

開發系統環境圖（SCD）和狀態轉換圖（STD）

2.將系統劃分為多個并發任務

初步任務架構圖（TAD）

3.定義任務間接口

4.設計每個任務

5.設計過程的成果：RTSA規范、各種文檔

主要優勢

分解，詳細定義任務間的接口

用任務架構圖（TAD）、用RTSA實現到實時的轉換

不足：RTSA沒有做好，創建任務非常困難

?

七、案例分析之鴻蒙操作系統

4個技術特征

1.分布式架構，實現跨終端無縫協同

2.確定時延引擎和高性能IPC技術，天生流暢

3.基于微內核，終端可信、安全

4.通過統一IDE支撐一次開發，多端部署

分布式架構帶來的優勢

1.分布式總線：設備之間互聯互通、

2.分布式設備虛擬化平臺：不同設備資源融合，不同手機，電腦，自動匹配設備來執行

3.分布式數據管理：應用數據與用戶數據分布式管理。跨設備數據無縫銜接

4.分布式任務調度：分布式服務管理

HOS安全性

分布式多端協同身份認證（正確的人）

分布式終端構筑可信運行環境（正確的設備）

**分布式數據跨終端過程中進行分類分級管理（正確的使用數據）
**

八、案例分析之安全攸關系統的跨領域GENESYS系統架構案例分析

GENESYS是一種跨領域的通用嵌入式架構平臺

解決三個挑戰

1.復雜性：采用消息交換方式提高抽象級別

2.系統健壯性：設計故障隔離框架

3.能量有效使用：采用綜合化資源管理方法

提供了三組服務：領域無關、領域專用、應用專用服務

思想：分離計算與通信、消息傳輸、多播單向消息

GENESYS四類消息構件接口

1.鏈路接口（LIF）：構件與構件之間

2.局部接口（LI）：構件與外部環境

3.技術無關架構（TII）：配置和管理資源

4.技術相關接口（TDI）：查看構件內部和變量

三級集成

芯片級（構件是核）、設備級（構件是芯片）、系統級（構件是設備）

二、大數據架構

大數據架構是指為了處理大規模數據而設計的系統架構。它能高效地存取、處理和分析海量數據，挖掘數據中有價值的信息，為相關決策提供支持。

大數據架構的典型架構有 Lamba 架構、Kappa 架構等。

1、傳統數據處理的問題

1. 數據孤島問題：不同部門或系統之間的數據隔離，數據無法共享和整合。

2. 數據不一致性問題：由于數據維護分散，同一數據在不同系統或部門中可能存在不同的版本，造成數據不一致。

3. 數據冗余問題：同一數據在不同系統或部門中存在多份副本，造成資源浪費和數據安全隱患。

4. 數據安全問題：數據安全保護措施相對較弱，容易受到惡意攻擊或數據泄露。

5. 數據處理效率低下問題：數據處理方式和技術相對落后，處理效率低下，無法滿足大數據時代的需求。

6. 數據分析能力不足問題：僅提供簡單的數據處理和查詢功能，無法進行高級的數據分析和挖掘，無法支持數據驅動的業務決策。

2、大數據架構的幾個方面

大數據處理系統架構主要包括以下幾個方面：

1. 數據采集層：大數據處理系統可以通過數據傳感器、日志、文件等多種方式采集數據。數據采集層需要考慮數據的格式、容量、采集周期等因素。

2. 數據存儲層：大數據處理系統可以使用多種存儲方式，如HDFS、NoSQL數據庫、關系型數據庫等。數據存儲層需要考慮數據的安全性、可擴展性、高可用性等因素。

3. 數據處理層：數據處理是大數據系統中最復雜的一部分。大數據處理系統可以使用多種處理方式，如MapReduce、Spark、Flink等。數據處理層需要考慮數據處理的速度、可擴展性、容錯性、計算能力等因素。

4. 數據查詢層：大數據處理系統可以使用多種查詢方式，如Hive、Presto、Drill等。數據查詢層需要考慮查詢的效率、可擴展性、數據精確性等因素。

5. 數據可視化與分析層：大數據處理系統可以使用多種數據可視化工具，如Tableau、Power BI等。數據可視化與分析層需要考慮用戶體驗、數據分析的精準性等因素。

3、大數據面臨的挑戰

1. 多源數據處理：如何利用信息技術等手段處理非結構化和半結構化數據
2. 數據特征描述、刻畫方法及系統建模方法：如何探索大數據復雜性、不確定性特征描述的刻畫方法及大數據的系統建模
3. 數據挖掘與決策支持：數據異構性與決策異構性的關系對大數據知識發現與管理決策的影響

4、Lambda 架構

• 設計 Batch Layer 和 Speed Layer 的依據
  • 容錯性。
  • 復雜性隔離。 Batch Layer 處理離線數據。 Speed Layer 采用增量算法處理實時數據，復雜性比 Batch Layer 要高很多。
  • 橫向擴容。當數據量/負載增大時，可擴展性的系統通過增加更多的機器資源來維持性能。
• 批處理層(Batch Layer)：接收原始數據流，處理離線數據。兩個核心功能：存儲數據集和生成Batch View。處理的數據是全量數據，進行復雜計算，具有高可靠性和長時間窗口（高延時）。
• 加速層(Speed Layer)：存儲實時視圖并處理傳入的實時數據流，更新到 Real-time View。處理的數據是部分數據（最近的增量數據流），進行簡單計算，具有低延時。
• 服務層(Serving Layer)：用于響應用戶的查詢請求，合并 Batch View 和 Real-time View 中的結果數據集到最終的數據集。

Lambda 架構的實現

1. Hadoop(HDFS)作為主數據存儲層，負責存儲大規模數據集。
2. Spark或Storm構成速度層，提供快速的數據處理能力。

• 特別適合需要迭代計算的數據挖掘和機器學習任務。

1. Hbase或 Cassandra 作為服務層，提供實時的數據訪問和更新。
2. Hive 用于創建可查詢的視圖，使得數據可以被方便地查詢和分析。

Lambda優缺點：

優點：容錯性好、查詢靈活度好、易伸縮、易擴展

缺點：全場景覆蓋帶來的編碼開銷、針對具體場景重新離線訓練一遍益處不大、重新部署和遷移成本很高

Lambda與其他架構模式對比

Lambda架構的誕生離不開很多現有設計思想和架構的鋪墊，如事件溯源 (Event Sourcing) 架構和命令查詢分離 (Command Query Responsibility Segregation,CQRS) 架構， Lambda架構的設計思想和這兩者有一定程度的相似。

下面對Lambda架構和這兩者進行分析。

**1.事件溯源 (Event Sourcing)**與 Lambda架構

Event Sourcing本質上是一種數據持久化的方式，其由三個核心觀點構成：

(1)整個系統以事件為驅動，所有業務都由事件驅動來完成。

(2)事件是核心，系統的數據以事件為基礎，事件要保存在某種存儲上。

(3)業務數據只是一些由事件產生的視圖，不一定要保存到數據庫中。

Lambda架構中數據集的存儲使用的概念與Event Sourcing 中的思想完全一致，二者都是在**使用統一的數據模型對數據處理事件本身進行定義。**這樣在發生錯誤的時候，能夠通過模型找到錯誤發生的原因，對這一事件進行重新計算以丟棄錯誤信息，恢復到系統應該的正確狀態，以此實現了系統的容錯性。

2.CQRS 與 Lambda 架構

CQRS架構分離了對于數據進行的讀操作(查詢)和寫(修改)操作。其將能夠改變數據模型狀態的命令和對于模型狀態的查詢操作實現了分離。這是領域驅動設計 (Domain-Driven Design,DDD) 的一個架構模式，主要用來解決數據庫報表的輸出處理方式。

Lambda架構中，數據的修改通過批處理和流處理實現，通過寫操作將數據轉換成查詢時所對應的View。在 Lambda架構中，對數據進行查詢時，實際上是通過讀取 View 直接得到結果，讀出所需的內容。這實際上是一種形式的讀寫分離。進行讀寫分離設計的原因是，讀操作實際上比寫操作要省時得多，如果將讀和寫操作放在一起，實際處理大量數據時會因為寫操作的時長問題影響整體業務的處理效率。在大數據系統 中經常處理海量數據，進行讀寫分離重要性不言而喻。

5、Kappa 架構

• Kappa架構在Lambda基礎上進行優化，刪除了batch layer的架構，將數據通道以消息隊列進行替代。因此對于 Kappa 架構來說，依舊以流處理為主

• 數據在數據湖層面進行了存儲，當需要進行離線分析或者再次計算的時候，則將數據湖的數據再次經過消息隊列重播一次則可。

Kappa 架構：

• 輸入數據直接由實時層的實時數據處理引擎對源源不斷的源數據進行處理;
• 再由服務層的服務后端進一步處理以提供上層的業務查詢。
• 而中間結果的數據都是需要存儲的，這些數據包括歷史數據與結果數據，統一存儲在存儲介質中。

Kappa 優缺點：

優點：
?將實時和離線代碼統一起來了；方便維護而且統一了數據口徑；避免了Lambda架構中與離線數據合并的問題。

缺點：
?(1)消息中間件緩存的數據量和回溯數據有性能瓶頸。
?(2)在實時數據處理時，遇到大量不同的實時流進行關聯時，非常依賴實時計算系統的能力，很可能因為數據流先后順序問題，導致數據丟失。
?(3)Kappa在拋棄了離線數據處理模塊的時候，同時拋棄了離線計算更加穩定可靠的特點。

6、Lambda架構 VS Kappa架構

對比內容	Lambda架構	Kappa架構
復雜度	需要維護兩套系統(引擎)，復雜度高	只需要維護一套系統(引擎)，復雜度低
開發、維護成本	開發、維護成本高	開發、維護成本低
計算開銷	需要一直運行批處理和實時計算，計算開銷大	必要時進行全量計算，計算開銷相對較小
實時性	滿足實時性	滿足實時性
歷史數據處理能力	批式全量處理，吞吐量大，歷史數據處理能力強	流式全量處理，吞吐量相對較低，歷史數據處理相對較弱
使用場景	直接支持批處理，更適合對歷史數據分析查詢的場景，期望盡快得到分析結果，批處理可以更直接高效地滿足這些需求。	不是Lambda的替代架構，而是簡化， Kappa放棄了對批處理的支持，更擅長業務本身為增量數據寫入場景的分析需求。

7、案例

采用 Lambda 架構，包括數據采集、集成、存儲、計算、應用層；

實時數據由Kalfka隊列分發給Spark Streaming 進行實時增量計算。

離線數據持續追加存儲在HDFS，由 Spark/MR 進行批量計算

實時/離線計算結果分別更新到Real-time view 和 Batch view

合并計算層將兩個 view 合并為最終結果，由 MemSQL/HBase 存儲

該平臺采用 Kappa 架構，使用 Flink 進行實時數據處理，Elasticsearch 和 OpenTSDB 分別存儲日志數據和時序指標數據。前端提供了豐富的搜索、分析和監控功能。

三、信息系統架構設計（ISA）

信息系統架構(ISA) 是指對某一特定內容里的信息進行統籌、規劃、設計、安排等一系列有機處理的活動。為了更好地理解信息系統架構的定義，特作如下說明：

1.1 架構是對系統的抽象，它通過描述元素、元素的外部可見屬性及元素之間的關系來反映這種抽象。因此，僅與內部具體實現有關的細節是不屬于架構的，即定義強調元素的“外部可見”屬性。

1.2 架構由多個結構組成，結構是從功能角度來描述元素之間的關系的，具體的結構傳達了架構某方面的信息，但是個別結構一般不能代表大型信息系統架構。

1.3 任何軟件都存在架構，但不一定有對該架構的具體表述文檔。即架構可以獨立于架構的描述而存在。如文檔己過時，則該文檔不能反映架構。

1.4 元素及其行為的集合構成架構的內容。體現系統由哪些元素組成，這些元素各有哪些功能(外部可見)，以及這些元素間如何連接與互動。即在兩個方面進行抽象:在靜態方面，關注系統的大粒度(宏觀)總體結構(如分層) ;在動態方面，關注系統內關鍵行為的共同特征。

1.5 架構具有“基礎”性: 它通常涉及解決各類關鍵重復問題的通用方案(復用性)，以及系統設計中影響深遠(架構敏感)的各項重要決策(一旦貫徹，更改的代價昂貴)

1.什么是信息系統架構風格？

信息系統架構風格是特定應用領域中系統組織方式的慣用模式。定義了一個系統家族，包括一個詞匯表和一組約束。詞匯表包含構件和連接件類型，約束則說明這些構件和連接件如何組合。架構風格反映領域內系統的共有結構和語義特性，并指導模塊和子系統的有效組織，形成一個完整的系統。

2.信息系統架構風格通常遵循的架構風格有哪些？

(1)數據流風格：批處理序列；管道/過濾器。

(2)調用/返回風格：主程序/子程序；面向對象風格；層次結構。

(3)獨立構件風格：進程通信；事件系統。

(4)虛擬機風格：解釋器；基于規則的系統。

(5)倉庫風格：數據庫系統；超文本系統；黑板系統。

3.什么是TOGAF框架？包括哪6個組件？其框架核心思想是什么？

TOGAF是一種開放式企業架構框架標準，它為標準、方法論和企業架構專業人員之間的溝通提供一致性保障。

TOGAF框架核心思想: 模塊化架構、內容框架、擴展指南、架構風格。

TOGAF是信息管理技術架構，采用迭代的過程模型，支持最佳實踐和可重用的架構資產。

TOGAF的六個組件：

架構開發方法（ADM）：TOGAF的核心，描述了企業架構的分步開發方法。

ADM指南和技術：包含應用ADM的指南和技術。

架構內容框架：描述架構工件的結構化元模型及可重用架構構建塊（ABB）的使用。

企業連續體和工具：討論對企業內部架構活動輸出進行分類和存儲的工具。

TOGAF參考模型：提供兩個架構參考模型，即技術參考模型（TRM）和集成信息基礎設施參考模型（Ⅲ-RM）。

架構能力框架：討論建立和運營架構實踐所需的組織、流程、技能、角色和職責。

框架核心思想：

模塊化架構：采用模塊化結構，便于靈活應用。

內容框架：提供詳細模型，使架構產品一致性更強。

擴展指南：支持大型組織內部團隊開發多層級集成架構。

架構風格：注重靈活性，適用于不同的架構風格。

4.ADM全生命周期劃分為哪些階段？

TOGAF中提出了一個著名的ADM架構開發的全生命周期模型，此模型將ADM全生命周期劃分為十個階段，分別為準備、需求管理、架構愿景、業務架構、信息系統架構、 技術架構、機會和解決方案、遷移規劃、實施治理、架構變更管理等十個階段。

5.企業應用集成有哪幾個集成方式？

**界面集成：**把各應用的界面集成起來，形成統一入口，有整體的感覺。

**數據集成：**應用集成和過程集成的基礎，可以提供企業信息共享能力。集成前，對數據進行統一標識和分類，并進行建模，實現企業數據共享和數據分布。

**控制集成（應用集成）：**多個應用系統進行綁定，像一個系統一樣輸入和產生輸出數據，實現多個系統功能的疊加。

**過程集成（業務流程集成）：**為實現整體的業務目標，定義、關聯管理不同的業務過程，實現信息交換、降低成本，包括過程管理、工程建模和工作流。

應用之間一對一接口集成的優缺點:

優點：開發速度快，開發比較容易實現

缺點：工作量大，維護費用高，系統升級與擴展困難，沒有標準化導致管理困難、只能解決應用系統之間的數據集成問題，難以支持過程集成和應用程序之間的協調。

在對遺留系統進行評估時，對于技術含量較高、業務價值較低且僅能完成某個部門的業務管理的遺留系統，一般采用的遺留系統演化策略是（ ）策略。

A：淘汰 B：繼承

C：集成 D：改造

答案：C

解析：

牢記四象限公式就行。

6.用戶界面設計的3條黃金原則是什么？

（1）置于用戶的控制之下

（2）減少用戶的記憶負擔

（3）保持界面的一致性

7.信息系統的生命周期分為4個階段，是哪些階段？其中最重要和關鍵的階段是哪個階段？該階段又可以分為5個階段，是哪5個階段？每個階段產出物是什么？

信息系統的生命周期分為4個階段，即產生階段、開發階段、運行階段和消亡階段。

其中信息系統的開發階段是信息系統生命周期中最重要和關鍵的階段。

信息系統的開發階段分為以下五個關鍵階段：

**總體規劃階段：**明確系統的開發目標和總體架構，規劃企業的業務流程，制定信息系統的組織結構、實施計劃及技術規范。

產出物：信息系統的開發目標、總體架構、組織結構和管理流程、實施計劃、技術規范等。

**系統分析階段：**基于企業業務流程，進行組織結構、業務流程和數據流程分析，提出系統的邏輯模型及初步方案。

產出物：系統的邏輯模型、組織結構及功能分析報告、業務流程分析報告、數據和數據流程分析報告、系統初步方案等。

**系統設計階段：**根據系統分析結果，進行系統架構、數據庫、處理流程、功能模塊及安全控制的詳細設計，形成系統實施方案。

產出物：系統架構設計文檔、數據庫設計方案、處理流程設計方案、功能模塊設計方案、安全控制方案、系統管理流程設計方案等。

**系統實施階段：**將設計方案轉換為可運行的軟件系統，進行系統部署、配置和測試，確保系統可以正常運行。

產出物：可運行的系統軟件、系統安裝與配置文件、系統測試報告、用戶手冊、培訓資料等。

**系統驗收階段：**在試運行中驗證系統性能及用戶體驗，進行最終的系統驗收，并根據反饋進行調整與優化。

產出物：系統試運行報告、系統驗收報告、最終用戶反饋與改進方案等。

6.信息系統建設原則是什么？

（1）高層管理人員介入原則

（2）用戶參與開發原則

（3）自頂向下規劃原則

（4）工程化原則

（5）其他原則：

例如：創新性原則，用來體現信息系統的先進性；

整體性原則，用來體現信息系統的完整性；

發展性原則，用來體現信息 系統的超前性；

經濟性原則，用來體現信息系統的實用性。

7.信息系統開發方法有哪些？

**瀑布模型：**線性順序開發，階段包括需求分析、系統設計、編碼、測試和維護。適用于需求明確且變化較少的項目。

**敏捷開發：**強調靈活性與快速迭代，采用短周期（如迭代或沖刺）進行開發與反饋。常用框架有Scrum和Kanban。

**迭代模型：**分階段開發，每個階段都涉及需求分析、設計、編碼和測試。通過反饋不斷完善系統，適合需求不確定的項目。

**增量模型：**將系統分為多個可獨立開發的增量部分，逐步交付并整合，每個增量可以提供實際功能。

**螺旋模型：**將開發過程視為多個迭代的螺旋，強調風險管理和用戶反饋。適合復雜且風險較高的項目。

**原型開發：**通過構建原型與用戶進行溝通，以便更好地理解需求和功能，常用于需求不明確的情況。

**V模型：**將測試過程與開發過程并行，強調驗證和確認，適用于對質量有嚴格要求的項目。

**RAD（快速應用開發）：**采用快速迭代與原型開發，減少開發周期，快速交付原型以便用戶反饋。

**DevOps：**強調開發（Dev）與運維（Ops）的協作，通過持續集成與持續交付提高軟件交付速度與質量。

8.信息系統常用架構模型有哪些？

常用4種架構模型：

（1）單機應用系統

（2）兩層/多層C/S

（3）MVC結構

（4）面向服務的 SOA 與多服務集合和數據交換總線等。

9. 信息化架構一般有兩種模式。

一種是數據導向架構，一種是流程導向架構。對于數據導向架構重點是在數據中心，BI商業智能等建設中使用較多，關注數據模型和數據質量;對于流程導向架構，SOA 本身就是關鍵方法和技術，關注端到端流程整合，以及架構對流程變化的適應度。兩種架構并沒有嚴格的邊界，而是相互配合和補充。

1 數據導向架構研究的是數據對象和數據對象之間的關系，這個是首要的內容。在這個完成后仍然要開始考慮數據的產生、變更、廢棄等數據生命周期，這些自然涉及的數據管理的相關流程。

2 流程導向架構關注的是流程，架構本身的目的是為了端到端流程整合服務。因此研究切入點會是價值鏈分析，流程分析和分解，業務組件劃分。

10.價值驅動的體系結構

價值模型核心的特征可以簡化為三種基本形式:

1 價值期望值: 表示對某一特定功能的需求，包括內容(功能)、滿意度(質量)和不同級別質量的實用性。

2 反作用力: 系統部署實際環境中，實現某種價值期望值的難度，通常期望越高難度越大，即反作用力。

3 變革催化劑: 表示環境中導致價值期望值發生變化的某種事件，或者是導致不同結果的限制因素。

反作用力和變革催化劑稱為限制因素，把這三個統稱為價值驅動因素。