软件架构评估是软件设计阶段最重要的活动之一，目前存在多种软件架构评估方式，其中，..

场景是一系列有序的使用或修改系统的步骤。基于场景的方式主要应用在体系结构权衡分析方法（Architecture Tradeoff Analysis Method, ATAM）和软件体系结构分析方法（Software Architecture Analysis Method, SAAM）中。在体系结构评估中，一般采用刺激（stimulus）、环境（environment）和响应（response）3方面来对场景进行描述。刺激是场景中解释或描述项目干系人怎样引发与系统的交互部分，环境描述的是刺激发生时的情况，响应是指系统是如何通过体系结构对刺激作出反应的。

基于场景的方式分析软件体系结构对场景的支持程度，从而判断该体系结构对这一场景所代表的质量需求的满足程度。例如，用一系列对软件的修改来反映易修改性方面的需求，用一系列攻击性操作来代表安全性方面的需求等。这一评估方式考虑到了所有与系统相关的人员对质量的要求，涉及到的基本活动包括：确定应用领域的功能和软件体系结构的结构之间的映射，设计用于体现待评估质量属性的场景，以及分析软件体系结构对场景的支持程度。

不同的系统对同一质量属性的理解可能不同，例如，对操作系统来说，可移植性被理解为系统可在不同的硬件平台上运行，而对于普通的应用系统而言，可移植性往往是指该系统可在不同的操作系统上运行。由于存在这种不一致性，对一个领域适合的场景设计在另一个领域内未必合适，因此基于场景的评估方式是特定于领域的。这一评估方式的实施者一方面需要有丰富的领域知识，以对某一质量需求设计出合理的场景；另一方面，必须对待评估的软件体系结构有一定的了解，以准确判断它是否支持场景描述的一系列活动。

评估

评估测试不只针对物理设备，更重要的是要评估、比较各种网络技术。通常使用模拟测试配置和模拟负载进行子系统（如路由器）和网络技术（如ATM或FDDI等）的评估。评估测试不适用于全局网络，因为全局网络拓扑负载、网络设备太多，不好准确定位引起问题的原因和位置，不能进行有效的比较。多数评估测试在专用的子网测试环境中进行。

很多公司都有其固定合作的网络设备供应商，如路由器、集线器或交换机的供应商，通常很少再做设备比较测试，但网络技术的比较测试需要经常进行。企业经常面对选择哪种技术以及怎样比较不同技术的问题，所以技术评估是评估测试中很重要的一项。

在比较设备与技术时，除了使用专用于待测设备或技术的工程负载外，有经验的程序员也使用真实负载，使用真实负载可以了解待测设备或技术在特定环境下的运行性能。通过两种负载模式检测结果的比较，可以获知待测设备还有多少多余容量。

评估测试与设备或技术的功能／特征测试一样，用于比较待测设备或技术的性能、稳定性、特性、易用性配置和管理等方面的功能。

评估测试实质是衰减测试的基础，评估测试中对几种设备或技术进行比较；衰减测试中对同一设备的不同版本进行比较。测试中选择设备的标准也完全可作为验证升级版本工作正常与否的标准。尽可能多地集成在计划／设计阶段进行测试是非常好的方法，最初的产品评估测试可以被开发阶段的可接受性测试和升级阶段的衰减性测试所借鉴。

评估测试是最常进行的测试，在设备选型、技术选型，以及网络系统升级过程中都要进行或多或少的评估测试。

用于评估测试的负载模式和测试脚本要能有效覆盖被检测的设备和技术。常使用最好情形（工程负载）和真实负载模式进行测试，两种方式都提供了唯一的、重要的检测结果，测试人员要能够理解、解释测试结果间的不同。

工程检测结果是被测设备和技术在最理想的情形下测试得到的结果，因此不能在真实运行环境里显示它们的运行性能；真实检测结果能很好地显示待测设备或技术在运行网络环境中的性能，但无法预测设备的总容量。如果时间允许，两种测试都要做。通常测试人员只有时间进行一种测试，一般进行最好情形的测试。许多公开发行的测试报告都是基于最好情形（工程负载）下的测试结果。

