信息系统获取、开发与实施

信息系统获取、开发与实施 .............................................................................................1
1. 业务实现 ....................................................................................................................34
1.1. 项目组合与项目群管理.....................................................................................34
1.1.1.
项目是特定条件下，具有特定目标的一次性任务，是在一定时间内，
满足一系列特定目标的多项相关工作的总称。 ...................................................34
1.1.1.1. 短期的，战术性 ..................................................................................35
1.1.2.
项目群可以看成是由一系列项目和有时间边界的任务组成，这些项目
和任务通过共同的目标、共同的预算、相互交织的日常和策略等精密地联系在

m
一起。 35

co
1.1.2.1. 长期的，战略性的 ..............................................................................35
1.1.3.

3.
项目组合（业务一致性）是在一个给定的时间点上，组织中正在进行
的所有项目的集合 ...................................................................................................35
16
1.1.3.1. 管理周期（每季度、每年） ..............................................................35
4@

1.2. 业务案例制定与审批.........................................................................................35
1.2.1.
在进行规划IT项目时，无论是开发新系统还是投资建设基础设施，都
05

需要先考虑业务案例（也被译为商业模式、业务案例等），组织可以获得业务
收益才是实施IT项目的源动力。 ............................................................................36
67

1.2.2. 项目发起人、IT指导委员会负责 ..............................................................36

1.2.3. IT项目的全生命周期内评估 ......................................................................36
2
80

1.3. 实施业务收益的技术.........................................................................................36
1.3.1. 验证预期的业务收益 .................................................................................36
1.3.2. 计划中收益得到了实现 .............................................................................36
1.3.3. 对业务收益进行描述 .................................................................................36
1.3.4. 制定测量方法和目标 .................................................................................36
1.3.5. 记录前提条件 .............................................................................................36
1.3.6. 建立实现利益的职责 .................................................................................36
1.3.7. 建立追踪和测量的制度 .............................................................................37
1.3.8. 系统实施6-18个月后进行实施后评审 ......................................................37
2. 项目管理结构 ...........................................................................................................37
2.1. 项目管理三要素.................................................................................................37
2.1.1. 时间（时间期限） .....................................................................................37
2.1.2. 成本（资源或预算） .................................................................................37

1
 2.1.3. 交付物/范围（功能需求）........................................................................37
2.2. 项目管理一般过程.............................................................................................37
2.2.1. 启动 .............................................................................................................38
2.2.1.1. PID/PRD的审批 ....................................................................................38
2.2.2. 计划 .............................................................................................................38
2.2.3. 执行 .............................................................................................................38
2.2.4. 控制 .............................................................................................................38
2.2.5. 收尾 .............................................................................................................38
2.3. 项目环境.............................................................................................................38
2.3.1. 组织中项目的重要性 .................................................................................39
2.3.2. 组织战略和项目之间的联系 .....................................................................39
2.3.3. 与其他项目之间的关系 .............................................................................39

m
2.3.4. 项目与业务效益分析之间的关系 .............................................................39

co
2.4. 项目组织形成.....................................................................................................39
2.4.1. 职能式组织形式 .........................................................................................39
2.4.1.1. 项目经理只作为一个成员，没有正式的管理权限。 ......................39
3.
16
2.4.2. 矩阵式组织形式 .........................................................................................39
2.4.2.1. 项目经理与部门经理共同分担管理权限。 ......................................40
4@

2.4.3. 项目式组织形式 .........................................................................................40

2.4.3.1. 项目经理有正式的授权来负责项目。 ..............................................40
05

2.5. 项目沟通与文化.................................................................................................40
2.5.1. 一对一的面谈 .............................................................................................40
67

2.5.2. 项目启动会议KICKOFF................................................................................40
2.5.3. 项目初期的研讨会 .....................................................................................40
2

2.5.4. 以上方式的综合使用 .................................................................................40

80

2.6. 项目目标管理原则SMART .................................................................................41

2.6.1. S具体(Specific)，绩效考核要切中特定的工作指标，不能笼统.............41
2.6.2.
M可度量(Measurable)，指标是可量化的，验证这些指标的数据或者信
息是可获得的； .......................................................................................................41
2.6.3.
A可实现(Attainable)，指标在付出努力的情况下可以实现，避免设立过
高或过低的目标 .......................................................................................................41
2.6.4.
R现实性(Realistic），指标是可以证明和观察；绩效指标是与本职工作
相关联的 ...................................................................................................................41
2.6.5. T有时限(Timebased)based)，注重完成绩效指标的特定期限。 ............41
2.7. 项目目标.............................................................................................................41

2
 2.7.1. OBS...............................................................................................................41
2.7.2. WBS..............................................................................................................41
2.7.3. WP................................................................................................................41
2.8. 项目中的团队及个人的角色和职责.................................................................42
2.8.1. 高级管理层 .................................................................................................42
2.8.2. 用户管理部门 .............................................................................................42
2.8.3. 项目指导委员会 .........................................................................................42
2.8.4. 项目发起人 .................................................................................................42
2.8.5. 系统开发管理部门 .....................................................................................42
2.8.6. 项目经理 .....................................................................................................42
2.8.7. 系统开发项目小组 .....................................................................................42
2.8.8. 用户项目小组 .............................................................................................42

m
2.8.9. 安全主管 .....................................................................................................42
2.8.10. 质量保证..................................................................................................42

co
3. 项目管理实务 ...........................................................................................................42

3.
3.1. 项目发起.............................................................................................................43
3.1.1. 项目宪章：描述了项目的目标，项目相关方，项目经理及项目发起人
16
43
3.2. 项目计划.............................................................................................................43
4@

3.2.1. 软件规模估计 .............................................................................................43

3.2.1.1. 源代码行数SLOC..................................................................................44
05

3.2.1.2. 功能点分析FPA....................................................................................44
3.2.1.2.1.
67

基于输入、输出、文件、接口和查询的数量和复杂度。适用于
大多数标准的应用软件开发但对于网站或者与页面表格、图片等有很大关
2

系的开发，则需要进一步修正。FPA不适于操作系统、处理控制、通讯、
80

工程类软件的评估。 .......................................................................................44
3.2.1.2.1.1. 外部输入EI-ExternalInput .......................................................44
3.2.1.2.1.2. 外部输出EO-ExternalOutput...................................................44
3.2.1.2.1.3. 外部查询EQ-ExternalQuery ....................................................44
3.2.1.2.1.4. 内部逻辑文件ILF-InternalLogicalFile ......................................45
3.2.1.2.1.5. 外部接口文件EIF-ExternalInterfaceFile..................................45
3.2.2. 软件成本估计 .............................................................................................45
3.2.2.1. 人力成本 ..............................................................................................45
3.2.2.2. 工具成本 ..............................................................................................45
3.2.2.3. 管理成本 ..............................................................................................45
3.2.2.4. 办公费用 ..............................................................................................45
3.2.3. 进度计划和期限 .........................................................................................45

3
 3.2.3.1. 甘特图 ..................................................................................................45
3.2.3.1.1.
显示任务开始时间和结束时间，任务完成顺序，任务的资源分
配，也可以追踪里程碑。 ...............................................................................46
3.2.3.2. 项目评审技术PERT..............................................................................46
3.2.3.2.1. 也是一种CPM技术.........................................................................46
3.2.3.2.2.
PERT时间乐观完成时间+4×最可能完成时间悲观完成时间））/
6 46
3.2.3.2.3.
设计项目的PERT网络图时，第一步是识别所有任务、项目的里
程碑和它们的相对次序。 ...............................................................................46
3.2.3.3. 关键路径发CPM ..................................................................................46

m
3.2.3.3.1.

co
关键路径代表了整个项目预计的最短耗时，关键路径上的任务
没有时间弹性，不在关键路径上的任务具有一定的时间弹性。 ...............46

3.
3.2.3.3.2.
16
正向遍历整个网络，可以确定关键路径；逆向遍历整个网络，
可以计算弹性时间。 .......................................................................................47
4@

3.2.3.4. 时间盒管理 ..........................................................................................47

3.2.3.4.1.
在限定一个相对短的时间，资源有限的情况下，定义和部署软
05

件的交付物。适合于原型法或快速应用开发法，关键功能可以在较短时间
内交付用户使用。 ...........................................................................................47
67

3.2.3.4.2. 优点：避免项目成本超支，避免进度拖延的情况。 ................47

3.3. 项目控制 ...........................................................................................................47
2
80

3.3.1. 范围变更管理 .............................................................................................47

3.3.1.1. 正式的变更流程 ..................................................................................48
3.3.1.2. 防止软件范围蔓延 ..............................................................................48
3.3.2. 资源利用管理 .............................................................................................48
3.3.2.1. 检查-盈利分析法EVA ..........................................................................48
3.3.2.1.1.
是一种能全面衡量项目进度状态、成本趋势的科学方法，其基
本要素是用货币量代替实物量来测量项目的进度。它不以项目投入资金的
多少来反映项目的进展，而是以投入资金已经转化为项目成果的量来衡量
，是一种完整和有效的项目监控方法。 .......................................................48
3.3.2.1.1.1.
已安排工作的预算费用（BCWS，BudgetedCostofWorkSche
duled），即根据批准认可的进度计划和预算到某一时点应当完成的工

4
 作所需投入资金的累计值，它等于计划工程量与预算单价的乘积之和。
49
3.3.2.1.1.2.
完成工作的预算费用（BCWP，BudgetedCostofWorkPerfor
med），即根据批准认可的预算，到某一时点已经完成的工作所需要投
入资金的累计值，它等于已完工程重与预算单价的乘积之和。 ...........49
3.3.2.1.1.3.
完成工作实际费用（ACWP，ActualCostofWorkPerformed）
，即某一时点已完成的工作所实际花费的总金额，它等于已完工程量与
实际支付单价（合同价）的乘积之和。 ...................................................49
3.3.2.1.1.4.
费用偏差（CV，CostVariance），可以看出已经完成的工作
是超过预算还是低于预算。CV=BCWP-ACWP。........................................49

m
3.3.2.1.1.5.

co
进度偏差（SV，ScheduleVariance），可以看出项目当前进
度是提前还是滞后。 SV=BCWP-BCWS。 ...................................................49

3.
3.3.3. 软件开发的风险 .........................................................................................49
16
3.3.3.1.
业务风险：系统不符合用户的业务需要，不能达到用户的期望值
4@

。该风险由项目发起人负责。 ...........................................................................50
3.3.3.2.
项目风险：项目活动超出必要的财务资源限制，项目推迟完成。
05

该风险由项目经理负责。 ...................................................................................50
3.3.4. 风险管理 .....................................................................................................50
67

3.3.4.1. 风险清单 ..............................................................................................50

2

3.3.4.2. 评估风险 ..............................................................................................50

80

3.3.4.3. 管理风险 ..............................................................................................50

3.3.4.4. 监控风险 ..............................................................................................50
3.3.4.5. 评估风险管理流程 ..............................................................................50
3.4. 项目关闭 ...........................................................................................................50
3.4.1. 实施后评审 .................................................................................................51
4. 业务使用系统的开发SDLC .......................................................................................51
4.1. 划分生命周期进行检查和评价的好处 ...........................................................51
4.2. 传统的系统开发生命周期方法（SDLC、瀑布模型、V型图） .....................51
4.2.1. 测试模型-V模型..........................................................................................51
4.2.1.1. 1.用户需求<->9.验收测试...................................................................52
4.2.1.2. 2.功能性要求<->8系统测试................................................................52
4.2.1.3. 3.架构设计<->7.集成测试...................................................................52
4.2.1.4. 4.详细设计<->6.单元测试...................................................................52

5
 4.2.1.5. 5.代码 ...................................................................................................52
4.3. 传统的SDLC各个阶段描述 ...............................................................................52
4.3.1. 阶段1：可行性研究 ...................................................................................52
4.3.1.1.
初步业务需求，业务案例，技术、经济、社会可行性，备选方案
，投资回报 ...........................................................................................................52
4.3.2. 阶段2：需求定义 .......................................................................................52
4.3.2.1.
用户须积极参与。功能性需求和非功能性需求。定义安全需求（C
IA，机密性、完整性、可用性），定义审计轨迹需求。确定是采购软件还是
定制开发。 ...........................................................................................................53
4.3.3. 阶段3A：软件的选择和获取 .....................................................................53
4.3.3.1.

m
用户要参与软件的评估和选择过程。准备需求建议书（RFP），要

co
考虑供应商的财务能力，与供应商签订软件源代码第三方保全协议（Escrow

3.
）。 53
4.3.3.2. 征求建议书格式 ..................................................................................53
16
4.3.3.3. 合同应当包含一下内容 ......................................................................53
4.3.3.3.1. 对合同递交物及其成本的详细描述 ............................................54
4@

4.3.3.3.2. 合同递交物承诺的交付日期 ........................................................54

4.3.3.3.3. 承诺同时交付的文档、补丁包、升级程序、新版本通告和培训
05

54
4.3.3.3.4.
67

如果合同递交物不包含源代码，应当考虑与供应商签署源代码
第三方保全协议 ...............................................................................................54
2

4.3.3.3.5. 软件安装与配置时，提供支持服务的有关描述 ........................54

80

4.3.3.3.6. 用户进行接受测试的标准 ............................................................54

4.3.3.3.7. 在正式决定购买前，提供给用户一段合理的接受测试时间 ....54
4.3.3.3.8. 允许购买方根据需要对软件进行一定的修改 ............................54
4.3.3.3.9. 维护协议 ........................................................................................54
4.3.3.3.10. 允许为业务连续性计划和测试工作使用软件的副本 ..............54
4.3.3.3.11. 与到货时间相关的付款计划 ......................................................54
4.3.3.3.12. 保密条款 ......................................................................................54
4.3.3.3.13. 数据保护条例 ..............................................................................54
4.3.4. 阶段3B：设计 .............................................................................................54
4.3.4.1.
系统规格说明，系统功能实现，接口设计，程序和数据库设计，
安全计划。用户过多参与不合适，但设计人员可向用户解释软件架构如何满
足需求。 55

6
 4.3.4.2. 设计阶段关键 ......................................................................................55
4.3.4.2.1.
开发系统流程图和实体关系图模型，以说明信息在系统中如何
流动 55
4.3.4.2.2.
确定是否使用结构化的设计方法，结构化的设计方法通过一系
列数据或流程图自顶向下建立各种关系。 ...................................................55
4.3.4.2.3. 描述输入与输出 ............................................................................55
4.3.4.2.4. 确定软件的过程步骤和计算规则，以满足功能需求 ................55
4.3.4.2.5. 确定数据文件或数据库文件设计 ................................................55
4.3.4.2.6. 为各种类型的需求或已定义的信息标准，建立程序规格说明书
55
4.3.4.2.7.

m
制定各种类型的测试计划（单元测试、子系统测试、集成测试

co
、测试与其他程序接口、测试系统装载和初始化的文件、压力测试、安全
测试、备份与恢复测试）） ...........................................................................55

3.
4.3.4.2.8.
16
制定数据转换计划，把数据从老系统转换到新系统。建立详细
的转换计划能防止数据不兼容、资源不够用或者员工对新系统不熟悉等问
4@

题的发生。 .......................................................................................................55
4.3.4.3. 实体关系图 ..........................................................................................56
4.3.4.3.1. 描述系统数据及数据之间的交互，用于表达逻辑数据模型。 56
05

4.3.4.4. 软件基础管理 ......................................................................................56

4.3.4.5. 设计过程的用户参与 ..........................................................................56
67

4.3.4.6. 设计阶段的完成 ..................................................................................56

2

4.3.4.7. IT审计的介入 .......................................................................................56

80

4.3.5. 阶段4A：开发 .............................................................................................56

4.3.5.1. 程序编码，调试与测试。 ..................................................................56
4.3.5.2. 开发阶段关键 ......................................................................................56
4.3.5.2.1. 程序编码和开发程序文档、系统文档 ........................................57
4.3.5.2.2. 程序调试和程序测试 ....................................................................57
4.3.5.2.3. 开发程序以旧系统转换数据到新系统中 ....................................57
4.3.5.2.4. 创建用户迁移计划，实现用户到新系统的顺利转移 ................57
4.3.5.2.5. 对使用新系统的用户进行培训 ....................................................57
4.3.5.2.6.
如果是对购买的商品化软件包进行定制开发，确定对程序代码
的修改记录在案，并把修改内容准确完整地应用到供应商的原始软件代码
中去，以保证供应商将来的升级版本包含了这些已更新代码 ...................57
4.3.5.3. 编程方法和技术 ..................................................................................57

7
 4.3.5.4. 在线编程设施（集成开发环境） ......................................................57
4.3.5.4.1. 优点 ................................................................................................57
4.3.5.4.1.1. 降低开发成本 .........................................................................58
4.3.5.4.1.2. 保持快速响应时间 .................................................................58
4.3.5.4.1.3. 提供共享的程序资源 .............................................................58
4.3.5.4.2. 缺点 ................................................................................................58
4.3.5.4.2.1. 多个程序版本容易引起混淆 .................................................58
4.3.5.4.2.2.
非授权访问与更改程序代码的可能性增加，危及系统与程
序的完整性 58
4.3.5.4.2.3. 对程序代码的合法修改可能被其他人员的修改覆盖 .........58
4.3.5.5. 编程语言 ..............................................................................................58

m
4.3.5.6. 编程调试 ..............................................................................................58
4.3.5.6.1. 逻辑路径监测 ................................................................................59

co
4.3.5.6.1.1. 一系列事件的报告，提供逻辑错误的线索。 .....................59

3.
4.3.5.6.2. 内存转储 ........................................................................................59
4.3.5.6.2.1.
16
用于系统崩溃时，将内存中的数据转储保存在转储文件中
，供给有关人员进行排错分析。 ...............................................................59
4@

4.3.5.6.3. 输出分析 ........................................................................................59

4.3.5.6.3.1. 通过比较实际的输出结果与预期结果检查系统的精确性。
05

60
4.3.5.7. 测试 ......................................................................................................60
67

4.3.5.7.1. 集成测试工具ITF............................................................................60
4.3.5.7.1.1.
2

测试数据输入到生产环境系统中运行，验证新系统在真实
80

