立項

目錄

• 輔助教學系統立項說明書
  • 1. 概述
    • 1.1. 項目要求
    • 1.2. 術語
  • 2. 可行性
    • 2.1. 可行性研究的前提
    • 2.2. 複查系統規模和目標
    • 2.3. 研究正在使用的系統
    • 2.5. 進一步定義問題
    • 2.6. 導出和評價供選擇的解法
    • 2.7. 推薦行動方案
    • 2.8. 草擬開發計劃
    • 2.10. 技術選型
    • 2.11. 過程模型選擇
  • 3. 團隊成員
  • 4. 分工
    • 4.1. 工做分解結構(WBS)的編制
    • 4.2. PERT時間估算
    • 4.3. 具體分工
  • 5. 質量保障
    • 5.1. 質量管理流程
    • 5.2. 項目質量評審
    • 5.3. 質量檢查和確認技術
    • 5.4. 標準和約定

輔助教學系統立項說明書

目錄：

修訂歷史：

日期	版本號	做者	說明
2016-03-23	v1.0	衛重波 楊柳	最第一版本
2016-04-14	v2.0	衛重波	按照立項說明書模板進行增刪修改

1. 概述

PCAE^([1])的開發是爲了利用我的計算機來幫助師生進行做業管理、相互學習和交流。目前，輔助教學類的軟件已有不少，可是適用於單個老師和少許學生的輔助教學系統卻很難找到。所以，此項目旨在開發出一個簡單、高效、實用的我的計算機輔助教學系統，該系統能上傳和發佈老師的做業、想法，學生們也能提交做業、查看做業榜、相互評論，老師能夠對做業進行評論、打分和統計。

1.1. 項目要求

1. 本系統是一個「我的」計算機輔助教學系統，爲一個老師和其約百人規模的學生服務。
   
2. 能系統化的管理做業、項目、想法教學資源。
   
3. 主要功能有：
   • 老師：發點PPT、想法、文章、做業、評論、打分、統計
     
   • 學生：提交做業、看做業排行榜、評論
     
4. 操做方便。簡單，實用，不支持多位老師共享平臺，不支持鏈入教務系統等。
5. 併發數100以上。
6. 須要完整的權限控制，防止惡意攻擊系統，修改數據的行爲。
7. 對數據庫中的數據定時備份，防止數據丟失。
8. 完成期限爲2016-04-21日。

1.2. 術語

[1] PCAE： 我的計算機輔助教學系統
[2] QA： 質量保證

2. 可行性

2.1. 可行性研究的前提

2.1.1. 要求

1. 功能：本教學輔助系統主要功能有教師、學生的信息化管理、課程信息獲取及資源共享。
   
2. 性能：本系統面對的使用者數量較小，併發性要求在100左右；設置必要的安全防範措施，以避免數據被惡意修改；簡潔易懂的交互界面。
   
3. 輸出：在資源共享部分學生下載課程信息中的課件文件，支持各類已上傳類型的文件下載。
   
4. 輸入：教師信息，由教師自行註冊和管理；學生信息、課程信息，由後臺管理員進行新增管理的操做；課件：由授課教師進行上傳，數據類型與課件的實際類型爲準。

2.1.2. 目標

1. 提升信息資源利用，減小人力與設備；
   
2. 不須要拷課件，提升教學效率；
   
3. 對教學管理系統的改進；
   
4. 管理信息服務的改進；

2.1.3. 條件、假定和限制

1. 系統的運行壽命的很多於3年；
2. 經費、投資方面的來源和限制；
3. 提示免責聲明，本系統對使用過程當中的違法犯罪行爲不負法律責任；
4. 普通PC電腦，有WEB瀏覽器，WINDOWS XP/7及以上系統版本，開發環境爲MyEclipse和 Mysql；
5. 系統投入使用時間爲2016年4月24日

2.2. 複查系統規模和目標

