第一篇：系統分析與設計 期末考試

10.在一個課程注冊系統中，定義了類CourseSchedule和類Course，并在類CourseSchedule中定義了方法add(c: Course)和方法remove(c: Course)，則類CourseSchedule和類Course之間的關系是：（）A.泛化（generalization）關系 B.組合（composition）關系 C.依賴（dependency）關系 D.包含（include）關系 13.進行企業系統規劃，哪種規劃方法使目標識別比較全面

A、企業系統規劃法 B、關鍵成功因素法

C、戰略目標集轉化法 D、成本效益分析法 14.系統開發的生命周期中不包括下列哪個階段（）A.系統規劃 B.系統分析 C.系統設計 D.系統實施

19.面向對象程序設計將描述事物的數據與()封裝在一起,作為一個相互依存、不可分割的整體來處理。A.信息 B.數據隱藏 C.對數據的操作 D.數據抽象 22.屬于系統設計階段的工具是（）：

A.數據流程圖 B.處理流程圖 C.系統流程圖 D.HIPO圖

23.進行企業系統規劃，哪種規劃方法可以形成一套完整的信息系統結構方案（）A.企業系統規劃法 B.關鍵成功因素法 C.戰略目標集轉化法 D.成本效益分析法

30.導出模塊結構圖的基礎是（）

A.業務流程圖 B.數據流程圖 C.處理流程圖 D.層次結構圖

32.（）是從用戶使用系統的角度描述系統功能的圖形表達方法。

A.類圖 B.對象圖 C.序列圖 D.用例圖

35.UML中，對象行為是通過交互來實現的，是對象間為完成某一目的而進行的一系列消息交換。消息序列可用兩種圖來表示，分別是（D）

A.狀態圖和順序圖 B.活動圖和協作圖

C.狀態圖和活動圖 D.順序圖和協作圖

36.用例（Use-case）用來描述系統在事件做出響應時所采取的行動。用例之間是具有相關性的。在一個“訂單輸入子系統”中，創建新訂單和更新訂單都需要檢查用戶帳號是否正確。那么，用例“創建新訂單”、“更新訂單”與用例“檢查用戶帳號”之間是（A）關系。

A.包含（include）B.擴展（extend）

C.分類（classification）D.聚集（aggregation）

1、組成UML有三種基本的建筑塊是：（A），事物和圖

A、關系 B、類 C、用例 D、實體

2、UML體系包括三個部分：UML基本構造塊，（A）和UML公共機制

A、UML規則 B、UML命名 C、UML模型 D、UML約束

4、（A）模型的缺點是缺乏靈活性，特別是無法解決軟件需求不明確或不準確的問題

A、瀑布模型 B、原型模型 C、增量模型 D、螺旋模型

5、下面哪個不是UML中的靜態視圖（A）

A.狀態圖 B.用例圖 C.對象圖 D.類圖

6、（A）技術是將一個活動圖中的活動狀態進行分組，每一組表示一個特定的類、人或部門，他們負責完成組內的活動。

A、泳道 B、分叉匯合 C、分支 D、轉移

7、下列關于狀態圖的說法中，正確的是（C）

A.狀態圖是UML中對系統的靜態方面進行建模的五種圖之一。B.狀態圖是活動圖的一個特例，狀態圖中的多數狀態是活動狀態

C.活動圖和狀態圖是對一個對象的生命周期進行建模，描述對象隨時間變化的行為。D.狀態圖強調對有幾個對象參與的活動過程建模，而活動圖更強調對單個反應型對象建模

8、對反應型對象建模一般使用（A）圖

A、狀態圖 B、順序圖 C、活動圖 D、類圖

12、（D）是系統中遵從一組接口且提供實現的一個物理部件，通常指開發和運行時類的物理實現 A、部署圖 B、類 C、接口 D、組件

13、關于協作圖的描述，下列哪個不正確（B）

A.協作圖作為一種交互圖，強調的是參加交互的對象的組織； B.協作圖是順序圖的一種特例 C.協作圖中有消息流的順序號；

D.在ROSE工具中，協作圖可在順序圖的基礎上按“F5”鍵自動生成； 8定義大多數的需求和范圍的工作是在UP中的 B 階段完成的。A初始階段 B細化階段 C構造階段 D提交階段

1.信息系統設計是系統開發的重要階段，進行系統設計的主要依據應是（）。A、可行性研究報告B 系統分析報告

C、系統調查報告 D、系統規劃報告

3.在系統總體結構設計時，應采納什么樣的方法（）。A、程序設計 B、結構化設計 C、由里向外 D、自底向上 4.結構化設計的基本思想是（）。

A、模塊化 B、集成化 C、自底向上，逐步求精 D、規范化

5.在結構化生命周期法中，系統分析和系統實施之間的階段是（）。A、詳細設計 B系統設計 C、需求分析 D、編程調試 6.對于結構化設計思想的描述哪一項是錯誤的（）。

A、在結構化設計中，模塊的功能應當簡單明確，易于理解 B、自頂向下，逐步求精

C、設計者應先設計頂層模塊

D、越下層模塊，其功能越具體，越復雜 8.系統設計階段的主要目的是（）。

A、設計新系統的目標 B 將系統邏輯方案轉換成物理方案 C、代碼設計 D、程序設計 19.結構化設計方法中繪制模塊結構圖的基礎是（）。A 數據流程圖 B、數據關系圖 C、數據結構圖 D、業務流程圖 29.系統設計階段的主要工作內容之一是（）。

A、程序設計 B、購置計算機 C、畫出數據流程圖 B、規定處理過程 31.系統的呑吐量指的是（）。

A、每天的數據輸出量 B、每秒數據的處理量 C、每日數據的輸入量 D、每秒執行的作業數

33.在系統物理配置方案的設計中，系統的（）可以用連續工作時間來表示。A、吞吐量 B、響應時間 C 可靠性 D、地域范圍 34.計算機和網絡系統配置說明，應包含在()中。

A、系統規劃說明書 B、系統設計說明書 C、系統實施說明書 D、系統分析說明書 35.屬于系統詳細設計工作的是（）。

A、輸入輸出設計 B、系統平臺設計 C、系統結構設計 D、程序設計 39.系統設計報告的主要作用是作為（）的依據。A、系統規劃 B、系統分析 C、系統實施 D、系統評價

1.B 3.B 4.A 5.B 6.D8.B 19.A 29.D 31.D 33.C 34.B 35.A 39.C 11.系統設計階段需要從數據流程圖導出模塊結構圖。B.生命周期結構(Lifecycle Architecture)里程碑 4．系統實施的主要活動包括（D）。C.初始功能(Initial Operational)里程碑 A、編程、系統調試 B、系統安裝 C、新舊系統轉換 D、以上都是 1．系統實施是以（B）為依據的。

A、系統分析文檔資料 B、系統設計文檔資料

C、系統分析和設計文檔資料 D、數據流程圖

7.一般子系統的劃分是在系統()階段,根據對系統的功能/數據分析的結果提出的.A.需求分析 B.邏輯階段 C.總體設計 D.詳細設計 答案: A 4.業務系統規劃法(BSP)的核心是()A.明確企業目標 B.定義(識別)業務過程 C.進行數據分析 D.確定信息結構 答案: C 7.一般子系統的劃分是在系統()階段,根據對系統的功能/數據分析的結果提出的.A.需求分析 B.邏輯階段 C.總體設計 D.詳細設計 答案: A 4.業務系統規劃法(BSP)的核心是()A.明確企業目標 B.定義(識別)業務過程 C.進行數據分析 D.確定信息結構 答案: C 12.RUP中的軟件生命周期在時間上被分解為四個順序的階段,分別是:初始階段(Inception),細化階段(Elaboration),構造階段(Construction)和交付階段(Transition),每個階段結束于一個主要的里程碑(Major Milestones).構建階段結束時是第三個重要的里程碑:初始功能(Initial Operational)里程碑.A.生命周期目標(Lifecycle Objective)里程碑

D.產品發布(Product Release)里程碑 答案: C

