企业信息化笔记

信息系统的概念（*）
信息系统的类型（*）
信息系统生命周期（*）
系统建模（*）
信息系统战略规划（*）
政府信息化与电子政务（*）
企业信息化与电子商务（*）
企业应用集成（*）
企业门户（**）

1.*

信息的定义

香农：信息就是不确定性的减少
维纳：信息就是信息，既不是物质，也不是能量

信息的特点

客观性
动态性
层次性
传递性
滞后性
扩压性
分享性

信息化的概念

信息化是从工业社会到信息社会的演进和变革
信息化主体是全体社会成员（政府、企业、团体、个人），时域是一个长期过程，空域是经济和社会的一切领域，手段是先进社会生产工具

信息化对组织的意义

组织的结构创新
组织的管理创新
组织经营创新
三类人才：IT专业人才，业务人才，专家型人才

信息化标准、法律和规定

信息系统的生命周期

立项阶段：企业全局、形成概念、需求分析
开发阶段
- 总体规划
  - 初步调查、分析系统目标、子系统组成、拟实施方案、可行性研究、制定系统建设方案
  - 系统设计任务书（系统建设方案、实施计划）
- 系统分析
  - 业务流程分析、数据与数据流程分析、软件需求分析、网络需求分析
  - 系统需求规格说明书、软件需求规格说明书、确认测试计划、系统测试计划、初步的用户手册
- 系统设计
  - 软件架构设计、软件概要设计、详细设计、网络设计
  - 架构设计文档、概要设计说明书、详细设计说明书、程序规格说明书、概要测试计划、详细测试计划、各类设计圈
- 系统实施
  - 软件编码、软件单元/集成/系统测试、综合布线
  - 源码、单元测试、集成测试报告、操作手册
- 系统验收
  - 确认测试、试运行
  - 确认测试报告、项目验收报告
运维阶段：通过验收、移交之后
消亡阶段：更新改造、功能扩展、报废重建

信息系统战略规划 - 方法

第一阶段：以数据处理为核心、围绕职能部门需求
- 企业系统规划法（BSP）：自上而下识别系统目标，自下而上设计信息系统，对组织机构的变动具有适应性
- 关键成功因素法（CSF）：找实现目标的关键信息集合，从而确定开发优先次序
- 战略集合转化法（SST）：把战略“目标”看成“信息集合”，把战略目标转变成信息系统的战略目标。
第二阶段：以企业内部MIS为核心，围绕企业整体需求
- 战略数据规划法（SDP）
- 信息工程法（IE）
- 战略栅格法（SG）
第三阶段：综合考虑企业内外环境，以集成为核心、围绕企业战略需求
- 价值链分析法（VCA）
- 战略一致性模型（SAM）

2.

政府信息化和电子政务（*）

企业信息化与电子商务（*）

1. 企业资源计划（ERP）

物料需求计划（MRP）：物料单系统

制造资源计划（MRPII)：增加库存、分销等

企业资源计划（ERP）：打通了供应链，把财务、人力、销售管理等纳入

管理思想的变革
软件产品：需要个性化的开发和部署
管理系统：存在众多的子系统，这些子系统有统一的规划，是互联互通的，便于事前事中监控

第一层经营计划：经营计划是企业总目标的具体体现

第二层生产计划大纲：根据经营计划的生产目标制定的，是对企业经营计划的细化，用以描述企业在可用资源的条件下，在一定时期中的产量计划。

第三层主生产计划：对企业生产计划大纲的细化，说明在一定十七内的

第四层物料需求计划：对主生产计划的各个项目所需的全部制造件和全部采购件的网络支持计划和时间进度计划

能力需求计划：对物料需求计划所需能力进行核算的一种计算管理方法

第五层车间生产控制：在MRP所产生的加工制造订单的基础上，按照交货期的前后和生产优先级选择原则以及车间的生产资源情况，将零部件的生产计划以订单的形式下达到适当的车间

客户关系管理（CRM）

市场营销和客户服务是CRM的支柱性功能

客户服务与支持
客户群维系
商机管理
自动化销售
自动化市场营销
自动化客户服务

