软件架构之系统规划

大家好，欢迎来到IT知识分享网。

第 7 章：系统规划

系统计划主要用于描述从项目提出、选择到确立的过程，包括系统项目的提出与可行性分析，系统方案的制订、评价和改进，新旧系统的分析和比较，以及现有软件、硬件和数据资源的有效利用等问题。

7.1 项目的提出与选择

组织在信息化的过程中，可能基于各种动机提出系统项目的建设，有关人员要根据这些动机，提出和确定信息系统的工作范围，确定项目立项，提出系统选择方案，给出选择结果。

7.1.1 项目的立项目标和动机

企事业单位在其自身的经营管理过程中，对于项目的立项建设可能具有多种动机，通常可归结为下列几种。

应用研发型软件通常具有一定的通用性，客户广泛，既可能是面向个人消费者的工具软件（例如 Office、杀毒软件、游戏软件等），也可能是面向特定领域或行业的工具软件（例如 SQL Server 数据库、AutoCAD 工程绘图软件、Rational Rose 这样的建模工具软件等）。

总的来说，此类组织通常会面向一个特定行业、具有相对稳定性的客户群体，通过提供一种综合性服务来获取市场价值，因此可以把此类公司看做“服务”导向的组织。

7.1.2 项目的选择和确定

系统项目的选择至少包含两种实用性目的，一个是软件开发公司在诸多的产品方向中选择适当的方向进行研究和开发，另一种是客户从诸多的产品中购买适合自己需要的产品或选择适合自己需要的技术方案进行实施。与系统项目提出的问题一样，并不存在一个统一模式进行系统项目的选择和取舍，但可以提出进行项目取舍和评估的若干原则。通过使用项目取舍和评估的原则，可以逐步排除那些不符合需求的项目定义，从而找到比较适合的项目或产品开发方向。

因此，在企业或客户经营活动中对价值链增值最大的部分，就是企业或客户的“核心业务”。针对核心业务的信息化产品或项目，通常都是具有高价值的，也可以说，所谓的 “行业信息化”的关键就是该行业中这些核心业务的信息化改造。例如：

（1）对生产制造业的企业来说，生产计划、库存控制、实现面向订单的生产就是核心业务，无论实施 ERP 还是小规模的 MIS 系统，针对这些部分的软件功能总是被客户认为是最有价值的。

（2）对于金融保险行业来说，由于保险公司的基本职责是分摊风险和补偿损失，所以一般要求保险公司有足够的分散风险的能力。因此，管理保单数据的业务系统、评估风险的定损系统等就是非常有价值的软件系统。

（3）对于教育行业来说，因为学校的核心职能是教书育人，因此与教研、教学、考试、评价等业务相关的软件系统，以及支持上述业务开展的教育资源库软件、电子图书馆软件等就是高价值的软件系统。

总之，选择软件项目，必须首先考察软件应用的行业、业务和目标，以便判明要建设的软件项目价值。

对于购买产品或技术服务的客户来说，还应该评估项目实施后对自身业务变更，组织机构和人员职责的影响，现有的业务流程和人员的 IT 技能是否能满足要求，是否需制定相关的系统维护、运行规约和规章制度等。而项目实施的实际开销，除购买产品或服务的开支外，通常还包括各种系统维护、改进、培训，招聘新职员，变更业务流程等各种应用方面的开销。以总持有成本（Total Owner Cost，TOC）来评估信息化的代价才能比较准确地得到项目的实际代价。

评估项目风险、预期收益和代价后，可筛选掉多数不符合企业要求的建议目。

需要说明的是，企业完成软件项目的方式并不单纯限制于自己组建开发团队进行软件项目或软件产品开发的策略。根据具体情况不同，还可能使用诸如转包开发业务给外部公司、直接 OEM（Original Equipment Manufacture，原始设备制造商）软件产品并进行系统集成、购买关键技术并进行“软件集成”方式的开发、完成技术方案和设计，然后寻求外部公司进行编码等各种方式。对这些项目实施方式的取舍，主要依据依然是对项目风险、收益和资源开销综合平衡的考虑。