14.信息系統開發的結構化方法的一個主要原則是().A.自頂向下原則 B.自底向上原則 C.分步實施原則 D.重點突破原則 答案: A

16.一般來說,占維護工作比例最高的是().A.糾錯性維護 B.適應性維護 C.完善性維護 D.預防性維護 答案: C

17.用戶開發應用系統的主要手段是().A.生命周期法 B.原型法 C.第四代語言 D.面向對象方法 答案: A

19.系統規劃的主要任務包括().A.明確組織的信息需求,制定系統總體結構方案 B.對系統進行經濟,技術和使用方面的可行性研究 C.選擇計算機和網絡系統的方案 D.確定軟件系統的模塊結構 答案: A

20.系統設計階段的主要成果是().A.用戶的決策方針 B.用戶的分析方案 C.系統設計說明書 D.系統總體設計方案

答案: C

21.信息系統建設的結構化方法中用戶必須參與的原則是用戶必須參與().A.系統建設中各階段工作 B.系統分析工作 C.系統設計工作 D.系統實施工作 答案: A

22.結構化生命周期法的主要缺點之一是().A.系統開發周期長 B.缺乏標準,規范

C.用戶參與程度低 D.主要工作集中在實施階段 答案: A 24.系統分析工作的全面總結和主要成果是().A.可行性研究報告B.數據詞典 C.系統說明書 D.系統詳細調查報告 答案: A 28.生命周期法的特點之一是().A.整個系統的開發工作是非勞動密集型的 B.系統開發時間短

C.對用戶需求的變更能做出迅速響應 D.適合大型復雜系統 答案: C 30.系統維護中要解決的問題來源于().A.系統分析階段 B.系統設計階段 C.系統實施階段 D.三者都包括

答案: D 38.下面哪一項不是系統設計階段的主要活動().A.系統總體設計 B.系統硬件設計 C.系統詳細設計 D.編寫系統實施計劃 答案: D 39.對于結構化設計思想的描述哪一項是錯誤的().A.在結構化設計中,模塊的功能應當簡單明確,易于理解

B.自頂向下,逐步求精

C.設計者應先設計頂層模塊

D.越下層模塊,其功能越具體,越復雜

答案: D 73.在系統生命周期的各階段中,花費費用和人力投入最多的階段是().A.分析與設計 B.編制程序 C.測試程序 D.系統維護

答案: A 78.在UML提供的圖中,()用于描述系統與外部系統及用戶之間的交互.A.用例圖 B.類圖 C.對象圖 D.部署圖

答案:A 79.在UML提供的圖中,()用于按時間順序描述對象間的交互.A.網絡圖 B.狀態圖 C.協作圖 D.序列圖（順序圖）答案:D 96.系統分析報告的主要作用是().A.系統規劃的依據 B.系統實施的依據 C.系統設計的依據 D.系統評價的依據 答案:C 95.繪制系統流程圖的基礎是().A.數據關系圖 B.數據流程圖 C.數據結構圖 D.功能結構圖 答案:B

9.信息系統開發的步驟是:在系統規劃后,循進行_____, _____, _____ ,_____ 工作.答案: 系統分析 系統設計 系統構建與實施 系統評價 13.信息系統規劃有哪些方法

答:用于企業信息系統規劃的方法主要有戰略分析法,即關鍵成功因素法(Critical Success Factors,CSF);企業分析法,即企業系統規劃法(Business System Planning,BSP);基于BPR的信息系統戰略規劃方法.其他的方法還有戰略目標集轉化法(Strategy Set Transformation,SST),企業信息分析與集成技術(BIAIT),投資回收法(R01)等.12.RUP中的軟件生命周期在時間上被分解為四個順序的階段,分別是:初始階段(Inception),細化階段(Elaboration),構造階段(Construction)和交付階段(Transition),每個階段結束于一個主要的里程碑(Major Milestones).構建階段結束時是第三個重要的里程碑:初始功能(Initial Operational)里程碑.A.生命周期目標(Lifecycle Objective)里程碑 B.生命周期結構(Lifecycle Architecture)里程碑 C.初始功能(Initial Operational)里程碑 D.產品發布(Product Release)里程碑

答案: C

14.信息系統開發的結構化方法的一個主要原則是().A.自頂向下原則 B.自底向上原則 C.分步實施原則 D.重點突破原則 答案: A

16.一般來說,占維護工作比例最高的是().A.糾錯性維護 B.適應性維護 C.完善性維護 D.預防性維護 答案: C

17.用戶開發應用系統的主要手段是().A.生命周期法 B.原型法 C.第四代語言 D.面向對象方法

答案: A

19.系統規劃的主要任務包括().A.明確組織的信息需求,制定系統總體結構方案 B.對系統進行經濟,技術和使用方面的可行性研究 C.選擇計算機和網絡系統的方案 D.確定軟件系統的模塊結構 答案: A

20.系統設計階段的主要成果是().A.用戶的決策方針 B.用戶的分析方案 C.系統設計說明書 D.系統總體設計方案 答案: C

21.信息系統建設的結構化方法中用戶必須參與的原則是用戶必須參與().A.系統建設中各階段工作 B.系統分析工作 C.系統設計工作 D.系統實施工作 答案: A 22.結構化生命周期法的主要缺點之一是().A.系統開發周期長 B.缺乏標準,規范

C.用戶參與程度低 D.主要工作集中在實施階段 答案: A 24.系統分析工作的全面總結和主要成果是().A.可行性研究報告B.數據詞典 C.系統說明書 D.系統詳細調查報告 答案: A 28.生命周期法的特點之一是().A.整個系統的開發工作是非勞動密集型的 B.系統開發時間短

C.對用戶需求的變更能做出迅速響應 D.適合大型復雜系統 答案: C 30.系統維護中要解決的問題來源于().A.系統分析階段 B.系統設計階段 C.系統實施階段 D.三者都包括 答案: D 38.下面哪一項不是系統設計階段的主要活動().A.系統總體設計 B.系統硬件設計 C.系統詳細設計 D.編寫系統實施計劃

答案: D 39.對于結構化設計思想的描述哪一項是錯誤的().A.在結構化設計中,模塊的功能應當簡單明確,易于理解

B.自頂向下,逐步求精

C.設計者應先設計頂層模塊

D.越下層模塊,其功能越具體,越復雜

答案: D 73.在系統生命周期的各階段中,花費費用和人力投入最多的階段是().A.分析與設計 B.編制程序 C.測試程序 D.系統維護

答案: A 78.在UML提供的圖中,()用于描述系統與外部系統及用戶之間的交互.A.用例圖 B.類圖 C.對象圖 D.部署圖 答案:A 79.在UML提供的圖中,()用于按時間順序描述對象間的交互.A.網絡圖 B.狀態圖 C.協作圖 D.序列圖（順序圖）

答案:D

96.系統分析報告的主要作用是().A.系統規劃的依據 B.系統實施的依據 C.系統設計的依據 D.系統評價的依據 答案:C

95.繪制系統流程圖的基礎是().A.數據關系圖 B.數據流程圖 C.數據結構圖 D.功能結構圖 答案:B

9.信息系統開發的步驟是:在系統規劃后,循進行_____, _____, _____ ,_____ 工作.答案: 系統分析 系統設計 系統構建與實施 系統評價 13.信息系統規劃有哪些方法

答:用于企業信息系統規劃的方法主要有戰略分析法,即關鍵成功因素法(Critical Success Factors,CSF);企業分析法,即企業系統規劃法(Business System Planning,BSP);基于BPR的信息系統戰略規劃方法.其他的方法還有戰略目標集轉化法(Strategy Set Transformation,SST),企業信息分析與集成技術(BIAIT),投資回收法(R01)等.2.信息系統規劃是指對組織目標、組織現狀進行分析，從而制定指導信息系統建設的總體規劃和信息系統長期發展展望。在眾多的信息系統規劃方法當中，具有代表性的主要有 企業系統規劃法、戰略目標轉移法、關鍵成功因素法。

