前言：中文期刊網精心挑選了數據庫需求分析報告范文供你參考和學習，希望我們的參考范文能激發你的文章創作靈感，歡迎閱讀。

數據庫需求分析報告范文1

引言是對這份軟件產品需求分析報告的概覽，是為了幫助閱讀者了解這份文檔是如何編寫的，并且應該如何閱讀、理解和解釋這份文檔。

1.1 編寫目的

說明這份軟件產品需求分析報告是為哪個軟件產品編寫的，開發這個軟件產品意義、作用、以及最終要達到的意圖。通過這份軟件產品需求分析報告詳盡說明了該軟件產品的需求規格，包括修正和(或)發行版本號，從而對該軟件產品進行準確的定義。

如果這份軟件產品需求分析報告只與整個系統的某一部分有關系，那么只定義軟件產品需求分析報告中說明的那個部分或子系統。

1.2 項目風險

具體說明本軟件開發項目的全部風險承擔者，以及各自在本階段所需要承擔的主要風險，首要風險承擔者包括：

任務提出者;

軟件開發者;

產品使用者。

1.3 文檔約定

描述編寫文檔時所采用的標準(如果有標準的話)，或者各種排版約定。排版約定應該包括：

正文風格;

提示方式;

重要符號;

也應該說明高層次需求是否可以被其所有細化的需求所繼承，或者每個需求陳述是否都有其自己的優先級。

1.4 預期讀者和閱讀建議

列舉本軟件產品需求分析報告所針對的各種不同的預期讀者，例如，可能包括：

用戶;

開發人員;

項目經理;

營銷人員;

測試人員;

文檔編寫入員。

并且描述了文檔中，其余部分的內容及其組織結構，并且針對每一類讀者提出最適合的文檔閱讀建議。

1.5 產品范圍

說明該軟件產品及其開發目的的簡短描述，包括利益和目標。把軟件產品開發與企業目標，或者業務策略相聯系。

描述產品范圍時需注意，可以參考項目視圖和范圍文檔，但是不能將其內容復制到這里。

1.6 參考文獻

列舉編寫軟件產品需求分析報告時所用到的參考文獻及資料，可能包括：

本項目的合同書;

上級機關有關本項目的批文;

本項目已經批準的計劃任務書;

用戶界面風格指導;

開發本項目時所要用到的標淮;

系統規格需求說明;

使用實例文檔;

屬于本項目的其它己發表文件;

本軟件產品需求分析報告中所引用的文件、資料;

相關軟件產品需求分析報告;

為了方便讀者查閱，所有參考資料應該按一定順序排列。如果可能，每份資料都應該給出：

標題名稱;

作者或者合同簽約者;

文件編號或者版本號;

發表日期或者簽約日期;

出版單位或者資料來源。

2. 綜合描述

這一部分概述了正在定義的軟件產品的作用范圍以及該軟件產品所運行的環境、使用該軟件產品的用戶、對該軟件產品己知的限制、有關該軟件產品的假設和依賴。

2.1 產品的狀況

描述了在軟件產品需求分析報告中所定義的軟件產品的背景和起源。說明了該軟件產品是否屬于下列情況：

是否是產品系列中的下一成員;

是否是成熟產品所改進的下一代產品;

是否是現有應用軟件的替代品(升級產品);

是否是一個新型的、自主型的產品。

如果該軟件產品需求分析報告定義的軟件系統是：

大系統的一個組成部分;

與其它系統和其它機構之間存在基本的相互關系。

那么必須說明軟件產品需求分析報告定義的這部分軟件是怎樣與整個大系統相關聯的，或者(同時)說明相互關系的存在形式，并且要定義出兩者之間的全部接口。

2.2 產品的功能

因為將在需求分析報告的第4部分中詳細描述軟件產品的功能，所以在此只需要概略地總結。僅從業務層面陳述本軟件產品所應具有的主要功能，在描述功能時應該 針對每一項需求準確地描述其各項規格說明。如果存在引起誤解的可能，在陳述本軟件產品主要功能的作用領域時，也需要對應陳述本軟件產品的非作用領域，以利 讀者理解本軟件產品。

為了很好地組織產品功能，使每個讀者都容易理解，可以采用列表的方法給出。也可以采用圖形方式，將主要的需求分組以及它們之間的聯系使用數據流程圖的頂層圖或類圖進行表示，這種表示方法是很有用的。

參考用戶當前管理組織構架，了解各個機構的主要職能，將有助于陳述軟件產品的主要功能。

2.3 用戶類和特性

確定有可能使用該軟件產品的不同用戶類，并且描述它們相關的特征。往往有一些軟件需求，只與特定的用戶類有關。描述時，應該將該軟件產品的重要用戶類與非重要用戶類區分開。

用戶不一定是軟件產品的直接使用者，通過報表、應用程序接口、系統硬件接口得到軟件產品的數據和服務的人、或者機構也有他們的需求。所以，應該將這些外部需求視為通過報表、應用程序接口、系統硬件接口附加給軟件產品的附加用戶類。

2.4 運行環境

描述了本軟件的運行環境，一般包括：

硬件平臺;

操作系統和版本;

支撐環境(例如：數據庫等)和版本;

其它與該軟件有關的軟件組件;

與該軟件共存的應用程序。

2.5 設計和實現上的限制

確定影響開發人員自由選擇的問題，并且說明這些問題為什么成為一種限制。可能的限制包括下列內容：

必須使用的特定技術、工具、編程語言和數據庫;

避免使用的特定技術、工具、編程語言和數據庫;

要求遵循的開發規范和標準

例如，如果由客戶的公司或者第三方公司負責軟件維護，就必須定義轉包者所使用的設計符號表示和編碼標準;

企業策略的限制;

政府法規的限制;

工業標準的限制;

硬件的限制

例如，定時需求或存儲器限制;

數據轉換格式標淮的限制。

2.6 假設和約束(依賴)

列舉出對軟件產品需求分析報告中，影響需求陳述的假設因素(與己知因素相對立)。如果這些假設因素不正確、不一致或者被修改，就會使軟件產品開發項目受到影響。這些假設的因素可能包括：

計劃使用的商業組件，或者其它軟件中的某個部件;

假定產品中某個用戶界面將符合一個特殊的設計約定;

有關本軟件用戶的若干假定(例如：假定用戶會熟練使用SQL語言。);

有關本軟件開發工作的若干假定(例如：用戶承諾的優惠、方便、上級部門給予的特殊政策和支持等。);

有關本軟件運行環境的一些問題;

此外，確定本軟件開發項目對外部約束因素所存在的依賴。有關的約束可能包括：

工期約束;

經費約束;

人員約束;

設備約束;

地理位置約束;

其它有關項目約束;

3. 外部接口需求

