第7章：嵌入式系统的项目开发与维护知识
软考视角：这一章是"软件工程 + 项目管理"的大杂烩，上午题爱考过程模型、CMM 等级、内聚耦合排序、质量特性、维护分类占比；下午案例分析题爱考 DFD 补数据流、UML 图填空、设计模式识别、Gantt/PERT 图分析。知识点多而散，是性价比很高的一章——背熟了就是送分。
本章在讲什么
写一个嵌入式系统，不只是写代码的事。从"为什么要做这个系统"开始，到需求分析、设计、编码、测试、运行维护，整个过程怎么组织、怎么管理、怎么保证质量，就是本章的内容。可以把它拆成几条线：
- 过程线：系统生存周期的八个阶段，以及把阶段组织起来的各种过程模型（瀑布、原型、螺旋、敏捷……）。
- 管理线：项目管理（4P）、成本估算、进度管理（Gantt/PERT）、风险管理、质量管理（CMM/CMMI、质量模型）。
- 技术线：结构化分析（DFD）、结构化设计（内聚/耦合）、软硬件协同设计、面向对象（UML、设计模式）。
- 收尾线：系统实施与测试、调试方法、系统维护、系统评价。
核心概念拆解
1. 系统生存周期：八个阶段
按时间顺序：问题定义 → 可行性研究 → 需求分析 → 总体设计 → 详细设计 → 实现和单元测试（编码）→ 综合测试 → 运行维护。
理解要点：
- 问题定义回答"要解决什么问题"；可行性研究从技术、经济、操作（社会）等角度回答"值不值得做、能不能做"。
- 需求分析产出的核心文档是需求规格说明书，它是后续一切工作的依据，也是验收的标准。
- 总体设计（概要设计）定"怎么划分模块、模块间怎么连接"；详细设计定"每个模块内部怎么做"（算法、数据结构）。
- 综合测试又称集成测试/系统测试阶段，包含组装、确认、系统测试和验收测试。
2. 过程模型：把阶段串起来的方式
- 瀑布模型：线性顺序、阶段分明，文档驱动。缺点是"直到项目后期才能看到结果"，不适合需求模糊的项目。好处是容易管理、每个阶段有明确的产出。
- V 模型：瀑布的"镜像加强版"，强调测试与开发阶段的对应关系——单元测试对详细设计、集成测试对概要设计、系统测试对需求分析、验收测试对用户需求。软考喜欢考"V 模型左边是什么、右边对应什么测试"。
- 增量模型：把系统分成多个构件（增量）逐个开发交付，第一个增量往往是核心产品。优点是能较早交付可用部分，用户可以及早反馈。
- 原型模型：先做一个"速成品"让用户看，澄清需求。原型分三类：
- 探索型：弄清需求；
- 实验型：验证方案可行性；
- 演化型：原型逐步演化成最终产品。
- 注意：抛弃型原型做完就扔，演化型原型会长大成产品。
- 螺旋模型：瀑布 + 原型 + 风险分析的迭代。每一圈四个步骤：制定计划（确定目标、方案和约束）→ 风险分析 → 实施工程（开发验证）→ 客户评估（评审、进入下一圈）。特点是加入了风险分析，适合大型复杂、高风险项目；缺点是要求有风险分析的经验，用不好反而更糟。
- 喷泉模型：面向对象开发常用，各阶段无明确界限、可以重叠迭代，像喷泉一样"水喷上去又落回来"，强调无缝与迭代。
- 形式化方法模型：用数学化的形式化规格说明来描述系统，严谨但门槛高，应用不广。
- 统一过程（UP/RUP）：用例驱动、以体系结构为中心、迭代增量。五个阶段：起始（初始）、精化（细化）、构建、移交（转换）、生产。
- 敏捷方法：拥抱变化、强调人与沟通、可工作的软件高于详尽的文档。典型代表：
- XP（极限编程）：4 大价值观（沟通、简单、反馈、勇气）、5 条原则、12 个最佳实践（结对编程、测试驱动、持续集成、重构、小型发布、规划游戏、集体代码所有制等）。
- 水晶方法（Crystal）：比 XP 更"以人为本"，强调人员的交流与灵活性，纪律性弱一些。
- Scrum：把工作切成固定长度的"冲刺（Sprint）"，通常 30 天一个冲刺，有每日站会、产品待办列表、冲刺评审。
- ASD（自适应软件开发）：猜测→协作→学习，靠自适应应对变化。
记忆技巧：需求明确、技术成熟选瀑布/增量；需求模糊选原型；高风险大型项目选螺旋；面向对象、迭代多选喷泉/UP；小团队快节奏选敏捷。
3. CMM 与 CMMI
- CMM（能力成熟度模型）五级：
- 初始级——过程混乱，靠英雄救火；
- 可重复级——有基本项目管理，能复用以往经验；
- 已定义级——过程被文档化、标准化（组织标准过程）；
- 已管理级——过程和产品都被定量测量和控制；
- 优化级——持续过程改进。 从第 2 级开始每个级别都有若干关键过程域（KPA）。
- CMMI 是 CMM 的升级整合版，有两种表示法：阶段式（同样 5 个成熟度等级）和连续式（按过程域给出能力等级 CL0 不完整～CL5 优化中）。
软考常给一句描述问"这家企业处于第几级"，抓住关键词：混乱无章=初始；能重复以前的项目=可重复；有标准文档=已定义；有定量数据=已管理；持续改进=优化。
4. 软件工具
- 开发工具：需求分析工具、设计工具、编码/排错工具、测试工具（静态/动态）。
- 维护工具：版本控制（配置管理）、文档分析、开发信息库、逆向工程/再工程工具。
- 管理支持工具：项目管理工具、配置管理工具、评价工具。
逆向工程是"从代码恢复设计/需求"，再工程是"逆向 + 重构 + 正向"，两者区分是常考点。
5. 项目管理：4P 与成本估算
- 项目管理四要素 4P：People（人员）、Problem（问题）、Process（过程）、Project（项目）。
- 成本估算方法：
- 按思路分：自顶向下（先估总再拆）、自底向上（先估模块再汇总）、差别估算（参照类似已完成的 项目调整）。
- 按手段分：专家判断、类推、算式（模型）估算。
- COCOMO 模型：以代码行数（KLOC）为自变量的经验模型，分基本型/中级/详细型三个层次。
- Putnam（普特南）模型：基于"人力曲线"（Rayleigh 曲线）的动态多变量模型，衍生出 SLIM 估算工具。
- 进度图：
- Gantt（甘特）图：横轴时间、条形表示任务，直观展示任务起止和进度；缺点是不能清晰反映任务间的依赖关系。
- PERT 图：网络图，能反映任务依赖与并行关系，标出松弛时间（时差）；松弛时间为 0 的路径就是关键路径，关键路径长度决定工期。PERT 的缺点是难以清晰看到任务起止时间的直观进度（与 Gantt 恰好互补）。
- 风险分析：识别 → 评估（风险值=概率×影响）→ 评价 → 管理/监控。主动采取措施叫规避，接受损失叫吸收（自留），转给第三方（如保险）叫转移。
6. 质量特性与质量模型
- ISO/IEC 25010 给出软件质量 8 大特性：功能性、性能效率、兼容性、易用性、可靠性、信息安全性、维护性、可移植性（旧版 25010 前身 9126 是 6 特性，注意版本差异）。
- McCall 质量模型：11 个质量特性分成三组：
- 运行方面：正确性、可靠性、效率、完整性、使用性（易用性）；
- 修正方面：维护性、灵活性（适应性）、可测试性；
- 转移方面：可移植性、复用性、共运行性（互操作性）。
考法：给一个特性问属于哪方面。记住"转移=搬到别的机器上"，可移植性、复用性、互操作性都在这组。
7. 结构化分析（SA）与结构化设计（SD）
- SA 的核心工具是数据流图（DFD），四种成分：数据流（箭头）、加工/处理（圆或圆角矩形）、数据存储（双横线/开口矩形）、外部实体（方框，源点/终点）。
- 分层 DFD 要保持父图与子图平衡：父图中某加工的输入输出数据流必须与对应子图的相同；顶层只有一张。
- 加工分解层数一般控制在"7±2"以内，别把一张图画成蜘蛛网。
- 数据字典（DD） 定义数据流和数据存储的细节，定义式符号：
=表示"定义为"、+表示"与"、[ | ]表示"或"、{ }表示重复、( )表示可选。 - 加工逻辑描述三工具：结构化语言（伪码）、判定表、判定树。多条件组合复杂时用判定表最清晰。
- SD 以结构图（SC 图）表达模块结构，把 DFD 映射为模块层次：
- 数据流分两种类型：变换流（输入→变换中心→输出）和事务流（一个事务中心按类型分派给多个动作路径）。
- 变换分析三步：确定输入流和输出流的边界（找变换中心）→ 完成一级分解（顶层：输入、变换、输出模块）→ 完成二级分解（中下层模块）。
- 模块独立性 = 内聚 + 耦合，这是每年必背的排序题：
- 内聚（由低到高）：偶然内聚 < 逻辑内聚 < 时间内聚 < 过程内聚 < 通信内聚 < 顺序内聚 < 功能内聚（最好）。
- 耦合（由高到低）：内容耦合（最糟，一个模块直接访问另一个内部数据/代码）> 公共耦合 > 外部耦合 > 控制耦合 > 标记耦合 > 数据耦合 > 非直接耦合（最好）。
- 设计原则：高内聚、低耦合；尽量用数据耦合，避免内容耦合。
8. 软硬件协同设计
嵌入式系统区别于纯软件的地方：软硬件要一起设计。
- 划分：决定哪个功能用硬件实现、哪个用软件实现。原则有三：性能原则（性能关键部分给硬件）、性价比原则（成本敏感部分掂量着放）、资源利用率原则。
- 划分评估方法有：性能评估、成本评估、功耗评估等；常用的图模型：单任务图、多分支图、并行流图等；统一表示可使用 INP（完全问题/Integer-numbered Process？考试中记作 INP 模型）等系统模型。
- 协同设计的典型流程：系统需求 → 软硬件划分 → 软硬件协同综合（调度与分配）→ 协同仿真与验证 → 集成。
9. 面向对象分析与 UML
- OOA（面向对象分析）建立对象模型、动态模型、功能模型；OOD 在 OOA 基础上加实现细节；OOP 用语言落地。
- UML 的四种事物：结构事物（类、接口、协作、用例、构件、节点等）、行为事物（交互、状态机）、分组事物（包）、注释事物（注解）。
- UML 的四种关系：
- 依赖：虚线箭头，"使用即依赖"（如类的参数引用另一个类）；
- 关联：实线，结构化联系，有重数（1.. 等）；关联的特例是聚集（聚合）——整体与部分但部分可独立存在；更强的组合*（实心菱形）部分不能独立存在；
- 泛化：空心三角实线，即继承（is-a）；
- 实现：空心三角虚线，类实现接口。
- UML 13 种图分两大类：
- 静态图（结构图）：类图、对象图、构件图、部署图、包图（组合结构图）；
- 动态图（行为图）：用例图、顺序图（时序图）、通信图（协作图）、状态图（状态机图）、活动图、交互概览图、定时图（时间图）。
- 记法："静态记结构（类对象构件部署包），动态记行为（用例顺序通信状态活动）"。状态图描述单个对象的状态迁移，活动图描述工作流（可画泳道），顺序图强调时间顺序，通信图强调对象组织结构。
10. 设计模式：23 个经典模式三大类
设计模式是"可复用的面向对象设计经验"，分三类：
- 创建型（5 个，管"造对象"）：
- Factory Method 工厂方法：定义创建对象的接口，让子类决定实例化哪个类；
- Abstract Factory 抽象工厂：创建一族相关产品；
- Builder 生成器：分步构建复杂对象，同样的构建过程可得到不同表示；
- Prototype 原型：通过克隆已有实例来创建新对象；
- Singleton 单例：一个类只有一个实例，全局访问点。
- 结构型（7 个，管"怎么组装"）：
- Adapter 适配器：转换接口，让不兼容的类一起工作（类适配器/对象适配器）；
- Bridge 桥接：把抽象部分与实现部分分离，使它们独立变化（避免多维度继承爆炸）；
- Composite 组合：树形"部分—整体"层次，如文件系统目录；
- Decorator 装饰器：不改变接口动态给对象加职责（比继承更灵活）；
- Facade 外观：给子系统提供一个统一的高层接口；
- Flyweight 享元：共享大量细粒度对象以省内存；
- Proxy 代理：给对象提供占位符以控制访问（远程、虚拟、保护代理）。
- 行为型（11 个，管"对象怎么交互、职责怎么分配"）：
- Chain of Responsibility 责任链：请求沿处理者链传递，如审批流；
- Command 命令：把请求封装成对象，可撤销、排队、记日志；
- Interpreter 解释器：为语言定义文法及解释器；
- Iterator 迭代器：顺序访问集合元素而不暴露内部表示；
- Mediator 中介者：用中介对象封装一组对象的交互（网状→星型）；
- Memento 备忘录：不破坏封装地保存/恢复对象状态；
- Observer 观察者：一对多依赖，状态变化通知所有观察者（事件机制）；
- State 状态：对象行为随内部状态改变而改变；
- Strategy 策略：封装一系列算法，使它们可以互相替换；
- Template Method 模板方法：父类定算法骨架，子类重写某些步骤；
- Visitor 访问者：不改变类的前提下给类增加新操作。
下午案例题常给一段场景描述问"用了什么设计模式"，答题口诀：换接口=Adapter、分维度=Birdge、树结构=Composite、加功能=Decorator、统一入口=Facade、共享省内存=Flyweight、控制访问=Proxy、造对象看创建型、通知=Observer、换算法=Strategy、骨架在父类=Template Method。
11. 系统实施：测试与调试
- 测试原则（8 条，理解即可）：
- 尽早、不断地进行测试；
- 测试用例应包括输入数据和预期的输出结果；
- 程序员应避免测试自己的程序（也要避免开发小组测试自己的程序）；
- 既要测试合法输入，也要测试非法/意外输入；
- 注意测试中的群集现象（错误往往集中在少数模块，80% 错误集中在 20% 模块）；
- 严格执行测试计划，排除随意性；
- 妥善保存测试计划、用例、出错统计等，作为文档保留；
- 彻底的穷举测试是不可能的。
- 测试过程五步：单元测试 → 集成测试 → 确认测试（有效性测试+软件配置审查+Alpha/Beta 测试）→ 系统测试 → 验收测试。单元测试用白盒为主，后面逐步转黑盒。
- 测试工具六类：静态分析工具、动态测试工具、测试数据生成工具、模块测试台、集成测试环境（测试管理系统）、性能模拟与仿真环境等。
- 调试（排错）方法 5 种：
- 试探法（蛮力法）：硬凑数据、打印信息，效率低；
- 回溯法：从错误现象出发沿程序逻辑往回找；
- 对分查找法：在程序中点插入检查，逐步缩小范围；
- 归纳法：从线索（若干测试结果）出发归纳出错误原因；
- 演绎法：先列出所有可能原因，逐一排除，剩下即真凶。
注意区分：测试是"发现错误"，调试是"定位并改正错误"。
12. 系统维护
软件交付后还有漫长的维护期，维护费通常超过开发费。
- 四类维护及占比（软考必背）：
- 完善性维护：增加新功能、改善性能——占 50%~60%，最大头；
- 适应性维护：适应环境（硬件、OS、法规）变化——约 18%~25%；
- 正确性（改正性）维护：修 bug——约 17%~21%；
- 预防性维护：为将来的可维护性提前做改造——约 4%，最少。
- 记忆："完善最大、预防最小"。
- 维护副作用三类：编码副作用、数据副作用、文档副作用。改了代码忘改文档，文档副作用就发生了——这提醒我们维护必须同步更新文档。
13. 系统评价
系统评价分三个时点：立项评价（事前，可行性角度）、中期评价（事中，阶段成果与调整）、结项/终期评价（事后，效果与效益）。评价维度包括性能、效益（经济效益与社会效益）、管理水平等。
初学者容易踩的坑
- Gantt 与 PERT 的优缺点记反：Gantt 直观但不能反映依赖；PERT 能反映依赖和关键路径但不够直观。考题常设"某图能反映任务依赖关系"让你选，答案永远是 PERT。
- 内聚耦合排序记反：内聚是"越低越差"（偶然最差、功能最好），耦合是"越高越差"（内容最差、非直接最好）。两个列表方向相反，考前一定再默写一遍。
- 原型与螺旋混淆：螺旋模型的关键增量是"风险分析"，没有风险分析的就不是螺旋；原型模型的关键是"快速做给用户看"。
- V 模型对应关系错位：验收测试↔用户需求，系统测试↔需求分析，集成测试↔概要设计，单元测试↔详细设计。别把集成测试对到详细设计上。
- 维护占比想当然：很多人以为修 bug 的正确性维护占大头，实际完善性维护占一半以上。这是送分题也是陷阱题。
- 聚合与组合不分：聚合（空心菱形）整体散了部分还能活（班级和学生）；组合（实心菱形）整体没了部分也没了（人和心脏）。UML 填空题爱考菱形的实虚。
- 设计模式张冠李戴：Strategy 和 State 长得像（都是组合+多态），区别在意图——Strategy 是"换算法"且互相独立，State 是"状态驱动行为切换"且通常知道其他状态。Bridge 和 Adapter 也易混：Adapter 是事后补救不兼容接口，Bridge 是事前设计分离两个变化维度。
- 调试与测试混为一谈：测试找错，调试改错；归纳法是从结果推原因，演绎法是列假设再排除，考试给场景要能对号。
小结 & 备考提示
本章是"背多分 + 理解应用"双轨并行的一章：
- 上午题重点背：过程模型选型（螺旋=风险、原型=需求模糊、瀑布=需求明确）、CMM 五级关键词、内聚耦合排序、McCall 三组 11 特性、维护四类占比（完善 50~60% 最大）、Gantt/PERT 优缺点、UML 图分类。
- 下午题重点练：DFD 补齐数据流（注意父子图平衡）、判定表/判定树、结构图变换分析、UML 图识别与填空（类图关系、菱形方向）、设计模式场景识别、PERT 图关键路径计算。
- 一个高效的复习策略：把"内聚 7 种、耦合 7 种、McCall 11 特性、维护 4 类占比、23 个设计模式名称"做成一张随身小抄，考前反复过；过程模型和 UML 则靠做题理解场景。
下一章（第8章）专门讲嵌入式系统软件测试技术，本章的测试原则、测试过程会继续展开，两章连着复习效果最好。