【軟工實踐】團隊項目Snug-需求分析報告

組長博客連接

博客連接

---

團隊項目總體計劃安排

階段序列	階段時間	主要階段任務	完成狀況
第一階段	9.6	團隊成立	已完成
第二階段	9.6-9.13	課題選擇	已完成
第三階段	9.13-9.18	團隊分工商定	已完成
第四階段	9.18-9.30	學習基礎知識前端、後端、產品經理	已完成
第五階段	9.30-10.7	市場分析以及產品調研	已完成
第六階段	10.7-10.15	基礎界面的設計構思以及原型設計	完成部分
第七階段	10.15-10.20	需求分析以及項目構思的再調整	已完成
第八階段	10.20-11.1	基本界面的前端50%設計	完成部分
第九階段	11.1-11.5	完成前端100%的設計，完成後端50%的鏈接，算法完成20%	待完成
第十階段	11.5-11.8	後端完成100%，算法完成20%，完成文檔的初版攥寫，以及產品測試	待完成
第十一階段	11.9	Alpha版本發佈	待完成
第十二階段	後期不肯定性大如下內容暫定
第十二階段	11.9-11.15	Bata版本完成50%以及項目的優化	待完成
第十三階段	11.15-11.20	基本完成Bata版本	待完成
第十四階段	11.20-11.22	項目優化	待完成
第十五階段	11.22-12.23	文檔定稿，視頻和PPT等的製做	待完成

alpha版本須要作的事情

模板序號	模塊名	模塊具體內容
1	首頁	引導頁設計，軟件簡介
2	註冊登錄模塊	實現用戶的註冊和登錄功能
3	寵物界面	寵物隨着任務完成的成長和任務未完成的退化
4	任務添加模塊	任務添加以及刪除
5	任務列表模塊	查看全部的任務以及任務的刪除
6	SNUG TAB	展現SNUG的功能和進入SNUG的功能界面
7	數據分析模塊	將收集的全部的數據統計而且進行分析
8	推薦個性化調整	調整推薦頻率和彈窗提醒
9	我的中心	用戶頭像，用戶信息等各類功能

各成員分工明細及TODO list

隊員	分工明細	To Do List
雅輝	1.文檔撰寫 2.輔助任務、提醒的內容設計	1.答辯主講 2.輔助後端設計任務、提醒內容 3.輔助製做PPT
婉怡	2.美工設計 2.輔助任務、提醒的內容設計	1.美工設計，主要負責界面設計 2.輔助後端設計任務、提醒的內容
秋琴	1.前端負責人，前端任務安排及彙總 2.前端主力	1.跟進前端組每一個人的任務完成狀況，並進行及時的反饋及調整 2.負責引導頁、主界面、添加打卡界面的實現和完善
鈺蕙	1.前端主力 2.輔助美工	1.負責任務列表、數據分析、寵物訓練界面的實現和完善 2.輔助進行UI美工設計
雅芳	1.UI美工設計 2.前端主力 3.輔助文檔撰寫	1.負責登陸、註冊、設置註冊界面、寵物交互動畫的實現和完善 2.UI美工設計，主要負責寵物及其互動模塊的設計 3.輔助修改文檔
君曦	1.後端負責人，後端任務安排及彙總 2.數據庫搭建 3.接口設計	1.數據庫搭建（雲端） 2.任務推送基礎功能實現 3.提醒內容的設計及實現
金海	1.後端主力 2.數據庫搭建 3.爬取數據	1.實現登入接口、新用戶註冊、短信獲取驗證碼、忘記密碼、修改密碼、退出登陸等（後端） 2.數據庫搭建（雲端） 3.爬取所需語言庫數據
恩澤	1.跟蹤項目進度，安排總體計劃 2.算法主力 3.實現模塊，根據反饋調整任務推送	1.跟進每一個組的完成反饋狀況，推動完成alpha版本 2.根據用戶主動反饋狀況和系統獲取的實際狀況，調整任務和提醒的推送時間等
銀山	1.算法負責人，算法任務安排及彙總 2.實現模塊，分析數據智能提醒	1.跟進算法組每一個人的任務完成狀況，並進行及時的反饋和調整 2.獲取用戶位置信息、天氣信息、周邊狀況等，根據所獲信息進行智能提醒
季城	1.算法輔助 2.文檔撰寫	1.根據用戶的屏幕使用時間等狀況分析用戶手機APP使用行爲 2.製做答辯PPT

