大專院校排球聯賽系統

目錄 * 摘要 ……………………………………………… P.2 * 動機 ……………………………………………… P.2 * 系統簡介與目標 ………………………………… P.3 * 開發方法 ………………………………………… P.5 * 系統概念圖 ……………………………………… P.6 * 活動範例圖(Use Case Diagram)……………… P.8 * 活動圖(Activity Diagram)……………………… P.9 * 工作分項架構(WBS)…………………………… P.9 * 網狀圖(Network Diagram) …………………… P.10 * 甘特圖(Gantt Chart) ………………………… P.11 * 目前進度 ………………………………… P.12

* 摘要 大專院校排球聯賽是一年一度重大的體育盛事，以前尚未擁有此排球聯賽系統時，所有的相關作業完全仰賴人力完成，包含繁複的報名作業、分組抽籤與賽程排定，往往需要花上許多個月來完成賽前工作，隨著網路的普及與科技的發展，我們希望可以透過電子化來節省部分的人工且藉由網路加速資訊傳遞的速度，而目前舊有的「大專院校排球聯賽系統」就是在這樣的背景下產生的。 然而隨著時間的推移，舊有的「大專院校排球聯賽系統」已經逐漸不敷使用，且不夠完善的功能使得使用者在系統操作上皆遭遇到一定程度的困難，為了解決這些問題，我們決定從現有的制度且在慎重考慮使用者的需求後，重新規劃一個完整的系統取代舊有的系統。

* 動機 目前現有的「大專院校排球聯賽系統」（以下簡稱舊系統）已經使用許多年了，在整個比賽中有著舉足輕重的地位，然而，因為當初系統設計上的不良造成使用上諸多的麻煩，例如系統執行上的錯誤、資料庫的關聯建立不完全、沒有完整的系統說明書等問題，對於後續接手此系統的人員而言無疑是個惡夢，管理者必須直接修改程式碼才能得出正確的結果，而錯誤的結果也會使得此聯賽的前置作業時間延長，如果情節嚴重，不只會延宕後續比賽的進行，也會影響參賽隊伍、裁判、控制委員的個人權益，比賽的公平性、公正性也會有所牽連，影響層面之廣絕不可輕忽。由於上述諸多弊病，我們決定重新設計一個新的系統以支援大專院校排球聯賽。

* 系統簡介與目標 有鑑於舊系統因為設計上的不良而造成後續使用與維護的諸多困難，造成系統使用周期太過短暫，因此我們想要設計出能夠「長期使用」的系統，除了要配合最新的比賽規則之外，也試著從使用者的角度出發，考量到不同角色的使用者需求進行個別規劃，因此資料庫的設計也需要更謹慎小心。依據不同的角色配置不同的功能與權限，將會是我們新系統發展的重點，設計友善的使用者操作介面且正確的執行結果更是不可或缺，此外我們希望新系統不管是使用或者維護都能更簡單、方便，讓未來接手的人員可以快速的上手。 此大專院校排球聯賽系統主要有六種角色，包含管理者、裁判、控制委員、分區負責人、主場學校與一般使用者，除了要整合比賽資訊、建立完整的賽程表之外，也要詳實記錄比賽成績與排定名次，本系統同時也是大專院校排球聯賽委員會對外發佈公開資訊的管道，因此如何充分扮演好傳遞資訊的橋樑也會是我們的目標之一。

（表一）新舊系統之間的比較圖表 新舊系統之比較 | 舊系統 | 新系統 | 人工處理部分多(例如：登記比賽成績、名次計算)，資訊傳遞速度緩慢。 | 人工處理部分少，提高資訊傳遞速度。 | 資料存取重覆性高，系統負擔增加。 | 資料間重覆性降低，減少記憶體空間的浪費。 | 資料庫眾多，不易維護。 | 單一資料庫的建立，以資料表代替資料庫，提升存取效率且方便維護。 | 賽程錯誤率極高。 | 賽程錯誤率低。 | 介面雜亂。 | 介面簡潔流暢。 | 功能不完善 | 功能完整，方便使用者操作。 |

另外，舊系統在使用者操作上相當不符合人性，假設一使用者同時擁有一個以上的角色時，需擁有多個帳號配合不同的角色，並由不同的頁面登入；然而，新系統解決了此項問題，將一使用者同時擁有的角色做整合，使得有多種角色的使用者操作時不需擁有多個帳號配合不同的角色和開啟不同的頁面。下表列舉部分見面做對照，其中新系統合併多角色的部分，以裁判和控制委員作範例。
（表二）新舊系統之間的介面對照
舊系統介面 | 新系統介面 | | | 首頁 | 首頁 | | | 控制委員 | 裁判+控制委員 | | | 裁判 | 分區負責人 | | | 管理者 | 管理者 |

