基于ODP的架构师设计
软件系统架构设计方法是一个实践性大于理论性的工作。从软件有模块概念那天起，就有了总体设计，研究模块、构件与它们之间的关系。架构设计虽然可以归集到几种风格，但面对复杂的应用环境，不同应用领域对架构的理解差异非常大，用事实说话是最基本的研究方法。本章在RM-ODP多视点架构模型上，探讨应用于分布式信息系统的软件架构开发，对软件生命周期其他阶段的影响，特别是架构师在开发过程中的任务与作用。
基于ODP的架构开发过程
系统架构反映了功能在系统构件中的分布、基础设施相关技术和架构设计模式等，它包含了架构的原则和方法、构件关系与约束，并能支持迭加或增量开发。以软件架构为中心的开发过程是以质量和风险驱动的，最终提供一个稳定、低风险的系统架构，并满足客户的需求（包含潜在需求）。
开放分布进程的参考模型（RM-ODP）是一个ISO标准，它为分布式计算进程提供了一个框架。RM-ODP定义了分布式系统的重要性质：开放性、整体性、灵活性、可塑性、联合性、可操作管理性、优质服务、安全性和透明性，并定义了一组视点。RM-ODP视点定义大体对应于IEEE 1471定义，RM-ODP定义的5个视点如下。
（1）企业视点：在如下因素的环境中分析系统，商业需求和策略、以及系统的范围和目的。RM-ODP处理可能会影响系统中的与企业相关的信息，如组织结构等。
（2）信息视点：指信息的结构，它的变化、流程以及在不同功能间的逻辑划分。
（3）计算视点：重点在于把系统分解为实体和实体间的接口。
（4）工程视点：处理分布式系统对象之间的交互，以及交互是如何得到支持的。
（5）技术视点：定义构成系统的硬件和软件构件。
体系结构视点是把抽象的符号或图表（如UML）运用到具体的体系结构开发任务中。每一个视点有具体的建模目标和系统相关者。例如，环境视图提供了对系统边界及与系统发生交互的外部实体集合的概述。分析视图提供了一个以建模问题而不是答案为中心的实体的抽象集合。
以描述软件设计为目的的视点包括构件、构件交互及构件状态。视图提供了一个对于逻辑运行结构及其功能，以及它们之间通信的映射。子系统接口依赖视图提供了一个子系统依赖关系和接口的图形表示；分层子系统视图提供了一个所有子系统高度抽象的视图；逻辑数据视图提供了构件共有的数据模型描述。
不同视图解决不同方面的问题，这是应对复杂问题的基本研究方法（分治）。采用ODP从5个视点描述信息系统架构，对整个系统开发过程有一定指导意义。除了架构设计阶段，其他阶段对架构师也提出不同的任务与要求。图14-1展示了整个系统及架构开发的10个过程。
图14-1 系统架构开发的10个过程
本章按图14-1的次序，探讨架构师的任务与设计工作。
系统构想
系统构想的定义
系统构想是指一个系统开发人员与系统用户之间共同的协议。按照该协议，系统开发人员需在特定的时间内完成系统用户的需求。系统构想必须简短而切中要点，给人以清晰的感觉。它不是一成不变的，必须根据系统的不同而不同。
构想描述建立了从需求分析开始的所有项目活动的语境，它高度概括了企业业务架构的核心内容。
架构师的作用
讨论建模的时候，我们曾提到关键词有目的、关注点、假设和优先级，它们都是系统级的“构想描述（Vision Statement）”的基本元素。如果它们在系统开发过程中改变，项目就有被抛弃的危险。因此，以架构为中心的开发的第一步就是建立一个构想描述，且假定构想描述在系统的各个开发阶段不会改变。所有的改变必须在关键的项目计划中有所反映，特别是在系统架构中。
系统构想包括为客户、为软件系统开发团队等受益人创建的，有助于各方明了系统的目标和范围。对开发者而言，从宏观层面上显示系统架构的需求，为待开发系统提供一个结构清晰的概要，确保系统开发的计划、设计等阶段能依次有序地展开。
系统构想阶段，架构师合理的介入，有以下好处。
（1）有利于使系统架构师本身对系统的看法更加全面、准确。
（2）有利于统一系统开发人员对系统的看法。
（3）有利于正确确定需求的优先次序。
（4）通过系统构想，可以在最大程度上提高客户对设计等过程的参与程度，更好地与客户沟通。
系统构想面临的挑战
建立和共享架构构想要面临着很多的挑战：架构师对其控制能力之外的因素（例如组织等）通常无能为力；当产品线由一个架构来支撑时，构想就会受更多的因素制约。此外，如果共享的架构构想有问题时，不易马上觉察到。不过，可以通过有效地评估，以及高级经理和架构师之间保持紧密的联系来克服这些困难。
除了以上介绍的挑战外，在系统构想阶段，还必须面对以下几种情况。
（1）很多架构师把架构看成是他们独自的创造，而且只要他们认为合适的就进行修改。
（2）有些人不是拥有产品线构想的高级经理，却总是由这些人来决定雇佣谁来做架构师。由于没有参与架构师的招聘工作，高级经理们将无法评估架构师的能力以及理解并实现其构想。
需求分析
架构师的工作
需求一般定义系统的外部行为和外观及用户信息，而不用设计系统的内部结构。外部行为包括了用来保证外部行为能够完成而所需的内部行为（例如持续性或计算）。外观包括用户界面的布局和导航，用户信息包含用户概念数据结构及关系模型。
架构师对需求分析通常考察以下6个方面的内容。
（1）系统范围对象关系图。主要用于定义系统与系统外部实体间的界限和接口的简单模型，它可以为需求确定一个范围。
（2）用户接口原型。可将其看作为用户操作的一个雏形，通过该接口界面用户能够用一系列的操作完成它想达到的效果。
（3）需求的适用性。即这个需求应该用什么技术解决，它实现后的性能怎么样，是否与其他需求相重合或是矛盾。需求分析应注重需求本身的实用或适用，而不必考虑其实现。
（4）确定需求的优先级。可采用迭代周期来说明何时完成。
（5）为需求建立功能结构模型。可以用UML创建组件图和实体数据对象图，概述系统原型。
（6）使用质量功能分配（Quality Function Deployment, QFD）。根据需求的理解发现隐藏质量需求，建立相关质量场景和易变需求场景，先期预测需求风险。
架构师的一个有效地捕捉行为需求的方法是分析用例（use case）。一个用例包含一个顶层的图和扩展的文字描述。用例符号简单、抽象，非常适合于用来保证在表述顶层需求概念时的简单性和清晰度。
需求分析的任务
需求分析的目的
需求分析的目的是完整、准确地描述用户对系统的需求，跟踪用户需求的变化。将用户的需求准确地反映到系统的架构和设计中，设计和用户的需求保持一致。需求分析具有决策性、方向性和策略性的作用，它在软件开发的过程中具有举足轻重的地位。
需求分析的特点
一般来说，需求分析特点的共同点都是追求系统需求的完整性、一致性和验证性。
（1）完整性：是准确、全面地描述用户对系统架构的需求。
（2）一致性：是通过分析整理，剔除用户需求矛盾的方面，规范用户需求。
（3）验证性：是需求的一致性表现形式，主要包含以下几个方面的含义。
① 保持和用户要求的同步。
② 保持需求分析各侧面之间的一致。
③ 保持需求和系统设计间的同步。
因此，在对系统架构需求分析之前必须建立需求分析技术层面的基本框架，从技术上保证需求分析的要求，在此基础上进行的架构需求分析才能满足项目对需求分析的要求。
需求文档与架构
每个用例都有一个相关需求的文字描述。这种方法采用了包含一系列活动的列表形式，用特定领域的平铺直叙的文字来描述。定义用例应该和领域专家一起进行，如果没有领域专家的长期参与，这种活动只能是一种“伪分析”。
用例为定义架构提供了一个系统的领域行为模型。在开发的第7个过程中，用例被特定系统的场景所扩展，最后这些场景会在软件测试中得到运用。
用户界面的外观、功能和导航同用例紧密相联。一个有效定义屏幕的方法叫做低保真度原型（Low-fidelity Prototyping）。在这种方法中，屏幕是用纸和笔先画出来的。同样，最终用户领域专家也始终参与到屏幕定义中去。
有了用例和定义的用户界面以及领域概念模型，我们建立了架构规划的环境。在产生文档之外（包括纸、笔的草图），架构小组得到最终用户领域中需求功能的更深刻理解。需求分析的项目词汇表，也将在架构规划中被扩展。
系统架构设计
系统架构沟通了需求和软件之间巨大的语义上的鸿沟。需求是模糊的、直观的，而软件则具有相反的性质。系统架构的第一个任务就是定义这两个极端之间的映射，架构用一种更为技术性的方式来捕捉直觉的决定，它在设计和编码之前定义了内部的系统结构。架构设计同时为项目计划服务，它允许系统构建用适应变化的方法来控制复杂性，同时指导建立软件项目与架构对应的组织。
开放分布式处理（Open Distributed Processing, ODP）从5个标准的视点组织分析了系统的架构，描述了同一系统的重要方面。如图14-2所示，这些视点包括企业、逻辑信息、计算接口、分布式工程和技术选择。对于每个视点，确认架构需求的一致性是非常重要的。ODP促进了这个过程，因为它内嵌了一个普遍的一致性方法，简单的一致性清单包含识别架构中一致点所需的全部内容。
图14-2 ODP视点
企业业务架构
企业业务架构从IT的角度，对企业的业务结构、企业机构与业务的关系、企业内部的关系以及企业与外部机构的关系进行整理定义。企业业务架构包含如下内容。
（1）企业的业务和战略目标。描述企业的目标，包含近期目标、中期目标和长远的战略目标。
（2）企业的组织机构。明确描述企业的组织机构和职能，以及与企业相关的机构和个体，如客户、合作伙伴和供应商等。
（3）业务的分类。对企业的产品、服务和资源体系进行分类。这种分类包含了对相关产品、服务和资源的共性提取和总结。
（4）各类业务之间的关系。对产品、服务和资源的相互关联进行总结。业务之间的关系体现为跨业务的流程及资源共享等。
（5）组织机构与业务的关系。业务的执行是由机构来完成的，但是机构与业务并不一定是一一对应的关系。清楚地找出机构与业务的关系，将为应用与集成架构奠定可靠的基础。
（6）企业与外部机构的关系。对与企业相关的外部机构或个人就其类型、业务类别和业务往来模式等进行分类。
企业业务架构（企业视点）也是用高层企业对象来定义业务目的和系统策略。这些业务对象模型标识出系统的关键性约束，其中包括系统目标和重要的系统策略。
策略包含如下三类明确的表达方式。
● 责任：业务对象必须做什么。
● 许可：业务对象可以做什么。
● 禁止：业务对象不可以作什么。
在对业务问题进行分析时，不仅要考虑企业目前业务的情况，而且要考虑企业业务的发展，如新的服务或产品的推出、考虑组织机构的改变等，企业的业务流程的变化也是要考虑的因素。所有这些可能的变化（易变场景）都应该体现在企业的业务架构中。
企业业务架构在明确了企业的业务和战略目标之后，从业务和机构两个基本点出发进行基础性的分类组织工作，然后根据业务的分工和业务流程与组织机构实现映射，从而形成对企业业务的完整描述。一个典型的企业业务架构包含一系列逻辑对象图（通常用UML表示）和对象语义的平铺直叙的文字描述。
通过对企业业务架构的定义，就可以很清楚地知道由于企业业务特点、业务流程的特点和企业的组织机构等原因对IT系统所带来的自然分块和各个分块之间的边界关系，从而就可以知道怎样从技术架构上来满足和支持企业的业务架构。
企业业务架构的维护也是一个长期而反复的工作。企业业务架构的变化可以通过技术架构反映出来，技术架构的正确与否可以通过业务架构来检验，这样才能通过架构来保证IT服务于企业的业务和战略。
下面以一个测试结果报告系统（Test Results Reporting System, TRRS）为例，介绍一下它的企业业务架构。
TRRS的企业视点由一些UML用例组成，这些用例确定了TRRS社区的参与者以及他们之间策略上的联系。图14-3展示了这些来自应用软件开发者视点的UML用例。这三个在UML图中的用例表明，软件开发者可以通过多种途径使用TRRS，以决定软件产品的兼容性。
图片详情
重要的企业策略关系到TRRS数据库中产品描述的完整性和责任。在TRRS处理中，可以使用UML对象约束语言（Object Constraint Language, OCL）来定义企业活动者的这些策略（如许可、禁止和义务等）。
逻辑信息架构
逻辑信息架构（信息视点）标识出系统必须知道什么。这种架构通过一个对象模型来表达，强调定义系统状态的属性。因为开放分布式处理是一种面向对象的方法，模型包含了关键信息的处理，如传统的对象概念。
软件架构对象并不是编程的对象，它表示对系统的约束和依赖。这些约束能够消除在把需求翻译成软件过程中的许多猜测性工作。架构师应该把他们的建模集中于系统中有高风险、高复杂性和模糊性的关键方面，而把直接的细节放在开发的环节中去。
下面以测试结果报告系统为例，介绍一下它的逻辑信息架构。
图14-5 供应商信息的UML表示
TRRS信息视点是由一组UML类模型组成，该信息视点定义了一些核心的概念，这些概念组成了TRRS系统的持久状态。图14-4是一个UML图，它展示了产品之间的互操作关系。一致性声明（Conformance Statements，如图14-5所示）提供了产品兼容性标准的保证。互操作性声明（Interoperability Statements）是一个类似的概念，和兼容性不同之处在于它不包含供应商对相互之间产品兼容性的保证。互操作性测试报告（Interoperability Test Report）包括了多产品互操作测试所得出的测试结果。互操作性产品（Interoperability Product）是特定的源于多供应商兼容性的解决方案。经验报告（Experience Report）是实例研究的文档，它记载了产品集成的成功经验。合起来，上述各个部分组成了TRRS数据库要储存的关键文档类型。
计算接口架构
计算接口对系统架构非常有帮助，但是它常常被架构师所忽略。它定义了顶层的应用程序接口，这些是完全工程化的子系统边界的接口。在实现时，开发者将对他们的模型在这些边界上进行编程，以消除多个开发者和小组的主要设计争端。这些接口的架构控制对于一个支持变化和控制复杂性的稳定的系统结构来说，是非常重要的。
开放分布式处理体系结构的一个ISO标准采用的是CORBA接口定义语言（IDL），IDL是一种基本记法，它完全独立于编程语言和操作系统。IDL可以被编译器自动翻译成Java、C++和C#等大多数流行的编程语言。
分布式工程架构
分布式工程架构定义了底层结构的需求，而独立于所选择的技术。它很好地解决了一些最复杂的系统策略，其中包括物理位置、系统规模可变性和通信服务质量。
ODP的一个最大好处是关注点分离，幸运的是，前面的视点解决了许多其他的复杂问题，那些是分布式很少关注的，如API、系统策略和信息纲要。相反，这些其他的视点能够解决它们各自的设计要点，而独立于分布式的考虑。
在进行分布式工程架构建模时，必须考虑系统的各个方面，如对象复制、多线程和系统拓扑等。
技术选择架构
技术选择架构（技术视点）确定了实际的技术选择，所有其他视点都独立于这些决定。因为大多数架构设计是独立的，商业技术的发展可以很容易地适应。
一个系统的选择过程包括初始的概念性机制的确认，如持久性或者通信。概念性机制的特定属性可以从其他视点得到。具体的机制被标识出来，如DBMS、OODBMS。这些特定的参选产品是从可得到的技术中选出来的。基于对候选者的初始选择，这个过程根据产品价格、培训要求和维护风险之类的项目因素而反复进行。
架构师选择的原因是非常重要的，因为所有这些观点可以作为以后架构约束的理由。记录可以放在一个由架构小组维护的非正式项目记事本上，可以用于以后进行参考。
以测试结果报告系统为例，介绍一下它的技术选择架构。
TRRS技术视点包括了原型规划的三种方式（如图14-6所示）。我们经常选用这些原型来支持渐进的系统演化和可扩展性。而从一种方式到另一种方式的演化之所以能够发生，是由在实现时选用不同的技术和提供多层结构间互操作机制所造成的。
图14-6 原型规划的三种方式
阶段1是一种快速的原型，它由一个独立的Java应用程序以及一个平面文件数据库配置而成。阶段2使用分布式基础设施中的RMI或者IIOP技术，支持局域网上的多客户系统。阶段3支持数据库的可扩展性，这是通过把平面文件替换为JDBC接口及其操作的后端数据库来实现的。
在阶段3之外，TRRS还需要对数据库表项、数据库集成和适应因特网环境下的安全性等功能提供支持。其他的开发挑战包括提供体系结构的设计工具以及利用TRRS数据进行管理等，例如向软件开发者报告相关的TRRS产品表项。这些为软件体系结构引入了一个新的动态层面。
实现模型
最终用户和架构师应在一起审查并贯穿于用例（业务场景、质量场景、易变场景）始终来证实需求的有效。通常这个交流会出现新的或者需要修改的需求，对于需求的任何修改都要标注并结合到随后的其他架构活动中去。通过模型，管理层能够看到可视化的进展。
大多数系统可以采用快速原型技术生成模型。快速原型技术有利于快速获取产品设计的反馈信息，并对产品设计的可行性做出准确的评估、论证。
架构原型
在完成上述任务之后，从构建的草图进而发展成产品原型。架构原型是很好的需求验证工具，它能够帮助利益相关人检测系统锲合用户操作的程度。可以使用各种各样的办法构建架构原型，而非编码一种。例如，可以使用故事板来可视化地展现用户使用产品的过程，也可以使用原型工具来模拟过程，以此说明产品是如何运行的。架构原型只是快速构建，作为改进设计的手段，如果在构建架构原型过程中使用了编码，也要尽量避免在最终产品中使用这些代码。
架构框架（Framework）是对系统架构的一种可运行验证工具，通过对系统的API定义的编译以及编写小程序来模拟运行的系统。架构框架用于正式计算和工程体系架构，这包括穿越分布式边界的控制和定时。
使用CORBA技术，一个架构的规范能够被自动地编译成带有分布式stub和框架程序的一系列程序的头文件。通过在框架程序中插入虚拟代码来模拟处理过程，编写简单的客户程序用虚拟的数据来穿越边界发送请求。一些关键的，比如说：高风险的用例被替换的客户程序所模拟。原型的执行被计时以确保与工程约束相一致。
下面是一些架构师可以在架构原型中寻求解答的具体问题。
（1）主要组件的责任是否得到了良好定义？是否适当？
（2）主要组件间的协作是否得到了良好定义？
（3）耦合是否得以最小化？
（4）我们能否确定重用的潜在来源？
（5）接口定义和各项约束是否可接受？
（6）每个模块在执行过程中是否能访问到其所需的数据？是否能在需要时进行访问？
为了构建实际的系统，初始的架构原型需要进行演化。较好的情况是在经过2次或3次迭代之后，架构变得稳定。主要的抽象对象都已被找到；子系统和过程都已经完成；所有的接口都已经明确定义。
在系统架构开发过程中，利用架构原型，至少有下面的几个好处。
（1）在架构落实之前，让团队成员能自由发表他们自己的看法，并进行讨论，提出建议，对在架构原型中存在的问题进行及时改正。
（2）可以在系统的整体性能上，把握得更好。统一团队成员之间的思想看法和提高系统开发的成功率。
（3）它对系统内部的结构分析与设计也有帮助。
项目规划
无论什么项目，其最终目标都是要按期、按预算开发出满足用户需求的、高可靠、高性能的产品。在实现这个目标的过程中，项目规划起着至关重要的作用。项目规划是一份已通过批准的正式文档，它根据项目的目标，对项目实施进行的各项活动作出规定，以它为基准跟踪和控制项目，确定未来的行动方案和资源分配，引导项目的实施。项目规划的主要作用是将制定规划的假设和决定以及批准的范围、成本、进度的基线等用正式的文档记录保存。规划的复杂性取决于项目的复杂性，它体现了对客户需求的理解，便于高层管理、项目经理、项目组成员及项目相关人等之间进行交流沟通。
项目规划是基于当前已有的信息，包括过去的经验，当前的目标、范围、组织结构、资源等，工作活动、里程碑、质量目标和风险管理等，其中估算是项目规划的核心。随着项目的进展，信息的增多和理解的深入，估算会不断校正并逐渐地接近实际。项目计划是在规划基础上建立的一组实现任务的活动表，如进度计划、质量活动计划和配置管理计划等。项目管理者通过计划与规划的差异，不断优化和更新计划策略，使项目按规划的要求得以实现，计划的变更是可管理和可受控的。
项目规划是项目工作的纲领，要以此去指导项目的技术和管理活动。项目规划包括如下内容。
（1）项目的目的、范围、目标和对象。
（2）软件生存周期的选择。
（3）精选的供开发和维护软件用的规程、方法和标准。
（4）待开发的软件工作产品。
（5）软件工作产品的规模估计、软件项目的工作量和成本的估计。
（6）关键计算机资源的估计；项目的里程碑。
（7）风险的识别和评估。
（8）工程设施和支持工具计划。
软件项目计划的目标有：软件估计被文档化，以供跟踪软件项目使用。软件项目的活动和约定是有计划的，并形成文档，受影响的组和个人认同与软件项目规划的约定。
并行开发
软件并行开发的内容及意义
并行开发的意义在于提高软件生产率和改善软件质量。软件并行开发有效地组织可以重复的资源，并附加额外的控制管理技术，使软件开发尽量并行进行，从而达到加快软件开发速度、提高软件生产率、缩短软件开发周期的目的。同时，软件并行开发通过改善软件过程，达到提高软件质量的目的。软件并行开发以提高软件生产率为目的，对实现软件并行开发的各个方面做了必要的分析，并且给出了可行的解决方案，直接面对软件工程的实施，因此具有重要的应用价值。
软件并行开发研究的内容主要如下。
（1）软件过程及其模型。
（2）并行成分划分。
（3）并行控制。
（4）支持环境。
（5）交互机制与集成技术。
并行开发的过程
要讨论软件并行开发的软件生存周期模型，需要把视野集中到软件开发过程中。把软件系统的开发过程划分为若干个可以并行的成分，这个成分称之为子开发过程。子开发过程是一个动态概念，和操作系统中的进程概念有类似之处。子开发过程可以定义为：子开发过程＝开发小组＋软件对象＋对软件对象的开发活动。或者说，子开发过程是一个开发小组对一个相对独立的软件对象的动态开发过程。
在此，我们把整个并行开发活动看作是一个并行系统，称为并行开发系统。子开发过程是对并行开发系统的一种动态描述，此系统中的实体是开发小组，实体属性是被开发的软件对象，行为是开发软件对象的活动。每个子开发过程完成一个子系统或一个模块的开发任务，当各个子开发过程都完成之后，进行系统集成和测试，最终完成整个系统的开发，如图14-7所示。
图14-7 并行开发中的生命周期模型
并行模块的划分是并行开发中的核心问题，模块独立性是衡量软件设计质量的关键。根据并行开发的特征，一个开发小组负责一个模块的开发，如果各模块之间的耦合度低，那么各并行开发过程之间交互作用将减少，为并行开发控制带来方便。有如下两种系统划分的方法。
（1）基于Petri网系统模型的动态划分方法。
（2）基于脚本的系统划分方法。
在软件并行开发中，软件过程并行控制（以下简称并行控制）是一个非常重要的问题。所谓并行控制，就是要用正确的方式调度并行操作，避免造成不一致性，使一个操作的执行不受其他操作的干扰。为保证开发出的系统内部各成分间的一致性、相容性，保证系统的正确性和可靠性，就要进行并行控制。通常的并行控制手段有加锁、时间戳、管程、Petri网和PV操作等手段。并行控制模型描述被控制对象的并行行为以及它们之间的关系，是并行控制的依据。
当各个产品开发过程分别完成后，应通过集成技术，把各子开发过程所开发的软件对象集成起来，作为一个统一的应用系统。在软件并行开发的软件生存周期模型中，系统集成和系统测试被分为两个阶段，如果不考虑硬件或系统软件的集成，两个阶段并没有明显的界限。所以，就应用软件系统而言，软件集成的主要问题是集成测试技术。通过集成测试技术，在现实可行的时间内，运用工具尽量去发现尽可能多的软件错误，以保证软件的质量。
系统转换
系统转换是指运用某一种方式由新的系统代替旧的系统的过程，也就是系统设备、系统数据和人员等方面的转换。
系统转换的准备
在系统转换前，必须认真做好系统设备、数据、人员以及有关文件（如程序说明书、系统操作说明书等）的准备。
除此之外，还需要系统试运行这项准备工作。系统试运行是指在系统没有正式转换之前，选择一些子项目进行的实验运行。需要注意如下两方面的问题。
（1）系统试运行工作的代表性。指在系统试运行工作中所选择的子功能和数据应该尽量接近实际系统运行的需要。
（2）系统试运行中错误的修正。系统试运行过程中用户发现的一些问题，对待这些问题应该以系统分析中确定的系统目标为标准，认真分析产生问题的原因和类型，决定对系统的问题是否修订和如何进行修订。
系统转换的方式
系统转换可分为直接转换、平行转换、分段转换和分批转换。
（1）直接转换。直接转换是当新系统安装完毕能够进行工作后，立即停止旧系统的运行，让新系统投入运行的转换方式。
（2）平行转换。平行转换是新旧系统共同工作一段时间，当证实新系统有较高的可靠性后，再停止旧系统工作的转换方式。
（3）分段转换。分段转换时一次只用新系统的部分功能去替换旧系统的相应部分，逐步完成新系统替换旧系统的转换方式。
（4）分批转换。分批转换是把新系统在小范围内使用，然后再全部推广的转换方式。
以上几种系统转换方式各有各的特点，应根据系统规模的大小、难易和复杂的程度以及企业的具体情况决定系统转换时采用哪种方式。
系统转换的注意事项
在系统的转换过程中，无论采取哪种转换方式，都要注意以下问题。
（1）新系统的运行需要大量的基础数据，这些数据的整理与录入工作量很大，应及早准备，尽快完成。
（2）系统的转换不仅仅是机器的转换、程序的转换，更难的是人员的转换，应提前做好人员的培训工作。
（3）系统运行时会出现一些局部性的问题，这是正常现象。系统工作人员对此应有足够的准备，并做好记录。系统只出现局部性问题，说明系统是成功的；反之，如果出现致命问题，说明系统设计质量不好，整个系统甚至要重新设计。
操作与维护
操作与维护的内容
一个系统交付使用后，系统的开发就结束了，系统转入正常的运行操作时期。从系统的生命周期看，只有系统投入正常的操作和维护后，才真正实现了系统。因此，可以说操作维护是系统过程的后阶段。
系统操作与维护的内容有数据管理与维护，包括数据收集、数据整理、数据录入以及数据的分发、数据库管理工作；机器设备的管理与维护，包括硬件维护、机器日常行政管理、系统操作记录和用户服务等；系统软件的管理与维护工作，应用软件的管理与维护工作，代码维护。
系统维护与架构
系统架构的好坏，可维护性是一个重要方面，维护人员应参与架构的评审。系统的可维护性可以定性地定义为：维护人员理解、改正、改动和改进这个软件的难易程度，提高可维护性时开发管理系统所有步骤的关键目的。系统能否被很好地维护，可用系统的可维护性这一指标来衡量。系统的可维护性有如下几个评价指标。
● 可理解性
● 可测试性
● 可修改性
依据信息系统需要维护的原因不同，系统维护工作可以分为以下4种类型。
● $\color{green}{\text{更正性维护}}$ ：由于系统测试不可能揭露系统存在的所有错误，因此在系统投入运行后频繁的实际应用过程中，就有可能暴露出系统内隐藏的错误。 诊断和修正系统中遗留的错误，就是纠错性维护。纠错性维护时在系统运行中发生异常或故障时进行的，这种错误往往是遇到了从未用过的输入数据组合或是在与其 他部分接口处产生的，因此只是在某些特定的情况下发生。有些系统运行多年以后才暴露出在系统开发中遗留的问题，这是不足为奇的。
● $\color{green}{\text{适应性维护}}$ ：适应性维护时为了使系统适应环境的变化而进行的维护工作。一方 面计算机科学技术迅速发展，硬件的更新周期越来越短，新的操作系统和原来操作系统的新版本不断推出，外部设备和其他系统部件经常有所增加和修改，这就是必 然要求信息系统能够适应新的软硬件环境，以提高系统的性能和运行效率；另一方面，信息系统的使用寿命在延长，超过了最初开发这个系统时应用环境的寿命，即 应用对象也在不断发生变化，机构的调整，管理体制的改变、数据与信息需求的变更等都将导致系统不能适应新的应用环境。如代码改变、数据结构变化、数据格式 以及输入/ 输出方式的变化、数据存储介质的变化等，都将直接影响系统的正常工作。因此有必要对系统进行调整，使之适应应用对象的变化，满足用户的需求。
● $\color{green}{\text{完善性维护}}$ ：在系统的使用过程中，用户往往要求扩充原有系统的功能，增加一 些在软件需求规范书中没有规定的功能与性能特征，以及对处理效率和编写程序的改进。例如，有时可将几个小程序合并成一个单一的运行良好的程序，从而提高处 理效率；增加数据输出的图形方式；增加联机在线帮助功能；调整用户界面等。尽管这些要求在原来系统开发的需求规格说明书中并没有，但用户要求在原有系统基 础上进一步改善和提高；并且随着用户对系统的使用和熟悉，这种要求可能不断提出。为了满足这些要求而进行的系统维护工作就是完善性维护。
● $\color{green}{\text{预防性维护}}$ ：系统维护工作不应总是被动地等待用户提出要求后才进行，应进行主动的预防性维护，即选择那些还有较长使用寿命，目前尚能正常运行，但可能将要发生变化或调整的系统进行维护，目的是通过预防性维护为未来的修改与调整奠定更好的基础。 例如，将目前能应用的报表功能改成通用报表生成功能，以应付今后报表内容和格式可能的变化，根据对各种维护工作分布情况的统计结果，一般纠错性维护占 21%，适应性维护工作占25%，完善性维护达到50%，而预防性维护以及其他类型的维护仅占4%，可见系统维护工作中，一半以上的工作室完善性维护。
某个维护目标确定以后，维护人员必须先理解要维护的系统，然后建立一个维护方案。由于程序的修改涉及面较广，某处修改很可能会影响其他模块程序，所以建立维护方案后要加以考虑的重要问题是修改的影响范围和波及面的大小。然后按预定维护方案修改程序，若测试发现重大问题，则要重复上述步骤。若通过，则修改相应文档并交付使用，结束本次维护工作。必须强调的是，维护是对整个系统而言的。因此，除了修改程序、数据和代码等部分以外，必须同时修改涉及的所有文档。系统维护的步骤如图14-8所示。
图14-8 系统维护步骤
系统移植
系统移植的形式
系统移植的方法有三种：第一种是不修改已有的软件，可以使用的方法有高位互换、仿真功能和虚拟机（Virtual Machine）功能；第二种是修改软件，就是把已有软件资源，即程序、数据、计算机应用方法及各种说明书转换为与新机器具有匹配性的软件；第三种是重编软件，有从逻辑设计开始、从程序设计开始和从编程开始三种开发方式。
$\color{red}{\text{系统移植的工作阶段划分}}$
移植工作大体上分为计划阶段、准备阶段、转换阶段、测试阶段和验证阶段。为了有效地进行系统移植，就得使系统移植工作标准化；配备软件工具实现自动化；还要简化各阶段的工作。下面简要介绍一下系统移植的各阶段工作。
（1） $\color{green}{\text{计划阶段}}$ 。在计划阶段，要进行现有系统的调查整理，从移植技术、系统内容（是否进行系统提炼等）和系统运行三个方面，探讨如何转换成新系统，决定移植方法，确立移植工作体制及移植日程。
（2） $\color{green}{\text{准备阶段}}$ 。在准备阶段要进行移植方面的研究，准备转换所需的资料。该阶段的作业质量将对以后的生产效率产生很大的影响。
（3） $\color{green}{\text{转换阶段}}$ 。这一阶段是将程序设计和数据转换成新机器能根据需要工作的阶段。提高转换工作的精度，减轻下一阶段的测试负担是提高移植工作效率的基本内容。
（4） $\color{green}{\text{测试阶段}}$ 。这一阶段是进行程序单元、工作单元测试的阶段。在本阶段要核实程序能否在新系统中准确地工作。所以，当有不能准确工作的程序时，就要回到转换阶段重新工作。
（5） $\color{green}{\text{验证阶段}}$ 。这是测试完的程序使新系统工作，最后核实系统，准备正式运行的阶段。
系统移植工具
数据不能互换的系统移植时，完整的数据转换工具是必需的。主要有以下几种软件工具。
（1）分析工具：是分析现有软件资源，得到探讨移植方法有用信息的工具。
（2）生成工具：是编制作业控制语言、测试数据、转换工作所需文档的工具。
（3）转换工具：包括程序转换、数据转换和作业控制语言转换。
（4）数据应用工具：使用这种工具不用编文件就可以简便地存取磁带上的数据。
（5）测试、验证工具：作为可分类的工具包括静态、动态跟踪。
（6）管理工具：是管理资源及作业的工具。
系统移植工作需要的软件工具有很多种，配备工具最主要的是在决定移植的工作方法之后，配备移植所需的工具并明确工具的界限。即选出移植工作中的作业项目，使项目系列化、标准化。配备、开发移植所需的工具；对于那些用工具转换的项目，采取相应的措施，进行文档化，使任何人都能以相同的顺序开展工作。这样，就不必制作大量的工具，只将有效的工具组合起来，就可以提高效率。