燃盡圖

---

思惟導圖

原圖連接

---

團隊中我的貢獻比例

工做流程

• 組長肯定需求規格說明書格式，明確分工安排及ddl；
• 對分工安排進行公示，若組員提出有意義、有建設性的建議，則對相應部分進行修改；
• 組員執行分工安排，在規定時間內交付本身負責的部分；
• 組長或相關負責人進行彙總，並對格式進行訂正。

組員分工

貢獻比例

姓 名	任務工做量（60）	我的參與度（10）	完成及時性（10）	Leader評分（20）	得分（100）	貢獻比例(%)
恩澤	56	10	10	20	96	11.3
秋琴	52	10	10	18	88	10.6
雅芳	52	10	10	20	92	10.8
鈺蕙	52	10	5	20	85	10.0
銀山	45	6	10	15	76	8.9
季城	35	5	10	15	58	7.6
君曦	52	10	10	20	92	10.8
金海	54	10	10	20	94	11.1
雅輝	54	10	8	20	92	10.8
婉怡	35	8	10	15	68	8.0

---

評審表格設計

評審設計表格戳這裏

---

UML

用例圖

• 描述的部分：

  • 描述了該軟件應有的功能；
  • 基本呈現了用戶和用例之間的關係；
  • 基本表達系統的具體行爲。

• 面臨的問題：

  • 製做uml圖軟件導出爲PNG格式的問題；
  • 功能大體的分類和描述。

• 解決的問題：

  • 大概描述了該軟件的功能和流程；
  • 可對其它工做起到參考做用。

附圖：

類圖

• 描述的部分：

  • 描述了咱們APP必須完成的類、接口以及它們之間的靜態結構和關係；
  • 類的部分：用戶、數據分析、主界面、任務列表、訓練、新建、數據庫、界面信息、任務信息、用戶數據、語句信息；
  • 關係部分：關聯、聚合；

• 面臨的問題：

  • 在APP開發以前沒有一個完整的思路，對不一樣界面、不一樣類之間的關聯性沒有深刻思考過；
  • 界面的個數、類的種類及個數、類中涉及的屬性及使用的方法不肯定；
  • 界面之間的關聯、類之間的關係比較模糊；
  • 沒有使用過繪製UML類圖的軟件，對關聯、聚合、泛化的概念不瞭解；

• 解決的問題：

  • 小組開會討論前端、後端具體的實現細節，對整個項目的結構設計有了必定的思路；
  • 與組內負責前端、後端的組員討論，肯定了界面的關聯及個數，類的屬性、方法和個數；
  • 經過比較Visio、Rose和StarUML以後選擇StarUML進行類圖繪製，搜索相關博客教程學習軟件的使用方法；

附圖：

活動圖

• 描述的部分：

  • 自定義項目生成過程。
  • 個性化寵物設計。
  • 用戶使用狀況的數據分析過程。

• 面臨的問題：

  • 面臨寵物設計問題。
  • 面臨帳戶管理問題。

• 解決的問題：

  • 提供智能提醒功能，根據用戶周邊天氣、溫度等狀況，提供推送衣食住行相關暖心提示的功能。
  • 提供智能分析功能，根據用戶的反饋信息，智能調整每日任務打卡量和消息提醒方式。
  • 提供項目生成功能，用戶自定義打卡項目名稱，提醒時間，完成個性化打卡項目設計。

附圖：

狀態圖

【part1】

• 描述的部分：
  • 描述了用戶登陸及未登陸使用的狀態。
