一、Beta階段項目復審

我們很低調隊

優點：這個小組的項目的功能基本上都完成，功能運行順暢，而且功能相對豐富，能從實際調研結果出發，設計適合用戶需求的。擁有進階試的題型選擇，分為簡單、中等和高級等難度供用戶選擇，還提供錯題集的保存，有利於用戶更好的使用該軟件，體現了軟件的人性化。團隊的分工明確，都能按時提交博客，按似乎完成任務，這與一個團隊的緊密合作密不可分。

缺點：

1、閃退。 功能使用時出現閃退現象，嚴重影響用戶使用。

2、功能之一的草稿本，有點雞肋，不適用，而且功能實現的也不理想。

3、兼容性問題，只能在虛擬機和安卓系統中使用，不能兼容全部用戶

團隊博客KKlist

優點

該小組所做出的項目整體還是比較好的，此項目目標在於實現個人的計劃管理，並在之前的基礎上完善郵件提醒的功能，實現了可自由添加課程表，沒有太多bug，但頁面響應速度較慢。

缺點

1.此項目的頁面響應速度較慢，用戶引導不是太好，考驗用戶的耐心的時候到了，有時要等待很久才能跳轉。

二、事後諸葛分析

設想和目標

1. 我們的軟件要解決什麽問題？是否定義得很清楚？是否對典型用戶和典型場景有清晰的描述？

我們的軟件的作用是幫助用戶實現準確快速的電子文檔查重，我們對軟件的定義是電子文檔查重系統，即通過文檔對比，統計文檔內容的重復率的軟件系統。軟件的典型用戶是大學教師，典型場景是老師對學生提交的論文進行方便快速準確的查重。

2. 我們達到目標了麽（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了麽？原計劃達到的用戶數量達到了麽?)?

原計劃做三個功能，基本都做了但是差一個問題沒有成功處理；按照原計劃交付的時間按時交付了；但原計劃的用戶數量沒有達到，幾乎沒人用。

3. 用戶量, 用戶對重要功能的接受程度和我們事先的預想一致麽? 我們離目標更近了麽？有什麽經驗教訓?

因為之前做過用戶需求調研，所以對用戶的需求有一定的了解，我們一開始就是按照用戶的需求做的，因此用戶對重要的工能的接受程度跟我們預想的一樣，我們離目標也更近了一步。

計劃

1.是否有充足的時間來做計劃?

有，整個軟件的基本開發較快完成。

2.團隊在計劃階段是如何解決同事們對於計劃的不同意見的？

對於計劃的不同意見，我們是進行集體協商的，從中選擇一個方法進行表決。

3.你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麽?

原計劃的工作幾乎做完了，只差一些細微的改良，這是由於要應對老師的要求。

4.有沒有發現你做了一些事後看來沒必要或沒多大價值的事?

沒有，因為軟件整體按需求和老師要求精簡改良了。而且軟件自身就比較精簡。

5.是否每一項任務都有清楚定義和衡量的交付件?

沒有每一項，因為軟件只有一個查重算法，也是最核心的一個功能，所以對這一部分代碼的編寫至關重要，軟件作為一個整體進行交付。

6.是否項目的整個過程都按照計劃進行，項目出了什麽意外？有什麽風險是當時沒有估計到的，為什麽沒有估計到?

項目的整個過程開發還算順利，做的是pc端的程序，沒有什麽大風險，只是還要對老師的一些小要求進行改善。但是遇到了一個docx文件讀取的問題沒有解決。

7.在計劃中有沒有留下緩沖區，緩沖區有作用麽?

沒有留下緩沖區。

8.將來的計劃會做什麽修改？（例如：緩沖區的定義，加班）

大體上不會再有修改，軟件已經成型，已經可以使用。

資源

1.我們有足夠的資源來完成各項任務麽?

我們是使用java語言來編程的，由於團隊裏成員此前都有學習過java，也都有過使用java編程的經驗，所以在整個軟件開發的過程中，程序編程，界面設計的資源還是很充足的。

2. 各項任務所需的時間和其他資源是如何估計的，精度如何?

我們是將軟件所需的要求劃分成多個任務，每天都大致完成幾個任務，精度是計算到每天。

3. 測試的時間，人力和軟件/硬件資源是否足夠? 對於那些不需要編程的資源 (美工設計/文案)是否低估難度?

·各項功能的測試時間相對充足，團隊的每個隊員完成一個模塊後，都會進行簡單的功能測試，最後整合進行總測試，減少出錯率。

·人力和軟件/硬件資源十分充足，我們是六個人的小組，每個人都各司其職，努力完成自己的模塊，也會對別的隊員提供自己的想法和幫助。

·美工設計我們確實有所低估，功能全部完成的前提下，軟件整體的界面使用都不算特別美觀。

·文案通常是我們組長來進行任務分配，每個人完成一個部分，再由一人總結，一般是人人都有參與。

你有沒有感到你做的事情可以讓別人來做（更有效率）?