环境下的运行状况。要做好测试数据的标识工作，避免与生产数据的混
淆。 60
4.3.5.8. 软件测试过程的要素 ..........................................................................60
4.3.5.8.1. 测试计划 ........................................................................................61
4.3.5.8.1.1. 自底向上：从底层的单元测试开始 .....................................61
4.3.5.8.1.1.1. 无需安装驱动程序 ..........................................................61
4.3.5.8.1.1.2. 在所有程序完成前就可以开始测试 ..............................61
4.3.5.8.1.1.3. 对关键模块的错误可以较早发现 ..................................61
4.3.5.8.1.2. 自顶向下：从顶层的系统测试开始 .....................................61
4.3.5.8.1.2.1. 可以较早对主要功能和处理流程进行测试 ..................62
4.3.5.8.1.2.2. 接口错误可以较早的测试出来 ......................................62
4.3.5.8.1.2.3. 编程人员与用户看到整个系统，增强信心 ..................62

8
 4.3.5.8.2. 实施测试和报告测试结果 ............................................................62
4.3.5.8.3. 解决测试中发现的问题 ................................................................62
4.3.5.9. 测试分类 ..............................................................................................62
4.3.5.9.1. 单元测试 ........................................................................................62
4.3.5.9.1.1. 对程序模块内部进行测试 .....................................................62
4.3.5.9.2. 接口测试/集成测试 .......................................................................62
4.3.5.9.2.1. 测试多个模块之间的连接，验证整个系统的功能 .............63
4.3.5.9.3. 系统测试 ........................................................................................63
4.3.5.9.3.1. 恢复测试 .................................................................................63
4.3.5.9.3.2. 安全测试 .................................................................................63
4.3.5.9.3.3. 压力测试/容量测试 ................................................................63
4.3.5.9.3.4. 性能测试 .................................................................................63

m
4.3.5.9.4. 最终接受测试 ................................................................................63

co
4.3.5.9.4.1.
用户接受测试UAT：用户进行验收测试，确保用户要求的

3.
功能得到实现 ...............................................................................................64
4.3.5.9.4.2.
16
质量保证测试QAT：质量保证人员进行测试，对软件的可
4@

迁移性、兼容性、可 维护性、错误的恢复功能进行技术性确认 ..........64

4.3.5.10. 其他类型测试 .....................................................................................64
4.3.5.10.1. α测试和β测试 ..............................................................................64
05

4.3.5.10.1.1.
α测试（AlphaTesting）：一个用户在开发环境下的测试，
67

用于评价系统的FURPS功能、可使用性、可靠性、性能、支持服务）。
64
2

4.3.5.10.1.2.
80

β测试（BetaTesting）：多个用户在实际使用环境下进行
的测试，开发者通常不在测试现场，目标是测试可支持性。 ...............65
4.3.5.10.2. 模拟测试 ......................................................................................65
4.3.5.10.2.1. 对系统的某些特定或预定义的内容进行预备性的测试。65
4.3.5.10.3. 白盒测试 ......................................................................................65
4.3.5.10.3.1.
测试软件系统的所有内部逻辑流程和路径，证实操作符合
设计要求。 65
4.3.5.10.4. 黑盒测试 ......................................................................................65
4.3.5.10.4.1.
根据软件功能进行测试，不考虑系统内部逻辑结构和内部
特性，检查软件是 否符合功能说明。 ......................................................65
4.3.5.10.5. 功能/确认测试 .............................................................................66

9
 4.3.5.10.5.1.
验证软件的有效性，即软件的功能和性能是否满足用户要
求。 66
4.3.5.10.6. 回归测试 ......................................................................................66
4.3.5.10.6.1.
对测试场景中的某些内容重新进行测试，目的是为了保证
最近对软件做的修 改没有引入新的错误。 ..............................................66
4.3.5.10.7. 平行测试 ......................................................................................66
4.3.5.10.7.1.
把同一套测试数据同时输入到开发的新系统和原有系统中
去运行，对比两个 系统的输出结果，判断新系统的正确性。 ..............66
4.3.5.10.8. 社交性测试 ..................................................................................67
4.3.5.10.8.1.

m
证实新系统在目标环境中运行时，不会对其他系统带来负

co
面影响。 67
4.3.6. 阶段4B：配置 ...........................................................................................67

3.
4.3.6.1. 系统参数配置，与已有系统的接口开发与联调。 ..........................67
16
4.3.6.2. 角色和职责 ..........................................................................................67
4.3.6.3. 基于业务风险对所有变更进行分类和排序 ......................................67
4@

4.3.6.4. 影响程度分析 ......................................................................................67

4.3.6.5. 由业务流程所有者及IT授权和同意所有的变更 ...............................67
05

4.3.6.6. 跟踪变更的状态 ..................................................................................67

4.3.6.7. 关注数据完整性 ..................................................................................67
67

4.3.7. 阶段5：最终测试和实施 .........................................................................67

4.3.7.1.
2

UAT测试之后进行，用户培训，数据转换，系统迁移，系统切换
80

。 68
4.3.7.2. 实施计划 ..............................................................................................68
4.3.7.2.1. 阶段一：制定所需的支持结构 ....................................................68
4.3.7.2.1.1. 差距分析 .................................................................................68
4.3.7.2.1.2. 角色定义 .................................................................................68
4.3.7.2.2. 阶段二：建立支持功能 ................................................................68
4.3.7.2.2.1. 开发服务水平协议 .................................................................69
4.3.7.2.2.2. 知识转移计划 .........................................................................69
4.3.7.2.2.3. 培训计划 .................................................................................69
4.3.7.3. 终端用户培训 ......................................................................................69
4.3.7.4. 转换数据 ..............................................................................................69
4.3.7.5. 迁移细化迁移方案 ..............................................................................69
4.3.7.6. 迁移失败后回退过程的情景 ..............................................................69

10
 4.3.7.7. 在数据转换项目中要考虑的关键因素 ..............................................69
4.3.7.7.1. 数据转换的完备性 ........................................................................69
4.3.7.7.2. 数据的完整性 ................................................................................69
4.3.7.7.3. 转换过程中的机密性 ....................................................................69
4.3.7.7.4. 数据的一致性 ................................................................................69
4.3.7.7.5. 连续性 ............................................................................................70
4.3.7.7.6.
转换之前，在旧的平台上对数据进行最后一次拷贝；转换之后
，与最后一次拷贝进行对比，确认一致 .......................................................70
4.3.7.8. 系统切换技术 ......................................................................................70
4.3.7.8.1. 平行切换 ........................................................................................70
4.3.7.8.1.1.

m
新老系统同时运行一段时间，对新系统的运行满意之后再
完全切换到新系统。缺点在于实施初期必须同时运行两个系统，工作量

co
大；优点在于可以最小化切换风险。 .......................................................70
4.3.7.8.2. 分段切换 ........................................................................................70
4.3.7.8.2.1.
3.
16
用新系统的模块逐步替代老系统的对应模块，直到全部完
成。 71
4@

4.3.7.8.3. 快速切换/一次性切换 ...................................................................71

4.3.7.8.3.1.
05

在某个具体时间点，快速从老系统切换到新系统。风险最
大。 71
67

4.3.7.9. 认证与认可 ..........................................................................................71

4.3.8. 阶段6：实施后审查 .................................................................................71
2

4.3.8.1.
80

评估系统的充分性，评价成本效益和投资回报，吸取经验教训，
为后续的开发项目提供改进建议。 ...................................................................71
4.3.8.2. 实施后评审的目标 ..............................................................................71
4.3.8.2.1. 评估系统的充分性 ........................................................................72
4.3.8.2.2. 评价项目的成本效益或投资回报 ................................................72
4.3.8.2.3. 针对系统存在的缺陷，提出改进建议 ........................................72
4.3.8.2.4. 为改进建议制定详细计划 ............................................................72
4.3.8.2.5. 对项目过程进行评估 ....................................................................72
4.4. 软件基线管理Baseline......................................................................................72
4.4.1.
基线设计阶段定义的一个冻结点，标志着软件开发过程的各个里程碑
，任何一个软件配置项，一旦形成文档并审核通过，就成为基线标志着一个阶
段的结束。如果需要修改基线，则需要通过正式的变更管理流程进行评估和审

11
 批。主要用于有效管理用户需求避免软件开发范围不断蔓延而导致项目失控。
72
4.5. 编程标准 ...........................................................................................................72
4.5.1.
编程标准改善了编码的质量和未来的维护能力，减小了系统开发过程
中由于人员轮换带来的返工，提高了系统开发效率，方便了维护和修改。 ...72
4.6. 与软件开发相关的风险 ...................................................................................72
4.6.1.
在项目内部：相关的风险是没有识别处理业务问题的正确需求或时机
，没有在规定的时间内和在成本约束的条件下管理要交付的项目 ...................73
4.6.2.
和供应商之间：相关的风险是没有与供应商进行明确地需求和期望，
导致供应商没有或不能按时以预期的成本交付合格的产品 ...............................73

m
4.6.3.
在组织内部：相关的风险是组织中的利益相关者不能提供项目所需要

co
的输入和承诺，而且改变了原定的组织优先级和政策 .......................................73

3.
4.6.4.
和外部环境之间：相关的风险是客户、竞争对手、立法部门、政府部
16
门等外部实体的相关活动对项目的影响；经济条件的变化对项目造成的影响73
4.6.5. 和选择的技术：技术风险 .......................................................................73
4@

5. 开发方法 ...................................................................................................................73
5.1. SDLC的缺陷 .......................................................................................................74
05

5.1.1. 不可预期的事 ...........................................................................................74

5.1.2. 对需求定义要求很高 ...............................................................................74
67

5.1.3. 需要用户有足够的耐心 ...........................................................................74

5.2. 敏捷开发 ...........................................................................................................74
2

5.2.1.
80

是一种以人为核心、迭代、循序渐进的开发方法。将计划和一些指导
性任务从项目经理移交给项目成员，让项目经理主要为项目成员移除障碍，实
现团队的目标。 .......................................................................................................74
5.2.2. 主要特点 ...................................................................................................74
5.2.2.1.
敏捷小组作为一个整体所有参与者都把自己看成朝向一个共同目
标前进的团队一员 ...............................................................................................75
5.2.2.2.
按短迭代周期工作，每次迭代称之为一次冲刺，每次只计划下一
次开发 75
5.2.2.3. 每次迭代交付一些成果并不强调需求基线管理 ..............................75
5.2.2.4. 关注业务优先级按照产品所有者制定的顺序交付功能 ..................75
5.2.2.5. 根据经常性的检查来调整开发过程 ..................................................75

12
 5.2.3. 使用小规模，基于时间盒的小项目或迭代 ...........................................75
5.2.4. 在每个迭代的末端都对项目进行重新计划 ...........................................75
5.2.5.
更以来默认的认知，这些知识与那些存于项目文档的知识不同，存于
人脑 75
5.2.6. 至少有些敏捷方法促进配对式编程，以便于知识共享和质量检查 ...75
5.2.7.
项目经理角色已经从计划项目、分配任务和监督项目进度转为项目促
进者和协调者 ...........................................................................................................75
5.2.8.
敏捷开发只会详细计划下一个迭代开发，不会一次性的详细计划之后
所有的开发阶段 .......................................................................................................75
5.2.9. 敏捷开发对于需求的适应性方法并不强调需求基线管理 ...................75

m
5.2.10.

co
敏捷开发的焦点是通过建立实际的功能来快速的证明一个软件和数据
结构，而不是以逐渐详细的模型和描述在早起就正式的定义软件和数据结构76

3.
5.2.11.
16
敏捷开发承认缺陷测试的限制，通过经常性的测试循环来验证系统功
能，以较小的时间盒成本来修正错误 ...................................................................76
5.2.12.
4@

敏捷开发并不强调已定义和重复定义的流程而是根据经常性的调查来
调整和改变开发过程 ...............................................................................................76
05

5.3. 原型法 ...............................................................................................................76

5.3.1.
67

方法一：为设计而建模（需求定义机制），然后，基于该模型而进行
体现效率、质量和维护特性的系统设计 ...............................................................76
2

5.3.2. 方法二：逐渐开发出能够运行使用第四代开发语言的系统 ...............76

80

5.3.3. 优点与缺点 ...............................................................................................76

5.3.3.1. 优点 ......................................................................................................76
5.3.3.1.1. 符合人们认识事物的规律，确保较好的用户满意度； ............77
5.3.3.1.2.
开发周期短，费用相对少；由于有用户的直接参与，系统更
加贴近实际； ...................................................................................................77
5.3.3.1.3. 易学易用，减少用户的培训时间； ............................................77
5.3.3.1.4. 应变能力强。 ................................................................................77
5.3.3.2. 缺点 ......................................................................................................77
5.3.3.2.1. 经常导致原始需求之外的额外功能的增加； ............................77
5.3.3.2.2. 变更控制变得复杂； ....................................................................77
5.3.3.2.3. 完成的系统在控制机制方面比较弱 ............................................77

13
 5.3.3.2.4. 开发过程管理要求高； ................................................................77
5.3.3.2.5.
用户过早看到原型，误认为系统就是这个模样，易使用户失去
信心； 77
5.3.3.2.6. 开发人员易将原型取代系统分析； ............................................77
5.3.3.2.7. 缺乏规范化的文档资料。 ............................................................78
5.3.4. 适用范围 ...................................................................................................78
5.3.4.1. 适用于：处理过程明确、简单系统；涉及面窄的小型系统 ..........78
5.3.4.2.
不适于：大型、复杂系统，难以模拟；存在大量运算、逻辑性强
的处理系统；管理基础工作不完善、处理过程不规范；大量批处理系统 ...78
5.3.5.
是指在获取一组基本的需求定义后，利用高级软件工具可视化的开发

m
环境，快速地建立一个目标系统的最初版本，并把它交给用户试用、补充和修

co
改，再进行新的版本开发。反复进行这个过程，直到得出系统的“精确解”，即
用户满意为止。 .......................................................................................................78

3.
5.4. 快速应用开发（RAD） ....................................................................................78
16
5.4.1.
是一种试图快速生成系统而不会牺牲质量的结构化开发方法。RAD与
4@

原型法有同样的目标--对用户需求做出快速反应，但它范围更广。.................78
5.4.2. 适用性 .......................................................................................................78
05

5.4.2.1. 适用RAD的情况 ...................................................................................79

5.4.2.1.1. 开发的软件相对独立，可以单独使用 ........................................79
67

5.4.2.1.2. 软件可利用许多现有的类库(APIs) ...............................................79

5.4.2.1.3. 系统操作性能(如速度)并非关键的考虑因素 ..............................79
2

5.4.2.1.4. 应用的开发可以使用高端的软件开发工具 ................................79

80

5.4.2.1.5. 系统用户覆盖面较窄(内部使用) ..................................................79

5.4.2.1.6. 项目的范围和时限都受到较严格的控制 ....................................79
5.4.2.1.7. 系统可靠性并非关键的考虑因素 ................................................79
5.4.2.1.8. 系统可分解成多个独立的模块 ....................................................79
5.4.2.1.9. 所采用的技术相对成熟(已使用超过一年) ..................................80
5.4.2.2. 不适用RAD的情况 ...............................................................................80
5.4.2.2.1. 应用软件必须与多个现有系统协同工作 ....................................80
5.4.2.2.2. 几乎没有现成可用的组件 ............................................................80
5.4.2.2.3. 程序具有很高的操作性能指标 ....................................................80
5.4.2.2.4. 系统开发不能使用高端的软件开发工具 ....................................80
5.4.2.2.5. 系统用户覆盖面广，数量大(面向大众) ......................................80
5.4.2.2.6. BAD偏离目标，变成快速但粗制滥造的开发..............................80

14
 5.4.2.2.7. 系统可靠性目标要求较高 ............................................................80
5.4.2.2.8. 系统无法模块化(无法进行多组同步开发) ..................................80
5.4.2.2.9. 使用过于“前卫”的技术，因而风险过高 .....................................80
5.4.3. 技术 ...........................................................................................................80
5.4.3.1. 小型、良好培训的开发团队 ..............................................................81
5.4.3.2. 演化原型法 ..........................................................................................81
5.4.3.3. 集成工具，支持模型、原型、组件重用 ..........................................81
5.4.3.4. 中央库存 ..............................................................................................81
5.4.3.5. 交互需求和设计工作组 ......................................................................81
5.4.3.6. 严格的开发时间限制 ..........................................................................81
5.4.4. 思路 ...........................................................................................................81
5.4.4.1.

m
概念定义阶段，定义业务功能和系统所需要支持的数据主题域，
决定系统范围 .......................................................................................................81

co
5.4.4.2.

3.
功能设计阶段所采用的工作组，将系统数据和过程模型化，建立
关键系统组件的原型 ...........................................................................................81
16
5.4.4.3.
开发阶段完成物理数据库和应用系统的构建，建立转换系统，开
4@

发用户帮助，部署工作计划 ...............................................................................81
5.4.4.4.
05

安装阶段包括所有最终用户测试和培训、数据转换、应用系统实
施 82
67

5.5. 面向对象开发 ...................................................................................................82

5.5.1.
2

客观世界是由各种各样的对象组成的，每种对象都有各自的内部状态
80

和运动规律，不同对象之间的相互作用和联系就构成了各种不同的系统。在设
计和实现一个客观系统时，在满足需求的条件下，把系统设计成一些不可变的
（相对固定）部分组成的最小集合（最好的设计）。这些不可变的部分就是所
谓的对象。 ...............................................................................................................82
5.5.2. 特点 ...........................................................................................................82
5.5.2.1. 封装性 ..................................................................................................82
5.5.2.2. 继承性 ..................................................................................................82
5.5.2.3. 多态性 ..................................................................................................82
5.5.3. 优点 ...........................................................................................................82
5.5.3.1.
采用特定的软件工具，直接完成从对象客体的描述到软件结构直
接的转换 83
5.5.3.2.
解决了传统方法中客观世界描述工具盒软件结构不一致的问题，

15
 缩短了开发周期，解决了分析到设计到软件模块结构直接多次转换映射的繁