通過本節描述可以確定，保證軟件產品能和外部組件正確連接的需求。關聯圖僅能表示高層抽象的外部接口，必須對接口數據和外部組件進行詳細描述，并且寫入數 據定義中。如果產品的不同部分有不同的外部接口，那么應該把這些外部接口的全部詳細需求并入到這一部分實例中。

注意：必須將附加用戶類的特征與外部接口需求加以區分，附加用戶類的特征描述的是通過接口取得軟件產品的數據和服務的人的需求;而外部接口需求描述的是接口本身的需求。

3.1 用戶界面

陳述需要使用在用戶界面上的軟件組件，描述每一個用戶界面的邏輯特征。必須注意，這里需要描述的是用戶界面的邏輯特征，而不是用戶界面。以下是可能包括的一些特征：

將要采用的圖形用戶界面(GUl)標準或者產品系列的風格;

有關屏幕布局或者解決方案的限制;

將要使用在每一個屏幕(圖形用戶界面)上的軟件組件，可能包括：

選單;

標準按鈕;

導航鏈接;

各種功能組件;

消息欄;

快捷鍵;

各種顯示格式的規定，可能包括：

不同情況下文字的對齊方式;

不同情況下數字的表現格式與對齊方式;

日期的表現方法與格式;

計時方法與時間格式;

等等。

錯誤信息顯示標準;

對于用戶界面的細節，例如：一個特定對話框的布局，應該寫入具體的用戶界面設計說明中，而不能寫入軟件需求規格說明中。

如果采用現成的、合適的用戶界面設計規范(標準)，或者另文描述，可以在這里直接說明，并且將其加入參考文獻。

3.2 硬件接口

描述待開發的軟件產品與系統硬件接口的特征，若有多個硬件接口，則必須全都描述。接口特征的描述內容可能包括：

支持的硬件類型;

軟、硬件之間交流的數據;

控制信息的性質;

使用的通訊協議;

3.3 軟件接口

描述該軟件產品與其它外部組件的連接，這些外部組件必須明確它們的名稱和版本號以資識別，可能的外部組件包括：

操作系統;

數據庫;

工具;

函數庫;

集成的商業組件

說明：這里所說的“集成的商業組件”，是指與系統集成的商業組件，而不是與軟件產品集成的商業組件。例如：中間件、消息服務，等等。

描述并且明確軟件產品與軟件組件之間交換數據或者消息的目的。描述所需要的服務，以及與內部組件通訊的性質。確定軟件產品將與組件之間共享的數據。如果必 須使用一種特殊的方法來實現數據共享機制，例如：在多用戶系統中的一個全局數據區，那么就必須把它定義為一種實現上的限制。

3.4 通訊接口

描述與軟件產品所使用的通訊功能相關的需求，包括：

電子郵件;

WEB瀏覽器;

網絡通訊標準或者協議;

數據交互用電子表格;

必須定義相關的：

消息格式;

通訊安全或加密問題;

數據傳輸速率;

同步和異步通訊機制;

4. 系統功能需求

需要進行詳細的需求記錄，詳細列出與該系統功能相關的詳細功能需求，并且，唯一地標識每一項需求。這是必須提交給用戶的軟件功能，使得用戶可以使用所提供 的功能執行服務或者使用所指定的使用實例執行任務。描述軟件產品如何響應己知的出錯條件、非法輸入、非法動作。

如果每一項功能需求都能用一項，也只需要用一項測試用例就能進行驗證，那么就可以認為功能需求已經適當地進行描述了。如果某項功能需求找不到合適的測試用例，或者必須使用多項測試用例才能驗證，那么該項功能需求的描述必然存在某些問題。

功能需求是根據系統功能，即軟件產品所提供的主要服務來組織的。可以通過使用實例、運行模式、用戶類、對象類或者功能等級來組織這部分內容，也可以便用這些元素的組合。總而言之，必須選擇一種是讀者容易理解預期產品的組織方案。

用簡短的語句說明功能的名稱，例如：“4.1系統參數管理”。按照服務組織的順序，逐條闡述系統功能。無論說明的是何種功能，都應該針對該系統功能重復敘述4.1~ 4.3這三個部分。

可以通過各種方式來組織這一部分內容，例如采用：使用實例、運行模式、用戶類、對象類、功能等級等，也可以采用它們的組合。其最終目的是，讓讀者容易理解 即將開發的軟件產品。一般來說，每個使用實例都對應一個系統功能，因而按照使用實例來組織內容比較容易讓用戶理解。

對應一些被共享的獨立使用實例，可以定義一些公用系統功能。

必須特別注意的是，在2.2節“產品的功能”中描述的全部需求，以及它們的規格說明;必須在某個系統功能描述中有所反映，而且不應重復。

4.1 說明和優先級

對該系統功能進行簡短的說明，并且指出該系統功能的優先級是：高、中、還是低。需要的話，還可以包括對特定優先級部分的評價，例如：利益、損失、費用和風險，其相對優先等級可以從1(低)到9(高)。

4.2 激勵/響應序列

列出輸入激勵(用戶動作、來自外部設備的信號或者其它觸發)并且定義針對這——功能行為的系統響應序列，這些序列將與使用實例中相關的對話元素相對應。

描述激勵/響應序列時，不僅需要描述基本過程，而且應該描述可選(擴充)過程，包括例外(引起任務不能順序完成的情況稱為例外)。疏忽了可選過程，有可能影響軟件產品的功能;如果遺漏例外過程，則有可能會引發系統崩潰。

如果采用流程圖來描述激勵/響應序列，比較容易讓用戶理解。

4.3 輸入/輸出數據

列出輸入數據(用戶輸入、來自外部接口的輸入或者其它輸入)并且定義針對這些輸入數據的處理(計算)方法，以及相應地輸出數據，描述對應區別：輸入數據和輸出數據。

當有大量數據需要描述時，也可以分類描述數據，并且注明各項數據的輸入、輸出屬性。

對于每一項數據，均需要描述：

數據名稱;

實際含義;

數據類型;

數據格式;

數據約束;

對于復雜的處理方法，僅僅給出算法原理是不夠的，必須描述詳細的計算過程，并且列出每一步具體使用的實際算式;如果計算過程中涉及查表、判斷、迭代等處理方法，應該給出處理依據和相關數據。如果計算方法很簡單，也可以將其從略，不加描述。

5. 其它非功能需求

在這里列舉出所有非功能需求，主要包括可靠性、安全性、可維護性、可擴展性、可測試性等。

5.1 性能需求

闡述不同應用領域對軟件產品性能的需求，并且說明提出需求的原理或者依據，以幫助開發人員做出合理的設計選擇。盡可能詳細地描述性能需求，如果需要，可以針對每個功能需求或者特征分別陳述其性能需求。在這里確定：

相互合作的用戶數量;

系統支持的并發操作數量;

響應時間;

與實時系統的時間關系：

容量需求

存儲器;

磁盤空間;

數據庫中表的最大行數。

5.2 安全措施需求

