信息系统开发与管理

课程定位

• 信息系统与信息管理专业的专业核心课程。
• 各类组织信息化部门的主要工作内容。
• 本课程与软件工程既有联系又有区别：
  • 本课程： “怎样用信息系统解决组织的问题？”
    • 涉及知识：组织业务+组织管理+技术
  • 软件工程： “怎样保证软件的质量和开发效率？”
    • 涉及知识：技术+工程方法

课程概述

• 信息系统是管理信息系统的简称。

  • 系统： 系统是内部互相依赖的各个部分，按照某种规则，为实现某一特定目标而联系在一起的合理的、有序的组合。
  • 信息系统： 输入数据/信息，通过加工处理产生信息的系统。在当前阶段，特指用计算机实现的数据处理系统。
  • 管理信息系统： 利用计算机硬件和软件，手工作业，分析、计划、控制和决策模型，以及数据库的用户—机器系统。它能提供信息支持企业或组织的运行、管理和决策功能。

• 管理信息系统不仅是软件，还包括应用软件的组织（人、硬件、规章制度等）。

• 广义上的管理信息系统包括人力资源管理、客户关系管理、供应链管理、财务管理、物流管理和电子商务等系统，约占整个软件市场份额的70%。

• 信息系统的开发是广义上的开发，主要包括

  • 规划（课程第3章）
  • 分析（课程第4、5章）
  • 设计（课程第6章）
  • 实施（开发、测试、安装、培训等）
  • 运行和维护（课程第7章）。
  • 本课程所述的系统“开发”涉及范围远远大于通常意义上的软件开发，因此有的资料称为“建设”。

课程要求

• 期末考试（占比50%），开卷，范围以课件为准。
• 平时成绩（占比20%），签到和学习通课后作业。
• 实验（占比30%），签到和实验报告。自行选题设计一个管理信息系统，按模板要求提交设计报告。

第1章 信息系统的基本概念

• 1 信息的基本概念
• 2 信息系统的基本概念
• 3 信息系统的开发

1 信息的基本概念

• 数据： 一般意义上认为是客观实体的属性值，是对客观事物记录下来的，可以鉴别的符号（数字，字符、文字、图形等等）。
  • 回顾数据库课程中的数据的特征：数据与其语义是不可分的。
• 信息： 构成一定含义的一组数据就称为信息。
  • 信息是对数据加工的结果。
  • 信息是帮助人们做出正确决策的知识。
  • 信息是能够导致某种决策的外界情况。
  • 数据和信息是原料和成品的关系。

$$\mathrm{数}\mathrm{据}+\mathrm{处}\mathrm{理}\to \mathrm{信}\mathrm{息}$$

• 概念辨析——数据、信息、知识和智慧：

  • 数据是信息的物理表现形式。
  • 信息是数据的内容。经常需要将数据处理成指定的形式才能获取需要的信息。
  • 长期有效的信息才能成为知识；知识通常是对因果关系的理论描述；
  • 具备获取和使用知识的能力为智慧。

• 传统上，由于数据处理成本高，人类重点关注知识的获取；

• 在大数据时代，随着数据处理成本的下降，并非长期有效的信息也能带来不菲的收益，越来愈多地得到人们的重视。

• 知识的获取与应用举例——吸烟与肺癌的关系：

  • 1948 年，英国医生 Richard Doll 和 Austin Bradford Hill 从伦敦的医院里观察了 649 例男性和 60 例女性肺癌死亡病人和相同数量的非癌症死亡病人的吸烟习惯，并排除其他可能的影响因素。结果显示，肺癌死亡病人中吸烟的比例明显高于非肿瘤死亡者中吸烟的比例。
  • 1951 年，Doll 和 Hill 对 34439 名男医生和 619 名女医生进行了为期 40 年的追踪调查研究。结果显示，吸烟者的总死亡率是不吸烟者的 2 倍，而患肺癌的死亡率是不吸烟者的 20 倍。
  • [此处需结合PPT中的生存率曲线图理解]

• 大数据时代，信息的获取与应用举例——体育比赛结果预测

  • “章鱼保罗”只是个“幌子”；
  • 百度大数据曾准确预测了2014年世界杯的所有胜负场；
  • Tipp24 AG公司已针对欧洲博彩业构建的下注和预测平台。
  • [此处需结合PPT中的章鱼保罗和国旗矩阵图理解]

• 智慧的获取与应用举例—— TRIZ理论：

  • TRIZ是俄文英译的缩写，直译为“发明家式的解决任务理论”。
  • TRIZ理论由俄国人阿利赫舒列尔 在1946年代所创。他审阅世界各种专利达四十万项，而发现这些发明之后的规律。
  • 目前，国际上已经对超过250万项出色的专利进行过研究，形成了庞大的理论体系，主要包括
    • 8大技术系统进化法则；
    • IFR最终理想解；
    • 40个发明原理；
    • 39个通用参数和阿奇舒勒矛盾矩阵；
    • 物理矛盾和分离原理；
    • 物-场模型分析；
    • 76个标准解法；
    • ARIZ发明问题解决算法；
    • 科学原理知识库。

信息的特性：

1、真伪性：

• 真实而准确的信息才可以帮助人们做出正确的决策，实现信息的价值。而虚假信息，即不真实、有错误的信息不但不能帮助人们做出正确的决策，反而可能会带来严重的错误，其价值可能为负。
• 案例： 日本瑞穗证券“乌龙指”事件——2005年12月8日，日本瑞穗证券一名交易员接到客户委托，要求以 61 万日元的价格卖出 1 股 J-Com 公司的股票，但交易员却误输为以每股 1 日元的价格卖出 61 万股。指令发出后，J-Com 公司股价迅速下跌，尽管交易员在 1 分 25 秒后意识到错误并连续 3 次发出撤单指令，但均因东京证交所交易系统的 bug 被拒绝。瑞穗证券随后采取反向买入指令，又导致 J-Com 股价大幅上涨。最终，瑞穗证券因这一错误蒙受了高达 400 亿日元（约合 27 亿元人民币）的损失，日经指数也大跌 301.3 点。
• 思考： 信息系统应如何避免上述错误的发生?

2、层次性：

• 信息大多是为管理服务的，而现实世界中管理是分层的，不同的管理层需要不同的信息，所以信息也具有层次性。
• 可以人为地将信息分为战略级、策略级和执行级三个层次。

[此处需结合PPT中的金字塔图理解]

• 高层决策 -> 战略级信息 -> 决策支持系统 DSS (Decision Support System)

• 中层管理 -> 策略级信息 -> 管理信息系统—MIS (Management Information System)

• 基层管理 -> 执行级信息 -> 数据处理系统—DPS (Data Process System)

• 执行级信息管理举例：

  • 库存管理系统之出库管理功能。
  • [此处需结合PPT中的软件界面截图理解，图中展示了“车间查询库存状况”、“车间建单请料”、“库房准备、发料”、“车间确认收到”的流程步骤]

• 策略级信息管理举例：

  • 精益生产管理系统中的合同基本信息和合同物料明细表。
  • [此处需结合PPT中的软件界面截图理解]

• 战略级信息管理举例：

  • 生产看板（生产进度报告系统）。
  • [此处需结合PPT中的进度条图表截图理解]

• 不同层次的信息在系统中所表现出来的特征也有所不同：

	信息来源	信息寿命	加工方法	使用频率	加工精度	保密要求
战略级	大多外部	长	灵活	低	低	高
策略级	内外都有	中	中	中	中	中
执行级	大多内部	短	固定	高	高	低

3、不完全性：

• 客观事实的全部信息是不可能得到的。
• 思考： 如何应对信息的不完全性？

4、滞后性：

• 信息是数据加工后的结果，因此信息必然落后于数据。
• 注意： 信息的滞后性可能会影响真伪性。
• 思考： 如何应对信息的滞后性？
• 人们通过信息技术不断提高信息的采集、传输和处理速度，进入了大数据时代。大数据决策逐渐成为主要的决策方式。

5、扩散性：

• 信息的扩散性就象热量的扩散一样，热量越高，扩散能力越强。
• 利用信息的扩散性，注意信息的保密性。
• 案例： 龙拱港开展 “人人都是业务员” 活动，打破岗位局限，让每一位员工都参与到业务拓展中来，使港口的信息源呈几何式扩散。活动期间，来自辽宁、重庆等地的客户通过招商视频中的联系方式与港口取得联系，进行相关业务洽谈。
• 在网络时代，利用信息扩散性的难点不在于技术渠道，而在于投放的精准性。
• 相关概念——信息威胁论：随着互联网技术的发展，信息呈现爆炸式增长，远远超出了人类能够处理和理解的速度。人们每天面临着海量的信息，难以从中迅速而准确地获取自己最需要的信息，甚至会被大量无用和不真实的信息所干扰，从而导致决策失误、认知混乱等问题。

6、概括性：

• 主要指能够对信息进行统计、综合和概括，进而用数学的方法在计算机上找出规律预测未来。
• 通过信息获取知识是人们长期以来关注的工作，信息技术提供了越来越多的方法。
• 相关概念——数据挖掘（Data mining）： 应用一系列技术从大型数据库或数据仓库的数据中提取人们感兴趣的信息和知识，这些知识或信息是隐含的、事先未知而潜在有用的，提取的知识多表示为概念、规则、规律和模式等形式。

7、共享性：

• 信息增加分享者后不会使原享有者失去信息。
• 共享性是信息不同于物质的重要特性。
• 案例： Visual Basic、Visual C++等是Microsoft推出的可视化开发工具。1997年，Microsoft推出Visual Studio 97将上述工具打包成一个产品捆绑出售，即买一种软件免费赠送其它全部开发工具。
• 思考： Microsoft为何采用这样的营销策略？
• 相关案例： 免费游戏的大量出现。
• 思考： 免费游戏的营销方式应用了信息的哪些特性？

8、转化性：

• 信息能够以多种形式存在；合适的形式才能支持决策，产生价值。
• 信息转化的目的是为了实现信息的价值。

补充9、价值性：

• 信息的价值有两种衡量方法：
• 一种是按所花的社会必要劳动时间来计算，称为内在价值；
• 另一种是按信息的使用效果来计算，称为外延价值。
• 思考： 人们的网购记录形成了电商所利用的大数据。电商通过大数据分析与决策获得的收益是否要分给每个提供原始数据的人？

信息的生命阶段

从信息的生产到最终使用发挥其价值，可分为需求（识别）、获取（收集、传输、加工）、存储、维护、使用和退出过程。

• 举例： 生产进度看板的信息生命周期。
  • 作业票 (加工前) -> 基本生产活动 -> 作业票 (加工后) -> 信息系统 -> 下发/回收 [此处需结合PPT流程图理解]

1、信息的识别：

• 为什么要识别？
  • 因为利用信息需要成本，一个具体的需求最好只采集必要的信息，因此需要人们进行识别。
• 信息由谁来识别?
  • （1）由管理者、决策者识别（用户了解组织，但缺少系统设计和计算机知识）。
  • （2）信息系统开发人员在系统开发过程中识别（开发人员不了解用户组织，但资深人员了解同类组织）。
  • （3）由管理者、信息系统开发人员共同识别（开发人员必须不断深入地与用户进行交流，才能逐步确定用户的实际需求）。
  • 识别人员如果是用户所在组织中的懂计算机知识的人员（信管部门的系统设计师），会容易很多。

2、信息的收集：

• 信息收集方法：
  • ①自底向上广泛收集
    • 例如局部零件的生产开始和结束信息被信息系统自动采集、汇总，形成各个产品的生产进度看板。
    • 这种方式需要提前设计好信息收集的方法，并开发相应的信息系统。
  • ②有目的的专项收集
    • 例如通过发放问卷调查用户的满意度。
    • 这种方式适合应突然出现的新需求，但需要付出额外的收集成本。
  • ③随机积累
    • 例如电商平台自动记录所有交易信息，提供给大数据分析平台获取各种决策信息。
    • 这种方式与方式①的区别在于先收集，在决定如何利用，经常与数据挖掘等探索式数据分析方法相结合。

3、信息的传输（光纤、万兆以太网、6G） 4、信息的加工（分布式数据处理技术） 5、信息的存储（分布式数据存储技术）

• 关注信息技术的发展，充分利用先进信息技术。

6、数据的维护

• 安全性： 保护信息防止被非法使用（软件、硬件、管理、法律方面）。
• 完整性： 保障信息的正确性和相容性。
• 一致性： 保障分布式条件下信息的一致。

7、信息的使用

• ①信息转换成合适的形式后为管理决策提供支持（相关概念——数据可视化）。
• ②信息转化后为人工智能的训练提供素材。

8、信息的退出

• 传统上，信息被利用后会被删除以节约存储成本。
• 随着存储技术的提高，大量信息被长期存储，以供为了进行数据挖掘，但仍需考虑存储成本。
• 信息是一种资源，不能轻易被抛弃。

信息资源

• 信息通过影响决策创造社会财富，是人类社会发展的一种资源。
• 狭义的信息资源指信息及其载体。
• 广义的信息资源还进一步反映了信息采集、传输、加工、存储与利用的能力和发展潜力，主要包括：
  • 信息及其载体；
  • 信息采集、传输、加工、存储的各类硬件、软件；
  • 制造上述硬、软件的关键设施；
  • 信息采集、传输、加工、存储、利用的各种方法、技术、标准、规范、规章制度、政策、法规；
  • 从事信息收集、传输、加工、存储与利用的技术与管理人员。

信息化的含义：

• 充分利用信息技术，开发利用信息资源，促进信息交流和知识共享，提高经济增长质量，推动经济社会发展转型的历史进程。
• 信息化的三要素：
  • 人、
  • 组织管理、
  • 信息技术。
  • 三者需要相互协调，共同发展。
• 目前，信息技术发展得很快，组织管理和人的因素成为阻挡信息化进步的主要障碍。
• [此处需结合PPT中的古代马车图理解]

2 信息系统的基本概念

• 信息系统是管理信息系统的简称。

  • 系统： 系统是内部互相依赖的各个部分，按照某种规则，为实现某一特定目标而联系在一起的合理的、有序的组合。
    • 系统的特性：整体性、层次性、相关性、目的性、环境适应性
  • 信息系统： 输入数据/信息，通过加工处理产生信息的系统。在当前阶段，特指用计算机实现的数据处理系统。
  • 管理信息系统（MIS）： 利用计算机硬件和软件，手工作业，分析、计划、控制和决策模型，以及数据库的用户-机器系统。它能提供信息支持企业或组织的运行、管理和决策功能（Gordon B. Davis）。

• 概念辨析——管理信息系统与信息系统。

  • 信息系统所指代的范围更大；
  • 管理信息系统是信息系统其中的一类，专门为组织管理服务。管理信息系统有时简称为信息系统。

问答与辨析

• 问题1： 以下软件是不是管理信息系统？

  • Windows、Excel、PowerPoint、Access等。

• 答案： 不是，因为管理信息系统通常有针对性地进行了设计和开发，专门用来处理组织管理相关的信息，而不是通用的信息。

• 问题2： 以下软件是不是管理信息系统？

  • 通讯录软件、日历软件等。

• 答案： 不是。

  • 管理信息系统针对多人协同使用，即为组织（特别是大型组织）所使用，而不是个人使用。

• 问题3： 以下是不是管理信息系统？

  • 超市收款系统、银行存取款系统、计算机辅助设计软件（CAD）、医学影像系统等。

• 答案： 不够资格，管理信息系统是用来处理管理与决策工作，而不是简单的辅助完成基本业务活动。

  • 从另一个角度，这些系统可用来记录业务信息，是进行管理和决策工作的基础，因此可以视作管理信息系统的一部分。

信息技术与管理活动的融合经历了四个阶段：

管理信息系统是信息技术与管理活动融合的产物。

1、 事务处理

• 利用计算机辅助处理一些基层的业务，称为电子数据处理系统（Electronic Data Processing System，EDPS），提高了员工处理日常事务的效率和准确性。
• 例如医院的挂号系统、开药系统：
• [此处需结合PPT中的医院挂号机和医生工作站图片理解]

2、 系统管理

• 对管理信息进行系统的、综合的处理，以实现企业的整体目标，开始称为管理信息系统（Management Information System，MIS）（处理问题的广度增加）。
• 例如医院信息系统（Hospital Information System，HIS），即包含挂号、缴费、医生工作站等基础功能，也包含病床调配、班次安排等综合管理功能。
• [此处需结合PPT中的HIS系统排班界面图片理解]

3、 决策支持

• 用以支持管理中的半结构化决策问题，称为决策支持系统（decision support system，DSS）（处理问题的深度增加）。

• 例如医院的实验室信息系统（Laboratory Information System, LIS）和影像归档和通信系统（Picture Archiving and Communication Systems，PACS）开始引入一些辅助分析功能。

• [此处需结合PPT中的实验室和影像分析界面图片理解]

• 相关概念——结构化、非结构化与半结构化：

  • 具有明确的目标、确定的信息需求、规范的方案探索及选择规则与程序的决策问题称为结构化问题。
  • 反之则称为非结构化问题，通常需要管理者根据经验甚至直觉判断处理。
  • 介于两者之间或两者混合的决策问题称为半结构化问题。目前已经尝试使用新技术（数据挖掘、人工智能等）支持管理者进行决策。例如医院中的检验报告分析、影像分析、疾病趋势分析、投诉分析等工作。

4、 综合集成

• 实现跨部门、跨组织的信息管理；对应用信息技术与现代管理的理念与方法进行组织变革与制度创新（处理问题的广度进一步增加）。
• 例如构建中的大健康信息系统，实现跨医院、保健、养老等组织的健康信息共享（病历、体检信息等），实现远程医疗，利用大数据支持医疗诊断、健康产品与服务推荐、膳食与运动建议、医保费用制定等工作。
• [此处需结合PPT中的大健康生态系统示意图理解]

管理信息系统的特征：

1. 信息系统与环境密切相关。
2. 信息系统的开发建设必须由管理部门来领导，要有高层领导和最终用户的参与。
3. 信息系统建设的群体性、计划性。
4. 信息系统是一个面向管理的用户—机器系统。
5. 数据库系统的特征。
6. “信息就是资源”是信息系统的一个重要特征。

• 概括： 管理信息系统是一个社会－技术系统。既要注意系统的技术属性，又要重视系统的社会属性，更要把握两者的相互关系。重视技术属性，而不重视社会属性，是应用管理信息系统初期常犯的错误。
• 案例： 1988年广州标致汽车公司决定投资建设制造资源计划（MRPⅡ），照搬法国标致的模式，总投入2000多万法郎。但最终由于法国本部的管理模式与国内不同，主系统十几个功能模块，启用的仅有库存管理模块，不到该软件内涵的十分之一。

信息系统的结构：

（1）概念结构

• 信息技术角度：
  • 信息源 -> 信息处理器 -> 信息用户 (管理者在上方进行管理)
• 管理角度： [此处需结合PPT中的金字塔结构图]
  • 顶层：战略计划与决策
  • 中层：管理控制
  • 底层：业务处理
  • 纵向切分：销售与生产子系统、生产子系统、财务子系统、其它子系统

（2）功能结构

• 由信息系统所应用的具体组织的结构和功能决定。
• 举例： 某生产信息控制系统
  • [此处需结合PPT中的系统功能模块流程图，展示订单、采购、库存、生产调度、工厂监控等子系统的关系]
• 某信息系统的功能结构：
  • [此处需结合PPT中的用友基于SOA架构的集成平台功能结构截图，展示了目标管理、战略规划、预算管理、管理驾驶舱以及下层的财务、物资、人力等模块]

（3）软件结构

• 层次结构： 底层（操作系统、数据库）、中间层（业务逻辑、数据处理）、上层（用户UI）
• 模块结构： 按用户功能划分，也有通用的登录、统计等模块。
  • [此处需结合PPT中的软件结构柱状图，展示各业务模块（如订货、库存、生产等）与公用程序、数据库管理系统的关系]
• 某信息系统的软件结构：
  • [此处需结合PPT中的SaaS/PaaS/IaaS分层架构图]

（4）硬件结构

• 空间结构： 集中式、 分布式
• 互联网的服务方式：
  • 资源共享式、
  • 浏览器/服务器（B/S）方式、
  • 客户机/服务器（C/S）方式。
• 相关概念：
  • WEB Services
  • SOA
  • 微服务
  • 云原生

<1> 集中式系统

• 信息资源在空间上集中配置（由指定少数服务器存储）的系统。
• 传统的管理信息系统多采用集中式系统方式，与传统的组织结构相匹配。
• [此处需结合PPT中的集中式拓扑图]
• 集中式系统的主要优点（简单）是：
  1. 信息资源集中，管理方便，规范统一；
  2. 专业人员集中使用，有利于发挥他们的作用，便于组织人员培训和提高工作（用人少）；
  3. 信息资源利用率高（存储需求小）；
  4. 系统安全措施实施方便。
• 集中式系统的不足（不利于往大规模发展）之处：
  1. 随着系统规模的扩大和功能的提高，集中式系统的复杂性迅速增长，给管理、维护带来困难；
  2. 对组织变革和技术发展的适应性差，应变能力弱（因为不支持局部变革）；
  3. 不利于发挥用户在系统开发、维护、管理方面的积极性与主动精神；
  4. 系统比较脆弱，主机出现故障时可能使整个系统停止工作。

<2> 分布式系统

• 利用计算机网络把分布在不同地点的计算机硬件、软件、数据等信息资源联系在一起服务于一个共同的目标而实现相互通信和资源共享的系统。
• Web、区块链都是典型的分布式系统（但不是管理信息系统）。
• 传统的管理信息系统很少采用分布式系统。随着现代组织结构往扁平化、网络化发展，集中式系统会逐渐往分布式系统转变，出现了集中分布式混合系统，例如社保系统、银行系统、沃尔玛、苏宁等企业的分布式ERP等。
• [此处需结合PPT中的分布式网络拓扑图]
• 分布式系统具有以下优点（支持大规模、健壮）：
  1. 可以根据应用需要和存取方便来配置信息资源（大规模系统存储成本低）；
  2. 有利于发挥用户在系统开发、维护和信息资源管理方面的积极性和主动性，提高了系统对用户需求变更的适应性和对环境的应变能力；
  3. 系统扩展方便，增加一个网络结点一般不会影响其他结点的工作，系统建设可以采取逐步扩展网络结点的渐进方式，以合理使用系统开发所需资源；
  4. 系统的健壮性好，网络上一个结点出现故障一般不会导致全系统瘫痪。