所有的测试配置都是模拟的。用于设备比较的测试配置不一定要代表运行网络的典型配置，任何有效、公正的测试配置都能对被测产品进行很好的比较。然而，测试配置和负载越接近运行网络的配置和负载，测试的结果越能反映被测设备在运行网络中的运行情况。

在安装和配置测试网络时必须注意：要确保配置中所有测试组件都是最新版本，使测试尽可能地公正和统一，以取得最好的测试结果。在测试非正式版时一定要小心，因为发布日期经常有错误。测试配置中安装了非正式版后，它还可能会变，所以非正式版的测试结果和正式版的测试结果经常不一致，分析非正式版的设备经常会延误项目的进行。

进行评估测试时，除了被测设备，测试配置中的所有网络组件都要保持不变。这一点非常重要，只有这样才能保证被测设备可以进行公平比较。对于子网，这一点很容易做到（一个网络设备很容易被另一个设备所替代）。

网络技术评估要比较各种网络技术，因而测试配置中的几个网络组件都需要更换。重要的是不要改变源或目标配置。在配置中不仅通信线路需要更换，路由器也需要更换。传输负载和端点的配置要保持不变。

需要评估测试计划中的各个测试任务，逐步完成测试、数据收集和数据解释。在评估测试中，各测试进行的先后次序没有关系，因为它们不是线性关系，而是多次重复进行的。当在测试中发现了新的信息时，以前所做的测试可能要重新进行以确定它的测试结果，或要对以前的测试稍作改变以检验网络运行的其他方面。此外，在评估期间设备提供商经常发布新的版本或非正式的版本，所以各种基于这种设备的测试都要重新进行。

制定网络设备、技术比较或取舍标准时，不仅要参考评估测试所得的测试结果数据，还要综合考虑其他一些信息，如各设备的性能价格比，但由于没有运行网络的持续和峰值负载要求，所以缺少比较基准，往往将产品评估测试引入歧途。

最后要根据评估测试所得的数据和图表对网络系统作出总结性评估，并撰写网络系统评估报告。

评估方式

评价网络广告效果的三种基本方法：对比分析法、加权计算法和点击率与转化率。

（1）对比分析法。无论是旗帜广告，还是邮件广告，由于都涉及到点击率或者回应率以外的效果，因此，除了可以准确跟踪统计的技术指标外，利用比较传统的对比分析法仍然具有现实意义。当然，不同的网络广告形式，对比的内容和方法也不一样。对于标志广告，除了增加直接点击以外，广告的效果通常还表现在品牌形象方面，这也就是为什么许多广告主不顾点击率低的现实而仍然选择标志广告的主要原因。当然，品牌形象的提升很难通过量化指标衡量，不过可以利用传统的对比分析法，对网络广告投放前后的品牌形象进行调查对比。

（2）加权计算法。所谓加权计算法就是对投放网络广告后的一定时间内，对网络广告产生效果的不同层面赋予权重，以判别不同广告所产生效果之间的差异。这种方法实际上是对不同广告形式、不同投放媒体或者不同投放周期等情况下的广告效果比较，而不仅仅反映某次广告投放所产生的效果。显然，加权计算法要建立在对广告效果有基本监测统计手段的基础之上。

下面以一个例子来说明：

第一种情况，假定在A网站投放的BANNER广告在一个月内获得的效果为：产品销售100件（次），点击数量5000次；

第二种情况，假定在B网站投放的BANNER广告在一个月内获得的效果为：产品销售120件（次），点击数量3000次；

如何判断这两次广告投放效果的区别呢？可以为产品销售和获得的点击分别赋予权重，根据一般的统计数字，每100次点击可形成2次实际购买，那么可以将实际购买的权重设为1.00，每次点击的权重为0.02，由此可以计算上述两种情况下，广告主可以获得的总价值。

