碎閱創造營 凡事預則立

2022-08-02 23:39:15 字數 1478 閱讀 6667

歸屬班級

2019秋福大軟體工程實踐z班

作業要求

團隊作業第五次—專案衝刺

團隊名稱

碎閱創造營

作業目標

統籌好專案衝刺規劃

作業正文

碎閱創造營——凡事預則立

11.7(周四)-11.13(週三)

需求規格說明書不足總結改進

不足&改進:

原型介面過於單調.

改進:增加色彩元素,預設藍色調,使用者可根據個人喜好更換主題色調.

總結:以碎片時間為起點、督促使用者去閱讀曾經收藏的文件文章等資料,進行了大部分功能的設計和設想的預期結果,但還是有些地方需要修改和補充的。總的來說,不足的或者說待改進的地方還有很多,有些枝枝末末的地方可能還不夠具體和詳細。但對於已發現的問題,都已提出相應的解決方法和措施,繼續完善。

資料庫說明書設計不足總結改進

不足&改進:

細節處理不得當,如多對多關係理解為一對多關係.

改進:使用者與碎片的匯入和使用者與收藏夾的一對多關係應該為多對多關係更為合適.

專案理解需要進一步加深,e-r圖設計的不完整.

改進:增加使用者與碎片的多對多匯入關係,並增添相應的邏輯模型二維表;增加使用者與收藏夾的多對多擁有關係,並增添相應的邏輯模型二維表.

系統安全部分比較模糊,對使用者安全的保障不到位.

改進:引入基於有限域中離散對數演算法的des演算法.

總結:碎閱專案本身,大多操作都基於本地,與資料庫的聯絡稍有欠缺;且由於本學期剛剛學習資料庫,新學新用還是有一定難處,在很多方面還有不足,有待在後續學習中加以改進。

系統設計說明書

不足:

對於類圖的設計存在問題,沒有理解實體類如何設計。

在軟體的設計過程中,忽略了如何實現閱讀進度的問題。

缺少對開發環境和執行環境的描述。

總結:缺乏實際專案經驗,總體考慮較少。團隊安排不夠合理,說明書沒有在團隊內部得到適當的檢驗。

多線下討論,開會流程預先制定公布,提高會議效率。

時間緊迫,計畫盡量靈活 。

明確各自任務ddl,規定時間進行驗收。

我們將參考這裡的做出最後決定。

閱讀《構建之法》的第13-17章,分別是關於軟體測試、質量保證、穩定和發布階段、it行業的創新、人,績效和職業道德。

在衝刺之前確保每個人都瀏覽一遍。

凡事預則立

昨天想到了乙個問題 凡事預則立。任何事情都需要準備好,甚至考慮到當時的場景,做乙個導演而不是觀眾。每次的tm會議,我去之前總是做做一些計畫,想象當時的場景,以便讓自己保持活躍的狀態。我的做法是只列綱,不打具體的草稿.胸中有數,而後隨意而至。這實在是在不知不覺中養成的乙個習慣,生活中平常的事情也是這樣...

凡事預則立

吸取之前alpha衝刺的經驗教訓,也為了這次的beta衝刺可以更好更順利地進行,更是為了迎接我們的新成員瑋詩。我們開了一次組內會議,進行beta衝刺的規劃。上一張我們的合照 具體會議議程如下 重新組隊後,我們進行了組內評選組長的投票。投票結果如下 成員意向組長 周龍榮李家鵬 李家鵬周龍榮 曾瑋詩周龍...

凡事預則立

1 討論組長是否重選的議題和結論。組長不重選,因為沒有人想當這個組長,所以還是由我繼續。2 下一階段需要改進完善的功能。alpha版本尚未完成的功能很多,預計先將基本功能完成 發布資訊和修改 3 下一階段新增的功能。暫無新增功能,先把聊天功能完成 4 需要改進的團隊分工 針對之前的不足,需要加強和改...