第一篇：實驗儀器登記系統分析與設計論文[范文模版]

摘要：當前在各類職業院校中存在著大量的實驗儀器設備，在實驗儀器設備的使用過程中一般都需要進行登記操作，從而能夠記錄和匯總實驗儀器設備的使用情況，但傳統的利用紙質表進行手工登記存在很多問題，這就需要借助于軟件技術開發出一個可以進行在線登記的平臺。筆者首先分析了職業院校實驗儀器設備使用在線登記系統研究的背景及價值，然后對該系統進行了可行性分析和功能需求分析，并對該系統進行了模塊設計和數據庫設計，最后對該系統進行了總結。

關鍵詞：職業院校；實驗儀器設備；在線登記；.NET

1研究背景與價值

隨著計算機技術和網絡技術的發展，在線登記系統已被廣泛應用到國民經濟的各個領域當中，政府機關、企事業單位、銀行、醫院和學校等都在使用各類在線登記系統，如在線預約登記系統、在線招生報名登記系統等，而目前實驗儀器設備的使用登記系統應用得并不是很廣泛，很多單位和部門仍然在使用傳統的方式進行使用登記，會浪費大量的人力、財力和物力，另外，也無法對實驗儀器設備的使用情況進行有效的監控和匯總統計。為了改變實驗儀器設備傳統的效率低下的登記模式和管理方式，可以借助于計算機軟件技術，設計和開發出一套易于操作的有良好的人機交互界面的在線登記系統，對實驗儀器設備的使用進行統一的管理，節約資源和提高效率，提升信息化管理水平。當前，在各類學校和研究所存在著大量的實驗儀器設備，為了對實驗儀器設備的使用進行有效管理，制定了相應的使用制度，并使用登記表來記錄日常的使用情況，但一般還是采用手工方式進行登記，從而導致可能存在以下問題：（1）登記種類繁雜，工作量大，存在重復記載現象；（2）需要大量的登記表進行登記，浪費資源；（3）登記出錯率高，數據的真實性、準確性不足；（4）查詢調閱不方便，監督檢查難度大；（5）紙質登記表難以保證長期保管；（6）對實驗儀器設備的使用情況難以進行統計和匯總。為了解決以上問題，可以借助于計算機軟件技術，設計和開發出一套在線登記系統，對實驗儀器設備的使用進行統一的管理，節約資源和提高效率。實驗儀器設備使用登記系統，具有以下作用：（1）實現無紙化登記，節約辦公資源；（2）節約教師和學生的登記時間，提高效率；（3）幫助提醒教師和學生進行使用登記；（4）對實驗儀器設備的使用情況進行實時的監控；（5）對實驗儀器設備的使用情況進行匯總統計；（6）了解實驗儀器設備的日常使用情況，提高設備的使用率。

2系統可行性分析與需求分析

2.1技術可行性分析本軟件系統采用B/S結構，以ASP.NET為開發平臺、SQLServer2005為后臺數據庫進行軟件系統的設計與開發。ASP.NET是當前主流的一項開發技術，有強大技術支持作后盾，在安全性、易維護性、靈活性方面都能夠得到保證。SQLServer是基于服務器端的中大型企業級數據庫，適合大容量數據的應用，在功能、管理方面也要比其他小型數據庫強得多，處理海量數據的效率、后臺開發的靈活性、可擴展性等方面也十分強大。本系統所采用的技術是比較流行的成熟的軟件技術，在技術上是完全可行的。2.2功能需求分析在本系統中主要有三類角色，分別為實驗室管理員、教師和學生，不同的角色具有不同的權限。其中實驗室管理員可以利用本系統實現對部門、設備的管理，主要包括數據的添加、修改和刪除等；管理教師和學生的基本信息，主要包括用戶數據的導入和密碼重置等；查看機器故障情況；統計實驗儀器設備的使用登記情況，可以按時間或者實驗室進行統計。教師可以利用本系統進行實驗儀器設備的在線登記操作，并查看當前學生的在線登記情況；查看學生的歷史登記記錄，可以按學生、按班級或按時間進行查看以及修改登錄密碼等。學生可以利用本系統進行實驗儀器設備的在線登記操作；查看本人歷史登記記錄以及修改登錄密碼等。

3系統設計

3.1模塊設計

為了充分保證該系統的可維護性和可重用性，根據模塊設計的原則，本系統主要分為以下幾個模塊。（1）人員管理模塊：主要實現對學生和教師基本信息的操作，如學生賬號的分配、密碼的設置等。（2）實驗儀器設備管理模塊：主要實現實驗儀器設備的管理操作，如設備的添加、修改、刪除等。（3）登記管理模塊：主要實現學生和教師的登記操作，教師和學生按照登記要求進行規范登記操作，并能夠查詢登記記錄。（4）匯總統計模塊：主要實現對實驗儀器設備的使用情況進行匯總和統計操作，如可以統計設備一段時期內的使用狀況。

3.2數據庫設計

一個優秀的數據庫能夠幫助程序員減少業務邏輯操作，降低出錯的可能性；而一個糟糕的數據庫會在需要添加功能時無從擴展，或是大量的冗余造成性能的瓶頸。因此，建立一個優秀的數據庫，設計好每一張表格尤為重要。根據數據庫設計的基本原則，即原子性、原始性、演繹性、穩定性，本系統主要設計8張表格，分別為：部門表、實驗室表、班級表、教師表、學生表、教師登記表、學生登記表和用戶登錄表。表中所包含的主要字段如下。（1）部門表：部門編號、部門名稱。（2）實驗室表：實驗室編號、實驗室名稱、設備數量、所屬部門、負責人。（3）班級表：班級名稱、班級人數、所屬部門。（4）教師表：教師工號、教師姓名、所屬部門。（5）學生表：學號、姓名、班級。（6）教師登記表：序號、周次、日期、使用節次、星期、實驗項目、班級名稱、機器狀況、實驗室、教師工號、備注。（7）學生登記表：序號、周次、日期、使用節次、星期、機器號、機器狀況、實驗室、學號、備注。（8）用戶登錄表：序號、用戶名、登錄密碼、用戶類型。表之間的數據關系如圖1所示。

