系统架构设计师学习笔记 第七章 系统计划

第七章 系统计划

7.1 项目的提出与选择

7.1.1 项目的立项目标和动机

1. 进行基础研究并获取技术
2. 进行应用研发并获得产品
   此类项目通常由企业立项和研发，通常是为了得到应用软件产品并向目标客户群进行销售从而获得利润等。可归入“应用研发”型软件
3. 提供技术服务
4. 信息技术产品的使用者

7.1.2 项目的选择和确定

系统项目的选择至少包含两种实用性目的，一个是软件开发公司在诸多的产品方向中选择适当的方向进行研究和开发，另一种是客户从诸多的产品中购买适合自己需要的产品或者选择自己需要的技术方案进行实施。

1. 选择有核心价值的产品/项目或者开发方向
   该策略在于确认什么样的系统项目是有价值的。在企业或客户经营活动中对价值链增值最大的部分，就是企业或客户的“核心业务”。
2. 评估项目风险、收益和代价
3. 评估项目的多种实施方式
   这种实施方式通常既包括了前面对项目风险、预期收益和资源开销的评估，也包含了企业对现阶段经营目标和现有资源如何合理运用的考虑。
4. 平衡的选择适合的方案
   项目开发方更多考虑的是项目风险和回报，而客户更多关心的是成本和购买后的满意度。

7.1.3 项目提出和选择的结果

系统项目提出和选择的结果，最终会以“产品/项目建议书”的方式来体现。

产品/项目建议书是一个包含多种综合内容的报告，涉及的范围通常要比GB8567-1988标准中规定的标准——“项目可行性分析报告”的内容更全面。

7.2 可行性研究与效益分析

虽然可行性研究不能指出项目最终的详细计划和方向，但是可行性研究可以在项目定义阶段用最小的代价识别出错误构思的系统，从而规避未来更多的资源投入的损失（时间、资金、人力、机会），或者因遭遇到无法逾越的技术障碍或环境障碍导致的不可避免的失败。

7.2.1 可行性研究的内容

1. 经济可行性
   主要评估项目的开发成本及项目成功后可能获得的经济收益。
2. 技术可行性
   评估对于假想的软件系统需要实现的功能和性能，以及技术能力约束。可以通过“提问——回答”的方式来进行论证，包括：
   1. 技术：现有的技术能力和IT技术的发展现状足以支持想象中的系统目标实现吗？
   2. 资源：现有的资源（掌握技术的职员、公司的技术积累、构件库、软硬件条件等）足以支持项目实施吗？技术风险在评估的哪个范围内？
   3. 目标：在目前设定的系统目标中，哪些目标会遭遇到较强的技术障碍？尤其是哪些被设定为必须实现的系统目标。
3. 法律可行性
   评估可能由系统开发引起的侵权或法律责任。
4. 执行可行性
   也称操作可行性，主要评估预期的软件系统在真实环境中能够被应用的程序和实施过程中障碍。
5. 方案的选择
   评估系统或产品开发的可选方法。

7.2.2 成本效益分析

效益分析实际上包含了“成本——效益”的分析。从内容上看，效益分析是可以包含在可行性研究的经济可行性分析中的。但效益分析的目的在于，项目开发目标的成本及可度量的项目现金收入和无形收益进行一次专门化的评估。

1. 项目可能涉及的成本

项目的成本部分，包括：

• 基础建设支出：基础设施、设备、软件等
• 一次性支出：各种费用支出
• 运营维护费用：定期消耗、租金、工资等。

2. 项目可能涉及的收益

项目的收益，通常可以分为一次性收益、非一次性收益和不可定量的收益三个部分。

a. 一次性收益

- 开支的缩减。包括改进了的系统的运行所引起的开支缩减。如资源要求的减少，运行效率的改进等。
- 价值的提升。包括由于一个应用系统的使用价值的增升所引起的收益，如资源利用的改进，管理和运行效率的改进及出错率的减少等。
- 其他。如多余设备的出售回收的收入等。

b. 非一次性收益
在整个系统生命周期内由于运行所建议系统而导致的按月的、按年的能用人民币表示的收益，包括开支的减少

c. 不可定量的收益
无法直接用人民币表示的收益。如服务的改进，由操作失误引起的风险的减少，信息掌握情况的改进等。有些不可捉摸的收益只能大概估计或进行极值估计

3. 效益分析的若干指标和进一步的分析