• 分布式系统的不足（管理难）之处有：
  1. 由于信息资源分散，系统开发、维护和管理的标准、规范不易统一；
  2. 配置在不同地点的信息资源一般分属信息系统的各子系统，不同子系统之间往往存在利益冲突，管理上协调有一定难度；
  3. 各地的计算机系统工作条件与环境不一，不利于安全保密措施的统一实施。
• 目前，管理信息系统在技术上已从集中式大量往分布式转变（例如“SAP上云”），但功能上的口口尚需研究和探索。

相关概念

• Web（全球广域网、WWW、万维网）：
  • 是一种全球性的、动态交互的、跨平台的分布式图形信息系统，主要包括浏览器与服务器。
  • 大规模分布式系统的特征： 具有高度内聚性（统一的协议与标准）和透明性（用户不需要关注内部操作）。
• 区块链（Block Chain）：
  • 是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式，具有去中心化、开放性、独立性、安全性、匿名性的特点。
  • 思考： 去中心化的优点和缺点？
  • 理解区块链的生活例子：
    • 如果班费由一个人记账那可能发生篡改和贪污，而改为全班都记账，使用时多人对照的方法就可避免。
    • 为了节约人力，可以每人记一部分帐，但每部分都有不同的多人记录，这些就不易串通篡改，一人丢失账本也不会导致账目丢失。
  • 区块链在当前主要用于数字货币，未来会支持版权保护、第三方验证等多种云安全的应用。
• 互联网的服务方式：
  • <1>资源共享式
    • 计算机之间通过共享资源的方式提供服务。
  • <2>浏览器/服务器（B/S）方式
    • 用户使用浏览器访问服务器资源。其优点是软件开发简单、使用方便，但功能性、安全性不如C/S方式。
  • <3>客户机/服务器（C/S）方式
    • 用户通过客户机（安装了客户端软件的计算机）在网络系统上向服务器提出服务请求，服务器根据请求向有关方面提供经过加工的信息。
    • 目前的管理信息系统（特别在移动互联网下）多数采用C/S方式，少数以B/S方式进行辅助。
• WEB Services技术：
  • 是在互联网环境下通过标准协议实现信息系统之间共享数据与功能以提供服务的方法与技术。
  • 使用该技术的各种软件通过规范的接口进行交互。它们的相互遵循特定的与平台无关的技术标准与规范（SOAP、WSDL、UDDI等），使得信息系统可能不受单一系统或网站功能的限制来提供各种服务。
  • WEB Services的典型应用：
    • <1>使用已有的组件功能。
    • <2>作为中间件联接现有软件系统，获取数据。
    • 例如网页中嵌入天气预报、汇率转换等模块，即使用了别人开发的软件功能，也获取了最新的数据。
• 组件（component）：
  • 对象管理组织（OMG）定义为系统中一种物理的、可代替的部件、它封装了实现并提供了一系列可用的接口。
• 插件（plug-in，add-in）：
  • 组件的一种，其特点为应用程序已预留好接口，在执行过程中动态调用，而一般组件是在软件开发时写入。
• 控件（control）：
  • 组件的一种，其特点为能够提供可视化的操作功能。
• 中间件（middleware）：
  • 把分布式系统中一些通用功能的抽象出来提供服务的一类软件统称，介于底层操作系统与应用软件之间。
• 面向服务架构（Service-Oriented Architecture，SOA）：
  • 将应用程序的不同功能单元（称为服务）进行拆分，通过定义良好的接口和协议联系起来，并逐步标准化，能够更方便地利用已有程序功能（软件业的“大规模生产”方式）。
  • 例如Spring、Ruby on Rails、Angular等开源框架。
  • [此处需结合PPT中的传统方式与Spring方式对比图理解]
• 微服务：
  • 一种架构设计模式，核心思想是将一个复杂的大型应用程序拆分为多个小型、独立的服务，每个服务专注于实现单一业务功能，并通过轻量级通信协议（如 REST API、gRPC）协同工作，共同完成整体业务目标。
• 云原生：
  • 面向云开发而提供的技术。在使用云原生技术后，开发者无需考虑底层的技术实现，可以充分发挥云平台的弹性和分布式优势，实现快速部署、按需伸缩、不停机交付等。
  • [此处需结合PPT中的Cloud-Native示意图理解]

3 信息系统的开发

早期，信息系统开发出现的常见问题：

1、信息系统开发人员对需求的理解出现偏差

• 偏差会导致系统质量差、返工、项目延期甚至失败。
• 案例： 2003 年厦门某信息系统项目，合同中描述“系统应实现业务中心的业务需求”，开发方认为实现业务中心软件即可。但项目开发接近尾声时，客户追问称业务中心的业务涉及和 20 几个网点之间的操作，开发方没有开发网点的客户端，不符合合同要求。最终该项目比原计划多投入接近 2 人 ×7 月 = 14 人月，这是由于开发方对客户需求中业务中心的业务范围理解不准确导致的。

2、“堆栈”现象

• 越早潜入的错误越晚发现。
• 越晚发现错误挽回的成本越大，甚至导致项目失败。
• [此处需结合PPT中的堆栈潜入错误/发现错误图理解]

3、重编程，轻规划，轻分析

• 管理信息系统是一个社会－技术系统。
• 案例： 1988年广州标致汽车公司决定投资建设制造资源计划（MRPⅡ），照搬法国标致的模式，总投入2000多万法郎。但最终由于法国本部的管理模式与国内不同，主系统十几个功能模块，启用的仅有库存管理模块，不到该软件内涵的十分之一。

4、当信息系统开发进度减缓时，采用增加人员的方式来加快进度

• 管理信息系统是一个十分复杂的系统。
• 多数开发工作不能完全并行开展，而是需要紧密沟通。
• 增加人员会使项目更加延期，因为要有沟通的成本。
• 增加人员也会明显增加系统的开发成本。

5、过低估计信息系统的投资而使开发工作夭折

• 管理信息系统是一个十分复杂的系统，很多工作在项目初期难以预料。需求变更会带来大量新的开发工作。

• 管理信息系统运行后，管理与维护也会带来大量成本。

• 冰山式系统开发费用分布： 难预见部分（系统运行与维护费用）远大于可预见部分（系统规划与开发费用）。

• [此处需结合PPT中的冰山图理解]

• 管理信息系统的巨额开发成本案例：

  • 案例： 国内机械制造集团公司为了应用国外ERP软件SAP R/3，自2003年至2008年，累计完成信息化建设投资9200万元。其中：硬件投入4000万元，软件投入2400万元，实施投入2400万元，运维投入4000万元。
  • 案例： 1986年，英国伦敦股票交易所的信息系统项目“金牛座”开发了近 10 年，花费达 1 亿美元。该交易所想建设一个大而全的信息系统，但由于摊子铺得太大，业务量太多，从硬件、软件和开发等方面都跟不上，导致项目下马。这个项目的失败不仅使 1 亿美元的投资付诸东流，还使交易所顾客遭受了 4 亿美元的损失，交易所还有 350 名员工和咨询人员失业，在信誉上也遭受了惨重损失。

如何解决上述问题的？

• 应用管理信息系统开发方法。
• 相关概念——信息系统开发思路：
  • 从上而下
  • 从下而上
• 相关概念——信息系统开发方法：
  • （1）结构化系统开发方法
    • 三维结构体系、CIM-OSA
  • （2）原型法
  • （3）面向对象开发方法

相关概念——信息系统开发思路：

• “自下而上”， “自上而下”，

  • 形式： 从局部到整体； 从整体到局部；
  • 优点： 实现简单； 总体结构良好；
  • 缺点： 总体不够周密。 实现困难。

• [此处需结合PPT中的部门层级结构图理解]

• 两种开发思路的适用范围：

  • 小型系统，
    • 适合“自下而上”；
  • 大型系统，
    • 需要两者结合，
    • 整体上“自上而下”；
    • 子系统“自下而上”。
  • 设计时更愿意强调“自上而下”，
    • 显得有开发经验，具有大局观。
  • [此处需结合PPT中的书籍和放大镜插图理解]

管理信息系统的主要开发方法：

（1）结构化系统开发方法

• 发展历程：

  • 60年代，出现结构化程序设计（SP）。
  • 70年代，出现信息系统的结构化分析（SA）、结构化设计（SD）方法、信息系统分析设计与实施STRADIS法等等。
  • 80年代，已提出的各类信息系统结构化设计方法不下30余种，并出现了可供参考的企业建模体系结构。

• 技术基础——高级语言。

• 结构化系统开发方法的思路是像设计复杂程序一样做出复杂项目的开发计划。

• 基本思路：

  • <1>把整个系统开发过程分成若干阶段，
  • <2>每个阶段分成若干活动进行，
  • <3>每项活动完成一个或多个任务，应用一系列标准、规范、方法和技术，形成符合给定规范的产品。
  • 即先将复杂系统逐层拆分出若干局部简单系统，然后为各个局部简单系统制定标准。
  • [此处需结合PPT中的阶段-活动-任务拆分图理解]

• 主要原则：

  • <1>用户参与的原则（但仅限于前两个阶段）。
  • <2>严格划分工作阶段，“先逻辑，后物理”的原则。
  • <3>“自上向下”的原则。
  • <4>工作成果描述标准化原则。

• 理论基础：

  • 系统工程方法论：“三维结构体系”（美国学者霍尔1969年提出）：时间维、逻辑维、知识维。
  • [此处需结合PPT中的三维坐标系图理解，包括时间维的各个阶段、逻辑维的各个步骤、知识维的各类知识]

• 开发步骤：

  • 1、可行性分析阶段
  • 2、信息系统规划阶段
  • 3、需求分析阶段
  • 4、信息系统分析阶段
  • 5、信息系统设计阶段
  • 6、信息系统开发实施阶段
  • 7、信息系统测试阶段
  • 8、信息系统安装调试阶段
  • 9、信息系统试运行阶段
  • 10、信息系统运行维护阶段
  • 11、信息系统更新阶段
  • 每个阶段之中还有更细致的步骤，将在后续章节介绍。

• 总结： 信息系统开发的工作不仅是编程，结构化系统开发方法编程前重规划、分析、设计，重视用户的意见，编程后重测试、维护和更新，充分重视了管理信息系统的社会属性。

• 本课程的讲授顺序（参考结构化系统开发方法的开发步骤）：

  • 第3章、信息系统总体规划（包含：2、信息系统规划阶段；1、可行性分析阶段（补充））
  • 第4章、业务流程及功能需求分析（包含：3、需求分析阶段）
  • 第5章、系统分析建模（包含：4、信息系统分析阶段）
  • 第6章、信息系统设计（包含：5、信息系统设计阶段）
  • 第2章、信息系统开发过程管理（包含：6、信息系统开发实施阶段）
  • 第7章、系统测试与运营维护（包含：8、安装调试；9、试运行；10、运行维护；11、更新阶段（补充））

• 基本原理：

  1. 数据位于现代数据处理的中心（集中式结构）
  2. 数据模型是稳定的，处理是多变的（注重扩展性，适应环境）
  3. 用户必须真正参与开发工作
  • [此处需结合PPT中的数据中心模式图理解：应用软件围绕数据和DBMS进行采集、更新、生成单据、报表、分析等操作]

• 基本观点：

  1. 面向用户的观点。
  2. 严格区分工作阶段，每个阶段规定明确的任务和所应得的成果。
  3. 按照系统的观点，自顶向下地完成研制工作。
  4. 充分考虑变化的情况。
  5. 工作的成果要成文，文献资料的格式要规范化、标准化。

• 应用举例——CIM-OSA体系结构：

  • CIM－OSA是由欧洲CIM体系结构委员会AMICE研究组在ESPRIT项目中开发的，该项目开始于1984年。

  • CIM－OSA为制造企业提供了一种参考体系结构（包括通用层和部分通用层），根据这些参考体系结构可以推导出满足特定企业需求的专门CIMS结构（即专用层）。

  • CIM－OSA定义了通用层、部分通用层和专用层三个结构通用性层次，每一层包含了三个建模阶段和四个视图。

  • [此处需结合PPT中的CIM-OSA立方体结构图理解]

    • 生成过程（具体化过程）： 通用需求 -> 部分通用需求 -> 专用需求
    • 推导过程： 需求定义层 -> 设计说明层 -> 实施描述层
    • 视图： 组织视图、资源视图、信息视图、功能视图

  • 三个层次的逐步抽取：

    • <1>通用层是CIM－OSA基本结构构成成份（通用结构模块）的一种参考目录，包括元件、约束、规则、术语、服务和协议等，该层所描述的结构成份广泛应用于CIMS中。
    • <2>部分通用层包含一组适用于多类特殊制造企业的部分通用模型。部分通用模型包括按照工业类型（行业）、企业规模、国别等不同分类的各类典型结构。
    • <3>专用层仅适用于一个特定企业，一个企业CIMS只能通过一种专用结构来描述，该结构包含了企业所必需的所有知识，可以直接用来描述企业物理元件和信息技术的集成元件。
    • 逐步抽取过程是只企业建模过程中逐步明确建模对象的特点，从通用层到专用层的过程逐步细化建模所依据的模板的过程。

  • 三个阶段的逐步推导：

    • <1>需求定义建模层是描述一个企业做什么和怎样做的建模层次，这是用户企业需求的定义阶段，是及其重要的一个阶段，用来为设计说明层和实施描述层的系统设计和实施提供选择方案。
    • <2>设计说明建模层用来构造和优化由用户根据全局经营和系统约束来定义的经营需求，属于系统组织和设计的范畴。
    • <3>实施描述建模层阐明了有效地实现企业运行的一套必须的组成元件，属于决策和系统实施的范畴。
    • 逐步推导过程是从企业需求到企业实施的逐步进行过程。推导过程用设计说明层的视图来重构用户的各种需求视图，进而得到与实施系统更加相关的说明视图。

  • 四种视图：

    • <1>组织视图描述了企业的组织结构，即功能和控制结构的职责，信息与资源的职责。
    • <2>功能视图描述了满足企业目标的功能结构和相关的控制结构。控制结构定义了控制顺序的规则或企业内部的活动流以及基本经营过程的规则。
    • <3>资源视图描述了资源、资源与功能和控制结构的关系以及资源和组织的关系（后来的模型中更经常使用过程视图）。
    • <4>信息视图描述了每个功能所需的信息。
    • 每类视图都有若干种工具进行描述。

  • 举例——“教学计划管理”业务流程图（过程视图）

    • [此处需结合PPT中的业务流程图，展示制定计划、修订、录入、初审、终审、评估等流程]

  • 举例——“教学计划管理”数据流程图顶层（信息视图）

    • [此处需结合PPT中的数据流程图，展示专业秘书、教工、处长与数据库DB_CoursePlan之间的交互]

  • 应用效果： 保障项目质量，减少总建设费用。

    • [此处需结合PPT中的费用曲线图：结构化方法前期费用较高，但后期运维费用较低；早期方法反之]

  • 存在的问题：

    1. 整个系统的开发工作费时过长，难以适应环境变化。
    2. 维护工作繁重，对用户需求变更不能做出迅速响应。
    3. 对非结构化因素较多的的问题难以处理（因为制定标准难）。
    • [此处需结合PPT中的软硬件成本交叉曲线图：软件成本随时间推移逐渐上升超过硬件成本]

（2）原型法（prototyping）

• 基本思想：

  • 在限定的时间内，用最经济的方法先开发出一个实际可用的原型系统试用；
  • 用户在使用原型的基础上，逐步评价并提出意见，反复修改直至完善。
  • 贯彻“自下而上”开发策略。
  • 时代背景——上世纪90年代开始，随着微机逐渐普及，规模较小的管理信息系统大量出现。

• 技术基础——第四代编程语言（4GL）。

  • 4GL的高效率支持实现了原型法要求的反复修改。

• 应用原型法的步骤：

  • [此处需结合PPT中的流程图]
    1. 第一步：明确用户基本需求和应用规模，成本估计。
    2. 第二步：建立初始原型。
    3. 第三步：使用原型，进一步明确用户需求。
    4. 判断：用户和分析设计者满意吗？
       • Yes -> 可应用的原型 -> 使用此原型作为应用系统开发的依据 或 直接将原型用作应用软件 -> 结束。
       • No -> 待修改的原型 -> 修改原型 -> 回到第三步。

• 应用前提：

  1. 并非所有的需求在系统开发以前都能准确地说明。
  2. 有快速的系统开发工具。
  3. 项目参加者之间存在通讯上的障碍。
  4. 需要实际的、可供用户参与的系统模型。
  5. 需求一旦确定，就可以遵从严格的方法。
  6. 大量的反复是不可避免的和必要的，应该加以鼓励。

• 优点：

  • 系统开发循序渐进，符合认识事物的规律（容易实现）；
  • 开发周期短，费用相对少；
  • 有用户的直接参与，系统更加贴近实际；
  • 易学易用，减少用户的培训时间。

• 缺点：

  • 不适合大规模系统的开发（变更成本高）；
  • 开发过程管理要求高（版本多，多阶段叠加）；
  • 用户过早看到系统原型，易使用户失去信心；
  • 系统容易过早定型。

• 案例——马屁股宽度决定了火箭的级数：

  • 火箭需要使用火车运往发射基地，
  • 途中经常需要通过隧道，
  • 隧道宽度根据火车轨道宽度设计；
  • 火车轨道宽度全世界具有统一标准（英国人定的），
  • 火车轨道宽度沿用了电车轨道宽度，
  • 电车轨道宽度沿用了马车的轮距，
  • 马车的轮距由两匹马屁股的宽度决定。
  • 结论： “习惯”的力量有时十分强大。由此产生了“路径依赖”理论。
  • [此处需结合PPT中的火箭与马屁股插图理解]

• 适用范围：

  • 处理过程明确、简单的系统，
  • 涉及面窄的小型系统。

• 不适合于：

  • 大型系统或复杂系统，
  • 管理基础工作不完善以及处理过程不规范的系统。

（3）面向对象方法（object-oriented method）

• 基本思想：

  • 借鉴了程序设计领域的面向对象思想。
  • 在程序设计领域，4GL中应用的面向对象方法支持重用代码，发挥了巨大的作用；
  • 在信息系统的开发领域，虽然多数情况下不能直接重用整个系统方案，但可以重用框架和部分功能。
  • 该领域最有名的工具IBM旗下Rational公司1995年提出的统一建模语言（Unified Modeling Language，UML）。
  • UML是使用面向对象设计方法的建模工具，但独立于任何具体程序设计语言（不是程序设计语言）。

• UML的基本元素：

  • <1>事务——是对模型中最具有代表性的成分的抽象，如类、用例、接口、接点、状态、协作、交互、包、构件、注释等；
  • <2>关系——能把事物联系在一起，可分为依赖、关联、泛化、实现；
  • <3>图——聚集了相关事物的集合，包含五类图：用例图、静态图（类图、对象图、包图）、行为图（状态图、活动图）、交互图（顺序图、协作图）、实现图（构件图、配置图）。由于UML的图是一组元素的图形表示，是相关事物与关系的可视化描述。

• 应用UML的系统开发过程：

  • <1>需求获取（用用例图描述用户需求）
  • <2>分析（用类图、状态图、顺序图等描述事务和关系）
  • <3>设计（将分析得来的事务和关系“嵌入”到基础技术类中）
  • <4>编程（自动生成部分代码）
  • <5>测试
  • [此处需结合PPT中的ATM取款状态图示例理解]

• UML的相关概念：

  • 统一开发过程（Rational Unified Process, RUP） 是与UML并行开发出来的一种软件开发过程方法。
    • RUP描述了如何有效地利用商业的可靠的方法开发和部署软件，因此特别适用于大型软件团队开发大型项目。
  • Rational Rose支持UML的可视化编程工具，
    • 具有UML模型的集成管理、对多种开发语言的支持、代码自动生成等功能。

• RUP的主要特点：

  1. 以架构设计（Architectural Design）为中心
     • 在项目初始阶段，设计师就必须完成对技术和运行平台的选取，确定整个项目的基础框架的设计，完成对公共组件（安全、日志等系统）的设计。
  2. 用例（Use Case）驱动
     • 简单地说，一个用例就是系统的一个功能。以每个用例为对象进行开发。
  3. 迭代模型(Iterative Model)
     • 每个用例的开发过程都经历四个阶段：初始、细化、构造、交付。这四个阶段反复迭代出现直至完成整个项目。通过不断迭代来细化对问题的理解，降低了项目开发的风险。

• 优点：

  • 极大地降低了代码重用的成本，
  • 加快了软件开发速度。
  • 保障了基础代码的质量。

• 缺点：

  • 使程序变得复杂，人难以理解（维护难）；
  • 对过去的代码过于依赖，不利于创新。

如今信息系统开发方法的适用情况：

• （1）结构化系统开发方法
  • 适合复杂、新出现的大型系统
  • 同时有足够的时间和资金投入
• （3）面向对象开发方法
  • 有成熟的先例可以参照的大型系统
  • 承担开发的公司掌握此开发方法，并拥有成功案例
• （2）原型法
  • 低投入、需求急的小型系统

信息系统开发人员的组织：

• 用户、系统分析员、硬件网络设计员、程序设计员、系统设计员、DBA（数据库管理员）

• 系统分析员处于核心沟通位置。

• [此处需结合PPT中的人员组织关系图理解]