4結語

本系統主要是針對于江蘇省南京工程高等職業學校的實驗儀器設備使用登記的實際情況和存在的問題，為了解決當前紙質登記中存在的各類問題，借助于軟件技術研究開發出來的，大大提高了實驗儀器設備登記管理的便利性和效率，進一步推進校園信息化和無紙化辦公，加快數字化校園的建設。

參考文獻

[1]李瓊.電子登記簿在線登記監測系統的設計與實現[J].中國金融電腦,2010(12).[2]崔鳴.實驗登記系統的設計與實現[J].蘇州市職業大學學報,2014(3).[3]張瑞,萬建成.基于.NET技術的企業國有資產產權登記系統的設計與實現[J].計算機應用與軟件,2007(2).[4]張瑩.事業單位登記在線管理系統設計與實現[D].濟南:山東大學,2008.[5]胡亞磊.基于“一張圖”模式下的土地登記系統的設計與實現[D].贛州:江西理工大學,2012.

第二篇：系統分析與設計實驗指導書

系統分析與設計實驗指導書

前言

信息系統分析與設計是一門研究管理信息系統開發與維護的普遍原理和技術的工程學科。隨著信息系統概念及應用的發展，成功的經驗與失敗的教訓使人們認識到：信息系統建設過程是復雜的社會過程，系統觀點是系統建設的重要思想武器，科學的開發過程和規范的項目管理要比開發技術本身更為重要，嚴格遵循系統分析與設計的方法論可以大大提高信息系統開發的成功率，顯著減少系統開發和維護中的問題。

按該課程的特點，實驗內容包括軟件開發的兩大方法學的專題訓練，即結構化（生命周期學）的方法學和面向對象的方法學，通過對一個具體的信息系統項目，要求學生利用結構化軟件開發技術或面向對象的軟件開發技術完成對該項目的開發。因此設置四個實驗項目，從項目開發的準備工作，系統分析過程，系統設計過程，到文檔的整理和完善，覆蓋軟件開發的主要過程，此外又引入我國國家《計算機開發規范》，以規范技術文檔的書寫標準，提高實驗教學質量。

通過實驗訓練，達到如下目的：

使學生進一步了解和掌握系統分析與設計原理，提高對實際項目的分析和設計能力，通過實驗課程，熟悉和基本掌握軟件開發方法學、軟件開發的過程，文檔資料的編寫格式及規范，全面領會和貫通所學習的理論知識，從而培養學生綜合運用所學課程知識，分析解決問題的能力，培養學生理論聯系實際作風，實事求是，嚴肅認真的科學態度和良好的工作作風，為今后從事科學研究工作打下基礎。

目

錄

實驗一：項目開發的準備工作--------------------1 實驗二：系統分析過程----------------------------1 實驗三：系統設計過程----------------------------2 實驗四：系統文檔整理----------------------------3

附錄一：--------------5 附錄二：--------------6 附錄三：--------------11

實驗一：項目開發的準備工作

實驗學時：2

實驗類型：驗證性

一、目的與任務

目的：確定課題，組織組員，合理分工，熟悉軟件開發環境，培養團隊精神。

任務：學習軟件開發小組的組織和管理，合理分工，將項目開發各階段的任務明確，并熟悉相應的軟件開發環境。

二、內容、要求與安排方式

1、實驗內容與要求：

根據各組選擇的課題，實行項目經理制，各組推薦一名組長，統一管理整個項目的實施過程，并和理調整資源和負責項目全局；根據項目的難易合理分配組員的任務，對問題達成一直的看法；針對項目的實施，熟悉相應的軟件開發工具的使用環境。

2、實驗安排方式：

本實驗為開放實驗，各組可同時進行實驗，每組2—3人。3．準備參考資料和閱讀相關的國家有關軟件開發的標準文檔。

三、思考題

1． 2． 3． 項目開發首先要做的事是什么？

你認為該軟件應具備的最重要的特性是什么。你認為怎樣分工是最合理的？

實驗二：系統分析過程

實驗學時：4

實驗類型：驗證性

一、目的與任務

目的：確定項目的可實施性，在此基礎上完成系統的邏輯功能模型的建立。任務：采用不同的軟件開發技術，完成對項目的分析過程，給出系統的邏 1 輯功能模型，數據字典以及規格說明書。

二、內容、要求與安排方式

1、實驗內容與要求：（1）結構化分析

明白項目的業務流程圖，繪制數據流程圖，編寫數據字典，數據加工處理的描述，實體關系圖（ER圖），需求規格說明書。

（2）面向對象分析

弄清信息系統的業務流程，繪制系統的用例圖，書寫用例規格說明；初步繪制系統的靜態結構——類圖；初步繪制系統動態行為——順序圖、協作圖、活動圖、狀態圖。最后利用Word寫出系統的需求規格說明書。

2、實驗安排方式：

本實驗為開放實驗，各組可同時進行實驗，每組2—3人。

三、思考題

1． 2． 3． 4． 需求分析在軟件開發中真的有那么重要嗎？

分析系統流程圖，流程圖和數據流圖的區別和各自的特點。怎樣寫合乎規范的數據流圖和數據詞典？ 怎樣組織對該工作的評審？

實驗三：系統設計過程

實驗學時：4

實驗類型：技能性

一、目的與任務

目的：在實驗二基礎上完成系統的體系結構的建立和系統詳細設計，并給出相應的規格說明書。

