第一篇：軟件工程實驗報告

實驗三：面向對象的系統對象模型實驗

一、實驗目的

1: 熟悉面向對象分析的基本方法，加深理解對象模型、動態模型和功能模型的意義和 作

2: 學習使用rose工具進行面向對象分析的方法

3：理解對象模型、動態模型和功能模型在rose系統中的表示

4：學習用例圖、類圖、關聯圖、順序圖、狀態圖的繪制方法，了解其各自的作用

二、實驗環境

1.硬件環境

P4以上的個人計算機環境，要求內存不少于128MB，硬盤不小于20G.。2.軟件環境

操作系統：Windows 2000 或 Windows XP 數據庫： SqlServer 2000 或 Access 2003數據庫系統 3.通用工具軟件

通用繪圖工具： MicroSoft Visio 2003 文本編輯工具： MicroSoft Word 2003 4.CASE工具

實體建模工具： Erwin 4.0 UML建模工具：Rose 2000

三、實驗內容

1.實驗題目

已知資料管理系統提供資料信息維護、資料查詢、借閱/歸還三項基本功能。使用本系統的角色包括管理員、教師、學生三類。管理員可從事所有操作，學生與教師只能進行資料查詢、借閱/歸還操作。教師最多可以同時借閱10本資料、學生只能同時借閱5本。對于借閱期滿3個月但是仍未歸還的資料，在管理員控制下，系統將自動生成并輸出“催還單”。

試采用面向對象的分析方法對“資料管理系統”進行需求分析和初步設計，做出其詳細的需求陳述；定義基本功能及角色；提取對象、做出用例圖和類圖 2.實驗內容

利用rose工具進行系統建模的實驗，建立所指定之題目的用例圖和對象模型 3.系統初步設計

資料管理系統的角色有三種，分別是管理員、教師、學生。資料管理系統的基本功能有一下三項： ? 資料信息維護 ? 資料查詢 ? 借閱/歸還 4.思考題

1：“角色定義”在應用系統中有什么作用？ 答：角色的定義有利于明晰角色所對應的事物以及對數據和功能的操作權限，是系統更加條理。

2：USE-CASE圖反映了系統在哪一方面的需求？ 答：它描述了系統的功能以及如何使用一個系統并顯示誰將是相關的用戶、用戶希望系統提供什么服務以及用戶需要為系統提供的服務，它反映了整個系統的一個大概設計。3：對象模型應當包括哪些內容？使用ROSE工具進行分析建模時，通過哪幾種圖例描述對象模型？

答：對象模型描述的是系統的靜態結構，包括系統的類和對象，他們之間的屬性和操作，以及它們之間的聯系。它通常用用例圖和類圖來描述。

5系統類圖

6.系統用例圖

第二篇：軟件工程實驗報告

《軟件工程》課程實驗報告

實驗名稱：教務管理系統之子系統——學院課程安排

姓名：

院（系）：軟 件 學 院

專業班級：

學號：

指導教師：

地點：

成績：

時間：2012 年 10月 日 至 2012 年 11月 8 日

1.實驗目的確定項目的可實施性，獲取項目的需求，并在此基礎上完成系統的邏輯功能模型的建立，了解軟件工程中需求分析階段的主要活動和需求分析文檔描述的主要內容，掌握利用數據流圖描述系統功能需求的方法，正確應用數據字典。增進對軟件工程的理解，學會系統的分析軟件的構成，掌握并理解軟件從確立到測試等一系列過程。

2.實驗內容

1.系統簡介

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

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

2.限定條件

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

b)學院中層干部的主講課時不能超過4學時/周。

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

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

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

項目數據流圖

系統的分析“教務管理系統之子系統——學院課程安排”的組成、結構和實現步驟，明白項目的業務流程圖，繪制數據流圖（DFD），數據模型（ER），編寫數據字典（DD），數據加工處理的描述，撰寫需求規格說明書

3.實驗步驟

1.2.3.4.5.對圖書管理系統進行分析，整合用戶權限和操作 根據用戶操作流程畫出系統流程圖 對系統做出概要分析，擬定開發流程 繪制出甘特圖 繪制線性時間圖

4總結與回顧

