第六章 开发方法
6.1 软件生命周期
软件生命周期划分为8个阶段：可行性研究与计划、需求分析、概要设计、详细设计、实现、集成测试、确认测试、使用和维护。
- 可行性研究与计划：通过可行性研究，来确定开发软件的必要性，并根据可行性研究的结果初步确定软件的目标、范围、风险、开发成本等内容。该阶段会产生《可行性研究报告》和《软件开发计划》，并进入需求分析的阶段。
- 需求分析：是软件开发的重要阶段。
- 概要设计：负责将需求分析的结果转化为技术层面的设计方案。在概要设计中，需求确定系统架构、各子系统间的关系、接口规约、数据库模型、编码规范等内容。概要设计的结果将做为程序员的工作指南，供程序员了解系统的内部原理，并在其基础上进行详细设计和编码工作。
- 详细设计：完成编码前的最后设计，详细设计在概要设计的基础上，进行细化，如类设计。不是必须的阶段。
- 实现：包括编码和单元测试。
- 集成测试：又称为组装测试。
- 确认测试：验证软件是否同需求一致，是否达到了预期目标。
- 使用和维护：在使用过程中不断进行维护和修改。当使用和维护阶段结束后，软件系统也就自然消亡，软件系统的生命周期结束。
6.2 软件开发模型
6.2.1 瀑布模型
1. 瀑布模型的核心思想
开发过程中，软件要经过需求分析、总体设计、详细设计、编码、调试、集成调试和系统测试阶段才能被准确的实现。而且每个阶段都有回到前一级的反馈线，指的是，在软件开发中当在后续阶段发现缺陷的时候，可以把这个缺陷反馈到上一阶段进行修正。
瀑布模型的一个重要特点是：软件开发的阶段划分是明确的，一个阶段到下一个阶段有明显的界限。在每个阶段结束后，都会有固定的文档或源程序流入下一阶段。在需求分析阶段结束后，需要有明确的描述软件需求的文档；总体设计结束后，需要有描述软件总体结构的文档；详细设计结束后，需要有可以用来编码的详细设计文档；而编码结束后，代码本身被作为文档流到下一阶段。因此也成瀑布模型为面向文档的软件开发模型。
2. 瀑布V模型
整个瀑布模型在编码与调试阶段转了个弯，形成了一个对称的V字。瀑布V模型同标准瀑布模型一样，在进行完需求分析后就将进入总体设计阶段，但是除总体设计外，需要分析还有一条虚线指向系统测试。这指的是，需求分析的结果将作为系统测试的准则，即需求分析阶段也将产生通软件需求一致的系统测试；同时软件产品是否符合最初的需求也将在系统测试阶段得到验证。以此类推，总体设计对应了集成测试，详细设计对应了单元测试。瀑布V模型不但保持了瀑布模型的阶段式文档驱动的特点，而且更强调了软件产品的验证工作。
3. 瀑布模型的缺点
首先，在瀑布模型中，需求分析阶段是一切活动的基础，设计、实现和验证活动都是从需求分析的结果到处的。一旦需求分析的结果不完全正确，存在偏差，那么后续的活动只能放大这个偏差。所以瀑布模型后期的维护工作相当繁重，而这些维护工作大多都是修正在需求分析阶段引入的缺陷。
其次，瀑布模型难以适应变化。在瀑布模型中精确地定义了每一个阶段的活动和活动结果，而每一阶段都紧密依赖于上一阶段的结果。如果在软件的后期出现了需求的变化，整个系统又要从头开始。
再次，使用瀑布模型意味着当所有阶段都结束才能最终交付软件产品，所以在提出需求后，需要相当长的一段时间的等待才能够看到最终结果，才能发现软件产品究竟能不能满足客户的需求。
最后，文档驱动型的瀑布模型除了制造出软件产品外还将产生一大堆的文档，大部分的文档对客户没有任何意义，但是完成这些对客户没有意义的文档却需要花费大量的人力。所以瀑布模型也是一种重载模型。
6.2.2 演化模型
一般情况下，一个演化模型可以看做若干次瀑布模型的迭代，当完成一个瀑布模型后，重新进入下一个迭代周期，软件在这样的迭代过程中得以演化、完善。根据不同的迭代特点，演化模型可以演变为螺旋模型、增量模型和原型法开发。
6.2.3 螺旋模型
螺旋模型将瀑布模型和演化模型结合起来，不仅体现了两个模型的优点，而且还强调了其他模型军忽略了的风险分析。螺旋模型的每一个周期都包括需求定义、风险分析、工程实现和评审4个阶段。
螺旋模型的基本做法实在瀑布模型的每一个开发阶段前，引入一个非常严格的风险识别、风险分析和风险控制。它把软件项目分解成一个个小项目，每个小项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定。
螺旋模型特别适用于庞大而复杂、具有高风险的系统。
与瀑布模型相比，螺旋模型支持用户需求的动态变化，为用户参与软件开发的所有关键决策提供了方便，有助于提高目标软件的适应能力，为项目管理人员及时调整管理决策提供了便利，从而降低了软件开发风险。
但是，不能说螺旋模型绝对比其他模型优越，事实上，螺旋模型也有其自身的缺点：
- 采用螺旋模型，需要具有相当丰富的风险评估经验和专业知识。在风险较大的项目开发中，如果未能及时标识风险，势必会造成重大损失。
- 过多的迭代次数会增加开发成本，延迟提交时间。
6.2.4 增量模型
对于增量模型，通常有两种策略。一个是增量发布的方法。即首先做好系统的分析和设计工作，然后将系统划分为若干不同的版本，每一个版本都是一个完整的系统，后一版本以前一个版本为基础进行开发，扩充前一版本的功能。在这种策略中，第一版本旺旺是系统的核心功能，可以满足用户最基本的需求，随着增量的发布，系统的功能逐步的丰富、完善起来。用户在很短的时间内救可以得到系统的初始版本并进行试用，试用中的问题可以很快的反馈到后续开发中，从而降低了系统的风险。在应用增量模型中需要注意：
- 每一个版本都是一个完整的版本。虽然最初的几个增量不能完全的实现用户需求，但这些版本都是完整的、可用的。
- 版本间的增量要均匀，这一点是很重要的。
另一种策略是原型法。同增量发布不同，原型法的每一次迭代都经过一个完整的生命周期，当用户需求很不明确或技术架构中存在很多不可知因素的时候，可以采用原型法。在初始的原型中，针对一般性的用户需求进行快速实现，并不考虑算法的合理性或系统的稳定性。这个原型的主要目的是获得精确的用户需求，或验证架构的可用性。一般情况下，会在后面的开发中抛弃这个原型，重新实现完整的系统。
6.2.5 构件组装模型
在构件组装模型中，当经过需求分析定义出软件功能后，将对构件的组装结构进行设计，将系统划分成一组构件的集合，明确构建之间的关系。在确定了系统构件后，则将独立完成每一个构件，这是既可以开发软件构件，也可以重用已有的构件，当然也可以购买或选用第三方的构件。构件是独立的、自包容的，因此架构的开发也是独立的，构建之间通过接口相互合作。
优点如下：
- 构建的自包容性让系统的扩展变得更加容易
- 设计良好的构件更容易被重用，降低软件开发成本
- 构件的粒度较整个系统更小，因此安排开发任务更加灵活，可以将开发团队分成若干组，并行的独立开发构件。
缺点如下：
- 对构件的设计需要经验丰富的架构设计师，设计不良的构建难以实现构件的优点，降低构建组装模型的重用度
- 在考虑软件的重用度时，往往会对其他方面做出让步，如性能等。
- 使用构件组装应用程序时，需要程序员熟练地掌握构件，增加了研发人员的学习成本。
- 第三方构件库的质量会最终影响到软件的质量，而第三方构件库的质量往往是开发团队难以控制的。
6.3 统一过程 UP
1. UP的二维模型
- 在初始阶段，开发者刚刚接入系统，此时最重要的工作是界定系统范围，明确系统目的。在这一阶段，业务建模和需求工作成了重头戏。
- 在细化阶段，开发者需要抽象出软件的逻辑模型，设计出软件的架构，在这一阶段，分析设计工作是最主要的工程活动。
- 在构建阶段，开发者需要基本完成系统的构建，使之成为一个完整的实体，并进行测试和部署。在这一阶段，实施和测试时最主要的活动。
- 在交付阶段（也称转移阶段），软件系统需求已经完全成熟或产品化，或进入下一个版本。在这一阶段不可避免的要对软件系统进行重构、修改、测试和部署。
对于纵轴而言，业务建模、需求、分析设计、实施、测试、部署、配置与变更管理、项目管理、环境称为UP的9个核心工作流。可以把这9个核心工作流进行简单的分类以帮助理解，业务建模、需求、分析设计、实施、测试和部署是工程活动，而配置与变更管理、项目管理和环境是管理活动。
2. UP的生命周期
- 目标里程碑。对应着先启阶段的结束，当开发者可以明确软件系统的目标和范围时即达到了该里程碑。
- 架构里程碑。架构里程碑是UP生命周期中的第二个里程碑，在这个里程碑前，开发者需要确定稳定的系统架构。
- 能力里程碑。当系统已经足够的稳定和成熟并完成Alpha测试后，认为达到了第三个里程碑。
- 发布里程碑。在达到发布里程碑前，需要完成系统的测试、完成系统发布和用户培训等工作。
在经过这4个里程碑后，即为一个完整的生命周期，开发出一个新的版本。此时可以关闭该产品的开发，也可以迭代进入下一版本。
3. UP的特点
- UP是一个迭代的二维开发模型，在生命周期的每一阶段都可以进行需求、设计等活动。UP不但给出了迭代的生命周期，还给出了生命周期每一阶段的迭代指南。
- 采用不同迭代方式的UP可以演变为演化模型或增量模型。
- UP的迭代特点使得更容易控制软件开发的风险。
- 虽然UP是一个迭代的开发模型，但UP本身不属于敏捷方法。相反，一般认为，未经裁剪的UP是一个重载过程。
- 在实际应用中可以根据具体问题对UP进行裁剪，从而使其可以使用各种规模的软件和开发团队。
4. 架构设计师在UP中的活动
在UP中，架构设计师除了需要建立系统架构模型外，还需要：
- 同需求人员和项目管理人员密切协作。
- 细化软件架构
- 保持整个架构的概念完整性。
具体的说，架构设计师不但需要设计系统架构，还需要定义设计方法、设计指南、编码指南、评审设计等工作。因此，也有人称UP是有一个以架构为中心的开发模型。
6.4 敏捷方法
敏捷开发宣言内容：
- 尽早的、持续的向客户交付有价值的软件对开发人员来说是最重要的。
- 拥抱变化，即使在开发的后期。敏捷过程能够驾驭变化，保持客户的竞争力。
- 经常交付可工作的软件，从几周到几个月，时间范围越小越好。
- 在整个项目中，业务人员和开发者紧密合作。
- 围绕士气高昂的团队进行开发，为团队成员提供适宜的环境，满足他们的需要，并给予足够的信任。
- 在团队中，最有效率的、也是效果最好的沟通方式是面对面的交流。
- 可以工作的软件是进度首要的度量方式。
- 可持续的开发。投资人、开发团队和用户应该保持固定的节奏。
- 不断追求优秀的技术和良好的设计有助于提高敏捷性
- 要简单，尽可能减少工作量。减少工作量的艺术是非常重要的。
- 最好的架构、需求和设计都来自于一个自我组织的团队。
- 团队要定期的总结如何能够更有效率，然后相应的自我调整。
6.4.1 极限编程 XP
XP是一种轻量（敏捷）、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。与其他方法论相比，其最大的不同在于：
- 在更短的周期内，更早的提供具体、持续的反馈信息。
- 迭代的进行计划变编程，首先在最开始迅速生成一个总体计划，然后在整个项目开发过程中不断的发展它。
- 依赖于自动测试程序来监控开发进度，并及早的捕捉缺陷。
- 依赖于口头交流、测试和源程序进行沟通。
- 倡导持续的、演化式的设计。
- 依赖于开发团队内部的紧密协作。
- 尽可能达到程序短期利益和项目长期利益的平衡。
XP由价值观、原则、实践和行为四个部分组成。
1. 四大价值观
- 沟通。XP组合了诸如结对编程这样的最佳实践，鼓励大家进行口头交流、通过交流解决问题，提高效率。
- 简单。尽量简单化的开发。
- 反馈。开发过程中必要的反馈，通过持续、明确的反馈来暴露软件状态的问题。
- 勇气。有勇气面对快速开发。
2. 十二个最佳实践
- 计划游戏。主要思想是先快速的制定一份概要计划，然后随着项目细节的不断清晰，再逐步完善这份计划。计划游戏产生的结果是一套用户故事及后续的一两次迭代的概要计划。
- 小型发布。XP方法秉承的是“持续集成、小步快走”的哲学思维，也就是说每一次发布的版本应尽可能的小。由于小型发布可以使得集成更频繁，客户获得的中间结果越频繁，反馈也就越频繁，客户就能实时的了解项目的进展情况，从而提出更多的意见，以便在下一次迭代中计划进去，以实现更高的客户满意度。
- 隐喻。一种语言的表达手段，它用来暗示字面意思不相似的事物之间的相似之处。隐喻常用于四个方面：寻求共识、发明共享词汇、创新的武器、描述架构。
- 简单设计。强调简单的价值观，引出了简单性假设原则，落到实处就是“简单设计”实践。XP的简单设计实践并不是要忽略设计，而是认为设计不应该在编码之前一次性完成，因为那样只能建立在“情况不会发生变化”或者“我们可以预见所有的变化”之类的谎言的基础上。
- 测试先行。
- 重构。对代码进行改动而不影响功能实现。
- 结对编程。
- 集体代码所有制。团队中的每个成员都拥有对代码进行改进的权利，每个人都拥有全部代码，也都需要对全部代码负责。同时，XP强调代码是谁破坏的（修改后出现问题），就应该由谁来修复。
- 持续集成。
- 每周工作40小时。
- 现场客户。在项目中有客户在现场明确用户故事，并作出响应的业务决策。
- 编码标准。
6.4.2 特征驱动开发 FDD
FDD是一个迭代的开发模型。FDD的每一步都强调质量，不断的交付可运行的软件，并以很小的开发提供精确的项目进度报告和状态信息。
1. FDD角色定义
FDD认为，有效的软件开发不可缺少的三个要素是人、过程和技术。软件开发不能没有过程，也不能没有技术，但软件开发中最重要的是人。FDD定义了6种关键的项目角色：
- 项目经理。是开发的组织者，但是不是开发的主宰。对于项目团队来说，项目经理应该是团队的保护屏障，他同团队外界（如高层领导、人事甚至写字楼的物业管理员）进行沟通，努力为团队提供一个适宜的开发环境。
- 首席架构设计师。负责系统架构的设计。
- 开发经理。负责团队日常的开发，解决开发中出现的技术问题与资源冲突。
- 主程序员。带领一个小组完成特征的详细设计和构建的工作，一般要求主程序员具有一定的工作经验，并能够带动小组的工作。
- 程序员。
- 领域专家
2. 核心过程
- 开发整体对象模型。也就是业务建模的阶段。不过FDD强调的是系统的完整的面向对象建模，这种做法有助于把握整个系统，而不仅仅关注系统中的若干个点。在这一阶段，领域专家和首席架构设计师相互配合，完成整体对象模型。
- 构造特征列表。完成系统建模后，需要构造一个完整的特征列表。所谓特征指的是一个小的、对客户有价值的功能。采用动作、结果和膜表来描述特征，特征的粒度最好可以在两周之内实现。在这一阶段中，可以整理出系统的需求。
- 计划特征开发。这一阶段中，项目经理根据构造出的特征列表、特征间的依赖关系进行计划，安排开发任务。
- 特征设计。在这一阶段，主程序员将带领特征小组对特征进行详细设计，为后面的构建做准备。
- 特征构建。特征构建和特征设计这两个阶段合并起来可以看做特征的是现阶段，这两个阶段反复的迭代，直到完成全部的开发。
3. 最佳实践
包括：领域对象建模、根据特征进行开发、类的个体所有、组成特征小组、审查、定期构造、配置管理、结果的可见性。
6.4.3 Scrum
是一个用于开发和维持复杂产品的框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周。在Scrum中，使用产品Backlog来管理产品的需求，产品Backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint Backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。
1. Scrum的五个活动
主要包括：产品代办事项列表梳理、Sprint计划会议，每日Scrum会议、Sprint评审会议、Sprint回顾会议等五个活动
1) 产品代办事项列表梳理
包括但不限于以下内容：保持产品代办事项列表有序、把看起来不再重要的事项移除或者降级、增加或提升涌现出来的或变得更重要的事项、将事项分解成更小的事项、将事项合并成更大的事项、对事项进行估算。
梳理时会特别关注那些即将被实现的事项。
2) Sprint计划会议
整个团队都要参加Sprint计划会议。针对排好序的产品代办事项列表，产品负责人和开发团队成员讨论每个事项，并对该事项达成共识，包括根据当前的“完成的定义”，为了完成该事项所需要完成的所有事情。所有的Scrum会议都是限定市场的，推荐的市场是Sprint中的每周对应两小时或者更少。因为会议室定长的，Sprint计划会议的成功十分依赖于产品待办事项列表的质量。
在Scrum中，Sprint计划会议有两部分：
- 决定在Sprint中需要完成哪些工作
- 决定这些工作如何完成
最终产生的待办事项列表就是“Sprint代办事项列表（Sprint Backlog）”
3) 每日Scrum会议
开发团队自组织的。开发团队通过每日Scrum会议来确认他们仍然可以实现Sprint的目标。这个会议每天在同样的时间和同样的地点召开。每一个开发团队成员需要提供一下三点信息：
从上一个每日Scrum到现在，我完成了什么；从现在到下一个每日Scrum，我计划完成什么；有什么阻碍了我的进展。
每日Scrum中可能有简要的问题澄清和回答，但是不应该有任何话题的讨论。通常，许多团队会在每日Scrum之后马上开会处理他们遇到的任何问题。
每日Scrum是Scrum中的一个关键组成部分，它可以带来透明性、信任和更好的绩效。它能帮助快速发现问题，并促成团队的自组织和自立。所有的Scrum会议都是限定时长的。每日Scrum通常不超过15分钟。
4) Sprint评审会议
5) Sprint回顾会议
2. Scrum的5大价值观
- 承诺——愿意对目标作出承诺
- 专注——把你的心思和能力都哟井道你承诺的工作上去
- 开放——Scrum把项目中的一切开放给每个人看
- 尊重——每个人都有他独特的背景和经验
- 勇气——有勇气作出承诺，履行承诺，接受别人的尊重。
6.4.4 水晶方法 Crystal
透明水晶方法具有以下七大体系特征：
1. 经常交付
项目主办者根据团队的工作进展获得重要反馈。用户有机会发现他们原来的需求是否是他们真正想要的，也有机会将观察结果反馈到开发当中。开发人员打破未解决问题的死结，从而实现对重点的持续关注。团队得以调整开发和配置的过程，并通过完成这些工作鼓舞团队的士气。
2. 反思改进
在迭代中及时反思和改进。
3. 渗透式交流
渗透交流就是信息流向团队成员的背景听觉，使得成员就像通过渗透一样获取相关信息。这种交流通常都是通过团队成员在同一间工作室内工作而实现的。
4. 个人安全
指的是当你指出困扰你的问题时，你不许担心受到报复。个人安全非常重要，有了它，团队可以发现和改正自身的缺点。没有它，团队成员们知而不言，缺点则愈发严重以至于损害整个团队。个人安全是迈向信任的第一步。
5. 焦点
就是确定首先要做什么，然后安排时间，以平和的心态开展工作。确保团队成员清楚地了解他们自己最重要的任务是什么，确保他们能够有充分的时间去完成这些任务。
6. 与专家用户建立方便的联系
能够提给团队提供：对经常交付进行配置以及测试的地方，关于成品质量的快速反馈，关于设计理念的快速反馈，最新的（用户）需求。
7. 配有自动测试、配置管理和经常集成功能的技术环境
最好的团队是将这三大技术结合成“持续测试集成技术”。
6.4.5 其他敏捷方法
- 开放式源码：指的是开放源码界所用的一种运作方式。开放式源码有一个特别之处，就是程序开发人员在地域上分布很广。一个突出特点就是查错排障的高度并行性，任何人发现了错误都可以将改正源码的“补丁”文件发送给维护者，然后由维护者将这些“补丁”或是新增的代码并入源码库。ASD方法的核心是三个非线性的、重叠的开发阶段：猜测、合作与学习。
6.5 软件重用
6.5.1 软件重用
指的是利用已经存在的软件元素建立新的软件系统，这其中的软件元素既可以是软件产品、源程序，也可以使文档、设计思想甚至是领域知识。常用的软件重用形式包括；
- 源代码重用
- 架构重用
- 应用框架的重用。
- 业务建模的重用
- 文档即过程的重用
- 软构件的重用。
- 软件服务的重用。
6.5.2 构建技术
构件又称为组件，是一个自包容、可复用的程序集。首先，构件是一个程序集，或者说是一组程序的集合。这个集合可能会以各种方式体现出来，如源程序或二进制的代码。这个集合整体向外提供统一的访问接口，构件外部只能通过接口来访问构件，而不能直接操作构件的内部。
构件的两个最重要的特性是自包容和可重用。自包容指的是构件本身是一个功能完整的独立体，构件内部与外部的功能界限清晰明确，可以独立配置与使用。而可重用即是构件的特点，也是构件出现的目的。
目前应用比较广泛的构件标准有CORBA、Java Bean/EJB、COM/DCOM。
6.6 基于架构的软件设计 ABSD
是一种架构驱动方法，有三个基础：
- 功能的分解。在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术。
- 通过选择架构风格来实现质量和业务需求。
- 软件模板的使用。软件模板利用了一些软件系统的结构。
软件模板是一个特殊类型的软件元素，包括描述所有这种类型的元素在共享服务和底层构造的基础上如何进行交互。软件模板还包括属于这种类型的所有元素的功能，这些功能有：每个元素都必须记录某些重大事件，每个元素必须为运行期间的外部诊断提供测试点等。在软件产品线系统中，软件模板显得格外重要，因为新元素的引入是一个通用的技术，这种技术用来使产品线架构适应一个特定的产品。
ABSD方法是递归的，且迭代的每一个步骤都是清晰定义的。因此，不管设计是否完成，架构总是清晰的，这有助于降低架构设计的随意性。
6.6.1 ABSD方法与生命周期
ABSD的输入由下列部分组成：
1. 抽象功能需求
包括需求的粗略变化的描述和通用的需求。
2. 用例
用例是一个或多个最终用户与系统之间的交互的具体表述。
3. 抽象的质量和业务需求
必须对待构建系统的质量和业务需求进行编号，每个质量属性都宝库啊一个特定的刺激，以及希望得到的响应。质量需求要尽量具体化。
4. 架构选项
5. 质量场景
质量场景是质量需求的特定扩充，使质量需求具体化。
6. 约束
6.6.2 基于架构的软件开发模型 ABSDM
把整个基于架构的软件过程划分为架构需求、设计、文档化、复审、实现、演化等6个子过程
1. 架构需求
需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。架构需求受技术环境和架构设计师的经验影响。需求过程主要是获取用户需求，标识系统中所要用到的构件。如果以前有类似的系统架构的需求，我们可以从需求库中取出，加以利用和修改，以节省需求获取的时间，减少重复劳动，提高开发效率。
1. 需求获取
架构需求一般来自三个方面，分别是系统的质量目标、系统的业务目标和系统开发人员的业务目标。软件架构需求获取过程主要是定义开发人员必须实现的软件功能，使得用户能够完成他们的任务，从而满足业务上的功能需求。与此同时，还需要获得软件质量属性，满足一些非功能需求。
2. 标识构件
这一过程又分为三步来实现
第一步：生成类图。
第二步：对类进行分组。一般的，与其他类隔离的类形成一个组，由泛化关联的类组成一个附加组，由聚合或组合关联的类形成一个附加组。
第三步：把类打包成构件。把在第二步得到的类簇打包成构件，这些构件可以分组合并成更大的构件。
3. 需求评审
组织一个由不同代表组成的小组，对架构需求及相关构件进行仔细的审查。审查的主要内容包括所获取的需求是否真实反映了用户的要求，累的分组是否合理，构建合并是否合理等。
2. 架构设计
- 提出软件架构模型
- 把已标识的构件映射到软件架构中。把在架构需求阶段已标识的构件映射到架构中，将产生一个中间结构，这个中间结构只包含那些能明确适合架构模型的构件。
- 分析构件之间的相互作用
- 产生软件架构
- 设计评审
3. 架构文档化
架构文档化的主要输出结果是架构需求规格说明和测试架构需求的质量设计说明书两个文档。生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约。
4. 架构复审
在一个主版本的软件架构分析后，要安排一次由外部人员参加的复审。
复审的目的是标识潜在的风险，以及早发现架构设计中的缺陷和错误，包括架构能否满足需求，质量需求是否在设计中得到体现、层次是否清晰、构件的划分是否合理、文档表达是否明确、构件的设计是否能满足功能和性能的要求等。
5. 架构实现
所谓“实现”就是要用实体来显示出一个软件架构，既要符合脚骨所描述的结构性设计决策，分割成规定的构件，按规定方式互相交互。
整个实现过程是以复审后的文档化的架构说明书为基础的，每个构件必须满足软件架构中说明的对其他构件的责任。这些决定即实现的约束是在系统级或项目范围内作出的，每个构件上工作的实现者是看不见的。
在架构说明书中，已经定义了系统中构件与构件的关系。因为在架构层次上，构件接口约束对外唯一的代表了构件，所以可以从构件库中查找符合接口约束的构件，必要时开发新的满足要求的构件。
然后，按照设计提供的结构，通过组装支持工具把这些构件的实现体柱状起来，完成整个软件系统的连接与合成。
最后一步是测试，包括单个构件的功能性测试和被组装应用的整体功能和性能测试。
6. 架构演化
在构件开发过程中，最终用户的需求可能还有变动。在软件开发完毕，正常运行后，由一个单位移植到另一个单位，需求也会发生变化。在这两种情况下，就必须响应的修改软件架构，以适应新的软件架构。
架构演化是使用系统演化步骤去修改应用，以满足新的需求。主要包括以下七个步骤：
- 需求变动归类。首先必须对用户需求的变化进行归类，使变化的需求与已有构件对应。对找不到对应构件的变动，也要做好标记。在后续构件中，将创建新的构件，以对应这部分变化的需求。
- 制定架构演化计划。在改变原有结构之前，开发组织必须制定一个周密的架构演化计划，作为后续演化开发工作的指南。
- 修改、增加或删除构件。在演化计划的基础上，开发人员可根据在第一步得到的需求变动的归类情况，决定是否修改或删除存在的构件、增加新构件。最后，对修改和增加的构件进行功能性测试。
- 更新构件的相互作用。随着构件的增加、删除和修改，构件之间的控制流必须得到更新。
- 构建组装与测试。通过组装支持工具把这些构件的实现体组装起来，完成整个软件系统的连接与合成，形成新的架构。然后对组装后的系统的整体功能和性能进行测试。
- 技术评审。对上述步骤进行确认，进行技术评审。评审组装后的架构是否反映需求变动，符合用户需求。如果不符合，则需要在第2到第6步之间进行迭代。
- 产生演化后的架构。在原来系统上所做的所有修改必须集成到原来的架构中，完成一次演化过程。
6.7 形式化方法
指采用严格的数学方法，使用形式化规约语言来精确定义软件系统。非形式化的开发方法是通过自然语言、图形或表格描述软件系统的行为和特性，然后基于这些描述进行设计和开发，而形式化开发则是基于数学的方式描述、开发和验证系统。
形式化方法包括形式化描述和基于形式化描述的形式化验证两部分内容。形式化描述就是用形式化语言进行描述，建立软件需求和特性，即解决软件“做什么”的问题。形式化验证是指验证已有的程序是否满足形式化描述的定义。形式化描述主要可以分为两类，一类是通过建立计算模型来描述系统的行为特征，另一类则通过定义系统必须满足的一些属性来描述系统。形式化描述又称之为形式化规约，相对于自然语言描述，形式化描述是精确的、可验证的，避免了模糊性与二义性，消除需求中相互矛盾的地方，避免需求定义人员和开发人员对需求的理解偏差。
形式化描述可以通过计算机技术进行自动处理，进行一致性的检查和证明，提高需求分析的效率和质量。通过形式化描述，需求分析的质量大大提高，很多自然语言描述无法避免的缺陷在序曲分析阶段就会被发现，并得到解决，从而降低后期开发和维护的成本，并提升软件的质量和可靠性。