任務：認真分析實驗二的結果，給出系統合理的體系結構，描繪系統結構圖，并合理劃分系統的各組成模塊，最后給出系統的各部分設計規格說明書。

二、內容、要求與安排方式

1、實驗內容與要求：（1）結構化設計

軟件體系結構圖（HIPO圖或模塊結構圖）設計，模塊處理流程設計，輸出設計（主要指打印輸出設計），存儲文件格式設計（數據庫結構設計），輸入設計（主要指數據錄入卡設計），代碼設計，系統設計說明書

（2）面向對象設計

設計系統合理的體系結構；在Rational Rose環境中對實驗二的分析模型進行細化、精化，使之成為計算機能夠實現的物理模型。最后利用Word寫出系統的設計規格說明書。

2、實驗安排方式：

本實驗為開放實驗，各組可同時進行實驗，每組2—3人。

三、思考題

1．系統設計和需求分析的關系是什么？兩者必須先后關聯嗎？ 2．怎樣描繪系統的體系結構？ 3．怎樣繪制復合規范的流程圖。4．怎樣組織對設計階段工作的評審？

實驗四：系統文檔整理

實驗學時：2

實驗類型：驗證性

一、目的與任務

目的：系統運行和軟件后期制作。

任務：總結軟件開發中的得失，正確書寫軟件說明書和用戶手冊。

二、內容、要求與安排方式

1、實驗內容與要求：

完善系統所涉及的程序框圖，源程序，模擬運行數據，打印報表，軟件使用說明書和用戶手冊等。

2、驗安排方式：

本實驗為開放實驗，各組可同時進行實驗，每組2—3人。

三、思考題

1.怎樣合理選擇軟件開發的工具？

2．怎樣進行用戶說明手冊和使用手冊的編寫。3．總結項目實施中的得失。

附錄一：

實驗要求

軟件工程實驗要求學生采用“項目小組”的形式，結合具體的開發項目進行設計。具體要求如下：

1． 班級按項目小組進行分組，每組不得超過4人

2． 每個項目小組選出項目負責人或項目經理，由項目經理召集項目組成員討論、選定開發項目

3．項目開的每項任務要落實到人且規定該任務的起止日期和時間 4．每個項目小組可以參照附錄中給定的文檔規范標準提供項目文檔 5．題目自定或采用附錄二中的題目

6．軟件開發的方法學自定（結構化或面向對象的方法學）

附錄一：實驗題目

題目一：“教務管理系統之子系統——學院課程安排”

1． 系統簡介

每個學期的期中，學校教務處向各個學院發出下各學期的教學計劃，包括課程名稱、課程代碼、課時、班級類別（本科、專科、成人教育、研究生）、班號等；學院教學主管人員根據教學任務和要求給出各個課程的相關限制（如：任課教師的職稱、上課的班數、最高和最低周學時數等）；任課教師自報本人授課計劃，經所在教研室協調任可，將教學計劃上交學院主管教學計劃的人員，批準后上報學校教務處，最終由教務處給出下個學期全學院教師的教學任務書。

假設上述排課過程全部由人工操作，現要求為上述過程實現計算機自動處理過程。2． 限定條件

（1）每位教師的主講課程門數不超過2門/學期：講師以下職稱的教師不能承擔學院定主課的主講任務。

（2）學院中層干部的主講課時不能超過4學時/周。

（3）本學期出現嚴重教學事故的教師不能承擔下各學期的主講任務。

（4）本系統的輸入項至少包括：教務處布置的教學計劃，學院教師自報的授課計劃和學院定的有關授課限制條件。

（5）本系統的輸出項至少包括：教務處最終下達全院教師的教學任務書和學院各個班級下各學期的課程表（可以不含上課地點）。

題目二：“學校教材定購系統”

1． 系統簡介

本系統可以細化為兩個子系統：銷售系統和采購系統。

銷售系統的主要工作過程為：首先由教師或學生提交購書單，經教材發行人員審核是有效購書單后，開發票、登記并返給教師或學生領書單，教師或學生可以到書庫領書。

采購系統的主要工作過程為：若是教材脫銷，則登記缺書，發缺書單給書庫采購人員；一旦新書入庫后，即發進書通知給教材發行人員。

以上功能要求在計算機上實現。2． 技術要求和限制條件

（1）當書庫中的各種書籍數量發生變化（包括進書和出書）時，都應修改相關的書庫記錄，如庫存表或進/出庫表。

（2）在實現上述銷售和采購的工作過程時，需考慮有關的合法性驗證。

6（3）系統的外部項至少包括：教師、學生和教材工作人員。

（4）系統的相關數據存儲至少包括：購書表、庫存表、缺書登記表、待購教材表、進庫表和出庫表。

題目三：“機票預定系統”

1． 系統簡介

航空公司為給旅客乘機提供方便，需要開發一個機票預定系統。各個旅行社把預定機票的旅客信息（姓名、性別、工作單位、身份證號碼（護照號碼）、旅行時間、旅行始發地和目的地，航班艙位要求等）輸入到系統中，系統為旅客安排航班。當旅客交付了預訂金后，系統打印出取票通知和帳單給旅客，旅客在飛機起飛前一天憑取票通知和帳單交款取票，系統核對無誤即打印出機票給旅客。此外航空公司為隨時掌握各個航班飛機的乘載情況，需要定期進行查詢統計，以便適當調整。2． 技術要求和限制條件

（1）在分析系統功能時要考慮有關證件的合法性驗證（如身份證、取票通知和交款發票）等。

（2）對于本系統還應補充以下功能：

? 旅客延誤了取票時間的處理 ? 航班取消后的處理 ? 旅客臨時更改航班的處理