4.信息系統建設的特點決定了信息系統建設要做大量復雜和細致的工作。信息系統建設主要包括 信息系統規劃、信息系統開發、信息系統維護 和 信息系統管理 四方面的工作。

1． UML統一建模語言共定義了哪兩類、哪八種圖形？

答：（1）靜態結構圖：類圖，對象圖，構件圖，實施圖

（2）動態行為圖：用例圖，順序圖，協作圖，狀態圖，活動圖

2.在下圖所示的用例分析類圖中，請指出各個概念類屬于哪一類，并分別解釋三種概念類的特點及概念?！笆蹠幚怼钡挠美治鲱悎D書目售書員售書界面產生待售圖書待售圖書開書單打印進程架存圖書出售圖書售出圖書答：屬于實體類的有：書目、架存圖書、代售圖書、售出圖書。

屬于邊界類的有：售書界面。

屬于控制類的有：產生待售圖書、出售圖書、開書單。三種概念類的特點及概念：

特點：概念類面向功能需求，一般不考慮性能要求，具有突出業務領域、突出概念性及大粒度的特征。概念：（1）實體類是信息系統表示客觀實體的抽象要素。它一般對應著在業務領域中的客觀事物，或是具有較穩定信息內容的系統元素。（2）邊界類是描述系統與參與者之間交互的抽象要素。邊界類只是對信息系統與參與者之間交互的抽象建模，并不表示交互的具體內容及交互界面的具體形式。

（3）控制類是表示信息系統對其他對象實施協調處理、邏輯運算的抽象要素。3．請根據下圖所示的概念模型，將其轉換為邏輯模型(即寫出其關系模式)。

編號姓名讀者職業電話住址郵編*待售圖書*類別單價出版日期書號架位架存冊數書號書名作者出版社1選書*架存圖書*11書目書單號冊數折扣率交款標記售書員答：根據其E-R圖，其關系模式為：

讀者(編號，姓名，職業，電話，住址，郵編)架存圖書(書號，架位，架存冊數)

待售圖書(書單號，冊數，折扣率，交款標記，售書員)書目(書號，書名，作者，出版社，出版日期，類別，單價)9.如圖，是在網上商店系統經理的用例圖如下：

網上購物系統顧客的功能用例

1.單一職責原則（Single Responsibility Principle, SRP）：

? There should never be more than one reason for a class to change.? 應該有且僅有一個原因引起類的變更 2.里氏替換原則 最正宗的定義：

If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.（如果對每一個類型為S的對象o1，都有類型為T的對象o2，使得以T定義的所有程序P在所有的對象o1都代換成o2時，程序P的行為沒有發生變化，那么類型S是類型T的子類型。）里氏替換原則

通俗講，只要父類出現的地方子類就可以出現，而且替換為子類也不會產生任何錯誤或異常，使用者可能根本就不需要知道是父類還是子類。但是反過來就不行了，有子類出現的地方，父類未必就能適應。3.迪米特法則

迪米特法則的定義：

迪米特法則（Law of Demeter, LoD）也稱為最少知識原則，一個對象應該對其他對象有最少的了解。

一個類應該對自己需要耦合或調用的類知道得最少，被耦合或調用的類的內部如何復雜都和我沒有關系，那是你的事情，我就知道你提供的這么多public方法，我就調用這么多，其他的我一概不關心。4.開閉原則

開閉原則的定義：

一個軟件實體如類、模塊和函數應該對擴展開放，對修改關閉。

一個軟件實體應該通過擴展來實現變化，而不是通過修改已有的源代碼來實現變化。5.依賴倒置原則

依賴倒置原則包含三層含義：

? 高層模塊不應該依賴低層模塊，兩者都應該依賴其抽象；

? ? 抽象不應該依賴細節； 細節應該依賴抽象。

在java語言中，抽象就是指接口或抽象類，兩者都是不能直接被實例化的；細節就是實現類，實現接口或繼承抽象類而產生的類就是細節，其特點就是可以直接被實例化，也就是可以加上一個關鍵字new產生一個對象。6.接口隔離原則

接口隔離原則定義：

? ? 客戶端不應該依賴它不需要的接口；

類間的依賴關系應該建立在最小的接口上。

建立單一接口，不要建立臃腫龐大的接口，接口盡量細化，同時接口中的方法盡量少。它要求“盡量使用多個專門的接口”。專門接口指提供給每個模塊的都應該是單一接口，提供給幾個模塊就應該有幾個接口，而不是建立一個龐大的臃腫接口，容納所有的客戶端訪問。

1.在RUP中，軟件開發生命周期根據時間和RUP的核心工作流劃分為二維空間。橫軸表示項目的時間維，縱軸以內容來組織為自然的邏輯活動。

第二篇：系統分析與設計心得

讀《系統分析與設計方法》一書有感

作為一個軟件專業的學生，理解和掌握系統分析與設計的知識是必不可少的。在閱讀《系統分析與設計方法》一書中以及加上老師教導，我學到了很多東西，收獲不少。

系統就是由若干可以相互區別、由相互聯系并且各自獨立的單元組成各個子系統之間同樣是獨立而又相互聯系的。系統具有集合性、相關性、目的性、整體性和環境適應性。在開發完成一個軟件項目的過程中，系統工程必須經過開發階段、建造階段、運行階段、更新階段、維護階段。

系統分析與設計的方法主要包括結構化生命周期法（又稱瀑布法）、原型化方法（迭代法）、面向對象方法。

按時間過程來分，開發方法分為生命周期法和原型法，實際上還有許多處于中間狀態的方法。原型法又按照對原型結果的處理方式分為試驗原型法和演進原型法。試驗原型法只把原型當成試驗工具，試了以后就拋掉，根據試驗的結論做出新的系統。演進原型法則把試好的結果保留，成為最終系統的一部分。

按照系統的分析要素，可以把開發方法分為三類：

①面向處理方法（Processing Oriented，簡稱PO）。

②面向數據方法（Data Oriented，簡稱DO）。

③面向對象的方法（Object Oriented，簡稱OO）。

系統分析和設計應遵循的原則有：

系統開發是面向客戶的，應從客戶的角度考慮。

諸如系統開發生命周期之類的產品更新換代機構應該在所有的信息系統開發項目中建立起來。

信息系統開發的過程并不是一個順序的過程，它允許步驟的重疊和倒轉等。

如果系統的成功可能性受到很大限制時，應取消整個項目。文檔材料是系統開發生命周期中重要的可遞交成果，應加以重視。在本書的第一部分中，主要集中于系統分析和設計的整體描述，包括系統分析和設計方法的環境，信息系統構件，信息系統開發，項目管理。期中印象比較深刻的是系統開發過程的能力成熟度模型（CMMI）。信息系統和軟件的CMM框架用來幫助改善其系統開發過程的成熟度。CMM包括了五個成熟度等級：初始級、可重復級、已定義級、已管理級、優化級。期中，每個等級都是下一個等級的必須條件。

在軟件開發過程中需求分析階段是至關重要的一個階段，需求分析階段可能被稱為定義階段或者邏輯設計階段。需求分析階段的第一個任務是確定需求，在這個階段至少將目標轉換成為滿足其需要的功能需求和非功能需求的框架。在這個階段需要交付的成果是功能需求和非功能需求的草稿。在初步定義完了功能需求和非功能需求后，得排列需求的優先次序。如果一個項目落后于進度或者超出預算，知道哪個需求比其他需求更重要可能是很有用的。在排列需求的優先次序中可以使用到時間盒的技術。需求分析并不會真正的技術，因為企業需要具有快速適應不斷變化的需求和機會的能力。信息系統不能比企業自身的響應技術還慢。

在學習本書第二部分的時候，我了解到了需求分析在整個項目開發中的作用以及成為整個項目主導的因素。只要好的需求才能設計開發出好的軟件項目。在項目開發過程中，我們還可以利用圖表的形式來簡化方便人員的開發設計。期中有五種圖表是系統分析師常用的：類圖、用例圖、協作圖、順序圖、狀態圖。期中用例圖是用例建模的產物，它以圖形化的方式將系統描述成用、參與者（用戶）及其之間的關系。簡單的說就是用直立的小人來表示參與者（用戶），用圓圈來表示用例，他們之間以箭頭的形式來連接。關系包括了：關聯關系、擴展關系、使用關系、依賴關系、繼承關系。但是書上沒講到《include》關系，跟老師的講解有點出路。老師在講義上通過畫圖的方式很好的解釋了《include》和《extend》的關系。