杂过程 83
5.5.3.3.
面向对象的方法中的继承机制，支持了模型和代码在一个系统中
的重用，大大降低了软件系统的复杂性，提高了开发效率 ...........................83
5.5.3.4. 面向对象的封装性简化了开发过程 ..................................................83
5.5.3.5.
在一般情况下的开发，类似于封装性，由于多态性的支持，可以
无须对系统进行修改，减少了错误和开发的工作量，使系统对环境变化的适
应性增强。 ...........................................................................................................83
5.6. 基于组件的开发 ...............................................................................................83
5.6.1. 组件 ...........................................................................................................83
5.6.1.1. 过程内客户端组件（InprocessClientComponents）：浏览器 ........84

m
5.6.1.2. 独立客户端组件（StandaloneClientComponents）：Office............84

co
5.6.1.3.
独立服务器端组件（StandaloneServerComponents）：微软的DCO

3.
M、CORBA、SUN的RMI.......................................................................................84
16
5.6.1.4.
过程内服务器组件（InprocessServerComponents）：微软的MTS、
4@

SUN的EJB 84
5.6.2. 减少开发时间 ...........................................................................................84
05

5.6.3. 改善开发质量 ...........................................................................................84

5.6.4. 允许开发商更加关注业务功能 ...............................................................84
67

5.6.5. 加强模块化 ...............................................................................................84

5.6.6. 重用性 .......................................................................................................84
2

5.6.7. 减少开发支出成本 ...................................................................................84

80

5.6.8. 允许在构建和购买的选择之间进行完美折中 .......................................84

5.6.9. 支持多用户开发环境 ...............................................................................84
5.7. 基于WEB应用开发............................................................................................84
5.7.1. 组织内或不同组织间的异构代码模块的有效集成 ...............................85
5.7.2.
利用Web服务应用技术构建企业的基于互联网的分布式应用系统的方
法。 85
5.7.3. 特点 ...........................................................................................................85
5.7.3.1. 应用的分布式 ......................................................................................85
5.7.3.2. 应用到应用的交互性 ..........................................................................85
5.7.3.3. 平台无关性 ..........................................................................................85
5.8. 软件重组 ...........................................................................................................85

16
 5.8.1.
一个通过抽取、重用现存软件的设计与程序组件，对现有系统进行升
级的过程 ...................................................................................................................86
5.9. 逆向工程 ...........................................................................................................86
5.9.1. 指分析已有的程序，寻求比源代码更高级的抽象表现形式。 ...........86
5.9.2. 逆向工程采取的方式 ...............................................................................86
5.9.2.1. 将对象和可执行文件拆编成源代码，用它来分析程序； ..............86
5.9.2.2. 采用逆向工程作为黑盒，采用测试数据揭示它的功能。 ..............86
5.9.3. 优点 ...........................................................................................................86
5.9.3.1. 能够实现快速开发并降低SDLC的时间..............................................87
5.9.3.2. 能够改善代码的质量 ..........................................................................87
5.9.4. 风险 ...........................................................................................................87

m
5.9.4.1. 软件许可协议通常包括限制软件工程的声明 ..................................87
5.9.4.2. 反编译器的功能是否满足逆向工程需要 ..........................................87

co
5.9.4.3.

3.
反编译器通常是相对较新的软件工具，其功能依赖于具体计算机
、操作系统和编程语言，这些组件中的任何变化都会需要开发或购买新的反
16
编译器 87
5.9.4.4. 逆向工程过程控制； ..........................................................................87
4@

5.9.4.5. 成本费用控制 ......................................................................................87

6. 业务应用系统 ...........................................................................................................87
05

6.1. 电子商务 ...........................................................................................................88

6.1.1. 电子商务模型 ...........................................................................................88
67

6.1.1.1. BtoC ......................................................................................................89

6.1.1.2. BtoB ......................................................................................................89
2

6.1.1.3. CtoC ......................................................................................................89

80

6.1.1.4. BtoG......................................................................................................89
6.1.2. We bservice ...............................................................................................89
6.1.2.1.
是一个平台独立的，松耦合的，自包含的、基于可编程的web的
应用程序，可使用开放的XML标准来描述、发布、发现、协调和配置这些应
用程序，用于开发分布式的互操作的应用程序。 ...........................................89
6.1.3. 电子商务架构 ...........................................................................................89
6.1.4. 电子商务风险 ...........................................................................................89
6.1.4.1. 机密性 ..................................................................................................90
6.1.4.2. 完整性 ..................................................................................................90
6.1.4.3. 可用性 ..................................................................................................90
6.1.4.4. 身份鉴别和不可否认性 ......................................................................90
6.1.4.5. 选择转移到了消费者手中 ..................................................................90

17
 6.1.5. 电子商务的要求 .......................................................................................90
6.1.5.1. 构建一个业务案例 ..............................................................................90
6.1.5.2. 开发一个清晰的业务目标 ..................................................................90
6.1.5.3. 围绕四个方面来构建业务案例：消费者、成本、竞争者和能力 ..90
6.1.5.4. 业务流程再造 ......................................................................................90
6.1.5.5. 连接遗留系统 ......................................................................................91
6.1.6. 电子商务的审计和控制问题（最佳实践） ...........................................91
6.1.6.1.
有效的安全机制和程序，并把两者相结合为电子商务建立一个安
全体系 91
6.1.6.2.
把公共网络（Internet）和公司私有网络进行恰当分割的防火墙机

m
制 91
6.1.6.3. 参与到电子商务中心的过程能够被唯一地和正确的鉴别 ..............91

co
6.1.6.4. 数字签名 ..............................................................................................91

3.
6.1.6.5. 管理和控制公共秘钥对和相关证书的架构包括 ..............................91
6.2. 电子数据交换EDI ..............................................................................................91
16
6.2.1. 采用EDI的好处 ..........................................................................................91
6.2.1.1. 较少的书面工作 ..................................................................................92
4@

6.2.1.2. 较少的信息交换错误 ..........................................................................92

6.2.1.3. 改善了数据库到数据库，公司到公司的信息流 ..............................92
05

6.2.1.4. 没有多余的数据和重复键入 ..............................................................92

6.2.1.5. 较少的通讯延迟 ..................................................................................92
67

6.2.1.6. 改善了的计价和支付处理 ..................................................................92

2

6.2.2. 目的 ...........................................................................................................92
80

6.2.2.1.
在组织的不同计算机系统之间以标准的、计算机可处理的格式传
输业务交易数据。 ...............................................................................................92
6.2.2.2.
EDI接口可以产生和发送功能性确认（也叫回执，Acknowledgemen
t），以识别和验证商业伙伴的身份，通过检查商业伙伴的主文件的传输信
息，验证交易的正确定。 ...................................................................................92
6.2.2.3.
功能性确认是标准的EDI事务，告诉商业伙伴其电子文件已经收到
。不同类型的功能性确认提供了各个层次的细节情况，因此可以作为EDI交
易的审计轨迹。 ...................................................................................................92
6.2.3. 传统的EDI ..................................................................................................92
6.2.3.1. 通讯处理器 ..........................................................................................93

18
 6.2.3.2. EDI接口.................................................................................................93
6.2.3.3. 应用系统 ..............................................................................................93
6.2.4. EDI的风险和控制 ......................................................................................93
6.2.4.1. 交易授权的风险 ..................................................................................93
6.2.4.2. 法律责任 ..............................................................................................93
6.2.4.3. 业务持续能力的丧失 ..........................................................................93
6.2.4.4. 对电子交易未授权的访问 ..................................................................93
6.2.4.5. 在应用控制建立之前或之后对交易的删除和修改 ..........................93
6.2.4.6. EDI传输的遗失和重复.........................................................................93
6.2.4.7. 在第三方处理过程中EDI交易机密性的丧失和不适当的发送.........94
6.3. 电子邮件 ...........................................................................................................94
6.3.1. 电子邮件的安全 .......................................................................................94

m
6.3.1.1. 网上钓鱼是一种电子社会工程学攻击 ..............................................94

co
6.3.1.2.
邮件服务器应用程序配置上的漏洞可能会被用来作为损害服务器

3.
和所连接的网络的工具 .......................................................................................94
6.3.1.3.
16
拒绝服务攻击可以直接攻击邮件服务器，使其拒绝或阻碍合法用
户正常使用邮件服务器 .......................................................................................94
4@

6.3.1.4.
在发送者和接受者之间的邮件中的信息可能会在某些点被改变（
05

拦截） 94
6.3.1.5. 病毒和其他恶意代码可能会通过电子邮件而在组织中转播 ..........94
67

6.3.1.6.
用户可能会通过电子邮件发送不适当的、专有的或其他的敏感信
2

息，从而导致法律风险 .......................................................................................94
80

6.3.2. 电子邮件安全标准 ...................................................................................95

6.3.2.1. 通过建立维护和管理标准来保证邮件服务器的安全 ......................95
6.3.2.2.
确保邮件服务器应用程序的使用、配置和管理符合由管理层所设
定的安全标准和指南 ...........................................................................................95
6.3.2.3. 实施加密技术以确保用户身份鉴别和邮件数据的安全 ..................95
6.3.2.4. 签名不能被伪造 ..................................................................................95
6.3.2.5. 签名是可信的和被加密的 ..................................................................95
6.3.2.6.
签名不能被重新使用，即一个文件上的签名不能被传递到另一个
文件上 95

19
 6.3.2.7.
被签名的文件不能被改变，如何对文件的改变都会致使签名无效
，无论文件是否被加密 .......................................................................................95
6.4. POS系统.............................................................................................................95
6.4.1.
最重要的是确定是否有任何信用卡的信息存储在本地的POS系统，如
果有，则应使用强加密的加密方法。 ...................................................................95
6.5. 电子银行 ...........................................................................................................96
6.5.1.
电子银行的主要面临的是战略、经营和声誉上的风险，因为银行业务
中可靠数据流面临的威胁和操作中的风险都与这些因素有关。 .......................96
6.6. 电子金融 ...........................................................................................................96
6.6.1.

m
服务商在搜集用户信息并创建用户配置文件时，要考虑用户信息的机

co
密性，以及对这些信息使用的授权。 ...................................................................96
6.7. 电子支付系统 ...................................................................................................96
6.7.1.
3.
电子现金模式 ...........................................................................................96
16
6.7.1.1. 支付者在采购的时候并不需要在线（电子现金放在计算机中） ..97
6.7.1.2. 支付者可以具有无条件的不可追溯性 ..............................................97
4@

6.7.2. 电子支票模式 ...........................................................................................97

6.7.2.1. 容易理解和实施 ..................................................................................97
05

6.7.2.2. 电子签收的可用性，允许使用者在没有发行者的情况下解决争议
97
67

6.7.2.3. 付款人不需要在线来进行支付 ..........................................................97

6.7.3. 电子转账模式 ...........................................................................................97
2

6.7.3.1. 容易理解和实施 ..................................................................................97

80

6.7.3.2. 付款人要在线，收款人不需要在线 ..................................................98

6.8. 集成制造系统 ...................................................................................................98
6.9. 电子资金转账EFT..............................................................................................98
6.9.1. EFT的控制与审计关注点..........................................................................98
6.9.1.1. 银行卡的物理安全、用于生成PIN的程序 ........................................98
6.9.1.2. EFT系统的访问控制 ............................................................................98
6.9.1.3. EFT交换过程中涉及的网络 ................................................................98
6.9.1.4. EFT系统和应用系统之间的接口 ........................................................98
6.10. 自动提款机ATM................................................................................................98
6.10.1. ATM的审计关注点....................................................................................99
6.10.1.1. 识别客户身份的措施及保密性的措施 .............................................99
6.10.1.2. 对交易的追踪处理 .............................................................................99
6.10.1.3. 维护例外报告，提供审计轨迹 .........................................................99

20
 6.10.1.4. 对ATM交易的对账..............................................................................99
6.10.1.5. 加密密钥的变更管理程序 .................................................................99
6.11. 交互式语音响应 ...............................................................................................99
6.12. 采购财务系统 ...................................................................................................99
6.13. 图像处理 ...........................................................................................................99
6.14. 人工智能和专家系统AI ....................................................................................99
6.14.1. 专家系统的潜在好处 .............................................................................100
6.14.1.1. 在职员离开组织前获得他们的经验和知识 ...................................100
6.14.1.2. 在特别的专业技术领域共享知识和经验 .......................................100
6.14.1.3. 促进一致的和有效的质量决策 .......................................................100
6.14.1.4. 提高个人生产力和业绩 ...................................................................100
6.14.1.5. 使高度重复性的工作自动执行 .......................................................100

m
6.14.1.6. 在人类专家不能到达的地方作用 ...................................................100

co
6.14.2. 知识库 .....................................................................................................100
6.14.2.1. 决策树 ...............................................................................................101

3.
6.14.2.2. IF-Then规则 .......................................................................................101
16
6.14.2.3. 语义网络 ...........................................................................................101
6.14.2.4. 知识接口 ...........................................................................................101
4@

6.14.2.5. 数据接口 ...........................................................................................101

6.14.3. 审计师注意事项 .....................................................................................101
05

6.14.3.1. 理解系统的目的和功能 ...................................................................101

6.14.3.2. 评价系统对于组织及其相关业务过程的重要性和相关的潜在风险
67

101
6.14.3.3. 评价系统与组织的政策和程序的要求是否一致 ...........................101
2

6.14.3.4.
80

评价内置在系统中的决策逻辑，以确保专家的知识或系统中的人
工智能是可靠的准确的。审计师应当确保在开发基本的假设和模型时，使用
了适当水平的专家经验。 .................................................................................102
6.14.3.5. 评价知识库中信息的更新程序 .......................................................102
6.14.3.6. 评价系统的安全访问，尤其是访问知识库 ...................................102
6.14.3.7. 评价是否建立程序保证有足够的优质资源可用于系统维护和更新
102
6.15. 商业智能BI ......................................................................................................102
6.15.1. BI的一些经典领域 ..................................................................................102
6.15.1.1. 处理的成本、效率和质量 ...............................................................102
6.15.1.2. 客户对产品与服务的满意度 ...........................................................102

21
 6.15.1.3.
客户的盈利能力，明确产品或服务中哪一种属性可以作为客户盈
利预测指标 .........................................................................................................102
6.15.1.4. 员工和业务单元完成关键绩效指标 ...............................................102
6.15.1.5.
风险管理，通过确定不正常的加以和累积时间与损失的统计资料
来实施 103
6.15.2. 商业智能治理的关注点 .........................................................................103
6.15.2.1.
确定投资什么样的BI计划，对BI计划赋予什么样的优先级，如何
测量投资回报。 .................................................................................................103
6.15.2.2.
对数据的治理，包括建立标准数据定义，业务规则和测量尺度，

m
确定数据来源等等。 .........................................................................................103

co
6.15.3. 数据流结构 .............................................................................................103
6.15.3.1. 表现层/桌面访问层 ..........................................................................103

3.
6.15.3.2. 数据资源层 .......................................................................................104
16
6.15.3.3. 核心数据仓库 ...................................................................................104
6.15.3.4. 数据集市层 .......................................................................................104
4@

6.15.3.5. 数据运输层/质量控制层 ..................................................................104

6.15.3.6. 数据访问层 .......................................................................................104
05

6.15.3.7. 数据准备层 .......................................................................................104

6.15.3.8. 元数据存储层 ...................................................................................104
67

6.15.3.9. 数据仓库管理层 ...............................................................................104

6.15.3.10. Internet/Intranet层 .........................................................................104
2

6.15.4. 对商业智能的治理 .................................................................................104

80

6.16. 决策支持系统DSS ...........................................................................................104

6.16.1.
是辅助决策者通过数据、模型和知识，以人机交互方式进行半结构化
或非结构化决策的 计算机应用系统。 ................................................................104
6.16.2. 决策支持系统的特征 .............................................................................104
6.16.2.1. 以解决半结构化、非结构化、不确定的问题为目标 ...................105
6.16.2.2. 使用传统的数据访问和检索功能，结合模型和分析技术来使用105
6.16.2.3. 强调灵活性和适应性 .......................................................................105
6.16.2.4. 注重效果（正确的完成任务）而不是效率（快速完成） ...........105
6.16.3. 决策支持系统面临的风险 .....................................................................105
6.16.3.1. 不存在的或不愿意的用户 ...............................................................105
6.16.3.2. 多个用户或多个实施者 ...................................................................105
6.16.3.3. 消失的用户、实施者和维护者 .......................................................105

22
 6.16.3.4. 不能事先详细说明目的或使用模式 ...............................................105
6.16.3.5. 不能预测对当事人的影响 ...............................................................105
6.16.3.6. 缺乏或失去支持 ...............................................................................105
6.16.3.7. 缺乏实施经验 ...................................................................................105
6.16.3.8. 技术问题和成本效益问题 ...............................................................105
6.17. 客户关系管理CRM..........................................................................................105
6.18. 供应链管理 .....................................................................................................105
7. 基础设施开发与获取实务 .....................................................................................106
7.1. 物理架构分析的各项阶段 .............................................................................106
7.1.1. 对现有架构的检查 .................................................................................106
7.1.2. 分析与设计 .............................................................................................106
7.1.3. 起草初步功能要求 .................................................................................106

m
7.1.4. 供应商与产品选择 .................................................................................106

co
7.1.5. 功能需求的正式成文 .............................................................................106
7.1.6. 概念验证（POC） ..................................................................................106

3.
7.2. 基础设施的规划实施 .....................................................................................106
16
7.2.1. 技术架构采购 .........................................................................................107
7.2.2. 制定交付计划 .........................................................................................107
4@

7.2.3. 制定安装计划 .........................................................................................107

7.2.4. 制定安装测试计划 .................................................................................107
05

7.3. 关键成功因素 .................................................................................................107

7.3.1.
67

要吸收有一定技能的合适成员参加到工作组中来，并要全程参与项目
实施，以避免产生项目延误 .................................................................................107
2

7.3.2. 完成工作所需的文档应当在项目开始时就准备好 .............................107

80

7.3.3.
决策制定者必须参与项目的各个环节，以确保所有必要的决策能快速
制定出来 .................................................................................................................107
7.3.4.
为作好准备，必须完成项目的第一部分工作（物理架构分析），并为
所需基础设施方案做出决策 .................................................................................107
7.4. 硬件获取 .........................................................................................................107
7.4.1. 准备邀标书 .............................................................................................108
7.4.1.1. 详细描述组织所需的计算机设施时中心式，分布式还是外包式 108
7.4.1.2. 信息处理需求 ....................................................................................108
7.4.1.3. 系统软件 ............................................................................................108
7.4.1.4. 支持需求 ............................................................................................108
7.4.1.5. 适应性需求 ........................................................................................108

