第7章 系统规划
系统计划主要用于描述从项目提出、选择到确立的过程，包括系统项目的提出与可行性分析，系统方案的制订、评价和改进，新旧系统的分析和比较，以及现有软件、硬件和数据资源的有效利用等问题。
7.1 项目的提出与选择
组织在信息化的过程中，可能基于各种动机提出系统项目的建设，有关人员要根据这些动机，提出和确定信息系统的工作范围，确定项目立项，提出系统选择方案，给出选择结果。
7.1.1 项目的立项目标和动机
企事业单位在其自身的经营管理过程中，对于项目的立项建设可能具有多种动机，通常可归结为下列几种。
1. 进行基础研究并获取技术
此类项目通常由大学院校或企业集团的战略研究性部门提出和实施。小规模的研究组织可能仅仅是企业中的一个研发部门或从事研发工作的团队；中大规模的研究组织包括研究所或研究院这种独立建制的单位；大规模的研究性项目可类似于国家 863 计划等跨行业、跨地域协作的国家级重大项目立项。
2. 进行应用研发并获得产品
此类项目通常由企业进行立项和开发，企业立项的基本动机通常是为了得到应用软件产品并向目标客户群进行销售从而获取利润等。产品一般会基于某类特定客户群体的需求进行设计，有明确和具体的研发目标需求，有严格的时间限制、资源预算等，因此可归入 “应用研发”型软件。
应用研发型软件通常具有一定的通用性，客户广泛，既可能是面向个人消费者的工具软件（例如 Office、杀毒软件、游戏软件等），也可能是面向特定领域或行业的工具软件（例如 SQL Server 数据库、AutoCAD 工程绘图软件、Rational Rose 这样的建模工具软件等）。
3. 提供技术服务
对此类项目进行立项的企业通常能向目标客户群提供比较全面的技术服务而不是单一的软件产品。因此企业的服务范围可能包含提供技术和解决方案的咨询、利用现有产品进行系统集成和服务、面向特定客户的软件项目定制开发、对现有的软件系统进行升级和改造、提供软件应用相关的技术支持、服务和培训等服务中的一个或多个内容。
总的来说，此类组织通常会面向一个特定行业、具有相对稳定性的客户群体，通过提供一种综合性服务来获取市场价值，因此可以把此类公司看做“服务”导向的组织。
4. 信息技术产品的使用者
信息技术的使用者是最终客户。对他们来说，软件项目的立项动机既不是为了得到软件产品而进行销售，也不是为了提供技术服务，而是通过购买产品或服务来得到使用价值。例如：一个消费者购买了绘图软件是为了存储和处理个人数码相机中的照片；而一个企业通过实施 ERP（Enterprise Resource Planning，企业资源计划）可能是为了达到生产能力的控制、生产计划科学性、提高管理水平、获取新的决策能力、降低库存成本、提高资金周转率、建立面向市场订单生产方式等目标，并期望通过这些目标的实现来增强企业竞争力、获取更大的市场份额。对信息技术的使用者来说，信息技术是一种手段，同时也是一种成本。如何用最小的成本和风险获得满意的效果是客户最关心的问题。
7.1.2 项目的选择和确定
系统项目的选择至少包含两种实用性目的，一个是软件开发公司在诸多的产品方向中选择适当的方向进行研究和开发，另一种是客户从诸多的产品中购买适合自己需要的产品或选择适合自己需要的技术方案进行实施。与系统项目提出的问题一样，并不存在一个统一模式进行系统项目的选择和取舍，但可以提出进行项目取舍和评估的若干原则。通过使用项目取舍和评估的原则，可以逐步排除那些不符合需求的项目定义，从而找到比较适合的项目或产品开发方向。
1. 选择有核心价值的产品/项目或开发方向
这个策略关键在于确定什么样的系统项目是有价值的。由于立项单位所处的行业、在行业中的位置、立项目标等因素不同，对软件项目的价值判断也不同。但“有核心价值的软件项目”通常总是和企业或客户的核心业务相关的。
美国哈佛商学院的著名教授 Michael Porter 曾经在他的《竞争优势》（CompetitiveAdvantage）一书中提出了“价值链”的概念，价值链把企业运作的各种活动划分为产品设计、产品生产、产品营销和产品应用等独立领域，企业的价值链也可以进一步和上游供货商与下游买主的价值链相连，从而构成一个产业的价值链。如果以“价值链”的观点来看待软件产品或项目，软件是作为一种技术服务手段被运用到企业业务的价值链上的，通过实现价值链中的关键业务的信息化从而最终改善客户单位的企业质量，同时也使软件开发公司获得现实的经济利益。
因此，在企业或客户经营活动中对价值链增值最大的部分，就是企业或客户的“核心业务”。针对核心业务的信息化产品或项目，通常都是具有高价值的，也可以说，所谓的 “行业信息化”的关键就是该行业中这些核心业务的信息化改造。例如：
- （1）对生产制造业的企业来说，生产计划、库存控制、实现面向订单的生产就是核心业务，无论实施 ERP 还是小规模的 MIS 系统，针对这些部分的软件功能总是被客户认为是最有价值的。
- （2）对于金融保险行业来说，由于保险公司的基本职责是分摊风险和补偿损失，所以一般要求保险公司有足够的分散风险的能力。因此，管理保单数据的业务系统、评估风险的定损系统等就是非常有价值的软件系统。
- （3）对于教育行业来说，因为学校的核心职能是教书育人，因此与教研、教学、考试、评价等业务相关的软件系统，以及支持上述业务开展的教育资源库软件、电子图书馆软件等就是高价值的软件系统。
总之，选择软件项目，必须首先考察软件应用的行业、业务和目标，以便判明要建设的软件项目价值。
2. 评估项目风险、收益和代价
在判断出一个潜在的软件项目后，还应评估项目实施的风险、收益和维护付出的代价。
对于开发产品进行销售的情况，主要评估的是产品的预期收益和为完成开发投入的各种资源（包括时间、人力、资金等），项目的风险主要是技术难度、技术能力、经济能力和各种资源是否能承担、是否是企业需要优先实施的项目、是否符合行业标准和国家政策规定（例如：
在电子签章没有经过国家法律许可之前，使用电子签章替代手工操作可能是有风险的）等。
对于购买产品或技术服务的客户来说，还应该评估项目实施后对自身业务变更，组织机构和人员职责的影响，现有的业务流程和人员的 IT 技能是否能满足要求，是否需制定相关的系统维护、运行规约和规章制度等。而项目实施的实际开销，除购买产品或服务的开支外，通常还包括各种系统维护、改进、培训，招聘新职员，变更业务流程等各种应用方面的开销。
以总持有成本（Total Owner Cost，TOC）来评估信息化的代价才能比较准确地得到项目的实际代价。
评估项目风险、预期收益和代价后，可筛选掉多数不符合企业要求的建议项目。
3. 评估项目的多种实施方式
对于已经确认有价值、并且有能力开发的软件项目，则可以进一步参照企业现状考察项目的实施方式。这种实施方式通常既包括了前面对项目风险、预期收益和资源开销的评估，也包含了企业对现阶段经营目标和现有资源如何合理运用的考虑。这个过程通常由项目的负责人和企业中高层经理进行决策，决策结果决定了项目的实施优先级及具体的实施方式。
需要说明的是，企业完成软件项目的方式并不单纯限制于自己组建开发团队进行软件项目或软件产品开发的策略。根据具体情况不同，还可能使用诸如转包开发业务给外部公司、直接 OEM（Original Equipment Manufacture，原始设备制造商）软件产品并进行系统集成、购买关键技术并进行“软件集成”方式的开发、完成技术方案和设计，然后寻求外部公司进行编码等各种方式。对这些项目实施方式的取舍，主要依据依然是对项目风险、收益和资源开销综合平衡的考虑。
4. 平衡地选择适合的方案
人们在选择可行的方案时，总是希望得到高质量、低成本的产品和方案。软件开发人员通常也很愿意在产品开发中，向产品加入创造性的内容。另一方面，客户单位在面对诸多的投标方案时，会听到各种各样关于技术先进性、快速开发、产品质量稳定可靠、价格如何低廉、推荐的方案有多少成功应用等宣传。然而：
- （1）新技术可能意味着未来更多的变化从而导致风险，也意味着未来产品的使用者需要更多的学习和导入期，而采用成熟的技术则可能享受不到新技术带来的好处。
- （2）不基于某种快速开发技术或平台构造的产品可能会延长项目开发时间从而导致更多的开销，但基于某种平台的产品又可能使得用户未来“绑定”在某种平台之上，减少未来的自由选择性。
- （3）不考虑系统的扩展性则很可能在业务变更时，会受阻于已经实施的 IT 设施，但过多考虑系统的扩展性，软件接口通常就需要花费较大的力气进行设计，那么用户是否在当前的购买中为一些自己并不需要的特性多支付成本？尤其在软件技术高速发展的今天，当用户期望进行系统升级的时候，常常会发现原来的计算体系已经早就被开发单位淘汰和抛弃。
- （4）价格低廉的产品可能具有好的质量，也可能有些功能并不那么让人满意，而最重要的是，当关注这些具有先进性、低成本及拥有众多成功应用的产品或方案的时候，项目的选择者容易失去对自己目标的关注，即这些先进技术或宣传的产品特性是否确实是自己需要的？
事实上，对性能的要求常常是充满矛盾的，任何时候都不存在一个完美无缺的方案，只存在一个对当前的项目目标相对比较适合的方案。项目的决策者必须从最终的项目目标出发，判明各种功能或性能的重要性和优先级。在抛弃明显存在问题的“差”项目后，选择项目的基本立场应该是“适合”，而不是尽可能的“好”。（实际上任何超出预期设定目标的“好”
性能，通常都意味着更多的成本。）
更进一步地看，“适合”的方案就是平衡考虑开发单位利益和客户满意度的方案。
图 7-1 是 Noriaki Kano 提出的顾客质量模型图，要求质量是客户认为产品应该具备的功能或性能，实现越多客户会越满意；假想质量是客户想当然认为产品应具备的功能或性能，客户并不能正确描述自己想当然要得到的这些功能或性能需求；兴奋质量则是客户要求范围外的功能或性能（但通常是软件开发者很乐意赋予产品的技术特性），实现这些性能客户会更高兴，但不实现也不影响其购买的决策。
显然，项目开发方更多考虑的是项目风险和回报。而客户更多关心的是成本和购买后的满意度。好的方案必须平衡考虑这些因素。系统分析师应尽可能用技术手段来平衡这些彼此对立的要求，保证在项目预期投入资源可接受的范围内，尽量实现客户要求质量对应的功能和性能、发掘客户假想质量对应的功能要求并进行沟通确认，但按自身所服务企业的经营目标平衡考虑客户兴奋质量的实现策略（是努力提供兴奋质量的功能、争取忠诚的客户获得远期潜在的收益，还是削减这些功能、以便使项目的成本最小化）。
希赛教育专家提示：系统设计师常犯的一个错误，就是用自己对技术的兴趣产生的兴奋质量，来替换客户最基本的要求质量和假想质量。而企业经营者常犯的错误，则可能是对客户提出的合理要求质量视而不见；或者走向另一个极端，不加区分地把一切未经评估的假想要求质量不断指派给软件开发团队。这些都是错误的做法。
7.1.3 项目提出和选择的结果
系统项目提出和选择的结果，最终会以“产品/项目建议书”的方式来体现。典型的应用场景是：
- （1）在投标项目中，产品/项目建议书通常是乙方提交给甲方竞标方案的一部分；
- （2）企业单位在确立了要开发某类型产品后，对该产品进行多角度的评估，最终项目立项人向上级提交供决策的建议报告的主要内容就是“产品/项目建议书”。
产品/项目建议书是一个包含多种综合内容的报告，涉及的范围通常要比 GB 8567-1988标准中规定的标准——“项目可行性分析报告”的内容更全面。在项目建议书中，可能包含如下几个部分：
用户单位、项目或产品的立项背景、需求来源和目标性的介绍；
用户的内外部环境、组织机构、现有的 IT 设施情况等；
用户的业务模型和业务规划；
预期要建设的技术系统在用户业务中的位置和作用；
信息化后的用户业务模型、软件应用方式、相关的部署环境、运行规则、管理规范等；
为实现信息化业务模型，技术系统的产品需求定义（功能、性能、约束）和部署方式等；
产品或项目的技术框架；
项目的要点、技术难点、主要实施障碍等；
项目或产品的可行性研究结果；
项目可选择的实施方式、组织方式、沟通和协调机制等；
项目的资源范围和预算（人、财、物、时间等）；
项目的成本/收益分析；
……
其他项目建议书可能包含的内容，或以单独文档列举的内容可能包括：
项目风险及影响评估；
项目进度计划；
项目质量计划；
项目过渡期资金的获得方式、财务计划；
产品或项目的商务模式、盈利模式论述；
同类产品或公司的市场调查结果，以及竞争性比较；
企业成功案例、资质等；
商务条款或供应商/客户合同；
……项目建议书标志着项目立项和选择阶段性工作的完成，一旦项目建议书被批准通过，项目即可进入正式的开发准备和实施阶段。
7.2 可行性研究与效益分析
在项目计划和选择的过程中，需要完成的首要目标是对项目进行估算。项目估算的范围涉及方方面面，例如项目或产品开发的范围、投入和回报、项目风险、作用和意义等。在传统软件工程方法中，是以可行性研究的方式来组织项目的主要估算内容。
可行性研究的范围可能覆盖技术、经济、执行、环境等各种需要评估的因素，但它并不是最后的详细计划（例如：项目的时间进度及人员安排）。通常在进行可行性研究的阶段，项目的目标或产品的最终方向也是极易变化的。
但可行性研究的意义在于，虽然可行性研究不能指出项目最终的详细计划和方向，但可行性研究可以在项目定义阶段用较小的代价识别出错误构思的系统，从而规避未来更多的资源投入的损失（时间、资金、人力、机会），或者因遭遇到无法逾越的技术障碍或环境障碍导致的不可避免的失败。
对于那些可行性研究表明可执行的软件项目来说，可行性研究的结果也不承诺系统的收益一定很大或技术风险和资源投入就一定很低，但可行性研究的结果设立了一个“底线”，即如果做什么，风险和收益是什么样的控制范围。这些评估结果给了未来的项目评估、项目风险控制，甚至在资源剧烈变化的情况下有计划有重点地削减功能、重定义项目开发范围，提供了非常有价值的方向性指引
7.2.1 可行性研究的内容
可行性研究的主要内容包括经济可行性、技术可行性、法律可行性、执行可行性和方案的选择 5 个部分。
1. 经济可行性
经济可行性主要评估项目的开发成本及项目成功后可能获得的经济收益。多数项目只有开发成本能控制在企业可接受的范围内的时候，项目才有可能被批准执行。而经济收益的考虑则非常广泛，例如：项目技术开发的直接现金收入、新产品在生命周期中预期的总销售收入、技术积累、对公司业务和产品线的完善和支持、开辟新市场和利润增长点、进入预期能带来较高收益的新市场、提高客户满意度和忠诚度、打击竞争对手抢夺市场份额、获得新的信息化能力从而改善经营或管理格局等。
2. 技术可行性
技术可行性评估对于假想的软件系统需要实现的功能和性能，以及技术能力约束。技术可行性分析可通过“提问—回答”的方式来进行论证，包括：
- （1）技术：现有的技术能力和 IT 技术的发展现状足以支持想象中的系统目标实现吗？
- （2）资源：现有的资源（掌握技术的职员、公司的技术积累、构件库、软硬件条件等）
足以支持项目实施吗？技术风险在评估的哪个范围内？
- （3）目标：在目前设定的系统目标中，哪些目标会遭遇到较强的技术障碍？尤其是那些被设定为必须实现的系统目标。
由于在可行性研究阶段，项目的目标是比较模糊的，因此技术可行性最好与项目功能、性能和约束的定义同时进行。在可行性研究阶段，调整开发目标和选择可行的技术体系均是可用的手段，而一旦项目进入开发阶段，任何调整都意味着更多的开销。
需要再次指出的是，技术可行性绝不仅仅是论证在技术上是否可实现，实际上还包含了在当前资源条件下的技术可行性。
投资不足、时间不足、预设的开发目标技术难度过大、没有足够的技术积累、没有熟练的职员可用、没有足够的合作公司和外包资源积累等均是技术可行性的约束。软件系统的技术评估者通常都只考虑技术手段是否能实现而忽视了当前的资源条件和环境，从而对技术可行性研究得出了过于乐观的结果，这种错误判断对后期的项目实施会导致灾难性的后果！
加强前期的项目调研、寻求专家的咨询以及采用具有大量成功应用案例、被广泛支持的技术标准和事实标准等均有助于改善项目的技术可行性。
3. 法律可行性
法律可行性评估可能由系统开发引发的侵权或法律责任，可能包括合同的订立和条款，职责、侵权情况的设定，违约、争议的解决等方方面面的内容。法律可行性还包括国家政策和法律的限制，例如：在政府信息化的领域中使用未被认可的加密算法或未经许可在产品中使用了其他公司被保护的软件技术、构件等。
4. 执行可行性
执行可行性也称操作可行性，它主要评估预期的软件系统在真实环境中能够被应用的程度和实施过程中障碍。例如：ERP 系统建成后的数据采集和数据质量问题，或客户工作人员没有足够的 IT 技能等。这些问题虽然与软件系统本身无关，但如果不经评估，很可能会导致投入巨资建成的软件系统毫无用处。
执行可行性还需要评估对用户的各种影响，包括对现有 IT 设施的影响、对用户组织机构的影响、对现有业务流程的影响、对地点的影响、对经费开支的影响等。如果某项影响会过多改变客户的现状，需要将这些因素作进一步的讨论并和软件系统的使用者进行沟通，提出建议的解决方法。
5. 方案的选择
评估系统或产品开发的可选方法。一般来说，同样的项目，可以采用不同的方法来实现。
甚至一个大项目的若干个子系统的实现方法也不一样。如何进行系统分解、如何定义各子系统的功能、性能和界面，实现方案不唯一。可以采用折中的方法，反复比较各个方案的成本和效益，选择可行的方案。
7.2.2 成本效益分析
效益分析实际上包含了“成本—收益”的分析。从内容上来看，效益分析是可以包含在可行性研究的经济可行性分析中的。但效益分析的目的在于，对项目开发目标的成本及可度量的项目现金收入和无形收益进行一次专门化的评估。这种以经济回报为收益的评估结果，是得到企业管理、决策层批准项目实施的重要因素。
效益分析中的成本分析，将尽可能地列举所有项目涉及的直接财务支出数字，以便管理层协调和制订各种资源的支出计划。效益分析中的收益分析，将尽可能清晰地列举实施项目带来的各种直接经济收益和无形收益，以便管理层理解项目的价值和给予项目资源上的支持。
否则，一旦项目所需要的各种资源不能按计划投入，项目失败的风险将大大增加，并且除了变更项目预设的开发目标外，几乎没有可供选择的应急方案。
1. 项目可能涉及的成本项目的成本部分，通常包括：
基础建设支出：如房屋和设施，办公设备，平台软件，必需的工具软件等购置费用；
一次性支出：如研究咨询费用、调研费、管理费用、培训费、差旅费、其他一次性杂费等；
运行维护费用：如设备租金和定期维护费用、定期消耗品支出、通信费、人员工资奖金、房屋租金、公共设施维护及其他经常性的支出项目。
2. 项目可能涉及的收益
项目的收益，通常可以分为一次性收益、非一次性收益和不可定量的收益三个部分。
- （1）一次性收益开支的缩减。包括改进了的系统的运行所引起的开支缩减，如资源要求的减少，运行效率的改进，数据进入、存储和恢复技术的改进，系统性能的可监控，软件的转换和优化，数据压缩技术的采用，处理的集中化和分布化等；
价值的增升。包括由于一个应用系统的使用价值的增升所引起的收益，如资源利用的改进，管理和运行效率的改进及出错率的减少等；
其他。如从多余设备出售回收的收入等。
- （2）非一次性收益
在整个系统生命期内由于运行所建议系统而导致的按月的、按年的能用人民币表示的收益，包括开支的减少。
- （3）不可定量的收益
无法直接用人民币表示的收益，如服务的改进，由操作失误引起的风险的减少，信息掌握情况的改进，组织机构给外界形象的改善等。有些不可捉摸的收益只能大概估计或进行极值估计（按最好和最差情况估计）。
3. 效益分析的若干指标和进一步的分析
收益/投资比：软件项目实施后整个系统生命期的收益/投资比值；
投资回收周期：收益的累计数开始超过支出的累计数的时间；
敏感性分析：分析项目中的一些关键性因素如系统生命期长度、系统的工作负荷量、工作负荷的类型、处理速度、设备和软件的配置等因素发生变化或进行合理搭配时，对开支和收益的影响最灵敏的范围估计。通常当项目需要在不同因素之间取舍和调整的时候，需要参考敏感性分析的内容。
7.2.3 可行性分析报告
在国家标准 GB 8567-1988 中，规定了可行性分析报告的详细格式和内容。这个规范文本基本上涵盖了可行性分析需要考察的问题，可作为书写可行性研究报告的参考文档模板。
不管可行性报告的形式如何，最重要的内容应当有以下几项。
项目背景：包括问题描述、实现环境和限制条件；
管理概要和建议：包括重要的研究结果、说明、建议和影响；
候选方案：包括候选系统的配置和最终方案的选择标准；
系统描述：包括系统工作范围的简要说明和被分配系统元素的可行性；
经济可行性（成本/效益分析）：包括经费概算和预期的经济效益；
技术可行性（技术风险评价）：包括技术实力、已有工作基础和设备条件；
法律可行性：包括系统开发可能导致的侵权，违法和责任等；
用户使用可行性：包括用户单位的行政管理，工作制度和使用人员的素质；
其他与项目有关的问题：例如，其他方案介绍和未来可能的变化。
可行性研究报告首先由项目负责人审查（审查内容是否可靠），再上报给上级主管审阅（评估项目的地位）。从可行性研究报告中应当得出“行或不行”的决断。
7.3 方案的制订和改进
通过在问题定义和归结模型阶段的工作，已经分析并定义了与系统开发目标相关的各种模型、分析出了系统的功能清单、性能要求等，解释了“系统目标是什么”的问题。在系统方案阶段，主要完成的工作则是解释“系统如何实现”的问题。
系统方案制订的最主要内容，包括以下几个方面。
1. 确定软件架构
在问题定义阶段得到的软件概念模型使用各种工具定义了项目的开发目标。在系统方案制订阶段才开始真正考虑如何去实现软件。其中最重要的工作，就是制定系统的实现架构。
系统的实现架构与一些很具体的方面相关：
- （1）分析模型的结构。例如，采用结构化分析方法得到的功能分解体系，或面向对象的类和“对象－关系图”、“对象－行为图”。
- （2）一些对应于系统目标的最基本、最重要的实现要素。例如，关键的用例、最主要的控制类、对象组织的模式、常用和最关键的实现算法模型等。这些实现要素对应于系统目标实现最重要的场景，表示了整个系统最主要的控制流程和实现机制。
- （3）特性和要点的解释。这些附加的内容解释系统的一些特性、服务等是如何实现的。
2. 确定实现的各种关键性要素和实现手段关键性的实现要素通常包括：
关键的用例、最主要的控制类、功能和服务的首要组织方式（例如网站首页）；
对象的组织模式；
常用和最关键的实现算法模型。关键性的实现手段通常包括：
选定基础计算平台，如操作系统、数据库、Web 服务器、中间件平台等；
选定开发工具和开发环境，如计算机语言、构件库、工具软件等。
3.归结目标到最适合的计算体系
通常，提供开发工具和开发环境的组织总是有一些标准的计算体系可以选择（例如，.NET和 J2EE 等），因此对于大多数系统开发项目来说，比较各种标准计算体系与预期目标之间的匹配程度即可选定计算体系。选择标准的计算体系去实现系统可以忽略大多数基础平台和底层支撑技术的实现问题，从而大大提高系统的质量、降低开发风险和成本。开发人员常根据基础平台的系统实现能力支持，公司或项目组在特定实现平台上的技术积累，甚至技术的“先进性”或流行程度这样的因素去选择系统的实现技术体系。
在另一些情况下，出于各种诸如用户投资力度，与用户现有的 IT 设施保持一致性、兼容性、扩展性及未来维护的能力等因素，系统的基础平台很可能在项目的论证阶段就已经被确定，如操作系统、数据库系统、Web 服务器、开发工具或开发环境等。在这种情况下，系统的实现体系实际上已经确定。
通过同时参考系统概念模型，将前面得到的系统功能清单和系统实现的各种关键要素整理并分类，然后与现有的技术、标准的实现体系进行比较和匹配，就可以将系统概念模型定义的系统目标，进一步映射到真正可计算、可实现的系统架构上。这个过程可以理解为一种不断归结、比较并匹配的过程。
进行匹配的过程常常是一种双向的选择和探究过程，一方面拿出一个系统目标中的功能或实现要素，询问：这部分功能属于表示层、业务逻辑、还是数据服务？另一方面，也研究标准计算体系提供的功能，例如：放在业务逻辑层合适吗？技术人员具有这方面的开发经验积累吗？甚至是标准构件或服务可用吗？
各种标准的计算体系可能很复杂，但通常总是包括一些逻辑上的划分，例如，.NET 体系将应用系统理解为三个层次，表示层、事务逻辑层和数据服务层构成。
- （1）表示层：用户的界面部分。例如，单一应用程序的用户界面、C/S 计算模式的客户端、B/S 模式在浏览器中运行的HTML、DHTML、Scripting、JavaApplet、ActiveX 等。
- （2）事务逻辑层：负责处理表示层的应用请求，完成商务逻辑的计算任务，并将处理结果返回给用户。事务逻辑处理层是将原先置于客户端的事务逻辑分离出来，集中置于服务器部分，为所有用户共享。事务逻辑层是整个应用的核心部分，而组件对象模型 COM 则相当于其心脏。事务逻辑层通过 COM 进行事务处理，并由 IIS（Internet Information Server，Internet 信息服务器）和 MTS（Microsoft Transaction Server，微软事务处理服务器）为各种应用组件提供完善的管理。
- （3）数据服务层：为应用提供数据来源。和以往的两层架构不同，数据库不再和每个活动客户保持一个连接，而是若干个客户通过应用逻辑组件共享数据库的连接，从而减少连接次数，提高数据服务器的性能和安全性。
相同的三层计算模式，也会表现为不同的实现方式。例如，表示层可能是单一应用系统的用户界面、C/S 计算的客户端、或 B/S 计算的 Web 页面和元素；事务逻辑层可能是单一应用系统的程序模块、C/S 的服务器端服务、B/S 应用服务器中的业务脚本或业务对象；
当利用类似存储过程来实现数据操作逻辑的时候，存储过程也被看作事务逻辑层的一部分，但如果利用 ADO（ActiveX Data Object，ActiveX 数据对象）这样的数据访问组件访问数据时，ADO 和后台的数据库系统及数据库的逻辑则被看作数据服务层的一部分。
在必要的情况下，某个层次还可能进一步细分，例如，使用面向对象设计方法的系统常常会将事务逻辑层划分为基本的计算对象、业务对象及黏合业务对象实现功能的脚本 “胶水”或一些控制类。
不同标准的计算体系的逻辑划分，甚至同一个计算体系的不同版本，通常也不会套用这样的三层分类方式，但却有类似之处。图 7-2 表示了利用 JSP 开发 Web 程序的计算模式。
JSP 页面构成了前端的表示层，EJB 构成了业务逻辑层，JDBC（Java DataBase Connectivity，Java 数据库连接）和后台的数据库构成了数据服务层。
对于小规模的网站系统，开发者可能直接在 JSP 页面中书写所有的应用逻辑脚本，这样业务逻辑层就和表示层合并了，而对于使用 J2EE 体系的开发人员来说，利用 EJB 的容器、对象操作语言等机制直接实现了对象级的接口，开发人员直接在业务逻辑层去构思应用，JDBC 和后台数据库系统的数据服务层被隐含在 J2EE 的平台机制内，在更高的抽象级别上被屏蔽。
因此，归结系统实现要素到计算体系的时候，要点在于理解各种计算体系的大致分层和构成，比较实现要素的目标和实现手段之间的“适合程度”，而不是生搬硬套某种实现机制，或盲目追求某种“流行的”或“先进的”算体系。
系统方案制订后，需要根据有关标准进行评价，找出不符合实际的地方，然后进行改进。
7.4 新旧系统的分析和比较
计算机技术飞速发展，日新月异，许多企业因为业务发展的需要和市场竞争的压力，需要建设新的企业信息系统。在这种升级改造的过程中，怎么处理和利用那些历史遗留下来的老系统，成为影响新系统建设成败和开发效率的关键因素之一。通常称这些老系统为遗留系统。
目前，学术和工业界对遗留系统的定义没有统一的意见。Bennett 在 1995 年对遗留系统做了如下的定义：遗留系统是不知道如何处理但对组织又至关重要的系统。Brodie 和Stonebraker 对遗留系统的定义如下：遗留系统是指任何基本上不能进行修改和演化以满足新的变化了的业务需求的信息系统。
笔者认为，遗留系统应该具有以下特点：
- （1）系统虽然能完成企业中许多重要的业务管理工作，但已经不能完全满足要求。一般实现业务处理电子化及部分企业管理功能，很少涉及经营决策。
- （2）系统在性能上已经落后，采用的技术已经过时。如多采用主机/终端形式或小型机系统，软件使用汇编语言或第三代程序设计语言的早期版本开发，使用文件系统而不是数据库。
- （3）通常是大型的系统，已经融入企业的业务运行和决策管理机制之中，维护工作十分困难。
- （4）系统没有使用现代系统工程方法进行管理和开发，现在基本上已经没有文档，很难理解。
在企业信息系统升级改造过程中，如何处理和利用遗留系统，成为新系统建设的重要组成部分。处理恰当与否，直接关系到新系统的成败和开发效率。遗留系统的演化方式可以有很多种，根据系统的技术条件、商业价值及维护和运行系统的组织特征不同，可以采取继续维护、某种形式的重构或替代策略，或者联合使用几种策略。究竟采用哪些策略来处理遗留系统，需要根据对遗留系统的所有系统特性的评价来确定。
7.4.1 遗留系统的评价方法
对遗留系统评价的目的是为了获得对遗留系统更好的理解，这是遗留系统演化的基础，是任何遗留系统演化项目的起点。本文的评价方法包括度量系统技术水准、商业价值和与之关联的组织特征，其结果作为选择处理策略的基础。
评价方法由一系列活动组成，如图 7-3 所示。
1. 启动评价
评价是为了获得对遗留系统的足够深度的理解，从技术、商业和企业角度对系统的理解为系统处理策略提供基础，开始评价前，需要了解以下问题。
- （1）对企业来说，遗留系统是否是至关重要的。在评价过程中，可能会发现系统对企业的继续运作产生的影响不大。在这种情况下，就没有必要考虑系统的演化问题。
- （2）企业的商业目标是什么。从商业观点来看，评估师必须理解企业的商业目标，因为商业目标产生演化需求。
- （3）演化需求是什么。演化需求来自企业的商业目标和评价活动。需求必须是可见的，以便决定已存在的系统是否能满足需求。
- （4）所期望的系统寿命多长。一个系统的寿命由软件和硬件的服务能力决定，一旦系统硬件或支撑软件过时，系统的有效性就受到限制。
- （5）系统使用期限多久。如果系统的使用期限只是短期的，就没有必要花费成本来演化系统。相反，如果系统将在相当长的时期内支持主要业务流程，则必须进行演化。
- （6）系统的技术状态如何。例如，如果应用软件的技术状况很差，则很难理解，维护费用会很高。
- （7）企业是否愿意改变。企业对改变的态度是遗留系统演化成功的关键因素之一。
- （8）企业是否有能力承受演化。企业的技术成熟度，员工的素质，支撑工具的级别等都是影响演化的因素。
2. 商业价值评价
商业价值评价的目标是判断遗留系统对企业的重要性。在多数情况下，重要业务过程的改变意味着旧的系统现在仅仅具有外围价值，修改这种系统只需花费少许财力和物力。
在其他情况下，系统的业务价值很大，需要继续维护运行。可以在概要和详细两个级别上进行遗留系统的商业价值评价。
概要级评价将为更加详细的分析提供信息。概要级评价包括：
- （1）咨询。向有关专家进行咨询，包括最终用户和负责业务处理的管理人员。
- （2）评价问卷。问卷应该标识系统在业务处理过程中的哪些地方使用，本系统与其他系统的关系，如果系统不再运行所需的代价，系统已有的缺点和存在的问题等。问题的准确性依赖于所评价的系统。
- （3）进行评价。有了问卷的基础后，必须认真分析系统是如何使用的，这往往会发现系统的价值，而这在问卷中是得不到的。
希赛教育专家提示：详细级评价包括应用系统不符合业务规范的风险分析，这种分析十分费时，最好由业务分析师来完成详细级的评价。
3. 外部环境评价系统的外部技术环境是指硬件、支撑软件和企业基础设施的统一体。
- （1）硬件。系统硬件包括许多需要进行常规性维护的部件，这些硬件或者在一个站点，或者分布在许多站点并由网络连接。一般来说，遗留系统的硬件包括主机和小型机、磁盘驱动器、磁带、终端、打印机和网络硬件。
与商业价值评价类似，硬件评价也可以分为概要级评价和详细级评价。概要级评价把遗留系统作为一个整体，提供硬件质量估计。详细级评价包括识别系统中的每个部件。在这两种情况下，必须识别一系列特征，用作评价的基础。特征的选择取决于要评价的系统，系统的一些常见特征有供应商、维护费用、失效率、年龄、功能、性能等。
具体评价方法是：每一个部件（或整个系统）在每个特征上分配一个价值分数（取值为1～4），然后把所有分数相加，获得该部件的总分。
- （2）支撑软件。系统的支撑软件环境也由许多部分组成，可包括操作系统、数据库、事务处理程序、编译器、网络软件、应用软件等。一般来说，支撑软件是依赖于某个硬件的，应用软件依赖于系统软件。在评价过程中，必须考虑这种依赖性。支撑软件的评价方法类似于硬件评价，在此省略。
- （3）企业基础设施。企业基础设施包括开发和维护系统的企业职责和运行该系统的企业职责（两者可能为同一个企业），这些基础设施是很难评价的，但对遗留系统的演化起关键作用。因此必须考虑以下问题。
企业和使用者的类型。企业或者有自己的系统开发队伍，或者所有开发和应用管理都是请其他企业完成。系统用户或许只重复一些记录性工作，或许包括一些更有技术性的工作。
开发组织的技术成熟度。开发组织的技术成熟度包括是否使用了现代系统工程方法，是否遵循了统一的标准，是否进行了过程改进等。
企业的培训过程。如果企业（包括开发方和客户方）的培训做得好，遗留系统的演化可能会更成功。
系统支持人员的技术水平。如果系统支持人员的水平和经验不够，就不要急于对系统做大的改动。
企业是否愿意改变。企业对改变的态度是遗留系统演化成功的关键因素之一。企业基础设施的评价方法类似于硬件评价，在此省略。
4. 应用软件评价应用软件评价也有两个级别。
- （1）系统级。把整个系统看作是不可分的原子，评价时不考虑系统的任何部分。
- （2）部件级。关注系统的每个子系统，考虑每个子系统的特征，包括复杂性、数据、文档、外部依赖性、合法性、维护记录、大小、安全性等。
具体评价方法也与硬件评价类似，在此省略。
5. 分析评价结果评价活动将产生硬件、支撑软件、企业基础设施和应用软件的特征值矩阵，这些特征值体现了遗留系统当前的技术因素，其加权平均值代表了系统的技术水平。
计算公式如下：
OR=(P1ORH+P2ORS+P3OAF+ P4ORA)/4
其中 ORH 是硬件的评价值，ORS 是支撑软件的评价值，ORF 是企业基础设施的评价值，ORA 是应用软件的评价值，Pi (1
i
4) 分别是它们的权系数，即第 i 个评价值对遗留系统的影响因子。
把对技术水平的全面评价结果与商业评价进行比较，可以为系统演化提供第一手的资料。
具体方法是按照商业评价分值和技术水平分值的情况，把评价结果分为四种类型，如图 7-4所示。
7.4.2 遗留系统的演化策略
在图 7-4 中，把对遗留系统的评价结果分列在坐标的四个象限内。对处在不同象限的遗留系统采取不同的演化策略。
1. 淘汰策略
第 3 象限为低水平、低价值区，即遗留系统的技术含量较低，且具有较低的商业价值。
对这种遗留系统的演化策略为淘汰，即全面重新开发新的系统以代替遗留系统。
完全淘汰是一种极端性策略，一般是企业的业务产生了根本的变化，遗留系统基本上不再适应企业运作的需要；或者是遗留系统的维护人员、维护文档资料都丢失了。经过评价，发现将遗留系统完全淘汰，开发全新的系统比改造旧系统从成本上更合算。
对遗留系统的完全淘汰是企业资源的根本浪费，应该善于“变废为宝”，通过对遗留系统功能的理解和借鉴，可以帮助新系统的设计，降低新系统开发的风险。
2. 继承策略
第 4 象限为低水平、高价值区，即遗留系统的技术含量较低，可满足企业运作的功能或性能要求，但具有较高的商业价值，目前企业业务对该系统仍有很大的依赖性。对这种遗留系统的演化策略为继承。在开发新系统时，需要完全兼容遗留系统的功能模型和数据模型。
为了保证业务的连续性，新老系统必须并行运行一段时间，再逐渐切换到新系统上运行。
要做到对遗留系统的继承，必须对系统进行分析，得到旧系统的功能模型和数据模型，这种分析可以部分代替或验证系统的需求分析。
如果遗留系统的维护文档不完整，而又必须解析系统的功能模型和数据模型，那将是一项十分艰巨的任务。这时可使用有关系统重构的 CASE 工具，通过分析系统的代码生成系统结构图或其他报告。
3. 改造策略
第 1 象限为高水平、高价值区，即遗留系统的技术含量较高，本身还有较大的生命力，且具有较高的商业价值，基本上能够满足企业业务运作和决策支持的要求。这种系统可能建成的时间还很短，对这种遗留系统的演化策略为改造。
这些改造包括系统功能的增强和数据模型的改造两个方面。系统功能的增强是指在原有系统的基础上增加新的应用要求，对遗留系统本身不做改变。数据模型的改造是指将遗留系统的旧的数据模型向新的数据模型转化的过程。
4. 集成策略
第 2 象限为高水平、低价值区，即遗留系统的技术含量较高，但其商业价值较低，可能只完成某个部门（或子公司）的业务管理。这种系统在各自的局部领域里工作良好，但从企业全局来看，多个这样的系统，他们各自基于不同的平台，不同的数据模型，无法互联互通，数据还不一致，这就是很严重的问题了。
对这种遗留系统的演化策略为集成。
在集成过程中，可采用由互连系统构成的系统的架构，遗留系统可作为从属系统来描述。
在企业信息系统建设过程中，如何处理那些遗留系统，将会是越来越突出的问题，因为即使是今天看来很先进的系统在明天也会成为遗留系统。对遗留系统的处理恰当与否，直接关系到新系统的成败和开发效率。如何建立一套系统的、行之有效的方法，以期望对实际工作有所指导，已成为一个迫切的问题。在实际工程项目中，遇到处理遗留系统的问题时，要具体情况具体分析，选择最佳的演化策略。