詳盡陳述與軟件產品使用過程中可能發生的損失、破壞、危害相關的需求。定義必須采取的安全保護或動作，以及必須預防的潛在危險動作。明確軟件產品必須遵從的安全標準、策略、或規則。

5.3 安全性需求

詳盡陳述與系統安全性、完整性問題相關的需求，或者與個人隱私問題相關的需求。這些問題將會影響到軟件產品的使用，和軟件產品所創建或者使用的數據的保 護。定義用戶身份認證，或備授權需求。明確軟件產品必須滿足的安全性或者保密性策略。也可以通過稱為完整性的質量屬性來闡述這些需求。一個典型的軟件系統 安全需求范例如下：“每個用戶在第一次登錄后，必須更改他的系統預置登錄密碼，系統預置的登錄密碼不能重用。”

5.4 軟件質量屬性

詳盡陳述對客戶和開發人員至關重要的在軟件產品其它方面表現出來的質量功能。這些功能必須是確定的、定量的、在需要時是可以驗證的。至少也應該指明不同屬性的相對側重點，例如：易用性優于易學性，或者可移植性優于有效性。

5.5 業務規則

列舉出有關軟件產品的所有操作規則，例如：那些人在特定環境下可以進行何種操作。這些本身不是功能需求，但是他們可以暗示某些功能需求執行這些規則。一個 業務規則的范例如下：“進行達到或者超過10，000，00元人民幣的儲蓄業務時，必須通過附加的管理員認證。”

列舉業務規則時，可以根據規則的數量，選取合適的編目方式。

5.6 用戶文檔

列舉出將與軟件產品一同交付的用戶文檔，并且明確所有己知用戶文檔的交付格式或標準，例如：

安裝指南

紙質文檔，16開本;

用戶手冊

紙質文檔，16開本;

在線幫助

電子文檔，與軟件產品一同分發、配置;

使用教程電子文檔，與軟件產品一同分發、配置。

6. 詞匯表

列出本文件中用到的專業術語的定義，以及有關縮寫的定義(如有可能，列出相關的外文原詞)。為了便于非軟件專業或者非計算機專業人士閱讀軟件產品需求分析 報告，要求使用非軟件專業或者非計算機專業的術語描述軟件需求。所以這里所指的專業術語，是指業務層面上的專業術語，而不是軟件專業或者計算機專業的術 語。但是，對于無法回避的軟件專業或者計算機專業術語，也應該列入詞匯表并且加以準確定義。

7. 數據定義

數據定義是一個定義了應用程序中使用的所有數據元素和結構的共享文檔，其中對每個數據元素和結構都準確描述：含義、類型、數據大小、格式、計量單位、精度 以及取值范圍。數據定義的維護獨立于軟件需求規格說明，并且在軟件產品開發和維護的任何階段，均向風險承擔者開放。

如果為軟件開發項目創建一個獨立的數據定義，而不是為每一項特性描述有關的數據項，有利于避免冗余和不一致性。但是卻不利于多人協同編寫需求分析報告，容 易遺漏數據，也不方便閱讀。因此還是建議為每個特性描述有關的數據項，匯總數據項創建數據定義，再根據數據定義復核全部數據，使得它們的名稱和含義完全一 致。必須注意的是，為了避免二義性，在匯總數據項時應該根據數據項所代表的實際意義匯總，而不是根據數據項的名稱匯總。

在數據定義中，每個數據項除了有一個中文名稱外，還應該為它取一個簡短的英文名稱，該英文名稱應該符合命名規范，因為在軟件開發時將沿用該英文名稱。可以使用等號表示數據項，名稱寫在左邊，定義寫在右邊。常見數據項的描述方式如下：

原數據元素

一個原數據元素是不可分解的，可以將一個數量值賦給它。定義原數據元素必須確定其

含義、類型、數據大小、格式、計量單位、精度以及取值范圍。采用以星號為界的一行

注釋文本，描述原數據元素的定義。

選擇項

選擇項是一種只可以取有限離散值的特殊原數據元素，描述時一一枚舉這些值，并用方

括號括起來寫在原數據元素的定義前。在兩項離散值之間，使用管道符分隔。

組合項

組合項是一個數據結構或者記錄，其中包含了多個數據項。這些數據項可以是原數據元

素，也可以是組合數據項，各數據項之間用加號連接。其中每個數據項都必須是數據定

義中定義過的，結構中也可以包括其它結構，但是絕對不允許遞歸。如果數據結構中有

可選項，使用圓括號把該項括起來。

重復項

重復項是組合項的一種特例，其中有一項將有多個實例出現在數據結構中，使用花括號

把該項括起來。如果知道該項可能允許的范圍，就按“最小值：最大值”的形式寫在花

括號前。

8. 分析模型

這是一個可選部分，包括或涉及到相關的分析模型，例如：

數據流程圖;

類圖;

狀態轉換圖;

實體-關系圖。

數據庫需求分析報告范文2

關鍵詞：高校后勤 財務管理模式 信息化平臺

中圖分類號：G475 文獻標識碼：A

文章編號：1004-4914（2012）05-094-02

評價一個財務信息系統成功與否的關鍵在于這個系統是否完成預期的建設目標，是否給高校的后勤財務管理帶來效率和水平的真正提高。在財務信息化平臺的建設過程中，可充分利用高校應運而生并迅速發展起來的新的信息技術手段和現代化設備，進一步拓展財務管理信息系統的各項功能，向集高校后勤財務管理與信息化校園于一體的“一體化”管理方向邁進。因此，高校后勤財務信息化平臺應以賬務核算、預算管理、資金管理和項目管理等模塊建設為核心，結合校園一卡通系統，整合形成校園后勤管理的一整套業務流程。

一、后勤財務信息化的需求與系統管理目標的設計

（一）后勤財務信息化的需求分析

從高校后勤管理的實際出發，針對高校具體的財務管理狀況和管理目標進行調研，作出符合實際情況的后勤財務信息化需求分析和評價。對于要達到的既定目標，既要用發展的眼光又不能脫離現實條件，盡可能細化、量化好系統需求方案制定前的組織調研工作。

1.理清高校的管理體制和結構。高校的辦校規模不同，管理體制也不盡相同，無論是哪一方面的管理都要服務并服從于高校的整體管理，后勤財務信息系統要為學校的財務管理服務這一點無可厚非。部分高校多個校區，屬于多級次的管理體制。管理體制的差異影響財務信息系統組織機構的功能設置，并對實施方案中的軟硬件環境（諸如網絡環境、軟硬件設備的選擇、人員的配備和崗位的設置）等要求產生影響。因此，只有明確了整個財務管理的組織結構以后，才能對財務信息系統的建設作出既科學又實用的規劃和設計方案。