數據建模這一章節中，我了解了數據建模的含義，它是一種為數據庫定義業務需求的技術。數據建模中比較重要的概念有實體和屬性之間的關系，關系是連接實體的一個時間，或者僅僅是存在于實體之間的邏輯關系。關系有很多種類，多對多、一對多、一對

一、等等。這些關系的圖形化符號記起來很不容易，但是我自己想到了一個比較容易記憶的簡單的方法。一個就用 “|”表示，零個就用“0”表示，多個就用“<”表示，然后根據相應的說明來選擇。比如零個或一個（0|），一個或多個（|<）。過程建模是一種組織和記錄數據的結構和流向的技術，它記錄系統的“過程”和有系統的“過程”實現的邏輯、策略和程序。期中也介紹到了數據流圖（DFD），數據流圖是一種描述通過系統的數據流以及系統實施的工作或處理過程的工具。我覺得數據流圖DFD的最大的優點就是容易閱讀，因為數據流圖僅有三種符號和一種連接：圓角矩形表示要完成的過程或者工作，正方形表示外部代理（系統的邊界），開放的方框表示數據存儲（可以是文件或者數據庫），箭頭表示數據流（可以是輸入和輸出，或者是表示到過程和來自過程）。統一建模語言UML的目的就是對面向對象系統進行可視化、評述、和文檔化。它適用于系統開發從需求規格描述道系統完成后測試的不同階段（需求分析階段、分析階段、設計階段、編程階段、測試階段）。UML2.0的模型主要圖包括了：用例圖、活動圖、類圖、對象圖、狀態機圖、組合結構圖、交互圖、定時圖、組件圖、部署圖和包圖。在理解這章的過程中，我感覺比較輕松，但是把一些關系，事件，實體等等用圖形化的形式表示出來還是非常難的。用UML設計面向對象系統時候，我們得準確的找到實體類、接口類、控制類、持續類、系統類和設計關系。在面向對象設計的過程中，主要包括了一下活動：對用例模型加以精煉以反映實現環境；建模支持用例情景的對象交互、行為和狀態；修改對象模型以反映實現環境。

前面說到需求分析是整個軟件項目開發中最重要的一環，其實我覺得可行性分析也是跟需求分析一樣的重要。因為信息是一個必須經過檢驗的重要資本投入，就像市場要檢驗一個新產品，系統分析員應該考慮投資能夠收回嗎？是否有其他投資能夠帶來比預期更高的回報。要說他們的區別，我個人覺得是：可行性分析是要決定“做還是不做”。需求分析是要決定“做什么，不做什么”?？尚行苑治鰣蟾嬗辛鶄€準則：運行可行性、文化可行性、技術可行性、進度可行性、經濟可行性。只有進行了可行性分析報告，才能夠確定企業是否要 做這個項目。如果說在可行性報告中顯示沒有成功的可能，那么就沒有必要再做需求分析了，整個項目就不會做下去了。進行可行性分析報告可以避免項目中途告終的結果，在系統開發過程中舉足輕重。

數據庫開發與設計這章，感覺書上講解的沒有老師講的詳細。書上并沒有提到范式，但是在課堂上我了解到數據庫設計的范式。有第一范式、第二范式、第三范式、BC范式等。等級越高，數據冗余越少，對系統調用數據庫更方便。數據庫的核心是DBMS，DBMS的核心是數據庫引擎，引擎響應專門的命令以創建數據庫結構，然后創建、讀取、修改和刪除數據庫中的記錄。DBMS使用數據定義語言（DDL）創建記錄類型、字段和結構化關系，還定義了數據庫視圖；DBMS還是用數據處理語言（DML）用來創建、讀取、修改和刪除數據庫中的記錄。但是并非所有數據庫的DBMS都被要求使用DDL和DML?？赐赀@章，總結了一下建立關系數據庫模式的步驟，首先要為每個實體類型建立一張表，然后為每張表選擇一個主鍵，同時增加外鍵來表示一對多的關系，接著還可以建立幾個新表來表示多對多的關系，然后還得定義參照完整性約束，評價模式質量，并且進行必要的改進，最后為每個字段選擇適當的數據類型和取值約束。數據庫在系統開發的過程中是必不可少的，幾乎所有框架類型都得用到數據庫，它也是MVC框架的底層核心。

對于本書的還有一個比較映像深刻的就是UI（user interface），用戶界面設計。一個良好的用戶界面應該為用戶提供友好的使用方式，通過用戶界面用戶可以同應用程序打交道，處理輸入并且獲得輸出。Galitz曾經提出過用戶界面設計的原則：理解你的用戶及任務、讓用戶參與界面設計、在實際用戶中測試系統、進行迭代設計。記得以前大二的時候學習JAVA的時候，我曾經開發過基于圖形用戶界面（GUI）的聊天軟件，不過當時的界面設計完全設計的是隨心所欲，并沒有理論作為指導。在學習VB課程的時候學過UAR，簡單的了解了一些關于界面友好化設計的原則。這本書也給出了用戶界面設計過程的幾個步驟：1.以圖表形式描述用戶界面對話；2.原型化對話和用戶界面；3.獲得用戶反饋；4.如果需要，回到1步或者2步。

最后總結下，雖然我沒用把這本書的每一個地方都認真精讀，有些地方略讀的，但是看完整本書后我收獲很大。讀完《系統分析與設計方法》這本書再加上老師在課堂上的一些講解以及以前學習事件過程中的收獲，我對于系統分析與設計有了進一步的理解，能高屋建瓴的看待系統分析與設計整個過程的步驟以及增加了一些開發設計中的重要事件的理論知識。

對于系統分析的心得

第三篇：系統分析與設計總結

第一章 概述

信息系統的五個組成部分：硬件、軟件、規程（processes）、數據、人

SDLC（System Development Life Cycle 系統開發生命周期）包括：計劃、分析、設計、實施、運維。替代方法：Prototyping（原型法）、CASE Tools（Computer-aided Software Engineering tools 計算機輔助軟件工程工具）、JAD（Joint Application Design 聯合應用設計）、RAD（Rapid Application Development 快速應用軟件開發）、敏捷方法（Agile Methodologies）、極限編程（Extreme Programming）。

第二章 計劃

總體規劃（Strategic planning）模型：諾蘭模型（初始、蔓延、控制、集成、數據管理、信息管理）。

總體規劃原則：支持企業總目標；面向各個管理層次；方法上擺脫信息系統對企業組織的依賴性；結構上具有良好的整體性；便于實施。

總體規劃的方法：關鍵成功因素法、戰略目標集轉換法、企業系統計劃法、信息系統規劃與企業過程重組、信息系統規劃和企業形象系統。

總體規劃步驟：準備工作、組織機構調查、定義管理目標、定義管理功能、定義數據類、定義信息結構（劃分子系統）、確定子系統實施順序。準備工作

確定規劃內容、成立規劃小組、收集數據、制定計劃、開好動員會。定義管理功能

資源的生命周期：產生、獲得、服務、歸宿 識別管理功能：根據資源識別（OO）、根據決策與活動識別（SSAD）管理功能是管理各類資源的各種相關活動和決策的組合 定義數據類

方法：實體法（如圖2-1）、功能法（如圖2-2）

兩者組合形成初始功能數據類矩陣（圖2-3）

圖2-1

圖2-2

圖2-3 定義信息結構

劃分子系統的方法：在初始功能數據矩陣中，排列數據類，使得矩陣中的C靠近主對角線。

確定子系統實施順序

根據企業目標和技術約束確定

原則：子系統的需求程度與潛在的效益評估、技術約束分析