23
 7.4.1.6. 约束条件 ............................................................................................108
7.4.1.7. 转换需求 ............................................................................................108
7.4.2. 获取步骤 .................................................................................................108
7.4.2.1. 拜访其他用户或获取其他用户的推荐书 ........................................109
7.4.2.2. 提供竞争性报价 ................................................................................109
7.4.2.3. 根据需求对报价进行分析 ................................................................109
7.4.2.4. 根据评价标准，对竞争报价进行对比分析 ....................................109
7.4.2.5. 对供应商的财务状况进行分析 ........................................................109
7.4.2.6. 对供应商提供维护与支持能力的状况进行分析 ............................109
7.4.2.7. 根据需求对交付的日程安排进行评审 ............................................109
7.4.2.8. 对软件、硬件升级能力的分析 ........................................................109
7.4.2.9. 对安全与控制设施的分析 ................................................................109

m
7.4.2.10. 针对需求的绩效评价 .......................................................................109

co
7.4.2.11. 针对价格的协商与评审 ...................................................................109
7.4.2.12. 对合同内部的评审（包括审计权力的条款） ...............................109

3.
7.4.2.13.
16
形成正式的书面报告，以对每一种可选的方案进行分析，并基于
成本效益原则对选择的方案进行验证 .............................................................110
4@

7.5. 系统软件获取 .................................................................................................110

7.5.1. 业务功能和技术需求与规范 .................................................................110
7.5.2. 成本与效益 .............................................................................................110
05

7.5.3. 系统的过时与失效 .................................................................................110

67

7.5.4. 与现有系统的兼容性 .............................................................................110

7.5.5. 安全 .........................................................................................................110
2

7.5.6. 对现有员工的要求 .................................................................................110

80

7.5.7. 未来增长的需求 .....................................................................................110

7.5.8. 对系统与网络性能的影响 .....................................................................110
7.5.9. 培训与聘用要求 .....................................................................................110
7.5.10. 开放源代码与知识产权代码的比较 .....................................................110
7.6. 系统软件实施 .................................................................................................111
8. 信息系统维护实务 .................................................................................................111
8.1. 变更管理过程 .................................................................................................111
8.1.1.
程序员不能拥有写、修改和删除系统数据的权限也不能获得读取敏感
信息的权限。如果职责无法分离，必须遵守变更管理流程，程序员必须得到必
要的授权，防止未经授权的程序变更。 .............................................................111
8.1.2. 部署更新 .................................................................................................111
8.1.3. 文档 .........................................................................................................111

24
 8.1.4. 测试变更的程序 .....................................................................................111
8.1.5. 审计程序变更 .........................................................................................111
8.1.6. 紧急变更 .................................................................................................111
8.1.6.1.
需考虑的因素：需要有特殊的登录ID，以保证人员能够暂时访问
生产环境。 .........................................................................................................112
8.1.7. 将变更部署回生产中 .............................................................................112
8.1.8. 变更的风险 .............................................................................................112
8.2. 配置管理 .........................................................................................................112
8.2.1.
是对软件修改进行标识、组织和控制的技术，用来协调和控制整个系
统过程。目的是为了减少混乱，提高软件生产率。 .........................................112

m
8.2.2. 指定配置管理计划 .................................................................................112
8.2.3. 将代码和相关文档基线化 .....................................................................112

co
8.2.4. 分析配置控制结果并报告 .....................................................................112

3.
8.2.5. 提供配置状态信息的报告 .....................................................................112
8.2.6. 制定发布程序 .........................................................................................112
16
8.2.7. 进行配置控制活动，如识别和记录申请 .............................................113
8.2.8.
4@

更新配置状态记录数据库 .....................................................................113
8.3. 配置管理工具 .................................................................................................113
8.3.1. 识别与变更申请相关的配置项并帮助进行影响评估 .........................113
05

8.3.2. 记录授权变更影响到的配置项 .............................................................113

8.3.3. 按照授权记录实施变更 .........................................................................113
67

8.3.4. 当授权的变更发布完成，对配置项的变更进行注册 .........................113

8.3.5.
2
80

记录基线，这些基线与发布相关，而这些发布的变更如果执行失败则
组织要倒退 .............................................................................................................113
8.3.6. 为了避免人工错误和资源浪费，进行自动化发布 .............................113
9. 过程改进实务 .........................................................................................................113
9.1. 业务流程再造和流程改变项目 .....................................................................113
9.1.1. BPR应当采取的步骤 ...............................................................................114
9.1.1.1. 定义评价的领域 ................................................................................114
9.1.1.2. 开发一个项目计划 ............................................................................114
9.1.1.3. 在评价的基础上获得对流程的理解/标杆管理 ..............................114
9.1.1.4. 重新设计流程并使其更有效 ............................................................114
9.1.1.5. 实施并监督新的流程 ........................................................................114
9.1.1.6. 确定一个持续的改进流程 ................................................................114
9.1.2. 业务流程再造的标杆管理 .....................................................................114

25
 9.1.2.1.
标杆管理主要是用于改善组织的业务过程，被定义为评价组织的
产品、服务和工作流程的一个持续的、系统的过程。 .................................114
9.1.2.2. (1)计划：确定关键流程，如何评价................................................115
9.1.2.3. (2)研究：收集流程的基线数据确定标杆对象................................115
9.1.2.4. (3)观察访问标杆对象，并收集资料................................................115
9.1.2.5. (4)分析总结并分析组织流程与标杆对象流程之间的差异............115
9.1.2.6. (5)调整调整标杆比对的结果把发现转换为行动计划....................115
9.1.2.7. (6)改进持续改进，把每个流程与组织战略和目标改进联系在一起
115
9.1.3. 业务流程再造的审计 .............................................................................115
9.1.3.1. 组织与流程的变更要与整个文化和战略计划相一致 ....................115

m
9.1.3.2. 使任何变更对组织成员造成的消极影响降低到最小的程度 ........115
9.1.3.3. 记录在BPR项目完成之后应当吸取的教训......................................115

co
9.1.4.

3.
信息系统审计师的任务就是要确定组织中现存的关键控制，并评价溢
出这些控制对组织的负面影响 .............................................................................115
16
9.1.5.
业务流程再造最需要关注的问题：一些关键控制可能会在业务重组过
4@

程中没有被纳入到新流程中去。 .........................................................................115
9.2. ISO9126............................................................................................................115
9.3. CMMI ...............................................................................................................115
05

10. 系统开发工具和辅助工具 .................................................................................115

67

10.1. 代码产生器 .....................................................................................................116

10.2. 计算机辅助软件工程CASE .............................................................................116
2

10.2.1. 前端 .........................................................................................................116
80

10.2.2. 中端 .........................................................................................................116
10.2.3. 后端 .........................................................................................................116
10.3. 第四代编程语言 .............................................................................................116
10.3.1. 非结构化语言 .........................................................................................117
10.3.2. 环境无关性 .............................................................................................117
10.3.3. 软件功能强 .............................................................................................117
10.3.4. 支持程序员工作台的概念 .....................................................................117
10.3.5. 使用简单语言子集 .................................................................................117
10.3.6. 查询与报告生成器 .................................................................................117
10.3.7. 嵌入式数据库 .........................................................................................117
10.3.8. 关系数据库 .............................................................................................117
10.3.9. 应用程序生成器 .....................................................................................117
11. 应用控制 .............................................................................................................117

26
 11.1. 输入控制/源头控制........................................................................................118
11.1.1. 输入授权 .................................................................................................118
11.1.1.1. 纸质签字授权 ...................................................................................118
11.1.1.1.1. 在一批表格和源文件上签字（提供了恰当的授权的证据） 119
11.1.1.2. 电子授权/在线访问控制 ..................................................................119
11.1.1.2.1.
在线访问控制（保证只有经授权的人可以访问数据或执行敏
感的职能） 119
11.1.1.3. 访问口令/密码 ..................................................................................119
11.1.1.3.1.
唯一性口令（不能因使用其他人的数据访问口令而损害系统
的访问授权机制，个人口令要对数据变动承担责任） .............................119
11.1.1.4. 访问终端限制 ...................................................................................119

m
11.1.1.4.1.

co
终端或客户工作站的识别（用于限制系统只接受由特定的终
端、工作站和个人输入的信息） .................................................................120

3.
11.1.1.5. 具有输入控制的表单 .......................................................................120
16
11.1.1.5.1. 源文件（指常用于记录的表单） ............................................120
11.1.2. 批控制和批平衡 .....................................................................................120
4@

11.1.2.1. 批控制 ...............................................................................................120

11.1.2.1.1.
05

总金额：确认被系统处理的项目总金额等于处理批文件中项
目金额之和 120
67

11.1.2.1.2.
总项目数：确定在本批次中的每一个文件中的项目总数被处
2

理的项目总数一致 .........................................................................................120
80

11.1.2.1.3. 总文件数：确认一个批次中文件总数等于被处理的文件总数
121
11.1.2.1.4.
杂数总和：确认一个批次中的所有文件中的数值类字段的总
和（虽然不同类型字段加起来的值并没有实际意义）与系统计算出来的综
合相等 121
11.1.2.2. 批平衡 ...............................................................................................121
11.1.2.2.1. 批注册 ........................................................................................121
11.1.2.2.2. 控制账户 ....................................................................................121
11.1.2.2.3. 计算机一致 ................................................................................121
11.1.3. 错误报告和错误处理方法 .....................................................................121
11.1.3.1. 仅拒绝有错误的事务 .......................................................................121
11.1.3.2. 拒绝整批事务 ...................................................................................121

27
 11.1.3.3. 暂停输入批次 ...................................................................................121
11.1.3.4. 整批接收并对错误事务做标识 .......................................................122
11.1.4. 联机系统或数据库系统中的批输入完整性 .........................................122
11.2. 处理程序和控制程序 （数据确认与编程控制） ........................................122
11.2.1. 顺序检查（sequencecheck）
例如，发票是按照顺序编号，这一天的发票开始于12001号并结束于15045号
，如果在处理过程中遇到一张大于15045的发票，就可作为一张无效发票而拒
绝处理 122
11.2.1.1.
任何没按顺序，或者顺序混乱的情况将被拒绝或记录为例外情况
。比如发票的顺序编号。 .................................................................................122
11.2.2. 限制检查（limitcheck）

m
例如，工资支票不应该超过4000美元，如果一张支票超过4000美元，该数据
将被拒绝以待进一步的极限确认或授权。 .........................................................123

co
11.2.2.1. 检查数据是否超过预定义的阈值。 ...............................................123

3.
11.2.3. 范围检查（rangecheck）
例如，产品类型的范围是从100到250，任何一个不在该范围内的编码将被视
16
为无效的产品类型而拒绝处理。 .........................................................................123
4@

11.2.3.1. 检查数据是否在预定义的值的范围之内。 ...................................123

11.2.4. 有效性检查（validitycheck）
例如，工资记录包含一个“婚姻”字段，期可接受的状态是"M"或"S"，输入任何
05

一个其他的编码将会被程序拒绝。 .....................................................................123
11.2.4.1. 按照预定义的输入标准对数据有效性进行检查。 .......................123
67

11.2.5. 合理性检查（reasonablenesscheck）
2

例如，在大多数情况下，一个小配件制造商通常所接受的订单不超过20个配
80

件，一旦任何一个订单超过20个配件，计算机程序就需要打印该记录并警告
提示该订单不合理 .................................................................................................124
11.2.5.1. 输入的数据与预定义的合理极限或发生率相匹配 .......................124
11.2.6. 查表（Tablelook-ups）
例如，录入员输入一个1到10的城市代码，这个数字就与存储在计算机中的城
市预定义名称相匹配，计算机就知道“1”代表“华盛顿”，“2”代表的是“纽约”。
124
11.2.6.1. 输入的数据必须与存储在数据库中预定义的值相符合。 ...........124
11.2.7. 存在性检查（Existencecheck）
数据被正确输入并与有效的预定义的标准一致。例如，一个有效的事物代码必
须在事务代码区域输入。 .....................................................................................124
11.2.7.1. 数据输入要与有效的预定义的标准一致。 ...................................125

28
 11.2.8. 击键校验（Keyverification）
例如，工人的代码被不同的录入人员键入两次，并比较这两者击键差距，以确
认工人输入过程中没有出现错误。 .....................................................................125
11.2.8.1.
不同的人员在同一个设备分别录入数据，通过计算机来比较录入
人员的击键顺序的差异来发现录入错误。 .....................................................125
11.2.9. 校验数位（Checkdigit）
例如，一个校验数位增加到一个账号后，当其使用时就可以检查其正确性。
125
11.2.9.1.
在数据后面附加一个经过计算的校验值，确保原始数据不被改变
或替换，用于检测数据的转换。 .....................................................................125
11.2.10. 完整性检查（completenesscheck）

m
一个字段应当总是包含非零和非空数据，要对该字段的每一个字节都要进行检

co
查，以检测是否满足非零和非空的条件。 .........................................................125
11.2.10.1.

3.
检查数据是否满足非空或非零的要求，一般该字段是数据库的关
键字段，不能为空。 .........................................................................................126
16
11.2.11. 重复检查（Duplicatecheck）
4@

新的事务应当与以前输入过的事务进行匹配，以确保该事务没有被重新输入
126
11.2.11.1. 数据要求不能重复，要保持唯一性。比如发票编号。 .............126
05

11.2.12. 逻辑关系检查（Logicalrelationship）
例如，雇员的雇佣时间要大于其生日16年。 .....................................................126
67

11.2.12.1. 输入的数据要符合预定的逻辑关系。 .........................................126

11.2.13. 处理控制................................................................................................126
2

11.2.13.1.
80

保证计算数据的完整性和准确性。保证数据在文件或数据库中的
完整和准确，只有授权的处理或程序才能对数据进行更改。 .....................126
11.3. 数据文件控制 .................................................................................................126
11.3.1. 处理前后的数据映像报告 .....................................................................127
11.3.1.1. 应当保留实务处理前后的数据映像，便于对事务进行追踪。 ...127
11.3.2. 错误报告的维护与处理 .........................................................................127
11.3.2.1. 应当有控制程序来保证错误报告被正确的核对和纠正，提交。127
11.3.3. 源文件保存期 .........................................................................................127
11.3.3.1.
源文件应当保持一个足够的时间期限，以确保对数据检索、重组
和验证的需要。 .................................................................................................128
11.3.4. 内部和外部标签 .....................................................................................128

29
 11.3.4.1.
应该有可移动存储介质的物理标签和文件内部的标签，前者保证
数据被正确的调用，后者保证数据被正确的使用。 .....................................128
11.3.5. 版本的使用 .............................................................................................128
11.3.5.1.
文件的使用应该确保是正确的版本，否则可能会造成数据的不准
确和不一致。 .....................................................................................................128
11.3.6. 数据文件安全 .........................................................................................128
11.3.6.1. 防止非授权人员对应用程序与数据的非授权访问。 ...................129
11.3.7. 一对一检查 .............................................................................................129
11.3.7.1. 确保每一个文件都与计算机处理的文件清单相符合。 ...............129
11.3.8. 预录输入 .................................................................................................129
11.3.8.1.

m
特定字段的输入内容已经被系统预先填入到相应的表单，以减少

co
错误。 129
11.3.9. 事务日志 .................................................................................................129
11.3.9.1. 所有的事务活动都应当由计算机记录下来，形成日志。 ...........130
3.
16
11.3.10. 文件更新和维护的授权........................................................................130
11.3.10.1.
4@

可以保证存储的数据受到了充分的保护，保证数据是正确的和及
时更新的。 .........................................................................................................130
05

11.3.11. 奇偶校验检查........................................................................................130
11.3.11.1.
67

用于在重要的数据传输时，通过错误检测代码和纠正代码来防止
出现错误。 .........................................................................................................130
2

11.4. 在线事务处理中的数据完整性 .....................................................................130

80

11.4.1. 原子性Atomicity：一个事务，要么完整执行，要么就回退到原始状态
131
11.4.2. 一致性Consistency：数据的更新要遵守所有的完整性约束 ..............131
11.4.3. 隔离性Isolation：每一个事务与其他事务相互隔离 ...........................131
11.4.4. 持久性Durability：对数据的任何变化都能恢复 .................................131
11.5. 数据完整性测试 .............................................................................................131
11.5.1. 关系完整性测试 .....................................................................................131
11.5.2. 参照完整性测试 .....................................................................................131
11.6. 对应用系统控制的测试方法 .........................................................................131
11.6.1. 快照 .........................................................................................................132
11.6.1.1. 描述：记录在程序中通过逻辑路径的指定事务流 .......................132
11.6.1.2. 优点：可以验证程序逻辑 ...............................................................132
11.6.1.3. 缺点：要求广博的信息系统知识 ...................................................132

30
 11.6.2. 映射 .........................................................................................................132
11.6.2.1. 描述：确定没有被测试的程序的逻辑 ...........................................132
11.6.2.2.
优点：通过识别非执行的程序代码来增加效率，可以识别潜在的
漏洞 133
11.6.2.3. 缺点：软件的成本 ...........................................................................133
11.6.3. 追踪和标识 .............................................................................................133
11.6.3.1.
描述：在输入时对所选择的事务做标记，并进行追踪，从而显示
出指令执行的轨迹。 .........................................................................................133
11.6.3.2. 优点：提供了一个准确的事件顺序图 ...........................................133
11.6.3.3.
缺点：要求有大量的计算事件，要熟悉应用程序，要额外编程以

m
执行追踪程序 .....................................................................................................133

co
11.6.4. 测试数据 .................................................................................................133
11.6.4.1.
描述：模拟某些业务数据，将测试数据输入系统，通过系统处理
3.
16
来检查系统对实际业务中同类数据处理的正确性。 .....................................133
11.6.4.2. 优点：可以使用实际主文件或虚构的模拟文件；
4@

