请帮我学习第5章： 第 5 章 应用系统规划 5.1 基础知识 针对组织的具体需求，应用系统规划设计的内容存在较大差异，覆盖了：1）应用系 统整体规划 ；2）应用系统业务条线规划 ；3）应用 软件设计。 1． 基本概念 无论是何种类型的应用系统规划设计，其基本业务逻辑都是基于组织业务发展的特 定和个性化需求，针对应用系统不同颗粒和层次的体系架构、领域或模块、模式等，按 照“需求－抽象－体系－配套” 的过程，实现相关内容的定义。 （1）抽象 抽象是从众多的事物中抽取出共同的、本质性的特征，而舍弃其非本质的特征的过 程。当组织考虑某个或某系列问题的体系化（模块化）解决方案时，可以进行多层级的 抽象。 对应用系统的不同层次进行抽象时，应用系统规划设计人员需要创建业务抽象、过 程抽象、数据抽象和技术抽象。 在最高的抽象级上，使用问题所处环境的语言以概括性的术语描述解决方案，如业 务效率提升、计划与调度可视化与敏捷化等术语。 在较低的抽象级上，提供更详细的解决方案说明，如审批流定义、信息表单定义、 前端界面定义等。 在最低的抽象级上，以一种能直接实现的方式陈述解决方案。 对应用系统的不同层次进行抽象时，应用系统规划设计人员需要创建业务抽象、过 程抽象、数据抽象和技术抽象。 ① 业务抽象：是将组织复杂的业务活动和业务逻辑，转化为可管控（管理）、可显 性表达、可重用的业务区块与组件的过程，需要聚焦业务的价值本质，忽略或简化无价 值或低价值活动。实质上就是面向现实世界的不同“场景”进行建模的过程，它用高度 概括性和结构化的内容来描述场景最核心的本质。 ② 过程抽象：是指具有明确和有限功能的指令序列。 ③ 数据抽象：是描述数据对象的具体数据集合。 ④ 技术抽象：是描述问题解决所需要的可持续开发利用的技术体系。 （2）体系架构 从最简单的形式来看，体系架构是应用系统组成结构，根据需要可以覆盖应用系统、 软件模块、程序构件等不同层次，以及这些组成部分交互的方式和所用数据的结构等。 ① 架构特性定义了系统的组成部分（如系统、模块、对象过滤器） 及其被封装的方 式，以及不同部分之间相互作用的方式。 ② 外部功能特性指出体系架构如何满足需求。这些需求可包括发展需求、性能需求、 功能需求、可靠性需求、安全性需求、可适应性需求以及其他特征需求。 ③ 一旦明确了架构特性， 就可以用一种或多种不同 的模型来表示应用系统体系架 构。 l 架构模型将体系架构表示为应用系统组成部分的有组织的集合。 l 框架模型可以通过确定相似应用中遇到的可复用体系框架来提高抽象的级别； l 动态模型强调体系架构的行为方面，指明结构或系统配置如何随着外部事件的变化 而产生变化； l 过程模型强调系统必须提供的业务或技术流程的设计;功能模型可用于表示系统的 功能层次结构。 l 功能模型可用于表示系统的功能层次结构。 （3）模式 模式是一种最佳实践的表达方法，是应用系统规划设计人员基于实践经验、试验与 教训等，总结出来的面向一般问题的解决方法，其承载了已证实的解决方案的精髓。应 用系统规划设计模式描述了解决某个特定问题的应用系统架构、解决问题方法、技术措 施等。面对不同的业务场景、应用系统建设需求，可以采用不同的模式。每种模式通常 用来解决特定环境的问题，该环境会影响模式的应用和使用方式。常见的模式包括创建 型模式、结构型模式和行为型模式等。 每种设计模式的 目的都是提供一种描述，以使规划设计人员可以确定： ① 模式是否适用于当前的工作。 ② 模式是否能够复用（节约设计时间）。 ③ 模式是否能够用于指导下一个相似的但功能或结构不同的模式。 （4）关注点分离 关注点分离是日常生活和生产中广泛使用的解决复杂问题的一种系统思维方法。它 表明任何复杂问题如果被分解为可以独立解决或优化的若干块，该复杂问题便能够更容 易地得到处理。 l 关注点是一个特征或一个行为，可被指定为应用系统需求模型的一部分。将关注点 分割为更小的关注点便可用更少的工作量和时间解决一个问题。 l 两个问题被结合到一起的认知复杂度经常高于每个问题各自的认知复杂度之和。这 就引出了 “分而治之”的策略，把一个复杂问题分解为若干可管理的块来求解时将 会更容易。 关注点分离表明任何复杂问题如果被分解为可以独立解决或优化的若干块，该复杂 问题便能够更容易地得到处理。 （5）模块化 模块化是应用系统的单一属性，它使应用系统能被智能化地管理。模块化是关注点 分离最常见的表现，也是一个相对概念，对于不同的应用系统规划的设计场景，其定义 模块的颗粒度 也不同。 应用系统被划分为独立命名的、可处理的模块（子系统、构件），把这些模块集成 到一起可以满足问题的需求。 绝大多数情况下，为了理解更容易，都应当将应用系统划分成许多部分，这样可以 降低构建应用系统所需的成本。 （6）信息隐蔽 模块化概念面临的一个基本问题是：应当如何分解应用系统解决方案以获得最好的 模块集合。 l 信息隐蔽原则建议模块应该具有的特征是每个模块对其他所有模块都隐蔽自己的规 划设计决策。换句话说，模块应该被特别说明并规划设计，使信息（算法和数据） 都包含在模块内，其他模块无须对这些信息进行访问。 l 将信息隐蔽作为应用系统模块化的一个规划设计标准，会在测试过程中以及随后的 应用系统维护过程中需要进行修改时受益匪浅。 l 由于大多数数据和过程对应用系统的其他部分是隐蔽的，因此，在修改过程中不小 心引入的错误就不太可能传播到应用系统的其他地方。 （7）功能独立 ① 功能独立的概念是关注点分离、模块化、抽象和信息隐蔽概念的直接产物。通过 建设具有专一功能、避免与其他模块过多交集的模块，可以实现功能独立。 ② 独立性可以通过两条定性的标准进行评估： 内聚性和耦合性。1）内聚性显示了 某个模块相关功能的强度；耦合性显示了模块间的相互依赖性。内聚性是信息隐蔽概念 的自然扩展，一个内聚的模块应该只完成一件（或一类）事情。2） 耦合性表明应用系统 架构中多个部分之间的相互连接。耦合性依赖于各部分间的接口复杂性、互操作所在的 点，以及什么数据通过接口进行传递。在应用系统规划设计中，应当尽力得到最低可能 的耦合。 （8）求精 求精是一种 自顶向下的规划设计策略 。通过逐步分解功能的宏观陈述（过程抽象） 进行层次建设，直至最终到达程序语言的语句可描述的层级。 求精实际上是一个细化的过程，该过程从高抽象级上定义的功能陈述或信息描述开 始。陈述概念性地描述了功能或信息，但并没有描述提供有关功能内部的工作或信息内 部的结构。可以在原始陈述上进行细化，随着每次细化的持续进行，将提供越来越多的 细节。 抽象和细化是互补的概念，抽象能够明确说明内部过程和数据，但对外部使用者隐 藏了低 层细节；细化有助于在规划设计过程中揭示低层细节。这两个概念均有助于规划 设计人员在规划设计演化中构建出完整的模型。 （9）重构 重构是一种重新组织的技术，可以简化应用系统及其组成部分的规划设计而无须改 变其功能或行为。在重构应用系统时，重点检查现有应用系统的冗余性、没有使用的元 素、低效的或不必要的算法、拙劣的或不恰当的数据结构以及其他不足， 修改这些不足， 以获得更好的规划设计。 2． 基础架构 应用系统的框架是指系统的一个或多个结构，包括软件构件、构件的外部可见属性 以及它们之间的相互关系。应用系统体系架构是建立在系统支持环境基础上的系统基本 框架，是应用系统生命周期中必须具备的骨骼，可作为构建、扩充与完善应用系统的基 础。 （1）分层体系 通常，应用系统从上至下可划分为多层，如图所示。 图：应用系统分层体系 l 界面交互层。实现系统与环境的交互，需要面向用户确定操作规则，构造元素主要 是界面控件，如按钮、文本框等。 l 业务处理层。实现业务流程控制与业务数据计算，构造元素是业务子系统，它们通 常基于特定业务定义，构造元素是一些功能构件。 l 数据处理层。实现数据读写处理， 构造元素主要是基于 SQL 语言的函数包，如数据 视图、数据存储过程、数据触发器等。 l 数据存储层。实现数据有效存储， 构造元素是数据集合体，如数据表、数据文件等。 （2）以数据为中心的架构 对于以数据处理、统计、汇总为业务特征的应用系统，可以数据为中心构建应用系 统架构，如图所示。数据驱动是以数据为中心的应用系统的最常见的设计路线，即先规 划设计好数据环境，如数据库、数据文件，然后按照系统对数据的业务应用划分来规划 设计各个子系统。 图：以数据为中心的应用系统架构 （3）客户机/服务器架构 ① 两层客户机/服务器架构 初期的客户机/服务器架构将应用系统分为前端程序与后台数据两个部分，其中，前 端程序（如界面程序、业务处理程序）被安置在客户机上，而后台数据则被安置在数据 库服务器上。 两层客户机/服务器架构的优点是结构简单，容易实现，而且交互与业务处理程序运 行在客户端，具有较好的操作性能，可方便客户端对数据的计算与表现。 但两层结构存在管理与维护的不便。客户端程序需要承担信息表示与业务处理双重 任务，并且被分散在许多不同的客户机上， 当界面风格或业务规则改变时，需要进行较 大的客户机程序的变更，变更成本较大。 图：两层客户机/服务器架构 ② 三层客户机/服务器架构 三层客户机/服务器架构是鉴于两层结构在管理与维护上的不便而提出的，即将原来 安置在客户机上的业务处理程序提取出来，并把它放到一个专门的应用服务器上。 三层架构的作用是将应用系统中容易改变的业务处理部分集中到应用服务器上，使 得当系统业务规则改变时，需要更新的不是数目庞大的客户机，而只需要针对应用服务 器上的应用程序进行更新，有利于系统的维护。 图：三层客户机/服务器架构 但三层架构的软件实现技术难度较大，并且在计算机硬件设备方面比两层结构需要 更高的性能要求。三层客户机/服务器架构是逻辑结构，在物理上，某台计算机可以既是 应用服务器，又是数据库服务器。 ③ 浏览器/服务器架构 浏览器/服务器架构又称为 B/S 架构，是一种互联网环境下特殊的客户机/服务器架 构。在 B/S 架构中，原来客户机上的界面程序被 Web 服务器上的 Web 页替代，因此， B/S 架构中已不需要专门的客户端程序，而 只需要有一个通用的 Web 浏览器，即可实现 客户端对服务器的访问。B/S 架构如图所示。 图：浏览器/服务器架构 B/S 架构的优越性：无须对客户机专门维护，且能够较好地支持基于互联网的远程信 息服务。 B/S 架构的不足：用户信息需要通过 Web 服务器间接获取，因此系统中数据的传输 速度、数据安全性、稳定性都将低于传统客户机/服务器架构。 （4）组件分布架构 组件是程序实体，常由对象类集成，其形态多样，可以是可执行程序/文件，或是需 要其他程序才能工作的动态库，甚至可以是一个具有一定综合处理功能的子系统。 组件分布架构可突破传统客户机/服务器架构对分布的限制。 组件分布架构需要有组件分布中间层构件提供基础服务，组件分布中间层构件如同 软件总线，可支持组件插拔，并可支持组件之间的通信与任务协作。基于中间层构件集 成的组件分布架构如图： 图：组件分布架构 目前应用中的主要的组件分布中间层构件有 CORBA、DCOM、EJB。 （1）CORBA （通用对象请求代理模型） ：是由对象管理组织（OMG）定义的通用 的并与机器无关的分布式对象计 算准则。OMG 是一个由诸多有影响力的软件开发机构 组成的集团组织，因此 CORBA 得到了非常广泛的应用支持，目前已在 UNIX、Linux 及 Windows 等诸多操作系统上有效应用。 （2）DCOM（分布式组件对象模型）：是一系列微软的概念和程序接口，利用这个 接口，客户端程序对象能够请求来自网络中另一台计算机上的服务器程序对象。 DCOM 基于组件对象模型（COM）, COM 提供了一套允许同一台计算机上的客户端和服务器之 间进行通信的接口。 DCOM 的通用性不如 CORBA。 （3）EJB 是基于 Java 的分布式组件对象模型，是由 Sun 公司定义的组件分布中间件 标准，主要用在基于 Java 的组件网络分布计算中。 3. 小结和思考 （1）基本概念 - 抽象：业务、过程、数据、技术四类抽象，提取本质特征。 - 体系架构：通过架构模型（功能、动态、过程等）满足性能、安全等需求。 - 设计模式：创建型、结构型、行为型模式，解决特定问题并提高复用性。 - 关键原则：关注点分离、模块化、信息隐蔽、功能独立（高内聚低耦合）、 逐步求精与重构。 （2）基础架构类型 - 分层体系：界面交互→业务处理→数据处理→数据存储层。 - 数据为中心：适用于数据统计类系统。 - 客户机/服务器：两层（简单但维护难） vs 三层（易维护但技术复杂）。 - B/S 架构：无需专用客户端，适合远程服务，但性能与安全性较低。 - 组件分布架构：CORBA、DCOM、EJB 等中间件支持组件化部署与通信。 5.2 主要内容 应用系统规划设计包括对相关应用系统进行分级分类，并根据分级分类的结果，对 应用系统进行生命周期选择、体系结构定义、接口定义、数据定义、构件定义等。 接口规划设计有三个重要元素：1）用户界面；2）和其他系统、设备、网络或其他 信息生产者或使用者的外部接口；3）各种构件之间的内部接口。 1． 生命周期选择 应用系统的生命周期是指从规划设计该系统的构想开始，到系统需求的确定、系统 设计、系统实现、产品测试与验收、投入使用以及应用系统版本的不断更新，到最终该 应用系统退役的全过程。 生命周期模型把应用系统生命周期细分为几个阶段，这些阶段需要包含识别用户需 求、开发、测试、安装、运行以及退役这几个步骤。 （1）瀑布模型 20 世纪 80 年代之前瀑布模型是一个被广泛采用的生命周期模型，其特点如下： l 阶段间具有顺序性和依赖性。其中包含两种含义：必须等前一阶段的工作完成后， 才能开始后一阶段的工作；前一阶段的输出成果就是后一阶段的输入内容。 l 推迟实现的观点。瀑布模型在编码之前设置了系统分析和系统设计的各个阶段。分 析与设计阶段的基本任务规定，在这两个阶段主要考虑目标系统的逻辑模型，不涉 及物理实现。清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现，是按 照瀑布模型开发应用系统的一条重要的指导思想。 l 质量保证的观点。每个阶段都必须完成规定的内容，没有交出合格的成果就是没有 完成该阶段的任务。每个阶段结束前都要对所完成的成果进行评审，以便尽早发现 问题，改正错误。 （2）V 模型 ① V 模型是瀑布模型的变种，它主要描述了测试活动是如何与分析和设计活动相关 联的。 ② 编码是 V 模型的顶点，分析和设计在模型的左侧，测试和维护在右侧。 ③ 单元测试和集成测试关注程序的正确性。V 模型说明单元测试和集成测试也可以 用来验证程序设计。 也就是说，在单元测试和集成测试期间，编码人员和测试团队成员应确保编码正确 地实现了程序设计的意图。类似地， 系统测试应能验证系统设计，确保系统设计得到正 确实现。由用户而不是开发人员主导的验收测试，通过把测试和需求规格说明的每一个 元素相关联，进行需求的确认，验收测试主要检查在系统交付之前所有的需求是否都被 实现了。 （3）迭代模型 ① 迭代模型分为两种： 一种是演化建设，即开始交付的就是一个完整的应用系统 ，然后在后续迭代中不断完善 系统的功能和质量； 另一种是增量建设，即将应用系统作为 一系列的增量构件来规划设计、编码集成和测试， 刚开始交付的是一个实现了部分功能的子系统，然后在后续迭代中不断增加新的功能。 ② 迭代模型的优点是： l 逐步增加应用系统的功能可以使用户有较充裕的时间学习和适应新产品，从而减少 全新的应用系统可能给用户带来的冲击。 l 建设失败的风险较低，虽然在某些增量构件中可能遇到一些问题，但其他增量构件 将能够成功地交付给客户。 l 优先级最高的服务首先交付，然后再将其他增量构件逐次集成进来。这样带来一个 必然的事实是，最重要的系统服务将接受最多的测试。这意味着系统最重要的部分 一般不会遭遇失败。 ③ 采用迭代模型需注意的问题是： 1）在把每个新的增量构件集成到现有的应用系 统体系架构中时必须不破坏原来已经部署的应用系统内容；2）应用系统体系架构必须是 开放的，即向现有应用系统中加入新构件的过程必须简单、方便。 （4）敏捷方法 ① 敏捷宣言的 4 种核心价值是：1）个体和互动高于流程和工具。2） 工作的软件高 于详尽的文档。3）客户合作高于合同谈判。4）响应变化高于遵循计划。 ② 敏捷宣言的 12 条原则包括： l 最高优先级的是，通过尽早和持续交付有高价值的软件，满足客户。 l 欣然面对需求变化， 即使是在开发阶段的后期，敏捷流程就是用变化来为客户获得 竞争优势。 l 频繁交付可工作的软件，从数周到数月，交付周期越短越好。 l 在项目过程中，业务人员、开发人员必须每天在一起工作。 l 以受到激励的个体为核心构造项目，为他们提供所需的环境和支持，信任他们可以 把工作做好。 l 最有效的、最高效的沟通方法是面对面的交谈。 l 可工作的软件是衡量进度的首要标准。 l 敏捷流程倡导可持续开发，客户、开发人员、用户要能够共同、长期维持步调（节 奏）、稳定向前。 l 持续地追求技术卓越和良好的设计，以此增强敏捷的能力。 l 简单，尽最大可能减少不必要的工作，简单是敏捷流程的根本。 l 最佳架构、需求和设计，来自自组织型的团队。 l 团队定期反思如何提升效率，并调节和调整自己的工作方式。 （5）生命周期模型选择 从前面所介绍的几种不同的生命周期模型中可以看到每个生命周期模型都会包含下 面这些通用的活动： ① 和用户达成一致的需求。 ② 基于需求的规划设计。 ③ 基于规划设计的构造。 ④ 基于所有优先级步骤的测试流程的构建。 ⑤ 每一阶段的出口和入口标准。活动的某些部分会重叠，但基本上是顺序关系。 2． 体系结构定义 在对应用系统进行体系结构定义时，首先从系统的功能入手，按照工程标准和严格 的规范将目标系统划分为若干功能模块。 （1）面向数据流的定义方法 ① 面向数据流的定义方法是常用的结构化规划设计方法，多在概要阶段使用。它主 要是指依据一定的映射规则，将需求分析阶段得到的数据描述从系统的输入端到输出端 所经历的一系列变换或处理的数据流图转换为目标系统的结构描述。 ② 在数据流图中，数据流分为变换型数据流和事务型数据流两种。 所谓变换，是指把输入的数据处理后转变成另外的输出数据。 所谓事务，是指非数据变换的处理，它将输入的数据流分散成许多数据流，形成若 干个加工，然后选择其中一个路径来执行。 （2）针对变换型数据流的规划设计可以分为以下三个步骤： ① 区分变换型数据流中的输入数据、变换中心和输出数据， 并在数据流图上用虚线 标明分界线； ② 分析得到系统的初始结构图； ③ 对系统结构图进行优化。 （3）针对事务型数据流的规划设计可以分为以下三个步骤： ① 确定以事务为中心的结构，找出事务中心、接收数据、处理路径三个部分； ② 将数据流图转换为初始的系统结构图； ③ 分解和细化接收分支和处理分支。 （2）面向数据结构的定义方法 面向数据结构的定义方法就是根据数据结构规划设计程序处理过程的方法。使用面 向数据结构的定义方法时，分析目标系统的数据结构是关键。 面向数据结构的定义方法通常在详细设计阶段使用。 比较流行的面向数据结构的定义方法包括 Jackson 方法和 Warnier 方法。Warnier 方 法仅考虑输入数据结构，而 Jackson 方法不仅考虑输入数据结构，还考虑输出数据结构。 Jackson 方法把数据结构分为三种基本类型：顺序型结构、 选择型结构和循环型结构。 （3）表示应用系统体系结构的图形工具 ① 层次图：通常使用层次图描绘应用系统的层次结构。在层次图中， 一个矩形框代 表一个模块，框间的连线表示调用关系（位于上方的矩形框所代表的模块调用位于下方 的矩形框所代表的模块）。每个方框可以带编号，像这样带编号的层次图也称为 HIPO 图。 图：正文加工系统的 HIPO 图 ② 结构图：结构图和层次图类似，也是描绘体系结构的图形工具，图中一个方框代 表一个模块，框内注明它们的名字或主要功能，方框之间的箭头（或直线）表示它们间 的调用关系。在结构图中通常还用带注释的箭头表示模块调用过程中来回传递的信息。 如果希望进一步标明传递的信息是数据还是控制信息，则可以利用注释箭头尾部的形状 来区分，尾部是空心圆表示传递的是数据，尾部是实心圆表示传递的是控制信息。 图：产生最佳解的结构图 3． 接口定义 （1）接口定义的内容应包括 功能描述、接口的输入/输出定义、错误处理等。接口 定义通常需要包括以下几个方面： ① 用户接口。用来说明将向用户提供的命令和它们的语法结构以及应用系统回答信 息。 ② 外部接口。用来说明本系统同外界的所有接口的安排， 包括软件与硬件之间的接 口、本系统与各支持系统之间的接口关系。 ③ 内部接口。用来说明本系统之内的各个系统元素之间的接口的安排。 (2) 界面定义是接口定义中的重要组成部分 。指导用户界面定义活动的基本原则如 下： ① 置用户于控制之下。1）以不强迫用户进入不必要的或不希望的动作的方式来定 义交互模式；2）提供灵活的交互；3）允许用户交互被中断和撤销；4）当技能级别增长 时可以使交互流水化并允许定制交互；5）使用户隔离内部技术细节；6）应允许用户和 出现在屏幕上的对象直接交互。 ② 减少用户的记忆负担。1）减少用户对短期记忆的要求； 2）建立有意义的默认设 置；3）定义直觉性的捷径；4）界面的视觉布局应该基于真实世界的隐喻；5）以不断进 展的方式揭示信息。 ③ 保持界面一致。1）允许用户将当前任务放入有意义的语境，在应用系统内保持 一致性； 2）如果过去的交互模式已经建立起了用户期望，则不要改变它，除非有不得 已的理由。 （3）明确系统界面是一个迭代的过程，其核心活动包括：1）创建系统功能的外部 模型；2）确定为完成此系统功能，人和计算机应分别完成的任务；3）考虑界面定义中 的典型问题；4）借助 CASE 工具构造界面原型；5）评估界面质量。 （4）在界面定义中，应该考虑以下 4 个问题： 1）系统响应时间。指当用户执行了 某个控制动作（如单击鼠标等）后，系统做出反应的时间。 2）用户求助机制。用户都 希望得到联机帮助，联机帮助系统有两类：集成式和叠加式。3） 出错信息。应选用用户 明了、含义准确的术语描述， 同时还应尽可能提供一些有关错误恢复的建议。4）命令方 式。键盘命令虽不再是唯一的交互形式，但许多有经验的熟练的软件人员仍喜爱这一方 式，更多的情形是菜单与键盘命令并存，供用户自由选用。 4． 数据定义 数据定义就是将需求分析阶段定义的数据对象转换为数据结构和数据库的过程，注 意要对程序级的数据结构和应用级的数据库两个方面进行定义。数据库的定义过程大致 可分为需求分析、定义概念模型、定义逻辑模型、定义物理数据库、验证 5 个步骤： ① 需求分析。调查和分析用户的业务活动和数据的使用情况，弄清所用数据的种类、 范围、数量以及它们在业务活动中交流的情况，确定用户对数据库系统的使用要求和各 种约束条件等，形成用户需求规约。 ② 定义概念模型。对用户要求描述的现实世界， 通过对其中信息的分类、聚集和概 括，建立抽象的概念数据模型。 ③ 定义逻辑模型。主要工作是将现实世界的概念数据模型转成数据库的一种逻辑模 式，即某种特定数据库管理系统所支持的逻辑数据模式。 ④ 定义物理数据库。根据特定数据库管理系统所提供的多种存储结构和存取方法等 依赖于具体计算机结构的各项物理设计措施，对具体的应用任务选定最合适的物理存储 结构、存取方法和存取路径等。 ⑤ 验证。在上述信息的基础上， 收集数据并具体建立一个数据库，运行一些典型的 应用任务来验证数据库定义的正确性和合理性。 5． 构件定义 对应用系统构件进行定义，将需求模型和架构模型中的信息转化为构件表示，这种 表示提供了用来指导构件（编码和测试）活动的充分信息。进行构件定义的典型任务包 括： l 标识出所有与问题域对应的类。 l 确定所有与基础设施域对应的类。 l 细化所有不需要作为可复用构件的类。 l 说明持久数据源（数据库和文件）并确定管理数据源所需要的类。 l 开发并且细化类或构件的行为表示。 l 细化部署图以提供额外的实现细节。 l 考虑每个构件级定义表示，并且时刻考虑其他可选方案。 6.小结和思考 (1）生命周期选择 - 瀑布模型：顺序依赖，强调质量保证。 - V 模型：测试与分析设计关联，验证程序设计。 - 迭代模型：演化（完整系统逐步完善）与增量（分构件交付），降低风险。 - 敏捷方法：4 大核心价值（个体互动、可工作软件等）+12 条原则（持续交付、 响应变化等）。 （2）体系结构定义 - 面向数据流：变换型（输入→变换→输出）与事务型（事务中心→处理路径） 数据流设计。 - 面向数据结构：Jackson（顺序/选择/循环结构）与 Warnier 方法。 - 图形工具：层次图与结构图描述模块调用关系。 （3）接口定义 - 用户/外部/内部接口，需定义功能、输入/输出及错误处理。 - 界面设计原则：用户控制、减少记忆负担、一致性。 （4）数据定义 - 5 步骤：需求分析→概念/逻辑/物理模型→验证。 （5）构件定义 - 关键任务：标识问题域类、细化行为表示、优化部署图。 5.3 主要过程 系统设计的目标是将分析阶段所获得的系统概念模型转换成一个具体的计算机实现 方案的物理模型。 1． 初步调研 系统的开发工作是从接受用户提出的任务开始的。 （1）初步调研的目标 建设新系统正式立项之前必须进行可行性研究，而可行性研究的基础是对系统的初 步调研。初步调研的目标就是掌握用户的概况，对用户提出的各种问题和初始要求进行 识别，明确新系统的初步目标，为可行性研究提供基础。 （2）初步调研的内容 初步调研主要围绕规划设计工作进行，应立足于宏观和全面，不需要过于具体和细 致 。初步调研的具体内容主要包括：组织概况、组织环境、现行系统概况、各方面对新 系统的态度、系统研制工作的资源情况。 2． 可行性研究 可行性研究也称可行性分析，是所有项目投资、工程建设或重大改革在开始阶段必 须进行的一项工作。 可行性研究是一个特定的过程，用来识别项目可能存在的问题、机会或要求，确定 项目目标，描述现有状况和成功后的结果，对问题的不同解决方案进行费用和收益的比 较。 （1）可行性研究概述 可行性研究的结果可分为三种情况：1）可行，按计划进行；2）基本可行，对项目 要求或方案做必要修改；3）不可行，不立项或终止项目。 可行性研究必须从系统总体出发，一般需要从经济、技术、社会、管理等多个方面 进行综合分析和论证，这四方面的分析工作分别称为经济可行性分析、技术可行性分析、 社会可行性分析和管理可行性分析。 应用系统可行性研究工作十分重要。 首先，要对系统的总体定义进行可行性论证； 其次，要对在系统建设过程中各阶段的项目进行可行性分析； 此外，随着环境、需求和技术的发展变化，还要及时根据变化对系统建设带来的影 响进行可行性分析。应用系统规划设计的可行性研究主要分析所制定的系统规划设计是 否符合组织发展的实际，也是从经济、技术、社会和管理等方面进行分析。 （2）可行性研究的步骤 ① 典型的应用系统可行性研究由以下 8 个步骤组成： 1）复查系统目标和规模。2） 研究目前正在使用的系统。3） 导出新系统的高层逻辑模型。4） 重新定义问题。5） 导出 和评价供选择的方案。6） 推荐一个方案并说明理由。7） 草拟开发计划。8） 书写文档并 提交审查。 ② 可行性研究的前 4 个步骤实际上构成一个循环：定义问题，分析这个问题，导出 一个试探性的解；在此基础上再次定义问题，再次分析，再次修改……继续这个过程， 直到提出的逻辑模型完全符合系统目标为止。 （3）可行性研究的必要性 必要性来自组织内部对建设应用系统的需要和组织外部的要求，是从管理人员对系 统的客观要求及现行系统的可满足性两个角度来分析新系统建设是否必要。 如果发现管理人员对信息的需求并不迫切，或者感到原系统没有更换的必要，那么 新系统的研制就不具备可行性。 如果现行系统的处理速度和处理内容满足不了日益发展的管理要求，则认为系统建 设是必要的。 （4）可行性研究的内容 可行性研究的目的不是解决问题，而是研究在当前的具体条件下建设新系统是否具 备必要的资源和其他条件。一般来说应从以下几方面进行论证。 ① 经济可行性 经济可行性分析也叫投资/效益分析或成本/效益分析，它是分析新系统项目所需的花 费和项目建设成功之后所能带来的经济效益。投资/效益分析需要确定所要建设的系统的 总成本和总收益。通过比较成本和效益，可以决定将要立项的新系统是否值得建设。一 般可获得的结论有以下三种：1）效益大于成本，建设对组织有价值；2）成本大于效益， 不值得建设；3）效益和成本基本持平。所以当总收益大于总成本时， 这个项目才值得建 设。总成本包括建设成本和运行成本，总效益包括直接经济效益和间接社会效益。 l 建设成本是指从立项到投入运行所需要的费用 ，而运行成本则是指系统投入使用之 后运行、管理和维护所需要的费用。 l 直接经济效益是系统能够直接获取的并且能够用资金度量的效益。 间接社会效益是 能够整体提升组织信誉和形象、提高组织管理水平，但不能简单地或无法用资金计 算的那部分效益。间接社会效益常常需要根据本组织的状况和不同组织之间的类比 进行估计。在进行成本/效益分析时不要忽视应用系统给组织所带来的间接社会效 益。 l 在进行成本估算时，往往要加大一定的比例，以防由于意外或物价变动因素而出现 预算偏低的现象。总成本主要由以下几项组成： 1）设备成本。2） 人员成本。3） 材 料成本。4）其他成本。 ② 技术可行性 技术可行性是分析特定条件下技术资源的可用性和这些技术资源用于解决应用系统 问题的可能性和现实性。在进行技术可行性分析时，一定要注意以下几方面的问题： l 应该全面考虑系统建设过程中涉及的所有技术问题。 l 尽可能采用成熟技术。 l 慎重引入先进技术。 l 着眼于具体的开发环境和开发人员。 ③ 社会可行性 社会可行性具有比较广泛的内容，它需要从政策、法律、道德、制度、管理、人员 等社会因素论证系统建设的可能性和现实性。社会可行性还需要考虑操作可行性，操作 可行性是指分析和测定给定系统在确定环境中能够有效地工作并被用户方便使用的程度 和能力。操作可行性需要考虑以下几方面： l 问题域的手动业务流程和新系统的流程的相近程度和差距。 l 系统业务的专业化程度。 l 系统对用户的使用要求。 l 系统界面的友好程度以及操作的方便程度。 l 用户的实际能力。 分析操作可行性必须立足于实际操作和使用系统的用户环境。 ④ 管理可行性 从组织管理上分析新系统建设的可行性，包括如下内容： l 组织领导、部门主管对新系统建设是否支持以及态度是否坚决。 l 管理人员对新系统建设的态度以及配合情况如何。 l 管理基础工作如何，现行管理系统的业务处理是否规范等。 l 新系统的建设运行会导致管理模式、数据处理方式及工作习惯的改变，这些工作的 变动量如何以及管理人员能否接受。 （5）可行性研究报告 可行性研究报告是在制定某一建设项目或科研项目之前，对该项目实施的可能性、 有效性、技术方案及技术政策进行具体、深入、细致的技术论证和经济评价， 以求确定 一个在技术上合理、经济上合算的最优方案而写的书面报告。 可行性研究完成之后要编写可行性研究报告。 ① 可行性研究报告的书写要求：包括首页、正文、附件、日期等几部分。 在写可行性研究报告时，要注意叙事清楚、文字简明、实事求是、客观公正、分析 全面而准确。 可行性研究报告的首页是可行性研究报告正文前面的内容的统称，一般包括标题、 研究人员名单、目录、前言几部分。 可行性研究报告的正文核心是论证项目的可行性。要围绕影响项目的各种因素，运 用大量的数据材料，以系统分析为主要方法进行论证。 不同的可行性研究报告会有不同类型的附件材料，其作用是补充说明正文，避免因 在正文中出现过多说明而影响正文内容的表达。 ② 可行性研究报告的主要内容 l 建设任务的提出。 l 系统的目标。 l 初步调研概况。 l 初步实施方案与比较。 l 可行性研究。 结论：根据分析的结果，对新系统建设做出以下三种结论之一：1）项目可行，条件 成熟，可以立即建设；2）需要修改目标，追加资源或等待条件；3）不可能或没有必要 进行，项目终止。 （6）可行性论证会 可行性研究报告提交给上级主管部门后，按规定应召开由主管部门主持，用户组织、 研制组织和其他组织的专家学者参加的可行性论证会。这是第一次交流，要做好详细的 会议记录。 讨论的结果有两种可能：一种是同意或基本同意报告中的结论，立即执行或修改目 标、追加资源和等待条件，或者取消研制项目；另一种是对报告持不同意见，对某些问 题的判断有不同看法。 可行性研究报告一旦通过，将成为以后工作的依据，因此必须有一个正式的报告文 本和可行性论证会的结论。 3． 详细调研 详细调研的目的主要是了解组织内部信息的处理和流通情况。重要性在于细致、准 确地掌握用户信息处理的具体情况，为建立一个符合实际要求的逻辑模型以及顺利开展 系统的规划设计与实现工作打下良好基础。 （1）详细调研的目标 l 详细调研的对象是现行系统（包括手动业务和已采用计算机的应用系统）。 l 详细调研的目的在于完整掌握现行系统的现状，查明其执行过程，发现问题和薄弱 环节，收集资料和数据，为下一步的系统分析和提出新系统的逻辑设计做好准备。 具体的调研内容包括管理业务状况与数据流程的调查和分析。 l 详细调研要目标明确，调研的内容紧紧围绕系统的任务。要注意调研方法，不断积 累和分析有关资料，并且利用各种系统分析技术和工具，把系统确切地描述出来。 系统调研分析从一开始就应成立调研组。调研组由使用组织的业务人员和领导人员 与规划设计团队共同组成。 （2）详细调研的范围 详细调研的范围可大致归纳为以下 9 个方面： 1）组织和功能业务；2）组织目标和 发展战略；3）工艺流程和产品构成；4）数据和数据流；5）业务流程和工作形式；6） 管理方式和具体业务的管理方法；7）决策方式和决策过程； 8）可用资源和限制条件；9） 现存问题和改进意见。 （3）详细调研的原则 详细调研工作应该遵循如下几点原则 ：1） 自顶向下全面展开；2）用户参与；3）分 析系统有无改进的可能性；4）工程化的工作方式；5）全面与重点相结合；6）主动沟通 和友善的工作方式。 （4）详细调研的内容 在详细调研阶段，以下几项活动必须全部完成，它们之间是互补的， 并且通常同时 完成。 ① 收集信息 收集信息是指通过各种方式获取所需的信息。信息收集工作的好坏直接关系到整个 信息管理工作的质量。为保证信息收集的质量，应坚持以下原则： 准确性：该原则要求所收集到的信息要真实可靠，当然，这个原则是信息收集工作 的最基本要求。 全面性：该原则要求所搜集到的信息要广泛、全面和完整。 时效性：信息的利用价值取决于该信息是否能及时地提供，即它的时效性。 在完成这项活动时，应该回答的关键问题是“我们是否已经拥有全部的信息来定义 系统必须完成的工作”。 ② 系统需求建模 在详细调研阶段，要完成的是系统需求建模。需求模型（或模型的集合）是一种逻 辑模型，它能够很详细地展示系统需要完成哪些功能，而不依赖任何技术。从中立的角 度看待技术，开发组首先要将精力集中在“需要什么”上，而不是“它将采用什么形式”。 在完成这项活动时，应该回答的关键问题是“我们需要系统做什么（详细的）”。 ③ 需求的优先级划分 用户和分析员都要问问自己到底哪些功能是真正重要的，而哪些功能也很重要但却 并不是绝对需要的。那些理解公司和用户所做工作的分析员在解决这个问题上会更有洞 察力。 为什么要对用户提出的功能进行优先级的划分呢？因为资源往往是有限的，我们时 常需要判断系统的作用域，所以了解究竟什么是绝对需要的非常重要。 在完成这项活动时，应该回答的关键问题是“系统要完成的最重要的事是什么”。 ④ 构建系统原型，检验可行性并发现问题 为了简化对新的业务处理过程的调研工作，我们需要构建原型，通过使用简单的投 影或报告，可以和用户讨论新系统如何支持新的处理过程，他们可以示范新系统的新的 业务处理过程。利用原型，我们可以验证该技术所能够实现的功能。 在分析过程中构建原型（通常称之为发现原型）的主要目的是更好地理解用户的需 求。 在系统分析阶段的原型构建有助于回答两个关键问题，即 “我们是否可以证明这种 技术能够实现我们想让它完成的那些功能”和“我们是否已经构建出一些原型，可以使 用户完全理解新系统的潜在功能”。 ⑤ 产生和评估候选方案 系统的最终设计和实现会有各种不同的方案， 因此，仔细地定义并评估所有的可能 性是很重要的。当需求的优先级确定后，可以产生几个可选方案，消除一些不重要的需 求。此外，技术也可以给系统带来一些解决方案。 在完成这项活动时，应该回答的关键问题是“创建系统的最好方案是什么”。 ⑥ 和管理部门一起复查各种建议 收集信息、定义需求、划分需求的优先级、构建系统原型以及产生和评估各种方案， 所有这些活动都是并行执行的，而分析阶段的最后一项活动（和管理部门一起复查各种 建议）通常是在所有分析活动已经完成或将要完成时进行。管理部门应该可以通过定期 的项目报告了解整个项目的进程。 向资深的主管人员提交一份推荐书是整个项目管理中的一个主要检验点。每一个可 选方案（包括已取消的）都必须探究。 在完成这项活动时，应该回答的关键问题是“我们应不应该继续设计和实现我们提 出的系统”。 （5）详细调研的方法 详细调研的方法包括：1）收集资料；2）发调研表征求意见；3）开调研会；4）访 问；5）深入实际的调研方式。 ① 收集资料。计划、原始凭证、单据和报表等的格式或样本统统收集起来， 以便对 它们进行分类研究。 ② 发调研表征求意见。一种是重点询问，另一种是全面业务需求分析的问卷调研。 ③ 开调研会。一种是按职能部门召开座谈会，另一种是各类人员联合座谈。 ④ 访问。在会后再进行个别访问。 ⑤ 深入实际的调研方式。即参加业务实践。 4． 系统分析 系统分析产生的系统说明书（需求规格说明书）既是后续开发工作的依据，也是衡 量一个信息系统优劣的依据。系统分析是系统开发中最重要也是最困难的阶段。 （1）系统分析的任务 系统分析阶段的基本任务是，系统分析师与用户在一起，充分了解用户的要求，并 把双方的理解用系统说明书表达出来。系统说明书审核通过之后，将成为系统设计的依 据，也是将来验收系统的依据。 系统分析要回答新系统“做什么”这个关键性的问题。 系统分析阶段要通过调查分析，抽象出新系统的概念模型，锁定系统边界、功能、 处理过程和信息结构，为系统设计奠定基础。 系统说明书是这一阶段工作的结晶，它实际上是用户与系统研发人员之间的技术合 同。 （2）系统分析的过程和方法 ① 问题分析 1）问题分析实际上就是需求调研， 需要从各种渠道收集大量资料和信息，从而获得 对业务系统的理解并获得系统原始需求，这些原始需求是进行需求分析并建立系统逻辑 模型的基础。 2）为了帮助用户更好地理解信息系统和信息技术的能力，引导他们发现现行组织管 理和业务处理中所存在的问题，启发他们更好地表达原始需求，可以使用一些需求引导 方法，例如原型法、JAD 会议、观摩法。 3）问题分析时重点明确以下事项： l 需要明确系统建设的背景。 l 在了解背景的基础上，需要进一步了解：本系统解决了用户的什么问题？本系统涉 及什么人、什么单位？本系统建设的目标是什么？范围是什么？成功标准是什么？ l 找出关键利益相关人员及待解决的问题。 l 详细调查和分析业务流程，建立业务流程模型以描述用户处理业务的过程及过程中 数据的流转，快速让分析人员、用户、开发人员对企业业务流程和管理流程达成共 识。 ② 需求分析 1）系统需求就是新系统必须完成的功能或其局限性。系统需求包括功能性需求和非 功能性需求。 l 功能性需求。功能性需求是系统最主要的需求，表达系统必须完成的所有功能的必 要性和相容性，以满足企业完成业务活动和管理的需要。功能性需求包括系统的软 件功能需求和数据需求。 l 非功能性需求。非功能性需求也称为技术性需求，是和环境、硬件和软件有关的所 有可操作目标。通常是响应时间、安全性、可靠性、易用性等技术指标和系统的质 量特性。 2）为了提高需求分析效果， 各种需求分析方法都强调模型的使用，通过建立模型的 方式来描述用户的需求，为用户、开发方及相关参与方提供一个交流的渠道。根据建模 特点，主要有以下几种常用的需求分析方法：面向过程的结构化方法。面向数据的信息 工程方法。基于 UML 的用例驱动方法。基于敏捷过程的用户故事。 根据建模特点，主要有以下几种常用的需求分析方法： l 面向过程的结构化方法。基于自顶向下、逐层分解的方法对数据处理功能进行分析。 数据流图是该方法最重要的模型。 l 面向数据的信息工程方法。该方法关注系统中存储的数据的结构，在分析过程和功 能之前先研究和分析数据需求。实体关系图是该方法最重要的模型。 l 基于 UML 的用例驱动方法。面向对象分析的方法中使用 UML 建立系统的需求模型。 该方法兼顾了系统的功能和数据两方面的需求，是目前最为流行的方法。 l 基于敏捷过程的用户故事。采用非正式的自然语言，以最终用户的角度描述软件功 能的方法。 ③ 需求定义 需求分析是分析人员与用户反复沟通和谈判的过程，一旦双方就系统需求达成一致 意见，接下来应该进行需求定义。需求定义阶段的任务是整理并建立最终的需求模型 ， 详细定义和描述每项需求，确认约束条件及限制，编写需求规格说明。由于需求分析采 用的方法和模型不同，需求定义的内容也有所不同，但基本上都会包括系统功能及流程、 数据存储、人机操作方式等方面的需求细节的规定。 （3）系统说明书 系统说明书是系统分析阶段的技术文档，也是这一阶段的工作报告，是提交审议的 一份工作文件。 ① 系统说明书一旦审议通过，则成为有约束力的指导性文件，成为用户与技术人员 之间的技术合同，成为下阶段系统设计的依据。系统说明书应具有以下特征：正确性。 完整性。一致性。无二义性。可修改性。可跟踪性。 ② 对系统说明书的审议是整个系统研制过程中一个重要的里程碑。系统说明书通常 包括以下三方面的内容： 1）引言。说明系统建设项目名称、目标、功能、背景、引用资料（如核准的计划任 务书、有关业务文件、项目合同等）、本文所用的专门术语等。 2）概述。具体包括： 系统建设项目的主要工作内容。现行系统的调查情况。系统功 能需求。系统数据需求。系统其他需求。 3）实施计划。具体包括：工作任务的分解。进度。预算。 5． 系统设计 系统设计阶段主要解决系统“如何做” 的问题，为后续各项系统实施工作做好具体 实施方案。通常可分为总体设计和详细设计，这两部分工作是互相联系的，需要交叉进 行。 （1）系统设计的目标 系统设计的目标是在保证实现逻辑模型功能的基础上，尽可能提高目标系统的性能， 使所设计的系统安全可靠、易于理解、便于维护并具有良好的经济性，将分析阶段所获 得的系统逻辑模型转换成一个具体的计算机实现方案的物理模型，包括计算机物理系统 配置方案报告和一份系统设计说明书。 系统设计的目标是评价和衡量系统设计方案优劣的基本标准，也是选择系统设计方 案的主要依据。评价与衡量系统设计目标实现程度的主要指标有以下几方面： ① 系统的可靠性。系统的可靠性是指系统抵御外界干扰的能力及受外界干扰时的恢 复能力。 ② 系统的可变更性。系统的可变更性指系统的可维护性或可修改性。 ③ 系统的效率。系统的效率可以通过系统对处理的响应时间或单位时间内处理的业 务量进行衡量。 ④ 系统的通用性。系统的通用性是指同一软件系统在不同使用单位中的可应用程 度。 ⑤ 系统的工作质量。系统的工作质量是指系统处理数据的准确性、输出各种信息的 易懂性和系统操作的方便性等。 （2）系统设计的原则 为保证系统设计的质量，在系统设计时要遵循的原则包括：系统性原则、灵活性原 则、可靠性原则。经济性原则、管理可接受原则。 ① 系统性原则。系统是一个有机整体。 ② 灵活性原则。信息系统是需要修改和维护的。 ③ 可靠性原则。一个成功的信息系统必须具有较高的可靠性，如安全保密性、检错 及纠错能力、抗病毒能力、系统恢复能力等。 ④ 经济性原则。经济性指在满足系统需求的前提下，尽可能减小系统的开销。 ⑤ 管理可接受原则。一个系统能否发挥作用和具有较强的生命力在很大程度上取决 于管理上是否可以接受。 （3）系统设计的内容和步骤 系统设计的主要内容可以概括为：1）系统总体结构设计；2）处理流程设计；3）代 码设计；4）人机界面设计；5）输出设计；6）输入设计；7）数据库设计；8）安全保密 设计；9）系统物理配置方案设计；10）编写系统设计说明书。 6.小结和思考 (1）初步调研 - 目标：掌握用户概况，明确系统初步目标，为可行性研究提供基础。 - 内容：组织概况、现行系统、资源情况等宏观信息。 （2）可行性研究 - 四类分析：经济（成本/效益）、技术（成熟性）、社会（政策/操作）、管理 （支持度）。 - 步骤：目标复查→现行系统研究→逻辑模型→方案评估→开发计划。 - 成果：可行性研究报告（结论分可行、需修改、不可行三类）。 （3）详细调研 - 目标：全面掌握现行系统，为逻辑模型设计打基础。 - 方法：资料收集、调研表、访谈等，需用户参与。 - 关键活动：需求建模、优先级划分、原型验证、候选方案评估。 （4）系统分析 - 任务：明确“做什么”，输出系统说明书（技术合同）。 - 需求分类：功能性（业务必要功能）与非功能性（性能/安全等指标）。 - 方法：业务流程建模、用例驱动、用户故事等。 （5）系统设计 - 目标：解决“如何做”，分总体设计与详细设计。 - 设计原则：系统性、灵活性、可靠性、经济性。 - 内容：总体结构、数据库、人机界面、安全设计等。 5.4 常用方法 1． 应用系统组合法 （1）应用系统组合法（APA）是一种用于评估和管理组织应用系统的方法。 （2）APA 的主要目标是帮助组织管理其应用系统组合，确保应用系统与组织的业务 目标和战略一致，同时降低应用系统的维护成本和风险。 （3）APA 的过程通常包括以下几个步骤：应用系统清单、评估应用系统、分析应用 系统组合、制定优化策略、实施优化计划、监测和评估。 ① 应用系统清单。收集和整理组织的应用系统清单， 包括系统名称、功能描述、技 术平台、使用情况等信息。 ② 评估应用系统。对每个应用系统进行评估， 包括业务价值、技术健康状况、维护 成本、风险等方面的评估。 ③ 分析应用系统组合。根据评估结果， 对应用系统进行分类和分析，识别重复、冗 余或过时的系统，找出存在的问题和瓶颈。 ④ 制定优化策略。根据分析结果，制定优化应用系统组合的策略和计划。 ⑤ 实施优化计划。根据制定的优化策略，实施相应的优化计划。 ⑥ 监测和评估。对优化后的应用系统组合进行监测和评估，确保优化效果的实现， 并根据需要进行调整和改进。 2． TOGAF （1）TOGAF 基础 ① TOGAF 是一种开放式企业架构框架标准，它基于一个迭代的过程模型，由一些 最佳实践和一套可重用的现有架构资产支持，用于设计、评估并建立适合的企业 IT 架构。 ② TOGAF 旨在通过以下 4 个目标帮助企业组织和解决所有关键业务需求： l 确保从关键利益相关方到团队成员的所有用户都使用相同语言，这有助于每个人以 相同的方式理解框架、内容和目标，并让整个企业在同一页面上打破任何沟通障碍。 l 避免被“锁定”到企业架构的专有解决方案，只要该企业在内部使用 TOGAF 而不 是用于商业目的，该框架就是免费的。 l 节省时间和金钱，可以更有效地利用资源。 l 实现可观的投资回报（ROD）。 ③ TOGAF 反映了企业内部架构能力的结构和内容，TOGAF 9 版本包括 6 个组件： l 架构开发方法（ADM）。架构开发方法是 TOGAF 的核心，是一种开发企业架构的 分步方法。 l ADM 指南和技术。这部分包含一系列可用于应用 ADM 的指南和技术。 l 内容框架。包括架构工件的结构化元模型、可重用架构构件块的使用以及典型架构 可交付成果的概述。 l 企业连续体和工具。这部分讨论分类法和工具，用于对企业内部架构活动的输出进 行分类和存储。 l TOGAF 参考模型。TOGAF 技术参考模型和集成信息基础设施参考模型。 l 架构能力框架。这部分讨论在企业内建立和运营架构实践所需的组织、流程、技能、 角色和职责。 （2）架构开发方法 ① 架构开发方法（ADM）对开发企业架构所需执行的各个步骤以及它们之间的关系 进行了详细的定义，同时它也是 TOGAF 规范中最核心的内容。 ② 架构开发方法是企业连续体得以顺利演进的保障，而作为企业连续体在现实中的 实现形式或信息载体，企业架构资源库也与架构开发方法有着千丝万缕的联系。 ③ ADM 的全生命周期模型将架构开发全生命周期划分为预备阶段、需求管理、架 构愿景、业务架构、信息系统架构（应用和数据）、技术架构、机会和解决方案、迁移 规划、实施治理、架构变更治理 10 个阶段，这 10 个阶段是反复迭代 的过程。 ④ ADM 三个级别的迭代概念：基于架构开发整体的迭代。多个开发阶段间的迭代。 在一个阶段内部的迭代。 ⑤ ADM 各个开发阶段的主要活动如表所示： 架构开发阶段 架构开发阶段内的活动 预备阶段 为实施成功的企业架构项目做好准备，包括定义组织机构、特 定的架构框架、架构原则和工具。 需求管理 完成需求的识别、保管和交付，相关联的架构开发阶段则按优 先级顺序对需求进行处理；TOGAF 项目的每个阶段都是建立在 业务需求之上并且需要对需求进行确认。 阶段 A：架构愿景 设置 TOGAF 项目的范围、约束和期望。创建架构愿景， 包括定 义利益相关者、确认业务上下文环境、创建架构工作说明书、 取得上级批准等。 阶段 B：业务架构；阶 段 C：信息系统架构（应 用和数据）：阶段 D： 技术架构 从业务、信息系统和技术三个层面进行架构开发，在每一个层 面分别完成以下活动：开发基线架构描述，开发目标架构描述， 执行差距分析。 阶段 E：机会和解决方 案 进行初步实施规划，并确认在前面阶段中确定的各种构建块的 交付物形式，确定主要实施项目，对项目分组并纳入过渡架构， 决定途径（制造/购买/重用、外包、商用、开源） ，评估优先顺 序，识别相依性。 阶段 F：迁移规划 对阶段 E 确定的项目进行绩效分析和风险评估，制订一个详细 的实施和迁移计划。 阶段 G：实施治理 定义实施项目的架构限制，提供实施项目的架构监督，发布实 施项目的架构合同，监测实施项目以确保符合架构要求。 阶段 H：架构变更治理 提供持续监测和变更管理的流程，以确保架构可以响应企业的 需求并且将架构对于业务的价值最大化。 3． 面向服务的架构 面向服务的架构（SOA）是一种软件架构设计的模型和方法论。 从广义上来看，SOA 是指一种新的组织应用架构和组织 IT 基础架构，它可以使组织 实现跨应用、跨部门、跨组织甚至跨行业之间的离散系统互连。 狭义的 SOA 是指一种软件架构，它可以根据需求，通过网络对松散耦合的粗粒度应 用组件进行分布式部署、组合和使用。 （1）SOA 的设计原则包括：明确的接口定义。自包含与模块化。粗粒度。松耦合。 互操作性、兼容性和策略声明。 ① 明确的接口定义。接口需满足稳定、明确、封装性等要求。 ② 自包含与模块化。实现服务的功能实体是完全独立自主的， 独立进行部署、版本 控制、 自我管理和恢复。 ③ 粗粒度。服务数量不应太多，依靠消息交互而不是远程过程调用。 ④ 松耦合。减少各个服务间的相互依赖和影响， 各个服务的位置、实现技术、当前 状态以及私有数据，对服务请求者不可见。 ⑤ 互操作性、兼容性和策略声明。 （2）SOA 的主要技术内容包括：服务封装。服务编排。服务注册与发现。服务治理。 服务安全。服务可靠性和可用性。 ① 服务封装。服务封装是将业务功能封装成标准化服务的过程，每个服务都具有明 确定义的接口，以供其他服务调用。 ② 服务编排。服务编排是指将多个服务组合成一个复杂业务流的过程。 ③ 服务注册与发现。服务注册是指将服务的信息存储到注册中心的过程，以便其他 服务可以查找和调用。 ④ 服务治理。服务治理是 SOA 的核心内容之一，它负责服务的生命周期管理、服 务质量保障、服务间协同等。 ⑤ 服务安全。服务安全是 SOA 的一个重要方面，它负责保障服务的可用性、机密 性和完整性。 ⑥ 服务可靠性和可用性。服务的可靠性和可用性是 SOA 的重要指标之一，它关系 到服务的稳定性和可靠性。 （3）SOA 的应用场景 SOA 适用于多种场景，其主要适用场景包括：组织级应用集成。业务流程管理。系 统扩展和重用。云计算和微服务架构。跨平台集成。 总体来说，SOA 适用于那些要求灵活、可扩展、可重用的组织级系统，尤其是在需要 集成多个系统或服务、处理复杂业务流程、使用云计算资源或进行跨平台集成的场景中。 4.小结和思考 （1）应用系统组合法（APA） - 目标：确保应用系统与业务战略一致，降低维护成本与风险。 - 步骤：清单→评估→分析→优化策略→实施→监测。 （2）TOGAF 框架 - 核心：架构开发方法（ADM）， 含 10 阶段（预备→需求管理→架构愿景→业 务/信息/技术架构→迁移→治理等），强调迭代。 - 目标：统一语言、避免锁定、节省成本、提升 ROI。 （3）面向服务的架构（SOA） - 原则：松耦合、粗粒度、互操作性。 - 技术：服务封装、注册发现、治理、安全。 - 场景：系统集成、业务流程管理、云计算/微服务支持。 5.5 软件工厂 软件工厂是一种软件开发的组织和管理模式。基于软件工厂， 可实现模板一次编写， 生成多样化产品。软件工厂能够提高软件开发的效率、质量和可控性，使得开发过程更 加工业化和可持续。它适用于大规模软件开发项目和组织，尤其在需要快速交付、高质 量和可扩展性的场景下具有明显的优势。 1． 发展现状 （1）软件工厂概念 l 软件工厂的核心思想是将软件开发视为工业化的生产过程，类似传统制造业生产线。 l 软件工厂强调规模化和标准化，通过制定统一的开发流程、规范的编码标准和代码 复用，实现高度的可重复性和一致性。 l 软件工厂的概念是将软件开发过程转化为工业化的生产过程，通过规模化、标准化、 自动化和协作等手段来提高软件开发的效率、质量和可控性。 （2）软件工厂构成 ① 专业人员。软件工厂的核心资源。 ② 基础设施和硬件。软件工厂顺利运行的基石。 ③ 工具和技术。软件工厂的辅助工具和支持系统。 ④ 流程规范和方法论。软件工厂的运作指南。 ⑤ 质量管理。软件工厂保证软件交付质量的一套保证机制。 这五方面相互配合，共同构成了一个高效、可靠的软件开发组织。通过合理的组织 和管理，软件工厂能够提高开发效率和质量，实现软件开发过程的工业化和规模化。 （3）国内外发展历程 软件工厂概念成型于 20 世纪 70 年代。20 世纪 90 年代进入了工业化和自动化的阶 段。21 世纪初，敏捷开发方法成为软件工厂的主流开发方法之一。 21 世纪 10 年代，DevOps 和持续集成/持续交付（CICD）的概念开始受到广泛关注。 DevOps 强调开发和运维团队之间的协作和沟通，以实现快速、可靠的软件交付。CI/CD 则强调通过自动化工具和流程，实现持续集成、持续测试和持续部署，提高软件交付的 质量和效率。 2． 与传统开发对比 软件工厂更加注重灵活性、自动化和创新，强调持续快速交付、质量保证和高效协 作等。 （1）敏捷交付 敏捷交付强调通过迭代、协作和自组织的方式，快速响应变化并持续交付软件产品。 主要包括的关键实践和原则包括：1）敏捷开发方法；2）用户需求和产品回溯日志； 3）迭代开发；4） 自动化测试；5）持续集成和持续交付（CICD）；6）产品质量和用户 反馈；7）团队协作和沟通；8）可视化和透明度。 这些实践共同推动了软件工厂的敏捷交付能力，使其能够快速响应变化、持续交付 高质量的软件产品。 （2）流水线作业 软件工厂的流水线作业是指将软件开发过程划分为不同的环节和任务，并通过流水 线的方式将这些环节和任务连接起来，以实现高效、规范和持续的软件开发。 流水线作业主要内容包括： ① 环节划分。首先，将软件开发过程划分为多个环节，每个环节负责特定的任务， 并有明确的输入和输出。 ② 任务定义。对每个环节中的任务进行明确的定义。 ③ 流转规则。定义任务的流转规则。 ④ 并行处理。通过并行处理来提高开发效率。 ⑤ 自动化支持。为流水线作业提供自动化支持，包括自动化工具和流程。 ⑥ 监控和优化。对流水线作业进行监控和优化，及时发现和解决问题。 通过软件工厂流水线作业的实践，可提高开发效率，降低开发成本，并确保软件质 量和交付时间的可控性。 （3）安全可靠 安全可靠是指在软件开发和交付过程中，保障软件系统的安全性和可靠性。软件工 厂确保安全可靠性的关键实践和原则主要包括： 安全可靠是指在软件开发和交付过程中，保障软件系统的安全性和可靠性。软件工 厂确保安全可靠性的关键实践和原则主要包括： ① 安全开发实践。软件工厂通过采用安全开发实践来保障软件系统的安全性。包括： 安全需求分析、安全设计原则、安全编码规范、安全测试和审计。 ② 数据和隐私保护。软件工厂需要重视数据和隐私保护， 确保用户的数据得到合理 的保护和使用。包括：数据加密、访问控制、隐私保护。 ③ 持续集成和持续交付。软件工厂倡导持续集成和持续交付（CVCD），这有助于 减少人为错误和安全漏洞的引入，并提高系统的可靠性。包括：自动构建和测试、持续 部署和发布、监控和告警。 ④ 团队安全培训和安全意识。软件工厂重视团队的安全培训和安全意识， 确保团队 成员具备必要的安全知识和技能。包括：安全培训、安全意识。 （4）协同开发 软件工厂的协同开发是指团队成员通过有效的协作和协同工具，共同参与软件开发 项目，共同解决问题、分享知识和推动项目进展。协同开发的关键实践和原则主要包括： ① 团队协作和沟通。软件工厂的协同开发强调团队成员之间的协作和沟通。包括： 日常站会、迭代评审会、冲刺回顾会。 ② 共享知识和经验。软件工厂的协同开发强调共享知识和经验， 以提高团队的整体 能力和效率。包括：文档和知识库、代码审查、技术分享会。 ③ 协同工具和平台。软件工厂的协同开发需要借助适当的协同工具和平台， 包括即 时通信工具（如微信、钉钉等） 、在线文档协作工具（如 WPS 等）、代码托管和协作平 台、团队协作工具（如金山协作）、数字协同平台（如 WPS365 等）。 3． 建设方法 （1）组织建设 ① 软件工厂的组织建设是确保软件开发团队高效运作和实现项目目标的关键要素 之一。组织建设的重要性主要体现在：一是明确分工和责任。二是提高团队协作。三是 提升决策效率。 ② 组织建设的策略和最佳实践方法包括：1）确定组织结构；2）制定明确的岗位和 职责；3）设计有效的流程和规范；4）优化沟通渠道和协作工具；5）培养领导力和团队 文化；6）定期评估和改进。 ③ 组织建设也要做好人才培养和团队建设。 （2）资源部署 通过资源部署，可以更好地规划和管理团队成员的工作和资源，提高资源的利用率 和项目的整体效益。合理的资源部署可以减少项目风险和延迟，确保项目按时交付，并 满足客户的需求和期望。 软件工厂资源部署的策略和最佳实践方法，这些策略和方法可以帮助组织高效地规 划和分配资源，包括：1）项目规划和优先级；2）人员分配和技能匹配；3）工作量估计 和调整；4）工具和设备支持；5）项目管理和协调；6）优先级和变更管理。 （3）业务管理 软件工厂的业务管理主要由以下模块构成：1）项目管理模块； 2）资源管理模块；3） 质量管理模块；4）绩效管理模块；5）沟通与协作模块；6）数据分析与报告模块。 实现业务管理主要采取的步骤包括：1）确定需求和目标；2）选取合适的软件解决 方案；3）进行系统定制和开发；4）进行系统测试和验证；5）系统部署和培训；6）监 控和维护。 （4）体系保障 软件工厂的体系保障是一个全面的、结构化的系统，旨在确保软件开发和交付过程 的质量和可靠性。 首先，软件工厂的体系保障需要建立一个质量管理体系。这个体系包括质量策略、 质量目标和质量标准的制定，以及质量管理流程和程序的定义。 其次，软件工厂的体系保障需要制定和实施流程规范。流程规范是为了确保团队成 员在软件开发过程中按照标准的流程和方法进行工作。 资源配置也是软件工厂体系保障的重要组成部分。它涉及人员、设备和工具的合理 配置，以支持软件开发和交付过程。必须确保团队成员具备所需的技能和知识，同时提 供适当的工作环境和工具。 质量控制是软件工厂体系保障的核心内容。质量控制措施可以包括代码审查、单元 测试、集成测试、系统测试和用户验收测试等。 持续改进是软件工厂体系保障的关键要素之一。它涉及不断识别和改进软件开发和 交付过程中的问题和风险。 此外，软件工厂的体系保障还需要建立一套完善的文档和记录体系，用于记录和追 溯软件开发和交付过程中的关键信息。 总之，软件工厂的体系保障是通过建立质量管理体系、流程规范、资源配置、质量 控制和持续改进等措施，确保软件开发和交付过程的质量和可靠性。它需要全面考虑软 件开发的各个方面，并与团队成员密切合作，以实现高质量的软件产品和服务。 4． 应用场景 （1）软件开发组织 软件开发组织项目类型包括嵌入式软件开发、桌面应用软件开发、Web 应用软件开 发、移动应用软件开发等。 嵌入式软件开发中的软件工厂应用如下： l 建立规范化的开发流程和标准化的开发规范。 l 使用版本控制系统来管理嵌入式软件的源代码和配置文件等资源。 l 建立自动化构建和测试环境。 l 将嵌入式软件拆分为模块，并使用模块化设计和开发方法。 l 建立自动化部署和配置管理流程。 l 将持续集成和持续交付的理念引入嵌入式软件开发中。 l 利用适合嵌入式软件开发的工具和框架。 相较于嵌入式软件开发，桌面应用软件、Web 应用软件、移动应用软件等的开发环 境不同，需要软件工厂配置适合各类软件开发的集成开发环境，例如 （2）软件项目交付 ① 软件项目交付阶段确保服务安全上线运营，具体内容包括：1）发布管理。2） 安 全性检查。3）事件响应计划。 ② 软件发布后运营阶段的具体内容包括：1）安全监控；2）安全运营；3）风险评 估；4）应急响应；5）升级与变更管理；6）服务与技术支持；7）运营反馈。 5.小结和思考 （1）软件工厂概念 - 工业化软件开发模式，强调标准化、自动化、协作，提升效率、质量与可控 性。 - 核心构成：专业人员、基础设施、工具技术、流程规范、质量管理。 （2）与传统开发对比 - 优势：敏捷交付（迭代、自动化测试、CI/CD）、流水线作业（环节划分、自 动化）、安全可靠（安全开发、数据保护）、协同开发（团队协作、共享知识）。 （3）建设方法 - 关键模块：组织建设（分工/流程优化）、资源部署（技能匹配/优先级管理）、 业务管理（项目/质量管理）、体系保障（质量体系/持续改进）。 （4）应用场景 - 适用领域：嵌入式/Web/移动应用开发。 - 项目交付：安全上线（发布管理/监控）、运营阶段（风险评估/应急响应）。