第一种情况，总价值为：100×1.00+5000×0.02=200；

第二种情况，总价值为：120×1.00+3000×0.02=180。

可见，虽然第二种情况获得的直接销售比第一种情况要多，但从长远来看，第一种情况更有价值。这个例子说明，网络广告的效果除了反映在直接购买之外，对品牌形象或者用户的认知同样重要。

（3）点击率与转化率。点击率是网络广告最基本的评价指标，也是反映网络广告最直接、最有说服力的量化指标，不过，随着人们对网络广告了解的深入，点击它的人反而越来越少，除非特别有创意或者有吸引力的广告，造成这种状况的原因可能是多方面的，如网页上广告的数量太多而无暇顾及、浏览者浏览广告之后已经形成一定的印象无须点击广告或者仅仅记下链接的网址，在其他时候才访问该网站等等，因此，平均不到1%的点击率已经不能充分反映网络广告的真正效果。

于是，对点击以外的效果评价问题显得重要起来，与点击率相关的另一个指标——转化率，被用来反映那些观看而没有点击广告所产生的效果。

“转化率”最早由美国的网络广告调查公司AdKnowledge在“2000年第三季度网络广告调查报告”中提出，AdKnowledge将“转化”定义为受网络广告影响而形成的购买、注册或者信息需求。正如该公司高级副总裁David Zinman所说，“这项研究表明浏览而没有点击广告同样具有巨大的意义，营销人员更应该关注那些占浏览者总数99%的没有点击广告的浏览者”。

软件架构

随着嵌入式技术的发展，特别是在后PC时代，嵌入式软件系统得到了极大的丰富和发展，形成了一个完整的软件体系，如下图所示。这个体系自底向上由3部分组成，分别是嵌入式操作系统、支撑软件和应用软件。

嵌入式系统的软件架构

嵌入式操作系统（Embedded Operating System，EOS）由操作系统内核、应用程序接口、设备驱动程序接口等几部分组成。嵌入式操作一般采用微内核结构。操作系统只负责进程的调度、进程间的通信、内存分配及异常与中断管理最基本的任务，其他大部分的功能则由支撑软件完成。

嵌入式系统中的支撑软件由窗口系统、网络系统、数据库管理系统及Java虚拟机等几部分组成。对于嵌入式系统来讲，软件的开发环境大部分在通用台式计算机和工作站上运行，但从逻辑上讲，它仍然被认为是嵌入式系统支撑软件的一部分。支撑软件一般用于一些浅度嵌入的系统中，如智能手机、个人数字助理等。

嵌入式系统中的应用软件是系统整体功能的集中体现。系统的能力总是通过应用软件表现出来的。

软件设计

软件设计的任务

在给定系统的需求规格说明书后，需要对软件的结构进行设计，并对设计的过程进行管理。在嵌入式系统的软件设计过程中，需要完成以下一些任务。

准备工作计划

在软件设计之前，首先要制订详细的工作计划，其内容包括：

.过程管理方案：包括软件开发的进度管理、软件规模和所需人年的估算、开发人员的技能培训等；

.开发环境的准备方案：包括开发工具的准备、开发设备的准备、测试装备的准备、分布式开发环境下的开发准则等；

.软硬件联机调试的方案：联调的起始时间、地点、人员和具体的准备工作；

.质量保证方案：包括质量目标计划、质量控制计划等；

.配置控制方案：包括配置控制文档的编写、配置控制规则的制订等。

确定软件的结构

设计软件的各个组成部分，包括：

.任务结构的设计：使用操作系统提供的函数，设计出一个最佳的任务结构；

.线程的设计；

.公共数据结构的设计：在确保系统一致性的基础上，设计出所需的公共数据；

.操作系统资源的定义；

.类的设计；

.模块结构设计：在设计时要充分考虑模块的划分、标准化、可重用和灵活性等；

.内存的分配与布局。

设计评审

对于软件设计的结果，进行一次设计评审，并在必要时对设计进行修正。具体内容包括：