2.確定目標工作流程。完成系統需求分析后，要著手對后勤財務信息系統運行的整個工作流程進行分析和前景規劃。通過對后勤財務信息系統工作流程與現行的財務工作流程進行比較，如果兩個流程的差異很大，那么應該及時同財務主管領導做細致的溝通，分析可能出現的問題，杜絕可能出現的漏洞，確認目標工作流程的可操作性。為方便今后開展工作，經過反復研究論證后的最終工作流程的分析報告也需要得到財務主管領導的簽字認可，方能進行下一步的工作。

3.信息化平臺的目標定位。對于將要建設的后勤財務信息系統需要達到的目標應該有一個相對準確的描述和合理定位，包括這個系統要實現的功能目標和性能目標，以及為實現這樣的目標對整個系統要進行多大規模的資金和人力投入，怎樣投入等。整個系統建設周期的計劃是什么，階段性目標是什么，特別是如何進行對系統建設完工后的驗收、使用和評價等。

4.出具需求分析報告。通過前期各階段的準備工作，對系統的需求分析進行了論證調研得出結論后形成書面報告。需求分析報告將成為系統設計的依據和今后系統改造的基礎資料。

（二）設計信息管理系統的目標方案

詳細了解高校后勤財務管理狀況以后，作出對具體的財務管理需求的分析報告，設計制定目標方案。理論上，財務信息化的目標與財務管理的目標應該保持一致，但我們必須要考慮財務信息化的階段性發展問題這一客觀因素的存在。不同階段會面臨要解決不同的問題，不能一刀切的看待遇到的各種障礙性因素，更不能主觀期望從一開始就解決所有的財務管理問題，這種想法是不切實際的。在開始設計具體的實施方案前，對高校的財務管理狀況要有一個比較整體、客觀和細致的了解。要內外兼明，尤其是對于高校后勤現行的財務管理體制、上級部門的支持情況、部門內部的業務流程、人員配備和崗位設置情況，以及高校整體的信息化水平、軟硬件環境等做一個比較細致的調查。應當明確高校后勤目前最迫切需要解決的財務管理問題，通過信息化平臺建設能否解決這一問題，能否做到通過一定程度上制度的變革來為財務信息化掃清障礙，領導層是否做好了這方面的思想準備。因為，當我們決定開始啟動財務信息系統后，都會在一定程度上引發財務管理體制“地震”，因而需要事前做好方方面面的準備工作。

二、后勤財務信息管理系統的建設

根據已經確定的需求分析報告對后勤財務信息管理系統進行規劃、設計，制訂出具體的設計方案。設計方案的內容包括：系統的網絡環境要求、系統需要的硬件和軟件配置、財務信息系統軟件的選購、系統的運行維護、人員和崗位配置等，整合這些具體的設計方案就形成一個相對完整的后勤財務信息系統設計。

（一）硬件平臺的設計與構建

1.規劃和設計網絡環境。通常情況下，單一校區的高校后勤多采用集中式財務管理模式，規模較大的高校后勤則采用分級管理。規模較大且多個校區的高校比較適合采取分散布局、集中管理的模式。建設后勤財務信息管理系統時，不同的管理模式對網絡環境的要求也不一樣。在設計后勤財務管理信息系統建設的方案時，一般都會優先考慮財務網絡的建設方案。單一校區的高校，往往選擇物理上與其他網絡隔離的獨立的網絡環境，這樣的網絡環境安全系數比較高，缺點是與其他管理系統的數據共享和交換受限。規模較大且擁有多個校區的高校，在選擇后勤財務信息管理系統的網絡環境時，要考慮的因素就相對復雜得多。首先要考慮的是安全因素，其次要考慮到建設實施的成本問題。在校區間相距較遠的條件下，構建獨立的財務專用網絡會產生較高的成本，這樣建設難度就比較大。近些年來，高校的校園網絡建設和發展速度較快，絕大部分高校都擁有自己的校園網，這是發展的必然趨勢。所以，通過依托“校園網”建設“財務局域網”成為一種較好的解決方案。利用VNP技術，依托校園網搭建一個財務專網，成為一種較為現實可行的做法，因為這種做法不僅大大降低了建設成本，而且在技術上和安全性能上也有一定的保障。網絡布局方案設計完成后，還應考慮網絡環境建設需要的網絡設備條件。網絡設備的挑選通常按性能價格比的原則，在建設資金保障充分的前提下，可選擇穩定性好、質量高的產品。

2.服務器及周邊設備的選型與配置。服務器的選擇非常重要，在選擇前要先咨詢這方面的專家。系統的應用規模和發展趨勢是選擇服務器種類的重要考量因素。同時要考慮到發展的需要，適當留有冗余。服務器工作環境要得到保障，條件允許的情況下，服務器最好設在通風、散熱條件好、環境整潔的獨立機房內。

（二）軟件平臺的建設

1.操作系統軟件的配置。當前應用較廣的操作系統有Linux、Unix、WindowsServer系列等等。高校在建信息系統的軟件平臺時，常會選擇一種作為主要的操作系統軟件。不過，也有混用的情況，如果從管理便捷性方面考慮，多種操作系統并用的情況往往會出現系統不兼容的現象，因此不利于管理。

2.選擇數據庫系統軟件。數據庫系統軟件在很大程度上直接影響到系統處理財務信息的效率和質量。目前常用的數據庫軟件有SQLServer、Informix、Oraele、MySQL等，這些數據庫軟件在性能方面各有各的特點。不同操作系統對軟件功能要求也有所不同。在建設財務信息化平臺之前，要根據后勤財務管理的要求，同時考慮其他管理系統的需求，以便選擇更適合后勤財務管理的數據庫軟件系統。

3.選擇財務管理系統軟件。在選擇財務管理系統軟件時要考量多方面的因素，軟件應用的核心問題是它的配置。財務管理軟件系統是整個財務信息系統運行的載體。財務管理軟件取得的途徑有兩種：一是購買，另外一種是自行開發。在后勤財務信息化平臺建設過程中，高校后勤財務管理系統軟件的規劃與選擇是核心工作，一方面要考察財務管理系統軟件在功能上是否能夠滿足高校后勤財務管理的需要，另一方面還要考慮自身的個性化需求。現在絕大多數高校都采用直接購買的方式取得軟件，因為，這種方式的建設周期可以大大縮短，而且沒有開發風險，系統運行也會比較穩定。但是，這種商品化軟件通常都是通用軟件，很可能存在短時間內無法滿足單位的個性化需求的問題。

三、財務信息化平臺的實施

（一）硬件平臺的運行

系統硬件平臺能夠穩定的運行取決于很多因素，包括服務器及其配套設備、網絡設備、備用電源供給、客戶端設備配置等。硬件平臺系統運行的穩定性、數據的安全保障是首要和重點考慮因素。財務信息系統因其功能的特殊性，在硬件設備配置的選擇方面要求相對較高。首先做好網絡設備的暗轉與調試，其次做好服務器及周邊硬件設備的安裝與調試。