• 面臨的問題：
  • 面臨用戶帳號管理及雲備份的問題。
• 解決的問題：
  • 解決了用戶使用雲備份功能的問題。
  • 解決了用戶註冊登陸流程的問題。
  • 解決了用戶找回密碼的問題。

附圖：

【part2】

• 描述的部分：
  • 描述了用戶添加打卡事件的狀態。
• 面臨的問題：
  • 面臨用戶打卡事件時間週期長，任務難度很差判斷的問題。
• 解決的問題：
  • 用戶只需先制定初步的目標和時間，隨着任務的開始會根據狀況進行修改。

附圖：

【part3】

• 描述的部分：
  • 描述了用戶查看任務列表的狀態。
• 面臨的問題：
  • 面臨用戶有自定義任務和用戶自行添加很差區分的問題。
  • 面臨用戶定義任務難度不適合自身狀況。
  • 面臨軟件推送的提醒的不合理。
• 解決的問題：
  • 用戶可自行選擇查看哪一種任務
  • 用戶能夠對任務量進行評級，後臺分析後修改
  • 用戶能夠查看提醒而且進行評級。

附圖：

【part4】

• 描述的部分：
  • 描述了用戶進行寵物訓練的狀態。
• 面臨的問題：
  • 面臨提醒時間段或者次數不符合用戶的問題。
• 解決的問題：
  • 用戶能夠對提醒頻率和時間進行修改。

附圖：

實體關係圖

• 描述的部分：

  • 描述用戶與各個主件之間的聯繫
  • 描述軟件總體的邏輯結構
  • 實體關係圖是概念模型

• 面臨的問題：

  • 實際功能有不肯定性須要進行必定的修改
  • 怎麼實例化實現各主件的聯繫

• 解決的問題：

  • 明確了要實現的功能
  • 數據庫的設計有了初步設想

附圖：

---

工具選擇

根據做業博客的推薦，先了解了Visio及Rose的使用，期間發現不少博客推薦StarUML，一番對比以後選擇了StarUML。

StarUML

• 工具版本：StarUML 3.1.0
• 選擇理由：界面簡潔美觀，開源項目發展快、靈活、可擴展性強，網上相關的博客教程比較多，功能基本完整；
• 可無償使用，對功能有更多要求的須要付費，網上也有不少破解教程。

其餘工具

• Visio
  Visio能夠說是目前最可以用圖形方式來表達各類商業圖形用途的工具。Visio在左側提供不少繪圖元素，只須要簡單的拖動就能夠完成設計，用於圖形語義的描述比較方便。軟件內提供了各類模板，方便各行業使用。缺點大概是收費過高。

• Rational Rose

  ROSE保證代碼和模型的高度一致，它能夠爲模型生成相應的代碼，能夠從原來的軟件系統中導出該系統的模型，還能夠真正實現代碼和模型之間的循環工程，保證模型和代碼的一致。支持多種語言。支持數據庫的建模，可以爲SQL server等支持DDL的數據庫自動生成數據描述語言DDL。在開發過程當中的各類語義、模塊、對象以及流程，狀態等描述比較好，主要體如今可以從各個方面和角度來分析和設計，使軟件的開發藍圖更清晰，內部結構更加明朗。

• Process On

  在線和免費兩大優點對於新手十分友好，因爲操做簡單，對於有繪圖經驗的用戶，學習成本幾乎爲零。在線儲存避免了斷電，藍屏等悲劇發生。結合網絡社交的特性，不一樣圖表的做者能夠輕鬆地在平臺分享各自做品，用戶也能夠方便地對公開的做品進行搜索，同時還支持多人協做的功能，適合團隊內部協同工做。

---

使用工具評價

StarUML

優勢：

