Smart City 項目總結 Postmortem（轉）

原貼地址：http://pku-group3.spaces.live.com/php

 

設想和目標面試

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

隨着城市化的加速發展，城市交通問題也顯得越來 越突出，咱們提出要作一個智能交 通疏導系統和模擬系統。這個系統能夠經過地圖編輯來繪製不一樣的道路、路口，能夠 經過設定車輛數目來實現不一樣的路況，能夠用來測試不一樣的調度算法。從嚴格的意義上來講，它應該是一個帶有地圖編輯功能的調度算法模擬平臺。它支持用戶經過 編程方式來實現不一樣的調度算法，可 覺得交通控制理論的研究工做人員提供交通模型模擬和實驗數據，也能夠檢驗各類交通控制和調度算法的實際效果。編程

2. 是否有充足的時間來作計劃?  項目原來預計有多少用戶，實際有多少用戶? 爲何有如此落差?編輯器

3. 計劃的時間比較充足，預計的用戶不會不少，由於使用本軟件須要有必定的編程基礎和交通領域的相關知識，或是相關領域的研究工做者。他們使用本 軟件主要就是爲了測試實現的算法是否「智能」，固然，若是從長期效應來說，本軟件爲交通智能調度和算法研究提供了良好的工具。本軟件的預計下載量在30，實際下載量在40左右。工具

4. 團隊在計劃階段如何解決同事們對於計劃的不一樣意見的？  單元測試

主要經過開會討論來統一不一樣意見，開會後會得出一個你們都 一致接受的結論。學習

計劃測試

1. 你原計劃的工做是否最後都作完了? 若是有沒作完的，爲何?google

計劃的工做並無徹底作完，咱們定義了4個scope而且預計實現其中的2～3個，最終實際完成了第一和第二個scope。沒有徹底完成的主要緣由仍是由於項目的時間吃緊，尤爲是到項目進行的後期。另一個緣由就是咱們缺乏熟悉交通領域知識的人來支持我 們完成系統的開發，不少交通領域的專業知識是咱們發現不足後臨時學習的，這也很大程度的拖慢了項目的進度。

2. 有沒有發現你作了一些過後看來不必，沒多大價值的事?

沒有。

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

大的任務咱們有清楚的定義和衡量，但並非具體到每個任 務都有定義，開發過程當中彈性很大。

4. 在項目的整個過程都按照計劃進行?

大致上是按照計劃來進行。在全組人員的共同努力下，項目按照原定計劃在6月23日發佈Beta版本， 並開始收集該版本的用戶反饋信息。在發佈Alpha版本以後的兩個星期，咱們陸續收到了用戶反饋信息。項目的進行基本按照計劃，在不影響版本發佈的前提下，對進度和任務作了一些必要的 調整。

5. 在計劃中有沒有留下緩衝區，緩衝區有做用麼?

留下了緩衝區，緩衝區主要是用來處理項目後期系統臨近發佈 時浮現出來的各類Bug。

6. 未來的計劃會什麼修改？ (例如： 緩衝區的定義，加班)?

應該不會有什麼修改。

資源

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

沒有，在項目過程當中，因爲組員本學期課業任務比較重，能投入項目的 時間並很少，因此項目時間比較緊張。

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

項目中的各項任務都基本按照經驗來估計，放寬必定的緩衝 區，採用保守估計，如今看來，這個方法雖然估計精度不是很高，可是從結果來看仍是保證了項目按照計劃如期交付。

3. 用戶測試的時間，人力和軟件/硬件資源是否足夠?

Alpha版本的測試時 間是2周，有點短，收集的用戶反饋深度不是很 夠；並且項目人力也存在問題。軟硬資源獲得了 保障。

4. 你有沒有感到你作的事情可讓別人來作（更有效率）?

主要是關於交通領域的專業知識咱們小組仍是有所欠缺，若是 有一個有這方面背景的人可以給予支持效果確定會好不少，至少能夠節約大量的時間。系統也能更加專業和貼近用戶的使用習慣。