信息系統需求：Improved service(改善服務)、Better performance（更好的性能）、More information（更多的信息）、Stronger controls（更強的控制）、Encryption and biometric devices、Reduced cost（降低成本）

影響系統因素

內部：Strategic plan（總體規劃）、Top managers（高層管理人員）、User requests（用戶需求）、Information technology（信息技術）、department（部門）、Existing systems（現有系統）

外部：software/hardware vendors（軟硬件供應商），technology（技術），suppliers，customers（客戶），competitors（競爭者），the economy（經濟），government（政府）

可行性分析

操作可行性（Operation feasibility）：系統在開發之后可以正常使用 技術可行性（Technical feasibility）：開發系統所需要的技術資源 經濟可行性（Economical feasibility）：Total cost of ownership(TCO)總擁有成本

進度可行性（Schedule feasibility）

信息系統初步調查（Preliminary investigation）

Understand the problem（了解問題）

Define the scope and constraints（確定范圍和約束）Perform fact-finding（進行實地考察）Estimate Feasibility（估計可行性）

Estimate development time/cost（評估項目成本、時間）Present results and recommendations（提出結果和建議）

第三章 需求模型（Requirements Modeling）

系統分析階段

包括：需求建模（Requirements Modeling）、企業建模（Enterprise Modeling）、開發策略（Development Strategy）

階段交付物：系統需求文檔（System Requirements document）

方法： JAD（Joint Application Development 聯合應用程序開發）

RAD（Rapid Application Development 快速應用軟件開發）

? Explain how systems analysts use a functional decomposition diagram(FDD)系統需求列表

輸出、輸入、處理、性能、控制、可擴展性（Scalability）、TCO（Total cost of ownership 總擁有成本）

實情考察方法（Fact-Finding）Interviews（訪談法）

documentation review（文檔審查）observation（觀察法）

questionnaires and surveys（問卷調查）sampling（抽樣法）research（研究）訪談法步驟

1.Determine the people to interview（確定訪談人群）2.Establish objectives for the interview（確定訪談目標）3.Develop interview questions（設計問題）4.Prepare for the interview（準備訪談）5.Conduct the interview（實施）6.Document the interview（記錄）7.Evaluate the interview（評估）抽樣法方法

隨機抽樣（Random sample）

分層抽樣（Stratified sample）

系統抽樣（Systematic sample）

文檔編寫原則

Record information as soon as possible（盡快記錄）

Use the simplest recording method（使用最簡單的記錄方法）Ensure that your work is understandable（能讓他人理解）Organize your documentation material（合理組織材料）

第四章 企業建模（Enterprise Modeling）

企業建模

產生：邏輯模型（Logical Model）

工具：Entity-relationship Diagrams（ERD E-R圖）

Data Flow Diagrams（DFD 數據流程圖）Data Dictionary（DD 數據字典）

Process Descriptions（PD 處理邏輯說明書）Query Analysis（QA 存取分析）

E-R圖

關系種類：一對一、一對多、多對多 數據流程圖

符號（Gane and Sarson symbol）包括：processes（處理邏輯），data flows（數據流），data stores（數據存儲），entities（外部實體）

種類：Context Diagram（第一層數據流程圖，無數據存儲）

Diagram 0（將第一層擴展，保持第一層的數據流）Lower-Level Diagram（子數據流程圖）

Lower-Level Diagram畫法：leveling（分層顯示 分層方法：Exploding、partitioning、decomposing）and balancing（前后數據流保持不變）

相關概念：

Black Hole：A process that has no output.Gray Hole：A process with at least 1 input and output, but the input is insufficient to generate the shown output.Spontaneous Generation Process：Used to describe an unexplained generation of data or information.數據字典

概念：對數據流程圖中的各個成分的含義進行描述的工具

用途：對數據流程圖的補充說明、參照，用于檢索，檢驗一致性與完整性 內容 ：數據元素：又叫數據項，是最小數據組成單位，不可分割

數據結構：數據之間的組合關系 數據流

數據存儲：數據存儲的結構，有關的數據流和查詢要求 處理邏輯 外部實體

方式：人工、計算機 常用屬性：

數據元素（名稱、類型/長度、默認值、值域、來源、安全、負責人、描述）數據結構（名稱、描述、屬性）

數據流（名稱、描述、來源、目的地、所包含數據結構、使用頻率）數據存儲（名稱、描述、屬性、使用頻率）處理邏輯（名稱、描述、編號、輸入、輸出）外部實體（名稱、描述、輸入流、輸出流）

處理邏輯說明書

工具：

結構化語言：一種用于描述處理邏輯的介于自然語言和程序語言之間的語言。包括三種基本語句：祈使句、判斷語句、循環語句。沒有嚴格的語法，極其有限的詞匯（祈使句中的動詞、數據字典中的名詞、邏輯表達式中的保留字）

決策樹：

決策表：

現將所有情況列出，在不斷進行合并，下表為最終表

存儲分析

目的：DFD中定義了數據存儲，DD中對數據存儲的數據結構作了描述，但沒有說明立即存取與實時響應，是補充。

存取類型：E：實體 A：屬性 V：屬性值 已知E、A，求V 2 已知A、V，求E 3 已知E、V，求A 4 已知E，求A、V 5 已知A，求E、V 6 已知V，求A、E

邏輯模型和物理模型的區別

邏輯模型展示信息系統有什么功能；物理模型展示信息系統的功能如何實現

Four-Model Approach 包括：原系統的物理模型、原系統的邏輯模型、所開發系統的邏輯模型、所開發系統的物理模型

第五章 開發策略（Development Strategies）

軟件開發趨勢

Software as a Service：軟件即服務

Software and Information Industry Association(SIIA)軟件與信息產業協會 application service providers（ASP）軟件服務提供商 軟件開發策略

Develop in-house Buy software package Customize 選擇考慮因素

total cost of ownership(TCO)系統需求文檔

包括：requirements for the new system（新系統的要求）

describes the alternatives that were considered（描述備選方案）

第六章

總體設計（General Design）

包括：硬件設計、軟件設計、網絡設計、子系統劃分與模塊結構 設備選配的依據：總體方案、容量、外設（數量、速度）

設備選配的指標：可靠性、可維修性、兼容性、熟悉性、方便性、可擴充性、經濟合理性

硬件設計：主站、工作站、外圍設備、主要性能指標

軟件設計：中文、操作系統、數據庫管理系統、其他開發環境、各種工具、各種媒體的編輯、處理軟件

網絡設計：網絡結構、拓撲結構、傳輸介質、網關、網絡管理軟件、OA設備

子系統劃分與模塊結構 方法：系統流程圖（強調執行順序）、HIPO（Hierarchy Plus Input/Process/Output）（強調層次）、模塊結構圖

模塊結構圖

方法：事務分析法、變換分析法 事務分析法

適用于高層數據流程圖，每一個處理邏輯都是一個事務 變換分析法

步驟： 1 找出系統的邏輯輸入、主加工和邏輯輸出設計頂層模塊和第一層模塊設計中下層模塊

系統總體優化的準則

模塊的耦合：模塊間的關聯程度

模塊的聚合：模塊內的緊湊程度

模塊的分解：分解到功能聚合型模塊為止

模塊的扇入和扇出：

扇入：一個模塊的上級模塊叫做扇入模塊 扇出：一個模塊控制的下級模塊叫扇出模塊

原則：扇入越大越好，扇出數目控制在7±2范圍內 模塊的控制范圍和判斷作用范圍：

控制范圍：指模塊本身和它的下級模塊

判斷作用范圍：模塊和有判斷調用的模塊的組合

第七章 數據設計（Data Design）

數據與文件分類

存儲方式、文件命名規則設計 規范化設計

1NF：在同一個表中無重復項出現 2NF：有且僅有一個數據元素為主鍵

3NF：表中所有數據元素不但要能夠唯一的被主鍵表示，而且他們之間還必須相互獨立

一致性、完整性、有效性、安全性 存儲過程

第八章 代碼設計（Code Design）

代碼的概念

一個或者一組有序的易于計算機和人識別與處理的符號。代碼的意義

