CISA D3 系統取得與開發:最常錯的 10 個觀念

D3 的前半段是系統取得與開發,很少只考背方法名稱,多半在問三件事:現在停在哪個階段、這是誰的責任、控制該放在哪裡。四個選項常常都有道理,錯的那幾個,多半是時點、角色或位置不對。

下面 10 個觀念依專案從頭走到尾排列,各講考試怎麼問、哪裡會被騙、怎麼分辨。例題是自寫的練習題。

商業論證與可行性研究:先看時點

• 1. 可行性研究最早,商業論證管核准與追蹤:可行性研究在專案初期評估技術、經濟、營運與時程是否可行,比較方案要看總持有成本,不能只看採購價。商業論證說明效益、成本、風險與替代方案,是核准專案、追蹤效益的依據。題目停在提案或投資核准,選商業論證;需求清單、使用者驗收測試都重要,但時點不對。
• 2. 商業論證要活著:它保留並更新到系統汰除,每個階段審查都重新檢視;假設改變、效益不再成立,該交指導委員會決定調整或終止,不是照原計畫做完。效益也不會在上線當天出現,衡量指標、基準值與負責人要在專案開始前訂好。

專案治理:誰負責什麼

• 3. 三個角色的「負責」不一樣:專案指導委員會定方向、做重大決策,對交付成果、成本與時程負最終責任,首要責任是確保系統符合業務需求;發起人出經費、擁有成果,效益當責在他;專案經理管日常執行。最常被騙:看到「最終責任」就選專案經理。排定全公司 IT 專案順序的是 IT 指導委員會,不是專案指導委員會。
• 4. 範圍、時程、成本互相牽動:期限不變而範圍增加,就得加資源或犧牲品質。範圍沒經正式變更控制就慢慢變大,叫範圍潛變,需求不清或採原型法時最容易發生;題目問對策,答案是需求基準加正式變更程序:基準凍結後的新需求先評估影響,不是當場答應。

瀑布、敏捷、DevOps:稽核人員看什麼

• 5. 敏捷不等於沒有控制:文件精簡,但變更與測試仍要留紀錄。最常被騙:認為敏捷可以不管控,或拿瀑布式的文件量去挑它的毛病。
• 6. DevOps 靠管線把控制自動化:職務分工被壓縮,就靠管線裡的自動化控制補償:核准關卡、自動測試、完整紀錄。DevSecOps 再把靜態分析、相依元件掃描放進每個階段,高風險發現自動擋下部署。能由系統強制、在最早時點擋下問題的預防性控制,勝過事後靠人檢查。

需求階段就要定控制

• 7. 控制越早嵌入,修正成本越低:需求定義除了功能,還要蒐集非功能與控制需求,不是事後補。設計階段稽核最該確認:控制已寫進規格、驗收準則已訂好(沒有它,測試與簽核就失去依據)、稽核軌跡已規劃進系統(上線後才補,先前的交易就查不到)。問「何時納入」,選最早的需求階段。

輸入、處理、輸出控制

• 8. 輸入控制越靠近輸入點越好,每種檢查只抓一種錯:資料在輸入端驗證,成本最低、效果最好。考法是描述一種錯,要你選抓得到它的檢查,陷阱是選到聽起來相關、其實抓不到的。

• 9. 處理與輸出控制,重點是有人看、有人追:處理控制確保資料在系統內算得對、沒遺漏沒重複,如各階段間核對控制總數、例外報告;輸出控制確保結果正確、只交給有權限的人,如報表分發管控、輸出與輸入總數核對。最常被騙:以為系統有產生例外報告就算完成,沒人覆核追蹤的報告形同虛設。

變更控制與職務分工

• 10. 變更要經核准,寫的人不能自己核准、自己上線:開發人員能碰正式環境,是最嚴重的分工衝突之一。程式碼審查由作者以外的人做;嵌在部署關卡、上線前把關的審查一般歸為預防性,事後的定期審查則偏偵測性,題目兩種都有時,選上線前把關的那個。管線的核准關卡就是變更控制的落點,主要目的是每次生產變更都經授權者核可,不是加快速度。拆不開的小團隊,補償是另一人逐筆驗證,或讓當事人改不了紀錄;緊急變更則事後立即核准並記錄。