信息系統分析與設計(自考)

名詞解釋

1、信息系統:

是指在經濟或社會的組織中,以滿足管理者的信息需求爲目標、以計算機和現代通信技術 等現代信息技術爲手段,既包括設備和技術,又包括人員與機構在內的綜合系統。

2、 CASE

就是一類專門用來幫助人們建設信息系統的軟件,是一類專用的特別爲信息系建設人員服 務的軟件。

3、BSP

方法:即企業系統規劃,是進行組織的信息系統規劃的一套規範方法。 

4、 CSF

方法:即關鍵成功因素法,是進行信息系統規劃的另一種類型的方法。

5、 白盒測試:

也稱爲結構測試。將軟件看成透明的白盒。根據程序的內部結構和邏輯來設計測試用例, 對程序的路徑和過程進行測試,檢查是否滿足設計的需要。 

6、 黑盒測試:

也稱爲功能測試,將軟件看成黑盒子,在完全不考慮軟件的內部結構和特性的情況下,測試軟件的外部特性。根據系統分析說明書設計測試用例,通過輸入和輸出的特性檢測是否滿足指定的功能。 

7、 軟件複用(Reuse)

就是將已有的軟件成分用於構造新的軟件系統。

8、 軟件構件(component)

是可複用的軟件組成成份,可被用來構造其它軟件。

9、 繼承

是對象類間的一種相關關係,指對象繼承它所在類的結構、操作和約束,也指一個類繼承另外一 個類的結構、操作和約束。繼承體現了一種共享機制。 

10、封裝(encapsulation)即信息隱藏。它保證軟件部件具有較好的模塊性,可以說封裝是所有主流信息系統方法學中的共同特徵,它對於提高軟件清晰度和可維護性,以及軟件的分工有重要的意義。 

二、簡答題 

1、使用生命週期法的條件

1.用戶需求定義可以明確;2.系統運行程序確定、結構化程度高;3.系統具有較長的使用壽命,環境變化不大;4.開發過程有嚴格的控制;5.研製人員對系統任務瞭解且熟練程度較高;6.系統文檔要求詳而全;開發成果重複使用。

2、可行性分析的概念及如何進行可行性分析?

1.可行性分析是根據系統的環境、資源等條件,判斷所提出的信息系統項目是否有必要、有可能開始進行,如果要進行,那麼採用什麼建設方案 

2.所謂可行性應該包括必要性和可能性兩個方面。

沒有必要性的項目是不應該進行的。一些單位的信息系統應用項目開展不起來的重要原因之一就是管理人員沒有緊迫感,沒有意識到信息化對組織競爭力的支持。 

3、生命週期各階段的內容:

1.系統規劃階段:其任務是對組織的環境、戰略、目標、現行系統的狀況進行初步調查,根據組織的目標和發展戰略,確定信息系統的發展戰略。

2.系統分析階段:其任務是根據系統設計任務書所確定的範圍,對現行系統進行詳細調查,描述現行系統的業務流程,指出現行系統的侷限和不足之處,確定新系統的基本目標和邏輯功能要求。

3.系統設計階段:其任務是根據系統分析說明書中規定的功能要求,考慮實際條件,具體設計實現邏輯模型的技術方案,即設計新系統的物理模型。

4.系統實施階段:其任務是程序的編寫和調試,人員培訓,數據文件的轉換等。5)系統運行和維護階段:需要經常進行維護和評價,記錄系統運行的情況,然後對系統進行必要的修改,評價系統的工作質量和經濟效益。

 4、可行性研究主要從哪些方面考察?

  建設信息系統的可行性研究應從以下三個方面考慮:技術可行性研究是指根據系統功能、性能及實現系統的各項約束條件,根據現有的技術條件,能否達到所提出的要求;所需要的物理資源是否具備,能否得到。經濟可行性研究:要估計項目的成本和效益,分析項目經濟上是否合理。要解決兩個問題:資金可得性和經濟合理性。社會可行性研究:是指所建立的信息系統能否在該企業實現,在當前操作環境下能否很好地運行,即組織內外是否具備接受和使用新系統的條件。 