（3）系統的外部輸入項至少包括：旅客、旅行社和航空公司。

題目四：“實驗室設備管理系統”

1． 系統簡介

每學年要對實驗室設備使用情況進行統計、更新。其中：（1）對于已徹底損壞的做報廢處理，同時詳細記錄有關信息。

（2）對于由嚴重問題（故障）的要及時修理，并記錄修理日期、設備名、編號、修理廠家、修理費用、責任人等。

（3）對于急需修改但又缺少的設備，需以“申請表”的形式送交上級領導請求批準購買。新設備購入后要立即進行設備登記（包括類別、設備名、編號、型號、規格、單價、數量、購置日期、生產廠家、保質期和經辦人等信息），同時更新申請表的內容。

（4）隨時對現有設備及其修理、報廢情況進行統計、查詢，要求能夠按類別和時間段等查詢。

2． 技術要求及限制條件

7（1）所有工作由專門人員負責完成，其他人不得任意使用。

（2）每件設備在做入庫登記時均由系統按類別加自動順序號編號，形成設備號；設備報廢時要及時修改相應的設備記錄，且有領導認可。

（3）本系統的數據存儲至少包括：設備記錄、修理記錄、報廢記錄、申請購買記錄。（4）本系統的輸入項至少包括：新設備信息、修理信息、申請購買信息、具體查詢統計要求。

本系統的輸出項至少包括：設備購買申請表、修理/報廢設備資金統計表。

題目五：人事管理系統的設計系統簡介和設計要求：（1）信息要求

本系統應該包含與人事管理相關的信息，如部門信息、職員信息，其中職員信息應該包含職員的基本信息（如職員的編號、姓名、性別等）職員的其他信息如（如：主要社會關系、獎懲情況等）。（2）功能要求

本系統的基本功能要求如下： ? 部門信息維護；

? 職員信息維護（含職員的部門調整）； ? 職員信息查詢（不確定查詢）； ? 人事信息查詢(如人才結構的統計查詢)? 用戶管理（含用戶權限的設置）

? 輔助功能（如學歷索引表、職稱索引表的維護等）

題目六：工資管理系統的設計

系統簡介和設計要求：（1）信息要求

本系統應該包含與工資管理相關的信息，如部門信息、職員工資信息，其中職員工資信息應該包含與支援工資相關的基本信息（如：職員的編號、姓名、基本工資、各種津貼以及其他應發工資項目，水電、煤氣等各項扣款，以及公積金、會費等）、職員的其他信息（如工資調整情況）等。

（2）功能要求

本系統的基本功能要求如下： ? 部門信息維護；

? 職員工資信息維護； ? 顯示打印職員工資表； ? 打印職員工資發放表； ? 打印部門工資匯總表；

? 用戶管理（含用戶權限的設置）。

題目七：畢業生管理信息系統

設計要求：（1）信息要求

本系統應該包含與畢業生管理相關的信息，如畢業生基本信息、畢業生就業信息、其中畢業生基本信息應該包括：畢業生的編號、姓名、性別、民族、籍貫、畢業時間、專業、政治面貌等信息；畢業生就業信息應該包括：畢業生的編號、就業時間、工作單位、工作性質、職務、地址等。

（2）功能要求

本系統的基本功能要求如下： ? 畢業生基本信息維護； ? 畢業生就業信息維護；

? 畢業生就業情況查詢（不確定查詢）； ? 按專業劃分的就業情況統計； ? 用戶管理（含用戶權限的設置）。

題目八：建立一個分布式、互動式的遠程教學平臺

為教師教學、學生學習提供比較完整的教學解決方案。其主要功能包括通知發布、參考資料發布、電子課件發布、學生作業提交、幫助教師批改學生作業、幫助學生復查批改后的作業。

題目九：開發一個基于WEB的網上機票查詢和銷售系統

該系統可以錄入航班和機票信息，用戶可以查詢航班時刻表、查詢機票可用信息和機票折扣信息，用戶可以通過WEB訂票。

題目十：開發一個基于WEB的網上投稿系統

該系統可以接受作者的電子投稿，以及作者信息（如姓名、單位、通信地址、電話、E-Mail等）注冊，并能供投稿人查詢稿件處理情況，以及在稿件處理后（退稿、錄用、修改后再審等），能自動發送E-Mail通知投稿人。

題目十一：開發一個基于Web的BBS系統

包含一般BBS所具有的功能，如用戶注冊、用戶信息管理、發貼功能、貼子管理、主題詞查詢、用戶信息修改和查詢等。

題目十二：開發一個基于Web的網上書店

該系統可以分類錄入書籍和相關信息（如名稱、頁數、出版商、摘要、目錄等），用戶可以注冊、登錄，注冊用戶享受打折服務，所有用戶都可以查詢、瀏覽書籍。注冊用戶可以定購書籍并查詢訂單。

附錄三：

軟件開發文檔指南 可行性研究報告

可行性研究報告的編寫目的是：說明該軟件開發項目的實現在技術、經濟和社會條件方面的可行性；評述為了合理地達到開發目標而可能先擇的各種方案；說明論證所選定的方案。可行性研究報告的編寫內容要求如下：

1.1 引言

1.1.1 編寫目的 1.1.2 背景

1.1.3 定義

1.1.4 參考資料

1.2 可行性研究的前提

1.2.1 要求

1.2.2 目標

1.2.3 條件、假定和限制

1.2.4 進行可行性研究的方法

1.2.5 評價尺度

1.3 對現有系統的分析

1.3.1 數據流程和處理流程

1.3.2 工作負荷

1.3.3 費用開支

1.3.4 人員

1.3.5 設備

1.3.6 局限性

1.4 所建議的系統

1.4.1 對所建議系統的說明

1.4.2 數據流程各處理流程

1.4.3 改進之處