• 收益/投资比：软件项目实施后整个系统生命期的收益/投资比值；
• 投资/回报周期：收益的累计数开始超过支出的累计数的时间；
• 敏感性分析：分析项目中一些关键性因素如系统生命期长度、系统的工作负荷量、工作负荷的类型、处理速度、设备和软件的配置等因素发生变化或进行合理搭配时，对开支和收益的影响最灵敏的范围估计。通常在项目需要在不同因素之间取舍和调整的时候，需要参考敏感性分析的内容。

7.2.3 可行性分析报告

可行性分析报告最重要的内容应有以下几项：

• 项目背景：包括问题描述、实现环境和限制条件；
• 管理概要和建议：包括重要的研究结果、说明、建议和影响；
• 候选方案：包括候选系统的配置和最佳方案的选择标准；
• 系统描述：包括系统工作范围的简要说明和被分配系统元素的可行性；
• 经济可行性（成本/效益分析）：包括经费概算和预期的经济效益；
• 技术可行性（技术风险评价）：包括技术实力、已有工作基础和设备条件；
• 法律可行性：包括系统开发可能导致的侵权、违法和责任等；
• 用户使用可行性：包括用户单位的行政管理，工作制度和使用人员的素质；
• 其他与项目有关的问题：例如，其他方案介绍和未来可能的变化。

可行性研究报告首先由项目负责人审查（审查内容是否可靠），再上报给上级主管审阅（评估项目的地位）。

7.3 方案的制定和改进

1. 确定软件架构

1. 分析模型的架构。
2. 一些对应于系统目标的最基本、最重要的实现元素。
3. 特性和要点的解释。

2. 确定实现的各种关键性要素和实现手段

关键性的实现要素通常包括：

• 关键的用例、最主要的控制类、功能和服务的首要组织方式（例如网站首页）。
• 对象的组织模式；
• 常用和最关键的实现算法模型。

关键性的实现手段通常包括：

• 选定基础计算平台，如操作系统、数据库、Web服务器等
• 选定开发工具和开发环境

3. 归结目标到最适合的计算体系

通过同时参考系统概念模型，将前面得到的系统功能清单和系统实现的各种关键要素整理并分类，然后与现有的技术、标准的实现体系进行比较和匹配，就可以将系统概念模型定义的系统目标，进一步映射到真正可计算、可实现的系统架构上。这个过程可以理解为一种不断归纳、比较并匹配的过程。

归结系统实现要素到计算体系的时候，要点在于理解各种计算体系的大致分层和结构，比较实现要素的目标和实现手段之间的“适合程度”，而不是生搬硬套某种实现机制，或盲目追求某种“流行的”或“先进的”计算体系。

系统方案制定后，需要根据有关标准进行评价，找出不符合实际的地方，然后进行改进。

7.4 新旧系统的分析和比较

遗留系统是指任何基本上不能进行修改和演化以满足新的变化了的业务需求的信息系统。遗留系统应具有以下特点：

1. 系统虽然能完成企业中需要重要的业务管理工作，但已经不能完全满足要求。一般实现业务处理电子化及部分企业功能，极少涉及经营决策。
2. 系统在性能上已经落后，采用的技术已经过时。
3. 通常是大型的系统，已经融入企业的业务运行和决策管理机制之中，维护工作十分困难。
4. 系统没有使用现代系统工程方法进行管理和开发，限制基本上已经没有文档，很难理解。

7.4.1 遗留系统的评价方法

1. 启动评价

评价是为了获得对遗留系统的足够深度的理解，从技术、商业和企业角度对系统的理解为系统处理策略提供基础，开始评价前，需要了解以下问题：

1. 对企业来说，遗留系统是否是至关重要的。
2. 企业的商业目标是什么。
3. 演化需求是什么。
4. 所期望的系统寿命多长。一个系统的寿命由软件和硬件的服务能力决定，一旦系统硬件或支撑软件过时，系统的有效性就受到了限制。
5. 系统使用期限多久。
6. 系统的技术状态如何。
7. 企业是否愿意改变。
8. 企业是否有能力承受演化。

2. 商业价值评价

商业价值评价的目标是判断遗留系统对企业的重要性。可以在概要和详细两个级别上对遗留系统的商业价值评价。

概要级评价将为更加详细的分析提供信息。包括：

1. 咨询。向有关专家进行咨询，包括最终用户和负责业务处理的管理人员。
2. 评价问卷。问卷应该标识系统在业务处理过程中的哪些地方使用，本系统与其他系统的关系，如系统不再运行所需的代价，系统已有的缺点和存在的问题等。问题的准确性依赖于所评价的系统。
3. 进行评价

3. 外部环境评价

系统的外部技术环境指硬件、支撑软件和企业基础设施的统一体。