• 免費下載，源碼開放，能夠安裝插件；
• 支持導出多種格式的圖片格式；
• 可以繪製多種UML圖：用例圖、類圖、序列圖、狀態圖、活動圖、通訊圖、構件圖、部署圖以及複合結構圖等；
• 具備語法自動檢測功能，違反語法的地方會提示；
• 能夠根據類圖生成Java、C++等代碼，也能夠經過代碼生成類圖；
• 破解方法簡單，入門門檻較低。

缺點：

• 使用右下角縮略圖的過程當中有時會出現延遲卡頓的現象，待優化解決；
• 全英文，暫時沒找到漢化的方法，對初次嘗試UML的初學者不是特別友好（爭議性缺點，對英語好的除外）；
• 從零開始學習UML，對不少相關的英語詞彙接觸很少，須要必定的時間；
• 沒法自定義安裝路徑，直接安裝到了C盤；當初是以這個理由拒絕了office的Visio，裝完StarUML後，emmm……？？

其餘工具

• Visio
  應用普遍，有各行業的圖庫可用，容易學習。

• Rational Rose
  用rose作設計，作的詳細後直接生成代碼，很是有優點。對應用結構任意一層作出修改時，只對其它層產生極小的影響。

• Process On
  不少模板參考，也能夠發給隊友在線看在線修改，對於團隊使用確實方便。但若是無網絡，仍是得安裝軟件，而且不能實現共享。

---

答辯總結

本組現場答辯總分

去掉一個最高分，去掉一個最低分，小組最終得分爲51.94分

組號	組名	打分
1	007	54.6
2	無駄無駄	54.6
3	十一根小腿	49.6
4	NewGame	50.4
5	計算機四班好朋友聯盟	52.8
6	拾光隊	49.2
7	搖光組	54.6
8	955	52.2
9	觀光隊	54
10	女生都隊	58.8
11	不知道叫什麼	46.2
12	To Be Done	47.4

團隊提問回答環節

第一組的提問：

問：寵物要怎麼設計？何時會動？

答：寵物會參考網上素材，根據需求進行調整和設計。至於何時會動，最開始咱們應該會作成gif像原型展現的那樣，在主界面就能看到它一直動，後期來得及的話，再考慮與用戶交互的效果。

第二組的提問：

問：想法仍是挺不錯的，跟市面上的產品比顯得獨樹一幟，可是感受經過用手機來作任務打卡改善生活的目的可行性和意義不是很大，良好的生活習慣可能首先要脫離依賴手機

答：咱們app的本意是在用戶使用手機的時候給予一些提醒，特別是現現在隨着手機功能的拓展，人們使用手機的時間也愈來愈多，咱們但願經過對用戶的一些溫暖的提醒及幫助可使用戶在繁忙的生活中依然保持較高的生活質量。

第三組的提問：

問：若是用戶設定的打卡任務違背健康的生活習慣，APP會不會作出一些提示、建議？

答：會的，咱們會對用戶設置的內容進行判斷，若是發現是違背健康的生活習慣，或者是違背道德標準的內容，都會對用戶進行提示建議甚至禁止。

第四組的提問：

問：

答：

第五組的提問：

問：原型設計真的不錯，期待看到大家的原創寵物

答：謝謝！原創寵物咱們會盡力的。

第六組的提問：

問：大家以爲真的會有人用這個軟件達到自律的目的嗎？

答：會的，咱們app的宗旨是陪伴用戶，會在用戶使用手機的時候進行提醒，假如用戶玩手機忘記了時間，看到咱們的提醒以後就會發現時間的流逝，想到還有一堆待作的事情，從而中止玩手機，這就是咱們使用戶達到自律的目的的情景之一。

第七組的提問

問：如何保證常駐後臺，且能低耗？

答：咱們會經過service來實現後臺的常駐，而後進行進程保活，開機喚醒app，接入SKD，咱們的app在後臺常駐後所運行的就只是任務提醒，電量消耗自己很小，咱們也會經過算法優化，儘可能減小後臺運行所消耗的電量。

第八組的提問

問：寵物訓練是一個很好的想法，能夠多作一些調查明確用戶對這個方面的需求，適當的加大宣傳的力度