變動管理

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

咱們經過SVN來管理代碼，每一個員 工都會受到變動消息。另外咱們還有QQ羣等輔 助手段來進行溝通。

2. 咱們採用了什麼辦法決定「推遲」和「必須實現」的功能?

咱們採用了劃分優先級的方式肯定了哪些功能必須實現，哪些 功能推遲實現。調度算法是推遲的功能，由於項目必須實現的是一個算法模擬的平臺，即平臺自己，而算法是能夠由用戶自行實現的。固然，咱們也致力於找到很好 的調度算法，目前，只實現了幾種簡單的調度供用戶參考使用。

3. 項目的出口條件 （Exit Criteria）是否獲得清晰的定義? 到底什麼叫 」作 好了」? 

咱們經過驗收測試來測試系統是否「作好了」，出口條件就是 開發出這個系統而且完成需求階段定義的90%以上的功能。

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

沒有應急計劃，項目變動時經過開會討論的方式來控制和處理 變動。

5. 員工是否可以有效地處理意料以外的工做請求？

員工基本能在完成本職工做的同時，完成意料以外的工做請 求，例如，文檔、BUG修復等等。團隊比較團結，組員積極性 較好。

設計/實現

1. 設計工做在何時，由誰來完成的？是合適的時間，合適的人麼？

第一週頭腦風暴肯定要作的系統爲：城市交通智能管理模擬系統，肯定主要的功能模塊爲：地圖編輯器和 路況監視器，並肯定每一個模塊要實現的具體功能，如地圖編輯器模塊的地圖保存功能，路況監視器中的局部查看功能，全局查看功能，局部放大功能，打印實時信息 功能等，頭腦風暴由全組人員參加。第二週討論具體的實現，由PM（瀋陽），一個DEV（何 建杉），一個TEST（萬成鋮）參加。

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

沒有。

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

在開發的過程當中進行了單元測試，可是是經過直接編寫測試代碼進行的，沒有用到專門的工具。

4. 什麼功能產生的bug 最多，爲何？ 

汽車自主控制功能，包括當前的車道，當前所處的路口，前方是否有車輛阻擋，前方是否爲路口，相位是 否已打開等等。由於汽車所處的狀態是一直變化的，不一樣車道的行爲時不一樣的，並且有隨機行爲，因此比較容易出現問題。

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

因爲時間限制，對關鍵模塊的代碼由測試人員進行了人工走查。

測試/發佈

1. 團隊是否有一個測試計劃？爲何沒有？

測試工做開始的初期就制定了測試計劃，測試計劃就肯定了軟 件的特性和測試範圍而且決定進行如下測試

Code Reviews

Blackbox Testing

Fault Injection

Stability Testing

在開發過程當中由開發人員完成了基本的單元測試和白盒測試。

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

在需求階段咱們定義了4個scope，目前咱們實現到第二個scope而且發佈了相應的Beta版。根據需求階段定義的系統特性咱們進行了驗收測試來確保系統實 現了預期的功能。咱們找不到最終用戶來幫助咱們進行驗收測試，因此是由軟件測試人員完成。

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

系統開發主要使用MFC技術，咱們沒有找到 比較適合的針對MFC程序的開源或者免費的測 試工具，更沒有時間來開發鑽用的測試工具，因此全部的測試代碼都是由開發人員和測試人員手動編寫。系統的特殊性決定了咱們很難找到合適的測試工具。

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

對軟件效能的測試主要是經過運行系統而且觀察結果來完成 的，軟件運行之後效能必須在用戶能夠接受的範圍之內，從軟件實際運行的結果來看這些測試工做仍是頗有效的，咱們前後爭對效能進行過兩次改進，每次改進都有 明顯提升運行效率。

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

在發佈過程當中遇到的意外問題就是上傳的資源意外被CSDN刪除，或者是因爲CSDN資源站不穩定致使用戶下載資源是出現「當前資源不存在」的提 示。咱們發現後又從新上傳了對應版本。