没有必要审核源代码； 可以在怀疑的基础上使用这种方法；
提供客观的审核和验证； 开始时只使用在特定功能上，以减小范围；
要求最少的信息系统知识。 .............................................................................133
05

11.6.4.3. 缺点：很难保证恰当的程序被检查； 不包含所有的交易风险；

67

需要较深的业务知识； 不能测试主文件与主文件中的记录。 ....................134

11.6.5. 基础用例系统评价 .................................................................................134
2

11.6.5.1.
80

描述：使用已开发的测试数据集作为对程序全面测试的一部分；
在接受和定期确认有效性之前用来验证正确的系统操作。 .........................134
11.6.5.2. 优点：综合测试验证和符合性测试 ...............................................134
11.6.5.3. 缺点：需要大量的维护数据集工作；要求所有参与者紧密合作。
134
11.6.6. 平行作业 .................................................................................................134
11.6.6.1. 描述：现有程序与新开发程序同时进行处理，并比较其结果。134
11.6.6.2. 优点：在停止旧系统之前，验证新系统 .......................................134
11.6.6.3. 缺点：增加了处理成本 ...................................................................134
11.6.7. 集成测试设施ITF.....................................................................................134
11.6.7.1. 描述：在数据库中创建测试数据，与生产数据同时处理事务 ...135
11.6.7.2. 优点：定期测试时，不要求单独的测试程序 ...............................135
11.6.7.3. 缺点：需要详细的计划； 测试数据必须与生产数据隔离...........135

31
 11.6.8. 平行模拟 .................................................................................................135
11.6.8.1. 描述：开发新的模拟程序，来处理实际业务和生产数据 ...........135
11.6.8.2. 优点：不需要准备测试数据 ...........................................................135
11.6.8.3. 缺点：需要开发模拟程序 ...............................................................135
11.6.9. 事务选择程序 .........................................................................................135
11.6.9.1. 描述：使用审计软件来筛选用于常规生产周期的事务输入 .......135
11.6.9.2. 优点：独立于生产系统 由审计师控制
要求不能对生产系统进行修改 .........................................................................136
11.6.9.3. 缺点：开发与维护的成本 ...............................................................136
11.6.10. 嵌入式审计数据收集............................................................................136
11.6.10.1.
描述：在生产系统中将审计软件嵌入到应用程序中，过滤和筛选

m
所需的事务和数据。 .........................................................................................136
11.6.10.2.

co
优点：提供抽样和实际业务数据的统计资料。可采集：应用系统

3.
错误、系统例外情况、统计样本等。 .............................................................136
11.6.10.3. 缺点：开发和维护的成本高； 存在审计师的独立性问题。.....136
16
11.6.11. 扩充记录................................................................................................136
11.6.11.1. 描述：收集受某个特定程序影响的所有数据 .............................136
4@

11.6.11.2. 优点：记录可以放到一个适宜的文件中去 .................................136

11.6.11.3. 缺点：增加了数据存储成本、管理成本和系统的开发成本。 .136
05

11.7. 联机/在线审计技术........................................................................................136
11.7.1. 系统控制审计检查文件和内嵌审计模型（SCARF/EAM）..................137
67

11.7.1.1.
简要描述：通过在应用系统中嵌入经特别编写的审计软件，使审
2

计师能选择审计哪些内容。 .............................................................................137
80

11.7.1.2. 复杂性：非常高 ...............................................................................137

11.7.1.3. 适用于：正常处理不能被中断时 ...................................................137
11.7.2. 快照（Snapshots）.................................................................................137
11.7.2.1.
简要描述：记录一个事务从输入到输出的各阶段的处理轨迹。通
常在应用系统的重要处理发生点嵌入软件，当交易通过不同处理点时，嵌入
软件可捕捉交易的前映像和后映像，通过检验前映像、后映像及其变换，评
价交易处理的真实性、准确性和完整性。 .....................................................137
11.7.2.2. 复杂性：中 .......................................................................................137
11.7.2.3. 适用于：需要审计轨迹的时候 .......................................................137
11.7.3. 审计钩（AuditHooks） ..........................................................................138
11.7.3.1.
简要描述：在应用系统中内嵌程序“钩”，像标识符那样起作用，

32
 在错误或违规事务、流程失去控制之前，提醒信息系统审计师采取行动。
138
11.7.3.2. 复杂性：低 .......................................................................................138
11.7.3.3. 适用于：只有所选的事务或流程需要被检查时 ...........................138
11.7.4. 集成测试设施（ITF）.............................................................................138
11.7.4.1.
简要描述：在应用系统正常处理其业务时，用测试数据对系统进
行检测的一种方法。这种方法要在应用系统的文件中建立一个虚拟实体，并
让应用系统处理该实体的审计测试数据。 .....................................................138
11.7.4.2. 复杂性：高 .......................................................................................138
11.7.4.3. 适用于：采用测试数据没有益处时 ...............................................138
11.7.5. 持续和间歇性模拟（CIS） ....................................................................138
11.7.5.1.

m
简要描述：在一个事务的处理运行期间，系统模拟应用程序指令

co
的执行。在一个事务输入时，模拟器确定该事务是否符合预定的标准，如果
符合就审计该事务，否则就等待直到下一个符合的出现。 .........................139

3.
11.7.5.2. 复杂性：中 .......................................................................................139
16
11.7.5.3. 适用于：符合能某些标准的事务需要被检查时 ...........................139
11.8. 输出控制 .........................................................................................................139
4@

11.8.1. 在安全的地方登记和存储重要表单 .....................................................139

11.8.1.1. 简要描述 ...........................................................................................139
05

11.8.1.2. 复杂性 ...............................................................................................139

11.8.1.3. 适用于 ...............................................................................................139
67

11.8.2. 计算机生产可流通的通知、表单和签名 .............................................139

11.8.2.1. 简要描述 ...........................................................................................140
2

11.8.2.2. 复杂性 ...............................................................................................140

80

11.8.2.3. 适用于 ...............................................................................................140

11.8.3. 报告分发 .................................................................................................140
11.8.4. 平衡和核对 .............................................................................................140
11.8.5. 输出错误处理 .........................................................................................140
11.8.6. 输出报告保管 .........................................................................................140
11.8.7. 报告接收确认 .........................................................................................140

33
 m
co
1. 业务实现

3.
16
4@
05
67

1.1. 项目组合与项目群管理
2
80

1.1.1. 项目是特定条件下，具有特定目标的一次性任务，是在一定时间内，满
足一系列特定目标的多项相关工作的总称。

34
 1.1.1.1. 短期的，战术性

1.1.2. 项目群可以看成是由一系列项目和有时间边界的任务组成，这些项目和
任务通过共同的目标、共同的预算、相互交织的日常和策略等精密地联系在一

m
起。

co
3.
16
4@
05

1.1.2.1. 长期的，战略性的
67

1.1.3. 项目组合（业务一致性）是在一个给定的时间点上，组织中正在进行的
2
80

所有项目的集合

1.1.3.1. 管理周期（每季度、每年）

1.2. 业务案例制定与审批

35
 1.2.1. 在进行规划IT项目时，无论是开发新系统还是投资建设基础设施，都需要
先考虑业务案例（也被译为商业模式、业务案例等），组织可以获得业务收益
才是实施IT项目的源动力。

1.2.2. 项目发起人、IT指导委员会负责

m
1.2.3. IT项目的全生命周期内评估

co
3.
1.3. 实施业务收益的技术
16
4@
05
2 67
80

1.3.1. 验证预期的业务收益

1.3.2. 计划中收益得到了实现

1.3.3. 对业务收益进行描述

1.3.4. 制定测量方法和目标

1.3.5. 记录前提条件

1.3.6. 建立实现利益的职责

36
 1.3.7. 建立追踪和测量的制度

1.3.8. 系统实施6-18个月后进行实施后评审

2. 项目管理结构

m
co
3.
16
2.1. 项目管理三要素
4@
05
2 67
80

2.1.1. 时间（时间期限）

2.1.2. 成本（资源或预算）

2.1.3. 交付物/范围（功能需求）

2.2. 项目管理一般过程

37
 m
2.2.1. 启动

co
3.
16
4@
05

2.2.1.1. PID/PRD的审批
67

2.2.2. 计划
2
80

2.2.3. 执行

2.2.4. 控制

2.2.5. 收尾

2.3. 项目环境

38
 2.3.1. 组织中项目的重要性

2.3.2. 组织战略和项目之间的联系

2.3.3. 与其他项目之间的关系

m
co
2.3.4. 项目与业务效益分析之间的关系

2.4. 项目组织形成
3.
16
4@
05
2 67
80

2.4.1. 职能式组织形式

2.4.1.1. 项目经理只作为一个成员，没有正式的管理权限。

2.4.2. 矩阵式组织形式

39
 2.4.2.1. 项目经理与部门经理共同分担管理权限。

2.4.3. 项目式组织形式

m
co
3.
16
4@

2.4.3.1. 项目经理有正式的授权来负责项目。
05

2.5. 项目沟通与文化
2 67
80

2.5.1. 一对一的面谈

2.5.2. 项目启动会议KICKOFF

2.5.3. 项目初期的研讨会

2.5.4. 以上方式的综合使用

40
 2.6. 项目目标管理原则SMART

2.6.1. S具体(Specific)，绩效考核要切中特定的工作指标，不能笼统

2.6.2. M可度量(Measurable)，指标是可量化的，验证这些指标的数据或者信息
是可获得的；

m
2.6.3. A可实现(Attainable)，指标在付出努力的情况下可以实现，避免设立过高

co
或过低的目标

3.
16
2.6.4. R现实性(Realistic），指标是可以证明和观察；绩效指标是与本职工作相
关联的
4@

2.6.5. T有时限(Timebased)based)，注重完成绩效指标的特定期限。
05

2.7. 项目目标
2 67
80

2.7.1. OBS

2.7.2. WBS

2.7.3. WP

41
 2.8. 项目中的团队及个人的角色和职责

m
co
2.8.1. 高级管理层

2.8.2. 用户管理部门
3.
16
2.8.3. 项目指导委员会
4@

2.8.4. 项目发起人
05

2.8.5. 系统开发管理部门
67

2.8.6. 项目经理
2
80

2.8.7. 系统开发项目小组

2.8.8. 用户项目小组

2.8.9. 安全主管

2.8.10. 质量保证

3. 项目管理实务

42
 3.1. 项目发起

m
co
3.
16
3.1.1. 项目宪章：描述了项目的目标，项目相关方，项目经理及项目发起人
4@

3.2. 项目计划
05
2 67
80

3.2.1. 软件规模估计

43
 3.2.1.1. 源代码行数SLOC

m
3.2.1.2. 功能点分析FPA

co
3.
16
4@
05

3.2.1.2.1. 基于输入、输出、文件、接口和查询的数量和复杂度。适用于大
多数标准的应用软件开发但对于网站或者与页面表格、图片等有很大关系
67

的开发，则需要进一步修正。FPA不适于操作系统、处理控制、通讯、工程
2

类软件的评估。
80

3.2.1.2.1.1. 外部输入EI-ExternalInput

3.2.1.2.1.2. 外部输出EO-ExternalOutput

3.2.1.2.1.3. 外部查询EQ-ExternalQuery

44
 3.2.1.2.1.4. 内部逻辑文件ILF-InternalLogicalFile

3.2.1.2.1.5. 外部接口文件EIF-ExternalInterfaceFile

3.2.2. 软件成本估计

m
co
3.2.2.1. 人力成本
3.
16
3.2.2.2. 工具成本
4@

3.2.2.3. 管理成本
05

3.2.2.4. 办公费用
67

3.2.3. 进度计划和期限
2
80

3.2.3.1. 甘特图

45
 3.2.3.1.1. 显示任务开始时间和结束时间，任务完成顺序，任务的资源分配
，也可以追踪里程碑。

3.2.3.2. 项目评审技术PERT

m
co
3.
16
3.2.3.2.1. 也是一种CPM技术
4@

3.2.3.2.2. PERT时间乐观完成时间+4×最可能完成时间悲观完成时间））/6
05

3.2.3.2.3. 设计项目的PERT网络图时，第一步是识别所有任务、项目的里程
67

碑和它们的相对次序。
2

3.2.3.3. 关键路径发CPM
80

3.2.3.3.1. 关键路径代表了整个项目预计的最短耗时，关键路径上的任务没
有时间弹性，不在关键路径上的任务具有一定的时间弹性。

46
 3.2.3.3.2. 正向遍历整个网络，可以确定关键路径；逆向遍历整个网络，可
以计算弹性时间。

3.2.3.4. 时间盒管理

m
3.2.3.4.1. 在限定一个相对短的时间，资源有限的情况下，定义和部署软件

co
的交付物。适合于原型法或快速应用开发法，关键功能可以在较短时间内
交付用户使用。
3.
16
3.2.3.4.2. 优点：避免项目成本超支，避免进度拖延的情况。
4@

3.3. 项目控制
05
2 67
80

3.3.1. 范围变更管理

47
 3.3.1.1. 正式的变更流程

m
3.3.1.2. 防止软件范围蔓延

co
3.3.2. 资源利用管理

3.
16
4@
05
67

3.3.2.1. 检查-盈利分析法EVA
2
80

3.3.2.1.1. 是一种能全面衡量项目进度状态、成本趋势的科学方法，其基本
要素是用货币量代替实物量来测量项目的进度。它不以项目投入资金的多
少来反映项目的进展，而是以投入资金已经转化为项目成果的量来衡量，
是一种完整和有效的项目监控方法。

48
 3.3.2.1.1.1. 已安排工作的预算费用（BCWS，BudgetedCostofWorkSchedul
ed），即根据批准认可的进度计划和预算到某一时点应当完成的工作所
需投入资金的累计值，它等于计划工程量与预算单价的乘积之和。

3.3.2.1.1.2. 完成工作的预算费用（BCWP，BudgetedCostofWorkPerforme

m
d），即根据批准认可的预算，到某一时点已经完成的工作所需要投入资

co
金的累计值，它等于已完工程重与预算单价的乘积之和。

3.
3.3.2.1.1.3. 完成工作实际费用（ACWP，ActualCostofWorkPerformed），
16
即某一时点已完成的工作所实际花费的总金额，它等于已完工程量与实
4@

际支付单价（合同价）的乘积之和。
05

3.3.2.1.1.4. 费用偏差（CV，CostVariance），可以看出已经完成的工作是
超过预算还是低于预算。CV=BCWP-ACWP。
2 67

3.3.2.1.1.5. 进度偏差（SV，ScheduleVariance），可以看出项目当前进度
80

是提前还是滞后。
SV=BCWP-BCWS。

3.3.3. 软件开发的风险

49
 3.3.3.1. 业务风险：系统不符合用户的业务需要，不能达到用户的期望值。该
风险由项目发起人负责。

3.3.3.2. 项目风险：项目活动超出必要的财务资源限制，项目推迟完成。该风
险由项目经理负责。

3.3.4. 风险管理

m
co
3.
16
4@

3.3.4.1. 风险清单
05

3.3.4.2. 评估风险
2 67

3.3.4.3. 管理风险
80

3.3.4.4. 监控风险

3.3.4.5. 评估风险管理流程

3.4. 项目关闭

50
 3.4.1. 实施后评审

4. 业务使用系统的开发SDLC

m
co
3.
16
4@

4.1. 划分生命周期进行检查和评价的好处
05

4.2. 传统的系统开发生命周期方法（SDLC、瀑布模型、V型图）
2 67
80

4.2.1. 测试模型-V模型

51
 4.2.1.1. 1.用户需求<->9.验收测试

4.2.1.2. 2.功能性要求<->8系统测试

4.2.1.3. 3.架构设计<->7.集成测试

4.2.1.4. 4.详细设计<->6.单元测试

4.2.1.5. 5.代码

4.3. 传统的SDLC各个阶段描述

m
co
3.
16
4@
05

4.3.1. 阶段1：可行性研究
2 67
80

4.3.1.1. 初步业务需求，业务案例，技术、经济、社会可行性，备选方案，投
资回报

4.3.2. 阶段2：需求定义

52
 4.3.2.1. 用户须积极参与。功能性需求和非功能性需求。定义安全需求（CIA
，机密性、完整性、可用性），定义审计轨迹需求。确定是采购软件还是定
制开发。

4.3.3. 阶段3A：软件的选择和获取

m
co
3.
16
4@

4.3.3.1. 用户要参与软件的评估和选择过程。准备需求建议书（RFP），要考
虑供应商的财务能力，与供应商签订软件源代码第三方保全协议（Escrow）
05

。
67

4.3.3.2. 征求建议书格式
2
80

4.3.3.3. 合同应当包含一下内容

53
 4.3.3.3.1. 对合同递交物及其成本的详细描述

4.3.3.3.2. 合同递交物承诺的交付日期

4.3.3.3.3. 承诺同时交付的文档、补丁包、升级程序、新版本通告和培训

4.3.3.3.4. 如果合同递交物不包含源代码，应当考虑与供应商签署源代码第
三方保全协议

4.3.3.3.5. 软件安装与配置时，提供支持服务的有关描述

4.3.3.3.6. 用户进行接受测试的标准

m
co
4.3.3.3.7. 在正式决定购买前，提供给用户一段合理的接受测试时间

3.
4.3.3.3.8. 允许购买方根据需要对软件进行一定的修改
16
4.3.3.3.9. 维护协议
4@

4.3.3.3.10. 允许为业务连续性计划和测试工作使用软件的副本
05

4.3.3.3.11. 与到货时间相关的付款计划
67

4.3.3.3.12. 保密条款
2
80

4.3.3.3.13. 数据保护条例

4.3.4. 阶段3B：设计

54
 4.3.4.1. 系统规格说明，系统功能实现，接口设计，程序和数据库设计，安全
计划。用户过多参与不合适，但设计人员可向用户解释软件架构如何满足需
求。

4.3.4.2. 设计阶段关键

m
co
4.3.4.2.1. 开发系统流程图和实体关系图模型，以说明信息在系统中如何流
动
3.
16
4.3.4.2.2. 确定是否使用结构化的设计方法，结构化的设计方法通过一系列
4@

数据或流程图自顶向下建立各种关系。
05

4.3.4.2.3. 描述输入与输出
67