5、系統設計的原則

1.系統性原則:統一的信息代碼、統一的數據組織方法、統一的設計規範和標準; 2.經濟性原則

3.可靠性原則:如安全保密性、檢錯及糾錯能力、抗病毒能力、系統恢復能力等。4.簡單性原則;5.靈活性原則:系統容易修改和維護 。

6、原型法的基本思想

     原型法是確定需求策略,是對用戶需求進行抽取、描述和求精。它快速的一迭代的方式建立最終系統工作模型,對問題的定義採用啓發的方式,由用戶作出響應。

7、原型法的工作步驟,在每一步開發者和用戶的責任,分別遵循的原則:

1.快速分析,弄清用戶的基本信息需求:用戶的責任是根據系統的輸出清晰地描述自己的基本需要,設計者和用戶共同負責規定系統的範圍、確定數據的可用性。設計者的基本責任是確定實現的用戶期望,估價開發原形的成本。

2.構造原型,開發初始原型系統:這一步驟用戶沒有責任,應由設計者去負責建立一個初始原型,其中包括與用戶的需求及能力相適應的對話,還包括收集用戶對初始原型的反映的設施。

3.用戶和開發人員使用並評價原型:用戶要在開發者的指導下試用原型,在試用的過程中考覈評價原型的特性,分析其運行結果是否滿足規格說明的要求。本步驟中的原則是:對實際系統的親身經驗能產生對系統的真實理解;用戶總會找到系統第一個版本的問題;讓用戶確定什麼時候更改是必需的,並控制總開發時間;如果用戶在一定時間裏(比如說一個月)沒有和開發者聯繫,那麼用戶可能是對系統表示滿意,也可能是遇到某些麻煩,設計者應該與用戶聯繫。

4.修改和完善原型系統:修改原型以便糾正那些由用戶指出的不需要的或錯誤的, 根據修改意見進行修改。若原型運行的結果未能滿足規格說明中的需求,反映出對規格說明存在着不一致的理解或實現方案不夠合理。 

8、面向數據流的方法與步驟

設計方法:變換分析。

設計步驟

1. 複查基本系統模型

2. 複查並精化數據流圖

3. 確定數據流圖具有變換特性還是事務特性

4. 確定輸入流和輸出流的邊界,從而孤立出變換中心

5. 完成“第一級分解”,把數據流圖映射成系統模塊結構,即設計系統的上層模塊結構

6. 完成“第二級分解”,基於數據流圖逐步分解高層模塊結構,設計出下層模塊

7.使用設計度量和啓發式規則對第一次分割得到的軟件結構進一步精化 

9、信息系統建設的關鍵成功要素:

除了先進的技術環境與設備之外,一個成功的信息系統建設項目必須具備以下五個條件:

1.正確的指導思想和切實可行的目標;2.突破口的正確選擇;3.有效的項目管理和控制機制;4.及時的信息交流渠道和科學的評價機制;5.強有力的組織及資源保證。 

10、原型法與生命週期法的比較

1.開發路徑:原型法的開發路徑是循環、迭代的,要經過用戶的多次檢驗。而生命週期法的開發路徑是嚴格按順序進行,是一次性的,開發具有階段性。

2.用戶參與程度:原型法的開發過程中,用戶的參與程度較高,它的設計糅合了用戶的意見和思想。在生命週期法的開發過程中用戶的參與程度較低,用戶只在需求分析的步驟中參與了系統的開發。

3.早期可測試性:這是由於原型法的簡便、快速的特性所決定的。生命週期法的早期可性較差,幾乎不能測試其整體的效果。

4.對開發環境和工具的要求:原型法對開發環境和根據要求較高,它必須有快速生成工具的支持,才能快速生成原型。而生命週期法對開發環境和工具要求則較低。

5.開發週期和自動化程度:原型法有着支撐軟件和高級的開發工具,開發迅速,週期短,自動化程度較高。而生命週期法的開發週期長,開發的自動化程度也

較低。