（二）軟件平臺的運行

要保證軟件平臺的正常運行，首先要做好操作系統軟件和數據庫軟件的安裝工作，然后進行財務管理軟件系統的安裝和調試。這時應注意確定財務管理信息子系統的使用規模和順序。通常高校后勤在安裝使用新系統過程中，首先要保證歷史工作的正常運轉和延續，因而會比較謹慎地選擇一個或者幾個有把握的子系統進行試運行，待穩定運行一個階段后再使用其他子系統。當然，也有高校采用新舊系統同時運行一段時間的方法。各高校可根據自身的實際情況進行選擇。另外，財務軟件的初始化工作也是非常關鍵的環節之一。系統初始化的工作不僅重要，而且工作量也很大。為了保證財務信息系統安全、穩定地運行，同時還要在服務器和客戶端上一并安裝防病毒軟件、數據備份軟件等。

［基金項目：黑龍江省教育會計學會科研課題，編號：1155KJXH402；黑龍江省人文社會科學研究項目，編號:11552175］

參考文獻：

1.肖富寧.高校財務信息化建設若干問題的探討.首都經濟貿易大學碩士論文，2009

2.許永斌.我國電算化會計信息系統模型改造理論基礎.會計研究，1996

3.薛云奎，饒艷超.會計信息系統(第二版).復旦大學出版社，2008

4.于金紅.稅務會計應用的障礙性因素及發展思路研究.財會研究，2011（12）

5.王海林.試論會計信息系統運行階段的風險與控制.會計之友，2009（1）

6.鄒秀華.高校財務管理信息化建設研究.中國科技信息，2008（3）

數據庫需求分析報告范文3

與傳統的教學方式相比，項目教學對教師能力提出了更高的要求，其中最核心的要求是教師要科學地選擇好課程項目內容，并具有課程項目開發和管理的實踐經驗。而目前職校的計算機教師基本上接受的都是學歷性教育，雖然他們理論功底較扎實，也掌握了一定的教學方法和技巧，但是站在講臺上絕大多數還處于以理論解釋理論的“紙上談兵”狀態。試想一個沒有親身經歷項目系統開發的人，怎能能夠“以就業為導向”、“以項目為主線”來開展好項目教學呢？

以能力為本位，設置項目

為了達到項目教學對教師提出的新要求，提高計算機專業項目教學的能力，作為計算機教研組的負責人，我利用學校學生信息管理要實現信息化的契機，帶領計算機教研組的相關教師，深入軟件公司進行實地考察和學習。

首先了解公司的實際用人需求、對員工的培養模式、軟件開發的實際流程，對比出我們教學的不足與差距，探索出項目教學的目標，人才培養的方案；其次，聯系學校的實際需求，與公司合作，將課程開發項目定位為既滿足學校的應用需求，又滿足教學需求的《學生信息管理系統》。

通過市場調研，教師親自接觸了用人市場，明確了學生的就業需求，教學中就能夠以學生能力為本位，實現了人才培養與上崗就業“零距離”接軌的教學培養目標。

以市場為中心，分析項目

結合在軟件公司的實地考察學習經驗，在設計人員的指導下，按照公司項目開發的實際工作流程，我們首先編制了本課程項目的開發流程:需求分析方案設計系統設計項目實施調試運行。

從流程中可以看出，需求分析是項目開發和管理的基礎。在項目開發中，所有的項目風險承擔者對需求分析階段都倍感興趣。因為這部分工作做的到位，就易于開發出很優秀的軟件產品，同時也會令客戶滿意；若處理不好，則會導致誤解、挫折、障礙以及潛在的質量和業務價值上的威脅。

這部分工作有一定的難度，客戶多數情況下只能說明整個項目的概念和目標。這些高層次的業務需求不足以提供開發的具體內容和時間，它要求項目開發人員在工作中要采用科學的方法和一定的技巧。

學生沒有接觸過市場和客戶，這就需要教師在教學中將這方面的感受和經驗傳授給學生，因此教師首先要有接觸市場的真實體會，并總結出方法和技巧。

按照這種思路，通過對學生科、教務科、班主任和任課教師等重要用戶的反復調研，明確了用戶的功能需求，建立了《學生信息管理系統》的系統用例圖。

經過客戶需求的調研，制作和反復修改需求分析報告，使得教師積累了市場經驗。在日后的教學中，他們可以用實踐經歷向學生講述軟件開發需求調研的全部過程，需求分析在軟件開發中的重要地位；同時把停留在書本上的理論化的職業道德轉化為具體的道德實踐，為學生形成良好的職業道德和規范化職業行為樹立典范。這些是書本上永遠學不到的知識

以就業為導向，實施項目

職業學校計算機數據庫教學培養的人才就業方向為：了解數據庫應用項目的開發流程，能夠從事項目的初級編碼或開發、軟件調試及技術服務與軟件銷售等工作的專業人員。

初到崗位就業的畢業學生，基本上都是在設計人員設計思路指導下，展開項目的開發和編碼工作，那么在學校的教學中，教師就要充當設計指導人員的角色。因此，要求教師具有數據庫設計、實施的實踐經驗和科學的指導思想。在項目設計和實施的環節，就是以學生的這種就業需求為導向，來錘煉教師的設計思想，豐富項目實施經驗。

在項目設計環節，首先教師通過學習軟件設計理論，參考公司的典型案例，按照系統的功能需求分析，設計了《學生信息管理系統》的軟件結構層次圖；其次教師在認真分析本項目的數據要求的基礎上，編制了系統的E-R圖，并實現了E-R圖向關系模型的轉換。

通過數據庫的設計，使項目開發的教師對規范、實體、屬性、關系、字段等數據庫概念有了進一步的理解，并使E-R、E-R到關系模型轉換原則等難度大的理論在實踐中得到了充分應用。

在項目實施環節，通過數據庫建立、界面設計、代碼編寫和程序測試等幾個階段，

使得教師進一步在深度和廣度上拓展了專業理論，掌握了所學專業、所任課程較為系統完整并具有前沿性的專業知識；強化了專業實踐能力，錘煉了教師的設計思想，豐富了項目實施經驗，提升教師解決特定問題的能力；進而促使教師根據職業教育的特征要求，進行有效的專業知識的整合優化與適度轉化，形成滿足學生專業實踐能力培養所需的知識結構，更好地把握了以學生的就業需求為導向的教學原則。

以學生為主體，應用項目

《學生信息管理系統》開發的最終目的，一方面是成為真正的應用產品，實現了學校學生信息管理的信息化。軟件在全校的使用提升了教師在學生中的威望，同時也擴大了該項目在學生中的影響力，激發了學生的學習積極性。

另一方面應用該課程項目，按照六個教學環節：分析任務確定項目分組討論制訂計劃知識儲備項目準備自主探索項目實施項目展示成果分享結果提交項目評價，“以項目為主線、教師為主導、學生為主體”， 就可以開展具體的數據庫項目教學工作了。