4.3.4.2.4. 确定软件的过程步骤和计算规则，以满足功能需求
2
80

4.3.4.2.5. 确定数据文件或数据库文件设计

4.3.4.2.6. 为各种类型的需求或已定义的信息标准，建立程序规格说明书

4.3.4.2.7. 制定各种类型的测试计划（单元测试、子系统测试、集成测试、
测试与其他程序接口、测试系统装载和初始化的文件、压力测试、安全测
试、备份与恢复测试））

4.3.4.2.8. 制定数据转换计划，把数据从老系统转换到新系统。建立详细的
转换计划能防止数据不兼容、资源不够用或者员工对新系统不熟悉等问题
的发生。

55
 4.3.4.3. 实体关系图

4.3.4.3.1. 描述系统数据及数据之间的交互，用于表达逻辑数据模型。

4.3.4.4. 软件基础管理

m
4.3.4.5. 设计过程的用户参与

co
4.3.4.6. 设计阶段的完成

3.
16
4.3.4.7. IT审计的介入
4@

4.3.5. 阶段4A：开发
05
2 67
80

4.3.5.1. 程序编码，调试与测试。

4.3.5.2. 开发阶段关键

56
 4.3.5.2.1. 程序编码和开发程序文档、系统文档

4.3.5.2.2. 程序调试和程序测试

4.3.5.2.3. 开发程序以旧系统转换数据到新系统中

m
co
4.3.5.2.4. 创建用户迁移计划，实现用户到新系统的顺利转移

4.3.5.2.5. 对使用新系统的用户进行培训
3.
16
4.3.5.2.6. 如果是对购买的商品化软件包进行定制开发，确定对程序代码的
4@

修改记录在案，并把修改内容准确完整地应用到供应商的原始软件代码中
去，以保证供应商将来的升级版本包含了这些已更新代码
05

4.3.5.3. 编程方法和技术
2 67

4.3.5.4. 在线编程设施（集成开发环境）
80

4.3.5.4.1. 优点

57
 4.3.5.4.1.1. 降低开发成本

4.3.5.4.1.2. 保持快速响应时间

m
co
4.3.5.4.1.3. 提供共享的程序资源

4.3.5.4.2. 缺点
3.
16
4@
05
67

4.3.5.4.2.1. 多个程序版本容易引起混淆
2

4.3.5.4.2.2. 非授权访问与更改程序代码的可能性增加，危及系统与程序
80

的完整性

4.3.5.4.2.3. 对程序代码的合法修改可能被其他人员的修改覆盖

4.3.5.5. 编程语言

4.3.5.6. 编程调试

58
 4.3.5.6.1. 逻辑路径监测

m
co
3.
16
4@

4.3.5.6.1.1. 一系列事件的报告，提供逻辑错误的线索。
05

4.3.5.6.2. 内存转储
2 67
80

4.3.5.6.2.1. 用于系统崩溃时，将内存中的数据转储保存在转储文件中，
供给有关人员进行排错分析。

4.3.5.6.3. 输出分析

59
 4.3.5.6.3.1. 通过比较实际的输出结果与预期结果检查系统的精确性。

4.3.5.7. 测试

m
co
3.
16
4@

4.3.5.7.1. 集成测试工具ITF
05
2 67
80

4.3.5.7.1.1. 测试数据输入到生产环境系统中运行，验证新系统在真实环
境下的运行状况。要做好测试数据的标识工作，避免与生产数据的混淆
。

4.3.5.8. 软件测试过程的要素

60
 4.3.5.8.1. 测试计划

m
co
3.
16
4@

4.3.5.8.1.1. 自底向上：从底层的单元测试开始
05
2 67
80

4.3.5.8.1.1.1. 无需安装驱动程序

4.3.5.8.1.1.2. 在所有程序完成前就可以开始测试

4.3.5.8.1.1.3. 对关键模块的错误可以较早发现

4.3.5.8.1.2. 自顶向下：从顶层的系统测试开始

61
 4.3.5.8.1.2.1. 可以较早对主要功能和处理流程进行测试

4.3.5.8.1.2.2. 接口错误可以较早的测试出来

4.3.5.8.1.2.3. 编程人员与用户看到整个系统，增强信心

4.3.5.8.2. 实施测试和报告测试结果

4.3.5.8.3. 解决测试中发现的问题

4.3.5.9. 测试分类

m
co
3.
16
4@
05

4.3.5.9.1. 单元测试
2 67
80

4.3.5.9.1.1. 对程序模块内部进行测试

4.3.5.9.2. 接口测试/集成测试

62
 4.3.5.9.2.1. 测试多个模块之间的连接，验证整个系统的功能

4.3.5.9.3. 系统测试

m
co
3.
16
4@

4.3.5.9.3.1. 恢复测试
05

4.3.5.9.3.2. 安全测试
2 67

4.3.5.9.3.3. 压力测试/容量测试
80

4.3.5.9.3.4. 性能测试

4.3.5.9.4. 最终接受测试

63
 4.3.5.9.4.1. 用户接受测试UAT：用户进行验收测试，确保用户要求的功能
得到实现

4.3.5.9.4.2. 质量保证测试QAT：质量保证人员进行测试，对软件的可迁移
性、兼容性、可
维护性、错误的恢复功能进行技术性确认

4.3.5.10. 其他类型测试

m
co
3.
16
4@
05
2 67

4.3.5.10.1. α测试和β测试
80

4.3.5.10.1.1. α测试（AlphaTesting）：一个用户在开发环境下的测试，
用于评价系统的FURPS功能、可使用性、可靠性、性能、支持服务）。

64
 4.3.5.10.1.2. β测试（BetaTesting）：多个用户在实际使用环境下进行的
测试，开发者通常不在测试现场，目标是测试可支持性。

4.3.5.10.2. 模拟测试

m
4.3.5.10.2.1. 对系统的某些特定或预定义的内容进行预备性的测试。

co
4.3.5.10.3. 白盒测试

3.
16
4@
05
67

4.3.5.10.3.1. 测试软件系统的所有内部逻辑流程和路径，证实操作符合设
2

计要求。
80

4.3.5.10.4. 黑盒测试

4.3.5.10.4.1. 根据软件功能进行测试，不考虑系统内部逻辑结构和内部特
性，检查软件是
否符合功能说明。

65
 4.3.5.10.5. 功能/确认测试

4.3.5.10.5.1. 验证软件的有效性，即软件的功能和性能是否满足用户要求
。

4.3.5.10.6. 回归测试

m
co
3.
16
4@

4.3.5.10.6.1. 对测试场景中的某些内容重新进行测试，目的是为了保证最
05

近对软件做的修
67

改没有引入新的错误。
2

4.3.5.10.7. 平行测试
80

4.3.5.10.7.1. 把同一套测试数据同时输入到开发的新系统和原有系统中去
运行，对比两个
系统的输出结果，判断新系统的正确性。

66
 4.3.5.10.8. 社交性测试

4.3.5.10.8.1. 证实新系统在目标环境中运行时，不会对其他系统带来负面
影响。

4.3.6. 阶段4B：配置

m
co
3.
16
4@
05

4.3.6.1. 系统参数配置，与已有系统的接口开发与联调。
67

4.3.6.2. 角色和职责
2
80

4.3.6.3. 基于业务风险对所有变更进行分类和排序

4.3.6.4. 影响程度分析

4.3.6.5. 由业务流程所有者及IT授权和同意所有的变更

4.3.6.6. 跟踪变更的状态

4.3.6.7. 关注数据完整性

4.3.7. 阶段5：最终测试和实施

67
 4.3.7.1. UAT测试之后进行，用户培训，数据转换，系统迁移，系统切换。

4.3.7.2. 实施计划

m
co
3.
16
4@
05
67

4.3.7.2.1. 阶段一：制定所需的支持结构
2
80

4.3.7.2.1.1. 差距分析

4.3.7.2.1.2. 角色定义

4.3.7.2.2. 阶段二：建立支持功能

68
 4.3.7.2.2.1. 开发服务水平协议

4.3.7.2.2.2. 知识转移计划

m
4.3.7.2.2.3. 培训计划

co
4.3.7.3. 终端用户培训

3.
16
4.3.7.4. 转换数据
4@

4.3.7.5. 迁移细化迁移方案
05

4.3.7.6. 迁移失败后回退过程的情景
67

4.3.7.7. 在数据转换项目中要考虑的关键因素
2
80

4.3.7.7.1. 数据转换的完备性

4.3.7.7.2. 数据的完整性

4.3.7.7.3. 转换过程中的机密性

4.3.7.7.4. 数据的一致性

69
 4.3.7.7.5. 连续性

4.3.7.7.6. 转换之前，在旧的平台上对数据进行最后一次拷贝；转换之后，
与最后一次拷贝进行对比，确认一致

4.3.7.8. 系统切换技术

m
co
4.3.7.8.1. 平行切换 3.
16
4@
05
2 67

4.3.7.8.1.1. 新老系统同时运行一段时间，对新系统的运行满意之后再完
80

全切换到新系统。缺点在于实施初期必须同时运行两个系统，工作量大
；优点在于可以最小化切换风险。

4.3.7.8.2. 分段切换

70
 4.3.7.8.2.1. 用新系统的模块逐步替代老系统的对应模块，直到全部完成
。

4.3.7.8.3. 快速切换/一次性切换

4.3.7.8.3.1. 在某个具体时间点，快速从老系统切换到新系统。风险最大

m
。

co
4.3.7.9. 认证与认可

3.
16
4.3.8. 阶段6：实施后审查
4@
05
2 67
80

4.3.8.1. 评估系统的充分性，评价成本效益和投资回报，吸取经验教训，为后
续的开发项目提供改进建议。

4.3.8.2. 实施后评审的目标

71
 4.3.8.2.1. 评估系统的充分性

4.3.8.2.2. 评价项目的成本效益或投资回报

4.3.8.2.3. 针对系统存在的缺陷，提出改进建议

4.3.8.2.4. 为改进建议制定详细计划

4.3.8.2.5. 对项目过程进行评估

4.4. 软件基线管理Baseline

m
co
3.
16
4@

4.4.1. 基线设计阶段定义的一个冻结点，标志着软件开发过程的各个里程碑，
任何一个软件配置项，一旦形成文档并审核通过，就成为基线标志着一个阶段
05

的结束。如果需要修改基线，则需要通过正式的变更管理流程进行评估和审批
67

。主要用于有效管理用户需求避免软件开发范围不断蔓延而导致项目失控。
2

4.5. 编程标准
80

4.5.1. 编程标准改善了编码的质量和未来的维护能力，减小了系统开发过程中
由于人员轮换带来的返工，提高了系统开发效率，方便了维护和修改。

4.6. 与软件开发相关的风险

72
 4.6.1. 在项目内部：相关的风险是没有识别处理业务问题的正确需求或时机，
没有在规定的时间内和在成本约束的条件下管理要交付的项目

4.6.2. 和供应商之间：相关的风险是没有与供应商进行明确地需求和期望，导
致供应商没有或不能按时以预期的成本交付合格的产品

m
4.6.3. 在组织内部：相关的风险是组织中的利益相关者不能提供项目所需要的

co
输入和承诺，而且改变了原定的组织优先级和政策

3.
16
4.6.4. 和外部环境之间：相关的风险是客户、竞争对手、立法部门、政府部门
等外部实体的相关活动对项目的影响；经济条件的变化对项目造成的影响
4@

4.6.5. 和选择的技术：技术风险
05

5. 开发方法
2 67
80

73
 5.1. SDLC的缺陷

5.1.1. 不可预期的事

m
5.1.2. 对需求定义要求很高

co
5.1.3. 需要用户有足够的耐心

5.2. 敏捷开发 3.
16
4@
05
2 67
80

5.2.1. 是一种以人为核心、迭代、循序渐进的开发方法。将计划和一些指导性
任务从项目经理移交给项目成员，让项目经理主要为项目成员移除障碍，实现
团队的目标。

5.2.2. 主要特点

74
 5.2.2.1. 敏捷小组作为一个整体所有参与者都把自己看成朝向一个共同目标前
进的团队一员

5.2.2.2. 按短迭代周期工作，每次迭代称之为一次冲刺，每次只计划下一次开
发

m
5.2.2.3. 每次迭代交付一些成果并不强调需求基线管理

co
3.
5.2.2.4. 关注业务优先级按照产品所有者制定的顺序交付功能
16
5.2.2.5. 根据经常性的检查来调整开发过程
4@

5.2.3. 使用小规模，基于时间盒的小项目或迭代
05

5.2.4. 在每个迭代的末端都对项目进行重新计划
67

5.2.5. 更以来默认的认知，这些知识与那些存于项目文档的知识不同，存于人
2

脑
80

5.2.6. 至少有些敏捷方法促进配对式编程，以便于知识共享和质量检查

5.2.7. 项目经理角色已经从计划项目、分配任务和监督项目进度转为项目促进
者和协调者

5.2.8. 敏捷开发只会详细计划下一个迭代开发，不会一次性的详细计划之后所
有的开发阶段

5.2.9. 敏捷开发对于需求的适应性方法并不强调需求基线管理

75
 5.2.10. 敏捷开发的焦点是通过建立实际的功能来快速的证明一个软件和数据结
构，而不是以逐渐详细的模型和描述在早起就正式的定义软件和数据结构

5.2.11. 敏捷开发承认缺陷测试的限制，通过经常性的测试循环来验证系统功能
，以较小的时间盒成本来修正错误

5.2.12. 敏捷开发并不强调已定义和重复定义的流程而是根据经常性的调查来调
整和改变开发过程

5.3. 原型法

m
co
3.
16
5.3.1. 方法一：为设计而建模（需求定义机制），然后，基于该模型而进行体
4@

现效率、质量和维护特性的系统设计
05

5.3.2. 方法二：逐渐开发出能够运行使用第四代开发语言的系统
67

5.3.3. 优点与缺点
2
80

5.3.3.1. 优点

76
 5.3.3.1.1. 符合人们认识事物的规律，确保较好的用户满意度；

5.3.3.1.2. 开发周期短，费用相对少；由于有用户的直接参与，系统更加
贴近实际；

5.3.3.1.3. 易学易用，减少用户的培训时间；

m
co
5.3.3.1.4. 应变能力强。

5.3.3.2. 缺点
3.
16
4@
05
2 67
80

5.3.3.2.1. 经常导致原始需求之外的额外功能的增加；

5.3.3.2.2. 变更控制变得复杂；

5.3.3.2.3. 完成的系统在控制机制方面比较弱

5.3.3.2.4. 开发过程管理要求高；

5.3.3.2.5. 用户过早看到原型，误认为系统就是这个模样，易使用户失去信
心；

5.3.3.2.6. 开发人员易将原型取代系统分析；

77
 5.3.3.2.7. 缺乏规范化的文档资料。

5.3.4. 适用范围

m
5.3.4.1. 适用于：处理过程明确、简单系统；涉及面窄的小型系统

co
5.3.4.2. 不适于：大型、复杂系统，难以模拟；存在大量运算、逻辑性强的处

3.
理系统；管理基础工作不完善、处理过程不规范；大量批处理系统
16
5.3.5. 是指在获取一组基本的需求定义后，利用高级软件工具可视化的开发环
4@

境，快速地建立一个目标系统的最初版本，并把它交给用户试用、补充和修改
，再进行新的版本开发。反复进行这个过程，直到得出系统的“精确解”，即用
05

户满意为止。
67

5.4. 快速应用开发（RAD）
2
80

5.4.1. 是一种试图快速生成系统而不会牺牲质量的结构化开发方法。RAD与原型
法有同样的目标--对用户需求做出快速反应，但它范围更广。

5.4.2. 适用性

78
 5.4.2.1. 适用RAD的情况

m
co
3.
16
4@
05

5.4.2.1.1. 开发的软件相对独立，可以单独使用
67

5.4.2.1.2. 软件可利用许多现有的类库(APIs)
2
80

5.4.2.1.3. 系统操作性能(如速度)并非关键的考虑因素

5.4.2.1.4. 应用的开发可以使用高端的软件开发工具

5.4.2.1.5. 系统用户覆盖面较窄(内部使用)

5.4.2.1.6. 项目的范围和时限都受到较严格的控制

5.4.2.1.7. 系统可靠性并非关键的考虑因素

5.4.2.1.8. 系统可分解成多个独立的模块

79
 5.4.2.1.9. 所采用的技术相对成熟(已使用超过一年)

5.4.2.2. 不适用RAD的情况

m
co
5.4.2.2.1. 应用软件必须与多个现有系统协同工作

5.4.2.2.2. 几乎没有现成可用的组件
3.
16
5.4.2.2.3. 程序具有很高的操作性能指标
4@

5.4.2.2.4. 系统开发不能使用高端的软件开发工具
05

5.4.2.2.5. 系统用户覆盖面广，数量大(面向大众)
2 67

5.4.2.2.6. BAD偏离目标，变成快速但粗制滥造的开发
80

5.4.2.2.7. 系统可靠性目标要求较高

5.4.2.2.8. 系统无法模块化(无法进行多组同步开发)

5.4.2.2.9. 使用过于“前卫”的技术，因而风险过高

5.4.3. 技术

80
 5.4.3.1. 小型、良好培训的开发团队

5.4.3.2. 演化原型法

m
co
5.4.3.3. 集成工具，支持模型、原型、组件重用

5.4.3.4. 中央库存
3.
16
5.4.3.5. 交互需求和设计工作组
4@

5.4.3.6. 严格的开发时间限制
05

5.4.4. 思路
2 67
80

5.4.4.1. 概念定义阶段，定义业务功能和系统所需要支持的数据主题域，决定
系统范围

5.4.4.2. 功能设计阶段所采用的工作组，将系统数据和过程模型化，建立关键
系统组件的原型

5.4.4.3. 开发阶段完成物理数据库和应用系统的构建，建立转换系统，开发用
户帮助，部署工作计划

81
 5.4.4.4. 安装阶段包括所有最终用户测试和培训、数据转换、应用系统实施

5.5. 面向对象开发

5.5.1. 客观世界是由各种各样的对象组成的，每种对象都有各自的内部状态和

m
运动规律，不同对象之间的相互作用和联系就构成了各种不同的系统。在设计