（1）新技术可能意味着未来更多的变化从而导致风险，也意味着未来产品的使用者需要更多的学习和导入期，而采用成熟的技术则可能享受不到新技术带来的好处。

（2）不基于某种快速开发技术或平台构造的产品可能会延长项目开发时间从而导致更多的开销，但基于某种平台的产品又可能使得用户未来“绑定”在某种平台之上，减少未来的自由选择性。

（3）不考虑系统的扩展性则很可能在业务变更时，会受阻于已经实施的 IT 设施，但过多考虑系统的扩展性，软件接口通常就需要花费较大的力气进行设计，那么用户是否在当前的购买中为一些自己并不需要的特性多支付成本？尤其在软件技术高速发展的今天，当用户期望进行系统升级的时候，常常会发现原来的计算体系已经早就被开发单位淘汰和抛弃。

（4）价格低廉的产品可能具有好的质量，也可能有些功能并不那么让人满意，而最重要的是，当关注这些具有先进性、低成本及拥有众多成功应用的产品或方案的时候，项目的选择者容易失去对自己目标的关注，即这些先进技术或宣传的产品特性是否确实是自己需要的？

事实上，对性能的要求常常是充满矛盾的，任何时候都不存在一个完美无缺的方案，只存在一个对当前的项目目标相对比较适合的方案。项目的决策者必须从最终的项目目标出发，判明各种功能或性能的重要性和优先级。在抛弃明显存在问题的“差”项目后，选择项目的基本立场应该是“适合”，而不是尽可能的“好”。（实际上任何超出预期设定目标的“好”性能，通常都意味着更多的成本。）更进一步地看，“适合”的方案就是平衡考虑开发单位利益和客户满意度的方案。

系统设计师常犯的一个错误，就是用自己对技术的兴趣产生的兴奋质量，来替换客户最基本的要求质量和假想质量。而企业经营者常犯的错误，则可能是对客户提出的合理要求质量视而不见；或者走向另一个极端，不加区分地把一切未经评估的假想要求质量不断指派给软件开发团队。这些都是错误的做法。

7.1.3 项目提出和选择的结果

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

• 用户单位、项目或产品的立项背景、需求来源和目标性的介绍；
• 用户的内外部环境、组织机构、现有的 IT 设施情况等；
• 用户的业务模型和业务规划；
• 预期要建设的技术系统在用户业务中的位置和作用；
• 信息化后的用户业务模型、软件应用方式、相关的部署环境、运行规则、管理规范等；
• 为实现信息化业务模型，技术系统的产品需求定义（功能、性能、约束）和部署方式等；
• 产品或项目的技术框架；
• 项目的要点、技术难点、主要实施障碍等；
• 项目或产品的可行性研究结果；
• 项目可选择的实施方式、组织方式、沟通和协调机制等；
• 项目的资源范围和预算（人、财、物、时间等）；
• 项目的成本/收益分析；
  ……
  
• 其他项目建议书可能包含的内容，或以单独文档列举的内容可能包括：
• 项目风险及影响评估；
• 项目进度计划；
• 项目质量计划；
• 项目过渡期资金的获得方式、财务计划；
• 产品或项目的商务模式、盈利模式论述；
• 同类产品或公司的市场调查结果，以及竞争性比较；
• 企业成功案例、资质等；
• 商务条款或供应商/客户合同；
  ……
  项目建议书标志着项目立项和选择阶段性工作的完成，一旦项目建议书被批准通过，项目即可进入正式的开发准备和实施阶段。
  
  

7.2 可行性研究与效益分析

在项目计划和选择的过程中，需要完成的首要目标是对项目进行估算。项目估算的范围涉及方方面面，例如项目或产品开发的范围、投入和回报、项目风险、作用和意义等。在传统软件工程方法中，是以可行性研究的方式来组织项目的主要估算内容。

