鲁达 简单介绍
软件开发方法是软件开发方法学。
提供该方法的主要目的是提高软件开发质量、降低软件的成本。
系统学习软件开发方法的步骤，主要有：
1、软件生命周期
2、软件开发模型
3、软件重用技术
4、形式化开发方法。
软件生命周期
软件也有诞生和消亡，指软件自开始构思与研发到不再使用消亡的过程。
对于软件生命周期的划分，不同的标准有不同的规定，如GB8566-88-软件工程国家标准-计算机软件开发规范将软件分为了8个阶段，具体如下：
l 可行性分析与计划
通过可行性研究，来决定开发此软件的必要性，可行性分析中确定软件的目标、范围、风险、开发成本等内容，从而制定初步的软件研发计划。
产出物《可行性分析报告》、《初步软件研发计划》
l 需求分析
确定软件做成什么样
产出物《需求规格说明书》
l 概要设计
确定整个软件的技术蓝图，根据需求内容从技术层面完成设计方案，主要确定系统的架构、子系统之间的关系、接口规约、数据库模型、编码规范等内容。
作为程序员的工作指南，共程序员了解系统的内部原理。
产出物《概要设计说明书》
l 详细设计
从概要设计中进行细化。
产出物《详细设计说明书》
l 研发实现
编码和单元测试。
产出物源代码。
l 集成测试
经过细心的组织，制订集成测试计划。
产出物《测试用例》、《测试报告》
l 确认测试
验证软件是否同需求一致，是否达到了预期目标。
l 使用和维护
使用过程中会产生新的需求。同时软件维护的过程会贯穿整个软件的使用过程。
当使用和维护结束后，软件系统也就自消亡，软件系统的生命周期结束。
软件开发模型
由于软件进行大规模的开发时代，需要遵循一定的开发方法才能取得成功，这些模式化的方法称之为开发模型。
瀑布模型
核心思想：从一个特定的阶段流向下一个阶段。
该模型认为软件开发是一个阶段化的精确的过程。主要由需求分析、总体设计、详细设计、编码与调试、集成测试与系统测试，同时每个阶段都会向上一个阶段进行反馈缺陷，由上一个阶段进行修正。
优点：分段明确，阶段界限明确。
各个阶段会产生完整的文档，故也称之后面向文档的软件开发模型。
当软件需求明确、稳定时，可以采用瀑布模型按部就班地开发软件，反之会暴露需求的缺陷、后期修改代价昂贵、难以控制开发的风险。
瀑布V模型
采用瀑布模型出现的缺陷无法避免，只能争取在交付前发现更多的缺陷。所以测试成为了最关键的环节。【测试质量直接影响到时软件的质量】，由此产生的瀑布V模型，提出更加强调测试。
1、完成需求分析之后进入总体设计外，还指向了系统测试，即将产生同软件需求一致的系统测试用例，同时软件产品是否符合最初的需求将在系统测试阶段得到验证。
2、其它的以此类推。
瀑布V模型除了保持瀑布模式的阶段文档驱动的特点，而且更强调了软件产品的验证工作。
瀑布模型的缺点： 1、所有后续工作来源地需求，如果需求出现不正确，所有事项将出现偏差。 2、后期的维护工作相当繁重，大部分是在修正需求中的问题。 3、瀑布模型难以适应变化，如果后期出现了需求变化，整个系统又得从头开始。 4、所有阶段完成才能交付给用户，用户等待时间长，有可能存在最终用户才发现不能够满足客户的需求。 5、每个阶段会产生一大堆的文档，这些文档对客户没有意义，但却需要花费大量的人力，所以也称瀑布模型为重载过程。 |
演化模型
为若干瀑布的迭代，根据不同的迭代特点可以深化为螺旋模型、增量模型和原型开发。
螺旋模型
将瀑布模型与演化模型结果，不仅体现了两个模型的优点，还强调了其他模型均忽略的风险分析。
螺旋模型包含4个阶段：需求定义、风险分析、工程实现和评审，组成一次迭代。
基于瀑布模型的开发阶段前，引入一个非常严格的风险识别、风险分析和风险控制，把项目拆解成一个一个的小项目，每个项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定。
螺旋模型强调的是风险分析，适用于庞大而复杂、具有高风险的系统，及时地识别、分析、决定采取何种对策。
存在缺点：
1、需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失。
2、过多地迭代次数会增加开发成本，延迟提交时间。
增量模型
主要用于系统的技术架构成熟、风险较低的时候，主要有两种策略：
1、增量发布：首先做好分析和设计工作，然后将系统划分为若干不同的版本，每一个版本都是一个完整的系统。用户可以在很短的时间内就可以得到系统的初始版本并试用，试用过程中进行反馈，降低项目风险，需要注意：
(1) 每一个版本都是完整的、可用的。
(2) 版本间增量要均匀，如一个月一次，不能存在一个版本为1个月，后一个片为4个月的情况。
2、原型法：每一次迭代都经过一次完整的生命周期，当用户很不明确需求和技术架构时，存在很多不可知的因素，可采用原型法。
(1) 初始时针对一般用户需求进行快速地实现，并不考虑算法的合理性或系统的稳定性。
(2) 主要目的是为了获取精确的用户需求，或验证架构的可用性。
后期会抛弃原型法，重新实现完整的系统。
构建组装模型
利用软构建进行拱积木式的开发，即构件组装模型。
定义软件功能后，将对构件的组装结构进行设计，将系统划分成一组构件的集合，明确构建之间的关系。
构件是独立的、自包容的，因此架构的开发也是独立的，构件之间通过接口相互协作 。
优点：
1、构件的自包容性让系统的扩展变得更加容易
2、设计良好的构件更容易被重用，降低软件开发的成本。
3、粒度小时，可分为不同的若干小组，独立完成。
缺点：
1、对构件设计需要经验丰富的架构师，设计不良的构件难以实现构件的优点
2、重用度时，性能会做出让步
3、增加研发人员的学习成本
4、第三方构件的质量难以控制
统一开发过程
统一开发过程（Unified Process, UP）是一种软件过程，是一个优秀的软件开发模型，提供了完整的开发过程解决方案，可以有效地降低软件开发过程的风险。
UP的二维模型
UP是一个二维模型，时间主线就是横轴的阶段，主要经过初始、细化、构建和交付。
纵轴是按不同的阶段进行的主要工作。
任何一个阶段的工作都不是绝对的，都是相互交叠配合的，但每一个阶段都有侧重点：
初始阶段：最重要的工作是界定系统范围，明确系统目的，这一阶段业务建模和需求工作成为重头戏。
细化阶段：开发者需要抽象出软件的逻辑模型，设计出软件的架构，这一阶段分析工作是最主要的工程活动。
构件阶段：开发者完成系统的构建，并进行测试和部署，这一阶段实施和测试是最主要的活动。
交付阶段：这一阶段不可避免地要对软件系统进行重构、修改、测试和部署。
纵轴而言，主要的工作流是：业务建模、需求、分析设计、实施、测试、部署、配置与变更管理、项目管理、环境称为UP的核心工作流。可分为工程活动与管理活动，业务建模、需求、分析设计、实施、测试、部署为工程活动，配置与变更管理、项目管理、环境称为管理活动。(其中环境，也称环境管理，主要用于定义必需的工具、活动的指南、活动的流程规范、工作产品的模板、基本的开发设施等 。
UP的生命周期
生命周期与时间主线阶段一一对应，共有4个里程碑：
1、目标里程碑，对应先启阶段的结束，明确系统的目标和范围即到达该里程碑；
2、架构里程碑，开发者需要确定稳定的系统架构；
3、能力里程碑，已经足够稳定和成熟，并完成Alpha测试；
4、发布里程碑，需要完成系统的Beta测试、完成系统发布和用户培训等工作。
UP的特点
1、每一个阶段都可以进行需求、设计等活动；
2、采用不同的迭代方式，可以演变为演化模型或增量模型；
3、更容易控制软件开发的风险；
4、未经裁剪的UP是一个重载过程；
5、实际应用中，可根据具体问题对UP进行裁剪，从而使其可以适应各种规模的软件和开发团队。
架构师在UP中的活动
1、建立系统架构模型
2、同需求人员和项目管理人员密切协作
3、细化软件架构
4、保持整个架构的概念完整性
还需要定义设计方法、设计指南、编码指南、评审设计等 工作，也有人称UP是一个以架构师为中心的开发模型。
敏捷方法
2001年2月发表《敏捷软件开发宣言》，指出
1、尽早地、持续地向客户交付有价值的软件对开发人员来说最重要的；
2、拥抱变化
3、经常交付可工作的软件
4、业务人员和开发人员紧密合作
5、满足团队人员的需求，并给予足够的信任
6、面对面沟通
7、进度的度量方式
8、可持续的开发
9、不断追求优秀的技术和良好的设计
10、最简单，尽可能减少工作量
11、最好的架构、需求和设计 都来自于一个自我组织的团队
12、团队要定期的总结如何能够更有效率，然后相应的自我调整
基于以上宣言，市场上共提出11种开发方法，如AD、AM、ASD、Crystal、FDD、DSDM、LSD、Scrum、TDD、XBreed、XP。
最常用的是XP（极限编程）。
极限编程
XP为最成熟的一种，XP是一种轻量、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。
1、在更短时间内，更早地提供具体、持续的反馈信息；
2、迭代地进行计划编制，最开始迅速生成一个总体计划
3、依赖自动测试程序来监控开发进度
4、依赖口头交流、测试和源程序进行沟通
5、倡导持续的演化式的设计
6、依赖于开发团队内部的紧密协作
7、尽可能达到程序员短期的利益和项目长期利益的平衡
由价值观、原则、实践和行为4部分组成。
一、四大价值观
XP的核心是其总结沟通、简单、反馈、勇气4大价值观。
1、沟通：项目中许多问题就出在缺乏沟通的开发人员身上，所以要求小组成员之间做到时持续的、无间断的交流。鼓励大家口头交流、通过交流解决问题，提高效率。
2、简单：提倡够用就行，也就是尽量简单化。
3、反馈：开发人员要注重反馈，通过持续、明确的反馈来暴露软件状态的问题。
4、勇气：需要有勇气面对快速开发，面对可能的重新开发。
二、12个最佳实践
XP中集成了12个最佳实践。
1、计划游戏：先快速的制定一个概要设计，随着细化不断的清晰，再逐步完善这份计划，产生的结果是一套用户故事及后续的一两次迭代的概要设计；
2、小型发布：“持续集成、小步快跑”，每一次发布的版本应该尽可能的小，前提条件是每个小版本有足够的商业价值，值得发布。
3、隐喻：寻求共识、发明共享词汇、创新的武器、描述架构。
4、简单设计：认为设计不应该在编码之前一次性完成。
5、测试先行
6、重构：一种对代码进行改进，而不影响功能的实现技术；
7、结对编程：团队协作、知识交流与共享
8、集体代码所有制
9、持续集成
10、每周工作40小时
11、现场客户
12、编码标准
特征驱动开发
FDD方法也是一个迭代的开发模型，FDD的每一步强调质量，不断地交付可运行的软件，并以很小的开发提供精确的项目进度报告和状态信息。
一、FDD的角色定义
三要素：人、过程和技术，6种关键性角色：
1、项目经理：
2、首席架构设计师
3、开发经理
4、主程序员
5、程序员
6、领域专家
二、核心过程
1、开发整体对象模型：业务建模的阶段，强调全系统的完整的面向对象建模，需要领域专家和首席架构师相互配合，完成整体对象模型；
2、构造特征列表：所谓特征指的是一个小的、对客户有价值的功能，采用动作、结果和目标来描述特征，特征的粒度最好把握在两周之内，可以整理出系统的需求。
3、计划特征开发：项目经理构造出特征列表、特征间的依赖关系进行计划，安排开发任务；
4、特征设计：主程序员带着特征小组特征进行详细设计，为后面的构建做准备；
5、构建特征：实现
三、最佳实践
组成FDD的最佳实践包含：领域对象建模、根据特征进行开发、类的个体所有、组成特征小组、审查、定期构造、配置管理、结果的可见性。
软件重用
软件重用
利用已存在的软件元素建立新的软件系统，可以是软件产品、源程序、也可以是文档，甚至是领域知识。软件重用可以提高软件的开发效率、降低软件的开发成本、缩短软件的开发周期、提高软件质量。
重用主要包含：源代码重用、架构重用、应用框架的重用、业务建构的重用、文档及过程的重用、软构件的重用、软件服务的重用。
构件技术
两个重要的特征：自包容和可重用。
形式化方法
指采用严格的数学方法，使用形式化规约语言来精确定义软件系统。