通過這次實驗，我學到了很多東西，教務管理系統是學校的管理核心，管理應涉及到學校的專業設置、學藉管理、成績管理、網上注冊、開課管理、選課管理、師資管理等，在數據庫一級建立強有力的安全系統，管理人員可以在互聯網的任何地方辦工，真正實現學校網上管理。

學校中的教務管理是一項很重要的工作，包括學生管理，教師管理和課程管理等。開發“教務信息處理系統”的目的就是利用計算機的查詢和運算功能，代替手工處理，提高工作效力和質量，所以該系統是必要而且能夠實現的。

此次開發的軟件是教務管理系統的一個子系統，即學院課程安排。通過此次課程設計，我們更加了解了軟件的原理，軟件的開發方法和步驟，如繪制數據流圖和數據字典的編寫。進一步掌握了有關數據庫設計的知識和JAVA程序設計，了解了有關網絡的相關知識，對軟件開發平臺有了一定了解。我增長了不少軟件工程與編程，數據庫的知識。在作設計的過程中，軟件是不斷變化的，開始構造的是一方面，實際制作時又是另外一方面，所以得不斷變化。軟件必須有效的支持他的用戶，我們做的軟件是學生選課系統，所以我們需要從學生和老師，管理員的實際情況出發，制定他們操作方便的系統，是軟件對用戶友好。

在寫數據字典之前，我對數據字典的理解有一些偏差，通過這次作實驗，我知道了數據字典就是對數據流，數據流分量，數據存儲，處理的定義集合。我們做這種比較小的軟件時，數據字典還比較好維護，哪里出了問題，可以很快的找到，然后改正。如果做比較大的軟件時，數據字典就不好維護了。開發大的軟件系統時，數據字典的規模和復雜程度迅速增加，貌似人工維護就不太可能了。

這次實驗的完成是我們小組共同努力的結果，我們每個人都付出了很大的汗水，也讓我明白了團隊合作是多么的重要，那么大的工作量僅靠一個人的力量是不可能完成的，在以后的工作和學習中一定要重視團隊合作的重要性，多與合作伙伴交流，了解每個人的想法，最后大家的想法和在一起就是個很了不起的工作。也讓我認識到軟件在我們的生活中越來越重要，我們的生活處處離不開軟件，也讓我對自己以后的工作有了很深的了解，讓我可以向著自己的目標一點點前進。

第三篇：軟件工程實驗報告

《軟件工程》實驗報告

專業班級微軟IT一班

學生姓名

指導教師趙春剛

實驗一需求分析

一、實驗目的通過對軟件項目的需求分析，掌握需求分析的主要方法和技術，了解需求分析過程。

二、實驗要求

自選一個軟件項目，應用軟件工程中需求分析方法對系統需求進行分析。

三、實驗內容

1、項目完成主要功能概述（1）項目名稱

（2）項目完成主要功能

2、項目需求描述（建立需求模型）（友情提示：完成主要的用例模型即可）

四、實驗總結

實驗二軟件設計

一、實驗目的通過對軟件項目的軟件設計，掌握軟件設計的方法的技術，了解軟件設計過程。

二、實驗要求

針對需求分析所選的項目和功能模塊進行。完成軟件項目主要概要設計和詳細設計。

三、實驗內容

1、項目概要設計描述（建立概要設計模型）

（友情提示：完成項目的主要系統結構圖（功能模塊圖）即可）

2、項目詳細設計描述（建立詳細設計模型）

（友情提示：用流程圖或UML相關模型（活動圖、時序圖等），完成兩個模塊以上）

四、實驗總結

說明：（此實驗為可選做，若完成實驗成績加分）

實驗三軟件測試

一、實驗目的通過對軟件項目的測試，掌握軟件測試的原理和方法，了解軟件測試過程。

二、實驗要求

針對需求分析所選的項目和功能模塊進行。完成軟件項目主要功能模塊的測試。

三、實驗內容

1、采用主要測試方法描述

2、主要功能模塊測試用例設計

四、實驗總結

第四篇：軟件工程實驗報告1

Compilation of reports 20XX 報 告 匯 編

報告文檔·借鑒學習word 可編輯·實用文檔

本科實驗報告

課程名稱：

軟件工程

實驗項目：

機票預定系統

實驗地點：

明向校區實驗室 208

專業班級：

軟件 1305 班

學號：