通過教學經驗的積累，教師探索出了項目教學的基本規律和教學技巧，順利地實現了教學中師生角色的重新定位；同時原有的教材已無法滿足所開發課程項目的教學，它引導教師在對原有教材進行整合的基礎上，逐步進行數據庫項目教學校本教材的開發。

教師通過科學地選擇項目，直接參與課程項目的設置、分析、實施和應用，有效地提高了自身的項目教學能力，促進了數據庫課程的教學改革與發展，實現人才培養與上崗就業“零距離”接軌的教學培養目標。

參考文獻

數據庫需求分析報告范文4

【關鍵詞】計算思維；教學改革；數據庫；PBL教學方法

2006年3月，美國卡內基·梅隆大學計算機科學系主任周以真（Jeannette M.Wing）教授在美國計算機權威期刊《Communications of the ACM》雜志上發表的《Computational Thinking》一文中定義了計算思維（Comp-utational Thinking）的概念，即計算思維是運用計算機科學的基礎概念進行問題求解、系統設計以及人類行為理解等涵蓋計算機科學之廣度的一系列思維活動。計算思維是每個人的基本技能，不僅僅屬于計算機科學家。

1.引言

醫學生學習任務繁重，理工基礎相對薄弱，記憶式學習占主導地位。醫學院校傳統的《數據庫基礎》教學往往采取“以教師為主導”的教學模式，即“教師講什么，學生學什么，考試考什么”的灌輸式的教學，學生的學習思維始終被教師牽制。教師單純注重知識鏈條的系統性和完整性，力圖做到把知識點“講全講細”，忽略了醫學生的自身特點，沒有將數據庫知識與醫學生所學專業有機的結合起來，沒有將計算思維的本質即抽象（Abstraction）和自動化（Automation）的思想有效的灌輸給學生，造成醫學生的學習興趣普遍不高，教學效果不甚理想。

為了改變這種落后的教學局面，對原有的教學模式重新進行了規劃和設計，從培養興趣出發，結合醫學專業特色，采用PBL教學方法和任務驅動等教學方法，將科學的邏輯思辨能力和計算思維融入課堂教學環節，大幅提升了教學效果。

2.教學改革的實施過程

（1）教學分組

為了驗證教學改革是否有效，將教授的法醫學專業學生分成2組（每組30人），一組采用基于計算思維的教學模式進行教學（以下簡稱組一教學），另一組采用基于非計算思維的教學模式進行教學（即傳統的教學模式，以下簡稱組二教學）。

（2）項目選題與實施

在組一教學中，打破傳統的教學模式，從上課伊始就要求學生結合法醫專業特點，自主選題，利用Visual FoxPro 6.0數據庫程序開發與法醫學應用相關的信息管理系統。由學生自愿組成5-6人的開發小組，由組長帶領組員到學校的司法鑒定中心和法醫學院各個教研室進行調研，設計需求分析報告，再根據需求分析報告進行模塊分工，每個同學至少完成1個模塊的編程任務，項目的開發周期貫穿整個學期。

在教學理念上，教師由傳統的“主導教學”轉變成“引導教學”，采用PBL教學方法（Problem-based learning，即以問題為導向的教學方法），激發學生的興趣和自主創新意識，在課堂上大量采用討論甚至爭論的形式就開發過程中遇到的問題進行比較和分析，逐步完善解決方案。教師僅在設計的關鍵點上進行核心語句的講解，把開發自完全下放給學生，著力培養學生自主學習能力及抽象和自動化的計算思維。比如有同學建議將尸檢信息，如身高、體重、體形、膚色、尸斑大小、尸斑位置、死亡地點等信息抽象成二維表便于信息的處理。再如在死亡時間的推斷問題上，多數同學都是根據尸體特征推測死亡時間的，有的同學提出還可以根據蠅蛆的生活史推斷死亡時間，進而有的同學指出死亡時間的推斷還應該考慮環境溫度的影響。經過一學期的實踐，同學們相繼開發出諸如《法醫毒物分析管理軟件》、《法醫尸檢信息管理系統》《法醫傷檢圖像分析系統》等具有一定應用價值的信息系統。

在組二教學中，采用傳統的教學方式，在學期結束前3周由教師統一布置《住院信息管理系統》的開發項目，將學生以5-6人為規模進行分組，指定組長，采取組長負責制，由組長負責子模塊的劃分，組員獨立完成子模塊的設計，完成整個項目系統的開發工作。

在教學理念上，教師采用“以教師為中心”的教學思想，以知識點分布為主線，嚴格依照教材章節的順序，從數據庫基礎知識開始講解各個章節的內容，把每個重點難點講懂講透，尤其在程序設計的三種循環結構和表單控件內容上花費了大量的時間，反復向學生灌輸程序設計思想。由于學時有限，課堂教學以經典案例教學為主，提問為輔。每章結束后，布置相應的作業，要求同學以實驗報告的形式上交給教師進行評閱。

（3）教學改革評價

在學期結束后向學生就教學改革中所涉及的8個方面進行了認可程度的問卷調查（見表1），發放60份，收回有效問卷58份。對所收集到的數據進行t檢驗的成對二樣本統計分析，其P

3.討論

自從周以真教授第一次清晰系統地描述計算思維概念以來，計算思維的概念得到國內外計算機同行的廣泛關注和支持。計算思維是一種由知識轉化為能力，再由能力遞進為思維的一種高級思維活動。通過對《數據庫基礎》教學重新規劃和組織，將計算思維融入課堂教學，使學生思考問題的廣度和深度都有了較大的提高，獨立分析問題、解決問題的能力得到很大的提升。和傳統的教學方法相比，基于計算思維的教學模式取得了更好的效果。

但由于計算思維本身的抽象性和高度概括性，如何理解計算思維的本質和內涵，如何確定計算思維的內容和體系，如何著手培養學生的計算思維等，還需要廣大計算機教育工作者繼續深入的探索。

參考文獻

[1]董榮勝.計算思維與計算機導論[J].計算機科學，2009 （4）：50-53.

[2]董榮勝，古天龍.計算思維與計算機方法論[J].計算機科學，2009，36（1）：1.

[3]周以真.計算思維[J].中國計算機學會通訊，2007，3（11）.

[4]宋曉榮，姬明麗，司艷莉，劉友才.研討式教學法在機能學綜合實驗教學中的應用[J].新鄉醫學院學報，2011，28 （3）：399-400.

[5]陳杰華，戴麗娟.以培養計算思維為核心的程序設計實驗教學[J].實驗技術與管理，2011，28（1）：125-127.

[6]廖偉志，李文敬，王汝涼.計算思維在離散數學課堂教學中的應用[J].計算機科學，2008（（11）.

[7]王榮良.信息技術課程中算法學習的價值探索[J].中國電化教育，2008（8）：78-81.

