软件工程与开发方法

本章系统梳理了从传统的结构化方法到现代敏捷开发、构件化工程及 CMMI (Capability Maturity Model Integration, 能力成熟度模型集成) 过程改进等软件工程核心知识。

1. 软件工具分类 (按软件过程活动)

【考试要点解析】工欲善其事，必先利其器。软件工具就是程序员手里的“家伙事儿”。考试的时候，经常会拿一堆工具名字来考你分类。这里最容易混的是“配置管理工具”，你可能觉得它只是用来存代码的（版本控制），但其实它管得更宽，还包括变更管理（谁改了啥）和状态统计（改完了没）。另外，逆向工程工具属于“维护工具”，因为它是在软件写完之后，为了搞懂它或者修它才用到的。

软件开发工具：需求分析工具、设计工具、编码与排错工具。
软件维护工具：
版本控制工具 (VSS (Visual SourceSafe), CVS (Concurrent Versions System), SCCS (Source Code Control System), SVN (Subversion))
文档分析工具
开发信息库工具
逆向工程工具
再工程工具
软件管理和软件支持工具：项目管理工具、配置管理工具、软件评价工具等。
配置管理工具功能：版本控制、变更管理、配置状态管理、访问控制和安全控制等。（注：配置管理工具包含了版本控制工具）。

2. 结构化开发方法

【考试要点解析】结构化方法就是老一辈的“瀑布式”思维，做事讲究个先来后到，一步一个脚印。它的核心思想是“自顶向下”，先看大局，再抠细节。这种方法的好处是规矩、严谨，文档齐全，谁接手都能看懂。但坏处就是太死板，客户要是半路改主意，那可就惨了，得从头推翻重来。所以，如果你的项目需求特别明确，像盖大楼一样，那就用它；如果需求变来变去，千万别用。

采用自顶向下、逐步分解 (求解) 的策略。严格区分工作阶段，每阶段有明确任务与成果。强调系统开发过程的整体性和全局性，开发目标清晰化，工作阶段程式化，开发文档规范化，设计方法结构化。

优点：理论基础严密，注重开发过程的整体性和全局性，适合需求明确的项目。
缺点：开发周期长；文档和设计说明繁琐，工作效率相对较低。

3. 原型法开发方法

【考试要点解析】原型法就是为了对付那些“不知道自己想要啥”的客户。与其跟他干聊需求，不如先花点时间做一个样板（原型）给他看。他看到了实物，就能说出“这儿不对”、“那儿要改”。这样反复几次，需求就搞清楚了。考试常考怎么分类：如果是为了看界面漂不漂亮，那是“水平原型”；如果是为了验证算法通不通，那是“垂直原型”。如果是做完就扔的，叫“抛弃式”；如果是慢慢改成正品的，叫“演化式”。

利用系统开发工具，快速建立一个系统模型展示给用户，在此基础上与用户交流，最终实现用户需求。适用于需求不明确的开发。

按功能实现程度分类：

水平原型 (行为原型)：探索预期系统的一些特定行为，达到细化需求的目的。通常只是功能的导航，主要用于界面设计。
垂直原型 (结构化原型)：实现了一部分功能，主要用于复杂的算法实现。

按最终结果分类：

抛弃式原型 (探索式原型)：达到预期目的后被抛弃。主要用于解决需求不确定性、二义性、不完整性。
演化式原型：逐步将原型演化成最终系统。主要用于必须易于升级和优化的场合，适合 Web 项目。

4. 面向对象方法

【考试要点解析】面向对象 (Object-Oriented, OO) 是现在的主流，它符合咱们人类看世界的方式——世界是由一个个“东西”（对象）组成的。每个东西有自己的属性（数据）和能干的事（方法）。OO 的最大好处就是“复用”，以前造过的轮子，拿过来就能装在新车上。考试里重点要搞清楚封装（藏起来）、继承（父传子）、多态（千人千面）这三大特征。

最早来源于仿真领域。特点是系统的描述及信息模型的表示与客观实体相对应，符合思维习惯，有利于用户与开发人员沟通。

优势：缩短开发周期，提高系统开发的准确性和效率，具有更好的复用性。
核心：建立一个全面、合理、统一的模型（分析、设计、实现三个阶段界限不明确）。
OMT (Object Modeling Technique, 对象建模技术) 方法 (UML (Unified Modeling Language, 统一建模语言) 前身) 三种模型：
对象模型：描述系统数据结构。
动态模型：描述系统控制结构。
功能模型：描述系统功能。

5. 面向服务的方法 (Service-Oriented Architecture, SOA)

【考试要点解析】 SOA 就是为了解决“系统烟囱”问题而生的。它把系统里的功能拆成一个个粗粒度的“服务”，大家通过标准接口说话，谁也不挨着谁（松耦合）。这就像积木，不管原来是木头的还是塑料的，只要接口一样，就能拼在一起。理解 SOA 要分三层看：最底下是干活的“操作”，中间是打包好的“服务”，最上面是串起来的“业务流程”。