可行性研究的范围可能覆盖技术、经济、执行、环境等各种需要评估的因素，但它并不是最后的详细计划（例如：项目的时间进度及人员安排）。通常在进行可行性研究的阶段，项目的目标或产品的最终方向也是极易变化的。

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

对于那些可行性研究表明可执行的软件项目来说，可行性研究的结果也不承诺系统的收益一定很大或技术风险和资源投入就一定很低，但可行性研究的结果设立了一个“底线”，即如果做什么，风险和收益是什么样的控制范围。这些评估结果给了未来的项目评估、项目风险控制，甚至在资源剧烈变化的情况下有计划有重点地削减功能、重定义项目开发范围，提供了非常有价值的方向性指引。

7.2.1 可行性研究的内容

可行性研究的主要内容包括经济可行性、技术可行性、法律可行性、执行可行性和方案的选择 5 个部分。

（1）技术：现有的技术能力和 IT 技术的发展现状足以支持想象中的系统目标实现吗？

（2）资源：现有的资源（掌握技术的职员、公司的技术积累、构件库、软硬件条件等）足以支持项目实施吗？技术风险在评估的哪个范围内？

（3）目标：在目前设定的系统目标中，哪些目标会遭遇到较强的技术障碍？尤其是那些被设定为必须实现的系统目标。

由于在可行性研究阶段，项目的目标是比较模糊的，因此技术可行性最好与项目功能、性能和约束的定义同时进行。在可行性研究阶段，调整开发目标和选择可行的技术体系均是可用的手段，而一旦项目进入开发阶段，任何调整都意味着更多的开销。需要再次指出的是，技术可行性绝不仅仅是论证在技术上是否可实现，实际上还包含了在当前资源条件下的技术可行性。投资不足、时间不足、预设的开发目标技术难度过大、没有足够的技术积累、没有熟练的职员可用、没有足够的合作公司和外包资源积累等均是技术可行性的约束。

软件系统的技术评估者通常都只考虑技术手段是否能实现而忽视了当前的资源条件和环境，从而对技术可行性研究得出了过于乐观的结果，这种错误判断对后期的项目实施会导致灾难性的后果！加强前期的项目调研、寻求专家的咨询以及采用具有大量成功应用案例、被广泛支持的技术标准和事实标准等均有助于改善项目的技术可行性。

7.2.3 可行性分析报告

在国家标准 GB 8567-1988 中，规定了可行性分析报告的详细格式和内容。这个规范文本基本上涵盖了可行性分析需要考察的问题，可作为书写可行性研究报告的参考文档模板。不管可行性报告的形式如何，最重要的内容应当有以下几项。

• 项目背景：包括问题描述、实现环境和限制条件；
• 管理概要和建议：包括重要的研究结果、说明、建议和影响；
• 候选方案：包括候选系统的配置和最终方案的选择标准；
• 系统描述：包括系统工作范围的简要说明和被分配系统元素的可行性；
• 经济可行性（成本/效益分析）：包括经费概算和预期的经济效益；
• 技术可行性（技术风险评价）：包括技术实力、已有工作基础和设备条件；
• 法律可行性：包括系统开发可能导致的侵权，违法和责任等；
• 用户使用可行性：包括用户单位的行政管理，工作制度和使用人员的素质；
• 其他与项目有关的问题：例如，其他方案介绍和未来可能的变化。
  可行性研究报告首先由项目负责人审查（审查内容是否可靠），再上报给上级主管审阅（评估项目的地位）。从可行性研究报告中应当得出“行或不行”的决断。
  

7.3 方案的制订和改进

（1）分析模型的结构。例如，采用结构化分析方法得到的功能分解体系，或面向对象的类和“对象－关系图”、“对象－行为图”。

（2）一些对应于系统目标的最基本、最重要的实现要素。例如，关键的用例、最主要的控制类、对象组织的模式、常用和最关键的实现算法模型等。这些实现要素对应于系统目标实现最重要的场景，表示了整个系统最主要的控制流程和实现机制。

