版本號：v0.1
版本號修改說明
一、引言
1、專案背景
「構建之法」於2023年在清華大學首次實踐，隨後經過在北航、東北師範大學、福州大學、集美大學等三十餘所學校的不斷迭代與改進，現已形成了一套成熟的軟體工程課程教學體系，覆蓋了軟體工程和程式語言的教學。該教學體系有下面的特點：
·練習量大, 內容多：除了大量的**練習，還有大量的部落格寫作練習。
·理論和實踐相結合：講現**論，同時結合體現理論的工具，例如：要求所有**使用git和github進行管理。
·真實的團隊開發：要求使用原型設計工具設計專案，使用團隊開發工具管理任務分配，使用燃盡圖進行進度管控等等一應俱全。
·學生助教熟悉課程，能夠協助老師，與學生充分互動。
在基於「構建之法」思想的軟工課程教學中，在團隊專案階段，主要採用部落格和github方式發布團隊作業並對源**進行管理。教師和助教需要對專案團隊管理質量進行度量並給予學生及時反饋和有效指導。當前這些工作都是人工進行，效率較低，步驟和流程較為繁瑣，缺乏必要的資料統計與彙總。因此需要一款軟體系統支援這項工作的開展。
l 專案名稱：團隊專案度量反饋平台
l 面向使用者：高校軟工教學團隊與學習軟工的學生
l 專案開發者：北航軟工暑期培訓班團隊專案1組
二、典型使用者與場景
1、典型使用者及需求
本系統主要有三類典型使用者：
l 軟工教學的教師：檢視所有專案團隊的源**管理質量以及專案進度管理質量並給予反饋，檢視每位學生在專案團隊內的貢獻情況
l 軟工課程的助教：檢視自己所負責的專案團隊的源**管理之里昂以及專案進度管理質量並給予反饋，檢視所負責專案團隊內的每位學生在隊內的貢獻情況
l 軟工課程的學生：檢視自己所在專案的源**管理質量、專案進度管理質量、教師和助教的反饋資訊以及參考文獻
2、典型場景
（1）軟工課教師鄒老師
名字鄒老師性別男
職業某高校軟工教師
動機學生的源**管理質量和進度管理質量實在慘不忍睹，學生太多啦！可不可以自動檢測這些專案的源**管理質量和專案進度管理質量啊！
目的自動評價學生團隊專案度源**管理質量和專案進度管理質量並根據情況給予反饋和指導
困難學生數量太多，源**管理質量和專案進度管理質量評估複雜
典型場景
登陸平台，瀏覽所有專案團隊的源**管理質量，點選按鈕進入某個專案團隊的專案管理質量詳細分析介面，了解詳細情況後填寫反饋和指導資訊。
典型描述
額……就一次提交？
（2）軟工課助教小夏
名字小夏性別男
職業某高校軟工助教生軟工課程助教
動機減少助教工作量、防止誤判、規範化評價標準
目的讓評價有據可依，拿資料說話；促進公平，減少人工認定的誤差率；
困難學生個人情況複雜，評價尺度難以普適性；需要及時更新，緊隨專案進展資訊低下
典型場景
登入平台，瀏覽所有專案團隊的源**管理質量，點選按鈕進入某個專案團隊的專案管理質量詳細分析介面。當助教給最終性評價時，需要大量的資料作為支撐，此時需要人工評價。指導資訊。
典型描述
這個**運用了新技術，但是考核裡面沒有，該如何處理？天的工作是什麼鬼？
（3）軟工課學生小劉
名字小劉性別女
職業某高校軟工課程學生
動機防止助教個人因素導致評分工作出現偏差，引起學生逆反心理，從而推進課程程序。進度，得到老師的評價和反饋。
目的使助教評價作業有統一標準，對學生工作負責
困難學生作業較多，助教工作難以保證評價不受主觀因素影響
典型場景
學生對於作業分數有疑問，助教可以根據需要給出評價標準。多少；提交issue id，任務內容描述，**簽入id，部落格位址等內容，檢視教師評分和反饋，或檢視課程相關資料的專欄
典型描述
為什麼不能只提交一次！？
3、執行環境
**預計支援火狐瀏覽器和谷歌瀏覽器，對ie瀏覽器，支援ie10以上版本。
三、原型設計
四、功能描述及驗收標準
測試功能
測試項輸入/操作
檢測點測試功能
完成情況
專案列表頁
概要檢視
點選是否跳轉至概要頁面
進入頁面
已完成**評估
點選是否跳轉至**評估頁面
進入頁面
已完成進度評估
點選是否跳轉至進度評估頁面
進入頁面
已完成專案搜尋
輸入條件，點選確定
確認是否與搜尋條件匹配的專案列表
找到相關列表
質量評估頁面
質量評分
檢視是否
顯示正確資料
資料顯示
已完成**修改量
檢視是否
顯示正確資料
資料顯示
已完成專案管理質量評價
檢視是否
顯示正確資料
資料顯示
已完成反饋
檢視是否
顯示正確資料
資料顯示
版本號：v0.1
版本號修改說明
規格說明書文件 第5小組
投標保證金 投標保證金是指在招標投標活動中，投標人隨投標檔案一同遞交給招標人的一定形式 一定金額的投標責任擔保。招標人會在書面合同簽訂後5日內向中標人和未中標的投標人退還投標保證金及銀行同期存款利息。合同履約金 合同履約金是指為合同的履行所提供的一種金錢保證，並在雙方合同到期或者依法解除時才予以退還...
團隊專案 需求規格說明書
deadline 2016.10.22 8 00am 發表一篇隨筆 課堂現場評審 要求 1 參考 軟體需求規格說明書 國標規範文字，撰寫對應專案的軟體需求規格說明書。2 除形式上滿足規範文字要求外，整體內容必須圍繞專案實質展開，對所要開發的專案確保盡力做到清晰完整準確。3 採用分層形式描述，隨著 層...
團隊專案 需求規格說明書
408 409410 428429 4311.要求瀏覽一遍 gb t 9385 2008 計算機軟體需求規格說明規範 2.立會討論分工事宜 3.分工 學號分工 比例408 類圖 介面原型 16.7 409功能描述 介面原型 16.7 410驗收驗證標準 16.7 428文件的圖表 文字 樣式統一且符...