• 系统分析员应具有的基本技能：

  • 人际关系方面的技能：
    • 具有建立信任、处理争端、信息交流的能力。
  • 技术方面的技能：
    • 具有运筹分析、系统开发、计算机知识与技能。
  • 两种技能在不同开发阶段中的作用：
    • [此处需结合PPT中的曲线图理解：人际关系技能在总体规划和系统实施/运行阶段要求较高；技术技能在系统分析和设计阶段要求较高]

文档管理

1、 文档的地位和作用

• 软件=文档+程序
• 文档是人脑思维活动的体现，是信息系统建设中的唯一可见物，它可以用来统一思想，防止健忘和误解。
• 文档是信息系统开发组内各类人员之间及组内外的通讯依据。
• 文档同时也是观察、控制、协调信息系统开发过程的依据。

2、 系统开发中开发人员缺乏文档管理的原因：

• 第一，程序是“硬件”，是必须最终完成的；文档是“软件”，有一些是必须完成，而有些则无严格要求，并且也可以事后补充。
• 第二，文档的形成过程实际上反映出对开发方法运用的过程，开发者往往只注意结果，不注重过程。
• 第三，程序和文档在信息系统建设中实际上是“静态”和“动态”的关系。一个是开发结果，一个是开发轨迹。开发者往往只看到程序的“静态”方面，不重视开发过程的“轨迹”。
• 第四，文档经常是给别人看的，文档的作用很多是事后才能体现出来的，系统开发人员缺乏书写文档的动力和自觉性。
• 总结： 重要性相对低、成本控制、缺少经验。

3、 文档管理的内容

• ①、文档要标准化、规范化

• ②、维护文档的一致性（文档与程序版本一致）

• ③、维持文档的可追踪性（保留历史版本文档）

• ④、文档管理的制度化

• AI写文档的优势：

  • 格式规范、成本低、效率高

• 目前AI写文档的不足：

  • 代码注释质量好，但对联系上下文的复杂逻辑理解不足。
  • 软件开发过程类文档能快速生成框架，内容仍需人类补充。
  • AI撰写的内容仍有错误的风险，AI提供的方法未经过实际验证，目前仍需人类进行校核。
  • 总结： 深层次的质量仍有不足。

第2章 信息系统的规划

• 1 概述
• 2 业务规划
• 3 数据规划
• 4 信息技术规划
• 5 可行性分析

1 概述

• 信息系统规划是组织根据自身战略目标、业务需求和内外部资源条件，对未来一段时间内（通常为 3-5 年）信息系统的建设目标、发展方向、核心架构、实施路径、资源配置及风险管控等进行系统性、前瞻性设计与部署的管理过程。

• 信息系统规划的必要性：

  • 系统性：
    • 第一、信息是企业的重要资源，应当被全企业所共享，只有经过规划和开发的信息资源才能发挥其作用。
    • 第二、各子系统除了完成相对独立的功能外，相互间还需要协调工作，总体规划的目的就是使信息系统的各个组成部分之间能够相互协调。
  • 前瞻性：
    • 第三、总体规划主要使人力、物力、时间的安排合理、有序，以保证将来的子系统的开发顺利进行。

• 信息系统规划的时机——诺兰模型：

  • 费用增长较快的两个阶段：普及期（传播阶段）、整合期（集成阶段）。
  • 信息系统设计需要关注技术的发展。
  • [此处需结合PPT中的诺兰6阶段论模型图理解，图中展示了费用随时间的S型增长曲线，包含初始期、普及期、控制期、整合期、数据管理期、成熟期，并标注了技术性断点]

• 诺兰模型的扩展：

  • 组织的信息化过程是组织管理与技术相结合、相互渗透的过程，这个过程呈现出新的条件下周而复始的演进特征。
  • 2015年左右，随着大数据、云计算和人工智能技术的大量应用进入了大数据时代（Big data Era）。
  • [此处需结合PPT中的三条S型曲线图理解：数据处理时代(DP Era) -> 信息技术时代(IT Era) -> 网络时代(Network Era)]

• 信息系统规划的内容及步骤：

  • （1）业务规划
    • 确定当前阶段利用信息系统解决什么问题。
  • （2）数据规划
    • 确定解决问题所需的数据及数据的形式。
  • （3）信息技术规划
    • 确定开发信息系统所使用的软件、硬件技术。

• 信息系统规划的组织：

  • 1、高层领导参与的必要性

  • 信息系统的社会性：

    • 规划中经常会发现一些管理流程中的弊病，克服弊病可能会导致管理机构的调整，其调整的最终决策权在高层领导。

  • 信息系统规划的全局性：

    • 任何重要资源的利用都需要有来自高层的规划的指导，信息作为一种资源，当然也不例外。
    • 当规划中出现争议和问题时，只有高层领导出面才能得以解决。
    • 信息系统开发的效率是至关重要的，为了避免信息资源开发上的浪费，必须有一个自顶向下的全局范围的信息结构，这种信息结构必须得到高层领导的确认。
    • 总体规划需要对下一步子系统的开发提出优先顺序，并做出开发预算，这些内容也必须由高层领导做最后的决策。
    • 总体规划往往要进行系统内数据定义的标准化工作，在数据定义过程中经常会出现一些问题必须由高层领导负责协调解决。

  • 2、企业或组织内总体规划的组织

  • 信息系统规划的长期性：

    • 组织一支在高层领导的倡导、支持下的强有力的规划队伍。这个队伍要在高层领导者的直接领导下，由负责全面规划工作的“信息资源规划者”和规划“核心小组”所组成，同时通过一批用户分析员和广大的最终用户相联系。——应成立长期存在的组织信息化部门。
    • （1）负责人最好出自高层领导（通常为副高层），也可以是受高层领导委任的高级管理人员（中层，但有在信息系统建设活动中考核其它中层的特权）。
    • （2）外聘顾问应该是信息系统开发方面的专家。
    • （3）全面规划工作应由强有力的核心小组（应成立长期存在的正式部门，而不能总是临时抽调人员）完成。
    • （4）最终用户（全体使用信息系统的员工）的参与。

• 实践中经常并提的两个概念

  • ——BPR（业务流程重组，组织管理制度上的改革）与ERP（企业资源计划，代表性的信息系统）：
  • ERP能够支持企业实现BPR；
  • 但不是实施ERP的企业一定要BPR。

• 由于实施ERP经常涉及BPR，

  • 因此实施ERP成功与否的难点在于管理（社会属性），而不在于技术。
  • 同时，实施ERP需要组织高层领导，而不是交给信息化部门的负责人（中层干部）。

• 案例，奥克斯铁腕实施ERP：

  • 设立20万元奖励基金；
  • 信息部长有权对部级以下管理者直接降薪，对部级以上管理者提出降薪建议；
  • 信息部长可直接将不配合的普通员工调职。

2 业务规划

• 组织中业务活动的层次：

  • <1> 业务范围： 一个组织为社会提供服务涉及的行业或专业范围。
  • <2> 业务领域： 一个组织在自己的业务范围内进行活动或提供服务的相似内容的集合，通常是按专业或产品与服务类型划分并与组织内部门划分相对应。
  • <3> 业务过程： 在业务领域内完成给定服务所必须的、逻辑上相关的一组活动，通常由若干指定岗位协助完成。
  • <4> 业务活动： 组成业务流程的各相关的活动称为基础业务活动。
  • 传统上，信息系统主要用于改进业务过程。
  • 今年来，信息系统支持大数据分析，也为企业调整业务范围和领域提供支持。

• （1）战略规划（确定或改变业务范围、调整业务领域）

  • 管理信息系统的战略规划是组织战略规划的一部分。
  • 需要明确企业需要通过管理信息系统实现什么目标？
  • 代表性方法——战略集合转移法（Strategy Set Transformation，SST）
    • [此处需结合PPT图示理解：组织战略集（使命、目标、战略、其它战略变量） -> 战略目标集转换法 -> MIS战略集（系统目标、系统约束、系统开发战略）]
  • 常用工具：战略地图（Strategy Map）。
  • 某制造企业战略地图举例：
    • [此处需结合PPT中的战略地图图片理解，包含长期股东价值、客户服务、内部运营、学习成长四个维度的因果关系链]

• （2）职能域（业务领域）

  • 职能域（Functional Area）或职能范围、业务范围，是指一个企业或组织的主要业务活动领域，可按照计划、获得、保管、处置的领域划分思路，并与组织机构相联系而产生。

  • 职能域可以使用组织机构图（组织视图）表示，例如某学校的组织机构图。

    • [此处需结合PPT中的学校组织机构图，展示了校长、副校长、各处室（规划、财务等）及各院系]

  • 职能域分析应该注意的问题：

    • 职能域可以调整（属于组织战略规划）
      • 职能域的建立来源于组织机构，因为企业职能部门的划分基于业务范围的考虑，但是又不局限于组织机构，如果在得到的职能域中发现业务范围重复或职能域之间的业务范围有交叉，则说明组织机构划分存在问题，需要考虑组织机构的调整
      • 在建立职能域的过程中，需要与高层决策者和业务主管探讨企业或组织的长期目标是什么？预计会发生或可能发生什么样的变化？所建立的职能域模型是否包含了这些目标和将来的变化？……
    • 为数据规划提供基础
      • 职能域的划分实际上还进一步明确了总体数据规划的范围和边界。
      • 作为企业或组织的最高层领导，应该认真审核所列出的职能域，检查其是否完善，同时确认总体数据规划。

• （3）业务过程

  • 每个职能域都要执行一定数目的业务过程（Process），业务过程实际上是对职能域的分解。识别业务过程目前缺乏一个较好的形式化方法，主要是靠有经验的业务人员和管理人员进行反复提炼。参考方法是对组织机构作进一步的调查，确定每个机构内部的业务范围。
  • 举例，某学校带有业务过程的组织机构图(组织视图)。
    • [此处需结合PPT图片，在组织机构图的基础上增加了“教学计划科”、“教学管理科”等具体科室]
  • 有的业务过程没有明确对应的部门，可以直接在途中命名表示，例如某部门的功能树图（功能视图）
    • [此处需结合PPT图片：人事工资管理 -> 人事管理/工资管理 -> (细分)工人人事管理/干部人事管理/考勤汇总等]

• （4）业务活动

  • 业务活动（Activity）是对业务过程的细化，每个业务过程都可能存在着一定数目的业务活动，包含的业务活动可以从业务过程的定义中识别出来。

  • 一般来说，对职能域、业务过程、业务活动的分级描述和定义，可以与管理的决策层、策略层、执行层相对应

  • 业务活动是企业或组织最基本的、不可再分的业务功能，判断分解是否到底的一个有效的方法，首先是看这个活动是否为一个人做的业务，其次看这个业务能否用一句话来说明其内容和目的，如果需要几句话来说明，那么这个活动就可能要继续细分。

  • 随着时代的发展，一组织出现了大量复合型岗位，例如销售市场岗、人事行政岗等，一个人可能负责多个业务活动，有些业务活动也不是一句话能说明的。

  • 三级业务模型部分（表格示例）：

职能域	业务过程	业务活动	定义 (略)	角色
教学管理	计划管理	制定培养计划修订日程		教工1
		下达培养计划修订日程通知		教工1
		汇总培养计划		教工1、院系教工、教学秘书
		制定培养计划评估日程		教工1
		制定培养计划评估日程		教工1
		评估培养计划		教工1、院系教工、教学秘书
		整理并修改评估后的培养计划		教工1
		审批培养计划		教务负责人
		颁布培养计划		教工1
		收集教学改革项目		教工2
		组织专家评审		教工2
		下达教学改革项目通知		教工2
		教学改革项目进度管理		教工3
		教学改革项目结题		教工3
	日常教学管理	下达教学执行计划制定日程		教工4
		汇总教学执行计划		教工4、院系教工
		协调教学执行计划		教工4、院系教工、院系负责人
		整理并修改协调后的教学执行计划		教工4
		审批执行计划		教务负责人
		下达正式教学执行计划		教工4
		教学任务分配		院系负责人
		汇总教学任务分配信息		教工5、院系教工
		排课处理		教工5
		学生选课		学生
		日常教学调度		教工6、院系教工、教师
		成绩管理		教工7
		学生学籍处理		教工8、院系教工
	教学实习	下达实习计划制定日程		教工9
		汇总实习计划		教工9
		协调实习计划		教工9、院系教工
		组织实习		教工10、院系教工、院系负责人

• （5）业务模型优化

  • 20世纪80年代，业务流程改善（Business Process Improvement, BPI），寻求对企业的业务流程的连续、渐进的改善。

  • 1990年，美国的M. 哈默（Micheal Hammer）提出业务流程重组（Business Process Reengineering, BPR），主张“推倒重来”，倡导“在一张白纸上重新开始”。

  • 美国的一些大公司，如IBM、科达、通用汽车、福特汽车等纷纷推行BPR，试图利用它发展壮大自己。实践证明，这些大企业实施BPR以后，取得了巨大成功。

  • BPR经典案例：

    • 北美福特汽车公司
      • 采购与应付帐款业务处理业务
      • 应用ERP系统的启示。
    • 2/3的汽车部件从外部供应商采购，
    • 部门员工总数500多人，工作效率低下，
    • 计划裁员20%，最后不超过400人。

  • 业务流程重组前：

    • [此处需结合PPT流程图理解：供应部发订单副本给财务科；供应商发货和发票；仓库发收料单给财务科。财务科需核对订单副本、收料单、发票三者一致后付款，流程复杂，容易出错]

  • 业务流程重组后：

    • [此处需结合PPT流程图理解：引入数据库。供应部录入订单到数据库；供应商发货；仓库收货时核对数据库中的订单信息，确认收货后更新数据库；财务科根据数据库信息直接付款。流程大大简化，实现了“无票据”处理]

  • BPR中信息系统效用的体现

    • 信息资源整合： 信息的传递具体表现为传递文件、票据、盖章或签字；传统的信息传递方式影响了流程的运行速度和结构。信息系统通过数据库集中管理信息资源，不仅加快了信息的流程速度，也简化了信息的获取流程。
    • 业务过程简化： 信息传递的简化支持业务过程的简化。
    • 人员机构重组： 业务过程的简化支持岗位的撤销与合并。

  • 信息系统对BPR的其它支持：

    • 提供制度说明，做好引导工作；
    • 共享信息资源，实现并行工作；
    • 删减监督流程，建立自我监管机制。

  • 总结： 信息系统赋予职员更高的能力，从而可以采用更高效的方式工作。近年来，AI技术的发展会进一步增加职员的工作能力。

  • 优化的业务模型应该具有以下几个特点

    • 完整性： 这种模型应该是表示组成一个企业的各个职能域中各种职能和活动的完整图表（优化不丢失原有职能）。
    • 适用性： 这种模型应该是理解一个企业合理有效的方法。在每一分析层次上，职能和活动的确定对于参与工作的管理人员来说都应该是觉得自然的和正确的（优化确实有效，不为了改变而改变）。
    • 永久性： 基于现行业务和未来发展业务的分析理念融入业务模型的优化中，只要企业的目标声明保持不变，这种模型应该保持有效（保持适度的优化频率）。

  • 组织对管理信息系统的影响：

    • （短期）管理信息系统的建立与应用应该与企业的目标、战略、改革与发展进程相适应。
    • （长期）企业组织也要以信息化建设为契机，按信息化的管理模式与运作机制改造企业，进行业务流程的改革与创新。

3 数据规划

• 四类数据环境：

  • (1)文件系统
  • (2)应用数据库
  • (3)主题数据库
  • (4)信息检索系统
  • 将组织需要管理的数据进行分类，
  • 使用不同的信息技术加以应用，
  • 以便高效、低成本地利用。

• （1）文件系统（相关技术：文件系统）

  • 数据冗余、分散，共享性不高。
  • 依赖人管理，数据检索不方便。
  • 很多文件在信息系统建设前就存在，管理数据成本低，将其转化成数据库数据成本高（未来期望使用AI低成本转化）。

• （2）应用数据库（相关技术：关系数据库）

  • 数据共享性提高，但从利用信息的角度数据依然冗余、分散。
  • 事务类数据检索快捷，但对分析类数据检索支持不够好。

• （3）主题数据库（相关技术：数据仓库、数据挖掘）

  • 从应用数据库中抽取指定数据重新构造出面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合（分析类数据），支持管理决策（Decision Making Support）。

• 相关概念——OLTP：

  • 联机事务处理（Online Transaction Processing，OLTP），也称为面向交易的处理过程，其基本特征是前台接收的用户数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果。
  • OLTP数据库旨在使事务应用程序仅写入所需的数据，以便尽快处理单个事务。

• 相关概念——OLAP：

  • 联机分析处理（Online Analytical Processing，OLAP），从大量历史数据中提取出所需要的数据，具有共享多维信息的快速分析的特征。
  • 对OLTP数据库中的数据进行再加工，以产生适合OLAP的数据，数据仓库就是如此诞生的。

• （4）信息检索系统（相关技术：分布式数据库、大数据分析平台、数据可视化）

  • 综合了多个主题数据库，实现信息的综合检索与利用。
  • 大数据分析的特点之一：探索式地发现规律，不事先进行假设限定。
  • 分布式数据库： 数据存储在地理上或逻辑上分散的多个节点（服务器 / 存储设备），但在用户或应用程序视角中呈现为 “单一统一数据库” 的数据管理系统，用于处理大规模数据。
  • 数据可视化： 借助于图形化（包括图表（chart）、图（Diagram）、地图（Map）、动态图片、视频、可交互图像等）手段，清晰有效地传达与沟通信息。在大数据时代，对数据分析前所未有地受到重视（因为数据的不确定性、动态性和相互干扰都更加明显），带动了数据可视化领域的发展。可视化成为大数据分析最后的一环，也是用户最关注的一环。

• 3.1 主题数据库规划：

  • 其核心是围绕 “业务主题”（而非部门或应用）组织数据，打破传统 “应用驱动” 的数据孤岛，实现数据的集中化、标准化和共享化，为企业数字化转型提供统一的数据底座。

• 客户关系管理（CRM）主题数据库建设举例：

  • 传统模式：每个应用（如销售系统、财务系统）自建数据库，数据重复存储（如 “客户信息” 在销售库和财务库各存一份），易产生数据不一致；
  • 主题数据库模式：“客户” 作为核心主题，构建统一的 “客户主题库”，销售、财务、客服等所有应用共享该库数据，从源头解决数据孤岛问题，支持对客户的大数据分析，为营销、制造、售后等多个部门提供决策支持。
  • 客户关系管理（customer relationship management，CRM）是管理信息系统中最为常见的应用类型之一，是数据挖掘技术的典型应用场景。
  • CRM的主要功能：
    • 客户细分；
    • 客户获得；
    • 客户保持；
    • 客户服务。
  • [此处需结合PPT中的金字塔图理解：VIP 1%, 主要客户 4%, 普通客户 15%, 小客户 80%]
  • Who is my customer? 分散的应用数据库产生零散的信息使得无法对客户有全面的了解。
  • [此处需结合PPT中的拼图图片理解：来自销售、服务、制造、市场等部门的信息是分散的拼图块，只有主题数据库提供综合全面的信息才能发现有价值的客户（拼成完整的人像）]

• 主题数据库规划关键要素：

  • （1）业务驱动：高管支持 + 业务参与
    • 需企业高管（如 CIO、业务负责人）牵头，协调跨部门资源（避免部门数据壁垒）；业务人员需深度参与主题划分和数据建模（如让销售负责人确认 “订单主题库” 需包含哪些字段，确保数据满足业务实际需求）。
  • （2）标准先行：建立统一数据治理体系
    • 主题数据库的核心是 “标准”，需先建立企业级数据标准（如数据编码标准、数据质量标准、元数据标准）；配套数据治理组织（如数据管理委员会），负责标准的落地和监督（如设置数据 Owner 负责 “客户主题库” 的数据质量）。
  • （3）技术适配：平衡理想与现实
    • 不追求 “一步到位”：若企业现有应用难以快速对接主题库，可先建 “数据集成层”（如数据中台），逐步替代传统应用的自建数据库。

• 3.2 信息系统总体结构规划 ：

  • 每一种业务活动对应信息系统中的一种功能。
  • 多数业务活动都会产生一些数据，也需要另外一些数据；
  • 明确这些数据之间关系可以帮助确定业务流程，也支持系统功能子系统的划分和关系确定。
  • 划分功能子系统，并明确功能子系统之间的数据联系，即为信息系统总体结构规划。
  • 这部分工作的常用工具为U/C矩阵。
  • U/C矩阵指Use/Create矩阵，有的地方翻译为过程/数据矩阵。

• 应用U/C矩阵的案例：

  • 某图书馆所使用的管理信息系统的功能/数据关系如下表所示。若使用U/C矩阵方法划分子系统，整理后的功能/数据关系如何？根据整理结果，该管理信息系统适合划分成几个子系统？每个子系统分别包含哪些功能？

数据类 功能	入库记录	财务报表	会员信息	支出报表	借出记录	归还记录	采购计划	账户信息	损失记录
会员办理			C
图书采购	C						U
损失统计						U			C
需求分析					U		C
缴费管理			U					C
图书借出	U				C			U
图书归还					U	C
罚款管理			U					C
成本核算	U			C
会计		C		U				U

• U/C矩阵的特点：

  • <1>每行有一个C（每个岗位产生一类数据；不产生数据的管理岗位很罕见；若产生两类及两类以上数据，应在逻辑上拆分成两个岗位）。
  • <2>每列至少有一个C（每类数据至少由一个岗位产生；少数数据由多个岗位产生）。
  • <3>多数行存在一个或一个以上的U（多数岗位都会使用其它岗位产生的数据，如没有U可能所用数据在矩阵之外）。
  • <4>多数列存在一个或一个以上的U（多数数据都会被其它岗位使用，如没有U可能使用该数据的岗位在矩阵之外）。

• U/C矩阵的变换规则：

  • <1>只能整行或整列地移动；
  • <2>将C排列到矩阵的对角线上；
  • <3>将U尽量集中。
  • 移动顺序没有严格的要求。
  • 最终根据移动后矩阵中U的聚集情况划分子模块。

