@chendushuai
2018-08-20T00:38:41.000000Z
字数 11920
阅读 1712
软考 高级职称 系统架构师 学习笔记
软件生命周期划分为8个阶段：可行性研究与计划、需求分析、概要设计、详细设计、实现、集成测试、确认测试、使用和维护。
开发过程中，软件要经过需求分析、总体设计、详细设计、编码、调试、集成调试和系统测试阶段才能被准确的实现。而且每个阶段都有回到前一级的反馈线，指的是，在软件开发中当在后续阶段发现缺陷的时候，可以把这个缺陷反馈到上一阶段进行修正。
瀑布模型的一个重要特点是：软件开发的阶段划分是明确的，一个阶段到下一个阶段有明显的界限。在每个阶段结束后，都会有固定的文档或源程序流入下一阶段。在需求分析阶段结束后，需要有明确的描述软件需求的文档；总体设计结束后，需要有描述软件总体结构的文档；详细设计结束后，需要有可以用来编码的详细设计文档；而编码结束后，代码本身被作为文档流到下一阶段。因此也成瀑布模型为面向文档的软件开发模型。
整个瀑布模型在编码与调试阶段转了个弯，形成了一个对称的V字。瀑布V模型同标准瀑布模型一样，在进行完需求分析后就将进入总体设计阶段，但是除总体设计外，需要分析还有一条虚线指向系统测试。这指的是，需求分析的结果将作为系统测试的准则，即需求分析阶段也将产生通软件需求一致的系统测试；同时软件产品是否符合最初的需求也将在系统测试阶段得到验证。以此类推，总体设计对应了集成测试，详细设计对应了单元测试。瀑布V模型不但保持了瀑布模型的阶段式文档驱动的特点，而且更强调了软件产品的验证工作。
首先，在瀑布模型中，需求分析阶段是一切活动的基础，设计、实现和验证活动都是从需求分析的结果到处的。一旦需求分析的结果不完全正确，存在偏差，那么后续的活动只能放大这个偏差。所以瀑布模型后期的维护工作相当繁重，而这些维护工作大多都是修正在需求分析阶段引入的缺陷。
其次，瀑布模型难以适应变化。在瀑布模型中精确地定义了每一个阶段的活动和活动结果，而每一阶段都紧密依赖于上一阶段的结果。如果在软件的后期出现了需求的变化，整个系统又要从头开始。
再次，使用瀑布模型意味着当所有阶段都结束才能最终交付软件产品，所以在提出需求后，需要相当长的一段时间的等待才能够看到最终结果，才能发现软件产品究竟能不能满足客户的需求。
最后，文档驱动型的瀑布模型除了制造出软件产品外还将产生一大堆的文档，大部分的文档对客户没有任何意义，但是完成这些对客户没有意义的文档却需要花费大量的人力。所以瀑布模型也是一种重载模型。
一般情况下，一个演化模型可以看做若干次瀑布模型的迭代，当完成一个瀑布模型后，重新进入下一个迭代周期，软件在这样的迭代过程中得以演化、完善。根据不同的迭代特点，演化模型可以演变为螺旋模型、增量模型和原型法开发。
螺旋模型将瀑布模型和演化模型结合起来，不仅体现了两个模型的优点，而且还强调了其他模型军忽略了的风险分析。螺旋模型的每一个周期都包括需求定义、风险分析、工程实现和评审4个阶段。
螺旋模型的基本做法实在瀑布模型的每一个开发阶段前，引入一个非常严格的风险识别、风险分析和风险控制。它把软件项目分解成一个个小项目，每个小项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定。
螺旋模型特别适用于庞大而复杂、具有高风险的系统。
与瀑布模型相比，螺旋模型支持用户需求的动态变化，为用户参与软件开发的所有关键决策提供了方便，有助于提高目标软件的适应能力，为项目管理人员及时调整管理决策提供了便利，从而降低了软件开发风险。
但是，不能说螺旋模型绝对比其他模型优越，事实上，螺旋模型也有其自身的缺点：
对于增量模型，通常有两种策略。一个是增量发布的方法。即首先做好系统的分析和设计工作，然后将系统划分为若干不同的版本，每一个版本都是一个完整的系统，后一版本以前一个版本为基础进行开发，扩充前一版本的功能。在这种策略中，第一版本旺旺是系统的核心功能，可以满足用户最基本的需求，随着增量的发布，系统的功能逐步的丰富、完善起来。用户在很短的时间内救可以得到系统的初始版本并进行试用，试用中的问题可以很快的反馈到后续开发中，从而降低了系统的风险。在应用增量模型中需要注意：
另一种策略是原型法。同增量发布不同，原型法的每一次迭代都经过一个完整的生命周期，当用户需求很不明确或技术架构中存在很多不可知因素的时候，可以采用原型法。在初始的原型中，针对一般性的用户需求进行快速实现，并不考虑算法的合理性或系统的稳定性。这个原型的主要目的是获得精确的用户需求，或验证架构的可用性。一般情况下，会在后面的开发中抛弃这个原型，重新实现完整的系统。
在构件组装模型中，当经过需求分析定义出软件功能后，将对构件的组装结构进行设计，将系统划分成一组构件的集合，明确构建之间的关系。在确定了系统构件后，则将独立完成每一个构件，这是既可以开发软件构件，也可以重用已有的构件，当然也可以购买或选用第三方的构件。构件是独立的、自包容的，因此架构的开发也是独立的，构建之间通过接口相互合作。
优点如下：
缺点如下：
对于纵轴而言，业务建模、需求、分析设计、实施、测试、部署、配置与变更管理、项目管理、环境称为UP的9个核心工作流。可以把这9个核心工作流进行简单的分类以帮助理解，业务建模、需求、分析设计、实施、测试和部署是工程活动，而配置与变更管理、项目管理和环境是管理活动。
在经过这4个里程碑后，即为一个完整的生命周期，开发出一个新的版本。此时可以关闭该产品的开发，也可以迭代进入下一版本。
在UP中，架构设计师除了需要建立系统架构模型外，还需要：
具体的说，架构设计师不但需要设计系统架构，还需要定义设计方法、设计指南、编码指南、评审设计等工作。因此，也有人称UP是有一个以架构为中心的开发模型。
敏捷开发宣言内容：
XP是一种轻量（敏捷）、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。与其他方法论相比，其最大的不同在于：
XP由价值观、原则、实践和行为四个部分组成。
FDD是一个迭代的开发模型。FDD的每一步都强调质量，不断的交付可运行的软件，并以很小的开发提供精确的项目进度报告和状态信息。
FDD认为，有效的软件开发不可缺少的三个要素是人、过程和技术。软件开发不能没有过程，也不能没有技术，但软件开发中最重要的是人。FDD定义了6种关键的项目角色：
包括：领域对象建模、根据特征进行开发、类的个体所有、组成特征小组、审查、定期构造、配置管理、结果的可见性。
是一个用于开发和维持复杂产品的框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周。在Scrum中，使用产品Backlog来管理产品的需求，产品Backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint Backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。
主要包括：产品代办事项列表梳理、Sprint计划会议，每日Scrum会议、Sprint评审会议、Sprint回顾会议等五个活动
包括但不限于以下内容：保持产品代办事项列表有序、把看起来不再重要的事项移除或者降级、增加或提升涌现出来的或变得更重要的事项、将事项分解成更小的事项、将事项合并成更大的事项、对事项进行估算。
梳理时会特别关注那些即将被实现的事项。
整个团队都要参加Sprint计划会议。针对排好序的产品代办事项列表，产品负责人和开发团队成员讨论每个事项，并对该事项达成共识，包括根据当前的“完成的定义”，为了完成该事项所需要完成的所有事情。所有的Scrum会议都是限定市场的，推荐的市场是Sprint中的每周对应两小时或者更少。因为会议室定长的，Sprint计划会议的成功十分依赖于产品待办事项列表的质量。
在Scrum中，Sprint计划会议有两部分：
最终产生的待办事项列表就是“Sprint代办事项列表（Sprint Backlog）”
开发团队自组织的。开发团队通过每日Scrum会议来确认他们仍然可以实现Sprint的目标。这个会议每天在同样的时间和同样的地点召开。每一个开发团队成员需要提供一下三点信息：
从上一个每日Scrum到现在，我完成了什么；从现在到下一个每日Scrum，我计划完成什么；有什么阻碍了我的进展。
每日Scrum中可能有简要的问题澄清和回答，但是不应该有任何话题的讨论。通常，许多团队会在每日Scrum之后马上开会处理他们遇到的任何问题。
每日Scrum是Scrum中的一个关键组成部分，它可以带来透明性、信任和更好的绩效。它能帮助快速发现问题，并促成团队的自组织和自立。所有的Scrum会议都是限定时长的。每日Scrum通常不超过15分钟。
透明水晶方法具有以下七大体系特征：
项目主办者根据团队的工作进展获得重要反馈。用户有机会发现他们原来的需求是否是他们真正想要的，也有机会将观察结果反馈到开发当中。开发人员打破未解决问题的死结，从而实现对重点的持续关注。团队得以调整开发和配置的过程，并通过完成这些工作鼓舞团队的士气。
在迭代中及时反思和改进。
渗透交流就是信息流向团队成员的背景听觉，使得成员就像通过渗透一样获取相关信息。这种交流通常都是通过团队成员在同一间工作室内工作而实现的。
指的是当你指出困扰你的问题时，你不许担心受到报复。个人安全非常重要，有了它，团队可以发现和改正自身的缺点。没有它，团队成员们知而不言，缺点则愈发严重以至于损害整个团队。个人安全是迈向信任的第一步。
就是确定首先要做什么，然后安排时间，以平和的心态开展工作。确保团队成员清楚地了解他们自己最重要的任务是什么，确保他们能够有充分的时间去完成这些任务。
能够提给团队提供：对经常交付进行配置以及测试的地方，关于成品质量的快速反馈，关于设计理念的快速反馈，最新的（用户）需求。
最好的团队是将这三大技术结合成“持续测试集成技术”。
指的是利用已经存在的软件元素建立新的软件系统，这其中的软件元素既可以是软件产品、源程序，也可以使文档、设计思想甚至是领域知识。常用的软件重用形式包括；
构件又称为组件，是一个自包容、可复用的程序集。首先，构件是一个程序集，或者说是一组程序的集合。这个集合可能会以各种方式体现出来，如源程序或二进制的代码。这个集合整体向外提供统一的访问接口，构件外部只能通过接口来访问构件，而不能直接操作构件的内部。
构件的两个最重要的特性是自包容和可重用。自包容指的是构件本身是一个功能完整的独立体，构件内部与外部的功能界限清晰明确，可以独立配置与使用。而可重用即是构件的特点，也是构件出现的目的。
目前应用比较广泛的构件标准有CORBA、Java Bean/EJB、COM/DCOM。
是一种架构驱动方法，有三个基础：
软件模板是一个特殊类型的软件元素，包括描述所有这种类型的元素在共享服务和底层构造的基础上如何进行交互。软件模板还包括属于这种类型的所有元素的功能，这些功能有：每个元素都必须记录某些重大事件，每个元素必须为运行期间的外部诊断提供测试点等。在软件产品线系统中，软件模板显得格外重要，因为新元素的引入是一个通用的技术，这种技术用来使产品线架构适应一个特定的产品。
ABSD方法是递归的，且迭代的每一个步骤都是清晰定义的。因此，不管设计是否完成，架构总是清晰的，这有助于降低架构设计的随意性。
ABSD的输入由下列部分组成：
包括需求的粗略变化的描述和通用的需求。
用例是一个或多个最终用户与系统之间的交互的具体表述。
必须对待构建系统的质量和业务需求进行编号，每个质量属性都宝库啊一个特定的刺激，以及希望得到的响应。质量需求要尽量具体化。
质量场景是质量需求的特定扩充，使质量需求具体化。
把整个基于架构的软件过程划分为架构需求、设计、文档化、复审、实现、演化等6个子过程
需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。架构需求受技术环境和架构设计师的经验影响。需求过程主要是获取用户需求，标识系统中所要用到的构件。如果以前有类似的系统架构的需求，我们可以从需求库中取出，加以利用和修改，以节省需求获取的时间，减少重复劳动，提高开发效率。
架构需求一般来自三个方面，分别是系统的质量目标、系统的业务目标和系统开发人员的业务目标。软件架构需求获取过程主要是定义开发人员必须实现的软件功能，使得用户能够完成他们的任务，从而满足业务上的功能需求。与此同时，还需要获得软件质量属性，满足一些非功能需求。
这一过程又分为三步来实现
第一步：生成类图。
第二步：对类进行分组。一般的，与其他类隔离的类形成一个组，由泛化关联的类组成一个附加组，由聚合或组合关联的类形成一个附加组。
第三步：把类打包成构件。把在第二步得到的类簇打包成构件，这些构件可以分组合并成更大的构件。
组织一个由不同代表组成的小组，对架构需求及相关构件进行仔细的审查。审查的主要内容包括所获取的需求是否真实反映了用户的要求，累的分组是否合理，构建合并是否合理等。
架构文档化的主要输出结果是架构需求规格说明和测试架构需求的质量设计说明书两个文档。生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约。
在一个主版本的软件架构分析后，要安排一次由外部人员参加的复审。
复审的目的是标识潜在的风险，以及早发现架构设计中的缺陷和错误，包括架构能否满足需求，质量需求是否在设计中得到体现、层次是否清晰、构件的划分是否合理、文档表达是否明确、构件的设计是否能满足功能和性能的要求等。
所谓“实现”就是要用实体来显示出一个软件架构，既要符合脚骨所描述的结构性设计决策，分割成规定的构件，按规定方式互相交互。
整个实现过程是以复审后的文档化的架构说明书为基础的，每个构件必须满足软件架构中说明的对其他构件的责任。这些决定即实现的约束是在系统级或项目范围内作出的，每个构件上工作的实现者是看不见的。
在架构说明书中，已经定义了系统中构件与构件的关系。因为在架构层次上，构件接口约束对外唯一的代表了构件，所以可以从构件库中查找符合接口约束的构件，必要时开发新的满足要求的构件。
然后，按照设计提供的结构，通过组装支持工具把这些构件的实现体柱状起来，完成整个软件系统的连接与合成。
最后一步是测试，包括单个构件的功能性测试和被组装应用的整体功能和性能测试。
在构件开发过程中，最终用户的需求可能还有变动。在软件开发完毕，正常运行后，由一个单位移植到另一个单位，需求也会发生变化。在这两种情况下，就必须响应的修改软件架构，以适应新的软件架构。
架构演化是使用系统演化步骤去修改应用，以满足新的需求。主要包括以下七个步骤：
指采用严格的数学方法，使用形式化规约语言来精确定义软件系统。非形式化的开发方法是通过自然语言、图形或表格描述软件系统的行为和特性，然后基于这些描述进行设计和开发，而形式化开发则是基于数学的方式描述、开发和验证系统。
形式化方法包括形式化描述和基于形式化描述的形式化验证两部分内容。形式化描述就是用形式化语言进行描述，建立软件需求和特性，即解决软件“做什么”的问题。形式化验证是指验证已有的程序是否满足形式化描述的定义。形式化描述主要可以分为两类，一类是通过建立计算模型来描述系统的行为特征，另一类则通过定义系统必须满足的一些属性来描述系统。形式化描述又称之为形式化规约，相对于自然语言描述，形式化描述是精确的、可验证的，避免了模糊性与二义性，消除需求中相互矛盾的地方，避免需求定义人员和开发人员对需求的理解偏差。
形式化描述可以通过计算机技术进行自动处理，进行一致性的检查和证明，提高需求分析的效率和质量。通过形式化描述，需求分析的质量大大提高，很多自然语言描述无法避免的缺陷在序曲分析阶段就会被发现，并得到解决，从而降低后期开发和维护的成本，并提升软件的质量和可靠性。