| 這個作業屬於哪個課程 | http://dwz.date/cts4 |
|---|---|
| 這個作業要求在哪里 | https://edu.cnblogs.com/campus/fzu/SE2020/homework/11224 |
| 這個作業的目標 | 完成需求分析 建立原型模型 |
| 學號 | 031802516 031802513 |
團隊簡介
團隊成員
| 學號 | 姓名 |
|---|---|
| 031802513 | 黃展 |
| 031802516 | 蘭傑 |
結對過程
因為我們是舍友，所以在老師一開始說有結對作業的時候我們就組好隊了。結對作業出來之后，我們很快就開始初步討論，但發現討論過程中存在着跑題的現象，為了防止跑題，我們一起觀看了相聲《跑題》以及生活大爆炸有關於跑題的片段。隨着進一步需求分析，我們決定采用web的形式完成需求，並且很快地着手原型模型的建立。由於我們白天很少有相同的空閑時間，所以我們的結對工作大都是在晚上進行的，工作過程中，我們嚴格按照結對的要求，一個人作為駕駛員坐在電腦面前工作，一個人站在背后作為導航員。
結對照片
需求分析
NABCD模型
-
N （Need 需求）
實驗室的現役成員不能很好的知曉已經出師的學長學姐的去向和現狀，已經出師的學長學姐也沒有便捷有效的方式了解實驗室現役成員的研究方向以及實驗室現在發展的情況。 -
A（Approach 做法）
我們團隊開發的web給實驗室新老成員提供了登錄內部頁面的功能，賬號注冊將由管理員審核后通過，解決了成員信息離散的問題，使成員無需訪問對方即可查看其研究方向、工作信息等基本信息，也提供了聊天功能使成員之間可以進一步交流，同時提供匹配功能，用戶可以匹配到和自己研究方向相同或相近的實驗室成員。 -
B（Benefit 好處）
把實驗室成員信息集中化，解決了實驗室新老成員間交流無門的問題。
匹配功能增強了成員之間交流的效率，優化了用戶體驗感。 -
C（Competitors 競爭）
web可以在多平台使用
相對於其他開發平台，web 成本低，而且可以呈現出高質量 -
D（Delivery 推廣）
在實驗室現役成員間可以由實驗室指導老師直接推廣
要在退役成員之間推廣，就需要指導老師、現役成員結合各種社交媒體共同推廣
利益相關者
- 開發團隊
- 已經離開實驗室的學長學姐
- 還在實驗室里修煉的學弟學妹
- 投資商--棟哥
原型模型
原型開發工具
Axure RP 9
模型
-
登錄界面
login
-
注冊界面
沒有賬戶的用戶提供個人信息，提交后經管理員審核通過后，即注冊成功
-
成員列表界面
用戶可以按標簽來篩選出某一方向的成員，可以點擊其他用戶查看具體信息，點擊 紙飛機 可以進入私聊窗口，點擊❤可以關注該用戶。
-
聊天界面
聊天頁面除了支持最基本的文本消息，還支持包括文件傳輸，表情包等類型的消息，還提供保存歷史消息等功能。
-
個人主頁
個人主頁會提供一些基本的信息，點擊頁面右上角的消息icon可以查看接收到的消息，也提供了查看關注者和粉絲的button,以及github跳轉鏈接（大家都是程序員出身，github可以使成員之間更有效的交流），還提供了留言板塊。
-
動態界面
用戶在動態界面可以發表/查看動態。
-
匹配界面
用戶在動態界面選擇想要匹配的技術類型，系統會根據用戶的選擇匹配到相符的對象。
UML用例圖
我們給普通用戶（實驗室現役成員和退役成員）提供了查看成員信息，跟成員聊天，關注成員，分享動態，留言，同類型成員匹配等功能，系統管理員負責管理用戶。
流程圖
web的功能流程圖
github
-
commit 提交截圖
效能分析
兩個人都是第一次接觸原型模型開發，在前期的軟件下載，資源庫下載以及建立團隊項目等方面花費了比較多的時間，而且在原型建立時沒有考慮充分，原型模型的有些部分是在寫博客時再返回去刪除或是添加的（凸顯了先設計好再動手實踐的重要性）。雖然兩個人都是第一次做原型模型建立，但是憑借着兩人多年的 游戲 合作經驗，不可取代的默契，讓這次結對作業進行的順利不少。總體上來說這次的結對作業效率達到了預期的效果。
PSP表
PSP
| 2.1 | Personal Software Process Stages | 預估耗時（分鍾） | 實際耗時（分鍾） |
|---|---|---|---|
| Planning | 計划 | 60 | 80 |
| Estimate | 估計這個任務需要多少時間 | 10 | 10 |
| Development | 開發 | ||
| Analysis | 需求分析 (包括學習新技術) | 40 | 40 |
| Design Spec | 生成設計文檔 | 30 | 30 |
| Design Review | 設計復審 | 20 | 20 |
| Coding Standard | 代碼規范 (為目前的開發制定合適的規范) | ||
| Design | 具體設計 | 200 | 240 |
| Coding | 具體編碼 | ||
| Code Review | 代碼復審 | ||
| Test | 測試（自我測試，修改代碼，提交修改） | ||
| Reporting | 報告 | 40 | 30 |
| Test Report | 測試報告 | ||
| Size Measurement | 計算工作量 | 5 | 10 |
| Postmortem & Process Improvement Plan | 事后總結, 並提出過程改進計划 | 60 | 90 |
| 合計 | 405 | 460 |