• 手工移动U/C矩阵的技巧：

  • 首先将一个C按照变换规则移动到矩阵坐标（1，1）的位置；
  • 然后在不移动第1行和第1列的情况下，再将另一个C按照变换规则移动到矩阵坐标（2，2）的位置；
  • 然后在不移动第1、2行和第1、2列的情况下，再将另一个C按照变换规则移动到矩阵坐标（3，3）的位置；
  • 以此类推，直至所以C排列到矩阵的对角线上。

• 答案： 分为3个模块（下图展示了重排并划分子系统后的矩阵）：

数据类 功能	会员信息	账户信息	采购计划	入库记录	借出记录	归还记录	损失记录	支出报表	财务报表
会员办理	C
缴费管理	U	C
罚款管理	U	C
需求分析			C		U
图书采购			U	C
图书借出		U		U	C
图书归还					U	C
损失统计						U	C
成本核算				U			U	C
会计		U						U	C

• [注：表中前三行为一个模块（如会员管理），中间四行为一个模块（如借阅采购），后三行为一个模块（如财务统计）]

• 3.3 数据的分布规划 ：

  • 选择 集中式存储 或 分散式存储（分布式存储）。

  • 大部分数据的固有属性必然导致集中存储，其原因可以概括如下：

    • 使用方便：
      • 所有部门的用户需要存取相同的数据，而且需要新到“分钟”级版本的数据。这种数据就需要集中管理，避免因更新频繁而引起分散在不同地点的数据版本不实时同步问题。
      • 如果用户要检索许多分散在各地的数据，那么将这些数据集中管理要比分散管理好。
      • 为使系统具有可审查性，需要保存某些事物更新的细节,将这些细节转储到一个大型集中式数据库存储设备上，可以更便宜、更安全些。
    • 存储成本低：
      • 有的数据量太大，不能存储在便宜的外围存储设备上，最经济的方法是采用大容量的集中式存储设备。

  • 少部分数据的固有属性又必然导致分散存储，其原因可以概括如下：

    • 安全性高：
      • 部门对自己创建和维护的数据有很高的准确性、保密性和安全性要求。
    • 成本低：
      • 有些数据只在某一个地点被经常使用，而其它地点很少或根本不用。
      • 某个地点的业务对某些数据的更新频率太高时。

  • 目前，在大规模分布式技术的支持下，大部分管理信息系统可以做到“逻辑上集中，物理上分散”，即方便用户使用，又能支持利用大规模数据。

• 3.4 数据的可靠性规划 ：

  • 专用性是指针对特定业务场景、行业需求或技术环境的 “定制化适配能力”，即 “为特定用途设计” 的属性，即可能是安全性用途，也可能是高效率需求，或者特定分析处理的需求（例如主题数据库）。
  • 安全性是指如何防止数据库数据受到非法破坏和损失。
  • 完整性是指如何保证数据库中数据的正确性、一致性。
  • 并发控制是指在允许多个用户并行地访问数据库数据的条件下，如何用正确的方式调度并发操作，避免造成数据的不一致性，使每一个用户的操作不受其他用户操作的干扰 。
  • 故障恢复是指当出现部件失效、偶然事故、人为失误等故障的发生使数据遭到破坏，造成数据库不能正常工作时，如何及时修复故障并将数据库恢复到故障发生前的状态 。
  • 这部分规划需要由用户提出明确的需求，具体项目建设时再由技术人员拟定实现的技术方案。

4 信息技术规划

• 信息技术规划主要包括：

  • 技术架构： 选择底层技术栈（如服务器部署模式：私有云 / 公有云 / 混合云；数据库类型；开发语言等）；
  • 网络架构： 规划网络拓扑（如总部与分支机构的网络连接、内外网隔离、带宽配置）。

• 相关工作还包括：

  • 预算规划： 估算各 IT 项目的成本（如系统采购、开发、运维费用），分阶段分配预算（如第一年投入电商平台建设，第二年投入数据中台）；
  • 人力规划： 确定 IT 团队的人员配置（如开发、运维、安全、数据分析师的数量与技能要求），以及是否需要外部合作（如外包开发、咨询服务）；
  • 基础设施规划： 规划服务器、存储设备、网络设备的采购或租赁（如选择阿里云 / 华为云的服务器资源，而非自建机房）。
  • 如今，信息技术越来越专业化，多数组织主要做好预算规划，其它规划由长期合作的软件公司合作拟定方案。

• 管理信息系统实施方式的选择：

  • （1）自行开发

    • 在管理信息系统出现的初期,应用软件主要由客户自行组织开发。每位客户都得重新设计相同的软件，可能还需要临时雇佣相关专业人员参与开发，每次开发都是一次庞大的重复劳动。
    • 自行开发的优点：<1>可以从组织最需要信息化的关键环节入手；<2>可以针对组织的业务特点进行针对性设计；<3>有助于锻炼企业自己的IT队伍。（设计容易）
    • 自行开发的缺点：<1>开发人员不够专业；<2>组织的原有工作会影响开发进程；<3>容易拘泥于组织当前的业务环境和管理需求，难以进一步提高。（设计不专业，开发更不专业）

  • SAP的诞生：

    • 1972年，正是IBM大型主机风行的时代。而当时所谓的应用软件市场，例如企业用的财务管理软件，才刚在起步阶段。
    • 五位SAP的创始人当时都是IBM德国分公司的软件工程师，他们建议IBM为大企业项目编写现成的软件供企业自由选用，但IBM拒绝了这项建议而执意采用定制软件。
    • 在自己的“少数派报告”被忽视后，五人决定离开IBM自己创业，开发标准软件。1972年4月1日，SAP公司成立。
    • 随着时间的推移，组织自行开发管理信息系统的情况越来越少，委托该领域的专业公司外包开发的情况越来越多。

  • （2）外包

    • 企业将知识、技术等依赖性强的高增值部分掌握在自己手中，而把自己不擅长、实力不够或没有优势的其他部分外包出去，通过与他人联盟，达到整合外部资源、弥补自身劣势的目的。
    • 业务流程外包（Business Process Outsourcing, BPO）是业务流程重组（BPR）的重要方式。
    • 管理学者彼得·德鲁克（Peter F. Drucker）（2001年）：“在10年至15年之内，任何企业中仅做后台支持而不创造营业额的工作都应该外包出去。任何不提供向高级发展机会的活动和业务也应该采用外包形式”。

  • 美特斯邦威的销售和制造外包：

    • 公司本身不卖衣服，而是由分散全国的1200多家加盟店销售。
    • 公司自身无一家工厂，产品全部由国内200多家服装厂OEM（代加工）。

  • 信息系统外包是BPO的常见应用方式之一：

    • 常见的信息技术外包涉及信息技术设备的引进和维护、通信网络的管理、数据中心的运作、信息系统的开发和维护、备份和灾难恢复、信息技术培训等。
    • 管理学者彼得·德鲁克：“在IT市场越来越细分的今天，IT外包将从根本上改变IT业乃至传统行业的运作模式。未来的IT服务会像水和电一样，成为新一代公共设施。”

  • 信息系统外包的形式：

    • Gartner将信息技术的外包分为四大类型，分别由“外包业务属性”和“企业使用系统环境”两个维度组成。

    • [此处需结合PPT中的四象限矩阵图理解：

      • 左上：业务流程外包 (BPO)
      • 右上：企业服务提供商 (BSP)
      • 左下：信息技术系统外包 (IT Systems Outsourcing)
      • 右下：应用服务提供商 (ASP)]

    • 例如某传统商家想通过“电子商务”模式售卖商品，他可以先选择：

      • 1、自行开发电商平台，自行售卖（自行开发）。
      • 2、委托某软件公司开发电商平台，自行售卖（信息技术系统外包）。
      • 3、与某公司合作，该公司负责开发电商平台并售卖，商家只负责供货（业务流程外包）。
      • 4、与某大型电商平台合作，利用该平台自行售卖（相当于天猫、京东的合作商家，电商平台为应用服务提供商）。
      • 5、与某大型电商平台合作，委托该平台代理售卖（相当于天猫、京东自营产品的供货商，电商平台为企业服务提供商）。

5 可行性分析

• 应用开发策略规划：

  • 前面的规划是长期规划，此规划则需要决定近期要做什么？
  • 主要包括
    • （1）如果企业内部已经存在一些分散开发的单项信息系统，为了使这些系统与总体规划相适应，需要在“重建？改造？保留？”（更新）问题上做出决策 。
    • （2）需要确定子系统的开发顺序。
    • （3）根据这个顺序制定开发计划（人力、物力和财力——资源）。

• （1）重建？改造？保留？——更新规划

  • [此处需结合PPT中的坐标图理解：X轴为系统质量(System quality)，Y轴为业务价值(Business value)]
  • 1、高质量、高业务价值： 维护并运行
  • 2、低质量、高业务价值： 再工程
  • 3、高质量、低业务价值： 维护或抛弃
  • 4、低质量、低业务价值： 抛弃

• （2）子系统的开发顺序

  • 参考通过UC矩阵划分出的子系统，和子系统之间的数据流。
    • 从技术角度看，应优先开发提供数据的子系统。
    • 但实践应用中，更多优先开发对业务发展的最为重要的子系统。

• （3）资源分配规划

  • 安排项目开发的主要原则是：
    • <1>组织改革、发展中起重要作用的项目优先；
    • <2>在信息系统建设中具有带动与示范作用的项目优先；
    • <3>项目的安排应与组织的改革与发展的进程相配合；
    • <4>项目的安排应与组织在经济上与其他资源上的承受能力相适应；
    • <5>相关部门与人员条件较好的项目优先。
  • 总结： 先重后轻、先易后难。

• 可行性研究：

  • 目 标： 进一步明确系统的目标、规模与功能，提出系统开发的初步方案与计划。
  • 关键问题： 系统开发的技术可行性研究、经济可行性研究、运营可行性研究（此外还有时间可行性、社会认可可行性等），系统开发初步方案与开发计划的制订。
  • 主要成果： 可行性研究报告、系统开发(设计) 任务书(含计划)。
  • 管理决策： 审定可行性研报告，若同意，下达系统开发(设计)务书(或签协议、订合同)。

• 技术可行性研究：

  • 当管理信息系统需要使用新技术时，
  • 需要注意：
    • <1>该技术是否已经成熟？
      • 不要轻信广告，要看实际应用案例；
    • <2>该技术是否能够获得？
      • 确认存在转让渠道，
      • 转让费用在经济可行性中评价。
  • 案例： 汉字手写识别技术的发展（1981年IBM第一套联机系统识别率79.9%，到2001年蒙恬科技推出成熟系统）。

• 经济可行性研究：

  • 基本要求： 有预算方案，在投资限额内。
  • 高级要求： 货比三家，为甲方选择省钱的方案，充分利用甲方现有的硬件资源。
  • 由于多数情况下组织的投资预算已经确定，所以经济可行性分析的目的不是减少投入，而是说明在当期投入下能够提供更多的东西。
    • 软件方面主要是根据组织现状分阶段的开放模块和功能；同时也要避免与现有或计划中的软件出现功能重复。
    • 硬件方面主要能利用的现有资源包括组织现有服务器、客户端、网络、机房等，通常仅需对部分陈旧设备进行升级，使用“虚拟主机”、“云计算”等新技术也能够明显节约硬件投入。

• 运营可行性研究：

  • 当管理信息系统需要改变现有管理方式时，
  • 需要注意：
    • <1>获得相关部门管理人员的认可；
    • <2>新方式不会带来管理上的漏洞；
    • <3>新方式不会严重降低原有工作效率或质量；
    • <4>有人并且有能力承担相应的新工作，并且有人或有方法监督新工作的执行情况，最好有利益驱动员工使用新系统。
    • <5>变更周期较短，并且有过渡计划；风险小，并且有备用计划。如果已有成功的实验案例更好。

• 案例：空闲教室查询系统。

  • 管理上的可行性分析：
    • 由谁提供空闲教室信息？（教务处？学生会？勤工助学学生？是否已承诺承担此工作？）
    • 信息的更新频率是多少？
    • 由谁监督这项工作？（有无投诉电话？）
  • 未来能否使用技术手段
    • 减少人工劳动？例如图像识别、传感技术等。

第3章 信息系统的需求分析

• 1 需求调查概述
• 2 业务流程图
• 3 用例图与活动图
• 4 功能需求分析及描述规范
• 5 数据库概念结构设计
• 6 情景描述板

1 需求调查概述

• 需求分析与系统分析的区别：

  • 需求分析： 核心是 “明确用户到底需要什么”，聚焦于用户视角，挖掘和梳理用户的业务需求、功能需求、非功能需求，最终形成对 “系统应该解决什么问题” 的清晰定义。
    • 在实际项目中，需求分析通常属于项目签订合同前的预投入调研，最终形成项目建议书，经用户确认后，再签订开发合同。
  • 系统分析： 核心是 “如何实现用户需求”，聚焦于技术视角，在需求分析的基础上，将用户需求转化为技术方案，设计系统的整体架构、模块划分、数据流程、接口规范等，回答 “系统应该怎么做”。
    • 在实际项目中，系统分析通常在项目签到合同后在展开，细化需求分析调研结果，最终形成项目计划书，指导后续系统设计与开发工作。

• 分析与设计工具概述：

  • 结构化系统开发方法工具（3种图）与面向对象法（UML9种常用图）的关系：共同描述、互为补充

信息系统建设阶段	结构化系统开发方法	面向对象法	数据库设计阶段	设计工具
需求分析阶段	业务流程图	用例图、活动图	概念结构设计	E-R图
系统分析阶段	数据流图	类图、对象图、序列图、协作图、状态图	逻辑结构设计	关系模型
系统设计阶段	HIOP图	组件图、部署图	物理结构设计

• 需求调查部分的主要内容：

  • 1、对用户进行调研，记录、整理用户需求。开始制作术语表。
  • 2、绘制业务流程图描述用户的业务流程。
  • 3、绘制用例图描述用于与系统功能的关系，作为业务流程图的补充，如有必要绘制活动图用户工作步骤补充说明用例图。
  • 4、使用自然语言、结构式语言、判断树、判断表在前面各种图的基础详细描述各种功能。完善术语表。
  • 5、进行数据库概念结构设计，绘制ER图。
  • 6、进行UI设计，使用情景描述板与用户沟通。

• 信息系统需求调查的目的：

  • 全面、准确地收集和梳理用户需求，为后续系统设计、开发和落地提供明确依据，避免因需求模糊导致项目偏离目标。

• 良好需求的特征：

  • 良好的需求一定具有可沟通性，保证所有人对需求的理解都是一致的，具有无歧义性、可检验性、确定性、完整性、可跟踪性和正确性。

  • 1、可沟通性

    • 调研人员需具备两项核心能力：
      • 一是优质沟通能力，能够引导被调研对象准确说出需求，精准理解被调研对象的表述，通过梳理、总结形成初步需求后，再与对方沟通确认，确保需求无偏差；
      • 二是清晰文字表达能力，能将确认后的需求以准确、简洁的形式描述出来，为后续环节提供明确依据。
      • 仅靠文字描述不足以覆盖所有需求场景。为让甲方（非计算机专业人员）与乙方（专业软件开发人员）达成共识，调研人员还需借助合适的工具，将需求转化为双方均能理解的可视化或结构化形式。
    • 本章将重点介绍需求调研中的常用描述工具，包括业务流程图、结构式语言、判断树、判断表等，助力调研人员更高效地传递需求信息。

  • 2、一致性

    • 不同的被调研对象提出的需求可能存在矛盾，这可能是
    • （1）需求描述得不够细致。需要进一步明确需求，消除矛盾。
      • 例如：
        • 需求 A：“普通用户可修改自己的订单收货地址”
        • 需求 B：“订单支付后，任何角色都不能修改收货地址”
        • 两者存在不可调和的矛盾。
      • 进一步明确需求，得到：
        • 需求 A：“普通用户可修改未支付订单的收货地址”
        • 需求 B：“订单支付后，仅管理员可修改收货地址（需记录修改日志）”
        • 两者其实并不存在矛盾。
    • （2）不同的需求确实存在矛盾，需要与多方协商，修改需求，调和矛盾，最终由甲方领导确定修改后的方案。

  • 3、无歧义性

    • 需求表述唯一，不存在多种解读方式。
    • 反面案例：“系统需支持‘常用地址’功能”。
      • 可能被解读为：①用户可保存多个地址；②系统自动推荐最近使用的地址；③系统默认填充上次地址。
    • 正面案例：“用户可手动添加、编辑、删除最多 5 个常用收货地址，下单时可从常用地址列表中选择 1 个作为当前订单地址”。
    • 每个关键词（添加 / 编辑 / 删除、常用收货地址、当前订单地址）都是术语，仅有一种解读。
    • 这要求调研人员熟悉项目涉及领域的专业词汇，必要时构建术语表。

  • 4、可检验性

    • 需求可通过具体方法验证是否实现，避免 “无法判断是否达标”。
    • 反面案例：“系统要保证手机号数据安全”。
      • “安全” 无法量化检验，无法判断开发后是否满足。
    • 正面案例：“数据传输过程需采用 数据加密，系统显示用户手机号需脱敏（仅显示前 3 位和后 4 位，中间用 * 代替）”。
    • 明确了安全性的验证方式，并且用户能够简单验证。
    • 如被调研对象无法给出验证方法，需调研人员根据经验给出可行方法，然后让被调研对象确认可行。

  • 5、确定性

    • 需求不模糊、不笼统，明确 “做什么”“不做什么”“边界是什么”。
    • 反面案例：“系统要处理订单相关的异常情况”。
      • 未明确 “哪些异常”“如何处理”，开发时无方向。
    • 正面案例：“当用户支付订单后，若 15 分钟内未收到支付成功回调，系统需自动触发邮件通知管理员，同时生成‘待核实’状态的订单记录，且不自动取消订单”。
    • 明确了 “异常场景（15 分钟无回调）”“处理动作（发邮件、改状态）”“不做的动作（不取消订单）”，边界清晰。
    • 有些需求被调研对象可能也没有清晰的认识，实际工作中经常结合原型法多次调整，才能最终获得被调研对象真正的、准确的需求。

  • 6、完整性

    • 需求覆盖业务场景的所有必要环节，无遗漏的关键信息。
    • 反面案例：“用户可申请订单退款”。
      • 未说明 “退款条件”“退款流程”“退款到账方式”，实际使用时会出现漏洞。
    • 正面案例：“用户可在订单签收后 7 天内申请退款（虚拟商品除外），需上传订单截图和退款理由；系统审核通过后，退款金额需在 1-3 个工作日内原路返回用户支付账户，同时发送短信告知用户退款进度”。
      • 覆盖了 “申请条件（时间、商品类型）”“申请材料”“审核流程”“到账规则”“通知方式”，无关键环节遗漏。
    • 调研人员需根据经验提示被调研对象补全需求的细节。

  • 7、可跟踪性

    • 要有一套完善的管理机制和文档规范，明确标识和记录每项需求从最初被提出到最终被确定的变化轨迹，记录为实现需求所进行的分析、设计、实现和测试的方案及工作过程。
    • 具有可跟踪性的文档可以帮助（1）明确需求来源，避免“忘记初心”；（2）明确责任，快速排查问题；（3）辅助项目复盘，积累工作经验。

  • 8、正确性

    • 任何一项需求都必须是正确的，能够准确地描述系统必须提供的功能。
    • 需要选择具有足够经验和工作能力的被调研对象，同时调研人员还应具有足够的专业知识和经验，才能得到正确的调研结果。

• 需求调查的步骤：

  • 1、流程调查阶段——主要任务是获取需求，其内容包括业务流程调查、功能性需求调查（系统要做什么）、非功能性需求调查（系统要做到什么程度，例如反应速度、并发性支持等）。
    • 调查结果通常使用业务流程图描述。
  • 2、功能描述阶段——对功能需求的描述需要借助另外的规范和工具来完成，结构式语言、判断树、判断表是一组较好的规范和工具。但它们的可视化效果弱，为加强与用户沟通，可以利用情景描述板，直观展示企业业务功能。
  • 3、检验与确认阶段——获得的需求一定要经过检验和用户的确认。

• 需求调查前的准备：

  • 1、阅读资料
  • 2、构建术语表
    • 术语表是一份包含特定领域或主题的术语及其定义（解释含义）的清单（便于查找），
    • 能够帮助调研人员高效、准确地获取需求信息。
  • 3、制定调查计划
    • 选择调查对象、确定调查内容和计划。
  • 调查前可以做一些培训工作，向用户讲解调查的目的、任务、内容以及表达需求的文档，以便用户能够对需求进行检验和确认。培训工作日程也应该一并纳入到调查计划中。

2 业务流程图

• 业务流程图绘制标准：

  • 圆圈： 客观实体/人
  • 箭头： 流动及方向
  • 单据框（波浪底）： 各类单证、报表等
  • 开口矩形： 数据存储或存档
  • 方框（带标识栏）： 业务功能描述
  • 虚线箭头： 客观实体/人参与某项业务

• 业务流程调查的步骤：

  • （1）业务流程概要调查
    • 采用自上而下方式调查，绘制子系统的顶层业务流程图。
  • （2）业务流程详细调查
    • 对单一流程细化，细化顶层的业务流程图，绘制各部分的详细业务流程图。
  • （3）扩充业务功能
    • 计划通过管理信息系统新增或修改原有业务流程（BPR），在业务流程图中补充或修改这样预期功能。
  • （4）业务流程审查与确认
    • 与甲方管理人员共同审查，得到书面确认。

