Alpha階段事後分析

我們軟體要解決的問題在我們的專案功能規格書中定義得很清楚。對典型使用者和典型場景也有比較清晰的描述。但是問題在於我們在並沒有優先去實現課程評價**的最核心功能，所有工作任務的優先順序並沒有定義好。

我們團隊花費了充足的時間來計畫每個任務，具體在專案管理可見。我們預估了每個專案的完成所需時間。

我們alpha階段的計畫的工作最後都已經完成。

這個並沒有發現，我們所做的事情都是比較有價值的。

後端的任務有清楚的定義和衡量的交付件。但是前端的任務在這方面來說較難確定，在網頁設計的細節和美化方面缺少相關的人員來鑑定。

整個專案按照計畫進行。

我們alpha階段的設定的截止日期為4.18，留下了一周左右的時間用來緩衝。在緩衝區這段時間裡，修復了不少測試發現的bug和使用者反饋的bug，緩衝區還是起到了非常重要的作用。

在將來的計畫中會把ui設計和美工加入到管理中，這是我們alpha階段所缺失的。

不管是時間，人力，設施的資源都比較充足。

各項任務的所需時間是各個小組一起商討確定的，算是比較精確，稍微有點出入但是不會預估太遠。

我們留了一周左右的時間用於推廣和處理使用者的反饋。在此期間有100多使用者參與了產品的使用，這部分的資源比較充足。

網頁的ui設計和css設計讓專門的人來做會比較有效率。

我們採用了石墨文件和issues來管理，每個成員都能很快地知道變更的訊息。

開例會的時候確定了「必須實現」的功能，如果要「推遲」，那麼則需要和pm進行商討才能確定。

首先，專案中每個任務的交付條件有三：

1，實現理想情況下的所有功能。

2，試用所有典型使用者。

3，覆蓋所有的邊界條件。

其次，在每個任務都按照如上的交付條件完成後，交付給內測使用者使用。在處理完內測使用者所有的反饋之後，專案即可「出口」。

alpha階段並沒有考慮到這種情況，不過我們在處理應急情況的時候，會由相關方面的負責人和pm商討如何解決。比如在**被攻擊的時候，我們小組前端和後端的負責人都和pm進行了緊急商討，制定了一系列方案來處理應急情況。詳見**被攻擊記錄。

留給員工們的緩衝時間足夠，大家都有充足的時間去處理意料之外的請求。

設計工作在我們正式動工完成任務之前就已經確定好了。是由pm，測試，前後端的負責人一起完成的。

有用單元測試和uml圖來幫助設計和實現。這些工具是十分有效的，我們可以很精確地找出bug所在地，方便開發成員找出bug所在並且修正。

產生bug最多的是身份驗證功能，即登入註冊功能。這一項功能是我們在原來的基礎上新加的，需要做的工作比較多。

**複審主要是由前後端負責人進行，按照規範文件執行。

有總的測試計畫，但細節部分因為我們產品本身在做之前缺少乙個細的設計，所以得做完才能制定細的測試計畫。

測試驗收目前就是看issue的解決程度和**覆蓋率。alpha階段做得並不好，驗收水平並不高，覆蓋率刷得不夠高。

基本只在用自動化測試工具來進行測試。

我們通過伺服器，cdn，驗證碼認證的控制台和伺服器上的日誌測量追蹤軟體的效能，其截圖如下：

我們alpha階段雖然有基礎**，但基本也是從0開發，開發人員在完成開發工作後，首先會自己測試。但在後續開發中是有用的，能快捷地進行回歸測試。改進之處就是需要一套更簡便的編寫測試樣例的手段，不然純粹的體力勞動太多、太嚴重了。

在發布的時候遇到的第乙個比較重大的問題便是中文使用者名稱無法登入的問題。

第二個問題是**在安全性方面欠考慮，被惡意註冊過。

總的來說我們組在alpha階段專案管理做得比較好，大家各司其職。需要改進的地方在於需要引入專門做css和ui設計的同學，來彌補網頁美觀性方面的不足。