MIS的系统实施 2004.12.21
6 MIS的系统实施
6,MIS的系统实施
? 物理系统的实施
? 程序设计与调试
? 人员培训
? 数据的准备与录入
? 系统转换和评价
? 项目管理
6.1 物理系统的实施
6.1 物理系统的实施
? 计算机系统
– 按总体设计方案购置和安装计算机、网络系统
– 参考：
? 性价比
? 可扩充性
? 供应商的售后服务和技术支持
? 网络系统
– 通信设备的安装
– 电缆线的铺设
– 网络性能的调试
6.2 程序设计（ PD）
6.2 程序设计（ PD）
? 程序设计的目标：
– 可维护性 可靠性
– 可理解性（协同工作） 效率
? PD方法：
– （ Top-Down）自顶向下的模块化设计
– 结构化程序设计方法
– 面向对象的程序设计方法
– 原型式的程序开发方法：
? 将 HIPO图中类似带有普遍性的功能模块集中
? 寻找有无可用的软件工具，若没有，则开发通用模块
? 利用工具生成原型
6.3 程序和系统测试
6.3 程序和系统测试
? 测试的目标,by G.Myers
– 测试是为了发现程序中的错误而执行程序的过程；
– 好的测试方案是极可能发现迄今为止尚未发现的错误的
测试方案；
– 成功的测试是发现了至今尚未发现的错误的测试。
– 由其他人员组成测试小组完成测试（目标是暴露程序中
的错误）
– 测试决不能证明程序是正确的。
? 测试方法：黑盒（功能测试）、白盒（结构测试）
6.3 程序和系统测试
? 测试的步骤：
– 一开始就将整个系统作为一个单独的实体来测试是不
现实的（大型 MIS → 子系统 → 模块 ）。
– 模块测试
? 保证每个模块作为一个单元能正常运行，又叫单元
测试。
? 发现的往往是编码和详细设计的错误。
– 子系统测试
? 模块间的协调和通信是主要问题，着重测试模块的
接口。
6.3 程序和系统测试
– 系统测试：
? 测试设计和编码错误
? 验证系统是否能提供需求说明书中指定的功能
? 系统的动态特性是否符合预定要求。
– 子系统测试和系统测试又叫集成测试，兼有检
测和组装双重含义。
– 验收测试,将系统作为单一的实体。
? 与系统测试不同，它需要用户参与，使用实际数据，
验证系统能否满足用户需求。
– 平行运行测试：
? 新旧系统同时运行，比较处理结果。
6.3 程序和系统测试
? 测试阶段的数据流
测试
评价
调试
可靠性模型
测试计划 &测试方案：
输入 /功能 /输出
需求说明书、设计说明书、源程序清单
确定错误位置并改正
?严重错误（要求修改设计）
?一般错误（易改正、功能正常）
6.3 程序和系统测试
? 软件测试的四个步骤
– 单元测试
– 组装测试
– 确认测试
– 系统测试
– 信息系统测试
? 见 P295（图 12.6—信息系统测试）
6.3 程序和系统测试
? 单元测试
– 评价模块的五个特性：
? 模块接口、局部数据结构、重要的执行通路、出错处理通路、
影响上述各方面特性的边界条件
– 单元测试过程（人工 /计算机）
? 代码审查
人工测试
– 『 程序审查会（ code inspections）－－调解人、程序员、系统
分析 /设计人员、测试专家 』
– 人工运行－－调解人、秘书（记录错误）、测试员、其他人员
（程序员、程序语言专家、维护员、其他程序员）
? 测试软件
– 思路：开发驱动程序和存根程序。
– 驱动程序：“主程序”，接受测试数据，并传送给被测试模块
– 存根程序：代替被测试模块所调用的模块，又称“虚拟子程序”。
驱动程序
测试模块
存根程序
– 单元测试的内容
? 模块接口
? 局部数据结构
? 重要的执行路径
? 出错处理
? 边界条件
6.3 程序和系统测试
? 组装测试
– 模块组装成系统的方法
– 非渐增式测试方法：先测试模块 → 所有模块结合在一起
– 渐增式测试方法：测试好的模块 → 下一个要测试模块与
之结合进行测试 → 再下一个 ? （每次增加一个模块）
– 优劣,
测试软件的数量、进度
接口错误
错误定位
彻底性
机器时间
M1
M2 M3 M4
M5 M6 M7
M8
步骤：
1,对主控制 Mod进行测试，用存根程序代替直接附
属 Mod。
2,根据结合策略（深度优先 /广度优先），代替存根
程序（往往需要新的存根程序）
3,测试
4,回归测试（部分或全部重复以前测试） --（保证未
引进新的错误）
5,重复 2-4
渐增式结合方法：
自顶向下
Mc
Ma Mb
D1 D2 D3
族 1
族 2
族 3
步骤：
1,底层模块组合成族
（特定子功能）。
2,写驱动程序，协调
测试数据的 I/O。
3,对族进行测试。
4,去掉驱动程序，沿
软件结构自下向上移动。
子功能 →→ 更大的子功能
组合
渐增式结合方法：
自顶向下
6.3 程序和系统测试
? 确认测试
– 有效性测试
? 规定测试类型，设计测试用例，对已集成的软件进行测试
– 软件配置审查
? 软件和文档是否齐全以及分类是否有序
? 确保文档、资料的正确和完善
– 验收测试（用户参与）
? 系统测试
– 恢复测试：系统的容错能力
– 安全性测试：系统的安全机制、保密措施是否完善
– 强度测试：系统在异常情况下的承受能力
– 性能测试：系统是否满足系统分析说明书对性能的要求
– 可靠性测试：
– 安装测试：检测系统安装过程中是否有误、是否易操作等。
? 设计测试情况（略）
用户需求
系统分析
系统设计
分类编码设计
系统测试
确认测试
组装测试
单元测试
? 调试：
– 测试：尽可能多的暴露错误
– 调试：进一步诊断和改正错误
– 策略（推断错误原因）－调试的关键
? 试探法：猜测大致位置，使用调试技术
? 回溯法：确定最先发生“症状”的地方，沿程序的控制流往回
追踪源程序代码
? 对分查找法,『 已知：变量的若干关键点的正确值 』,赋值 /
输入 →→ 『 结果正确－前半部分；结果错误：后半部分 』
? 归纳法：从个别判断一般。 『 收集数据（正确的和不正确的）、
组织数据、导出假设、证明假设 』
? 演绎法：从一般原理出发，推导出结论。 『 用已有的数据排除
不正确的假设、精化余下的假设、证明余下的假设 』
– 调试技术：
? 输出存储器内容
? 打印语句（打印语句，插在源程序各个部分，以便输出关键变
量的值）
? 自动工具（语言的调试功能）
测试用例 测试用例 测试用例 测试用例
执行 出现错误 确定错误原因
回归测试
假设错误原因
设计所对应的测试用例 未找出错误原因
测试 &调试过程
系统的运行维护 2004.12.21
7.1 系统切换
7.1 系统切换
? 系统切换前的准备
– 数据准备
– 文档准备
– 用户培训
? 人员培训
– 系统整体结构和系统概貌
– 系统分析、设计思想、计算机系统的操作与使用
– 主要软件工具的使用
– 输入方式与操作方式的培训
– 可能出现的故障及故障排除
– 文档资料的分类及检索
– 数据收集、统计渠道、统计口径，注意事项，信息管
理规则等
7.1 系统切换
? 试运行及系统切换
– 系统试运行：
? 系统 初始化,输入各原始数据记录
? 记录 系统运行的数据和状况
? 核对 新旧系统输出的结果
? 评价系统的输入方式、实际运行、响应时间 T
– 基础数据准备
? 基础数据统计工作严格科学化
? 稳定可靠的数据来源
? 各类统计和数据采集报表要标准化、规范化
7.1 系统切换
– 系统切换
Old
New
切换时间
直接切换
Old
New
并行时间
并行切换
Old
New
分段时间
分段切换
7.2 系统运行与维护
7.2 系统运行与维护
? 系统运行
– 运行管理体制：
? 组织机构
? 基础数据的管理
? 运行管理制度 『 操作规程、保密、定期维护 』
? 系统运行结果分析
– 信息系统在组织中的地位（信息中心的组织）
7.2 系统运行与维护
? 系统维护
– MIS运行的日常管理
? 系统运行的日常维护 『 数据收集、整理、录入、处理结果的整
理与分发、包括硬件管理、软件管理 』
? 系统运行情况的记录
– 系统维护
? 程序的维护
? 数据文件的维护
? 代码的维护
7.3 系统运行的审计与评价
7.3 系统运行的审计与评价
? 系统评价的指标
– 经济指标：投入产出率、投资回收期、系统后备需求
的规模与费用
– 性能指标：平均无故障时间、联机响应时间、处理时
间、安全与保密、数据质量
– 管理指标：人员对 MIS的满意度、外部环境的评价、管
理制度的完备
– 系统评价报告
7.3 系统运行的审计与评价
? IS的质量（特征和指标）
– 系统对用户和业务需求的相对满意程度
– 系统开发的过程是否规范（包括文档）
– 系统功能的先进性、有效性、完备性
– 系统的性能、成本、效益综合化
– 系统运行结果的有效性或可行性
– 结果是否完整（各级管理者）
– 信息资源的利用率
– 提供信息的质量如何
– 系统的实用性
MIS中的软系统方法 2004.12.21
软系统方法
相对于硬系统而言
硬系统：
传统的系统工程方法面临挑战
20世纪 70年代中期 Checkland教授创立了软系统方法论
基于系统工程、系统分析方法
是逐次改进的一种学习和修改过程，使用系统的思想形
成 4种智力活动：感知 ---〉 判断 ---〉 比较 ---〉 决策
不导致问题的全部解决，导致情况的改善、学习系统
的建立是系统理论停滞不前的 20世纪 90年代后一个较大的更
新和转折，是一种跨学科的研究与应用 新思路
软系统方法的开发过程
1、非结构化问
题的情景描述
2、表达问题情景
3、相关系统
的根定义
4、概
念 模
型
4a、形式系统概念
4b、其他系
统思想
5,2与 4的
比较
6、可行的合乎
需要的变革
7、改善问题情景
的行动
现实世界
系统思想
软系统方法的应用前景
目前,实际应用效果有待于时间的检验
在英美等国：受到普遍重视
在我国,仅有介绍,应用与研究刚刚开始
IS开发方法组合与开发策略
没有适合各类企业通用的 IS开发方法 —不能照搬
一,各种 IS开发方法的比较
LCA的问题：
? 开发周期漫长、开发过程复杂
? 系统开发者急于求成
? 陷入矛盾中
原型法的问题：
? 对大型系统的开发无能为力
? 不适合于大量运算、逻辑性强的程序模块
? 对象工作过程不清晰，原型法构造模型有困难
? 子系统间接口不明确、文档不同意,运行维护工作困难
软系统方法问题：
刚起步，待检验
二,IS的开发策略
? 接受式的开发策略
? 直接式的开发策略
? 迭代式的开发策略
? 试验式的开发策略
IS的开发管理 — 项目的组织管理
IS的开发管理是项目管理
管理目的：保证开发质量、进度、经费按预定的目标到达
1,组织变化的类型（根据信息系统对组织变化的风险收益）
?自动化（普遍）, 利用技术有效地完成任务。
例如：民航订票系统、帐务处理系统、生产统计系统
适用于：规模小、业务流程合理、简单
?业务流程合理化,简化标准操作程序，避免瓶颈。
?业务流程重组（更有力）, 为改善成本、质量、服务，最
大化技术的利益，对流程所做的彻底再设计。
目的：降低费用、提高服务与工作质量、扩大信息技术带
来的效益
业务流程：为提供某项业务成果必须完成的一系列逻辑相
关的任务，如：开发一项新产品、完成一笔订货
BPR 目标：使顾客满意，不是只满足顾客的需求
方法：过程的观点来分析
手段：以信息技术和组织作为两个使能器 （ Enabler）
特征：根本的再思考, 彻底的再设计, 使企业效率和效益获得重大提高
改变企业过程, 提高经济效益
改变过程：删除战略上错向的过程, 职能上错位的过程, 业务运行上冗
余的过程 ----需要信息技术的支持
BPR是对传统组织形式的一种新的挑战,传统层级结构将逐步
取消, 面向流程的管理取代面向职能的管理, 组织形态扁平化
BPR分为五个主要步骤：
1,拓展业务的视野, 目标
2,确定要再造的业务流程
3,理解评价已有业务流程的执行效果
4,找出利用信息技术的机会
5,建立新业务流程的原型
2、项目的人员管理
? 选人
知识密集型工作
完整的选人、知人、用人、评人、育人、留人、激励人的体系
?对项目经理的要求
?对开发人员的要求
? 分配
分配指任务分配、开发时间分配、资源分配、责权利分配、
精神分配等
项目工作绩效与分配挂钩
考核项目人员的主要尺度：先看分配素质，后看分配能力、
再看实现和控制分配的能力
3、项目的组织结构
蛛网式、无边界的
开发小组的组织结构模式：
?主程序员小组制
?民主小组制
4、项目的组织环境
以人为本
为什么项目会失败？
? 项目开始时疏于评价实现的风险
? 疏于评价项目组合的综合实现风险
? 不同的项目需要不同的项目管理方法
IS的开发管理 ---IS开发的风险评价业
一、项目的风险
项目风险是正确地使用了项目管理方法后仍存在的问题
风险的后果：
?失去预计的收益
?成本高
?花费时间长
?系统性能低于估计
?系统不兼容无法使用
和风险相关的项目特征：
?规模
?经验
?结构
风险评价（调查表法）
规模风险评价
风险因子 权重
1,系统总开发工作小时 5
100---3000 低 1
3000—15000 中 2
15000---30000 中 3
大于 30000 高 4
2,估计的项目实现时间 4
小于等于 12个月 低 1
13—14个月 中 2
大于 24个月 高 3
3,除 IT部门外卷入的部门数 4
1个 低 1
2个 中 2
3个 高 3
结构风险评价
风险因子 权重
1,多少现存系统被一对一替换 5
0—25% 3
25%---50% 2
50%---100% 1
2,新系统对用户手续变化的程度？ 5
3,新系统要求用户组织结构变化的程度？ 5
4,用户的态度怎样？ 5
5,系统的上级用户单位受委托的情况 5
6,综合的 IT—用户团队建立了没有？ 5
技术风险评价
风险因子 权重
1,那些硬件对用户来说是新的? 5
无 0
CPU 高 3
外设或附加存储设备 高 3
终端 高 3
小型机或微机 高 3
2,系统软件对项目组是新的吗? 5
3,用户的 IT知识如何? 5
4,项目中的用户代表的知识如何? 5
二、降低风险的一些措施
至今没有任何方法能解决所有项目的风险问题
四种工具有贡献
? 内部集成工具
?选择 IT专家领导团队
?团队经常开会
?经常规律散发项目进展通报、技术状态评估报告
?大部分项目成员曾有重要的工作关系
?项目成员参与目标和限期的决策
?争取外部技术帮助
? 外部集成工具
?选择用户作为项目经理
?建立用户指导委员会
?经常举行委员会会议
?用户管理变化控制过程
?给关键用户经常发放项目备忘录
?选择用户作为项目成员
?正式的用户说明批准过程
?为公司指导委员会准备进展报告
?用户负责教育和安装系统
?用户管理重要活动日程决策
? 正式计划工具
?关键路径、网络,PERT
?届时阶段选择
?系统说明标准
?可行性研究说明
?项目批准过程
?项目后审计过程
? 正式结果控制工具
?周期的计划与执行状态报告
?变化控制训练
?规律的阶段报告会议
?计划偏差报告
6 MIS的系统实施
6,MIS的系统实施
? 物理系统的实施
? 程序设计与调试
? 人员培训
? 数据的准备与录入
? 系统转换和评价
? 项目管理
6.1 物理系统的实施
6.1 物理系统的实施
? 计算机系统
– 按总体设计方案购置和安装计算机、网络系统
– 参考：
? 性价比
? 可扩充性
? 供应商的售后服务和技术支持
? 网络系统
– 通信设备的安装
– 电缆线的铺设
– 网络性能的调试
6.2 程序设计（ PD）
6.2 程序设计（ PD）
? 程序设计的目标：
– 可维护性 可靠性
– 可理解性（协同工作） 效率
? PD方法：
– （ Top-Down）自顶向下的模块化设计
– 结构化程序设计方法
– 面向对象的程序设计方法
– 原型式的程序开发方法：
? 将 HIPO图中类似带有普遍性的功能模块集中
? 寻找有无可用的软件工具，若没有，则开发通用模块
? 利用工具生成原型
6.3 程序和系统测试
6.3 程序和系统测试
? 测试的目标,by G.Myers
– 测试是为了发现程序中的错误而执行程序的过程；
– 好的测试方案是极可能发现迄今为止尚未发现的错误的
测试方案；
– 成功的测试是发现了至今尚未发现的错误的测试。
– 由其他人员组成测试小组完成测试（目标是暴露程序中
的错误）
– 测试决不能证明程序是正确的。
? 测试方法：黑盒（功能测试）、白盒（结构测试）
6.3 程序和系统测试
? 测试的步骤：
– 一开始就将整个系统作为一个单独的实体来测试是不
现实的（大型 MIS → 子系统 → 模块 ）。
– 模块测试
? 保证每个模块作为一个单元能正常运行，又叫单元
测试。
? 发现的往往是编码和详细设计的错误。
– 子系统测试
? 模块间的协调和通信是主要问题，着重测试模块的
接口。
6.3 程序和系统测试
– 系统测试：
? 测试设计和编码错误
? 验证系统是否能提供需求说明书中指定的功能
? 系统的动态特性是否符合预定要求。
– 子系统测试和系统测试又叫集成测试，兼有检
测和组装双重含义。
– 验收测试,将系统作为单一的实体。
? 与系统测试不同，它需要用户参与，使用实际数据，
验证系统能否满足用户需求。
– 平行运行测试：
? 新旧系统同时运行，比较处理结果。
6.3 程序和系统测试
? 测试阶段的数据流
测试
评价
调试
可靠性模型
测试计划 &测试方案：
输入 /功能 /输出
需求说明书、设计说明书、源程序清单
确定错误位置并改正
?严重错误（要求修改设计）
?一般错误（易改正、功能正常）
6.3 程序和系统测试
? 软件测试的四个步骤
– 单元测试
– 组装测试
– 确认测试
– 系统测试
– 信息系统测试
? 见 P295（图 12.6—信息系统测试）
6.3 程序和系统测试
? 单元测试
– 评价模块的五个特性：
? 模块接口、局部数据结构、重要的执行通路、出错处理通路、
影响上述各方面特性的边界条件
– 单元测试过程（人工 /计算机）
? 代码审查
人工测试
– 『 程序审查会（ code inspections）－－调解人、程序员、系统
分析 /设计人员、测试专家 』
– 人工运行－－调解人、秘书（记录错误）、测试员、其他人员
（程序员、程序语言专家、维护员、其他程序员）
? 测试软件
– 思路：开发驱动程序和存根程序。
– 驱动程序：“主程序”，接受测试数据，并传送给被测试模块
– 存根程序：代替被测试模块所调用的模块，又称“虚拟子程序”。
驱动程序
测试模块
存根程序
– 单元测试的内容
? 模块接口
? 局部数据结构
? 重要的执行路径
? 出错处理
? 边界条件
6.3 程序和系统测试
? 组装测试
– 模块组装成系统的方法
– 非渐增式测试方法：先测试模块 → 所有模块结合在一起
– 渐增式测试方法：测试好的模块 → 下一个要测试模块与
之结合进行测试 → 再下一个 ? （每次增加一个模块）
– 优劣,
测试软件的数量、进度
接口错误
错误定位
彻底性
机器时间
M1
M2 M3 M4
M5 M6 M7
M8
步骤：
1,对主控制 Mod进行测试，用存根程序代替直接附
属 Mod。
2,根据结合策略（深度优先 /广度优先），代替存根
程序（往往需要新的存根程序）
3,测试
4,回归测试（部分或全部重复以前测试） --（保证未
引进新的错误）
5,重复 2-4
渐增式结合方法：
自顶向下
Mc
Ma Mb
D1 D2 D3
族 1
族 2
族 3
步骤：
1,底层模块组合成族
（特定子功能）。
2,写驱动程序，协调
测试数据的 I/O。
3,对族进行测试。
4,去掉驱动程序，沿
软件结构自下向上移动。
子功能 →→ 更大的子功能
组合
渐增式结合方法：
自顶向下
6.3 程序和系统测试
? 确认测试
– 有效性测试
? 规定测试类型，设计测试用例，对已集成的软件进行测试
– 软件配置审查
? 软件和文档是否齐全以及分类是否有序
? 确保文档、资料的正确和完善
– 验收测试（用户参与）
? 系统测试
– 恢复测试：系统的容错能力
– 安全性测试：系统的安全机制、保密措施是否完善
– 强度测试：系统在异常情况下的承受能力
– 性能测试：系统是否满足系统分析说明书对性能的要求
– 可靠性测试：
– 安装测试：检测系统安装过程中是否有误、是否易操作等。
? 设计测试情况（略）
用户需求
系统分析
系统设计
分类编码设计
系统测试
确认测试
组装测试
单元测试
? 调试：
– 测试：尽可能多的暴露错误
– 调试：进一步诊断和改正错误
– 策略（推断错误原因）－调试的关键
? 试探法：猜测大致位置，使用调试技术
? 回溯法：确定最先发生“症状”的地方，沿程序的控制流往回
追踪源程序代码
? 对分查找法,『 已知：变量的若干关键点的正确值 』,赋值 /
输入 →→ 『 结果正确－前半部分；结果错误：后半部分 』
? 归纳法：从个别判断一般。 『 收集数据（正确的和不正确的）、
组织数据、导出假设、证明假设 』
? 演绎法：从一般原理出发，推导出结论。 『 用已有的数据排除
不正确的假设、精化余下的假设、证明余下的假设 』
– 调试技术：
? 输出存储器内容
? 打印语句（打印语句，插在源程序各个部分，以便输出关键变
量的值）
? 自动工具（语言的调试功能）
测试用例 测试用例 测试用例 测试用例
执行 出现错误 确定错误原因
回归测试
假设错误原因
设计所对应的测试用例 未找出错误原因
测试 &调试过程
系统的运行维护 2004.12.21
7.1 系统切换
7.1 系统切换
? 系统切换前的准备
– 数据准备
– 文档准备
– 用户培训
? 人员培训
– 系统整体结构和系统概貌
– 系统分析、设计思想、计算机系统的操作与使用
– 主要软件工具的使用
– 输入方式与操作方式的培训
– 可能出现的故障及故障排除
– 文档资料的分类及检索
– 数据收集、统计渠道、统计口径，注意事项，信息管
理规则等
7.1 系统切换
? 试运行及系统切换
– 系统试运行：
? 系统 初始化,输入各原始数据记录
? 记录 系统运行的数据和状况
? 核对 新旧系统输出的结果
? 评价系统的输入方式、实际运行、响应时间 T
– 基础数据准备
? 基础数据统计工作严格科学化
? 稳定可靠的数据来源
? 各类统计和数据采集报表要标准化、规范化
7.1 系统切换
– 系统切换
Old
New
切换时间
直接切换
Old
New
并行时间
并行切换
Old
New
分段时间
分段切换
7.2 系统运行与维护
7.2 系统运行与维护
? 系统运行
– 运行管理体制：
? 组织机构
? 基础数据的管理
? 运行管理制度 『 操作规程、保密、定期维护 』
? 系统运行结果分析
– 信息系统在组织中的地位（信息中心的组织）
7.2 系统运行与维护
? 系统维护
– MIS运行的日常管理
? 系统运行的日常维护 『 数据收集、整理、录入、处理结果的整
理与分发、包括硬件管理、软件管理 』
? 系统运行情况的记录
– 系统维护
? 程序的维护
? 数据文件的维护
? 代码的维护
7.3 系统运行的审计与评价
7.3 系统运行的审计与评价
? 系统评价的指标
– 经济指标：投入产出率、投资回收期、系统后备需求
的规模与费用
– 性能指标：平均无故障时间、联机响应时间、处理时
间、安全与保密、数据质量
– 管理指标：人员对 MIS的满意度、外部环境的评价、管
理制度的完备
– 系统评价报告
7.3 系统运行的审计与评价
? IS的质量（特征和指标）
– 系统对用户和业务需求的相对满意程度
– 系统开发的过程是否规范（包括文档）
– 系统功能的先进性、有效性、完备性
– 系统的性能、成本、效益综合化
– 系统运行结果的有效性或可行性
– 结果是否完整（各级管理者）
– 信息资源的利用率
– 提供信息的质量如何
– 系统的实用性
MIS中的软系统方法 2004.12.21
软系统方法
相对于硬系统而言
硬系统：
传统的系统工程方法面临挑战
20世纪 70年代中期 Checkland教授创立了软系统方法论
基于系统工程、系统分析方法
是逐次改进的一种学习和修改过程，使用系统的思想形
成 4种智力活动：感知 ---〉 判断 ---〉 比较 ---〉 决策
不导致问题的全部解决，导致情况的改善、学习系统
的建立是系统理论停滞不前的 20世纪 90年代后一个较大的更
新和转折，是一种跨学科的研究与应用 新思路
软系统方法的开发过程
1、非结构化问
题的情景描述
2、表达问题情景
3、相关系统
的根定义
4、概
念 模
型
4a、形式系统概念
4b、其他系
统思想
5,2与 4的
比较
6、可行的合乎
需要的变革
7、改善问题情景
的行动
现实世界
系统思想
软系统方法的应用前景
目前,实际应用效果有待于时间的检验
在英美等国：受到普遍重视
在我国,仅有介绍,应用与研究刚刚开始
IS开发方法组合与开发策略
没有适合各类企业通用的 IS开发方法 —不能照搬
一,各种 IS开发方法的比较
LCA的问题：
? 开发周期漫长、开发过程复杂
? 系统开发者急于求成
? 陷入矛盾中
原型法的问题：
? 对大型系统的开发无能为力
? 不适合于大量运算、逻辑性强的程序模块
? 对象工作过程不清晰，原型法构造模型有困难
? 子系统间接口不明确、文档不同意,运行维护工作困难
软系统方法问题：
刚起步，待检验
二,IS的开发策略
? 接受式的开发策略
? 直接式的开发策略
? 迭代式的开发策略
? 试验式的开发策略
IS的开发管理 — 项目的组织管理
IS的开发管理是项目管理
管理目的：保证开发质量、进度、经费按预定的目标到达
1,组织变化的类型（根据信息系统对组织变化的风险收益）
?自动化（普遍）, 利用技术有效地完成任务。
例如：民航订票系统、帐务处理系统、生产统计系统
适用于：规模小、业务流程合理、简单
?业务流程合理化,简化标准操作程序，避免瓶颈。
?业务流程重组（更有力）, 为改善成本、质量、服务，最
大化技术的利益，对流程所做的彻底再设计。
目的：降低费用、提高服务与工作质量、扩大信息技术带
来的效益
业务流程：为提供某项业务成果必须完成的一系列逻辑相
关的任务，如：开发一项新产品、完成一笔订货
BPR 目标：使顾客满意，不是只满足顾客的需求
方法：过程的观点来分析
手段：以信息技术和组织作为两个使能器 （ Enabler）
特征：根本的再思考, 彻底的再设计, 使企业效率和效益获得重大提高
改变企业过程, 提高经济效益
改变过程：删除战略上错向的过程, 职能上错位的过程, 业务运行上冗
余的过程 ----需要信息技术的支持
BPR是对传统组织形式的一种新的挑战,传统层级结构将逐步
取消, 面向流程的管理取代面向职能的管理, 组织形态扁平化
BPR分为五个主要步骤：
1,拓展业务的视野, 目标
2,确定要再造的业务流程
3,理解评价已有业务流程的执行效果
4,找出利用信息技术的机会
5,建立新业务流程的原型
2、项目的人员管理
? 选人
知识密集型工作
完整的选人、知人、用人、评人、育人、留人、激励人的体系
?对项目经理的要求
?对开发人员的要求
? 分配
分配指任务分配、开发时间分配、资源分配、责权利分配、
精神分配等
项目工作绩效与分配挂钩
考核项目人员的主要尺度：先看分配素质，后看分配能力、
再看实现和控制分配的能力
3、项目的组织结构
蛛网式、无边界的
开发小组的组织结构模式：
?主程序员小组制
?民主小组制
4、项目的组织环境
以人为本
为什么项目会失败？
? 项目开始时疏于评价实现的风险
? 疏于评价项目组合的综合实现风险
? 不同的项目需要不同的项目管理方法
IS的开发管理 ---IS开发的风险评价业
一、项目的风险
项目风险是正确地使用了项目管理方法后仍存在的问题
风险的后果：
?失去预计的收益
?成本高
?花费时间长
?系统性能低于估计
?系统不兼容无法使用
和风险相关的项目特征：
?规模
?经验
?结构
风险评价（调查表法）
规模风险评价
风险因子 权重
1,系统总开发工作小时 5
100---3000 低 1
3000—15000 中 2
15000---30000 中 3
大于 30000 高 4
2,估计的项目实现时间 4
小于等于 12个月 低 1
13—14个月 中 2
大于 24个月 高 3
3,除 IT部门外卷入的部门数 4
1个 低 1
2个 中 2
3个 高 3
结构风险评价
风险因子 权重
1,多少现存系统被一对一替换 5
0—25% 3
25%---50% 2
50%---100% 1
2,新系统对用户手续变化的程度？ 5
3,新系统要求用户组织结构变化的程度？ 5
4,用户的态度怎样？ 5
5,系统的上级用户单位受委托的情况 5
6,综合的 IT—用户团队建立了没有？ 5
技术风险评价
风险因子 权重
1,那些硬件对用户来说是新的? 5
无 0
CPU 高 3
外设或附加存储设备 高 3
终端 高 3
小型机或微机 高 3
2,系统软件对项目组是新的吗? 5
3,用户的 IT知识如何? 5
4,项目中的用户代表的知识如何? 5
二、降低风险的一些措施
至今没有任何方法能解决所有项目的风险问题
四种工具有贡献
? 内部集成工具
?选择 IT专家领导团队
?团队经常开会
?经常规律散发项目进展通报、技术状态评估报告
?大部分项目成员曾有重要的工作关系
?项目成员参与目标和限期的决策
?争取外部技术帮助
? 外部集成工具
?选择用户作为项目经理
?建立用户指导委员会
?经常举行委员会会议
?用户管理变化控制过程
?给关键用户经常发放项目备忘录
?选择用户作为项目成员
?正式的用户说明批准过程
?为公司指导委员会准备进展报告
?用户负责教育和安装系统
?用户管理重要活动日程决策
? 正式计划工具
?关键路径、网络,PERT
?届时阶段选择
?系统说明标准
?可行性研究说明
?项目批准过程
?项目后审计过程
? 正式结果控制工具
?周期的计划与执行状态报告
?变化控制训练
?规律的阶段报告会议
?计划偏差报告