（3）特性和要点的解释。这些附加的内容解释系统的一些特性、服务等是如何实现的。

• 对象的组织模式；
• 常用和最关键的实现算法模型。关键性的实现手段通常包括：
• 选定基础计算平台，如操作系统、数据库、Web 服务器、中间件平台等；
• 选定开发工具和开发环境，如计算机语言、构件库、工具软件等。

在另一些情况下，出于各种诸如用户投资力度，与用户现有的 IT 设施保持一致性、兼容性、扩展性及未来维护的能力等因素，系统的基础平台很可能在项目的论证阶段就已经被确定，如操作系统、数据库系统、Web 服务器、开发工具或开发环境等。在这种情况下，系统的实现体系实际上已经确定。

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

（1）表示层：用户的界面部分。例如，单一应用程序的用户界面、C/S 计算模式的客户端、B/S 模式在浏览器中运行的 HTML、DHTML、Scripting、JavaApplet、ActiveX 等。

（2）事务逻辑层：负责处理表示层的应用请求，完成商务逻辑的计算任务，并将处理结果返回给用户。事务逻辑处理层是将原先置于客户端的事务逻辑分离出来，集中置于服务器部分，为所有用户共享。事务逻辑层是整个应用的核心部分，而组件对象模型 COM 则相当于其心脏。事务逻辑层通过 COM 进行事务处理，并由 IIS（Internet Information Server，Internet 信息服务器）和 MTS（Microsoft Transaction Server，微软事务处理服务器）为各种应用组件提供完善的管理。

（3）数据服务层：为应用提供数据来源。和以往的两层架构不同，数据库不再和每个活动客户保持一个连接，而是若干个客户通过应用逻辑组件共享数据库的连接，从而减少连接次数，提高数据服务器的性能和安全性。

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

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

7.4 新旧系统的分析和比较

计算机技术飞速发展，日新月异，许多企业因为业务发展的需要和市场竞争的压力，需要建设新的企业信息系统。在这种升级改造的过程中，怎么处理和利用那些历史遗留下来的老系统，成为影响新系统建设成败和开发效率的关键因素之一。通常称这些老系统为遗留系统。

（1）系统虽然能完成企业中许多重要的业务管理工作，但已经不能完全满足要求。一般实现业务处理电子化及部分企业管理功能，很少涉及经营决策。

（2）系统在性能上已经落后，采用的技术已经过时。如多采用主机/终端形式或小型机系统，软件使用汇编语言或第三代程序设计语言的早期版本开发，使用文件系统而不是数据库。

（3）通常是大型的系统，已经融入企业的业务运行和决策管理机制之中，维护工作十分困难。

（4）系统没有使用现代系统工程方法进行管理和开发，现在基本上已经没有文档，很难理解。

在企业信息系统升级改造过程中，如何处理和利用遗留系统，成为新系统建设的重要组成部分。处理恰当与否，直接关系到新系统的成败和开发效率。遗留系统的演化方式可以有很多种，根据系统的技术条件、商业价值及维护和运行系统的组织特征不同，可以采取继续维护、某种形式的重构或替代策略，或者联合使用几种策略。究竟采用哪些策略来处理遗留系统，需要根据对遗留系统的所有系统特性的评价来确定。

7.4.1 遗留系统的评价方法

（1）对企业来说，遗留系统是否是至关重要的。在评价过程中，可能会发现系统对企业的继续运作产生的影响不大。在这种情况下，就没有必要考虑系统的演化问题。

（2）企业的商业目标是什么。从商业观点来看，评估师必须理解企业的商业目标，因为商业目标产生演化需求。

（3）演化需求是什么。演化需求来自企业的商业目标和评价活动。需求必须是可见的，以便决定已存在的系统是否能满足需求。

（4）所期望的系统寿命多长。一个系统的寿命由软件和硬件的服务能力决定，一旦系统硬件或支撑软件过时，系统的有效性就受到限制。