触发中心、挖掘中心

供应链管理（SCM）

对象包括供应商、制造商、零售商、分销商

功能包括计划、采购、制造、配送、退货

设计原则

自顶向下和自底向上结合
简洁性原则
互补性原则
协调性原则
动态性原则
创新性原则
战略性原则

商业智能（BI）

数据仓库、数据挖掘、OLAP

需求分析
数据仓库建模
数据抽取
建立BI分析报表
用户培训和数据模拟测试
系统改进和完善

数据仓库

特点

面向主题：数据按主题组织
集成的：消除了源数据中的不一致性，提供整个企业的一致性全局信息
相对稳定的（非易失的）：主要进行查询操作，只有少量的修改和删除操作
反映历史变化（随时间变化）：记录了企业从过去某一时刻到当前各个阶段的信息，可对发展历程和未来趋势做定量分析和预测

数据挖掘

方法

决策树（构建树结构进行分析）
神经网络（类似统计学中的判别、回归、聚类等功能）
遗传算法（三个基本过程：繁殖、交叉、变异）
关联规则挖掘算法（关联规则是描述数据之间存在关系的规则）

分类

关联分析：挖掘出隐藏在数据间的相互关系
序列模式分析：侧重点是分析数据间的前后关系（因果关系）
分类分析：为每一种记录赋予一个标记再按标记分类
聚类分析：分类分析法的逆过程

决策支持系统（DSS）

业务流程重组（BPR)

业务流程管理

企业门户

企业应用集成

电子商务

信息化的三流（*）
- 信息流（核心）
- 资金流
- 物流
电子商务的形式（*）
- 企业对消费者
- 企业对企业
- 消费者对消费者
- 线上对线下

软件工程笔记

系统规划
软件开发方法
- 软件开发方法（*)
- 软件开发模型（** ）
面向对象基础
- 基础概念（**）
- UML 4+1 视图（）
- UML图（ * ）
- UML关系（）
需求工程
- 需求获取（ *）
- 需求分析（ *）
软件架构分析
- 架构风格（**）
- 架构评估（**）
系统设计
- 界面设计（**）
- 业务流程设计（ *）
- 面向对象设计原则（）
- 设计模式（ * ）
测试与评审
软件开发环境与工具
系统运行与评价
- 可维护性因素（ *）
- 维护类型（ *）
软件过程改进

软件开发方法

结构化
- 用户至上
- 严格区分工作阶段，每阶段有任务与成果
- 强调系统开发过程的整体性和全局性
- 系统开发过程工程化、文档资料标准化
- 自顶向下，逐步分解
原型法
- 适用需求不明确的开发
- 包括抛弃型原型、进化型原型
面向对象方法
- 更好的复用性
- 关键在于建立一个全面、合理、统一的模型
- 分析、设计、实现三个阶段，界限不明确
面向服务的方法
- SO方法有三个主要的抽象级别：操作、服务、业务流程
- SOAD分为三个层次：基础设计曾（底层服务构件）、应用结构层（服务之间的接口和服务级协定）、业务组织层（业务流程建模和服务流程编排）
- 服务建模：分为服务发现、服务规约、服务实现

软件开发模型

瀑布模型演化模型增量模型螺旋模型快速原型模型喷泉模型 V模型迭代模型快速应用开发购件组装模型/基于构件的开发方法统一过程/统一开发方法敏捷开发方法模型驱动的开发方法基于架构的开发方法

迭代模型

瀑布模型

增量模型与螺旋模型

V模型

购件组装模型

统一过程

敏捷方法

逆向工程

净室软件工程

需求工程

1. 概述

软件需求是指，用户对系统在功能、行为、性能、设计约束等方面的期望
软件需求是指，用户解决问题或达到目标所需的条件或能力，是系统或系统不见要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明

需求管理（变更控制、版本控制、需求跟踪、需求状态跟踪）

支持需求开发（需求获取、需求分析、需求定义、需求验证）

2. 需求开发

2.1 需求获取

需求分类

业务需求、用户需求、系统需求
功能需求、性能需求、设计约束
基本需求、期望需求、兴奋需求

