一、設想和目標

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

我們的系統是《聯邦型知識圖譜關鍵詞搜尋引擎》

由於計算機可以理解RDF 描述和攜帶的元資料的含義,因此可以做到基於內容的精確檢索。為此,我們的系統是一種基於RDF 的科技論文搜尋引擎而設計的。查詢結果為搜尋網頁的元資料顯示,從而使使用者對查詢結果有準確的瞭解,可大大提高使用者的搜尋效率。

     我們對我們所要解決的問題定義的非常清晰，目前，聯邦RDF 系統由許多自治的SPARQL 端點組成，SPARQL 端點只提供查詢介面而使用者不能通過此介面遠端下載資料集來建立全域性倒排索引，因此，關鍵字檢索受到了很大的挑戰。我們基於一種在聯邦RDF 系統上進行關鍵字搜尋的方法，通過SPARQL 端點上下文檢索把關鍵字對映到子圖結構中，然後通過子圖生成SPARQL 查詢來查詢Endpoints 上的資料集，而不需要在不同SPARQL Endpoints 上建立全域性倒排索引。為了提高查詢效能，我們設計了多重查詢優化策略來重寫查詢語句，廣泛的實驗證明我們的技術還是有效的。

我們的典型使用者為網路瀏覽者(即訪客)、網站註冊使用者、網站管理員。要求基本熟悉網路及Windows 操作規範，同時，基本瞭解Life-Science、Cross-Domain 兩個資料庫。

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

      我們的團隊在一輪迭代過程中有充分的時間完成研究與設計工作，並且開發過程中不斷完善我們的前端設計。

      這是第一次團隊的合作，正處於磨合期。所以效率不是很理想。而且除了這門課程之外還有其他的課程。所以第一輪迭代時間不是很充足。希望能夠在第二次迭代有所改進。

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

     我們經常在圖書館研討空間進行討論，會上大家會將自己的想法提出，每個人對於其他人提出的想法都會認真思考分析並提出自己的建議，大家一起商討可行性之後，對於計劃的是否實施與實施程度進行決策。

      在一些關鍵問題上面，我們採用投票的方式。使得大家的意見可以完整的、無拘束的表述出來。除了開會之外，我們組建了QQ群，如果有組員有什麼問題，都可以在QQ群裡面提出，老師也在群裡面，以方便對於專案決策的快速響應。組員們出現了什麼問題，大家也會一同解決，求同存異，一切以專案優先。

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

      在軟體開發前期一定要將整個架構做好，團隊一定要有明確的美工，否則每個人如果沒有做好自己的部分，會嚴重影響團隊的效率。

如果歷史重來一遍，那麼我們一定會改進上述問題：

首先是明確分工，

選出最適合審美的人來專職美化前端，提供各種素材與修改各種素材；

定義好介面，為每個人提供最適合他的分工，第一輪迭代我們每個人都完成了部分程式碼，第二輪迭代過程中為整個團隊的效率，團隊成員應該各司其職，做自己適合的部分，明確自己的職責，不要東做一下西做一下。

———————————————————————————————————————————————————

二、計劃

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

     我最初的原計劃基本完成，因為我們團隊經常一起討論，遇到問題可以及時解決，我們也不拖延，在規定的時間裡完成開發。在整個過程中，團隊的凝聚力都很強，雖然我們每個人都有很忙的事，但是都把專案這件事看得很重要。

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

      我們在設計的時候花了太多的時間在撰寫文件上，我認為這是浪費了我們很大的時間，雖然文件非常重要，但是作為第一次迭代開發，能夠有一個成型的東西才是最重要的。

2.3 是否項目的整個過程都按照計劃進行?

      專案在整個過程中並沒有完全按照計劃進行。所以專案雖然整體上跟上步伐，但是細化到每一天，確實不完全按照計劃進行。

2.4 將來的計劃會做什麼修改？（例如：緩衝區的定義，加班）

      將來的計劃主要會做以下幾個方面的修改：

    1.在實際開發中會更加註重介面定義以及模組測試。

    2.緩衝區的時間需要留的更長一點，特別是在後期，還有期末考試，大家的時間會更少，所以應該留夠更長的緩衝區。

    3.任務分配更加平均：這次的任務其實有明顯的不平均的情況，導致有的組員做了很多工作，有的組員做的就稍稍少了一點，之後的任務分配會更加的公平，旨在發揮每個組員的最大潛能。

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

總的來說，這次的專案我們學到了很多知識。

如果歷史重來一遍，就像我剛才說的，我們會做四件事情：

    1.在實際開發中會更加註重介面定義以及模組測試。

    2.緩衝區的時間需要留的更長一點，特別是在後期，還有資料庫，編譯大作業，大家的時間會更少，所以應該留夠更長的緩衝區。

    3.任務分配更加平均：這次的任務其實有明顯的不平均的情況，導致有的組員做了很多工作，有的組員做的就稍稍少了一點，之後的任務分配會更加的公平，旨在發揮每個組員的最大潛能。

三、設計/實現

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

      設計工作是大家一起完成的。每個部分的設計詳情可以參考我們的會議記錄。應該說專案一拿到第一時間就是完成設計工作，而且每個模組的設計人員都是對那個模組很感興趣，最後的設計都是很有意思的。

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

      專案中有些模組的設計確實碰到過模稜兩可的情況，會隨著專案的進展進行確定下來。

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

      首先每個模組寫完，我們會有一位同學負責（我）程式碼複審。然後程式碼彙總後，再一次進行復審。

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

      最初設計的時候並沒有很完整把整個框架都設計出來，這也導致了開發過程進行到了一半時各個模組的工作進度沒有協調好。介面沒有設計好，導致一些功能實現的難度增大。

 -------------------------------------------------------------------------------------------

四、總結

4.1你覺得團隊目前處於 萌芽/磨合/規範/創造階段的哪一個階段?

      我們正處於第二階段到第三階段的過渡狀態，目前團隊正處於磨合到規範的過渡狀態。在前幾周的工作之中，我們團隊相互磨合，已經較為成功的完成了整個專案的第一次迭代。並且在這之上我們定義了相關的文件，已經將程式部分規範化。大家協同作戰，成員們就很多事情取得了一致。

4.2你覺得目前最需要改進的一個方面是什麼?

     成果可維護性、可移植性不是很高。所以我們下一步會更加的規範這一類的程式、文件。爭取在第二次迭代中期進入CMM中第三階段，使團隊狀態處於規範階段。

4.3 什麼是在下個階段要改進的地方?  越具體越好。

    這個階段的不足，以及下個階段要改進的地方，已經都在上文中列出了。主要的問題如下：

    1、正式開發前沒有完全定義好介面，使得整合工作難度加大。

    2、分工上沒有完全利用好團隊資源。也是由於經驗不足，我們在分工的時候確實對某些模組的工作量和難度有誤判，導致有特長的同學的同學反而沒有發揮的空間。

最後，願我們小組在第二輪迭代中，發揚優點，改正缺點，共同進步！