2013005747

學生姓名：

王偉

指導教師：

崔冬華

時間：2015 年 4 月 26 日

報告文檔·借鑒學習word 可編輯·實用文檔

實驗 題目: 機票預定系統 1．系統簡介 航空公司為給旅客乘機提供方便，需要開發一個機票預定系統。各個旅行社把預定機票的旅客信息（姓名、性別、工作單位、身份證號碼（護照號碼）、旅行時間、旅行始發地和目的地，航班艙位要求等）輸入到系統中，系統為旅客安排航班。當旅客交付了預訂金或通過網上支付方式付款后，旅客就可以在飛機起飛前憑個人二代身份證在機場指定系統上自助打印機票，系統核對無誤即打印出機票給旅客。此外航空公司為隨時掌握各個航班飛機的乘載情況，需要定期進行查詢統計，以便適當調整。

2．技術要求和限制條件（1）在分析系統功能時要考慮有關證件的合法性驗證（如身份證的驗證可以直接連接公安系統的二代身份證信息庫）等。

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

1．旅客延誤了取票時間的處理 2．航班取消后的處理 3．旅客臨時更改航班的處理（3）系統的外部輸入項至少包括：旅客、旅行社和航空公司。

報告文檔·借鑒學習word 可編輯·實用文檔

課程名稱 機票預訂系統 實驗題目 傳統軟件工程的可行性研究 一． 引言

隨著社會的發展，人民生活水平的不斷提高，出行旅游成為了人們放松心情、接觸自然的最好方式。優質的服務，快速的運輸，廉價的機票，空運成為了人們出行的第一選擇。然而傳統的購票方式，仍然是人工機械的處理。大多數乘客通過電話方式了解信息和預訂機票。這樣給服務臺增加了很大的壓力，并且大多數時間不能及時響應乘客的要求。這種傳統的購票方式，不僅效率低下，而且給人們的出行帶來了很多不便。同時，人工處理的成本再加上巨額的通信費用造成了傳統購票方式的巨大開銷。當面對機票訂購高峰時刻的大量數據處理的時候，僅靠手工操作以現有的工作人員根本無法應付。同時還會出現由此帶來的大量記錄存放和管理所帶來的問題。從而給旅客和管理人員帶來了許多的不便。

航空公司需要開發一個機票預定系統，用于簡化處理預定機票的過程。由各個旅行社直接將定票信息通過網絡提交到航空公司，系統安排航班及打印各類單據。

目標：在計算機網絡，數據庫和先進的開發平臺上，利用現有的軟件，配置一定的硬件，開發一個具有開放體系結構的、易擴充的、易維護的、具有良好人機交互界面的機票預定系統，實現航空公司的機票銷售的自動化的計算機系統，為企業的決策層提供準確、精細、迅速的機票銷售信息，為旅客提供快捷、方便的服務。

二． 可行性研究前提

系統規模與功能: 1.旅行社記錄旅客的基本信息以及航班需求，并且加工這些信息，最后存儲這些信息。

2.旅行社提供旅客訂票信息：各個旅行社把預定機票的旅客信息輸入到系統中； 3.系統處理訂票信息：系統根據旅行社提供的旅客訂票信息，為旅客安排航班； 4.系統打印取票通知單和帳單：當旅客交付了預訂金后，系統打印出取票通知和帳單給旅客； 5.系統出票：旅客在飛機起飛前一天憑取票通知和帳單交款取票，系統核對無誤即打印出機票給旅客； 6.航班信息中心：包括各航班飛機的乘載情況等信息； 7.對于本系統還應補充一下功能：

(1)．旅客延誤了取票時間的處理(2)．航班取消后的處理(3)．旅客臨時更改航班的處理

報告文檔·借鑒學習word 可編輯·實用文檔 8.系統的外部輸入：旅客、旅行社和航空公司。

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

三、對所建設系統的分析

技術可行性：在計算機網絡、數據庫和先進的開發平臺的基礎上，使用 JSP 技術，在加上好的硬件支持，和高速的校園網絡，開發一個具有開放體系結構的、易擴充的、易維護的、具有良好人機交互界面的機票預定系統，實現航空公司的機票銷售的自動化的計算機系統是可行的。在加上扎實的理論知識和一些開發經驗。在現有的技術條件和硬件條件的支持下開發機票預定系統被證實為可行的。

