第7章 系统规划 - 详细梳理总结（第3部分）
🏗️ 7.3 方案的制订和改进
系统方案阶段主要解决"系统如何实现"的问题，是从概念模型到具体实现的关键转换。通过问题定义阶段的工作，已经分析并定义了系统开发目标相关的各种模型，解释了"系统目标是什么"；而系统方案阶段则要解释"系统如何实现"。系统方案制订的最主要内容，包括以下几个方面:
一， 确定软件架构
软件架构是系统实现的核心框架，与多个具体方面相关：
1) 架构相关要素：
graph TD
A[软件架构] --> B[分析模型结构]
A --> C[基本实现要素]
A --> D[特性和要点解释]
B --> E[结构化分析功能分解体系<br/>面向对象类和关系图<br/>对象行为图]
C --> F[关键用例<br/>最主要控制类<br/>对象组织模式<br/>关键实现算法模型]
D --> G[系统特性实现说明<br/>服务实现机制<br/>控制流程和实现机制]
2) 分析模型结构：
- 📊 结构化分析方法得到的功能分解体系
- 🎯 面向对象的类和"对象-关系图"、"对象-行为图"
3)基本实现要素：
- 🎯 关键用例：对应系统目标实现最重要的场景
- 🎮 最主要控制类：表示整个系统最主要的控制流程
- 🏗️ 对象组织模式：对象间的组织和交互方式
- ⚙️ 关键实现算法模型：常用和最关键的算法实现
二，确定实现的关键性要素和实现手段
1) 关键性实现要素：
| 要素类型 | 具体内容 | 重要性 |
|---|---|---|
| 关键用例 | 系统最重要的使用场景 | 决定系统核心功能 |
| 主要控制类 | 系统主要控制流程 | 决定系统架构骨架 |
| 组织方式 | 功能和服务的首要组织方式 | 如网站首页设计 |
| 对象模式 | 对象的组织模式 | 决定系统内部结构 |
| 算法模型 | 常用和关键的实现算法 | 影响系统性能及复杂度 |
2) 关键性实现手段：
graph LR
A[实现手段] --> B[基础计算平台]
A --> C[开发工具和环境]
B --> D[操作系统<br/>数据库<br/>Web服务器<br/>中间件平台]
C --> E[计算机语言<br/>构件库<br/>工具软件]
三， 归结目标到最适合的计算体系
计算体系选择的两种情况：
1) 情况一：选择标准计算体系
- 🎯 比较各种标准计算体系与预期目标的匹配程度
- ✅ 选择标准计算体系可以忽略大多数基础平台和底层技术实现问题
- 📈 大大提高系统质量、降低开发风险和成本
选择依据：
- 🏗️ 基础平台的系统实现能力支持
- 💼 公司或项目组在特定平台上的技术积累
- 🚀 技术的"先进性"或流行程度
2) 情况二：预定计算体系
- 💰 基于用户投资力度考虑
- 🔗 与用户现有IT设施保持一致性、兼容性、扩展性
- 🔧 考虑未来维护能力等因素
- ✅ 系统基础平台在项目论证阶段已经确定
标准计算体系架构分析：
1) .NET三层架构
graph TD
A[.NET三层架构] --> B[表示层]
A --> C[事务逻辑层]
A --> D[数据服务层]
B --> E[单一应用程序用户界面<br/>C/S计算模式客户端<br/>B/S模式浏览器HTML/DHTML<br/>Scripting/JavaApplet/ActiveX]
C --> F[处理表示层应用请求<br/>完成商务逻辑计算任务<br/>COM组件对象模型<br/>IIS+MTS管理和服务]
D --> G[为应用提供数据来源<br/>共享数据库连接<br/>减少连接次数<br/>提高性能和安全性]
各层详细说明：
| 层次 | 功能职责 | 技术实现 | 特点 |
|---|---|---|---|
| 表示层 | 用户界面部分 | HTML、DHTML、Scripting、JavaApplet、ActiveX | 用户交互入口 |
| 事务逻辑层 | 商务逻辑处理 | COM组件、IIS、MTS | 应用核心，COM是心脏 |
| 数据服务层 | 数据来源提供 | 数据库、连接池 | 共享连接，提高性能 |
2) J2EE架构对比
graph TD
A[J2EE架构] --> B[JSP页面]
A --> C[EJB组件]
A --> D[JDBC+数据库]
B --> E[前端表示层<br/>Web页面展示]
C --> F[业务逻辑层<br/>企业级组件]
D --> G[数据服务层<br/>数据库连接]
不同规模应用的架构变化：
| 应用规模 | 架构特点 | 实现方式 |
|---|---|---|
| 小规模网站 | 简化架构 | JSP页面直接包含所有应用逻辑脚本 |
| 企业级应用 | 完整三层 | EJB容器+对象操作语言，JDBC被平台机制屏蔽 |
四，系统目标到计算体系的匹配过程
1) 匹配过程特点：
- 🔄 双向选择和探究过程
- 📊 不断归结、比较并匹配的过程
- ⚖️ 系统概念模型与可计算实现架构的映射
2) 匹配方法：
graph LR
A[匹配过程] --> B[功能归类询问]
A --> C[技术能力研究]
B --> D[表示层?<br>业务逻辑?<br>数据服务?]
C --> E[技术积累?<br>开发经验?<br>标准构件?]
3) 双向探究的典型问题：
- 从功能到技术： 这部分功能属于表示层、业务逻辑、还是数据服务？
- 从技术到功能： 放在业务逻辑层合适吗？技术人员有开发经验吗？标准构件可用吗？
4) 匹配成功的标志：
- ✅ 系统功能清单与实现要素整理分类完成
- 🎯 与现有技术、标准实现体系比较匹配成功
- 🏗️ 系统概念模型成功映射到可计算、可实现的系统架构
五, 方案评价和改进
1) 评价标准：
- 📋 根据有关标准进行系统方案评价
- 🔍 找出不符合实际的地方
- 🔧 进行针对性改进
2) 改进原则：
- 🎯 以系统目标为导向
- ⚖️ 平衡技术先进性与实用性
- 💰 考虑成本效益比
- 🔄 保持架构的可扩展性和可维护性
🔄 7.4 新旧系统的分析和比较
随着计算机技术飞速发展，企业因业务发展需要和市场竞争压力，需要建设新的企业信息系统。如何处理和利用历史遗留的老系统（遗留系统），成为影响新系统建设成败和开发效率的关键因素。
📋 遗留系统的定义和特点
1) 学术界定义
Bennett (1995) 定义：
遗留系统是不知道如何处理但对组织又至关重要的系统。
Brodie & Stonebraker 定义：
遗留系统是指任何基本上不能进行修改和演化以满足新的变化了的业务需求的信息系统。
2) 遗留系统的四大特点
graph TD
A[遗留系统特点] --> B[功能局限性]
A --> C[技术落后性]
A --> D[业务依赖性]
A --> E[维护困难性]
B --> F[1,能完成重要业务管理工作<br>2,但不能完全满足要求<br>3,实现业务电子化和部分管理功能<br>4,很少涉及经营决策]
C --> G[1,性能落后技术过时<br>2,主机终端或小型机系统<br>3,汇编语言或早期程序设计语言<br>4,使用文件系统而非数据库]
D --> H[1,通常是大型系统<br>2,融入企业业务运行机制<br>3,融入决策管理机制<br>4,企业对其有很大依赖性]
E --> I[1,维护工作十分困难<br>2,未使用现代系统工程方法<br>3,基本没有文档<br>4,很难理解和修改]
🔍 7.4.1 遗留系统的评价方法
评价目的是获得对遗留系统更好的理解，这是遗留系统演化的基础，是任何遗留系统演化项目的起点。
1) 评价方法组成活动
graph TD
A[遗留系统评价流程] --> B[启动评价]
A --> C[商业价值评价]
A --> D[外部环境评价]
A --> E[应用软件评价]
A --> F[分析评价结果]
B --> G[确定评价必要性和范围]
C --> H[概要级评价<br/>详细级评价]
D --> I[硬件评价<br/>支撑软件评价<br/>企业基础设施评价]
E --> J[系统级评价<br/>部件级评价]
F --> K[综合分析<br/>制定演化策略]
1️⃣ 启动评价
在开始评价前，需要了解以下关键问题：
| 评价问题 | 具体内容 | 重要性 |
|---|---|---|
| 系统重要性 | 对企业来说，遗留系统是否至关重要？ | 决定是否需要演化 |
| 商业目标 | 企业的商业目标是什么？ | 产生演化需求的源泉 |
| 演化需求 | 演化需求是什么？ | 来自商业目标和评价活动 |
| 系统寿命 | 所期望的系统寿命多长？ | 由软硬件服务能力决定 |
| 使用期限 | 系统使用期限多久？ | 短期使用无需演化投入 |
| 技术状态 | 系统的技术状况如何？ | 影响维护费用和理解难度 |
| 变革意愿 | 企业是否愿意改变？ | 演化成功的关键因素 |
| 承受能力 | 企业是否有能力承受演化？ | 技术成熟度、员工素质、工具级别 |
2️⃣ 商业价值评价
评价目标： 判断遗留系统对企业的重要性
两个评价级别：
概要级评价
提供更详细分析的基础信息：
graph LR
A[概要级评价] --> B[咨询]
A --> C[评价问卷]
A --> D[进行评价]
B --> E[最终用户<br/>业务管理人员]
C --> F[系统使用位置<br/>与其他系统关系<br/>停运代价<br/>存在问题]
D --> G[系统实际使用分析<br/>发现问卷中得不到的价值]
详细级评价
⚠️希赛教育专家提示：详细级评价包括应用系统不符合业务规范的风险分析，这种分析十分费时，最好由业务分析师来 完成详细级的评价
3️⃣ 外部环境评价
系统外部技术环境包括硬件、支撑软件和企业基础设施的统一体。
硬件评价
评价对象：
- 🖥️ 主机和小型机
- 💾 磁盘驱动器、磁带
- 🖨️ 终端、打印机
- 🌐 网络硬件
评价特征和方法：
| 评价特征 | 具体内容 | 评分方法 |
|---|---|---|
| 供应商 | 硬件供应商信誉和支持能力 | 1-4分评分 |
| 维护费用 | 年度维护成本 | 成本高低评分 |
| 失效率 | 硬件故障频率 | 可靠性评分 |
| 年龄 | 硬件使用年限 | 新旧程度评分 |
| 功能 | 硬件功能完备性 | 功能评分 |
| 性能 | 硬件性能水平 | 性能评分 |
评价级别：
- 概要级： 遗留系统作为整体，提供硬件质量估计
- 详细级： 识别系统中的每个部件
支撑软件评价
评价组件：
graph TD
A[支撑软件环境] --> B[系统软件]
A --> C[开发工具]
A --> D[应用软件]
B --> E[操作系统<br/>数据库<br/>事务处理程序]
C --> F[编译器<br/>网络软件]
D --> G[各种应用软件]
重要考虑：
- 🔗 支撑软件依赖于硬件
- 📱 应用软件依赖于系统软件
- ⚖️ 评价过程中必须考虑这种依赖性
企业基础设施评价
虽然难以评价，但对遗留系统演化起关键作用：
| 评价维度 | 具体内容 | 影响分析 |
|---|---|---|
| 企业和用户类型 | 自有开发队伍 vs 外包开发 记录性工作 vs 技术性工作 | 影响演化方式选择 |
| 技术成熟度 | 现代工程方法使用 统一标准遵循 过程改进情况 | 影响演化成功率 |
| 培训过程 | 企业培训质量 | 影响演化实施效果 |
| 支持人员技术水平 | 技术水平和经验 | 决定可承受的改动规模 |
| 变革意愿 | 企业对改变的态度 | 演化成功的关键因素 |
4️⃣ 应用软件评价
两个评价级别：
系统级评价
- 🔒 把整个系统看作不可分的原子
- 🚫 不考虑系统的任何部分
- 📊 整体性评价
部件级评价
关注系统的每个子系统特征：
| 评价特征 | 具体内容 |
|---|---|
| 复杂性 | 系统复杂程度 |
| 数据 | 数据质量和结构 |
| 文档 | 文档完整性 |
| 外部依赖性 | 对外部系统的依赖 |
| 合法性 | 合规性状况 |
| 维护记录 | 历史维护情况 |
| 大小 | 系统规模 |
| 安全性 | 安全保障水平 |
5️⃣ 分析评价结果
综合评价公式：
OR = (P1×ORH + P2×ORS + P3×ORF + P4×ORA) / 4
参数说明：
- ORH： 硬件评价值
- ORS： 支撑软件评价值
- ORF： 企业基础设施评价值
- ORA： 应用软件评价值
- Pi (1≤i≤4)： 各项权重系数，表示第i个评价值对遗留系统的影响因子
评价结果应用：
- 📊 技术水平的全面评价
- ⚖️ 与商业评价进行比较
- 📋 为系统演化提供第一手资料
📝 说明： 这是第7章系统规划详细梳理总结的第3部分，主要涵盖了方案制订和新旧系统分析的详细内容。第4部分将完成遗留系统演化策略和全章总结。