.确认每件工作的执行方法是否恰当，其内容是否完善；

.确认该设计完成了系统需求规格说明书所要求的功能和服务；

.评估任务结构设计、评估类的设计、评估模块结构设计；

.对软件设计的结果进行总结，编写出相应的文档。

维护工作计划

执行软件设计工作控制，在每日、每周和每月的时间粒度上对进度进行控制，确保软件设计能够如期完成。

与硬件部门密切合作、相互协调

根据工作计划中的安排，定期与硬件部门召开会议，协调各自的进展。如果软件规格说明书发生了变化，立即进行调整，重新进行软件设计。

控制工作的结果，把工作记录存档

掌握当前的工作进展情况，尽早地发现和分析问题，并采取相应的措施。对各种事件进行跟踪记录，包括：

.执行过程控制，跟踪进展情况并定期记录、存档。

.执行质量控制，保留质量记录。

.记录产品的配置、版本变化、bug的发现和处理等信息。

软件架构设计

软件架构也称为软件体系结构，需要考虑如何对系统进行分解，对分解后的组件及其之间的关系进行设计，满足系统的功能和非功能需求。软件架构形成过程如下图所示。

架构的形成过程概要

软件架构设计需要从用户业务需求、未来应用环境、需求分析、硬件基础、接口输入、数据处理、运算或控制规律、用户使用等方面进行综合、权衡和分析基础上产生。面向某种问题的架构一旦确定就很难改变，随后的架构设计需要通过一系列的迭代开发完善，使得软件架构日趋成熟、稳定。

软件架构的重要作用也在于控制一个软件系统的使用、成本和风险。好的架构要求是和谐的软件架构，包括与上一级系统架构相互和谐、与系统中同一级的其他组件架构互相和谐，确保系统满足性能、可靠性、安全性、信息安全性和互操作性等方面的关键要求，也具有可扩展、可移植性，从而为一个软件带来长久的生命力。

在大量开发实践中，有很多广泛使用并被普遍接受的软件架构设计原则，这些原则独立于具体的软件开发方法，主要包括抽象、信息隐藏、强内聚和松耦合、关注点分离等。

（1）抽象：这是软件架构的核心原则，也是人们认识复杂客观世界的基本方法。抽象的实质是提取主要特征和属性，从具体的事务中通过封装来忽略细节，并且运用这些特征和属性，描述一个具有普遍意义的客观世界。软件架构设计中需要对流程、数据、行为等进行抽象。复杂系统含有多层抽象，从而有多个不同层次架构。

（2）信息隐藏：包括局部化设计和封装设计。局部化设计就是将一个处理所涉及到的信息和操作尽可能地限制在局部的一个组件中，减少与其他组件的接口。而封装设计是将组件的外部访问形式尽可能简单、统一。

（3）强内聚和松耦合：强内聚是指软件组件内的特性，即组件内所有处理都高度相关，所有处理组合在一起才能组成一个相对完整的功能。而松耦合是指软件组件之间的特性，软件组件之间应尽量做到没有或极少的直接关系，使其保持相对独立，这样使得未来的修改、复用简单，修改之后带来的影响最小。

（4）关注点分离：所谓关注点是软件系统中可能会遇到的多变的部分。如为适应不同运行接口条件，需要进行适应性的参数调整和驱动配置。关注点分离设计是将这部分组件设计成为相对独立的部分，使未来的系统容易配置和修改。而核心的部分可以保持一个相对独立的稳定状态。如果功能分配使得单独的关注点组件足够简单，那么就更容易理解和实现。但“展示某些关注点得到满足时，可能会影响到其他方面的关注点，但架构师必须能够说明所有关注点都已得到满足”。

以上的原则中，删除需求细节或对细节进行抽象是最重要的工作，为用户的需求创建抽象模型，通过抽象将特殊问题映射为更普遍的问题类别，并识别各种模式。