鑒別、分類、排序、特殊意義

代碼設計的步驟

1.信息分類

原則：科學性、系統性、可擴充性、兼容性、綜合實用性 方法：

線分類法（將選定的分類對象按若干屬性逐次地分成若干層級的類目）面分類法（若干屬性獨立分類、沒有上下級的從屬關系）2.編碼

原則：唯一性、合理性、可擴充性、簡單性、適用性、規范性 方法：根據代碼的種類和類別進行編碼，然后說明代碼組成的原則

第九章 用戶設計和輸入輸出設計

以用戶為中心設計原則 Understand the underlying business functions 2 Maximize graphical effectiveness 3 Profile the system’s users 4 Think like a user 5 Use prototyping 6 Design a comprehensive interface 7 Continue the feedback process 8 Document the interface design 輸入方式：

批量輸入、聯機輸入（后面太亂了。不寫了。）

第十章 網絡體系結構

B/S 瘦客戶端服務模式 C/S 胖客戶服務模式

兩層設計：Server + Client 三層設計：Server + Application Server + Client

第十一章 系統實施

系統實施過程

1.硬件和軟件的購買 2.網絡的構建 3.應用開發 4.用戶培訓

5.編寫文檔（程序文檔+系統穩定+操作文檔+用戶文檔）6.測試（單元、集成、系統測試）7.安裝 8.評估

9.數據轉換 10.系統上線 系統切換

1.直接切換 2.平行切換 3.試驗切換 4.階段切換

第十二章 系統運營

四種維護

1.改正性維護 2.適用性維護 3.改善性維護 4.預防性維護

維護流程

1.維護請求 2.初步判斷 3.處理請求 4.布置任務 5.用戶通知

系統底線

1.Functional baseline（功能基線，終結于分析階段）2.Allocated baseline（分配基線，終結于設計階段）

3.Product baseline（產品基線，終結于實施、測試階段）

系統退化（System Obsolescence）

原因：無法滿足當前管理的需要（維護無效或維護成本高）這意味著新的系統的開始

第四篇：系統分析與設計心得

系統分析與設計心得(精選多篇)

系統分析師對考生的綜合素質要求較高，考查的知識面很廣。但分析歷年考題可以發現，雖然考試知識面廣但考試內容并不是很深。因此，這就要求我們注意平時積累，經常通過網絡、講座、學術會議等途徑及時了解一些流行技術熱點和業界最新動態。

2、多做項目，在實踐中鍛煉提高

如果說平時積累的各個知識點是一粒粒寶貴的珍珠的話，那么項目經歷則是將這些珍珠串聯起來的一根紅線。“紙上得來終覺淺，絕知此事要躬行”。軟件工程是一門實踐性、綜合性非常強的專業，如果沒有參加過完整的實際項目，就難以從根本上理解書本上所學的

理論知識，就難以真正領會軟件工程的思想精髓。同時，在做項目時還要勤于思考，無論是作為主持者還是作為一個普通的程序員，都應該去潛心思考為什么要這樣設計、這樣設計的優點是什么、有哪些不足，如果你是設計師的話你又會怎樣設計？經常做這樣的換位思考，會不自覺地提高自己的系統分析和設計能力，積累豐富的項目經驗，這對下午一的考試來說是非常有益的。

3、注意提高個人文檔編寫能力

一些軟件工程師有個不好的習慣，那就是只喜歡鉆研具體的技術點而不注重提高文檔編寫能力。他們的一個通病是做得多、寫得少，在某一個具體的技術領域上往往表現得非常優秀，但寫出的文檔質量實在難以恭維。作為一個合格的系統分析師文檔編寫能力是必不可少的基本素質，也是下午二考試的考查重點。

文檔編寫能力不僅對于應試是十分必要的，而且在實際工作也是非常重

要的。因此，我們應當在平時多做這方面的訓練，多思考、多動筆，努力提高自己文檔編寫能力。

4、掌握評卷專家心理，注意論文寫作技巧

在下午二的考試中，應注意把握評卷專家的心理狀況。根據希賽it教育研發中心的著名軟考專家張友生所說的，評卷專家不可能把你的論文一字一句地精讀，要讓他短時間內了解你的論文內容并認可你的能力，必須把握好主次關系，論文的組織一定要條理清晰。一般說來，項目概述部分評卷專家會較認真看，為讓評卷專家對你所做的項目產生興趣，這里可適當吹捧。在論文陳述部分應當按主次關系分條進行陳述，首先最好開門見山指出你所采取的措施，然后指出你為什么這樣做，這樣做有何優點，克服了以前做法的哪些缺點等等。在分條陳述時最好一個問題一個自然段，在每個自然段首先要有一個主題句，主題句簡明扼要地描述本段的中心思

想。

在論文撰寫中，切忌大談空洞的理論知識或不懂裝懂，以專家的姿態高談闊論。應當將重點放在匯報你自己在項目中所做的與論題相關的工作，讓評卷專家相信你確實做過這方面的項目而且達到了相應水平。

在下午二考試時間的分配上，建議首先花3--5分鐘根據個人特長選定題目，然后花10—15分鐘左右整理一下所掌握的素材，列出提綱，即你打算談幾個方面，每個方面你是怎么做的，收效如何等等，簡明扼要地寫在草稿紙上。

5、張友生的書，不能不讀

要想通過系統分析師考試，不但需要多做項目，而且有關全國著名的軟考輔導專家張友生老師的書是不可不讀的。

學習電子商務系統分析與設計的心得體會

《電子商務系統分析與設計》系統地介紹了電子商務系統的規劃、分析、設計、實施與運行管理的基本概念、方法、技術和相關案例。從結構上可以進一步分為4個部分：概述部分，主要說明電子商務系統分析設計的基本概念、內容、過程與方法；系統規劃、分析與設計部分，主要說明系統規劃、分析、設計的方法、內容和工具；系統實施與維護部分，涵蓋電子商務系統的開發與集成、測試、部署、維護、審計與評價；案例部分，給出了兩個完整的案例，從背景、規劃、分析、設計角度幫助我們進一步理解電子商務系統的規劃、分析與設計。圍繞電子商務系統開發過程的各個階段，系統地闡述了電子商務系統開發的思想、方法和技術，包括系統的規劃、分析、設計、實現與維護等內容，重點介紹了采用uml進行系統的分析與設計的方法；并從企業管理者和電子商務應用實踐的角度，對國內外一些典型的企業電子商務解決方案進行了介紹；最后結合實例闡述了運用struts、javaee1.5等新技術進行電子商務系統的

設計與開發的過程，使我們能很好地把理論學習與實踐訓練更好地結合起來。

本課程結合電子商務系統領域的最新技術、方法和實踐，以及電子商務系統應用成果，從理論基礎、方法運用、技術基礎和實踐4個維度對電子商務系統做了較深入、全面的闡述。教科書共十章，第一章介紹電子商務系統的基礎概念和知識；第二章介紹電子商務系統建設的過程與方法；第三章介紹電子商務系統規劃的內容、方法和步驟；第四章介紹電子商務系統的分析方法與工具，重點利用uml進行了系統分析；第五章闡述了電子商務系統設計基礎與思想方法；第六章介紹電子商務支付系統、電子商務系統安全體系設計的思想方法；第七章介紹了電子商務系統的開發技術與模式，并結合實例完整介紹struts2框架web應用開發的基本過程；第八章介紹電子商務系統運行、維護與評價的知識和方法；第九章結合我國實際，介紹了國內外的電子商務系統解決方案；

第十章結合實例和具體技術，系統的闡述了一個電子商務系統從分析、設計到實現的過程，讓我們通過一個電子商務系統的設計實踐和操作，消化和理解所學的理論知識。

本課程在繼承軟件工程和信息系統分析與設計的思想,方法,技術和工具的基礎上,從系統化的思想及結構化開發方法入手,全面介紹電子商務系統特色,規劃方法,系統分析及設計,并依據電子商務自身的特點,著重針對網站設計,支付系統設計及安全系統設計進行分析和介