1.4.4 影響

1.4.4.1 對象設備的影響

1.4.4.2 對軟件的影響

1.4.4.3 對用戶單位機構的影響

1.4.4.4 對系統動行的影響

1.4.4.5 對開發的影響

1.4.4.6 對地點和設施的影響

1.4.4.7 對經費開支的影響

1.4.5 局限性

1.4.6 技術條件方面的可行性

1.5 可選擇其他系統方案

1.5.1 可選擇的系統方案1

1.5.2 可選擇的系統方案2

……

1.6 投資及收益分析

1.6.1 支出

1.6.1.1 基本建設投資

1.6.1.2 其他一次性支出

1.6.1.3 非一次性支出

1.6.2 收益

1.6.2.1 一次性收益

1.6.2.2 非一次性收益

1.6.2.3 不可定量的收益

1.6.3 收益/投資比

1.6.4 投資回收周期

1.6.5 敏感性分析

1.7 社會條件方面的可行性

1.7.1 法律方面的可行性

1.7.2 使用方面的可行性

1.8 結論 2 項目開發計劃

編制項目開發計劃的目的是用文件的形式，把對于在開發過程中各項工作的負責人員、開發進度所需經費預算、所需軟、硬件條件等問題作出安排記載下來，以便根據本計劃開展和檢查本項目的開發工作。編制內容要求如下：

2.1 引言

2.1.1 編寫目的 2.1.2 背景

2.1.3 定義

2.1.4 參考資料

2.2 項目概述

2.2.1 工作內容

2.2.2 主要參加人員

2.2.3 產品及成果

2.2.3.1 程序

2.2.3.2 文件

2.2.3.3 服務

2.2.3.4 非移交產品

2.2.4 驗收標準

2.2.5 完成項目的最遲期限

2.2.6 本計劃的審查者與批準者

2.3 實施總計劃

2.3.1 工作任務的分解

2.3.2 接口人員

2.3.3 進度

2.3.4 預算

2.3.5 關鍵問題

2.4 支持條件

2.4.1 計算機系統支持

2.4.2 需要用戶承擔的工作

2.4.3 需由外單位提供的條件

2.5 專題計劃要點 3 軟件需求說明書

軟件需求說明書的編制是為了使用戶的軟件開發者雙方對該軟件的起初規定有一個共同的理解，使之成為整個開發工作的基礎。編制軟件需求說明書的內容要求如下：

3.1 引言

3.1.1 編寫的目的 3.1.2 背景

3.1.3 定義

3.1.1 參考資料

3.2 任務概述

3.2.1 目標

3.2.2 用戶的點

3.2.3 假定與約束

3.3 需求規定

3.3.1 對功能的規定

3.3.2 對性能的規定

3.3.2.1 精度

3.3.2.2 時間特性要求

3.3.2.3 靈活性

3.3.3 輸入輸出要求

3.3.4 數據管理能力的要求

3.3.5 故障處理要求

3.3.6 其它的專門的要求

3.4 運行環境規定

3.4.1 設備

3.4.2 支持軟件

3.4.3 接口

3.4.4 控制 4 數據需求說明書

數據要求說明書的編制目的是為了向整個開發時期提供關于處理數據的描述和數據采集要求的技術信息。編制數據要求說明書的內容要求如下：

4.1 引言

4.1.1 編寫目的 4.1.2 背景

4.1.3 定義

4.1.4 參考資料

4.2 數據的邏輯描述

4.2.1 靜態數據

4.2.2 動態輸入數據

4.2.3 動態輸出數據

4.2.4 內部生成數據

4.2.5 數據約定

4.3 數據的采集

4.3.1 要求和范圍

4.3.2 輸入的承擔者

4.3.3 處理

4.3.4 影響 5 概要設計說明書

概要設計說明書可稱作系統設計說明書，這里說的系統是指程序系統，編制的目的是說 15 明對程序的系統的設計考慮，包括程序系統的基本處理流程、程序系統的組織結構、模塊劃分、功能分配、接口設計、運行設計、數據結構設計和出錯處理設計等，為程序的詳細設計提供基礎。編制概要設計說明書的內容要求如下：

5.1 引言

5.1.1 編寫目的 5.1.2 背景

5.1.3 定義

5.1.4 參考資料

5.2 總體設計

5.2.1 需求規定

5.2.2 運行環境

5.2.3 基本設計概念和處理流程

5.2.4 結構

5.2.5 功能需求與程序的關系

5.2.6 人工處理過程

5.2.7 尚未解決的問題

5.3 接口設計

5.3.1 用戶接口

5.3.2 內部接口

5.3.3 外部接口

5.4 運行設計

5.4.1 運行模塊組合 5.4.2 運行控制

5.4.3 運行時間

5.5 系統數據結構設計

5.5.1 邏輯結構設計要點

5.5.2 物理結構設計要點

5.5.3 數據結構與程序的關系

5.6 系統出錯處理設計

5.6.1 出錯信息

5.6.2 補救措施

5.6.3 系統維護設計 6 詳細設計說明書

詳細說明書可稱作程序設計說明書。編制目的是說明一個軟件系統各個層次中的每一個程序（每個模塊或子程序）的設計考慮，如果一個軟件系統比較簡單，層次很少，本文件可以不單獨編寫，有關內容合并概要設計說明書。對詳細設計說明書的內容要不得要求如下：

6.1 引言

6.1.1 編寫目的 6.1.2 背景

6.1.3 定義

6.1.4 參考資料

6.2 程序系統的組織結構

6.3 程序1（標識符）設計說明

6.3.1 程序描述

6.3.2 功能

6.3.3 性能

6.3.4 輸入項

6.3.5 輸出項

6.3.6 算法

6.3.7 流程邏輯

6.3.8 接口