软件架构设计使用纵向分解和横向分解两种方式。纵向分解就是分层，横向分解就是将每一个层面分成相对独立的部分。经过分解之后，可以将一个完整的问题分解成多个模块来解决。模块是其中可分解、可组装，功能独立、功能高度内聚、之间低耦合的一个组件。

类似于建筑架构，软件架构也决定了软件产品的好用、易用、可靠、信息安全、可扩展、可重用等特性，好的软件架构也给人完整、明确、清晰等赏心悦目的感觉，具有较长的生命力。

架构设计是围绕业务需求带来的问题空间到系统解决空间第一个顶层设计方案。按照抽象原则，在这个阶段进行的架构设计关注软件设计环节抽象出来的重要元素，而不是所有的设计元素。在架构设计时将软件这些要素看作是黑盒，架构设计需要满足黑盒的外部功能和非功能需求的目标。一个软件的架构设计首先为软件产品的后续开发过程提供基础，在此基础上可将一个大规模的软件分解为若干子问题和公共子问题。而一般意义的软件设计是软件的底层设计，开发人员需要关注各子问题或要素的进一步分解和实现，是根据架构设计所定义的每个要素的功能、接口，进一步实现要素组件内部的配置、处理和结构。在遵守组件外部属性前提下，考虑实现组件内部的细节及其实现方法。对于其中的公共子问题，形成公共类和工具类，从而可以达到重用的目的。

一般的软件构架是根据需求自上而下方式来设计，即首先掌握和研究利益相关方的关键需求，基本思路是首先进行系统级的软件架构设计，需要将软件组件与其外部环境属性绑定在一起，关注软件系统与外部环境的交联设计；其次将一个大的系统划分成各组成部分，这些部分可以按照架构设计的不同方法，分为层次或成为模块；之后再开始研究所涉及到的要素，再实现这些要素以及定义这些要素之间的关系。

在实际工作中，软件构架也可采用自底向上的方法，前提是已经建立了一个成熟稳定的软件架构，也可以称之为“模式”。模式是组织一级设计某一类具体问题的顶层思路，是为了解决共有问题解的方案模板，但并不是一个问题的设计或设计算法。

模式常常整合在一起使用，提供解决更大、更复杂问题的解决方案，而组成一个解决问题的通用框架。框架往往提供统一平台和开发工具，而且已经高效地利用了已经经过验证的模式、技术和组件。在新软件系统的设计中指定沿用或重用这种架构框架，这时其他重要元素可以在这个架构基础上针对新的需求进行扩展，有时是针对性地进行参数化设计。所以在架构设计中可以借用模式的概念进行设计，采用成熟的先进的设计框架和工具提高开发的效率，保证设计正确性。

下图所示是针对架构设计中非功能需求的多维度分析，从中可知任何一个因素的变化都会带来对其他因素的影响。实际上软件架构设计属于软件设计过程的一部分，但超越了系统内部的算法和数据结构的详细设计。

架构的多维度分析

在架构设计阶段，需要定义边界条件、描述系统组织结构、对系统的定量属性进行约束、帮助对模型进行描述并基本构造早期的原型、更准确地描述费用和时间的评估。

软件设计方法

在将系统分解为各个组件的过程中，需要采取不同的策略，而每个策略则关注不同的设计概念。根据分解过程中所采用的不同策略，设计方法有基于功能分解的设计方法、基于信息隐藏的设计方法和基于模型驱动开发的设计方法等分类。

（1）基于功能分解的设计方法。实时结构化分析与设计采用了功能分解，系统被分解为多个函数，并且以数据流或控制流的形式定义函数之间的接口；基于并发任务结构化的设计（Design Approach for Real-Time Systems，DARTS）提供了任务结构化标准，辅助人员确定系统中的并发任务，并指导定义任务接口。

（2）基于信息隐藏的设计方法。面向对象（Object Oriented，OO）设计方法将数据和数据上操作封装在对象实体中，对象外界不能够直接对对象内部进行访问和操作，只能通过消息间接访问对象，符合人类思维方式，提高软件的扩展性、维护性和重用性。