[8]薩師煊，王珊.數據庫系統概論[M].北京：高等教育出版社，2006.

[9]朱立平，林忐英.基于思維教學理論的程序設計課程教學模式的構建[J].計算機教育，2008（8）.

數據庫需求分析報告范文5

關鍵詞：航空；安全；設計

中圖分類號：G350 文獻識別碼：A 文章編號：1001-828X（2016）028-0000-01

一、航空安全是近年來國家和社會普遍關注的一個問題，其中任何一個環節的缺失都可能造成不安全事件的發生，由于航空行業的特殊性，一旦發生航空事故就是很嚴重的事故，將給社會和家庭帶來巨大的影響，因此航空安全需要做到準確、穩定、可靠。針對目前航空安全管理中業務處理的需求，采用了軟件工程的設計思想，設計并實現了航空安全管理系統，對飛行管理的每一個階段進行了流程化的管理，通過航空安全培訓模塊、風險管理模塊、飛行管理模塊、維護管理模塊完成對整個航空安全的管理，實現了實時、準確的航空管理，同時采用了大數據分析技術提高了安全問題分析的可靠性和準確性。

1.登錄功能：系統中采用了ajax技術實現對驗證碼的處理，通過對驗證碼進行局部刷新，保證了頁面的穩定效果，用戶進行手動驗證碼刷新，或有軟件進行驗證碼刷新都保持了整體頁面的無閃動效果。

2.航空安全培訓模塊：在本功能中主要是通過web頁面提供封裝的前臺信息，系統服務對這些信息進行處理和存儲，服務在業務處理完成后將生成相應的數據存儲在數據庫中，用戶通過頁面能夠查詢或瀏覽到計劃信息。通過設計培訓更新、查詢等服務對數據庫中的培訓記錄進行訪問，提高了訪問的效率和安全性。在本系統中設計了各種考核頁面，用戶可以通過在頁面中指定培訓id，系統將根據培訓的內容生成考核的內容，用戶通過考試頁面完成考核內容的填寫，提交給系統進行保存，考核部門給出考核評價意見。

3.風險管理模塊：風險采集，該功能完成對指定位置信息的采集和由人工進行風險提供的工作，本功能設計風險設備管理和風險設備參數設定功能，通過該功能使用者能夠對風險設備的信息進行查詢和管理。風險評估，在本功能中提供了風險評估方法和參數的調整功能，對不同的類型風險進行評估時所采用的評估方法是不同的，因此在頁面中提供了風險評估方法的定義和修改。風險決策，在本功能中為了能夠使決策具有合理性，系統提供了多個人員對風險決策進行評閱的功能，在頁面中提供了多人決策的內容，不同的人員可以對統一風險進行決策，同時在系統生成決策報告時，必須由多個決策人員都填寫意見后才能生效。

4.飛行管理模塊：該模塊完成對飛行前的檢查工作，在本模塊中設計了多個檢查流程，該流程的作用是完成對飛行準備工作的核查，任何一項核查沒有通過都不能進行實施。飛行實施模塊，該模塊完成飛行過程的記錄工作，其中包括對飛行航線、飛行參數、飛行通信信息的記錄工作，同時為了能夠方便用戶實施跟蹤飛機的飛行軌跡，通過調用GPS數據在頁面上進行實時軌跡顯示。

5.維護管理模塊：日常維護功能，完成維護計劃的指定和維護計劃的執行，由于日常維護是常規性的工作，所以在本功能中提供了日常維護計劃模板，通過模板可以方便快捷的實現維護計劃的生成。維護信息管理功能，該功能完成對維護工作的相關信息的統一管理，其中設計了設備信息管理、維護作業信息管理等功能。

二、航空安全是航空企業生產的重點，由于航空安全貫穿了生產過程，因此在目前的航空企業管理中，存在信息系統結構簡單、兼容性差的問題，在不同的部門間存在信息難以交流，工作重復開展的問題，給航空企業帶來了資源、人力、物力的浪費。

為了解決航空企業安全管理中存在的問題，在信息化建設的基礎上，對本企業航空安全管理工作進行系統化的調研、分析和論證，最終結合軟件系統的開發經驗設計并實現了航空安全管理系統，實現了對航空企業安全管理工作的統一化、信息化和智能化，提高了企業管理的效率和質量，同時為企業信息化提供了一條新的建設思路。

1.完成了航空安全管理工作的需求分析和項目建設的可行性分析，首先通過在本企業的系統化調研，對企業中安全管理工作進行了梳理和整合，形成了具有權威性的需求分析報告，依據需求分析內容對軟件系統開發的經濟、技術的投入進行了論證和分析，證實了航空安全管理系統建設具有必要性和可行性。

2.完成了航空安全管理系統的總體結構的設計，根據航空安全系統的需求分析和軟件設計的規范，設計了安全管理系統的總體結構，規范了數據庫設計的方法和軟件開發方法，并完成了數據庫結構的設計。確定軟件開發采用JAVA語言、B/S結構，數據庫管理系統采用oracle數據庫。

3.完成了航空安全管理系統的具體功能的設計與實現，根據軟件的總體設計規劃，對飛行管理子系統、風險管理子系統、安全培訓子系統和維護管理子系統具體功能進行了編碼和實現，在WEB開發中采用了S2SH架構。

4.完成了航空安全管理系統的測試工作，依據軟件測試規范和系統的需求分析設計了科學合理的測試方案，采用了人工和工具測試相結合的方法，從模塊、集成、系統三個階段完成了測試工作，證實了航空安全管理系統具有功能全面性，性能穩定性，滿足了航空企業進行信息化安全管理的需求。

三、航空安全管理工作是一項長期存在的工作，從其業務的范圍呈現逐步擴大的趨勢，所以在航空企業中，安全管理將成為工作的重點，結合國外航空安全管理系統的實例和軟件技術發展的趨勢，本項目的研究未來具有以下趨勢：

1.充分結合物聯網技術，通過物聯網技術實現大量人工操作到傳感器的轉移，人工工作逐步向管理轉移。

2.未來的發展將webgis技術進行很好的應用，對于企業安全管理將采用基于可視化的webgis技術。

3.大數據技術將被應用于航空企業信息的分析和管理，通過大數據技術實現對數據的可靠、可信、高效的管理。

參考文獻：

[1]詹敏，孟予希.航空安全信息管理與決策輔助系統框架研究[J].科技促進發展.2012，（03）

[2]田波，吳倩，甄浩.航空公司信息安全管理系統的構建與安全保障體系研究[J].情報科學.2011，（09）

[3]朱雪飛.航空公司安全管理系統（SMS）項目的建設與應用研究[D]. 山東大學 2013

[4]LI Feng， LIU Xiao-jie， LIN Han-he. Tolerant system based on Oracle[J]. Computer Engineering and Design，2011（11）