1. 硬件。系统硬件包括许多需要进行常规性维护的部件，这些硬件或者在一个站点，或者分布在许多站点并由网络连接。
   与商业评价类似，硬件评价也可以分为概要级评价和详细级评价。概要级评价把遗留系统作为一个整体，提供硬件质量估计。详细级评价包括识别系统中的每个部件。在这两种情况下，必须识别一系列特征，用作评价的基础。特征的选择取决于要评价的系统。系统的一些常见特征有：供应商、维护费用、失效率、年龄、功能、性能等。
   具体评价方法是：每一个部件（或整个系统）在每个特征上分配一个价值分数（取值为1~4），然后把所有分数相加，获得该部件的总分。
2. 支撑软件。系统的支撑软件环境也由许多部分组成，可包括操作系统、数据库、事务处理程序、编译器、网络软件、应用软件等。一般来说，支撑软件是依赖于某个硬件的，应用程序依赖于系统软件。在评价过程中，必须考虑这种依赖性。支撑软件的评价方法类似于硬件评价。
3. 企业基础设施。包括开发和维护系统的企业职责和运行该系统的企业职责，这些基础设施都是很难评价的，但对遗留系统的演化起关键作用，因此必须考虑以下问题：

• 企业和使用者的类型
• 开发组织的技术成熟度
• 企业的培训过程
• 系统支持人员的技术水平
• 企业是否愿意改变

4. 应用软件评价

应用软件评价也有两个级别

1. 系统级。把整个系统看做是不可分的原子，评价时不考虑系统的任何部分。
2. 部件级。关注系统的没格子系统，考虑每个子系统的特征，包括复杂性、数据、文档、外部依赖性、合法性、维护记录、大小、安全性等。

5. 分析评价结果

评价活动将产生硬件、支撑软件、企业基础设施和应用软件的特征值矩阵，这些矩阵值体现了遗留系统当前的技术因素，其加权平均值代表了系统的技术水平。计算公式如下：

$$OR=(P_1ORH+P_2ORS+P_3ORF+P_4ORA)/4$$

其中ORA是硬件的评价值，ORS是支撑软件的评价值，ORF是企业基础设施的评价值，ORA是应用软件的评价值。$P_i(1<=i<=4)$分别是它们的权系数，即第$i$个评价值对遗留系统的影响因子。

根据评价结果的分值，可以将评价结果分为四种类型

类型	处理方式
高水平低价值	集成
高水平高价值	改造
低水平高价值	继承
低水平低价值	淘汰

7.4.2 遗留系统的演化策略

1. 淘汰策略

当遗留系统的评价很低，为低水平低价值时，就说明遗留系统的技术含量很低，且具有较低的商业价值。对于这种遗留系统的演化策略为淘汰，即全面重新开发新的系统以代替遗留系统。

完全淘汰是一种极端性策略，一般是企业的业务产生了根本的变化，遗留系统基本上不再适应企业运作的需要；或者是遗留系统的维护人员、维护文档都丢失了。经过评价，发现遗留系统完全淘汰，开发全新的系统比改造旧系统从成本上更合算。

2. 继承策略

当评价的结果为低水平、高价值时，说明遗留系统的技术含量较低，可满足企业运作的功能或性能要求，但具有较高的商业价值，目前企业业务对该系统仍有很大的依赖性。对这种遗留系统的演化策略为继承。在开发新系统时，需要完全兼容遗留系统的功能模型和数据模型。为了保证业务的连续性，新老系统必须并行运行一段时间，再逐渐切换到新系统上运行。

3. 改造策略

当评价结果为高水平、高价值时，说明遗留系统的技术含量较高，本身还有较大的生命力，且具有较高的商业价值，基本上能够满足企业业务运作和决策支持的要求。这种系统可能建成的时间还很短，对这种遗留系统的演化策略为改造。

这种改造包括系统功能的增强和数据模型的改造两个方面。系统功能的增强是指在原有系统的基础上增加新的应用要求，对遗留系统本身不做改变。数据模型的改造是指将遗留系统的旧的数据模型向新的数据模型转化的过程。

4. 集成策略

当评价结果为高水平低价值时，说明遗留系统的技术含量较高，但是商业价值较低，可能只完成某个部门（或子公司）的业务管理。这种系统在各自的局部领域里工作良好，但从企业全局来看，多个这样的系统他们各自基于不同的平台，不同的数据模型，无法互联互通，数据还不一致，这就是很严重的问题了。

因此对这种遗留系统的演化策略为集成。

集成过程中，可采用由互连系统构成的系统的架构，遗留系统可作为从属系统来描述。