获取方法：收集资料、联合讨论会、用户访谈、书面调查、现场观摩、参加业务时间、阅读历史文档、抽样调查

2.2 需求分析

2.2.1 SA

SA图

DFD图

STD图

E-R图

2.2.2 OOA（*）

对象
类
- 实体类：映射需求中的每个实体，实体类保存需要存储在永久存储体中的信息
- 控制类：用于控制用例工作的类
- 边界类：用于封装在用例内、外流动的信息或数据流
抽象
封装
继承与泛化
多态
接口
消息
组件
模式和复用

OOA

UML 2.0

结构图（静态图）
- 类图
- 对象图
- 包图
- 组合结构图
- 构件图
- 部署图：软硬件之间映射
- 制品图
行为图（动态图）
- 用例图：系统与外部参与者的交互
- 顺序图：强调按时间顺序
- 通信图（协作图）
- 定时图
- 状态图：状态转换变迁
- 活动图：类似程序流程图，并行行为
- 交互概览图

2.3 需求定义

严格定义法：所有需求都能够被预先定义、开发人员与用户之间能够准确而清晰地交流、采用图形文字可以充分体现最终系统

用结构化、自然语言编写文本型文档
建立图形化模型
编写形式化规格说明

原型法：并非所有地需求都能在开发前被准确说明、项目参加者站之间通常都存在交流上地困难、需要实际地可供用户参与地系统模型、有合适地系统开发环境、反复是完全需要和值得提倡地

2.4 需求验证

需求评审：正式、非正式

需求测试

用户签字确认… 验收标准之一

3. 需求管理

3.1 定义需求基线

3.2 需求跟踪

变更控制

软件系统建模

系统设计

1. 人机界面设计

置于用户控制之下
- 以不强迫用户进入不必要的或不希望的动作的方式来定义交互方式
- 提供灵活的交互
- 允许用户交互可以被中断或撤销
- 当技能级别增加时可以使交互流水话并允许定制交互
- 使用户隔离内部技术细节
- 设计应允许用户和出现在屏幕上的对象直接交互
减少用户的记忆负担
- 减少对短期记忆的要求
- 建立有意义的缺省
- 定义直接性的捷径
- 界面的视觉布局应该基于真实世界的隐喻
- 以不断进展的方式揭示信息
保持界面的一致性
- 允许用户将当前任务放入有意义的语境
- 在应用系列内保持一致性
- 如过去的交互模型已建立起了用户期望，除非有迫不得已的理由，不要改变

2. 结构化设计

概要设计、详细设计

抽象化；自顶而下、逐步求精；信息隐蔽；模块独立（高内聚、低耦合）

保持模块的大小适中
尽可能减少调用的深度
多扇入，少扇出
单入口，单出口
模块的作用域应该在模块之内
功能应该是可预测的

3. 面向对象的设计

基本过程

分析模型：用例模型、分析模型（领域模型）

设计师：设计用例实现方案、设计技术支撑实施、设计用户界面、细化设计模型

设计模型：架构图（用包图表示）、用例实现图（用交互图表示）、类图（完整、精确）、其他（状态图、活动图）

设计原则

单一职责原则：设计目的单一的类
开放-封闭原则：对扩展开放，对修改封闭
Liskov替换原则：子类可以替换父类
依赖倒置原则：要依赖于抽象，而不是具体实现；针对接口编程，不要针对实现编程
接口隔离原则：使用多个专门的接口比使用单一的总接口要好
组合重用原则：要尽量使用组合，而不是继承关系达到重用目的
迪米特原则（最少知识法则）：一个对象应当对其他对象有尽可能少的了解

3.1 设计模式

概念：

架构模式：软件设计中的高层决策，例如C/S结构就属于架构模式，架构模式反映了开发软件系统过程中所作的基本设计决策
设计模式：主要关注软件系统的设计，与具体的实现语言无关
惯用法：用最底层的模式，关注软件系统的设计与实现，实现时通过某种特定的程序设计语言来描述构件与构件之间的关系

包括：