答：寵物訓練是咱們app 的一大特點，咱們前期進行了調研，不少被調查者都對咱們的app產生了濃厚的興趣，咱們相信咱們的app上市後必定會取得不錯的成績，宣傳會在app上線前期再作打算。

第九組的提問

問：這類app不是很瞭解，我的以爲用戶激勵機制能夠再改進吧

答：這類app的主要功能是經過任務提醒來養成用戶的自律性，咱們創新性的將寵物的元素融於app 的設計中，這是咱們和市面上面的產品最大的區別。用戶激勵機制這自己就是一個和用戶互動的，讓用戶得到成就感的功能，這種獎勵能夠是虛擬的，目前是用戶按時完成任務寵物會成長，後期能夠考慮加入一些更加吸引的機制。

第十組的提問

問：原型設計太強了吧，是什麼樣的機靈小腦瓜設計出來的呢？

答：謝謝你，這個原型是咱們團隊共同協商產生的想法，而且由咱們團隊兩位對原型設計最爲擅長的女生設計完成的。咱們的初衷是設計出一種簡潔可愛，暖心的界面，在提醒用戶自律的同時讓用戶更加的喜歡咱們的app，咱們也更加完善咱們的設計，讓它更爲大衆所喜歡。

第十一組的提問

問：怎麼讓寵物動起來呢..

答：寵物是一種UI，他的動主要靠UI設計和後端接口，在後端會有實現寵物活動的算法，UI設計咱們基本完成了，目前還在努力的讓寵物運動更加智能。

第十二組的提問

問：MD5加密仍是沒有改。還有大家的類圖真的是系統的設計嗎？

答：MD5加密新的需求報告已經修改了，這也是團隊成員第一次作的類圖，確實會存在些許的bug，你看到的是以前舊版的，後面等文檔修改完成會再作上傳。

需求分析報告修改處

1.對不合理的時間特性標準做出了修改。

這裏主要修改了文字編輯錯誤，數據應在30s內完成的數據指的是用戶的數據分析報告，並且以用戶的數據文本量在3s內完成較爲合理。因爲本APP的體量較小，因此響應的更新請求應在在1min內較爲準確。

2.對錯誤使用的加密技術進行了修改。

因爲了解不當，不清楚MD5技術的使用，這裏進行調整改成DES加密算法。

---

《需求規格說明書》

需求分析報告PDF 提取碼: x24e

---

遇到的困難及解決方法

史恩澤

• 困難描述

  • 沒有繪製過UML類圖
  • 對需求規格說明書的書寫內容及規範沒有了解
  • 對產品的主線和定位還須要進一步的明確

• 作過哪些嘗試

  • 經過尋找博客教程學習UML工具的使用，瞭解具體繪製方法
  • 學習需求規格說明書的規範文本，瞭解內容及格式要求
  • 小組開會討論產品的需求及具體的實現措施

• 是否解決

  • 經過組內討論及自我學習基本上解決了上述問題

• 有何收穫

  • 學習了StarUML的使用方法，熟練地掌握了繪製類圖的技能
  • 經過請組員喝奶茶的方式鞏固了本身在組內至高無上的地位

陳秋琴

• 困難描述

  • 活動圖不知道怎麼作
  • 活動用例及場景不知道怎麼描述比較好
  • 本身負責的部分的許多專業詞彙不懂

• 作過哪些嘗試

  • 網上百度看流程圖，以及查看了書本的知識，瞭解各個模塊之間的做用
  • 找隊友去詢問建議，查找往年的用例，用本身的理解來寫。
  • 百度優先，而後查找相關解釋

• 是否解決

  • 解決
  • 解決
  • 解決

• 有何收穫

  • 讓我更全方位瞭解了需求分析整個流程，同時鍛鍊了咱們的文字表述能力還有細膩程度，畢竟細節決定成敗，每個部分的差錯都有可能會影響整個團隊的進度，後面還會存在返工的狀況。

鄭雅芳