·王若凡：我所負責的工作之一就是項目管理和任務分配，將整個軟件分成多個任務，根據組員自身的情況再來分配，這個需要對每個人的自身情況都要有了解，這個任務花時間是了解我覺得可以讓別的組員來完成。

·鄭懷勇：我主要是完成查重程序的算法一塊看，界面一塊也有涉及到。在查重算法上我們查閱了很多資料最後選擇了余弦算法這一算法去實現查重功能，在算法上我是和另一個組員一同完成的，我的任務我覺得可以交由另一個組員去完成，但是單獨一人除非是有很強的能力，效率實在太低了

·呂誌哲：我是負責軟件最後的測試以及需求分析說明書的制定，我覺得我做的還沒達到我的理想指標，交由別的更細心的隊友可能會有更好的效果。

·歐陽勇：我主要是負責界面這一塊的，這塊內容的編程我還是比較熟悉的，團隊裏每個人多多少少都有掌握好java，但我自認為還是比較擅長。

·盧少銳：我的任務在測試跟界面制作上都有涉及到，在參與開發的同時也參與了軟件測試，這對測試的效率提高挺有幫助的，測試也可以交由其他有參與開發的人來完成，效率應該不差。

·連永剛：我是負責開發者文件那一塊的代碼，在開發的過程中有碰到一下小問題，經過團隊互幫互助都成功解決了，但我覺得我做的還不夠，可能交由他人來做會更有效率吧。

有什麽經驗教訓? 如果歷史重來一遍, 我們會做什麽改進?

每個任務都會讓人學習到很多，如果還重來一次，我們會重新分配任務，讓組員去嘗試不一樣的任務，讓人學習到不同的東西。

變更管理

1. 每個相關的員工都及時知道了變更的消息?

成員都在一個班級，就隔壁宿舍而已，天天見面，而且現在有各種消息傳遞方式如qq群，所以變更消息能夠及時知道。

2. 我們采用了什麽辦法決定“推遲”和“必須實現”的功能?

首先判斷這個功能的重要性，重要級別高就優先，其次看它的實現難度，如果成員們都解決不了就暫時推遲。對於重要功能就肯定是要實現，附加的額外功能若實現不了就可以選擇放棄。

3.項目的出口條件（Exit Criteria）是否得到清晰的定義?

對於我們來說，項目出口條件就是程序滿足規定的要求，並且運行無誤，沒有bug，體驗感好。

4. 對於可能的變更是否能制定應急計劃?

算是沒有吧，一開始就將計劃制定好了，將任務分配到個人，而出現變更就是看屬於哪個任務由負責人解決。

5. 員工是否能夠有效地處理意料之外的工作請求？

對於該完成的功能成員們都有效處理了，對於一些難度太大無法解決的就只能放棄處理了。

設計/實現

1. 設計工作在什麽時候，由誰來完成的？是合適的時間，合適的人麽？

2. 設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？

. 對於算法選擇剛開始大家意見不同，不知道該選擇哪種算法進行查重，所以最早選擇使用三種算法供使用者選擇，最後在 老師的建議下只選擇了余弦算法。

. 對於頁面設計，有人建議簡潔的好，有人望越高端越好，但是實現是有難度的，所以最後決定選取簡單的，然後能進行一些美化就好了。

3. 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麽？

團隊沒有單元測試，由於大家都對測試比較陌生，基本沒有使用過，所以此次就以完成代碼為主要任務並沒有想到去測試，而且都沒有這個習慣。

4. 什麽功能產生的Bug最多，為什麽？在發布之後發現了什麽重要的bug? 為什麽我們在設計/開發的時候沒有想到這些情況?

Bug：不能讀取docx文件

原因：找不到問題，發布之前就發現。

5. 代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規範？

大家在完成自己的代碼時就完成多少就先審核多少，最後匯總大家互相查看代碼，看有沒有自己審核時沒發現的問題，當局者迷，旁觀者清。

我們學到了什麽? 如果歷史重來一遍, 我們會做什麽改進?

加深對項目的認識，並且爭取更好的配合，此次合作中發現分工大家一起完成一個工作時，真的比較輕松與愉快。

測試/發布

1. 團隊是否有一個測試計劃？為什麽沒有？

我們對測試有一個粗略的計劃，但是沒有對代碼進行測試只是對功能進行了測試。

2. 是否進行了正式的驗收測試？

我們還沒進行驗收測試，只是我們自己測試過。

3. 團隊是否有測試工具來幫助測試？

沒有

4. 團隊是如何測量並跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工作有用麽？應該有哪些改進？

我們是一個查重的軟件，衡量效能的標準是一次性導入文件的數量與查重時間的比值作為一個度量值，繪制表格，然後人工分析代碼效率。相對低效。

5. 在發布的過程中發現了哪些意外問題？

在發布實施是跨電腦運行，32位系統和64位系統需要分系統使用

1. b. 博客要附上全組討論的照片。

1. 團隊成員在Beta階段的角色和具體貢獻：

團隊作業10——Beta階段項目復審