软考-开发方法
导读
随着进入大规模软件开发的时代，软件系统变得非常复杂，也随着开发软件系统数量的增多，前辈们根据一些规则和经验总结出一些开发模型，遵循这些的开发模型会大大提高开发效率，每种开发模型都有特有的思想，本章用来总结和学习现有的一些软件开发模型。本章将介绍软件生命周期、软件开发模型、软件重用技术、逆向工程及形式化开发方法。
随着时间长河不断演进的各种思想，面向过程到面向对象再到面向服务等等，也总结出不同思想下的各种开发模型，例如强调过程，以文档驱动的瀑布模型；强调测试伴随始终，瀑布模型的变种V模型；对瀑布模型根据不同的渐进、迭代和不断深化思想的演化模型，又如根据演化模型增加风险分析所演变的螺旋模型；每个版本都可发布的增量模型；复用思想的构建组装模型、以及迭代思想的统一过程UP。
软件的生命周期
软件的生命周期指软件开始构思到不在使用而消亡的过程，生命周期的阶段划分不同的标准由不同的规定，在GB8566-88《软件工程国家标准-计算机软件开发规范》中将软件的生命周期分为8个阶段，分别为可行性研究与计划、需求分析、概要设计、详细设计、实现、集成测试、确认测试、使用和维护。
可行性研究与计划
在决定是否开发软件之前，首先需要进行可行性研究。通过可行性研究，来确定开发此软件的必要性，并根据可行性研究的结果初步确定软件的目标、范围、风险、开发成本等内容。从而指定出初步的软件开发计划。通过可行性研究，如果确定该软件具有研发的必要，则将产生《可行性研究报告》和《软件开发计划》
需求分析
对软件的需求进行细致的分析，来确定软件要做成什么样的。如果需求分析出现重大偏差，那么软件开发必然会偏离正确的道路，越走越远。尤其是需求分析的错误在开发后期才发现，修正的代价是非常大的。
概要设计
用于确定整个软件的蓝图，负责将需求分析的结果转化为技术层面的设计方案。该阶段需要确认系统架构、各子系统间的关系、结构规约、数据库模型、编码规范等内容，概要设计的结果将作为程序员的工作指南，供程序员了解系统的内部原理，并在其基础上进行详细设计和编码工作
详细设计
编码前的最后设计，在概要设计的基础上进行细化，如类设计。详细设计不是开发过程中必需的阶段，在规模较小、结构简单的系统中，详细设计往往被忽略，也有可能只有部分关键模块进行详细设计
实现
该阶段包括编码和单元测试，单元测试是指对刚刚编写出的一个小程序单元进行测试，如某一过程、方法或函数，有效的单元测试可以大大提高编码质量，降低系统缺陷率
集成测试
也称为组装测试，通过单元测试的程序不意味没有缺陷，当程序单元被集成在一起进行交互时，往往会出现单元测试中没有发现的问题，集成测试必须经过精心的组织，指定集成测试计划、确定如何将这些单元集成到一起，按照什么顺序进行测试，使用哪些测试等问题
确认测试
当完成集成测试后，软件之间的接口错误已经排除，这事需要验证软件是否同需求一致，是否达到预取目标，与集成测试一样，确认测试也需要进行计划和组织，逐步的验证软件系统同需求的一致性，主要是测试是否满足需求
使用和维护
即使通过了单元、集成、确认测试也不可能发现软件系统中全部的缺陷；软件系统的需求也会根据业务的发展变化而变化，因此在软件使用过程中，必须不断对软件进行维护，修正软件中的缺陷，修改软件中已经不能适应最新情况的功能或者增加新的功能，软件维护的过程会贯穿整个软件的使用过程，当使用和维护阶段结束后，软件也就会自然消亡，软件系统的生命周期结束
小结
1. 本章内容是对软件系统生命周期的梳理，需要记住有多少个阶段，每个阶段的作用以及输入和输出
2. 最后说明软件消亡不单单指废弃，废弃不在使用该项目只是消亡的一种，也会有重构的可能，可以理解涅槃重生。
软件开发模型
瀑布模型
主张软件开发是一个阶段化的精确过程，以文档进行驱动每个阶段且有每个阶段明显的界限，将上一个阶段的输出成果作为下一个阶段的目标，如同瀑布一样，从特定的阶段流向下一个阶段，软件过程分为需求分析、总体设计、详细设计、编码与调试、集成测试和系统测试阶段才能被准确的实现，每一个阶段都有回到前一个阶段的反馈线，反馈线的作用是当在后续阶段发现缺陷时，可以把这个缺陷反馈到上一个阶段进行修正。
从图中可以看出，软件开发的阶段划分时明确的，每个阶段到下一个阶段都有明确的分界线、每个阶段结束都会有固定的文档或源程序流入下一个阶段。
需求分析阶段结束后需要产出明确描述软件需求的文档；
总体设计阶段结束后需要产出描述软件总体结构的文档；
详细设计阶段结束后需要产出可以用来编码的详细设计文档；
编码阶段结束后需要产出源代码；
小结
当软件需求明确、稳定时可以采用瀑布模型按部就班的开发软件、但不适用于需求不明确或变化剧烈的情况，瀑布模型往往要到测试阶段才会暴漏出需求的缺陷，造成后期修改代价太大，难以控制开发的风险
V模型
瀑布模型的变种，用于解决瀑布模型发现缺陷时机过晚导致后期修改缺陷代价过大的问题，强调测试贯穿项目始终，期望在交付前能够发现更多的缺陷，对瀑布模型进行小小的改动形成了V模型，模型在编码与调试阶段转了个弯，形成了对称的V字。
V模型同瀑布模型一样需求分析阶段完成后来到总体设计阶段，但除了总体设计外，需求分析还用虚线指向了系统测试，这里指的是将需求分析的结果作为系统测试的准则，既需求分析阶段也将产生同软件需求一致的系统测试，以此类推，总体设计对应了集成测试、详细设计对应了单元测试，V模型不但保持了瀑布模型的阶段式文档驱动的特点，更强调了软件产品的验证工作
小结
关于需求分析指向系统测试，这里并不是实际测试工作，而是指在需求分析阶段可以根据分析后的需求(功能)形成系统测试的准则，也就是文档性质的东西，在写准则的时候就可以排除一些缺陷出来
虽然V模型可以解决一些瀑布模型的一些缺陷，但是还有部分问题无法解决，首先，瀑布模型中，需求分析阶段是一切活动的基础，设计、实现和验证活动都是从需求分析阶段的结果中导出的，一旦需求分析的结果存在偏差，那么后续的活动只能放大这个偏差，在错误的道路上越走越远。事实上，由于用户和开发着的立场、经验、知识与都不相同，不同的人对同一件事物的表述也不同，这就会造成需求分析的结果不可能精确、完整的描述整个软件系统，所以瀑布模型后期的维护工作相当繁重，这个问题是瀑布模型难以克服的。其次，难以适应变化。在瀑布模型中精确的定义了每一个极端的活动和活动结果，而每一阶段都紧密依赖于上一个阶段的结果，如果在软件后期出现需求的变化，整个系统又要从头开始，再次，使用瀑布模型意味着当所哟阶段都结束才能最终交付软件产品，所以在提出需求后需要相当长一段时间的等待才能够看到最终结果，才能发现软件产品究竟能不能满足客户端的需求，最后文档文档驱动型的瀑布模型除了制造出软件产品外还将产生一大堆的文档，大部分的文档对客户没有任何意义，但完成这个对客户没有意义的文档却要花费大量的人力，所以瀑布模型也是一种重载过程。
演化模型
瀑布模型变种之一，瀑布模型看起来很好，随着一个有一个阶段流过，软件系统就被建立起来，可以在实际应用开发中，人们发现很难一次性完全理解用户的需求、设计出完美的架构，开发出可用的系统，由于人的认知本身就是一个过程，这个过程是渐近的不断深化的。对于复杂问题”做两次“肯定能够做的更好，演化模型正是基于这个观点提出，一般情况下一个演化模型可以看作若干次瀑布模型的迭代，当完成一个瀑布模型后，重新进入下一个迭代周期，软件在这样的迭代过程中的到演化、完善。根据不同的迭代特点，可以演变为螺旋模型、增量模型和原型法。
螺旋模型
螺旋模型将瀑布和演化模型结合起来，不仅体现了两个模型的优点，而且还强调了其他模型忽略的风险分析，每一周期都包括需求定义、风险分析、工程实现和评审4个阶段，由这4个阶段进行迭代，每迭代一次软件开发就向前进一个层次。
小结
在”瀑布模型“的每一个开发阶段前，引入一个非常严格的风险识别、风险分析和风险控制。把软件项目分解为一个个小项目，每个小项目都表示一个或多个主要风险，知道所有的主要风险因素都被确定。
强调风险分析，使得开发人员和用户对每个演化层出现的风险都有所了解，继而做出应用的反应，因此特别适用于庞大而复杂具有高风险的系统，支持用户需求的动态变化，为用户参与软件开发的所有关键决策提供方便，有助于提高目标软件的适应能力，为项目管理人员即使调整管理决策提供了便利，从而降低了软件开发风险。但是也有其缺点，采用螺旋模型需要具有相当丰富的风险评估经验和专业知识。在风险较大的项目开发中，如果没有及时标识风险，势必会造成重大损失。过多的迭代次数会增加开发成本，延迟提交时间。
增量模型
演化模型的另一种形式。在系统的技术架构成熟、风险较低的时候，可以采用增量的方式进行系统开发，这样可以提前进行集成测试和系统测试，羧酸初始版本的发布周期，提高用户对系统的可见度。
增量模型通常由两种策略。
增量发布，首先做好系统的分析和设计工作，将系统划分为若干不同的版本，每一个版本都是完整的系统，后一版本以前一版本为基础进行开发，扩充前一版本的功能，在这种策略中第一版往往是系统的核心功能，可以满足用户最基本的需求，随着增量的发布，系统的功能逐步丰富完成。用户在很短的时间就会获得初始版本并进行试用，后续将试用产生的问题进行分析后由下一版本进行解决，降低系统风险，但需要注意每一个版本都是完整的、可用的。版本之间的增量要均匀。
原型法，与增量发布不同，原型法每一次迭代都经过一个完整的生命周期。当用户需求不明确或技术架构存在很多不确定因素时，可以采用原型法。在初始的原型中，针对一般性的用户需求进行快速实现，并不考虑算法的合理性或系统的稳定性，主要是用于获得精确的用户需求或验证架构的可用性，一般情况会在后面的开发中抛弃这个原型，重新实现完整系统，原型法由分为演化型原型与抛弃型原型
构件组装模型
随着软构建技术的发展，尝试利用软构件进行搭积木式的开发，即构件组装模型。在构建组装模型中，当经过需求分析定义出软件功能后，将对构件的组装结构进行设计，将系统划分为一组构件的集合，明确构件之间的关系。在确定了系统构建后，则将独立完成每个构件，这时既可以开发软件构件，也可以复用已有构件，当然可以购买或选用第三方的构件，构建是独立的，自包容的，因此架构的开发也是独立的，构件之间通过接口互相协作。
构件组装模式的优点有很多，构件的自包容性让系统的扩展变得更加容易；设计良好的构件可以更容易重用降低开发成本；构建的粒度较小，因此安排开发任务更加灵活，可以将开发团队分为若干组，并行的独立开发构件。 当然鱼和熊掌不可兼得，也有很明显的缺点，对构件的设计需要经验丰富的架构设计师，设计不良的构件难以实现构件的优点，降低构件的重用度；考虑软件重用度时，往往会对其他方面做出让步，比如性能；使用构件组装应用程序时，要求程序员熟练的掌握构件，增加了学习成本，第三方构件库的质量会影响到软件的质量。
统一过程UP
统一过程模型是一种迭代的软件过程，提供了完整的开发过程解决方案，可以有效的降低软件开发过程的风险，经过裁剪的UP可以适应各种规模的团队和系统，强调用例驱动。
1. UP的二维模型
对于UP而言，时间主线就是横轴的阶段，随着时间的流逝，软件开发活动总要经过初始、细化、构建和交付这4个阶段方能完成，纵轴的工作流程则描述了在不同的阶段需要进行的主要工作。
在初始阶段，软件组织需要进行大量的调研，对软件进行业务建模、需求。
通过一些设计用来验证建模的合理性，通过一些实施甚至测试和部署的工作用于验证需求和设计的工作及开发系统原型。
配置与变更管理、项目管理、环境是任何阶段都是不可缺少的。
从模型中可以看出UP的迭代特点。任何一个阶段的工作都是互相交叠配合的，但每个阶段都有其侧重点。
初始阶段： 界定系统范围、明确系统目的。 业务建模和需求工作
细化阶段： 抽象软件逻辑模型、设计软件架构（体系结构）。 分析设计
构建阶段： 基本完成系统的构建，使之称为一个完整的实体。 实施和测试
交付（转移）阶段： 软件系统需求已经完全成熟或产品化或进入下一个版本。 重构、修改、测试和部署
每个阶段中系统的推进不是一蹴而就的。细化、构件、交付可以根据实际的需要进行划分更多的小阶段来完成。
对于纵轴而言。业务建模、需求、分析设计、实施、测试、部署、配置与变更管理、项目管理、环境称为UP的9个核心工作流，可以对着9个工作流进行简单的分类用于帮助理解，业务建模、需求、分析设计、实施、测试和部署属于工程活动，配置与变更管理、项目管理、环境属于管理活动
2. UP的生命周期
UP模型的时间主线是阶段，UP的生命周期与每个阶段一一对应，在UP的声明周期有4个里程碑。在经历过4个里程碑后可以认为是一个完整的生命周期，可以关闭该产品的开发，或者迭代下一个版本。
目标里程碑。对应着初始阶段的结束，当开发者可以明确软件系统的目标和范围即表示到达该里程碑。
架构里程碑。开发者确定稳定的系统架构时表示到达了该里程碑。
能力里程碑。当系统已经足够稳定成熟并完成Alpha测试后，认为到达了该里程碑。
发布里程碑。当完成系统测试、系统发布和用户培训后就到达了该里程碑。
3. UP的特点
3.1. UP是一个迭代的二维开发模型。在生命周期的每一个阶段都可以进行需求、设计等活动。UP提供了迭代的生命周期并给出了每一阶段的迭代指南。
3.2.采用不同迭代的UP可以演变成演化模型或增量模型。
3.3 UP的迭代特点是的更容易控制软件开发的风险。
3.4 UP是一个迭代的开发模型，但UP本身不属于敏捷开发，相反一般而言，未经裁剪的UP是一个重载过程。
3.5 在实际应用中可以根据具体问题对UP进行裁剪，从而使其可以适应各种规模的项目和团队。
4. 架构师在UP中的活动
在UP中架构师除了需要建立系统架构模型外还需要，同需求人员和项目管理人密切协作、细化软件架构、保持整个架构的概念完整性。具体的说架构师不但需要设计系统架构还需要定义设计方法、设计指南、编写指南、评审设计等工作，UP也有人称为以架构为中心的模型。
RAD 快速应用开发
增量时的软件开发过程模型，强调极短的开发周期。瀑布模型的高速变种，通过大量使用可复用构件，采用基于构件的建造方式赢得快速开发。如果需求明确且约束了项目的范围，利用该模型可以很快的创建出功能完善的信息系统。其流程从业务建模开始，随后是数据建模，过程建模，应用生成，测试及交付。
业务建模依靠DFD数据流图。数据建模依靠E-R图。过程建模依靠STD状态转换图。应用程序生成，利用第四代语言（4GL）写出处理程序，重用已有构件或创建新的可重用构件，利用环境提供的工具自动生成并构造出整个应用系统。测试与交付，由于大量的重用，一般只做总体测试，但新创建的构件还是会单元集成测试。
并不是所有应用都适合RAD，首先RAD对模块化要求比较高。要求高性能并必须通过调整接口使其适应系统构建才行时RAD方法也可能不奏效。开发者和客户必须在极短的时间完成一系列需求分析，任何一方配合不当都可能导致失败。RAD只适用于信息系统开发，不适合技术风险较高的情况
敏捷开发
XP极限编程
一种轻量、高效、低风险、柔性、可预测、科学的软件开发方式。特点是在更短的周期内获得具体、持续的反馈信息；在项目的初始阶段生成一个总体计划后续对这个计划不断完善；依赖于自动测试程序来监控开发进度并及早的捕获缺陷；依赖口头交流、测试和源程序进行沟通；倡导持续的、演化式的设计；依赖于开发团队内部的紧密协作；尽可能可能达到程序员短期利益和项目长期利益的平衡。由价值观、原则、时间和行为四个部分组成，彼此相互依赖、关联并通过行为贯穿整个生命周期。
价值观
四大价值观沟通、简单、反馈、勇气作为XP的基础，也是灵魂。沟通，相对于完整的流程和面面俱到的文档、报表、计划XP更倾向于持续的、无间断的交流，鼓励口头交流通过交流解决问题，提高效率。简单，相较于传统开发方法的预先规划更倾向与“够用就好”不要做过度设计。反馈，注重反馈，提倡持续、明确的反馈用来暴漏软件问题，也是XP能尽早捕获缺陷的关键。勇气，提倡开发团队面对需求变化时处于积极向上的心理状态，勇起可以来源于沟通、简单、反馈。
最佳实践
在XP中集成了12个最佳实践。计划游戏、小型发布、隐喻、简单设计、测试先行、重构、结对编程、集体代码所有制、持续集成、每周工作40小时、现场客户、编码标准。
计划游戏计划游戏的主要思想就是先快速地制定一份概要的计划，然后，随着 项目细节的不断清晰，再逐步完善这份计划。计划游戏产生的结果是一套用户故事及后续的一两次迭代的概要计划。小型发布XP 方法秉承的是“持续集成、小步快走”的哲学思维，也就是说每一次发布的版本应该尽可能地小，当然前提条件是每个版本有足够的商业价值，值得发布。由于小型发布可以使得集成更频繁，客户获得的中间结果越频繁，反馈也就越频繁，客户就能够实时地了解项目的进展情况，从而提出更多的意见，以便在下一次迭代中计划进去，以实现更高的客户满意度。隐喻相对而言，隐喻比较令人费解。根据词典中的解释是：“一种语言的表达手段，它用来暗示字面意义不相似的事物之间的相似之处”。隐喻常用于四个方面：寻求共识、发明共享语汇、创新的武器、描述架构。如果能够找到合适的隐喻是十分快乐的，但并不是每一种情况都可以找到恰当的隐喻，因此，没有必要去强求，而是顺其自然。简单设计强调简单的价值观，引出了简单性假设原则，落到实处就是“简单设计”实践。这个实践看上去似乎很容易理解，但却又经常被误解，许多批评者就指责 XP 忽略设计是不正确的。其实，XP 的简单设计实践并不是要忽略设计，而是认为设计不应该在编码之前一次性完成，因为那样只能建立在“情况不会发生变化”或者“我们可以预见所有的变化”之类的谎言的基础上。测试先行对于有些团队而言，有时候程序员会以“开发工作太紧张”为理由，继而忽略测试工作。这样，就导致了一个恶性循环，越是没空编写测试程序，代码的效率与质量越差，花在找缺陷、解决缺陷的时间也越来越多，实际产能大大降低。由于产能降低，因此时间更紧张，压力就更大。重构重构是一种对代码进行改进而不影响功能实现的技术，XP 需要开发人员在 “闻到代码的坏味道”时，就有重构代码的勇气。重构的目的是降低变化引发的风险、使得代码优化更加容易。结对编程从 20 世纪 60 年代开始，就有类似的实践在进行，长年以来的研究 结果给出的结论是，结对编程的效率反而比单独编程更高。一开始虽然会牺牲一些速度，但慢慢地，开发速度会逐渐加快。究其原因，主要是结对编程大大降低了沟通的成本，提高了工作的质量。结对编程技术被誉于 XP 保证工作质量、强调人文主义的一个最典型的实践，应用得当还能够使开发团队协作更加顺畅、知识交流与共享更加频繁、团队稳定性也会更加牢固。集体代码所有制由于 XP 方法鼓励团队进行结对编程，而且认为结对编程的组合应该动态地搭配，根据任务的不同、专业技能的不同进行最优组合。因此，每一个人都会遇到不同的代码，代码的所有制就不再适合于私有，因为那样会给修改工作带来巨大的不便。所谓集体代码所有制，就是团队中的每个成员都拥有对代码进行改进的权利，每个人都拥有全部代码，也都需要对全部代码负责。同时，XP 强调代码是谁破坏的（修改后出现问题），就应该由谁来修复。集体代码所有制是 XP 与其他敏捷方法的一个较大不同，也是从另一个侧面体现了 XP 中蕴含的很深厚的编码情节。持续集成在前面谈到小型发布、重构、结对编程、集体代码所有制等最佳实践的时候，多次提到“持续集成”，可以说持续集成是这些最佳实践的基本支撑条件。每周工作 40 小时这是最让开发人员开心、管理者反对的一个最佳实践了，加班、再加班早已成为开发人员的家常便饭，也是管理者最常使用的一种策略。而 XP 方法认为，加班最终会扼杀团队的积极性，最终导致项目的失败，这也充分体现了 XP 方法关注人的因素比关注过程的因素更多一些。不过，有一点是需要解释的，“每周工作 40 小时”中的“40 ”不是一个绝对数，它所代表的意思是团队应该保证按照“正常的时间”进行工作。现场客户为了保证开发出来的结果与客户的预想接近，XP 方法认为最重要的是需要将客户请到开发现场。就像计划游戏中提到过的，在 XP 项目中，应该时刻保证客户负责业务决策，开发团队负责技术决策。因此，在项目中有客户在现场明确用户故事，并做出相应的业务决策，对于 XP 项目而言有着十分重要的意义。编码标准拥有编码标准可以避免团队在一些与开发进度无关的细枝末节问题上发生争论，而且会给重构、结对编程带来很大的麻烦。不过，XP 方法的编码标准的目的不 是创建一个事无巨细的规则列表，而是要能够提供一个确保代码清晰，便于交流的指导方针。有句经典名言“1+1>2”最适合表达 XP 的观点， Kent Beck 认为， XP 方法的最大价值在于，在项目中融会贯通地运用这 12 个最佳实践，而非单独使用。当然，可以使用其中的一些实践，但这并不意味着就应用了 XP 方法。 XP 方法真正能够发挥其效能，就必须完整地运用 12 个实践。
FDD 特征驱动开发
一种迭代的开发模型、每一步都强调质量，不断的交付可运行的软件，并以很小的开发提供精确的项目进度报告和状态信息。所谓特征是指一个小的、对客户有价值的功能。
角色定义
定义6种角色。项目经理，开发的组织者，作为团队的保护屏障，主要负责与开发团队外人员（高层领导、人事）的沟通工作。首席架构设计师，负责系统架构的设计。开发经理，负责团队日常的开发，解决开发中出的技术或资源冲突。主程序员，带领小组完成特征的详细设计和构建工作。程序员，按照特征开发计划完成开发。领域专家，对业务领域精通的人，一般由客户、系统分析员担任，主要解答指导技术人员对业务产生的疑惑或业务方向。
开发整体对象模型
也就是业务建模阶段，强调系统的、完整的面向对象建模，有助于把握整个系统，而不仅仅关注系统的若干个点。在这个阶段，领域专家和首席架构师互相配合，完成整体对象模型。
构造特征列表
构造一个完整的特征列表。采用动作、结果和目标来描述特征。特征的粒度最好可以在两周之内实现，在这一阶段可以整理出系统的需求。
计划特征开发
项目经理根据构造出的特征列表、特征间的依赖关系进行计划，安排开发任务。
特征设计
主程序员带领特征小组对特征进行详细设计，为后面的构建做准备。
特征构建
特征构建和特征设计这两个阶段合并起来可以看成特征的实现阶段，这两个阶段反复的迭代、直到完成全部的开发。
最佳实践
领域对象建模、根据特征开发、类的个体所有、组成特征小组、审查、定期构造、配置管理、结果的可见性。
类的个体所有
几乎所有的开发模型都是代码共有，程序员们负责开发系统中的全部代码，并通过配置管理和变更控制来保持代码的一致性。在 FDD 中，将类分配给特定的任何小组，分配给 A 成员的代码将全部由 A 来维护，除 A 外的角色都不能修改它，只能使用它。这样做当然有它的优点：个人对所分配的类很容易保持概念的完整性；开发类代码的人肯定是最熟悉这个类的主人；而对这个类的支配感会促使开发人员产生自豪感，从而更出色地完成任务。不过 FDD 也提到了类个体所有的缺陷：项目中的依赖关系增强、当 A 需要 B 修改他自己的类时，必须等待 B 完成修改才能使用；类的个体所有增加了员工离职的损失。面对这些优点和缺陷，显然 FDD 认为类的个体所有对系统开发更有帮助。
审查
审查也是 FDD 中很具特色的一项实践。不少人都认为审查是非常严格的软件过程所特有的，因为进行审查不但要花费不少的人力和时间，对审查者本身的素质也有要求。然而在 FDD 中，明确地将审查作为一项最佳实践提出。审查是一种很有效的发现缺陷的手段，但经常被忽视，国内的软件组织中很少有严格审查制度保证软件质量。有效的审查可以发现很多潜在的问题，而这些问题往往是无法通过测试发现的，例如建模、需求和设计期的缺陷。这些潜在的缺陷大多要到系统测试甚至发布后才能发现，修正这些缺陷的代价是很大的。
Scrum 并列争球
增量、迭代的开发过程，首先有了解它的组成概念，BackLog 管理产品的需求，可以理解成需求列表。Sprint 一个开发迭代周期。计划会议 ，讨论需求的排序。Sprint BackLog ，经过讨论、分析、估算后得到的任务列表。Scrum的流程为，首先根据商业价值对需求排序后经过计划会议进行讨论、分析、估算得到任务列表，在根据任务列表分配给每个开发小组或人员且每天经过短暂的站会进行对任务进度的汇报，整个实现周期大概在2~4周左右就可以得到一个可交付的产品增量。
五个活动
Scrum 主要包括：产品待办事项列表梳理、Sprint 计划会议、每日Scrum 会议、Sprint 评审会议、Sprint 回顾会议等五个活动
产品待办事项列表梳理产品待办事项通常会很大，也很宽泛，而且想法会变来变去、优先级也会变化，所以产 品待办事项列表梳理是一个始终贯穿整个 Scrum 项目的活动。该活动包含但不限于以下的内容：保持产品待办事项列表有序、把看起来不再重要的事项移除或者降级、增加或提升涌现出来的或变得更重要的事项、将事项分解成更小的事项、将事项归并为更大的事项、对事项进行估算。产品待办事项列表梳理的一个最大好处是为即将到来的几个 Sprint 做准备。为此，梳理时会特别关注那些即将被实现的事项。需要考虑不少因素，这包括但不限于以下的内容：理想情况下，下一个 Sprint 的备选事项都应该提升“商业价值”。开发团队需要能够在一个 Sprint 内完成每一个事项。每个人都需要清楚预期产出是什么。产品开发决定了，有可能需要其他的技能和输入。因此，产品待办事项列表梳理最好是所有团队成员都参与的活动，而不单单是产品负责人。Sprint 计划会议每个 Sprint 都以 Sprint 计划会议作为开始，这是一个固定时长的会议，在这个会议中，Scrum 团队共同选择和理解在即将到来的 Sprint 中要完成的工作。整个团队都要参加 Sprint 计划会议。针对排好序的产品待办事项列表（ Product Backlog ），产品负责人和开发团队成员讨论每个事项，并对该事项达成共识，包括根据当前的“完成的定义”，为了完成该事项所需要完成的所有事情。所有的 Scrum 会议都是限定时长的。 Sprint 计划会议推荐时长是 Sprint 中的每周对应两小时或者更少（例如，一个 Sprint 包含 2 个星期，则 Sprint 计划会议时长应为 4 个小时或者更少）。因为会议是限制时长的 ,Sprint 计划会议的成功十分依赖于产品待办事项列表的质量。这就是产品待办事项列表梳理十分重要的原因。在 Scrum 中， Sprint 计划会议有两部分：第一部分：需要完成哪些工作?在会议的第一部分，产品负责人向开发团队介绍排好序的产品待办事项，整个 Scrum 团队共同理解这些工作。Sprint 中需要完成的产品待办事项数目完全由开发团队决定。为了决定做多少，开发团队需要考虑当前产品增量的状态，团队过去的工作情况，团队当前的生产能力，以及排好序的产品待办事项列表。做多少工作只能由开发团队决定。产品负责人或任何其他人，都不能给开发团队强加更多的工作量。通常 Sprint 都有个目标，称作 Sprint 目标。这将十分有效地帮助大家更加专注于需要完成的工作的本质，而不必花太多精力去关注那些对于我们需要完成的工作并不重要的小细节。第二部分：如何完成工作？在会议的第二部分里，开发团队需要根据当前的“完成的定义”一起决定如何实现下一个产品增量。他们进行足够的设计和计划，从而有信心可以在 Sprint 中完成所有工作。前几天的工作会被分解成小的单元，每个工作单元不超过一天。之后要完成的工作可以稍大些，以后再对它们进行分解。决定如何完成工作是开发团队的职责，决定做什么则是产品负责人的职责。在计划会议的第二部分，产品负责人可以继续留下来回答问题，以及澄清一些误解。不管怎样，团队应该很容易找到产品负责人。Sprint 计划会议的产出。Sprint 计划会议最终需要 Scrum 团队对 Sprint 需要完成工作的数量和复杂度达成共识，并预期在一个合理的条件范围内完成它们。开发团队预测并共同承诺他们要完成的工作量。总而言之：在 Sprint 计划会议中，开发团队和产品负责人一起考虑并讨论产品待办事项，确保他们对这些事项的理解，选择一些他们预测能完成的事项，创建足够详细的计划来确保他们能够完成这些事项。 最终产生的待办事项列表就是“ Sprint 待办事项列表（ Sprint Backlog ）”。每日 Scrum 会议开发团队是自组织的。开发团队通过每日Scrum 会议来确认他们仍然可以实现 Sprint的目标。这个会议每天在同样的时间和同样的地点召开。每一个开发团队成员需要提供以下三点信息：从上一个每日Scrum 到现在，我完成了什么；从现在到下一个每日Scrum，我计划完成什么；有什么阻碍了我的进展。 每日 Scrum 中可能有简要的问题澄清和回答，但是不应该有任何话题的讨论。通常，许多团队会在每日Scrum 之后马上开会处理他们遇到的任何问题。 每日Scrum 既不是向管理层汇报，也不是向产品负责人或者 ScrumMaster 汇报。它是一个开发团队内部的沟通会议，来保证他们对现状有一致的了解。只有 Scrum 团队的成员，包括 ScrumMaster 和产品负责人，可以在会议中发言。其他感兴趣的人可以来旁听。在必要时，开发团队会基于会议中的发现重新组织他们的工作来完成 Sprint 的目标。每日Scrum 是 Scrum 的一个关键组成部分，它可以带来透明性 , 信任和更好的绩效。它能帮助快速发现问题，并促进团队的自组织和自立。所有 Scrum 会议都是限定时长的。每日Scrum 通常不超过 15 分钟。Sprint 评审会议Sprint 结束时， Scrum 团队和相关人员一起评审 Sprint 的产出。 Sprint 评审会议的推荐时长是 Sprint 中的每一周对应一个小时（例如，一个 Sprint 包含 2 个星期，则 Sprint 评审会议时长为 2 个小时）。讨论围绕着 Sprint 中完成的产品增量。由于 Sprint 的产出会涉及一些人的“利益”， 因此一个明智的做法是邀请他们参加这个会议，这会很有帮助。这个会议是个非正式的会议, 帮助大家了解我们目前进展到哪里，并一起讨论我们下一步如何推进。每个人都可以在Sprint 评审会议上发表意见。当然，产品负责人会对未来做出最终的决定，并适当地调整产品待办事项列表 Product Backlog 。团队会找到他们自己的方式来开 Sprint 评审会议。通常会演示产品增量 , 整个小组也会经常讨论他们在 Sprint 中观察到了什么、有哪些新的产品想法出现。他们还会讨论产品待办事项列表的状态、可能的完成日期以及在这些日期前能完成什么。Sprint 评审会议向每个人展示了当前产品增量的概况。因此，通常都会在 Sprint 评审会议中调整产品待办事项列表。Sprint 回顾会议在每个 Sprint 结束后 ,Scrum 团队会聚在一起开 Sprint 回顾会议 , 目的是回顾一下团队在流程人际关系以及工具方面做得如何。团队识别出哪些做得好, 哪些做得不好 , 并找出潜在的改进事项, 为将来的改进制定计划。 Sprint 回顾会议的推荐时长是 Sprint 中的每一周对应一个小时（例如，一个 Sprint 包含 2 个星期，则 Sprint 回顾会议时长为 2 个小时）。Scrum 团队总是在 Scrum 的框架内，改进他们自己的流程。
五个价值观
承诺 — 愿意对目标做出承诺。专注 — 把你的心思和能力都用到你承诺的工作上去。开放 — Scrum 把项目中的一切开放给每个人看。尊重 — 每个人都有他独特的背景和经验。勇气 — 有勇气做出承诺，履行承诺，接受别人的尊重
水晶方法Crystal
一种提倡“机动性”的方法，包含具有共性的核心元素，每个都含有独特的角色、过程模式、工作产品和实践。一组经过证明、对不同类型项目都非常有效的敏捷过程。透明水晶、黄水晶、橙水晶、红水晶。一般透明水晶使用的比较多，适合小团队来进行敏捷开发，人数在6人一下为宜。
透明水晶有七大体系特征。经常交付，任何项目、无论大小、敏捷程度，其最重要的一项特征就是每过几个月就向用户交付已测试的运行代码。反思改进，顾名思义在开发的过程中总结反思。渗透式交流，通常团队在同一个工作室内工作，若由一名成员提出问题，其他成员可以选择关注或不关注的态度，加入到这个问题的讨论中。个人安全，当指出困扰的问题时，不用担心收到报复。焦点，确定首先做什么然后安排时间以平和的心态开展工作。与专家用户建立方便的联系，可以给团队提供、成品质量的快速反馈，关于设计理念的快速反馈，最新的（用户）需求。配有自动测试，开发人员在代码修改后就可以进行自动测试，能够发现从存在的一些bug，可以及时尽早的进行修改，节省时间提高效率。
软件重用
软件重用是一个重要软件开发方法，至今重用技术还不够成熟，离理想的软件工厂还有很长的路要走，但现有的一些重用技术例如中间件、应用服务器等已经改变了开发过程
软件产品和其他的产品不同，是抽象的，一旦产生就可以无限制的复制，因此重复利用软件产的意义重大，可以节省大量的人力物力。指利用已经存在的软件元素建立新的软件系统，其中软件元素可以是软件产品、源程序、文档、设计思想甚至是领域知识。可以提高软件的开发效率、降低软件的开发成本、缩短软件的开发周期，提高软件质量。
源代码重用。这是最简单也是最常见的重用形式，但由于软件系统的复杂性，很难大规模地重用已有源代码。架构重用。架构重用也很常见，随着软件架构风格和设计模式的推广和应用，架构重用已经对软件开发产生了重大的影响。应用框架的重用。随着软件技术的发展，应用框架的重用变得越来越普遍，很多成熟的软件公司都建立了自己的开发框架。在开源社区中，世界各地的技术爱好者也在不断地推出应用了各种新技术的开发框架，例如，应用了 AOP（ Aspect Oriented Programming ，面向方面编程）技术的 Spring 等。业务建模的重用。虽然不同的软件的业务领域各自不同，但人们还是总结出了一些常见领域的建模方法，重用这些领域模型可以降低因领域知识不足而造成的需求风险。文档及过程的重用。软件文档和软件过程也是软件开发中不可或缺的元素，有效地重用这些文档和过程也有助于提高开发效率和软件质量、降低开发成本。软构件的重用。软件服务的重用。随着 Web 服务的提出，人们越来越关注服务的重用。 SOA（Service-Oriented Architecture ，面向服务的架构）提出了面向服务的软件架构，并定义了相应的标准。但 SOA 还不够成熟，相信这一领域在未来的几年中还将取得更大的进展。
ABSD 基于架构的软件设计
一种架构驱动方法，即强调业务、质量和功能需求的组合驱动架构设计，使用该方法时设计活动可以从项目总体功能框架明确就开始，这意味着修去获取和分析还没有完成就开始了软件设计。
三个基础，第一个基础功能分解，使用已有的基于模块的内聚和耦合技术；第二个基础是通过选择架构风格来实现质量和业务需求。第三个基础是软件模板的使用，利用了一些软件系统的结构。
ABSD是递归且迭代的，每一个步骤都是清晰定义的。因此，不管设计是否完成，架构总是清晰的，有助于降低架构的随意性。
视角和视图，从不同的角度来检查，所以可以产生不同的视图。用例用来捕获功能需求，特定场景用来捕获质量需求。
在ABSD中，必须记录所有做出的决策以及这些决策的原理，有助于决策的可跟踪性和决策评审。
ABSD在生命周期中应用
上面已经说到，ABSD方法在项目总体功能框架明确就可以开始设计活动了，而不需要等待需求分析阶段全部完成后才开始，所以可以理解该方法存在于需求分析与实际设计之间做一些工作，下面以ABSD方法来分析输入与输出，首先假设根据需求分析阶段获取抽象功能需求包括变化或通用的需求、用例（实际功能需求）、抽象的质量和业务需求、质量因素（实际质量和业务需求）、架构选项、约束。通俗理解本段的说明的就是ABSD在属于它的生命周期阶段做了什么。
抽象功能需求，根据某种抽象需求上获取功能需求，为之后详细需求做分类。
用例，一个或多个最终用户与系统之间的交互的具体表述，用例很容易找到和创建并且很有可能会有成千上百个用例，但是架构设计阶段需要我们分析用例，所以必须限制用例的数量，在架构设计阶段只有重要的用例才有用。对创建的用例进行分组、设置优先级、已便筛选出最重要的用例，剩下次优先级的用例可以在设计阶段创建。
抽象的质量和业务需求，将构件系统的质量和业务需求编号，每个质量属性都包含一个特定的刺激（触发点），以及希望得到的响应（期望的结果），质量需求要尽量具体化。
架构选项，列举所有可能的选项，不做真正的决策，只要有符合某一方面需求的架构都可以提出来，举例的架构可以来源于设计师的经验、书籍等。
质量场景，如同用例使功能需求具体化，质量场景可以使质量需求具体化，和用例一样质量场景也很容易找到和创建，所有也必须对质量场景进行分组、设置优先级，只为选出最重要的质量场景
约束，约束是一个前置的设计决策，设计过程本身包含决策。某些决策可以直接由业务目标导出而无需考虑对设计的影响。收到业务或其他原因必须要做的决策就是约束。
ABSD软件开发模型
该模型把整个ABSD的过程分为架构需求、架构设计、架构文档化、复审、实现、演化等6个子过程。
1. 架构需求
指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望，架构需求受技术环境和架构设计师的经验影响。该过程主要获取用户需求，标识系统中所要用到的构件。如果之前维护了类似系统架构的需求库，就可以从需求库中取出，加以修改，以节省需求获得的时间，减少重复劳动，提高开发效率。该阶段主要用来激发和调整设计决策，不同的视图被用来表达与质量目标有关的信息。
1.1 需求获取
架构需求一般来自三个方面，系统的质量目标、系统的业务目标和系统开发人员的业务目标。该阶段主要定义开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足业务上的功能需要。与此同时，还要获得软件质量属性，满足一些非功能需求。
1.2 标识构件
该过程又有三个小过程，生成类图；对类进行分组，在生成的类图基础上，使用一些标准对类进行分组可以大大简化类图结构，使之更清晰。一般关系与其他隔离的类形成一个组，泛化、关联、聚合、组合关系的类组成一个附加组；把类打包成构件，把第二部得到的类簇打包成构件，这些构件可以分组合并成为更大的构件。
1.3 需求评审
组织一个由不同代表（分析人员、客户、测试、设计）组成的小组，对架构需求及相关构件进行详细的审查，审查主要内容包括获取的需求是否真实反馈了用户的要求、类的分组是否合理，构件合并是否合理等。
2. 架构设计
是一个迭代的过程，如果要开发的系统能够从已有的系统中导出大部分则可以使用已有系统的设计过程。
2.1 提出软件架构模型
在建立架构的初期，选择一个合适的架构风格是首要的。在这个风格基础上，开发人员通过架构模型，可以获得架构属性的理解。虽然现在这个模型是理想化的（其中某个部分可能错误的表达了应用的特征），但是该模型为将来的实现和演化过程建立了目标。
2.2 把已标识的构件映射到软件架构中
把在架构需求阶段已标识的构件映射到架构中，将产生一个中间架构，这个中间结构只包含那些能够明确时候架构模型的构件。
2.3 分析构件之间的互相作用
为了将已标识的构件集成到架构中，必须认真分析这些构件之间的互相作用和关系。
2.4 产生软件架构
一旦决定了关键的构件之间的关系和相互作用，就可以在第二阶段得到的中间架构的基础上进行细化。
2.5 设计评审
一旦设计了软件架构，必须邀请独立于系统开发的外部人员对架构进行评审。
3. 架构文档化
绝大多数的架构都是抽象的，由一些概念上的构件组成，例如 “层”的概念在任何程序设计语言中都不存在。因此要让系统分析师和程序员去实现架构，还必须要把架构进行文档化。文档是系统演化的每一个阶段，系统设计与开发人员的通信媒介，是为验证架构设计和提炼或修改这些设计所执行预先分析的基础
4. 架构复审
架构设计、文档化和复审是一个迭代过程。从这个方面来讲，在一个主版本的软件架构分析之后，要安排一次由外部人员（用户代表/领域专家）参加的复审。
5. 架构的实现
通过以”实体“来显示出一个软件架构，既要符合架构所描述的结构性设计决策、分割成规定的构件、按规定方式互相交互。
分析与设计、构件实现、构件组装、系统测试是架构的实现过程。整个实现过程是以复审后的文档化架构说明书为基础，每个构件必须满足软件架构中说明的对其他构件的责任。这些决定即实现的约束实在系统级或项目范围内做出的，每个构件上工作的实现者是不可见的。
在架构说明书中，已经定义了系统中构件与构件之间的关系。因此在架构层次上，构件接口约束是对外唯一的代表了构件，所以可以在构件库中查找符合接口约束的构件，必要时开发新的满足要求的构件。然后按照设计提供的结构，通过组装支持工具把这些构件的实体组装起来，完整整个软件系统的链接与合成。最后就是测试，对单个构件的功能性测试和被组装应用的整体功能、性能测试。
6. 架构演化
在架构的开发中，最终用户的需求可能还会变动。在软件开发完毕后，交付运行后，因其他的原因导致需求变化，针对这种情况就必须相应的修改软件架构，以适应新的软件需求。架构演化是使用系统演化步骤去修改应用以满足新的需求。
6.1 需求变化归类
首先必须对用户需求的变化进行归类，使变化的需求与已有构件对应。对找不到对应构件的变动，也要做好标记，在后续工作中，将创建新的构件，以对应这部分变化的需求。
6.2 架构演化计划
在改变原有结构之前，开发组织必须制订一个周密的架构演化计划，作为后续演化开发工作的指南。
6.3 构件变动
在修改、增加或删除构件的演化计划的基础上，开发人员可根据在第一步得到的需求变动的归类情况，决定是否修改或删除、增加构件，最后对修改或增加的构件测试。
6.4 更新构件间相互作用
随着更新、删除或新增构件，构件之间的控制流必须得到更新，不然后续乱套了。
6.5 构建组装与测试
完成整个软件系统的链接与合成，形成新的框架，然后对组装后的系统的整体功能和性能进行测试
6.6 技术评审
对以上步骤进行确认，进行技术评审，用于反映 组装后的架构是否满足用户需求，如果不满足将在6.2 ~ 6.6 之间迭代。
6.7 演化后的架构
产生演化后的架构在原来系统上所作的修改必须集成到原来的架构中，完成一次演化过程。
形式化方法
采用严格的数据方法，使用形式化规约语言来精确定义软件系统。基于数学的方式描述、开发和验证系统。包括形式化描述（形式化规约）和基于形式化描述的形式化验证两部分。形式化描述就是用形式化语言进行描述，建立软件需求和特性。形式化验证指验证已有的程序是否满足形式化描述的定义。
形式化描述可以分为两类，一类是通过建立计算模型来描述系统的行为特性，另一类则是通过定义系统必须满足的一些属性来描述系统。相对于自然语言，形式化描述是准确的、可验证的、避免了模糊性与二义性，消除需求中互相矛盾的地方。避免需求人员与开发人员对需求的理解偏差。
形式化描述可以通过计算机技术进行自动处理，进行一致性的检查和证明，提高需求分析的效率和质量。还需要经过灵敏性分析。通过形式化描述，需求分析的质量大大提高。在一些要求高可用性的关键应用上，可以采用形式化方法保证软件系统的可靠性。