（5）系统使用期限多久。如果系统的使用期限只是短期的，就没有必要花费成本来演化系统。相反，如果系统将在相当长的时期内支持主要业务流程，则必须进行演化。

（6）系统的技术状态如何。例如，如果应用软件的技术状况很差，则很难理解，维护费用会很高。

（7）企业是否愿意改变。企业对改变的态度是遗留系统演化成功的关键因素之一。

（8）企业是否有能力承受演化。企业的技术成熟度，员工的素质，支撑工具的级别等都是影响演化的因素。

（3）进行评价。有了问卷的基础后，必须认真分析系统是如何使用的，这往往会发现系统的价值，而这在问卷中是得不到的。详细级评价包括应用系统不符合业务规范的风险分析，这种分析十分费时，最好由业务分析师来完成详细级的评价。

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

（2）支撑软件。系统的支撑软件环境也由许多部分组成，可包括操作系统、数据库、事务处理程序、编译器、网络软件、应用软件等。一般来说，支撑软件是依赖于某个硬件的，应用软件依赖于系统软件。在评价过程中，必须考虑这种依赖性。支撑软件的评价方法类似于硬件评价，在此省略。

（3）企业基础设施。企业基础设施包括开发和维护系统的企业职责和运行该系统的企业职责（两者可能为同一个企业），这些基础设施是很难评价的，但对遗留系统的演化起关键作用。因此必须考虑以下问题。企业和使用者的类型。企业或者有自己的系统开发队伍，或者所有开发和应用管理都是请其他企业完成。系统用户或许只重复一些记录性工作，或许包括一些更有技术性的工作。

开发组织的技术成熟度。开发组织的技术成熟度包括是否使用了现代系统工程方法，是否遵循了统一的标准，是否进行了过程改进等。企业的培训过程。如果企业（包括开发方和客户方）的培训做得好，遗留系统的演化可能会更成功。

系统支持人员的技术水平。如果系统支持人员的水平和经验不够，就不要急于对系统做大的改动。企业是否愿意改变。企业对改变的态度是遗留系统演化成功的关键因素之一。企业基础设施的评价方法类似于硬件评价，在此省略。

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

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

7.4.2 遗留系统的演化策略

在图 7-4 中，把对遗留系统的评价结果分列在坐标的四个象限内。对处在不同象限的遗留系统采取不同的演化策略。

完全淘汰是一种极端性策略，一般是企业的业务产生了根本的变化，遗留系统基本上不再适应企业运作的需要；或者是遗留系统的维护人员、维护文档资料都丢失了。经过评价，发现将遗留系统完全淘汰，开发全新的系统比改造旧系统从成本上更合算。对遗留系统的完全淘汰是企业资源的根本浪费，应该善于“变废为宝”，通过对遗留系统功能的理解和借鉴，可以帮助新系统的设计，降低新系统开发的风险。

为了保证业务的连续性，新老系统必须并行运行一段时间，再逐渐切换到新系统上运行。要做到对遗留系统的继承，必须对系统进行分析，得到旧系统的功能模型和数据模型，这种分析可以部分代替或验证系统的需求分析。

如果遗留系统的维护文档不完整，而又必须解析系统的功能模型和数据模型，那将是一项十分艰巨的任务。这时可使用有关系统重构的 CASE 工具，通过分析系统的代码生成系统结构图或其他报告。

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

对这种遗留系统的演化策略为集成。在集成过程中，可采用由互连系统构成的系统的架构，遗留系统可作为从属系统来描述。在企业信息系统建设过程中，如何处理那些遗留系统，将会是越来越突出的问题，因为即使是今天看来很先进的系统在明天也会成为遗留系统。对遗留系统的处理恰当与否，直接关系到新系统的成败和开发效率。如何建立一套系统的、行之有效的方法，以期望对实际工作有所指导，已成为一个迫切的问题。在实际工程项目中，遇到处理遗留系统的问题时，要具体情况具体分析，选择最佳的演化策略。