• 困難描述

  • 用Axure作安卓類的原型圖了吧，主要用於製做網頁原型的Axure用來作安卓真的窒息
  • 時間控制器的彈窗不能在動態面板指定位置顯示
  • 同一個頁面不一樣面板的切換

• 作過哪些嘗試

  • 百度百度再百度，認真摸索了一下發現Axure許多邏輯和ppt還有ps差很少，兩個軟件帶來的思惟基礎讓我更快的上手了axure

• 是否解決

  • 解決，取消了彈窗固定在html的選項，進一步學習了動態面板和事件點擊的事件實例及頁面連接，實現了想對滿意的原型

• 有何收穫

  • 和鈺蕙小姐姐一塊兒熬夜做圖真的很歡樂啊哈哈哈哈哈哈。進一步熟悉了Axure，製做了想對滿意的原型圖，「團隊的快樂必定比一我的的快樂更快樂。」今天也是以爲個人隊友們好棒的一天(～￣▽￣)～

陳鈺蕙

• 困難描述

  • 用Axure作移動端原型圖太窒息了！！！！！
  • 元件交互動效的製做
  • 預覽的時候某些元件會莫名其妙瞎跑還變形

• 作過哪些嘗試

  • 百度學習法
  • 反覆調整反覆預覽
  • 諮詢百變萬能鄭雅芳

• 是否解決

  • 解決，終於作出想要的交互效果，預覽的時候終於不會變形了，這裏必須再誇誇鄭雅芳，雅芳學姐太強了！

• 有何收穫

  • 收穫了小可愛（傻子）鄭雅芳？
  • 更加了解Axure的功能。通宵做圖可太刺激了，每成功作出一個動效，那種成就感真是足以抵消睏意。
  • 和隊友們一塊兒作事情真是件能讓人十分開心的事呢~

陳銀山

• 困難描述

  • 對於此次分配的任務，由於之前沒有接觸過，不理解這個驗證標準的具體的要求是要什麼樣的標準因此寫起來仍是有點困難的。

• 作過哪些嘗試

  • 主要仍是經過百度和以往的資料進行學習，有點照貓畫虎的味道，勉勉強強算是理解了一些要求。

• 是否解決

  • 經過一些瞎摸索，最後仍是成功完成了任務。

• 有何收穫

  • 收穫就是作事情不能太過馬虎，因爲在文檔撰寫途中對於一些細節缺少考慮，致使出了不少問題被人懟，仍是感到很愧疚的。

李季城

• 困難描述

  • 用戶分析以前並無作過，上手起來較爲困難
  • 對產品將來的方向還不是特別的明瞭
  • 這段時間參加比賽，因此沒有辦法很好的參與到項目中去

• 作過哪些嘗試

  • 經過借鑑往屆的材料進行學習和了解，上網搜索用戶分析
  • 和團隊成員溝通了解產品將來的方向

• 是否解決

  • 用戶分析已經獲得解決，目前全部的比賽基本結束，後面能夠更好的參與到項目中去，提升參與度

• 有何收穫

  • 瞭解到了用戶分析文案的攥寫，對項目的瞭解程度更高了。

阮君曦

• 困難描述

  • 思惟導圖的佈局分配
  • 對uml軟件不熟悉，以及部分uml軟件不能免費導出PNG格式

• 作過哪些嘗試

  • 製做思惟導圖使用的是xmind，瀏覽了裏面不少的模板，最終從中挑了一個，而後按照原格式補充了內容。
  • 一開始使用的uml軟件沒法免費導出PNG格式，因此只能換了另外一個軟件。。太慘了。。

• 是否解決

  • 已解決
  • 已解決

• 有何收穫

  • 對東西的佈局有了必定的提高
  • 收穫了黑黑的眼圈

施金海

• 困難描述

  • 在使用UML畫圖工具時，作了不少嘗試，不少工具好比StarUML都是英文版的，對於英語渣渣的我實在是有點難受。
  • 在具體畫圖時，對ER圖總體的構建不是很瞭解