（3）基于模型驱动开发的设计方法。通过借助有效的（Model Driven Development，MDD）工具，构建和维护复杂系统的设计模型，直接产生高质量的代码，将开发的重心从编码转移到设计。当前使用较为广泛的MDD工具有IBM公司的Rhapsody。

软件设计阶段

从工程管理角度来看，软件设计可分为概要设计和详细设计两个阶段。

概要设计

概要设计也称为高层设计，即将软件需求转化为数据结构和软件的系统结构。例如，如果采用结构化设计，则从宏观的角度将软件划分成各个组成模块，并确定模块的功能及模块之间的调用关系。

概要设计主要包括设计软件的结构、确定系统由哪些模块组成，以及每个模块之间的关系。它采用的是结构图（包括模块、调用和数据）来描述程序的结构，还可以使用层次图和HIPO（层次图加输入／处理／输出图）。整个过程主要包括复查基本系统模型、复查并精化数据流图、确定数据流图的信息流类型（包括交换流和事务流）、根据流类型分别实施变换分析或事务分析，以及根据软件设计原则对得到的软件结构图进一步进行优化。

详细设计

详细设计也称为低层设计，即对结构图进行细化，得到详细的数据结构与算法。同样，如果采用结构化设计，则详细设计的任务就是为每个模块进行设计。

详细设计确定应该如何具体地实现所要求的系统，得出对目标系统的精确描述。它采用自顶向下、逐步求精的设计方式和单入口单出口的控制结构。经常使用的工具包括程序流程图、盒图、PAD图（问题分析图）及PDL（伪码）。

总的来说，在整个软件设计过程中，需完成以下工作任务。

（1）制定规范，作为设计的共同标准。

（2）完成软件系统结构的总体设计，将复杂系统按功能划分为模块的层次结构，然后确定模块的功能，以及模块间的调用关系和组成关系。

（3）设计处理方式，包括算法、性能、周转时间、响应时间、吞吐量和精度等。

（4）设计数据结构。

（5）可靠性设计。

（6）编写设计文档，包括概要设计说明书、详细设计说明书、数据库设计说明书、用户手册和初步的测试计划等。

（7）设计评审，主要是对设计文档进行评审。

在设计阶段，必须根据要解决的问题做出设计的选择。例如，半结构化决策问题就适合由交互式计算机软件来解决。

设计阶段

设计阶段监理进行质量控制的要点如下。

（1）了解建设单位的建设需求和对信息系统安全性的要求，协助建设单位制定项目质量目标规划和安全目标规划。

（2）对各种设计文件提出设计质量标准。

（3）进行设计过程跟踪，及时发现质量问题，并及时与承建单位协调解决。审查阶段性成果，并提出监理意见。审查承建单位提交的总体设计方案，审查承建单位对关键部位的测试方案。

（4）协助承建单位建立质量保障体系。

（5）协助承建单位完善现场质量管理制度。

（6）组织设计文件及设计方案交底会，制定质量要求标准。

项目干系人

定义

项目干系人（Project Stakeholder），也称为利害相关者，是积极参与项目，或其利益因项目的实施或完成而受到积极或消极影响的个人或组织，他们还会对项目的目标和结果产生影响。项目管理团队必须明确项目的干系人，确定其需求，然后对这些需求进行管理和施加影响，确保项目取得成功。

干系人对项目的影响

包括积极的影响和消极的影响。项目管理团队不仅要关注积极的项目干系人，也不能忽略消极项目干系人。项目关键干系人包括：

.项目经理（Project Manager）

.顾客／客户（Customer/User）

.执行组织（Performing Organization）

.项目团队成员（Project Team Members）

.项目管理团队（Project Management Team）

.出资人（Sponsor）

.有影响力的人（Influencers）

.项目管理办公室（PMO）

更多复习资料
请登录电脑版软考在线 www.rkpass.cn

京B2-20210865 | 京ICP备2020040059号-5