【正文】 * 發(fā)現(xiàn)沒有職責(zé)分離，找補償性控制* 選擇項中不選：多加人、停止工作、自動化檢查系統(tǒng)* 審計師發(fā)現(xiàn)問題——找證據(jù) 審計師確認(rèn)問題——報告適當(dāng)?shù)墓芾韺? 控制組負(fù)責(zé)收集、轉(zhuǎn)換和控制輸入，核對結(jié)果并向用戶分發(fā)結(jié)果* 質(zhì)量控制：負(fù)責(zé)執(zhí)行測試或?qū)彶?，以驗證并確保軟件不存在缺陷并滿足用戶預(yù)期，必須在程序被遷移到生產(chǎn)環(huán)境之前進行。發(fā)布、制定、維護質(zhì)量標(biāo)準(zhǔn)。* 在制定業(yè)務(wù)戰(zhàn)略過程中缺乏IT的介入將導(dǎo)致IT戰(zhàn)略規(guī)劃不能與業(yè)務(wù)戰(zhàn)略保持一致的風(fēng)險* 戰(zhàn)略指導(dǎo)委員會的主要職責(zé)是對重要的信息系統(tǒng)項目進行審查，而不應(yīng)當(dāng)涉及日常運營。* 程序反映了業(yè)務(wù)流程及嵌入的控制。* 安全政策必須在控制水平與生產(chǎn)效率之間進行平衡，控制成本決不能超過控制所帶來的預(yù)期收益。* 應(yīng)當(dāng)按照計劃周期或當(dāng)發(fā)生重大變化時對信息安全政策進行審查，以確保其適當(dāng)性、充分性和有效性。* 信息系統(tǒng)職責(zé)分離的原則： 資產(chǎn)保管 授權(quán) 交易記錄* 任何風(fēng)險，都應(yīng)當(dāng)基于信息資源對組織的價值，將其降低至可接受水平。在IT環(huán)境下，風(fēng)險偏好推動所有的風(fēng)險管理工作，影響未來的技術(shù)投資，IT資產(chǎn)的保護程度及所需的保證水平。* 質(zhì)量控制（QC）可以在系統(tǒng)開發(fā)的各個階段進行，但必須在程序被遷移到生產(chǎn)環(huán)境之前進行* 在任何情況下都不應(yīng)當(dāng)讓個人對自己所負(fù)責(zé)的工作執(zhí)行質(zhì)量審查* 針對數(shù)據(jù)庫管理員（DBA）的嚴(yán)格控制： 職責(zé)分離 DBA活動需要得到管理層批準(zhǔn) 由主管對訪問日志和相關(guān)活動進行審查 對數(shù)據(jù)庫工具的使用事實檢查性控制* 必須確保應(yīng)用程序員不能修改生產(chǎn)環(huán)境中的程序和應(yīng)用數(shù)據(jù)，他們應(yīng)當(dāng)只能在測試環(huán)境下工作，由另外的團隊把程序和應(yīng)用變更遷移到生產(chǎn)環(huán)境中。* 針對職責(zé)分離的補償性控制： 審計軌跡—在缺乏職責(zé)分離時，詳細(xì)的審計軌跡將是可接受的補償性控制 核對—核對是用戶的最終責(zé)任，還可以增加控制組使用控制總計和平衡表對應(yīng)用系統(tǒng)執(zhí)行部分核對功能 例外報告—應(yīng)當(dāng)由主管層處理并且需要留下證據(jù) 交易日志—可以時電子也可以手工 監(jiān)督性審核—可以通過現(xiàn)場觀察、訪談或遠程執(zhí)行 獨立性審核—執(zhí)行獨立審核是對錯誤或故意違反既定流程的補償性控制，在職責(zé)不能恰當(dāng)分離的小型組織中尤其重要* 審計過程中應(yīng)該審計的文檔： IT戰(zhàn)略、規(guī)劃和預(yù)算 安全政策文檔 組織圖或職能圖 工作說明 指導(dǎo)委員會報告 系統(tǒng)開發(fā)和程序變更流程 操作流程 人力資源手冊 質(zhì)量保證程序* 信息系統(tǒng)審計師應(yīng)當(dāng)驗證管理層在合同過程中的參與程度，確保按適當(dāng)?shù)闹芷趯贤裱赃M行審查。* 外包的基本原則是：雖然將服務(wù)交付轉(zhuǎn)移，但其職責(zé)仍屬于組織內(nèi)管理層，他們必須確保對風(fēng)險的適當(dāng)管理及供應(yīng)商持續(xù)的價值交付。應(yīng)當(dāng)通過用戶訪談和調(diào)查來監(jiān)督用戶滿意度* 質(zhì)量管理是控制、衡量和改善IS部門流程的一種方法* 信息系統(tǒng)部門制定并維護的書面流程是有效管理信息資源的證據(jù)，堅持遵守流程及相關(guān)流程管理技術(shù)是信息系統(tǒng)部門有效運營的關(guān)鍵因素。* BCP主要是組織高級管理層的責(zé)任，因為高級管理層對組織的資產(chǎn)和生存負(fù)有最高責(zé)任；高級管理層不能推托將責(zé)任委托給下級人員。* BCP維護的一個重要步驟：組織內(nèi)任何相關(guān)變化產(chǎn)生時都要進行BCP的更新和演練* 業(yè)務(wù)連續(xù)性計劃（BCP）是組織為避免業(yè)務(wù)功能/運作中斷，減少業(yè)務(wù)風(fēng)險而建立的一個控制流程，包括對支持組織關(guān)鍵業(yè)務(wù)的人力、物力需求和關(guān)鍵業(yè)務(wù)所需的最小級別服務(wù)水平的連續(xù)性保證。* 無論發(fā)生何種中斷，關(guān)注的焦點永遠是關(guān)鍵業(yè)務(wù)流程的可用和持續(xù)運行* 如果信息系統(tǒng)的BCP與DRP需要單獨建立，必須與組織的總的BCP計劃保持一致。* 一個整合的BCP計劃必須確保： 每個部分都被涵蓋 承諾的資源被最有效的方式使用，并有充分證明通過它組織可以克服中斷生存下去* 災(zāi)難：把發(fā)生概率極小，但沖擊極大* 一個業(yè)務(wù)連續(xù)性計劃應(yīng)當(dāng)識別出當(dāng)發(fā)生災(zāi)難時，業(yè)務(wù)應(yīng)當(dāng)做什么* 保證恢復(fù)的成本永遠不要超過所獲得的利益* 流感大流行的到來具有很強的不確定性，對社會和經(jīng)濟的影響與威脅是確定的。* 流感大流行的應(yīng)對規(guī)劃和傳統(tǒng)的業(yè)務(wù)連續(xù)性規(guī)劃不同，信息系統(tǒng)審計師應(yīng)評價組織對流感大流行的準(zhǔn)備；流感大流行的影響由于范圍和持續(xù)時間不同難以確定。* HR的員工手冊中必須有人員撤離計劃* RPO影響備份技術(shù)的選擇* RTO越小，對災(zāi)難容忍程度就越低，就只能選擇“熱站”* 完全不允許停機——雙生產(chǎn)中心（冗災(zāi)中心、鏡像站點）* 災(zāi)難恢復(fù)策略其他參數(shù)： 中斷窗口：組織能夠等待的自失效點時刻到關(guān)鍵服務(wù)應(yīng)用恢復(fù)的時刻 服務(wù)交付目標(biāo)（SDO）：直到正常的生產(chǎn)系統(tǒng)恢復(fù)運營，由替代流程實現(xiàn)的服務(wù)水平。* 恢復(fù)成本不應(yīng)大于停機成本* 最適合的恢復(fù)策略的選擇，首先要通過業(yè)務(wù)影響分析確定風(fēng)險和重要性級別，然后通過比較恢復(fù)成本和停機成本來決定。* 在管理層選擇了適用的恢復(fù)策略后，下一步的目標(biāo)就是制定詳細(xì)的業(yè)務(wù)連續(xù)性計劃和災(zāi)難恢復(fù)計劃，并在異地備份場所存放一份計劃的拷貝，最好是紙質(zhì)* 首先用戶和管理層的參與是識別關(guān)鍵資源的基礎(chǔ)，其次要由他們來決定關(guān)鍵的恢復(fù)時間和定義所需的資源。* 制定和維護一個DRP與BCP應(yīng)該： 執(zhí)行BIA； 識別各類資源并分類； 選擇策略恢復(fù)IT設(shè)施，支持關(guān)鍵業(yè)務(wù)流程； 制定詳細(xì)計劃恢復(fù)IT設(shè)施（DRP）； 制定詳細(xì)計劃保證關(guān)鍵業(yè)務(wù)運行（BCP）； 測試計劃； 當(dāng)業(yè)務(wù)和系統(tǒng)環(huán)境發(fā)生變化時，維護與更新計劃。* 項目一定有截至點,不能無限期延續(xù)；一定在有限的時間、有限的預(yù)算內(nèi)。* 軟件項目一旦交付到生產(chǎn)環(huán)境后應(yīng)立即交割給運維人員。* 項目群可以看成是由一系列項目和有時間邊界的任務(wù)組成，這些項目和任務(wù)通過共同的目標(biāo)、共同的預(yù)算、相互交織的日程和策略等緊密的聯(lián)系在一起。* 項目群中典型的溝通結(jié)構(gòu)就是召開項目群所有者會議和項目群團隊會議* 項目管理辦公室是項目管理和項目群管理過程的所有者，它必須是永久性的組織結(jié)構(gòu)，需要配置充足的人員，以對當(dāng)前的項目管理提供充分的支持，同時開發(fā)新的程序和標(biāo)準(zhǔn)。* 在一個給定的時間點上，組織中正在進行的所有的項目的集合稱為項目組合。* 規(guī)劃IT項目時首先需要進行業(yè)務(wù)利益分析（商業(yè)案例/Business Cass），組織可以獲得的業(yè)務(wù)利益是實施IT項目的源動力。* 對項目進行充分詳細(xì)的業(yè)務(wù)模式分析，作為啟動和持續(xù)一個項目的驗證條件，為項目的實施提供一個合理的理由* 業(yè)務(wù)模式分析是項目生命周期中各個決策過程的關(guān)鍵因素，無論在項目的哪一個階段，如果業(yè)務(wù)模式分析表明由于成本增加或預(yù)期的利益不能實現(xiàn)使得項目不再有意義時，項目發(fā)起人或指導(dǎo)委員會應(yīng)當(dāng)考慮是否要終止項目的執(zhí)行。* 項目管理的四個要素：環(huán)境、資源、目標(biāo)、組織* 項目管理的方式是目標(biāo)管理。* 如果IT項目實施階段中其業(yè)務(wù)模式發(fā)生變化，應(yīng)當(dāng)通過部門規(guī)劃和審批流程對項目重新進行評估和批準(zhǔn)* 實施后評審：在項目實施后6~18個月進行，評價利益實現(xiàn)程度，獨立于項目實施的審計師進行評審* 有關(guān)項目的所有治理決策應(yīng)當(dāng)由業(yè)務(wù)效益驅(qū)動，并進行周期性評審* 信息系統(tǒng)項目可以由組織的任何一部分啟動，包括信息系統(tǒng)部門* 項目管理的一般過程：啟動、計劃、執(zhí)行、控制、收尾（其中控制過程，貫穿整個項目實施過程）* 業(yè)務(wù)過程的設(shè)計方法也同樣適用于項目管理過程* 項目環(huán)境最關(guān)鍵就是一把手工程。* 安全主管評價安全測試計劃并在實施之前進行報告* 項目發(fā)起人對項目指導(dǎo)委員會負(fù)責(zé)；* 項目經(jīng)理負(fù)責(zé)項目的日?；顒?；* 關(guān)鍵用戶在需求分析階段、測試階段需要積極參與；用戶培訓(xùn)在測試階段進行，主要培訓(xùn)怎么使用軟件。* QA獨立整個項目組，對整個項目的活動做獨立的評價。也不能忽略測試；在特別的情況下，只能減少功能。* 項目中三個元素/緯度必須考慮 時間/持續(xù)時間 需要花多少時間才能完成項目 成本/資源 需要花費多少 交付品 什么是必須做的* 軟件規(guī)模評估：源代碼行數(shù)、功能點分析（FPA）、FPA特征點* 源代碼行數(shù)評估結(jié)構(gòu)化程序語言（BASIC、COBOL）有用，其他不行，尤其業(yè)務(wù)功能不行* 功能點分析（FPA）廣泛用于評估開發(fā)大型業(yè)務(wù)應(yīng)用的復(fù)雜性。* 甘特圖的缺點：無法表現(xiàn)任務(wù)之間的邏輯關(guān)系* PERT時間計算=（樂觀完成時間+4X最可能完成的時間+悲觀完成時間）/6* 先用PERT算出每個工作的工期，然后再用關(guān)鍵路徑法* 關(guān)鍵路徑法中，有多條路的時候找最長的路。* 關(guān)鍵路徑中的松弛時間為0* 設(shè)計系統(tǒng)開發(fā)項目的PERT網(wǎng)絡(luò)時，第一步是識別所有的任務(wù)、項目的相關(guān)事件/里程碑和它們相對應(yīng)次序* 時間盒管理是項目管理方法* 原型法的項目管理方法是時間盒管理* 時間盒管理中：時間、質(zhì)量、資源不可變，只有功能可以變* 時間盒管理是在一個相對短的、絕對的和不許變更的時間以及有限資源的情況下，定義和部署軟件交付產(chǎn)品。* 項目控制活動包括項目的范圍管理，資源使用和風(fēng)險管理。* 范圍變更管理： 變更請求必須提交項目經(jīng)理 項目經(jīng)理提交項目咨詢顧問委員會決定是否建議變更 項目出資人決定是否變更* 項目出資人有最后決定是否變更的決定權(quán)。* SDLC需求定義：描述系統(tǒng)應(yīng)該做的，用戶如何與系統(tǒng)交互，系統(tǒng)運行的條件，系統(tǒng)應(yīng)滿足的信息標(biāo)準(zhǔn)；確保需求完整、連續(xù)、清楚、可驗證、可修改、可跟蹤* 審計師在SDLC需求分析階段需要關(guān)注：業(yè)務(wù)部門的人員積極參與到需求調(diào)研中；安全控制是否提出（審計師作為用戶，提出嵌入式在線審計模塊是否提出）* SDLC方法適用于一個需求穩(wěn)定、定義準(zhǔn)確的項目，并且在開發(fā)工作早期建立總體的系統(tǒng)架構(gòu)* 軟件購買階段： 不修改，只配置 進行部分定制開發(fā) 完全重新開發(fā)（絕對不允許，ERP軟件代表行業(yè)的最佳實踐）* 迭代法：業(yè)務(wù)需求被迭代開發(fā)和測試直至整個應(yīng)用系統(tǒng)被設(shè)計、建立和測試。* 自行開發(fā)的設(shè)計階段==購買軟件包的選擇階段* 自行開發(fā)的開發(fā)階段==購買軟件包的配置階段* 實施階段在最終用戶驗收測試完成、用戶簽署正式文件后進行* 組織應(yīng)當(dāng)按照ERP的要求首先要轉(zhuǎn)變原有的管理理念、策略和實踐方法，并按業(yè)務(wù)需求對ERP進行定制，才能有效提高信息技術(shù)能力，以支持組織業(yè)務(wù)目標(biāo)的實現(xiàn)。從可行性研究應(yīng)當(dāng)?shù)贸觥靶谢虿恍小钡臎Q斷* 與可行性報告聯(lián)系緊密的是影響評估，研究當(dāng)前項目對其他項目和資源的潛在影響。* 需求定義即在可行性研究后對選擇的業(yè)務(wù)系統(tǒng)識別和明確業(yè)務(wù)需求。* 信息標(biāo)準(zhǔn)包括：系統(tǒng)的效力、效率、機密性、可用性、合規(guī)性和可靠性。創(chuàng)建項目計劃用于開發(fā)、測試和實施系統(tǒng)。* 實體關(guān)系圖（ERD）描述的是系統(tǒng)數(shù)據(jù)和這些數(shù)據(jù)是如何交互的，可作為需求分析工具* 實體關(guān)系圖（ERD）的基本元素是實體和關(guān)系* 信息系統(tǒng)審計師在需求分析階段要確定：應(yīng)用系統(tǒng)是否定義了充分的安全需求以保證系統(tǒng)的機密性、完整性和可用性；是否定義了完備的審計蹤跡作為系統(tǒng)的必要組成部分，審計蹤跡是審計師未來進行跟進的重要依據(jù)。* 組織應(yīng)當(dāng)建立一個由技術(shù)人員和主要業(yè)務(wù)人員組成的項目小組，由項目小組制定征求建議書（RFP）或邀標(biāo)書（ITT），并發(fā)送給軟件供應(yīng)商，讓軟件供應(yīng)商根據(jù)組織的需求，在考慮技術(shù)先進、成本最優(yōu)的前提下，提供最佳解決方案。組織根據(jù)各個供應(yīng)商提供的信息，制定出正式的征求建議書。一旦為軟件開發(fā)過程建立了基線，就要引入配置管理的過程來管理對軟件的修改，以協(xié)調(diào)和控制整個系統(tǒng)。* 基線標(biāo)志軟件開發(fā)過程的里程碑，任何一個軟件配置項（如設(shè)計說明書、測試計劃等），一旦形成文檔并審核通過，即為一個基線。對于已稱為基線的軟件配置項，雖然可以修改，但必須按照特殊、正式的變更管理過程進行評估，在確認(rèn)風(fēng)險與成本的前提下，再進行修改。在系統(tǒng)之間傳遞數(shù)據(jù)時測試確認(rèn)和驗證單個系統(tǒng)系統(tǒng)的應(yīng)用程序功能 系統(tǒng)測試：對整個軟件進行測試；目的在于通過與系統(tǒng)需求定義作比較，發(fā)現(xiàn)軟件與系統(tǒng)定義不符合或與之矛盾的地方 最終接受測試：當(dāng)開發(fā)與測試人員完成所有測試，準(zhǔn)備交付軟件產(chǎn)品時，就應(yīng)該開始系統(tǒng)的用戶接受測試。QAT需要測試運行功能* 用戶接受測試（UAT）一般使用用戶界面輸入測試數(shù)據(jù)，分析測試的輸出結(jié)果，一般使用生產(chǎn)中的實際數(shù)據(jù)進行測試，以確保用戶要求的功能得到實現(xiàn)* 質(zhì)量保證測試（QAT）對軟件的可移植性、兼容性、可維護性、錯誤的恢復(fù)功能進行技術(shù)性確認(rèn)* 系統(tǒng)測試包括： 恢復(fù)測試：檢查系統(tǒng)從硬件或軟件故障中恢復(fù)的能力 安全測試：確保新系統(tǒng)內(nèi)置了充分的訪問控制 壓力測試/容量測試：對大量數(shù)據(jù)的處理，評估系統(tǒng)在處理高峰時的性能 性能測試：利用通用測試標(biāo)準(zhǔn)來比較系統(tǒng)性能* UAT測試應(yīng)該在單獨的測試環(huán)境，不能與生產(chǎn)與開發(fā)環(huán)境在一起* 用戶接受測試（UAT）應(yīng)該在源代碼和可執(zhí)行代碼都能得到很好保護的安全測試環(huán)境，有助于避免非授權(quán)的版本或最后一分鐘還在修改的系統(tǒng)沒有經(jīng)過標(biāo)準(zhǔn)的系統(tǒng)維護過程就直接引入正式系統(tǒng)* α測試是由一個用戶在開發(fā)環(huán)境下進行的測試，是在受控環(huán)境下的測試。通過在不同點檢查程序狀態(tài)，確定實際的狀態(tài)是否與預(yù)期的狀態(tài)一致* 黑盒測試：在軟件接口處進行測試，證實每個實現(xiàn)的功能是否符合要求。* 功能/確認(rèn)測試：驗證軟件的有效性，驗證軟件功能和性能及其它特性是否與用戶的要求一致* 回歸測試：對測試計劃或測試場景的某些內(nèi)容重新進行測試，目的是為了保證最近對軟件所做的變更和修改沒有引入新的錯誤。* 要對實施的各個階段（從老系統(tǒng)到新系統(tǒng)的構(gòu)建、集成、移植和轉(zhuǎn)換）進行有效管理* 實施計劃（知識轉(zhuǎn)移計劃）——應(yīng)當(dāng)按照漸變式或接力棒方式進行，這是知識轉(zhuǎn)移和職責(zé)轉(zhuǎn)移的最佳方式* 培訓(xùn)計劃——定義了角色與職責(zé)后，需要用矩陣圖方式記錄，便于相關(guān)人員清晰