高點
‧高上
【版權所有，重製必究！】
108年高上高普考 ‧ 高分詳解
-- -- 1
《系統專案管理》
試題評析
本份試題返璞歸真，集中於系統分析與設計之基礎概念。第一題為需求分析之訪談；第二、三題 為系統分析基礎之開發階段、敏捷式開發模式；第四題則為系統轉換。學員如熟悉課程內容，應 可獲得一定程度之高分。
考點命中
第一題：《高點‧高上系統專案管理講義》第三章，張又中編撰，頁3-5～8。
第二題：《高點‧高上系統專案管理講義》第一章，張又中編撰，頁1-37～38；
《高點‧高上系統專案管理講義》第二章，張又中編撰，頁2-4～6；
《高點‧高上系統專案管理講義》第四章，張又中編撰，頁4-37～38。
第三題：《高點‧高上系統專案管理講義》第二章，張又中編撰，頁2-18～23。
第四題：《高點‧高上系統專案管理講義》第四章，張又中編撰，頁4-39～40。
一、你受命要去訪談購買北迴線車票的民眾，了解這些民眾向臺灣鐵路管理局購買車票時的情境與 流程，你被告知訪談結果必須涵蓋 5W1H 的描述：
(一)請問訪談為什麼要運用 5W1H？（10 分）
(二)請用 5W1H 的方式，簡述你可能的訪談問題有那些？（15 分）
答：
(一)訪談為最有效且最普遍的資料蒐集方法。訪談時系統分析師與使用部門的主管或相關作業人員面對面討論 實際作業的情況、所需報表和資訊需求等。訪談期間，系統分析師需要蒐集事實、選擇或推測，故需要 5W1H 來釐清相關流程的人、事、時、地、物，以定義使用者需求。
構面 描述
What 描述發生的問題、現象與癥結點。
Why 釐清為何造成此問題、現象與癥結點，及其所造成的影響。
Who 找出問題、現象與癥結點的利害關係人。
When 問題、現象與癥結點發生的時間。
Where 問題、現象與癥結點發生的地點。
How 問題、現象與癥結點發生時，使用者行為或相關的流程。
(二)
構面 問題
What
透過什麼管道購買北迴線車票？
現有管道購買北迴線車票的問題？
是否已有解決問題的方案？
Why
購買北迴線車票的目的？
什麼原因造成現有管道購買北迴線車票的問題？
解決方案是否真正解決了問題？
Who
向誰購買北迴線車票？
幫誰購買北迴線車票？
第三方業者的利益為何？
When
什麼時間點購買北迴線車票？
購買流程花費的時間？
取票流程花費的時間？
Where
在哪裡購買北迴線車票？
到哪裡取票？
利用什麼裝置購買、拿取北迴線車票？
How
如何購買北迴線車票？
購買北迴線車票的流程？
取票的流程？
高點
‧高上
【版權所有，重製必究！】
108年高上高普考 ‧ 高分詳解
-- -- 2
二、 你剛剛被首長任命擔任新陶市消防機關下一代指揮派遣平台開發專案的系統分析師。請問什麼 是「系統分析師」？請以這個專案為例，說明未來你這位系統分析師在設計與開發這個系統的 各個階段，包括：(一)系統分析（5 分）(二)系統設計（5 分）(三)系統測試（5 分）(四)系統上 線（5 分）(五)營運維護（5 分）等階段，將負責那些可能的工作內容。
答：
系統分析師為在資訊系統開發中，負責需求分析、確認系統需求，進而形成系統設計的資訊專業人員，其 通常會涉及可行性評估、系統規劃、需求驗證、專案管理等工作。
因此，系統分析師不僅需要電腦軟硬體知識，更重要的是如：IT設計、規劃、開發，以及評估等系統技 術。此外，由於相關工作龐雜，需要集合相關成員成立一個專案小組來完成。因此，其人際溝通技術相當重 要。
(一) 系統分析(System Analysis)
建立系統的邏輯模型(Logical Model)，第一步進行需求塑模(Requirement Modeling)，最終交付成果為系統 需求文件。
系統分析師於此階段，可能的工作內容為針對需求進行分析，以便將系統需求抽象化至應用系統中。簡而 言之，即為從系統需求找出解決方案。
(二) 系統設計(System Design)
創造出滿足所有需求的實體模型(Physical Model)，設計使用者介面，以及必要的輸入、輸出、流程與內外 部控制。
系統分析師於此階段，可能的工作內容為建立完整的解決方案，詳細描述如何建立整個軟體系統來滿足定 義的系統需求。
(三) 系統測試(System Testing)
如同工廠生產線的品質管制，其目的是確認已經成功建立一套可用的軟體程式。
系 統 分 析 師 於 此 階 段 ， 可 能 的 工 作 內 容 為 檢 查 實 作 建 立 的 程 式 是 否 符 合 定 義 之 需 求 ， 即 證 實 (Verification)；以及測試是否真正解決客戶問題和滿足客戶需求，即驗證(Validation)。
(四) 系統上線(System Online)
目標為交付一功能完整、運作正常且具完整文件的系統，包含系統評估(System Evaluation)，以確保系統是 否運作正常、成本與效益是否符合預期。
系統分析師於此階段，可能的工作內容為將最終釋出版本的軟體交至客戶的使用者，包含軟體安裝、教育 訓練和使用手冊等。
(五) 營運維護(Operation and Maintenance)
系統上線後，後續的維護、加強與保護。始於系統上線之時，終於系統淘汰之日，佔整個系統開發生命週 期的最大成本(約 67%)。
系統分析師於此階段，可能的工作內容為依據使用者於系統上線後續的需求，進行系統的調整與修正。例 如：診斷並修正運作系統中既有的錯誤之修正型維護(Corrective Maintenance)。
三、 維仁市政府想要開發一個主要給銀髮市民使用的「上車鈴」APP 系統，讓在等候公車的銀髮市 民可以透過刷公車路線站牌上 QR CODE 的方式通知即將到站的公車司機，本站有老人要上 車，以免他過站未停車或是到時沒發現還有人沒上車。而乘客也可以在公車到站時獲得準備上 車 的 通 知 。 你 是 這 個 系 統 開 發 專 案 的 負 責 人 ， 本 專 案 預 計 將 採 取 敏 捷 式 開 發 （ Agile Development）方式進行：
(一)請問什麼是敏捷式開發（Agile Development）？（10 分）
(二)以下有三個敏捷式開發的應用方式，請你解釋它們的意義，並以這個「上車鈴」APP 系統 為例，分別舉例說明它們在這個專案中可能是如何達成的：
(1)測試驅動開發（Test-Driven Development）。（5 分）
(2)持續集成（Continuous Integration）。（5 分）
(3)重構（Refactoring）。（5 分）
答：
高點
‧高上
【版權所有，重製必究！】
108年高上高普考 ‧ 高分詳解
-- -- 3
(一)敏捷宣言(Agile Manifesto)係由一群不同軟體開發方法的領域代表所共同發表，主要目的為提出一套較傳統 軟體開發方式更為簡捷且快速的軟體開發概念。其主要開發理念和價值觀如下(Beck et al., 2001)：
1.因應變化勝於遵循計畫。
2.個體與互動勝於流程與工具。
3.可運作的軟體勝於全面性的文件。
4.與客戶的協同合作勝於契約談判。
敏捷式開發即為遵循敏捷宣言的價值觀之系統開發方式。
(二)1.測試驅動開發(Test-Driven Development)
首先對銀髮市民的上車鈴APP需求進行分析，分解為一個個的故事(Story)，並記錄於故事卡(Story Card)。
之後兩個人同時坐在電腦前，一人依照故事來撰寫測試編碼，另一人如有不同的意見則進行討論，直到 達成共識為止。
2.持續整合(Continuous Integration)
當銀髮市民的上車鈴 APP 撰寫有進度時持續整合，一天內整合十幾次甚至幾十次，如此頻繁的整合能盡 量減少衝突。此外，由於整合頻繁，每次整合的變動也很少，即使整合失敗也容易找到錯誤。
3.重構(Refactoring)
重構貫穿於整個銀髮市民的上車鈴 APP 開發流程，每次開發者簽入(Check in)編碼前，都要對所寫編碼進 行重構。值得注意的是，每次重構時改變要盡可能小，並用單元測試來驗證其是否引起衝突。
四、 前不久國內有家人壽公司斥資新臺幣百億元的營運系統上線，原本寄望這個以知名套裝企業系 統為基礎的新系統可以整合各個系統及商業流程，提升銷售效率及客戶體驗，卻因系統頻出 包，影響保戶權益。金融監督管理委員會表示，未來將要求壽險業者更換系統時須採新、舊系 統「雙軌並行」，避免風險過大。
請回答以下問題：
(一)為什麼新、舊系統「雙軌並行」，可以避免風險過大？（5 分）
(二)請站在該公司的角度，探討該公司當初並未選擇採取新、舊系統「雙軌並行」的可能原因。
（10 分）
(三)請問如果還有機會，你會建議該公司如何進行系統的轉換？（10 分）
答：
(一)雙軌並行為新系統與舊系統同步作業，將兩系統的處理結果相互核對，若發現兩者有不合之處，應即追查 錯誤原因並修正。若兩系統的處理結果完全相同，則平行作業二至三個週期後，廢除舊系統並由新系統完 全取代之。
如此一來，使用者有更多機會熟悉新系統的流程與方法，並檢視新舊系統的差異。此外，萬一新系統有重 大的錯誤時，還有回頭的機會。
(二)然而，採取新舊系統雙軌並行需花費更多的人力、物力，不論資訊部門或是業務部門皆須花費比平常單一 系統時更多的心力於操作新舊兩系統。
若以現有人力來處理，短期間內可勉力而為，然長久下來其可能無法承受工作壓力。所以雙軌並行時間不 應太長，另在執行時資訊部門應該全體動員支援。
(三)分段轉換(Phase Conversion)為將整個系統分成許多子系統(Subsystem)，然後按作業程序之先後與業務的輕 重緩急，先將某部分子系統轉由新系統處理，俟處理結果良好且有較充裕的經驗、人力與設備時，再逐階 段將其他子系統改用新系統處理，適用於此人壽公司的營運系統，分階段導入子系統。
試驗轉換(Pilot Conversion)為新系統必須在受控制的環境下建置，先由某一部門或地區試用，若試用結果良 好，再全面推廣到各個部門正式運作。此外，亦可利用過去資料供新系統試作，然後將處理結果與舊系統 過去的處理結果相比較，若新系統穩定、成效良好即可全面轉換，可避免全面使用後因新系統不穩定所造 成的損失。