1. 實現一個供一個老師和百餘名學生使用的PCAE。
2. 併發數100以上。
3. 系統須要操做方便。簡單且實用。
4. 提供上傳、下載文件，數據統計、評論等功能。
5. 安全性要求，防止惡意攻擊和數據的篡改、丟失。
6. 系統須要練好的災難恢復機制。
7. 完成期限爲2016-04-21日。

2.3. 研究正在使用的系統

2.3.1. 流程簡介

1. 教師經過博客發佈題目。
2. 學生經過關注教師博客動態得到題目，並發表文章做答，以回覆的方式將連接提交。
3. 教師給學生打分，並藉助 Excel 表存儲和統計分數。

2.3.2. 存在的主要問題

1. 博客是一個開放的平臺，但也許教師並不但願向外部公開教學詳情或者一些教學資源。
2. 若是須要上傳下載附件，又須要藉助其餘平臺。
3. 沒法系統的管理和方便的查找教學資源。
4. 用 Excel 表計分、統計很複雜。
5. 沒法保證 Excal 中數據的安全性。

2.4. 新系統的高層邏輯模型

用數據流圖來表示新系統的邏輯模型：

• PCAE 頂層DFD 圖
  
  
  
  
• PCAE 第二層DFD 圖
  

2.5. 進一步定義問題

新系統的邏輯模型已經基本知足用戶需求，通過分析員和用戶對 DFD 圖的複審，發現：
1. 以上設計中缺乏用戶身份校驗模塊
2. 未考慮數據的安全性問題
咱們將在第三層 DFD 圖設計中，在以上四大模塊中加入相應的校驗和數據保護功能。

2.6. 導出和評價供選擇的解法

2.6.1 方案一

• 擬建系統的目標
  • 管理一個科目的做業及資料文件
  • 教師上傳與共享資源
  • 加快信息的查詢速度和準確性
  • 簡介的交互界面
  • 併發性知足約50人同時使用
  • 保證數據安全
• 初步方案
  • 採用B/S結構，客戶端電腦經過瀏覽網頁的形式與系統進行交互。
  • 教師發佈做業與資料，以公告的形式推送給學生。
  • 使用MySQL數據庫管理全部的資源信息。
  • 使用 Struts 框架與 JSP 技術實現。

2.6.2 方案二

• 擬建系統的目標
  • 管理多個科目的做業及資料文件
  • 加強資源共享
  • 加快信息的查詢速度和準確性
  • 人性化的交互界面
  • 高併發
• 初步方案
  • 採用B/S結構，客戶端電腦經過瀏覽網頁的形式與系統進行交互。
  • 學生與老師之間能夠進行相似 QQ 空間留言板方式的交流與溝通，符合當前建設信息化校園的理念。
  • 性能上，用比較高性能的服務器和數據庫，加強其計算和併發能力
  • 輸入輸出方面，使用算法在 jsp 視圖層上給管理員提供對系統的操做和維護、爲教師留下上傳接口，給課程配備相關的屬性實現下載。
  • 使用 Struts 2框架與 JSP 技術實現。

2.7. 推薦行動方案

2.7.1. 方案描述

1. 在方案一的基礎之上：
   • 使用某些措施來增強數據的安全性。
     
   • 優化文件上傳、下載速度。
     
   • 嚴格限定教師和學生的權限。
2. 初步的資料信息處理的 DFD 圖：

1. 初步的活動圖：
   

2.7.2. 技術可行性

1. 在當前的限制條件下，該系統的功能目標都可以達到預期要求；
2. 利用 Struts 框架與 JSP 技術，該系統的功能能夠實現；
3. 開發人員中兩人對框架和技術熟練掌握；
4. 合理分配時間，能夠在規定的時間內完成開發；

2.7.2. 經濟可行性

2.7.2.1. 支出

1. 基建投資
   • 服務器一臺 2000 元
   • 數據庫系統 1000 元
   • 其它開支 1000 元
2. 常常性支出100元/月。

2.7.2.2. 效益

1. 廣告費

1人用1月可產生1元廣告費。

2.7.2.3. 收益/投資比

假定：

