整體系統的程式開發主要集中在 Android Client 及 Mantis Plug-in 上，其餘 的部份透過系統整合為主。
4.2.1 Android Client
Android Client 功能主要為回報問題及查詢為主，功能上較為陽春，不過已經 可以達到作業上的需求，其功能有四個部份：
1. 設定：設定 Mantis 的位址及使用者的帳號密碼。(圖 15)
2. 新增問題回報：回報問題至 Mantis 系統，並有方便的附檔功能，可以於照 像後或直接將檔案上傳至 Mantis 系統。(圖 16)
3. 查詢及其它功能：目前暫時以自動登入 Mantis 網頁為主，其功能由原 Mantis 界面提供，因為其它功能不需要有上失敗暫存功能，故以 Mantis 功能，增加自動登入功能即可，因原系統開發商已有開發手機版網頁功能，
故不再重複開發現有套件。(圖 17)
4. 斷線上傳問題功能：原問題若在上傳過程中上斷線情況時，系統會自動將 資料記錄在行動裝置之資料庫中，待回復連線後再手動將問題上傳。(圖 18、圖 19)
圖 14：主畫面 圖 15：設定畫面 圖 16：回報及附件
圖 17：查詢及其它功能
圖 18：暫存問題列表 圖 19：暫存問題處理
流程圖如下：
圖 20：Android 程式流程
在問題回報時，透過回報界面(圖 16)，於進入界面時，系統會先透過 Ksoap2 向 Mantis 系統詢問專案、類別、出現頻率、嚴重性、優先權等列表，讓回報人員 作選擇，填妥摘要與說明後，可透過界面利用 Android 系統的 Intent 呼叫，使用 照相、檔案管理等工具，將檔案夾帶於問題附件。
當回報人員將資料填妥後，系統便會透過 Ksoap2 將資料上傳至伺服器，若網 路有問題時，則會暫時將資料存在行動裝置的資料庫中，其資料庫在安裝 Mantis Client 時便會自動產生，並向系統註冊，待網路可用時，則可透過未傳列表(圖 18) 選取要上傳的資料，選取上傳(圖 19)。
在整個撰寫 Android 裝置的過程中，其實遇上了不少的問題，其中之一就是行 動裝置的記憶體有限，雖然 Android 可直接使用原生的 Java 函式庫，不過這類的 函式庫大部份是針對桌上型電腦或伺服器，所以應用在行動裝置上時，記憶體的管 理上就比較沒那麼輕鬆，有時容易產生記憶過不足的錯誤，例如在上傳檔案時，因 為使用 SOAP 界面，所以必產生一份 xml 檔案，若檔案太大則會產生錯誤而無法上 傳，取代的方式便是捨棄 Ksoap2 的函式庫，改採 Http 連線的方式，一邊產生 xml 文件，同時上傳 xml 文件。
另外一個問題是由於 Android 的作業系統是仰賴各家廠商自行實作，所以對於 其功能未必有完整實作，如：SQLite 的 Data Cursor，於 Motorola 的 Milestone 2
的方式替代，如此的不相容會造成開發上的困難。
4.2.2 Mantis Capability Graph
在 Mantis 上所開發的功能，為一個 Plug-in 功能，可以分析其問題記錄，並 產生能力指標，其指標的計算方式如前述，其安裝方式為 Mantis Plug-in 的標準 安裝方式，其套件名稱為 Capability Graph，如下圖 21：
圖 21：Mantis Plug-in 管理介面 功能路徑為：管理->套件管理
Capability Graph 的功能在於計算出能力指數，故需先設定規格，因此功能上 會有規格編修及報表二部份，如下圖 22：
圖 22：報表規格列表
功能路徑為：統計資訊->Capability 報表
圖 23：設定報表規格
如圖所示，其規格需設定上下限、目標值、方向值及計算類型，上下限值及目 標如字面意思，即規格的上限值、下限值及其望的目標值，而方向則是平均值則分 為近目標為佳、小於目標值為佳，還是大於目標值為佳，其計算是影響 Ca值。
類型的部份共有六種：
1. Solving Time / Issue：指的是每個問題從回報到結案或解決的處理時間。
2. Reassign Times / Issue：每個問題被重新指定負責人的次數。
3. Times / Hour：每小時問題發生的次數。
4. Times / Day：每天問題發生的次數。
5. Times / Week：每星期問題發生的次數。
6. Times / Month：每月問題發生的次數。
完成以上的設定後，便可於報表選取規格，計算能力指數。
計算的方式，是以專案的類別來分類計算，對於不同的類別，其規格應該不相 同。如圖 24 先選專案、類別，再選取報表規格，並選取計算的區間，按下查詢之 後，便會顯示能力指標及圖表：
圖 25：報表結果
於上圖可以看出其 Cp、Ca、Cpk值及分佈情況，透過不同的時間可以比較其能力 是否有已進步。
Mantis 與維基系統透過整合，可於每個 Issue 連結至維基系統，將記錄與知識 作連結，如下圖：
圖 26：維基系統連結
如圖 26，整合 Mantis 後，於 Issue 上方會有 Wiki 連結，可連結至維基系統作 編修知識(圖 27)，其知識可以作為日後的參考。
圖 27：Wiki 例子
4.2.3 維基系統標記
在 Dokuwiki 系統中，新增加二個標記功能，分別為 Exam 及 Note，此二個標記 功能主要在於未來若需要作訓練或測驗時使用，Note 的功能，可將維基系統中重點 的部份標記下來，透過 Parser 程式，可將筆記的部份獨立出來，產生 PDF 或文字 檔等，方便未來產生重點筆記或技術文件、投影片等。
而 Exam 的部份，則可以在維基系統中，即時標記題目，在未來需要產生測驗 的時候，透過擷取程式將題目擷取出來，產生題庫，應用在紙本或其它測驗系統來 應用。
這二個功能在維其系統產生文件的時候，會將呈現方式作一些改變，以方便閱 讀，而不會在文件中看到標註碼而影響閱讀，這二個功能之所以採內嵌的方式，主 要是使文件的的撰寫人可以在撰寫文件的時候，可以不必再到其它系統撰寫、維護 題庫，而可以在同一份文件內就將題庫、筆記、技術文件等一次完成，除了可以減 少撰寫的負擔外，對於文件更新時，不必再手動同步其它系統的資料，減少管理上 的麻煩。
Exam 功能是透過 plug-in 的系統，產生測驗的題目，在維基系統的文件編輯完 成後，維基系統頁面，會將答案隱藏，需透過反白才可將答案顯示出來，規格如系 統設計時所規範，其實作完成後例子如下：
圖 28：Exam 例子
如上圖(圖 28)例子，exam type 共三種，產生後的文件如下(圖 29)：
圖 29：Exam 結果 圖 30：Exam 答案
其產生的文件，會將答案隱藏，透過選取反白，方可將答案顯示出來如圖 30。
Note 系統，亦是透過 plug-in 的方式，將資料標記下來，於維基系統產生閱讀 文件時，將作文筆記的部份畫上標線，筆記 Title 的部份文字會以藍色，而內文則 以綠色標記文字，Note 系統了支援維基系統的標記方式，故在 Note 系統內可以使 用維基系統語法，其實作完成後例子如下：
圖 31：Note 標記 圖 32：Note 結果
上有一個標題，二個內文，其產生後的閱讀文件如圖 32，其 Note 標題的部份 會被轉成藍色，且會產生上標線，而內文的部份為綠色，項目的部份，只有上標線 為綠色，透過顏色和標線，方便閱讀的人知道哪些項目被標記成了筆記。
其它尚有一些現成的維基系統的外掛，如 wiki slide、wiki book…等，對於 這些知識的再運用，都有良好的幫助，不會使得這些知識因為雜亂、無結構而失去 運用的可能性。
五、結果與分析 Application 來記錄、查詢資料，達成彈性運用、即時記錄的目的，不會 因為沒有電腦系統而造成問題無法記錄、追踪，且可以透過各式的行動裝
透過新增的標記功能，可以將知識作標記，於將來可以透過類似 Javadoc 的擷取程式，將題目抽出，作為其它測驗系統的題目來源，或者將重點筆
一般而言，人員異動時，於過往的知識常常就隨著人員而消失，導致知識
Issue Tracking System for Knowledge Accumulation
Bug Tracking
System FDC 客服系統
生多樣化應 用，如：測驗、
投影片…等。
建置成本
因為使用的皆 為 Open Source 系統，故系統成
六、結論及建議