6.開發技術管理:原型法的開發具有循環、迭代性,開發的工具也很多樣化,因開發技術管理較困難。生命週期法在開發技術管理中具有優勢,它對需求分析有着嚴格的定義,開發按一個階段一個階段地進行,對開發的技術管理也較容易。7)系統質量:原型法因爲對環境的適應性更好和用戶的參與,因此利用原型法設計的系統整體質量更好。生命週期法的有着嚴格的階段性,文檔資料全面,設計的整體性較好;但是它不能隨着變化了的環境變化,對環境的適應性較差、用戶的參與程度也較低,因此係統質量不是很高。

11、在社會和經濟組織中,信息系統的地位和作用是什麼?

答:以計算機和現代通信技術爲基本手段的、活躍在各種社會經濟組織中的信息系統,已經變得越來越普遍.越來越重要、越來越和人們的日常生活息息相關。。信息系統作用:滿足管理者的信息需求爲目標。 

12、 保證信息系統建設切實取得成效的關鍵因素有哪些?

答:信息系統的建設能否成功取決於多方面因素,既有技術因素,又有經濟社會環境的因素;既有項目組織本身的管理技能等主管因素,又有無法控制的許多外界因素。 

從宏觀的角度看,技術、管理、人員是保證信息系統建設成功的三個主要支撐條件。除了先進的技術環境與設備之外,一個成功的信息系統建設項目必須具備五個條件:正確的指導思想和切實可行的目標;突破口的正確選擇;有效的項目管理和控制機制;及時的信息交流渠道和科學的評價機制;強有力的組織及資源保證。 

13、生命週期法的特點:a建立面向用戶的觀點,根據用戶需求來設計系統。b自頂向下來規劃或設計信息 系統。c嚴格按階段進行。d工作文檔標準化和規範化。e運用系統的分解和綜合技術,使複雜的系統結構化、模塊化。f強調階段成果的審定和檢驗。

 14、生命週期法的優點:a系統易於實現;b有利於系統總體結構的優化;c實現的系統具有較好的可維 護性。 

 15、生命週期法的成功要素有哪些?

答:1 注意文檔管理、變更管理和聘請監理;2 樹立面向用戶的觀點,根據用戶需求設計系統;

       3 自頂向下來規劃或設計信息系統;   4  嚴格按階段進行;  5  建立有效的工作文檔;

      6  運用系統的分解和綜合技術,使 複雜的系統結構化、模塊化;  7  強調階段成果的審定和檢驗。

16、系統調查的原則有:a自上而下全面展開;b全面展開與重點調查相結合;c深入細緻的調查研究。 

17、常用的調查研究的方法:問卷調查法、召開調查會、業務實踐、專家訪談電子問卷、參加業務實踐。 

18、 數據字典的主要作用是對數據流程圖中的數據項、數據結構、數據流、處理邏輯、數據存儲、和外部實體等方面進行具體的定義。建立數據字典的目的是爲了保證全局數據的一致性和準確性。數據字典和數據流程圖共同構成對系統邏輯模型的準確完整描述。 

19、 U/C矩陣主要用來對系統功能劃分進行分析和優化。U表示該功能爲數據的使用者,即某個功能使用某類數據,C表示該功能爲數據的產生者或創建者。

20、邏輯設計的目標在於根據對上述現有業務處理模式侷限性的分析,按照計算機信息處理的特點,拋棄手工處理模式下的組織方式和業務分工,建立合理的新系統邏輯設計方案,確定新系統的處理模式和管理模型,明確新系統開發中努力的方向。 

21 、輯設計的原則:a 管理信息化和現代管理思想的相結合;b 分解和協調相結合;

                                c 模型化結構設計; d  全局一致性原則;e  靜態與動態相結合。 

22、 業務流程是指爲完成一定的目標或任務而進行的一系列時間上承繼的業務活動序列,是企業或組織運行的方式。 

23、 根據流程範圍和重組特徵,可將BPR分爲以下三類:a功能內的BPR;   b功能間的BPR;   c組織間的BPR 

24、 系統分析報告的審議,對以下問題做出評價:a一致性;   b完整性   c現實性    d有效性

