系统架构师：开发方法
软件开发方法是软件开发的方法学，通过软件开发方法研究，提高软件的质量、降低软件的成本。
软件开发方法包括：软件生命周期、软件开发模型、软件重用技术、****及形式化开发方法
一、软件生命周期
GB8566-88中，软件生命周期划分为8个阶段：
1.可行性研究与计划。确定开发此软件的必要性、目标、范围、风险、成本，输出《可行性研究报告》和《软件开发计划》。
2.需求分析。有了目标和范围，需要对需求进行细致的分析，确定软件是什么样的。
3.概要设计。确定了软件的技术蓝图，把需求分析的结果转换为技术层面的设计方案：系统架构、子系统间的关系、接口规约、数据库模型、编码规范等。
4.详细设计。在概要设计的基础上，进行细化。有一些小工程可能省略这个阶段。
5.实现。编码和单元测试。
6.集成测试。也叫组装测试。
7.确认测试。是否与需求一致？是否达成预期的目标？
8.使用和维护。使用过程中，业务需求会变化、环境会变化，新的bug会出现，因此，需要不断维护。
二、软件开发模型
1. 瀑布模型。
瀑布模型认为软件开发是一个阶段化的精确的过程，阶段间有明显的界限和反馈，一个阶段结束会有固定的文档或者代码输入下一个阶段。因此，瀑布模型是面向文档的软件开发模型。
瀑布V模型是瀑布模型的一种变体。工程师们发现，缺陷无法避免，如何阶段都会在软件中引入缺陷，最后的测试也无法保证100%正确，只能争取在交付之前发现更多的缺陷。V模型就是增强了测试的瀑布模型：
瀑布模型是经典的开发模型，具有以下缺点：
一是需求分析阶段是一切活动的基础，设计、实现和验证活动都是从需求分析阶段的结果导出。
二是难以适应变化，阶段之间有强依赖性，后期有变化，前面的所有阶段都需要修改。
三是所有阶段都结束之后，才有交付产品。需要很长时间才会有结果。
瀑布模型是文档驱动的，除了制造软件产品外，也将产生大堆的文档，大部分的文档对客户是没有意义的，整理编写这些文档需要花费大量的人力物力，所以瀑布模型是 重载过程 。
2.演化模型
演化模型是做若干次瀑布模型的迭代，完成一个瀑布周期，又开始另外一个瀑布周期，不断演化、完善。根据不同迭代特点，分为螺旋模型、增量模型和原型法开发。
2.1 螺旋模型
每一个周期包括：需求定义、风险分析、工程实现和评审。
风险分析：风险识别、风险分析和风险控制。
有了风险分析环节，螺旋模型适用于特别庞大而复杂、具有高风险的系统，软件交付时间长。
使用螺旋模型，需要具备相当丰富的风险评估经验和专业知识。
2.2 增量模型
适用于技术架构成熟、风险较低，增量模型缩短初始版本的交付周期，提高用户对系统的可见度。
增量模型有两种策略：
一是增量发布方法。把软件划分为若干不同版本，每一个版本都是完整的系统，后一个版本在前一个版本的基础上进行开发，扩充前一个版本的功能。第一版本往往是系统的核心功能。
二是原型法。原型法的每一次迭代都经过一次完整的生命周期，原型法用于加强用户参与度，提高需求的明确性。一般情况下，后期会抛弃最开始的原型，重新实现完整的系统。
3. 构建组装模型
构件是独立的、自包容的，构件之间通过接口相互协作。
优缺点：
构件的自包容性让系统的扩展变得容易；构件可以重用；可以对软件进行不同颗粒度划分，任务分工清晰，可以并行开发；
构件设计需要经验丰富的架构设计师；性能可能是一个问题；需要熟悉构件，增加了学习成本；第三方构件难以控制，最终会影响软件的质量。
三、统一过程
统一过程（UP）是由Rational公司开发的一种迭代的软件过程，提供了完整的开发过程解决方案，可以降低风险，可以适应各种规模的团队和系统。
横轴是时间主线，纵轴是不同阶段的工作流程，每一个阶段都是相互交叠配合的，但是每一个阶段都是侧重点：
初始阶段重点是业务建模，细化阶段重点是分析设计，构建阶段重点是构建和测试，交付阶段重点是重构、修改、测试和部署。
纵轴是9个核心工作流：业务建模、需求、分析设计、实施、测试、部署、配置和变更管理、项目管理、环境。环境比较难以理解：在软件开发中，需要为各种工作准备相应的工作环境，在工作环境中需要包含必需的工具、活动的指南、活动的流程规范、工作产品的模板、基本的开发设施等。实际的公司很多时候是忽略了环境的，放羊式的管理，除了收获羊毛，啥也收获不了。
UP是特点鲜明的开发模型：
它是一个迭代的二维开发模型；采用不同迭代模式UP可以演变为演化模式或者增量模型；它容易控制软件开发的风险；未经裁剪的UP是一个重载过程。有人也称UP是一个以架构为中心的开发模型。
四、敏捷方法
2001年2月在美国犹他州17位“无政府主义者”共同发表了《敏捷软件开发宣言》，指出：
尽早地、持续地向客户交付有价值的软件；
拥抱变化，即使在开发的后期；
经常交付可工作的软件；
业务人员和开发者紧密合作；
围绕士气高昂的团队进行开发，提供适宜的环境，足够的信任；
面对面沟通；
可以工作的软件是进度首要的度量方式；
可持续地开发；
不断追求优秀的技术和良好的设计；
要简单，尽可能减少工作量；
最好的架构、需求和设计都来自于一个自我组织的团队；
团队要定期总结如何才能更有效率，相应地调整。
以上就是敏捷开发方法，其中极限编程（XP）比较普遍。
XP是一种轻量、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。
XP 的四大价值观：
一是沟通。比如结对编程。
二是简单。够用即好。
三是反馈。客户、管理层、开发团队，通过反馈达成信息的流转。
四是勇气。有勇气面对快速开发，面对可能的重新开发。
XP的十二个最佳实践：
1）计划游戏。快速计划，用户故事。
2）小型发布。持续集成、小步快走。
3）隐喻。寻求共识、发明共享语汇、描述架构。
4）简单设计。设计不应该在编码之前一次性完成。
5）测试先行。不能忽略测试。
6）重构。要有重构的勇气。
7）结对编程。强调人文主义，协作顺畅、知识交流和共享、团队稳定。
8）集体代码所有制。代码属于所有人，公开、民主。
9）持续集成。
10）每周工作40小时。
11）现场客户。把客户请到现场。
12）编码标准。确保代码清晰、便于交流。
除了XP，敏捷开发方法还有特征驱动开发、Scrum、水晶方法等。
五、基于架构的软件设计
ABSD是一种架构驱动方法，它有三个基础：
一是功能的分解。
二是选择架构风格实现质量和业务需求。
三是软件模板的使用。