• 軟件的生命期爲3年；
• 平均每個月有500人次的使用量

總支出：2000元 + 1000元 + 1000元 + 100元/月 * 3 * 12月 = 7600元
總收益：1 元/人月 * 3 * 12月 * 500人 = 18000元

收益投資比：18000元/7600元 = 45/19 ≈ 2.3684

2.7.2.4. 投資回收週期

設回收週期爲X，單位爲月，則有：

1元/人月 * 500人 * X = 7600元，X = 15.2月，即約在在一年零3個月後進入投資回收期。

2.7.2. 操做可行性

該系統有以下特色：

• 系統採用菜單式實現用戶與數據庫的交互
• 界面簡潔
• 菜單條目簡單明瞭
• 關鍵的操做部分有傳統慣用的標識符
• 全部功能嚴格劃分界限，用戶不會步入複雜的功能選擇中。

基於以上特色，該系統的可操做性和常見的 windows 系統中的簡單 Web 頁面相似，符合用戶的操做習慣。

2.8. 草擬開發計劃

2.8.1. 工程進度表

階段	主要工做	時間段
需求分析	收集用戶需求	3/20 ~ 3/20
	驗證項目可行性	3/21 ~ 3/21
	制定項目初步計劃
	肯定系統功能及性能要求	3/22 ~ 3/23
	編寫用戶手冊概要	3/24 ~ 3/24
	討論並決定開發計劃
	編寫立項說明書	3/25 ~ 3/26
	編寫需求說明書
概要設計	創建系統整體結構，劃分功能模塊	3/27 ~ 3/27
	定義各功能模塊接口
	數據庫設計	3/28 ~ 3/28
	制定組裝測試計劃	3/29 ~ 3/29
	對已完成的文檔進行評審
	設計各模塊具體實現算法	3/30 ~ 3/30
	肯定模塊間詳細接口	3/31 ~ 4/1
	制定模塊測試方案
	編寫程序源代碼	4/2 ~4/7
	進行模塊測試和調試	4/8 ~ 4/9
	編寫用戶手冊	4/9 ~ 4/9
	集成測試	4/10 ~ 4/14
	編寫集成測試報告	4/15 ~ 4/15
	測試整個軟件系統	4/16 ~ 4/19
	編寫開發總結報告	4/20 ~ 4/21

2.8.2.人員

2.10. 技術選型

2.10.1. 表現層：JSP

使用Java開發Web項目在表現層上佔比最大的仍是JSP了。一方面，在以前的J2EE課程中已經接觸過了JSP，而且以前的不少web項目的開發訓練也都使用的JSP，組內成員對該技術都比較熟練；另外一方面，JSP的功能十分強大，整個項目的資源均可以經過它輕鬆訪問，它也十分適合於該項目表現層的實現。

2.10.2. 控制層：Struts

兩方面的緣由：

1. Struts框架功能全面，有着普遍的羣衆基礎，網上的相關資料也不少。
   
2. 組內開發人員比較熟悉。

2.10.3. 數據持久層：Hibernate

主要緣由是該框架的下面的這些優勢：

1. Hibernate充分體現了ORM的設計理念，提供了高效的對象到關係型數據庫的持久化服務。
   
2. 它將持久化服務從軟件業務層中徹底抽取出來，讓業務邏輯的處理更加簡單，更加有利於高效地開發和維護。
   使開發人員在程序中能夠利用面向對象的思想對關係型數據庫進行持久化操做。

2.11. 過程模型選擇

瀑布模型。

1. 該軟件的功能更需求簡單明確，需求→分析→設計→編碼→測試 各個階段工做量較小，對於每一個階段，都可以有時間完整的規劃和完成。
2. 項目開發時間有限，採用瀑布模型並明確設定每一個階段的截止時間，可以確保項目在規定時間內順利完成。
3. 將功能的實現與設計分開，更便於組內成員的分工協做。
4. 每一個階段全部人都參與，便於查缺撿漏和結合全部人的智慧。

3. 團隊成員