25、系統設計階段的任務

     a總體設計:模塊結構設計、系統物理配置方案設計、總體數據庫設計

     b詳細設計:代碼設計、數據庫設計、輸出設計、輸入設計、人機界面設計、處理過程設計、安全保密設計  

26、  模塊聚合是用來衡量一個模塊內部各組成部分間整體統一性指標,它具體描述一個模塊功能專一性的程度。簡單地說,理想聚合的模塊只完成一件事情。根據模塊內部的構成的情況,模塊聚合可以劃分爲七個等級,這七個等級的模塊聚合程度具有由強到弱變化的特點。

27、  模塊的耦合:是衡量一個模塊與其他模塊之間相互作用程度的指標。 

28、 模塊的主要耦合形式:a數據耦合b控制耦合c公共耦合d內容耦合. 

29、 如何理解系統結構設計中模塊的高聚合、低耦合原則? 

答:模塊耦合度越低,說明模塊間的聯繫越少相互間的影響也就越小,產生的連鎖反應的概率就越低,在對一個模塊進行修改和維護時,對其他模塊的影響程度就越小,系統可修改性就越高。在系統中聚合度越大,則模塊間的耦合度越小,但這種關係並不是絕對的,耦合度小使得模塊間儘可能相對獨立,從而各模塊可以單獨開發和維護。聚合度大使得模塊的可理解性和維護性大大增強。因此在模塊的分解中應儘量減少模塊的耦合度,力求增加模塊的聚合度。

30、 何爲模塊化?如何畫出系統模塊結構圖?

答:模塊化,是指把一個系統自頂向下逐步分解爲若干個彼此獨立而又有一定聯繫的組成部分,這些組成部分也稱爲模塊。 

結構圖中,模塊用矩形方框表示,寫有模塊 的名稱,反映這個模塊的功能;

模塊間的調用關係用箭頭表示,鍵尾表示調用模塊,箭頭表示被調用模塊;

調用箭頭線旁邊帶圓圈的小箭頭線,表示從一個模塊傳送到另一個模塊的數據;調用箭頭線旁邊帶圓點的小箭頭,表示從一個模塊傳遞給另一個模塊的控制信息。模塊加上數據流、控制流以及模塊間的調用關係,就組成了系統模塊結構圖。

31、 新舊系統之間的轉換方式有三種,分別是直接轉換、並行轉換和分段轉換。

32、 系統詳細設計階段包含哪些內容? 

主要包括:代碼設計、數據庫設計、模塊的功能與性能設計、人機界面設計、輸入輸出設計等。 

33、 系統測試按硬件系統、網絡系統和軟件系統分別進行測試,最後對整個系統進行總的綜合測試。

34、 硬件測試的主要工作是?

答: 1.配置檢測    2.硬件設備的外觀檢查    3.硬件測試

35、 網絡測試的主要工作是?

答:1.網絡設備的外觀檢查      2.硬件測試        3.網絡連通測試。

36、 軟件測試的主要 工作:單元測試,組裝測試,確認測試,和系統測試。 

37、 軟件測試有哪些方法?各有什麼含義? 

答:單元測試,對源程序中的每一個程序單元進行測試,驗證每個模塊是否滿足系統設計說明書的要求。

        組裝測試,是將已測試過的模塊組合成子系統,重點測試各模塊之間的接口和聯繫。

        確認測試是對整個軟件進行驗收,根據系統說明書來考察軟件是否滿足要求。

        系統測試是將軟件,硬件,網絡等系統的各個部分連接起來,對整個系統進行總的功能、性能等方面的測試。 

38、 原型法是指在獲取一組基本的需求定義後,利用高級軟件工具可視化的開發環境,快速地建立一個目標系統的最初版本,並把它交給用戶試用、補充和修改,再進行新的版本開發。反覆進行這個過程,直到得出系統的“精確解”,即用戶滿意爲止。經過這樣一個反覆補充和修改過程,應用系統 “最初版本”就逐步演變爲系統 “最終版本”。

 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章