面試過程中描述項目一般分爲三大點（第一點是參考說辭。後兩點是可補充的說明，個人可根據具體情況介紹）
1、項目的開發背景介紹以及個人在項目中完成的功能點
2、項目的開發過程（開發週期）
3、項目的系統架構
1、項目開發背景以及個人完成的功能點介紹
我們這個項目是爲XXX公司開發的一套辦公自動化系統，簡稱OA。該公司屬於XX行業，業務類型主要是XXX，該公司爲了提高辦公效率與辦公質量，實現無紙化辦公與科學的管理而委託我們公司研發該系統。通過需求調研與設計，我們將該項目劃分爲了XX個大的模塊。主要包括 XXX。。。而本人在該項目中主要負責組織機構與權限管理兩個大模塊的設計，開發，調式以及維護等工作。
組織機構模塊主要是對該公司的部門以及人員的管理。所以在此模塊中我們又分爲機構管理與人員管理兩個子模塊。由於該公司的機構屬於職能型機構，父機構下面又存在子機構，就像一個樹狀結構，所以我們在設計該模塊表的時候使用了自關聯的方式，這樣可以減少數據庫設計的允餘，也便於擴展。而人員模塊設計比較簡單，就是直接在表中加入了一個機構的外鍵，因爲人員肯定是屬於某個部門的。
至於權限模塊的設計就稍微複雜點。任何一個項目都會根據需求來設計相應的權限操作，權限也是我們保證項目健壯性的一種手段。在此模塊中我們分爲用戶管理，權限管理，角色管理三個子模塊。因爲首先我們考慮到應該爲每個人員建立一個唯一的登陸賬號，我們稱爲用戶，我們將權限不直接授予具體人員，而是授予相應的用戶，這樣就可以降低耦合度。但是如果具有相同權限的人都需要重複授予一樣的權限，客戶操作起來會很麻煩，而人員在公司一定有其相應的職位，所以我們決定將權限打包授予某個角色，讓角色與具體職位關聯，再將角色授予用戶，這樣就能很好的解決問題了。不過一般來說，公司有些人員可能身兼數職，也就是說一個用戶可能會被分配都多個角色，默認情況下我們是取所有權限的合集，但也會出現角色之間權限的衝突問題，因此我們在表中設計了一個優先級的字段，讓一個用戶擁有的多個角色有不同的優先級，如果權限產生了衝突，則以優先級高的角色爲準。有點類似我們web程序中加載servlet時候配置的load-on-startup的屬性。
當我們將項目交與客戶試運行後，客戶反映，無論什麼情況都需要通過建立角色來授權感覺很麻煩，而公司的職位變動也會引起角色的增多，造成角色的泛濫。所以通過與客戶的溝通，我們修改了當初的設計，也就是除了可以通過角色來授權，也可以給用戶直接授權。這種方式與oracle數據庫的授權方式是一樣的，客戶也感覺很滿意。當然，既然可以直接授權給用戶，也可以授權給用戶所屬的角色，同樣會發生類似於開始說的兩者之間權限的衝突問題，我們解決的辦法同樣是多設計了一個字段，該字段表示是否使用用戶自身的權限還是使用其角色的權限。
我們這個項目的權限分爲三級，首先在用戶登錄的時候就開始驗證是否有資格進入，（這是第一級）在通過該驗證後，我們會查詢出該用戶擁有的所有具有可讀功能的模塊並展示，對於該用戶不可讀的模塊是不會展示出來的，這樣能避免用戶的誤操作（這是第二級）。但有些模塊該用戶雖然具有可讀權限，但是沒有更新與刪除等權限，我們此係統也可以及時屏蔽該誤操作（這是第三級）。
2、項目開發週期
本項目總開發週期爲1年，具體分爲以下幾個階段
1、需求分析階段，由系統分析員對客戶進行需求調研，產生需求分析說明書，經客戶簽字確認。
2、概要設計，由系統分析員根據需求分析書編寫概要設計文檔，經客戶簽字確認。
3、詳細設計，由系統分析員和架構師根據概要設計文檔編寫詳細設計文檔，經客戶簽字確認。
4、用戶手冊，根據以上三個文檔編寫用戶使用手冊
5、數據庫設計，由系統分析員做數據庫架構設計，生成數據字典
6、系統架構設計，由系統架構師做整個系統的架構設計，產生架構說明文檔
7、分模塊編碼，主要由程序員進行分模塊編碼，並由測試人員對模塊進行交叉測試
8、系統集成（也叫產品集成）
9、集成測試（對整個系統的產品結構功能進行整體測試）
10、上線試運行，將集成後的產品交付給客戶進行試運行，對試運行期出現的錯誤進行修改
11、產品交付，試運行完後，如果產品沒有什麼問題之後，對客戶交付產品
12、後期升級與維護(根據合同規定)
3、系統架構
本系統是基於J2EE平臺，採購B/S模式進行開發，數據庫採購oracle，系統框架採用當今主流的SSH集成。分層架構進行開發，主要分爲數據層、業務層、界面層。