软件开发方法
软件开发方法***（方法论）
结构化法(早期、C语言、面向过程)
用户至上
严格区分工作阶段
强调系统开发过程的整体性和全局性
系统开发过程工化、文档资料化
自项向下、逐步分解（求精、输入、输出很明确、设计做到极致）
应变能力比较差。灵活度不高、流程容易写死。面向对象方法(C++、JAVA、VB、dephi)
在计算机中构建一个相对真实的体系
更好的复用
关键在于建立一个全面、合理、统一的模型。
分析、设计、实现三个阶段、界限不明确。面向服务方法
在面向对象的基础上，进行再次封装。
SO方法有三个主要的抽象级别：操作（方法）、服务、业务流程。
SOAD分为三个层次：基础设计层（底层服务构件）、应用结构层（服务之间的接口和服务协定）和型业务组织层（业务流程建模和服务流程编排）
服务建模：分为服务发现、服务规约和服务实现三个阶段。原型法
用于分析阶段（Demo）Axure，静态UI
适用于需求不明确的开发
包括抛弃型原型和进化型模型。
软件开发模型（****）
瀑布模型
典型结构化开发方法，适合于需求明确的项目，通常与原型模型一起使用，一次性完成。
分为定义阶段、开发阶段、维护阶段。
软件计划、需求分析、软件设计、程序编码、软件测试、运行维护。
向下进行、向上反馈、逐层依赖。各阶段产出物相对明确。螺旋模型
分为制订计划、风险分析、实施工程、客户评估四个象限，从中心向外扩充。
用到了迭代思想，螺旋推进，每次开发出一个原型版本，由用户确认。最终完成目标。适合于大项目。原型模型
用于需求不明确的，避免用户阅读需求文档障碍。
敏捷开发方法
比较新的方法，自适应开发，水晶方法，特性驱动开发，极限编程
适合小型项目的开发，不是单一的模型，是一个混合的模型。统一过程/统一开发方法（RUP、UP）
在基于构件的开发方法发展而来。特点：用例驱动，以架构为中心，迭代和增量
分为初始（系统分析）、细化（完成 架构设计）、构建（软件的组装与测试）、交付（制作发布版本）四个阶段。增量模型
将系统分成几块，将各功能块分别开发，最后组装。每一个增量均发布一个可操作的产品。
构件组装模型（基于构件的开发方法，CBSD）
需求定义、软件架构设计、构件库建立、应用软件构建、测试和发布。
在构件库建立阶段，要完成构件的标准定义，以及构件库的管理功能。构件标准发（CORBA，COM/DCOM,EJB)。此阶段是此模型的重中之重。
只是负责构件的组装，开发过，稳定性好，节约成本。构件是基于标准的，互相通用，CoRBA，COM/DCOM，EJB
构建构件库需要很长的时间
构建是个广义概念，微服务，单个的服务就是一个构件，微服务就是标准更高的模型V模型
强调测试贯穿始终的模型，测试迟早做，提前做，将一系列的测试计划做在前面，将测试用例
下行：需求分析、概要设计、详细设计、编码
上行：验收测试、系统测试、集成测试、单元测试
将测试尽早做、提前做，测试用例及时跟上，发现问题，解决问题。在需要分析阶段做（验收测试、系统测试），在概要设计时做集成测试，在详细设计阶段进行单元测试快速应用开发（RAD）
常与瀑布模型和构件库开发一起使用
业务建模、数据建模、过程建模、应用生成、测试与交付喷泉模型（面向对象的开发模型）
需求工程
定义
软件需求是指用户在功能、行为、性能、设计约束等方面对系统的期望软件需求是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明
需求管理(管理维度)
变更控制
版本控制
需求跟踪：客户提出的需求，记录需求被实现的过程，有自向跟踪，反向跟踪。用户原始需求->软件需求->下游工作产品
需求状跟踪：被建议->被批准->被实现->被验证->被交付被拒绝->被抛弃需求开发(技术维度)
需要需求管理的支持
需求分析
需求定义
需求验证–>需求基线
需求获取
收集资料
联合讨论
用户访谈
现场观摩
参加业务实践
阅读历史文档
抽样调查（节省成本的一种方法，经常与其它方法相结合）
需求分析
- 需求分类
技术维度：
业务需求
用户需求
系统需求
管理维度：
基本需求，用户明确提出的
期望需求，隐含的需求，不用讲就应该去做的，比较难把握，分歧多。
兴奋需求，最值得注意，客户没提出要做，也不觉得你该做，但是你做了，这个不好，客户不会付费，属镀金性。
方法
SA结构化分析
- 功能模型使用数据流图建模(DFD)，谁会用户这个系统，每个角色的一些操作，可数据交换内容。涉及：数据流，加工，数据存储，外部实体，等，逐层细化。
- 数据模型使用ER图建模
- 行为模型使用状态转换图展现
- 数据字典，在需求分析阶段，来完成为以上分析过程提供参考数据。
- 数据元素
- 数据结构
- 数据流
- 数据存储
- 加工逻辑
- 外部实体
面向对象分析OOA
概念，以选择题形式出现
对象，对应生活中的人物，三要素：属性、方法、ID
类
- 实体类：映射需求中的每个实体，保存需要存储在永久存储体中的信息
- 控制类：用于控制用例中工作的类，一般由动宾结构短语转化来的名词。『身份验证』可以对应一个控制类『身份验证器』，它提供了与身份验证相关的所有操作
- 边界类：用于封装在用例内、外流动的信息或数据流。边界类位于系统与外界的交接处，包括所有窗体、报表、打印机和扫描仪等硬件的接口，以及与其他系统的接口。
抽象-抽取共性的过程
封装-类成员的私有数据外部不可直接访问等，通过提供的外部接口访问，方便问题定位及分析
继承和泛化-父子关系，继承是一种复用的机制。子类继承自父类，父是是子类的泛化
多态-对父类功能的重写
接口-特殊的类，只有方法的定义，没有方法的实现，约定方法的规范
消息-对象之间传递信息的机制，异步
组件-即构件，颗粒度比类大
模式和复用-模式就是为复用，解决某种问题常用的手段，称之为模式。
UML组成
概念：统一建模语言，主要用于需求分析、设计和软件设计阶段，用于模型制作，与开发技术无关
构造块
事务
结果构事物：最静态的部分，包括：类、接口、协作、用例、活动类、构件和节点
行为事物：代表时间和空间的动作。包括：消息、动作次序、连接
分组事物：看成盒子。如包，构件
注释事物：UML模型的解释部分。描述和说明、标注模型中的元素关系
图规则
范围：给一个名字以特定含义的语境
可见性：怎么使用中看见名字
完整性：事物如何创建、一致地相互联系
执行：运行或模拟动态模型的含义是什么公共机制
规格说明：事物语义的细节描述，它是模型的真正核心
修饰：通过修饰来表达更多的信息
公共分类：类与对象、接口的实现
扩展机制：允许添加新的规则
UML图
- 静态图（结构图）
类图：一组类、接口、协作和它们之间的关系，相当重要
对象图：一组对象及它们之间的关系。对象图描述了在类图中所建立的事物实例的静态快照。
构件图：一个封装的类和它的接口
部署图：软硬件之间的映射
制品图：系统的物理结构
包图：由模型本身分解而成的组织单元，以及它们之间的依赖关系
组合结构图
动态图（行为图）
用例图：系统与外部参与者的交互
概念：用例图描述一组用例、参与者及它们之间的关系
用户角度描述系统功能
能与者是外部触发因素（包括用户、组织、外部系统、时间）
用例是功能单元。关系
包含关系：其中这个提取出来的公共用例称为抽象用例，而把原始用例称为基本用例或基础用例系：当可以从两个或两个以上的用例中提取公共行为时，应该使用包含关系来表示它们。A–(include)–>B(使用关系，之前uses)
扩展关系：如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例，这样使描述可能更加清晰。A<–(Extern)–B
泛化关系：当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。—–|>。子类可以替换父类用户建模流程
识别参与者（必须）
合并需求获得用例（必须）
细化用例描述（必须）
调整用户模型（可选），通过以下关系进行调整，答题时也需要参考关系来完成:包含、扩展、泛化。
顺序图：强调按时间顺
顺序图是一种交互图，它强调对象之间的消息发送顺序，同时显示对象之间的交互。
虚线代表生命线，框里代表一个对象
从上往下看
调用的方法称为消息
虚线和实线不胜感激同步或异步通信图：协作图
Communication Diagram。通信图也是一种交互图，它强调收发消息的对象或参与者的结构组织。顺序图和通信图表达了类似的基本概念，但它们所强调的概念不同，顺序图强调的是时序，通信图强调的是对象之间的组织结构(关系)。
节点中为对象，连接中间的是消息
虚线表示的是回调定时图：强调实际时间
如：洗衣机工作过程的描述，以时间为X轴，Y轴表示工作状态
状态图：状态的转换和变迁
StateDiagram，状态图描述一个状态机，它由状态、转移、事件和活动组成。状态图张出了对象的动态视图。它对于接口、类或协作的行为建模尤为重要，而且它强调事件导致的对象行为，这非常有助于对反应式系统建模。
节点是对象的状态，连线表示状态的变更，连线上的注释为状态变化的条件
命名要一致，无歧义
经常出现的是填空题型
示例：在订单处理的过程中，会员可以点击『取消订单』取消该订单。如果支付失败，该订单将被标记为挂起状态，可后续重新支付，如果挂起超时30分钟未支付，系统将自动取消该订单。订单支付成功后，系统判断订单类型：（1）对于常规订单，标记为备货状态，订单信息发送到货运部，完成打包后交付快递发货；（2）对于定制订单，会自动进入定制状态，定制完成后交付快递发货。会员在系统中点击”收货”按钮变为收货状态，结束整个订单的处理流程。活动图：类似程序的流程图，并行行为
活动图将进程或其他计算结构展示为计算内部上步步的控制流和数据流。活动图专注于系统的动态视图。它对系统的功能建模和业务流程建模特别重要，并强调对象间的控制流程
用粗线表示并行（并发）
节点是系统的动作
更科学一点的叫泳道式活动图，以操作对象为标准，将每个操作者的节点分开交互概览图
UML4+1
- 与架构设计的4+1一一对应
- 从不同角度分析系统的图
系统分析人员、设计人员:逻辑视图（logic view），通过类与对象来表现，主要表现系统的功能
程序员:实现视图(implementation view)，通过物理代码和组件表现
系统集成人员:进程视图(process view)，通过线程、进程、并发表现
系统和网络工程师 部署视图(deployment view)，表现软件到硬件的映射
最终用户4+1中的1，与其它4个都有相关性 用例视图(user-case view)，需求分析模型
2014年真题：
UML对系统架构的定义是系统的组织结构，包括系统分解的组成部分，以及它们的关联性、交互机制和指导原则等提供系统设计的信息。具体来说，就是指以下5个系统视图：
①逻辑视图。逻辑视图也称为设计视图，它表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集。
②进程视图。进程视图是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描述了并发与同步结构。
③实现视图。实现视图对组成基于系统的物理代码的文件和构件进行建模。
④部署视图。部署视图把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构。
⑤用例视图。用例视图是最基本的需求分析模型。
UML 关系
类之间的关系
- 依赖关系：一个事物发生变化，影响另一个事物(虚线）——-|>实心箭头
- 关联关系：描述一组链，链是对象之间的连接（实线———-）
聚合关系：整体与部分生命周期不同。（实线）——<>空心菱形
组合关系：整体与部分生命周期相同。（实线）——<> 实心菱形
举例：书籍（整体）列表中包含书籍（部分）菱形代表整体（汽车和轮子）聚合关系（公司和公司的部门）组合关系 - 泛化关系：特殊（子类）/一般（父类）关系。（实线）——-|>空心箭头
- 实现关系：接口与类之间的关系。（虚线）———|>空心箭头
类与对象中的关系的表示
- 1：表示一个集合中的一个对象对应另一个集合中的一个对象
- 0..*：表示一个集合中的一个对象对应另一个集合中的0个或多个对象
- 1..*：表示一个集合中的一个对象对就另一个集合中的一个或多个对象
- *：表示一个集合中的一个对象对应另一个集合中的多个对象
需求开发
需求定义
会生成SRS，需求规格说明书
严格定义法
所有需求都能够被预先定义开发人员与用户之间能够准确而清晰地交流采用图形/文字可以充分体现最终系统
用结构化和自然语言编写文本型文档,建立图形化模型,编写形式化规格说明原型法
并非所有的需求都能在开发前被准确地说明
项目参加者之间通常都存在交流上的困难
需要实际的、可供用户参与的系统模型
有万古天帝人系统开发环境
反复是完全需要和值得提倡的，需求一旦确定，
就应遵从严格的方法
- 需求验证
- 需求评审（SRS）需求测试（通过场景的模拟，确定开发的系统是否满足将来的需求）–>正式评审，非正式评审–>用户签字确认,也是将来的验收标准之一–>生成需求基线，什么是需求基线?
- 甲方、乙方、开发方负责人
需求管理
- 定义需求基线
状态：被建议、被批准（被拒绝）、被实现、被验证、被交付。用配置管理工具来完成管理，禅道软件
- 需求跟踪
- 用户的原始需求<->软件需求<->下游工作产品（代码模块，测试用例）
- 正反双向跟踪，需求跟踪矩阵。
1、用户原始需求与用例（功能）
2、功能（用例）与设计上的元素（功能点，设计元素，代码模块，测试用例）
需求变更
- 流程：变更申请、变更评估、变更决策、变更实施、变更验证、沟通存档等步骤。
- 工作状态->评审状态->受控状态
- 基线已经定义好之后的变更，需要走变更流程
软件系统建模
建模方法
UML中各种图都是用来建模的
- 结构化建模方法
结构化建模方法是以过程为中心的技术，可用于分析一个现有的系统以及定义新系统的业务需求。结构化建模方法所绘制的模型称为数据流图（DFD）。对于流程较为稳定的系统可考虑结构化建模方法。- 信息工程建模方法（或数据库库建模方法）
信息工程建模方法是一种以数据为中心，但过程敏感的技术，它强调在分析和研究过程需求之前，首先研究和分析数据需求。信息工程建模方法所创建的模型被称为实体联系图（ERD）。主要用于数据建模。- 面向对象的建模方法
面向对象建模方法将“数据”和“过程”集成到被称为“对象”的结构中，消除了数据和过程的人为分离现象。面向对象建模方法所创建的模型被称为对象模型。随着面向对象技术的不断发展和应用，形成了面向对象的建模标准，即UML（统一建模语言）。UML定义了几种不同类型的模型图，这些模型图以对象的形式共建一个信息系统或应用系统。目前比较常用的建模方法。
例题
论软件系统建模方法及应用
软件系统建模（Software System Modeling)是软件开发中的重要环节，通过构建软件系统模型可以帮助系统开发人员理解系统、抽取业务过程和管理系统的复杂性，也可以方便各类人员之间的交流。软件系统建模是在系统需求分析和系统实现之间架起一座桥梁，系统开发人员按照软件系统模型
开发出符合设计目标的软件系统，并基于该模型进行软件的维护和改进。
请围绕“论软件系统建模方法及应用”论题，依次从以下三个方面进行论述：
1、概要叙述你参与的软件系统开发项目以及你所担任的主要工作。
2、说明软件系统开发中常用的建模方法有哪几类？阐述每种方法的特点及其适用范围
3、详细说明你所参与的软件系统开发项目中，采用了哪些软件系统建模方法，具体实施效果如何？
系统设计
人机界面设计（**）
- 置于用户控制之下
- 减少用户的记忆负担
- 保持界面的一致性
结构化设计（**）
- 概要设计详细设计（模块内）
- 内聚
- 耦合
面向对象设计（*）（延续了分析模型而来）
基本过程
设计原则
单一职责原则
开放-封闭原则
李氏替换原则
依赖倒置原则
接口隔离原则
组合重用原则
迪米特原则设计模式的概念
架构模式。针对高层：软件设计中的高层决策，例如C/S结构就属于架构模式，架构模式反映了开发软件系统过程中所有的基本设计决策
设计模式。针对中层：主要关注软件系统的设计，与具体的实现语言无关
惯用法。是最低层的模式，关注软件系统的设计与实现，实现时通过某种特定的程序设计语言来描述构件与构件之间的关系。每种编程语言都有它自己特定的模式，即语言的惯用法。例如引用-计数就是C++语言的一种惯用法。
注：模式就是套路，是解决问题的一种方案
设计模式的分类
考查点：
设计模式三种类型定位
设计模式分类
设计模式应用场景及特点，考试时经常出现，往
往结合设计模式分类出现
以下模式中无特别说明，即仅为对象模式创建型模式：创建对象
- 工厂方法（Factory）模式
动态生产对象。定义一个创建对象的接口，但由子类决定需要实例化哪一个类。工厂方法使得子类实例化的过程推迟
- 抽象工厂(Abstract Factory)模式
生产系列对象，提供一个接口，可以创建一系列相关或相互依赖的对象，而无需指定他们的具体的类，一个抽象工厂中包含多个对象工厂，使用抽象工厂前，需要先指定工厂。
比如通过数据工厂拿到针对特定数据库的数据库连接 - 原型（模型Prototype）
克隆对象，用原型实例指定创建对象的类型，并且通过拷贝这个原型来创建新的对象。
- 单例(Singleton)模式
保证一个类只有一个实例，并提供一个访问他的全局访问点
- 构建器(Builder)模式
复杂对象的构造，将一个复杂类的表示与其构造相分离，使得相同的构建过程能够得出不同的表示
举例：1初始化人物、2创建武器、3创建战袍、4创建鞋子……
- 工厂方法（Factory）模式
结构型模式：更大的结构
- 适配器模式(Adapter)
转换接口，将一个类的接口转换成用户希望得到的另一种接口。它使原本不相容的接口得以协同工作。
如：我们已经有了接口，但使用时参数的传递不是很匹配，这时可以用转接方法来实现。生活中的电源适配器即是这个接口，可以通过电源适配器将220V 转换为特定设备使用 - 桥接模式(Bridge)
继承树的拆分，将类的抽象部分和它的实现部分分离开来，使它们可以独立的变化。使用组合方式，将不同的特性引用过来。网站的类型–（bridge）–配色文案。变化的条件比较多时，可以灵活组合。
- 组合模式(Composite)
树形目录结构，将对象组合成树型结构以表示『整体-部分』的层次结构，使得用户对单个对象和组合对象的使用具有一致性。
- 装饰模式(Decorator)
动态附加职责，动态地给一个对象添加额外的职责。它提供了用子类扩展功能的一个灵活替代，比派生一个子类更加灵活。
比如我们喝咖啡时可以加糖，还可以加奶。 - 外观模式(Facade)
对外统一接口。定义一个高层接口，为子系统中的一组接口提供一个一致的外观，从而简化该子系统的使用。通过一个接口，实现多系统联动。
- 享元模式(Flyweight)
例如汉字编码。提供支持大量细粒度对象共享的有效方法。
- 代理模式(Proxy)
快捷方式，为其它对象提供一种代理以控制这个对象的访问。A访问B，A也可以访问B的影子（快捷方式，引用），是一种映射方式访问。不直接访问。
- 适配器模式(Adapter)
行为型模式：交互及职责
- 职责链模式(Chain of Responsibility)
传递职责。通过给多个对象处理请求的机会，减少请求的发送者与接收者之间的耦合。将接收对象链接起来，在链中传递请求，直到有一个对象处理这个请求。审批流程
- 命令模式(Command)
日志记录，可撤销。将一个请求封装为一个对象，从而可用不同的请求对客户进行参数化，将请求排队可记录请求日志，支持可撤销的操作。关键字就是可撤销。与备忘录模式不好区分
- 解释器模式(Interpreter)
虚拟机的机制，给定一种语言，定义它的文法表示，并定义一个解释该解释器用来根据文法表示来解释语言中的句子。关键字是自定义。SQL，JAVA等代码的解释器。自定义，更加灵活。工作流引擎。
- 迭代模式(Iterator)
数据集。提供一种方法来顺序访问一个聚合对象中的各个元素，而不需要暴露该对象的内部表示
- 中介者模式(Mediator)
不直接访问，用一个中介对象来封装一系列的对象交互。它使各对象不需要显示的相互调用，从而达到低耦合，还可以独立地改变对象间的交互。将网关结构更改为星型结构。解决结构上的问题。数据的路由转发
- 备忘录模式(Memento)
游戏存档。在不破坏封装性的前提下，捕获一个对象内部的状态，并在该对象之外保存这个状态，从而可以在以后将该对象恢复到原先保存的状态。快照，版本控制
- 观察者模式(Observer)
联动。订阅发布模式。定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知，并自动更新。Excel的单元格计算….呵呵。触发器的思想
- 状态模式(State)
状态变成类。允许一个对象在其内部状态改变时改变它的行为。客房根据不同的入住情况决定了自己所提供的功能。
- 策略模式(Strategy)
多文案切换。定义一系列的算法，把它们一个个封装起来，并且使它们之间可以互相替换，从而让算法可以独立于使用它们的用户而变化。商场的促销规则，根据用户的性质，花费等计算优惠方法的选择。
- 模板方法模式(Template Method)
框架。定义一个操作的的算法框架，而将一些步骤延迟到子类中，使得子类可以不改变一个算法的结构即可重新定义算法的某些特定步骤。
- 访问模式(Visitor)
数据与操作分离。表示一个作用于某对象结构中的各元素的操作，使得在不改变各元素的类的前提下定义作用于这些远程的新操作。
*
- 职责链模式(Chain of Responsibility)
软件测试
测试方法
尽早、不断的进行测试。
程序员避免测试自己设计的程序。
既要选择有效、合理的数据、也要选择无效、不合理的数据。修改后应进行回归测试，修改一个BUG，可能会引入新的BUG。尚未发现的错误数量与该程序已经发现的错误数成正比。
测试类型
静态测试，手工，不依赖计算机
桌前检查
代码审查
代码走看动态测试
黑盒测试
看不到模块内部结构，功能测试
等价类划分，选择测试用户时选择不同的测试用例
边界值分析
错误推测
因果图白盒测试
看得到程序内部结构，设计测试用例
基本路径测试
循环覆盖测试
逻辑覆盖测试语句覆盖
判定覆盖
条件覆盖
条件判定覆盖
修正的条件判定覆盖
条件组合覆盖
点覆盖
边覆盖
路径覆盖
- 灰盒测试=白+黑
测试阶段
单元测试
测试模块内部的功能：模块测试，模块功能，性能，接口等。
集成测试
模块间的接口
一次性组装
增量是组装，测试的更加精准自项向下
自底向上
混合式确认测试
验证软件需求的一致性，用户参与
内部确认测试
Alpha测试，针对产品的测试，在开发环境由用户做的测试。内测
Beta测试，针对产品的测试，QQ2019Beta版，在用户环境，由用户进行的测试，后台发送错误报告
验收测试系统测试
真实环境下，验证完整的软件配置项能否和系统正确连接，联调测试
恢复测试
安全性测试
压力测试
性能测试
负载测试
强度测试，降低系统资源的情况
容量测试，并发数等。
可靠性测试
可用性测试
可维护性测试
安装测试
- 回归性测试
测试软件变更后，变更部分对变更需求的符合度。
面向对象的测试
- 算法层（单元测试）
包括等价类的划分测试，组合功能测试（基于判定表的测试）、递归函数测试和多态消息测试
- 类型（模块测试）
包括不变式边界测试，模态类测试和非模态类测试
- 模板层/类树层（集成测试）
包括多态服务测试和展平测试
- 系统层（系统测试）
软件调试
软件的调试方法
蛮力法：主要思想是『通过计算机找错』，低效耗时
回溯法：从出错处人工控制流程往回追踪，直至发现错误根源。复杂程序由于回溯路径多，难以实施（反向）
原因排除法：主要思想是演绎和归纳，用二分法实现（正向）软件调试与测试的区别
测试的目的是找出存在的问题，面调试的目的是定位错误并修改程序以修正错误。
调试是测试后的活动，测试和调试在目标、方式上和思路上都有所不同。
测试从已经的条件开始，使用预定义过程，有预知的结果；调试从未知的条件开始，结束的
过程不可预计。
测试过程可以事先设计，进度可以事先确定；调试不能描述过程或持续时间。
系统运行与软件维护
系统转换计划
遗留系统的演化策略
技术水平和业务价值
- 高水平、高价值，进行改造
- 高水平、低价值，集成
- 低水平、高价值，继承
- 低水平、低价值，淘汰
淘汰策略
遗留系统的技术含量较低，且具有较低的业务价值。对遗留系统的完全淘汰是企业资源的根本浪费,系统分析师应该善于“变废为宝”，通过对遗留系统功能的理解和借鉴，可以帮助新系统的设计，降低新系统开发的风险。
继承策略
遗留系统的技术含量较低，已经满足企业运作的功能或性能要求，但具有较高的商业价值，目前企业的业务尚紧密依赖该系统。对这种遗留系统的演化策略为继承。在开发新系统时，需要完全兼容遗留系统的功能模型和数据模型。为了保证业务的连续性，新老系统必须并行运行一段时间，再逐渐切换到新系统上运行
改造策略
遗留系统具有较高的业务价值，基本上能够满足企业业务运作和决策支持的需要。这种系统可能成的时间还很短，对这种遗留系统的演化策略为改造。改造包括系统功能的增强和数据模型的改两个方面。系统功能的增强是指在原有系统的基础上增加新的应用要求，对遗留系统本身不做改变；数据模型的改造是指将遗留系统的旧的数据模型向新的数据模型的转化。
集成策略
遗留系统的技术含量较高，但其业务价值较低，可能只完成某个部门(或子公司)的业务管理。这种系统在各自的局部领域里工作良好，但对于整个企业来说，存在多个这样的系统，不同的系统基于不同的平台、不同的数据模型，形成了一个个信息孤岛，对这种遗留系统的演化策略为集成。
新旧系统的转换策略
直接转换策略
并行转换策略
分段转换策略数据转换与迁移
抽取、转换、装载
系统切换前通过工具迁移。系统切换前采用手工录入。系统切换后通过新系统生成
软件维护
- 正确性维护，改BUG
指改正在系统开发阶段已发生而系统测试阶段尚未发现的错误
- 适应性维护
指使应用软件适应信息技术变化和管理需求变化而进行的修改。企业的外部市场环境和管理需求的不断变化也使得各级管理人员不断提出新的信息需求。
- 完善性维护
扩充功能和改善性能而进行的修改。对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征。
- 预防性维护
为了改进应用软件的可靠性和可维护性，为了适应未来的软硬件环境的变化，应主动增加预防性的新的功能，以使用系统适应各类变化而不被淘汰。如将专用报表功能改成通用报表生成功能，以适应将来报表格式的变化。
最后编辑：admin 更新时间：2022-11-02 13:24