紹。本實驗課程使學生進一步理解和掌握所學各種電子商務系統分析和設計的方法.熟練掌握系統分析和設計建模軟件.。

本課程目的是為了讓我們能夠全面了解應用系統的整個電子商務系統的開發建設流程，并掌握電子商務系統開發的相關技術：

掌握電子商務系統的分析方法；

掌握電子商務系統的總體設計方法；

學會使用visio軟件構建電子商務系統數據流程圖,use case圖以及活動圖；

體會應用軟件工程的設計思想進行電子商務系統開發的過程與方法。

通過本課程設計，便于我們全面理解電子商務系統規劃、分析與設計知識，并掌握操作方法，而不是獨立地學習某單方面的操作技術；另一方面實用性較強，我們認真完成本書實驗后，基本上可以勝任電子商務系統規劃、分析、設計及實現工作。

學習這門課程，使我對電子商務網站的開發有了一定的了解。掌握了電子商務系統的基本概念、特征及其結構。了解電子商務系統開發技術和發展方向，理解電子商務生命周期的概念、特征及其作用。能夠按要求撰寫電子商務系統規劃報告，基本掌握uml需求分析思路和方法，能結合運用實際撰寫系統分析報告。熟悉電子商務平臺技術，包

括操作系統、應用服務器、中間件技術等?；玖私怆娮由虅罩Ц断到y與安全系統。初步掌握一些電子商務網站客戶端技術。能正確理解電子商務系統評價的作用，并掌握評價指標體系設計的思路等等。

通過一系列的實驗讓我知道了基礎的電子商務分析的方法，掌握對電子商務系統進行系統總體結構設計及應用系統設計的內容及方法。加深理解了在課程中、書本上學到的知識和理論，并使其在課題研究中得到運用而且讓我得到了實踐的收獲。

希望在以后的實習實踐中多接觸、對比一些案例能夠增長對網上電子商務系統設計的一些知識。

0911061237

朱寶

信息系統分析與設計學習心得

通過近10周的學習，我覺得信息系統分析與設計這門課程收獲還是挺大的。我覺得，如果我們決定要做一件事，就得對這個系統有一個整體得把握，首先要進行系統的規劃和選擇，接著就是系統的設計，其中系統設計包括三個部分：1.確定系統需求；2.系統需求結構化：過程建模，這一步驟主要就是畫數據流圖；3.系統需求結構化：概念數據建模，這一過程主要是畫實體—關系圖。然后就是進行系統設計，系統設計包括設計人機界面和數據庫設計。最后一步就是系統的實現與運行。

在做信息系統分析與設計的大作業的時候，我和我們的小組成員曾經去實地考察過，雖然最后并沒有被接待，但還是小有收獲的。通過實地考察，我們能更清晰地了解我們系統所要實現的功能，甚至說讓它比現有系統更加完善。當然，我們做東西，也是要追求進步，如果說做出來的東西和以前的系統都沒什么兩樣，這樣意義也不大。不過，這也得是在我們能力所及的范圍內，我們得適當地把握好自己的時間和現有資源進行適當的設計。相信自己的努力還是

能有一個很好的結果的，我們得對自己的發展有一個好的概括。信息系統分析與設計的大作業從第一周到第九周一直伴隨著我們，說實在話，一直覺得自己有做不完的作業，剛開始還有些抱怨，但隨著作業的進行，我們慢慢看到了自己的小小成果，覺得付出有了回報，并開始樂在其中。在這期間，徐老師也一直鼓勵我們，他告訴我們，只要堅持做下去，我們會收獲到成功的喜悅的！

現在，我們已基本完成了大作業分析階段，在我和小組成員的協作下，總算按時完成了。在分析階段，我們也遇到了很多問題，比如剛開始畫數據流圖時，visio用的不是很熟練，數據流圖中的數據流、數據存儲、過程、源點和宿點不知

道怎樣連接，層與層之間也不知如何區分，有時候甚至想要放棄。還好有老師的鼓勵與指導加上小組一起努力，我們克服了這一難關。在畫er圖的時候遇到的問題就相對少了一點，因為以前

學習數據庫的時候就畫過er圖了，所以在畫的過程中就相對輕松一點。接下來就是系統的設計了，時間還蠻緊迫的，我們仍需努力。

我作為小組的組長，從中真的學習到不少知識。老師說過，組長應該做的比別人更加多，才能夠勝任。我們現在還沒有達到“喝茶看報紙”的層次，那得等到我們具備了足夠的能力，所以要想達到那個高度，我們現在應該更加努力。負責的整個過程中，我必須把握好進度，如果一步跟不上，可能就會步步跟不上。我們小組成員也很配合，基本不需我太多督促。在對我們所要實現的功能有了個整體的把握的情況下，我們制作出了令自己還算滿意的圖形?，F在我覺得自己基本可以熟練運用visio了，這也算是一大收獲吧！

總的來說，這次這次信息系統分析與設計的課程設計讓我獲益匪淺，以前只是紙上談兵，沒有親自實踐，不知道理論上升到實踐路程的艱辛。通過這次

自己親自選題、實地考察、繪制dfd、er圖到完成分析，我體驗了其中的不容易，也嘗到了其中的甜頭。我們還會繼續努力，更好的完成下面的工作。

0963710205 秦曉雅

《信息系統分析與設計》考試題目及評分標準

下周一中午12點之前由班長或學習委員收齊各班紙質版本作業，周二收齊交給任課老師。

請注意論文封面、格式以及老師強調的論文重點，打印并裝訂好交給班長或學習委員。考試題目：

設計一個銀行存取款管理信息系統。

要求具有下面的功能：①儲戶憑身份證在銀行開戶，銀行賬戶中保存儲戶姓名、聯系電話、家庭住址等基本信息，并保存儲戶每筆存取款業務數據。②儲戶存款時，需提交存折/卡號，由業務員在銀行賬戶及存折/卡上登記存款信息。③儲戶取款時，還需提交密碼，以確認

身份，在驗證取款合法性后，更新銀行賬戶。④統計員每日統計存、取款情況，形成日存取款匯總表，提供給信貸管理部作為信貸主要依據。

設計一個物資采購及庫存管理業務管理信息系統。

要求具有下面的功能：①車間填寫領料單到倉庫領料，庫長根據用料計劃審批領料單，未批準的退回車間。②庫工收到已批準的領料單后，首先查閱庫存賬，若有貨，則通知車間前來領取所需物料，并登記用料流水賬；否則將缺貨通知采購人員。③采購人員根據缺貨通知，查閱訂貨合同單，若已訂貨，則向供貨單位發出催貨請求，否則就臨時申請補充訂貨。④供貨單位發出貨物后，立即向訂貨單位發出提貨通知。采購人員收到提貨通知單后，就可辦理入庫手續。接著是庫工驗收入庫，并通知車間領料。⑤此外，倉庫庫工還要依據庫存賬和用料流水賬定期生成庫存報表，呈送有關部門。

考核內容：

熟練掌握信息系統分析與設計的方法。具體考核的內容是：

1、編寫信息系統可行性報告。

2、編寫信息系統需求分析報告，繪制數據流圖。

3、編寫信息系統設計報告，繪制功能結構層次圖，數據庫設計，界面設計和硬件和軟件設計。

評分標準：

1、編寫信息系統可行性報告。

2、編寫信息系統需求分析報告，繪制數據流圖。

3、編寫信息系統設計報告，繪制功能結構層次圖。

4、數據庫設計

5、界面設計。

6、簡單的硬件和軟件設計。

系統分析與設計方法讀書筆記

《系統分析與設計方法》，顧名思義，是論述軟件開發過程中涉及到的分析與設計過程的方法論。作者依照軟件

開發過程將書劃分為四個部分：系統開發項目環境、系統分析方法、系統設計方法、系統分析和設計完成后的工作。同其他美國作者一樣，作者通過一個貫穿全書的案例--音階公司系統項目，向我們詳細地講解了開發一個軟件系統過程中設計到的知識。