• 举例：某教学管理系统的业务流程调查

  • 首先约谈部门的主要负责人，确定业务范围、划分业务岗位。
    • 教学计划管理： 学校每年都要组织各个专业的专业负责人制订本专业的培养计划, 培养计划一旦审核通过,作为档案存储,同时印刷成册下发。
    • 教学改革项目管理： 教师根据培养计划和教学的实际，提出教学改革项目的申请，并填写申请表给项目管理员，获得审批的教学改革项目要存档，作为跟踪项目进度和结题的依据，教师完成教学改革项目的研究认为后，要提交结题报告。
    • 日常教学管理： 日常教学管理从新入学的学生填写学生登记表考试，并建立学生档案，每年组织专业负责人制订年度课程计划，即教学执行计划，根据课程计划组织日常教学工作，在考试化解完成后，根据教师提供的成绩单，建立学生成绩档案。
    • 教学实习管理： 如果在课程计划中包含有实习计划，则实习管理员开展教学实习的各项组织工作。

• 绘制各岗位的顶层业务流程图：

  • 每个岗位的业务功能先使用单一图标表示，后面再细化。
  • 关联业务功能相关的文档、人员和数据存储。
  • [此处需结合PPT图片：各专业 -> (专业培养计划) -> [教学计划管理 3.1] -> (培养计划) -> 计划管理员]

• 绘制全部岗位的顶层业务流程图，并关联在一起。

  • [此处需结合PPT流程图，展示了教学秘书、教师、学生、计划管理员、项目管理员、教务管理员、实习管理员之间的顶层业务流转，涉及培养计划、教改项目、日常教学、教学实习等模块的交互]

• 绘制各岗位的详细业务流程图：

  • 开展业务流程详细调查，约谈负责具体业务的职工，得到业务流程的具体步骤和详细文档，按业务流程细化顶层业务流程图，直至绘制出完整的业务流程图。
  • [此处需结合PPT图片：[3.1.1 制订培养计划修订日程] -> [3.1.2 下达培养计划修订日程通知] -> 院系]

• 完整详细业务流程图示例：

  • [此处需结合PPT图片，展示了从3.1.1到3.1.9的详细流程，涉及制定日程、下达通知、录入、初审、终审、评估、整理、颁布等环节，以及与培养计划主题库的交互]

• 业务流程的扩充：

  • 应用管理信息系统经常能够改进原有业务流程，结合系统功能修改相关部分的业务流程图。
  • 例如原排课处理流程（人工处理）。
  • 应用计算机排课系统后的流程（自动化排课，调整课表，打印课表）。

• 业务流程审查与确认：

  • 首先与管理人员一道共同审查这些业务流程图所描绘的工作流程是否正确，是否有遗漏的部分；
  • 其次要检查业务流程图的一致性，即在高层流程图中出现的各类报表、单证、数据存储等数据载体一定要在低层的业务流程图中反映出来，相应地，业务处理的参与者、完成者等客观实体或人也要在低一层的业务流程图中反映出来；
  • 再次要检查低层的业务流程图中是否存在这样的业务功能，它没有输入或处理完毕不产生输出，如果存在则要仔细调查这项业务功能是确实没有输入或没有输出，还是将某些输入或输出遗忘；
  • 最后要对各项业务活动和数据载体的名称进行审查，确认名称定义的正确性和准确性，不能存在同名异义或同义异名的现象。

3 用例图与活动图

• 用例（Use Case） 是在不展现系统内部结构的情况下，对系统功能的定义和描述。可以把用例理解为是要完成一件事情，而要完成这件事情就需要做一系列的活动，在做这些活动时可以采用不同的办法和步骤。

• 用例模型由用例和参与者（又称角色）组成，其中值得注意的是用户和参与者的概念有所不同，一个用户可以在系统中扮演多个角色，角色是系统行为的主体。用例模型描述了系统的功能需求，信息系统的开发以实现用例为目标。

• 用例模型通过用例图来描述，用例模型回答了每个角色执行了哪些功能，这些功能内部包含了哪些行为，这些行为的执行序列是什么，这些行为序列对哪些数据做了什么处理等等。用例图是UML的核心图、总览图，是其它工具图的基础。

• 用例图的基本符号：

  • 椭圆： 用例
  • 小人： 参与者
  • 实线箭头： 单向关联
  • 虚线箭头 (《Extend》)： 扩展
  • 虚线箭头 (《Include》)： 包含

• 用例之间的扩展关系和包含关系：

  • 如果意图是对某个完整的用例进行扩充（产生新的开发工作），那么可以使用扩展关系；
  • 如果意图是将两个或两个以上用例的共同行为分解为单个用例（复用组件），那么使用包含关系。
  • 扩展关系可以在不需要时方便地取消，而包含则必须执行，不能被随意取消。

• 用例图与业务流程图对比：

  • 用例图重点关注“系统能为用户做什么”，描述功能与用户的关系，帮助开发者尽量利用已有代码（面向对象思想）。—— 对熟悉领域的重复开发适合使用用例图。
  • 业务流程图关心“业务的步骤”，帮助开发者了解原本不熟悉的业务（面向过程思想）。—— 对新领域的首次开发适合使用业务流程图。
  • 也可以将两者相结合，先用业务流程图梳理业务，在用用例图寻找可重复利用的代码。

• 包含（Include）关系是用于描述用例之间依赖关系的重要工具，其核心用途是实现功能的复用（提取公用功能，避免重复定义）与拆分（细化用例，明确基础用例）。

  • [此处需结合PPT图片：专业秘书、教工1、主管处长通过Include关系复用“修改专业培养计划信息”和“查询专业培养计划信息”等功能]

• 用例图的层次结构：

  • 高层用例模型 -> 各个子模块的用例模型（如“教学计划管理”、“日常教学管理”等）。

• 用例模型的检验：

  • 用例模型中，除扩展用例和包含用例可以没有参与者外，每个用例都应该有角色，并且由角色启动用例。
  • 两个参与者之间不应该有“单向关联”线，即某个参与者不能启动另一个参与者。
  • 用例间的包含关系和扩展关系出现循环回路，在逻辑上是不合理的，应该重新考虑扩展用例或包含用例的设置问题
  • 如果发现有两个参与者共同启动一个用例，说明两个角色都可以操作同一个功能，当操作中出现问题时，很难鉴别是由哪个角色引发的，因此，这种现象要尽量避免。
  • 每个用例应该是一个相对独立的功能，如果包含多个功能，那么可以考虑对用例进行分解。

• 活动图：

  • 用例图缺少对业务流程的描述，如有必要，可以在用例图基础上绘制活动图进行描述。
  • 基本符号： 实心圆（开始）、圆角矩形（活动）、圆角矩形（状态）、粗横线（同步条）、菱形（判断）、同心圆（结束）、箭头（迁移）、泳道。

• 用例内部的活动图描述：

  • 例如“学生基本信息管理”的活动图描述。

• 用例间关系的描述：

  • 例如“学籍变更申请处理”的活动图描述。

4 功能需求分析及描述规范

• 功能需求分析是在业务流程图
  • 或者用例图+活动图基础上，
  • 对各种业务功能进行详细描述。
• 常用的描述工具有
  • （1）自然语言
  • （2）结构式语言
  • （3）判断树
  • （4）判断表

（1）自然语言

• 自然语言是使用最便捷、最常用的描述工具，
• 但其使用面临的一些问题：

1、模糊性

• 1.1、界限不明确
  • 举例：90分属于优还是良，表格中存在歧义。
  • 使用大于、大于等于等词汇可以准确表达这种界限。

成绩（分数）	成绩等级
90～100	优
80～90	良
70～80	中
60～70	及
60以下	不

• 1.2、逻辑条件的次序不明确

  • 例： 学校有一项奖励条件“凡各科成绩平均在92分以上，或单科最低分在85分以上，且英语成绩平均在90分以上者，可申请特等奖学金。”
  • 解释一： 有两类学生可以申请奖学金，一类是各科成绩平均在92分以上且英语成绩平均在90分以上者；另一类是单科成绩最低在85分以上且英语成绩平均在90分以上者
  • 解释二： 有两类学生可以申请奖学金，一类是各科成绩均在92分以上者；另一类是单科成绩最低分在85分以上且英语成绩平均在90分以上者。

• 1.3、意义模糊的形容词或副词

  • 例： 学校评定三好学生的标准是学习成绩好、思想道德修养好、身体健康。
  • 这个“好”的标准是什么？如果学习成绩都在90分（含90）以上者是学习成绩好，那么只有一门课程的成绩是89分，其余均为90分的学生算不算成绩好？……

2、一致性难保障，易出现冲突

• 同一事务不同人习惯使用的称呼不一样，
• 容易导致理解偏差，并且不方便检索。

3、缺乏结构化，可执行性差

• 自然语言是线性叙述，无法清晰体现功能间的层级、依赖关系。

4、冗余

• 容易出现重复描述或无关信息，增加文档阅读和梳理成本。

（2）结构式语言

• 结构式语言能够弥补自然语言上述缺点，

• 但需要一定的技术基础（程序设计，编程语言就是一种结构式语言）。

• 使用的词汇主要有以下三类：

  • ①祈使句中的动词；
  • ②在数据字典（术语表）中定义的名词；
    • 通常情况下，在下一步系统分析阶段结合数据流图才完成数据字典，此时只有相对粗糙的术语表。
  • ③某些逻辑表达式中的保留字。

• 基础的结构式语言使用的逻辑控制语句只允许有以下四类：

  • ①简单的祈使句
  • ②判断句
  • ③循环语句
  • ④上述三种的复合语句

• 结构式语言举例：

  • <例：处理订货单逻辑过程的结构英语表示法>

  IF 欠款时间<30天
      IF 需要量<库存量 THEN 立即发货
      ELSE 先按库存量发货，进货后再补发
  ELSE
      IF 欠款时间<100天 THEN
          IF 需求量<库存量 THEN 先付款再发货
          ELSE 不发货
      ELSE 要求先付欠款

  • 可直接使用中文进行结构式表达（注意定义关键字，保持一致性）
  • [此处需结合PPT中“查询功能”的中文结构式表达示例截图理解]

（3）判断树

• 判断树是用一种树型图形方式来表示多个条件、多个取值所应采取的动作。看一张判断树图形的时候，要从左边（树根）开始，沿着各个分支向右看，根据每一个条件的取值状态可以找出应该采取的动作，所有的动作都列在这张图的最右侧。

• 判断树构造方法：

  • 首先,确定有哪些条件；
  • 第二,确定每一个条件有几种可能的状态，即有几种取值；
  • 第三,要确定有哪些动作；
  • 最后,确定每一项动作要依赖哪些条件及取值。

• 判断树举例：

  • 假设学校的奖学金有两种，且记为奖学金A和奖学金B。
    • 对于奖学金A，凡各科成绩平均在88分以上、单科成绩不低于75分、英语平均在80分以上者可申请一等奖学金（金额400元）；凡各科成绩平均在85分以上、单科成绩不低于70分、英语平均在80分以上者可申请二等奖学金（金额300元）。
    • 对于奖学金B，凡各科成绩平均在92分以上、单科成绩不低于85分、英语平均在90分以上者可申请特等奖学金（金额1500元）；凡各科成绩平均在90分以上、单科成绩不低于80分、英语平均在85分以上者可申请一等奖学金（金额800元）；凡各科成绩平均在88分以上、单科成绩不低于75分、英语平均在80分以上者可申请二等奖学金（金额400元）；凡各科成绩平均在85分以上、单科成绩不低于70分、英语平均在80分以上者可申请三等奖学金（金额300元）。
  • 两个条件： 奖学金种类，成绩
  • 第一个条件有两个状态： 奖学金A和奖学金B。
  • 第二个条件有六个状态： 依据平均成绩、单科最低成绩和英语平均成绩来最终确定。
  • 有六个处理动作，即最后发放的奖学金金额。

• 其中：

  • 计算出学生的平均成绩，将值放入G中；
  • 计算出学生各科的最低成绩放入D中；
  • 计算出英语的平均成绩放入E中。

• 判断树图示（结构还原）：

  • 奖学金政策
    • 奖学金A
      • G大于等于 88 且 D大于等于75且E 大于等于80 $\to$ 400元
      • G大于等于 85 且 D大于等于70且E 大于等于80 $\to$ 300元
    • 奖学金B
      • G大于等于 92 且 D大于等于85且E 大于等于90 $\to$ 1500元
      • G大于等于 90 且 D大于等于80且E 大于等于85 $\to$ 800元
      • G大于等于 88 且 D大于等于75且E 大于等于80 $\to$ 400元
      • G大于等于 85 且 D大于等于70且E 大于等于80 $\to$ 300元

（4）判断表

• 判断表是另外一种表达工具，用表格方式来表示多个条件、多个取值所应采取的动作，与判断树的核心目标一致。

• 判断表构造方法：

  • 首先确定有哪些条件；
  • 第二确定每一个条件有几种可能的状态，即有几种取值；
  • 第三要确定有哪些动作；
  • 第四给出所有条件的组合；
  • 最后确定每一项动作要依赖哪些条件及取值。

• 判断表举例：

  • 某工厂人事部门对一部分职工重新分配工作，其分配原则：
    • “如果年龄不满18岁，文化程度是小学，则脱产学习，文化程度是中学，则当电工。如果年龄满18岁但不满40岁，如果文化程度是小学或中学，若是男性，则当钳工，若是女性，则当车工，文化程度是大学，则当技术员。如果年满40岁及以上者，文化程度是小学或中学，则当材料员，文化程度是大学，则当技术员。”
  • 有三个条件：性别、年龄、文化程度。
  • 性别有2个取值，年龄有3个取值，文化程度有3个取值
  • 所有条件的组合有：$2\times 3\times 3=18$个。

• 初始判断表：

  • （☆为后补动作）

	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18
性别	0	0	0	0	0	0	0	0	0	1	1	1	1	1	1	1	1	1
年龄	0	0	0	1	1	1	2	2	2	0	0	0	1	1	1	2	2	2
文化程度	0	1	2	0	1	2	0	1	2	0	1	2	0	1	2	0	1	2
脱产学习	※										※
当电工		※										※
当钳工				※	※
当车工													※	※
当技术员			☆			※			※			☆			※			※
当材料员							※	※								※	※

• 简化后判断表：
  • 每个动作只有一列判别条件
  • 有些动作无需判别的条件，其状态以空白表示。

	1	2	3	4	5	6	7	8	9
性别					0	0			1
年龄	0	0		1	1	2	2	1	1
文化程度	0	1	2	0	1	0	1	0	1
脱产学习	※
当电工		※
当钳工				※	※
当车工								※	※
当技术员			※
当材料员						※	※

• 判断树、判断表选用原则：
  • 优先选判断表的场景：
    • 条件数量多（如 4 个及以上），且条件之间无明显优先级，需覆盖所有可能的组合；
    • 需严格验证逻辑的完整性（避免遗漏某个条件组合），或用于技术开发中规则的精确落地（如编程时的逻辑判断）；
    • 规则需要频繁修改或维护，表格形式便于快速定位和调整某一组合的规则。
  • 优先选判断树的场景：
    • 条件数量少（2-3 个），且条件有明确的先后决策顺序；
    • 需向非技术人员（如业务方、用户）展示逻辑流程，树形结构更符合人类自然的思考路径，易于理解；
    • 逻辑规则以 “分支递进” 为主，而非 “多条件平行组合”（如 “先满足 A 条件，再判断 B 条件”）。
  • 总结：
    • 当逻辑依赖多条件的平行组合，且需确保完整性时，用判断表；
    • 当逻辑强调条件的先后顺序和流程性，且需直观展示时，用判断树。
    • 实际使用时经常先用判断树梳理流程，在构造判断表方便使用。

5 数据库概念结构设计

• 在需求分析的此阶段同步完成数据库的概念结构设计，
  • 常用实体联系（Entity-Relationship，E-R）模型表达设计方案。
  • [此处需结合PPT中的E-R图理解，包含供应商、仓库、职工、项目、零件等实体及其属性和关系]

6 情景描述板

• 情景描述板用于描述业务功能的外观和使用方式，

• 有助于开发人员与用户之间有效和准确沟通。

• 情景描述板举例：

  • [此处需结合PPT中的“学生档案信息管理”界面原型图理解，包含查询条件、学生信息列表、学生信息编辑弹窗及提示信息]

• 随着软件行业的发展，情景描述板不仅是简单的页面图片，

• 而是形成一个新的职业——UI（user interface）设计：

  • 包括页面美观设计、操作逻辑设计、人机交互设计等。
  • 随着软件开发的快速发展，UI设计已逐渐成为一个独立的专业，并具有广泛的人才需求市场。
  • [此处需结合PPT中的UI设计师职业发展及薪资图表理解]

UI设计的主要内容：

1、词汇（尽量使用专业术语，参考术语表）

• （1）词汇应该专注于业务，并且是熟悉的、无歧义的（易用性）。
• （2）词性规范运用（名词/动词，易用性）。
• （3）避免同名异义和同义异名（一致性）。

2、用户界面（UI）

• （1）界面上的展示的信息内容简洁明了，突出重点且具有结构化强的特点（清晰性）。
• （2）控件的选择以操作简单、无歧义、保证数据的正确性为主要原则（清晰性）。
• （3）界面布局风格、色彩统一且与信息系统的特征、需求、文化相适应（清晰性、美观性）。

3、操作方式

• （1）当操作不符合规范或被其他任务中断时，要有及时而清晰的提示（易用性、容错性）。
• （2）多做选择（易用性、高效性）。
• （3）清晰地标注出操作步骤、当前的位置，引导操作实现完整的操作流程（易用性、包容性）。

UI设计的基本原则：

• （1）一致性
• （2）清晰性
• （3）易用性（人性化、包容性、容错性、反馈性、高效性）
• （4）美观性（情感性）
• （5）个性化

（1）一致性

• 一致性包括词汇、选用控件、页面布局、操作流程等方方面面。
• 方便用户快速掌握软件，不要增加用户的学习成本。
• 举例： 一样的按钮风格设计能够让用户很快找到全部按钮，反之则让用户怀疑到底哪些可以按下去？
• [此处需结合PPT中的按钮风格对比图理解]
• 思考： 哪种信息系统开发思路会降低一致性？哪种信息系统开发方法最能够保障一致性。

（2）清晰性

• 安排单页合理的信息量。
  • 当用户需要仔细读取多列数据事，
    • 一个数据表格同时展示的数据行数控制住5-9行。
  • 当用户需要快速导航到所需条目时，
    • 一个导航条同时展示的数据行数控制住20-30行。
• 注意视觉传达的效率，
  • 例如复杂统计数据辅以数据图的形式展示；
• 安排合理的视觉流程，
  • 例如从左到右, 从上到下；
• 注意视觉平衡感，例如合理留白。
• 良好的视觉效果可以帮助用户提高信息获取效率。
• 参考案例： 要让界面层次分明，可以在这些方面做文章——对齐方式，间距，颜色，缩进，字体大小，元素尺寸等。当所有这些调整运用得适当时，可以提高整个界面的可读性。
• [此处需结合PPT中的界面优化前后对比图理解，左侧混乱，右侧层次分明]

（3）易用性——人性化

• 在设计总考虑到用户的感受。
• 要考虑具体应用环境带来的操作需求。
• 案例： 车载屏幕采用手式控制。[此处需结合PPT中的车载手势控制图片理解]

（3）易用性——包容性、高效性

• UI既要
  • 给熟练用户提供高效操作方式，
  • 也让普通用户凭直觉能够快速上手。
• 借鉴常用信息系统的设计方案，
  • 购买成熟的控件。
  • 可以减少用户的学习成本。
• [此处需结合PPT中的键盘快捷键贴膜图片理解]

（3）易用性——容错性、高效性

• 提供批量操作、默认填写等高效操作，但也要在用户操作失误后给出弥补手段。
• 参考案例： 假设你刚点击了一个连接或者按钮，撤销操作可以让操作流畅自然，这也符合人类的本能。而每次操作都弹一个确定框则好像是在质问用户你明白不明白这个操作会产生什么后果。
• [此处需结合PPT中的撤销提示与确认弹窗对比图理解]

（3）易用性——反馈性

• 参考案例： 各色样式的进度条或者标明状态的图标，让用户知道某些操作是否成功或者还要等多久。
• [此处需结合PPT中的进度条图片理解]

（4）美观性（情感性）

• 不同的颜色对人的感觉有不同的影响,
  • 如红色使人兴奋, 蓝色使人平静, 黑色显得庄重。
• 文字则影响人的阅读速度，
  • 如宋体、楷体适合正文，各种艺术字体适合标题。
• 不同的多媒体有着不同的表达特点：

媒体类型	特点
文 本	表现概念、刻划细节
图 形	趋向性、空间信息
动 画	突出整个事物，静态图形无法表现的动作信息
视 频	真实生活的事件和情景
语 音	对话信息突出，与动画、视频结合

• 思考： 参考信息技术与管理方法融合的各阶段，哪类信息系统功能最需要多媒体表达？
• 面向数据处理的典型管理信息系统的页面风格参考
• [此处需结合PPT中SAP系统的图表界面截图理解]

（5）个性化

• 可提供定制功能来实现个性化设计：
  • 例如手机操作系统提供给用户自定义操作页面的功能。
  • 最好还能给用户提供优化建议（例如统计哪些功能经常使用）。
• [此处需结合PPT中手机应用界面自定义截图理解]

第4章 信息系统的系统分析

• 1 系统分析概述
• 2 数据流图
• 3 UML中的几种图
• 4 数据字典
• 5 编码设计
• 6 数据库逻辑结构设计

1 系统分析概述

• 系统分析是在需求分析的基础上，

  • 进一步明确应以什么样的方式和手段满足需求分析中所提出的功能要求，为系统设计提供基础。

• 系统分析的目的：

  • 1、理解业务本质：跳出具体操作细节，深入剖析组织的业务目标、价值创造逻辑、关键流程及痛点根源，而非仅停留在 “用户想要某个功能” 的表面需求。
  • 2、明确系统边界：界定信息系统的功能范围、数据范围、接口范围及与外部实体（如其他系统、用户、第三方服务）的交互边界，回答 “系统包含什么、不包含什么” 的问题。
  • 3、构建逻辑模型：在不涉及具体技术实现（如编程语言、数据库选型、服务器架构）的前提下，用标准化的工具和语言，将业务需求转化为系统的逻辑结构、数据关系和功能流程，回答 “系统具体做什么” 的问题。

