Appearance
信息化与信息系统：生命周期 · 开发方法 · 软件工程 · CMM/CMMI
本页导读：本页讲"信息系统本身"——它的一生怎么度过（生命周期）、用什么方法把它建出来（开发方法与生命周期模型）、建造过程中的工程规范（软件工程与测试），以及衡量组织研发管理成熟度的尺子（CMM/CMMI）。这页概念密度大、辨析题多，是综合知识的传统得分区。
一、从数据到智慧：先把名词分清
| 名词 | 含义 | 例子 |
|---|---|---|
| 数据 | 对客观事物的原始记录 | "37.2" |
| 信息 | 被组织、有语境的数据 | "病人张三体温 37.2℃" |
| 知识 | 从信息中提炼的规律 | "低热且咳嗽，疑似上呼吸道感染" |
| 智慧 | 运用知识决策的能力 | "结合病史决定居家观察还是就诊" |
信息化就是把信息作为关键资源，用 IT 改造业务和管理的过程。
二、信息化大背景（概念题背景板）
| 概念 | 一句话 |
|---|---|
| 两化融合 | 信息化与工业化深度融合 |
| 数字中国 | 数字政府、数字经济、数字社会、数字生态的整体布局 |
| 数据要素 | 数据列为生产要素，参与分配 |
| 新基建 | 5G、数据中心、人工智能等新型基础设施 |
| 数字化转型 | 利用数字技术重塑业务模式与运营方式 |
这组名词常出现在综合知识题干里当"帽子"，读懂即可。
三、信息系统的一生：生命周期（高频考点）
四阶段总框架
| 阶段 | 主要工作 | 产出 |
|---|---|---|
| 立项（规划） | 可行性研究、需求初步调研，决定"建不建" | 可行性研究报告、立项报告 |
| 开发 | 系统分析、设计、实施、测试，把系统建出来 | 需求规格说明书、设计文档、可运行系统 |
| 运维 | 持续运行、维护、优化、小规模升级 | 运维记录、变更单 |
| 消亡 | 功能不再满足，改造、替换或退役 | 消亡方案、数据迁移/归档方案 |
开发阶段内部再细分（总-分结构要记牢）：
| 环节 | 干什么 |
|---|---|
| 总体规划 | 明确系统边界、总体架构与分期计划 |
| 系统分析 | 搞清楚"要做什么"（逻辑模型，如数据流图） |
| 系统设计 | 搞清楚"怎么做"（物理模型：概要设计 + 详细设计） |
| 系统实施 | 编码、测试、数据准备、试运行 |
| 系统验收/评价 | 正式验收、上线转换、后评价 |
考点提示："可行性研究属于哪个阶段？"——立项阶段。"数据流图（DFD）是哪个环节的产出？"——系统分析。生命周期类选择题爱考"某活动属于哪一阶段"。
四、怎么建：开发方法对比
| 方法 | 核心思想 | 优点 | 缺点 | 适用 |
|---|---|---|---|---|
| 结构化方法 | 自顶向下、逐步分解、阶段清晰 | 逻辑严密、文档规范 | 周期长、难应对需求变化 | 需求稳定的数据处理类系统 |
| 原型法 | 先快速做个"样机"给用户看，再迭代完善 | 需求表达直观、用户参与早 | 系统性差，易"炒剩饭" | 需求不明确的小型系统 |
| 面向对象（OO） | 以对象为中心，封装、继承、多态 | 复用性好、贴近现实 | 需要OO思维与工具（UML） | 复杂系统、长期演进系统 |
| 敏捷方法 | 小步快跑、拥抱变化、持续交付 | 响应变化快、交付节奏稳 | 文档少、对团队自组织要求高 | 需求多变的互联网类项目 |
| 面向服务（SOA） | 把功能封装成服务，松耦合编排 | 复用与集成能力强 | 治理复杂 | 企业级集成、遗留系统整合 |
OO 三大特性必背：封装、继承、多态；UML 是面向对象的标准建模语言（用例图、类图、顺序图、状态图、活动图等）。
五、生命周期模型对比（与开发方法区分开）
考题常把"模型"和"方法"混在一起考，先立规矩：模型 = 阶段怎么排；方法 = 每阶段怎么干。
| 模型 | 特点 | 风险/适用 |
|---|---|---|
| 瀑布模型 | 阶段线性推进，前一阶段完才进下一阶段 | 需求明确且稳定；需求一变代价大 |
| V 模型 | 瀑布 + 测试左移：每阶段对应一种测试 | 强调验证；同样不适应变化 |
| 增量模型 | 分批交付可用构件，"先主后辅"滚动发布 | 早出成果；需要良好架构规划 |
| 螺旋模型 | 每轮循环都做风险分析 | 大型复杂高风险项目；成本高 |
| 原型模型 | 用原型明确需求后再正式开发 | 需求模糊场景 |
| 迭代模型 | 每轮迭代产出可评价的半成品逐步精化 | 与增量常放一起辨析 |
| 敏捷（Scrum/XP） | 短迭代、持续反馈、拥抱变化 | 需求多变、小型自组织团队 |
高频辨析："强调风险分析的是哪个模型？"——螺旋模型。"需求明确、阶段界限清晰"——瀑布。"快速交付可运行的小版本"——增量/敏捷。
六、软件工程基础
需求
- 需求层次：业务需求 → 用户需求 → 系统需求（功能需求 + 非功能需求）
- 非功能需求：性能、可靠性、易用性、安全性、可维护性等
- 产出物：需求规格说明书（SRS），是后续设计、测试、验收的基准
设计
| 阶段 | 任务 |
|---|---|
| 概要设计 | 系统架构、模块划分、接口定义 |
| 详细设计 | 模块内部算法与数据结构，接近可直接编码 |
测试（高频考点密集区）
| 分类角度 | 内容 |
|---|---|
| 按阶段 | 单元测试 → 集成测试 → 系统测试 → 验收测试（顺序必背） |
| 按方法 | 黑盒（功能视角：等价类、边界值）；白盒（结构视角：语句/判定/条件/路径覆盖） |
| 特殊测试 | α 测试：开发方场所、用户参与；β 测试：用户真实环境；回归测试：改完再验；第三方测试：独立机构 |
α/β 辨析口诀：α 在家测、β 出门测。
维护
| 类型 | 干什么 | 占比感受 |
|---|---|---|
| 纠正性维护 | 修 bug | 有 |
| 适应性维护 | 适应环境变化（系统升级、政策变化） | 有 |
| 完善性维护 | 按用户建议增强功能体验 | 最多 |
| 预防性维护 | 提前改造，防患未然 | 最少 |
软件质量
- 质量模型分功能性、可靠性、易用性、效率、维护性、可移植性等特性
- 质量保证（QA，过程导向）与质量控制/测试（QC，产品导向）要分清
七、CMM 与 CMMI（经典必背）
两把尺子长得像，二级四级名字不同，是软考最爱挖的坑：
| 级别 | CMM（软件能力成熟度模型） | CMMI（能力成熟度模型集成） |
|---|---|---|
| 1 级 | 初始级 | 初始级 |
| 2 级 | 可重复级 | 已管理级 |
| 3 级 | 已定义级 | 已定义级 |
| 4 级 | 已管理级 | 量化管理级 |
| 5 级 | 优化级 | 优化级 |
记忆抓手：
- CMM L2 叫"可重复"（重复以前的成功项目）
- CMMI L4 叫"量化"（用数据说话）
- 1 级都"随缘"（英雄主义、结果不可预期），5 级都"持续优化"
CMMI 表述方式有两种：阶段式（上面的 1~5 级）与连续式（能力等级，按过程域打分），选择题偶尔涉及。
八、常考辨析汇总
| 易混点 | 一句话区分 |
|---|---|
| 开发方法 vs 生命周期模型 | 怎么干 vs 阶段怎么排 |
| 结构化 vs 面向对象 | 以功能过程为中心 vs 以对象为中心 |
| 瀑布 vs 螺旋 | 螺旋多了每轮风险分析 |
| 增量 vs 迭代 | 增量按功能切块交付，迭代整体逐步精化 |
| 黑盒 vs 白盒 | 看功能 vs 看代码结构 |
| α 测试 vs β 测试 | 开发方场所 vs 用户环境 |
| 完善性 vs 适应性维护 | 主动优化 vs 被动适配 |
| CMM L2 vs CMMI L2 | 可重复级 vs 已管理级 |
| 系统分析 vs 系统设计 | 做什么（逻辑） vs 怎么做（物理） |
| QA vs 测试 | 管过程 vs 查产品 |
九、论文里怎么用
- 项目章程/计划里写"本项目采用增量模型分三期交付"——体现方法论意识
- 质量管理段落写"严格执行单元、集成、系统、验收四级测试，上线后建立完善性维护机制"——术语准确加分
- 组织背景写"公司通过 CMMI 3 级评估"——常见且可信的设定
小结
- 生命周期四阶段（立项、开发、运维、消亡）+ 开发环节五步是骨架
- 开发方法五类、生命周期模型七种，抓"一模型一关键词"
- 测试顺序、维护四类型、CMM/CMMI 级别名称是送分点，一分都不该丢
下一页：IT 治理与 IT 审计 →