本系統使用的操作系統和數據庫是目前最為普及和成熟的一種系統開發軟件。從這種軟件過去使用、升級情況和軟件商所承諾的今后軟件發展情況分析，系統軟件應支持原系統版本上的各種應用正常使用。因而，該機票預定系統不存在技術問題。

服務器采用 Windows 最新系統，利用 MySQL 最新數據庫系統。

經濟可行性：

社會可行性：

1、法律因素

2、所有軟件都選用正版.3、所有技術資料都由提出方保管。

4、合同制定確定違約責任

操作可行性：

所有員工都要接受培訓，包括前臺工作人員和系統管理人員。要求所有員工都具有一定的計算機操作能力。

客戶端與服務器端聯系在一起，在旅游局中只設立終端，在機場設立服務器，數據輸入由終端輸入，所有數據都由服務器處理，只在終端上顯示數據結果。

此設計簡化了數據處理，但加重了服務器的數據處理。而使用客戶端/服務器機理，簡化數據流量，加快數據處理。

五、系統流程圖

報告文檔·借鑒學習word 可編輯·實用文檔 填寫基本信息旅客 初期數據旅行社將旅客信息輸入系統安排航班 交付定金打印出訂票通知和賬單交款 系統核對 打印機票機票旅客訂票通知和賬單 旅客旅客信息

報告文檔·借鑒學習word 可編輯·實用文檔

課程名稱 機票預訂系統 實驗題目 傳統軟件工程的需求分析建模 一、目的與任務

目的：

(1)客戶端功能 旅行社把旅客要求訂票的信息由專人負責輸入，進行網上訂票。

當旅客交付了預訂金后，系統打印出取票通知和帳單給旅客。

(2)服務器端功能 接收由旅行社客戶端發回的所需機票信息。通過網絡接收機票信息并存入到服務器的數據庫中。

生成航班信息。根據所需機票信息（時間，地點），在數據庫中查詢并得到正確的航班的信息，分配所需的機票數并在數據庫中做出已售出的標記。

傳遞航班信息到旅行社（客戶端），把得到的航班信息通過網絡傳遞到旅行社。

打印機票給已經訂票的旅客。根據旅客的取票通知及帳單，經過確認無誤后，接受旅客的付款后把機票印出來交給旅客。

任務：

數據流圖(1)旅客訂票流程圖，如圖 3.1 所示：

旅客旅客信息記錄訂票訂票旅客清單傳給航空公司訂票信息訂票信息安排航班訂票信息傳給旅行社訂票信息航班機票信息航班信息產生取票通知旅客訂票清單航班信息旅客 取票通知 圖 3.1 旅客訂票流程(2)旅客取票流程圖，如圖 3.2 所示：

報告文檔·借鑒學習word 可編輯·實用文檔 旅客旅客訂票信息取票通知訂票信息確認打印機票核對正確售出機票信息旅客 機票 圖 3.1 旅客取票流程 數據 字典 名字：旅客信息別名：custom描述：旅客個人信息，用于確認旅客定義：旅客信息=姓名+性別+身份證號碼+旅行時間+旅行目的地位置：輸入到旅行社（瀏覽器端）

名字：訂票旅客清單別名：orderList描述：已訂票的旅客的記錄定義：訂票旅客清單=所有訂票旅客信息的集合位置：輸入到旅行社（瀏覽器端）

名字：訂票信息別名：orderInf描述：旅客的旅行時間和目的地，用于確定旅客的航班定義：訂票信息=旅客旅行時間+旅客旅行目的地位置：傳輸到航空公司端（服務器端）

名字：機票信息別名：ticket描述：旅客的航班信息，根據旅客的旅行時間和目的地確定定義：航班機票信息=旅客機票時間+旅客機票班次+剩余機票數位置：記錄在航空公司（服務器端）

名字：取票通知別名：getMesg描述：旅客領取機票的憑證定義：取票通知=旅客姓名+旅客身份證號碼位置：輸出到打印機

報告文檔·借鑒學習word 可編輯·實用文檔

