一、信息系统
1.信息系统的定义
信息系统是由硬件、软件、数据、人员和流程组成的集合体，用于收集、处理、存储和分发信息，支持组织决策、协调和控制。
信息系统具有三个维度：组织、管理、信息技术。
信息系统是一组相互关联的元素或组件，它们收集（输入）、操作（处理）、存储和传播（输出）数据信息，并提供满足目标的反馈机制。
输入：信息系统通过各类设备或界面（如键盘、传感器、扫码枪等）接收原始数据。例如超市收银台扫描商品条形码，将价格和名称录入系统。
处理：系统对输入的数据进行计算、分类或分析。例如超市系统将扫描的商品价格累加，计算总金额，或根据会员等级自动折扣。
存储：处理后的数据被保存到数据库或云端。例如交易记录、会员信息会存储在系统中，便于后续查询或生成报表。
输出：将处理结果以可视化的形式呈现。例如收银小票显示购物清单和总价，或后台生成每日销售统计图表。
反馈：系统根据输出结果调整后续操作。例如库存不足时自动触发补货提醒，或根据销售数据动态调整促销策略。
信息系统的五个基本功能包括：输入、存储、处理、输出和控制。
- 输入功能：输入功能决定于系统所要达到的目的及系统的能力和信息环境的许可。
- 存储功能：存储功能指的是系统存储各种信息资料和数据的能力。
- 处理功能：处理功能指的是对数据进行加工、处理和计算，以产生有用的信息。
- 输出功能：信息系统的目的就是保证实现最佳的输出。
- 控制功能：控制功能对构成信息系统的各种信息处理设备进行控制和管理，对整个信息加工、处理、传输、输出等环节通过各种程序进行控制。
2.信息系统的发展
诺兰将计算机信息系统的发展道路划分为六个阶段：
- 初始阶段
- 传播阶段
- 控制阶段
- 集成阶段
- 数据管理阶段
- 成熟阶段
初始阶段：组织对信息技术的应用处于实验性探索阶段，技术投入有限，通常由个别部门或项目驱动。缺乏整体规划，系统功能简单，主要用于解决局部问题。管理层对技术的认知不足，投资回报率不明确。
传播阶段：信息技术应用开始扩散到多个部门，出现自发性的技术采纳现象。系统数量和用户规模快速增长，但可能伴随重复建设或资源浪费。管理层逐渐意识到技术的重要性，但尚未建立统一的管理标准。
控制阶段：组织开始对信息技术应用进行集中管控，制定标准化政策和预算控制机制。重点转向成本效益分析，可能缩减非必要项目。此阶段通常伴随首次大规模系统整合，建立专门的信息技术管理部门。
集成阶段：通过统一的技术架构实现系统互联互通，数据共享程度显著提高。企业级应用系统（如ERP）开始部署，业务流程与信息系统深度结合。投资重点转向基础设施升级和跨部门协同解决方案。
数据管理阶段：信息资源被视作战略资产，建立完善的数据治理体系。数据仓库和分析工具得到广泛应用，支持决策优化。信息系统的管理从技术导向转向业务价值导向，注重数据质量与安全。
成熟阶段：信息技术与业务战略完全融合，形成动态调整的能力。系统具备高度灵活性和可扩展性，能快速响应市场变化。组织建立起完善的技术创新机制，IT投资与业务目标持续对齐。
3.信息系统的结构
信息系统的结构分为物理结构与逻辑结构两种。物理结构是指不考虑系统各部分的实际工作与功能结构，只抽象地考察其硬件系统的空间分布情况。逻辑结构是指信息系统各功能子系统的综合体。
3.1 信息系统的物理结构
按照信息系统硬件在空间上的拓扑结构，其物理结构一般可分为集中式与分布式两类。
| 主题 | 内容 |
| 集中式结构 |
集中式结构指物理资源在空间上集中配置。早期的单机系统是最典型的集中式结构，它将软件、数据与主要外部设备集中在一套计算机系统中。由分布在不同地点的多个用户通过终端共享资源的多用户系统，也属于集中式结构。
集中式结构多用于传统银行、电信等行业。 |
| 分布式结构 |
分布式结构指通过计算机网络把不同地点的计算机硬件、软件、数据等资源联系在一起，实现不同地点的资源工程。各地的计算机系统既可以在网络系统的统一管理下工作，也可以脱离网络环境利用本地资源独立运作。
|
一个标准的分布式系统在没有任何特定业务逻辑约束的情况下，具有分布性、对等行、并发性、缺乏全局时钟，故障多样等特性。
- 分布性。分布式系统中的多台计算机都会在空间上随意分布，同时，计算机的分布情况也会随时变动。
- 对等性。分布式系统中计算机没有主从之分，组成分布式系统的所有计算机节点都是对等的。
- 并发性。在一个计算机网络中，程序运行过程中的并发性操作是非常常见的。例如，同一个分布式系统的多个节点，可能并发地操作一些共享资源，诸如数据库或分布式存储等。如何准确并高效地协调分布式并发操作是分布式结构中最大的挑战之一。
- 缺乏全局时钟。典型的分布式系统由一系列在空间上随意分布的多个进程组成，进程之间通过交换消息来相互通信。在分布式系统中，很难定义两个事件的先后顺序，原因是分布式系统缺乏一个全局的时钟序列控制。
- 故障多样。组成分布式系统的所有计算机都可能发生任何形式的故障。
3.2信息系统的逻辑结构
随着信息技术的不断发展，分布式的应用表现层物理结构已经成为信息系统的主流，结合逻辑结构，信息系统的通用结构自底向上可分为基础设施层、资源管理层、中间件层、业务逻辑层、应用表现层五个层次。
-
基础设施层。基础设施层是系统整体架构的底层技术基础，基于多种软件、硬件、网络和信息安全技术之间的相互作用支撑整个管理系统的正常应用，包括信息感知设备、网络传输设备、存储设备、计算设备等。
-
资源管理层。主要包括操作系统、数据库等，负责各类资源的管理与调度。
-
中间件层。主要保障信息（数据）的传输、共享，提供某一类特定基础数据服务，例如传输中间件、交易中间件、GIS中间件、J2EE架构等。
-
业务逻辑层。主要是通过软件研发，创建统一的业务流程驱动引擎，例如工作流引擎、报表引擎、交易处理引擎等。
-
应用表现层。主要负责用户的交互界面，通过UI设计将信息交互在客户端进行展示。
4.信息系统的分类与建设原则
4.1信息系统的分类
按照信息系统的通用架构，信息系统工程建设项目交付的内容主要包括机房基础设施、物理资源、虚拟资源、平台资源、应用和数据等。
- 机房基础设施。主要指机房基础环境、安防系统、电气系统、精密空调系统、环境监测系统、消防系统。
- 物理资源。主要指网络、服务器、存储、终端、外设等硬件。
- 平台资源。主要指支撑应用系统运行的基础软件，如操作系统、数据库、中间件等。
- 应用。主要指面向各类应用的软件系统。如财务软件、人力资源管理软件、办公自动化软件、监控软件、流程系统软件、安全分析软件等。
- 数据。主要是指业务数据、运维数据、安全数据等。
从工程建设的角度，可以将信息系统分为：信息网络系统、信息资源系统和信息应用系统。
- 信息网络系统，是指以信息技术为主要手段建立的信息处理、传输、交换和分发的计算机网络系统。信息网络系统为信息资源系统和信息应用系统提供基础的网络平台，其工程建设的核心是网络。
- 信息资源系统，是指以信息技术为主要手段建立的信息资源采集、存储、处理的资源系统。信息资源系统是承载并管理基础设施、物理资源、虚拟资源、平台资源、应用和数据等资源的系统，在当前云计算、大数据的发展角度，其工程建设的核心是数据资源平台和云资源系统（包括云服务、云数据中心）。
- 信息应用系统，是指以信息技术为主要手段建立的各类业务管理的应用系统，以满足业务处理、信息管理需要，其工程建设的核心是软件。
4.2信息系统的建设原则
-
高层管理人员介入原则
-
用户参与建设原则
-
自顶向下规划原则
-
工程化原则
-
其他原则
对于信息系统建设，人们还从不同角度提出了一系列原则，主要包括：创新性原则，用户体现信息系统的先进性；整体性原则，用于体现信息系统的完整性；发展性原则，用于体现信息系统的前瞻性；经济性原则，用于体现信息系统的实用性等。
二、系统工程
1.系统工程方法
系统工程方法针对将要解决的问题及相关情况进行分门别类地处理并确定边界，强调各门类之间和各门类内部因素之间内在联系的完整性和整体性。系统工程方法主要包括以下几种。
1.1霍尔三维结构
霍尔三维结构集中体现了系统工程方法的系统化、综合化、最优化、程序化和标准化等特点，是系统工程方法论的重要基础。【时间维、逻辑维、知识维】
| 主题 | 内容 |
| 时间维 | 时间维标识系统工程活动从开始到结束按时间顺序排列的全过程，分为规划、制定方案、研制、生产、安装、运行、更新七个时间阶段。 |
| 逻辑维 | 逻辑维是指时间维的每个阶段内所要进行的工作内容和应该遵循的思维程序，包括问题确定、目标确定、系统综合、系统分析、方案选择、评价、决策、实施计划七个逻辑步骤。 |
| 知识维 | 知识维需要运用包括工程、医学、建筑、商业、法律、管理、社会科学、艺术在内的各种知识和技能。霍尔三维结构形象地描述了系统工程研究的框架，对其中任意一个阶段和步骤又可以进一步展开，形成分层次的树状体系。 |
1.2 切克兰德方法
切克兰德认为完全按照解决工程问题的思路来解决社会问题或“软科学”问题，会碰到许多困难，尤其是在设计价值系统、模块化和最优化等步骤方面，有许多因素很难进行定量分析。切克兰德把霍尔方法称为“应科学”，他提出来自己的方法论，并称之为“软科学”方法论。
切克兰德方法将工作过程分为以下七个步骤：
| 主题 | 内容 |
| 认识问题 | 收集与问题相关的信息，表达问题现状，寻找构成和影响因素及其关系，以便明确系统问题结构、现存过程及其相互之间的不适应之处，确定有关的行为主体和利益主体。 |
| 初步定义 | 初步弄清、改善与现状有关的各种因素及其相互关系。为系统发展及其研究确立各种基本的看法，并尽可能选择出最合适的基本观点。 |
| 建立概念模型 | 在不能建立精确数学模型的情况下，用结构模型或语言模型来描述系统的现状。概念模型基于初步定义，是通过系统化语言对问题抽象描述的结构，其结构及要素必须符合初步定义的思想，并能实现其要求。 |
| 比较及探寻 | 将现实问题和概念模型进行对比，找出符合决策者意图且可行的方案或途径。有时通过比较，需要对根底定义的结果进行适当修正。 |
| 选择 | 针对比较结果，考虑有关人员的态度及其他社会、行为等因素，选出现实可行的改善方案。 |
| 设计与实施 | 通过详尽和有针对性的设计，形成具有可操作性的方案，并使得有关人员乐于接受和愿意为方案的实现竭尽全力。 |
| 评估与反馈 | 根据在实施过程中获得的新知识，修正问题描述、根底定义及概念模型等。 |
1.3 并行工程方法
并行工程是对产品及其相关过程（包括制造过程和支持过程）进行并行、集成化处理的系统方法和综合技术。
并行工程的目标是提高质量、降低成本、缩短产品开发周期和产品上市时间。
并行工程的具体做法是：在产品开放初期，组织多种智能协同工作的项目组，使有关人员从一开始就获得对新产品需求的不要求和信息，积极研究涉及本部门的工作业务，并将相应的要求提供给设计人员，使许多问题在开发早期就得到解决，从而保证了设计的质量，避免了大量的返工浪费。
并行工程强调一下三点：
- 在产品设计开发期间，将概念设计、结构设计、工艺设计、最终需求等结合起来，保证以最快的速度按要求的质量完成。
- 各项工作由与此相关的项目小组完成。进程中小组成员各自安排自身的工作，但可以随时或定期反馈信息，并对出现的问题协调解决。
- 依据适当的信息系统工具，反馈与协调整个项目的进行。利用现代信息技术，在产品的研制与开发期间，辅助项目进程的并行化。
1.4 综合集成法
1990年初，钱学森等提出从系统的本质出发对系统进行分类的新方法，首次公布了“开放的复杂巨系统”这一新的科学领域及其基本观点，并首次把处理开放的复杂巨系统的方法命名为从定性到定量的综合集成法。
从系统的本质出发，根据组成子系统及子系统种类的多少和它们之间关联关系的复杂程度，可以把系统分为简单系统和巨系统两大类。
- 如果组成系统的子系统数量比较少，子系统之间的关系比较单纯，这样的系统称为简单系统，如一台测量仪器。
- 如果子系统数量巨大（例如成千上万），则称作巨系统。
- 如果巨系统中子系统种类不太多（几种、几十种），且它们之间的关联关系又比较简单，就称作简单巨系统，如激光系统。
- 如果巨系统中子系统种类很多并有层次结构，它们之间的关联关系又很复杂，这就是复杂巨系统，如果这个系统又是开放的，就称作开放的复杂巨系统。
开放的复杂巨系统的一般原则与一般系统论的原则相一致：一是整体论原则；二是相互联系原则；三是有序性原则；四是动态原则。
开放的复杂巨系统的主要性质可以概括为：
- 开放性。系统对象及其子系统与环境之间有物质、能量、信息的交换。
- 复杂性。系统中子系统的种类繁多，子系统之间存在多种形式、多种层次的交互作用。
- 进化与涌现性。系统中子系统或基本单元之间的交互作用，从整体上演化、进化出一些独特的新性质，如通过自组织方式形成某种模式。
- 层次性。系统部件与功能上具有层次关系。
- 巨量性。数目极其巨大。
综合集成法的主要特点有：
- 定性研究与定量研究有机结合，贯穿全过程；
- 科学理论与经验知识结合，把人们对客观事物的知识综合集成起来解决问题；
- 应用系统思想把多种学科结合起来进行综合研究；
- 根据复杂巨系统的层次结构，把宏观研究与微观研究统一起来；
- 必须有大型计算机信息系统支持，不仅要有管理信息系统、决策支持系统等功能，而且还要包括综合集成的功能。
1.5 WSR系统方法---wuli、shili、renli
WSR是将物理、事理、人理三者合理配置、有效利用以解决问题的一种系统方法论，由中国著名系统科学家顾基发教授和朱志昌博士于1994年在英国HULL大学提出的。
WSR方法论的一般工作过程包含理解意图、制定目标、调查分析、构造策略、选择方案、协调关系和实现构想七个步骤。其中协调关系始终贯穿于整个过程。
2.系统工程生命周期
系统工程生命周期一般包括7个阶段。
| 主题 | 内容 |
| 探索性研究阶段 | 相当于“头脑风暴+可行性摸底”。先搞清楚谁需要这个系统、他们到底想要什么，再看看有没有新技术或创意能实现。很多创新项目在这里就定型了，比如新能源车的早期概念验证。 |
| 概念阶段 | 把模糊的需求变成具体方案。比如明确“要造一辆续航800公里的电动车”，并设计出初步架构。这个阶段会把前期研究的成果细化成可落地的蓝图，同时把所有需求写进文档备案。 |
| 开发阶段 | 真刀真枪开始“搭积木”。根据方案设计详细计划，搭建系统原型，反复测试验证。这个阶段最灵活——可以用瀑布模型、敏捷开发，甚至自创方法，只要能做出符合需求的系统就行。 |
| 生产阶段 | 从“样品”到“量产”。把开发好的系统批量制造出来，同时检查质量、优化成本。如果发现生产中出问题（比如零件不合格），可能要回炉重造，甚至重新验证整个系统。 |
| 使用阶段 | 系统正式“上岗服务”。在实际环境中运行，满足用户日常需求。期间会定期升级（比如手机系统更新），通过小改动提升性能或修复漏洞。 |
| 保障阶段 | 当系统的“终身管家”。负责维护、维修、优化运行效率，延长使用寿命。比如给老设备加装新模块，或者通过软件更新降低能耗。 |
| 退役阶段 | 系统的“谢幕仪式”。当它完成使命或技术过时，就要安全退出——数据归档、硬件回收、服务终止。现在很多国家强制要求设计时就规划好退役方案，避免电子垃圾污染。 |
3.生命周期方法
| 主题 | 内容 | 考点 |
| 计划驱动方法 | 以需求、设计、构建、测试、部署为传统范式，强调系统化流程、文档完整性、需求可追溯性和事后验证，适用于大型团队项目。 | 传统开发流程、文档管理、需求追溯性 |
| 渐进迭代式开发（IID） | 从20世纪60年代开始使用，通过初始能力逐步交付，目标是快速产生价值和响应能力，适用于需求不明确或需引入新技术的小型系统。 | 迭代开发、快速交付、灵活性；适合较小的、不太复杂的。 |
| 精益开发 | 起源于丰田“准时化”哲学，目标是消除浪费、提高效率，聚焦客户价值，应用于制造、医疗、产品开发等领域。 | 动态的、知识驱动的、以客户为中心 |
| 敏捷开发 | 强调灵活性和快速交付，欢迎需求变更，周期短（几周到几个月），团队协作和面对面沟通是关键。 | 敏捷原则、迭代周期、团队协作 |
4.信息系统生命周期
信息系统从产生到消亡的整个过程称为信息系统的生命周期。一般来说信息系统的生命周期可分为五个阶段，分别是系统规划、系统分析、系统设计、系统实现、系统运行与评价。
| 特征 | 定义 | 通俗理解 |
| 系统规划 | 信息系统规划是系统建设的起始阶段，作用是指明信息系统在组织经营战略中的作用和地位，指导信息系统后续的实现与开发。一个完整的系统规划，应当包括信息系统的目标、总体框架、组织结构和管理流程、实施计划和技术规范等。欢迎需求变更，即使是在项目开发后期。敏捷流程利用需求变更帮助客户获得竞争优势。 | 相当于“画蓝图”。明确信息系统的目标和框架，就像盖房子前确定用途和风格，允许后续调整需求以适应变化。 |
| 系统分析 | 系统分析阶段的目标是为系统设计阶段提供系统的逻辑模型，主要任务是在可行性分析和总体规划的基础上，对现有系统进行进一步的详细调查，并整理成规范的文档资料；对使用信息系统的组织的结构、业务流程和经营管理，以及信息需求与处理的现状和问题进行分析，为系统设计提供依据。 | 相当于“做调研”。深入调查现有系统和业务需求，整理成文档，为设计提供基础，就像盖房前了解地形和使用需求。 |
| 系统设计 | 系统设计是信息系统建设过程中的另一个重要阶段。在这一阶段，要根据系统分析的结果，设计出信息系统的实施方案，从而为程序员提供清晰而完整的物理设计说明。 | 相当于“出施工图”。根据调研结果设计具体实施方案，为开发人员提供详细的设计说明，就像盖房前画出施工图纸。 |
| 系统实现 | 系统实现阶段的任务是将设计文档变成能在计算机上运行的信息系统。 | 相当于“施工建设”。将设计转化为可运行的系统，就像按图纸把房子建起来。 |
| 系统运行与评价 | 系统投入运行后，需要经常进行维护和评价，记录系统运行的情况，根据一定的规则对系统进行必要的修改，评价系统的工作质量和经济效益。 | 相当于“入住后维护”。系统上线后持续维护和评估效果，根据反馈调整优化，确保其有效运行并创造价值。 |
三、软件工程
1.架构设计
1.1 软件架构风格
- 数据流风格。包括批处理序列和管道/过滤器两种。
- 调用/返回风格。包括主程序/子程序、数据抽象和面向对象，以及层次结构。
- 独立构件风格。包括进程通信和事件驱动的系统。
- 虚拟机风格。包括解释器和基于规则的系统。
- 仓库风格。包括数据库系统、黑板系统和超文本系统。
数据流风格
核心思想是数据在不同组件间流动处理。
- 批处理序列：数据按固定步骤顺序处理，如传统数据处理系统。
- 管道/过滤器：数据通过多个独立过滤器（组件）流动，每个过滤器处理并传递数据，如Unix命令行工具。
调用/返回风格
强调组件间的层级调用关系。
- 主程序/子程序：主程序调用子程序完成功能，如C语言程序。
- 数据抽象/面向对象：对象封装数据和方法，通过接口交互，如Java类设计。
- 层次结构：系统分层，每层为上层提供服务，如OSI网络模型。
独立构件风格
组件独立运行，通过特定机制协作。
- 进程通信：独立进程通过消息传递交互，如微服务架构。
- 事件驱动系统：组件响应事件触发动作，如GUI应用。
虚拟机风格
通过虚拟执行环境实现灵活性。
- 解释器：解析并执行指令，如Python解释器。
- 基于规则的系统：按规则集动态执行，如专家系统。
仓库风格
围绕中央数据存储构建。
- 数据库系统：数据集中管理，如MySQL。
- 黑板系统：组件通过共享黑板交换数据，如语音识别系统。
- 超文本系统：非线性信息链接，如网页导航。
记忆技巧
- 关键词联想：每类风格提取核心词（如“流动”“调用”“独立”“虚拟”“仓库”）。
- 对比记忆：区分“数据流”（流动处理）与“仓库”（集中存储）。
- 实例关联：结合常见技术（如Unix管道、微服务）加深理解。
1.2 软件架构评估
评估方法主要可以归纳以下三类：基于调查问卷（或检查表）的方法、基于场景的方式和基于度量的方式。这三种评估方式中，基于场景的评估方法最为常用。
基于场景的方式主要包括：架构权衡分析法、软件架构分析法和成本效益分析法。在架构评估中，一般从刺激、环境和响应三个方面对场景进行描述。刺激是场景中解释或描述项目干系人怎样引发与系统的交互部分，环境描述的是刺激发生时的情况，响应是指系统是如何通过架构对刺激做出反应的基于场景的方式分析软件架构对场景的支持程度，从而判断该架构对这一场景所代表的质量需求的满足程度。
2.需求分析
2.1 需求的层次
QFD（质量功能部署）将软件需求分为三类：常规需求、期望需求和意外需求。
| 主题 | 内容 | 通俗理解 |
| 常规需求 | 用户认为系统应该做到的功能或性能，实现越多用户会越满意。 | 这是用户最基本的要求，比如手机能打电话、发短信，这些功能越齐全，用户越开心。 |
| 期望需求 | 用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现，会让用户感到不满意。 | 这是用户心里期待但没明说的需求，比如手机拍照要清晰、反应要快，如果达不到，用户会觉得不够好。 |
| 意外需求 | 意外需求也称为兴奋需求，是用户要求范围外的功能或性能（但通常是软件开发人员很乐意赋予系统的技术特性），实现这些需求用户会更高兴，但不实现也不影响其购买的决策。意外需求是控制在开发人员手中的，开发人员可以选择实现更多的意外需求，以便得到高满意、高忠诚度的用户，也可以（出于成本或项目周期的考虑）选择不实现任何意外需求。 | 这是超出用户预期的小惊喜，比如手机有美颜功能、能自动识别场景拍照，有了会让人特别满意，没有也不会影响购买决定。 |
2.2 需求过程
需求过程主要包括需求获取、需求分析、需求规格说明书编制、需求验证与确认等内容。
| 主题 | 内容 | 通俗理解 |
|---|---|---|
| 需求获取 | 确定和理解不同项目干系人的需求和约束，方法包括用户访谈、问卷调查等。 | 通过各种方式收集用户想要什么，比如直接问用户、发问卷等。 |
| 需求分析 | 将杂乱无章的用户要求和期望转化为清晰的用户需求。 | 把用户零散的想法整理成明确、可执行的需求，比如把“要好用”变成具体功能点。 |
| 需求规格说明书编制 | 编制SRS文档，使项目干系人与开发团队对系统初始规定有共同理解。 | 写一份详细的说明书，让所有人对软件要做什么有一致的认识，避免后期扯皮。 |
| 需求验证与确认 | 验证SRS的正确性，确保需求完整、一致、高质量，为后续工作提供基础。 | 检查说明书有没有写错、漏掉或矛盾的地方，确保开发前需求是靠谱的。 |
需求验证与确认活动的内容包括：
- SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征：确保软件需求规格说明书（SRS）准确反映了项目干系人的期望和需求，系统的行为和特性符合预期。
- SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的：验证软件需求是否合理地从更高层次的系统需求、业务规则以及其他相关来源中推导出来，保证需求的来源可靠且逻辑正确。
- 需求是完整的和高质量的：检查需求是否覆盖了所有必要的功能和非功能要求，没有遗漏，并且表述清晰、无歧义，具备高质量的标准。
- 需求的表示在所有地方都是一致的：确保在整个文档中，相同的需求描述保持一致，避免因表述不一致导致的理解偏差或实现错误。
- 需求为继续进行系统设计、实现和测试提供了足够的基础：确认需求文档能够为后续的系统设计、编码实现和测试工作提供充分的信息支持，确保开发过程有据可依。
在实际工作中，一般通过需求评审和需求测试工作来对需求进行验证。这些活动有助于在早期阶段发现并修正需求中的错误，从而节省后期开发和交付阶段的时间和成本。
2.3结构化分析
使用结构化分析（SA）方法进行需求分析，其建立的模型的核心是数据字典。围绕这个核心，有三个层次的模型：数据模型、功能模型和行为模型（也称为状态模型）。
在实际工作中，一般使用实体关系图（ER图）标识数据模型，用数据流图（DFD）标识功能模型，用状态转换图（STD）标识行为模型。
| 模型类型 | 表示方法 | 主要描述内容 | 基本元素 | 应用示例 |
|---|---|---|---|---|
| 数据模型 | 实体关系图（E-R图） | 描述实体、属性及实体间的关系，用于构建现实世界概念数据模型。 | - 实体：用矩形表示，如学生、饭卡、办公室等。 - 属性：用椭圆形表示，如姓名、学号、编号等。 - 联系：用菱形表示，描述实体间关系（1:1, 1:n, m:n）。 | 学生使用饭卡在食堂消费，涉及“学生”“饭卡”“食堂”等实体及“使用”“消费”等联系。 |
| 功能模型 | 数据流图（DFD） | 从数据传递和加工角度，描述系统内各部件功能及数据流动情况。 | - 数据流：用箭头表示，标注数据流向（如用户登录信息）。 - 处理：用矩形框表示，如“用户登录”“用户注册”。 - 数据存储：用数据库或文件形式表示，如“用户信息表”。 - 外部项：用圆角或平行四边形表示，如“用户”“教师”。 | 用户登录系统，数据流从“用户”到“用户登录”处理，再存入“用户信息表”，并反馈登录结果。 |
| 行为模型 | 状态转换图（STD） | 描述系统状态及引发状态转换的事件，指出特定事件触发的动作（如处理数据）。 | - 初态：实心圆。 - 终态：同心圆（内圆实心）。 - 中间状态：圆角矩形，可分三部分： - 上部：状态名称。 - 中部：状态变量名和值（可选）。 - 下部：活动表（可选）。 | 优惠券状态转换：从“未生效”经“运营手动生效”转为“已生效可领取”，再经“增加可领取数量”或“运营手动失效”变化。 |
2.4 面向对象分析
面向对象分析（OOA）模型包含用例模型和分析模型。
- 用例模型：用例是描述系统需求的方法，通过用例来描述系统需求的过程叫用例建模。构建用例模型一般经历四个阶段：识别参与者、合并需求获得用例、细化用例描述和调整用例模型，其中前三个阶段是必需的。
- 分析模型：从用户观点对系统进行用例建模后，还需深入分析获取关于问题域本质内容的分析模型。分析模型描述系统的基本逻辑结构，展示对象和类如何组成系统（静态模型），以及它们如何保持通信实现系统行为（动态模型）。建立分析模型的过程大致包括定义概念类、确定类之间的关系、为类添加职责、建立交互图等，前三个步骤统称为CRC（Class - Responsibility - Collaborator，类 - 责任 - 协作者）建模。
| 主题 | 内容 | 通俗理解 |
|---|---|---|
| 用例模型 | 构建用例模型一般需要经历四个阶段：识别参与者、合并需求获得用例、细化用例描述和调整用例模型，其中前三个阶段是必需的。 | 就像拍电影前先确定谁（参与者）参与、要拍哪些场景（用例），然后把每个场景细节完善，最后调整整体剧情，前三个步骤是必须的。 |
| 分析模型 | 建立分析模型的过程大致包括定义概念类、确定类之间的关系、为类添加职责、建立交互图等，前三个步骤统称为CRC（Class - Responsibility - Collaborator，类 - 责任 - 协作者）建模。 | 相当于把电影里的角色（类）确定好，明确角色之间的关系（比如朋友、敌人），给每个角色安排任务（职责），然后规划角色之间的互动（交互图），前三个步骤合起来叫CRC建模。 |
2.4.1. OOA模型的组成
OOA模型包括用例模型和分析模型。
- 用例模型：用于描述系统需求，通过用例来捕捉用户与系统的交互。
- 分析模型：用于描述系统的静态结构（对象和类如何组成系统）和动态行为（对象间如何通信以实现系统功能）。
2.4.2. 用例模型的构建阶段
构建用例模型需经历四个阶段：
- 识别参与者：确定与系统交互的外部实体（如用户、其他系统）。
- 合并需求获得用例：将相关需求整合为具体的用例。
- 细化用例描述：详细描述每个用例的流程、前置条件、后置条件等。
- 调整用例模型：根据反馈或新需求对模型进行优化。
其中，前三个阶段是必需的，这是考试常考的知识点。
2.4.3. 分析模型的建立过程
建立分析模型的过程包括：
- 定义概念类：识别系统中的核心概念并将其抽象为类。
- 确定类之间的关系：如继承、关联、聚合等。
- 为类添加职责：明确每个类应承担的功能或责任。
- 建立交互图：如顺序图、协作图，展示对象间的动态交互。
前三个步骤统称为 CRC建模（Class-Responsibility-Collaborator，即类-责任-协作者建模），这是面向对象分析中的经典方法，也是考试重点。
3.软件设计
软件设计是需求分析的延伸与拓展，需求分析解决“做什么”的问题，软件设计解决“怎么做”的问题。软件设计分为结构化设计和面向对象设计。
3.1结构化设计（SD）
结构化设计是一种面向数据流的方法，以SRS（软件需求规格说明书）和SA（结构化分析）阶段产生的数据流图DFD和数据字典等文档为基础，是自顶向下、逐步求精和模块化的过程。SD方法的基本思想是将软件设计成由相对独立且具有单一功能的模块组成的结构，分为概要设计和详细设计两个阶段。在SD中，需要遵循的基本原则是高内聚、低耦合。
3.2面向对象设计（OOD）
面向对象设计（OOD）是OOA方法的延续，其基本思想包括抽象、封装和可扩展性，其中可扩展性主要通过继承和多态来实现。如何同时提高软件的可维护性和可重用性，是OOD需要解决的核心问题之一。
| 主题 | 内容 | 通俗理解 |
|---|---|---|
| 软件设计概述 | 软件设计是需求分析的延伸与拓展，需求分析解决“做什么”，软件设计解决“怎么做”，分为结构化设计与面向对象设计。 | 就像盖房子，需求分析是确定房子要有什么功能（如几间卧室、厨房等），软件设计是确定怎么盖（用什么结构、材料等）。 |
| 结构化设计（SD） | 是一种面向数据流的方法，以SRS和SA阶段产生的数据流图DFD和数据字典等文档为基础，是自顶向下、逐步求精和模块化的过程，分为概要设计和详细设计两个阶段，遵循高内聚、低耦合的原则。 | 把软件设计想象成做一道菜，先确定整体步骤（概要设计），再细化每个步骤的具体操作（详细设计），每个步骤尽量独立（高内聚），步骤之间的联系尽量简单（低耦合）。 |
| 面向对象设计（OOD） | 是OOA方法的延续，基本思想包括抽象、封装和可扩展性，可扩展性主要通过继承和多态来实现，核心问题是提高软件的可维护性和可重用性。 | 就像用乐高积木搭东西，抽象是确定要用哪些类型的积木，封装是把积木的内部结构隐藏起来只展示功能，继承和多态是让积木可以组合出更多样式的结构，同时还要保证积木能方便地修改和重复使用。 |
3.3设计模式
设计模式是前人经验的总结，它使人们可以方便地复用成功的软件设计。设计模式包含模式名称、问题、目的、解决方案、效果、实例代码和相关设计模式等基本要素。
根据处理范围不同，设计模式可分为类模式和对象模式。类模式处理类和子类之间的关系，这些关系通过继承建立，在编译时刻就被确定下来，属于静态关系；对象模式处理对象之间的关系，这些关系在运行时刻变化，更具动态性。根据目的和用途不同，设计模式可分为创建型模式、结构型模式和行为型模式三种。
3.3.1. 创建型模式
主要用于创建对象，包括工厂方法模式、抽象工厂模式、原型模式、单例模式和建造者模式等。
3.3.2. 结构型模式
主要用于处理类或对象的组合，包括适配器模式、桥接模式、组合模式、装饰模式、外观模式、享元模式和代理模式等。
3.3.3. 行为型模式
主要用于描述类或对象的交互及职责的分配，包括职责链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板方法模式、访问者模式等。
| 主题 | 内容 | 通俗理解 |
|---|---|---|
| 设计模式概述 | 设计模式是前人经验的总结，包含模式名称、问题、目的、解决方案、效果、实例代码和相关设计模式等基本要素。 | 就像建筑行业里的“标准户型图”，前人已经验证过这些设计是好用的，直接拿来用可以少走弯路。 |
| 类模式与对象模式 | 类模式处理类和子类之间的关系（通过继承建立，编译时确定）；对象模式处理对象之间的关系（运行时变化）。 | 类模式像“家族遗传”，结构在出生（编译）时就定好了；对象模式像“朋友合作”，关系是动态变化的。 |
| 创建型模式 | 主要用于创建对象，包括工厂方法模式、抽象工厂模式、原型模式、单例模式和建造者模式等。 | 相当于“造物主”，负责怎么把一个新对象“生”出来，比如用模板复制（原型）、统一入口创建（工厂）等。 |
| 结构型模式 | 主要用于处理类或对象的组合，包括适配器模式、桥接模式、组合模式、装饰模式、外观模式、享元模式和代理模式等。 | 相当于“装修队”，负责把已有的零件（类或对象）组合起来，形成一个更复杂或更易用的整体结构。 |
| 行为型模式 | 主要用于描述类或对象的交互及职责的分配，包括职责链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板方法模式、访问者模式等。 | 相当于“导演”，负责协调各个角色（对象）之间的互动和分工，比如谁来发号施令（命令）、谁来监听事件（观察者）等。 |
4.软件实现
4.1软件编码
4.1.1. 软件编码的定义
软件编码是将软件设计的成果转化为计算机可执行的程序代码的过程。其核心是使用某种程序设计语言，将设计阶段的逻辑和结构“翻译”成机器能理解的指令。
4.1.2. 程序设计风格
程序设计风格是影响代码质量的关键因素，主要包含以下四个核心方面：
- 源程序文档化：通过注释、清晰的命名等手段，使代码本身成为一种“自说明”的文档，方便他人（和未来的自己）阅读和理解。
- 数据说明：在代码中对数据的类型、结构、用途等进行明确的说明，增强数据的可读性和可维护性。
- 语句结构：采用简洁、清晰、逻辑性强的语句结构，避免复杂的嵌套和冗余代码。
- 输入/输出方法：规范程序与外界交互的方式，确保输入的有效性和输出的清晰性。
遵循良好的编码原则是提高程序可读性和改善整体质量的根本途径。
4.1.3. 编码效率分析
编码效率并非单一维度的概念，而是综合考量多个层面的表现：
| 主题 | 内容解析 |
|---|---|
| 程序效率 | 关注程序运行的速度和内存占用情况。需注意的是，在追求极致性能的同时，不应牺牲程序的简单性、可读性和正确性，否则得不偿失。 |
| 算法效率 | 直接取决于设计阶段选定算法的质量。高效的算法能在翻译为源代码后，表现出优异的执行速度和较小的存储需求，这是衡量算法优劣的关键指标。 |
| 存储效率 | 对软件规模和运行成本影响巨大。应优先选择能生成紧凑目标代码且压缩性能优良的编译器，并可通过手动编写汇编语言优化关键部分来提升空间利用率。简化程序结构是提高存储效率的根本方法。 |
| I/O效率 | 包括面向人的交互效率和面向设备的数据传输效率。前者强调界面友好、操作简便；后者则侧重于充分利用硬件自身的性能特性来加速数据交换过程。 |
4.2软件测试
4.2.1. 软件测试方法分类
软件测试方法主要分为静态测试和动态测试两大类，两者相辅相成，共同保障软件质量。
4.2.2. 静态测试
静态测试是指在程序不运行的情况下，通过人工或工具对程序、文档或源代码进行检查和评估的方法。其核心价值在于能有效发现30%～70%的逻辑设计和编码错误，是成本最低、效益最高的早期质量保障手段。
静态测试的主要方法：
- 桌前检查 (Desk Checking)：又称纸上审查，由开发或测试人员通过人工模拟程序执行流程，逐行验证算法的正确性和逻辑的完整性。这是一种低成本、高效率的个人自查方式。
- 代码走查 (Code Walkthrough)：一种结构化的团队审查活动，通常在开发人员之间进行。参与者共同逐行检查代码，分析其执行路径，旨在发现逻辑错误、语法错误及编码风格问题。
- 代码审查 (Code Review)：由开发人员或专家对源代码进行正式审查，重点关注编程错误、命名规范一致性及整体代码风格。
- 静态分析工具 (Static Analysis Tools)：利用自动化工具对源代码进行扫描，能高效发现潜在的缺陷、安全漏洞和性能瓶颈。
- 文档审查 (Document Review)：对需求文档、设计文档等进行审查，确保其准确性、完整性和符合标准。
4.2.3. 动态测试
动态测试是指在计算机上实际运行程序来进行的测试，其核心是验证程序在真实环境下的行为是否符合预期。
动态测试的主要方法：
- 白盒测试 (White-box Testing)：
- 别名：结构测试、透明盒测试、代码覆盖测试。
- 核心思想：基于对程序内部结构和实现细节的了解来设计测试用例。
- 目标：验证软件内部的逻辑流程和结构，确保所有路径都能按预期处理输入和边界条件。
- 优缺点：优点是能深入检查内部逻辑，更容易发现潜在错误；缺点是耗时长，且可能因过度关注细节而忽略用户体验。
- 黑盒测试 (Black-box Testing)：
- 别名：功能测试、数据驱动测试、规格测试。
- 核心思想：将软件视为一个“黑盒子”，只关注输入和输出结果，不关心内部实现。
- 目标：验证程序是否满足功能需求和用户体验。
- 优缺点：优点是从用户角度出发，易于实施；缺点是无法检查内部逻辑和结构，可能遗漏一些深层次错误。
| 方法类别 | 具体方法 | 核心内容 |
|---|---|---|
| 静态测试 | 桌前检查 | 又称为纸上审查，通过人工模拟程序执行来检查算法正确性和逻辑流程。开发或测试人员逐步模拟程序执行，验证输入、处理和输出是否符合预期，有助于发现问题并确保软件满足需求规格。 |
| 代码走查 | 结构化的代码审查过程，通常在开发人员之间进行，目的是找出代码中的逻辑错误、语法错误和编码风格问题。参与者逐行检查代码，分析其执行流程，并确保代码符合项目的设计要求和编码规范。 | |
| 代码审查 | 开发人员或专家对源代码进行审查，以发现编程错误、命名规范不一致和代码风格等问题。 | |
| 静态分析工具 | 使用自动化工具对源代码进行扫描和检查，可以发现潜在的缺陷、安全漏洞和性能问题。 | |
| 文档审查 | 对需求文档、设计文档等相关软件文档进行审查，确保其准确、完整和符合标准。 | |
| 动态测试 | 白盒测试 | - 别名：结构测试、透明盒测试或代码覆盖测试。 - 测试内容：测试人员对软件内部结构和实现细节有详细了解，根据代码逻辑和程序设计创建测试用例，以确保程序能按预期处理各种输入和边界条件。 - 目标：验证软件内部的逻辑流程和结构，发现程序中可能存在的错误或不足。 - 优缺点：优点是能检查程序内部的逻辑和结构，更容易找到潜在问题；缺点是时间消耗较大，可能因过于关注细节而忽略用户体验。 |
| 黑盒测试 | - 别名：功能测试、数据驱动测试或规格测试。 - 测试内容：测试人员不关心软件内部的实现细节，只关注程序的输入和输出结果。将软件看作一个黑盒子，通过提供各种输入并观察输出结果，来确定程序是否按照预期工作。 - 目标：主要关注程序是否满足功能需求和用户体验，而不关心其内部结构。 - 优缺点：优点是可以从用户角度发现问题，相对于白盒测试更容易实施；缺点是无法检查程序内部的逻辑和结构，可能会漏掉一些潜在的错误。 |
5.部署交付
1. 传统软件部署与交付的常见问题
传统软件部署与交付流程中，常面临以下八大痛点：
- 分支冗余：导致代码合并困难，增加冲突风险。
- 缺陷过多：阻塞测试进度，延长发布周期。
- 环境不统一：开发、测试、部署环境差异导致“未知错误”频发。
- 版本混乱：代码提交版本管理混乱，无法有效回溯。
- 上线周期长：等待时间过长，影响业务响应速度。
- 操作复杂：部署过程繁琐，易出错且失败率高。
- 紧急回滚：上线后出现问题需紧急回滚，增加运维压力。
- 架构缺陷：设计不合理导致错误发生后难以准确定位。
| 问题类别 | 具体问题描述 |
|---|---|
| 分支管理 | 分支冗余导致合并困难 |
| 质量控制 | 缺陷过多导致阻塞测试 |
| 环境一致性 | 开发、测试、部署环境不统一导致未知错误 |
| 版本管理 | 代码提交版本混乱无法回溯 |
| 效率问题 | 等待上线周期过长 |
| 操作风险 | 项目部署操作复杂经常失败 |
| 应急响应 | 上线后出现问题需要紧急回滚 |
| 架构设计 | 架构设计不合理导致错误后无法准确定位 |
2. 持续交付（Continuous Delivery）
为解决上述问题，持续交付应运而生。它是一套自动化、标准化的开发实践方法，旨在确保代码能够快速、安全地部署到生产环境中。
持续交付的核心实践：
- 需求阶段：摒弃传统文档，采用开发人员易于理解的“用户故事”进行需求沟通。
- 开发测试阶段：实现持续集成，让测试人员尽早介入项目，提前发现并修复问题。
- 运维阶段：打通开发与运维的壁垒，保持开发环境与运维环境的高度统一。
| 阶段 | 核心实践内容 |
|---|---|
| 需求阶段 | 抛弃传统文档，使用开发人员易于理解的用户故事进行需求沟通 |
| 开发测试阶段 | 实现持续集成，让测试人员尽早介入项目开始测试 |
| 运维阶段 | 打通开发与运维之间的通路，保持开发环境和运维环境的统一 |
3. 持续部署（Continuous Deployment）
持续部署是持续交付的延伸和自动化体现，其核心在于“Build-Ship-Run”三个环节：
持续部署的三大环节：
- Build（构建）：将源代码编译打包成可执行的RPM包或Jar包等格式。
- Ship（分发）：将构建好的包及其依赖项自动安装到目标运行环境中。
- Run（运行）：在不同的服务器或容器中启动并运行整个应用环境。
| 环节 | 核心内容 |
|---|---|
| Build（构建） | 将源代码编译打包成可执行的RPM包或Jar包等格式 |
| Ship（分发） | 将构建好的包及其依赖项自动安装到目标运行环境中 |
| Run（运行） | 在不同的服务器或容器中启动并运行整个应用环境 |
4. 常见的持续部署策略
为了降低发布风险，业界常用以下两种策略：
（1）不可变服务器（Immutable Server）
指服务器一旦部署完成，除更新和安装补丁外，不再对其进行任何修改。这保证了环境的一致性和可预测性。
（2）蓝绿部署（Blue-Green Deployment）
准备新旧两个完全独立的部署版本。通过域名解析切换流量，在新版本出现问题时可快速切回旧版本进行修复。
（3）金丝雀部署（Canary Deployment）
先让少量用户使用新版本，观察其稳定性和性能表现。若一切正常，则逐步扩大新版本的用户范围；若发现问题，则及时回滚并修复。
| 策略名称 | 核心内容 |
|---|---|
| 不可变服务器 | 服务器部署完成后，除更新和安装补丁外，不再进行任何修改，保证环境一致性和可预测性。 |
| 蓝绿部署 | 准备新旧两个完全独立的部署版本，通过域名解析切换流量，新版本出问题时可快速切回旧版本。 |
| 金丝雀部署 | 先让少量用户使用新版本，观察其稳定性和性能表现。若正常则逐步扩大用户范围；若出问题则及时回滚并修复。 |
四、数据工程
数据工程是信息系统的基础工程，其核心是围绕数据的生命周期，规范数据从产生到应用的全过程。其主要目标包括：
- 提供可靠的数据保障和服务：确保信息系统运行所需数据的准确性和可用性。
- 构建安全高效的数据共享环境：促进不同信息系统之间的数据流通与协作。
- 支撑系统互连互通互操作：为实现信息系统的集成与协同提供坚实的数据基础。
数据工程的研究范畴广泛，主要包括以下几个关键领域：
- 数据建模：设计和构建数据结构，以支持业务需求和系统功能。
- 数据标准化：制定统一的数据格式、编码和命名规范，确保数据的一致性和可交换性。
- 数据运维：对数据进行日常的监控、维护和管理，保障数据系统的稳定运行。
- 数据开发利用：挖掘数据价值，支持数据分析、决策支持和业务创新。
- 数据库安全：保护数据免受未授权访问、泄露和破坏，确保数据的机密性、完整性和可用性。
1.数据建模
1.1. 数据建模的定义
数据建模是对现实世界中具体的人、物、活动、概念进行抽象、表示和处理，将其转化为计算机可处理的数据形式。简而言之，就是将现实世界的数据抽象到信息世界和计算机世界的过程。
1.2. 数据模型的分类
根据模型应用目的的不同，数据模型可分为三类：概念模型、逻辑模型和物理模型。
| 模型类型 | 定义 | 主要特点/内容 | 示例/说明 |
|---|---|---|---|
| 概念模型 (Conceptual Model) | 从用户角度对数据和信息进行建模，将现实世界中的客观对象抽象为信息结构。 | * 不依赖于具体计算机系统或DBMS。 * 是概念级别的模型。 | 一个“订单”可能包含“商品”、“客户”和“销售人员”等实体，这些实体间存在关联。 |
| 逻辑模型 (Logical Model) | 在概念模型基础上，确定数据结构。目前最常用的是关系模型。 | * 基本元素：关系、属性、视图等。 * 完整性约束：实体完整性、参照完整性、用户定义完整性。 | * 关系模型：数据以二维表（关系）形式组织。 * 参照完整性：如“选修课”表中“选课学生学号”必须在“学生”表的“学号”中存在。 |
| 物理模型 (Physical Model) | 在逻辑模型基础上，考虑技术实现因素，设计数据库体系结构。 | * 基本元素：表、字段、索引、存储过程、触发器等。 * 可能会与逻辑模型有差异，以满足性能需求。 | * 表：如学生表、选修课表。* 字段：如 学号、姓名、成绩等。* 外键：如 选修课表中的选课学生学号是外键 |
（1）概念模型
- 定义：也称为信息模型，它从用户的角度对数据和信息进行建模，将现实世界中的客观对象抽象为一种信息结构。
- 特点：这种信息结构不依赖于具体的计算机系统，也不对应某个具体的数据库管理系统（DBMS），属于概念级别的模型。
（2）逻辑模型
- 定义：在概念模型的基础上确定模型的数据结构。目前主要的数据结构包括层次模型、网状模型、关系模型、面向对象模型和对象关系模型。其中，关系模型是当前最重要的一种逻辑数据模型。
- 基本元素：关系、关系的属性、视图等。
- 完整性约束：包括实体完整性、参照完整性和用户定义的完整性。
（3）物理模型
- 定义：在逻辑模型的基础上，考虑具体的技术实现因素，进行数据库体系结构设计，以真正实现数据在数据库中的存储。
- 内容：确定所有的表和列，定义外键以确定表之间的关系，基于性能需求可能进行反规范化处理等。
- 基本元素：表、字段、视图、索引、存储过程、触发器等。
1.3. 数据建模过程
数据建模通常包括以下四个主要阶段：
| 阶段 | 任务/描述 | 关键点/说明 |
|---|---|---|
| (1) 数据需求分析 | 分析用户对数据的需要和要求。 | * 是数据建模的起点，其准确度直接影响模型质量。 * 通常融合在整个系统需求分析过程中。 * 使用数据流图作为工具，描述数据流动和处理过程。 |
| (2) 概念模型设计 | 将用户的数据应用需求抽象为信息世界的结构。 | * 主要任务是确定实体和数据及其关联。 * 如确定“客户”、“商品”、“订单”等实体及其关系。 |
| (3) 逻辑模型设计 | 将概念模型转换为具体的逻辑结构（主要是关系模型）。 | * 核心任务是将概念模型中的实体、属性和关联转换为关系模式（二维表）。 * 如将“客户”实体转换为“客户表”，包含“客户编号”、“姓名”、“地址”等字段。 |
| (4) 物理模型设计 | 针对具体的DBMS进行实现设计，使数据模型走向存储应用环节。 | * 主要考虑命名、字段类型定义、编写存储过程与触发器等。 * 目标是用数据库模式实现逻辑模型，并真正保存数据。 |
（1）数据需求分析
- 任务：分析用户对数据的需求和要求。这是数据建模的起点，其准确程度直接影响后续阶段数据模型的质量。
- 方法：通过与用户充分沟通，形成共识，并采用数据流图作为工具，描述系统中数据的流动和处理过程。
（2）概念模型设计
- 任务：将用户数据应用需求抽象为信息世界的结构。其主要任务是确定实体和数据及其关联。
（3）逻辑模型设计
- 任务：在概念模型的基础上，将实体、属性和关联转换为关系模型结构中的关系模式。由于当前DBMS普遍采用关系模型结构，因此逻辑模型设计主要指关系模型结构的设计。
（4）物理模型设计
- 任务：针对具体的DBMS进行物理模型设计，使数据模型走向数据存储应用环节。主要考虑的问题包括命名、确定字段类型以及编写必要的存储过程与触发器等。
2.数据标准化
2.1. 数据标准化的定义与目标
数据标准化是实现数据共享的基础。其主要目的是为复杂的信息表达、分类和定位建立相应的原则和规范，使其简单化、结构化和标准化，从而实现信息的可理解、可比较和可共享，为信息在异构系统之间实现语义互操作提供基础支撑。
| 项目 | 内容 |
|---|---|
| 定义 | 数据标准化是实现数据共享的基础，为复杂的信息表达、分类和定位建立相应原则和规范，使其简单化、结构化和标准化。 |
| 目标 | 实现信息的可理解、可比较和可共享，为信息在异构系统之间实现语义互操作提供基础支撑。 |
2.2. 数据标准化的主要内容
数据标准化主要包括以下三个方面：
- 元数据标准化：对元数据进行规范，确保其描述信息资源或数据的内容、覆盖范围、质量、管理方式等信息的一致性。
- 数据模式标准化：对数据的概念、组成、结构、相互关系进行统一规范，以减少因不同人群对相同客观世界的主观认知差异而导致的数据模式不一致。
- 数据分类与编码标准化：根据内容的属性或特征，将数据按一定的原则和方法进行区分和归类，并建立起一定的分类体系和排列顺序，以统一数据的表示法，提高信息处理效率。
| 内容分类 | 定义与说明 | 作用/意义 |
|---|---|---|
| 元数据标准化 | 对元数据进行规范，确保其描述信息资源或数据的内容、覆盖范围、质量、管理方式等信息的一致性。 | 提供关于信息资源或数据的结构化描述，便于理解和管理。 |
| 数据模式标准化 | 对数据的概念、组成、结构、相互关系进行统一规范，减少因主观认知差异而导致的数据模式不一致。 | 统一数据结构和概念，确保不同系统间的数据一致性。 |
| 数据分类与编码标准化 | 根据内容属性或特征，按一定原则和方法进行区分和归类，建立分类体系和排列顺序。 | 用于信息系统的共享和互操作，统一数据的表示法，提高信息处理效率。 |
2.3. 数据标准化管理过程
数据标准化的具体过程包括四个阶段：
- 确定数据需求：产生数据需求及相关元数据、域值等文件，考虑现行法规、政策及现有数据标准。
- 制定数据标准：处理“确定数据需求”阶段提出的需求，建议制定新标准或修改/封存已有标准，并记录于数据字典中。
- 批准数据标准：由数据管理机构对提交的标准建议进行审查，批准后扩充或修改数据模型。
- 实施数据标准：在各信息系统中实施和改进已批准的数据标准。
| 阶段 | 任务/描述 | 关键点/说明 |
|---|---|---|
| (1) 确定数据需求 | 产生数据需求及相关元数据、域值等文件。 | * 考虑现行法规、政策及现有数据标准。 * 为后续标准制定提供依据。 |
| (2) 制定数据标准 | 处理“确定数据需求”阶段提出的需求。 | * 如现有标准不满足需求，可建议制定新标准或修改/封存已有标准。 * 记录于数据字典中，供审查和批准。 |
| (3) 批准数据标准 | 由数据管理机构对提交的数据标准建议进行审查。 | * 一经批准，将扩充或修改数据模型。 * 确保标准的权威性和适用性。 |
| (4) 实施数据标准 | 在各信息系统中实施和改进已批准的数据标准。 | * 确保标准在实际应用中落地。 * 持续优化以适应新的需求。 |
3.数据运维
3.1数据存储
3.1.1. 数据存储的定义与核心内涵
数据存储被定义为：根据不同的应用环境，通过合理、安全、有效的方式将数据保存到物理介质上，并保证对数据实施有效的访问。其核心包含两个方面：
- 物理媒介：数据临时或长期驻留的载体。
- 管理方式：保障数据完整、安全存放和访问所采取的行为或技术手段。
数据存储的本质是将上述两方面结合，提供一个完整的解决方案。
3.1.2. 数据存储的两大关键环节
（1）数据存储介质
存储介质并非越贵越好、越先进越好，而应根据具体应用环境进行合理选择。主要类型包括：
- 磁带：成本低、容量大，但速度较慢，适用于长期归档。
- 光盘：具有只读性、抗电磁干扰、易复制的特点，适合永久性归档备份。
- 磁盘：性能高、安全性强，常采用RAID技术提升读取性能和数据安全性。
（2）存储管理
随着数据量的增长，存储管理的重要性日益凸显。其核心目标包括：
- 提高访问性能
- 保障数据安全与可用性
- 满足空间共享与扩展需求
具体管理内容涵盖资源调度、资源管理、负载均衡和安全管理。
3.1.3. 各类存储介质的详细对比
五种主要存储介质（磁带、光盘、磁盘、内存、闪存、云存储）特性描述：
- 磁带：经济型大容量存储，但读写速度慢。
- 光盘：分VCD/DVD等格式，容量从700MB到60GB不等，适合归档。
- 磁盘：通过RAID技术提升性能和安全，是主流的高性能存储方案。
- 内存：用于CPU运算数据的高速缓存，断电后数据丢失。
- 闪存：兼具高速与持久性，常作为磁盘替代品。
- 云存储：提供可扩展的异地存储方案，支持通过网络访问。
| 存储介质 | 主要特点 | 典型应用场景 |
|---|---|---|
| 磁带 | 成本低、容量大、读写速度慢 | 长期归档、冷数据备份 |
| 光盘 | 只读性好、抗干扰强、易复制、容量从700MB到60GB不等 | 永久性归档、资料分发、冷备份 |
| 磁盘 | 性能高、安全性强（常配合RAID技术） | 主流高性能存储、热数据访问 |
| 内存 | 读写速度极快、断电后数据丢失 | CPU运算数据的高速缓存 |
| 闪存 | 兼具高速读写与数据持久性 | 作为磁盘的替代品、移动存储 |
| 云存储 | 可扩展性强、支持异地网络访问 | 弹性存储需求、异地容灾、协作办公 |
| 要素类别 | 定义/描述 | 核心要点 |
|---|---|---|
| 存储介质 | 数据临时或长期驻留的物理载体 | * 选型原则：并非越贵、越先进越好，需根据应用环境合理选择。 * 涵盖：磁带、光盘、磁盘等物理硬件。 |
| 管理方式 | 保障数据完整、安全存放和访问的技术手段与行为 | * 目标：确保数据的合理、安全、有效存储。 * 结合：将物理媒介与管理方式结合，提供完整解决方案。 |
| 管理领域 | 任务/描述 | 关键点/说明 |
|---|---|---|
| 资源调度 | 根据需求分配和调度存储资源 | 确保数据能够被高效地存取和处理。 |
| 资源管理 | 对存储资源进行统一的监控和维护 | 保证存储系统的稳定运行和资源利用率。 |
| 负载均衡 | 分散数据访问压力，避免单点过载 | 提高整体系统的访问性能和响应速度。 |
| 安全管理 | 保护数据免受未授权访问和破坏 | 保障数据的机密性、完整性和可用性。 |
3.2 数据备份
3.2.1. 数据备份结构
当前最常见的数据备份结构可以分为4种：DAS备份结构、基于LAN的备份结构、LANFREE备份结构和SERVER-FREE备份结构。
（1）DAS备份结构
- 定义：最简单的备份结构，将备份设备（RAID或磁带库）直接连接到备份服务器上。
- 适用场景：数据量不大、操作系统类型单一、服务器数量有限的情况。
- 特点：结构简单，但扩展性差，不适合大规模数据备份。
（2）基于LAN的备份结构
- 定义：一种C/S模型，多个服务器或客户端通过局域网共享备份系统。
- 优点：
- 用户可以通过LAN共享备份设备。
- 可以对备份工作进行集中管理。
- 缺点：
- 备份数据流通过LAN到达备份服务器，与业务数据流混合，占用网络资源。
（3）LANFREE备份结构
- 定义：为了克服基于LAN备份结构的缺点，将备份数据流和业务数据流分开。
- 优点：
- 业务数据流主要通过业务网络进行传输。
- 备份数据流通过SAN进行传输，减少对业务网络的影响。
- 缺点：
- 备份数据流要经过应用服务器，影响应用服务器提供正常服务。
（4）SERVER-FREE备份结构
- 定义：LAN-FREE备份结构的改进，不依赖应用服务器，通过第三方备份代理直接将数据从应用服务器的存储设备传送到备份设备上。
- 特点：
- 第三方备份代理是一种软、硬结合的智能设备。
- 使用网络数据管理协议发送命令，从需要备份的应用服务器上获得需要备份数据的信息。
- 通过SAN直接从应用服务器的存储设备将需要备份的数据读出，再存储到备份设备上。
3.2.2. 数据备份策略
主要有3种备份策略：完全备份、差分备份和增量备份。
（1）完全备份（Full Backup）
- 定义：每次都对需要进行备份的数据进行全备份。
- 优点：当数据丢失时，用完全备份数进行恢复即可。
- 缺点：
- 占用较多的服务器、网络等资源。
- 备份数据中有大量重复数据，对备份介质资源消耗较大。
（2）差分备份（Differential Backup）
- 定义：每次所备份的数据只是相对上一次完全备份之后发生变化的数据。
- 优点：
- 所需时间短，节省存储空间。
- 数据恢复方便，管理员只需两份备份数（如星期日的完全备份数和故障发生前一天的差分备份数），就能对系统数据进行恢复。
（3）增量备份（Incremental Backup）
- 定义：每次所备份的数据只是相对于上一次备份数后改变的数据。
- 优点：
- 没有重复的备份数，节省存储空间。
- 缩短了备份数时间。
- 缺点：
- 数据恢复时比较复杂。如果其中一个增量备份数出现问题，那么后面的数据也就无法恢复了。因此增量备份数的可靠性没有完全备份数和差分备份数高。
| 备份结构 | 定义/描述 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| DAS备份结构 | 最简单的备份结构，将备份设备（RAID或磁带库）直接连接到备份服务器上。 | 结构简单，易于实现。 | 扩展性差，不适合大规模数据备份。 | 数据量不大、操作系统类型单一、服务器数量有限的情况。 |
| 基于LAN的备份结构 | 一种C/S模型，多个服务器或客户端通过局域网共享备份系统。 | 用户可以通过LAN共享备份设备，并且可以对备份工作进行集中管理。 | 备份数据流通过LAN到达备份服务器，与业务数据流混合，占用网络资源。 | 小型的网络环境中较为常见。 |
| LANFREE备份结构 | 为了克服基于LAN备份结构的缺点，将备份数据流和业务数据流分开。 | 业务数据流主要通过业务网络进行传输，备份数据流通过SAN进行传输，减少对业务网络的影响。 | 备份数据流要经过应用服务器，影响应用服务器提供正常服务。 | 需要减少对业务网络影响的中大型网络环境。 |
| SERVER-FREE备份结构 | LAN-FREE备份结构的改进，不依赖应用服务器，通过第三方备份代理直接将数据从应用服务器的存储设备传送到备份设备上。 | 不依赖应用服务器，减少对应用服务器的影响。 | 需要第三方备份代理，增加系统复杂性。 | 需要高可靠性和低影响的大型网络环境。 |
| 备份策略 | 定义/描述 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 完全备份 (Full Backup) | 每次都对需要进行备份的数据进行全备份。当数据丢失时，用完全备份数进行恢复即可。 | 恢复简单，只需一份备份数即可恢复所有数据。 | 占用较多的服务器、网络等资源；备份数中有大量重复数据，对备份数介质资源消耗较大。 | 数据量较小、对恢复时间要求不高的场景。 |
| 差分备份 (Differential Backup) | 每次所备份数的数据只是相对上一次完全备份数之后发生变化的数据。 | 所需时间短，节省存储空间；数据恢复方便，管理员只需两份备份数（如星期日的完全备份数和故障发生前一天的差分备份数），就能对系统数据进行恢复。 | 随着时间推移，差分备份数的大小会逐渐增加。 | 数据量较大、对恢复时间有一定要求的场景。 |
| 增量备份 (Incremental Backup) | 每次所备份数的数据只是相对于上一次备份数后改变的数据。 | 没有重复的备份数，节省存储空间；缩短了备份数时间。 | 数据恢复时比较复杂；如果其中一个增量备份数出现问题，那么后面的数据也就无法恢复了；可靠性没有完全备份数和差分备份数高。 | 数据量非常大、对存储空间要求严格的场景。 |
3.3数据容灾
| 题 | 内容 | 通俗理解 | ||
|---|---|---|---|---|
| 灾难定义 | 一切引起系统非正常停机的事件，包括自然灾害、系统软硬件故障、人为误操作和恶意攻击等。 | 凡是能让系统“突然罢工”的事儿，比如地震、服务器坏掉、手滑删库、黑客攻击，都算灾难。 | ||
| 容灾系统分类 |
分为应用容灾和数据容灾两类： - 应用容灾：保证应用服务的完整、可靠和安全，让用户随时能得到正常服务； - 数据容灾：重点关注用户数据的高可用性，灾难时尽量减少数据丢失，让应用系统能不间断运行或快速恢复。 |
应用容灾：相当于给“服务”买保险，比如网站服务器坏了，用户还能正常刷网页； 数据容灾：相当于给“数据”买保险，比如数据库崩了，用户资料不会丢，能快速找回。 | ||
| 数据备份与数据容灾的关系 | 数据备份是数据容灾的基础，是数据高可用的最后一道防线，目的是系统数据崩溃时能快速恢复数据。 | 数据备份就像“存底稿”，数据容灾是“底稿+应急方案”——备份是容灾的基本操作，但容灾不止是备份，还要能快速“复活”系统。 | ||
| 数据容灾的核心目标 | 不是简单备份，要避免传统冷备份的先天不足（如恢复慢、数据丢失多），在灾难发生时能全面、及时地恢复整个系统。 | 传统备份可能“恢复要半天，数据丢一天”；数据容灾要实现“故障秒切，数据几乎不丢”，让系统像没出事一样继续用。 |
3.4数据质量评价与控制
| 主题 | 内容 | 通俗理解 |
|---|---|---|
| 数据质量定义 | 在特定业务环境下，数据满足业务运行、管理与决策的程度，是保证数据应用效果的基础。衡量指标包括完整性、规范性、一致性、准确性、唯一性、及时性等。 | 数据质量就是“数据好不好用”。比如销售报表数字准不准、客户信息填全没填全、数据更新及时不及时，这些都决定业务能不能顺利跑起来。 |
| 数据质量元素 | 数据质量可通过“质量元素”描述，分为“定量元素”（可量化测量）和“非定量元素”（需主观判断）。 | 定量元素像“数学题”，能打分（如错误率5%）；非定量元素像“作文题”，靠经验判断（如数据格式是否统一）。 |
| 数据质量评价过程 | 分五步：①确定适用的质量元素及范围；②确定度量方法；③选择评价方法；④确定评价结果；⑤报告结果（含定量结果和一致性判定）。 | 就像给数据做“体检”：先定检查项目（如查错率），再选检查工具（如写程序扫数据），最后出报告（合格/不合格+具体分数）。 |
| 数据质量评价方法 | 分“直接评价法”（与标准值对比，如比对理论值）和“间接评价法”（通过数据源、采集方法等信息推断质量）。 | 直接法是“拿尺子量”——有标准答案就比对；间接法是“看卷面分”——没标准答案，但能从字迹、格式等推断质量。 |
| 数据质量控制 | 分“前期控制”（录入前+录入中）和“后期控制”（录入后处理与评价），覆盖数据全生命周期。 | 前期是“防病”——录数据时设校验规则，防止错输；后期是“治病”——数据录完后清洗、修复，把已有的错改对。 |
| 数据清理 | 广义指精简数据库、去重、转标准；狭义指建数仓前对源数据处理，目标是让数据满足准确性、完整性等要求。一般分三步：数据分析→数据检测→数据修正。 | 数据清理就是“大扫除”：先看数据哪乱（分析），再找具体垃圾（检测），最后动手收拾干净（修正），让数据从“毛坯房”变成“精装房”。 |
4.数据开发利用
4.1. 数据集成
- 定义：将驻留在不同数据源中的数据进行整合，向用户提供统一的数据视图（全局模式），使用户能以透明的方式访问数据。
- 作用：打破数据孤岛，让用户能便捷地获取跨数据源的统一数据视图，无需关心底层数据源的差异，方便数据的访问和使用。
4.2. 数据挖掘
- 定义：从大量、不完全、有噪声、模糊、随机的实际数据中，提取人们未知但潜在有用的知识。
- 主要任务：
- 数据总结：对数据进行概括性描述，如统计摘要。
- 关联分析：发现数据项之间的关联关系，如购物篮分析中“买A会买B”的规律。
- 分类和预测：对数据进行分类（如将客户分为高价值、低价值）或预测未来趋势（如预测销售额）。
- 聚类分析：将数据分为不同的簇，簇内数据相似，簇间差异大，如客户细分。
- 孤立点分析：识别数据中的异常点，如欺诈交易检测。
- 流程：包括确定分析对象、数据准备、数据挖掘、结果评估与结果应用五个阶段，实施中可能重复多次。
- 参与人员：业务分析人员（明确业务需求）、数据挖掘人员（执行挖掘操作）、数据管理人员（保障数据质量与管理）。
4.3. 数据服务
- 数据目录服务：用于快捷发现和定位所需数据资源的检索服务，是数据共享的基础功能，类似图书馆的书籍目录，帮助用户快速找到数据。
- 数据查询与浏览及下载服务：用户通过查询或下载的方式使用网上数据共享服务，满足不同数据获取需求。
- 数据分发服务：数据生产者将数据传送到用户的过程，核心包括数据发布（对外提供数据）、数据发现（用户找到数据）、数据评价（评估数据质量与价值）、数据获取（用户拿到数据）。
4.4. 数据可视化
| 表现方式 | 说明 | 通俗理解 |
|---|---|---|
| 一维数据可视化 | 一维数据是简单的线性数据，如文本、数字表格、程序源代码等，其可视化取决于数据大小和用户对数据的处理任务。 | 就像看一串珠子，每个珠子是一个数据（如温度数值），可以按顺序排成一行，方便数数或找规律。 |
| 二维数据可视化 | 二维数据由两种主要描述属性构成，如物体的宽度和高度、城市平面地图、建筑楼层平面图等，地理信息系统（GIS）是典型应用。 | 好比看照片，有长有宽，能展示空间关系，比如用地图App看街道分布，就是二维可视化。 |
| 三维数据可视化 | 三维数据在二维基础上增加一层，可描述立体信息，如实际的三维物体（通过三维建模或计算机模拟），操作和预测多实体行为。 | 像看3D电影，有长、宽、高，能更真实地展示物体，比如汽车设计时用3D模型查看车身结构。 |
| 多维数据可视化 | 在可视化环境中，多维数据的属性超过三维，为实现可视化，往往需要降维。 | 好比有多个“抽屉”（属性）的柜子，每个抽屉装不同数据（如销量、成本、时间），可视化时需把多个抽屉的内容整合成能看懂的图。 |
| 时态数据可视化 | 时态数据是二维数据的特殊形式（二维+一维时间轴），用图形展示随时间变化的数据，是信息可视化的常见方式。 | 像看动态图表，比如股票价格随时间的波动图，能直观看到数据“动起来”的趋势。 |
| 层次数据可视化 | 层次数据（如树形结构）的特征是每个节点有父节点（根节点除外），节点分兄弟（同父节点）和子孙（下属节点），如组织架构图、文件目录。 | 好比看家族族谱或文件夹结构，能清晰看到“谁是谁的上级/下级”，比如公司部门层级关系。 |
| 网络数据可视化 | 网络数据指节点（如用户、设备）和边（关系）构成的图数据，节点间关系的属性和数量可变，如社交网络关系图。 | 像看地铁线路图或社交关系网，节点是站点/好友，边是线路/关系，能直观展示“谁和谁有联系”。 |
5.数据库安全
5.1数据库安全定义
- 定义：数据脆弱，易被破坏或修改，需采取安全措施确保合法用户正确操作数据，保障数据机密性、完整性、可用性与合法使用，防止不合法使用导致的数据泄露、更改或破坏。
5.2数据库安全威胁
| 维度 | 表现方式 | 说明 | 通俗理解 |
|---|---|---|---|
| 威胁后果 | 非授权的信息泄露 | 未授权用户获取信息，含通过授权数据推导非授权信息 | 小偷没进门，但从你发的朋友圈推测出你家地址 |
| 非授权的数据修改 | 通过数据处理修改破坏信息完整性，不读取数据也可破坏 | 有人偷偷改了你存折里的数字，你没发现 | |
| 拒绝服务 | 影响用户访问数据或使用资源的行为 | 让你没法用WiFi，上不了网 | |
| 经济性 | 自然或意外灾害 | 地震、水灾等破坏软硬件，致完整性破坏或拒绝服务 | 地震把存钱罐砸碎了，钱丢了 |
| 灵活性 | 系统软硬件中的错误 | 应用策略错误，致非授权信息泄露、修改或拒绝服务 | 手机系统bug，导致信息发错人 |
| 相关性 | 人为错误 | 无意违反安全策略，后果同软硬件错误 | 手滑误删了重要文件 |
| 可靠性 | 授权用户 | 授权用户滥用特权造成威胁 | 有钥匙的人乱翻你家东西 |
| 安全性 | 恶意代理 | 病毒、木马、后门等 | 黑客用病毒偷你电脑里的资料 |
5.3数据库安全对策
| 安全对策 | 说明 | 通俗理解 |
|---|---|---|
| 防止非法的数据访问 | 按授权检查访问请求，仅允许授权用户访问 | 就像小区门禁，只有业主能进 |
| 防止推导 | 防止用户从统计信息推导原始个体信息（统计数据库易受此威胁） | 不能从全班平均分推出某个人的分数 |
| 保证数据库的完整性 | 防非授权修改，防病毒、系统错误致数据破坏，通过访问控制、备份/恢复等实现 | 确保你的作业不会被别人乱改，也不会因电脑坏掉而丢失 |
| 保证数据的操作完整性 | 并发事务中保证数据逻辑一致性，并发管理子系统负责 | 多人同时编辑文档，不会出现内容冲突 |
| 保证数据的语义完整性 | 修改数据时，新值符合逻辑完整性，通过完整性约束描述 | 填年龄时，不能填“abc”这样的字符 |
| 审计和日志 | 记录数据操作，保留日志文件，用于事后调查、分析 | 像监控摄像头，记录谁在什么时间做了什么 |
| 标识和认证 | 同计算机系统用户管理，是数据库第一道安全防线，为授权、审计前提 | 登录微信时，需要输入账号密码，确认是你本人 |
| 机密数据管理 | 访问控制保证机密数据保密性，授权用户可操作机密数据但不能传播权限，可访公开数据但不干扰 | 军事基地里的机密文件，只有特定人员能看，且不能把内容传出去 |
| 多级保护 | 划分数据保密级别，按用户权限访问对应级别数据 | 公司文件分“绝密”“机密”“秘密”，不同职级看不同级别的文件 |
| 限界 | 防程序间非授权信息传递，分授权通道、存储通道、隐通道 | 就像信件，只能通过邮局（授权通道）寄，不能偷偷塞别人家信箱（隐通道） |
5.4数据库安全机制
- 定义：实现数据库安全策略的功能集合，包括用户身份认证、存取控制、数据库加密、数据审计、推理控制等，通过这些机制实现安全模型，保护数据库系统安全。
- 通俗理解：就像保护城堡的“护城河+城墙+守卫+内部监控”，身份认证是“守卫认人”，存取控制是“城墙门禁”，加密是“把宝物藏进密室”，审计是“记录城内所有活动”，推理控制是“防止间谍从公开信息推断机密”。
五、系统集成工程
1.集成基础
1.1系统集成定义与核心组成
| 主题 | 内容 | 通俗理解 |
|---|---|---|
| 系统集成 | 通过硬件平台、网络通信平台、数据库平台、工具平台、应用软件平台，将各类资源高效集成到一起，形成完整工作台面。 | 就像组装一台电脑，把CPU（硬件）、网卡（网络）、硬盘（数据库）、办公软件等整合起来，让它们协同工作。 |
| 技术原则 | 需遵循开放性、结构化、先进性、主流化四大原则。 | 做饭要遵循食材搭配、火候控制等原则，系统集成也有自己的“烹饪法则”。 |
1.2系统集成技术原则
| 原则 | 内容 | 通俗理解 |
|---|---|---|
| 开放性 | 系统软硬件平台、通信接口等需遵循工业开放标准，不同厂商设备集成依赖接口标准化。 | 就像乐高积木，不同系列的积木能拼在一起，是因为它们遵循相同的卡扣标准。 |
| 结构化 | 将复杂系统逐层分解为独立子系统，再分解为可执行模块（自顶向下）。 | 建房子先设计整体框架（结构），再细分到每块砖怎么砌。 |
| 先进性 | 分“当前先进”和“未来先进”，技术先进才能保证系统生命力，设计（如架构、软件交互）也需先进。 | 买手机要选最新款（当前先进），还要考虑未来几年系统能升级（未来先进）。 |
| 主流化 | 系统每个产品需属于该产品发展的主流，有可靠技术支持、成熟使用环境和良好升级势头。 | 买电脑选Intel、AMD的CPU（主流），而不是小众品牌，因为主流产品售后和技术支持更稳。 |
2.网络集成
2.1网络集成概述
计算机网络系统集成不仅涉及技术问题，还涉及组织管理问题，因此比较复杂，大型网络系统更是如此。网络集成的体系框架包括多个子系统，共同构成完整的网络系统。
2.2网络集成体系框架中的重要子系统
| 子系统 | 内容 | 通俗理解 |
|---|---|---|
| 传输子系统 | 传输是网络的核心，是网络信息的“公路”和“血管”。传输线路带宽高低体现网络通信能力和现代化水平，传输介质决定通信质量，影响网络协议。 | 就像高速公路和血管，带宽是路的宽度，决定能跑多少车（数据），介质是路的材质（光纤、铜线），影响车跑得稳不稳。 |
| 交换子系统 | 网络按覆盖区域分为局域网、城域网和广域网，交换技术也相应分为局域网交换、城域网交换和广域网交换技术。 | 像不同规模的城市交通网，小区内用局域网交换（小区内道路），城市间用广域网交换（高速公路）。 |
| 安全子系统 | 关注防火墙技术（防外部侵入）、数据加密技术（防信息窃取）、访问控制（设口令、密码、权限保护资源）。 | 像小区安保，防火墙是大门保安，加密是给快递盒上锁，访问控制是门禁卡。 |
| 网管子系统 | 网络是动态结构，随组织规模扩大而改变。网管任务是保证网络良好运行，找出并解决“瓶颈”问题（如速度慢）。 | 像交通指挥中心，监控路况（网络状态），发现堵车（瓶颈）就疏导（优化配置）。 |
| 服务器子系统 | 服务器提供处理器内存、磁盘、打印机、软件数据等资源和服务，并协调管理这些资源。需高性能（快CPU、大内存/磁盘、高可靠）。选型考虑CPU速度/数量、内存容量/性能、总线结构/类型、磁盘容量/性能、容错性、网络接口性能、服务器软件等。 | 像公司数据中心的“大脑”，要处理所有员工请求（用户服务），所以得配置高配电脑（服务器），还要考虑扩展性（如加内存）。 |
| 网络操作子系统 | 调度和管理网络资源（服务器、工作站、打印机、路由器等），为用户提供统一、透明使用资源的手段。 | 像操作系统桌面，把所有硬件软件图标整理好，你点一下就能用，不用管后台怎么调度。 |
| 服务子系统 | 网络服务是网络应用的核心。包括互联网服务、多媒体信息检索、信息点播、信息广播、远程计算和事务处理等。 | 像手机App商店，提供各种服务（微信聊天、抖音刷视频），没这些服务，再快的5G也没意义。 |
3.数据集成
3.1数据集成定义与目的
- 定义：运用技术手段将系统中数据按规则组织成整体，使用户能有效操作数据。
- 目的：为应用提供统一访问支持，实现数据共享和辅助决策。
- 关键对象：系统中各种异构数据库中的数据。
- 关键技术：数据仓库技术。
3.2数据集成层次
| 层次 | 内容 | 通俗理解 |
|---|---|---|
| 基本数据集成 | 处理同一业务实体在多系统中的标识符问题（如“张三”在不同系统叫“Zhang San”或“张三丰”）。解决办法：隔离（每次出现指派唯一标识符）、调和（确认相同实体并合并）。 | 就像班级花名册，不同老师记录的“张三”可能写法不同，需统一成一个标准名字。 |
| 多级视图集成 | 通过两级映射实现：底层（局部模型格式）→中间层（公共模式格式）→高层（综合模型格式）。过程包括数据翻译、转换、语义冲突消除、集成和导出。 | 像翻译不同语言的文档，先转成通用格式（中间层），再整合成最终报告（高层）。 |
| 模式集成 | 模型合并，解决命名、单位、结构、抽象层次等冲突。设计好坏依赖经验，理论参考少。 | 像合并两个公司的组织架构图，需统一部门名称、层级关系等。 |
| 多粒度数据集成 | 最难处理的问题，理想模式是自动逐步抽象。从高精度局部数据获取低精度全局数据，过程是特征提取和归并。 | 像从高清照片（高精度）生成缩略图（低精度），保留主要特征但简化细节。 |
3.3异构数据集成
- 完整性要求：保证数据完整性和约束完整性。
- 语义冲突问题：信息资源间语义区别可能引起矛盾，从简单名字冲突到复杂结构冲突都会干扰处理、发布和交换。
- 其他考虑因素：数据访问权限、异构数据源数据的逻辑关系、数据集成范围等。
4.软件集成
4.1 软件集成定义与目标
- 定义：软件集成是在异构型计算资源（不同硬件平台、操作系统、信息资源）基础上，构建信息共享的分布式系统。
- 目标：实现不同厂商、不同语言、不同网络环境下的软件组件无缝协作，提升系统灵活性和可扩展性。
4.2 代表性软件构件标准
| 标准 | 内容 | 通俗理解 |
|---|---|---|
| CORBA | 公共对象请求代理结构，支持跨平台、跨语言的对象通信。 | 就像国际通用的“翻译官”，让不同国家（平台）的人（程序）能互相交流。 |
| COM/DCOM/COM+ | 微软推出的组件对象模型，支持本地和分布式组件通信。 | 像Windows系统的“插件接口”，让不同软件能像搭积木一样组合使用。 |
| .NET | 微软的开发框架，支持多种语言和跨平台应用开发。 | 像一个“全能工具箱”，开发者可以用C#、VB等语言快速搭建应用。 |
| J2EE | Java企业版，支持企业级分布式应用开发。 | 像Java世界的“企业级开发规范”，适合构建大型网站和后台系统。 |
4.3 软件集成趋势
- 面向对象技术改进：为适应异构网络应用需求，需对面向对象技术进行扩展和改进。
- 标准化推动：通过制定统一的软件构件标准，降低系统集成复杂度，提高互操作性。
5.应用集成
5.1应用集成定义与目标
- 定义：应用集成（Enterprise Application Integration, EAI）是指将独立的软件应用连接起来，实现协同工作。
- 目标：提高运营效率，实现工作流自动化，增强不同部门和团队之间的协作。
5.2应用集成在系统集成堆栈中的位置
- 最上层：应用集成位于系统集成堆栈的最上层，主要解决应用的互操作性问题。
- 三层结构：
- 网络集成（互连）：解决语法问题，确保系统间的基本连接。
- 数据集成（互通）：解决语义问题，确保数据在不同系统间的正确理解和交换。
- 应用集成（互操作性）：解决语用问题，确保应用间的信息有意义交换和功能服务的使用。
5.3应用集成的技术要求
| 要求 | 内容 | 通俗理解 |
|---|---|---|
| 互操作性 | 提供不同系统间信息的有意义交换，即信息的语用交换，而不仅限于语法交换和语义交换。此外，它还提供系统间功能服务的使用功能，特别是资源的动态发现和动态类型检查。 | 就像不同国家的人不仅能说同一种语言（语法），还能理解对方的意思（语义），更重要的是能一起合作完成任务（语用）。 |
| 可移植性 | 提供应用程序在系统中迁移的潜力，并且不破坏应用所提供的或正在使用的服务。这种迁移包括静态的系统重构或重新安装，以及动态的系统重构。 | 像搬家时，不仅要把家具搬走，还要确保新家的水电煤气都能正常使用，不影响生活。 |
| 透明性 | 屏蔽由系统的分布所带来的复杂性。它使应用编程者不必关心系统是分布的还是集中的，从而可以集中精力设计具体的应用系统，这就大大减少了应用集成编程的复杂性。 | 像使用手机APP，用户不需要知道后台是单机还是分布式服务器，只需关注功能是否好用。 |
六、安全工程
1.安全系统
1.1信息安全空间三维模型
信息安全系统可通过“宏观”三维空间图（信息安全空间）来反映其体系架构及组成，该模型由三个轴构成：
| 轴 | 名称 | 内容 | 通俗理解 |
|---|---|---|---|
| X轴 | 安全机制 | 提供安全服务的结构体系，如平台安全、安全数据库、安全平台等。 | 就像房子的“安全设施”，如门锁、监控、消防系统，保障整体安全。 |
| Y轴 | OSI网络参考模型 | 信息安全技术在OSI七层模型（物理层至应用层）上实施，离开网络，安全失去意义。 | 像不同楼层的安全措施，从地基（物理层）到顶层（应用层）都要有防护。 |
| Z轴 | 安全服务 | 从各网络层次提供所需的安全服务支持，如认证、访问控制、数据保密等。 | 像不同岗位的安保人员，各司其职提供具体安全保障服务。 |
1.2安全机制详解
安全机制包括基础设施安全、平台安全、数据安全、通信安全、应用安全、运行安全、管理安全、授权和审计安全、安全防范体系等。
| 主题 | 内容 | 通俗理解 |
|---|---|---|
| 基础设施安全 | 包括机房、场地、设施、动力系统安全及灾备等。 | 像公司大楼的物理安全，如门禁、消防、备用电源。 |
| 平台安全 | 操作系统、网络基础设施漏洞检测与修复，安全产品部署等。 | 像电脑的操作系统打补丁，防止黑客入侵。 |
| 数据安全 | 数据介质保护、访问控制、完整性、可用性、监控审计等。 | 像给文件上锁，防止被偷看或篡改。 |
| 通信安全 | 通信线路和设施测试优化，加密设施安装，身份鉴别机制等。 | 像打电话用加密电话，防止被窃听。 |
| 应用安全 | 软件安全性测试（Bug分析）、防抵赖测试、身份鉴别检测等。 | 像APP登录时的人脸识别，确保是本人操作。 |
| 运行安全 | 应急处置机制、系统监测、漏洞通报、灾难恢复等。 | 像公司IT部门的“救火队”，随时处理突发故障。 |
| 管理安全 | 人员管理、培训、系统管理、文档管理等。 | 像公司的人事制度和流程规范，确保人人守规矩。 |
| 授权和审计安全 | 权限管理和授权服务，用户身份到应用授权的映射功能。 | 像公司门禁卡，不同级别员工能进不同区域。 |
| 安全防范体系 | 实现EISRM（企业信息安全资源管理），包括预警、保护、检测、响应、恢复和反击六项能力（WPDRRC模型）。 | 像公司的“安保指挥中心”，能提前预警风险并快速应对。 |
1.3安全服务详解
安全服务包括对等实体认证服务、访问控制服务、数据保密服务、数据完整性服务、数据源点认证服务、禁止否认服务和犯罪证据提供服务等。
| 主题 | 内容 | 通俗理解 |
|---|---|---|
| 对等实体认证服务 | 确认通信双方实体的合法性与真实性，以防假冒。 | 像微信加好友时验证对方身份，防止骗子冒充。 |
| 访问控制服务 | 控制通信过程和内容的访问权限，保护信息免受未授权访问。 | 像公司文件夹设置权限，只有特定人员能查看。 |
| 数据保密服务 | 提供密码加密保护，防止数据被截获或非法存取泄露。 | 像给重要文件加密码压缩包，外人打不开。 |
| 数据完整性服务 | 防止数据在交换过程中被修改、插入或删除导致丢失。 | 像快递包裹贴封条，确保中途没被拆开或掉包。 |
| 数据源点认证服务 | 确保数据发自真正的源点，防止假冒源点发送数据。 | 像邮件显示发件人真实地址，防止钓鱼邮件冒充领导。 |
| 禁止否认服务 | 防止发送方或接收方事后否认发送或接收过数据的行为。 | 像电子合同签字后无法反悔，有法律效力。 |
| 犯罪证据提供服务 | 为违反法律法规的行为提供数字证据和信息线索。 | 像监控录像作为破案证据，记录违法过程。 |
1.4 安全技术
- 加密：通过特定算法对数据进行编码，确保信息在传输或存储过程中不被未授权者读取。
- 数字签名技术：用于验证数据的来源和完整性，确保信息在传输过程中未被篡改。
- 访问控制：管理用户对系统资源的访问权限，确保只有授权用户才能访问特定资源。
- 数据完整性：保证数据在传输和存储过程中不被修改或破坏，通常通过校验和或哈希值来实现。
- 认证：验证用户或系统的身份，确保其合法性和可信度，常见的认证方式包括密码、生物识别等。
- 数据挖掘：从大量数据中提取有价值的信息和模式，常用于安全分析和威胁检测。
2.工程体系架构
2.1 ISSE-CMM 基础概念
- 定义：ISSE-CMM（Information System Security Engineering Capability Maturity Model）是用于评估和改进信息安全系统工程能力的成熟度模型。
- 目标：通过系统化的方法，确定系统和过程的安全风险，并将其降至最低或有效控制。
2.2 ISSE-CMM 过程分解
ISSE-CMM 将信息安全系统工程实施过程分解为三个基本部分：
- 工程过程：负责确定安全策略和实施方案。
- 风险过程：识别和优先排序产品或系统的安全风险。
- 保证过程：建立解决方案的可信性，并向用户传达这种安全可信性。
2.3 ISSE-CMM 体系结构
ISSE-CMM 的体系结构采用两维设计：
- 域维（Domain）：汇集了定义信息安全工程的所有实践活动，称为过程域（Process Area, PA）。
- 安全工程过程域（11个）：
- PA01 实施安全控制
- PA02 评估影响
- PA03 评估安全风险
- PA04 评估威胁
- PA05 评估脆弱性
- PA06 建立保证论据
- PA07 协调安全
- PA08 监控安全态
- PA09 提供安全输入
- PA10 确定安全需求
- PA11 验证和证实安全
- 项目和组织实施相关过程域（11个）：
- PA12 保证质量
- PA13 管理配置
- PA14 管理项目风险
- PA15 监测和控制技术工程项目
- PA16 规划技术工程项目
- PA17 定义组织的系统工程过程
- PA18 改进组织的系统工程过程
- PA19 管理产品线的演变
- PA20 管理系统工程支持环境
- PA21 提供不断更新的技能和知识
- PA22 与供应商的协调
- 安全工程过程域（11个）：
- 能力维（Capability）：通用实施（Generic Practices, GP）由被称为公共特性的逻辑域组成，分为5个级别，依次表示增强的组织能力。
- Level 1: 非正规实施级
- 执行基本实施
- Level 2: 规划与跟踪级
- 规划执行、规范化执行、验证执行、跟踪执行
- Level 3: 充分定义级
- 定义标准化过程、执行已定义的过程、协调安全实施
- Level 4: 量化控制级
- 建立可测度的质量目标、对执行情况实施客观管理
- Level 5: 持续改进级
- 改进组织能力、改进过程的效能
2.4 能力级别特点总结
| 级别 | 重点 | 能力特点 |
|---|---|---|
| Level 1: 非正规实施级 | 着重于一个组织或项目只是执行了包含基本实施的过程 | 必须首先做它，然后才能管理它 |
| Level 2: 规划与跟踪级 | 着重于项目层面的定义、规划和执行问题 | 在定义组织层面的过程之前，先要弄清楚与项目相关的事项 |
| Level 3: 充分定义级 | 着重于规范化地裁剪组织层面的过程定义 | 这个级别的能力特点可描述为用项目中学到的最好的东西来定义组织层面的过程 |
| Level 4: 量化控制级 | 着重于测量。测量是与组织业务目标紧密联系在一起的。尽管在以前的级别上，也把数据收集和采用项目测量作为基本活动，但只有达到高级别时，数据才能在组织层面上被应用 | 只有知道它是什么，才能测量它。当被测量的对象正确时，基于测量的管理才有意义 |
| Level 5: 持续改进级 | 从前面各级的所有管理活动中获得发展的力量，并通过加强组织的文化来保持这种力量。这一方法强调文化的转变，这种转变又将使方法更有效 | 持续性改进的文化需要以完备的管理实施、已定义的过程和可测量的目标作为基础 |
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