创建型模式
- 工厂方法模式：定义一个创建对象的接口，但由子类决定需要实例化哪个类。工厂方法使得子类实例化的过程推迟。（动态生产对象）
- 抽象工厂模式：提供一个接口，可以创建一些列相关或相互依赖的对象，而无需指定它们具体的类（生成系列对象）
- 原型模式：用原型实例指定创建对象的类型，并且通过拷贝这个原型来创建新的对象（克隆对象）
- 单例模式：保证一个类只有一个实例，并提供一个访问它的全局访问点（单实例）
- 构建器模式：将一个复杂类的表示与其构造相分离，使得相同的构建过程能够得出不同得表示（复杂对象构建）
结构型模式
- 配适器模式：转换接口
- 桥接模式：继承树拆分
- 组合模式：树形目录结构
- 装饰模式：附加职责
- 外观模式：对外统一接口
- 享元模式：汉字编码
- 代理模式：快捷方式
行为型模式
- 职责链模式：传递职责
- 命令模式：日志记录，可撤销
- 解释器模式：虚拟机的机制
- 迭代器模式：数据集
- 中介者模式：不直接引用
- 备忘录模式
- 观察者模式：联动
- 状态模式：状态变成类
- 策略模式：多方案切换
- 模块方法模式
- 访问者模式

软件测试

测试类型

动态测试：黑盒测试法、白盒测试法、灰盒测试法

静态测试：桌前测试、代码审查、代码走查

尽早、不断地进行测试
程序员避免测试在自己设计的程序
既要选择有效、合理的数据，也要选择无效、不合理的数据
修改后要进行回归测试
尚未发现的错误数量与该程序已发现错误数成正比

测试用例设计

黑盒测试法：等价类划分、边界值分析、错误推测、因果图

白盒测试法：基本路径测试、循环覆盖测试、逻辑覆盖测试

测试阶段

冒烟测试
- 单元测试
- 集成测试
  - 一次性组装
  - 增量式组装
    - 自顶向下
    - 自底向上
    - 混合式
- 确认测试
  - 内部确认测试
  - Alpha测试
  - Beta测试
  - 验收测试
- 系统测试
  - 恢复测试
  - 安全性测试
    - 负载测试、强度测试、容量测试
  - 压力测试
  - 性能测试
  - 可靠性测试
  - 可用性测试
  - 可维护性测试
  - 安装测试

V模型测试

单元测试：模块测试，模块功能、性能、接口等
集成测试：模块间的接口
确认测试：验证软件与需求的一致性。内部确认测试、Alpha测试、Beta测试、验收测试
系统测试：真实环境下，验证完整的软件配置之项能否与系统正确连接
回归测试：测试软件变更之后，变更部分的正确性对变更需求的符合性

面向对象测试

算法层（单元测试）：包括等价类划分测试、组合功能测试（基于判定表的测试）、递归函数测试、多态消息测试
类层（模块测试）：包括不变式边界测试、模态类测试、非模态类测试
模块层/类树层（集成测试）：包括多态服务测试、展平测试
系统层（系统测试）

软件调试

软件调试方法
- 蛮力法：主要思想是通过计算机找错，低效、耗时
- 回溯法：从出错处人工沿控制流程往会追踪，直至发现出错的根源。复杂程序由于回溯路径多，难以实施
- 原因排除法：主要思想是演绎和归纳，用二分法实现
软件测试与调试的区别
- 测试的目的是找出存在的错误，调试的目的是定位错误并修改程序以修正错误
- 调试是测试之后的活动，目标、方法、思路都有所不同
- 测试从一个已知的条件开始，使用预先定义的过程，有预知的结果；调试从一个未知的条件开始，结束的过程不可预计
- 测试过程可以实现设计，进度可以事先确认；调试不能描述过程或持续时间

系统运行与软件维护

数据转换与迁移

从旧数据库到新数据库：抽取、转换、装载

系统切换前通过工具迁移
系统切换前采用手工录入
系统切换后通过新系统生产

系统运行与维护

软件维护是生命周期的一个完整部分

可以将软件维护定义为需要提供软件支持的全部活动，这些活动包括在交付前完成的活动，以及交付后完成的活动。

