Part 0. 開篇
WeEdit需求規格說明書
第三次軟工實踐答辯材料
一分鐘示範視訊
組長部落格連結
Part 1. 計劃安排
- 團隊所有成員共同讨論各部分實作功能，共有5個功能，分别由5名成員負責各自的後端接口，2名同學負責前端界面，1名同學負責美工；
- 在11月8日前，美工組同學先完成界面主體設計，然後交由各參數于前端小組；
- 在11月8日——11月15日期間，前端小組根據美工小組同學的設計，完成前端的程式設計，與此同時，後端組自發讨論學習各自功能的實作算法；
- 在11月15日——11月20日期間，後端組完成各自的後端功能實作，并與前端接口相連接配接；
- 在11月20日——11月25日期間，團隊成員組織探讨合并該項目，對于有缺陷或者未能實作的功能集中讨論，改善項目。
- 線上推廣
- 在本院、校學生會以及各個班級組織推廣免費使用
- 線下推廣
- 與福建省其他高校一起推廣使用，體驗高效便捷的微信辦公軟體服務
- 另外，在辦公區域，通過添加小程式等服務，贈送相關辦公用品
Part 2. 項目logo
因為我們的項目名稱是WeEdit，是以我們的LOGO象形E，即辦公的意思，同時主體部分為共享的标志，符合我們項目的立意。另外，用交流符号“...”以及鉛筆形象地結合，展現出我們的主推功能———“共享編輯”。底色設定為綠色，主要是為了契合微信的圖示底色，我們竭盡全力地使這個小程式與微信進一步的貼切，減少使用者的使用難度，友善使用。
Part 3. 思維導圖
Part 4. 團隊中個人的貢獻比例
圖中已經細分了各個成員在本次的團隊實踐任務中的具體工作分工，并以工作量的比例進行分數的評定，詳細見圖。本次的需求規格說明書具體參照了“GB-T 9385-2008，《計算機軟體需求規格說明規範》”，以大綱為架構逐漸完善内部内容，後續經稽核補充完成最終的文檔。
| 姓名 | 得分（百分制比例%） |
|---|---|
| 柯奇豪 | 18.575 |
| 蔣雄 | 8.675 |
| 黃志銘 | 7.775 |
| 黃毓明 | 14.975 |
| 林翔宇 | 16.775 |
| 丁水源 | |
| 楊禮亮 | |
| 陳超 | 1.475 |
Part 5. 評審表格設計
Part 6. 答辯總結
Q&A
- 第一組的問題
Q1:在宣傳中講到應用的文檔編輯傾向于“輕量化的編輯”，這與現有的移動端文檔編輯應用相比有獨到的競争力嗎？
A1: 我們主推微信群聊群體(尤其針對經常使用微信群聊進行辦公的上班族、社團部門等)，簡單編輯易上手和鍊式體驗就是我們的競争力。
Q2:産品比起之前的需求分析又增添了新功能，能否闡述一下産品的核心功能是？
A2: 我們的核心功能還是共享編輯。
Q3:是否對文檔協同編輯時可能出現的問題制定相應的驗收标準（比如文檔在多端編輯時沒有同步更新）
A3: 後期會制定一個标準，及時更新，謝謝。
- 第二組的問題
Q1:市面上有很多做的很成熟且使用很友善的競品，其功能也很豐富，為什麼客戶要選擇你們的？
A1: 首先，微信小程式便于使用和分享，其次捕獲定位資訊的功能能夠友善使用者們的使用而不同于其他軟體的選取地點。
Q2:你們産品為小程式且介紹的功能較多，加上小程式本身有局限，能夠真正實作你們所介紹的功能嗎？
A2: 小程式開發内部提供有豐富的接口，就目前了解而言是可以實作的。
Q3:是否有考慮增加更佳新穎功能或界面設計更加突出來吸引使用者使用？
A3:暫時沒有，我們認為能使使用者更加便捷快速的去熟悉使用就是我們産品推出的初衷。
- 第四組的問題
Q1:請問你們開發的産品相比于如騰訊文檔這類多人實時線上編輯的軟體，存在有哪些附加功能呢，還是僅是以微信小程式形式來實作？
A1:我們還有現場簽到、釋出通知等一系列功能，可以形成一個鍊式的關聯整體使用。
Q2:微信小程式能實作的功能存在局限性，是否能有效完成該項目呢？
A2: 就目前而言是可以完成的。
Q3: 僅依賴于微信小程式是否顯得拓展性不夠，擴充成APP的形式是否會效果更好呢？
A3: 我們認為微信小程式本身以其簡單便捷的優點會給産品帶來更大的吸引力，拓展性方面會在可行的範圍内，再進一步的去深入，盡可能的在完成既定規劃的情形下去豐富拓展。
- 第五組的問題
Q1:既然是鍊式功能服務，有沒有考慮做成app，可供多種社交賬号進行登入使用？并且不同賬号之間的檔案可以共享編輯？
A1: 我們暫時主要是為了微信使用者來考慮，因為從目前來看，微信這邊市場需求比較大，辦公人群居多。
Q2:文檔編輯授權問題，發起人能否進行批量授權？
A2: 文檔本身是以一種互動回報的形式來共享編輯，是以批量授權的實作是在我們考慮範圍中的。
Q3:現場簽到的防止虛拟定位是否繁瑣了點，能否有更加高效的簽到方式？
A3: 目前為止這是我們想到的一個解決虛拟定位的方式之一，後續會再進一步去深入了解與學習，尋找更便捷一點的防範措施，感謝你們的建議。
- 第六組的問題
Q1:你好，請問1分鐘的視訊用來展示原型的操作時間過短，且沒有聲音，觀看者很難看清楚具體功能，是否可以考慮采用截圖置于PPT中由演講者大緻講解功能子產品？
A1: 視訊的展示主要是為了引導使用者的使用，達到一個過程式的介紹，關于時間過短(題目規定)以及無聲(視訊制作的不足)的問題我們是可以後續修改的，你們提出的建議可以接收，謝謝指出不足。
Q2:你好，請問簽到功能是否能夠解決代簽問題？
A2: 我們在介紹中有提到，目前給出的一個解決方案是配合網絡接入位址進行防止虛拟定位的問題，後續會進一步去了解使用其他更便捷的方法。
Q3:你好，請問PPT内容相對比較少，是否可以考慮豐富PPT内容? 如增加原型的界面截圖。
A3: 本次的ppt主要介紹的主題均已經點出，已經滿足基礎性的要求，關于内容較少的問題，我們後續會注意的。
- 第七組的問題
Q1:你們提到簽到的時候會限制IP或者WIFI，不知道這個方法的可行性有多高呢？是否可以給出一些例證來說明？
A1: 舉例你到一定的地點使用上此IP，然後我對此進行判斷後抉擇簽到授權問題，當你在其他的IP位址上簽到時因為不滿足要求則視為無效簽到位址。可行性目前的了解是可以做到的。
Q2:”收集想法“這個功能和在朋友圈發一條消息或者在QQ空間發說說有什麼差别？
A2: 不太能夠了解你們提問的目的，但是作為本産品的一個輔助性功能，收集想法本身對使用群體沒有多大的限制，它本身作為一種放松心态、随時發送随機回答的方式，滿足工作閑暇之餘的放松。
Q3:”共享編輯“這個功能是否有曆史修改記錄，能實作版本回退？如果回退到較早的一個版本，這個版本之後的改動是否會一直儲存着，還說是在這次操作裡還能保留，但退出本次操作後，那些版本就會被清空？
A3: 會考慮增設記錄的儲存，即可以退回使用，如果是願意回退到上一個版本的話，自然該版本後的操作将視為失效不予記錄。
- 第八組的問題
Q1:産品與其他同類型産品拉開距離的核心競争力是什麼？
A1: 我們使用微信小程式，依托微信潛在的巨大辦公市場，能夠給使用者更便捷的辦公體驗。
Q2:對于協同編輯功能有沒有考慮到線上使用者數量會暴增，那會不會造成編輯的不穩定，有什麼對策解決？
A2: 目前我們考慮的是小群體使用者，即一個部門或者一個小團隊的内部使用，針對于這個，我們後續也會考慮解決的，謝謝。
Q3:對于簽到，為防止代簽之類的問題，是不是會用gps定位功能，但若是組員沒有開啟這個功能，那這樣不就有漏網之魚了嗎？
A3: 本身該功能就是為了精準簽到設定的，是以對于使用者是有要求的，你所提到的問題不屬于我們産品本身該考慮的問題。
- 第九組的問題
Q1:既然是多人編輯文檔，以微信小程式實作的話，在手機端會不會不友善編輯文檔？
A1: 我們會考慮盡可能的去使得使用者滿意并願意使用我們的小程式，關于不友善操作的問題我們正在設法簡約操作，謝謝你們給予的意見。
Q2:如果在電腦端實作，那麼該産品跟目前以有的産品相比較，你覺得你們的優勢在哪裡？
A2: 可以進行配套使用，因為主打的群體面向微信使用者，目前市面上的公司等等大型組織一般都更經常的使用微信，是以其存在的意義就是以其友善快捷來拉攏這些潛在的既有使用者，拓展更多的新使用者湧入。
Q3:微信小程式的編輯文檔界面是否真的能友善使用者的使用，有沒有考慮調查一下使用者的使用感受？
A3: 可以在後續進行若幹次産品調研，提升使用品質。
Final Score：
| 小組 | 評分 |
|---|---|
| 第一組 | 82 |
| 第二組 | 77 |
| 第三組 | |
| 第四組 | 87 |
| 第五組 | 63 |
| 第六組 | |
| 第七組 | 79 |
| 第八組 | 76 |
| 第九組 | 90 |
| 最低分 | 63（第五組） |
| 最高分 | 90（第九組） |
| 有效分數 | 82，77，77，87，82，79，76 |
| 最終平均得分 | 80 |
Part 7. 軟體需求規格說明書(有大幅度的豐富改動)
之前提到過的關于格式上的問題已經全部進行了修改，包括頁碼、部分未處理好的文字陰影等。同時在内容上進行了大幅度的增加，包括重新繪制實體關系圖，增加資料流圖以及資料字典等
Part 8. 遇到的困難及解決辦法
困難描述
一開始ppt不知道怎麼準備，都要講哪些内容，需要上台講也有點緊張。
做過哪些嘗試
和同學交流，參考助教的ppt和需求文檔。
是否解決
是。
有何收獲
對比其他組，覺得自己還有很多地方有待提高。在講需求分析時，使用貼近生活的實際的用例時，會讓他人更好了解。
Part 9. PSP表格
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鐘） | 實際耗時（分鐘） |
|---|---|---|---|
| Planning | 計劃 | 5 | |
| · Estimate | · 估計這個任務需要多少時間 | ||
| Development | 開發 | 260 | 560 |
| · Analysis | · 需求分析 (包括學習新技術) | 40 | 120 |
| · Design Spec | · 生成設計文檔 | 30 | |
| · Design Review | · 設計複審 | 10 | 100 |
| · Coding Standard | · 代碼規範 (為目前的開發制定合适的規範) | ||
| · Design | · 具體設計 | 180 | |
| · Coding | · 具體編碼 | ||
| · Code Review | · 代碼複審 | ||
| · Test | · 測試（自我測試，修改代碼，送出修改） | ||
| Reporting | 報告 | ||
| · Test Repor | · 測試報告 | 60 | |
| · Size Measurement | · 計算工作量 | ||
| · Postmortem & Process Improvement Plan | · 事後總結, 并提出過程改進計劃 | 15 | 35 |
| | 合計 |345 |765
學習進度表
| 第N周 | 新增代碼（行） | 累計代碼（行） | 本周學習耗時(小時) | 累計學習耗時（小時） | 重要成長 |
|---|---|---|---|---|---|
| 7 | 400 | 12 | 56 | 學習java基本文法 |