角色	姓名
項目組長	祖慶慶
項目成員	楊浪
項目成員	衛重波
項目成員	楊柳
項目成員	李鑫
項目成員	何磊
項目成員	鄒純鑫
項目成員	高揚

4. 分工

4.1. 工做分解結構(WBS)的編制

4.2. PERT時間估算

1. 利用相似法，從網上搜集與之相似的項目的花費人時做爲參考。
2. 當前的項目的複雜性較以前的簡單。沒有外部系統接入、課程共享等比較複雜的功能。
3. 當前團隊人數爲8人。

• T₀(樂觀時間)
• T_m(最可能時間)

• T_p(悲觀時間)

• 指望時間 = (T₀ + 4T_m + T_p) / 6

4.3. 具體分工

任務	截止時間	人員
需求分析報告	2016-3-26	全員
總體頁面設計	2016-4-1	祖慶慶 何磊 李鑫 衛重波
各個模塊網頁連接	2016-4-10	祖慶慶 何磊 李鑫 楊柳 楊浪 高揚
創建數據庫並錄入數據	2016-4-12	楊浪 鄒純鑫 高揚
數據庫的驗證	2016-4-15	祖慶慶 衛重波 李鑫
數據庫鏈接測試	2016-4-15	楊浪 鄒純鑫 高揚 何磊
網頁鏈接調試	2016-4-17	祖慶慶 衛重波 李鑫 楊柳
系統測試	2016-4-20	全員

5. 質量保障

5.1. 質量管理流程

5.1.1. 交付文檔質量監控流程

1. 項目經理和QAE^([2])在項目初期對項目交付文檔的模板進行檢查和審覈，確保項目交付品的架構和內容大綱的完整性和正確性。
2. 在項目進行過程當中，QA、項目經理及各項目功能小組組長會分別對交付品進度和質量進行監控，確保在最後的項目完成階段，客戶對提交的交付文檔能有滿意的反饋。

5.2. 項目質量評審

1. 該系統質量監控將採用平常質量監控流程與按期質量評審制度。
2. 平常質量監控程序經過制定系統開發的統一的規範、流程、指南、模板等指導項目的開發過程，並監控這些流程和規範的執行狀況，以確保全部交付品的質量。
3. 項目質量評審報告將根據各階段質量檢查點所應檢查的內容做出質量上的評審。對在質量評審工做中發現的問題，將根據其性質、範圍劃分級別。相關人員以此爲依據來肯定缺陷修復的優先級，缺陷嚴重程度高的修復優先級也高。
4. 項目質量評審報告將交由項目管理辦公室討論，質量保證經理與項目管理辦公室將對項目質量評審報告中須要明顯改善的質量問題做出具體地改進方案，以及時間上和人員上的安排。

5.3. 質量檢查和確認技術

5.3.1. 工具和技術

項目管理軟件：@Team
網站測試：host-tracker.com

5.4. 標準和約定

5.4.1 基本文檔

• 立項說明書
• 軟件需求規格說明書
• 概要設計
• 詳細設計
• 軟件測試計劃
• 軟件測試報告
• 開發總結

5.4.2 文檔質量的度量準則

• 完備性：應按照GB8567的規定編制相應的文檔，以保證在開發階段結束時其文檔是齊全的
• 正確性:在軟件開發各個階段所編寫的文檔的內容，必須真實的反映階段的工做且與該階段的需求相一致
• 簡明性:在軟件開發各個階段所編寫的各類文檔的語言表達應該清晰、準確簡煉，適合各類文檔的特定讀者
• 自說明性：在軟件開發各個階段所編寫的各類文檔應該具備較好的自說明性。文檔的自說明性是指在軟件開發各個階段中的不一樣文檔能獨立表達該軟件其相應階段的階段產品的能力。
• 規範性：在軟件開發各個階段所編寫的各類文檔應該具備良好的規範性。文檔的規範性是指文檔的封面、大綱、術語的含義以及圖示符號等符合有關規範的規定。

5.4.2 代碼規範

遵循java代碼規範