• 作過哪些嘗試

  • 在畫圖工具的選擇上，最終採用了EDraw ，界面友好，重要的是中文版，很適合我
  • 學習了ER圖的畫圖技巧，順便複習一下數據庫

• 是否解決

  • 都已解決

• 有何收穫

  • 又學習了一個工具的使用技巧
  • 對UML圖更加了解

吳雅輝

• 困難描述

  • 啊此次的困難描述好像沒有很困難。最開始我是畫原型設計的，在選擇總體風格的時候深深的懷疑本身可能要變成色盲了，可是設計出來仍是不太好看的亞子。後來咱們團隊針對目前的情況進行了人員微調，我接下了主講人這個職位，第一次替團隊上去發言，感受仍是很緊張，最怕本身影響整個團隊的成績。

• 作過哪些嘗試

  • 首先是那個懷疑本身是色盲原型設計的問題。爲了這個事，我找來了RGB的顏色對照表，而後就開始了漫長的嘗試之路。後來就是在接下主講人以後，和隊友配合一塊兒改PPT，連夜寫講稿改講稿。（凌晨5點的福大，真美）

• 是否解決

  • 固然是解決了啊！解決方案就是角色調換。因爲我剛接觸這一塊，作原型設計是真的莫得經驗，兩個隊友就主動挑起了原型設計修改的重擔，最後的成品就是那六張我以爲很是厲害的動圖（吹爆隊友），而後我大概可能也許在講話這方面就底氣深度麼仍是比較足吧（?），就老老實實地當去主講了。

• 有何收穫

  • 感受今天做爲主講人，發揮仍是差那麼一點點，可能之後有機會再次講的話會更加自信一點，控制一下語速語調啊什麼的；而後就是做爲一個團隊，是要以團隊的利益爲重的，若是有更好的辦法，哪怕不是本身的辦法，也應該積極改變；最後一個就是，仍是想好好向隊裏的各位厲害的學長學姐學點技術吧。

張婉怡

• 困難描述

  • 除了visio，沒使用過其餘軟件

• 作過哪些嘗試

  • 經過百度瞭解、下載軟件，根據隊友和他人使用狀況評價。

• 是否解決

  • 已解決

• 有何收穫

  • 瞭解了這些軟件的基本使用和優缺點，之後用到能夠根據需求選擇

---

PSP

PSP2.1	Personal Software Process Stages	預估耗時（分鐘）	實際耗時（分鐘）
Planning	計劃	30	25
· Estimate	· 估計這個任務須要多少時間	30	25
Development	開發	350	475
· Analysis	· 需求分析 (包括學習新技術)	60	60
· Design Spec	· 生成設計文檔	60	120
· Design Review	· 設計複審	40	45
· Coding Standard	· 代碼規範 (爲目前的開發制定合適的規範)	0	0
· Design	· 具體設計	190	250
· Coding	· 具體編碼	0	0
· Code Review	· 代碼複審	0	0
· Test	· 測試（自我測試，修改代碼，提交修改）	0	0
Reporting	報告	100	95
· Test Repor	· 測試報告	0	0
· Size Measurement	· 計算工做量	40	50
· Postmortem & Process Improvement Plan	· 過後總結, 並提出過程改進計劃	60	45
	合計	480	595

---

學習進度條

第N周	新增代碼（行）	累計代碼（行）	本週學習耗時（小時）	累計學習耗時（小時）	重要成長
1	103	103	14	14	學會了十三水的玩法，對原型設計有了必定的基礎
2	400	503	10	24	學習C# winform開發，完善具體設計思路
3	1313	1816	30	54	實現核心算法「自動分牌」
4	1153	2969	22	76	界面設計與代碼實現，完成各窗體與接口的實現
5	0	2969	15	91	詳細瞭解商業計劃書以及產品介紹視頻的製做
6	0	2969	20	111	學習了UML類圖的繪製，瞭解需求規格說明書的書寫