6.3.9 存儲分配

6.3.10 注釋設計

6.3.11 限制條件

6.3.12 測試計劃

6.3.13 尚未解決的問題

6.4 程序2（標識符）設計說明

…… 數據庫設計說明書

數據庫設計說明書的編制目的是對于設計中的數據庫所有標識、邏輯結構和理結構作出具體的設計規定。其內容要求如下：

7.1 引言

7.1.1 編寫目的 7.1.2 背景

7.1.3 定義

7.1.4 參考資料

7.2 外部設計

7.2.1 標識符和狀態

7.2.2 使用它的程序

7.2.3 約定

7.2.4 專門指導

7.2.5 支持軟件

7.3 結構設計

7.3.1 概念結構設計

7.3.2 邏輯結構設計

7.3.3 理結構設計

7.4 運用設計

7.4.1 數據字典設計

7.4.2 安全保密設計 8 用戶手冊

用戶手冊的編制是要使用非專門術語的語言，充分地描述該軟件系統工程所具有的功能及基本的使用方法。使用戶（或潛在用戶）通過本手冊能夠了解該軟件的用途，并且能夠確定在什么情況下，如何使用它。具體的內容要求如下：

8.1 引言

8.1.1 編寫目的 8.1.2 背景

8.1.3 定義

8.1.4 參考資料

8.2 用途

8.2.1 功能

8.2.2 性能

8.2.2.1 精度

8.2.2.2 時間特性

8.2.2.3 靈活性

8.2.3 安全保密

8.3 運行環境

8.3.1 硬設備

8.3.2 支持軟件

8.3.3 數據結構

8.4 使用過程

8.4.1 安裝與初始化

8.4.2 輸入

8.4.2.1 輸入數據的現實背景

8.4.2.2 輸入格式

8.4.2.3 輸入舉例

8.4.3 輸出

8.4.3.1 輸出數據的現實背景

8.4.3.2 輸出格式

8.4.3.3 輸出舉例

8.4.4 文卷查詢

8.4.5 出錯處理與恢復

8.4.6 終端操作

操作手冊

操作手冊的編制是為了向操作人中提供該軟件每一個運行的具體過程和有關知識，包括操作方法的細節。具體的內容要求如下：

9.1 引言

9.1.1 編寫目的 9.1.2 背景

9.1.3 定義

9.1.2 參考資料

9.2 軟件概述

9.2.1 軟件的結構

9.2.2 程序表

9.2.3 文卷表

9.3 安裝與初始化

9.4 運行說明

9.4.1 運行表

9.4.2 運行步驟

9.4.3 運行1（標識符）說明

9.4.3.1 運行控制

9.4.3.2 操作信息

9.4.3.3 輸入-輸出文卷

9.4.3.4 輸出文段

9.4.3.5 輸出文段的復制

9.4.3.6 啟動恢復過程

9.4.4 運行2（標識符）說明

9.5 非常規過程

9.6 遠程操作 10 模塊開發卷宗

模塊開發卷宗是在模塊開發過程中逐步編寫出來的，每完成一個模塊或一級密切相關的 20 模塊的復審時編寫一份，應該把所有的模塊開發卷宗匯集在一起。編寫的目的是記錄和匯總低層次開發的進度和結果，以便于對整個模塊開發工作的管理和復審，并為將來的維護提供非常有用的技術信息。具體的內容要求如下：

10.1 標題

10.2 模塊開發情況表

10.3 功能說明

10.4 設計說明

10.5 源代碼清單

10.6 測試說明

10.7 復審的結論 11 測試計劃

11.1 引言

11.1.1 編寫目的 11.1.2 背景

11.1.3 定義

11.1.4 參考資料

11.2 計劃

11.2.1 軟件說明

11.2.2 測試內容

11.2.3 測試1（標識符）

11.2.3.1 進度安排

11.2.3.2 條件

11.2.3.3 測試資料

11.2.3.4 測試培訓

11.2.4 測試2（標識符）

……

11.3 測試設計說明

11.3.1 測試1（標識符）21

11.3.1.1 控制

11.3.1.2 輸入

11.3.1.3 輸出

11.3.1.4 過程

11.3.2 測試2（標識符）

……

11.4 評價準則

11.4.1 范圍

11.4.2 數據整理

11.4.3 尺度 12 測試分析報告

測試分析報告的編寫是為了把組裝測試和確認測試的結果、發現及分析寫成文件加發記載，具體的編寫內容要求如下：

12.1 引言

12.1.1 編寫目的 12.1.2 背景

12.1.3 定義

12.1.4 參考資料

12.2 測度概要

12.3 測試結果及發現

12.3.1 測試1（標識符）

12.3.2 測試2（標識符）

……

12.4 對軟件功能的結論

12.4.1 功能1（標識符）

12.4.1.1 能力

12.4.1.2 限制

12.4.2 功能2（標識符）

……

12.5 分析摘要

12.5.1 能力

12.5.2 缺陷和限制

12.5.3 建議

12.5.4 評價

12.6 測試資源消耗 13 開發進度月報

開發進度月報的編制目的是及時向有關管理部門匯報項目開發的進展和情況，以便函及時發現或處理開發過程中出現的問題。一般地，開發進度月報是以項目組為單位每月編寫的。如果被開發的軟件系統規模比較大，整個工程項目被劃分給若干個分項目組承擔，開發進度月報將以項目組為單位按月編寫。具體的內容要求如下：

13.1 標題

13.2 工程進度與狀態

13.2.1 進度

13.2.2 狀態

13.3 資源耗用與狀態

13.3.1 資源耗用

13.3.1.1 工時

13.3.1.2 機時

13.3.2 狀態

13.4 經費支出與狀態

13.4.1 經費支出

13.4.1.1 支持性費用