課程名稱 機票預訂系統 實驗題目 傳統軟件工程的結構設計 總體設計可能的設計方法有自頂向下，逐步細化設計方法；模塊化設計方法；結構化設計方法。針對以上系統要完成的功能，本系統總體設計采用自頂向下，逐步細化的方法將功能層次結構的各個部分組合起來，以完成整個系統的實現細節。

1.層次結構 系統的的 頂層結構

: 航班信息管理

訂票處理:

取票處理：

例外處理(此處航班改變后, 均做退票處理)2.接口設計（人機界面設計）

管理員和票務員使用同一登陸界面，登陸后進去后有個自的界面，然后進一步操作。

大體的界面設計 訂票界面 4.數據庫設計 體 整體 E-R 圖 航班信息管理 航班錄入 航班查詢 航班修改 航班刪除 圖 4.2 航班信息管理 圖 4.2 訂票處理

報告文檔·借鑒學習word 可編輯·實用文檔 旅客姓名性別 身份證號 旅行時間旅行目的地訂票nm機票剩余數 機票編號出發地 機票班次 機票日期旅行出發地航班訂票日期目的地編號旅行社編號 模塊設計

模塊設計將對總體設計中模塊結構進行細化。

登陸模塊 航班信息管理的各個模塊 訂票處理的各個模塊

報告文檔·借鑒學習word 可編輯·實用文檔 輸入旅客信息檢查信息的合法性是否正確？入口NY保存旅客數據出口列出匹配信息自動匹配航班調整和確認匹配入口出口更新數據旅客登記安排航班規范并打印通知單從旅客信息中讀出訂票信息入口出口通知旅客響應旅客 圖：訂票處理各模塊 取票處理模塊 例外處理退票面模塊(延誤取票和這個模塊類似)

報告文檔·借鑒學習word 可編輯·實用文檔

課程名稱 機票預訂系統 實驗題目 測試

一、目的與任務 目的：在實驗四基礎上選擇一個模塊進行編碼，完成相關的測試。

1、了解軟件測試方法分類，其中包括：

1）白盒測試 2）黑盒測試 3）靜態測試 4）動態測試 2、了解測試類型

1）單元測試 2）集成測試 3）確認測試 4）黑盒測試

5）白盒測試 6）功能測試 7）

α 測試

8）

β 測試 任務：正確運用軟件測試技術和方法，完成系統的單元測試、綜合測試、確認測試、系統測試的方法，掌握測試用例的設計方法，并給出測試報告。

二、內容、要求

測試用例：

使用黑盒法測試 “新增航班” 模塊功能 1． 驗證表單完整性：

用例一：

出發城市：北京

到達城市：

起飛日期：

起飛時間：

機票價格：

機票數目：

用例二：

出發城市：北京

到達城市：上海

起飛日期：

起飛時間：

機票價格：

機票數目：

用例三：

出發城市：北京

到達城市：上海

起飛日期：2008-6-11

報告文檔·借鑒學習word 可編輯·實用文檔

起飛時間：

機票價格：

機票數目：

用例四：

出發城市：北京

到達城市：上海

起飛日期：2008-6-11

起飛時間：12:30

機票價格：

機票數目：

用例五：

出發城市：北京

到達城市：上海

起飛日期：2008-6-11

起飛時間：12:30

機票價格：1234

機票數目：

用例六：

出發城市：北京

到達城市：上海

起飛日期：2008-6-11

起飛時間：12:30

機票價格：1234

機票數目：123 2． 驗證出發城市及到達城市合法性：

用例一：

出發城市：北京

到達城市：上海

起飛日期：2008-6-11

報告文檔·借鑒學習word 可編輯·實用文檔

起飛時間：12:30

機票價格：1234

機票數目：123 用例二：

出發城市：北京

到達城市：北京

起飛日期：2008-6-11

起飛時間：12:30

機票價格：1234

機票數目：123 3． 驗證起飛日期合法性：

用例一：

出發城市：北京

到達城市：上海

起飛日期：2008-6-11

起飛時間：12:30

機票價格：1234

機票數目：123 用例二：

出發城市：北京

到達城市：上海

起飛日期：2008-6-6

起飛時間：12:30

機票價格：1234

機票數目：123 4． 驗證機票價格合法性：

用例一：

出發城市：北京

到達城市：上海

報告文檔·借鑒學習word 可編輯·實用文檔

起飛日期：2008-6-11