交付前完成的活动包括交付后运行的计划和维护计划等；交付后的活动包括软件修改、培训、帮助资料等

软件架构设计

概念-> 风格 -> 设计 -> 评估

1. 软件架构的概念

1.1 概念

需求分析 ——架构——软件设计

架构设计就是需求分配，即将满足需求的职责分配到组件上

1.2 发展史

无架构阶段（汇编语言）
萌芽阶段（程序结构设计）
初级阶段（统一建模语言）
高级阶段（4+1视图）

1.3 软件架构建模

结构模型：以架构的构件、连接件和其他概念来刻画结构
架构模型：不太侧重描述结构的细节而更侧重于整体的结构
动态模型：系统的“大颗粒”的行为性质
过程模型：构建系统的步骤和过程
功能模型：由一组功能构件按层次组成，下层向上层提供服务

2. 体系结构描述语言（ADL）

3. 软件架构风格

架构设计的一个核心问题是能否达到架构级的软件复用
架构风格反映了领域众多系统所共有的结构和语义特性，并指导如何将各个构件有效地组织成一个完整地系统
架构风格定义了用于描述系统地术语表和一组指导构件系统的规则

风格包括

数据流风格：批处理序列、管道-过滤器
调用/返回风格：主程序/子程序、面向对象、层次结构
独立构件风格：进程通信、事件驱动系统（隐式调用）
虚拟机风格：解释器、基于规则的系统
仓库风格：数据库系统、超文本系统、黑板系统

3.1 数据流风格

3.1.1 批处理序列

构件为一系列固定顺序的计算单元，构件之间只通过数据传递交互。

每个处理步骤是一个独立的程序，每一步必须在其前一步结束后才能开始，数据必须是完整的，以整体的方式传递。

3.1.2 管道-过滤器

每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。这个过程通常是通过对输入数据流的变换或计算来完成的，包括通过计算和增加信息以丰富数据、通过浓缩和删除以精简数据、通过改变记录方式以转换数据和递增地转化数据等。这里地构件称为过滤器，连接件就是数据流传输地管道，将一个过滤器地输出传到另一个过滤器地输入。

3.2 调用/返回风格

3.2.1 主程序/子程序

单线程控制，把问题划分为若干个处理步骤，构件即为主程序和子程序，子程序通常可合成为模块。

过程调用作为交互机制，即充当连接件地角色。

调用关系具有层次性，其语义逻辑表现为主程序的正确性取决于它调用的子程序的正确性。

3.2.2 面向对象

构件是对象，对象是抽象数据类型的实例。在抽象数据类型中，数据的表示和它们的相应操作被封装起来，对象的行为体现在其接受和请求的动作。

连接件即是对象间交互的方式，对象是通过函数和过程的调用来交互的。

3.2.3 层次结构

构件组织成一个层次结构，连接件通过决定层间如何交互的协议来定义。每层为上一次提供服务，使用下一层的服务，只能见到与自己邻接的层。

通过层次结构，可以将大的问题分解为若干个渐进的小问题逐步解决，可以隐藏问题的复杂度。修改一层，最多影响相邻的两层。

优点

这种风格支持基于可增加抽象层地设计，允许将一个复杂问题分解成一个增量步骤序列地实现
不同的层次处于不同的抽象级别
由于每一层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现，同样为软件复用提供强大的支持

缺点

并不是每个系统都可以很容易地划分为分层地模式
很难找到一个合适的、正确地层次抽象方法

3.3 独立构件风格

3.3.1 进程通信

构件是独立的过程，连接件是消息传递。

构件通常是命名过程，消息传递的方式可以是点对点、异步或同步方式、远程过程（方法）调用等

3.3.2 事件驱动系统（隐式调用）

构件不直接调用一个过程，而是出发或广播一个或多个事件。构件中的过程在一个或多个事件中注册，当某个事件被触发时，系统自动调用在这个事件中注册的所有过程。

3.4 虚拟机风格

3.4.1 解释器

解释器通常包括一个完成解释工作的解释引擎、一个包含将被解释的代码的存储区、一个包含将被解释的代码的存储区、一个记录解释引擎当前工作状态的数据结构、以及一个记录源代码被解释执行的进度的数据结构。