13.4.1.2 設備購置費

13.4.2 狀態

13.5 下個月的工作計劃

13.6 建議

14 項目開發總結報告

項目開發總結報告的編制是為了總結本項目開發工作的經驗，說明實際取得的開發結果以及對整個開發工作的各個方面的評價。具體的內容要求如下：

14.1 引言

14.1.1 編寫目的 14.1.2 背景

14.1.3 定義

14.1.4 參考資料

14.2 實際開發結果

14.2.1 產品

14.2.2 主要功能和性能

14.2.3 基本流程

14.2.4 進度

14.2.5 費用

14.3 開發工作評價

14.3.1 對生產效率的評價

14.3.2 對產品質量的評價

14.3.3 對技術方法的評價

14.3.4 出錯原因的分析

第三篇：系統分析論文

一、系統的概念級特征

1.系統，所謂系統,就是由相互作用和相互聯系的若干組成部分結合而成的整體。

2．系統的特征：1)整體性。整體性就是要用系統的方法研究系統的對象,立足整體,統籌全局,全面規劃,協調處理,使系統的總體與部分之間、部分之間、系統與環境之間達到辯證統一,組成的整體功能,即系統功能,是各部分所不具備的。系統的功能大于各部分功能的和。2)綜合性。綜合性即從系統的總目標出發,將相關的經驗和知識有機結合,協調運用,從而開發出全新的系統概念,創造出全新的系統結構和功能。綜合創造,集成創新,獲得綜合效益。3)科學性。科學性要求分析問題時按規律辦事,即處理問題時,要有嚴格的工作步驟和程序,定性與定量相結合,還要認識到整體與部分的協調與統一。整體是更大系統的部分,又是本系統的整體。整體具有一定結構、層次和功能,組成整體部分相互聯系、相互作用。4)創新性。創新性要求人們在運用科學技術的同時,充分發揮人的創新能力,大膽地進行系統的開發,實現系統的最優效果,要超前預測,持續創新。

二、系統分析的概念及特征

1.系統分析的概念: 將所得到的文檔資料集中到一起,對組織內部整體管理狀況和信息處理過程進行分析。系統分析所確定的內容是今后系統設計、系統實現的基礎。

2．系統分析的特征：

系統分析從系統需求入手，從用戶觀點出發建立系統用戶模型。用戶模型從概念上全方位表達系統需求及系統與用戶的相互關系。系統分析在用戶模型的基礎上，建立適應性強的獨立于系統實現環境的邏輯結構。系統分析是咨詢研究的最基本的方法，我們可以把一個復雜的咨詢項目看成為系統工程，通過系統目標分析、系統要素分析、系統環境分析、系統資源分析和系統管理分析，可以準確地診斷問題，深刻地揭示問題起因，有效地提出解決方案和滿足客戶的需求。

三、系統分析的產生及發展

20世紀60年代以來,許多學者對系統工程解決問題、處理問題的方法進行了大量研究,雖然目前還找不到能處理所有問題的標準方法, 但是,Hall在1969年提出的系統工程的三維結構是影響較大而且比較完善的方法, Hall認為:現實問題都可以歸結為工程問題,從而可以應用定量分析方法求得最優的系統方案。Hall方法論適應了60年代系統工程的應用需要。當時系統工程主要用來尋求各種戰術問題的最優策略,或者用來組織管理大型工程建設項目。

從70年代中期開始,Checkland經過大量系統實踐,提出了軟系統方法。由于社會經濟系統不可能像工程技術系統那樣將各種方案進行科學地定量分析,因而難以評價出最優方案,所以Checkland方法的核心不是最優化而是比較或者是學習,即是從模型和現狀的比較中來學習改善現狀的途徑。

80年代末以來,錢學森等學者從各種系統中分離出一種系統,即開放復雜巨系統,并研究其方法論。錢學森早年在蘭徹斯特的工作中提煉出半經驗半理論的處理復雜對陣問題的方法論,后來又進一步發展為處理復雜行為系統的定量方法學,從經驗假設出發,通過定量方法途徑獲得結論,強調數學模型的經驗含義和定量定性相結合。

1987年,錢學森提出了定性和定量相結合的系統研究方法,之后提出綜合集成的概念,并把處理復雜巨系統的方法命名為定性定量相結合的綜合集成方法,又把它表述為從定性到定量的綜合集成技術。

1992年,又提出從定性到定量的綜合集成研討廳體系,進而把處理開放復雜巨系統的方法與使用這種方法的組織形式有機結合起來。對于難度自增值系統,王浣塵提出了“旋進原則”,即不斷地跟蹤系統的變化,選用多種方法,采用循環交替結合的方式,逐步推進問題的深度和廣度。張文泉等將系統思維分為硬、軟系統思維。并將以傳統的運籌學(OR)、系統工程等為代表的用常規數學模型就能優化解決硬問題的方法稱為硬系統方法。而注重人的因素,考慮人的世界觀、價值觀以便處理包括人在內的軟問題的方法則稱為軟系統方法。其中,根底定義由系統的受益者或受害者C(Customer)、系統(變換T)的執行者A(Actors)、系統輸入輸出變換T(Transformation Process)、賦予根底定義實際意義的世界觀W(Worldview)、系統所有者O(Owners)、系統的環境約束E(Environ-mental constraints)組成。CATWOE的具體含義是系統所有者O使系統在環境約束E下,由系統執行者A通過變換T將其輸入變換為輸出。而系統的受益者或受變換影響的人,賦予變換具體含義的世界觀至少包括W。在硬、軟系統方法的基礎上,研究探索硬、軟方法兼容,自然科學和人文社會科學膠合的廣義系統方法GSM(General Systmes Methodol-ogy),在理論(模型世界)和實踐(現實世界)相結合的原則下,GSM由五部分組成(見圖3)。GSM是以知識綜合集成為其基本特征的。

