2018軟工實踐第八次作業
目錄
團隊資訊
隊名 404 Note Found
隊長：胡緒佩
臨時隊長：周政演
| 學號 | 姓名 | 部落格連結 |
|---|---|---|
| 031602543 | 周政演 | https://www.cnblogs.com/vancasola/p/9821102.html |
| 031602510 | 葛家燦 | https://www.cnblogs.com/dalegac/p/9823211.html |
| 031602513 | 黃鴻傑 | https://www.cnblogs.com/Jeho/p/9823214.html |
| 031602627 | 劉愷琳 | https://www.cnblogs.com/lkl-fzu/p/9821459.html |
| 031602113 | 何宇恆 | https://www.cnblogs.com/hyh1072797231/p/9822827.html |
| 031602444 | 莊卉 | https://www.cnblogs.com/ffxpy/p/9823213.html |
| 031602525 | 劉一好 | https://www.cnblogs.com/howtoloveyou/p/9823202.html |
| 081600410 | 胡青元 | https://www.cnblogs.com/waaaafool/p/9823203.html |
| 031602114 | 胡緒佩 | https://www.cnblogs.com/heihuifei/p/9823207.html |
| 031602511 | 何家偉 | https://www.cnblogs.com/Bylight/p/9823215.html |
| 031602539 | 翟丹丹 | http://www.cnblogs.com/breakbreak/p/9822763.html |
分工選擇
課上分工
課下分工
alpha版本要做的事情：
迭代原則，由核心功能到輔助功能
燃盡圖
UML
用例圖
描述的部分：
- 描述了我們軟體必須完成的任務，定義了必須完成的軟體功能；
- 基本呈現使用者與用例之間的具體關係；
- 基本表達系統的基本功能；
- 基本表達系統的具體行為。
面臨的問題：
- 如何具體對用例進行分類，使得用例更加具體；
- 如何對使用者與不同用例之間的關係詳細分析。
解決的問題：
- 初步獲取使用者的需求；
- 指導測試；
- 在整個過程中對其他工作流起到指導作用。
狀態圖
【part1】
描述的部分：
- 描述了使用者登入及未登入使用的狀態。
面臨的問題：
- 面臨使用者賬號管理及雲備份的問題。
解決的問題：
- 解決了使用者使用雲備份功能的問題。
- 解決了使用者註冊登入流程的問題。
- 解決了使用者找回密碼的問題。
附圖：
【part2】
描述的部分：
- 描述了使用者新建自定義備忘的狀態。
面臨的問題：
- 面臨使用者新增自定義備忘條目選填資訊較多的問題。
解決的問題：
- 使用者只需新增標題便可新建備忘，選填資訊個性化新增。
附圖：
【part3】
描述的部分：
- 描述了備忘資訊的狀態。
面臨的問題：
- 備忘錄的備忘錄事項狀態較多，如何分類、組織的的問題。
解決的問題：
- 使用者可清晰瞭解備忘錄事項的各種狀態。
附圖：
【part4】
描述的部分：
- 描述了所有備忘展示的狀態。
面臨的問題：
- 備忘資訊分類方式不同及備忘資訊展示形式比較多對於使用者較複雜。
解決的問題：
- 方便使用者切換檢視備忘資訊的分類方式，如按時間順序與事務型別。
- 方便使用者選擇備忘資訊展示的形式。
附圖：
活動圖
描述的部分
- 備忘錄生成過程。
- 個性化桌布設計。
- 使用者自定義備忘錄設定。
面臨的問題
- 面臨賬戶管理問題。
- 使用者自定義設計問題。如何使使用者獲得喜愛的簡潔實用的備忘錄桌布。
解決的問題
- 提供使用者行為分析功能，對使用者娛樂，遊戲方面進行時間監控。
- 提供智慧分析功能，智慧讀取快遞資訊和訂單資訊，將有效資訊轉化成備忘錄。
- 提供智慧提醒功能，在備忘錄自定義提醒時間之前進行簡訊提醒，並提供天氣提醒附加功能。
- 提供桌布生成功能，使用者自定義桌布樣式，字型顏色及字號，完成個性化特色桌布設計。
附圖
類圖
描述的部分：
- 描述了我們軟體必須完成的類、介面以及它們之間的靜態結構和關係；
- 類的部分：使用者、備忘錄、備忘錄分類夾、桌面控制元件、鎖屏桌布、圖片、音訊、備忘詳情、智慧分析、快遞資訊、訂單資訊、天氣資訊；
- 關係部分：關聯、聚合、泛化；
面臨的問題：
- 繪製類圖軟體的選擇和該軟體在類圖繪製上的使用方法；
- 類的定義（如屬性和方法）和個數比較不明確；
- 各種類之間的關係比較模糊；
解決的問題：
- 1確定使用StarUML進行類圖繪製並搜尋相關部落格教程學習使用StarUML繪製類圖；
- 2 與其他負責後端任務的組員討論交流溝通，確定主要的類的屬性、方法和個數；
- 3與組內負責前端、原型設計和其他UML圖繪製的組員反覆溝通；
附圖：
部署圖
描述的部分：
- 描述伺服器內部構建
- 描述軟體物理構架示意圖
- 描述軟體與硬體元件之間的物理關係以及處理節點
面臨的問題：
- 我們無法提供24小時開機的主機，只能進行租借與託管
解決的問題：
- 解決了開發者對於物理構架的巨集觀理解
- 提供了科學可實現的物理框架構建
附圖：
例項圖
描述的部分：
- 描述使用者和軟體之間、軟體各個部分之間的聯絡
- 描述軟體的邏輯結構
- 描述實體與其屬性的聯絡，是用來描述現實世界的概念模型。
面臨的問題：
- 1.具體實際功能要與後端商議，進行一定修改
解決的問題：
- 1.明確了各個部分的具體功能
- 2.具體解決了資料庫的設計
附圖：
物件圖
描述的部分：
- 軟體執行中的靜態時刻，描述物件之間關聯的例項；
- 描述某一個應用情景；
面臨的問題：
- 具體的應用情景需求；
- 資料流圖的設計；
- 抽象語義的視覺化描述；
解決的問題：
- 可以直觀表示出系統在某一個時刻（情景）一組類的實體之間的關係；
- 通過檢視某個時刻不同類之間的關係，思考歸納資料流圖；
- 對系統的設計檢視建模時，可以使用一組類圖完整地描述抽象的語義以及它們之間的關係；
附圖：
時序圖
雲備份
描述的部分
- 這裡描述了系統的雲備份部分
面臨的問題
- 要面臨雲搭建的，以及訪問的問題
解決的問題
- 設計幫助後端成員理解這一過程
附圖
登陸系統：
描述的部分
- 這裡描述了使用者登陸系統時遇到的情況
面臨的問題
- 面臨與資料庫連線訪問和與現有資訊匹配的問題
解決的問題 - 幫助編碼人員分析登陸時遇到的情況
附圖
備忘錄管理：
描述的部分
- 這裡描述了使用者對備忘錄進行操作時遇到的情況
面臨的問題
- 面臨對備忘錄的內容進行增刪改的問題
解決的問題
- 幫助編碼人員分析錄入備忘錄時遇到的情況
附圖
備忘錄類別：
描述的部分
- 這裡描述了使用者對備忘錄類別進行操作時遇到的情況
面臨的問題
- 面臨對備忘錄的類別進行增刪改的問題
解決的問題
- 幫助編碼人員分析修改備忘錄類別時遇到的情況
附圖
桌布系統：
描述的部分
- 這裡描述了使用者設定時遇到的情況
面臨的問題
- 面臨如何使用備忘錄生成桌布的問題
解決的問題
- 幫助編碼人員分析如何生成桌布的情況
附圖
智慧分析：
描述的部分
- 這裡描述了備忘錄軟體進行智慧分析時遇到的情況
面臨的問題
- 面臨如何對使用者行為進行分析和根據簡訊進行識別的問題
解決的問題
- 幫助編碼人員分析進行智慧分析時遇到的情況
附圖
包圖
描述的部分：
- 基本表達系統的基本功能
- 描述了軟體大致需要實現的功能
面臨的問題：
- 如何對於相關的類進行整合使之成為更加簡練的包
- 對於相關包之間的關係如何顯示比較好
解決的問題：
- 大致瞭解整個軟體的使用過程
- 對於繁雜的類實現相當於資料夾的功能，看起來更加簡潔
- 實現了uml的附加功能之一
附圖
通訊圖
【part1】
描述的部分
- 描述的是使用者登陸註冊流程。
面臨的問題
- 面臨使用者賬號管理以及雲備份的問題。
解決的問題
- 解決使用者註冊登入的問題
- 解決了使用者使用雲備份的問題
- 解決使用者找回密碼的問題。
附圖
【part2】
描述的部分
- 描述的備忘錄的生成以及刪除的問題。
面臨的問題
- 面臨備忘錄自動生成和使用者自行建立的問題。
解決的問題
- 解決使用者自動撰寫備忘錄的問題，解決根據手機簡訊生成備忘錄提醒的問題，解決備忘錄雲備份的問題。
附圖
【part3】
描述的部分
- 這裡是根據使用者手機上其他APP的使用頻率自動生成分析圖表的部分
面臨的問題
- 應用使用頻率的獲取問題
- 生成分析圖表的問題
- 生成訊息提醒的問題。
解決的問題
- 自動獲取應用使用頻率
- 自動生成分析圖表
- 自動傳送訊息提醒。
附圖
貢獻分評定
分工參考：
團隊內部一致交流後，大致分為以下三個模組：任務工作量、任務完成效率、反饋度。貢獻分評定不應當僅僅侷限於工作量，而應該綜合考慮所有對團隊發展的因素。具體理由分析：
任務工作量：如構建之法中所說，在軟體行業中，如何衡量工作量這本身就是一個大問題。但是工作量卻並不能因為其難以衡量便不予以考慮，我們會採取團隊重複討論投票形式比較精確、公平的決定工作量佔比。比如：在還未開始時進行投票哪個模組的難度最大，工作量最多，這樣不夠全域性自然也會存在偏差，因此我們還會在實現過程中中途繼續進行討論對初始工作量、難度的投票結果進行一定程度的更改使之更為精確。儘量避免出現：“明明有效的只有十行程式碼，卻因為其中加了許多的冗餘程式碼甚至是空行使其程式碼量看上去較多”這類誤判情況。因此我們相信在我們團隊中評定出的較為合理的工作量作為貢獻分佔比的重要參考資料可以使團隊更良好的發展，相互良性競爭。
任務完成效率：團隊並非一個人，而是許多個成員之間的整體，多個模組功能組成的集合，相互之間的影響是很大的，產品的進度很可能會受其中某一個模組而停滯不前。比如產品釋出時出現前後端有一個模組還有一半未完成的現象那對整個專案的影響也非常大。因此任務完成效率也是一個重要衡量貢獻分佔比的資料。
反饋度：團隊想要良好的發展，就應當每一個成員都儘量保持較高的熱情和動力，這樣團隊才會持久的具有活力和潛力。因此將反饋作為一項重要參考資料決定貢獻分，防止出現因為個別成員懈怠導致整個團隊缺乏活力，專案完成自然也受到影響。
考慮到本次工作的臨時性，既要考慮到貢獻分評定的公平性，又要考慮要計算的快速性，故採用以下方式
- 臨時貢獻分評定 ：個人任務量 45%+完成度45%+反饋情況10%
- 要求：組裡總共11個人，分數加起來為100分
- 每個人結束前，對臨時隊內的每個人進行評定，彙總給PM，PM對每個人的給分進行平均，得出最後貢獻分
課上貢獻分
課下貢獻分
工具選擇
根據助教學姐推薦，以及轉進同學的使用習慣，本次作業共使用了兩種工具：StarUML，ProcessOn。
StarUML
- 製作工具：staruml2.8
- 選擇理由：staruml功能完整、易上手；
- 本小組組內試用過ProcessOn和visio，前者缺少部分構圖件，後者使用感覺一般。
Process on
- 製作工具 Process on
- 選擇理由：
- 支援流程圖、思維導圖、原型圖、UML、網路拓撲圖等；
- 支援圖形介面操作，容易上手，方便實用；
- 隨時將作品分享給隊友，達成團隊之間的共享，能夠更好的協同合作，互相促進；資源豐富，相簿資源強大；
使用工具感受
本次作業使用了一種工具：StarUML
StarUML
- 這是一個很好的UML設計工具
通過這個工具很好的實現了我的時序圖的部分，平常的軟體一是無法建立生命線這一重要控制元件，二是無法針對各種實際情況做出應對，例如迴圈，條件等都無法進行設計。這款軟體完美地解決了這些問題，並且還能針對時序圖生成程式碼，很好地契合了我們的需求。
PSP表格
| PSP8.1 | header 2 | 預估耗時（分鐘） | 實際耗時（分鐘） |
|---|---|---|---|
| Planning | 計劃 | 35 | 30 |
| · Estimate | ·估計這個任務需要多少時間 | 15 | 5 |
| Development | 開發 | 0 | 0 |
| · Analysis | 需求分析（包括學習新技術） | 60 | 60 |
| · Design Spec | · 生成設計文件 | 60 | 120 |
| · Design Review | · 設計複審 | 30 | 30 |
| · Coding Standard | · 程式碼規範 (為目前的開發制定合適的規範) | 0 | 0 |
| · Design | · 具體設計 | 180 | 240 |
| · Coding | · 具體編碼 | 0 | 0 |
| · Code Review | · 程式碼複審 | 0 | 0 |
| · Test | ·測試（自我測試，修改程式碼，提交修改） | 0 | 0 |
| Reporting | 報告 | 245 | 300 |
| · Test Repor | · 測試報告 | 0 | 0 |
| · Size Measurement | · 計算工作量 | 0 | 0 |
| · Postmortem & Process Improvement Plan | · 事後總結, 並提出過程改進計劃 | 60 | 60 |
| 合計 | 685 | 845 |
換隊感受
- 換走了pm以及其他兩位同學，由於這次的任務比較簡單，所以沒有太大區別
- 由於本次我的部分沒有和換來的同學有交集，所以沒有更多的感受，看他們的完成情況還是很優秀的！