重点1：软件开发方法
要点1：结构化法
1、结构化方法的原则有：
（1）用户至上。
（2）严格区分工作阶段，每阶段有任务与成功。
（3）强调系统开发过程的整体性和全局性。
（4）系统开发过程工程化，文档资料标准化。
（5）自顶向下，逐步分解（求精）。
要点2：原型法
原型法适用于需求不明确的开发。它包含抛弃型原型和进化型原型两种具体的实施方式。
要点3：面向对象方法
面向对象方法有更好的复用性，使用该方法的关键在于建立一个全面、合理、统一的模型。
面向对象方法包含分析、设计、实现三个阶段，它们之间的界限是不明确的。
要点4：面向服务的方法
SO方法有三个主要的抽象级别：操作、服务、业务流程。
SOAD分为三个层次：基础设计层（底层服务构件）、应用结构层（服务之间的接口和服务级协定）和业务组织层（业务流程建模和服务流程编排）。
服务建模：分为服务发现、服务规约和服务实现三个阶段。
要点5：常见的软件开发模型
1、瀑布模型
2、增量模型与螺旋模型
3、构件组装模型
4、统一过程（RU）
5、敏捷方法
重点2：重点软件开发模型
要点1：Scrum
Scrum是一个用于开发和维持复杂产品的框架，是一个增量的、迭代的开发过程。
Scrum主要包括：梳理产品待办事项列表、Sprint计划会议、每日Scrum会议、Sprint评审会议、Sprint回顾会议等五个活动。
要点2：逆向工程
1、实现级：包括程序的抽象语法树、符号表、过程的设计表示。
2、结构级：包括反映程序分量之间相互依赖关系的信息，如调用图、结构图、程序和数据结构。
3、功能级：包括反映程序段功能及程序段之间关系的信息，如数据和控制流模型。
4、领域级：包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息，如实体关系模型。
重点3：需求工程
要点1：需求获取
软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望。
软件需求是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明。
要点2：需求定义
1、严格定义法：
（1）所有需求都能够被预先定义。
（2）开发人员与用户之间能够准确而清晰地交流。
（3）采用图形/文字可以充分体现最终系统。
2、原型法：
（1）并非所有的需求都能在开发前被准确地说明。
（2）项目参加者之间通常都存在交流上的困难。
（3）需要实际的、可供用户参与的系统模型。
（4）有合适的系统开发环境。
（5）反复是完全需要和值得提倡的，需求一旦确定，就应遵从严格的方法。
要点3：需求基线管理
要点4：需求变更控制
需求变更的流程：变更申请、变更评估、变更决策、变更实施、变更验证、基线版本管理。
要点5：DFD
1、DFD中包括以下几个基本元素：
2、数据流图提供一种表现系统高层和低层概念的机制，由顶层数据流图逐级向下分解细化，直至每一个系统交互过程被清楚的描述出来。
要点6：E-R图
1、E-R图包括3个要素：
（1）实体（型）：用矩形框表示，框内标注实体名称。
（2）属性：用椭圆形表示，并用连线与实体连接起来。
（3）实体之间的联系：用菱形框表示，框内标注联系名称，并用连线将菱形框分别与有关实体相连，并在连线上注明联系类型。根据参与联系的两个实体类值之间的对应关系分为一对一（1：1）、一对多（1：n）及多对多（m：n）三种类型。E-R图示例如下所示。
要点7：面向对象基本概念
实体类映射需求中的每个实体，实体类保存需要存储在永久存储体中的信息，例如，在线教育平台系统可以提取出学员类和课程类，他们都属于实体类。
控制类是用于控制用例工作的类，一般是由动宾结构的短语（“动词+名词”或“名词+动词”）转化来的名词，例如，用例“身份验证”可以对应于一个控制类“身份验证器”，它提供了与身份验证相关的所有操作。
边界类用于封装在用例内外流动的信息或数据流。边界类位于系统与外界的交接处，包括所有窗体、报表、打印机和扫描仪等硬件的接口，以及与其他系统的接口。
1、继承与泛化
继承用来说明特殊类（子类）与一般类（父类）的关系，而泛化用来说明一般类与特殊类的关系，也就是一对多的关系。
2、多态与重载
（1）多态（即多种形式）性是指一般类中定义的属性或服务被特殊类继承后，可以具有不同的数据类型或表现出不同的行为，通常是使用重载和改写两项技术来实现的。
（2）重载指同一个函数名有多种实现方式，一般在编译时基于类型签名来区分。
（3）改写发生在继承时，子类重写了父类的方法实现。
要点8：UML4+1视图
“4+1”视图模型从5个不同的视角包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件架构；每一个视图只关心系统的一个侧面，5个视图结合在一起才能反映系统的软件架构的全部内容。
1、逻辑视图
主要支持系统的功能需求，即系统提供给最终用户的服务；在逻辑视图中，系统分解成一系列的功能抽象，这些抽象主要来自问题领域；这种分解不但可以用来进行功能分析，而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。
在面向对象技术中，通过抽象、封装和继承，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图，逻辑视图中使用的风格为面向对象的风格，逻辑视图设计中要注意的主要问题是要保持一个单一的、内聚的对象模型贯穿整个系统。
2、开发视图
也称为模块视图，主要侧重于软件模块的组织和管理；软件可通过程序库或子系统进行组织，这样，对于一个软件系统，就可以由不同的人进行开发。
开发视图要考虑软件内部的需求，如软件开发的容易性、软件的重用和软件的通用性，要充分考虑由于具体开发工具的不同而带来的局限性。
开发视图通过系统输入输出关系的模型图和子系统图来描述，可以在确定了软件包含的所有元素之后描述完整的开发角度，也可以在确定每个元素之前，列出开发视图原则。
3、进程视图
侧重于系统的运行特性，主要关注一些非功能性的需求，例如系统的性能和可用性。
进程视图强调并发性、分布性、系统集成性和容错能力，以及逻辑视图中的主要抽象的进程结构；它也定义逻辑视图中的各个类的操作具体是在哪一个线程中被执行的；进程视图可以描述成多层抽象，每个级别分别关注不同的方面。
4、物理视图
主要考虑如何把软件映射到硬件上，它通常要考虑到解决系统拓扑结构、系统安装、通信等问题。
当软件运行于不同的节点上时，各视图中的构件都直接或间接地对应于系统的不同节点上；因此，从软件到节点的映射要有较高的灵活性，当环境改变时，对系统其他视图的影响最小。
5、场景
可以看作是那些重要系统活动的抽象，它使四个视图有机地联系起来，从某种意义上说，场景是最重要的需求抽象。
在开发架构时，它可以帮助设计者找到架构的构件和它们之间的作用关系；同时，也可以用场景来分析一个特定的视图，或描述不同视图构件间是如何相互作用的。场景可以用文本表示，也可以用图形表示。
逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。对于不同的软件系统来说，侧重的角度也有所不同。例如，对于管理信息系统来说，比较侧重于从逻辑视图和开发视图来描述系统，而对于实时控制系统来说，则比较注重于从进程视图和物理视图来描述系统。
要点9：UML图
1、用例图描述一组用例、参与者及它们之间的关系。
2、用例之间的关系有包含、扩展、泛化。
（1）包含关系：其中这个提取出来的公共用例称为抽象用例，而把原始用例称为基本用例或基础用例系，当可以从两个或两个以上的用例中提取公共行为时，应该使用包含关系来表示它们。
（2）扩展关系：如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例，这样使描述可能更加清晰。
（3）泛化关系：当多个用例共同拥有一种类似的机构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。
3、类图（class diagram）：类图描述一组类、接口、协作和它们之间的关系。
4、对象图（object diagram）：对象图描述一组对象及它们之间的关系。对象图描述了在类图中所建立的事物实例的静态快照。
空心菱形箭头表示聚合关系（aggregation），聚合关系是关联关系的一种，是强的关联关系。聚合关系是整体和个体的关系。
关联关系的两个类处于同一层次上，而聚合关系两个类处于不同的层次，一个是整体，一个是部分。箭头指向整体。
空心三角箭头表示为类与类之间的继承关系，接口与接口之间的继承，类对接口的实现关系，也叫泛化关系。箭头指向父类，如果父类是类，用实线；如果父类是接口，用虚线。
5、类之间的关系
（1）依赖关系（Dependency）
有两个元素X、Y，如果修改元素X的定义可能会引起对另一个元素Y的定义的修改，则称元素Y依赖于元素X。在UML中，使用带箭头的虚线表示依赖关系，带箭头的虚线，指向依赖者。
（2）泛化关系
泛化关系描述了一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系。继承关系是泛化关系的反关系，也就是说子类是从父类中继承的，而父类则是子类的泛化。在UML中，使用带空心箭头的实线表示泛化关系，箭头指向父类。
（3）关联关系
关联表示两个类之间存在某种语义上的联系。关联关系提供了通信的路径，它是所有关系中最通用的、语义最弱的。在UML中，用一条实线来表示关联关系。
（4）聚合关系
聚合是一种特殊形式的关联。聚合表示类之间的关系是整体与部分的关系。在UML中，用一个带空心菱形的实线表示，空心菱形指向的是代表“整体”的类。如果聚合关系中的表示“部分”的类的存在，与表示“整体”的类有着紧密的关系，例如“公司”与“部门”之间的关系，那么就应该使用**“组合”**关系来表示。
在UML中，用带有实心菱形的实线表示，菱形指向的是代表“整体”的类。
聚合关系是指部分与整体的生命周期可以不相同，而组合关系则是指部分与整体的生命周期是相同的。
（5）实现关系
实现关系是用来规定接口和实现接口的类或组件之间的关系的；接口是操作的集合，这些操作用于规定类或组件的服务。在UML中，用一个带空心箭头的虚线表示。
6、顺序图
顺序图用来描述对象之间动态的交互关系，着重体现对象间消息传递的时间顺序。
7、通信图
通信图用于描述相互合作的对象间的交互关系和链接关系。虽然顺序图和通信图都用来描述对象间的交互关系，但侧重点不一样。顺序图着重体现交互的时间顺序，通信图则着重体现交互对象间的静态链接关系。
8、状态图
用来描述一个特定对象的所有可能状态及其引起状态转移的事件。
9、构件图
构件图是面向对象系统的物理方面进行建模要用的两种图之一，它可以有效地显示一组构件，以及它们之间的关系。构件图中通常包括构件、接口及各种关系。
通常构件指的是源代码文件、二进制代码文件和可执行文件等，而构件图就是用来显示编译、链接或执行时构件之间的依赖关系的。
要点10：软件系统建模
重点4：系统设计
要点1：人机界面设计
1、置于用户控制之下
（1）以不强迫用户进入不必要的或不希望的动作的方式来定义交互方式。
（2）提供灵活的交互。
（3）允许用户交互可以被中断和撤销。
（4）当技能级别增加时可以使交互流水化并允许定制交互。
（5）使用户隔离内部技术细节。
（6）设计应允许用户和出现在屏幕上的对象直接交互。
2、减少用户的记忆负担
（1）减少对短期记忆的要求。
（2）建立有意义的缺省。
（3）定义直觉性的捷径。
（4）界面的视觉布局应该基于真实世界的隐喻。
（5）以不断进展的方式揭示信息。
3、保持界面的一致性
（1）允许用户将当前任务放入有意义的语境。
（2）在应用系列内保持一致性。
（3）如过去的交互模型已建立起了用户期望，除非有迫不得已的理由，不要改变它。
要点2：结构化设计
1、结构化设计的原则：抽象化、自顶而下逐步求精、信息隐藏、模块独立。
2、模块的内聚类型通常可以分为7种，根据内聚度从高到低排序，如下表所示。
| 内聚类型 | 描述 |
|---|---|
| 偶然内聚或巧合内聚 | 指一个模块内的各处理元素之间没有任何联系。 |
| 逻辑内聚 | 指模块内执行若干个逻辑上相似的功能，通过参数确定该模块完成哪一个功能 |
| 时间内聚 | 把需要同时执行的动作组合在一起形成的模块 |
| 过程内聚 | 指一个模块完成多个任务，这些任务必须按指定的过程执行 |
| 通信内聚 | 指模块内的所有处理元素都在同一数据结构上操作，或者各处理使用相同的输入数据或产生相同的输出数据 |
| 顺序内聚 | 指一个模块中的各个处理元素都密切相关，且各功能且必须顺序执行，前一个功能元素的输出就是下一个功能的输入 |
| 功能内聚 | 指模块内的所有元素共同作用完成一个功能，缺一不可 |
3、模块的耦合性类型通常也分为7种，根据耦合度从低到高排序，如下表所示。
| 耦合类型 | 说明 |
|---|---|
| 无直接耦合 | 无直接联系，互不依赖 |
| 数据耦合 | 借助参数表传递简单数据 |
| 标记耦合 | 一个数据结构的一部分借助于模块接口传递 |
| 控制耦合 | 传递的是控制变量，例如开关、标志等 |
| 外部耦合 | 与软件之外的环境有关，比如I/O环境 |
| 公共耦合 | 多个模块引用的是同一个全局数据区，比如公共数据环境中的数据 |
| 内容耦合 | 一个模块访问另一个模块的内部数据；一个模块通过特殊入口进入另一个模块内部；两个模块有一部分程序代码重叠；一个模块有多个入口 |
4、除了满足以上两大基本原则之外，通常在模块分解时还需要注意：
（1）保持模块的大小适中，尽可能减少调用的深度，直接调用该模块的个数应该尽量大，但调用其他模块的个数则不宜过大。
（2）保证模块是单入口、单出口的。
（3）模块的作用域应该在控制域之内。
（4）功能应该是可预测的。
要点3：面向对象设计的基本过程和原则
1、基本过程
2、设计原则
（1）单一职责原则：设计目的单一的类。
（2）开放-封闭原则：对扩展开放，对修改关闭。
（3）里氏替换原则：子类可以替换父类。
（4）依赖倒置原则：要依赖于抽象，而不是具体实现；针对接口编程，不要针对实现编程。
（5）接口隔离原则：使用多个专门的接口比使用单一的总接口要好。
（6）组合重用原则：要尽量使用组合，而不是继承关系达到重用目的。
（7）迪米特原则（最少知识原则）：一个对象应当对其他对象有尽可能少的了解。
要点4：设计模式的概念
架构模式：软件设计中的高层决策，例如C/S结构；架构模式反映了开发软件系统过程中所作的基本设计决策。
设计模式：主要关注软件系统的设计，与具体的实现语言无关。
惯用法：是最低层的模式，关注软件系统的设计与实现，实现时通过某种特定的程序设计语言来描述构件之间的关系，例如引用-计数器就是C++语言中的一种惯用法。
要点5：面向对象设计模式
1、创建型模式
| 设计模式名称 | 简要说明 | 速记关键词 |
|---|---|---|
| 工厂方法 Factory Method |
定义一个创建对象的接口，但由子类决定需要实例化哪一个类。 工厂方法使得子类实例化的过程推迟。 |
动态生成对象 |
| 抽象工厂模式 Abstract Factory |
提供一个接口，可以创建一系列相关或相互依赖的对象而无需指定它们具体的类 | 生成一系列对象 |
| 构造器模式 Builder |
将一个复杂类的表示与其构造相分离，使得相同的构建过程能够得出不同的表示 | 复杂对象构造 |
| 原型模式 Prototype |
用原型实例指定创建对象的类型，并且通过拷贝这个原型来创建新的对象 | 克隆对象 |
| 单例模式 Singleton |
保证一个类只有一个实例并提供一个访问它的全局访问点 | 单一全局实例 |
2、结构型模式
| 设计模式名称 | 简要说明 | 速记关键词 |
|---|---|---|
| 适配器模式 Adapter |
将一个类的接口转换成用户希望得到的另一个接口 它使原本不相容的接口得以协同工作 |
转换接口 |
| 桥接模式 Bridge |
将类的抽象部分和它的实现部分分离开来，使它们可以独立地变化 | 继承树拆分 |
| 组合模式 Composite |
将对象组合成树型结构以表示“整体-部分”的层次结构，使得用户对单个对象和组合对象的使用具有一致性 | 树形目录结构 |
| 装饰模式 Decorator |
动态地给一个对象添加一些额外的职责 它提供了用子类扩展功能的一个灵活的替代，比派生一个子类更加灵活 |
动态附加职责 |
| 外观模式 Façade |
定义一个高层接口，为子系统中的一组接口提供一个一致的门面，从而简化了该子系统的使用 | 对外统一接口 |
| 享元模式 Flyweight |
提供支持大量细粒度对象共享的有效方法 | 汉字编码 |
| 代理模式 Proxy |
为其他对象提供一种代理以控制这个对象的访问 | 快捷方式 |
3、行为型模式
| 设计模式名称 | 简要说明 | 速记关键词 |
|---|---|---|
| 责任链模式 Chain of Responsibility |
通过给多个对象处理请求的机会减少请求的发送者与接收者之间的耦合；将接收对象链接起来，在链中传递请求，直到有一个对象处理这个请求 | 传递职责 |
| 命令模式 Command |
将一个请求封装为一个对象，从而可用不同的请求对客户进行参数化，将请求排队或记录请求日志，支持可撤销的操作 | 日志记录 |
| 解释器模式 Interpreter |
给定一种语言，定义它的文法表示并定义一个解释器，用以解释使用这种文法的语句 | 虚拟机的机制 |
| 迭代器模式 Iterator |
提供一种方法来顺序访问一个聚合对象中的各个元素，而不需要暴露该对象的内部表示 | 数据集 |
| 中介者模式 Mediator |
用一个中介对象来封装一系列对象的交互；它使各个对象不需要显示地相互调用，从而达到低耦合，还可以独立地改变对象间的交互 | 不直接引用 |
| 备忘录模式 Memento |
在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，从而可以在以后将该对象恢复到原先保存的状态 | 游戏存档 |
| 观察者模式 Observer |
定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并自动更新 | 联动 |
| 状态模式 State |
允许一个对象在其内部状态改变时改变它的行为 | 状态变成类 |
| 策略模式 Strategy |
定义一系列算法，把它们一个个封装起来并且使它们之间可相互替换，从而让算法可以独立于使用它的用户而变化 | 多方案切换 |
| 模版方法模式 Template Method |
定义一个操作中的算法骨架，而将一些步骤延迟到子类中，使得子类可以不改变一个算法的结构即可重新定义算法的某些特定步骤 | 框架 |
| 访问者模式 Visitor |
表示一个作用域某对象结构中的各元素的操作，使得在不改变各元素的类的前提下定义作用于这些元素的新操作 | 数据与操作分离 |
重点5：软件测试与调试
要点1：测试的原则
- 尽早、不断的进行测试。
- 程序员避免测试自己设计的程序。
- 既要选择有效、合理的数据，也要选择无效、不合理的数据。
- 修改后应进行回归测试。
- 尚未发现的错误数量与该程序员已发现错误数成正比。
要点2：测试的类型
- 动态测试：黑盒测试、白盒测试、灰盒测试。
- 静态测试：桌前检查、代码审查、代码走查。
要点3：测试用例设计
1、黑盒测试：等价类划分、边界值分析、错误推测、因果图。
2、白盒测试：基本路径测试、循环覆盖测试、逻辑覆盖测试。
3、循环覆盖测试的方法：语句覆盖、判定覆盖、条件覆盖、条件判定覆盖、修正的条件判断覆盖、条件组合覆盖、点覆盖、边覆盖、路径覆盖。
要点4：测试阶段
1、单元测试：函数、功能模块的测试；确认模块功能、性能、接口等。
2、集成测试：模块间的接口测试；分为一次性组装和增量式组装，其中增量式组装分为自顶向下、自底向上和混合式。
不同的集成方法对于被测试的模块需要使用不同的辅助模块。在自顶向下的测试中需要借助于桩模块；在自底向上的测试中需要借助于驱动模块。
3、确认测试：验证软件与需求的一致性；包括内部确认测试、Alpha测试、Beta测试和验收测试。
4、系统测试：在真实环境下，验证完整的软件配置项能否和系统正确连接；包括恢复测试、安全性测试、压力测试、性能测试（负载、强度、容量）、可靠性测试、可用性测试、可维护性测试、安装测试。
要点5：面向对象的测试
1、算法层（单元测试）：包括等价类划分测试、组合功能测试（基于判定表的测试）、递归函数测试和多态消息测试。
2、类层（模块测试）：包括不变式边界测试、模态类测试和非模态类测试。
3、模块层/类树层（集成测试）：包括多态服务测试和展平测试。
4、系统层（系统测试）。
要点6：软件调试
1、软件调试方法
（1）蛮力法：主要思想是“通过计算机找错”，低效并且耗时。
（2）回溯法：从出错处人工沿控制流程往回追踪，直至发现出错的根源；复杂程序由于回溯路径多，难以实施。
（3）原因排除法：主要思想是演绎和归纳，用二分法实现。
2、软件调试与测试的区别
（1）测试的目的是找出存在的错误，而调试的目的是定位错误并修改程序以修正错误。
（2）调试是测试之后的活动，测试和调试在目标、方法和思路上都有不同。
（3）测试从一个已知的条件开始，使用预先定义的过程，有预知的结果；调试从一个未知的条件开始，结束的过程不可预计。
（4）测试过程可以事先设计，进度可以事先确定；调试不能描述过程和持续时间。
重点6：系统运行与软件维护
要点1：遗留系统演化策略
1、遗留系统的特点：
（1）虽然能实现重要业务的管理，但不能完全满足要求。
（2）一般只涉及业务流程电子化和企业管理，但很少涉及经营决策。
（3）系统性能落后，采用的技术已经过时。
（4）维护困难。
（5）没有使用现代工程方法开发和管理，文档缺失。
2、遗留系统评价方法：
本文的评价方法包括度量系统技术水准、商业价值和与之关联的组织特征，其结果作为选择处理策略的基础。
商业价值评价的目标是判断遗留系统对企业的重要性。按照商业评价分值和技术水平分值的情况，把评价结果分为四种类型。
3、遗留系统的演化策略
把对遗留系统的评价结果分列在的四个象限内，对处在不同象限的遗留系统采取不同的演化策略：
（1）淘汰策略
第3象限为低水平、低价值区，即遗留系统的技术含量较低，且具有较低的商业价值。对这种遗留系统的演化策略为淘汰，即全面重新开发新的系统以代替遗留系统。
（2）继承策略
第4象限为低水平、高价值区，即遗留系统的技术含量较低，可满足企业运作的功能或性能要求，但具有较高的商业价值，目前企业业务对该系统仍有很大的依赖性。
（3）改造策略
第1象限为高水平、高价值区，即遗留系统的技术含量较高，本身还有较大的生命力，且具有较高的商业价值，基本上能够满足企业业务运作和决策支持的要求；这种系统可能建成的时间还很短，对这种遗留系统的演化策略为改造。
（4）集成策略
第2象限为高水平、低价值区，即遗留系统的技术含量较高，但其商业价值较低，可能只完成某个部门（或子公司）的业务管理；这种系统在各自的局部领域里工作良好，但从企业全局来看，多个这样的系统，他们各自基于不同的平台，不同的数据模型，无法互联互通，数据还不一致，这就是很严重的问题了。
要点2：新旧系统过渡方案
使用不同的系统过渡方案意味着不同的风险，不同的费用及不同的复杂度。
1、直接过渡
设计者主要权衡当新系统失败时，系统停止运行或者勉强运行给客户带来的损失有多大。由于这种过渡方式简单而费用低廉，对于可以容忍停机一段时间的系统的实践者，可以采用这种方式。
2、并行过渡
并行过渡显然比直接过渡要消耗更多的资源：现有的硬件资源必须保证能同时跑两套系统，这常常意味着增加服务器和额外的存储空间，需要增加人员来同时使用两套系统，或者增加现有员工的工作量，让他们同时操作两套系统。这种方式同时也增加了管理和后勤保障的复杂度。
据统计，并行过渡时期的开销是旧系统单独运行时的2.5～3倍；设计者还会发现有些系统无法使用并行过渡的方式，主要是客户没有足够的资源来维持两个系统同时运行，另外一种情况是新、旧系统差别太大，旧系统的数据无法为新系统采用。
当客户无法使用并行过渡，又想尽可能地减少风险，设计者可以使用部分并行过渡的策略，使并行的开销减少到客户能够接受的范围内。
3、阶段过渡
通常在系统非常复杂、过于庞大以至于无法一次性进行过渡时采用，也适用于分阶段开发的系统。设计者需要设计一系列步骤和过程来完成整个系统的过渡，这种过渡方式和系统的复杂程度相关，随着系统的不同往往有很大的不同。和并行过渡一样，阶段过渡也能够减少风险，显然局部的失败要比全体的失败更容易接受，带来的损失更小。阶段过渡也带来了复杂性，有时候比并行过渡更加复杂。
要点3：数据转换与迁移
要点4：系统维护
1、正确性维护：指改正在系统开发阶段已经发生而系统测试阶段尚未发现的错误。
2、适应性维护：指使应用软件适应信息技术变化和管理需求变化而进行的修改。企业的外部市场环境和管理需求的不断变化也使得各级管理人员不断提出新信息需求。
3、完善性维护：扩充功能和改善性而进行的修改。对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征。
4、预防性维护：为了改进应用软件的可靠性和可维护性，为了适应未来的软硬件环境的变化，应主动增加预防性的新的功能，以使用系统适应各类变化而不被淘汰，如将专用报表功能改成通用报表功能，以适应将来报表格式的变化。