• 系统分析的主要内容：

  • 1、从业务流程图（过程模型）中抽取数据流动关系，绘制数据流图（信息模型）。
  • 2、从用例图中抽象出类图，使用状态图、序列图和协作图细化描述类图，按需绘制对象图补充说明。
  • 3、使用数据字典细致描述上述图中涉及到的数据，必要时进行编码设计补充原业务中缺失的编码。
  • 4、进行数据库的逻辑结构设计，建立关系模型。

2 数据流图

• 数据流图根据需求分析阶段的业务流程图绘制。

• 二者的主要区别：

  • 业务流程图（Business Process Diagram, BPD）： 以 “业务活动” 为核心，描述组织中人员、部门、系统之间的业务流转过程，侧重 “谁做、做什么、按什么顺序做” ，体现业务的实际执行逻辑。核心目的在于梳理现有业务流程、发现流程缺点、优化业务逻辑。
  • 数据流图（Data Flow Diagram, DFD）： 以 “数据” 为核心，描述系统中数据的来源、流转、处理、存储路径，侧重 “数据从哪来、经过什么处理、到哪去、存在哪” ，体现系统的逻辑功能。核心目的在于定义系统的逻辑功能、明确数据处理规则、为系统开发提供依据。

• 数据流图的绘制标准：

  • [此处需结合PPT中的符号对比图理解]
  • 外部实体：表示名称的矩形。
  • 数据流：带箭头的线，标注数据流名称。
  • 业务功能（加工）：带有标识、功能描述、完成人(角色)的方框（有的标准为圆角矩形或圆形）。
  • 数据存储：右边开口的长方形，包含标识和数据存储名称。

• 对比业务流程图的绘制标准：

  • [此处需结合PPT中的符号图理解]
  • 客观实体/人：圆形。
  • 各类单证、报表等：波浪底边的矩形。
  • 流动及方向：箭头线。
  • 数据存储或存档：右边开口的长方形。
  • 业务功能描述：带有标识和描述的矩形。
  • 客观实体/人参与某项业务：虚线箭头。

• 数据流图的符号含义：

  • <1>外部项（外部实体）： 外部项在数据流图中表示所描述系统的数据来源和去处的各种实体或工作环节。
  • <2>加工（数据加工）： 又称数据处理逻辑，描述系统对信息进行处理的逻辑功能。在数据流图上这种逻辑功能由一个或一个以上的输入数据流转换成一个或一个以上输出数据流来表示。
  • <3>数据存储： 逻辑意义上的数据存储环节，即系统信息处理功能需要的、不考虑存储物理介质和技术手段的数据存储环节。
  • <4>数据流： 与所描述系统信息处理功能有关的各类信息的载体。

• 数据流图举例：

  • [此处需结合PPT中的示例图理解]
  • 流程：业务员1 -> 单证1 -> 业务处理1 (1.1) -> 报表1 -> 业务处理2 (1.2) -> 报表2 -> 部门2。
  • 业务处理2 (1.2) 读取 D1 存档数据。
  • 涉及角色：业务员2、业务员3。

• 从业务流程图到数据流图：

  • 形式上的转化。
  • [此处需结合PPT中的对比图理解]
  • 左侧（业务流程图）：教学实习管理（3.4） <-> 实习管理员（虚线关联）。
  • 右侧（数据流图）：教学实习管理（3.4） <- DB_Course, -> 专业执行计划。

• 从业务流程图到数据流图：功能分析与优化

  • [此处需结合PPT中的复杂流程图理解]
  • 展示了从“制定计划修订日程”到“培养计划主题库”建立的全过程，涉及多个职能部门（教工、教学秘书、院系教工等）和多个数据处理步骤（3.1.1至3.1.9）。
  • 体现了数据如何流转并最终存储到数据库（DB_CoursePlan）以及如何生成输出（专业培养计划、修改专业培养计划、打印专业培养计划）。

• 数据流图分层举例：

  • 学籍管理系统顶层 DFD：

    • 招生办 -> 新生名单 -> 学籍管理系统
    • 学籍管理系统 -> 报表 -> 教委
    • 学籍管理系统 -> 毕业生登记表 -> 用人单位
    • 学籍管理系统 <-> D1 学籍表

  • 学籍管理系统的第一层 DFD：

    • 展开为：P1 异动管理、P2 成绩管理、P3 奖惩管理。
    • P1 处理新生名单，输出报表、毕业生登记表，更新 D1 学籍表。
    • P2 处理成绩单，读取/更新 D1 学籍表。
    • P3 处理奖惩报告，输出奖惩结论，读取 D1 学籍表。

  • “成绩管理”框的展开（第二层 DFD）：

    • P2展开为：P2.1 分析期末成绩、P2.2 统计成绩、P2.3 登记期末成绩、P2.4 分析补考成绩、P2.5 登记补考成绩。
    • 展示了各子加工与 D1 学籍表（系/校）之间的数据交互。

• 绘制数据流图的主要原则：

  • <1>明确系统边界
    • 识别出那些不受所描述的系统的控制，但又影响系统运行的外部环境，这就是系统的数据输入的来源和输出的去处。把这些因素都作为外部项确定下来。
  • <2>自顶向下逐层扩展
    • 某些数据加工项可分解为数个数据加工项，这样就形成下一层数据流图。
  • <3>合理布局
    • 一般系统数据主要来源的外部项尽量安排在左方，而数据主要去处的外部项尽量安排在右边，数据流的箭线尽量避免交叉或过长。

3 UML中的几种图

• UML中的几种图的绘制顺序和关联：

  • 整体上先绘制静态结构再绘制动态结构，然后根据动态结构补充静态结构。
  • 静态结构：
    • 1、从用例图提取出类图（Class Diagram）。
      • 考虑能不能用一个类（属性/方法）来实现一个用例？
    • 2、从类图实例化若干个对象图（Object Diagram）。
      • 通过典型对象辅助理解和说明类。
  • 动态结构：
    • 3、使用状态图（State Diaram）说明某对象在某方法触发后而产生的属性变化，反映对象的内部变化规律。
    • 4、使用序列图（Sequence Diagram）按时间顺序展示对象间的消息传递流程。
    • 5、使用协作图（Collaboration Diagram）按空间结构展示对象间的交互关系。
    • 后三种图没有严格的绘制顺序，而是根据需要交替、配合使用。

• 类图用于展示模型的静态结构，不显示暂时性的信息。

  • 类图既用于应用程序的系统分类的一般概念建模（用绘图工具绘制，支持人之间的交流），
  • 也用于详细建模，将模型转换成编程代码（用专用工具绘制，能够自动生成对应的程序代码），
  • 类图也可用于数据建模（可将类转化成数据库中的表）。
  • 类图由用例图提取产生。优先分解用例，分析包含关系，找到共同用例所对应的已有类。没有已有类可用时，根据功能说明构建新的类。
  • [此处需结合PPT中的类图示例理解：教师 -> 成绩录入（网上） -> 学生成绩实体类（包含属性如学号、姓名、课程号等，操作如查询操作、修改操作）]

• 类图的结构：

  • 类名 (Class Name)
  • 属性 (Attributes)
  • 操作 (Operations)
  • [示例：TCRCheckData类]

• 类图之间的关系：

  • Association (关联)
  • Inheritance (继承/泛化)
  • Realization / Implementation (实现)
  • Dependency (依赖)
  • Aggregation (聚合)
  • Composition (组合)

• 类之间的关系：

  • 1、泛化（Generalization）

    • 是一种继承关系，表示子类继承超类的所有特征和行为。
    • 带三角箭头的实线，箭头指向超类。
    • 为了构图清晰，子类不再重复标注超类的属性和方法，但子类拥有全部超类的的属性和方法。
    • [示例：Shape <|-- Circle]

  • 2、实现（Realization）

    • 是一种类与接口的关系，表示类是接口所有特征和行为的实现。
    • 带三角箭头的虚线，箭头指向接口。
    • 接口（Interface）是一种抽象的行为契约，本身不能被实例化，必须由其他类通过 “实现” 关系来落地。它的核心作用是解耦 “行为规范” 与 “实现细节” ，实现多态、模块化设计。
    • 举例：电商系统中，“支付功能” 可定义为IPayable接口，具体实现交给WeChatPay类、Alipay类、BankCardPay类 —— 订单系统只需调用IPayable接口的pay()方法，无需关心是微信还是支付宝支付，后续新增支付方式（如ApplePay）时，无需修改订单系统代码，仅需新增实现类即可。
    • [示例：<<interface>> IPay <|.. AliPay]

  • 3、依赖（Dependency）

    • 是一种使用关系，即一个类的实现需要另一个类的协助。
    • 带普通箭头的虚线，普通箭头指向被使用者。
    • [示例：Driver - - -> Car]

  • 4、关联（Association）

    • 是一种拥有关系，它使得一个类知道另一个类的属性和方法。
    • 带普通箭头的实线，指向被拥有者。双向的关联可以有两个箭头，或者没有箭头。单向的关联有一个箭头。
    • [示例：People -> Car]

• 依赖关系与关联关系的区别：

  • 依赖关系： 类之间短期、临时性的使用关系（如 “订单” 与 “支付工具” ），体现 “需要借助” ，通常用虚线箭头连接（箭头指向被依赖方），是一种弱关系。

  • 关联关系： 类之间长期、稳定的结构性关系（如 “学生” 与 “班级” ），体现 “拥有” 或 “相互作用” ，通常用实线连接，可标注multiplicity（如 1 对多），是一种强关系。

  • 5、聚合（Aggregation）

    • 是一种整体与部分的关系。且部分可以离开整体而单独存在。聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。
    • 带空心菱形的实线，空心菱形指向整体。
    • 电脑有键盘才能输入信息，电脑是整体，键盘是部分，键盘也可以离开电脑，单纯的拿去敲。所以是聚合。
    • [示例：Computer <>- Keyboard]

  • 6、组合（Composition）

    • 是一种整体与部分的关系。但部分不能离开整体而单独存在，组合关系是关联关系的一种，是比聚合关系还要强的关系。
    • 带实心菱形的实线，实心菱形指向整体。
    • 鸟是整体，翅膀是部分。鸟死了，翅膀也就不能飞了。所以是组合。
    • [示例：Bird <*>- Wing]

• 关联、聚合与组合关系总结：

  • [图示：A->B (关联), A<>->B (聚合), A<*>->B (组合)]
  • 聚合与组合关系：
    • 一个公司拥有多个部门，公司和部门之间是组合关系，公司破产了，部门就不复存在了。
    • 部门和员工是聚合关系，部门被裁掉，员工就换下家了。
    • [示例：Company <*>- Department <>- Staff]

• 对象图是类图的一个实例，是系统在某个时间点的详细状态的快照，用来表示两个或者多个对象之间在某一时刻之间的关系。

  • 对象图中名称栏命名方式 对象名：类名
  • 对象图中属性栏命名方式 属性名=属性值
  • 对象图之间的关系给类图相同。
  • 举例：某时间点bat这个公司有一个研发部，一个销售部，两个部门只有一个人iisheng。
  • [示例图：d1:Department(Sales), d2:Department(R&D), company:Company(bat), person:Person(iisheng) 之间的连接]

• 状态图举例：

  • [示例图：展示了 Open, Closed, Locked 状态及其之间的转换条件 (Close, Open, Lock, Unlock)]

• 序列图举例：

  • [示例图：用户手机 -> 商户系统 -> 支付宝。展示了扫码输入付款码 -> 发起支付请求 -> 同步返回支付结果 -> 轮询查询交易状态 -> 撤销交易的时序流程]

• 协作图举例：

  • [示例图：展示了 Teacher, WebInterface, DataManager, StudentInfo, Grades 之间的消息传递关系，标注了顺序号 1-8]

4 数据字典

• 数据字典（Data Dictionary）是用于定义系统中所有数据元素的标准化文档，核心作用是确保团队对数据的定义，避免歧义。

• 数据字典通常与各种图配合使用，例如与数据流图配合。其作用是给数据流图上每个成分给以定义和说明。

• 与数据流图配合的数据字典主要内容有：（1）数据流、（2）数据元素、（3）数据存储、（4）加工、（5）外部项，其中数据元素是组成数据流的基本成分。除此之外，数据词典还要对系统分析中其他需要说明的问题进行定义和说明。

• 数据词典的要求：

  • <1>一致性（命名、编号与数据流图一致）；
  • <2>完整性（对数据流图上的成分定义与说明无遗漏项）。

• 数据词典条目举例：数据流

  • [表格展示]
  • 系统名：学籍管理
  • 条目名：学生成绩通知
  • 别名：成绩通知单
  • 来源：成绩管理
  • 去处：学生
  • 数据流结构：学生成绩通知：{学号+学生姓名+{课程名称+成绩}+(补考课程名称+补考时间+补考地点)}
  • 简要说明：学生成绩通知在每学期期末考试结束后一周至下学期开学前一周期间发给所有本期在校学生。

• 数据词典条目举例：数据元素

  • [表格展示]
  • 系统名：学籍管理
  • 条目名：学号
  • 属于数据流：F1-F7
  • 存储处：D1 学生名册, D2 学生成绩
  • 数据元素结构：代码类型（字符），取值范围（00010001-992999），意义（XX XX XXX - 编号/系别代号/学生入学年号）
  • 简要说明：学号是学生的识别符，每个学生都有唯一的学号。

• 数据词典条目举例：数据存储

  • [表格展示]
  • 系统名：学籍管理
  • 条目名：学生名册
  • 存储组织：每个学生一条记录，按学号顺序排列
  • 记录数：约800
  • 数据量：约72KB
  • 主关键字：学号
  • 辅关键字：学生排名
  • 记录组成：学号、姓名、性别、出生年月...
  • 简要说明：(1)学籍变动在备注中说明 (2)重修课程在备注中说明。

• 数据词典条目举例：加工

  • [表格展示]
  • 系统名：学籍管理
  • 条目名：成绩管理
  • 输入：学生修课名单、课程名称、学生成绩
  • 输出：教学安排、学生成绩通知单、学生修课情况与成绩统计
  • 加工逻辑：1.从学生名册中获取修同一课程的学生名单... 6.进行成绩统计... 7.向学生发出成绩通知...

• 数据词典条目举例：外部项

  • [表格展示]
  • 系统名：学籍管理
  • 条目名：教师
  • 别名：任课教师
  • 输入数据流：教学安排
  • 输出数据流：学生成绩
  • 主要特征：教师，即本系统中为修课学生授课的任课教师...
  • 简要说明：本系统负责下达教师的教学任务...

• 不同领域、不同团队的数据字典

  • 有着不同的项目和格式习惯， 并没有统一的要求。

• 对比：

  • 与数据流图配合的数据字典项目： （1）数据流、（2）数据元素、（3）数据存储、（4）加工、（5）外部项
  • 数据库设计中的数据字典项目： （1）数据项、（2）数据结构、（3）数据流、（4）数据存储、（5）处理过程

• 在UML方法中，也需要数据字典与用例图、类图、活动图等各种图相配合。

5 编码设计

• 信息分类编码优先采用甲方组织原有编码（例如学号），在信息系统规划阶段初步确定，并在后续开发阶段不断调整和补充。

  • [架构图：总体规划 -> 信息分类编码设计 -> (信息系统分析/设计/实施)]

• 信息分类编码设计的目的：

  • 技术层： 提高信息处理的效率和精度，实现信息系统的高效运作。
  • 管理层： 提升管理的规范化水平，加速业务流程，支撑跨部门 / 跨组织协同，保障业务合规。
  • 思考：学号、身份证号的用处？为什么不能用姓名代替？

• 信息分类编码的基本原则：

  • （1）科学性：选择系统中最稳定的本质属性或特征作为分类的基础和依据。
  • （2）系统性：把选定属性的特征值按一定的排列顺序予以系统化，形成一个合理的科学分类体系。
  • （3）可扩展性：分类要具有可拓展的类目，以保证增加新类目时，不致于打乱已建立的分类体系，同时还应为下级系统在本分类体系基础上做细化创造条件。
  • （4）兼容性：分类要与有关标准（包括国际标准、国家标准、行业标准等）协调一致，尽量保持向上的兼容。
  • （5）综合实用性：分类要从系统出发，把全局问题放在系统整体中处理，以达到系统整体最优，同时在满足系统总任务、总要求的前提下，尽量满足系统内各个部分的实际需要。
  • 对于甲方组织已使用的编码，根据上述基本原则进行调整和补充。

• 信息分类的基本方法：

  • 信息分类编码法，先分类，后编码。
  • （1）线分类法
    • 将初始的分类对象（即被划分的事物或概念）按所选定的若干属性或特征（作为分类的划分基础）逐次地分成相应的若干层级的类目，并排成一个有层次的、逐级展开的分类体系 。
  • （2）面分类法
    • 将所选定的分类对象的若干个属性或特征视为若干个“面”，每个“面”中又可以被分成彼此独立的若干个类目，再按一定的顺序将各个“面”平行排列。使用时可根据需要将这些“面”中的类目按指定的顺序组合在一起，形成一个新的复合类目。

• 线分类法：

  • 上位类： 即在线分类体系中，一个类目相对于由它直接划分出来的下一级类目而言，称为上位类。
  • 下位类： 即在线分类体系中，由上位直接划分出来的下一级类目相对于上位类而言，称为下位类。
  • 同位类： 即在线分类体系中，由一个类目直接划分出来的下一级中的各类目，彼此称为同位类。
  • 在该体系中，同位类类目之间存在并列关系；下位类与上位类类目之间存在隶属关系，同位类类目不重复、不交叉。
  • [示例：部门 -> 科 -> 组 (人力资源部 -> 劳资科/培训科 -> 劳资计算/保险/岗前培训等)]

• 线分类法举例：

  • GB2260-86《中华人民共和国行政区划代码》采用的是线分类法，将全国行政区划分为三层，每层用2位数字表达：
    • 第一层为省（自治区、直辖市）
    • 第二层为地区（市、州、盟）
    • 第三层为县（市、旗、镇、区）。
    • 例如130302表示河北省秦皇岛市海港区。

• 线分类法的原则：

  • 在线分类中，由某一上位类划分出来的下位类类目的总范围应与上位类类目相等（除了第一层，不存在没有上位类的类目）；
  • 当某一个上位类类目划分成若干个下位类类目时，应选择一个划分基准（按一种方式分类，例如手机按大小、颜色或型号一种方式分类）
  • 同位类类目之间不交叉、不重复，并只对应于一个上位类
  • 分类要依次进行，不应有空层或加层。

• 线分类法的优点：

  • 层次性好，能较好地反映类目之间的逻辑关系
  • 使用方便，既符合手工处理信息的传统习惯，又便于计算机处理信息

• 线分类法的缺点：

  • 结构弹性较差，分类结构一经确定，不易改动
  • 当分类层次较多时，为其所设计的代码位数会比较大，影响数据处理的效率与速度。

• 面分类法举例：

  • 便于通过学号便掌握学生学院、专业和班级，对“学生”这个待分类对象按其学院、专业和班级属性进行分类。
  • 三个属性作为三个“面”。
  • [表格示例：学院面(计算机01, 管理02...), 专业面(软件工程01, 企业管理04...), 班级面(1, 2, 3...)]

• 区分面分类法和线分类法：

  • 面分类法的一个面中编码不能重复；
  • 线分类法的同位类编码不能重复，而同一层次的非同位类编码可以重复。
  • 举例：
  • 面分类法：
    • 01（计算机学院） 01（软件工程） 01（1班）
    • 02（管理学院） 04（企业管理） 01（1班）
    • 专业全校统一编码，软件工程的编码是01，企业管理的编码是04，所有专业编码不能相同。
  • 线分类法：
    • 01（计算机学院） 01（软件工程） 01（1班）
    • 02（管理学院） 01（企业管理） 01（1班）
    • 专业各学院统一编码，管理学院01号专业是企业管理，计算机学院01号专业软件工程，可以相同

• 面分类法的原则：

  • 根据需要选择分类对象本质的属性或特征作为分类对象的各个面。
  • 不同面内的类目不应相互交叉，也不能重复出现。
  • 每个面有严格的固定位置。面的选择以及位置的确定，根据实际需要而定。

• 面分类法的优点：

  • 具有较大的弹性，一个面内类目改变，不会影响其它的面。易于添加和修改类目。
  • 适应性强，可根据需要组成任何类目，同时也便于计算机处理信息（有的案例没有明确的层次结构，无法用线分类法）。

• 面分类法的缺点：

  • 不能充分利用容量，可组配的类目很多，但有时实际应用的类目不多（有的组合编码存在，但对应的项目实际不存在，例如可以存在编码010401，但不存在计算机学院企业管理专业1班）。
  • 难于手工处理信息（手工检索效率比线分类法低）。

• 编码的功能要求：

  • ①标识功能：代码是分类对象的惟一标志；
  • ②分类功能：当按编码对象的属性或特征分类，并赋予不同的类别代码时，代码可以作为区分对象类别的标志（部分编码重复的代码是一类代码，例如学号以2023开头的都是2023级学生）；
  • ③排序功能：当为编码对象赋予不同代码时，可以按代码进行排序（例如可以通过学号将学生信息按年级排序）；
  • ④特定含义：代码是在一定分类体系下产生的，因此代码可提供一定的含义（帮助人直接从代码获取信息，参考后面介绍的表意码）；
  • 在这些功能中，标识功能是代码的最基本的特性，任何代码都必须具备这种基本特性，同时，代码的其它功能是为满足处理信息或对信息做深加工需要而人为赋予的。

