網頁開發/PTM培訓

PTM_Training 專案是由蒙大拿大學教育學院的 Mdj 教授（以下簡稱“客戶”）的工作訂單啟動的，由蒙大拿大學中央網路服務團隊（以下簡稱“機構”）負責開發，團隊負責人為 RobertB。^[1]

專案啟動

開發團隊由以下人員組成：

• SteveM（應用程式開發人員）；
• AndrewL（應用程式開發人員）；
• RonaldS（生產伺服器的系統管理員）；
• PattyZ（圖形設計師）；以及
• 學生團隊（三到五名在 SteveM 和 RobertB 的監督下的本科生，根據需要協助專案）。

工作訂單規定，專案將包含一個基於網路的“專業培訓介面”，供教育學院（以及其他機構）使用，以協調和發展教師之間的專業發展機會。

所有專案工作都在大學校園設施內進行，使用機構擁有和維護的開發和生產伺服器。客戶同意向機構支付開發和維護費用，工作根據雙方之間的書面諒解備忘錄（以下簡稱“MOU”）進行。

專案階段

專案階段（由 RobertB、SteveM 和客戶事先確定和同意）包含以下內容：

• 定義階段
• 設計階段
• 開發階段
• 部署階段
• 維護階段

定義階段

挑戰

• 工作訂單和 MOU 都沒有包含詳細的功能集規範或現有示例應用程式作為參考。
• 客戶提出了一些相當新穎的想法，這些想法將阻止簡單地重複使用現有程式碼資產。
• 客戶打算將專案成果用於向其他學院和州政府機構的演示。這將給專案成果帶來“令人印象深刻”和“功能性”的壓力。
• 專案啟動時間相對於學術日曆，基本上保證了學生工人的員工流動。
• 學生團隊中的一些成員在他們將要幫助的領域幾乎沒有或根本沒有經驗。

優勢

• 該機構擁有相當可觀的生產資產組合和一支技能合理的員工隊伍。這意味著應用程式開發人員在選擇開發工具和作業系統方面具有一定的靈活性。
• 專案某些方面的創新性和知名度意味著，RobertB 在建立優先順序和在緊急情況下請求額外資源方面給了開發團隊一些自由。RobertB 還注意與客戶建立合理的期望，因此客戶也允許專案交付成果具有一定的靈活性。

響應

• 由於專案的相對高知名度，它必須在缺乏完整定義的專案規範的情況下繼續進行。“定義”階段將不得不不時地重新審視。鑑於此，SteveM 選擇使用專案“增量原型”策略來進行。
• SteveM 選擇的技術主要基於以下考慮：可用的員工隊伍的熟悉程度最高、易於使用、易於建立原型以及一旦定義和設計確定後，便於遷移到“生產”基礎設施。

這些包括：

• Microsoft Access（設計階段資料庫，將遷移到 MSFT SQL Server 以用於生產階段）；
• Allaire（現在的 Macromedia）Cold Fusion Web 應用程式伺服器；

功能集規範的開始

SteveM 和 AndrewL 繼續與客戶合作，以獲得所需功能的精確定義。

在與客戶進行了幾輪迭代諮詢後，雙方一致同意，以下功能是必需的：

• 與最新版本的微軟 Windows 上使用的兩個最受歡迎的瀏覽器相容的 Web 應用程式；
• 能夠透過網路登入的使用者帳戶；
• 透過網路以匿名方式訪問有限的功能；
• 能夠透過網路修改 Web 應用程式的各個方面並管理使用者帳戶的管理帳戶；
• 一個“可換膚”的圖形應用程式介面，也可以由管理帳戶修改和管理；
• 支援使用者活動審計、記錄儲存、統計和例行報告；

SteveM 得出結論，該應用程式本質上將包含一個混合的線上：1）產品目錄；2）事件管理系統；3）課程管理系統（支援學分和“評分”）；4）基於角色的身份驗證系統；以及 5）討論論壇。

在專案啟動時，沒有現有的產品或資源可以滿足客戶的期望，因此證明了內部開發優於現成購買。

設計階段

SteveM 和 AndrewL 開始設計資料庫架構。SteveM 開始著手 Web 應用程式的框架。為了進一步簡化開發並增加成功交付的可能性，SteveM 選擇使用 ColdFusion 的“FuseBox”應用程式框架進行編碼。

在初始設計階段的一半時間裡，AndrewL 被調到另一個專案，因此他能夠在 PTM_Training 上投入的時間大大減少。這要求 SteveM 承擔設計方面的全部責任，也需要更多同時進行的技術文件，以便 AndrewL 在有時間幫助時，能夠及時瞭解系統。

開發階段

SteveM 主要與學生團隊合作，進行開發的最初階段。在本學期結束時，學生團隊規模大幅縮減。

挑戰

• 可用的學生開發人員幾乎沒有或根本沒有計算機程式設計經驗。

響應

• SteveM 建立了例行程式碼審查會議，以跟蹤學生開發人員的進度。這些程式碼審查包括讓學生有機會重新分配時間，並在可行的情況下，自行選擇更符合他們能力和偏好的任務。
• 對所有程式碼模組都進行了例行的單元測試，以確保不會出現資料完整性問題。這是必要的，因為專案的“即時”使用過早地開始了，並且資料庫包含人們實際關心的資料，丟失這些資料是不可接受的。雖然這違反了最佳實踐。但這在早期就被預測到了，因為專案定義階段確定了專案的性質和範圍。

部署階段

專案的部署包括將程式碼庫遷移到生產 Web 伺服器機器，並將資料庫內容和架構轉移到 MSFT SQL Server 主機。部署並不困難，但是，在開發機器和生產伺服器之間，在名稱解析和資源分配方面存在一些“棘手”問題。這些問題很快就被追蹤到，程式碼被重構以進行補償。

維護階段

維護被證明是整個系統開發中的一個持續性元素，但具有諷刺意味的是，在專案的第一個可交付成果部署以供使用並提供給客戶後，它並沒有成為一個重大問題。最終，客戶對該專案進行了一次相對富有成效的演示，程式碼和資源後來被一家外部公司收購。SteveM 和客戶是該系統的命名作者，並因購買的程式碼庫獲得了版稅。在 SteveM 進行初步諮詢和審查階段後，所有進一步的維護和擴充套件程式碼庫的工作都由外部公司管理，以便他們能夠熟悉系統的基本要素。