軟工 團隊第三次做業

Part 0. 開篇

WeEdit需求規格說明書
第三次軟工實踐答辯材料
一分鐘演示視頻
組長博客連接

Part 1. 計劃安排

1. 團隊全部成員共同討論各部分實現功能，共有5個功能，分別由5名成員負責各自的後端接口，2名同窗負責前端界面，1名同窗負責美工；
2. 在11月8日前，美工組同窗先完成界面主體設計，而後交由各參數於前端小組；
3. 在11月8日——11月15日期間，前端小組根據美工小組同窗的設計，完成前端的編程，與此同時，後端組自發討論學習各自功能的實現算法；
4. 在11月15日——11月20日期間，後端組完成各自的後端功能實現，並與前端接口相鏈接；
5. 在11月20日——11月25日期間，團隊成員組織探討合併該項目，對於有缺陷或者未能實現的功能集中討論，改善項目。

• 線上推廣
  • 在本院、校學生會以及各個班級組織推廣無償使用
• 線下推廣
  • 與福建省其餘高校一塊兒推廣使用，體驗高效便捷的微信辦公軟件服務
  • 另外，在辦公區域，經過添加小程序等服務，贈送相關辦公用品

Part 2. 項目logo

由於咱們的項目名稱是WeEdit，因此咱們的LOGO象形E，即辦公的意思，同時主體部分爲共享的標誌，符合咱們項目的立意。另外，用交流符號「...」以及鉛筆形象地結合，展示出咱們的主推功能———「共享編輯」。底色設定爲綠色，主要是爲了契合微信的圖標底色，咱們不遺餘力地使這個小程序與微信進一步的貼切，減小用戶的使用難度，方便使用。

Part 3. 思惟導圖

思惟導圖高清pdf版

Part 4. 團隊中我的的貢獻比例

圖中已經細分了各個成員在本次的團隊實踐任務中的具體工做分工，並以工做量的比例進行分數的評定，詳細見圖。本次的需求規格說明書具體參照了「GB-T 9385-2008，《計算機軟件需求規格說明規範》」，以大綱爲框架逐漸完善內部內容，後續經審覈補充完成最終的文檔。

姓名	得分（百分制比例%）
柯奇豪	18.575
蔣熊	8.675
黃志銘	7.775
黃毓明	14.975
林翔宇	16.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
第三組	77
第四組	87
第五組	63
第六組	82
第七組	79
第八組	76
第九組	90
最低分	63（第五組）
最高分	90（第九組）
有效分數	82，77，77，87，82，79，76
最終平均得分	80

Part 7. 軟件需求規格說明書(有大幅度的豐富改動)

WeEdit需求規格說明書
以前提到過的關於格式上的問題已經所有進行了修改，包括頁碼、部分未處理好的文字陰影等。同時在內容上進行了大幅度的增長，包括從新繪製實體關係圖，增長數據流圖以及數據字典等

Part 8. 遇到的困難及解決方法

• 困難描述
  • 軟件需求規格說明書的規範化
  • 短視頻製做、數據流圖的補充
  • 原型設計許多操做還不太熟悉
• 作過哪些嘗試
  • 參考範例一點點學習，瞭解具體的一些基礎知識
  • 閱讀相關的文檔學習
• 是否解決
  • 軟件需求規格說明書按照規範進行編寫完成
  • 視頻主要運用剪輯與加速，後續也補入了能夠增色一點的背景樂，花了我大把時間不斷反覆將其壓縮成一分鐘視頻，能夠說是很花功夫惹QAQ
  • 原型設計基本知足要求，交互正常，效果滿意
• 有何收穫
  • 參看別組的做品，發覺本身的視頻製做以及idea還須要多加提升，存在明顯差距
  • 經過與其餘組的Q&A，對自身軟件有了更多的認識，考慮的方面更加的全面，查缺補漏。

Part 9. PSP

PSP	Personal Software Process Stages	預估耗時（分鐘）	實際耗時（分鐘）
Planning	計劃
· Estimate	· 估計這個任務須要多少時間	20	20
Development	開發
· Analysis	· 需求分析 (包括學習新技術)	20	30
· Design Spec	· 生成設計文檔	120	300
· Design Review	· 設計複審 (和同事審覈設計文檔)	20	30
· Coding Standard	· 代碼規範 (爲目前的開發制定合適的規範)	0	0
· Design	· 具體設計	260	290
· Coding	· 具體編碼	0	0
· Code Review	· 代碼複審	0	0
· Test	· 測試（自我測試，修改代碼，提交修改）	30	40
Reporting	報告
· Test Report	· 測試報告	0	0
· Size Measurement	· 計算工做量	10	10
· Postmortem & Process Improvement Plan	· 過後總結, 並提出過程改進計劃	10	30
合計		490	750

Part 10. 學習進度條

第N周	新增代碼（行）	累計代碼（行）	本週學習耗時(小時)	累計學習耗時（小時）	重要成長
7	300+	N	15	60	瞭解小程序先後交互並測試實現，Java數據處理相關