• 代码的种类：

  • 1、顺序码

    • 顺序码是用一组连续的数字代表某一分类类目。
    • 例如，企业或组织中部门的分类代码：00 企业, 01 人力资源部, 02 生产计划部, 03 营销部
    • 优缺点：位数少（每一个编码都有对应项目），便于处理（设计工作简单，可以按时间顺序自动产生）；但弹性差（插入、修改困难）；检索能力差。

  • 2、位别码

    • 位别码是在为分类对象设计固定长度的代码格式前提下，在格式中用不同的位置代表不同的分类类目。
    • 例如：为机构（部门）分类设计6位长度的代码格式，其中第1、2位表示部门级分类，第3、4位表示科级分类，第5、6位表示组级分类。
    • 例如：为学生学号设计10位长度的代码格式，其中第1、2位表示学院，第3、4、5、6位表示专业、第7位表示班级、第8、9、10位表示序号。
    • 优缺点：位数多（存在无对应项目的编码），设计工作较复杂；弹性好；检索能力强。

  • 3、表意码

    • 表意码直接或间接（例如拼音、缩写）用某些文字、数字、记号作为编码。
    • 例如：在商品的规格尺寸分类中，直接使用MT（米）、CM（厘米）、MM（毫米）等表示分类单位。表意码易记忆、易理解、便于识别，因此比较适合描述分类对象的性能、尺寸、重量、容积等分类类目。
    • 例如：车次，K—快速列车，T—特快列车， Z—直达特快列车，D—新时速动车……
    • 优缺点：便于人理解、记忆、检索，辅助人校验，避免人出错。
      • 编码规则复杂，编码容易过长（例如某产品编码PROJECT-2024-IT-RESEARCH-SHANGHAI-003）；
      • 容易产生重码（例如计算机学院、经济学院拼音首字母都为J）；
      • 计算机处理效率较低。

  • 4、校验码：

    • 设置校验码目的——为了保证信息传递的准确性（例如身份证最后一位）。
    • 方法举例：算术级数法。
      • 原代码 1 2 3 4 5
      • 各乘以权 6 5 4 3 2
      • 乘积之和 6+10+12+12+10 = 50
      • 以11为模去除乘积之和，得出的余数：50/11=4余6
      • 因此，加入校验位以后的代码为：123456。
      • 注意：以11为模时，若余数是10，记作X（个别情况下按0处理）。

  • 5、合成码

    • 合成码是把上述几种编码形式合成在一起的组合编码方式。
    • 最常见的方式是将位别码与顺序码组合在一起。
    • 根据需要选择加入表意码或校验码。

  • 实际使用的多数代码是位别码与顺序码的组合，例如：邮政编码，学号，身份证号等。

• 合成码举例：

  • 某企业的部门划分，将位别码与顺序码组合在一起，表达采用线分类法的编码方案。
  • 首先采用位别码，每两位编码分别表示部门、科室、岗位。
  • 同位类使用顺序码（从01依次递增），并使用00表示该同位类的上位类。
  • [代码示例：010000 人力资源部, 010100 劳资科, 010101 劳资计算...]

• 合成码举例：

  • 某校学生的分类编码中，将位别码与顺序码组合在一起，表达采用面分类法的编码方案。
  • 首先为每个“面”定义编码（学院、专业、班级）。
  • 然后再为每位学生制定学号代码。
  • [代码示例：0108011001 (01计算机学院 + 0801软件工程 + 1班 + 001号学生)]

6 数据库逻辑结构设计

• 在系统分析阶段同步完成数据库的逻辑结构设计。
  • 校验码、范式，分解、合并关系，设计视图，得到数据课的关系模型（局部结构和整体结构）。
• [局部结构举例：学号、姓名、年龄、性别、系名、年级等属性组成的表]
• [整体结构举例：多个表之间的关系连线，如专业号->专业名称]

第5章 信息系统的系统设计

• 1 系统设计概述
• 2 架构设计
• 3 详细设计
• 4 辅助设计

1 系统设计概述

• 系统设计是在系统分析的基础上，

  • 将抽象的业务需求转化为可落地、高质量、易维护的技术方案，为系统开发提供指导。

• 系统设计的目的：

  • 1、需求转化： 将业务需求转化为技术可实现的方案。拆解系统整体架构，降低模块间耦合，控制开发与维护复杂度。提前规划系统的非功能需求，保障运行稳定性、安全性、性能等核心质量指标。
  • 2、技术选型： 选择适配业务场景的技术栈，合理规划硬件、软件资源，平衡成本与效率。识别技术风险，验证方案可行性，避免开发阶段出现重大返工。

• 系统设计的主要内容：

  • 1、首先从宏观层面进行架构设计。
    • 对系统规划阶段的方案进行调整和补充，从架构模式、模块划分、技术栈选择和部署架构多个角度定义系统的整体框架，明确各组件的关系与技术选型，是系统设计的 “顶层设计”。
  • 2、其次从微观层面进行详细设计
    • 对总体架构中的 功能、接口、数据和算法多个角度进行精细化设计，直接指导编码实现。
  • 3、最后从多个角度进行辅助设计
    • 为系统的 性能、安全性、可扩展性、可维护性 提供技术支撑，是 容易被忽视但很重要的工作。

2 架构设计

• 1、架构模式选择

  • 确定系统的整体组织形式，适配业务场景与性能需求。
  • 常见模式：
    • B/S（浏览器 / 服务器）
    • C/S（客户端 / 服务器）
    • SOA 架构（面向服务的架构，企业级集成系统）
    • 微服务架构（云ERP，云原生开发）
    • 相关概念参考课程1-2节。
  • 选型依据： 性能需求、维护成本、用户规模和并发量、跨平台需求。

• 各种架构模式的应用案例及特点：

  • 1、B/S 架构——某大学的教学管理系统
    • 优点： 部署成本低、用户适用方便
    • 缺点： 功能受限、性能受限、安全性低（受限于浏览器）
    • 应用情景： 适合大量用户分散办公，对系统性能、安全性要求不高
  • 2、C/S架构——某中型制造企业生产管理信息
    • 优点： 性能、安全性高，界面交互灵活，可定制化程度高（相对于B/S架构）
    • 缺点： 部署、维护成本高（相对于B/S架构），跨平台兼容差，并发性能有限（相对于SOA和微服务）
    • 应用情景： 适合中小规模组织
  • 3、 SOA 架构——某制药集团合规审计MIS
    • 此前企业内部运行着 SAP R3、Oracle BI、Peoplesoft 等多个独立系统，各系统数据不通、交互困难，难以满足食药监部门的审计要求和业务快速调整需求。通过 SOA 架构改造后，系统将各独立系统的功能封装为可复用的服务，通过服务总线实现数据互通与协同。
    • 优点： 服务松耦合，可复用性强；支持异构系统集成；业务扩展灵活，新增功能可通过新增服务实现，无需重构整体系统。
    • 缺点： 系统构造复杂，开发难度大，故障排查困难；服务总线易成为性能瓶颈，高并发下需集群部署。
    • 应用情景： 适合企业级大规模系统，支持跨部门 / 跨地域协同
  • 4、微服务架构——某新能源车制造集团的用友制造业云ERP
    • 借助其微服务拆分能力，将生产计划、设备管理、跨工厂协同等功能拆分为独立业务单元。系统可实时采集深圳、武汉、重庆三地生产基地的设备状态和物料库存数据。
    • 优点： 开发迭代速度快，支持异构技术栈（Java/Go/Python 可混用）（云原生开发支持）；支持弹性伸缩（如双十一订单峰值扩容），故障隔离性好（云计算支持） 。
    • 缺点： 架构复杂、运维成本高；数据一致性难保障。
    • 应用情景： 适合大规模团队，适合新建管理信息系统。

• 2、系统模块划分

  • 系统模块的初步划分：
    • 系统规划阶段，使用UC矩阵，划分子系统；
  • 系统模块的再次划分：
    • 需求分析阶段，业务流程图/UML用例图，从匹配业务角度，划分功能模块；
    • 系统分析阶段，数据流图/ UML类图，模块的合理性和可行性角度，调整功能模块；
    • 系统设计阶段，HIPO图/ UML包图和组件图，从匹配技术角度，调整功能模块。

• HIPO（分层和输入-处理-输出）：

  • HIPO技术是用图形方法表达一个系统的输入和输出功能以及模块层次的方法，包含两个方面的内容：

  • 1、H图（模块层次图）。

    • 表示自顶向下分解所得系统的模块层次结构。

  • 2、IPO图(输入-处理-输出图)。

    • 实际上是一张图形化的表格。它描述分层图中每一个模块的输入输出关系、处理内容、本模块的内部数据和模块间的调用关系。

  • HIOP的应用举例：

    • 应用HIPO技术对一库存管理系统中的数据加工“修改库存数据”进行模块结构设计。
    • [此处需结合PPT中的H图理解：展示了“修改库存数据”模块分解为“提取库房收发数据”、“提取库存数据”、“处理收发数据”等子模块，并进一步细分到第三轮H图，包含“写补充定货记录”、“刷库房存记录”等底层模块]

• UML 包图：

  • 通过文件夹符号组织的模型元素组合，主要用于对关联的用例、类等元素进行分组管理，用于展示软件的逻辑结构，主要有用例包图和类包图。其核心功能包括系统需求与设计的高阶概述、复杂图模块化及源代码组织。
  • 类包图举例：
    • [此处需结合PPT中的类包图理解：展示了“系统数据信息”包包含“项目统计数据库”、“贫困户信息数据库”等，以及不同业务包（如“消息数据库”、“贫困户档案”等）之间的数据流向和依赖关系]

• UML 组件图：

  • 主要用于展示软件系统的物理结构和组件间的组织关系。
  • 在架构设计阶段，组件图用于宏观组件拆分、组件职责边界、跨组件依赖关系。
  • 在后续的详细设计阶段，进一步细化组件图，用于模块内子组件拆分、组件间接口定义。
  • 组件图举例：
    • [此处需结合PPT中的组件图理解：展示了 Account、Order、Product 组件之间的接口调用关系，以及 Order header 与 Line item 的聚合关系]

• 3、技术栈选型

  • 确定开发语言、框架、中间件、数据库等核心技术
  • 主要包括：
    • 开发语言： 例如Java（企业级系统）、Python（数据分析系统）、JavaScript（前端）、C#（桌面应用）。
    • 技术框架： 例如Spring Boot（后端）、Vue/React（前端）、MyBatis（数据访问）。
    • 中间件： 例如Redis（缓存）、RabbitMQ（消息队列）、Elasticsearch（搜索引擎）。
    • 数据库： 例如Oracle Database （关系数据库）、 Oracle Autonomous Data Warehouse （数据仓库）。
  • 选型原则： 技术成熟度（包括各部分技术的兼容性）、团队熟练度、可扩展性、成本预算。

• 4、部署架构设计

  • 规划系统的硬件、网络、部署方式
  • 部署模式： 单机部署（小型系统）、集群部署（私有云，安全）、云部署（公有云，低成本、弹性扩展）；
  • 关键组件： 服务器、数据库服务器、负载均衡器、防火墙、存储设备等。
  • UML中的相关工具：部署图。
  • 在组件图描述系统的组件及其依赖关系基础上，进一步描述系统的部署架构，即组件与节点的对应关系。
  • UML部署图举例：
    • [此处需结合PPT中的部署图理解：展示了 End User Client (Browser) 通过 HTTP 访问外网 Firewall，进入 APP Server（包含设备管理、设备维修保养管理等组件），再通过内网 Firewall 连接到 SQL Server Database 和 File Access Server]

3 详细设计

• 在宏观的架构设计基础上，进行功能、接口、数据和算法方面微观设计。

• 1、功能设计

  • 在前述模块划分的基础上，对模块内部进行设计，确定模块的核心功能。
  • 系统设计阶段的功能设计参考需求分析、系统分析阶段的功能描述、数据字典完成，主要工作在于
  • （1）从功能的业务视角（用户、产品经理）转化为技术视角（开发工程师、数据库工程师）。
  • （2）从功能的粗粒度、宏观化到细粒度、微观化。
  • （3）描述工具的变化：
    • HIPO图在分层的H图基础上，补充IPO图，进行功能描述。
    • UML方法使用组件图，描述模块内的子组件；修改、细化类图，修改、补充类之间的关联关系。

• 软件系统总体结构设计的工具：

  • HIOP的应用举例： 处理收发数据模块的IPO图。
  • 系统名： 库存管理 | 制图者： 白XX
  • 模块名： 处理收发数据 | 日期： 1/5/88
  • 由下列模块调用： 修改库存数据
  • 调用下列模块： 增加在库数、减少在库数、增加记录、删除记录
  • 输入： （由修改库存数据模块提供库房收发数据、库存数据）
  • 输出： （由修改库存数据模块接收）、修改后的库存数据、无效收发数据
  • 处理内容： 如库房收入，则调用增加在库数模块；如库房发出，则调用减少在库数模块；如增加库文件记录，则调用增加记录模块；如删除文件记录，则调用删除记录模块。否则，按无效数据处理。
  • 内部数据元素： [空] | 备注： [空]

• 2、接口设计

  • 接口（Interface）是不同实体（组件、系统、模块、对象）之间交互的桥梁，核心作用是隐藏内部实现，标准化交互规则—— 让交互双方只需关注 “如何通信”，无需关心对方 “内部如何工作”，是降低耦合、实现模块化、跨系统协作的核心技术手段，有利于提高开发速度、质量，降低开发成本，提高系统安全性。
  • 接口类型：
    • （1）内部模块接口：系统内部各功能模块间的协作契约（如采购模块→库存模块） 。
    • （2）外部系统接口：与企业其他系统的集成接口（如ERP（先应用的企业资源计划）→CRM（后应用的客户关系管理））。
    • （3）人机交互接口（UI 接口）：系统与用户的交互入口（前端页面→后端服务）。
    • （4）数据接口：批量数据导入 / 导出、同步接口 数据迁移、报表生成、第三方数据接入
  • 所用工具：HIPO图没有考虑接口问题；UML方法中的组件图、类图都可以描述接口设计。

• 3、数据设计

  • （1）数据分类

    • 根据系统的逻辑功能和主题数据的识别可对数据进行以下分类（重要性由高到低排列） ：
      • 存档类数据——重要、需要长期保存的数据。
      • 事务类数据——处理日常业务记录下的数据，传统上 只有短期保存价值；大数据技术进一步深入挖掘了此类数据的价值，因此很多系统改为长期保留。
      • 计划数据——尚未时间开展而处于计划阶段的业务数据，可能存在多个版本，保留价值相对更低。
      • 统计类数据——主要通过事务类数据加工得到，为了提升查询、分析效率而单独存储，即使不保留也可以通过其它保留数据重新统计获得。
    • 数据分类的主要目的是支持数据持久化设计。
    • 数据持久化（Data Persistence）是指将内存中临时存储的数据保存到外存（如硬盘） 中，使其在程序关闭、系统重启或断电后依然能够保留的技术和过程。

  • （2）数据存储规模的确定

    • 既要考虑现有数据量的存储规模，又要预见到未来数据量的增长趋势，要注意控制数据量的无限制增长。
    • 在以上分析的基础上合理的组织数据的存储格式，应用各种必要的数据压缩技术并选择合适的外部存储设备。

  • （3）数据存储空间的分布

    • 与前面系统总体布局方案中的硬件配置相匹配，即规定什么设备上保存哪些数据。

  • （4）数据库管理系统的选择

    • 在架构设计技术栈选型的基础上，选择具体的数据库产品版本、节点数量等具体配置方案。

  • （5）数据库性能设计和安全性设计

    • 本章第3节介绍。

• 4、算法设计

  • 将需求分析、系统分析阶段的业务逻辑转化为可落地的高效计算方案。

  • 主要步骤：

    • （1）核心目标定义：分解需求，对于子需求逐一明确算法要解决的核心问题
      • 例如计算订单最终支付金额、筛选符合条件的商品等。
    • （2）输入输出定义：明确输入、输出数据的内容、格式和规模。
      • 例如输入：业务数据（如订单金额、优惠券列表、商品类型）
      • 输出：算法结果（如优惠后金额、使用的优惠券）
    • （3）约束条件梳理：明确业务规则限制
      • 例如优惠券使用条件、数据范围约束。
    • （4）问题类型归类:将业务问题映射为经典算法类型
      • 例如排序、查找、动态规划等。
      • 排序、查找类基础算法已经集成在通用组件中。
      • 复杂的优化、数据挖掘算法才需要专家单独设计。

  • 基本原则：

    • （1）业务适配性：算法必须贴合业务场景，优先满足业务规则。
    • （2）高效性：算法时间 / 空间复杂度需适配数据规模。
      • 小规模数据可直接使用组件自带的基础算法；
      • 大规模数据需要专家精选挑选、设计算法保障系统可用性。
    • （3）正确性：算法输出结果必须符合业务预期，无逻辑漏洞。
      • 需要大量测试保障来正确性。
    • （4）稳定性：算法在边界条件（如空数据、异常输入）下无崩溃，输出合理结果。算法运行失败时能够自我检测识别，不输出错误的数据。
    • （5）可扩展性：算法设计需适配未来业务变化。
      • 如新增优惠类型，排序维度增加，数据规模增大等。
    • （6）易实现性：优先选择成熟、易编码的算法，避免过度设计（除非有性能瓶颈）。

4 辅助设计

• 在详细设计基础上，进行非功能性设计，提升系统的性能、安全性、可扩展性、可维护性。

• 1、性能设计

  • 提升系统性能是一个系统工程，需要覆盖架构、数据库、应用、部署多个维度，找到系统性能评价，并采用最有经济性的方案解决。
  • （1）架构层面
    • 分层架构优化：“表现层→业务层→数据访问层→数据层”分层，不同层部署在不同服务器，减少相互干扰。
    • 缓存架构设计：例如使用本地缓存（例如Caffeine）、分布式缓存（例如Redis）、数据库缓存（例如 MySQL 查询缓存）缓存频繁的执行结果，复用计算过程。
    • 异步架构设计：将耗时操作（如报表生成、数据导出）改为异步执行，使用消息队列（例如Kafka）解耦同步流程。
  • （2）数据库层面
    • 对于传统的关系数据库，主要是数据库物理结构设计。
    • 主要工作包括优化查询、建立索引、选择数据的存储硬件与存放位置、修改存储引擎的参数设置等。
    • 对于分布式数据库，可能还要进行分库、分表设计（NoSQL、NewSQL已自动化）。
  • （3）应用层面
    • 主要有代码优化、接口优化、对象序列化优化等。
  • （4）部署层面
    • 主要有服务器硬件选型、服务器参数设置、网络优化等。

• 2、安全性设计

  • （1）业务角度
    • 用户身份认证、基于角色的访问控制、细粒度权限控制（例如只能看本部门的数据）。
  • （2）技术角度
    • 需要综合考虑数据库、应用软件、硬件、网络方面的安全。
    • 能够应对常见的网络攻击。
    • 做好审计、数据备份与恢复工作。
  • （3）管理角度
    • 制定系统开发、使用时的安全规章制度。

• 3、可扩展性设计

  • 主要内容：

    • （1）功能扩展：新增功能时，无需修改原有代码或仅需少量修改。例如某MIS 系统后期新增 “供应商管理”“合同管理” 模块，不影响现有 “采购管理” 功能。
    • （2）容量扩展：系统用户量、数据量增长时，通过增加资源（服务器、存储）提升处理能力。例如某 MIS 用户从 100 人增至 1000 人，通过扩容服务器支撑并发。
    • （3）技术扩展：兼容新的技术栈、第三方服务，避免技术绑定。例如MIS 系统从单体架构迁移到微服务架构，或集成新的支付接口、物流接口。

  • 基本原则：

    • （1）高内聚低耦合：模块内部功能高度相关，模块之间依赖最小化。
    • （2）组件化：将系统功能封装为可复用的组件，新增功能基于组件组合实现。
    • （3）接口标准化：模块间、系统间的交互接口遵循统一标准（如REST），MIS 系统与外部 ERP 系统对接时，采用标准化的 REST 接口，更换 ERP 系统时无需修改接口逻辑。
    • （4）配置化驱动：业务规则、流程逻辑通过配置文件 / 数据库配置实现，而非硬编码。
    • （5）分层设计：严格遵循 “表现层→业务层→数据访问层→数据层” 分层架构，避免跨层调用。

• 3、可维护设计 (注：此处序号应为4，延续PPT原文标注为3)

  • （1）架构层面
    • 高内聚低耦合、组件化、接口标准化等。
    • 策略与可扩展性高度重合。
  • （2）代码层面
    • 松耦合的依赖管理：采用依赖注入（DI） 框架（如 Spring 的 IOC 容器），降低组件间的硬依赖，便于替换实现类和单元测试。
    • 避免硬编码配置：所有配置项（如数据库连接信息、接口地址等）集中存储在配置文件，支持动态修改。
    • 制定编码规范：制定统一的编码规范。编码规范有通用规范（如命名规则、注释规则、代码格式等） 、语言规范（例如Oracle 官方 Java 编码规范）和企业级规范（例如华为编码规范）。
    • 异常处理与日志设计：设计统一的异常处理机制，制定分级日志策略。
  • （3）运维层面
    • 配置集中管理、日常运维自动化、变更流程规范化（尽量自动化，减少人工操作带来的故障）。

第6章 信息系统的实施

• 1 系统实施概述
• 2 软件过程能力成熟度模型
• 3 软件开发模型
• 4 系统测试、部署、培训和切换

1 系统实施概述

• 系统实施
  • 是把系统分析和系统设计的成果转化为可实际运行的系统。
• 广义上的系统实施主要包括以下工作：
  • （1）开发（编程）： 按照详细设计阶段产生的程序设计说明书，用选定的程序设计语言书写源程序。
    • 本节重点介绍软件过程能力成熟度模型和软件开发模型。
  • （2）测试： 运用一定的技术与方法按照一定步骤，发现和排除系统可能存在的问题。
  • （3）部署（安装）： 各种软、硬件设备的选型、论证、购置、安装，以及整个系统调试运行。
  • （4）培训： 确保用户能够熟练操作新系统，是系统顺利推广的前提。
  • （5）切换： 以新开发的系统替换旧的系统，并使之投入使用的过程。

2 软件过程能力成熟度模型