起飛時間：12:30

機票價格：1234

機票數目：123 用例二：

出發城市：北京

到達城市：上海

起飛日期：2008-6-11

起飛時間：12:30

機票價格：￥1234

機票數目：123 用例三：

出發城市：北京

到達城市：上海

起飛日期：2008-6-11

起飛時間：12:30

機票價格：-1234

機票數目：123 5． 驗證機票數目合法性：

用例一：

出發城市：北京

到達城市：上海

起飛日期：2008-6-11

起飛時間：12:30

機票價格：1234

機票數目：0 用例二：

出發城市：北京

到達城市：上海

報告文檔·借鑒學習word 可編輯·實用文檔

起飛日期：2008-6-11

起飛時間：12:30

機票價格：1234

機票數目：&123 用例三：

出發城市：北京

到達城市：上海

起飛日期：2008-6-11

起飛時間：12:30

機票價格：1234

機票數目：-123

報告文檔·借鑒學習word 可編輯·實用文檔

課程名稱 機票預訂系統 實驗題目 面向對象的分析與設計 一、目的與任務

目的：掌握面向對象的分析、設計方法，建立對象模型、功能模型和動態模型，并掌握 UML 中常用的模型符號的使用方法。

任務：用一個簡單項目（可以考慮仍然選擇前面面向過程軟件工程所選定的項目），通過分析，建立系統用例圖，抽取出類，建立順序圖及類的狀態圖等。

二、內容、要求

用例模型圖

用例模型圖說明：

機票預訂系統主要使用的對象是旅行社管理員。管理員根據顧客填寫的目的地和時間信息，將其輸入系統，系統根據相關信息進行處理，則系統其中的一個功能即用例就是接收顧客信息。顧客需要用取票單去航空公司取票，系統由管理員輸入的信息來識別，則系統的另一個功能即用例就是預定管理員輸入信息符合的票。1--2 2、類圖

類圖說明：

為此系統定義了 4 個類，分別是顧客類，管理員類，航空公司類，機票類。各個類對應的屬性和操作方法在圖中已表示出，目前應該還是有很多不完善的地方，在后期再加以修改。

報告文檔·借鑒學習word 可編輯·實用文檔 1 1--3 3、對象圖

對象圖說明：

對象圖是根據設置的類圖而設置的。一個對象就是類的一個具體實例，本例中設置了一個 custom 的取票操作，詳細信息在圖中已經設置，根據顧客的相關信息和操作，系統會調用相應的類的對象來處理，在本例中不一定會全部都涉及。1--4 4、順序圖

順序圖說明：

順序圖用來描述對象之間動態的交互關系，著重體現對象間消息傳遞的時間順序。由于在顧客，旅行社，航空公司之間也有先后順序，所以在順序圖中會有兩個生命周期，分別是訂票和取票操作。旅行社根據顧客填寫的信息，就操作系統的訂票功能。系統在對管理進行處理時，會先記錄顧客的相關信息，最后再打印取票單給顧客。系統對取票進行處理時，會先收取款，最后會把票給顧客。1--5 5、狀態圖

報告文檔·借鑒學習word 可編輯·實用文檔

狀態圖說明：

在訂票系統中，主要會有兩個對象的狀態：顧客和管理員。顧客的狀態最開始是填寫信息，再管理員將信息輸入系統，此時系統查詢合適的航班，顧客收到系統打印出的相應單據，最后顧客將取票單和款返回給系統得到票。1--6 6、活動圖

報告文檔·借鑒學習word 可編輯·實用文檔

活動圖說明：

狀態圖著重描述對象的狀態變化以及觸發狀態變化的事件，活描述系統中各種活動的執行順序，刻畫一個方法中所要進行的各項活動的執行流程。在訂票系統中，各種活動由顧客和管理員的狀態圖轉化而來。顧客的信息，之后就由管理員輸入系統，系統對應的活動就有查詢訂票，各自活動都有自己的的后續活動。2、動態模型

動態模型說明：

動態模型主要是描述系統的動態行為和控制結構。動態行為包括系統中對象生存期內可能的狀態以及事件發生時狀態的遷移，還包括對象之問動態合作關系，顯示對象之間的交互過程以及交互順序，同時描述了為滿足用例要求所進行的活動以及活動問的約束關系。動態模型主要包括的狀態圖、順序圖和活動圖已經在1-4、1-5、1-6中畫出。