以粗粒度、松散耦合的系统功能为核心，强调系统功能的标准化和构件化，加强了系统的灵活性、可复用性和可演化性。

SOA 的三个主要抽象级别：

操作：代表单个逻辑工作单元 (Logical Unit of Work, LUW) 的事务。位于最底层，类似于 OO 中的方法。
服务：代表操作的逻辑分组。例如，“客户画像”服务包含“查找客户”、“保存客户”等操作。
业务流程：为实现特定业务目标而执行的一组长期运行的动作或活动。例如，“接纳新员工”、“完成订单”。

6. 原型模型

【考试要点解析】原型模型既是方法也是过程。它打破了瀑布模型那种“一条道走到黑”的模式。它的核心就两步：先快速做一个样子出来（原型开发），客户点头了，再正儿八经地做（目标软件开发）。这对那些需求模糊的项目绝对是救命稻草。

典型的原型开发方法模型，适用于需求不明确的场景。两个阶段：

原型开发阶段
目标软件开发阶段

7. 瀑布模型

【考试要点解析】瀑布模型是软件工程的老祖宗。它的特点就像瀑布流水，一级一级往下流，回不去。需求分析做完做设计，设计做完写代码。这种模式非常依赖文档，上一个阶段的输出就是下一个阶段的输入。一旦最开始的需求搞错了，那后面全是白忙活，回炉重造的代价极大。所以，除非你对需求有十足的把握，否则慎用。

将软件生存周期中的各个活动规定为线性顺序连接的若干阶段：需求分析 -> 软件设计 -> 程序设计 -> 编码实现 -> 单元测试 -> 集成测试 -> 系统测试 -> 运行维护。

特点：严格区分阶段，每个阶段因果关系紧密相连。
适用性：只适合需求明确的项目。

8. 增量模型

【考试要点解析】增量模型就是“分期付款”。与其让用户等一年才拿到完整的软件，不如先给他一个能用的核心功能（第一个增量），让他先用起来。然后再每隔一段时间给他加点新功能。这样用户高兴，因为能早点干活；你也高兴，因为风险分散了。不过这对架构要求很高，得保证后加的功能能顺利插进去。

融合了瀑布模型的基本成分和原型实现的迭代特征。

特点：可以有多个可用版本的发布，核心功能往往最先完成。每轮迭代发布新的增量，核心功能得到充分测试。
强调：每一个增量均发布一个可操作的产品。

9. V 模型和 W 模型

【考试要点解析】 V 模型最大的贡献是告诉我们：测试不是最后才干的事，它和开发过程是一一对应的。比如，你在写详细设计的时候，单元测试的计划其实就该有了。而 W 模型更进一步，它说测试应该和开发“双龙戏珠”，并行推进。从需求分析开始，测试人员就得介入，这就叫“测试左移”。

V 模型：强调测试贯穿项目始终，是一种测试驱动的开发模型（测试活动与开发活动对应）。
W 模型：强调测试和开发并行进行。

10. 敏捷开发

【考试要点解析】敏捷开发就是为了应对“变化”。它不迷信文档，不迷信流程，就信“人”和“代码”。它的节奏是“小步快跑”，两周一个迭代，快速试错。考试常考那几个流派：XP (Extreme Programming, 极限编程) 强调结对编程、测试驱动；Scrum (敏捷开发框架) 强调站会、冲刺。如果你是小团队，需求又老变，敏捷就是你的首选。

以人为核心、迭代、循序渐进的开发方法。适用于小团队和小项目，具有“小步快跑”的思想。

常见方法：极限编程 (XP)、水晶法、并列争球法 (Scrum)、自适应软件开发 (ASD (Adaptive Software Development))。

11. 统一过程 (UP/RUP)

【考试要点解析】 RUP (Rational Unified Process, Rational 统一过程) 是个“大块头”，它是给大公司、大项目准备的。它有三个法宝：第一是“用例驱动”，一切从用户需求出发；第二是“以架构为中心”，先把骨架搭好；第三是“迭代增量”，一口口吃成胖子。它把开发分成四个阶段：初始（画大饼）、细化（搭骨架）、构建（填肉）、移交（交货）。每个阶段都有明确的目标，非常稳健。

典型特点：用例驱动、以架构为中心、迭代和增量。

四个阶段：

构思阶段 (Inception)：定义最终产品视图、业务模型、确定系统范围。
细化阶段 (Elaboration)：设计及确定系统架构、制定工作计划及资源要求。
构造阶段 (Construction)：开发剩余构件和功能，集成产品并进行详细测试。
移交阶段 (Transition)：确保软件对最终用户可用，进行 β 测试，制作发布版本。

9 个核心工作流：业务建模、需求、分析与设计、实现、测试、部署、配置与变更管理、项目管理、环境。

12. 基于构件的软件工程 (CBSE)