* 開發方法 由上圖比較表所述，舊系統本身存在許多架構上的問題(例如：資料庫繁雜導致資料維護、存取不易)，但基本上六位使用者的功能需求已有相當明確的方向，未來不太可能會有大變動，因此我們採用「瀑布式開發」(Waterfall Model)流程的系統設計方式，在程式設計開始之前即與使用者確認系統所有功能與需求，將可能的變更次數降至最低。以下是我們的開發流程： * 計畫 Planning： 1. 初期階段藉由操作舊系統的各種功能熟悉其運作方式以及一般使用者所需的各種功能，推斷該系統需要加以改善的地方 2. 實際參加大專院校排球聯賽賽程之排定，與使用者面對面接觸，了解舊有系統的不足 3. 蒐集歷年賽程相關資料與比賽成績，建立資料庫以利查詢 * 分析 Analysis 1. 透過蒐集來的歷史資料，研究其關聯性，轉化為方便使用者閱覽之可用資訊，減少使用者查詢時間(例如:查詢賽程相關事宜) 2. 賽程排定之演算法的分析 * 設計 Design 1. 使用者介面之美化設計，利用繪圖軟體製作網站樣式以及簡單、易操作的友善介面 2. 單一完整資料庫之建立，改善舊系統資料庫眾多、維護不易且造成資料重覆存取性高等問題 * 實作 Implementation 1. 介面採用CSS語法，再利用photoshop、flash等軟體，繪製出實際網站頁面 2. 系統程式碼之撰寫以PHP語法為主 3. 整合介面以及程式碼，測試系統完整性及可用性

* 系統概念圖

* 活動範例圖(Use Case Diagram)

* 活動圖(Activity Diagram)

* 工作分項架構(WBS)

* 網狀圖(Network Diagram)

[分工項目摘要說明] A. 系統內容架構討論：
了解舊系統的架構，並提出可以改善的地方。
B. 系統計劃書之撰寫：
包含研究動機、系統簡介及系統流程圖。
C. 系統介面流程之模擬：
利用簡報動畫呈現使用者進入網頁時的操作情形，展示不同角色的使用者可使用的功能及流程。
D. 參賽隊伍資料蒐集：
蒐集、彙整歷年參賽隊伍資料。
E. 角色功能模組配置：
依據角色權限的不同設計其功能模組。
F. 網頁架構與美工設計： 網頁版面構思及美工設計。 G. 系統平台介面完成：
互動式頁面撰寫，呈現網頁的完整樣貌。
H. 系統資料庫設計：
依資料關聯性與角色功能需求設計系統資料庫。
I. 分組賽程排定之演算法：
依系統需求統整邏輯概念及邏輯概念圖的構思。
J. 系統程式碼撰寫：
使用PHP及CSS語法建立此系統。
K. 程式整合與測試：
整合內部程式並進行除錯。
L. 系統內外部合併與檢測：
結合資料庫與網頁設計、對各項功能做測試，並且美化頁面，減少網頁使用的障礙性。
* 甘特圖(Gantt Chart)

* 分工項目： A. 系統內容架構討論： 11/01 – 12/04 B. 系統計劃書之撰寫： 12/04 – 02/01 C. 系統介面流程之模擬： 01/16 – 02/11 D. 參賽隊伍資料蒐集： 01/16 – 01/29 E. 角色功能模組配置： 01/28 – 02/24 F. 網頁架構與美工設計： 02/04 – 04/14 G. 系統平台介面完成： 04/14 – 05/25 H. 系統資料庫設計： 01/30 – 03/01 I. 分組賽程排定之演算法： 03/01 – 04/01 J. 系統程式碼撰寫： 04/01 – 05/05 K. 程式整合與測試： 05/05 – 06/01 L. 系統內外部合併與檢測： 06/01 – 07/01

* Milestone：
1完整系統架構之審查： 12/04
2系統計劃書內容之審查： 02/01
3功能模組與資料庫設計完成： 03/01
4系統外部設計雛型審查： 04/14
5內部系統完成審查： 05/05
6系統整合審查： 06/01
7系統上線實測： 07/01

* 目前進度
由於我們專題開始的較早，因此在規劃上各階段預期的時程相較於其他專題組明顯提早許多。總體而言，進度皆依照甘特圖上的計畫持續進行，目前為止已完成四項milestone，現階段的重點著手於系統程式碼撰寫與系統平台介面的製作，預估將在5/5如期達成第五項里程碑，且在七月份完成此大專院校排球聯賽系統。
此外，在改善舊系統缺點方面也有很大的進展。發展中的新大專院校排球聯賽系統規劃能夠使委員會更加快速、簡單地完成聯賽前置作業，減少眾多的人力與時間成本；又因為新建立的資料庫相較於舊系統而言，資料間的關聯性更加完整，因此能夠有效地避免因不必要的資料存取而造成之系統錯誤。
同時，新系統也解決了舊系統介面繁雜與功能不完善的缺點。在新大專院校排球聯賽系統上，我們以簡單的畫面顯示各項功能，按鈕排列整齊、易於點選，且使用步驟標示清楚、簡明扼要，能夠讓使用者操作更加便利。
接下來我們將會致力於使用者功能之開發與系統介面的美工設計，希望在有限的時間內讓此系統更趨完善。