co
和实现一个客观系统时，在满足需求的条件下，把系统设计成一些不可变的（

3.
相对固定）部分组成的最小集合（最好的设计）。这些不可变的部分就是所谓
16
的对象。
4@

5.5.2. 特点
05
2 67
80

5.5.2.1. 封装性

5.5.2.2. 继承性

5.5.2.3. 多态性

5.5.3. 优点

82
 5.5.3.1. 采用特定的软件工具，直接完成从对象客体的描述到软件结构直接的
转换

5.5.3.2. 解决了传统方法中客观世界描述工具盒软件结构不一致的问题，缩短

m
了开发周期，解决了分析到设计到软件模块结构直接多次转换映射的繁杂过

co
程

3.
5.5.3.3. 面向对象的方法中的继承机制，支持了模型和代码在一个系统中的重
16
用，大大降低了软件系统的复杂性，提高了开发效率
4@

5.5.3.4. 面向对象的封装性简化了开发过程
05

5.5.3.5. 在一般情况下的开发，类似于封装性，由于多态性的支持，可以无须
对系统进行修改，减少了错误和开发的工作量，使系统对环境变化的适应性
67

增强。
2
80

5.6. 基于组件的开发

5.6.1. 组件

83
 5.6.1.1. 过程内客户端组件（InprocessClientComponents）：浏览器

5.6.1.2. 独立客户端组件（StandaloneClientComponents）：Office

5.6.1.3. 独立服务器端组件（StandaloneServerComponents）：微软的DCOM
、CORBA、SUN的RMI

m
co
5.6.1.4. 过程内服务器组件（InprocessServerComponents）：微软的MTS、SU

3.
N的EJB 16
5.6.2. 减少开发时间
4@

5.6.3. 改善开发质量
05

5.6.4. 允许开发商更加关注业务功能
67

5.6.5. 加强模块化
2
80

5.6.6. 重用性

5.6.7. 减少开发支出成本

5.6.8. 允许在构建和购买的选择之间进行完美折中

5.6.9. 支持多用户开发环境

5.7. 基于WEB应用开发

84
 5.7.1. 组织内或不同组织间的异构代码模块的有效集成

5.7.2. 利用Web服务应用技术构建企业的基于互联网的分布式应用系统的方法
。

m
5.7.3. 特点

co
3.
16
4@
05
67

5.7.3.1. 应用的分布式
2
80

5.7.3.2. 应用到应用的交互性

5.7.3.3. 平台无关性

5.8. 软件重组

85
 5.8.1. 一个通过抽取、重用现存软件的设计与程序组件，对现有系统进行升级
的过程

5.9. 逆向工程

m
5.9.1. 指分析已有的程序，寻求比源代码更高级的抽象表现形式。

co
5.9.2. 逆向工程采取的方式

3.
16
4@
05
67

5.9.2.1. 将对象和可执行文件拆编成源代码，用它来分析程序；
2
80

5.9.2.2. 采用逆向工程作为黑盒，采用测试数据揭示它的功能。

5.9.3. 优点

86
 5.9.3.1. 能够实现快速开发并降低SDLC的时间

5.9.3.2. 能够改善代码的质量

5.9.4. 风险

m
co
5.9.4.1. 软件许可协议通常包括限制软件工程的声明

3.
16
5.9.4.2. 反编译器的功能是否满足逆向工程需要
4@

5.9.4.3. 反编译器通常是相对较新的软件工具，其功能依赖于具体计算机、操
作系统和编程语言，这些组件中的任何变化都会需要开发或购买新的反编译
05

器
67

5.9.4.4. 逆向工程过程控制；
2
80

5.9.4.5. 成本费用控制

6. 业务应用系统

87
 m
co
3.
16
4@
05
2 67
80

6.1. 电子商务

6.1.1. 电子商务模型

88
 6.1.1.1. BtoC

6.1.1.2. BtoB

m
co
6.1.1.3. CtoC

6.1.1.4. BtoG
3.
16
6.1.2. We bservice
4@
05
2 67
80

6.1.2.1. 是一个平台独立的，松耦合的，自包含的、基于可编程的web的应用
程序，可使用开放的XML标准来描述、发布、发现、协调和配置这些应用程
序，用于开发分布式的互操作的应用程序。

6.1.3. 电子商务架构

6.1.4. 电子商务风险

89
 6.1.4.1. 机密性

m
6.1.4.2. 完整性

co
6.1.4.3. 可用性

3.
16
6.1.4.4. 身份鉴别和不可否认性
4@

6.1.4.5. 选择转移到了消费者手中
05

6.1.5. 电子商务的要求
2 67
80

6.1.5.1. 构建一个业务案例

6.1.5.2. 开发一个清晰的业务目标

6.1.5.3. 围绕四个方面来构建业务案例：消费者、成本、竞争者和能力

6.1.5.4. 业务流程再造

90
 6.1.5.5. 连接遗留系统

6.1.6. 电子商务的审计和控制问题（最佳实践）

6.1.6.1. 有效的安全机制和程序，并把两者相结合为电子商务建立一个安全体
系

m
6.1.6.2. 把公共网络（Internet）和公司私有网络进行恰当分割的防火墙机制

co
6.1.6.3. 参与到电子商务中心的过程能够被唯一地和正确的鉴别

6.1.6.4. 数字签名 3.
16
4@

6.1.6.5. 管理和控制公共秘钥对和相关证书的架构包括

6.2. 电子数据交换EDI
05
2 67
80

6.2.1. 采用EDI的好处

91
 6.2.1.1. 较少的书面工作

6.2.1.2. 较少的信息交换错误

6.2.1.3. 改善了数据库到数据库，公司到公司的信息流

6.2.1.4. 没有多余的数据和重复键入

6.2.1.5. 较少的通讯延迟

6.2.1.6. 改善了的计价和支付处理

m
6.2.2. 目的

co
3.
16
4@

6.2.2.1. 在组织的不同计算机系统之间以标准的、计算机可处理的格式传输业
05

务交易数据。
67

6.2.2.2. EDI接口可以产生和发送功能性确认（也叫回执，Acknowledgement
2

），以识别和验证商业伙伴的身份，通过检查商业伙伴的主文件的传输信息
80

，验证交易的正确定。

6.2.2.3. 功能性确认是标准的EDI事务，告诉商业伙伴其电子文件已经收到。
不同类型的功能性确认提供了各个层次的细节情况，因此可以作为EDI交易的
审计轨迹。

6.2.3. 传统的EDI

92
 6.2.3.1. 通讯处理器

m
6.2.3.2. EDI接口

co
6.2.3.3. 应用系统

6.2.4. EDI的风险和控制 3.
16
4@
05
2 67
80

6.2.4.1. 交易授权的风险

6.2.4.2. 法律责任

6.2.4.3. 业务持续能力的丧失

6.2.4.4. 对电子交易未授权的访问

6.2.4.5. 在应用控制建立之前或之后对交易的删除和修改

6.2.4.6. EDI传输的遗失和重复

93
 6.2.4.7. 在第三方处理过程中EDI交易机密性的丧失和不适当的发送

6.3. 电子邮件

m
co
6.3.1. 电子邮件的安全

3.
16
4@
05

6.3.1.1. 网上钓鱼是一种电子社会工程学攻击
67

6.3.1.2. 邮件服务器应用程序配置上的漏洞可能会被用来作为损害服务器和所
2

连接的网络的工具
80

6.3.1.3. 拒绝服务攻击可以直接攻击邮件服务器，使其拒绝或阻碍合法用户正
常使用邮件服务器

6.3.1.4. 在发送者和接受者之间的邮件中的信息可能会在某些点被改变（拦截
）

6.3.1.5. 病毒和其他恶意代码可能会通过电子邮件而在组织中转播

6.3.1.6. 用户可能会通过电子邮件发送不适当的、专有的或其他的敏感信息，
从而导致法律风险

94
 6.3.2. 电子邮件安全标准

6.3.2.1. 通过建立维护和管理标准来保证邮件服务器的安全

6.3.2.2. 确保邮件服务器应用程序的使用、配置和管理符合由管理层所设定的
安全标准和指南

m
co
6.3.2.3. 实施加密技术以确保用户身份鉴别和邮件数据的安全

6.3.2.4. 签名不能被伪造
3.
16
6.3.2.5. 签名是可信的和被加密的
4@

6.3.2.6. 签名不能被重新使用，即一个文件上的签名不能被传递到另一个文件
05

上
67

6.3.2.7. 被签名的文件不能被改变，如何对文件的改变都会致使签名无效，无
2

论文件是否被加密
80

6.4. POS系统

6.4.1. 最重要的是确定是否有任何信用卡的信息存储在本地的POS系统，如果有
，则应使用强加密的加密方法。

95
 6.5. 电子银行

6.5.1. 电子银行的主要面临的是战略、经营和声誉上的风险，因为银行业务中
可靠数据流面临的威胁和操作中的风险都与这些因素有关。

6.6. 电子金融

m
co
3.
16
4@

6.6.1. 服务商在搜集用户信息并创建用户配置文件时，要考虑用户信息的机密
05

性，以及对这些信息使用的授权。
67

6.7. 电子支付系统
2
80

6.7.1. 电子现金模式

96
 6.7.1.1. 支付者在采购的时候并不需要在线（电子现金放在计算机中）

6.7.1.2. 支付者可以具有无条件的不可追溯性

6.7.2. 电子支票模式

m
co
3.
16
4@

6.7.2.1. 容易理解和实施
05

6.7.2.2. 电子签收的可用性，允许使用者在没有发行者的情况下解决争议
67

6.7.2.3. 付款人不需要在线来进行支付
2
80

6.7.3. 电子转账模式

6.7.3.1. 容易理解和实施

97
 6.7.3.2. 付款人要在线，收款人不需要在线

6.8. 集成制造系统

6.9. 电子资金转账EFT

m
co
6.9.1. EFT的控制与审计关注点

3.
16
4@
05

6.9.1.1. 银行卡的物理安全、用于生成PIN的程序
67

6.9.1.2. EFT系统的访问控制
2
80

6.9.1.3. EFT交换过程中涉及的网络

6.9.1.4. EFT系统和应用系统之间的接口

6.10. 自动提款机ATM

98
 6.10.1. ATM的审计关注点

m
co
3.
16
6.10.1.1. 识别客户身份的措施及保密性的措施
4@

6.10.1.2. 对交易的追踪处理
05

6.10.1.3. 维护例外报告，提供审计轨迹
2 67

6.10.1.4. 对ATM交易的对账
80

6.10.1.5. 加密密钥的变更管理程序

6.11. 交互式语音响应

6.12. 采购财务系统

6.13. 图像处理

6.14. 人工智能和专家系统AI

99
 6.14.1. 专家系统的潜在好处

m
co
3.
16
6.14.1.1. 在职员离开组织前获得他们的经验和知识
4@

6.14.1.2. 在特别的专业技术领域共享知识和经验
05

6.14.1.3. 促进一致的和有效的质量决策
67

6.14.1.4. 提高个人生产力和业绩
2

6.14.1.5. 使高度重复性的工作自动执行
80

6.14.1.6. 在人类专家不能到达的地方作用

6.14.2. 知识库

100
 m
6.14.2.1. 决策树

co
6.14.2.2. IF-Then规则

6.14.2.3. 语义网络 3.
16
6.14.2.4. 知识接口
4@

6.14.2.5. 数据接口
05

6.14.3. 审计师注意事项
2 67
80

6.14.3.1. 理解系统的目的和功能

6.14.3.2. 评价系统对于组织及其相关业务过程的重要性和相关的潜在风险

6.14.3.3. 评价系统与组织的政策和程序的要求是否一致

101
 6.14.3.4. 评价内置在系统中的决策逻辑，以确保专家的知识或系统中的人工
智能是可靠的准确的。审计师应当确保在开发基本的假设和模型时，使用了
适当水平的专家经验。

6.14.3.5. 评价知识库中信息的更新程序

6.14.3.6. 评价系统的安全访问，尤其是访问知识库

6.14.3.7. 评价是否建立程序保证有足够的优质资源可用于系统维护和更新

6.15. 商业智能BI

m
co
3.
16
4@
05

6.15.1. BI的一些经典领域
2 67
80

6.15.1.1. 处理的成本、效率和质量

6.15.1.2. 客户对产品与服务的满意度

6.15.1.3. 客户的盈利能力，明确产品或服务中哪一种属性可以作为客户盈利
预测指标

6.15.1.4. 员工和业务单元完成关键绩效指标

102
 6.15.1.5. 风险管理，通过确定不正常的加以和累积时间与损失的统计资料来
实施

6.15.2. 商业智能治理的关注点

m
6.15.2.1. 确定投资什么样的BI计划，对BI计划赋予什么样的优先级，如何测

co
量投资回报。

3.
6.15.2.2. 对数据的治理，包括建立标准数据定义，业务规则和测量尺度，确
16
定数据来源等等。
4@

6.15.3. 数据流结构
05
2 67
80

6.15.3.1. 表现层/桌面访问层

103
 6.15.3.2. 数据资源层

6.15.3.3. 核心数据仓库

6.15.3.4. 数据集市层

6.15.3.5. 数据运输层/质量控制层

6.15.3.6. 数据访问层

6.15.3.7. 数据准备层

m
6.15.3.8. 元数据存储层

co
6.15.3.9. 数据仓库管理层

3.
16
6.15.3.10.Internet/Intranet层
4@

6.15.4. 对商业智能的治理
05

6.16. 决策支持系统DSS
2 67
80

6.16.1. 是辅助决策者通过数据、模型和知识，以人机交互方式进行半结构化或
非结构化决策的
计算机应用系统。

6.16.2. 决策支持系统的特征

104
 6.16.2.1. 以解决半结构化、非结构化、不确定的问题为目标

6.16.2.2. 使用传统的数据访问和检索功能，结合模型和分析技术来使用

6.16.2.3. 强调灵活性和适应性

6.16.2.4. 注重效果（正确的完成任务）而不是效率（快速完成）

6.16.3. 决策支持系统面临的风险

m
co
3.
16
4@

6.16.3.1. 不存在的或不愿意的用户
05

6.16.3.2. 多个用户或多个实施者
67

6.16.3.3. 消失的用户、实施者和维护者
2
80

6.16.3.4. 不能事先详细说明目的或使用模式

6.16.3.5. 不能预测对当事人的影响

6.16.3.6. 缺乏或失去支持

6.16.3.7. 缺乏实施经验

6.16.3.8. 技术问题和成本效益问题

6.17. 客户关系管理CRM

6.18. 供应链管理

105
7. 基础设施开发与获取实务

7.1. 物理架构分析的各项阶段

m
co
3.
16
4@
05

7.1.1. 对现有架构的检查
67

7.1.2. 分析与设计
2

7.1.3. 起草初步功能要求
80

7.1.4. 供应商与产品选择

7.1.5. 功能需求的正式成文

7.1.6. 概念验证（POC）

7.2. 基础设施的规划实施

106
 7.2.1. 技术架构采购

7.2.2. 制定交付计划

m
7.2.3. 制定安装计划

co
7.2.4. 制定安装测试计划

3.
16
7.3. 关键成功因素
4@
05
67

7.3.1. 要吸收有一定技能的合适成员参加到工作组中来，并要全程参与项目实
2

施，以避免产生项目延误
80

7.3.2. 完成工作所需的文档应当在项目开始时就准备好

7.3.3. 决策制定者必须参与项目的各个环节，以确保所有必要的决策能快速制
定出来

7.3.4. 为作好准备，必须完成项目的第一部分工作（物理架构分析），并为所
需基础设施方案做出决策

7.4. 硬件获取

107
 7.4.1. 准备邀标书

m
co
3.
16
4@
05

7.4.1.1. 详细描述组织所需的计算机设施时中心式，分布式还是外包式
67

7.4.1.2. 信息处理需求
2
80

7.4.1.3. 系统软件

7.4.1.4. 支持需求

7.4.1.5. 适应性需求

7.4.1.6. 约束条件

7.4.1.7. 转换需求

7.4.2. 获取步骤

108
 m
7.4.2.1. 拜访其他用户或获取其他用户的推荐书

co
7.4.2.2. 提供竞争性报价

3.
16
7.4.2.3. 根据需求对报价进行分析
4@

7.4.2.4. 根据评价标准，对竞争报价进行对比分析
05

7.4.2.5. 对供应商的财务状况进行分析
67

7.4.2.6. 对供应商提供维护与支持能力的状况进行分析
2
80

7.4.2.7. 根据需求对交付的日程安排进行评审

7.4.2.8. 对软件、硬件升级能力的分析

7.4.2.9. 对安全与控制设施的分析

7.4.2.10. 针对需求的绩效评价

7.4.2.11. 针对价格的协商与评审

7.4.2.12. 对合同内部的评审（包括审计权力的条款）

109
 7.4.2.13. 形成正式的书面报告，以对每一种可选的方案进行分析，并基于成
本效益原则对选择的方案进行验证

7.5. 系统软件获取

m
co
3.
16
4@

7.5.1. 业务功能和技术需求与规范
05

7.5.2. 成本与效益
67

7.5.3. 系统的过时与失效
2

7.5.4. 与现有系统的兼容性
80

7.5.5. 安全

7.5.6. 对现有员工的要求

7.5.7. 未来增长的需求

7.5.8. 对系统与网络性能的影响

7.5.9. 培训与聘用要求

7.5.10. 开放源代码与知识产权代码的比较

110
 7.6. 系统软件实施

8. 信息系统维护实务

m
8.1. 变更管理过程

co
3.
16
4@
05
2 67

8.1.1. 程序员不能拥有写、修改和删除系统数据的权限也不能获得读取敏感信
80

息的权限。如果职责无法分离，必须遵守变更管理流程，程序员必须得到必要
的授权，防止未经授权的程序变更。

8.1.2. 部署更新

8.1.3. 文档

8.1.4. 测试变更的程序

8.1.5. 审计程序变更

8.1.6. 紧急变更

111
 8.1.6.1. 需考虑的因素：需要有特殊的登录ID，以保证人员能够暂时访问生产
环境。

8.1.7. 将变更部署回生产中

m
8.1.8. 变更的风险

co
8.2. 配置管理

3.
16
4@
05
2 67