建立動態模型的第一步是編寫交互行為的腳本；第二步從腳本中提取出事件，確定后觸發每個事件的動作對象及接收事件的目標對象；第三步排列事件發生的次序，確定每個對象可能有的狀態及狀態間的轉換關系，并用狀態圖描繪它們。最后，比較各個對象的狀態圖，檢查它們之間的一致性，確保事件之間的匹配。3、功能模型

功能模型表明了系統中數據之間的依賴關系，以及有關的數據處理功能，它由一組數據流圖組成，此功能模型的分析與設計依照對象模型和動態模型而來。

DFD圖（數據流圖）描繪信息流和數據從輸入移動到輸出的過程中所經受的變換。數據流中沒有任何具體的物理部件，它知識描繪數據在軟件中流動和被處理的邏輯過程，流程如圖。4、對象模型

報告文檔·借鑒學習word 可編輯·實用文檔

對象模型說明:

對象模型描述了現實世界中的類與對象以及它們之間的關系，表示了目標系統的靜態數據結構。首先確定對象類和關聯，對于大型復雜問題還要進一步劃分出若干個主題；然后給類和關聯增添屬性，以進一步描述它們；接下來利用適當的繼承關系進一步合并和組織類。而對類中操作的最后確定，則需要等到建立了動態模型和功能模型之后，以為這兩個子模型更準確地描述了對類中提供的服務的需求。

第五篇：軟件工程第二次實驗報告

江 西 理 工 大 學

軟件工程 實驗報告

實驗名稱 實驗2 編寫軟件可行性分析報告 實驗日期 2014-04-03 專業班級 計算機111班 桌號

實 驗 人

學號

同組人

一、實驗目的和要求

對一個軟件系統進行可行性分析，將可行性分析過程的結果進行分析匯總，編寫一份描述計劃任務的可行性分析報告。

二、實驗內容和步驟

（1）系統概述。對當前系統及存在問題的簡單描述、新系統特點及開發要點，新系統及其各個子系統的功能與特性、新系統與當前系統的比較等。

（2）可行性分析。可行性分析是報告的主體。論述新系統在經濟上、技術上、運行上、管理及法律上的可行性，以及對新系統的主客觀條件的分析。

（3）初步開發方案及開發計劃。在可行性分析的基礎上，提出初步開發建議方案和計劃。

（4）結論意見。綜合上訴分析，說明新系統是否可行，給出具體結論。

三、結果分析 1 引言

1．1 編寫目的：

可行性研究的目的是為了對問題進行研究，以最小的代價在最短的時間內 確定問題是否可解

經過對此項目進行詳細調查研究，初擬系統實現報告，對軟件開發中將要

面臨的問題及其解決方案進行初步設計及合理安排。明確開發風險及其所帶來的 經濟效益。本報告經審核后，交軟件經理審查。1.2項目背景：

開發軟件名稱：機票預訂系統。

項目任務提出者：中國民航及中國國際旅游開發公司。項目開發者：浙江大學IMK 開發小組。用戶：中國民航及中國國際旅游開發公司。

第2 頁 / 共4頁

實現軟件單位：中國國際旅游開發公司及浙江大學 項目與其他軟件，系統的關系：

本項目采用客戶機/服務器原理，客戶端的程序是建立在Windows NT 系統上以MicrosoftVisual C++為開發軟件的應用程序，服務器端采用Linux 為操作系統的工作站，是采用Oracle8 的為開發軟件的數據庫服務程序。1．3 參考資料： 《軟件工程導論》，張海藩，清華大學出版社。《實用軟件工程》，鄭人杰等，清華大學出版社。２ 可行性研究的前提 2.1要求

主要功能：為游客提供機票預定服務，方便旅游局的售票工作，提高旅游局的服 務質量和服務效率

性能要求：機場提供的信息必須及時的反映在旅游局的工作平臺上。售票系統的 定單必須無差錯的存儲在機場的主服務器上。對服務器上的數據必須進行及時正確的刷新。

輸出要求：數據完整，詳實。輸出要求：簡捷，快速，實時。

