2、 它是大规模复用的有效基础。
通过明确阐述它们之间的主要构件和关键接口,构架为您决定重复使用提供依据，包括内部复用（确定公用的部分）和外部复用（并入现成的构件）。它还允许更大规模上的复用：构架本身的复用，用于处理同一领域中的不同功能。
3、 构架还可作为项目管理的基础。
项目计划和人员配备是根据主要构件的类别组织进行的。基本的结构决策是由一个人员组成相对固定的构架小组作出的，他们不是分散的。而开发活动则被分配给若干个小组，每个小组负责开发系统的一个或若干个部分。
三、 迭代和递增的开发
迭代式方法一般要优于线性或瀑布式方法，其原因很多。
1、 允许变更需求。需求有时会变化，这常常给项目带来麻烦，它们会导致延期交付、工期延误、客户不满意、开发人员受挫。
2、 逐步集成元素。在迭代式方法中，集成可以说是连续不断的。过去在项目结束时要占到整个项目工作量的那段较长的、不确定的且棘手的时期，现在分散到六至九个集成部分中，每一部分要集成的元素都比过去少得多。
3、 及早降低风险。因为风险一般只有在集成阶段才能发现或得到处理。在初期迭代时，检查所有的核心工作流程，对项目使用的工具、市售软件及人员技能等许多方面进行磨合。过去认定的风险可能被证明不再是风险，而又可能出现一批新的未曾怀疑过的风险。
4、 有助于组织学习和提高。团队成员有机会在整个生命周期中边做边学，各显其能。测试员可以早一些开始测试，技术文档编写员可及早开始编写，其他人也是如此。如果是非迭代式开发，这些人在初期只能制定计划或培训技能，空等着开始他们的工作。培训需求等也可在评估复审中尽早提出。
5、 提高复用性。因为分部分设计或实施比起预先确定所有共性更容易确定公用部分。确定和开发可重复使用的部分并非易事。早期迭代中的设计复审可使构架设计师确定毋庸置疑的潜在复用部分，并在以后的迭代中开发和完善这些公用代码。
6、 生成性能更强壮的产品。因为在多次迭代中您总是不断地纠正错误。在产品脱离先启阶段后的初期迭代中仍然可以发现缺陷。性能上的瓶颈可以尽早发现并处理，而不象在交付前夕，此时已来不及处理。
7、 容许产品进行战术改变。例如同现有的同类产品竞争。可以决定采用抢先竞争对手一步的方法，提前发布一个功能简化的产品，或者采用其他厂商的已有技术。
8、 迭代流程自身可在进行过程中得到改进和精炼。一次迭代结束时的评估不仅要从产品和进度的角度来考察项目的情况，而且还要分析组织和流程本身有什么待改进之处，以便在下次迭代中更好地完成任务。
通常在软件开发过程中，迭代在数量、持续时间和目标上都是按计划进行的。参与者的任务和职责都已确定好。对进度进行的目标评测都将记录备查。从一次迭代到下一次迭代确实会存在返工现象，但返工也是严格按规定进行的。
四、 使用不当的问题
很多企业员工在使用UML的过程中，只是进行了领域建模，没有进行用例建模，这样是不能最大可能地发挥UML的优势的，因为该组织的软件开发过程不是用例驱动的。
文章来源于领测软件测试网 https://www.ltesting.net/