具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用，缺点是执行效率比较低。

3.4.2 基于规则的系统

基于规则的的系统包括规则集、规则解释器、规则/数据选择器和工作内存，一般用在人工职能领域和DSS中

3.5 仓库风格（以数据为中心的风格）

3.5.1 数据库系统

构件主要由两大类，一类是中央共享数据源，保持当前系统的数据状态；另一类是多个独立处理单元，处理单元对数据元素进行操作

3.5.2 黑板系统

包括知识源、黑板、控制三部分

知识源包括若干独立计算的不同单元，提供解决问题的知识。知识源响应黑板的变化，也只修改黑板；黑板是一个全局数据库，包含问题域解空间的全部状态，是知识源相互作用的唯一每阶；知识源响应是通过黑板状态的变化来控制的。黑板系统通常应用在对于解决问题没有确定性算法的软件中（信号处理、问题规划、编译器优化等）

3.5.3 超文本系统

现代集成编译环境一般用这种架构风格。

构件以网状链接方式相互连接，用户可以在构件之间进行按照人类的联想思维方式任何跳转到相关构件。超文本是一种非线性的网状信息组织方法，它以节点为基本单位，链作为结点之间的联想式关联。

3.6 闭环控制架构（过程控制）

当软件被用来操作一个物理系统时，软件与硬件之间可以粗略地表示为一个反馈循环，这个反馈循环通过接受一个的输入，确定一系列的输出，最终使环境达到一个新的状态。适用于嵌入式系统，涉及连续的动作与状态。

4. 重要软件架构风格

4.1 层次架构风格

5. 基于架构的软件开发方法

6. 软件架构评估

为什么要进行架构评估？
架构评估到底评什么？
架构评估怎么评？

6.1 质量属性

6.1.1 性能

performance 是指系统的响应能力，即经过多长时间才能对某个事件制作出响应，或者在某段时间内系统所能处理的事件个数

代表参数：响应事件、吞吐量

设计策略：优先级队列、资源调度

6.1.2 可靠性

reliability 是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力

代表参数：MTTF、MTBF

设计策略：冗余、心跳线

6.1.3 可用性

availability 是系统能够正常运行的事件比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。

代表参数：故障间隔时间

设计策略：冗余、心跳线

6.1.4 安全性

security 是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性可划分为机密性、完整性、不可否认性以及可控性等特性。

设计策略：追踪审计、信息隐藏

6.1.5 可修改性

modifiability 是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。

6.1.6 功能性

functionality 是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。

6.1.7 可变性

changeability 是指体系结构经扩充或变更而成为新体系结构的能力。这种新体系结构应该符合预先定义的规则，在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列相关产品的基础时，可变性是很重要的。

6.1.8 互操作性

interoperation 软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题.

具体举例

用户提交搜索请求后,系统必须在1秒内显示结果
用户信息数据库授权必须保证99.9%可用
系统由MySQL数据库升级为Oracle数据库,必须在1人月内完成
主服务器出现严重问题无法提供服务时,备用系统10分钟内能接替工作
需要在3人周内为系统添加一种新的支付方式
视频点播时,超清模式必须保证画面具有1280*720的分辨率
主站点断电后,需要在3s内将访问请求重定向到备用站点

风险点: 指架构设计中潜在的存在问题的架构决策所带来的隐患.

敏感点:指为了实现某种特定的质量属性,一个或多个构件所具有的特性

权衡点:影响多个质量属性的特性,是多个在质量属性的敏感点

6.2 基于场景的方式

6.2.1 ATAM

6.2.2 CBAM

6.2.3 SAAM

6.2.4 质量效用树

7. 软件产品线

8. 中间件技术

9. 典型应用架构

系统安全分析与设计

项目管理

系统架构设计案例分析

系统架构设计论文

计算机组成与体系结构

1. 计算机体系结构分类

1.1 Flynn

体系结构类型	结构	关键特性	代表
单指令流单数据流SISD
单指令流多数据流SIMD
多指令流单数据流MISD
多指令流多数据流MIMD

企业信息化 笔记

1.*