• CMM(Capability Maturity Model)软件过程能力成熟度模型：

  • 起源： 软件管理工作引起广泛注意源于20世纪70年代中期。当时美国国防部曾立题专门研究软件项目做不好的原因，发现70%的项目是因为管理不善而引起的，而并不是因为技术实力不够，进而得出一个结论：管理是影响软件研发项目全局的因素，而技术只影响局部。
  • 出现： 1987年，美国卡内基.梅隆大学软件研究所（SEI）受美国国防部的委托，率先在软件行业从软件过程能力的角度提出了软件过程能力成熟度模型（CMM）。
  • 认证机构： CMM的开发与早期管理均由美国卡内基 - 梅隆大学软件工程研究所（CMU/SEI） 负责。后来，随着业务量增大，又委托给诸多第三方评测机构，如中国软件评测中心（CSTC） 等。

• CMM中的基本概念：

  • 软件过程（Software Process）： 人们用以开发和维护(进化)软件及其相关产品的一系列活动。
  • 软件过程能力（Software Process Capability）： 描述（开发组织或项目组）通过执行其软件过程能够实现预期结果的程度。
  • 软件过程性能（Software Process Performance）： 表示遵循其软件过程所得到的实际结果。
  • 软件过程成熟度（Software Process Maturity）： 指一个特定软件过程被明确和有效地定义、管理、测量和控制，以及产生实际效果的程度。
  • 软件能力成熟度等级： 软件开发团队（或组织、企业）在走向成熟的途中几个具有明确定义的、表征软件过程能力成熟度的平台。
    • 关键域： 对软件开发过程进行有效管理且相互关联的一系列活动的集合，这些活动反映了一个组织对软件开发过程有效改进的关键问题，或者说是达到某个软件能力成熟度等级所必须满足的条件。
      • 关键实践： 对关键域的实施起关键作用的方针、规程措施、活动以及相关基础设施的建立、实施和检查。

• CMM框架（成熟度等级）：

  • 1、初始级： 无规章制度和严格的开发步骤，软件能力等价于个人能力。
  • 2、可重复级： 有规章制度约束
    • 关键域：需求管理、软件项目计划、软件项目跟踪和监控、软件转包合同管理、软件质量保证、软件配置管理。
  • 3、已定义级： 统一的标准、规范
    • 关键域：组织过程定义、组织过程焦点、培训程序、集成软件管理、软件产品工程、组间协调、同级评审。
  • 4、已管理级： 量化管理，可预测
    • 关键域：定量过程管理、软件质量管理。
  • 5、优化级： 基于新概念、技术和方法的持续改进
    • 关键域：缺陷预防、技术改革管理、过程变更管理（即流程重组）

• 信息系统开发阶段与CMM之间的关系：

  • [此处需结合PPT中的流程图理解，CMM1到CMM5逐级递进，覆盖系统规划到运行维护全过程]
  • CMM1（无序）： 对应系统规划、分析、设计、实施等各阶段均无规范。
  • CMM2（有规章制度）： 引入规章制度，对应各阶段有活动和标准。
  • CMM3（有标准规范）： 制度标准化，形成标准规范。
  • CMM4（量化管理）： 基于过程数据库的量化管理。
  • CMM5（持续改进）： 基于先进的管理理念、技术和方法的持续改进。

• CMM与ISO9000：

  • CMM是专门针对软件产品开发和服务的，而ISO9000涉及的范围则相当宽
  • CMM强调软件开发过程的成熟度，即过程的不断改进和提高。而ISO9000则强调可接受的质量体系的最低标准。

• CMM的局限性：

  • CMM标准并不意味着高品质工程，并不意味着最高水平的组织，并不意味着生产效率最高，其标准本身与项目的品质没有直接的关系
  • CMM只是一种形式测试：它不检测程序的内容，只是检测程序的形式。它是大型项目开发的必要条件，而不是品质高的充分条件。
  • CMM 仅提出能力标准，却未解决企业如何落地这些能力的问题。
  • 实际推广时，很多企业把 CMM 认证当作拿订单、享政策补贴的 “敲门砖”，而非真正用于优化开发流程。
  • 部分企业实施后软件开发效率和质量无明显提升，甚至出现项目周期加长的情况。

• CMM在我国的应用的发展：

  • 2000 年左右 CMM 刚引入中国时，曾因明确了软件开发团队的基础能力标准而受到关注，短期内有数百企业通过 CMM 2 级、3 级评估。
  • CMM 最初仅针对纯软件开发设计，存在覆盖领域窄、改进路径单一等问题。而 2000 年初期推出的 CMMI 作为其升级版，整合了系统工程、集成产品开发等多个领域的模型，还提供阶段式和连续式双改进路径，能灵活适配软硬件集成、服务管理等多场景需求。
  • 2002 年 CMMI 正式引入中国后，迅速成为市场主流。到 2015 年，中国的 CMMI 评估数量就已跃居全球第一，广泛应用于 IT、金融、航空航天等多个领域，原本少量使用 CMM 的企业也纷纷转向 CMMI。
  • 2021 年国内发布了自主的软件能力成熟度评估标准 CSMM，该标准被称为 “中国版 CMMI”，更贴合国内政务、央国企、金融等领域的本土实践与合规要求，还能保障数据与敏感信息可控。对于以国内客户为主的软件开发企业，CSMM 成为了更优选择。

3 软件开发模型

• 软件开发模型（Software Development Model）

  • 是一套结构化的框架、流程和方法论，它定义了软件开发全过程的阶段划分、活动顺序、任务分工、里程碑节点和质量管控方式，用于指导团队从需求分析到系统维护的全生命周期工作。
  • 简单来说，软件开发模型就是软件开发的 “路线图”，它明确了 “先做什么、再做什么、如何做、如何验证”，让开发过程从无序的作坊式工作，变成可规划、可监控、可追溯的标准化流程。

• 应用软件开发模型的意义：

  • （1）规范开发流程，降低管理成本
  • （2）控制项目风险，提升交付成功率
  • （3）保障软件质量，减少缺陷率
  • （4）适配不同项目场景，提高灵活性
  • （5）优化团队协作，提升开发效率

• 软件开发模型与管理信息系统开发方法（1-3节）：

  • 前者管理编程（软件开发）活动，后者管理信息系统分析、设计与开发的全过程，两者存在关联。

• 经典的软件开发模型：

  • 结构化系统开发方法思路：

    • （1）瀑布模型：严格线性分阶段推进，阶段依次衔接，文档驱动，上一阶段完成才进入下一阶段。
    • （2）V 模型：瀑布模型的扩展，开发阶段与测试阶段严格对应，形成 “V” 型验证链，强调各阶段的验证环节。

  • ①瀑布模型

    • [此处需结合PPT中的瀑布模型图理解，展示了制定计划->需求分析->软件设计->程序编写->软件测试->运行维护的线性流程]
    • 阶段具有顺序性和依赖性：
      • 前一阶段完成后，才能开始后一阶段；
      • 前一阶段的输出文本为后一阶段的输入文本
    • 每个阶段都坚持：
      • 1. 每个阶段都必须完成每个阶段规定的文档。
      • 2. 每个阶段结束前都要对所完成的文档进行评审，以便于尽早发现问题，改正错误。
    • 优点： 结构清晰，易于管理，沟通成本低；文档齐全，有利于交接和复盘。
    • 缺点： 灵活度差，不利于设计变更；测试滞后，易积累问题；后续阶段用户参与度低，易导致交付偏差。
    • 适用场景： 需求明确且稳定、变更极少的项目，如政府合规系统、银行核心交易系统、传统嵌入式控制系统、军工及航空航天等对流程和可靠性要求严苛的软件项目。

  • V 模型：

    • [此处需结合PPT中的V模型图理解，左侧为开发过程，右侧为测试过程，两者一一对应]
    • 核心优化： 将开发阶段与测试阶段一一对应，构建 “V” 型验证链，把测试活动前置到开发初期。
    • 优点： 测试提前，能够早发现问题并处理；其余与瀑布模型一样。
    • 缺点： 只解决了测试滞后问题，瀑布模型的其它缺点依然存在。
    • 适用场景： 与瀑布模型一致。

  • 原型法思路

    • （3）进化模型：快速构建简化原型供用户试用，通过用户反馈逐步明确需求，分抛弃型和演进型。
    • （4）增量模型：将系统拆分为多个独立增量模块，按优先级分阶段开发并交付，每个阶段交付可运行的功能子集。
    • （5）净室模型：形式化增量开发，强调在分析设计阶段就消除错误，以无缺陷状态实现软件制作。
    • （6）迭代模型：划分多个迭代周期，每个周期均包含完整的分析、设计、编码、测试流程，逐步完善产品功能。
    • （7）螺旋模型：以迭代为基础，每轮螺旋周期均包含计划、风险分析、开发、评审环节，风险驱动流程推进。

  • 进化模型：

    • 核心特点： 以快速构建可运行原型为核心，通过用户迭代反馈逐步完善需求与功能，需求模糊阶段即可启动开发。
    • [此处需结合PPT中的流程图理解：识别基本需求 -> 开发工作模型 -> 模型验证 -> 修正和改进(循环) -> 原型完成 -> 整理原型提供文档]
    • 优点： 灵活度强，用户深度参与，需求验证高效，降低最终产品与需求不符的风险，用户满意度高。
    • 缺点： 易陷入 “无限迭代” 误区，若管控不当会造成成本失控。产品容易过早定型，后期优化难度大；轻文档特性影响团队交接与长期维护。
    • 适用场景： 需求模糊、创新性强或用户体验要求高的项目，如新型 APP 交互设计、政企定制化系统前期需求探索、产品创新试点项目、市场验证类 开发等。

  • 原型法类模型的对比：

    • 进化模型： 70年代出现，以快速原型为核心，通过用户反馈迭代完善原型，最终演化成产品。侧重需求探索，适合需求完全模糊的场景。
    • 增量模型： 70年代末出现，按功能优先级拆分模块，分批次开发交付，每个增量都是可独立运行的子集。侧重分阶段交付，先上线核心功能，适配资源紧张或需快速见成效的项目。
    • 净室模型： 80年代中期由IBM提出，形式化增量开发，侧重于打造高质量软件。
    • 迭代模型： 80年代出现，按固定周期迭代，每轮完成 “分析 - 设计 - 编码 - 测试” 全流程（融合了瀑布模型），逐步细化功能。侧重功能完善，每轮迭代产出更完整的版本。
    • 螺旋模型： 1988 年由 Barry Boehm 正式提出，是迭代模型的升级版，加入风险管控核心环节，每轮螺旋包含 “计划 - 风险评估 - 开发 - 评审”。侧重风险管控，适配高复杂度、高风险项目。

  • 面向对象方法思路：

    • （8）喷泉模型：面向对象开发，各开发阶段无缝重叠，分析、设计、编码环节循环迭代推进。
    • [此处需结合PPT中的喷泉模型图理解，展示了各个阶段如同喷泉一般重叠和循环]

  • 喷泉模型（面向对象方法思路）与迭代模型（原型法思路）对比：

    • 喷泉模型： 强依赖面向对象技术，适配对象模型的构建与复用。面向对象开发，各阶段（分析、设计、编码）无缝重叠、循环渗透，像喷泉一样持续迭代细化。
    • 迭代模型： 无固定适配技术，将开发拆分为固定周期迭代，每轮完成 “分析 - 设计 - 编码 - 测试”完整闭环。

  • 喷泉模型：

    • 优点： 阶段衔接无间隙，分析、设计同步推进，能快速响应需求细化。契合面向对象 “抽象 - 封装 - 继承” 特性，提升代码复用率。
    • 缺点： 对项目管理和团队协作能力要求高；反复迭代，代码维护难度大；依赖代码重用，不利于创新。
    • 适用场景： 需求逐步明确（开始阶段模糊）、采用面向对象技术的复杂项目，例如大型游戏引擎开发、企业级分布式系统、复杂仿真软件、人工智能算法落地项目等。

  • 同类模型：

    • （9）RUP（Rational Unified Process，统一软件开发过程）：IBM公司提出的方法，以用例驱动、架构为中心，分初始、细化、构建、移交 4 个阶段，每个阶段包含多次迭代。
    • （10）增量迭代模型（面向对象版）：将系统拆分为功能增量，每轮迭代完成一个增量的分析、设计、编码、测试。

• 后续出现的软件开发模型/方法：

  • 敏捷开发思路：

    • 20 世纪 90 年代，传统开发模型流程僵化、文档冗余，难以适配互联网时代需求快速变更的场景。大量项目因需求滞后、返工频繁导致延期或失败，行业亟需灵活高效的开发方法论，迭代模型、瀑布模型等继续进化，最终形成敏捷体系。

    • 2001 年，17 位软件开发者在犹他州聚会，共同签署《敏捷软件开发宣言》，标志敏捷开发正式诞生。

    • 核心特点：

      • （1）价值导向：优先响应变化而非遵循计划，提升客户满意度，避免“无限迭代”，降低成本。
      • （2）迭代交付：以 1-4 周的短周期（冲刺）迭代开发，每次交付最小可用产品，快速获取用户反馈。
      • （3）团队自组织：弱化层级管理，团队自主分工协作。
      • （4）持续优化：通过回顾会议总结问题，持续改进流程，适配业务动态调整。

    • （11）敏捷统一过程（AUP）： RUP 的轻量化版本，保留 4 个核心阶段，缩短迭代周期，弱化文档，强调快速交付。

    • （12）Scrum：敏捷开发的典型实现模型，以 2 - 4 周的 “冲刺” 为周期，通过产品待办列表、每日站会等机制推进开发。适合互联网产品等需求频繁变化的场景，比如短视频 APP 的功能迭代，能快速响应市场热点调整开发内容。

    • （13）Kanban（看板）：通过可视化看板呈现 “待办 - 进行中 - 已完成” 等任务状态，限制在制品数量提升流程效率。常用在团队协作场景中，借助 Jira 等工具，让研发、测试、产品等角色清晰了解任务进度，适配多角色协同的开发需求。

    • （14）DevOps：

      • Development和Operations的组合词，是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
      • 它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运维工作必须紧密合作。
      • 尽管有的学者认为这是老生长谈，但在2015年后随着大数据开发的增多，这个概念得到越来越多大型公司的重视。
      • 这是软件开发行业从“分工”向“集成”转变的一个标识。

• 软件开发的其它发展趋势：

  • （17）低代码/无代码开发

    • 参与开发人员增多，同时还出现了大量非专业人员增多，通用开发工具的使用难度变得越来越简单。
    • 2010年，Yahoo!研发的类SQL语言为复杂的海量数据并行计算提供了一个简单的操作和编程接口，命名为Pig。
    • 2017年，“胶水语言”Python成为最受欢迎的开发语言。
    • 2019年，Google推出了完全图形化的开发工具iVX。

  • （18）AI编程

    • 以大语言模型（LLM）、代码生成模型（如 GitHub Copilot、CodeLlama）为工具，通过自然语言指令生成、优化代码，辅助或部分替代人工编码，属于人机协同的开发模式。
    • 优点：
      • 提效降本：快速生成重复性代码，减少人工编码时间。
      • 辅助优化：自动检测代码漏洞、优化冗余逻辑，提升代码规范性和可读性。
      • 降低门槛：非专业开发者可通过自然语言生成简单应用，缩短技术与业务的鸿沟。
      • 拓展思路：为复杂算法、冷门语法提供参考方案，帮助开发者突破思维局限，快速验证技术可行性。
    • 缺点：
      • 质量风险：生成代码可能存在逻辑漏洞、性能隐患或不符合业务场景，需人工深度校验。
      • 依赖语境：指令描述模糊时，易生成偏离需求的代码，对提示词撰写能力要求高。
      • 版权与安全：生成代码可能包含开源协议冲突内容，或泄露训练数据中的敏感信息。
      • 弱化基础：过度依赖 AI 易导致开发者代码能力退化，难以独立解决复杂架构问题。
    • 适用场景：
      • 适用重复性编码任务（如 CRUD 接口、测试用例编写）、原型快速验证、冷门语法查询、低代码 / 无代码开发、新手入门辅助；
      • 不适用于高安全要求的核心系统（如金融交易、航天软件）及需深度架构设计的复杂项目。

  • AI编程出现bug的典型案例：

    • 案例1：电商订单金额计算功能AI 生成的代码仅处理了正常金额（正数）的计算逻辑，未校验 “金额为 0”“负数金额” 等边界场景。实际上线后，用户提交 0 元订单时，系统触发空指针异常，导致订单流程卡死。
      • 原因：AI 仅复刻通用代码模板，未结合业务场景补充边界校验规则。
    • 案例2：金融系统利率计算某银行系统需按 “年化利率 ÷12” 计算月利率，AI 却生成了 “年化利率 ×12” 的代码。上线后导致用户月供计算错误，涉及上千笔贷款订单，需紧急回滚并修正。
      • 原因： AI 对专业业务术语（如 “年化利率”）的理解仅停留在字面，未匹配行业通用规则。
    • 结论：AI 生成代码依赖训练数据的通用性，缺乏对具体业务场景、安全规范、边界条件的深度理解，且无法主动校验 “代码是否符合实际业务目标”。因此，AI 生成的代码必须经人工复审、单元测试、业务场景验证后，才能投入使用。

4 系统测试、部署、培训和切换

• 系统测试：

  • 是贯穿信息系统全生命周期的质量保障活动，核心目标是提前发现并修复缺陷（参考V模型），确保系统符合需求规格、稳定可靠运行。其覆盖需求分析、设计、开发、维护各阶段，包含需求测试、单元测试、集成测试、功能测试、性能 / 安全测试、回归测试等类型，需协同开发、产品、业务多方角色，是保障系统质量的核心环节。

• 测试用例：

  • 是测试工作的核心执行依据，是为验证某一功能或特性而设计的标准化文档，包含前置条件、输入数据、操作步骤、预期结果四大核心要素，同时需覆盖正常场景、边界值、异常场景（如空值、非法输入）。

• 测试用例的准备工作贯穿信息系统开发的多个阶段，并非集中在单一阶段，而是分层次、分批次逐步完善。

  • （1）需求分析阶段：测试用例的雏形构建
    • 基于需求规格说明书和验收标准，梳理测试大纲和核心测试场景，确定测试范围、测试类型（功能 / 性能 / 安全等），明确每个需求对应的验证点，编写测试计划和用例框架。
  • （2）系统分析、设计阶段：测试用例的细化设计
    • 结合系统架构、模块设计、接口定义等文档，将需求阶段的测试场景拆解为具体的测试用例初稿。重点补充用例的前置条件、输入数据、预期结果、操作步骤。
  • （3）开发阶段：测试用例的完善与评审
    • 在单元测试、集成测试启动前，完成测试用例的最终定稿和评审。
  • （4）系统维护阶段：测试用例的迭代更新
    • 系统上线后，针对版本迭代、bug 修复、功能新增等场景，补充和修订测试用例，尤其是回归测试用例库的维护，确保每次系统变更都能通过复用和更新用例完成全面验证。

• 系统部署是将开发完成的系统从测试环境迁移至生产环境，实现稳定上线与交付使用的关键环节，主要包含 4 个核心步骤。

  • （1）部署前准备：完成环境搭建，配置生产服务器、数据库、网络等基础设施，与测试环境隔离；同步做好数据迁移规划，确保历史数据完整无丢失；制定部署方案、回滚预案及应急预案，组织团队培训并明确分工。
  • （2）环境与数据迁移：部署系统程序包，配置系统参数、权限及接口；执行数据迁移，完成历史数据清洗、转换与导入；开展基础功能验证，检查系统启动状态、数据准确性及接口连通性。
  • （3）上线验证与试运行：进行冒烟测试（Smoke Test，快速基础轻量测试） ，快速校验核心业务流程；启动试运行，模拟真实业务场景；收集用户反馈，及时修复试运行中暴露的问题。
  • （4）正式上线与交付：切换域名或路由，将用户流量导入生产系统；持续监控系统运行指标（如响应时间、吞吐量）；输出部署报告，完成文档交付，组织用户培训，移交运维团队负责后续管理。
  • 云原生的优势：快速部署、降低部署风险、可实现停机交付。

• 系统培训是确保系统上线后用户能熟练使用、发挥业务价值的关键环节，核心目标是降低用户使用门槛、提升系统应用效率、减少操作失误。

  • 工作要点：
    • 一是分层定位培训对象，按角色划分为 “管理员（负责系统配置与维护）、核心用户（部门业务骨干）、普通用户（日常操作群体）”，避免 “一刀切” 式培训；
    • 二是梳理培训内容，结合系统功能与业务场景，以注重“理论 + 实操” 结合。提炼各角色高频操作（如普通用户侧重数据录入、查询，管理员侧重权限分配、日志管理），摒弃冗余技术细节。

• 系统切换：

  • （1）直接切换

    • 在老系统停止运行的某一时刻，新系统立即开始运行。
    • 缺点： <1>中间没有过渡过程，不够安全。<2>有可能会造成系统的暂时停止运行。
    • 适用： 通常仅用于简单的小规模系统。
    • [此处需结合PPT中的直接切换示意图理解]

  • （2）并行切换

    • 新老系统并行工作一段时间，经过一段时间的考验以后，以新系统正式全面代替老系统。
    • 缺点： <1>需要耗费额外的人力和设备资源。<2>可能会出现新旧系统指示不一致的现象。需要提前规定主次。
    • 适用： 安全性较高，是中等规模系统经常采用的一种方式。
    • [此处需结合PPT中的并行切换示意图理解]

  • （3）分段切换（试点切换）

    • 在新系统全部正式运行之前，分阶段一部分一部分地替代老系统。
    • 缺点： <1>局部仍然存在直接转换的缺点，但影响较小。<2>新旧系统数据交换不方便。<3>旧系统可能影响新系统运行的效率和部分功能，过渡期难以发挥新系统的优势。
    • 适用： 适合大规模系统切换。
    • [此处需结合PPT中的分段切换示意图理解]