8.2.1. 是对软件修改进行标识、组织和控制的技术，用来协调和控制整个系统
80

过程。目的是为了减少混乱，提高软件生产率。

8.2.2. 指定配置管理计划

8.2.3. 将代码和相关文档基线化

8.2.4. 分析配置控制结果并报告

8.2.5. 提供配置状态信息的报告

8.2.6. 制定发布程序

112
 8.2.7. 进行配置控制活动，如识别和记录申请

8.2.8. 更新配置状态记录数据库

8.3. 配置管理工具

8.3.1. 识别与变更申请相关的配置项并帮助进行影响评估

m
co
8.3.2. 记录授权变更影响到的配置项

8.3.3. 按照授权记录实施变更
3.
16
8.3.4. 当授权的变更发布完成，对配置项的变更进行注册
4@

8.3.5. 记录基线，这些基线与发布相关，而这些发布的变更如果执行失败则组
05

织要倒退
67

8.3.6. 为了避免人工错误和资源浪费，进行自动化发布
2
80

9. 过程改进实务

9.1. 业务流程再造和流程改变项目

113
 9.1.1. BPR应当采取的步骤

m
co
3.
9.1.1.1. 定义评价的领域
16
9.1.1.2. 开发一个项目计划
4@

9.1.1.3. 在评价的基础上获得对流程的理解/标杆管理
05

9.1.1.4. 重新设计流程并使其更有效
67

9.1.1.5. 实施并监督新的流程
2
80

9.1.1.6. 确定一个持续的改进流程

9.1.2. 业务流程再造的标杆管理

9.1.2.1. 标杆管理主要是用于改善组织的业务过程，被定义为评价组织的产品
、服务和工作流程的一个持续的、系统的过程。

114
 9.1.2.2. (1)计划：确定关键流程，如何评价

9.1.2.3. (2)研究：收集流程的基线数据确定标杆对象

9.1.2.4. (3)观察访问标杆对象，并收集资料

9.1.2.5. (4)分析总结并分析组织流程与标杆对象流程之间的差异

9.1.2.6. (5)调整调整标杆比对的结果把发现转换为行动计划

9.1.2.7. (6)改进持续改进，把每个流程与组织战略和目标改进联系在一起

m
9.1.3. 业务流程再造的审计

co
3.
16
4@

9.1.3.1. 组织与流程的变更要与整个文化和战略计划相一致
05

9.1.3.2. 使任何变更对组织成员造成的消极影响降低到最小的程度
67

9.1.3.3. 记录在BPR项目完成之后应当吸取的教训
2
80

9.1.4. 信息系统审计师的任务就是要确定组织中现存的关键控制，并评价溢出
这些控制对组织的负面影响

9.1.5. 业务流程再造最需要关注的问题：一些关键控制可能会在业务重组过程
中没有被纳入到新流程中去。

9.2. ISO9126

9.3. CMMI

10. 系统开发工具和辅助工具

115
 10.1. 代码产生器

10.2. 计算机辅助软件工程CASE

m
co
3.
16
4@
05

10.2.1. 前端
67

10.2.2. 中端
2

10.2.3. 后端
80

10.3. 第四代编程语言

116
 m
co
10.3.1. 非结构化语言

10.3.2. 环境无关性 3.
16
4@

10.3.3. 软件功能强

10.3.4. 支持程序员工作台的概念
05
67

10.3.5. 使用简单语言子集
2

10.3.6. 查询与报告生成器
80

10.3.7. 嵌入式数据库

10.3.8. 关系数据库

10.3.9. 应用程序生成器

11. 应用控制

117
 m
11.1. 输入控制/源头控制

co
3.
16
4@
05

11.1.1. 输入授权
2 67
80

11.1.1.1. 纸质签字授权

118
 11.1.1.1.1. 在一批表格和源文件上签字（提供了恰当的授权的证据）

11.1.1.2. 电子授权/在线访问控制

m
co
3.
16
11.1.1.2.1. 在线访问控制（保证只有经授权的人可以访问数据或执行敏感
的职能）
4@

11.1.1.3. 访问口令/密码
05
2 67
80

11.1.1.3.1. 唯一性口令（不能因使用其他人的数据访问口令而损害系统的
访问授权机制，个人口令要对数据变动承担责任）

11.1.1.4. 访问终端限制

119
 11.1.1.4.1. 终端或客户工作站的识别（用于限制系统只接受由特定的终端
、工作站和个人输入的信息）

11.1.1.5. 具有输入控制的表单

m
11.1.1.5.1. 源文件（指常用于记录的表单）

co
11.1.2. 批控制和批平衡

3.
16
4@
05
2 67
80

11.1.2.1. 批控制

11.1.2.1.1. 总金额：确认被系统处理的项目总金额等于处理批文件中项目
金额之和

11.1.2.1.2. 总项目数：确定在本批次中的每一个文件中的项目总数被处理
的项目总数一致

120
 11.1.2.1.3. 总文件数：确认一个批次中文件总数等于被处理的文件总数

11.1.2.1.4. 杂数总和：确认一个批次中的所有文件中的数值类字段的总和
（虽然不同类型字段加起来的值并没有实际意义）与系统计算出来的综合
相等

11.1.2.2. 批平衡

m
co
3.
16
4@

11.1.2.2.1. 批注册

11.1.2.2.2. 控制账户
05

11.1.2.2.3. 计算机一致
2 67

11.1.3. 错误报告和错误处理方法
80

11.1.3.1. 仅拒绝有错误的事务

11.1.3.2. 拒绝整批事务

11.1.3.3. 暂停输入批次

121
 11.1.3.4. 整批接收并对错误事务做标识

11.1.4. 联机系统或数据库系统中的批输入完整性

11.2. 处理程序和控制程序
（数据确认与编程控制）

m
co
3.
16
4@
05

11.2.1. 顺序检查（sequencecheck）
67

例如，发票是按照顺序编号，这一天的发票开始于12001号并结束于15045号，
2

如果在处理过程中遇到一张大于15045的发票，就可作为一张无效发票而拒绝
80

处理

11.2.1.1. 任何没按顺序，或者顺序混乱的情况将被拒绝或记录为例外情况。
比如发票的顺序编号。

122
 11.2.2. 限制检查（limitcheck）
例如，工资支票不应该超过4000美元，如果一张支票超过4000美元，该数据将
被拒绝以待进一步的极限确认或授权。

11.2.2.1. 检查数据是否超过预定义的阈值。

m
co
11.2.3. 范围检查（rangecheck）

3.
例如，产品类型的范围是从100到250，任何一个不在该范围内的编码将被视为
16
无效的产品类型而拒绝处理。
4@
05
2 67

11.2.3.1. 检查数据是否在预定义的值的范围之内。
80

11.2.4. 有效性检查（validitycheck）
例如，工资记录包含一个“婚姻”字段，期可接受的状态是"M"或"S"，输入任何
一个其他的编码将会被程序拒绝。

11.2.4.1. 按照预定义的输入标准对数据有效性进行检查。

123
 11.2.5. 合理性检查（reasonablenesscheck）
例如，在大多数情况下，一个小配件制造商通常所接受的订单不超过20个配件
，一旦任何一个订单超过20个配件，计算机程序就需要打印该记录并警告提示
该订单不合理

m
11.2.5.1. 输入的数据与预定义的合理极限或发生率相匹配

co
3.
11.2.6. 查表（Tablelook-ups）
16
例如，录入员输入一个1到10的城市代码，这个数字就与存储在计算机中的城
市预定义名称相匹配，计算机就知道“1”代表“华盛顿”，“2”代表的是“纽约”。
4@
05
2 67
80

11.2.6.1. 输入的数据必须与存储在数据库中预定义的值相符合。

11.2.7. 存在性检查（Existencecheck）
数据被正确输入并与有效的预定义的标准一致。例如，一个有效的事物代码必
须在事务代码区域输入。

124
 11.2.7.1. 数据输入要与有效的预定义的标准一致。

11.2.8. 击键校验（Keyverification）
例如，工人的代码被不同的录入人员键入两次，并比较这两者击键差距，以确
认工人输入过程中没有出现错误。

m
11.2.8.1. 不同的人员在同一个设备分别录入数据，通过计算机来比较录入人

co
员的击键顺序的差异来发现录入错误。

11.2.9. 校验数位（Checkdigit）
3.
16
例如，一个校验数位增加到一个账号后，当其使用时就可以检查其正确性。
4@
05
2 67

11.2.9.1. 在数据后面附加一个经过计算的校验值，确保原始数据不被改变或
80

替换，用于检测数据的转换。

11.2.10. 完整性检查（completenesscheck）
一个字段应当总是包含非零和非空数据，要对该字段的每一个字节都要进行检
查，以检测是否满足非零和非空的条件。

125
 11.2.10.1.检查数据是否满足非空或非零的要求，一般该字段是数据库的关键
字段，不能为空。

11.2.11. 重复检查（Duplicatecheck）
新的事务应当与以前输入过的事务进行匹配，以确保该事务没有被重新输入

m
11.2.11.1.数据要求不能重复，要保持唯一性。比如发票编号。

co
11.2.12. 逻辑关系检查（Logicalrelationship）
例如，雇员的雇佣时间要大于其生日16年。
3.
16
4@
05
67

11.2.12.1.输入的数据要符合预定的逻辑关系。
2
80

11.2.13. 处理控制

11.2.13.1.保证计算数据的完整性和准确性。保证数据在文件或数据库中的完
整和准确，只有授权的处理或程序才能对数据进行更改。

11.3. 数据文件控制

126
 m
co
3.
16
11.3.1. 处理前后的数据映像报告
4@
05
67

11.3.1.1. 应当保留实务处理前后的数据映像，便于对事务进行追踪。
2
80

11.3.2. 错误报告的维护与处理

11.3.2.1. 应当有控制程序来保证错误报告被正确的核对和纠正，提交。

11.3.3. 源文件保存期

127
 11.3.3.1. 源文件应当保持一个足够的时间期限，以确保对数据检索、重组和
验证的需要。

11.3.4. 内部和外部标签

m
co
3.
16
11.3.4.1. 应该有可移动存储介质的物理标签和文件内部的标签，前者保证数
4@

据被正确的调用，后者保证数据被正确的使用。
05

11.3.5. 版本的使用
2 67
80

11.3.5.1. 文件的使用应该确保是正确的版本，否则可能会造成数据的不准确
和不一致。

11.3.6. 数据文件安全

128
 11.3.6.1. 防止非授权人员对应用程序与数据的非授权访问。

11.3.7. 一对一检查

m
co
3.
16
11.3.7.1. 确保每一个文件都与计算机处理的文件清单相符合。
4@

11.3.8. 预录输入
05
2 67
80

11.3.8.1. 特定字段的输入内容已经被系统预先填入到相应的表单，以减少错
误。

11.3.9. 事务日志

129
 11.3.9.1. 所有的事务活动都应当由计算机记录下来，形成日志。

11.3.10. 文件更新和维护的授权

m
co
3.
16
11.3.10.1.可以保证存储的数据受到了充分的保护，保证数据是正确的和及时
4@

更新的。

11.3.11. 奇偶校验检查
05
2 67
80

11.3.11.1.用于在重要的数据传输时，通过错误检测代码和纠正代码来防止出
现错误。

11.4. 在线事务处理中的数据完整性

130
 11.4.1. 原子性Atomicity：一个事务，要么完整执行，要么就回退到原始状态

11.4.2. 一致性Consistency：数据的更新要遵守所有的完整性约束

11.4.3. 隔离性Isolation：每一个事务与其他事务相互隔离

11.4.4. 持久性Durability：对数据的任何变化都能恢复

11.5. 数据完整性测试

m
co
3.
16
4@

11.5.1. 关系完整性测试
05

11.5.2. 参照完整性测试
67

11.6. 对应用系统控制的测试方法
2
80

131
 m
co
3.
11.6.1. 快照 16
4@
05
67

11.6.1.1. 描述：记录在程序中通过逻辑路径的指定事务流
2
80

11.6.1.2. 优点：可以验证程序逻辑

11.6.1.3. 缺点：要求广博的信息系统知识

11.6.2. 映射

11.6.2.1. 描述：确定没有被测试的程序的逻辑

132
 11.6.2.2. 优点：通过识别非执行的程序代码来增加效率，可以识别潜在的漏
洞

11.6.2.3. 缺点：软件的成本

11.6.3. 追踪和标识

m
11.6.3.1. 描述：在输入时对所选择的事务做标记，并进行追踪，从而显示出

co
指令执行的轨迹。

3.
11.6.3.2. 优点：提供了一个准确的事件顺序图
16
11.6.3.3. 缺点：要求有大量的计算事件，要熟悉应用程序，要额外编程以执
4@

行追踪程序
05

11.6.4. 测试数据
2 67
80

11.6.4.1. 描述：模拟某些业务数据，将测试数据输入系统，通过系统处理来
检查系统对实际业务中同类数据处理的正确性。

11.6.4.2. 优点：可以使用实际主文件或虚构的模拟文件；
没有必要审核源代码；
可以在怀疑的基础上使用这种方法；
提供客观的审核和验证；

133
 开始时只使用在特定功能上，以减小范围；
要求最少的信息系统知识。

11.6.4.3. 缺点：很难保证恰当的程序被检查；
不包含所有的交易风险；
需要较深的业务知识；
不能测试主文件与主文件中的记录。

11.6.5. 基础用例系统评价

m
co
3.
11.6.5.1. 描述：使用已开发的测试数据集作为对程序全面测试的一部分；在
16
接受和定期确认有效性之前用来验证正确的系统操作。
4@

11.6.5.2. 优点：综合测试验证和符合性测试
05

11.6.5.3. 缺点：需要大量的维护数据集工作；要求所有参与者紧密合作。
67

11.6.6. 平行作业
2
80

11.6.6.1. 描述：现有程序与新开发程序同时进行处理，并比较其结果。

11.6.6.2. 优点：在停止旧系统之前，验证新系统

11.6.6.3. 缺点：增加了处理成本

11.6.7. 集成测试设施ITF

134
 11.6.7.1. 描述：在数据库中创建测试数据，与生产数据同时处理事务

11.6.7.2. 优点：定期测试时，不要求单独的测试程序

11.6.7.3. 缺点：需要详细的计划；
测试数据必须与生产数据隔离

m
co
11.6.8. 平行模拟

3.
16
4@
05

11.6.8.1. 描述：开发新的模拟程序，来处理实际业务和生产数据
67

11.6.8.2. 优点：不需要准备测试数据
2
80

11.6.8.3. 缺点：需要开发模拟程序

11.6.9. 事务选择程序

11.6.9.1. 描述：使用审计软件来筛选用于常规生产周期的事务输入

135
 11.6.9.2. 优点：独立于生产系统
由审计师控制
要求不能对生产系统进行修改

11.6.9.3. 缺点：开发与维护的成本

11.6.10. 嵌入式审计数据收集

m
co
11.6.10.1.描述：在生产系统中将审计软件嵌入到应用程序中，过滤和筛选所
需的事务和数据。
3.
16
11.6.10.2.优点：提供抽样和实际业务数据的统计资料。可采集：应用系统错
4@

误、系统例外情况、统计样本等。
05

11.6.10.3.缺点：开发和维护的成本高；
67

存在审计师的独立性问题。
2

11.6.11. 扩充记录
80

11.6.11.1.描述：收集受某个特定程序影响的所有数据

11.6.11.2.优点：记录可以放到一个适宜的文件中去

11.6.11.3.缺点：增加了数据存储成本、管理成本和系统的开发成本。

11.7. 联机/在线审计技术

136
 11.7.1. 系统控制审计检查文件和内嵌审计模型（SCARF/EAM）

m
11.7.1.1. 简要描述：通过在应用系统中嵌入经特别编写的审计软件，使审计

co
师能选择审计哪些内容。

3.
16
11.7.1.2. 复杂性：非常高
4@

11.7.1.3. 适用于：正常处理不能被中断时
05

11.7.2. 快照（Snapshots）
2 67
80

11.7.2.1. 简要描述：记录一个事务从输入到输出的各阶段的处理轨迹。通常
在应用系统的重要处理发生点嵌入软件，当交易通过不同处理点时，嵌入软
件可捕捉交易的前映像和后映像，通过检验前映像、后映像及其变换，评价
交易处理的真实性、准确性和完整性。

11.7.2.2. 复杂性：中

11.7.2.3. 适用于：需要审计轨迹的时候

137
 11.7.3. 审计钩（AuditHooks）

11.7.3.1. 简要描述：在应用系统中内嵌程序“钩”，像标识符那样起作用，在
错误或违规事务、流程失去控制之前，提醒信息系统审计师采取行动。

11.7.3.2. 复杂性：低

m
11.7.3.3. 适用于：只有所选的事务或流程需要被检查时

co
11.7.4. 集成测试设施（ITF）

3.
16
4@
05

11.7.4.1. 简要描述：在应用系统正常处理其业务时，用测试数据对系统进行
67

检测的一种方法。这种方法要在应用系统的文件中建立一个虚拟实体，并让
2

应用系统处理该实体的审计测试数据。
80

11.7.4.2. 复杂性：高

11.7.4.3. 适用于：采用测试数据没有益处时

11.7.5. 持续和间歇性模拟（CIS）

138
 11.7.5.1. 简要描述：在一个事务的处理运行期间，系统模拟应用程序指令的
执行。在一个事务输入时，模拟器确定该事务是否符合预定的标准，如果符
合就审计该事务，否则就等待直到下一个符合的出现。

11.7.5.2. 复杂性：中

11.7.5.3. 适用于：符合能某些标准的事务需要被检查时

11.8. 输出控制

m
co
3.
16
4@
05

11.8.1. 在安全的地方登记和存储重要表单
2 67
80

11.8.1.1. 简要描述

11.8.1.2. 复杂性

11.8.1.3. 适用于

11.8.2. 计算机生产可流通的通知、表单和签名

139
 11.8.2.1. 简要描述

11.8.2.2. 复杂性

11.8.2.3. 适用于

m
co
11.8.3. 报告分发

11.8.4. 平衡和核对
3.
16
11.8.5. 输出错误处理
4@

11.8.6. 输出报告保管
05

11.8.7. 报告接收确认
2 67
80

140