软件生命周期

软件开发模型

统一过程

敏捷方法

所谓敏捷开发，个人认为，最大特点就是，过程中多输出，多反馈，让客户看到实现效果，虽然这还不是最终成品。

极限编程

极限编程（XP）方法是一种轻量（敏捷）、高效、低风险、柔性、可预测、科学且充满乐趣的软件开发方式。XP由** 价值观、原则、实践、行为**四个部分组成，它们彼此相互依赖、关联，并通过行为贯穿整个生命周期。

XP的核心是其总结的 沟通、简单、反馈、勇气 四大价值观，它们是XP的基础，也是XP的灵魂。

• 沟通 ：在传统的开发方法中，主要借助于完善的流程和面面俱到的文档、报表、计划来替代，但效率低，而XP ** 鼓励大家进行口头交流、通过交流解决问题 **，以提高效率。
• 简单：传统的开发方法中，都要求开发人员对未来做一些预先规划，以便对今后可能发生的变化预留一些扩展空间，XP秉承“够用即好”的思路，也就是尽量地简单化，只要今天够用就行，不考虑明天会出现的新问题。

在XP中集成了12个最佳实践，它们本身每个都没有创新的概念，但最大的创新点在于提供一种良好的思路将这些最佳实践结合在一起，并且确保尽可能彻底地执行，使得它们能够在最大程度上互相支持。

ps：对12个实践中的测试先行、重构、结对编程、集体代码所有制、每周工作40小时、现场客户、编码标准很有感触，

• 写完功能一定要测试；
• 而且发现架构不利于后续维护、需求增加，一定要有重构的勇气；
• 以团体的形式进行开发，代码共享；
• 在完成每日任务的情况，不加班，避免影响第二天开发；
• 到现场都跟客户交流，一起交流过程中完成开发过程；
• 在开发时一定要有一个明确的编码规则，是驼峰、下划线命名法要定好，避免后续其他人接手维护不方便。

特征驱动开发

FDD 也是一个迭代的开发模型，它的每一步都强调质量，不断交付可运行软件，并以很小的开发提供精确的项目进度报告和状态信息。

FDD 定义了6种关键的项目角色：

1. 项目经理
2. 首席架构设计师
3. 开发经理：负责团队日常开发，解决开发中出现的技术问题和资源冲突
4. 主程序员：将带领一个小组完成特征的详细设计和构建工作
5. 程序员
6. 领域专家：是对业务领域精通的人，一般由客户、系统分析员等担当，领域专家作为关键的项目角色正是敏捷宣言中“业务人员同开发人员紧密合作”的体现。

FDD一共5个核心过程，由领域专家和首席架构设计师相互配合，完成整体对象模型的开发；然后构建一个完整的特征列表，所谓特征即一个小的、对客户有价值的功能；然后由项目经理根据构造出的特征列表、特征间的依赖关系进行计划，安排开发任务；接着主程序员带领特征小组对特征进行详细设计和构建，这2个过程反复迭代，直到完成全部开发。

Scrum

Scrum 是一个用于开发和维持复杂产品的框架，是一个增量的、迭代的开发过程；整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint ； 使用产品Backlog 来管理产品的需求，它是一个按照商业价值排序的需求列表；挑选最高优先级的需求在Sprint 计划会议上经过讨论、分析和估算得到相应的任务列表，即Sprint backlog 。

Scrum 主要包括5个活动 ： 产品待办事项列表梳理、Sprint 计划会议、每日Scrum 会议、Sprint 评审会议、Sprint 回顾会议。

Scrum 的** 5个价值观**:

• 承诺–愿意对目标做出承诺
• 专注–把你的心思和能力都用到你承诺的工作上去
• 开放–Scrum 把项目中的一切开放给每个人看
• 尊重–每个人都有他独特的背景和经验
• 勇气–有勇气做出承诺，履行承诺，接受别人的尊重。

水晶方法

水晶方法（Crystal）使用频度较高的是Crystal Clear — 透明水晶方法，适合于一个小团队来进行敏捷开发，人数在6人以下为宜。透明水晶方法有7大体系特征：

• 经常交付
• 反思改进
• 渗透式交流 — 通常就是通过团队成员在同一间工作室内工作而实现，若其中一个成员提出问题，工作室内其他成员可以选择关注或不关注的态度，可以加入到这个问题的讨论当中来，也可以继续忙自己的工作。
• 个人安全–当你指出困扰你的问题时，你不用担心受到报复
• 焦点–明确首先要做什么，然后安排时间，以平和的心态开展工作
• 与专家用户建立方便的联系
• 配有自动测试、配置管理和经常集成功能的技术环境

开放式源码

一个特别之处，就是程序开发人员在地域上分布很广。一个突出特点就是 查错排障（debug）的高度并行性，任何人发现了错误都可以将改正源码的补丁文件发给维护者，然后由维护者将这些补丁或是新增代码并入源码库。

ASD

核心是三个非线性的、重叠的开发阶段 ：** 猜测、合作 、学习 **。

软件重用

主要要注意一下构件技术的两个最重要的特性：自包容 和可重用 。

• 自包容 ： 构件本身是一个功能完整的独立体，构件内部与外部的功能界限清晰明确，可以独立配置与使用

基于架构的软件设计

基于架构的软件设计（Architechture-Based Software Design ,ABSD）是一种架构驱动方法，这种方法有3个基础：

• 功能的分解。在功能分解中，ABSD使用已有的基于模块的内聚和耦合技术。
• 通过选择架构风格来实现质量和业务需求
• 软件模板的使用。软件模板利用了一些软件系统的结构，就像实现tcp 通信可以用servlet 模板。

ps ：内聚是指一个模块内部各个元素之间的联系紧密度；而耦合是指模块与模块之间的联系紧密度

基于架构的软件开发模型（Architecture-Based Software Design Model ,ABSDM）把整个基于架构的软件过程划分为架构需求、设计、文档化、复审、实现、演化等6个子过程。

• 架构需求 ： 包含 ** 需求获取 - 标识构件 - 需求评审** 三部分，且有序。
• 架构文档化 ： 主要输出 架构需求规格说明 ** 和 ** 测试架构需求的的质量设计说明书 两个文档。

形式化方法

形式化方法是采用严格的数学方法，使用形式化规约语言来精确定义软件系统。包括形式化描述 和基于形式化描述的形式化验证两部分内容。形式化描述用于解决软件做什么的问题，形式化验证用于验证已有的程序是否满足形式化描述的定义。

非形式化的开发方法是通过自然语言、图形或表格描述软件系统的行为和特性，然后基于这些描述进行设计和开发。

ps： 非形式化方法就是是一种开发方法，如用自然语言等这些进行开发，而形式化方法就是用数学方法如公式等去完成开发。