數據庫需求分析報告范文6

創新型和創業型人才的培養是當前推進高校教育教學改革的重點。軟件工程專業是近年來就業比較熱門的專業之一。《軟件工程導論》課程是該專業非常重要的一門專業基礎課程，也是軟件開發系列課程的基礎。針對當前該門課程在教學中存在的問題，并結合當前各高校開展的應用型轉型的發展目標，文章提出基于項目的實踐訓練的授課形式的教學模式，以進一步改善軟件工程專業人才培養的效果。

關鍵詞：

應用型；基于項目；實踐訓練；答辯考核

隨著我國高等教育改革的進一步深化，由教育部提出針對在校大學生的創新型人才和創業型人才的培養正逐漸成為應用型院校轉型的目標。那么如何讓在校大學生具備軟件項目開發的技能和知識也是軟件工程專業的培養目標之一。培養學生軟件開發的應用能力已經成為軟件工程專業的人才培養的首要目標。[1]《軟件工程導論》課程的教學任務也由原來軟件開發理論知識的講授轉變為軟件開發基本技能和文檔撰寫能力的訓練和培養，通過學習這門課使學生能夠了解軟件開發的流程，并且知道在開發的過程中每個階段都做什么和怎么去做，讓學生能夠直接進入到項目組里，參與軟件項目開發。這樣改革的好處是多樣的：1.這樣除了對學生應用能力進行了培養，而且讓學生對軟件項目的了解進一步加深，后續為以后的其它專業課的學習也打下了基礎；2.在同步開設的其他課程中，進行橫向聯合，讓學生都針對同一項目進行訓練，讓學生能夠學有所用，大大提高了學習興趣和積極性；3.對各門專業課的教學內容和方式都有所觸動，促進了教學改革的深入。目前，國內各個高校的軟件專業中都開設有《軟件工程導論》這門課。多數學校還是當作一門專業基礎理論課來講授，這樣的學校大多是研究型大學，學生基礎比較扎實，對枯燥的理論可以接受，但是只學理論沒有實踐造成的后果是學完就忘，學生只會答題；還有一些學校對《軟件工程導論》課程進行了一些改革，比如將理論基于一種開發環境的軟件開發，試圖將理論和實踐相結合，但是多數是面向對象開發方式，理論多實踐少，落到實際課堂教學上還是教師說的多，學生做的少，對學生實踐能力培養并沒有多大的改變。對課程的教學改革主要包括教學內容的改革，教學方式方法的改革，考核方法的改革。

一、教學內容的改革

目前《軟件工程導論》課程的教學內容包括：軟件開發基礎知識，需求分析，總體設計、詳細設計、編碼、測試[2]、項目管理這些內容，采用的是結構化的軟件開發方法。之前我們只講理論知識，特別是開發過程中的一些技術和軟件，但是學生學完即使會做題也不會開發項目。現在，我們將教師實際參與開發的項目帶領學生從需求開始分析，進行總體設計和詳細設計加入到授課內容中，結合實際的項目開發的內容，把理論和實踐相結合。學生邊學理論知識，邊完成自己的項目，可以將學到的知識應用到項目中，做到學有所用。希望培養學生整體軟件開發的方法、軟件項目管理能力、軟件需求分析能力、數據庫設計能力、人機交互設計能力、軟件測試計劃及方案的制定能力、課程報告撰寫能力、學習態度等各方面能力。

二、教學方式方法的改革

《軟件工程導論》是一門理論課，多數是在多媒體教室由教師講授為主進行授課。現在，在開課之初，我們要求每個學生申報一個題目，整個學習過程中學到哪個階段，學生就自己去完成所申報題目的該階段的任務，這樣課堂上老師講怎么開發軟件，在課下布置了大量的階段性文檔要求學生去完成，而且各個階段所采用的方法也不同，隨著各階段任務的完成，學生也體會到了項目開發的過程、方法。為了保證學生提交的階段文檔的質量和保證學生的項目能夠順利進行，我們將階段評審添加到了教學過程中。學生需要提交的階段任務文檔有：《軟件需求規格說明書》、《軟件概要設計說明書》、《軟件測試報告》和《課程綜合報告》。其中《課程綜合報告》中要求按照畢業論文的格式要求去排版和完成，希望同學們通過這樣的訓練能夠在畢業設計中取得較好的效果和成績。在教學改革時我們還嘗試著和同時開設的《數據庫原理與應用》、《面向對象程序設計》等課聯合起來，分別針對同一題目進行階段訓練，在最終答辯的時候由三門課的老師同時參與答辯，答辯成績被記入到三門課的最終成績里，比如《數據庫原理與應用》課學習如何設計數據庫就應用在了《軟件工程導論》課的總體設計階段，學生需要畫出E-R圖，給出主要表結構；《面向對象程序設計》課最終就是根據《軟件工程導論課》分析和設計的結果用JAVA語言開發出一個小項目，這樣學生不僅寫出了階段文檔，最終還能做出一個實際的項目，增加了完整性和學習積極性。

三、考核方法的改革

原來我們都是采用試卷考核的方式，但是試卷考核只能考察學生的知識掌握能力，并不能考核學生的實踐應用能力，而我們希望通過這門課程讓學生具備一定的軟件開發實踐能力，所以由試卷考核改為答辯考核和平時階段性評審。[3]這也要求在開課之初就制定出比較詳細和全面的考核方案，我們的考核方案從課程報告、答辯平時表現這三大方面出發進行考核。而且，在課程報告提交時，我們有統一的文檔格式和內容要求，包括需求分析報告，概要設計報告、測試報告、課程設計報告，在平時授課階段就需要提交上來；而答辯時，將學生答辯的項目原型與學生之前提交的需求、設計進行對應，審核是否是按照需求和設計進行的開發；而且在近幾次的答辯中，我們將答辯所占的比重逐步增加，這樣可以看出學生的表達能力、思維能力、項目綜合運用能力的高低。《軟件工程導論》課程改革的目標就是希望將枯燥、抽象的理論課變成充滿趣味和挑戰的實訓課，讓學生通過本課程學習能夠知道項目開發各階段的工作內容，且能夠開發一個簡單的項目，避免在畢業設計時犯一些軟件開發的常識性錯誤，比如項目開發流程弄錯，如何進行分析和設計等等。同時為了提高學生的創新能力，讓學生自己申報題目，從需求分析到最終分析設計結束都需要學生自己動手來做，通過學習軟件工程思想和方法去完成軟件開發過程，可以調動學生的主觀能動性，真正做到獨立思考，能夠激發學生的潛能和創新性，為創新型和應用型人才的培養打下堅實的基礎。

作者：蘇丹 鄒紅 崔曉微 仲曉慶 馬英瑞 單位：大慶師范學院

參考文獻

[1]王菁華.地方高校向應用型轉型必須實現三個根本轉變[J].職業教育，2016.