歷時四十天之久的教務終於結束了。哈哈哈。。。感覺像是死裡逃生啊。。。
下面對這四十天的工作做乙個總結：
說說每一階段的收穫和不足吧！每一次收穫都是在解決問題的過程中體會到的，同時也是通過解決問題，發現的自身的不足。我們的這個系統（教師教務部分：包括排課，教師教務管理，和課程安排三個板塊）特點就是邏輯比較亂，其實根本不是亂，而是我們自己對需求不太明白。同時還有一大特點就是和其他幾個（比如考試管理，自習室管理，和選課系統等）直接聯絡，所以做設計的時候還得兼顧這幾個系統的需求。再加上自身技術水平有限，同時也存在一些不良的學習和做事習慣，所以有了我們下面一系列的問題出現。
首先是開始做介面，讓我們根據自己的理解分析需求，然後根據需求做介面。當時因為需求不知道從**來，然後我們就根據自己的理解做了設計，當時對於自己的要求是這個系統肯定不會投入使用，所以可以隨便定需求。就這樣需求定了，但是後來由於大家意見不一致，有人要求標準高，有人要求標準低，所以再次去六期師姐那裡問需求，最後確定的是要有足夠的參考資料，然後基本保證系統可以滿足實際要求。這樣能找的資料都找過來了，需求定下來了（不過沒去找公尺老師問問這需求到底對不對）。我們的需求確定浪費時間還是比較長的，因為改了好多次。這裡我發現最根本的問題就是我們沒有明確目標，如果當時就定下來高標準，這樣可能就不會有後來那麼多的改動了（不過也正是由於改動，才讓我意識到了這個問題）。
其次，資料庫設計。資料庫設計當時因為根據自己抽象出來的名詞進行做資料庫（主要是組長跟組員商量後完成），資料庫中的字段根據我們的理解寫了，感覺還是挺對的，基本任務都可以完成。不過後期呢由於具體資料庫是組長設計的，我對我自己要用的資料庫呢不是特別的了解，所以後來又開始對組長設計資料庫的具體欄位的目的進行了解。然後呢既然這樣設計，自己也感覺還可以實現功能，也就這樣順著思路用了。不過到了後期呢才發現有些欄位和自己的理解是不一致的，出了一些問題。所以資料庫一定要誰用誰建，如果是像現在這樣的每個人負責一部分的話。我覺得這是後期資料庫出問題的根源。 最可怕的是到了後期該做介面層了，我們的資料庫又進行了一次重新建表。當然這一次不是因為自己需求不行（僅僅為了自己，肯定不這樣折騰）。這次僅僅是因為其他組乙個系統要做的事情從我們這裡返回的資料少了乙個字段。同時有了這個字段，原來的一張表得拆分成兩張表。為此都該做介面了，我們的幾張表又重新進行了一次拆分，然後從實體層重新做起到b層。這次失誤我覺得歸根結底就是我們做表之後沒有給其他組及時去溝通，當做完資料庫後各組都應該把資料庫文件去上傳，然後大家一起去看自己能想到或者能用到的東西，然後不滿足的及時去給對方溝通。這樣或許更能減少類似的失誤。
(續)
教務總結三（思想）
下面繼續教務系統的總結。說說做bll和介面的過程。做bll的時候才真正明白了需求，因為這個時候不徹底搞明白介面具體是做什麼的，那bll的方法就不知道改具體該怎麼寫。然後這時候才發現dal層缺少太多的方法，因為需求不了解嗎，所以大部分書寫的查詢方法都用不上。其實做dal層的時候想到了這些問題，就是到了...
教務系統總結
這次合作開發最大的不同點是，我們六個組分別負責有六個模組子系統，分別負責不同的系統，dal層和model層做好之後分別生成dll，除了介面層都是通過生成的dll檔案來呼叫，從而縮減了檔案和減少錯誤，只需要引用就行了。為了剛開始的開發的方便，我們每個子系統都有自己的資料庫，這樣就防止了把所有的資料放到...
教務系統後台總結
這次教務系統，我跟校林負責成績管理這部分。這一塊，總的來說不複雜。主要是對成績進行匯入和查詢。從開始分析需求到現在已經半個月了，後台 已經完工。目前開始著手做介面。將前面的工作總結一下。1.需求分析 這次的需求主要是參考正方的教務系統軟體。做需求的同時把系統的介面設計出來。正方軟體裡的成績管理的功能...