软件开发方法是软件开发的方法学。自从“软件危机”爆发以来，软件研究人员就在对
开发方法进行不断地研究，以期能够提高软件的质量、降低软件的成本。经过 40 多年的研
究，人们提出了很多开发方法，如最初的结构化开发到现在非常流行的面向对象的开发方法
等。本章将介绍软件生命周期、软件开发模型、软件重用技术、逆向工程及形式化开发方法。
1 软件生命周期
| 可行性研究与计划 | 确定开发此软件的必要性，确定软件的目标、范围、风险、开发成本等内容 将产生《可行性研究报告》和《软件开发计划》 |
| 需求分析 | 确定软件要做成什么样的 |
| 概要设计 | 将需求分析的结果转化为技术层面的设计方案 确定系统架构、各子系统间的关系、 接口规约、数据库模型、编码规范等内容 概要设计的结果将作为程序员的工作指南，供程序员了解系统的内部原理，并在其基础上进行详细设计和编码工作 |
| 详细设计 | 在概要设计的基础上，进行细化，如类设计 详细设计不是开发过程中必需的阶段 |
| 实现 | 包括编码和单元测试 |
| 集成测试 | 指定集成测试计划，确定如何将这些程序单元集 成到一起，按照什么样的顺序进行测试，使用哪些测试数据等问题 |
| 确认测试 | 验证软件是否同需求一致，是否达到了预期目标 |
| 使用和维护 | 软件维护的过程会贯穿整个软件的使用过程。 当使用和维护阶段结束后，软件系统也就自然消亡，软件系统的生命周期结束。 |
2 软件开发模型
| 瀑布模型 | 一个阶段到下一个阶段有明显的界线。 在每个阶段结束后，都会有固定的文档或源程序流入下一阶段
当软件需求明确、稳定时，可以采用瀑布模型按部就班地开发软件 |  |
| 瀑布 V 模型 | 总体设计对应了集成测试，详细设计对应了单元测试 保持了瀑布模型的阶段式文档驱动的特点，而且更强调了软件产品的验证工作 瀑布模型后期的维护工作相当繁重，而这些维护工作大多都是修正在需求分析阶段引入的缺陷 |  |
| 螺旋模型 | 螺旋模型的每一周期都包括需求定义、风险分析、 工程实现和评审 4 个阶段，由这 4 个阶段进行迭代，软件开发过程每迭代一次，软件开发就前进一 螺旋模型强调风险分析 需要具有相当丰富的风险评估经验和专业知识 在风险较大的项目开发中，如果未能及时标识风险，势必会造成重大损失。 |  |
| 增量模型 | 将系统划分为若干不同的版本，每一个版本都是一个完整的系统，后一版本以前 一版本为基础进行开发，扩充前一版本的功能 | |
| 原型法开发 | 原型法的每一次迭代都经过一个完整的生命周期 户需求很不明确或技术架构中存在很多不可知因素的时候，可以采用原型法 | |
| 构件组装模型 |  构件的自包容性让系统的扩展变得更加容易 在考虑软件的重用度时，往往会对其他方面做出让步，如性能 使用构件组装应用程序时，要求程序员熟练地掌握构件，增加了研发人员的学习成本 | |
| 统一过程 | 统一过程（Unified Process， UP）UP 是一个迭代的二维开发模型，在生命周期的每一阶段 都可以进行需求、设计等活动 UP 的迭代特点使得更容易控制软件开发的风险。 |  |
| 敏捷方法 1、极限编程XP | 由价值观、原则、实践和行为四个部分组成，它们彼此相互依赖、关联，并通过行
在 XP 的四大价值观之下，隐藏着一种更深刻的东西，那就是尊重。因为这一切都建立在团队成员之间相互关心、相互理解的基础之上。 在 XP 中，集成了 12 个最佳实践，（1）计划游戏（2）小型发布（3）隐喻（4）简单设计（5）测试先行（6）重构（7）结对编程（8）集体代码所有制（9）持续集成（10）每周工作 40 小时（11）现场客户（12）编码标准 | |
| 敏捷方法 2、特征驱动开发（FDD） | 有效的软件开发不可缺少的三个要素是：人、过程和技术 FDD 定义了 6 种关键的项目角色：（1）项目经理（2）首席架构设计师（3）开发经理（4）主程序员（5）程序员（6）领域专家：一般由客户、系统分析员等担当 FDD 共有 5 个核心过程
组成 FDD 的最佳实践包括：领域对象建模、根据特征进行开发、类的个体所有、组成 | |
| 敏捷方法 3、Scrum |
Scrum 主要包括：产品待办事项列表梳理、 Sprint 计划会议、每日 Scrum 会议、 Sprint Scrum 的 5 大价值观为： | |
| 敏捷方法 4、水晶方法（ Crystal） | 透明水晶方法有七大体系特征： （1）经常交付（2）反思改进（3）渗透式交流（4）个人安全（5）焦点（6）与专家用户建立方便的联系（7）配有自动测试、配置管理和经常集成功能的技术环境 | |
| 敏捷方法 5、开放式源码 | 开放源码的一个突出特点就是查错 ASD 方法： ASD (Adaptive | |
3 软件重用
常见的软件重用形式包括：
（1）源代码重用
（2）架构重用
（3）应用框架的重用
（4）业务建模的重用
（5）文档及过程的重用
（6）软构件的重用
（ 7）软件服务的重用
构件技术
构件又称为组件，是一个自包容、可复用的程序集。
构件是一个程序集，或者说是一组程序的集合。这个集合可能会以各种方式体现出来，如源程序或二进制的代码。这个集合整体向外提供统一的访问接口，构件外部只能通过接口来访问构件，而不能直接操作构件的内部
自包容指的是构件的本身是一个功能完整的独立体，构件内部与外部的功能界限清晰明确，可以独立配置与使用。
而可重用既是构件的特点，也是构件出现的目的。
目前应用比较广泛的构件标准有 CORBA、Java Bean/EJB、COM/DCOM。
4 基于架构的软件设计
基于架构的软件设计（Architecture-Based Software Design， ABSD）是一种架构驱动方法。
这种方法有 3 个基础：
（1）功能的分解。在功能分解中， ABSD 方法使用已有的基于模块的内聚和耦合技术。
（2）通过选择架构风格来实现质量和业务需求。
（3）软件模板的使用。软件模板利用了一些软件系统的结构
ABSD 方法的输入由下列部分组成：
（1）抽象功能需求，包括变化的需求和通用的需求；
（2）用例（实际功能需求）；
（3）抽象的质量和业务需求；
（4）质量因素（实际质量和业务需求）；
（5）架构选项；
（6）约束。
基于架构的软件开发模型（Architecture-Based Software Design Model， ABSDM）把整个
基于架构的软件过程划分为架构需求、设计、文档化、复审、实现、演化等 6 个子过程，
 |  |
 |  |
5 形式化方法
形式化方法是指采用严格的数学方法，使用形式化规约语言来精确定义软件系统。
非形式化的开发方法是通过自然语言、图形或表格描述软件系统的行为和特性，然后基于这些描
述进行设计和开发，而形式化开发则是基于数学的方式描述、开发和验证系统。
形式化方法包括形式化描述和基于形式化描述的形式化验证两部分内容。
形式化描述就是用形式化语言进行描绘，建立软件需求和特性，即解决软件“做什么”的问题
形式化验证指的是验证已有的程序是否满足形式化描述的定义
978
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