四、系統分析有哪些內容

霍爾方法論是出現最早、影響最大的結構模型方法論。霍爾結構模型包括三維,即時間維、邏輯維和專業維。其中,粗結構時間維劃分為7個階段,即規劃、設計、研制(開發)、生產、安裝、運行和更新等階段。細結構邏輯維又將時間維的每個階段分為6個具體工作步驟,即擺明問題、確定目標、系統綜合、系統分析、決策和實施。專業維是系統工程涉及的專業。

霍爾方法論解決的是結構化良好的工程問題,也稱為硬系統方法論。

英國學者P.B.Checkland提出軟系統方法論。其他典型的方法論還有我國學者錢學森院士、顧基發研究員等在20世紀80年代~90年代提出的綜合集成法和綜合集成研討體系,以及“物理—事理—人理”系統方法論。

最主要的是錢學森等所提出的開放的復雜巨系統理論及其方法論,即從定性到定量的綜合集成方法,包括知識體系專家體系和工具體系的定性到定量的綜合集成研討廳體系。王浣塵把系統方法論概括為五種類型:即內核原則;系統原理包括6條基本原理(組成原理、關聯原理、整體原理、層次原理、階段原理和對環境的相對獨立原理)和2條輔助原理(功能原理、目的原理);結合原則;從定性到定量綜合集成技術;旋進原則。隨著科學技術的發展,人們固然重視一個個能解決實際問題的具體方法,同時人們更重視從中研究和提煉相應的方法論,尤其是針對系統分類去研究相應的系統方法論,具有極其重要的理論意義和實踐意義。

五、系統工程方法論在建筑企業管理中的應用

模型和模擬方法在系統工程研究中具有極為重要的地位。因為系統工程的研究對象不僅是有待建立的,而且是無樣本的、信息不充分的,這就使得系統工程研究包含著建立新的概念,對各種方案進行分析、評定、選擇以及檢驗各種環境因素對系統的影響等極為復雜的問題,于是就特別需要運用模型和模擬方法來表達和考察這些問題。只有這樣才能對問題有更深入的認識,從而幫助啟發思想和加速系統工程研究的進程。

明確企業基本使命和目標。在充分認識企業基本使命的基礎上,確定企業發展的目標,并力求使目標與基本使命保持一致,基于目標市場預期與企業方向選擇制定企業發展目標,建立指標體系客觀地反映和描述企業發展目標,各項指標準確定量計算或者容易進行定性分析。實施戰略的總結,總結經驗,發現問題,為研究新戰略提供依據。

現狀分析:分析環境。環境是企業生存和發展的空間,是企業戰略管理行動的主要制約因素;發現機會和威脅,在分析了環境之后,就需要評估企業有哪些機會可以發掘、利用,以及企業可能會面臨哪些威脅;分析企業的資源,識別優勢和劣勢;把握未來發展趨勢,影響中國建筑市場未來發展趨勢的驅動與抑制因素分析;中國建筑市場未來的發展格局與可能的前景;未來競爭格局;未來產業格局如法規及監管的變化,技術的進步等;未來長、中、短期主要市場格局,用戶細分與用戶需求變化,以及業務態勢等的分析預測。可采用數學模型法、交叉影響分析法等預測方法。

戰略態勢的確定。把握戰略時機、充分考慮客觀條件、充分考慮進行戰略調整或轉移的動力。

形成新戰略。經營戰略:建筑市場的轉型與建筑企業發展的重點,建筑業務的統一戰略安排與管理,單一業務的運營模式選擇與創新;業務發展戰略:高檔環保業務發展、增值業務發展;市場開拓戰略:高檔與環保業務相互進入、海外市場拓展策略;營銷戰略:企業品牌宣傳、產品市場營銷;競爭戰略:與各大運營商的競爭與合作;合作伙伴戰略:與上、下游企業的合作與對整體生態環境的控制;技術與網絡支持戰略;企業信息化與管理現代化戰略;網絡演進與技術發展戰略;資本運作戰略;資本管理戰略;戰略投資戰略;風險投資戰略;集團運作戰略;人力資源戰略;公共關系、政府關系與企業風險管理戰略。

戰略評價和選擇。對新提出戰略的合理性、可行性及對實現企業目標的潛在作用做出嚴格評價,從而為戰略選擇提供依據。

戰略籌劃。確定戰略階段、戰略重點、戰略目標及戰略措施等。

戰略實施。制定中、長期規劃和短期計劃,溝通思想、儲備人力、完善政策體系。

從系統的觀點看,企業戰略與企業戰略環境、企業戰略能力有關。因此,將企業戰略環境、企業戰略能力因素建立量化的尺度。可采用專家評分法對企業戰略環境(SE)進行量化。可采用功效系數法對企業戰略能力(SC)進行量化。

利用系統動力學方法確定一個適當的模型,綜合、有效地反映各種復雜因素之間的關系,通過分析、觀察各因素發生波動時,對總體戰略目標的影響,找出關鍵因素,并研究其穩定性。系統建模的原則:數學模型要滿足現實性、簡潔性、適應性、強壯性。系統建模的步驟主要有:形成問題;選定變量;變量關系的確定;確定模型的數學結構及參數辨識;模型真實性檢驗。

通過對博弈論中激勵理論、代理模型的研究,分析企業價格戰略、競爭戰略以及多方合作經營戰略。“競爭”是目前國內建筑行業發展最為顯著的特點,也是國內建筑企業面臨的首要問題,國內建筑企業必須改變原來的經營理念和管理方法,采用更多科學的分析方法,進行細致的分析,才能做大做強,在國際競爭中占據一席之地.

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

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

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

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

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

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

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

①面向處理方法（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）

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