【考试要点解析】 CBSE (Component-Based Software Engineering, 基于构件的软件工程) 的核心思想就是“搭积木”。与其自己一砖一瓦地盖房子，不如去买现成的门窗、墙板（构件）拼装起来。这样不仅快，而且质量有保证，因为那些构件都是经过检验的。当然，前提是这些积木的接口得是标准的，不然拼不上。

体现了“购买而不是重新构造”的哲学。

构件特征：

可组装性：交互通过公开接口进行。
可部署性：二进制形式，独立实体运行。
文档化：用户依靠文档判断是否满足需求。
独立性：可独立组装和部署。
标准化：符合标准化模型。

构件组装方式：

顺序组装：按顺序调用。
层次组装：被调用构件的“提供”接口兼容调用构件的“请求”接口。
叠加组装：合并形成新构件，整合功能并提供新接口。

13. 构件模型要素

【考试要点解析】一个好构件，光有代码是不够的。它得有“说明书”。首先是接口，告诉别人怎么用它；其次是使用信息，包括它叫啥、有啥属性；最后是部署说明，告诉别人怎么把它装进系统里。这三样缺一不可，否则别人拿到了也不敢用、不会用。

接口：定义构件的操作、参数及异常。
使用信息：包括构件的全局唯一名称、元数据（接口和属性信息）以及配置方式。
部署：打包规格说明，指出如何打包成独立的可执行实体。

14. 逆向工程及相关概念

【考试要点解析】这块是讲怎么处理老旧系统的。逆向工程就像是“破案”，从现有的代码反推出当初的设计图；正向工程就是正常的盖楼，从设计图出代码。重构是在不改变功能的前提下整理代码，让它更整洁。再工程则是大动干戈，先把老系统研究透（逆向），再结合新需求，重新盖一遍（正向）。

重构 (Restructuring)：在同一抽象级别上转换系统描述形式。
设计恢复 (Design Recovery)：从已有程序中抽象出数据、结构和过程设计信息。
逆向工程 (Reverse Engineering)：分析程序，在比源代码更高抽象层次上建立程序的表示过程（设计的恢复过程）。
正向工程 (Forward Engineering)：从现有系统中恢复设计信息，并使用该信息重构系统以改善质量。
再工程 (Re-engineering)：对现有系统的重新开发过程。包含：逆向工程 -> 新需求考虑 -> 正向工程。

15. 净室软件工程

【考试要点解析】净室工程听起来很“洁癖”，其实它就是追求“零缺陷”。它的思路是：与其写完了再测 Bug，不如在写的时候就用数学方法证明它是对的。它用“盒结构”来建模，分为黑盒（只看输入输出）、状态盒（看状态变化）、明盒（看具体逻辑）。虽然理论很完美，但因为太难太贵，实际用得很少。

强调在受控（“洁净”）环境下开发，使用盒结构规约（形式化方法）进行建模。

核心理念：将正确性验证作为发现和消除错误的主要机制，而不是测试。
技术手段：
统计过程控制下的增量式开发。
基于函数的规范和设计（盒子结构）：黑盒 (行为) -> 状态盒 (状态机) -> 明盒 (过程)。
正确性验证（核心）。
统计测试和软件认证。
缺点：太理论化，正确性验证耗时困难；不进行传统模块测试在现实中较难实施。

16. 软件过程改进 (CMMI)

【考试要点解析】 CMMI 就是给软件公司的能力打分。一级是草台班子，乱七八糟；二级是项目经理牛，能管好单个项目；三级是公司牛，有一套标准流程，谁来都一样；四级是数据牛，管理能量化，用数据说话；五级是自我进化，不仅好，还能不断更好。考试常给你个场景，问你这公司是几级。

等级	名称	关键特征
L1	初始级	混乱，不可预测。
L2	已管理级	项目级可重复。关注需求、计划、配置、监督。
L3	已定义级	组织级标准化文档。关注技术解决、验证确认、组织级过程。
L4	定量管理级	量化管理。关注过程性能、定量项目管理。
L5	优化级	持续优化。关注改革、因果分析。

17. 使用许可

【考试要点解析】这里是讲知识产权的。重点分清“独占”和“排他”。独占许可最霸道，只要授权给你了，连原作者自己都不能用了，你是独一份。排他许可稍微好点，原作者还能用，但不能再给别人用了。普通许可就是大家都能用，谁给钱给谁用。

独占许可：仅被授权人可用（著作权人也不可用）。
排他许可：被授权人 + 著作权人可用。
普通许可：多人可用。

预览时标签不可点

Name cleared

微信扫一扫赞赏作者

Like the AuthorOther Amount

赞赏后展示我的头像

作品

暂无作品

Like the Author

Other Amount

最低赞赏 ¥0

Back

Other Amount

赞赏金额

最低赞赏 ¥0

二手架构师杂谈 · 目录

二手架构师杂谈

上一篇软考高级系统架构设计师知识精要-信息系统与企业信息化下一篇软考高级系统架构设计师知识精要-系统建模与UML设计

搜索「」网络结果

调整当前正文文字大小

100%