第一部分“系統開發項目環境”介紹信息系統開發的概念和過程。第二部分“系統分析方法”涵蓋了生命周期前期活動、工具和技術，這些內容用于分析業務問題、說明信息系統業務需求以及制定業務和系統方案。第三部分“系統設計方法”涵蓋了生命周期中期活動、工具和技術，特別強調應用架構的概要設計和詳細設計、快速開發和原型設計、外部設計、內部設計以及面向對象設計。第四部分“系統分析和設計完成后的工作”通過縱覽生命周期后期活動，透視系統分析和設計工作。

《系統分析與設計方法》這本書圍繞軟件開發這一中心，詳細講解了從需

求分析到后期維護各個階段中，如何運用文檔與周圍的人員進行有效溝通和協作。文檔，作為各類人員之間的橋梁和紐帶，如使用得當，有以下幾個好處：

1.提高軟件開發過程的能見度。把開發過程中發生的事件以某種可閱讀的形式記錄在文檔中。管理人員可把這些記載下來的材料作為檢查軟件開發進度和開發質量的依據，實現對軟件開發的工程管理。

2.提高開發效率。軟件文檔的編制，使得開發人員對各個階段的工作都進行周密思考、全盤權衡、從而減少返工。并且可在開發早期發現錯誤和不一致性，便于及時加以糾正。

3.作為開發人員在一定階段的工作成果和結束標志。

4.記錄開發過程中的有關信息，便于協調以后的軟件、開發、使用和維護。

5.提供對軟件的運行、維護和培訓的有關信息，便于管理人員、開發人員、操作人員、用戶之間的協作、交流和了

解。使軟件開發活動更科學、更有成效。

6.便于潛在用戶了解軟件的功能、性能等各項指標，為他們選購符合自己需要的軟件提供依據。

也正是基于這樣的好處，軟件行業才會定義、開發各種溝通表達工具和建模語言來統一溝通方法，從而便于各種人員的團結合作。以uml為例。從1989

年到1994年,建模語言數量從不到十種增加到了五十多種。90年代中,又一批新方法出現,其中最引人注目的是booch 1993、oose和omt-2等。但到目前為止，uml這一統一建模語言脫穎而出，它貫穿軟件開發周期中的每一個階段，并被omg采納作為業界的標準。就如書中所講，uml是一個標準的圖形表示法，它不是面向對象的分析和設計，也不是一種方法，它僅僅是一組符號。uml是在開發階段，說明，可視化，構建和書寫一個面向對象軟件密集系統的制品的開放方法。作為一種模型語言，它使開發人員專注于建立產品的模型和結構，而不是選用什么程序語言和算法實現。當模型建立之后，模型可以被uml工具轉化成指定的程序語言代碼。所以說，運用優秀的溝通工具與各種角色進行有效地溝通在一定程度上決定著系統能否保質保量的成功完成。在這個崇尚團結與合作的社會，作為新一代的軟件開發人員，我們更應該認真學習書中說講的各種文檔編寫方法，更好的運用到實際開發中去。

首先，需求分析人員從接觸到深入了解客戶業務有一個漸進的過程，如果一開始就深入到業務的細節中去，不但容易迷失方向，而且很容易顯露出你對業務的無知，客戶會因此而失去與你溝通的興趣。

其次，溝通雙方都有自己習慣的溝通方式。所以在雙方能夠達成默契之前，不要急于深入業務細節，而是圈定范圍，先就一些大框框進行溝通，借此了解客戶的溝通方式。客戶是喜歡開放型問題還是封閉型問題？客戶是很健談還是很

含蓄？客戶是主導型溝通者還是被動型溝通者？客戶是具有很強邏輯思維的人，可以將一個問題有條不穩地講清楚，還是一個發散型思維的人，總是沒有什么目的地想到什么就講什么？如果雙方的溝通方式不能切合 rf4ss，必定會造成溝通的障礙。

再次，客戶的時間是有限的，很多時候不能有整塊的時間來配合需求調研。由于項目的周期也是有限的，因此每一次會面都需要爭分奪秒，用最快的時間把問題搞清楚。另一方面，客戶通常不會為需求調研做好準備，往往是等著回答問題的。如果需求分析人員寄希望于客戶能有條不理的把一套業務都能講解很清楚，整個業務形成閉環往往是很不現實的。這就要求需求分析人員根據經驗提前要做好調研計劃和內容，逐個進行落實。

系統分析與設計的方法主要包括結構化生命周期法、原型化方法、面向對象方法。

按時間過程來分，開發方法分為生命周期法和原型法，實際上還有許多處于中間狀態的方法。原型法又按照對原型結果的處理方式分為試驗原型法和演進原型法。試驗原型法只把原型當成試驗工具，試了以后就拋掉，根據試驗的結論做出新的系統。演進原型法則把試好的結果保留，成為最終系統的一部分。按照系統的分析要素，可以把開發方法分為三類：

①面向處理方法。

②面向數據方法。

③面向對象的方法

系統分析和設計應遵循的原則有：

系統開發是面向客戶的，應從客戶的角度考慮。

諸如系統開發生命周期之類的產品更新換代機構應該在所有的信息系統開發項目中建立起來。

信息系統開發的過程并不是一個順序的過程，它允許步驟的重疊和倒轉等。如果系統的成功可能性受到很大限

制時，應取消整個項目。

文檔材料是系統開發生命周期中重要的可遞交成果，應加以重視

最后總結下，學完《系統分析與設計方法》這門課程再加上老師在課堂上的一些講解以及以前學習過程中的收獲，我對于系統分析與設計有了進一步的理解，能高屋建瓴的看待系統分析與設計整個過程的步驟以及增加了一些開發設計中的重要事件的理論知識。

第五篇：信息系統分析與設計

《信息系統分析與設計》考試題目及評分標準

下周一（11月26日）中午12點之前由班長或學習委員收齊各班紙質版本作業，周二收齊交給任課老師。

請注意論文封面、格式以及老師強調的論文重點，打印并裝訂好交給班長或學習委員。考試題目：（任選其一）

設計一個銀行存取款管理信息系統。

要求具有下面的功能：①儲戶憑身份證在銀行開戶，銀行賬戶中保存儲戶姓名、聯系電話、家庭住址等基本信息，并保存儲戶每筆存取款業務數據。②儲戶存款時，需提交存折/卡號，由業務員在銀行賬戶及存折/卡上登記存款信息。③儲戶取款時，還需提交密碼，以確認身份，在驗證取款合法性后，更新銀行賬戶。④統計員每日統計存、取款情況，形成日存取款匯總表，提供給信貸管理部作為信貸主要依據。

設計一個物資采購及庫存管理業務管理信息系統。

要求具有下面的功能：①車間填寫領料單到倉庫領料，庫長根據用料計劃審批領料單，未批準的退回車間。②庫工收到已批準的領料單后，首先查閱庫存賬，若有貨，則通知車間前來領取所需物料，并登記用料流水賬；否則將缺貨通知采購人員。③采購人員根據缺貨通知，查閱訂貨合同單，若已訂貨，則向供貨單位發出催貨請求，否則就臨時申請補充訂貨。④供貨單位發出貨物后，立即向訂貨單位發出提貨通知。采購人員收到提貨通知單后，就可辦理入庫手續。接著是庫工驗收入庫，并通知車間領料。⑤此外，倉庫庫工還要依據庫存賬和用料流水賬定期生成庫存報表，呈送有關部門。

考核內容：

熟練掌握信息系統分析與設計的方法。具體考核的內容是：

1、編寫信息系統可行性報告。

2、編寫信息系統需求分析報告，繪制數據流圖。

3、編寫信息系統設計報告，繪制功能結構層次圖，數據庫設計，界面設計和硬件和軟件設計。

評分標準：

1、編寫信息系統可行性報告。（20分）

2、編寫信息系統需求分析報告，繪制數據流圖。（30分）

3、編寫信息系統設計報告，繪制功能結構層次圖。（20分）

4、數據庫設計（10分）

5、界面設計。（10分）

6、簡單的硬件和軟件設計。（10分）