安全與保密要求：服務器的管理員享有對機場航班信息庫及機票信息庫和定票信 息庫的管理與修改。售票員只享有對訂票信息庫的部分修改（寫入與讀出）。完成期限：預計六個月。2.2目標：

系統實現后，大大提高旅游局的機票預定服務效率。降低售票服務中的錯誤發生率，減少信息交流的煩瑣過程及其帶來的開銷。2.3條件，假定和限制 建議軟件壽命：5 年。

經費來源：中國國際旅游開發公司。

硬件條件：服務器sun 工作站，終端為pc 機。運行環境：Linux 數據庫：Oracle8

2.4決定可行性的主要因素

成本/效益分析結果，效益〉成本。

技術可行，現有技術可完全承擔開發任務。操作可行，軟件能被原有工作人員快速接受。３ 技術可行性分析 系統簡要描述：

在旅游局中的終端是安裝了Windows NT 的PC 機，主要目的是向機場的服務器傳 遞數據。當顧客在旅游局進行咨詢時，終端向服務器發出查詢請求，服務器根據航班信息庫的實時數據，向終端發送數據，顯示在終端的屏幕上。當顧客向售票員定票時，終

第3頁 / 共4頁第4頁/ 共4頁

端向服務器發出詳盡的一份定單，服務器核對后，存入定票信息庫，并修改機票信息庫。當顧客再次來取票時，終端向服務器發出查詢定票請求，服務器接收后，查詢定票信息庫，核對后，傳送機票確認表單，終端打印出機票。４ 經濟可行性分析 4.1支出 基礎投資：

終端PC 機２０臺：8000*20 = 16 萬 網絡設備：10 萬 輔助配置：10 萬 共計：36 萬

其他一次性投資： 系統管理員事務 航班信息的更新

服務器終端顯示數據產生報表 售票員查詢請求 數據庫產生報表 客戶機終端顯示數據 售票員表單申請產生報表 客戶機終端顯示數據

售票員機票核對事務在客戶端打印機票和帳單產生報表及帳單 Oracle 8.0 : 20 萬 Windows NT: 10 萬 操作員培訓費：5 萬 共計：35 萬 經常性支出：

人工費用: 6(月)*20(人)*5000(圓)=60 萬 其他不可知額外支出: 20 萬 共計: 80 萬

支出共計: 151 萬 4.2效益 一次性收益 0 元

經常性收益

（按銀行利率：1%）；

減少員工20 人(1000 圓/人)五年收益:

1000*（1.1+（1.1）2+（1.1）3+（1.1）4+（1.1）5）*20*12*5=120 萬 工作效率提高收益（工作效率提高30%）:

30*（1.1+（1.1）2+（1.1）3+（1.1）4+（1.1）5）*（30%）*5 = 45 萬 經常性收益共計: 160 萬

不可定量收益

因服務質量提高增加旅客量10%:

1000 萬*10%*(90%+(90%)2+(90%)3+(90%)4+(90%)5)=360 萬 收益共計: 520 萬 4.3收益/投資比

520 萬/151 萬= 344% 4.4投資回收周期 2-3 年

4.5敏感性分析

設計系統周期為五年, 估計最長可達10 年 處理速度: 一般查詢速度<4 秒 關鍵數據查詢速度: <2 秒 5 用戶使用可行性

使用本軟件人員要求有一定計算機基礎的人員,系統管理員要求由計算機的專業知 識,所有人員都要經過本公司培訓.管理人員也需經一般培訓.經過培訓人員將會熟練使用本軟件.兩名系統管理員,一名審計員將進行專業培訓,他們將熟練管理本系統.６ 其他可供選擇的方案

客戶端與服務器端聯系在一起，在旅游局中只設立終端，在機場設立服務器，數據輸入由終端輸入，所有數據都由服務器處理，只在終端上顯示數據結果。此設計簡化了數據處理，但加重了服務器的數據處理。而使用客戶端/服務器機理，簡化數據流量，加快數據處理。７ 結論意見

由于投資效益比遠大于100%, 技術、經濟、操作都有可行性，可以進行開發。

四、實驗心得

此次文檔的編寫在整個軟件開發的過程中，起到了很重要的作用。它讓我們知道在以后的軟件開發過程中應該注意的問題，并且應該做出相應的措施來解決軟件開發過程中出現的各種問題。